Monthly Archives: January 2015

Slight hitch

Apologies to anyone looking in this morning. I tried to get just a little too clever with the blog and it fell over - so anyone looking in while I was asleep (British time) would have seen a dead site - all working. As this blog is new could you please remember when commenting to tick the little box to say you want emails when someone replies to posts.

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 MQTT and LOSS OF WIFI

Update at 13:22:00 on 02/02/2015
This morning I had an email to say the WIFI loss was fixed in the MQTT code. I downloaded the latest MQTT software and put my code back into it. I turned the WIFI off for a few seconds then back on – that worked, sending out the message backlog and re-subscribing to messages. I then turned the WIFI off until the 2K queue buffer was full – that I guess is the ultimate test.  That took several minutes. I turned the WIFI back on and…no. BUT we understand what’s wrong. The queue is full – and hence there is no room to re-subscribe. This is now fixed here https://github.com/tuanpmt/esp_mqtt. Everything seems to operate perfectly. That is important for a number of reasons as it suggests that there is nothing wrong with the SDK.

Original blog:

This  is getting to a be a problem.  I don’t know if it is the MQTT software or ESPRESSIFs SDK but there is an issue if you lose WIFI connection.  I tested this on the road the week but now I’m back in the office I’m doing it a bit more scientifically.

So – I know that the WIFI here is perfect.  I also know that the SDK is case sensitive so in order to simulate loss of signal it’s simply a matter of renaming the “office” WIFI to something else or just change case (my computer is hardwired) to test.

Here’s the result of this mornings test.

So what we have is an ESP-01 – I’m using the latest SDK (0.9.5) on a PC using Eclipse and using Tuan’s MQTT software as a base (NOT the LUA version – so I’m programming in C).  The basic MQTT software has a number of subscriptions… including the time.  A separate system updates the time every minute (Linux timestamp – seconds since 1974).  The board has a temperature sensor which on a timer sends out the temperature every 5 seconds (using code that does not involve long delays).

Here is the log.. “in the beginning” the router has the WRONG name so that the board cannot see the WIFI.. It sits in a loop waiting….

 

no office found, reconnect after 1s
STATION_IDLE
STATION_IDLE
reconnect
STATION_IDLE
STATION_IDLE
STATION_IDLE
STATION_IDLE
scandone
STATION_IDLE
add 0
aid 1
pm open phy_2,type:2 0 0
cnt
STATION_IDLE

 

At this point I turn on the WIFI – and all is well, it is picked up – the board starts up and subscribes to the various topics.

After about a minute, it gets the time – and now starts transmitting the temperature (the sensor isn’t hooked up so it’s just sending dummy info)

 

connected with office, channel 13
dhcp client start...
STATION_IDLE
STATION_IDLE
ip:192.168.0.9,mask:255.255.255.0,gw:192.168.0.138
TCP: Connect to domain home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
MQTT: Connected to broker home.scargill.org:1884
MQTT: Sending, type: 1, id: 0000
TCP: Sent
TCP: data received 4 bytes
MQTT: Connected to home.scargill.org:1884
MQTT: Connected
MQTT: queue subscribe, topic"output", id: 1
MQTT: queue subscribe, topic"mytime", id: 2
MQTT: queue subscribe, topic"time", id: 3
MQTT: queue subscribe, topic"dusk", id: 4
MQTT: queue subscribe, topic"dawn", id: 5
MQTT: queue subscribe, topic"peak", id: 6
MQTT: queue subscribe, topic"off_peak", id: 7
MQTT: queue subscribe, topic"frost", id: 8
MQTT: queue subscribe, topic"on_1", id: 9
MQTT: queue subscribe, topic"off_1", id: 10
MQTT: queue subscribe, topic"on_2", id: 11
MQTT: queue subscribe, topic"off_2", id: 12
MQTT: queue subscribe, topic"timestring", id: 13
MQTT: Sending, type: 8, id: 0001
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0002
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0003
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0004
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0005
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0006
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0007
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0008
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 0009
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 000A
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 000B
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 000C
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
MQTT: Sending, type: 8, id: 000D
TCP: Sent
TCP: data received 5 bytes
MQTT: Subscribe successful
TCP: data received 18 bytes
MQTT topic: time, data: {1422703981}
TCP: data received 62 bytes
MQTT topic: timestring, data: {11:33 Saturday 31-01-2015}
Get another published message
TCP: data received 23 bytes
MQTT topic: dawn, data: {439}
Get another published message
TCP: data received 12 bytes
MQTT topic: dusk, data: {1042}
MQTT: queuing publish, length: 17, queue size(0/2048)
MQTT: Sending, type: 3, id: 0000
TCP: Sent
MQTT: Published
MQTT: queuing publish, length: 17, queue size(0/2048)
MQTT: Sending, type: 3, id: 0000
TCP: Sent
MQTT: Published
TCP: data received 13 bytes
MQTT topic: mytime, data: {400}
MQTT: queuing publish, length: 66, queue size(0/2048)
Time: 11:33:09 31/01/2015 Dawn=439 Dusk=1042 Tick=86392MQTT: Sending, type: 3, id: 0000
TCP: Sent
MQTT: Published
MQTT: queuing publish, length: 17, queue size(0/2048)
MQTT: Sending, type: 3, id: 0000
TCP: Sent
MQTT: Published
MQTT: queuing publish, length: 17, queue size(0/2048)
MQTT: Sending, type: 3, id: 0000
TCP: Sent

 

As you can see above – the unit is sending out temperature and the outgoing queue is not building up – all is well. So now I disconnect the WIFI.

 

rm match
pm close 7 0 0/96959550
TCP: Reconnect to home.scargill.org:1884
reconnect
STATION_IDLE
scandone
no office found, reconnect after 1s
STATION_IDLE
STATION_IDLE
scandone
STATION_IDLE
STATION_IDLE
STATION_IDLE
STATION_IDLE
scandone
add 0
aid 1
pm open phy_2,type:2 0 0
cnt
STATION_IDLE

 

And that sits in the loop waiting for a reconnect.. NOW I reconnect (by renaming) the WIFI

 

connected with office, channel 13
dhcp client start...
MQTT: queuing publish, length: 17, queue size(57/2048)
STATION_IDLE
STATION_IDLE
STATION_IDLE
DNS: Found, but got no ip, try to reconnect
STATION_IDLE
STATION_IDLE
STATION_IDLE
ip:192.168.0.9,mask:255.255.255.0,gw:192.168.0.138
TCP: Connect to domain home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
MQTT: queuing publish, length: 17, queue size(76/2048)
TCP: Reconnect to home.scargill.org:1884
TCP: Connect to domain home.scargill.org:1884
TCP:Reconect to: home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
MQTT: queuing publish, length: 17, queue size(95/2048)
TCP: Reconnect to home.scargill.org:1884
MQTT: queuing publish, length: 17, queue size(114/2048)
TCP: Connect to domain home.scargill.org:1884
TCP:Reconect to: home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
TCP: Reconnect to home.scargill.org:1884
MQTT: queuing publish, length: 17, queue size(133/2048)
TCP: Connect to domain home.scargill.org:1884
TCP:Reconect to: home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
TCP: Reconnect to home.scargill.org:1884
MQTT: queuing publish, length: 17, queue size(152/2048)
TCP: Connect to domain home.scargill.org:1884
TCP:Reconect to: home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
MQTT: queuing publish, length: 17, queue size(171/2048)
TCP: Reconnect to home.scargill.org:1884
MQTT: queuing publish, length: 17, queue size(190/2048)
TCP: Connect to domain home.scargill.org:1884
TCP:Reconect to: home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
TCP: Reconnect to home.scargill.org:1884
MQTT: queuing publish, length: 17, queue size(209/2048)
TCP: Connect to domain home.scargill.org:1884
TCP:Reconect to: home.scargill.org:1884
DNS: found ip 109.170.132.114
TCP: connecting...
TCP: Reconnect to home.scargill.org:1884
MQTT: queuing publish, length: 17, queue size(228/2048)

 

Note the problem – it is connected – or so it says – but the queue is still building up – as if it is unable to send anything out.

And that, right now renders the code useless as there will always be problems with WIFI.   If anyone has any ideas do let me know – this has to apply to other setups to one extent or another. According to Espressif they have solved some issues with reconnects in the latest SDK – well, I’ve overwritten the old one and recompiled so unless I’m missing some trick in the compile process I’m definitely using the latest SDK.

Facebooktwittergoogle_pluspinterestlinkedin

The New ESP201 and Dev Board

All I have time for right now, here’s the new board, the ESP-01 (left) next to it should give you an idea of the size of both the development board and the ESP8266 board that goes into it – NOT SMALL.  And yes, those are 0.1” centres. No points for PCB design but it does look useful.

So you’re looking at a test board for around £10 complete with ESP board, wire antenna as well as the on-board antenna, relay, connector for DHT11/22, mini-USB and micro-USB, a 3-way connector for the relay (and by the look of it enough clearance to make it save for mains power use) 3-colour LED, a buzzer, interface components – pretty much all you need for experimenting, really…

New ESP8266 Board

Facebooktwittergoogle_pluspinterestlinkedin

The ESP8266 Grand Master Plan

So… here’s where I’m up to with my little project… currently stalled until we can figure out why the ESP8266 is not recovering from loss of WIFI.

The plan

This is “the plan.  Using the basic MQTT code, I’ve added the ability to control GPIO0 and take input from say a Dallas DS18B20 chip.  I have the ESP8266 on a little board with a 3v3 regulator to ensure it gets decent quality power from a typical cheap 5v supply.  The MQTT software uses a block at 3c000 to store non-volatile information and it’s only using a small part of the 4K available.

Why 4K, because that’s the minimum size of FLASH you can erase – and if you can’t erase, you can’t write. Here is my understanding of the FLASH. You can write a 0 to it – but not a 1. So when you erase the FLASH – which can only be done in 4K blocks as a minimum in this case, the bytes are all set to 255 or 0xFF if you prefer Hex, or 11111111 in binary.

You can then write to that block – and read it as often as you like. The path that Tuan has taken to store user info, passwords etc is to use a 16K block at 3c000, use the first and second blocks to store information (the same information, ignore the third block and use one byte of the 4th block to tell you which of the first two has accurate info. The reasoning for this becomes obvious after a while, you don’t want to lose your info in the event of a power failure during erase or program. So, lets say you have a binary flag in the top block set to 1. That means that the existing data is held in the second block. You wish to change something – read the data into RAM, erase block ZERO, write a copy of the data to block zero and update that flag accordingly – if any of that fails, the data stays in block zero, if it succeeds the software will know to use block 1 from now on when powering up to get the data. Simples. GROSSLY wasteful, but simple.

So as well as input, output and non-volatile data I’ve also added a real time clock able to go for days without update but as it happens my MQTT fires out the correct time every minute. Should the broadband fail however, the clock will still keep ticking.

Now that the system can send messages and receive them including subscriptions to the time, dawn and dusk and other info, I have a state variable which tells it what it is doing – that is described at he top – and involves sending a message with number 0 upwards – which gets stored in FLASH. So 0 turns the output off, 1 turns it on all the way up to 5 which has it operating as a proper thermostat with 2 lots of on-off times.

All works a treat – except… it is not recovering from lost WIFI. So next steps – harassing Luan to ensure his MQTT code is ok and asking him to check to see if the new SDK helps – personally I’m just not that sure how the new SDK is dropped in. The instant this works – I’ll put this in a box with the solid state relay jobs I detailed earlier – and – Bobs your uncle.  First useful ESP8266 outcome. Now, given that there is plenty of code space, that APPARENTLY you can double the clock speed to 160Mhz if you need more power and the availability of ESP8266 boards with many more pins – who knows how this will develop.

Facebooktwittergoogle_pluspinterestlinkedin

A Brave New World… no just a new blog

Good morning/afternoon/evening wherever you are! You may notice that you’re looking at a different site – i.e. NOT scargill.wordpress.com but tech.scargill.net -  and for good reason. The blog has proven popular and I want more control over the site – in terms of plug-ins to offer code highlighting and a boatload of other things – which I simply can’t do using the old wordpress.com site.

So can I ask you to do me a little favour – if you are by any chance on the old site ( don’t think that’s possible but you never know) – or if you’ve been here before, please ensure you are set up with this site to receive emails on new topics etc. from here  otherwise you might miss something interesting. I’ve done the best I can to set up automatic redirection.  I hope you continue to enjoy the blog and for those of you who have contributed in the past your input is REALLY welcome and I hope you will continue to contribute on this new site.

The visuals may change over time as I tweak the content but hopefully the layout is simple enough to find what you need. The site should also be a lot more useful on a mobile than before due to the responsive nature of the template.

Any problems let me know.

 

Pete Scargill

Facebooktwittergoogle_pluspinterestlinkedin

Solid State Relays

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.

Facebooktwittergoogle_pluspinterestlinkedin

ESP8266 and Lost WIFI Connection

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!

Facebooktwittergoogle_pluspinterestlinkedin

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?

Facebooktwittergoogle_pluspinterestlinkedin

SOLID STATE MINI-RELAY FOR ESP8266

8-pin chipThe PR26MF22NSZ and it’s larger cousin the PR39MF22NSZ  are miniature 8-pin devices which look for all the world like any other 8-pin chip – but are able to switch mains power at up to 0.9amps – i.e. up to 200w. Seems unbelievable but that’s the claim – sensible you could certainly run a typical mains light.

Given the very small size of our ESP-01 boards and the equally small size of the mains power supplies I found earlier, these would appear to be an ideal companion. Right now they are marginally more expensive than the cheapest Chinese relays and even very slightly more expensive than some solid state relays – but the size has to make it all worthwhile?

Digikey have the larger one at 1.18 but the postage kills that option – you have to wonder what their marketing people are thinking about – 1.18 for the chip – 12.00 for postage – come on guys – it’ll fit in an envelope!!!

http://www.digikey.co.uk/product-detail/en/PR39MF22NSZF/425-2375-5-ND/720413

The best I’ve seen up to now is £1.97 with free postage here..

http://www.ebay.co.uk/itm/PR39MF51YIPF-Sharp-Relay-Solid-State-/141500293514?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item20f213218a

 Here is some more info and a diagram.

So – the one I ordered turned up and has 7, not 8 pins. It is marked R39MF5. It is the surface mount version but in this case is no smaller, just has short leads, flattened for SM use. Pin 7 is missing.  I went out and bought the highest power bulb I could  - a halogen 75w lamp. I attached one end of the lamp to LIVE mains, the other end of the lamp to pin 8 of the chip and connected NEUTRAL to pin 6.   DO NOT DO THIS AT HOME UNLESS YOU ARE HAPPY TO DIE or know what you are doing.

I connected pin to a 330r resistor… so that the resistor would be + input and pin 3 would be – input.

That’s it. I tried with an isolated battery first – fine, checked with a meter, fine,  put pin 3 to GPIO0 on the ESP8266 and the resistor to the 3v3+ supply.   Works perfectly with the light going on and off on demand.

Finally, I left the light on for 10 seconds, disconnected the mains and immediately felt the chip – freezing cold.  So would I be happy to put some more power in there? YES. Mounted on a board with some copper to get rid of any heat I see no reason why this chip should not handle a 100w lamp. For the size I think that’s pretty good.

Facebooktwittergoogle_pluspinterestlinkedin

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.

Facebooktwittergoogle_pluspinterestlinkedin