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?
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).
Z-way server works without this drain issue and proper wakeups, device lost no battery during night.
Moving back to openhab2 and will check behaviour
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?
It is also that Danfoss was new at Z wave that period (2012) and therefore issues can be
I will attach a log on What is Z-way updates.
But I suspect one of the details was the Clock.
This is one of the transactions with z-way https://pastebin.com/mw3CpSPk
And a second one https://pastebin.com/gBNUG6dt
Putting the Device on openhab server it began after a while to perform the same dancing!
Can it be that device needs an Clock update or a scheduling setting to be set once a while to keep it sane?
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?
That will not be easy from danfoss, as not easy to also find their contact . I will try the generic ones.
I will also try to find from Z-wave.me or Zipato a debug log of Commands sent on every execution to compare them (would that help?)
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.