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:

[Lloyd-Davies]

I am also experiencing the same issue. Experimented with adding the option: "ReconnectDelay: 10000," to the json file. Unable to confirm if it fixes it, but I will report my findings in due course.

[pergolafabio]

Ah, that's worth a try, gonna test that also, it's easy to replicate, just unplug the network cable :+)

Today there was a risco cloud upgrade, the addon wasnt able to reconnect, untill a manually restart

[Lloyd-Davies]

Unfortunately, issue still persists.

Hopefully a solution can be devised, such as automatically attempting to reinitiate the cloud connection every 10 seconds until it reconnects, similarly to the way the add-on already does with the panel.

[pergolafabio]

Ah that's a bummer, I didn't test yet...

Shouldnt be to difficult I think?

@vanackej , do you have some time to look at this issue?

Thnx in advance

[markxroberts]

The add-on does do an automatic reconnect, which is what you're seeing here. The automatic delay is currently set at 5 seconds and is not user-configurable.

[pergolafabio]

No it doesn't always do a reconnect, if I unplug the UTP from the panel, I can simulate the issue... Seems it doesn't reconnect then, not sure why

[markxroberts]

I wonder if the automatic reconnect is failing. It may be that the interval between disconnecting and reconnecting is too short, although the logs would suggest that the connection is re-established and then dropped. When the connection initialises at startup, do the logs show 'connect' then 'ready'?

[pergolafabio]

Hi , I will do some testing when I'm back home from vacation, thnx in advance..

Are you improving this addon?

[markxroberts]

I've been doing some development work for a while. Some of this is working well. I'm not a programmer, though, so much is trial and error. I run HA in a docker and don't need the proxy socket, so rely on others to test. I've only just tried to make add-ons.

[pergolafabio]

Ah ok, :-)

Do you have the knowledge to extract the proxy from the addon, so I can just only run proxy in separate addon, and use the official pyrisco integration in HA itself?

[markxroberts]

This would be a separate project and really needs to be an adaptation of the pyrisco project. Pyrisco is written in python and communicates with the panel directly, including portions of risco-lan-bridge project. The original project is written in typescript and is divided in to two parts: the risco-lan-bridge project communicating with the panel, and the risco-mqtt-local project that publishes to MQTT. I've now had a go at making the cloud reconnection interval user configurable. I've also added a sensor for cloud connection. Hopefully these might work.

[pergolafabio]

Yes, indeed , it's an separate project, is it doable? Would be nice for official risco integration

[pergolafabio]

I thought the proxy inside the docker was just Somekind of code that listen for incoming connection and forwards to risco?

[markxroberts]

Your description is correct, but the key here is how the different parts of the system communicate with each other. It’s definitely possible though.

[pergolafabio]

Well, let me know if you are interested, maybe we can make a separate topic about it? We can maybe also I clude onFreund, owner of the pyrisco , I "know" him as well

[pergolafabio]

Hi @markxroberts , back on topic, i'm home again, and did a test I started the Addon , around 07:21 i unplugged my UTP cable from risco panel, you see in log, its giving an error at around 07.28 i plug in again the UTP cable, but as you can see, it doesnt reconnect, it stays in the loop To make it work again, i have to restart the addon again ....

So on any internet/router/switch issue, the addon fails everytime, would be great if it can restart or does a reconnect somehow

...

thnx for looking into it!!

logs: risco.log

[markxroberts]

Thanks. There's no obvious reconnect here. I've made some updates in the latest release. See if those work. The reconnection delay is configurable and there's a cloud connection sensor.

[pergolafabio]

Ok , then I need to install the addon from your repo instead? What do I need to set for the delay?

Is there a new setting in the Json file then?

[markxroberts]

You might need to experiment with the delay. The default is 5 seconds, but I'd try 10 seconds minimum. The setting in the config.json file is cloudReconnectionDelay.

[pergolafabio]

Ok , I test it out asap , I also see you have outputs, that's nice..

[pergolafabio]

What is the function anyway of the cloud reconnect delay? Does it check if there is cloud connection, if not it does somekind of restart?

[markxroberts]

The reconnect function already exists. The hypothesis is that this doesn't work properly because it doesn't have the time to reset itself before it's asked for a repeat connection. Making the delay user-configurable tests the hypothesis.

[pergolafabio]

ok, quickly installed 2023.7.3 , using same config file as before

I see this in logs:

7/23/2023, 10:57:52 AM [info] Subscribing to Home assistant commands topics
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/partition/1/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/1-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/2-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/3-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/4-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/5-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/6-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/7-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to risco-alarm-panel/alarm/zone/8-bypass/set topic
7/23/2023, 10:57:52 AM [info] Subscribing to panel partitions events
7/23/2023, 10:57:52 AM [info] Subscribing to panel zones events
7/23/2023, 10:57:52 AM [info] Subscribing to panel outputs events
7/23/2023, 10:57:52 AM [info] Subscribing to panel system events
7/23/2023, 10:57:52 AM [info] Subscribing to Home Assistant online status
7/23/2023, 10:57:52 AM [info] Initialization completed
7/23/2023, 10:57:52 AM [info] homeassistant/status was subscribed
7/23/2023, 11:01:08 AM [error] RiscoCloud Socket Timeout.
7/23/2023, 11:05:08 AM [error] RiscoCloud Socket Timeout.

as for sensors, i have a lot of unknown, also myt panel itself is unknown ?

[pergolafabio]

alltough i see this in logs, my panel is unknown:

7/23/2023, 11:09:15 AM [info] [Panel => MQTT][Discovery] Published cloud status sensor, HA name = Cloud connection status
7/23/2023, 11:09:15 AM [info] [Panel => MQTT][Discovery] Published panel status sensor, HA name = Panel connection status
7/23/2023, 11:09:15 AM [info] [Panel => MQTT][Discovery] Published System message sensor, HA name = System message
7/23/2023, 11:09:15 AM [info] [Panel => MQTT][Discovery] Published alarm_control_panel to HA Output label = Pergola Quintens, HA name = risco alarm panelPergola Quintens on partition 1

[pergolafabio]

This is my panel config, allthough the IP is incorrect, its a fictive setting, since i use the proxy method... Maybe i need to remove all IP settings there?

{
  "log": "info",
  "logColorize": true,
  "panel": {
    "panelIp": "192.168.1.150",
    "panelPort": 1000,
    "panelPassword": XXXX,
    "panelId": "0001",
    "watchDogInterval": 10000,
    "cloudConnectionDelay": 10000,
    "guessPasswordAndPanelId": false,
    "Disable_RiscoCloud":  true,
    "Enable_RiscoCloud":  true,
    "autoDiscover":  false,
    "socketMode": "proxy",
    "listeningPort": 33000,
    "cloudPort": 33000,
    "cloudUrl": "www.riscocloud.com"    
  },
  "mqtt": {
    "url": "mqtt://homeassistant:1883",
    "username": "XXXX",
    "password": "XXXX"
  },
  "zones": {
    "default": {
      "off_delay": 0,
      "name_prefix": ""
    },
    "GARAGE": {
      "off_delay": 0,
      "device_class": "garage_door",
      "name": "Garage Door",
      "name_prefix": ""
    }
  }
}

[pergolafabio]

Seems i have 2022.7.3 , but i see you have 2 newer versions avaible? .4 and .5 ? Can you update the config file so i can update the addon? so i can test those ones

thnx

[markxroberts]

2022.7.4 and .5 won't update this. It's the risco-lan-bridge library that needs updating. I'll take a look as soon as a can. Will take a few days. Something's going wrong at startup.

[pergolafabio]

Ok, np, take your time..

Thnx for looking into it

[markxroberts]

So, when I refactored this I've included discovery of more devices. I wonder whether this has caused the timeout. The socket timeout was set at 120 seconds, and there's much more than that between the start and the finish of your discovery. I've lengthened this delay. You now have the latest version of the library including group arming. The reason that everything is unknown is that no state has been published. I don't know whether this will fix it, but give it a go.

[pergolafabio]

Ok, I test it tomorrow, thnx in advance

[pergolafabio]

Hi, tried the new update, the sensors are unknown, but on presence detected they are working , but the panel itself is still unknown?

7/28/2023, 9:02:00 AM [info] Subscribing to Home assistant commands topics
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/partition/1/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/1-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/2-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/3-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/4-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/5-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/6-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/7-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to risco-alarm-panel/alarm/zone/8-bypass/set topic
7/28/2023, 9:02:00 AM [info] Subscribing to panel partitions events
7/28/2023, 9:02:00 AM [info] Subscribing to panel zones events
7/28/2023, 9:02:00 AM [info] Subscribing to panel outputs events
7/28/2023, 9:02:00 AM [info] Subscribing to panel system events
7/28/2023, 9:02:00 AM [info] Subscribing to Home Assistant online status
7/28/2023, 9:02:00 AM [info] Initialization completed
2023-07-28T07:02:00.486Z System initialization completed.
7/28/2023, 9:02:00 AM [info] homeassistant/status was subscribed
2023-07-28T07:02:00.547Z [Panel => Bridge] Received encrypted data Buffer from Panel : [2,17,58,52,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,133,127,148,146,113,198,3]
2023-07-28T07:02:00.547Z Received data Buffer : [2,17,58,52,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,133,127,148,146,113,198,3]
2023-07-28T07:02:00.548Z Command[81] crcOK : true, Computed CRC : D32A, Message CRC: D32A
2023-07-28T07:02:00.548Z Command[81] Received data: CLOCK=28/07/2023 09:01, crcOk: true
2023-07-28T07:02:00.548Z Command[81] Data from Panel, need to send an ACK
2023-07-28T07:02:00.549Z Command[81] Sending Ack.
2023-07-28T07:02:00.549Z Command[81] Data type: Clock
2023-07-28T07:02:00.627Z [Panel => Bridge] Received encrypted data Buffer from Panel : [2,17,58,55,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,148,226,0,194,3]
2023-07-28T07:02:00.627Z Received data Buffer : [2,17,58,55,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,148,226,0,194,3]
2023-07-28T07:02:00.627Z Command[82] crcOK : true, Computed CRC : DCCE, Message CRC: DCCE
2023-07-28T07:02:00.627Z Command[82] Received data: CLOCK=28/07/2023 09:02, crcOk: true
2023-07-28T07:02:00.627Z Command[82] Data from Panel, need to send an ACK
2023-07-28T07:02:00.627Z Command[82] Sending Ack.
2023-07-28T07:02:00.628Z Command[82] Data type: Clock
2023-07-28T07:02:10.464Z Command[14] Sending Command: CLOCK
2023-07-28T07:02:10.464Z Command[14] Writing command buffer to socket: [2,17,51,49,72,91,96,29,246,109,176,219,231,152,3]
2023-07-28T07:02:10.464Z Command[14] Data Sent : CLOCK
2023-07-28T07:02:10.576Z [Panel => Bridge] Received encrypted data Buffer from Panel : [2,17,51,49,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,148,145,5,197,3]
2023-07-28T07:02:10.577Z Received data Buffer : [2,17,51,49,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,148,145,5,197,3]
2023-07-28T07:02:10.577Z Command[14] crcOK : true, Computed CRC : D0FB, Message CRC: D0FB
2023-07-28T07:02:10.577Z Command[14] Received data: CLOCK=28/07/2023 09:02, crcOk: true
2023-07-28T07:02:10.577Z Command[14] Command response from Panel
2023-07-28T07:02:10.577Z Command[14] Emitting expected command response
2023-07-28T07:02:10.577Z Command[14] Data type: Clock
2023-07-28T07:02:10.586Z Command[14] command response : CLOCK=28/07/2023 09:02
2023-07-28T07:02:20.590Z Command[15] Sending Command: CLOCK
2023-07-28T07:02:20.591Z Command[15] Writing command buffer to socket: [2,17,51,48,72,91,96,29,246,109,197,219,230,152,3]
2023-07-28T07:02:20.591Z Command[15] Data Sent : CLOCK
2023-07-28T07:02:20.656Z [Panel => Bridge] Received encrypted data Buffer from Panel : [2,17,51,48,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,228,148,16,2,177,3]
2023-07-28T07:02:20.656Z Received data Buffer : [2,17,51,48,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,228,148,16,2,177,3]
2023-07-28T07:02:20.656Z Command[15] crcOK : true, Computed CRC : 45A6, Message CRC: 45A6
2023-07-28T07:02:20.656Z Command[15] Received data: CLOCK=28/07/2023 09:02, crcOk: true
2023-07-28T07:02:20.656Z Command[15] Command response from Panel
2023-07-28T07:02:20.656Z Command[15] Emitting expected command response
2023-07-28T07:02:20.656Z Command[15] Data type: Clock
2023-07-28T07:02:20.662Z Command[15] command response : CLOCK=28/07/2023 09:02
2023-07-28T07:02:30.662Z Command[16] Sending Command: CLOCK
2023-07-28T07:02:30.663Z Command[16] Writing command buffer to socket: [2,17,51,51,72,91,96,29,246,109,197,219,229,224,3]
2023-07-28T07:02:30.663Z Command[16] Data Sent : CLOCK
2023-07-28T07:02:30.685Z [Panel => Bridge] Received encrypted data Buffer from Panel : [2,17,51,51,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,146,224,119,181,3]
2023-07-28T07:02:30.685Z Received data Buffer : [2,17,51,51,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,146,224,119,181,3]
2023-07-28T07:02:30.685Z Command[16] crcOK : true, Computed CRC : BA42, Message CRC: BA42
2023-07-28T07:02:30.685Z Command[16] Received data: CLOCK=28/07/2023 09:02, crcOk: true
2023-07-28T07:02:30.685Z Command[16] Command response from Panel
2023-07-28T07:02:30.687Z Command[16] Emitting expected command response
2023-07-28T07:02:30.687Z Command[16] Data type: Clock
2023-07-28T07:02:30.693Z Command[16] command response : CLOCK=28/07/2023 09:02
2023-07-28T07:02:40.697Z Command[17] Sending Command: CLOCK
2023-07-28T07:02:40.698Z Command[17] Writing command buffer to socket: [2,17,51,50,72,91,96,29,246,109,176,219,228,224,3]
2023-07-28T07:02:40.698Z Command[17] Data Sent : CLOCK
2023-07-28T07:02:40.785Z [Panel => Bridge] Received encrypted data Buffer from Panel : [2,17,51,50,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,226,231,114,193,3]
2023-07-28T07:02:40.785Z Received data Buffer : [2,17,51,50,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,226,231,114,193,3]
2023-07-28T07:02:40.785Z Command[17] crcOK : true, Computed CRC : 2F1F, Message CRC: 2F1F
2023-07-28T07:02:40.785Z Command[17] Received data: CLOCK=28/07/2023 09:02, crcOk: true
2023-07-28T07:02:40.785Z Command[17] Command response from Panel
2023-07-28T07:02:40.785Z Command[17] Emitting expected command response
2023-07-28T07:02:40.785Z Command[17] Data type: Clock
2023-07-28T07:02:40.789Z Command[17] command response : CLOCK=28/07/2023 09:02
2023-07-28T07:02:50.790Z Command[18] Sending Command: CLOCK
2023-07-28T07:02:50.790Z Command[18] Writing command buffer to socket: [2,17,51,61,72,91,96,29,246,109,176,219,146,148,3]
2023-07-28T07:02:50.791Z Command[18] Data Sent : CLOCK
2023-07-28T07:02:50.844Z [Panel => Bridge] Received encrypted data Buffer from Panel : [2,17,51,61,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,149,231,117,194,3]
2023-07-28T07:02:50.844Z Received data Buffer : [2,17,51,61,72,91,96,29,246,71,198,208,255,145,117,170,57,38,31,105,149,91,239,151,106,134,127,149,231,117,194,3]
2023-07-28T07:02:50.844Z Command[18] crcOK : true, Computed CRC : EF6E, Message CRC: EF6E
2023-07-28T07:02:50.844Z Command[18] Received data: CLOCK=28/07/2023 09:02, crcOk: true
2023-07-28T07:02:50.844Z Command[18] Command response from Panel
2023-07-28T07:02:50.844Z Command[18] Emitting expected command response
2023-07-28T07:02:50.844Z Command[18] Data type: Clock
2023-07-28T07:02:50.851Z Command[18] command response : CLOCK=28/07/2023 09:02

[pergolafabio]

this the log from the official addon from vaneckej, i see here this: 7/28/2023, 9:06:36 AM [info] [Panel => MQTT] Published alarm status disarmed on partition 1

I dont see that in your log?

7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published alarm_control_panel to HA on partition 1
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Bureau, HA name = Bureau
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = Bureau, HA name = Bureau Bypass
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Living, HA name = Living
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = Living, HA name = Living Bypass
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Inkom, HA name = Inkom
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = Inkom, HA name = Inkom Bypass
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Boven, HA name = Boven
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = Boven, HA name = Boven Bypass
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = Keuken, HA name = Keuken
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = Keuken, HA name = Keuken Bypass
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = RM Bureau, HA name = RM Bureau
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = RM Bureau, HA name = RM Bureau Bypass
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = RM Zolder, HA name = RM Zolder
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = RM Zolder, HA name = RM Zolder Bypass
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published binary_sensor to HA: Zone label = RM Wasplaats, HA name = RM Wasplaats
7/28/2023, 9:06:36 AM [info] [Panel => MQTT][Discovery] Published switch to HA: Zone label = RM Wasplaats, HA name = RM Wasplaats Bypass
7/28/2023, 9:06:36 AM [info] Publishing initial partitions and zones state to Home assistant
7/28/2023, 9:06:36 AM [info] [Panel => MQTT] Published alarm status disarmed on partition 1
7/28/2023, 9:06:36 AM [info] Subscribing to Home assistant commands topics
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/partition/1/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/1-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/2-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/3-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/4-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/5-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/6-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/7-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to riscopanel/risco_alarm/zone/8-bypass/set topic
7/28/2023, 9:06:36 AM [info] Subscribing to panel partitions events
7/28/2023, 9:06:36 AM [info] Subscribing to panel zones events
7/28/2023, 9:06:36 AM [info] Subscribing to Home Assistant online status
7/28/2023, 9:06:36 AM [info] Initialization completed
7/28/2023, 9:06:36 AM [info] homeassistant/status was subscribed

[markxroberts]

I think the unavailability is because of the differing structure of MQTT topics in my version of this. Do you delete the device in HA before you initialize my version? I use the configuration option risco-node-id to differentiate between panels.

The reason you don't see partition status changed with 'info' level of logging is that I've changed the logging level for that to 'verbose'.

[pergolafabio]

ah ok, makes sense, yeah i always delete the complete mqtt device before running the new version WHat do i need to do them to see the arm status?

[markxroberts]

The final bit of the initialization depends on the addon 'seeing' the HA autodiscovery topic and getting an 'online' message from that. The topic it's looking for based upon the logs you show is homeassistant/status. The message is always online. If it doesn't see that, it won't initialize. That looks to be where it's getting stuck at the moment. The next message should be:

7/28/2023, 9:02:00 AM [info] Home Assistant is online
7/28/2023, 9:02:00 AM [info] Delay 30 seconds before publishing initial states

I have changed the initialization process, but it shouldn't really affect receipt of subscription messages, and if your sensors are changing, it would suggest that message reception is working.

[pergolafabio]

ahh, i know what was happening, i yhink its because of the first start All my entities are unavaible, once i walk before them, they get a state , there was no state history, so thats probably why the panel was unavaible in HA

Once i changed from disarmed to armed, i see now the state, also after a restart of the Addon, it now takes the last state

SO i think thats resolved

Lemme test now the UTP / interrupt with that new connection delay setting ...

[pergolafabio]

OK, tested with below settings

    "watchDogInterval": 10000,
    "cloudConnectionDelay": 10000,
    "guessPasswordAndPanelId": false,
    "Disable_RiscoCloud":  true,
    "Enable_RiscoCloud":  true,
    "autoDiscover":  false,
    "socketMode": "proxy",
    "listeningPort": 33000,
    "cloudPort": 33000,
    "cloudUrl": "www.riscocloud.com"

Unplugged UTP , wait a few min, plug back in , but as you can see in log, i waited long enough, the connection is not coming back... Should i increase the delay ?

What i also see, that new binary_sensor.risco_alarm_panel_cloud_connection_status , this one is always with state "connected" , it never changed during the panel dropoff from the network/internet ?

full log risco.log :

[pergolafabio]

I now also noticed when using the alarm panel in HA, I can't change the states anymore, it doesnt do anything

Need to revert now to original addon

[markxroberts]

So the logs supplied show a clock error to the panel rather than the cloud. This is because you're removing the cable from the panel so both connections are interrupted. Non-proxy connections don't show this error, but timeout after 4 attempts. I've amended the coded to reinitiate both connections after the timeout. I don't know whether this will solve your problem.

Your arming error is harder to explain. The arming should work, but unless you reload the frontend, the updated mappings for MQTT won't propagate. This may be causing the failure to arm that you are seeing. If you still have problems and can supply debug logs then I can look at this again.

I've removed the sensors for cloud and panel connections. These don't update as everything goes offline if they don't work, and this is probably the correct response. Latest version is 2023.7.6

[pergolafabio]

Ok, will try again, but have you updated now a newer? I already have 2023.7.6

[markxroberts]

Hopefully that will have newer content. The build was successful, so it should have been pushed.

On 30 Jul 2023, at 09:52, Pergola Fabio @.***> wrote:

Ok, will try again, but have you updated now a newer? I already have 2023.7.6

— Reply to this email directly, view it on GitHub https://github.com/vanackej/risco-mqtt-local/issues/57#issuecomment-1657082688, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2J4VZBKEZT4EFT6D6XONDXSYOEPANCNFSM6AAAAAAVJJL6F4. You are receiving this because you were mentioned.

[pergolafabio]

Ok I don't see the new version of the addon yet, you did t change the config.yaml , right? Then I think I need to uninstall and reinstall addon again, will also remove the Mqtt device then..

Will do it maybe today or tomorrow

[markxroberts]

Yes, that’s right.

On 30 Jul 2023, at 09:57, Pergola Fabio @.***> wrote:

Ok I don't see the new version of the addon yet, you did t change the config.yaml , right? Then I think I need to uninstall and reinstall addon again, will also remove the Mqtt device then..

Will do it maybe today or tomorrow

— Reply to this email directly, view it on GitHub https://github.com/vanackej/risco-mqtt-local/issues/57#issuecomment-1657083656, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2J4V6GLHOFPW72FYMWJKLXSYOXZANCNFSM6AAAAAAVJJL6F4. You are receiving this because you were mentioned.

[pergolafabio]

ok, tried new version , deleted amm mqtt devices, on first start, seems now all states are correct, no unavaible anymore, not even for the motion detectors, looking better... , also no cloud connector sensor anymore, like you told

But, 1) my panel was disarmed, i cant change the state to armed away or armed home, when i click on that pane, it just doesnt do anything 2) do you want me to test also the UTP interrupt with this new version ?

[pergolafabio]

with original addon, i see this in log when changing states:

7/30/2023, 3:10:01 PM [info] homeassistant/status was subscribed
7/30/2023, 3:10:08 PM [info] [MQTT => Panel] Received change state command ARM_HOME on topic riscopanel/risco_alarm/partition/1/set in partition 1
7/30/2023, 3:10:08 PM [info] [MQTT => Panel] ARM_HOME command sent on partition 1
7/30/2023, 3:10:09 PM [info] [Panel => MQTT] Published alarm status armed_home on partition 1
7/30/2023, 3:10:12 PM [info] [MQTT => Panel] Received change state command DISARM on topic riscopanel/risco_alarm/partition/1/set in partition 1
7/30/2023, 3:10:12 PM [info] [MQTT => Panel] DISARM command sent on partition 1
7/30/2023, 3:10:13 PM [info] [Panel => MQTT] Published alarm status disarmed on partition 1

On yours addon, i dont see those logs, it just doesnt do anything?

[pergolafabio]

Also tried the UTP interrupt, but still doesnt reconnect, below full log

Maybe i need to increase this value?

"cloudConnectionDelay": 10000,

I know it takes a while before my panbel actually tries to connect, i have the older board, single socket

you can see here it took 11 secs

7/30/2023, 3:26:39 PM [info] Panel is not connected, waiting
7/30/2023, 3:26:50 PM [info] Incoming connection from panel received

and here 1 min and 12 sec

7/30/2023, 3:36:46 PM [info] Panel is not connected, waiting
7/30/2023, 3:37:58 PM [info] Incoming connection from panel received

risco.log

[pergolafabio]

while testing, also see this:

7/30/2023, 3:38:29 PM [info] Automatic reconnection will be attempted in 10000 ms
7/30/2023, 3:38:29 PM [warn] sendCommand(ZLBL*1:8?): Socket is destroyed, ignoring command
7/30/2023, 3:38: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)

[pergolafabio]

for test, i changed it to a high value, 120 sec, "cloudConnectionDelay": 120000,

But that didnt help either:

risco.log

Only restarting the addon brings the connection back

[markxroberts]

Thanks for testing.  I have an idea that the additional code for the states has caused the timeout (it also has a delay).I’ll need full debug logs to work out the arming question.  I’ve changed the topic structure for this in MQTT which I suspect is the cause.I’ll not get to it for a few days.Mark RobertsOn 30 Jul 2023, at 14:50, Pergola Fabio @.***> wrote: for test, i changed it to a high value, 120 sec, "cloudConnectionDelay": 120000, But that didnt help either: risco.log Only restarting the addon brings the connection back

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[pergolafabio]

No problem, take your time, let me know if I need todo something