Switches do not work anymore after upgrade to 3586

[joshimosh]

Hi,
after an upgrade to V2.3586 my switches not not operate. I get the message that I should check the hardware. The protocol says: MySensors: Light command received for unknown node_id: 27, child_id: 7
Of course there are no changes to my hardware. Sensors attached to that node are working well.
Please advise.

Is there a way to fall back to a previous version of Domoticz, which is known to work ? I can backup the database. Would it be sufficient to copy the domoticz directory completely and copy it back in case of problems ?
Thanks a lot
Josh

[gizmocuz]

It seems your node does not response to an ACK request
please update to the latest version, and disable ACK for this node, see also topic:
viewtopic.php?f=42&t=8792

[joshimosh]

Thank you very much for your fast response !
Although I welcome the possibility to have ACKs (makes it more reliable), it would take some time to implement ACK on all my 16 nodes.
The possibility to enable/disable ACKs per node is *very* welcome, thank you.

Will test it within the next few hours and report back.

Again, thank you so much for providing information so fast.
Cheers
Josh

[joshimosh]

In addition to my previous mail: I noticed that the field where you can chose whether ACK is enabled or not does not show in my firefox browser (actual version).
But in Chrome it worked


Cheers
Josh

[joshimosh]

Update:
I have upgraded to V.3589
I have disbled ACKs on the "offending" node (node 27)
I did a restart of Domoticz
I still get the same errormessage: "MySensors: Light command received for unknown node_id: 27, child_id: 7"

What now ?
Please advise. Thanks a lot in advance
Josh

[gizmocuz]

i think this all was not related to ACK.
The error came out of domoticz, because it did not receive the node/child yet, which is logical at startup,
you do not want to unplug/replug all your switch nodes
Just made a new beta version #3590, that now also loads the childs, that should hopefully solve this problem.

If it does, please enable ack, and tell if this works good, as you really want to have this on to make sure the command is received

[joshimosh]

Thank you, that did it !

My nodes so far do not react on ACK. My think is/was, that the protocol between the nRF24L01+ devices is good enough to recover at least from spurious loss of packets. There is a bulit-in retry (up to 15 times) if packet are not acked by the receiving nRF24. The acks and retransmissions are fully done by the nRF24s themselves, so this is not an additional load for the Arduino running the MySensors sketch.

But sure, you can be never safe enough - belt *and* suspenders

So yes, I will enable ACks in my nodes one by one, but this will take some time. I will try it first in a sort of fake node to check my ACK code and them incorporate it in the other nodes.

Again, thank you so much for providing me with fixes.
Have a nice weekend
Josh

[gizmocuz]

hi josh,
thanks for the feedback, the ACK is done between the gateway and the node, and is not related to a sketch
so it should just work....
i just received another confirmation that the previous patch works, and also ACK mode works

[gizmocuz]

another confirmation when using ACK:

"I unplug my test sensor and when I try to switch it on I got an error, once reconnect it work "

[joshimosh]

Ah, that was a misunderstanding on my side. I tought that you referred to the the ACKs between gateway and node. For those you have to provide code for ACK in the nodes.

I just switched ACK on for one of my switches, used it and ... it worked !!!

Very good, thanks a bunch !!!!!!!

Cheers
Josh

[joshimosh]

Update:
Switches and sensors seem to work with ACK (I have not checked them all, but quite a few of them), but my switch for my blinds (S_COVER) does not work with ACK. I do not get an entry in the protocal, but a pup-up errormessage saying:
Fehler beim Senden des Schaltbefehl, Gerät/Hardware überprüfen ! <- meaning Error during sending of switch command, check device/hardware. When ACK is disabled for this device, everything is fine.
I can live with ACK switched off for this device, but perhaps this is helpful for you.

Cheers
Josh

[NewFolk]

Ah, that was a misunderstanding on my side. I tought that you referred to the the ACKs between gateway and node. For those you have to provide code for ACK in the nodes.

Cheers
Josh

ACK is built in function of mysensors lib. You should not do anything in you sketch code.

[gizmocuz]

Update:
Switches and sensors seem to work with ACK (I have not checked them all, but quite a few of them), but my switch for my blinds (S_COVER) does not work with ACK. I do not get an entry in the protocal, but a pup-up errormessage saying:
Fehler beim Senden des Schaltbefehl, Gerät/Hardware überprüfen ! <- meaning Error during sending of switch command, check device/hardware. When ACK is disabled for this device, everything is fine.
I can live with ACK switched off for this device, but perhaps this is helpful for you.

Cheers
Josh

I dont know why this happens, but it should not.
You are running 1.5 or 1.6 correct?
Glad it is working with ACK turned off, .... but it should not

[joshimosh]

@gizmocuz:
Yes, I am running on 1.5.
I will try to collect more information and be back to you if I find something.

@NewFolk:
my understanding of the ACK mecahnism in the mysensors protocol was, that you can request ack messages from the destination node (as stated in the description of the API). In incoming messages, you have a getter for the ack-flag (bool isAck()). I think that it does not make sense to ask for an ack and then not to react when (after some time) there is no ack. And to react on missing acks is something you need to write code for. You could - for example - try a retransmit if there was no ack after (say) two seconds. In my view, this is a bit of overkill, since the nRF24 offer the possibilty to have ack (and retransmits) between any two nRF24s in case of checksum errors or complete packet losses. AFAIK this option is switched on in the setup of mysensors library - it would be stupid not make use of it.
You can argue that a node or/and the controller can miss a packet which has been alredy acked on the lower level - agreed. But then it only makes sense if you do something about it -> additional code -> see my previous argumentation.

So, in all my nodes I am using for sending data the default: no ack requested.

@gizmocuz:
Could this be a potential source of problems, that all my nodes do not request ACK when sending data to the controller ? But since this is the default, many others besides me should stumble over the same problem ...

Cheers
Josh

[joshimosh]

@gizmocuz:
One of my node is a pulsecounter connected to my gasmeter. My heating runs on gas. The node sends the number of pulses from the meter during the last five minutes - always, even if there was no chnage, in particular if the flame in the heater has been turned off and gas consumption is zero. This allows me to calculate and display the gas flow (which for me is much more interesting than the meter count).

I noticed that with ACK turned on for this sensor, it happens that there are missing entries of this node in my log. With ACK turned off, I see entries exactly every five minutes.

My suspicion is, that there is an issue with sensor values which are the same as the previous value. Could that be the source of the problem ?

Josh

[joshimosh]

@gizmocuz:
an additional hint that sending a message with the same value is dropped when ACK is turned on:
I have a sensor for temperature and humidity connected to a mysensors node. The sensor is a DHT-22, which is known for not being overly accurate. This results in temperature readings which vary by approx. 0.1 degree per reading. I am rounding the humidity reading to a full percent, so there is less variation.

With ACK turned off for this sensor, I see two entries in the protocol every five minutes (this is my perferred interval ):

2015-11-15 06:37:28.405 (ProMini GW) Temp + Humidity (Basement)
2015-11-15 06:37:28.904 (ProMini GW) Temp + Humidity (Basement)

With ACK turned on, I see from time to time only one reading in the protocol. In the device tab I can see that there are values for temp and humidity.
I have checked, that in case of only one entrty in the protocol, there was no variation of the value for humidity, only for temp.

May I ask you what your motivationwas to introduce an additional ACK (on top of the ACK/retransmit feature between the nRF24s ? What kind of action does Domoticz perform when it does not see an ACK ? Would be interesting to know ...

Anyway, I hope that this littel piece of information can help.

Again, thanks a lot for all your efforts you put into Domoticz. We all appreciate it.

All the best
Josh

[gizmocuz]

Hi Josh,

The ACK is only used for SET commands, and is not related to your temp sensor (unless you send this value with ACK to the gateway/controller, but i would not do this)
We use the native ACK implementation from MySensors, so when setting a switch to On/Off we can send it with ACK, meaning, the gateway and your node, will handle this stuff, you dont have to do anything for it

So it is from gateway -> (to) node, not for the other way around

[joshimosh]

Hi Gizmocuz,
thank you for the information provided. It is always good to understand what is going on.
What I do not (yet) understand is the behaviour in case that sensor values are sent, which have not changed. At the time being, it does not bother me, because I have switched off ACK for all sensors which send data like temperature, humidity etc to Domoticz. For switches, ACK is on - with the exception of S_COVER.

Thank you for this piece of information. Domoticz rocks

Cheers
Josh

[malarcy]

That's an interesting observation regarding nodes with ACK not updating when a SET with the same value is sent. I have been looking at a very similar issue - and had not made the connection between ACK and "ignored updates to same state"

]https://www.domoticz.com/forum/viewtop ... =42&t=9272


In my case I am looking to raise some kind of alert when I haven't heard from a particular sensor for a period of time - and I wasn't seeing the last see time updating when the node sent a message that "repeated" current state - I have modded the mysensors domoticz library to remove the "has it changed" check to get the behaviour I want, it's not ideal and there are probably knock on effects.

If this turns out to be a bug or a feature of the ACK implementation then I can look to remove my mod and work around by turning ACK off for the nodes I want to check on (seems illogical) but at least I won't have to keep changing the source when I update the install.

Would be interested to know if this is an expected outcome of the ACK processing - or an accidental change.

[malarcy]

Just retested with my "fix" backed out - ACK doesn't make any difference to the effect I am seeing - I am going to raise a bug ticket and then the dev's can confirm how things are supposed to work.