RaspberryMatic as a Home Assistant OS (in VMware Workstation Player) Add-on and HmIP-RFUSB on Windows

[ericleigh007]

Hey, and thanks for creating all this wonderful software. I'm looking forward to using it.

I'm trying to get the configuration shown in the Title to work on Windows, and I'm not sure how to get the Docker contains containing the RaspberryMatic CCU Add-in for Home Assistant to see the USB device I have plugged into my Windows Hardware.

I have previously plugged in the device on my Windows hardware, and then in VMWare Workstation Player, have taken control of the device in the Settings. My VM's settings are set to USB 2.0.

So now my VM sees the USB device. How does the docker container with RM in it see the device? or should that "just work"?

I'm asking here because after doing some pretty exhaustive searches, I have not found an answer. If it turns out there is no direct answer to that question, it seems that an article should be written to troubleshoot the event should it happen, and add a link to that in the RM Add-in installation for Home Assistant.

I have seen some articles on the RPi4 installation for the HmIP-RFUSB, but that obviously isn't the same thing as the RM within the docker container within the VM environment I'm using.

Sorry if this is already answered, but my web search prowess has failed me ;)

[ericleigh007]

The answer is "if the guest OS on the VM has access to the USB device(s) on the host, it should just work.

I did simple lsusb commands to see if the device was recognized, using the SSH and terminal add-in. On the SSH container, the lsusb DID show the USB device, 1B1F:c020, so my assumption that the device was not getting to the container turned out to be false.

lsusb
Bus 002 Device 005:  ID 1b1f:c020

It looks like when I disabled protection for the RM add-on, it started working. (note I have not double-checked this, but I don't remember doing anything else). Now I have this in my startup log:

Identifying Homematic RF-Hardware: ....HmRF: none, HmIP: HMIP-RFUSB/USB, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 4.2.14=>4.4.16, OK

But everytime the VM reboots, one has to manually reconnect the USB device.

In the .vmx file for the VM (in my case ha.vmx), I added this line:

usb.autoConnect.device0 = "0x1B1F:0xC020"

So now the VM guest OS connects to the USB device and removes it from the host on each boot.

Next, seeing an incredibly long pause during the startup of the VM, I decided I should change the boot order on the VM.
To do this, just after starting the VM from the player, click on its screen and press F2 (as many times as it takes).
The required procedure for changing the boot order follows here.

This considerably sped up the boot of my VM.

I'll report back any further progress.

[jens-maus]

But everytime the VM reboots, one has to manually reconnect the USB device.

In the .vmx file for the VM (in my case ha.vmx), I added this line: usb.autoConnect.device0 = "0x1B1F:0xC020"

So now the VM guest OS connects to the USB device and removes it from the host on each boot.

To me this reads like a limitation / issue in VMware Workstation Player rather than something in RaspberryMatic itself. IMHO it is anyway highly questionable to use a Windows host as a virtualization platform. Better use something like Proxmox VE on your host system and then run your windows as a VM within Proxmox as well as RaspberryMatic and Home Assistant. That would be a way better sustainable solution than using Windows as the virtualization host.

[ericleigh007]

Understood. Is there a test on any platform that will test the RFUSB stick’s RF operation, in order to verify it was assembled successfully? Thanks!

[jens-maus]

Understood. Is there a test on any platform that will test the RFUSB stick’s RF operation, in order to verify it was assembled successfully?

Simply boot into RaspberryMatic with the HmIP-RFUSB attached and if the HomeMatic and homematicIP teach-in mode starts to count down, then the RF module works as expected. Furthermore, you can have a look into the Help page in the WebUI. There you will find detailed technical information also on the connected/used RF module and if there it shows up the HmIP-RFUSB everything is fine.

[ericleigh007]

If I could have one more second… The RFUSB is in two parts and has to be assembled. The part that is connected to the USB connector is working, that’s for sure, but I don’t think anything you mentioned proves the RF section is working. From what I understand (and please correct), if the RF section isn’t working, then the teach-in mode will just count down and, receiving no signal from the device, it will time out. It is this hypothetical mode I think I’m in now, so that’s why I’m looking specifically for an RF test. I do know my devices are fine because they are currently being used in HomeAssistant and Smartha app, etc, using the gateway. I’m just trying to transition to RaspberryMatic. Is there a debug flag I can turn on that will maybe show the packets to-from the device?

[ericleigh007]

Okay, I just checked this morning, and I am getting CarrierSense of 14%. I assume that's from my access hub, as that is till in operation during this transition. One would surmise then, the RFUSB is working.

However, strangely, I have tried to teach-in my Radiator Thermostat TRV-B unsuccessfully. I attempted using both KEY, SGTIN, and by using the Device teach-in mode (fully resetting the device and then teaching-in), and received no response.

[jens-maus]

Okay, I just checked this morning, and I am getting CarrierSense of 14%. That should mean the RFUSB is working, but now, why can I not teach in my Radiator Thermostat TRV-B?

Because if you have a constant CarrierSense of 14%. This is way too high. Try to move away the HmIP-RFUSB from your host system using a 1-2 meter USB extension and bring it away of any RF interferences that might be possible because homematicIP does listen-before-talk. That means if there is too much noise on a channel it won't talk at all. Especially RaspberryPi4 system are known to heavily produce 868MHz RF interferences in their near vicinity and I guess your Windows box does as well!

[ericleigh007]

okay, isolated that with the cable that came with the RFUSB module. Not very long, but best I can do for now.

Now I'm getting failure messages spewed to the console. Unfortunately don't know exactly how to copy and paste text, so here is an image.

[jens-maus]

This looks like you are using an older HomeAssistant OS version because of "ttyUSB" mentioned. Please upgrade to HomeAssistantOS 7.3+ and try again.

[ericleigh007]

I'm running homeassistant OS 7.2 which seems to be the latest version posted as a VMWare virtual machine. It just appeared a few days ago.

I'll inquire on their boards if there is a new one and how to get updated.

Otherwise, I'm a bit confused ;)

[jens-maus]

Read/Check again:

https://github.com/home-assistant/operating-system/releases/latest

7.3 is the latest one and definitly required here in the game you are trying to play in here :)

[Baxxy13]

Make a full Backup of your existing HA Configuration via the HA Backup Function.
Set up a new HA-VM with latest 7.3 Image.
Shut down your old HA-VM, boot up your new HA-VM. At the first Screen you can restore your Backup.

Or wait some days till 7.3 arrives the official upgrade channel.

[ericleigh007]

I feel as if some step may have been missed here.
When I did a backup on my old VM, it would seem as if that backup would be on that VM's disk, not the new pristine 7.3 disk.
Wouldn't that be right?

At any rate, i don't see any backup on the new machine that I can restore.

[ericleigh007]

Okay, I got the 7.3 OS up and running, and installed RaspberryMatic.

Again, the add-on's startup log showed no RFUSB hardware until I started it without the protection mode. I seem to recall something about that being normal, or at least something others have had to do.

After turning off the protection mode, the startup log for RaspberryMatic looks good:

Mounting /data as /usr/local (Home Assistant Add-On): OK
Identifying onboard hardware: oci, OK
Initializing RTC Clock: onboard, OK
Running sysctl: OK
Checking for Factory Reset: not required
Checking for Backup Restore: not required
Initializing System: OK
Starting logging: OK
Init onboard LEDs: init, OK
Starting irqbalance: OK
Starting iptables: OK
Starting network: eth0: link up, fixed, firewall, inet up, 172.30.33.2, OK
Identifying Homematic RF-Hardware: ....HmRF: HMIP-RFUSB/eQ-3 HmIP-RFUSB@usb-0000:02:00.0-2.1, HmIP: HMIP-RFUSB/eQ-3 HmIP-RFUSB@usb-0000:02:00.0-2.1, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 4.4.16, OK
Starting hs485dLoader: disabled
Starting xinetd: OK
Starting eq3configd: OK
Starting lighttpd: OK
Starting ser2net: disabled
Starting ssdpd: OK
Starting ha-proxy: OK
Starting NUT services: disabled
Initializing Third-Party Addons: OK
Starting LGWFirmwareUpdate: ...OK
Setting LAN Gateway keys: OK
Starting hs485d: disabled

until this:

Starting multimacd: .....ERROR
Starting rfd: ....................ERROR
Starting HMIPServer: .......................................................................................................................................................ERROR

I would assume this is a problem.

Rest of the startup log:

Starting ReGaHss: .OK
Starting CloudMatic: OK
Starting NeoServer: disabled
Starting Third-Party Addons: OK
Starting crond: OK
Setup onboard LEDs: booted, OK

lsusb shows the device on Bus 002, device 004 as ID 0x1b1f:0xc020, so the add-on does see the hardware.

I'm running with a 1m USB extension, and Carrier Sense is now 0%.

[ericleigh007]

By using the latest snapshot, we get farther, but still cannot teach-in devices.

MountingsMounting /data as /usr/local (Home Assistant Add-On): OK
Identifying onboard hardware: oci, OK
Initializing RTC Clock: onboard, OK
Running sysctl: OK
Checking for Factory Reset: not required
Checking for Backup Restore: not required
Initializing System: OK
Starting logging: OK
Init onboard LEDs: init, OK
Starting irqbalance: OK
Starting iptables: OK
Starting network: eth0: link up, fixed, firewall, inet up, 172.30.33.2, OK
Identifying Homematic RF-Hardware: ....HmRF: HMIP-RFUSB/eQ-3 HmIP-RFUSB@usb-0000:02:00.0-2.1, HmIP: HMIP-RFUSB/eQ-3 HmIP-RFUSB@usb-0000:02:00.0-2.1, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 4.4.16, not necessary, OK
Starting hs485dLoader: disabled
Starting xinetd: OK
Starting eq3configd: OK
Starting lighttpd: creating new SSL cert... OK
Starting ser2net: disabled
Starting ssdpd: OK
Starting ha-proxy: OK
Starting NUT services: disabled
Initializing Third-Party Addons: OK
Starting LGWFirmwareUpdate: ...OK
Setting LAN Gateway keys: OK
Starting hs485d: disabled
Starting multimacd: .OK
Starting rfd: .OK
Starting HMIPServer: ........OK
Starting ReGaHss: .OK
Starting CloudMatic: OK
Starting NeoServer: OK
Starting Third-Party Addons: OK
Starting crond: OK
Setup onboard LEDs: booted, OK
Finished Boot: 3.61.7.20220208 (raspmatic_oci_amd64)

-thanks
-e

[Baxxy13]

I feel as if some step may have been missed here.

My fault. Of course you had to download your generated backup from your old HA-VM. Klicking on the Backup, then on the 3 dots in lower right corner of the popup.

The Errors occurs since version 7.3 of HA-OS. There is an open issue for that. #1707

What kind of devices did you try to teach in? HM or HmIP?

[ericleigh007]

I'm running the snapshot mentioned in that issue after I found it searching for help with the HMIPserver problem the error is gone but I cannot teach in my HmIP radiator thermostat using key and ID it's a TRV-B to be more precise.

[jens-maus]

I'm running the snapshot mentioned in that issue after I found it searching for help with the HMserver problem the error is gone but I cannot teach in my HmIP radiator thermostat using key and ID it's a TRV-B to be more precise.

As said before: If the teach-in mode works and counts down, the RF module works correctly. If then you are unable to teach-in your HomeMatic/homematicIP device, the fault is located either in the way/sequence you are trying to do the teach-in or your RF module ist still located too near to RF interference for working reliably. Go out and get that 1 - 2m USB extension cable to bring the HmIP-RFUSB more far away from your host system or any other technical components that may interference in 868MHz communication. Furthermore, you can try to replace the internal 868MHz antenna of the HmIP-RFUSB with an own antenna (GroundPlane antennas work best). And furthermore you can try to get something like https://de.elv.com/elv-usb-entstoerfilter-usb-ef1-komplettbausatz-152745 which should also help in improving RF communication with a USB device connected.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

BTW: Please stop answering to github Emails directly via your E-mail client. GitHub Tickets/Issues/Discussions should always be answered via its web-page and not via a simple email reply. This just adds unnecessary garbage and SPAM.

[ericleigh007]

Sorry about the email. Was early in the morning and I wasn't thinking about that.
I removed the extra chaff from my earlier comment, and please feel free to edit the above post to remove the offending spam.
I removed the signature from my email as well, so it won't bother anyone again!

[ericleigh007]

Okay, I'm back to this with some new information.
Running as above, using Windows as a Virtualization host, and VMWare Workstation Player 16.1.

We have:
Home Assistant OS 7.4
Core 2022.2.9
Supervisor 2022.01.1
RaspberryMatic 3.61.7.20220115

Check this if it sounds right.
If i start RaspberryMatic add-on with Protection mode on, I get the following log entries, indicating that for some reason, the HmIP-RFUSB is not valid, or not found.

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

Things work as expected ONLY if I start with Protection mode OFF.

Identifying Homematic RF-Hardware: ....HmRF: HMIP-RFUSB/eQ-3 HmIP-RFUSB@usb-0000:02:00.0-2.1, HmIP: HMIP-RFUSB/eQ-3 HmIP-RFUSB@usb-0000:02:00.0-2.1, OK
Updating Homematic RF-Hardware: HMIP-RFUSB: 4.4.16, OK
Starting hs485dLoader: disabled
Starting xinetd: OK
Starting eq3configd: OK
Starting lighttpd: OK
Starting ser2net: disabled
Starting ssdpd: OK
Starting ha-proxy: OK
Starting NUT services: disabled
Initializing Third-Party Addons: OK
Starting LGWFirmwareUpdate: ...OK
Setting LAN Gateway keys: OK
Starting hs485d: disabled
Starting multimacd: .OK
Starting rfd: .OK
Starting HMIPServer: ........OK
Starting ReGaHss: .OK
Starting CloudMatic: OK
Starting NeoServer: disabled
Starting Third-Party Addons: OK
Starting crond: OK
Setup onboard LEDs: booted, OK

I now have a brand-new, pre-assembled HmIP-RFUSB, so now I know that the problem isn't because of my lack of soldering or assembly prowess. The HmIP-RFUSB is on a 2m extension, in order to stave off any RF interference in the 866Mhz band.

On the control panel in RaspberryMatic, it says Duty Cycle 2% - Carrier Sense 0%, which would seem to indicate that the RF device is definitely working. In addition to that, as @jens-maus wanted to verify, the countdown clock is definitely counting down when I press the "teach-in device" button.

I can now teach-in devices.

Please note that a problem I was having, after discovering that I had to run the RaspberryMatic addon in unprotected mode was that I still had a Homematic-IP access point running. Having that running caused the RaspberryMatic CCU to fail to teach-in anything, presumably because the access point was also communicating with the Homematic-IP hardware.

I hope that I can prevent others from making that mistake, and having the two types of 866Mhz communications interfering with one another.

As this discussion should be in a state that others may be helped, I'll end it here.

It seems like the requirement to run in the RaspberryMatic CCU add-on in unprotected mode IS A BUG, but perhaps that just needs to be documented.

[jens-maus]

It seems like the requirement to run in the RaspberryMatic CCU add-on in unprotected mode IS A BUG, but perhaps that just needs to be documented.

This is something that will go away with the next official release version. Having to disable protection mode is just a workaround currently.