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.
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 - #2 by mstormi)
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 - #2 by mstormi)
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 
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…
- List item Cube thinks it got a factory reset command ( clean resets all)
- 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
- The thermostats links are somehow lost… Meaning the cube does not know how to reach them anymore
- 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
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
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 
Hi all,
At the present time, everything seems to be OK after a full reset by doing these steps :
- Remove all thermostats things using OpenHAB
- Stop Max OpenHAB binding using Karaf
- Factory Reset of the Max! Gateway
- Factory Reset for each Thermostat+
- Pair all thermostats (One thermostat per room) using MAX! Software on MacOSX
- Remove internet access using MAX! Software on MacOSX
- Stop Max! software
- Start Max OpenHAB binding using Karaf
- Configure Gateway to be in exclusive mode + refresh interval to 30 seconds
- Add Thermostats things which have been automatically detected
I’m going to still keep on eye on the stability… crossing my fingers right now
@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
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 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