Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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

[harrym]

@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.

[da_Woody]

@Xenon nichts anpassen! das tut! ich hab gerade nochmal geschaut, value.power wird alle 5sec update gesendet, solange der shelly plug-s eingeschalten ist. das liegt am eigenverbrauch. wenn switch = false wird logischer weise auch nichts gesendet. wozu auch.

@fila612 wie gesagt, solange der shelly aufgedreht ist, werden die werte aktualisiert, erst wenn der shelly abgedreht ist, gibts keine value.power weils nicht benötigt wird. sobald der shelly (gerät) aktiv, werden werte aktualisiert.

während dem schreiben am 2. monitor getestet...

[fila612]

@da_Woody
Danke dir, die Shellys an trockner und WaMa bleiben immer an (switch=true).
Ich möchte auch nicht, dass hier gleich ohne Analyseergebnis am Script geschraubt wird.
Was mich positiv stimmt ist, dass es anscheinend bei einigen mit den Shellys funktioniert. Habt ihr PlugS oder evtl. die Unterputzvarianten?
Ich habe eben nochmal nachgesehen, der Timestamp bei Mouseover ist tlw. unterschiedlich und mehrere Stunden alt.
Zusatzinfo: ich monitore & erfasse bei den Shellys mit dem Sourceanalytics Adapter die fortlaufenden Verbrauchswerte & Kosten.
Was mir auch auffällt ist der Punkt Quelle (Mouseover bei value.power): dort steht bei WaMa der Shelly Adapter, beim Trockner jedoch der Sourceanalytics Adapter.
Nicht das dieser Adapter da irgendwie mit reinfunkt.
Ich werden diesen einmal deinstallieren (funktioniert aktuell sowieso noch nicht zuverlässig) und melde mich nochmal.

Am Script selber habe ich nicht groß "rumgefummelt", nur folgendes (letzter Wert geändert):

console.debug(obj)
    switch (obj.geraeteTyp) {
        case 'wama':
            const WaMa = new Geraet(obj, zustand, verbrauchAktuell, laufzeit, zustandSchalter, 15, 5, 3, 10); //15, 5, 3, 65
            arrGeraete.push(WaMa);
            break;
        case 'dryer':
            const Trockner = new Geraet(obj, zustand, verbrauchAktuell, laufzeit, zustandSchalter, 120, 10, 5, 10); //120, 10, 5, 60
            arrGeraete.push(Trockner);
            break;

Fakt ist: ich lasse aktuell beide Script (dieses hier und mein altes Blockly) parallel laufen. mein Blockly sendet Telegramm, dieses hier Whatsapp.
Wenn ich die Nachrichten vergleiche, dann erhalten ich sofort nach Ende des Wasch- bzw. Trockenprogramm eine Nachricht via Telegramm (altes Script) aber extrem zeitversetzt via Whatsapp:
Mit den originalwerten aus dem Script (65 &60):
WaMa fertig: Telegramm 17:38Uhr ; Whatsapp: 3:51Uhr
Angepasste Werte (10 & 10):
Trockner fertig: Telegramm: 16:45Uhr; Whatsapp: 17:18Uhr

@harrym: Könntest du mir evtl. etwas spezifischer sagen, woran du ein sauberes Netzwerk ausmachst? würde das gerne prüfen, aber da gibt es viele Einstiegspunkte und ich würde behaupten, dass es nicht das schlimmste Netz ist, was ich habe - aber Optimieren geht ja bekanntlich immer :)

[da_Woody]

@fila612

die Shellys an trockner und WaMa bleiben immer an (switch=true)

jup, bei mir im normalfall auch.

Habt ihr PlugS oder evtl. die Unterputzvarianten?

WaMa hat nen Plug-S, Trockner einen Plug. der Plug-S hat immer overpower am Trockner bekommen...
die verschiedenen quellen machen mich da "etwas" stutzig. bei mir lööpt alles über alias ab. geloggt wird über influxDB. wegen dem script müsste dir @harrym auskunft geben. die hat er geschnitzt und ist auch anwesenheitserkennung drinnen. CMB funzt aber astrein. schneller als pushover und wie sie alle heissen.

[FredF]

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

mein Blockly sendet Telegramm, dieses hier Whatsapp.

Bin gerade hierüber gestolpert.
Whatsapp Meldungen brauchen meiner Erfahrung nach länger als Telegramm Meldungen. Wenn du das Skript und dein Blockly vergleichst solltest du bei beiden den gleiche Messanger verwenden.

[Xenon]

@FredF der Vergleich hinkt sowieso, weil mein Script auf Berechnungen basiert und die anderen mit sehr hoher Wahrscheinlichkeit auf timeout bei unterschreiten eines Schwellwertes. Wenn dann noch dazu kommt, dass man sehr lange Intervalle im Einsatz hat bis die Werte aktualisiert werden, ist der Vergleich hinfällig

[da_Woody]

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

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

mein Blockly sendet Telegramm, dieses hier Whatsapp.

Bin gerade hierüber gestolpert.
Whatsapp Meldungen brauchen meiner Erfahrung nach länger als Telegramm Meldungen. Wenn du das Skript und dein Blockly vergleichst solltest du bei beiden den gleiche Messanger verwenden.

kann ich bei mir nicht bestätigen, bei mir ist der CmB schneller...

[Xenon]

Update: Der Adapter läuft bei mir auf dem Testsystem. Ich denke, dass ich ihn in wenigen Tagen zum Testen bereitstellen werde :)

[Xenon]

Test Adapter "device-reminder" in der beta im Test-Forum :)

https://forum.iobroker.net/topic/37915/test-adapter-device-reminder-v0-x

[Xenon]

adapter in der latest

@Jey-Cee Thema kann geschlossen werden