Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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