Where do I find this?
Never mind, found it in the release notes.
1 Like
Ive just finished a more extensive test, and it definitely isnt about the input_number. As a matter of fact, if these templates fail, or Hue is having a hiccup, I often see the value of the input_number only…
this is what I tested just now, and they all show the behavior I describe above, in which the |default doesnt help
test:
friendly_name: Test
value_template: >
{{states('sensor.auditorium_sensor_temperature')}}
test_default:
friendly_name: Test default
value_template: >
{{states('sensor.auditorium_sensor_temperature')|default}}
test_default_value:
friendly_name: Test default value
value_template: >
{{states('sensor.auditorium_sensor_temperature')|default(15)}}
test_plus:
friendly_name: Test plus
value_template: >
{{(states('sensor.auditorium_sensor_temperature')|float +
states('input_number.temp_calibration')|float)|round(2)}}
test_default_plus:
friendly_name: Test default plus
value_template: >
{{((states('sensor.auditorium_sensor_temperature')|default)|float +
states('input_number.temp_calibration')|float)|round(2)}}
test_default_value_plus:
friendly_name: Test default value plus
value_template: >
{{((states('sensor.auditorium_sensor_temperature')|default(15))|float +
states('input_number.temp_calibration')|float)|round(2)}}
Each time with availability_template defined? like:
availability_template: >-
{% set id = states('sensor.auditorium_sensor_temperature') %}
{% set un = ['unknown','unavailable'] %}
{{id not in un and id is not none}}
no, in this case not, because I had previously tested that, and it didnt solve the issue. I can confirm the core sensor sensor.auditorium_sensor_temperature to exist at that time. So it is definitely a template sensor thing, not a Hue thing…
I don’t know if either of the following two suggestions will fix the problem but they won’t take long to test:
-
Try
default(15, true)instead ofdefault(15). -
If the first suggestion fails then try something like this:
{% set x = states('sensor.auditorium_sensor_temperature') %}
{{ x if x != none else 15 }}
1 Like
thanks Taras, unfortunately none of your suggestions help. Ive also tried ‘not is none’ as I have all over in the conditions, and
{% set x = states('sensor.auditorium_sensor_temperature') %}
{% set un = ['unknown','unavailable'] %}
{{ x if x not in un else 15 }}
alas…
Oh well. Now we know this is a really tricky one to solve.
FWIW, I recently wanted to get the value of a timer attribute (finishes_at) that only exists when the timer is running. That means this returns none when the timer is not running (finished or paused):
{% set f = state_attr('timer.your_timer', 'finishes_at') %}
I tried adding a default filter but it didn’t work (probably because none doesn’t satisfy default’s idea of what it considers is undefined). So I made the template check for f != none before it proceeds. I thought some of that might work for the issue you encountered but apparently not.
Obviously most bugged features work - this is the way how we can say it works improper way. In common communication we say: it doesn’t work if something doesn’t work correctly/as expected. no need to correct it.
The fact that snapshot feature stores database files in improper way (because don’t ensure their consistency) is a bug. In any production environment such behavior would be considered as not acceptable thus “doesn’t work”.
For manual snaphots, the workaround could be: stop HA, wait a while, make snaphot. I suppose such snapshot is consistent.
Unfortunately, in case of automated snaphosts we cannot affect that. Those are done by supervisor which copy files not ensuring their consistence from database pov. I don’t know if this fact and potential fix is on the core devs roadmap.
It’s not stored in an ‘improper way’. If you make a back up of a configuration when a database is being written to and it’s partially written, you get a backup of a non-complete file. There in lies the problem.
This is why it’s backed up (ok, in fact it’s read operation in order to create file copies) in improper way.
Application which backs up database by copying their files should make sure those files are consistent from DB pov (ie all write operations are finished, incl ensured consistency etc).
The problem is that every database provides different ways how to make possible to create such file copies in safe way.
I think there is more to this. I use the google drive add on and it set it to stop the DB prior to the snapshot. I still have seen the snapshot restore DB corrupted. Should not have happened.
Are you sure this addon stops the database? AFAIK it calls Supervisor method to create backup - it is how it’s described by an author of this addon.
well, indeed. tricky. and have no more up my sleeves I fear. Tried all ways of preventing a none known to me, or found in the community/docs. Maybe this is a more fundamental ‘template’ thing. Since it isnt new (my issue is from a few iterations back) I won’t letter here anymore on the subject.
Your help is much appreciated though! Please don’t stop doing that 
thanks Petro, and I did for now.
I did ask you in another spot whether the integration you wrote has been released yet allowing to calibrate entities, and it must be snown under… What is the status of that component? Could I maybe use it to calibrate my core Hue temp sensors too?
btw, as I saw in your config, you did include the template: in a dedicated file, while my packages file wasnt accepted. I believed you told me I had to add these to configuration.yaml directly? How come the include (as opposed too the mentioned top-level only in the docs) does work?
Or does ‘top-level’ mean ‘in the same folder as configuration.yaml’ ? I believed it to indicate the level under homeassistant: …
The google drive backup addon has an option to stop addons prior to backing them up. It doesn’t necessarily do that but it does have an option to do so. Sounds like Bill is using that option.
@KennethLavrsen Yes, the codemirror component versions were bumped up (as they include a list of fixes), but unfortunately according to Bram did not solve the reported issue. We need a minimal reproducible example for the upstream codemirror library. The issue was raised there a few weeks ago already, but they could not reproduce it in vanilla (confirmed also by you and others via their demo page).
So simply assigning someone in the raised issue, will not have an effect. We need leads in the code or something reproducible for the codemirror maintainers. Help very much welcome!
I realize you traditionally used input_numbers to store the values (at midnight) because it’s a Helper and its value is stored/restored. Of course, the input_number isn’t a sensor so its appearance in the UI may not be ideal.
What I have done is to use an automation to publish the value (as a retained message) to an MQTT Sensor. Your automation would do this at midnight. The value is stored on the broker. If Home Assistant is restarted, or MQTT entities are reloaded, the MQTT Sensor will instantly acquire the retained value from the broker. It’s an MQTT Sensor so its appearance in the UI is like any other sensor (and can be graphed).
1 Like
This looks like a great release. Lots of good stuff. Thanks for that. I had to downgrade though as tplink devices are now hanging the startup process till a 500 second timeout where it used to load before and other integrations wait for the tplink delay.
I just looked into configuration option of Google Drive Backup (from HA adonns store) and I cannot see such options.
I verified github documentation incl configuration file. There option ti exculde addons in order to create partial backup. But to do achieve what we are after, it should shut down HA, especially in case of sqllite which cannot be shut down as other databases)
Maybe we are talking about different addons? Or it’s hidden/not obvious feature
Its in the settings. There’s a checkbox for stop addons… At least in the 'Home Assistant Google Drive Backup" addon.