Node to node communication fails if gateway is not reachable

[Heizelmann]

Re: Node to node communnication in v2.0 between repeater nodes

In relation to this older post I have a sceneraio where node to node communication stops working. I have two nodes, a sensor and a repeater/actuator combination and a gateway. As long as the gateway is present to all nodes a direct communication between the sensor and the repeater/actuator works. On the sensor the log shows

MSG:SEND,44-44-43-43,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=1,st=OK:1

and on the repeater/actuator

TSF:MSG:READ,44-44-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1

But if the gateway is not reachable (tested by simply switiching it off) the message delivery is unreliable. Mostly on sensor side the log shows NACK instead of OK

!TSF:MSG:SEND,44-44-43-43,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=2,st=NACK: 

On the receiver side (the repeater/actuator node) a lot of logs are seen for finding the gateway, I think this correct. But the receive function is not called.

...
TSF:MSG:SEND,43-43-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
!TSM:FPAR:NO REPLY
TSM:FPAR
TSF:MSG:SEND,43-43-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
!TSM:FPAR:FAIL
TSM:FAIL:CNT=7
TSM:FAIL:PDT
...
TSF:MSG:READ,44-44-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
...

[Boots33]

@Heizelmann This post will give you some info

[mfalkvidd]

Hi.

As described on https://www.mysensors.org/about/network the MySensors network topology is a tree, with the gateway at the root. All messages go through the gateway, so if the gateway is turned off the nodes will start searching for a new way to the root, which will fail since there is no root.

It is possible to hard-code parent node. I am not sure if it helps in your case, but it might be something to experiment with.

Or start with troubleshooting why your gateway is turned off. Maybe it needs to be fixed?

This discussion on gateway redundancy might be useful
https://forum.mysensors.org/topic/5690/multiple-gateways-for-redundancy

[Heizelmann]

@mfalkvidd said in Node to node communication fails if gateway is not reachable:

All messages go through the gateway, so if the gateway is turned off the nodes will start searching for a new way to the root, which will fail since there is no root.

In the post refered from @Boots33 stands something diffrent:

@napo7: So, when I send a message with anything but 0 as destination, it goes thru the gateway, and the gateway rewrites a new message with the same destination ?
@hek: No, it might never reach the gateway. For instance if a repeater on the way routes knows the destination, it will route it.
Only repeaters and gateway holds a routing table which is build dynamically from the traffic the "see". So they are the only ones that can send messages "downward" in the sensor network.

What is right and more important what can I do to solve my problem? The receiving message is seen in the log of the repeater but is not processed.

[hek]

Disable the transport check on the repeater.

#define MY_TRANSPORT_WAIT_READY_MS 1

[Heizelmann]

@hek I already did this, but with 3000ms. Changed to 1ms but without success.

[Heizelmann]

I do not much understand the serial protocoll, but as far as I can see the leaf sends a ping to the repeater, but not the message I defined.

TSF:MSG:READ,44-44-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1

See my other logs in the previous post.

[mfalkvidd]

@Heizelmann the log parser can be used to make the log easier to read, like this

[Heizelmann]

@mfalkvidd Thanks for this hint! @hek I like it!

[Heizelmann]

Still unclear for me? Is it possible or not to have a node to node communication via a repeater without gateway online?
If not I would suggest to put an issue on github. If yes, it would be nice to have a clear instruction how to do this.

[Heizelmann]

Added an issue for this on https://github.com/mysensors/MySensors/issues/792

[DavidZH]

@Heizelmann The nodes are unreachable in that situation because the radio is powered down for a set amount of time before a new attempt to establish a connection is done. When you try to send something from a node, that radio will wake up. The receiving node on the other hand will be powered down so it will not do anything.

Depending on the radio you use, a solution for the RFM69 might be to engage the listen mode. It uses just a bit more energy as power down, but it can generate an interrupt on the node to wake it up and receive the message. I'm not sure if this function is available in the library as of yet, but I know it's in the works.

[Heizelmann]

@DavidZH Can not confirm this. Messages from sending node reaches repeater but not handled because the repeater finds no gateway.

[Heizelmann]

Still need this ️. I heard of some low level communication. Might this be a solution? I am not en expert. Would be kind if someone can give an instruction.

[berkseo]

@heizelmann
This problem is solved ...completely, independence and autonomy if the gateway is not available. Return to standard mode if the gateway is online again.
Watch video - https://www.youtube.com/watch?v=x1oNCO0TXG8&t=126s

On the channel there are other videos that explain the principle. I about six months ago did topics here for discussion, but it is interesting to nobody.

[gohan]

@berkseo it could be that not many people are using node to node communications. Good job you found a way

[berkseo]

@gohan Perhaps not many people think about it ...first. But this is before the first fall of the gateway when the power supply is interrupted or when the processing of messages in the network is overloaded. The more responsible nodes in the network, the more obvious the problem. And how these problems are solved by an ordinary user??? HE GOES OUT FROM MYSENSORS. If we start to trust the important work of the mysensors network, there should be a guarantee that there will be no problems. So there are two big things for me that I think are missing in mysensors:

1.Possibility of direct radio communication between network nodes. Now I change the parent ID for this on the fly, it provides communication both with the gateway and between nodes directly. It makes no sense to use a gasket when you need to pass a command or data from node A to node B.

2.Autonomy, full, flexible. There is a gateway available, we work through the gateway. There is no working gateway - work without a gateway. There is a gateway in the network again - work with him again. Passive mode can not provide this.

Perhaps not giving stability to the network is the policy of the founding fathers, then it's sad, wouldn't want to if it was.

[scalz]

@berkseo
there are valid and nonvalid points in what you're saying. The valid point is self healing isn't (never) finished and I agree with you it is an important feature.

1. e.g. I saw your mysensors hack code a while ago. i didn't look at your video etc but just thought "got it", then end of a todo.
   (I've no falling gw, nor messages overload. my gw is enough powerful and autorestart.). Gw could fail but a node, or a repeater on border of network could fail too.

2. Is your implementation bullet-proof vs all cases?? if there is repeater with node in routing table in between. moving nodes. etc. Not a problem when people live in apartment and don't need big range, with no repeater.
   Remember, mysensors isn't a mesh with all the self healing. It's a classic star topology network for the moment, where repeater's role is to forward a msg (not the node's role).

We can't give guarantee! Except saying we do our best in our free time. MySensors is open source, and community driven as possible. Zigbee users etc can also have their issues. That said MySensors is opensource, we can guarantee reactivity when community wants to help

1. "not giving stability in the network" isn't the policy of the team (i guess you know it).

As you can imagine, it's also often more fun to work on new innovative things (like new framework and hw, smarter stuff etc) than maintenance
And it's not easy to follow all posts, piece of code/hacks, videos, adding them to a dev todolist etc.

The easiest way if you want the feature implemented is as you know, please:

• open an issue on gitub
• or create a PR
  then that will be checked if the addition is valid and complete. At least there will be history for the next mysensors rev.

And as you're using internal mysensors vars and functions, this will prevent you to lose your work during mysensors updates.

From someone smart: "if all the great critics would only contribute 1% of code - we would have solved lots of issues"

[Heizelmann]

Sorry, but this is too much complicated discussion for me. Is it possible or not with the current version for end users like me? If yes, I need a simple how to example.

[mfalkvidd]

@heizelmann I think all you need to do is follow @berkseo's video guides.

[scalz]

for info, thanks to @tekka, he prepared a PR to address node to node communication, and make you happy
https://github.com/mysensors/MySensors/pull/1174

So

• you can try berkseo implementation but like I said above, maybe it will be broken in future, who knows.. as it's using internal mysensors api (not the end user api).
• or try tekka work and feedback (from a end user point of view, you just have to add same changes in your files as those this PR) https://github.com/mysensors/MySensors/pull/1174/files

Btw, not sure if it will work with signing (whitelisting etc), and if not, not sure when.. but plz feedback!

[Heizelmann]

@scalz Thanks for the info. I do not understand much of the software, but I would prefer the second solution as far as it will be integrated in the release. Using an internal API is unacceptable.
But what about the case that the gateway is not reachable and the direct node also but a repeater inbetween could serve it?

[berkseo]

@scalz
The thing is, I don't change anything in the library, I just use some things from there. In theory, this should not change. But I agree that this is not quite reliable, as it can be renamed. BUT.. I did this when I first came out 2.0, now 2.3.1 and still it works. I use two things. On-the-fly spoofing parentID and a feature with a set of parameters that does roughly the same thing as a passive node, but all the proof-of-delivery work. This works like this: if the gateway is OK then work through it, if there is a problem with the gateway then the nodes work directly. If the gateway is back online then the nodes build a new route and work again through the gateway. Your previous posts have brought me to new thoughts. Because my solution works very well in a direct exchange between two nodes. Now I want to expand the functionality and make such a transition from node to node and worked through repeaters. @tekka solution is good, but not sufficient.

And most likely I will recommend the сreator of this theme to use your solution if it suits him. My research is rather experimental, this is what I would like to see in mysensors. But studying my experiments, I think, will be useful, because it works ... work well.

[scalz]

@berkseo
as OP asked for a end user solution, I can't give a better answer than what I already said.
I didn't say you changed lib nor it doesn't work (in all cases, with signing etc?).
and as you noticed, it works in 2.x. Maybe things will be different for 3.x in future, in case transport layer etc is revamped..

But most important is to use what fit your needs. and of course then to be able to maintain it in long term. less easy for endusers with less programming skills.
Anyway thx for sharing.

@Heizelmann
if node2node not in range, it should try to find a parent I think. but then i've not tested.

[Heizelmann]

My scenario is as follows: A sensor node should report directly to a actuator node wether the gatway or any repeater are on or off. Both nodes should communicate bidirectonal to the gateway if available some different messages. Can anyone give me as an end user a simple example code for the both nodes?

[mfalkvidd]

@heizelmann while it is a valid use case, it is not how MySensors was designed. MySensors uses a tree topology, and if the root of the tree (=the gateway) is gone, there is no way to route the messages.

Supporting the use case would be nice, but changing the topology will require a lot of work deep inside the MySensors library.

[gohan]

@heizelmann have you tried to use it normally in order to check the long term stability before going trough all that trouble?

[Heizelmann]

For me, node to node communication is a must have for a reliable secure home automation system. E.g. if a PIR sensor node detects motion, a lamp actuator on a different place should switch on the lamp quickly even if the gateway is off. May be mySensors is the wrong choice for this domain.

[berkseo]

@heizelmann said in Node to node communication fails if gateway is not reachable:

May be mySensors is the wrong choice for this domain.

This is not so, you are in the right place :), do not leave here, this project has excellent prospects. Mysensors is still evolving, who knows what awaits us in version 3.0 for example. For me, uninterrupted communication between nodes is as important as it is for you. This is a fundamentally important thing that should be. For myself, I decided it, respectively, and for you it is also solved.

[JeeLet]

the Node To Node must be seen as a Gateway to node
the controller is not mandatory.
so we rethink the topology.

Gateway (node0) <---> Node1 <---> Node2 <---> 3.. 4...

The Gateway in 2022/2023 must be used, how to do!!?!! ...... a Node Useful

(yes an old message, but to refresh the ideas )

happy holidays to you all