Restart needed on cloud disconnect

[pergolafabio]

Describe the bug Hi @vanackej , using the addon with cloud proxy method... Yesteday i had a small internet interrupt, but after internet was restored, the addon was not able to connect to cloud anymore, i had to restart the addon to make it functional... It possible on this type of event as in screenshot, that the service can be restarted? I had watchdog enabled, but that doesnt help, since addon keeps on running

Thnx in advance

Configuration

• Environment: Addon
• Version: 0.5.0. beta 2
• Mode: Proxy
• Risco Panel model: Lightsys2
• Risco Panel firmware version: 2.x

Logs

I only have a screenshot:

[markxroberts]

To look at the partition issue, I need full debug logs please.

[pergolafabio]

Ok, is there sensitive data in it? I will enable it and upload later

[pergolafabio]

Hi, here is full debug When i started addon, the panel was in "disarmed" state, i tried sending 2 times the commands armed home OR armed away

riscodebug.log

[markxroberts]

Thanks for these. No messages are being received in the application from MQTT. I think this is because the partition topics are different to those expected (even though you have deleted the device). A restart of MQTT and probably HA is likely to be needed. Out of interest, do the bypass commands work as I haven't changed the topic structure for these? That would tell us whether or not the MQTT aspect is working at all.

[pergolafabio]

i restarted HA, restarted MQTT broker, deleted all devices, also from other addon, within mqtt explorer, deleted the panels (historical data), so all clear...

2 issues, you can clearsy see, i have 5 sensors:

8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Bureau, HA name = Bureau
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Bureau, HA name = Bureau Alarm
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Living, HA name = Living
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Living, HA name = Living Alarm
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Inkom, HA name = Inkom
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Inkom, HA name = Inkom Alarm
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Boven, HA name = Boven
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Boven, HA name = Boven Alarm
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Keuken, HA name = Keuken
8/7/2023, 8:14:55 PM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Keuken, HA name = Keuken 

But only 3 created:

Sending bypass commands dont work either...

I had a look, and as you can see, i sended/tested again, the disarmed command , but the topic is wrong, its directly under /risco-alarm-panel... while it should be /homeassistant/alarm-control-panel

[markxroberts]

Thanks for this. Can you reproduce the full HA discovery message for the partition and one of the zones, please. There are nearly always differing topics for autodiscovery and state. This is not an error. The reason that there are fewer bypass switches is that you can't bypass entry/exit zones, so these aren't published. It appears that the application isn't receiving the messages even though the listeners are properly installed. It's hard for me to debug as it's working in my system so thanks for providing the extra info.

[pergolafabio]

Hi, what do you mean by below , not 100% sure what info you want?

Thanks for this. Can you reproduce the full HA discovery message for the partition and one of the zones, please.

About bypassing zones, wth other addon i see them all 5 , i can also bypass entry/exit zones, also with th iRisco app itself

[markxroberts]

The messages aren't getting back to risco-mqtt-local. I wondered initially whether the discovery message might be faulty. It is sometimes because the client disconnects. Delays sometimes cause this. I've introduced a couple of delays related to message publishing, but as the online message is published every 10 seconds anyway, there shouldn't be a disconnection. Can you look in your MQTT logs for risco-mqtt-XXXXX disconnects please? Do you get any messages in the HA logs when you're trying to operate the bypass switches or arm the partitions? Interesting about the bypasses. The bypass switches for entry/exit zones also turn up for all zones in my version of RiscoCloud but it doesn't do anything for entry/exit zones - no bypass occurs. This may be a firmware version difference. I can make that optional if the bypass is actually functional for you.

[pergolafabio]

hmm, dont see any disconnects on broker addon, also no errors in log from HA it self

Maybe its best to remove the check for bypass zones , maybe indeed supported for other type of panels?

in screenshot below, the ones in yellow are from the vanackei addon, working the one in purple are from yours, you can see i do an "armed_away" , but status stays on "disarmed"

Here is a copy from the config the working addon

{"name":"Pergola Quintens","command_topic":"riscopanel/risco_alarm/partition/1/set","state_topic":"riscopanel/risco_alarm/partition/1/status","unique_id":"risco_alarm-partition_1","availability":{"topic":"riscopanel/risco_alarm/status"},"device":{"manufacturer":"Risco","model":"LightSys/RP432","name":"Risco Alarm","sw_version":"2.70","identifiers":"risco_alarm"}}

Here is a copy of yours, there are differences?

{"name":"risco alarm panelPergola Quintens","object_id":"risco-alarm-panel-1","state_topic":"risco-alarm-panel/alarm/partition/1/status","unique_id":"risco-alarm-panel-partition-1","availability":{"topic":"risco-alarm-panel/alarm/status"},"payload_disarm":"disarmed","payload_arm_away":"armed_away","payload_arm_home":"armed_home","payload_arm_night":"armed_home","payload_arm_vacation":"armed_away","payload_arm_custom_bypass":"armed_home","device":{"manufacturer":"Risco","model":"LightSys/RP432","name":"LightSys","sw_version":"2.70","identifiers":"risco-alarm-panel"},"command_topic":"risco-alarm-panel/alarm/partition/1/set"}

[markxroberts]

I think I've figured out the messaging problem. The new version includes some more options, including an option for switches to bypass all zones. There is a new naming convention for HA which applies to HA 2023.8 which I've looked at. I haven't yet revisited the internet disconnection issue.

[pergolafabio]

Hi , I check it out next week , or asap...

Indeed, there were changes since 2023.8, but the original addon didn't have an update, and that one still works? Or is yours working differently?

[pergolafabio]

Quickly tested it, and I think it works now correctly, I leave it running for a while now...

Now back to the internet connection issue :-)

[markxroberts]

I've tried a slightly different approach to this. The panel connection sensor should now work properly as it relies on the clock. There are buttons to republish some MQTT info, and a third to restart communications. If I interrupt my risco-mqtt-local connection to the panel, this effectively restores the communication. To see if it works for proxies, you'll need to interrupt both direct panel access (pull the cable out of the panel), and specifically cloud access (turn off your DSL/other connection).

[pergolafabio]

Hey, i updated to 2023.9 , but now i have error below :-(

can you quickly revert to older image? cause now i dont have any alarm anymore in HA :-)

9/11/2023, 9:36:00 AM [info] Setting a timer for panel connection in 30000 ms
9/11/2023, 9:36:00 AM [warn] Command[4] Command response was unexpected, ignoring. Data[N05]
9/11/2023, 9:36:00 AM [warn] Command[4] Receipt of an error code: Invalid parameter
9/11/2023, 9:36:00 AM [warn] Command[3] Receipt of an error code: Invalid parameter
/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoComm.js:305
                    throw new Error(`Unsupported panel type : ${panelType}`);
                          ^
Error: Unsupported panel type : N05
    at RiscoComm.<anonymous> (/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoComm.js:305:27)
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/tslib/tslib.js:114:62)
    at runNextTicks (node:internal/process/task_queues:61:5)
    at listOnTimeout (node:internal/timers:528:9)
    at processTimers (node:internal/timers:502:7)

[pergolafabio]

here is debug:

9/11/2023, 9:39:00 AM [debug] Risco Panel Connected.
9/11/2023, 9:39:00 AM [verbose] Command[1] Sending Command: PNLCNF
9/11/2023, 9:39:00 AM [debug] Command[1] Writing command buffer to socket: [2,48,49,80,78,76,67,78,70,23,70,49,68,53,3]
9/11/2023, 9:39:00 AM [debug] Command[1] Data Sent : PNLCNF
9/11/2023, 9:39:00 AM [debug] [Panel => Bridge] Received unencrypted data Buffer from Panel : [2,48,52,78,48,53,23,53,54,70,52,3]
9/11/2023, 9:39:00 AM [debug] Received data Buffer : [2,48,52,78,48,53,23,53,54,70,52,3]
9/11/2023, 9:39:00 AM [debug] Command[4] crcOK : true, Computed CRC : 56F4, Message CRC: 56F4
9/11/2023, 9:39:00 AM [verbose] Command[4] Received data: N05, crcOk: true
9/11/2023, 9:39:00 AM [debug] Command[4] Command response from Panel
9/11/2023, 9:39:00 AM [warn] Command[4] Command response was unexpected, ignoring. Data[N05]
9/11/2023, 9:39:00 AM [warn] Command[4] Receipt of an error code: Invalid parameter
9/11/2023, 9:39:00 AM [debug] Risco Panel Connected.
9/11/2023, 9:39:00 AM [verbose] Command[2] Sending Command: PNLCNF
9/11/2023, 9:39:00 AM [debug] Command[2] Writing command buffer to socket: [2,48,50,80,78,76,67,78,70,23,69,52,57,53,3]
9/11/2023, 9:39:00 AM [debug] Command[2] Data Sent : PNLCNF
9/11/2023, 9:39:00 AM [debug] [Panel => Cloud] Forwarding panel packet to cloud: [2,19,53,53,4,81,0,16,3,0,51,48,48,53,48,48,50,48,52,49,50,32,32,32,32,32,65,65,65,65,65,65,32,32,32,32,32,32,32,32,32,32,0,0,23,23,69,76,16,2,112,1,255,255,255,255,255,255,49,16,2,49,0,0,0,0,6,255,30,236,60,0,0,16,2,15,49,57,50,46,49,54,56,46,48,48,48,46,48,50,54,1,23,68,53,50,66,3]
9/11/2023, 9:39:00 AM [debug] Risco Panel Connected.
9/11/2023, 9:39:00 AM [verbose] Command[3] Sending Command: PNLCNF
9/11/2023, 9:39:00 AM [debug] Command[3] Writing command buffer to socket: [2,48,51,80,78,76,67,78,70,23,50,56,53,52,3]
9/11/2023, 9:39:00 AM [debug] Command[3] Data Sent : PNLCNF
9/11/2023, 9:39:00 AM [debug] [Panel => Bridge] Received unencrypted data Buffer from Panel : [2,48,50,78,48,53,23,53,54,55,67,3]
9/11/2023, 9:39:00 AM [debug] Received data Buffer : [2,48,50,78,48,53,23,53,54,55,67,3]
9/11/2023, 9:39:00 AM [debug] Command[2] crcOK : true, Computed CRC : 567C, Message CRC: 567C
9/11/2023, 9:39:00 AM [verbose] Command[2] Received data: N05, crcOk: true
9/11/2023, 9:39:00 AM [debug] Command[2] Command response from Panel
9/11/2023, 9:39:00 AM [debug] Command[2] Emitting expected command response
9/11/2023, 9:39:00 AM [warn] Command[2] Receipt of an error code: Invalid parameter
9/11/2023, 9:39:00 AM [debug] Command[2] command response : N05
/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoComm.js:305
                    throw new Error(`Unsupported panel type : ${panelType}`);
                          ^
Error: Unsupported panel type : N05
    at RiscoComm.<anonymous> (/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoComm.js:305:27)
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/tslib/tslib.js:114:62)

[markxroberts]

Hopefully I've now found the cause of that unexpected error...2023.9.1

[pergolafabio]

ah ok,good :-)

i dont see the 2023.9.1 yet in this file:

https://github.com/markxroberts/risco-mqtt-local/blob/main/risco-mqtt-local-addon/config.yaml

[markxroberts]

Sorry. You should be able to see it now.

[pergolafabio]

ok, updated , i now see the new sensors, alltough the "cloud connection status" is still unknown?

I now unplugged UTP and plugged back in i see then in log below, but sensor is still unavaible

9/11/2023, 12:07:02 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":26,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,48,51,72,91,96,29,246,109,196,222,225,224,3]}}
9/11/2023, 12:07:06 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms
9/11/2023, 12:07:06 PM [verbose] [Panel => MQTT] Published cloud connection status 0

then i see:

9/11/2023, 12:08:08 PM [debug] RiscoCloud Socket: connect
9/11/2023, 12:08:08 PM [info] RiscoCloud Socket: ready
9/11/2023, 12:08:08 PM [verbose] [Panel => MQTT] Published cloud connection status 1
9/11/2023, 12:08:12 PM [verbose] Command[29] Sending Command: CLOCK

but it never comes back online, i see the whole time a loop of messages below: Maybe i need to change the my config?

    "watchDogInterval": 10000,
    "cloudConnectionDelay": 10000,

looping below:

9/11/2023, 12:10:19 PM [info] RiscoCloud Socket: ready
9/11/2023, 12:10:19 PM [verbose] [Panel => MQTT] Published cloud connection status 1
9/11/2023, 12:10:22 PM [warn] Command[33] 'CLOCK' Timeout
9/11/2023, 12:10:22 PM [verbose] Command[33] retrying command
9/11/2023, 12:10:22 PM [verbose] Command[33] Sending Command: CLOCK
9/11/2023, 12:10:22 PM [debug] Command[33] Writing command buffer to socket: [2,17,49,54,72,91,96,29,246,109,183,169,232,228,3]
9/11/2023, 12:10:22 PM [debug] Command[33] Data Sent : CLOCK
9/11/2023, 12:10:27 PM [warn] Command[33] 'CLOCK' Timeout
9/11/2023, 12:10:27 PM [verbose] Command[33] retrying command
9/11/2023, 12:10:27 PM [verbose] Command[33] Sending Command: CLOCK
9/11/2023, 12:10:27 PM [debug] Command[33] Writing command buffer to socket: [2,17,49,54,72,91,96,29,246,109,183,169,232,228,3]
9/11/2023, 12:10:27 PM [debug] Command[33] Data Sent : CLOCK
9/11/2023, 12:10:32 PM [warn] Command[33] 'CLOCK' Timeout
9/11/2023, 12:10:32 PM [debug] Command[33] command response : undefined
9/11/2023, 12:10:32 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":33,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,54,72,91,96,29,246,109,183,169,232,228,3]}}
9/11/2023, 12:10:35 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms
9/11/2023, 12:10:35 PM [verbose] [Panel => MQTT] Published cloud connection status 0
9/11/2023, 12:10:42 PM [verbose] Command[34] Sending Command: CLOCK
9/11/2023, 12:10:42 PM [debug] Command[34] Writing command buffer to socket: [2,17,49,49,72,91,96,29,246,109,196,169,150,153,3]
9/11/2023, 12:10:42 PM [debug] Command[34] Data Sent : CLOCK
9/11/2023, 12:10:45 PM [debug] RiscoCloud Socket: connect
9/11/2023, 12:10:45 PM [info] RiscoCloud Socket: ready
9/11/2023, 12:10:45 PM [verbose] [Panel => MQTT] Published cloud connection status 1
9/11/2023, 12:10:47 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 12:10:47 PM [verbose] Command[34] retrying command
9/11/2023, 12:10:47 PM [verbose] Command[34] Sending Command: CLOCK
9/11/2023, 12:10:47 PM [debug] Command[34] Writing command buffer to socket: [2,17,49,49,72,91,96,29,246,109,196,169,150,153,3]
9/11/2023, 12:10:47 PM [debug] Command[34] Data Sent : CLOCK
9/11/2023, 12:10:52 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 12:10:52 PM [verbose] Command[34] retrying command
9/11/2023, 12:10:52 PM [verbose] Command[34] Sending Command: CLOCK
9/11/2023, 12:10:52 PM [debug] Command[34] Writing command buffer to socket: [2,17,49,49,72,91,96,29,246,109,196,169,150,153,3]
9/11/2023, 12:10:52 PM [debug] Command[34] Data Sent : CLOCK
9/11/2023, 12:10:57 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 12:10:57 PM [verbose] Command[34] retrying command
9/11/2023, 12:10:57 PM [verbose] Command[34] Sending Command: CLOCK
9/11/2023, 12:10:57 PM [debug] Command[34] Writing command buffer to socket: [2,17,49,49,72,91,96,29,246,109,196,169,150,153,3]
9/11/2023, 12:10:57 PM [debug] Command[34] Data Sent : CLOCK
9/11/2023, 12:11:01 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms
9/11/2023, 12:11:01 PM [verbose] [Panel => MQTT] Published cloud connection status 0
9/11/2023, 12:11:02 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 12:11:02 PM [debug] Command[34] command response : undefined
9/11/2023, 12:11:02 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":34,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,49,72,91,96,29,246,109,196,169,150,153,3]}}
9/11/2023, 12:11:11 PM [debug] RiscoCloud Socket: connect
9/11/2023, 12:11:11 PM [info] RiscoCloud Socket: ready
9/11/2023, 12:11:11 PM [verbose] [Panel => MQTT] Published cloud connection status 1

I also see a new button to restart communications: i pressed on it and that makes my connection comes back!! SO thats good SO i think if you can get the "cloud connections status sensor" to work , so it can restart communications, the issue could be fixed?

9/11/2023, 12:12:31 PM [debug] Socket Destroyed.
9/11/2023, 12:12:31 PM [debug] RiscoCloud Socket Destroyed.
9/11/2023, 12:12:31 PM [info] TCP Socket Disconnected
9/11/2023, 12:12:31 PM [info] Won't attempt automatic reconnection
9/11/2023, 12:12:31 PM [verbose] [Panel => MQTT] Published alarm offline
9/11/2023, 12:12:31 PM [verbose] [Panel => MQTT] Published panel connection status 0
9/11/2023, 12:12:56 PM [info] Listening on IP :: and Port 33000
9/11/2023, 12:12:56 PM [info] Waiting for panel incoming connection... This can take up to 1 or 2 minutes
9/11/2023, 12:14:59 PM [info] Incoming connection from panel received
9/11/2023, 12:14:59 PM [debug] RiscoCloud Socket: connect
9/11/2023, 12:14:59 PM [info] RiscoCloud Socket: ready
9/11/2023, 12:14:59 PM [verbose] [Panel => MQTT] Published cloud connection status 1
9/11/2023, 12:14:59 PM [info] Setting a timer for panel connection in 30000 ms
9/11/2023, 12:14:59 PM [debug] [Panel => Cloud] Forwarding panel packet to cloud: 

so all was good , but then i saw below, and it stopped there and didnt proceed anymore

9/11/2023, 12:15:15 PM [debug] [Cloud => Panel] Forwarding Cloud data Buffer to panel: [2,19,48,48,4,16,3,0,10,0,255,23,51,48,49,65,3]
9/11/2023, 12:15:29 PM [error] Panel Socket Closed.
9/11/2023, 12:15:29 PM [debug] RiscoCloud Socket Destroyed.
9/11/2023, 12:15:29 PM [verbose] [Panel => MQTT] Published alarm offline
9/11/2023, 12:15:29 PM [verbose] [Panel => MQTT] Published panel connection status 0
9/11/2023, 12:15:29 PM [warn] Panel Socket not connected, aborting panel connection sequence

[pergolafabio]

now after restart addon, i see now the sensor good:

[pergolafabio]

Gonna press now the "restart communications" button, lets see if it comes back ...

9/11/2023, 12:23:48 PM [debug] Socket Destroyed.
9/11/2023, 12:23:48 PM [debug] RiscoCloud Socket Destroyed.
9/11/2023, 12:23:48 PM [info] TCP Socket Disconnected
9/11/2023, 12:23:48 PM [info] Won't attempt automatic reconnection
9/11/2023, 12:23:48 PM [verbose] [Panel => MQTT] Published alarm offline
9/11/2023, 12:23:48 PM [verbose] [Panel => MQTT] Published panel connection status 0
9/11/2023, 12:23:53 PM [verbose] [Panel => MQTT] Published alarm offline
9/11/2023, 12:23:53 PM [verbose] [Panel => MQTT] Published panel connection status 0
9/11/2023, 12:24:18 PM [info] Listening on IP :: and Port 33000
9/11/2023, 12:24:18 PM [info] Waiting for panel incoming connection... This can take up to 1 or 2 minutes

It brought the connection back GOOD

[pergolafabio]

Gonna test again with the UTP disconnect now ... same loop, never comes back, pressed again the "restart communications" button , and this tiime it crashed

9/11/2023, 12:33:53 PM [debug] Socket Destroyed.
9/11/2023, 12:33:53 PM [verbose] [Panel => MQTT] Published alarm offline
9/11/2023, 12:33:53 PM [verbose] [Panel => MQTT] Published panel connection status 0
9/11/2023, 12:33:53 PM [verbose] [Panel => MQTT] Published alarm offline
9/11/2023, 12:33:56 PM [warn] Command[3] 'CLOCK' Timeout
/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoBaseSocket.js:243
                this.panelSocket.off('error', socketErrorHandler);
                                 ^
TypeError: Cannot read properties of undefined (reading 'off')
    at RiscoProxyTCPSocket.<anonymous> (/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoBaseSocket.js:243:34)
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/tslib/tslib.js:114:62)

There is progress tough, the "restart communications" button is a good start, it just now needs to detect the disconnect issue somehow?

[pergolafabio]

now restarted addon again, everything back online, but the cloud sensor is again "disconnected" while it should be connected

[markxroberts]

I’ve tried a small change to events. It won’t change initial cloud state.

[pergolafabio]

ok, installed 2023.9.2 You want me to test something?

[pergolafabio]

Can you also work with images in future? the addon takes a lot of space :-)

[markxroberts]

Thanks. Question is - does this 'crash' by itself as it did before without any intervention or not? I see that cloud is showing as disconnected. Is that just because it's become available again, or did you delete all sensors? If it doesn't crash by itself, I can move on and try to make all the sensors report properly.

What do you mean by images? This has always been available as a docker image, which is quite small as based on Alpine.

[pergolafabio]

i mean, by image, that you point here in this file https://github.com/markxroberts/risco-mqtt-local/blob/main/risco-mqtt-local-addon/config.yaml to an image on ghcr.io, lots of addon using it, i think your addons needs to build locally also: if you compare below to other addons:

[pergolafabio]

No, didnt delete any sensors in the mqtt integration, one time i saw the status to connected , not sure what triggered that, now its always "disconnected"

No, the crash happened after i pressed the "restart communications button" it started OK but then crashed, this only happened once, maybe the panel didnt like it

[markxroberts]

Thanks. Can you try disconnecting the panel and restarting communications.

[pergolafabio]

ok so:... 1) remove UTP/connection 2) press restart communicaions 3) insert back UTP

that method?

[pergolafabio]

it this also ok? Or do i need to change it?

  "watchDogInterval": 10000,
  "cloudConnectionDelay": 10000,

[markxroberts]

Yes, physical disconnection fine. Would also like to know what happens when you only disconnect Cloud (ie leave cable plugged in to router but disconnect router from internet. Leave all other settings the same please.

[pergolafabio]

ok, unplugged UTP

then pressed "restart comm buton"

9/11/2023, 3:51:53 PM [info] Message to reinitiate communications
9/11/2023, 3:51:53 PM [info] Waiting 30 seconds before reconnecting
9/11/2023, 3:51:54 PM [warn] Command[39] 'CLOCK' Timeout
9/11/2023, 3:51:54 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":39,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,60,72,91,96,29,246,109,183,169,226,149,3]}}
9/11/2023, 3:51:58 PM [warn] Command[40] 'DCN' Timeout
9/11/2023, 3:51:58 PM [warn] Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":40,"attempts":1,"crcOk":false,"commandStr":"DCN","sentBuffer":{"type":"Buffer","data":[2,17,54,53,79,84,97,73,248,75,176,220,3]}}
9/11/2023, 3:51:58 PM [warn] Error while sending DCN command
9/11/2023, 3:51:58 PM [info] TCP Socket Disconnected
9/11/2023, 3:51:58 PM [info] Won't attempt automatic reconnection
9/11/2023, 3:52:23 PM [info] Listening on IP :: and Port 33000
9/11/2023, 3:52:23 PM [info] Waiting for panel incoming connection... This can take up to 1 or 2 minutes

Now plugged back in UTP and it restarted fine!!

About the test to disable router from internet , that will be the same... I have configured an inbound rule on my router, all traffic from my risco panel goes to the addon, not directly to www.riscocloud.com , its the addon/proxy thats connected to internet

[pergolafabio]

the restart comm should be done, once its senses the connected to disconnected? does that happen? or do you need to implement that?

[pergolafabio]

i will try tro disconnect again the UTP, now the sensors is in a "connected" state, that wasnt before, lets see what happens now

[pergolafabio]

ok, discoonected the cable, but then the sensors goes from "connected" to "unavaible" , it should go to "disconnected", right?

then it goes back to the same loop again and again

now pressed the "restart comm" button, and i see the crash again:

9/11/2023, 4:22:29 PM [error] Panel Socket Closed.
9/11/2023, 4:22:29 PM [warn] sendCommand(ZLBL*1:8?): Socket is destroyed, ignoring command
9/11/2023, 4:22:29 PM [warn] sendCommand(PNLCNF): Socket is destroyed, ignoring command
/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoComm.js:305
                    throw new Error(`Unsupported panel type : ${panelType}`);
                          ^
Error: Unsupported panel type : 
    at RiscoComm.<anonymous> (/app/node_modules/@markxroberts/risco-lan-bridge/dist/RiscoComm.js:305:27)
    at Generator.next (<anonymous>)
    at fulfilled (/app/node_modules/tslib/tslib.js:114:62)

[markxroberts]

Few things.

1. Does it run OK if you don't interrupt it? Does it crash spontaneously?
2. If you disconnect and reconnect ethernet cable, and then push restart communications, does that work? It's very likely to crash if no ethernet connection when you restart
3. Don't know how to do 'images' - sorry!
4. Am releasing 2023.9.3 with delayed offline with cloud clock and to fix panel and cloud availability sensor

[pergolafabio]

Hi

1) when its running, its stable, i would look to much for this error, got them just random, when its final, i will enable the watchdog anyway, so in case it happens, it restarts anyway

2) yes, when restarting communication manually, it connects again!

3) you can have a look at this workflow, it creates an image, and then in your config file, you can point to that image: https://github.com/vanackej/risco-mqtt-local/blob/main/.github/workflows/ha-addon-builder.yaml

4) will test tomorrow

[pergolafabio]

ok, quickly tested 2023.9.3 :-)

When UTP was out, the "cloud connection" sensor was constantly swittching between "connected" and "disconnected" now, not sure if thats ok??

in the loops below

9/11/2023, 7:25:59 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":33,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,54,72,91,96,29,246,109,183,169,232,228,3]}}
9/11/2023, 7:26:09 PM [info] RiscoCloud Socket: ready
9/11/2023, 7:26:14 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 7:26:19 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 7:26:24 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 7:26:25 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms
9/11/2023, 7:26:30 PM [warn] Command[34] 'CLOCK' Timeout
9/11/2023, 7:26:30 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":34,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,49,72,91,96,29,246,109,196,169,150,153,3]}}
9/11/2023, 7:26:35 PM [info] RiscoCloud Socket: ready
9/11/2023, 7:26:45 PM [warn] Command[35] 'CLOCK' Timeout
9/11/2023, 7:26:50 PM [warn] Command[35] 'CLOCK' Timeout
9/11/2023, 7:26:51 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms
9/11/2023, 7:26:55 PM [warn] Command[35] 'CLOCK' Timeout
9/11/2023, 7:27:00 PM [warn] Command[35] 'CLOCK' Timeout
9/11/2023, 7:27:00 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":35,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,48,72,91,96,29,246,109,183,169,149,153,3]}}
9/11/2023, 7:27:01 PM [info] RiscoCloud Socket: ready
9/11/2023, 7:27:15 PM [warn] Command[36] 'CLOCK' Timeout
9/11/2023, 7:27:17 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms
9/11/2023, 7:27:20 PM [warn] Command[36] 'CLOCK' Timeout
9/11/2023, 7:27:25 PM [warn] Command[36] 'CLOCK' Timeout
9/11/2023, 7:27:27 PM [info] RiscoCloud Socket: ready
9/11/2023, 7:27:30 PM [warn] Command[36] 'CLOCK' Timeout
9/11/2023, 7:27:30 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":36,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,51,72,91,96,29,246,109,183,169,148,227,3]}}
9/11/2023, 7:27:43 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms
9/11/2023, 7:27:45 PM [warn] Command[37] 'CLOCK' Timeout
9/11/2023, 7:27:50 PM [warn] Command[37] 'CLOCK' Timeout
9/11/2023, 7:27:53 PM [info] RiscoCloud Socket: ready
9/11/2023, 7:27:55 PM [warn] Command[37] 'CLOCK' Timeout
9/11/2023, 7:28:00 PM [warn] Command[37] 'CLOCK' Timeout
9/11/2023, 7:28:00 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":37,"attempts":4,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,49,50,72,91,96,29,246,109,196,169,147,227,3]}}
9/11/2023, 7:28:09 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms

When i inserted back the UTP, it was still looping ...

i had to restart the with the "restart connection" button

isnt it possible on the events below maybe, to restart communication?

9/11/2023, 7:30:44 PM [error] RiscoCloud Socket: close. Retrying within 10000 ms

9/11/2023, 7:32:27 PM [error] Panel Socket Closed.

[markxroberts]

Thanks for the update and for testing. It looks as though the correct status updates are being emitted from risco-lan-bridge. What's not correct (in my view) is that every 10 seconds we're seeing a RiscoCloud Socket: ready. This is what is causing the cloud connection sensor to flick between connected and disconnected (and isn't true!).

When RiscoCloud Socket: close appears in the log, this should change the Cloud Connection sensor to off for much longer.

Previously I tried to pick up on the close event to restart communication from within risco-lan-bridge and it ended up crashing.

Risco-mqtt-local really only reflects risco-lan-bridge via HA, so it's a bit tricky to put the automatic reconnection logic in there.

I'll have a think about solutions.

[pergolafabio]

Ok, thnx already for investigating this!!

[markxroberts]

I've released 9.6. Hopefully this now has images for you to use. I've removed the separate cloud and panel sensors and just put in a proxy sensor. I don't think it's possible with the proxy to disconnect either cloud or panel separately - both fail. Therefore we just need a sensor for both. There's a new configuration option auto_reconnect: boolean which enables auto reconnect after clock timeout. The buttons are still available to instigate this manually.

[pergolafabio]

ok, but i dont see 2023.9.6 yet, seems its not updated in "main" yet

[pergolafabio]

i think you also published to dockerhub, not ghcr.io HA users ghcr, not dockerhub i believe

[pergolafabio]

about the clock timeout, i see them sometimes a lot, but it stays connected... does it mean, now it will break and restart communications if i define auto_reconnect: true ? Bceuase thats maybe not good either?

see here

9/11/2023, 7:52:01 PM [info] [MQTT => Panel] disarmed command sent on partition 1
9/11/2023, 10:31:10 PM [warn] Command[11] 'CLOCK' Timeout
9/11/2023, 10:31:10 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":11,"attempts":1,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,51,52,72,91,96,29,246,109,176,219,226,226,3]}}
9/11/2023, 11:36:13 PM [warn] Command[6] 'CLOCK' Timeout
9/11/2023, 11:36:13 PM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":6,"attempts":1,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,50,51,72,91,96,29,246,109,176,174,233,227,3]}}
9/12/2023, 3:48:39 AM [warn] Command[40] 'CLOCK' Timeout
9/12/2023, 3:48:39 AM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":40,"attempts":1,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,54,53,72,91,96,29,246,109,198,171,150,226,3]}}
9/12/2023, 4:21:57 AM [warn] Command[42] 'CLOCK' Timeout
9/12/2023, 4:21:57 AM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: {"panelId":1,"commandId":42,"attempts":1,"crcOk":false,"commandStr":"CLOCK","sentBuffer":{"type":"Buffer","data":[2,17,54,55,72,91,96,29,246,109,177,171,148,231,3]}}
9/12/2023, 4:55:56 AM [warn] Command[48] 'CLOCK' Timeout
9/12/2023, 4:55:56 AM [warn] Failed to send CLOCK command: RiscoCommandError: Risco command error: TIMEOUT. Command: 

[markxroberts]

It's not failing very often. It won't be every fail. It will wait for 30 seconds before initiating a reconnection. See how it goes...

[pergolafabio]

i cant use / install it :

Can't install ghcr.io/markxroberts/risco-mqtt-local-addon-amd64:2023.9.6: 500 Server Error for http+docker://localhost/v1.42/images/create?tag=2023.9.6&fromImage=ghcr.io%2Fmarkxroberts%2Frisco-mqtt-local-addon-amd64&platform=linux%2Famd64: Internal Server Error ("manifest unknown")

i think its because your image is on dockerhub, and not ghcr.io

i dont see any here: https://github.com/markxroberts/risco-mqtt-local/pkgs/container/risco-mqtt-local-addon-amd64

maybe remove the image tag now? :-)

[markxroberts]

OK. I've tried to remake this...

[pergolafabio]

perfect, now the image works, installs much faster