Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Xenon]

@Ente sagte in [Vorl.]Gerätezustandsüberw.+Benachrichtigung bei Start/Ende:

@Xenon

Danke für Dein Replay.

Folgendes Testszenario:

An einer Tasmota-Steckdose hängt mein PC. Später soll die Waschmaschine verwendet werden, leider ist derzeit keine Wäsche geplant.

Also, die Steckdose zeigt x-Watt an. Dann fahre ich den PC runter und schalte alle Standby-Geräte via Schalter am Verteiler (da ich immer noch 3 Watt ziehe) aus. Nun dachte ich, wenn dann die
Steckdose 0 Watt zieht, dass das Skript das erkennt und mir die Nachricht via Alexa sagt, dass das Gerät fertig ist.

Vermutlich habe ich einen Denkfehler.

Ja, da hast du leider einen Denkfehler. Das Script erfasst deine Geräte wenn sie starten. Erst ab diesem Moment läuft das Script. Sollte Durchschnittsverbrauch (dieser wird berechnet) einen bestimmten Wert unterschreiten, so sagt das Script "Gerät fertig" und schaltet, wenn denn gewünscht, die Steckdose auch aus.
Du kannst das Script aber für deinen PC nutzen, das tue ich auch. Du legst dir deine Datenpunkte für den Computer an und stellst "autoOff = true", dann schaltet das Script deine Steckdose aus, kurz nachdem der Computer runtergefahren wurde.

Anbei das Alexa-Gerät:

Muss noch ein anderer Alexa-Adapter für die Sprachausgabe installiert werden?

bei Alexa kann ich dir nicht helfen, da ich keine im Einsatz habe aber @Ankh_Morpork weiß da bestimmt einen Rat. Aber ich würde sagen, du gibst erstmal die richtigen Datenpunkte für deine Steckdosen, stellst autoOff = true und dann schauen wir mal weiter, bis jetzt lief dein Script nämlich nicht, da der Trigger der Verbrauch und eben nicht der Zustand der Steckdose ist

[fila612]

@Xenon
Muss denn das automatische abschalten auf True stehen um Nachrichten zu erhalten?
Ich habe heute meinen Trockner und meine WaMa in das Script eingebunden.
Beide hängen an einem Shelly plugS.
Dieser dient nur zur Übermittlung des Verbrauches und für die benachrichtigen wenn die Geräte fertig sind.
Die Shellys bleiben aber immer an.
Problem bei mir heute:
Ich erhalte eine startnachricht, aber leider keine mehr wenn die Geräte aus bzw fertig sind.

Ich find das Script super, allein schon wegen den Möglichkeiten je gerät eigene Nachrichten zu verfassen.
Mein eigenes blockly läuft zwar, jedoch habe ich es nicht geschafft die fertigmeldung des Trockners auf einmal zu reduzieren.
Daher probiere ich gern dieses Script, aber leider funktioniert es noch nicht so.
Achja, der DP der Geräte steht immer noch auf „in Betrieb“.
Über Tipps wäre ich dankbar.
Viele Grüße
Lars

[Xenon]

@fila612 ich glaube es gibt da ein Problem beim Plug S. Hatte ich auch schon in der Facebook Gruppe gelesen. Kann es sein, dass der Shelly auf 0 Watt abfällt und dann nicht mehr sendet? Wie oft aktualisiert sich der Wert? Das script triggert auf "aktualisiert"

[Xenon]

kurze info:

Als nächstes implementiere ich 3D-Drucker. Hier wird es einen Cooldown Timer geben, den man selber einstellen kann, damit nach erreichen des Status "fertig" noch eine Abkühlphase durch die Lüfter erfolgen kann. Ebenfalls kommt dann im gleichen Update "Sayit" mit rein ..

[da_Woody]

@Xenon gerade nachgeschaut value.power wird aktualisiert und fällt, bei mir zumindest, zwar auf 0W, (eigenverbrauch) dann teilweise auf 0,4W
bei eingeschaltenem shelly plug-s

[Xenon]

@da_Woody ich verstehe nicht, wieso die Leute nur mit shelly Ärger haben. Gosund, homematic, usw laufen alle ohne Probleme. Ich hab die Dinger nicht im Einsatz, kann es leider also nicht nachstellen. Ich weiß auch ehrlich gesagt nicht, wo ich da ansetzen soll...

[fila612]

@Xenon
Hmm, der Shelly zeigt dann 0 Watt an, ob er das dann weiter sendet und in welchen Abständen weiß ich nicht.
Rein logisch müsste er es weiter senden, da in der App ja immer 0 Watt angezeigt wird.
Die WaMa bei mir schaltet sich am Ende komplett aus (0 Watt), der Trockner ist noch ne ganze Weile im Knitterschutz, daher schwanken dann die Verbrauchswerte.
Ich habe ein wenig im Script gespielt und den letzten der 4 Werte stark nach unten angepasst, jetzt kommt zumindest eine Meldung, aber stark verzögert.
In den Datenpunkten steht auch z.b. nach Ende des Waschprogramms 0 Watt, jedoch unverändert „im Betrieb“.
Es hat den Anschein das der Wechsel auf Standby nicht klappen will.

[Xenon]

@fila612 die Frage ist, wie oft kommen die Werte beim shelly? Anpassen kann man natürlich immer, aber die Werte sind aus längerer Testphase ermittelt und funktionieren überall, außer beim shelly. Also muss es am intervall liegen, also wie oft die Werte neu oder aktualisiert reinkommen

[fila612]

@Xenon
Verstehe, aber ich weiß grad nicht wie ich das prüfen kann.

[Xenon]

@fila612 also bei tasmota und 10 Sekunden intervall entsprechen 50 Aufzeichnungen 500 Sekunden, dh wenn du 50 Werte im Script aufzeichnest, kann es BIS ZU 500 Sekunden dauern, bis die Maschine als fertig erkannt wird. Sendet dein shelly bei Aktualisierung nur alle 30 sekunden, dann dauert es 3x länger. Du könntest dir ein kleines Script bauen, welches bei Aktualisierung zb. eine Logmeldung ausgibt, dann könnte man den Zeitintervall sehen, ich kann dir dabei gerne helfen

[fila612]

@Xenon
Okay, klingt logisch.
Die logmeldung Ausgeben wäre ja machbar, nur Weiß ich grad nicht worauf ich den Pointer setzen sollte. Einfach auf value.power wäre zu kurz gedacht, da sich der Wert ja im ausgeschalteten Zustand nicht ändert.
Wenn ich in die Objekte schaue, dann leuchten manche Werte ab und zu grün auf, z.b. die temp. Oder uptime. Ich vermute das das grüne blinken evtl. So ein senden symbolisiert.
Bei value.Power ist da nicht viel grün, zumindest jetzt wo die Geräte aus sind:(

[Xenon]

@fila612 wenn du mit der Maus auf den wert gehst (nicht klicken!) erscheint ja ein popup, worin die Zeit der letzten Änderung und der letzten Aktualisierung steht.
Seit Firmware 1.5 gibt es bei shelly wohl Probleme, dass die Geräte zu schnell in den deepsleep Mode gehen und nicht mehr senden, so lange es keine Wertänderung gibt. Damals gab es auch eine Lösung, wie man es umgehen kann, ob das heute noch funktioniert weiß ich aber leider nicht

[fila612]

@Xenon
Ich schau mir das mal an, bin aber grad nicht am Rechner.
Was ich grad noch gefunden habe ist deren api Beschreibung (https://shelly-api-docs.shelly.cloud/#shelly-plug-plugs-status).
Gerade bei /Meter/0 sollte doch der timestamp helfen oder der Counter, aber ich glaube das dies nicht sauber funktioniert, da de4 timestamp weiter hochzählt obwohl die Geräte aus sind.

[harrym]

Shelly schickt ÄNDERUNGEN .... sowohl bei CoAP als auch bei MQTT .... somit melden sie sich recht häufig und nachdem jetzt auch der CoAP Bug behoben ist, sollte dir eigentlich ein Zeitraum von unter einer sekunde reichen.

[harrym]

@Xenon Firmware aktuell bei Shelly: 1.8.4

[Xenon]

@harrym sagte in [Vorl.]Gerätezustandsüberw.+Benachrichtigung bei Start/Ende:

Shelly schickt ÄNDERUNGEN .... sowohl bei CoAP als auch bei MQTT .... somit melden sie sich recht häufig und nachdem jetzt auch der CoAP Bug behoben ist, sollte dir eigentlich ein Zeitraum von unter einer sekunde reichen.

Wie gesagt, ich kann mich nur auf die Aussagen der Leute berufen, die die shellys im Einsatz haben. Anscheinend wird aber nicht gesendet, wenn der Wert 0 W ist und sich nicht ändert, dass ist aber zwingend notwendig, da sonst die Berechnungen nicht funktionieren

[harrym]

@Xenon aber es ändern sich andere Werte .... eben die Uptime und sonstiges .... 0 W wird dann weiterhin mitgeschickt im CoAP/MQTT Block

[Xenon]

@harrym sagte in [Vorl.]Gerätezustandsüberw.+Benachrichtigung bei Start/Ende:

@Xenon aber es ändern sich andere Werte .... eben die Uptime und sonstiges ....

Da habe ich nichts von, es wird auf Aktualisierung Verbrauch getriggert.
Und ich will ungerne jetzt den trigger ändern, wenn das Script auf allem läuft, außer auf shelly..

[harrym]

@Xenon btw .... @da_Woody hat das Script auch mit Shelly am laufen ..... da hatten wir die Probleme nicht ;) Muss aber mal fragen, was da jetzt für eine Version vom Script im Einsatz ist.

[Xenon]

@harrym habe den Eindruck das hier entweder zu viel im Script gefummelt wurde oder das eventuell Probleme im Netzwerk vorhanden sind, die verzögerte Werte zur Folge haben...
Ich schaue trotzdem mal, ob ich den trigger auf einen Wert legen kann, der sich immer aktualisiert, halte da aber nicht viel von