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]

Well, that is interesting. I have updated to the latest moddable code and also node-red-mcu and it has been running for a couple of hours without a glitch. I will leave it running and see what happens, but it is looking hopeful. Why my previous build showed the problem I don't know, I had checked several times that I was using what I thought was the latest version of the files from the gist.

[colinl]

Having just checked, I see that the new version of $MODDABLE/modules/drivers/onewire/esp/owb_gpio.c is not the same as the version in the gist, so perhaps that is the explanation. In fact modGPIO.c is not the same either.

[colinl]

I am happy it is solid now, I haven't had any reading failures in 24 hours so I will close this.

[phoddie]

@colinl - I'm only just getting back to this thread. I was traveling and my DS18B280 hardware was a few hundred miles away. I'm happy to see things are working well for you!

In staring at the code for the 37th time, I noticed a potential issue in how the GPIO driver (modGPIO) transitions to output. Normally it wouldn't matter, but for a 1-wire protocol it could look like noise. There's some more work to solve the that correctly in all cases, related to this issue EcmaTC53/spec#35. I'll get to that in time. Once I do, it will allow the GPIO 1-wire implementation in owb_gpio to work on hardware beyond ESP8266 (like Raspberry Pi Pico and another port we have brewing).

Anyway... many thanks for your help in tracking this one down. Great to have this level of reliability now.

[colinl]

OK. Let me know when the changes are done and I will check it out with my hardware.

[colinl]

Have you had a chance to look at this yet? I am again seeing issues on some sensors, that come and go with apparently unrelated changes to the flow, such as adding a debug node.

[phoddie]

The work I mentioned above shouldn't have a visible impact. It is architectural. At the moment, the code in owb_gpio.c bypasses the code that would generate the noise by using DIRECT_MODE_INPUT instead of calling modGPIOSetMode.

I believe the only significant difference from the Arduino implementation at the moment is the timings for some of the 1-wire states. The values use match the recommendations from Maxim for broadest compatibility. We had tried the Arduino implementation's numbers at one point, but that didn't seem to make a difference. I'm happy to put that back as an option, if you'd like to give it a try.