value_template: >
{% set dateraw_match = value | regex_findall('1\\-0\\:1\\.6\\.0\\(([0-9]{12})') %}
{% if dateraw_match %}
{{ as_timestamp(strptime(dateraw_match[0], '%y%m%d%H%M%S')) | timestamp_local }}
{% else %}
{{ "unavailable" }}
{% endif %}
to read this data:
1-0:1.6.0(241204154500W)(05.473*kW)
from a Youless sensor RAW data page (W peak usage timestamp) with the REST integration.
When templating other data, like the actual W usage or W peak, I fallback to “{% else %} 0 …”
But what is the correct fallback for a timestamp? {{“unavailable”}} generates errors in the log.
I guess it depends on what you want to achieve. Unavailable is a valid state as obviously your sensor does not deliver a valid input.
In templates you for example could just reuse the last state, but I guess this won’t do in value_template and would still make no sense in your case with the youless:
I don’t have such device. Can you show some examples the REST interface returns for the people to see the different cases?
Do I understand correctly that this timestamp can be of any time in the past when the device had it’s highest W peak?
Without further insight: Would it be possible to just save the tag as json_attributes? Then you can create a triggered template sensor which only updates when the highest W peak (timestamp) value is valid and has changed.
So I’m using the REST sensor to retrieve data from that local URL hxxp://192.168.1.34/V?p=1
You are correct that 1-0:1.6.0 shows the watt peak usage date/time (in the past for the current month) and the actual peak usage in W.
I guess that sometimes the page returns blank due to some network error and in that case I would like to turn the sensor unavailable or unknown, but that doesn’t seem to be possible for a timestamp as the log shows “sensor.piekvermogen_tijd rendered invalid timestamp: unavailable”.
I’ve tried {{ None }}, {{ Unavailable }}, {{ Null }}, but the error keeps returning.
PLEASE understand that this is just a stupid error log and I can ignore it, but it’s my OCD kicking in and I’m trying to handle it correctly
For other templates (eg. the actual W peak usage) I can just use “0” ase “else” without showing errors.
Yes, but returning “Unavailable” caused errors in the log as it was not a valid timestamp value. I believe with the availability set, it correctly enters the unavailable state and won’t attempt to render the value.
If you make the else value {{ none }} (null) the state of the sensor will be unknown instead of unavailable, and the log will not complain about it. This is probably more accurate and more desirable that having a state of unavailable and you don’t need the availability parameter.
{% set dateraw_match = value | regex_findall('1\\-0\\:1\\.6\\.0\\(([0-9]{12})') %}
{% if dateraw_match %}
{{ as_timestamp(strptime(dateraw_match[0], '%y%m%d%H%M%S')) | timestamp_local }}
{% else %}
{{ none }}
{% endif %}
Rule #1: all states are strings. So you must not think of none being 0. It’s just the defined state whatever happened behind the scene.
unavailable in case of an error or as @w35l3y says if it does not have deterministic state. E.g. you don’t know if a binary sensor is true or false (on or off) although everything seemes fine with the setup and sensor.
unknown in case the sensor was not reached or setup yet. E.g. after booting homeassistant when the state was not set yet it’s often unknown
none could mean unknown or some other (hopefully) specified state of a sensor
So all the availability and template availability checks are to determine the deterministic state while just setting the state to unknown you flag it as “Right now I don’t know pal”
) this seems to be the reasoning what to choose: