Sensor instance not always available throws breaking error - how to ignore?
I have just started out with HASS.Agent. My use is only for providing sensors for the Windows server it is running on.
I have it up and running with the sensors showing up fine in HA.
The problem is when I want to watch Performance Counter sensors related to processes that are not always running. If I add them when the processes are running everthing works fine, for then. If at a later time the process is not running when I save sensors configuration or when I (re)start HASS.Agent, it throws an error - e.g. on start "Error loading sensors: Instance [process name] does not exist in the specified Category". If I edit sensors configuration and try to save the edits and the process is not running, I get a similar error and the configuration edits are not saved.
I imagine this is not an unusual situation, for example wanting to track processor load of a process that is only running at certain times. So I imagined there was a solution ready to find. I have tried setting IgnoreAvailability to true but it did not help, I suspect that this is not intended to do what I want here. Googling and looking at forums have not made me wiser, so here I am asking for help or if this is unsupported (and I should rather see if there is feature request for it or make one).
Thanks for any help.
21 Replies
Help us Help Others!
To help others find answers, you can mark your question as solved via
Right click solution message -> Apps -> ✅ Mark Solution
Help us Help You!
Please don't delete messages or posts because it makes it impossible to understand what happened. If you don't want your messages to be seen then don't post here.
We will help as soon as possible.
While you're waiting you can try the following:
- Checkout the documentation. - Search here in discord for previously solved similar issues.
@DrR0x
@Amadeo, haven't seen this yet, surprised though, seems like a common issue people would have? Is there an inbuilt solution?
xenogeneic-maroonOP•2mo ago
A specific example is here, I am tracking the Plex Transcoder process, which only starts up when transcoding is needed:
{
"Type": "PerformanceCounterSensor",
"Id": "0a24a76c-4600-4a65-92a3-ffe450544e5e",
"Name": "Plex Transcoder Processor Time",
"UpdateInterval": 30,
"Query": "",
"Scope": null,
"WindowName": "",
"Category": "Process",
"Counter": "% Processor Time",
"Instance": "Plex Transcoder",
"EntityName": "performancecounter_ProcessorTimePlexTranscoder",
"IgnoreAvailability": true,
"ApplyRounding": false,
"Round": null,
"AdvancedSettings": "{"DeviceClass":"","UnitOfMeasurement":"%","StateClass":""}"
},
Perhaps I made some error, or should set it up another way, but it works fine as long as the process is running.
The IgnoreAvailability was set to "false", but I tried to get things running again by editing it to "true" in the config file. Did not help though.
from a quick read of some code,
IgnoreAvailability is about the MQTT availability topic and not the sensor's target's availability
seems like maybe we want a Default you can configure that's reported when the program isn't running?Yeah, changes the way availability works inside of HA
I'd say that the behaviour is expected, WMI works on the data being provided from somewhere, if that data is not available is like trying to select an element from a list that is not there anymore
Now the question is what can we do about it
I can modify the sensor that in case of failure to initialize it returns always 0 but that doesn't solve the issue
As after a given program is launched (for example plex), hass.agent won't know about it and won't recreate the sensor that failed to initialize
So it'll still return 0
(Or won't publish anything, depending on how we change it)
xenogeneic-maroonOP•2mo ago
I see that I am off into feature request land here. And though I code I don't know anything of what is involved here.
Could it keep track of what sensors failed to initialize and retry them regularly?
it could, its a much more complicated implementation though, not necessarily because of the retrying loop, but because of the extra settings and parameters to go with it.
Just to be clear, I'll be more than happy to implement this 😄
The most difficult question is the logic yo follow, constantly trying to recreate the sensors is not a wise idea, doing so in intervals is a better one but then, what interval, 10 seconds, more?
This is the bit we need to think about. Winui forms sucks but we need at least a checkbox for whether or not to retry, and then possibly a number input for period?
I had a different idea for this: if they want an
UpdateInterval of 30 seconds, then every 30 seconds have the sensor run the WMI query and either return it (process is running and value is available) or some DefaultValue. the sensor is always sampling, rather than having its lifecycle tied to the lifecycle of the monitored program. does that make sense?
there wouldn't need to be a retrying checkbox or anything, because the sensor meaning would be "every 30 seconds, tell me how much CPU this process is using, if any"not a bad idea
we already kinda do it with the WMI service restart fix
talking about it
which version are you currently at?
I’m on the latest published beta, if you mean me
xenogeneic-maroonOP•2mo ago
If you mean me:
HASS.Agent windows app 2.1.0
Satellite service 2.1.0.0
HA integration 2.1.0-beta1 (not that it should matter, I guess)
integration technically needs an update, but that wont change anything in this case
try one of the 2.1.1 betas please https://github.com/hass-agent/HASS.Agent/releases/tag/2.1.1-beta3
GitHub
Release 2.1.1-beta3 · hass-agent/HASS.Agent
This time it's actually last of betas for 2.1.1 :D
Fixes:
Satellite Service exe path is now properly enclosed in double quotes according to good security practices (thanks to @yakidd for repor...
as it includes some changes in WMI handling
note: in your case it might generate quite some log file 😄
xenogeneic-maroonOP•2mo ago
Switching to latest beta now
HASS.Agent windows app 2.1.1-beta3
Satellite service 2.1.1.0
HA integration 2.1.1
Same issue as before, but I think that was expected
Interesting, there is already a check that should recreate is unless it fails right at the begining when hass.agent starts
I'll do some hands on testing and report back