A long time ago, back in the dark ages when all we had were Arduinos (seems such a long time ago) I spent a bit of time playing with the Dallas DS18B20 chips.
There are a number of ways to read these and so I’ll explain my logic as I go along. Not everyone will agree with my conclusions and that’s fine. Works for me as they say.
The example that comes with the Lua interpreter caters for almost everyone by making the software check for missing chips, multiple chips and offering a range of output options including degrees C and F. As the language subset does not include floats, it simulates that with two catenated numbers.
In order to avoid issues with delays stopping communications ( and I can confirm that delays WILL stop for example incoming MQTT messages), it also does away with the typical setup delay.
So – a number of issues with this. Firstly, for me, if I am reading temperature and maybe controlling something, I cannot for the life of me see the need for sub-degree precision. Accuracy yes but precision? Really, you’re going to keep the house at exactly 22.15c? Probably not. I control 2 properties and this code will likely control the third – 24-7, 365 days as year if it works as reliably as the Arduino version.
Secondly, when I received my Dallas chips I got a mixed bunch on special offer and ended up with some with a P suffix. I quickly discovered that the delay is needed for these chips and today when using the example software with Lua I was set back temporarily before remembering this fact. The P suffix chips simply would not work AT ALL and constantly returned 85c. That delay is needed one way or another.
Because it has been removed, the first reading you take with the code will be incorrect.. and that’s not really a problem – you could take that during setup. There are ways around this but it’s not worth the bother when it’s so easy to circumvent.
Now personally I don’t see me using more than one chip per board and if I did I could always use another pin – so that whole search scenario is a waste of time, resources and RAM for me.
So given these criteria I have a MUCH simpler version of the driver for you – and one which will work without alteration with both chips. It’s also fast.
Instead of seeking the address of the chip, then starting the conversion, then reading the chip… I assume one chip, simply read the value then start the conversion.
This seems utterly wrong but then remember your first reading is naff anyway. Assuming you don’t try to read the unit more than, say, once a second, the time in between reads will be more an enough to do the conversion for BOTH types of chip. I plan to stick this on a timer, say, every 10 seconds, dumping the value into a global variable so it’s “just there”.
Also as I’m just reading an integer, about the only check I have to do is for overflow so as to perhaps create a negative number (for freezing conditions) and finally all that CRC stuff and the buffer needed to store the data – why bother, with only one chip it’s not going to go wrong unless you have a long lead between the board and the chip. You only need to read 2 bytes!! Speed, storage…
So here’s the EASY version.
I have to say, I simply do not understand the registration system for LUA modules yet (wasn’t there last time I looked in) so those first few lines at the start I’ve copied verbatim.
Can you make it even simpler and also explain this stuff at the very first few lines to do with modname? Oh, I’m using all 3 leads (GND, D and VDD) of the Dallas chip and a 4k7 pull-up from D to VDD. I found the pull-up un-necessary on short leads but let’s not test fate?
Please note – this information has now been superseded by the info on the new blog at https://tech.scargill.net – please visit the new blog where you can search many hundreds of IOT-related entries.
——————————————————————————–
— DS18B20 one wire module for NODEMCU
— LICENCE: http://opensource.org/licenses/MIT
— Vowstar <vowstar@nodemcu.com>
— Dramatic simplification: Peter Scargill
——————————————————————————–
— Set module name as parameter of require
local modname = …
local M = {}
_G[modname] = M
——————————————————————————–
— Local used modules
——————————————————————————–
— Table module
local table = table
— String module
local string = string
— One wire module
local ow = ow
— Timer module
local tmr = tmr
— Limited to local environment
setfenv(1,M)
——————————————————————————–
— Implementation – you don’t get any shorter than this
——————————————————————————–
function readNumber(pin)
ow.setup(pin)
ow.reset(pin)
ow.write(pin, 0xCC, 1)
ow.write(pin, 0xBE, 1)
data = nil
data = “”
for i = 1, 2 do
data = data .. string.char(ow.read(pin))
end
t = (data:byte(1) + data:byte(2) * 256) / 16
if (t>100) then
t=t-4096
end
ow.reset(pin)
ow.write(pin,0xcc,1)
ow.write(pin, 0x44,1)
return t
end
— Return module table
return M
That’s it!!! So there’s the library done… now here’s the test code…
t=require(“ds18b20”)
print(t.readNumber(4))
t = nil
ds18b20 = nil
package.loaded[“ds18b20”]=nil
Notice that this, too is simplified. “4” refers to GPIO2 in the Lua tables. I’m using an ESP-01 and I use GPIO0 to control a relay.
and here are the results showing a swing across through zero thanks to my handy liquid air spray. I do wish I could figure out how to turn the UART off except when I’m firing prints out – anyone know how to do this? Results buried in that mess are –2, 0, 1 and are degrees C (you could easily mod the code to F). Suggest not trying to measure over 84C.
> t=require(“ds18b20”)
> t.setup(4)
> print(t.readNumber())
-2
> t = nil
> ds18b20 = nil
> package.loaded[“ds18b20”]=nil
>
> t=require(“ds18b20”)
> t.setup(4)
> print(t.readNumber())
0t = nil
> ds18b20 = nil
> package.loaded[“ds18b20”]=nil
>
> t=require(“ds18b20”)
> t.setup(4)
> print(t.readNumber())
1t = nil
> ds18b20 = nil
> package.loaded[“ds18b20”]=nil
If you’re on Facebook why not LIKE here. https://www.facebook.com/esp8266wifi
![plot[3]](https://scargill.files.wordpress.com/2015/01/plot3.jpg "plot[3]")
My Tech Weblog 