eBus Schaltung in Betrieb nehmen

Begonnen von Reinhart, 23 Dezember 2015, 15:19:45

Vorheriges Thema - Nächstes Thema

Reinhart

eBus Schaltung in Betrieb nehmen!

Dieser Thread dient als Unterstützung für den Nachbau und der Inbetriebnahme der Ebus-Schaltung nach pah seinem Entwurf.
Da der Thread des eBus schon sehr lange und unübersichtlich wird, habe ich alles was die Schaltung und den Testbetrieb der Schaltung betrifft hier gesammelt wieder gegeben. Anlass war die Sammelbestellung von 50 Platinen für den eBus die in wenigen Tagen bei den Usern eintreffen und einige Fragen schon im Vorfeld abklären sollten.

Als Unterstützung sollte man als erstes das Wiki lesen! 
Bei allgemeinen Problemen rund um die Software "eBusd" bitte diesen Thread benutzen.
EBusd Installation ist hier.
Anbindung an Fhem bitte hier weiter.

Link zum automatischen Installer!



Diese Beschreibung sollte hauptsächlich für Personen dienen, bei denen es nicht das tägliche Brot ist elektronische Schaltungen in Betrieb zu nehmen. Ich setze hier voraus, dass der Umgang mit einem Lötkolben klar ist. Wer noch nie gelötet hat, sollte besser einen Bekannten ersuchen der das schon gemacht hat.
Wer eine fertige Platine hat, ist etwa in 30 Minuten mit der Bestückung der Platine fertig. Wer die Schaltung selbst auf einer Lochrasterplatine machen will, muss schon einige Stunden dafür aufbringen.

http://www.fhemwiki.de/w/images/5/55/EBUS-IF-USB.png
(http://www.fhemwiki.de/w/images/5/55/EBUS-IF-USB.png)
Die Schaltung des eBus von Prof. Dr. Peter A. Henning (aus dem Wiki verlinkt).


Probeaufbau:
(http://up.picr.de/24052707hf.png)
Hier ein Beispiel eines Aufbaues auf einer Lochrasterplatine. Sieht nicht ganz so schön aus, tut aber genau so seine Dienste und ist natürlich etwas aufwändiger was die Lötarbeit betrifft. Für kleine Prototypen immer noch die ideale Art, besonders wenn es schnell gehen muss und man auf Platinenbestellungen nicht warten will.



fertige Platine:


(http://up.picr.de/24044459gu.png)

so sieht eine fertige Platine aus wie sie aus den Gerberfiles gefertigt wird. Es gibt zahlreiche Anbieter von Platinenfertigungen, auch aus dem deutschsprachigen Raum. Bei der Sammelbestellung von 50 Stück kamen wir auf einen Preis von knapp 1.- € bei einem asiatischen Hersteller. 5 Platinen gab es dann noch als Zugabe.


(http://up.picr.de/24044456sa.png)

bei der Bestückung sollte geachtet werden mit den niedrigsten Bauteilen zuerst zu beginnen, sonst fallen sie beim verlöten ständig heraus.

 
(http://up.picr.de/24045014ko.png)

in der Version 1.5 ist noch ein kleiner (Schönheits)Fehler, welcher jedoch mit einer kleinen Lötbrücke (man verbindet Pin 14+13+12) schnell beseitigt wird. Da es sich bei dem 4011 um einen CMos  handelt, ist es von Vorteil alle offenen Eingänge (oder unbenutzte Gatter) auf einen logischen Pegel zu legen damit es zu keinen Schwingneigungen im Betrieb kommen kann. Aber bitte nur Eingänge (12+13), niemals Ausgänge außer über einen hochohmigen Widerstand!


(http://up.picr.de/24052604qc.png)

Es empfiehlt sich zusätzlich (wie hier abgebildet) bei CMos IC-Sockel mit Blockkondensator zu verwenden.
Die Sockel sind zwar etwas teurer, leisten aber gute Dienste und sind extrem kurz an der Versorgungsspannung was ein wichtiger Faktor ist.
Wer so einen Sockel nicht zur Verfügung hat, kann auch einen 10nF Kondensator hinten auf die Platine löten. Unbedingt notwendig ist er nicht, kann aber Störungen im Betrieb vermeiden helfen.


(http://up.picr.de/24052608gw.png) 

Nach fertiger Bestückung und nochmaliger Endkontrolle der Lötstellen und der Bauteile, sollte man die Schaltung (ohne eBus) kontrollieren und kann auch gleich eine Grobabstimmung des Potentiometers durchführen. Dazu verwende ich ein regelbares Netzgerät (5-24 Volt) am Eingang des Schaltung. Bitte niemals direkt anschließen, sondern über einen Vorwiderstand von etwa 330 Ohm damit in Senderichtung kein Kurzschluss am Transistor entsteht. Ich habe hier Abstimmung noch schnell eine LED an RXD angeschlossen, damit ich rein optisch den Schaltpunkt sehe. Dann stelle ich das Netzgerät auf etwa 12.0 Volt (an der eBusklemme gemessen) und drehe das Poti so lange bis die Led gerade NICHT leuchtet. Erhöhe ich die Spannung um ein kleines bisschen, dann sollte die Led leuchten. Die meisten so abgestimmten Platinen brauchen keine Feinabstimmung mehr. Die Spannung von 12.0 Volt kann jedoch bei anderen Signalpegeln des eBus (andere Therme oder Hersteller) etwas abweichen. Bei der Abstimmung muss unbedingt der RS232-Konverter angeschlossen sein und an einem USB Stecker wie Laptop versorgt werden, damit die Schaltung auch Versorgungsspannung hat.
Manche RS232 Konverter haben Leds am Eingang und damit kann auch prima direkt am eBus abgestimmt werden. Beginnt die RxD zu flackern, dann soweit drehen bis es aufhört und dann wieder um die Hälfte zurück damit die Mittelstellung erreicht wird. Es sind aber nur wenige Millimeter wo die Schaltung funktioniert.
Hier noch eine nützliche Einstellhilfe von John30 direkt am eBus ohne erforderliches Zubehör.

(http://up.picr.de/24052607mu.png)
bei dieser Spannung sollte die Led noch nicht leuchten! So lange am Poti drehen bis sie "gerade" erlischt.

(http://up.picr.de/24052611nr.png)
so ein primitives kleines Netzgerät kann gute Dienste leisten. Wer so etwas nicht zur Verfügung hat, muss wohl die Abstimmung an der Therme durchführen. Hier schön zu sehen der Vorwiderstand zur Spannungsversorgung der Platine. NIEMALS an den eBus der Heizungsanlage anschließen!

(http://up.picr.de/24052606lw.png)


wer es ganz genau machen will, soll sich ein Trimpotentiometer besorgen, hier ist die Abstimmung etwas leichter. zu bewerkstelligen.


(http://up.picr.de/24052605zc.png)
so wie hier dargestellt, schaltet die Led schon bei 12,19 Volt durch.

(http://up.picr.de/24052609vr.png)

mit einem Schraubendreher wird hier abgestimmt, man braucht fast 3 Hände dazu um auch gleichzeitig zu messen, aber das erledigt ja die behelfsmäßige Led und man kontrolliert die Spannung nachher.


(http://up.picr.de/24052612ke.png)

hier noch der Schaltplan mit einigen wichtigen Spannungen für den Testbetrieb am Netzgerät. Bitte beachtet den Widerstand am Eingang des eBus und die Anschaltung der behelfsmäßigen Led zur Abstimmung. Spätestens dann, wenn die Schaltung auf Anhieb nicht funktionieren sollte,  werdet ihr über so einen Versuchsaufbau nicht herum kommen. Hier kann in Ruhe die Schaltung getestet und gemessen werden. Defekte Bauteile oder fehlerhafte Lötstellen sollten dann schnell gefunden werden.


Ich wünsche viel Erfolg bei der Inbetriebnahme.


Bekannte Fehler:
nicht alle RS232 Konverter verhalten sich auf dieser Schaltung gleich, es kann sein das einige ungeeignet dafür sind oder sehr schwer abzustimmen sind. Der wie oben im Bild dargestellte eignet sich sehr gut, achtet auf den FTDI-Chip.

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

#1
Software Installation und Test!


Alle wichtigen Informationen findet man in der Wiki von John30!
Hier noch ein wichtiger Hinweis von John30 betreffend der Installation.


Im Prinzip sollte man sich überlegen ob man für den eBus einen eigenen Rechner nimmt oder auf der bestehenden Fhem Installation laufen lassen sollte. Ich empfehle eine Trennung, da dies mehrere Vorteile speziell zum Testen anbietet.


(http://up.picr.de/24055307fd.png)
hier meine Konfiguration von Fhem und das Zusammenspiel mit eBusd via ECMD, bitte nur als Beispiel zu sehen, kann aber jeder handhaben wie es am Besten ins Konzept passt.


Hier in Kurzübersicht die wichtigsten Befehle zur Installation von ebusd für einen Raspberry Pi unter Debian.

zunächst wird aus dem Git ausgecheckt:
git clone https://github.com/john30/ebusd.git

falls das nicht funktioniert sollte vorher noch git auf dem Raspi aktualisiert (installiert)  werden:
apt-get install git autoconf automake g++ make

(http://up.picr.de/24055308gf.png)



cd ebusd
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo update-rc.d ebusd defaults

um die Binary zu compilieren mache ich das immer so.

Das kann je nach Geschwindigkeit des Rechners schon um die 20 Minuten dauern. Nach erfolgter Meldung kann schon getestet werden welche Version nun auf dem Rechner ist und ob der Dämon überhaupt schon läuft.

pi@raspberry2 ~ $ ps -ax | grep ebus
2236 ?        Ssl   14:10 /usr/bin/ebusd -l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888 --httpport=80 --htmlpath=/var/www
[code]


[code]pi@raspberry2 ~ $ ebusd -V
ebusd 2.0.0-preview.79cbd56


Zur Kontrolle sollte noch gecheckt werden ob das Logfile (var/log/ebusd.log) auch richtig angelegt wurde und ob schon Einträge vorhanden sind.


Logfile:

Das Logfile ist zur Inbetriebnahme unerlässlich und kann (zB. mit PsPad) ausgelesen werden.



2015-12-22 16:27:34.015 [bus error] signal lost
2015-12-22 16:27:34.195 [bus notice] signal acquired
2015-12-22 16:28:12.029 [bus error] signal lost
2015-12-22 16:28:12.339 [bus notice] signal acquired
2015-12-22 16:28:14.006 [bus error] signal lost
2015-12-22 16:28:16.372 [bus notice] signal acquired
2015-12-22 16:28:18.023 [bus error] signal lost
2015-12-22 16:28:18.729 [bus notice] signal acquired
2015-12-22 16:28:20.458 [update notice] update myCustom Status01: 43.0;41.0;8.000;41.0;38.0;ok
2015-12-22 16:28:26.460 [update notice] update bc Mode QQ=10: standby
2015-12-22 16:28:30.436 [update notice] update myCustom Status01: 41.0;40.0;8.000;41.0;38.0;ok
2015-12-22 16:28:32.458 [update notice] update broadcast vdatetime QQ=10: 16:24:52;22.12.2015
2015-12-22 16:28:32.696 [update notice] update myCustom2 Pumpenstatus: ok
2015-12-22 16:28:36.452 [update notice] update bc Mode QQ=10: standby
2015-12-22 16:28:40.478 [update notice] update myCustom Status01: 40.0;39.0;7.750;41.0;38.0;ok
2015-12-22 16:28:42.482 [update notice] update myCustom1 Status11: nosignal;41;5;18;-;-;-;-;8.000
2015-12-22 16:28:42.753 [update notice] update myCustom Status02: auto;60;70.0;70;54.0


hier ein typisches Log wenn das Poti noch nicht kalibriert wurde.
Ab dem Eintrag 16:28:20.458 war dann die richtige Stellung gefunden. Das Poti soll daher zunächst ganz nach links (Transistor der Platine ist dann rechts unten) gedreht werden und dann vorsichtig auf etwa 2:00 Uhr. Bei knapp 2:00 Uhr ist bei mir die ideale Stellung. Der Stellbereich ist sehr klein (etwa 1-2 mm), daher einen Schraubendreher verwenden der sehr exakt passt und gleichzeitig mit dem Laptop abfragen starten. Zur Kontrolle dann das Log (var/log/ebusd.log) abfragen. Im Anschluß teste ich dann noch Befehle wie Heizkurve verstellen oder Offset für Außentemperatur, diese sieht man dann auch innerhalb von Sekunden in der Anzeige der Temperatur.

2015-11-29 06:26:55.271 [update notice] update myCustom1 Status11: nosignal;40;0;15;-;-;-;-;-0.188
2015-11-29 06:26:55.541 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-11-29 06:26:59.293 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:03.323 [update notice] update myCustom Status01: 53.0;45.0;-0.438;47.0;46.0;error
2015-11-29 06:27:05.268 [update notice] update broadcast outsidetemp QQ=10: -3.188
2015-11-29 06:27:09.344 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:11.934 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:11.981 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.025 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.069 [bus error] send to 08: ERR: read timeout


in diesem Fall liegt ein Fehler bei jedem Sendeversuch vor. Ein "bus error" mit timeout sollte nicht (zu oft) zu finden sein. Gut zu sehen sind schon die Broadcast Meldungen, die selbständig über den Bus laufen und vom Konverter schon richtig interpretiert werden. Sollten wie in diesem Fall, die Meldungen nicht mit Texten zu lesen sein fehlen noch die Konfigurationfiles (csv) im Verzeichnis /etc/ebusd. Welche Files hier verwendet werden sollen ist von der Therme und dem Zubehör abhängig.

pi@raspberry2 /etc/ebusd $ ls -al *.csv
-rw------- 1 pi pi 16908 Nov 28 18:34 430.csv
-rw-rw-rw- 1 pi pi 19588 Nov  7 19:05 bai.csv
-rwxrwxrwx 1 pi pi  2547 Okt 10 18:18 broadcast.csv
-rw-rwxrwx 1 pi pi   869 Sep 18 14:26 common.csv
-rw------- 1 pi pi  1104 Okt 24 19:12 error.csv
-rwxrwxrwx 1 pi pi   371 Sep 12 16:01 scan.csv
-rw-rw-rw- 1 pi pi  3406 Okt 10 18:14 _templates.csv

hier meine Konfigurationen bei einer Vaillant Therme mit Calormatic 430.

Bei einer korrekten Funktion des Schaltung sollte das Logfile wie folgt aussehen:
2015-12-23 16:55:42.922 [update notice] update myCustom Status01: 33.0;33.0;7.125;35.0;37.0;ok
2015-12-23 16:55:44.919 [update notice] update myCustom1 Status11: nosignal;12;17;19;-;-;-;-;7.125
2015-12-23 16:55:45.139 [update notice] unknown BC cmd: 10feb505020400
2015-12-23 16:55:46.920 [update notice] update bc Mode QQ=10: standby
2015-12-23 16:55:52.984 [update notice] update myCustom Status01: 33.0;33.0;7.125;35.0;37.0;ok
2015-12-23 16:55:56.962 [update notice] update bc Mode QQ=10: standby
2015-12-23 16:56:02.984 [update notice] update myCustom Status01: 33.0;32.0;7.125;35.0;37.0;ok
2015-12-23 16:56:04.973 [update notice] update broadcast vdatetime QQ=10: 16:52:23;23.12.2015
2015-12-23 16:56:05.230 [update notice] update myCustom2 Pumpenstatus: ok
2015-12-23 16:56:06.959 [update notice] update bc Mode QQ=10: standby
2015-12-23 16:56:11.004 [update notice] update myCustom Status01: 33.0;32.0;7.125;35.0;37.0;ok
2015-12-23 16:56:13.002 [update notice] update myCustom1 Status11: nosignal;41;17;19;-;-;-;-;7.125
2015-12-23 16:56:13.273 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-12-23 16:56:16.978 [update notice] update bc Mode QQ=10: standby
2015-12-23 16:56:21.009 [update notice] update myCustom Status01: 33.0;32.0;7.125;35.0;37.0;ok
2015-12-23 16:56:22.934 [update notice] update broadcast outsidetemp QQ=10: 4.125
2015-12-23 16:56:27.013 [update notice] update bc Mode QQ=10: standby


"nosignal" bedeutet hier nur, das im Außenfühler kein DCF Signal zur Verfügung steht (ist bei mir nicht eingebaut) und hat und deutet auf keinen Übertragungsfehler hin!


Sendeversuche:

pi@raspberry2 /etc/ebusd $ ebusctl read -m 10 outsidetemp
4.125

hier ein Versuch die Aussentemperatur abzufragen, ist in diesem Fall ok.

pi@raspberry2 /etc/ebusd $ ebusctl write 430 OutsideTempOffset -1.0
done

pi@raspberry2 /etc/ebusd $ ebusctl read -m 10 OutsideTempOffset
-1.0

in diesem Beispiel wird das Offset (zur Kalibrierung des Aussenfühlers) auf -1,0 Grad eingestellt und in die Calormatic 430 geschrieben. In der 2. Zeile wird sie wieder abgefragt ob das Ergebnis ok ist. Eventuell sollte jetzt das Log kontrolliert werden ob hier keine Fehlermeldungen durch den Sendeversuch kommen.

Sollte bis jetzt alles ok sein, steht der weiteren Einbindung in Fhem nichts mehr im Wege. Ob ihr das mit GAEBUS oder der herkömmlichen Methode mit ECMD realisiert, ist im Prinzip egal. GAEBUS ist einfacher, man sollte sich aber im Thread dort einlesen.

CSV Files:
Wie bereits oben erwähnt ist der Output des eBusd abhängig von den korrekt eingerichteten CSV-Files. Die aktuellen CSV-Files gibt es hier im Wiki. Auch auf Sourceforge hat pah seine Sammlung veröffentlicht.
Hier die letzten CSV von John Version 2.xx als Debian Paket zum installieren!

Teilweise sind jedoch immer wieder Anpassungen an persönliche Bedürfnisse oder andere HW-Konfigurationen durzuführen. Ich möchte euch daher meinen aktuellen Stand für Vaillant Therme EcoTecPlus und Calormatic 430 nicht vorenthalten. Es sind hier die Zeitprogramme (von der 470) mit übernommen und noch verschiedene Kleinigkeiten angepasst (File siehe Anhang).

pi@raspberry2 ~ $ ebusctl r -f mcTTMonday
0;03:30;19:30;-:-;-:-;-:-;-:-;Mo-So

pi@raspberry2 ~ $ ebusctl r -c 470mc mcTTMonday
0;03:30;19:30;-:-;-:-;-:-;-:-;Mo-So

pi@raspberry2 ~ $ ebusctl w -c 470mc mcTTMonday "04:00;19:30;24:00;24:00;24:00;24:00;selected"
done


ein Beispiel wie ich Zeitprogramme abfrage oder korrekt setze.
Weitere komplette Beispiele wie man das in Fhem integriert habe ich hier gepostet.

(http://up.picr.de/24061987mp.png)
Fhem Ansicht des oben geposteten Beispiels.


(http://up.picr.de/24062138ph.png)
hier noch eine Tablet Variante, welche ich mit FTUI erstellt habe. Hier habe ich eine Übersicht über die wesentlichen Varianten der Heiztherme die mich interessieren.

(http://up.picr.de/24062139uy.png)
und hier noch die Möglichkeit einer Timereingabe im Tabletmodus.

Es gibt noch einige weitere Beispiele was man mit den Ebusdaten alles anfangen kann. Hier einige Lösungen mit YAF.
Wie man sieht sind die Möglichkeiten des eBus noch lange nicht erschöpft und der Phantasie stehen hier alle Türen offen. Ob man solche Spielereien wirklich braucht sei dahin gestellt, aber primär geht es um die technische Machbarkeit. Danke an die Entwickler der Software eBusd die solche Spielereien erst ermöglichen!

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

sua

#2
Danke Reinhart für Deine Mühe, cooler Service.  8)

Füge doch bitte noch oben ein, daß es ggf. notwendig ist, vor dem git noch einige zusätzliche Softwarepakete (incl. git) zu installieren:
apt-get install git autoconf automake g++ make

LG,
sua

cs-online

Schließe mich Sua an, wirklich gut gemacht !!!

Grüße

Christian
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20, Shelly1,2 und 2.5,Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV mit Speicher, alles auf einem RPI und da geht noch mehr

Reinhart

#4
wenn jemand was auffällt oder abgeht, einfach hier posten. Wenn es ganz wichtig ist (so wie der Hinweis von sua) dann hänge ich es in den ersten Post hinein.

Ich bin mir ziemlich sicher, wenn die 50 Platinen aus der Sammelbestellung in den nächsten Tagen/Wochen gebaut werden, dass nicht alle auf Anhieb funktionieren werden. Spätestens dann sollte dieser Thread euch wertvolle Hilfe geben oder zumindest könnt ihr euch dann hier mit der gewonnen Erfahrung austauschen!

Ich halt euch die Daumen auf gutes Gelingen! Die von mir bis jetzt 4 gebauten Platinen dieser Bestellung haben aber alle auf Anhieb funktioniert. Also Platinen Fehler gibt es schon mal keine!

Noch ein Tipp am Rande, wer die Farbcodes der Widerstände nicht auswendig kennt, einfach mit dem Messgerät nachmessen. Oft ist es schwierig den Anfang der Codes zu erwischen (links oder rechts beginnen), besonders wenn die Augen (so wie bei mir) nicht mehr die Besten sind. Der nicht in der Schaltung eingezeichnete Pullupwiderstand (links unten neben dem seriellen Anschluß) beträgt 100 KOhm. Ist aber logisch, denn der wird euch sonst übrig bleiben. Dieser Widerstand ist dann besonders wichtig, wenn ihr im Sendeweg Fehler suchen müsst. Dann müsst ihr nämlich den TxD vom RS232 Konverter abziehen und habt trotzdem noch einen definierten Eingangspegel, welcher letztlich den Darlington-Transistor durchsteuern sollte. Somit sind auch die "Sendefehler" in der Schaltung (gab es schon etliche, bei mir war nach einem Jahr plötzlich die Zenerdiode defekt) leichter zu finden.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

Zitat von: ms_9 am 23 Dezember 2015, 20:02:35
wäre es möglich die Vorgehensweise für die Erstellung dieser Log-Datei kurz zu dokumetieren, eigener Thread vielleicht ?

Danke, habe es oben verlinkt, trotzdem nochmals hier zum Nachlesen.

Das Logfile solltest du in /etc/logrotate.d/ebusd konfigurieren. Ich habe es so eingestellt. Die Datei editieren und diesen Eintrag hinzufügen.

/var/log/ebusd.log {
rotate 7
copytruncate
compress
missingok
notifempty
daily
}


D.h: alle 7 Tage wird überschrieben, die Files werden dann komprimiert (außer dem aktuellen File) und das Ganze wird täglich ausgeführt.

LG

FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Jojo11

Danke Reinhart! Macht das Finden der relevanten Informationen einfacher.

schöne Grüße
Jo


Reinhart

Zitat von: Jojo11 am 23 Dezember 2015, 21:01:23
Danke Reinhart! Macht das Finden der relevanten Informationen einfacher.

schöne Grüße
Jo

Hallo Jojo11!

ja, ich wollte einmal das der eBus Thread etwas abgesplittet wird weil er sonst sehr unübersichtlich wird. Gerade Neueinsteiger finden sich kaum mehr zurecht, so erleichtert es etwas den Nachbau der Schaltung und man findet an einer Stelle alles wesentliche. John30 kann sich dann ganz mit pah auf das "eingemachte" konzentrieren.

Speziell jetzt nach der Sammelbestellung werden viele Fragen auftauchen, die möchte ich gleich vorweg entschärfen.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

john30

Hallo Reinhart,
wieder mal eine geniale Idee, hier die wichtigsten Daten zu konzentrieren!
Danke dafür und schöne Weihnachten!
LG John

PS: Installation der einzelnen Teile und das Builden können entfallen, wenn man eines der fertigen Releases aus https://github.com/john30/ebusd/releases nimmt. Ist evtl. für Einsteiger noch etwas einfacher als der ganze Build Prozess...
In den nächsten Tagen sollte auch Version 2.0 fertig werden, dann gibts auch ein wirklich aktuelles Release :-)
author of ebusd

Reinhart

Danke John für den Hinweis, habe es soeben verlinkt. Habe ich noch gar nicht entdeckt, das du bereits fertige Binarys zur Verfügung stellst.

Es gibt Zwischenzeitlich schon so viele tolle Entwicklungen, das es immer schwerer wird auf die "Schnelle" was zu finden. Ich habe mich ja schon lange mit dem Thema eBus beschäftigt, muss aber auch immer wieder suchen, daher dieser Sammelthread rund ums Thema Nachbau.

Ich bin ebenfalls schon sehr gespannt auf die 2.0, gerade richtig für die vielen Nachbauer die jetzt kommen.

Wünsche auch allen noch ein schönes Fest!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

john30

Noch ein Hinweis zur Poti Einstellung:

Ich finde es leichter, wenn man zur ersten Justierung des Potis den Dienst stoppt (service ebusd stop) und statt dessen mit minimalen Parametern und ohne irgendwelche CSVs direkt in der Kommandozeile startet, z.B. so:
ebusd -f -c /tmp --logareas bus --loglevel info -d $DEVICE
$DEVICE dabei einfach durch das entsprechende /dev/ttyUSB0 o.ä. ersetzen.

Danach aktiviere ich noch aus einem zweiten Terminal (oder über screen) wie folgt den raw output:
ebusctl raw

Somit erhält man im ebusd Fenster die empfangenen Bytes als Hex, also z.B.:
2015-12-24 12:07:16.955 [bus notice] <aa
2015-12-24 12:07:17.001 [bus notice] <aa
2015-12-24 12:07:17.047 [bus notice] <aa
2015-12-24 12:07:17.093 [bus notice] <aa
2015-12-24 12:07:17.097 [bus notice] <10
2015-12-24 12:07:17.102 [bus notice] <50
2015-12-24 12:07:17.107 [bus notice] <b5
2015-12-24 12:07:17.111 [bus notice] <04


Wenn gerade kein Gerät den Bus benutzt, dann sollten etwa 20 Zeilen pro Sekunde ausgegeben werden und zwar mit "<aa" (im Beispiel die oberen 4 Zeilen).

Sobald ein Gerät den Bus benutzt, sieht das natürlich wieder anders aus. Da sind dann kurze Peaks mit was anderem als "aa" zu sehen. Das sollte man dann ignorieren (im Beispiel die unteren 4 Zeilen).

Wichtig ist dann bei der Poti Einstellung, dass man vor allem die regulären "aa"s zu sehen bekommt. Erst wenn die zuverlässig reinlaufen, kann man sich der nächsten Stufe widmen und ebusd wieder regulär als Dienst starten.
author of ebusd

Reinhart

ich finde die von John30 erwähnte Methode mit den 2 Terminalfenster sehr gut zur Einstellung, weil sie wirklich sehr schnell durchläuft und man sofort ein Feedback bekommt ob man mit der Trimmung richtig liegt oder nicht. Sehr schön zu sehen wenn man daneben regelt!

Wer also die Möglichkeit hat unmittelbar neben dem Konverter einen Laptop zu positionieren sollte diese Methode vorziehen, weil es damit sehr schnell geht. Wenn diese Methode versagt und sich nichts tut, hat man ohnehin ein Problem in der Hardware und muss erst dann zum Messgerät greifen.

Danke dafür!

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

ms_9

#12
Beim compilieren tauchen Warnungen bei der Variablenkonvertierung auf, sind da noch Korrektruen im cpp-File notwendig ?

john30

Zitat von: ms_9 am 25 Dezember 2015, 11:11:45
Beim compilieren tauchen Warnungen bei der Variablenkonvertierung auf, sind da noch Korrektruen im cpp-File notwendig ?
Das kannst Du getrost ignorieren, liegt an der RPi Architektur.
author of ebusd

Wzut

Da der Postbote noch über die Alpenpässe reitet habe ich schon mal angefangen den den ebusd auf dem Rpi klar zu machen.
Wenn ich bis jetzt die ganze Doku richtig verstanden habe ist nachher der Dreh und Angelpunkt die .csv Dateien unterhalb von /etc/ebusd ?
Unter https://github.com/john30/ebusd-configuration sind auch einige für verschiedene Hersteller und ebusd Versionen hinterlegt.
Mein Problem z.Z. : für den Hersteller Wolf sind auf github aber nur Dateien für die Version 0.5 hinterlegt.
Kann ich diese auch für die Version 2.0 verwenden ? Bzw. ich habe sie aktuell nach /etc/ebusd kopiert und erhalte beim Start folgende Fehlermeldung :
2015-12-24 18:16:57.979 [main error] error reading config files: ERR: invalid argument, /etc/ebusd/wolf.csv:5



Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher