Don't forget the windows 08 - it's moving!

I was rather slow in getting my Farnell order together, so the parts arrived end of last week. Since I had no time over the weekend, I got a deeper look at them only on sunday evening. Most important part are the three additional STM310 contact sensors I needed for all the windows to be monitored.

Some more sensors and stuff

EnOcean was so kind to send me enclosures for all of them (and one for the STM330, and one HSM100 sensor), so the problem of mounting them is now solved. And it looks much better, which increases the wife-acceptance-factor

From top to bottom:

• a case with the bottom lid closed (so its ready to be mounted)
• a case from the top side, with just the solar cell visible
• a lid - the stud in the middle holds the PCB in place, and the small hole beneath id allows to press the button (on the STM330 at least)
• the STM310 contact sensor in the case - there is extra room for the antenna
• the STM330 temperature and humidity sensor in the case - here the lid will not fit without modification

I should have asked EnOcean whether they also have the corresponding magnet enclosures, since they also don't seem to be available standalone. Btw: there are a many companies out there the provide sensors witn EnOcean technology, so there are also different kinds out there (e.g. door handles which signal their current state).

Working with OpenHAB rules

Having now multiple contact sensors, I could go ahead and create a OpenHAB rule system that provides an overall state for all windows.

First, I added a new item:

String WindowState "State [%s]"

Then this item must be added to the sitemap:

Frame label="Window State"
{
    Text item=WindowState
}

And the last step was creating a rule that gets triggered when any of the window contacts changes state:

import org.openhab.core.library.types.*
import org.openhab.model.script.actions.*

rule "Windows"
when
    Item sensor_CONTACT1 changed or
    Item sensor_CONTACT2 changed or
    Item sensor_CONTACT3 changed or
    Item sensor_CONTACT4 changed
then
    if ((sensor_CONTACT1.state==OPEN) || (sensor_CONTACT2.state==OPEN) || (sensor_CONTACT3.state==OPEN) || (sensor_CONTACT4.state==OPEN))
    {
        postUpdate(WindowState,"open")
    }
    else
    {
        postUpdate(WindowState,"closed")
    }
end

Unfortunately the rules can be triggered by items only (or be time- or system-event-based). So it looks like its not possible to create a rule that gets triggered by an update to a group (or one of the items in a group). That means whenever a new sensor is added, not only the list of items but also the rule must be updated. No nice...

Having this rule in place, and waiting for OpenHAB to reload all changes, the main window ends up in (with all but one contact closed):

Optimizing that rule

The language underneath that rules is really powerful - its based on the Eclipse xtend framework which in turn is based on Java. So the condition from above could be written as:

if (Windows.members.filter(w | w.state == OPEN).size > 0)

which reads much cleaner.

And after taking a closer look at the examples, Groups are handles as items indeed. So the condition now looks also much simpler:

when
    Item Windows changed
then

with 'Windows' being the group where exactly all the window contact sensors are in. Neat!

I also verified that the summary item 'WindowState' can also be listened to with the REST API, so my Android application can utilize that one.

One thing I noticed while doing the experiments: the sensor state was not always transmitted right away, but seemed to got lost. So probably I will reconfigure the sensors to do more that one retransmit when their state changes.