Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support

[daern]

@sups Yes, much the same here:

2023-06-25 17:07:33 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)...
node:events:368
      throw er; // Unhandled 'error' event
      ^
Error: connect ECONNREFUSED 192.168.1.101:10001
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '192.168.1.101',
  port: 10001
}

It’s a little hard to narrow down, as I recently switched from a Pi4 to x86, but I’ve had a few occasions over the last 2-3 weeks where this add-on has crashed and then failed to restart with the watchdog, with the last reported log above. Unfortunately, I suspect that the add-on is handling the error on restart a little bit too well and, as a result, exiting cleanly resulting in the watchdog not kicking in to restart it again.

I’ve got the watchdog disabled for now so I can see what the initial error is that triggers the crash in the first place, as well as some monitoring so I can tell if things stop updating and get alerted to look at it.

For avoidance of doubt, I’ve not changed anything on the alarm or networking config, with the exception of moving HA from RPi4 to x86 (still HAOS).

[daern]

As I mentioned above, after a long period of stability, suddenly I’m seeing regular failures of this add-on, with periodic lack of recovery by the watchdog. I’ve captured the following debug of the crash:

2023-06-26 21:29:24 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":0,"type":"Guard"}
2023-06-26 21:29:24 - INFO: Kitchen status changed to Active
2023-06-26 21:29:24 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":1,"type":"Guard"}
2023-06-26 21:29:26 - INFO: Kitchen status changed to Secure
2023-06-26 21:29:26 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":0,"type":"Guard"}
2023-06-26 21:29:28 - INFO: Kitchen status changed to Active
2023-06-26 21:29:28 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":1,"type":"Guard"}
2023-06-26 21:29:31 - INFO: Kitchen status changed to Secure
2023-06-26 21:29:31 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":0,"type":"Guard"}
2023-06-26 21:29:33 - INFO: Kitchen status changed to Active
2023-06-26 21:29:33 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":1,"type":"Guard"}
2023-06-26 21:29:36 - INFO: Kitchen status changed to Secure
2023-06-26 21:29:36 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":0,"type":"Guard"}
2023-06-26 21:29:40 - DEBUG: Updating system power...
2023-06-26 21:29:40 - DEBUG: Publishing to texecom2mqtt/status: online
2023-06-26 21:29:40 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":9,"battery_voltage":13.49,"panel_current":603,"panel_voltage":13.56}
2023-06-26 21:29:59 - INFO: Kitchen status changed to Active
2023-06-26 21:29:59 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":1,"type":"Guard"}
2023-06-26 21:30:01 - INFO: Kitchen status changed to Secure
2023-06-26 21:30:01 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":0,"type":"Guard"}
2023-06-26 21:30:04 - INFO: Kitchen status changed to Active
2023-06-26 21:30:04 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":1,"type":"Guard"}
2023-06-26 21:30:07 - INFO: Kitchen status changed to Secure
2023-06-26 21:30:07 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":0,"type":"Guard"}
2023-06-26 21:30:09 - INFO: Kitchen status changed to Active
2023-06-26 21:30:09 - DEBUG: Publishing to texecom2mqtt/zone/kitchen: {"name":"Kitchen","number":7,"areas":["A"],"status":1,"type":"Guard"}
2023-06-26 21:30:10 - DEBUG: Updating system power...
2023-06-26 21:30:10 - ERROR: Corrupt response from panel: CRC 49 is invalid (message: 744d088019f10031)
2023-06-26 21:30:10 - DEBUG: Closing connection to panel
2023-06-26 21:30:10 - DEBUG: Closed connection to panel
2023-06-26 21:30:10 - DEBUG: Panel socket closed
2023-06-26 21:30:10 - INFO: Panel disconnected, exiting now
2023-06-26 21:30:10 - DEBUG: Publishing to texecom2mqtt/status: offline
2023-06-26 21:30:10 - DEBUG: Closing connection to MQTT broker
2023-06-26 21:30:10 - DEBUG: Closed connection to MQTT broker

These are a bit of a return to problems of old, but to my knowledge nothing has changed about my texecom infrastructure, with the panel, firmware and configuration all being unchanged for many months now. As I mentioned above, I have moved HA to new hardware, but the configuration running it is unchanged. I’m running version 1.2.3 of the addon as confirmed here, after a restart:

2023-06-26 21:36:32 - DEBUG: Publishing to texecom2mqtt/config: {"version":"1.2.3","log_level":"debug","model":"Premier Elite 48","firmware_version":"V5.04.01LS1","serial_number":"xxxxx"}

I (and others) had a stack of problems with this back two years ago and @dchesterton was kind enough to introduce some changes to improve stability, but it looks like something has made something of a return here. Perhaps something specific to the system power message which varies according to system status? Any thoughts?

@dchesterton I’m happy to have a look at debugging this on my system, if you would be willing to give me access to the private repo.

[marshn]

This is almost certainly a CRC failure which occurred at 21:30:10 when the outgoing command to update the system panel coincided with an incoming mesage containing a ‘zone 7 is secure’ message.

This CRC failures are a known problem with the Texecom panels. See this post, which explains the problem: Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support - #462

I am using v6.02.00 firmware on several Premier Elite 168 panels and see this CRC problem on all of them.The nature of this problem is that the ‘busier’ a system becomes, and the more zone/area/output messages the panel sends, the more likely a CRC fail (and a lost message) is likely to become. On a quiet panel I may not see a CRC failure for months. On a really busy panel they can occur several times a day. In every case that I have captured the CRC failures occur when incoming messages and outgoing commands ‘collide’.

This may be what you are seeing?

Unless Texecom fix the issue, which is unlikely to happen, the only mitigation would be make the way Texecom2mqtt handles a CRC error more gracefull. I don’t use texecom2mqtt (but do develop firmware to interface to Texecom panels) so cannot help directly.

[daern]

Thanks @marshn - I’m quite sure you’re right.

I’m fortunate that my panel is neither overly full (I have around 20 zones used), nor exceptionally busy (it’s a residential install) so this hasn’t been a common occurrence for me, until recently - and, indeed, it’s been stable since the last failure a couple of days ago. I doubt we’ll see Texecom fix this, so I’d settle for an option to configure a slightly more graceful failure mode that doesn’t take out the whole add-on which doesn’t always start up again cleanly, presumably as the panel is still busy at the point of reconnection!

I’ve not brought my panel to a newer version than 5.04.01, on the “if it ain’t broke, don’t fix it” premise, and I’m still reticent to do so now, especially as you’re reporting it still happening even on 6.02.00 as well. Have you noticed any change in CRC failures between 5.x and 6.x?

[marshn]

Unfortunately I didn’t notice any change in CRC failures between 5.x and 6.x. Each time I updated I checked the before and after CRC failure rates on a test panel set up as a ‘worst case’ system. If there had been an improvement I would have seen it.

It is a pity that the CRC failures havn’t been fixed by Texecom as it makes their interface unusable for any critical application.

[shoei600]

Any Virtualbox guidance/help for my post above please?

Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support

I have this awesome solution running on a Pi setup without any issues. I’m trying to setup a HA system on a Windows machine. Could somebody please point me to step by step instructions for getting texecom2mqtt running? I’m using Virtualbox. I have seen a post hat talked about adding some lines to create the docket image but where do they go to get executed. https://community.home-assistant.io/t/texecom-alarm-integration/203169/17 Thanks.

[sups]

Alias …

2023-07-28 11:35:36 - ERROR: Corrupt response from panel: CRC 91 is invalid (message: 744d087e193d005b)
2023-07-28 11:35:36 - INFO: Panel disconnected, exiting now

This is happening way more regularly than ever before (3-4 times a day now)

Has anyone found a work around? how are people managing the CRC disconnection.

[marshn]

There are a few posts about CRC failures in this thread, for example #462 and #861 have some details.

[sups]

Thanks @marshn, I’ve already seen these posts. I was just wondering what others are doing, have people come up with some clever automation or (like me) are they simply just reseting the add-on everytime it crashes.

[daern]

It’s not pretty, it’s not elegant, but…

- id: detect_alarm_failure
  alias: "Detect alarm failure and recover"
  trigger:
    - platform: state
      entity_id: alarm_control_panel.house_alarm
      to: "unavailable"
      for: "00:01:00"
  action:
    - service: hassio.addon_stop
      data: 
        addon: "c15a2434_texecom2mqtt"
    - delay: "00:00:15"
    - service: hassio.addon_start
      data: 
        addon: "c15a2434_texecom2mqtt"
    - service: notify.pushover
      data_template:
        title: >
          Restarted Texecom add-on
        message: >
          Restarted Texecom add-on.

          This happened at: {{ now() }}
        data:
          sound: classical   

[sups]

Sweet… thank you!

[technophobe (Arnie)]

I read in one of the comments that the original app notifications no longer work with this integration. Can someone confirm if that is the case. (my notifications have stopped since using this integration but i’m really hoping i have just made a mistake in a config and can tweak it to fix)

My current HA setup is local only. So, I’m really hoping there is a work around because if thats the case I won’t be able to receive any arm/disarm notifications. Worse still I won’t be notified if my alarm is set off.

I can work around getting notifications when i’m at home but its when i leave home that will be a problem! I have added push notifications locally and have managed to integrate some automations around door opening events etc. But no notifications will mean i can’t use any of this

[MJWMJW (Matthew)]

I can confirm this behaviour, native app notificatrions no longer work once this integration is running.

[daern]

This is correct. There’s a few posts above explaining it, but in short, one ComIP can support one application and if you try to run two (e.g. Texecom Cloud and HA), they will interfere and neither will work well. Most people here doing this, will have multiple ComIP / Smart on devices to work around this.

[ptruman (Peter)]

Has anyone else’s HASS / Texecom integration just lost all sensors as entities?
I now only have “the alarm” which I can arm/disarm but all sensors (PIRs etc) are no longer showing in HASS.

I can see the updates publishing in MQTT, but HASS isn’t recognising them?

[PABHudds (Paul Baxter)]

Hi, just wanted to thank you for this integration. I recently upgraded my alarm system to Texecom Premier Elite 24 with a SmartCom and it all works fine, I got the integration up and running pretty quickly. I was also able to connect to the panel with WinTex (using SmartCom) and HA at the same time, and could see movement triggers appearing in both, I also have Texecom cloud. I have read that this is likely to cause me issues with conflicts, but I’ll see how it goes, but I’m aware that I may need to add a ComIp for HA to use exclusively, I don’t mind stopping the addon if I want to use WinTex as this probably won’t be a frequent occurrence.

The system was installed when I moved in and only has PIRs. I have wireless door contacts connected to HA using Zigbee and I’d like to expose these to the alarm system. I think, from what I’ve read, that there is no way to add ‘virtual’ zones that can be triggered by HA, but I just wanted to confirm that. I plan to use ESP32Home to configure an ESP32 or 8266 to output the door sensor states and feed these into the zone inputs on an 8XP zone extender.

Thanks again.

[daern]

@PABHudds

The system was installed when I moved in and only has PIRs. I have wireless door contacts connected to HA using Zigbee and I’d like to expose these to the alarm system. I think, from what I’ve read, that there is no way to add ‘virtual’ zones that can be triggered by HA, but I just wanted to confirm that. I plan to use ESP32Home to configure an ESP32 or 8266 to output the door sensor states and feed these into the zone inputs on an 8XP zone extender.

You’re quite right - the integration doesn’t allow for this sort of virtual contact, but the ESPhome solution sounds a really good idea - not sure why I hadn’t thought to do that myself, TBH! Let us know how you get on with it and how well it works for you.

[PABHudds (Paul Baxter)]

Hi. It’s all up and running and working well. I picked up 2nd hand zone extender on eBay and was able to run the ESP from the Aux power out on the Zone extender using a buck converter, so it will be powered by the panel battery in a power cut and so shouldn’t trigger an alarm. The only other part I needed was a little board with a Darlington transistor IC so that I could pull down the +5v exposed on the XP zones without frying the ESP (which works a 3.3V) I configured the zones as normally open and I have a single automation in HA that triggers on any change on the 8 door sensors and then sets the ‘mimic’ output on the ESP to open or closed based on the state of the door contact. I specifically check for open or closed so if the sensor goes unavailable it doesn’t change the output state.

[chrisjcbt (Chris)]

Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support

So does it work? Your config should look something like this: homeassistant: discovery: true areas: house: mapping: full_arm: armed_away part_arm_1: armed_night Be sure to replace house in the above config with whatever you’ve called the area (lowercased with the spaces changed to underscores), or you can use the area number. To answer your previous question which I missed, you should set retain: true unless you have a specific reason not to.

I think this is the problem I have. When you say I should change “house” to whatever I have called my area, is that the entity ID of the partition/area I want to arm on the panel? Like mine is called “alarm_control_panel.area_a” in Home Assistant.

[IanRH (Ian)]

Food for thought Re the ESP - on a similar theme when I used HUbitat I ran an arduino for a long time, picking up wires that ran from the Tex panel outputs which were set up to echo whatever state I wanted (sensors on/off, armed, triggered etc). Worked really well for about 2 years.

When I changed to HA I swapped to a modbus interface, but it does the same thing - just listens to the outputs and switches a helper on/off.

Of course this is ‘output’ only. Next stage is to hack one of those little Tex remote fobs to connect its buttons to the modbus interface outputs - this will give me control over panic, arm, disarm and part arm functions.