Monatsrückblick Januar/Februar 2026 ist online!

[ArnoD]

Ich habe bei mir jetzt den Fehler mit der doppelten Push Meldung korrigiert, eventuell willst du ja die Lösung in deinem Script übernehmen.
Es ist eigentlich derselbe Fehler, wie Jens bei seiner Quittierung der Fehler macht.
Das ein Fehler, der noch aktuell ansteht, versucht wird zu quittieren, was natürlich nicht geht.
Die Schleife STICKY_UNREACH darf erst durchlaufen werden, wen UNREACH= false ist, sonst kann der Fehler nicht quittiert werden.
Ich habe in deiner Funktion Servicemeldung(obj) eine neue Variable var id_UNREACH und status_UNREACH eingefügt und folgenden code geändert:

Ist Programmiertechnisch nicht die beste Lösung aber es funktioniert und mir ist nichts besseres eingefallen ohne das ganze Script abzuändern. :grinning:

[ArnoD]

und so sieht es dann in Pushover aus:

[cash]

@ArnoD Der Buchstabendreher ist mir gestern auch schon aufgefallen :-) Werde ich im Script anpassen.

Hast Du nur die drei Zeilen geändert? Dann baue ich das ganze ein. Kannst Du natürlich auch per GitHub direkt machen dann merge ich das ganze.

Gute Idee übrigens.

[ArnoD]

@cash pull requests erstellt.

[MartyBr]

@ArnoD
Richtig, ich wollte nicht im Script ändern. Es hätte ja auch bewusst so sein können, als zweite "Message"-Variable.
Ist aber nun erkannt worden.

[cash]

@MartyBr das war ein Schreibfehler bzw copy & past. Deshalb habe ich es auch beim suchen nicht gefunden :-)

Habe die Variablen nun ganz entfernt weil ich die eigentlich eh schon geändert hatte in Servicemeldung und formatierte_Servicemeldung. Hatte es nur an einer Stelle übersehen.

@ArnoD Danke nochmal. Habe ich entsprechend gemerged und meine Änderungen noch eingebaut. Dann warte ich mal auf meine nächste Servicemeldung... Wie testest Du das eigentlich? Oder hast Du bei der Heizung in der Garage öfter Kom-Störungen?

@All V1.45 ist auf github verfügbar.

[MartyBr]

@cash
Vielen Dank, werde ich testen!

[ArnoD]

@cash said in Servicemeldungen - All inclusive für Homematic -:
Wie testest Du das eigentlich? Oder hast Du bei der Heizung in der Garage öfter Kom-Störungen?

Nein, ich habe für eine E-Heizung in der Garage ein HM-ES-PMSw1-Pl Funk-Schaltaktor mit Leistungsmessung den ich einfach ausstecken kann.

[ArnoD]

Ich habe die Version 1.45 jetzt mal getestet und unreach funktioniert so, wie es soll, bei den RF Geräten, leider nicht bei den IP Geräten da es dort den Datenpunkt STICKY_UNREACH nicht gibt. Man bekomm zwar die Meldung das die Kommunikation gestört ist, aber keine Meldung, wenn die Störung nicht mehr besteht. Ein Vorschlag wäre eine Push Meldung zu schicken, wenn das Script durchgelaufen ist und keine Störmeldung vorliegt, das würde dann alle Meldungen abdecken und man kann im Urlaub wieder beruhigt sein :grinning:
Habe auch LOWBAT getestet, dort ist mir aufgefallen, das die Uhrzeit an die Servicemeldung mit angehängt wird, obwohl die Variable with_time = false ist.

Hier müsste bei else +datum_seit entfernt werden, ausser es ist so beabsichtigt.

Alles andere funktioniert echt super :+1: :grinning:
UNREACH IP :heavy_check_mark:
UNREACH RF :heavy_check_mark:
STICKY_UNREACH RF :heavy_check_mark:
SABOTAGE RF :heavy_check_mark:
SABOTAGE IP :heavy_check_mark:
LOWBAT RF :heavy_check_mark:

[cash]

@ArnoD Batterie-Meldung mit Datum ist eigentlich so gewollt. Der Grund dafür ist simpel. Wenn man zum erstenmal die Meldungbekommt wäre das Datum theoretisch über aber wenn Du nicht sofort reagierst sondern wartest und in der Zwischenzeit kommt z. B. eine unreach Meldung dann bekommt man ja eine Push mit beiden aktuellen Meldungen und dann fand ich es besser wenn bei der Batterie generell das Datum dabei ist. Alle anderen Servicemeldungen sind i. d. R. Ja nur temporär. Lediglich die Batteriemeldung kann auch schon mal ein paar Wochen vorhanden sein.

Bei den IP Meldungen wäre die Frage wie man das realisieren will das man eine Push kriegt wenn es erledigt ist? Bei den normalen braucht man die ja nicht. Generell eine Push wenn keine Meldung mehr vorliegt finde ich auch eher nicht so gut, da ich z. B. nach einen Batteriewechsel weiß das die Meldung erledigt ist.

[ArnoD]

@cash ok verstanden, macht sinn. :+1:
Mann könnte ja bei den IP Geräten UNREACH_ALARM===2 abfragen, mir ist nur noch nicht klar wan dieser Datenpunkt 0 wird.

[integer63]

Auch von mir zu aller erst mal ein fettes DANKE!

Und ich möchte etwas melden :-)
Bitte melden: Wohnzimmer.FB19 (MEQ0602355) --- HM-RC-19-SW --- Batterietyp fehlt im Script

Eine Frage habe ich: wieso bleibt bei mir "Anzahl_GESAMT" auf 1, obwohl alle anderen Zähler auf 0 sind? (auch Text ist leer)

Beste Grüße
Thomas

[cash]

@integer63 Welche Batterien gehören darein? 3 x AAA?

Bei mir steht das Feld auch auf 1. Ist mir nicht aufgefallen. Habe den Fehler hoffentlich behoben. Werde ein Update bei GitHub einstellen zusammen mit dem Batterieupdate.

[integer63]

@cash Bei der Fernbedienung sind drei NiMH Akkus (Typ HR 03) und eine Ladestation mit dabei - also keine klassischen Batterien.

[integer63]

Mir ist gerade aufgefallen, dass es auch andersherum nicht stimmt - falls das bei der Fehlersuche hilft:

[SRo769]

vielen vielen Dank für die super Arbeit! Script läuft sauber. Jetzt wird die Überwachnung deutlich komfortabler:+1:

Nachtrag: bei den Geräten ohne Batterie fehlt noch das 'HM' im Eintrag 'HM-LC-Sw2PBU-FM'

[cash]

Neues Update auf github. Sollte hoffentlich das Problem mit der Anzahl der Servicemeldungen lösen.

[Knallochse]

@cash Ich möchte mich einfach nur mal für dein Servicemeldungsscript BEDANKEN :+1:

[cash]

@Knallochse Danke. Habe viel gelernt durch das Script :-)

[integer63]

@cash Danke für das schnelle Update. Der Gesamtzähler geht jetzt auch auf 0, aber leider bleibt nun im TEXT etwas stehen:

Kannst du dir das bitte auch noch mal ansehen?