I use the “SSL countdown timer” suggested by Danny at Smart Home Pursuits. This fetches a timestamp for when the SSL certificate runs out and puts it into a sensor. A template sensor is then used to calculate a countdown in days till the SSL certificate runs out. I have found this to be a great help and it displays nicely in a gauge.
However, from Jan 2022 though, the strptime and as_timestamp methods both require a default value to be added! Zero (0) is a suitable value though changing the logic a bit to detect use of the default is a further step to avoid getting silly large values displayed when the defaults get used. I have not done this…
A more serious issue is that the behaviour of the date/time manipulation function strptime() has changed as well.
In the past a partial format pattern could be used to match from the start of the provided time string, hence
YYYY-MM-DD or similar was OK. Now, a few tests using the Developer Tools for templates in Jan 2022 show that the
strptime() format pattern string has to match every character in the provided time string.
So you could change the format from
%Y-%m-%d to something like
%Y-%m-%dT%H:%M:%S+00:00 which works for me in UTC time. You cannot use
%z to match the time zone
+00:00 as it does’nt match the
: given in e.g. my current timeout of:
2022-04-24T09:47:54+00:00. Yet again, you could do some string manipulation on the provided time before use. This is indeed the solution giving :
strptime(states(("sensor.shp_cert_issued.state")[:-15]), "%Y-%m-%d", 0)
Note: The change to function “states”, extra speech marks round argument + brackets to force evaluation of the function result compared to the Smart Home Pursuits website referenced above. Its last 15 characters chopped off the time value (…[:-15]) before being fed into
strptime() that fixes the problem described here so it works now correctly again in my HA. You may need to adapt your code in other ways!
The question is: Was the change to always needing to exactly match the string & patterm/format arguments rather than just the start of the provided time string deliberate? I think it might break quite a few people’s code even once they have added the now required default values.