Die Option rrd=>... trägt immer den Wert ins rrd ein, der gesendet wurde. Nicht den, der empfangen wurde. Für deine Anwendung ist also die Logik mit explizitem update_rrd die einzig Richtige.
-
-
-
Hallo zusammen,
nachdem das mit Elabnet leider noch etwas dauert und ich nun mein Haus bezogen hab, mach ich mich nun doch manuell noch dran die Patches von Fry alle einzubauen.
Habe nun schon fast alles aus Frys letzten geposteten WG.zip installiert bekommen und auch am Laufen, nur nun gibt es beim Logikprozessor noch folgende Fehlermeldung:
Can't locate Frontier/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 26) line 1647. BEGIN failed--compilation aborted at (eval 26) line 1647.
Was fehlt hier? Muß ich evtl. noch irgendein perl Update machen?
Für alle die auch noch Installieren wollen hier die Einzelschritte die ich bisher ausgeführt habe:
- letzte wg.zip von Fry hier aus dem Thread ins WG root kopieren und umbenennen in WG.tgz (mit WinSCP)
- per Terminalzugriff den Befehl ausführen:
tar zxvf WG.tgz
- in webmin von WG den wiregeate Serverprozess "wiregated.pl" neu starten
- in Logikprozessor die sub samurai auskommentieren oder löschen falls man die SMS Funktion nicht benötigt
- In webmin über Pluginseite die Config files der Plugins bearbeiten/anpassen (Die Beispielkonfig muß an einigen Stellen auskommentiert werden bzw. durch eigene Logiken ergänzt werden)
Danke an Fry für das tgz file, das macht die Installation eigentlich echt super einfach! Nun muß nur noch der o.g. Fehler verstanden und behoben werden...
Gruß
AndiGruß
AndiKommentar
-
Das liegt an der Samurai-Funktion. Such mal hier im Forum nach "Frontier" dann solltest du es finden. Kurzform: wenn du den SMS-Versand nicht brauchst, kannst du die Samurai-Funktion in Logikprozessor.pl einfach löschen.Zitat von tger977 Beitrag anzeigen
VG
MichaKommentar
-
Hallo Micha,
danke für die prompte Antwort.
Habe nun die samurai sub mal auskommentiert. Damit ging es dann.
Habe die Anleitung oben entsprechend angepasst damit sich vielleicht weiter Leute leichter tun...
Jetzt werd ich mal mit Logiken anfangen...
Gruß
AndiGruß
AndiKommentar
-
Hallo zusammen,
hier mal wieder ein einfaches Anwendungsbeispiel des Logikprozessors, der neuere Funktionen nutzt und deshalb auch nur mit der letzten Version funktioniert:
Steuerung der Warmwasser-Zirkulationspumpe
Die GA-Kuerzel bedeuten:Code:# Zirkulation mit Praesenz im Bad anschalten $logic{Zirkulation_D2}={ trigger=>'PI_D2==1', transmit=>'SW_HE_Zirkulationspumpe', translate=>1, }; # Zirkulationspumpe 3min nach dem Lauf stoppen und sperren $logic{Zirkulation_gelaufen_sperren}={ trigger=>'SM_HE_Zirkulationspumpe==1', transmit=>['SW_HE_Zirkulationspumpe','SS_HE_Zirkulationspumpe'], translate=>0, delay=>'3min' }; # Sperre 1h spaeter, sowie bei Initialisierung, freigeben $logic{Zirkulation_wieder_frei}={ trigger=>'SS_HE_Zirkulationspumpe==0', transmit=>'SS_HE_Zirkulationspumpe', translate=>1, delay=>'1h', transmit_on_startup=>1, }; # Zirkulationspumpe vorzeitig ausschalten, falls Temp-sensor>35 Grad $logic{Zirkulation_warm_aus}={ trigger=>'TO_BA_Zirkulation>35', transmit=>['SW_HE_Zirkulationspumpe','SS_HE_Zirkulationspumpe'], translate=>0, };
PI_D2: Praesenz im Bad (1 bei Praesenz, 0 bei Abwesenheit)
SW_HE_Zirkulationspumpe: Steuerung des Schaltaktors fuer die Steckdose der WW-Zirkulationspumpe (1 an, 0 aus)
SM_HE_Zirkulationspumpe: Rueckmeldung des Schaltaktors fuer die Steckdose der WW-Zirkulationspumpe (1 an, 0 aus)
SS_HE_Zirkulationspumpe: Sperre des Schaltaktors fuer die Steckdose der WW-Zirkulationspumpe (0 gesperrt, 1 frei)
TO_BA_Zirkulation: Temperatursensor am Rohr der WW-Zirkulation an dem Punkt, der von der Zirkulationspumpe am weitesten entfernt ist
(Natürlich kann und sollte man Teile der Funktionalität direkt in KNX abbilden, so zB mit der Treppenlichtfunktion des Aktors. Dieses hier dient als Beispiel einer Logik und ist daher moeglichst komplett)
Have fun,
FryKommentar
-
Das mit dem Trigger hatte ich in der Beispielconfig gelesen, aber durch so ein Beispiel werden einem immensen die Möglichkeiten erst mal vor Augen geführt...Zitat von Fry Beitrag anzeigen
Den Wert gleich dort als Bedingung mit ein einzubauen ist schon sehr charmant. Für receive und fetch geht das aber nicht, oder?
VG
MichaKommentar
-
Nein, das ist speziell für trigger. trigger erlaubt darüber hinaus noch Mehrfachnennung und Modifikatoren wie 'any', 'all' und 'within 2min'.
"trigger" habe ich eingebaut, weil ich Sequenzen brauchte. Wenn die Haustür geschlossen wird, DANACH die Garagentür geöffnet und geschlossen und DANACH das Garagentor auf und zu geht, dann führe XYZ aus.
Sowas in der Art.
Kurz gesagt:
receive löst die Logik aus und wird (bei mehreren Adressen) per knx_read abgefragt
fetch löst die Logik NICHT aus, wird aber bei Ausführung per knx_read abgefragt.
trigger ist der Schlussstein: er ruft niemals knx_read auf, aber löst die Logik aus.
Übrigens ist der Logikprozessor jetzt ziemlich komplett und der Code stabil. Ich habe vor, nicht mehr viel zu ändern.
Was sich noch lohnen könnte: den wiregated.pl per fork() in zwei Prozessen laufen zu lassen: einen für die Plugins (Logiken usw.) und einen für den Rest (1wire).Kommentar
-
Registriert, ich wäre auch für eine Parallelisierung, lasse ich prüfen.Zitat von Fry Beitrag anzeigen
StefanKommentar
-
@ Fry:
Erst mal nochmals vielen Dank für den Logikprozessor - er leistet schon eine Weile ganz solide seine Dienste.
Ein feature hätte ich gerne noch abgebildet und zwar sonnenstandsabhängige Schaltvorgänge (um z.b. x minuten vor Sonnenuntergang bestimmte Jalousien runterzufahren etc.). Die timer Logiken können das doch bisher nicht abbilden oder? Bisher löse ich das Ganze mit emx_uhr und emx_sonne aus dem svn. Bei emx_uhr gibt es allerdings ein memleak-Problem, was bisher nicht gelöst ist. Ich wollte gerne alles in den logikprozessor "transferrieren".Viele Grüße JensKommentar
-
Die Berechnung des aktuellen Sonnenstandes habe ich in einer Logik implementiert (und hier auch schon gepostet). Die Berechnung des Sonnenuntergangs- und aufgangszeitpunkts ist selbstverständlich in einer Logik möglich, und man kann damit auch Timer setzen (praktisch ist die relativ neue "followup"-Funktion).
Als Kernfunktion im Logikprozessor ist so eine Funktion aber nicht geeignet. Zu speziell. Ich werde auch den Samurai wieder rauswerfen, und wie schon mehrfach gesagt wuerde ich auch vorschlagen, die Prowl-Funktion in eine ganz normale Funktion zu stecken, sie macht sonst den Code des LP unnötig kompliziert.
Aber aktuell fasse ich den LP sowieso kaum mehr an. Er wird ja nun von ein paar Leuten genutzt, da möchte ich nicht mehr viel ändern, damit nicht vorhandene Logiken zerbrechen.
VG, FryKommentar
-
Hier nochmal die Sonnenstandsberechnung, duerfte relativ leicht sein, daraus was zu bauen...
Code:### Sonnenstandsberechnung ############################################################################################# $logic{Sonnenstand}={ transmit=>'QA_Sonnenaufgang', translate=>sub{ # Geografische Breite (positiv=Nord) und Laenge (positiv=Ost) in Grad my $lat = 50.; my $lon = 10.; # mittlere Ortszeit in Stunden. Dies ist die "Greenwich-Zeit" mit exakter Zeitzone auf diesem Laengengrad my $MOZ = strftime("%H",gmtime())+$minute/60.+$lon/15; # wahre Ortszeit. Beruecksichtigt die Exzentrizitaet der Erdbahn. # 12 Uhr entspricht hier dem Sonnenhoechststand (genau im Sueden) des Tages my $WOZ = $MOZ-0.171*sin(0.0337*$day_of_year+0.465)-0.1299*sin(0.01787*$day_of_year-0.168); my $tau = ($WOZ-12)/12*3.1416; # Stundenwinkel der Sonne # Deklination der Sonne beim Hoechststand des Tages im Bogenmass # dies ist der Breitengrad, an dem die Sonne durch den Zenit geht my $dek = 0.4095*sin(0.016906*($day_of_year-80.086)); # Aktuelle Elevation der Sonne in Grad. Die Erdachse ist um 23.44 Grad geneigt $lat/=57.29578; # Umrechnung in Bogenmass my $arg = cos($tau)*cos($lat)*cos($dek)+sin($lat)*sin($dek); my $elev = 57.29578*asin($arg); # Aktueller Azimut der Sonne, 180 Grad ist Sueden my $N=-sin($tau)*cos($dek); my $D=sin($dek)*cos($lat)-cos($tau)*cos($dek)*sin($lat); my $azim = 57.29578*atan($N/$D); $azim += $N<0?-180:180 if $D<0; # Emulation atan2 $azim += 360 if $azim<0; # Variable Tag/Nacht schreiben und auf Bus senden, andere Plugins/Geraete koennen das nutzen my $aufgang=undef; if(defined $elev) { my $day=($elev>=0); $aufgang=$day if $day!=$plugin_info{'Logik_day'} && abs($elev)<3; # Sonnenauf- oder untergang $plugin_info{'Logik_day'}=$day; $plugin_info{'Logik_night'}=!$day; $plugin_info{'Logik_night'}=!$day; } # Auch der Sonnenstand wird zusaetzlich in einer Variable gespeichert $plugin_info{'Logik_sun'}=sprintf("%d;%d",$azim,$elev); $plugin_info{'Logik_sun_azim'}=$azim; $plugin_info{'Logik_sun_elev'}=$elev; # Auf Bus schreiben knx_write('QA_Azimuth',int($azim)); knx_write('QA_Elevation',int($elev)); return $aufgang; }, timer=>{ time=>'00:00+5min' }, transmit_on_startup=>1, reply_to_read_requests=>1, };Kommentar
-
Da muss ich nochmal einhaken...Zitat von Fry Beitrag anzeigen
Ich habe bei mir auch auf Basis des Sonnenuntergangs die Rollläden gesteuert, einer 10min nach Sonnenuntergang, einer 20min usw alles per emx_uhr. Jetzt hätte ich aber gerne eine feste Zeit, wann der Rollladen definitiv runter gehen soll (bspw 21 Uhr) - das habe ich bisher per LP nicht hinbekommen.
Folgendes habe ich versucht:
Funktion "sonnUntOderZeit" prüft, ob die Sonnenuntergangszeit plus Parameter1 (AdditionalTime) oder den Parameter2 (LastTime) bereits erreicht sind und gibt dann entsprechend 0 oder 1 zurück, "sonnAufUndZeit" aber genauso nur anders ;-)Code:#bei Sonnenuntergang, spätestens aber 21:00 Uhr runter EG_Wohnen_Jalousie_ab => { transmit=>'1/1/4', timer=>{ time=>'00:00+5m' }, eibd_cache=>86400, transmit_changes_only => 1, translate => sub { return unless &sonnUntOderZeit(0.4, '21:00'); 1}, debug=>1}, #bei Sonnenaufgang, frühestens aber 07:00 Uhr rauf EG_Wohnen_Jalousie_auf => { transmit=>'1/1/4', timer=>{ time=>'00:00+5m' }, eibd_cache=>86400, transmit_changes_only => 1, translate => sub { return unless &sonnAufUndZeit (0.2, '07:00'); 0}, debug=>1},
Problem dabei ist, dass ich nach 21 Uhr nicht mehr aufmachen kann, weil dann immer wieder ein Telegramm mit Runter geschickt würde. Was ich also bräuchte wäre eine Logik die "timer=>{time=>'SonneruntergangOder2100'}" heißt oder eine Logik die sich für den Rest des Tages selbst deaktiviert.
Jetzt habe ich versucht zu verstehen, was du mit "followup" gemeint/gemacht hast, hat aber nicht geklappt
Kannst du mir mal einen Denkanstoß dazu geben.
Grüße
DavidKommentar
-
Ich habe jetzt mal noch etwas mit dem Trigger rumgespielt:Zitat von mivola Beitrag anzeigen
Das führt leider nicht zum gewünschten Erfolg (Ausführung nur dann, wenn aktueller Wert ==1 und zuvor muss der Wert anders gewesen sein). Lt. meinem Verständnis liegt dies an der Tatsache, dass die Werte der Trigger-GAs nicht in $input übernommen werden, oder?Code:fahrsperreAus => { trigger=>'5/2/51==1', transmit=>'3/2/27', execute_on_input_changes_only=>1, translate => 0, debug=>1 },
Es funktioniert wie gehabt mit receive, aber das ist etwas aufwändiger in der translate-Logik:
@Fry: gibt es noch eine elegantere Möglichkeit die Vorteile der beiden Lösungen zu vereinen?Code:fahrsperreAusWennTuerEZzu => { receive=>'5/2/27', transmit=>'3/2/27', execute_on_input_changes_only=>1, translate => sub { return ($input==1 ? 0 : undef); }, debug=>1 },
Danke,
MichaKommentar
-
Und gleich noch eine Frage: ich möchte eine Logik starten wenn sich die GA1 ändert (Wert wird 0). Aber nur, wenn zuvor (innerhalb von zb 10sek) nicht auf GA2 ein Wert gesendet wurde. Also im Prinzip bräuchte man für trigger noch etwas wie:
Oder kann man das auch anders lösen?Code:trigger=>[[COLOR="Red"][B]![/B][/COLOR]'GA2==ANY', 'GA1==0', 'within 10s', 'all_in_order']
Danke,
MichaKommentar
Kommentar