- Low power node : Mesh node that can be a sensor Tag that wakes up on RTC or on sensor value interrupt to log a parameter. Can also be a button that wakes up on a press PIO interrupt.
- Router node : Mesh node that cooperates with the Low power nodes, the router has to be a device that keeps listening permanently on the same RF channel, this might require ~ 13 mA. Example router devices are light controllers, server’s RF dongle or USB powered sensors and status devices.
- Server : A Raspberry pi running linux. The RF signals come through the serial port or with a USB adapter, then published on MQTT, from which Python scripts inject signals on the Database, connected to Grafana web server. Note that there can be multiple router dongles connected to servers.
The Home Smart Mesh project introduce an RF Mesh protocol which is a complete stack implementation to allow devices to communicate in a Mesh Network Topology. This protocol implementation is using the nRF SDK 15 it is using the Radio module through a modified Enhanced Shock-burst custom protocol. Implementations range from nRF24L01+ with an STM8L and STM32 to the nRF51 and nRF52 families that add features such as RSSI and bigger packets sizes.
As per the projects github history, this mesh protocol has preceded the Bluetooth Mesh which is now converging into the same concepts of sleepy / active nodes and flood communication.
- 100% Open source Mesh RF Stack
- Ported on STM8L, STM32, nRF51 and nRF52
- Concept designed for Low Power Nodes and Router Nodes
- Same radio channel configured for the whole network
- Single channel allows maximum power save with unlimited sleep periods, and random wake up with button press or sensor event.
- Mesh with flooding broadcast, where every message has its own configurable time to live. This brings multiple advantages of usage simplicity.
- Short addresses allow efficient packets sizes. Possibility for extensions with short address reuse and exception addresses to allow unlimited network size.
- For simplicity purpose, security is a matter of application payload content.
- Raspberry pi server with two interface implementations:
- C++ version for performance
- Python version for shell debug of the mesh Network.
- The stack is so small that the RAM and ROM are left for the application logic, not requiring a network co-processor.
- A simple flood mechanism is implemented where every router repeats the signal heard decrementing the time to live to avoid infinite propagation.
- Future extensions can extend the routing by gathering statistics and deciding of the optimal path in a decentralized fashion. Note that small installations in a home do not bring any significant advantage, thus the interest for a simple protocol for such use case.
Peer 2 peer
- This type of communication uses a source and destination addresses
- Only the node recognizing itself as destination will send a packet as acknowledge
- The acknowledge packet is propagated the same way, until it reaches the source, which make it an end to end acknowledge
- If the source did not got an acknowledge back while it was requested, it can retry the transmission again.
This protocol is using the direct Radio module capabilities and does not require the sofdevices. The softdevices are Nordic firmware that are closed source and distributed as binaries, they have higher privileges than the user application. Softdevices guarantee that the RF functions keep always working as the user application is untrusted. This comes at a big price to pay, as the rest of the SoC cannot be properly used, no free configuration of interrupts for example, they have also a big memory footprint that prevents safe double paged firmware updates.
The nRF Packet as used by the RF hardware module can be seen below
The HSM (Home Smart Mesh) configuration has discarded the usage of S0 and S1 which are intended for compatibility with other protocols which require a certain number of bits on the air that do not map to 8 aligned to form bytes in memory.
- control: bit 7 defines whether a packet is to be broadcasted or has a target destination. Bits 6 and 5 allow safe communication with acknowledge, and a request response type. That allows the sw stack to handle the acknowledge and re-transmission. bit 3 allows streaming of messages without acknowledge.
- pid: is defining the application function which maps to a particular payload serialization
- Source and dest: are the Node Id, and are unique within every mesh. Although 8 bits, exceptions allow further reserved sizes.
- Time to live : used by the routers to know when to drop the packet.
Alive trace routing
- All Nodes including the low power, send a periodic “alive” packet
- The initiator includes a counter that informs about the live cycle count
- Every retransmission appends information about
- Received RSSI (Radio Signal Strength Indicator)
- The Node Id of the Router performing the re transmission
- Transmission power with which the packet has been re transmitted
Alive on MQTT
- The “alive” packet that reaches the server’s dongle has the full route information
- Multiple paths can reach the server for the same original broadcast
- A single “alive” packet can provide link status of the complete mesh netwrok
- The signal route information is packed in a json structure
- json structures are broadcasted on the jNodes topics path