Ankündigung

**JuMi2006** · 17.02.2013, 00:20

Dann werde ich morgen mal anfangen den anderen Daemon dahin gehend umzubauen, die Damon config daraus zu stricken und dann die RRD einzubauen.

Danke und Gruß

**JuMi2006** · 17.02.2013, 10:53

Roland, eine kurze Frage.
Die Anzahl der Elemente wird ja mit angegeben - finde ich gut und macht die Verarbeitung leichter.

Wie stellst Du Dir die Verabeitung bei mehreren Elementen vor?

Beispiel 1:
Einen Temperatursensor kann ich z.B. mit

Code:

get mv at_temp
get mv at_stat

nach Temperatur und Status befragen, um den Rest kümmert sich der ebusd.

Beispiel 2:
Den Ferienzeitraum frage ich auch mit den einzelnen Befehlen ab?

Code:

get ci holiday_period start1
get ci holiday_period start2
get ci holiday_period end1
get ci holiday_period end2

Beispiel 3:
Jetzt möchte ich einen Ferienzeitraum verändern, hier muss ich nun alle 4 Daten in einem Paket versenden. Wie stelle ich das an?

Code:

set ci holiday_period ....

Grüße

P.S. Was brauchst Du an Funktionen ausser dem erstellen von Graphen/RRDs ?

**Frank0207** · 17.02.2013, 11:09

Mittlerweile...

...läuft die telnet Abfrage auch.

Code:

root@wiregate907:/etc/ebusd# perl telnet.pl
Unquoted string "cfg" may clash with future reserved word at telnet.pl line 14.
Unquoted string "cfg" may clash with future reserved word at telnet.pl line 34.
get ci hydraulic   4

get ci language  error send ebus msg

get ci holiday_period 11.01.2013 error start2 ==> 01 01 ff 24.01.2013 error end2 ==> 01 01 ff

get ci holiday_cir2_temp    20.0000

get ci password  error send ebus msg

get ci cir2_set_temp    35.0000

get ci cir2_flow_temp    37.9375

get ci hw_heat_time  20.00

Was ich noch nicht ganz versteh ist, dass diese Abfrage nur mit dem Skript hier https://knx-user-forum.de/292586-post556.html funktioniert.
Wenn ich einen Einzelbefehl hier absende bekomme ich immer ne Fehlermeldung.
Wie muss denn hier der Befehl genau aussehen? Würde danach das Senden ausprobieren und mal einen Einfachen Befehl an die WP schicken.

Es lag übrigens an der Trimmung weshalb ich die Fehler bekam.
Das Poti ist bei mir sehr empfindlich und es ist nur ein sehr schmaler Bereich wo es passt.

@JuMi: Mit dem Knxd ist es dann möglich den eBus schon mit dem KNX zu verknüpfen?

@all: Neben meiner WP habe ich noch den auromatic 560 Solardifferenzregler verbaut. Dieser hat ja auch eBus, jedoch ist nirgends von Vaillant eine Verbindungsmöglichkeit zwischen WP und auromatic dargestellt. Momentan sage ich der WP über den Relaisausgang C1/C2 und ner selbstgebastelten Schaltung wann ich Warmwasser von der WP benötige. Wäre aber schön wenn aber alles eine saubere Einheit wäre.
Hat von euch jemand die auromatic auch im Einsatz und mit der WP über eBus gekoppelt?

Grüße

Frank

**JuMi2006** · 17.02.2013, 12:07

@Frank:
Ja mit dem knxd besteht die Verbindung zwischen eBus und KNX.
Ist hier auch schon im Einsatz.

Zu telnet:

Code:

get ci cir2_flow_temp

Genau so sollte es eigentlich passen ... am Ende einfach Enter drücken

und mit

Code:

quit

verlassen.

@yuhu:
Wenn man den ebusd via telnet nicht mit einem sauberen "quit" verlässt dann kachelt der ab ... ist das behebbar?

Grüße

**Frank0207** · 17.02.2013, 12:53

Wer lesen kann...

..ist klar im Vorteil

Ich weiß nicht wo ich war aber ich hab immer beim Befehl den Teil "class" vergessen!

Jetzt funktioniert es!

Code:

...
get cir2 rt_day
  28.00
set cir2 rt_day 30.00
 ACK
get cir2 rt_day
 30.00
...

Auch das Schreiben geht! Dann werde ich mich jetzt mal dem knxd widmen!

Danke für die Tipps!

**JuMi2006** · 17.02.2013, 13:27

Hallo Frank,

die neueste Revision ist nicht knxd-kompatibel ! Da sitze ich gerade dran .... jetzt geh ich aber estmal eine rauchen

.

Ich baue das jetzt so um dass eine weitere config für den knxd oder whatever entsteht. Diese wird aus der ebusd.csv erzeugt (ist gerade fertig geworden).

In dies config wird dann einfach nur noch GA,DPT und RRD-Wunsch eingetragen. Diese wird dann dem knxd Zur Verfügung gestellt. Ist zwar nervig aber durch einen gewissen Automatismus noch handlebar. Ich habe da oft mir Roland drüber gesprochen und wir waren uns am Ende einig dass es da eine weitere config braucht.

In dieser sind ja dann lediglich ein paar GAs einzutragen und Kreuzchen für die RRDs zu machen.

Grüße

**JuMi2006** · 17.02.2013, 14:15

Also das config-file für den knxd wird jetzt erzeugt.
Ich hab da jetzt mal folgenden Vorschlag:

Code:

GA;DPT;RRD_TYPE;RRD_STEP;set;ci language;Sprachvariante 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci holiday_period start1;Ferienzeitraum 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci holiday_period start2;Ferienzeitraum 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci holiday_period end1;Ferienzeitraum 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci holiday_period end2;Ferienzeitraum 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci password pin1;Passwort Konfiguration 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci password pin2;Passwort Konfiguration 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci password pin3;Passwort Konfiguration 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci password pin4;Passwort Konfiguration 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci hw_wait_time;WW-Zeit max. bei Heizanforderung 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci pre_off_time;Vorabschaltzeit (Minuten) 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci freeze_wait;Frostschutz-Verzögerung (Stunden) 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci temp_error;Temperaturfehlererkennung 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci boiler;Pufferspeicher vorhanden 
GA;DPT;RRD_TYPE;RRD_STEP;set;ci hw_heat_time;Heizzeit max. bei WW-Anforderung 
GA;DPT;RRD_TYPE;RRD_STEP;set;amu zh_bivalent;Zusatzheizung - Bivalenzpunkt 
GA;DPT;RRD_TYPE;RRD_STEP;set;amu zh_hysterese;Zusatzheizung/ Hysterese 
GA;DPT;RRD_TYPE;RRD_STEP;set;amu zh_hys_delay;Zusatzheizung/ Verzögerung Hysterese  
GA;DPT;RRD_TYPE;RRD_STEP;set;amu zh_heating;Zusatzheizung/ Heizung 
GA;DPT;RRD_TYPE;RRD_STEP;set;amu zh_water;Zusatzheizung/ WarmWasser

Das ließe sich dann auch einfach in einem Texteditor weiter bearbeiten.

GA = Gruppenadresse KNX/EIB
DPT = Datentyp KNX/EIB
RRD_TYPE = Counter (g) oder Gauge (g)
RRD_STEP = Wäre der Schritt für Zählerstände bzw. hochlaufende Variablen

ad RRDs:
Ich würde erstmal sämtliche GAUGE-RRDs (Temperatur-/Druckverläufe etc.) auf dem default des RRD-tools von 300s belassen. Die Option da evtl. mal was nachzubessern hätten wir ja, wobei ein kürzerer Zyklus auch öfter abgefragt werden müsste (sicherlich auch lösbar ... aber schon etwas komplexer).

Zum COUNTER RRD, erstmal ne kurze Erklärung für die die sich noch nicht damit beschäftigt haben. Ein COUNTER, verrät der Name ja schon, ist ein Zähler-RRD. Wenn ich die normalen (GAUGE) RRDs immer mit dem aktuellen Zählerstand befüllen würde so gäbe eine (mehr oder weniger gleichmäßig) ansteigende Linie. In der Regel will ich aber wissen wie war mein Tagesverbrauch? Das kann eben das COUNTER-RRD. Ich schiebe immer nur den aktuellen Zählerstand ins RRD und dieses berechnet dann um Mitternacht (bzw. MEZ +1) den Tagesverbrauch. Die wäre bei einem RRD_STEP von 24 Stunden (im Programm 86400s) der Fall. Dieser Wert wäre dann nochmal variabel.

Grüße

**Gast** · 17.02.2013, 14:55

Hi,

aktuelles Commit (1489) ==> svn commit -m "cyc decoding added. Add csv tool to print config"

Im tools Verzeichnis gibt es nun csv. Damit können die csv Dateien ausgegben werden.

Code:

~/src/ebusd/tools $ ./csv -h

Usage: csv [OPTION] cfgdir

  -a --all      print ALL
  -c --cyc      print CYC
  -d --detail   print DETAIL
  -g --get      print GET
  -s --set      print SET
  -h --help     print this message.

~/src/ebusd/tools $ ./csv ../../csv/. -dc
2013-02-17 14:54:39.016 [0x02 NOT] ../../csv/./vaillant_cyc.csv
2013-02-17 14:54:39.017 [0x02 NOT] ../../csv/./vaillant_cyc.csv success
2013-02-17 14:54:39.017 [0x02 NOT] ../../csv/./vaillant_get.csv
2013-02-17 14:54:39.017 [0x02 NOT] ../../csv/./vaillant_get.csv success
2013-02-17 14:54:39.017 [0x02 NOT] ../../csv/./vaillant_set.csv
2013-02-17 14:54:39.018 [0x02 NOT] ../../csv/./vaillant_set.csv success
2013-02-17 14:54:39.018 [0x01 INF] [000] cyc : broad.date_time_temp                      (type: 1) FE0700           (len: 9) [4] ==> Datum, Uhrzeit und Aussentempertur
2013-02-17 14:54:39.018 [0x01 INF]           temp                 pos: 1,2           d2b [ 1.00] [°C]     -    Temperatur
2013-02-17 14:54:39.018 [0x01 INF]           day                  pos: 8             bdy [ 0.00] [-]     -    Wochentag
2013-02-17 14:54:39.018 [0x01 INF]           date                 pos: 6,7,9         bda [ 0.00] [-]     -    Datum
2013-02-17 14:54:39.018 [0x01 INF]           time                 pos: 5,4,3         bti [ 0.00] [-]     -    Uhrzeit

2013-02-17 14:54:39.018 [0x01 INF] 
2013-02-17 14:54:39.018 [0x01 INF] [001] cyc : broad.load_VF_temp                        (type: 1) FEB50527         (len: 4) [2] ==> Speicherladung und Vorlauftempertur
2013-02-17 14:54:39.018 [0x01 INF]           load                 pos: 2             bcd [ 1.00] [-]     00,01    Speicherladung
2013-02-17 14:54:39.018 [0x01 INF]           temp                 pos: 3             d1c [ 1.00] [°C]     -    Vorlauftemperatur
2013-02-17 14:54:39.018 [0x01 INF] 
2013-02-17 14:54:39.018 [0x01 INF] [002] cyc : broad.date_time                           (type: 1) FEB51600         (len: 8) [3] ==> Datum, Uhrzeit
2013-02-17 14:54:39.018 [0x01 INF]           day                  pos: 7             hdy [ 0.00] [-]     -    Wochentag
2013-02-17 14:54:39.018 [0x01 INF]           date                 pos: 5,6,8         bda [ 0.00] [-]     -    Datum
2013-02-17 14:54:39.018 [0x01 INF]           time                 pos: 4,3,2         bti [ 0.00] [-]     -    Uhrzeit
2013-02-17 14:54:39.018 [0x01 INF] 
2013-02-17 14:54:39.018 [0x01 INF] [003] cyc : broad.temp                                (type: 1) FEB51601         (len: 3) [1] ==> Aussentemperatur
2013-02-17 14:54:39.018 [0x01 INF]           temp                 pos: 2,3           d2b [ 1.00] [°C]     -    Temperatur
2013-02-17 14:54:39.018 [0x01 INF]

Seht Euch einfach die vaillant_cyc.ods für eine richtige Konfiguration an.

Danke Vaillant

Datum und Uhrzeit kann in Hex oder BCD Format vorkommen.
Daher gibt es nun als mögliches Format bda bzw. bti (bcd) oder hda bzw. hti (hex)

Sieht zwar nicht schön aus, aber mit 3 Buchstaben als Key noch einigermassen lesbar.

Im Daemon Log sieht das aus.

Code:

2013-02-17 14:37:36.333 [0x20 EBH]  10 fe b5 05 04 27 00 1a 00 15
2013-02-17 14:37:36.333 [0x40 EBS]   0  13.00 
2013-02-17 14:37:39.907 [0x20 EBH]  10 fe b5 16 08 00 04 37 14 17 02 07 13 0c
2013-02-17 14:37:39.907 [0x40 EBS] Sun 17.02.2013 14:37:04
2013-02-17 14:37:40.348 [0x20 EBH]  10 fe b5 16 03 01 60 05 75
2013-02-17 14:37:40.348 [0x40 EBS]    5.375 
2013-02-17 14:37:40.902 [0x20 EBH]  10 fe 07 00 09 60 05 04 37 14 17 02 06 13 a1
2013-02-17 14:37:40.902 [0x40 EBS]    5.375 Sun 17.02.2013 14:37:04

@JuMi2006:

Das der daemon crashed, wenn statt einem quit das Programmfenster beendet wird ist mir auch schon aufgefallen. <== Ist schon gefixt

Gut das du eine eigene Konfiguration für den knxd gemacht hat. Ist besser so.

**JuMi2006** · 17.02.2013, 15:11

Roland,
was passiert derzeit mit den Daten die via CYC ausgelesen werden?
Wie wäre die Telnet-Usage für CYC ?

**Gast** · 17.02.2013, 15:21

Zitat von JuMi2006 Beitrag anzeigen

Roland,
was passiert derzeit mit den Daten die via CYC ausgelesen werden?
Wie wäre die Telnet-Usage für CYC ?

Die Befehle kommen einfach in die gleich Struktur wie für GET/SET.

Mit Telnet können keine CYC Telegramme gesendet werden. Brauchen wir sowas?
Abhilfe: Stattdessen einfach eine SET/GET Telegramm definieren und benutzen.

FIX: Der Daemon sollte nun nicht mehr crashen, wenn das telnet Fenster einfach geschlossen wird.

**JuMi2006** · 17.02.2013, 15:26

Ich wollte eigentlich wissen ob ich via Telnet den letzten Wert eines CYC Telegramms erhalten kann ?
Also die gleiche Usage wie GET. Das wäre sinnvoll wenn sich der Daemon den letzten CYC merken könnte und dann ausgibt.

btw.

Weißt Du schon wie Du später visualisieren möchtest?

**Gast** · 17.02.2013, 15:54

Zitat von JuMi2006 Beitrag anzeigen

Ich wollte eigentlich wissen ob ich via Telnet den letzten Wert eines CYC Telegramms erhalten kann ?
Also die gleiche Usage wie GET. Das wäre sinnvoll wenn sich der Daemon den letzten CYC merken könnte und dann ausgibt.

Gute Idee. - Im Moment wird noch nicht gepuffert, aber dass könnte man machen. Dann sollte sich auch der Wert abholen lassen.

Zitat von JuMi2006 Beitrag anzeigen

Weißt Du schon wie Du später visualisieren möchtest?

Nein, was könnte ich nehmen?

**JuMi2006** · 17.02.2013, 16:36

Fürs erste testen wäre sicherlich drraw eine alternative.
Das lässt sich erstmal ziemlich simpel auf jedem webserver installieren.

LINK:
drraw

Ich denke dass das Puffern von konifgurierten cycles sinnvoll ist.
Dann würde ich die wie ein GET behandeln.

**kleinklausi** · 17.02.2013, 16:42

Zitat von yuhu Beitrag anzeigen

Gute Idee. - Im Moment wird noch nicht gepuffert, aber dass könnte man machen. Dann sollte sich auch der Wert abholen lassen.

Hallo,

Das Puffern wäre super!
Ich hatte mal in https://knx-user-forum.de/293041-post577.html beschrieben wie ich mir das vorstelllen könnte. Und das deckt sich sehr gut mit was JuMi2006 schreibt.

Gruß Moritz

**Gast** · 17.02.2013, 16:49

Dann nehme ich drraw mal fürs erste.

Gibt es den knxd schon im SVN?

Ankündigung

eBus->USB->Plugin->KNX

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar