[ARCHIVED] AlertMe Device Drivers with Presence

Please head over to the current thread about these drivers.

There are a few UK devices from AlertMe which aren't in the Iris V1 system drivers right now, so examining some code from the past and with @markus's invaluable help deciphering the data block, I present my first drivers!

There's every possibility that these will work with their Iris V1 equivalents as well, given that generation of Iris was built on the AlertMe platform.

They all have presence detection for troubleshooting and system control (using key fobs) plus a 'ranging mode' for checking link quality (LQI). While in ranging mode device LEDs will double-flash to show a good quality link, or triple flash if the LQI is poor. This measurement is transmitted back to the Hub and shown on the device page.

Drivers are in the new thread.

3 Likes

For instructions, just in case.

These drivers are now available through Hubitat Package Manager.

Just search for "AlertMe" in the keyword search.

Device temperature readings below zero now work correctly. Now that it’s chilly in the UK it turns out that zigbee.convertHexToInt() doesn’t convert negative hex values. It is definitely not over 4095 degrees in the garden.

Just a note to say that if you have an AlertMe SmartPlug with 2010-10-20 firmware, it's likely that after 6 months or so you may need to give it a little nudge to keep it reporting correctly.

It seems there's a memory leak in the internal firmware where the device remains controllable but no longer reports any data. You'll see that powering it on and off remotely is perfectly fine, but it doesn't transmit any responses back to the hub.

The fix is easy, just trigger a reboot of the plug by holding down the power button for 12 seconds. Later firmware appears to have fixed this bug.

I've just updated all of these drivers to properly handle IAS enrolment requests (security devices) and match descriptor (cluster 0006) requests, which occur when AlertMe devices feel they need to be 're-authenticated', usually following a battery replacement.

It was pretty sketchy as to when this was required; just removing the battery from a device and reinstalling it didn't often trigger the need to re-enrol, but a device where the battery had become exhausted naturally would often not do anything except for send repeated enrolment requests when a new battery was installed.

This made battery replacement time a nightmare as some devices just wouldn't reattach to the mesh, sometimes even needing to be deleted, reset and re-joined. This all appears to be fixed now.

1 Like