Bug: On resuming from sleep, sessionState sensor reports "Locked" indefinitely, even though PC is unlocked.
Describe the bug I use this program to report my PC's state to Home Assistant via the sessionState sensor. 90% of the time it works correctly, though sometimes after resuming from sleep it will be stuck reporting "Locked" when the device is actually unlocked and in use.
One faulty sequence looks like this:
6:26pm - PC transitions from Unlocked to locked. Sensor updates. 6:32pm - PC goes to sleep. Sensor becomes "unavailable", as expected 6:35pm - PC is worken up from sleep and unlocked. Sensor updates from unavailable to locked. 7pm - PC has been in use for the last half hour, but sensor still saying locked.
I have a VPN running on the PC, so when resuming from sleep it has to reestablish a VPN connection, so the connectivity is a little unstable for the first 30 seconds after boot. But after that it should be able to report unlocked back to Home assistant.
Misc info (please complete the following information):
- Windows build (ideally screenshot/info of
winver.exeoutput): Version 21H1 OS Build 19043.1706 - Windows' UI language: English
- HASS.Agent version: 2022.11.4
Please check what's applicable (multiple answers possible):
- [x] Installed via installer
- [ ] Installed manually
- [x] Problem occurs in HASS.Agent
- [ ] Problem occurs in Satellite Service
Logs Attached debug logs of the half hour in question that I detailed above.
[2022-05-31] HASS.Agent_20220531 - debug.log
Thank you!
Hi @karwosts,
Thank you for the detailed bug report :) Could you please confirm that when the fault occurs, HASS.Agent has the right value - you can do so by opening the 'local sensors' window and checking the 'last known value' column:

If it is (and I'm guessing/hoping it is), it's because the system that keeps HASS.Agent from sending the same values fails due to the temp. lack of connection. I'm developing a better system that continuously compares HA's values with that of the agent (hassagent-5), when that's done, this issue will be fixed as well.
The Error checking for updates: API rate limit exceeded error in your logs is new to me, and very interesting, guess I'll have to consider not using GitHubs API anymore.
It does have the correct value locally. Sensors Config shows "Unlocked", while MQTT Explorer and HASS shows "Locked" state.
Thanks, that is (relatively) good news - means the sensor works. Hang tight for the fix :)
Just an idea, but would it make sense to just resend all sensor values anytime MQTT goes from disconnected to connected?
2022-05-31 18:35:34.809 -07:00 [WRN] [MQTT] Not connected, message dropped (won't report again for 5 minutes
2022-05-31 18:35:52.951 -07:00 [INF] [MQTT] Connected
Seems like if you just updated the sensor values here after MQTT connected that might have resolved the issue.
I think I read that you didn't want to send updates continually because that was spamming the MQTT broker, though I'm not sure if spamming HA with polling requests to check the current sensor status is really that much better. If polls are infrequent, then the sensor could have the wrong value for a few minutes after resume from sleep, which is not quite ideal
Thank you very much for the quick updates.
It actually already does that (otherwise it'd fail a whole lot more), but sometimes the package's lost even though it looks sent.
I already request sensor data on intervals for the quick actions, and that doesn't slow anything down. But it could have a somewhat smart algorithm, for instance: after a disconnect, increase the polling interval for 5 minutes.
I've merged all tickets related to this issue into a central pinned one: [#204]
Closing this one to keep it in one place.