Max! Cube loses all settings with OpenHab

@wmccann well, most of the insights on the commands we send to the cube come from wiresharing the network traffic the ‘normal’ program does.

I can’t confirm this, but I have very strong suspicion that if you were to run the normal EQ3 software 24/7 you will encounter the same issue.

Also, I’m running OH for several years now on the cube with 30 sec refresh cycles and never experienced the issue, which is why I believe it is more a firmware/hardware issue rather than the software side.
Having said that indeed, I also believe it has to do with the frequency of the connections & commands send, the lower you make this, the lesser chance you have to trigger the race condition that leads to the overwriting of the memory.

Hi,

After coming across this thread yesterday I found the following software:
http://www.dmitry-kazakov.de/ada/max_home_automation.htm

It has a Mqtt server and it appears to work - with homeseer at least - I am sure there is an openhab MQTT interface available. Since it works by push (i.e. keeps the connection to the cube open and “reads” the messages as they are sent I am hoping this will resolve the problem.

Fingers crossed!

W.

.

1 Like

The cube does not send status messages by itself, at least I have never observed it.
The thing that comes the most close is what in Openhab binding is the ‘exclusive connection’ mode which basically means that it will not disconnect after each message but instead keep the connection and send only the command to receive the status (L command).

Anyways, hope you have good result and if it resolves the issue let us know and we can study how the communication is different.

My Cube lost its data without any third software. I am going to try a CUL solution to get rid of the Cube.

Also the MAX! cube PC-interface causes trouble if the binding is running.
I’m not sure if this goes as “third party” also.
So if I have to do some config in the MAX! cube with the PC-interface I stop openhab.

Beside that the binding works fine - I’m happy with it.

Reflash the Cube with a CUL firmware to make it an CUNx and use it with homegear and homematic binding.
Works like a charm at my installation.

@hmerk Exactly what i did :slight_smile:

Care to give pointers to firmware and homegear install docs ?

I’m just experiencing a new type of problem, actually the cube does not execute commands I send via OH
(I do see in debug that they ARE sent to the cube, but it ignores them).

Shure, will write the needed information later this evening or tomorrow.

Thanks. Please do, I think a number of people are fed up with the Cube (and particularly the fact that it does not allow for backup/restore of its config).

BUT seems this time I blamed it for a problem that it didn’t cause.
Desperately looking to avoid a full re-configuration, I tried a couple of tools such as that one mentioned in post 62, latest MAX!cube Windows SW etc., and the cube always did what we expect it to.
As a last attempt I installed the 2.3.0 binding (ran latest snapshot before) et voilà, target temperature setting started working again. Will file an issue for it.

Hi guys,

Same problem for me for 2 days, Max! Cube lost all settings… When I look into the logs, I have the following message :

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

But all commands are sent to the thermostats !
I’m using the binding 2.3.0, and I’m not configured in exclusive mode (in order to use the Max! application from Playstore or Appstore because of stability problems I encountered with my installation - see thread : Max! cube stability eQ-3 under OpenHAB2)

Curious !!!

@mstormi, you wrote this few days ago :

I don’t know if it could help, but I had a similar problem, and actually it was just due to the pooling period, I thought nothing happened, but once, I saw it worked a long time (around 30 min) after I sent the command… And I realised that it could be linked to the pooling period. Now I put 10 seconds, and never see the problem again. But, it could also be fixed by the entire reconfiguration in zones as I explained in my other thread (Max! cube stability eQ-3 under OpenHAB2)

Pleas find my first HOWTO here

Please feel free to ask if there is anything to be added.

Best
Hans-Jörg

Hi all,

I re-setup everything two days ago through theses steps:

  • Stopped Max Binding 2.3.0 using karaf => Status was “Resolved”
  • Factory Reset of the Max Cube
  • Paired all thermostat+ to Max Cube using MAX! Software on MacOSX
  • Stopped MAX! Software on MacOSX
  • Started Max Binding 2.3.0 using karaf => Status is “Active”
  • Configured binding in exclusive mode, and update every 30sec.

Every works… ouch, no, everything workED, but all the configuration is lost again :face_with_symbols_over_mouth:

I wanted to follow @hmerk tutorial (HOWTO: Reflash MAX!Cube to CUL/CUNx and use with homegar and homematic binding) but at the moment I don’t want to use another solution than a OpenHAB stuff

To be continued…

What will be interesting to understand what song is lost…
There are 4 things in my mind that can happen…

  1. List item Cube thinks it got a factory reset command ( clean resets all)
  2. M data lost… This is the data that holds the room information… Note this is rather independent from the actual linking to the thermostats. Also this is very easy to restore
  3. The thermostats links are somehow lost… Meaning the cube does not know how to reach them anymore
  4. Memory is corrupted differently…(e.g the firmware runs out of space somehow and overwrites data on the wrong spot) In that case it would be also good to factory reset the cube prior to program it again with new settings.

E.g in case of m data lost, you would still have some data left… E.g the defined timezones…
Likewise if the thermostat info is not truly lost b the p program info would still be there…

Hi,

i have same problem repat on about 10 days? Is now some solution so max! sistem will work with this sistem?
I have openHAB2

Hi @marcel_verpaalen,

I"m not sure to know if I’m in one of your four cases… I guess I’m in “M data lost” one, but not sure.

Here is a short description of my configuration. As MAX! does not recommand to use more than 10 rooms, I created 6 zones, and I associated radiators (15 at the moment, and 17 in few days) in each of these zones (rooms). Thanks to this, if I change the desired temperature on a specific radiator, all the other radiators of the same zone (room) will change in the same way. It works without any problem.

I’m using org.openhab.binding.max in version 2.3.0, in exclusive mode, refresh all 30 seconds
The configuration I did through MAX! software was done as follow :

  • Room1 : E0-GOINGTHROUGH :
    • E0-ENTRANCE (OEQ1240108) id: max:thermostatplus:NEQ1206682:OEQ1240108
    • E0-WASHING (OEQ1244230) id: max:thermostatplus:NEQ1206682:OEQ1244230
  • Room2 : E0-CONFORT-
    • E0-CINEMA2 (OEQ1240748) id: max:thermostatplus:NEQ1206682:OEQ1240748
  • Room3 : E0-CONFORT+
    • E0-DESK (OEQ1240481) id: max:thermostatplus:NEQ1206682:OEQ1240481
  • Room4 : E1-CONFORT-
    • E1-BEDR-PARENTS (NEQ1259833) id: max:thermostatplus:NEQ1206682:NEQ1259833
    • E1-BATH1 (OEQ1240461) id: max:thermostatplus:NEQ1206682:OEQ1240461
    • E1-BATH2 (OEQ1240507) id: max:thermostatplus:NEQ1206682:OEQ1240507
  • Room5 : E1-CONFORT+
    • E1-ENTRANCE (NEQ1260356) id: max:thermostatplus:NEQ1206682:NEQ1260356
    • E1-KITCHEN (NEQ1585567) id: max:thermostatplus:NEQ1206682:NEQ1585567
    • E1-LIVINGR1 (OEQ1241901) id: max:thermostatplus:NEQ1206682:OEQ1241901
    • E1-LIVINGR2 (OEQ1240499) id: max:thermostatplus:NEQ1206682:OEQ1240499
  • Room6 : E2-CONFORT+
    • E2-BEDR-CHILD2 (NEQ1587690) id: max:thermostatplus:NEQ1206682:NEQ1587690
    • E2-BEDR-CHILD1 (NEQ1585269) id: max:thermostatplus:NEQ1206682:NEQ1585269
    • E2-MEZZ1 (OEQ1240085) id: max:thermostatplus:NEQ1206682:OEQ1240085
    • E2-MEZZ2 (OEQ1240099) id: max:thermostatplus:NEQ1206682:OEQ1240099

As I explained in my last post, it seems I lost my configuration, as I can read in the logs in INFO level (org.openhab.binding.max set to INFO), I have the following message :

2018-11-05 11:07:00.000 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! cube : 192.168.xxx.xxx

But, weirdly, if I change a desired temperature (settemp) on a radiator, using openhab, the desired temperature is effectively set on the thermostat+, and on all the thermostats of the same room. Note that I don’t send the command to all the radiators of the room, but only one radiator, the temperature is automatically set up on other thermostats of the same room thanks to the initial configuration as explained before.

So everything seems to be ok… the problem is that if I reboot OpenHAB or MAX! cube, It doesn’t work anymore… it’s like if the configuration is somewhere in cache. (I’ll try to do it this evening to be sure, and I don’t remember if I’m still able to communicate at least with one radiator in a room)

In order to get more logs, I used DEBUG level (org.openhab.binding.max set to DEBUG), I have the following logs, but it doesn’t seem to give me more information :

2018-11-05 11:10:59.903 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Open new connection... to 192.168.xxx.xxx port yyyyy
2018-11-05 11:10:59.910 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Connect to MAX! Cube
2018-11-05 11:11:00.165 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - === H_Message ===
2018-11-05 11:11:00.168 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    Serial number:            NEQ1206682
2018-11-05 11:11:00.171 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    FreeMemorySlots:          50
2018-11-05 11:11:00.175 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    NTPCounter:               0
2018-11-05 11:11:00.178 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    Unknown:                  00000000
2018-11-05 11:11:00.181 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    CubeTimeState:            03
2018-11-05 11:11:00.184 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    RF address (HEX):         172847
2018-11-05 11:11:00.187 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    Firmware version:         01.13
2018-11-05 11:11:00.190 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    Connection ID:            0beb16e8
2018-11-05 11:11:00.193 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] -    Duty Cycle:               4
2018-11-05 11:11:00.197 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.xxx.xxx
2018-11-05 11:11:00.312 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - === C_Message ===
2018-11-05 11:11:00.316 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - DeviceType:               Cube
2018-11-05 11:11:00.319 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - SerialNumber:             NEQ1206682
2018-11-05 11:11:00.322 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - RFAddress:                172847
2018-11-05 11:11:00.324 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - RoomID:                   19
2018-11-05 11:11:00.327 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Utc   Offset   ( Winter ):3600
2018-11-05 11:11:00.330 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Unknown2:                 0B 00 04 40 00 00 00 00 00 00 00 41 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2018-11-05 11:11:00.333 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Portal   Enabled:         0
2018-11-05 11:11:00.336 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Winter   Time:            Sun Oct 28 03:00:00 CET 2018
2018-11-05 11:11:00.339 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Portal   URL:             http://max.eq-3.de:80/cube0/lookup
2018-11-05 11:11:00.341 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Time Zone   ( Winter ):   CET
2018-11-05 11:11:00.343 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Summer   Time:            Sun Mar 25 03:00:00 CEST 2018
2018-11-05 11:11:00.345 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Time Zone   ( Daylight ): CEST
2018-11-05 11:11:00.347 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Unknown1:                 0B 00 04 40 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2018-11-05 11:11:00.349 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - Utc   Offset   ( Summer ):7200
2018-11-05 11:11:00.429 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - === C_Message ===
2018-11-05 11:11:00.431 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - DeviceType:               Thermostat+
2018-11-05 11:11:00.433 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - SerialNumber:             OEQ1240108
2018-11-05 11:11:00.435 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - RFAddress:                196c6b
2018-11-05 11:11:00.437 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - RoomID:                   5
2018-11-05 11:11:00.439 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - window Open Temp:         12.0
2018-11-05 11:11:00.441 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - boost Duration:           0
2018-11-05 11:11:00.443 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - decalcification:          12
2018-11-05 11:11:00.445 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - offset Temp:              0.0
2018-11-05 11:11:00.447 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - max Temp Setpoint:        30.5
2018-11-05 11:11:00.449 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - boost Valve Pos:          80
2018-11-05 11:11:00.451 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - min Temp Setpoint:        4.5
2018-11-05 11:11:00.453 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - valve Maximum:            100
2018-11-05 11:11:00.455 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - comfort Temp:             20.0
2018-11-05 11:11:00.457 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - valve Offset:             0
2018-11-05 11:11:00.458 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - eco Temp:                 17.0
2018-11-05 11:11:00.460 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - window Open Duration:     15
2018-11-05 11:11:00.469 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - === C_Message ===
2018-11-05 11:11:00.471 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - DeviceType:               Thermostat+
2018-11-05 11:11:00.473 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - SerialNumber:             OEQ1244230
2018-11-05 11:11:00.475 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - RFAddress:                195ea5
2018-11-05 11:11:00.477 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - RoomID:                   5
2018-11-05 11:11:00.479 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - window Open Temp:         12.0
2018-11-05 11:11:00.481 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - boost Duration:           0
2018-11-05 11:11:00.483 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - decalcification:          12
2018-11-05 11:11:00.485 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - offset Temp:              0.0
2018-11-05 11:11:00.487 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - max Temp Setpoint:        30.5
2018-11-05 11:11:00.489 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - boost Valve Pos:          80
2018-11-05 11:11:00.491 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - min Temp Setpoint:        4.5
2018-11-05 11:11:00.493 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - valve Maximum:            100
2018-11-05 11:11:00.495 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - comfort Temp:             21.0
2018-11-05 11:11:00.497 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - valve Offset:             0
2018-11-05 11:11:00.499 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - eco Temp:                 16.5
2018-11-05 11:11:00.501 [DEBUG] [nternal.handler.MaxCubeBridgeHandler] - window Open Duration:     15
...
same === C_Message === for all radiators
...
2018-11-05 11:11:01.032 [DEBUG] [b.binding.max.internal.device.Device] - Device 196c6b (Thermostat+): Actual Temperature : 18.0
2018-11-05 11:11:01.035 [DEBUG] [b.binding.max.internal.device.Device] - Device 195ea5 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.037 [DEBUG] [b.binding.max.internal.device.Device] - Device 1969ff (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.039 [DEBUG] [b.binding.max.internal.device.Device] - Device 196b10 (Thermostat+): Actual Temperature : 19.4
2018-11-05 11:11:01.042 [DEBUG] [b.binding.max.internal.device.Device] - Device 196c62 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.044 [DEBUG] [b.binding.max.internal.device.Device] - Device 16f0f8 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.046 [DEBUG] [b.binding.max.internal.device.Device] - Device 176951 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.048 [DEBUG] [b.binding.max.internal.device.Device] - Device 196afc (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.050 [DEBUG] [b.binding.max.internal.device.Device] - Device 16ecbc (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.053 [DEBUG] [b.binding.max.internal.device.Device] - Device 196ad7 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.055 [DEBUG] [b.binding.max.internal.device.Device] - Device 196ada (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.057 [DEBUG] [b.binding.max.internal.device.Device] - Device 176374 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.059 [DEBUG] [b.binding.max.internal.device.Device] - Device 196567 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.061 [DEBUG] [b.binding.max.internal.device.Device] - Device 196ca4 (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.063 [DEBUG] [b.binding.max.internal.device.Device] - Device 17623d (Thermostat+): Actual Temperature : 0.0
2018-11-05 11:11:01.068 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E1-ENTRANCE (NEQ1260356) id: max:thermostatplus:NEQ1206682:NEQ1260356
2018-11-05 11:11:01.071 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E1-KITCHEN (NEQ1585567) id: max:thermostatplus:NEQ1206682:NEQ1585567
2018-11-05 11:11:01.075 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E1-LIVINGR1 (OEQ1241901) id: max:thermostatplus:NEQ1206682:OEQ1241901
2018-11-05 11:11:01.078 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E1-LIVINGR2 (OEQ1240499) id: max:thermostatplus:NEQ1206682:OEQ1240499
2018-11-05 11:11:01.082 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E2-BEDR-CHILD2 (NEQ1587690) id: max:thermostatplus:NEQ1206682:NEQ1587690
2018-11-05 11:11:01.086 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E2-BEDR-CHILD1 (NEQ1585269) id: max:thermostatplus:NEQ1206682:NEQ1585269
2018-11-05 11:11:01.090 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E2-MEZZ1 (OEQ1240085) id: max:thermostatplus:NEQ1206682:OEQ1240085
2018-11-05 11:11:01.095 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E2-MEZZ2 (OEQ1240099) id: max:thermostatplus:NEQ1206682:OEQ1240099
2018-11-05 11:11:01.099 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E1-BATH1 (OEQ1240461) id: max:thermostatplus:NEQ1206682:OEQ1240461
2018-11-05 11:11:01.103 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E1-BATH2 (OEQ1240507) id: max:thermostatplus:NEQ1206682:OEQ1240507
2018-11-05 11:11:01.106 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E1-BEDR-PARENTS (NEQ1259833) id: max:thermostatplus:NEQ1206682:NEQ1259833
2018-11-05 11:11:01.110 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E0-CINEMA2 (OEQ1240748) id: max:thermostatplus:NEQ1206682:OEQ1240748
2018-11-05 11:11:01.115 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E0-ENTRANCE (OEQ1240108) id: max:thermostatplus:NEQ1206682:OEQ1240108
2018-11-05 11:11:01.119 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E0-DESK (OEQ1240481) id: max:thermostatplus:NEQ1206682:OEQ1240481
2018-11-05 11:11:01.123 [DEBUG] [x.internal.handler.MaxDevicesHandler] - No changes for Thermostat+ E0-WASHING (OEQ1244230) id: max:thermostatplus:NEQ1206682:OEQ1244230

I’m wondering if the 10 rooms limitation is a real limitation… because @mstormi told me he’s using more than 10 rooms. So I have the opportunity to create as many rooms as radiators and to manage the relation between radiators through rules (e.g. if a new temperature is set for a radiator, send an update command to all other radiators of the same group). But in that cas, it means there will have more communication between the binding and the cube (I will have in the worst case 17 commands sent from the binding to the gateway instead of 6 commands)

Is it clear enough ?
Am I in the “M data lost” case ?

Very interesting indeed… this is the first time actually seeing the data from a ‘settings lost’ cube.
Indeed the M data is missing… the remaining data appears in tact.
The good news: actually most info is in the C data, so in theory the M data can be rebuild based on the information still there. M message is the more simple to restore than the rest. Actually the MAX! binding already has functionality to send the M message
The bad… no software currently does this. It would require some programming to generate the right arrays for the room info. Once the arrays are there, it would be as simple as changing the room name in the thing settings to trigger the sending of new M information to the cube.

Anyway, there is a chance it will work: you could try to see what happens if you try to update the room name in the OH thermostrat settings. Maybe it has enough info to construct the M info

hummmm… I’m happy to see that this log is interesting… but I have to admit that I don’t understand what you’re talking about when you address “C data and M data” (do you have any link about this ? I could read it and try to help more deeply).
So at the moment I don’t understand what I have to concretely try.

Beside this, after I sent the post this morning, an idea came in my head… I’m wondering if the problem could not come from a “double communication / collision” issue… let me explain.

As I told you, I configured my cube in order to have zones (rooms) in which I have several radiators. The idea was to be able to set the new desired temperature to all radiators just by physically setting up a new desired tempature on one of them.

A normal use case, is that at 10.00pm, openHAB automatically receives an event, requesting to set a “night” temperature to all zones (rooms). So, I have a rule which sends the new temperature to only one radiator of each zone (room), consequently it sends 6 commands (one per second) to the cube (one per zone), so all commands are sent to the cube in around 6/7 seconds. But the cube itself also sends commands to the other thermostats of the room it is dealing with…
Finally, I wonder if there is not a kind of collision between the commands received by OpenHAB while dealing with commands it sends to thermostats…

Do you see what I mean ?

What I am going to try :

  • Extend the delay between commands (e.g. 30 seconds between commands instead of 1 second… just to let more time to the cube to deal with the thermostats of the room it is dealing with
  • Attribute only one room per thermostat, so the cube is not going to send internal commands to other thermostats. I hope it won’t be a problem to use more than 10 rooms (see. @mstormi who’s using more than 10)

What do you think of this ?

Question for other people who have the same “configuration loosing issue”… Do you have several thermostats per room ?

I have only one wall thermostat only one radiator thermostat and one cube for now.

@schnibel sorry indeed that was probably confusing.

See here description of the protocol

in very short: M message contains the room & thermostat names as well as the linkage between the two
the C messages contain the configuration of the thermostats, but also holds the linking between room & thermostat.

To elaborate on my suggested possible fix; go to one of the thermostats in openhab, go into the thing edit mode.
then go to the config, use show more to see the advanced properties. You see now the roomnames & thermostat names. What I suggest to try is to change one of the thermostat names. With a little luck, the binding will send a complete M command to the cube and voila it is back in business. I looked shortly at the code and there is a good chance it will actually work

anyway, to backup the settings, in a more manual way, telnet 192.168.178.22 62910 (change to your ip) and it will spit out the information. Basically with that you can later onwards restore it.
I said M is easy to restore as for m commands, the update is almost the same as the data it provides when you telnet to it (you need to remove the second number from the string).

nb, during the rewrite of the binding from OH1.8 to 2.x the main difference was that the binding is not sending all the commands at one time anymore (like in 1.8), but keeps time between. All not send commands are kept in a queue. Hence it should not be a problem if you send up to 50 commands at one go, after that it will ignore new ones until there is place again