search

jens-maus / RaspberryMatic

:house: A feature-rich but lightweight, buildroot-based Linux operating system alternative for your CloudFree CCU3/ELV-Charly 'homematicIP CCU' IoT smarthome central. Running as a pure virtual appliance (ProxmoxVE, Home Assistant, LXC, Docker/OCI, Kubernetes/K8s, etc.) on a dedicated embedded device (RaspberryPi, etc.) or generic x86/ARM hardware.
https://raspberrymatic.de
Apache License 2.0
1.55k stars 192 forks source link

HmIP-RFUSB docker log shows "Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>2.8.6, ERROR ( != 2.8.6)" #1516

Closed nobodyman1 closed 2 years ago

nobodyman1 commented 3 years ago

Describe the issue you are experiencing

After starting the container the docker log shows an error: Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>2.8.6, ERROR ( != 2.8.6)

Describe the behavior you expected

I don´t expect any error message.

Steps to reproduce the issue

docker run -d --name ccu \
  -v ccu_data:/usr/local:rw -v /lib/modules:/lib/modules:ro \
  -v /run/udev/control:/run/udev/control \
  -p 8080:80 -p 2001:2001 -p 2010:2010 -p 9292:9292 -p 8181:8181 \
  --privileged --stop-timeout 30 \
  --hostname homematic-raspi ghcr.io/jens-maus/raspberrymatic:latest

What is the version this bug report is based on?

3.59.6.20211009 3.61.5.20211113

Which base platform are you running?

rpi4 (RaspberryPi4)

Which HomeMatic/homematicIP radio module are you using?

HmIP-RFUSB

Anything in the logs that might be useful for us?

No.

Additional information

No response

jens-maus commented 2 years ago

Please show the output of the following commands within the RaspberryMatic container:

lsusb

cat /var/hm_mode

nobodyman1 commented 2 years ago 
/ # lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 002: ID 2109:3431
Bus 002 Device 001: ID 1d6b:0003
Bus 001 Device 003: ID 1b1f:c020
/ # cat /var/hm_mode
HM_HMIP_ADDRESS='0xBC0553'
HM_HMIP_ADDRESS_ACTIVE='0xBC0553'
HM_HMIP_DEV='HMIP-RFUSB'
HM_HMIP_DEVNODE='/dev/ttyUSB0'
HM_HMIP_DEVTYPE='USB'
HM_HMIP_SERIAL='xxxxxx'
HM_HMIP_SGTIN='xxxxxxxxxxxxxxxxxxxxxxxx'
HM_HMIP_VERSION=''
HM_HMRF_ADDRESS=''
HM_HMRF_ADDRESS_ACTIVE='0x6D08C0'
HM_HMRF_DEV=''
HM_HMRF_DEVNODE=''
HM_HMRF_DEVTYPE=''
HM_HMRF_SERIAL=''
HM_HMRF_VERSION=''
HM_HOST='oci'
HM_LED_GREEN=''
HM_LED_GREEN_MODE1='mmc0'
HM_LED_GREEN_MODE2='heartbeat'
HM_LED_RED=''
HM_LED_RED_MODE1='timer'
HM_LED_RED_MODE2='mmc0'
HM_LED_YELLOW=''
HM_LED_YELLOW_MODE1='none'
HM_LED_YELLOW_MODE2='none'
HM_MODE='NORMAL'
HM_RTC=''
HM_SUPERVISOR_TOKEN=''
jens-maus commented 2 years ago

Thanks. And now please show the FULL output of the following command:

detect_radio_module /dev/ttyUSB0
nobodyman1 commented 2 years ago 
/ # detect_radio_module /dev/ttyUSB0
HmIP-RFUSB <HM_HMIP_SERIAL> <HM_HMIP_SGTIN> 0x000000 0xBC0553 4.2.14
jens-maus commented 2 years ago 
/ # detect_radio_module /dev/ttyUSB0
HmIP-RFUSB <HM_HMIP_SERIAL> <HM_HMIP_SGTIN> 0x000000 0xBC0553 4.2.14

Please reveal the full data here because the SERIAL+SGTIN could reveal additional information on the actual hardware type of HmIP-RFUSB you are using.

The strange thing here is, that your HmIP-RFUSB is showing a firmware version 4.2.14 which does not exist for a HmIP-RFUSB device, AFAIK. Where did you buy this HmIP-RFUSB from? Perhaps @alexreinert has an idea how it could happen that a HmIP-RFUSB has a firmware version > 2.8.6 (which is the latest known one). Does this HmIP-RFUSB actually work at all in the RaspberryMatic system?!?

bambuleee commented 2 years ago

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

nobodyman1 commented 2 years ago

The parts HM_HMIP_SERIAL and HM_HMIP_SGTIN are exactly the same as shown in /var/hm_mode, you could believe me. The HmIP-RFUSB is from ELV. Yes, the HmIP-RFUSB is working with the current version.

nobodyman1 commented 2 years ago

Sorry, I hit the wrong button.

jens-maus commented 2 years ago

The parts HM_HMIP_SERIAL and HM_HMIP_SGTIN are exactly the same as shown in /var/hm_mode, you could believe me.

I believe you, but the SGTIN pattern could actually help to identify if this is a new hardware generation of these sticks or see a pattern. So please reveal them.

The HmIP-RFUSB is from ELV. Yes, the HmIP-RFUSB is working with the current version.

So only the Firmware-Update process is outputting an error, right? Apart from that the stick is working? And which firmware version of the Stick is shown if you go to the device settings of the HmIP-RFUSB device in the WebUI?

jens-maus commented 2 years ago

@bambuleee

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

@nobodyman1 is reporting that his stick is working correctly and only the firmware update process is outputting an error. And please state which hardware you are using with the HmIP-RFUSB? RaspberryPi?

bambuleee commented 2 years ago

I tried a VM on vmware and docker. Where can I find the device settings you mentioned above? I can't find the stick in the WebUI

jens-maus commented 2 years ago

I tried a VM on vmware and docker. Where can I find the device settings you mentioned above? I can't find the stick in the WebUI

I could be wrong. Usually only a RPI-RF-MOD is showing up in the WebUI as a dedicated device in the device list from which you can read the firmware version as well. However, then please execute the same command in a SSH session like I stated above:

detect_radio_module /dev/ttyUSB0

The should output all necessary information including the current firmware version of the stick.

bambuleee commented 2 years ago

detect_radio_module /dev/ttyUSB0 HmIP-RFUSB 1D899715AC 3014F711A000041D899715AC 0x000000 0x19BD76 4.2.14

alexreinert commented 2 years ago

Can you please provide the output of detect_radio_module --debug /dev/ttyUSB0?

bambuleee commented 2 years ago

/ # detect_radio_module --debug /dev/ttyUSB0 Sending HM frame: fd 00 03 fe 00 01 14 1e Received HM frame: fd 00 11 fe 00 05 01 44 75 61 6c 43 6f 50 72 6f 5f 41 70 70 a2 21 Sending HM frame: fd 00 03 fe 01 02 92 17 Received HM frame: fd 00 04 fe 01 05 01 07 02 Received HM frame: fd 00 0e fe 00 00 48 4d 49 50 5f 54 52 58 5f 42 6c f4 c2 Sending HM frame: fd 00 03 fe 02 01 98 1d Received HM frame: fd 00 0f fe 02 05 01 48 4d 49 50 5f 54 52 58 5f 42 6c ea c6 Sending HM frame: fd 00 03 fe 03 03 9e 11 Received HM frame: fd 00 04 fe 03 05 01 87 29 Received HM frame: fd 00 10 fe 01 00 44 75 61 6c 43 6f 50 72 6f 5f 41 70 70 b7 36 Sending HM frame: fd 00 03 01 04 09 00 22 Received HM frame: fd 00 05 01 04 04 01 01 16 28 Sending HM frame: fd 00 03 01 05 02 06 18 Received HM frame: fd 00 0d 01 05 04 01 04 02 0e 01 00 18 01 36 00 1f 9a Sending HM frame: fd 00 03 02 06 01 0c 2e Received HM frame: fd 00 07 02 06 06 01 11 d8 b6 75 c4 Sending HM frame: fd 00 03 fe 07 04 86 03 Received HM frame: fd 00 10 fe 07 05 01 30 14 f7 11 a0 00 04 1d 89 97 15 ac f5 2a HmIP-RFUSB 1D899715AC 3014F711A000041D899715AC 0x000000 0x11D8B6 4.2.14

nobodyman1 commented 2 years ago

@bambuleee

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

@nobodyman1 is reporting that his stick is working correctly and only the firmware update process is outputting an error. And please state which hardware you are using with the HmIP-RFUSB? RaspberryPi?

My HmIP-RFUSB is working. I have paired one HmIP-eTRV-2 successfully. The HmIP-RFUSB is connected to a Raspberry Pi 4 Model B.

nobodyman1 commented 2 years ago

/ # detect_radio_module --debug /dev/ttyUSB0 Sending HM frame: fd 00 03 fe 00 01 14 1e Received HM frame: fd 00 11 fe 00 05 01 44 75 61 6c 43 6f 50 72 6f 5f 41 70 70 a2 21 Sending HM frame: fd 00 03 fe 01 02 92 17 Received HM frame: fd 00 04 fe 01 05 01 07 02 Received HM frame: fd 00 0e fe 00 00 48 4d 49 50 5f 54 52 58 5f 42 6c f4 c2 Sending HM frame: fd 00 03 fe 02 01 98 1d Received HM frame: fd 00 0f fe 02 05 01 48 4d 49 50 5f 54 52 58 5f 42 6c ea c6 Sending HM frame: fd 00 03 fe 03 03 9e 11 Received HM frame: fd 00 04 fe 03 05 01 87 29 Received HM frame: fd 00 10 fe 01 00 44 75 61 6c 43 6f 50 72 6f 5f 41 70 70 b7 36 Sending HM frame: fd 00 03 01 04 09 00 22 Received HM frame: fd 00 05 01 04 04 01 01 16 28 Sending HM frame: fd 00 03 01 05 02 06 18 Received HM frame: fd 00 0d 01 05 04 01 04 02 0e 01 00 18 01 36 00 1f 9a Sending HM frame: fd 00 03 02 06 01 0c 2e Received HM frame: fd 00 07 02 06 06 01 11 d8 b6 75 c4 Sending HM frame: fd 00 03 fe 07 04 86 03 Received HM frame: fd 00 10 fe 07 05 01 30 14 f7 11 a0 00 04 1d 89 97 15 ac f5 2a HmIP-RFUSB 1D899715AC 3014F711A000041D899715AC 0x000000 0x11D8B6 4.2.14

My output is nearly the same, except the last two frames. Is there any documentation about this protocol?

alexreinert commented 2 years ago

Debug output of @bambuleee does show, that the HmIP-RFUSB does send the version 4.2.14 (Hex 04 02 0e) in the frame data. I see two options: eQ-3 has a new firmware, which is programmed to the stick in production or something wrote the RPI-RF-MOD firmware to the stick. My guess would be the first option.

@nobodyman1 Giving just breadcrumbs instead of full info is not very helpful.

nobodyman1 commented 2 years ago

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

How did you try to pair the device? I only set the KEY and SGTIN.

bambuleee commented 2 years ago

Debug output of @bambuleee does show, that the HmIP-RFUSB does send the version 4.2.14 (Hex 04 02 0e) in the frame data. I see two options: eQ-3 has a new firmware, which is programmed to the stick in production or something wrote the RPI-RF-MOD firmware to the stick. My guess would be the first option.

@nobodyman1 Giving just breadcrumbs instead of full info is not very helpful.

So my only option to get it running is to send it back and get a new one? Or can it be a fault my side during assambly?

bambuleee commented 2 years ago

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

How did you try to pair the device? I only set the KEY and SGTIN.

Tried both ways.

nobodyman1 commented 2 years ago

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

How did you try to pair the device? I only set the KEY and SGTIN.

Tried both ways.

What do mean with "both ways"?

jens-maus commented 2 years ago

I see two options: eQ-3 has a new firmware, which is programmed to the stick in production or something wrote the RPI-RF-MOD firmware to the stick. My guess would be the first option.

That would then perhaps mean that this is potentially a new dualcopro firmware for the HmIP-RFUSB and thus would mean it should alsosupport the old BidCos-RF protocol, I guess. Interesting.

bambuleee commented 2 years ago

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

How did you try to pair the device? I only set the KEY and SGTIN.

Tried both ways.

What do mean with "both ways"?

The online automatic way and with adding KEY and SGTIN

alexreinert commented 2 years ago

That would then perhaps mean that this is potentially a new dualcopro firmware for the HmIP-RFUSB and thus would mean it should alsosupport the old BidCos-RF protocol, I guess. Interesting.

That could be possible, if you look at the first Frame, the stick identifies as "DualCoPro_App". The big question: Was the firmware programmed by purpose and if yes: Where to get it for older sticks and are there any limitations in comparison to the RPI-RF-MOD.

I ordered a stick today and will do some additional tests.

Maybe eQ-3 wants to contact me, if this was done by purpose, it would be nice to talk about it, to add some official support to my generic-raw-uart kernel modules, without that support it would be not possible to use the stick in Dual mode because of the timing requirements and the ioctl's required by multimacd.

jens-maus commented 2 years ago

@alexreinert

Maybe eQ-3 wants to contact me, if this was done by purpose, it would be nice to talk about it, to add some official support to my generic-raw-uart kernel modules, without that support it would be not possible to use the stick in Dual mode because of the timing requirements and the ioctl's required by multimacd.

Ok, I contacted my eQ3 contact and he checked with the responsible developers of the HmIP-RFUSB and got confirmation that there is indeed a new 4.x.x firmware for the HmIP-RFUSB. He said that he will try to put up the new 4.x.x firmware to OCCU during the next days.

However, please note, that the firmware bump to 4.x was intentionally not made to introduce old BidCos-RF/HomeMatic support, but to get the stick a more modern HmIP compatibility for testing and use with the advanced HmIP routing capabilities which was introduced with the 4.x.x firmware line like the one the RPI-RF-MOD received. Nevertheless, there might actually be chances (since this firmware is also a similar DualCoPro firmware like the one for the RPI-RF-MOD) that we/you can get BidCos-RF running for this stick, indeed. But what I don't know or even doubt is, if eQ3 has any own interest in getting BidCos-RF running for this stick. Thus, we could be on our own to get it running with your generic_raw_uart kernel drivers in the end, but I will try to discuss this with eQ3 again ASAP. Nevertheless, be prepared that the new 4.x.x firmware for the RFUSB will show up in OCCU shortly ;)

BTW Here it was committed now: https://github.com/eq-3/occu/commit/fd79d119f32748ec104674c7f9a49a3bf1eea64b

alexreinert commented 2 years ago

Hopefully I get a new HmIP-RFUSB today (package is currently in the car of the delivery service). I will try to get it working with the generic-raw-uart modules, but even if I get it working, I would not release until I have the official permission of eQ-3 to add there USB-ID to the kernel modules. For the time being: There were some checks in the WebUI for the HAP inclussion, which just checked the firmware version without the check for the radio module type. I'm not sure, if they still exist.

jens-maus commented 2 years ago

Hopefully I get a new HmIP-RFUSB today (package is currently in the car of the delivery service). I will try to get it working with the generic-raw-uart modules, but even if I get it working, I would not release until I have the official permission of eQ-3 to add there USB-ID to the kernel modules.

I think this this should be no problem to get this permission. But for the time being I think we should concentrate on getting this new firmware integrated and potentially working with your generic_raw_uart. Thus, if you have a potential prototype, let me know so that I can test it here as well.

For the time being: There were some checks in the WebUI for the HAP inclussion, which just checked the firmware version without the check for the radio module type. I'm not sure, if they still exist.

Good to know, where exactly should that check be?

jens-maus commented 2 years ago

Please note that I will close this ticket since the issue described here had been fixed with 33ba700. So the next release should be able to correctly upgrade or downgrade a firmware version for the RFUSB again.

ciB89 commented 2 years ago

I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.

How did you try to pair the device? I only set the KEY and SGTIN.

Tried both ways.

What do mean with "both ways"?

The online automatic way and with adding KEY and SGTIN

Did you get it to work? Mine also does not find any devices..

a-marcel commented 2 years ago

I've the same problem, but like Jens wrote: It looks like we need to wait till the next release in december..

bambuleee commented 2 years ago

He just wrote that firmware up and downgrading will work. Pairing devices should work today ... correct?

jens-maus commented 2 years ago

Yes, it should work with the latest nightly snapshot build. And if pairing does still not work you have some other issues that prevents the pairing.

bambuleee commented 2 years ago

So pairing will also work with the latest snapshot? Or also with current stabelrelease?

ciB89 commented 2 years ago

I have tested it with the stable build and it would not find my valve - although it was sitting in the room next to it, so maybe range issues? But if the stick has such a limited range it's a waste of money??

jens-maus commented 2 years ago

This is no discussion fora here. Keep on track of the issue content, please. All I can say is, that this stick works, but you have to make sure to bring it far enough away from e.g. a RaspberryPi which is known to cause severe RF interferences.

a-marcel commented 2 years ago

Hello,

i checked my device with the snapshot Version 3.61.5.20211128-37aa4ba and get a similar but different error message now:

Identifying Homematic RF-Hardware: ....HmRF: none, HmIP: HMIP-RFUSB/USB, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>4.4.8, ERROR ( != 4.4.8)

Registering new devices is possible without problems. 

/ # dmesg
[45607.721358] usb 1-1.4: new full-speed USB device number 4 using xhci_hcd
[45607.826758] usb 1-1.4: New USB device found, idVendor=1b1f, idProduct=c020, bcdDevice= 1.00
[45607.826785] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[45607.826801] usb 1-1.4: Product: eQ-3 HmIP-RFUSB
[45607.826816] usb 1-1.4: Manufacturer: Silicon Labs
[45607.826831] usb 1-1.4: SerialNumber: <SerialNumber>
[45607.850361] cp210x 1-1.4:1.0: cp210x converter detected
[45607.858562] usb 1-1.4: cp210x converter now attached to ttyUSB1
/ # lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 10c4:ea60
Bus 001 Device 002: ID 2109:3431
Bus 002 Device 002: ID 174c:0857
Bus 002 Device 001: ID 1d6b:0003
Bus 001 Device 004: ID 1b1f:c020
/ # cat /var/hm_mode
HM_HAPROXY_SRC='172.30.32.2/32'
HM_HMIP_ADDRESS='0xB13590'
HM_HMIP_ADDRESS_ACTIVE='0xB13590'
HM_HMIP_DEV='HMIP-RFUSB'
HM_HMIP_DEVNODE='/dev/ttyUSB1'
HM_HMIP_DEVTYPE='USB'
HM_HMIP_SERIAL='1D8992663C'
HM_HMIP_SGTIN='<SerialNumber>'
HM_HMIP_VERSION=''
HM_HMRF_ADDRESS=''
HM_HMRF_ADDRESS_ACTIVE=''
HM_HMRF_DEV=''
HM_HMRF_DEVNODE=''
HM_HMRF_DEVTYPE=''
HM_HMRF_SERIAL=''
HM_HMRF_VERSION=''
HM_HOST='oci'
HM_LED_GREEN=''
HM_LED_GREEN_MODE1='mmc0'
HM_LED_GREEN_MODE2='heartbeat'
HM_LED_RED=''
HM_LED_RED_MODE1='timer'
HM_LED_RED_MODE2='mmc0'
HM_LED_YELLOW=''
HM_LED_YELLOW_MODE1='none'
HM_LED_YELLOW_MODE2='none'
HM_MODE='NORMAL'
HM_RTC=''
HM_RUNNING_IN_HA='1'
HM_SUPERVISOR_TOKEN='<Token>'
/ # detect_radio_module /dev/ttyUSB1
HmIP-RFUSB 1D8992663C <SerialNumber> 0x000000 0xBEF0EA 4.2.14

Should i open for this a new thread or is this issue related to this one ?

Thanks a lot

jens-maus commented 2 years ago

@a-marcel Please reveal the first 6 digits of the SGTIN found in /var/hm_mode. If it starts with 3014F5xxxxx then this is a HmIP-RFUSB-TK from Telekom for which the eQ3 supplied 4.4.x firmware does not apply (it requires the original ELV HmIP-RFUSB).

a-marcel commented 2 years ago

Thanks for the quick answer. Yes the SGTIN starts with 3014F5. I ordered a "non telekom" from amazon, but the package i got was branded with the telekom logo and color. Does this stick has any negative impact / disadvantages ? I only plan to use Homematic IP devices in my smart home. Thanks a lot.

jens-maus commented 2 years ago

Does this stick has any negative impact / disadvantages ? I only plan to use Homematic IP devices in my smart home. Thanks a lot.

The only currently known disadvantage is, that we don't have any newer 4.4.x firmware for this special TK version of the HmIP-RFUSB-TK which comes with improved HmIP Advanced Routing capabilities regarding HmIP-HAP/DRAP connectivity. Apart from that the stick should (hopefully) work the same like the non-TK version.

ciB89 commented 2 years ago

@a-marcel Please reveal the first 6 digits of the SGTIN found in /var/hm_mode. If it starts with 3014F5xxxxx then this is a HmIP-RFUSB-TK from Telekom for which the eQ3 supplied 4.4.x firmware does not apply (it requires the original ELV HmIP-RFUSB).

Mine starts with 3014F7*** but yet I get the exact same error as @a-marcel

jens-maus commented 2 years ago

Mine starts with 3014F7*** but yet I get the exact same error as @a-marcel

But not with the latest nightly snapshot build, I guess! Keep in mind: this issue/ticket has just been fixed and will be integrated with the next stable version.

ciB89 commented 2 years ago

Well, I using the latest snapshot from the addon store (3.61.5.20211128-37aa4ba) which should have the fix included, right?

jens-maus commented 2 years ago

Yes, it should. The ELV version of the HmIP-RFUSB starts with a SGTIN of 3014F711xxxxx. Thus, if your stick starts with such a SGTIN it should perfectly flash the 4.4.x firmware upon startup of the latest nightly snapshot.

nopeee535 commented 2 years ago

Hey guys, i got the same problem. after changing to snapshot the update failed : Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>4.4.8, ERROR ( != 4.4.8)

now my docker container will not find the usb stick ... the System still have it:

root@nuc-srv:/opt/docker/homematic# ll /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 Nov 30 16:31 ./
drwxr-xr-x 4 root root 80 Nov 30 16:31 ../
lrwxrwxrwx 1 root root 13 Nov 30 16:36 usb-Silicon_Labs_eQ-3_HmIP-RFUSB_3014F711A000041D89971510-if00-port0 -> ../../ttyUSB0

here the log output:

ccu               | Identifying Homematic RF-Hardware: ...HmRF: none, HmIP: none, OK
ccu               | Updating Homematic RF-Hardware: no GPIO/USB connected RF-hardware found

i tried both images (snapshot and latest) with the same result. any ideas? thanks

ciB89 commented 2 years ago

Hey guys, i got the same problem. after changing to snapshot the update failed : Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>4.4.8, ERROR ( != 4.4.8)

now my docker container will not find the usb stick ... the System still have it:

root@nuc-srv:/opt/docker/homematic# ll /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 Nov 30 16:31 ./
drwxr-xr-x 4 root root 80 Nov 30 16:31 ../
lrwxrwxrwx 1 root root 13 Nov 30 16:36 usb-Silicon_Labs_eQ-3_HmIP-RFUSB_3014F711A000041D89971510-if00-port0 -> ../../ttyUSB0

here the log output:

ccu               | Identifying Homematic RF-Hardware: ...HmRF: none, HmIP: none, OK
ccu               | Updating Homematic RF-Hardware: no GPIO/USB connected RF-hardware found

i tried both images (snapshot and latest) with the same result. any ideas? thanks

I got exactly the same issue now.

jens-maus commented 2 years ago

Did you guys try to completly unplug/replig the rfusb to see if it comes back in RM after restarting the container?

ciB89 commented 2 years ago

Did you guys try to completly unplug/replig the rfusb to see if it comes back in RM after restarting the container?

Yes, that's the first I tried. I even rebooted the pi completely - no luck.

radio_module /dev/ttyUSB1
Error: Radio module was not detected
nopeee535 commented 2 years ago

yes, i changed the usb-port ... but the same chmod 777 /dev/ttyUSB0 does not help

i also tried to link the device directly in my compose file (without success) :

 21   ¦ devices:
 22   ¦ ¦ - "/dev/ttyUSB0:/dev/ttyUSB0"

maybe the update crashed the stick ? is there a way to test the stick ?

jens-maus commented 2 years ago

Hmm, then try to plug it in your laptop and see if it is recognized or shown there as a HmIP-RFUSB. If not, it might have been bricked. Perhaps @alexreinert has some idea what else to try to get it working again.