I am new to this OpenHAB and still fumbling a bit, but I have an issue with the Basic UI SetPoint feature.
I have configured my sitemap to contain SetPoints for my 5 MAX! thermostats connected to my MAX! Cube LAN Gateway.
The MAX! Cube LAN gateway communicate with other units in the eco-system using a 868,3 Mhz radio frequency, which has a broadcast usage limit imposed. The limit can read as a duty_cycle value on the cube itself.
The problem is that when the Cube hits 100 in duty_cycle then its banned from broadcasting untill it gets below 100 again.
What I noticed with my Basic UI setup is that the SetPoint feature eats duty_cycles like crazy.
f.ex. if I change a MAX thermostat from automatic to manual mode, then it will default to a SetPoint temperature of 20, but if I want to have it at 17 instead, then I have to click the buttons to get it to 17.
Those steps happens in increments of 0,5 and I end up clicking the button 6 times.
The problem is that each of those 6 clicks sends a command to the Cube that will then send a command out on the 868,3 Mhz band and thereby eat up duty_cycles.
When 5 thermostats have to go through this process the MAX Cube will hit the 100 mark quite fast.
What I would like is a delayed send, so you set your temperature and then you click a new checkmark button that will actually send the temperature.
Hope this makes sense to you.
I’m using Homematic thermostats, developed by the same company. For my thermostats I set
delay = 5,
for the thermostat thing SET_TEMPERATURE channel. This only sends the actual new SET_TEMPERATURE value with the 5 seconds delay, allowing me to change the SET_TEMPERATURE without issuing many temperature changes immediately.
This might also be possible with the MAX! binding. Have a look in the SET TEMPERATURE channel (pencil / edit icon) of your thermostats.
Thanks for the reply, Hans.
I tried to figure out where I should put that delay in, but I can not seem to find a place for it.
I looked at both the thermostats in the Things section and the available variables listed in the Items section, but found no place for a delay to be put in.
If you do have to “do it yourself”, you might use a proxy Item and perhaps a delay for automation.
Put the proxy Item on the sitemap.
A rule can update this Items state from the real Item, for display.
Another rule can trigger from UI initiatiated commands to the proxy Item, and start a timer.for say 2 secs. Each new command reschedules the timer.
Only when the timer expires, transmit the most recent command to the real Item.
Thanks for the idea, rossko57.
I understand the idea you are suggesting, but I still lack the bigger picture of even the basic commands in OpenHab and associated extensions, so I have no clue yet on how to actually make a proxy item and the needed rules.
Do you have a link to a guide or just some info about it?
MAX! binding is not suppose to send all 6 clicks, it is suppose to discard the in-between temperature changes. Looking at the code I see that this behavior indeed was broken in the mean time as the commands are send too fast to be discarded.
I made small PR to restore this old behavior, if you send multiple temp updates, the in-between ones will get discarded, the first and last one will be send. (wait time is 5 seconds…so any temp update in between will be discarded)
Good to hear.
How do I get that new version?
Even though it is a oneliner, It is still in review
Once accepted / merged you can download & install the snapshot version