Have tried to start with a clean install and couldn’t get Razberry card working. All settings reviewed, no issue found, no error messages in Openhab or syslogs.
Have validated now with Zwave and found communication errors in that log. Happens even with a clean bookworm 32 Bit Image with only Z-Wave installed. No system tweaks besides enabling serial port, which obviously is working, but contents are not usable by Applications. Z-Wave Error Messages copied below.
[2024-12-22 16:51:04.175] [D] [zway] Opened device: /dev/ttyAMA0
[2024-12-22 16:51:04.175] [I] [i/o] Setting port speed to 115200
[2024-12-22 16:51:04.175] [D] [zway] Worker thread entry point
[2024-12-22 16:51:04.175] [D] [zway] Worker thread successfully created
[2024-12-22 16:51:04.176] [I] [zway] Adding job: Get controller info and supported function classes
[2024-12-22 16:51:04.186] [D] [zway] SENDING: ( 01 03 00 07 FB )
[2024-12-22 16:51:04.188] [D] [zway] RECEIVED ACK
[2024-12-22 16:51:04.188] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x04
[2024-12-22 16:51:04.188] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x00
[2024-12-22 16:51:04.188] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x02
[2024-12-22 16:51:04.188] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0xfe
[2024-12-22 16:51:04.188] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x87
[2024-12-22 16:51:04.188] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x7f
[2024-12-22 16:51:04.192] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x88
[2024-12-22 16:51:04.193] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0xcf
[2024-12-22 16:51:04.193] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x3f
[2024-12-22 16:51:04.193] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0xc0
[2024-12-22 16:51:04.193] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x47
[2024-12-22 16:51:04.193] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0xfb
[2024-12-22 16:51:04.193] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x89
[2024-12-22 16:51:04.193] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0xea
[2024-12-22 16:51:05.692] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x47
[2024-12-22 16:51:07.192] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x75
[2024-12-22 16:51:08.712] [E] [zway] RECEIVED UNKNOWN PACKET TYPE: 0x0e
[2024-12-22 16:51:24.355] [I] [zway] Job 0x07 (Get controller info and supported function classes): No RESPONSE received before timeout
[2024-12-22 16:51:24.355] [D] [zway] SENDING: ( 01 03 00 07 FB )
[2024-12-22 16:51:24.561] [I] [zway] Job 0x07 (Get controller info and supported function classes): No ACK received before timeout
[2024-12-22 16:51:24.561] [D] [zway] SENDING: ( 01 03 00 07 FB )
[2024-12-22 16:51:24.763] [I] [zway] Job 0x07 (Get controller info and supported function classes): No ACK received before timeout
[2024-12-22 16:51:24.763] [W] [zway] Job 0x07 (Get controller info and supported function classes) dropped: too many resends
[2024-12-22 16:51:24.763] [D] [zway] Job 0x07 (Get controller info and supported function classes): fail
[2024-12-22 16:51:24.763] [C] [zway] Get Serial API Capabilities returned zero.
[2024-12-22 16:51:24.763] [I] [zway] Removing job: Get controller info and supported function classes
[2024-12-22 16:51:24.778] [D] [zway] Worker thread exit point
[2024-12-22 16:51:24.778] [D] [zway] Worker thread successfully finished
[2024-12-22 16:51:24.778] [D] [i/o] Closing port
Zwave binding or Z-way binding? These are two separate bindings. One interfaces with the Zwave dongle directly and the other goes through the Zway software which in turn connects to the physical binding.
Yopur logs are comming from zway, not zwave. See Z-Way - Bindings | openHAB for details on how to get the Z-way binding working. If you prefer to use the Zwave binding, see ZWave - Bindings | openHAB.
My understanding the Razberry can work with either.
Thanks for replying.
Don’t think the Issue is Zway, Zwave or Openhab Bindings. All don’t work on bookworm. Have validated with two RasPi 3B+, 2 Razberry two and one Razberry 7 extension Card. Result is the same with all - running with Bullseye works with all, running with bookworm works with none. So assume the serial driver in bookworm is the issue. Think the error messages supports that suspicion.
The error Messages result out of Z-wave me. Only Reason is, that that is the only source printing an error message - neither openhab logs nor syslogs deliver an error info.
Binding in OpenHab stays offline and is therefore unusable, but does not list the error. Believe there is also room for improvement.
I have zwave working with bookworm on rpi3b with an old aeotec, on a rpi4 with zooz zst39 and rpi5 with zooz st10. What the capability command looks like (OH Zwave binding) is shown below.
From your log it looks like the bytes are not being processed. Not sure that is serial. Are you using bookworm armv7? I don’t think a 64 bit OS will work on the devices you listed
2023-02-08 16:44:44.786 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 03 00 07 FB
2023-02-08 16:44:44.795 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2023-02-08 16:44:44.796 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2023-02-08 16:44:44.801 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2023-02-08 16:44:44.801 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 2: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2023-02-08 16:44:44.802 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 2B 01 07 07 12 00 00 00 04 00 04 F6 87 3E 88 CF 2B C0 4F FB D7 FD E0 17 00 00 80 00 80 86 80 BA 05 00 70 00 00 EE 7F C0 00 00 00 D5
2023-02-08 16:44:44.803 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2023-02-08 16:44:44.803 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 2: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2023-02-08 16:44:44.804 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2023-02-08 16:44:44.805 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2023-02-08 16:44:44.805 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2023-02-08 16:44:44.806 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SerialApiGetCapabilities[7], type=Response[1], dest=255, callback=0, payload=07 12 00 00 00 04 00 04 F6 87 3E 88 CF 2B C0 4F FB D7 FD E0 17 00 00 80 00 80 86 80 BA 05 00 70 00 00 EE 7F C0 00 00 00
2023-02-08 16:44:44.808 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SerialApiGetCapabilities[7], type=Response[1], dest=255, callback=0, payload=07 12 00 00 00 04 00 04 F6 87 3E 88 CF 2B C0 4F FB D7 FD E0 17 00 00 80 00 80 86 80 BA 05 00 70 00 00 EE 7F C0 00 00 00
2023-02-08 16:44:44.809 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 2: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2023-02-08 16:44:44.810 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2023-02-08 16:44:44.810 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 2: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2023-02-08 16:44:44.812 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SerialApiGetCapabilities[7], type=Response[1], dest=255, callback=0, payload=07 12 00 00 00 04 00 04 F6 87 3E 88 CF 2B C0 4F FB D7 FD E0 17 00 00 80 00 80 86 80 BA 05 00 70 00 00 EE 7F C0 00 00 00
2023-02-08 16:44:44.813 [DEBUG] [SerialApiGetCapabilitiesMessageClass] - API Version = 7.18
2023-02-08 16:44:44.814 [DEBUG] [SerialApiGetCapabilitiesMessageClass] - Manufacture ID = 0x0
2023-02-08 16:44:44.814 [DEBUG] [SerialApiGetCapabilitiesMessageClass] - Device Type = 0x4
2023-02-08 16:44:44.815 [DEBUG] [SerialApiGetCapabilitiesMessageClass] - Device ID = 0x4
2023-02-08 16:44:44.816 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 2: Transaction COMPLETED
Thanks for your reply.
Its a armv71 system. Newly created SD-Card with RasPi Imager. Only serial port adaptations done prior to running system test. Hardware is 3B+, but don’t think that explains why mine is not working and yours does.
Did you generate your system image with RasPi Imager as well or with a different method ?
To run the razberry on my Pi4B with bookworm, it was necessary to stop the agetty on /dev/ttyAMA0
#stop agetty on /dev/ttyAMA0
sudo systemctl disable serial-getty@ttyAMA0
sudo systemctl stop serial-getty@ttyAMA0
sudo systemctl mask serial-getty@ttyAMA0
Thanks for the hint, found the issue alkready upfront and had it disabled. Otherwise it would have shown up in the error message.
edgar@raspberrypi:~ $ sudo systemctl status serial-getty@ttyAMA0
○ serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; prese>
Active: inactive (dead)
Docs: man:agetty(8)
man:systemd-getty-generator(8)
systemd for Administrators, Part XVI
only disable and stop was not working on my system. In addition I needed to mask the service on my system to get the razberry running.
sudo systemctl mask serial-getty@ttyAMA0
Thanks for the hint. Have tried, but wasn’t successfull. Masking kills the serial interface (/dev/Null) with the effect that it can’t be started later on. Assume you have been doing something else to make sure the service works afterwards - appreciate more details about the additional activities.
Below logs with masked service - serial interface not available.
[2024-12-23 11:27:48.709] [D] [zway] [73] “ZMESerialAPIOptions”
[2024-12-23 11:27:48.709] [C] [i/o] Failed to open device /dev/ttyAMA0: No such file or directory
[2024-12-23 11:27:48.709] [D] [i/o] Closing port
[2024-12-23 11:27:48.709] [I] [zway] SaveData will not save data since it wasn’t loaded. This is to prevent data loss.
[2024-12-23 11:27:48.726] [I] [core] Error: Invalid port
right, also changed the file "/boot/firmware/config.txt
[all]
gpu_mem=16
dtparam=i2c_arm=on
dtparam=i2c1=on
enable_uart=1
#dtoverlay=miniuart-bt
dtoverlay=disable-bt
max_framebuffers=0
Recently did a fresh O/S install with the rpi imager
Linux raspberrypi3 6.6.62+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.62-1+rpt1 (2024-11-25) armv7l
Haven’t done anything special, but OH is running in a container with
devices:
- '/dev/serial/by-id/usb-0658_0200-if00'
Thanks a lot, that solved it. Works now.
Not sure whether I understand why, but doesnt matter.
Very valuable support.