Debmatic can be run on Debian 12 together with a supervised installation of HA, but you might have hard time maintaining the HA installation. It does require a lot of Linux skills and understanding.
I did it in the beginning.
… that I have try as you can read here so as an result it’s nothing what I can handle.
So I will try with an VM like Proxmox or KVM…
I could handle the supervised installation, but new wishes made me use choose proxmox and HAOS, which is something I am happy for today.
It is just a lot easier.
1 Like
yep, you are right, I think. I will try this combination. I just have to wait for an DP2HDMI for the MiniPC due I can’t block the 2nd PC without massively lower the WAF 
I’m sure I come back shortly with other questions about this… I’m sure that don’t run like an oiled flash… I know me… If there is a rock on the road, I hit them 
If you can use the normal CCU, then debmatic is exactly the same. You can even backup your current CCU and restore it on Debmatic.
… I have never used a native CCU. FHEM can do all that natively, so there was no need for a CCU before. This will be the 1st time I get in touch with that …
In the meantime, I had already thought about replacing most of the HM stuff, e.g. the radiator thermostats with Shelly TVR, but considering the amount required (15 pieces), that’s not financially feasible. So I’m stuck with the HM stuff for better or for worse 
BTW: The SONOFF TRVZB are maybe useable, but I haven’t read any reports about it in connection with HA; maybe I’m too blind …
The only thing I have found is that there are probably problems or no way to read the valve position from HA on the thermostat. But this is absolutely necessary because I calculate the actual heat requirement from this and pass it on to the heating control system, which then calculates the output of the pumps and the required flow temperature…
In the meantime, after many hours of trial and error, I have Proxmox running and set up my first VM with Debmatic…
So far, so good… Everything seems to be working at first.
However, problems are already starting to arise, so I think I won’t reach my goal this way…
- Both HM-LAN-CFG existing in the network can be entered, but are displayed as “not connected” even after Debmatic is restarted. However, I can ping both HM-LANs from the shell with a response time of around 1.5ms. So they are accessible from the container.
- I haven’t found any way to connect the existing SCC’s on the Pi; This option simply doesn’t exist, neither with HA nor with DebMatic…
So as far as I can tell so far, a conversion from FHEM → HA using DebMatic is simply impossible with the existing (HM/MAX/IT) hardware. At least I don’t see any viable option without having to spend a lot of money (again). So I’m now taking a image of the current status and burying my idea for the time being…
Thank you everyone for the help provided here.
Hi,
I have the same situation. Running fhem with HM-cfg-LAN and want to play around or move to HA.
I will try MQTT-Bridge (and for HM and some other things like modbus will leave running my fhem VM), but this could be a hard way.
Did anyone already do this? Or would buying a used CCU be the better option? Would have to re-configure all the HM devices then, what is also a pain…
Best regards and thanks in advance,
Otto
Just for completeness, got it working using MQTT-bridge.
Example-config in fhem for a HM device:
attr wz_rolladen_rechts mqttBridgePublish mqttPublish *:topic={"$base/wz_rolladen_rechts/$name"} *:qos=2 *:retain=1
attr wz_rolladen_rechts mqttBridgeSubscribe pct:stopic={"$base/wz_rolladen_balkon/set/pct"} stop:stopic={"$base/wz_rolladen_balkon/set/stop"} on:stopic={"$base/wz_rolladen_rechts/set/on"} off:stopic={"$base/wz_rolladen_rechts/set/off"} state:stopic={"$base/wz_rolladen_rechts/set/state"}
and in HA (mqtt):
- name: "wz_rolladen_rechts"
unique_id: wz_rolladen_rechts
command_topic: "fhem/wz_rolladen_rechts/set/state"
position_topic: "fhem/wz_rolladen_rechts/level"
state_topic: "fhem/wz_rolladen_rechts/state"
set_position_topic: "fhem/wz_rolladen_rechts/set/pct"
qos: 0
retain: true
payload_open: "off"
payload_close: "on"
payload_stop: "stop"
position_open: 0
position_closed: 100
optimistic: false
value_template: "{{ value.x }}"
Of course it has to be changed according to your configuration and probably the stopic can be done more generic, but for me it works…
1 Like