If anyone is interested... I had a reply to my official Shelly support ticket and they have said they've sent the issue to their developers and they will fix this bug as soon as possible.
Beiträge von caravanboy
-
-
Hi,
I have four new Shelly Motion devices that I intend to use with Home Assistant.
I first upgraded the firmware from version from 1.0.3 to v2.0.3 (the latest).
I then enabled CoIoT and set a unicast address 192.168.1.x:5683
This worked fine and my Shelly Motion works correctly with Home Assistant.
I do NOT have Cloud or MQTT enabled.
HOWEVER - I think there is a definite bug in the Shelly Motion firmware. If I tell the Shelly Motion to reboot (from its browser page) OR if I turn the Shelly Motion off and on again, then the CoIoT settings are blank.
I have tried this several times now and after any reboot (or power cycle) the CoIoT settings are lost.
Has anyone else seen this issue? Is there any known work around, or do I have to wait for a new firmware update?
-
Frage: betreibst du die Shelly 1PM mit dem Addon für Temperaturmessung?
Damit bin ich nämlich am Verzweifeln und deine Probleme ähneln sehr stark meinen Problemen.
Apoloigies, ich benutze Google, um auf Deutsch zu schreiben ...
Ich habe eine Shelly 1 mit Temperaturzusatz und ähnlichen Problemen wie Sie und das Originalplakat. Ich bin überzeugt, dass die Temperatur-Add-Ons viele zeitweise auftretende Netzwerkprobleme und / oder Neustarts verursachen.
Ich habe 3 Shellys aus verschiedenen Chargen (und verschiedenen Firmware) mit jeweils Temperatur-Add-Ons - alle haben das gleiche Problem.
Wenn ich "ping -t <shelly IP>" mache, sehe ich ungefähr alle 5 Sekunden eine lange Antwortzeit und auch regelmäßige Zeitüberschreitungen.
Alle meine Shellys ohne Temperaturzusätze pingen perfekt.
-
I use Shelly4Hass in Home Assistant (via HACS) and the latest version just works as-is and auto-discovers all of my Shelly devices with native Shelly firmwares. I did briefly have to use MQTT for the Shelly Button 1's but that was fixed in a recent release
-
The two existing Shelly 1's that I now know exhibit the same issue are on 1.9.0 (+two temperature sensors) and 1.9.4 (one sensor). The newer one is on 1.10.1. All three behave the same - some sort of very significant slowdown inside the Shelly approximately ever 5 seconds, which is presumably what causes the intermittent slowness in responses to any external activity (whether that is pings, the device's Web UI, or Home Assistant)
-
Hi, I have lots of Shelly 1 devices in my network and all ping fine (~4-5ms response). When recently installing a newer Shelly with temperature module add-on (with a single DS18B20 connected, and latest 1.10.1 firmware) I noticed occasional slow response (e.g. when clicking the on/off button on the local web UI, or when clicking buttons in Home Assistant).
To investigate I was pinging the new Shelly 1 and I noticed regular ping timeouts (e.g. sometimes as often as every 5 or 10 seconds) and I noticed that when it does respond, every 5th response is slow at 250-600ms.
I have two other Shellys with temperature add-ons too and I've just tested pinging those and surprisingly I see exactly the same behaviour (i.e. every 5th ping is very slow), although the timeouts are slightly less frequent, maybe only 3-4 times per minute on those, but they are on older firmware.
So, this seems to be a bug/fault with the temperature add-on that is causing the Shelly to become briefly unresponsive.
Has anyone else noticed this? I know from experimenting with Arduinos that there are various ways of retrieving the temperature from DS18B20's that take longer if you want more accuracy. Perhaps the implementation inside Shelly needs fixing?
I will probably try and report this as an issue on the Shelly support site but would be good to see if any of you can do a simple ping -t test and see what you get
-
It depends how the lights in your wall switches are wired. Are they a simple neon connected to the switch, or are the lights fed back via a separate wire from some sort of existing central system?
Assuming they are powered locally inside the switch then they may continue to work (BUT, beware that I've found toady that connecting any sort of live 'load' to a Shelly SW input can cause it to think the switch is on even when it is off, as current flows back from the Shelly's SW towards the load).
If they do work then they will only show you the status of the local switch, they will NOT show you the status of the device connected the Shelly as that may be different to the switch. The SW input does not change to provide feedback if the shelly is remotely switched on through the app.
-
Maybe this diagram will explain what I plan to do - the coloured lines are the extras for my two PIRs.
Basically the Shelly is just providing an additional manual remote override to the PIR.
My question is, will the red wires (which may become LIVE if the PIR detects movement) cause any problem being connected to O1 or O2 if the Shelly believes the lamp should be off?
Any comments appreciated.Shelly2.5 With PIRs.jpg
-
I'm not sure what you are trying to achieve now with the 'flip'?
If you want to trigger the Shelly1 via the SW input then I think I am concluding (from my own experiments) that SW can be connected ONLY to LIVE, it cannot have any loads also connected to it because the 'SW' is floating in some way and if you have a load such as a lamp, then when the lamp is off then a low voltage current flows out from Shelly's SW, through the load to the neutral (on the other side of the load) and thus makes the Shelly1 think that it's input SW is already switched on.
-
I came to the forum tonight to look into an issue I had today but it sounds very similar to yours - essentially that you cannot also have a switched 'load' connected to the Shelly1 SW input.
I had an existing bathroom light that I did NOT want to automate, but when the light was switched on I wanted a new bathroom heater to also be turned on (by the Shelly 1's relay). So, I split the switched-live so that it was still connected to the existing LED lights and ALSO to the Shelly 1 SW. However, no matter what I did with the wall switch the Shelly1 input indicator still showed that it was on. This meant that I could only control the heater from the app, not from the wall switch.
As a test, with nothing connected to the Shelly's SW input I measured the voltage between SW and N and found that it was ~33 Volts AC.
I'm not sure what the solution will be for you but in my case I've now got to re-think my plans as I cannot simply connect my lights to the Shelly output as the heater will be programmed to potentially switch off sooner than the lights - the only need to go off when the wall switch goes off.
-
Hi, sorry for taking so long to reply to you but I did not get any notification emails. I don't know if you have sorted this now anyway?
I doubt that you can make the SW outputs go LIVE when the Shelly App is activated. You will have to connect O1 directly to M1 and M2 (up) and O2 directly to M1 and M2 (down).
If lack of space is the problem and you cannot get crimp ferrules to work, have you considered soldering the cables as a last resort?
-
I have a PIR with Shelly 1 and I only use the Shelly to override the Switched-Live of the PIR so that I can remotely turn on the light that the PIR is connected to. This works okay since the shelly 1 is a dry-relay output.
I now plan to use a Shelly 2.5 to apply similar control to 2 other PIRs - each channel of the Shelly 2.5 will control override one PIR switched-live.
So, my question is, is it safe to do the same as I did with the Shelly 1, or will the Shelly 2.5 get damaged/upset if O1 or O2 are made live by the PIR (i.e. without them being made live by the Shelly 2.5 itself)?
Just in case anyone is wondering... I cannot use the PIR switched-lives to feed the Shelly switch inputs (i.e. and then just connect the lights to O1 and O2) because in my setup the Shelly switch inputs will be used for existing manual wall switches which already manually override the PIR outputs.
Any comments or suggestions welcome
-
It might be clearer if you just show a diagram with only the live connections and remove the blue neutral and green earth (as they don't matter as much).
On diagram 1 you used the brown wires to the shutter for Up and black for Down, I don't know if that is to match the wires inside your switch but in diagram 2 they differ, which is confusing.
Also in diagram 2, I cannot see how that works at all - for example, if you press "UP" then the SW2 is made live ,and so I assume O2 is made live which means Shutter 1 has both UP and DOWN inputs (brown and black) live at the same time.
You mentioned WAGO connectors and not having space... in the UK we have WAGO connectors. I used to use the larger 222 but I recently discovered the 221 range which are a little smaller. Would that help you?