The problem is related to the MAX CUBE that with component polling interval (60s) it resets itself (losing all configuration) depending on how many devices are connected to the system.
I guess leaving an option to change polling interval gives the user the choice of using appropriate polling interval
Do you have any insights about the conditions when it resets? Maybe it makes sense to use different default values?
which default values?
The reset, and configuration lost, is happening to a lot of users. WHen I use mine without touching the configured EQ3 MAX original app it all works, once I use the HASS it got reset after few hours (or 1 day) of use.
In some forum (openhab) they suggested to disable the polling from the original app, and use the OH component with a poll interval not shorter then 5 minutes .. and it works (according to users).
So I guess we need the same
Same problem here although I seem to lose the configuration mostly when restarting Hassio. I will try this to backup and restore using a script: https://github.com/Juerd/eq3-max
This at least makes the impact of configuration smaller.
It is possible to restore using a script and @Juerd commands but you do have to push the buttons on the thermostats so you cannot do it remotely but at least it is less work and you do not have to fire this bad Windows application from EQ3
Create a script with the following commands:
$ max pair 1
$ max pair 1
...
...
$ max crosslink 1
$ max name 1 "Study"
max name 1a2a41 "small_radiator"
$ max status
I use HA with HASSIO so I guess can't use your solution?
If you run Hassio on the raspberry pi it is probably more difficult but you could run it on a sperate Linux machine e.g. Ubuntu. It just re-configures the Max Cube so does not change anything to your Hassio installation.
I run hassio on a Ubuntu 16.04 NUC Intel
In that case just ssh to your box and run
$sudo git clone git://github.com/Juerd/eq3-max /opt/eq3-max
$sudo ln -s /opt/eq3-max/bin/* /usr/local/bin
After these instructions, you can use the commands above. If you put them in a .sh file and make it executable you just have to run that script.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:
I have not seen this issue anymore since I used @Juerd linux tool to configure them. Could also be caused by HA updates running 0.70 now.
You can save and restore Max! Cube's configuration also with this tool
http://www.dmitry-kazakov.de/ada/max_home_automation.htm
I've tried only the "Save configuration into a file" and it works perfectly
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:
Only to give an update.....i've tryed also the upload trought Max Home Automation software and no way to upload old configuration to a resetted Max! Cube.
I've deleted the Max! Cube configuration trought HA and now i'm using Max Home Automation in a windows server machine working as MQTT server. Then trought HA i'm able to integrate each MAX! thermostat within the MQTT climate component and it's working fine without unespected reset.
I'm still facing the issue that the component is still basically unusable due to this, because it resets the gateway regularly.
@sibbl how are you restoring your configuration now when it is reset? Since I stopped using the official tool and restore via the command line it far more stable. One reset needed in 6 month. With the script based upon https://github.com/Juerd/eq3-max tools it takes me <5 minutes to restore.
I am using Dmitry's SW to get the right settings (offset, display room temperature i.s.o set temp). So far I am happy with the result running 3 Wall thermostats and 4 radiator valves.
For scheduling I am using Schedy which makes it far easier as using automations.
@sibbl I'm using ZWave myself, but tried to integrate the cube of my parents multiple times.
It forgot its config more than once each month, maybe because they've also been using the official app quite often and have some more devices (I remember 6 thermostatic radiator valves and 6 window sensors).
While I understand that the workarounds make it easy for you and me, my personal opinion is that it's still a beta solution, nothing stable which you don't have to reconfigure/restore regularly.
@sibbl
i completely agree with you and still think that the component should be hidden from Home Assistant official components. I've many Max Cube! installed and i'm happy with them. I've them in 4 houses working as bed and breakfast and i need heating system remote managment. In one of this house i've
two cubes and 30 Max radiator thermostat. Trying with home assistant made, in this house, made me become crazy so i definitively gave it up. Now trying with Dimitry's software working as MQTT server or directly trought PHP scripts
Hi,
I am using polling interval 15 minutes and more and it is fine more than month.
I am using a polling inverval of 60s now for more as a month and it is also fine. I do not know what the diffrence is. The last time I lost my settings I went back to factory settings of the cube and fully installed with the 3rd part SW without using the official application.
@claudioita Did @taste66's fix resolve your issue?
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 馃憤
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Any new findings on this?
Maxcube lost configuration again (after several month, was ok for the winter season), willl have to reprogramming. (on hassio 0.98.4)
Maxcube lost configuration again (after several month, was ok for the winter season), willl have to reprogramming. (on hassio 0.98.4)
To "solve" this problem, the maxcube interface needs to keep the communication open! Polling will trigger configuration loss, for some cubes sooner, for others later. Increasing the polling interval will trigger the problem just a bit later (if your're lucky). If you're in bad luck, it won't help. I'm using http://www.dmitry-kazakov.de/ada/max_home_automation.htm now for a year or so and as it keeps open the connection, I do not have any problem anymore. Before when using FHEM or HA I head a configuration loss quite often (every few months)...
Maxcube lost configuration again (after several month, was ok for the winter season), willl have to reprogramming. (on hassio 0.98.4)
To "solve" this problem, the maxcube interface needs to keep the communication open! Polling will trigger configuration loss, for some cubes sooner, for others later. Increasing the polling interval will trigger the problem just a bit later (if your're lucky). If you're in bad luck, it won't help. I'm using http://www.dmitry-kazakov.de/ada/max_home_automation.htm now for a year or so and as it keeps open the connection, I do not have any problem anymore. Before when using FHEM or HA I head a configuration loss quite often (every few months)...
I'll stick with HA even it comes to the problem again in the future (as i have a lot of automation and other stuff working on HA). Anyway thanks cs42 for the hint (as i'am using Mac it won't work anyway and I don't like using several "entry points" to my home).
To "solve" this problem, the maxcube interface needs to keep the communication open!
Do you mean the TCP connection? What is the "maxcube interface" - which side do you mean?
Keeping a connection open would be a very simple fix. But what about a device (e.g. the raspberry) is restarting? Keeping a connection opened forever is not possible, regardless which software you are using.
Do you mean the TCP connection? What is the "maxcube interface" - which side do you mean?
Yes, keep the TCP connection to the cube open endlessly. Just reopen it, if lost. Problem with this is, that no other device can talk to the cube while this connection is open...
I can confirm too that this software (http://www.dmitry-kazakov.de/ada/max_home_automation.htm) is working properly. I have it installed and running since almost 2 years. No issues. @cs42 if your solution is working would be wonderful. We could try creating a custom component...if someone know how to modify the script
@cs42 if your solution is working would be wonderful. We could try creating a custom component...if someone know how to modify the script
Well, every other discussion I found (FHEM, openhab, other packages) suggests that this is the problem. I used FHEM myself for years and with "ondemand mode" (not keeping open the connection) I had this problem as well as with HA.
I'm using max_home_automation and connect it to HA via MQTT. This works but isn't as nice as the maxcube integration.
So @cs42, here is the component: https://github.com/syssi/maxcube
Maybe @syssi could help us with this 馃檹
The default scan interval is 300 seconds and can be changed by configuration:
At the moment the underlying library disconnects the gateway on every update:
https://github.com/hackercowboy/python-maxcube-api/blob/master/maxcube/cube.py#L79
So in order to leave the connection always open is only needed to modify that few lines here?
https://github.com/hackercowboy/python-maxcube-api/blob/master/maxcube/cube.py#L79
Yes. You could give it a try. Connect just once. Don't disconnect and connect again if the connection gets dropped.
By the way, looking at the code, better delete all lines inside update or simply delete line 83?
https://github.com/hackercowboy/python-maxcube-api/blob/master/maxcube/cube.py#L79
So i've tryed changing that few lines but still disconnecting
I also tried deleting line 83 - and in addition, as suggested somewhere else, lines 16-20 from connection.py.
Unfortunately, sHA still seems to disconnect from the cube.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 馃憤
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
Well, every other discussion I found (FHEM, openhab, other packages) suggests that this is the problem. I used FHEM myself for years and with "ondemand mode" (not keeping open the connection) I had this problem as well as with HA.
I'm using max_home_automation and connect it to HA via MQTT. This works but isn't as nice as the maxcube integration.