eBus Schaltung Rpi in Betrieb nehmen!

[Trainer]

solange der ttyAMA0 sichtbar ist wird es nicht funktionieren! Bitte nochmals alles kontrollieren ob er auch wirklich überall entfernt wurde ( sudo raspi-config ). Was hast du denn überhaupt für eine Hardware, Raspi 3 (bei Raspi3 noch in der boot/config.txt schauen).


Bezüglich Treiber, da hast du noch einen älteren Kernelheader drauf, hast du schon einmal eine Seite vorher geschaut?
Eventuell gleich nach der Stretch Installation das Installieren des ttyebus versuchen.


Compilieren erst dann, wenn der ttyAMA0 wirklich verschwunden ist, sonst funktioniert das nicht!


LG

Ich habe es wie in der Anleitung https://github.com/ebus/ttyebus durchgeführt. Leider erscheint noch immer

Code Auswählen Erweitern

crw-rw---- 1 root dialout 204,  64 Dec 27 19:39 ttyAMA0.
ich besitze einen RPI3b+

[Reinhart]

.... dann hast du noch irgendwas übersehen!
Ich habe auch den Raspi 3 für Fhem und habe jetzt den ttyAMA0 abgeschaltet.

Nochmals zum Checken:

Code Auswählen Erweitern

pi@Raspberry:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=b2fd9059-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
Kontrolle ob hier alles passt, sollte in etwa so aussehen und kein "ttyAMA0" vorkommen.

und Kontrolle cat/boot/config.txt, die letzte Zeile ist wichtig.

Code Auswählen Erweitern


# Enable audio (loads snd_bcm2835)
dtparam=audio=on
enable_uart=0
program_usb_boot_mode=1
dtoverlay=pi3-miniuart-bt



sudo raspi-config, Interfacing Options, P6 Serial -> 2x "nein" und "ok".

dann den Service abschalten:

Code Auswählen Erweitern

sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo systemctl status serial-getty@ttyAMA0.service

Code Auswählen Erweitern

sudo reboot
und rebooten

Code Auswählen Erweitern

ls -l /dev

Code Auswählen Erweitern

crw--w---- 1 root tty       4,   7 Dez 28 09:14 tty7
crw--w---- 1 root tty       4,   8 Dez 28 09:14 tty8
crw--w---- 1 root tty       4,   9 Dez 28 09:14 tty9
crw------- 1 root root      5,   3 Dez 28 09:14 ttyprintk
crw-rw---- 1 root dialout   4,  64 Dez 28 09:14 ttyS0
crw------- 1 root root     10, 239 Dez 28 09:14 uhid
crw------- 1 root root     10, 223 Dez 28 09:14 uinput
crw-rw-rw- 1 root root      1,   9 Dez 28 09:14 urandom
crw-rw---- 1 root video   245,   0 Dez 28 09:14 vchiq

und weg ist er!

LG
Reinhart


                                                                                                                     

[Trainer]

.... dann hast du noch irgendwas übersehen!
Ich habe auch den Raspi 3 für Fhem und habe jetzt den ttyAMA0 abgeschaltet.

Nochmals zum Checken:

Code Auswählen Erweitern

pi@Raspberry:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=b2fd9059-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
Kontrolle ob hier alles passt, sollte in etwa so aussehen und kein "ttyAMA0" vorkommen.

und Kontrolle cat/boot/config.txt, die letzte Zeile ist wichtig.

Code Auswählen Erweitern


# Enable audio (loads snd_bcm2835)
dtparam=audio=on
enable_uart=0
program_usb_boot_mode=1
dtoverlay=pi3-miniuart-bt



sudo raspi-config, Interfacing Options, P6 Serial -> 2x "nein" und "ok".

dann den Service abschalten:

Code Auswählen Erweitern

sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo systemctl status serial-getty@ttyAMA0.service

Code Auswählen Erweitern

sudo reboot
und rebooten

Code Auswählen Erweitern

ls -l /dev

Code Auswählen Erweitern

crw--w---- 1 root tty       4,   7 Dez 28 09:14 tty7
crw--w---- 1 root tty       4,   8 Dez 28 09:14 tty8
crw--w---- 1 root tty       4,   9 Dez 28 09:14 tty9
crw------- 1 root root      5,   3 Dez 28 09:14 ttyprintk
crw-rw---- 1 root dialout   4,  64 Dez 28 09:14 ttyS0
crw------- 1 root root     10, 239 Dez 28 09:14 uhid
crw------- 1 root root     10, 223 Dez 28 09:14 uinput
crw-rw-rw- 1 root root      1,   9 Dez 28 09:14 urandom
crw-rw---- 1 root video   245,   0 Dez 28 09:14 vchiq

und weg ist er!

LG
Reinhart


                                                                                                                     

Ich habe noch einmal alles gecheckt und konnte keine Auffälligkeiten finden.
Hier meine Ausgaben.

Code Auswählen Erweitern

pi@raspberrypi:~ $ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=7ee80803-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

Code Auswählen Erweitern

pi@raspberrypi:~ $ cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
enable_uart=0
dtoverlay=pi3-miniuart-bt

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo systemctl stop serial-getty@ttyAMA0.service
pi@raspberrypi:~ $ sudo systemctl disable serial-getty@ttyAMA0.service
pi@raspberrypi:~ $ sudo systemctl status serial-getty@ttyAMA0.service
● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
   Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:agetty(8)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html

Code Auswählen Erweitern

pi@raspberrypi:~ $ ls -l /dev

crw--w---- 1 root tty       4,   8 Dec 28 14:22 tty8
crw--w---- 1 root tty       4,   9 Dec 28 14:22 tty9
crw-rw---- 1 root dialout 204,  64 Dec 28 14:22 ttyAMA0
crw------- 1 root root      5,   3 Dec 28 14:22 ttyprintk
crw------- 1 root root     10, 239 Dec 28 14:22 uhid
crw------- 1 root root     10, 223 Dec 28 14:22 uinput
crw-rw-rw- 1 root root      1,   9 Dec 28 14:22 urandom


[Reinhart]

irgend etwas muss bei deinem PI anders sein als bei meinem Pi 3.

Lies einmal hier, eventuell hilft es wenn du erst das Bluetooth Modem deaktivierst (das liegt ja beim Pi3 auf ttyAMA0) und dann erst die ttyAMA0 Schnittstelle.   Beim Pi 3 ist der UART0 ja für den integrierten Bluetooth Controller vorgesehen, also wird hier der ttyAMA0 benutzt. Die serielle ist ja beim PI3 ttyS0.

LG

[Boemmel]

Hallo zusammen,
nach intensivem Durchforsten des Forums muss ich nun doch eure Unterstützung in Anspruch nehmen und würde mich über eine Rückantwort sehr freuen.

Zielsetzung: Auslesen der Betriebsdaten (Temperaturen) meines Weishaupt Solarreglers WRSol 2.0 über eBus und Ausgabe in FHEM.

Devices: Raspberry Pi 3 (B+) mit Raspbian und FHEM, sowie RPi-Adapter.

Bislang durchgeführt:
- Serial Port deaktiviert -> ttyAMA0 nicht mehr unter /dev gelistet.
- ttyebus-Treiber installiert -> ttyebus unter /dev vorhanden.
- eBusd (ebusd-3.3_armhf-jessie.deb) installiert.
- Konfigurationsdateien (ebusd 2.1 config 2016/06/05) installiert.
- EBUSD_OPTS wie folgt angepasst:

Code Auswählen Erweitern

EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080"
- RPi-Adapter aufgesteckt -> gelbe u. grüne LED leuchten permanent (noch nicht an eBus der WRSol angeschlossen).
- Treibertest durchgeführt -> rote LED leuchtet kurz auf.
- Platine mit eBus verbunden -> gelbe LED leuchtet permanent, grüne LED flackert.
- eBusd gestartet.

Fragen: Ich hatte unter /var/log/ebus.log mehr Traffic [update notice] o.ä. erwartet. Zu sehen ist lediglich:

Code Auswählen Erweitern

2018-12-30 01:30:54.099 [main notice] ebusd 3.3.v3.3 started with auto scan
2018-12-30 01:30:54.375 [bus notice] bus started with own address 31/36
2018-12-30 01:30:54.393 [bus notice] signal acquired
2018-12-30 01:33:01.883 [main notice] update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available


Sonst - stillruhtderSee! Mache ich etwas falsch? Fehlt noch etwas? Muss ich eBusd in jedem Fall eine bestimmte Konf-Datei mitgeben? Wie? Werden darin auch die Abfragezyklen und der Inhalt definiert? Hat jemand so etwas für die WH-WRSol 2.0?

Hier noch die Abfrage "ebusd info"

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.3.v3.3
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
signal: acquired
symbol rate: 21
max symbol rate: 22
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd

pi@raspberrypi:~ $

Ist die Update-Meldung relevant? War eigentlich der Meinung die aktuellsten Versionen installiert zu haben. Müsste hier nicht auch der Solarregler mit aufgeführt sein?

Hier noch die eBusd-Abfrage nach dem Starten, welche m.E so ok sein sollte?!

Code Auswählen Erweitern

pi@raspberrypi:~ $ journalctl -u ebusd -b
-- Logs begin at Sat 2018-12-29 23:36:11 CET, end at Sun 2018-12-30 15:17:01 CET. --
Dez 30 00:21:31 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 30 00:21:31 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
Dez 30 01:01:01 raspberrypi systemd[1]: Stopping ebusd, the daemon for communication with eBUS heating systems....
Dez 30 01:01:02 raspberrypi systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Dez 30 01:30:54 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 30 01:30:54 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $

Wäre schön, wenn mir jemand bei meinem Projekt auf die Sprünge helfen könnte.

Viele Dank u. Viele Grüße
Bernd

[Reinhart]

ich kann dir da leider nicht viel helfen weil ich das Weishauptgerät nicht kenne.
Aber offensichtlich findet der scan nur sich selbst und kein anderes Gerät. Eine Verbindung zum Bus hast du und das Signal ist auch ok.

Kannst du einmal ins Log schauen ob hier während des Tages irgendwelche undefinierte Telegramme kommen oder ob auch hier ewiges Schweigen herrscht?
Die Update Meldung ist irrelevant und ja es müsste mindestens noch der Solarregler auftauchen. Aber ich frage mich ehrlich mit wem der überhaupt kommunizieren soll wenn kein weiterer Master vorhanden ist. Ob dieser Regler auch Broadcasts senden soll weis ich leider auch nicht. Wenn die grüne Led aber flackert dürfte schon ein Busverkehr da sein, zumindest ein Syn könnte es sein.

Du kannst aber einmal im Rawmodus Loggen und schauen was denn da so am Bus los ist, denn das flackern muss ja was an RxD sein.

LG

[Boemmel]

Hallo Reinhart, Hallo Forum,
frohes neues Jahr allerseits.

Ersteinmal Danke für die prompte Antwort. Ich bin über die Feiertage etwas weiter gekommen, allerdings bräuchte ich noch Support bzgl der Konfigurationsdateien.

Sobald ich den Solarregler stromlos und wieder ein schalte meldet sich dieser auch am eBus wie folgt an:

Code Auswählen Erweitern

2018-12-31 18:52:34.072 [main notice] ebusd 3.3.v3.3 started with auto scan
2018-12-31 18:52:34.343 [bus notice] bus started with own address 31/36
2018-12-31 18:52:34.356 [bus notice] signal acquired
2018-12-31 18:53:51.000 [bus error] signal lost
2018-12-31 18:53:54.203 [bus notice] signal acquired
2018-12-31 18:53:58.444 [bus notice] new master 10, master count 2
2018-12-31 18:53:58.445 [bus notice] scan 15: ;TEM;20599;2522;1112
2018-12-31 18:53:58.445 [update notice] store broadcast ident: done
2018-12-31 18:53:58.445 [update notice] received update-read broadcast id QQ=10: TEM;20599;2522;1112
2018-12-31 18:54:04.637 [main error] unable to load scan config 15: list files in tem ERR: element not found
2018-12-31 18:54:04.637 [main error] scan config 15: ERR: element not found
2018-12-31 18:56:06.813 [main notice] update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available


Abfrage "ebusd info":

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.3.v3.3
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
signal: acquired
symbol rate: 21
max symbol rate: 54
reconnects: 0
masters: 2
messages: 12
conditional: 0
poll: 0
update: 4
address 10: master #2
address 15: slave #2, scanned "MF=TEM;ID=20599;SW=2522;HW=1112"
address 31: master #8, ebusd
address 36: slave #8, ebusd

pi@raspberrypi:~ $

Ich würde jetzt versuchen, wie Hans vorzugehen (siehe: https://forum.fhem.de/index.php/topic,65678.0.html) und eine entsprechende Konfig-Datei erstellen. Diese würde dann 15.20599.csv heißen.

Wird dann nur diese benötigt und kann die einfach im /etc/ebusd/ liegen? Sind memory.csv, broadcast.csv und _templates.csv ebenfalls notwendig? Wird mit --scanconfig automatisch die richtige Datei gewählt? Wenn ja, nach welchen Kriterien? Anhand der Nummer (15)? Im Vaillant-Ordner existieren ja ebenfalls einige Dateien, die mit 15 beginnen. Sollte man --scanconfig nutzen, oder den Pfad lieber direkt angeben?

Wann erscheint die "loaded" Ausgabe innerhalb der "ebusd info"?

Viele Grüße - Bernd

[john30]

Ich würde jetzt versuchen, wie Hans vorzugehen (siehe: https://forum.fhem.de/index.php/topic,65678.0.html) und eine entsprechende Konfig-Datei erstellen. Diese würde dann 15.20599.csv heißen.

Wird dann nur diese benötigt und kann die einfach im /etc/ebusd/ liegen? Sind memory.csv, broadcast.csv und _templates.csv ebenfalls notwendig? Wird mit --scanconfig automatisch die richtige Datei gewählt? Wenn ja, nach welchen Kriterien? Anhand der Nummer (15)? Im Vaillant-Ordner existieren ja ebenfalls einige Dateien, die mit 15 beginnen. Sollte man --scanconfig nutzen, oder den Pfad lieber direkt angeben?

wenn du deine eigene config baust, dann nimm am besten nur die CSVs, von denen du weißt, dass sie passen. also erstmal höchstens broadcast.
und dann musst du natürlich ebusd beibringen, in deinem Verzeichnis zu suchen statt auf dem Webservice. dazu noch den Parameter "-c /etc/ebusd" eintragen

[Schlauer Det]

Prima!

zu 1. wenn du noch keine Konfigurationsdateien hast dann kannst du es so machen (aus dem Home Verzeichnis installieren  /home/pi ) .

Code Auswählen Erweitern

git clone https://github.com/john30/ebusd-configuration.git
if [ -d /etc/ebusd ]; then sudo mv /etc/ebusd /etc/ebusd.old; fi
sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusd
Aber die Versionen ab 3.x können das auch online durchführen wenn es in der /etc/default/ebusd eingetragen ist.

zu 2. jederzeit, sonst siehst du ja nichts ob deine Arbeit Früchte trägt!

LG
Reinhart

@reinhart, @john30, @galileo, @pah und all jene, die im Verborgennen solch eine großartige Leistung vollbringen. 

Nachdem ich über die Feiertage familienbedingt eBus-mäßig nicht so viel unterwegs sein konnte, habe ich gestern die Arbeit wieder aufgenommen.

Ich hatte ja vor, den eBus über die RJ10-Buchse an meinem Vaillant VR70-Regler abzugreifen. Dazu verband ich die Buchse über ein RJ10-Modularkabel und die Rpi-Platine mit meinen Heiz-Raspi. Nachdem ich den Raspi software-seitig soweit hatte (was auch eine Weile dauerte), startete ich den ganzen Aufbau, konnte aber keine Verbindung zum eBus herstellen.

Also "back to the roots": Eine Messung der vier Ausgangsleitung am RJ10-Stecker in der VR70-Buchse ergab, dass es sich eindeutig NICHT um den eBus handelt, der da in die Aussenwelt gereicht wird.

Damit musste ich mir ein neues Kabel machen und die Rpi-Platine direkt mit dem eBus-Anschluß im VR70 verbinden (ursprünglich hatte ich ja geplant, aus Gewährleistungsgründen diese Lösung nicht zu benutzen).

Und siehe da, nach erneutem Starten habe ich das angehängte Log produziert.

Dazu habe ich jetzt einige Fragen an die Experten:

• Es sind noch einige "undefined MS commands" im Log-File. Was bedeutet das? Was kann ich tun, um diese los zu werden?
• Irgendwann während der Arbeit an der Software stolperte ich mal darüber, dass es schon eine eBus-Version 3.3 gibt. Bei Gelegenheit würde ich gerne darauf umsteigen. Wie kann ich das, ohne alles neu aufzusetzen?
• Mein Plan ist, dass ich zunächst das Busgeschehen, also die Lebensäußerungen meiner Heizung, offline ganz einfach auswerte, z.B. mit Excel auf der mir mehr vertrauten Windows-Maschine (bitte keine Prügel von den Linux-Fans  ). Schreibzugriffe plane ich derzeit noch nicht, da will ich erst etwas sicherer mit dem ganzen System werden. Wie kann ich das erreichen?

Für ein paar weiterführende Tipps und Hinweise wäre ich sehr dankbar 


Grüße von der feucht-kalten Wasserkante
Det 

[john30]

Es sind noch einige undefined MS commands im Log-File. Was bedeutet das?

Dass deren Definition/Syntax noch nicht klar ist.

[Reinhart]

Punkt 1 hat dir John schon erklärt!

Punkt 2:
selber compilieren und du hast die neuste Version. John hat das im Wiki sehr gut beschrieben und sind nur ein paar Kommandos, dauert aber ein paar Minuten.

Punkt 3:
ohne Schreibzugriffe ist ein etwas schwieriges unterfangen weil schon ein Scan ein Schreibzugriff ist. Sofern du in der Config aber keine weiteren Rechte vergibst (mit --accesslevel) , kann dir auch nicht wirklich viel passieren. Dann ist die sog. Techniker Ebene schon blockiert, egal was du versuchst zu senden. Ein versehentliches Senden sollte ohnehin nicht so leicht passieren, denn sowas muss ja bewusst definiert  und abgesetzt werden.


LG

[Baunti66]

Schönen Nachmittag zusammen.

Nach langen experimentieren läuft die Schaltung endlich reibungslos nur der MQTT Broadcast will nicht laufen.

_{Auszug aus dem LOG}

Code Auswählen Erweitern

2019-01-23 15:14:21.168 [mqtt error] publish: The client is not currently connected.

_{Meine Konfig}

Code Auswählen Erweitern

EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log  --scanconfig --httpport=8080 --mqtttopic=Vaillant/Heizung --mqttjson --mqtthost=192.168.1.201 --mqttport=1880"

Ich hoffe jemand hat eine Idee.
Danke im Voraus

LG
Daniel

[john30]

Ich hoffe jemand hat eine Idee.

ist 192.168.1.201 der host, auf dem auch ebusd läuft?

[Baunti66]

Nein.
201 ist der broker.

[john30]

Nein.
201 ist der broker.

und ist der broker port auch für nicht-lokale clients zugänglich?