Kleiner Zusatz, man könnte das senden auf den Bus natürlich auch verhindern sofern der Wert sich nicht geändert hat ... ich bin allerdings eher der Freund von zyklischen Telegrammen.
Das müsste dann optional sein, ich lass mir was einfallen.
EDIT:
Momentan müsste man das global so halten, wo sollte sich dass denn optimalerweise Konfigurieren lassen?
Lokale RRDs wären erstmal nicht betroffen, nur wenn man Remote RRDs erzeugen will macht das natürlich keinen Sinn.
Der Ansatz steht.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Plugins auslagern - eBus/KNX Daemon
Einklappen
Dieses Thema ist geschlossen.
X
X
-
Ja ist Geschmackssache. Das Problem liegt da aber im ebusd. Da hab ich aber heute Nacht drüber gegrübelt und mir was überlegt was ich mit Roland mal abklopfen müsste. Das ist dann aber definitiv ein ebusd-Feature.
Ich kann Dir sonst mein WW-Zirkulation-Plugin mal anhängen. Dies beinhaltet auch ein PWM-Modul. Vorgehensweise ist bei mir folgende:
Die Zirkualtionspumpe hängt am Schaltaktor, Spannungsversorgung ist der Ausgang für die Zirkulationspumpe in der Wärmepumpe.
WW-Bereitung ist an der WP folgendermaßen eingestellt: 6:30 - 7:00 und 8:00-22:30. Zirkulationspumpe auf 100%.
In der Woche sind wir bis 8:00 spätestens aus dem Haus, die halbe Stunde von 6:30 bis 7:00 reicht um im Zweifel das Wasser auf Duschtemperatur zu bringen. Verlassen wir das Haus wird über ein zweites Plugin die WW-Betriebsart von "Auto" auf "Aus" gestellt. Der Schaltaktor macht dann zwar weiter sein PWM aber die Zirkulationspumpe bekommt keinen Strom. Bei Vaillant wird die nur zugeschaltet wenn auch die (zeitliche) Freigabe für WW erfolgt.
Damit habe ich dann auch an Feiertagen und bei Krankheit ab 8:00 warmes Wasser. Wenn den ganzen Tag/Wochenende keiner da ist dann wird auch kein WW bereitet. Das sind hier insgesamt 3 Plugins:
- Präsenz
- Zirkulationspumpe
- WW-Modus
Die Präsenz wird über iButtons ausgewertet.
Code:###Zirkulationspumpe ### MAIN ### # Variablen definieren my $time = time(); my $ww; my $zirk_ga = '8/4/1'; #GA Zirkulationspumpe my $praesenz_ga = '0/7/0'; #GA fuer Meldung der Praesenz my $base_time = 60; #Zykuluszeit in Minuten my $on_perc = 7; #Einschaltdauer in Prozent my $ww_ga = '8/6/1'; #GA fuer Statusuebertragung Heizung my $ww_ga_val = '8'; #Wert fuer WW-Bereitung von GA $plugin_subscribe{$ww_ga}{$plugname} = 1; $plugin_info{$plugname.'_cycle'} = 60; ### CHECK WARMWASSERBEREITUNG if (knx_read($ww_ga,300) == $ww_ga_val) { $ww = 1; #plugin_log($plugname, "WW-Bereitung"); }else{} ### MAIN / VERARBEITUNG if ($ww == 1) { #Zirkulation waehrend WW-Bereitung knx_write($zirk_ga,1,1.001); plugin_log($plugname, "WW-Bereitung"); } else { & pwm; #plugin_log($plugname, "PWM"); } return; #-------------S U B S -------------# ### PWM ### sub pwm{ my $on_time = (($base_time/100)*$on_perc); my $off_time = ($base_time - $on_time); $on_time *= 60; #Minuten in Sekunden umrechnen $off_time *= 60; #Minuten in Sekunden umrechnen if ($plugin_info{$plugname.'_state'} eq 'pwm-off') #status = aus { if (($plugin_info{$plugname.'_stat-time'} + $off_time) <= $time) #zyklus aus ist vorbei { #ANSCHALTEN knx_write($zirk_ga,1,1.001); #STATUS = EIN setzen $plugin_info{$plugname.'_state'} = 'pwm-on'; #ANZEIT = jetzt $plugin_info{$plugname.'_stat-time'} = $time; } else { #Senden wiederholen# #knx_write($zirk_ga,0,1.001); } } else {} if ($plugin_info{$plugname.'_state'} eq 'pwm-on') #status = an { if (($plugin_info{$plugname.'_stat-time'} + $on_time) <= $time) #zyklus an ist vorbei { #AUSCHALTEN knx_write($zirk_ga,0,1.001); #STATUS = AUS setzen $plugin_info{$plugname.'_state'} = 'pwm-off'; #AUSZEIT = JETZT $plugin_info{$plugname.'_stat-time'} = $time; } else { #Senden wiederholen# #knx_write($zirk_ga,1,1.001); } } else {} if (($plugin_info{$plugname.'_stat-time'} + $on_time + $off_time) <= $time) #initialisierung { #ANSCHALTEN knx_write($zirk_ga,1,1.001); #STATUS = EIN setzen $plugin_info{$plugname.'_state'} = 'pwm-on'; #ANZEIT = jetzt $plugin_info{$plugname.'_stat-time'} = $time; plugin_log($plugname, "INITIALISIERUNG nach Abwesenheit"); } else {} }
Funktioniert hier wirklich hervorragend. Vielleicht hilft das ein wenig.Code:#WW-Modus #return; my $ww_mode_set_ga = "8/7/200"; my $ww_mode_get_ga = "8/6/200"; my $ww_mode_val_auto = 3; my $ww_mode_val_off = 2; my $praesenz_ga = "0/7/0"; $plugin_subscribe{$praesenz_ga}{$plugname} = 1; $plugin_info{$plugname.'_cycle'} = 30; if (knx_read($praesenz_ga,300,1) == 0){ if (knx_read($ww_mode_get_ga,300,1) == $ww_mode_val_auto) { knx_write($ww_mode_set_ga,$ww_mode_val_off,1); plugin_log($plugname, "WW-Modus aus"); } } else { if (knx_read($ww_mode_get_ga,300,1) == $ww_mode_val_off) { knx_write($ww_mode_set_ga,$ww_mode_val_auto,1); plugin_log($plugname, "WW-Modus auto"); } }
Einen Kommentar schreiben:
-
Ende Februar hatte ich das damalige SVN gezogen. Vor ca. einer Woche habe ich dann knxd runtergeworfen und das knxd-0.1_all.deb aus dem trunc installiert.Zitat von JuMi2006 Beitrag anzeigenPuh ... der verbrät auf dem WireGate 20.00 MB / Tag.
Jetzt weiß ich nicht welche Revision des Plugins da bei Dir vorher drauf war, also müsste man das jetzt noch mal beobachten.
Einen Kommentar schreiben:
-
Vielleicht noch eine Sache, die mir gerade auffällt:
knxd schreib ja zyklisch auf den Bus, unabhängig davon, ob sich ein Wert geändert hat oder nicht.
Jetzt möchte ich z.B. den Betriebsmodus verwenden (plugin_subscribe), um bei WW Speicherladung auch die Zirkulationspumpe laufen zu lassen. Nun wird alle X Sekunden das wiregate Plugin aufgerufen, weil knxd den Betriebsmodus schreibt (obwohl keine Änderung des Modus vorliegt).
Das ist zunächst kein wirkliches Problem, irritiert jedoch etwas, da es doch eher typisch ist Werte nur bei Änderung auf den Bus zu schreiben. Vielleicht ist das auch nur Geschmackssache.
Einen Kommentar schreiben:
-
Puh ... der verbrät auf dem WireGate 20.00 MB / Tag.
Jetzt weiß ich nicht welche Revision des Plugins da bei Dir vorher drauf war, also müsste man das jetzt noch mal beobachten.
Nur so zum Vergleich, der knxd braucht auf dem Pi mit wheezy 0.01 MB / Woche.
Das macht jetzt erstmal nichts ist aber durchaus interessant.
Einen Kommentar schreiben:
-
Hab den knxd seit Ende Februar laufen (mit zwei Wochen Unterbrechung). Bislang habe ich nicht auf den Spreicherverbrauch geachtet. Wenn ich mir die rrd ansehen, sieht es jedoch so aus, als würde knxd regelmäßig neustarten, wenn ca. 20MB voll sind (ich nehme an die Einheit ist MB, rrd im Anhang).Angehängte Dateien
Einen Kommentar schreiben:
-
Wie lange läuft der knxd schon bei Dir? Mich würde mal interessieren wie sich der Speicherverbrauch entwickelt. Dafür müsste es ein RRD geben -> knxd_mem.rrd - es läuft doch bei Dir auf dem WireGate oder? Ich hab das bisher nur auf dem Pi am laufen.
Einen Kommentar schreiben:
-
Habe die Dateien kopiert und sicherheitshalber meine Verlinkung der eibga.conf gelöscht... Läuft!
Danke für die schnelle Hilfe!
Einen Kommentar schreiben:
-
Ich kämpfe gerade mit meinem SVN-Client. Daher mal das Update hier.
knxd.pl --> /usr/sbin
ebusd.pl --> /etc/knxd/plugin
Damit wird nun ein "Read" vom Bus unterstützt und der Wert live ausgelesen. Die GA die angefragt wird muss mit "get" oder "cycle" in der knxd-ebusd.csv geführt sein.
Weiterin sind die unterschiedlichen Arten von $subscribe_plugin eingearbeitet.
Die eibga.conf ist damit für das ebus-Plugin überflüssig. Die DPTs werden jetzt aus der knxd-ebusd.csv ermittelt.
Bitte mal kurz Rückmeldung geben ob es klappt.
GrüßeAngehängte Dateien
Einen Kommentar schreiben:
-
Das ist genauso gelöst wie beim WireGate, ist ja auch nur ein abgespeckter wiregated.pl mit zusätzlichen kleine Features.
Ich hab mir den Code mal angesehen und eine Lösung dafür. Die eibga.conf ist eben ein zentrale Ort der Konfiguration, aber das bekomme ich in diesem Fall umschifft. Du kannst ja auch andere Plugins auf dem knxd laufen lassen.
Einen Kommentar schreiben:
-
In der eibga.conf steht die GA noch nicht drin. Wollte mir den Aufwand zum Testen sparen.
Probier ich später mal aus!
Wenn GA und DPT schon in der csv stehen, warum wird eibga.conf überhaupt benötigt?
Einen Kommentar schreiben:
-
Den knxd musst Du nicht neustarten. Die config wird bei jedem Durchlauf geprüft.
Was allerdings wichtig ist: Die GA sollte in /etc/knxd/eibga.conf eingetragen sein, alternativ einen Symlink auf die /etc/wiregate/eibga.conf herstellen, dann hat man nur eine eibga.conf zu pflegen.
Im laufenden Betrieb kannst Du das log mit folgendem Befehl über die Konsole beobachten:
Da das ganze ein Trigger ist gibt es keine richtige Rückmeldung. Bei Fragen immer her damit, ich komme im Moment neben Garten, Familie und Beruf nicht dazu das alles zu fixen. So ganz glücklich bin ich mir der ganzen Lösung im Moment noch nicht da mir da zu viele Abhängigkeiten drin sind. Evtl. bekomme ich das Plugin noch so gelöst dass es keine eibga.conf braucht. ICh hab ja alles was ich brauche schon in der knxd-ebusd.csv. Sehe ich mir heute Abend mal an.Code:tail -f /var/log/knxd-plugin.log
Einen Kommentar schreiben:
-
Wie kann man eigentlich prüfen, ob ein set Befehl, der über eine Gruppenadresse ausgelöst wurde, auch von knxd wahrgenommen worden ist?
Nachdem nun die WW Speicherladung meiner Geotherm auch über ebusd (telnet) angestoßen werden kann, wollte ich dies nun auch über knxd einbinden.
knxd-ebusd.csv enthält folgenden Eintrag:
knxd habe ich natürlich auch neugestartet, nachdem der Eintrag hinzukam.Code:11/3/149;1;;;set;short hw_load;Quick - WW Speicherladung
Wenn ich eine '1' auf die Gruppenadresse 11/3/149 schicke, passiert jedoch nichts. Wie kann ich prüfen, ob knxd überhaupt das Telegramm wahrgenommen hat?
Einen Kommentar schreiben:
-
AW: Plugins auslagern - eBus/KNX Daemon
Ich hatte eh vor das makki in einem separaten Thread vorzuschlagen.
Die jetzige (meine) Implementierung finde ich allerdings sinniger und macht bestehende Plugins ja auch nicht kaputt. Liegt aber auch darin dass ich kein Fan Flags bin und der Code ohne Zusatzinfos verständlich ist.
Edit: Da $plugin_subscribe ein Hash ist müsste man bei einem zusätzlichen Parameter ziemlich viel im Code wühlen.
Baustelle 2.0
Einen Kommentar schreiben:
-
Zum Teil Offtopic, aber falls Makki mitliest...
Wäre die Aufsplittung für $plugin_subscribe nicht auch was für die Standard Plugins des Wiregate?
Bislang filtere ich read/write/response bei jedem Pluginaufruf. Da muss man sich tatsächlich fragen, ob es Sinn macht, das vorab zentral zu filtern. Von der Reaktionsgeschwindigkeit her wird es vermutlich keinen wirklichen Unterschied machen, aber man könnte Plugins gezielter aufrufen.
Könnte man nicht bei $plugin_subscribe, die übergebene Variable als "flag" interpretieren, um read/write/response zu unterscheiden.
Anstatt 0 bzw. 1 würde man unterscheiden:
read = 1, write = 2, response = 4; read/write wäre folglich 3; write/response wäre 6; default wäre 7 (alles). Quasi in Anlehnung an die Rechtevergabe in Linux.
Wenn man $plugin_subscribe als Variable behalten will und die Abwärstkompatibilität in Betracht zieht, müsste man natürlich einen anderen Zahlenbereich wählen. 0/1 würde seine Gültigkeit behalten und 2/4/8 kämen dazu... wie auch immer, nur ein Denkanstoß.
Einen Kommentar schreiben:


Einen Kommentar schreiben: