Difference between revisions of "Sensor nodes"

From Fixme.ch
Jump to: navigation, search
m
 
Line 54: Line 54:
  
 
Notes:
 
Notes:
 +
 
The next step will be to add mesh-networking capabilities by sending a broadcast packet and waiting for the reply from the others nodes, and create a table of reachable nodes.
 
The next step will be to add mesh-networking capabilities by sending a broadcast packet and waiting for the reply from the others nodes, and create a table of reachable nodes.
It would be nice to add some randomness in the delays of transmission otherwise we will only receive packets from nodes emitting at a precise moment
+
 
 +
It would be nice to add some randomness in the delays of transmission otherwise we will only receive packets from nodes emitting at a precise moment.
 +
 
 
Also, at the moment the packets are received in a dumb fashion, so we are not sure if the values will correctly update. We could correct this by adding a fifo queue on the receiving node (the raspi) and treat the packets one by one, not ignoring some while the last packet is treated.
 
Also, at the moment the packets are received in a dumb fashion, so we are not sure if the values will correctly update. We could correct this by adding a fifo queue on the receiving node (the raspi) and treat the packets one by one, not ignoring some while the last packet is treated.

Latest revision as of 13:24, 17 August 2015

The goal is to have a working, mesh network of sensors (i.e. light, temperature, presence) and actuators (motors to open / close a window, turn lights on and off, etc.). The solution is centred around a raspberry pi that has a NRF24L01+ chip, and works as a central point for gathering all of the data received via the radio. It then builds a webpage transmitting the data in real time and then rules are applied so that we can say, activate one motor if the value of a sensor is below 20° The nodes are based on the ATTiny85 AVR micro-controller and another NRF24L01+ chip.


Parts

  • Raspberry Pi
  • x + 1 NRF24L10+ chips, where x is the number of nodes
  • x ATTiny
  • Tool to flash the ATTiny, this can either be an arduino (using the Arduino as ISP sketch) or a dedicated AVR USB programmer


Sensors

Here is a list of the sensors I made/will made, complete with Kicad files (schematics and PCB layouts)


Light Sensor

Light-B Cu.svg

Uses a light dependant resistor (todo)

Temperature & Humidity

(todo)

Presence (PIR)

(todo)

Gaz

(todo)

Piezo

(todo)

Sound

(todo)


Actuators

RGB Led strip

Be able to change the color

Window opening

Use a motor to open / close a window

Blinders

(todo)

Sound

(todo)

Code

On the final destination node (raspi): There will be 2 parts of code running in parallel. The first one will get the values through the NRF24L01+ and parse them into a json file that will be used for a web interface. The other part will allow the dynamic creation of rules that have to be applied (e.g. turn on the lights if the presence sensor activates, etc.).

Transmission

The radio packets contains 4 values to transmit:

  • The ID of the node (unsigned int_8) -> max nodes = 255
  • The type of value (temperature/presence/humidity/light) or the type of "activator" (blinders/doors/lights)
  • The value to transmit as a signed int8_t (from -128 to 127) (Note: maybe this is not enough, try other sizes)

Notes:

The next step will be to add mesh-networking capabilities by sending a broadcast packet and waiting for the reply from the others nodes, and create a table of reachable nodes.

It would be nice to add some randomness in the delays of transmission otherwise we will only receive packets from nodes emitting at a precise moment.

Also, at the moment the packets are received in a dumb fashion, so we are not sure if the values will correctly update. We could correct this by adding a fifo queue on the receiving node (the raspi) and treat the packets one by one, not ignoring some while the last packet is treated.