It’s worth a try - it’s probably about the only thing you can do unfortunately.
This device worked perfectly with Zipato. I want to migrate to openhab, and trying to test before shutting down completely zipato.
I did remove it from zipato using the exclusion procedure, reset it (device) and use it here with openhab. Can some network interference causing this?
Now I did exclude it, hard reset it and joined it again.Lets see.
I’m not sure what you are suggesting can be done differently? We’ve spent time looking at the logs, and as you can see openHAB is not sending anything to the device to configure this. The device is setting its wakeup period to a value that is less that it allows even - I don’t know how openHAB can do this?
I’m open to suggestions as to what you think is wrong.
No - to me this must be an issue with the device. You could always try sending a command from OH to set the wakeup period to (say) 10 seconds and see what happens. My guess is it will either be ignored, or it will get set to 60 seconds if the device respects its own minimum value. If it doesn’t respect this, then possibly another device is setting the level (we know this is not being set by OH as we’ve looked through the logs).
I agree with both your replies. Let me rephrase.
Thoughts:
Can Zipato still have this node registered and cause this?
Can the device have a Firmware issue! from the past, and other companies like Zipato/ Fibaro which device worked with without this strange behaviour, did overcome it by setting the wakeup interval?
Because If i change the wakeup value, while device is constantly waking… stops waking like crazy for at least an hour.
No - it shouldn’t be possible. The network ID (HomeID) should be different, so it shouldn’t be possible. But… Clearly something that shouldn’t be possible is happening 
…
You are suggesting that the device has a problem, but Zipato have a workaround to periodically reset the wakeup? Yes, this could be possible (not sure how to confirm it though).
I suspect because of the device behaviour. That something resets on these devices. As these devices If i remember well before the new LC-13 thermostats, have had strange issues.
i can join another Old danfoss and check if it is having simillar issues, if so! then it is something wrong on the firmware of these waiting for the Wakeup Interval to be refreshed.
As both would be working on previous Z-wave Hubs. Going silent to test.
Either way if this is an issue, I cannot afford batteries every 2 days. Though I want to get rid of Zipato.
I think I found the issue.
The Polling value of the device before inclusion was 86400.
2018-10-28 07:57:10.616 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling…
2018-10-28 07:57:10.618 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling zwave:device:1668227521b:node2:thermostat_setpoint_heating
2018-10-28 07:57:10.625 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling skipped for zwave:device:1668227521b:node2:thermostat_setpoint_heating on COMMAND_CLASS_BASIC
2018-10-28 07:57:10.627 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling zwave:device:1668227521b:node2:battery-level
2018-10-28 07:57:14.236 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling intialised at 86400 seconds - start in 175 milliseconds.
AFter inclusion it is 1800 (30 minutes). This
2018-10-28 14:10:08.255 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling…
2018-10-28 14:10:08.258 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:1668227521b:node3:thermostat_setpoint_heating
2018-10-28 14:10:08.268 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling skipped for zwave:device:1668227521b:node3:thermostat_setpoint_heating on COMMAND_CLASS_BASIC
2018-10-28 14:10:08.270 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:1668227521b:node3:battery-level
Constant Awake is the Panic mode behaviour (found some opsts from another forum back from 2015.
Can this polling causing the panic mode due to the high value of it?
As the device now runs really without issues the last two hours!
I’m not sure - this isn’t a standard mode in ZWave, and I therefore don’t know how it works (ie what logic Danfoss have implemented to perform this function).
I saw default polling on Web interface is 1 day! and when I saved it it switched from 1800 (device) to 86400 (web int).
I will put it at 4 hours! if this happens again… then we know the issue!
Same issue exists, Will begin trials with another device of the same type.
If this happens also with another device of the same model. then something is really wrong.
Second device LC12 the same issue. Draining also like crazy.
For sure something is not reported on the logs or makes the device go on a mode which on other z-wave softwre seem not to happen. it is clearly not the hardware, as both devices do that.
Is there any possibility to debug more about what happens?
Also can it be an issue of Razzberry2 on my PI that makes the device waking?
I don’t think so. Already, every frame that is sent and received by the binding are logged, so I’m not sure what else can be logged, or how any data can not be reported.
I can’t see how. The device only interacts via the RF interfaces - there’s no other interface. This means that by logging the data that we send and receive, we have a full view of all interactions with the device that come from openhab.
I am surprised that all devices do this though as other people use these devices without such problems where the device is waking up every 8 seconds. Maybe there’s something else happening from other controllers?
You mean like Zipato? As I properly excluded/deleted the nodes from it.
For instance.
I’m not sure what is happening. All we can see is what the binding is sending, and there is nothing there. We also know that others don’t have this issue with the 8 second wakeup, so if you have 3 devices all doing this, then we need to look at what else can cause this.
I agree that in general I would not have expected something else like another controller to cause this, but unless I’m missing something, it’s not the binding sending something to do this.
can it be an old nearby device which was routing signal?
the other controller for some reason creates the “confusion” ?
Also found from the past this:
Finally, I disable the climate schedule and clock command classes which have
been reported elsewhere to be unstable (although this is apparently not
strictly necessary for correct operation with the THERMOSTAT_SETPOINT command
class, so you may want to ignore that part).
Can this be something causing it?
About the controller I began a network heal on my other network. still getting these random issues with the second device too.
First time laster 5 minutes, second is on 10+ minutes and still going crazy!
If I set a point or update some parameter I suspect it will stop
I saw this on the log:
2018-10-28 22:09:59.840 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 6: Thermostat Setpoint report Scale = 0
2018-10-28 22:09:59.841 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 6: Thermostat Setpoint Value = 2E+1
2018-10-28 22:09:59.843 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 6: Thermostat Setpoint Report, Type Heating (1), value = 20
Generally, I would think no, but at the moment clearly there is an unexplained issue, so I can’t be sure.
I don’t think so. This is about setpoint references, and is just an update to the OZW database. We know that the binding isn’t sending anything to the device to get it into this state.
I’m not sure what your point is? This looks ok to me, but I guess that you see a problem with this report and that’s why you are pointing it out?
the 2E+1 was strange but means 20.
I installed Z-way server and stopped openhub. Zway reported device was not interviewed completely (I suspect the non Controller registration, aka server.
I want to see what battery drain I have there.
As with OpenHab2 and the new Z-wave binding it was about 5%/hour.
Yes - this is just how Java prints it without formatting, but it is correct.
What does that mean? The interview is not related to the controller - it’s only in the binding, and I guess ZWay also does one, but there is no link between the binding and ZWay server. Presumably if it’s reporting that the interview is not complete, it is only talking about itself, and this is not linked to the binding at all. There is no state that is saved anywhere (well, the binding does save state in an XML, but the ZWay server doesn’t know that).
You are checking the issue with the 8 second wakeup I thought?
I am trying to pinpoint if the issue is interfierence when using another software outside openhab.
Then I will move back to openhab 2.3 and test again.
Do you find it a good idea?
Yes, it’s fine. I was just wondering if you were looking to see if the problem with the 8 second message repeat was also happening on all 3 devices on the different server?