Design Pattern: Associated Items

You have it backwards.

Rooms.members.forEach[room |
    val target = TargetTemps.members.findFirst[r | =="_Target"]
1 Like

by the way, on the same note - is there a way to remove letters from the

like I have Kithchen_Temp and Kitchen_TargetTemp, so I would need to remove from Temp and add TargetTemp. otherwise, I guess I just need to create items with plain room names?

Of course, you can split things apart and recombine them all you want. See

However, you will have to weight the pretty significant increase in code complexity for, IMHO, dubious benefit. Given that the names of Items are something that only you see in the code, I would recommend sticking with a naming scheme that makes your code simpler rather than making the names more aesthetically pleasing to the reader.

1 Like

In the first post, the first DSL example have a small error. The trigger line is before the ‘when’ and ‘then’…
I believe it should be:

rule "A Door's State Changed"
    Member of gDoors changed
    if(previousState == NULL) return;
    postUpdate("_LastUpdate", now.toString)
1 Like

Lights in my home automation setup may be controlled multiple ways: by a physical switch hardwired to the light, by a button on a UI screen, or by a rule in response to some other events. To keep it simple, I combine the design patterns for Proxy Items, for Groups and for Associated Items. I define rules for the desired behavior at the level of a group, and then assign the lights to that group.

With this setup, the proxy item will always correctly reflect the status of the light, independent of what caused that status (command from a rule, gesture on a physical control, gesture on a UI element).

A more detailed description can be found here.

1 Like