As the blog entry on using my home control code ROMS for ESP8266 is filling up and of course as much of the information is now dating I thought I’d do a new blog to bring everyone up to speed and move the conversation to this blog entry. The good news is – the code is now running under SDK 2.1.0 – i.e. bang up to date at the time of writing.
Firstly – yes, everything works – but the procedure for flashing ESP-12 etc has changed ever so slightly. I have updated the binary files to run on Espressif SDK 2.1.0 and updated the RBOOT code I use for OTA (over-the-air updating) to the latest version.
To backtrack a little…
For anyone new in here – some background – with help from several people and gleaning information from several libraries, I’ve written software to work with the ESP8266 SDK (not Arduino software) which has been in operation for some time, is very reliable and is subject to continuous development. It allows the ESP8266 to control things like simple lights, serial LEDs, PWM LEDs, handle various displays including I2c and SPI – and reading sensors etc, talking via WIFI and MQTT to whatever central system you have – for example a Raspberry Pi with Node-Red. I’ve written a node to allow endless units to log in and to provide central communications for them.
I use Windows to develop the software using the Cherts unofficial development environment environment. This provides an IDE using Eclipse for running and compiling C code. It is not necessary to use any of this if you simply FLASH the ROMS which are available – but of course if you do use the IDE you can customise code for your own use. The projects Home Control 2017 and Nextion WiFi Touch Display both use the same software and are the end result of many years developing home control. Personally I access much of this equipment using Apps like Blynk and more recently Imperihome (see also this article, this and this) and of course the wonderful Node-Red dashboard. Tools I use in Node-Red include my own BigTimer node. All of these options were chosen after much deliberation.
So what have I learned and what has changed?
All has been going well until early 2016 when the Espressif SDK for ESP8266 was updated, firstly to 1.54 then very quickly followed by 2.0 and all of a sudden I and other started to have issues starting up ESP8266 boards. This was resolved at version 2.0 and now I’m using 2.1.0 which increased available RAM by some way..
Firstly one of my problems was lack of serial output on power-on. Some serial (115Kb) status messages I have on power up, just point-blank refused to show. I figured the code might be starting at the wrong place. But no, a quick port flick at power-up proved that everything was working – but no serial out.
After much debugging, I discovered that there would be no serial output until this function:
wifi_set_opmode(0);
had been called. Prior to SDK 1.54 this was NOT the case. Simple enough – I put this at the start of my code – I checked and web updating works just fine – but merely moving this function to the start solved all the serial output issues.
Incidentally much is made of the “garbage” that comes out of the ESP8266 on power up – it is just that Espressif chose to use 78,600 baud instead of a more popular speed like 115200 baud. If user software is set to this speed rather than, say, 11500 (which is what I use) then things look very different – diagnostic on power up followed by user code – all very seamless. Problem is – not that many serial terminals support 78k.. but I digress.
The second problem was a tendency for the unit to run away with itself on power-up, firing out garbage as if the ESP-12 was broken. It would SEEM that post-SDK-1.53 or thereabouts – it is NECESSARY on initial run, to flash location starting 0x3fc000 (end of the 4th page in a 4MB Flash chip) with the default file esp_init_data_default.bin which is found in the Espressif development kit. If this has already been blown (previous installation) then it is not necessary to redo that, but with a CLEAN FLASH, failure to flash this area results in the continuous rubbish on output. Again this did not seem to be the case before SDK 1.53/4 – I have NEVER flashed that location in the past. Once blown it is not necessary to blow this again for OTA. Still – now we know. This should not be confused with startup issues due to insufficient power.
At the time of the problems, I had a Skype chat with Espressif engineers to try to dig deeper. They confirmed that the small file at the end is essential (I probably didn’t notice it before as I’d generally be using boards already programmed).
System Data
There are 2 relevant files here. A file called blank.bin sits at 0x3fe000 (top of the third MB in a 4MB Flash i.e. ESP-12) and contains default system parameters produced in the SDK. NOT setting this initially seems to have no effect on my code.
A file called esp_init_data_default.bin sits at 3fc000 (again near the top of the last MB) and contains default system parameters stored in the SDK. This is a 1K file. This HAS to be blown when first setting up a chip.
What to do
There is a binary file called esp_init_data_default.bin which I have added to the server at http://roms.scargill.net – this is in addition to rboot.bin and rom.bin
In the Espressif setup there is a file called ESPTOOL – there are exe versions and .py versions of this floating around (see below). This is what I use to flash the ESP8266 chips – there are others – you may use them – but I can’t VOUCH for them!
https://github.com/themadinventor/esptool
https://github.com/metalheart/esp8266/raw/master/bin/esptool.exe
In Windows this works for me – you will have to check for yourself.
To completely wipe an ESP12 board (I no longer support the ESP01 as the 512K Flash is now too limiting) – including all data and setup etc and assuming COM3 in this case (not necessary but if it makes you feel better)…
esptool.exe -p COM3 -b 115200 erase_flash
To initially flash the code from scratch… assuming you have the 3 files mentioned above…
esptool.exe -p $(COM3) -b 115200 write_flash -fs 32m -ff 80m -fm qio 0x00000 rboot.bin 0x02000 rom.bin 0x3FC000 esp_init_data_default.bin
Obviously you can change port, speed and file locations. I usually double up on that baud rate but this one is safe.
The observant user may note the main ROM file is called rom.bin and not romx.bin – I recently made a break from the old ESP-01 boards and hence I thought it would be better to make a clean start. Existing boards on the old roms may lose user setup on first update and the OTA address has changed anyway as slow site access was causing occasional “OTA failures” which were in fact not failures -they were timeouts.
As an alternative, I’ve tried NODEMCU FIRMWARE PROGRAMMER and that seems to work…
![Nodemcu[6]](https://tech.scargill.net/wp-content/uploads/2016/07/Nodemcu6.jpg "Nodemcu[6]")
Note in the photo above the old romx.bin name is used – you should use rom.bin instead.
And so there it is – the source is updated on the web and you should use Espressif SDK version 2.1.0. The ROMS of course are updated and the new file is up there so ROM users need not concern themselves about the SDK.
Bear in mind there is some data here NOT being erased (see full erase command higher up) – in my case at 0xF9000 – near the top of the first megabyte – this is USER data – leaving the best part of a MB for code – plenty of room.
And why?
Why worry about updates indeed? Well, one good reason – is that recently, updates to the SDK have used LESS precious RAM – the kind that programs (not data) run in – so with 2.1.0 there is more margin for expansion – which means more features and more room for more features! It is fine having 1MB to put code in but that is generally NOT the limiting factor with the ESP8266. The code ultimately has to run in RAM and there’s a slight bottleneck there – the gains of later SDK updates help a lot.
Update June 2016
Having now added i2c and parallel LCD displays to the board, I set a parallel LCD running from MQTT and updating all 4 lines of the display, once a second from Node-Red. While this was running (it’s been running all afternoon – I thought I’d try a test)… I set my serial terminal program fire out lots of on-off commands in a row – which is WAY over the top…
I set up 30 on/off commands for GPIO0 – to run at 80ms each (I no longer use GPIO as an output) – as you can see, clean as a whistle. I dropped that to 50ms per instruction and the board rebooted – I’m guessing that is a buffer overflow – but then – that simply is not going to happen in real life or anything like it.
I figured I’d go for broke – with 390 (I got sick of cut and paste) commands sent at 80ms it lasts almost to the end then rebooted – again a sure sign of the buffer being in trouble either overflow or wrap – backing that off to 100ms gave zero errors so not a wrap issue –
Very happy with this – typically the boards get no more than a few instructions a seconds – often MUCH less. For the sake of it I may just take a look at this – firstly to see if at such speed, my terminal is screwing up – and if not – I’ll see if I can narrow that down but it is utterly academic
A complete and utter aside
I don’t use the Arduino setup but as I was thinking about user data, I just checked the Arduino EEPROM library SOURCE for ESP8266 and the Arduino environment does NOT use the 3-sector trick employed in the SDK. When you update the EEPROM (which is actually FLASH on the ESP8266), the sector is wiped (even if you have user data smaller than 4k, a 4k sector is still used) and then updated from RAM – not ideal. I have suggested to the designer that it might be a good idea to change this. Right now he’s busy working on ESP32 code.
Update 11/07/2017
Added in more code for the colour PCI display and now added in the ability to handle the neat 32-pixel or 64-high SSD1306 OLED modules – which are very cheap also some SPI-based boards – see the manual.
Update 08/10/2017
Added support for the INA219 voltage/current monitor, the SHT30 temperature and humidity sensor, added in deep-sleep software to turn boards off for up to 7 hours (for which, after setup you need to connect GPIO16 to reset), saved a load of RAM and made other improvements to the startup and debug information. As always, see the manual and also read about QIO and DIO modes as some WEMOS boards use a different FLASH chip and need a minor mod to programming mode.
sorry to bother you ot was a missing DLL VCRuntime140.dll
i tried compiling in eclipse using makerjays instructions but get this error.
Makefile:110: recipe for target ‘C:/Users/Doug/eclipse-workspace/scargill-esp-mqtt-dev-b7de8c23b776.zip_expanded/scargill-esp-mqtt-dev-b7de8c23b776/build/rboot-hex2a.h’ failed
mingw32-make.exe[1]: Leaving directory ‘C:/Users/Doug/eclipse-workspace/scargill-esp-mqtt-dev-b7de8c23b776.zip_expanded/scargill-esp-mqtt-dev-b7de8c23b776/rboot’
C:/Users/Doug/eclipse-workspace/scargill-esp-mqtt-dev-b7de8c23b776.zip_expanded/scargill-esp-mqtt-dev-b7de8c23b776/Makefile:210: recipe for target ‘firmware/rboot.bin’ failed
mingw32-make.exe[1]: *** [C:/Users/Doug/eclipse-workspace/scargill-esp-mqtt-dev-b7de8c23b776.zip_expanded/scargill-esp-mqtt-dev-b7de8c23b776/build/rboot-hex2a.h] Error -1073741515
mingw32-make.exe: *** [firmware/rboot.bin] Error 2
I have problem when build this code with Eclipse
This is error
CC easygpio/easygpio.c
CC rboot/appcode/rboot-api.c
CC rboot/appcode/rboot-bigflash.c
AR build/app_app.a
LD build/app_0.out
c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/5.2.0/../../../../xtensa-lx106-elf/bin/ld.exe: cannot find -lcirom
collect2.exe: error: ld returned 1 exit status
make: *** [build/app_0.out] Error 1
How i can’t fix it
its a build enviroment problem, not Peters code,
try this link – http://bfy.tw/FV1W
Around line 30 in the make file (Makefile) there is a line that starts..
LIBS=cirom
change to iron
I’ve been experimenting with a version or irom that saves a little memory.
Hi Pete,
First, thank you for all the great info! I have been using ESP8266 for some time and use WPS to establish connectivity. It works great with 802.11b/g/n routers, but generally fails with 802.11ac routers. I’m using SDK 2.1.0. Have you had any luck using WPS with 802.11ac?
You can see more info about the problem here:
http://bbs.espressif.com/viewtopic.php?t=1695
Pete, I tried the link to the ROMs this morning and I get this message (attached)
I’ve never tried WPS – and I can’t use 2.1.0 right now as it tips me over the edge for program RAM… I’m using 2.0.0
Hi Peter. Thank you again. Your blog gave me the inspiration to purchase my 1st ESP32. Very excited indeed. I’m still not sure what to even make out of it yet. I’m sure it will come to me. Will this run circuit python?
Added a Microduino display to a Witty board and it’s working great, is there any documentaion on the fonts 1 – 12 anywhere, in the blog? I’ve looked in the doc but can’t find anything.
I’ve played with them in the ssd1306 command but numbers 6 and 7 look interesting.
Some have icons – not documented due to lack of time – just experiment.
That would explain why the “Hello” doesn’t work, it’s in the first half of the display not visible.
Well I’ve got several Sonoffs up and running now, thanks for the great firmware, I’ve just flashed it onto a Wemos d1 Mini and tried to send something to the Wemos OLED plugin board but no success, is there something I need to do differently? I’ve only tried the sample code from your word doc for the ssd1306 so far.
Hello Phil
The WEMOS OLED according to this page…
https://wiki.wemos.cc/products:d1_mini_shields:oled_shield
uses D1 for SCL and D2 for DTA
According to THIS AliExpress page https://goo.gl/wVPFq1
Their OLED display uses (see underside) (I hope you’re sitting comfortably)
D1 for SDA and D2 for SCL
Notice the subtle difference?
I’m going to take a guess that someone, somewhere has screwed up because my code definitely works with the SECOND example (make sure my code is no more than a month or so old as I only added it a while ago – but then if you do it serially if you get it wrong you’ll get an “eh” or similar…
So my suggestion would be to get some patch lead and temporarily swap D1 and D1 going to the OLED…. send {ssd1306:”$SHELLO”} and it should then work – if it does – you’re going to have to get the soldering iron out…
It gets worse – some people use GPIO14 and GPIO2 for I2c…..
Yep! spot on, luckily I have a couple of the “dual base” PCB for the Wemos devices so it was quite easy to swap the pins over, the hello doesn’t work but the example from the doc works it’s just not the right layout for the screen, I suppose I’ll have to start reading to figure it out. I have one of the boards you used in your blog on order from Aliexpress.
Thanks for the help.
OH Hang on – the S has an optional number after it – 1 or 0 (default 0) – one of them switches from 32 pixels high to 64 pixels high versions…. That should do it.
I can now send text to the display but the xy coordinates don’t seem to work right, I’m assuming there’s something different about the display as it looks like its trying to write to one of the long format displays in your blog post and the first half of the text is missing. I’ll go and chaeck the display spec’s BTW my anti virus won’t let me visit wemos.cc as it says it’s a source of malware !! maybe it’s a false positive.
Hi Pete,
I thought I’d finally get around to trying out your home control code …flashed it and powered up and seeing the debug messages but I’m not seeing a WiFi access point “Hack-setup” on my phone, the LED is flashing at around 2 Hz, here is an extract of the debug output.
Starting in ROM Slot 0…
Reboot reason: software reset
GPIO4 and 5 are outputs
Current web programming pin: 0
GPIO13 is a LED indicator
Firmware version 2.3.13
SDK Version: 2.1.0(116b762)
ESP8266 in DHCP STATION mode.
Web page control is enabled
Waiting for Access Point beyond
Waiting for Access Point beyond
Waiting for Access Point beyond
I’m assuming that “web page control is enabled” means I should see the WiFI access point ?
Thanks,
Phil
It is set by default to GPIO0 as the web programming pin… immediately AFTER turning on but not before, hold GPIO0 to ground for a few seconds – you’ll then see your access point.
Personally I always program them up using the serial interface…..
Hmmm no matter what I do I can’t get an access point, I’ll try another ESP.
Tried another ESP and I got the web access point so it’s my ESP device or me!
Good – glad it’s working for you.
I’ve managed to get it working, its a web kit 8 ESP from aliexpress with a built in OLED display but I cannot get any display commands working, I’m using your word document to help set it up but it doesn’t display anything, is there some setup I need to do first?
here’s the pin-out drawing.
Thanks
I’ guessing the pinout may be incompatible, the I2C bus connections don’t look right, is it possible to reconfigure them in the code?
Absolutely – but you’ll have to do your own version – as I have uses for all my pins, documented etc, so don’t want to change that…. so I’ve found one board that states 2 and 14, I have a display board that says D1 (GPIO5) is SDA and D2 (GPIO4) is SCL – and my code works with that… but WEMOS boards state the opposite!
So it’s all a bit of a mess. For the record… on my code, SDA is GPIO5 – SDL is GPIO4
Thanks for the info, at least I know my suspicions were right, it’s a bit strange that anyone would design a board that doesn’t use the pins that are clearly identified for that purpose!
I thought about altering the circuit board but so far I can’t find a circuit diagram for my board and I don’t have much hope of being able to do it anyway so I suppose I will have to learn how to edit and compile your code to fix it ……. I suppose an externally connected display will do instead 🙂
Well, one could argue the points about the wires for ages…. as I sit here I’m checking out the original Espressif I2c code.
In their original I2cmaster code they chose GPIO2 and 14
#define I2C_MASTER_SDA_GPIO 2
#define I2C_MASTER_SCL_GPIO 14
But then going back in time, GPIO2 was a very important resource on the ESP-01 boards as only GPIO0 and 2 were available (and as we know, GPIO0 comes with it’s own issues as an input as it is already the programming pin – so some folk went off and used GPIO 4 and 5… but then some early boards had GPIO4 and 5 marked the wrong way around….
Were all the times the same – one could easily say – well why not just make them all selectable – but it isn’t that easy – the actual instructions for pin setup are different for different pins, some need pullups at powerup, one isn’t even a proper IO pin (GPIO16 can only be used as an output and doubles up as the trigger for deep sleep).
All in all a bit of a mess, but at this price – there is zero competition.
If it helps- next time you’re buying a combined board, mine says WEMOS on the back of the black board and also “D1-SDA D2 SCL” – and that board works a treat.
Thanks for the information, everyday is a learning day, I think it was Einstein said “when you stop learning you start dying” well I’m not dead yet 😁
Me too!
Hi Peter,
Thanks for the great blog & code.
I’d like to draw your attention to Oliver Peter’s comment (July 14, 2017):
————
Link to “roms.wubutu.com” should be “roms.webutu.com”.
I was confused to get an error.
————
I tripped over the same issue, and I assume others will continue to do so until you fix the link.
Thanks,
R. Main.
Hi there. Somewhere I’ve commented back. I went to that service because I needed a little more speed than I was getting from the current provider – the OTA process does not handle delays well. However it turns out that wasn’t one of my better ideas – well, the site was free – and when you get free you take your chances. Accordingly I’ve instead pointed my subdomain name roms.scargill.net at the site – which is safer anyway if you think about it. So the quick answer is – use “roms.scargill.net” for the OTA.
Hi Peter,
I tried to get a pcb made combining the Home Control and the Nextion boards after some minor change(added a gnd header). Only after I got the pcbs made did I notice that there was a copper fill area on the bottom side close to the 240v pads.(see image). This would not be visible unless I click the ratsnest icon.
I suggest that you please move the right edge of the bottom side copper-fill polygon further to the left to avoid the above scenario happenning accidentally.
We should remove those boards really – they’re old and there are lots of boards out there that will do the job.
Link to “roms.wubutu.com” should be “roms.webutu.com”.
I was confused to get an error.
Ready to jump and flash my ESP8266, but I can’t find the file esp_init_data_default.bin . Can you provide a pointer. Yhank
I’m not sure I’m following this one at all – standard behaviour for the MQTT broker is to deliver the message then scrap it unless you mark messages as retain – which I don’t use.
Its the retain function I am looking for from the esp when it publishes the message . if it doesn’t do this then it explains the reason so I will figure out another solution to my problem. Thanks
It would be simple enough to turn the retain on (last parameter currently set to zero) but I would hate to imagine what effect that might have on existing code and users… so best check out another solution unless you want to recompile the code yourself which is easy with the unofficial dev environment… in which case it is the last parameter of the “mqtt_publish” command.
Many thanks I will give it a go.
Tried it with MQTT.FX on the PC and it does the same. The value from the ESP is temporary it seems as soon as the message is requested and received by the subscriber its lost so any one else connecting has to ask it the output is ON or OFF
Hi Peter,
Just started using your Home Control system using a Raspberry pi 3 and a number of ESP modules. when I send the OUT0? I get a response from the ESP but this is not retained in the server, can I change this. I just want to be able to see the last known state of a GPIO line. I also find my ESP doesn’t respond to certain messages like reboot or uptime I just get a eh? in the serial output. Any idea what I am doing wrong?
Hi
Not sure what you mean by not retained in the server? when you say out0? You are getting the last known value to be sent to the ESP… and the ESPs store their output status during power cycling… uptime? reboot doesn’t work because the command is “reset” which will work EXCEPT if you use the board just after you have programmed it…. something to do with the chip… but that is the ONLY time you might have issues with that command. Just reset the board after programming (does not apply to OTA).
Pete.
erhaps I am not understanding but I assumed be hen non issued the command out0? The esp would publish the result to the broker but the value isnt retained so if some one else looks at that value its empty. As you can see I’m new to this so trying to understand the concept.
Sorry the start of the previous message had a few typos hope you understood what I was trying to explain
Ok, so I’m sitting at MQTT Spy to monitor and send to MQTT.
topic: heatingrelay/toesp
payload: {out0:1}
that turns the relay on…
Same topic
payload: {out0?}
Returns ON
Same topic
payload: {out0:0}
Same topic
payload: {out0?}
Returned value OFF
Works a treat.
I agree it does work exactly as you say. However I am using an app called MQTT Dashboard and it will show the value if you send the {OUT0?} message but if you stop the app then restart it the value is n/a which I assume means there is no value stored on the MQTT server until you send the message again {out?}. If you publish a message with the topic id/fromesp/out0 with a value of OFF or ON, as I assume the ESP does, and tick the retained box it will keep the value so when I restart the app again the last value pops up. Could the ESP do this or does it cause other issues? At the moment you have to send a message to get its value OFF or ON were as if it sent the message with the value retained then the server would store it until it was updated again.
Hi Pete
Could you please check the code around {mqtt_host:”10.10.10.28”}.
Running this command gives “OK” but {debug} still shows the default of “MQTT Host: 192.168.0.20 Port: 1883 User:”
thanks Roger…
Hi Roger -well for me there is no mqtt_host:”10.10.10.28″ – but I’m assuming you’re saying you’ve set the MQTT host to that – that it is WORKING but the debug says no.
Can’t see anything wrong. I set the MQTT host –
else if (os_strcmp(token, “mqtt_host”) == 0) {
if (isQuery) os_sprintf(strValue, “%s”, sysCfg.mqttHost);
else
{
if (os_strlen(strValue) > 1)
{
os_strcpy(sysCfg.mqttHost, strValue);
doUpdate = 1;
}
ok();
}
}
and debug says…
iprintf(RESPONSE, “MQTT Host: %s”, sysCfg.mqttHost);
iprintf(RESPONSE, ” Port: %d”, sysCfg.mqttPort);
iprintf(RESPONSE, ” User: %s \r\n”, sysCfg.mqttUser);
Hi Roger.
No idea why it won’t connect if you have put the correct SSID and password, sorry. Check case of password etc.
Hi Pete,
I think that I have found the cause of my connection problem. I have taken another ESP and fiddled around with the AT commands. I have found that if I apply a fixed IP address it connects fine. Must be an issue with DHCP, I have checked the AP and tried another same result. Many other devices including a couple of Raspberry Pi’s and this tablet are obtaining DHCP addresses just fine off the AP.
Have you considered adding the option for fixed IP? If I could only get the Eclipse environment working for me I would code it myself, but that’s another story.
Thanks, Roger…
Some time ago when hunting through the SDK I put in the ability to go to fixed IP – and never tested it – hence never documented it – but it occurs to me that I never did the opposite – so if you care to verify the correct version – looking at this it it obviously NOT correct.. but now I can handle up to 8 arguments so it could be done if I’m on the right track….
else if (os_strcmp(token, “fixed_ip”) == 0) {
struct ip_info info;
wifi_station_dhcpc_stop();
IP4_ADDR(&info.ip, arg2, arg3, arg4, arg5);
IP4_ADDR(&info.gw, arg2, arg3, arg4, arg6);
IP4_ADDR(&info.netmask, 255, 255, 255, 0);
wifi_set_ip_info(arg1, &info);
wifi_softap_dhcps_start();
ok();
}
and what exactly the opposite function would be – I’ll enable both and you can give them a try…
Hi Pete,
Looks like you are on the right track. I will need to read up on the SDK, but I think that you only need “wifi_softap_dhcps_start” if you are not using the static IP. I will spend a bit of time reading the SDK to check on this.
Let me know when you have enabled the code above and I will download the binaries and give it a go.
Many thanks, Roger..
Oh that “fixed_ip” code is enabled – always has been… I just never tested – and hence never documented it.
So if you wanted an IP address of 192.168.1.20 and your gateway was 192.168.1.1
the code would be {fixed_ip:192,168,1,20,1}
Give it a whirl as it stands and see what happens.
So that needs testing – I guess it needs a powerup to check – and I need the opposite function to have it go back to dhcp.
Hi Pete
I tried with “{fixed_ip:10,10,10,35,1}”
It responded with OK but would not connect. I tried a power cycle, still no go.
Thanks Roger
Hi Pete,
From the SDK!
Function: Set IP address of ESP8266 station or soft-AP Note: To set static IP, please disable DHCP first (wifi_station_dhcpc_stop or wifi_softap_dhcps_stop): If enable static IP, DHCP will be disabled; If enable DHCP, static IP will be disabled; Prototype: bool wifi_set_ip_info( uint8 if_index, struct ip_info *info ) Prototype: uint8 if_index : set station IP or soft-AP IP #define STATION_IF 0x00 #define SOFTAP_IF 0x01 struct ip_info *info : IP information Example: struct ip_info info;
wifi_station_dhcpc_stop();
wifi_softap_dhcps_stop();
IP4_ADDR(&info.ip, 192, 168, 3, 200); IP4_ADDR(&info.gw, 192, 168, 3, 1); IP4_ADDR(&info.netmask, 255, 255, 255, 0); wifi_set_ip_info(STATION_IF, &info);
Cheers, Roger
Actually – the arguments are wrong – for setting the station – the first argument needs to be zero….. so more like “{fixed_ip:0,10,10,10,35,1}”
If 1 you are setting the access point I believe – but then – I note I’d restarted the DHCP on the access point…
I’ve updated the code to this – which might be nearer the mark.
else if (os_strcmp(token, “fixed_ip”) == 0) {
struct ip_info info;
wifi_station_dhcpc_stop();
wifi_softap_dhcps_stop();
IP4_ADDR(&info.ip, arg2, arg3, arg4, arg5);
IP4_ADDR(&info.gw, arg2, arg3, arg4, arg6);
IP4_ADDR(&info.netmask, 255, 255, 255, 0);
wifi_set_ip_info(arg1, &info);
ok();
}
If that works I still need the opposite function to shift them back to DHCP. Well, give it a go – no guarantees. I’ve updated source and roms.
Hi Pete,
I think that I am slowly getting there. After setting fixed IP I get AP connected. This is followed by the MQTT trying to connect but failing as the just keeps repeating.
A quick question; Does the MQTT connect user authorisation as I have not set this up on my Mosquitto host (Raspberry P13)?
If it does can it be configured not to use authorization on connecting to the MQTT host?
Thank, Roger…
Hi Pete,
I cannot find any reference to a scan command in the document “Hackitt-and-Bodgitt-ESP.doc”. What is the syntax for the scan command?
Can we continue this off line, I have a number of questions re compiling the code and don’t want to hijack this blog with my dumb questions.
Many thanks,
Roger…
Hi Peter,
I Just grabbed a copy of your source code for the ESPs and have setup the eclipse environment. I am new to the Eclipse environment (have worked a lot in Rowely Crossworks) and cant for the life of me figure out how to import your project into the workbench. Can you please give me the 5 minute lesson on this.
Many thanks, Roger…
Assuming this is the Windows unofficial environment with Eclipse, FILE – IMPORT – EXISTING PROJECTS INTO WORKSPACE – and point to the directory where you’ve stored the project. That’s it.
Hi Pete,
Many thanks for the reply. I have had little time to work on this, but have managed to import the code. Now I have to setup the make and flash targets.
I have loaded your bin files into my ESP8266 module okay, but at this stage I cannot connect to my wifi AP. One useful addition to your code would be to implement a {scan_for_AP} command so that you can see what AP’s the device is seeing.
Again, thanks for your assistance, I am looking forward to getting this up and running.
Roger…
There is a scan command – and also the WIFI setup has a scan!
Scan command is now in the manual. I don’t know how I managed to miss that off. Of course in WIFI setup mode the scan runs automatically.
Thanks for adding scan to the manual.
Next problem…a scan show my AP. But after giving the SSID and password it wont connect, just repeats “Waiting for access point orion” orion being my AP SSID. Any thoughts on how to determine what the issue is?
Thanks Roger…
For clarification…
Whenever a unit logs in – that is – when it is powered up, it sends the message esplogon (and the node is listening for that). In there is ID information.
For example:
{“id”:”freddy”,”desc”:”empty”,”attribute”:””,”fail”:”0″}
The node then sends the time tot that particular device. Additionally the node sends the time to all devices at once at regular intervals (once a day). That way, each unit always has up to date time information.
Ok – so I am on the right track.
What topic does the esp utilize for sending its information such as ID?
I have esplogin setup and the heartbeat but I have tried listening on the following topics with mqtt-spy but see no traffic:
Test/fromesp/# (test is the name of my esp for now)
fromesp
Test/esplogin/#
esplogin
I see the appropriate answer (on or off) when I send {out12?} to Test/toesp so I know that my esp is connected to my broker and able to send messages but I see no traffic in regards to the ID and information of the esp.
Peter
I noticed in the other blog that a gentleman (Ian) posted the output of his esp:
ESP Starting…
STATION mode
Web page control disabled
Waiting for Access Point Studio224G
Connected as 192:168:1:15
MQTT connecting
MQTT Broker connected
Device ID is BPA3
Item published
Time is 08:55:01 10/04/2016
Tick
I compared that to mine :
ESP Starting…
GPIO4 and 5 are outputs.
Current web programming pin: 2
GPIO13 is a LED indicator.
Software version 1.5.52
SDK Version: 2.0.0(656edbf)
Use the {debug} command for more information.
STATION mode
Web page control enabled
Connected as 192:168:1:217
MQTT connecting
MQTT Broker connected
Device ID is Test
–>
Tick
and noticed that my device is not being published to mqtt. When I use mqtt-spy and send a request to the esp it responds according such as {out12?} = off. When I look at Test/fromesp/# I only see responses back when I query the esp.
Should my esp be sending/publishing to the broker its id and information upon loading?
The top version is wrong – and is the result of changes in the SDK which Espressif are still investigating – I put a workaround for that in the latest code – he needs to update his code which is old – on yours you see -> – that means the same thing.
Peter,
Trying the latest code (as of 3/8 – downloaded) – blowing this to a NODEMCU board.
Windows 10 – could not get esptool to run under Windows 64-bit – even after installing the latest CYGWIN and updating my path still got the dreaded CYGWIN1.DLL could not be found.
Used the NODEMCU flasher and followed the steps from your post above – all flashed well – the unit boots (for anyone else doing this with a NODEMCU board – Pin D4 is actually GPIO2) and the board sits there at the following screen saying Scanning for Wifi
I am using 1.5.52 of your code – and it is showing the SDK as 2.0.0
Any ideas on this one ?
Craig
Hi Craig – that’s because version 1.5.52 of my code is using SDK 2.00
Sorry Peter – the versions i gave where just as verification that i was using the latest and greatest from you – the question was in relation to the board sitting there saying Scanning for WIFI and going no further ?
On a side note and a question of interest
We have four Access points around our house – all with the same SSID and password – the idea being that as you wander around the devices seamlessly drop connection to weak APs and move across – in the main this works well on most devices – Android is notorious for falling in love with a weak AP and holding on – but thats another matter.
When setting up your unit – how is connection to an AP determined – is the MAC address of the wireless interface of the AP used – or is it purely SSID and hence “portable”
The reason i ask is that after getting no joy with yours i blew ESPEasy onto the unit to verify correct operation and it saw four SSIDs with the same name in its setup process.
Craig
I use purely the WIFI access code – now, whether the ESP stores the MAC address internally is another matter. I doubt it.
OK thanks Peter – any idea then on troubleshooting the scanning for WIFI ?
Craig
I want to make temperature control.
Currently it works:
– Raspberry PI2 used to install the script
– NODEMCU home control FIRMARE
– Mqtt connection pi nodmcu
– Sensor DHT 11
-com port temperature and humidity works
Does not work
-ESPLOGIN
-node-red temperature, humidity
Help you to know more specific descriptions, or possibly sample flow?
I do not know what could be the problem.
Thanks
When you say “ESPLOGIN does not work” – have you attached it to an MQTT node which is subscribed to “esplogon” ?? See page 9 of manual. Have you checked that messages are coming into that MQTT node by attaching a debug node? Temperature and humidity – have you set temp_type and temperature commands?
I’ve just realised that is “esplogon”. The units send this when they log in – and the node then sends them the time – to which they do not reply. It also sends the time to everyone at regular intervals and there is no reply.
Hi Peter
Esplogin,temp,humidity it works fine
Nextion to node red communication it ok.
Now I have a problem node red to nexton display communication.
I tried the serial communication terminal works.
I do not know what is wrong.
Hi Peter
You would not be able to divide it complete Nod-Rred home control project flow sampels?
Would help very much!
Thanks
Balázs
Not entirely sure I caught what you are after there – it sounds like you would like a complete home control project example… good luck there, mine is being developed incrementally – in any case, everyone has different expectations. For some, a couple of timers controlling lights with dusk dawn might do it (bigtimer does that) – for others – a home control system might stretch to full security, heating, lighting and sound.
Peter,
I am having issues with your recent updates, where compiled with SDK2.0
Basically, whenever I issue an OUT command to an upgraded 8266 it does as requested, then within a few seconds causes MQTT to fail, then a full recycle with re-establishing SSID. After that it is stable for other commands, until it sees an OUT command (no particular pin).
I have just recompiled your latest version 1.5.51 with SDK 1.5.4 and I am having no failures with any commands and no reboots.
For reference devices were ESP12 1meg and ESP12 4 meg (Electrodragon)
Do a full wipe – make sure you have the latest version as of today – might as well be up to date – it absolutely definitely does NOT do that with 2.0…. I’m using 4 meg ESP12.. you need to use ESPTOOL to do a complete erase….. do I take it you have the source…..
I’m adding a screenshot to the article now – look at blog in about 5 mins.
Full wipe completed with ESPTOOL, installed 1.5.51 from tonight and all stable again, no reboots.
Thanks for quick response, look forward to trying out the new commands.
Peter,
Thanks for the quick response.
You answered my question on the Adafruit esp. I believe it has 4MB flash. Thanks.
I had seen the write up on the database setup and the script for the raspberry pi. I had no problem getting this setup. What I did not understand is how the data was fed into the database initially for the ID of the esp and outlets. Do you input the data manually or is automatic? Based upon your reply, my understanding is that this is done automatically with the explogin node.
Thanks again for sharing the wealth of knowledge and experience.
Hello Peter,
Thanks for sharing your experiences – the amount and detail of information is over whelming and inspiring to say the least.
If you do not mind – I had a couple of questions about your home control code for ESPs:
1.) Can you use this code with say a Adafruit Huzzah Feather esp? Or is it specifically for the boards that you designed?
2.) How do you initially setup/feed the database specific to the device ID and outputs for Imperihome? Do you have to manually input the device ID and outputs in the database ? Or is this actually done when you setup the device using your esp code and the explogin feeds the database accordingly?
I have read all of your blogs as far back as I can go and still do not understand the initial feed process into the database.
Any help would be appreciated.
Hi
I have no idea what an Adafruit Huzzah Feather is – as their stuff seems overly expensive to me. If it is based on the ESP8266 and has 4MB of FLASH then yes.
Somewhere in the blog is the setup for the database – and also in my script which I refer to often in the blog – is the database setup. Imperihome is also covered in there. The database setup could be better… – the units log in and the ID is stored in the database.
Actually the database is only used for Imperihome. The ESPLOGIN module hands back time information to the boards and logs them in – and regularly updates all units with time – but it does not rely on the database for that. I use Imperihome a lot – but given that we now have an officially supported node-red-dashboard, I’m not sure how long that will last.
Hello Peter,
How did you find that wifi_set_opmode(0); fixed the problem? Parameter 0 is not even valid since their enum uses 0x01, 0x02, and 0x03.. At least it’s not documented as far as I know.
Thanks
Simple – I realised it was at the start of my second init file…. and that was working – so I moved it to the start of the first init file – and everything worked and has done since. It was something we stuck in AGES ago…. I can reliably go back to the older SDK – doesn’t care where that file is – new SDK – won’t output serial until that function has been called… and yes I know, firing zero at it is not valid – or at least it does not select anything.
Espressif are looking at this now – but it works – everything works – I’m now back to working on my i2c.
Hi
just updated boards via ota for first time..which worked great, but i now don’t seem to be able to send commands to nextion display any more. when i first up dated. i noticed where the time should be i had “Jul 2”. so i went into my node red that sends the time and noticed that {gettime?} now returns “international time” instead of “time” and as i was using .slice(22,27) to get HH:MM it needed to be (33,41) to now get HH:MM:SS and i needed to also update display every second. but i now dont get any thing in my time text box. temp and humidity are also the same ???
i have attatched a debug and this is exactly what is being sent to nextion display:
{to_nextion:”t0.txt=\”23:01:11\””}.
pressing buttons on the display sends data ok
chris.
I changed the format of gettime() – it used ntp servers and is not used anywhere nor does it have any relation to the Nextion software. As for temperature – check the manual (today) there are two relevant commands – {temperature_port} and {temp_type} – check they are set correctly. No changes made to nextion software.
Pete.
Hi pete
I am still unable to update anything on the nextion display. pressing buttons on the display works and i can see the commands coming into node red debug. i have attatched a scope to “to Nextion pin” and fired commands at the esp, but the pin just sits in a high state. i have tried different esp boards but get the same. i have also tried switching 4 & 5 back to gpio ({set_serial:0}) and switching them with the out4/5:0/1 and they both switch ok ! reset them back {set_serial:2} i’m at a loss!
Chris
i just realisied i was scoping the rx pi without display connected ! thats why it is high Duh. Still not working though. I have sent “hello” from nextion editor and is works, i stored the waveform in the scope, then sent “hello” from Node red.. dosn’t work and waveform completely different ? could i have a timing issue ?
Hi Peter,
If the previous revision of your code supported OTA, why do you still use the serial interface method of updating the firmware?
I haven’t tried OTA updating on my devices, is there some reference in any of your blogs that describe how this is actually done?
Thanks for your informative blog and patience with newbies.
regards
greg
Hi Peter, I use the Arduino IDE and use SPIFFS which does not suffer from this limitation.
Hi there
Well, firstly you can’t OTA from scratch – you have to start from somewhere. You FLASH the chips, then you can either use the web interface to set everything up like SSID etc or (and I find this easier) just use serial commands (which are identical to MQTT commands but without the topic) to set things up – in my serial terminal I have a macro all set up to make life easier for me when testing. Once things are the way you want, you can OTA updates. The latter is done by issuing one command either serially or by MQTT – {otaupdate} – that’s it – the board goes off and gets the update and reboots.
Thanks Peter.
Is it possible to ask for a little more information about the specifics of the web server that provides the update source files?
The ESP8266 device has to know where to go and what to ask for.
The device configuration settings specify the address or URL and the port used by the web server. Do the update files have to be located in a particular directory on the source machine? Do they have to be named in a particular way? Any other clues on what needs to be done to set this up?
Thanks.
Greg
The only specific for the website Greg is that it can server .bin files – so for example if you go in Chrome to http://www.scargill.net/rboot.bin – the file will download – in my case that’s just a straight-forward website – some providers may not allow this – so just dump any old file with a suffix .bin on the site and see if it will download in a browser.
What limitation?