Wireless/wired mix sensor network

[Register 3]

Hi,

My project is an home automation network. The first aim was to regulate the two heaters I got in my business place. So I made a first PoC with an arduino nano and a rapsberry. The nano sends to the RPi temperature from one side of the room and the a RPI log it along with it's own temperature measurement (the 2 based on DS18B20). Communications between the two is done by 2 RF24 modules, the Raspberry got one 433 transmitter to send order to 2 Chacon switch plug onto which the heaters are connected.

On the raspberry I got a Python module logging the temperature in files and a web site in php to display temp graphs with d3.js.

As everything was ok, and with some advices from HackSpark.fr shop owner I switched to the MSP430 platform. Got now three sensors, 2 soldered and one on a bread board, communicating with one Rpi.

 

Now for the future :

Challenge 1
Part 1
At the moment I'm using ManiacBug library for Energia, and use the RF24 auto ack with the sensors writing to the same pipe (they write every 10 seconds but should at last write once a minute) so there are few packet packet collision, but to avoid this problem, and as I want more than 5 sensors, I'm gonna have to manage some network addresses and the management packet acknowledgements.

Which strategy for address assignment ? I would like to have the more flexible solution. So the sensor have to register themselves to the logger (RPi) so the loggers (in case several sensor networks) had to have the same physical address (on the RF24) as for each sensors. At init the sensors call the logger and register themselves. If there are several logger reachable, you have to accept the new sensor on the logger side. When the logger accept a new sensor it send back to the sensor a 'local' address for the network it manages.  The security concerns are not taken into account in my near future plan.
The addresses must be unique (managed by the logger) they are compose by the network id and the sensor address, so the logger or networks must have unique ids and not two long has the payload is only 32 bytes on the RF24...

The user have to manage the link between physical sensors and logical assignments ( 0x02f = the one in the garage) in case of replacement or complete reset of an existing sensor.


Part 2
One of my plan is to monitor plants soil in pot moisture  (for exemple). So the wireless is less interesting as the pot may be near each other or need 2 sensor due to their size. What i want to achieve is to have one transmitter with several wired sensor hooked to it. The perfect solution is to have the possibility to daisy chain the sensors. So here to I should have a unique "address" for each sensor had to the network.
The goal is to identify each sensor across the network and to have the possibility to request or command them.

I'm wondering which way to go, the easiest the better ;-), implementing OneWire sensors (i need distance, moisture, flow...) as i already have OneWire ds18b20 or I2C...

The wired sensor need to measure and transmit it with a stable address (keep it if it switch off) but it doesn't not to have to bee an hardware one, should be assigned on network registering. The address of the wired sensors are sub address of  the sensor. Or they could be considered has  'top' address and the wireless sensor they are attached to have to manage is packets and for attached sensor.

 

Challenge 2

The protocol : the transmission packet themselves. It has to be the more flexible possible, clear string one will be too long, for the moment I use a struct but it's to  restricting if the protocol must evolve...

And now the fun part : the images :-)

 

The Wip version

 

The soldered version

 

The logger with its screen : date, hour and three temp.

 

The graphs

[spirilis 1,265]

I read part 1 mostly, kind've glazed over some details but at this point I want to share what I did for widespread nRF24L01+ based sensor networking.

 

My architecture includes a "packet format" with code that I include in each project to drive this protocol, both on the transmit side & receive side.  It's a lightweight "logical link control" layer overtop the nRF24's 32-byte packet format (let's call them "frames", actually, to use a lexicon similar to Ethernet).  The protocol even supports stuffing multiple "packets" inside the 32-byte frame.

 

Each logical "packet" consists of:

1 byte = Program ID, indicating what type of packet this is.  (Temperature data?  GPIO setting command intended for a remote recipient? Debug information? Relative humidity + temperature?  Water level?)  I have a manifest of program ID assignments I've made for myself.

1 byte = Packet length, indicating the size of the payload which follows.

X bytes = packet contents

(after processing this packet, if any bytes remain in the frame, the protocol interpreter goes back through the loop interpreting the next program ID, packet len, contents, etc)

 

Within the packet format, each program ID handles the contents differently but generally speaking, all of them support a 1-byte Logical Address ID that has nothing to do at all with nRF24L01+ addresses.  This ID is hardcoded into the firmware so I can tell one sensor from another, but there's nothing to say you can't make this auto-configurable.

 

For packets that request a reply from the base station, the program ID for that packet type declares that the first 5-bytes of the payload are the remote sensor's nRF24 address.  For auto-discovery purposes, this could be chosen at random on startup using some sort of random-number source.  The base station will then send the appropriate reply (reply packets will use yet a different program ID, i.e. think like ICMP Echo Request vs ICMP Echo Reply in IPv4) to the 5-byte address previously reported.  This could be used by a newly-connected sensor to autoconfigure its 1-byte ID.  Future reports from this sensor will be sent to the base station's address but with the ID of the packet contents set to the sensor's unique ID byte.  That way you can tell one sensor from another.

 

Or maybe you can forego this autoconfigure process and have a set of DIP switches or jumpers on each of your sensor nodes so you can manually configure them.  That way you know which ID corresponds to which physical sensor.  For my current installation I just hardcode the ID in the firmware and change it + recompile for each sensor I program.

[Register 3]

Hi,

Thanks for your answer, I want to avoid setting  in firmware and compiling, because it's prone to error. One way is write ID in flash bank when it's not set or forced to be change, so this way I can recompile and load firmware without thinking about id's each time.

For the protocol/frame/packet what ever i use structs as :

#define DOMOS_PROT_V = 1 ;

#define DMS_SERVICE_MSG 1
#define DMS_MEASURE_MSG 2

#define DMS_RQST_ID 1
#define DMS_SEND_ID 2

#define DMS_MEASURE_T_LONG 1
#define DMS_MEASURE_T_FLOAT 2

#define DMS_MEASURE_TEMPERATURE 1
#define DMS_MEASURE_DISTANCE 2
#define DMS_MEASURE_BATTERY_VOLTAGE 3
#define DMS_MEASURE_MOISTURE 4

struct domos_service_msg
{
 uint8_t type ;
 char value[10] ;
} ;


struct domos_measure_msg
{
 uint8_t sensor_id ;
 uint8_t sensor_type ;
 uint8_t type ;

 int32_t value ;
} ;

struct domos_msg
{
 uint8_t address ; // Address of the transmiter
 uint8_t id ;      // message id (counter)
 uint8_t type ;    // Type of union
 union
 {
  domos_service_msg service ;	
  domos_measure_msg measure ;	
 } msg ;
} ;