Need to send initial data on startup and then only upon meeting a threshold

ESPHome
1

I have a esphome device working as a distance-measurement-device that i need to send initial data on startup and then only upon meeting a threshold.

I use the the code below today but the problem is that on device restart, the device doesn’t send any data until the threshold is met. So sensor state will forever be unavailable until anything comes in sight.

How do I change this code below to what I need?

sensor:
  - platform: ultrasonic
    trigger_pin: GPIO0
    echo_pin: GPIO2
    update_interval: 1s
    filters:
     - lambda: |-
         static float last_value = NAN;
         if (isnan(last_value)) {
           last_value = x;
           return {};
         }
         float change = x - last_value;
         if (abs(change) > 0.2) { 
           last_value = x;
           return {x};
         }
         return {};
    timeout: 4m
    name: "XYZ01"
2

What’s wrong with delta filter?

1 Like
3

If you sincerely want to know what’s wrong with it, you should create your own thread about that.
if you’re here to try to help, make it so.

4

Thank’s for valuable advices. Good luck.

1 Like
5

I wouldn’t ask for help if I knew the answer to your question.

6

Is there any kind person (who isn’t rude) that can help me with this?
I would be really grateful.

7

Would an availability template work? The example here relates to energy readings, but the problem seems to be similar.

1 Like
8

@jackjourneyman Thank you for replying.
The thing is that I need the ESP-device to handle this on it own so that it’s not sending data via WiFi on every single difference in measurement. Which tend to be a lot with a ultrasonic sensor. I only want it to send data when necessary.

Worth mentioning is also that I haven’t written the code.
I’m not very good at coding ESP32s. I found it somewhere online and tweaked it for my purpose.

9

Sorry, I misunderstood. Have you looked on the ESPHome forum?

10

Whats wrong using the native API? :rocket:

The ESPHome native API is used to communicate with clients directly, with a highly-optimized network protocol.

Combined with a sane update interval? :stopwatch:

Do you have any bandwidth constrains or other limitations you didn’t shared with us yet (x-y problem)? :thinking:

11

No worries. Yes, I’ve looked but haven’t found anything like it.

12

No, native API isn’t the solution.
I have a working code. I just need it to send data upon device restart.

The ESP-device (sensor) needs to update Home Assistant almost instantly so the update interval can’t be more then a second, preferably a lot less. Sending data that often is not a problem to bandwidth for as long as this sensor is alone in the network. But it’s not. Another problem with sending all live data from the sensor wound be that it is not all accurate and it might give Home Assistant the false impression that the object is closer or further away then it is for just a second. But that can potentially lead to a failure that this sensor is created to prevent. That’s why I also need the filtering in the code.

13

I really don’t understand your concerns. Any technical reasons/links you could provide which support your vague claims? :eyes:

We run over a 100 of esphome nodes and some (like pulse counters) delivery quite astonishing amount of data without any notacible impact on HA or the network itself. We also have ultra sonic sensors in use and can even stream high-res video content over the same (old) wifi :wink:

Just wonder if we have a x-y problem here. :point_down:

The XY problem is a communication problem encountered in help desk, technical support, software engineering, or customer service situations where the question is about an end user’s attempted solution rather than the root problem itself. The XY problem obscures the real issues and may even introduce secondary problems that lead to miscommunication, resource mismanagement, and sub-par solutions.

https://xyproblem.info

And just in case (not clear at all yet with the little information you gave) the goal is to achieve some (very) resilent setup - you don’t want to rely on HA or WIFI (no guaranteed airtime!) and - in best case - have all logic on the esphome node (sensor and actors) :hammer_and_wrench:

And one more helpful link for you :point_down:

14

No need to be rude mate.

I made my self perfectly clear what I needed help with.

The code I got works well for me, I just need it to send a initial data upon startup. Nothing else.

15

How are you sending the data at all? Our esphome based ultrasonic sensors always send the first value after start up/connection which seems to be the default behavior with native api :person_shrugging:

It’s still total unclear to me (and probably many others - hence no one replies?) what your goal is or what the problem is that you are trying to solve. You don’t describe/picture what the problem is you are trying to overcome nor what your config/yaml looks like. Without being rude it really looks like the typical x-y problem we have here :yawning_face:

sketchplanations-the-xy-problem
sketchplanations-the-xy-problem3432×3432 681 KB

You then might simply need to find somebody who you can pay to receive the help you are requesting.

As you already know :point_down:

16

As it seems it’s already on Native API

The goal is totally irrelevant. I don’t need to explain what the sensor is for in this case, I provided the information you need.

A sensor that has the value “unknown” at startup is the problem.
The workaround is the wave in front of the sensor so that the filter threshold is met and and trigger it to send data.

Without the filter in the code it send data on startup but I need the filter in the code (I have been running the sensor without it for a long time) and the problem I have then is that sensor value fluctuating to much that an object that is in front of the sensor al of a sudden is gone for about a second.
The filter has, as mentioned, helped with this and works very well.

Posting big pictures like that can seem a bit rude, Yes!
And so you did it again.

If it’s no solution. Fine. It has taken more time then it was worth already.
And it wasn’t a nice chat either.

17

We can’t know as you did not provide the minimum information necessary to evaluate this (full yaml). More over you claimed in one of your post that the native “isn’t the solution” which can be interpreted that you don’t use it. :person_shrugging:

Nope, not even the basics. Classic X-Y problem… :yawning_face:

That’s totally different from everything you told us so far. :warning:

Please don’t be sad but instead wasting more time trying helping you I’d rather use it smarter and help 10 others that know how to ask a good question :bulb:

You actually wasted all our time by not providing necessary information even when asked multiple times. :person_facepalming:

Good luck :wave:

PS: Minimum two possible solutions are floating in my head :brain:

1 Like
18

@Grepen with all due respect, you need to re-evaluate how you behave on these forums. The first reply to you was not rude, yet you claimed it was. Also @orange-assistant’s 2nd reply to you wasn’t rude… everything after that is up for debate. As an outside observer, the rudeness didn’t appear until after you mentioned rude replies in both instances.

In fact, the first rude reply is this:

2 Likes
19

I think the answer was in the first response you got. The question was why you wrote your own filter instead of using the standard delta filter. Had you looked it up you would have seen it. It probably does not contain the bug you have in your filter lambda.

It is ok that you know little about the code, but then you should not dismiss any answer you get. If you do not understand the intent of the answer, ask.

the problem with your code is that the first measurement is stored in the static variable, but not returned. This:

           last_value = x;
           return {};

Should be this:

           last_value = x;
           return {x};

But most likely, had you asked what the first post was about, you would have done this (I have not tried it, but is unlikely it contains the same bug):

sensor:
  - platform: ultrasonic
    trigger_pin: GPIO0
    echo_pin: GPIO2
    update_interval: 1s
    filters:
     - delta: 0.2
    timeout: 4m
    name: "XYZ01"

Frankly, I originally stopped looking at your problem when I saw how you responded to the first post.

20

It was just copy-pasta :spaghetti: without the author knowing what actually is going on :person_shrugging: