Absolutely - it’s a bug. If you have any logs it would be useful, but otherwise I will have a look at how the home id is inserted into the nodes during inclusion.
Thanks.
How long should initialisation take? Is it normal to still be seeing “Polling deferred until initialisation complete” messages after +12 hours?
It depends on the configuration of the device. If it’s a mains device, then it should be quick (normally seconds, but if there’s a lot happening during startup, then it can be more). Battery devices may take an hour or two maybe, but it depends on the wakeup period.
I’ve found the reason for the incorrect home ID and I’ll do an update today or tomorrow to resolve this.
2 Likes
I’ve just tried the updated binding and it is not creating the ‘00000002’ XML files. I’ve also just quickly tried similar checks to before where I securely included a node, restarted OH2 and was getting InvalidKeyException and this also looks to have been fixed. I’ll keep an eye on it and let you know if I see it again.
Thanks,
Steve.
1 Like
@ Chris:
I have a fresh install of openhab 2 with an aeon z-wave stick.
If i use the jar file from the first post and try to add the Z-Wave Serial Controller, i can’t save, if i click to “Show More”.
Do you know this issue?
See the screenshot.
There is a red line under the SUC setting - PaperUI wants you to select a value for this. I’m also not sure why node ID is 0 as this is also out of range…
If i write in the first red line Node ID “1”, the 0 from the Node ID under “Others” will disappear. So i have no possibilities to set a value. If i should test something, let me know. 
1 Like
Hi all,
I finally switched to DEV binding two days ago. Some of my devices work fine, but I have several issues with others. Nodes with issues described below.
Controller:
Aeon Labs Z-Stick Series 2
Generally works, but what is interesting, the only neighbour is node 3. It has been always like this, works (in general) well despite this fact. Node 3 is the only Aeon device in my network, is it possible the controller talks only to Aeon devices?
Node 13
Qubino ZMNHDA Flush Dimmer. Never had any problems with it, but on DEV binding it does not report state changes of binary sensor.
network_0184d835__node_13.xml (15.7 KB)
Node 14
Philio PAN04 In Wall Dual Relay. Does not report state and power/energy, but there was always problem with it. I don’t care.
Node 21
Qubino ZMNHDD Dimmer Plus. I think it worked well before, but on DEV binding it does not report state/energy/power.
network_0184d835__node_21.xml (33.9 KB)
Node 26
Qubino ZMNHBA 2 Relays. Worked well, but now it does not report state/power/energy.
network_0184d835__node_26.xml (15.4 KB)
Node 31
Qubino ZMNHDD Dimmer Plus. This is a new device I bought few days ago, but it seem the same like node 21. It has problems with initialisation, hangs on collecting endpoints, if I read the log correctly. Also for some reason it treats monostable button as bistable, even though in the configuration is set monostable. I excluded it with reset to factory setting, but no change.
This is my biggest problem right now. It somehow works - I can switch it on and off from OH, but does not report state/power/energy and does not report both binary sensors - which is very important to me.
I removed the thing, stopped the binding, set DEBUG logging level and started the binding to catch initialisation messages. Here is the log:
zz.zip.xml (338.0 KB)
Any help is much appreciated. I’d like to stick with DEV version, but need to solve all the issues.
No - the new version works exactly the same as the old - there is no change with the way the controller works, and if the Aeon controller only worked with Aeon devices, then surely this would have been an issue with the previous version?
These have been problematic with the associations. Your is a very old version (V1) which has been difficult to get working.
The dev binding uses the new implementation of the association configuration which is required for Qubino devices. Unfortunately there are many implementations in many different devices, and not all of them conform for the standard (and the V1 devices from Qubino fall in to that category). I’ve tested newer Qubino devices and tehy work fine, but I’m aware that some people are having are issues with reporting.
From what I saw recently, these devices don’t support associations properly - at least not on multichannel devices.
If other reports are working, then I would have expected energy reports to also work.
Same as above.
I’m not sure what’s going on with this device - as you saw, it is not responding to the multichannel request, which it should. I suspect that this is the issue with Qubino trying to be super smart and complicating things. They say they report multi_instance in the NIF, but I think they only enable multiple channels if there are multiple channels available (eg if the temp sensor is added). The binding tries to request the multi-channel data because the device is reporting multi channels in the NIF, and then it’s hung because the device is not responding 
.
Hi.
I’m trying to move my openhab over from one server to another. I simply copied over /var/lib/openhab2, /etc/openhab2 and /usr/share/openhab2/addons between the servers, but on the new server the controller never went online, it just says “Serial Error: Port {0} does not exist”. (more log below) The really strange thing is after I moved the controller back to the old server (which is in production and never had this problem before) I get the exact same error there. The controller is /dev/ttyUSB0 and I’m positive the openhab user has rw access to it. And openhab-transport-serial is installed. What else could be wrong?
The log says:
11:37:29.988 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zwave:serial_zstick:15f24d360d4' has been updated.
11:37:30.026 [INFO ] [ding.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyUSB0'
11:37:30.045 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:15f24d360d4' changed from OFFLINE (COMMUNICATION_ERROR): Serial Error: Port {0} does not exist to OFFLINE (BRIDGE_OFFLINE): Controller is offline
11:37:30.130 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:15f24d360d4' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to OFFLINE (COMMUNICATION_ERROR): Serial Error: Port {0} does not exist
And this is what it looks like in habmin:
Any idea what’s going on? What is {0}?
I’m running 2.2.0 stable with the latest version of the binding in this thread.
edit: Forgot to mention, of course I’ve been restarting the binding. Now I’ve also restarted entire openhab and even the entire server, seems to make no difference.
edit 2: Ok… After moving back the controller to my old server and restarting the binding AGAIN, suddenly things started working. So now at least I can put my lamps out tonight. Not really happy though since I still don’t understand what’s happening and thus can’t move to the new server. Is it my controller being flaky?
It has been always like this, even on OH1 version.
But it worked in the previous version. I am aware that many have change in the DEV binding, but is it a problem to get this device working as well? What does need to be done? I just want to be clear: state and power reports work, also when I press the button connected to binary sensor, the device sends report, but there’s no state change in bound item.
None of the reports is working, sorry for the confusion. This applies to Node 21, 26, 31. For 26 the device does send reports, but it seems the there is endpoint matching issue or something like this. Similar to node 13 and binary sensor. For 21 and 31 nothing in the logs when pressing buttons.
This seems to be identical device as Node 21, but I’ve enabled binary sensors and reincluded it to get them detected by the binding. After this button stopped working as monostable. However I just change the config to bistable and back to monostable and it started working again as monostable. But the endpoints issue is still there…
As I said, the Aeon device definitely works with devices that are not from Aeon.
As said - the new version uses the new concept for associations. This has to make decisions based on the command classes that are reported in the device. The old version was very simple and therefore didn’t work with many new devices that only support the new concept. These V1 devices aren’t compliant and do cause some problems.
Ok, then it will likely be related to the same issue above.
Just found a while to analyze the code. Decapsulating multiinstance code looks weird to me…
We have a notification:
2018-04-02 14:44:31.265 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 1A 06 60 06 02 25 03 FF 56
So this is:
2018-04-02 14:44:31.281 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=26, callback=0, payload=00 1A 06 60 06 02 25 03 FF
Which is sent from node 26 with multiinstance message: 60 06 02 25 03 FF
This is what we have in ZWaveCommandClassPayload as payload bytes.
Then the control goes to ZWaveNode.processCommand(60 06 02 25 03 FF): https://github.com/openhab/org.openhab.binding.zwave/blob/development/src/main/java/org/openhab/binding/zwave/internal/protocol/ZWaveNode.java#L1126
Here: https://github.com/openhab/org.openhab.binding.zwave/blob/development/src/main/java/org/openhab/binding/zwave/internal/protocol/ZWaveNode.java#L1203
we check payload.getCommandClassId() which takes byte nbr 0 of the payload -> 60 (COMMAND_CLASS_MULTI_CHANNEL)
and payload.getCommandClassCommand() which takes byte nbr 1 of the payload -> 06
Then we go into ‘if’ statement and here: https://github.com/openhab/org.openhab.binding.zwave/blob/development/src/main/java/org/openhab/binding/zwave/internal/protocol/ZWaveNode.java#L1219
we realize this is MULTI_INSTANCE_ENCAP
AND (!) we get instance number from byte nbr 1 (from which we were taking class command) -> 06.
Shouldn’t we take byte nbr 2 (02)? This is what I spotted just browsing sources, haven’t had time to debug this yet, but definitely will do.
Is this a bug or I am just missing something?
I will take a look - thanks (but this is not related to the issue where the device is not responding to the MC requests).
Strictly speaking, it’s a bug, but the code is not used so can be deleted. It will not change the operation of the binding at all since it is assigned to a value that is never used. Probably this was a line for debugging at some stage in the past…
I am talking about Node 13 and 26 issue, this log is for node 26.
Are you sure? Please take a closer look. There is another bug: endpoint number is assigned indeed to wrong variable, but the code is definitely used.
I just tested it and now - woohoo - reports are back for node 13 and 26. I am going to make a PR in a few minutes.
1 Like
I’m a bit confused what you’re talking about with this? What log are you talking about - your report above didn’t have a log 
.
Well, I just deleted the line and there were no errors as the variable is not used, so yes, I’m pretty sure.
Cool - I’ll be interested to see this 
.
No - it’s lost in this thread. It doesn’t seem to be related to security in any way is it? Maybe a separate thread would be better as we don’t need to discuss every zwave issue here 
.
I’m not really sure I can answer much though - probably something strange in the lower layers outside of the binding, but I don’t know.