I´m using RPi3 OH 2.1.0 Snapshot & raZberry GPIO Card
Since yesterday almost everything went well. Today I had to switch down the main power of my house as I did some installation stuff.
In the evening I recognized the rollershutter did not go down.
In the Paper UI the ZWave Board and all ZWave Things were lost… So I added the Board again to /dev/ttyS0 and all Things were recognized immediately, but the address changed.
in by rules file there are all zwave Things named like this
I’m having the same issue on an Intel NUC, so it is not RaZberry related.
It’s happened to me before and I went and did manually a global substitution in the configuration database.
But it’s rather painful, especially if the address may change randomly on a power outage.
This is an old thread, but since it’s not isolated, can anyone help? @chris ? Any guidance on this? How can we avoid such changes?
Chris, it is not a port/device issue.
The same device, the same /dev/ttyACM0 but it will come up as a zstick with an id " 49627221 " and then after shutting down openhab2, unplugging the device, re-plugging it in, it is not being recognized the same way. I have to add it again and it comes up with a different id (bbf23b76)
This throws off the whole ‘thing’ and ‘item’ configuration where every device refers to the original number.
Though the “Office Ceiling Light” item is listed, it does not appear to be effective.
The log after trying to change its value says:
2018-11-17 14:30:54.857 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key _tags:Office_Dimmer in ManagedMetadataProviderImpl, because it does not exists.
As I said, I’m not familiar with this code. If you can take a look it would be useful. If you can’t, then I will try and find some time, but it won’t be for a while as I’m tied up at the moment on some other issues.
I tried to restart from a fresh state, removing all json data and all zwave data.
Now Zwave sees all the devices but none of them are getting their configuration.
Paper UI says of the ones I’ve added “This device has not been fully discovered by the binding.”
I’m lost!
It seems you are mixing up issues - I thought that the problem was the controller changing serial ports?
With such little information, it’s hard to comment, but normally the device needs to be woken up so it can be interrogated by the binding so the binding can discover the device type and services etc.
First of all we need to clarify what type of USB dongle Michel is using. You are not using a Razberry board, right? The USB discovery participant is not configured to detect this type of board, so it shouldn’t be any problem with it. Is it an Aeon Z-Stick Gen 5 device?
The code that defines the Thing ID is the following one:
private ThingUID createSerialControllerThingType(UsbSerialDeviceInformation deviceInformation) {
if (deviceInformation.getSerialNumber() != null) {
return new ThingUID(CONTROLLER_SERIAL, deviceInformation.getSerialNumber());
} else {
return new ThingUID(CONTROLLER_SERIAL, String.valueOf(deviceInformation.getProductId()));
}
}
The SerialNumber of each device should be unique, but I think that the linux driver used for Z-Wave USB sticks doesn’t provide this information, so we are in the “else” part of the code. AFAIK, the productID also shouldn’t change between restarts, so I’m not sure what is going on here. Today I’m busy, but tomorrow morning I will have a look at it and make some tests. Ideally we should use the Z-Wave network ID as the Thing ID (that will solve all our problems), but I know that chris doesn’t like this option because reading the network ID involves making a serial connection with the device and that can interference with an already made connection
I don’t agree it will solve all problems - it will generate different problems as it requires to attempt to open the serial port to read data from the device that it’s found. This will likely create a race condition with different instances trying to open the port and it will prevent the binding opening the port if the discovery is also trying to read at the same time.
Hi @chris, I cannot check with the zwave binding as I only use ZigBee, but a couple of considerations that might help here, as something similar (not necessarily the same thing, anyway) happened to me with the ZigBee binding after a power failure.
In my case I saw that the zigbee state XML file had been corrupted (zero-size) after the power failure. When I look at the code, I see updating the file is not atomic, so if a power failure (or a crash for whatever reason) happens while the file is being updated, all network state info (including the saved bridge info) is lost.
So my understanding is that, after such failure and rebooting, the device is seen as something new by the binding, and assigned a new id.
Having a look at the zwave code, it looks like network serialization takes a similar approach (maybe with a file per node?)
To improve stability, I would suggest to do network serialization (both in ZigBee and here) in two steps: save the new state to a temporary file on the same path, and then replace (atomic move) the old file with the new one.
ZigBee and ZWave are very different in the way that this works - not just the serialisation function itself (which I agree is similar), but also what happens if there is a problem reading the file back. In ZWave, this makes no practical difference as the data will be re-read quite easily. This is not necessarily the case for ZigBee.
The atomic move suggestion might be useful for ZigBee especially where there is more impact if this file is lost as the data is not easily availble in the controller as it is in ZWave.
In any case, for the dongle, this is not relevant as it’s not used when doing dongle discovery in ZWave or ZigBee.
My dongle is an Aeon Z-Stick Gen 5 indeed.
I understand Chris’ point of view. But I have another suggestion:
How about using symbolic names (variable like objects) in the description of things and items?
i.e. instead of having
Ummmm… after having a look at it, I think that @FunMiles problem is not related to the USB discovery service. The ThingID that the autodiscovery service sets to the Thing is, as you can see in the previously provided code, the same as the productID of the USB device. And for Z-Wave Plus sticks this is 512 (0x0200 in hexadecimal). This number doesn’t match with any of the ids provided by Michel, so I’m not sure how that can be related to USB discovery.
What selects the “thing ID” when adding a zwave stick in paper UI?
When you add a new Thing from Paper UI, the ThingID is automatically set (randomly) by the framework, but you can change it in the “Z-Wave Serial Controller” creation page just before approving the creation of the Thing.
How about using symbolic names (variable like objects) in the description of things and items?
AFAIK, the framework doesn’t allow dynamic Thing ID definitions based on variable definition.
The problem is: why are you creating a new controller thing after shutting down openHAB and re-plugging the usb device? What do you mean with “it is not being recognized the same way”?
I’ll start by answering your last question. After shutting down OpenHAB, then unplugging the device, pairing with new devices, re-plugging the usb device and starting OH again, it sometimes does not recover the existing USB setting for some reason. Now, I am not 100% sure why that is, but I found some rogue process that could have been stepping on the feet of OH when accessing the device (/dev/ttyACM0). Given that I’ve gotten rid of that process and that it is not something I can re-produce, unless you have some idea of something to do before the next time I re-plug in the device, trying to discuss that part is in my view futile that I discuss further that aspect.
However, given that the stick did not appear anymore, I tried to get it back. And there, I may have made a mistake, i.e. create a new stick rather than go back to the original thing and make it bind to the stick afresh…
In any case, I started the PaperUI interface to add a stick and it does pick a random ID. In fact, it has to be random, since it is done before even telling it which port to use. I tried to change that ID to the old one, but that didn’t work.
Eventually I cleared up everything, backed up my files, uninstalled OH, upgraded linux, re-installed OH, started afresh with the things, and eventually could add back the items, using my original .items file after substituting the new ID for every occurrence of the old one.
As for my id of a symbolic name/variable, I was not assuming it was currently allowed in the framework, but it might be something worth considering in adding to the framework. Such a feature could have other broader beneficial impacts.
After shutting down OpenHAB, then unplugging the device, pairing with new devices, re-plugging the usb device and starting OH again, it sometimes does not recover the existing USB setting for some reason.
Have you checked if, in those cases, the port of the USB device has changed? In Linux, if you unplug and re-plug a USB device, it’s very common to see that the OS gives the device a new port: from /dev/ttyACM0 to /dev/ttyACM1. As the Z-Wave thing is configured to listen on /dev/ttyACM0, it won’t recognize the new /dev/ttyAMC1 device and your Z-Wave network won’t work. You have three solutions:
Instead of restarting openHAB, reboot your whole device everytime you disconnect the USB controller. On a clean restart, the controller will always get the /dev/ttyACM0 port.
In Paper UI -> Configuration -> Things -> Z-Wave controller -> Edit button (Pencil) -> Serial Port -> “/dev/ttyAMC1”. But this won’t work for long, because next time the controller will get the “/dev/ttyACM0” port and you will have to change it again.
You should never delete and create a new Z-Wave controller thing, because, as you have seen, the individual Z-Wave nodes are linked to the controller through the thing id. Let’s see if any of the proposed solutions works for you. The simplest one is the first one, but the best solution is the last one. If you have any problem, don’t hesitate to ask
