Get sensor value immediately after ON system#init instead of next ON MySensor#temperature

[tuxbow]

hello all,
i want to build a temperature/humidity sensor which immediatly goes to deepsleep if the new value does not differ too much from the last transmitted value. The rule
ON system#init DO status10 ENDON ON HTU21#Temperature DO mem1=%value% ENDON
displays the sensor values about 0.2 seconds after restart, while ON HTU21#Temperature appears about 3 sec. later, meanwhile the connection to the server is started. Is there a way to acces the sensor values directly, not waiting for the next MySensor#MyValue event?
Regards, Dirk

[sfromis]

While I'd generally recommend against expecting a couple of seconds to matter for ambient temperature, especially when doing nothing but set a variable, it is still an invalid command (it does not do what you want). The command would be Status 10; computers are very fussy about details like spaces. Do make sure to very carefully read the log when things does not happen as you hoped for.

One reason for discouraging the idea of polling sensors "as fast as possible" is that some sensors may not have booted or stabilized yet. IDK about HTU21, but with another sensor I saw that it did not yet have a valid reading at that time.

[tuxbow]

hi sfromis, thank you for your hint. The missing space in STATUS 10 was a typo in my question, not in my rule.
Regarding the idea of polling sensors "as fast as possible": I want to write a rule for MY HTU21 sensor. If it does not work because the sensor is too slow, it is MY mistake, and NOT a bug in TASMOTA. using
ON system#init DO status 10 ENDDO anyhow would show wrong values if the sensor is too slow.
In the code of xsns_08_htu21.ino I see that the values are stored in a struct as Htu.temperature etc. What I asked : Is it possible to access these values from a rule? e.g. ON system#init DO backlog status 10; mem1=Htu.temperature ENDDO ?
(Of course the name "Htu.temperature" is not correct)

[sfromis]

There is no "direct" access to the driver internals, only the JSON-based way you already use for the sensor payload. The difference is that the payload from Status 10 has an extra JSON object level, which you can also use in the trigger. That was an additional reason for me to remind you of reading the log output very carefully.

BTW. I can strongly recommend using copy-paste instead of manually retyping rules (or other things), as we by necessity are on the lookout for wrong details which would cause problems.