polarity of contact sensor events

[justme-1968]

i have just added the fakegato-history to the homebridge-them platform plugin.

basic functionality is already very nice. but I have noticed some things:

• I think the documented polarity for the contact sensor events is wrong. at least I have to store 1 for closed and 0 for open. otherwise the graph and the list of events is inverted. maybe the values follow the style of the CurrentDoorState characteristic instead of the ContactSensorState style?

• as the contact sensor history will not work without the TimesOpened, SecondsOpened and SecodsClosed characteristics it would be nicht if fakegato would add them automatically and also cunt the events. the data is there :).

• the same would be true for the LastActivation

would you accept a patch that adds support for these three?

• maybe reset is also something that could be handed in fakegato then?

[ebaauw]

I think the documented polarity for the contact sensor events is wrong

Not in my experience. The value in the history entry is the value of the ContactSensorState: https://github.com/KhaosT/HAP-NodeJS/blob/414cd96ca9708596b1f71304bd4e6dff5ab045fc/lib/gen/HomeKitTypes.js#L386-L388. What plugin are you using?

the data is there :).

No, it's not. TimesOpened and LastActivation are characteristics of the ContactSensor service, not of the History service provided by fakegato-history. fakegato is unaware of any other services. Reset is a characteristic of the History service, but you need to reset TimesOpened when it's set.

Afaik, there's no TimesClosed characteristic.

[justme-1968]

hmm... very strange. I have to use 0 for window open and 1 for window close in the history.

if write a 0 then the detailed list in eve will display a line like '- opened' if I write a 1 then the line will change to '- closed'

so if I use the values from the readme the list will be wrong.

I'm using my own homebridge-fhem platform plugin: https://github.com/justme-1968/homebridge-fhem the last checking has switched to inverted values in regard to the fakegato documentation and now eve will show the graph and the ist correctly.

of course the data is there. in the same way fakegato adds the history service it could (optionally) add the other characteristics to the ContactSensor service. just give it in an optional parameter. addEntry would then calculate the values and expose them in the additional characteristics. in my option this would be better than every plugin implementing this on its own. especially as fakegato for contact sensors is not really usable without them.

regarding reset: I think it is also a characteristic of the ContactSensor. not of the history service. it relates to the reset of the TimesOpened characteristic not to the history list.

I'm not sure how the clearing of the history is handled at the moment. I think the clearing of the persisted data is missing from fakegato.

that was a typo. it should read TimesOpened, SecondsOpened and SecodsClosed.

[justme-1968]

I just noticed something ...

maybe the reason for the problem with the polarity is the meaning of window open/closed vs. contact open/closed.

most/all contact sensors used with fhem (that is homematic for example) will send a contact closed event if the door/window is closed. this is translated to a CONTACT_DETECTED homebridge state. but this would not match the fakegato documentation.

if you use sensors that use a reversed polarity (as it is also assumed in the alexa api) then it would match the documentation.

so maybe just the documentation should be changed to remove the ambiguity between contact closed and door closed. eve uses open/closed as in door/window closed for the history. not contact closed.

by the way: I think CONTACT_DETECTED for a closed window is much more fail save as it will report broken wires as an open window instead of a closed window.

[NorthernMan54]

Just watching this dialog and 100% agree on Alexa being backwards

https://github.com/NorthernMan54/homebridge-alexa/blob/7ac502614040b3509a369a7ea44e5784f2015e86/lib/alexaTranslator.js#L310

[justme-1968]

one more data point: homebridge-fhem will expose both ContactSensorState and CurrentDoorState characteristics for door and window contacts. this was historically the only way to be able to ask siri 'are the doors/windows open/closed'.

but it looks like this somehow brings eve to display the history for both characteristics. as it is the same history one is wrong.

i will do some more experiments.

[simont77]

Hi, concerning the polarity of the contact, I read it many times, but honestly I cannot see your point. For Homekit door open = contact open = 1 = CONTACT_NOT_DETECTED. Eve is consistent with Home.app. Fakegato docs says "Status can be 1 for ‘open’ or 0 for ‘close’. "

Concerning the extra characteristics, this is something we discussed in the past on slack. The main idea behind fakegato-history was to provide a way to display history in Eve, which was not obviuos at all. Instead managing the extra characteristics is something more standard, so we decided to leave it to plugin developers. Nonetheless, if you would like to propose a PR for optionally adding all the extra characteristics it would be fine. However right now I don't have so much time for coordinating this work. The key point is that all the additions must be completely backward compatible since a lot of plugin are using fakegato and probably already manage that characteristics by their own. Also, I makes sense only if all characteristics are provided for all accessory types supported by fakegato. One problem that I see here is that Eve Aqua manages this extra data in a completely different manner (see wiki).

[simont77]

but it looks like this somehow brings eve to display the history for both characteristics. as it is the same history one is wrong.

Eve internally marks histories using some unknown combination of accessory name, serial number and services/characteristics exposed. So probably in your case Eve is assigning the same history to both the characteristics. Keep in mind that Eve protocol was not designed for public use, so the more your accessory is similar to original Elgato’s ones, the more reliable and meaningful will be the behavior of fakegato.

[bwp91]

Sorry for dragging open a two year old issue but thought i’d add my comments in case this helps anyone in the future (as this thread has helped me today!).

From what I have noticed for an accessory with a GarageDoorOpener service and a ContactSensor service using the fakegato type door:

It seems that the status entry does indeed need to be reversed, probably to match the GarageDoorOpener target characteristic of 0 for OPEN and 1 for CLOSED (which in this case relates to 0 for contact not detected and 1 for contact detected, against the documented otherwise).

It’s probably fair to sum up that if the accessory has just the ContactSensor service then the documented entries 0 for detected and 1 for not detected are correct. But when the accessory has a second service like GarageDoorOpener or perhaps Door, WindowCovering then the entries for status need to be reversed.

Hope this helps anyone in the future that might be reading 👍