Beiträge von eiche

steffda

redrooster will damit sagen, dass du bitte mal prüfen solltest, ob das Auslösen des Schaltens von der Cloud kommt. Vielleicht ist eine andere Quelle dafür verantwortlich, die mit dem aufgeführten RPC erfasst werden kann.

Der Aufruf lautet: http://<IP Adresse>/rpc/shelly.getstatus

Die Antwort zeigt u.a. die Quelle des letzten Schaltens an.

Ein Teil dieser Antwort lautet bei mir wie folgt.

  "switch:0": {
    "id": 0,
    "source": "init",
    "output": false
    }

Daran ist erkennbar, dass der aktuelle Ausgangszustand aus (false) ist und die Quelle des Ausschaltens ein Reboot (init) war.

Wenn die Quelle des Schaltens die Cloud war, muss bei dir bspw. stehen:

  "switch:0": {
    "id": 0,
    "source": "SHC",
    "output": true
    }

Erst wenn dies der Fall ist, ist sichergestellt, dass die Nachricht aus der Cloud kam und vermutlich die von dir gelöschte Szene dafür verantwortlich ist.

Ich habe mich zwar daran gewöhnt, aber störend finde auch ich, dass auf dem WebUI immer dieses Aktualisierungssymbol auftaucht. Dann schaue ich nach der Firmwareversion und sehe, dass ich dieses Symbol ignorieren soll. Das ist alles andere als ein Abschluss seitens Shelly.

SebDob_ Fotografiere bitte deine Anordnung mit den vielen Shelly, welche den Pumpen-Shelly zum schalten beauftragen! Vielleicht gibt deren Anordnung etwas Aufschluss.

Zitat von eiche

Demnach sendet das H&T Gen 3 vermutlich zu anderen Zeiten, also nicht synchron. Wenn du die Zeiten der Wertänderungen bzw. des Sendens zusätzlich irgendwie erfasst, sollte sich ein nichtsynchrones Verhalten feststellen lassen.

Übliche Umgebungstemperaturen verändern sich zumeist langsamer als es die Luftfeuchtigkeit tut. Das schwächt imho nicht meine Vermutung des zeitversetzten Aktualisierens. Wenn keine anderen Informationen über den Kommunikationsablauf vorliegen (ich habe jedenfalls keine solche), dann täte ich das Zeitverhalten versuchen zu analysieren. D.h. die Zeitstempel der jeweiligen Nachrichten (MQTT) und die der Anzeigewerte (Cloud?) könnten wenigstens meine Vermutung stärken/schwächen. Ich erfasse MQTT Zeitstempel via Node-RED Flow. Ich kenne deine Möglichkeiten nicht.

Hierbei wären auch die Zeitabstände der MQTT Nachrichten für den Anfang interessant.

steffda

Allgemein betrachtet, ohne vertiefte Cloud Kenntnisse, sind solche Einträge sicherlich in einer Datenbank gespeichert. Es liegt nahe, dass der dbzgl. Datenbankeintrag weder als inaktiv markiert noch entfernt wurde. Nicht selten werden solche DB Fehler via serverbasiertem, zeitgesteuertem Programm (Skript) mindestens einmal täglich bereinigt. Dafür muss

1. die Datenbank dafür entworfen worden sein und
2. ein solches Programm Inkonsistenten finden können, um diese zu beseitigen.

Ob beide Bedingungen hier erfüllt sind, weiß ich nicht und vermute, dass dies hier niemand weiß.

Somit ist das Problem ein Fall für den Support <- Ticket.

Zu meiner Skriptplanung in #5

Es ist auch möglich, statt dem dort vorausgesetzten, unveränderbaren Puls:Pause Verhältnis von 1:1 ein allgemeines zu implementieren, wenn bspw. nur kurze Ausschaltdauern genutzt werden sollen. Dies erfordert eine filigranere Anwendung von mehreren Timern und eine tiefere Verschachtelung von Funktionsaufrufen. Eine solche Implementation täte ich als Ausbaustufe vorsehen, wenn die Anwendung nach Planung in #5 bereits fehlerfrei funktioniert.

Aha, danke tvbshelly. Da weiß ich nun noch sicherer als zuvor, warum ich die Cloud für solche Zwecke nicht nutze.

Zitat von xlarge

Has this unit connecton to ethernet? And I am not looking for an AP in the Shelly 1PM but how to give the unit wifi connection.

No, it doesn't. My solution works largely independently without such a connection. Only a short connection (via the smartphone or anything else) is required to transfer all the stored values.

Zitat von Randy069

Zur Info ich habe noch eine Szene hinterlegt die alle Rollläden zu einer bestimmten Zeit hoch bzw. runter fahren lässt.

Kann das damit zusammen hängen?

Du hast eine Schwachstelle meines Skripts zur Wirkung gebracht. Ja, das hängt damit zusammen, weil das Skript (noch) keine externen Steuerungen erfasst bzw. erfassen kann. Hierfür wäre es zu erweitern und im Rollladen-Shelly Aktionen zu konfigurieren, welche das Skript auf dem i4 benachrichtigen. Vielleicht werde ich demnächst die Muße finden, dies zu implementieren.

Worin besteht denn das Problem. Ein Wechselrichter speist doch ausschließlich in das Hausnetz ein. Eine umgekehrte Stromflußrichtung gibt es nicht oder dürfte im mA Bereich liegen. Ok, die Cloud (grässlich) mag invertiert anzeigen, aber der Mensch kann dies doch interpretieren, oder?

Merkwürdig!

Die Anzeige im Display schätze ich als aktuell ein (Cloud/App nicht zwingend).

Demnach sendet das H&T Gen 3 vermutlich zu anderen Zeiten, also nicht synchron. Wenn du die Zeiten der Wertänderungen bzw. des Sendens zusätzlich irgendwie erfasst, sollte sich ein nichtsynchrones Verhalten feststellen lassen.

Die ganz andere Blink-Alternative via zweier Schedule Jobs und Aktionen (s. #4) besitzt den kleinen Nachteil des uhrzeitbezogenen/uptimebezogenen synchronen Sekundentaktes. Weil ein Benutzer aber nicht sekundensynchron Licht schaltet, führt dies zu kleineren, zufälligen Verzögerungen beim abschließenden Blinken.

Für solche, die gerne konfigurieren und denen Skripte ein Gräuel sind, ist dieser Weg sicher lieber. Das Skript zu #5 kommt ohne schreiben in den nichtflüchtigen Speicher aus, die Schedule-Konfigurationslösung hingegen nicht.

Teilst du uns noch deine Lösung mit?

christian24395

Es gibt eine recht gute API Dokumentation zu den Shelly.

Shelly Skripte werden ereignisgesteuert abgearbeitet. Hierfür sind am besten sog. EventHandler geeignet - s.a. den Link zur Skripteinführung in meiner Signatur. Ein solcher EventHandler muss dem Betriebssystem mitgeteilt werden, damit dieser in die Ereignismitteilung einbezogen wird. Ein solcher EventHandler ist eine Funktion in einem Skript.

Für dein Anliegen will ich zunächst die Lösungsidee umreißen. Es gibt verschiedene alternative Wege der Implementation deines Wunsches. Ich erläutere hier zunächst nur die (fast) reine Skriptlösung, weil sie letztlich am einfachsten ist, wenn das Skript irgendwann vorliegt.

1. Der im System registrierte EventHandler empfängt vom System ein Objekt als Parameter, welches er selektiv verarbeitet. Das hier interessierende Ereignis ist das Ausschalten des Shelly Ausgang oder beide Ausgangs-Schaltvorgänge.
2. Es können u.a. zwei alternative Wege zur Implementation genutzt werden.
   1. Mit konfiguriertem Einschalttimer, der automatisch nach einer eingestellten Dauer ausschaltet.
   2. Mit Einschaltdauer per Timer Objekt, wobei der skriptinterne Timer nach einer Dauer eine callback Funktion aufruft, die den Ausgang ausschaltet.
3. Beide Wege sind gleichwertig, die beiden Skripte unterscheiden sich nur geringfügig. Ich setze zunächst Variante 1 voraus. Hier braucht der EventHandler ausschließlich das Ausschalten des Ausgangs zu verarbeiten.
4. Das Skript beinhaltet im einfachsten Fall eine Konstante "Blinks", die die Blinkanzahl beinhaltet, bspw. 3, und eine Konstante "Period", welche die Periodendauer des Blinkens beinhaltet, bspw. 1000ms.
5. Sobald das Licht ausgeschaltet wird, wird
   1. eine Variable "Count" mit 2 * Blinks, z.B. 6, initialisiert und
   2. ein skriptinterner periodisch arbeitender Timer gestartet, dessen callback Funktion den Ausgang umschaltet (toggle), welche ich entsprechend "toggle()" nenne. Der erste Parameter des gestarteten Timers ergibt sich aus Period / 2, z.B. 500ms.
6. toggle() schaltet den Ausgang schlicht um und zählt Count herunter.
7. Sobald Count den Wert 0 erreicht, wird der Timer gestoppt, was zur Beendigung des Blinkens führt. Der letzte Zustand ist "Aus".

Das Blinken wird somit an das temporäre Einschalten des Lichts angehängt. Blinkfrequenz und -anzahl sind frei im Skript per Konstanten konfigurierbar.

Diese Liste stellt die Planung des Skripts dar. Das Coden folgt später, derzeit bin ich wegen Krankenhausaufenthaltes etwas verhindert.

Bei Fragen bitte den entsprechenden Punkt in obiger Liste aufführen!

Solches gelingt, vermutlich ausschließlich, per Skript. Wenn du dich darauf einlassen willst, können wir darüber reden.

Eine Lösung mit Aktionen und zwei Schedule Jobs (Zeitpläne) könnte möglich sein, ist aber eher ein Krampf.

Dir sollte klar sein, dass mit diesem Blinken die Leuchtmittel schneller altern.

Da zeigt sich der Vorteil von MQTT. Wenn Werte via MQTT übertragen werden, spielt ausschließlich das Topic eine Rolle und keine MAC Adresse. Auch die Nutzung von IP Adressen wäre dafür förderlich. Kann man in HomeAssistant nicht bspw. MQTT nutzen. Dann braucht ein ausgewechseltes Gerät nur dasselbe Topic zu verwenden. Ich kenne mich mit diesen fertigen Systemen nicht aus, weiß aber, dass HomeMatic MQTT nutzen kann, zumindest das eingebettete Node-RED, was dann RedMatic genannt wird.

Offenbar geht es um die Speicherung der Werte, die mit dem neuen Gerät schlicht fortgesetzt werden soll. Dazu brauchen doch nur die Werte in derselben Datenbank-Messreihe abgelegt zu werden. Oder habe ich da etwas falsch verstanden?

Ich kann solches wegen Abwesenheit von zu Hause nicht testen.

Meine Vermutung geht in Richtung Funkwellen, die vom Backofen weitgehend abgeschirmt werden. Das kann folgende Wirkungen haben - solches kann ich mangels Ausstattung nicht messen. Ob diese Vermutung realistisch ist, mögen andere beurteilen.

1. Der Shelly erhöht wegen der schlechteren Verbindung seine Sendeleistung, was ihn erwärmt.
2. Die reflektierten Funkwellen heizen den Shelly zusätzlich etwas auf.

Bringe gelegentlich einen empfangenden Shelly dicht vor den Backofen (Glastür?). Wird der BLU dann auch so warm?

Das meinte ich in #7 Punkt 2. Das Relais des Shelly 1 in Reihe zum (externen) Wall Display Relais kann vom DS18B20 gesteuert die Heizung abschalten.

Vielleicht wird das Deaktivieren/Entfernen von Szenen nur ein- oder zweimal täglich durchgeführt, aber sofort entsprechend markiert. Ich bin kein Cloud/Szenen Spezi und will es auch nicht werden.

It's too expensive.