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.
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.
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…
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
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.
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 ). But on the other hand it looks more like a hw/fw error
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)
@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 ?
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.
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 ?
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
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.