Node to node communnication in v2.0 between repeater nodes

[Jeff]

Re: Node to Node communication

I know there is an old thread mentioning that we can send node to node message directly in the MySensors network.
I've been trying since yesterday to send a message directly between 2 nodes but I had no success.

I am logging everything I receive in the "receive()" method and I don't see any extra message coming form the other node.
I have set the destination to be the node ID I want to send to (I confirmed the nodeID by logging it in the receiver to be sure I did not make a mistake). Here is how I send the message in the sending node:
send(msgCustom.setSensor(64).set(0.121, 3).setDestination(8));
I am expecting to receive the float value 0.121 directly in the receiving node (node ID == 8 ) in the receive() method, or at least to see an extra message, but I don't see anything.

My 2 nodes have the repeater feature enabled and are never sleeping and always powered on and processing messages all the time.
My network has been up and running since almost 2 years now and I am currently running on mysensors version 2.0
I also have MY_RF24_ENABLE_ENCRYPTION turned on and this has been working well since I upgraded to version 2 this summer.
Overall my network only has 5 nodes + 1 gateway node that are all set as repeater (again, they never sleep), with some extra nodes that are normally turned off and not set as repeater.

Is the node to node communication still working properly in version 2.0 (note: I never tried it in previous versions)? Are there any caveat? Is there a recent example that is available?
I tried with many different message types, but I don't think it should matter at this point. Right now I am using V_CUSTOM. I also tried to present this child ID as S_CUSTOM but I am not too sure the presentation is required in this case as it is meant as an internal communication between 2 nodes.

Any help or additional information would be appreciated.

Jeff

[Boots33]

@Jeff I have used node to node on V2 mysensors. Have a look at this thread

I am only toggling switches though but would think it should be the same for other data types

[Jeff]

Thank you @Boots33 for referring me to your project, it confirms at least that node to node communication works in version 2.

I looked at your code and the way you send to the other node in your remote code is not so different from what I do at high level. The main difference is that your remote does not seem to do the sketch presentation to the gateway. In my case both sensor nodes have many other child IDs and need to be registered with the gateway, at this point I am not sure if that makes any difference.
When I get more time I'll try to do another sensor that does not register with the gateway to see if I can get this to work by simplifying the whole proof of concept until it works. Of course this would be only to troubleshoot the issue because I need to register my other sensors with the gateway in my final solution.

What I am understanding so far is that it should work, and the fact that 2 sensors are registered to the gateway and act as repeater should not matter for node to node communication to work. This is mainly what I wanted to confirm.

[Jeff]

I just did a different test, I looked at the source code of the mysensors project, and also noticed an error message when I was trying to send the message as if it can't be sent (!TSP:MSG:SEND)
I then decided to do a test and call transportSendWrite(0,msgTempDiff.setSensor(64).set(0.121, 3).setDestination(8)) instead of send() to see if I can force it to be routed through the node 0 (I understand this forces it to be routed trough the gateway), and this worked, I can now receive the message in the other node (ID 8 )

My assumption at this point is that the normal send method is not able to route the message properly to the destination node. I also think I shouldn't be calling transportSendWrite as it seems more like an internal method, but for now this is more for testing and troubleshooting the issue.

Overall, it still doesn't work using the normal send method and I wouldn't want to use that internal method since I am not too such of the implications of calling it directly and if I am assuming anything with node 0 being always able to route the message (and this internal method may stop working in future versions)

[tekka]

@Jeff Can you post a full debug log with both sending methods?

[Jeff]

I will work on that tonight when I come back from work to see what I can do to get this info.
I may not be able to log it from the sending node, I will have to reverse the scenario (which also have the same issue), because I can't enable logging on my real sending node since it is already using a lot of memory and just enabling MY_DEBUG cause it to not work properly. So I will try to enable log and send from my receiving node.

Thanks,
Jeff

[Jeff]

Here is a log using the normal send (in this case I am sending from node id 8 to node id 1):

Starting repeater (RNNRA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=8)
TSM:FPAR
TSP:MSG:SEND 8-8-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-8 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=8)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-8 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=11,pt=0,l=19,sg=0,ft=0,st=ok:sensor
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:4.0
TSP:MSG:SEND 8-8-0-0 s=1,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=5,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=64,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=ok:
NODE:!REG
NODE:!REG
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 8-8-0-0 s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
TSP:MSG:READ 0-0-8 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
TSP:MSG:READ 0-0-8 s=255,c=3,t=6,pt=0,l=1,sg=0:M
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=11,pt=0,l=19,sg=0,ft=0,st=ok:sensor
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:4.0
TSP:MSG:SEND 8-8-0-0 s=1,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=5,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=64,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=ok:
Request registration...
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2
TSP:MSG:READ 0-0-8 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=8, parent=0, distance=1, registration=1
TSP:MSG:SEND 8-8-0-0 s=5,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=ok:10
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.229
TSP:MSG:READ 2-2-0 s=1,c=1,t=0,pt=7,l=5,sg=0:21.4
TSP:MSG:REL MSG
TSP:MSG:SEND 2-8-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:21.4
TSP:MSG:READ 2-2-0 s=0,c=1,t=1,pt=7,l=5,sg=0:21.3
TSP:MSG:REL MSG
TSP:MSG:SEND 2-8-0-0 s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:21.3
TSP:MSG:SEND 8-8-0-0 s=5,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=ok:20
!TSP:MSG:SEND 8-8-7-1 s=64,c=1,t=48,pt=7,l=5,sg=0,ft=0,st=fail:0.121
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.233
TSP:MSG:READ 2-2-0 s=1,c=1,t=0,pt=7,l=5,sg=0:21.5
TSP:MSG:REL MSG
TSP:MSG:SEND 2-8-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:21.5
TSP:MSG:READ 2-2-0 s=0,c=1,t=1,pt=7,l=5,sg=0:21.5
TSP:MSG:REL MSG
TSP:MSG:SEND 2-8-0-0 s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:21.5
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.238
TSP:MSG:READ 2-2-0 s=1,c=1,t=0,pt=7,l=5,sg=0:21.4
TSP:MSG:REL MSG
TSP:MSG:SEND 2-8-0-0 s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=ok:21.4
TSP:MSG:READ 2-2-0 s=0,c=1,t=1,pt=7,l=5,sg=0:21.1
TSP:MSG:REL MSG
TSP:MSG:SEND 2-8-0-0 s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=ok:21.1
TSP:SANCHK:OK
TSP:MSG:SEND 8-8-0-0 s=5,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=ok:20
!TSP:MSG:SEND 8-8-7-1 s=64,c=1,t=48,pt=7,l=5,sg=0,ft=0,st=fail:0.121

And here is how it looks using transportSendWrite to node 0:

Starting repeater (RNNRA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=8)
TSM:FPAR
TSP:MSG:SEND 8-8-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 8-8-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-8 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.271
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=8)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-8 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=11,pt=0,l=19,sg=0,ft=0,st=ok:sensor
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:4.0
TSP:MSG:SEND 8-8-0-0 s=1,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=5,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=64,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=ok:
NODE:!REG
NODE:!REG
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 8-8-0-0 s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
TSP:MSG:READ 0-0-8 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
TSP:MSG:READ 0-0-8 s=255,c=3,t=6,pt=0,l=1,sg=0:M
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=11,pt=0,l=19,sg=0,ft=0,st=ok:sensor
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:4.0
TSP:MSG:SEND 8-8-0-0 s=1,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=5,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 8-8-0-0 s=64,c=0,t=23,pt=0,l=0,sg=0,ft=0,st=ok:
Request registration...
TSP:MSG:SEND 8-8-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2
TSP:MSG:READ 0-0-8 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=8, parent=0, distance=1, registration=1
TSP:MSG:SEND 8-8-0-0 s=5,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=ok:10
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.271
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.271
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.271
TSP:MSG:SEND 8-8-0-0 s=5,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=ok:27
TSP:MSG:SEND 0-8-0-1 s=64,c=0,t=48,pt=7,l=5,sg=0,ft=0,st=ok:0.121
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.271
TSP:MSG:READ 0-0-8 s=64,c=0,t=48,pt=7,l=5,sg=0:0.271
TSP:SANCHK:OK
TSP:MSG:SEND 8-8-0-0 s=5,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=ok:27
TSP:MSG:SEND 0-8-0-1 s=64,c=0,t=48,pt=7,l=5,sg=0,ft=0,st=ok:0.121

The message was sent twice in both cases. You can see that it fail using the send method.

[tekka]

@Jeff Your node (8) is defined as repeater with an invalid entry in the routing table:

!TSP:MSG:SEND 8-8-7-1 s=64,c=1,t=48,pt=7,l=5,sg=0,ft=0,st=fail:0.121

Node 1 is accessed via (a non-present/inactive) node 7, hence TX fails. Try clearing the routing table information / eeprom - this will force the message to be routed via the GW (until the routing table is updated correctly).

[Jeff]

Thanks for the response. The node ID 7 exists in my network, it is a temperature sensor, always on / not sleeping. Maybe it is too far to be reached.
I thought the routing was more dynamic than that, and if a node can't be reached using the current routes it will try to determine a new route. I guess I was wrong in my assumption.
Is there an easy way to clear only the routing part of the eeprom? I have other settings that i don't want to clear stored in eeprom. Also, maybe I will implement an automatic mechanism that clears the routing table if there are too many failure.

[mfalkvidd]

@Jeff the cleareeprom sketch only clears addresses up to (excluding) the local config, so the area where custom config is stored is not affected.