Open B-Hartley opened 1 year ago
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
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.
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 :)
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.. 😬
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
Ours seems to have a guaranteed crash on an arm fail. Other scenarios I haven’t been able to confirm the crash reason.
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.
Ooooh! That looks very useful. I will have a go myself as the app does not always seem to restart on its own as I find it "stalled" from time to time.
On Thu, 12 Oct 2023 at 12:41, Quentin Stafford-Fraser < @.***> wrote:
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 https://community.home-assistant.io/t/tenacious-watchdog-for-add-ons-example-for-zigbee2mqtt/521888 where people had problems with Zigbee2MQTT crashing.
— Reply to this email directly, view it on GitHub https://github.com/dchesterton/texecom2mqtt-hassio/issues/82#issuecomment-1759445262, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFWRDQEPSGNTHKLHVKKRNDX67JN5ANCNFSM6AAAAAAV6INXFQ . You are receiving this because you commented.Message ID: @.***>
Thanks - might be just what I need.
In case anyone needs the Node-RED equivalent
[{"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}]
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.
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
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.
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