Added mappings for event, state, and contact_open for Honeywell 58XX devices in rtl_433_mqtt_hass.py

[dmz006]

Author:David M. Zendzian ([email protected])
Date: Wed Mar 20 00:34:00 2024 -0500

Added mappings for event, state, and contact_open for Honeywell 58XX devices.

• Event is an event ID. I've not mapped them yet but I've seen 0, 4, 60, 57, 120, 128, 248 and others as the devices change state
• State is either "open" | "closed" and corresponds to the state of the door sensor
• contact_open appears to be tied to state

On the 5800 devices I tested alarm state did not correspond with device state or contact_open and doesn't appear to change with opening or closing door/window

[zuckschwerdt]

"state" is legacy and should not be used. "event" is a code that is then broken down:

rtl_433/src/devices/honeywell.c

Lines 96 to 103 in afb5b34

	// decoded event bits: CTRABHUU
	// NOTE: not sure if these apply to all device types
	contact = (event & 0x80) >> 7;
	tamper = (event & 0x40) >> 6;
	reed = (event & 0x20) >> 5;
	alarm = (event & 0x10) >> 4;
	battery_low = (event & 0x08) >> 3;
	heartbeat = (event & 0x04) >> 2;

[dmz006]

Thank you for the info on the event. Not sure if that is helpful or not; but it's not captured in mqtt_hass so not sure

State may be legacy; but what about older devices? The devices in my house do not use the alarm state (they never change); only state or contact_open changes when magnet moves from sensor (or when motion sensor sees movement).

What do you suggest I do? I can't change out the devices and get non-legacy devices. And the one new device I have appears to function the way the older devices do.

Is there any history on the state being legacy or not? I searched past PR and didn't find anything.

{"time" : "2024-03-20T05:56:31.255725-0400", "model" : "Honeywell-Security", "id" : 390678, "channel" : 8, "event" : 124, "state" : "closed", "contact_open" : 0, "reed_open" : 1, "alarm" : 1, "tamper" : 1, "battery_ok" : 0, "heartbeat" : 1, "mic" : "CRC"}

Or this example; for the same device, the state/contact_open and event change but alarm, reed and others do not
{"time" : "2024-03-20T05:52:15.564504-0400", "model" : "Honeywell-Security", "id" : 945266, "channel" : 8, "event" : 128, "state" : "open", "contact_open" : 1, "reed_open" : 0, "alarm" : 0, "tamper" : 0, "battery_ok" : 1, "heartbeat" : 0, "mic" : "CRC"}
{"time" : "2024-03-20T05:52:15.624784-0400", "model" : "Honeywell-Security", "id" : 945266, "channel" : 8, "event" : 0, "state" : "closed", "contact_open" : 0, "reed_open" : 0, "alarm" : 0, "tamper" : 0, "battery_ok" : 1, "heartbeat" : 0, "mic" : "CRC"}

One other example from a device with a weak battery (which is my guess on why it can't read state of tamper - new batteries arriving tomorrow)
{"time" : "2024-03-20T04:58:48.505590-0400", "model" : "Honeywell-Security", "id" : 390678, "channel" : 8, "event" : 248, "state" : "open", "contact_open" : 1, "reed_open" : 1, "alarm" : 1, "tamper" : 1, "battery_ok" : 0, "heartbeat" : 0, "mic" : "CRC"}
{"time" : "2024-03-20T04:58:57.307090-0400", "model" : "Honeywell-Security", "id" : 390678, "channel" : 8, "event" : 120, "state" : "closed", "contact_open" : 0, "reed_open" : 1, "alarm" : 1, "tamper" : 1, "battery_ok" : 0, "heartbeat" : 0, "mic" : "CRC"}

In watching the data from RTL I never see alarm change value; in fact I have devices where alarm is 1 and some where alarm is 0; but the value for alarm never changes. However the value for state and contact_open changes.

What do you suggest I monitor? And is this functionality what is expected??

[dmz006]

In looking at the event code you shared and the events from the last post:

Using this exampe: {"time" : "2024-03-20T05:52:15.564504-0400", "model" : "Honeywell-Security", "id" : 945266, "channel" : 8, "event" : 128, "state" : "open", "contact_open" : 1, "reed_open" : 0, "alarm" : 0, "tamper" : 0, "battery_ok" : 1, "heartbeat" : 0, "mic" : "CRC"}

Event code of 128 or in binary 10000000

to simplify the code shared above for event:

• 0x80 == 10000000 - contact
• 0x40 == 01000000 - tamper
• 0x20 == 00100000 - reed
• 0x10 == 00010000 - alarm
• 0x08 == 00001000 - battery_low
• 0x04 == 00000100 - heartbeat

leaving 2 bits for future code??

So the event above 128 in hex is 10000000 which makes sense that the contact would be open as the state and contact show open.

However how come the alarm is 0? Shouldn't the alarm be 1 if the contact and state is open?

Other codes I've seen include:

• 0 == 00000000
• 4 == 00000100
• 28 == 00011100
• 36 == 00100100
• 52 == 00110100
• 124 == 01111100
• 128 == 10000000
• 188 == 10111100
• 132 == 10000100

{"time" : "2024-03-20T05:52:16.958049-0400", "model" : "Honeywell-Security", "id" : 945266, "channel" : 8, "event" : 0, "state" : "closed", "contact_open" : 0, "reed_open" : 0, "alarm" : 0, "tamper" : 0, "battery_ok" : 1, "heartbeat" : 0, "mic" : "CRC"}

Here the event is 0; but battery_ok is still 1; should't it be 0 with all bits to 0?

I searched through my logs for all that said the state or contact was open and the following events were used in those states:
128 == 10000000 == contact
132 == 10000100 == contact & heatbeat
188 == 10111100 == contact & reed & alarm & battery_log & heartbeat
248 == 11111000 == contact & tamper & reed & alarm & battery_low

All of these had state open and contact open in the logs and the alarm/reed_open/tamper/battery_ok and heartbeat all appear to match the right state for this.

How can I have some in alarm state, some not, but all have the contact & state as open - and some have reed open and some closed; but all are still in open state.

Alarm & reed_open appear to match in state, but the open/closed state (legacy code) and the contact_open do not match alarm or reed state.

Last example
{"time" : "2024-03-20T03:38:30.249932-0400", "model" : "Honeywell-Security", "id" : 405702, "channel" : 8, "event" : 188, "state" : "open", "contact_open" : 1, "reed_open" : 1, "alarm" : 1, "tamper" : 0, "battery_ok" : 0, "heartbeat" : 1, "mic" : "CRC"} {"time" : "2024-03-20T03:46:45.557065-0400", "model" : "Honeywell-Security", "id" : 523010, "channel" : 8, "event" : 132, "state" : "open", "contact_open" : 1, "reed_open" : 0, "alarm" : 0, "tamper" : 0, "battery_ok" : 1, "heartbeat" : 1, "mic" : "CRC"}

2 different devices; both states and contact_open are 1; however reed and alarm don't fully match.

Any help understanding this is much appreciated.

[dmz006]

If a device is using the internal reed and magnet I am thinking maybe that is why we see the reed ones; and if it's using an external magnet connected to junction box then would that be the contact?

Just trying to grok this.

Also; if contact is part of the coding in rtl; shouldn't it be exposed in mqtt_hass? I would be OK with state being legacy if I can get the contact info as that appears to be the same for what I need.

Any idea what causes alarm to be tagged? It appears to me by some quick searches that alarm is tied to reed_open like state is tied to contact_open?? But I have a few events with code 28 having state closed, contact and reed set to 0 but alarm is still 1 (maybe because battery is low on that device).

Alarm may be tied to reed_open || tamper || battery - but does not appear to be tied to contact_open - but I have a few event 36 which has contact and state closed, reed open, tamper 0 and battery 1; but alarm is 0.

Alarm doesn't appear to be consistently tied to things like I would expect (I expected if contact, reed, tamper or battery has problems it would be in alarmstate).

Either way there is a contact and reed switch; shouldn't mqtt_hass also capture the contact? I am OK dropping state - but would appreciate seeing any documentation or details on it being depreciated (esp since it's still reported from rtl)

[dmz006]

One last question; since I'm not using the reed switch I didn't notice that mqtt_hass wasn't publishing reed_open state - shouldn't it publish all active details, like contact and reed?

Should I update the PR to remove event (which would be good to capture but not necessary), remove state but keep contact_open and add reed_open?

[zuckschwerdt]

Sorry, no idea. We see that "event" byte in the data transmission and we guess it decodes that way. I'm just saying you shouldn't use the raw "event" output. We have since added new information about decoding: the breakdown of event seen above.
"event" is undecoded, "state" is the old name for "contact_open", "battery_ok" is inverted. Click the source code I posted for more info.

Yes, remove "event" and "state" please.

[zuckschwerdt]

Looks good to me.

[dmz006]

Just curious; what is the normal process/workflow/timeline for PR?

[zuckschwerdt]

We usually allow a week or two for people to chime in.

[rct]

Sorry didn't see this earlier. But, FYI, users of a number of the 5800 series sensors will need to do some hand configuring for which bit(s) they care about for each sensor.

I thought more detail made it into the 5800 source but I guess not.

Background: Apparently when these devices get added to Honeywell panels, the installer selects which "loop" that zone is monitoring. Many sensors use Loop 1 which is the 0x80 "contact" bit. But some sensors use Loop 2 (0x20 reed).

It is possible on some of the 5800 series sensors to get 1-3 zones out of a single sensor. For some since the contact terminals are separate from the reed switch, that sensor can cover 2 zones.

Tamper 0x40 is considered Loop 4.

Some sensors send additional information on Loop 3 (0x10), like tilt or low temperature.

So from my notes:

- 0x80 - Contact Open  (loop 1)
- 0x40 - Tamper (loop 4)
- 0x20 - Reed Open  (loop 2)
- 0x10 - Alarm (Loop 3 - Tilt, low temperature, etc.)
- 0x08 - Battery Low  (0 OK, 1 low)
- 0x04 - Heartbeat  (0 Event, 1 heartbeat)
- 0x02 - ??  (not used or not seen)
- 0x01 - ??  (not used or not seen)
	- From @klohner's decoder (might be related to RE220 repeater?)
		- 0x02 - Power (0 OK, 1 initialized?)  (maybe power up/reboot?)
		- 0x01  - Source (0 local, 1 Repeater) 

[zuckschwerdt]

Great information! I always wondered why there are different contact/reed bits, as those contact would likely be "reed switch" type hardware too?

Do you want to PR this to the decoder comment text for posteriority?

[rct]

Yeah, I'll try to clean that up at some point. Was waiting/hoping for some progress on the problematic 5816's #2015 (and the related #2479)