Max! cube stability eQ-3 under OpenHAB2

Setup, Configuration and Use Installation
1

Hi all,

I have some communication issues with my heating control installation.

First of all, the installation is the following equipment and softwares :

As I have a lot of thermostats, I don’t want to send all the commands in the same time, so each command is sent every 2 seconds (I also tried every 5 seconds, it doesn’t change anything)
Here is a part of the rule :

rule "DRAFT: Set up temperatures"
when
     Item TH_MODE received command
then
     var String currentTime = new DateTime(now).toString("dd/MM/yyy HH:mm:ss")
     var float heatingDesiredTemp = "18.0"
     logDebug("default.rules", "TH_MODE : Received command (previousMode = " + heatingCurrentMode + ") / (newMode = " + TH_MODE.state + ") --- on : " + currentTime)
    heatingCurrentMode = new String(TH_MODE.state.toString)

    HEATING_MODE.members.forEach [s | logDebug("default.rules", "Setting up " + s.name + " to MANUAL")
    sendCommand(s, "MANUAL")
    Thread::sleep(2000)
    ]

    HEATING_SETTEMP.members.forEach [s | logDebug("default.rules", "Setting up desired temperature (" + heatingDesiredTemp +") to Thermostat (" + s.name + ")")
    sendCommand(s, heatingDesiredTemp)
    Thread::sleep(2000)
    ]
end

When the rule is executed, I can see in the Max Cube binding debug logs that everything seems to be correctly executed. No error, and the free memory slots are still 49. So at the gateway level, everything seems to be ok…
The problem is that some (one or two) Thermostats, not each time but often, didn’t effectively received the command from the Gateway (not always the same, so sometimes it works, and sometimes it don’t work :face_with_raised_eyebrow: )

When I connect directly through Max cube application, the thermostats are all virtually set to the desired temperature… So everything is correct under the application, but not in the real life… It’s like no acknowledgement is sent back from the Thermostat to the Gateway (saying “Ok Gateway, you ask me to set the temperature to 18°C, I took it into account, you can go sleep well”).
As you can imagine, it’s not a great behaviour… the idea is to control my home heating system, and if I think the heating is set to 18°C when I’m away, and that in reality it is still set to 20°C, it’s not good for our planet and for my wallet.

Of course, I unlink, factory reset and paired all thermostats and gateway, but the problem is the same.
I also wondered if the communication was not “stopped/degraded” by the walls, but it happens also for Thermostats which are next to the gateway.
I also saw another instability, slots are not always well released, the counter is 49 at the beginning and decreases to 0 after 49 commands ! In that case I manually reboot the gateway :frowning: But all that I explained before has been viewed several times in a “stable” way (49 free memory slots)… Maybe there is a link between issues…

Does anyone have this problem ? have a workaround ? a solution ? a clue ?
Thanks in advance for your answer.

2

Hmm, if it’s always different thermostats to be hit then it does not sound like a RF problem.
Did you upgrade MAX! cube to latest SW (1.4.6) ?
I’ve seen this with my thermostats, too, but it went away when I deleted/readded all devices.
But as you claim you’ve already re-setup everything from scratch… no further idea, sorry.

3

Thanks @mstormi for your answer I’m gonna check the firmware version this evening…
I searched for a gateway firmware update functionality proposed in the Max! application, but I didn’t see that, so I concluded (too quickly) that the update was done automatically. So this is maybe a reason. So thanks for this,

I was also wondering if it could be linked to the number of thermostats… Indeed, I saw that the Gateway is able to deal with 10 rooms without “performance impacts”, but as I have 17 thermostats dispatched in more than 10 rooms I was wondering if it could be a reason… maybe ! but before buying a second Gateway, I would like to understand the issue.
The most incomprehensible point to my mind concerns the acknowledgment management between gateway/thermostats which doesn’t seem to exists.

4

Hi All,

Just to answer myself in order to help the community.

I checked for the firmware update as proposed by @mstormi , it is automatically done when starting the program on your computer, so you do not have to do anything (that’s cool, because there is no proposed functionality to manually update firmware :)).
Today, the software version is 1.4.5, which was the same when I posted the first question. So the problem was due to this version.

As I explained, I was wondering if the problem could not be linked to the fact I set up more than 10 rooms… So I decided to reset everything (factory reset for all thermostats+ and MAX! gateway), and then I created only 7 zones (rooms) to deal with my 17 radiators. Instead of declaring rooms, I declared zones such as “Long Living rooms (Ground Floor)”, “Short Living rooms (Ground Floor)”, “Going through rooms (Ground Floor)”, …
Next, I attached my thermostats to these zones.
And now it seems to work as I want… At least, 2 weeks after, I didn’t see any other lost packets, but I’ll keep an eye on it !

The main problem with this solution is that when I change the temperature or program on one thermostat in a zone, then all others thermostats from the same zone are changing in the same way. It is not a problem for me, but it could be one for some of you. A workaround in that case, would be to by another Gateway ( :frowning: ), or to ask Max! Company to come back to the real world and update their software to put a greater limit (I’m quite sure it’s only a variable to set ! I hope so !)

The acknowledgment question is still remaining… and won’t change alone :slight_smile:

To be continued…

5

@schnibel if I remember well from my experience looking at both the commands I send and the actual sending of the command over the air, it takes some time. Also the sending of each command is not very fast. It is not like an wired connection, where things go in fractions of seconds.

So if you want to retry the commands, I suggest to take a much longer period (90 seconds or so) before resending the command. In case of 17 thermostats, even a much longer time needs to be taken, because of the above… it might not even be completed sending the commands over the air.

to your question, if I recall right, indeed no act message is replied directly. However, there is a feedback once the command has been executed. (e.g. this is why you only get the actual temperature when the valved has changed).

Note that the binding itself already takes care of some buffering, so you can send commands to the binding fast (without the 2 seconds delay), the binding than submits these commands to the cube in a slower pace.

6

My SW is 1.4.6 and I do use more than 10 rooms. So while we’ll probably never find out what combination of elements/handling/… causes the cube to loose its config (and EQ-3 is unwilling to help), these 2 aren’t any of the factors.
For me, the problem stopped after a) I’ve re-setup the MAX! cube config from scratch AND b) I moved to exclusive mode (and I always disable the OH binding before I use the MAX! SW).

7

Hi @mstormi and @marcel_verpaalen,
It’s weird ! When I launch the Max! Application, on MacOS, it’s written : “Max! is up to date (1.4.5)”
Really weird !
I’ll have to re-setup the MAX! cube config too, and use the exclusive mode as you mentioned.
The bad news is that I’m far away from home right now, and the cube lost the configuration :frowning: so unable to control my heating system remotely :frowning:

Thanks @marcel_verpaalen too for the explanation.

I’ll tell you next week if it works for me too.

8

Refer to Max! Cube loses all settings with OpenHab

9

Hi,

I am using 15 eq-3 thermostats as well together with window sensors from a different brand. After half a year I can say, that those thermostats are totally unreliable, unless you stick to standard software MAX! and it’s scheduled programs.
The support of eq-3 is also not very customer oriented. If you point them to the fact, that the thermostat can’t be just switched off (only possible to set temperature to 4.5), but setting the temperature might switch back the mode from manual to automatic, which you try to set so the MAX!-schedule does not override it, their opinion is, there is no bug, it’s a feature.

I think their might be a command which enables “away-mode”, but I couldn’t figure out how to implement it yet. It is possible with the MAX!-Software though.

If anyone has a solution for those thermostats being reliably controlled by openhab, I am very happy if you share your solution.
I already tried different “sleep”-timings between mode an temperature setting, but so far everything is not stable. Currently I am using sleep(45000).

Cheers
Philipp

10

I think I still have an experimental build that implements this features…
I’ll try to find it and push it for merging.

Note wrt to stability… As you have many devices, ensure to disable automatic temperature update feature and set it to exclusive with refreshing each 60 sec.
But indeed these devices have some strange undesirable ‘features’ on their firmware

11

Please be aware that “sleep” longer than 500 ms could cause several issues …

12

I also recommend this approach …
The “mixed” mode seems to be not reliable.

13

Thank you for your reply. Exclusive mode is already set. Regarding the automatic temperature update I don’t know, what you mean. Where should I set it? In paperui? In MAX! Software?
Regards Philipp

14

Thank you for the hint. But if I shorten the sleep time, the mode will switch back, if I set the temperature afterwards. Maybe there is an solution without sleep. Do you have an idea?

15

automatic temp update is bit hidden as advanced configuration. (use the show/hide button in paperUI while editing the thing)