Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Regular crashes over last couple of weeks ? Connection Refused #82

Open
B-Hartley opened this issue Mar 17, 2023 · 13 comments
Open

Regular crashes over last couple of weeks ? Connection Refused #82

B-Hartley opened this issue Mar 17, 2023 · 13 comments
Assignees

Comments

@B-Hartley
Copy link

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
Copy link

Smart-Techno1ogy commented Apr 8, 2023

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
Copy link

LindsayReid commented Apr 27, 2023

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
Copy link

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
Copy link

supss commented Jul 28, 2023

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
Copy link

greghesp commented Sep 9, 2023

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
Copy link

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

@quentinsf
Copy link

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
Copy link

LindsayReid commented Oct 13, 2023 via email

@hunterdrayman
Copy link

Thanks - might be just what I need.

@hunterdrayman
Copy link

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}]

@edc1
Copy link

edc1 commented Dec 29, 2023

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
Copy link

shababyousaf commented Feb 15, 2024

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
Copy link

ptruman commented Mar 27, 2024

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests