Läuft: Heizung mit eBus-Schnittstelle

Begonnen von Prof. Dr. Peter Henning, 29 November 2014, 13:36:59

Vorheriges Thema - Nächstes Thema

john30

Zitat von: monoton am 23 Februar 2015, 23:50:24
leider ist mein kleiner krank geworden und braucht nun volle aufmerksamkeit.
dann mal gute besserung!

Zitat von: monoton am 23 Februar 2015, 23:50:24
05;Joh. Vaillant GmbH & Co.;VD600;0213;7501
06;Joh. Vaillant GmbH & Co.;PMS00;0107;4302
08;Joh. Vaillant GmbH & Co.;BAI00;0703;7401
0a;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
12;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
15;Joh. Vaillant GmbH & Co.;UI   ;0501;6201
1c;Joh. Vaillant GmbH & Co.;RC C ;0501;6201
23;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
25;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
26;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
50;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
52;Joh. Vaillant GmbH & Co.;MC2  ;0500;6301
53;Joh. Vaillant GmbH & Co.;MC2  ;0500;6301
75;Joh. Vaillant GmbH & Co.;RC C ;0501;6201
ec;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
ed;Joh. Vaillant GmbH & Co.;PMS00;0107;4302
fc;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
Das ist ja ne stolze Liste :-) Hast Du dem ebusd die Vaillant Configsfiles vom github spendiert?
Du könntest mal die Datei https://github.com/john30/ebusd-configuration/blob/master/ebusd-0.5.x/vaillant/scan.csv in das ebusd config Verzeichnis (z.B. /etc/ebusd) legen, dann würde der Scan noch die Produktnummern der Geräte ausgeben. Damit kann man etwas mehr über die Geräte herausfinden.

VD600 ist das vrnetDialog System, hab ich auch im Einsatz.
Die SOLSY Identifikation sieht in der Tat merkwürdig aus, die Adressen sind normalerweise Zirkulation, Warmwasser, Mischer für Heizkreis (ohne die "26", die kenn ich noch nicht). Kann gut sein, dass das SOLSY all das aus einem Guss liefert.
MC2 ist ein weiterer Mischer (hab ich auch).
RC C sind Raumregler, einer für den ersten und einer für den zweiten Heizkreis (sind bei mir auch im Einsatz).
Adresse ED ist klassicherweise Solarregler.
Für BAI00 und PM* gibts glaube ich schon Configfiles.

LG John
author of ebusd

monoton

#526
danke! wird schon wieder werden. bei den kleinen geht das ja schnell das sie mal krank werden, aber genauso schnell sind´s wieder gesund! :-)

danke für die info welche bedeutung die einzelnen identifikationen haben denke da steht mir noch einiges bevor...
hoffe wirklich das ich da nähere infos von vaillant bekomme.

habe das soeben nochmal mit der scan.csv durchlaufen lassen. ich habe aber öfters scannen müssen um alle ergebnisse zu erhalten, hatte öfters einen bus error (arbitration lost, retry)

05;Joh. Vaillant GmbH & Co.;VD600;0213;7501;21114300;200037180;082006429;N5
06;Joh. Vaillant GmbH & Co.;PMS00;0107;4302;21114300;200714883;110003697;N4
08;Joh. Vaillant GmbH & Co.;BAI00;0703;7401;21114400;100075083;100006309;N4
0a;Joh. Vaillant GmbH & Co.;PMW00;0117;4402;21114300;100072683;110002438;N6
12;Joh. Vaillant GmbH & Co.;PMW00;0117;4402;21114300;100072683;110002438;N6
15;Joh. Vaillant GmbH & Co.;UI   ;0501;6201;21114500;20 804650;907005828;N6
1c;Joh. Vaillant GmbH & Co.;RC C ;0501;6201;21120200;200400790;907005119;N0
23;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
25;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
26;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
50;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
52;Joh. Vaillant GmbH & Co.;MC2  ;0500;6301;21112730;6782<<<<0;907005639;N4
53;Joh. Vaillant GmbH & Co.;MC2  ;0500;6301;21112730;6782<<<<0;907005639;N4
75;Joh. Vaillant GmbH & Co.;RC C ;0501;6201;21120200;200400790;907005114;N0
ec;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
ed;Joh. Vaillant GmbH & Co.;PMS00;0107;4302;21114300;200714883;110003697;N4
fc;Joh. Vaillant GmbH & Co.;PMW00;0117;4402;21114300;100072683;110002438;N6


lg und gn8 :)
mono

Prof. Dr. Peter Henning

SOLSY liefert das tatsächlich "alles aus einem Guss" - das ist in der vrs620 Konfiguratiinsdatei bereits berücksichtigt.

LG

pah

john30

Zitat von: monoton am 24 Februar 2015, 00:50:24
habe das soeben nochmal mit der scan.csv durchlaufen lassen. ich habe aber öfters scannen müssen um alle ergebnisse zu erhalten, hatte öfters einen bus error (arbitration lost, retry)
Das ist bei derart vielen Geräten nicht verwunderlich.
Was sagt denn die Buslast bei Dir ("ebusctl state")?
Es hilft vielleicht, die Anzahl der Wiederholungen bei Arbitrierungsverlust zu erhöhen (z.B. "ebusd --acquireretries=5") oder auch die Anzahl der Master auf dem Bus (z.B. "ebusd --numbermasters=7"), das sind bei Dir mit ebusd immerhin 7.

LG John
author of ebusd

elmar

Hallo!
Ich logge fleißig meine Wolf-Anlage und versuche die Codierungen nach zu vollziehen.
Klappt (Dank diesem Forumsbeitrag!) soweit auch schon ganz gut

ich bekomme aber immer auch mal so etwas:
2015-02-24 13:16:53.435 [update notice] unknown BC cmd: 30fe50230924be0200005d01000045
2015-02-24 13:16:54.247 [update notice] unknown MS cmd: 0708502203de2a0217 / 025e10b3
2015-02-24 13:16:54.670 [update notice] unknown MS cmd: 07085022036176015d / 021400df
2015-02-24 13:16:55.701 [update notice] unknown MS cmd: 0751502203900f0011 / 02900114


Hat da jemand eine Idee dazu?
50 22 und 50 23 konnte ich bisher in keiner eBus Doku finden.
Auch was die die Sache mit dem Slash bedeuten könnte ?

LG Elmar

john30

Zitat von: elmar am 24 Februar 2015, 13:30:38
unknown BC cmd: 30fe50230924be0200005d01000045
"BC" steht für broadcast, also eine Nachricht an alle Teilnehmer (auch erkennbar an der Ziel-Adresse "fe").

Zitat von: elmar am 24 Februar 2015, 13:30:38
unknown MS cmd: 0708502203de2a0217 / 025e10b3
Auch was die die Sache mit dem Slash bedeuten könnte ?
"MS" steht für master-slave, also eine Nachricht, die von einem Master and einen Slave gesendet wurde. Der Master war hier die "07" und der Slave die "08".
Der Master hat den ersten Teil der Nachricht geschickt (vor dem Slash) und der Slave mit dem zweiten Teil (hinter dem Slash) geantwortet, also vom Master:
QQ=07
ZZ=08
PBSB=5022
NN=03
DD=de2a02
CRC=17

und darauf die Antwort vom Slave:
NN=02
DD=5e10
CRC=b3
author of ebusd

elmar

OK! soweit verstanden  :)
... und bereits vermutet.

Müsste ich, wenn ich die Daten entschlüsselt habe, 2 Zeilen in der CSV-Datei erstellen?
1x für M und 1x für S ?

LG Elmar

Prof. Dr. Peter Henning

Natürlich nicht.

Bitte erst einmal alles lesen, was schon da ist - dann braucht man nicht bei jedem Komma und jedem Schrägstrich zu fragen. Insbesondere das bereits mehrfach zitierte http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_eBUS_v0.6.0_mod.pdf.

So ein Dokument wird auch für das Zeug von Wolf benötigt.

LG

pah

elmar

Zitat von: Prof. Dr. Peter Henning am 24 Februar 2015, 17:50:47
Bitte erst einmal alles lesen, was schon da ist - dann braucht man nicht bei jedem Komma und jedem Schrägstrich zu fragen. Insbesondere das bereits mehrfach zitierte http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_eBUS_v0.6.0_mod.pdf.
So ein Dokument wird auch für das Zeug von Wolf benötigt.

Entschuldige bitte, es kommt nicht wieder vor.

LG Elmar

Prof. Dr. Peter Henning

"Nicht wieder" hat gar keiner verlangt - auch ich habe hier schon triviale Fragen gestellt, weil ich den Wald vor lauter Bäumen nicht gesehen habe.

Aber eben vielleicht nicht bei jedem Schrägstrich - denn das ist alles dokumentiert.

LG

pah

elmar

Alles klar...  :)
... und danke an für die bisher geleistete Arbeit und Unterstützung.

/_ G Elmar


MilanK

#536
@John30
Hallo,

gerade aktualisierte ich ebusd aus letze beta  bei yuhu auf deine Version 1.0.0 und ebusd behält sich seltsam.

Arch Linux, Raspberry Pi B+.

Solange ich die Kommandos in CLI benutze (direkt oder in einem Bash Skript), alles ist okay:

$ ebusctl read FanSpeed
0



$ tail -f /var/log/ebusd/ebusd.log
2015-02-24 21:21:36.496 [network info] [00013] connection opened 127.0.0.1                                                                                 
2015-02-24 21:21:36.497 [main notice] >>> read FanSpeed                                                                                                     
2015-02-24 21:21:36.498 [main info] read cmd: ff08b509030d8300aa                                                                                           
2015-02-24 21:21:36.499 [network debug] [00013] wait for result                                                                                             
2015-02-24 21:21:36.506 [bus debug] switching from ready to send command                                                                                   
2015-02-24 21:21:36.569 [bus debug] switching from send command to receive command ACK                                                                     
2015-02-24 21:21:36.575 [bus debug] switching from receive command ACK to receive response                                                                 
2015-02-24 21:21:36.603 [bus debug] switching from receive response to send response ACK                                                                   
2015-02-24 21:21:36.611 [bus debug] notify request: done                                                                                                   
2015-02-24 21:21:36.611 [bus notice] read res: 040000ffff15                                                                                                 
2015-02-24 21:21:36.611 [main notice] <<< 0                                                                                                                 
2015-02-24 21:21:36.618 [network info] [00013] connection closed


Sobald ich das selbe Skript durch systemd.service (https://en.wikipedia.org/wiki/Systemd) aufrufe, ebusd log sagt:

2015-02-24 21:13:35.776 [network info] [00001] connection opened 127.0.0.1
2015-02-24 21:13:35.779 [main notice] >>> read FanSpeed
2015-02-24 21:13:35.780 [main info] read cmd: ff08b509030d8300aa
2015-02-24 21:13:35.782 [network debug] [00001] wait for result
2015-02-24 21:13:35.797 [bus debug] switching from ready to send command
2015-02-24 21:13:35.862 [bus debug] switching from send command to receive command ACK
2015-02-24 21:13:35.868 [bus debug] switching from receive command ACK to receive response
2015-02-24 21:13:35.897 [bus debug] switching from receive response to send response ACK
2015-02-24 21:13:35.906 [bus debug] notify request: done
2015-02-24 21:13:35.906 [bus notice] read res: 040000ffff15
2015-02-24 21:13:35.907 [main notice] <<< 0
2015-02-24 21:13:35.909 [network debug] [00001] wait for result
[b]2015-02-24 21:13:35.910 [main notice] >>>[/b]
2015-02-24 21:13:35.914 [main notice] <<< usage:
read    Read value(s)         'read [-v] [-f] [-m SECONDS] [-c CLASS] NAME [FIELD]'
write   Write value(s)        'write CLASS NAME VALUE[;VALUE]*' or 'write -h ZZPBSBNNDx'
find    Find value(s)         'find [-v] [-r] [-w] [-p] [-d] [-c CLASS] [NAME]'
listen  Listen for updates    'listen [stop]'
state   Report bus state      'state'
scan    Scan seen slaves      'scan'
         Scan all slaves       'scan full'
         Report scan result    'scan result'
log     Set log area(s)       'log areas AREA[,AREA*]' (AREA: main|network|bus|update|all)
         Set log level         'log level LEVEL'        (LEVEL: error|notice|info|debug)
raw     Toggle log raw data   'raw'
dump    Toggle raw dump       'dump'
reload  Reload config files   'reload'
stop    Stop the daemon       'stop'
quit    Close connection      'quit'
help    Print this help page  'help'
         Print command usage   'help COMMAND'
2015-02-24 21:13:35.917 [network info] [00001] connection closed
2015-02-24 21:13:35.919 [bus debug] switching from send response ACK to send SYN
2015-02-24 21:13:35.931 [bus debug] ERR: SYN received during send SYN, switching to ready
2015-02-24 21:13:36.778 [network debug] dead connection removed - 0


Ich verstehe nicht die Zeile um 21:13:35.910 mit leerem Kommando.
2015-02-24 21:13:35.910 [main notice] >>>

Es kann sein, daß systemd nicht die richtige Umgebung setzt wie es im Terminal existiert. Dennoch, das systemd.service funktionierte gut mit ebusd von yuhu...

Hast du eine Ahnung was los ist?

P.S. Ich versuchte extra "newline" im Terminal, aber es verursachte nicht das oben geschriebenes Verhalten:

$ ebusctl read FanSpeed $'\n'
0


EDIT: Als provisorische Lösung filtriere ich den Output durch "head -1", so daß die andere Zeilen weggeschmissen werden.

john30

Zitat von: MilanK am 24 Februar 2015, 22:01:12
Ich verstehe nicht die Zeile um 21:13:35.910 mit leerem Kommando.
2015-02-24 21:13:35.910 [main notice] >>>

Ja, diese Zeile irritiert mich auch. Im Moment habe ich keine Erklärung dafür.
Du könntest versuchen, die Unterschiede im ENV herauszufinden, indem Du systemd anstatt auf das ebusd binary auf ein shell script verweist, das dann wiederum den ebusd startet. Darin könntest Du mit "export" die ENV in ein log file schieben und dann mit Deiner login shell ENV vergleichen.

Zitat von: MilanK am 24 Februar 2015, 22:01:12
Es kann sein, daß systemd nicht die richtige Umgebung setzt wie es im Terminal existiert. Dennoch, das systemd.service funktionierte gut mit ebusd von yuhu...
Hast du den ebusd frisch gebuildet oder das install package verwendet?

Zitat von: MilanK am 24 Februar 2015, 22:01:12
P.S. Ich versuchte extra "newline" im Terminal, aber es verursachte nicht das oben geschriebenes Verhalten:
Das bringt sicher nichts.
author of ebusd

MilanK

Zitat von: john30 am 24 Februar 2015, 22:12:23
Ja, diese Zeile irritiert mich auch. Im Moment habe ich keine Erklärung dafür.
Du könntest versuchen, die Unterschiede im ENV herauszufinden, indem Du systemd anstatt auf das ebusd binary auf ein shell script verweist, das dann wiederum den ebusd startet. Darin könntest Du mit "export" die ENV in ein log file schieben und dann mit Deiner login shell ENV vergleichen.
Hm. Es half nicht. Ich stellte auch direkt im Skript die selbe ENV um, wie die in meiner login shell bestehenden - keine Verbesserung.

Sollte ich es so verstehen, daß es nicht nur mit Systemd auftaucht? (Ich nehme an, daß du Debian benutzt.) Es wäre 'gut', weil ab und zu ist das ein vergeblicher Kampf mit Systemd...
Zitat
Hast du den ebusd frisch gebuildet oder das install package verwendet?
Frisch gebuildet, von hier https://github.com/john30/ebusd/archive/v1.0.0.tar.gz untergeladen.

P.S. Später schaffe ich ein Pull Request in GitHub für meine CSV Datei und auch für das Arch Build Package.

john30

Zitat von: MilanK am 24 Februar 2015, 22:40:58
Hm. Es half nicht. Ich stellte auch direkt im Skript die selbe ENV um, wie die in meiner login shell bestehenden - keine Verbesserung.
Kannst Du mir mal Deine "config.h" als PN schicken (oder einfach an ebusd (at) johnm.de)? Vielleicht fehlt Deinem Linux ja was grundlegendes.
author of ebusd