search

letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.28k stars 2.21k forks source link

P051_AM2320 not working (and other issues) with 2.5.x ESP8266 library and 2.7.x core #3160

Closed pm-cz closed 1 year ago

pm-cz commented 4 years ago

Summarize of the problem/feature request

The esp8266 library espressif8266@2.5.0 and espressif8266@2.5.2 together with core library version of 2.7.1 and 2.7.0 cause problems at least with AM2320 sensor (I suspect also problems with ADS1115 providing incorrect measurements off-and-on, maybe related to #3159, but I am not sure as it can also be a wiring issue), and I2C scan.

After downgrading in platformio build script to espressif8266@2.4.0 and core library 2.6.3 the sensor starts to work again (on the other hand, upgrading to core 2.7.2 with espressif8266@2.5.3 did not help).

Expected behavior

Retreive AM2320 measurement data as in mega-20200426 and earlier. In serial log, this is displayed as: Info : AM2320: Temperature: 27.60 Info : AM2320: Humidity: 49.10

Actual behavior

Serial log for broken versions:

Steps to reproduce

  1. Install one of the stock affected version bin files
  2. Connect AM2320 over I2C
  3. Do an I2C scan/setup AM2320

System configuration

Hardware: ESP8266: ESP-12F, NodeMCU

TD-er commented 4 years ago

I don't have such a sensor here, so I cannot test it.

Do you have other I2C sensors or displays that could be used here to test? Also please make sure to do a cold boot when testing such issues or else you may be drawing wrong conclusions on what core library may be working and what not, while it may be something like a configured pull-up resistor or something similar.

ghtester commented 4 years ago

I had an issue with AM2320 connected to the same i2c bus together with LCD2004 (=PCF8574). In this case I had to decrease the i2c clock speed from default 400000 to 200000. LCD2004 was working alone and together with AM2320 at clock 400000, AM2320 was working alone with clock 400000 but did not work at this speed together with LCD2004. And yes I tried to struggle with pull-up resistors and Vcc voltage (at PCF8574 board there are pull ups). After decreasing clock speed to 200000 both devices started working together.

v-a-d-e-r commented 4 years ago

I have (or better had) that sensor. It is crap! I had also a lot of trouble with it. Someone wrote me: AM2320 wake-up sequence is not exactly following i2c standard! So in the wake-up sequence, the device is not acknowledging the slave address.

pm-cz commented 4 years ago

It is possible the I2C speed/init sequence is the culprit, but this may also influence some other devices if I2C is on max speed by default for some reason.

Anyway I have of course cold-booted the device, tested everything possible. For old firmwares up to mega-20200426 it works and from mega-20200515 it does not. I have checked the changes and the SDK change is really the culprit.

Just to make sure, I have tested it with 3 AM2320s, 2 different connection cables and 3 separate different devices of two types as mentioned above. The fix for me was the downgrade, but if there is some change in the I2C default in the library, it may cause issues with other modules. I will check if the core/esp8266 version rollback has any influence on ADS1115 behvior tomorrow (I would rather not flash it remotely).

EDIT: Also, in the first setup, there were several devices on I2C bus, but for the testing itself, the test was bare-bone, just NodeMCU and the single I2C sensor, nothing else was configured (not even any controller).

TD-er commented 4 years ago

Well there have been some changes in the core libs regarding I2C recently. So it is not that surprising reverting the core to a different version may fix these issues.

We do have a field in the settings to force the I2C clock frequency. I'm not 100% certain adding this setting may also have changed the default clock speed. But as far as I know, if you had the OLED Framed plugin active, it would always have set the I2C clock speed to 400 kHz. Well it forces it to 700, but it would be auto limited to 400 as that's the highest on ESP8266.

Maybe you can also test a bit with the I2C clock setting in ESPEasy?

pm-cz commented 4 years ago

I don't have any OLED connected right now and do not plan to on those nodes, so I can try to force the bus to be slower before flashing the second firmware.

So far after on hour of testing it looks like decreasing the I2C bus speed to 200000 or 100000 helps, I am also not seeing the strange behaviour of ADS1115 since the change.

So we can probably close this, but maybe a notice on P51 Wiki Help page about the need to switch I2C speed on Hardware tab to 200000 at most should be added. Or alternatively default settings for I2C speed set to this value? Also, it is a question how many other devices this change impacts.

It looks like the SDK increased the possible I2C speed above the threshold the devices are able to process (maybe originally the setting was 400000 but in reality the generated clock speed was lower).

TD-er commented 4 years ago

Hmm that's also a possibility. I will connect a scope to the pins to see what the actual clock frequency is. Not sure if I added a limit on the number field or asked the core to see what it would allow for max. value. It may be possible the limit has indeed been removed in the latest core.

pm-cz commented 4 years ago

The value from the number field is used, otherwise it would not work (and default value I had there is 400000). The question is if the I2C bus really operates on this speed or not.

TD-er commented 4 years ago

The value from the number field is used, otherwise it would not work (and default value I had there is 400000). The question is if the I2C bus really operates on this speed or not.

It could also be that the signal is not really that clean anymore when it arrives at the I2C device. So even though it is sent as 400 kHz, it may not be usable anymore since the time per pulse it is above some threshold voltage may be too short for the device. That's what I tried to explain in my previous post.

pm-cz commented 4 years ago

Yes, that can be it in the complete installation, but the cable I tried to test it with in the single sensor scenario was really short, so distance and attenuation should not have been an issue.

I have also looked in the source code of esp8266/Arduino and they completely reworked the timing delays for emulated I2C communication waits in core_esp8266_si2c.cpp in 2.7.0, so it may actually be that the calculated wait cycles for clocks are off now, exceeding the permitted 400k.

TD-er commented 4 years ago

I did follow the issue about the I2C rewrite and they were very meticulous about the timings, so I doubt it is incorrect. What could be is that the old implementation was a bit slower then the settings suggest. But like I said, I will attach a scope so we can see the timings. I tried a frequency counter I had laying around, but that one only allows for the counts per interval of 1 sec which is completely useless here, so I have to move things around a bit so I can use the scope here.

tonhuisman commented 1 year ago

This plugin has been worked on, and seems to be working, so this issue can be closed.