Läuft: Heizung mit eBus-Schnittstelle

[john30]

Das hat mein Installateur gemacht.
Aber in einem Menue der 620 steht:
HK2: Radiatoren
HK4: Fussboden
HK5: Warmwasser
Da die Radiatoren an der 620 angeschlossen sind, muss auf der VR60
KHa = HK4 = Fussboden und HKb = HK5 = Warmwasser sein.

Mach doch mal ein "ebusctl scan full", warte ne Minute und gib dann nochmal das info Ergebnis aus.
Im Moment scheint kein einziges Gerät mit HK4+HK5 zu kommunizieren...

[galileo]

Mach doch mal ein "ebusctl scan full", warte ne Minute und gib dann nochmal das info Ergebnis aus.
Im Moment scheint kein einziges Gerät mit HK4+HK5 zu kommunizieren...

Also das ist sehr eigenartig. Ich hab das Warmwasser laufen lassen und auch die Solltemperatur Fussboden auf 30 Grad gestellt und 10 Minuten gewartet.
Da hätte sich doch etwas tun müssen
Wie könnte ich denn erkennen dass mit HK4-HK5 kommuniziert wird ?

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl scan result
08;Vaillant;BAI00;0703;7401;21;13;28;0010004111;0006;005309;N2
15;Vaillant;UI   ;0507;6201;21;13;26;0020080465;0907;007457;N9
1c;Vaillant;RC C ;0501;6201;21;12;11;0020040079;0907;005033;N9
23;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
25;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
26;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
50;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
ec;Vaillant;SOLSY;0500;6301


[galileo]

Ich habe auch noch alle Geräte stromlos gemacht und wieder eingeschaltet. Jetzt gibt es zwei Adressen mehr (3F und 52):

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 52
masters: 5
messages: 698
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI   ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 17: master #17
address 1c: slave #17, scanned "MF=Vaillant;ID=RC C ;SW=0501;HW=6201", loaded "vaillant/1c.rcc.4.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8
address 3f: master #23
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address 52: slave
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"


[john30]

Also das ist sehr eigenartig. Ich hab das Warmwasser laufen lassen und auch die Solltemperatur Fussboden auf 30 Grad gestellt und 10 Minuten gewartet.
Da hätte sich doch etwas tun müssen
Wie könnte ich denn erkennen dass mit HK4-HK5 kommuniziert wird ?

Das "info" Ergebnis zeigt alle Adressen, die seit Start von ebusd in einer erfolgreichen Kommunikation involviert waren, d.h. wenn dort die Geräte nicht auftauchen, dann hat kein anderes Gerät mit diesen erfolgreich kommuniziert. Zumindest aus Sicht von ebusd.
Es könnte noch sein, dass Du das Poti Deiner eBUS Hardware etwas nachjustieren musst. Dazu gibt es einige Hinweise im FHEM ebus Wiki.

[galileo]

Es könnte noch sein, dass Du das Poti Deiner eBUS Hardware etwas nachjustieren musst.

Ich werde das heute abend ausprobieren.
Aber kannst du mir bitte noch sagen, was ich zu erwarten habe, falls das VR60 erkannt würde.
Erscheint dann eine neue Adresse und eine neue ID ?
Welches csv wäre denn dafür zuständig ?
Oder gibt's noch gar kein csv welches das abdeckt ?
Entschuldige bitte die dumme Fragerei, aber ich denke ich tu mir leichter, wenn ich verstehe, wonach ich suchen muss.
LG
Eduard

[john30]

Aber kannst du mir bitte noch sagen, was ich zu erwarten habe, falls das VR60 erkannt würde.
Erscheint dann eine neue Adresse und eine neue ID ?

Es müsste dann nach meinen Infos die Adressen 52 und 53 im "info" Ergebnis auftauchen.

Welches csv wäre denn dafür zuständig ?

52.mc2.mc.4.csv bzw. 53.mc2.mc.5.csv

[galileo]

Es könnte noch sein, dass Du das Poti Deiner eBUS Hardware etwas nachjustieren musst. Dazu gibt es einige Hinweise im FHEM ebus Wiki.

Hallo John, das war's !!
Lange am Poti gedreht, aber jetzt habe ich eine Adresse 52 und 53.
Vielen Dank für den Tip, ich wäre - eben wegen der Anleitung im WIKI - nie auf die Idee gekommen.
Tatsächlich war es so dass ich einwandfreie <aa und dazwischen andere Hex Werte hatte, aber das ist offenbar nur notwendig - und nicht hinreichend.
Das heißt ja nur dass ich irgendeinen Busteilnehmer empfange aber eben nicht alle. Wenn ein anderer mit seinen Pegeln ein wenig neben jenen mit dem Poti eingestellten liegt, dann empfängt man den halt nicht...

Ja und dann noch die Frage, ob ich mich da nicht nützlich machen könnte: Auch in der 53.mc2.mc.5.csv gibt's Einträge, die sicher so nicht gehören. Z.B. steht in der Überschrift "MK2", beim [comment] steht "Hk3P_Port3", bei comment steht "...pump on MK1P" und die tatsächliche Beschriftung in der VR60 lautet "HKb-P".
Besteht ein Interesse soetwas auszubessern und wenn ja, wo soll ich das "ablegen" ?

[flash91]

Mit dem jüngsten commit 086dea5 lassen sich jetzt auch ganz einfach mehrere ebusd Instanzen starten, indem mehrere EBUSD_OPTS in /etc/default/ebusd eingetragen werden.

Hey John,

lange ists her. Habe gestern meinen Raspberry frisch aufgesetzt und gleich deine aktuellste ebusd Version von git ausgecheckt.
Wollte dann folgendes testen:

Code Auswählen Erweitern

EBUSD_OPTS1="--readonly --device=/dev/ftdi1 --localhost --port=5001 -l /var/log/ebusd1.log"
EBUSD_OPTS2="--readonly --device=/dev/ftdi2 --localhost --port=5002 -l /var/log/ebusd2.log"


Code Auswählen Erweitern

sudo systemctl start ebusd

die erste Instanz funktioniert dann einwandfrei aber im /var/log/ebusd2.log steht

Code Auswählen Erweitern

2016-10-21 07:46:45.920 [main notice] ebusd 2.2.af6e1c1 started
2016-10-21 07:46:45.931 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-21 07:46:45.939 [bus error] unable to open /dev/ftdi2: ERR: generic device error


schreibe ich aber

Code Auswählen Erweitern

sudo systemctl stop ebusd
ebusd -f --readonly --device=/dev/ftdi2 --localhost --port=5002
ins Terminal so erhalte ich gleich:

Code Auswählen Erweitern


2016-10-21 08:03:54.638 [main notice] ebusd 2.2.af6e1c1 started
2016-10-21 08:03:54.650 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-21 08:03:54.676 [bus notice] signal acquired
2016-10-21 08:04:02.163 [bus notice] new master 71, master count 2
2016-10-21 08:04:02.163 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-21 08:04:17.112 [update notice] update solar temp: 0;41.88;34.62


weißt du worans liegen könnte?

bevor du diese Methode angeboten hast habe ich ja das ebusd programm dupliziert und es mit folgendem Startscript zum laufen gebracht:

Code Auswählen Erweitern


        systemctl start ebusd2
systemctl start ebusd
sleep 2
systemctl stop ebusd2
systemctl stop ebusd
systemctl start ebusd
sleep 1
systemctl start ebusd2
wobei es hier auf die Reihenfolge ankam wie gestartet und gestoppt wird.

Beste Grüße

[john30]

Hallo John, das war's !!
Lange am Poti gedreht, aber jetzt habe ich eine Adresse 52 und 53.
Vielen Dank für den Tip, ich wäre - eben wegen der Anleitung im WIKI - nie auf die Idee gekommen.
Tatsächlich war es so dass ich einwandfreie <aa und dazwischen andere Hex Werte hatte, aber das ist offenbar nur notwendig - und nicht hinreichend.
Das heißt ja nur dass ich irgendeinen Busteilnehmer empfange aber eben nicht alle. Wenn ein anderer mit seinen Pegeln ein wenig neben jenen mit dem Poti eingestellten liegt, dann empfängt man den halt nicht...

Das freut mich. Ja, die Pegel können halt insbesondere auch wegen der Leitungslänge je nach Device etwas unterschiedlich sein.

Ja und dann noch die Frage, ob ich mich da nicht nützlich machen könnte: Auch in der 53.mc2.mc.5.csv gibt's Einträge, die sicher so nicht gehören. Z.B. steht in der Überschrift "MK2", beim [comment] steht "Hk3P_Port3", bei comment steht "...pump on MK1P" und die tatsächliche Beschriftung in der VR60 lautet "HKb-P".
Besteht ein Interesse soetwas auszubessern und wenn ja, wo soll ich das "ablegen" ?

Interesse besteht da natürlich, klar. Allerdings sind die paar Tausend Zeilen der CSVs größtenteils generiert und warten eigentlich noch auf die Vereinheitlichung der Namen, die pah mal angeregt hatt und die ich auch befürworte. Da gehts nur leider seit nicht vorwärts, weil die Regeln für die Nomenklatur erst einmal diskutiert werden wollen. Der letzte Beitrag dazu ist schon einige Monate her fürchte ich.

Anyway, bevor diese Umbenennung durchgeführt wurde und in meinem Generator eingebaut ist, macht es nicht so wahnsinning viel Sinn, Korrekturen in den anderen Teilen der Definitionen durchzuführen. Denn sonst darf ich das nach der Generierung alles manuell mergen, was nicht wirklich der große Spaß ist...

VG John

[john30]

schreibe ich aber

Code Auswählen Erweitern


ebusd -f --readonly --device=/dev/ftdi2 --localhost --port=5002

Hast Du mal die Rechte der dev nodes gecheckt?

[flash91]

meinst du unter /lib/udev/rules.d/50-udev-default.rules ?
dort steht

Code Auswählen Erweitern

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664"


bzw.:

Code Auswählen Erweitern

ls -ldh /dev/ftdi1
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi1 -> ttyUSB1


Code Auswählen Erweitern


ls -ldh /dev/ftdi2
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi2 -> ttyUSB0


[john30]

Code Auswählen Erweitern

ls -ldh /dev/ftdi1
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi1 -> ttyUSB1


Code Auswählen Erweitern


ls -ldh /dev/ftdi2
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi2 -> ttyUSB0


Das meinte ich, aber das scheint nicht das Problem zu sein. Merkwürdig, da hab ich jetzt spontan keine Idee, woran es liegen könnte.
Probier mal die EBUSD_OPTS1 auszukommentieren und die EBUSD_OPTS umzubenennen in EBUSD_OPTS (vorher service ebusd stop) und dann service ebusd start.
Ach ja, EBUSD_OPTS ist aber schon auskommentiert oder?

[flash91]

Das meinte ich, aber das scheint nicht das Problem zu sein. Merkwürdig, da hab ich jetzt spontan keine Idee, woran es liegen könnte.
Probier mal die EBUSD_OPTS1 auszukommentieren und die EBUSD_OPTS umzubenennen in EBUSD_OPTS (vorher service ebusd stop) und dann service ebusd start.
Ach ja, EBUSD_OPTS ist aber schon auskommentiert oder?

Ohh hatte nicht gesehen dass im Konfig-File ganz oben zwischen den Kommentaren noch EBUSD_OPTS steht  .
Daran hats gelegen! Jetzt starten beide Instanzen normal. Danke 

Allerdings habe ich seit heute das Problem, dass ich über den ftdi2 keine updates mehr erhalte...
nicht mal mehr wenn ich den Prozess im Vordergrund starte, so wie gestern, obwohl ich immer folgende Meldungen erhalte:

Code Auswählen Erweitern


2016-10-22 16:10:26.251 [main notice] ebusd 2.2.af6e1c1 started
2016-10-22 16:10:26.262 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-22 16:10:26.267 [bus notice] signal acquired

und sonst nichts geändert habe (außer die Konfig).

Ich hab auch mindestens 5 min gewartet und auch den ftdi2 im raw-Modus kontrolliert, da kommen schön die aa und zwischendurch die Werte vom Wolf-Gerät mit 71 fe 50 17 10 01 01 7d ....

Über den ftdi1 funktionierts aber reibungslos...

Folgendes habe ich auch schon probiert:

• raspi reboot
• make uninstall, /home/pi/ebusd löschen, erneut von git auschecken und wieder kompiliert und installiert

Hast du noch einen schnellen Rat was ich sonst noch probieren könnte?
Andernfalls werde ich den Raspberry vermutlich nochmal komplett neu aufsetzen.

Edit: achja und beide Instanzen verwenden dieselbe "50.csv" in /etc/ebusd also sind Tippfehler darin ausgeschlossen.

[flash91]

Sehr seltsam... seit heute bekomm ich wieder updates für beide ftdi
Naja damit hat sich das hoffentlich auch erledigt ^^
Danke nochmal 

[john30]

Sehr seltsam... seit heute bekomm ich wieder updates für beide ftdi
Naja damit hat sich das hoffentlich auch erledigt ^^
Danke nochmal 

gerne