MAX! system installation and configuration walktrough

(Udo) #23

the cube itself has a “week program” in factory default.
So the “week program” of the cube overwrites the last setpoints from openhab eventually.

(Pekka) #24

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).

(Udo) #25

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.

(Alexander Köberl) #26

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 :grin:)

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"
	member of wz received command

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"
	Item wz_wt_setTemp changed  
	//or wz_wt_setTemp received update

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

(Pekka) #27

Moin Alexander,

sorry, I can’t help - I don’t own any Homematic thermostats, so I don’t know hoe to configure them.

(Udo Hartmann) #28

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"
    Member of wz received command
    if(!(receivedCommand instanceof Number)) return;
    if(!lock) {
        lock = true
            if(m.state != receivedCommand)
        lock = false

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.

(Alexander Köberl) #29

Hi Udo, Pekka,

thanks for your Answers :slight_smile:

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