[wiregate] Suche eine Programier-Leitfaden speziell für wiregate?

[lo4dro]

Hallo Kollegen,

ich such für meine eigene Programmierexperimente einige Infos:

- eine Übersichtsliste, über alle globalen Variabeln, die auch in eigene Erweiterungen genutzt werden können, oder nicht dürfen.
- wenn man $plugin_info{$plugname.'_cycle'} weg lässt, wird dann das Plugin kontinuierlich ausgeführt?
- wie startet das Plugen, wenn es auf Änderungen von einem GA Regieren soll.
- wie speichert man eigen Zwischenwerte richtig? z.B. Vergleich von Messwerte auf eine Veränderung?
- wie liest man die werte aus dem Bereich config. Einfach Datei öffnen open(CONF, $confFile); ...

[makki]

Hallo Kollegen,

ich such für meine eigene Programmierexperimente einige Infos:

Nun, einiges steht in der Hilfe bzw. den Anleitungen hier, aber die konkreten Fragen versuche ich mal kurz zu beantworten:

- eine Übersichtsliste, über alle globalen Variabeln, die auch in eigene Erweiterungen genutzt werden können, oder nicht dürfen.

Grundsätzlich darf (und kann!) man alles benutzen. Man muss sich nur über die Auswirkungen im klaren sein, also am besten an vorhandenen Plugins anlehnen.
-> Gedacht dafür ist primär $plugin_info (eigentlich %plugin_info, ein hash)

Data::Dumper

dürfte die beste Antwort liefern Sorry..

- wenn man $plugin_info{$plugname.'_cycle'} weg lässt, wird dann das Plugin kontinuierlich ausgeführt?

ja, Default ist 60 Sekunden, minimum 30
$plugin_info{$plugname.'_cycle'} = 0;
deaktiviert den zyklischen Aufruf.

- wie startet das Plugen, wenn es auf Änderungen von einem GA Regieren soll.

$plugin_subscribe{"x/y/z"}{$plugname} = 1;
x/y/z ist die GA, fertig.

- wie speichert man eigen Zwischenwerte richtig? z.B. Vergleich von Messwerte auf eine Veränderung?

$plugin_info{$plugname.'_MEINEVariable'}

- wie liest man die werte aus dem Bereich config. Einfach Datei öffnen open(CONF, $confFile); ...

Dazu enthalte ich mich ehrlichgesagt, weil ich rein garnichts davon halte.. Es geht, es ist hier beschrieben, war aber nie so gedacht;
$plugin_info ist ebenso persistent und sogar zum ablegen komplexer Strukturen geeignet: siehe http://sourceforge.net/p/openautomat...toreComplex.pl

Grüsse Makki

[lo4dro]

Vielen Dank, werde mit diesen Infos mal meine ersten Versuche starten.
Das mit

Data::Dumper

kannte ich nicht, scheint eine mächtige Funktion zu sein

[XueSheng]

@lo4dro: Wenn Du die ersten Hürden in Perl genommen hast und das Verhalten der Plugins besser verstehen willst, macht ein Blick in die wiregated.pl Sinn... dann wird einiges klarer.

[SARKASMUS]
Alternativ kannst Du auf das nächste, größere Wiregate Update warten, dann kannst Du die Plugin Dokumentation käuflich erwerben .
[/SARKASMUS]
@StefanW: Tut mir leid, aber den Seitenhieb konnte ich mir an dieser Stelle (mal wieder) nicht ersparen und bitte gleichzeitig um Verzeihung für den nicht angebrachten Kommentar.

Das wichtigste hat Makki bereits genannt. Ergänzend dazu:
Wenn Du Werte nicht persistent in $plugin_info speichern möchtest, kannst Du alternativ auch $plugin_cache verwenden. Vorteil: ist schneller, wenn man viele Werte speichen will. Ebenso lassen sich $hash_ref und $array_ref ohne Umwege speichern. Nachteil: Bei einem wiregated restart sind alle Werte weg! Also nur für das kurzzeitige Zwischenspeichern von Werten/Datenstrukturen geeignet.

Bei Bedarf kannst Du anstatt $plugin_subscribe auch $plugin_subscribe_read bzw. $plugin_subscribe_write verwenden. Dann wird Dein Plugin nur bei einem Lese- bzw. Schreibtelegramm aufgerufen.

Eine weitere Optimierung kannst Du mit der Verwendung von #COMPILE_PLUGIN vornehmen (hat bei dem ein oder anderen nicht nachvollziehbaren Speicherleck schon Wunder bewirkt). Einfach mal danach suchen, wenn Dich das interessiert.

[lo4dro]

Vielen Dank für die vielen Infos,

ich habe mich jetzt ein bisschen eingearbeitet.

Anhand von anderen Plugin Beispielen habe ich eine einfach Regelung erstellt.
- Ich lese eine Temperatur ein
- Prüfe ob $plugin_cache{$plugname.'_rollozu'} = 0; ist
- Prüfe Temp > Sollwert dann schreibe knx Wert
- sichere den Vorgang mit "$plugin_cache{$plugname.'_rollozu'} = 1;"

Das ganze funktioniert dann einmal, weil danach ist ja die Variable $plugin_cache{$plugname.'_rollozu'} = 1
Nun würde ich gerne diesen Wert nach jedem Editieren wider auf 0 setzen.

Habe aber keine Lösung anhand der Beispiele gefunden.
Diesen Code habe ich mal als Grundlage benutzt.

# 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 (%msg) { $event='bus'; return if !$config_modified && $msg{apci} eq "A_GroupValue_Response"; } # Bustraffic
#elsif ($fh) { $event='socket'; } # Netzwerktraffic
else { $event='cycle'; } # Zyklus

Wenn ich jetzt auf $event='modified' prüfe, sollte das doch passen?

[XueSheng]

Wenn ich jetzt auf $event='modified' prüfe, sollte das doch passen?

Genau, das entspricht dem Fall, dass Du das Plugin gespeichert hast.

Ich habe zwar nicht verstanden, was Du umsetzen möchtest, aber überlege Dir auch was passieren soll/darf, wenn wiregated mal neugestartet wird (aus welchem Grund auch immer). Dein $plugin_cache ist dann leer! Nur wenn das für Deinen Anwednungsfall ok ist, macht die Verwendung von $plugin_cache sinn.

Um künftig besser mit der Auswertung von $plugin_cache spielen zu können, kannst Du das auch folgendermaßen nutzen:

$plugin_cache{$plugname}{value} = 1234;
$plugin_cache{$plugname}{string} = "text";
$plugin_cache{$plugname}{hashref} = \%hash;

Bei komplexeren plugins kannst Du dann die vorhandenen keys des cache durchlaufen:

for (keys %{$plugin_cache{$plugname}}) {
   plugin_log($plugname, "key found: $_");
}

[makki]

Ich kann XueSheng nur beipflichten, einige Anmerkungen:
- der wiregated kann auch "unerwartet" restartet werden (mem-leak, Stromausfall, ...) -> Also immer damit rechnen, daher sollte sich bei "einfachen" Sachen an $plugin_info halten, denn dort spielt es keine Rolle, man muss sich nicht darum kümmern, wann, warum oder weshalb der restart erfolgte..

Makki

[lo4dro]

das mit dem Cache passt mir ganz gut, es ist n dieser Stelle aus meiner Sicht sogar besser.

[lo4dro]

@XueSheng

Danke für deine Tipps.
Ich habe das ganze für mich verständlich umgeschrieben und nun tut auch der Reset.

#Prufen warum das Script gestartet wurde und Variabeln zurücksetzen
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 (%msg) {
     $event='bus'; # Bus
} elsif ($fh) {
    $event='socket'; # Netzwerktraffic
} else {
    $event='cycle'; # Zyklus
}
if ($debug == 1){
    plugin_log($plugname, "1 - Event: ".$event)
}

if ($event eq 'modified') {
  $plugin_cache{$plugname.'_rollozu'} = 0;
  if ($debug == 1){
    plugin_log($plugname, "1a - Reset Variable _rollozu : ".$plugin_cache{$plugname.'_rollozu'})
  }
}

Wenn man jeden Tag um 2 Uhr morgens die Variabeln zurücksetzen möchte, muss man dann eine eigene Datumsfunktion Programieren oder gibts hierfür auch schon was vordefiniertes? Die Uhrzeit ist egal, solange das abends zwischen 23 und 5 Uhr liegt.

[XueSheng]

Mmmmh... Ich kann mich da dunkel an einen Thread erinnern, der sich mit der Thematik Uhrzeit und Pluginausführung beschäftigt hat. https://knx-user-forum.de/forum/suppo...rst-einstellen

Stimmt, war ja Dein Thread, lo4dro . Ein bisschen faul bist Du schon oder?

[lo4dro]

XueSheng,

hast mich eiskalt erwischt.
Ich bin etwas vergesslich allerdings wollte ich wissen, ob es ein Wiregate integriertes Bordmittel gibt, so wie das mit den ganzen anderen geheimen Registern, die ich bis jetzt erfahren habe.
Werde wohl meine eigene Idee umsetzen *g*

[lo4dro]

Wenn die Temperatur den Sollwert überschritten hat, werden die Rollos geschlossen.
Und eine Sperrvariable gesetzt. Damit die Aktion nur einmalig ausgeführt wird.
Nun soll aber Nachts diese Sperrvariabel zurückgesetzt werden.
Aus diesem Grund setzte ich $plugin_info{$plugname.'_cycle'} = 3600;
Das Script wird also jede Stunde einmal gestartet und Prüft auf die Uhrzeit
So weit funktioniert das.
Damit das Script nicht unnötig gestartet wird, steht beim Initalisieren der _cycle auf 0 und erst wenn die Rollos geschlossen werden wird _cycle auf 3600 gesetzt.
Nachts wird _cycle und Sperrvariabel wider auf 0 gesetzt.

Ist dieser Ansatz so richtig, oder geht das besser bzw. schöner?

[XueSheng]

Ich versuche mal Dein Vorhaben zu verstehen. Das ist ehrlich gesagt nicht ganz einfach, da die Informationen etwas konfus erscheinen. Ich bitte Dich meine Aussagen/Fragen zu prüfen/beantworten. Danke.

Wenn die Temperatur den Sollwert überschritten hat, werden die Rollos geschlossen.
Und eine Sperrvariable gesetzt. Damit die Aktion nur einmalig ausgeführt wird.

Es geht also um eine Automatisierung der Beschattung in Abhängigkeit von der Temperatur.
Ist hier die Außentemperatur oder Innentemperatur gemeint? Die Temperatur ist vielleicht nicht der beste Indikator für die Notwendigkeit einer Beschattung (Global-/Solarstrahlung oder evtl. auch Helligkeit wären vermutlich besser geeignet).
Das Plugin soll also auf Temperaturveränderungen reagieren und bei Überschreiten eines Grenzwertes ein Beschattungstelegramm senden?

Nun soll aber Nachts diese Sperrvariabel zurückgesetzt werden.
Aus diesem Grund setzte ich $plugin_info{$plugname.'_cycle'} = 3600;
Das Script wird also jede Stunde einmal gestartet und Prüft auf die Uhrzeit
So weit funktioniert das.

Hast Du einen Status für Tag/Nacht? Oder Status Rollladenautomatik hoch/runter? Dies könnte auch für das Triggern der Sperre geeignet sein.

Damit das Script nicht unnötig gestartet wird, steht beim Initalisieren der _cycle auf 0 und erst wenn die Rollos geschlossen werden wird _cycle auf 3600 gesetzt.
Nachts wird _cycle und Sperrvariabel wider auf 0 gesetzt.

Alternativ könntest Du auch gleich den passenden _cycle bis zum nächsten Start berechnen. Oder eben den Status für Tag/Nacht, dann kannst Du auf den _cycle komplett verzichten.

Ist dieser Ansatz so richtig, oder geht das besser bzw. schöner?

Viele Wege führen nach Rom. Allerdings kennen wir nach wie vor nicht Deinen Plugin-Code. Es ist also schwer zu sagen, was Du im Detail besser machen könntest. Als erstes würde ich den Input für das Plugin in Frage stellen. Temperatur für Beschattung? Fixe Uhrzeit für Reset? Keine Berücksichtigung von Sonnenstand oder absoluten Messwerten wie Globalstrahlung oder Helligkeit?

[lo4dro]

Es geht also um eine Automatisierung der Beschattung in Abhängigkeit von der Temperatur.
Ist hier die Außentemperatur oder Innentemperatur gemeint? Die Temperatur ist vielleicht nicht der beste Indikator für die Notwendigkeit einer Beschattung (Global-/Solarstrahlung oder evtl. auch Helligkeit wären vermutlich besser geeignet).
Das Plugin soll also auf Temperaturveränderungen reagieren und bei Überschreiten eines Grenzwertes ein Beschattungstelegramm senden?

Beschattung ist falsch, es geht darum, das die Raumtemperatur unter dem Dach (Dachfenster) nicht zu hoch werden soll.
In den letzten Jahren hat sich hier gezeigt, das wenn die Rollos bei einer Ausentemp von >24 °C geschlossen werden die Raumtemperatur stabil bleibt.

Ich habe (bis jetzt) auch keine anderen Sensoren, wie z.B. Helligkeit

Hast Du einen Status für Tag/Nacht? Oder Status Rollladenautomatik hoch/runter? Dies könnte auch für das Triggern der Sperre geeignet sein.

Solche ein Status habe ich bis jetzt nicht.

Alternativ könntest Du auch gleich den passenden _cycle bis zum nächsten Start berechnen. Oder eben den Status für Tag/Nacht, dann kannst Du auf den _cycle komplett verzichten.

Die Idee ist auch sehr gut, muss mir überlegen, wie ich das berechne.