MQTT to Home assistant

[RobinC]

Hi,

I have FHEM running the MAX! radiator valves in my house. I recently set up an Opentherm Gateway to my boiler. I connected it to Home Assistant as it seemed easier. I would now like to connect the valves to Home assistant via MQTT.

I found this on Github: https://github.com/danielrheinbay/fhemMAX2HASS it seems to be exactly what I need.Unfortunately I can't get it running.

This is the client:
defmod mqtt MQTT2_CLIENT <192.168.1.203>:1883
attr mqtt lwt homeassistant/binary_sensor/fhem/availability offline
attr mqtt lwtRetain 1
attr mqtt msgAfterConnect -r homeassistant/binary_sensor/fhem/availability online
attr mqtt msgBeforeDisconnect -r homeassistant/binary_sensor/fhem/availability offline

setstate mqtt disconnected
setstate mqtt 2026-11-03 19:45:08 lastPublish homeassistant/binary_sensor/MAX.Kitchen/0f5c7f-panel/config:{"availability":[{"payload_available":"online","payload_not_available":"offline","topic":"homeassistant/binary_sensor/fhem/availability"},{"payload_available":"alive","payload_not_available":"dead","topic":"homeassistant/MAX.Kitchen/Activity"}],"availability_mode":"all","default_entity_id":"MAX-HeatingThermostatPlus-0f5c7f-panel","device":{"configuration_url":"http://192.168.1.134:8083/fhem?detail=MAX.Kitchen","identifiers":["0f5c7f"],"manufacturer":"eQ-3","model":"MAX! Radiator Thermostat Plus","name":"MAX.Kitchen","suggested_area":"MAX","sw_version":"1.0"},"device_class":"lock","entity_category":"diagnostic","payload_off":"locked","payload_on":"unlocked","state_topic":"homeassistant/MAX.Kitchen/panel","unique_id":"MAX-HeatingThermostatPlus-0f5c7f-panel"}
setstate mqtt 2026-11-03 19:46:07 state disconnected

I have tried to use MQTT explorer but it does not see anything if I point it at the FHEM installation.

I know that the MQTT broker is working on Home Assistant as it is receiving data from the OTGW.

One thing I have not done is to SAVE CONFIG, I revert to the old config with shutdown restart when I give up trying to make it work.

Can anyone help me work out what I have got wrong?

Thanks,

Robin

[Beta-User]

Can anyone help me work out what I have got wrong?

There are quite a few options to get this to work. Imo the "cleanest" way ist to use MQTT_GENERIC_BRIDGE (MGB), see especially https://wiki.fhem.de/wiki/MQTT_GENERIC_BRIDGE.

There are some attrTemplate to support the entire process, you may want to start with "base_settings_MQTT_GENERIC_BRIDGE" in the version "ATTRTVERSION_MGB_only".

There may also exist a template to set appropriate Attributes to the thermostats itself.

If needed, I could try to explain more in detail these days. Hope this helps as a starting point.

(btw: I don't use HomeAssistant, so for the yaml part, you might need additional help.)

[RobinC]

Thanks for the response. The solution I'm working from uses the client, the generic bridge and some code

Configure a connection to your MQTT broker using the MQTT2_CLIENT module:

define mqtt MQTT2_CLIENT <mymqttbroker.local>:1883
attr mqtt lwt homeassistant/binary_sensor/fhem/availability offline
attr mqtt lwtRetain 1
attr mqtt msgAfterConnect -r homeassistant/binary_sensor/fhem/availability online
attr mqtt msgBeforeDisconnect -r homeassistant/binary_sensor/fhem/availability offline

Note: If you configure more than one MQTT2_CLIENT device, specify which one to use in 99_myUtils.pm#L56.
Configure an MQTT Generic Bridge:

define mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev mqtt
attr mqttGenericBridge globalDefaults base="homeassistant" qos=2 retain=1
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count

Add a trigger to call MAX2HASSdiscovery using the DOIF module:

define hass.MAXdiscovery DOIF ([":Activity",""]) ({MAX2HASSdiscovery("$DEVICE")})
attr hass.MAXdiscovery do always

Others have got this to work. My problem is I can't even see how to start troubleshhoting. In the Client it seems I have an MQTT message prepared:
homeassistant/binary_sensor/MAX.Kitchen/0f5c7f-panel/config:{"availability":[{"payload_available":"online","payload_not_available":"offline","topic":"homeassistant/binary_sensor/fhem/availability"},{"payload_available":"alive","payload_not_available":"dead","topic":"homeassistant/MAX.Kitchen/Activity"}],"availability_mode":"all","default_entity_id":"MAX-HeatingThermostatPlus-0f5c7f-panel","device":{"configuration_url":"http://192.168.1.134:8083/fhem?detail=MAX.Kitchen","identifiers":["0f5c7f"],"manufacturer":"eQ-3","model":"MAX! Radiator Thermostat Plus","name":"MAX.Kitchen","suggested_area":"MAX","sw_version":"1.0"},"device_class":"lock","entity_category":"diagnostic","payload_off":"locked","payload_on":"unlocked","state_topic":"homeassistant/MAX.Kitchen/panel","unique_id":"MAX-HeatingThermostatPlus-0f5c7f-panel"}

But it is not being received at Home Assistant. I tried to use MQTT explorer to listen to what is going on but I get a message Econn refused when I try to connect to port 1883 on the FHEM address.

[Beta-User]

Some remarks in advance:

- use Code tags to (re-) format your posts. Makes them much easier to read . The "Copy for Forum" function in fhemweb adds some usefull live data .
- there are tons of different "solutions" out there. I'm not willing to dicuss all the pros and cons... Just follow the process descibed in the already linked wiki, unless you know to do better.

MQTT requires configuration on both ends, this brings endless possibilities to discuss...

Let' first check the IO:

Code Auswählen Erweitern

define mqtt MQTT2_CLIENT <mymqttbroker.local>:1883Did you replace <mymqttbroker.local> by the IP or hostname of the Computer Homeassistant ist running?

Then you may just use an arbitrary "publish" command and check if that is visible in the tool you use (like MQTT Explorer).

[RobinC]

Thanks, I'll investigate using publish to see if anything is being sent.

[RobinC]

Hi again,

If I manually publish I am seeing this in the log

2026.11.04 18:04:11 5: HttpUtils url=http://<homeassistant.local>:1883/ NonBlocking via http
2026.11.04 18:04:11 4: HttpUtils: gethostbyname <homeassistant.local> failed

I also tried with the IP address of Home Assistant with the same result.

The address in MQTT_CLIENT is
DEF    
<homeassistant.local>:<1883>

What am I doing wrong?

Thanks for your help.

[Beta-User]

Try without these brackets ("<xxx>" => "Info"), they are just to indicate where to place which type of installation specific content...

[RobinC]

Thanks, that worked! I have STATE opened. Hopefully I can now get it doing the autodiscovery.

[Beta-User]

Thanks, that worked! I have STATE opened. Hopefully I can now get it doing the autodiscovery.

Forget about autdiscovery in HASS... Do yaml config manually and especially first get the fhem<=>MQTT part working.

[Beta-User]

Forget about autodiscovery in HASS... Do yaml config manually

Some additional remarks on this provoking wording:
- As already remarked, I'm not using HomeAssistant, so my sight on this might not be aptly in all aspects
- To my understanding, (MQTT-) autodiscovery allows using whatever gadget without any deeper insight, which topics the gadget uses and expects, how the payload is built and so on. Very helpfull, if you really don't know nothing about the gadget, and/or the firmware etc. might change and bring some braking changes in the MQTT communication
- fiddling around with yaml language seems to be special (I personally absolutely dislike it...), so providing all the configuration info via MQTT may somehow be the "easier way". There ares some users in FHEM trying to support this, see e.g. https://forum.fhem.de/index.php?topic=138354.0 (there might even exist a working solition somewhere...)
- the "basic problem" imo is the non persistive design: As long as there's no config message, the gadget doesn't exist. So one could either abuse the MQTT server (via retain) as "configuration storage", or send all the configution stuff more or less regularly.

All together: Not the best option for any interaction to be fully configured on both ends (FHEM and HomeAssistant) in cases the configuration itself, once established (more or less) never changes...

[Beta-User]

especially first get the fhem<=>MQTT part working.

So let's start with some remarks to the FHEM=>MQTT part. Means: how to publish reading values towards the server.

Many "solutions" out there recommend using (more or less) "global publish of any information". My very personal point of view: this isn't really state of the art, even if you use the "devspec" option to restrict at least the number of devices to send.

Let's start, my example - just as shown via "Copy for forum" with one dummy device configured to interact "somehow" with the MQTT_GENERIC_BRIDGE:

Code Auswählen Erweitern

define mgb3 MQTT_GENERIC_BRIDGE mgb3 TYPE=dummy
#   DEF        mgb3 TYPE=dummy
#   FUUID      6aec49d7-f33f-d171-3512-4d1df8c29d30b951
#   IODev      mqtt_io
#   NAME       mgb3
#   NR         664
#   NTFY_ORDER 70-mgb3
#   STATE      ???
#   TYPE       MQTT_GENERIC_BRIDGE
#   devspec    TYPE=dummy
#   eventCount 5
#   prefix     mgb3
#   READINGS:
#     2026-11-05 10:19:48   IODev           mqtt_io
#     2026-11-05 10:25:04   device-count    1
#     2026-11-05 10:19:48   incoming-count  0
#     2026-11-05 10:19:48   outgoing-count  0
#     2026-11-05 10:19:48   transmission-state IO device initialized (mqtt2)
#     2026-11-05 10:19:48   updated-reading-count 0
#     2026-11-05 10:19:48   updated-set-count 0
#   devices:
#     devStrich0:
#   globalDeviceExcludes:
#   globalReadingExcludes:
#   globalTypeExcludes:
#     pub:
#       FHEMWEB    *
#       Global     *
#       MQTT       transmission-state
#       MQTT_BRIDGE transmission-state
#       MQTT_DEVICE transmission-state
#       MQTT_GENERIC_BRIDGE *
#       telnet     *
#     sub:
#       FHEMWEB    *
#       Global     *
#       MQTT       transmission-state
#       MQTT_BRIDGE transmission-state
#       MQTT_DEVICE transmission-state
#       MQTT_GENERIC_BRIDGE *
#       telnet     *
#
setstate mgb3 2026-11-05 10:19:48 IODev mqtt_io
setstate mgb3 2026-11-05 10:25:04 device-count 1
setstate mgb3 2026-11-05 10:19:48 incoming-count 0
setstate mgb3 2026-11-05 10:19:48 outgoing-count 0
setstate mgb3 2026-11-05 10:19:48 transmission-state IO device initialized (mqtt2)
setstate mgb3 2026-11-05 10:19:48 updated-reading-count 0
setstate mgb3 2026-11-05 10:19:48 updated-set-count 0
 

So what's that:

Code Auswählen Erweitern

define mgb3 MQTT_GENERIC_BRIDGE mgb3 TYPE=dummydefine <name> <TYPE> should be obvious, "mgb3" is the "prefix", "TYPE=dummy" is the regex to limit the possible devices (I'd prefered "TYPE=MAX", so just change that ).
"prefix" is just the first letters of the attributes (in your case available in all the MAX-devices) that might be set for interaction of these devices with this MQTT_GENERIC_BRIDGE. (Maybe there are better options, but imo less confusing than generic "mqtt", especially as I have configured more than one MQTT_GENERIC_BRIDGE here).

Next step would be to do some more testing with just one device (my "dustbin"):

Code Auswählen Erweitern

defmod devStrich0 dummy
attr devStrich0 icon dustbin
attr devStrich0 mgb3Publish temperature:mgb3/$device/$reading
So whatever might be send towards my dustbin, only any event referring to the reading "temperature" will finally be visible via MQTT.
As topic, only "mgb3" is hardcoded. We could do better, so let us turn to the "solution" you found:

Code Auswählen Erweitern

attr mqttGenericBridge globalDefaults base="homeassistant" qos=2 retain=1


Just forget about the last to "recommendations" and DELETE them:
Afaik, "qos" is not needed nor supported by the MQTT2_(SERVER|CLIENT) modules, and if you really need the "last known value" of any gadget in HomeAssistant, there's afaik more efficient ways possible than abusing any MQTT-Server as data storage. You might better provide some "get the latest fhem values" request option, if you really suffer from relevant downtimes in HomeAssistant

Wrt. to "base", in the commandref there's an (at least in the german version somehow missing the attribute name) example:

Code Auswählen Erweitern

attr <dev> globalDefaults sub:base={"FHEM/set/$device"} pub:base={"FHEM/$device"}
Adopting this to

Code Auswählen Erweitern

attr mgb3 globalDefaults sub:base={"mgb3/set/$device"} pub:base={"mgb3/$device"} and

Code Auswählen Erweitern

attr devStrich0 mgb3Publish temperature:$base/$readingwill finally publish all new temperature values (generating events!) to the same topic as the hardcoded version.

Apart from some remarks wrt. to the differentiation between publish ("pub:...") and "supscription" (sub:...") the explanation of the relevant modules and attributes might be more or less complete. Additionally just make sure MQTT_GENERIC_BRIDGE points to the desired IODev and set the appropriate attribute value if needed.

Once you got your MAX thermostat values published as wanted, we could turn to the "subscription" side (MQTT=>FHEM). Be warned: this is a little more complex than what we've discussed until now (but might already be a peace of cake in case you tried the configuration the attrTemplate way ).