Läuft: Heizung mit eBus-Schnittstelle

[joachimS]

Mein log sieht ja ähnlich aus wie bei Jojo11.
Habe wie Jojo11 die Zeit im ebusd system und im Wolf BM synchronisiert und auch das wolf directory nach /etc/ebusd kopiert, so dass der ebusd jetzt 9 messages findet.
Der log zeigt aber dieselben messages 

[Jojo11]

Mein log sieht ja ähnlich aus wie bei Jojo11.
Habe wie Jojo11 die Zeit im ebusd system und im Wolf BM synchronisiert und auch das wolf directory nach /etc/ebusd kopiert, so dass der ebusd jetzt 9 messages findet.
Der log zeigt aber dieselben messages 

Die messages sind bei mir nicht das Problem. Im Gegenteil, sie zeigen ja, dass der Koppler am ebus mitlesen kann. Mit den entsprechenden (zu Deiner Anlage passenden) .csv-Dateien kannst Du sie "übersetzen".

schöne Grüße
Jo

[john30]

habe jetzt die aktuelle Version gebaut und die neuen config files verwendet. Seitdem erhalte ich bei den messages im daemon fast nur noch "unknown ms ..."

Folgende config files verwende ich bei o.g. Scan:bai.csv, pms.csv, pmw.hwc.csv ,solsy.cc.csv  ,solsy.mc.csv,  _templates.csv, broadcast.csv , pms.sc.csv, scan.csv, solsy.hc.csv, solsy.sc.csv , ui.csv
Woran liegt das?

Dazu müsstest Du mal ein paar Zeilen vom Log preis geben, sonst kann ich dazu nichts sagen.

Wenn ich zusätzlich die solsy.cc.csv erscheint beim reload "Duplicate entry" error.

Du hast glaub ich die solsy.hwc.csv zusätzlich gemeint. Das liegt daran, dass Du bereits eine hwc curcuit in den Config-Files hast, nämlich die pmw.hwc.csv, das verträgt sich nicht gut. In diesem Falll müsstest Du in einer der beiden Dateien in den Zeilen 3-5 bzw. 3-6 aus ",hwc," z.B. ",hwc1," machen, um einen anderen Circuit-Namen dafür zu vergeben.

Wie ist das denn, macht Deine auromatic Warmwasser und Deine Frischwasserstation auch?

[john30]

Bei checkconfig kommt kein Fehler. Allerdings erscheint bei ebusd -V weiterhin 1.0.0. das versteh ich nicht.

Probier mal "which ebusd" und schau, wohin das andere frisch compilierte ebusd File abgelegt wurde.

[john30]

Habe ich gemacht und auch das Poti mal durchgedreht.
Ergebnis:

Code Auswählen Erweitern

odroid@SmartHome:~$ ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --lograwdata
2015-03-30 18:59:23.807 [main notice] ebusd started
2015-03-30 18:59:23.808 [main error] error reading templates: ERR: element not found
2015-03-30 18:59:23.808 [main notice] found messages: 0 (0 poll, 0 update)
2015-03-30 18:59:47.094 [bus notice] <00
2015-03-30 18:59:47.094 [bus notice] signal acquired
2015-03-30 18:59:47.119 [bus notice] <00
2015-03-30 18:59:47.441 [bus notice] <00
2015-03-30 18:59:47.461 [bus notice] <00
2015-03-30 18:59:47.624 [bus notice] <00
2015-03-30 18:59:47.873 [bus notice] <00
2015-03-30 18:59:48.431 [bus notice] <00


Sehr bizarr. Mach doch mal für ne Minute einen dump ("ebusctl dump") und schick mir die Datei via PN oder einfach an ebusd@johnm.de

[john30]

Dann ist mir aufgefallen, dass die Zeit des RPi noch nicht stimmt.

Das ist ein wichtiger Hinweis. Vielleicht kann ich dadurch das Mysterium entschlüsseln.
Hast Du einen NTP konfiguriert?
Falls nicht, dann schau doch mal alle 60 Sekunden, wie sich die Systemzeit auf dem RPi im Vergleich zu der richtigen Uhrzeit ändert.
Ich vermute, dass da ein Problem im Detail steckt.

Ich kann sogar wieder Werte abfragen (mit den entsprechenden .csv-Dateien). Ansonsten habe ich nichts geändert. Leider verstehe ich dieses Verhalten in keinster Weise. Kann die "Fehlfunktion" wirklich daran liegen, dass die Therme eine andere (=spätere) Zeit hatte (DCF-Funkuhr) als der RPi? Oder kann der Zeitpunkt des Startens des ebusd eine Rolle spielen?

Nein, daran liegt es nicht.
Der ebusd macht aber für die Arbitrierung am Bus ein paar zeitlich abhängige Operationen und wenn Deine Systemzeit wild durch die Gegend springt, bringt das alles durcheinander.

Nachtrag: Bei genauerer Betrachtung funktioniert z.B. mit der 470er csv-Datei "read OutsideTemp" ohne Probleme. "read RoomTemp" endet aber zuverlässig immer in einem "ERR: arbitration lost". Kann es etwas damit zu tun haben, dass die OutsideTemp ohne vorheriges Senden bereitgestellt wird? Das würde die Theorie untermauern, dass der Koppler nicht senden kann.

Richtig, die outsidetemp kommt vermutlich vom broadcast, den der ebusd ja mitlesen kann. Wenn er aber nicht schreiben kann, dann kannst Du niemals aktiv irgendwas von einem anderen Gerät abfragen.

Ich vermute aber, dass dieses Problem auch mit deinem Zeitproblem in Zusammenhang steckt.

[Jojo11]

Das ist ein wichtiger Hinweis. Vielleicht kann ich dadurch das Mysterium entschlüsseln.
Hast Du einen NTP konfiguriert?
[...]
Ich vermute aber, dass dieses Problem auch mit deinem Zeitproblem in Zusammenhang steckt.

Hallo John,

NTP habe ich konfiguriert. Ich verwende einen RPi mit debian wheezy. Das kommt von Haus aus mit NTP. Habe aber jetzt mal ntpdate eingerichtet.
Danach reboot und ebusd wieder gestartet: OutsideTemp geht auch nicht mehr (broadcast-Meldung): "ERR: arbitration lost". Mit Option -f bekomme ich wieder nur "signal lost"/"signal acquired" (s. oben).

Ich hatte mich vor kurzem lange mit dem Hersteller vom ebus-Koppler (eservice) unterhalten und ihm das Problem geschildert. Er vermutet auch ein timing-Problem. Der Koppler sei Hardware-seitig in Ordnung. Frage ich mich allerdings, warum nur ich diese Schwierigkeiten habe...? Der RPi ist weit verbreitet, der Koppler auch und meine Therme ist einen einfache Vaillant 206 mit 470f-Steuergerät 

schöne Grüße
Jo

[Prof. Dr. Peter Henning]

Ich vermute, dass irgendwelche Prozesse auf dem RPi laufen und den bis an die Grenze belasten - oder er einen Hardware-Defekt hat

Habe schon einmal vorgeschlagen, den Buskoppler zu Testzwecken an einem anderen Rechner zu betreiben.

Man könnte auch mal ein komplett neues Image für das Betriebssystem auf eine neue SD-Karte spielen, und nur ebusd installieren.

LG

pah

[stinch]

@john30 & Reinhard:

Vielen Dank für eure Hilfe. Inzwischen habe ich version 1.1.0 compiliert. Die genannten Probleme bestehen jedoch unverändert weiterhin mit den neuen csv files.
Die alten funktionieren problemlos. Irgendeine Idee?

Viele Grüße
David

[Reinhart]

@stinch

wenn du schreibst, die alten funktionieren problemlos, was meinst du genau damit? Funktionieren die neuen Files aus der Konsole oder aus Fhem nicht?

John hat mit den neuen 1.1.0er CSV's ja einiges an der Namensgebung geändert und zum Schluß nochmals, da hat er diesen komischen Text "DK" noch entfernt. Ich musste hier ebenfalls meine Abfragen alle nach der neuen Namensgebung in Fhem umstellen.
Wenn dich nur die die "Textlosen" Meldungen in der Konsole stören, dann mache John einen "grab" und lade ihm das Ergebnis ins Git als Kommentar hoch! Siehe hier: http://forum.fhem.de/index.php/topic,29737.msg278309/topicseen.html#msg278309

Code Auswählen Erweitern

pi@raspberry2 /etc/init.d $ ebusctl grab
done

pi@raspberry2 /etc/init.d $ ebusctl grab result
1008b5040100 / 0a00012723ffffffff800d
1008b5110101 / 093636800d3a3e0000ff
1008b5110102 / 05033c964666

sieht dann so ungefähr aus, bei dir wird es wesentlich mehr sein.
Anhand der vielen unterschiedlichen Konfigurationen an Geräten kann John dann versuchen eine "gemeinsame" common.csv zusammen stellen die für möglichst alle gilt. Ob es tatsächlich so einfach geht weiß ich nicht, aber so helfen wir ihm zumindest damit.

Hier kannst du dein Ergebnis für John dann posten: https://github.com/john30/ebusd-configuration/issues/3

LG
Reinhart

[Jojo11]

Ich vermute, dass irgendwelche Prozesse auf dem RPi laufen und den bis an die Grenze belasten - oder er einen Hardware-Defekt hat

Habe schon einmal vorgeschlagen, den Buskoppler zu Testzwecken an einem anderen Rechner zu betreiben.

Man könnte auch mal ein komplett neues Image für das Betriebssystem auf eine neue SD-Karte spielen, und nur ebusd installieren.

LG

pah

Hallo pah,

wie oben geschrieben habe ich alles ausgetauscht: Neuer RPi, neue SD mit frischem wheezy, neues Netzteil, neues USB-Kabel und abgeschirmtes Kabel zur Therme (3 m lang). Ich habe nur wheezy installiert, LAN eingerichtet, NTP installiert und den ebusd natürlich.

schöne Grüße
Jo

[Prof. Dr. Peter Henning]

Und anderer Computer ?

LG

pah

[Jojo11]

Und anderer Computer ?

LG

pah

Bin mir jetzt nicht sicher, welchen Du meinst. Der Raspberry wurde getauscht. Auf ihm läuft der ebusd und an ihn ist der Koppler angeschlossen. Sonst habe ich nur PC usw. von dem ich per SSH auf den RPi zugreife. FHEM läuft auf einem cubietruck, aber bisher versuche ich nur, den RPi mit Therme, Koppler und ebusd zum Laufen zu bringen.

schöne Grüße
Jo

[stinch]

wenn du schreibst, die alten funktionieren problemlos, was meinst du genau damit? Funktionieren die neuen Files aus der Konsole oder aus Fhem nicht?

ich meine damit, dass ich mit den neuen Files in der Konsole viele "unknown ms" erhalte, die mit den alten Files decodiert werden.
ich nutze gar kein fhem. ich speichere die werte mittels vwmon in eine mysql Datenbank und lese dort die werte mittels php aus und gebe sie an meinen knx server weiter.

Viele Grüße
david

[Prof. Dr. Peter Henning]

@Jo. Eben

Ich schlage vor, einen Desktop-Computer mit ebusd zu versehen und per USB (-Externder) mit dem Buskoppler zu verbinden.

LG

pah