Difference between Onewire lib and espeasy onewire

[dredrash]

Hello, i have 10 ds18b20 connected to D4(GPIO2) on ESP8266, but when i try to add them as devices in field "Device Address: " there is nothing. But when i flash a sketch with a simple search function using OneWire and Dallas libs every sensor is found.
My question is about the difference between the lib and the plugin in espeasy. I checked the code and there is a minuscule difference between the search functions .

[TD-er]

Can you show this "minuscule difference" ?

[dredrash]

in espeasy code is used digitalWrite() digitalRead() and pinMode() while in onewire is used definitions i didn't find any other difference . i have replaced search() callings in the plugin's code with the original Class OneWire from OneWire lib, and now it can find them and is working as it suppose to be. And even stranger the problem is only with the search it self not with calling each device by address and reading the date from it, i tried to trace the problem and it fails at

Code: Select all

 
 // check for no devices on 1-wire
      if ((id_bit == 1) && (cmp_id_bit == 1)) {
        break;
      }
      

On Onewire lib is the same think but is working fine.

I know that generally the plugin is working fine i'm using it in other projects, and that why it was strange for me where is the difference.

[TD-er]

GPIO-2 is normally pulled up during boot, so maybe the (extra) pull up resistor for this is having an effect?
The ESP also has an internal pull up resistor and thus you should also check the init routine of the test library that is working.
Apart from that, an extra pull up resistor may also have an effect on the max. rise- and fall time for electric signals so timing may become more critical.

[ThomasB]

@TD-er: Agreed. The one-wire bit timing and logic levels are critical and can be affected by poorly chosen pullup values. Sensor cable length affects it too, so when trouble occurs the sensors should be directly connected (no cable) to allow debugging. After it is working the longer cable can be re-installed.

@dredrash: If changing the GPIO pin (with recommended 4.7K pull-up) does not help then I suggest you start with just one DS18B20 sensor. Then add one at a time until the plugin stops working. What you observe might help identify a firmware bug or hardware problem.

Keep in mind that the pull-up value may need to be revised to support your ten sensors. With multiple sensors I think you will find that very short cables are best.

i tried to trace the problem and it fails at:
if ((id_bit == 1) && (cmp_id_bit == 1)) {
break;
}

This could be caused by the GPIO issue already discussed. But it's useful to note that the Arduino library uses slightly different timing in its read_bit() function. And unlike the plugin, the Arduino library disables interrupts to protect the critical bit timing. So there is the possibility that these differences are involved with the problem.

- Thomas

[dredrash]

Thank you, I think you are right I'm using long cables with many branches so I decreased the pullup resistor to 2.2k, as I said i have included directly Onewire lib to the plugin's code and its fine , because now the plugin is working as usual.

[ThomasB]

as I said i have included directly Onewire lib to the plugin's code and its fine , because now the plugin is working as usual.

Glad to know you have it working with your modified code.

It would be helpful to try the new pull-up value with the unmodified ESPEasy firmware (latest Mega version). If it fails at the same place then that would indicate that the plugin's read_bit() timing is not optimized. And a problem like that should be reported to the developers.

- Thomas

[dredrash]

thank you for your suggestion, i will check that as soon as i can.