Sensor DS18b20 and DH11/DH22 not work

[giobbe70]

On Release mega-20191116 Sensor DS18b20 and DH11/DH22 not work,
Its value NaN.

[giobbe70]

[TD-er]

And in what ESPEasy version did it work well?

[giobbe70]

All version on Release 20191116
I have install

  | ESP_Easy_mega-20191116_normal_core_241_ESP8266_4M1M.bin

[giobbe70]

the 20190630 version work well

[TD-er]

Have you used older versions of ESPEasy where it was running well?

For example this is on my breadboard, to which I just flashed the latest code:

[giobbe70]

ESP_Easy_mega-20191003_test_core_260_sdk3_alpha_ESP8266_4M1M.bin
WORK WELL

[TD-er]

The topic title suggests the Dallas sensors also don't work, but like I showed you, they work on my setup.
So if it then both the Dallas sensors and the DHT11/DHT22? Or only the last one?

[giobbe70]

Inglese

IN MY CONFIGURATION WITH THE 20190630 VERSION THE Dallas sensors and the DHT11 / DHT22 WORK WELL. IN NEW VERSIONS FROM SEPTEMBER TO FORWARD DO NOT WORK. THE VALUE IS NaN

[uzi18]

please provide debug log from units where they are connected

I see on screenshot that boiler sensor works, but 2 other sensors are unavailable.

[giobbe70]

64974: EVENT: Clock#Time=Sat,13:43
65860: SW : State 0.00
65863: EVENT: RELE-TERM-SOTTO#Switch=0.00
67861: SW : State 0.00
67862: EVENT: RELE-TERM-SOTTO#Switch=0.00
68171: EVENT: TEMP-PANNELLO#Temperature=38.50
68749: EVENT: TEMP-BOILER#Temperature=78.00
69862: SW : State 0.00
69864: EVENT: RELE-TERM-SOTTO#Switch=0.00
71860: SW : State 0.00
71862: EVENT: RELE-TERM-SOTTO#Switch=0.00
73242: EVENT: TEMP-PANNELLO#Temperature=38.50
73872: SW : State 0.00
73873: EVENT: RELE-TERM-SOTTO#Switch=0.00
74270: EVENT: TEMP-BOILER#Temperature=78.00
75720: DHT : No Reading
75860: SW : State 0.00
75862: EVENT: RELE-TERM-SOTTO#Switch=0.00
77715: WD : Uptime 1 ConnectFailures 0 FreeMem 16456 WiFiStatus 3
77876: SW : State 0.00
77878: EVENT: RELE-TERM-SOTTO#Switch=0.00
78394: EVENT: TEMP-PANNELLO#Temperature=38.50
79860: SW : State 0.00
79862: EVENT: RELE-TERM-SOTTO#Switch=0.00
80096: EVENT: TEMP-BOILER#Temperature=78.00
81860: SW : State 0.00
81862: EVENT: RELE-TERM-SOTTO#Switch=0.00
83474: EVENT: TEMP-PANNELLO#Temperature=38.50
83897: SW : State 0.00
83899: EVENT: RELE-TERM-SOTTO#Switch=0.00
85860: SW : State 0.00
85862: EVENT: RELE-TERM-SOTTO#Switch=0.00
86077: EVENT: TEMP-BOILER#Temperature=78.00
87860: SW : State 0.00
87862: EVENT: RELE-TERM-SOTTO#Switch=0.00
88748: EVENT: TEMP-PANNELLO#Temperature=38.50
89860: SW : State 0.00
89862: EVENT: RELE-TERM-SOTTO#Switch=0.00
91789: EVENT: TEMP-BOILER#Temperature=78.00
92006: SW : State 0.00
92008: EVENT: RELE-TERM-SOTTO#Switch=0.00
93713: EVENT: TEMP-PANNELLO#Temperature=38.50
93931: SW : State 0.00
93933: EVENT: RELE-TERM-SOTTO#Switch=0.00
95860: SW : State 0.00
95862: EVENT: RELE-TERM-SOTTO#Switch=0.00
97705: EVENT: TEMP-BOILER#Temperature=78.00
97947: SW : State 0.00
97952: EVENT: RELE-TERM-SOTTO#Switch=0.00
98818: EVENT: TEMP-PANNELLO#Temperature=38.50
99860: SW : State 0.00
99862: EVENT: RELE-TERM-SOTTO#Switch=0.00
101860: SW : State 0.00
101862: EVENT: RELE-TERM-SOTTO#Switch=0.00
103762: EVENT: TEMP-BOILER#Temperature=78.00
103970: EVENT: TEMP-PANNELLO#Temperature=38.50
104185: SW : State 0.00
104187: EVENT: RELE-TERM-SOTTO#Switch=0.00
105738: DHT : No Reading
105861: SW : State 0.00
105863: EVENT: RELE-TERM-SOTTO#Switch=0.00
107715: WD : Uptime 2 ConnectFailures 0 FreeMem 16424 WiFiStatus 3
107860: SW : State 0.00
107862: EVENT: RELE-TERM-SOTTO#Switch=0.00
109045: EVENT: TEMP-PANNELLO#Temperature=38.50
109487: EVENT: TEMP-BOILER#Temperature=78.00
109917: SW : State 0.00
109919: EVENT: RELE-TERM-SOTTO#Switch=0.00
111860: SW : State 0.00
111862: EVENT: RELE-TERM-SOTTO#Switch=0.00

[giobbe70]

BOILER SENSOR IS REMOTE SENSOR ON ANOTHER ESPEASY WITH EASPEASY 20190630

[TD-er]

You need to get logs from the unit that actually has the sensor connected.
From remote sensors it is next to impossible to see what is wrong, since you only see the reported value, not why a value is incorrect.

[giobbe70]

the local sensor DH22 not work .
The sensor DS18b20 is remote on other ESPEASY release 20190630.
If I load the Release 201911013 The sensor DS18b20 not work.
the log is telease 20191116 with DH22 not work

[TD-er]

Well the plugin P005_DHT was last changed in August, so I guess it is not something in the plugin itself.

Does the plugin give data sometimes? Or are all measurements failing?

[giobbe70]

DH22 all measurements failing after August,
and DS18b20 all measurements failing after October
Thanks

[TD-er]

Which August build?
There have been several changes on the DHT plugin in August.
See: https://github.com/letscontrolit/ESPEasy/commits/mega/src/_P005_DHT.ino

[giobbe70]

I don't know that in October I am in agreement with the sensor malfunction

[uzi18]

DHT22 works for me with latest code, just recompiled and tested
@giobbe70 please try to change sensor type, and give us info what readings you have on other settings

@TD-er it is first report about not working sensor from long time, in my opinion it is hardware related
we can add some more debug for "no reading" to have more info for the future, maybe we can move noInterrupts() 2 lines up.

ESPEasy/src/_P005_DHT.ino

Lines 175 to 179 in 0d6d136

	if(!P005_waitState(0)) {P005_log(event, P005_error_no_reading); return false; }
	if(!P005_waitState(1)) {P005_log(event, P005_error_no_reading); return false; }
	noInterrupts();
	if(!P005_waitState(0)) {

[giobbe70]

Hi,
Unfortunately I cannot change settings, as the sensor is in a closed thermostat

[TD-er]

@uzi18 Moving the interrupts up is fine, as long as you make sure they are enabled before exiting the function.
Still, I wonder why it was working fine before.

Also, what is the common change for both Dallas and DHT plugins?
They can send out NaN, maybe the handling of that is the problem?

[clumsy-stefan]

@TD-er not sure if it's related, but roughly after 20191108 I experience also again more strange issues, like laggy-webpages, HW-WD reboots, Units that won't connect to AP anymore (especially when signal is weak), NeoPixel's don't run smoothly anymore, etc.

To me it looks like timing issues or background tasts that do not get executed or stalled... Which could explain why Dallas sensors are not read anymore correctly (wrong timing etc.)...

Can't really nail it currently, I'm searching, but did something change in WiFi handling or handling of background tasks?

[uzi18]

@TD-er small tweaks here #2748

@clumsy-stefan maybe it is core related?

[clumsy-stefan]

maybe it is core related?

Could very well be, yes, as I'm using latest GIT core... I'm still trying to track down what exactly happens... It could also be memory related, as the 1M units have more problems than the 4/16M ones...

[TD-er]

1M units often have more low-cost flash chips. Maybe we should lower the flash frequency on those? Or maybe it is lowered and that's what does make it more slow.

[clumsy-stefan]

strange thing is, it happens only since about a week ago or so (after 20191108) and I have a 16M unit with some Dallas sensors and 50 Neopixels. I see wrong colors on the strip or laggy movement of the color pattern, which normally means some timing is not correct when driving the neo's....

[TD-er]

This 16M module, what SPIFFS size do you use?
Maybe this is not related to this issue, since the reported issues here apparently started in August (and nobody else has them?)

[jeroenhe]

I experienced the same problem as OP with my DHT22 sensor, going from firmware version file ESP_Easy_mega-20190425_normal_ESP8266_4M.bin to ESP_Easy_mega-20191130_normal_ESP8266_4M1M.bin on a NodeMCU v3 CH340G.
After the firmware upgrade, the humidity and temperature sensor both gave me NaN. Then I figured I switch the GPIO port from GPIO-16 (D0) to GPIO-15 (D8) which fixed my problem. I'm mentioning this here because it might help someone fix their sensor problem, just by avoiding the GPIO-16 port (when possible that is).

[andyjbm]

Hi there,

Just jumped on the easyesp ship this week and I'm excited. So here I am with my observations using easyesp with DS18B20 in parasite power mode.

The problem is that in parasite power mode the one wire bus must be held high when a measurement is being performed or when the data is being written to eeprom. This is because of the amount of current required during this time. The DS18B20 cannot store enough energy to complete a conversion. It needs power from the bus during this time.

How it gets this power is not the debate for me - I've had success with really low pullup resistors (1k) when there are 8 or more DS18B20 or setting the GPIO pin as output high during conversion.

Now the crux of the problem with easyesp as I've just observed today.
With one DS18B20 the easyesp sends the 44 command code to initiate a conversion and then waits for 200mS with the data line high. I was using a 3k3 pullup to 3v3. Then it asks the DS18B20 for the results with command code BE.

This means that the DS18B20 gets the power it needs to achieve a successful conversion.

However with more than one DS18B20 easyesp sends the start measurement command (44) to the 1st DS18B20 AND THEN IMMEDIATELY sends a start measurement command to the next DS18B20 starving the 1st of the power it needs to succesfully perform a measurement. So the 1st fails and results in NaN but the last DS18B20 succeeds.

This was using one esyesp "device" in single vs dual vs quad mode.

I also had varying degrees of success by using each DS18B20 on its own easyesp "device" but on the same one-wire bus.

Conclusion: The issue with DS18B20 NaN is not communication or hardware issues but because the firmwaare implementation is not honouring the requirement of a DS18B20 to have the one-wire bus to be held high WHILE A MEASUREMENT IS IN PROGRESS. Easyesp is attempting to communicate with other devices on the one-wire bus and therefore starving those DS18B20s that are trying to perform measurements of the power they need for succesful measurement.

I had both a DS1054 and a picoscope looking at the onewire bus and both wave form and data are fine and not corrupt at all. The issue for most is not the pullup resistor or not likely to be wire length. It is the problem that the firmware is writing to the one-wire bus while a device is trying to perform a measurement.

Now how to fix? No idea yet. Only just got started with easyesp. Off to take a look at the code for the DS18B20 plugin.

Others that know the code better may beat me to a fix now they know the crux of the problem.

Regards,

Andy.

[TD-er]

Parasitic powering of the Dallas sensors is not supported.
And the 'interleaving' of reading is done on purpose.
It does allow to get upto 4 sensors per task which will be read at the same time.
When using parasitic mode, this is impossible.
It also needs some synchronization between tasks to make sure the GPIO pin is not changed when another sensor is read.
So therefore I have chosen to not support parasitic mode... or at least not yet.

[andyjbm]

@TD-er Ahh, Ok.

I misunderstood then in the device stats where it stated "Parasite Powered:" with a true flag as being recognised & therefore supported.

Maybe a comment on that page to advise that parasitic powered configuration is not supported would save those from the frustration of trying to get it to work and understanding why it is not working?

Is parasitic power config on the road map at all? I guess not in the immediate future from the wording of your reply...

Regards, Andy.

[andyjbm]

As an additional thought, I believe it is possible to initiate measurement/converrsion to all DS18b20 simultaneously on the one-wire rather than addressing and initiating a measurement to each DS18B20 individually by sending a global 44h instead of a 55h and the ROM address and then 44h.

That should allow all devices in a quad to measure simultaneously and be read interleaved as is already the case but also preserving the state of DQ while measurement takes place?

The limitation would then be up to 4 DS18B20 per one-wire bus as a single easyesp "device".

Andy.

[andyjbm]

As an additional thought, I believe it is possible to initiate measurement/converrsion to all DS18b20 simultaneously on the one-wire rather than addressing and initiating a measurement to each DS18B20 individually by sending a global 44h instead of a 55h and the ROM address and then 44h.

That should allow all devices in a quad to measure simultaneously and be read interleaved as is already the case but also preserving the state of DQ while measurement takes place?

The limitation would then be up to 4 DS18B20 per one-wire bus as a single easyesp "device".

Andy.

Nah, I'm not convinced I got this right. Can't find where I thought I saw it now. But it was a while ago.

A.

[TD-er]

See documentation where it is stated that parasitic power is not supported.

As an additional thought, I believe it is possible to initiate measurement/converrsion to all DS18b20 simultaneously on the one-wire rather than addressing and initiating a measurement to each DS18B20 individually by sending a global 44h instead of a 55h and the ROM address and then 44h.

That should allow all devices in a quad to measure simultaneously and be read interleaved as is already the case but also preserving the state of DQ while measurement takes place?

The limitation would then be up to 4 DS18B20 per one-wire bus as a single easyesp "device".

Andy.

What happens with the Dallas sensors on several tasks is that they will start the measurement, one task after another and then reschedule the tasks to read the sensors.

However it is not guaranteed this will always be done in this sequence.
The (upto) 4 sensors in a task are read in the same sequence, so those will always be read at the same time.
The reason why it cannot be guaranteed for multiple tasks is that ESPEasy will run a lot more so things should not be blocking.
Starting an 1-wire measurement does take some time and the max. read period is 750 msec.
So I am not entirely sure more than 12 can be read at the same time. But this is already blocking for roughly a second to read them all at the same time.
1000 msec blocking is a big no-no as it will affect all other scheduled actions on the ESP.
You may even get into trouble with WiFi connection since the 1-wire bit toggling is rather blocking code which cannot be interrupted by checking WiFi in the mean time.

[andyjbm]

Hi @TD-er ,

So I found the sequence to initiate a measurement on all Ds18B20 on the one wire bus in one hit. Perform a one-wire reset then write CCh (ROM skip command) followed by 44h (initiate measurement command). Then set the one-wire bus high.

This should syncronously start measurements on all the devices on the one wire bus. After the conversion time has passed the event schedule can then poll each device to read the values as it does already.

This has the downside of only working for 4 devices on the one bus and other easyesp "devices" with physical devices on the same bus would interfere with this process. Also other devices would be interfered with by this process!

I have another idea which must wait until I'm in front of a real keyboard to type it up!

Regards, Andy.

[TD-er]

Just to avoid confusion in explaining.

In ESPEasy we have a plugin, which is a piece of code describing how to interact with some sensor (or other hardware like a display)
The items you see on the "Devices" tab are called "tasks".
A task is an instance of a plugin, with specific settings for a specific sensor (e.g. pin configuration, or hardware address, etc.)

So what you call "devices", you probably mean "tasks" right?

[andyjbm]

So what you call "devices", you probably mean "tasks" right?

Yes I think so, Not with the lingo yet...

A.

[andyjbm]

Ok, So quick aside as I thought I'd got this nailed right now but as they say one step forward and you fall off the cliff...

So my use case for easyesp. I'd been using a PI to read in 10 dallas 10b20s and posting to a local emoncms server monitoring a heating system which has been recently ripped out and replaced. I need to monitor flow and return as a quick verification and I thought a wemos D1 mini and easyesp capable of both ds18B20 and emoncms would be plug and play....

However.

Parasite power not supported - fair enough. But it does work if you only have one device on the bus. So I just set up two devices on separate GPIO. Fine and dandy. Values flowing out the serial monitor.

Now to emoncms that was working aok with NaN values across 4 sensors on one bus. As field1 field2 etc.

however now they are on separate "tasks" (yay!) both devices are referred to as "field1" rather than the task name or the task device value (correct notation?). And as the emoncms node id is tied to the easyesp instance on the wemos the two dallas values are pasting over the top of each other on one emoncms input instead of being sent to two different inputs (temp1, temp2) on the same node or the same field1 on two different nodes 41,42 etc.

Bugger, there's the cliff.

This "feature" is more to do with the emoncms controller than the dallas thread and ought to be raised somewhere else - probably would be nice to push the task value name to emoncms rather than field1 field2 etc. But it became apparent because of the problem I was having with the dallas DS18B20.

Bedtime.

Andy.

[TD-er]

I have never used EmonCMS.
But if you need to send a task with 2 variables, why not store the values in a 'dummy' task and let the dummy task send its values to the EmonCMS controller?
From the rules you can store something in a dummy task using task taskvalueset

To 'flush' the values in a dummy, you can call taskrun, which will send all values to the connected controller.

You can even call taskvaluesetandrun (as last one)

But why do you need to use the Dallas sensors in parasitic mode?
Why not adding an extra wire to them?

[andyjbm]

But why do you need to use the Dallas sensors in parasitic mode?
Why not adding an extra wire to them?

The sensors are already in and wired. I was avoiding having to rewire them thinking this would work with the wemos as is.

Moving the old software to a pi zero was the immediate idea but for the problem that there is no easy access to power and a wemos/easyesp combo was attractive from a power point of view being able to last a significant time on a battery compared to the pi.

In hindsight (or starting afresh) a three wire one-wire (there's an irony) with wemos/ easyesp would have been the thing to do. And may well be what I end up doing in the end.

A.

[andyjbm]

I have never used EmonCMS.
But if you need to send a task with 2 variables, why not store the values in a 'dummy' task and let the dummy task send its values to the EmonCMS controller?

So emoncms would take data in the form value1Name:value,value2Name:value etc. Easyesp emoncms plugin uses field1,field2 etc as the value name and this works when posting the data from a Ds18B20 task in quad mode. The one task sends the four values which get sent to emoncms as field1, field2, field3, field4. One for each temp sensor. Great.

However when using a separate plugin task for each Ds18B20, each task instance sends its own value via the emoncms controller as "field1", so the values from the four sensors end up in emoncms in one input feed instead of four separate ones.

From the rules you can store something in a dummy task using task taskvalueset

To 'flush' the values in a dummy, you can call taskrun, which will send all values to the connected controller.

You can even call taskvaluesetandrun (as last one)

I'm completely newbie to easyesp. It is obviously a capable bit of kit - my initial attraction to it being the WiFi setup out of the box and straight forward to get up & going on power efficient hardware.

I will have to set time aside to understand what it can do and give these other ways you describe a shot.

Thanks for the pointer...

A.

[TD-er]

Just to get the concepts straight of what role a task has in ESPEasy.

• Task is an instance of a plugin
• Task interacts with hardware (optional) and may yield 0 ... 4 task values
• Task values can be handed over to 0 .. 3 controllers to get the data somewhere (EmonCMS has its own controller in ESPEasy as you already have seen)

A 'dummy' task does not interact with hardware, but can hold task values and send them over to the controllers.
A task has a number of 'states' or 'functions' of which I will describe the most important ones:

• PLUGIN_TASK_READ is called when you "run" a task. This is the only call that may yield new task values which can be handed over to the controller(s)
• PLUGIN_TASK_ONCE_A_SECOND, PLUGIN_TASK_TEN_PER_SECOND, etc. are periodically called to complete active measurement, signal events from hardware, etc.
• PLUGIN_TASK_WRITE handles commands you send to a specific task. Commands can be sent from rules, HTTP calls, etc.

One of the commands for a 'dummy' task is to set a value to the dummy task: TaskValueSet.
After you stored a number of values in this dummy task, you want to flush them, so the PLUGIN_TASK_READ must be called.
This is done via the command TaskRun, which can be used on any task by the was.
Since a dummy task does not have to interact with hardware, it just takes its task values and sends them to the connected controllers of that task.
In a dummy task, you may select what kind of data type you intend to send to the controller.
There are basic types like "Single value", "double values", "triple..." and I think you get the idea.
But there are also specific types, which are often only needed for controllers like Domoticz, since Domoticz has a fixed set of data types, mainly tailored to specific hardware like the BME280, which delivers temp/hum/pressure. (named temp_hum_baro)

[andyjbm]

Hi @TD-er,
Sorry, been away on work and other domestic things consuming my time atm.

Thanks for the above. I will endevour to invest some time to discover how you intend espeasy to be used instead of being butchered by old hacks like me.

However:

I added this method to Dallas1WireHelper.cpp:

bool Dallas_SensorData::initiate_global_read(int8_t gpio_rx, int8_t gpio_tx, int8_t res){
  Dallas_reset(gpio_rx, gpio_tx);
  Dallas_write(0xCC, gpio_rx, gpio_tx); // Skip ROM addressing, ie next command is to all devices on the One-wire bus.
  Dallas_write(0x44, gpio_rx, gpio_tx); // Take temperature measurement.
  return true;
}

And then in P004_data_struct.cpp changed the line:

if (_sensors[i].initiate_read(_gpio_rx, _gpio_tx, _res)) 

to

if (_sensors[i].initiate_global_read(_gpio_rx, _gpio_tx, _res)) 

and basically it works a treat. So the CCh, 44h combo initiates a global measurement on all devices on the onewire bus and then the read of values is just as already coded.

I did a bit of hacking so that only the 1st of 4 sensors in the loop initiates the gobal read and also to make sure the resolutions are the same.

I'm thinking a CCh command will also allow a global config of all sensor resolutions to be set in one hit as well but not got that far.

So for completeness (as I haven't had time to push it to github yet) (and it's a shameful proof of concept hack at this point) here's the mod to bool P004_data_struct::initiate_read() that calls the hacked _sensors[i].initiate_global_read(..)

 bool P004_data_struct::initiate_read() {
  
  // Check/set the resolution of each sensor before we initiate a global measurement.

  for (byte i = 0; i < 4; ++i) {
    _sensors[i].check_sensor(_gpio_rx, _gpio_tx, _res);
  }
  
  _measurementStart = millis();
  for (byte i = 0; i < 4; ++i) {
    if (i==0){ // Global meaurement initiated by the 1st sensor - we don't need to do the others.
     if (_sensors[i].initiate_global_read(_gpio_rx, _gpio_tx, _res)) { //res doesn't do anything in this call yet.
      if (!measurement_active()) {
        // Set the timer right after initiating the first sensor


        /*********************************************************************************************\
        *  Dallas Start Temperature Conversion, expected max duration:
        *    9 bits resolution ->  93.75 ms
        *   10 bits resolution -> 187.5 ms
        *   11 bits resolution -> 375 ms
        *   12 bits resolution -> 750 ms
        \*********************************************************************************************/
        uint8_t res = _res;

        if ((res < 9) || (res > 12)) { res = 12; }
        _timer = millis() + (800 / (1 << (12 - res)));
      }
     }
    }
    _sensors[i].measurementActive = true;
  }
  return measurement_active();
}

Anyhow this is installed and pushing me the data I need for now to emoncms so I'm a happy bunny.

And I've found a new toy (espeasy) in the process.

Andy.

[TD-er]

Looks interesting.
There is however a number of questions popping up in my mind right now:

• How long is the measurement stored in the sensor? There is a limit to how many values you can read in a limited amount of time.
• Will this also work with 'clone' Dallas sensors? I have spent quite a while to get it to work as it does now with the cheapest Dallas sensors available on the market as those reportedly have issues when used with > 3 on the same bus. In my setup I can read 12 with 4 per task just fine, but I guess sending a global start sample command may be one of those features not implemented in the non official ones. Thus it must be configurable for sure to also be able to read it as done now.
• With a global read, there must also be a static flag in this data struct to keep track of global read being performed.
• What will a separate read do to a running measurement? There are more 1-Wire Dallas sensors out there which are not temperature sensors.

[andyjbm]

Quick reply before I call it a night.

Looks interesting.
There is however a number of questions popping up in my mind right now:

Sure... My initial quest was to get parasitic power working but that's opened a pandora's box.

• How long is the measurement stored in the sensor? There is a limit to how many values you can read in a limited amount of time.

As far as I'm aware (research and experience) the value obtained by a measurement action stays in the scratch space until it's overwriten with the next measurement or the power is removed. So potenitally indefinately.
Yes I agree that reading all these values from 10+ sensors takes time. Maybe a way of scheduling measurement initiations separate from reads may help with blocking important wifi tasks etc. Realistically if you need a temp measurement every 10 seconds (not likely you need a temp reading every second??) from 10 sensors that's only one device a second to read the data.. What's really important is that the measurements are all synchronised - which is what the CC44h combo achieves.

• Will this also work with 'clone' Dallas sensors? I have spent quite a while to get it to work as it does now with the cheapest Dallas sensors available on the market as those reportedly have issues when used with > 3 on the same bus. In my setup I can read 12 with 4 per task just fine, but I guess sending a global start sample command may be one of those features not implemented in the non official ones. Thus it must be configurable for sure to also be able to read it as done now.

My understanding is that the CCh command is part of the dallas spec and as such is implemented by the knock offs also. 99% of the time the issue with parasitic powering is not holding the onewire high enough for long enough for all the devices on the bus to achieve their measurement simultaneously. It is their source of power while this takes place. One PI implementation with 8 sensors was fixed using a 680R pullup resistor which would seem way overkill but so long as all the devices and the PI can sink the 680R to ground then it worked!

• With a global read, there must also be a static flag in this data struct to keep track of global read being performed.

For sure there needs to be a way of determining are we global or discrete. Maybe the parasitic power flag is a heads up that discrete is going to fail.
Another approach I'd considered was to read subsequent devices once every event. IE four devices on 10 second schedule would mean one device every 10 seconds or all devices completed every 40 seconds. The problem for parasitic power is that once that 44h has been sent for the measurement to succeed the line cannot be interrupted until the device(s) have completed their measurement.

• What will a separate read do to a running measurement? There are more 1-Wire Dallas sensors out there which are not temperature sensors.

Break it I guess. Once a measurement has commenced in parasite power mode the line cannot be used for anything other than powering the device that has a measurement in progress. This is the fundamental reason for NaN (125 or 85 degC) values being returned accross the planet for these devices in parasite power mode. The Onewire line was disturbed before the measurement was allowed to complete.

I can't speak for other sensors but what I can say is that they have to wait patiently for DS18B20 to finish the measurement before they can communicate. But isn't the CC44h spec a One-wire spec rather than just a Dallas spec? So all devices would be busy measuring at that point anyway? We just have to wait for the longest device to complete before we start asking for results ad that point.

But this shouldn't be a problem. If DS18B20 are all on one GPIO and other sensor types are on another? I'd be reluctant to mix device types on a bus but then my use case is quite specific.

I don't see a problem with 20 or 30 or more DS18B20 on one GPIO in parasite power mode from a hardware point of view. CC44h would initiate a read on all 30 in one hit. Then you've got to read the data. Which is the same timing challenge that you have from a separate power 3 wire implementation point of view anyway.

Enough for now.

Later,
A.

[TD-er]

There are also Dallas 1-Wire tags (like RF-ID, but electrical contact), an 1-wire counter, etc.
And it doesn't mean it should not be implemented, but more like side effects should be documented :)

[uzi18]

@TD-er time gone, but do you know now how accurate functions like micros64() are?

[TD-er]

@uzi18
Quite accurate if you use them in a while loop.
But using delay for micros is not accurate at all. (or any delay, even in a while loop)

Typically the crystal should be within 10 ppm, so that's about the accuracy of the micros.
If the crystal is less accurate, I guess you would also see it in instable WiFi performance.

[uzi18]

@TD-er asking you because have new data about esp32.
If you are interested in here is a link for you to read:
pstolarz/OneWireNg#38

This explains why we changed timmings in OW and DHT and can't find accurate.

[tonhuisman]

Long time no reply in this issue, so most likely it has been solved, especially as there have been a lot of updates on ESPEasy code regarding these plugins. This can most likely be closed.

[TD-er]

This has for sure been solved as I have been tweaking those plugins using a logic analyzer on both ESP8266 and ESP32 with the latest ESP32 SDK.