I have included only one device on the setup for this. I finished also network heal of my Zipato network. In Netherlands is already cold and I cannot stay without heating.
Plan:
Stop Openhab2 and use Z-way server to check if the device behaves the same. I also enabled debug log for Z-way server. I also installed the software of zwave.me for first time on my RaspberryPI. I do not know if drivers included.
Stop Z-way and start again Openhab2 and check behaviour.
Exclude device / Downgrade from 2.4.0M4 to 2.3.0 (stable) and do the test again.
Install AEONTEC Z-stick and repeat the above (will be here on tuesday).
If you can work out what is different, I’ll be happy to look at it, but so far from what I’ve seen, OH is not sending anything abnormal to put the device into this mode.
Maybe the device automatically does this if it doesn’t receive some sort of message within some time - this would be very non-standard behaviour, although given Danfoss have their own software, maybe they don’t care too much for the standards here?
Previous post has the debug part of Z-way, pretty small… I think some commands mentioned there.
Also While the device is on endless loop (8sec) wakes. If I change the wakeup interval from 300 to 301… it stops./
Therefore some of the commands/info send to the device everytime it wakes fixes the loop. Like setting a time/clock or setting the interval on every wake.
Possibly - I’m not sure as there’s no documentation as far as I’m aware on what this requires to keep itself happy.
It’s a lot of guesswork here and it would be good to find out properly - ie get a statement from the manufacturer of the device as to how to use their device. Maybe you can contact Danfoss to get a statement from them on what needs to be done?
Maybe, but they should have a user manual that says how to use their product. If I look at products like Fibaro or Aeon, they have such a thing. Given that this device seems to require very specific functions to make it work, I would think that it should be documented somewhere?
Yes, we can try and reverse engineer, but it would be much better to actually know what is needed. We’ve tried this in the past, and clearly have not been successful and it takes a lot of time to do.
I am now testing with 2.3.0 Version of Z wave binding. if this is stable, will it help to find the differences? Because I saw no crazy issues for the last two hours with it.
There should not be any difference, but if you can find the difference, then please let me know. My guess at the moment is that this is related to a high level issue - eg not sending some sort of command such as time. However, that’s a guess, and if it is the case, then 2.3 will be the same.
I think this must just be down to your configuration - the binding doesn’t do this itself. If you have channels configured, and polling enabled, then these GET requests will be sent - it should be the same on 2.3 and 2.4.
I just added the device on Channels as it was not on any channel. It is stable for 3 hours on 2.3.
If it stays stable after adding channels… I think of moving to a clean 2.4.0M4 install and try again.
I have setup a fresh install and hard reset controller and the danfoss… now letting it work for a bit at 2.3.0
I kept debug log from the beginning which start with the inclusion. and next is to reset and setup the 2.4.0M4 again from scratch.