eBus Schaltung Rpi in Betrieb nehmen!

Begonnen von Reinhart, 19 Februar 2018, 19:38:23

Vorheriges Thema - Nächstes Thema

fisch3009

Ergänzung:
Meine Vermutung ist, dass das Gerät mit dem ich kommuniziere die Therme ist und die Calormatic 470 gar nicht am EBUS hängt, der Regler ist nämlich direkt aufgesteckt auf das Heizungsmainboard und dann wird eine 3 polige Stiftleiste gesteckt. Wenn die Calormatic abgesetzt montiert wird, wird der EBUS über eine andere 2 polige Stiftleiste an die Calormatic angeschlossen.

Reinhart

Nein, das passt schon so, ich habe die Calormatic auch direkt in der Therme am vorgesehenen Steckplatz aufgesteckt. Das funktioniert schon so.

Es kommen ja im Normalbetrieb nur Brodcast und das funktioniert ja bei dir. Wenn du mehr benötigst dann frage die Werte (über Timer etc.) einfach ab, dazu gibt es genug Beispiele.

Hier ein Beispiel für einen Timer via MQTT2 mit ein paar Werten:
define EBUS.MQTT at +*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;;\
set ebusMQTT publish ebusd/430/HwcTempDesired/get;;\
set ebusMQTT publish ebusd/bai/WaterPressure/get;;\
set ebusMQTT publish ebusd/bai/FlowTemp/get;;\
set ebusMQTT publish ebusd/bai/ReturnTemp/get;;\
set ebusMQTT publish ebusd/bai/FanSpeed/get;;\
set ebusMQTT publish ebusd/bai/WPPWMPower/get;;\
set ebusMQTT publish ebusd/bai/Status02/get;;\
set ebusMQTT publish ebusd/bai/HcHours/get;;\
set ebusMQTT publish ebusd/bai/HwcStarts/get
attr EBUS.MQTT group timer
attr EBUS.MQTT room MQTT2_DEVICE


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

fisch3009

Hallo Reinhart,
danke für deine Antwort.
Mein Problem ist aber, dass er die VRC470 oder Colormatic ja im ebusctl info gar nicht anzeigt und dementsprechend die csv Datei dafür nicht lädt.
Obwohl ich davon ausgehe, dass es dafür schon eine gibt (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.x.x/de/vaillant/15.470.csv) zumindest wäre das so meine Vermutung.
Kann ich dem ebusd denn erzählen, dass er die Datei verwenden soll?
Wenn ich einen scan mit ebusctl scan 15 (vermutlich die Adresse des Colormatic) starte bekomme ich entweder "ERR: arbitration lost" oder "ERR: wrong symbol..." genauso für 8. Die er aber offensichtlich mit --scanconfig findet (aber auch nicht immer).


Eraser

Hallo Forum!

Ich habe nun auch endlich das Projekt RPI + eBus gestartet.
Vielen Dank an alle die daran gearbeitet und die Infos hier geteilt haben!


Folgende Daten:

-) Raspberry Pi 4 mit Debian Buster Image
-) Selbst gebaute eBus-Adapter 2-Platine laut https://ebus.github.io/adapter/

Status:

Erfolgreich nach Anleitung ttyebus installiert
Erfolgreich nach Anleitung ebusd installiert

Leider wird unter mittels "ebusctl info" kein Signal angezeigt:


pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd



Wenn ich eine Sendetest mittels echo "das ist ein Sendetest" >/dev/ttyebus durchführe (vorher den ebusd-service natürlich gestoppt), dann blinkt auch die rote TX-LED kurz auf.

Wenn ich dann den RPI neustarte und somit ebusd wieder automatisch gestartet wird, und dann den eBus von meiner Vaillant-Wärmepumpe dran anschließe, so blinkt die grüne RX-LED wild,
was auf den korrekten Empfang von eBus-Signalen an der eBus-Platine hindeutet.


Folgend die Infos von dem System:

uname -a und uname -r

Linux raspberrypi 5.4.51-v7l+ #1327 SMP Thu Jul 23 11:04:39 BST 2020 armv7l GNU/Linux
5.4.51-v7l+


Die Devices (kein AMA0-Device wird angezeigt):


...
crw--w---- 1 root tty       4,  63 Aug  4 12:19 tty63
crw--w---- 1 root tty       4,   7 Aug  4 12:19 tty7
crw--w---- 1 root tty       4,   8 Aug  4 12:19 tty8
crw--w---- 1 root tty       4,   9 Aug  4 12:19 tty9
crw-rw-rw- 1 root root     10,  60 Aug  4 12:19 ttyebus
crw------- 1 root root      5,   3 Aug  4 12:19 ttyprintk
crw-rw---- 1 root dialout   4,  64 Aug  4 12:19 ttyS0
crw------- 1 root root     10, 239 Aug  4 12:19 uhid
...


Interrupts:

pi@raspberrypi:~ $ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
17:          1          0          0          0     GICv2  99 Level     timer
18:          0          0          0          0     GICv2  29 Level     arch_timer
19:       4648       5635       1518       1597     GICv2  30 Level     arch_timer
26:        489          0          0          0     GICv2  65 Level     fe00b880.mailbox
29:      11377          0          0          0     GICv2 125 Level     ttyS0
32:        352          0          0          0     GICv2 114 Level     DMA IRQ
34:          0          0          0          0     GICv2 116 Level     ttyebus_irq_handler
39:         57          0          0          0     GICv2  66 Level     VCHIQ doorbell
40:       9332          0          0          0     GICv2 158 Level     mmc1, mmc0
42:          0          0          0          0     GICv2  48 Level     arm-pmu
43:          0          0          0          0     GICv2  49 Level     arm-pmu
44:          0          0          0          0     GICv2  50 Level     arm-pmu
45:          0          0          0          0     GICv2  51 Level     arm-pmu
47:       2359          0          0          0     GICv2 189 Level     eth0
48:        283          0          0          0     GICv2 190 Level     eth0
54:          0          0          0          0     GICv2 106 Level     v3d
55:          0          0          0          0     GICv2 175 Level     PCIe PME, aerdrv
56:         39          0          0          0  BRCM STB PCIe MSI 524288 Edge      xhci_hcd
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0          0          0          0  Timer broadcast interrupts
IPI2:       2083       1890       5102       2732  Rescheduling interrupts
IPI3:         97        423        250        364  Function call interrupts
IPI4:          0          0          0          0  CPU stop interrupts
IPI5:       1133       2083        289        184  IRQ work interrupts
IPI6:          0          0          0          0  completion interrupts
Err:          0



/var/log/ebusd.log:

pi@raspberrypi:~ $ cat /var/log/ebusd.log
2020-08-04 12:20:12.230 [main notice] ebusd 3.4.v3.3-51-g57eae05 started with auto scan
2020-08-04 12:20:12.591 [bus notice] bus started with own address 31/36
2020-08-04 12:22:22.696 [main notice] update check: revision v3.4 available



/etc/default/ebusd


EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --latency=10000 --httpport=8080"



/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=off
#dtparam=i2s=on
dtparam=spi=off

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

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

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
dtoverlay=miniuart-bt

enable_uart=0



/boot/cmdline.txt


console=tty1 root=PARTUUID=5f90cfd3-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait



Das einzige was laut Anleitung von ttyebus nicht ganz funktioniert ist, dass wenn mittels raspi-config die serielle Schnittstelle mit Betätigung von 2x "No" deaktiviert wird, so wird das AMA0-device nach einem Neustart entfernt und wird nicht mehr aufgelistet.
Gleichzeitig aber wird in der "/boot/config.txt" die Zeile enable_uart=0 wieder hinzugefügt.
Lösche ich nun diese Zeile von der "boot/config.txt" und starte den RPI neu, so bleibt diese Zeile zwar weg, aber gleichzeitig wird wieder das AMA0-device aktiviert.
Danach müsste man wieder mittels raspi-config die Serielle Schnittstelle (2. "No" bei der Auswahl) deaktivieren, aber so beginnt der Rattenschwanz und man dreht sich im Kreis.


Ich bitte um Eure Hilfestellung hierzu.

Vielen Dank
mfg Wolfgang

Reinhart

durch das abschalten mit raspi-config wird ja letztlich nur der Eintrag in der boot.txt "enable_uart=0" eingetragen. 0 bedeutet AUS und eine 1 wäre EIN, also stimmt das schon.

Wenn nun deine grüne Led fröhlich blinkt sieht das auch schon mal gut aus (Signal vom eBus kommt somit an der Platine an und wird detektiert) und dein Sendetest hat ja auch schon funktioniert. Scheint also nur die serielle Weiterleitung zum Dämon nicht zu funktionieren.

Poste doch bitte einmal den gesamten Inhalt der /etc/default/ebusd!

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

Eraser

Hallo Reinhart,

danke für deine Antwort.

Aufgrund der Anleitung des ttyebus war ich der Meinung, dass "enable_uart=0" nicht drin stehen darf.


On Raspberry Pi 4 verify that file /boot/config.txt does NOT contain a line "enable_uart=0". If the line exists remove or comment (#) this line.



Hier der gesamte Inhalt der etc/default/ebusd:


# /etc/default/ebusd:
# config file for ebusd service.

# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --latency=10000 --httpport=8080"

# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1$#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2$#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3$
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.


Dort ist nur die eine Zeile aktiv.

nightstorm99

@Eraser

leider läuft es bei mir auch nicht auf einem Rasp4!  :(

Habe vom  Rasp 3 B auf einen Rasp 4 2 GB gewechselt, da ich Poe nutzen will.
Leider geht nun mein Ebus nicht mehr.

- ttyAMA0 ist nicht unter /dev
- alles nach Anleitung erledigt

Hat wer noch eine Idee?

Danke und Gruß
Denny

galileo

Die Sache ist ein wenig verwirrend, ich versuche die Informationen einmal zusammenzutragen. Alle Infos von der Raspi UART Seite:
https://www.raspberrypi.org/documentation/configuration/uart.md

miniuart-bt (bzw. pi3-miniuart-bt):
Zitatswitches the Bluetooth function to use the mini UART, and makes the first PL011 (UART0) the primary UART.
Wichtig ist: der PL011 ist jetzt der ,,primary".

ZitatThe default state of the enable_uart flag depends on which UART is the primary UART:
Mini UART : Default = 0  (für uns nicht relevant)
first PL011 (UART0) = 1  (!! Wenn nicht angegeben dann eingeschaltet !!)
Das heisst also: entweder die Zeile mit ,,enable_uart" herauslöschen, dann ist der Default wirksam, oder ,,enable_uart=1" hineinschreiben. Funktioniert theoretisch aber nur wenn gleichzeitig miniuart-bt gesetzt ist.
(Mir ist das auch erst jetzt so richtig bewusst geworden, bitte um Kontrolle und Rückmeldung – ich schreibe das aus dem ,,Trockendock" ohne Möglichkeit es tatsächlich zu verifizieren)

ZitatBy default, the primary UART is assigned to the Linux console. If you wish to use the primary UART for other purposes, you must reconfigure Raspberry Pi OS. This can be done by using raspi-config:
1.   Start raspi-config: sudo raspi-config.
2.   Select option 5 - interfacing options.
3.   Select option P6 - serial.
4.   At the prompt Would you like a login shell to be accessible over serial? answer 'No'
5.   At the prompt Would you like the serial port hardware to be enabled? answer 'Yes'
6.   Exit raspi-config and reboot the Pi for changes to take effect.

Jetzt kommt es darauf an dass die Konsole nicht auf dem UART herumfuhrwerkt. Wenn sie das parallel zum ttyebus tut dann funktioniert natürlich nichts mehr.
Da sich diese Dinge teilweise gegenseitig beeinflussen (Reihenfolge!!) bitte alles reihum zu überprüfen. Wenn alles richtig steht sollte es eigentlich funktionieren, zumindest tut es das schon in vielen Fällen.
LG

Eraser

#338
Hallo galileo,

ich habe das jetzt mal probiert, indem ich in der config.txt enable_uart=1 gesetzt habe:


dtoverlay=miniuart-bt
enable_uart=1


Die Zeile enable_uart herauslöschen funktioniert ja leider wie oben beschrieben nicht.

Nach einem Neustart dies Pi ändert sich aber leider nichts, immer noch "No signal" wenn ich "ebusctl info" aufrufe.


pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd


Bei den devices ist nun wieder das ttyAMA0 aktiv:


...
lrwxrwxrwx 1 root root           7 Aug  5 16:58 serial0 -> ttyAMA0
lrwxrwxrwx 1 root root           5 Aug  5 16:58 serial1 -> ttyS0
...
crw--w---- 1 root tty       4,   8 Aug  5 16:58 tty8
crw--w---- 1 root tty       4,   9 Aug  5 16:58 tty9
crw-rw---- 1 root dialout 204,  64 Aug  5 16:58 ttyAMA0
crw-rw-rw- 1 root root     10,  60 Aug  5 16:58 ttyebus
crw------- 1 root root      5,   3 Aug  5 16:58 ttyprintk
crw-rw---- 1 root dialout   4,  64 Aug  5 16:58 ttyS0
...


Eraser

Hab jetzt mal hinterher probiert wieder mittels raspi-config beide Serial-Einstellungen auf No zu setzen, dann verschwindet ttyAMA0 wieder.


...
lrwxrwxrwx 1 root root           5 Aug  5 17:07 serial1 -> ttyS0
...
crw--w---- 1 root tty       4,   8 Aug  5 17:07 tty8
crw--w---- 1 root tty       4,   9 Aug  5 17:07 tty9
crw-rw-rw- 1 root root     10,  60 Aug  5 17:07 ttyebus
crw------- 1 root root      5,   3 Aug  5 17:07 ttyprintk
crw-rw---- 1 root dialout   4,  64 Aug  5 17:07 ttyS0
...


ttyS0 bleibt aber auf serial1.

Otto123

Ich denke, Du musst den serial-getty (Console) Dienst deaktivieren:
# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service

Und eigentlich musst Du die Frequenz fest setzen.
Siehe https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

nightstorm99

Bringt leider alles nichts, auf dem Rasp 3 geht das ohne Probleme genau nach Anleitung, aber
auf dem Rasp 4 leider nicht.
Irgendwo ist da noch ein Fehler.

Habe mal ein Issue beim ttyebus aufgemacht!


Gruß

Eraser

#342
Hallo Otto,

ich hab jetzt den serial-getty Dienst laut deinen 3 Kommandos deaktiviert und den Pi neu gestartet.

Leider sind die Devices immer noch gleich:


...
lrwxrwxrwx 1 root root           7 Aug  6 09:08 serial0 -> ttyAMA0
lrwxrwxrwx 1 root root           5 Aug  6 09:08 serial1 -> ttyS0
...
crw--w---- 1 root tty       4,   8 Aug  6 09:08 tty8
crw--w---- 1 root tty       4,   9 Aug  6 09:08 tty9
crw-rw---- 1 root dialout 204,  64 Aug  6 09:08 ttyAMA0
crw-rw-rw- 1 root root     10,  60 Aug  6 09:08 ttyebus
crw------- 1 root root      5,   3 Aug  6 09:08 ttyprintk
crw-rw---- 1 root dialout   4,  64 Aug  6 09:08 ttyS0
...


Immer noch no signal bei ebusctl info.

Auch bei Hinzufügen der Zeile core_freq=250 ändert sich nichts.
Ist da ein Unterschied zu arm_freq, welche in der config.txt auskommentiert ist?

ebusd zeigt mir Folgendes an (schon immer):


pi@raspberrypi:~ $ ebusd
2020-08-06 09:13:44.530 [main error] invalid configpath without scanconfig


Ich schätze das ist deshalb, weil es noch keine Telegramme erkennen konnte oder?

Otto123

Moin,

Ich kann leider nur bis zum ttyAMA0 helfen, weiter kenn ich mich nicht aus. Meinen ebusd hab ich mit dem alten Adapter und USB angeschlossen :)
Ich weiß, dass

  • ohne mask der serial-getty nicht dauerhaft deaktiviert ist - insofern zweifle ich an der Anleitung in #1
  • beim tauschen der UART und miniUART bei zumindest einer der beiden Schnittstellen die Taktfrequenz von der core frequenz abhängt. Wenn diese dynamisch geändert wird, funktioniert die UART nicht.
  • einige der Abhängigkeiten UART - restliches System in der Konfiguration und dem OS im Laufe der Entwicklung berücksichtigt wurden und einige Dinge im Hintergrund konfiguriert werden.
Siehe auch https://www.raspberrypi.org/documentation/configuration/uart.md
Es sind auch durchaus Unterscheide in den einzelnen Betriebssystemen!

Ist dieser Start ebusd auf CL so wie Du zeigst sinnvoll? Ich habe mir da mal folgendes notiert
sudo systemctl start ebusd

ebusctl info
ebusctl scan
ebusctl scan result
...


Gruß Otto

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Eraser

Hallo Otto,

ebusd wird bei mir auch automatisch mittels
sudo systemctl start ebusd gestartet.