MppSleeper/MppContact application - physical switches

[Mike P]

Just grabbed this from amazon:  4 inexpensive switches for $26 CND.  Cute right?

What makes them useful is they've got a battery holder for 2 AAA's and some extra room inside.  They're about 3 1/2" in diameter.  So here's what I did:

1. Pried out the rubber feet to get at the 4 screws and opened them up.
2. Popped out the speaker and threw it away.
3. Reversed the red and black battery wires so that the button grounds instead of sending power.
4. Fit an ESP01 running MppAlert into the space left by the speaker
5. VCC and GND are obvious, connect them to the ESP01.
6. Run J4 to CE (the pad of 4 contacts at the edge of the board, J4 is the one nearest the speaker).  
7. Put a resistor (value is not important, big is good, I used 10K, probably 100M would work too, bridging with just my finger was enough) between +5 and CE.
8. Connect RST to +5.
9. Put it back together.  The button and the base are keyed with little tabs to keep them steady, make sure they line up.

A little "kiddy" looking but now it's a big "easy" button with a solid click for triggering automation.  It'll run for years on the batteries.  

I've got it using a static IP so it fires up and triggers in < 3s.  

An MppContact will work too, should trigger in < 1s, the battery should last for at least 6-8 months, maybe more.

[DougC]

And pretty durable too I should hope given the target market. I'm seeing a big sign - "do not push the red button" for when the grandkids (imaginary in my case thus far) come over and something "interesting" happening when they inevitably do. I may have to get some of these. :-)

[Mike P]

I've got one wired up as an MppContact now, it's even easier:

1. De-solder the red and black wires from the board.
2. De-solder the white wires from the board and speaker.
3. Pry out the speaker and discard.
4. Wire + & - from the battery to the ESP01
5. Use one of the white wires from the ESP01 "-" to where the red was formally (button in)
6. Use the other white from J4 to GPIO0 or GPIO2
7. Remove the power LED from the ESP01 if it has one.

Configure the MppContact to connect to your MppGateway and with the correct sensor.

I use the wifi LED to show when the MppContact is awake.

Usually < 1s response time.

[Mike P]

The switches have been officially rejected by my GF as too ugly :).  Great for the garage and basement though - I use them to override the auto-off timers.

[Steve Marshall]

I should be able to re-purpose a Sonoff SV to use as an MppSleeper device, shouldn't I?  The relay on the board will be redundant, but that's fine.  Can it use the button on the board as the toggle button?

I have a couple of them I'm not using, and have hooked one up with the USB-serial adapter but am not getting any responses from it using LuaLoader - tried all speeds.  What have I forgotten?  It's a while since I last tinkered with these.  It's definitely working, because it has connected to my network and I can see it in AM/ESP8266 Devices.  It's configured to work as a switch, with older firmware, and I can switch it on/off with AM perfectly ok.

EDIT:  I think this is a problem with the USB-Serial adapter I have, on Windows 10.  I was using a Win7 laptop when tinkering previously, so I think I need to get a different adapter/driver that will work on Win10.  I'm sure LuaLoader is sending data ok AND getting responses, but for some reason it cannot read/display the received data.  I found a page on a website that said the chip used on my adapter is not supported on Win10.

[Mike P 4 MPP]

Relays use a LOT of power even if they're not activated, so you'd need to disconnect it (the pins providing power, not the switched input/output) somehow to run on batteries.  So do the USB integration devices if they're built in (usually they're not on sonoffs).  It's usually a good idea to remove any power LED if it has one, but the other LEDs can be left if they are off when the device is sleeping.  The ESP01 is usually the best choice for a sleeper, though if you can find a bare ESP12 it may work well.

Could TX/RX be reversed?  The LuaLoader should adjust to the baud rate, though older MPP V1 & V2 devices use 9600bps when they come up if it helps.  If the chip hits a problem when booting it'll show errors at 78600bps (not 100% sure of the exact value...), or sometimes 115200.  But it does sound like it's working if it's available in AM so it's probably the RX/TX connection since +5 and gnd must be ok.  You may want to update to V3 as soon as you get it sorted so you can manage it OTA instead.

[Steve Marshall]

Thanks for that.  I dug out an old Win7 laptop and have managed to flash MppSleeper into the Sonoff.  It appears in AM but against Firmware in "Details" it shows "MppArduino 1.2.0/MppSleeper 1.1.0" - is that what it should look like?  I downloaded everything from the page headed V3 Flashing.  When I try to rename the device in AM it always times out and I can't do it - is that because it has gone to sleep?

I hear what you say about disconnecting the relay, that's fine.  And I guess I will have to figure out how to wire a switch to short RST to GND.  I can see a GND location on the board, but it's unclear to me where RST is at the moment.  And I may not be far enough down the track yet, but it's also unclear to me how/where to configure what happens when the MppSleeper is toggled.  Anyway, getting there - maybe.

EDIT: I have removed the relay from the board, and it still seems to work ok.  Just in case, I re-flashed the MppSleeper firmware.  Still don't seem to be able to get any further, but that's maybe because I don't yet have a button rigged up to wake the device.  But if I go into AM / ESP8266 Devices, it shows that the MppSleeper software is "still loading...".  I can't get to its web page either - should I be using the port number (8898) when I do that?  I've tried with and without - just times out.  I'm beginning to wonder if the Sonoff SV is not suitable for this.

[Mike P 4 MPP]

Yep, that firmware sounds right.  MppSleeper goes to sleep after 10s so it won't respond to anything until it's restarted.  You can keep it awake by hitting it's web page within 10s after a restart - that extends the sleep timeout to 5 minutes.  The device web page should be available on port 80.

It's quite possible RST isn't accessible on the board, itead usually doesn't run all of the ESP8266 pins out to contacts.

You might want to use MppSensor until you get it running, MppSleeper is a bit tricky to use the first time.  Once you're ready you can flash MppSleeper over MppSensor using the web page (the UDN will change so you'll need to forget the old sensor).  Use the web page or the AM ESP8266 manager to get it to stay awake for 5 minutes while you finish configuring it.

[Steve Marshall]

OK, thanks for the suggestions. I was able to call up the web page of MppSleeper by being quick enough, so that bit does work.  I have flashed MppSensor into the Sonoff, and managed to do it on the Win10 laptop, somewhat to my surprise.  I think what did the trick was running the flasher as administrator.  I can call up its web page too, but I cannot flash different firmware using the web page - I get the error as per the screenshot fragment above.  But that's a side issue - I don't think this is going to go anywhere with the Sonoff SV, because I can't access the RST pin - or if I can I have no idea where.  So I will have to track down another more suitable device before I can get any further.  No big deal, and a different device will be smaller anyway.

EDIT: You suggested ESP-01 devices as being suitable for MppSleepers - I've found any number of them on Ebay and elsewhere, but where is RST on them?  As far as I can see it is not one of the 8 pins on the end.  Are there different variations of ESP-01?

[Mike P 4 MPP]

I wonder if the sonoff is a 0.5MB device?  There should be more than enough room in a 1MB device (most are that or more), the binaries are < 400KB.

The ESP01's should have +5, GND, TX, RX, CE, RST, GPIO0, GPIO2 on the pinouts.  Be sure to grab a programmer (or a few) - the ones with the 8 pin connector for the ESP01.  They make handy power supplies for ESP01s if you deploy them with a USB charger block,. and excellent programmers for any of the ESP8266 devices that don't come with native USB.

[Steve Marshall]

I'm pretty sure the Sonoff SV has 1MB of flash available, so I suspect it's something else masquerading as a memory problem. I've attached a pic of an ESP-01 I found - is this what you expect to see?  So is RST on pin 6 - the one labelled EXT_RSTB?  Somehow I'd missed that.  And I assume the momentary switch should short that to GND for the MppSleeper. Should Vcc be 5V or 3.3V for these?

[Mike P 4 MPP]

Yep, that's right, pin 6 is RST, and you do ground it for an instant.

You want to get the breakout boards for the ESP01's, again with 8 pin connectors to hold them.  They make it a bit easier to hook them up as well.

The ESP01's run off of battery voltage - 2v5 to 3v3 should be ok.  I use an AM trigger to detect any battery value < 2.5 with an action to send an email to me to know when to change it - MppSleeper updates the battery value on every button push.  I'd try to use rechargables until you get the kinks out if you can't measure the power use with an ammeter (which can be a bit of an adventure) so you don't burn through too many batteries...

That ESP01 picture shows it has a power LED that you might need to remove.  It was pretty easy to flick it off using the soldering iron for the one I had. I try to use the ESP-01S when I can which doesn't have the power led.

I just double checked flashing MppSleeper and MppSensor over MppSleeper and it seemed to be ok.  The size numbers look a bit weird in that screen cap but I'm not sure (they're a bit hazy).  It could be a problem with the flash type, I use DIO for the web upload (it's supposed to work with all) but it could be the older sonoff's use one of the other types.  You may be stuck with updating it via USB so you can select the flash type directly.

[Steve Marshall]

Thanks, that's all very helpful.  I'll see if I can find some ESP-01S devices, and some USB-serial adapters, and we'll see where I can get with them.  All good fun!

Last thought for now - so will 5V on Vcc kill an ESP-01?

[Curtis E]

yessir, 5V is going to kill the chip

[Steve Marshall]

OK, my ESP-01S devices arrived, so I have been ascending the learning curve.  Here's what I have done:

1. Successfully flashed nodemcu_integer_4mpp.bin (I believe) using ESP8266Flasher.exe.  I have one of the USB-serial adapters that an ESP-01 plugs into directly, so all I had to do was wire a switch to allow putting it into flash mode.  All seemed to work.

2. Tried to talk to it on the serial interface with LUALoader, and MPPController.  Not a lot of joy - I'm not familiar with what I should be seeing.

3. Tried flashing MppDevice.bin - seems to flash ok, but...

4. I don't think the WIFI is doing anything useful.  I can't see an AP on my phone, and AM/ESP8266 Devices doesn't show me any.  As far as I can see, I have not set the SSID and password for my wireless network, despite trying several times in MPPController.

5. So I tried re-flashing the base NodeMCU firmware, and now it is behaving differently.  It seemed to flash ok, but now when I start it up in normal mode, the blue LED flickers constantly - it's almost continuously on.  I'm sure it didn't do that the first time I flashed the NodeMCU firmware.

So, the learning curve is feeling a bit steep here at the moment!  Any suggestions would be welcome.

EDIT:  Not sure what I did differently, but I just flashed MppDevice into another of the ESP-01s, and I can call up its webpage and have managed to set the SSID and password for my network, yay.

I can now see the device in AM/ESP8266 Devices, but it is showing "MppSetup1.0.0 still loading..." and has been for several minutes now.  How long should that take?  Is there a problem?

So how do I now change this into an MppSleeper or whatever?  Just upload the MppSleeper.bin file via web page?  It's not clear to me how to do it via AM.

And another edit:  I think I am getting the idea that I don't need the nodemcu_integer_4mpp.bin at all if I'm using all the new V3 firmware, which I am.  So I just started from scratch with another ESP01 and flashed MppDevice first, and it all feels quite smooth.  I can see it in AM and can set the SSID/password in MppArduino, so I can get them onto my network.  Both devices are still showing "still loading..." for the Device property in AM/ESP8266 Devices.

[Mike P 4 MPP]

Good progress :).

Right, you shouldn't use that old integer bin file anymore.  If you have a flickering blue light the flash didn't work so you'll need to try again using a USB flasher.

MppDevice is really only for testing and setup so it won't show anything useful in AM and will sit there showing loading.  I haven't bothered much with getting that sorted because you shouldn't stay with it.

In MPP V3 you don't change the device type from AM anymore, you (as you've guessed) apply the firmware you'd like - so use MppSleeper.bin.  Easiest is to do an OTA update from the device's web page.  Remember the MppSleeper will go to sleep after 10s!  Hitting the device's web page again with your browser will give you 5 minutes to sort it.

Once you've got the desired firmware going, AM will be able to check for updates and install them for you (except for MppDevice/MppSetup as there are none).  MppSleeper and MppReporter need to be woken to apply updates.

[Steve Marshall]

Thanks Mike.  As far as setting up the MppSleeper is concerned, seems to me the only properties I should need to set are the server IP and the event name, is that right?  If not then what else needs to be set?  And event names are just arbitrary things that I can make up, yes?

I started with the NodeMCU firmware because that's where I started reading all the stuff about the ESP8266 devices.  The distinction between the two firmware "worlds" could perhaps be made a little clearer on the web pages, but that's not a complaint - I'm so impressed with what you are doing here, thanks!  And the new world of Arduino-based devices seems to be a very worthwhile step forward, good stuff.

I've been working with computers for just over 50 years, but it still blows me away how much functionality can be embedded on this little thing the size of a postage stamp - a SMALL postage stamp at that!

[Steve Marshall]

Victory!  I have my first MppSleeper switch all set up and running on 2 AAA batteries.  And working perfectly, of course.  I love this! Now to start thinking up some uses for the other ESP-01s I bought...

And another edit:  What is a sensible minimum level to set in the rule that watches the MppSleeper battery?  That is, how low can the battery voltage go before the ESP01 stops working reliably?

[Mike P 4 MPP]

Nice!  Yeah, I really like these things, there's something very satisfying about physical changes vs pretty pictures on a web page in a laptop...

Rechargable batteries usually start at about 3V (for the pair), and non-rechargeable at about 3V3 if I remember right.

I find the ESP01 starts to get unreliable below about 2.4 so I set the minimum at 2.5 for mine - that's a very long time for a pair of AAA's and even if you're using the button once a month the use is so low there's plenty of time for it to report under voltage before it dies.

[Steve Marshall]

Ok thanks Mike.  I had set the rule at 2.8V, but I'll drop it down a few decimal points.

Yes, you are right - it's amazing how compelling it is to see something react remotely to something, either at the end of a cable or (even better) through the air.  In my work I do a lot of development for a client who uses sophisticated analytical instruments to test electronic gear for RF emissions and/or susceptibility, so lots of connecting up to analyzers, signal generators etc etc to control them and capture data.  Great fun.

And because of the same problem as most commercial home automation, i.e. operation through unknown foreign servers, I wrote my own software to monitor my solar panels here at home instead of using the manufacturer's system.  Works great, and no questionable connections to who-knows-where. Oh, and I've just discovered that my semi-smart TV has a low-level wifi interface, plus all the data for simulating buttons on the IR remote, so my own TV remote app is now on my to-do list as well.  I can't help myself really - if I discover that something is programmable or remotely controllable, I just have to see if I can get it doing stuff.  Must be a control freak I think!

[ChrisM]

Hey Mike,  I'm using MPPSleeper loaded onto an ESP01 as a battery operated switch to trigger lights.  

The NO pushbutton switch is wired between RST and GND.  Using 2 AAA batteries to power the ESP connected to 3V3(+) and GND(-).  Have the IP address for the sleeper configured as static and reserved in the DHCP table of the router.  I have the sleeper configured to send an event message and a rule that triggers on that message.  

Closing and opening the switch wakes the sleeper (it is accessible by browser)  but the sleeper doesn't send the message.  Once the sleeper is awake, and before it goes back to sleep, if I close and open the switch, the message is sent and the rule is triggered.  I checked the log and there is no indication that AM is receiving the event message on the first activation of the switch but it is clearly seen on the second activation.

Appreciate any ideas you may have to help figure this out.

Thanks

Chris

[MikeP 4 MPP]

Bit tricky to say without seeing the MppArduino log...  WAG would be the SleepTime is too short to allow it to connect and report - maybe a longer SleepTime and a shorter EarlySleep timer would help.  But that doesn't fit the browser can connect (which is going to put it into "NoSleep" mode).  Closing the switch is going to cause another boot, right?  Hard to understand why it wouldn't report on the first boot but does on the second.

[ChrisM]

Hi Mike here is the output from the ESP01 serial port.

With the ESP01 asleep, shorting RST to GND results in

;ld⸮⸮|⸮$⸮|  ⸮d⸮ c|ǃ ⸮ ⸮{⸮c⸮b⸮⸮og⸮l'o⸮⸮⸮b x⸮⸮l;l{l

The device remains asleep

Shorting shorting RST to GND a second wakes the device.  Here is the output from the monitor:

rld⸮⸮|⸮l⸮|  ⸮ $⸮ c|⸮⸮ ⸮ ⸮;⸮c⸮ c⸮⸮g'⸮lng⸮⸮⸮c x⸮⸮l;l{lx⸮o⸮  ⸮d⸮⸮ # g⸮| ⸮⸮Ǐ⸮#⸮⸮ng⸮$⸮⸮l ⸮ gnd` gs⸮ۓn ۓ⸮` ;⸮⸮g ⸮⸮⸮` ⸮s$⸮⸮l ⸮| ⸮` ⸮⸮'⸮ ⸮#d` ;⸮g laddSubscriber to MppSleeper_807d3a41c500

added subscriber 192.168.2.37

192.168.2.37 subscribed until 600048

MppSleeper BOOT! Reason = 5/Deep-Sleep Wake

MppServer restarted: Deep-Sleep Wake on SDK:2.2.2-dev(a58da79)/Core:2.7.2=20702000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be

Device Configuration:

{"gw":"192.168.2.1","OUTPUTIP":"","ip":"192.168.2.232","SensorPin":"","StaticIp":"true","NotifyType":"","ServerIp":"192.168.2.37","ButtonPin":"","EnablePin":"","WifiPin":"","NoMulticast":"true","WifiRetry":"","EarlySleep":"","AwakeTime":"10","IpMessage":"Sleeper01","WifiActive":"","nm":"255.255.255.0","UseUdp":"","Version":"MppArduino 1.11.5","MppVersion":"MppSleeper 1.6.0","uid":"807d3a41c500","ssid":"Farley"}

Connecting...

heap=31896 at 0s, v=3.39, sleep in 10s

Wifi connected to Farley(50:6a:03:ae:58:2c) on ch=1

.

Wifi ip=192.168.2.232, gw=192.168.2.1, nm=255.255.255.0

.

807d3a41c500 connected to 'Farley' at 192.168.2.232 rssi=-52

OUT: STARTING: 807d3a41c500 as MppArduino 1.11.5 / MppSleeper 1.6.0...

OUT: RESTARTED: 807d3a41c500 - Deep-Sleep Wake

OUT: CONNECTED: 807d3a41c500 to 'Farley' at 192.168.2.232  rssi=-52

MppDevice MppArduino 1.11.5 / MppSleeper 1.6.0 / 807d3a41c500 is open and ready for business...

sendHttp to http://192.168.2.37:4030/events/Sleeper01 

Notifying with {"location":"http://192.168.2.232:8898","state":"on","value":"3.39","firmware":"MppArduino 1.11.5/MppSleeper 1.6.0","group":"807d3a41c500","mac":"80:7D:3A:41:C5:00","udn":"MppSleeper_807d3a41c500"}...

Sent notification to 192.168.2.37:8898 (197 bytes sent)

Notifications sent.

Notifying with {"location":"http://192.168.2.232:8898","state":"unknown","value":"3.39","firmware":"MppArduino 1.11.5/MppSleeper 1.6.0","group":"807d3a41c500","mac":"80:7D:3A:41:C5:00","udn":"MppSleeper_807d3a41c500"}...

Sent notification to 192.168.2.37:8898 (202 bytes sent)

Notifications sent.

heap=29792 at 1s, v=3.39, UPDATED, sleep in 9s

heap=30464 at 2s, v=3.39, UPDATED, NOTIFIED, sleep in 8s

heap=30464 at 3s, v=3.39, UPDATED, NOTIFIED, sleep in 7s

heap=30464 at 4s, v=3.39, UPDATED, NOTIFIED, sleep in 6s

heap=30464 at 5s, v=3.39, UPDATED, NOTIFIED, sleep in 5s

heap=30464 at 6s, v=3.39, UPDATED, NOTIFIED, sleep in 4s

heap=30464 at 7s, v=3.39, UPDATED, NOTIFIED, sleep in 3s

heap=30464 at 8s, v=3.39, UPDATED, NOTIFIED, sleep in 2s

heap=30464 at 9s, v=3.39, UPDATED, NOTIFIED, sleep in 1s

Wifi disconnected from Farley, reason 8 ASSOC_LEAVE

[ChrisM]

Hi Mike, further to capturing the log, I tried a second ESP01 and it behaves the same way.  

firmware is MppDevice MppArduino 1.11.6 / MppSleeper 1.6.0

Here is a paste of the properties screen from the browser connection

Properties
uid
a4cf12a03cab
MppVersion
MppSleeper 1.6.0
Version
MppArduino 1.11.6
OUTPUTIP

nm
255.255.255.0
gw
192.168.2.1
ip
192.168.2.196
StaticIp

WifiActive

WifiPin

WifiRetry

NotifyType

EarlySleep

EnablePin

UseUdp

SensorPin

AwakeTime
10
IpMessage
Sleeper01
ServerIp
192.168.2.37
ButtonPin

ssid
Farley
NoMulticast
true

[MikeP 4 MPP]

Looks a bit odd on startup, maybe a wiring/power problem?  Setting the baud rate to 78kbps for boot will show those messages if you need to see them.  I wonder if it's wiring - you may want to try connecting CH_PD (probably), GPIO0 (maybe), and GPIO2 (maybe) to VCC, and double check RST floats high on it's own  (probably)  or you'll need a resistor (10K or so) to VCC.

[ChrisM]

Thanks Mike.  I'll try your suggestions and let you know how I make out. 

Also, I just noticed on your web pages in the description of the properties for the sleeper it mentions;

"PullUp - if true the sensor input will have the pullup resistor applied. Default float"

I didn't set that property.  Should it be set to true?  Would that have the same effect as the 10K pull up resistor you mentioned?

Thanks again

[MIKE POLAN]

Pullup is only for the GPIO’s and isn’t really necessary in most cases.  If GPIO0 is wired low at reset the device goes into flash mode, and GPIO2 low at startup does something with the flash memory but I leave both open on my ESP01s.  RST and CH_PD don’t have pullups, but some boards add them, e.g. the wemos and nodemcu boards.  I think on mine just jumpering CH_PD to VCC was enough, but they’re assembled and I can’t easily see right now… 

 

Sent from Mail for Windows 10

--
You received this message because you are subscribed to the Google Groups "MppDevices" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mppdevices+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mppdevices/fb4cd693-5741-459e-9ae2-161b9886bd6cn%40googlegroups.com.

 

[ChrisM]

Hi Mike, thanks.  Unfortunately no change after tying CH_PD to VCC and adding 4.7K pull up onto RST. If you have any other thoughts or suggestions I'm all ears.

[MikeP 4 MPP]

Ok, what I'd do next is have a look at those startup messages.  In MppArduino under "Port" you can set the baud rate to 74880.  See if there's an error message in the 1st startup, and see if the 2nd startup message differs from the first.  After checking, go back to 115000.

Also, for some reason the startup log in the 2nd boot is garbled and doesn't catch the full sequence.  So there's something wrong there too, not sure what though.

What happens if you boot a 3rd time?  How long do you need to wait before a 3rd boot fails like the first?

What are you using for the USB connector?  I see VCC is 3.39V so it's probably ok, but some of the behavior suggests a power or GND problem.

I use the ESP01 USB adapter for all of my coding/flashing/setup/testing because the wiring is all done (and I've added on a flash and reset button) to make sure it's working.  Then I move it to one of those protoboard sockets in the actual button device which changes the hw a bit.  Are you wiring it in place or are you working the same way?

[ChrisM]

Hi Mike, I am using a USB connector that the ESP01 plugs into and then a short jumper to bring RST to GND.

With baud rate at 74880, device asleep, grounding RST and releasing prints this message to the serial monitor.

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

With baud rate at 74880, device asleep, grounding RST and releasing a second time prints this to the serial monitor and wakes the device.

 

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

load 0x4010f000, len 3664, room 16 

tail 0

chksum 0xee

csum 0xee

v39c79d9b

~ld

V2

Mo (after this line the text is unreadable, presumably because baud rate of the device changed to 115200)

Here is a complete log sequence (at 115200) capturing device on power up, after 10 seconds goes to sleep, 1st grounding of RST, 2nd grounding of RST, device wakes, after 10 seconds returns to sleep.  If I bring RST to gnd a 3rd time it does not wake. On the fourth grounding, the device will wake.

/Device is powered up

heap=31632 at 2s, v=3.40, sleep in 8s

.

Wifi connected to Farley(50:6a:03:ae:58:2c) on ch=1

..heap=30960 at 3s, v=3.40, sleep in 7s

Wifi ip=192.168.2.196, gw=192.168.2.1, nm=255.255.255.0

.

a4cf12a03cab connected to 'Farley' at 192.168.2.196 rssi=-48

OUT: STARTING: a4cf12a03cab as MppArduino 1.11.6 / MppSleeper 1.6.0...

OUT: RESTARTED: a4cf12a03cab - External System

OUT: CONNECTED: a4cf12a03cab to 'Farley' at 192.168.2.196  rssi=-48

MppDevice MppArduino 1.11.6 / MppSleeper 1.6.0 / a4cf12a03cab is open and ready for business...

sendHttp to http://192.168.2.37:4030/events/Sleeper01 

Notifying with {"location":"http://192.168.2.196:8898","state":"on","value":"3.40","firmware":"MppArduino 1.11.6/MppSleeper 1.6.0","group":"a4cf12a03cab","mac":"A4:CF:12:A0:3C:AB","udn":"MppSleeper_a4cf12a03cab"}...

Sent notification to 192.168.2.37:8898 (197 bytes sent)

Notifications sent.

Notifying with {"location":"http://192.168.2.196:8898","state":"unknown","value":"3.40","firmware":"MppArduino 1.11.6/MppSleeper 1.6.0","group":"a4cf12a03cab","mac":"A4:CF:12:A0:3C:AB","udn":"MppSleeper_a4cf12a03cab"}...

Sent notification to 192.168.2.37:8898 (202 bytes sent)

Notifications sent.

heap=30320 at 4s, v=3.40, UPDATED, NOTIFIED, sleep in 6s

heap=30320 at 5s, v=3.40, UPDATED, NOTIFIED, sleep in 5s

heap=30320 at 6s, v=3.40, UPDATED, NOTIFIED, sleep in 4s

heap=30320 at 7s, v=3.40, UPDATED, NOTIFIED, sleep in 3s

heap=30320 at 8s, v=3.40, UPDATED, NOTIFIED, sleep in 2s

heap=30320 at 9s, v=3.40, UPDATED, NOTIFIED, sleep in 1s

Wifi disconnected from Farley, reason 8 ASSOC_LEAVE

/ Device is asleep

/First grounding of RST

{$l⸮⸮|⸮d⸮|  ⸮l⸮#|⸮⸮ ⸮ ⸮s⸮b⸮#⸮⸮no⸮$gn⸮⸮⸮ c p⸮⸮ds$sd

/Second grounding of RST

rld⸮⸮|⸮l⸮|  ⸮ $⸮ c|⸮⸮ ⸮ ⸮;⸮c⸮ c⸮⸮g'⸮lng⸮⸮⸮c x⸮⸮l;l{lx⸮o⸮  ⸮d⸮⸮ # g⸮| ⸮⸮Ǐ⸮#⸮⸮ng⸮$⸮⸮l ⸮ gnd` gs⸮ۓn ۓ⸮` ;⸮⸮g ⸮⸮⸮` ⸮s$⸮⸮l ⸮| ⸮` ⸮⸮'⸮ ⸮#d` ;⸮g laddSubscriber 192.168.2.37

added subscriber 192.168.2.37

192.168.2.37 subscribed until 600048

MppSleeper BOOT! Reason = 5/Deep-Sleep Wake

MppServer restarted: Deep-Sleep Wake on SDK:2.2.2-dev(a58da79)/Core:2.7.2=20702000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be

Device Configuration:

{"uid":"a4cf12a03cab","MppVersion":"MppSleeper 1.6.0","Version":"MppArduino 1.11.6","OUTPUTIP":null,"nm":"255.255.255.0","gw":"192.168.2.1","ip":"192.168.2.196","StaticIp":null,"WifiActive":null,"WifiPin":null,"WifiRetry":null,"NotifyType":null,"EarlySleep":null,"EnablePin":null,"UseUdp":null,"SensorPin":null,"AwakeTime":"10","IpMessage":"Sleeper01","ServerIp":"192.168.2.37","ButtonPin":null,"ssid":"Farley","NoMulticast":"true"}

Connecting...

heap=31856 at 0s, v=3.40, sleep in 10s

Wifi connected to Farley(50:6a:03:ae:58:2c) on ch=1

...heap=30960 at 1s, v=3.40, sleep in 9s

..

Wifi ip=192.168.2.196, gw=192.168.2.1, nm=255.255.255.0

.

a4cf12a03cab connected to 'Farley' at 192.168.2.196 rssi=-46

OUT: STARTING: a4cf12a03cab as MppArduino 1.11.6 / MppSleeper 1.6.0...

OUT: RESTARTED: a4cf12a03cab - Deep-Sleep Wake

OUT: CONNECTED: a4cf12a03cab to 'Farley' at 192.168.2.196  rssi=-46

MppDevice MppArduino 1.11.6 / MppSleeper 1.6.0 / a4cf12a03cab is open and ready for business...

sendHttp to http://192.168.2.37:4030/events/Sleeper01 

Notifying with {"location":"http://192.168.2.196:8898","state":"on","value":"3.40","firmware":"MppArduino 1.11.6/MppSleeper 1.6.0","group":"a4cf12a03cab","mac":"A4:CF:12:A0:3C:AB","udn":"MppSleeper_a4cf12a03cab"}...

Sent notification to 192.168.2.37:8898 (197 bytes sent)

Notifications sent.

Notifying with {"location":"http://192.168.2.196:8898","state":"unknown","value":"3.40","firmware":"MppArduino 1.11.6/MppSleeper 1.6.0","group":"a4cf12a03cab","mac":"A4:CF:12:A0:3C:AB","udn":"MppSleeper_a4cf12a03cab"}...

Sent notification to 192.168.2.37:8898 (202 bytes sent)

Notifications sent.

heap=29160 at 2s, v=3.40, UPDATED, sleep in 8s

heap=30320 at 3s, v=3.40, UPDATED, NOTIFIED, sleep in 7s

heap=30320 at 4s, v=3.40, UPDATED, NOTIFIED, sleep in 6s

heap=30320 at 5s, v=3.40, UPDATED, NOTIFIED, sleep in 5s

heap=30320 at 6s, v=3.40, UPDATED, NOTIFIED, sleep in 4s

heap=30320 at 7s, v=3.40, UPDATED, NOTIFIED, sleep in 3s

heap=30320 at 8s, v=3.40, UPDATED, NOTIFIED, sleep in 2s

heap=30320 at 9s, v=3.40, UPDATED, NOTIFIED, sleep in 1s

Wifi disconnected from Farley, reason 8 ASSOC_LEAVE

/Device is asleep

[MikeP 4 MPP]

I'm stumped... on the 2nd boot everything is ok, but for some reason the first boot just stops without finishing - it never gets to the flashed binary.

Maybe try to reflash?

Are you using this adapter?  I have a lot of success with this adapter but others have given me trouble. 

[ChrisM]

Thanks Mike.  I'm using this one I bought off amazon.  

It has the switch that makes flashing a bit easier.  I have already tried refreshing a couple of times. If there is an older version of the firmware I'd be happy to give it a try.  I've also tried the ESP01 with 2 AAA batteries (I'm using the same toy buttons you used) and same result.  

Its a weird one.

Chris

[MikeP 4 MPP]

I don't think it's firmware - on the second boot everything works, but the first boot doesn't seem to launch anything - it stops without loading from flash at all.

Might be interesting to remove the ServerIp so the device doesn't go to sleep and try booting a few times.  And maybe try the same with MppDevice.bin to see if it's different.

I'm not sure how that would help figure anything out :), but might narrow it down to whether it's related to deepsleep.
Is there a reset button on that adapter?  I'm guessing you move the switch to PROG, boot, then move it back to flash?

[Chris McGaffey]

Hi Mike, with that USB plug in, I slide the switch to Prog, plug it in and flash. Remove it when the flash completes and then slide the switch to uart and use the serial monitor. I will try what you’ve suggested and report back. Thanks

To view this discussion on the web, visit https://groups.google.com/d/msgid/mppdevices/5ced4a08-dcaa-4c4d-9f7c-5ae71fc7eb2dn%40googlegroups.com.

[DougC]

Those buttons are great aren't they. I have them with MppSleeper too.  I don't use any pullups or pulldowns on my ESP-01 chips in this application. 

I think I've seen a few instances over the years where a device fails to boot up properly but a power up sorts it out - not really investigated due to lack of diagnostics at the time, but it could be a similar sort of thing. Never seen it as consistent as this though.

Are the chips you are using all from the same batch? Are they of particularly new or old manufacture? - and do you have any other ESP chips you could compare behaviour with?

One other question this has reminded me of is whether it is correct/incorrect/harmless to specify Property StaticIp=true when using DHCP reservation in your network. I  do see it is irrelevant to this particular problem btw.

[ChrisM]

Hi Doug, I bought a 4 pack of ESP01's about a year ago.  So I'm guess yes, they're probably all from the same batch. 

I flashed one just after receiving it with MppSleeper to see how that would work. I don't recall seeing this behaviour but not sure how closely I was looking.  Its only recently when I bought the switches that I realized I needed 2 clicks of the switches to make anything happen and started troubleshooting from there.  

I just flashed the device with a blank file and re-flashed MppSleeper.  Aside from setting up the wifi and setting awake time to 10sec, I  decided to leave all of the other properties unconfigured.  

The device is reporting that it is in configuration mode.  I thought setting awake time and rebooting got me out of configuration mode last time but obviously I missing something.  How do you get the device out of configuration mode?

Thanks

[DougC]

it may be if you have the device web page open in your browser that could keep it awake.

[MikeP 4 MPP]

Right, those adapters seem to have everything they need to run the chips.  I use them for programming, and when I have an ESP01 near a power supply.  I use this breakout board with mine:

I've added momentary switches to RST and GPIO0 for flashing and testing.  It plugs into the adapter and then the ESP01 plugs into it, and I prototype by adding wires using the pins.

Just checked my battery switches, I use the breakout there with no extra bits - just VCC, GND, and a momentary button to short RST to GND.

Very puzzling about the ESP01 not finishing the reboot, Doug might be on the right track about version.  Are there any labels on the board that indicate type or version?

Right, if using DHCP reservations it's best to clear StaticIp - it shouldn't hurt but it can cause confusion later when you forget it's set :).

[Chris McGaffey]

I did close the page after setting the awake time.  Rebooted and I see in the serial monitor that it remains in configuration mode.

To view this discussion on the web, visit https://groups.google.com/d/msgid/mppdevices/a2dae7e2-fafc-45ea-b51c-ee3acf35bae9n%40googlegroups.com.

[Chris McGaffey]

Thanks Mike.  I had reserved the address in the router and then set Static to true.  Since blanking the device and reflashing, the only parameters configured are the wifi ap and awake time. Right now its stuck in configuration mode.  Not sure how to get out of that mode.

You received this message because you are subscribed to a topic in the Google Groups "MppDevices" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mppdevices/vuC34vW7N5A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mppdevices+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mppdevices/63a349c6-62c3-4d2b-8d2f-9daba6e92f2fn%40googlegroups.com.

[MikeP 4 MPP]

Right, visiting it with a web browser will put it into config mode.  Rebooting with AwakeTime > 0 and ServerIp not null will let it sleep.

You'll need to double check with MppArduino to see why it's staying awake. 

[MikeP 4 MPP]

ServerIp - the code assumes that if ServerIp isn't set you're not done configuring it.

[Chris McGaffey]

Thanks Mike and Doug.  I was missing the server IP.  Once that was set the device goes to sleep as expected. Unfortunately, the same behavior is observed after the blanking and re-flashing.  I'll keep plugging away and let you know if I find the root cause.

You received this message because you are subscribed to a topic in the Google Groups "MppDevices" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mppdevices/vuC34vW7N5A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mppdevices+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mppdevices/e9cb7e0d-8b81-4403-8ad4-f1c57ba6440dn%40googlegroups.com.

[ChrisM]

Hi Mike can you explain the NotifyType property?

[MikeP 4 MPP]

Yep - you can suppress notifications based on the boot type - e.g. RST vs deepsleep vs soft reboot.  Very unlikely you'll need that here, it's only used when it's important not to trigger AM during setup/configuration of the device.  The config settings are going to be unrelated to the double-boot problem since the firmware isn't being started at all...