What is the point of a device list that hides devices?
I updated Dwains theme and I’m not using Lovelace Gen. but still have the same error message.
what would be the reason?
now this is an advanced one, and seeing this as of late (though not 100% positive it is since 2021.4…)
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:95
First occurred: 10:09:04 AM (1 occurrences)
Last logged: 10:09:04 AM
Error doing job: protocol.resume_writing() failed
Traceback (most recent call last):
File "/usr/local/lib/python3.8/asyncio/transports.py", line 294, in _maybe_resume_protocol
self._protocol.resume_writing()
File "/usr/local/lib/python3.8/asyncio/sslproto.py", line 517, in resume_writing
self._app_protocol.resume_writing()
File "/usr/local/lib/python3.8/site-packages/aiohttp/base_protocol.py", line 31, in resume_writing
assert self._paused
AssertionError
there is nothing really I can relate to this, nor in the logs close to it.
Would anyone have a clue what this could be?
would this be expected too:
I cant correlate the blank phase in the chart to a restart I did, or anything else really, the rest of my sensors show fine. Including the sensor this template is based on:
But most importantly, the state of the sensor didnt survive any of this apparently, while the graph does show the current value…
template:
- trigger:
- platform: time
at: '00:00:00'
sensor:
- name: Netwerk library usage daystart
state: >
{{states('sensor.netwerk_library_totaal')|float}}
unit_of_measurement: kWh
I’ve added all of these sensors to the recorder. Why would this gap exist, and how come the state is ‘Unknown’? This same behavior is shown on all of these trigger based template sensors.
update
no, its positive, these sensors dont survive a restart. which currently makes them useless for my goal here, recording daily power consumption/usage in a sensor.
before restart:
after:
Hi all,
Got the following error when updating to 2021.4.4:
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
home-assistant-frontend==20210407.3 from https://files.pythonhosted.org/packages/1e/29/13a7ee41fdc63f2ad07fc0c7c664ffd8c8e4319764d33d95bf7727bc25b9/home-assistant-frontend-20210407.3.tar.gz#sha256=b9c7b04b5f7791bbe593843ee481184fab1f27f1f4d3abb2d22222f141ceccfa (from -c /srv/homeassistant/lib/python3.8/site-packages/homeassistant/package_constraints.txt (line 19)):
Expected sha256 b9c7b04b5f7791bbe593843ee481184fab1f27f1f4d3abb2d22222f141ceccfa
Got ca3ef965059f3874a208848f38a48191ad113550966f8871e5a74bc0b6f6e2fa
Cause for immediate panic?
Yeah it’s an event stream. It won’t survive a restart, no sensors do. This is nothing new. Add a homeassistant startup trigger.
see my template sensors.
No I don’t want the startup trigger, I need them to record the value at midnight, and only then.
That’s why I had a whole setup with intermediary input_numbers to record those values, and create the template sensors based on these numbers (via a python script)
My hope was that these new trigger based template sensors would only update on the trigger, but would keep their value crossing restarts.
Nothing has ever done that in home assistant outside helpers.
with helper you mean eg an input_number? Which would mean that I would have to go back to
automation:
- alias: Set daystart sensors
trigger:
platform: time
at: '00:00:01'
action:
- service: python_script.daystart
which python script in fact does:
- service: input_number.set_value
data:
entity_id: input_number.afzuigkap_zolder_usage_daystart
value: >
{{states('sensor.afzuigkap_zolder_totaal')}}
and the template sensors
afzuigkap_zolder_usage_daystart:
friendly_name: Afzuigkap zolder usage daystart
value_template: >
{{states('input_number.afzuigkap_zolder_usage_daystart')|float}}
unit_of_measurement: kWh
are then only updated at the timed trigger, and keep their value because the input_number hasn’t changed?
I made this python script to not have to do the above for all sensors manually, though it still forces to create all intermediary input_numbers (which I would have liked to prevent with these new trigger based sensors…)
#################################################################################
# Record daystart values for power and usage. To survive restarts, this is done
# with intermediary input_numbers, and an automation calling this Python script
# at midnight
#
# automation:
#
# - alias: Set daystart sensors
# trigger:
# platform: time
# at: '00:00:01'
# action:
# - service: python_script.record_daystart
#################################################################################
switches = 'group.z_wave_switches'
for entity_id in hass.states.get(switches).attributes['entity_id']:
sensor = hass.states.get(entity_id).object_id
input_idPower = 'input_number.{}_power_daystart'.format(sensor);
sensor_idPower = 'sensor.{}_actueel'.format(sensor);
input_idUsage = 'input_number.{}_usage_daystart'.format(sensor);
sensor_idUsage = 'sensor.{}_totaal'.format(sensor);
#################################################################################
# Select Input_number and set value to the corresponding sensor
#################################################################################
# get sensor value
sensor_valuePower = hass.states.get(sensor_idPower).state
sensor_valueUsage = hass.states.get(sensor_idUsage).state
#
# and assign to input_number
hass.services.call(
'input_number',
'set_value',
{'entity_id': input_idPower,
'value': sensor_valuePower}
)
hass.services.call(
'input_number',
'set_value',
{'entity_id': input_idUsage,
'value': sensor_valueUsage}
)
edited.
I’m getting this error on start up:
Logger: homeassistant.components.statistics.sensor
Source: components/statistics/sensor.py:159
Integration: statistics (documentation, issues)
First occurred: 19:42:36 (1 occurrences)
Last logged: 19:42:36
sensor.today_temp_bom: parsing error, expected number and received None
From this sensor:
- platform: statistics
name: today_temp_bom
sampling_size: 150
entity_id: sensor.hobart_temp
max_age:
hours: 24
today_temp_bom
comes from the BoM integration and is restored on start up. So something screwy is happening on start-up.
seems like a bug in statistics, just looked at the code and it appears as if None is causing the problem and there’s no check for it.
Thanks Petro. Should I open a Core Issue?
Go back to whatever you had before if the new template integration isn’t working. It’ll be getting updates but it won’t get ‘restore state’ until thats implemented everywhere. And I don’t think that’s even being thought about.
Yah, and tag the statistics integration. This try catch’s net is too large
def _add_state_to_queue(self, new_state):
"""Add the state to the queue."""
if new_state.state in [STATE_UNKNOWN, STATE_UNAVAILABLE]:
return
try:
if self.is_binary:
self.states.append(new_state.state)
else:
self.states.append(float(new_state.state))
self.ages.append(new_state.last_updated)
except ValueError:
_LOGGER.error(
"%s: parsing error, expected number and received %s",
self.entity_id,
new_state.state,
)
I assume you just don’t want another integration Tom but the custom average component is much better for that sensor (as you can get the true average for the current day from midnight instead of a 24hr period - also the min temp for the last 24 hrs isn’t necessarily going to be the same as the low temp since midnight etc)
I want the min and max for the templates though.
EDIT: I see it has those attributes. Will try it. Thanks.
thats what I want with the min_max platform, based on templates sensors, but they always error on startup also… min_max doesn't wait for template entities to be ready · Issue #41931 · home-assistant/core · GitHub
@DavidFW1960 don’t you see startup errors in the logs when doing that?
Yeah that works. Thanks.
Have you set availability_template
in your templates?
Defines a template to get the
available
state of the component. If the template returnstrue
, the device isavailable
. If the template returns any other value, the device will beunavailable
. Ifavailability_template
is not configured, the component will always beavailable
.
That’s scary- coming from a moderator, no less. Are you really saying that snapshots “rarely work”?