Connecting eQ-3 MAX! Thermostats via FHEM/MAXLAN and Mosquitto as bridge


thanks for providing this great tool :slight_smile:

I thought, it would be a good solution to talk to my to the hosted MQTT server)

As far as good, the connection works, but Googles interpretation is a little wired to me.

If I talk to the Assistent, it shows the thermostat and will let me set the temperature.
If I use the Google home app, it only shows the room temperatur, I can not make any input.

Beside: The room temperature in both cases is displayed correct (rounded to full degree) but if I ask the Assistent “how warm is it here” it gives back the tempset-setpoint even if it displays the tempset-ambient correct.

I am using the FHEM MQTT_BRIDGE function and this connections:

publishReading_mode > gBridge/u*/d*/tempset-mode/set
publishReading_desiredTemperature > gBridge/u*/d*/tempset-setpoint/set
publishReading_temperature > gBridge/u*/d*/tempset-ambient/set

subscribeSet_desiredTemperature > gBridge/u*/d*/tempset-setpoint

since of trying out the, I actually only used the tempset-mode “auto” but already found out that FHEM only sets a new received temperature, if the mode is set to “manual”

Any idea why Google acts this way?



Well… :wink:

Long story short: The “Automatic” mode isn’t fully supported by the Google Home app (at least not for the german version). As you can see, it reports “Andere” as the status for the device - though it should be automatic. Automatic seems to be unknown. I’ve filed a bug report for Google - but i don’t expect them to do something about that anytime soon, sadly.

I think a possible workaround is not reporting back the mode from FHEM (removing the attribute publishReading_mode > gBridge/u*/d*/tempset-mode/set). Only set this one to heat or on once, after creating the device.

You’d somwhow need another attribute, like subscribeSet_mode > gBridge/u*/d*/tempset-mode, though some additional scripting for mapping values is needed there.

At least for me, I can do set MAX-Thermostat desiredTemperature 20.5, even if it is in auto. However, it switches to manual mode after that command. But I use a CUL for these thermostats, don’t know if thats a difference. We’d have to do set MAX-Thermostat desiredTemperature auto 20.5, in order for it to stay in automatic mode.


Great, thanks for the hint :+1:

I followed your workaround and set tempset-mode to ‘heat’ after creating the device.
Now it works fine with the home app and the assistant.
If I change temperature with Google, the MAX-Thermostat also switches to manual now, so my MAXLAN shows the same behavior as your CUL.


Made some cruel Inline-Perl, but it works.

This is for desiredTemperature:
attr MaxTherm.gBridge subscribeSet_desiredTemperature { if(ReadingsVal($device, "mode", "") eq "auto"){ fhem("set $device desiredTemperature auto $message");; 0 }else{ fhem("set $device desiredTemperature $message");; 0 } } gBridge/ux/dy/tempset-setpoint
This will keep auto, if the thermostat is in auto.

I’ve tried something to set the mode. Configure the device in gBridge to support Off, Heating, On, Automatic and Energy Saving. This is the FHEM part:
attr MaxTherm.gBridge subscribeSet_modex { my $isAuto = (ReadingsVal($device, "mode", "") eq "auto") ? "auto":"";; if($message eq "off"){ fhem("set $device desiredTemperature $isAuto off");; 0 }elsif(($message eq "heat") || ($message eq "on")){ fhem("set $device desiredTemperature $isAuto comfort");; 0 }elsif($message eq "auto"){ fhem("set $device desiredTemperature auto");; 0 }elsif($message eq "eco"){ fhem("set $device desiredTemperature $isAuto eco");; 0 } } gBridge/ux/dy/tempset-mode

This leads to the following behaviour:

  • Google “Off” will lead to set desiredTemperature off, keeping auto if applicable.
  • Google “On” or “Heat” will lead to set desiredTemperature comfort, keeping auto if applicable
  • Google “Energy Saving” will lead to set desiredTemperature eco, keeping auto if applicable
  • Google “Auto”, well, will set to the automatic program using the scheduled temperature


looks nice :grinning:

I am not 100% sure, but after the “mode” script has been active once, my device shows radio frequency interferences. It looses radio connection to the cube …
hm, well, it says it does, but seems to work still.
If I reset it by taking batteries off, the error is fixed till the script’s next running.
That now happend 3 times, I will try again the next days.
(My FHEM MQTT_BRIDGE is connected to a Wall Thermostat)



I’ve seen these RF issues on my setup, too - but I haven’t thought this comes from this script.

Is there anything obvious in your logs?


Nope, the logs look good here.

What I noticed also: switching the device to manual mode when changing the desired temperature seems to come from FHEM.
If the device is in auto mode and I change temperature at the device itself or with MAX! Remote on Android keeps the auto mode.

I now deactivated both of your scripts and will see, what happens with the RF error.