Beiträge von eiche

Laut Google Übersetzer

snubber: an electric circuit intended to suppress voltage spikes.

funzel:

Wie du obigen Beiträgen entnehmen kannst, sind vermutlich Spannungsspitzen für den Neustart des Shelly verantwortlich. Sei froh, dass er dann neu startet, es gibt schlimmeres.

Zur Fehlersuche ist das Ausschlussverfahren mitunter ein gutes Mittel.

Hier: Klemme einfach mal den einen und dann den anderen Verbraucher ab und prüfe, ob dann der Shelly auch neu startet!

Der bereits erwähnte RC-Snubber ist zum Schutz gegen Störungen nie verkehrt, in deinem Fall evtl. je einen pro Kanal.

Interessant wäre auch eine Antwort auf die Frage von Muetze.

You can also use an LED with a lower consumption, e.g. 2W or lower or an electronic LED, instead of your lamp to check the desired function of shelly 1.

If the function is ok using this LED, the reason for the problem is your power supply.

Ich bin verwundert.

Ich habe bisher die App als reine Cloud App verstanden und erlebt, die allenfalls das Einbinden von lokalen Shellies in die Cloud unterstützt. Dabei geht bei Shellies der ersten Generation bspw. die MQTT Nutzung verloren. Evtl. geht bei schaltenden Shellies noch das Ein-/Ausschalten, mehr aber nicht.

Ich konnte noch nie diese App brauchbar für nur lokale Shellies nutzen. Habe ich da etwas verpasst?

Nebenbemerkung: Ich brauche für die lokale Nutzung die Shelly App auch nicht, falls sie jedoch Komfort in der Gerätenutzung böte, könnte ich mich dafür interessieren.

Ich kann in solchen Fällen bei Shellies der ersten Generation, wovon du schreibst, die lokale Kommunikation empfehlen und ggf. VPN zu verwenden. Ein Raspberry Pi mit Mosquitto als MQTT Broker unterstützt diese Kommunikation imho verlässlich. Man kann auch HTTP requests einsetzen, mein Ding ist das weniger.

Mit Shellies der zweiten Generation kannst du eh Cloud und MQTT zugleich nutzen. Funzt die Cloud mal nicht, steht immer noch die lokale MQTT Kommunikation zur Verfügung.

Ich halte die lokale Kommunikation für verlässlicher. Insbesondere für einen IT ler sollte es kein Problem sein, einen Raspberry Pi als Server 24/7 zu betreiben.

Ich habe kein IPhone, vermute aber, dass es hierfür auch geeignete MQTT Apps als Mensch Maschine Schnittstelle gibt. Auf meinem Android Smartphone nutze ich gerne MQTT Dash, was es aber afaik nicht für IOS gibt.

Du kannst auf einem o.a. Raspberry auch openHAB oder ähnliche Tools installieren. In diesem Zusammenhang sind auch InfluxDB (Zeitreihendatenbank) und Grafana (Web Anwendung für Grafiken auf Basis von Datenbanken) interessant. Mit Node-RED lässt sich sogar ernsthaft programmieren und bei Bedarf MQTT-Adapter bereitstellen. Auch eine WebGUI kann man damit zusammenstellen, die von modernen Browsern dargestellt wird und auf diese Weise schließlich der Shelly App Paroli bieten kann.

Falls du Linux Shellskripte erstellen kannst, kannst du auch kleinere MQTT basierte Dienste bereitstellen (mosquitto_sub, mosquitto_pub, jq, systemctl).

Mit letzterem ist der Arbeitsaufwand größer als bei Nutzung der Shelly App, dafür gibt es deutlich mehr Flexibilität.

Habe ich genug Werbung für Cloud-Alternativen gemacht?

Zitat

Code

   if (daten.info.event === !"undifined")

Schau dir mal deine Zeile an!

! ist der logische not operator. Das sollte nur gehen, wenn "undefined" ein boolescher Ausdruck wäre - und nicht etwa ein String.

Ein Compiler hätte so etwas nicht übersetzt. Bei einer Interpretersprache ist nicht sicher, wie sich der Interpreter verhält.

Schließlich hast du diese Bedingung ja geeignet codiert.

Es passt auch:

if(daten.info.event!==undefined) ...

Nun, ich habe meine Idee in knapper Form beschrieben.

Voraussetzung ist eh, dass du dich mit dieser kleinen Scriptsprache beschäftigst und wenigstens eine C bzw. C++ ähnliche Sprache kennst.

Auch die Kenntnisse von anonymen Funktionen sowie insbesondere Formalparameter sind fast Voraussetzung.

Andernfalls wird es sehr mühsam für dich, weil du dich dann noch zugleich mit elementaren Programmiertechniken beschäftigen musst.

Programmieren lernen in 5 Tagen geht heutzutage schlicht nicht.

Darf ich fragen, welche Vorkenntnisse/Erfahrungen du diesbezüglich mitbringst?

Prinzip-Idee:

Last (Power) erfassen. Dies gelingt entweder per Eventhandler oder in der callback-Funktion eines fortlaufende Timers per RPC Abfrage (Shelly.call(...)).

Fortlaufender Timer per Timer.set(Periode, true, callback, ...). Parameter true steht für fortlaufend wiederholen, d.h. die callback Funktion wird nach jeder Periode aufgerufen.

Überschreitet die Last die obere Schwelle, einen fortlaufenden Timer starten, dessen callback-Funktion die Perioden zählt. Sobald die Last die untere Schwelle unterschreitet, den Timer löschen. Überschreitet der Periodenzähler einen Zähler-Endwert, Timer löschen, den Kanal abschalten und Nachricht senden.

Dies ist eine Art Watchdog, der mit Unterschreitung der unteren Schwelle schlafen gelegt wird. Er wird mir Überschreitung der oberen Schwelle geweckt, bellt aber erst, wenn die max. Dauer der Überlast überschritten wird.

Evtl. ist für diesen Zweck eine größere Timer-callback-Funktion zweckmäßig. Globale Variable werden erforderlich sein. Die Parameter sollten bspw. per MQTT einstellbar sein, damit der Anwender dafür nicht im Script Änderungen vornehmen muss. Am besten wäre es, wenn Konfigurationseinträge des Kanals oder Gerätes verwenbar wären, weil diese afaik im NVS (non volatile storage) abgelegt werden.

Die Hysterese obere Schwelle - untere Schwelle ist mitentscheidend für die Eignung des Algorithmus.

Tja, da gibt es etwas zu programmieren, wenn du das so implementieren willst.

Viel Erfolg!

Zitat von Schubbie

... das Licht schnell eingeschaltet werden können.

Das ist wohl wahr. Wenn dies die höchste Priorität besitzt, ist imho allerdings das Anliegen von FIZZY ohne zusätzlichen Installationsaufwand (Schalter an für Kinder kaum zugänglichen Stelle) nicht zu befriedigen.

Und selbst eine solche zusätzliche Installation ist vermutlich von einem Kind sehr schnell benutzbar, wenn es dem Kind wichtig ist.

Somit widerspricht eine Erschwernis für ein Kind der Prämisse, Licht schnell, und damit leicht, schalten zu können.

Das vermute ich auch. Ich schließe aber eine gewisse Mitwirkung meinerseits nicht aus, abhängig von dessen Rahmenbedingungen.

Zum Ausgangsanliegen, DIYROLLY und MIHO:

Ebendrum täte ich einen Shelly Plus 1 und Skripte favorisieren und nicht solche Speziallösungen per Hardware.

Mit Skripten lässt sich zumeist viel flexibler das Gewünschte implementieren. Auch erwarte ich, dass die zu Grunde liegende Firmware weiter verbessert wird und es evtl. zusätzliche Abfrageparameter und Skript-Funktionen geben wird.

Wenn ein Plus verbaut ist, lässt sich auch per Skript von einem PC aus das Verhalten des Plus erheblich ändern, ohne die Hardware wechseln zu müssen.

Allerdings sind hierzu Programmierkenntnisse erforderlich. Ein Skript kann aber auch von einem Dritten bereitgestellt werden.

Es ist relativ leicht, eine automatisierte, zeitabhängige Ignoranz des Lichtschalters bzw. -tasters per Smartphone (temporär) zu aktivieren oder zu deaktivieren, jedenfalls per MQTT.

Auch deshalb fragte ich FIZZY, womit er/sie den betreffenden Shelly steuert. Entscheidend sind dann die verwendeten Steuerungs-Nachrichten.

Es ist auch bspw. möglich, das Licht nachts ausschließlich per Smartphone einschalten zu können. Vielleicht würde dies für eine Weile helfen.

Meine Empfehlung ist vielleicht nicht so ganz schnell implementierbar, aber sie ist mittel- und langfristig für verschiedenste Zwecke nutzbar.

MIHO: Afaik bist du in der QA Gruppe oder hast einen Draht dorthin. Ich hätte da noch Mängel an der Plus Firmware 0.10.1 anzumerken. Es wäre schön, wenn du das vermitteln könntest.

Zitat von eiche

Es wird alle 60 Minuten eingeschaltet, der Einschalt-Timer ist auf 900s gestellt.

Unter "WENN" steht "ZEITSCHALTUHR" und darunter "Intervall: 60 Minuten".

Unter "MACHEN" steht der Gerätename und darunter "Einschalten das Gerät".

Dass die Szene noch zu aktivieren ist, muss ich dir wohl nicht erklären.

24/7 ist voreingestellt, d.h. die Szene arbeitet an jedem Wochentag von 00:00 bis 23:59.

Noch einmal der Hinweis:

Solange der Shelly nicht mit der Cloud verbunden ist, funktioniert das (temporär) nicht.

Für eine höhere Funktionssicherheit wäre bspw. Tasmota zu flashen und mit dessen Rules zu arbeiten oder ein Shelly Plus 1 mit einem Script zu bevorzugen.

Es gibt auch Spezis, die gerne mal zwei Shellies miteinander koppeln. Das ginge hier auch mit zwei Shelly 1. Shelly A schaltet den SW-Eingang von Shelly B und B schaltet den SW-Eingang von A. Dazu wären die Timer und die Schalter- bzw. Tasterarten passend einzustellen.

Zwischenbericht zur Szenensteuerung 15 Min ein, 45 Min aus.

Die ersten 5 Ein-Aus-Schaltvorgänge waren erfolgreich. Nur der erste war nur 42 Min aus, was vermutlich an meinem manuellen Anstoßen des ersten Einschaltens innerhalb der Szene liegt. Ich kenne mich in Szenen nicht aus, brauche solche auch bisher nicht.

Das Protokoll zeigt ansonsten eine präzise Abfolge der gewünschten Schaltsequenzen. Es wird alle 60 Minuten eingeschaltet, der Einschalt-Timer ist auf 900s gestellt.

Ich würde mich wundern, wenn sich ein Shelly 1 anders verhielte.

Ich suchte und fand soeben, dass ich dies naheliegenderweise auch in der Cloud protokolliert finde, nur nicht so gut dokumentiert wie in meinem Protokoll.

zombo42 : An Hand des Cloud Protokolls kannst du immerhin selbst die Funktionstüchtigkeit eines Szenen gesteuerten Ablaufs überprüfen, ohne dich selbst mit einer Protokollierung zu befassen.

Wenn mir gespeicherte Daten wichtig sind, dann vertraue ich nicht auf eine Cloud. Außerdem gibt es noch Nicht-Shelly Mikrocontrollerboards.

Dann lasse ich die Daten lokal auf einem selbst eingerichteten Raspberry Pi speichern und mir auch per Grafana darstellen.

Der Nachteil ist, dass ich mich damit befassen muss - und anfangs auch "durchärgern" musste.

Der Vorteil ist, dass ich die Erfassung, die Speicherung und die grafische Darstellung genau so gestalten kann, wie ich das möchte.

Ich nutze für Aufzeichnungen und Grafiken einen Raspberry Pi 4 mit Mosquitto, Node-RED, InfluxDB und Grafana.

Dazu braucht es nicht zwingend eine Cloud, aber zweckmäßigerweise MQTT.

Szene bedeutet afaik Steuerung per Cloud. Na ja, dann arbeitet der Shelly nicht wie gewünscht, wenn die Cloudverbindung weg ist. Mein Ding wäre das nicht. Aber wie du willst.

Mit einem Shelly Plus 1 ließe sich so etwas per Script implementieren, was auch alleinstehend funktioniert.

Ich habe soeben mal meine erste Szene mit einem Plus 1 getestet, 1 Min ein, 1 Min aus - ohne Script. Das geht.

Ich werde das gleich mal mit 15 Min und 45 Min testen, incl. Protokollierung per Script.

Mal sehen ...

Die Mühe, dies mit einem Shelly 1 zu testen, werde ich mir jetzt nicht machen.

Ist der Shelly in ein WLAN als Client eingebunden oder ist er alleinstehend, bietet sich also als Accesspoint an?

Im ersten Fall muss der Gast einen WLAN-Zugriff haben, im zweiten Fall muss er sein Gerät mit dem WLAN des Shelly verbinden.

Das sind die Voraussetzungen, dass überhaupt das Gewünschte funktionieren kann.

Die Bedenken wurden bereits geäußert.

Es könnte hilfreich sein, wenn du nicht nur die Antwort/Fehlermeldung postest sondern insbesondere auch die von dir abgeschickte Nachricht bzw. den URL.

Das hat bereits @Muetze festgestellt.

Falls du noch Shellies in der Schublade liegen hast, sind die bereits aufgeführten Hinweise reizvoll.

Bevor du versuchst, weitere Shellies dazuzuschalten, bedenke andere Ideen! Sie basieren nicht auf Verdrahtung und purer Konfiguration sondern auf Software.

Du könntest betreffende Shelly 1 durch Shelly Plus 1 ersetzen, also solche der zweiten Generation. Diese lassen sich in ihren Funktionen sehr flexibel durch Scripte erweitern. Damit ist es bspw. möglich, die lokale Uhrzeit abzufragen und abhängig von dieser Zeit

1. den Shelly automatisiert spezifisch zu konfigurieren oder
2. die Betätigung des Schalters/Tasters wirksam oder unwirksam werden zu lassen

Ich kann gelegentlich gerne hierfür ein Script erstellen.

Besonders flexibel wird das Ganze mit MQTT. Dann kann man die "Nachtzeit" nach Bedarf per Smartphone einstellen und die Nachtszene mal eben deaktivieren bzw. aktivieren.

Man kann die Cloud verwenden, man braucht sie aber nicht zwingend. Beim Einsatz eines solchen Scripts braucht man nicht zwingend MQTT, es geht auch alleinstehend.

Für deinen Einsatzzweck würde ich dir einen Shelly Plus 1 mehr empfehlen als einen Schelly 2(.5). Die zweite Generation ist zukunftssicherer, weil auf Dauer vielseitiger einsetzbar.

Eine andere Möglichkeit mit Shelly 1, wieder mit MQTT, besteht darin, das Einschalten zu erfassen und beim Einschalten per MQTT sofort wieder auszuschalten.

Für MQTT braucht man aber so etwas wie einen Raspberry Pi. Dieser kann 24/7 arbeiten und Dienste zur Verfügung stellen. Damit geht sehr viel. Evtl. können auch die fertigen IoT Anwendungen wie ioBroker, openHAB ... so etwas. Solche können auch auf einem Raspberry Pi arbeiten.

Schließlich kann man auch Tasmota auf den Shelly 1 flashen und dessen Funktion per Rules erweitern.

Ein ersetzter Shelly 1 kann bspw. per Addon als Messstation für Temperatur und Luftfeuchtigkeit weiter verwendet werden.

Frage Fizzy : Womit steuerst du deine Shelly 1 außer mit angeschlossenen Schaltern?

Am AP sollte es nicht liegen, weil ...

Zitat von Placebo2210

--> Ich habe sogar extra einen Shelly 1 daneben geklemmt, der genau das gleiche schalten simuliert, der geht nie offline

Ich habe mit 12V Hutschienen-Netzteilen (wohl zumeist für LED Beleuchtung eingesetzt) als Shelly Versorgung und zum schalten von 12V Magnetventilen erhebliche Störprobleme gehabt. Schließlich funzten die Teile dauerhaft, als ich einen Abstand von ca. 30 cm zwischen Trafo und Shelly einhielt.

Vielleicht liegt hier ein ähnliches Problem vor. Nicht alle meine Trafos stören den zugeordneten Shelly 1 in gleichem Maße. Ob dies am Trafo oder eher am Shelly liegt, habe ich nicht weiter untersucht.

Das mag ja sein. Ich wäre aber dann nicht überrascht, wenn der Shelly 3 em zwischenzeitlich keine WLAN-Verbindung hat. Und eine kleine zusätzliche Abschirmung per metallenem Gegenstand kann in solcher Umgebung bereits die Verbindung entscheidend stören. So gesehen erscheint mir weder die Entwicklung des 3em ohne LAN sowie dessen Nutzung hinter Metall - hust - nicht sehr professionell.