[SOLVED] MAX! Binding Bug: Thermostats are switching together

Add-ons Bindings
, ,
1

Hey there,

I am recently facing a very strange problem with my MAX! radiator thermostats.
Two of the thermostats are switching their set temperature simultaneously although I am only changing the set temperature of one of them. The problem does not occur if I use the MAX! desktop application, this is why I think it has to be a problem in the openhab binding.

The thermostat things are added via autodiscovery in the paper ui, hence without any file configuration.
The item configuration of my living room thermostat looks like this:

Group gMAXWohnzimmer "Wohnzimmer" ["Thermostat"]
String max_therm_wohn_switch "Heizung Wohnzimmer" <radiator>
Switch max_therm_wohn_battery "Batterie Thermostat Wohnzimmer" <lowbattery> {channel="max:thermostat:NEQ1207898:OEQ0013043:battery_low"}
Number max_therm_wohn_actual "Aktuelle Temperatur [%.1f °C]" <temperature> (gMAXWohnzimmer) [ "CurrentTemperature" ] {channel="mqtt:topic:mosquitto:msnode4:temp"}
Number max_therm_wohn_settemp "Temperatur Heizung [%.1f °C]" <temperature> (gMAXWohnzimmer) [ "TargetTemperature" ] {channel="max:thermostat:NEQ1207898:OEQ0013043:set_temp"}
String max_therm_wohn_mode "Modus" <settings> (gMAXWohnzimmer) [ "homekit:HeatingCoolingMode" ] {channel="max:thermostat:NEQ1207898:OEQ0013043:mode"}

and of my bathroom thermostat like this:

Group gMAXBadezimmer "Badezimmer" ["Thermostat"]
String max_therm_bad_switch "Heizung Badezimmer" <radiator>
Switch max_therm_bad_battery "Batterie Thermostat Badezimmer" <lowbattery> {channel="max:thermostat:NEQ1207898:OEQ0014191:battery_low"}
Number max_therm_bad_actual "Aktuelle Temperatur [%.1f °C]" <temperature> (gMAXBadezimmer) [ "CurrentTemperature" ] {channel="max:thermostat:NEQ1207898:OEQ0014191:actual_temp"}
Number max_therm_bad_settemp "Temperatur Heizung [%.1f °C]" <temperature> (gMAXBadezimmer) [ "TargetTemperature" ] {channel="max:thermostat:NEQ1207898:OEQ0014191:set_temp"}
String max_therm_bad_mode "Modus" <settings> (gMAXBadezimmer) [ "homekit:HeatingCoolingMode" ] {channel="max:thermostat:NEQ1207898:OEQ0014191:mode"}

As far as I can see there is nothing mixed up here.

Does someone has an idea if I am doing something wrong or if this might be a bug in the binding? Does someone else experienced a similiar thing?

Best regards
Ron

EDIT: I am using Openhab 2.4.0 on an Raspberry Pi 3B.

2

How are you doing that - rules, UI?
May we see the events.log of the process?

3

I have a setpoint switch on my sitemap to change the *_settemp items. This is done in the openhab android app.

When I increase e.g. the settemp of my living room, this is what is generated in the events.log:

2019-10-10 11:22:20.194 [me.event.ThingUpdatedEvent] - Thing 'max:bridge:NEQ1207898' has been updated.
2019-10-10 11:22:30.096 [ome.event.ItemCommandEvent] - Item 'max_therm_wohn_settemp' received command 20.0
2019-10-10 11:22:30.101 [nt.ItemStatePredictedEvent] - max_therm_wohn_settemp predicted to become 20.0
2019-10-10 11:22:30.117 [vent.ItemStateChangedEvent] - max_therm_wohn_settemp changed from 18.5 to 20.0
2019-10-10 11:22:30.156 [vent.ItemStateChangedEvent] - max_therm_wohn_switch changed from ECO to ON
2019-10-10 11:22:30.375 [me.event.ThingUpdatedEvent] - Thing 'max:bridge:NEQ1207898' has been updated.
2019-10-10 11:22:30.884 [vent.ItemStateChangedEvent] - Cube_free_mem changed from 50 to 49
2019-10-10 11:22:31.517 [vent.ItemStateChangedEvent] - Memory_Used changed from 610 to 611
2019-10-10 11:22:37.774 [vent.ItemStateChangedEvent] - CPU_Load5 changed from 0.1 to 0.0
2019-10-10 11:22:37.787 [vent.ItemStateChangedEvent] - CPU_Load1 changed from 0.1 to 0.0
2019-10-10 11:22:50.733 [vent.ItemStateChangedEvent] - Cube_free_mem changed from 49 to 50
2019-10-10 11:22:50.790 [me.event.ThingUpdatedEvent] - Thing 'max:bridge:NEQ1207898' has been updated.
2019-10-10 11:22:51.147 [vent.ItemStateChangedEvent] - max_therm_bad_settemp changed from 18.5 to 20.0
2019-10-10 11:22:51.160 [vent.ItemStateChangedEvent] - max_therm_bad_switch changed from ECO to ON

This is everything from the point where the change is triggered on the livingroom thermostat until the point where also the bathroom thermostat changes.
The *_switch items are changed in a rule where each item has its own rule.

The maxcube thing seems to be updating another time and then changing the bathroom settemp also.
Btw: Cube_free_mem is the free memory places in the maxcube.

4

So, guessing, because of a preceding command this is Good -

and this is Bad ?

because there is no associated command.
We can rule out a groups/rules issue, with no command.

In the next case, must consider crossed up Things and channels.

How convinced are you that the command arrives at the correct target device - we cannot rely on what autoupdate says about the target settemp in events.log , but that ECO change looks like it comes from the actual device?
It obviously makes a difference if looking for a “duplicated” or “misdirected” problem.

I note the “rogue” settemp takes 20 seconds to get updated. I guess that is because it gets noticed in a routine poll, rather than an immediate announcement.

I’ve no idea how you could check in the Maxi-cube bridge thingy if these thermostats are accidentally linked as though in the same room.

5

Are you sure it’s OH to sync your two thermostats ?
The MAX! system all by itself allows for coupling thermostats (and window sensors) by placing them into the same room. This in fact forcefully synchronizes them, i.e. if you change one target temp, this change will be propagated to all linked devices (= all in the same “room” as define by the MAX! software).
IIRC this happens in “AUTO” mode only so it may be different if you put them into “MANUAL”, and I think it even results in individualized setting if you separately instruct them from OH (overriding that "in-MAX! sync).
@marcel_verpaalen Did I get that right ?

6

I am pretty sure that I did not mix up things and channels. Things are auto discovered within paper ui (I also checked that both thermostats have different RF addresses) and I checked the item definitions multiple times.

The item max_therm_wohn_switch is a string item which is used to set three different presets (“ON”, “ECO” and “OFF”), like a switch with three states. For every such string item there is a rule which makes sure that whenever the set temperature changes (may be due to manual change at the thermostat itself or via the setpoint switch), the switch item shows the actual status. E.g. when I change the set temperature at the thermostat from 18 to 20°C the rule posts an update on the max_therm_wohn_switch item to change it to “ON”.

@mstormi
I am quite sure that it has to be something within OH.
As a short test I used the windows software which is provided by the manufacturer to change the settemp remotely and as far as I remember there was no such problem with that one (but I may repeat that this evening). I also deleted the bathroom thermostat in the MAX! windows software, reset it to factory defaults and readded it into the system, making sure that it has its own room assigned.
Also all my thermostats are in “MANUAL” mode.

7

If it was OH to instruct them, it’s never because the binding does anything like that.
It would ALWAYS be due to a rule you wrote yourself (or - unlikely - profiles) and you would find corresponding entries in events.log.
Easy to find out, isn’t it ? (Yeah I know this leaves you questioning where the behavior comes from, but the answer is: not from OH user level (rules) and not from the binding, so it must be inside MAX!)

8

Alright, thank you very much for the clarification :slight_smile:
I will look in more detail into the desktop application and into the way the thermostats are integrated and I will probably post an update later.

9

@mstormi indeed the binding actually controls the rooms rather than individual thermostats.
In fact that is what the original desktop app is also doing as far as I remember. It is not directly obvious though.

If you create a room for each thermostat or discover them with oh (room 0) than you can control them individually.

10

The system is working again as expected.
I checked in the MAX! desktop application how the thermostats are arranged in rooms. They got however all their own rooms. I then removed the two thermostats that were making the problem including their rooms and readded them. Simultaneously I removed all OH things and readded them afterwards. This solved the issue.

I absolutely down known what the problem was but as long as everything is working as expected I don’t mind. :sweat_smile: