maxonthenet Posted July 8 Share Posted July 8 (edited) Hi everyone, as a newcomer in this forum, I will try my best to match posting guidelines as well as be as informative as I can. I am a very satisfied user of a set of Shelly smart switches, including a versatile Shelly Pro 2. I am writing this post to share an odd behavior of this device, which I have observed multiple times and I am unable to definitely qualify as expected, ascribed to a faulty unit or simply improvable in the design. Scenario Being a 2-relays device, the Shelly Pro 2 drives 2 mostly resistive loads, each consisting of one 220V AC outdoor (garden) LED light requiring less than 20W of power. The Shelly Pro 2 receives as input a phase wire coming downline a single switch (terminal SW1) and a pair of 3-way switches (terminal SW2), all of them already existing before the Shelly had been installed. The phase entering terminals SW1 and SW2 is the same that powers the Shelly Pro 2 and, although irrelevant, is also the same that powers the outdoor lights. The Shelly Pro 2 is meant to be controlled from the local network only using an Ethernet cable, therefore: AP mode is disabled Wi-Fi is also disabled the Ethernet interface is configured with a static IP address Bluetooth is disabled the Shelly Cloud is disabled At the time of writing, the Shelly Pro 2 runs stock firmware release 1.3.3. Issue Description In most cases the Shelly Pro 2 operates perfectly. Aside from integrations with third-party home automation systems, input readings as well as relay operations can be fully and seamlessly controlled from its built-in web interface. Issues arise when a power outage occurs, as in some cases the Shelly Pro 2 simply disappears from the network and is stuck in a non-functional state. As a term of comparison, here is a summary of the normal operational conditions (as a reference, also see the Shelly Pro 2 user guide): Power LED: steady red light (power connected and device ready) Wi-Fi LED: steady red light (not connected) LAN LED: steady green light (connected) Out1 and Out2 LEDS are lit according to the state of the driven lights unit successfully controlled from the local network using all its standard interfaces (web GUI, RPC, etc.) lights controllable both using existing physical switches and by remotely triggering the Shelly Pro 2 relays, according to the configured Input-to-Switch logic set up in the web GUI When the Shelly Pro 2 fails to restart it hangs in the following state: Power LED: steady red light Wi-Fi LED: off LAN LED: off Out1 and Out 2 LEDs: steady red light, and both controlled lights powered on (this is the most annoying behavior) [*] I suspect that the two outputs are turned off after a (possibly long) timespan, but the Shelly Pro 2 never exits the non-functional state anyway unit totally unreachable from the local network no evidence of issues on the network switch it is connected to [*] in at least one case, the MAC address of the Shelly Pro 2 was visible on the switch (it is a managed device, so learned MAC addresses can be accessed), and some traffic originated by the Shelly apparently to an NTP time server was observed, but the Shelly still could not be reached by any kind of traffic (web GUI, RPC, not even ICMP ping) lights stuck in the "ON" state, and no ways to control them, even by using the existing physical switches consider that the Shelly Pro 2 is configured to set both relays to the "OFF" state after a power loss has occurred I have marked with [*] the conditions which I am not able to reproduce or which I am not completely sure to be fully ascribed to the Shelly Pro 2, but which I am fairly confident that have occurred at least once. In the end, the only way to recover the Shelly Pro 2 is to cut and restore its input power. After recovery, all existing configuration settings are retained and the device is again fully operational (possibly until the following power outage). Several test rounds of power cut-and-restore, applied selectively to the Shelly Pro 2 (therefore the Internet provider's router and the subsequent switch are not affected), seem to demonstrate that: the issue occurs roughly 2 times (not necessarily contiguous) over 5 rounds; that is, power cycling the Shelly Pro 2 five times results in it being stuck in the non-functional state at least twice there seems to be no evident correlation between the time for which power is suspended (e.g., 1 second, 5 seconds, 1 minute, etc.) and the likeliness of the issue occurring similarly, there seems to be no evident correlation between the last functional/non-functional state of the Shelly Pro 2 and the state following a power cycle the issue has occurred at least once with an earlier firmware release (although I am not able to tell which one) the likeliness of the issue occurring is unchanged if the Ethernet port speed on the switch is fixed at 100Mbps full duplex (i.e., autonegotiation is disabled) Additional pieces of information: two other Shelly 1 Plus, as well as an additional Shelly Plus 1 Mini devices are operating flawlessly in the same household with similar settings (i.e., no AP, no Bluetooth, no Cloud, just Wi-Fi with a static IP address), even after any power outages as far as I know, the Shelly Pro 2 is never expected to reset to factory defaults as a consequence of special patterns of activation of the external switches or of the power supply, given that it has a dedicated Reset button: therefore, I am pretty confident that explanations like Shelly devices are going in factory reset mode without my intention do not apply at all to the Shelly Pro 2; in addition, the device recovers its normal configuration and operation after a simple (and lucky) power cycle I am fully inclined to ruling out a network-related issue, as all devices in this LAN segment have a statically assigned IP address and, first and foremost, the Shelly Pro 2 just ignores even the status of the physical switches when stuck All in all, for me this is basically unexaplainable. It's just as if the Shelly Pro 2 randomly failed to inizialize altogether. Of course, it is also very inconvenient because outages may occur at night and power cycling the Shelly Pro 2 is hardly attainable given that the household where it is installed is somewhat distant from the place where I spend most of the week (after all, this is one of the main use cases for remotely controlled switches). Any suggestions are welcome. So far I am not very keen on attempting an RMA, because the Shelly Pro 2 indeed operates perfectly unless the dreaded outage occurs, so it more likely seems a software/design issue to me. Links A small collection of potentially relevant references follows, although none of them has ever fully addressed this specific issue: This post in the ShellyUSA Reddit community documents issues in reconnecting to Wi-Fi after a power outage; differently from this case, I am not using Wi-Fi at all and the issue is definitely not related to the Internet being unavailable for a while after the power outage ends, because connectivity was continuously available during all the power cut-and-restore rounds I have attempted with the Shelly Pro 2. This other post in the ShellyUSA Reddit community deals with a stuck device which is lost from the cloud but can still be recovered by issuing a reboot command over the local network: I am not using the cloud at all, and the Shelly Pro 2 is completely unresponsive on the network whenever stuck (aside from its MAC address being sometimes visible due to traffic it autonomously originates). Finally, this post in the same ShellyUSA Reddit community documents an issue which is apparently very close to the one I am experiencing, but again Wi-Fi is involved and ultimately the solution is to fix subnet masks in the local network. This post in the homeassistant Reddit community deals with the target switch status after a power loss, but this is more a matter of the expected switch operation, which can be configured according to the user's needs; remember that my Shelly Pro 2 is configured to set both switches to the "OFF" state after a power loss. Also this Github issue seems potentially related but, again, for that case the problem lied in Wi-Fi coverage. This post mentions generic Shelly devices failing to reconnect after a power outage but nobody ever followed up. Thank you very much for reading so far. Edited July 8 by maxonthenet Quote Translate Revert translation? English (American) Finnish French German Italian Portuguese (European) Spanish Link to comment Share on other sites More sharing options...
maxonthenet Posted July 10 Author Share Posted July 10 Here is the outcome of a few additional attempts: Resetting the Shelly Pro 2 to factory defaults, and reconfiguring it soon after with the same parameters described in the previous post does not eliminate the issue. There is no evidence at all of internal relays "sticking" as documented in this post, because of at least 4 reasons: the load cannot be excessive (1 LED light on each line) when starting in the faulty state, a distinct "click" sound can be heard when each of the two internal relays turns the corresponding output on, therefore the mechanical parts of the relays are free to move without any interference both relays are always involved when the fault occurs, with no exceptions, making it very unlikely that they are affected by the same "disturbance" none of the devices installed close to the Shelly Pro 2 is known to emit relevant magnetic fields; by the way, the Shelly is mounted on a DIN rail inside an electrical panel on a separate row with respect to circuit breakers Although this is barely perceived, there might be a slight difference in terms of startup time between the case of a successful startup and a failed one: usually, when the startup of the Shelly Pro 2 takes slightly longer than about 3-5 seconds, the relays are turned on and the device enters the stuck condition; the feeling is just as if initialization of any network services timed out and, therefore, this permanent error condition is triggered. But, indeed, it may just be a feeling after all. Quote Translate Revert translation? English (American) Finnish French German Italian Portuguese (European) Spanish Link to comment Share on other sites More sharing options...
donez Posted September 5 Share Posted September 5 Hello @maxonthenet, I have same issue, exatly the same. Did you solved it in any way? The strange thing is that other Pro2 not have the same issue after the power outage. Did you proceed with an RMA? I ask just in case I have your device (via Amazon) XD. Thx. Quote Translate Revert translation? English (American) Finnish French German Italian Portuguese (European) Spanish Link to comment Share on other sites More sharing options...
klim Posted September 16 Share Posted September 16 I have exactly the same problem. I have 3x Pro2 and one of them stuck(freeze) after power outage. How to fix? Please help. Quote Translate Revert translation? English (American) Finnish French German Italian Portuguese (European) Spanish Link to comment Share on other sites More sharing options...
Shelly Olsche Posted September 16 Shelly Share Posted September 16 If we want to look for similarities, at best we should note special settings so that it can be reproduced: Summary: -WiFi/AP/Bluetooth disabled -LAN connected and static IP? please add... Quote Translate Revert translation? English (American) Finnish French German Italian Portuguese (European) Spanish Link to comment Share on other sites More sharing options...
maxonthenet Posted September 22 Author Share Posted September 22 During the timespan since my last post I have contacted the Shelly support service asking for help in troubleshooting this issue. They have been very responsive and, after a few verification steps, agreed on granting an RMA (@donez, to address your concern, the device ID of my faulty Shelly Pro 2 was 30C6F78A1EC8 😊). I have installed the replacement Shelly Pro 2 in exactly the very same operational conditions as the (supposedly) faulty one, including: same electrical panel in the same position same power line same configuration Maybe the operation history of this brand new unit is still too short but, until now, "artificially" power cycling the new Shelly Pro 2 never triggered the failure: now I am again a very happy Shelly Pro 2 user: Shelly support has been great! 👍 Interestingly, the replaced/old/faulty unit seemed to behave fairly better after a few weeks being off-grid: triggering the "stuck" state by power cycle patterns had become very hard, to the point that this unit almost seemed to have "self healed". Of course I didn't feel confident at all about relying on it again. At the above considered, likeliness that the replaced/old/faulty unit was affected by a hardware malfunction increases, although it is quite unclear to me what the actual cause could have been. In fact: since, after being moved away from the electrical panel, the replaced/old/faulty unit was behaving "better", it could have been a matter of environmental conditions, but: the brand new unit is operating perfectly in exactly the same conditions described in my original report in the same room where the electrical panel of the Shelly Pro 2 is located, there is also a Shelly Plus 1 (although located in a different compartment), which has never had any issues temperature conditions are not so extreme (yes, it may get somewhat warm during summer time, but nothing that approaches the extreme conditions described here and, at the time of my report, the replaced/old/faulty unit displayed the issue even when transferred in a supposedly "cold" room) humidity is also not expected to reach higher levels than those where other Shelly 1 units are operating correctly (one of them even continued to work despite a very unfortunate water infiltration in an outdoor watertight box) it could also be due to strain of the internal voltage transformer, but then this would hardly explain the improved behavior along time Hoping that the brand new Shelly Pro 2 never exhibits the problem again, it just seems to have been caused by a possibly faulty unit. @Olsche, to also help direct your more than correct attempt to find common factors across reports, in my case the configuration did not matter at all: even resetting the replaced/old/faulty unit to factory defaults caused it to equally misbehave. The common ground might be more likely to be sought after in hardware-level factors (e.g., purchase period - mine was purchased on February 2024, but the supplier might have built his stock earlier - hardware revision - which I am not sure how to check -, etc.). Quote Translate Revert translation? English (American) Finnish French German Italian Portuguese (European) Spanish Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.