Beiträge von eiche

Ratzebaer

Es ist dir hoffentlich klar, dass deine Vögelversorgung nur dann automatisiert arbeitet, wenn der Shelly Plus 1 eine Verbindung zum Internet hat. Ohne diese fällt deine Automatisierung aus. Das Ganze lässt sich auch autark arbeitend lösen - ohne Alexa-Erfordernis. Und zusätzlich so, dass die Pumpe bei Niedrigwasserstand nicht einmal kurz eingeschaltet wird. Dabei kann die Cloud, Szene und Alexa zusätzlich genutzt werden, falls Bedarf daran besteht.

Wie?

Das beantworte ich erst bei Interesse daran.

Ohne selbst ein solches Problem gehabt zu haben, täte ich

1. die betreffenden Geräte aus der Cloud entfernen,
2. sicherheitshalber eine Weile warten - 1h bis 1Tag,
3. falls dies das Problem noch nicht löst, ein Factory Reset.

Vermutlich kann dieses Vorgehen das Problem lösen. Mehr als eine Vermutung kann ich allerdings nicht beisteuern.

peterpaul1

Wie von apreick empfohlen, gelingt dies mit einem übergeordneten System. Dies empfiehlt sich besonders dann, wenn du bereits ein solches nutzt.

Es ist aber auch möglich, all dies mit einem Shelly Plus Plug S und einem darauf laufenden Skript zu implementieren. Allerdings erfordert solches entweder auf die Anwendung genau zugeschnittenes Skript oder ein gut durchdachtes Skript, welches per Konfiguration auf die gewünschte Anwendung anpassbar ist. Das Zweite ist erheblich aufwändiger zu erstellen, aber flexibler nutzbar. Damit wäre dein Vorhaben ohne zusätzliche Investition in Hardware implementierbar.

Ob per übergeordnetem System oder per Skript - ohne Zeitinvestition gelingt eh nichts.

Da du an deinen beiden Küchengeräten jeweils einen skriptfähigen Shelly nutzt, ließen sich beide per Skripte "intelligenter" machen, als sie ohne Skript sind - incl. Priorisierung und gegenseitigem Sperren. Dass dafür WLAN zwingend erforderlich ist, wird dir sicher bekannt sein. Das "intelligenter" Machen der beiden Plus Plug S ist die ausfallsicherste Lösung, weil diese auch untereinander ohne zusätzliches System kommunizieren können. Eine Cloud basierte Lösung ist technisch immer die schlechteste, aber mitunter die bequemste.

Wenn du keine Programmierkenntnisse hast, sind Skripte nicht zu empfehlen. Allenfalls könnte dann jemand mit genügend Zeitreserve für dich geeignete Skripte erstellen.

Edit:
Die Einwände seitens DIYROLLY sind sehr ernst zu nehmen und sicherheitshalber Tests durchzuführen. Die angegebenen maximalen schaltbaren Stromstärken sind mit großer Vorsicht zu genießen und für reguläre Einsätze auf ca. die Hälfte zu reduzieren - als grobe Richtlinie.

Verständlich.

Zitat

Sonnenauf-/Untergangsschaltung wäre bei Aktionen noch nützlich bezüglich dem Zeitfenster für die Aktionen.

Ich weiß es auch nicht und brauche es bisher nicht. Ich weiß aber, dass ich so etwas mit einem Plus Plug S und einem Skript implementieren könnte.

I would try the following.

Equipment

1. one Shelly Pro 4 PM or
2. two Shelly Plus 2 PM

I would code a script that ensures that only one of the four outputs is switched on at a time. As soon as you want to switch, all outputs can be switched off for safety reasons and then the desired output can be switched on.

I don't know if this can be imlemented without a script.

Edit: After a reboot, all outputs must be configured to “off”.

Edit 2:
I mistakenly saw the 80V connection being used. Of course, three outputs are sufficient.
Compared to the electrically safe series connection of relay outputs ( thgoebel), my script solution uses slightly less energy...

Das Prinzip gefällt mir. Ich habe dein Skript nur überflogen, nicht analysiert. Dazu nur ein kleiner Hinweis.

Du kannst mit einem Skript auskommen, indem du zwei HTTPServer Endpoints in diesem Skript nutzt. Der Rest ist eine Frage der Parametrierungen. Auch ein zusätzlicher HTTP GET Parameter könnte genutzt werden ...

Wenn die Beschriftungen/Beschreibungen im UI sorgfältig und richtig sind ...

Zitat

Bedeutet das jetzt, dass er alle 30 Minuten die Aktion erneut auslöst, wenn die Bedingungen noch erfüllt sind?

ist dies zu erwarten.

Zitat

wie verhält es sich wenn der H&T am Vortag geschalten hat und die Luftfeuchtigkeit über Nacht nicht auf <50% Luftfeuchtigkeit fällt und der Plug S bei Sonnenuntergang abschaltet. Schaltet der H&T dann am Folgetag ab 0900 Uhr die Aktion erneut ein? Wenn nicht, wie lässt sich das programmieren, dass er das tut?

und auch dies zu erwarten.

Frage: Warum testest du solches nicht selbst, was nicht wirklich schwierig ist und nur etwas Zeit kostet?
Dazu kannst du den Entfeuchter für den Test abklemmen und stattdessen eine Lampe oder ähnliches als Signalgeber anschließen. Dann kannst du das Schaltverhalten beobachten. Mit einem übergeordneten System kannst du auch des Schaltverhalten registrieren und vermutlich speichern lassen. Ich täte solches per Node-RED.

Ich nutze zwei Taster in einer anderen Anwendung am Plus AddOn. Ein Taster am digitalen Eingang, den anderen am analogen Eingang. Allerdings nutze ich zur Auswertung ein Skript, welches den analogen Eingang binär interpretiert. Es sollte aber auch ohne Skript gelingen, wobei der analoge Eingang bspw. auf unter U_ref/2 bzw. über U_ref/2 zu prüfen wäre -> Action.

Dafür ist ein zusätzliches RC-Glied erforderlich, siehe bspw. meine "Autarke Heizkreisregelung per Shelly Skript" unter "Mikrotaster am AddOn. Die vom TE genutzten Magnetsensoren sind vermutlich Reed-Schalter, die genauso nutzbar sind wie Taster.

Selbstverständlich kann der Plus Plug S nur das messen, was über seinen Ausgang strömt. Das gelingt mit einem angeschlossenen Verbraucher.

Ob dies auch in der anderen Richtung gelingen kann, also das BKW über den Plus Plug S in dein Netz einspeist, weiß ich nicht. Ich vermute, dass dies gelingt. In jedem Fall muss etwas an den Plus Plug S angeschlossen werden.

Wie sieht denn deine Schaltung aus? Schaltskizze wäre hilfreich.

Zitat

mit einem Doppeltaster und 2 Shelly's bedienen so dass bei einem Klick der entsprechende Rollladen ganz hoch fährt, nochmal klick Stopp, runter analog.

Ich habe dies als einen reinen Eintastenbetrieb verstanden. horkatz Deine Handhabungsbevorzugung nutze ich auch, allerdings mit 4 Tastern und einem Shelly i4 in einer Dose -> WLAN erforderlich. Damit kann ich komfortabel zwei Rollläden manuell steuern. Vielleicht wäre solches auch etwas für Ekkkke .

Aha, dann muss man also die "Auf"- und die "Ab"-Stellung eines solchen Tasters festhalten, solange der Rollladen fahren soll?

Eine solche Handhabung empfinde ich als wenig ergonomisch.

Ekkkke

Mit einem Skript auf einem skriptfähigen Shelly gelingt solches mit jedem beliebigen einfachen Taster, allerdings mit der folgender Einschränkung.

Nach einem Stopp kann per nicht unterschiedenen Drücken (nur push, ohne double push oder long push) nur in einen nächsten Fahrvorgang gewechselt werden. Ich wundere mich immer wieder über die Festlegung auf bestimmte Taster bzw. deren Hersteller. Ein schlichter Doppeltaster aus dem Baumarkt kann hierfür eingesetzt werden, wenn man dafür ein flexibel konfigurierbares Skript einsetzt.

Mein folgendes Skript könnte hierfür bereits geeignet sein. Dieses erstellte ich für ein anderes Forumsmitglied.

// created by eiche, 2024-04-13
// Application for a roller shutter controlled by a single button

// Succ beinhaltet zu einem Schlüssel (key) die Nachfolgemethode als Wert (value)
// Die Struktur jedes Eintrags ist Schlüssel:Wert.
// Weil die Methode nach "stopped" vom letzten Schlüssel abhängt, ist der Wert von "stopped" ein zusammengesetztes Objekt
// bestehend aus zwei Einträgen. Jeder Eintrag beinhaltet als Schlüssel einen möglichen vorherigen Schlüssel.
// Damit ist für diese Anwendung eine hierarchische Struktur aus Einträgen konfigurierbar,
// in welcher jeder Eintrag einen einfachen Wert (einstufig) oder eine Struktur (zweistufig) mit einfachen Werten enthält.
// Diese Konfiguration wird anwendungsgerecht von eventHandler() verarbeitet.
let Succ = {
  "opening":"Cover.Stop",
  "closing":"Cover.Stop",
  "stopped":{"opening":"Cover.Close","closing":"Cover.Open"}, // Nach "stopped" gibt es zwei mögliche Nachfolgemethoden.
  "closed":"Cover.Open",
  "open":"Cover.Close"
};

let last = null, // für das letzte Ereignis (event)
next = null; // für die auf das letzte Ereignis folgende Methode

function eventHandler(e) {
  //print(e.name);
  switch(e.name) {
    case "cover":
      e = e.info.event;
      if(e===undefined) return;
      //print(e);
      if(Succ[e]===undefined) return;
      let s = Succ[e];
      switch(typeof(s)) {
        case "string": next = s; break;
        case "object": next = s[last]; break;
        default: return;
      }
      last = e;  
      print("last: "+last+", next: "+next);
      break;
    case "input": // Diesen Teil habe ich nicht getestet.
      if(typeof(next)==="string")
        Shelly.call(next, {id:0}, function(res, errc, errm) {
          if(errc) print(errc, errm);
        });
      break;
  }
}

Shelly.addEventHandler(eventHandler);

Sunshine57

Dafür steht die RPC Methode "Sys.GetStatus" zur Verfügung. Diese liefert ein Resultat im JSON Format, welches auch die Komponente "uptime" enthält.

Es bleiben folgende Fragen.

1. Womit steuerst du das Hochfahren des Shelly bzw. des geschalteten Geräts.
2. Soll der genannte Shelly ausschließlich zum erfassen der Einschaltdauern genutzt werden? Ich sehe zunächst bei dir keinen anderen Einsatzzweck.
3. Wie lange wird der Shelly typischerweise geschaltet bzw. wie sind die Dauern solcher Schaltzustände.
4. Steuert dein Home Assistant das Ein- und Ausschalten?

Ich nutze als zentrales System ausschließlich Node-RED, womit ich das Gewünschte leicht implementieren könnte, auch ohne den Shelly.
Mit anderen übergeordneten Systemen kenne ich mich nicht hinreichend aus.

Per Skript könnten die Einschaltdauern zielführend allenfalls mit Genauigkeiten in Minuten und einer zusätzlichen Toleranz von ca. 1 Minute gespeichert werden, da er nicht "weiß", wann er ausgeschaltet wird.

Wenn der Shelly kurz vor dem Ausschalten darüber informiert werden kann, können die Einschaltdauern durchaus per Skript ermittelt und persistent auf dem Shelly gespeichert werden, bspw. bestehend aus dem aktuellen Zeitstempel (unixtime) und dem uptime Wert. Selbstverständlich bleibt dabei ein systematischer Fehler von vermutlich ca. -1s. Es bleibt die Frage nach der Sinnhaftigkeit einer solchen Implementation.

Ggf. weitere Möglichkeiten und deren Zweckmäßigkeiten können erst genauer betrachtet werden, wenn du mehr von deinem Projekt preisgibst, auch eine Schaltskizze wäre evtl. nützlich.

Hast du einen Plus Plug S oder einen Plug S (ohne Plus). In #1 schreibst du "+PlugS", im Pfad steht aber "Shelly Plug S".
Ein Plus Plug S kann seinen Access Point trotz Einbindung in's WLAN zur Verfügung halten, ein Plug S nicht.
Im ersten Fall ist es möglich, ihn über seinen AP zu erreichen, nachdem du dein Endgerät mit seinem AP verbunden hast (192.168.33.1).

Zitat

und es gibt keinen AP

Das müsste bedeuten, dass du im Falle eines Plus PLug S dessen AP selbst deaktiviert hast.

Edit:

Unabhängig davon muss sich der (Plus) Plug S durch sehr langes Drücken des kleinen Buttons auf die Werkseinstellungen zurücksetzen lassen. Es hat dabei aber auch schon Probleme gegeben, weil irgendwelche Konfigurationseinträge beibehalten wurden. Zumindest sein AP sollte dann wieder verfügbar sein.

Zitat

Also z.B. 192.168.44.45:0 - und solch ein Port funktioniert nicht.

Wenn du dies ablesen kannst, bist du vermutlich über den AP mit dem Shelly verbunden. Dann solltest du bspw. ein "Factory reset" auslösen und ihn danach neu einrichten können. Vielleicht gelingt stattdessen auch eine Änderung in der Konfiguration.

Simon74

Ich bin nicht sicher, ob dieses hinreichend helfen kann, weil ich es bisher nicht brauchte.

Unter "Cover settings" gibt es "Movement time limits" ¹⁾ und "Idle power thresholds" ²⁾.

¹⁾ Damit wird die maximale Dauer zum öffnen und/oder schließen eingestellt.

²⁾ Damit sollte der Shelly eigenständig feststellen können, wenn der Motor angehalten ist.

Eine kleine, wohlmeinende Thread Kritik - auch mitunter auf andere Threads übertragbar

Im folgenden verwende ich nicht die Zitierfunktion des Forums, markiere aber die Textstellen als Zital mit Quellenangabe. Grund: Ich bereitete dieses Statement in einem Editor vor und zögerte, es zu veröffentlichen.

Das Thema dieses Threads lautet: "Shelly Plus2PM Control Button Mode Script"
Hiermit wird zwar offenbar nach einem Skript bzw., wie im ersten Post zu lesen, nach der Möglichkeit gefragt, etwas per Skript zu lösen.

Dann wird es allerdings speziell:
"Ich würde den Modus gerne auch auf SW2 erweitern. Also, dass beim Tasterdruck auf SW1 oder SW2 zwischen den Modi Open -> Stop -> Close -> Stop gewechselt wird."

Im nachhinein betrachtet war die Intention des TE vermutlich, dies eher als Beispielanwendung anzuführen - s. #23:
"Ja das stimmt, wollte ich einfach nur brücken hätte ich nicht nach einer Script Lösung gefragt"
Auch kann es sein, dass der TE weitere, von ihm hier nicht eröffnete Anwendungsmöglichkeiten sucht.

Die folgende Äußerung aus #1 lässt nicht zwingend das Ziel erkennen, etwas über ein Skript zu erfahren.
"Hat das vielleicht schon jemand umgesetzt oder könnte das vielleicht mittels eines Skriptes umsetzen?"

Mir widerstrebt es nicht, auf die Möglichkeiten eines Skripts einzugehen. Aber andere hier im Forum versuchen, wann immer auch nur halbwegs möglich, eine Skriptlösung als überflüssig oder übertrieben anzusehen. Dann wird allzuoft das Ziel eines TE überaus kritisch hinterfragt. Auch wenn dieses Hinterfragen zielführend sein kann, so nehme ich mitunter wahr, dass es einem TE schwer gemacht wird, trotz alledem im gegebenen Kontext an seinem Ziel festzuhalten. Aus einem solchen Grund können "Belehrungen" bzgl. des TE-Anliegens kontraproduktiv sein.

Ich halte ein Nachfragen zu den Absichten des TE für zielführend, nicht aber eine wiederholende Belehrung über eine, vorsichtig ausgedrückt, Sinnarmut des TE Anliegens. Irgendwann sollte imho das Anliegen eines TE akzeptiert werden und ihm/ihr die Freiheit eines vielleicht fehlgeleiteten Weges selbst überlassen bleiben. Dabei kann es helfen, die eigene Fehlbarkeit in der Betrachtung eines Themas oder von Perspektiven einzuräumen. Ich nehme mich selbstverständlich aus solchen Fehlbarkeiten nicht aus.

Mir gefällt es mehr, wenn ein Post eine gewisse Eigenkreativität erkennen lässt - im Vergleich zu einem schlichten und ausschließlich auf Konsum ausgerichtetem "Wie geht das?".

Ich hoffe, hiermit niemandem zu nahe getreten zu sein und dass meine Absicht als konstruktiv erkennbar ist. Ich bitte darum, vor einer Reaktion diesen Text sorgfältig und wohlmeinend zu lesen.
Auf weiterhin gute (reibungsarme) Zusammenarbeit

Zitat

Das höchste Ziel des TE ist doch, daß es KEINE Unterschiede geben soll. Oder habe ich da etwas falsch verstanden?

Das stimmt. Wenn dies so bleiben sollte, schließe ich mich deiner einfachen Lösung vorbehaltlos an. Mal sehen, wie der TE reagieren wird.

Zitat

Aber wozu der Quatsch?

Solches kannst du dir in Zukunft sparen oder versuche einfach, meine Erklärungen zu verstehen!

Da der TE sich bisher nicht weiter erklärte, bleiben alle Optionen zunächst offen.

Bei Verwendung eines Skripts können bei (a) beide unterschieden werden, was mit (b) nicht gelingen kann.