A simple answer was given. In fact, it was the best answer, because if you follow that advice you can help yourself next time. It is a fact that many users don’t read logs or changelogs — and this thread once again proved that. There’s nothing berating about that. The problem was already solved by the third post.
I read everything you said, but look at the first two posts again: neither poster gave any indication as to their skill level. Just say: “I copy-pasted this originally and I don’t understand all of it. Please help.” Without context those of us trying to help can’t guess. Skill levels across the forum vary drastically.
Whilst it certainly feels that’s what it is when you are that people in the haze, desperate for a working solution, I don’t think any ill-intent was meant.
But maybe it’s the ‘engineer’ or IT Trainer in me that when I see people falling into the same hole over an over, I don’t assume they are all slow or lazy but that there could be an opportunity to help or make things easier for them?
Luckily (for many of us), systems do evolve, generally making things easier for those who aren’t ‘technical’ or have all the skills, time, experience or interest to get their hands fully dirty. I have see this with Linux where it was nearly impossible for me to get a working Linux PC to where it’s often no more difficult than creating the boot media. HA has also evolved, moving more and more things out of .yaml and into the GUI, possibly to the frustration of those who enjoy that level of ‘control’?
So thank you for your support and insight on how this issue panned out.
Luckily I have been in the field of IT and IT Support long enough to see that not all of us are cut out to be true ‘givers’. 
1 Like
+1 to this.
1 Like
Oh, of course and I’m not taking away the responsibility for all to try to do their best to make it as easy as possible for others to help us.
But sometimes it can be difficult to know where to start, especially if you aren’t doing this sort of thing every day and it is sad where people (and I can confirm I am one of these people) who might avoid asking a question here, because of the sort of expectation of some.
I would rather randomly Google, just ignore the issue or go without something and I’m pretty sure it’s not supposed to be that way.
So for me it was ‘This is what seems to now be an issue (when it hasn’t been for several years previously with the exact same code, and here is the code …) is this known, is there a fix and if so how please’ sort of thing.
I had tried to find the changelog and even if I had (and did after Nick pointed it out), it didn’t help at all.
It looks like it didn’t work because it wasn’t just the addition of the ‘allow_other_uses: true’ line but the code around it had to be in the right format?
I have spent days trying to sort some code I’d copied/ pasted / hacked to suit my needs and getting nowhere, only to have my coding mate glance at it for the first time over Teamviewer and get it working within seconds! (WTF!).
FWIW I try to watch the HA launch parties on Youtube and do try to take note on things that are added, removed, moved into the GUI or broken but whilst I would love to spend 100% of my time ‘playing’ with HA, I’m also a full time carer for my Wife with with dementia.
3 Likes
I am an update cowboy. I push the button and hope for the best. But when something goes wrong, I’ve learnt to…
Read the release notes 
3 Likes
But what if that doesn’t help, what do you do then?
Recap. A Good couple of years ago I assembled a CO2 sensor project using an ESP32 and it has been working ever since. Ironically I think there might have been one previous ‘breaking change’ (that I mentioned here) that I fixed.
Yesterday I applied the latest ESPHome update and then Updated All my 17 online ESP devices. all went though fine except for the CO2 sensor.
After not doing any level of code work on HA for a good while (maybe a year) I had to try to see what it was having an issue with and Googled a few variants of the errors in the hope I would come across a fix, I didn’t. I tried to find the changelog but couldn’t.
I posted here and was directed to the changelog (and a bit of RTFM) but because there was no example of the new ‘allow_other_uses: true’ in the pin_schema examples, I wasn’t sure how I would use it in my code.
I tried it many ways, with indentation, without and because I don’t ‘understand’ code / coding rules, I was reliant of the ESPHome editor to prompt re what was wrong. Nothing that came back helped at all.
So I think I now understand (only ‘think’ mind) it also needed the pin code to be set out in a specific way, not just the inclusion of another line.
Now, whilst I’m not coder I was able to isolate the cause of the issue (duplicate pin allocation) and remove one of the duplications, because (as it happens), it wasn’t something I was using anyway, the display backlight on/off toggle.
So that’s all I was really interested in and that is something that has been part of my life as a support tech (the customer just wants the stuff fixed and working, you don’t always get time to play and learn ‘why’ or what went wrong, only maybe if it starts appearing more often).
So my CO2 sensor then updated, I move onto something else and may not touch any more … or have to do code update faultfinding for another year …
4 Likes
Still asking why do you want to use three different I2C id’s on the same pins? That doesn’t make sense and is not necessary to connect multiple I2C devices. In terms of hardware you are now using just one I2C bus with three different names, so that’s a lot of unnecessary ‘overhead’ in your yaml (and generated C++ code). Your solution makes the yaml complex to read. For inspiration some code I use for an ESP8266 with a I2C BME280 (temperature, humidity and Air pressure) sensor and a I2C Oled screen attached.
i2c:
sda: D1
scl: D2
frequency: 800kHz
sensor:
- platform: bme280
address: 0x76
temperature:
name: "Temperature"
id: temp
humidity:
name: "Humidity"
id: hum
accuracy_decimals: 1
pressure:
name: "Pressure"
id: pres
update_interval: 60s
display:
- platform: ssd1306_i2c
model: "SSD1306 128x64"
address: 0x3C
update_interval: 60s
lambda: |-
it.printf(0, 0, id(my_font), "Temp: %6.1f", id(temp).state);
it.printf(0, 20, id(my_font), "Hum : %6.1f", id(hum).state);
it.printf(0, 40, id(my_font), "Pres: %6.1f", id(pres).state);
font:
- file: "fonts/DejaVuSansMono.ttf"
id: my_font
size: 17
1 Like
On the esp module I have, I have 2 INA219’s connected to the I2C pins as well a temp, humidity, barometric pressure sensor. I’ll try and abbreviate it as much as possible here so as not to take up too much space, but the main code is as follows:
i2c:
- id: bus_a
sda:
number: GPIO4
allow_other_uses: true
scl:
number: GPIO5
allow_other_uses: true
scan: true
- id: bus_b
sda:
number: GPIO4
allow_other_uses: true
scl:
number: GPIO5
allow_other_uses: true
scan: true
- id: bus_c
sda:
number: GPIO4
allow_other_uses: true
scl:
number: GPIO5
allow_other_uses: true
scan: true
frequency: 200kHz
seonsor:
- platform: aht10
i2c_id: bus_c
address: 0x38
temperature:
id: ${sen_id}b_temperature
name: "${sen_name}b Temperature"
unit_of_measurement: °C
accuracy_decimals: 2
filters:
- calibrate_linear:
- 07.50 -> 07.40
- 09.50 -> 09.40
- 11.50 -> 11.40
- 13.50 -> 13.40
- 15.50 -> 15.40
- 17.50 -> 17.40
- 19.50 -> 19.40
- 21.50 -> 21.40
- 23.50 -> 23.40
humidity:
id: ${sen_id}_humidity
name: "${sen_name} Humidity"
unit_of_measurement: "%"
icon: mdi:water-percent
accuracy_decimals: 2
update_interval: ${update_time}
- platform: ina219
i2c_id: bus_a
address: 0x40
shunt_resistance: 0.0039132 ohm
update_interval: ${update_int}
bus_voltage:
id: ${sen_id}b_bus_voltage
name: "${sen_name}b Bus Voltage"
unit_of_measurement: "V"
accuracy_decimals: 3
device_class: voltage
icon: mdi:alpha-v-circle-outline
filters:
- throttle_average: ${avg}
etc, etc.
- platform: ina219
i2c_id: bus_b
address: 0x41
shunt_resistance: 0.003742 ohm
update_interval: ${update_int}
bus_voltage:
id: ${sen_id}s_bus_voltage
name: "${sen_name}s Bus Voltage"
unit_of_measurement: "V"
accuracy_decimals: 3
device_class: voltage
icon: "mdi:alpha-v-circle-outline"
filters:
- throttle_average: ${avg}
etc, etc.
The board is the Sonoff SV which has limited amount of pins that can be used (5 if memory serves correctly), and this was the only way I could accommodate all the sensors, reed switches, external backlight LED etc.
If you have a suggestion to streamline the code down some, I would be most appreciative, as this specific nodes code is in the late 650 lines already, and from what I can tell, the 8266 is sometimes struggling with flashing over WiFi as it is most likely extremely busy in the background doing all the calculations it has been forced to do 
Just a note, I am “That” person that buys a D1 Mini and “Finds” uses for ALL the pins so that I don’t have 100 of them doing just one task 
.
Would anyone know what the solution is for where the sensor is “platform: adc” , as the “allow_other_uses: true” whilst working for pulse_meter and pulse_counters etc doesn’t work for “adc”.
ADC usage example below, the same PIN is used to read a pressure sensor and from that create sensors for the voltage of the physical sensor and then from that the water pressure in psi and kpi, and from that water tank levels, % an litres are then calculated.
# ADC Input Port 3 - 0-5V
- platform: adc
pin: 35
name: 'Water Tank - Voltage'
id: water_tank_voltage
accuracy_decimals: 3
device_class: "voltage"
state_class: "measurement"
unit_of_measurement: "V"
update_interval: 5s
attenuation: 11db #auto
filters:
# - multiply: 3.3
- median:
window_size: 6
send_every: 6
send_first_at: 6
# - calibrate_polynomial:
# degree: 2
# datapoints:
# # Map from SENSOR -> TRUE value
# - 4.15867 -> 4.01667
# - 3.75700 -> 3.61500
# - 3.35533 -> 3.21333
# - 2.95367 -> 2.81167
# - 2.55200 -> 2.41000
# - 2.15033 -> 2.00833
# - 1.74867 -> 1.60667
# - 1.34700 -> 1.20500
# - 0.94533 -> 0.80333
# - 0.14200 -> 0.00000
internal: true
# sensor:
- platform: adc
pin: 35
name: 'Water Tank - Pressure (kPa)'
id: water_tank_pressure_bar
accuracy_decimals: 2
device_class: pressure
state_class: "measurement"
unit_of_measurement: kPa
icon: "mdi:gauge"
update_interval: 5s
attenuation: 11db #auto
filters:
# - multiply: 3.3
- median:
window_size: 6
send_every: 6
send_first_at: 6
- calibrate_linear:
# Measured value of X volt maps to y kPa
- 4.15867 -> 23.6061428 # 100%
- 3.75700 -> 21.2455285 # 90%
- 3.35533 -> 18.8849142 # 80%
- 2.95367 -> 16.5243 # 70%
- 2.55200 -> 14.1636857 # 60%
- 2.15033 -> 11.8030714 # 50%
- 1.74867 -> 9.44245712 # 40%
- 1.34700 -> 7.08184284 # 30%
- 0.94533 -> 4.72122856 # 20%
- 0.54367 -> 2.36061428 # 10%
- 0.14200 -> 0.0 # 0%
# From https://www.sensorsone.com/liquid-level-to-pressure-calculator/?lval=241&lunit=centimetres+%28cm%29&lfctr=cm&sg=1&grav=9.79508&punit=kilopascals+%28kPa%29&pfctr=kPa
# Gouburn 655m - Local Gravity 9.79508 ms-2
internal: true
- platform: adc
pin: 35
name: 'Water Tank - Pressure (psi)'
id: water_tank_pressure_psi
accuracy_decimals: 2
device_class: pressure
state_class: "measurement"
unit_of_measurement: psi
icon: "mdi:gauge"
update_interval: 5s
attenuation: 11db #auto
filters:
# - multiply: 3.3
- median:
window_size: 6
send_every: 6
send_first_at: 6
- calibrate_linear:
# Measured value of X volt maps to y PSI
- 4.15867 -> 3.42378155 # 100%
- 3.75700 -> 3.08140339 # 90%
- 3.35533 -> 2.73902524 # 80%
- 2.95367 -> 2.39664708 # 70%
- 2.55200 -> 2.05426893 # 60%
- 2.15033 -> 1.71189077 # 50%
- 1.74867 -> 1.36951262 # 40%
- 1.34700 -> 1.02713446 # 30%
- 0.94533 -> 0.68475631 # 20%
- 0.54367 -> 0.342378155 # 10%
- 0.14200 -> 0.0 # 0%
# https://www.sensorsone.com/liquid-level-to-pressure-calculator/?lval=241&lunit=centimetres+%28cm%29&lfctr=cm&sg=1&grav=9.79508&punit=kilopascals+%28kPa%29&pfctr=kPa
internal: true
2 Likes
On a single I2C bus you can connect 128 devices by just using 2 pins, as long as all the devices have unique addresses. However I don’t think you should try that on a single ESP8266 
To avoid the flashing problems due to a busy ESP, you could add a safe mode reboot button Safe Mode Button — ESPHome and trigger that button from HA before you do start flashing the device.
Looking at your yaml, I would strip all the fuzz from the i2c section and remove the i2c_id’s from the device sections. You only need these ID’s is you are using more than one I2C bus. But your are using an ESP8266 and that has only one I2C bus
Here your updated yaml:
i2c:
sda: GPIO4
scl: GPIO5
scan: true
frequency: 200kHz
seonsor:
- platform: aht10
# You don't need this line anymore ---> i2c_id: bus_c
address: 0x38
temperature:
id: ${sen_id}b_temperature
name: "${sen_name}b Temperature"
unit_of_measurement: °C
accuracy_decimals: 2
filters:
- calibrate_linear:
- 07.50 -> 07.40
- 09.50 -> 09.40
- 11.50 -> 11.40
- 13.50 -> 13.40
- 15.50 -> 15.40
- 17.50 -> 17.40
- 19.50 -> 19.40
- 21.50 -> 21.40
- 23.50 -> 23.40
humidity:
id: ${sen_id}_humidity
name: "${sen_name} Humidity"
unit_of_measurement: "%"
icon: mdi:water-percent
accuracy_decimals: 2
update_interval: ${update_time}
- platform: ina219
# You don't need this line anymore ---> i2c_id: bus_a
address: 0x40
shunt_resistance: 0.0039132 ohm
update_interval: ${update_int}
bus_voltage:
id: ${sen_id}b_bus_voltage
name: "${sen_name}b Bus Voltage"
unit_of_measurement: "V"
accuracy_decimals: 3
device_class: voltage
icon: mdi:alpha-v-circle-outline
filters:
- throttle_average: ${avg}
etc, etc.
- platform: ina219
# You don't need this line anymore ---> i2c_id: bus_b
address: 0x41
shunt_resistance: 0.003742 ohm
update_interval: ${update_int}
bus_voltage:
id: ${sen_id}s_bus_voltage
name: "${sen_name}s Bus Voltage"
unit_of_measurement: "V"
accuracy_decimals: 3
device_class: voltage
icon: "mdi:alpha-v-circle-outline"
filters:
- throttle_average: ${avg}
etc, etc.
1 Like
Oh, awesome, and thank you for the explanation. This does indeed streamline the whole I²C
It makes life so much simpler (and neater) not having all this unnecessary code in place.
Was also just refreshing my memory on the bus id and went to the I²C esphome pages and noticed it mentions “id (Optional*, ID): Manually specify the ID for this I²C bus if you need multiple I²C buses”.
Would be nice if they just throw in a mention that if multiple sensors on the same I²C bus are used, that you don’t need the bus id as you pointed out in your example.
ps. As I mentioned, I’m one of those that would actually attempt the 128 x I²C sensors just to see how much it crippled the poor node 
You say “I don’t understand the release notes”
The issue is none of the “release notes” talk about broken changes and how to correctly fix them. This is yet the 3rd time a “documented” change has occurred and the ESPHome language has drastically changed resulting in these questions. Having your comment sure doesn’t seem to assist verses MAYBE you look at someones code and guide them WHY those changes need to occur in those specific areas.
1 Like
If that’s the case, why not?
The thing is, most improvement / progress come not from those accepting the status quo but those questioning it.
Many of the main Linux dristros have very Windows-like GUIs, have brought things that were once CLI only into the GUI and now we get things like the Windows Control Panel, meaning the need to do the geeky CLI stuff become reduced. This in turn means that more ‘ordinary people’, people who wouldn’t have the skills to fully consider the implications of the release notes, rarely have to read them.
Nabu Casa and all the devs there and in their homes have put loads of effort into ‘automating’ and simplifying HA as much as possible, reducing the need for ‘ordinary users’ to have to open file editors and get involved in editing .yaml, simply to be able to use HA as the appliance many want / need it to be.
That way, it doesn’t matter how deep down the release note rabbit hole you might previously needed to dive because now it ‘just works’ or if it might break, it’s either fixes it for you or makes it very clear why and what needs some manual intervention.
1 Like
I agree. The user needs an explanation on how to fix the problem because he is the user and not the programmer.
I will give one example of the recent ESPHome update 2023.12(1,2,3)
Internal Touch Screen Changes. The link there doesn’t tell you anything. The XPT2046 settings documentation has not changed and yet the esp cannot be compiled and when you remove the problematic lines of code the button touch does not agree. The question is which documentation should I look at?
2 Likes
Just stumbled upon this threat after updating. Could someone help me understand how to improve the following code, or is using GPIO12 not a problem in this case?
sensor:
- platform: pulse_counter
pin:
number: GPIO12
allow_other_uses: true
update_interval: 6s
name: "water pulse"
id: water_pulse
- platform: pulse_meter
pin:
number: GPIO12
allow_other_uses: true
name: "Water Pulse Meter"
unit_of_measurement: "liter/min"
icon: "mdi:water"
total:
name: "Water Meter Total"
unit_of_measurement: "m³"
id: water_meter_total
accuracy_decimals: 3
device_class: water
state_class: total_increasing
filters:
- multiply: 0.001
- platform: template
name: "Water Usage Liter"
id: water_flow_rate
accuracy_decimals: 1
unit_of_measurement: "l/min"
icon: "mdi:water"
lambda: return (id(water_pulse).state * 10);
update_interval: 6s
device_class: water
Looks ok I think. Does it work?
But why do you need both pulse counter and pulse meter? The pulse meter gives you both liter/min and m3, so what are you doing with the number of pulses (pulse counter).
I also have the problem for days with the error message!
Unfortunately I can’t fix it by adding (allow_other_uses: true)
This gives me a new error message
