Neues Plugin: Logikprozessor.pl

[Fry]

@dombn: der Output ist völlig korrekt, genau das erwartet der Logikprozessor. Leider kann ich den Fehler nicht reproduzieren, das verhindert natürlich auch die Fehlerbehebung.

andere Frage: was liefert bei euch

echo $LANG

?

Bei mir kommt da de_DE@euro

Fry

[dombn]

Ebenfalls: de_DE@euro

Da bei mir der Fehler ja immer wieder vereinzelt auftritt, hatte ich die Ausgabe der Fehlermeldung ja so geändert, dass der Variabelinhalt von $date mit ausgegeben wird. $date ist in diesen Fällen »leer«*! Da kann dann die RegEx auch nicht matchen.


* möglicherweise auch NULL oder false. Die String-Ausgabe ist halt leer.

[firefox]

gleicher Fall bei mir, wobei ich heute morgen das Wiregate neu gestartet habe und im Moment die Plugin Log sauber ist. Werde das nochmal versuchen wenn die Meldungen wieder auflaufen.

[firefox]

@dombn

Hast Du eventuell auch parallel noch das "schaltuhr.pl" Script am laufen? Ich versuche momentan durch das Ausschlussverfahren weiter zu kommen. Seit vorgestern habe ich besagtes Plugin deaktiviert und konnte bislang den Fehler nicht mehr reproduzieren...

Gruß

[dombn]

nein, habe ich nicht.

Es laufen »nur«:
- Logikprozessor.pl
- PluginInfo_Cleanup.pl [deaktiviert]
- eigene RRD-Plugins
- eigene Consolar-Schnittstelle (Prototyp)
- eigene Rack-Lüfterregelung

Allerdings werde ich als nächstes auch mal Linknx ausprobieren. Erst muss ich aber weiter an meiner (Auftrags-)App arbeiten.


Der Fehler tritt bei mir allerdings auch nicht täglich auf. Wenn, allerdings meist mehrmals am selben Tag. Zum Beispiel im Dezember:
- 2012-12-03: 9
- 2012-12-06: 7
- 2012-12-08: 4
- 2012-12-11: 7
- 2012-12-14: 13
- 2012-12-17: 10
- 2012-12-21: 10
- 2012-12-30: 2

Jeweils zu völlig unterschiedlichen Uhrzeiten, mal vereinzelt, mal 3-4 innerhalb von wenigen Sekunden.

[Fry]

Hier wäre vielleicht ein Workaround:

 my $date=`/bin/date +"%W,%a,%u,%m,%d,%Y,%j,%H,%M,%T"`;
$date=strftime("%W,%a,%u,%m,%d,%Y,%j,%H,%M,%T",time(),0,1,0,0,70,7,0) unless $date;
 plugin_log($plugname, "Datum/Uhrzeit nicht lesbar: '$date'.") unless $date=~/^(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+)$/;

(die mittlere Zeile einfügen). Das führt dazu, dass wenn /bin/date nicht funktioniert, strftime "einspringt". Leider beachtet diese Krücke nicht die lokale Zeitzone, und ich weiß ehrlich gesagt auch nicht, wie man die einfach rauskriegt (für Sommerzeit muss die 1 in der Zeile durch eine 2 ersetzt werden).

VG, Fry

[Fry]

Noch besser so:

...
sub limit { my ($lo,$x,$hi)=@_; return $x<$lo?$lo:($x>$hi?$hi:$x); }
my $date=`/bin/date +"%W,%a,%u,%m,%d,%Y,%j,%H,%M,%T"`;
unless($date=~/^(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+)$/)
{
    plugin_log($plugname, "Datum/Uhrzeit nicht lesbar: '$date', versuche strftime.");
    $date=strftime("%W,%a,%u,%m,%d,%Y,%j,%H,%M,%T",time(),0,1,0,0,70,7,0);
    unless($date=~/^(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+)$/)
    {
        plugin_log($plugname, "Datum/Uhrzeit auch bei strftime nicht lesbar: '$date', steige aus.");
        return;
    }
}
my $calendar_week=$1;
...

so kriegt man wenigstens weiterhin mit, was los ist.

@Makki: wenn du das hier mitliest, hast du vielleicht einen Tipp, wie man _zuverlässig_ innerhalb eines Plugins Uhrzeit/Datum (in der korrekten Zeitzone) abrufen kann? Hat der wiregated die zeitzone vielleicht sogar in einer Variable abgelegt?

VG, Fry

PS Update: es geht sicher auch mit der Perl-Funktion "localtime" (die ich bis jetzt eigenartigerweise gar nicht kannte). Werde ich demnächst einbauen. -> mach ich heute noch.

[Fry]

Alle guten Dinge sind drei. Wir kommen ab sofort ohne /bin/date aus!

Hoffentlich ist das die Lösung.

my $date=strftime("%W,%a,%u,%m,%d,%Y,%j,%H,%M,%T",localtime);
plugin_log($plugname, "Datum/Uhrzeit nicht lesbar: '$date'.") unless ($date=~/^(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+),(.+)$/);

Ich habe die neue Version auch schon ins SVN gestellt (in gewohnt risikofreudiger Art :-)

Bitte berichtet, ob das das Problem löst.

VG, Fry

[dombn]

Ich erhalte die folgende Fehlermeldung:

Logikprozessor.pl,,0.3s,Undefined subroutine &main::strftime called at (eval 306) line 14

Update: hatte es gefixt (bei use POSIX fehlte strftime), fry war aber schneller und hatte schon ein Update im SVN

[Fry]

Danke. Der Fix ist dieser hier:

10c10
< use POSIX qw(floor strftime);
---
> use POSIX qw(floor);

Bereits wieder im SVN.
VG
Fry

[Fry]

Problem jetzt gelöst, oder noch da?
VG, Fry

[dombn]

Sorry, da es bei mir ja alle paar Tage nur willkürlich und nicht reproduzierbar auftrat, wollte ich noch etwas abwarten.

Aber ein Zwischenstand gibt's schon mal: bisher nicht mehr aufgetreten. Danke für den Patch.

»Gefühlt«, wird das Plugin jetzt auch weniger oft »neu gestartet« (d.h. es initialisiert sich, ohne dass es eine Änderung von mir gab. Ich vermute, es wurde wegen zu hohen Speicherverbrauchs abgeschossen.)

[firefox]

Hi,

gleiches bei mir. Bisher kein Fehler mehr aufgetreten. Muss aber jetzt noch nach und nach alle Plugins wieder reaktivieren um Wechselwirkungen auszuschließen.

Danke für Deine Hilfe!

Ich würde gerne den Feature Request "mehrfach Senden" noch einmal anpinnen. Wenn das irgendwann möglich wäre, kann ich auf andere Plugins fast komplett verzichten.
Eventuell kann ja auch die Sonnenauf- und Untergangsberechnung hier mit eingebaut werden?

Gruß Thomas

[kleinklausi]

Hi Thomas,

das mit der Sonnenstandsberechnung hatte ich auch mal überlegt. Allerdings hat mich fry in die richtige Richtung geschubst - in einem separsten Plugin den Sonnenstand etc berechnen, auf GAs senden und damit dann im Logikprozessor arbeiten.

Gruß Moritz

[Fry]

Zum "mehrfach Senden": wäre es vielleicht ein gangbarer Kompromiss, bei transmit ebenfalls Listen zuzulassen, aber dann grundsätzlich an alle den gleichen Wert zu senden? (also ein Skalarwert unter "return", der aber dann an die ganze Liste gesendet wird)

Ich fände das auch sinnvoll, vor allem weil ich gewisse Einschränkungen bei meinen Pear-Schaltaktoren festgestellt habe, die ich mit einer Logik umgehen muss.

Habe das mal eben gehackt und ins SVN eingestellt. Bitte mal testen. Natürlich sollten alle bisherigen Logiken unverändert funktionieren.

VG, Fry