Shouldn't ESPHome's Uptime and Wifi Sensors show somewhere in Home Assistant

ESPHome
1

I have added this code (mostly from the forum) to have an uptime sensor for my ESPHome devices:

  - platform: uptime
    type: seconds
    name: "Oppetidssensor"
    filters:
      - lambda: return x / 3600.0;
    unit_of_measurement: "hours"
    accuracy_decimals: 2

But it doesn’t show in Home Assistant. I tried adding device_class: timestamp since I read in another thread that humidity needs a device class to show, and I thought that might be the problem here too. But ut still doesn’t show in Hass at all. How can I make it show? Do I need to create an MQTT sensor in Hass for each of the ten plus ESPHome devices and use that instead? That seems unnecessary complicated. The wifi sensor has the same problem, I have this code:

  - platform: wifi_signal
    name: "WiFi-signal"
    update_interval: 60s
    device_class: signal_strength
2

I use this:

sensor:
  - platform: uptime
    name: "Uptime Sensor"
    id: uptime_sensor
    entity_category: "diagnostic"
    internal: false

  - platform: wifi_signal
    name: "WiFi Signal dB"
    id: wifi_signal_db
    entity_category: "diagnostic"

  - platform: copy
    source_id: wifi_signal_db
    name: "WiFi Signal Percent"
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
    unit_of_measurement: " %"
    entity_category: "diagnostic"
    device_class: ""
3

Thank you! That worked out! :grin:

1 Like
4

ESPHome and HA have over the past years made massive improvements to the built-in Native API Component such that it does almost everything that we used to need MQTT to do.

MQTT works well and still has its uses … but be aware that there are still a large number of users, forum posts and blog entries which say to use MQTT because that used to be the best option. For those who are already familiar with MQTT there is no good reason to change … but for new users I suggest that the Native API component will be much easier.

5

This is a system running in my boat. And my problem was that the native API did not play nice when MQTT was activated at the same time. For safety reasons I have a redundancy system that uses MQTT to make sure that even if an ESP should boot, the relays that were on before the boot will still be on.

That system runs on a separate Pi that has a few extra checks (one of them being a custom Python script running at all times) to make sure everything’s working as it should. It can also control the main Pi by restarting Hass or SignalK (boating software) when they lock up (which almost never happens, but if it happens at the wrong time it can be dangerous) and reboot/power cycle the main Pi.

This separate Pi also has the access point for wifi and the MQTT server, so it’s as directly connected to the ESPs as wifi can be. For the most important functions (main power, engine, sonar) I even have a Phidgets physical board that is connected to the main relays so that if the ESP fails, I won’t loose power. Yeah, I’m a bit extreme when it comes to that, 99 % stability is no stability.

6

Yep, this is expected. There’s a warning about this in the ESPHome MQTT page:

image
image1364×184 17.3 KB

7

That’s not it, I had reboots and crashes even when using API for Hass and MQTT on the second Pi for Node-RED.