Error sending switch command, check device/hardware !
-
I put together another node exactly the same but keeping it at my workbench roughly the same distance from the gateway. It works without any troubles so far. The only change in the sketch is the node id and no ds18b20 temperature reading.
The log from myscontroller show that it works even if the node doesn't send back the same status as the command. Domoticz doesn't complain as it does with the first node. This behaviour was last night.Now this morning the replys from the new nodes is also present. They weren't last night. At least not in the logs from MYScontroller.
When domoticz sends a switchcommand to the gateway it does so with with ACK flag set. Does mysensors library automatically reply?
I haven't programmed in a replyfunction in my sketch so it seems like it. But in that case why doesn't my first node reply every time?Strange. Have to investigate this further.
-
Having checked the serial output from the new node at my computer I see that the library returns the command when a ACK i requested. I also looked in the sourcecode for the library and it seems that it handles the ackmessage.
So it seems that the ACK message get missed in the recieving node. Why, is the next question.Investigation continues...
-
I put together another node exactly the same but keeping it at my workbench roughly the same distance from the gateway. It works without any troubles so far. The only change in the sketch is the node id and no ds18b20 temperature reading.
The log from myscontroller show that it works even if the node doesn't send back the same status as the command. Domoticz doesn't complain as it does with the first node. This behaviour was last night.Now this morning the replys from the new nodes is also present. They weren't last night. At least not in the logs from MYScontroller.
When domoticz sends a switchcommand to the gateway it does so with with ACK flag set. Does mysensors library automatically reply?
I haven't programmed in a replyfunction in my sketch so it seems like it. But in that case why doesn't my first node reply every time?Strange. Have to investigate this further.
-
... why doesn't my first node reply every time?
My guess is that it does reply every time. But the message gets lost along the way. The most common reason is power problems on the sending node.
@mfalkvidd After Little more investigating and experimenting I am pretty sure I have found a bug in the library. I found that when debug is active all is working as expected. But if I commented out debug it starts to not work. I tried it about 10 times, once with debug and then without. And everytime debug is active it works, no debug it fails.
I opened the transport sourcefile and added a delay(100) at the procedure where the debug message is sent. With that change it works everytime with or without debug. It seems that if the ackmessage is sent to quick it gets missed by the gateway. Any thoughts on this? -
-
We just discussed this in the core team. Unless it is a compiler problem (like the other one we experienced some time ago) the most probably cause is..
- Radio problems. Could be bad really bad clone, or that radio doesn't have time to "recharge" enough between transmissions.
- Slow node, Fast Gw => GW sends response and node isn't in RX mode yet. But this is also quite strange as GW retransmits 15x with a 1.5ms delay before failing.
-
I've experienced a similar problem when testing OTA updates on SensebenderMicro. With debug active, no missed messages, with debug disabled, a lot of missed messages and retries. It was a really obvious difference, since the rate of messages during OTA updates is quite fast. Gateway was an UNO and radios were clones.
-
@kk02067 , Would you please post specifically where you added the delay(100). I have exactly the same problem as you and would like to be sure the ack gets back to the controller. Thank you!
In other tests and explorations I had noticed that with debug enabled things seemed to work a bit more consistently - but had not tied it to this problem. Unfortunately, debug sacrifices quite a bit of flash which I need for other uses.
-
@kk02067 , Would you please post specifically where you added the delay(100). I have exactly the same problem as you and would like to be sure the ack gets back to the controller. Thank you!
In other tests and explorations I had noticed that with debug enabled things seemed to work a bit more consistently - but had not tied it to this problem. Unfortunately, debug sacrifices quite a bit of flash which I need for other uses.
@novicit If I remember correctly i put it here: https://github.com/mysensors/MySensors/blob/master/core/MyTransport.cpp#L463
just to test that it worked. Then I removed the change to keep the library source original.I turned on debug again to get it working again.. The reason why I wanted to have debuging disabled was to keep the hexfile size down so the OTA update wouldn't take so long time. I hope this issue will be fixed in a more elegant manner in a future release.
-
Update. Please note that when @kk02067 gave the response directly above it was for Ver 2.0 and referenced a line in that code. It appears that changes leading to Ver 2.1.1 the location has changed and the delay(100) line would not be added at L463 as referenced. In Ver 2.1.1 it is now added between L659 and L660. It will look like this I believe:
L658 _msgTmp.destination = sender;
L659 // send ACK, use transportSendRoute since ACK reply is not internal, i.e. if !transportOK do not reply
ADD delay(100) here!!
L660 (void)transportSendRoute(_msgTmp);Also, I have not yet used Ver 2.1.1, so don't know if the changes in the latest version might solve the Domoticz relay ack issue I had. This solution solved my problems 100% in Ver 2.0.
