Issue with DS18B20 on D1 Mini not found, dependent on trivial changes to flow

[colinl]

The attached simple flow, with an inject node driving a DS18B20 node and on to a function node and MQTT Out, works correctly. The Wemos D1 Mini has a DS18B20 connected in the normal manner, 0V, 3,3V and GPIO4, with a 3k3 pullup resistor.

However, if I delete the wire to the MQTT node then the sensor is not detected. Using xsbug I can see that the bus search in rpi-ds18b20.js does not find anything. With the wire connected I can see that it does find the device, so I am looking at the right code. Making other trivial changes to the flow can also change whether it is found or not. I have done enough experimenting to be confident that it is not an intermittent hardware problem. The attached flow works every time and with a flow that does not work then it never works.

This makes absolutely no sense to me, and it has taken a lot of playing to convince myself that it is really happening, but I am convinced.

[{"id":"ca71fe5f83dd3ed0","type":"tab","label":"mcu test","disabled":false,"info":"","env":[]},{"id":"daf71fd6976e6abe","type":"mqtt out","z":"ca71fe5f83dd3ed0","name":"","topic":"","qos":"0","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"75fb29423f8a0770","x":690,"y":260,"wires":[]},{"id":"e8104385c3f36513","type":"debug","z":"ca71fe5f83dd3ed0","name":"debug 86","active":true,"tosidebar":false,"console":true,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":510,"y":60,"wires":[]},{"id":"5da2de6f6e27f039","type":"inject","z":"ca71fe5f83dd3ed0","name":"Measure","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"10","crontab":"","once":true,"onceDelay":"3","topic":"","payload":"","payloadType":"date","x":100,"y":260,"wires":[["36501d946e21bc46","e8104385c3f36513"]]},{"id":"36501d946e21bc46","type":"rpi-ds18b20","z":"ca71fe5f83dd3ed0","topic":"","array":false,"name":"","x":270,"y":260,"wires":[["28589ba6de2421c5","e8104385c3f36513"]]},{"id":"28589ba6de2421c5","type":"function","z":"ca71fe5f83dd3ed0","name":"Extract id and temperature","func":"if (msg.payload.id && msg.payload.id.length > 0) {\n    msg.topic = `tydwr/ds18b20/${msg.payload.id}`\n    msg.payload = msg.payload.temp\n    return msg\n}","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":480,"y":260,"wires":[["daf71fd6976e6abe"]]},{"id":"75fb29423f8a0770","type":"mqtt-broker","name":"Owl2 for mcu","broker":"192.168.49.83","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]

[colinl]

I have done some more testing, and determined that the symptom remains absolutely consistent.
In node-red-mcu/nodes/rpi-ds18b20/rpi-ds18b20.js the relevant code is

		const items = this.#bus.search();
		for (let i = 0; i < items.length; i++) {
			const id = items[i];
			this.#sensors.push(new DS18X20({bus: this.#bus, id}));
		}
}

I can see that it is getting to this code, but the search is not finding any sensors.
If I add a line of code after the for loop, so it now reads

		const items = this.#bus.search();
		for (let i = 0; i < items.length; i++) {
			const id = items[i];
			this.#sensors.push(new DS18X20({bus: this.#bus, id}));
		}
		trace(`18b20 items.length: ${items.length}\n`);
}

then the search does correctly find the sensors. Moving that line up to before the for loop causes it to fail again and it shows the length as zero.
I hesitate to suggest that this is a build/compile issue, but I am having difficulty thinking what else it might be.

Is anyone able to confirm what I am seeing?

[phoddie]

Surely mysterious. I did a bunch of work recently with the DS18X20 on ESP32 without a problem. The I/O is completely different on ESP8266, and much more sensitive to timing variations. But that doesn't explain your observations. Stupid questions:

• If you repeat the search a few times, does it always return the same number of items?
• If you disable Wi-Fi, are the OneWire search results still the same?

[colinl]

I only have one sensor connected at the moment, it always returns 1 when it is working and 0 when it isn't. I think I have another sensor somewhere I will dig it out and wire it up.

Disabling Wi-Fi does not appear to make any difference either way.

[phoddie]

Disabling Wi-Fi does not appear to make any difference

Thanks for trying.

I only have one sensor connected at the moment, it always returns 1 when it is working and 0 when it isn't

I wasn't clear. I was suggesting to try something like this:

trace(`search: ${this.#bus.search().length\n`);
trace(`search: ${this.#bus.search().length\n`);
trace(`search: ${this.#bus.search().length\n`);
trace(`search: ${this.#bus.search().length\n`);
trace(`search: ${this.#bus.search().length\n`);

[colinl]

Bingo!
With the code looking like

		const items = this.#bus.search();
		trace(`search: ${items.length}\n`);
trace(`search: ${this.#bus.search().length}\n`);
trace(`search: ${this.#bus.search().length}\n`);
trace(`search: ${this.#bus.search().length}\n`);
trace(`search: ${this.#bus.search().length}\n`);
trace(`search: ${this.#bus.search().length}\n`);

Then if I remove all the wires in the flow I get, consistently

Wi-Fi connected to "RedKite"
IP address 192.168.49.245
search: 0
search: 1
search: 1
search: 1
search: 1
search: 1

or if I add back the first wire I get all 1s
If I then add back the next wire

Wi-Fi connected to "RedKite"
IP address 192.168.49.245
search: 1
search: 1
search: 1
search: 0
search: 0
search: 0

and if put all the wires back then

Wi-Fi connected to "RedKite"
IP address 192.168.49.245
search: 1
search: 0
search: 0
search: 0
search: 0
search: 0

So it is looking as if maybe there is a time window during which it works, and small changes move the window about.
Whatever the wiring, if I step through that code one line at a time they always all work.

One thing I have just realised is that, since the ds18b20 node is not the first one started, parts of the flow are already running while this code is running, so that may be part of the reason for the variation in the symptom.

[phoddie]

So it is looking as if maybe there is a time window during which it works, and small changes move the window about

Wild. I guess the question is, "what closes the window?"

[colinl]

When the stuff going on in the background in the other nodes finishes? Or starts? No idea really.

[phoddie]

When the stuff going on in the background....

ESP8266 is cooperatively multitasked -- there's really just one thing running at a time and it cannot be swapped out. And there are just two tasks -- the project and Wi-Fi. An interrupt can take time, of course, but there's not much running there either (Wi-Fi is the main one, but you said turning that off didn't make a difference).

[colinl]

This is just ridiculous. I went back to the situation with just the first two wires in the flow connected, and I get (as I did yesterday)

search: 1
search: 1
search: 1
search: 0
search: 0
search: 0

If I comment out the last two trace(search: ${this.#bus.search().length}\n); lines then obviously I should get 1,1,1,0, but actually I get

search: 0
search: 1
search: 1
search: 1

So commenting out the last two lines affects what the earlier lines do. There needs to be some understanding of how that can be.
Again this is absolutely repeatable.

[colinl]

Could this be something to do with trace() calls, or the comms associated with that? I replaced the code with

		const items = this.#bus.search();
		let results = [items.length]
		for (let i=0; i<5; i++) {
			results.push(this.#bus.search().length)
		}
		results.forEach(e => trace(`search: ${e}\n`))

and now I get 100% success, whatever I do with the flow (so far anyway). I don't understand how though, the trace calls will affect the timing of the second and later searches, but I don't see how it could affect the result of the first search. Also I think that takes us back to the unmodified file (except for the forEach line) which itself did fail consistently on the first (and only) search.

[ralphwetzel]

with a 3k3 pullup resistor

Hi @colinl !
Could you please confirm this data?
According to spec, a single DS18B20 demands a 4k7.
A 3k3 might be too small & create issues on the bus... or is it a typo derived from the 3,3V ?

[colinl]

Hi @ralphwetzel
Yes, I am using a 3k3 resistor. It is a long time since I looked at the spec, but if I remember correctly, one issue is that they are designed for 5V operation, and when you look at the worst case situation they are not guaranteed to work at all with 3.3V. In practice they do, however, but I have always used a slightly lower resistor in order to make sure the bus pulls high enough, particularly if there are long wires and several sensors. With only one sensor and short wires I suspect almost anything would do. I will certainly swap it for a 4k7 however, just to remove any uncertainty. If this were part of the problem I would expect it to give variable results, but I am finding complete repeatability here.

[tve]

'been using low resistor values with DS18B20's for over a decade, however, always with 5V. They certainly work down to 2.7K or even 2.2K pull-up resistors IIRC and the low values are beneficial for long lines. The 3.3V could produce issues, though, because that means the internal capacitors that power the chips don't get nearly as much charge. The issue this causes could also very well be 100% repeatable because certain bus transactions require more power for the DS18B20 to send its data to the bus master. So it could run out of power consistently when it reaches a specific transaction.
If I were you, I would connect the bus pull-up to 5V and see whether it changes the situation. IIRC the esp8266 are de-facto 5V tolerant and you have a current-limiting resistor there, so the chip's pad driver doesn't actually have to shunt that much current.

[colinl]

[quote]
IIRC the esp8266 are de-facto 5V tolerant
[/quote]

Are you sure about that? Opinion appears to be divided over the issue. I don't want to blow the chip up.

I am having great difficulty seeing how that could give the sort of issues I am seeing here, where changing the code in the lines following the bus access changes the result of the search.

[tve]

I'm sure the Moddable folks would be happy to send you a couple of spare esp8266's, that's less money than about 1-2 minutes of their troubleshooting time in salary ;-). Using a 3.3K pull-up you're only putting 0.5mA into the pad, that's pretty much in the noise.

WRT how later lines could influence earlier ones... The code gets executed from flash, which comes in pages/lines that get cached. The processor only really executes from cache. So changes in code size can cause "distant" code to be split across cache lines where they formerly fit into a cache line. That can cause bus transactions to have delays introduced, or timings to be missed. The one-wire bus distinguishes 1's and 0's using the timing of an edge, that timing generation/measurement could be off due to cache misses depending on how it's implemented in the SDK. I'm not saying that any of this is the real reason for what you observe, I'm just providing some ideas for how changes in later code can affect earlier code...

Happy troubleshooting ;-)