I have a command line sensor using ‘curl’, the refresh is at 3600 (1 hour)
The webservice behind curl went down last night and was restored during the day.
However, although the refresh is set to 1 hour, I only restored this by using devtools > command line entities. … I was expecting the hourly refresh to re-start when the service was restored, wrong idea/expectation?
Did you end up solving this problem? I am having the same issue where the polling doesn’t recover after a connection failure without manual action.
Sorry but no, I had a number of elec.net issues about 2 months ago and this is one of them. I also discovered some HACS apps did not reconnect too … and the ‘core’ netatmo integration but these are other things. I sort of forgot about above but will open a ticket …which means I need to create a use-case by shutting down network for my HA machine…probably this weekend
In my case, I have to do a full HA reset to recover the command line binary sensors from the “unknown” state after a no response failure. I should look into curl parameters that might address this problem.
Interesting idea, I am not the specialist but I would not know wwhy curl params would change the behavior to (re)connect…what are you thinking of? That the process is hanging and maybe a timeout setting to restart?
OK, I think I’ve solved the problem. I spent a couple hours fiddling the other night.
I am using a curl | grep command using the grep regex to return the value from curl response.
curl xxxxx | grep -Po '"vDarkSensor":\K[0-9]'
When the service goes down the curl responds with a null file after a timeout. Then the grep fails and returns a blank to stdout BUT also returns a 1 (error) as the return code because it didn’t match any text. This is what HA is picking up which seems to kill the command line sensor.
Basically I played around until I could get rid of the 1 return code. I did this by piping the output of the grep to cat which will simply echo nothing with a return code of 0 (success).
curl xxxxx | grep -Po '"vDarkSensor":\K[0-9]' | cat
For me it turned out to be that simple. Now if the service goes down, the sensor changes to state:unknown, but recovers when the service comes back.
That should be default behaviour imo and not related to how the curl is written. In my case the network went down and I would expect that HA refreshes sensors when this returns…in your case the same, HA should recover from timeout …e.g. a less frequent ‘repair’ event could take place …
1 Like
I agree, I would like to see it behave that way, but I also see what the developers have done. They are choosing to interpret the stderr channel as distinct form the command line response (stdout) and they are choosing to log an error when stderr is not 0 and treating it as an unrecoverable error.
In practicality, that doesn’t seem the most reasonable action when we’re looking at the way we’re using command lines here.
It would also help if that behaviour was called out in the documentation.