Beiträge von tophee

Ich schalte seit über einem Jahr meine Warmwasserumwälzpumpe (Grundfos Alpha 2) mit einem Shelly 1, aber jetzt läuft sie nicht mehr und ich habe den Verdacht, dass es womöglich nicht an der Pumpe liegt, sondern am Shelly. Ich habe nämlich gelesen, dass diese Pumpe einen sehr hohen Einschaltstrom haben kann (bis zu 70A für 0.0003 sek). Kann es sein, dass dem Shelly das nicht gefallen hat?

Andererseits hat es, wie gesagt, lange problemlos funktioniert... Sehe jetzt wiederum in einer älteren Facebook diskussion, dass hohe Einschaltströme des Relays "langsam" schädigen können:

Soll ich da jetzt also einen Schütz dazwischen hängen? Grundfos selber empfiehlt, dass man deren Filterkabel mit NTC Widerstand kauft und zusätzlich noch ein Relais. Man darf vermuten, dass das Kabel - wie bei solchem Zubehör üblich - überteuert und schwer zu finden ist. Vielleicht tut es auch ein Relais allein? Oder ein (welcher) Schütz? Was ist der Unterschied?

Edit: OK, nach weiterer Recherche verstehe ich, dass es keinen Sinn macht, nur ein (weiteres) Relais zwischenzuschalten, da der Einschaltstrom ja weiterhin zu hoch wäre. Bleibt also die Frage: Schütz oder NTC Widerstand? Zur Einschaltstrombegrenzung scheint ein NTC Widerstand die Standardlösung zu sein. Aber wieviel Eigenverbrauch hat so ein Ding? Wenn ich das richtig verstehe, funktioniert das ja so, dass sich das Teil erhitzt und damit den Widerstand nach und nach reduziert. Das heißt aber auch, dass es sich iim Betrieb ständig warm hält. Wieviel Strom das wohl kostet?

Zitat von M_XXL

Wie sind denn die Erfahrungen mit Router / Switche / WLAN-AP?

Da ja ich jag gleichzeitig mit dem Wechsel von Unifi zu Omada auch diverse Probleme mit den Shellies hatte bzw. habe, kann ich nicht genau sagen, welche Probleme von den Shellies verursacht sind und welche evtl. von Omada bzw. Unifi, insbesondere weil alle drei Hersteller im "Versuchszeitraum" auch mehrmals ihre Firmware erneuert haben. Mein Eindruck nach ein paar Monaten mit Omada ist aber, dass bei den verbleibenden wenigen Verbindungsproblemen der Fehler bei den Shellies liegt. Was das Leben mit Omada etwas einfacher macht, ist dass ich die betroffenen Shellies bisweilen durch drücken von "Reconnect" im Omada controller wieder verbunden bekomme (also ohne hard reboot). Diese Funktion hatte ich bei Unifi nicht gesehen.

Ansonsten funktioniert das Omada-System einwandfrei. Größter Nachteil. scheint mir zu sein dass es kein mDNS unterstützt (also z.B. kein Bonjour über zwischen den VLANS), weswegen ich immer noch nicht den Nerv hatte meine VLANs einzurichten... Die zweite Schwäche, die mir aufgefallen ist )wo ich aber nicht weiß, ob das andere Systeme besser machen) ist folgendes: ich sehe immer wieder dass Clients nicht mit dem optimalen AP verbunden sind (etwa ein Gerät in der Küche hängt plötzlich am Wohnzimmer AP, mit deutlich schlechterem Signal). Meine Vorstellung nach sollte das System das erkennen, dass client X ein stärkeres signal an AP A hat als an AP B und dann dafür sorgen, dass AP B client X rausschmeißt damit er sich dann (hoffentlich) mit AP A verbindet. Aber ich bin kein Netzwrktechniker. Womöglich findet tatsächlich eine solche Steuerung statt, allerdings nicht nach Signalstärker sondern Traffic, was ja auch Sinn machen würde.

Zitat von tophee

Andererseits weisen sie darauf hin, dass der letzte Schaltvorgang durch "Input", erfolgt ist und sie wollen, dass ich den Shelly auf "Detached" umstelle, ihn also vom Taster entkopple.

Hierzu kommt mir gerade folgender Gedanke: die Quelle dieser feststellung ist ja folgende ausgabe von http://deviceIP/status beim Dimmer 2

"actions_stats":{"skipped":0},"lights":[{"ison":true,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0

und beim Shelly 2.5:

"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"},{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"}]

da steht also jeweils quasi: lights (bzw. relays) ison = true, source = input. Wenn ich das richtig verstehe, dann bedeutet das, dass das Licht jetzt an ist und dass der Grund dafür ein Schaltvorgang am Eingang ist.

Soweit so gut. Nun interpretiert der support das aber so, dass der grund für das An- und Ausschalten am Eingang zu suchen ist und meinen das es sich wahrscheinlich um elektromagnetische Störungen handelt.

Was aber wenn die Firmware so funktioniert, dass hier der letzte "offizielle" Schaltvorgang dokumentiert wird, nicht der letzte faktische Schaltvorgang? In dem Fall dokumentiert diese status-Ausgabe nichts anderes, als dass ich vor dem Aussetzer das Licht am Schalter eingeschaltet habe. Dann geht der Shelly aus unbekannten Gründen aus und rebootet. Außerdem wird der letzte Zustand wieder hergestellt, weil ich das so eingestellt habe, also lights on.

Die Frage ist nun, ob die Firmware diese Einschalten des Lichts wegen "default on = last" in der Statusmitteilung registriert oder ob der status einfach unverändert auf "source = input" bleibt. Ich kann das leider gerade nicht testen, aber wenn "source = input" einen Stromausfall überdauert, dann sagt uns diese status-Mitteilung rein gar nichts über den Grund des Aussetzers.

Wenn nach einem Stromausfall der Status aber auf "source = restore last state" oder sowas steht, dann würde das in der tat bedeuten, dass bei meinen Shellies nach dem reboot ein Schaltvorgang am Eingang registriert wird, der nicht auf das Drücken des Schalters zurückzuführen ist. Ich halte das für sehr unwahrscheinlich, da der Aussetzer i.d.R. Kürzer als eine Sekunde ist aber überprüfen sollte man das.

Oh, je. Wenn das so stimmt, graut mir schon davor, dass dem Shelly-Support zu erklären. Die sind in der Vergangenheit nicht gerade durch logisches Räsonieren aufgefallen...

Here is an update from my side: After iamheretohelp didn't respond to my pings in the private conversation he suggested to move to facebook messenger because that would make it easier for him to have a conversation. So we continued the chat there but it has led to absolutely nothing and he is just as unresponsive as here on the forum.

Hier mal ein kurzes Update von mir. Der Shelly support sträubt sich mal wieder mit der Kraft der absurden kommunikation dagegen irgendwelche (möglichen) Fehler einzugestehen oder auch nur zu untersuchen, geschweige denn defekte Shellys zurückzunehmen.

Ich fasse hier mal die Kommunikation der letzten Wochen zusammen, kann wenn gewünscht aber gerne auch den gesamten Chat-Verlauf posten.

Ich habe also berichtet dass einer meiner Shelly 2.5 sich immer wieder von allein aus und gleich wieder einschaltet. Daraufhin wurde ich gebeten http://deviceIP/status aufzurufen, direkt nachdem der Aussetzer aufgetreten ist. Lustigerweise beobachtete ich den Aussetzer aber zunächst an einem Shelly Dimmer 2. Das hatte ich vorher noch nie bemerkt aber meine Frau, die ihren Homeoffice in dem Zimmer hat, meinte: "Ach was, diese Aussetzer haben wir etwas einmal am Tag."

OK, offenbar ist auch der Dimmer 2 betroffen. Ich ergänze also das Ticket diesbezüglich und schicke das Ergebnis von http://deviceIP/status mit.

Die Antwort vom Shelly-Support:

Zitat

We see 2 things for source of the last actions of the device switching is "source":"input" but also we see that the uptime is 106 seconds that mean before you got this information probably the device got rebooted for some reason.

We are advising you to try with the option - button type - detached just to eliminate the problem with the Input source. That will show us if you have any interference which might cause that problem with the random ON and OFF

Es ist also einerseits wie vermutet, dass der Shelly rebootet. Andererseits weisen sie darauf hin, dass der letzte Schaltvorgang durch "Input", erfolgt ist und sie wollen, dass ich den Shelly auf "Detached" umstelle, ihn also vom Taster entkopple.

Das kann ich leider nicht, da der Schalter ständig gebraucht wird. Ich schlage statt dessen vor, dass wir zwei Fragen nachgehen:

1. Warum hat der Shelly rebootet? (meine Hypothese: lost connectivity, was ja bekanntlich bei vielen shelly's immer wieder auftritt

2. Warum hat der reboot offenbar dazu geführt dass das Licht an und aus geht (Hypothese: firmware bug)

Der support meint, dass es möglich ist, dass der Shelly wegen Verbindungsproblemen rebootet, betont aber, dass in dem Fall das Licht nicht geschaltet werden würde. Dahingegen werde das Lich aus und wieder an geschaltet, wenn der Shelly aus anderen Gründen rebootet (und Power-on default auf ON steht). Ich gehe davon aus, dass dies auch gilt wenn Power-on default auf "LAST" steht und das Licht gerade an ist.

Einige Zeit später habe ich den Aussetzer dann auch beim Shelly 2.5 beobachten können und schickte also die Ausgabe von http://deviceIP/status and den Support.

Der support stellt fast, dass der Auslöser des Befehls wieder "INPUT" war, also der Lichtschalter. Sie Vermuten, dass das Problem auf elektromagnetische Störungen zurückzuführen ist und Fragen wie lange die Leitung zwischen dem Schalter und dem Leuchtmittel ist.

Ich schätze dass es im einem Fall vielleicht 6 im anderen 2 meter sind und Frage was sie aus dieser Information schließen und wie das Problem gelöst werden könne. Beide Fragen blieben unbeantwortet. Statt dessen fragen sie, ob ich das Problem durch Verändern der Leitungslänge lösen konnte.

Ich sage, dass ich nichts verändert habe und die Leitungslänge auch gar nicht verändern kann und sie sagen mir erneut, ich solle den Shelly auf "detached" stellen, um elektromagnetische Störungen ausschließen zu können.

Ich wiederhole, dass dies leider nicht möglich ist und stelle fest, dass es sich bei den beiden Shellys wohl um fehlerhafte Exemplare handelt, keiner meiner anderen Shellys diese Aussetzer hat.

Shelly support behauptet schlicht "The units are not faulty" und will, dass ich die beiden gegen andere austausche, Wenn das Problem weiterhin besteht (wovon sie offenbar felsenfest ausgehen) muss es ihnen zufolge an elektromagnetischen Störungen liegen.

Ich lasse mich gerne darauf ein, diesen Test zu machen, aber nur, wenn sie mir die defekten Teile ersetzen falls sich zeigen sollte, dass das Problem mit dem Austausch behoben ist. Mal sehen, was sie sagen, aber ich mache mir keine großen Hoffnungen.

Das ist wirklich ein Saftladen sondergleichen. Ich vermute, denen gehen allmählich die EU-Subventionen aus und sie versuchen alles, um den Laden am Laufen zu halten, nur nicht durch Qualitätsverbesserung.

Ich habe ja noch ein anderes Ticket bei denen am Laufen, das noch um einiges absurder gelaufen ist. In dem Fall hat sich vor einiger der CEO von Alterco höchstpersönlich eingeschaltet und versprochen, sich der Sache anzunehmen. Er antwortete auch tatsächlich im Forum chat auf meine Mitteilung, aber dann war mehrere Wochen komplette Sendepause, trotz mehrere Erinnerungen. Er ignoriert meine Fragen und Vorschläge völlig und plötzlich meint er ob wir nicht auf Messenger chatten könnten, das sei für ihn praktischer. Wir setzen also den chat dort fort, aber auch dort postet er nur unzusammenhängendes Zeug, das keinen Sinn ergibt. Und Fragen beantwortet er auch dort nicht. Bei so einem Chef wundert es mich nicht, dass der Support so nutzlos ist.

Zitat von StreifenKarl

alle unnötigen Optionen ausgeschaltet

Und welche sind das?

I agree with Schubbie. Earlier in this thread, I have documented extensively what happens when you contact Shelly support in this matter. Please take the time and read through it (I also sent you the ticket ID almost a month ago, so you can look at it directly in your ticket system.

I have not heard back from iamheretohelp since almost three weeks. By now I am starting to consider this behaviour as rude. As busy as he may be, there is always time to write a quick note that you haven't forgotten about the issue and will get back. But he is just silent, despite multiple reminders I sent.

Zitat von iamheretohelp

We are in touch with tophee

No, you are not. You are ignoring tophee.

Zitat von Seven of Nine

Debug Log aktivieren und schauen, woran es liegt

Das lasse ich erstmal bleiben. Hier siehst Du was passiert ist, als ich letzte Woche auf Anweisung von Dimitar das debug log auf meinem Dimmer 2 aktiviert habe:

[media]https://youtu.be/4D5sCbWXL9g[/media]

Dimitar hat sich übrigens seither trotz mehrerer messages nicht mehr gemeldet.

Zitat von smhex

Es besteht offensichtlich ein Zusammenhang mit der Group Rekey Interval Einstellung beim nanoHD. Diese Einstellung habe ich deaktiviert.

Ich will kein spielverderber sein, aber bei TP-Link Omada ist das standardmäßig deaktiviert und ich habe dennoch massenhafte disconnects...

Zitat von Schubbie

Haben deine anderen APs von TP-Link den Zusatz "HD"?

Nein, die beiden "kleinen" APs sind EAP235-Wall (siehe hier: EAP235-Wall | Omada AC1200 Wireless MU-MIMO Gigabit Wall Plate Access Point | TP-Link). Der "große" mit Wifi6 ist einEAP620. (siehe EAP620 HD | AX1800 Wireless Dual Band Ceiling Mount Access Point | TP-Link )

Die Theorie, dass Wifi 6 (d.h. neue, möglicherweise noch nicht vollständig definierte Standards) zumindest ein Teil des Problems sind, ist erstmal gut. Auch dass Ubiquiti angesichts deren Firmwarechaos ein Teil des Problems ist, ist erstmal plausibel. Allerdings kann ich das nicht bestätigen. Ich habe drei APs vom TP-Link Omada system, einer davon ist Wifi6, die anderen nicht und ich habe ständige Verbindungsabbrüche (Shelly 1, Shelly 2.5, Shelly Dimmer 1, Shelly dimmer 2, Shelly Plug).

Mir ist allerdings aufgefallen, dass die disconnects viel häufiger auftreten, seit ich von Unifi (UDM) auf Omada umgestiegen bin und ich glaube, dass dies nicht mit Unifi oder Omada zu tun hat sondern damit dass bei Unifi die DHCP-Lease Zeit standarmäßig auf 24h steht und bei Omada auf zwei Stunden.

Spielt also gerne mal mit dieser Einstellung um zu prüfen, was sich ändert. Wenn es bei längerer Lease Zeit weniger disconnects gibt, dann haben wir das Problem schon relativ deutlich eingegrenzt. Allerdings ist mir nicht ganz klar auf was genau, denn eines spricht dagegen, dass es ein reines DHCP problem ist: auch Shellies mit statischer IP sind ja betroffen.

Wie ich an anderer Stelle beschrieben habe, gibt es noch eine andere Beobachtung, die zur Eingrenzung des Problems beitragen könnte: m.E. gibt es drei unterschiedliche Arten von Disconnects:

Zitat von tophee

1. Shelly ist nicht über das Netzwerk erreichbar und kommuniziert auch nicht mit der Cloud, wird aber vom Netzwerkcontroller (TP-Link Omada, in meinem Fall) als Client mit IP Adresse angezeigt (ist unter dieser aber nicht zu erreichen).

2. Shelly ist nicht über das Netzwerk erreichbar und kommuniziert auch nicht mit der Cloud, wird aber vom Netzwerk-controller als"Client angezeigt", jedoch ohne IP Adresse.

Im Zustand 1 und 2 lässt sich der Shelly meistens zum Verbinden überreden indem ich im Controller auf "Reconnect" klicke. Ich denke, das bewirkt, dass die Verbindung vom Access point beendet wird und der Shelly gleich darauf wieder eine neue Verbindung aufbaut. Dies deutet m.E. darauf hin dass sich der Shelly irgendwo im Prozess des Verbindungsaufbaus aufgehängt hat und in einer Limbozustand verharrt.

3. Shelly ist nicht über das Netzwerk erreichbar und kommuniziert auch nicht mit der Cloud, und wird auch im Controller nicht angezeigt. In diesem Fall hilft nur noch Strom ausschalten um ein reboot auszulösen.

I surely will. Yesterday I tried to create a debug-log that documents what is going on when turning the dimmer on, but I failed because of a major bug in the firmware which makes the dimmer go crazy once you enable debug logging. So I guess they need to fix that first.

Then again, I don't think it is really necessary to produce any logs, at least if what support has previously said is true, namely that the delay is purposely programmed into the firmware...

iamheretohelp , I have sent you a private message on this forum website. Did you see it?

In Anlehnung an den Thread zu Ubiquiti - Informationsaustausch möchte ich hier gerne einen Ort schaffen um sich über das TP-Link Omada SDN System auszutauschen. Ich selbst bin vor kurzem von Ubiquiti Unifi zu TP-Link Omada gewechselt und habe es bislang nicht bereut.

Wenn Interesse an einem Vergleich besteht, kann ich ja bei Gelegenheit mal meine Sicht der Dinge zusammenfassen, aber der aktuelle Anlass för diesen Thread ist eigentlich mehr, dass ich in letzter Zeit massive Verbindungsprobleme mit vieler meiner Shellies habe, ich aber unsicher bin, ob es vielleicht teilweise auch an Omada liegen könnte. Ich glaube nicht, dass es so ist, denn ich hatte ähnliche Probleme auch schon mit Unifi aber ich kann auch nicht ausschließen, dass die (gefühlte) Häufung von Shelly disconnects nicht doch etwas mit Omada zu tun hat. Ich vermute aber, dass die Häufung damit zu tun hat, dass die default lease time bei Omada auf 120 Minuten steht (und bei Unifi war es, glaube ich, ein Tag), sodass die Shellies viel häufiger ihre IP erneuern müssen und in diesem Prozess irgendetwas schief geht. Dagegen spricht wiederum, dass auch mehrere Shellies mit static IP disconnecten...

Positiv mit Omada ist aber auf jeden Fall, dass bei vielen Disconnects kein Strom mehr ausgeschaltet werden muss, sondern ich einfach im Controller auf "Reconnect" klicken kann und damit erst mal für eine Weile Ruhe ist.

Wenn du Erfahrungen mit Omada und Shellies hast, berichte gerne hier!

Hier die neuesten Antworten:

Zitat

Shelly - Technical support posted 12.04.2021 16:03

We do not have a report from our developers yet. You can adjust the transition time if you desire to dim up/down the light faster or slower. But we do not have a report for the 800ms delay yet.

As we stated, you can leave us a feature request and our relevant team will have a look at it.

Zitat

[tophee] posted 12.04.2021 19:08

So are you suggesting that if I submit a feature request instead of a bug-report via you, the developers will respond faster?

Zitat

Shelly - Technical support posted 13.04.2021 11:10

We are trying to explain you something, but you are not understanding us.

Developers are not responding on feature requests, just the suggestions are being discussed if could be implemented.

The delay from switch cannot be removed. That is the last and final statement.

We remain available if you have another questions.

Thank you for your time.

Alles anzeigen

Zu allem Überfluss haben sie das Ticket jetzt auch noch geschlossen, was zur folge hatte, dass durch meine untenstehende Antwort automatisch ein weiteres Ticket erstellt wurde...

Zitat

[tophee] posted 13.04.2021 13:46

Yes, there are obviously some misunderstandings. I am also trying to explain something to you, and you don't seem to understand: you say that the delay occurs when you press and hold in order to determine whether this is a long press or not. But the delay I'm reporting is not when I press and hold but when I short-press. There is no reason for the device to wait after a short press (and you have stated so yourself). So what I'm reporting is not a feature request but a bug, because the device is not working as expected.

You say: after short-press, the light should turn on immediately. But this is not what is happening, so it's a bug, right?

Es ist mir ein völliges Rätsel, warum die Entwickler sich so massiv dagegen sträuben, ihre Firmware zu reparieren. Dass die Leute im Support offenbar nicht verstehen, wie die Firmware funktioniert, mag ja sein. Aber die Entwickler müssten das doch wissen, oder? Mich beschleicht der Verdacht, dass das Anliegen gar nicht an die Entwickler weitergereicht wurde. Wenn das stimmt, liegt bei Alterco leider noch mehr im Argen als bislang vermutet.

Ich wäre wirklich dankbar, wenn jemand mit einem gute Draht zu Dimitar ihn mal auf dieses Problem mit der Einschaltverzögerung aufmerksam machen könnte. Seven of Nine? @Olsche? Admin?

Damit Ihr diesen Thread nicht erst durchlesen müsst, hier das wichtigste in einer Nussschale: Der Dimmer 2 schaltet bei Verwendung des Tasters mit einer knappen Sekunde Verzögerung ein, über die Shelly App gibt es keine Einschaltverzögerung. Soweit ich das auf Basis der teils widersprüchlichen Angaben vom Shelly Support beurteilen kann, ist es wahrscheinlich, dass diese Verzögerung in die Dimmer-2 firmware eingebaut wurde um long-press registrieren zu können. Dabei hat man offenbar den Denkfehler begangen, dass man immer 800 ms wartet, anstatt nur solange der Taster gedrückt gehalten wird.

Das Problem ist Alterco nun seit bald vier Monaten bekannt und hätte längst behoben werden können, aber wenn der Support aus Unkenntnis jegliche Lösung abblockt, können wir noch lange warten.

Ich habe das Zeitfenster zum updaten auf die Beta-version verpasst, bin aber auch von den Verbindungsproblemen mehrer Shellies betroffen (ich glaube, es sind vor allem Shelly Plug und Shelly 2.5 Geräte, die diese Probleme haben).

Ich weiß nicht, ob folgende Beobachtung zur Fehlerfindung beitragen kann, aber erstmal ist die Frage, ob das jemand bestätigen kann:

Mir scheint, es gibt drei unterschiedliche Weisen, auf denen die Shellies offline sein können, alle drei treten bei mir auf und ich glaube auch bei allen Shellies:

1. Shelly ist nicht über das Netzwerk erreichbar und kommuniziert auch nicht mit der Cloud, wird aber vom Netzwerkcontroller (TP-Link Omada, in meinem Fall) als Client mit IP Adresse angezeigt (ist unter dieser aber nicht zu erreichen).

2. Shelly ist nicht über das Netzwerk erreichbar und kommuniziert auch nicht mit der Cloud, wird aber vom Netzwerk-controller als"Client angezeigt", jedoch ohne IP Adresse.

Im Zustand 1 und 2 lässt sich der Shelly meistens zum Verbinden überreden indem ich im Controller auf "Reconnect" klicke. Ich denke, das bewirkt, dass die Verbindung vom Access point beendet wird und der Shelly gleich darauf wieder eine neue Verbindung aufbaut. Dies deutet m.E. darauf hin dass sich der Shelly irgendwo im Prozess des Verbindungsaufbaus aufgehängt hat und in einer Limbozustand verharrt.

3. Shelly ist nicht über das Shelly ist nicht über das Netzwerk erreichbar und kommuniziert auch nicht mit der Cloud, und wird auch im Controller nicht angezeigt. In diesem Fall hilft nur noch Strom ausschalten um ein reboot auszulösen.

Und hier die Fortsetzung (musste das ganze in zwei Posts aufteilen, wegen der Zweichengegrenzung);

Zitat

[Shelly support] posted 31.03.2021 12:38

We said that could be related but not for your case, that why asked you to try with different kind of bulbs.

The difference between button push in order to switch on the lights is related to the waiting time of 800ms as we mention in the previous response. After the light turned ON and while dimming up and down with the Switch the fade rate option is taken in action.

That why we are asking you to adjust the settings and also to check the button debounce in order to find the best settings for your case.

Zitat

[tophee] posted 08.04.2021 09:47

As requested, I changed the transition time from 0 to 1000, and, as expected, the transition from 0% to 100% was slower. And, as expected, there was no change in the delay before the transition starts.

> the waiting time of 800ms as we mention in the previous response.

Which previous response are you referring to? You stated earlier that there is a waiting time of 800 ms in order to determine whether it is a double-press or single press. But then you said "There is no such a thing. Dimmer is waiting 800ms to check for long-press." And then you said: "If you use the device in one button mode and pres once the button (short press) the lights will come ON immediately." In other words: there is not supposed to be any delay after releasing the button. Are you now saying that there is supposed to be a delay of 800ms?

> After the light turned ON and while dimming up and down with the Switch the fade rate option is taken in action.

I believe this is not correct. My understanding is that the fade rate applies to the dimming speed when dimming via press-and-hold.

Did you get a response from the developers regarding the proposed firmware update?

Alles anzeigen

Zitat

[Shelly support] posted 09.04.2021 09:16

The delay as we mentioned is not related to double-press. If you press and hold the button it will count 800ms and after that, it will register a long-press and will start dimming. After the start of the dimming, the speed related to the dimming is fade-rate. You can adjust it and check how the device is actin

About your request for the firmware update: Kindly asking you to leave us a request in the following form for Features and device requests.

https://shelly.cloud/support/devices-and-features-requests/

Our representative team will check and have in mind your request in future updates.

Zitat

[tophee] posted 12.04.2021 11:07

Dear *****,

this is not a feature request. The device is not working as it should and from what I understanding you have reported the problem to the developers and are awaiting their reply, right? Could you please let me know what their answer was?

I understand that you said that there is a delay when you press and hold the button because the device needs to wait for the long-press duration before it can register a long-press. I understand that. But what I am reporting is not a delay when pressing and holding, but the delay occurs after the button has been released. You can see it here in this video: Shelly Dimmer 2 delay (no delay when switched via the cloud) - YouTube

Ich bin hier bewusst nicht auf die Frage eingegangen, wie long-press eigentlich funktioniert, denn das lenkt nur wieder vom eigentlichen Problem ab. Aber vielleicht können wir das hier ja mal kurs durchgehen: Falls Shelly-support mit "long-press" das meint, was in der Shelly app mit "Button X long pressed URL" bezeichnet ist (unter I/O URL Actions), dann ergibt das ganze noch weniger Sinn als ohnehin schon. denn zum einen habe ich keinerlei Button Long-Pressed actions programmiert, zum anderen, meint der Support ja, long-press würde dazu führen, dass gedimmt wird solange der Taster gedrückt gehalten wird, und das sticht sich ja mit eventuell programmierten Button Long-Pressed actions.

Mir scheint daher, dass der "Long-press", von dem der Support hier spricht, nicht der "Long-Press" von "Button X long pressed URL" ist, sondern eine weitere Funktion, die man vielleicht als "Very-Long-Press" bezeichnen könnte und die aktiviert wird, wenn man länger als 800 ms drückt und dann auch weiter gedrückt hält. Das funktioniert aber nicht bei meinem Dimmer 2, nur bei meinem Dimmer 1.

Es gibt leider keinerlei Fortschritt zu berichten. Hier die Antwort auf meine obenstehende Nachricht:

Zitat

[Shelly support] posted 25.03.2021 15:39

If that is the case with your device that would means there is some problem with your configuration.

Advise us what kind of bulb you are using? How you have wired them? Did you perform calibration? Send us link to the bulbs.

Some of the bulbs need some time until they power on (warm up time) Also we are advising you to lower the transition time and increase the fade rate.

We will need information on what kind of switches you are using.

Video of the problem will be very helpful for resolving your case.

Could you please provide us with the output of http://deviceip/status and http://deviceip/settings?

On device IP you have to place the actual IP of the unit. For example, if the IP of the device is 192.168.0.100 - you have to write in the browser http://192.168.0.100/status and get the output

Alles anzeigen

Die meisten dieser Fragen hatte ich schon vor Wochen einmal beantwortet, aber es schadet sicher nicht, es nochmal zu tun:

Zitat

[tophee] posted 25.03.2021 18:31

The bulbs cannot be the reason because they turn on immediately when I use the Shelly-App instead of the hardware button.

Yes, the dimmer has been calibrated many times. The most recent one was after the recent firmware upgrade (as reported above).

The transition time is already set to 0 and the fade rate is at 5x.

Are you asking for the hardware switches to which the dimmer is attached? If so, it is this model here: https://www.se.com/se/sv/product/…ch-tryckknappar I am using the same model with the Shelly dimmer 1 (where there is no delay).

A video showing the delay is here: [media]https://www.youtube.com/watch?v=S--jj9r3HzA[/media]

output of http://deviceip/status

Code

{"wifi_sta":{"connected":true,"ssid":"cs","ip":"192.168.1.52","rssi":-57},"cloud":{"enabled":true,"connected":true},"mqtt":{"connected":false},"time":"18:28","unixtime":1616693327,"serial":4,"has_update":false,"mac":"8CAAB54C5424","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"lights":[{"ison":true,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":1}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true, "timestamp":1616696927,"counters":[0.000, 0.000, 0.000],"total":0}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"tmp":{"tC":64.54,"tF":148.18, "is_valid":true},"calibrated":true,"calib_progress":0,"calib_status":0,"calib_running":0,"wire_mode":1,"forced_neutral":false,"overtemperature":false,"loaderror":0,"overpower":false,"debug":0,"update":{"status":"idle","has_update":false,"new_version":"20210323-110201/v1.10.1-gf276b51","old_version":"20210323-110201/v1.10.1-gf276b51"},"ram_total":48224,"ram_free":34636,"fs_size":233681,"fs_free":116966,"uptime":48}

and http://deviceip/settings:

Code

{"device":{"type":"SHDM-2","mac":"8CAAB54C5424","hostname":"shellydimmer2-8CAAB54C5424","num_inputs":2,"num_outputs":1,"num_meters":1},"wifi_ap":{"enabled":false,"ssid":"shellydimmer2-8CAAB54C5424","key":""},"wifi_sta":{"enabled":true,"ssid":"cs","ipv4_method":"static","ip":"192.168.1.52","gw":"192.168.1.1","mask":"255.255.255.0","dns":"192.168.1.1"},"wifi_sta1":{"enabled":true,"ssid":"cs2","ipv4_method":"static","ip":"192.168.1.52","gw":"192.168.1.1","mask":"255.255.255.0","dns":"192.168.1.1"},"ap_roaming":{"enabled":false,"threshold":-70},"mqtt": {"enable":false,"server":"192.168.33.3:1883","user":"","id":"shellydimmer2-8CAAB54C5424","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":true,"keep_alive":60,"max_qos":0,"retain":false,"update_period":30},"coiot": {"enabled":true,"update_period":15,"peer":""},"sntp":{"server":"time.google.com","enabled":true},"login":{"enabled":false,"unprotected":false,"username":"admin"},"pin_code":"NffnpS","name":"Couch lights","fw":"20210323-110201/v1.10.1-gf276b51","factory_reset_from_switch":false,"discoverable":false,"build_info":{"build_id":"20210323-110201/v1.10.1-gf276b51","build_timestamp":"2021-03-23T11:02:01Z","build_version":"1.0"},"cloud":{"enabled":true,"connected":true},"timezone":"Europe/Stockholm","lat":59.405682,"lng":17.947701,"tzautodetect":true,"tz_utc_offset":3600,"tz_dst":false,"tz_dst_auto":true,"time":"18:30","unixtime":1616693408,"led_status_disable":false,"debug_enable":false,"allow_cross_origin":false,"actions":{"active":false,"names":["btn1_on_url","btn1_off_url","btn1_longpush_url","btn1_shortpush_url","btn2_on_url","btn2_off_url","btn2_longpush_url","btn2_shortpush_url","out_on_url","out_off_url"]},"hwinfo":{"hw_revision":"prod-20200629","batch_id":1},"mode":"white","pulse_mode":1,"pulse_mode_detected":1,"pulse_mode_rebooted":0,"load_autodetect":1,"calibrated":true,"transition":0,"fade_rate":5,"min_brightness":0,"zcross_debounce":100,"bypass":false,"lights":[{"name":"","ison":true,"default_state":"last","auto_on":0.00,"auto_off":0.00,"schedule":false,"schedule_rules":[],"btn_type":"dual_button","btn_debounce":60,"swap_inputs":1}],"night_mode":{"enabled":false, "start_time":"00:00", "end_time":"00:00", "brightness":0},"warm_up": {"enabled":0, "brightness":10, "time":200}}

Alles anzeigen

Zitat

[Shelly support] posted 26.03.2021 13:19

Please change the transition time to 1000ms and also increase the fade rate to x5

Zitat

[tophee] posted 26.03.2021 13:35

Why would I want to increase the transition time? We're trying to get the lights to turn on faster, not slower...

The fade rate is already at 5x.

Zitat

[Shelly support] posted 29.03.2021 11:14

The transition time the minimum which you can make is 1000ms that is the fastest which you can make it.

Ich versuche jag wirklich, mich nicht in irrelevanten Fragen aufzuhalten (d.h. nicht auf allen Unsinn einzugehen) aber hier musste ich dann doch nachhaken (hätte ja sein können, dass ich da was falsch verstanden habe):

Zitat

[tophee] posted 29.03.2021 13:58

If 1000 ms is the lowset value, why does the UI allow me to set any value starting from 0?

Zitat

[Shelly support] posted 29.03.2021 15:58

Transition time is visible only when you dimming the light from the webUI or the app while it is on. And the default value is 1000ms because you are not able to see any big difference if it is lower.

The fade rate on the other hand is when you are dimming the lights from the switch.

What if you use a different kinds of bulbs?

Mein Versuch, obenstehende Antwort irgendwie zu verstehen:

Zitat

[tophee] posted 29.03.2021 16:48

If transition time only matter when dimming from the webUI or the app, then I don't understand why you are suggesting I should change it in order to solve the delay that occurs only when pressing the hardware switch and which does not occur when using the webUI or the app.

I do not see how the bulbs make a difference, given that the delay only occurs when using the hardware button and not when using the app.

If you don't have any other solution, may I suggest that you get back to the developers of the firmware and ask them to fix the firmware so that the hardware button works the same way as the software button in the app?

Zitat

[Shelly support] posted 30.03.2021 12:33

We will contact our developers in this regard.

In the meantime, we are advising you to try different bulbs and recalibrate them before doing the test.

Zitat

[tophee] posted 30.03.2021 12:35

Thanks for contacting the developers.

Since you keep advising me to try different bulbs, could you explain to me how changing the bulbs could reduce the delay, given that the current bulbs turn on without delay when I use the Shelly app?

Zitat

[Shelly support] posted 30.03.2021 15:38

Some of the bulbs have a warm-up time which can cause that delay.

Zitat

[tophee] posted 30.03.2021 16:07

And why would the warm-up time cause a delay when the dimmer is switched with the hardware button but not when it is switched via the shelly app?

Zitat

Sadly I don't speak german, but I did try my best to understand what you wrote and I appreciate you communicating with them for us all.

Glad you appreciate it. Since I was the only one posting, it felt like I'm talking to mysel...

I thought it should work to follow the updates in the other thread even without knowing german because the quotes from support are in english anyway and for everything else there is google translate.