As a conclusion (just to confirm) - do you mean that we should never use “Dev tools → Set state” since it does not cause a REAL change of the state object?
Here it is properly stated that changing a value by “Set state” will not cause a change of a physical object (like I cannot make the Sun rise again). But it is not mentioned there that “Set state”-changes may not affect state object at all in some cases.
It is not about finding a bug or a liar here - it is about a clear Docs & understanding.
this is the best way I can show you
take the following class
class Foo():
def __init__(self):
self._x = 4
@cached_property
def x(self):
return self._x
x is a property that feeds from _x.
Now, instantiate it
a = Foo()
Now, change the x property to 3
a.x = 3
Now print out a.x
print(a.x)
>>> 3
now print out the internal values of the a class
a.__dict__
>>> {'_x': 4, 'x': 3}
Notice how a._x is unaltered, yet accessing a.x is giving you 3?
Thanks for a clear example. But this does not make a picture clearer for me.
Consider this:
template;
- sensor:
- name: testing_unknown_4
state: 123
- name: testing_unknown_5
state: >-
{{ states('sensor.testing_unknown_4')|float(default=0) * 2 }}
You can set a value to “testing_unknown_4” = “100”.
And then I see that “testing_unknown_5” = 200.
As expected (for me).
NEVER ever in my childish experience from September 2020 seen a case when a “testing_unknown_5” is NOT changed accordingly to “testing_unknown_4” - whether the “testing_unknown_4” was set “automatically” or manually (via “Set state”). Until today with that bloody sensor.
HA contains template sensors. Assume that all of them are derived from some “testing_unknown_4” - which was changed manually. So, what is this “states(‘sensor.testing_unknown_4’)” - does it use REAL values or exposed “proxies”?
I think I localized the issue.
Code:
input_number:
testing_round_1:
initial: 9940
min: 9000
max: 9999
step: 1
mode: box
template:
- sensor:
- name: testing_round_2
state: >-
{{ (states('input_number.testing_round_1')|float(default=0) / 10000 * 100) }}
- name: testing_round_3
state: >-
{{ (states('input_number.testing_round_1')|float(default=0) / 10000 * 100) | round(1) }}
Test card:
type: entities
entities:
- entity: input_number.testing_round_1
secondary_info: last-changed
- entity: sensor.testing_round_2
secondary_info: last-changed
- entity: sensor.testing_round_3
secondary_info: last-changed
Both sensors are similar - but the 2nd sensor has a “round(1)” function.
How to reproduce:
-
Open a card and start changing the “input_number” up/down.
-
Check that both sensors are properly evaluated.
-
Go to Dev tools-> Set state. Set value “abc” to “sensor.testing_round_2”:
-
Check this change on the card:
-
Change the “input_number” by “1”. Then the “sensor.testing_round_2” will be evaluated:
-
Go to Dev tools-> Set state. Set value “abc” to “sensor.testing_round_3”:
-
Check this change on the card:
-
Change the “input_number” by “1”. Then the “sensor.testing_round_2” will be evaluated, the “sensor.testing_round_3” will NOT:
-
Keep changing the “input_number”. At some point the “sensor.testing_round_3” will be evaluated as well:
A possible explanation:
Internally the “sensor.testing_round_3” was still “99.5”.
Although it was shown as “abc” on a card, although “{{states(“sensor.testing_round_3”)}}” returned “abc” in Dev tools → Template.
While the “input_number” was changing, the internal value of “sensor.testing_round_3” was still “99.5” after “round(1)”.
Only when the “input_number” became 9955, the internal value became “99.6”.
This caused an update of “presentation” - the card started showing “99.6” (and Dev tools → Template which I omitted here started showing same “99.6” as well).
So, here is what Petro said - the “states(‘sensor.testing_round_3’)” is a “cached state”, i.e. not the actual one.