Send Key press Command #12 about homebridge-texecom

[kieranmjones]

I was confused there for a second because I haven't released a version of this module with the ability to arm/disarm etc through sending key presses, then I realised this is just a general query about the API spec. How are you sending the commands? Sending number keys etc is simply enough, just put into serial or TCP if you're doing it that way something like KEY3

However, what you'll find with this API is that some functions won't work, for example to enable something like quick arming on a regular Texecom keypad to enable that feature on that keypad address, with the API you aren't able to specify that the API has those permissions and so that feature can't be enabled if that makes sense? At least that is my understanding, it could be something like chime simply can't work via the API because you can't adjust what the API has permission to do because that virtual command keypad doesn't have an address or anything.

[coleged]

Yeah, sorry, I haven't looked at your code, nor Homebridge. Mine is a native C++ tool. I've yet to receive a response to this question from Texecom, so was looking for others who have integrated with them.

I'm opening socket with the comIP interface, then following protocol specified in the two docs Texecom Connect [Payload] Specification supplied under NDA. i.e. login using UDL code, then issue various commands and parse responses. I am able to query everything I have tried so far, get/set LCD, query all the zones, status flags etc, [un]omit zones, arm and disarm the system etc.

I understand the limitations of the implementation over TCP, and can't monitor events, but for my purposes it's pretty good.

What I would like to do is turn chime on/off - and the spec implies I should do this sending a message to simulate key press on panel in similar way to others with properly formatted payload etc.

When I do this I get a response message back with matching sequence number and good CRC containing an ACK which implies that the command has been actioned, but it isn't.

If you don't have the Texecom paper to hand then I feel this might only confuse further.

[kieranmjones]

Sorry for slow reply, my theory on your issue is that it somehow relates to keypad permissions as certain functions must be expressly enabled on a keypad which you can’t do for the virtual keypad the protocol is pretending to be. Sadly the APIs for the alarm are far from well defined or thought out and so there are many many caveats and limitations. As this doesn’t relate to this project I’ve closed the issue, by all means message me on social media to discuss further.