Add support for culfw

Culfw provides possibility to integrate with the following devices/product lines:

  • “SlowRF” mode (1kHz datarate, AM)
    • FS20: send/receive
      There are numerous FS20 devices, AFAIK. all of them are fully supported.
    • FHT: send/receive
      Communication to the FHT80b and directly to the FHT8v is supported. Sending out FHT80TF data pakets to FHT80b.
    • S300: receive
      Examples of such devices: S300TH, KS300-2
    • EM1000: receive
      Devices: EM1000FM, EM1000GZ, EM1000WZ
    • HMS: receive
      Devices: There are numerous HMS devices, AFAIK. all of them are fully supported.
    • Hoermann: receive
      Some 868 Hoermann garage door openers.
    • ESA2000: send and receive
    • Lacrosse TX2/TX3: receive
    • Intertechno: send
    • Somfy RTS: send
  • BidCos® in the “AskSin” mode (20kHz datarate, FM). HomeMatic® Wireless devices use this protocol.
  • MAX! in the “MORITZ” mode

Further documentation:

I wrote a custom component for an FS20 switch using the Serial library from python so I could provide help for it but I’m not sure how the general architecture of such a component supporting a variety of devices should look like.

There also is an DIY Tutorial building such a cul:

It’s possible to use the CUL with Homegear, and then connecting to Homegear using the HomeMatic integration. That way Intertechno devices are already usable. BidCos itself also is already supported, obviuosly by the HomeMatic integration as well. For AskSin devices it would be required to implement support in pyhomematic. So here’s the drawback that it’s not possible to just use any custom-built device.

I don’t know how Homegear handles the other protocols you have mentioned. But I think at least FS20 can be used there as well. However, support for the specific devices would need to be added in pyhomematic again.

While it may be true that this would work, I would much rather prefer a direct integration in Home Assistant to reduce dependencies and overhead. Having to maintain and update an additional piece of software is not the ideal solution for me. As far as I know there is no official addon for Homegear.

It’s part of Home Assistants modular design principles, that device-specific code comes through external modules. It’s not Home Assistants job to know how to talk with a CUL, it’s a libraries job. HA then talks to the library, and whatever happens there HA doesn’t care about.
There are very few exceptions to this rule, so I’m 99% sure an integration not doing this wouldn’t be merged into HA.

Does it really matter if you update the HA integration or your library? It would be the same code, just different places. And at least in your own library you wouldn’t have to follow the strict rules for how code has to look like in HA.
Or are you talking about using Homegear? I understand that this would be annoying. But in that case most of the work would already be done, not taking into account protocols that are not supported by Homegear and exposed via the XML-RPC the HomeMatic integration is using.

FWIW, just yesterday a user has posted how he got is cc1101 working on HassOS. Maybe that’s an option for you?

Lack of support for this is the only reason I switched back to FHEM.


the only intergation I miss when switching from openHAB to HA. I have some FHT80b devices including window contacts. Would be great to integrate them natively into HA.


Any news on this topic? It’s really a show stopper for many FHEM users to move to home assistant.


Same here.

I am using fhem because I have a lot FS20 and FHT8X Devices and some S555TH. Everything else is supported by HASS

1 Like

Did you see this for FHT Integration GitHub - Rsclub22/home-assistant-fht: FHEM Connector for FHT Heating devices ?

I think you can in general bridge from FHEM to HA using mqtt rather easily. There’s a general mqtt bridge available in FHEM, that already should be enough to integrate FHTs as mqtt hvac.