Star vs mesh topology

[gandalph]

Hi
I have a feature request I'd like to discuss, as I am not sure how to approach this. The mysensors implementation uses a mesh topology to make sure the messages land at the gateway, via multiple pathways, whereas the current implementation of computourist gateway/node RFM69(H)W is a star topology. This means that when there is no point to point conncction with the gateway the info gets lost. Of course the chip RFM96HW (which I use) is very powerful, which makes it a good candidate to use it in both wide areas and (heavily) concreted areas as well.

The question I'd like to pose: is is possible to; with limited effort; re-enigneer the current node/gateway to a mesh topology to increase message reception probability?

some considerations:
- battery powered nodes are sleeping and therefore not able to participate in the mesh
- current implementation is already bi-directional and able to receive commands, reception of a struct could trigger repeating the same struct as is?
- should the nodes be put in promiscuous mode?
- how to deal with the reception of multiples of the same message via different nodes by the gateway

looking forward to your suggestions!

cheers

[computourist]

Hi gandalph ,

Interesting idea, but also very complex. Every node would need some routing mechanisme, duplicate message prevention, maybe queueing and a lot more.
It would be good to first think on the functionality you would want; all cpu-power and memory needed for the mesh network functions would be lost to end node -sensor- functions. Given the limited resources of the Arduino chip this is a serious limitation.

Another option to consider would be using multiple gateways. This leads to a multiple-star topology. The gateway acts as a standard MQTT client to the broker and nothing keeps you from connecting multiple gateways. Each gateway could have a separate network number. The topic naming scheme used allows the root of the MQTT-topic to be different for each gateway (i.e. /home/rfm_gwA, /home/rfm_gwB, etc). The MQTT-broker would deliver all messages to the proper Openhab destination.

This setup would be static (not dynamically adjusting to circumstances like a mesh network) but for the majority of purposes it would be adequate.
It sure is a lot easier to implement

A last option would be to use multiple gateways within the same radio network. If the link to an end node is lost another gateway would take over.
For transmission to the node Openhab could decide which gateway to use, based on error messages received. Reception of end node messages would mostty be in multiples. With proper programming Openhab should be able to cope with that..... This setup is dynamic in nature and has the benefit that no extra code is needed on the end nodes.

[papa]

Unless one gateway / network gets overwhelmed, the current approach seems good to me. Even then if the one gateway is overwhelmed, then setting up another parallel network to connect thru a new gateway makes sense. Likewise increasing the times between end node's data transmissions could dial down the attention they need from a gateway.

I'd need to see more on what benefits would be gained via the possibly big effort in reprogramming.

[gandalph]

The upside of the mesh would be that for a node cluster in a more remote area the farthest node would still be able to get the data to the gateway via the closest node in the cluster. As Computourist states, this can also be achieved by introducing another gateway, which then would need ethernet access to connect to the bus. A local relay is also a way to solve this, however adjustments to the gateway still are mandated to avoid double messages, and then there's the queue, when a node is sending it cannot receive. This is why I like the resilience the mesh offers, but yes that requires quite some scarce mem space on the arduino nodes.

I don't have an actual need for this functionality (yet;-) )But my farthest node is stretching it in terms of reception. Maybe I'll take a look at the mysensor implementation and offer further thoughts.

Thanks for your inputs!


edit: mysensors actually has a "tree" topology, like the one I describe above with local repeaters, and very cool pathway seeking... fyi: www.mysensors.org/about/network

[papa]

Back when in this thread, we discussed using more than one Gateway & RFM69 network to spread the communication load & extend the capability of this DIY Home Automation project. However, until lately I had not seen or tried to work out all needed to have more than one Gateway/RFM69 network connected to the same MQTT server & OpenHAB UI.

I just figured that out & posted the documentation in the thread Using More Than One Gateway/RFM69 Network

[papa]

Part of the desire for adding a mesh topology was the case of nodes having trouble communicating reliably with a Gateway because of distance or obstacles.

One way to address this is adding another RFM69 Gateway that is closer to the struggling node.

        This need not be an Ethernet Gateway. It can be a WiFI ESP32 Gateway.

Another way to address this is using an ESP32 RFM95 Gateway & Nodes in order to get better communication with more distant locations.

Perhaps one wants to "communicate" between nodes. For example, if Node 10 senses a certain temperature, then have Node 17 turn on a fan.

    In such a case, we can make a rule in openHAB that accomplishes this.