Closed ChrisOboe closed 3 years ago
I don't have any issue with i2c, but I have a feeling you have have a problem with it's stability - do you have pull-up resistors on i2c bus?
I don't know. It's pre-build hardware and there is no electrical wiring diagram available. Also i'm not able to measure it directly, since the smd parts are just too small (at least for the tools i have available). And i don't know other ways how i could find this out.
Also it's not random. I can always reproduce this. It works correctly after the ota update (and i tested it about 20 times). And it never works without it. Also when it works via the update, it works fine for at least an hour (i never tested it longer).
I think, when it would be a general stability issue, it would be more random.
I have exactly same problem. Changing i2c speed, delaying boot not helped. Only work after OTA, till next button reset or power down.
[V][esp32-hal-i2c.c:1484] i2cInit(): num=0 sda=25 scl=26 freq=0 [V][esp32-hal-i2c.c:1680] i2cSetFrequency(): freq=100000Hz [V][esp32-hal-i2c.c:1696] i2cSetFrequency(): cpu Freq=240Mhz, i2c Freq=100000Hz [V][esp32-hal-i2c.c:1704] i2cSetFrequency(): Fifo delta=1 [W][esp32-hal-i2c.c:1411] i2cCheckLineState(): invalid state sda(25)=0, scl(26)=0 [E][esp32-hal-i2c.c:1426] i2cCheckLineState(): Bus Invalid State, TwoWire() Can't init sda=0, scl=0
in the log of Here is the log after i power off the device and power it on again: There is a error in your Bus: [E][esp32-hal-i2c.c:1426] i2cCheckLineState(): Bus Invalid State, TwoWire() Can't init sda=0, scl=0
Maybe this is a similar problem like this one: _ESPHome puts SHTC3 sensors to sleep between measurements. While asleep the sensor will only respond to a wake up command. All other commands, including a soft reset are ignored (it even ignores an I2C general call reset). This is problematic if ESPHome is rebooted between measurements, since the sensor will still be asleep when it tries to set it up again after the reboot. For example, doing an OTA update will usually cause the sensor to remain "failed" until power is cycled, because the OTA process will reboot while the sensor is still asleep.
So the trivial fix to this is to send a wake up command during setup() before anything else to make sure it's awake. For me, this fixes SHTC3 sensors "failing" after most OTA updates._ https://github.com/esphome/esphome/pull/993
for the SHTC3 it works adding wake_up in the setup() in the file esphome/components/shtcx/shtcx.cpp
void SHTCXComponent::setup() { ESP_LOGCONFIG(TAG, "Setting up SHTCx..."); ESP_LOGCONFIG(TAG, "Setting up SHTCx..."); this->wake_up(); this->soft_reset(); this->soft_reset();
if (!this->writecommand(SHTCX_COMMAND_READ_ID_REGISTER)) { if (!this->writecommand(SHTCX_COMMAND_READ_ID_REGISTER)) {
but in your component this is missing? @ChrisOboe maybe you can try to edit to something like this: https://github.com/esphome/esphome/blob/dev/esphome/components/shtcx/shtcx.cpp Your component: https://github.com/esphome/esphome/blob/dev/esphome/components/bh1750/bh1750.cpp
Is this a component that sleeps like the shtc3?
Ohh, happy to see I'm not alone with the problem. Using the same LilyGO TTGO-HiGrow board. Original Arduino code is working fine with all sensors. dht11 and moisture/salt are working with esphome. But can not make i2c and bh1750 to work with esphome:(
If it helps ... when trying to make blank arduino sketch just for bh1750, I found that the initialization will fail unless I have previous attempt of bme280 init (which I don't have even connected to the board).
#include <Wire.h>
#include <BH1750.h>
#include <Adafruit_BME280.h>
#define POWER_CTRL 4
#define I2C_SDA 25
#define I2C_SCL 26
BH1750 lightMeter(0x23); //0x23
Adafruit_BME280 bmp; //0x77
void setup() {
Wire.begin(I2C_SDA, I2C_SCL);
Serial.begin(115200);
pinMode(POWER_CTRL, OUTPUT);
digitalWrite(POWER_CTRL, 1);
delay(1000);
if (!bmp.begin()) {
Serial.println(F("Could not find a valid BMP280 sensor, check wiring!"));
}
if (lightMeter.begin(BH1750::CONTINUOUS_HIGH_RES_MODE)) {
Serial.println(F("BH1750 Advanced begin"));
} else {
Serial.println(F("Error initialising BH1750"));
}
}
e.g. in the above code, w.out bmp.begin the lightMeter always ends up with error. If I do bmp.begin (which gives error) then lightMeter gives the 'Advanced begin' .
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
here you go guys. solved it! :D
it seems that the power line for the sensors doesn´t get enough power.
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Docker
ESP (ESP32/ESP8266, Board/Sonoff):
ESP32. It's a liligo tt-higrow (https://github.com/Xinyuan-LilyGO/TTGO-HiGrow)
Affected component:
i2c/bh1750
Description of problem: The bh1750 only works directly after an ota update. It does not work under following conditions:
Problem-relevant YAML-configuration entries:
The YAML is shortened to the relevant parts.
Logs (if applicable):
Here is the run after the ota update:
Here is the log after i power off the device and power it on again:
Additional information and things you've tried: I tried a lot of different stuff in the last two days.
Switching between different arduino frameworks did not help.
Changing the frequency of the i2c bus did not help either.
Also i naively thought that maybe the startup is too fast and it tries to communicate with the bh1750 and the bh1750 is not powered (i don't know a lot about electronics and don't know how this device is wired). This would explain that it works after an ota update but not after an power cycle.
I tested my assumption with adding a long delay on the boot (before i2c gets initialized) so enough time is there that the bh1750 is powered. But it still did not work. So my assumption was wrong.
I also searched a lot about simliar issues with the esp32 and the i2c and tested everything that was proposed, but nothing helped.
I'm running out of ideas what to try. But i'm still pretty optimistic to get it running, since it definetly works fine after an ota update.
Thats why i'm writing this issue, in the hope that we can get this running.