Beiträge von jdwhite

Anything changed for you in the last 6 hours? Both browser and command line show a valid cert for shelly-api-docs.shelly.cloud and shelly.cloud:

shelly-api-docs.shelly.cloud has address 91.92.139.35

$ openssl s_client -servername shelly-api-docs.shelly.cloud -connect shelly-api-docs.shelly.cloud:443 | openssl x509 -noout -text -certopt no_pubkey,no_sigdump,no_extensions,no_header,no_version,no_serial -ext subjectAltName

Signature Algorithm: sha256WithRSAEncryption

Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA

Validity

Not Before: Nov 15 00:00:00 2021 GMT

Not After : Dec 15 23:59:59 2022 GMT

Subject: CN = *.shelly.cloud

X509v3 Subject Alternative Name:

DNS:*.shelly.cloud, DNS:shelly.cloud

-Jason

Can you elaborate on "fried"? Botched firmware update? Connected to AC when jumpered for DC?

Note: i've got four of the EMs, not 3EMs, but I'd think (possibly naively) that they would work similarly.

To clarify, are you seeing entities to select in the Energy configuration screen and not sure which ones to pick or you're not seeing any at all? Or something else?

For what it's worth, I'm using the native Shelly integration (not MQTT) and I've made sure that I've enabled "ColoT" under Internet & Security -> ADVANCED - DEVELOPER SETTINGS and for "ColoT peer" I make sure I put in the IP address of my hass server (port will auto-fill) so its using unicast.

You may have better luck:

• on the Home Assistant Discord #energy channel.
• on the Home Assistant Community forums.

Just a quick note that curl's --connect-timeout option can take decimal values for sub-second timeouts.

I had a particularly problematic switch which only made it to AP mode about one in 10 times I energized it and despite seeing its SSID appear I wasn't able to successfully send the configuration request before it locked up. I changed the timeout to .5 and finally got it on the next time the SSID appeared, so I think the shorter timeout helped.

Zitat

Clearly these devices have some software problems that don't inspire confidence.

Indeed. Having purchased 15 of these and having them be unusable with stock Shelly firmware due to random hangs/going offline and random momentary power cycles I decided to try the Tasmota firmware. I'm happy to report that in the three days since I started using Tasmota, all 10 of the switches I have in production have been 100% solid. Tasmota also gives you the ability to calibrate the units to a known accurate voltage/current/power settings, which is really nice.

From what I can tell in my experience, I/O are isolated from N-/L+/SW. Keep in mind what whatever hot/+ voltage you power the shelly with, part of that is present on SW (measure yourself between SW and N verus L and N). If what you're using to switch has voltage present, you're better off using an isolated relay that will switch a dry contact on/off and connect the dry contact side to the shelly.

I've used the RIBU1C in several projects involving the Shelly1 (with the switch type in "disconnected" mode) where I needed to detect the closing of a circuit where voltage was present since it provides an electrically isolated switch that I can connect to the shelly SW/N(-) when voltage is present.

I and O are open/closed based on how you've configured the behavior of SW, so in your example it will always show on because the switch is always on. The shelly1can't tell you whether the circuit connected to I/O is closed or power is flowing -- you'd need a 1P, EM, etc. for that.

If you want to detect circuit closure with the shelly1 then it has to go through the SW contact with the switch configured for "disconnected" mode so the state of SW no longer controls I/O. However, the L/+ (hot) wire also feeds the SW input on the shelly1 (which is connected to -/N to close the switch), so whatever is connected from SW to ground has to be able to handle the voltage supplied by +/L.

In your application, your switch is introducing 24VDC, so not a good choice. There is a way to make your application work with the shelly1 but requires an additional component: an electrically isolated relay such as this one I've used in several projects:

https://www.functionaldevices.com/products/build…details/RIBU1C/

Essentially you would take your 24V switched circuit and wire it into the DC (10-30V) and Common on the relay's inputs and the N/O (normally open) and (C)ommon side (dry contact in this case) to +/L and SW on your shelly switch. This way, when your 24V switch is closed the relay will close the dry contact side, and the shelly1 will display input/0 as "1". When the 24V switch is opened, the relay opens the dry contact side and shelly1 will display input/0 as "0". You can power the shelly with AC or DC as long as it's within the tolerances of the RIBU1C (or relay of your choice), which is the nice thing about using a relay like this as you can mix AC/DC/voltages because the RIBU1C isolates each side.

I've used RIBU1Cs and shelly1s in disconnected mode to control and monitor my garage doors.

I/O is used to toggle the door into opening/closing (I have the shelly automatically turn it off after 1 second to simulate a momentary button press when triggered) while the SW/- inputs are connected to a reed switch that's normally closed (NC) when the garage door is closed. I also power my shellies in this application with 12V DC which the reed switches can handle (again, because the L/+ voltage on the shelly is routed "out" through the SW to ground).

Good luck.

-Jason

I received my two replacement shellyplugus' today. Same behavior on Apple equipment. Had a Windows10 laptop. No joy with that either. This is kind of insane. Only thing that works for me is using a Raspberry Pi 4 running Linux.

I wrote a script to aid in configuring these plugs to client mode.

while : ; do
  curl --connect-timeout 1 \
    'http://192.168.33.1/settings/sta?enabled=1&ssid=YOUR_WIFI_SSID&key=YOUR_WIFI_PASSWORD&ipv4_method=dhcp'
  [ $? = 0 ] && break
done

You'll need to replace the strings YOUR_WIFI_SSID and YOUR_WIFI_PASSWORD accordingly. Be sure to "url encode" any special characters (e.x. "my passwd" => "my%20passwd"). These are the settings of you existing WiFi network you want to configure the shellyplug to use.

I used the following procedure to more quickly configure my plugs for client mode without a browser.

Start with the plug powered off/deenergized.

Procedure:

1. Start the above script in a dedicated terminal/shell. Every second you should see an error message from curl such as "curl: (28) Connection timed out after 1000 milliseconds". This is normal. Curl only waits one second for a connection. If no connection was made, curl exits and the script loops and starts curl again. The goal is to send the configuration request as soon as the shellyplug enters AP mode -- and before it locks up. The script will exit if curl was successful in sending the config request to the shellyplug.
2. Configure the WiFi on your Linux machine to associate to the SSID of the shelly you're trying to configure. The SSID of the plug is 'shellyplugu1-XXXXXX' where XXXXXX is a hexadecimal identifier of the SSID your plug uses. There is no password.
3. Turn on/energize the shelly plug.

If you're successful you'll see something like the following:

[...]
curl: (28) Connection timed out after 1001 milliseconds
curl: (28) Connection timed out after 1001 milliseconds
curl: (28) Connection timed out after 1001 milliseconds
{"enabled":true,"ssid":"YOUR_WIFI_SSID","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null}

Else you'll just keep seeing the "connection timed out" messages.

Like before you may have to power cycle the plug several times before it even goes into Access Point mode.

Although not tested, there's no reason this script shouldn't on any system with a Bourne compatible shell and curl. The whole point is to rapidly hammer requests to the shelly so as soon as you can associate to its WiFi and get an address that the configuration request is sent before it wedges.

Good luck!

-Jason

Suggest you open a support ticket. They're very reasonable and responsive. Just keep in mind that they're working out of the EU (Bulgaria, perhaps?) so if you're in the States like me you'll typically get replies overnight. Nice to wake up to.

Regarding my two original units, I finally got the third one to pair long enough to get it in to client mode, but the fourth I had to get warranty replaced (which is done with a coupon code for the store -- you get to keep the broken unit(s)).

Fast forward to last week -- this probably deserves a thread of its own. Received 8 more plugs. I'll preface all this by saying that I typicall work in a Mac ecosystem (desktop/laptop/tablet/phone). So I unbox all 8 of these units and NONE of them will pair. Same bahavior as before: see, the AP but when try to connect the plug freezes up. I try my desktop, laptop, iPad, phone....nothing mac works.

At this point I'm pretty sure that all 8 units aren't defective, so I boot up a RPi4 running Linux, configure WiFi and right away I get an address, connect to it with the RPi and configure for client mode. So, something mac is doing with WiFi is incompatible with the plugs? Because I've configured many other models of Shellies (1, 1P, 2.5, EM, RGB2, DW2, i3) with my Macs and NEVER had this issue. For me, this is entirely unique to the shellyplugus1.

I continue with the other shellyplugs and I eventyally get 6 out of 8 confugured. Of the remaining 5 I configured with LInux it often took multiple power cycles before I could associate with the AP long enough to configure for client mode, so while LInux eventually got the job done it wasn't problem-free.

Two of the 8 new ones failed. With these units, 90% of the time you'll get a brief red/blue blip at power on and then either no LED or LED will blink blue for a bit and go solid blue -- at which point they're wedged. I contacted support, provided them a video of my troubleshooting, and got a coupon code for two replacements the next day..

I do not think that Allterco Robotics is the OEM for the shellyplugus units in the same way they are for other shellies I've purchased. I've seen pictures of a unit that's the spitting image of a shellyplugus but is not Shelly branded. The lack of convenient headers is another indication that these may not be Allterco OEM -- but just guessing.

I did take one of the broken ones apart and if you desolder the hot and neutral plugs, on the back by where the board with the ESP8266 attaches there are two solder pads labelled TX and RX. I was going to see if I could re-flash these units, but none of the other pins are labelled, so I don't know which pin GPIO0 is (have to ground it momentarily as part of the flashing procedure). I'm going to try using the button to see if maybe that's linked to GPIO0. Otherwise it's trial and error. Will post if I come up with anything. Even if I do it's kind of a pain getting to the non-component side of the board.

-Jason

I have two brand new Shellymotion sensors, arrived today. Configured both for client AP mode and updated both of them to firmware v1.1.2. Next thing I did was enter a user/pass under RESTRICT LOGIN. As soon as I saved, by browser prompted me for a password (normal) but as soon as I entered my credentials and hit return the device seemed to freeze (red light on solid for a couple seconds) then appeared to reboot -- eventually see it cycle through all colors. This happened with both sensors.

Waited a few seconds for them to reboot, and again, access them with a web browser but before I can even be prompted for credentials the unit reboots again.

I was able to reset (hold for 10 seconds), reconfig for client AP mode, etc. They're working now, but I don't like not having restricted logins.

I did downgrade one of the sensors to v1.1.0 and was able to save a user/pass successfully without having the unit go into a reset loop. I then updated that sensor back to v1.1.2 and now it's in a reboot loop.

1) cycles through green/blue (purple?)/red for a few seconds.

2) blinks green 2-3 times.

3) red light on solid for ~5 seconds, then off.

4) 10-15 second with no indicators, then the cycle.

Marking as resolved. Didn't see a way to mark an already-saved posting as resolved.

I'd wondered if there was a physical change in the i3 design that was reflected in the PDF download version. I looked for a document version number on the PDF and on my my paper copy that that came with my i3, but couldn't find one on either.

Hello.

I ran into an inconsistency with the i3 user guide that I downloaded from the shelly.cloud knowledge base: https://shelly.cloud/documents/user_guide/shelly_i3.pdf

In the downloaded document, the DC wiring diagram has a couple issues. I discovered them while trying to hook up some switches today while referring to the downloaded user's guide and it wasn't working properly.

I'm going to open a ticket to report this, but currently the ticketing system is unavailable.

FYI,

-Jason

I recently purchased a set of 4 shellyplug US (shellyplugu1) switches. Using my laptop, I paired two of them them same way I've paired numerous other shelly switches -- energize, select the SSID of the device, bring up 192.168.33.1 in browser, enter my WiFi credentials in the client mode config screen and save.

The other two have been a complete pain to set up. I have spent hours trying to get connected to these other two plugs. I've performed the factory reset numerous times (energize, press and hold switch button for 10 seconds and the red/blue LEDs are blinking) but hasn't helped.

Here's the procedure I've been following:

1. energize (plug in) the shelly plug.
2. blue LED starts blinking slowly.
3. Select shellyplugu1-XXXXXX from list of WiFi networks and attempt connection.

At this point one of two things happens:

• the blue led will go out (no red LED either)
• --OR--
• the blue led will stay on solid (and no red LED)

In either case no WiFi connection is made and the push button is no longer responsive. I believe the unit is in some sort of wedged state at this point. Within 45-60 seconds the unit seems to reset and the blue led will start slow blinking again as if it'd been newly energized.

Every so often I can get connected to the shellyplug, but only for a few seconds -- not long enough to perform any configuration.

I've opened a trouble ticket with Shelly support, but after sending them a video of me trying to connect to these plugs I haven't heard anything in several days so I thought I'd try here.

I let the two problematic plugs sit for a few days. Today I decided to try again and I managed to get connected to one of them and configure client access mode. In that case I'd pressed the button once so that the red and blue LEDs were slow blinking and was able to connect. I tried to repeat this same procedure with the second problematic plug but no luck.

Part of what's confusing here is the documentation says the unit is in AP mode if both red and blue LEDs are blinking, but my own experience would indicate that one can typically only connect in AP mode if just the blue LED is slow blinking. This reddit thread also indicates that the documentation is suspect and slow blue blink mode is the AP connection mode.

I've run out of new things to try so I'm going to unplug and let this sit a few days and try again.

Regards,

-Jason