RPI 5 WebThings Support and Z-Wave Migration Steps

WebThings
#1

I was perusing the upcoming upgrade to a new Z-Wage build and caught the comment that WebThings Gateway is not designed to operate on a RPI 5; I was not happy

I just installed a test RPI 5 with the intention of figuring out the steps to migrate my docker RPI 2B+ WT instance to this new architecture. I wanted to load 1.2a in a test container and manually install the latest z-wave build (14?) to test if it loaded since I had a few minutes of tech-time to spare…

My real goal was to figure out how to move my Z-Wave devices from the RPI 2 to the RPI 5 w/o having to reset the Z-Wave USB controller and devices, add each device again, and then re-create their schedules. In the past I’ve heard that migration is “difficult” to say the least.

So:

Q: Is there any hope for WebThings supporting the RPI 5?

Q: Does anybody have any hints about migrating a working Z-Wave USB dongle from 1 system to a new host w/o having to reset the controller, add each device again, and recreate their schedules.

#2

Hi Eric,

It’s not so much that WebThings Gateway doesn’t support the Rasberry Pi 5, as Raspbian Buster doesn’t support the Raspberry Pi 5. The 1.x full OS images we distribute for the Raspberry Pi are currently built on Raspbian Buster, and therefore don’t support Raspberry Pi 5.

However, as far as I know WebThings Gateway should run just as well under Docker on a Raspberry Pi 5 as on a Raspberry Pi 3/4.

WebThings Gateway 2.x full OS images will be based on a different base operating system, which should support Raspberry Pi 5.

I haven’t tried migrating Z-Wave devices from one Raspberry Pi to another, but in theory if you copied the whole ~/.webthings folder to a new install using the same USB dongle it should work as before. I don’t know how well this works in practice, but I would be interested to find out.

Hope this helps

Ben

#3

Thanks for the feedback about Z-Wave migration. I’m on vacation for the next week or so.

When I return I’ll load 1.2a and the latest test Z-Wave addon and report back on any load errors. If I get brave, I might move the Z-Wave dongle. The only thing I kinda remember now is Z-Wave library needs a key provisioned, and I’m not sure if there are any dynamic configuration files it may maintain relative in it’s code library.

later,

Eric

#4

@EricEdberg Please be aware that the Z-Wave add-on does not currently work with WebThings Gateway 1.2.0-alpha.1 due to the bug you linked to.

This issue is currently blocking the WebThings Gateway 1.2 release and I’m seeking contributors to the Z-Wave add-on, which currently lacks a module owner.

#5

Some notes on RPI5:

Also waiting for RPI5 support, but decided to have a go at running WT under Docker.
Little previous experience using Docker, other than zigbee+zwave readers on RPI3+.

$ cat /etc/os-release
PRETTY_NAME=“Debian GNU/Linux 12 (bookworm)”
NAME=“Debian GNU/Linux”
VERSION_ID=“12”
VERSION=“12 (bookworm)”
VERSION_CODENAME=bookworm
ID=debian
HOME_URL=“https://www.debian.org/”
SUPPORT_URL=“https://www.debian.org/support”
BUG_REPORT_URL=“https://bugs.debian.org/”

$ arch
aarch64

Several attempts back and forth with WT.1.1, copying a .node_version (as suggested in discourse posts) here and there, but initially no success.
Then got WT.1.0 started, and later when going back to WT.1.1 it got past the node startup error.
No clear idea of what made the change.
One thing I did was to delete the ‘version’ entry in docker-compose.yml, since this was flagged as obsolete.

Multiple attempts at WT.1.2a met with no success, so far

If I am not completely lost, I now have an instance of WT.1.1 running inside Docker on RPI5 Bookworm 64 bit version.

No complete functionality test, but:

Did WT server log in and reclaimed a domain previously used for testing.
Add ZigBee adapter and connect to Mosquitto on other RPI.
Add Network presence detector - several other devices visible
Add Philips Hue adapter - did not sync with HUE controller
Add Pulse adapter - create a pulse, see that it appears in 'Things' and 'Rules' page
Add Run program adapter - run 'ls', 'Success' but output is hidden
Settings->Domain - local access cannot be ticked. However, host.local:8080 works.
Settings->Localization - Timezone correct, but country is Afghanistan (far away ...) Setting is read-only. Set from docker-compose maybe ?
Settings->Developer->View internal logs -> ok

Also, noted that the convenient add-on ‘Seashell’ is not available.

// GHo

#6

I have a new vanilla RPI5 using Raspbian OS x64 with docker installed. I’ve had no obvious problems “starting” both WT 1.1 and WT 1.2a with an empty data volume (except for the mandatory .node_version pre-initialized before startup.

*ele@elerpi5:~ $ docker ps*
*CONTAINER ID   IMAGE                       COMMAND      CREATED        STATUS      PORTS                                                                                  NAMES*
*4ebc1d17ed63   webthingsio/gateway:12a1    "/init.sh"   9 days ago     Up 5 days   0.0.0.0:7443->4443/tcp, :::7443->4443/tcp, 0.0.0.0:7080->8080/tcp, :::7080->8080/tcp   webthings12a1*
*61b0ad552d5e   webthingsio/gateway:1.1.0   "/init.sh"   2 months ago   Up 5 days*

When testing v12a1, I installed numerous addons after starting the container without obvious fatal errors, except for numerous “type” or “object” errors which were observed in previous releases. I’ve not configured/tested anything yet due to vacation and Ben’s comments that the Z-Wave addon test build will fail which is my end integration goal.

This is the .sh script I use to start my 12a1 image for reference. There are separate /home/webthings* folders for each running WT version and re-mapped ports to allow simultaneous testing. I’ve also downloaded and tagged the 12a1 build accordingly (docker best practice).

ele@elerpi5:~ $ VOL="/home/webthings12a"

# bug: docker WT will not start if .node_version does not exist
[ ! -f "${VOL}"/.node_version ] && echo "12" > "${VOL}"/.node_version

docker rm webthings12a1

docker run -d --restart unless-stopped \
        -p 7080:8080 \
        -p 7443:4443 \
        -e TZ=America/Chicago \
        -v /usr/bin/nc:/usr/bin/nc \
        -v /home/webthings12a1:/home/node/.webthings \
        --name webthings12a1 webthingsio/gateway:12a1

I’m still hoping to have time in the near future to load the purported problematic Z-Wave addon build (v14) to see what errors it produces, curious minds and all…

Eric

#7

Thank you - following your hints I managed to get the alpha running as well.

I stopped the testing effort for this months ago, since for me the ‘Rules’ display appear broken.
Without rules further testing became a little cumbersome…

// GHo

#8

@bfrancis

Ben,

I wrote an addon that defined/created WebThing X10 devices. They used Netcat to communicate to a remote Mochad server to control X10 state changes. It’s worked well for the last couple of years, but I wanted to make a few changes.

The addon “package.sh” program generates SHA256SUMS, so if you make real-time test changes to the running code, WT complains about the SSHSUM hash mismatch when it loads the addon.

Q: Is there a way to build an addon package that does not contain the checksum security check so I only have to disable/enable the addon to reload test changes?

This is the URL to my current package.sh for reference which I obtained from some other addon example.

Could it be as simple as removing the SSH256SUMS file?

Eric

#9

@EricEdberg Probably best to start a new thread for this question, but…

I haven’t experienced this. I do know that if the gateway sees a .git directory in the add-on’s directory it treats it differently and doesn’t try to update it. That might bypass the checksum check too?