the cube itself has a “week program” in factory default.
So the “week program” of the cube overwrites the last setpoints from openhab eventually.
The thermostats have a week program which is written by the cube, yes. That is exactly what you want: Use OpenHAB to set the current temperature to a new value, without disturbing your schedule.
If you want to get rid of the weekly schedule, set the thermostats into manual mode as decribed above (Section "Usage in rules).
Thx!
I afraid that but I found it a bit strange to see allways manual mode on the display.
Someone could try to press the auto button on the thermostat.
But I’ ll do that manual now.
Many many thanks for this tutorial Pekka, It helped me a lot this evening to do a basic configuration on new homematic thermostates. But there are still unanswered questions about grouping of thermostates for me.
I’d like to group 4 heating thermostates in a room (4 radiators) with one wallthermostate (Yes its a big room 
)
With this group I’d like to change the temperature of all radiators just with setting a new temperature at the wallthermostate, in fact directly at the termostate at the wall, and here in openhab at its corresponding item.
I had massive Problems with rules like:
rule "Wohnzimmer Temp Change Example"
when
member of wz received command
then
wz.sendCommand(receivedCommand)
end
Then the temperatures of all rooms items “jump around”… I guess this is because change of a item of a room then affects “itself”, so I changed rules to much more code version like:
rule "Wohnzimmer Temp Change Example"
when
Item wz_wt_setTemp changed
//or wz_wt_setTemp received update
then
wz_ht1_setTemp.sendCommand(receivedCommand)
wz_ht2_setTemp.sendCommand(receivedCommand)
[...]
end
I tried rules with “received command” / “received update” / “state” but I fail with everything I try.
Best case for all this would be: any change on any thermostate (real change on hardware, not in openhab) changes the groups setting in openhab (like a regular max or homematic roomconfiguration does)
Do you or anyone of you guys have a working example for this?
Thanks a lot
Alex
Moin Alexander,
sorry, I can’t help - I don’t own any Homematic thermostats, so I don’t know hoe to configure them.
As you want to send a command to a group of members by using a rule which is triggered through a received command to this rule, it’s like a endless loop, the rule is triggered by its own action.
One option would be to define a master thermostat and a group of slaves. Another option is to lock the rule.
var Boolean lock = false
rule "set wz members"
when
Member of wz received command
then
if(!(receivedCommand instanceof Number)) return;
if(!lock) {
lock = true
wz.members.forEach[m|
if(m.state != receivedCommand)
m.sendCommand(receivedCommand)
]
lock = false
}
end
As a first step, the rule ensures that the received command is of type Number. If not, the rule is immediately stopped.
The second step is to test if the rule is already running (i.e. lock is true) If not, the group members are iterated and each item is checked, if the state is already the right one. if not, the new state is sent.
Hi Udo, Pekka,
thanks for your Answers 
Yes Udo I understand I created a kind of loop causing the first problem. Thanks for your Info with the lock, I think I will try it when I start over again. My First decision was to use a CUL and the Thermostates only. First I was motivated to do all the programming for creating “groups” by myself. But I noticed there are many complicated things for building a stable working group. Meanwhile I ordered a CCU2 (it’s like the “Cube” at the Max system) to controll the homematic components. I found out its much easier to use the CCU2 for the grouping and using the “virtual device” / room-group in openhab).
I have a very stable system running now with very small code.
This is what I can recommend to all homematic thermostat users who want to get a good result in short time. But there’s also something bad when using the CCU2 for grouping:
When directly accessed with a CUL all homematic thermostates offer more usefull information like “valve state”, “battery voltage”, … for every single thermostate . When using the CCU2 for grouping there’s much less information. All this information is filtered in the CCU2 and just a Battery State if there’s one low-voltage-thermostate in the group is pushed to openhab. So i’ll give it anoter try soon…
Thanks guys
Many thanks, this was extremely helpful for a bloody beginner. Was able to successfully add and configure all my Max! devices. Next will be the sitemap, which currently isn’t working but I’ll spend a bit more time on that and hope to get it to work soon.
Let my know if I can buy you a coffee or beer as a little way of saying thanks to you.
What I was wondering in addition were two things:
-
Is there any way to edit the weekly heating schedule through OpenHAB? I would like to have at least two different plans to switch between (e.g. regular work weeks and holiday weeks). Furthermore my regular software isn’t able to connect to the Cube as before, I assume that this is because of OpenHAB accessing the cube…
-
Any idea how to just modify the heating for the next morning in one room? Example: Usually the bath should be heated at 7am. On some occasions we need to get up earlier and use the bath already at 6am. What would be perfect was an easy way to tell the system in the evening before to heat the bath at 6am the next morning, without having to change the whole weekly plan. Any ideas?
Cheers,
Joseph
Unfortunately not. You can, however, quit using the cube for the schedules and define your schedules completely using OpenHAB rules. Disadvantage: the thermostats are in manual mode, that means if anything goes wrong (cube down, OpenHAB hickups) they stay in the latest state.
Indeed. You can switch off exclusive mode:
Use a “dummy” switch “EarlyBird”. Check at 5.30 (enough time to heat up the room before 6 am) if the switch is set to “on”. If yes, set the heating on, turn the switch off (ready to be used the next day). The thermostat should remain in “Auto” state, so the schedule takes over on the next scheduled event (heat at 7.00)
rule "Early bird heating"
when
Time cron "0 30 05 1/1 * ? *"
then
if(Earlybird.state == ON) {
Earlybird.sendCommand(OFF)
maxSetTempBath.sendCommand(23)
}
end
(untested, may contain errors, but you can use this as a starting point)
Thanks! Great work!
U used it in my installation.
Could you also post this two icons (i could cut them by my self, but they are with grey background here).
Has anyone flashed the MaxCube to a CUL?
After my MaxCube fully lost its configuration (requiring a new pairing of each and every device, reconfiguring everything, including rooms, temperaturs and weekly heating plans) two times this week, I am rather unhappy with the reliability.
I am therefore considering to flash the Cube to a CUL, which should solve this. Im am wondering about the following:
-
Would this affect the existing configuration in accordance with this tutorial (other than the need to install the CUL Binding)?
-
As the “traditional” Max Interface would be gone, do I assume correctly that editing the weekly schedule would only be possible by writing the code?
EDIT: Just noticed, that I should probably ask a lot more basic question first: Is there something like a weekly program after flashing to CUL or would everything have to be done via rules?
Cheers,
Joseph
Search the forum for my instructions howto flash a Cube to CUL. All your questions are answered in that conversation.
1 Like
Does anyone know how to show average (from all thermostats) temparature in sitemap?
You can find it in docs under Items/Groups
Group:Number:AVG Temperatures "All Room Temperatures [%.1f °C]" // e.g. "21.3 °C"
Just add your Items to this group.
1 Like
Many thanks. I had seen your instructions but had not looked very diligently through all anwers. In one of them I found the information that weekly schedules are not natively supported after flashing anymore but would require either using Homegear or rules in OpenHAB.
Many thanks!
The gys of homegear have a nice scheduler in the newly introduced Admin-UI, but it is available in the nightlys only.
It would be to difficult to have this build into openhab, cause there are so many different hvac systems and each of them uses a different way to setup week schedules.
So for me it is absolutely fine to use this functionality offered in homegear, as it stores the result in the devices, just like MAX! software did.
Perfekt!
Thanks a lot!
Hello,
helpfull guidline. Everything works fine.
But, I have 4 rooms - 3 are showing the icons - 1 not?
Why?
I made the .items 4 times - nothing changes.
Sorry Ansgar, I don’t get your point here…