Status does not go from Arming... to Armed. SSAPI timeout errors. #189
Comments
lmcquade
added
bug
|
Hi @lmcquade , as you said the logs suggest you’re not able to connect to SS servers. Yes, if you can’t connect successfully then changing the alarm state etc won’t work. The log output after first startup of homebridge might be helpful too. Have you verified if you can use the SS app/website when the plug-in is unable to connect? |
|
Hi @shamoon, thank you for looking at this! I am able to connect to the SS website from my computer, the SS app on my phone, and from homebridge. Setting the alarm state works, it just doesn't update the status correctly. Here relevant log output from the startup of homebridge: |
|
Yes I meant that the socket connection is what listens for events to actually update HomeKit that an event happened (e.g. arming alarm etc). Its definitely weird, and not something I can reproduce ATM and haven't quite seen this before. Was it previously working and then stopped or have you never gotten past this point? Also since the SS API has been known to temporarily block IPs (though the plugin has logic to try and detect this) have you tried turning it off for a few hours or even a full day? |
|
It feels like it has been this way for a couple months, but since it arms and disarms correctly I didn't dig into it until now. I'll try disabling the plugin for a while to see if it helps. |
|
Still get SSAPI timeouts after leaving it disabled for several hours. It looks like only the |
|
Yea was a bit of a shot in the dark. It’s definitely odd that you can authenticate and reach the API in other ways. Anything about your network that could explain? Looks like it’s just timing out after 20s. Have you tried on a different machine? Checked your firewall? Again just kinda troubleshooting as I don’t see an obvious explanation. |
|
The connections I see going to I don't think it is a firewall issue. Both kinds of messages are sent to |
|
|
|
Just going on the fact that this works fine for every other user of the plugin makes me think its an issue with your machine / network which is why I was asking about whether you've tried another host and / or outside your network? Only other thing that might make sense would be an issue with the socket-io client but I haven't found anything obvious looking around. So Im left with recommending process-of-elimination... 🤷🏽♂️ |
|
I agree, it is strange. I tend to think it is something strange with socket.io on my machine. I'll keep looking in my spare time. I don't know that I am the only one with this issue. Sounds identical to #166. |
|
That issue could be the same but really no idea. Agreed I’d poke around with socket.io, maybe try different version(s) but again, my first thing would be to try a different machine and then a machine outside my network. Please do report back if you figure anything out, sorry I can’t really help more without being able to reproduce/an obvious way to investigate more |
|
It starts working if I roll back to |
|
Going from |
|
Very interesting, appreciate all the work. Thing is, Im not sure what to do with this. Its still quite odd to me others aren't seeing this (at least not in huge numbers). Im a little hesitant to downgrade the package. The other odd thing is this works fine on my Mac (my main testing machine in fact). |
|
I agree it is odd, and downgrading doesn't seem like a great option. I am on MacOS Catalina 10.15.7, if that makes a difference. Also, other modules on my system, like |
|
Yea Im on Big Sur. Still very odd. Wish I could reproduce on my end so I could dig in further, thanks for sharing and all the investigating. |
|
Finally got VSCode setup to debug into node.js stuff, and was able to track down the issue. PR #191 The issue appears to be that socket.io sets pfx to null if it is undefined. Unfortunately, as of node v15.3.0, the https code explicitly checks against pfx === undefined. It fails because null is not a valid pfx. Until socket.io is fixed, the workaround is to set pass in pfx as []. More info about this issue here: nodejs/node#36292 |
Describe The Bug:
After arming the system (using scene from home app) the status gets stuck as "Arming...". In the debug logs, I see repeated SSAPI reconnect attempts and timeouts from when homebridge starts.
To Reproduce:
Restart homebridge and homebridge-simplisafe3 in debug mode, watch log for SSAPI timeouts.
Expected behavior:
Status updates correctly. No SSAPI timeouts in log.
Environment:
Homebridge Config:
{ "name": "Home Alarm", "auth": { "username": "****", "password": "****" }, "cameras": false, "debug": true, "sensorRefresh": 15, "persistAccessories": true, "resetSimpliSafeId": false, "cameraOptions": { "enableHwaccelRpi": false }, "platform": "homebridge-simplisafe3.SimpliSafe 3" },Screenshots:
not applicable
Logs:
The text was updated successfully, but these errors were encountered: