Question: how long does it take to write a helper value und read it again?
Situation: in between some milliseconds to sensors are triggert.
One changes a helper state. The helper state is read by a script.
The other one is read directly by the script.
How much does the indirect way over the helper state falsify the time stamp of the original Sensor value change time stamp? What time ranges are we talking about? „Writing, then reading“-duration.
My main database is maria-db. Changed from SQLite. If that is the database that handles these very fast interactions. I am not sure…
Even then you could have a (tiny) delay if e.g. CPU load or memory pressure is high.
What is the actual problem you’re working on?
This is important to know, because there could be multiple (and better) ways of doing what you want. One example would be that if you have an automation or script that expects a new/next state, you can simply wait for it with a timeout.
usecase:
Motion Sensor with 10sek wait after „no motion“.
On every side of the door there is one sensor on the ceiling.
With the row of sensor „no motion anymore“s you know the direction of movement. (Into or out of the room)
All sensors are the same hue motion sensor hw.
This works very fine. (If there is no helper-entity inbetween)
There are more use cases:
Currently I control light with this information directly.
next should be a „presence“-entity for every room.
(Multiple) Reactions will then be triggered by „presence“.
Because of individual situations sometimes there is this „presence“ entity. Sometimes directly a sensor-input.
I want to understand the procedures to define the correct latencies - or general reworks to have a stable concept.
Hopefully that describes the usecase for a first insight
Can I assume the sensors (in HA) you have stays on for some seconds after being triggered? Will it also be safe to assumed it would be near impossible to trigger the two physical sensors at the same time?
Personally, I’d try to avoid a direct DB check and try to stick to HA features. That will be my angle with my suggestion. Btw, I haven’t seen a similar ask over the years, so this is interesting.
Let’s simplify this and just focus on one direction for the moment. Call the first sensor A and the other B. If A’s state can remain true for long enough so that it overlaps with moment B gets triggered, you’d simply make an automation that triggers on A and in its actions wait for B’s state to change. You would then know the direction was A → B. This is assuming B doesn’t get triggered for some other reason (e.g. two people approaching from each side).
Would you be interest in taking this idea further? I can say for sure it will work (or even work well), but it’s worth a try.
all assumptions are correct.
Current solution: because of the lack of knowledge how fast the recognition chain is, i implemented a buffer of 1 sek. - hopefully that covers every case.
So if sensor B is „no_motion“ when sensor A triggers „no_motion“ than the automation checks of the last change of Sensor B is less than 1 second ago. If it is, it still „counts“ als „motion“.
Disadvantage for sure: it is less accurate. There is the possibility that the interpretation is wrong, and somebody entered the room - and did not leave it.
To optimize that i need to know what tolerances I need. Therefore I need to know what time it needs to write values in a Maria db in RAM. Think that is lightning fast. Or better what time it takes, that they are acknowledged. I would estimate values like 100ms for that? But this is only experience from ioBroker.
When is the value_template updated? At trigger timestamp? Or every minute? Where can I see that?
The automation should say:
switch of the room light if the door sensor triggers „no_motion“. But check if there is a „motion“ in the next room. If not, do nothing.
Update: if in next room there is „no_motion“ AND „last_changed“<1 → that should also lead to „lights of in room“
The sensor state will be the value whenever it last updated. When used in a state trigger, it’s the update itself that causes it to trigger. In a condition, as in your case, there’s nothing that will force an update. It’s current value is simply evaluated at the time the condition is checked.
That said, the state engine is pretty fast, and I think the state engine would be more up to date than a DB, due to the flush interval to persist data (hence my reason for originally suggestion to avoid reading the DB for this kind of fast reaction requirement). Point is: HA uses “optimistic state” (experts, please shout if I have this wrong): When there’s a change, the state engine will update immediately, regardless of whether the change has persisted to the DB. That is as opposed to pessimistic state, where you’ll assume nothing, persist the data, read it back and that will be the new state. I’ve seen some MQTT things behave this way. Here is a specific issue related to all of this I saw recently.
Some state triggers are different though. A state trigger using a template with now() will e.g. be evaluated once a minute, and not every second.
Ok, thanks. That tells me: Every value writing & reading runs in the state engine. Meaning in RAM and needs nearly no time. All right - so there is no duration problem.
First state engine handle the values, but when there are new ones and flush db already happened. The „old“ value is from that point on only read out of the DB from disk?
Did I understand right?
And: is „last changed“ already an older value or an attribute „in parallel“ to the current timestamp? Sothat it is still in RAM after flushing?
You see, I am looking for potential delays in the read-write-chain.
My pefered SW architecture here would be to have (multiple) sensors in a room that result in an entity room_presence(yes,no). All actions, like light off, panel off etc would than only be depended on room_presence.
Is that a possible (performant/reliable) way to go?
What is reading it in your case, or is your question hypothetical?
Last changed is the previous time the state changed, not the time there was last a state written to the DB (it doesn’t have anything to do with the DB). There’s a bit more to it, like the difference between this and last updated and how an HA restart affects this. I’m not sure what you mean with parallel.
Many people do similar things, but YMMV. It depends on many things and probably some trial and error. I personally have created a reverse situation: I use the state of a specific light (the main living room lamp) to trigger many automations and to use it as a proxy for presence. It’s very simple and for years hasn’t had issues with edge cases. Granted, it’s just me and my wife. Things will be interesting with children.