Neues Plugin: Logikprozessor.pl

[Tulkas]

Hallo Micha,

vielen Dank für die schnelle Antwort. Ich habe es jetzt auch über die Translate-Funktion umgesetzt. Es ist halt leider etwas unübersichtlich, da der Timer starr aufgerufen wird, auch wenn er nichts zu tun hat. Schöner wäre es, ihn komplett deaktivieren oder die Ausführung von einer externen Variable oder GA abhängig machen zu können. Aber letztendlich funktioniert es, und das ist natürlich das Wichtigste.

Einen guten Start ins neue Jahr!
Manfred

[Tulkas]

Hallo mal wieder,

nach all den Jahren habe ich wieder eine Frage zum Logikprozessor. Ich verwende ein followup innerhalb der translate-Funktion und möchte diesen in manchen Fälle auch wieder löschen. In der Beispielkonfiguration steht dazu:

# Moechte man die evtl. laufenden followup-Timer loeschen, geht wieder ein einfaches return 'cancel', wie schon bei der Option delay.

# Verwendung von followup als Funktion: im Unterschied zur timer-Option laesst sich ein followup-Timer
# auch innerhalb einer translate-Funktion ausfuehren:
Tuer1_oeffnen => { transmit=>'Tuer1', translate=>sub { followup({'Tuer2_oeffnen'=>2, debug=>1}); }, },
# Dies geht ohne jedwede Einschraenkung. Zum Debuggen kann man dem followup-Hash noch eine Option debug=>1 mitgeben, wie oben gezeigt.​

Trotz return 'cancel' wird das followup bei mir jedoch nach wie vor ausgeführt. Funktioniert dies evtl. nicht, wenn followup innerhalb von translate verwendet wird? Falls ja, gibt es eine andere Möglichkeit, diesen gesetzten Timer zu löschen?

Ich kann das Problem mit einem in $plugin_info hinterlegten Status umgehen, den ich dann in der followup-Funktion prüfe, aber mich würde interessieren, ob man den Timer nicht auch, wie angenommen, vollständig löschen kann.

Danke und Grüße
Manfred

[Fry]

Hallo mal wieder,

nach all den Jahren habe ich wieder eine Frage zum Logikprozessor. Ich verwende ein followup innerhalb der translate-Funktion und möchte diesen in manchen Fälle auch wieder löschen. In der Beispielkonfiguration steht dazu:

# Moechte man die evtl. laufenden followup-Timer loeschen, geht wieder ein einfaches return 'cancel', wie schon bei der Option delay.

# Verwendung von followup als Funktion: im Unterschied zur timer-Option laesst sich ein followup-Timer
# auch innerhalb einer translate-Funktion ausfuehren:
Tuer1_oeffnen => { transmit=>'Tuer1', translate=>sub { followup({'Tuer2_oeffnen'=>2, debug=>1}); }, },
# Dies geht ohne jedwede Einschraenkung. Zum Debuggen kann man dem followup-Hash noch eine Option debug=>1 mitgeben, wie oben gezeigt.​

Trotz return 'cancel' wird das followup bei mir jedoch nach wie vor ausgeführt. Funktioniert dies evtl. nicht, wenn followup innerhalb von translate verwendet wird? Falls ja, gibt es eine andere Möglichkeit, diesen gesetzten Timer zu löschen?

Ich kann das Problem mit einem in $plugin_info hinterlegten Status umgehen, den ich dann in der followup-Funktion prüfe, aber mich würde interessieren, ob man den Timer nicht auch, wie angenommen, vollständig löschen kann.

Danke und Grüße
Manfred

Probiere mal followup({'Tuer2_oeffnen'=>'cancel'});
LG Fry

[Tulkas]

Super, genau das ist die Lösung, vielen Dank für die schnelle Antwort und ein schönes Wochenende!

[Tulkas]

Hallo, ich habe diesmal eine Frage, die nur zum Teil mit dem Logikprozessor zu tun hat. Bei der Zeitumstellung werden die Timer-Logiken nicht automatisch neu berechnet, so dass morgens die Zeiten für z.B. die Rollläden und die Heizung nicht stimmen. Eine einfache Maßnahme ist es, den Logikprozessor neuzustarten, deshalb habe ich im Wiregate einen Cronjob eingerichtet, der dass jeweils in der Nacht des letzten Sonntags im März und Oktober per "touch Logikprozessor.pl" erledigt. Das ganze wird auch korrekt ausgeführt (die zusätzliche Mitteilung wird versendet und das Datum des Logikprozessors passt zur Uhrzeit), jedoch wird der Logikprozessor dadurch nicht neugestartet (die in diesem Fall eingerichtete Nachricht wird nicht versandt). Der Grund ist mir ein Rätsel, denn ein manuell ausgeführtes "touch" führt jedes Mal zu einem Neustart. Deshalb stellen sich mir folgende Fragen:

1. Gibt es einen eleganteren Weg, die Timer nach der Zeitumstellung anzupassen?
2. Warum führt ein manuelles "touch" zuverlässig zum Neustart, nicht jedoch im Zuge eines Cronjobs?
3. Gibt es einen anderen Weg, ein Wiregate-Plugin per Cronjob neuzustarten?

Danke vorab und Grüße,
Manfred

[wuestenfuchs]

2. Warum führt ein manuelles "touch" zuverlässig zum Neustart, nicht jedoch im Zuge eines Cronjobs?

Unter welchem Benutzer läuft der Cronjob, oder besser noch: stell mal deinen kompletten Cronjob hier rein!

Und füge bitte noch die Dateirechte vom Logikprozessor dazu:

ls -l Logikprozessor.pl

[Tulkas]

Hallo,

den Cronjob habe ich in der Crontab von root eingetragen:

root@wiregate:~# crontab -l

30     4     *     3,10  0   /root/bin/last_weekday_in_month.sh && touch /etc/wiregate/plugin/generic/Logikprozessor

Das Skript prüft nur, ob es der letzte Sonntag im Monat ist:

root@wiregate:~# cat /root/bin/last_weekday_in_month.sh

#!/bin/bash
# Falls der aktuelle Tag im Monat +7 kleiner als 8 ist
if [ $(date +%d -d '+7 days') -lt '8' ] ; then
  exit 0
else
  exit 1
fi

Die Datei wird auch korrekt angefasst:

root@wiregate:~# ls -l /etc/wiregate/plugin/generic/Logikprozessor
-rw-r--r-- 1 root root 60k 30. M�r 04:30 /etc/wiregate/plugin/generic/Logikprozessor

Wenn ich den Befehl manuell als root ausführe, wird die Datei angefasst und der Logikprozessor neu gestartet. Im Cronjob hingegen bleibt der Neustart aus.

[wuestenfuchs]

Steht der Shebang auch wirklich in der ersten Zeile deines Scripts, also in Zeile 1?

[Tulkas]

Ja, ich hatte die Leerzeile nur zur optischen Abtrennung eingefügt. Nach dem touch folgt in der Crontab auch noch ein curl zur Benachrichtigung per Ntfy, das wird auch alles korrekt ausgeführt. Ich habe auch testweise sowohl das touch als auch curl in das Skript verlagert, so dass in der Crontab wirklich nur noch der Aufruf des Skripts steht, ohne folgendes &&. Aber all das hat am Verhalten nichts geändert: Die Befehle werden ausgeführt, trotzdem startet das Plugin nicht neu.

Test-Aufruf per Cron: 30 4 * 3,4,10 0,1,2 /root/bin/zeitumstellung.sh

#!/bin/bash
# Dieses Skript wird nur an Sonntagen im März und Oktober aper Cronjob ufgerufen und prüft dann, ob es der letzte Sonntag im Monat ist oder nicht.

# Falls der aktuelle Tag im Monat +7 kleiner als 8 ist
if [ $(date +%d -d '+7 days') -lt '8' ] ; then
  echo "Letzter Sonntag im Monat"
  touch /etc/wiregate/plugin/generic/Logikprozessor
  curl -H 'Title: Zeitumstellung' -H 'Priority: default' -d 'Geplanter Neustart des Logikprozessors zur Zeitumstellung.' 10.1.2.3:8123/WireGate-Debug
  exit 0
else
  echo "Nicht der letzte Sonntag im Monat"
  curl -H 'Title: Zeitumstellung' -H 'Priority: default' -d 'Nicht der letzte Sonntag im Monat.' 10.1.2.3:8123/WireGate-Debug
  exit 1
fi

[wuestenfuchs]

D.h. ein

ls -l /etc/wiregate/plugin/generic/Logikprozessor

zeigt nach dem Cron-Aufruf des obigen Scripts zeitumstellung.sh das aktuelle Datum und die aktuelle Zeit an, aber der Neustart des Logikprozessors unterbleibt?

[Tulkas]

Exakt, und das kann ich mir nicht erklären.

[Tulkas]

Mittlerweile habe ich noch viel herumexperimentiert, wirklich schlau bin ich dabei jedoch nicht geworden. Bei den Versuchen hat ein simples "touch" auch oftmals funktioniert, alles in allem erscheint mir das Verhalten aktuell nicht-deterministisch, was mir absolut unverständlich ist. Ich habe das Skript nun auf "/etc/init.d/wiregated restart" umgestellt und hoffe, dass es damit zuverlässig laufen wird. Der Punkt ist damit für mich erstmal abgeschlossen, auch wenn ich weiterhin gerne verstehen würde, warum das touch im Cronjob nicht zuverlässig zum Neustart des Plugins führt.