[Vorl.]Gerätezustandsüberw.+Benachrichtigung bei Start/Ende
-
@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 -
@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"
-
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 ..
-
@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 -
@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...
-
@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. -
@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
-
@Xenon
Verstehe, aber ich weiß grad nicht wie ich das prüfen kann. -
@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
-
@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:( -
@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 -
@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. -
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.
-
@Xenon Firmware aktuell bei Shelly: 1.8.4
-
@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
-
@Xenon aber es ändern sich andere Werte .... eben die Uptime und sonstiges .... 0 W wird dann weiterhin mitgeschickt im CoAP/MQTT Block
-
@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.. -
@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. -
@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 -
@Xenon ich würd da gar nichts anpassen. Der Shelly Adapter läuft sauber mit CoAP (wenn das Netzwerk sauber ist) und eben auch MQTT .... bzgl. MQTT haben wir sogar nen Punkt in der Konfig hinzugefügt, dass immer alles aktualisiert werden soll, auch wenn nichts geändert wurde.
