Database messed up?

Not sure what happened today, but something went wrong when I tried to add a zwave node.
When I re-insert my USB Stick GEN5, I restart my server each time. Reason herefor is that /dev/ttyACMx changes each time. And after the reboot, it’s back to 0 (and 1 since I use 2 sticks).
Normally this isn’t a problem, but today, the paperUI found almost all my zwave node back in the inbox. I added them once more in things part. When I looked in the things, I had now 2 devices, one offline and one online. I’ve removed the nodes that were offline. But it looks that now, nothing works anymore regarding zwave nodes. So I guess I’ve done something wrong with this.

Any idea/suggestion what I can do to resolve it?

==> logs/events.log <==
2016-10-16 19:50:42.393 [ItemStateChangedEvent     ] - Sch_Lichtzuil changed from 70 to 82
2016-10-16 19:50:42.594 [ItemCommandEvent          ] - Item 'Sch_Lichtzuil' received command 82

==> logs/openhab.log <==
2016-10-16 19:50:42.594 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate command '82' for item 'Sch_Lichtzuil' to handler for channel 'zwave:device:1578e7a83ee:node53:switch_dimmer', because no thing with the UID 'zwave:device:1578e7a83ee:node53' could be found.
2016-10-16 19:50:42.595 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update '82' for item 'Sch_Lichtzuil' to handler for channel 'zwave:device:1578e7a83ee:node53:switch_dimmer', because no thing with the UID 'zwave:device:1578e7a83ee:node53' could be found.

And the ‘control’ part in paperUI stays empty. I see only the non zwave things in here (fe ntp, sun and moon). :sweat:

Maybe also a strange detail, not all nodes where properly in the inbox. So I needed to ‘tamper’ some nodes before they were properly recognized.

I’ve also found that when I create a new link (linked items) it works.
But is there a way to ‘recreate’ them automaticlly (from fe the items file)? Would save me a lot of ‘clicking’…

You haven’t inadvertently changed the controller name, or added a new controller or something?

If those devices are battery devices, then this is normal - it will take a wakeup or two for the binding to download all the data from the devices and they need to be manually woken up initially.

I had to reboot my VMware once, because for some reason, he wouldn’t see an USB Stick. So OH2 was started with only 1 stick.
Maybe at this point, ACM1 became ACM0, but this shouldn’t be a problem, or should it?

The reason why I mentioned this, was because all these devices were already properly recognized before.

The thing that worries me a bit, is that all my ‘linked items’ are gone. And that I need to make this now manually? Before I didn’t do this, and everything was working. Now when I don’t link them, I’m getting warning as above?

I’ve also noticed that in my temperature graphs, I’m now getting descriptions as ‘sensor temperature’, and no longer the description. I guess these are the sensors I’ve already linked manually. The others don’t work anymore at first sight.

Not sure if I can/must relink all items in paperUI, or is there more wrong?

Yes. This is the same as swapping the networks around. Effectively, you have controller 1 = port 1, and all the nodes associated with this are linked to this ‘thing’ in OH2. When OH2 starts, it reads all these nodes. Now if it reads all the nodes from a different stick, then it will add them as if they are new nodes.

Yes, but swapping the sticks like this will cause the reading of the XML to fail since the networks have changed. This means it will have to re-read all the data from the devices. This is the issue that is on Github about saving the XML files in a way that avoids conflicts with different sticks.

I guess that the system has auto created items for all channels not linked to items (so called simple mode) so you need to relink your items to sort out the names.

Is there a way to ‘fix’ the sticks to a certain ports? To avoid that this would happen again?

[quote=“chris, post:5, topic:15357”]
I guess that the system has auto created items for all channels not linked to items (so called simple mode) so you need to relink your items to sort out the names.[/quote]

Okay, is there another way then link them in paperUI?
About 30 nodes, with +/- 4 sensors is about 120 clicking and searching. So if there’s an easier way… :blush:

Yes - under Linux at least you can configure symbolic links that should allow you to do this (I think!). It might take some messing around to get working, but the OH1 wiki has some information on setting up the symbolic links.

I’m not familiar with PaperUI, but in HABmin at least you can link items to channels in the UI - I guess PaperUI does this as well.

If you have simple mode enabled, then OH will automatically generate a kind of virtual item for all channels that don’t have manual items linked to them.

FTR: https://github.com/openhab/openhab/wiki/symlinks

Thanks, I’ll look into it.

Of course, I’m having 2x the same Gen5 sticks. :blush:
So I guess I’ll have to dig som deeper to see if I can identify my sticks more in detail. Else ACM0 and ACM1 can always be swapped. And if I understand it correclty, this can lead to the issue above…

You should have a play with the software that is used to add the simlinks. There are other options, and while I’m not 100% sure, I thought that there were options relating to serial number or something, but it’s been a while since I played with this…

Look for “UUID”, but I don’t know if that only works for storage devices … not a Linux expert :sunglasses:

Use udevadm info -a -n /dev/ttyACM0 etc, and see what your serial attribute is. Use this in your udev symlink rule to create a symlink for that specific device. E.g. have a line like

SUBSYSTEM=="tty", ATTRS{idVendor}=="YYYYYY", ATTRS{serial}=="XXXXXXXXXXX", SYMLINK+="zwave1"

(replacing the X’s and Ys with your device details). Then repeat for the other usb stick.

I can’t find a serial linked with the usb stick.

root@habirus:/etc/openhab2# udevadm info -a -n /dev/ttyACM0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-2/2-2.1/2-2.1:1.0/tty/ttyACM0':
    KERNEL=="ttyACM0"
    SUBSYSTEM=="tty"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-2/2-2.1/2-2.1:1.0':
    KERNELS=="2-2.1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="cdc_acm"
    ATTRS{authorized}=="1"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bInterfaceClass}=="02"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bInterfaceProtocol}=="01"
    ATTRS{bInterfaceSubClass}=="02"
    ATTRS{bNumEndpoints}=="01"
    ATTRS{bmCapabilities}=="0"
    ATTRS{supports_autosuspend}=="1"

  looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-2/2-2.1':
    KERNELS=="2-2.1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="02"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{bMaxPower}=="100mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 2"
    ATTRS{bcdDevice}=="0000"
    ATTRS{bmAttributes}=="80"
    ATTRS{busnum}=="2"
    ATTRS{configuration}==""
    ATTRS{devnum}=="4"
    ATTRS{devpath}=="2.1"
    ATTRS{idProduct}=="0200"
    ATTRS{idVendor}=="0658"
    ATTRS{ltm_capable}=="no"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="unknown"
    ATTRS{speed}=="12"
    ATTRS{urbnum}=="5382"
    ATTRS{version}==" 2.00"

  looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-2':
    KERNELS=="2-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{bMaxPower}=="0mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bcdDevice}=="0100"
    ATTRS{bmAttributes}=="e0"
    ATTRS{busnum}=="2"
    ATTRS{configuration}=="VMware Virtual USB Hub"
    ATTRS{devnum}=="3"
    ATTRS{devpath}=="2"
    ATTRS{idProduct}=="0002"
    ATTRS{idVendor}=="0e0f"
    ATTRS{ltm_capable}=="no"
    ATTRS{maxchild}=="7"
    ATTRS{product}=="VMware Virtual USB Hub"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="unknown"
    ATTRS{speed}=="12"
    ATTRS{urbnum}=="50"
    ATTRS{version}==" 1.10"

  looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2':
    KERNELS=="usb2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{authorized_default}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{bMaxPower}=="0mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bcdDevice}=="0404"
    ATTRS{bmAttributes}=="e0"
    ATTRS{busnum}=="2"
    ATTRS{configuration}==""
    ATTRS{devnum}=="1"
    ATTRS{devpath}=="0"
    ATTRS{idProduct}=="0001"
    ATTRS{idVendor}=="1d6b"
    ATTRS{interface_authorized_default}=="1"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="Linux 4.4.0-42-generic uhci_hcd"
    ATTRS{maxchild}=="2"
    ATTRS{product}=="UHCI Host Controller"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="unknown"
    ATTRS{serial}=="0000:02:02.0"
    ATTRS{speed}=="12"
    ATTRS{urbnum}=="32"
    ATTRS{version}==" 1.10"

  looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:02.0':
    KERNELS=="0000:02:02.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="uhci_hcd"
    ATTRS{acpi_index}=="16777744"
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x0c0300"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{d3cold_allowed}=="0"
    ATTRS{device}=="0x0774"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{driver_override}=="(null)"
    ATTRS{enable}=="1"
    ATTRS{irq}=="16"
    ATTRS{label}=="usb"
    ATTRS{local_cpulist}=="0"
    ATTRS{local_cpus}=="1"
    ATTRS{msi_bus}=="1"
    ATTRS{numa_node}=="-1"
    ATTRS{subsystem_device}=="0x1976"
    ATTRS{subsystem_vendor}=="0x15ad"
    ATTRS{vendor}=="0x15ad"

  looking at parent device '/devices/pci0000:00/0000:00:11.0':
    KERNELS=="0000:00:11.0"
    SUBSYSTEMS=="pci"
    DRIVERS==""
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x060401"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{d3cold_allowed}=="0"
    ATTRS{device}=="0x0790"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{driver_override}=="(null)"
    ATTRS{enable}=="1"
    ATTRS{irq}=="0"
    ATTRS{local_cpulist}=="0"
    ATTRS{local_cpus}=="1"
    ATTRS{msi_bus}=="1"
    ATTRS{numa_node}=="-1"
    ATTRS{subsystem_device}=="0x0790"
    ATTRS{subsystem_vendor}=="0x15ad"
    ATTRS{vendor}=="0x15ad"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

In that case, do a comparison with the output for your other USB device (ttyACM1) and see what differences, if any, your devices are showing. In my case, my z-stick has a serial attribute, which makes the process relatively straight forward.

No differences.

Just the urbnumber is different. What stands for ‘Usb Request Blocks’.
So I don’t think that I can use that for reference… :’(

Oh well, in that case I’m out of ideas!