random setpoints, no setpoint at all (problem "duty cycle"???)
prankousky opened this issue · comments
Hi everybody,
I have been testing this flow and it works great - for the query part at least. I get all relevant data from my maxcube and all its connected thermostats and window sensors.
However, setting temperature does not always work properly. I have already reset the maxcube itself so assure that no old timers triggered temperature changes. However, some thermostats get seemingly random values at times.
I also have some rules like "if bathroom window is open, set bathroom thermostat to 5 degrees", which is triggered every 20 seconds to assure thermostats are definitely at minimum heat when the appropriate window is open. I understand that 20 seconds could be a bit much, so I put an RBE node in between (so if a window is open, no further value is set after temperature has been set to 5 degrees until the setpoint value changes).
I did some research and found this https://www.elv.de/faq/max-cube-lan-gateway-dauer-der-signaluebertragung.html Apparently, each thermostat can only send and receive so many commands per hour. While this should generally not be a problem, it definitely is while setting things up and testing rules. This is called "duty cycle" and systemctl status nodered.service even gives an output on the duty cycle (after manually restarting the max cube these values are reset).
While I kept working with this flow over the past week, I have had some good experiences (everything worked as expected) and some really bad ones (window being open but thermostat not accepting injected 5 degree value and staying at high value WHILE window open).
Is there a fool-proof way not to have the entire max-cube ignoring my commands even though I have a lot of rules (window status- and time-based ones)?
Tbh I am considering to connect the max cube to a smart outlet and have it power off and back on based on the duty cycle output grabbed from the systemctl status command. However, if there is a better way, I'd like to go with that one.
Today was so bad (some thermostats not reacting at all, one did even not accept the change from "manual" to "auto" via MANUAL BUTTON PRESS until I reset the thermostat AND max cube itself) that I switched back to the max app... but I would really really like to have node-red handle my thermostats, so if this is a user error, I'd like to know what I could improve on.
I grab the maxcube output every x (usually between 30s and 2min) and write the values for window open/closed, setpoint, temp, and battery_low for each device; then I automatically inject setpoints at 2 to 5 times a day at static times. Then one flow only checks if each window is open (every 10s) and if so, it will set that thermostat to 5; however, in order to not set it to 5 every 10s, there is an RBE to limit the 5 degree injection to one time until the setpoint changes. Manual changes come in via mqtt and happen without a delay.
So that being said, I definitely do not exceed 34 setpoints per hour per thermostat! Yet sometimes thermostats are not being addressed at all when I do send a command, or just random setpoints "appear" on different thermostats; for example, I did not send any new value to the living room thermostat, nor was there an automatic timer to change its value. But it still changes its setpoint to some value I cannot understand why it would.
Thank you in advance for your help. Any input to solve this problem is greatly appreciated, as I would really love to finally use node-red and maxcube together. I tried with the previous flow and had no success, now there is this great flow that does everything I need it to reliably, but I still cannot use it due to these random errors.
Cheers 👍
Hi thanks for your feedback,
I also noticed that max! thermostats react badly on some conditions and it's protocol is error prone:
- concurrent access of 2 or more clients will cause trouble (for example node-red and official pc app.). In extreme conditions the cube won't respond until you power cycle it. I even disabled remote access from https://max.eq-3.de, just in case...
- Sometimes republishing node-red flows causes some errors on the cube and over the last year i had to reboot a couple of times.
- After a electrical leakage my cube won't boot in a clean way if node-red starts pulling data before the cube is fully functional...and again...i have to power cycle...or delay the first call to the maxcube node in node-red.
Regarding the window switches, are you using the eq3 one? In that case the "window open mode" should be automatic and handled by the cube, so no need to inject setpoints to put the termostats in pause, or am i wrong?
Pay attention also on injecting setpoints which are outside the thermostat bounds: every device has its own max and min setpoints (configurable only via official app at the moment, since the library actually sends a partial "S-Message" with Command 10 and i'm not sure it implements Command 11).
I happy to help you but i have to say that this project is merely a wrapper of the maxcube/maxcube2 library and the protocol itself is pretty rigid and at the moment not fully implemented in the library.
with 0.1.3 (commit 91a4a5a) all the nodes will have a comm_status property on output containing duty_cycle and free_slot. Hope it helps you to debug your flows.
In my case it helped and i noticed that over 95% the cube won't respond to any "set" command.
Hello, i have the same problem that when the windows get opened and the xiaomi-sensors detect this,
i send {
"rf_address": "1a6e46",
"degrees": 12,
"mode":"MANUAL"
}
and nothing happend. Under the iobroker-Forum is an Java-Script which handels with MaxCube-Devices
very well. What do they different? I´m using the script with the maxcube-adapter for the iobroker and it nerver fails to set the temperature. Maybe you can contact the developer?
here is the forum: https://forum.iobroker.net/viewtopic.php?t=10096
Kind regards Klaus
I'm not familiar with that ioBroker script but I tried to read that topic with google translate. They reference the EQ3 CCU and for the EQ3 Max Cube it seems to use the ioBroker maxcube adapter (which should be GermanBluefox's maxcube fork ). This plugin relies on another maxcube fork: normen's. They both share the same core...
At the moment I really can't say why it isn't working for you, sorry.
Try to monitor the duty_cycle value on maxcube output node; if you send too many commands it may saturate the traffic of the maxcube.
"comm_status": { "duty_cycle": 18, "free_memory_slots": 49, "valve": 0 } }
Hello maxill1,
now it´s workung fine. I didn´t defined the output as Json. Now with this the temperature chnged:
Kind regards and thanks for your help
Good news and thanks for your feedback.
I'm closing the issue then.