14_CUL_MAX.pm - (Wunsch-) Reaktion auf 'Send Queue missing ack from ...'

[Hanso]

Hallo in die Runde,

im Modul 14_CUL_MAX.pm Zeile 1295 wird auf das Fehlen eines Ack nach 3-maligem Senden des Kommandos mit dem Eintrag ins Log und dem Entfernen aus der Queue reagiert.
siehe hier:

Code Auswählen Erweitern

      {
        Log3 $hash, 3, $name.', Send Queue missing ack from '.$packet->{dst_name}.' for '.$packet->{cmd}.', removing from queue';
        splice @{$hash->{sendQueue}}, $pktIdx, 1; # Remove from Queue


Hier wäre wünschenswert, dem Anwender das komplette Scheitern des Sendens eines Kommandos zu signalisieren.
Z.B. über eine konfigurierbare Callback-Routine des Anwenders.
So kann man u.a. das Erkennen von Verbindungsstörungen z.B. durch das Senden einer Mail signalisieren.
Ansonsten bleibt dem Anwender nur, im Nachlauf die Log-datei zu sichten.

Ich helfe mir hier seit geraumer Zeit mit einer eigenen 'CallBack-Routine' mit folgender Zeile, die ich nach der LOG3-Zeile einfüge:

Code Auswählen Erweitern

my_14_CUL_MAX_ErrorHandler(2, $packet->{dst_name}, "Send Queue missing ack from $packet->{dst_name} for $packet->{cmd}");

Dort erzeuge ich u.a. eine Mail.

Ich spreche hier ein prinzipielles Design-Thema des Handlings  (nicht nur!) von MAX-Geräten an:
Die abgesetzten Kommandos für die Geräte (z.B. der set-Befehl) laufen in eine Queue und werden 'zur Unzeit' abgearbeitet.
Dem Anwender fehlt hier die Möglichkeit die Kommandos über eine zentrale Schnittstelle in gewünschter Reihenfolge
mit der Möglichkeit auf den Status der Schnittstelle reagieren zu können.
Eine eigene Anwender-Schnittstellen-Schicht zu realisieren scheitert spätestens mit dem Einsatz von FTUI.
Die dort abgesetzten Kommandos laufen 'intern' und sind oft nicht transparent für den Anwender.
FTUI nutze ich ausgiebig.

Also bleibt nur, hier und da, wo es sinnvoll erscheint bestehende Module um Anwender-Callback-Routinen zu ergänzen.

Wie seht ihr das?

Gruß
Hans

[rudolfkoenig]

Meiner Ansicht nach fehlt hier ein Event, worauf ein notify/DOIF/etc reagieren kann.
Notfalls kann man im notify auch auf logfile-Aenderungen reagieren, indem man "attr ntfy readLog 1" setzt.

[Wzut]

fehlt hier ein Event, worauf ein notify/DOIF/etc reagieren kann.

in meiner Beta habe ich ein Reading error das könnte in der nächsten Version den Job übernehmen.

[Wzut]

so wie versprochen hier meine aktuelle Beta Version mit dem neuen Reading error
@Hanso , das sollte deine eigene CallBack überflüssig machen da du nun mittels notify/DOIF das Readings auswerten und reagieren kannst.