I can’t really see how this is linked to the device loosing its key. The error is in the binding - the device is still sending encrypted data, and if it had a corrupted key, it would just not decrypt, but wouldn’t throw this error.
My guess is that the binding initialisation is corrupt as the report here seems to be that the key in the binding is null, or not initialised in some way.
In my case, the other secure devices still worked. Which reminded me of this occurring with a NGD00Z garage door opener too, but that was after an accidental reinitialization. I had about 5 devices completely drop off the network after reincluding locks the last time they lost their keys. I haven’t had much time to play with Z-Wave lately… but I am due for a network rebuild. Sorry for the lack of empirical data.
Ok, but the keys are initialised separately for each device, so the fact that they work for some and not others doesn’t mean that it’s not the binding. The error is definitely coming from the binding, and I think the null in the error probably points to an initialisation error.
If it happens again, then I’d like to see the binding initialisation to see if there are any errors during the key initialisation.
Yes, coming from 2.3 stable, and the device has just been deleted and then readded in the 2.4 upgrade process, so I don’t know of anything else that has changed than the binding. Do the log messages point anywhere, or should I gather more?
Here is the log of the binding initialization (I’ve just quickly removed lots of lines containing nodes other than 2 and 16 that are the one that does not work).
I’m using encryption for many other items and they work correctly.The problem seems to be bound only to the binding and these two special devices (Aeotec Walmote Quad).
01: Sensor type
02: Precision / Scale / Size
02 = Precision=0, Scale=0, Size=2
072C: Value = 1836
Because Precision = 0, there is no scaling performed - I guess that this should be 18.36 with a precision of 2, but the data received doesn’t define this. The binding can’t easily know this - I guess it could perform some sort of trending on the data and learn what is correct, but I think that’s a little out of scope
Hello Chris, thanks a lot for the super fast answer.
I have checked in traces and there are other spontaneous reports from this device with the right value, precision etc… with the right processing by the binding as per traces below.
This would lead to the conclusion that the device is sending “randomly” a badly formatted message?
Or, the other difference could be that in the first case, the initial message contains both battery and setpoint values and the second (where there is no problem) contains only the setpoint value?
Yes, this is likely - or the message is corrupted when sent which is also possible as ZWave does not use a very strong error detection system by default.
I’m not sure I follow your point? I think that in all cases I saw, the messages are separate - the setpoint is always sent by itself.
Whereas I am sure that the device was included with security enabled.
Shortly after that it comes to the “REQUEST NIF” state and does not advance any more. Could it be related to that, making the binding not decoding the encrypted messages because it thinks security is not used ?
Ok, understood, I have to say that I don’t distinguish very well between the messages, and in the first trace I posted, the processing of battery level & setpoint are very near each other and almost interleaved.
Going back tothe first block of traces, this would be
And this one would be the setpoint info, which seems to have arrived before the entire processing of the battery info was completed…
Since I did not have this problem when using my super old Zibase and associated openHab binding with this device, I’m not sure I’ll be able to ask the vendor for support, so I guess I’m going to have to filter those “erratic” values (and very temporary as well, because after few seconds there is another message with the right value…
The concrete issue for me is that temperature graphs are “a bit” distorted by the 2000°C reported, even if for a short period of time, so basically I guess I’ll have to filter those values and ensure that they are not saved in database and don’t trigger the various alerts…
The first one is the battery level and the second one is the setpoint.
Maybe this device had filtering for such events?
I understand. I could add some filtering, but it’s very complex to get right, and IMHO is something that is not ZWave specific. If someone wants to add such filtering, it would probably be good to add it to the core instead so it is resolved on all bindings.
Apologies if this was already covered (I did search, but it’s a long thread) but I have tried to follow the instructions, and kept my old controller. zwave:serial_zstick:157b8d41438 (Type=Bridge, Status=INITIALIZING, Label=Z-Wave Serial Controller, Bridge=null)
(I have a Zwave plus aeonlabs USB stick in a raspberry pi running the latest snapshot).
However when I look in PaperUI I see " ZWave Plus USB Dongle" and in the log I see:
2018-10-31 13:51:09.281 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:serial_zstick:512' to inbox.
I tried deleting my old controller, and adding this, but I wasn’t sure how to change the thing id using PaperUI (so I wouldn’t have to update my items files). So in the end I added azwave serial controller again using Habmin, with id=157b8d41438, but then I get back in the original situation: I have a serial controller, but PaperUI (and since I see it in the log, presumably openhab itself) wants me to add another dongle.
What am I missing?
Edit: hmm. This controller doesn’t seem to find any things:
zwave:serial_zstick:157b8d41438 (Type=Bridge, Status=INITIALIZING, Label=Z-Wave Serial Controller, Bridge=null)
Maybe I just need to give in and edit my items files…
There was new core functionality added to auto-detect USB devices. That’s what you’re seeing in the Inbox – the system auto-detecting the zwave USB stick. You can ignore the one that was auto-detected.