ESPhome custom component for us-100 uart can't compile after update

ESPHome
1

Hello,

I use esphome to monitor my oil tanks. In every tank i have an esp8266 that talks to an us-100 ultrasonic sensor via uart (uart mode is hardwired and the sensors themself are glued into an housing, so it’s not easy to change communication mode to trigger/echo pins like the ultrasonic example shows).

This is my code, that works with esphome 2024:

esphome:
  name: esp8266-us100-tank3
  friendly_name: esp8266-us100-tank3
  includes:
    - us100.h

esp8266:
  board: esp01_1m

# Enable logging
logger:
  # disable serial ogging, we need it fpr us100
  baud_rate: 0


# Enable Home Assistant API
api:
  encryption:
    key: "mysuperstrongencryptionkeyplaceholder"

ota:
  - platform: esphome
    password: "mysuperstrongencryptionkeyplaceholder"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esp8266-Us100-Tank3"
    password: "mysuperstrongencryptionkeyplaceholder"

captive_portal:

uart:
  id: uart_bus
  tx_pin: GPIO0
  rx_pin: GPIO2
  baud_rate: 9600

sensor:
  - platform: wifi_signal
    name: "WiFi Signal Sensor"
    update_interval: 60s
  - platform: custom
    lambda: |-
      auto us100 = new US100(id(uart_bus));
      App.register_component(us100);
      return {
        us100->distsensor,
        us100->tempsensor,
      };
    sensors:
      - name: "US100 Distance"
        id: "tank3_distance"
        unit_of_measurement: mm
        icon: "mdi:tape-measure"
      - name: "US100 Temperature"
        id: "tank3_temperature"
        unit_of_measurement: °C
  - platform: template
    name: "Ölmenge in Liter"
    accuracy_decimals: 0
    unit_of_measurement: "L"
    lambda: |-
      int liters = 0;
      if ( ( id(tank3_distance).state > 1500 ) || ( id(tank3_distance).state < 10 ) ) {
        liters = 0;
      } else {
        liters = ( 1500 - (int) id(tank3_distance).state ) * 0.6933 ;
      }
      if (liters > 1050)
      {
        return 0;
      }
      else if (liters > 0)
      {
        return liters;
      }
      else
      {
        return 0;
      }
    update_interval: 60s
    filters:
      - sliding_window_moving_average:
          window_size: 60
          send_every: 60
          send_first_at: 60
  - platform: template
    name: "Ölmenge in Prozent"
    accuracy_decimals: 0
    unit_of_measurement: "%"
    lambda: |-
      int percent = 0;
      if ( ( id(tank3_distance).state > 1500 )  || ( id(tank3_distance).state < 10 ) ) {
        return 0;
      } else {
        // = Füllhöhe[mm]                         * ( 100% / maxFüllhöhe(1500mm) ) = Füllhöhe[mm] * 0,06666666666667
        // = ( maxFüllhöhe(1500mm) - t3dist[mm] ) * 0,0666666666667
        //return ( ( 1500 - (int) id(tank3_distance).state ) * 0.067 );
        percent = ( 1500 - (int) id(tank3_distance).state ) * 0.067;
      }
      if (percent > 100)
      {
        return 0;
      }
      else if (percent > 0)
      {
        return percent;
      }
      else
      {
        return 0;
      }
    update_interval: 60s
    filters:
      - sliding_window_moving_average:
          window_size: 60
          send_every: 60
          send_first_at: 60

My actual solution is to stay at esphome 2024.12. Does anybody know how the code has to be modified to compile with esphome2025.03 ?

Best regards
Marcel

2
1 Like
3

Hello muh_kuh_zutscher,

You may want to ask here: ESPHome

1 Like
4

Maybe this solution can help, since it does not use a custom component.

5

Thank you for trying to help, but I really don’t like discord.

6

Thanks for trying to help, but my preferred solution would be to migrate my code instead of patching esphome itself with unknown effects for the future.

7

If you don’t want to bring back custom component support and you don’t want to join Discord to ask for help, you can start here: Contributing — ESPHome

(note that one of the main reasons I brought back custom component support is because the process of converting them to an external component is not trivial, and the process is basically undocumented)

8

I agree with @robertklep on this one. You will need to dedicate a lot of time and thought to convert the us100 code to an external component.

But, look here: JSN-SR04T Waterproof Ultrasonic Range Finder — ESPHome

That might work as is or maybe reasonably easy to adapt it to work with your sensor, since it is presumably doing close to the same thing.

1 Like
9

Thanks for your answer. SR04 where the first sensors, I tried but I was not satisfied with the result. US-100 give me a lot better results. (And the sr04 has other disatvantages, compared to the us-100, for example the sr-04 cant detect distances lower than 20 cm which the us-100 can. That was one of the killer features because of how i placed them in the tanks)

If it’s so a big think to convert the code, then if think i just stay with esphome 2024. Maybe I also dont run in other breaking changes.

Fun fact: I run esp8266 sensors for 10 years. At the time back, when esp8266 + arduino ide was the hot new thing, i soldered ds18b20 to the esp8266, glued the 1wire example to the http-server example and can parse this with my browser/munin/checkmk until today, it just works. But reflashing would be not so comfortable. Here esphome is a real game changer.

For other people who are cleverer than me and didnt glued their us100, best option would be to remove the jumper at the us100. Then it acts like a sr04 and can be used with trigger/echo example, at the cost of loosing some precision and the temperature sensor ability.

10

Good option for sensors that have been running a decade without problems.
And Roberts approach is equally good…