[wiregate] _cycle Angabe aus plugin wird ignoriert

[emax]

Ich habe hier das Problem, das der wiregated ein Plugin ausführt, obwohl _cycle das eigentlich nicht zulässt.

Beispiel: Ich setze _cycle im plugin auf 8 Sekunden, aber es wird bereits nach deutlich weniger als 2 Sekunden ausgeführt - was schlecht ist. Dabei variieren diese Zeiten ohne dass ich eine Regelmäßigkeit erkennen könnte.

Hier mal ein (abgestripptes) plugin und die davon erzeugten Ausgaben im log.

# -*- Perl -*-

# Aufrufgrund ermitteln
my $event=undef;
if (!$plugin_initflag) {
    $event='restart';  # Restart des daemons / Reboot
} elsif ($plugin_info{$plugname.'_lastsaved'} > $plugin_info{$plugname.'_last'}) {
    $event='modified'; # Plugin modifiziert
} elsif (defined $msg{'apci'} and $msg{'apci'} eq "A_GroupValue_Write") {
    $event = 'bus';    # bus telegram
} else {
    $event = 'cycle';
}

plugin_log($plugname, "Doing '$event'");        

if ($event eq 'modified') {    
    $plugin_subscribe{'0/0/28'}{$plugname} = 1;
    $event = 'cycle';           # after subscription, run a regular cycle
} # modified ...

if ($event eq 'restart') {
    plugin_log($plugname, "in 'restart'");
    $event = 'cycle';
}

if ($event eq 'bus') {
    plugin_log($plugname, "in 'bus'");
    plugin_log($plugname, "INF: telegram from pa[$msg{'src'}], ga[$msg{'dst'}], val[$msg{'data'}]");
    $plugin_info{$plugname.'_cycle'} = 8;
} elsif ($event eq 'cycle') {  
    plugin_log($plugname, "in 'cycle'");
    $plugin_info{$plugname.'_cycle'} = 60;
} # cycle

return "$plugname: _cycle[$plugin_info{$plugname.'_cycle'}]";

Das Plugin ist hier tatsächlich zu Ende, es gibt keine weiteren Zeilen mehr.

Nun die Ausgabe im Log (Kommentare in blau manuell hier eingefügt, Zeitsprung zwischen grün und rot viel zu klein):

2017-01-21 14:45:33.190,test.pl,Doing 'cycle'          [B][COLOR=#0000FF]# Normale Zyklus-Ausführung ab hier[/COLOR][/B]
2017-01-21 14:45:33.190,test.pl,in 'cycle'
2017-01-21 14:45:33.193,test.pl,test.pl: _cycle[60],0s,
2017-01-21 14:45:56.135,test.pl,Doing 'bus'[B][COLOR=#0000FF]            # Ab hier telegramm von mir ausgelöst, alles geht wie erwartet[/COLOR][/B]
2017-01-21 14:45:56.136,test.pl,in 'bus'
2017-01-21 14:45:56.136,test.pl,INF: telegram from pa[1.2.201], ga[0/0/28], val[01]
2017-01-21 [B][COLOR=#008000]14:45:56.138[/COLOR][/B],test.pl,test.pl: _cycle[8],0s, [B][COLOR=#0000FF]# eindeutig 8 Sekunden _cycle, hier direkt aus plugin_info angezeigt[/COLOR][/B]
2017-01-21 [B][COLOR=#FF0000]14:45:56.481[/COLOR][/B],test.pl,Doing 'cycle'          [COLOR=#0000FF][B]# Ab hier das Problem. Das Plugin wird sofort erneut ausgeführt, [/B][/COLOR]
2017-01-21 14:45:56.481,test.pl,in 'cycle'
2017-01-21 14:45:56.483,test.pl,test.pl: _cycle[60],0s,

Ich hab mich hier schon grün und blau geärgert, weil das m.e. vor langer Zeit alles mal tadellos funktionierte. Gibt es da bekannte Änderungen/Einschränkungen ?

Mein emx_dcode plugin hängt z.B. von einigermaßen genauen Timeouts (+/0,5 Sekunden) ab, und hat immer exakt funktioniert. Nun macht es Zicken.

Ich bin hier auf V1.4.0.

[emax]

Hat denn keiner eine Idee?

Vielleicht kann ja mal jemand das Plugin bei sich laufen lassen. Es tut ja nichts, außer sich selber aufzurufen. Lediglich meine die test-GA 0/0/28 müsste durch eine eigene Lichtschalter-GA ersetzt werden, eine conf-Datei gibt es nicht.

Würde mir schon helfen, wenn ich wüsste, ob das auch anderswo so ist.

[Robert_Mini]

Kann das leider gerade nicht testen (bin auf Dienstreise).
Ich kenne diesen Effekt nur, wenn man auf eine GA schreibt, die man man mit subscribe angemeldet hat.

Ich bin mir nicht mehr ganz sicher, aber es gibt da das Thema, dass GAs angemeldet bleiben, auch wenn man das subscribe aus dem Plugin löscht.

Vll. hilft dir das?

lg
Robert

[emax]

Danke Robert,

der Effekt tritt auch auf, wenn ich die plugin.db gelöscht habe, also alle Registrierungen ebenfalls gelöscht wurden. Daran liegt es also nicht.

Das Plugin oben schreibt ja auch auf keine GA, kann sich also auch nicht selber triggern. Und die testhalber verwendete GA wird nur von einem einzigen Schalter beschrieben, und der liegt mit einem Verlängerungskabel bei mir auf dem Schreibtisch neben der Tastatur. Außerdem würde, wenn ein Telegramm dran schuld wäre, im Log dann ja so was stehen:

2017-01-21 14:45:56.136,test.pl,in 'bus'

Vielleicht kannst Du später zuhause ja mal probieren, wie das bei Dir läuft.

[XueSheng]

Ich verstehe das Problem nicht. Laut log ist doch alles ok. Letzter cycle um 14:45:33 Uhr. Der 8 sec cycle wird um 14:45:56 gesetzt und ist somit längst überfällig.

Pluginaufrufe durch Telegram beeinflussen _cycle nicht, da _last nur bei zyklischen Aufrufen aktualisiert wird (durch wiregated selbst).

Wenn Du willst, dass alle Pluginaufrufe _cycle beeinflussen, musst Du _last manuell aktualisieren (_last = time() bei jedem Pluginaufruf).

[emax]

> ich verstehe das Problem nicht.

Sieht so aus ;-)

_cycle steht auf 8. Das plugin kommt aber nach schon nach knapp einer Sekunde wieder zurück. Soll aber erst nach 8 Sekunden wiederkehren.

Muss man denn _last selber setzen? Das wäre für mich neu. Denn auch wenn das Plugin durch ein Bus-Event aufgerufen wird, müsste dann nicht nicht der wiregated auch _last immer automatisch aktualisieren?

Wenn das nicht so ist, dann hättest Du u.U allerdings Recht - und ich wäre dankbar für den Hinweis. :-)

[XueSheng]

Ich habe doch geschrieben wie sich wiregated verhält. Kannst ja in den Code sehen, um Dich selbst davon zu überzeugen.

[Robert_Mini]

So kenne ich das auch: Aufruf mit jedem _cycle Intervall und mit jeder angemeldeten GA.

[emax]

@XueSheng: Du hast Recht, das war der entscheidende Hinweis.

Ich hatte (nur) diese Zeile im wiregated beachtet:

$plugin_info{ $plugname . '_last' } = time() unless ( $runname eq $plugname ); #only reset cycle on non-direct call

und den Kommentar am Zeilenende nicht ernst genommen, weil ich mir dachte 'naja, ich ruf ja nix direkt auf'. Nach Deinem Hinweis hab ich mir dann nochmal den ganzen wgd genauer angeschaut, und dann erst bemerkt, dass Telegramme nur im eiblisten_thread verarbeitet werden (was in Nachhinein ja auch logisch erscheint):

check_generic_plugins($k);

also 'direct call', wie im Kommentar dokumentiert. Eindeutig mein Patzer, jetzt läuft alles wie es soll.


Besten Dank noch mal! :-)


PS: Was ich nicht begreife ist, warum das vorher zu gehen schien. Allerdings hatte ich das zuletzt vor drei Jahren getestet, seit dem sind viele Versionen gegangen und gekommen ...


PPS: Wirklich fein, dass es hier immer wieder kompetente Hilfe auch für sehr spezielle Fragen gibt! :-)

[Hammer69]

Hallo Emax,

ich würde auch sagen vor langer Zeit hat das dCode Plugin funktioniert, doch irgend wann leider nicht mehr.
Was hast du denn nun geändert das dein Plugin "dcode" nun wieder funktioniert?
Oder ist nun auf Github eine aktuelle Version.

Schönen Sonntag
Stefan

[emax]

Hallo Stefan,

mir war gar nicht bewusst, dass das überhaupt jemand verwendet. Umso schöner, mal eine Rückmeldung zu bekommen. :-)

Nein, ich habe ewig nichts auf Github eingecheckt, weil ich plötzlich keinen Zugang mehr hatte (wegen svn-Umzug usw.). Nun hat Chris mir (vielen Dank!) kürzlich wieder Zugang zum aktuellen Repository verschafft, da werde ich das dann wohl mal aktualisieren.

Allerdings hatte ich hier zuhause die ein oder andere Änderung als 'Laborversion' laufen, und muss nun erst mal schauen, welche Änderung nun korrekt einzuchecken ist. Ich mache das dann hier bekannt.


Wenn so was nicht funktioniert, dann ist es übrigens imemr eine Idee, hier mal nach zu fragen. Die Wiregate-Sachen gehören zu den wenigen Dingen, die ich wirklich auch nachhaltig betreibe. Es ist ein tolles Produkt, da setz ich mich auch mal hin, wenn es 'nur' für andere ist.


PS: Noch was: Ich habe in der Zwischenzeit einiges gelernt (bzw. lernen müssen), was die Implementierung der Plugins anbelangt. Es liegen halt im Detail doch mehr Möglichkeiten für Fehler ebenso wie für Verbesserungen. Deshalb kann das mit dem decoder schon etwas dauern, denn wenn schon, dann möchte ich das auch gründlich 'nach dem Stand der Erkennisse' machen. ;-)