That’s what I figured. The reason I was seeing motion or anything at all is because I manually changed it to your DTH. Unfortunately, most features don’t work. In fact, the temperature was working, but today it isn’t. So, looks like I’m back to square one. @zcorneli I may try using your DTH and making one for this keypad. Any hints on where I could get some documentation on this device? Also, while watching the log output, it only sends any notifications when there is motion. Key presses and pressing any of the “home”, “away” or “night” buttons sends no codes to the DTH.
Sadly, companies like this (Centrallite, UEI, TCH) only provide their documentation to dealers / direct customers, and not to end users, so you’ll have to do some reverse engineering, and see what works, and what doesnt.
Probably the best place to start, assuming UEI at least somewhat followed the standards, would be the Zigbee IAS ACE (Intruder Alarm System Ancillary Control Equipment) zone type.
Temperature, and battery are both reported via Zigbee standards for those, so I would expect those to ‘just work’ with most Zigbee DTH’s.
As far as seeing incoming data for the key presses, etc, if it follows the Zigbee IAS standards, you’ll need to force it to join as an IAS zone. For the Centrallite keypads, that’s done by pressing the tamper switch once its paired, and I’d think the UEI would do something similar.
If everything’s working then, and it does follow (roughly) the IAS ACE standard, you should see at least something when you put in a code + home/away/night button. You might want to add a debug logging statement for the message received method, to just dump the contents of the received message.