Pi4 USB boot and Zwave/Zigbee not responding

Tags: #<Tag:0x00007f61702abe98> #<Tag:0x00007f61702abdd0>

Hi,

I flashed the beta eeprom for native USB boot on my PI4. Installed openhabian on a new SSD, updated everything and restored a backup. So far so good. The PI boots from USB/SSD without any problems. Openhab runs fine except that my Zwave (razberry shield/ttyAMA0) and Zigbee (TI CC2531EMK USB Stick / ttyACM0) controllers and things are online but not updating/responding. (after a while some Zwave devices go offline (device not communicating))

I inserted my original SD card and everything worked as before. So I cloned this (working) SD card with rpi-clone and booted from USB again. Same as before, everything online but Zwave/Zigbee not responding.

Anyone else with the same issues?

  1. Did you backup the SD-Card configuration & restore to SSD?
  2. What versions if OH?
  3. If they are new configs, secure devices will not work. The key is stored in the OH config.

1st attempt:
openhab-cli backup --full on the running instance, copied zip to SSD and restored (used this method successfully on another SD)
2nd attempt:
cloned the whole SD with rpi-clone

openHAB 2.5.5-1 (Release Build)

I have no secure devices :slight_smile:

Maybe it has something to do with the bootloader/“bios” ?
BOOT_UART is disabled, so there shouldnt be any debug output on GPIO 14/15

[13:25:33] root@openhab:/home/openhabian# vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
SD_BOOT_MAX_RETRIES=1
USB_MSD_BOOT_MAX_RETRIES=1
BOOT_ORDER=0xf41

Not sure if the same config is used while booting from SD? I doubt it’s binding related tbh.

If so, that would be off-topic here and more appropriate on a Pi forum likely.

It could still be of interest to other Rpi4 users with newer (beta) firmware.

2 Likes

Hey @tsmit Tom,
Let me get this straight so I’m sure to understand you correct.
So you flashed the PI4 with the 28-05 release of the EEPROM Beta? Installed Openhabian on a new SSD, copied the latest *.elf and *.dat files on the Openhabian /boot partition?
So that implies that you are not running the latest Raspberry Pi OS and the latest Kernel right?
Interesting if that is the case. Makes the whole transition a lot easier because it eliminates the manual OpenHab installation.
I’m running a new PI4 (8Gb, whoop whoop, version) booting from USB (Kingston SSD) with Raspberry Pi OS. Works like a charm and I’m going to test Openhab this weekend on that setup. However I’m still not sure what the best (and easiest) approach would be.
Keep you all posted.
Best,
E

Hi! @EdwardV,

Yes, make sure you change rpi-update to beta on the new SSD as well, otherwise it will “update” to the non-beta elf/dat files and stop booting.
I used this tutorial: https://tynick.com/blog/05-22-2020/raspberry-pi-4-boot-from-usb/

I’m not sure, I did run apt update && apt dist-upgrade (I think the Openhabian install script does that too?)

Nice :sunglasses:

Openhabian and Openhab are running fine! Everything works flawlessly and fast (!!) except Zwave and Zigbee. That is all :slight_smile:

Do you use Zwave (razberry) or Zigbee?

Hey @tsmit, I started with an extra SSD disk and conducted your process, manually copied the *.dat and *.elf files. Works like a charm. So I have a completely new, clean Openhabian running.That proves that one doesn’t need the latest RaspOS to run from USB, the EEPROM update is enough.
I am using Zwave but with a USB stick (Aeotec), that’s on the list for tomorrow :slight_smile:
Keep you posted on my Zwave findings.

Best,
E

Hi @EdwardV, How did it go with your setup? Does everything work?

Last week I experimented some more with my SSD setup and aparently zigbee does work. It’s only razberry that doesnt work. I hooked up a serial usb cable to GPIO 14 and 15 to see if there is any data from the bootloader, there isn’t.

I captured some zwave data and it look like this:

[13:48:28] root@openhab:/home/openhabian# jpnevulator --timing-print --tty /dev/ttyAMA0:SB9600d --read --ascii -i 30
2020-06-11 13:48:33.860778:
10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 00 0B …-.2.!..
2020-06-11 13:48:35.359553:
01 10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 0B …-.2.!..
2020-06-11 13:48:36.859338:
01 10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 0B …-.2.!..
2020-06-11 13:48:38.359657:
01 10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 0B …-.2.!..
2020-06-11 13:48:39.858908:
01 06 00 49 81 00 00 31 …I…1
2020-06-11 13:48:41.358665:
06 00 49 81 00 00 31 …I…1
2020-06-11 13:48:42.858752:
01 06 00 49 81 00 00 31 …I…1
2020-06-11 13:48:44.358667:
01 06 00 49 81 00 00 31 …I…1
2020-06-11 13:48:45.859339:
01 10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 00 0B …-.2.!..
2020-06-11 13:48:47.359124:
01 10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 00 0B …-.2.!..
2020-06-11 13:48:48.859243:
10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 00 0B …-.2.!..
2020-06-11 13:48:50.358890:
01 10 00 04 00 2D 08 32 02 21 12 00 00 00 00 C6 00 0B …-.2.!..

Not sure if it is supposed to look like this but the binding seems to be communicating with the razberry hat.

Hi @tsmit, as I mentioned I’m using a Aeotec Gen5 Zwave USB stick. So I can confirm that this works without any issues for the last couple of weeks. Stable and without dropping the connection. I use a € 1,00 passive USB hub on one of the USB2 ports of the Pi.
I don’t have a razberry so I can’t give you any insights in that area . . .
Best,
E

Good! Now I’m pretty sure the problem is in the onboard uart/firmware/USB booloader and is not OpenHAB related :slight_smile: Thanks for your reply :slight_smile:

Just for future reference:

I found out that it has something to do with the Asmedia controller. (I tried two different usb to m.2 converters)

scenario’s:

  1. boot from usb device -> zwave doesn’t work
  2. boot from SD -> zwave works -> insert usb to ssd controller -> zwave stops working after a while

Next I’m going to try to boot from another brand usb to ssd controller.

We have seen some USB2 controllers that do not respond correctly in a USB3 port. A solution is to add a USB2 hub in between. The port tries to communicate as USB3 which is incorrect.

yeah, both controllers are usb 3 connected to a usb 3 port