Porting MySensors to work with the RadioHead library
-
RH is a true mesh where every node can communicate with any other directly (if in range). All nodes acts as repeaters.
MySensors forms nodes forms a star network where every node has a parent and potentially a few child sensors. The gateway node is the "center". Every node always tries to find the closest (least number of hops) route to gateway.
GW / \ A D / \ B CIf B want to communicate with C messages has to pass A in the MySensors case. In RH C and B will communicate directly if the can hear each other.
RH does not use the nifty features NRF24L01 offers which offloads mcu (pipes/addresses) nor auto ack (impossible in RH setup). So nodes in range has to process every message it can "hear". And this can potentially be a lot.
@hek said:
RH does not use the nifty features NRF24L01 offers which offloads mcu (pipes/addresses) nor auto ack (impossible in RH setup). So nodes in range has to process every message it can "hear". And this can potentially be a lot.
So MySensors can use both individual node addresses as well a broadcast, while RH uses only broadcast (at the radio level)? I understand why RH needs to do this, and I wonder if the receive FIFO ever overruns with unneeded packets.
I wonder if MySensors gets much savings from using the auto-ack of ESB. If you already have network ack code anyway, how much code & ram is saved by sometimes using ESB (one hop away) and sometimes not? (I do get that a star network with no repeater nodes could use only ESB autoack and save some code).
-
@Zeph said:
So MySensors can use both individual node addresses as well a broadcast, while RH uses only broadcast (at the radio level)?
Yes.
I think end-to-end ack is very important. The inter-node ack is only used as a trigger re-routing today (if communication fails 3 times to parent node .. the node tries to find another parent).
-
Could someone please explain to me how the direct messaging of the NRF24 works? In my mind every radio network is a broadcast network on the physical layer, and it is up to the receiving radio to determine whether the packet is relevant or not. How is this different from your radios? Is it perhaps that your radios have a hardware address so that the filtering is done on the hardware level, while Radiohead uses a software address, so each packet has to be explicitly processed? I have no idea, I'm just guessing here...
-
Could someone please explain to me how the direct messaging of the NRF24 works? In my mind every radio network is a broadcast network on the physical layer, and it is up to the receiving radio to determine whether the packet is relevant or not. How is this different from your radios? Is it perhaps that your radios have a hardware address so that the filtering is done on the hardware level, while Radiohead uses a software address, so each packet has to be explicitly processed? I have no idea, I'm just guessing here...
Yes,
NRF chip offer 6 reading "pipes". In practice it acts as a hw filter for addresses between 0-255.
I use this to have one broadcast address (255) which all repeating nodes and gateway listens to and each sensor also listen to its own address.
-
Looking at the documentation for the RF69 (page 41) it talks about sync word recognition. This is a programmable word that apparently can be used as the node's hardware address, similarly to the NRF24. Perhaps it is possible to expand the Radiohead drivers to utilise this functionality where it is available for filtering incoming packets?
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications. We have horses, and it would be really fun to place a radio module with a accelerometer, and maybe GPS receiver, on each horse to track their movements. This could also be combined with a breakable wire in the harness which would let us know if the radio had been ripped off of the horse. Having a dynamic mesh will greatly increase the range of flexibility of such a monitoring network. I know that this is somewhat outside of the normal use case, but how fun wouldn't it be to build this? :-).
Personally I'm also a bit interested in direct sensor to sensor configurations to allow for tightly coupled control systems without the need for a central controller in the loop (all the time). I know, we have resource limits so that I can probably not have everything, but one can dream...
-
Nevermind the sink word recognition, this appears to function as some kind of network ID has to be the same for both the sender and receiver. However, there is also an optional address byte which is considered by the radio before the packet enters the FIFO queue. Page 55 of http://www.hoperf.com/upload/rfchip/RF69-V1.2.pdf
-
Nevermind the sink word recognition, this appears to function as some kind of network ID has to be the same for both the sender and receiver. However, there is also an optional address byte which is considered by the radio before the packet enters the FIFO queue. Page 55 of http://www.hoperf.com/upload/rfchip/RF69-V1.2.pdf
-
Looking at the documentation for the RF69 (page 41) it talks about sync word recognition. This is a programmable word that apparently can be used as the node's hardware address, similarly to the NRF24. Perhaps it is possible to expand the Radiohead drivers to utilise this functionality where it is available for filtering incoming packets?
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications. We have horses, and it would be really fun to place a radio module with a accelerometer, and maybe GPS receiver, on each horse to track their movements. This could also be combined with a breakable wire in the harness which would let us know if the radio had been ripped off of the horse. Having a dynamic mesh will greatly increase the range of flexibility of such a monitoring network. I know that this is somewhat outside of the normal use case, but how fun wouldn't it be to build this? :-).
Personally I'm also a bit interested in direct sensor to sensor configurations to allow for tightly coupled control systems without the need for a central controller in the loop (all the time). I know, we have resource limits so that I can probably not have everything, but one can dream...
@kolaf said:
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications.
Yep, both pros and cons. :)
A nice feature you can do with MySensors is to set a static parent (when calling gw.begin()). This could be useful for a presence sensor e.g. mounted on a car set statically to contact a repeater node mounted near the garage. The car sensor won't try to find or contact any other node than the garage one.
-
Looking at the documentation for the RF69 (page 41) it talks about sync word recognition. This is a programmable word that apparently can be used as the node's hardware address, similarly to the NRF24. Perhaps it is possible to expand the Radiohead drivers to utilise this functionality where it is available for filtering incoming packets?
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications. We have horses, and it would be really fun to place a radio module with a accelerometer, and maybe GPS receiver, on each horse to track their movements. This could also be combined with a breakable wire in the harness which would let us know if the radio had been ripped off of the horse. Having a dynamic mesh will greatly increase the range of flexibility of such a monitoring network. I know that this is somewhat outside of the normal use case, but how fun wouldn't it be to build this? :-).
Personally I'm also a bit interested in direct sensor to sensor configurations to allow for tightly coupled control systems without the need for a central controller in the loop (all the time). I know, we have resource limits so that I can probably not have everything, but one can dream...
@kolaf said:
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications. We have horses, and it would be really fun to place a radio module with a accelerometer, and maybe GPS receiver, on each horse to track their movements. This could also be combined with a breakable wire in the harness which would let us know if the radio had been ripped off of the horse. Having a dynamic mesh will greatly increase the range of flexibility of such a monitoring network.
Just brainstorming, but what if we consider adding the concept of a roving node to the MySensors network, without the overhead of a full mesh? Your use case doesn't require that all nodes be meshed with each other, just that a class of leaf nodes be able to move around.
If I understand, a gateway or repeater node will forward a packet from anybody, if it recognizes the destination (as a node id in its routing table). Suppose you had coverage of your corral (or whatever) via gateway and various repeaters. In theory (perhaps naive theory) the roving node could report to the gateway by broadcasting a message picked up by whatever repeater is nearest; being addressed to node 0, the repeater knows what to do with it.
There would be no network ack and no way for the gateway to send to the roving node as described so far. That is, unless this special "rover packet" caused each relay to rewrite that entry of its routing table as it was passed to the gateway, to enable an updated path back to the roving node. If your horses run around among many nodes often, EEPROM wear could be a concern, unless there was a small "routing override table" in RAM to handle roving nodes.
One part I'm not clear about is how to avoid two or more nearby repeaters both forwarding this broadcast packet from the roving node. That might be tricky if it often causes OTA collisions. It could also complicate the back route logic, IF that was implemented. If we could avoid or gracefully recover from collisions, the gateway and controller may be able to deal with multiple copies of the same packet (not unlike the MQTT level 1 "deliver at least once").
And - it might be technically infeasible to enhance MySensors networking to support roving nodes. But in that case I'm sure I'll learn something from the manner in which it's shot down :-)
-
@kolaf said:
an optional address byte
The trouble is you have to distinguish between broadcasts and direct messages, so you need to listen at 2 addresses at a time, so to say.
@Yveaux said:
@kolaf said:
an optional address byte
The trouble is you have to distinguish between broadcasts and direct messages, so you need to listen at 2 addresses at a time, so to say.
There is a separate optional broadcast address byte. I'm not sure how this is used, but I'm guessing that the radio checks against both addresses before deciding what to do with the message. That should solve the broadcast problem.
-
@kolaf said:
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications. We have horses, and it would be really fun to place a radio module with a accelerometer, and maybe GPS receiver, on each horse to track their movements. This could also be combined with a breakable wire in the harness which would let us know if the radio had been ripped off of the horse. Having a dynamic mesh will greatly increase the range of flexibility of such a monitoring network.
Just brainstorming, but what if we consider adding the concept of a roving node to the MySensors network, without the overhead of a full mesh? Your use case doesn't require that all nodes be meshed with each other, just that a class of leaf nodes be able to move around.
If I understand, a gateway or repeater node will forward a packet from anybody, if it recognizes the destination (as a node id in its routing table). Suppose you had coverage of your corral (or whatever) via gateway and various repeaters. In theory (perhaps naive theory) the roving node could report to the gateway by broadcasting a message picked up by whatever repeater is nearest; being addressed to node 0, the repeater knows what to do with it.
There would be no network ack and no way for the gateway to send to the roving node as described so far. That is, unless this special "rover packet" caused each relay to rewrite that entry of its routing table as it was passed to the gateway, to enable an updated path back to the roving node. If your horses run around among many nodes often, EEPROM wear could be a concern, unless there was a small "routing override table" in RAM to handle roving nodes.
One part I'm not clear about is how to avoid two or more nearby repeaters both forwarding this broadcast packet from the roving node. That might be tricky if it often causes OTA collisions. It could also complicate the back route logic, IF that was implemented. If we could avoid or gracefully recover from collisions, the gateway and controller may be able to deal with multiple copies of the same packet (not unlike the MQTT level 1 "deliver at least once").
And - it might be technically infeasible to enhance MySensors networking to support roving nodes. But in that case I'm sure I'll learn something from the manner in which it's shot down :-)
-
@kolaf said:
As for the dynamic mesh, this is a feature I find especially useful for one of my dream applications.
Yep, both pros and cons. :)
A nice feature you can do with MySensors is to set a static parent (when calling gw.begin()). This could be useful for a presence sensor e.g. mounted on a car set statically to contact a repeater node mounted near the garage. The car sensor won't try to find or contact any other node than the garage one.
-
@Yveaux said:
@kolaf said:
an optional address byte
The trouble is you have to distinguish between broadcasts and direct messages, so you need to listen at 2 addresses at a time, so to say.
There is a separate optional broadcast address byte. I'm not sure how this is used, but I'm guessing that the radio checks against both addresses before deciding what to do with the message. That should solve the broadcast problem.
@kolaf said:
There is a separate optional broadcast address byte. I'm not sure how this is used, but I'm guessing that the radio checks against both addresses before deciding what to do with the message. That should solve the broadcast problem.
That's good!
-
@Yveaux said:
@kolaf said:
an optional address byte
The trouble is you have to distinguish between broadcasts and direct messages, so you need to listen at 2 addresses at a time, so to say.
There is a separate optional broadcast address byte. I'm not sure how this is used, but I'm guessing that the radio checks against both addresses before deciding what to do with the message. That should solve the broadcast problem.
@kolaf said:
There is a separate optional broadcast address byte.
Aha, I see that on page 57 now.
I think that would handle it! (I see no need for 6 address-filtered pipes, two addresses will do).
Yes, it would be nice if the RH library could take advantage of address filtering for those radios which support it. I'm not so sure auto-ack is important tho.
-
So, anyone still developing on RadioHead integration, or did all of you just give up? ;-)
I spend some time on writing Wireshark dissectors for RadioHead and integration of MySensors, to be used with the sniffer (http://forum.mysensors.org/topic/242/wireless-nrf24l01-sniffer-for-mysensors)
Code is almost final (still have to test dessection of routing tables).Just as a preview, here's a screenshot to hopefully get you enthusiastic again!
http://yveaux.blogspot.nl
-
So, anyone still developing on RadioHead integration, or did all of you just give up? ;-)
I spend some time on writing Wireshark dissectors for RadioHead and integration of MySensors, to be used with the sniffer (http://forum.mysensors.org/topic/242/wireless-nrf24l01-sniffer-for-mysensors)
Code is almost final (still have to test dessection of routing tables).Just as a preview, here's a screenshot to hopefully get you enthusiastic again!
-
I'm still a bit in doubt how sleeping nodes fit in when using RadioHead.
It has no notion of sleeping nodes and just expects all nodes to be available anytime.
When a route is e.g. discovered which uses a node that is about to go to sleep, routing will fail, but probably the route will then be rediscovered and finally settle using a node that is continuously powered.
How long this will take and the likelyhood of such scenarios (depends ofcourse on the amount of nodes and how often/when they are awake) is still unclear to me.
Hopefully I can analyze some real-world behavior using the sniffer. -
So, anyone still developing on RadioHead integration, or did all of you just give up? ;-)
I spend some time on writing Wireshark dissectors for RadioHead and integration of MySensors, to be used with the sniffer (http://forum.mysensors.org/topic/242/wireless-nrf24l01-sniffer-for-mysensors)
Code is almost final (still have to test dessection of routing tables).Just as a preview, here's a screenshot to hopefully get you enthusiastic again!
@Yveaux said:
So, anyone still developing on RadioHead integration, or did all of you just give up? ;-)
no progress on my end - but that's rather related to the fact that this was my first week back in the office after vacation...
I think we should do one thing first: decouple the "network layer" from the "application layer" in MySensors:
- not having MySensors derived from RF24
- have a "generic" interface between MySensors and the radio
That way it would be rather easy to make use of other radios and other network topologies - could be RH or something else. I've taken a shot at that (a lot of this based on what Kolaf and Yveaux did adjusting MySensors to RH) and will provide a link once it compiles and is tested and I hope I can keep the overhead small enough to be acceptable for the gained flexibility.
-
It is great to see that something is still happening. I wonder if I can build a packet sniffer for the RF69 radios? I guess it shouldn't be that difficult since they receive everything that is sent...
The reason for my lack of progress late the has several reasons.
- I have a version of the library networks for my simplifications. This means that I can start building small sensors instead of spending all my time on the library :-)
- My kids think I spent way too much time on this project already :-(
- I'm waiting for some kind of consensus to emerge.
My hope has been to get this new radio library thing to a point where the community would adopt it so that I would not have to do any specific maintenance to keep my copy up to date with the official version. Based on this very long discussion thread there seems to be interest among you guys to achieve this, so I hope we will be able to get there at some point. However, we need to agree on how it is to be done, how much of the Radiohead library we want to use (or maybe even use a different library?). This obviously depends mostly on resource constraints considerations, and I'm not the best to judge this since I have not used MySensors extensively.
It is great to see effort being spent on trying to reduce the footprint, and as an experiment it makes sense to do this. Once we have seen how small it is possible to make it, then we can perhaps agree on what features we want (everything, or just the device interface, maybe with RHDatagram manager class (without acknowledgements)).
I'm holding back on developing any more this until we have reached some kind of consensus since I do not really have time to play around too much without being a relatively sure that the results will be useful.
-
@Yveaux said:
So, anyone still developing on RadioHead integration, or did all of you just give up? ;-)
no progress on my end - but that's rather related to the fact that this was my first week back in the office after vacation...
I think we should do one thing first: decouple the "network layer" from the "application layer" in MySensors:
- not having MySensors derived from RF24
- have a "generic" interface between MySensors and the radio
That way it would be rather easy to make use of other radios and other network topologies - could be RH or something else. I've taken a shot at that (a lot of this based on what Kolaf and Yveaux did adjusting MySensors to RH) and will provide a link once it compiles and is tested and I hope I can keep the overhead small enough to be acceptable for the gained flexibility.
@ToSa said:
I think we should do one thing first: decouple the "network layer" from the "application layer" in MySensors:
- not having MySensors derived from RF24
- have a "generic" interface between MySensors and the radio
Initial version - tested with a simple DallasTemperatureSensor setup successfully here
Note that this fork/branch does not include the "1.4 update 1" changes for nodeID / CRLF.Overhead is limited (~150b flash / ~20b ram):
Sketch uses 20,426 bytes (66%) of program storage space. Maximum is 30,720 bytes.
Global variables use 575 bytes (28%) of dynamic memory, leaving 1,473 bytes for local variables. Maximum is 2,048 bytes.
