Thanks for the analysis, Bernd,
I did play around with allowing duplicates (not quite as you suggested, but similar). It was ugly, and as you say still didn’t work 100%.
I have come to the conclusion that the hidden door sensor will never be 100% reliable, and as such, should not be used wherever you need a reliable open/close indication (such as security). The same goes for the wireless open/close sensor, which has a similar problem.
They do work fine in situations where the open/close does not occur quickly, such as windows and sliding doors. The insteon network also works reliably (turning on/off lights etc).
The hidden door sensor has one very useful feature however, the ability to change the heartbeat timing, and enable repeat of open/close (every 5 minutes). The wireless open/close sensor also has the repeat open/close feature, but it’s much more difficult to enable as it’s not exposed in Houselinc.
What I have done is to install an Aeon Z-Wave hidden door sensor (which is 100% reliable), along with the insteon sensor. I now use the insteon sensor to initialize the Aeon Z-Wave sensor. The Z-Wave sensor is now the primary door status sensor (with insteon as backup).
So on openHAB startup, both sensors are Unintialised, but within 5 minutes, the insteon sensor repeats it’s status, which I then use to initialize the Z-Wave sensor status. It remains to be seen how this will impact the battery life of the insteon sensor.
I have also changed my closet door sensor to repeat it’s status every 15 minutes, so it gets initialized also (eventually).
In order for this to work, I had to modify the OpenedOrClosedContactHandler in MessageHandler, as the repeat messages and Heartbeat are sent to group 4 (contact status was being ignored in group 4 previously).
The new OpenedOrClosedContactHandler should work for single or dual group messages, for Leak Detector, Wireless open/close Sensor and the Hidden Door sensor. it also detects heartbeat, and requests battery status (only on repeat and heatbeat, not normal open/close actions). Battery status only works on the hidden door sensor (no battery state reported by the other sensors). It also traps “low battery” triggers sent to group 3. The feature is #contact, field=low_battery and is a decimal type == 1.
This is the new contact handler:
public static class OpenedOrClosedContactHandler extends MessageHandler {
OpenedOrClosedContactHandler(DeviceFeature p) { super(p); }
@Override
public void handleMessage(int group, byte cmd1, Msg msg,
DeviceFeature f, String fromPort) {
try {
byte cmd2 = msg.getByte("command2");
switch (cmd1) {
case 0x11:
switch (cmd2) {
case 0x02:
m_feature.publish(OpenClosedType.CLOSED, StateChangeType.ALWAYS); //for two groups reporting
break;
case 0x01:
m_feature.publish(OpenClosedType.OPEN, StateChangeType.ALWAYS); //for single or dual group reporting
break;
case 0x03:
m_feature.publish(new DecimalType(1), StateChangeType.ALWAYS, "field", "low_battery"); // low battery message
case 0x04:
sendExtendedQuery(f, (byte)0x2e, (byte) 00); //query battery state
m_feature.publish(OpenClosedType.OPEN, StateChangeType.ALWAYS); //periodic update (if repeat open selected)
break;
default: // do nothing
break;
}
break;
case 0x13:
switch (cmd2) {
case 0x01:
m_feature.publish(OpenClosedType.CLOSED, StateChangeType.ALWAYS); //if set to single group
break;
case 0x03:
m_feature.publish(new DecimalType(1), StateChangeType.ALWAYS, "field", "low_battery"); // low battery message
case 0x04:
sendExtendedQuery(f, (byte)0x2e, (byte) 00); //query battery state
m_feature.publish(OpenClosedType.CLOSED, StateChangeType.ALWAYS); //periodic update (if repeat closed selected)
break;
default: // do nothing
break;
}
break;
}
} catch (FieldException e) {
logger.debug("{} no cmd2 found, dropping msg {}", nm(), msg);
return;
}
}
}
It has been working fine for the last few days, but I haven’t done extended testing so far. my sensors, (Leak, open/close, hidden door) have been reporting correctly using this contact handler, but this is only a few days worth of data.
The new device I created is:
<device productKey="F00.00.03">
<model>2845-222</model>
<description>Hidden Door Sensor</description>
<feature name="contact">TestHiddenDoorSensorContact</feature>
<feature name="data">HiddenDoorSensorData</feature>
<feature name="lastheardfrom">GenericLastTime</feature>
</device>
And the feature is:
<feature name="TestHiddenDoorSensorContact">
<message-dispatcher>DefaultDispatcher</message-dispatcher>
<message-handler cmd="0x03">NoOpMsgHandler</message-handler>
<message-handler cmd="0x11">OpenedOrClosedContactHandler</message-handler>
<message-handler cmd="0x13">OpenedOrClosedContactHandler</message-handler>
<message-handler cmd="0x19">NoOpMsgHandler</message-handler>
<message-handler cmd="0x2e">NoOpMsgHandler</message-handler>
<command-handler command="OnOffType">NoOpCommandHandler</command-handler>
<poll-handler>NoPollHandler</poll-handler>
</feature>
In my more_devices.xml and more_features.xml files.
I think it would be worth updating the contact handler, as it should really have been trapping the contact status in group 4 (previously it was just updating the lastheardfrom date/time). I changed the StateChangeType from CHANGED to ALWAYS also, not sure if this matters, but I wanted to be able to track the updates.
Let me know if you think it’s worth updating the contact handler, and I think I should update the wiki to note the limitations of the hidden door and wireless open/close sensors. If you agree, I’ll do so.
Regards,