SeByDocKy
commented
5 months ago For me, with this new version, my ESP32 S3 crash after a couple of second
Closed rccoleman closed 5 months ago
SeByDocKy
commented
5 months ago For me, with this new version, my ESP32 S3 crash after a couple of second
rccoleman
commented
5 months ago Seems unrelated to this issue. Feel free to open a new one.
ssieb
commented
5 months ago @rccoleman that's very strange. Try using this:
one_wire:
- platform: gpio
pin: 4
id: dallas
button:
- platform: template
name: Test 1-wire bus
then:
- lambda: |-
id(dallas).search();
id(dallas).dump_config();See what you get in the logs when you do that.
@SeByDocKy get serial logs of the crash, then come ask on discord or file a different issue.
rccoleman
commented
5 months ago Hmm, looks like it worked with that?
I still got the "No devices found!" during startup, but that search worked. Here's the full log after I removed the explicit address in the sensor:
[15:20:08][I][app:100]: ESPHome version 2024.6.0b2 compiled on Jun 15 2024, 15:19:28
[15:20:08][C][wifi:599]: WiFi:
[15:20:08][C][wifi:427]: Local MAC: 48:E7:29:6E:AD:1A
[15:20:08][C][wifi:432]: SSID: [redacted]
[15:20:08][C][wifi:435]: IP Address: 192.168.1.53
[15:20:08][C][wifi:438]: BSSID: [redacted]
[15:20:08][C][wifi:440]: Hostname: 'kit-water-temp'
[15:20:08][C][wifi:442]: Signal strength: -70 dB ▂▄▆█
[15:20:08][C][wifi:446]: Channel: 1
[15:20:08][C][wifi:447]: Subnet: 255.255.255.0
[15:20:08][C][wifi:448]: Gateway: 192.168.1.1
[15:20:08][C][wifi:449]: DNS1: 192.168.1.1
[15:20:08][C][wifi:450]: DNS2: 0.0.0.0
[15:20:08][C][logger:185]: Logger:
[15:20:08][C][logger:186]: Level: DEBUG
[15:20:08][C][logger:188]: Log Baud Rate: 115200
[15:20:08][C][logger:189]: Hardware UART: UART0
[15:20:08][C][gpio.one_wire:016]: GPIO 1-wire bus:
[15:20:08][C][gpio.one_wire:017]: Pin: GPIO4
[15:20:08][W][gpio.one_wire:078]: Found no devices!
[15:20:08][C][restart.button:017]: Restart Button 'Kitchen Restart'
[15:20:08][C][dallas.temp.sensor:029]: Dallas Temperature Sensor:
[15:20:08][W][dallas.temp.sensor:031]: Unable to select an address
[15:20:08][C][mdns:115]: mDNS:
[15:20:08][C][mdns:116]: Hostname: kit-water-temp
[15:20:08][C][esphome.ota:073]: Over-The-Air updates:
[15:20:08][C][esphome.ota:074]: Address: kit-water-temp.local:8266
[15:20:08][C][esphome.ota:075]: Version: 2
[15:20:08][C][safe_mode:018]: Safe Mode:
[15:20:08][C][safe_mode:019]: Boot considered successful after 60 seconds
[15:20:08][C][safe_mode:021]: Invoke after 10 boot attempts
[15:20:08][C][safe_mode:022]: Remain in safe mode for 300 seconds
[15:20:08][C][api:139]: API Server:
[15:20:08][C][api:140]: Address: kit-water-temp.local:6053
[15:20:08][C][api:144]: Using noise encryption: NO
[15:20:12][D][api:102]: Accepted 192.168.1.159
[15:20:12][D][api.connection:1375]: Home Assistant 2024.6.3 (192.168.1.159): Connected successfully
[15:20:16][D][button:010]: 'Test 1-wire bus' Pressed.
[15:20:16][C][gpio.one_wire:016]: GPIO 1-wire bus:
[15:20:16][C][gpio.one_wire:017]: Pin: GPIO4
[15:20:16][C][gpio.one_wire:080]: Found devices:
[15:20:16][C][gpio.one_wire:082]: 0x480000006a42a528 (DS18B20)Maybe a race condition/dependency issue?
ssieb
commented
5 months ago Can you get serial logs from boot? And can you come find me on the esphome discord server, so we be more interactive?
rccoleman
commented
5 months ago Sure
roblamoreaux
commented
5 months ago I noticed this as well, but was able to go back a version to find the device IDs to put in for my devices. After adding the device IDs for the three DS18x20s I have it listed the ids during One_wire init.
It would be nice if the index: x option worked still or there was an easier way to assign which device is which after boot so we don't have to compile, run, find ids, update code, compile and run again.
Rob
I did save logs if needed, but they are on another computer
rccoleman
commented
5 months ago @ssieb provided a patch that a patch on Discord that just retries discovery 5 times and it works for me. Obviously just a workaround, though.
https://discord.com/channels/429907082951524364/866427615564922920/1251665034191310879
external_components:
- source:
type: git
url: https://github.com/ssieb/esphome
ref: onewire
components: [ gpio ]
refresh: 1min
djexplode6
commented
5 months ago Same here. Had Dallas temps working fine on.5. Changed config to use one-wire for .6. One-wire reports nothing on the bus. I have the devices defined with their ids and get the following errors:
[17:53:18][W][component:170]: Component dallas_temp.sensor cleared Warning flag [17:53:18][W][dallas.temp.sensor:074]: 'Refridgerator' - reading scratch pad failed bus reset [17:53:18][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [17:53:18][D][sensor:094]: 'Refridgerator': Sending state nan °C with 1 decimals of accuracy [17:53:34][W][component:170]: Component dallas_temp.sensor cleared Warning flag [17:53:34][W][dallas.temp.sensor:074]: 'Freezer' - reading scratch pad failed bus reset [17:53:34][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [17:53:34][D][sensor:094]: 'Freezer': Sending state nan °C with 1 decimals of accuracy
Related Config:
one_wire:
sensor:
kbrgmn
commented
5 months ago Indeed, the sensor which worked on 2024.5 is not being reported anymore with 2024.6.0, even when updated for the breaking changes according to the changelog:
one_wire:
- platform: gpio
pin: 4
sensor:
- platform: dallas_temp
name: "Temperature"I added a logic analyzer trace here for one of my devices: https://discord.com/channels/429907082951524364/1251665034191310879/1252826630561464452
TheRealFalseReality
commented
5 months ago Would support for using index: come back? It really helps for not having to find the addresses, especially if using just 1 Dallas probe.
rccoleman
commented
5 months ago if you're just using one, a functional discovery mechanism would work without index. Adding this from above works around the discovery issue and I no longer need to specify the address:
@ssieb provided a patch that a patch on Discord that just retries discovery 5 times and it works for me. Obviously just a workaround, though.
https://discord.com/channels/429907082951524364/866427615564922920/1251665034191310879
external_components: - source: type: git url: https://github.com/ssieb/esphome ref: onewire components: [ gpio ] refresh: 1min
Otherwise, it sounded like index wasn't a very reliable way to identify individual devices on a bus that contains more than one.
TheRealFalseReality
commented
5 months ago if you're just using one, a functional discovery mechanism would work without
index. Adding this from above works around the discovery issue and I no longer need to specify the address:@ssieb provided a patch that a patch on Discord that just retries discovery 5 times and it works for me. Obviously just a workaround, though. https://discord.com/channels/429907082951524364/866427615564922920/1251665034191310879
external_components: - source: type: git url: https://github.com/ssieb/esphome ref: onewire components: [ gpio ] refresh: 1minOtherwise, it sounded like
indexwasn't a very reliable way to identify individual devices on a bus that contains more than one.
I'll look into. I'm using a total of 6 ESP32 devices, 2 of which are using 2 dallas sensors (to monitor 2 adjacent aquariums). I actually use index: 0 and another sensors with index: 1 . They have always been discovered and to my surprise, they have never switched, as I feared they may have. Really convenient way to have dallas_sensors "plug-and-play". I was able to just have the code set-up for 2 sensors for each device, and whenever I was to add another one, all I had to add was wire it and restart the esp32 device...
Here's an example and the source code if you wanted to take a look:
sensor:
# Temperature Probe 1
- platform: dallas
id: temp_1
icon: mdi:thermometer-lines
index: 0
name: "Temperature"
state_class: "measurement"
device_class: "temperature"
filters:
- calibrate_linear:
method: least_squares
datapoints:
- 0.0 -> ${cal_0}
- 100.0 -> ${cal_100}
on_value:
then:
- component.update: temp_range
# Temperature Probe 2
- platform: dallas
id: temp_2
icon: mdi:thermometer-lines
index: 1
name: "Temperature 2"
state_class: "measurement"
device_class: "temperature"
filters:
- calibrate_linear:
method: least_squares
datapoints:
- 0.0 -> ${cal_0_2}
- 100.0 -> ${cal_100_2}
disabled_by_default: true
on_value:
then:
- component.update: temp_range_2https://github.com/TheRealFalseReality/aquapi/blob/main/common/temperature_dallas.yaml
brostudiodev
commented
5 months ago I have tried the workaroud
Couldn't find any component that can be used for 'one_wire::OneWireBus'. Are you missing a hub declaration?.
if you're just using one, a functional discovery mechanism would work without
index. Adding this from above works around the discovery issue and I no longer need to specify the address:@ssieb provided a patch that a patch on Discord that just retries discovery 5 times and it works for me. Obviously just a workaround, though. https://discord.com/channels/429907082951524364/866427615564922920/1251665034191310879
external_components: - source: type: git url: https://github.com/ssieb/esphome ref: onewire components: [ gpio ] refresh: 1minOtherwise, it sounded like
indexwasn't a very reliable way to identify individual devices on a bus that contains more than one.
I have tried this one but it is not installing - error: Couldn't find any component that can be used for 'one_wire::OneWireBus'. Are you missing a hub declaration?.
And yes my dallas temp sensors failed due 2024.6 update :( Please fix this or restore dallas sensor in ESPHome :(
Makin-Things
commented
5 months ago I just updated and have the same problem. I already had the correct address in the config yet it still cannot be found. Now I am without a working heater when it is frigging cold. So how do I get my heater working again?
@jesserockz I seriously don't understand how a breaking change with open issues against it could possibly be merged and released.
SeByDocKy
commented
5 months ago I can also confirm that that the new one-wire integration let crash my ESP32 S3..... I tested also the n-1 commit and was working fine until the one-wire commit.
Actually this ESP32 S3 is in production in my solar station. I have to make an access to the serial port (in the current enclosing box) to output serial logs to help to debug...
schinddo
commented
5 months ago I had also similar problems with the 2024.6.1 release and I urgently need a working one-wire component so I downgraded to 2024.5.5 release and its working fine now.
I will wait with the update until this is fixed.
There is also issue #5922 for the final 2024.6.0 release.
brostudiodev
commented
5 months ago I just updated and have the same problem. I already had the correct address in the config yet it still cannot be found. Now I am without a working heater when it is frigging cold. So how do I get my heater working again?
@jesserockz I seriously don't understand how a breaking change with open issues against it could possibly be merged and released.
For this case it is better to go back to previous version (use Settings/System/Restore points (or similar -> I have different lang than EN in my instance) and revert back the change. It is better to wait once HA team fixed this...
Makin-Things
commented
5 months ago I just updated and have the same problem. I already had the correct address in the config yet it still cannot be found. Now I am without a working heater when it is frigging cold. So how do I get my heater working again? @jesserockz I seriously don't understand how a breaking change with open issues against it could possibly be merged and released.
For this case it is better to go back to previous version (use Settings/System/Restore points (or similar -> I have different lang than EN in my instance) and revert back the change. It is better to wait once HA team fixed this...
It was easier to go back to dumb heating. But the release practices for ESPHome need to be looked at. It is such a PITA every time a minor patch is released.
SeByDocKy
commented
5 months ago I would also vote for a revert to the dallas component until the one-wire is fully tested and debugged....
mathieucarbou
commented
5 months ago https://github.com/ssieb/esphome
I've looked at the diff (https://github.com/ssieb/esphome/commit/0a704810a88a502232c0129ce5fdb60d9e2f695a#diff-fe5aa506e8e456fd0236a4fd142f41d72c8c358d54007854f5738e40e805b41b) and this is exactly what I also need to do with the implementation for DS18 on ESP32 I am using, which relies on the RMT Peripheral and don't have any delay calls. Scanning the devices once right after a boot is a hit and miss and I need to redo the scan.
I've seen that the previous impl of 1-wire in ESPHome was also relying heavily on delays in the I/O methods plus one of 500us just in the setup before scanning. Now, the search is happening right away:
before:
// clear bus with 480µs high, otherwise initial reset in search_vec() fails
pin_->pin_mode(gpio::FLAG_INPUT | gpio::FLAG_PULLUP);
delayMicroseconds(480);
one_wire_ = new ESPOneWire(pin_); // NOLINT(cppcoreguidelines-owning-memory)
std::vector<uint64_t> raw_sensors;
raw_sensors = this->one_wire_->search_vec();now:
void GPIOOneWireBus::setup() {
ESP_LOGCONFIG(TAG, "Setting up 1-wire bus...");
this->search();
}Maybe this delay was helping this hit and miss ?
saschaludwig
commented
5 months ago Indeed, the sensor which worked on 2024.5 is not being reported anymore with 2024.6.0, even when updated for the breaking changes according to the changelog:
one_wire: - platform: gpio pin: 4 sensor: - platform: dallas_temp name: "Temperature"
ESP8266 GPIO4 same here, worked on 2024.5.5 broken on 2024.6.1
gjgeary
commented
5 months ago I am seeing this issue with DS18B20 on ESP32. I have another ESP8266 with 2 DS18B20 sensors that is working just fine. So far. Fingers crossed.
roblamoreaux
commented
5 months ago I am going to try to get better logs tonight or this weekend on my 2 DS1820 sensor board since it only has sensors and a display unlike the other boards.
Is there anything I can set to get better logs?
When I set very_verbose there were a lot of other messages but not enough about the 1-wire stuff to be useful.
Of note about using Index. Because of the way discovery is done as long as all devices are up the index will always be same address order unless a part is replaced. So while I find Index useful I can see it is not the greatest solution. I'd love it if the index could be changed as a configuration parameter so it doesn't need a recompile to change which device is where.
Links2004
commented
5 months ago can confirm this being a problem with ESP32 and ESP32-C3 e.g.: https://github.com/esphome/issues/issues/5936
any more debugging info that can I provide for my setup, or is there good info already to fix it?
in short after 2024.6.1 (did not test 2024.6.0):
Found no devices!SeByDocKy
commented
5 months ago and ESP32-S3 ...
gabest11
commented
5 months ago I also have a problem with the C3 (board) and this temperature sensor. Tested all available gpio pins and found that half of them do not work.
GPIO0 OK GPIO1 OK GPIO3 OK GPIO4 FAIL GPIO5 FAIL GPIO6 FAIL GPIO7 FAIL GPIO10 OK
Just to verify my setup, tried an old esp32 nudemcu and a esp8266 d1 mini, they worked the first time on GPIO23 and GPIO4.
peregrines2
commented
5 months ago Same here :( GPIO4 FAIL ESP8266: worked on 2024.5.5 broken on 2024.6.1
ConvergintMarkMartens
commented
5 months ago Confirmed Broken. Same Here.. ESP32 GPIO13 Worked on 2024.5.5 Broken on 2024.6.1
Some logs in case it helps:
[13:08:37][W][component:170]: Component dallas_temp.sensor cleared Warning flag [13:08:38][W][dallas.temp.sensor:074]: 'Combustion Air' - reading scratch pad failed bus reset [13:08:38][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [13:08:38][D][sensor:094]: 'Combustion Air': Sending state nan °C with 1 decimals of accuracy [13:08:39][W][component:170]: Component dallas_temp.sensor cleared Warning flag [13:08:40][W][component:170]: Component dallas_temp.sensor cleared Warning flag [13:08:40][W][dallas.temp.sensor:074]: 'Cold Water Supply' - reading scratch pad failed bus reset [13:08:40][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [13:08:40][D][sensor:094]: 'Cold Water Supply': Sending state nan °C with 1 decimals of accuracy [13:08:41][W][dallas.temp.sensor:074]: 'Thermostat' - reading scratch pad failed bus reset [13:08:41][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [13:08:41][D][sensor:094]: 'Thermostat': Sending state nan °C with 1 decimals of accuracy [13:08:43][W][component:170]: Component dallas_temp.sensor cleared Warning flag [13:08:43][W][dallas.temp.sensor:074]: 'Cold Air Return' - reading scratch pad failed bus reset [13:08:43][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [13:08:43][D][sensor:094]: 'Cold Air Return': Sending state nan °C with 1 decimals of accuracy [13:08:48][W][component:170]: Component dallas_temp.sensor cleared Warning flag [13:08:49][W][dallas.temp.sensor:074]: 'Attic Sensor 1' - reading scratch pad failed bus reset [13:08:49][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [13:08:49][D][sensor:094]: 'Attic Sensor 1': Sending state nan °C with 1 decimals of accuracy [13:08:51][W][component:170]: Component dallas_temp.sensor cleared Warning flag [13:08:52][W][dallas.temp.sensor:074]: 'Outside North' - reading scratch pad failed bus reset [13:08:52][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed [13:08:52][D][sensor:094]: 'Outside North': Sending state nan °C with 1 decimals of accuracy [13:08:53][W][component:170]: Component dallas_temp.sensor cleared Warning flag
Update
Added:
update_interval: 60s
and no change. It just takes longer to get the same errors.
Rollback to ESPHome 2024.5.5; everything works perfect. (No stability issues during the last few years)
gabest11
commented
5 months ago Could someone test this?
external_components:
- source: github://gabest11/esphome@one_wire
components: [ gpio ]It fixes my problem where half of the pins are not working.
rccoleman
commented
5 months ago Doesn't help for my discovery issue. I'm using
# Temp Sensor on D02/GPIO4
one_wire:
- platform: gpio
pin: 4
id: dallas[18:04:08][C][gpio.one_wire:017]: GPIO 1-wire bus:
[18:04:08][C][gpio.one_wire:018]: Pin: GPIO4
[18:04:08][W][gpio.one_wire:078]: Found no devices!
[18:04:08][C][restart.button:017]: Restart Button 'Kitchen Restart'
[18:04:08][C][dallas.temp.sensor:029]: Dallas Temperature Sensor:
[18:04:08][W][dallas.temp.sensor:031]: Unable to select an address
joe-cole1
commented
5 months ago Same issue here. I have two DS18B20 sensors on an ESP32. The one on pin 22 works. Pin 14 does not work.
thargy
commented
5 months ago I have 9 DS18B20 sensors on an ESP32 on pin 14. I've been using the sensors for over a year without issue before the release of 2024.6. It worked for several hours before the above issue appeared, and I lost all temperature readings. This caused my hot water tank to overheat in the middle of the night and woke me up at 4AM!
Even though I have ESPHome installed via HAOS, I also have a local installation on my dev machine, so it was relatively quick for me to roll back by reverting my local version and pushing the firmware from my PC rather than the HAOS add-on. I have huge sympathy for less techie users trying to figure out how to do a rollback via HAOS itself...
On the plus side, this has reminded me to check for NaNs in the temperature readings and act appropriately (i.e. turn off immersion heaters when I can't read the temperatures!)
Mistakes do happen, particularly in open-source software run by volunteers. Further, the suggestion of splitting the dallas component up to allow for more 1-wire components in future is sensible. My goal is not to dump on @ssieb or @jesserockz, who I have no doubt are as disappointed as any of us (and probably more so). No one wants to release broken code.
However, it is abundantly clear that this issue did not only separate out the 1-wire logic. Instead, it changed a lot of the existing logic and timings for the existing temperature sensor. As a result, the description of the breaking change was far from complete - and is a classic example of doing too much in one step. Indeed, it also dropped index and moved update_interval, neither of which surfaced clearly in the release notes, making it hard for users to understand what has broken and why. The update_interval change is buried even further.
ESPHome is a hugely popular project, and DS18B20 sensors are a popular sensor and common use case. Many users will use ESPHome via HAOS, and rolling back an addon version is far from trivial.
At the very least, I submit that the existing 'Dallas' component should have been left in place for a period with a compile warning or similar to indicate it was deprecated. This would have allowed users to migrate to the new 1-wire system in their own time and to easily roll back when they identified this problem.
Can I respectfully encourage @ssieb to focus on creating a PR that allows the legacy dallas component to coexist with the new one_wire & dallas_temp components so that it can be released ASAP and restore existing functionality? That way, the numerous timing issues and bugs can be addressed without prolonging the disruption.
Similarly, could I encourage @jesserockz to consider requiring deprecation periods over breaking changes when accepting pull requests? I appreciate that it can sometimes cause more work, but it is a reasonable balance to protect less technical users and one adopted by the HA devs in general.
I have tried very hard to write this in a constructive manner, and I hope it reads as such.
schinddo
commented
5 months ago I've seen that the previous impl of 1-wire in ESPHome was also relying heavily on delays in the I/O methods plus one of 500us just in the setup before scanning. Now, the search is happening right away:
before:
// clear bus with 480µs high, otherwise initial reset in search_vec() fails pin_->pin_mode(gpio::FLAG_INPUT | gpio::FLAG_PULLUP); delayMicroseconds(480); one_wire_ = new ESPOneWire(pin_); // NOLINT(cppcoreguidelines-owning-memory) std::vector<uint64_t> raw_sensors; raw_sensors = this->one_wire_->search_vec();
Maybe the DS18B20 sensor needs to be reset before you can use it, unlike other sensors.
In the DS18B20 manual, in chapter "Hardware Configuration", there is a delay of 480 µs mentioned for reset:
If the bus is held low for more than 480μs, all components on the bus will be reset.
ssieb
commented
5 months ago Yes, I missed the setup call and it seems that it only matters in some cases. This change was tested by several people on various platforms with no issues found (including people that couldn't use the previous version of the component). If more people would test beta releases, issues like this would be much more likely to be found. Test out this branch that has several fixes and works for several people that have been having issues:
external_components:
- source:
type: git
url: https://github.com/ssieb/esphome
ref: onewire
components: [ gpio ]
refresh: 1minLet me know if you see anything other than 0 retries in the config logging.
joos81
commented
5 months ago Yes, I missed the setup call and it seems that it only matters in some cases. This change was tested by several people on various platforms with no issues found (including people that couldn't use the previous version of the component). If more people would test beta releases, issues like this would be much more likely to be found. Test out this branch that has several fixes and works for several people that have been having issues:
external_components: - source: type: git url: https://github.com/ssieb/esphome ref: onewire components: [ gpio ] refresh: 1minLet me know if you see anything other than 0 retries in the config logging.
This resolves the issue for me on two ESP32 devices with Dallas sensors on GPIO15. I don't have any errors or warnings in the logs anymore and I get proper temperature readings.
kaufe
commented
5 months ago Yes, I missed the setup call and it seems that it only matters in some cases. This change was tested by several people on various platforms with no issues found (including people that couldn't use the previous version of the component). If more people would test beta releases, issues like this would be much more likely to be found. Test out this branch that has several fixes and works for several people that have been having issues:
external_components: - source: type: git url: https://github.com/ssieb/esphome ref: onewire components: [ gpio ] refresh: 1minLet me know if you see anything other than 0 retries in the config logging.
Same for me, resolved also the Issue on 2 ESP32 devices with Dallas sensors ON GPIO14. Thanks @ssieb Don`t see any Errors or warning in the logs.
peregrines2
commented
5 months ago Yes, I missed the setup call and it seems that it only matters in some cases. This change was tested by several people on various platforms with no issues found (including people that couldn't use the previous version of the component). If more people would test beta releases, issues like this would be much more likely to be found. Test out this branch that has several fixes and works for several people that have been having issues:
external_components: - source: type: git url: https://github.com/ssieb/esphome ref: onewire components: [ gpio ] refresh: 1minLet me know if you see anything other than 0 retries in the config logging.
Did not work for me on 2 ESP8266 GPIO2
ssieb
commented
5 months ago Did not work for me on 2 ESP8266 GPIO2
Need more info than that. And GPIO2 is not a good pin to use. Did it work on that before?
peregrines2
commented
5 months ago Did not work for me on 2 ESP8266 GPIO2
Need more info than that. And GPIO2 is not a good pin to use. Did it work on that before?
It did work perfectly before (about 6 months now). Updating esphome broke it yesterday.
ssieb
commented
5 months ago And you still didn't provide any details...
Pulpet90
commented
5 months ago After update to 2024.6.3, I can see my sensors finally
[09:58:08][C][gpio.one_wire:016]: GPIO 1-wire bus:
[09:58:08][C][gpio.one_wire:017]: Pin: GPIO5
[09:58:08][C][gpio.one_wire:080]: Found devices:
[09:58:08][C][gpio.one_wire:082]: 0x0280000003678628 (DS18B20)
[09:58:08][C][gpio.one_wire:082]: 0x9c800000036f0b28 (DS18B20)
[09:58:08][C][gpio.one_wire:082]: 0x85800000039a9f28 (DS18B20)[10:07:16][C][dallas.temp.sensor:029]: Dallas Temperature Sensor: [10:07:16][C][dallas.temp.sensor:034]: Address: 0x0280000003678628 (DS18B20) [10:07:16][C][dallas.temp.sensor:035]: Resolution: 12 bits [10:07:16][C][dallas.temp.sensor:036]: Update Interval: 3.0s [10:07:16][C][dallas.temp.sensor:029]: Dallas Temperature Sensor: [10:07:16][C][dallas.temp.sensor:034]: Address: 0x9c800000036f0b28 (DS18B20) [10:07:16][C][dallas.temp.sensor:035]: Resolution: 12 bits [10:07:16][C][dallas.temp.sensor:036]: Update Interval: 3.0s [10:07:16][C][dallas.temp.sensor:029]: Dallas Temperature Sensor: [10:07:16][C][dallas.temp.sensor:034]: Address: 0x85800000039a9f28 (DS18B20) [10:07:16][C][dallas.temp.sensor:035]: Resolution: 12 bits [10:07:16][C][dallas.temp.sensor:036]: Update Interval: 3.0s [10:07:16][C][captive_portal:088]: Captive Portal:
[10:07:16][C][mdns:116]: Hostname: temp-sensor-x3 [10:07:16][C][esphome.ota:073]: Over-The-Air updates: [10:07:16][C][esphome.ota:074]: Address: temp-sensor-x3.local:8266 [10:07:16][C][esphome.ota:075]: Version: 2 [10:07:16][C][esphome.ota:078]: Password configured [10:07:16][C][safe_mode:018]: Safe Mode: [10:07:16][C][safe_mode:019]: Boot considered successful after 60 seconds [10:07:16][C][safe_mode:021]: Invoke after 10 boot attempts [10:07:16][C][safe_mode:022]: Remain in safe mode for 300 seconds [10:07:16][C][api:139]: API Server: [10:07:16][C][api:140]: Address: temp-sensor-x3.local:6053 [10:07:16][C][api:142]: Using noise encryption: YES [10:07:17][D][dallas.temp.sensor:054]: 'temperature2': Got Temperature=25.1°C [10:07:17][D][sensor:093]: 'temperature2': Sending state 25.12500 °C with 1 decimals of accuracy [10:07:17][D][dallas.temp.sensor:054]: 'temperature1': Got Temperature=25.8°C [10:07:17][D][sensor:093]: 'temperature1': Sending state 25.81250 °C with 1 decimals of accuracy [10:07:18][D][dallas.temp.sensor:054]: 'temperature3': Got Temperature=25.4°C [10:07:18][D][sensor:093]: 'temperature3': Sending state 25.37500 °C with 1 decimals of accuracy [10:07:20][D][dallas.temp.sensor:054]: 'temperature2': Got Temperature=25.1°C [10:07:20][D][sensor:093]: 'temperature2': Sending state 25.12500 °C with 1 decimals of accuracy [10:07:20][D][dallas.temp.sensor:054]: 'temperature1': Got Temperature=25.8°C [10:07:20][D][sensor:093]: 'temperature1': Sending state 25.81250 °C with 1 decimals of accuracy [10:07:21][D][dallas.temp.sensor:054]: 'temperature3': Got Temperature=25.4°C [10:07:21][D][sensor:093]: 'temperature3': Sending state 25.37500 °C with 1 decimals of accuracy [10:07:23][D][dallas.temp.sensor:054]: 'temperature2': Got Temperature=25.1°C [10:07:23][D][sensor:093]: 'temperature2': Sending state 25.12500 °C with 1 decimals of accuracy [10:07:23][D][dallas.temp.sensor:054]: 'temperature1': Got Temperature=25.8°C [10:07:23][D][sensor:093]: 'temperature1': Sending state 25.75000 °C with 1 decimals of accuracy [10:07:24][D][dallas.temp.sensor:054]: 'temperature3': Got Temperature=25.4°C [10:07:24][D][sensor:093]: 'temperature3': Sending state 25.43750 °C with 1 decimals of accuracy [10:07:26][D][dallas.temp.sensor:054]: 'temperature2': Got Temperature=25.1°C [10:07:26][D][sensor:093]: 'temperature2': Sending state 25.12500 °C with 1 decimals of accuracy [10:07:26][D][dallas.temp.sensor:054]: 'temperature1': Got Temperature=25.8°C
Makin-Things
commented
5 months ago Yes, I missed the setup call and it seems that it only matters in some cases. This change was tested by several people on various platforms with no issues found (including people that couldn't use the previous version of the component). If more people would test beta releases, issues like this would be much more likely to be found. Test out this branch that has several fixes and works for several people that have been having issues:
external_components: - source: type: git url: https://github.com/ssieb/esphome ref: onewire components: [ gpio ] refresh: 1minLet me know if you see anything other than 0 retries in the config logging.
This has worked for me on an ESP32 GPIO15. I will politely point out that this issue was opened against the BETA version a number of days before the release.
gabest11
commented
5 months ago Did not work for me on 2 ESP8266 GPIO2
https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/ Best Pins to Use – ESP8266
GPIO2 is connected to the LED and also needs to be HIGH to boot.
GPIO 4, 5, 12, 13, 14 (or even TX if you do not have debug output) are the safest pins to use.
I will mess around a bit with ESP8266 after coffee.
ssieb
commented
5 months ago I will politely point out that this issue was opened against the BETA version a number of days before the release.
Yes, but this issue was only discovery not working for one person and even then, the sensors were still reading correctly. And there was a workaround to retry the discovery.
gabest11
commented
5 months ago @ssieb this->retries++ < 5 is always evaluated when this->devices.empty() is true. In other words, the incrementing does not stop at 5, it just returns false (until it rolls over. then it searches again).
Works on GPIO2 with ESP8266 D1 mini.
[09:50:15][C][gpio.one_wire:027]: GPIO 1-wire bus:
[09:50:15][C][gpio.one_wire:028]: 0 retries required
[09:50:15][C][gpio.one_wire:029]: Pin: GPIO2
[09:50:15][C][gpio.one_wire:080]: Found devices:
[09:50:15][C][gpio.one_wire:082]: 0xcb3ce10457b8ba28 (DS18B20)
[09:50:15][C][gpio.one_wire:027]: GPIO 1-wire bus:
[09:50:15][C][gpio.one_wire:028]: 97476 retries required
[09:50:15][C][gpio.one_wire:029]: Pin: GPIO4
[09:50:15][W][gpio.one_wire:078]: Found no devices!Can't really find any problems with this, tried all possible pins, even TX, or multiple sensors on the bus.
crossbreed3
commented
5 months ago Hi can anyone please share a snippet of the yaml file, im not coming right in the configs. only got my first sensor yesterday, with my luck it was the day the internet broke. i dont know how to implement the external component and if any changes are needed from this to the rest of the code.
Using ESP32 Wroom Dallas Sensor on GPIO14
1) where to place "external component" line 2) one_wire configs 3) sensor configs.
Thanks
gabest11
commented
5 months ago external_components:
- source: github://ssieb/esphome@onewire
# - source: github://gabest11/esphome@one_wire # with fixed retry counting
components: [ gpio ]
refresh: 1min
one_wire:
- platform: gpio
pin: GPIO14
id: one_wire_on_gpio14
sensor:
- platform: dallas_temp
one_wire_id: one_wire_on_gpio14
name: "Temperature"
# address: 0x... # only needed if you have more than one
The problem
I've been successfully using a Dallas onewire temperature sensor on my ESP8266 boards for quite a while, but after upgrading from 2024.5.x to 2024.6.x (beta) and updating the config, my sensor is no longer detected. I've been using automatic discovery as I only have a single sensor hooked up to a single GPIO, and now I have to explicitly specify the address of the sensor (which I got from seeing what was discovered in 2024.5.5). As you can see the in the config below, I was using
index: 0in my older working config, but I don't see a way to specify that in the new one. Explicitly specifying the address of the sensor works, though.The release notes from the PR imply that discovery should work and that
indexis no longer required:Which version of ESPHome has the issue?
2024.6.0b2
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
2024.6.2
What platform are you using?
ESP8266
Board
nodemcu
Component causing the issue
one_wire
Example YAML snippet
I had the following snippet working find for a long time on 2024.5.x and prior ESPHome versions:
I modified the config to work with 2024.6.x beta and simplified it a bit, but it no longer detects my onewire sensor:
When I add
address: 0x480000006a42a528, it detects the sensor and reports correct data. I was specifyingindex: 0in the original config, as either that oraddresswas required, but I don't see a way to specifyindex: 0in the new config.Anything in the logs that might be useful for us?
2024.6.0b2 not working:
2024.5.5 working:
Additional information
No response