UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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 :sunglasses:

[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 :wink:

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