Max! Cube loses all settings with OpenHab

Thanks,

Ok, I will read about the protocole thread.
I did some other tests :

  • 1st : I stopped / started openhab (I even rebooted my RaspberryPI)
    • I checked in the advanced properties as you mentioned, and all my Things had the right room name in the dedicated field
    • I still had the “No Rooms information found” INFO message,
    • I was still able to communicate with the thermostats from OpenHAB, and all thermostats of the same room are updated
  • 2nd : Through Paper UI, I removed all Things, and re-add them after being automatically detected by OpenHAB
    • I checked in the advanced properties, the room fields were empty (not really surprised)
    • I still had the “No Rooms information found” INFO message,
    • I was still able to communicate with the thermostats from OpenHAB, and all thermostats
  • 3rd : I rebooted the Max! Cube
    • I was not able to communicate again with the thermostats, the configuration has been lost…
    • I removed all things except the gateway, and openhab automatically detected new things, but only showed the SerialNumber and not the human readable description previously entered through MAX! Software

Note that before removing/re-adding Things, I only saw the SerialNumber of the gateway in the logs, SerialNumber for the thermostats disappeared.

2018-11-05 19:39:50.759 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - SerialNumber:             NEQ1206682
  • 4th : I “factory” reset the cube and add as many room as thermostats (15 at the moment)… I’m under test.

I’m sorry, I didn’t change the room name as I already reset the cube when I saw your message, but I’ll do this if I still have the same issue.

To be continued :slight_smile:

Hi all,

At the present time, everything seems to be OK after a full reset by doing these steps :

  1. Remove all thermostats things using OpenHAB
  2. Stop Max OpenHAB binding using Karaf
  3. Factory Reset of the Max! Gateway
  4. Factory Reset for each Thermostat+
  5. Pair all thermostats (One thermostat per room) using MAX! Software on MacOSX
  6. Remove internet access using MAX! Software on MacOSX
  7. Stop Max! software
  8. Start Max OpenHAB binding using Karaf
  9. Configure Gateway to be in exclusive mode + refresh interval to 30 seconds
  10. Add Thermostats things which have been automatically detected

I’m going to still keep on eye on the stability… crossing my fingers right now :slight_smile:

@marcel_verpaalen, I have a question… do you think it could be possible to easily add a new channel type (at the bridge level such as the free_mem one for example) in order to know if the configuration is lost or not ? From my window, it seems to be possible as you already log the “No Rooms information found”

2018-10-28 01:43:30.244 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.XXX.XXX.XXX

The idea is to have a rule which watch an item linked to this new channel, and to automatically send a message to alert when the configuration is lost.

Does it make sense ?

I made a quick version that includes your feature.
have little time to test it, as I need to make a setup and ‘corrupt’ my cube to really test it

I can email that version to you…
or build from https://github.com/marcelrv/openhab2/tree/max-newChannel

Hi Marcel,

Wow, you’re really quick !
Please, don’t corrupt your cube :slight_smile:
At the moment, I’m testing the cube as well to see if it is stable, If ever I encounter a new problem, I’ll test directly the new feature.

At the moment, It seems to be stable, and I didn’t see anything wrong… except that OpenHAB does not send me an update of Duty Cycle (when decreasing only) and FreeMem (when released only)…
It’s weird, I’ll have a look, I don’t think it’s linked to the Max! Binding…

Thanks again Marcel

don’t worry…
I have a 2nd cube just for testing :slight_smile: but need to search for it a bit

please try to telnet (port 62910) to your cube as per my earlier post… (don’t have the binding in exclusive mode at that time)
it will give you a text file as output. With that, M info can be reasonably easy restored if it is corrupted again

yep,
I just did it… I got something like this (truncated) :

H:NEQ1206682,172847,0113,0000..............................
M:00,01,VgIPBwxFMC1CVUFOREVSS..............................
C:172847,7RcoRwATAQBORVExMjA2..............................
C:196c62,0hlsYgIEEP9PRVExMjQw..............................
C:16ecbc,0hbsvAINEP9ORVExMjU5..............................
C:176951,0hdpUQICEABORVExNTg3..............................
C:196b10,0hlrEAIFEABPRVExMjQw..............................
C:17623d,0hdiPQIDEP9ORVExNTg1..............................
C:196ad7,0hlq1wIPEABPRVExMjQw..............................
C:196c6b,0hlsawIGEABPRVExMjQw..............................
C:196ada,0hlq2gIMEP9PRVExMjQw..............................
C:196ca4,0hlspAIBEP9PRVExMjQw..............................
C:195ea5,0hlepQIHEP9PRVExMjQ0..............................
C:196567,0hllZwIOEABPRVExMjQx..............................
C:16f0f8,0hbw+AIJEABORVExMjYw..............................
C:1969ff,0hlp/wIIEP9PRVExMjQw..............................
C:196afc,0hlq/AILEP9PRVExMjQw..............................
C:176374,0hdjdAIKEP9ORVExNTg1..............................
L:CxlsYgkSGQAhAOUACxbsvAkSGQA..............................

I’m going to keep it safely :slight_smile: I don’t know yet how to restore it but at least it’s backed !
Thanks for your help…

I have try same procudure like this

  1. Remove all thermostats things using OpenHAB
  2. Stop Max OpenHAB binding using Karaf
  3. Factory Reset of the Max! Gateway
  4. Factory Reset for each Thermostat+
  5. Pair all thermostats (One thermostat per room) using MAX! Software on MacOSX
  6. Remove internet access using MAX! Software on MacOSX
  7. Stop Max! software
  8. Start Max OpenHAB binding using Karaf
  9. Configure Gateway to be in exclusive mode + refresh interval to 30 seconds
  10. Add Thermostats things which have been automatically detected

But still after one day i get log like this

2018-11-07 10:30:20.781 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:32:01.383 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:33:41.984 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:35:22.585 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:37:03.186 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:38:43.788 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:40:24.389 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:42:04.990 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

2018-11-07 10:43:45.592 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.125

I have only one wall thermostat and only one radiator thermostat for now. I have also disabe internet connection on MAX! original software

Where can you do that in the software?

To restore the rooms, you can try the following… Go to the thermostat, edit the properties (in openhab thing).
Change the room name. If you are little lucky your room info will be restored for all rooms.

Hi, i have one more question.

If i set Comfort temperature in openhab --> things --> radiator thermostat to 21.

Then comfort temperature on wall thermostat stay on 21,5 like before changed settings. Is there option to change comfort and eco temperature of wall thermostat via open hab?

Hi, @marcel_verpaalen, I have exactly same issue with my cube as all the guys here do.

On the other side I do not use the Open Hab. Instead there is my own program that periodically (every minute) polls the cube information. Every minute it connects, waits for a second, sends the L command and gather the response (I am using only the L and M message responses but it is not important here). After this I am closing the connection and everything is repeated after a minute. So it should be something like the non exclusive mode you’ve mentioned, right?

I can try to change my app to simulate the exclusive mode, to wait a longer times before sending the L message and so on. I would like to fix this issue. What about to figure it out together?

As the data lost issue happens independent from the software used, I don’t think it can be solved from the remote side, but rather this is a firmware bug.

I’ve no intention to reverse engineer the firmware.

I think new connections have higher chance to trigger the issue, hence exclusive mode, or in other words, not disconnecting after each message helps.
Also reducing the flow of command seem to help.

My cubes have never demonstrated the issue so it is hard to judge for me… This is what I concluded from all of the reports around this topic.

Anyway… if you want to explore and help for a solution I would suggest to try if just restoring the m info is doing the trick. In that case fixing the matter will be easier.
To restore, you can just play back the M info replacing the M for m and removing the 2nd number and comma

Ok, I have just saved the M config message. When the cube goes wrong again, I will try and report the result.

Another thing - what do you think about turning on the official MQ3 application and sniffing the communication between it and the cube? Maybe there is something that is going on (a magic command :slight_smile: ). But on the other hand it looks more like a hw/fw error :frowning:

How do you think we know the responses to the various commands??.. Any ways I can confirm to you from looking at wireshark a lot that the eq-3 app does not send anything different than the commands used here for the regular communication…

Hi all,
Here is the feedback after having done what is explained in this thread during two months.
Result : everything is working perfectly, I didn’t encounter any issue such as lost of configuration… and I can see on my graphs that it’s doing the job !!!
so thank you guys for your help and for the binding !
My wife is very happy because she feels well, so I got +10000 points on the WAF (Wife Acceptance Factor) :slight_smile:

@marcel_verpaalen, I have two other suggestions for the binding features, based on the same principle than the one you used for the new channel type… Not sure it is possible, but here are the suggestions :

  • Feature to request a reboot of the Max Cube, using directly an item (instead of going in PaperUI)
  • Feature to reset the number of Duty Cycle. Indeed, as I have a lot of radiators (17), I have a lot of limitations concerning the number of commands I can send within one hour. For example, sending a command to all radiators takes around 55% of Duty cycle, so I quickly reach 100% with other rules such as “stop heating if the window is opened”, “relaunch heating if the window is closed”, …

I guess the first suggestion is not too hard to develop, but for the second I’m not sure it will even be possible to develop it if you don’t have any interface available.
If it’s not possible, I would be easy to create a simple rule in order to reboot the cube depending on the level of Duty cycle.
Does it make sense ?

Thanks again for all

1 Like

Happy to hear it’s working for you now.

Disagree. There’s usually no need for a reboot and if there really is, it’s an administration task not a user one, so PaperUI clearly is the (only) right place.
Also disagree on the duty cycle. We mustn’t mess with, in the end it’s mandatory by law.
You won’t need to program rules to stop heating if a window is opened, it’s autonomously done if you use MAX! window sensors. And you can tweak the response times etc. so you can reduce the number of messages if you really need to.

Hi @mstormi,

It was just two suggestions… to discuss about :slight_smile:

OK, you’re right on the fact than the first suggestion is not a user one, so it doesn’t have to be in another place than PaperUI… I totally agree !

Concerning the duty cycle, I don’t understand why you said “it’s mandatory by law”… What is defined in the law ? the number of authorized duty cycle per hour ? or the fact that a number of duty cycles have to be set per hour for ecological reasons ? I totally understand the second one, I’m not saying that’s unnecessary, I’m just saying that the number defined in the Max! cube today doesn’t take into account large houses… I know I have the opportunity to buy a second Max! cube, but is it ecological :face_with_raised_eyebrow: ?

Concerning your remark saying “You won’t need to program rules to stop heating if a window is opened, it’s autonomously done if you use MAX! window sensors”. It is likely you’re right, but I don’t have these MAX! windows sensors, and I won’t buy any of them as I already have sensors thanks to my alarm system. The purpose of OpenHAB solution is precisely to provide a huge interoperability :slight_smile:

I can tell you I already optimized communications between openHab and MAX! cube, in a logical and ecological way, but sometimes I need more percent on the duty cycle. It was the idea of the suggestions.

Whatever, I’m very happy to use this binding :slight_smile:

@schnibel

Duty cycle is a restriction by law.

See here:

wow !!! @Celaeno1 and @mstormi… I’m really impressed by your knowledges guys !
This evening, I’ll go to bed a little less dumb as usual :wink: