I mean if Dallas temp sensors are working again…
Sorry I thought you were talking about the ota thing.
My 2 Dallas sensors are back working with 2024.6.2
Have you seen a temperature shift like this? Dallas temp, DS18B20, shows lower temperature after update - #8 by Lars_Eriksson
Not that I can see yet as my sensors went offline when I updated to 2024.6.0 on the 20th, at around 12. I’ll keep an eye on the graph today, you can just see it working again on the RHS
Cheers for the info…
I’ve stuck with the latest version and working through the issues.
I’m just getting this error when I recompile my config…?
any advice?
INFO ESPHome 2024.6.2
INFO Reading configuration /config/esphome/esphome-web-075f8b.yaml…
INFO Generating C++ source…
INFO Compiling app…
Processing hotwater (board: esp12e; framework: arduino; platform: platformio/[email protected])
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- ESPAsyncTCP-esphome @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.2.2
|-- DNSServer @ 1.1.1
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- noise-c @ 0.1.4
|-- Wire @ 1.0
Compiling .pioenvs/hotwater/src/main.cpp.o
/config/esphome/esphome-web-075f8b.yaml: In lambda function:
/config/esphome/esphome-web-075f8b.yaml:74:74: error: ‘class esphome::gpio::GPIOOneWireBus’ has no member named ‘state’
74 | it.printf(64, 10, id(roboto), TextAlign::TOP_CENTER, “%2.1f°C”, id(temp).state);
| ^~~~~
*** [.pioenvs/hotwater/src/main.cpp.o] Error 1
========================== [FAILED] Took 4.15 seconds ==========================
Just tried to update OTA 2024.6.3 and getting this error now…
Failed config
ota.esphome: [source /data/packages/74f605c3/base.yaml:51]
Only one instance of the esphome ota platform is allowed per port. Note that this error may result from OTA specified in packages.
platform: esphome
id: ratgdo_ota
version: 2
port: 8266
<<<<<<<<< EDIT 1 >>>>>>>>>
I was able to get update to install by removing
ota:
platform: esphome
<<<<<<<<< <<<<<<<<<<<<<<<<
I just added this “OTA platform: esphome” for the last update(2024.6.2), now remove it for this update(2024.6.3).
P.S. - I did read breaking changes, but didn’t see this.
1 Like
Is the password the local wifi password ?
Dallas sensors have been fixed with 2024.6.3 release. Using last 5 hours with no issue.
1 Like
No. It is the password you use to protect over the air updates from nefarious sources.
Thanks for the information. Really helpful!
Thanks to all who’ve posted here! My update to 2024.6.4 went smoothly, including the OTA and Dallas one-wire changes. Without the guidance here, it would have been a mess. The documentation was as clear as mud. Detailed information here, especially working examples, saved the day.
Cheers from one of those who don’t read stuff Nick
1 Like
Thanks for all the infos. I just updated to esphome 2024.6.4 release. The OTA thingy worked fine. I have been splitting the esphome config YAML files for some time now, i.e. using the packages statement within the toplevel files to include common yaml files. For example, the WIFI- , OTA- reboot-button and other parts are stored in common.yaml, because these parameters are the same for all ESP devices, only the device_name and static_ip need to be configured. This means that the effort for the OTA thingy has been reduced in editing just one single file.
However, there is another problem with the release. The http_request component got a breaking change. This github PR gives some information, but it took me hours to find out the steps to do.
- The get_string method was removed , i.e. the lambda code has to be modified to access the received data → github discussion
- The
http_request.getwas broken. It looks like there is no real solution yet → github discussion.
I go the error-message [http_request.arduino:119]: Content-Length: -1 as well. Then the ESP just hangs, and have to be reseted.
1 Like
Does the beken chips also carry platform: esphome change under OTA?
As far as I can see in the docs it works the same on every micro.
I’ve got 50 devices, so I figured if I’d have to hit them all, I’d use it as an opportunity to try and standardize some basic sensors on them all and some basic configs and pull the identical items out into a separate document that can be referenced instead and most importantly to make it so if another change like this is made in the future, I won’t need to manually edit 50 devices (likely more by the time it happens) and can just edit a couple text files and ‘update all’ and be done with it.
Before the most I had was the SSID & WiFi Password in secrets … I didn’t have fallback APs set, connection status, MAC Addresses, IP Addresses (I found that while I was manually making these updates, I’d occasionally forget to change the IP address when updating and having it the the MAC as a sensor just made it a bit easier to find the mistake when I made it).
I had to do a ton of troubleshooting and testing and ran into some roadblocks using includes (without packages) and such that wouldn’t work if you had (for example) a binary sensor in both your baseline that’s being included and in the device config, so that was a no-go for me.
There were a ton of posts on here that I basically cherrypicked bits and pieces from to come to a solution that worked for me.
I think I only separated WiFi because that’s what someone else did … realistically, if I were doing it again, I’d probably condense that down into the one file instead, but that’ll require me to re-edit all 50 devices again, so that’s not likely to happen … even with a quick script to edit all the files to remove the single line, it’s still not worth even the 5-10 minutes it’d take.
So, this is how I did it, to hopefully be able to help the next person who wants to do something similar … hopefully they’ll pay it forward as well and share what they find to help the next person even more!
I’ve been using ESPHOME since long before it became owned by Home Assistant (and waaaay before it came into the Open Home), so, there is bound to be some ‘cruft’ in here … modify for your purposes as you see fit, but hopefully it’ll give you a place to start if you want to do something similar! I posted basically everything since I always hate filling in gaps from what other people post … here, you’ve got everything that worked for me and you can pull as you need.
Sorry for the freaking book I wrote above.
config/esphome/common_configs/baselineCommon.yaml
logger:
# Time set to zero to prevent reboots when internet is out. Garage went crazy without this ... NOTE: This is potentially bad if the device doesn't have WiFi and won't get it without a reboot.
api:
reboot_timeout: 0s
ota:
platform: esphome
web_server:
port: 80
binary_sensor:
- platform: status
name: "$humanName Connection Status"
button:
- platform: restart
name: $humanName Restart
sensor:
- platform: wifi_signal
name: $humanName Wifi
update_interval: 30s
- platform: uptime
name: $humanName Uptime
id: g_uptime
update_interval: 60s
internal: True
on_raw_value:
then:
- text_sensor.template.publish:
id: uptime_human
state: !lambda |-
int seconds = round(id(g_uptime).raw_state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
return (
(days ? to_string(days) + "d " : "") +
(hours ? to_string(hours) + "h " : "") +
(minutes ? to_string(minutes) + "m " : "")
).c_str();
text_sensor:
- platform: template
name: $humanName Uptime
id: uptime_human
icon: mdi:clock-start
entity_category: diagnostic
- platform: wifi_info
ip_address:
name: $humanName - IP Address
mac_address:
name: $humanName - MAC Address
config/esphome/common_configs/wifi.yaml
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
#fast_connect is needed if your SSID is hidden ... I only use IP addresses for ESPHOME devices, so I don't use a DNS
fast_connect: true
domain: ".YourDomainHere.com"
manual_ip:
static_ip: $ipAddress
gateway: "10.1.100.1"
subnet: "255.255.255.0"
ap:
ssid: "FBH_$deviceName"
password: !secret fallbackPassword
Then, my standard esphome device looks like this:
substitutions:
deviceName: basementmain01-motiontemp
humanName: "Basement Main"
ipAddress: 10.1.100.195
packages:
wifi: !include common_configs/wifi.yaml
device_base: !include common_configs/baselineCommon.yaml
esphome:
name: $deviceName
platform: ESP8266
board: nodemcuv2
binary_sensor:
- platform: gpio
pin: D5
name: "$humanName Motion 01"
device_class: motion
sensor:
- platform: dht
pin: D0
model: DHT22
temperature:
name: "$humanName Temperature"
humidity:
name: "$humanName Humidity"
update_interval: 60s
My secrets is also referenced and that looks like this:
wifi_ssid: "NetworkOfThings_SSID_HERE"
#Generate new ones with password generator, periodically
wifi_password: "Example_Praising$Unclothed7$Deviancy$Tantrum"
fallbackPassword: "Example_Slapping$Ducktail$Sadden0$Salad"
I have a baseline ESP32 one too … I’ve currently only got two ESP32’s, so this is even more of a WIP than the ESP8266 ones (NOTE: You can override the items in the package ‘baseline’ files simply by re-using the items (in this example, the board is different)
config/esphome/common_configs/baselineESP32.yaml
esp32_ble_tracker:
scan_parameters:
active: true
bluetooth_proxy:
active: true
esp32:
board: nodemcu-32s
improv_serial:
Example ESP32 device (honestly, this one is a bit of a mess since it’s basically my first ESPHOME project ever and has even been transferred from an ESP8266 to an ESP32, and has gone through a lot of iterations, so, it could probably be done better, but, it’s been stable) … this is basically 2 reed switches to read when a garage door is open and two relays that I wired into the physical push button on the wall (way pre-dates the ratgdo! … if you’re doing this today, probably use that project as your baseline instead)
substitutions:
deviceName: garage02-openersensor
humanName: "Garage Door"
ipAddress: 10.1.100.190
packages:
wifi: !include common_configs/wifi.yaml
device_base: !include common_configs/baselineCommon.yaml
device32: !include common_configs/baselineESP32.yaml
esphome:
name: $deviceName
esp32:
board: esp32doit-devkit-v1
binary_sensor:
- platform: gpio
pin:
number: GPIO16
mode: INPUT_PULLDOWN
inverted: False
name: "$humanName Right State"
id: garage_door_right
device_class: garage_door
filters:
- delayed_off: 250ms
- platform: gpio
pin:
number: GPIO17
mode: INPUT_PULLDOWN
#inverted: True
name: "$humanName Left State"
id: garage_door_left
device_class: garage_door
filters:
- delayed_off: 250ms
- platform: template
name: "$humanName (Either)"
id: garage_door_either
device_class: garage_door
lambda: |-
if (id(garage_door_left).state) {
return true;
} if (id(garage_door_right).state) {
return true;
} else {
return false;
}
switch:
- platform: gpio
pin: GPIO18
restore_mode: ALWAYS_ON
id: relayleft
- platform: template
name: "$humanName Left"
icon: "mdi:garage-variant"
lambda: |-
if (id(garage_door_left).state) {
return true;
} else {
return false;
}
turn_on_action:
- switch.turn_on: relayleft
- delay: 500ms
- switch.turn_off: relayleft
turn_off_action:
- switch.turn_on: relayleft
- delay: 500ms
- switch.turn_off: relayleft
- platform: gpio
pin: GPIO19
restore_mode: ALWAYS_ON
id: relayright
- platform: template
name: "$humanName Right"
icon: "mdi:garage"
lambda: |-
if (id(garage_door_right).state) {
return true;
} else {
return false;
}
turn_on_action:
- switch.turn_on: relayright
- delay: 500ms
- switch.turn_off: relayright
turn_off_action:
- switch.turn_on: relayright
- delay: 500ms
- switch.turn_off: relayright
5 Likes
OK, my ESPHOME zoo is not that big but it is growing 
Beside the common.yaml and the esp32_base.yaml files I have created a kind of template yaml, e.g. for shelly and sonoff devices. After that the top level yaml looks very clear.
All these include-yaml files are stored in a subdirectory like so, then they don’t appear as dummy devices at the Esphome GUI.
/esphome/config <-- all the device yamls
/esphome/config/lib <-- the template yamls to inlcude
OK it is a little editing but afterwards the final single device needs just some lines of yaml code, e.g. a Shelly 1 plus, all you have to edit is a device_name and an ip-address. Easy peasy for additional shellys.
substitutions:
device_name: "shelly-plus1-01"
ip: 192.168.178.68
packages:
common: !include lib/common.yaml
esp32_base: !include lib/esp32_base.yaml
shelly_plus1: !include lib/shelly_plus1.yaml
logger:
# turn off logger uart
# level: VERBOSE
baud_rate: 0
the lib/common.yaml file
# wifi settings, onchip temperature, memory, speed, ha-time
wifi:
fast_connect: True
manual_ip:
static_ip: ${ip}
gateway: !secret gateway
subnet: !secret subnet
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: ${device_name}
password: !secret esphome_password
power_save_mode: none
# esphome API settings
api:
encryption:
key: !secret esphome_api_key
# over-the-air-update settings
ota:
- platform: esphome
password: !secret esphome_password
# fallback
captive_portal:
web_server:
port: 80
time:
- platform: homeassistant
id: current_time
on_time_sync:
- component.update: uptime_timestamp
sensor:
- platform: uptime
id: uptime_sec
# Device uptime
- platform: template
id: uptime_timestamp
name: "Uptime"
device_class: timestamp
entity_category: diagnostic
accuracy_decimals: 0
update_interval: never
lambda: |-
static float timestamp = (
id(current_time).utcnow().timestamp - id(uptime_sec).state
);
return timestamp;
#Device wifi signal
- platform: wifi_signal
name: Wifi RSSI
device_class: signal_strength
state_class: measurement
entity_category: diagnostic
update_interval: 60s
filters:
- median:
window_size: 7
send_every: 4
send_first_at: 3
- delta: 2 # Only send values to HA if they change
- throttle: 60s # Limit values sent to Ha
binary_sensor:
- platform: status
name: "Status"
text_sensor:
- platform: wifi_info
ip_address:
name: IP Address
icon: mdi:ip-network-outline
button:
- platform: restart
icon: mdi:power-cycle
name: "ESP Reboot"
the lib/esp32_base.yaml file:
sensor:
#Device Memory
- platform: template
name: ESP32 Free Memory
id: esp_memory
icon: mdi:memory
entity_category: "diagnostic"
device_class: data_size
state_class: measurement
unit_of_measurement: "kB"
lambda: return (heap_caps_get_free_size(MALLOC_CAP_INTERNAL) / 1024);
# - platform: esp32_hall
# name: ESP32 Hall Sensor
# update_interval: 60s
the template for shelly plus 1 devices: shelly_plus1.yaml
substitutions:
# Higher value gives lower watt readout
current_res: "0.001"
# Lower value gives lower voltage readout
voltage_div: "1925"
esphome:
name: ${device_name}
friendly_name: ${device_name}
platformio_options:
board_build.f_cpu: 160000000L
esp32:
board: esp32dev
framework:
type: esp-idf
sdkconfig_options:
CONFIG_FREERTOS_UNICORE: y
CONFIG_ESP32_DEFAULT_CPU_FREQ_160: y
CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ: "160"
output:
- platform: gpio
id: "relay_output"
pin: GPIO26
switch:
- platform: output
id: "relay"
name: "Relay"
output: "relay_output"
binary_sensor:
- platform: gpio
name: "Switch"
pin: GPIO4
on_press:
then:
- switch.toggle: "relay"
filters:
- delayed_on_off: 50ms
- platform: gpio
name: "Button"
pin:
number: GPIO25
inverted: yes
mode:
input: true
pullup: true
on_press:
then:
- switch.toggle: "relay"
filters:
- delayed_on_off: 5ms
sensor:
- platform: ntc
sensor: temp_resistance_reading
name: "NTC Temperature"
unit_of_measurement: "°C"
accuracy_decimals: 1
icon: "mdi:thermometer"
calibration:
b_constant: 3350
reference_resistance: 10kOhm
reference_temperature: 298.15K
on_value_range:
- above: "80.0"
then:
- switch.turn_off: "relay"
- platform: resistance
id: temp_resistance_reading
sensor: temp_analog_reading
configuration: DOWNSTREAM
resistor: 10kOhm
- platform: adc
id: temp_analog_reading
pin: GPIO32
attenuation: 11db
- platform: adc
name: "Relay Supply Voltage"
pin: GPIO33
attenuation: 11db
filters:
- multiply: 8
status_led:
pin:
number: GPIO0
inverted: true
I have just one more point. Since remembering to update every esphome device was a bit annoying, I installed esphome on my local machine instead of the HA server. Since then I have been generating everything from the commandline. Downloading a new esphome release from github and also the generation is much faster, and above all I don’t disturb the productive system with compiling and uploading the devices. In addition, I can finally see what the generated source code looks like. I find this very useful, especially when generating lambda code. I’m going crazy in the docker context, it’s all hidden.
2 Likes
Nice! A lot of mine are all homemade and I was an idiot and made each one differently (half the time the length of available wire was the deciding factor!), so I wasn’t able to split it out by device type in a consistent way.
I do have a bunch of in-wall switches and those are all the same, but some switch mains and some control smart switches only, so for me, it was easier to just re-create the device specifics as needed.
I’ll look into ESPHOME locally, but, I’ve got HA loaded into a pretty beefy VM and haven’t really had any issues with the compilation process harming the live system or even taking too long to run.
Thanks. Friend