Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support

I’ve released an update to fix the add-on issue.

Unfortunately due to a breaking change in Home Assistant it will require you to update your config file (even those not using the add-on). However, I’ve taken the opportunity to simplify the config massively which should fix a lot of the pain points with the application.

I’ve also put in quite a bit of code to validate the config so you should get a nice warning/error telling you what’s wrong and how to fix it if your config is not quite right.

The full format is on the Docker page: https://hub.docker.com/r/dchesterton/texecom2mqtt but essentially where you had something like this before:

log: 0
texecom:
  ...
mqtt:
  ...

homeassistant:
  discovery: true
  prefix: "home-assistant"
  areas:
    house:
      name: "House Alarm"
      mapping:
        full_arm: armed_away
        part_arm_1: armed_night
        part_arm_2: armed_home
      options:
        code_arm_required: true
        code_disarm_required: true
        code: 123456
  zones:
    front_door:
      device_class: "motion"
      name: "Living Room Motion Sensor"

It will now be:

log: debug
texecom:
  ...
mqtt:
  ...

homeassistant:
  discovery: true
  prefix: "home-assistant"

zones:
- id: front_door
  name: "Front Room Motion Sensor"
  device_class: "motion"

areas:
- id: house
  full_arm: armed_away
  part_arm_1: armed_night
  part_arm_2: armed_home
  code_arm_required: true
  code_disarm_required: true
  code: 123456

Additionally, I’ve fixed the versioning issue on the add-on store so you should now see an Update button in Supervisor to easily update to the latest version.

Please let me know if the fix works for you. Sorry for the delay getting it sorted and also for having to change your config but it should improve the project going forward :+1:

Edit: You may have to reload your repositories for the new version (1.0.14) to show. Go to ‘Supervisor’ -> ‘Add-on Store’, click the icon in the top right and click Reload.

1 Like

Hi Rogan, really nice work on the reverse engineering! I’d be keen to poke around the code when you get a chance to publish it :slight_smile:

Switching protocol is not something I’m going to do. I appreciate it’s frustrating that I can’t publish the source code but I’m using the Connect protocol (it’s different to the simple/crestron protocols) which is the modern API that Texecom want applications to use where possible and it’s also well documented and works well. I’m happy to help in any way I can to support your work with non-Elite panels though.

It’d be quite difficult to extract out the non-NDA bits from the NDA bits in the code :confused: and if I’m honest, I’m really pushed for time at the moment too. Can you sign the NDA? I’ve shared access to the repo to others who have signed it and I’d be happy to do the same with you.

Hi @dchesterton. Thanks, I’ll be sure to share it once I have cleaned it up a bit, and got something more functional.

I understand completely that you don’t wish to change protocol - the Wintex protocol is rather obscure, and mixes internal implementation details with exposed external API. Among other things, a lot of the protocol seems to depend on knowing specific memory regions to query, and then how to parse the resulting output as bitfields, etc. Nonetheless, it does provide the ability to interface with older panels which do not support the Connect protocol at all.

Would you perhaps consider providing it as an alternate backend, alonside the Connect protocol, to enable support for those panels in texecom2mqtt? I honestly don’t care if my reverse engineering gets incorporated elsewhere, and would be happy to provide it in a format that makes it easy for you to use. e.g. a protocol-specific implementation of a general interface.

I haven’t done any node development, but syntactically it seems easy enough.

As far as signing the NDA, it’s not something I am keen to do. I don’t particularly want to have to ask permission from anyone to share my code. And it exposes me to legal action if I share something that I believe is not covered, but someone else does. So, no.

@MouseZA @Alpha01-OS @MortenVinding I also have a non-Elite panel (Premier 832, in my case), and have started work on reverse-engineering/reimplementing the Wintex protocol (as used by Wintex itself) to allow monitoring/control of older panels too.

It may even be possible to implement a Connect<->Wintex shim that would allow older Premier panels to appear as a Connect-capable panel! My Panel->network interface is homebrew, based on an ESP32 connected to both COM1 and COM2 on my 832, with both ports configured as USB-COM in the panel itself. Based on a quick look at the functions specified in the Connect protocol, it should be fairly straightforward to accept Connect-protocol function calls, and translate them to Wintex protocol to the panel. It could potentially even be done in the ESP32!

Thank you Daniel, that update has got me back up and running! All my sensors worked straight away (as before) without any manual tweaking of settings in the config.

On this update it cleared the config back to defaults, required in this case as it needed rejigging but would make me wary of future updates. Is there a way of adding a warning to back up config first?

Sorry about that, I can promise that there won’t be any big changes to the config going forward. As I was forced to make a change I wanted to make a bigger change now so there’s a good foundation going forward.

1 Like

Hi Daniel,

Just managed to capture this, the sensors have become unavailable and the application has stopped.

2021-02-11 14:51:19 - INFO: HALLWAY Motion Sensor status changed to Active
2021-02-11 14:51:19 - DEBUG: Publishing to texecom2mqtt/1184708/zone/hallway_motion_sensor: {"name":"HALLWAY Motion Sensor","number":1,"areas":[1],"status":1,"type":"Entry/Exit 1"}
2021-02-11 14:51:20 - DEBUG: Received data true
2021-02-11 14:51:20 - PANEL: Output state changed digi: 252
2021-02-11 14:51:20 - DEBUG: Updating system power...
2021-02-11 14:51:20 - DEBUG: Executing command 25
2021-02-11 14:51:20 - DEBUG: Received data true
/snapshot/app/dist/texecom/texecom.js:87
            throw new Error("CRC is invalid");
            ^
Error: CRC is invalid
    at Texecom.parseBuffer (/snapshot/app/dist/texecom/texecom.js:87:19)
    at Socket.<anonymous> (/snapshot/app/dist/texecom/texecom.js:242:26)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:271:9)
    at Socket.Readable.push (_stream_readable.js:212:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:186:23)

This is not something new and has happened previously only now i have been able to get the details of the log.

Any thoughts?

It’s an issue that happens occasionally but it’s hard to replicate. I think I have an idea of what’s causing it and I might have a fix but I need to dig into it a bit more.

You should set the application to restart automatically if it crashes. If you use the add-on, enable Watchdog, or if you’re using Docker, set the container restart policy to always, e.g.

docker run ... --restart always texecom2mqtt

It should then come back online nicely and pick up where it left off.

I’ve spent some time on it this evening and added a potential fix for this. As I say, it happens intermittently so difficult to know if the issue is sorted so please let me know if you do/don’t get it again.

… because we all check forum threads before updating (HA!), but I’d give 1.0.23 a miss for now causes the below problem for me. 1.0.22 is fine:

Oh bother, missed this - I am getting the same error.

Is there a way to reinstall the last version?

Take the port off the MQTT address - or move to the port option. So:

mqtt:
  host: 'mqtt://core-mosquitto:1883'

Becomes:

mqtt:
  host: 'mqtt://core-mosquitto'

That fixed it - thank you kindly.

Hi Daniel,

Thanks so much for fixing this integration. I’ve been using it for quite a long time now and I was lost when the HA update broke it.
Any chance to update your code so that it is able to show the state of an area when it’s ‘auto armed’? At the moment it just shows up as disarmed after its armed via the auto arm feature of the panel.
I think this state is missing from the Texecom documentation.
Thanks.

For anyone else having the same issue with auto arming, I’ve pushed an update and confirmed with @fredkruger that it’s fixed the bug.

2 Likes

Do we know if there’s an opt out for add-ons for the new HaveIBeenPwned check? It’s warning me repeatedly about my UDL password but I would guess all 6-digit numeric passwords are in the HIBP database

I changed my UDL to an 8 digit one that I pre-checked against the HIBP website. This seems to have solved it. Since can be different to the engineer code, it just means I had to change in Wintex and the integration.

1 Like

I am seeing the following in my supervisor log

21-03-04 09:51:30 WARNING (MainThread) [supervisor.addons.options] Unknown option 'device_class' for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-04 09:51:30 WARNING (MainThread) [supervisor.addons.options] Unknown option 'full_arm' for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-04 09:51:30 WARNING (MainThread) [supervisor.addons.options] Unknown option 'part_arm_1' for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-04 09:51:30 WARNING (MainThread) [supervisor.addons.options] Unknown option 'part_arm_2' for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-04 09:51:30 WARNING (MainThread) [supervisor.addons.options] Unknown option 'code_arm_required' for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-04 09:51:30 WARNING (MainThread) [supervisor.addons.options] Unknown option 'code_disarm_required' for texecom2mqtt (c15a2434_texecom2mqtt)
21-03-04 09:51:30 WARNING (MainThread) [supervisor.addons.options] Unknown option 'code' for texecom2mqtt (c15a2434_texecom2mqtt)

and this is my config

texecom:
  host: 192.168.0.211
mqtt:
  host: 'mqtt://core-mosquitto'
  port: 1883
  username: xxxx
  password: xxxxxxxxx
  client_id: texecom2mqtt
  retain_log: true
homeassistant:
  discovery: true
  prefix: home-assistant
areas:
  - id: hallway_motion_sensor
    name: Hallway Motion Sensor
    device_class: motion
zones:
  - id: area_a
    full_arm: armed_away
    part_arm_1: armed_night
    part_arm_2: armed_home
    code_arm_required: false
    code_disarm_required: true
    code: 2501
log: debug

I am also still getting one or two crashes / restarts a day running latest update,

Any thoughts?

Aren’t those options part of an area rather than a zone and vice versa?

Mine looks like this

texecom:
  host: 192.168.1.209
  udl_password: 'xxxxxx'
mqtt:
  host: 'mqtt://xxxxxxx'
  username: xxxxxx
  password: xxxxxx
  client_id: texecom2mqtt
  keepalive: 30
homeassistant:
  discovery: true
areas:
  - id: house
    full_arm: armed_away
    part_arm_1: armed_home
zones:
  - id: inner_doors
    device_class: door
  - id: external_bell
    device_class: sound
log: info
1 Like

Yeah as Roger says, you’ve got your zones and areas the wrong way around :slight_smile:

Can you send me logs around the crashes and I might be able to investigate further?