Shelly 1 - a new ESP8266 switch

[Yuval Hadas]

Hi,

I've found a new company selling ESP8266 devices from Bulgaria. One of the products is the Shelly 1, an open source switch similar to the SONOFF, with advantages (ready made header, AC and DC, small size, EU standards, 3500W, etc.) - https://shelly.cloud/shelly1-open-source/

I've ordered two (9.9 Euros each) and it is indeed easy to modify to work with AM:

1. Flash - ground GPIO0 and just follow Mike's instructions.

2. Setup as Relay (ButtonPin - 1 (GPIO5), RelayPin - 2 (GPIO4).

3. The physical switch is high-voltage, not 3v3, so you hook up a regular switch - follow the user guide).

I plan to replace one of my SONOFF basic's with the Shelly as I can reuse my original switch with the Shelly inside the wall.

However, one question to Mike - currently to I need to flip the switch up/down (or down/up) in order to toggle the light. Is it possible to setup the device to act "normal", i.e., one flip will toggle?

Happy new year.

Yuval.

[DougC]

That looks very interesting. Pretty small too. Am I right thinking it is a proper relay rather than a switched power supply like the Sonoff? Have you opened one up yet?

[Curtis E]

Picture shows a 12VDC coil voltage.  That relay can be ordered down to 5VDC coil voltage, but that means the unit has to power the chip at 3.3 and the coil at 12.  I think I would like to take one apart.

[Mike P 4 MPP]

Those do look like they're a handy size and they're at least marked with what looks like the necessary certifications so should be ok in wall.

I'm not sure I'm following on the need to flip the switch to set the light, isn't that what you want for a light switch?  MppRelay/MppSensor set the relay to follow the sensor value so up/on and down/off seem to make sense there.  Are you asking whether there's a way to use an input as a toggle instead?  The "button" GPIO input will toggle if touched, though if it's held too long the device will go into wifi setup mode.

[Yuval Hadas]

Oh, I was not clear...

The Shelly does not have a button, like the SONOFF, or other exposed GPIO's to use as sensors. You need to connect a high-voltage rated switch/button to GPIO5, so it makes sense to connect the original light switch. However, MPP relay works with a toggle button, so in order to switch the light on or off I need to "toggle" the switch (flip up and then flip down). I would like to have the device to toggle with one flip. This YouTube clip might help (minute 9:45) - https://www.youtube.com/watch?v=J20hxfUTP9I&index=21&list=WL&t=0s

[Mike P 4 MPP]

Usually for a light switch you'd configure the GPIO with a pullup so that it floats high, and wire the physical switch to pull the GPIO low, and then use the "follow" setting to have the relay match the switch position.

I think, if that's really what you want, you'll need to build a custom module...  And you're going to need to use a 3-way switch there with the switch pulling low on both sides and letting the input float high for a few milliseconds as the switch changes position.  Then you'll need to detect the high to low transition and use it to toggle the relay position.  

You won't be able to use the built in wifi button there as it's a momentary low (because you usually can't "pull" an input low by leaving it open), and holding it low will put it into wifi config mode.  But you could use the "Extension" setting to override the button interrupt handler to toggle the relay.

[DougC]

I had to get one!  My Shelly 1 dropped through the letterbox yesterday. My first thought was it looked like one of my kid's pencil sharpeners.

Similar experience as Yuval re flashing. Bit fiddly getting pins into the header as the slot in the casing didn't align with the header.

I've set it up as an MppMaker which seemed to me the best fit from the Mpp library. So the sensor device on pin 1 should show if the external switch is on or off and the relay device on pin 2 will of course be the state of the onboard relay.

I've not connected it to mains power yet. I'll set it up with a switch and lightbulb I guess.

[DougC]

Got my mains powered test set up. 

Operating the relay no problem.

However. If I switch the power on/off to the Shelly 'switch' connection I get unexpected behaviour from MppMaker.

So what I do see is that the on/off does correctly alter the state of the associated Mpp sensor device on gpio 5. But this does not seem to be being broadcast. I have to do a refresh from AM to find the new state.

Also, and possibly associated, I often see 'watchdog timer ' reboots of the chip when I am doing this. 

I have UDPIP and OUTPUTIP set in properties , so I get this little bit of diagnostic. I haven't yet dared to connect up MppController when the Shelly is on mains power. So I'll try adding in a few debug prints to the code to see where the trouble is happening.

[Mike P 4 MPP]

Yeah, I'd want to check the header pins very carefully against ground with a meter before I'd risk using it while on the mains, and you'd need to be very careful about swapping the line in wires after measuring just in case one side ends up live.

MppMaker was stable last time I tested it, but that was a while ago.

Assuming it's working properly, you might check that the ButtonPin setting is different than the SensorPin.  If they're the same and you're using a switch that's staying closed it might be causing the device to go into wifi recovery mode and reboot.  When it does it'll look for the old SSID and if it connects it'll go back into normal mode - you might see it's broadcast SSID for a short time.

Whenever the device is restarted/reboots it drops any AM subscriptions.  So AM won't see state updates until after the next time it refreshes and resubscribes.  This might explain why AM isn't seeing updates.

[DougC]

The  issue with not connecting your PC when the device is on mains power came up with he Sonoff POW too if I recall. After avoiding earthing issues I seemed to manage that OK, but since I only have one Shelly at the moment I guess I'll be careful with it for now.

re ButtonPin. no I was careful to avoid conflicts with pin assignments (been  there before!)

Something odd here that I need to sleep on I suspect. Might try their support chat . Looks quite a contrast to Belkin's.

[Mike P 4 MPP]

Another thing if there's doubt about the MppMaker would be to try the MppSenor type and use the option to have the RelayPin follow the SensorPin (that you'd connect to a regular lightswitch).

[Yuval Hadas]

Why use MppMaker or MppSensor? I'm using MppRelay and it is working perfectly (aside from the need to "toggle" the physical switch).

[Mike P 4 MPP]

If you use MppSensor you can configure it so that relay state follows the sensor state so using the original lightswitch you shouldn't need to toggle it.  If necessary use the sensor "Invert" property so that up is on, down is off.

MppMaker can be configured the same way but yes it is overkill for a simple lightswitch.

[Mike P 4 MPP]

But, MppMaker is of course the right solution so the switch can be a toggle from either state.

[Mike P 4 MPP]

Wait, it finally clicked (no pun intended!) with me for what you need Yuval!

Because you're using it with a rocker switch (vs most smart switches that are clicked via the button), you need the switch to behave like a 3-way switch would.  Because the light can be turned off from multiple locations (physically and via AM for example), it needs to change state when the rocker is moved.  Is that right?

That makes sense, I can do that - it may end up easier to do with an MppSensor vs an MppRelay, but I can add an option for the relay to toggle on sensor change instead of follow the state.

[Mike P 4 MPP]

Ok, posted MppMaker with this function.  Sorry for being so thick!

I put it in MppMaker since with a rocker on the sensor it seems appropriate to have the relay and switch state reported separately.

The latest MppMaker will now use the state of the "Follow" property to decide what to do with the relay.  If not set, the relay and sensor are independent.  If set to "true", the relay will follow the sensor (you can use "Invert" to change the sense).  If set to "false", the relay will be toggled when ever the sensor changes state.

[Yuval Hadas]

Bingo! (no pun intended...).

I'll check your updated MppMaker and report.

To my own logic, it is odd to think of a switch as a "sensor" or a "relay+sensor". However, the switch is a sensor (in a way).

[Yuval Hadas]

OK, the MppMaker with SensorPin=ButtonPin and follow=false works perfect! Now it is possible to toggle on/off via the rocker, as a "regular" switch, and to toggle via the AM. I think the Shelly 1 is a perfect solution when the physical switch should continue to function. furthermore, the Shelly 1 can be installed behind the switch due to its small size.

Thanks for the super fast update.

[Mike P 4 MPP]

Very cool, thanks Yuval!

[DougC]

Sounds like good progress and the logic sounds right to me too. My aim was always to get a smart switch into my lighting without affecting the operation of the existing dumb switches in any way (so as not to confuse granny and probably also to reduce the amount of rewiring to be done when we move house and have to revert everything back to 'normal')

I suppose the choice between Mpp Maker/Relay/Sensor basically comes down to which devices you want to be visible in Automation Manager?

Anyway I'm still seeing occasional reboots when flipping the switch/sensor, so I need to pursue that. Could be that I have a defective Shelly (should have bought 2!) or something about my test setup. Given that the Shelly has no LED and the reboot only takes a few seconds it is easy to miss. Yuval - you seeing anything like that?

[Yuval Hadas]

Doug,

I have no issues with my device. I bought two, flashed both, but only tested one.

My testing was with a temporarily connected rocker, bulb and a plug. after figuring out the pins, etc., I've kept that configuration for several days and it was stable. then I've connected the device to the "production" rocker. since then I have no issues, however, the rocker is hardly used, as the lights are turned on and off via AM (home entrance). Initially the device was MppRelay, however last day I've change it to MppMaker so the rocker can be used as a "normal" rocker. the new configuration is stable.

[DougC]

Thanks Yuval. One last question for now - are your Shellys same as mine? Labelled V3

[DougC]

Well I finally bit the bullet and connected the serial interface up to my laptop, while the Shelly was on mains power. (a few health and safety checks along the way to be sure)

Raised more questions than answers probably.

Running it as MppMaker btw

What I saw  after operating the Shelly sensor/switch a few times is a Panic for  task queue overflow from MppBuild1 line 146.

First thought was maybe I have too many AM servers subscribed to the device and it is running out of resource trying to post updates. Reduced that to just one server - and no difference.

Then I realised something else. The panic happens after exactly three switchings. Always. Doesn't matter if I do them quickly or wait 5 minutes before the third one.

Beyond me to even guess what's going on at the moment. Mike - you have any suggestions for further debugging?

Yuval. would you be able to do a test of this please? If not closely monitoring it, the reboot will just seem like a few seconds delay in the lights switching.(perhaps every third time?)

[Yuval Hadas]

V3

[Yuval Hadas]

I haven't encountered any of these. However, I did not check the device's log (I cannot access it any more, unless opening the switch-box). The device seems to response correctly all the time.

BTW, I think it is not recommended to connect via the serial while on mains.

[DougC]

OK thanks Yuval. It probably just is something about my setup then. 

Regarding the serial connection whilst on mains thing. Definitely good advice for the unwary, but if you are careful, check everything two or three times, and remember that electricity is all about potential difference, then it works out fine. 

[DougC]

Mike, I fully acknowledge I don't really know what I'm doing, but setting that task post at line 146 to high priority seems to circumvent my particular problem. Obviously that might likely have wider implications but may nevertheless help in understanding?

[DougC]

In fact, though I was looking particularly at the reboot issue, that has also sorted the lack of prompt notifications.

[Mike P 4 MPP]

Sure, I'll have a look.  When I've seen task overflows it's usually because the input is very noisy and causes a lot of interrupts - could that be the problem?  Do you have another device you could try?  If you haven't, try using the pullup on the sensor.

Setting the task to high priority shouldn't change the device function, and wasn't really necessary for basic operation so I left it as the default.

[Mike P 4 MPP]

Also using the MppMaker is needed for using the rocker switch as a toggle - either on board or using AM rules to monitor and act on it it separately from the relay.

For debugging, some prints sprinkled in the task interrupt task and back in the main handler might help.  I'll do the same here.

[DougC]

Thanks Mike. I had wondered whether the Shelly would be 'noisy' in its sensor transitions, but that's not apparent from the few messages I do see, nor from the observed behaviour.. 

And I had tried pullup on the sensor. It just stays pulled up.

What do you reckon on the failing after three transitions? That sounds like resources not being released somewhere. I suspect I was seeing something similar when I ran MppSensor on the Shelly, but will verify that. Sadly I only bought one Shelly for evaluation, so I can't eliminate the hardware item itself as root cause.

More testing...

[Mike P 4 MPP]

Yeah the 3 count is odd... If the input is ringing it'll keep pumping in new tasks and you won't see any other symptoms as the code will smooth them until it fails. You could try a trace message or count but the restart will drop then.

The sensor doesnt work with pullup enabled? Thats odd too... a small external cap might help.

I ran it on the simulator and it seemed ok. I'll test it on a real device soon.

[Mike P 4 MPP]

Ok, just double checked on my NodeMCU v0.9 and it seems fine (I did just post an update but that was to move to the newer OO timers).

[DougC]

Mike, I reinstated some of your debug prints in the NotifyListeners routine. As far as I can see from that, the task gets posted but never runs (except when I have altered it to run at high priority). So after some number of calls to NotifyListeners, I see a task queue overflow. Does that imply that the calling task is failing to complete and allow the (same priority) called task to run?

Putting my Problem Management hat on, I look for differences between what you have and what I have. The elephant in the room is the Shelly. Think I'll dig out one of my Lolin minis and configure it with the same parameters as the Shelly, then see what happens.

[DougC]

Sure enough. The Lolin mini works fine. Same firmware and software and pretty much same device properties file as on the Shelly.

So is it possible the (presumably newish) esp chips in the Shelly are behaving differently wrt task priorities? All seems very odd to me. Specially as Yuval sees no issues with apparently the same device.

I guess I'll have to get another Shelly or two so I can see if it is down to my particular piece of kit, or something dumb I'm doing...

[Mike P 4 MPP]

When you change the priority to high it allows the interrupt handlers to run and keep the queue from overflowing so that part makes sense - I don't think it's an issue with a difference in the firmware (it's the same firmware in both),  The problem is that the interrupts are coming in too fast, posting to the OS faster than they can be handled at a normal priority.  So changing the level can work but it'll probably mask the real problem and you might find the device is unstable later.  Every reboot clears the posted tasks, and it takes 3 clicks before they build up again and the device runs out of RAM.

If I understand, the shelly's have a converter that detects switched line in and presents it as a TTL output to the sensor.  I'm guessing these device is missing a filter, that the TTL side is ringing and flooding the device.  I would have thought using the internal pull-up would have helped but perhaps it's been blown?  Adding one plus a capacitor (on the TTL side) should quiet it back down if you can get to it on the board.  If a pull-up locks in the input as high it might be that the converter doesn't work well and isn't strong enough to present a good signal (which would cause ringing or a floating value).  A pull down might help, but it's possible this is a manufacturing defect and using another device might sort it.

The last option is to live with it if it's working.  My next device for the arduino is the MppMaker, maybe that one will be fast enough to handle any ringing.

[DougC]

Mike I disagree. I really don't think this is an issue with s flooding of interrupts, or ringing, as you say. The fact I can wait a few minutes before submitting the event that finally kills the device really confirms that to me. I will persevere with my testing,

[Mike P 4 MPP]

Yeah, it is odd.  The firmware is the same for both though, so it needs to be some sort of hardware thing that's blocking the posted tasks from running - either by itself or something preventing the main thread from giving up the CPU to let them run.  Setting them to high would pre-empt the main thread, but I hate that we don't know why that's necessary.  Maybe a thread leak if multiples are posted?  It'd happen though even with high priority, unless the priority is letting them run sooner to clean up so they don't leak.  I'll think on it a bit to see if I can come up with a way to test/force it either way.  Because I hate unknowns :).

[Mike P 4 MPP]

Maybe temporarily change the interrupt handler to just count the number of interrupts rather than post?  Then after a few clicks check the counter (you can't print in there 'cause it uses serial io which is another interrupt hander).

[DougC]

Hmm. tried what you suggested, Didn't reveal anything.

There is something odd going on with the serial IO though. I'd been suspecting dodgy breadboard wiring, but it's too persistent to be just that. MppController sees unsolicited stuff fine  but if I send in a command from it (eg the heap button), I see an acknowledgement (echo of the command) but no answer to the query itself.  I really need to start taking good notes. 

[Mike P 4 MPP]

Ok, that's good, seems to confirm there's no ringing on the input line.  But the lack of a response is telling - it suggests something is hanging up the device somehow even if it's not the sensor.  Could it be noise on the TX or RX lines?  Remember the serial i/o and the UDP io is all handled by interrupts in LUA and takes some time - so, like when debugging with C, the problem may still happen long after a message that doesn't show up, not just before - it can be tricky to nail down.

Since the firmware is the same between the working and non-working devices, I would concentrate on noise, power, and ground when trying to debug it.  I usually start with making sure the ground is solid as that can cause the weirdest problems, then double checking power is at the right level and that it's properly filtered (which can be tricky to determine) and finally signal noise.

[Mike P 4 MPP]

No promises, but the arduino version of MppMaker may be worth trying: https://sites.google.com/site/mppsuite1/esp8266-updates-v3.  Careful with the properties settings, I don't have much in the way of error checking and it's easy to shoot yourself :).  I did just yesterday by trying to move the button handler out of the way to pin 1...  which on arduino is the serial port.  Took me a bit to figure out what went wrong.

[DougC]

Looks like I might have to get stuck into the Arduino thing then.

I reduced my Shelly test to just the device itself connected to live and neutral 240V AC. No other wires connected at all. 

To be simpler still I put in MppRelay and reset the Properties just to get rid of any conflicting stuff left over from MppMaker. Set RelayPin to 2 of course.

Operating the relay from AM I can hear it click, so I know when it's working even without a lamp connected. Typically I get 8 operations before the task queue overflow is reported. Interestingly this doesn't cause a panic any more (??) so the fault persists without it having caused a reboot which would conceal it.

Where's the best tutorial on Arduino?

[Mike P 4 MPP]

At least for now you shouldn't need to do anything but install the MppMaker.bin from that link with whatever firmware installer you use.  Run the serial port at 76800 and use the command line "help" to see how to set the wifi.  Once setup you may need to format the FS.  

If you use eclipse then you'll want to install the C/C++ stuff (CDT) and I'm currently using the sleober add in because the CDT version has a bug and won't build arduino, they have a tutorial.

I haven't tried the "native" arduino tools and I'm not sure if it'll work, but they have a tutorial as well.

[DougC]

Thanks for the pointers Mike. I guess I'll start on something expendable, like an ESP-01. 

[Mike P 4 MPP]

Not to worry, it won't cause any damage or brick it :).  I was stuck 'cause I didn't have wifi where I was working so USB/serial was my only option.  One nice thing is the OTA support, after the first load it's much faster, and the ESP01 is even easier 'cause you don't need to jumper the flash..

[DougC]

No success so far putting MppDuino onto my Shelly. Same results as when trying to put it onto an ESP-01. I may be missing something.

[DougC]

Having put V3/Arduino on my Shelly, the good news is that the failure after several operations of the relay has gone away.

However I'm now seeing some other seriously weird stuff. I'll need to set up one of my Sonoffs as an MppRelay on V3 so I can compare which of what I'm seeing is to do with the firmware, and which with the hardware.

[Mike P 4 MPP]

Just double checked by using V3 MppRelay on a wemos mini, seems to be working fine.  Can't remember if I mentioned it here, but the arduino uses "proper" pin numbers vs the NodeMCU/LUA.  In V3 the GPIO0 is pin 0, GPIO1 is pin 1, etc.  There's a new table at the bottom of https://sites.google.com/site/mppsuite1/esp8266-updates-v3 with the updated pin numbers.  I hope the weirdness isn't from using the wrong pin numbers! I've made that mistake once or twice.  The new sensor input pin overlaps the old TX/RX pin - so serial data out causes the interrupt handler to go nuts...

[DougC]

I'll check all that out. I've left a lot of things to default, which may be part of the problem.

[Mike P 4 MPP]

I'm using the black ESP01 with 1MB of memory, it says "AI-Cloud inside" (which I think is a little optimistic...).

The defaults are a bit general, the ESP01 does use different values.  Not sure about the shelly though.

[DougC]

I set up my Sonoff Basic with V3 MppMaker as close as possible to the same properties as my Shelly. It worked perfectly of course. Except, out of the blue, a message about wifi restart mode, then strange stuff in the serial log followed by an exception and reboot. I was using MppController for monitoring (out of habit). I attach the key bit of the log. Don't know if it reveals anything useful.

re the esp-01s. Mine only have "ESP-01 S" and "S Series" on them. They are black.

More interesting though, their flash chip is a PUYA P25080H and there has been some discussion in the Arduino community about spiffs problems with them.  A bit over my head.

[Mike P 4 MPP]

"last failed alloc call: 00000006(48)" might mean an out of memory condition, not sure why it would happen though.  (The weird text is a restart at a different baud rate).

It'd take me a few hours to massage the output (or to write a parser) into exception analyser input ...  Unfortunately MppController doesn't work with the dumps, the output is reversed and the timestamps mess it up.

If you can capture it raw using a serial port monitor (there's one in the arduino IDE) I might be able to figure out what happened.  I did have an earlier bug where incoming discovery/subscribe messages were stopping on memory (class C bug, forgot to use len+1!!!), fixed in 0.4.1 and they've been rock solid for me since then.

[DougC]

Thanks Mike. I'm still fumbling around in the dark with the Arduino stuff in general (probably there's some irrational comfort factor in still using MppController)  Once I've worked out how it all hangs together I'll be a lot happier. For instance I had a go at compiling MppMaker, just to see if I could do it. I get an error    'class MppServer' has no member named 'handleCommand'     which I don't understand. I assume all the MppServer bits are in the .zip library I included, so why is the compiler not finding handleCommand?

[Mike P 4 MPP]

You need to update the library (unzip the new version over top) and the MppMaker.ino file together - if you did and that's broken it's my fault somewhere, I'll double check.

[Mike P 4 MPP]

Seems ok but I re-uploaded just in case I missed something.  Maybe re-download the zip file and re-add it (or unzip it into) the MppLibrary in the Arduino IDE?

[DougC]

Ah thanks Mike. I was assuming something that was wrong. Got MppMaker compiled now. Wonder if it will work??

[Mike P 4 MPP]

There's a pair of shelly builds available on the espurna site that might be worth a try https://github.com/xoseperez/espurna/releases.  If they don't work it'd pretty much confirm a hardware problem.  I wonder if some of the shelly's are using the PUYA chips?

[DougC]

Having fired up Espurna on the Shelly, I haven't seen any quirky behaviour so far...

As far as I can tell, this module just sets the relay to follow the switched input. Also it doesn't appear to expose the value of the switched input in a way that AM can see. Only the relay gets found, but that operates fine.  More testing required...

[DougC]

My mistake re how the Espurna module works. Must have been too early in the morning. for me! Toggling the switch input does in fact toggle the relay state. Which I guess is what everyone wants.

[Mike P 4 MPP]

I wonder if the shelly is using that same RAM chip with the SPIFFS problem?  I've just posted 0.5.0 that doesn't use SPIFFS, might be worth a try.  Properties will be lost so back them up first.

[DougC]

I put 0.5.0 MppMaker on the Shelly. Initially after booting up with  the default Properties I was seeing a flood of sensor interrupts reported on pin 0 (which stopped when I grounded GPIO0) At that time SensorPin was set to null, but I guess that was being interpreted as GPIO0

I set the SensorPin and RelayPin  to 5 and 4 and it came up correctly.

However I still get exactly the same sort of weird behaviours as before.

Occasionally operating the switch input (ie triggering the sensor) will trigger the relay (no follow property is set). 

Occasionally operating the relay causes it to open then close shortly after, as if for a momentary action. (no momentary property is set)

I suspect this is some noise/interference in the system. But curiously the Espurna module didn't suffer the same issues. If I can work out where the ESPerna source code is I'll try to understand what they've done.

On the subject of using ESPerna. I'm finding I can operate the Shelly perfectly from AM. However if I try to operate the relay from AM remote, I get no response.

[Mike P 4 MPP]

That's right SensorPin is required anything pin that's not defined defaults to 0.  Strange about the interrupts on GPIO0 though - that doesn't seem like a good thing - I'd be a little worried it'll put the device into flash mode.

It does sound like inputs might be bouncing.  If can confirm that's the case I can look at de-bouncing them in the firmware (esp if that's what the shelly folks needed to do).

The AM Remote thing is probably that same URL encoding problem - just released an updated beta 16.3.15 that fix.  You'll need to forget and re-discover the espurnas for that.

[DougC]

Thanks Mike. The AM Remote fix works for me.

re the interrupts on GPIO0. It occurs to me that I still had a wire connected to the Shelly GPIO0 that could have been acting as an antenna and picking up interference. Easily tested.