Please provide a log during startup so I can see what is happening.
I’m a bit confused by this to say the least 
. How does this become YYYYYYYY?
Possibly - the logfile will help work out what’s up - hopefully 
No problem, I’ve created a ticket and uploaded on your website.
is the redacted network ID from the device, is it a hex number in the logging and files.
Thanks,
Steve.
Ah, ok, understood (although I don’t know why you think you need to do this - it’s not secret and is not secured at all in the network). At least it explains it though…
I would suggest to remove the XML files from these devices, as well as the XML from the controller, and restart to see if that fixes things. Maybe the controller XML has become corrupted (maybe have a look at it before you remove it - or send it over on the ticket).
I had a quick look at it and it does not look obviously wrong. I’ve added it to the ticket.
Thanks for the tip about Network ID not needing to be secret.
Thanks,
Steve.
Agreed - it looks ok. I’m not sure what’s caused this then, but I guess at some stage the home ID got itself screwed up. I don’t know why this would cause the exception you’re seeing, and in any case, if the network is currently returning the correct home id, then these files iwth the 0000002 in the name shouldn’t be being loaded (although the log above does cast some doubt on that!).
I’d delete the file, restart, and if you’re still seeing these “Serializing to file /var/lib/openhab2/zwave/network_00000002__node_55” messages, then send the log and I’ll try and work out why.
I can confirm that sometimes the binding produces such 0000002 numbers in xml files when including new devices. This happened a couple of times to me in the last weeks. But fortunately the binding will also produce correct xml files (whith the real network number) after a restart. However I think that this is not expected behaviour and rather a bug.
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.