Restoring from (faulty) backups manually, recreating z-wave devices, recovering paperui-created MQTT devices

Setup, Configuration and Use Beginners
, ,
1

So I’ve demoted myself back to this beginners section. I thought I had backups running nightly with amanda, as well as automatic backups with openhab-cli backup. It turns out these ran the day I set them up and not since. Unfortunately, lots of changes happened in the interim.
On rebooting my pi3b+ (nicely, shutting down OH, then restarting the pi with ssh) after changing a persistence file, my Pi refused to boot. Rainbow screen of death, when I plugged a monitor in.
I can access the SD, as well as the USB SSD drive the install was expanded onto. I’ve done a wholesale copy/paste to make backups of what I believe are all the pertinent files, should they have anything useful.

  1. Any suggestions on where to correctly re-configure booting (initially from file on SD /boot) onto USB mass storage, when it was set up with the openhab-config expand onto usb storage option? From looking at the drives from my laptop, they don’t appear corrupted. Would the processes decribed below work?
    https://www.raspberrypi.org/blog/pi-3-booting-part-i-usb-mass-storage-boot/
    https://www.raspberrypi.org/forums/viewtopic.php?t=220799
    I’ve reviewed the file descriptions here: https://www.raspberrypi.org/documentation/configuration/boot_folder.md , but that doesn’t particularly help me. I can see a /boot directory full of files on my micro-SD card, and the /boot directory is emtpy on the USB drive.

  2. While I would love to save my influx db data from my house for the past year, I can live without this. A fresh install could be an option. What is challenging to me is:
    a) my zwave devices stay as unknown devices. in Z-Way config, when I booted that up, they were listed as unknown as well (I took this opportunity to update the zway firmware, and make a backup of the controller). I’ve tried cycling several of the devices multpile times, and it seems OH doesn’t re-interrogate them. I’d rather not exclude and re-include all 38 devices scattered over two buildings. Given that the controller has them clearly added, are there files I can copy over from my (newly-created) backup to restore the devices identity in openhab? I had been running zwave 2.5.0 release on openhab 2.4. I imagine there shouldn’t be much of a difference from the 2.5.0 to the 2.5.1 that appears to be installed with a fresh install.
    b) my custom mqtt devices - this was a lot of technical work setting them up, and none used a home-like standard. These were all set up with Paper-UI. Is there somewhere I can go to recover these configurations?

Background, not really questions:
I put the card and USB drive into another RPi3B+(#2), and they also wouldn’t boot. I took the SD from that RPi, and it booted fine in RPi #1 with its own linux distro. I put a fresh SD into the initial RPi (#1), and was able to install openhab just fine. When installing openhab, I had a monitor connected, and it frequently was giving me low voltage warnings - with the only peripherals being the razberry shield and a USB keyboard. I had this using multiple 2A power supplies. I am suspicious there is something flaky on the board itself producing this, prompting me to want to move everything over to a new board. I haven’t yet decided on if I’ll get an RPi4 (4gb), or stick with the RPi3B+ #2 until I decide on a more robust mini PC like mintbox or some similar device, even though that will involve getting a new Z-wave dongle and then having to exclude/re-include all the devices manually.

================
I am currently running Openhabian (current as of Feb 10th) on a Raspberry Pi3B+, running Openhab 2.5.0 release.
Previously, on the same RaspberryPi3B+ device, I was running Openhabian, OH 2.4.0 release with the z-wave 2.5 binding from approximately early January.

Edit Feb 24th 8PM Update.
The low power warning was a red herring. They were due to a bad USB power cable - not used in the usual deployment, only for when I brought the RPi down to my work area.
In re-trying the extend-to-usb, I note that both a fat32 sda1 partion is created, as well as an ext4 sda2.
My SSD seems to have lost recognition of the fat32 sda1 partition.
Backups - Check them before you rely on them, folks. Make sure they’re sent to where they are supposed to go, and make sure the files are big enough for what you’re expecting it to contain. If not, try use them and ensure everything is there. Having a copy of all the relevant config files is good, but may not be sufficient.

2

You are likely running 2.5.1 addons.

Please also be aware that the footer of the dashboard will still say “openHAB 2.5.0 Release Build” - this is because the version of the core runtime is show, which has not been touched at all. To see the detailed version information, please have a look at userdata/etc/version.properties , which should look like:

openHAB Distribution Version Information
----------------------------------------
build-no        : Release Build
online-repo     : https://openhab.jfrog.io/openhab/libs-release

Repository        Version
----------------------------------------
openhab-distro  : 2.5.1
openhab-core    : 2.5.0
openhab1-addons : 1.14.0
openhab2-addons : 2.5.1
karaf           : 4.2.7

from openHAB 2.5.x Patch Releases

1 Like
3

This doesn’t help you, but this is a great example why you need to test your backups.

My understanding is that the OH ZWay binding (not to be confused with the Z-Wave binding) just interacts with the Z-Way service. So you need to figure out how to get the devices recognized by that software before OH will be able to see them.

If you are talking about the Z-Wave binding, I think you need to make sure that you are using the same inclusion password as your old OH install used or else the binding won’t be able to decrypt the messages to figure out what it is.

I’m sure that debug logs in both cases would be helpful. I believe you would only need to exclude/reinclude devices if you’ve done so securely in the past and you lost the password. I could be wrong about that though.

Everything done through PaperUI is stored in /var/lib/openhab2/jsondb.

All of that data is stored in /ver/lib/influxdb.

You have a bad or failing power supply. Replace that and I bet you will be able to boot your original SD/USB config just fine.Or try plugging in the USB stuff to a powered USB hub and then plug it into the RPi to eliminate an overdraw from those as a potential problem.

4

Thanks Rich,
You’re right, it doesn’t help about the backups - and this is why I booted myself back to the beginners forum. I was distracted by shiny things, and am learning a painful lesson. Up until today, I had expected to be spending my time learning how to do an amanda restore, when I saw the old, single backup on my separate server.

The location of the data for paperui devices and influxdb is helpful, thanks.

Re: the power supplies - I’ve now tried 4 different power supplies, at least one of which I had been fairly comfortable of its reliability. I think I may set up an ammeter to sort out the actual draw, but it’s a good consideration - especially given that bad power is the error that I am getting. I will try chase this down further - it has the potential to be quite an easy fix.

For the Z-Wave devices, I was talking about the Z-Wave binding. I haven’t ever had the Z-Way binding up and functional (If I had perhaps the z-way controller backup would have preserved all of this). I usually don’t have the z-way server running - I had only fired it up to update the firmware of the chip.
It’s an interesting thought about the passkey used for inclusion. I really can’t recall what I may have supplied - not sure I supplied anything. I know the 6 schlage locks may have used this, but I have several other devices - some predating S2 or zwave plus - so there should be many that were not securely included. The only items I’m not sure about the inclusion possibly having a key would have been the locks. Given that none of the z-wave devices are showing up, would the z-wave key still be a potential cause? Do you know if I can try copy over files from my old install openhab somewhere in the z-wave binding, and see if my non-secure devices work?

Finally, I am trying to sort out the boot issues with the microSD card.
Do you, or does someone else know if the openhabian-config ‘expand to USB’ option uses the ‘boot form USB mass storage device’ option as documented by the raspberry pi foundation (link below), or if it uses an SD boot, with some files stored on the mass storage device?

On RPi #1 I can boot with a new microSD (standalone fresh install openhabian). Trying the old microSD card gives me the rainbow screen of death, regardless of which powersupply is used. I can boot with another microSD cards as well - although I now over-wrote it with a fresh bootloader.bin, but this didn’t fix my problem. What I’m wondering is if this is a problem with my old microSD not directing to the USB storage, or if the problem is that the USB storage isn’t picking up where the microSD left off with the boot process.
I don’t think that my RP3B#2 has had the write once memory updated to boot from USB. I double-checked, and Pi#1 is a 3B+, and Pi#2 is a 3B - which is significant as the older one needs the one-time programmable memory written to enable USB boot. My read is that this will prevent the pi from booting just on SD in the future, but I will bite this bullet.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

5

Small update (and perhaps this should be on a separate thread):
I’ve flashed the OTP successfully, apparently enabling USB boot. I have an otherwise blank microSD just with the bootcode.bin file on it that apparently is the minimal requirement for booting on USB mass storage. The device powers on, but the screen stays black.
I put the old microSD card in and boot. The screen displays the rainbow screen, and remains frozen on it. Not knowing how openhabian-config had expanded to USB, I’m not sure of the significance of this.

@Bruce_Osborne. Yes, it is 2.5.1 addons, 2.5.0 core.

[edit: corrected filename of the bootloader to bootcode.bin, not bootloader.bin]

[edit: update #2 - I found my amanda backups on the expanded USB storage device - it appears they weren’t being mirrored to my other server, but amanda had been running correctly. Perhaps this gives me somewhere to proceed.
I have also been able to set up a more traditional USB boot system. I put the openhabian image on an USB memory stick, put the otherwise blank with bootcode.bin microSD card in, and was able to boot and have the USB stick have a working openhabian system. Superficially comparing this with the previous usb SSD mass storage device has very similar folder structure. I’m guessing something has simply changed with this ssd to have it stop being bootable. I’ll keep digging.]

edit #3 - The SSD expanded drive doesn’t have a fat32 partition that can house the /boot information, and its own /boot directory is empty. This contrasts against the micro SD cards and the USB stick I just made from the openhabian image. With the Fat32 section, the USB stick can be booted with just the bootcode.bin on the microSD card. Without the Fat32 section, the SSD drive is unable to boot. I’m guessing this has something to do with the way openhabian-config moved files over onto the SSD drive.
Given this, I imagine it would be preferable burn the openhabian image directly to the expanded USB mass media drive an dhave it expanded for the initial install, raather than the openhabian-config expand-to-usb method, which is still reliant on a functioning microSD card. I’m going to try discover what the minimum required files are for the microSD card Fat32 partition, and hopefully can reverse-engineer how to fix this. It sure would be nice if someone out there had some pointers, though ! :wink:

edit #4 I’ve copied the boot directory from the new USB stick over onto my microSD card’s boot directory, and now no longer freeze at the rainbow screen. I modified the cmdline.txt file to set the root to /dev/sda1 (and sda2, and sda).
It now freezes after it’s recognized the attachde SCSI disk, identified it, has write-protect off, disabled FUA, enabled the write cache and read cahce (doesn’t support DPO or FUA), and labels sda:sda1
It the freezes on/after random: crng init done . I don’t know what is supposed to happen here.
Are there any other files that need to be configured? It may be that I’ve told it all the files it will need are on the SSD drive, but they aren’t, or perhaps there are other parameters that need to be configured. I think I’m done troubleshooting for tonight, and will eagerly await potential suggestions on which direction to go.

6

I’m no expert on zwave so I couldn’t say, but I’m certain the experts will want to see some debug logs from the binding to help diagnose this further. I agree, the devices that were included without security wouldn’t be affected. I think the binding generates a default password, or perhaps a random password which would be bad in this case as the password might be harder to recover (not impossible if you have a copy of your original Zwave controller Thing hanging around).

As long as the OH base versions are the same that should work. But you need to grab both the CONF and the USERDATA folders.

Unfortunately I don’t know anything about that.

7

Hi Rich,

I tried stopping openhab, cleaning the cache, copying the conf and userdata directories over, then restarting my OH system. The z-wave config files are over-written with essentially blank ones each time. The logs show:

2020-02-23 21:52:11.796 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller

2020-02-23 21:52:11.799 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.

2020-02-23 21:52:16.705 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 12: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.716 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 30: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.716 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 35: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.723 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 14: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.728 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 17: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.717 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 20: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.729 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 36: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.771 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 10: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.782 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 9: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.776 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 26: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.776 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 34: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.770 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 11: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.772 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 18: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.769 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 28: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.755 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 29: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.750 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 24: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.753 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 16: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.753 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 27: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.765 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 6: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.731 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 21: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.801 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 19: Restore from config: Error. Data invalid, ignoring config.

2020-02-23 21:52:16.776 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 37: Restore from config: Error. Data invalid, ignoring config.

==> /var/log/openhab2/events.log <==

2020-02-23 21:52:16.906 [hingStatusInfoChangedEvent] - 'zwave:serial_zstick:7eafb589' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:16.935 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node37' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:16.947 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node30' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:16.957 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node31' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:16.977 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node32' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.012 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node34' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.038 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node36' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.058 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node33' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.068 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node35' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.072 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node37' has been updated.

2020-02-23 21:52:17.081 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node34' has been updated.

2020-02-23 21:52:17.094 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node30' has been updated.

2020-02-23 21:52:17.099 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node37' has been updated.

2020-02-23 21:52:17.104 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node36' has been updated.

2020-02-23 21:52:17.109 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node34' has been updated.

2020-02-23 21:52:17.113 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node30' has been updated.

2020-02-23 21:52:17.120 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node20' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.128 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node19' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.133 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node35' has been updated.

2020-02-23 21:52:17.140 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node27' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.148 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node21' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.154 [me.event.ThingUpdatedEvent] - Thing 'zwave:serial_zstick:7eafb589' has been updated.

2020-02-23 21:52:17.235 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node27' has been updated.

2020-02-23 21:52:17.254 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node21' has been updated.

2020-02-23 21:52:17.264 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node26' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.267 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node19' has been updated.

2020-02-23 21:52:17.270 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node35' has been updated.

2020-02-23 21:52:17.298 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node29' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.314 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node20' has been updated.

2020-02-23 21:52:17.324 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node29' has been updated.

2020-02-23 21:52:17.332 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node26' has been updated.

2020-02-23 21:52:17.343 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node19' has been updated.

2020-02-23 21:52:17.346 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node20' has been updated.

2020-02-23 21:52:17.356 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node22' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.360 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node27' has been updated.

2020-02-23 21:52:17.366 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node24' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.373 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node23' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.379 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node28' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.385 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node10' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.452 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node22' has been updated.

2020-02-23 21:52:17.479 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node24' has been updated.

2020-02-23 21:52:17.481 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node29' has been updated.

2020-02-23 21:52:17.491 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node18' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.504 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node28' has been updated.

2020-02-23 21:52:17.508 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node10' has been updated.

2020-02-23 21:52:17.531 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node16' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.534 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node16' has been updated.

2020-02-23 21:52:17.537 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node28' has been updated.

2020-02-23 21:52:17.540 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node18' has been updated.

2020-02-23 21:52:17.544 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node24' has been updated.

2020-02-23 21:52:17.550 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node6' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.557 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node10' has been updated.

2020-02-23 21:52:17.564 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node17' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.570 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node12' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.644 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node6' has been updated.

2020-02-23 21:52:17.646 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node12' has been updated.

2020-02-23 21:52:17.663 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node17' has been updated.

2020-02-23 21:52:17.666 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node16' has been updated.

2020-02-23 21:52:17.672 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node14' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.709 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node9' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.715 [hingStatusInfoChangedEvent] - 'zwave:device:7eafb589:node11' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

2020-02-23 21:52:17.720 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node18' has been updated.

2020-02-23 21:52:17.723 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node11' has been updated.

2020-02-23 21:52:17.726 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node6' has been updated.

2020-02-23 21:52:17.729 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node14' has been updated.

2020-02-23 21:52:17.733 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node9' has been updated.

2020-02-23 21:52:18.453 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:7eafb589:node11' has been updated.

I don’t think there is a permissions issue with the files copied over, as they were successfully able to be over-written by openhab.
Oddly enough, this also occurs for the org.eclipse.smarthome.core.thig.Thing.json file (and associated files in that directory) - meaning my MQTT things can’t be batch re-created by pasting my old config into the new files. One big possible area for problems could be that I’m copying over files from OH2.4 stable to a new OH2.51 system - with the exception being zwave was previously 2.5.0 January snapshot. I haven’t clearly broken anything, though - the new files simply get removed. I copy the files over using ‘Paragon linux file system for windows’ (a lifesaver) - I’m not sure if there are permissions issues with it, and the system auto-boots into openhab, so I haven’t been able to try restore permissions (before the files are tossed).
** Is there something I could be missing that is causing the newly copied-over files to be deleted?

I’ll try do an amanda restore next, now that I have the files.

I think I’ll be looking at a fresh install, booting cleanly from only (other than the single bootloader.bin file on a microSD card). I’ll probably bite the bullet and walk around with a portable power supply and the RPi to exclude/re-include everything.

8

If it’s relevant, below are two different zwave node config files. The first one auto-created by my ZWave2.5.0 snapshot binding with the old system, and the second one the one over-written by the new 2.5.1 system/binding

Old, with all the correct information:

<node>
  <homeId>0xc3b69503</homeId>
  <nodeId>34</nodeId>
  <version>4</version>
  <manufacturer>0x63</manufacturer>
  <deviceId>0x3032</deviceId>
  <deviceType>0x4f50</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_ZWAVEPLUS_INFO</commandClass>
    <commandClass>COMMAND_CLASS_CRC_16_ENCAP</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
    <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
    <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
    <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
    <commandClass>COMMAND_CLASS_SCENE_ACTUATOR_CONF</commandClass>
    <commandClass>COMMAND_CLASS_SCENE_ACTIVATION</commandClass>
    <commandClass>COMMAND_CLASS_FIRMWARE_UPDATE_MD</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map">
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <maxNodes>0</maxNodes>
        <name>Lifeline</name>
        <profile1>0x0</profile1>
        <profile2>0x1</profile2>
        <commands>
          <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
          <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
        </commands>
        <associations>
          <associationMember>
            <node>1</node>
          </associationMember>
        </associations>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <maxNodes>0</maxNodes>
        <name>On/Off control</name>
        <profile1>0x20</profile1>
        <profile2>0x1</profile2>
        <commands>
          <commandClass>COMMAND_CLASS_BASIC</commandClass>
        </commands>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>3</int>
      <associationGroup>
        <index>3</index>
        <maxNodes>0</maxNodes>
        <name>On/Off control</name>
        <profile1>0x20</profile1>
        <profile2>0x1</profile2>
        <commands>
          <commandClass>COMMAND_CLASS_BASIC</commandClass>
        </commands>
        <associations/>
      </associationGroup>
    </entry>
  </associationGroups>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SWITCH_BINARY</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_POWER_SWITCH_BINARY</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>99</deviceManufacturer>
              <deviceType>20304</deviceType>
              <deviceId>12338</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
            <COMMAND__CLASS__SWITCH__BINARY>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__SWITCH__BINARY>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SCENE_ACTIVATION</commandClass>
            <COMMAND__CLASS__SCENE__ACTIVATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__SCENE__ACTIVATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
            <COMMAND__CLASS__SWITCH__ALL>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
              <mode>SWITCH_ALL_INCLUDE_ON_OFF</mode>
            </COMMAND__CLASS__SWITCH__ALL>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SCENE_ACTUATOR_CONF</commandClass>
            <COMMAND__CLASS__SCENE__ACTUATOR__CONF>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__SCENE__ACTUATOR__CONF>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ZWAVEPLUS_INFO</commandClass>
            <COMMAND__CLASS__ZWAVEPLUS__INFO>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
              <zwPlusVersion>1</zwPlusVersion>
              <zwPlusRole>ROLE_TYPE_SLAVE_ALWAYS_ON</zwPlusRole>
              <zwPlusNodeType>NODE_TYPE_ZWAVEPLUS_NODE</zwPlusNodeType>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__ZWAVEPLUS__INFO>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_CRC_16_ENCAP</commandClass>
            <COMMAND__CLASS__CRC__16__ENCAP>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__CRC__16__ENCAP>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_VERSION</commandClass>
            <COMMAND__CLASS__VERSION>
              <version>2</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
              <libraryType>LIB_SLAVE_ENHANCED</libraryType>
              <protocolVersion>4.54</protocolVersion>
              <applicationVersion>5.21</applicationVersion>
              <hardwareVersion>255</hardwareVersion>
            </COMMAND__CLASS__VERSION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
            <COMMAND__CLASS__DEVICE__RESET__LOCALLY>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__DEVICE__RESET__LOCALLY>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
            <COMMAND__CLASS__ASSOCIATION__GRP__INFO>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <autoSubscribeGroups>
                <int>1</int>
              </autoSubscribeGroups>
            </COMMAND__CLASS__ASSOCIATION__GRP__INFO>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_FIRMWARE_UPDATE_MD</commandClass>
            <COMMAND__CLASS__FIRMWARE__UPDATE__MD>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
            </COMMAND__CLASS__FIRMWARE__UPDATE__MD>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
            <COMMAND__CLASS__ASSOCIATION>
              <version>2</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
              <maxGroups>3</maxGroups>
            </COMMAND__CLASS__ASSOCIATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
            <COMMAND__CLASS__POWERLEVEL>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <powerLevel>0</powerLevel>
              <powerTimeout>0</powerTimeout>
            </COMMAND__CLASS__POWERLEVEL>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors>
    <int>6</int>
    <int>10</int>
    <int>11</int>
    <int>12</int>
    <int>14</int>
    <int>17</int>
    <int>18</int>
    <int>20</int>
    <int>29</int>
    <int>30</int>
  </nodeNeighbors>
  <lastReceived>2020-02-13 02:36:46.344 UTC</lastReceived>
</node>

New, with no working content:

<node>
  <homeId>0xc3b69503</homeId>
  <nodeId>34</nodeId>
  <version>4</version>
  <manufacturer>0x7fffffff</manufacturer>
  <deviceId>0x7fffffff</deviceId>
  <deviceType>0x7fffffff</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <associationGroups class="concurrent-hash-map"/>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SWITCH_BINARY</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_POWER_SWITCH_BINARY</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>0</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors>
    <int>6</int>
    <int>10</int>
    <int>11</int>
    <int>12</int>
    <int>14</int>
    <int>17</int>
    <int>18</int>
    <int>20</int>
    <int>29</int>
    <int>30</int>
  </nodeNeighbors>
</node>
9

You mean the XML files ? You can do, but if they are missing, OH will query your devices and regenerate them.

10

I figured out the undervoltage errors : a bad USB cord.
I soldered up a USB socket to a benchtop powersupply and kepy getting this error. I eventually swapped out the USB cord, and the problem went away. Incidentally I saw my RPi3B with SSD drive and RaZberry shield drew a peak of 0.8 amps, usually 0.5-0.6, should anybody be interested in knowing.

Looking into a possible problem with the zwave xml files: “Paragon Linux File Systems for Windows” writes files with owners of “nobody” and group “nogroup”. This doesn’t fully make sense, though, as it has the permissions rw, rw, rw - so OH should be able to read/write them OK. Do you know if OH /the ZWave binding requires the owner to be correct before accepting these files, or is simple rw access sufficient?

11

So you are running under Windows Subsystem for Linux. In my experience WSL1 works with many but not all Linux functionality. I see they are now developing a new WSL 2 compatibility layer.
Quite a few people here run OH under Windows. I have not heard if anybody running under WSL. I doubt it has even been tried before now.

12

Hi @Bruce_Osborne
Sorry, no, I’m not running under a subsystem. Way up near the top I specified in running on openhabian, on a raspberry pi 3b+.

The sd (expanded to usb ssd) stopped booting, and I really wanted to get at the files on the ext4 partitions, when I found my backups weren’t on my server. My Ubuntu server is hard to physically get to, and my laptop is windows, which led my to find this windows program for reading /writing ext4.

In the end, I was able to get the files to “stuck” by cutting /pasting into putty/ssh. Reset the cache, refreshed ownership, and I can see the zwave devices with the correct parameters /names which appear to be online. They don’t do anything, though. I’m wondering if it may be due to having overwritten the paperui json files on 2.5.1 from my 2.4 backup.

Side note, I learned the value of testing backups. While the backup files were eventually found, they didn’t seem to contain anything of value. Also, backups would need you to restore on the same version openhabian that had made the backup.