Concept: Proxy Node: multi protocol proxy
-
Hi everyone.
The last couple of days I've been thinking in a new concept for our nodes that would enhance flexibility of our networks.
Nowadays we have Gateways and Nodes. The nodes sends messages by air(nrf24l01/RFM69/RFM65) or by wire(RS485) to the gateway and the gateways then translates those messages into another protocol understood by the controller, could be wifi, ethernet, serial.
The proxy gateway/node concept is based upon the idea of having a gateway talking two different languages, as it does now, but choosing what it talks way down (downlink) the network and way up (uplink) to the main gateway.
Nothing better to comprehend and idea than an image:
In the previous figure, the Proxy node would behave as a nrf24l01 gateway with nodes in its daughter network talking RS485. It would be the gateway of its own daughter network.
The idea came up while designing a network where it would have many nodes very close to each other and it seemed overkill having each node with its own wireless link. I believe a better it's better having just one node talking wirelessly to the gateway and all the others piggybacking in a rs485 bus. For example, a huge three piece window with motorized internal blinds and motorized rollershutters on the outside. This setup would need 6 rollershutter nodes, with 6 RF links. Having just on RF link with a RS485 bus for the rest 5 child nodes seems better.
I believe this concept enables unlimited network expansion without physical nor transport layer limitations.
Let me know what you think about it, and if you feel it's doable.
Regards.
-
it has already been discussed as somebody else asked for a RS485 <-> NRF24 bridge. In addition at the moment the only OTA updates supported are through nrf24 and rfm69
-
@gonzalonal it seems like it is doable, especially the case you layed out, the proxy would just take any packets from the rs485 side and transmit them over radio. It would have to remember which nodes it has on rs485 so it can take messages to the nodes and send them on the wire. No changes to the gateway needed. Literally just a bridge. If there were any radio nodes down stream from the proxy, that might be trouble.
Of course you can get fancy and have buffering, proxying acks and nacks etc.
This might actually be a benefit in an all rs485 network, by having 2 separate busses with a small bit of buffering the concern over collisions could just about be eliminated.
-
https://forum.mysensors.org/topic/5455/bridge-between-rf24-and-rs485
If will be very complex to route data over different network types with a certain reliability, because when traffic increases you will inevitably get collisions, retransmissions and you could get to a point where everything becomes unusable.
-
Hi @gohan . Thanks for showing interest on the topic.
It's sure a hard thing to accomplish, but keeping in mind that daughter networks should be kept as small as possible (around 3~5 nodes) and that, for instance, nrf24l01 has its own fifo buffer, and atmegas has it's own uart buffer (for RS485 example) I believe it would be posible. Maybe creating a software fifo queue.
I know we are very hardware limited, but as hardware evolves, this may become a easily doable task. Not sure if it's doable in a atmega328p but for sure in the newer SAMD platform.
Let me know what you think.
Regards!
-
The problem with this protocol is that is not connected, sensor sends data and it is not waiting for an ack before sending something else. That would lead to congestion when traffic starts to rise and eventually to packet loss (it happens all the time on the Internet but you don't notice it because the tcp-ip protocol takes care of resending lost packets)
-
Hi @gohan.
Yes I know about protocols, I'm a teco engineer.
That same congestion you talk about, is already present in the current networks we are building. So, I don't believe it's a real limitation.There are critical task in home automation that needs messages confirmation or to resend (as TCP does), but there are many more, the vast majority, that doesn't need confirmation. Who would bother to lose a humidity reading.
-
Agreed, but if you have actuators for heating, watering, open close window blinds, light, whatever else, you would like them to work no matter what, especially if they are operated from remote or automatically and you can't get visual confirmation
-
I think most of the problems could be overcome, but they will take time and effort, which would take away from other projects unless a volunteer comes forward. Im not ready for something like this yet, so I should propbably keep my mouth shut.
-
Right, since this is community driven project it is difficult to put all that effort into it given that developers have their lives like everybody else
-
Hi @gohan
@gonzalonal said in Concept: Proxy Node: multi protocol proxy:
Hi @gohan.
Yes I know about protocols, I'm a teco engineer.
That same congestion you talk about, is already present in the current networks we are building. So, I don't believe it's a real limitation.There are critical task in home automation that needs messages confirmation or to resend (as TCP does), but there are many more, the vast majority, that doesn't need confirmation. Who would bother to lose a humidity reading.
Offcourse. We agree. Those mode critical messages/commands should be send with the ack bit enabled so as to receive delivery confirmation, and if not, to resend.
@wallyllama said in Concept: Proxy Node: multi protocol proxy:
I think most of the problems could be overcome, but they will take time and effort, which would take away from other projects unless a volunteer comes forward. Im not ready for something like this yet, so I should propbably keep my mouth shut.
@gohan said in Concept: Proxy Node: multi protocol proxy:
Right, since this is community driven project it is difficult to put all that effort into it given that developers have their lives like everybody else
Again, we agree. It's just a concept that I would like to share. Nothing else. We all have many things to do in life and in MySensors as well
, but I believe talking about this kind of things, slowly builds the idea in our heads, and may be prone to guide the platform development into it or some other great ideas.What today seems overkill or impossible, tomorrow we'll see.
Thanks for your comments.
-
Let's see what @hek might have to say about this
