You absolute legend, looks like I am getting somewhere now
Is there any (built in) way to get a sensor to show when an area is clear? ie. All sensors within that area are “secure”?
This indicator is available on the diagnostics on Wintex.
Within HA I guess I could create a group of all sensors within areas, but that becomes something else to maintain.
can somone please help with this what do i need to change to get it working?
Hey. I’ve recently noticed the app crashing fairly regularly… over the past few days I’ve simply just restarted it but today I’ve had a look a the logs, and here is what it says:
‘2023-06-16 16:14:56 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)…
node:events:368
throw er; // Unhandled ‘error’ event
^
Error: connect ECONNREFUSED 192.168.0.6: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.0.6’,
port: 10001
}’
Any idea what could be causing this?
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 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).
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.
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.
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?
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.
Any Virtualbox guidance/help for my post above please?
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.
There are a few posts about CRC failures in this thread, for example #462 and #861 have some details.
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.
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
Sweet… thank you!
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 
I can confirm this behaviour, native app notificatrions no longer work once this integration is running.
1 Like
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.
1 Like