Defender NodeMCU Design

The Arduino project has inspired me to further document the Defender IOT Controller project. I am quite ambivalent about doing so because of the potential for harm and mayhem this may cause. But I thought I would get started with this massive project, which rivals or exceeds creating the substitute controller in scope. The documentation and supporting materials are about 40% complete. Your kind comments and suggestions via this forum topic will be much appreciated. We are looking for errors and omissions. When the topic is completed, I can make the decision to "pull the trigger" and post the controller source code. I am very uncomfortable with the notion of publishing a knowingly incomplete and inadequate design for a potentially dangerous product. Some discussion on this point would also be helpful.

The work in progress can be found at Defender IOT Controller Add-On Construction Details.

The Defender IOT Controller Add-On Construction Details documentation project is now about 85% complete. See the previous post for details.

I now have to turn my attention to my poor Defender. After being without propane for 2 weeks, it started up with fresh propane and ran for about a week before the On-Off switch failed (again). An intermittent switch is costly because it uses up the igniter with repeated restarts. Fortunately, it failed hard off, which was "fixed" by operating it on and off rapidly several times (to displace contamination and oxidation). Time for more DeOxit.

As if that's not enough, after a few hours, near the time of a rain storm, the combustion temperature sank from 115°C to about 75°C to 85°C, a problem I wrestled with last year (see the blog). Restarting the ignition cycle has temporarily fixed this problem for now, but I know it won't last. Please wish me luck.



Edited 1 time(s). Last edit at 08/29/2019 02:19AM by dev.

Wow!

That is some serious work! The WiFi capability is really cool.

I tossed my original Defender control board (mostly out of pure frustration!)...but looking at the images you posted, do you know why there is such a massive capacitor on the board?

The big heat sink on the one MOSFET must be for the igniter, based on how how the one on the Mega got.

Good stuff!

"I tossed my original Defender control board"

Oh, no. I was going to ask you to send it to me. Really?

The massive capacitor is 3300 uF @25 volts for the +12v rail. See the controller wiki. The big heat sink is for the 12 volt regulator, which must drive the fan and solenoid. The mosfet is just soldered to the PCB, and I haven't noticed it getting hot.

I envy those whose traps modifications "just work." The blog writes about a chronic nasty problem of combustion abnormality that is apparently going to require a step up in instrumentation to solve. Accordingly, the NodeMCU design may be significantly upgraded to add tank weight and a temporary gas pressure measurement, although I wonder how many would need these increased capabilities. Your comments here would be most helpful.

You guys are leaving me in the dust. :-) This is going to be a winter project for me.

Hooray! My poor Mosquito Magnet Defender is now working reliably. No more odd fundamental abnormal combustion problems. It was the regulator. For a blow-by-blow, see the blog. I am now testing replacement regulators. I purchased three new ones. None of them are exact replacements for the originals. So far, one of them failed to provide a steady constant flow in the Defender, although it will likely work fine for its intended purpose of barbecue. The other two are still in testing, time will tell how well they work.

i always felt that the regulator was a problem point after finding powdering inside the aluminum housing on the failed original. i tried several replacements with little success, and i could never find the original italian version.

I spoke too soon! After testing 3 new regulators, and finding 1 of them lacking, the trap suddenly started to exhibit abnormal combustion, leading to fault shutdown. Yes, the outside temperatures were cooler, but still, the season is not over. I repeatedly tried to restart only to find more or less immediate transition into this state. With two new, highly rated regulators not preventing this failure, it had to be something else, but what?

Look hard enough, and you will find a problem. My problem was that I was using the wrong nozzle. Switching back to what I now think is the correct replacement nozzle, freshly cleaned, the trap started perfectly and has run for more than a day with no problems. The replacement nozzle burns hotter, yielding a measured thermistor temperature rise of 105° instead of 95°C. I am hoping the more robust burn will isolate the combustion from small variations in gas pressure to keep the system in normal 100% combustion, instead of the mosquito-repelling incomplete abnormal combustion.

For more details, read the blog.

Read it all. So should I be using the MEGR-230 on a Liberty, and what actually is the correct nozzle for a Liberty?

Thanks!

To avoid confusion with the Defender, I will answer this on your Liberty post thread.

"Read it all. So should I be using the MEGR-230 on a Liberty, and what actually is the correct nozzle for a Liberty?"

The Defender started without incident, and has been running since the end of May. The first tank captured 275 mosquitos and 30-50 times that of tiny flies (no-see ums). You can easily see the MQTT real-time telemetry. Use a web based client, enter the host "broker.hivemq.com", hit connect, add a new topic subscription, and subscribe to "MMD/esp11817981". The status updates once per second. As of this writing, it was:

Temp=124.6C (0) at 5:16479 F=1 I=0 G=1 S=1 E=0 T=33.4C H=56.4% M=11360 (221/1010:5272) R=70~140 B=1.0 V=3.1

For an explanation, see Message Format on the construction details wiki.

This wiki page is long and complex, and includes warnings and specifications, etc., that are not instructions. See the blog.

I am running a new version of the software that simplifies construction, improves performance, and can be further enhanced. This new version will require rewriting the detailed directions, but I am unsure how to proceed. I would appreciate feedback on the forum for suggestions of rewriting the documentation to make it more accessible.



Edited 1 time(s). Last edit at 06/25/2020 03:30PM by dev.

Having a bash at this at the moment - Lua is a bit of a learning curve with respect to nodemcu. Getting there though. Did you ever complete your nodemcu design?

Yes, indeed. The newest file has a timestamp of 7/23/2020. It worked fine and caught quite a few mosquitos.

Learning lua was not that easy for me either. I had to get used to the event-driven nature of the NodeMCU SDK, which acts like a sort of operating system. Also, before using the NodeMCU improvement to allow lua code to run from eeprom (I think), every byte of memory was so precious, much of the development time was in saving a few bytes here and there.

What was really great about it was the MQTT remote control, ftp OTA updating, and web page configuration. No more trips outside in the rain (or biting mosquitos)!

The system is off the air now, put away in that garage, waiting for the season to begin. But spring is a fine time, with new growth and no biting mosquitos, yet, so all is ok.

I was following your Defender IOT construction guide wiki - very informative.

Did you consider releasing your code? It says at one point 'Download and unzip the latest software into a folder' but can't see any links.

Would like to give it a bash if and when you do?

J

Quite a project, "releasing code." The previous version was dated July, 2020, but the NodeMCU system has advanced well beyond this. Accordingly, the system has been updated to the latest version. The Defender source code didn't change much, but a few additional features, such as an ftp server and 'telnet' server, have been added to support remote development and updating. Also, a much smaller processor board, the WeMos D1 Mini, promises to provide identical functionality with a smaller footprint.

This means that the documentation is way out of date. But today there is a new schematic with the smaller board (the original NodeMCU still works), and an attempt to note some of the major differences between the older system and the new one. This has not been tested on a unit as of now, but there is an unused Liberty that perhaps I can install this into for testing (although I don't know what to do about those additional LEDs, and the On/Off pushbutton switch).

The software is in a link at the start of the slightly updated Construction Wiki page.

Use this forum for support.

Weekend reading! Looks good, thanks for sharing.

It's beginning to look a lot like mosquito time. The source code to the NodeMCU Defender Add-on was released 2 weeks ago, and I am in the process of updating my Defender and adapting the system to my old Liberty. The software is in a link at the start of the Construction Wiki page.

In testing the released software, the web interface failed to update the MQTT settings, and crashed. This occurred because the web server was not initialized, a statement was missing from the DefMain.lua module, which is compiled into the LFS package. After the modified units are deployed and working, an updated bug-fix release will be posted. In the meantime, the missing statement should be added to the existing DefMain.lua module module.start() function, and DefMain.lua downloaded into the NodeMCU to override the pre-compiled version, and the web server should then work to update settings.

function module.start()
  setPost("")	-- dev_2021-06-13 - forgot this....

  t6.stop(t6)
  t6.alarm(t6, 10, tmr.ALARM_AUTO, timer100)
end

Edited 1 time(s). Last edit at 06/16/2021 02:05PM by dev.

I got the new NodeMCU software up and running in the 2002 Defender last night, but there were temperature and mechanical issues, otherwise so far so good. See the blog.

I've got a packet of the wemos d1 mini pro devices and am working my way through the installation doc.

Flashed the unit with the 2 files supplied as follows:-

C:\NODEMCU\esptool>esptool -p COM5 write_flash -fs 32m -ff 80m --flash_mode dio 0x00000 0x00000_3.0.0-128-16_20210602_2233.bin 0x10000 0x10000_3.0.0-128-16_20210602_2233.bin
WARNING: Flash size arguments in megabits like '32m' are deprecated.
Please use the equivalent size '4MB'.
Megabit arguments may be removed in a future release.
esptool.py v3.1
Serial port COM5
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 48:3f:da:5a:38:89
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00007fff...
Flash will be erased from 0x00010000 to 0x0007afff...
Flash params set to 0x024f
Compressed 31216 bytes to 22645...
Wrote 31216 bytes (22645 compressed) at 0x00000000 in 2.2 seconds (effective 111.0 kbit/s)...
Hash of data verified.
Compressed 438272 bytes to 307801...
Wrote 438272 bytes (307801 compressed) at 0x00010000 in 27.4 seconds (effective 128.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

I then ran up ESPLORER , got the 'Cant autodetect firmware..' message. Pressed the reset button. Got a single line of gibberish - and then nothing more.

Didn't get anything further - didn't say No LFS image loaded and no summary of the system.

Any ideas? What am I doing wrong?

Just to add - I've tried this on 2 different wemos d1 pro boards, both of which gave the same result. Went back and tried an ESP32 and it worked straight away - got the full 'NodeMCU 3.0.0.0 built with Docker' message as soon as I opened the port in ESplorer.

Midge Wrote:

... 2 different wemos d1 pro boards, both of which gave the same result. Went back and tried an ESP32 and it worked straight away...

I haven't tried it on the Wemos D1 Mini PRO board, just the Wemos D1 Mini (not PRO). AFAIK, the PRO board has no internal antenna, adds an external antenna connector, has 16 MB flash instead of 4 MB, and uses a CP210 instead of a CH340 USB interface chip.

The bin files were compiled for a 4 MB flash size. I don't know what happens when you flash a 16 MB flash with these files -- this may be the problem. Try a D1 Mini (not PRO).

I suppose you need an external antenna for better WiFi reception. My Defender is experiencing a really lousy WiFi signal (-77 dBm), but it seems completely reliable, even in the presence of stronger (outside the house) WiFi-6 interference from neighbors that disrupts other devices such as cameras and internet radios inside the house.

Temp=104.5C (0) at 5:158446 F=1 I=0 G=1 S=1 E=0 T=25.2C H=56.6% M=26736 (342/1024:9439) R=70~140 W=-77.85 B=0.0 V=3.5

I then ran up ESPLORER , got the 'Cant autodetect firmware..' message. Pressed the reset button. Got a single line of gibberish - and then nothing more.

Just a quick check: does the ESPlorer RTS button work to reset? Have you tried changing the baud rate on ESPlorer to display the gibberish? On the WeMos D1 Mini, using 74880 as the baud rate displayed

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 28596, room 16 
tail 4
chksum 0x79
load 0x3ffe8000, len 2572, room 4 
tail 8
chksum 0xb3
load 0x3ffe8a0c, len 8, room 0 
tail 8
chksum 0x4c
csum 0x4c
system SPI FI size:4, Flash size: 4194304
boot not set
ota1 not set
ota2 not set
rf cal sector: 13
freq trace enable 0
rf[112] : 00
rf[113] : 00
rf[114] : 01

SDK ver: 3.0.1-dev(fce080e) compiled @ Apr 16 2019 15:02:05
phy ver: 1145_0, pp ver: 10.2

before it switched to the 115200 baud rate for the normal sign-on after the "gibberish."

Perhaps a 16 MB flash version is required for the PRO, or at least, perhaps different settings for the esptool, including first erasing the flash, a step left out of the instructions:

esptool.py.exe -p COM3 erase_flash

Also, it wouldn't hurt to accommodate that "WARNING: Flash size arguments in megabits like '32m' are deprecated. Please use the equivalent size '4MB'." message and change the esptool command line, which I suppose would be different for the 16 MB pro.

I'll look into getting a D1 Mini Pro and antenna, and see what happens. Let me know what external antenna you use. I will order the same model to test. This will take a while. In the meantime, try the D1 Mini. Certainly play with the NodeMCU and set up your MQTT destination, WiFi setup, etc. These settings are saved in the config.lua and eus_params.lua files, after a successful WiFi setup. You could upload these files, edit them as desired, then download them to another board. If you wish, let us know your MQTT endpoint.

Hope this helps. Good Luck!

There are so many clones of these things. The one I've got has a ceramic internal antenna with a zero ohm link connecting it to the module. To use the external antenna, you have to unsolder the smt link and swing it 90 degrees to put the connector into circuit.

With the ESP32 I've gotten further, but having uploaded def_lfs.img with Esplorer and run node.flashreload("def_lfs.img") , it hangs with an error of init.lua:27: attempt to call field '_init' (a nil value)

I'll see if I can find the mini, not pro on amazon and try again in a couple of days.

Happy Fifth of July!

Midge Wrote:
With the ESP32 I've gotten further, but having uploaded def_lfs.img with Esplorer and run node.flashreload("def_lfs.img"), it hangs with an error of init.lua:27: attempt to call field '_init' (a nil value)

I have not been able to duplicate your issue. I erased a D1 Mini and programmed if with the .bin files, then uploaded and ran node.flashreload("def_lfs.img"). This causes the NodeMCU to reboot:

node.flashreload("def_lfs.img") 
Warning, deprecated API! node.flashreload. ...
LFS region updated.  Restarting.
...
NodeMCU 3.0.0.0 built with Docker provided by frightanic.com
...
 build 2021-06-02 22:23 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
cannot open init.lua: 

I then uploaded: FWinfo.lua, Wifi_0.jpg, arctile.jpg, conf.htm, config.lua, favicon.ico, init.lua, mosqtile256T.gif, nf.htm
and reset:

NodeMCU 3.0.0.0 built with Docker provided by frightanic.com
...
 build 2021-06-02 22:23 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
i	41520
's6()' within 5 seconds to stop running
> renaming 'def_lfs.img' to 'def_lfs_X.img'
loading and restarting
Warning, deprecated API! node.flashreload. ...
LFS region updated.  Restarting.
...
build 2021-06-02 22:23 powered by Lua 5.1.4 on SDK 3.0.1-dev(fce080e)
i	41520
's6()' within 5 seconds to stop running
> R	41832
starting system
...
H	29152
Temp=-43.7C (-43.7) at 0:0 F=0 I=0 G=0 S=0 E=0 T=128.8C H=118.9% M=30728 (3/3:18804706) R=70~140 W=nil. B=-19.0 V=3.5
state = 0 was 7 at 1 (0)

and the software started running normally.

When run for the first time, the init.lua module checks for a new LFS image, renames it, and reloads the flash from it. This step seems to be missing from your experience.

Also, the call to node.LFS._init() happens on line 24, not line 27 in init.lua, although I don't know if the line number discrepancy is relevant or not.

You should have been able to halt the system start by entering "=s6()" within 5 seconds. Don't forget the '=' sign. Does the message not appear, or does that not work for you? The message should say "Enter '=s6()' within 5 seconds to stop running." I have =s6() programmed as one of the code snippet buttons.

If init.lua doesn't just stop and reboots over and over again, you should try to rename or delete init.lua to something like "initx.lua." If you cannot do that, erase, reprogram, load the LFS, and upload the other files, but, this time, rename init.lua so that it won't execute on reboot.

The system should now just stop after reset. You can send it commands to see what's what. Try these:

for a,b in pairs(node) do print(a,b) end
for a,b in pairs(node.LFS) do print(a,b) end
for j,k in pairs(node.LFS.config) do print(j,k) end
for j,k in pairs(node.LFS.list()) do print(j,k) end
node.LFS._init()

The list (2nd to last) statement lists the modules in the LFS:

for j,k in pairs(node.LFS.list()) do print(j,k) end
1	DefMain
2	StationAp
3	_init
4	ads1115
5	bme280d2
6	bmp180d
7	dummy_strings
8	ftpserver
9	htu21d
10	hx711
11	mqtt_svr
12	telnet_svr
13	www

The last statement runs the _init() function, which sets up lua to return the location of a module loaded by init.lua (and other modules) if it finds the module in the LFS but only after not finding in the file system.

The other suspicious thing is that error line number discrepancy. Did init.lua get corrupted somehow? The _init() function should be in the LFS. I suppose it could be run from the file system, but we should get it to work in the LFS.

If this doesn't work, please capture the screen output from a freshly erased board, as you load the LFS and other files.
Edit out repetitive blocks of sign-on and the gibberish characters which frequently prevent display or truncate the listing.
Zip the listing, and post it here. somewhere, and include a link. (I don't believe this forum accepts zip files, perhaps this could be changed somehow.)

Zip files have been enabled! To demonstrate, here is the 2021-06-03 software: Defender_3r5_LFS_2021-06-03.zip



Edited 1 time(s). Last edit at 07/05/2021 08:39PM by dev.

Success!! def_lfs.img had got corrupted on my system somehow. I deleted it and re-extracted it from the archive and it works as above.

I got some mini boards today (not pro) so have a selection to play with.