esp8266 - mqtt

I am moving here the discussion that was in a workshop entry.

I am playing with my program tRead.lua (which is an abomination of a program by the same name from Deryn).

At this stage I managed to get a version (tRead-2.lua) that runs reliably if it get though the first iteration). The main change here is that I added a m:close() following the m:publish(). The publish callback is never called, yet the data gets though.

The dsleep is in the m:on("connect") called back and I changed to to 2 seconds (I am impatient).
I also used a timeout of 2 seconds for the mqtt client with the hope that this will get us going if things get stuck. So far it does not look like doing so.

Good progress. I realised that I could always require("ds18b20") from the command line but not from a program, even a very small one. So I suspected that the environment where init.lua runs is heavily loaded, and thus changed the program from being loaded into init.lua to tRead.lua.

init.lua is now:

tmr.alarm (1, 10, 0, function () dofile ("tRead.lua") end)

and things work (no memory shortage). I had this running while I attended the MHV video night, for over two hours (almost 1300 wakeups after 2s dsleep).

Naturally, this is with my latest fw that does not have the hanging wakeup problem.

After many tests it seems that the wakeup problem is truly gone (as of fw 20150212).

Breaking the program into parts chained with dofile()s saves some memory.

Compiling the programs into .lc saves some memory (as of 2015/02/13 but official fw not yet released, I uploaded mine).

All in all, using lua is nice but memory limit suggests that any non-trivial commissioned application probably should be native code directly over (or in) the sdk.

Thanks for the info Eyal. Good to hear that problem is fixed.

How do we compile the script? Is there an inbuilt function in the new firmware to compile in the ESP? Or are you compiling on the PC?

See my recently uploaded example 20150214-1431.

1 Like

This document
http://www.cnx-software.com/2014/11/19/dwa8-esp8266-wi-fi-module-supports-10-bit-adc-up-to-8-gpios-4-pwm-outputs-and-more-crowdfunding/
says: “Espressif Systems ESP8266 32-bit RISC processor @ 80 MHz with 120KB RAM (40KB usable)”

It also shows a nice module that exports many more pins. It was a failed crowdfunding but seems to be on sale on taobao (but I cannot read that page).

So lua uses much of the abovementioned 40KB before our programs get to have a go.

I had the program run tonight (on battery) in the bedroom (1m iteration). It died after about 5 hours. I could not use it until I blanked the fw and flashed a new one.

Later test this morning also dies after a while (this is on a 5s sleep):

NodeMCU 0.9.5 build 20150213-2202-eyal  powered by Lua 5.1.4
run 487
> $¦¦@
¦¦¦¦¦

NodeMCU 0.9.5 build 20150¦$¦¦¦¦@
¦=¦¦¦¦¦

NodeMCU 0.9.5 build 20150213-2202-eyal  powered by Lua 5.1.4
lua: ?:0: attempt to perform arithmetic on global 'runCount' (a nil value)
>

The error is interesting, and I suggest that the problem is with the file system. It failed to read the runCount file which is re-written at the start of each iteration.

I wonder if there is another way to keep some data across restarts. Maybe some register is maintained along with the sleep timer?

Further to the above, I removed the runCount tracking (so no file writes) but it still fails after a while.

After these failures I must re-flash as I did not find a way of avoiding this.

[later] I replaced the battery input with a USB charger. The no-write test completed 1000 loops before I killed it. I am now running the full test (counting run numbers) and we will see.

1100 loops so far. Time to go back to battery and see if it dies again.

OMG, accidentally left the voltmeter connected and saw that the voltage is only 2.8v. from the 3.3v output. It is 3.9v out of the 5v so I will now use this.

So, was I looking at a power issue all this time? Sad…

Running on the 3.9v … worked well and stopped at 650 iterations.

I now moved to using a small adjustable DC-DC set to 3.3v and am running a test. Fingers crossed.

So far so good, test stopped.

I now confirmed that the problem is not the 5v/3.3v attachment but the battery. After exactly 1 minute it drops from 5v to 4v. This is unexpected, and may be in response to the low power usage? Here is an example of the data published by the test rig. The columns are date/time, runCount, time, readvdd33(), temp
Notice how at after run 20 vdd drops from 3.2v to 2.7v. Some time later it will die.

20150216154225  9 2830497 3.194 26.5
20150216154230 10 2802349 3.205 26.5625
20150216154235 11 2820747 3.206 26.5625
20150216154241 12 2903959 3.207 26.5625
20150216154246 13 2817140 3.209 26.5625
20150216154251 14 2769595 3.208 26.5625
20150216154256 15 2821660 3.210 26.5625
20150216154302 16 2806267 3.209 26.5625
20150216154306 17 2823125 3.211 26.5625
20150216154311 18 2813864 3.215 26.5625
20150216154316 19 2794999 3.211 26.5625
20150216154321 20 2772898 3.213 26.5625
20150216154327 21 2783713 2.691 26.5625
20150216154332 22 2910990 2.673 26.5625

The above has a 2s dsleep, and the program takes about 3s to run, so an item is published every about 5s.

I am now using another battery and it does not exhibit this “feature”. I will let it run in the bedroom for a day and see how it goes. Fingers still crossed.

Hi Eyal,

There’s been lots of postings about these unreliabilities on the nodemcu git-hub channel. It doesn’t look like the lua firmware is production ready as you’re pointing out.

They are working on it though, and are getting through issues.

At the moment it looks like it’s just at proof-of-concept or Alpha status.

Look at my ongoing report. The memory shortage can be improved with some techniques (compile in the upcoming fw). The wakeup seems to be sorted now (fw 20150212).

I am actually rather optimistic now compared to a couple of weeks ago.

Me too.

Last night I got the ESP8266 mounted to the back of a I2C-CharLCD. Also, I started on a better breakout board with more pins.

Plus, I made up some better USB adaptors that make the wires-go-away. I’ll bring them.