dchesterton/texecom2mqtt-hassio

Regular crashes over last couple of weeks ? Connection Refused

Opened this issue · 13 comments

B-Hartley commented

Describe the bug
Add On crashes, watch dog doesn't restart it,
Add on has worked solidly for a long time, but in last couple of weeks or so have been getting frequent crashes.
Can't be 100% sure what version of home assistant or supervisor started the problems.

Application version
v1.2.3

Texecom alarm type
Premier Elite 24 (V5.02.01LS1)

Home Assistant version
Home Assistant 2023.3.5
Supervisor 2023.03.1
Operating System 9.5
Frontend 20230309.1 - latest

Debug log

2023-03-17 01:00:31 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)...
node:events:368
      throw er; // Unhandled 'error' event
      ^
Error: connect ECONNREFUSED 192.168.21.133: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.21.133',
  port: 10001
}
Smart-Techno1ogy commented

Hi, did you get a resolve to this? I have a very similar issue.

HAS is fully up to date. The add-on runs for a while and the stops and fails to restart. The error message consistently being as follows:

“ERROR: Unhandled rejection - Command 25 timed out 5 times and could not be completed“

also, what drives the time stamp in the log? I note this is an hour out despite the time being correct on both the panel and home assistant. Is there a clock in addition?

Any help would be appreciated thank you

LindsayReid commented

After around two years wiuth no problems, my texecom2mqtt seems to stop every day and fails to restart automatically. Apart from standard Home Assistant updates:
Home Assistant 2023.4.6
Supervisor 2023.04.1
Operating System 10.0
Frontend 20230411.1 - latest

I have stopped using Zigbee devices as I can use existing Texecom "Ricochet" PIRS and Door/Window detectors.

Any ideas/updates.

Pathaleon commented

We've been having similar issues too, seems to crash when there is an exit error on the alarm.

Shame the project appears to be abandoned as it works better than other integrations.

If it was open source we could have a go at fixing it.

Hopefully the dev is still around :)

supss commented

Also having this problem, worked a treat for over 2 years. Then it started with the odd crash, now it's like 4-5 times a day.
I disabled watchdog to see if I can grab exactly what's causing the problem...here is the log output

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

I think this would be the same as other. It's becoming pretty frustrating.. 😬

greghesp commented

I run this separately outside of hassio, and mine is also crashing. Probably a couple of times a month, so im not sure its specific to Home Assistant

Pathaleon commented

Ours seems to have a guaranteed crash on an arm fail. Other scenarios I haven’t been able to confirm the crash reason.

quentinsf commented

I have a very similar issue: when I have a power outage, connection to the Smartcom is lost (through things like network switches being offline). I get a 'Host unreachable' error rather than 'Connection refused' error, but from the same line of code. The watchdog doesn't seem to restart it. Or maybe it tries but gives up too quickly.

So I've implemented my own simple watchdog: every 15 mins, it looks to see whether my alarm is 'unavailable', and if so, it tries starting the add-on. On my initial tests, this seems to work nicely!

- alias: Texecom2mqtt watchdog
  id: "texecom2mqtt_watchdog"
  initial_state: on
  mode: restart
  trigger:
    - platform: time_pattern
      minutes: "/15"
      seconds: 00

  condition:
    - condition: state
      entity_id: alarm_control_panel.house_alarm
      state: "unavailable"

  action:
    - service: hassio.addon_start 
      data: 
        addon: c15a2434_texecom2mqtt

If you're not doing this through the GUI, the add-on name at the bottom can be deduced by looking at the URL when you're viewing the add-ons page.
This was inspired partly by this post where people had problems with Zigbee2MQTT crashing.

LindsayReid commented
hunterdrayman commented

Thanks - might be just what I need.

hunterdrayman commented

In case anyone needs the Node-RED equivalent

image

[{"id":"23254f671972abaa","type":"debug","z":"7e84ab06f46c8a03","name":"texecom2mqtt stopped","active":true,"tosidebar":false,"console":true,"tostatus":false,"complete":"\"The texecom addon became unavailable. Attempting restart.\"","targetType":"jsonata","statusVal":"","statusType":"auto","x":490,"y":440,"wires":[]},{"id":"39ec83dce9f97913","type":"api-call-service","z":"7e84ab06f46c8a03","name":"Start it","server":"82070ffe.b97dd","version":5,"debugenabled":false,"domain":"hassio","service":"addon_start","areaId":[],"deviceId":[],"entityId":[],"data":"{ \"addon\": \"c15a2434_texecom2mqtt\" }","dataType":"json","mergeContext":"","mustacheAltTags":false,"outputProperties":[],"queue":"none","x":430,"y":500,"wires":[[]]},{"id":"6097cfd23c08ee70","type":"poll-state","z":"7e84ab06f46c8a03","name":"Texecom2MQTT unavailable","server":"82070ffe.b97dd","version":3,"exposeAsEntityConfig":"","updateInterval":"15","updateIntervalType":"num","updateIntervalUnits":"minutes","outputInitially":false,"outputOnChanged":true,"entityId":"alarm_control_panel.texecom_alarm","stateType":"str","ifState":"unavailable","ifStateType":"str","ifStateOperator":"is","outputs":2,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"x":160,"y":440,"wires":[["23254f671972abaa","39ec83dce9f97913"],[]]},{"id":"82070ffe.b97dd","type":"server","name":"Home Assistant","version":5,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true,"heartbeat":false,"heartbeatInterval":30,"areaSelector":"friendlyName","deviceSelector":"friendlyName","entitySelector":"friendlyName","statusSeparator":"at: ","statusYear":"hidden","statusMonth":"short","statusDay":"numeric","statusHourCycle":"h23","statusTimeFormat":"h:m","enableGlobalContextStore":true}]

  • 👍1
edc1 commented

I was getting this error regularly too with an Elite 48. My SmartCom had version 3 firmware and the panel was running 5.01.03 LS6 firmware. I upgraded the SmartCom to version 4.05.01 then the panel to version 6.05.03 LS6 (using Texecom Cloud). I've not seen this error again since I upgraded over a week ago. Arming and disarming the alarm through Home Assistant seems more reliable now as well.

shababyousaf commented

Ive updated all firmware on both smartcom and Panel elite 24 still get disconnected below is my latest error log

2024-02-15 05:02:22 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)...
node:events:368
throw er; // Unhandled 'error' event
^

Error: connect EHOSTUNREACH 192.168.1.18: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: -113,
code: 'EHOSTUNREACH',
syscall: 'connect',
address: '192.168.1.18',
port: 10001
}

Is this the case of just host unreachable
Don't know why it would be unreachable as haven't dropped connection to it
Btw added a spare comip separate just for this texecom2mqtt addon

ptruman commented

I've improved performance by putting the container on the "host" network.
I use a ComWiFi, and I need to reset the COM port BEFORE docker starts else it gets confused/upset.