Zigbee ZoneStatus

🚧 Developers
1

Was messing around porting a Visonic door/window contact sensor DTH from ST to see if temperature would report in 0.5C increments like it is supposed to, instead of 1C increments like the in-box driver does...

Keep getting an error from the ZoneStatus part. Not being a zigbee guru, I'm unsure what I did wrong exactly. As there is no documentation for the ZoneStatus handler in Hubitat, I'm kind of just guessing here.

Any comments are welcome.

Error:

dev:15352020-05-19 06:43:42.091 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_tomasaxerot_Visonic_Door_Window_Sensor_1257.parseZoneStatus() is applicable for argument types: (java.lang.String) values: [zone status 0x0024 -- extended status 0x00] on line 134 (parse)
dev:15352020-05-19 06:43:42.051 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_tomasaxerot_Visonic_Door_Window_Sensor_1257.parseZoneStatus() is applicable for argument types: (java.lang.String) values: [zone status 0x0024 -- extended status 0x00] on line 134 (parse)
dev:15352020-05-19 06:43:42.035 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_tomasaxerot_Visonic_Door_Window_Sensor_1257.parseZoneStatus() is applicable for argument types: (java.lang.String) values: [zone status 0x0024 -- extended status 0x00] on line 134 (parse)
dev:15352020-05-19 06:43:41.965 pm debugdescription: zone status 0x0024 -- extended status 0x00
dev:15352020-05-19 06:43:41.888 pm debugParse returned [:]
dev:15352020-05-19 06:43:41.884 pm debugdescription: catchall: 0104 0500 01 01 0040 00 5A6D 00 00 0000 04 01 701000
dev:15352020-05-19 06:43:41.850 pm debugParse returned [:]
dev:15352020-05-19 06:43:41.847 pm debugdescription: catchall: 0104 0500 01 01 0040 00 5A6D 00 00 0000 0B 01 0000
dev:15352020-05-19 06:43:41.843 pm debugdescription: zone status 0x0024 -- extended status 0x00
dev:15352020-05-19 06:43:41.826 pm debugParse returned [:]
dev:15352020-05-19 06:43:41.813 pm debugParse returned [:]
dev:15352020-05-19 06:43:41.774 pm debugdescription: catchall: 0104 0500 01 01 0040 00 5A6D 00 00 0000 04 01 701000
dev:15352020-05-19 06:43:41.771 pm debugdescription: zone status 0x0024 -- extended status 0x00
dev:15352020-05-19 06:43:41.755 pm debugdescription: catchall: 0000 8021 00 00 0040 00 5A6D 00 00 0000 00 00 4C00

Applicable handler:

private Map parseIasMessage(String description) {
	ZoneStatus zs = parseZoneStatus(description)

	return zs.isAlarm1Set() ? getContactResult('open') : getContactResult('closed')
}
2

Use something like this in parse...

if (description.startsWith("zone status")) {
    def zs = zigbee.parseZoneStatus(description)
    sendContactEvent(zs.alarm1Set ? "open" : "closed")

You may just be missing zigbee in the class path...

3

Thanks.

It does start with "zone status", my guess is that it is the "extended status" that is also in the description that is killing it. Probably just need to strip that off.

The string value in the description is:
"zone status 0x0024 -- extended status 0x00"

4

Yeah, that's fine, that's normal

5

OK, thanks for the tips. I'll go poke around some more then. Something stupid I'm doing, I'm sure.

6

Yup. That was it. I'm an idiot. If I would READ the error instead of assuming it says what I want the issue to be, I would finish faster.

3 Likes
7

Story of my life! Lol

2 Likes
9

@mike.maxwell

Question - looks like I need to byte swap the temp value before converting. Any thoughts on why that is? I would have thought the built in parsing function would have done that already (as it does on other devices I've messed with)? Why not on this one?

10

If you're using parseDescriptionAsMap, it swaps the attribute bytes.
if you're having to swap them again after that, then that's a bug in the device firmware.

11

I'll learn someday...

The ST DTH used custom parsers, so wasn't using the map parser. So, of course, I have to swap it myself.

I think I'll just rewrite the stupid thing at this point with built-in parsers. I don't see anything custom about the response that would necessitate a custom parser anyway.

12

There isn't anything special if I recall about this device, btw none of Zigbee reporting configurations controll the scale of a devices return values...

13

Agreed. The temperature reporting is what it is. Why the device reports in 1C increments is beyond me. Luckily I bought it for the contact sensor (which works perfectly), not the temperature anyway.

14

Cheap ass temperature sensor and or implementation...

1 Like
15

You used Zigbee. Come on, man. We're Z-Wave Heople!

1 Like
16

Lol. Maybe in zwave 700 someone will make zwave leak sensors, contact sensors, and temp/humidity sensors that aren't $50/ea... Those are my main zigbee devices.

3 Likes
17

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.