Servicemeldungen - All inclusive für Homematic -

[cash]

@ArnoD ob der Paramter das gleiche bewirkt weiß ich nicht 100% klingt zumindest so? Wenn ich mich nicht täusche gibt es die Option nur beim raspberrymatic...

Also bei IP Geräten gibt es keinen Sticky-Unreach das ist richtig. Ich möchte die Meldung auf jeden Fall haben, denn sie sagt das es eine Kommunikationsstörung gab die man nun mit dem Paramter autoACK erledigen kann.

Früher wollte man eigentlich schon wissen wieviel Kommunikationsstörungen hat meine ccu denn und wieviele erledigen sich von ganz alleine.

Sinn des Scripts ist es halt jede Servicemeldung zu pushen.

In meiner aktuellen Version (ich glaube 1.43) werden doppelte Meldungen rausgefiltert. Werde die Version heute Abend oder am Wochenende hochladen. Habe in der Version aber immer noch kleine ungereimtheiten. Ich bekomme leider nicht regelmäßig Servicemeldungen, so dass das Fehler finden nicht so einfach ist

Du kannst natürlich den Teil löschen oder auskommentieren. Einfacher geht es wenn Du ganz unten bei if(obervation) die drei Zeilen mit Sticky_Unreach auskommentierst.

Du kannst das Script jederzeit Deinen Bedürfnissen anpassen.

[ArnoD]

@cash danke für deine schnelle Antwort und für die neue Version 1.43

@cash said in Servicemeldungen - All inclusive für Homematic -:

@ArnoD ob der Paramter das gleiche bewirkt weiß ich nicht 100% klingt zumindest so? Wenn ich mich nicht täusche gibt es die Option nur beim raspberrymatic...

Ok wieder was gelernt, wuste nicht das diese Option nur bei der raspberrymatic vorhanden ist.

Habe heute die neue Version 1.43 am laufen und bin gerade wieder am testen.
Einen Fehler habe ich finden können, allerdings nicht im Script sondern in der automatischen Quittierfunktion der Raspberrymatic. Wenn ein Teilnehmer nicht mehr erreichbar ist wird die Störung automatisch quittiert und STICKY_UNREACH_ALARM auf 2 gesetzt obwohl die Störung immer noch besteht und eigentlich nicht quittiert werden kann, UNREACH bleibt auf true. Nach etwa 60 sek. wird STICKY_UNREACH_ALARM wieder auf 1 gesetzt. Das hat zur Folge das eine weitere Push Nachricht verschickt wird.
Das sieht dann so aus:

Ist aber eher ein Thema für Jens Maus

Ist es eigentlich gewollt das beide Meldungstexte verschickt werden? Also die Störung und das es sich um eine quttierbare Störung handelt.

Wenn es dir hilft bin ich immer gerne bereit zu testen, habe mehrer RF HMIP und Wired Geräte im Einsatz.

[MartyBr]

Hallo cash,
ich habe mal eine Frage zu deinem Script: Du verwendest bei den Push-Funktionen eine Variable messgae. Weiter unten im Script wird eine Variable message benutzt. Als temporäre Variablen nutzt du messgae_temp.

Ist das so beabsichtichtigt? Oder verstehe ich deinen Code nicht (bin Anfänger

[cash]

@ArnoD Ja es ist beabsichtigt das beide Meldungen kommen. Den Grund sieht man in der ersten Pushmeldung. Es kann ja sein, das es nur eine Sticky_Unreach Meldung gibt und nicht auch eine Unreach.

In Deinem Fall hätte die zweite Meldung eigentlich nicht kommen sollen. Das finde ich eher unschön und versuche ich zu unterdrücken. Das nachstellen ist halt immer schwierig um so eine Lösung zu finden.

Und was den Parameter von raspberrymatic angeht glaube ich das Jens etwas schummelt. Wenn ich mich nicht täusche unterdrückt er nur die Anzeige, da bin ich mir aber nicht so ganz sicher. Anderseits mache ich das im Script auch. Wenn man ein Gerät bei no_observation einträgt und es kommt eine Meldung wird halt nur keine Push verschickt im Protokoll taucht die Meldung trotzdem auf...

@MartyBr ich weiß nicht genau was Du meinst. Ich benutzte glaube in der aktuellen Version verwende ich kein message_tmp mehr (bin mir unsicher am ipad ist er mühsam den Code sich komplett anzugucken). Aus dem Kopf:

Früher habe ich die Meldungen erstmal in message_tmp bzw message_tmp1 aufgenommen. Unterschied war einmal mit html tags und einmal ohne. Da Telegram z. B. damit nicht umgehen kann Irgendwo im Script habe ich dann einfach message = message_tmp gesetzt so dass sie identisch sind. Den genauen Hintergrund warum ich das gemacht habe kann ich Dir nicht mehr sagen. Aber meistens habe ich mir irgend etwas dabei gedacht wenn ich eine Script Zeile schreibe

[MartyBr]

Hallo cash,

das sind diese Code passagen:

    sendTo(pushover_Instanz, { 
        device: device,
        message: message, 
        title: titel, 
        priority: prio,
        retry: 60,
        expire: 600,
        html: 1
    }); 
}

function send_telegram (messgae, user_telegram) {
    sendTo('telegram.0', { 
        text: messgae,
        user: user_telegram,
        parse_mode: 'HTML'
    }); 

Wenn du nach messgae suchst, dann findes du die Variable an mehreren Stellen:

    var servicemeldung = [];
    var formatiert_servicemeldung = [];
    var messgae_tmp = '';
    var messgae_tmp1 = '';
    var log_manuell = false;
    

Das wird wahrscheinlich auch nur ein Tippfehler sein.

[cash]

@MartyBr wie ich schon schrieb ich habe mir etwas dabei gedacht. In der aktuellen Version verwende ich message_tmp garnicht mehr. Oder meine suche funktioniert nicht.

Falls Du nicht die V1.44 benutzt aktualisiere bitte das Script.

[cash]

@MartyBr aber nochmal zu Erklärung. Ursprünglich habe ich nur message verwendet. Irgendwann kam der Wunsch auf das ich Telegram intergriere. Telegramm kann aber nicht mit html-Tags umgehen. Also habe ich zwei Variablen benutzt. Aus message wurde message_tmp und für Telegram gab es message_tmp1. Da ich viel aus meinen anderen Scripten immer wieder kopiere und meine Standard Pushover Function mit message funktioniert habe ich es so umgesetzt das ich dann die Vaiable message entweder mit message_tmp fülle oder eben mit message_tmp1 und somit hat das Script korrekt gearbeitet.

Man hätte es anders lösen können oder eben so wie ich. Viele Wege führen zum Ziel. Aber es ist eh eine alte Version. Bei der neuen habe ich es anders umgesetzt aber auch bei der Version gibt es die Variable message.

[MartyBr]

@cash
Alles klar verstanden

[ArnoD]

Ich denke @MartyBr meinte den Buchstabendreher in message, da wurde bei message das a und g vertauscht.
Bei den Funktionen send_telegram und send_mail.

genauso weiter unten im Script bei den Variablen messgae_tmp und messgae_tmp1. Ist aber nur ein kosmetischer Fehler

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

[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
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
UNREACH IP
UNREACH RF
STICKY_UNREACH RF
SABOTAGE RF
SABOTAGE IP
LOWBAT RF

[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.
Mann könnte ja bei den IP Geräten UNREACH_ALARM===2 abfragen, mir ist nur noch nicht klar wan dieser Datenpunkt 0 wird.