I use 1 sec refresh (because I "mis"use several window contacts) i.e. maximum frequency so that by itself also ain’t the problem.
In some ways it was good that I had the issue… could better understand the impact.
I successfully recovered my Max with the help of the backup file from OH.
In my case the C messages were not corrupted (hence the cube still knows which devices are linked), and I could simply recover the M message.
My steps:
Look for backup file (./userdata/max folder) that still has a M: line
e.g. in my case it was : M:00,01,VgIFAQRGaW5uFA8rAghiYWRrYW1lcgsNowMGc3pvbmphCMNJBAxzdHVkZWVya2FtZXIHtucFCVdvb25rYW1lcgAAAAUBFA8rTUVRMTQ1OTY5MQRGaW5uAQILDaNLRVEwNTQ0MjQyDXRoZXJtb3N0YWF0IDECAQjDSUtFUTA2NDg5NDkNdGhlcm1vc3RhYXQgMQMBB7bnS0VRMDE0NTE3Mg10aGVybW9zdGFhdCAxBAMOFcxMRVEwMDE1MzQwD3dhbmR0aGVybW9zdGFhdAUB
Connect manually to the cube (note if you have exclusive switched on, disable your Cube thing first in OH)
telnet 192.168.3.9 62910
Trying 192.168.3.9...
Connected to 192.168.3.9.
Escape character is '^]'.
H:KEQ0565026,0b5951,0113,00000000,1959b7ee,06,32,140310,0b18,03,0000
M:
C:0b5951,7QtZUQATAQBLRVEwNTY1MDI2AAsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly9tYXguZXEtMy5kZTo4MC9jdWJlAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwACAAAcIA==
C:08c349,0gjDSQEDGP9LRVEwNjQ4OTQ5KyE9CQcYAzAM/wAwVDEgMSAxIDEgMSAxIEUgRSBFIEUgRSBFIDBUMSAxIDEgMSAxIDEgRSBFIEUgRSBFIEUgMFQxIDEgMSAxIDEgMSBFIEUgRSBFIEUgRSAwVDEgMSAxIDEgMSAxIEUgRSBFI EUgRSBFIDBUMSAxIDEgMSAxIDEgRSBFIEUgRSBFIEUgMFQxIDEgMSAxIDEgMSBFIEUgRSBFIEUgRSAwVDEgMSAxIDEgMSAxIEUgRSBFIEUgRSBFIA==
C:07b6e7,0ge25wEEGP9LRVEwMTQ1MTcyKyE9CQcYAzAM/wBEYFMVUSBRIFEgUSBRIEUgRSBFIEUgRSBFIER4Ux1FIEUgRSBFIEUgRSBFIEUgRSBFIEUgREhOaETMUxxRIFEgUSBFIEUgRSBFIEUgRSBETlZqVs1THFEgUSBRIEUgRSBFI EUgRSBFIERITmhEzFMcUSBRIFEgRSBFIEUgRSBFIEUgREhOaETMUxxRIFEgUSBFIEUgRSBFIEUgRSBESE5oRMxTHFEgUSBRIEUgRSBFIEUgRSBFIA==
C:0e15cc,zg4VzAMFEP9MRVEwMDE1MzQwKyE9CURIVQhFIEUgRSBFIEUgRSBFIEUgRSBFIEUgREhVCEUgRSBFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSBFIEUgRSBFIEUgR EhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSBFIEUgRSBFIEUgBxgw
C:140f2b,0hQPKwEBEKFNRVExNDU5NjkxKiAwCQcYAzAM/wBAVU7aSP1BIEEgQSBBIEUgRSBFIEUgRSBFIEBVTtpI/UEgQSBBIEEgRSBFIEUgRSBFIEUgQFJMW0DZSP1BIEEgQSBFIEUgRSBFIEUgRSBAUkxbRLRI/kEgQSBBIEUgRSBFI EUgRSBFIERRTFtElkz9RSBFIEUgRSBFIEUgRSBFIEUgQFJMW0DZSP5BIEEgQSBFIEUgRSBFIEUgRSBAUkxbQNlI/UEgQSBBIEUgRSBFIEUgRSBFIA==
C:0b0da3,0gsNowICEABLRVEwNTQ0MjQyKyE9CQcYAzAM/wBMSlyETtdZGk8gTyBPIEUgRSBFIEUgRSBFIExKXIRO11kaTyBPIE8gRSBFIEUgRSBFIEUgSklgYkTkVRhFIEUgRSBFIEUgRSBFIEUgRSBKSWBiRORVGEUgRSBFIEUgRSBFI EUgRSBFIEpJYGJE5FUYRSBFIEUgRSBFIEUgRSBFIEUgSklgYkTkVRhFIEUgRSBFIEUgRSBFIEUgRSBKSWBiRORZGkUgRSBFIEUgRSBFIEUgRSBFIA==
L:CwjDSQkSGV86AAAACwe25wkSmGMqAMQADA4VzAkSGQQoAAAAwgsUDysJEhgAJgAAAAsLDaMJEhgtIgDBAA==
You can see the empty M: line there. Now copy the details from the backup after M:00,01,
send to the cube m:00, following the copied info from the backup. (example below)
m:00,VgIFAQRGaW5uFA8rAghiYWRrYW1lcgsNowMGc3pvbmphCMNJBAxzdHVkZWVya2FtZXIHtucFCVdvb25rYW1lcgAAAAUBFA8rTUVRMTQ1OTY5MQRGaW5uAQILDaNLRVEwNTQ0MjQyDXRoZXJtb3N0YWF0IDECAQjDSUtFUTA2NDg5N DkNdGhlcm1vc3RhYXQgMQMBB7bnS0VRMDE0NTE3Mg10aGVybW9zdGFhdCAxBAMOFcxMRVEwMDE1MzQwD3dhbmR0aGVybW9zdGFhdAUB
A:
q:
after this, the original M: info is restored and your cube is recovered from the memory loss. You can see it after disconnecting and re-connecting to your cube.
Note: This will only work if the cube still knows the C: info lines.
Also if you have many rooms, you have multilines for the m messages. you probably need to repeat similar for each m line.
Afterwards it makes sense to make a new backup by typing in the OH console smarthome:max backup
2 Likes
Has become !!
A few days ago, after almost 6 years of trouble-free operation of the entire MAX! system, I joined the group of owners of "EQ-3 MAX! CUBE Alzheimer version ".
I broke the iron rule “if something works fine, don’t update it !!!”
Maybe it is just a coincidence and that has nothing to do with it … but it all started with the upgrade .
As suggested by openhabian-config - “openHABian Update Available” - I updated the entire system and switched from OH2.4 to 2.5.4
Effect:
I noticed a slowdown in the response to the commands issued, which, as it turned out later, was due to the continuous booting and stopping of the entire system.
Log entries below:
2020-04-29 22:49:44.938 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection
2020-04-29 22:49:44.949 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 010101010101010111111, base URL = http://localhost:8080)
2020-04-29 22:49:45.403 [INFO ] [panel.internal.HABPanelDashboardTile] - Stopped HABPanel
2020-04-29 22:49:45.531 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Stopped HABmin servlet
2020-04-29 22:49:45.671 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
.
.
.
2020-04-29 22:49:55.983 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = bleble, base URL = http://localhost:8080)
2020-04-29 22:49:57.754 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2020-04-29 22:49:58.343 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2020-04-29 22:49:58.516 [ERROR] **[core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-misc-restdocs'**
.
.
.
2020-04-29 22:50:43.626 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection
2020-04-29 22:50:43.634 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 010101010101010111111, base URL = http://localhost:8080)
2020-04-29 22:50:44.040 [INFO ] [panel.internal.HABPanelDashboardTile] - Stopped HABPanel
2020-04-29 22:50:44.187 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Stopped HABmin servlet
2020-04-29 22:50:44.367 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
.
.
.
2020-04-29 22:50:51.943 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 010101010101010111111, base URL = http://localhost:8080)
2020-04-29 22:50:53.732 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2020-04-29 22:50:54.445 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2020-04-29 22:50:54.630 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-misc-restdocs'
.
.
.
2020-04-29 22:51:43.935 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection
2020-04-29 22:51:43.941 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 010101010101010111111, base URL = http://localhost:8080)
2020-04-29 22:51:44.334 [INFO ] [panel.internal.HABPanelDashboardTile] - Stopped HABPanel
2020-04-29 22:51:44.470 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Stopped HABmin servlet
2020-04-29 22:51:44.610 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
2020-04-29 22:51:52.241 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 010101010101010111111, base URL = http://localhost:8080)
2020-04-29 22:51:54.099 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2020-04-29 22:51:54.627 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2020-04-29 22:51:54.824 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-misc-restdocs'
Over and over again.
And it was preceded by several errors that appeared
2020-04-29 22:43:55.376 [INFO ] [nternal.handler.MaxCubeBridgeHandler] - No Rooms information found. Configure your MAX! Cube: 192.168.1.130
.
.
.
2020-04-29 22:44:07.313 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-persistence-mapdb, openhab-ui-homebuilder, openhab-misc-openhabcloud, openhab-misc-restdocs, openhab-binding-network, openhab-binding-max, openhab-binding-weather1, openhab-ui-habpanel, openhab-binding-yamahareceiver, openhab-binding-weatherunderground, openhab-transformation-jsonpath, openhab-binding-mqtt1, openhab-binding-wifiled, openhab-binding-chromecast, openhab-binding-mqtt, openhab-persistence-rrd4j, openhab-transformation-map, openhab-ui-basic, openhab-ui-habmin, openhab-ui-paper': Error restarting bundles:
Exception in org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start() of bundle org.openhab.core.io.rest.sse.
The final result:
-
MAX!Cube is not visible in the oryginal dedicated application -> it does not detect it, “First start” starts - _ time zone …
-
MAX!Cube is not visible in alternative app MAX! Home automation 3.15
-
MAX!Cube is visible in OH, detected as a THING by OH Binding but doesn’t auto detects any ITEMs. Thermostats, contacts switches …
Everything is seems to be strange because:
-
MAX!Cube is visible on the network (ping responds)
-
!!! THIS IS THE MOST WEIRD !!! MAX!Cube logic still working - communicates with paired devices - closes the thermostat’s heads after signal “window open” from window contact switches, realizes the weekly schedule…
-
Inability to restore factory settings (HOLD reset buton + reconnect power cord) done several times - to no resoult.
-
telnet 192.168.1.130 62910 return something like this:
H:NEQ1442106,17d453,0113,00000000,7eb68bf9,00,32,140504,1433,03,0000 M:00,01,VgIAAAE= C:17d453,7RfUUwATAQBORVExNDQyMTA2AAsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly9tYXgtcG9ydGFsLmVxLTMuZGU6ODAvbG9va3VwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwACAAAcIA==
L:
Help pls
Jack
What makes you think that? All these actions don;t require communication with the Cube.
Based on your description & telnet output indeed your device has been reset to factory.
You need to pair your devices again to get it to work.
If the original software does not see it you can try to go once more in telnet and type a: followed by return. This will reset the device once more.
My cube got hung. The M: line was empty and I was able to reconstruct it thanks to your post.
But there’s only 1 C: line and L: is also empty.
It still does not work (devices blink 3x and hourglass forever in MAX! software as well) so I fear I have to completely reset it again and relearn the devices.
As I have the backup files, can I reconstruct C:, too ?
I tried but it doesn’t take 'em like it took M:
Indeed you can’t reconstruct the c line by just sending it. If I remember well during the configuration it sends about 10 lines for it:
- 7 lines for the program of each day
*2 lines for the settings - 1 or more to define the room definition
In my case it still remembered the C line and had a L line so reconstruction was simple.
In your case it ’ forgot’ these as well meaning it does not know the devices anymore.
So far I did not manage to find a way to let the cube remember thermostats it forgot without doing a new device search.
speaking of the devil… my cube also now got memory loss and forgot the devices 
I can now confirm you can’t restore the cube by sending commands only. I knew already sending the m: command was not enough… that is just the room info.
I now tried to send the linking commands to the Cube (s:…) but it will not see it as linked. You really have to re-do the discovery in order to have the cube know the thermostat again. (the stupid thing is the thermostat still think the it is linked to the cube…)
It is technically possible to restore the settings after the thermostat is discovered again, but that requires quite some development. This is really a firmware bug that EQ3 should fix… but I’m no so confident they ever will. (read: I’m confident they wont fix this anymore)
Marcel your efforts are highly appreciated. Thanks a lot.
Just as an idea, did anyone around ever check if HomeMatic CCU is compatible with MAX!, could we replace the cube ?
You could also reflash your CUBE to a CUNx and use togesther with homegear and homematic binding.
A HOWTO can be found here
I had it running successfull for a while but now replaced my Max! devices with Z-Wave.
Just came across this and wonder why that happened out of the blue ?
I use exclusive connection to the cube so as that’s in use by the binding, no 2nd connect is possible. But why was the discovery triggered ? No it wasn’t me 
I restarted the binding bundle. Could that have caused that ?
2020-07-10 14:07:15.198 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - Run MAX! Cube discovery
2020-07-10 14:07:15.203 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - IO error during MAX! Cube discovery: Die Adresse wird bereits verwendet (Bind failed)
2020-07-10 14:07:15.204 [DEBUG] [nal.discovery.MaxCubeBridgeDiscovery] - Done receiving discovery messages.