eBus->USB->Plugin->KNX

[kobza]

Hi Oliver,

Danke Dir, hatte es gestern mit der internen eBUS Schnittstelle probiert, werde es jetzt mit der am Display versuchen. Arduino ist ein Mikrokontroller Board, wollte erst mal damit versuchen.

Gruß
Thomas

[JuMi2006]

Es sind nun einige Fixes im SVN, damit sollte das Dekodieren von int, d1b, d1c, d2b und d2c ganz gut funktionieren.

Das läuft schon mal richtig gut durch! Mein Testscript schafft jetzt die gesamte "get"-config mit 164 Befehlen in 43 Sekunden

get ci hydraulic   3
get ci language   0
get ci cir2_set_temp    27.0000
get ci cir2_flow_temp    24.9375
get ci hw_heat_time  20.00
get ci hw_wait_time  40.00
get ci temp_camber   0
get ci pre_off_time error send ebus msg
get ci freeze_wait   1
get ci temp_error   0
get ci boiler   0
get ci yield_transfer 21573.000
get ci mode   1
get ci yield_jan_act 1950.000
get ci yield_jan_last 3788.000
get ci yield_feb_act  315.000
get ci yield_feb_last 2438.000
get ci yield_mar_act    0.000
get ci yield_mar_last 1640.000
get ci yield_apr_act    0.000
get ci yield_apr_last 1289.000
get ci yield_may_act    0.000
get ci yield_may_last  534.000
get ci yield_jun_act    0.000
get ci yield_jun_last  356.000
get ci yield_jul_act    0.000
get ci yield_jul_last  142.000
get ci yield_aug_act    0.000
get ci yield_aug_last  175.000
get ci yield_sep_act    0.000
get ci yield_sep_last  389.000
get ci yield_oct_act    0.000
get ci yield_oct_last 1196.000
get ci yield_nov_act    0.000
get ci yield_nov_last 2014.000
get ci yield_dec_act    0.000
get ci yield_dec_last 2451.000
get amu weekday   3
get amu wp_stat   6
get amu boiler_avail   4
get amu zh_bivalent    -4.0000
get amu zh_hysterese     7.0000
get amu zh_hys_delay  20.00
get amu zh_EI -600.000
get amu zh_heating   0
get amu zh_water   1
get amu comp_hysteres     7.0000
get amu comp_energy_int -150.000
get amu comp_start_hour   3
get amu comp_max_in    50.0000
get amu brine_spreiz    20.0000
get amu brine_frost -10.00
get amu offset_pump_min   4
get amu preset_pump_sek   2.00
get amu comp_h_heating 2888.000
get amu comp_h_water  317.000
get amu comp_h_sum 3209.000
get amu comp_starts 2198.000
get amu boiler_h_sum  306.000
get amu boiler_h_heating  295.000
get amu boiler_h_water   11.000
get amu boiler_starts    0.000
get amu cooling_preset  21.00
get amu service_time   0
get amu venting   0
get amu save_codes   0
get amu high_eff_pump_stat   0
get amu high_eff_pump_perc   7.00
get amu high_eff_pump_perc_heating 100.00
get amu bivalentmode   0
get mv yield_sum 21594.000
get mv brine_in_temp     4.8125
get mv brine_in_stat   0
get mv brine_out_temp     6.0625
get mv brine_out_stat   0
get mv brine_press    2.375
get mv brine_press_stat   1
get mv brine_press_switch   0
get mv high_press    6.468
get mv high_press_stat   0
get mv low_press    6.214
get mv low_press_stat   0
get mv overheat_temp     0.0000
get mv undercool_temp     0.0000
get mv EI_current  -68.000
get mv comp_in_temp    22.3750
get mv comp_in_stat   0
get mv comp_out_temp    22.4375
get mv comp_out_stat   0
get mv tev_in_temp     9.3125
get mv tev_stat   0
get mv prestostate   0
get mv comp_io   0
get mv boiler_io   0
get mv T6_temp    24.6875
get mv T6_stat   0
get mv T5_temp    24.6875
get mv T5_stat   0
get mv heat_press    2.360
get mv heat_press_stat   0
get mv heat_pump_io   1
get mv VF1_temp   -13.9375
get mv VF1_stat 255
get mv RF1_temp   -13.9375
get mv RF1_stat 255
get mv VF2_temp    24.5000
get mv VF2_stat   0
get mv pump_stat   1
get mv boiler_temp    35.4375
get mv boiler_temp_stat   0
get mv circ_pump_io   1
get mv valve   0
get mv circ_once   0
get mv power_interrupt   0
get mv phase_stat   7
get mv phase_rot_stat 255
get mv curr_limiter   0
get mw at_temp     1.0625
get mw at_stat   0
get cal outdoor     1.0000
get cal brine_in     0.0000
get cal brine_out     0.0000
get cal boiler    -1.0000
get cal heat_flow     0.0000
get cal heat_return     0.0000
get cal VF2     0.0000
get cal comp_in error send ebus msg
get cal comp_out     0.0000
get cal buffer_in     1.8750
get cal buffer_out     0.0000
get hw mode   0
get hw target_temp     0.0000
get hw min_temp    38.0000
get hw legionella_protect   0
get hw legionella_wday   7
get hw legionelle_starttime    0.000
get hw tank_layered  30.00
get hw tank_coyled 100.00
get hw tank_mode   1
get cir2 mode   1
get cir2 type   1
get cir2 rt_day  22.00
get cir2 rt_night  15.00
get cir2 curve   0.15
get cir2 at_off  16.00
get cir2 vl_min  15.00
get cir2 vl_max  43.00
get cir2 pre_hours   0
get cir2 estrich   0
get cir2 floor_protect  26.00
get cir2 cooling   2
get cir2 cooling_support   0
get cir2 outdoor_24h_average     1.5625
get cir2 cooling_offset_outdoor   4.00
get cir2 locktime_cool>heat   6
get cir2 locktime_heat>cool   6
get cir2 min_diff   1.00
get cir2 holiday_cooling   0
get cir2 cooling_request   0
get cir2 heat_pump_stat   0
get cir2 heat_pump_curr  40.00
get cir2 heat_pump_load  50.00
get cir2 heat_pump_heat 100.00
get cir2 heat_pump_pause  40.00
164 Befehle in 43 Sekunden

Jetzt gilt es noch ein paar Fehler auszumerzen und mit der vrDialog abzugleichen.

Danke Roland!

Demnächst kommen SET und CYC Telegramme bzw. exotische Datentypen zum Implementieren an die Reihe
Gibt es Feature Wünsche?

Bestimmt ... mein erster Featurewunsch wäre die Implementierung von SET bevor wir die exotischen Datentypen kommen .
Dann geht das ganze nämlich in den Praxistest über.

ad Features:
- Schnittstelle zum RRD-Tool und zyklisches Füllen der Datenbank mit ausgewählten Werten
- Schnittstelle zum EIB/KNX*


Grüße

*Ich habe mir mal makkis wiregated geschnappt und angefangen den abzuspecken. Also alles was man nicht direkt für eine KNX-Verbindung braucht raus (Busmaster, Datum/Zeit-Telegramme, VPN-Geschichten etc.). Darin laufen auch die geliebten Perl-Plugins, die RRDs werden mit entsprechendem Patch ordentlich erstellt (auch COUNTER) und es kollidiert auch nichts mit dem normalen wiregated. Durch weniger Funktionen auch weniger memleaks (ca. 1MB pro Tag). Aber das ist schon ein richtiger Brocken den makki da geschrieben hat. Wenn wir KNX nicht mit in den Daemon bekommen dann wird es bei mir evtl. darauf hinauslaufen.

[JuMi2006]

Hi Oliver,

Danke Dir, hatte es gestern mit der internen eBUS Schnittstelle probiert, werde es jetzt mit der am Display versuchen. Arduino ist ein Mikrokontroller Board, wollte erst mal damit versuchen.

Gruß
Thomas

Hallo Thomas, theoretisch sollte die Arduino Schaltung aus dem Wiki doch auch für ein Senden erweiterbar sein oder? Davon hab ich nur leider Null Ahnung .

[MarcusF]

ad Features:
- Schnittstelle zum RRD-Tool und zyklisches Füllen der Datenbank mit ausgewählten Werten
- Schnittstelle zum EIB/KNX*

Meinst Du wirklich, dass das in den ebusd gehört? So ein Monolith widerspricht doch dem modularen Gedanken.

Tolle Arbeit, Roland. In den nächsten Tagen habe ich hoffentlich wieder etwas mehr Zeit, dann werde ich an meiner Anlage weiter testen.

Marcus

[JuMi2006]

Meinst Du wirklich, dass das in den ebusd gehört? So ein Monolith widerspricht doch dem modularen Gedanken.

Hallo Marcus,

nein muss es nicht zwangsläufig. Aber die Daten hätten bestimmt viele entweder auf dem Bus oder in RRDs. Auf welcher Basis wäre denn die Kommunikation mit dem ebusd von anderen gewünscht?

In Perl wird die csv momentan problemlos geparst. Damit könnte man die eben einlesen und die RRDs und KNX-Kommunikation auch damit machen. Dank telnet muss ja nicht alles auf einem Gerät passieren. Die WireGate Plugins in ihrer jetzigen Form würde ich allein aufgrund der Laufzeit/Thread-Problematik da ausklammern.
Selbst wenn der Daemon die Daten per UDP versenden würde ergibt das mit 100% Sicherheit ein perfektes memleak-Plugin. Das behaupte ich jetzt mal nach mehrmonatiger Beobachtung von Plugins/Speicherbedarf. Alles was bei mir mit Sockets zu tun hat zeigt dieses Verhalten. Das alte Squeezebox-Plugin hat den wiregated alle 24 Stunden neu starten lassen, mein erstes eBus-Plugin mit selbstgestricktem Perl-Daemon war da genauso hungrig.

Wenn akzeptabel und gewünscht würde ich versuchen den wiregated so abzuspecken dass er sich als reiner KNX/RRD/eBus-Daemon verhält und mit dem ebusd kommuniziert.

Grüße

[kobza]

Hi,

ja ich habe erst gestern Abend damit angefangen :-) Bin aber erst morgen wieder zu Hause, am Wochenende geht es weiter.

Gruß
Thomas

Hallo Thomas, theoretisch sollte die Arduino Schaltung aus dem Wiki doch auch für ein Senden erweiterbar sein oder? Davon hab ich nur leider Null Ahnung .

[kleinklausi]

Wenn akzeptabel und gewünscht würde ich versuchen den wiregated so abzuspecken dass er sich als reiner KNX/RRD/eBus-Daemon verhält und mit dem ebusd kommuniziert.

Auch wenn ich hier im Moment leider nur mitlese, finde ich das gut.

Gruß

[MarcusF]

nein muss es nicht zwangsläufig. Aber die Daten hätten bestimmt viele entweder auf dem Bus oder in RRDs. Auf welcher Basis wäre denn die Kommunikation mit dem ebusd von anderen gewünscht?

Ich für meinen Teil kann mit der Telnet-Schnittstelle gut leben, die Busanbindung etc. sollte mein HS übernehmen. Obwohl Du natürlich recht hast, letzten Endes sollen die Daten auf den Bus, da hätte ein Raspi + ROT mit dem ebusd schon seinen Charme. Das ganze in ein REG...

Statt den wiregated abzuspecken - wäre da vielleicht die Einbindung in smarthome.py eine Lösung? Ich mein, da wär der Buszugriff und die RRDs schon da.

Marcus

[JuMi2006]

Obwohl Du natürlich recht hast, letzten Endes sollen die Daten auf den Bus, da hätte ein Raspi + ROT mit dem ebusd schon seinen Charme

Statt den wiregated abzuspecken - wäre da vielleicht die Einbindung in smarthome.py eine Lösung? Ich mein, da wär der Buszugriff und die RRDs schon da.

ad smarthome/wiregate/etc:
Da können wir über viele Wege diskutieren, smarthome.py habe ich neulich versucht mir anzusehen. Ganz ehrlich, ich hab da nach 2 Stunden immer noch nicht durchgeblickt.
Vielleicht gibt es irgendwann mal ein ein How-To von Usern für User. Mit dem Programmier-Englisch tue ich mich da ein wenig schwer ... ebenso wie mit gefühlten 100 config-files.
Ich hab das auf meinem Test-System (clone-gate) installiert und bin bei der Installation schon fast verzweifelt (Dauer: 2h). Perl bekomme ich, incl. der benötigten Pakete mit einer Zeile "apt-get install xyz zyx abcd" zum laufen.

Ebenso hatte ich schonmal linknx im Auge. Das braucht wenig Ressourcen und die paar RRDs bekommt man dem auch noch bei gebogen.

Ich will hier nichts ausschließen und begrüße jegliche Diskussion darüber.

ad Pi/ROT:
Genau das ist MEIN Wunsch. Den möchte ich natürlich niemanden aufzwingen, aber KNX ist nun mal ein dezentrales/modulares System ... dem könnte man so sehr schön treu bleiben.

Grüße

[Gast]

ad Pi/ROT:

Pi = Raspberry Pi ==> das ist auch meine erste Zielplattform, auch wenn daneben eine Backup-Server steht
ROT = was ist damit gemeint?

Bestimmt ... mein erster Featurewunsch wäre die Implementierung von SET bevor wir die exotischen Datentypen kommen

Ja, SET kommt als nächstes

Mit exotischen Datentypen habe ich vor allem Datum / Uhrzeit / Datumsblock gemeint.
Das Datum und die Uhrzeit können wir dann sofort für die uns bekannten zyklischen Telegramme verwenden.
Somit kommen die CYC Telegramme erst danach.


zu den Feature Wünschen.

Der ebusd muss kein Monolith werden, jedoch werde ich für mich, sobald der Daemon halbwegs stabil läuft mit Langzeitaufzeichnungen beginnen.
Spätestens da muss ich wissen wie und vor allem mit was ich die Daten weiterverearbeiten will und kann. Soweit bin ich leider immer noch nicht.
Für das erste kann ich sicher mit der Telnet Schnittstelle leben. Vielleicht gibt es ja andere, besser, einfachere,... Möglichkeiten.
Ich denke hier vor allem an andere Wege, wie UDP, RRD, Datenbank,.... War da nicht auch einmal der Wunsch für eine andere, serielle Anbindung?

[JuMi2006]

ROT ist eine Hardware-Erweiterung für den Raspberry die den direkten Zugriff auf den 1-Wire-Bus und den KNX Bus erlaubt. Den Link dazu reiche ich noch mal nach.

Wenn wir hier über einen zweiten Daemon sprechen dann ist in meinen Augen da RRD + KNX-Zugriff schon mit drin.
Die RRDs lassen sich leicht per Kommandozeile machen. Ebenso ist dies mit Perl recht einfach machbar ... das kann wohl jede Programmiersprache recht simpel.

Wenn Du noch Muse hast und Dir mal die RRD-Tools bzw. das entsprechende Perl-Paket lädst kann ich Dir nochmal was zum Testen senden. RRD ist ja die Langzeitaufzeichnung.

Grüße

[Gast]

Telegramm je Sekunde

Das läuft schon mal richtig gut durch! Mein Testscript schafft jetzt die gesamte "get"-config mit 164 Befehlen in 43 Sekunden

..
get ci pre_off_time error send ebus msg
..
get cal comp_in error send ebus msg
..

Man sieht dann doch, einige Fehler bei der Übertragung.

Die Anzahl der Busteilnehmer ist hier sicher entscheidend, wieviel Telegramme hier zyklisch gesendet werden.

In meinem Fall werden neben den Broadcasts noch zyklische Telegramme zu

* den 3 Heizkreisen (0x50, 0x52 und 0x53)
* dem Solarmodul (0xec und 0xed)
* bzw. Frischwassermodul (0x0a)
* und zur Wärmepumpe (0x08 und 0x25)

gesendet.

Da tut sich schon einiges auf dem Bus.

Aus meiner Sicht ist hier eine gesicherte Übertragung wichtiger als die maximale Anzahl der Telegramme je Sekunde.

Vorschlag von mir: Nachdem das ganze ja nicht Zeitkritisch ist, sollten wir uns auf die sichere Seite legen und eventuell die Sendefrequenz künstlich beschränken.
Für die Langzeitaufzeichnungen will ich keine Löcher in den Daten haben.

Mir ist schon klar, dass Du damit einfach sagen wolltest, was möglich ist. (habe ich ja mit dem Stresstest Skript so gemacht)

[JuMi2006]

Also ich würde das auch auf 2 Abfragen pro Sekunde begrenzen.

Ich bastel gerade an dem Perl Daemon, der hat bei der Datenabfrage eh ein paar "timeouts" bzw. brauchts eine Limitierung.

Wie das laufen soll habe ich schon im Kopf. Ich versuche den gerade mal stabil zu bekommen und die unvermeidbaren memleaks zu minimieren bzw. im Daemon selbst zu überwachen. Noch ein paar Abende und das ganze geht in "Produktion". Der zweite Daemon setzt auf den wiregated auf bzw. ist ein abgespeckter.
Für die KNXer: Die GAs + DPTs könnte man mit in der config ablegen, hier tendiere ich zu einer "Schalt"-GA und einer "Rückmelde"-GA ... könnte man aber auch in einer machen.
Für die Nicht-KNXer: Die RRDs könnte man auch aus der config erstellen lassen.
Ich mach da jetzt erstmal ein bisschen weiter bis irgend jemand "Stop" ruft .

Wie ich gestern getestet habe kann man auf den ebusd ja auch mit mehreren (2=getestet) Telnet Instanzen zugreifen ... sehr schön !!!

ad Löcher:
Sofern wir das mit RRDs lösen wird es da keine Löcher geben, das bekommt man so hin.

Grüße

[Gast]

Es scheint so, dass die Adressen ab floor_protect nicht für die Heizkreise 4 und 5 stimmen. Dass muss ich wohl mal mit dem Original Adapter ran.

[Gast]

ebusd - SET für d1b und d1c

Hi,

der aktuelle Stand im SVN kann SET Befehle für die Datentypen d1b und d1c verarbeiten.

Einschränkung: Der Befehl hat nur 1 Datenbyte nach dem eigenlichen Kopf.
==> ohne führende oder nachfolgende 00 - eventuell stimmt da ja auch der Datentyp nicht

Getestet mit

set;cir2;rt_day;3;50;B509;4;0E3200;1;1;d1b;0.500;°C;Heizkreis – Raumsolltemperatur;

Client:

media ~/src/ebus $ telnet backup 8888
Trying 192.168.1.16...
Connected to backup.lan.
Escape character is '^]'.
get cir2 rt_day
 17.00
set cir2 rt_day 18.5
 ACK
get cir2 rt_day
 18.50
shutdown
Connection closed by foreign host.

Server:

2013-02-09 22:00:19.980 [0x02 NOT] /usr/src/vaillant_set.csv
2013-02-09 22:00:19.981 [0x02 NOT] /usr/src/vaillant_set.csv success
..
..
2013-02-09 22:00:32.521 [0x80 NET] >>> client [6] get cir2 rt_day
2013-02-09 22:00:32.521 [0x02 NOT] search: get cir2.rt_day (null)
2013-02-09 22:00:32.521 [0x02 NOT]  found: 50B509030D3200 type: 3 ==> id: 152
2013-02-09 22:00:32.521 [0x10 DBG] add: id: 152 msgtype: 0 data: - clientfd: 6 ==> entries: 1
2013-02-09 22:00:32.541 [0x10 DBG] del: id: 152 msgtype: 0 data: - clientfd: 6 ==> entries: 0
2013-02-09 22:00:32.541 [0x20 EBH]  50 b5 09 03 0d 32 00
2013-02-09 22:00:32.653 [0x20 EBH]  01 22
2013-02-09 22:00:32.653 [0x10 DBG] id: 152 r_pos: 1 p1: 1 p2: 0 p3: 0 p4: 0
2013-02-09 22:00:32.653 [0x80 NET] <<< client [6]  17.00
..
..
2013-02-09 22:00:41.882 [0x80 NET] >>> client [6] set cir2 rt_day 18.5
2013-02-09 22:00:41.882 [0x02 NOT] search: set cir2.rt_day 18.5
2013-02-09 22:00:41.882 [0x02 NOT]  found: 50B509040E3200 type: 3 ==> id: 1
2013-02-09 22:00:41.882 [0x10 DBG] add: id: 1 msgtype: 1 data: 18.5 clientfd: 6 ==> entries: 1
2013-02-09 22:00:41.887 [0x10 DBG] del: id: 1 msgtype: 1 data: 18.5 clientfd: 6 ==> entries: 0
2013-02-09 22:00:41.887 [0x10 DBG] id: 1 d_pos: 1 p1: 1 p2: 0 p3: 0 p4: 0
2013-02-09 22:00:41.887 [0x20 EBH]  50 b5 09 04 0e 32 00 25
2013-02-09 22:00:41.999 [0x20 EBH]  00
2013-02-09 22:00:41.999 [0x80 NET] <<< client [6]  ACK
..
..
2013-02-09 22:00:47.950 [0x80 NET] >>> client [6] get cir2 rt_day
2013-02-09 22:00:47.950 [0x02 NOT] search: get cir2.rt_day (null)
2013-02-09 22:00:47.950 [0x02 NOT]  found: 50B509030D3200 type: 3 ==> id: 152
2013-02-09 22:00:47.950 [0x10 DBG] add: id: 152 msgtype: 0 data: - clientfd: 6 ==> entries: 1
2013-02-09 22:00:47.963 [0x10 DBG] del: id: 152 msgtype: 0 data: - clientfd: 6 ==> entries: 0
2013-02-09 22:00:47.963 [0x20 EBH]  50 b5 09 03 0d 32 00
2013-02-09 22:00:48.108 [0x20 EBH]  01 25
2013-02-09 22:00:48.108 [0x10 DBG] id: 152 r_pos: 1 p1: 1 p2: 0 p3: 0 p4: 0
2013-02-09 22:00:48.108 [0x80 NET] <<< client [6]  18.50