Changes

Jump to: navigation, search

Sensor nodes

1,379 bytes added, 10:24, 17 August 2015
=== Sensors ===Here is a list of the sensors I made/will made, complete with Kicad files (schematics and PCB layouts)
 ==== Light Sensor ====
[[File:Light-B Cu.svg]]
(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.
154
edits