Auslöser eines Programmes finden und loggen

[MichaelN]

Woran kann das liegen, wenn das Skript kein Telegramm sendet? Der Protokoll Eintrag wurde erstellt, aber ich habe kein Telegramm empfangen. Benutze CUxD und prinzipiell funktioniert es auch. Nur manche kommen nicht durch.

[Baxxy]

Woran kann das liegen, wenn das Skript kein Telegramm sendet?

Vermutlich daran, das in Alchy's Script (von Seite 1 des Threads) überhaupt keine Sendefunktion irgend einer Art implementiert ist. Es wird nur die SysVar "Programme_loggen" gefüllt.

Grüße
Baxxy

OT:
@Alchy... jetzt erst gesehen das dein Script wieder verfügbar ist. Danke dafür!
OT Ende:

[MichaelN]

OK, etwas ausführlicher. Ich habe das Skript, wie in Beitrag 1 auch beschrieben, natürlich um die Sende Funktion ergänzt. Das Skript habe ich in der Form in mehreren Programmen drin und getestet. Es läuft prinzipiell. Habe z. B. Um 13:30 und 14:04 ein Telegramm erhalten. Um 15:15 und 15:30 erscheint nur die protokolliert variable im Protokoll, aber kein Telegramm abgekommen. Andere skripte senden mir weiterhin Telegramm. Das meinte ich mit "prinzipiell funktioniert es".

[alchy]

Wenn das Script dir "ab und zu" eine Telegramnachricht schickt aber immer die Variable beschreibt würde ich im Fehlerprotokoll nachschauen.

@Alchy... jetzt erst gesehen das dein Script wieder verfügbar ist. Danke dafür!

Dann gibt es ja schon jemanden der es testet. Meldungen über Probleme werden entgegen genommen.

Alchy

[Xel66]

Wenn das kopierte Script in diesem Programm nicht funktioniert, aber in anderen, dann hast Du wahrscheinlich in dieser Kopie einen Fehler drin. Darum sind zentrale Programme, die sich um soetwas kümmern auch zuverlässiger, denn in anderen Programmen braucht nur die jeweilige Systemvariable beschrieben werden und das Telegram-Programm kümmert sich um den Versand. dtp hat sowas im zPNP umgesetzt. Ich setze dafür ein eigenes Script ein. Dieses reagiert auf die Änderung/Aktualisierung der Variable und kümmert sich um den Versand des Inhaltes. So muss man nicht immer wieder das gleiche Script in vielen Programmen hinterlegen sondern kann den Versand zentral pflegen. So mache ich es auch mit anderen Diensten wie TTS und Mail. Und es verhindert auch, dass man vielleicht das Script fehlerhaft kopiert (weil man es eben nicht kopieren muss) und es funktioniert entweder in allen Programmen, die die Systemvariable verändern oder in gar keinem.

Gruß Xel66

[MichaelN]

Wenn das Script dir "ab und zu" eine Telegramnachricht schickt und dann auch mal wieder nicht, würde ich im Fehlerprotokoll nachschauen.

Das würde ich gerne, ist aber einer der Punkte, mit denen ich mich auch noch nicht auskenne.
Welches Fehlerprotokoll? Das der CCU oder von CUxD oder ??? Und wenn, wo finde ich die?
CCU - Systemsteuerung - Zentralenwartung
CUxD - Info - FullSysLog

Diese Dateien sind voll mit Kram, der mir ncihts sagt. Nach welchen Stichwörtern sollte ich schauen? Wie unterscheide ich übliche Meldungen von Problemen?

Code: Alles auswählen

May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-3] (un)registerCallback on LegacyServiceHandler called from url: http://127.0.0.1:2098 
May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-0] init finished 
May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.internal.InterfaceInitializer INFO  [vert.x-worker-thread-1] Added InterfaceId: HmIP-RF 
May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.internal.DeviceUtil INFO  [vert.x-worker-thread-1] updateDevicesForClient HmIP-RF -> 92 device addresses will be added 
May 9 15:30:05 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-1] SYSTEM: 0 Accesspoints in Queue 
May 9 15:30:05 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-1] SYSTEM: Permanent-/Burstlistener Handler utilization: 0/50 used 
May 9 15:30:05 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-1] SYSTEM: Eventlistener Handler utilization: 0/50 used 
May 9 15:30:05 de.eq3.cbcs.lib.remotecommadapter.device.service.AccessPointWatchdog INFO  [vert.x-eventloop-thread-0] SYSTEM: Access Point Watchdog running periodic connection check... 

[MichaelN]

Wenn das kopierte Script in diesem Programm nicht funktioniert, aber in anderen, dann hast Du wahrscheinlich in dieser Kopie einen Fehler drin. Darum sind zentrale Programme, die sich um soetwas kümmern auch zuverlässiger,

Leider nicht. Ich habe auch ein zentrales Telegram-Sende-Program, das wie von Dir beschrieben arbeitet. Hier habe ich die gleichen Verluste. Ich hatte vermutet, das es dadurch passiert, das mehrere Programme (nahezu) zeitgleich die Variabel ändern. Und gedacht, wenn das Skript gleich im Programm mit drin ist, kann das nicht passieren.

Gibt es eine Beschränkung seitens Telegram von max. x Nachrichten pro Minute oder so?

btw: Würde diese Routine zur Ermittlung des Auslösers denn überhaupt in einem zentralen Programm funktionieren?

[alchy]

Es ist doch nicht weiter schwierig Wörter wie >> Fehlerprotokoll << in der Suche einzugeben.

Diese Dateien sind voll mit Kram, der mir ncihts sagt. Nach welchen Stichwörtern sollte ich schauen? Wie unterscheide ich übliche Meldungen von Problemen?

Als erstes mache es Sinn Nur Fehler zu loggen, einzustellen unter Klickibunti - Systemsteuerung - Zentralenwartung - Fehlerprotokoll...
Außerdem habe ich auch nicht behauptet, das dir das Fehlerprotokoll etwas sagt

Ein ganz großer Vorteil des Fehlerprotokolls ist seine zeitliche Struktur.
Führt man ein Script um 22:43 aus, dann macht es Sinn die Einträge um +/- 22:43 herum zu betrachten / zu posten.
Im Scriptfehlerfall ist messages.XXX das interessantere Protokoll.

Und wenn, wo finde ich die?
CCU - Systemsteuerung - Zentralenwartung
CUxD - Info - FullSysLog

Beides korrekt, schau es dir einfach mal an und vergleiche den Inhalt.
Eine weitere Möglichkeit ist einfach ein kleines Script zu bemühen, welches z.B. die letzten 100 Zeilen anzeigt:

Code: Alles auswählen

!Fehlerprotokoll letzte 100 Zeilen ausgeben
string stdout;string stderr;
system.Exec("tail -100 /var/log/messages",&stdout,&stderr);
WriteLine(stdout);

btw: Würde diese Routine zur Ermittlung des Auslösers denn überhaupt in einem zentralen Programm funktionieren?

Vielleicht fängst du bei 0 an und postest mal genau, was dein Vorgehen und was dein Problem ist und bebilderst das Ganze vielleicht auch mal mit dem Programm usw.




Alchy

[Baxxy]

Dann gibt es ja schon jemanden der es testet.

Naja, ich muss es erstmal in den neuralgischen Programmen einpflegen. Dann melde ich mich falls Problemchen auftauchen sollten.
Ein guter Kanditat zum testen wäre ja die neue Astro-Offset Funktion der RaspberryMatic-Experimental Version. Jaja ich weiß, da biste raus.

Genug OT...

Grüße
Baxxy

[MichaelN]

Vielleicht fängst du bei 0 an und postest mal genau, was dein Vorgehen und was dein Problem ist und bebilderst das Ganze vielleicht auch mal mit dem Programm usw.

OK.

Das Programm

Das Skript

Code: Alles auswählen

! Programmauslöser egal welchen Types (soweit ich es überblicken kann)
! mit Programmname, Auslöser, Auslösewert und (Einheit falls vorhanden) und Zeit in Stringvariable schreiben +  Telegram senden
! v 0.98 (c) by alchy
! https://homematic-forum.de/forum/viewtopic.php?f=31&t=35686

Das Programm lief um 15:30 durch und dein Skript hat die Protokollvariable beschrieben und das System hat sie protokolliert:

Aber auf meinem Handy ist kein Telegram angekommen. Davor und danach haben andere Programme - und auch dieses - erfolgreich Telegramme gesendet. Bzw. sind sie auch erfolgreich zugestellt wroden. Fehler kann ja auch auf Seiten von WWW, Telegram, WLAN, Mobilfunk, Smartphone liegen.

Im CUxD steht im Zeitfenster 15:30 gar nichts drin.
Und das Log der CCU habe ich oben schon gepostet:

Code: Alles auswählen

May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-3] (un)registerCallback on LegacyServiceHandler called from url: http://127.0.0.1:2098 
May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler INFO  [vert.x-worker-thread-0] init finished 
May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.internal.InterfaceInitializer INFO  [vert.x-worker-thread-1] Added InterfaceId: HmIP-RF 
May 9 15:29:38 de.eq3.cbcs.legacy.bidcos.rpc.internal.DeviceUtil INFO  [vert.x-worker-thread-1] updateDevicesForClient HmIP-RF -> 92 device addresses will be added 
May 9 15:30:05 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-1] SYSTEM: 0 Accesspoints in Queue 
May 9 15:30:05 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-1] SYSTEM: Permanent-/Burstlistener Handler utilization: 0/50 used 
May 9 15:30:05 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO  [vert.x-eventloop-thread-1] SYSTEM: Eventlistener Handler utilization: 0/50 used 
May 9 15:30:05 de.eq3.cbcs.lib.remotecommadapter.device.service.AccessPointWatchdog INFO  [vert.x-eventloop-thread-0] SYSTEM: Access Point Watchdog running periodic connection check... 

Fragestellung: wieso kommen manche Telegramme nicht durch?

btw: einegstellt ist "nur Fehler" für die Protokollierung. Trotzdem ist das Log voll. Wenn das alles Fehler sind. Puh, da habe ich was zu googeln.