Läuft: Heizung mit eBus-Schnittstelle

[Reinhart]

also ich schreibe noch so und das funktioniert, auch über FHEM.

Code Auswählen Erweitern

# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write vrc430 mcHeatingCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*"
get HeizkurveSchreiben postproc  { $_ }

Code Auswählen Erweitern

pi@raspberry2 ~ $ ebusctl write vrc430 mcHeatingCurve 0.20
done


LG

[heikoh81]

Also interessant:
Wähle ich in FHEM einen neuen Wert, erscheint dieser als Wunschtemp. auf der Calormatic nach ca. 1-2 Sekunden (war glaub auch schon mit 0.5.0 so).
Der read-Befehl liefert aber noch ewig den alten Wert - und irgendwann nach zufälliger Zeit den neuen.

Woran kann das liegen?
War bei 0.5.0 nicht so, da kam der neue Wert sofort im Read.
Wird da irgendwas gecached?

UPDATE
Da wird tatsächlich was gecached.
https://github.com/john30/ebusd/wiki/3.-Commands

Read value(s) from a configured message. The result can either be returned from the cache (without accessing the eBUS at all) or retrieved directly from the slave by querying it via the eBUS.

read -f
==> -f          force reading from the bus (same as '-m 0')

Und tatsächlich:

Code Auswählen Erweitern


localhost: read -c vrc430 mcDesiredTemp
21.0

localhost: read -f -c vrc430 mcDesiredTemp
21.5

(Beide Befehle innerhalb von 2 Sekunden abgesendet).

Das ist wohl die Änderung in der 1.0.
Dann werde ich meinen Reads wohl überall das -f hinzufügen - möchte immer die aktuellen Werte auslesen!

[Reinhart]

ja das ist komisch, ich lese alles ohne Parameter und bekomme den Wert sofort!

Code Auswählen Erweitern

# Heizkurve lesen
get HKurve cmd {"r mcHeatingCurve\n"}
get HKurve expect "\d+\.\d+\n\n"
get HKurve postproc {$_}

zum Glück habe ich das was nicht gelesen!

LG

[Reinhart]

@heikoh81

ich habe jetzt viel getestet, aber ich schaffe es nicht, das mir der Wert verzögert ausgegeben wird. Ob ich mit "-f" oder nur mit "-c" oder ohne abfrage, erhalte ich den neuen SollWert immer sofort. Vielleicht ist das noch ein spezifisches Verhalten zwischen Master und Slave. Aber mit "-f" kann es sicher nicht schaden, den umsonst ist ja der Parameter nicht eingebaut worden. Der Parameter "-c" filtert ja nur gezielt auf die Klasse (vrc430) Eventuell verhält sich das nicht bei jedem Wert gleich? Kannst du vielleicht einmal mit der Heizkurve testen?

Code Auswählen Erweitern

pi@raspberry2 ~ $ ebusctl read -f mcheatingcurve
1.10

pi@raspberry2 ~ $ ebusctl read -c vrc430 mcheatingcurve
1.10

pi@raspberry2 ~ $ ebusctl read mcheatingcurve
1.10

hier im Beispiel habe ich den neuen Sollwert 1.10 vorgegeben und sofort in der Konsole die 3 Kommandos abgesetzt.

LG
Reinhart

[joachimS]

Hi,
ich habe jetzt das USB interface zusammen gelötet und es wird auch erkannt, hängt aber noch nicht am ebus.
Gibt es andere Funktionstests, Spannungen, die da sein müssen?

Auch find ich den ebusd code nicht mehr auf github.
Wo ist denn bitte der aktuelle code?
in contrib sind ja nur config Dateien
Thx!

[Reinhart]

Hallo Joachim

am besten du hängst das Interface an den Bus und stellst den Regler ein bis du einen vernünftigen Output in der Konsole bekommst. In der Konsole startest du wie folgt (sollte aber dann kein Dämon laufen, nur zum testen)

Code Auswählen Erweitern

ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888


Den eBus installieren kannst du wie folgt direkt am Raspberry:

Code Auswählen Erweitern

svn co https://github.com/john30/ebusd
cd /home/pi/ebusd/trunk
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo cp /home/pi/ebusd/trunk/contrib/etc/init.d/ebusd.debian /etc/init.d/ebusd 
sudo chmod 755 /etc/init.d/ebusd       
sudo update-rc.d ebusd defaults     
wenn der erste Befehl nicht funktioniert musst du noch das SVN installieren.

Code Auswählen Erweitern

sudo apt-get install Subversion

und eventuell noch:
sudo apt-get install autoconf
sudo apt-get install automake


Dann solltest du noch die /etc/default/ebusd anpassen:

Code Auswählen Erweitern

EBUSD_OPTS="-l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888"

so wird einmal alles nach /var/log/ebusd.log mitgeloggt

wenn du die paar Schritte ausgeführt hast, den Raspberry einmal booten und dann schauen ob der Dämon läuft:

Code Auswählen Erweitern

pi@raspberry2 /usr/bin $ ps -aux|grep ebusd
root      2677  0.4  0.5  36396  2604 ?        Ssl  Mär14   3:24 /usr/bin/ebusd -l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888
pi        3119  0.0  0.3   3596  1688 pts/1    S+   09:41   0:00 grep --color=auto ebusd
pi@raspberry2 /usr/bin $


[Jojo11]

Hallo,

nach einer etwas längeren Pause komme ich nun wieder dazu, mich dem ebus zu widmen. Ich hatte meinen Koppler vom Hersteller überprüfen lassen. Dieser scheint allerdings bestens zu finktionieren.
Folgendes Phänomen habe ich hier: Wenn ich den ebusd laufen lasse, steigt er nach ca. einem Tag aus und gibt nur noch die Fehlermeldung "Err: Arbitration lost" zurück. Ich habe gestern die aktuelle Version aus dem git installiert (1.0.0), hatte das Problem aber auch schon mit 0.5. Ich habe den ebusd gestartet und nur alle paar Stunden mal einen Wert abgerufen. In FHEM habe ich ihn noch nicht wieder eingebunden. Die LED des Kopplers blinkt wie im normalen Betrieb.
USB-Koppler trennen und wieder verbinden hilft nicht. Ebenso hilft seltsamer Weise ein kompletter Neustart des RPi nicht. Ich bin leider etwas ratlos, wo ich den Fehler suchen könnte  Legt der ebusd irgendwelche Dateien im Betrieb an, die ihn evtl. daran hindern, die Werte zu empfangen? Kann das etwas mit dem timing beim Empfang/Senden zu tun haben?

schöne Grüße
Jo

[Reinhart]

Hallo Jojo11!

Ich habe ja diese Meldungen auch, aber meist nur wenn FHEM gerade Abfragen macht und die zyklischen Telegramme der VRC430 kommen, so wie hier im Beispiel, mitten in der Abfrage kommt eine update notice:

Code Auswählen Erweitern

2015-03-15 13:10:02.528 [main notice] <<< 1095
2015-03-15 13:10:02.547 [main notice] >>> r BurnerStartsHWC
2015-03-15 13:10:02.662 [bus notice] read res: 0211098c
2015-03-15 13:10:02.662 [main notice] <<< 2321
2015-03-15 13:10:02.682 [main notice] >>> r OperatingHoursHC
2015-03-15 13:10:02.801 [bus notice] read res: 027b2ab7
2015-03-15 13:10:02.802 [main notice] <<< 10875
2015-03-15 13:10:02.821 [main notice] >>> r OperatingHoursHWC
2015-03-15 13:10:02.939 [bus notice] read res: 02b108e2
2015-03-15 13:10:02.939 [main notice] <<< 2225
2015-03-15 13:10:02.959 [main notice] >>> r FanOperatingHours
2015-03-15 13:10:02.998 [bus error] ERR: arbitration lost, retry
2015-03-15 13:10:03.082 [update notice] unknown MS cmd: 1008b51101028a / 05033c964666c4
2015-03-15 13:10:03.350 [bus notice] read res: 029f35ce
2015-03-15 13:10:03.350 [main notice] <<< 857.94
2015-03-15 13:10:03.366 [main notice] >>> r BurnerFaults
2015-03-15 13:10:03.484 [bus notice] read res: 01019a
2015-03-15 13:10:03.485 [main notice] <<< 1
2015-03-15 13:10:03.504 [main notice] >>> r BurnerStartFaults1
2015-03-15 13:10:03.619 [bus notice] read res: 010299
2015-03-15 13:10:03.619 [main notice] <<< 2
2015-03-15 13:10:07.105 [update notice] update MS SetBoiler: 1;77.0
2015-03-15 13:10:11.101 [update notice] update bai00 StatusTHER QQ=10: 31.0;31.0;15.125;31.0;36.0;0
2015-03-15 13:10:13.101 [update notice] unknown MS cmd: 1008b50401003d / 0a00384814ffffffff200fde
2015-03-15 13:10:13.321 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-15 13:10:15.145 [update notice] update MS SetBoiler: 1;77.0
2015-03-15 13:10:21.154 [update notice] update bai00 StatusTHER QQ=10: 31.0;31.0;15.125;31.0;36.0;0
2015-03-15 13:10:25.180 [update notice] update MS SetBoiler: 1;77.0
2015-03-15 13:10:31.189 [update notice] update bai00 StatusTHER QQ=10: 30.0;31.0;15.125;31.0;36.0;0
2015-03-15 13:10:33.235 [update notice] update broadcast vdatetime QQ=10: 14:07:03;15.03.2015
2015-03-15 13:10:33.490 [update notice] unknown MS cmd: 1008b512020064ae / 0000
20

Laut John und pah ist das aber normal, weil das eben gleichzeitige Aktivitäten am eBus sind. Wenn bei dir aber dieser Fehler erst nach einem Tag auftritt, kann es doch nur in irgend einer Hardware liegen, oder?  Ich habe heute das ganze Log bei mir durchforstet und seit Mitternacht etwa 30 solcher Errors gehabt, welche aber den normalen Betrieb absolut nicht stören. Ich frage aber alle 6 Minuten 19 Werte ab und FHEM steuert zwischendurch noch die Heizkurve.

Wenn du jetzt nichts abfragst sondern nur lauscht, dann kann es ja theoretisch auch eine andere Einheit sein die da am eBus solche Kollisionen hervorruft und dein Koppler meldet diese einfach. Wenn sich ab diesem Zeitpunkt dann nichts mehr tut kannst ja am Regler ein paar Kommandos absetzen (irgendwas ändern) und schauen ob die einerseits überhaupt an der Therme ausgeführt werden und wenn ja ob diese dann in der Konsole sichtbar ist. Wieviele Devices hast du denn am eBus hängen?
Eventuell auch einmal schauen ob die ebusd auch wirklich nur einmal am Raspi läuft. Ich hatte in der Anfangsphase auch mehrere Tasks laufen, da ist dann nichts mehr vorhersehbar.

Was machst du denn, das du den Koppler (eBus) dann wieder zum Laufen bekommst?

LG
Reinhart

[Reinhart]

@Jojo11

was mir noch eingefallen, du kannst ja einmal die Rawdata loggen.
Dazu einfach in der /etc/default/ebusd diese Optionline aktivieren (ändern und speichern) und dann einen Restart des ebusd durchführen.

Code Auswählen Erweitern

EBUSD_OPTS="--logfile /var/log/ebusd --lograwdata -d /dev/ttyUSB0 -p 8888"

Dann siehst du zumindest was sich da am Bus tut und welche Bytes hier noch empfangen werden. Musst halt einen Tag so laufen lassen bis der Fehler kommt. Wenn du dann den Inhalt postest, kann John das sicher erklären.

LG

[Jojo11]

Hallo Reinhart,

vielen Dank für Deine Tipps. Das log-file habe ich mal erstellt (s. Anhang). Ich habe nur ab und zu mal DisplayRoomTemp abgerufen, was wie folgt definiert ist:

Code Auswählen Erweitern


*r,vc470f,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,DisplayRoomTemp,display room temp,,,,8000,,,temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,


Wie ich den ebus jetzt wieder ans Laufen bringe weiß ich ehrlich gesagt nicht. Alles stromlos setzen und warten hilft glaube ich. Aufgrund akuten Zeitmangels hatte ich für eine systematische Fehlersuche leider noch keine Zeit. Langsam glaube ich, der RPi läuft nicht rund.

schöne Grüße
Jo

[Reinhart]

das Log müsste sich John einmal ansehen, ob ich mit meiner Vermutung richtig liege.
Was ich darin sehe ist die Tatsache, dass dein Koppler ständig "FF" sendet bis er mit der "arbitration lost" abbricht. Dann kommen am Bus ein paar zyklische Daten und er beginnt sofort wieder zu senden, als möchte er das Paket quittieren.

Code Auswählen Erweitern

2015-03-15 19:45:35.598 [bus notice] <46
2015-03-15 19:45:35.602 [bus notice] <8c
2015-03-15 19:45:35.606 [bus notice] <78
2015-03-15 19:45:35.610 [bus notice] <f5
2015-03-15 19:45:35.615 [bus notice] <00
2015-03-15 19:45:35.615 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-03-15 19:45:35.619 [bus notice] <aa
2015-03-15 19:45:35.662 [bus notice] <aa
2015-03-15 19:45:35.705 [bus notice] <aa
2015-03-15 19:45:35.706 [bus notice] >ff
2015-03-15 19:45:35.749 [bus notice] <aa
2015-03-15 19:45:35.750 [bus notice] >ff
2015-03-15 19:45:35.792 [bus notice] <aa
2015-03-15 19:45:35.793 [bus notice] >ff
2015-03-15 19:45:35.796 [bus notice] <10
2015-03-15 19:45:35.796 [bus error] ERR: arbitration lost,
2015-03-15 19:45:35.797 [main error] read: ERR: arbitration lost
2015-03-15 19:45:35.807 [bus notice] <08

hier so eine typische Situation, 1/10 Sekunde nachdem ein Wert am Bus gelesen wurde, beginnt der Koppler FF zu senden. Ich hoffe, ich deute das Log jetzt richtig. Ich kenne den Koppler den du verwendest leider nicht, aber man müsste einmal versuchen das Sendesignal zu unterbinden. Wenn das alles zugebaut ist, dann könnte man theoretisch eine Diode in Serie zum eBus Anschluß schalten. Also bei einem Draht vom eBus Anschluß des Kopplers eine Diode dazwischen schalten. Wenn sie verkehrt rum ist, dann empfängt er nichts mehr, dann einfach umdrehen. Den Versuch wäre es wert, falls du eine Diode herumliegen hast. (1N4148 oder 1N4007 etc.)

Bei mir sieht das ganz anders aus, mein selbstgebauter Koppler sendet niemals ">ff" !

PS: habe mir die Schaltung von pah nochmals angesehen, das mit der Diode wird nicht funktionieren, weil beim Senden zieht er einfach den High-Pegel auf etwa 8 Volt (LOW) herunter. Ich nehme an dein Buskoppler wird ja eine ähnliche Schaltung sein, zumindest dieselbe Funktion.

LG

[heikoh81]

ich habe jetzt viel getestet, aber ich schaffe es nicht, das mir der Wert verzögert ausgegeben wird. Ob ich mit "-f" oder nur mit "-c" oder ohne abfrage, erhalte ich den neuen SollWert immer sofort.

Zwischenzeitlich läuft bei mir alles, und ich habe meine ECMD-Dateien entsprechend angepasst, dass jetzt die Werte mit Force abgerufen werden.
Gecachte Werte brauche ich nicht
Bei Werten, die über Broadcast kommen (z.B. Außentemperatur), führt -f übrigens zu 0.0 - weil man Broadcast-Messages vermutlich nirgends anfordern kann.

Folgendes Phänomen habe ich hier: Wenn ich den ebusd laufen lasse, steigt er nach ca. einem Tag aus und gibt nur noch die Fehlermeldung "Err: Arbitration lost" zurück. Ich habe gestern die aktuelle Version aus dem git installiert (1.0.0), hatte das Problem aber auch schon mit 0.5.

Auch ich habe gelegentlich, vielleicht so 20-30 mal am Tag, diese Arbitration Lost.
Es funktioniert aber alles normal, sowohl lesen als auch schreiben.

====

Insgesamt habe ich jetzt auch Ramlog installiert & Logrotate für das ebusd-log, das mit loglevel error läuft.
Soweit alles gut mit 1.0.0.

Nochmal dank an alle.

[Reinhart]

@heikoh81

Super wenn nun bei dir auch alles klappt, ja es waren einige Änderungen von 0.5 auf 1.0, ich habe alle Zwischenschritte mitgemacht. Ich bin sehr zufrieden mit dem eBus und schon lange im Produktiv Betrieb.

Die Außentemperatur hole ich über die bai00.csv und nicht über den Status dann klappt es auch mit "-f".

Code Auswählen Erweitern

pi@raspberry2 ~ $ ebusctl r -f -c bai00 outsidetemp
12.94;ok


bai00.csv

Code Auswählen Erweitern

r,,OutsideTemp,d.47 => Außentemperatur  ,,,,7600,,,tempsensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

LG
Reinhart

[john30]

Wie ich den ebus jetzt wieder ans Laufen bringe weiß ich ehrlich gesagt nicht. Alles stromlos setzen und warten hilft glaube ich. Aufgrund akuten Zeitmangels hatte ich für eine systematische Fehlersuche leider noch keine Zeit. Langsam glaube ich, der RPi läuft nicht rund.

Hallo Jo,
was hast Du denn genau für ein eBUS Interface? Hängt der via USB dran und wenn ja, mit welchem Chipsatz? Falls nein, hängt er an der RPi GPIO UART? Die macht gravierende Timing Probleme, weil der UART so eingestellt ist, dass bis zu 16 Bytes gecacht werden, was einen Sendebetrieb in der Form völlig unmöglich macht (wegen der Arbitration).

Fragen über Fragen
LG John

[john30]

Bei Werten, die über Broadcast kommen (z.B. Außentemperatur), führt -f übrigens zu 0.0 - weil man Broadcast-Messages vermutlich nirgends anfordern kann.

Hallo Heiko,
mit welcher Version hast Du das denn so? Also frisch von GIT oder Release 1.0.0 oder was anderes?
Das klingt mir sehr nach dem Bug, den ich auch gern fixen würde...
LG John