How to combine recorder feature and setting initial value of input_xxx to get a predictable initial state?

Configuration
1

There were several times when I wanted to have say, input_number with a range from 0 to 100 and initial value of 50.
If I put initial: 50 in that entity’s config, it will be 50 on every HA restart.
If I don’t use initial, it will be either the last recorded state or min value (if the entity is new)
And there is possibility that if something goes wrong with the recorder/HA restart, I’ll end up with something different to 50 as a state of my entity (min value?) if I understand HA docs correctly.

The thing is I want to benefit from the recorder’s capability of storing values so one should not tweak everything after every HA restart, but I also don’t want to have the minimum value as initial/default state.
It seems like a lack of extra config variable, or I’m over-complicating things and there is a nicer approach? :wink:

2

guess you need to take a decision, either you use the stored value or you set one up.
How would you even device when to override the stored value?

3

Well, I think that’s the problem in the approach some HA developers have to the initial_state, been there at least once.

There are 2 different aspects of an entity: initial state of an entity and ability to restore it after restart. Do you agree?
And I’m currently demonstrating that it’s just impossible to configure these 2 different sides with only one binary setting.

If we keep initial_state as a value that one wants to see by when an entity is created/intact, and use something named say, default to fall back if HA cannot restore the last recorded state of that entity, I presume it will do the job.

4

may sound silly but why would HA not be able to restore a state?

If you really want to set such a safety, then I would recommend creating a template sensor that would like like this:
{% if states("sensor.sensor_name") == "unknown" %}50{% else %}{{states("sensor.sensor_name")}}{% endif %}

5

I think I saw it several times - database corruption or some HA tantrum, don’t know. And it’s especially highlighted in the documentation, so it’s very well possible.

I think your template_sensor approach wouldn’t work because of == "unknown" bit as HA will most likely initialise that input_number with min value. Please read carefully my initial post, it’s not about sensors.

6

Good morning everyone !

Perhaps this might interest you to answer the question

Any help, advice or support is welcome !
Thanks!

7

Good morning everyone,
I wanted to inform you that in these two weeks I have completely rethought and redone the code of my repository, which allows the activation of a switch according to your habits.

Still the project is under development and if you want to help me in some way, I would be really happy!

Some news:

  • Compatible with influxDB !
  • If influxDB is not available, use the HASS history
  • All objects are managed by Pandas frames
  • The day of the week, the season, the quarter, the beginning and the end of the month are taken into account.
  • Situations are generated through an internal patternMarching and are integrated in a heuristic way.
  • much more!

What’s next:

  • Approach with a MachineLearning (perhaps scikitLearn) for data model creation, learning, and prediction.
  • Identification of new events in live
  • Probability and event management
  • much more!

If you have practice with Pyton and want to help, I would be very happy!
Otherwise, if you want, you can buy me a beer :slight_smile:

Thanks!