I'm trying to work out if a change between ver 1.5 and 2.0 is deliberate.
The case is a node sending a message that requires signing, but signing failed (e.g. nonce timeout).
In previous versions (1.5) , this would result in the send function returning false.
In the current dev branch, this results in signerSignMsg returning false, but the message itself can be sent and return "st=ok", e.g.:

send: 4-4-97-0 s=4,c=3,t=16,pt=0,l=0,sg=0,st=ok:
Nonce requested from 0. Waiting...
Message to send could not be signed!
sign fail
send: 4-4-97-0 s=4,c=2,t=36,pt=0,l=0,sg=0,st=ok:

So the send function returns true, even though the gateway will discard the message (presumably).

I seem to have lots of radio issues, so I want my nodes to repeat status updates until the send is confirmed.

I guess my question is this: should the send function (transportSendWrite) be changed so that if signing fails, the send fails, or should I go about this differently (e.g. using ack's, or testing with mGetSigned)?

p.s. I'm fairly new to the forum, and github, so I'm not sure where the best place to post this is - let me know if it's not appropriate here.

This thread has been great - thanks @mfalkvidd!

@hayduke I had a similar problem earlier. I haven't fixed it yet, but here's where I'm at:

Clean install (Jessie, RF24, Raspberry) March 25th 2016 has the problem where it works for a few minutes, then stops (/dev/pts/0 dissapears, which breaks the symbolic links - ttyMySensorsGateway and ttyUSB20). This is at home where I have a bunch of nodes around and a Vera with serial gateway, so there are lots of different signals coming in.

But when I move to another location with just one node (that just sends a light status update regularly), it works fine - at least, I've been sitting here with it running for 30 minutes so far.

I know this might not help much, I'm new to all this and still getting my head around everything. I would probably agree with what you suggested earlier: something in one of the messages that causes a problem with the gateway (possibly to do with already having another serial gateway nearby).

I'll try to do some more testing by changing this gateway to a different channel to my other one, and gradually bringing nodes across to see when it breaks.

I just found the discussion on reliable delivery , which clears up some things.
I believe the v2.0 send function returns "hop-to-hop" acknowledgment - i.e. if the message got delivered to the next node.
Therefore I should use software ack's from the gateway to confirm message delivery, though it appears to be an ongoing discussion.
There's still the question of how signing fits in, but it's not so relevant to my case anymore - regardless of whether it fails because of signing or something else, the result will be no ack from the gateway.

I'm trying to work out if a change between ver 1.5 and 2.0 is deliberate.
The case is a node sending a message that requires signing, but signing failed (e.g. nonce timeout).
In previous versions (1.5) , this would result in the send function returning false.
In the current dev branch, this results in signerSignMsg returning false, but the message itself can be sent and return "st=ok", e.g.:

send: 4-4-97-0 s=4,c=3,t=16,pt=0,l=0,sg=0,st=ok:
Nonce requested from 0. Waiting...
Message to send could not be signed!
sign fail
send: 4-4-97-0 s=4,c=2,t=36,pt=0,l=0,sg=0,st=ok:

So the send function returns true, even though the gateway will discard the message (presumably).

I seem to have lots of radio issues, so I want my nodes to repeat status updates until the send is confirmed.

I guess my question is this: should the send function (transportSendWrite) be changed so that if signing fails, the send fails, or should I go about this differently (e.g. using ack's, or testing with mGetSigned)?

p.s. I'm fairly new to the forum, and github, so I'm not sure where the best place to post this is - let me know if it's not appropriate here.

@alexsh1 No actually. I didn't want to go around and reprogram all my nodes, and I forgot to turn off my other gateway. That is what I was going to do next, but I've just been running it for a few hours with no problems (with a heap of nodes and another gateway a few metres away, all on the same channel).

I then Home Assistant and tested out a few nodes, and now it sometimes breaks, but mostly works fine.

All that being said, I've realised I need signing (I have a few electronic locks), so I'm going back to a hardware serial gateway. If anyone has got signing working I'd love to hear how - I had a look but couldn't figure it out and don't have much time to spare on it.

This thread has been great - thanks @mfalkvidd!

@hayduke I had a similar problem earlier. I haven't fixed it yet, but here's where I'm at:

Clean install (Jessie, RF24, Raspberry) March 25th 2016 has the problem where it works for a few minutes, then stops (/dev/pts/0 dissapears, which breaks the symbolic links - ttyMySensorsGateway and ttyUSB20). This is at home where I have a bunch of nodes around and a Vera with serial gateway, so there are lots of different signals coming in.

But when I move to another location with just one node (that just sends a light status update regularly), it works fine - at least, I've been sitting here with it running for 30 minutes so far.

I know this might not help much, I'm new to all this and still getting my head around everything. I would probably agree with what you suggested earlier: something in one of the messages that causes a problem with the gateway (possibly to do with already having another serial gateway nearby).

I'll try to do some more testing by changing this gateway to a different channel to my other one, and gradually bringing nodes across to see when it breaks.