RaspberryMatic: HmIP-RFUSB docker log shows "Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>2.8.6, ERROR ( != 2.8.6)"
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
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 107 (43 by maintainers)
Commits related to this issue
- fixed a bug in the firmware update routine for a HmIP-RFUSB where an incorrect variable was used, thus a firmware update always failed. This refs #1516. — committed to jens-maus/RaspberryMatic by jens-maus 3 years ago
- Merge branch 'master' of https://github.com/jens-maus/RaspberryMatic * 'master' of https://github.com/jens-maus/RaspberryMatic: updated monit to latest 5.29.0 and updated the configure patch accord... — committed to jp112sdl/RaspberryMatic by jp112sdl 3 years ago
- use /firmware/HmIP-RFUSB as the firmware path for HmIP-RFUSB firmware updates which will promoto the 4.2.14 firmware for the time being. This refs #1516. — committed to jens-maus/RaspberryMatic by jens-maus 3 years ago
My test are showing the same, I can update the old sticks as well as the new sticks and both types switch into App Mode afterwards and are fully detected by the detect-radio-module tool and the HMIPServer.
Hi all, as eQ3 just released a new potentially fixed 4.4.16 firmware for the HmIP-RFUSB (cf. https://github.com/eq-3/occu/commit/a2641df55cdde81239bbdbe7cf4dbcd4e3e62c5b), I retested the upgrade/downgrade procedures again. See here:
Firmware Upgrade 4.2.14->4.4.16 with older device bootloader (1.0.11):
Firmware Upgrade 4.2.14->4.4.16 with latest device bootloader (1.0.24):
So, voila. The issue with 4.4.x firmwares and newer device bootloader versions some users here (and myself) were facing seem to be fixed with the 4.4.16 HmIP-RFUSB firmware. In addition, this is now the latest/newest firmware available for the RFUSB stick series ATM with all Advanced HmIP Routing features included.
Next will be that I integrate this new firmware in the next nightly snapshot and then you all can (re-)test it again with your various HmIP-RFUSB use-cases and then provide some feedback here or even reopen the issue ticket in case the issue isn’t fixed or the new 4.4.16 firmware is not working as expected in your environment.
Definitely! Just let me know and I will try to integrate it ASAP.
Win11 find it : eQ-3 HmIP-RFUSB
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.
Well, if you use the home assistant addon under HAos you will have to wait until a new HAos version will be released somewhat in the future with the newer generic_raw_uart version supporting the HmIP-RFUSB. And if you are purely using the docker/OCI version you will have to wait for @alexreinert to publish new pivccu kernel modules, indeed.
Ok, now I retested the firmware update/downgrade between 4.2.14 <> 4.4.8 and vice verse with different platforms (ova and rpi3) with the three different HmIP-RFUSB sticks I have here at home. And what should I say, I could finally reproduce the issue here with two of my RFUSB sticks. Funny enough, with one of the RFUSB the firmware update/downgrade between 4.2.14<>4.4.8 always works as expected and that was actually the stick I initially used to test my integration.
See here the output of the successful 4.2.14 -> 4.4.8 update:
And here the output of the unsuccessful update:
If you look close and compare the output, the only relevant difference (apart from the error) is the difference between:
vs.
So it seems that at least in my environment for HmIP-RFUSB sticks which have a bootloader version of 1.0.24 the firmware update fails indeed. And looking at the other update log outputs above from users which also reported an update failure, these sticks also have a 1.0.24 bootloader. So this actually seems to be a pattern, indeed.
Nevertheless, to me this looks like some potential timing issue related to the bootloader and this
hmip-copro-update.jartool. I already reported this to eQ3, so lets hope they can fix this issue soonish in the update tool or provide a new firmware update or even provide technical details on how to perform this update without this tool so that we could potentially create an own update tool or integrate update routines indetect_radio_module, etc.So until this issue is resolved, I will roll back to only provide the 4.2.14 update per default and hope eQ3 can provide a fix soon.
Not really, it is my development system, where I develop and test the required changes for the raw uart kernel modules, the detect-radio-module tool and so on. Once the development is finished, I’m pretty sure that Jens will update to them.
Hello, I got a new stick from ELV, too. Pairing doesn’t work.
I installed “RaspberryMatic-3.61.5.20211113.ova” at proxmox (on my deskmini dmaf5). Installation works fine.
I get following error: Updating Homematic RF-Hardware: …HMRF: none, HmIP: HMIP-RFUSB/USB, OK Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>2.8.6, ERROR ( != 2.8.6)
other informations: 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 b2 6b a0 d7 06 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 12 f6 ae HmIP-RFUSB 1D899XXXXX 3014F711A000041DXXXXXXXX 0x000000 0xXXXXXX 4.2.14
lsusb Bus 003 Device 001: ID 1d6b:0003 Bus 002 Device 002: ID 1b1f:c020 Bus 001 Device 001: ID 1d6b:0001 Bus 001 Device 002: ID 0627:0001 Bus 002 Device 001: ID 1d6b:0002
cat /var/hm_mode HM_HMIP_ADDRESS=‘0xB26BA0’ HM_HMIP_ADDRESS_ACTIVE=‘0xB26BA0’ HM_HMIP_DEV=‘HMIP-RFUSB’ HM_HMIP_DEVNODE=‘/dev/ttyUSB0’ HM_HMIP_DEVTYPE=‘USB’ HM_HMIP_SERIAL=‘1D899XXXXX’ HM_HMIP_SGTIN=‘3014F711A000041DXXXXXXXX’ 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=‘ova-KVM’ HM_LED_GREEN=‘’ HM_LED_GREEN_MODE1=‘none’ HM_LED_GREEN_MODE2=‘heartbeat’ HM_LED_RED=‘’ HM_LED_RED_MODE1=‘timer’ HM_LED_RED_MODE2=‘none’ HM_LED_YELLOW=‘’ HM_LED_YELLOW_MODE1=‘none’ HM_LED_YELLOW_MODE2=‘none’ HM_MODE=‘NORMAL’ HM_RTC=‘onboard’
@jens-maus Could you please reopen the issue? I think this issue is not finished!
One remark: I am using the short usb extension cable which belongs to the HMIP-RFUSB and I soldered an external antenna to the module. Might this be the difference if pairing works or not (if the HMIP-RFUSB is correctly recognized by the system of course)?
oh je 😦 i copied the jar out of the container and did the following :
testing:
factory reset:
im not sure if i did everything right but this looks not good …
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.
@alexreinert
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
I received my stick today. Same error. I bought it from ELV. Also pairing is not working for the device I also bought there.