The Boston Trip

Please note – this blog is WELL out of date and all of my blog items and much, much more have now been moved to http://tech.scargill.net

beerSome time ago, the CEO of Espressif, makers of the lowest cost WIFI-enabled processor on the planet and one I’ve blogged about frequently in here, invited me over to MIT at Boston to the FAB11 conference. As it turns out this was a rather small affair featuring things like 3D printers and other fabrication equipment. However the main point was to run a series of workshops on the ESP8266 and along with me were employees of Espressif including Jeroen Domburg (ES_-HTTPD) and Ivan Grokhotkov (Esp8266/Arduino).

Simmons Hall or Stalag as I will no doubt remember itWe arrived on Sunday here in sunny Boston and of course the first thing that happened was Iberia lost my large case complete with samples, laptop+presentation, clothing, pills, you name it.  I’d had a note to say that due to flooding, my single room accommodation was to be “shared” – with someone I’d never met before. Ok, I’d emailed Jeroen before but I did stress to the staff at the hostel (or as we now call it, the prison) that I really would like my own room. I arrived and despite protests, no change. Now as it happens Jeroen and I get on just fine and it was not a problem – but if this is typical of how they treat students here – you can keep Boston hospitality – not even remotely acceptable. I would not put my cat in the room they gave us. However, he turned up later than me – near midnight and as technical people often do, the moment he walked through the door we started chatting and I think finally gave up around 1am. We got along just fine.

MITIvan and Swee-AnSo first thing Monday I went off and bought a load of clothes. The Americans invented the term “convenience store” but I think they only meant that to apply if you have a car. Walking and taking the bus is not at all funny in the heat and so it was I arrived at the mall mid-morning to find the old American staples – CVS, Walgreens, J C Pennys etc..  I have to say for a country with some pretty large people I had difficulty getting clothes my size (at least with any choice) but came away at lunchtime armed to the teeth with new gear.

I’m not sure what I was expecting, but organisation was high up there somewhere but inside MIT campus, 30 minutes before our presentation, no laptops – eventually they turned up, half of them with the wrong power supplies rendering them useless.  As it happens it was not a full house and so we managed just nicely – talking about ESP8266, MQTT, Node-Red and finally a little about ESP-Arduino.

MIT[6]Of course in each of the three versions of the workshops we improved and I have to say by and large they went down very well. Clearly the organisers had done little to help promote us because I know the level of interest I get when I talk about ESP8266 and I was expecting a full house every time – still – all good fun. Yesterday in the middle of a heat wave, the heavens opened up and threw out some pretty amazing hailstones! I mean MONSTERS.

We went out at night – the first walk was rather too far for my airplane-equipped feet and I’ve been hobbling since. Amazingly despite having a medical dispensary within MIT itself and a near by Co-op (or as the lady kept insisting COOP as in soup – I didn’t like to tell her the name is made from two words) – no foot fixing kit, so being the inventive type I went off and bought a box of cork tiles and a pair of scissors – and DIY fixed the foot which is going to need some tender care when I get back to Spain.

MIT[8]Tonight I received my case at long last, I should say thanks but frankly I think Iberia have shown themselves to be a load of tossers up to now. Not only did they give me someone else’s reference number which confused the issue but the fact that I had important medicine in the case didn’t seem to phase them even slightly. Had I fallen ill while away things would be very different now – as it is lets see how promptly they cough up for the clothing and toiletries!

The end result of all of this however is enlightenment and a pretty good time generally. I’ve met some great people and learned some new stuff. Tomorrow I head back to Spain with new ideas, some new thoughts on China having spoken at length to the Chinese guys here – and generally feeling that this was another worthwhile adventure. I cannot, however wait to get back into the nice cool lake in Spain (I’ll never complain about cold water again) – heat can be a great thing but in a city built for commerce and not comfort in heat, give me the wilderness any time.

Next week I plan to write a blog with Ivan on the work he’s done with ESP8266-Arduino  which I have to say is pretty good – we’ll be driving a servo from a NETIO Android App – it’s so easy it’s like falling off a log. For now, I’ll leave you with some photographs. My thanks to Espressif and to Swee-An for looking after me and providing thought-provoking conversation.

Restaurants

Boston

FAB11

MIT[10]

everyone

Deployment Beckons

moisture sensorPlease note – this blog is WELL out of date and all of my blog items and much, much more have now been moved to http://tech.scargill.netI

’m now getting dangerously near the point where I have to DO something with all of this ESP8266 control stuff. We’re at the cave and I’ve a watering system to sort – a simple example – so one of the ESP012 boards has a relay on it and another has an ADC input. By the use a simple Node-red function combining timing and reading the ADC convertor (which is attached to a cheap Chines moisture sensor) and looking at the value coming out (already tongue-tested) I should be able to arrange to turn the watering system on and off twice a day – but also taking into account extreme levels of moisture either way (i.e. don’t’ bother watering the plants when it is pouring with rain… and give them a little extra when it is bone dry out there.  If I really trusted the moisture sensor I could do away with the timings – but I don’t – I am convinced the PCB-based sensor will corrode and die as the units are only £1 a time – they work incidentally from 3v3 to 5v and have 2 outputs – one is simply digital – you adjust the pot onboard to get a change of level from 0-1 etc at a certain level of humidity – the other output is analog –  I think I prefer the latter.  Anyway, one must try these things as they are cheap enough to put all over the place.

Yesterday however I came up with a problem. My wife, trying to fit a bulb in the dark, blew the fuses and of course the mains went off as did my broadband. On reconnect, it took the router a little while to get it’s act together – and I realised – the Raspberry Pi does NOT recover from no WIFI which means no controllers talking to each other.

This link to an article about using cron jobs and a script to reboot the PI  I’ve just implemented –very easy to do – just takes a minute or so… checks the router address every 5 minutes – and if it does not get a response – reboots the Pi. Hopefully that’s that problem out of the way. I already know that the little ESP boards with MQTT have a watchdog timer and so they reboot until they get a connection. Here’s hoping that is sufficient to guarantee operation under real-life circumstances.

A fine day for playing with solar panels

Galera

Please note – this blog is WELL out of date and all of my blog items and much, much more have now been moved to http://tech.scargill.net

7am here in Bedrock as we start our second full day in Andalucía.

It’s starting to look good already and this morning Maureen is off with some of the ladies to have fun while I sort out some tech work I have to complete via Skype with my friend Aidan in the UK.

testing solar panelsMy jobs for this weekend include getting the watering system back up and tested this time using an ESP8266 board with the Raspberry Pi controller which I’ve just spent several hours getting working thanks to a router that amazingly by default isolated users from each other (believe me that took some finding).. I’ve brought much more meaty power supplies (12v 6amp) with me to Spain this time to handle the rather unpredictable power here – though I suspect I’ve not brought enough.  As an experiment I brought another solar regulator along with an alarm 12v battery and panel –I want to see if I can run the router and  Raspberry Pi controller off the sun entirely. I suspect that’ll have to wait for our June/July run in which we’re bringing the car from the UK as I just could not fit my largest (40w) solar panel into the travel case!!

I’m quite excited today as the tech Facebook page just tipped 1000 likes…  but first, we need to get into that lake and enjoy the fine weather Andalucía is having right now, t was a little misty at 7am but already as 9am approaches, the sky is clear blue and will typically sail past 30c in the afternoon with peaks around 40c which might sound a bit much to Brits starved of sunshine but trust me – you get used to it if you’re neck-deep in a lake.

As you see below, my Arduino/NRF24L01 network has been working reliably over here, tracking temperature and humidity as well as giving me remote access to lighting etc. I have been logging temperature and humidity for a some time now) and the humidity is finally dropping rapidly – we picked a good time to arrive.

Graph of temperature and humidity

Just put the latest “Esp8266 unofficial” development kit on my laptop,  developed a MYSQL logging protocol for the little ESP boards and just about ready to start populating the place with controllers. I just need a little clearer understanding of the MQSQL  “Insert into… on Duplicate” code I’m playing around with here http://sqlfiddle.com/#!9/04c6c/1

For now I’m off with my OWNCLOUD-backed-up mobile phone, thanks to THREE network I have access to my unlimited data while abroad so no problem syncing up with servers. Nice.

Solid State Relays

Please note – this blog is WELL out of date and all of my blog items and much, much more have now been moved to http://tech.scargill.net – visit the site – sign up for much more.

SSRYesterday I published a blog about some little DIP solid state relays – and was reminded by a friend that these… http://www.ebay.co.uk/itm/351198840167?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT are cheaper and higher power if not so tiny – and he’s right – I have some and they work a treat. If you try them from GPIO0 on the ESP8266 however, make them + based not – based.. ie connect – to the output and + to the 3v3 supply of the ESP8266 which means you have to reverse your on/off logic.

I have one attached to a compact fluorescent light and it’s working a treat.

ESP8266 and Lost WIFI Connection

Please note – this blog is WELL out of date and all of my blog items and much, much more have now been moved to http://tech.scargill.net – many of the blog entries have been brought up to date – please visit the new site and register for much more.

Something those of you planning to use your ESP8266 units in remote installations might want to be aware of.  I’ve been working with TUAN who developed the MQTT software – now, I’m sure it has nothing to do with his code… but essentially, I’m using his latest software as the basis of a controller.

I’ve added a simple interrupt driven real time clock, refreshed by occasional MQTT message, I control output 0……GPIO0 – and I have a temperature sensor on GPIO2.

All of this works VERY nicely (some new updates from last night you might want to get from the GIT repository) – when the temperature drops below a certain level the output comes on etc, or I can manually turn the output on and off.  I can even store settings in FLASH having added a little section to the area that normally holds WIFI settings – all of this works perfectly.

BUT.. has anyone tried turning off the WIFI for a while…. and then turning it back on? Does your little board reconnect every time, reliably? Because in the real world of remote control that will happen.  I am finding that this is not always the case, that the code sits and tries to connect, maybe even seems to but ultimately fails. If the ESP SDK comes back with “STATION_CONNECT_FAIL” just what exactly should yo do about it?

Most of the time, simply disconnecting the ESP8266 board sorts the problem – if not the first time, the second time (and that in itself is a worry) – but that is no good if the board is actually controlling something – you can’t just reboot the board, you need to somehow reboot the WIFI while maintaining control over whatever it was you were doing…. or find another way to ensure that the WIFI reconnects every time.

The alternative is to use the board with an Arduino and have the Arduino reset the ESP8266 in the event of communication failure – but that’s really a bit of a cop out.

Thoughts?  (this is for C programmers, we’re not talking about LUA though I’m sure that is also worth testing).

Thanks to input here I’ve asked Tuan if it’s possible to update the code using the new 0.9.5 SDK + patch… and we’ll try again!

ESP8266 and JSON

Has anyone using the ESP8266 with the SDK had a go at using the JSON routines yet? I ask because I need to pass several MQTT messages to the board in a string.  I can of course do this the hard way, comma delimiter or similar, but it would be nice to try to use the JSON routines already in there. Anyone up for a simple example of use with 3 or 4 values passed to a string?

Please note – this blog is WELL out of date and all of my blog items and much, much more have now been moved to http://tech.scargill.net – visit the site – sign up for much more. There is a search facility in the new blog – and you can find all of these old items usually with a similar name.

For example…

http://tech.scargill.net/esp8266-and-json-2/

ESP8266 GPIO

Has anyone had a go at making a set of macros or defines in C to make the programming of the GPIO pins easier?

For people used to:

setMode(1,OUTPUT);

a cold sweat appears when confronted with

PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U, FUNC_GPIO12);

And if you’re only dealing with GPIO0 and GPIO2 then that’s not too hard, but we have commands to pull up pins, disable pull up, pull down, disable pull down, set as outputs etc…

Personally I’ve no idea which commands can be used on which pins and outside of GPIO0 and 2 I’m not even sure what commands CAN be used on which pins.

Is anyone aware of a simple concise set of documentation with examples for all the pins? Or has anyone done their own thing which would make life easier for others?

The nearest I’ve been able to find is this

http://g-lab.ca/esp8266ex-gpio-application-programming-interface/

and there are also some snippets of useful info here..

http://www.esp8266.com/viewtopic.php?f=13&t=273

However I’m still not clear in my head what can and cannot be done with each pin.

ESP8266 and the Dallas DS18B20 and DS18B20P

Please note – this information has now been superseded by the info on the new blog at http://tech.scargill.net – please visit the new blog.

Having wasted half the night following up dodgy temperature readings for the DS18B20P only to realise I’d left existing code running for the DHT22 !!!  I managed in the process to reduce the necessary code down to a minimum.

If you look at a previous blog in here I referred to some simplified Arduino code I’d written back in the dark ages and wondering if I could get similar here.  I’m only interested in temperatures to the nearest degree C for thermostatic control and was very concerned about the typical 1 second delay to read these chips.

I reasoned that if you were to read the chip before conversion then start a conversion off, your first reading would be rubbish – but subsequent readings would be fine without the delays associated with the more normal code.

So, here is what I ended up needing for a library – very little as you’ll see… most of it is comments…

 

/*
* Adaptation of Paul Stoffregen’s One wire library to the ESP8266 and
* Necromant’s Frankenstein firmware by Erland Lewin <erland@lewin.nu>
*
* Paul’s original library site:
*   http://www.pjrc.com/teensy/td_libs_OneWire.html
*
* See also http://playground.arduino.cc/Learning/OneWire
*
* Stripped down to bare minimum by Peter Scargill for single DS18B20 or DS18B20P integer read
*/

static int gpioPin;

void ICACHE_FLASH_ATTR ds_init( int gpio )
{
//set gpio2 as gpio pin
PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO2_U, FUNC_GPIO2);
//disable pulldown
PIN_PULLDWN_DIS(PERIPHS_IO_MUX_GPIO2_U);
//enable pull up R
PIN_PULLUP_EN(PERIPHS_IO_MUX_GPIO2_U);
// Configure the GPIO with internal pull-up
// PIN_PULLUP_EN( gpio );
GPIO_DIS_OUTPUT( gpio );
gpioPin = gpio;
}

// Perform the onewire reset function.  We will wait up to 250uS for
// the bus to come high, if it doesn’t then it is broken or shorted
// and we return;

void ICACHE_FLASH_ATTR ds_reset(void)
{
//    IO_REG_TYPE mask = bitmask;
//    volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
uint8_t retries = 125;
// noInterrupts();
// DIRECT_MODE_INPUT(reg, mask);
GPIO_DIS_OUTPUT( gpioPin );
// interrupts();
// wait until the wire is high… just in case
do {
if (–retries == 0) return;
os_delay_us(2);
} while ( !GPIO_INPUT_GET( gpioPin ));
// noInterrupts();
GPIO_OUTPUT_SET( gpioPin, 0 );
// DIRECT_WRITE_LOW(reg, mask);
// DIRECT_MODE_OUTPUT(reg, mask);    // drive output low
// interrupts();
os_delay_us(480);
// noInterrupts();
GPIO_DIS_OUTPUT( gpioPin );
// DIRECT_MODE_INPUT(reg, mask);    // allow it to float
os_delay_us(70);
// r = !DIRECT_READ(reg, mask);
//r = !GPIO_INPUT_GET( gpioPin );
// interrupts();
os_delay_us(410);
}

//
// Write a bit. Port and bit is used to cut lookup time and provide
// more certain timing.
//
static inline void write_bit( int v )
{
// IO_REG_TYPE mask=bitmask;
//    volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
GPIO_OUTPUT_SET( gpioPin, 0 );
if( v ) {
// noInterrupts();
//    DIRECT_WRITE_LOW(reg, mask);
//    DIRECT_MODE_OUTPUT(reg, mask);    // drive output low
os_delay_us(10);
GPIO_OUTPUT_SET( gpioPin, 1 );
// DIRECT_WRITE_HIGH(reg, mask);    // drive output high
// interrupts();
os_delay_us(55);
} else {
// noInterrupts();
//    DIRECT_WRITE_LOW(reg, mask);
//    DIRECT_MODE_OUTPUT(reg, mask);    // drive output low
os_delay_us(65);
GPIO_OUTPUT_SET( gpioPin, 1 );
//    DIRECT_WRITE_HIGH(reg, mask);    // drive output high
//        interrupts();
os_delay_us(5);
}
}

//
// Read a bit. Port and bit is used to cut lookup time and provide
// more certain timing.
//
static inline int read_bit(void)
{
//IO_REG_TYPE mask=bitmask;
//volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
int r;
// noInterrupts();
GPIO_OUTPUT_SET( gpioPin, 0 );
// DIRECT_MODE_OUTPUT(reg, mask);
// DIRECT_WRITE_LOW(reg, mask);
os_delay_us(3);
GPIO_DIS_OUTPUT( gpioPin );
// DIRECT_MODE_INPUT(reg, mask);    // let pin float, pull up will raise
os_delay_us(10);
// r = DIRECT_READ(reg, mask);
r = GPIO_INPUT_GET( gpioPin );
// interrupts();
os_delay_us(53);
return r;
}
//
// Write a byte. The writing code uses the active drivers to raise the
// pin high, if you need power after the write (e.g. DS18S20 in
// parasite power mode) then set ‘power’ to 1, otherwise the pin will
// go tri-state at the end of the write to avoid heating in a short or
// other mishap.
//
void ICACHE_FLASH_ATTR  ds_write( uint8_t v, int power ) {
uint8_t bitMask;
for (bitMask = 0x01; bitMask; bitMask <<= 1) {
write_bit( (bitMask & v)?1:0);
}
if ( !power) {
// noInterrupts();
GPIO_DIS_OUTPUT( gpioPin );
GPIO_OUTPUT_SET( gpioPin, 0 );
// DIRECT_MODE_INPUT(baseReg, bitmask);
// DIRECT_WRITE_LOW(baseReg, bitmask);
// interrupts();
}
}
//
// Read a byte
//
uint8_t ICACHE_FLASH_ATTR ds_read() {
uint8_t bitMask;
uint8_t r = 0;
for (bitMask = 0x01; bitMask; bitMask <<= 1) {
if ( read_bit()) r |= bitMask;
}
return r;
}

and here is the code that ended up in my timer callback routine, sending off an MQTT message for the temperature every 5 seconds – this works with both chips and works reliably.

    ds_init(2); // one off for the DS18B20

The above goes in my INIT routine – note that I’ve referred to GPIO2  – this will not work for other port bits as the Port initialisations seems to be partly hard coded – if anyone cares to re-write that so that anyone can easily access any of the usable pins.. would be nice..

I’ve also renamed the  routines, adding ds_ at the start to avoid confusion with other routines.

And now  for the actual code.. I call this every 5 seconds for testing and as you’ll see there’s a little extra code to send this out via MQTT. The extra code is in bold. “Temperature” is an integer defined elsewhere.  As you can see, no search, no checksum, no delay for processing – this works with both the DS18B20 and the DS18B20P chips.

char *tBuf = (char*)os_zalloc(6);
ds_reset();
ds_write(0xcc,1);
ds_write(0xbe,1);

temperature=(int)ds_read();
temperature=temperature+(int)ds_read()*256;
temperature/=16;
if (temperature>100) temperature-=4096;
ds_reset();
ds_write(0xcc,1);
ds_write(0x44,1);
os_sprintf(tBuf, “%d”, temperature);
MQTT_Publish(&mqttClient, “temperature”,tBuf,strlen(tBuf), 0, 0);
os_free(tBuf);

And so how to test all of this. For the life of me I can’t find a simple, no-nonsense program to read MQTT and graph it – you would think there would be loads around – I have asked the writer of MQTT-SPY if he’d like to add something into the program – for what’s out there – you seem to have to sign up and go through a whole learning curve – a little excessive for what I wanted (i.e. MQTT in – graph out), so I hooked up Node-RED to simply store the incoming data in a file.

node-red
And now having that information in a simple text file, it was easy to graph in EXCEL but again a whole FAFF to simply update dynamically until I discovered Live-Graph – not the prettiest but set to read the file every 5 seconds and update the graph –  I have to say it works a treat.

Here is my little sensor, as it happens the P variety I was originally having problems with, happily monitoring the ambient air temperature with a little excitement added on two occasions from my Dust-off air blower which is able to freeze the life out of the sensor on demand!

plot[3]

As you can see, the code is working well – doesn’t even need averaging.

ESP8266 C FLASH Saving of Variables

While I’m off in search of a C one-wire library, has anyone saved any variables to FLASH (hence non-volatile) – and if so would they care to give the simplest C code example of how to do that?  I (and no doubt others) would like to save some strings and integers permanently or semi-permanently – or even perhaps some log info – we have loads of Flash but personally I’ve not idea which bits I can safely use or how to do the read and write….  So kind of like the equivalent of Arduino EEPROM library.

Please note – this information has now been superseded by the info on the new blog at http://tech.scargill.net – please visit the new blog.

Lua and the DS18B20/DS18B20P temperature sensor

DS18B20 or DS18B20PA 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 http://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