sensorNET - Project Update
I have been working on the sensorNET project and I thought it was time for an update on where I am at the moment. As I go about developing the code, new questions arise and sometimes, those questions push the project into some new direction I never considered before.
Consider the following shematic:
The connections from the console to the client boards is nothing new (we distribute both power and data connections to the clients). There's also nothing new in that the main console connects to a main server that organizes and saves data sent from the console and makes that data available through user interaction with read and write APIs (the thingspeak and pachube model).
New proposed server extra-functionality
If we consider the above, however a few questions arise, specially if we want to make this project truly universal, to the point where anybody can contribute with new client boards. Those new client boards need to have a set of commands that the main console cannot know beforehand and must be declared to the main console afterwards without reloading firmware.
Since we are connected to the internet (or to a LAN server) anyway, we may store the parameters of each new board on that server and then send the configuration to the main console once it detects that type of client connected to it. If we follow a clear standard it is possible for he main console to handle future boards.
Conceptually, the main server will require a table to store new device data (table_device: id, developer_name, board name, description) and another to store the list of commands the new client may receive from the master console (table_device_command: id, device_id, command_value, command_description).
Developers of new client boards need only to register their boards and specify their commands. Needless to say this allows for complex boards, capable of simultaneous input and output. For example, we can have a board that has a temperature sensor and a relay output. Sending a 0x01 to the i2C address that board is connected to will make the board send the temperature value back, if we send a 0x02, we activate the relay. Sending 0x03 deactivates the relay.
The concept of rules
After the user configures the network parameters and the server address on the main console using a serial connection (possibly dedicated configuration software will have to be developed, more on this on another post), we are left with a board connected to I/O and in turn connected to the internet. The input data may be local or remote and we may act on the world depending on the data received. For example if we consider a system that contains two relays (R1 and R2), one controllable LED, a local temperature sensor (that may live on the same board as the relays or on another connected to the same console) but also reads a temperature feed from another public feed from another user available on the server. In summary we have:
a) one local input (temperature)
b) one remote input (temperature from another feed)
c) one output R1
d) one output R2
e) one output controllable LED L1
and we would like to achieve the following:
1. post our temperature data to a public feed on the network server
2. activate relay 1 if local temperature above 25
3. activate relay 2 if remote temperature above 25
4. deactivate relay 1 if local temperature below 22
5. deactivate relay 2 if remote temperature below 22
6. activate LED if both local and remote temperature above 25
7. achieve this without uploading new firmware on the main console
To do this we could make use of the concept of rules, which is a list of actions specified on the server that would look a bit like a list of firewall rules. These are then uploaded to the main console that saves them on EEPROM and then starts playing the new rules after a reset (I can't get rid of the need to do a board reset).
Because we are connected to a server some of the actions to be taken (Outputs) may be on server side, for example send an email or an sms through a sms service.
I'm quite confident I can achieve what I describe above. See my next post for the status of the programming on the project and for the code as it is at the moment.
Consider the following shematic:
New proposed server extra-functionality
If we consider the above, however a few questions arise, specially if we want to make this project truly universal, to the point where anybody can contribute with new client boards. Those new client boards need to have a set of commands that the main console cannot know beforehand and must be declared to the main console afterwards without reloading firmware.
Since we are connected to the internet (or to a LAN server) anyway, we may store the parameters of each new board on that server and then send the configuration to the main console once it detects that type of client connected to it. If we follow a clear standard it is possible for he main console to handle future boards.
Conceptually, the main server will require a table to store new device data (table_device: id, developer_name, board name, description) and another to store the list of commands the new client may receive from the master console (table_device_command: id, device_id, command_value, command_description).
Developers of new client boards need only to register their boards and specify their commands. Needless to say this allows for complex boards, capable of simultaneous input and output. For example, we can have a board that has a temperature sensor and a relay output. Sending a 0x01 to the i2C address that board is connected to will make the board send the temperature value back, if we send a 0x02, we activate the relay. Sending 0x03 deactivates the relay.
The concept of rules
After the user configures the network parameters and the server address on the main console using a serial connection (possibly dedicated configuration software will have to be developed, more on this on another post), we are left with a board connected to I/O and in turn connected to the internet. The input data may be local or remote and we may act on the world depending on the data received. For example if we consider a system that contains two relays (R1 and R2), one controllable LED, a local temperature sensor (that may live on the same board as the relays or on another connected to the same console) but also reads a temperature feed from another public feed from another user available on the server. In summary we have:
a) one local input (temperature)
b) one remote input (temperature from another feed)
c) one output R1
d) one output R2
e) one output controllable LED L1
and we would like to achieve the following:
1. post our temperature data to a public feed on the network server
2. activate relay 1 if local temperature above 25
3. activate relay 2 if remote temperature above 25
4. deactivate relay 1 if local temperature below 22
5. deactivate relay 2 if remote temperature below 22
6. activate LED if both local and remote temperature above 25
7. achieve this without uploading new firmware on the main console
To do this we could make use of the concept of rules, which is a list of actions specified on the server that would look a bit like a list of firewall rules. These are then uploaded to the main console that saves them on EEPROM and then starts playing the new rules after a reset (I can't get rid of the need to do a board reset).
Because we are connected to a server some of the actions to be taken (Outputs) may be on server side, for example send an email or an sms through a sms service.
I'm quite confident I can achieve what I describe above. See my next post for the status of the programming on the project and for the code as it is at the moment.
Comments