Rpi Platine für eBus Inbetriebnahme!Hallo,
da es nun Dank Galileo endlich möglich wurde die interne serielle Schnittstelle des Raspi zu nutzen, hier der Unterstützungsthread zur Inbetriebnahme des Rpi Bausatzes.
Im Prinzip bleibt alles so wie bei der V 2.0, lediglich der Unterschied das hier nun ein Dc-Wandler eingesetzt wurde und somit die Platine auf die höchste Klasse nach der Spezifikation empor rückt und auch hartnäckige Fälle abdecken sollte. Chons hat die Platine so gestaltet, das die auch ohne DC-Wandler in Betrieb genommen werden kann.
Achtung, nur verbleites Zinn verwenden! (https://forum.fhem.de/index.php/topic,84636.msg865304.html#msg865304)
Achtung: ohne DC-Wandler auf keinen Fall C3 einlöten, sonst wird das eBus Signal verschliffen und die Schaltung funktioniert nicht! Ebenso darf der Jumper SJ2 nicht gesetzt sein wenn der DC-Wandler eingebaut ist!
mit DC-Wandler Jumper SJ1 offen und C3 eingelötet
ohne DC-Wandler Jumper SJ1 geschlossen aber ohne C3Verzicht des DC-Wandlers bei der V2.2 (https://forum.fhem.de/index.php/topic,84636.msg860127.html#msg860127)
TreiberinstallationBevor die Schaltung in Betrieb genommen werden kann, muss bei der Rpi Platine der Treiber installiert werden.
Dazu den neuen eBus Treiber von Galileo Github (https://github.com/ebus/ttyebus) laden. Im Augenblick ist Version 1.4 aktuell und läuft auf Raspi 1, 2 und 3! Getestet wurde unter Jessie und Stretch! Hier hat ein Anwender den Treiber auf dem Raspberry Zero (https://forum.fhem.de/index.php/topic,84636.msg861790.html#msg861790) eingerichtet.
Bitte unbedingt die Installationsanleitung beachten und den alten Treiber deaktivieren. Dazu "raspi-config" und
den "Serial Port" deaktivieren, sonst kann der Treiber nicht funktionieren da er ersetzt werden muss.
# AMA0 Treiber Service deaktivieren
sudo raspi-config , zuerst hier den Serial Port deaktivieren
sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
Deaktivierung des AMA0 Treiber
Kurzanleitung ttyeBus Treiber
sudo echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt(nur) beim Raspi3 zunächst den UART und MINI Uart umleiten:
sudo apt-get update sudo apt-get -y upgrade
sudo apt-get install raspberrypi-kernel-headers
cd ~ git clone https://github.com/ebus/ttyebus.git
cd ~/ttyebus make
sudo make install
lsmod modinfo ttyebus
Nach erfolgreiche Installation muss dann der Treiber "
ttyebus" sichtbar sein und AMA0 verschwunden sein!
Zitatpi@raspberrypi:~ $ lsmod
Module Size Used by
cfg80211 527100 0
rfkill 21373 2 cfg80211
snd_bcm2835 23131 0
snd_pcm 97825 1 snd_bcm2835
snd_timer 22706 1 snd_pcm
snd 68784 3 snd_timer,snd_bcm2835,snd_pcm
i2c_bcm2835 6433 1
bcm2835_gpiomem 3791 2
w1_gpio 4566 0
uio_pdrv_genirq 3718 0
uio 10166 1 uio_pdrv_genirq
fixed 3029 0
w1_therm 5969 0
wire 31801 2 w1_gpio,w1_therm
cn 5860 1 wire
ttyebus 5666 1
i2c_dev 6642 2
ip_tables 12512 0
x_tables 20921 1 ip_tables
ipv6 384613 41
pi@raspberrypi:~ $
Die Installation sollte vor der Inbetriebnahme der Platine erfolgt sein!
Bitte ebenfalls gegenchecken mit
ls -l /devttyebus muss auftauchen, AMA0 muss verschwunden sein!
In der EBUSD_OPTS (etc/default/ebusd) sollte dann "ttyebus" verwendet werden.
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%name"
Beispiel der EBUSD_OPTS
Bei den Bauteilen befinden sich 2 Keramik Kondensatoren, der blaue hat den Wert 100nF = C2 und der braune ist 1 bzw. 2uF = C3(siehe Foto) für den DC-Wandler.
Bei den Rpi Bausätzen liegen 2 Printklemmen dabei, die höhere kann nur eingesetzt werden wenn genug Platz vorhanden ist, das hängt von eurem Gehäuse ab. Ansonsten die kleine flachere (schwarz) verwenden.
Bei den Mini-Uarts liegt jetzt vom Hersteller eine gewinkelte Stiftleiste bei. Bitte diese nicht einlöten, das passt NICHT. Ich habe daher den Bausätzen eine zusätzliche Stiftleiste beigelegt, die ist für diesen Uart gedacht! Das betrifft aber nur die V 2.1 und nicht die Rpi!
Bauteileliste
C1 10uF Elektrolytkondensator (schwarz)
C2 100nF keramischer Kondensator (blau)
C3 2,2uF keramischer Kondensator (braun)
D1 1N4007 Diode
D2 1N4007 Diode
D3 1N4007 Diode
D4 1N4007 Diode
D5 ZPY 9.1V 1.3W Zenerdiode
IC1 TLC393CP Operationsverstärker
IC2 78L05Z Spannungsregler
LED1 RX grün LED 3MM
LED2 TX rot LED 3MM
LED3 PWR gelb LED 3MM
OK1 CNY17-4 Optokoppler
OK2 CNY17-4 Optokoppler
Q1 BC337-40 Transistor
R1 390 R-EU_0207/10
R2 220 Widerstand
R3 100k Widerstand
R4 22k Widerstand
R5 470 Widerstand
R6 470 Widerstand
R7 18k Widerstand
R8 15k Widerstand
R9 220k Widerstand
R10 4,7k Widerstand
R11 820 Widerstand
R12 10k Widerstand
R13 1,2k Widerstand
R14 220 Widerstand
RNM-0512S DC-Wandler
RPIGPIO JP3 Pfostenstecker
JP2-7 Stiftleisten 1-2pol
SJ1 Löt Jumper
EBUS eBus Printklemme
EBUS2 Printklemme Waggo
I2C1 Stiftleiste 4-pol
I2C2 Stiftleiste 4-pol
Schaltplan Rpi (https://forum.fhem.de/index.php?action=dlattach;topic=75878.0;attach=96953)
MQTT2 Beispiele Konfiguration (https://forum.fhem.de/index.php/topic,79600.msg878716.html#msg878716)
Wemos oder UART am RPI-Adapter (https://forum.fhem.de/index.php/topic,104259.msg989382.html#msg989382)
LG
Reinhart
Durch Einsatz dieser Steckplatine ergeben sich sehr viele praktische Möglichkeiten, denn chons hat die Platine mit den wichtigsten Schnittstellen wie 1-Wire und I2C ausgestattet.
Mit 1-Wire könnt ihr nun direkt an der Platine Temperatursensoren des Typ DS18b20 anschließen und damit Temperaturen an Rohren eurer Heizungsanlage bequem erfassen und auswerten.
#################################################
# 1-Wire Komponenten
#################################################
# Modul 58_GPIO4.pm aus dem contrib Verz. nach /opt/fhem/FHEM kopieren.
# /boot/config.txt
# activating 1-wire with pullup
# dtoverlay=w1-gpio-pullup
#ls /sys/bus/w1/devices/
#pi@raspberrypi:/opt/fhem $ ls /sys/bus/w1/devices/
#28-0417c1d99bff w1_bus_master1
define RPi GPIO4 BUSMASTER
attr RPi room 1-wire
define Temp_DS18b20 GPIO4 28-0417c1d99bff
attr Temp_DS18b20 group 1-wire
attr Temp_DS18b20 model DS18B20
attr Temp_DS18b20 pollingInterval 300
attr Temp_DS18b20 room 1-wire
Mit dem I2C Bus kann auch weiterhin der BME280 verwendet oder ein Oled angeschlossen werden, es eröffnen sich somit sehr viele Kombinationen.
########
# I2C
########
define i2c RPII2C 1
attr i2c group I2C
attr i2c room I2C
##########
# BMP180
##########
# sudo adduser fhem i2c
define BME280 I2C_BME280
attr BME280 IODev i2c
attr BME280 group I2C
attr BME280 poll_interval 2
attr BME280 room I2C
define FileLog_BME280 FileLog ./log/BME-%Y.log BME280:(temperature|humidity|pressure).*
attr FileLog_BME280 logtype text
attr FileLog_BME280 room I2C
Beispiel einer Konfiguration des Temperatur Sensors BME280 über I2C in FHEM.
Die hier gezeigten Beispiele führen dann zu den Plots in den angehängten Bildern.
Bitte nicht zu vergessen, voher am Raspi mit "raspi-config" 1-wire und i2c zu aktiveren!
LG
Reinhart
ebenfalls eine gute Möglichkeit ist es, die Rpi Platine in ein Hutschienen Gehäuse einzubauen!
Der Vorteil liegt hier, dass man hier sehr viel mehr Platz hat und noch einige Erweiterungen wie ein Oled einbauen könnt.
Das Oled kann entweder über ein installiertes Fhem angesteuert, aber wer dies nicht vorhat kann es auch direkt vom Raspi über ein kleines Python Programm (Ergebnis siehe Bilder) realisieren. Dazu werde ich aber einen eigenen Beitrag schreiben, da speziell bei Python einges an Librarys installiert werden muss. Was letztlich auf dem Oled Display landen soll, ist natürlich eurer Phantasie überlassen. Es funktionieren alle Readings die in FHEM vorhanden sind. Fhem muss dabei nicht auf diesem Raspi laufen und es wird Remote zugegriffen.
Wie hier auf den Fotos zu sehen, wurde auch mit dem eingebauten roten Taster der Anschluß des Gpio24 an der Platine genutzt. Die Anzeige aller Messdaten (es können beliebig viele eingebaut werden) wird hier 5 x durchlaufen und dann schläft das Oled ein. Durch Tastendruck wird es dann wieder geweckt.
Aber vorerst geht es mir darum um die neuen Möglichkeiten der Rpi Platine aufzuzeigen!
LG
Reinhart
erster Treibertest!
Nach erfolgreicher Treiberinstallation könnt ihr ohne eBus den Treiber schon mal testen.
Öffnet einfach eine Konsole und gebt folgendes ein:
echo "das ist ein Sendetest" >/dev/ttyebus
Die Sendeled (mittlere Led 2) muss am Rpi jetzt kurz aufblitzen!
Wenn kein eBus angeschlossen ist, müssen die beiden äußeren Leds (Led 1 + 3) permanent leuchten.
LG
Reinhart
Heizkurve farbig in Grafik darstellen!
Eine kleine Anregung was man alles mit den eBus-Daten anstellen kann.
Ich habe mich schon lange geärgert, dass meine Kenntnisse in HTML nicht ausreichen die eingestellte Heizkurve farbig in einer Grafik darzustellen. Ich habe daher eine ganz primitive Möglichkeit angewendet um das trotzdem zu realisieren indem ich vorgezeichnete eingefärbte Kurven als Bilder lade.
define Kurve weblink htmlCode {Heizkurve_URL()}
attr Kurve group Heizkurve_Grafik
attr Kurve htmlattr width="630" height="282"
attr Kurve room Vaillant
das ist die ganze Definition des Weblink Aufrufes.
sub Heizkurve_URL() {
my $heizkurve = ReadingsVal("HKurve", "HKurve", "1.00");
my $erster = '<tr class="odd"><td informId="Kurve" colspan="2"><img src="http://10.0.0.5:8083/fhem/YAF/www/global/img/Heizkurve';
my $zweiter = '.png" width="630" height="282"><br></td>';
my $url = "$erster$heizkurve$zweiter";
return $url;
}
Perl Code in der 99_myUtils.pm. Der Trick ist einfach der, je nach ausgelesener Heizkurve vom eBus das entsprechende Bild als Grafik zu laden.
Die Files heißen dann Heizkurve0.2.png - Heizkurve1.5.png. Die Ip-Adresse und das Verzeichnis muss euren Gegebenheiten angepasst werden.
Ich bin mit 10 Bildern ausgekommen.
LG
Reinhart
so ... dann werde ich mal den anfang machen :)
der RPi ist zusammengebaut, hat alles wunderbar funktioniert - nur der abstandhalter geht ein wenig zäh durch das loch.
vor der "hochzeit" hab ich meinen raspberry pi 3 lt. anleitung vorbereitet.
nachdem ich openhabian verwende, hab ich die serial ports über openhabian-config disabled
(->30 System Setting -> 35 Serial Port: alle 3 Optionen auswählen).
im hintergrund wird dabei folgendes ausgeführt:
$ systemctl stop serial-getty@ttyAMA0.service
$ systemctl disable serial-getty@ttyAMA0.service
$ systemctl stop serial-getty@serial0.service
$ systemctl disable serial-getty@serial0.service
$ systemctl stop serial-getty@ttyS0.service
$ systemctl disable serial-getty@ttyS0.service
das update der config.txt wird durch openhabian-config gleich mitgemacht.
(Adding 'dtoverlay=pi3-miniuart-bt' to /boot/config.txt (RPi3))
alles weitere kernel headers, ttyebus installieren geht wieder 1:1 nach anleitung.
im test hab ich den ebus natürlich noch nicht angeklemmt, deshalb leuchtet die LED 1 und 3 wie erwartet dauerhaft.
der schreibtest auf das device ist auch erfolgreich, die LED2 flackert immer kurz auf.
soweit - alles perfekt.
was mich jedoch nachdenklich stimmt ist das ls -l /dev
lrwxrwxrwx 1 root root 7 Mär 7 07:59 serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Mär 7 07:59 serial1 -> ttyS0
crw-rw---- 1 root dialout 204, 64 Mär 7 07:59 ttyAMA0
crw-rw-rw- 1 root root 10, 58 Mär 7 07:59 ttyebus
lt. Anleitung müsste der ttyAMA0 verschwunden sein, er ist leider immer noch sichtbar.
im lsmod scheint der ttyAMA0 hingegen nicht auf.
weiters ist scheinbar zumindest in der openhab ebus config noch keine auswahl vom /dev/ttyebus möglich,
dies kläre ich aber mit dem entwickler und gebe hier bescheid sobald sich was tut.
LG
Hallo,
ja das mit dem Abstandshalter habe ich vergessen zu erwähnen, das Loch mit einem 3,5mm Bohrer etwas zu erweitern, dann geht das ganz leicht durch!
Der AMA0 muss unbedingt verschwinden, sonst kommen sich die Treiber ins Kreuz!
Ich kenn jetzt dein System nicht, aber wenn du die serielle Einrichtung alles "disabled" hast, dann schau doch einmal in die Bootconfigs (cmdline.txt) ob da wo ein serielles Logging noch aktiviert ist (console=serial0,115200 oder console=ttyAMA0) und entferne alle Einträge dazu und dann einen Neustart.
LG
Hi,
in der cmdline.txt hab ich unter console "tty1" eingetragen
das dürfte aber passen - oder?
System basiert auf Raspbian Stretch Lite
LG
Ja das passt.
meine cmdline.txt sieht so aus, habe auch Stretch Lite
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=71510238-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
crw--w---- 1 root tty 4, 9 Feb 25 10:44 tty9
crw-rw-rw- 1 root root 10, 58 Feb 25 10:44 ttyebus
crw------- 1 root root 5, 3 Feb 25 10:44 ttyprintk
crw------- 1 root root 10, 239 Feb 25 10:44 uhid
crw------- 1 root root 10, 223 Feb 25 10:44 uinput
und so ls -l /dev
Eigentlich sollte mit raspi-config und Interfacing Options/ P6 Serial und 2 x "nein" alles erledigt sein.
LG
Reinhart
Zitat von: Reinhart am 07 März 2018, 09:17:55
Hallo,
ja das mit dem Abstandshalter habe ich vergessen zu erwähnen, das Loch mit einem 3,5mm Bohrer etwas zu erweitern, dann geht das ganz leicht durch!
...
LG
Wo kommt der denn eigentlich rein? (RPI oder Platine?)
Gruss Christoph
Zitat von: pc1246 am 07 März 2018, 11:14:31
Wo kommt der denn eigentlich rein? (RPI oder Platine?)
Gruss Christoph
von unten durch die ebus RPi Platine, damit diese nicht unabsichtlich mit dem Raspberry Kontakt bekommt.
Alternativ gibt es auch Raspberry Cases die sowas verhindern.
Zitat von: aia am 07 März 2018, 14:23:53
von unten durch die ebus RPi Platine, damit diese nicht unabsichtlich mit dem Raspberry Kontakt bekommt.
Alternativ gibt es auch Raspberry Cases die sowas verhindern.
Moin
Wozu das ist, war mir klar. Ich hatte mich nur an die Bilder von Chons erinnert, und da war eine Schraube zu sehen! Aber ich habs jetzt oben im Thread bei Reinhart gesehen, da ist der Fuss zu sehen!
Danke und Gruss
Christoph
Chons hatte das ursprünglich mit der Schraube und einem Abstandshalter gemacht. Da diese Plasitkschrauben aber nicht so leicht (nur 5mm lang) aufzutreiben sind, habe ich diese Abstandshalter dazu gelegt. Das geht sogar einfacher zu montieren und kann auch leicht gekürzt werden wenn das Gehäuse einen Zwischenboden hat.
Ein entsprechendes Gehäuse mit Zwischenboden hilft nicht viel, weil die Platine ja beim durchdrücken am HDMI Stecker den Kurzschluss machen würde.
LG
wenn sich wer wundert, der "komische Kugelschreiber" mit dem Kabel dran ist ein wasserdichter DS18b20 Temperaturfühler, den habe ich bei den Rpi Bausätzen (wenn es in die Packung ging) als Beilage dazu gelegt!
Den könnt ihr idealerweise direkt an Rohre mit einer Schelle (oder Kabelbinder) montieren um die Temperatur zu erfassen. Wärmeleitpaste wäre von Vorteil.
Beispiel ist oben. (https://forum.fhem.de/index.php/topic,84636.msg769463.html#msg769463)
LG
Reinhart
Hallo zuammen!
Ich hab inzwischen den eBus Rpi Adapter erfolgreich in Betrieb genommen. Allerdings verliert ebusd nach einigen Stunden die Verbindung zum Bus ("no signal"). Wenn ich den Rpi neu boote dann geht es wieder. Die Heizungsgeräte sind nicht betroffen. Habt Ihr vielleicht einen Tipp?
Viele Grüße
Jan Eric
Zitat von: jkyprian am 12 März 2018, 19:34:04
Hallo zuammen!
Ich hab inzwischen den eBus Rpi Adapter erfolgreich in Betrieb genommen. Allerdings verliert ebusd nach einigen Stunden die Verbindung zum Bus ("no signal"). Wenn ich den Rpi neu boote dann geht es wieder. Die Heizungsgeräte sind nicht betroffen. Habt Ihr vielleicht einen Tipp?
Viele Grüße
Jan Eric
Hallo! Lt. FHEM Wiki sollte hier ein Watchdog Abhilfe schaffen! (siehe https://wiki.fhem.de/wiki/EBUS#System.C3.BCberwachung)
LG
Zitat von: jkyprian am 12 März 2018, 19:34:04
Hallo zuammen!
Ich hab inzwischen den eBus Rpi Adapter erfolgreich in Betrieb genommen. Allerdings verliert ebusd nach einigen Stunden die Verbindung zum Bus ("no signal"). Wenn ich den Rpi neu boote dann geht es wieder. Die Heizungsgeräte sind nicht betroffen. Habt Ihr vielleicht einen Tipp?
Viele Grüße
Jan Eric
Man müsste jetzt wissen wer oder was das verursacht? Hast du schon eimal in den Logs (ebusd, syslog) geschaut ob hier irgend ein Hinweis steht?
Blinken die Leds in diesem Status noch?
LG
Zitat von: Reinhart am 12 März 2018, 22:05:39
Man müsste jetzt wissen wer oder was das verursacht? Hast du schon eimal in den Logs (ebusd, syslog) geschaut ob hier irgend ein Hinweis steht?
/var/log/syslog
syslog:Mar 12 23:44:52 raspi kernel: [12146.229627] ttyebus: Close at at major 10 minor 58
syslog:Mar 12 23:44:52 raspi kernel: [12146.229637] ttyebus: Close exit
/var/log/ebusd.log:
2018-03-12 23:43:37.046 [bus error] signal lost
2018-03-12 23:44:52.123 [bus notice] re-opened /dev/ttyebus
Zitat von: Reinhart am 12 März 2018, 22:05:39
Blinken die Leds in diesem Status noch?
Orange Led leuchtet, grün flimmert wg. der Aktivität auf dem eBus durch die Heizung.
ebusd scheint auch ok.
Es scheint mir am ttyebus zu liegen bzw. an der uart schnittstelle es Rpi. Ich hab schon versucht ttyebus neu zu laden (also erstmal ebusd gestoppt. dann rmmod ttyebus und insmod ttyebus). Hat leider nicht gebracht. Gibt es eine Möglichkeit den uart des Rpi zu reseten?
Viele Grüße,
Jan Eric
Hi,
Du könntest den USB Port reseten:
http://www.gtkdb.de/index_36_2304.html
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
da passiert eindeutig mit dem Treiber was und irgendwas bringt ihn zum Beenden seiner Tätigkeit.
syslog:Mar 12 23:44:52 raspi kernel: [12146.229627] ttyebus: Close at at major 10 minor 58
syslog:Mar 12 23:44:52 raspi kernel: [12146.229637] ttyebus: Close exit
Galileo ist bis zum Sonntag nicht erreichbar, wird sich aber darum kümmern, bzw. bei dir melden!
Kannst du noch posten welcher Typ von Raspi das ist?
Kannst du uns eventuell noch ein normales Log vom ebsud posten, so dass wir in etwa die letzten 5 Minuten vor dem Absturz sehen?
LG
Moin
Da bin ich ja froh, dass ich mich noch nicht rangemacht habe!
@Arnd: Das Board steckt auf dem RPI nicht am USB!
Gruss Christoph
Zitat von: pc1246 am 13 März 2018, 09:06:31
Moin
Da bin ich ja froh, dass ich mich noch nicht rangemacht habe!
Bei uns allen läuft der Treiber problemlos (Raspi B+, Raspi 2, Raspi 3), das ist der erste wo jetzt Probleme bekannt sind und auch dessen Ursache wird zu finden sein.
Bei mir läuft das seit vielen Wochen ohne einen einzigen Fehler.
LG
Zitat von: Reinhart am 13 März 2018, 09:26:13
Bei uns allen läuft der Treiber problemlos (Raspi B+, Raspi 2, Raspi 3), das ist der erste wo jetzt Probleme bekannt sind und auch dessen Ursache wird zu finden sein.
Bei mir läuft das seit vielen Wochen ohne einen einzigen Fehler.
LG
Moin Reinhart
Das war auch so nicht gemeint. Zum einen haengt mein Leben nicht am eBus, und zum Anderen wollte ich das auf einem anderen RPI machen, den ich aber noch in Benutzung habe!
Gruss Christoph
Zitat von: RaspiLED am 13 März 2018, 07:26:39
Hi,
Du könntest den USB Port reseten:
http://www.gtkdb.de/index_36_2304.html
Danke für den Tipp. Habe es gerade ausprobiert. Hilft leider anscheinend nicht. Ich werde heute abend mich nochmal dransetzen...
Zitat von: Reinhart am 13 März 2018, 09:26:13
Bei uns allen läuft der Treiber problemlos (Raspi B+, Raspi 2, Raspi 3), das ist der erste wo jetzt Probleme bekannt sind und auch dessen Ursache wird zu finden sein.
Bei mir läuft das seit vielen Wochen ohne einen einzigen Fehler.
Ich polle alle 10 Sekunden mit eBus Werte der Heizung. Was ich mal probieren könnte ist das pollen auszustellen und nur lesend auf den eBus zuzugreifen.
alle 10 Sekunden ist etwas zuviel des Guten, das kommt darauf wieviel Werte du auslesen willst, aber das wird er kaum schaffen. Du musst bedenken, das für die normale Buskommunikation zwischen den Geräten auch noch genügend Zeitfenster vorhanden sein müssen. Das ist ja der eigentliche Zweck des eBus. Wenn du jetzt ständig den Bus belegst, bleibt da kaum Zeit für die internen Daten über.
Ich polle alle 10 - 15 Minuten.
Nichts desto trotz, sollte der Treiber sich dadurch nicht beenden.
LG
Zitatsyslog:Mar 12 23:44:52 raspi kernel: [12146.229627] ttyebus: Close at at major 10 minor 58
syslog:Mar 12 23:44:52 raspi kernel: [12146.229637] ttyebus: Close exit
Der Treiber beendet sich nicht von selbst, sondern er wird explizit von aussen beendet, durch den Aufruf von "ttyebus_close".
Das scheint aber der ebusd zu sein, der das sendet:
Zitat2018-03-12 23:43:37.046 [bus error] signal lost
2018-03-12 23:44:52.123 [bus notice] re-opened /dev/ttyebus
der hier wegen "signal lost" ein "close" und ein "reopen" macht. Wenn das stimmt, müsste im kernel log unmittelbar darauf so ein open sichtbar sein:
ttyebus: Open at at major xx minor yy"allerdings erst wenn man "DEBUG" einschaltet. Du kannst das einmal temporär probieren, indem du im File ttyebusm.c in Zeile 54 den Kommentar (//) von "#define DEBUG 1" entfernst und neu compilierst.
Aber Achtung, das erzeugt eine Menge LOGs, also nicht vergessen wieder auszuschalten.
Wenn das nicht erscheint, geht vielleicht das re-open schief?
LG
Eduard
Zitat von: galileo am 13 März 2018, 16:10:26
allerdings erst wenn man "DEBUG" einschaltet. Du kannst das einmal temporär probieren, indem du im File ttyebusm.c in Zeile 54 den Kommentar (//) von "#define DEBUG 1" entfernst und neu compilierst.
Aber Achtung, das erzeugt eine Menge LOGs, also nicht vergessen wieder auszuschalten.
Danke für den Tipp. Hab jetzt DEBUG eingeschaltet und lass es mal laufen...
Zitat von: jkyprian am 13 März 2018, 18:09:27
Danke für den Tipp. Hab jetzt DEBUG eingeschaltet und lass es mal laufen...
/var/log/kern.log
Mar 13 18:39:41 raspi kernel: [25066.039011] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039017] ttyebus: Poll succeeded. RxHead=51, RxTail=46
Mar 13 18:39:41 raspi kernel: [25066.039024] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039029] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039039] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039046] ttyebus: Poll succeeded. RxHead=51, RxTail=47
Mar 13 18:39:41 raspi kernel: [25066.039053] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039058] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039069] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039075] ttyebus: Poll succeeded. RxHead=51, RxTail=48
Mar 13 18:39:41 raspi kernel: [25066.039082] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039087] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039097] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039103] ttyebus: Poll succeeded. RxHead=51, RxTail=49
Mar 13 18:39:41 raspi kernel: [25066.039110] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039116] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039126] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039132] ttyebus: Poll succeeded. RxHead=51, RxTail=50
Mar 13 18:39:41 raspi kernel: [25066.039139] ttyebus: Read request with offset=0 and count=1
Mar 13 18:39:41 raspi kernel: [25066.039144] ttyebus: Read exit with 1 bytes read
Mar 13 18:39:41 raspi kernel: [25066.039154] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.039158] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.064234] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.064244] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.064357] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.064363] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.115231] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.115242] ttyebus: Poll timeout
Mar 13 18:39:41 raspi kernel: [25066.115271] ttyebus: Poll request
Mar 13 18:39:41 raspi kernel: [25066.115277] ttyebus: Poll timeout
/var/log/ebusd.log
2018-03-13 18:39:31.130 [update info] received MM cmd: 1013050a00
2018-03-13 18:39:31.130 [update notice] received unknown MM cmd: 1013050a00
2018-03-13 18:39:31.722 [update info] received BC cmd: 10fe080208003700300000003f
2018-03-13 18:39:31.722 [update notice] received unknown BC cmd: 10fe080208003700300000003f
2018-03-13 18:39:31.808 [main debug] performing regular tasks
2018-03-13 18:39:31.936 [update info] received MS cmd: 011506210400e00040 / 0a60800d02e8030000f900
2018-03-13 18:39:31.936 [update notice] received upd00 vorlauftemp_ww2 QQ=01: 24.9
2018-03-13 18:39:32.416 [update info] received MM cmd: 131005030c011a000031ffff3f43000100
2018-03-13 18:39:32.416 [update notice] received unknown MM cmd: 131005030c011a000031ffff3f43000100
2018-03-13 18:39:32.973 [bus debug] ERR: read timeout during receive command, switching to skip
2018-03-13 18:39:33.103 [bus debug] ERR: read timeout during receive response, switching to skip
2018-03-13 18:39:33.217 [update info] received MS cmd: 011506210400840040 / 0a04800d02e8030000ee01
2018-03-13 18:39:33.217 [update notice] received upd00 hwtemp2 QQ=01: 49.4
2018-03-13 18:39:33.431 [bus debug] ERR: read timeout during receive response, switching to skip
2018-03-13 18:39:34.155 [update info] received MS cmd: 011506210400800040 / 0a00800d02f4010cfe6200
2018-03-13 18:39:34.155 [update notice] received upd00 außentemp2 QQ=01: 9.8
2018-03-13 18:39:35.404 [update info] received MS cmd: 011506210402c80040 / 0a4841042a9f0500006304
2018-03-13 18:39:35.405 [update notice] received upd02 uhrzeit QQ=01: 18:43
2018-03-13 18:39:36.373 [update info] received MS cmd: 011506210402c60040 / 0a46410428ffff0000a3a8
2018-03-13 18:39:36.374 [update notice] received upd02 datum QQ=01: 14.03.2018
2018-03-13 18:39:37.134 [mqtt debug] publish ebusd/upd00/vorlauftemp_ww2 24.9
2018-03-13 18:39:37.411 [update info] received BC cmd: 10fe100a0c11030000030a010100213500
2018-03-13 18:39:37.411 [update notice] received unknown BC cmd: 10fe100a0c11030000030a010100213500
2018-03-13 18:39:37.518 [update info] received MS cmd: 011506210402b50040 / 0a35810000ff0000000100
2018-03-13 18:39:37.518 [update notice] received upd02 status2 QQ=01: Heizbetrieb
2018-03-13 18:39:38.091 [update info] received BC cmd: 10fe100a0e100300000000f4000000e001c800
2018-03-13 18:39:38.091 [update notice] received unknown BC cmd: 10fe100a0e100300000000f4000000e001c800
2018-03-13 18:39:38.593 [update info] received MS cmd: 011506210400e00040 / 0a60800d02e8030000fc00
2018-03-13 18:39:38.593 [update notice] received upd00 vorlauftemp_ww2 QQ=01: 25.2
2018-03-13 18:39:38.790 [update info] received MM cmd: 031005030c010148053218ff3f00000600
2018-03-13 18:39:38.790 [update notice] received unknown MM cmd: 031005030c010148053218ff3f00000600
2018-03-13 18:39:39.037 [bus info] poll cmd: 31150621047d870002
2018-03-13 18:39:39.041 [bus debug] arbitration delay 158 micros
2018-03-13 18:39:41.789 [bus debug] switching from ready to send command
2018-03-13 18:39:41.789 [bus debug] notify request: ERR: SYN received
2018-03-13 18:39:41.789 [bus error] poll waermepumpe heizenergie_kwh failed: ERR: SYN received
2018-03-13 18:39:41.789 [bus debug] ERR: SYN received during send command, switching to ready
2018-03-13 18:39:41.790 [update info] received MM cmd: 131005030c011a000032ffff3f43000100
2018-03-13 18:39:41.790 [update notice] received unknown MM cmd: 131005030c011a000032ffff3f43000100
2018-03-13 18:39:41.791 [update info] received MS cmd: 011506210400840040 / 0a04800d02e8030000ee01
2018-03-13 18:39:41.791 [update notice] received upd00 hwtemp2 QQ=01: 49.4
2018-03-13 18:39:41.809 [main debug] performing regular tasks
2018-03-13 18:39:41.817 [bus debug] ERR: read timeout during receive command, switching to skip
2018-03-13 18:39:42.136 [mqtt debug] publish ebusd/upd00/vorlauftemp_ww2 25.2
2018-03-13 18:39:43.038 [bus debug] ERR: read timeout during skip, switching to no signal
2018-03-13 18:39:43.038 [bus error] signal lost
2018-03-13 18:39:43.137 [mqtt debug] publish ebusd/global/signal false
2018-03-13 18:39:43.137 [mqtt debug] publish ebusd/global/uptime 2512
2018-03-13 18:39:51.809 [main debug] performing regular tasks
2018-03-13 18:39:59.143 [mqtt debug] publish ebusd/global/uptime 2528
2018-03-13 18:40:01.810 [main debug] performing regular tasks
2018-03-13 18:40:11.811 [main debug] performing regular tasks
Für mich sieht das so aus als ob bei ttyebus gar keine Daten mehr ankommen (Poll request -> Poll timeout)
Nachtrag: Habe jetzt zusätzlich IRQDEBUG eingeschaltet. Wenn er sich aufhängt dann kommen keine IRQs mehr.
Hab Ihr eine Idee was da vorgehen könnte?
ZitatHab Ihr eine Idee was da vorgehen könnte?
Mit
watch -n1 "cat /proc/interrupts"könntest du feststellen, ob der Linux Kernel die Interrupts überhaupt noch sieht...
LG
Zitat von: galileo am 14 März 2018, 09:06:26
Mit
watch -n1 "cat /proc/interrupts"
könntest du feststellen, ob der Linux Kernel die Interrupts überhaupt noch sieht...
Every 1.0s: cat /proc/interrupts raspi: Wed Mar 14 10:09:07 2018
CPU0 CPU1 CPU2 CPU3
16: 0 0 0 0 bcm2836-timer 0 Edge arch_timer
17: 1884043 1720809 1514576 1595765 bcm2836-timer 1 Edge arch_timer
23: 18301 0 0 0 ARMCTRL-level 1 Edge 3f00b880.mailbox
24: 2 0 0 0 ARMCTRL-level 2 Edge VCHIQ doorbell
46: 0 0 0 0 ARMCTRL-level 48 Edge bcm2708_fb dma
48: 0 0 0 0 ARMCTRL-level 50 Edge DMA IRQ
50: 65307 0 0 0 ARMCTRL-level 52 Edge DMA IRQ
59: 0 0 0 0 ARMCTRL-level 61 Edge bcm2835-auxirq
62: 12943614 0 0 0 ARMCTRL-level 64 Edge dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
79: 0 0 0 0 ARMCTRL-level 81 Edge 3f200000.gpio:bank0
80: 0 0 0 0 ARMCTRL-level 82 Edge 3f200000.gpio:bank1
83: 776 0 0 0 ARMCTRL-level 85 Edge 3f804000.i2c
86: 55341 0 0 0 ARMCTRL-level 88 Edge mmc0
87: 302469 0 0 0 ARMCTRL-level 89 Edge ttyebus_irq_handler
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 567063 650351 461451 619155 Rescheduling interrupts
IPI3: 8 16 15 12 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 196600 82008 80168 123790 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
Err: 0
In der Zeile "87" ändert die "302469" sich nicht. Heißt dies, dass der uart keine Interrupts mehr auslöst?
ZitatHeißt dies, dass der uart keine Interrupts mehr auslöst?
Das heißt es wohl. Man müsste jetzt herausbekommen, wo die Information steckenbleibt.
1. Ist der UART vielleicht disabled ?
2. Ist der Interrupt im UART maskiert ?
3. Ist der Interrupt im Interrupt Controller maskiert ?
Da müsste man einen Spion schreiben (der die zugehörigen Register ausliest und im Log ausgibt) und am besten in die Poll Routine setzen.
Ich kann das aber erst nächste Woche machen - ich bin diese Woche eigentlich gar nicht (mehr) da....
LG
Zitat von: galileo am 14 März 2018, 13:43:02
Das heißt es wohl. Man müsste jetzt herausbekommen, wo die Information steckenbleibt.
1. Ist der UART vielleicht disabled ?
2. Ist der Interrupt im UART maskiert ?
3. Ist der Interrupt im Interrupt Controller maskiert ?
Da müsste man einen Spion schreiben (der die zugehörigen Register ausliest und im Log ausgibt) und am besten in die Poll Routine setzen.
Gute Idee! Also gleich mal reingehackt: Der Übertäter scheint ein "Overrun error" zu sein denn:
UART_RX_ERR = 0x8 = 1000
Die Doku sagt dazu:
Zitat
Overrun error. This bit is set to 1 if data is received and the FIFO is already full.
This bit is cleared to 0 by a write to UARTECR.
The FIFO contents remain valid because no more data is written when the FIFO is full, only the contents of the shift register are overwritten. The CPU must now read the data, to empty the FIFO.
Als Test werde ich mal UART_RX_ERR löschen beim öffnen des Treibers. Dazu muss ich jetzt aber erstmal ggf. einige Stunden warten bis der Fehler wieder auftritt...
Zitat von: jkyprian am 14 März 2018, 16:39:21
Als Test werde ich mal UART_RX_ERR löschen beim öffnen des Treibers. Dazu muss ich jetzt aber erstmal ggf. einige Stunden warten bis der Fehler wieder auftritt...
Einfach nur UART_RX_ERR=0 zu schreiben funktioniert nicht. Was funktioniert ist das Datenregister auszulesen. Das führt zum Löschen des Overflow Bits. Wenn man dies in der
ttyebus_open macht dann läuft nach einem Restart von ebusd wieder alles.
Vermutlich entsteht das Problem bei einem IRQ Buffer overrun. Da wird nämlich zwar UART_RX_ERR gelöscht aber das Datenregister nicht gelesen.
Zitat von: jkyprian am 14 März 2018, 23:49:20
Vermutlich entsteht das Problem bei einem IRQ Buffer overrun. Da wird nämlich zwar UART_RX_ERR gelöscht aber das Datenregister nicht gelesen.
Läut seit einigen Tagen ohne Probleme. Allerdings bekomme ich dann und wann immer mal wieder overruns des read buffers. Spricht irgendwas dagegen den Buffer einfach etwas größer zu machen?
Hallo jkyprian,
ich bin jetzt wieder im Lande und werde mir die Sache morgen genauer ansehen. Vorerst vielen Dank für deine Geduld, deine Analyse und vor allem für die Lösung !!!
ZitatSpricht irgendwas dagegen den Buffer einfach etwas größer zu machen?
Da spricht überhaupt nichts dagegen, das war von meiner Seite einfach "Sparsamkeit" ohne besonders darüber nachzudenken. Ich denke wir werden das auf 256 Bytes erhöhen, oder vielleicht kann John etwas dazu aus der Erfahrung heraus sagen ?
Kannst du mir bitte vielleicht deine Änderungen per PM zukommen lassen, ich hätte dann eine Basis um den Source entsprechend anzupassen. Du hast ja quasi den Test schon vorweg genommen.
Nochmals vielen Dank,
LG
Eduard
Zitat von: galileo am 18 März 2018, 18:39:12
ich bin jetzt wieder im Lande und werde mir die Sache morgen genauer ansehen. Vorerst vielen Dank für deine Geduld, deine Analyse und vor allem für die Lösung !!!Da spricht überhaupt nichts dagegen, das war von meiner Seite einfach "Sparsamkeit" ohne besonders darüber nachzudenken. Ich denke wir werden das auf 256 Bytes erhöhen, oder vielleicht kann John etwas dazu aus der Erfahrung heraus sagen ?
Kannst du mir bitte vielleicht deine Änderungen per PM zukommen lassen, ich hätte dann eine Basis um den Source entsprechend anzupassen. Du hast ja quasi den Test schon vorweg genommen.
Hallo Eduard, ich hab Dir einen Pull Request mit meinen Änderungen geschickt. Im Moment habe ich die Größe des Read Buffers auf 128 gesetzt. Ich schau nachher mal in den Logs ob der Overrun weiterhin auftritt. Viele Grüße, Jan Eric
Zitat von: jkyprian am 18 März 2018, 19:21:43
Im Moment habe ich die Größe des Read Buffers auf 128 gesetzt.
Das erscheint mir eigentlich viel zu hoch und würde bedeuten, dass im driver wesentlich schneller der Puffer gefüllt wird, als ebusd diesen auslesen kann.
Puffer sind bei eBUS generell ein Problem und eigentlich immer ein Killer Kriterium für saubere Kommunikation.
Hi,
Mein Setup fhem auf rpi3(Diele) und rpi2(Heizung) mit ebus v2.1 an einer Wolf Heizung. Momentan 1-Wire an Arduino mit Firmata (Ethernet) das aber auf den rpi2(Heizung) soll.
Ich habe am WE die Platine erhalten (DANKE Galileo) und ttyebus erfolgreich installiert und mit ebusd bereits Heizungswerte (Wolf) im fhem erhalten. Soweit sehr gut. Beim Versuch 1-Wire auf den rpi2(Heizung) unzuziehen bin ich auf die blöde Idee gekommen meine beiden RPIs auf den neuesten Stand zu bringen:
sudo rpi-update
sudo apt-get update && apt-get upgrade
sudo apt-get dist-upgrade
dabei ist der ttyebus auf dem rpi2(Heizung) "verloren" gegangen. Ein erneutes installieren (https://github.com/ebus/ttyebus) scheiter an:
make -C /lib/modules/4.14.27-v7+/build M=/home/pi/ttyebus modules
make[1]: *** /lib/modules/4.14.27-v7+/build: Datei oder Verzeichnis nicht gefunden. Schluss.
Makefile:24: die Regel für Ziel ,,all" scheiterte
make: *** [all] Fehler 2
Frage 1: Muss ich wieder auf den vorherigen Kernel zurück? Bin kein Linux Crack, scheint aber als ob header für diesen Kernel nicht existieren.... und daher Make failed?
Frage 2: Bin ich mit dem 1-Wire auf dem richtigen Weg? Auf dem rpi2(Heizung) habe ich bereits die aktuellen Temperaturwerte in /sys/bus/w1/devices/28-000004be1fb1/w1_slave. Jetzt weis ich aber nicht wie ich die auf dem fhem auf rpi3(Diele) erhalte. Geht das über owfs/OWserver oder kann ich über Busmaster auf den remoten RPI zugreifen?
Danke schonmal
Markus
Hallo MarkusEd
Es gibt da mehre Möglichkeiten die Messwerte auf den richtigen PI zu bringen, ich mache das mit Fhem2Fhem und Remotepi.
define RemotePI6 FHEM2FHEM 10.0.0.6:7072 LOG:.*(temperature|humidity|pressure).*
define Temp_DS18b20_2 cloneDummy Temp_DS18b20
attr Temp_DS18b20_2 group Fhem2Fhem
attr Temp_DS18b20_2 icon temp_temperature
attr Temp_DS18b20_2 room Entwicklung
attr Temp_DS18b20_2 stateFormat {sprintf("T: %.2f", ReadingsVal("Temp_DS18b20_2","temperature",0))}
define BME280_2 cloneDummy BME280
attr BME280_2 group Fhem2Fhem
attr BME280_2 icon temp_temperature
attr BME280_2 room Entwicklung
attr BME280_2 stateFormat {sprintf("T: %.1f Grad Feuchte: %.1f ", ReadingsVal($name,"temperature",0), ReadingsVal($name,"humidity",0))}
Beispiel mit 2 Sensoren, 10.0.0.6 ist hier der Raspi mit ebusd und werden in dieser Instanz dann dargestellt. Vorausgesetzt dass auch eine Miniversion von FHEM am ebusd läuft um dort die Sensoren zu erfassen.
Zu deinem ersten Problem, das hatte ich auch schon, entweder du biegst die richtigen Verzeichnisse jetzt händisch hin (indem du in die Scripts eingreifst), oder besser du installierst neu, machst die Updates und dann die Treiberinstallation, sonst kommst du aus dem Dilema nicht mehr so leicht raus. Es hätte geklappt, wenn du vorher einen uninstall des Treiber gemacht hättest.
Ich habe dazu immer ein paar SD Karten rumliegen, mit denen ich sowas schnell testen kann und das funktionierende Original nicht angreifen muss. Kopie ziehen und du ersparst dir letztlich viel Arbeit.
LG
Danke Reinhard,
habs fast hinbekommen nur fhem2fhem fehlt noch. Ich habe neu installiert. EBUSD liefert wieder Daten, wenn ich auch noch an den *.csv Daten arbeiten muss.
Auf dem zweiten RPi läuft jetzt auch fhem und GPIO4 device ist angelegt (onewire). Momentan scheint sich das aber noch nicht zu aktualisieren.
In dmesg steht:
w1_add_master_device: set_pullup requires write_byte or touch_bit, disabling
Vorsicht bei Kernel upgrade > 4.9.80
Make für den ttyebus läuft nur mit Kernel 4.9.80-v7+ da keine neueren Header geladen werden:
pi@raspberrypi:~ $ ls /usr/src/
linux-headers-4.9.80+ linux-headers-4.9.80-v7+
CIAO
Markus
ZitatHallo Eduard, ich hab Dir einen Pull Request mit meinen Änderungen geschickt. Im Moment habe ich die Größe des Read Buffers auf 128 gesetzt.
Ich habe die von jkyprian vorgeschlagenen Änderungen in den Source vom ttyebus übernommen. Somit sollte es nach einem Buffer Overflow nicht mehr zu einem Deadlock kommen.
Vielen Dank an jkyprian!
Die neue Version ist nun 1.5 und kann von Github heruntergeladen werden.
LG
Eduard
@MarkusEd
scheint irgendwie bei der Busmasterkonfiguration zu liegen. Ich hänge dir einmal meine funktionierende Konfiguration an, vor allem die 2 Einträge in der /boot/config.txt. Vielleicht hast hier wo eine Kleinigkeit übersehen.
#################################################
# 1-Wire Komponenten
#################################################
# Modul 58_GPIO4.pm aus dem contrib Verz. nach /opt/FHEM/FHEM kopieren.
# /boot/config.txt
# activating 1-wire with pullup
# dtoverlay=w1-gpio-pullup
#ls /sys/bus/w1/devices/
#pi@raspberrypi:/opt/fhem $ ls /sys/bus/w1/devices/
#28-0417c1d99bff w1_bus_master1
define RPi GPIO4 BUSMASTER
attr RPi room 1-wire
define Temp_DS18b20 GPIO4 28-0417c1d99bff
attr Temp_DS18b20 group 1-wire
attr Temp_DS18b20 model DS18B20
attr Temp_DS18b20 pollingInterval 300
attr Temp_DS18b20 room 1-wire
define FileLog_Temp_DS18b20 FileLog ./log/Temp_OG-%Y-%W.log Temp_DS18b20
attr FileLog_Temp_DS18b20 logtype text
define SVG_FileLog_Temp_DS18b20 SVG FileLog_Temp_DS18b20:SVG_FileLog_Temp_DS18b20:CURRENT
attr SVG_FileLog_Temp_DS18b20 room 1-wire
define forwardRemote dummy
LG
Hallo Reinhard,
1wire Werte bekomme ich jetzt auf dem HeizungsPI! Ich war nur verwirrt dass sich der timestamp der w1_slave files nicht aktuialisiert, die Werte sind aber aktuell. Dem Fehler "w1_add_master_device: set_pullup requires write_byte or touch_bit, disabling" in dmesg gehe ich später nach:
Hab mich eigentlich an deine Vorgabe gehalten.
pi@heizungpi:/opt/fhem $ tail /boot/config.txt
# activating 1-wire with pullup
dtoverlay=w1-gpio-pullup
So nun zum FHEM2FHEM Teil, der funktioniert noch nicht.
Der HeizungPi (192.168.2.63) erzeugt die Werte. Das funktioniert jetzt.
define KaminAnPumpe_0 GPIO4 28-000003e6cc14
attr KaminAnPumpe_0 model DS18B20
attr KaminAnPumpe_0 room GPIO4
Erfolg:
setstate KaminAnPumpe_0 T: 29.562
setstate KaminAnPumpe_0 2018-03-21 06:59:02 failures 0
setstate KaminAnPumpe_0 2018-03-21 18:45:57 state T: 29.562
setstate KaminAnPumpe_0 2018-03-21 18:45:57 temperature 29.562
Auf dem FHEMPI der die Wert darstellen sollte habe ich:
define RemotePI FHEM2FHEM 192.168.2.63:7072 LOG:.*(temperature).
define KaminAnPumpe cloneDummy KaminAnPumpe_0
attr KaminAnPumpe room Keller
attr KaminAnPumpe stateFormat {sprintf("T: %.2f", ReadingsVal("KaminAnPumpe","temperature",0))}
Ergebnis:
setstate RemotePI connected
setstate KaminAnPumpe T: 0.00
setstate KaminAnPumpe 2018-03-21 18:20:01 state defined
Irgendwo habe ich da noch den Wurm drinnen......
CIAO Markus
define RemotePI FHEM2FHEM 192.168.2.63:7072 LOG:.*(temperature).
dir fehlt hinten ein Stern
define RemotePI FHEM2FHEM 192.168.2.63:7072 LOG:.*(temperature).*
so
LG
Zitat von: galileo am 21 März 2018, 11:26:35
Ich habe die von jkyprian vorgeschlagenen Änderungen in den Source vom ttyebus übernommen. Somit sollte es nach einem Buffer Overflow nicht mehr zu einem Deadlock kommen.
Der ttyebus läuft jetzt bei mir seit 3 Tagen ohne Probleme. Allerdings erhalte ich immer noch Buffer Overruns:
Mar 18 16:28:30 raspi kernel: [265585.823286] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:30 raspi kernel: [265585.888772] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:30 raspi kernel: [265585.935656] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:30 raspi kernel: [265585.982529] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.029503] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.076281] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.123123] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.170032] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.216872] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.263798] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.310634] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.357720] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.404380] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.451257] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.498125] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.545106] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.591882] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.638755] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.685602] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.732477] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.736874] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.741149] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.745364] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.749611] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.753829] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.758047] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.762293] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.766511] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.770757] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.774974] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.779582] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.783832] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.788046] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.792295] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.796510] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.800731] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.805028] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.809246] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.813726] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.817943] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.822137] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.826329] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.830548] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.834741] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.838931] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.843127] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.847343] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.851540] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.855755] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.860264] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.864505] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.868735] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.873347] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.877655] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.881867] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.886166] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.890457] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.894854] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.899100] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.903315] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.907555] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.911721] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.916173] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:31 raspi kernel: [265586.982465] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.029355] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.076241] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.123106] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.169981] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.216826] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.263727] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.310576] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.357718] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.404328] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.408753] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.412998] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.417216] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.421487] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.425705] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.429950] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.434169] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.438388] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.442658] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.446877] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.451461] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.455679] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.459924] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.464169] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.468388] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.472632] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.476903] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.481148] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.544985] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.591810] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.638713] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.685552] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.732454] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.779302] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.826179] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.873086] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 16:28:32 raspi kernel: [265587.919935] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 21:24:25 raspi kernel: [265587.966780] ttyebus: IRQ: Buffer overrun. RxHead=59, RxTail=60
Mar 18 21:24:25 raspi kernel: [283340.745821] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.792632] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.839486] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.843906] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.848100] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.852315] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.856511] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.860701] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.864894] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.869115] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.873307] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.877501] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.881692] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.885938] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.890572] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.894815] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.899038] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.903253] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.907501] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.911743] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.916018] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.920232] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.924478] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.928724] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.932968] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.937213] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.941406] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283340.945862] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:25 raspi kernel: [283341.011369] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.058211] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.062632] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.066879] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.071095] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.075340] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.079561] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.083802] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.088024] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.092239] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.096487] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.100703] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.105341] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.109560] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.113777] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.118023] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.122267] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.126513] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.130730] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.134973] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.139247] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.143489] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.198833] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.245743] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.292584] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.339485] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.386336] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.433207] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.480097] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.526961] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.573808] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.620710] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.667588] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.714511] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.761518] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.808187] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.855064] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.901936] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.948817] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.953264] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.957483] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.961699] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.965896] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.970084] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.974278] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.978498] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.982690] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.986884] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.991101] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.995295] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283341.999981] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.004199] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.008447] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.012663] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.016884] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.021126] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.025350] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.029593] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.033810] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.038056] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.042274] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.046493] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:26 raspi kernel: [283342.050685] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.055139] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.120660] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.167561] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.214430] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.261294] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.308167] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.355038] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.401991] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.448791] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.495670] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.542513] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.589415] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.636263] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.683139] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.730118] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.776890] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.823764] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.870644] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.917518] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283342.964366] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.011266] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.015698] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.019912] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.024104] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.028298] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.032491] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.036710] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.040901] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.045095] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:27 raspi kernel: [283343.049287] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.053506] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.057699] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.062386] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.066605] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.070850] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.075225] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.079678] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.083923] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.088142] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.092386] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.096604] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.100823] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.105251] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.109470] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.113662] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.118121] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.183117] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 18 21:24:28 raspi kernel: [283343.229996] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 19 06:25:30 raspi kernel: [283343.276869] ttyebus: IRQ: Buffer overrun. RxHead=88, RxTail=89
Mar 19 06:25:30 raspi kernel: [315805.920635] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315805.924876] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315805.929326] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315805.933722] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315805.937942] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315805.942189] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315805.946407] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315805.950678] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:30 raspi kernel: [315806.011383] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.058256] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.105139] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.152008] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.156461] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.160652] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.164846] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.169038] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.173257] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.177449] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.181645] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.185835] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.190054] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.194247] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.198466] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.203102] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.207320] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.211564] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.215783] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.220028] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.224247] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.228491] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.232945] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.237190] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.241669] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.246071] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.250419] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.254586] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.259062] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.323868] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.370772] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.417637] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.464507] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.511388] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.558245] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.605117] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.652015] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.698861] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 06:25:31 raspi kernel: [315806.745737] ttyebus: IRQ: Buffer overrun. RxHead=65, RxTail=66
Mar 19 07:33:30 raspi kernel: [319885.612523] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.616733] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.620981] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.625196] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.629441] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.633659] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.637904] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.642123] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.646316] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.650742] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.716403] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.763287] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.810152] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.856996] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.903924] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.950774] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319885.997624] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.044524] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.048922] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.053221] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.057490] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.061891] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.066370] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.070590] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.074963] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.079208] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.083557] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.087880] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.092282] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.096735] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.100981] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:30 raspi kernel: [319886.105198] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:31 raspi kernel: [319886.109679] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:31 raspi kernel: [319886.169505] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:31 raspi kernel: [319886.216373] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 19 07:33:31 raspi kernel: [319886.263254] ttyebus: IRQ: Buffer overrun. RxHead=45, RxTail=46
Mar 20 01:27:26 raspi kernel: [384322.068432] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.072626] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.077310] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.081527] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.085745] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.090016] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.094261] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.098505] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.102724] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.106969] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.111188] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.115407] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.119652] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.123872] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.128063] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.132516] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.198181] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.244894] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.249288] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.253532] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.257777] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.261996] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.266215] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.270459] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.274710] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.278955] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.283196] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.287414] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.291996] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.296215] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.300459] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.304684] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.308913] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.313149] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.317416] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Mar 20 01:27:26 raspi kernel: [384322.321660] ttyebus: IRQ: Buffer overrun. RxHead=70, RxTail=71
Das ist jetzt eigentlich nicht weiter schlimm. Ich wüsste nur trotzdem ganz gerne woran das liegt. Im ebusd.log finden sich komischerweise keine Fehlermeldungen zu den Zeiten wo der Buffer overrun auftritt (was mich wiederum etwas wundert!? Es werden ja immerhin Daten verworfen). Gelegentlich kommt es zu einem bus error oder zu einem broadcast receive Fehler wie z.B.:
2018-03-21 21:01:26.080 [bus error] poll waermepumpe heizenergie_kwh failed: ERR: read timeout
2018-03-21 21:02:32.906 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:05:33.116 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:07:44.090 [bus error] poll heizkreis2 feuchte failed: ERR: read timeout
2018-03-21 21:08:32.918 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:09:29.491 [bus error] poll waermepumpe twr failed: ERR: read timeout
2018-03-21 21:11:33.158 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:12:59.107 [bus error] poll waermepumpe wwenergie_mwh failed: ERR: read timeout
2018-03-21 21:14:32.884 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:17:33.124 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:20:32.881 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:20:41.081 [bus error] poll waermepumpe betriebsstunden failed: ERR: read timeout
2018-03-21 21:21:44.109 [bus error] poll waermepumpe heizenergie_mwh failed: ERR: read timeout
2018-03-21 21:23:33.075 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:25:14.067 [bus error] poll heizkreis2 status failed: ERR: read timeout
2018-03-21 21:26:32.863 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:29:33.134 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:32:32.829 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:35:33.088 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:37:29.099 [bus error] poll heizkreis2 feuchte failed: ERR: read timeout
2018-03-21 21:38:32.818 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:41:33.203 [update notice] received broadcast error QQ=10: SE60 E OK
2018-03-21 21:44:32.915 [update notice] received broadcast error QQ=10: SE60 E OK
Das entspricht 23/4944=0.47% Errors pro Stunde. Ich vermute mal das ist durchaus normal?
Gibt es vielleicht Operationen (z.B. auf der SD-Karte aufräumen) die irgendwie die Linux Kernel und andere Prozesse blockieren?
Zitat von: jkyprian am 21 März 2018, 21:55:31
Der ttyebus läuft jetzt bei mir seit 3 Tagen ohne Probleme. Allerdings erhalte ich immer noch Buffer Overruns:
Mit RX_BUFF_SIZE = 256 gibt es auch bei mir keine Buffer Overruns mehr.
ZitatMit RX_BUFF_SIZE = 256 gibt es auch bei mir keine Buffer Overruns mehr.
Da es sich bei Linux einmal primär um kein Echtzeit Betriebssystem handelt, kann ich mir schon vorstellen, dass ein anderer Prozess wegen seiner höheren Priorität
den ebusd eine Zeit lang blockiert und deswegen der Buffer nicht ausgelesen werden kann.
Hast du noch etwas anderes auf dem Raspi laufen? Bzw. hast du einmal versucht, den Raspi neu aufzusetzen und nur den ebusd zu installieren? Das könnte diesen Verdacht erhärten.
Ich werde den Buffer im ttyebus halt noch einmal vergrößern, das tut ja nicht weh, aber die Frage ist natürlich: wo ist Schluß ? Da der ttyebus direkt im Interrupt läuft entgeht ihm nichts, also kann es letztlich
immer zu einem Overrun kommen wenn die Daten nicht zeitgerecht abgeholt werden...
Zitat von: galileo am 23 März 2018, 07:21:28
Da es sich bei Linux einmal primär um kein Echtzeit Betriebssystem handelt, kann ich mir schon vorstellen, dass ein anderer Prozess wegen seiner höheren Priorität den ebusd eine Zeit lang blockiert und deswegen der Buffer nicht ausgelesen werden kann. Hast du noch etwas anderes auf dem Raspi laufen? Bzw. hast du einmal versucht, den Raspi neu aufzusetzen und nur den ebusd zu installieren? Das könnte diesen Verdacht erhärten. Ich werde den Buffer im ttyebus halt noch einmal vergrößern, das tut ja nicht weh, aber die Frage ist natürlich: wo ist Schluß ? Da der ttyebus direkt im Interrupt läuft entgeht ihm nichts, also kann es letztlich immer zu einem Overrun kommen wenn die Daten nicht zeitgerecht abgeholt werden...
Auf meinem Raspi laufen noch einige andere Dienste (influxdb, chronograph, mosquitto, openhab2). Das ebusd ausgebremst wird kann also durchaus sein. Aber das müsste sich doch mit geeigneten Einstellungen vielleicht in den Griff bekommen lassen. Ich habe jetzt mal "Nice=-10" für ebusd gesetzt und die Buffergröße wieder auf 64.
Bei den verschiedenen Optionen wie nice, io priority, rtprio, etc blicke ich noch nicht so richtig durch. Hinweise und Tipp sind also sehr willkommen ;)
Zitat von: jkyprian am 23 März 2018, 21:12:43
Ich habe jetzt mal "Nice=-10" für ebusd gesetzt und die Buffergröße wieder auf 64.
Overrun tritt bei nice=-50 und Buffergröße 64 leider immer noch auf. Das gleiche bei
CPUSchedulingPolicy=rr
CPUSchedulingPriority=50
IOSchedulingClass=realtime
IOSchedulingPriority=0
und einer Buffergröße von 64.
CPUSchedulingPolicy=rr und Buffergröße 128 läuft jetzt seit 10 Stunden ohne Overrun. Ich werde das mal das Wochenende über beobachten.
hi, I followed all the instructions of galileo on my raspberry 2 with wheezy raspbian.
now I see the /dev/ttyebus device, but if I trying to use with ebusd I obtain no traffic:
root@rasprino:~# ebusd -f -d /dev/ttyebus --lograwdata=bytes
2018-03-28 19:17:37.118 [main notice] ebusd 3.1.v3.0-35-gb0e20b7 started
2018-03-28 19:17:37.389 [main error] error reading config files: ERR: duplicate entry, last error: /etc/ebusd/vaillant/1c.v81.4.csv:7: ERR: duplicate entry, duplicate ID
2018-03-28 19:17:37.404 [bus notice] bus started with own address 31/36
instead if I use /dev/ttyAMA0 (which does not disappear, even if is not in use) I see ack packets:
root@rasprino:~# ebusd -f -d /dev/ttyAMA0 --lograwdata=bytes
2018-03-28 19:17:02.492 [main notice] ebusd 3.1.v3.0-35-gb0e20b7 started
2018-03-28 19:17:02.744 [main error] error reading config files: ERR: duplicate entry, last error: /etc/ebusd/vaillant/1c.v81.4.csv:7: ERR: duplicate entry, duplicate ID
2018-03-28 19:17:02.754 [bus notice] bus started with own address 31/36
2018-03-28 19:17:02.796 [bus notice] <aa
2018-03-28 19:17:02.796 [bus notice] signal acquired
2018-03-28 19:17:02.845 [bus notice] <aa
2018-03-28 19:17:02.889 [bus notice] <aa
2018-03-28 19:17:02.934 [bus notice] <aa
2018-03-28 19:17:02.979 [bus notice] <aa
2018-03-28 19:17:03.024 [bus notice] <aa
2018-03-28 19:17:03.069 [bus notice] <aa
2018-03-28 19:17:03.113 [bus notice] <aa
2018-03-28 19:17:03.159 [bus notice] <aa
Hello modenet!
I think you have a Problem with the configuration files!
There are 2 installation methods:
Method 1: (you can read in John's (https://github.com/john30/ebusd-configuration)github)
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
Method 2:
You can also install from here (https://github.com/john30/ebusd-configuration/releases), but these files are a bit older.
Hallo
nachdem ich endlich dazu gekommen bin den Rpi Bausatz zu löten, möchte ich das Projekt weiter mit meinen minderen Linuxkenntnissen voran treiben.
Ich habe soweit alles "installiert". Starte ich den ebusd Service steht im ebusd.log leider nur
[bus error] unable to open /dev/ttyUSB0: ERR: element not found
in der etc/default/ebusd steht
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%name --httppath=/var/ebusd/hmtl"
steht nur
EBUSD_OPTS="--scanconfig"
erhalte ich den selben Fehler im log.
Kann mir hier jemand helfen?
Bin zwar technisch, sowie am PC sehr fit. Jedoch fehlt mir einiges ein Linuxerfahrung.
gruß,
Markus
edit:
EBUSD_OPTS="--device=/dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080"
hiermit kommt zumindest kein Fehler mehr.
dafür viele
2018-04-16 23:16:56.322 [update notice] unknown MS cmd: 1026b5050427005a00 / 00
2018-04-16 23:16:56.646 [update notice] unknown MS cmd: 1025b5040117 / 0100
2018-04-16 23:16:57.177 [update notice] unknown MS cmd: 1026b505082b0f010000000080 / 00
Ein Fortschritt ;-)
ich mache morgen weiter
Zitat von: Ghost-Talker am 16 April 2018, 20:49:28
Ich habe soweit alles "installiert". Starte ich den ebusd Service steht im ebusd.log leider nur
[bus error] unable to open /dev/ttyUSB0: ERR: element not found
in der etc/default/ebusd steht
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%name --httppath=/var/ebusd/hmtl"
EBUSD_OPTS="--device=/dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080"
hiermit kommt zumindest kein Fehler mehr.
das passt eigentlich nicht zusammen... Da muss ein anderer Fehler in der /etc/default/ebusd gewesen sein.
Zitat von: john30 am 17 April 2018, 07:37:05
das passt eigentlich nicht zusammen... Da muss ein anderer Fehler in der /etc/default/ebusd gewesen sein.
Verstehe das auch nicht. Habe nur die Zeile kopiert.
Momentan funktioniert es. Allerdings fehlen IMHO noch einige Funktionen bzw. Werte.
Außerdem sagt mir die Versionsanzeige "3.0pre.bbc4d04" obwohl sicher die 3.1 (https://github.com/john30/ebusd/releases/tag/v3.1) heruntergeladen wurde.
gibt es noch eine einfachere Möglichkeit die Sensoren den richtigen Werten in der Steuerung (Vaillant Auromatic620) zuzuweisen?
Es gibt wieder eine neue Adapterversion V2.2!
hier geht's zur Sammelbestellung V2.2! (https://forum.fhem.de/index.php/topic,93190.msg857894.html#msg857894)
LG
Reinhart
Zitat von: Reinhart am 19 Februar 2018, 19:38:23
Dazu den neuen eBus Treiber ... und läuft auf Raspi 1, 2 und 3! Getestet wurde unter Jessie und Stretch!
Demnach dürfte das auch auf einem Pi Zero W laufen, oder? Der Zero hat die gleiche CPU wieder Pi1, nur höher getaktet. Der 40pin-GPIO ist kompatibel mit dem Pi2/3, nur der Formfaktor passt dann nicht perfekt zur RPI-Platine, was mich aber nicht stört...
Verzicht des DC-Wandler bei der V2.2
Wer bei der V2.2 auf den DC-Wandler verzichtet oder keinen hat, der darf auf keinen Fall C3 und C4 bestücken!
Dafür muss dann der Jumper S1 verbunden (Lötbrücke) werden!
LG
Reinhart
Zitat von: Reinhart am 26 Februar 2018, 16:52:54
erster Treibertest!
Nach erfolgreicher Treiberinstallation könnt ihr ohne eBus den Treiber schon mal testen.
Öffnet einfach eine Konsole und gebt folgendes ein:
Null
echo "das ist ein Sendetest" >/dev/ttyebus
Die Sendeled (mittlere Led 2) muss am Rpi jetzt kurz aufblitzen!
Wenn kein eBus angeschlossen ist, müssen die beiden äußeren Leds (Led 1 + 3) permanent leuchten.
LG
Reinhart
Rpi Version 2.2 mit DC wandler hier:
Bei mir leuchtet keine Led beim treibertest :(
Aus familären Gründen (Aufmerksamkeitsersuchen meiner Kinder gestern Abend) habe ich die Ebus Platine noch nicht mit den ebus kabeln der therme in Verbindung bringen können.
Kann dann überhaupt etwas leuchten? Bin verwirrt.
ttyebus und ebusd sind installiert.
ZitatKann dann überhaupt etwas leuchten? Bin verwirrt.
Gelbe LED:
Zeigt die Stromversorgung des Prints an. Bei der DC Wandler Variante also ob "Stromversorgung Raspi --> DC/DC Wandler --> Regler für 5V am Print" in Ordnung ist.
Rote LED:
Zeigt an ob der Ausgangstransistor, der zum Schreiben auf dem Bus benötigt wird, richtig angesteuert wird. Deshalb leuchtet die LED auch (kurz auf) wenn der Bus nicht angeschlossen
ist, aber die richtigen Steuersignale vom Treiber kommen.
Grüne LED:
Leuchtet wenn am Bus ein "LOW" Signal erkannt wird. Wenn der Bus NICHT angeschlossen ist (offener Eingang), dann leuchtet die LED permanent.
Aber: Wenn die Stromversorgung nicht in Ordnung ist (Gelbe LED aus) dann funktioniert auch der Rest nicht und auch die rote und grüne LED werden nichts anzeigen.
LG
Eduard
Hallo HeikoGr und alle die den Rpi Print selber löten!
Ein beliebter Fehler beim Einlöten der LEDs ist das Vertauschen der Polung.
Bitte ganz genau aufpassen, dass sie richtig herum eingelötet werden.
Falsch eingebaute LEDs leuchten nicht! ((die Schaltung selbst wird aber möglicherweise sogar funktionieren - nie getestet))
1. Der längere Draht an der LED ist (normalerweise) der + Pol
2. Am Print ist der + Pol beschriftet. Er befindet sich immer auf der Seite in Richtung zum eBus Anschluss hin.
3. Wenn man die LED gegen das Licht hält dann kann man eine "Grundplatte" sehen, die einen Draht nach unten hat, und einen "Aufbau", der einen Draht nach oben oder seitlich weggehend hat. Siehe Bild anbei.
Der Draht VON DER GRUNDPLATTE IST DER MINUS POL !!!
Wenn die LED also schon eingebaut ist, ist dies die einzige Methode um die korrekte Polung festzustellen.
Wenn man den RPI Print also vor sich hält und seitlich auf die drei LEDs blickt, dann müssen allr LEDs die "Grundplatte" (den Minus Pol) RECHTS haben.
LG
Eduard
Zitat von: HeikoGr am 21 November 2018, 06:16:14
Rpi Version 2.2 mit DC wandler hier:
Bei mir leuchtet keine Led beim treibertest :(
Aus familären Gründen (Aufmerksamkeitsersuchen meiner Kinder gestern Abend) habe ich die Ebus Platine noch nicht mit den ebus kabeln der therme in Verbindung bringen können.
Kann dann überhaupt etwas leuchten? Bin verwirrt.
ttyebus und ebusd sind installiert.
Beide äußeren Leds müssen bei eingebautem DC-Wandler leuchten, auch wenn nichts am eBus angeschlossen ist. Der Jumper S1 muss offen sein! Ohne DC-Wandler und ohne Bus Anschluß kann nichts leuchten, denn dann fehlt ja die Versorgungsspannung.
Und bitte unbedingt darauf achten, das die Platine richtig steckt, also Pin1 auf Pin1 des Raspi usw. Das untere Ende der Pfostenleiste muss plan mit der Raspi Steckleiste sein, somit ist das Befestigungsloch vom Raspi noch zu sehen.
LG
Reinhart
Danke für die schnelle Antwort!
LEDs sind richtig herum und der Adapter steckt auch mit pin1 auf pin1 des Raspberry.
Wie du gesehen hast, habe ich jetzt ein fertig gelöteten Adapter bestellt.
Wenn ich Zeit (mangelt gerade) und Muse habe suche ich den Fehler.
UPDATE
Lösung war ganz einfach: neben einem Lötpunkt war die grüne Isolierung beschädigt, sodass der Lötzinn einen Kurzschluss verursacht hat. War kaum zu sehen aber schnell repariert.
Die Beschädigung war sicher von mir, da ich das Board vorher visuell geprüft habe - dabei ist mir nix aufgefallen.
Wenn ich heute Abend gefahrlos und ohne von meinen zwillingstöchtern belagert zu werden an den Computer komme, poste ich noch ein Foto.
Zitat von: dkreutz am 14 November 2018, 09:25:49
Demnach dürfte das auch auf einem Pi Zero W laufen, oder? Der Zero hat die gleiche CPU wieder Pi1, nur höher getaktet. Der 40pin-GPIO ist kompatibel mit dem Pi2/3, nur der Formfaktor passt dann nicht perfekt zur RPI-Platine, was mich aber nicht stört...
Ich antworte mir mal selbst: ja, läuft auch auf einem Pi Zero W - Sendetest war erfolgreich...
@dkreutz
Danke für die Info, somit hast du auch den seriellen Treiber Problemlos installieren können!
LG
Reinhart
Es gab ein Problem beim kompilieren, das lag aber nicht an ttyebus selbst. Der RPI-Kernel (4.14.81) war aktueller als die neuesten verfügbaren raspberrypi-kernel-headers (4.14.79) - ein Downgrade (https://github.com/Hexxeh/rpi-update#Options) des Kernel hat geholfen.
Ansonsten ist der Pi Zero "identisch" zum Pi3B - also auch ein "dtoverlay=pi3-miniuart-bt" in /boot/config.txt erforderlich.
EDIT: Link zum Kernel-Downgrade eingefügt
Danke für die Info, ich werde das vorne auf hier verlinken.
Kannst du mal ein Foto posten wie das aussieht wenn die RPI drauf sitzt?
LG
Reinhart
Hier ein Bild RPI-Platine auf Pi Zero W
Zitat von: Reinhart am 21 November 2018, 19:17:29
Kannst du mal ein Foto posten wie das aussieht wenn die RPI drauf sitzt?
Produktiv testen konnte ich bisher noch nicht, aber anbei auch ein paar Bilder von mir :)
wenn der Zero auch von der Perfomance klar kommt ist es eine sehr günstige Alternative. Die nächste Größe (4x 1,4Ghz) wäre der neue PI 3A+ (https://www.reichelt.de/raspberry-pi-3-a-4x-1-4-ghz-512-mb-ram-wlan-bt-raspberry-pi-3a-p243791.html?trstct=tsr_147401&&r=1), der passt von der Größe ideal, kostet aber wieder um 10.- € mehr.
LG
Anbei zwei Fotos meiner problemplatine (rpi mit DC Wandler)
Symptome:
- Power LED und RX LED Leuchten wenn ebus nicht angeschlossen ist.
- Power LED leuchtet und RX flimmert, wenn ebus abgeschlossen ist.
- Treibertest (Echo "XYZ" > /dev/ttyebus) bringt die RX LED NICHT zum aufleuchten
- ebusctl Info sagt "No Signal"
Wie oben (anderer Post in diesem Thread) geschrieben ist beim Abstandshalter eine Lötstelle mit zerstörter Isolation. Hier hatte das Lötzinn vermutlich einen Kurzschluss verursacht. Seitdem ich das Lötzinn abgesaugt habe gehen Power und RX LEDs.
Hallo Heiko!
Im Prinzip schaut das nicht so schlecht aus. Auf der Oberseite sind einige "kalte" Lötstellen zu erkennen, d.h. dort hat sich das Zinn nicht von selbst durch das Loch gesaugt. Das ist meist Zuwenig lange erhitzt, bzw. zu wenig Lötzinn aufgetragen.
Ich würde dir empfehlen, nochmals in Ruhe auf der Oberseite das nachzulöten. D.h. zuerst mit der Lötspitze erhitzen bis das Zinn fließt und gleichzeitig etwas Lötzinn zuführen, dass sich die Löcher von selbst schließen. Speziell aufgefallen ist mir das bei: R1,R10,R7 und alle Dioden. Im Bereich von Q1 ist es am Foto durch den Winkel schwer erkennbar, könnte aber ein Kurzschluß sein.
Ansonsten sind die Symptome richtig, nur der Treibertest mit dem Sendeversuch sollte noch funktionieren. Versuche einen längeren Text zu senden, sonst ist das Aufleuchten der Led sehr kurz und man sieht es kaum. Das Leuchtsignal ist ja nur sehr schwach.
Wenn du einen groben Porstenpinsel hast (so eine Art Tuschradierer etc.), dann kannst du ja so betroffene Lötstellen wo Zinn seitlich liegt noch reinigen. Oft ist es ja nur erstarrtes Kolophonium. Die Platinen sind ja alle mit Lötstoplack beschichtet, das eigentlich ein Kurzschluß nur schwer möglich ist.
Noch Kurz ein Tipp zum löten: Die Spitze gut von oxidiertem Material (so schwarz graues Zeug) am Schwamm reinigen, mit etwas Zinn verzinnen, dann die Spitze des Lötkolben mit leichtem Druck so platzieren, dass gleichzeitig die Lötbohrung und seitlich das zu verlötende Beinchen erhitzt wird. Nun wird Lötzinn von der freien Seite des Beinchen zugeführt und das verrinnt dann bei richtig eingestellter Hitze (etwa 300-330 Grad, bei dicken Drähtchen wie die Klemme bis 350) sehr schnell und saugt sich auch durch das Loch auf die andere Seite. Das dauert maximal eine Sekunde. Du solltest kein bleifreies Zinn verwenden! Ein geübter Löter merkt die richtige Temperatur beim Löten durch sein Gefühl sofort.
PS: kannst du auch deine Konfig posten (/etc/default/ebusd)?
LG
Reinhart
Hi zusammen,
meine Schaltung ist auch da und läuft an einem Pi-Zero-W einwandfrei.
Danke nochmal an alle, die das ermöglichen! :)
Einziges Problem ist jetzt, dass der ebusd-Dienst nicht automatisch mit dem PI mitstartet, obwohl "systemctl is-enabled ebusd" enabled ausgibt - ein "sudo service ebusd start" funktioniert auch einwandfrei.
-> Hat hierzu jemand noch einen Tipp?
Danke!
Viele Grüße aus München,
Christian
Das freut uns immer wenn eine Schaltung auf Anhieb läuft.
Zu deinem Problem, schau einmal mit nachfolgendem Kommando was da im Log steht?
journalctl -u ebusd -b
Es sollte so eine ähnliche Ausgabe stehen, hier wurde automatisch gestartet.
pi@raspberrypi:~ $ journalctl -u ebusd -b
-- Logs begin at Thu 2016-11-03 18:16:43 CET, end at Sat 2018-11-24 11:34:47 CET. --
Nov 24 11:33:12 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Nov 24 11:33:14 raspberrypi ebusd[520]: Starting ebusd: ebusd.
Nov 24 11:33:14 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..
Ansonsten überprüfe ob in der /etc/systemd/ die Startdatei des Service "ebusd.service" mit folgendem Inhalt vorhanden ist:
[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network.target
ConditionPathExists=/var/log
[Service]
Type=forking
Restart=always
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS
[Install]
WantedBy=multi-user.target
LG
Reinhart
Zitat von: Reinhart am 24 November 2018, 11:44:32
Das freut uns immer wenn eine Schaltung auf Anhieb läuft.
Zu deinem Problem, schau einmal mit nachfolgendem Kommando was da im Log steht?
journalctl -u ebusd -b
Danke für die schnelle Antwort und den Tipp - da findet sich auch tatsächlich eine Fehlermeldung...
Nov 24 13:24:32 pi_eBusD ebusd[429]: Starting ebusd: ebusd2018-11-24 13:24:32.288 [main error] invalid configPath URL
... die mit "invalid configPath URL" den entscheidenden Hinweis gegeben hat:
Ich hatte ebusd neu kompiliert, aber die ebusd-configuration files nicht nach /etc/ebusd kopiert.
Das hab ich jetzt gemacht und "--configpath=/etc/ebusd/" als Argument in /etc/defaults/ebusd hinzugefügt, und siehe da, schon startet es zusammen mit dem pi-zero :)
Wenn ich recht verstehe, ging es vorher bei manuellem Start nur deswegen, weil er die Configfiles aus dem Internet gezogen hat - zum ebusd-Startzeitpunkt beim booten scheint der raspi aber noch kein Internet zu haben, daher konnte das natürlich nicht funktionieren...
Viele Grüße,
Christian
Hallo Christian!
Sehr gut wenn es jetzt klappt!
Ich liebe Logfiles wenn sie so wie bei dir auch was aussagen!
LG
Reinhart
Zitat von: Reinhart am 24 November 2018, 09:26:36
Auf der Oberseite sind einige "kalte" Lötstellen zu erkennen, d.h. dort hat sich das Zinn nicht von selbst durch das Loch gesaugt. Das ist meist Zuwenig lange erhitzt, bzw. zu wenig Lötzinn aufgetragen.
Ich würde dir empfehlen, nochmals in Ruhe auf der Oberseite das nachzulöten. D.h. zuerst mit der Lötspitze erhitzen bis das Zinn fließt und gleichzeitig
erledigt! Hat nix gebracht :-( galileo hat mir Angeboten einen Blick auf die Platine zu werfen. Ich schicke Sie am Montag zu ihm,
Zitat von: Reinhart am 24 November 2018, 09:26:36
PS: kannst du auch deine Konfig posten (/etc/default/ebusd)?
Klar:
EBUSD_OPTS="--scanconfig -d /dev/ttyebus -p 8888 --httpport=8080 --loglevel=info"
Hallo,
ich habe leider ein Problem auf meinem Raspberry Pi 3b+ ttyebus nach Anleitung zu installieren.
Nach dem Versuch mittels sudo make install zu installieren erhielt ich folgende Fehlermeldung cp ttyebus.ko /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko
depmod -a
insmod /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko
insmod: ERROR: could not insert module /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko: Invalid module format
Makefile:37: recipe for target 'install' failed
make: *** [install] Error 1
Wie kann ich das Problem beheben?
Hallo,
der EBus läuft bei mir. Nun suche ich ein transparentes Gehäuse für den RSP + EBus Platine . Könnt ihr mir eins empfehlen. Ich denke durch die LEDs auf der Platine kann man nicht jedes nehmen.
Vielen Dank
Hallo,
die Led Abstandhalter sind eigentlich so bemessen, dass die Leds durch das Gehäuse schauen und auf der Halterung aufsitzt. Auch die Höhe des DC-Wandlers passt genau und das Geäuse sitzt hier auf. Das funktioniert bei mehreren Gehäusetypen, zB: das hier (https://www.amazon.de/Vilros-Raspberry-Model-Geh%C3%A4use-transparent/dp/B00P8A66V4/ref=sr_1_4?ie=UTF8&qid=1543134843&sr=8-4&keywords=raspberry+vilros+geh%C3%A4use).
Am Besten den Deckel leicht aufsetzen, die Löcher anzeichnen und vorsichtig (zuerst mit kleinerem Bohrer) bohren. Acryl Gals bricht leicht aus, daher auf Holz auflegen und von hinten nur mit leichtem Druck bohren. Ich habe dir hier im Anhang ein Foto angehängt, wo du bei diesem Gehäuse die exakte Höhe siehst.
LG
Reinhart
Zitat von: Trainer am 24 November 2018, 23:52:33
Hallo,
ich habe leider ein Problem auf meinem Raspberry Pi 3b+ ttyebus nach Anleitung zu installieren.
Nach dem Versuch mittels sudo make install zu installieren erhielt ich folgende Fehlermeldung cp ttyebus.ko /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko
depmod -a
insmod /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko
insmod: ERROR: could not insert module /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko: Invalid module format
Makefile:37: recipe for target 'install' failed
make: *** [install] Error 1
Wie kann ich das Problem beheben?
Ich habe jetzt versucht das nachzustellen, habe mir das neueste Stretch Lite (https://www.raspberrypi.org/downloads/raspbian/) installiert, ein update durchgeführt und laut Anleitung im Wiki installiert. Da läuft alles einwandfrei. Es hat bei dir den Anschein, das bei der Kernelversion was nicht passt.
Ich habe zumindest eine neuere Version am Raspi:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
Ich bin laut Wiki so vorgegangen:
sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get install raspberrypi-kernel-headers
cd ~
git clone https://github.com/ebus/ttyebus.git
cd ~/ttyebus
make
sudo make install
lsmod
modinfo ttyebus
Beim Raspi3 musst du vorher noch die /boot/config.txt anpassen.
sudo echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txtLG
Reinhart
Zitat von: Reinhart am 25 November 2018, 11:21:19
Ich habe jetzt versucht das nachzustellen, habe mir das neueste Stretch Lite (https://www.raspberrypi.org/downloads/raspbian/) installiert, ein update durchgeführt und laut Anleitung im Wiki installiert. Da läuft alles einwandfrei. Es hat bei dir den Anschein, das bei der Kernelversion was nicht passt.
Ich habe zumindest eine neuere Version am Raspi:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
Ich bin laut Wiki so vorgegangen:sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get install raspberrypi-kernel-headers
cd ~
git clone https://github.com/ebus/ttyebus.git
cd ~/ttyebus
make
sudo make install
lsmod
modinfo ttyebus
Beim Raspi3 musst du vorher noch die /boot/config.txt anpassen.
sudo echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt
LG
Reinhart
Danke Reinhart,
Meine Kernel Version ist nach dem update noch immer auf
[11:55:15] openhabian@openHABianPi:~$ uname -a
Linux openHABianPi 4.14.72v7-aufs #1 SMP Sat Sep 29 19:45:02 CEST 2018 armv7l GNU/LinuxIch nutze Openhabian also Openhab 2. Kann es sein, dass deswegen ein Package fehlt, welches ich für die Installation brauche?
Das erste Problem tritt nach dem Befehl make auf
[12:59:28] openhabian@openHABianPi:~/ttyebus$ make
make -C /lib/modules/4.14.72v7-aufs/build M=/home/openhabian/ttyebus modules
make[1]: *** /lib/modules/4.14.72v7-aufs/build: Permission denied. Stop.
Makefile:24: recipe for target 'all' failed
make: *** [all] Error 2
mit
[12:59:33] openhabian@openHABianPi:~/ttyebus$ sudo make
make -C /lib/modules/4.14.72v7-aufs/build M=/home/openhabian/ttyebus modules
make[1]: Entering directory '/root/linux-2efa7450a8f408084d40b28cfa3fa75cf488d473'
CC [M] /home/openhabian/ttyebus/ttyebusm.o
LD [M] /home/openhabian/ttyebus/ttyebus.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/openhabian/ttyebus/ttyebus.mod.o
LD [M] /home/openhabian/ttyebus/ttyebus.ko
make[1]: Leaving directory '/root/linux-2efa7450a8f408084d40b28cfa3fa75cf488d473' läuft es soweit ohne Probleme.
Leider bleibt der Fehler weiterhin bestehen.
[13:00:19] openhabian@openHABianPi:~/ttyebus$ sudo make install
cp ttyebus.ko /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko
depmod -a
insmod /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko
insmod: ERROR: could not insert module /lib/modules/4.14.72v7-aufs/kernel/drivers/tty/serial/ttyebus.ko: Invalid module format
Makefile:37: recipe for target 'install' failed
make: *** [install] Error 1[13:12:45] openhabian@openHABianPi:~/ttyebus$ modprobe -f ttyebus.ko
modprobe: FATAL: Module ttyebus.ko not found in directory /lib/modules/4.14.72v7-aufsdmesg
[ 427.125104] ttyebus: disagrees about version of symbol module_layout
Vielleicht entsteht das Problem dadurch, da sich im Ordner /usr/src
[13:18:14] openhabian@openHABianPi:/usr/src$ ls
linux-headers-4.14.79+ linux-headers-4.14.79-v7+ linux-headers-4.9.0-6-common linux-headers-4.9.0-6-rpi linux-kbuild-4.9
nicht die selbe 4.14.72v7-aufs Version existiert. Wie kann ich die "4.14.72v7-aufs" Version in den /usr/src Ordner einbinden?
[13:18:03] openhabian@openHABianPi:/lib/modules$ ls
4.14.72v7-aufs 4.14.79+ 4.14.79-v7+ 4.9.0-6-rpi
genau das Problem (/usr/src) hatte ich ganz am Anfang einmal, das war aber noch während der Entwicklung des ttyebus von galileo bei einem Test.
Ich hatte damals durch händisches anlegen und kopieren das lauffähig bekommen. Wie ich genau vorgegangen bin, weiß ich aber leider nicht mehr genau. Ich habe auf jeden Fall aus dem existierenden Verzeichnis alles "ttyebus" in das nicht vorhandene kopiert und dann mit "make install" nochmals installiert.
Zitat von: Reinhart am 25 November 2018, 17:52:27
genau das Problem (/usr/src) hatte ich ganz am Anfang einmal, das war aber noch während der Entwicklung des ttyebus von galileo bei einem Test.
Ich hatte damals durch händisches anlegen und kopieren das lauffähig bekommen. Wie ich genau vorgegangen bin, weiß ich aber leider nicht mehr genau. Ich habe auf jeden Fall aus dem existierenden Verzeichnis alles "ttyebus" in das nicht vorhandene kopiert und dann mit "make install" nochmals installiert.
welches existierende Verzeichnis meinst du ?
Ich finde in den vorhanden Verzeichniessen kein "ttyebus" file oder Ordner.
Des weiteren ist mir aufgefallen, dass im Verzeichnis "\boot" nur ein "config-4.9.0-6-rpi" existiert, aber nicht von meiner zuletzt installieren Version "4.14.72v7-aufs".
bei einem Raspberry sieht die Installation mit "install so aus"
pi@raspberrypi:~/ttyebus $ sudo make install
cp ttyebus.ko /lib/modules/4.14.79+/kernel/drivers/tty/serial/ttyebus.ko
depmod -a
insmod /lib/modules/4.14.79+/kernel/drivers/tty/serial/ttyebus.ko
sed -i "s/ttyebus//g" /etc/modules
echo "ttyebus" >> /etc/modules
wenn du dir nun das Makefile vom ttyebus anschaust, dann wird ja da als erstes nur kopiert.
TARGET_MODULE:=ttyebus
TARGET_DIR:=/lib/modules/$(shell uname -r)/kernel/drivers/tty/serial
Als Pfad wird hier "uname -r" genommen und wenn du den Pfad auf dein existierendes "drivers Verzeichnis" absolut legst sollte die Installation auch klappen. Bei meinem Raspi nennt sich das Verzeichnis
/lib/modules/4.14.79+/kernel/drivers/tty/serial
Bei dir befinden sich vermutlich im uname -r Verzeichnis keine Treiber, also einfach nachschauen wo die wirklich liegen und dann den Pfad anstatt uname -r eingeben.
LG
Hi, wie in dem anderen Thread beschrieben(https://forum.fhem.de/index.php/topic,29737.msg864401.html#msg864401 (https://forum.fhem.de/index.php/topic,29737.msg864401.html#msg864401)), dtartet mein Ebus nicht im Autostart.
Ich habe ein Rpi 3 B+ mit Stretch.
Zitat
Zu deinem Problem, schau einmal mit nachfolgendem Kommando was da im Log steht?
Code: [Auswählen]
journalctl -u ebusd -b
liefert:
pi@raspberrypi:~ $ journalctl -u ebusd -b
-- Logs begin at Thu 2016-11-03 17:16:42 GMT, end at Tue 2018-11-27 07:59:20 GMT. --
Nov 27 07:58:42 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Nov 27 07:58:42 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
die Datei "service.ebusd" in /etc/systemd/ ist nicht vorhanden. Ich habe diese mit dem folgenden Inhalt angelegt.
[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network.target
ConditionPathExists=/var/log
[Service]
Type=forking
Restart=always
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS
[Install]
WantedBy=multi-user.target
Das ganze neugestartet, jedoch ohne Erfolg
Hi,
habe keine Ahnung, aber ist das Minus Im EnvironmentFile richtig?
-/etc/... -> /etc/...
Gruß Arnd
Gesendet von iPhone mit Tapatalk
ah, jetzt ist mir das klar, du hast den Service nicht eingetragen!
Steht hier in Johns Wiki (https://github.com/john30/ebusd/wiki/1.-Build-and-install).
aus dem Home Verzeichnis ( /home/pi/ebusd ) ausführen!
sudo cp contrib/debian/default/ebusd /etc/default/
sudo cp contrib/debian/systemd/ebusd.service /etc/systemd/system/
sudo systemctl enable ebusd
sudo service ebusd start
LG
Reinhart
Richtig, das habe ich nicht gemacht. War der Meinung das ich das bei Jessie auch nicht machen musste, hatte es auch meine ich irgendwo gelesen, dass das automatisch geht.
Im fhem ebus wiki ist der Eintrag dann auch unvollständig. Wer kann das ergänzen?
Leider geht es immernoch nicht.
Ich habe die Datei (ebusd.service) manuell in das Verzeichnis kopiert.
und dann noch die folgenden Zeilen ausgeführt
sudo systemctl enable ebusd
sudo service ebusd start
Nach einem Neustart erhalte ich jedoch:
pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/systemd/system/ebusd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2018-11-27 12:30:43 GMT; 1min 14s ago
Process: 451 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=22)
Nov 27 12:30:43 raspberrypi systemd[1]: ebusd.service: Unit entered failed state.
Nov 27 12:30:43 raspberrypi systemd[1]: ebusd.service: Failed with result 'exit-code'.
Nov 27 12:30:43 raspberrypi systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Nov 27 12:30:43 raspberrypi systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Nov 27 12:30:43 raspberrypi systemd[1]: ebusd.service: Start request repeated too quickly.
Nov 27 12:30:43 raspberrypi systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Nov 27 12:30:43 raspberrypi systemd[1]: ebusd.service: Unit entered failed state.
Nov 27 12:30:43 raspberrypi systemd[1]: ebusd.service: Failed with result 'exit-code'.
Das File hat volle Zugriffsrechte 0777
MfG Matthias
So, Fehler selbst gefunden :D.
Ich habe folgende Config gehabt:
EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=ff --loglevel=error"
Hier musste ich wohl den configpath angeben, wie hioer beschrieben:
https://forum.fhem.de/index.php?topic=29737.2730 (https://forum.fhem.de/index.php?topic=29737.2730)
Config umbenannt in :
EBUSD_OPTS="--configpath=/etc/ebusd -d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=ff --loglevel=error"
, und siehe da, es startet nach dem neustart.
Aber warum ist die Frage, das ist doch der Standartpfad?
Ich habe spaßenshalber den Service nochmal aus dem Verzeichnis geschmissen, und neu gestartet und nun startet ebus auch von alleine.
Dann war das nur der fehlende configpath, der im alten Rpi (Jessie) mit angegeben war und im neuen nicht mehr.
MfG Matthias
Moin,
ich verzweifel ich ein bisschen mit dem Messplan. Meine gemessenen Spannungen am RPI Adapter liegen konstant über den angegebenen.
JP5: 5,44V
JP6: 7,47V
Was habe ich wohl falsch gemacht?
Hallo DietmarD!
Du kannst da nicht viel falsch gemacht haben, JP5 ist die Spannung nach dem 5V Regler und JP6 die Spannung am Collector des Q1, wenn der durchschaltet zieht er ja über die Zenerdiode gegen Masse. Hast du den bei der Messung auch die Leds in Betrieb, den sonst wird der Ausgang vom Spannungsregler recht hochohmig und da kann die Spannung schon höher sein. Die angebenden Spannungen im Messplan sind ja nur Werte zur Orientierung da die je nach Streuung der Komponenten und der verwendeten Messgeräte (Analog, Digital) ja geringfügig abweichen können.
Hast du den Probleme mit dem Adapter, weil du die Spannungen misst? Galileo hat jetzt an die 40 Platinen gelötet und die haben alle auf Anhieb funktioniert. Das ist ja das Schöne an der Schaltung, du brauchst nichts einstellen! Wichtig ist die Polung und wer darauf achtet da wird auch die Platine funktionieren.
Was machen den die Leds wenn der eBus angeschlossen ist? Keine Angst, der eBus ist kurzschlussfest, es kann da nicht viel passieren. Die Leds geben dann mehr Aussage ob RxD verstanden wird oder nicht.
Zur Messung greife ich erst wenn die Leds nicht leuchten!
LG
Zitat von: Reinhart am 26 November 2018, 16:05:24
bei einem Raspberry sieht die Installation mit "install so aus"
pi@raspberrypi:~/ttyebus $ sudo make install
cp ttyebus.ko /lib/modules/4.14.79+/kernel/drivers/tty/serial/ttyebus.ko
depmod -a
insmod /lib/modules/4.14.79+/kernel/drivers/tty/serial/ttyebus.ko
sed -i "s/ttyebus//g" /etc/modules
echo "ttyebus" >> /etc/modules
wenn du dir nun das Makefile vom ttyebus anschaust, dann wird ja da als erstes nur kopiert.
TARGET_MODULE:=ttyebus
TARGET_DIR:=/lib/modules/$(shell uname -r)/kernel/drivers/tty/serial
Als Pfad wird hier "uname -r" genommen und wenn du den Pfad auf dein existierendes "drivers Verzeichnis" absolut legst sollte die Installation auch klappen. Bei meinem Raspi nennt sich das Verzeichnis
/lib/modules/4.14.79+/kernel/drivers/tty/serial
Bei dir befinden sich vermutlich im uname -r Verzeichnis keine Treiber, also einfach nachschauen wo die wirklich liegen und dann den Pfad anstatt uname -r eingeben.
LG
Danke für den Tipp.
Leider erhalte ich den selben Fehler.
Versuche ich nur den
insmod Befehl auszuführen erhalte ich
[16:59:32] openhabian@openHABianPi:~/ttyebus$ sudo insmod ttyebus.ko
insmod: ERROR: could not insert module ttyebus.ko: Invalid module format
ACHTUNG, kein bleifreies Lot verwenden!
Ein Anwender hat sich einen Lötkolben gekauft und da war bleifreies Lot beigelegt! Der Bausatz wurde damit zusammen gelötet und hat nicht funktioniert. Galileo hat jetzt diese Platine untersucht und festgestellt das eigentlich sauber gelötet wurde, aber die Lötstellen alle komisch grau waren (weil nicht unter Stickstoff gelötet wurde).
Ein nachverzinnen mit verbleitem Lot ist nicht gefahrlos möglich (Ablösung der Pins und Leiterbahnen) und funktioniert auch nur schwer.
Unsere Platinen sind nur für verbleites Lot geeignet, da sie auch vom Hersteller schon verbleit vorverzinnt wurden.
Infoblatt bleifrei / verbleites Lot von ELV (https://files.elv.com/service/manuals_hw/63088_bleifreies_Loete_Infosheet.pdf)
Bitte beachten, so was ist so wie hier schnell passiert!
LG
Reinhart
Zitat von: Reinhart am 28 November 2018, 10:32:07
Hallo DietmarD!
Du kannst da nicht viel falsch gemacht haben, JP5 ist die Spannung nach dem 5V Regler und JP6 die Spannung am Collector des Q1, wenn der durchschaltet zieht er ja über die Zenerdiode gegen Masse. Hast du den bei der Messung auch die Leds in Betrieb, den sonst wird der Ausgang vom Spannungsregler recht hochohmig und da kann die Spannung schon höher sein. Die angebenden Spannungen im Messplan sind ja nur Werte zur Orientierung da die je nach Streuung der Komponenten und der verwendeten Messgeräte (Analog, Digital) ja geringfügig abweichen können.
Hast du den Probleme mit dem Adapter, weil du die Spannungen misst? Galileo hat jetzt an die 40 Platinen gelötet und die haben alle auf Anhieb funktioniert. Das ist ja das Schöne an der Schaltung, du brauchst nichts einstellen! Wichtig ist die Polung und wer darauf achtet da wird auch die Platine funktionieren.
Was machen den die Leds wenn der eBus angeschlossen ist? Keine Angst, der eBus ist kurzschlussfest, es kann da nicht viel passieren. Die Leds geben dann mehr Aussage ob RxD verstanden wird oder nicht.
Zur Messung greife ich erst wenn die Leds nicht leuchten!
LG
Haha, alles klar. Also erstmal vorweg, ich bin schon geübter Löter und mach sowas schon ein paar Jahre. Ich wollte lieber die Platine im Vorausprüfen, weil ich zur Miete wohne und die Gastherme hier natürlich nicht mir gehört. Darum wollte ich vorneweg so viel wie möglich testen um mögliche Schäden an der Therme zu vermeiden. Aber wenn du sagst, dann der eBus kurzschlussfest ist, dann werd ichs am Wochenende mal dran klemmen. Vorher schaffs ich leider momentan beruflich nicht. Melde mich dann nochmal.
Hello,
my plan was to implement my Wolf oil heating with ebus to Openhab 2.3
I ordered an Ebus Adapterboard (v 2.2 ) here, connected it to my Raspberry and fail now to start the ebus binding in openhab. My log file always show only:
2018-12-03 22:24:46.074 [ERROR] [ernal.connection.EBusSerialConnector] - Unable to connect to serial port /dev/ttyebus
2018-12-03 22:24:46.079 [WARN ] [nal.connection.AbstractEBusConnector] - Unable to connect to eBus, retry in 5 seconds ...
2018-12-03 22:24:51.085 [ERROR] [ernal.connection.EBusSerialConnector] - Unable to connect to serial port /dev/ttyebus
2018-12-03 22:24:51.089 [WARN ] [nal.connection.AbstractEBusConnector] - Unable to connect to eBus, retry in 5 seconds ...
My ebus.cfg shows:
# Serial port of eBUS interface
# Valid values are e.g. COM1 for Windows and /dev/ttyS0 or /dev/ttyUSB0 for Linux
serialPort=/dev/ttyebus
ls -l /dev shows:
crw--w---- 1 root tty 4, 8 Dez 3 22:07 tty8
crw--w---- 1 root tty 4, 9 Dez 3 22:07 tty9
crw-rw---- 1 root dialout 204, 64 Dez 3 22:07 ttyAMA0
crw-rw-rw- 1 root root 10, 58 Dez 3 22:07 ttyebus
crw------- 1 root root 5, 3 Dez 3 22:07 ttyprintk
I am lost now and need the help from community. I hope somebody can support me.
On the adapter board the yellow and green LED is on, which is expected behavior.
The wired connection from Adapter Board to the Wolf heating is not done yet.
I read that the ttyAMA0 must be removed by disabling the serial port in rasp-config. I have openhabian-config, but when I disable the ports (30-35) the ttyAMA0 does not disappear. Maybe this is related to my problem? Please help
Many thanks for support!
Thomas
Platform information:
Hardware: Raspberry 2 Model B
OS: Openhabian
openHAB version: 2.3.0.
@Theisy
The interface AMA0 still occupies the interrupt. You must necessarily disable the AMA0, this occupies the internal serial port. (See first post here). I do not know Openhab, but it must also be possible to do so here.
LG
Hi
Is the package "ebusd-3.2_armhf-jessie_mqtt1.deb" Ok for a rasbian strech ?
Thanks
Erstmal danke an Reinhart! Das Board kam heute an. Direkt in Betrieb genommen! :)
Vorher habe ich schon ttyebus auf dem RPi erstellt. ttyAM0 ist nicht mehr da.
Soweit so gut.
Meine Wolf CGB(-K)-20 habe direkt an den eBus auf der Platine angeschlossen.
Ist die Heizung aus (also Kabel nicht angeschlossen) sind die äußeren LEDs an.
Mit echo "das ist ein Sendetest" >/dev/ttyebus blinkt dann auch die mittlere rote LED.
Scheint also zu funktionieren.
ebus zum Testen mit ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyebus gestartet.
Im Log steht aber nur:
...
2018-12-05 19:47:54.463 [bus notice] signal acquired
2018-12-05 19:47:56.041 [bus error] signal lost
2018-12-05 19:48:19.479 [bus notice] <77
2018-12-05 19:48:19.479 [bus notice] signal acquired
2018-12-05 19:48:21.006 [bus error] signal lost
2018-12-05 19:48:44.505 [bus notice] <77
2018-12-05 19:48:44.505 [bus notice] signal acquired
2018-12-05 19:48:46.032 [bus error] signal lost
2018-12-05 19:49:09.522 [bus notice] <77
2018-12-05 19:49:09.523 [bus notice] signal acquired
2018-12-05 19:49:11.050 [bus error] signal lost
...
Das gleiche hatte ich auch mit der 1.6 Platine. Ich dachte ich bin zu doof den Poti einzustellen. Habe dann die V2 gefunden. Geil muss ich den kack Poti nicht einstellen. :D
Ich glaube ich bin zu doof, übersehe etwas oder irgendwas stimmt nicht.
Kann mir jemand helfen?
Zitat von: diam35 am 05 Dezember 2018, 13:06:37
Hi
Is the package "ebusd-3.2_armhf-jessie_mqtt1.deb" Ok for a rasbian strech ?
Thanks
Yes, its running on stretch!
LG
@copystring
starte doch einmal ebusd als Service und schaue ins Log was dann kommt.
LG
@Reinhart
Ui. Ja da kommt was.
2018-12-05 20:34:26.112 [bus notice] new master 03, master count 2
2018-12-05 20:34:26.113 [update notice] unknown BC cmd: 03fe05030801004000683528d8
2018-12-05 20:34:34.904 [main error] unable to load scan config 08: list files in /etc/ebusd/kromschroeder ERR: element not found
2018-12-05 20:34:57.057 [update notice] unknown BC cmd: 03fe05030801004000643328d8
Habe eben auch noch zusätzlich das eBus Display von der Heizung wieder angeschlossen. Kann es daran gelegen haben?
kann ich jetzt nicht sagen, probiere es aus.
Aber die Config Files in /etc/ebusd/kromschroeder werden nicht gefunden.
LG
Naja gut. So komme ich erstmal weiter. Vielen dank für deine Hilfe. Ich weiß das sehr zu schätzen und finde das nicht selbstverständlich!
Ich helfe gerne wenn ich kann, ich kenne aber die Kromschroeder nicht und deshalb ist meine Hilfe nur eingeschränkt.
LG
Ich bins nochmal.
Die Anbindung an FHEM klappt. Den Fehler mit Kromschröder habe ich behoben. Alles gut.
Ich glaube ich brauche aber nich weitere Dateien, welche sich nicht im github von john30 befinden.
Wenn ich das richtig verstehe, zeigt das Log daher die "unknown BC" und "unknown MM" an. Kann das ein?
Dann müsste ich selbst herausfinden für was die cmd stehen und eine passende CSV erstellen?
2018-12-05 22:18:09.837 [bus notice] new master f1, master count 2
2018-12-05 22:18:09.837 [update notice] unknown BC cmd: f1fe080008000000f580600000
2018-12-05 22:18:11.129 [bus notice] new master 03, master count 3
2018-12-05 22:18:11.139 [update notice] unknown MM cmd: 03f1080008003500d880000034
2018-12-05 22:18:13.641 [bus notice] new master 10, master count 4
2018-12-05 22:18:13.654 [update notice] unknown MM cmd: 1003050709bb0450030080ff68ff
2018-12-05 22:18:18.642 [update notice] unknown MM cmd: 1003080008003500f500130034
2018-12-05 22:18:19.682 [main notice] read common config file /etc/ebusd/kromschroeder/broadcast.csv
2018-12-05 22:18:19.683 [main notice] read scan config file /etc/ebusd/kromschroeder/08.csv for ID "3b", SW0777, HW5130
2018-12-05 22:18:19.684 [main notice] found messages: 17 (0 conditional on 0 conditions, 0 poll, 8 update)
2018-12-05 22:18:19.879 [update notice] update broadcast sollw QQ=f1: 0.000;-11.000;-;60;0.000
2018-12-05 22:18:21.813 [main error] unable to load scan config 15: no file from /etc/ebusd/kromschroeder with prefix 15. found
2018-12-05 22:18:23.647 [update notice] update feuerung betrd QQ=10: Brauchwasser_Heizen;Verbraucheran;53.00;-;-;52.0;-
2018-12-05 22:18:23.918 [main error] unable to load scan config f6: no file from /etc/ebusd/kromschroeder with prefix f6. found
Zitat von: Trainer am 25 November 2018, 13:01:40
hi
did you solve your problem ?
if not try this :
get UART to the GPIO
$ sudo echo dtoverlay=pi3-miniuart-bt | sudo tee -a /boot/config.txt
only if $ uname -r return 4.14.79-v7+
wget https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel-headers_1.20181112-1_armhf.deb
sudo dpkg -i raspberrypi-kernel-headers_1.20181112-1_armhf.debthis code will install raspberrypi-kernel-headers 4.14.79-v7+.
if not solve you can also try Reverting back to current stock Raspbian kernel
sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel
do not any update
then
git clone https://github.com/ebus/ttyebus.git
cd ~/ttyebus
make
sudo make install
lsmod
modinfo ttyebus
Hallo,
ich habe nach einer Woche Postlaufzeit von A nach D den fertig gelöteten Rpi Ebus Adapter von Reinhart wohlbehalten bekommen. Die Hardware hat mit meinem alten Raspberry Typ 1 auf Anhieb funktioniert. Ich habe dann einige Stunden mit der Konfiguration von ebusd verbracht und schließlich mit Telnet meine ersten Live-Werte von der Vaillant VWS 101/2 ausgelesen !
Ich wollte mich bei Euch für dieses tolle Projekt bedanken. Die Platine sitzt auf dem Raspi super professionell und ist wirklich noob-sicher und super elegant konzipiert !
Ich komme sicher als ebus Anfänger bald mal an meine Grenzen und melde mich wieder !
Viele Grüße
Daniel
Moin Gemeinde,
habe gesehen, dass mein Rpi seit gestern in der Post ist. Vielen Dank @Reinhart :D
Damit mir in der Zwischenzeit nicht langweilig wird, habe ich schon mal diesen Thread oberflächlich durchgelesen.
Bisher habe ich aber noch nichts zum dem Thema "Vaillant VR70 über dessen Diagnosebuchse an Rpi anschliessen" gefunden. Bisher weiss ich, dass die Diagnosebuchse eine RJ10 Buchse ist. Die Beschaltung habe ich aber bisher nicht ermitteln können.
Daher meine erste Frage: Kennt jemand die Details zu dieser Buchse???
Zweite Frage: Bevor ich jetzt in dem unglaublich umfangreichen Material zur Heizungssteuerung weiter herumstochere, würde ich gerne wissen, wo ich als blutiger Anfänger zuerst anfangen sollte.
Ich dachte mir, dass ich schon mal die eBus-Software auf einen hier derzeit unnütz herumliegenden Raspi 2 aufbringen und so weit als möglich testen könnte, bis der Rpi zu mir gefunden hat. Was halten die Experten davon?
Grüße vom Südrand des Nordmeeres
Det :)
Ja genau, die Treiberinstallation ist schon die erste Sache.
Zum Diagnoseanschluß, ich glaube das ist der alte serielle Diagnosestecker (RS232) für den Fachhandwerker.
LG
Reinhart
@Reinhart:
Vielen Dank, das hilft mir schon ein wenig weiter.
Dennoch: Gibt es niemand, der sich mit der Vaillant VR 70 Hardware auskennt???
Grüße von der kalten Küste
Det :)
Moin Reinhart,
heute Vormittag kam die RPi-Platine mit der Post bei mir an. Vielen Dank für die schnelle Lieferung und die prima Arbeit, auch an die anderen Beteiligten des Projektes. :D :D :D :D :D
Ich hatte in den vergangenen Tagen schon Raspbian Lite, ttye und eBusd gemäß Anleitung von John30 auf Github auf einem Raspberry 2 installiert.
So konnte ich heute die Platine gleich auf den Pi stecken und anheizen.
Ergebnisse:
- Die gelbe und die grüne LED leuchten kontinuierlich, die rote blitzt beim Sendeversuch (pi@raspberrypi:~ $ echo "Dies ist ein Sendetest" >/dev/ttyebus) kurz auf.
- "pi@raspberrypi:/ebusd $ sudo ./src/ebusd/ebusd --help" funktioniert ebenfalls
- "pi@raspberrypi:/ebusd $ ps -ax | grep ebus" ergibt bei mir:
3041 pts/0 S+ 0:00 grep --color=auto ebus - "pi@raspberrypi:/ebusd $ ebusd -V" ergibt:
ebusd 3.2.v3.2-23-g768bd5c - Beim vorangehenden "sudo make install" erhalte ich folgenden Output:
pi@raspberrypi:/ebusd $ make install
Making install in docs
make[1]: Entering directory '/ebusd/docs'
make[2]: Entering directory '/ebusd/docs'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/ebusd/docs'
make[1]: Leaving directory '/ebusd/docs'
Making install in src/lib/utils
make[1]: Entering directory '/ebusd/src/lib/utils'
make[2]: Entering directory '/ebusd/src/lib/utils'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/ebusd/src/lib/utils'
make[1]: Leaving directory '/ebusd/src/lib/utils'
Making install in src/lib/ebus
make[1]: Entering directory '/ebusd/src/lib/ebus'
Making install in contrib
make[2]: Entering directory '/ebusd/src/lib/ebus/contrib'
make[3]: Entering directory '/ebusd/src/lib/ebus/contrib'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/ebusd/src/lib/ebus/contrib'
make[2]: Leaving directory '/ebusd/src/lib/ebus/contrib'
make[2]: Entering directory '/ebusd/src/lib/ebus'
make[3]: Entering directory '/ebusd/src/lib/ebus'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/ebusd/src/lib/ebus'
make[2]: Leaving directory '/ebusd/src/lib/ebus'
make[1]: Leaving directory '/ebusd/src/lib/ebus'
Making install in src/ebusd
make[1]: Entering directory '/ebusd/src/ebusd'
make[2]: Entering directory '/ebusd/src/ebusd'
/bin/mkdir -p '/usr/bin'
/usr/bin/install -c ebusd '/usr/bin'
/usr/bin/install: cannot remove '/usr/bin/ebusd': Permission denied
Makefile:327: recipe for target 'install-binPROGRAMS' failed
make[2]: *** [install-binPROGRAMS] Error 1
make[2]: Leaving directory '/ebusd/src/ebusd'
Makefile:497: recipe for target 'install-am' failed
make[1]: *** [install-am] Error 2
make[1]: Leaving directory '/ebusd/src/ebusd'
Makefile:376: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1Da ich mich recht strikt an die Anleitung von John30 gehalten habe und leider kaum Linux-Kenntnisse habe, komme ich hier nicht mehr weiter. Mir kommen die "Nothing to be done for..." Meldungen etwas spanisch vor; ich kann mir noch keinen Reim darauf machen.
Kann mir jemand weiterhelfen?
So, und jetzt hole ich mir von Reichelt erstmal Modularkabel mit RJ10-Steckern, damit ich meine Vaillant-Heizung möglichst bald belauschen kann. 8)
Grüße von der Nordsee
Det :)
Zitat von: Schlauer Det am 19 Dezember 2018, 15:27:51
Beim vorangehenden "sudo make install" erhalte ich folgenden Output:
Du hast dann aber doch das "sudo" vorne dran vergessen. Ohne das darf der User "pi" nicht /usr/bin/ebusd ersetzen.
Zitat von: john30 am 19 Dezember 2018, 15:54:25
Du hast dann aber doch das "sudo" vorne dran vergessen. Ohne das darf der User "pi" nicht /usr/bin/ebusd ersetzen.
@john30:
Ja, vielen Dank, Du hast recht. :(
Auch mit dem "sudo..." läuft das make install zwar ohne für mich ersichtliche Fehler durch, ich kann jedoch kein "/var/log/ebusd.log" finden.
Das lässt mich vermuten, dass irgendetwas noch nicht stimmt.
Wo finde ich Hinweise darauf, was, wo und wann etwas schiefgelaufen sein könnte?
Grüße aus dem hohen Norden
Det :)
wenn der Dämon läuft (siehst du mit ps ax|grep ebusd) dann schau doch einmal die config an ob hier das Log richtig definiert wurde ( /etc/default/ebusd ). Die Config musst du schon selber definieren!
LG
Zitat von: Reinhart am 19 Dezember 2018, 19:28:44
wenn der Dämon läuft (siehst du mit ps ax|grep ebusd) dann schau doch einmal die config an ob hier das Log richtig definiert wurde ( /etc/default/ebusd ). Die Config musst du schon selber definieren!
LG
Verzeihe bitte einem totalen Linux-NOOB :( :P
Weiter oben hatte ich ja schon beschrieben, was ich als Ergebnis von "ps ax..." erhalten hatte:
Ich hatte in den vergangenen Tagen schon Raspbian Lite, ttye und eBusd gemäß Anleitung von John30 auf Github auf einem Raspberry 2 installiert.
So konnte ich heute die Platine gleich auf den Pi stecken und anheizen.
Ergebnisse:
"pi@raspberrypi:/ebusd $ ps -ax | grep ebus" ergibt bei mir:
3041 pts/0 S+ 0:00 grep --color=auto ebus
Was das aber bedeutet ist mir nicht klar.
Zudem weiss ich nicht, um welche config es geht und wie die zu definieren ist.
Mittlerweile glaube ich, dass ich die Hunderte von Seiten aus den drei wesentlichen Threads noch mal durchackern muss. ::)
Kann mir jemand bitte nochmal ein wenig mehr Starthilfe geben?
Von weit im Norden
Det :)
Zitat von: Schlauer Det am 19 Dezember 2018, 19:54:49
Zudem weiss ich nicht, um welche config es geht und wie die zu definieren ist.
die config ist in /etc/default/ebusd. Dort musst Du mindestens noch das device eintragen, auf dem der Adapter zu finden ist. Das reicht normalerweise bereits, da das Logfile per default als daemon schon auf /var/log/ebusd.log steht.
Nach dem install mit "sudo make install" läuft der Dienst ja noch nicht, also musst Du den nataürlich noch starten.
Das geht je nach Betriebssystem bspw. mit "systemctl start ebusd" oder "service ebusd start". Danach kannst dann mit "ps aux|grep ebusd" sehen, ob der Prozess jetzt läuft und dann sollte auch das Logfile etwas enthalten.
Aber: bitte erwarte nicht von uns, dass wir dir hier sämtliche Linux Grundlagen beibringen. Da musst du dich schon selbst ein wenig mit beschäftigen!
Zitat von: john30 am 20 Dezember 2018, 08:15:26
die config ist in /etc/default/ebusd. Dort musst Du mindestens noch das device eintragen, auf dem der Adapter zu finden ist. Das reicht normalerweise bereits, da das Logfile per default als daemon schon auf /var/log/ebusd.log steht.
Bei mir findet sich kein Logfile!
Zitat
Nach dem install mit "sudo make install" läuft der Dienst ja noch nicht, also musst Du den nataürlich noch starten.
Das geht je nach Betriebssystem bspw. mit "systemctl start ebusd" oder "service ebusd start".
Das hatte ich getan.
[/quote]
ZitatDanach kannst dann mit C sehen, ob der Prozess jetzt läuft und dann sollte auch das Logfile etwas enthalten.
Den Output von "ps ...." hatte ich ja bereits in meiner vorigen Antwort dargestellt. Darauf kann ich mir aber keinen Reim machen. Und in /var/log finde ich keine Datei ebusd.log.
[/quote]
Zitat
Aber: bitte erwarte nicht von uns, dass wir dir hier sämtliche Linux Grundlagen beibringen. Da musst du dich schon selbst ein wenig mit beschäftigen!
Mein vollstes Verständnis, bin ich auch schon dran. Aber das hilft mir noch nicht wirklich weiter.
Um Integrationsfehler auszuschliessen, habe ich heute Vormittag nochmal ein neues Stretch Lite geschrieben und den ganzen Installations lauf von ttye und eBusd lat den Wikis durchgeführt.
Ergebnis: Kein Fortschritt. :( :( :(
Grüße von der Küste
Det :)
schau doch einfach einmal auf den Status:
sudo service ebusd status
und wenn der Dämon nicht läuft, dann starte ihn:
sudo service ebusd start
und dann schaue wieder ob sich der Status geändert hat. Erst wenn der Dämon läuft, wird auch das Logfile angelegt!
LG
Zitat von: Schlauer Det am 20 Dezember 2018, 14:23:51
Um Integrationsfehler auszuschliessen, habe ich heute Vormittag nochmal ein neues Stretch Lite geschrieben und .....
Sorry, aber den muss ich aufgreifen!
Warum bewirbst Du Dich nicht bei Linus Torvald?
Duck und weg
Zitat von: pc1246 am 20 Dezember 2018, 17:56:03
Sorry, aber den muss ich aufgreifen!
Warum bewirbst Du Dich nicht bei Linus Torvald?
Duck und weg
Jau, das wär's doch. ;D Vielleicht könnte ich dem dann zeigen, wie's geht??? ;) ;) ;)
Gemeint hatte ich: "... habe ich heute Vormittag nochmal ein neues Stretch Lite auf eine SD-Karte geschrieben..." ??? Das kann ich schon, bin ja schon groß.
Jedenfalls brauchst Du Dich mit solchen Äußerungen weder zu ducken noch wegzurennen; meist habe ich viel Humor ;D ;D ;D
Grüße von der Waterkant
Det :)
Zitat von: Reinhart am 20 Dezember 2018, 17:19:49
schau doch einfach einmal auf den Status:
sudo service ebusd status
und wenn der Dämon nicht läuft, dann starte ihn:
sudo service ebusd start
und dann schaue wieder ob sich der Status geändert hat. Erst wenn der Dämon läuft, wird auch das Logfile angelegt!
LG
N'Abend, Reinhart
Danke für Deine Reaktion. Ich habe Deinen Vorschlag befolgt und erhalte:
pi@raspberrypi:~ $ sudo service ebusd status
? ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated; vendor preset: enabled)
Active: active (exited) since Thu 2018-12-20 13:17:08 GMT; 3h 55min ago
Docs: man:systemd-sysv-generator(8)
Process: 436 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ebusd.service
Dec 20 13:17:08 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Dec 20 13:17:08 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $ sudo service ebusd start
pi@raspberrypi:~ $ sudo service ebusd status
? ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated; vendor preset: enabled)
Active: active (exited) since Thu 2018-12-20 13:17:08 GMT; 3h 56min ago
Docs: man:systemd-sysv-generator(8)
Process: 436 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ebusd.serviceIst wohl noch nicht das Gelbe vom Ei. :(
Daraufhin habe ich wieder das Literaturstudium aufgenommen und fand in diesem Thread einen Hinweis von Christian in Antwort #74.
Ich habe dann mal probehalber die Datei "/home/pi/ebusd/configure" nach "/etc/ebusd" kopiert, "--configpath=/etc/ebusd/" als Argument in /etc/defaults/ebusd hinzugefügt und neu gebootet.
Dann erhielt ich Folgendes:
pi@raspberrypi:~ $ sudo journalctl -u ebusd -b
-- Logs begin at Thu 2016-11-03 17:16:42 GMT, end at Thu 2018-12-20 18:55:19 GMT
Dec 20 18:45:21 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon
Dec 20 18:45:21 raspberrypi ebusd[440]: ebusd: WARNING: you should use --build,
Dec 20 18:45:21 raspberrypi ebusd[440]: ebusd: error: cannot find sources (src/e
Dec 20 18:45:21 raspberrypi systemd[1]: ebusd.service: Control process exited, c
Dec 20 18:45:21 raspberrypi systemd[1]: Failed to start LSB: controls ebusd, the
Dec 20 18:45:21 raspberrypi systemd[1]: ebusd.service: Unit entered failed state
Dec 20 18:45:21 raspberrypi systemd[1]: ebusd.service: Failed with result 'exit-
lines 1-8/8 (END)
-- Logs begin at Thu 2016-11-03 17:16:42 GMT, end at Thu 2018-12-20 18:55:19 GMT. --
Dec 20 18:45:21 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating syst
Dec 20 18:45:21 raspberrypi ebusd[440]: ebusd: WARNING: you should use --build, --host, --target
Dec 20 18:45:21 raspberrypi ebusd[440]: ebusd: error: cannot find sources (src/ebusd/main.cpp) in /etc/init.d or ..
Dec 20 18:45:21 raspberrypi systemd[1]: ebusd.service: Control process exited, code=exited status=1
Dec 20 18:45:21 raspberrypi systemd[1]: Failed to start LSB: controls ebusd, the daemon for communication with eBUS heati
Dec 20 18:45:21 raspberrypi systemd[1]: ebusd.service: Unit entered failed state.
Dec 20 18:45:21 raspberrypi systemd[1]: ebusd.service: Failed with result 'exit-code'.
~
~
~
~
~Könnte es sein, dass ich den gleichen Fehler gemacht habe wie Christian???
Was könnte die Ursache sein, denn ich habe nicht neu kompiliert???
Grüße aus dem Norden
Det :)
ich habe jetzt selber keine Ahnung was du alles wo kopiert hast, aber da stimmt einiges nicht.
ebusd: error: cannot find sources (src/ebusd/main.cpp) in /etc/init.d or ..
Ich würde dir vorschlagen, einfach ein fertiges "deb" File von Johns Git zu laden oder einfach nochmals alles genau nach Wiki zu kompilieren. Die Verzeichnisse werden ja durch die Installation automatisch alle richtig angelegt. Wenn du dich in Linux gut auskennst ist es kein Problem das jetzt hinzubiegen, aber sonst machen wir hier noch lange so weiter.
Ach ja noch was, was früher unter bestimmten Umständen notwendig war, ist jetzt schon lange durch John bei der Installation verbessert worden.
LG
@Reinhart: Vielen Dank für Deine Hinweise und Deine Geduld. Hat jetzt sehr geholfen :)
Zitat von: Reinhart am 20 Dezember 2018, 21:13:29
ich habe jetzt selber keine Ahnung was du alles wo kopiert hast, aber da stimmt einiges nicht.
Das war auch mein Eindruck! ;)
Zitat
Ich würde dir vorschlagen, einfach ein fertiges "deb" File von Johns Git zu laden oder einfach nochmals alles genau nach Wiki zu kompilieren. Die Verzeichnisse werden ja durch die Installation automatisch alle richtig angelegt. Wenn du dich in Linux gut auskennst ist es kein Problem das jetzt hinzubiegen, aber sonst machen wir hier noch lange so weiter.
Habe mir https://github.com/john30/ebusd/releases/download/v3.2/ebusd-3.2_armhf-jessie.deb runtergeladen und entpackt sowie in /etc/default/ebusd die EBUSD_OPTS ergänzt wie in Antwort #76 gezeigt.
Das Neukompilieren nach Wiki hat ja bei mir nicht geklappt. Warum auch immer???
Hier das Log meiner Aktivitäten aus PuTTY:
pi@raspberrypi:~ $ sudo dpkg -i ebusd-3.2_armhf-jessie.deb
Selecting previously unselected package ebusd.
(Reading database ... 68256 files and directories currently installed.)
Preparing to unpack ebusd-3.2_armhf-jessie.deb ...
Unpacking ebusd (3.2) ...
Setting up ebusd (3.2) ...
Instructions:
1. Edit /etc/default/ebusd if necessary
(especially if your device is not /dev/ttyUSB0)
2. Start the daemon with 'systemctl start ebusd'
3. Check the log file /var/log/ebusd.log
4. Make the daemon autostart with 'systemctl enable ebusd'
pi@raspberrypi:~ $ sudo nano /etc/default/ebusd
pi@raspberrypi:~ $ sudo systemctl start ebusd
pi@raspberrypi:~ $ sudo nano /var/log/ebusd.log
pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated; vendor preset: enabled)
Active: active (running) since Fri 2018-12-21 08:29:42 GMT; 1min 58s ago
Docs: man:systemd-sysv-generator(8)
Process: 924 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ebusd.service
└─931 /usr/bin/ebusd --pidfile /var/run/ebusd.pid --scanconfig -d /dev/ttyebus -p 8888 --httpport=8080 --logfile=info
Dec 21 08:29:42 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Dec 21 08:29:42 raspberrypi ebusd[924]: Starting ebusd: ebusd.
Dec 21 08:29:42 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $ sudo service ebusd start
pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/init.d/ebusd; generated; vendor preset: enabled)
Active: active (running) since Fri 2018-12-21 08:29:42 GMT; 2min 47s ago
Docs: man:systemd-sysv-generator(8)
Process: 924 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/ebusd.service
└─931 /usr/bin/ebusd --pidfile /var/run/ebusd.pid --scanconfig -d /dev/ttyebus -p 8888 --httpport=8080 --logfile=info
Dec 21 08:29:42 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Dec 21 08:29:42 raspberrypi ebusd[924]: Starting ebusd: ebusd.
Dec 21 08:29:42 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $ sudo nano /var/log/ebusd.log
pi@raspberrypi:~ $ ps -ax | grep ebus
931 ? Ssl 0:00 /usr/bin/ebusd --pidfile /var/run/ebusd.pid --scanconfig -d /dev/ttyebus -p 8888 --httpport=8080 --logfile=info
1029 pts/0 S+ 0:00 grep --color=auto ebus
pi@raspberrypi:~ $ ls /var/log
alternatives.log auth.log bootstrap.log daemon.log dpkg.log faillog lastlog samba user.log
apt boot.log btmp debug ebusd kern.log messages syslog wtmp
pi@raspberrypi:~ $
Wenn ich das mit meinen bescheidenen Linux-Kenntnissen richtig interpretiere, läuft der Daemon, aber ebusd.log wurde nicht angelegt.
Würdest Du Dir das mal kritisch ansehen und mir dann weiter auf's Pferd helfen?
Viele Grüße aus dem Regen an der Küste
Det :)
ja sieht gut aus, der ebusd Dämon läuft. Gib im /etc/default/ebusd noch folgenden Parameter mit:
-l /var/log/ebusd.log
anstatt des --logfile=info
Dann sollte auch das Log klappen, musst aber den Dämon nach der Änderung einmal stoppen und wieder starten
sudo service ebsud stop
sudo service ebsud start
Prüfen kannst das ja sofort nach dem Start mit (ein bisschen warten)
cat /var/log/ebusd.log
LG
Grosse Klasse! Ich denke, er tut, was er soll:
pi@raspberrypi:~ $ cat /var/log/ebusd.log
2018-12-21 09:32:01.542 [main notice] ebusd 3.2.v3.2 started with auto scan
2018-12-21 09:32:01.740 [bus notice] bus started with own address 31/36
pi@raspberrypi:~ $Prima, dass ich mit Deiner und John30s Hilfe schon mal soweit gekommen bin.
Bevor ich in die falsche Richtung marschiere, noch zwei Fragen:
- Wenn ich das Wiki https://github.com/john30/ebusd/ (https://github.com/john30/ebusd/) richtig interpretiere, dann muss ich jetzt den eBus konfigurieren.
Dazu geht es wohl dann weiter, wie in https://github.com/john30/ebusd-configuration (https://github.com/john30/ebusd-configuration) beschrieben.? - Wann ist der Zeitpunkt gekommen, meinen eBus-Raspi mit Eurer Platine an die Vaillant-Hardware anzuschliessen?
Groetjes vom Nordmeer
Det :)
Prima!
zu 1. wenn du noch keine Konfigurationsdateien hast dann kannst du es so machen (aus dem Home Verzeichnis installieren /home/pi ) .
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
Versuch' es doch mal mit sudo.
Groetjes
Det :)
Ich habe jetzt mit Stretch Lite probiert.
Gleich darauf habe ich openhanded 2.4 installiert, java und versucht nach dieser Installationsanleitung vorzugehen.
Nach dem deaktivieren der seriellen Ports habe ich mittels "ls -l /dev" kontrolliert ob "ttyAMA0" noch in der Auflistung vorhanden ist. Leider ist diese noch zu sehen, obwohl es laut Anleitung verschwinden sollte.
Auch nach dem Befehle make erscheint folgende Meldung. pi@raspberrypi:~/ttyebus $ sudo make
make -C /lib/modules/4.14.72v7-aufs/build M=/home/pi/ttyebus modules
make[1]: *** /lib/modules/4.14.72v7-aufs/build: No such file or directory. Stop.
Makefile:24: recipe for target 'all' failed
make: *** [all] Error 2
Des weiteren kommt mir komisch vor, das im Ordner /use/src pi@raspberrypi:/usr/src $ ls
linux-headers-4.14.79+ linux-headers-4.14.79-v7+ andere Versionen ersichtlich sind als meine Kernal Version.
pi@raspberrypi:/usr/src $ uname -r
4.14.72v7-aufs
wie kann ich die Probleme beheben?
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 (https://forum.fhem.de/index.php/topic,84636.msg869202.html#msg869202) 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
Zitat von: Trainer am 24 Dezember 2018, 12:43:54
Des weiteren kommt mir komisch vor, das im Ordner /use/src pi@raspberrypi:/usr/src $ ls
linux-headers-4.14.79+ linux-headers-4.14.79-v7+ andere Versionen ersichtlich sind als meine Kernal Version.
pi@raspberrypi:/usr/src $ uname -r
4.14.72v7-aufs
wie kann ich die Probleme beheben?
Dein Problem: die Kernel-Header sind Version 4.14.79, du hast Kernel 4.14.72. Es gibt zwei mögliche Lösungen:
1) Du suchst Kernel-Header 4.14.72 und installierst diese.
2) Du aktualisierst Deinen Kernel auf 4.14.79
Zitat von: Peter0961 am 26 Dezember 2018, 13:45:08
Habe ich!
Auch mit sudo davor immer noch: keine Berechtigung!
mach doch einfach "sudo -s", dann bist Du root.
Danach die Befehle ohne sudo und es sollte klappen
Zitat von: john30 am 26 Dezember 2018, 13:46:15
mach doch einfach "sudo -s", dann bist Du root.
Danach die Befehle ohne sudo und es sollte klappen
Danke für den Tipp!
Hallo,
so Treiber ist installiert!
Ich habe mich leider erst ein wenig in die Irre leiten lassen
und habe seriall -> ttyS0 und seriall -> ttyAMA0 durcheinander geschmissen!
ttyAMA0 war doch schon verschwunden!
Habe es nach Anleitung von Diam35 aus Antwort #106 am: 08 Dezember 2018, 01:08:54 gemacht!
Manchmal sieht man den Wald vor lauter Bäumen nicht! :-[
Gruß Peter
Zitat von: dkreutz am 24 Dezember 2018, 20:23:22
Dein Problem: die Kernel-Header sind Version 4.14.79, du hast Kernel 4.14.72. Es gibt zwei mögliche Lösungen:
1) Du suchst Kernel-Header 4.14.72 und installierst diese.
2) Du aktualisierst Deinen Kernel auf 4.14.79
Ich habe ein Kernel Update auf die Version 4.14.79 versucht. Leider ohne Erfolg.
pi@raspberrypi:~ $ sudo rpi-update 2267b322afdb18b4abf9603fea836916190b1b5d
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13545 100 13545 0 0 41118 0 --:--:-- --:--:-- --:--:-- 41045
*** Relaunching after update
You appear to be using a custom kernel file.
Skipping installation of new kernel, as bundled dtb files may be incompatible with your kernel.
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** We're running for the first time
*** Backing up files (this will take a few minutes)
*** Backing up firmware
#############################################################
This update bumps to rpi-4.14.y linux tree
Be aware there could be compatibility issues with some drivers
Discussion here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=197689
##############################################################
*** Downloading specific firmware revision (this will take a few minutes)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 168 0 168 0 0 420 0 --:--:-- --:--:-- --:--:-- 421
100 56.1M 0 56.1M 0 0 891k 0 --:--:-- 0:01:04 --:--:-- 309k
*** Updating firmware
*** As requested, not updating kernel
*** As requested, not updating kernel modules
*** Updating VideoCore libraries
*** Using HardFP libraries
*** Updating SDK
*** Running ldconfig
*** Storing current firmware revision
*** Deleting downloaded files
*** Syncing changes to disk
*** If no errors appeared, your firmware was successfully updated to 2267b322afdb18b4abf9603fea836916190b1b5d
*** A reboot is needed to activate the new firmware
Nach einem Reboot noch immer auf der alten Version.
pi@raspberrypi:~ $ uname -r
4.14.72v7-aufsWie kann ich ein dorngrad der Kernel header durchführen?
Zitat von: Reinhart am 24 Dezember 2018, 13:34:23
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 (https://forum.fhem.de/index.php/topic,84636.msg869202.html#msg869202) 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 (https://github.com/ebus/ttyebus) durchgeführt. Leider erscheint noch immer
crw-rw---- 1 root dialout 204, 64 Dec 27 19:39 ttyAMA0.
ich besitze einen RPI3b+
.... dann hast du noch irgendwas übersehen!
Ich habe auch den Raspi 3 für Fhem und habe jetzt den ttyAMA0 abgeschaltet.
Nochmals zum Checken:
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.
# 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:
sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo systemctl status serial-getty@ttyAMA0.service
sudo reboot
und rebooten
ls -l /dev
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
Zitat von: Reinhart am 28 Dezember 2018, 09:30:32
.... dann hast du noch irgendwas übersehen!
Ich habe auch den Raspi 3 für Fhem und habe jetzt den ttyAMA0 abgeschaltet.
Nochmals zum Checken:
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.
# 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:
sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo systemctl status serial-getty@ttyAMA0.service
sudo reboot
und rebooten
ls -l /dev
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.
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.shpi@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-btpi@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.htmlpi@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
irgend etwas muss bei deinem PI anders sein als bei meinem Pi 3.
Lies einmal hier (https://dreamshader.bplaced.net/wordpress/2016/08/25/aktivieren-der-seriellen-schnittstelle-des-raspberry-pi/), 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
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:
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:
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"
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?!
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
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
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:
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":
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 (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
Zitat von: Boemmel am 01 Januar 2019, 16:06:13
Ich würde jetzt versuchen, wie Hans vorzugehen (siehe: https://forum.fhem.de/index.php/topic,65678.0.html (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
Zitat von: Reinhart am 21 Dezember 2018, 12:56:54
Prima!
zu 1. wenn du noch keine Konfigurationsdateien hast dann kannst du es so machen (aus dem Home Verzeichnis installieren /home/pi ) .
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. :D :D :D
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 ;D
Grüße von der feucht-kalten Wasserkante
Det :)
Zitat von: Schlauer Det am 04 Januar 2019, 17:01:19
Es sind noch einige undefined MS commands im Log-File. Was bedeutet das?
Dass deren Definition/Syntax noch nicht klar ist.
Punkt 1 hat dir John schon erklärt!
Punkt 2:
selber compilieren und du hast die neuste Version. John hat das im Wiki (https://github.com/john30/ebusd/wiki/1.-Build-and-install)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
Schönen Nachmittag zusammen.
Nach langen experimentieren läuft die Schaltung endlich reibungslos nur der MQTT Broadcast will nicht laufen.
Auszug aus dem LOG
2019-01-23 15:14:21.168 [mqtt error] publish: The client is not currently connected.
Meine Konfig
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
Zitat von: Baunti66 am 23 Januar 2019, 16:52:27
Ich hoffe jemand hat eine Idee. ::)
ist 192.168.1.201 der host, auf dem auch ebusd läuft?
Nein.
201 ist der broker.
Zitat von: Baunti66 am 23 Januar 2019, 17:59:42
Nein.
201 ist der broker.
und ist der broker port auch für nicht-lokale clients zugänglich?
danke für deinen Gedanklichen anstoss, mein router hat die verbindung geblockt.
Hallo zusammen,
erst einmal vielen Dank für eure Mühe dieses Thema so gut zu betreuen. Ich habe mittlerweile die RPI Platine zu spielen bekommen. Es gab ein paar Hindernisse, allerdings waren die zwischen den Ohren und nicht in der Technik.
Bei einem Punkt komme ich trotz nachforschen nicht weiter. Ich würde gerne bei einer auromatic 620 den Solarpumpenstatus (an-aus) auslesen. Im Gerät ist er verfügbar, aber halt ebusd nicht und in keiner csv. Ich habe mir auch das vrDialog 810 installiert und auch da gibt es keinen Eintrag. Vielleicht weiß einer von euch, wie ich diesen Status ausgelesen bekomme.
Viele Grüße
Benedikt
Habe heute meine Platine V2.2 erhalten. Läuft auch am Raspberry.
Kann ich die RPi Platine auch mit einem FTDI Serial Adapter betreiben? Also, wie die normale Platine bzw. die alte Version?
@nols
ja, sollte funktionieren am JP1 mit einem Uart einspeisen aber Adapter dann nicht am Raspi aufstecken.
Du musst nur sicherstellen, das an Pin 5 auch 5V für den DC-Wandler zugeführt werden, aber auch die 3,3V nicht vergessen. Normalerweise werden die 5V ja von der Steckleiste dem Adapter zugeführt.
Ich habe das so noch nicht getestet, aber ich glaube chons hat das schon praktiziert.
LG
Danke für die Antwort.
Ich wollte den EBUS Adapter in OpenHAB einbinden. Dort kann ich leider den /dev/ttyebus nicht ansprechen. Deswegen der Umweg über den USB-Serial Adapter.
Meine V1.6 bekomme ich leider nicht ans laufen. (Liest nur und kann nicht schreiben, daher identifiziert diese die Vaillant Geräte nicht)
Die neue V2.2 funktioniert mit ebusd. Kann aber leider über /dev/ttyebus nicht eingebunden werden.
Gesendet von iPhone mit Tapatalk
aber openhab hat ja nichts mit dem ttyebus zu tun, das ist reiner serieller Basistreiber vom Raspberry!
LG
Zitat von: nols am 01 Februar 2019, 23:00:51
Ich wollte den EBUS Adapter in OpenHAB einbinden.
Ich lasse ebusd über MQTT die Daten an OpenHAB weiterleiten. Das funktioniert ziemlich gut.
hast du den RPI Adapter und hattest du da Probleme mit dem ttyebus?
LG
Zitat von: Reinhart am 02 Februar 2019, 17:21:31
hast du den RPI Adapter und hattest du da Probleme mit dem ttyebus?
Am Anfang gabs ein Problem mit Pufferüberläufen. Das ist aber schon lange behoben. Seit dem läuft alles ohne Probleme.
Zitat von: jkyprian am 02 Februar 2019, 16:41:44
Ich lasse ebusd über MQTT die Daten an OpenHAB weiterleiten. Das funktioniert ziemlich gut.
Hast du dazu eine Anleitung? Ich habe über MQTT nur Sonoffs in Openhab. Das funktioniert mit dem MQTT2 Binding ganz gut.
Als erstes möchte ich mal Danke an alle beteiligten Entwickler und Unterstützer dieses Projektes sagen. Die Platinen 1.6 sowie die jetzige 2.0-RPi (beide selbst bestückt) und auch der EBUSD laufen seit der Einrichtung auf dem Pi völlig Problemlos und Transparent. Dank MQTT ist die ganze Einrichtung der Verbindung zu FHEM nun noch problemloser geworden.
Eine Frage zum integrierten MQTT-Client habe ich dennoch.
@John30
Zur Zeit läuft die Kommunikation zwischen dem EBUS-Demon und FHEM auch über MQTT. Ist es geplant den im EBUSD enthaltenen MQTT Client zu erweitern um auch die GPIO des RasPi R/W zuzugreifen?
Hintergrund ist, dass ich bei mir die Warmwasser-Umwälzpumpe über eine extra Platine durch FHEM ein und ausschalte. Das geht leider nicht direkt über den eBus. So ähnlich wie hier https://forum.fhem.de/index.php/topic,29737.0.html (https://forum.fhem.de/index.php/topic,29737.0.html) nur nicht über 1-Wire sondern über die GPIO des PasPi.
Dazu benutze ich einen zusätzlichen MQTT Client für die Verbindung zu FHEM.
Grüße
Zitat von: majorshark am 08 Februar 2019, 14:18:53
@John30
Zur Zeit läuft die Kommunikation zwischen dem EBUS-Demon und FHEM auch über MQTT. Ist es geplant den im EBUSD enthaltenen MQTT Client zu erweitern um auch die GPIO des RasPi R/W zuzugreifen?
nein, das wäre Quatsch. Dafür gibt es sicher einfachere Lösungen mit anderen clients und/oder fhem Integration.
Hallo,
scheitere schon am testen. Der Ebusd läuft die orangene und grüne LED leuchten dauerhaft, beim Test bekomme ich die Meldung ttyebus wäre belegt.
Was muss ich nun wo prüfen ?
pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-02-09 17:49:22 CET; 26min ago
Process: 434 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 435 (ebusd)
CGroup: /system.slice/ebusd.service
└─435 /usr/bin/ebusd -d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%name
Feb 09 17:49:22 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Feb 09 17:49:22 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $ echo "das ist ein Sendetest" >/dev/ttyebus
-bash: /dev/ttyebus: Das Gerät oder die Ressource ist belegt
Grüße
Thomas
Ja, ist klar, wenn der Dämon gestartet ist belegt er ja den ttyebus, daher die Fehlermeldung!
Wenn du testen willst, darf der Dämon natürlich nicht laufen sonst kannst du mit Echo nichts an Device ttyebus schicken!
LG
Ja, sry ... Danke, dann blinkts auch kurz :).
Das ist richtig, der Test war dann positiv!
LG
Hi,
wie ist das genaue vorgehen wenn ich jetzt eine Multimatic VRC 700/5 habe statt einer Calormatic 430 ?
Wie genau frage ich die Multimatic mit dem at ab und wo kann man das nachlesen/steht das ?
Zitatfhem("set Mosquitto publish ebusd/430/Hc1HeatCurve/get");
Grüße
Thomas
edit:
Aha, man schaut sich die Konfigurationsdateien an, gefunden hab ich sie bisher aber nicht.
Muss ich statt ebusd-2.x.x ebusd-2.1.x verwenden ? Finde die Multimatic nur dort .
Ja genau, nimm die letzte Version und schaue in den diversen Threads nach ob schon jemand eine csv für die 700 gepostet hat.
LG
Zitat von: Reinhart am 10 Februar 2019, 17:25:45
Ja genau, nimm die letzte Version und schaue in den diversen Threads nach ob schon jemand eine csv für die 700 gepostet hat.
LG
Das ich dich richtig verstehe, hier (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de/vaillant) hab ich die csv für die Multimatic gefunden. Ich verwende den letzten Release.
So gehts nicht:
fhem("set Mosquitto publish ebusd/700/Hc1HeatCurve/get")
Muss ich wsl. den vorletzten Release nehmen.
Mir war unklar ob man diese Datei auch einfach in den entsprechenden Ordner schieben kann und gut ist.
Klar (https://forum.fhem.de/index.php/topic,46098.msg792309.html#msg792309) hat die mal jemand geposted.
wenn John die schon im Git hat dann sollte sie auch bei dir installiert sein wenn du die Config vom Server ziehst.
-c http://ebusd.eu/config/
Dann solltest du zunächst am Mosquitto debuggen bevor du beginnst Befehle aus Fhem abzusetzen.
Öffne dazu 2 Konsolen, in der der ersten startest du das MQTT Logging.
mosquitto_sub -d -v -t \#
und in der 2.Konsole setzt du dein Kommando ab und schaust in der ersten Konsole was nun zurück kommt
mosquitto_pub -n -t ebusd/700/Hc1HeatCurve/get
Das Ergebnis sollte so aussehen:
Client mosqsub/31927-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/700/Hc1HeatCurve/get', ... (0 bytes))
ebusd/700/Hc1HeatCurve/get (null)
Client mosqsub/31927-Raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/700/Hc1HeatCurve', ... (32 bytes))
ebusd/700/Hc1HeatCurve {
"curve": {"value": 0.20}}
die erste Message ist dein abgesetztes Kommando und die zweite Zeile gibt dir eBusd mit dem Ergebnis zurück.
LG
Ok,
beim debuggen sieht man denke ich schon das Problem.
Client mosqsub|15701-raspberry received PUBLISH (d0, q0, r1, m0, 'ebusd/global/updatecheck', ... (392 bytes))
ebusd/global/updatecheck "revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.700.csv: different version available, vaillant/bai.0010010674.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc:different version available, vaillant/hcmode.inc: different version available, vaillant/service.inc: different version available"
Was läuft hier schief ?
Schön ist aber zu sehen das es generell klappen sollte. :)
Client mosqsub|15701-raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/700/Hc1HeatCurve/get', ... (0 bytes))
ebusd/700/Hc1HeatCurve/get (null)
Client mosqsub|15701-raspberry received PUBLISH (d0, q0, r0, m0, 'ebusd/700/Hc1HeatCurve', ... (40 bytes))
ebusd/700/Hc1HeatCurve {
"0": {"name": "", "value": 2.05}}
Nachdem ich ein mosquitto_pub -n -t ebusd/700/Hc1HeatCurve/get ausgeführt habe, wurde auch das MQTT2_ebusd_700 angelegt. :)
Von alleine kommt aber nichts rein, nur wenn ich anfordere schätze doch mal liegt an dem different version available
Zitat von: TomLee am 10 Februar 2019, 22:54:25
Von alleine kommt aber nichts rein, nur wenn ich anfordere schätze doch mal liegt an dem different version available
von alleine kommen nur Broadcast, du musst sie schon selber abholen! Das habe ich hier einmal kurz (https://forum.fhem.de/index.php/topic,79600.msg903197.html#msg903197)beschrieben. Mit dem Modul Gaebus kannst du mit "interval" einstellen das automatisch abgeholt wird, dazu brauchst du aber Fhem.
define <name> GAEBUS <device-addr>[:<port>] [<interval>]; Aber sonst sieht es ja gut aus, du bekommst die aktuelle Heizkurve angezeigt, alles ist ok!
LG
Oh Mann,
das at hab ich direkt anfangs definiert (etwas eingelesen hab ich mich schon).
Aber gleich ein Blick ins Logfile hätte gezeigt das mein Broker sich nicht wie in den Beispielen Mosquitto schimpft.
defmod at_MQTT2_Ebus at +*00:05:00 {\
fhem("set myBroker publish ebusd/700/Hc1HeatCurve/get");;\
fhem("set myBroker publish ebusd/bai/WaterPressure/get");;\
fhem("set myBroker publish ebusd/bai/FlowTemp/get");;\
fhem("set myBroker publish ebusd/bai/ReturnTemp/get");;\
fhem("set myBroker publish ebusd/bai/OutdoorstempSensor/get");;\
}
Jetzt klappt alles :)
Bin erstaunt das die Einrichtung des Ebusd und allem was dazugehört am Ende mit den MQTT2-Templates so einfach war.
Danke allen die das ermöglicht haben.
Hallo zusammen,
ich hatte es zwar schon im Thread "eBus Schaltung V2 in Betrieb nehmen" gepostet, aber anscheinend bin ich mit meinem Problem hier besser aufgehoben - zuerst aber auf jeden Fall einmal ein großer Dank an alle Beteiligten für dieses Projekt - ich entwickle selber etwas Vergleichbares für den BSB/LPB/PPS-Bus von Heizungen mit Siemens-Steuerung, daher weiß ich, wie viel Arbeit in so einem Projekt steckt.
Ich muss zur Arbeit pendeln und habe in der Butze dort eine Vaillant atmoTEC plus VCW DE 194/4-5-HL R1 mit einem Calormatic 332 Raumgerät hängen, die so grausig taktet, dass ich hoffe, ihr mit dem Auslesen der Daten und angepasster Konfiguration etwas auf die Sprünge zu helfen. Die Platine habe ich von Reinhard bekommen und alles läuft so erst einmal prima. Nur leider komme ich mit dem Auslesen nicht weiter.
Installiert ist die ebusd Version frisch von GitHub: 3.3.v3.3-12-g5af41df (allerdings sagt mir ebusctl i, dass eine neuere broadcast.csv revision bereit stünde, die über git clone aber nicht zu kommen scheint. Wie kann ich die installieren?).
Das ist, was bisher kommt:
ebusctl i
version: ebusd 3.3.v3.3-12-g5af41df
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
signal: acquired
symbol rate: 22
max symbol rate: 57
reconnects: 0
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
ebusctl find:
broadcast datetime = no data stored
broadcast error = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast signoflife = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan.08 = no data stored
scan.15 = no data stored
ebusctl grab result decode:
1008b5110102 / 05033c8a467a = 36
BCD 03=3, 46=46
BDY 03=Thu
D1B 03=3, 3c=60, 8a=-118, 46=70, 7a=122
D1C 03=1.5, 3c=30.0, 8a=69.0, 46=35.0, 7a=61.0
D2B 033c=60.012, 3c8a=-117.766, 8a46=70.539, 467a=122.273
D2C 033c=960.19, 3c8a=-1884.25, 8a46=1128.62, 467a=1956.38
DAY 033c="24.01.1942", 3c8a="21.11.1996", 8a46="11.06.1949", 467a="14.09.1985"
EXP 033c8a46=17694, 3c8a467a=2.5772e+35
EXR 033c8a46=5.5407e-37, 3c8a467a=0.0168793
FLR 033c=0.828, 3c8a=15.498, 8a46=-30.138, 467a=18.042
FLT 033c=15.363, 3c8a=-30.148, 8a46=18.058, 467a=31.302
HDY 03=Fri
HEX:5 033c8a467a="03 3c 8a 46 7a"
NTS:5 033c8a467a="<?Fz"
S3N 033c8a=-7717885, 3c8a46=4622908, 8a467a=8013450
S3R 033c8a=212106, 3c8a46=3967558, 8a467a=-7715206
SCH 03=3, 3c=60, 8a=-118, 46=70, 7a=122
SIN 033c=15363, 3c8a=-30148, 8a46=18058, 467a=31302
SIR 033c=828, 3c8a=15498, 8a46=-30138, 467a=18042
SLG 033c8a46=1183464451, 3c8a467a=2051443260
SLR 033c8a46=54299206, 3c8a467a=1015694970
STR:5 033c8a467a=" <?Fz"
TEM_P 033c=24-003, 3c8a=20-060, 8a46=13-010, 467a=20-070
TTM 03="00:30", 3c="10:00", 8a="23:00", 46="11:40", 7a="20:20"
U3N 033c8a=9059331, 3c8a46=4622908, 8a467a=8013450
U3R 033c8a=212106, 3c8a46=3967558, 8a467a=9062010
UCH 03=3, 3c=60, 8a=138, 46=70, 7a=122
UIN 033c=15363, 3c8a=35388, 8a46=18058, 467a=31302
UIR 033c=828, 3c8a=15498, 8a46=35398, 467a=18042
ULG 033c8a46=1183464451, 3c8a467a=2051443260
ULR 033c8a46=54299206, 3c8a467a=1015694970
1008b512020064 / 00 = 23
BCD 00=0, 64=64
BDA 0064="10.11.1944"
BDY 00=Mon
D1B 00=0, 64=100
D1C 00=0.0, 64=50.0
D2B 0064=100.000
D2C 0064=1600.00
DAY 0064="03.02.1970"
EXP 0064=3.58732e-41
EXR 0064=1.4013e-43
FLR 0064=0.100
FLT 0064=25.600
HDA 0064="03.02.1970"
HDY 00=Tue
HEX:2 0064="00 64"
NTS:2 0064=""
PIN 0064=0064
S3N 0064=25600
S3R 0064=100
SCH 00=0, 64=100
SIN 0064=25600
SIR 0064=100
SLG 0064=25600
SLR 0064=100
STR:2 0064=""
TEM_P 0064=00-100
TTM 00="00:00", 64="16:40"
U3N 0064=25600
U3R 0064=100
UCH 00=0, 64=100
UIN 0064=25600
UIR 0064=100
ULG 0064=25600
ULR 0064=100
ebusctl grab result:
1008b5110102 / 05033c8a467a = 37
1008b512020064 / 00 = 25
Mein Hauptproblem ist anscheinend, dass beim Start ein "scan config 15: ERR: read timeout" bzw. "scan config 08: ERR: read timeout" kommt. Ähnlich wie hier (https://github.com/john30/ebusd/issues/217) scheint, wenn man die Rohdaten loggt, keine Antwort auf ">31" zu kommen. Die RasPi-Platine ist aber über den Service-Port der Calormatic angeschlossen, da sollte ein Schreiben auf jeden Fall möglich sein. Da beim Rohdaten-Log außerdem einige Telegramme erscheinen, die zumindest laut ebus-Wiki Sinn machen, gehe ich davon aus, dass die Busverbindung klappt.
Auf Pi-Seite flackert die rote LED, wenn die ">31" gesendet werden, so dass ich davon ausgehe, dass bis zur LED hin auch alles soweit nach Plan läuft. Da ich die fertige Platine von Reinhart bezogen habe, der die ja auch getestet hat, gehe ich auch hier nicht von einem Hardware-Problem aus.
Gibt es irgendeine andere Erklärung dafür, bzw. eine Möglichkeit, wie ich damit umgehen soll? Zur Not würde es mir auch reichen, direkt auf die passende CSV-Datei zu verweisen, aber auch dazu habe ich bisher noch nichts gefunden, wie ich das bewerkstelligen könnte...
Dank' Euch im Voraus und viele Grüße,
Frederik
...Asche auf mein Haupt! Die (fehlende) Installation des ttyebus-Treibers war mein entscheidender Fehler - ich hatte mich zuerst nur an die Anleitung im Thread "eBus Schaltung in Betrieb nehmen" gehalten, und da ich zuvor schon mal die serielle Konsole deaktiviert hatte, kam es da zu keinen Problemen; dazu funktionierte ja das Lesen der Broadcast-Telegramme. Durch die Anleitung hier am Anfang des Threads habe ich aber nun gesehen, dass das mehr Zufall war. Nun, mit dem ttyebus Treiber klappt die Erkennung und auch ebusctl find gibt nun zumindest bei ein paar Parametern einen Wert aus:
350 ActualPumpPower = no data stored
350 ActualRoomTempDesired = no data stored
350 ActualTempDesired = no data stored
350 ActualWeekday = no data stored
350 BypassValve = no data stored
350 C1C2State = no data stored
350 CirPump = no data stored
350 ClockSwitchSummerWinterDone = no data stored
350 CMResetCnt = no data stored
350 CollPumpHRuntime = no data stored
350 COMErrorCnt = no data stored
350 ComfTempDesired = no data stored
350 ComfTempEnabled = no data stored
350 ControlMode = no data stored
350 Date = no data stored
350 DcfDaten = no data stored
350 DisableAutoSync = no data stored
350 eBUSCRC = no data stored
350 eBUSFifoDiffCntMax = no data stored
350 EDControlEnabled = no data stored
350 EEpromMaxInkonsCnt = no data stored
350 ElectronicCartridge = no data stored
350 FillmodeStartTime = no data stored
350 FlowTempMin = no data stored
350 FrostProtectDelay = no data stored
350 HeatingCurve = no data stored
350 HwcState = no data stored
350 HwcTempDesired = no data stored
350 HydraulicMixer = no data stored
350 HydraulicScheme = no data stored
350 IsInFloorPavingDrying = no data stored
350 IsInHoliday = no data stored
350 IsInParty = no data stored
350 IsInQuickVeto = no data stored
350 IsInSavingsFunction = no data stored
350 IsInSingleHwcLoadingMode = no data stored
350 IsInTeleSwitch = no data stored
350 LegioProtectionEnabled = no data stored
350 LegioProtectionState = no data stored
350 LegioPump = no data stored
350 LoadingDelayEnabled = no data stored
350 LVResetCnt = no data stored
350 NumCollPanels = no data stored
350 OffDiff = no data stored
350 OffsetDesTemp = no data stored
350 ONDiff = no data stored
350 ONMAXDiff = no data stored
350 ONMINDiff = no data stored
350 OperatingMode = no data stored
350 OperatingModeHwc = no data stored
350 OperatingmodeStartTime = no data stored
350 OtShutdownLimit = no data stored
350 OutsideTemp = no data stored
350 OutsideTempOffset = no data stored
350 POCResetCnt = no data stored
350 PrevOperatingMode = no data stored
350 PumpPower = no data stored
350 QuickVetoTemp = no data stored
350 ReducedNightTemp = no data stored
350 ResetOperatingTimes = no data stored
350 ResetYield = no data stored
350 RestoreOpModeAfterHoliday = no data stored
350 resvdColl1Sensor = no data stored
350 resvdColl2Sensor = no data stored
350 resvdCollPump1 = no data stored
350 resvdCollPump2 = no data stored
350 resvdStorage1Sensor = no data stored
350 resvdStorage2Sensor = no data stored
350 resvdStorage3Sensor = no data stored
350 ROCRoomSet = no data stored
350 RoomTemp = no data stored
350 RoomTempOffset = no data stored
350 RoomTempOffsetSelfWarming = no data stored
350 RoomTempSwitchOn = no data stored
350 RTCAdjustment = no data stored
350 SavingsFunctionTime = no data stored
350 SolFlowRate = no data stored
350 SolHwcMaxLoadTemp = no data stored
350 SolPumpBlockingTime = no data stored
350 StackeBUSTaskMax = no data stored
350 StackLifeCheckTaskMax = no data stored
350 StackMainTaskMax = no data stored
350 StartCircuitAeration = no data stored
350 StateOfRoomCon = no data stored
350 StatusDcf = no data stored
350 SwitchOffParty = no data stored
350 TeleSwOperatingMode = no data stored
350 Time = no data stored
350 TimeWindows = no data stored
350 UV1State = no data stored
350 Variant = no data stored
350 VariantDKRefreshCnt = no data stored
350 WDResetCnt = no data stored
350 WeekDayProgSwitch = no data stored
350 YearCalendarActive = no data stored
350 Yield = no data stored
350 YieldSensor = no data stored
350 ZweipunktAnalogSlct = no data stored
bai AATemp = no data stored
bai AccessoriesOne = no data stored
bai AccessoriesTwo = no data stored
bai ACRoomthermostat = no data stored
bai AircontrolOk = no data stored
bai AITemp = no data stored
bai AntiCondensValue = no data stored
bai averageIgnitiontime = no data stored
bai BlockTimeHcMax = no data stored
bai BoilerType2 = no data stored
bai BoilerType = no data stored
bai ChangesDSN = no data stored
bai CirPump = no data stored
bai CounterStartattempts1 = no data stored
bai CounterStartattempts2 = no data stored
bai CounterStartAttempts3 = no data stored
bai currenterror = no data stored
bai DateTime = nosignal;09:26:14;-.-.-;-
bai dcfState = no data stored
bai DCFTimeDate = no data stored
bai DCRoomthermostat = no data stored
bai DeactivationsIFC = no data stored
bai DeactivationsTemplimiter = no data stored
bai DeltaFlowReturnMax = no data stored
bai DisplayMode = no data stored
bai DSN = no data stored
bai DSNOffset = no data stored
bai DSNStart = no data stored
bai EBusHeatcontrol = no data stored
bai EbusSourceOn = no data stored
bai EbusVoltage = no data stored
bai errorhistory = no data stored
bai ExhaustCurve = no data stored
bai exhaustWayBlockCounter = no data stored
bai expertlevel_ReturnTemp = no data stored
bai ExternalFaultmessage = no data stored
bai externalFlowTempDesired = no data stored
bai externalHwcSwitch = no data stored
bai ExternGasvalve = no data stored
bai ExtFlowTempDesiredMin = no data stored
bai extWP = no data stored
bai FanHours = no data stored
bai FanMaxSpeedOperation = no data stored
bai FanMinSpeedOperation = no data stored
bai FanPWMSum = no data stored
bai FanPWMTest = no data stored
bai FanSpeed = no data stored
bai FanStarts = no data stored
bai Flame = no data stored
bai FlameSensingASIC = no data stored
bai FloorHeatingContact = no data stored
bai FlowsetHcMax = no data stored
bai FlowsetHwcMax = no data stored
bai FlowSetPotmeter = no data stored
bai FlowTemp = no data stored
bai FlowTempDesired = no data stored
bai Fluegasvalve = no data stored
bai Gasvalve3UC = no data stored
bai Gasvalve = no data stored
bai GasvalveASICFeedback = no data stored
bai GasvalveUC = no data stored
bai GasvalveUCFeedback = no data stored
bai GVStepOffsetMax = no data stored
bai GVStepOffsetMin = no data stored
bai HcHours = no data stored
bai HcPumpMode = no data stored
bai HcPumpStarts = no data stored
bai HcStarts = no data stored
bai HcUnderHundredStarts = no data stored
bai HeatingSwitch = no data stored
bai HoursTillService = no data stored
bai HwcDemand = no data stored
bai HwcHours = no data stored
bai HwcImpellorSwitch = no data stored
bai HwcPostrunTime = no data stored
bai HwcSetPotmeter = no data stored
bai HwcStarts = no data stored
bai HwcSwitch = no data stored
bai HwcTemp = no data stored
bai HwcTempDesired = no data stored
bai HwcTempMax = no data stored
bai HwcTypes = no data stored
bai HwcUnderHundredStarts = no data stored
bai HwcWaterflow = no data stored
bai HwcWaterflowMax = no data stored
bai Ignitor = no data stored
bai IonisationVoltageLevel = no data stored
bai maintenancedata_HwcTempMax = no data stored
bai maxIgnitiontime = no data stored
bai minIgnitiontime = no data stored
bai ModulationTempDesired = no data stored
bai OutdoorstempSensor = no data stored
bai OverflowCounter = no data stored
bai ParamToken = no data stored
bai PartloadHcKW = no data stored
bai PartloadHwcKW = no data stored
bai PartnumberBox = no data stored
bai PositionValveSet = no data stored
bai PowerValue = no data stored
bai PrAPSCounter = no data stored
bai PrAPSSum = no data stored
bai PredCombustionDecrementTime = no data stored
bai PredCombustionPredCounter = no data stored
bai PredCombustionSwitchingPoint = no data stored
bai PredFanPWMDevThreshold = no data stored
bai PredFanPWMPredCounter = no data stored
bai PredFanPWMRefPWMcounter = no data stored
bai PredFanPWMRefPWMsum = no data stored
bai PredFanPWMSwitchingPoint = no data stored
bai PredIgnitionPredCounter = no data stored
bai PredIgnitionSwitchingPoint = no data stored
bai PredSourcePressureDevThreshold = no data stored
bai PredSourcePressurePredCounter = no data stored
bai PredSourcePressureSwitchingPoint = no data stored
bai PredWaterflowDevThreshold = no data stored
bai PredWaterflowSwitchingPoint = no data stored
bai PredWaterpressureMaxPressure = no data stored
bai PredWaterpressureMinPressure = no data stored
bai PredWaterpressureSwitchingPoint = no data stored
bai PrEnergyCountHc1 = no data stored
bai PrEnergyCountHc2 = no data stored
bai PrEnergyCountHc3 = no data stored
bai PrEnergyCountHwc1 = no data stored
bai PrEnergyCountHwc2 = no data stored
bai PrEnergyCountHwc3 = no data stored
bai PrEnergySumHc1 = no data stored
bai PrEnergySumHc2 = no data stored
bai PrEnergySumHc3 = no data stored
bai PrEnergySumHwc1 = no data stored
bai PrEnergySumHwc2 = no data stored
bai PrEnergySumHwc3 = no data stored
bai PumpHours = no data stored
bai PumpHwcFlowNumber = no data stored
bai PumpHwcFlowSum = no data stored
bai ReduceModulationBlocktime = no data stored
bai RemainingBoilerblocktime = no data stored
bai ReturnRegulation = no data stored
bai ReturnTemp = no data stored
bai ReturnTempMax = no data stored
bai SecondPumpMode = no data stored
bai SerialNumber = no data stored
bai SetFactoryValues = no data stored
bai SetMode = auto;0.0;-;-;1;0;1;0;0;0
bai SHEMaxDeltaHwcFlow = no data stored
bai SHEMaxFlowTemp = no data stored
bai SolPostHeat = no data stored
bai SpecialAdj = no data stored
bai Statenumber = no data stored
bai Status01 = 14.0;14.0;-;-;14.0;off
bai Status02 = auto;60;68.0;70;61.0
bai Status16 = no data stored
bai Status = no data stored
bai Storageloadpump = no data stored
bai StorageLoadPumpHours = no data stored
bai StorageloadPumpStarts = no data stored
bai StorageLoadTimeMax = no data stored
bai StoragereleaseClock = no data stored
bai StorageTemp = no data stored
bai StorageTempDesired = no data stored
bai StorageTempMax = no data stored
bai TargetFanSpeed = no data stored
bai TargetFanSpeedOutput = no data stored
bai TempDiffBlock = no data stored
bai TempDiffFailure = no data stored
bai TempGradientFailure = no data stored
bai Templimiter = no data stored
bai TemplimiterWithNTC = no data stored
bai TempMaxDiffExtTFT = no data stored
bai TimerInputHc = no data stored
bai ValveMode = no data stored
bai ValveStarts = no data stored
bai VolatileLockout = no data stored
bai WarmstartDemand = no data stored
bai WarmstartOffset = no data stored
bai WaterHcFlowMax = no data stored
bai WaterPressure = no data stored
bai WaterpressureBranchControlOff = no data stored
bai WaterpressureMeasureCounter = no data stored
bai WaterpressureVariantSum = no data stored
bai WP = no data stored
bai WPPostrunTime = no data stored
bai WPPWMPower = no data stored
bai WPPWMPowerDia = no data stored
bai WPSecondStage = no data stored
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = no data stored
broadcast signoflife = no data stored
broadcast vdatetime = 17:08:19;04.01.2010
general valuerange = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.08 = Vaillant;BAI00;0518;7401
scan.08 id = 21;12;36;0010006110;0001;012873;N3
scan.15 = Vaillant;35000;0109;7102
scan.15 id = 21;12;34;0020124472;0082;006074;N9
Sorry noch mal für die Verwirrung und danke für den Support!
Moin
Schoen, dass es doch noch geklappt hat!
Gruss Christoph
Nachdem es jetzt nun seit einigen Tagen gut läuft, verstehe ich doch immer noch nicht die Meldungen mit "different version available", wenn ich ebusctl info aufrufe. Ich habe ebusd aus git ausgecheckt und kompiliert, git pull origin master sagt mir, dass alles up-to-date ist, aber trotzdem bekomme ich diese Meldung:
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.350.csv: different version available, vaillant/bai.0010006101.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
Es werden mit der Zeit auch immer mehr Dateien, die anscheinend verändert wurden. Im ebusd-configuration git steht ja, dass sich ebusd automatisch die Dateien besorgt, aber warum erscheinen dann diese Meldungen und wie bekomme ich sie weg?
ich glaube mich daran erinnern zu können das John30 erwähnt hat das der Versionscheck im Augenblick wohl einen Fehler hat.
pi@raspberrypi:~ $ ebusctl i
version: ebusd 3.3.v3.3-5-g2f6b2bb
update check: revision v3.3-4-g212b22d available,
meine lokale Version ist neuer als die er beim Update Check findet und bei dir wird es sicher auch so sein.
Also vorerst diese Meldung einfach ignorieren, ansonsten war deine Vorgangsweise schon richtig.
LG
Reinhart
Hallo Leute,
nachdem ich nun nach 3 Tagen probieren & lesen nicht so richtig klar komme, hoffe ich auf eure Hilfe.
Ich wollte meine RPi-Platine nun in Betrieb nehmen und habe nach Anleitung erstmal alles soweit hinbekommen.
Die grüne & rote LED leuchtet... der Sendetest wird mir auch mit einem kurzen Aufblitzen der roten LED quittiert.
Nun hänge ich beim Einrichten des ebusd.
Erstmal hatte ich schon arge Probleme mit der Installation an sich, da bei jeder gefundenen Anleitung (Forum/WIKI/GitHub) irgendwelche neuen Fehler auftraten.
Nun scheint ebusd aber installiert zu sein. Ich bekomme den Service aber nicht gestartet, da beim Start noch eine Legitimierungs-Abfrage benötigt wird, bei der automatisch der Benutzer root vorausgewählt wird.
[11:16:30] openhabian@OH2:~$ systemctl start ebusd
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Starten von »ebusd.service« notwendig.
Authenticating as: root
Password:
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
==== AUTHENTICATION FAILED ===
Failed to start ebusd.service: Access denied
See system logs and 'systemctl status ebusd.service' for details.
Nun meine Frage: Wie kann ich ebusd mit meinem aktuellen User starten? Ich habe bis jetzt noch keine Configfile gefunden in der ich das ändern kann.
Beste Grüße
@Reinhart: Ok, danke, dann weiß ich Bescheid - hatte mich nur gewundert, dass die Liste der csv-Dateien (zumindest gefühlt) länger, aber dann warte ich einfach mal ab..
@rande: Probier's mal mit sudo service ebusd start und schau' dann, was Dir
tail -f /var/log/ebusd ausgibt.
Ich weiß nicht, ob das hier auch der richtige Thread ist, oder ob ich das eher in den Mega-Thread schreiben sollte, aber ich frage mich, ob es möglich ist, die Uhrzeit und das Datum entweder für bai oder 350 zu setzen.
Ich habe keinen DCF-Empfänger, und da ich in dieser Wohnung nur zwei Nächte die Woche bin und leider auch jetzt mit dem ebusd die Betriebsart meiner Vaillant nicht aus der Ferne wechseln kann, schalte ich die Heizung immer aus, wenn ich wieder fahre. Um mir wenigstens beim Wiederkommen das Neustellen der Uhrzeit zu sparen, wäre ein Setzen der Uhrzeit und des Datums, das ich dann periodisch absetzen könnte, eine große Hilfe...
Zitat von: freetz am 27 Februar 2019, 13:24:03
@rande: Probier's mal mit sudo service ebusd start und schau' dann, was Dir
tail -f /var/log/ebusd ausgibt.
mit sudo davor bekomme ich gar keine Ausgabe & wenn ich nur "service ebusd start" eingebe, kommt die selbe Abfrage wie mit "systemctl start ebusd"
in der /var/log/ebusd.log steht folgendes
2019-02-27 14:34:38.678 [mqtt error] publish: The Client is not currently connected.
Keine Ausgabe ist richtig, und da ebusd.log geschrieben wird, läuft das Programm.
Ok... Na toll.
Auf irgend einer Seite hatte ich gelesen, das mir der Start des Dienstes noch mit einer Ausgabe bestätigt wird.
Dann versuche ich mal mit meiner Vaillant zu kommunizieren.
Vielen Dank!
Gesendet von meinem TA-1012 mit Tapatalk
Zitat von: Reinhart am 27 Februar 2019, 11:17:58
ich glaube mich daran erinnern zu können das John30 erwähnt hat das der Versionscheck im Augenblick wohl einen Fehler hat.
richtig. ich habe jetzt mal ein Ticket (https://github.com/john30/ebusd/issues/266) dafür gemacht, damit ich es nicht ständig vergesse :)
Zitat von: rande am 27 Februar 2019, 17:09:28
Ok... Na toll.
Auf irgend einer Seite hatte ich gelesen, das mir der Start des Dienstes noch mit einer Ausgabe bestätigt wird.
Dann versuche ich mal mit meiner Vaillant zu kommunizieren.
Vielen Dank!
Gesendet von meinem TA-1012 mit Tapatalk
Moin
Das steht in der Tat im Wiki, stimmt aber nicht.
Gruss Christoph
Hallo zusammen,
ich hab jetzt soviel wie möglich gelesen aber zu meinem Problem noch nix gefunden:
Platine ist selber gelötet.
Die gelbe LED leuchtet, die rote blitzt auch auf, aber die grüne LED leuchtet nie (also auch ohne ebus Anschluß, da sollte sie ja dauerhaft leuchten).
Minuspol ist rechts wie bei den anderen beiden LEDs.
Hat jemand eine Idee was ich testen könnte? Kann/soll ich die LED auslöten und mit einer bestimmten Spannung testen ob sie überhaupt funktioniert?
Danke & viele Grüße
Kalle
EDIT: Habe die grüne LED mal gg eine aus dem Bestand getauscht, aber gleiches Problem. Sowohl die alte als auch neue (als auch die neue eingelötet) leuchten per Labornetzeil mit 2,1V.
wenn du die Led tauschst, musst du unbedingt darauf achten, dass es eine Low Current Version (2 mA ) ist, sonst funktioniert die Schaltung nicht.
Eigentlich kann das nicht viel sein.
Der Optokoppler OK1 ist richtig eingelötet? Ansonsten ist hier nur R2, Led1 und der Optokoppler OK1 im Einfluß. Du kannst ja einmal versuchen, bei angesteckter Platine am Raspi (ohne eBus) Pin 4+5 mit einem Schraubendreher kurzschließen, dann muss sie leuchten. Wenn sie nicht leuchtet, ist sie entweder verkehrt gepolt oder du hast wohl den Widerstand R2 vertauscht, dieser muss 220 Ohm haben.
LG
Hi Reinhart,
der Widerstand passt, den hab ich gemessen. Die originale LED hab ich auch wieder eingelötet, die geht auch noch (per Labornetzteil) und ist nicht verpolt. Ich hab mir grad mal einen neuen Optokoppler gekauft, aber mit dem geht es auch nicht. Kurzschließen an Pin 4-5 geht an der roten LED, also dem anderen Koppler, aber an dem für die grüne nicht :(
Gibt es noch etwas was ich versuchen kann?
Eine neue Platine oder einen Bausatz gibt es nicht mehr wenn ich den Sammelbestellungsthread richtig gelesen habe, oder?
Danke & VG
Kalle
Poste doch bitte mal ein paar Bilder von der fertig gelöteten Platine (Ober- Unterseite etc.)
Gesendet von iPhone mit Tapatalk Pro
OK, anbei.. ein größer Löter bin ich nicht wie man sieht.. bisher hats halt gereicht. Lötzinn ist auf jeden Fall verbleit.
Ein paar Stellen habe ich auf Verdacht schon mal nachgelötet - siehst du noch etwas wo ich das sinnvollerweise (noch mal) tun sollte?
Danke!
Danke, die Bauteile sind soweit ich sehen kann richtig platziert, jedoch an einigen Stellen unsauber gelötet.
Nur zur Sicherheit, könntest Du bitte sicherstellen/prüfen bzw. nachschauen, ob der BC337 an Q1 und 78L05 an IC2 verbaut ist, ich kann das leider auf den Bildern nicht erkennen.
Leider ist eine Ferndiagnose etwas schwierig, weshalb Du ein paar Messungen (Bei der Messung darf Platine nicht auf dem RPI aufgesteckt sein) durchführen musst, nicht zuletzt wegen den etwas unsauberen Lötstellen.
Ich hänge dir mal ein Bild an auf dem die entsprechenden Stellen eingezeichnet sind, welche aus meiner Sicht relevant sind und mit einem Multimeter (im Diodenprüfmodus ) geprüft werden müssten, um sicher zu stellen, dass die Bauteile miteinander sauber/richtig verbunden sind.
Noch ein Hinweis: Messe bitte an dem OK1 auf den entsprechenden Beinchen selbst und nicht an den Lötstellen.
Ähm, dumme Frage, sind die Werte im Diodenprüfmodus wichtig oder egal? habe z.T. 0Vdc und zum Teil etwas höhere Werte.
Auf jeden Fall keinen Wert bekomme ich bei der roten und bei der untersten orangenen Verbindung (also die zur Steckleiste).
Kann man damit den Fehler eingrenzen?
Danke noch mal für den Support!
Wenn du die beiden Messspitzen zusammenhältst, dann ist das der Wert den Du beim Messen auch haben musst (i.d.R 0=gut 0<> schlecht(keine Verbindung) - was davon abweicht ist nicht gut und muss überprüft werden.
Ok, ich habe versucht die Problemstellen nachzulöten.. nicht so richtig erfolgreich.
- Ist der rote Pfeil zur grünen LED eigentlich für den Minus-Pol gedacht? So sieht es aus aber da habe ich keine Verbindung. Am Pluspol habe ich aber Verbindung (also roter+gründer Pfeil, sprich R2 und OK1)
- R5 Verbindung zur Steckleiste 5. Pin von unten linke Seite (rosa Pfeil) geht, R5 zur Steckleiste 5. Pin von oben rechts (orangener Pfeil) geht nicht, auch nach ent- und nachlöten vom Steckleistenpin. Gibt es da noch etwas was man versuchen kann?
Danke mal wieder :)
Zitat von: kalled am 11 März 2019, 15:17:11
- Ist der rote Pfeil zur grünen LED eigentlich für den Minus-Pol gedacht? So sieht es aus aber da habe ich keine Verbindung.
Nein, der rote Pfeil ist nicht der Plus-Pol, der liegt an dem anderen Beinchen (3,3V kommen über den Widerstand R2).
Zitat von: kalled am 11 März 2019, 15:17:11
Am Pluspol habe ich aber Verbindung (also roter+gründer Pfeil, sprich R2 und OK1)
Das verstehe ich nicht - R2 und OK1 haben keine Verbindung und dürfen auch nicht miteinander verbunden sein, aber vielleicht verstehe ich noch nicht was Du genau meinst.
Es ist aber erst einmal nicht wichtig - wichtig ist die eingezeichneten Messpunkte zu messen und systematisch vorzugehen, sonst kommen wir schnell durcheinander. ;o) Schreib doch bitte, welche Messpunkte (Nummer - siehe Anhang) "ok" bzw. "nicht ok" sind.
Zitat von: kalled am 11 März 2019, 15:17:11
R5 zur Steckleiste 5. Pin von oben rechts (orangener Pfeil) geht nicht, auch nach ent- und nachlöten vom Steckleistenpin. Gibt es da noch etwas was man versuchen kann?
Das ist schlecht, denn dann können keine 3,3V am Widerstand anliegen. Kannst Du bitte an dieser Stelle erneut messen, aber diesmal am Beinchen vom Widerstand und an dem Pin der Steckerleiste.
Wenn das alles nicht funktioniert, dann kannst Du über eine Drahtbrücke (Kabel) den Widerstand mit dem Pin1 der Steckerleiste (siehe GPIO RPI (https://www.elektronik-kompendium.de/sites/raspberry-pi/1907101.htm)) verbinden/anlöten.
Aber, ich würde damit erst einmal warten bis die Messung komplett und transparent ist. ;)
Nummeriung ist ne gute Idee! :)
Also Nr.1 geht nicht, nach sauberem neu-löten der LED passen alle anderen. Aber: R2 und OK1 haben tatsächlich eine (nicht sehr gute) Verbindung. Also Wert von ~0,1Vdc - kann das sein?
Eine Brücke zu PIN1 habe ich mal rangemacht.. die LED geht immer noch nicht von alleine an, allerdings beim kurzschließen von PIN4+5 am OK1 jetzt neuerdings schon. Aber eigentlich soll sie ja ohne Signal immer blinke wenn ich richtig gelesen habe.
Schwierig das ganze :(
Ich habe einmal in die Pläne geschaut und mir ist da noch ein kleiner Fehler unterlaufen. Messung Punkt 2 ist natürlich Blödsinn - da können/und sollen keine 3,3V anlegen, sonst hätten wir einen Kurzschluss auf dem RX Pin.
Kannst Du bitte noch eine Messung am RX Pin zum R11 durchführen. (siehe Anhang).
Also die Messung ist top.
Noch eine Idee?
Bisher passen alle Messungen außer Nr.1 und dafür habe ich jetzt eine Drahtbrücke von R5 zu Pin1.
Danke nochmal für die Mühe!
Zitat von: kalled am 11 März 2019, 17:05:11
Eine Brücke zu PIN1 habe ich mal rangemacht.. die LED geht immer noch nicht von alleine an, allerdings beim kurzschließen von PIN4+5 am OK1 jetzt neuerdings schon. Aber eigentlich soll sie ja ohne Signal immer blinke wenn ich richtig gelesen habe.
Grüne LED leuchtet wenn am Bus ein "LOW" Signal erkannt wird. Wenn der Bus NICHT angeschlossen ist (offener Eingang), dann leuchtet die LED permanent.
Zitat von: kalled am 13 März 2019, 15:36:24
Noch eine Idee?
Bis Du dir sicher, dass dein ttyebus richtig läuft (insbesondere, dass es keine Kollisionen mit /dev/ttyAMA0 gibt.)?
Zitat von: chons am 16 März 2019, 17:43:42
Grüne LED leuchtet wenn am Bus ein "LOW" Signal erkannt wird. Wenn der Bus NICHT angeschlossen ist (offener Eingang), dann leuchtet die LED permanent.
Theoretisch ja, bei mir leider nicht.. bei mir: Leuchtet nie, auch nicht ohne das der Bus angeschlossen ist, außer: Wenn ich per schraubenzieher Pin 5+6 kurzschließe.
Zitat von: chons am 16 März 2019, 17:43:42
Bis Du dir sicher, dass dein ttyebus richtig läuft (insbesondere, dass es keine Kollisionen mit /dev/ttyAMA0 gibt.)?
Schon ziemlich sicher. Bin genau nach Anleitung vorgegangen, ttyAMA0 gibts nicht (mehr), ttyebus aber schon und ebusd.log sagt auch dass er kurz mal ein Signal bekommt (aber gleich wieder verliert).
Vielleicht hab ich beim Löten ein bisschen zu viel kaputt gemacht. Habe jetzt noch ein paar Teile zum Test-tauschen bei Reichelt bestellt, wenn das nix hilft und keiner mehr eine gute Idee für mich hat, schau ich dass ich sobald neue Platinen kommen (ich weiß, das ist nicht kurzdfristig angekündigt) einen neuen Versuch starte.
Nur zur Sicherheit: Die Drahtbrücke wie im Bild war schon richtig bzw. wie vorgeschlagen, oder?
Hallo kalled,
Wenn du möchtest und das Porto (Österreich!) nicht scheust, dann kannst du mir die Platine schicken und ich schau sie mir an.
Schreib mir einfach eine PN.
LG
Prima danke, mach ich!
Hallo,
nach Eingabe von ebusctl i wird mir folgendes angezeigt:
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
Wie und wann wird das updaten durchgeführt?
Muss ich das selber anstoßen?
Nachdem ich den ebusd Service einmal gestopt habe und etwas später neu gestartet habe,
wird mir nach Eingabe von ebusctl i jetzt kein Update mehr angezeigt.
Ist das richtig so?
Ich habe im Forum leider nichts dazu finden können!
Zitat von: Peter0961 am 24 März 2019, 21:02:30
Wie und wann wird das updaten durchgeführt?
Muss ich das selber anstoßen?
Nachdem ich den ebusd Service einmal gestopt habe und etwas später neu gestartet habe,
wird mir nach Eingabe von ebusctl i jetzt kein Update mehr angezeigt.
das Update erfolgt nach Neustart von ebusd bzw. durch Absetzen von "reload".
Allerdings gibt es jetzt eine Übergangsphase durch https://github.com/john30/ebusd/issues/266, in der teilweise alle Definitionen als different angesehen werden.
Das dauert dann an bis der webservice aktualisiert ist. Damit wollte ich noch warten, bis das nächste ebusd Release kommt.
Hallo kalled,
Ich habe deinen Print zum Leben erwecken können. Hier ein kleiner Reparaturbericht:
Die Bauteile waren alle noch in Ordnung, aber auf der Platine hat es zwei kalte Lötstellen und einen Kurzschluss gegeben. Alle im Rx Pfad und deswegen hat die grüne LED nie geleuchtet und der Host konnte auch keine Signale empfangen.
1. Kurzschluss zwischen Pin 1 und 2 des OK1 (CNY17-4)
Auf dem Foto (1) kann man die Ursache sehen: zwischen den beiden Pins befindet sich ein feiner Kupferfaden. Ich vermute, der stammt von einer abgelösten Leiterbahn ??
Auf dem Foto (2) kann man noch so ein Phänomen erkennen: dort hängt auch ein Kupferfaden vom Pin weg. Der hat allerdings keinen Schaden angerichtet.
2. Kalte Lötstelle am Pin 4 des OK1.
Das ist die Ground-Verbindung für den Opto-Koppler.
Auf dem Bild (3) kann man erkennen, dass das Bein des Chips an der Oberfläche nicht mit dem Lötauge verbunden ist.
Obwohl die Unterseite gut verlötet war, war offensichtlich die Durchkontaktierung so beschädigt, dass die Leiterbahn auf der Oberseite keine Verbindung zu dem Chip mehr hatte.
3. Kalte Lötstelle am Pin 17 des RPIGPIO
Das ist die 3,3V Versorgung vom Raspi zur Schaltung.
Auf dem Foto (4) kann man erkennen, dass das obere Lötauge fehlt und die Messung hat gezeigt, dass auch die Durchkontaktierung nicht mehr funktioniert.
Da die Verbindung zur Schaltung aber auf der Unterseite des Prints erfolgt und diese vom Stecker verdeckt wird, blieb mir nichts anderes übrig, als eine Drahtbrücke aufzulöten (Bild (5)).
Mit diesem Schönheitsfehler wirst du leben müssen :-\
Ich möchte jetzt nicht dozieren, aber vielleicht einen Tip für's nächste Projekt abgeben:
Mir scheint, dass du mit einem falschen Lötkolben arbeitest oder diesen falsch verwendest. Die Lötstellen hatten entweder zu wenig Temperatur oder du hast den Lötkolben zu kurz drangehalten.
Richtig wäre:
1. Lötkolben auf das Lötauge und gleichzeitig möglichst nahe an den Draht zu halten.
2. Den Lötdraht auf die Lötspitze(!) aufbringen, möglichst nahe am Draht.
3. Das Lötzinn beginnt nun an der heißen Spitze zu schmelzen und rinnt auf das Lötauge und dann auf den Draht. Weiter Lötzinn nachgeben bis genügend Material auf dem Lötauge ist.
Das muss nun aussehen wie ein Vulkan, in dessen Krater ein Draht hervorkommt. Dann ist alles gut geflossen. Wenn es aussieht wie eine aufgespießte Melone, dann war etwas falsch.
Die Temperatur, das Lötzinn (Flußmittel ?) oder die Zeit die der Lötkolben geheizt hat.
4. Das ist übrigens der nächste Punkt: Keine Angst, den Lötkolben für 1-2 Sekunden auf dem Lötauge zu lassen (ohne Zinn-Nachschub).
Die Bauteile halten das bedenkenlos aus und das Zinn erhält dadurch die Möglichkeit und die Zeit, zu fließen...
Keinesfalls darfst du den Lötkolben dazu verwenden um durch Bewegen (,,Kratzen am Untergrund") ein Verfließen zu erzwingen.
Ich habe nämlich den dringenden Verdacht, dass die Kupferfäden auf deinem Print dadurch entstanden sind ???
Dein Print ist heute an dich retour gegangen. Ich wünsch dir viel Erfolg damit, jetzt kommen ja erst einmal die Software-Probleme ;D
LG Eduard
Hallo Eduard,
Die Platine ist angekommen und hat auch sofort funktioniert, softwareseitig hab ichs zum Glück nicht verbockt :)
Vielen vielen Dank für deine Mühen!!
Ich werd mir dann jetzt mal Gedanken zur Visualisierung machen und zum richtig löten lernen was kleines suchen.
Vielen Dank nochmal & LG
Kalle
Zitat von: john30 am 26 März 2019, 07:24:12
das Update erfolgt nach Neustart von ebusd bzw. durch Absetzen von "reload".
Allerdings gibt es jetzt eine Übergangsphase durch https://github.com/john30/ebusd/issues/266, in der teilweise alle Definitionen als different angesehen werden.
Das dauert dann an bis der webservice aktualisiert ist. Damit wollte ich noch warten, bis das nächste ebusd Release kommt.
Hallo!
Mir ist jetzt aufgefallen das er mir das Update erneut anzeigt, trotz Stop und Neustart der ebusd!
Hat sich dann wohl nicht upgedatet!
Wie ist das mit dem absetzen von "reload" gemeint?
Das ist mir nicht klar?
Freue mich über jeden Hinweis!
Gruß Peter
ZitatMir ist jetzt aufgefallen das er mir das Update erneut anzeigt, trotz Stop und Neustart der ebusd!
Schau mal hier.
https://forum.fhem.de/index.php/topic,79600.msg907944.html#msg907944 (https://forum.fhem.de/index.php/topic,79600.msg907944.html#msg907944)
Zitat von: majorshark am 04 April 2019, 14:14:42
Schau mal hier.
https://forum.fhem.de/index.php/topic,79600.msg907944.html#msg907944 (https://forum.fhem.de/index.php/topic,79600.msg907944.html#msg907944)
Ah, ok! Danke!
Das hatte ich noch nicht gelesen!
Hello,
I've just assembled the 2.2 version of the eBus Adapter and connected it to a Vaillant VC 246/3-5. When running ebusd, I get the following output:
From what I've read on the ebusd github, this would indicate that the adapter cannot write to the bus. Have I done something wrong? Is some tweaking required?
I have attached a photo of the assembled board on top of a Raspberry Pi 1B.
Thanks,
Jan
root@ebus:~# ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d /dev/ttyAMA0
2019-04-05 07:57:50.867 [main notice] ebusd 3.3.v3.3 started with full scan
2019-04-05 07:57:51.246 [bus notice] bus started with own address 31/36
2019-04-05 07:57:51.294 [bus notice] signal acquired
2019-04-05 07:57:51.337 [bus notice] <00
2019-04-05 07:57:51.899 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:57:57.921 [bus notice] new master 10, master count 2
2019-04-05 07:57:58.004 [bus notice] <1008b51101018900093c3c700bff580000ff6e00
2019-04-05 07:58:00.034 [bus notice] <1008b50401003d000a00562111ffffffff700bf900
2019-04-05 07:58:00.257 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 07:58:00.258 [bus notice] <10feb5050204000b
2019-04-05 07:58:01.247 [main notice] starting initial full scan
2019-04-05 07:58:01.309 [bus notice] >31
2019-04-05 07:58:01.355 [bus notice] >31
2019-04-05 07:58:01.400 [bus notice] >31
2019-04-05 07:58:01.446 [bus notice] >31
2019-04-05 07:58:01.490 [bus notice] >31
2019-04-05 07:58:01.534 [bus notice] >31
2019-04-05 07:58:01.582 [bus notice] >31
2019-04-05 07:58:01.628 [bus notice] >31
2019-04-05 07:58:01.672 [bus notice] >31
2019-04-05 07:58:01.716 [bus notice] >31
2019-04-05 07:58:01.765 [bus notice] >31
2019-04-05 07:58:01.814 [bus notice] >31
2019-04-05 07:58:01.860 [bus notice] >31
2019-04-05 07:58:01.905 [bus notice] >31
2019-04-05 07:58:01.949 [bus notice] >31
2019-04-05 07:58:01.994 [bus notice] >31
2019-04-05 07:58:02.039 [bus notice] >31
2019-04-05 07:58:02.085 [bus notice] >31
2019-04-05 07:58:02.130 [bus notice] >31
2019-04-05 07:58:02.174 [bus notice] >31
2019-04-05 07:58:02.219 [bus notice] >31
2019-04-05 07:58:02.266 [bus notice] >31
2019-04-05 07:58:02.312 [bus notice] >31
2019-04-05 07:58:02.356 [bus notice] >31
2019-04-05 07:58:02.400 [bus notice] >31
2019-04-05 07:58:02.447 [bus notice] >31
2019-04-05 07:58:02.492 [bus notice] >31
2019-04-05 07:58:02.537 [bus notice] >31
2019-04-05 07:58:02.581 [bus notice] >31
2019-04-05 07:58:02.626 [bus notice] >31
2019-04-05 07:58:02.671 [bus notice] >31
2019-04-05 07:58:02.716 [bus notice] >31
2019-04-05 07:58:02.763 [bus notice] >31
2019-04-05 07:58:02.806 [bus notice] >31
2019-04-05 07:58:02.852 [bus notice] >31
2019-04-05 07:58:02.897 [bus notice] >31
2019-04-05 07:58:02.944 [bus notice] >31
2019-04-05 07:58:02.988 [bus notice] >31
2019-04-05 07:58:03.032 [bus notice] >31
2019-04-05 07:58:03.079 [bus notice] >31
2019-04-05 07:58:03.126 [bus notice] >31
2019-04-05 07:58:03.171 [bus notice] >31
2019-04-05 07:58:03.217 [bus notice] >31
2019-04-05 07:58:03.261 [bus notice] >31
2019-04-05 07:58:03.306 [bus notice] >31
2019-04-05 07:58:03.351 [bus notice] >31
2019-04-05 07:58:03.396 [bus notice] >31
2019-04-05 07:58:03.441 [bus notice] >31
2019-04-05 07:58:03.486 [bus notice] >31
2019-04-05 07:58:03.530 [bus notice] >31
2019-04-05 07:58:03.575 [bus notice] >31
2019-04-05 07:58:03.622 [bus notice] >31
2019-04-05 07:58:03.668 [bus notice] >31
2019-04-05 07:58:03.714 [bus notice] >31
2019-04-05 07:58:03.759 [bus notice] >31
2019-04-05 07:58:03.808 [bus notice] >31
2019-04-05 07:58:03.858 [bus notice] >31
2019-04-05 07:58:03.902 [bus notice] >31
2019-04-05 07:58:03.947 [bus notice] >31
2019-04-05 07:58:03.992 [bus notice] >31
2019-04-05 07:58:04.036 [bus notice] >31
2019-04-05 07:58:04.082 [bus notice] >31
2019-04-05 07:58:04.127 [bus notice] >31
2019-04-05 07:58:04.171 [bus notice] >31
2019-04-05 07:58:04.216 [bus notice] >31
2019-04-05 07:58:04.261 [bus notice] >31
2019-04-05 07:58:04.307 [bus notice] >31
2019-04-05 07:58:04.352 [bus notice] >31
2019-04-05 07:58:04.398 [bus notice] >31
2019-04-05 07:58:04.443 [bus notice] >31
2019-04-05 07:58:04.491 [bus notice] >31
2019-04-05 07:58:04.538 [bus notice] >31
2019-04-05 07:58:04.582 [bus notice] >31
2019-04-05 07:58:04.627 [bus notice] >31
2019-04-05 07:58:04.674 [bus notice] >31
2019-04-05 07:58:04.720 [bus notice] >31
2019-04-05 07:58:04.764 [bus notice] >31
2019-04-05 07:58:04.808 [bus notice] >31
2019-04-05 07:58:04.854 [bus notice] >31
2019-04-05 07:58:04.898 [bus notice] >31
2019-04-05 07:58:04.943 [bus notice] >31
2019-04-05 07:58:04.989 [bus notice] >31
2019-04-05 07:58:05.032 [bus notice] >31
2019-04-05 07:58:05.078 [bus notice] >31
2019-04-05 07:58:05.123 [bus notice] >31
2019-04-05 07:58:05.169 [bus notice] >31
2019-04-05 07:58:05.215 [bus notice] >31
2019-04-05 07:58:05.262 [bus notice] >31
2019-04-05 07:58:05.306 [bus notice] >31
2019-04-05 07:58:05.352 [bus notice] >31
2019-04-05 07:58:05.396 [bus notice] >31
2019-04-05 07:58:05.440 [bus notice] >31
2019-04-05 07:58:05.487 [bus notice] >31
2019-04-05 07:58:05.532 [bus notice] >31
2019-04-05 07:58:05.577 [bus notice] >31
2019-04-05 07:58:05.621 [bus notice] >31
2019-04-05 07:58:05.669 [bus notice] >31
2019-04-05 07:58:05.713 [bus notice] >31
2019-04-05 07:58:05.759 [bus notice] >31
2019-04-05 07:58:05.803 [bus notice] >31
2019-04-05 07:58:05.851 [bus notice] >31
2019-04-05 07:58:05.898 [bus notice] >31
2019-04-05 07:58:05.944 [bus notice] >31
2019-04-05 07:58:05.989 [bus notice] >31
2019-04-05 07:58:06.032 [bus notice] >31
2019-04-05 07:58:06.078 [bus notice] >31
2019-04-05 07:58:06.124 [bus notice] >31
2019-04-05 07:58:06.169 [bus notice] >31
2019-04-05 07:58:06.214 [bus notice] >31
2019-04-05 07:58:06.258 [bus notice] >31
2019-04-05 07:58:06.304 [bus notice] >31
2019-04-05 07:58:06.351 [bus notice] >31
2019-04-05 07:58:06.396 [bus notice] >31
2019-04-05 07:58:06.439 [bus notice] >31
2019-04-05 07:58:06.485 [bus notice] >31
2019-04-05 07:58:06.532 [bus notice] >31
2019-04-05 07:58:06.579 [bus notice] >31
2019-04-05 07:58:06.627 [bus notice] >31
2019-04-05 07:58:06.673 [bus notice] >31
2019-04-05 07:58:06.717 [bus notice] >31
2019-04-05 07:58:06.762 [bus notice] >31
2019-04-05 07:58:06.807 [bus notice] >31
2019-04-05 07:58:06.851 [bus notice] >31
2019-04-05 07:58:06.897 [bus notice] >31
2019-04-05 07:58:06.944 [bus notice] >31
2019-04-05 07:58:06.988 [bus notice] >31
2019-04-05 07:58:07.036 [bus notice] >31
2019-04-05 07:58:07.080 [bus notice] >31
2019-04-05 07:58:07.124 [bus notice] >31
2019-04-05 07:58:07.171 [bus notice] >31
2019-04-05 07:58:07.218 [bus notice] >31
2019-04-05 07:58:07.264 [bus notice] >31
2019-04-05 07:58:07.309 [bus notice] >31
2019-04-05 07:58:07.353 [bus notice] >31
2019-04-05 07:58:07.398 [bus notice] >31
2019-04-05 07:58:07.443 [bus notice] >31
2019-04-05 07:58:07.487 [bus notice] >31
2019-04-05 07:58:07.532 [bus notice] >31
2019-04-05 07:58:07.578 [bus notice] >31
2019-04-05 07:58:07.623 [bus notice] >31
2019-04-05 07:58:07.669 [bus notice] >31
2019-04-05 07:58:07.716 [bus notice] >31
2019-04-05 07:58:07.760 [bus notice] >31
2019-04-05 07:58:07.805 [bus notice] >31
2019-04-05 07:58:07.851 [bus notice] >31
2019-04-05 07:58:07.899 [bus notice] >31
2019-04-05 07:58:07.946 [bus notice] >31
2019-04-05 07:58:07.991 [bus notice] >31
2019-04-05 07:58:08.037 [bus notice] >31
2019-04-05 07:58:08.082 [bus notice] >31
2019-04-05 07:58:08.126 [bus notice] >31
2019-04-05 07:58:08.171 [bus notice] >31
2019-04-05 07:58:08.215 [bus notice] >31
2019-04-05 07:58:08.260 [bus notice] >31
2019-04-05 07:58:08.305 [bus notice] >31
2019-04-05 07:58:08.350 [bus notice] >31
2019-04-05 07:58:08.397 [bus notice] >31
2019-04-05 07:58:08.444 [bus notice] >31
2019-04-05 07:58:08.488 [bus notice] >31
2019-04-05 07:58:08.532 [bus notice] >31
2019-04-05 07:58:08.587 [bus notice] >31
2019-04-05 07:58:08.632 [bus notice] >31
2019-04-05 07:58:08.677 [bus notice] >31
2019-04-05 07:58:08.721 [bus notice] >31
2019-04-05 07:58:08.767 [bus notice] >31
2019-04-05 07:58:08.812 [bus notice] >31
2019-04-05 07:58:08.855 [bus notice] >31
2019-04-05 07:58:08.900 [bus notice] >31
2019-04-05 07:58:08.946 [bus notice] >31
2019-04-05 07:58:08.990 [bus notice] >31
2019-04-05 07:58:09.036 [bus notice] >31
2019-04-05 07:58:09.082 [bus notice] >31
2019-04-05 07:58:09.127 [bus notice] >31
2019-04-05 07:58:09.172 [bus notice] >31
2019-04-05 07:58:09.217 [bus notice] >31
2019-04-05 07:58:09.267 [bus notice] >31
2019-04-05 07:58:09.312 [bus notice] >31
2019-04-05 07:58:09.357 [bus notice] >31
2019-04-05 07:58:09.401 [bus notice] >31
2019-04-05 07:58:09.447 [bus notice] >31
2019-04-05 07:58:09.492 [bus notice] >31
2019-04-05 07:58:09.540 [bus notice] >31
2019-04-05 07:58:09.585 [bus notice] >31
2019-04-05 07:58:09.630 [bus notice] >31
2019-04-05 07:58:09.674 [bus notice] >31
2019-04-05 07:58:09.720 [bus notice] >31
2019-04-05 07:58:09.765 [bus notice] >31
2019-04-05 07:58:09.810 [bus notice] >31
2019-04-05 07:58:09.855 [bus notice] >31
2019-04-05 07:58:09.899 [bus notice] >31
2019-04-05 07:58:09.950 [bus notice] >31
2019-04-05 07:58:09.994 [bus notice] >31
2019-04-05 07:58:10.040 [bus notice] >31
2019-04-05 07:58:10.085 [bus notice] >31
2019-04-05 07:58:10.129 [bus notice] >31
2019-04-05 07:58:10.175 [bus notice] >31
2019-04-05 07:58:10.220 [bus notice] >31
2019-04-05 07:58:10.265 [bus notice] >31
2019-04-05 07:58:10.310 [bus notice] >31
2019-04-05 07:58:10.354 [bus notice] >31
2019-04-05 07:58:10.401 [bus notice] >31
2019-04-05 07:58:10.447 [bus notice] >31
2019-04-05 07:58:10.492 [bus notice] >31
2019-04-05 07:58:10.536 [bus notice] >31
2019-04-05 07:58:10.583 [bus notice] >31
2019-04-05 07:58:10.632 [bus notice] >31
2019-04-05 07:58:10.676 [bus notice] >31
2019-04-05 07:58:10.721 [bus notice] >31
2019-04-05 07:58:10.765 [bus notice] >31
2019-04-05 07:58:10.810 [bus notice] >31
2019-04-05 07:58:10.855 [bus notice] >31
2019-04-05 07:58:10.900 [bus notice] >31
2019-04-05 07:58:10.945 [bus notice] >31
2019-04-05 07:58:10.990 [bus notice] >31
2019-04-05 07:58:11.034 [bus notice] >31
2019-04-05 07:58:11.082 [bus notice] >31
2019-04-05 07:58:11.127 [bus notice] >31
2019-04-05 07:58:11.172 [bus notice] >31
2019-04-05 07:58:11.216 [bus notice] >31
2019-04-05 07:58:11.261 [bus notice] >31
2019-04-05 07:58:11.310 [bus notice] >31
2019-04-05 07:58:11.321 [main error] scan config 15: ERR: read timeout
2019-04-05 07:58:11.354 [bus notice] >31
2019-04-05 07:58:11.400 [bus notice] >31
2019-04-05 07:58:11.445 [bus notice] >31
2019-04-05 07:58:11.493 [bus notice] >31
2019-04-05 07:58:11.538 [bus notice] >31
2019-04-05 07:58:11.583 [bus notice] >31
2019-04-05 07:58:11.627 [bus notice] >31
2019-04-05 07:58:11.672 [bus notice] >31
2019-04-05 07:58:22.227 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:58:22.459 [bus notice] <10feb516080038161506040619b2
2019-04-05 07:58:22.764 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:58:23.057 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:58:26.478 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:58:28.538 [bus notice] <1008b50401003d000a00252211ffffffff400b5700
2019-04-05 07:58:28.788 [bus notice] new master 03, master count 3
2019-04-05 07:58:28.790 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 07:58:28.805 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 07:58:30.593 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:58:33.376 [main error] scan config 08: ERR: read timeout
2019-04-05 07:58:33.411 [bus notice] >31
2019-04-05 07:58:36.660 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:58:38.666 [bus notice] <10feb5160301400b1f
2019-04-05 07:58:40.772 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:58:46.880 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:58:48.863 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 07:58:48.880 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 07:58:50.948 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:58:55.005 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:58:57.068 [bus notice] <1008b50401003d000a00542211ffffffff400bef00
2019-04-05 07:58:57.290 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 07:58:57.291 [bus notice] <10feb5050204000b
2019-04-05 07:59:01.126 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:59:04.254 [bus notice] <0364b5120202fe98
2019-04-05 07:59:05.180 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:59:09.542 [bus notice] <0364b5120202fe98
2019-04-05 07:59:11.284 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:59:14.903 [bus notice] <0364b5120202fe98
2019-04-05 07:59:15.376 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:59:17.386 [bus notice] <10feb51608003717150604061916
2019-04-05 07:59:20.211 [bus notice] <0364b5120202fe98
2019-04-05 07:59:21.495 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:59:25.560 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:59:27.573 [bus notice] <1008b50401003d000a00262311ffffffff400bbd00
2019-04-05 07:59:27.839 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 07:59:29.630 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:59:35.729 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:59:37.735 [bus notice] <10feb5160301400b1f
2019-04-05 07:59:39.800 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:59:45.909 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:59:47.947 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 07:59:50.007 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 07:59:54.070 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 07:59:56.133 [bus notice] <1008b50401003d000a00552311ffffffff400ba400
2019-04-05 07:59:56.354 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 07:59:56.356 [bus notice] <10feb5050204000b
2019-04-05 08:00:00.184 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:00:04.242 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 08:00:10.333 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:00:14.434 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 08:00:16.439 [bus notice] <10feb51608003618150604061922
2019-04-05 08:00:18.508 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:00:24.622 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 08:00:26.639 [bus notice] <1008b50401003d000a00272411ffffffff400baf00
2019-04-05 08:00:26.890 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:00:26.907 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:00:28.695 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:00:34.823 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 08:00:35.586 [main notice] update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
2019-04-05 08:00:36.783 [bus notice] <10feb5160301400b1f
2019-04-05 08:00:38.886 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:00:42.935 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 08:00:44.969 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:00:44.986 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:00:49.050 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:00:53.112 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 08:00:55.169 [bus notice] <1008b50401003d000a00562411ffffffff400b1700
2019-04-05 08:00:55.388 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 08:00:55.390 [bus notice] <10feb5050204000b
2019-04-05 08:00:59.215 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:01:03.325 [bus notice] <1008b51101018900093c3c400bff580000ff2c00
2019-04-05 08:01:09.426 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:01:13.481 [bus notice] <1008b51101018900093c3a400bff580000ff7500
2019-04-05 08:01:15.492 [bus notice] <10feb5160800351915060406195b
2019-04-05 08:01:17.563 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:01:23.665 [bus notice] <1008b51101018900093c3a400bff580000ff7500
2019-04-05 08:01:25.688 [bus notice] <1008b50401003d000a00272511ffffffff400b7900
2019-04-05 08:01:25.960 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:01:27.745 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:01:33.867 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:01:35.827 [bus notice] <10feb5160301400b1f
2019-04-05 08:01:37.936 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:01:42.007 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:01:44.003 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:01:48.124 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:01:52.177 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:01:54.205 [bus notice] <1008b50401003d000a00572511ffffffff400b5c00
2019-04-05 08:01:54.429 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 08:01:54.430 [bus notice] <10feb5050204000b
2019-04-05 08:01:58.303 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:02:02.371 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:02:06.433 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:02:12.531 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:02:14.538 [bus notice] <10feb516080034201506040619f3
2019-04-05 08:02:16.600 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:02:22.718 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:02:24.784 [bus notice] <1008b50401003d000a00282611ffffffff400b5400
2019-04-05 08:02:25.042 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:02:25.059 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:02:26.794 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:02:30.856 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:02:32.863 [bus notice] <10feb5160301400b1f
2019-04-05 08:02:36.970 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:02:41.040 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:02:43.062 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:02:43.079 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:02:47.181 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:02:51.248 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:02:53.268 [bus notice] <1008b50401003d000a00582611ffffffff400b7100
2019-04-05 08:02:53.498 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 08:02:53.500 [bus notice] <10feb5050204000b
2019-04-05 08:02:57.327 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:03:01.432 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:03:05.493 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:03:11.601 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:03:13.606 [bus notice] <10feb51608003321150604061948
2019-04-05 08:03:15.679 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:03:21.780 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:03:23.806 [bus notice] <1008b50401003d000a00292711ffffffff400b1f00
2019-04-05 08:03:24.060 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:03:24.077 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:03:25.867 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:03:29.926 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:03:31.878 [bus notice] <10feb5160301400b1f
2019-04-05 08:03:36.032 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:03:40.106 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:03:42.084 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:03:42.101 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:03:46.210 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:03:50.278 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:03:52.301 [bus notice] <1008b50401003d000a00582711ffffffff000b6f00
2019-04-05 08:03:52.527 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 08:03:52.529 [bus notice] <10feb5050204000b
2019-04-05 08:03:54.361 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:04:00.467 [bus notice] <1008b51101018900093a3a400bff580000ff0d00
2019-04-05 08:04:04.525 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:04:10.625 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:04:12.679 [bus notice] <10feb51608003222150604061901
2019-04-05 08:04:14.709 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:04:18.785 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:04:20.847 [bus notice] <1008b50401003d000a00282811ffffffff000b1900
2019-04-05 08:04:21.119 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:04:24.906 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:04:28.960 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:04:29.907 [bus notice] <0364b5120202fe98
2019-04-05 08:04:30.957 [bus notice] <10feb5160301000bd7
2019-04-05 08:04:35.203 [bus notice] <0364b5120202fe98
2019-04-05 08:04:35.287 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:04:39.173 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:04:40.532 [bus notice] <0364b5120202fe98
2019-04-05 08:04:41.154 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:04:41.171 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:04:45.286 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:04:45.870 [bus notice] <0364b5120202fe98
2019-04-05 08:04:49.336 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:04:51.357 [bus notice] <1008b50401003d000a00592811ffffffff000ba100
2019-04-05 08:04:51.579 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 08:04:51.581 [bus notice] <10feb5050204000b
2019-04-05 08:04:53.415 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:04:59.533 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:05:03.599 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:05:09.705 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:05:11.713 [bus notice] <10feb51608003123150604061978
2019-04-05 08:05:13.785 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:05:17.857 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:05:19.881 [bus notice] <1008b50401003d000a00292911ffffffff000b5200
2019-04-05 08:05:20.133 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:05:20.150 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:05:23.945 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:05:28.006 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:05:30.008 [bus notice] <10feb5160301000bd7
2019-04-05 08:05:34.157 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:05:38.215 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:05:40.205 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:05:40.222 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:05:42.283 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:05:48.387 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:05:50.451 [bus notice] <1008b50401003d000a00003011ffffffff000b6b00
2019-04-05 08:05:50.671 [update notice] received unknown BC cmd: 10feb505020400
2019-04-05 08:05:50.672 [bus notice] <10feb5050204000b
2019-04-05 08:05:52.464 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:05:58.573 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:06:02.647 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:06:06.711 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:06:08.720 [bus notice] <10feb516080028241506040619b2
2019-04-05 08:06:12.833 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:06:16.895 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:06:18.919 [bus notice] <1008b50401003d000a00293011ffffffff000b7b00
2019-04-05 08:06:19.173 [update notice] received unknown MS cmd: 1008b5110102 / 05033c58505a
2019-04-05 08:06:19.190 [bus notice] <1008b51101028a0005033c58505a9700
2019-04-05 08:06:23.034 [bus notice] <1008b510090000005affff05ff00bb0001019a00
2019-04-05 08:06:27.093 [bus notice] <1008b51101018900093a3a000bff580000fff500
2019-04-05 08:06:29.052 [bus notice] <10feb5160301000bd7
2019-04-05 08:06:33.206 [bus notice] <1008b510090000005affff05ff00bb0001019a00
Zitat von: jasiek83 am 06 April 2019, 22:41:07
From what I've read on the ebusd github, this would indicate that the adapter cannot write to the bus. Have I done something wrong? Is some tweaking required?
yes, you're adapter is not able to send aynthing.
maybe go and look for the soldering on the optocouplers. One of the is responsible for the sending part and if not soldered correctly, this might be the reason.
Also the transistor connected to the Z-diode might be the issue, just check the soldering there for a start.
I've soldered them at 320 deg C - perhaps that is the problem. I'll order replacements and see where that takes me.
Zitat
I've soldered them at 320 deg C - perhaps that is the problem. I'll order replacements and see where that takes me.
Save that money and send this print to me. I will try to repair it.
Send me a PM if you agree
Regards,
Eduard
Zitat von: Reinhart am 28 Dezember 2018, 20:39:58
irgend etwas muss bei deinem PI anders sein als bei meinem Pi 3.
Lies einmal hier (https://dreamshader.bplaced.net/wordpress/2016/08/25/aktivieren-der-seriellen-schnittstelle-des-raspberry-pi/), 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
Vielen Dank für deine Hilfe.
Das Problem lag daran, dass ich berryboot genutzt habe, dies nutzt anscheinend einen modifizierten Kernel der das Problem ausgelöst hat.
Jetzt hat soweit alles funktioniert.
Leider erhalte ich nur folgende Meldung.
pi@raspberrypi:/$ sudo modinfo ttyebus
modinfo: ERROR: Module ttyebus not found.Kann man den Adapter testen, da ich ihn versucht habe ihn openhab einzubinden jedoch erhalte ich kein einziges package angezeigt.
Hallo,
ich hoffe ich bin im richtigen Tread...
ich habe anfang des Jahres die V2.2 für den Pi mit DC bekommen, und eigentlich auch ziemlich problemlos in Betrieb nehmen können...Vorher hatte ich so ein Ethernet Dingens mit Poti, wo ich eigentlich nie sauber alle Geräte hatte.
Nun mit diesem Adapter war ich echt Happy, dass endlich auch das Gerät bai gefunden wurde... Allerdings habe ich jetzt nach ein paar Monaten das Problem, dass bai (der Brenner ?) wieder nicht gefunden wird.. Wenn ich den ebusd neu starte, dann wird manchmal nach mehreren Versuchen doch noch bai gefunden...
Woran könnte das liegen ? Wie könnte ich irgendwas verbessern ?
Hier noch die Ausgabe von Info:
info
version: ebusd 3.3.v3.3
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.ui.csv: different version available, vaillant/25.solsy.hwc.csv: different version available, vaillant/26.solsy.hc.csv: different version available, vaillant/broadcast.csv: different version available, vaillant/ec.solsy.sc.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 25
max symbol rate: 99
min arbitration micros: 6
max arbitration micros: 32
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 3
messages: 536
conditional: 9
poll: 0
update: 9
address 03: master #11
address 08: slave #11
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0324;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
Gruß, Martin
Ich beantworte es mir mal selber...
Die Steuerung meines Brenners hat wohl einen Hau weg.... scheint bekannt zu sein, 2 Kondensatoren... F61
Kaum hab ich das Ding mal aufgemacht und am Bus-Stecker gewackelt geht alles wieder .. vorher kam : Com Fehler ..
Mal sehen, ob es dauerhaft ist.. kein Bock ne neue Platine zu kaufen.
Hi Leute,
nachdem meine Platine nun schon ein paar Monate lief, hat irgendwas heute früh den Geist aufgegeben.
Auf einen Schlag konnte ich keine Werte mehr aus meiner Heizung auslesen.
ebusctl info liefert folgendes:
version: ebusd 3.3.v3.3
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version 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
kein Signal...
Daraufhin hab ich nochmal alles gegengecheckt. AMA0 taucht bei ls -l /dev nicht auf... ttyebus hingegen schon.
Bei lsmod taucht ttyebus ebenfalls auf.
Wenn ich den ebusd dienst beende und den Sendetest mache, blinkt die rote LED auch einmal kurz auf.
Heizungsanlage sowie RPi habe ich schon neu gestartet. Die Verkabelung zwischen beiden ebenfalls überptüft.
FHEM zeigt mir das der ebus dienst opened ist.
Hat jemand noch eine Idee? Software - & hardwareseitig wurde nichts geändert. Wäre ein Hardwaredefekt denkbar?
EDIT:
Meine ebusd.log zeigt immer wieder diesen Eintrag
2019-06-04 20:30:16.878 [mqtt error] publish: The client is not currently connected.
Die grüne LED auf der Platine flackert so wie sie es immer tat.
Das gleiche Problem habe ich auch. Ich dachte es lag an updates meines Raspberry.
Aber ich habe auch immer "no signal"
gelbe LED leuchtet und grüne Blink. Also Signal vom Ebus hat die Platine. Nur ebusd bekommt nichts oder der ttyebus hat ne macke.
Zitat von: rande am 02 Juni 2019, 20:58:17
kein Signal...
Daraufhin hab ich nochmal alles gegengecheckt. AMA0 taucht bei ls -l /dev nicht auf... ttyebus hingegen schon.
Bei lsmod taucht ttyebus ebenfalls auf.
Wenn ich den ebusd dienst beende und den Sendetest mache, blinkt die rote LED auch einmal kurz auf.
Heizungsanlage sowie RPi habe ich schon neu gestartet. Die Verkabelung zwischen beiden ebenfalls überptüft.
hast du bzw. dein System evtl. vor kurzem ein kernel update o.ä. eingespielt?
Zitat von: rande am 02 Juni 2019, 20:58:17
2019-06-04 20:30:16.878 [mqtt error] publish: The client is not currently connected.
läuft denn dein mqtt broker?
Hi john30,
ein Update hatte ich tatsächlich durchgeführt mit apt-get update, apt-get upgrade (Kernelupdate via rpi-update hab ich definitiv nicht gemacht)... allerdings schon am Nachmittag des Vortags. Bis zum nächsten morgen lief ja alles noch, wie ich es auch meinen Logdateien und angelegten Graphen für Außentemperatur uns Speichertemperatur entnehmen kann.
Wie kann ich meinen mqtt-broker denn überprüfen?
Beste Grüße,
rande
gib doch einfach in der Raspberry Console "mosquitto_sub -d -v -t \#" ein.
Damit kannst du den gesamten MQTT Verkehr zum Broker mitverfolgen.
Wenn du schon MQTT2_Server verwendest, dann siehst du das im Event Monitor, dazu den Loglevel einfach auf 5 erhöhen.
LG
Hi Reinhart,
bei dem Befehl kam nur, das der Befehl bzw. das Kommando nicht gefunden wurde.
Daraufhin hab ich mosquitto & mosquitto-clients nochmal installiert. Anscheinend hatte ich die gar nicht drauf, da er alle Pakete runtergeladen hat. Ich kann mich auch nicht erinnern, dass ich mosquitto schonmal wissentlich installiert hatte.
Jedenfalls kommt jetzt bei Eingabe deines Befehls folgendes:
Error: Connection refused
Beste Grüße
Zitat von: rande am 08 Juni 2019, 21:21:44
Daraufhin hab ich mosquitto & mosquitto-clients nochmal installiert. Anscheinend hatte ich die gar nicht drauf, da er alle Pakete runtergeladen hat. Ich kann mich auch nicht erinnern, dass ich mosquitto schonmal wissentlich installiert hatte.
dann war der aber vorher auch nicht drauf, oder? hast du denn MQTT überhaupt genutzt? Falls nicht, kannst du die Meldung im ebusd.log einfach ignorieren.
Hi john30,
Nein, mosquitto habe ich nicht benutzt.
ich denke mal auch das ich mqtt vorher nicht drauf hatte.
Was könnte ich denn weiter zur Fehlersuche versuchen?
Wie gesagt... alles was ich bei der ersten Verwendung / Einrichtung installiert & konfiguriert habe, hab ich nochmals gemacht und gecheckt.
Mir fällt grad nichts mehr ein... :(
Gesendet von meinem TA-1012 mit Tapatalk
Zitat von: rande am 09 Juni 2019, 16:22:28
Was könnte ich denn weiter zur Fehlersuche versuchen?
ich vermute, dass dein System ein automatisches Update gemacht hat, bei dem die Kernel Version aktualisiert wurde. Damit wärst du schon der dritte im Bunde. Ich hab ein Ticket dafür aufgemacht, siehe hier: https://github.com/eBUS/ttyebus/issues/2
Für den Moment würde als schnelle Abhilfe m.E. nur ein Downgrade des Kernel helfen
Zitat von: john30
ich vermute, dass dein System ein automatisches Update gemacht hat, bei dem die Kernel Version aktualisiert wurde.
Hi john30,
scheint wirklich so zu sein. Ich habe grade mal meine Kernelversion mit uname -r gecheckt... 4.19.42-v7+
Also genau diese für die du das Ticket geöffnet hast.
Dann versuche ich mal ein downgrade und hoffe, das danach mein System noch läuft.
Grüße
EDIT: Mist, jetzt hab ich den Salat. Nach mehreren getesteten "älteren" Kernel-Versionen kann ich ttyebus nun gar nicht mehr installieren. beim Befehl "make" komt nun immer folgendes:
pi@raspberrypi:/ttyebus $ sudo make
make -C /lib/modules/4.19.46-v7+/build M=/ttyebus modules
make[1]: *** /lib/modules/4.19.46-v7+/build: Datei oder Verzeichnis nicht gefunden. Schluss.
Makefile:24: die Regel für Ziel ,,all" scheiterte
make: *** [all] Fehler 2Wenn ich das Verzeichnis "build" im angegebenen Pfad erstelle, resultiert beim Ausführen nur noch eine andere Fehlermeldung:
pi@raspberrypi:/ttyebus $ make
make -C /lib/modules/4.19.46-v7+/build M=/ttyebus modules
make[1]: Verzeichnis ,,/lib/modules/4.19.46-v7+/build" wird betreten
make[1]: *** Keine Regel, um ,,modules" zu erstellen. Schluss.
make[1]: Verzeichnis ,,/lib/modules/4.19.46-v7+/build" wird verlassen
Makefile:24: die Regel für Ziel ,,all" scheiterte
make: *** [all] Fehler 2
versuchs mal damit (https://community.matrix.one/t/kernel-modules-4-19-workaround/2413).
LG
Zitat von: Reinhart am 10 Juni 2019, 21:39:05
versuchs mal damit (https://community.matrix.one/t/kernel-modules-4-19-workaround/2413).
Super, hat geklappt. Mein Problem war wohl vorher, dass ich kernel_headers nicht gedowngraded hatte.
Mit den Maßnahmen in dem Link und anschließendem make & make install für ttyebus hat es dann funktioniert.
Vielen Dank allen beteiligten für eure Hilfe und dem Workaround.
Beste Grüße
Ich werde mir das mit dem ttyebus selbstverständlich ansehen. Ich fürchte nur dass ich frühestens am Wochenende Zeit dazu finden werde.
Bitte bis dahin bitte keinen Upgrade machen oder eben den Downgrade. Sobald ich etwas weiss melde ich mich hier wieder.
LG
Eduard
Neue Version des ttyebus Kernel Moduls
Auf github https://github.com/eBUS/ttyebus (https://github.com/eBUS/ttyebus) gibt es eine neue Version 1.6 des ttyebus Treibers.
Dieser funktioniert nun auch mit der Kernel Version V4.19.42 (und hoffentlich höher auch).
Die Ursache für die Fehlfunktion war folgende:
Der Interrupt für den UART PL011 war beim Raspi 2 und 3 bisher auf 87.
Mit dem Kernel Update ist der Interrupt auf 81 gewandert. Ich habe keine Ahnung, warum das so ist.
Auffällig ist jedenfalls, dass der Interrupt für den Raspi 1 immer schon auf 81 war.
Der ttyebus Treiber hat jetzt eine Versionsabfrage auf V4.19.42 (oder größer) und setzt dann den Interrupt auf 81.
Schön ist das nicht, ich würde gerne den Interrupt so setzten wie ihn Raspbian jeweils vorgibt, habe aber noch keine
Möglichkeit gefunden, das per Programm herauszufinden. Falls irgendjemand hier eine Idee hat, wie das gehen könnte
("welcher Interrupt ist dem uart-pl011 zugeordnet") dann wäre ich für einen Hinweis dankbar.
LG
Eduard
Hallo,
da ich mir den Raspi 4 zulegen möchte, bin ich gerade dabei "Buster" zu installieren. Bisher lief alles gut. ;D
EBUS 3.3 habe ich installiert.
Ab EBUS 3.3 soll es ja möglich sein, die config-Dateien automatisch zu holen/aktualisieren: mit
-c, --configpath=PATH
Read CSV config files from PATH [http://ebusd.eu/config/]
...soll ganz einfach sein, aber wenn das Scheunentor erstmal zu ist..., ich versuche schon seit 2h den Eintrag in der "ebusd" anzupassen :-[
...ich weiß einfach nicht an welcher Stelle welcher Eintrg zu machen ist, und welche Optionen noch anzugeben sind ???
Bisherige Konfiguration:
EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01"
EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01 --configpath=http://ebusd.eu/config/"
Bei der manuellen Installation unter Stretch bekomme ich folgende Ausgabe:
root@phoscon:/home/pi# dpkg -l | grep 'ebusd'
ii ebusd 3.2 armhf eBUS daemon.
ii ebusd-configuration 2.1.b143f39-de all ebusd configuration files (de).
...unter BUSTER mit der Autom.Conf:
pi@raspiBUSTER:/ $ dpkg -l | grep 'ebusd'^C
pi@raspiBUSTER:/ $ sudo dpkg -l | grep 'ebusd'
ii ebusd 3.3 armhf eBUS daemon.
...kann mir jemand einen Schub's geben?
Liebe Grüße Jörg
Zitat von: jonien am 17 Juli 2019, 20:20:33
-c, --configpath=PATH
Read CSV config files from PATH [http://ebusd.eu/config/]
die Werte in eckigen Klammern sind die defaults, d.h. wenn du nicht schon an den Parametern etwas geändert hast, dann wird eh der webservice genutzt.
Anonsten findest du die Einstellungen in der Zeile mit
EBUSD_OPTS="..." in der Datei /etc/default/ebusd oder /etc/init.d/ebusd
Guten Morgen John,
vielen Dank für Deine schnelle Antwort. Da habe ich die Hinweise im WIKI und GIT falsch interpretiert. Ich hatte angenommen, das ich entweder die "manuelle" Installation der Config-Dateien vornehmen muss, oder aber die "ebusd" entsprechend ergänzen muss.
Demnach wäre ja dann dieser Eintrag in der "ebusd" ausreichend:
EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01"
Werden die Config-Dateien dann auf dem Raspi (zwischen-)gespeichert? Wenn ja, müsste ich sie dann nicht mit
dpkg -l | grep 'ebusd' angezeigt bekommen?
Wie könnte ich sonst am besten kontrollieren, ob der Zugriff auf die Config-Dateien erfolgreich ist?
LG Jörg
Zitat von: jonien am 18 Juli 2019, 09:29:55
Demnach wäre ja dann dieser Eintrag in der "ebusd" ausreichend:
EBUSD_OPTS="-d 192.168.168.151:8889 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=01"
richtig
Zitat von: jonien am 18 Juli 2019, 09:29:55
Werden die Config-Dateien dann auf dem Raspi (zwischen-)gespeichert? Wenn ja, müsste ich sie dann nicht mit
dpkg -l | grep 'ebusd' angezeigt bekommen?
nein und nein
Zitat von: jonien am 18 Juli 2019, 09:29:55
Wie könnte ich sonst am besten kontrollieren, ob der Zugriff auf die Config-Dateien erfolgreich ist?
lass dir einfach nach start von ebusd mit dem "info" Kommando sagen, was Sache ist, also
ebusctl info aufrufen.
Da steht dann drin, ob ebusd überhaupt irgendwelche Geräte am Bus sieht und falls ja, welche config files dafür geholt&geladen wurden.
Hallo John,
Danke für Deine ausführliche Hilfe und Hintergrundinformation. Somit ist die Standartinstallation ja sehr einfach geworden. ;D
Wie immer ein toller Support.
LG Jörg
Zitat von: jonien am 18 Juli 2019, 11:41:45
Somit ist die Standartinstallation ja sehr einfach geworden. ;D
das war die Idee :)
Guten Tag,
ich habe hier plötzlich Probleme mit den Config-Dateien. Ohne wirklich erkennbare Ursache hatte ich nur noch ca. 50 messeages (statt vorher über 1.000) zur Verfügung. Das konnte ich inzwischen weitgehend bereinigen. Die Ursache konnte ich aber nicht wirklich feststellen. Ich vermute, dass sich die Speicherkarte beim Raspi langsam in den Ruhestand verabschiedet und daher einige Dateien vorübergehend nicht mehr lesbar waren.
Bei der Ursachenforschung habe ich mir die Frage gestellt, ob es nicht möglich ist, für erkannte Geräte das Laden der passenden csv zu erzwingen.
Und die 2. Frage wäre dann ob man schon das aktuelle Debian für den Raspi verwenden kann, oder ob da Probleme zu erwarten sind.
Viele Grüße, Claus
... zur 2. Frage:
ich habe Buster auf einem Raspi4 seit einigen Wochen in Betrieb, aber es läuft noch nicht alles ganz rund. Wenn du sowas vorhast, unbedingt als Testsystem parallel vorher austesten, kostet zwar etwas aber du kannst jederzeit zurück stellen. Wie sich der eBus unter Buster verhält, kann ich nicht sagen weil ich es noch nicht getestet habe.
Da ich jedoch den Raspi und das System getauscht habe, weiß ich noch nicht genau wo die Ungereimtheiten herkommen. Meine Hauptprobleme sind noch bei Cul und der verwendeten Software und habe deshalb mein Produktivsystem wieder auf Raspi3 und Stretch gelegt.
Aber im wesentlichen läuft alles und schneller noch dazu.
LG
Hallo, Reinhart
ich habe schon mal einen Raspberry Zero bestellt. Da werde ich dann ausprobieren, ob der Ebusd drauf läuft. So kann ich dann einfach die Hardware auswechseln. Ich werde dann berichten.
Ist ja inzwischen auch nicht mehr so eilig. Der alte läuft derzeit wieder schön stabil.
Viele Grüße, Claus
ja, mach das bitte!
Ich habe gerade gesehen, das eine Seite vorher schon jemand Buster (https://forum.fhem.de/index.php/topic,84636.msg958817.html#msg958817) positiv mit dem eBus getestet hat.
LG
Hallo, Reinhart
na dann sollte es ja keine Probleme geben. Ist auch eine gute Gelegenheit, mal alles wieder auf den neuesten Stand zu bringen. Und diesmal ein Image von der SD-Karte zu ziehen, um solche Probleme ohne viel Denken zu lösen. ;-) Ich habe hier das alte Verzeichnis mit den CSV-Dateien umbenannt, ein neues angelegt und die Dateien (neu aus der Quelle) dort hinein kopiert. Nachdem ich die richtige Version genommen hatte, ging es wieder. Den ebusd musst ich natürlich auch neu starten. Vermutlich hätte ich gar nichts gemerkt, wenn ich in der Config den Verweis auf die Webseite gesetzt hätte. Aber ich mag die Cloud nicht. Auch wenn meine Vorbehalte hier sicherlich absolut unzutreffend sind.
Viele Grüße, Claus
Zitat von: Reinhart am 12 September 2019, 19:53:51
Ich habe gerade gesehen, das eine Seite vorher schon jemand Buster (https://forum.fhem.de/index.php/topic,84636.msg958817.html#msg958817) positiv mit dem eBus getestet hat.
ttyebus und ebusd laufen auch bei mir problemlos unter Buster auf einem RPi3.
Auf einem RPi4B konnte ich ttyebus nicht kompilieren. die Fehlermeldung weiß ich leider nicht mehr. sorry... (siche unten)
Demzufolge habe ich die Ebus Schaltung respektive ebusd am RPi4B noch nicht in Betrieb genommen.
Aktuelle Raspbian Version 4.19.75-v7+Scheinbar sind die Skripte in dem verteilten Paket fehlerhaft.
mit Raspberry Pi 3B+ttyebus / make hat bei mir einen Fehler ausgeworfen "fixdep: Exec format error". Hier haben folgende Befehle geholfen:
cd /usr/src/linux-headers-4.19.75-v7+
sudo make scripts
Das kompilieren brach zwar auch irgendwann ab - offensichtlich reichen die erzeugten Tools bis dahin jedoch aus um ttyebus wie gewohnt zu kompilieren...
mit Raspberry Pi 4BHier hat oben genannter Befehl nicht geholfen. Ich musste erst die kompletten Sourcen downloaden. Dafür habe ich folgendes Script benutzt:
https://github.com/notro/rpi-source/wiki (https://github.com/notro/rpi-source/wiki)
danach konnte ich auch hier ttyebus kompilieren.
Weiteres habe ich noch nicht getestet! Nachmachen auf eigene Gefahr. Ich habe keine Ahnung, was das oben verlinkte Tool alles downloaded!
Update vom 14.10.2019heute wurden neue kernel und Header sourcen (unter gleicher Versionsbezeichnung "linux-headers-4.19.75-v7+") verteilt, mit diesen konnte ich ttyebus auf RPi3B+ und Rpi4B kompilieren.
Entschuldigung für die Verwendung von Englisch.
Today I recived the Rpi adapter von Reinhart. Vielen Dank für das. It worked straight out of the envelope.
Even better than the Esera eBUs-USB adapter. I am using it with a Brink (Wolf) Renovent 400 plus ventilation system. The Esera adapter was drawing too much current from the ebus, meaning that I could not use the control screen and the ebus adapter simultaneous.
With the Rpi adapter (with DC-DC) this is no longer an issues and I can use the controller and read/write the ebus via the adapter at the same time!
@tinusv
Thanks for the feedback!
That's exactly why we use the DC converter, because otherwise the eBus specification can not be maintained.
LG
Reinhart
Kann mir mal einer hier helfen.
Ich habe die ebus schaltung RPI mit einem PI2 auf stretch in Betrieb genommen:
der ebusd läuft, verkabelung ist auch ok.
Aber ebusctl info sagt immer no signal
ebusctl info
version: ebusd 3.4.v3.4
update check: OK
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
und im log habe ich folgende Meldung:
ttyebus: Close at at major 10 minor 58
Wie weiter?
Gruß
Carlos
Ja, du hast Probleme mit dem ttyebus Treiber!
schau bitte einmal mit
ls -l /dev
ob einerseits der Treiber ttyAMA0 verschwunden ist und andererseits ttyebus vorhanden ist.
crw--w---- 1 root tty 4, 8 Okt 13 12:17 tty8
crw--w---- 1 root tty 4, 9 Okt 13 12:17 tty9
crw-rw---- 1 root dialout 204, 64 Nov 8 19:00 ttyAMA0
crw------- 1 root root 5, 3 Okt 13 12:17 ttyprintk
crw-rw---- 1 root dialout 4, 64 Okt 13 12:17 ttyS0
crw-rw---- 1 root dialout 188, 0 Okt 30 22:04 ttyUSB0
ttyAMA0 muss weg sein, wenn nicht dann nochmals hier (https://forum.fhem.de/index.php/topic,84636.0.html)die Installation des Treiber beachten.
crw--w---- 1 root tty 4, 9 Nov 1 16:06 tty9
crw-rw-rw- 1 root root 10, 58 Nov 1 16:06 ttyebus
crw------- 1 root root 5, 3 Nov 1 16:06 ttyprintk
crw------- 1 root root 10, 239 Nov 1 16:05 uhid
crw------- 1 root root 10, 223 Nov 1 16:05 uinput
ttyebus muss laufen und hole dir aus dem git den letzten, galileo hat da noch was geändert!
LG
Der Treiber ttyAMA0 ist verschwunden ist und der ttyebus ist da, aber die Gruppe stimmt bei mir nicht.
crw--w---- 1 root tty 4, 62 Nov 8 16:17 /dev/tty62
crw--w---- 1 root tty 4, 63 Nov 8 16:17 /dev/tty63
crw--w---- 1 root tty 4, 7 Nov 8 16:18 /dev/tty7
crw--w---- 1 root tty 4, 8 Nov 8 16:17 /dev/tty8
crw--w---- 1 root tty 4, 9 Nov 8 16:17 /dev/tty9
crw-rw-rw- 1 root root 10, 58 Nov 8 16:17 /dev/ttyebus
crw------- 1 root root 5, 3 Nov 8 16:17 /dev/ttyprintk
Könnte das das Problem sein?
Nein war es auch nicht.
crw-rw-rw- 1 root dialout 10, 58 Nov 8 16:17 /dev/ttyebus
immer noch der Fehler:
ttyebus: Close at at major 10 minor 58
Gruß
Carlos
Das ist kein Problem vom ttyebus Treiber.
Die Meldung "ttyebus: Close at major 10 minor 58" zeigt, dass zuerst ein korrektes "ttyebus_open()" mit major 10 / minor 58 stattgefunden hat.
Die Funktion "ttyebus_close()" aus der diese Meldung stammt, wird AUSSCHLIESSLICH von außen aufgerufen.
Das heisst also, dass irgendwer ein explizites "Close" auf den Treiber absetzt. Die Frage ist natürlich, warum ?
LG
Eduard
wäre jetzt interessant zu welchem Zeitpunkt dieser "close" denn kommt.
Wenn ebusd gestartet wird? Wenn ja, dann die config einmal kontrollieren und checken.
USD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --accesslevel=*"
was passiert denn wenn du ohne ebusd zu starten folgendes Komando eingibst, gibt es da auch einen "close" oder kommt das Signal am Adapter an der Rx Led an?
echo "das ist ein Sendetest" >/dev/ttyebus
und schau mal hier (https://forum.fhem.de/index.php?topic=84636.15), das hatten wir schon einmal.
LG
Nach einem reboot mit laufendem ebusd steht im log bzgl ebus nur:
[ 2.661347] ttyebus: loading out-of-tree module taints kernel.
[ 2.662824] ttyebus: Found RASPI model 2
Nach dem stop des ebusd:
[ 146.261639] ttyebus: Close at at major 10 minor 58
Nach echo "das ist ein Sendetest" >/dev/ttyebus:
[ 146.261639] ttyebus: Close at at major 10 minor 58
[ 146.261657] ttyebus: Close exit
[ 193.776943] ttyebus: Close at at major 10 minor 58
dann mal ein rmmod ttyebus:
[ 146.261639] ttyebus: Close at at major 10 minor 58
[ 146.261657] ttyebus: Close exit
[ 193.776943] ttyebus: Close at at major 10 minor 58
[ 193.776960] ttyebus: Close exit
und wieder insmod ttyebus:
root@ebusd:~# insmod ttyebus
insmod: ERROR: could not insert module ttyebus: No such device
r
also lässt sich das module nicht mehr laden.
Keine Ahnung was ich jetzt noch machen kann.
Gruß
Carlos
Hallo carlos,
zuerst einmal: "loading out-of-tree module taints kernel" ist völlig normal, weil das ein "Modul" ist und nicht fix mit dem Kernel mit-compiliert ist. Also ignorieren.
Found RASPI model 2 ist nur eine Info-Message.
So weit so gut, aber jetzt fehlen einfach Log-Einträge um sehen zu können was weiter passiert. Die kannst du relativ einfach erzeugen:
- Editiere das Source File "ttyebusm.c" und entferne in Zeile 57 den Kommentar ( // define DEBUG 1 ---> define DEBUG 1 )
- dann neu compilieren ("make") und installieren (sudo make install). Nach einem Reboot sollten im kern.log wesentlich mehr Einträge kommen.
Bitte nicht vergessen, später den Kommentar wieder einzusetzen, sonst wird kern.log mit Einträgen geflutet.
Und noch etwas zum Thema Herumprobieren: Die Reihenfolge:
- sudo service ebusd stop
- sudo make uninstall
- make
- sudo make install
muss unbedingt eingehalten werden. Wenn man ein "uninstall" versucht, während ebusd noch läuft (also ohne stop), oder ein mehrfaches "rmmod" und "insmod",
dann kommen schon mal solche Meldungen wie "could not insert module..."
Und zuletzt möchte ich noch bitten aufzupassen, dass der eBus physikalisch NICHT angeschlossen ist, wenn du ein "echo "das ist ein Sendetest" > /dev/ttyebus"
absetzt, weil sollte es funktionieren dann wird auf dem eBus Müll erscheinen und das mag anderen Zuhörern eventuell gar nicht gefallen. Und ebusd sollte bei diesem
Test jedenfall auch nicht laufen !
LG
Hallo,
Das ist das Ergebnis nach dem neu compilieren mit debug.
Habe ein reboot gemacht und ebusd gestopt und wieder gestartet.
[ 81.553911] ttyebus: Close at at major 10 minor 58
[ 81.553920] ttyebus: Close exit
[ 94.447807] ttyebus: Open at at major 10 minor 58
[ 94.447825] ttyebus: Open exit
[ 94.448669] ttyebus: Poll request
[ 94.448684] ttyebus: Poll timeout
[ 94.708955] ttyebus: Poll request
[ 94.708967] ttyebus: Poll timeout
[ 94.709034] ttyebus: Poll request
[ 94.709039] ttyebus: Poll timeout
[ 94.969421] ttyebus: Poll request
[ 94.969431] ttyebus: Poll timeout
[ 94.969465] ttyebus: Poll request
[ 94.969470] ttyebus: Poll timeout
[ 95.229786] ttyebus: Poll request
[ 95.229803] ttyebus: Poll timeout
[ 95.229860] ttyebus: Poll request
[ 95.229868] ttyebus: Poll timeout
[ 95.490238] ttyebus: Poll request
[ 95.490262] ttyebus: Poll timeout
[ 95.490314] ttyebus: Poll request
[ 95.490324] ttyebus: Poll timeout
[ 95.750600] ttyebus: Poll request
[ 95.750612] ttyebus: Poll timeout
[ 95.750652] ttyebus: Poll request
Gruß
Carlos
Zitat[ 94.709034] ttyebus: Poll request
[ 94.709039] ttyebus: Poll timeout
ebusd hat beim ttyebus Treiber angefragt, ob ein Datum verfügbar ist. Der ttyebus Treiber hat innerhalb der Timeout-Zeit keine Daten liefern können.
Vermutlich hat die Hardware keine Daten geliefert. Was sagen denn die LEDs auf der Platine ?
Guten Morgen,
habe gestern abend meine RPI Platine V2.2 gestern auch erfolgreich auf einem Raspi 3B+ mit Buster Image ans laufen bekommen.
Hier meine Konfig:
EBUSD_OPTS="-r -d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig
Und ein Auszug aus dem Log:
2019-11-10 19:57:54.764 [main notice] ebusd 3.3.v3.3 started with auto scan
2019-11-10 19:57:54.883 [bus notice] bus started with own address 31/36
2019-11-10 19:57:54.909 [bus notice] signal acquired
2019-11-10 19:57:55.463 [bus notice] new master 70, master count 2
2019-11-10 19:57:57.466 [bus notice] new master 10, master count 3
2019-11-10 19:57:57.472 [bus notice] new master 03, master count 4
2019-11-10 19:57:57.472 [update notice] received unknown MM cmd: 1003050709bb0532020080ff64ff
2019-11-10 19:57:57.764 [bus notice] new master f1, master count 5
2019-11-10 19:57:57.764 [update notice] received unknown BC cmd: f1fe050308010100ff40ff3803
2019-11-10 19:58:02.442 [update notice] received unknown MM cmd: 10030800081a23000380030032
2019-11-10 19:58:02.735 [update notice] received unknown BC cmd: f1fe0800081a239a0300000032
2019-11-10 19:58:04.990 [update notice] store 08 ident: ERR: argument value out of valid range
2019-11-10 19:58:04.991 [update error] unable to parse scan-read scan.08 from 3108070400 / 0a50011a33440211d36830: ERR: argument value out of valid range
2019-11-10 19:58:04.991 [bus notice] scan 08: ;Kromschroeder; 3D ;
2019-11-10 19:58:04.991 [main error] scan config 08: ERR: argument value out of valid range
2019-11-10 19:58:07.123 [bus notice] scan 15: ;Kromschroeder; ;0204;-
2019-11-10 19:58:07.123 [update notice] store 15 ident: done
2019-11-10 19:58:07.124 [update notice] sent scan-read scan.15 QQ=31: Kromschroeder; ;0204;-
2019-11-10 19:58:07.124 [bus notice] scan 15: ;Kromschroeder; ;0204;-
2019-11-10 19:58:07.153 [main error] unable to load scan config 15: list files in kromschroeder ERR: element not found
2019-11-10 19:58:07.153 [main error] scan config 15: ERR: element not found
2019-11-10 19:58:07.428 [update notice] received unknown MM cmd: 1003050709bb0132020080ff64ff
2019-11-10 19:58:07.542 [update notice] received unknown MM cmd: 03f10800080029000380000032
2019-11-10 19:58:07.744 [update notice] received unknown BC cmd: f1fe050308010100ff40ff3803
2019-11-10 19:58:09.272 [bus notice] scan 75: ;Kromschroeder; ;0204;-
2019-11-10 19:58:09.272 [update notice] store 75 ident: done
2019-11-10 19:58:09.273 [update notice] sent scan-read scan.75 QQ=31: Kromschroeder; ;0204;-
2019-11-10 19:58:09.273 [bus notice] scan 75: ;Kromschroeder; ;0204;-
2019-11-10 19:58:09.302 [main error] unable to load scan config 75: list files in kromschroeder ERR: element not found
2019-11-10 19:58:09.302 [main error] scan config 75: ERR: element not found
2019-11-10 19:58:11.392 [bus notice] scan f6: ;Kromschroeder; ;0204;-
2019-11-10 19:58:11.392 [update notice] store f6 ident: done
2019-11-10 19:58:11.392 [update notice] sent scan-read scan.f6 QQ=31: Kromschroeder; ;0204;-
2019-11-10 19:58:11.392 [bus notice] scan f6: ;Kromschroeder; ;0204;-
2019-11-10 19:58:11.422 [main error] unable to load scan config f6: list files in kromschroeder ERR: element not found
2019-11-10 19:58:11.422 [main error] scan config f6: ERR: element not found
2019-11-10 19:58:12.412 [update notice] received unknown MM cmd: 10030800081a23000380030032
2019-11-10 19:58:12.658 [update notice] received unknown BC cmd: 03fe0503080100040040ff3803
2019-11-10 19:58:12.727 [update notice] received unknown BC cmd: f1fe0800081a239a0300000032
2019-11-10 19:58:17.362 [update notice] received unknown MM cmd: 1003050709bb0332020080ff64ff
2019-11-10 19:58:17.656 [update notice] received unknown BC cmd: f1fe050308010100ff40ff3803
2019-11-10 19:58:22.363 [update notice] received unknown MM cmd: 10030800081a23000380030032
2019-11-10 19:58:22.657 [update notice] received unknown BC cmd: f1fe0800081a239a0300000032
Hab ich nun noch ein Konfigurationfehler oder wird meine Wolf Heizung nicht unterstützt?
Zitat von: ecki945 am 11 November 2019, 05:57:53
Hab ich nun noch ein Konfigurationfehler oder wird meine Wolf Heizung nicht unterstützt?
du musst vermutlich die Konfigs aus https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de nehmen, sprich clonen und ebusd von dort die CSV lesen lassen
Hallo,
Habe meinen alten Adapter noch mal dran und im Zuge dessen auch das Kabel noch mal kontrolliert.
Jetzt gehen wieder beide Adapter.
Ich gehe also davon aus dass es tatsächlich die Verkabelung war.
Ich bekomme jetzt sauber Daten von meiner Weishaupt Heizung in FHEM.
Jetzt gehts nur noch um das setup mit MQTT2.
Danke für die Hilfe.
Gruß
Carlos
Zitat von: carlos am 15 November 2019, 09:22:17
Jetzt gehts nur noch um das setup mit MQTT2.
das ist der leichteste Teil, habe ich hier (https://wiki.fhem.de/wiki/EBUS-MQTT2) einmal zusammen geschrieben!
LG
Danach gehe ich auch vor.
Aber bei mir sieht das so aus, was als MQTT Nachrichten kommt.
ebusd/broadcast/datetime/outsidetemp 4.000
ebusd/broadcast/datetime/time "15:14:-"
ebusd/global/uptime 80
ebusd/hc1/Set/Status "hotwaterinheating"
ebusd/hc1/Set/Action "startconsumer"
ebusd/hc1/Set/SetTemp 51.00
ebusd/hc1/Set/SetPressure null
ebusd/hc1/Set/OutputDegree null
ebusd/hc1/Set/DHWSetTemp 50.0
ebusd/hc1/Set/Fueltype null
ebusd/sc/Act/Status1 1
ebusd/sc/Act/Operatingphase "BrennerAus"
ebusd/sc/Act/Ukn2_1 1
ebusd/sc/Act/Ukn2_2 1
ebusd/sc/Act/Ukn2_3 1
ebusd/sc/Act/Flame 0
ebusd/sc/Act/GasValve1 0
ebusd/sc/Act/GasValve2 0
ebusd/sc/Act/Pump 1
ebusd/sc/Act/Error 0
ebusd/sc/Act/Ukn3_1 0
ebusd/sc/Act/SoWi "Winter"
ebusd/sc/Act/Ukn3_3 0
ebusd/sc/Act/Ukn3_4 1
ebusd/sc/Act/Ukn3_5 1
ebusd/sc/Act/Ukn3_6 0
ebusd/sc/Act/Ukn3_7 0
ebusd/sc/Act/SettingUV "Heating"
ebusd/sc/Act/Load 0
ebusd/sc/Act/SupplyTemp 44.0
ebusd/sc/Act/FlueGasTemp 45.0
ebusd/sc/Act/DHWTemp 49.0
ebusd/sc/Act/UknTemp 0.0
ebusd/sc/Act/ExternalTemp 4
ebusd/sc/Act/TrendTemp 4.188
ebusd/sc/Act/SupplySetTemp 51
ebusd/hc2/Set/Status "hotwaterinheating"
ebusd/hc2/Set/Action null
ebusd/hc2/Set/SetTemp 31.31
ebusd/hc2/Set/SetPressure null
ebusd/hc2/Set/OutputDegree null
ebusd/hc2/Set/DHWSetTemp null
ebusd/hc2/Set/Fueltype null
ebusd/global/uptime 96
ebusd/hc1/Set/Status "hotwaterinheating"
ebusd/hc1/Set/Action "startconsumer"
ebusd/hc1/Set/SetTemp 51.00
ebusd/hc1/Set/SetPressure null
ebusd/hc1/Set/OutputDegree null
ebusd/hc1/Set/DHWSetTemp 50.0
ebusd/hc1/Set/Fueltype null
ebusd/hc2/Set/Status "hotwaterinheating"
ebusd/hc2/Set/Action null
ebusd/hc2/Set/SetTemp 31.31
ebusd/hc2/Set/SetPressure null
ebusd/hc2/Set/OutputDegree null
ebusd/hc2/Set/DHWSetTemp null
ebusd/hc2/Set/Fueltype null
Das passt nicht so ganz.
Außerdem wird mir bei jedem Start vom ebusd ein neues device (z.B. MQTT2_ebusd_3.4_6732) obwohl ich schon eines habe (MQTT2_ebusd_3.4_340 ) angelegt.
Muss ich mir alles noch mal genauer anschauen.
Gruß
Carlos
wenn du mir etwas mehr erzählst was du bis jetzt angelegt hast, dann kann ich dir vielleicht weiter helfen!
Hast du einen MQTT2_Server angelegt, wenn ja dann mach bitte ein "list", hast du einen Client angelegt, dann bitte auch ein "list" des Devices.
LG
ist es möglich 2 x ebus auf einen Rpi zu Installieren?
1 x Ebus für den UART --> /dev/ttyEbus
1x Ebus für den USB Anschluss --> /dev/ttyUSB0
so das ich mit einem RPI die Gastherme und die Solar Anlage abfragen kann.
Hallo,
ich habe gestern meine RPI Platine V2.2 auf einem Raspi 3B+ mit Buster Image in Betrieb genommen.
Anschließend ebusd von John installiert und soweit läuft alles wie es soll.
Doch wenn ich ebusctl i eingebe, wird mir eine neue Version angezeigt obwohl die 3.4 ja schon drauf ist.
Sieht wie folgt aus:
root@raspberrypi:/home/pi# ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
Habe ich da jetzt etwas falsch gemacht oder warum ist das so?
Hat da jemand einen Tip für mich?
Zitat von: Peter0961 am 17 November 2019, 16:33:52
Hat da jemand einen Tip für mich?
Probiere das hier (https://forum.fhem.de/index.php/topic,46098.msg989059.html#msg989059)
Zitat von: chons am 17 November 2019, 17:25:01
Probiere das hier (https://forum.fhem.de/index.php/topic,46098.msg989059.html#msg989059)
Hallo, ich habe es aber über das ".deb" Paket aktualisiert:
wget https://github.com/john30/ebusd/releases/download/v3.4/ebusd-3.4_armhf-stretch_mqtt1.deb
Ah, ok das wusste ich nicht, dann würde ich das so lassen wie es ist und die Meldung ignorieren. Die Version, welche Du verwendest ist relativ (paar Tage alt) aktuell.
Alternative: Du wechselst auf die repo(github) Version und kompilierst es regelmäßig selbst.
Zitat von: spacecowboy.21 am 17 November 2019, 14:14:25
so das ich mit einem RPI die Gastherme und die Solar Anlage abfragen kann.
Hängen Gastherme und Solar Anlage nicht am gleichen physikalischen Bus?
Oder wäre es denkbar die beiden Systeme zu koppeln? Immerhin ist es ein Bus-System :-D
Vielleicht stimmen sich dann ja auch Therme und Solaranlage besser ab?
du müsstest vermutlich den ebusd 2x starten. Keine Ahnung, ob das mit vertretbarem Aufwand machbar ist.
Zitat von: Peter0961 am 17 November 2019, 16:33:52
Hallo,
ich habe gestern meine RPI Platine V2.2 auf einem Raspi 3B+ mit Buster Image in Betrieb genommen.
Anschließend ebusd von John installiert und soweit läuft alles wie es soll.
Doch wenn ich ebusctl i eingebe, wird mir eine neue Version angezeigt obwohl die 3.4 ja schon drauf ist.
Sieht wie folgt aus:
root@raspberrypi:/home/pi# ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
Habe ich da jetzt etwas falsch gemacht oder warum ist das so?
Hat da jemand einen Tip für mich?
alles gut, beim Bauen des letzten Release ist anscheinend unter RPi die Versionsnr. nicht richtig eingesetzt worden
Zitat von: HeikoGr am 18 November 2019, 08:21:46
du müsstest vermutlich den ebusd 2x starten. Keine Ahnung, ob das mit vertretbarem Aufwand machbar ist.
ja, einfach in der ebusd config unter /etc/default/ebusd nachschauen, da ist das beschrieben
Zitat von: john30 am 18 November 2019, 09:23:31
ja, einfach in der ebusd config unter /etc/default/ebusd nachschauen, da ist das beschrieben
Ich denke das Du diesen Teil meinst.
Zitat# 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.
Ich habe also die ebusd.service kopiert /etc/systemd/system/ebusd-2.service und die ExecStart geändert.
Zitat[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network-online.target
ConditionPathExists=/var/log
[Service]
Type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
#EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS1
[Install]
WantedBy=multi-user.target
Dann habe ich in der /etc/default/ebusd EBUSD_OPTS1="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd-2.log --scanconfig" hinzugefügt.
Zitat# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig"
EBUSD_OPTS1="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd-2.log --scanconfig"
War das so richtig?
----------
Ich denke nicht.
Mit sudo service ebusd-2 start
kommt die Meldung:
Job for ebusd-2.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status ebusd-2.service" and "journalctl -xe" for details.
Zitat von: spacecowboy.21 am 19 November 2019, 20:27:19
War das so richtig?
EnvironmentFile= darfst natürlich nicht auskommentieren, wenn nach wie vor in der default/ebusd die Einstellungen konfiguriert werden sollen. Dort müssen dann entsprechende nicht-kommentierte EBUSD_OPTS1 etc auch drin sein
Hallo,
hat schon jemand Erfahrungen mit dem RPi4 gemacht? Funktioniert der Adapter mit dem ttyebus Treiber?
Ich bin gerade am Aussuchen eines passenden RPi's.
Gruß
Stefan
ich konnte ttyebus kompilieren, aber nicht installieren ("sudo make install").
Irgendwas beim insmod(?) Aufruf hat nicht funktioniert.
War aber auch ein recht unmotivierter Test, da ich aus gebäudetopologischen Gründen vom Raspberry Modul auf das Basismodul (mit Wemos D1 als WLAN-Brücke) umgestellt habe, als ich vom RPi3 auf RPi4 umgestiegen bin...
Du kannst aber auch das Raspberry Modul mit einem FTDI Adapter (oder Wemos D1) über USB (oder WLAN) koppeln, wenn es ein RPi4 sein muss und solange der Fehler (in ttyebus oder Raspbian) noch nicht behoben wurde.
ein Fehlerlog hast du nicht mehr zufällig?
Ich habe zwar einen Raspi4, aber auf dem läuft das produktive Fhem und ist auf SSD umgestellt, deshalb möchte ich den jetzt nicht unbedingt zum testen nehmen.
Wenn wie den Fehler kennen, dann kann galileo das ja fixen. Ich kann mir nur vorstellen, das die Interruptbelegung eine andere ist.
LG
Nein, leider nicht.
Aber wenn ich die tage mal ein bisschen mehr Zeit habe wollte ich mir das ganze mal in Ruhe ansehen.
Wie hast du den ebus adapter an den RPi4 angebunden?
für den eBus habe ich einen einen Raspi 3 mit RPI-Adapter, der Raspi 4 hat nur Fhem drauf.
Aber es stimmt schon wie du schreibst, alternativ über UART anbinden geht immer.
LG
ZitatWenn wie den Fehler kennen, dann kann galileo das ja fixen. Ich kann mir nur vorstellen, das die Interruptbelegung eine andere ist.
Ich besitze leider noch keinen RASPi 4, deshalb kann ich das nicht ansehen. Falls das wirklich der Interrupt ist wäre es aber leicht zu korrigieren.
Könnte bitte jemand, der einen RASPI 4 besitzt, einmal den Befehl
cat /proc/interruptsausführen und hier posten. Aber Achtung! der ttyebus darf nicht laufen, sondern es muss der ttyAMA0 aktiv sein. Dessen Interrupt Wert ist interessant.
LG
Gerne:
CPU0 CPU1 CPU2 CPU3
17: 0 0 0 0 GICv2 29 Level arch_timer
18: 9318306 5135947 7296660 5006799 GICv2 30 Level arch_timer
31: 238458 0 0 0 GICv2 65 Level fe00b880.mailbox
35: 10576 0 0 0 GICv2 125 Level ttyS0
37: 0 0 0 0 GICv2 72 Level dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb3
38: 0 0 0 0 GICv2 169 Level brcmstb_thermal
39: 2790862 0 0 0 GICv2 158 Level mmc0
45: 0 0 0 0 GICv2 106 Level v3d
47: 20028377 0 0 0 GICv2 189 Level eth0
48: 9928945 0 0 0 GICv2 190 Level eth0
54: 49 0 0 0 GICv2 66 Level VCHIQ doorbell
55: 0 0 0 0 GICv2 175 Level PCIe PME, aerdrv
56: 23852219 0 0 0 Brcm_MSI 524288 Edge xhci_hcd
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 1426215 2640956 2907549 2403056 Rescheduling interrupts
IPI3: 9318 96508 97866 98421 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 1718673 374559 585368 368738 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
Err: 0
Ich würde ja gerne schreiben ,,vergiss den Post oben", da der serielle anschluss noch deaktiviert war. Aber ich sehe keinen Unterschied nach dem aktivieren:
CPU0 CPU1 CPU2 CPU3
17: 0 0 0 0 GICv2 29 Level arch_timer
18: 24691 21109 18762 12399 GICv2 30 Level arch_timer
31: 143 0 0 0 GICv2 65 Level fe00b880.mailbox
36: 10575 0 0 0 GICv2 125 Level ttyS0
38: 0 0 0 0 GICv2 72 Level dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb3
39: 0 0 0 0 GICv2 169 Level brcmstb_thermal
40: 22612 0 0 0 GICv2 158 Level mmc0
46: 0 0 0 0 GICv2 106 Level v3d
48: 7431 0 0 0 GICv2 189 Level eth0
49: 519 0 0 0 GICv2 190 Level eth0
55: 49 0 0 0 GICv2 66 Level VCHIQ doorbell
56: 0 0 0 0 GICv2 175 Level PCIe PME, aerdrv
57: 3980 0 0 0 Brcm_MSI 524288 Edge xhci_hcd
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 4515 8478 6292 6797 Rescheduling interrupts
IPI3: 1112 2109 1928 3154 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 310 89 200 80 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
Err: 0
Ich glaube auch nicht, dass es an den Interrupts liegt. Hier der Fehler beim ausführen von ,,sudo make install":
cp ttyebus.ko /lib/modules/4.19.75-v7l+/kernel/drivers/tty/serial/ttyebus.ko
depmod -a
insmod /lib/modules/4.19.75-v7l+/kernel/drivers/tty/serial/ttyebus.ko
insmod: ERROR: could not insert module /lib/modules/4.19.75-v7l+/kernel/drivers/tty/serial/ttyebus.ko: Invalid parameters
make: *** [Makefile:39: install] Fehler 1
Soweit ich das sehen kann, hat der RASPI 4 nunmehr fünf UARTS (bisher 2)
Beim Raspi 3 muss ja der UART und der Mini-UART wegen Bluetooth getauscht werden.
Vermutlich wird das beim Raspi 4 nicht mehr nötig sein, bzw. überhaupt ganz anders funktionieren.
Es tut mir leid, aber das wird nicht ohne größere Recherche abgehen, und ich muss mir erst einen RASPI 4 besorgen...
Also bitte vorerst nicht annehmen dass der ttyebus auf Raspi 4 funktionieren wird.
LG
Ich kann auch nicht mehr helfen. Mein Raspi ist gerade nicht erreichbar. Die ssh Session hat sich gestern mit wilden kernel error Meldungen verabschiedet (erinnere mich grade daran, dass es bei meinem letzten Versuch auch so war. Mist). Power off/on hat auch nix gebracht. Werde den raspi/fhem jetzt neu aufsetzen müssen ::) (hatte ich eh vor, um von sd card auf SSD umzuziehen)
Hi Galileo,
ich hab dasselbe Problem wie HeikoGr, mit exakt dem gleichen Kernel.
Evtl. hilft dir ja die dmesg, die wärend dem make install passiert:
[ 1101.129067] ttyebus: loading out-of-tree module taints kernel.
[ 1101.129458] ttyebus: Found RASPI model 1
[ 1101.129564] ------------[ cut here ]------------
[ 1101.129580] WARNING: CPU: 3 PID: 1343 at arch/arm/mm/ioremap.c:303 __arm_ioremap_pfn_caller+0x188/0x214
[ 1101.129583] Modules linked in: ttyebus(O+) bnep hci_uart btbcm serdev bluetooth ecdh_generic 8021q garp stp llc brcmfmac spidev brcmutil sha256_generic cfg80211 raspberrypi_hwmon hwmon rfkill vc4 v3d drm_kms_helper gpu_sched drm bcm2835_codec(C) bcm2835_v4l2(C) v4l2_mem2mem drm_panel_orientation_quirks bcm2835_mmal_vchiq(C) snd_bcm2835(C) snd_soc_core v4l2_common videobuf2_dma_contig snd_compress videobuf2_vmalloc snd_pcm_dmaengine videobuf2_memops videobuf2_v4l2 snd_pcm videobuf2_common snd_timer i2c_bcm2835 syscopyarea sysfillrect snd videodev sysimgblt fb_sys_fops media rpivid_mem vc_sm_cma(C) spi_bcm2835 uio_pdrv_genirq uio fixed i2c_dev ip_tables x_tables ipv6
[ 1101.129796] CPU: 3 PID: 1343 Comm: insmod Tainted: G C O 4.19.75-v7l+ #1270
[ 1101.129799] Hardware name: BCM2835
[ 1101.129812] [<c0212d10>] (unwind_backtrace) from [<c020d530>] (show_stack+0x20/0x24)
[ 1101.129821] [<c020d530>] (show_stack) from [<c097fb20>] (dump_stack+0xd4/0x118)
[ 1101.129830] [<c097fb20>] (dump_stack) from [<c0222330>] (__warn+0x104/0x11c)
[ 1101.129837] [<c0222330>] (__warn) from [<c0222480>] (warn_slowpath_null+0x50/0x58)
[ 1101.129844] [<c0222480>] (warn_slowpath_null) from [<c0219d08>] (__arm_ioremap_pfn_caller+0x188/0x214)
[ 1101.129851] [<c0219d08>] (__arm_ioremap_pfn_caller) from [<c0219dfc>] (__arm_ioremap_caller+0x68/0x70)
[ 1101.129857] [<c0219dfc>] (__arm_ioremap_caller) from [<c0219e5c>] (ioremap+0x30/0x38)
[ 1101.129871] [<c0219e5c>] (ioremap) from [<bfa64914>] (init_module+0xe4/0x17c [ttyebus])
[ 1101.129896] [<bfa64914>] (init_module [ttyebus]) from [<c02030cc>] (do_one_initcall+0x50/0x218)
[ 1101.129904] [<c02030cc>] (do_one_initcall) from [<c02bb8f4>] (do_init_module+0x74/0x220)
[ 1101.129912] [<c02bb8f4>] (do_init_module) from [<c02ba86c>] (load_module+0x1dc0/0x2404)
[ 1101.129918] [<c02ba86c>] (load_module) from [<c02bb0cc>] (sys_finit_module+0xbc/0xcc)
[ 1101.129925] [<c02bb0cc>] (sys_finit_module) from [<c0201000>] (ret_fast_syscall+0x0/0x28)
[ 1101.129929] Exception stack(0xd95affa8 to 0xd95afff0)
[ 1101.129934] ffa0: 684ef200 bee30764 00000003 0002d064 00000000 00000004
[ 1101.129939] ffc0: 684ef200 bee30764 0003fce8 0000017b 01823200 00000000 00000002 00000000
[ 1101.129943] ffe0: bee30598 bee30588 00022cb8 b6cbcaf0
[ 1101.129947] ---[ end trace 9a62985f777ab829 ]---
[ 1101.129951] ------------[ cut here ]------------
[ 1101.129958] WARNING: CPU: 3 PID: 1343 at arch/arm/mm/ioremap.c:303 __arm_ioremap_pfn_caller+0x188/0x214
[ 1101.129961] Modules linked in: ttyebus(O+) bnep hci_uart btbcm serdev bluetooth ecdh_generic 8021q garp stp llc brcmfmac spidev brcmutil sha256_generic cfg80211 raspberrypi_hwmon hwmon rfkill vc4 v3d drm_kms_helper gpu_sched drm bcm2835_codec(C) bcm2835_v4l2(C) v4l2_mem2mem drm_panel_orientation_quirks bcm2835_mmal_vchiq(C) snd_bcm2835(C) snd_soc_core v4l2_common videobuf2_dma_contig snd_compress videobuf2_vmalloc snd_pcm_dmaengine videobuf2_memops videobuf2_v4l2 snd_pcm videobuf2_common snd_timer i2c_bcm2835 syscopyarea sysfillrect snd videodev sysimgblt fb_sys_fops media rpivid_mem vc_sm_cma(C) spi_bcm2835 uio_pdrv_genirq uio fixed i2c_dev ip_tables x_tables ipv6
[ 1101.130166] CPU: 3 PID: 1343 Comm: insmod Tainted: G WC O 4.19.75-v7l+ #1270
[ 1101.130169] Hardware name: BCM2835
[ 1101.130177] [<c0212d10>] (unwind_backtrace) from [<c020d530>] (show_stack+0x20/0x24)
[ 1101.130183] [<c020d530>] (show_stack) from [<c097fb20>] (dump_stack+0xd4/0x118)
[ 1101.130189] [<c097fb20>] (dump_stack) from [<c0222330>] (__warn+0x104/0x11c)
[ 1101.130195] [<c0222330>] (__warn) from [<c0222480>] (warn_slowpath_null+0x50/0x58)
[ 1101.130201] [<c0222480>] (warn_slowpath_null) from [<c0219d08>] (__arm_ioremap_pfn_caller+0x188/0x214)
[ 1101.130208] [<c0219d08>] (__arm_ioremap_pfn_caller) from [<c0219dfc>] (__arm_ioremap_caller+0x68/0x70)
[ 1101.130214] [<c0219dfc>] (__arm_ioremap_caller) from [<c0219e5c>] (ioremap+0x30/0x38)
[ 1101.130223] [<c0219e5c>] (ioremap) from [<bfa64928>] (init_module+0xf8/0x17c [ttyebus])
[ 1101.130231] [<bfa64928>] (init_module [ttyebus]) from [<c02030cc>] (do_one_initcall+0x50/0x218)
[ 1101.130238] [<c02030cc>] (do_one_initcall) from [<c02bb8f4>] (do_init_module+0x74/0x220)
[ 1101.130244] [<c02bb8f4>] (do_init_module) from [<c02ba86c>] (load_module+0x1dc0/0x2404)
[ 1101.130251] [<c02ba86c>] (load_module) from [<c02bb0cc>] (sys_finit_module+0xbc/0xcc)
[ 1101.130257] [<c02bb0cc>] (sys_finit_module) from [<c0201000>] (ret_fast_syscall+0x0/0x28)
[ 1101.130261] Exception stack(0xd95affa8 to 0xd95afff0)
[ 1101.130265] ffa0: 684ef200 bee30764 00000003 0002d064 00000000 00000004
[ 1101.130270] ffc0: 684ef200 bee30764 0003fce8 0000017b 01823200 00000000 00000002 00000000
[ 1101.130274] ffe0: bee30598 bee30588 00022cb8 b6cbcaf0
[ 1101.130288] ---[ end trace 9a62985f777ab82a ]---
eine interesante seite hab ich auch gefunden:
https://www.raspberrypi.org/forums/viewtopic.php?t=244827
Bei mir hats keine eile, ich hab ein laufendes system auf RPI3 (mit selbst gebautem EBUS-Adapter), wollte aber mit dem neuen RPI-4 + rpi-ebus adapter auf ein neues system umsteigen.
PS: noch was gefunden, evtl für dich interessant, zum thema interrupts:
[ 0.843814] uart-pl011 fe201000.serial: cts_event_workaround enabled
[ 0.843892] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 34, base_baud = 0) is a PL011 rev2
[ 0.847254] fe215040.serial: ttyS0 at MMIO 0x0 (irq = 37, base_baud = 62500000) is a 16550
l.g. erwin
ich habe mir das jetzt einmal genauer bei meinem Raspi 4 angesehen.
Hier gibts einen Link (https://www.raspberrypi.org/forums/viewtopic.php?t=244827) wo näher auf den Raspi 4 darauf eingegangen wird.
pi@raspberrypi4:~ $ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
17: 0 0 0 0 GICv2 29 Level arch_timer
18: 52112619 41598324 41649563 42928511 GICv2 30 Level arch_timer
23: 341 0 0 0 GICv2 114 Level DMA IRQ
31: 1779937 0 0 0 GICv2 65 Level fe00b880.mailbox
34: 6555 0 0 0 GICv2 153 Level uart-pl011
37: 0 0 0 0 GICv2 72 Level dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb3
38: 0 0 0 0 GICv2 169 Level brcmstb_thermal
39: 1894498 0 0 0 GICv2 158 Level mmc1, mmc0
45: 0 0 0 0 GICv2 106 Level v3d
47: 30743307 0 0 0 GICv2 189 Level eth0
48: 10950011 0 0 0 GICv2 190 Level eth0
54: 114076 0 0 0 GICv2 66 Level VCHIQ doorbell
55: 0 0 0 0 GICv2 175 Level PCIe PME, aerdrv
56: 98106082 0 0 0 Brcm_MSI 524288 Edge xhci_hcd
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 26881451 47174422 46815699 48151291 Rescheduling interrupts
IPI3: 5313770 4831327 4762349 4775095 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 2767314 1761194 1739106 1875257 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
auf 34 habe ich hier den UART PL011 hängen.
pi@raspberrypi4:~ $ raspi-gpio funcs
GPIO, DEFAULT PULL, ALT0, ALT1, ALT2, ALT3, ALT4, ALT5
0, UP, SDA0, SA5, PCLK, SPI3_CE0_N, TXD2, SDA6
1, UP, SCL0, SA4, DE, SPI3_MISO, RXD2, SCL6
2, UP, SDA1, SA3, LCD_VSYNC, SPI3_MOSI, CTS2, SDA3
3, UP, SCL1, SA2, LCD_HSYNC, SPI3_SCLK, RTS2, SCL3
4, UP, GPCLK0, SA1, DPI_D0, SPI4_CE0_N, TXD3, SDA3
5, UP, GPCLK1, SA0, DPI_D1, SPI4_MISO, RXD3, SCL3
6, UP, GPCLK2, SOE_N_SE, DPI_D2, SPI4_MOSI, CTS3, SDA4
7, UP, SPI0_CE1_N, SWE_N_SRW_N, DPI_D3, SPI4_SCLK, RTS3, SCL4
8, UP, SPI0_CE0_N, SD0, DPI_D4, I2CSL_CE_N, TXD4, SDA4
9, DOWN, SPI0_MISO, SD1, DPI_D5, I2CSL_SDI_MISO, RXD4, SCL4
10, DOWN, SPI0_MOSI, SD2, DPI_D6, I2CSL_SDA_MOSI, CTS4, SDA5
11, DOWN, SPI0_SCLK, SD3, DPI_D7, I2CSL_SCL_SCLK, RTS4, SCL5
12, DOWN, PWM0_0, SD4, DPI_D8, SPI5_CE0_N, TXD5, SDA5
13, DOWN, PWM0_1, SD5, DPI_D9, SPI5_MISO, RXD5, SCL5
14, DOWN, TXD0, SD6, DPI_D10, SPI5_MOSI, CTS5, TXD1
15, DOWN, RXD0, SD7, DPI_D11, SPI5_SCLK, RTS5, RXD1
16, DOWN, -, SD8, DPI_D12, CTS0, SPI1_CE2_N, CTS1
17, DOWN, -, SD9, DPI_D13, RTS0, SPI1_CE1_N, RTS1
18, DOWN, PCM_CLK, SD10, DPI_D14, SPI6_CE0_N, SPI1_CE0_N, PWM0_0
19, DOWN, PCM_FS, SD11, DPI_D15, SPI6_MISO, SPI1_MISO, PWM0_1
20, DOWN, PCM_DIN, SD12, DPI_D16, SPI6_MOSI, SPI1_MOSI, GPCLK0
21, DOWN, PCM_DOUT, SD13, DPI_D17, SPI6_SCLK, SPI1_SCLK, GPCLK1
22, DOWN, SD0_CLK, SD14, DPI_D18, SD1_CLK, ARM_TRST, SDA6
23, DOWN, SD0_CMD, SD15, DPI_D19, SD1_CMD, ARM_RTCK, SCL6
24, DOWN, SD0_DAT0, SD16, DPI_D20, SD1_DAT0, ARM_TDO, SPI3_CE1_N
25, DOWN, SD0_DAT1, SD17, DPI_D21, SD1_DAT1, ARM_TCK, SPI4_CE1_N
26, DOWN, SD0_DAT2, -, DPI_D22, SD1_DAT2, ARM_TDI, SPI5_CE1_N
27, DOWN, SD0_DAT3, -, DPI_D23, SD1_DAT3, ARM_TMS, SPI6_CE1_N
28, NONE, SDA0, SA5, PCM_CLK, -, MII_A_RX_ERR, RGMII_MDIO
29, NONE, SCL0, SA4, PCM_FS, -, MII_A_TX_ERR, RGMII_MDC
30, DOWN, -, SA3, PCM_DIN, CTS0, MII_A_CRS, CTS1
31, DOWN, -, SA2, PCM_DOUT, RTS0, MII_A_COL, RTS1
32, DOWN, GPCLK0, SA1, -, TXD0, SD_CARD_PRES, TXD1
33, DOWN, -, SA0, -, RXD0, SD_CARD_WRPROT, RXD1
34, UP, GPCLK0, SOE_N_SE, -, SD1_CLK, SD_CARD_LED, RGMII_IRQ
35, UP, SPI0_CE1_N, SWE_N_SRW_N, -, SD1_CMD, RGMII_START_STOP, -
36, UP, SPI0_CE0_N, SD0, TXD0, SD1_DAT0, RGMII_RX_OK, MII_A_RX_ERR
37, DOWN, SPI0_MISO, SD1, RXD0, SD1_DAT1, RGMII_MDIO, MII_A_TX_ERR
38, DOWN, SPI0_MOSI, SD2, RTS0, SD1_DAT2, RGMII_MDC, MII_A_CRS
39, DOWN, SPI0_SCLK, SD3, CTS0, SD1_DAT3, RGMII_IRQ, MII_A_COL
40, DOWN, PWM1_0, SD4, -, SD1_DAT4, SPI0_MISO, TXD1
41, DOWN, PWM1_1, SD5, -, SD1_DAT5, SPI0_MOSI, RXD1
42, DOWN, GPCLK1, SD6, -, SD1_DAT6, SPI0_SCLK, RTS1
43, DOWN, GPCLK2, SD7, -, SD1_DAT7, SPI0_CE0_N, CTS1
44, NONE, GPCLK1, SDA0, SDA1, -, SPI0_CE1_N, SD_CARD_VOLT
45, NONE, PWM0_1, SCL0, SCL1, -, SPI0_CE2_N, SD_CARD_PWR0
46, UP, SDA0, SDA1, SPI0_CE0_N, -, -, SPI2_CE1_N
47, UP, SCL0, SCL1, SPI0_MISO, -, -, SPI2_CE0_N
48, UP, SD0_CLK, -, SPI0_MOSI, SD1_CLK, ARM_TRST, SPI2_SCLK
49, UP, SD0_CMD, GPCLK0, SPI0_SCLK, SD1_CMD, ARM_RTCK, SPI2_MOSI
50, UP, SD0_DAT0, GPCLK1, PCM_CLK, SD1_DAT0, ARM_TDO, SPI2_MISO
51, UP, SD0_DAT1, GPCLK2, PCM_FS, SD1_DAT1, ARM_TCK, SD_CARD_LED
52, UP, SD0_DAT2, PWM0_0, PCM_DIN, SD1_DAT2, ARM_TDI, -
53, UP, SD0_DAT3, PWM0_1, PCM_DOUT, SD1_DAT3, ARM_TMS, -
Moin
Wie waere es, wenn wir einfach einen RPI4 fuer galileo sammeln. Das haben wir bei HM-Teilen mit Martin auch schon gemacht.
Es reicht ja, dass er seine Zeit investiert, nicht auch noch sein Geld!
Gruss Christoph
ich wär mit 10€ dabei!
PS: ich habe heute den rpi-adapter erhalten, danke Reinhart & Galileo!
l.g. erwin
Zitat von: erwin am 04 Dezember 2019, 13:45:05
PS: ich habe heute den rpi-adapter erhalten, danke Reinhart & Galileo!
l.g. erwin
da staune ich, den habe ich erst am 02.12 versendet und das bei dem weihnachtlichen Poststress!
LG
Zitat von: erwin am 04 Dezember 2019, 13:45:05
ich wär mit 10€ dabei!
PS: ich habe heute den rpi-adapter erhalten, danke Reinhart & Galileo!
l.g. erwin
Von mirgibt es auch €5,-. Fuer mich ist das nicht so immens wichtig, aber da ich ja angefangen habe!
Gruss Christoph
Zitat von: pc1246 am 04 Dezember 2019, 13:00:57
Wie waere es, wenn wir einfach einen RPI4 fuer galileo sammeln.
Ich kann mich mit 5 EUR beteiligen.
Hallo Leute,
Vielen Dank für die angebotene finanzielle Hilfe für einen Raspi4, aber das ist überhaupt nicht notwendig.
Es ist viel mehr eine Frage der Zeit die mir zur Verfügung steht und ob ich damit das Problem lösen kann.
Ich versuche bereits seit Wochen eine generische Lösung für das Problem mit der Interrupt Zuordnung zu finden, bin aber bis jetzt kläglich gescheitert.
Viel besser als eine Spende wäre da ein richtiger Linux-Spezialist, der ich leider nicht bin, und der mir bei den Interrupts weiterhelfen könnte.
Trotzdem, ein Raspi4 zum Testen ist bereits unterwegs, und ich hoffe damit wenigstens wieder eine dedizierte Lösung zu finden, wenn schon nicht eine generelle.
Aber wie schon gesagt, den Rest dieses Jahres geht da leider gar nichts mehr...
Bis dahin bitte keinen Raspi4 für den ttyebus verwenden, sonder nur 1-3.
LG
Hallo Galileo,
danke für deine Bereitschaft, da nochmals Zeit zu investieren!
Ich hab etwas geforscht und folgendes herausgefunden:
Der BCM_2711 verwendet eine andere Base adresse, ich hab mich mal daraun versucht, aber mit den interupts bin ich nicht klar gekommen! Hier ein diff:--- //mh-qnap419p/Download/myFHEM_mods/ttyebus/ttyebusm.c_orig So Dez 8 08:52:26 2019
+++ //mh-qnap419p/Download/myFHEM_mods/ttyebus/ttyebusm.c So Dez 8 12:43:29 2019
@@ -57 +57 @@
-// #define DEBUG 1 // if uncommented, will write some debug messages to /var/log/kern.log
+#define DEBUG 1 // if uncommented, will write some debug messages to /var/log/kern.log
@@ -129,0 +130 @@ static int IrqCounter = 0;
+#define RASPI_4_PERI_BASE 0xFE000000 // RASPI 4
@@ -181,0 +183 @@ static int IrqCounter = 0;
+#define RASPI_4_UART_IRQ 87
@@ -183,0 +186 @@ static int IrqCounter = 0;
+#define RASPI_4_UART_IRQ 81
@@ -818,0 +822 @@ unsigned int ttyebus_raspi_model(void)
+ case '4' : return 4; break;
@@ -854 +858 @@ int ttyebus_register(void)
- if (RaspiModel < 1 || RaspiModel > 3)
+ if (RaspiModel < 1 || RaspiModel > 4)
@@ -887 +891 @@ int ttyebus_register(void)
- PeriBase = (RaspiModel == 1) ? RASPI_1_PERI_BASE : RASPI_23_PERI_BASE;
+ PeriBase = (RaspiModel == 1) ? RASPI_1_PERI_BASE : (RaspiModel == 4) ? RASPI_4_PERI_BASE : RASPI_23_PERI_BASE;
@@ -901 +905 @@ int ttyebus_register(void)
- UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : RASPI_23_UART_IRQ;
+ UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : (RaspiModel == 4) ? RASPI_4_UART_IRQ : RASPI_23_UART_IRQ;
@@ -948 +952,2 @@ void ttyebus_unregister(void)
- UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : RASPI_23_UART_IRQ;
+// UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : RASPI_23_UART_IRQ;
+ UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : (RaspiModel == 4) ? RASPI_4_UART_IRQ : RASPI_23_UART_IRQ;
Die Int's sind miseriös: Enable ich den Uart, bekomm ich int 34 auf dem PL-011.
Disable ich den Uart, bekommt der SPI-Bus den Int 34.....
irgenwas mit den GPIO setting dürfte auch anders sein, siehe hier:
https://github.com/RPi-Distro/raspi-gpio/blob/master/raspi-gpio.c (https://github.com/RPi-Distro/raspi-gpio/blob/master/raspi-gpio.c)
Bin nicht sicher ob das weiterhilft...
l.g. erwin
Hallo erwin,
danke für deine Bemühungen. Genau das ist ja das Problem: Die Interrupts werden vom Linux dynamisch zugewiesen, je nach vorhandener Konfiguration.
Nur leider konnte ich bis heute weder herausfinden, nach welcher Logik das stattfindet, noch konnte ich die aktuelle Zuweisung aus dem Kernel auslesen, *bevor* der ttyebus geladen wird.
Und das in der Literatur vorgeschlagene try-and-error Verfahren bei laufendem Treiber hat mir das System jedes Mal permanent gecrasht.
Der Interrupt 34 ist jedenfalls bisher noch nicht vorgekommen. Bisher waren es 81 und 87, aber da war die Hardware auch immer (fast) ident.
Dass die GPIOs anders belegt sind würde mich auch nicht wundern, weil der Raspi4 ja jetzt 5 UARTs hat. Da gibt's aber auch schon genügend Postings und Beschreibungen dazu.
Das alles gilt es also zu checken.
LG
Ich besitze jetzt einen Raspi 4 und habe mich nun intensiv mit dem ttebus/Raspi 4 Problem beschäftigt.
Es gibt dazu einige Erkenntnisse:
- Der Raspberry Pi 4 benötigt zwingend Raspbian Buster.
- Der von HeikoGr gemeldete Fehler beim "sudo make install" ist darauf zurückzuführen, dass "insmod $(TARGET_DIR)/$(TARGET_MODULE).ko" nunmehr kein ".ko" mehr haben darf.
In den Versionen vor Buster musste es aber zwingend vorhanden sein. Eine mögliche Lösung des Problems wäre "modprobe" statt "insmode" verwenden, dort gibt's das Problem nicht.
- Die "Peripheral Base Address" ist bei Buster/Raspi4 nunmehr auf 0xFE000000 gewandert.
- Der I/O Address-Space hat sich in der Größe verdoppelt.
- Die UART Interrupt Behandlung im Raspbian Buster ist komplett umgestellt, soweit ich das beurteilen kann ist das jetzt ein "chained" model.
Die direkten Interrupts verschwinden dadurch und können auch nicht mehr manipuliert werden. Damit erhält der ttyebus keine Interrupts mehr.
Da der Raspberry Pi 4 aber zwingend ein Raspbian Buster voraussetzt, kann der ttyebus auf diesem Board nicht funktionieren.
Ob Raspbian Buster auf einem Raspi 3 auch die Interrupts verändert oder vielleicht doch gleich lässt, habe ich noch nicht getestet.
Ich muss also leider alle Raspi4 Besitzer enttäuschen: ttyebus funktioniert auf Raspi 4 nicht, und wird vermutlich auch nie funktionieren.
Für ttyebus auf Raspi 1-3 muss ich momentan warnen, auf Raspbian Buster upzugraden oder es zu verwenden, das könnte eventuell zu Problemen führen.
LG
Zitat von: galileo am 17 Dezember 2019, 10:40:58
Für ttyebus auf Raspi 1-3 muss ich momentan warnen, auf Raspbian Buster upzugraden oder es zu verwenden, das könnte eventuell zu Problemen führen.
ttyebus hat bei mir problemlos unter Raspbian Buster funktioniert (Hardware: Raspi 3B+ mit Aufsteckplatine)
Hier:
https://www.raspberrypi.org/forums/viewtopic.php?t=248772
wird auch über den Interrupt für den UART diskutiert.
Mit Verweis auf die Sourcen:
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2838.dtsi#L712
Wird als zuständiger Interrupt 121 genannt.
Ich kenne mich (leider) zu wenig mit Hardwarenaher Programmierung aus, aber hilft das?
Hallo HeikoGr
Ich kannte das schon, es hilft leider nicht viel. Es geht hier wahrscheinlich darum, dass die Interrupt Nummern über den Device Tree irgendwie zusammengebaut werden.
Wenn man jetzt das Device ttyAMA0 wegnimmt, dann verschwindet auch diese "errechnete" Interrupt Nummer, die aber offensichtlich nichts mit der Realität zu tun hatte.
Deshalb kann man diese Nummer auch nicht ganz simpel für den ttyebus weiterverwenden, so wie es früher funktioniert hat. Und das ganze "korrekt" über den Device Tree
neu einzubinden übersteigt meine Fähigkeiten bei weitem.
Zitatttyebus hat bei mir problemlos unter Raspbian Buster funktioniert (Hardware: Raspi 3B+ mit Aufsteckplatine)
Das wäre toll wenn das wirklich funktioniert. Könntest du bitte zur Sicherheit noch ein "cat /proc/interrupts" eingeben und schauen, welchen Interrupt der ttyebus bekommen hat?
Sollte eigentlich auf 81 liegen.
Und wie hast du den Fehler bei "sudo make install" wegbekommen? Auch mit modprobe ? Weil wenn das alles klar ist, dann bessere ich das im Repository aus.
LG
Hallo Galileo,
ich kann bestätigen, das der Adapter mit buster / raspi 3b+ funktioniert!
ein cat /proc/interrupt ergibt: 81: 1221 0 0 0 ARMCTRL-level 89 Edge ttyebus_irq_handler
Ich hab ihn zwar noch nicht an der Vaillant dran, aber mit einem Netzteil (& 470 Ohm Wid) kann ich senden und das echo sehen (inkl. led's blinken).
Dieselbe SD Karte im RPI-4 geht definitiv nicht, auch probiert mit int 121....
alles mit: Linux MH-RPI-12 4.19.75-v7+ getestet.
l.g. erwin
Kann ich leider nicht unter real Bedingungen machen, da ich die rpi ebus platine weitervererbt habe und auf die esp variante umgestiegen bin :-[
Was ich machen kann ist evtl. heute abend ttyebus auf meinem derzeit arbeitslosen rpi 3b+ Unter buster zu installieren. Aber ohne Platine am gpio...
so weit ich mich erinnere kam zwar die Fehlermeldung - das Modul wurde dennoch installiert. Kann ich heute abend (evtl.) testen.
Moin Moin Leute,
ich wollte mich jetzt auch so langsam an meinen eBus wagen und habe vorab eine Frage.
Ich habe hier noch einen Pi 1 Model B und einen Pi 2 Model B Version 1.1 liegen.
Kann man die benutzen oder sollte man sich einen neuen besorgen?
Und welche raspbian Version sollte man nehmen?
PI 2 B ist doch ideal und nimm die letzte Debian Version, also Buster!
LG
Reinhart
Mit Buster mag es eventuell noch das bereits geschilderte Problem mit modprobe/insmode geben. Also bitte selbst ausbessern oder bis nächste Woche warten,
da wird es Dank chons eine neue Version von ttyebus und dem make Programm geben, die hoffentlich alle Kombinationen von Raspi und Raspbian abdecken kann.
Es fehlen derzeit nur noch einige Tests.
Es gibt eine neue Version V1.7 des ttyebus Treibers (https://github.com/eBUS/ttyebus).
Dank der Hilfe von chons ist es nun doch gelungen, die Besonderheiten des Raspi 4 zu berücksichtigen.
Diese entstehen hauptsächlich durch die nunmehr fünf UARTs im System, die sich einen gemeinsamen Interrupt teilen sowie einen Eintrag in config.txt den Buster absetzt.
Der Treiber sowie das Installationsprogramm decken jetzt alle Varianten von Raspi 1 bis 4 sowie Raspbian bis inklusive Buster ab.
Bitte die Installationsanleitung genau beachten, insbesondere Raspi 4 Benutzer müssen darauf achten dass die Zeile "enable_uart=0" aus config.txt entfernt wird.
LG
Ihr seid super cool! Danke Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Hallo,
hab ich das richtig gelesen das man bei Buster die Stretch-Images verwenden kann ?
Weiter hätt ich eine OT Frage, spricht etwas dagegen zusätzlich zum ebusd noch den Unifi-Controller (sonst nichts, auch kein FHEM) auf einem Raspberry Pi 2b zu installieren ?
Gruß
Thomas
Zitat von: TomLee am 14 Januar 2020, 12:31:46
hab ich das richtig gelesen das man bei Buster die Stretch-Images verwenden kann ?
ja
Zitat von: TomLee am 14 Januar 2020, 12:31:46
Weiter hätt ich eine OT Frage, spricht etwas dagegen zusätzlich zum ebusd noch den Unifi-Controller (sonst nichts, auch kein FHEM) auf einem Raspberry Pi 2b zu installieren ?
spricht nichts dagegen
Hallo Zusammen,
da ich bisher nur bestellt und mich sonst nicht gemeldet habe, hier eine kurze Rückmeldung und Beschreibung meiner Lösung.
Wie verbinde ich mich?
Ich komme so gesehen von der Konkurrenz aus dem KNX Forum und habe für edomi (http://edomi.de/) einen Logikbaustein (http://service.knx-user-forum.de/?comm=download&id=19000175) zur Nutzung des eBus geschrieben.
Seit 2017 war ich mit dem ESERA eBUS Koppler Ethernet unterwegs.
Trotz tollem Support durch @john30 in github und Umstellung von TCP auf UDP war die Anbindung nie stabil. Ich hatte sogar eine Logik, die in Reihenfolge ebusd gestoppt, den Koppler neugestartet und dann den ebusd wieder gestartet hat. Auf der Suche nach der idealen Poti Einstellung bin ich endlich hier gelandet.
Vielen Dank an @Reinhart für den megaschnellen Versand zur Weihnachtszeit.
Gestern habe ich dann endlich Buster auf eine SD gezogen und in einer Raspberry Pi Model B Rev 2 gestartet.
Installation nach Reihenfolge, Platine aufgesteckt und direkt anstelle des Kopplers provisorisch im Schaltschrank an den eBus gehangen, IP gewechselt und los. Das ganze hat keine 2h gedauert - apt-get upgrade dauerte am längsten.
Was soll ich sagen: Lesen / Schreiben lief sofort und super stabil! Meine Logik zum Filtern fehlerhafter Nachrichten und zum Nachsenden, weil writes nicht ankamen, kann ich einstampfen.
Vielen lieben Dank noch mal - das kommt jetzt noch vernünftig in ein REG Gehäuse und gut.
Was mache ich mit dem eBus?
Gas sparen! Per Default möchte die Wasserstation bei gewünschten 50°C Wassertemperatur den Speicher auf >75°C aufheizen.
Hintergrund ist Komfort, aber was möchte man dann bitte noch mit Solar erreichen? Darum trennen die meisten Techniker die Wasserstation vom eBus oder stellen sehr kurze Heizzeiten ein.
Ich heize nur, wenn die Temperatur im oberen Segment unter eine Schwelle von 45°C fällt und stoppe bei 50°C - also nur bei Bedarf stelle ich die Betriebsart des HWC auf on.
Im Urlaub heize ich nicht und auch nicht, wenn Solarertrag erwartet wird bzw. ändere die Schwellwerte. Darum hatte ich mit der ESERA Lösung auch immer Sorge morgens kalt zu duschen ;-)
Werte lesen, sichern und darstellen (alle 10min)! Ich hatte sehr viele Probleme mit der Solaranlage und konnte Vaillant mit großen Datenmengen versorgen.
Komfort! Die FBH läuft bei Bedarf (wenn ein Raum geheizt werden soll), nicht nach Zeitfenster. Wenn also alle Räume warm genug sind, wird die Pumpe auch abgeschaltet. Über Heizkurve und AT-Abschaltung, kann ich selbst bei hohen Außentemperaturen einen gewärmten Fußboden im Bad erreichen - super WAF :-)
Wie sieht das aus?
Screenshots zur Darstellung der Daten findet Ihr hier (https://knx-user-forum.de/forum/projektforen/edomi/989086-vcontrold-d%C3%A4mon-f%C3%BCr-viessmann-heizungssteuerungen-f%C3%BCr-edomi?p=1299927#post1299927).
EDIT: Lade die Bilder auch hier hoch, da man sie ohne Account im anderen Forum nicht sieht:
Sorry, ist lang geworden; ich hoffe das passt halbwegs in den Thread.
Viele Grüße,
Patrick
Zitat von: stoxn am 25 Januar 2020, 21:31:06
Screenshots zur Darstellung der Daten findet Ihr hier (https://knx-user-forum.de/forum/projektforen/edomi/989086-vcontrold-d%C3%A4mon-f%C3%BCr-viessmann-heizungssteuerungen-f%C3%BCr-edomi?p=1299927#post1299927).
Cool, Danke fürs Teilen Deiner Erfahrungen!
Nur die Links auf die Screenshots scheinen leider nicht zu funktionieren.
Zitat von: john30 am 26 Januar 2020, 10:09:41
Nur die Links auf die Screenshots scheinen leider nicht zu funktionieren.
Danke für den Hinweis! Denke mal, dass man im KNX Forum angemeldet sein muss.
Ich habe die Bilder in meinem Post angehangen, so dass hier auch alle was sehen können - Screenshots anderer User helfen mir auch immer sehe bei der Umsetzung neuer Ideen 8)
Hallo
Ich brauche mal eure Hilfe. Habe die Platine in Betrieb genommen. Ich finde nur, dass erstaunlich wenig Werte über den eBus kommen. An der Vaillant Therme (2016) sehe ich noch einige Infos mehr.
Muss ich mich damit abfinden oder habe ich noch etwas vergessen bzw. falsch gemacht?
ebusctl find -d -v
700 Hc1HeatCurve = =0.75
bai DateTime = dcfstate=valid;btime=19:48:00;bdate=28.01.2020;temp2=3.250
bai FlowTemp = temp=27.56;sensor=ok
bai SetMode = hcmode=auto;flowtempdesired=0.0;hwctempdesired=-;hwcflowtempdesired=-;disablehc=1;disablehwctapping=0;disablehwcload=0;remoteControlHcPump=0;releaseBackup=0;releaseCooling=0
bai Status01 = temp1=28.0;temp1=28.5;temp2=3.250;temp1=39.5;temp1=54.5;pumpstate=off
bai Status02 = hwcmode=auto;temp0=60;temp1=50.0;temp0=70;temp1=65.0
broadcast outsidetemp = temp2=3.250
broadcast vdatetime = time=19:48:00;date=28.01.2020
scan.06 = MF=Vaillant;ID=VMS01;SW=0116;HW=0303
scan.08 = MF=Vaillant;ID=BAI00;SW=0116;HW=9602
scan.08 id = prefix=21;year=16;week=06;product=0010015609;supplier=3100;counter=005102;suffix=N9
scan.15 = MF=Vaillant;ID=70000;SW=0209;HW=4103
scan.15 id = prefix=21;year=16;week=11;product=0020171314;supplier=0082;counter=013315;suffix=N7
scan.ed = MF=Vaillant;ID=VMS01;SW=0116;HW=0303
scan.ed id = prefix=??;year=??;week=??;product=??????????;supplier=????;counter=??????;suffix=??
ebusctl find -d
700 Hc1HeatCurve = 0.75
bai DateTime = valid;19:57:01;28.01.2020;3.250
bai FlowTemp = 27.56;ok
bai SetMode = auto;0.0;-;-;1;0;0;0;0;0
bai Status01 = 29.0;29.0;3.250;39.5;54.5;off
bai Status02 = auto;60;50.0;70;65.0
broadcast outsidetemp = 3.250
broadcast vdatetime = 19:57:00;28.01.2020
scan.06 = Vaillant;VMS01;0116;0303
scan.08 = Vaillant;BAI00;0116;9602
scan.08 id = 21;16;06;0010015609;3100;005102;N9
scan.15 = Vaillant;70000;0209;4103
scan.15 id = 21;16;11;0020171314;0082;013315;N7
scan.ed = Vaillant;VMS01;0116;0303
scan.ed id = ??;??;??;??????????;????;??????;??
ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
signal: acquired
symbol rate: 23
max symbol rate: 135
min arbitration micros: 11
max arbitration micros: 37
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 4
messages: 602
conditional: 2
poll: 0
update: 9
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=VMS01;SW=0116;HW=0303"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/bai.0010015600.inc" ([PROD='0010015609']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ed: slave, scanned "MF=Vaillant;ID=VMS01;SW=0116;HW=0303"
es wurden zwei CSV Definitionen geladen mit insgesamt 602 messages, also Werte die Du auslesen und manche davon schreiben kannst.
Die Werte die Du aktuell siehst, sind nur die die per Broadcast geschickt und dekodiert bzw. interpretiert wurden.
Du musst die entsprechenden Werte (die findest Du per "find" heraus) "aktiv" abfragen.
Wie sieht es eigentlich mit der Polung des ebus-Anschlusses aus?
Ich würde gerne eine Wolf CWL 300 Excellent anschließen und im Handbuch steht:
"In Zusammenhang mit der Polaritäsempfindlichkeit immer die
Kontakte X1-1 mit X1-1 verbinden und die Kontakte X1-2 mit
X1-2 verbinden. Beim Vertauschen der Kontakte wird das Gerät
nicht funktionieren!"
Könnte sich aber auch auf das darin beschriebene Bedienmodul beziehen.
Hat jemand das gleiche Problem?
Beim eBus darf man grundsätzlich immer nur Plus mit Plus und Minus mit Minus verbinden.
Alle hier beschriebenen Schaltungen, also auch der RPI Print haben am Bus-Eingang einen Brückengleichrichter, der die richtige Polung automatisch herstellt, egal wie man den Bus anschließt.
Das mag für andere Produkte aber durchaus nicht der Fall sein.
Zitat von: chons am 28 Januar 2020, 20:42:50
es wurden zwei CSV Definitionen geladen mit insgesamt 602 messages, also Werte die Du auslesen und manche davon schreiben kannst.
Die Werte die Du aktuell siehst, sind nur die die per Broadcast geschickt und dekodiert bzw. interpretiert wurden.
Du musst die entsprechenden Werte (die findest Du per "find" heraus) "aktiv" abfragen.
Das wars! Vielen Dank für deine Hilfe! ;D
Ich habe jetzt noch ein Problem und hoffe, dass mir geholfen werden kann :)...
Ich setze den ioBroker ein und sehe die vielen Objekte/Werte, welche über den eBus kommen.
Aber die Werten werden im ioBroker nicht aktualisiert. Nur wenn ich diesen Befehl, den ich irgendwo gefunden habe, ausführe, werden die Werte im ioBroker aktualisiert....
ebusctl find | grep -vE "^(broadcast|memory|scan[. ])" | cut -sd "=" -f 1 | sed "s/^/ebusctl read -c /" >/tmp/$$TMPFILE ; . /tmp/$$TMPFILE ; rm /tmp/$$TMPFILENun weiß ich nicht warum das so ist. Muss ich die Ursache im ioBroker oder im eBus Daemon suchen? Vielleicht hat Jemand auch einen konkreten Hinweis für mich?
Zitat von: Sandmanyz am 30 Januar 2020, 07:07:36
Nun weiß ich nicht warum das so ist. Muss ich die Ursache im ioBroker oder im eBus Daemon suchen? Vielleicht hat Jemand auch einen konkreten Hinweis für mich?
das hat chons doch schon erklärt: die Werte müssen explizit abgefragt werden. Wenn iobroker das nicht macht, dann klingt das nach nem Design Fehler
Zitat von: galileo am 29 Januar 2020, 13:08:14
Beim eBus darf man grundsätzlich immer nur Plus mit Plus und Minus mit Minus verbinden.
Alle hier beschriebenen Schaltungen, also auch der RPI Print haben am Bus-Eingang einen Brückengleichrichter, der die richtige Polung automatisch herstellt, egal wie man den Bus anschließt.
Das mag für andere Produkte aber durchaus nicht der Fall sein.
Danke Dir! Es ist also völlig egal was die Gegenseite macht, mit den Adaptern aus dem Forum ist eine Verpolung ausgeschlossen :D
Habe nun alles am Laufen. War, wie zu erwarten ein Konfigurationsproblem meinerseits (im ioBroker). Werte auslesen klappt und sie werden auch aktualisiert. Danke an alle Beteiligten! :D
Ich habe noch ein Problem mit dem Schreiben (SetMode) und habe dazu auch einige Beiträge, u.a. bei Github, gelesen.Zum Beispiel diesem hier: https://github.com/john30/ebusd/issues/179 (https://github.com/john30/ebusd/issues/179). Leider besitzt mein Gehirn gerade nicht die Fähigkeit die ganzen Zusammenhänge zu verstehen ::).
Meine Vaillant Heizung (inkl. VR 700) hat Sonderbetriebsarten welche alle mit "SetMode auto;30;-;-;0;0;0;0;0;0" aktiviert oder deaktiviert werden. So wird bspw. Stoßlüften mit "auto;0.0;-;-;1;0;0;0;0;0" aktiviert und mit "SetMode auto;30;-;-;0;0;0;0;0;0" deaktiviert. Dies konnte ich mit "listen" sehen.
ebusctl read -v -c bai SetMode
bai SetMode hcmode=auto;flowtempdesired=25.0;hwctempdesired=-;hwcflowtempdesired=-;disablehc=0;disablehwctapping=0;disablehwcload=0;remoteControlHcPump=0;releaseBackup=0;releaseCooling=0
Dem Github Beitrag konnte ich nun entnehmen, dass der Wert nicht schreibbar ist weil es in der Datei "hcmode.inc" so definiert ist. Wenn ich jedoch das "u" am Anfang entferne, sollte es funktionieren. Vermutlich werden die gesetzten Werte dann vom VR 700 wieder überschrieben. Habe ich das bis hierher richtig verstanden?
Zitatuw,,SetMode,Betriebsart,,,,00,,,hcmode,,,,flowtempdesired,,temp1,,,,hwctempdesired,,temp1,,,,hwcflowtempdesired,,temp0,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2,,,,
Jetzt nicht böse werden wenn ich daneben liege...
Im Normalfall bezieht der ebusd seine Konfigurationsdateien automatisch (ab Version 3.2). Sofern ich die Dateien lokal liegen haben bzw. anpassen möchte (um bspw. das besagte "u" zu entfernen), muss ich in der Datei ebuds den Pfad festlegen "--configpath=/etc/ebusd". Ist das richtig?
Oder gibt es evtl. andere Möglichkeiten die Sonderbetriebsarten zu aktivieren?
Zitat von: Sandmanyz am 01 Februar 2020, 13:16:36
Habe nun alles am Laufen. War, wie zu erwarten ein Konfigurationsproblem meinerseits (im ioBroker). Werte auslesen klappt und sie werden auch aktualisiert. Danke an alle Beteiligten! :D
Ich habe noch ein Problem mit dem Schreiben (SetMode) und habe dazu auch einige Beiträge, u.a. bei Github, gelesen.Zum Beispiel diesem hier: https://github.com/john30/ebusd/issues/179 (https://github.com/john30/ebusd/issues/179). Leider besitzt mein Gehirn gerade nicht die Fähigkeit die ganzen Zusammenhänge zu verstehen ::).
Meine Vaillant Heizung (inkl. VR 700) hat Sonderbetriebsarten welche alle mit "SetMode auto;30;-;-;0;0;0;0;0;0" aktiviert oder deaktiviert werden. So wird bspw. Stoßlüften mit "auto;0.0;-;-;1;0;0;0;0;0" aktiviert und mit "SetMode auto;30;-;-;0;0;0;0;0;0" deaktiviert. Dies konnte ich mit "listen" sehen.
ebusctl read -v -c bai SetMode
bai SetMode hcmode=auto;flowtempdesired=25.0;hwctempdesired=-;hwcflowtempdesired=-;disablehc=0;disablehwctapping=0;disablehwcload=0;remoteControlHcPump=0;releaseBackup=0;releaseCooling=0
Dem Github Beitrag konnte ich nun entnehmen, dass der Wert nicht schreibbar ist weil es in der Datei "hcmode.inc" so definiert ist. Wenn ich jedoch das "u" am Anfang entferne, sollte es funktionieren. Vermutlich werden die gesetzten Werte dann vom VR 700 wieder überschrieben. Habe ich das bis hierher richtig verstanden?
Jetzt nicht böse werden wenn ich daneben liege...
Im Normalfall bezieht der ebusd seine Konfigurationsdateien automatisch (ab Version 3.2). Sofern ich die Dateien lokal liegen haben bzw. anpassen möchte (um bspw. das besagte "u" zu entfernen), muss ich in der Datei ebuds den Pfad festlegen "--configpath=/etc/ebusd". Ist das richtig?
Oder gibt es evtl. andere Möglichkeiten die Sonderbetriebsarten zu aktivieren?
alles richtig soweit, d.h. du musst das config repo clonen, deine Anpassungen machen und ebusd auf die lokale Kopie konfigurieren.
Zitat von: john30 am 05 Februar 2020, 07:34:55
alles richtig soweit, d.h. du musst das config repo clonen, deine Anpassungen machen und ebusd auf die lokale Kopie konfigurieren.
Ich Danke Dir!
Heute bin ich, wegen zu wenig Arbeitsspeicher, von einem Raspberry 3 auf einen Raspberry 4 umgestiegen. Leider werden auf dem Raspi 4 keine Werte mehr ausgelesen/angezeigt.
Mit "ls -l /dev" wird kein ttyAMA0 mehr angezeigt, "ttyebus" ist aufgeführt. lsmod zeigt ebenfalls "ttyebus | 16384 | 1".
Auszug aus dem syslog:
systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems...
.
.
.
kernel: [ 1.974179] ttyebus: loading out-of-tree module taints kernel.
kernel: [ 1.975199] ttyebus: Found RASPI model 4
kernel: [ 1.975568] ttyebus: Successfully requested IRQ 34
ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
access: *
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
Was kann ich tun damit's beim Raspi 4 genauso wie beim Raspi 3 funktioniert?
Zitat von: Sandmanyz am 05 Februar 2020, 11:47:16
Was kann ich tun damit's beim Raspi 4 genauso wie beim Raspi 3 funktioniert?
Hast du dich an die Anleitung (https://github.com/ebus/ttyebus#install) für RPI4 gehalten?
Poste bitte deine
/boot/config.txt
Ich bin ganz ehrlich, ich habe das fett geschriebene "Raspberry 4" übersehen :o. Ich danke dir für den Hinweis, es läuft nun :)
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.
Hallo,
ich bin nun auch dazu gekommen meinen eBus Adapter für Raspberry v2.2 in Betrieb zu nehmen. (Raspberry Pi 1B)
Leider bisher noch nicht so erfolgreich.
Angeschlossen ist er an eine Vaillant Ecotec.
Im Ebusd Log steht:
2020-06-06 17:40:49.034 [bus error] signal lost
2020-06-06 17:40:49.150 [bus notice] signal acquired
2020-06-06 17:40:51.014 [bus error] signal lost
2020-06-06 17:40:51.172 [bus notice] signal acquired
ebusctl i sagt:
version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
signal: acquired
symbol rate: 0
max symbol rate: 42
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
Die LED1 ist nur ab und zu kurz am blinken.
Wenn ich den Raspberry neustarte und den ebusd noch nicht gestartet habe blinkt die LED1 die ganze Zeit sehr schnell (so als wäre viel auf dem Bus los). Sobald der ebusd gestartet wird (starte ich noch von Hand) kommt wieder das ab und zu blinken.
Mache ich da irgendwas grundsätzlich falsch?
Nachdem ich jetzt an der Heizung (die hat eine zusätzliche Calormatic 470 Steuerung) etwas mache, fängt die LED1 wieder schnell an zu blinken und jetzt tauchen auch plötzlich etwas sinnvollere? Einträge im ebusd.log auf:
2020-06-06 17:53:43.881 [main error] scan config 08: ERR: wrong symbol received
2020-06-06 17:53:45.903 [main error] scan config 15: ERR: wrong symbol received
2020-06-06 17:53:49.982 [update notice] received unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2020-06-06 17:53:50.250 [update notice] received unknown MS cmd: 1008b5110101 / 095458f00eff800000ff
2020-06-06 17:53:50.509 [update notice] received unknown MS cmd: 1008b5110102 / 06033c96468c6e
2020-06-06 17:53:54.012 [update notice] received unknown MS cmd: 1008b5110101 / 095458f00eff800000ff
2020-06-06 17:53:56.013 [update notice] received unknown MS cmd: 1008b5040100 / 0a0357531806060620200f
2020-06-06 17:53:57.919 [main error] scan config 08: ERR: wrong symbol received
2020-06-06 17:53:59.977 [update notice] received unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2020-06-06 17:53:59.995 [main error] scan config 15: ERR: wrong symbol received
2020-06-06 17:54:03.991 [update notice] received unknown MS cmd: 1008b5110101 / 095458200fff800000ff
2020-06-06 17:54:05.963 [update notice] received unknown MS cmd: 1008b5100305ff01 / 0101
ebusctl i sagt seitdem:
version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
signal: no signal
reconnects: 1
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
Nach kurzer Zeit (ich schätze mal, wenn die Calormatic in Standby geht. Lande ich wieder bei obigem Wechsel zwischen "Signal lost" und "Signal acquired".
Wie kann ich weiter vorgehen?
Edit:
Mittlerweile habe ich noch folgende Einträge im ebusd-Log gefunden
2020-06-08 04:59:13.451 [update notice] received unknown BC cmd: 10feb516080013590508060120
2020-06-08 04:59:13.668 [update notice] received unknown BC cmd: 10feb5160304e00e
2020-06-08 04:59:22.259 [main error] scan config 08: ERR: arbitration lost
2020-06-08 04:59:28.897 [main error] scan config 15: ERR: arbitration lost
2020-06-08 04:59:43.810 [main error] scan config 08: ERR: arbitration lost
2020-06-08 04:59:46.732 [main error] scan config 15: ERR: arbitration lost
so wie du das schilderst, scheint die Hardware in Ordnung zu sein, denn wenn der eBus am Konverter hängt funktioniert noch alles (blinken)!
Die Probleme beginnen sobald du den Dämon startest.
Ich glaube eher, das der Fehler in der Software liegt. Hast du den schon einmal nachgesehen ob der ttyebus Treiber auch wirklich ordentlich installiert ist?
ls -l /dev
hier muss der ttyebus Treiber sichtbar sein, und der AMA0 verschwunden!
Checke das bitte nochmals und schau eventuell im Syslog ( var/log/syslog ) ob da Ungereimtheiten betreffend ttyebus auftauchen.
Und poste bitte einmal deine Config ( etc/default/ebusd ).
LG
Hallo,
möchte ebusd mit einem symbolischen link an "ttyEBUS" starten, dazu habe ich --device=/dev/ttyEBUS als Option mitgegeben.
Leider findet er das device nicht (log-ebus):
2020-06-11 13:29:10.357 [bus error] unable to open /dev/ttyEBUS: ERR: element not found
ttyEBUS ist aber unter /dev gelistet und mit Rechten 777 angelegt ...
Das device heißt "ttyebus" und nicht ttyEBUS.
Zitat von: HaWe68 am 11 Juni 2020, 13:30:29
Hallo,
möchte ebusd mit einem symbolischen link an "ttyEBUS" starten, dazu habe ich --device=/dev/ttyEBUS als Option mitgegeben.
Leider findet er das device nicht (log-ebus):
2020-06-11 13:29:10.357 [bus error] unable to open /dev/ttyEBUS: ERR: element not found
ttyEBUS ist aber unter /dev gelistet und mit Rechten 777 angelegt ...
wie Galileo dir schon geschrieben hat stimmt die Schreibweise nicht, steht das irgendwo so geschrieben, wenn ja dann sage uns wo damit wir das ausbessern können!
Habe selbst den symbolischen Link per RULES angelegt, daher ttyEBUS
warum hast du den Link händisch angelegt, das wird doch alles bei Treiberinstallation automatisch durchgeführt?
Hat die Treiberinstallation denn nicht korrekt funktioniert?
Ist hier (https://github.com/ebus/ttyebus) beschrieben.
LG
Ich habe mir dieses Wochenende endlich mal Zeit genommen, den Adapter, den Reinhart mir bereits im Herbst zugesendet hat, in Betrieb zu nehmen. Nach 2 Tagen Lesen, Suchen und Ausprobieren funktioniert nun alles so, wie ich es mir (zunächst) vorstelle. An dieser Stelle ein riesiges Lob für die super Arbeit, die in Planung, Entwicklung und Bestellabwicklung des Adapters, in die Entwicklung des ebusd, den tollen Support hier im Forum und die ganzen Arbeiten im Hintergrund, die man nicht direkt sieht, geflossen ist! Das, was hier einige Freiwillige in ihrer Freizeit auf die Beine gestellt haben, muss sich auch vor großen kommerziellen Projekten nicht verstecken!
Für die, die nach mir vor den gleichen Problemen stehen sollten, hier ein paar Tipps und Erfahrungen, worüber ich gestolpert bin:
* Die aktuelle Version des ebusd unterstützt laut dem, was ich gelesen habe, einige Geräte out-of-the-box inkl. automatischer Erkennung und Download des passenden .csv. Leider gilt das scheinbar nicht für die Viessmann Vitovent 300-W, ich musste ein passendes .csv manuell aktivieren. Die Dateien von https://github.com/dstrigl/ebusd-config-brink-renovent-excellent-300 haben bei mir nicht funktioniert, dafür das auf der Seite dort ganz unten verlinkte .csv von paddyx von mikrocontroller.net.
* Ich bin über das Problem gestolpert, dass FHEM mir nach jedem Restart des ebusd ein neues MQTT2_DEVICE nach dem Namensschema ebusd_Version_Zeitstempel angelegt hat. Das konnte ich beheben, indem ich in der Datei /etc/default/ebusd den Parameter --mqttclientid=ebusd hinzugefügt habe.
* Das Vorgehen bzgl. der Templates, das im Wiki unter https://wiki.fhem.de/wiki/EBUS-MQTT2 (https://wiki.fhem.de/wiki/EBUS-MQTT2) beschrieben ist, hat bei mir nicht so recht geklappt, vielleicht einfach, weil es für mein Gerät kein passendes Template gibt oder schlicht das Namensschema in der .csv nicht passt (evtl. ist ein Namensschema erforderlich, das die von ebusd automatisch heruntergeladenen .csv Dateien erfüllen). Lässt sich aber meiner Erfahrung nach auch gut manuell ohne Template anlegen, ich habe autocreate auf complex gesetzt, dann den ebusd gestartet und bin dann im Bedienteil der Lüftung durch die beiden Info-Menüs gegangen. Dadurch schickt das Bedienteil entsprechende Anfragen über den Bus an die Anlage, der ebusd liest mit und in FHEM werden die Readings passend angelegt. Wenn man Readings für Schreibbefehle haben will, steuert man im Bedienteil einfach die gewünschten Einträge an und stellt sie ein.
* Ich glaube, dass ich das json-Geraffel nicht brauche und habe daher in /etc/default/ebusd den Parameter --mqttjson entfernt, dadurch haben die Readings nicht mehr den störenden Suffix, den sie sonst bekommen.
Erstmal bin ich mit dem Ergebnis sehr zufrieden, Fragen kommen später bestimmt, wenn die eigenen Ansprüche steigen!
Zitat von: Reinhart am 10 Juni 2020, 09:39:30
so wie du das schilderst, scheint die Hardware in Ordnung zu sein, denn wenn der eBus am Konverter hängt funktioniert noch alles (blinken)!
Die Probleme beginnen sobald du den Dämon startest.
Die Probleme sind jetzt anscheinend verschwunden, nachdem ich an der Calormatic 470 (VRC 470) einmal auf die Fachhandwerkerebene gegangen bin, danach kamen plötzlich Daten, sowohl im Log, als auch über Mqtt.
Seitdem kommt zyklisch (1min) die Außentemperatur und Datum und Uhrzeit. Die "restlichen" Daten nur, wenn ich in der Calormatic 470 auf die Fachhandwerkerebene gehe.
Der Vollständigkeit halber
ls -l /dev/
...
crw-rw-rw- 1 root root 10, 58 Jun 8 05:43 ttyebus
...
ttyama0 ist auch nicht dabei.
Meine Konfiguration:
pi@raspberrypi:~ $ cat /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 --mqttport=1883 --mqttjson --mqtthost=192.168.178.23 --mqtttopic=ebusd/%name"
... nur noch auskommentierte Zeilen!
Soweit sieht das für mich also so aus, als wäre die Hardware in Ordnung und Software grundsätzlich auch.
ebusctl info liefert:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
signal: acquired
symbol rate: 32
max symbol rate: 98
reconnects: 11
masters: 3
messages: 211
conditional: 3
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
Mein Ziel wäre jetzt, die Heizung über MQTT (ich verwende kein FHEM) gezielt in den Sommer bzw. Wintermodus zu bringen, sowie die Heißwasserbereitung zu aktivieren/deaktivieren.
Ich bekomme, sobald ich etwas über die Colormatic ändere auch schon sinnvolle Werte im MQTT angezeigt, die 1. Frage wäre, wie kann ich zyklisch diesen Status auslesen?
Geht das über MQTT und Get?
Z.B. habe ich folgende Mqtt-Topics
ebusd/Status01
Value:
{
"0": {"name": "temp1", "value": 57.0},
"1": {"name": "temp1", "value": 57.0},
"2": {"name": "temp2", "value": 17.188},
"3": {"name": "temp1", "value": null},
"4": {"name": "temp1", "value": 53.5},
"5": {"name": "pumpstate", "value": "off"}}
und
ebusd/SetMode
Value:
{
"hcmode": {"value": "auto"},
"flowtempdesired": {"value": 0.0},
"hwctempdesired": {"value": null},
"hwcflowtempdesired": {"value": null},
"disablehc": {"value": 1},
"disablehwctapping": {"value": 0},
"disablehwcload": {"value": 0},
"remoteControlHcPump": {"value": 0},
"releaseBackup": {"value": 0},
"releaseCooling": {"value": 0}}
Über den letzteren Topic, setzt die Calomatic anscheinend die Betriebsart der Heizung. (momentan im Sommermodus, deshalb disablehc:1, nehme ich an)
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.
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
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).
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
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
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.
@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
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 (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
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
...
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.
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
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ß
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?
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
Hallo Otto,
ebusd wird bei mir auch automatisch mittels
sudo systemctl start ebusd gestartet.
Eines ist einmal klar: solange ttyAMA0 gelistet ist, kann das nicht funktionieren.
Zusätzlich kann ich nicht ausschließen, dass es ein Problem mit der Baudrate gibt. Möglicherweise erst ab einer gewissen Kernel Version.
Der ttyebus Treiber geht da von einem fixen Clock Wert aus, FIKo hat das schon bei den ttyebus Issues bemerkt, dass das nicht optimal ist.
Kann sein dass auch der PL011 nun plötzlich einen anderen Clock hat. Leider konnte ich bisher keine Methode identifizieren, welche den aktuellen Clock im Kernel ausliest
und somit in eine Berechnung einfließen könnte. Wenn da jemand eine Idee hat, wäre das eine ganz tolle Sache.
Weiters bin ich derzeit nicht in der Lage irgendwelche Tests zu machen, weil ich im Urlaub bin (und keine Hardware mitgenommen habe :-)
Deshalb bitte um Geduld. Eventuelle Tests könnten überprüfen ob das mit einer älteren Buster Version nicht vielleicht doch funktioniert... Oder ob die aktuelle Baudrate richtig ist (Oszilloskop!)
Tut leid dass ich aktuell nicht helfen kann.
LG
Hallo galileo,
kein Problem, mach mal schön Urlaub derweil ;D
Interessant ist, dass bei enable_uart=1 wie du beschrieben hast, das ttyAMA0 aber wieder aktiv wird...
ZitatInteressant ist, dass bei enable_uart=1 wie du beschrieben hast, das ttyAMA0 aber wieder aktiv wird...
Na ja, das war ja nur aus dem Trockendock... Da gibt es so unendlich viele Beschreibungen und Meinungen...
Ich hoffe ja doch dass wir eines Tages die Wahrheit finden werden. Wenigstens bis zum nächsten Linux Upgrade :-)
Zitat von: galileo am 06 August 2020, 17:31:59
Leider konnte ich bisher keine Methode identifizieren, welche den aktuellen Clock im Kernel ausliest
Damit hatte ich mir mal vor einiger Zeit die Sache genauer angeschaut:
vcgencmd measure_clock core
vcgencmd measure_clock armAber die in Berechnungen einfließen zu lassen ist meiner Meinung nach der falsche Weg. Wenn der Pi / das System die Clock dynamisch ändert ist aus meinem Verständnis kein sinnvoller Betrieb möglich. Man muss für diesen Betrieb die Frequenz festziehen. Was das aber genau für den Pi 4 bedeutet habe ich bisher nicht betrachten können. Ich habe keinen :)
Es wäre interessant, wenn jemand dazu etwas sagen könnte, der den Pi 4 mit ttyebus schon am Laufen hat.
Und mit welcher Firmware.
Mir gehts ja nicht darum die neueste Version zu haben, sondern dass die ebus-Kommunikation funktioniert. Das ist die einzige Funktion des Pi 4 bei mir.
Bitte danke
ZitatEs wäre interessant, wenn jemand dazu etwas sagen könnte, der den Pi 4 mit ttyebus schon am Laufen hat.
Und mit welcher Firmware.
Ich habe mir im Jänner 2020 extra einen Raspi4 zugelegt um das verifizieren zu können. Genauso wie du sagst: Standard Buster Installation,
dann nur ttyebus und ebusd. Hat einwandfrei funktioniert, nachdem der ttyebus an den Raspi4 angepasst war (V1.7 vom 2020-01-08).
Das einzige was jetzt anders ist ist die Buster (Linux) Version. Leider kann ich die Versionsnummer von damals (von meinem momentanen Standpunkt aus) nicht identifizieren.
Aber wenn du es schaffst, eine Buster Version von Jänner/Februar aufzutreiben wäre das sicher einen Versuch wert.
LG
OK danke, das werde ich demnächst gleich mal testen.
So ich hab jetzt mal folgendes probiert:
Älteres RaspberryPi-Image auf SD-Karte geflashed:
2019-09-26-raspbian-buster-lite
uname -a ergibt folgendes:
Linux raspberrypi 4.19.75-v7l+
Prozedur laut Anleitung in ttyebus durchgegangen.
Beim Punkt wo man "make" durchführt, kommt dann folgende Meldung:
pi@raspberrypi:~ $ cd ~/ttyebus
pi@raspberrypi:~/ttyebus $ make
make -C /lib/modules/4.19.75-v7l+/build M=/home/pi/ttyebus modules
make[1]: *** /lib/modules/4.19.75-v7l+/build: No such file or directory. Stop.
make: *** [Makefile:24: all] Error 2
Ein ls -la im Ordner modules ergibt folgendes:
pi@raspberrypi:/lib/modules $ ls -la
total 36
drwxr-xr-x 9 root root 4096 Aug 16 05:52 .
drwxr-xr-x 16 root root 4096 Sep 26 2019 ..
drwxr-xr-x 3 root root 4096 Sep 26 2019 4.19.75+
drwxr-xr-x 3 root root 4096 Sep 26 2019 4.19.75-v7+
drwxr-xr-x 3 root root 4096 Sep 26 2019 4.19.75-v7l+
drwxr-xr-x 3 root root 4096 Sep 26 2019 4.19.75-v8+
drwxr-xr-x 2 root root 4096 Aug 16 05:52 5.4.51+
drwxr-xr-x 2 root root 4096 Aug 16 05:52 5.4.51-v7+
drwxr-xr-x 2 root root 4096 Aug 16 05:52 5.4.51-v7l+
Danach ein apt update und upgrade durchgeführt.
Wieder make probiert:
pi@raspberrypi:~ $ cd ~/ttyebus
pi@raspberrypi:~/ttyebus $ make
make -C /lib/modules/4.19.75-v7l+/build M=/home/pi/ttyebus modules
make[1]: *** /lib/modules/4.19.75-v7l+/build: No such file or directory. Stop.
make: *** [Makefile:24: all] Error 2
Im Ordner modules nachgesehen, nun fehlen die alten Versionen:
pi@raspberrypi:/lib/modules $ ls -la
total 24
drwxr-xr-x 6 root root 4096 Aug 16 06:01 .
drwxr-xr-x 16 root root 4096 Aug 16 06:01 ..
drwxr-xr-x 3 root root 4096 Aug 16 06:01 5.4.51+
drwxr-xr-x 3 root root 4096 Aug 16 06:01 5.4.51-v7+
drwxr-xr-x 3 root root 4096 Aug 16 06:01 5.4.51-v7l+
drwxr-xr-x 3 root root 4096 Aug 16 06:01 5.4.51-v8+
Das Update in der raspi-config habe ich zu keinem Zeitpunkt durchgeführt, da ansonsten bei uname wieder auf die aktuelle 5.4.51-v7l+ upgraded wird und dann ja im Endeffekt wieder der aktuelle Stand von vor den Tests da ist mit der letzten Rpi-Image-Version.
Mit meinem sehr begrenzten Linux-Wissen bin ich da jetzt leider am Ende.
Kann es irgendwas mit dem rpi-eeprom-update zu tun haben?
pi@raspberrypi:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad
Hab das ganz am Anfang bei der allerersten Installation des Rpi durchgeführt.
@nightstorm99:
Hast du schon etwas rausgebracht?
@galileo:
Würde es nicht gehen, wenn du ein Image von deiner funktionierenden Installation erstellst, sodass man dieses wo anders einspielen kann?
mfg
Wolfgang
ZitatWürde es nicht gehen, wenn du ein Image von deiner funktionierenden Installation erstellst, sodass man dieses wo anders einspielen kann?
Kann ich gerne tun. Bitte aber um etwas Geduld, das geht erst wenn ich wieder daheim bin.
Zu dem Problem mit "make": Hast du auch ein
sudo apt-get install raspberrypi-kernel-headersversucht? Ich glaube allerdings einmal gelesen zu haben, dass nicht alle Raspbian Versionen immer die korrekten kernel-headers mitbringen.
LG
Ja die kernel headers hab ich auch installiert.
Eine neue Version des Rpi-Kernels mittels uname wird aber erst dann angezeigt, wenn man im raspi-config-Menü updatet.
ZitatWürde es nicht gehen, wenn du ein Image von deiner funktionierenden Installation erstellst, sodass man dieses wo anders einspielen kann?
Ich habe alles noch einmal neu auf einem Raspi4 installiert:
Raspbian 4.19.97
ttyebus 1.8
ebusd 3.4.v3.3-51
und es funktioniert einwandfrei. Ich habe *kein* Upgrade vom Raspbian auf die aktuelle Version gemacht, weil ich ja dort das Problem vermute.
Ich habe ein Image (buster4.19.97-ttyebus1.8-ebusd3.4.v3.3-51.rar) gezogen und hier (https://drive.google.com/file/d/1t5DwRCnL9svqCC7si-Y-qeUK_uVIfmuW/view?usp=sharing) abgelegt.
Ich hoffe dass das zu einem Erfolg führt. Feedback erwünscht. Eine genauere Analyse mit anderen Raspbian Versionen werde ich noch anstellen.
LG
Hi,
vielleicht als Such Hinweis: Liegt es ev. daran das der Pi4 6 UARTs hat und diese irgendwie in der neuen Firmware "offener" zu Tage treten?
https://www.raspberrypi.org/documentation/configuration/uart.md
Gruß Otto
Super danke galileo,
werd ich mal probieren.
So, Image erfolgreich übertragen und Pi gestartet.
Folgende Anzeigen:
ls -l /dev zeigt trotzdem wieder das ttyAMA0 an.
pi@raspberrypi:~ $ ls -l /dev
lrwxrwxrwx 1 root root 7 Aug 26 10:23 serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Aug 26 10:23 serial1 -> ttyS0
drwxrwxrwt 2 root root 40 Feb 14 2019 shm
drwxr-xr-x 3 root root 180 Aug 26 10:23 snd
lrwxrwxrwx 1 root root 15 Feb 14 2019 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Feb 14 2019 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Feb 14 2019 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root tty 5, 0 Aug 26 10:23 tty
crw--w---- 1 root tty 4, 0 Aug 26 10:23 tty0
crw--w---- 1 root tty 4, 1 Aug 26 10:24 tty1
...
crw--w---- 1 root tty 4, 8 Aug 26 10:23 tty8
crw--w---- 1 root tty 4, 9 Aug 26 10:23 tty9
crw-rw---- 1 root dialout 204, 64 Aug 26 10:23 ttyAMA0
crw-rw-rw- 1 root root 10, 57 Aug 26 10:23 ttyebus
crw------- 1 root root 5, 3 Aug 26 10:23 ttyprintk
crw-rw---- 1 root dialout 4, 64 Aug 26 10:24 ttyS0
crw------- 1 root root 10, 239 Aug 26 10:23 uhid
...
ebusctl info spuckt dies aus, was schon mal erfolgreich ausschaut:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 23
max symbol rate: 146
min arbitration micros: 9
max arbitration micros: 21
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 6
messages: 586
conditional: 49
poll: 0
update: 9
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=VR920;SW=2007;HW=5703"
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e0.omu.csv"
Jetzt ist nur die Frage, ob dies meine erkannte Vaillant Luftwärmepumpe ist oder dies noch Reste von deinem gezogenen Image sind ;D
Was sagst du dazu? Sieht das gut aus?
Was mich wundert ist, dass der Messages-Counter nicht nach oben geht, sonder bei 586 seit Beginn an steht...
Ein eingestelltes Logging bei ebusd ergibt folgendes:
pi@raspberrypi:~ $ cat /var/log/ebusd.log
2020-08-26 17:08:55.379 [main notice] ebusd 3.4.v3.3-51-g57eae05 started with auto scan
2020-08-26 17:08:55.719 [bus notice] bus started with own address 31/36
2020-08-26 17:08:55.723 [bus notice] signal acquired
2020-08-26 17:09:00.378 [bus notice] new master 10, master count 2
2020-08-26 17:09:00.440 [bus notice] new master 03, master count 3
2020-08-26 17:09:00.440 [update notice] received unknown MS cmd: 1008b5110101 / 094133301cff4d0000ff
2020-08-26 17:09:00.707 [bus notice] new master 71, master count 4
2020-08-26 17:09:00.707 [update notice] received unknown MS cmd: 1076b5110101 / 09ff33301cff4d0000ff
2020-08-26 17:09:00.974 [update notice] received unknown MS cmd: 1076b512030f0201 / 076e020000801405
2020-08-26 17:09:01.241 [update notice] received unknown MS cmd: 1008b51009000100ffffff060001 / 0101
2020-08-26 17:09:01.508 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2020-08-26 17:09:05.841 [bus notice] scan 08: ;Vaillant;HMU00;0307;0403
2020-08-26 17:09:05.841 [update notice] store 08 ident: done
2020-08-26 17:09:05.841 [update notice] sent scan-read scan.08 QQ=31: Vaillant;HMU00;0307;0403
2020-08-26 17:09:05.841 [bus notice] scan 08: ;Vaillant;HMU00;0307;0403
2020-08-26 17:09:06.217 [main notice] read common config file vaillant/scan.csv
2020-08-26 17:09:06.306 [main notice] read common config file vaillant/general.csv
2020-08-26 17:09:06.392 [main notice] read common config file vaillant/broadcast.csv
2020-08-26 17:09:06.484 [main notice] read scan config file vaillant/08.hmu.csv for ID "hmu00", SW0307, HW0403
2020-08-26 17:09:06.663 [main notice] found messages: 59 (0 conditional on 0 conditions, 0 poll, 9 update)
2020-08-26 17:09:06.792 [update notice] sent unknown MS cmd: 3108b5090124 / 09003231313735303030
2020-08-26 17:09:06.932 [update notice] sent scan-read scan.08 id QQ=31:
2020-08-26 17:09:07.071 [update notice] sent scan-read scan.08 id QQ=31:
2020-08-26 17:09:07.210 [update notice] sent scan-read scan.08 id QQ=31: 21;17;50;0010016422;0001;006292;N8
2020-08-26 17:09:07.210 [bus notice] scan 08: ;21;17;50;0010016422;0001;006292;N8
2020-08-26 17:09:09.315 [bus notice] scan 15: ;Vaillant;70000;0510;6403
2020-08-26 17:09:09.315 [update notice] store 15 ident: done
2020-08-26 17:09:09.315 [update notice] sent scan-read scan.15 QQ=31: Vaillant;70000;0510;6403
2020-08-26 17:09:09.316 [bus notice] scan 15: ;Vaillant;70000;0510;6403
2020-08-26 17:09:09.447 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313830363030
2020-08-26 17:09:09.579 [update notice] sent scan-read scan.15 id QQ=31:
2020-08-26 17:09:09.710 [update notice] sent scan-read scan.15 id QQ=31:
2020-08-26 17:09:09.842 [update notice] sent scan-read scan.15 id QQ=31: 21;18;06;0020242192;0082;013799;N8
2020-08-26 17:09:09.842 [bus notice] scan 15: ;21;18;06;0020242192;0082;013799;N8
2020-08-26 17:09:10.018 [bus notice] max. symbols per second: 119
2020-08-26 17:09:10.154 [main notice] read scan config file vaillant/15.700.csv for ID "70000", SW0510, HW6403
2020-08-26 17:09:10.235 [main notice] found messages: 461 (0 conditional on 0 conditions, 0 poll, 9 update)
2020-08-26 17:09:10.495 [update notice] received read hmu Status01 QQ=10: 29.0;23.0;28.188;-;38.5;off
2020-08-26 17:09:10.762 [update notice] received unknown MS cmd: 1076b5110101 / 09ff2e301cff4d0000ff
2020-08-26 17:09:11.028 [update notice] received unknown MS cmd: 1076b512030f0201 / 076e020000801405
2020-08-26 17:09:11.295 [update notice] received update-write hmu SetMode QQ=10: off;0.0;-;-;0;1;1;1;0;0
2020-08-26 17:09:11.561 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2020-08-26 17:09:12.338 [bus notice] scan 76: ;Vaillant;VWZ00;0307;0403
2020-08-26 17:09:12.338 [update notice] store 76 ident: done
2020-08-26 17:09:12.338 [update notice] sent scan-read scan.76 QQ=31: Vaillant;VWZ00;0307;0403
2020-08-26 17:09:12.338 [bus notice] scan 76: ;Vaillant;VWZ00;0307;0403
2020-08-26 17:09:12.440 [update notice] sent unknown MS cmd: 3176b5090124 / 00
2020-08-26 17:09:12.540 [update notice] sent scan-read scan.76 id QQ=31:
2020-08-26 17:09:12.639 [update notice] sent scan-read scan.76 id QQ=31:
2020-08-26 17:09:12.739 [update error] unable to parse scan-read scan.76 id from 3176b5090127 / 00: ERR: invalid position
2020-08-26 17:09:12.739 [main error] scan config 76: ERR: invalid position
2020-08-26 17:09:17.322 [bus notice] scan e0: ;Vaillant;OMU00;0131;5202
2020-08-26 17:09:17.322 [update notice] store e0 ident: done
2020-08-26 17:09:17.322 [update notice] received scan-read scan.e0 QQ=03: Vaillant;OMU00;0131;5202
2020-08-26 17:09:20.577 [update notice] received read hmu Status01 QQ=10: 26.0;22.0;28.188;-;38.5;off
2020-08-26 17:09:20.843 [update notice] received unknown MS cmd: 1076b5110101 / 09ff2c301cff4d0000ff
2020-08-26 17:09:21.109 [update notice] received unknown MS cmd: 1076b512030f0201 / 076e020000801405
2020-08-26 17:09:21.376 [update notice] received update-write hmu SetMode QQ=10: off;0.0;-;-;0;1;1;1;0;0
2020-08-26 17:09:21.642 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2020-08-26 17:09:24.823 [update error] unable to parse scan-read scan.76 id from 3176b5090124 / 00: ERR: invalid position
2020-08-26 17:09:24.923 [update error] unable to parse scan-read scan.76 id from 3176b5090125 / 00: ERR: invalid position
2020-08-26 17:09:25.022 [update error] unable to parse scan-read scan.76 id from 3176b5090126 / 00: ERR: invalid position
2020-08-26 17:09:25.122 [update error] unable to parse scan-read scan.76 id from 3176b5090127 / 00: ERR: invalid position
2020-08-26 17:09:25.122 [main error] scan config 76: ERR: invalid position
2020-08-26 17:09:27.229 [update notice] sent unknown MS cmd: 31e0b5090124 / 09003231313830373030
2020-08-26 17:09:27.369 [update notice] sent scan-read scan.e0 id QQ=31:
2020-08-26 17:09:27.509 [update notice] sent scan-read scan.e0 id QQ=31:
2020-08-26 17:09:27.648 [update notice] sent scan-read scan.e0 id QQ=31: 21;18;07;0010016715;0001;005428;N0
2020-08-26 17:09:27.648 [bus notice] scan e0: ;21;18;07;0010016715;0001;005428;N0
2020-08-26 17:09:27.874 [main notice] read scan config file vaillant/e0.omu.csv for ID "omu00", SW0131, HW5202
2020-08-26 17:09:28.125 [main notice] found messages: 584 (49 conditional on 3 conditions, 0 poll, 9 update)
2020-08-26 17:09:30.620 [update notice] received read hmu Status01 QQ=10: 24.0;21.0;28.188;-;38.5;off
2020-08-26 17:09:30.885 [update notice] received unknown MS cmd: 1076b5110101 / 09ff2a301cff4d0000ff
2020-08-26 17:09:31.152 [update notice] received unknown MS cmd: 1076b512030f0201 / 076e020000801405
2020-08-26 17:09:31.418 [update notice] received update-write hmu SetMode QQ=10: off;0.0;-;-;0;1;1;1;0;0
2020-08-26 17:09:31.685 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2020-08-26 17:09:40.224 [update error] unable to parse scan-read scan.76 id from 3176b5090124 / 00: ERR: invalid position
2020-08-26 17:09:40.324 [update error] unable to parse scan-read scan.76 id from 3176b5090125 / 00: ERR: invalid position
2020-08-26 17:09:40.423 [update error] unable to parse scan-read scan.76 id from 3176b5090126 / 00: ERR: invalid position
2020-08-26 17:09:40.523 [update error] unable to parse scan-read scan.76 id from 3176b5090127 / 00: ERR: invalid position
2020-08-26 17:09:40.523 [main error] scan config 76: ERR: invalid position
2020-08-26 17:09:40.660 [update notice] received read hmu Status01 QQ=10: 23.0;20.5;28.188;-;38.5;off
2020-08-26 17:09:40.926 [update notice] received unknown MS cmd: 1076b5110101 / 09ff29301cff4d0000ff
2020-08-26 17:09:41.192 [update notice] received unknown MS cmd: 1076b512030f0201 / 076e020000801405
2020-08-26 17:09:41.403 [update notice] received unknown BC cmd: 10feb505025c00
2020-08-26 17:09:41.670 [update notice] received update-write hmu SetMode QQ=10: off;0.0;-;-;0;1;1;1;0;0
2020-08-26 17:09:41.936 [update notice] received unknown MS cmd: 1076b51009000000ffffff010000 / 0101
2020-08-26 17:09:42.205 [update notice] received read hmu DateTime QQ=10: valid;17:09:43;26.08.2020;28.188
2020-08-26 17:09:42.448 [update notice] received unknown MS cmd: 1008b507020900 / 02d202
2020-08-26 17:09:42.685 [update notice] received update-read broadcast vdatetime QQ=10: 17:09:40;26.08.2020
2020-08-26 17:09:42.951 [update notice] received unknown MS cmd: 1008b5110100 / 096c0114000008000100
Also ich glaube es schaut schon nicht so schlecht aus...
Vielen Dank für deine Hilfe
Vielen Dank für das Image @galileo.
Mit diesem Image habe ich es endlich geschafft meinen Raspi-Adapter ans laufen zu bekommen. :)
Frage:
Wenn ich per ebusctl listen auf dem Bus mithöre, kriege ich folgendes rein:
pi@raspberrypi:~ $ ebusctl
localhost: listen
listen started
hmu Status01 = 25.0;25.0;20.000;-;44.0;off
broadcast vdatetime = 12:30:27;30.08.2020
hmu DateTime = valid;12:30:30;30.08.2020;20.000
broadcast vdatetime = 12:31:27;30.08.2020
hmu DateTime = valid;12:31:29;30.08.2020;20.000
broadcast outsidetemp = 20.000
hmu DateTime = valid;12:32:30;30.08.2020;20.000
hmu Status01 = 25.0;24.5;20.000;-;44.0;off
broadcast vdatetime = 12:32:28;30.08.2020
hmu Status01 = 25.0;25.0;20.000;-;44.0;off
broadcast vdatetime = 12:33:28;30.08.2020
hmu DateTime = valid;12:33:30;30.08.2020;20.000
700 currenterror = -;-;-;-;-
scan.05 = Vaillant;VR920;2007;5703
hmu currenterror = -;-;-;-;-
scan.05 id = 21;18;50;0020252922;0938;032169;N5
scan.38 = Vaillant;V32;0117;9802
hmu DateTime = valid;12:34:31;30.08.2020;20.000
broadcast vdatetime = 12:34:28;30.08.2020
hmu Status01 = 25.0;24.5;20.000;-;44.0;off
hmu Status01 = 25.0;25.0;20.000;-;44.0;off
hmu Status01 = 25.0;24.5;20.000;-;44.0;off
hmu DateTime = valid;12:35:31;30.08.2020;20.000
broadcast vdatetime = 12:35:29;30.08.2020
hmu Status01 = 25.0;25.0;20.000;-;44.0;off
hmu Status01 = 25.0;24.5;20.000;-;44.0;off
hmu Status01 = 25.0;24.5;20.188;-;44.0;off
broadcast vdatetime = 12:36:29;30.08.2020
hmu DateTime = valid;12:36:31;30.08.2020;20.188
hmu Status01 = 25.0;25.0;20.188;-;44.0;off
hmu Status01 = 25.0;24.5;20.188;-;44.0;off
hmu Status01 = 25.0;25.0;20.188;-;44.0;off
Das ist derzeit nur die Übertragung der Uhrzeit jede Minute und ein paar Temperaturen per Status.
Wenn ich nun auf dem Vaillant Multimatic VR700 einen Soll-Temperaturwert oder die Lüftungsstufe verändere, bekomme ich dies im ebustl nicht angezeigt.
Liegt das daran, dass das Datenpaket nicht korrekt dekodiert werden konnte (was im Einklang mit den Fehlermeldungen in meinen vorigen Post ist) oder übersehe ich hier etwas?
Danke für Eure Hilfe
Hi!
Mit dem einfen listen Befehl erhältst Du nur entschlüsselte Nachrichten, keine unbekannten.
Versuch mal "listen -u" oder "listen -U".
Oder "grab" und nach einiger Zeit "grab result". Das listet alle unentschlüsselten Telegramme. (meine mich zu entsinnen, das "grab" schon automatisch beim start von ebusctl gestartet wird)
Gruß,
Burkhard
Hallo Burkhard,
danke für deine Hilfe.
Hat folgendes ergeben:
pi@raspberrypi:~ $ ebusctl
localhost: listen -u
listen started
localhost: listen -u
hmu Status01 = 25.0;24.5;23.188;-;41.0;off
1076b5110101 09ff313017ff520000ff
1076b512030f0201 0790020000801405
1076b51009000000ffffff050000 0101
03e0b5210900002214e4ffff4600 0b000040013b010700000600
1076b5110101 09ff313017ff520000ff
1076b512030f0201 0790020000801405
1076b51009000000ffffff050000 0101
1076b5110101 09ff313017ff520000ff
1076b512030f0201 0790020000801405
1076b51009000000ffffff050000 0101
1076b5110101 09ff313017ff520000ff
10feb505025c00
1076b512030f0201 0790020000801405
1076b51009000000ffffff050000 0101
broadcast vdatetime = 14:51:14;30.08.2020
hmu DateTime = valid;14:51:16;30.08.2020;23.188
1008b5110100 09900114000000000100
1008b507020900 02a402
broadcast outsidetemp = 23.188
10feb510020601
1008b512020064 00
1008b5120204ff 0101
1008b513020528 0101
1076b51303040d00 02ffff
1076b5110101 09ff313017ff520000ff
1076b512030f0201 0790020000801405
1076b51009000000ffffff050000 0101
1076b5110101 09ff313017ff520000ff
1076b512030f0201 0790020000801405
1076b51009000000ffffff050000 0101
listen continued
localhost: grab result all
3105070400 / 0ab5565239323020075703 = 1: scan.05
3105b5090127 / 094e3500000000000000 = 3: scan.05 id
3108070400 / 0ab5484d55303003070403 = 1: scan.08
3108b5090127 / 094e383c3c3c3c3c3c3c = 3: scan.08 id
3115070400 / 0ab5373030303005106403 = 1: scan.15
3115b5090127 / 094e3800000000000000 = 3: scan.15 id
3138070400 / 0ab5563332000001179802 = 1: scan.38
3176070400 / 0ab556575a303003070403 = 1: scan.76
3176b5090127 / 00 = 3907: scan.76 id
03e0070400 / 0ab54f4d55303001315202 = 25: scan.e0
31e0b5090127 / 094e303c3c3c3c3c3c3c = 3: scan.e0 id
1008b51009000000ffffff070000 / 0101 = 922: hmu SetMode
10feb516080016581430080720 = 154: broadcast vdatetime
10feb51603013017 = 153: broadcast outsidetemp
1008b5040100 / 0a0327221230080720a013 = 1: hmu DateTime
1008b507010a / 03828207 = 3
1008b5110100 / 09900114000000000100 = 155
1008b5110101 / 093232a013ff590000ff = 2: hmu Status01
1076b5110101 / 09ff313017ff520000ff = 924
10feb505025c00 = 156
10feb508020900 = 16
10feb510020601 = 31
10feb516080024221230080720 = 1: broadcast vdatetime
3105b5090124 / 09003231313835303030 = 1: scan.05 id
3108b5090124 / 09003231313735303030 = 1: scan.08 id
3115b5090124 / 09003231313830363030 = 1: scan.15 id
3176b5090124 / 00 = 1: scan.76 id
31e0b5090124 / 09003231313830373030 = 1: scan.e0 id
1008b5040100 / 0a03195814300807203017 = 154: hmu DateTime
1008b5110101 / 0932313017ff520000ff = 899: hmu Status01
0008b503020002 / 0affffffffffffffffffff = 9
0008b503020004 / 0affffffffffffffffffff = 10
0015b503020002 / 0affffffffffffffffffff = 10
1008b507020900 / 02a402 = 156
1008b512020064 / 00 = 31
1008b5120204ff / 0101 = 31
1008b513020528 / 0101 = 31
0008b503020001 / 0affffffffffffffffffff = 9: hmu currenterror
0015b503020001 / 0affffffffffffffffffff = 10: 700 currenterror
1076b512030f0201 / 0790020000801405 = 924
1076b51303040d00 / 02ffff = 154
0008b51608100000ff83050000 / 0b00000483051e2900e88049 = 12
0015b51608100000ff41030000 / 0b00000241031e2900000000 = 2
0033b5170608b503020004 = 42
1008b51009000000ffffff070000 / 0101 = 2: hmu SetMode
1076b51009000000ffffff050000 / 0101 = 924
03e0b5210900002214e4ffff4600 / 0b000040013a010700000600 = 280
3300b5180affffffffffffffffffff = 39
3310b5180affffffffffffffffffff = 1
Sieht so aus, als ob der Großteil von meiner Vaillant-Heizung noch nicht dekodiert ist.
Ist eine Vaillant Flexotherm VWF 117/4 mit Recovair VAR 260/4, Multimatic VR700 und Kommunikationsmodul VR920.
Hatte gehofft, dass mehr Telegramme schon dekodiert sind.
Hat jemand so eine Heizung in Verbindung mit ebusd am Laufen bzw. schon dekodiert?
Würde dafür auch "spenden".
mfg Wolfgang
Hi Wolfgang!
Ich könnte mir vorstellen, dass auch schon mehr bekannt ist, evtl. passt Deine Konfiguration noch nicht so ganz, dass die passenden Dateien nicht geladen werden.
Hast Du die aktuellen CVS Dateien unter /etc/ebusd/ abgelegt. Sind das alle oder nur eine Auswahl? Mit welchen Optionen wird bei Dir ebusd gestartet? Nutzt Du --scanconfig und --configpaht/etc/ebusd/ oder --configpaht/etc/ebusd/de/ ?
Sieh mal hier
https://github.com/john30/ebusd/wiki/4.7.-Automatic-configuration
https://github.com/john30/ebusd-configuration
Bei Viailant kann ich dir konkret nicht weiterhelfen, da wir hier eine Wolf Therme haben.
Freut mich, wenn ich schon mal etwas helfen kann. Jetzt im Sommer ist es wohl noch schwer hier him Forum Hilfe bei diesem Thema zu bekommen. Ich warte auch noch auf gute Tips.
Gruß,
Burkhard
Hallo Burkhard,
folgend der Eintrag der /etc/default/ebusd:
EBUSD_OPTS="--scanconfig -d /dev/ttyebus -l /var/log/ebusd.log"
Unter /etc/ebusd ist nichts hinterlegt:
pi@raspberrypi:/etc/ebusd $ ls -la
total 8
drwxr-xr-x 2 pi pi 4096 Oct 27 2019 .
drwxr-xr-x 81 root root 4096 Aug 26 17:07 ..
Ich dachte, das macht die Option --scanconfig mit der neuesten ebusd-Version zusammen automatisch anhand der empfangenen Daten auf dem eBus?
Dann hab ich das falsch verstanden, sodass nur die richtige csv ausgewählt aber nicht downgeloaded wird?
Aufgrund der Auflistung der csv-Datei hier bin ich davon ausgegangen, dass die richtige csv bereits ausgewählt wurde:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 23
max symbol rate: 146
min arbitration micros: 9
max arbitration micros: 21
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 6
messages: 586
conditional: 49
poll: 0
update: 9
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=VR920;SW=2007;HW=5703"
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e0.omu.csv"
Da sind die folgenden csv bereits gelistet:
"vaillant/08.hmu.csv"
"vaillant/15.700.csv"
"vaillant/e0.omu.csv"
Danke
Hab gerade mit folgendem Code laut Anleitung die csv's kopiert:
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
Die ebusd-Parameter dann wie folgt abgeändert:
EBUSD_OPTS="--scanconfig --configpath=/etc/ebusd/de -d /dev/ttyebus -l /var/log/ebusd.log"
Nach einem Neustart ist das Ergebnis aber nun, dass er gar keine csv mehr auswählt:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
signal: acquired
symbol rate: 61
max symbol rate: 122
min arbitration micros: 10
max arbitration micros: 20
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 4
messages: 4
conditional: 0
poll: 0
update: 0
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202"
Die csv's sind korrekt hinterlegt:
pi@raspberrypi:/etc/ebusd $ ls -la
total 24
drwxr-xr-x 3 root root 4096 Aug 31 14:34 .
drwxr-xr-x 4 root root 4096 Aug 31 14:34 ..
-rw-r--r-- 1 root root 1253 Aug 31 14:34 broadcast.csv
-rw-r--r-- 1 root root 754 Aug 31 14:34 memory.csv
-rw-r--r-- 1 root root 1228 Aug 31 14:34 _templates.csv
drwxr-xr-x 2 root root 4096 Aug 31 14:34 vaillant
Habe danach wieder den configpath aus der ebusd gelöscht und nach einem Neustart werden die csv's wieder aufgelistet:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 80
max symbol rate: 153
min arbitration micros: 7
max arbitration micros: 60
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 6
messages: 587
conditional: 49
poll: 0
update: 9
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=VR920;SW=2007;HW=5703"
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e0.omu.csv"
Laut Anleitung von ebusd reicht das --scanconfig bei einer Version >3.2 aus.
Bei mir klappt das mit dem --scanconfig überhaupt nicht. Bekomme dann die Meldung, dass einige CVS nicht gefunden werden. Habe dann einen manuelle Konfiguration angelegt und nutze --scanconfig nicht.
Evtl. ist das /de bei Dir im --configpath zu viel, da möglicherweise ebusd selbst nochmal nach dem Sprachenordner sucht und das selbst anhängt.
Damit ich viel mitbekomme, lasse ich zur Zeit ebusd nicht als service laufen, bzw. habe den Service gleich wieder gestoppt und nutze den commandline aufruf mit -f. So sehe ich sofort was ebusd so treibt. So geht es auch schneller mit den Parameter zu experimentieren. Nachdem ich die für mich passenden Einstellungen gefunden habe, habe ich die Datei in /etc/default entsprechend angepasst.
Gruß,
Burkhard
Hab gerade ein bisschen rumgespielt mit -f statt dem service, da sieht man alles sehr gut, danke.
Leider keine Änderung, egal wie ich den config-path abändere.
Ohne --scanconfig dann immer die Meldung, dass die csv nicht vorhanden ist.
pi@raspberrypi:~ $ ebusd --configpath=/etc/ebusd/ -d /dev/ttyebus -f
2020-08-31 21:17:19.060 [main notice] ebusd 3.4.v3.3-51-g57eae05 started
2020-08-31 21:17:19.107 [main error] error reading config files from /etc/ebusd/: ERR: duplicate entry, last error: vaillant/15.ui.csv:8: ERR: duplicate entry, duplicate ID
pi@raspberrypi:~ $ ebusd --configpath=/etc/ebusd/vaillant/ -d /dev/ttyebus -f
2020-08-31 21:17:07.699 [main notice] ebusd 3.4.v3.3-51-g57eae05 started
2020-08-31 21:17:07.705 [main error] error reading templates in /: ERR: element not found, last error: _templates.csv:46: ERR: element not found, field type TEMP in field 0
2020-08-31 21:17:07.705 [main error] error reading config files from /etc/ebusd/vaillant/: ERR: element not found, last error: 15.470.csv:7: ERR: element not found, field type BDAY in field 0
2020-08-31 21:17:07.706 [bus notice] bus started with own address 31/36
config-files wären vorhanden:
pi@raspberrypi:~ $ cd /etc/ebusd/vaillant
pi@raspberrypi:/etc/ebusd/vaillant $ ls -la
total 800
drwxr-xr-x 2 root root 4096 Aug 31 14:34 .
drwxr-xr-x 3 root root 4096 Aug 31 14:34 ..
lrwxrwxrwx 1 root root 10 Aug 31 14:34 05.vd2.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 05.vd3.csv -> 05.vd4.csv
-rw-r--r-- 1 root root 5833 Aug 31 14:34 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 05.vd6.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 05.vl8.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 05.vl9.csv -> 05.vd4.csv
-rw-r--r-- 1 root root 5350 Aug 31 14:34 06.pms.csv
-rw-r--r-- 1 root root 3887 Aug 31 14:34 08.bai.csv
-rw-r--r-- 1 root root 28639 Aug 31 14:34 08.ehp.csv
-rw-r--r-- 1 root root 2753 Aug 31 14:34 08.hmu.csv
-rw-r--r-- 1 root root 5656 Aug 31 14:34 0a.pmw.hwc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 15.140.csv -> 15.350.csv
-rw-r--r-- 1 root root 4822 Aug 31 14:34 15.350.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 15.360.csv -> 15.350.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 15.36p.csv -> 15.350.csv
-rw-r--r-- 1 root root 9886 Aug 31 14:34 15.370.csv
-rw-r--r-- 1 root root 8443 Aug 31 14:34 15.392.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 15.400.csv -> 15.350.csv
-rw-r--r-- 1 root root 15460 Aug 31 14:34 15.430.csv
-rw-r--r-- 1 root root 17160 Aug 31 14:34 15.470.csv
-rw-r--r-- 1 root root 24429 Aug 31 14:34 15.700.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 15.b7v.csv -> 15.700.csv
-rw-r--r-- 1 root root 3949 Aug 31 14:34 15.e7f.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 15.f35.csv -> 15.350.csv
-rw-r--r-- 1 root root 9945 Aug 31 14:34 15.f37.csv
-rw-r--r-- 1 root root 14715 Aug 31 14:34 15.f43.csv
-rw-r--r-- 1 root root 16734 Aug 31 14:34 15.f47.csv
lrwxrwxrwx 1 root root 12 Aug 31 14:34 15.heb.csv -> 15.sdr_p.csv
lrwxrwxrwx 1 root root 12 Aug 31 14:34 15.hep.csv -> 15.sdr_p.csv
-rw-r--r-- 1 root root 2986 Aug 31 14:34 15.sdr_p.csv
-rw-r--r-- 1 root root 13608 Aug 31 14:34 15.ui.csv
-rw-r--r-- 1 root root 5908 Aug 31 14:34 15.uih.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 1c.rcc.4.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 1c.v81.4.csv -> 75.v81.csv
-rw-r--r-- 1 root root 539 Aug 31 14:34 23.ehp.cc.csv
-rw-r--r-- 1 root root 885 Aug 31 14:34 23.solsy.cc.csv
-rw-r--r-- 1 root root 886 Aug 31 14:34 23.vr630.cc.csv
-rwxr-xr-x 1 root root 913 Aug 31 14:34 23.zeo.cc.csv
-rw-r--r-- 1 root root 2196 Aug 31 14:34 25.ehp.hwc.csv
-rw-r--r-- 1 root root 2906 Aug 31 14:34 25.solsy.hwc.csv
-rw-r--r-- 1 root root 1944 Aug 31 14:34 25.vr630.hwc.csv
-rwxr-xr-x 1 root root 851 Aug 31 14:34 25.zeo.hwc.csv
-rw-r--r-- 1 root root 4203 Aug 31 14:34 26.solsy.hc.csv
-rw-r--r-- 1 root root 2187 Aug 31 14:34 26.vr630.hc.csv
-rw-r--r-- 1 root root 2447 Aug 31 14:34 26.vr_71.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 35.rcc.1.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 35.v81.1.csv -> 75.v81.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 3c.rcc.5.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 3c.v81.5.csv -> 75.v81.csv
-rw-r--r-- 1 root root 6424 Aug 31 14:34 50.ehp.mc.csv
-rw-r--r-- 1 root root 3794 Aug 31 14:34 50.solsy.mc.csv
-rw-r--r-- 1 root root 7688 Aug 31 14:34 50.v61.mc.csv
-rw-r--r-- 1 root root 2403 Aug 31 14:34 50.vr630.mc.csv
-rwxr-xr-x 1 root root 1599 Aug 31 14:34 50.zeo.mc.csv
-rw-r--r-- 1 root root 2446 Aug 31 14:34 51.vr630.mc.3.csv
-rw-r--r-- 1 root root 5359 Aug 31 14:34 52.mc2.mc.4.csv
-rw-r--r-- 1 root root 1349 Aug 31 14:34 52.vr_70.csv
-rw-r--r-- 1 root root 4957 Aug 31 14:34 53.mc2.mc.5.csv
lrwxrwxrwx 1 root root 15 Aug 31 14:34 54.mc2.mc.6.csv -> 52.mc2.mc.4.csv
lrwxrwxrwx 1 root root 15 Aug 31 14:34 55.mc2.mc.7.csv -> 53.mc2.mc.5.csv
-rw-r--r-- 1 root root 515 Aug 31 14:34 64.v65.csv
-rw-r--r-- 1 root root 713 Aug 31 14:34 75.rcc.csv
-rw-r--r-- 1 root root 2601 Aug 31 14:34 75.v81.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 7c.rcc.6.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 7c.v81.6.csv -> 75.v81.csv
-rwxr-xr-x 1 root root 15147 Aug 31 14:34 84.zeo.csv
-rw-r--r-- 1 root root 3309 Aug 31 14:34 a0.sol.hwc.csv
-rw-r--r-- 1 root root 661 Aug 31 14:34 a1.sol.cc.csv
-rw-r--r-- 1 root root 14212 Aug 31 14:34 bai.0010002315.inc
-rw-r--r-- 1 root root 16921 Aug 31 14:34 bai.0010002465.inc
-rw-r--r-- 1 root root 16142 Aug 31 14:34 bai.0010003857.inc
-rw-r--r-- 1 root root 16494 Aug 31 14:34 bai.0010003886.inc
-rw-r--r-- 1 root root 22824 Aug 31 14:34 bai.0010004121.inc
-rw-r--r-- 1 root root 17089 Aug 31 14:34 bai.0010004150.inc
-rw-r--r-- 1 root root 17150 Aug 31 14:34 bai.0010005400.inc
-rw-r--r-- 1 root root 18344 Aug 31 14:34 bai.0010006101.inc
-rw-r--r-- 1 root root 16327 Aug 31 14:34 bai.0010006341.inc
-rw-r--r-- 1 root root 17863 Aug 31 14:34 bai.0010007508.inc
-rw-r--r-- 1 root root 17872 Aug 31 14:34 bai.0010010674.inc
-rw-r--r-- 1 root root 17105 Aug 31 14:34 bai.0010015600.inc
-rw-r--r-- 1 root root 17428 Aug 31 14:34 bai.0010021961.inc
-rw-r--r-- 1 root root 5547 Aug 31 14:34 bai.0020066007.inc
-rw-r--r-- 1 root root 17001 Aug 31 14:34 bai.308523.inc
-rw-r--r-- 1 root root 620 Aug 31 14:34 broadcast.csv
-rw-r--r-- 1 root root 6658 Aug 31 14:34 e0.omu.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 e1.omu.1.csv -> e0.omu.csv
-rw-r--r-- 1 root root 5665 Aug 31 14:34 ec.sol.sc.csv
-rw-r--r-- 1 root root 6001 Aug 31 14:34 ec.solsy.sc.csv
-rwxr-xr-x 1 root root 1280 Aug 31 14:34 ec.zeo.sc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 ed.pms.sc.csv -> 06.pms.csv
-rw-r--r-- 1 root root 525 Aug 31 14:34 errors.inc
lrwxrwxrwx 1 root root 10 Aug 31 14:34 f5.rcc.3.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 f5.v81.3.csv -> 75.v81.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 fc.rcc.7.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 31 14:34 fc.v81.7.csv -> 75.v81.csv
-rw-r--r-- 1 root root 693 Aug 31 14:34 general.csv
-rw-r--r-- 1 root root 1104 Aug 31 14:34 hcmode.inc
-rw-r--r-- 1 root root 883 Aug 31 14:34 hwcmode.inc
-rw-r--r-- 1 root root 404 Aug 31 14:34 iotest620.inc
-rw-r--r-- 1 root root 407 Aug 31 14:34 iotest630.inc
-rw-r--r-- 1 root root 307 Aug 31 14:34 iotestact.inc
-rw-r--r-- 1 root root 348 Aug 31 14:34 iotestbmc.inc
-rw-r--r-- 1 root root 313 Aug 31 14:34 iotestbsol.inc
-rw-r--r-- 1 root root 423 Aug 31 14:34 iotesthp.inc
-rw-r--r-- 1 root root 1435 Aug 31 14:34 mcmode.inc
-rw-r--r-- 1 root root 316 Aug 31 14:34 quick.inc
-rw-r--r-- 1 root root 238 Aug 31 14:34 roomtempoffset.inc
-rw-r--r-- 1 root root 792 Aug 31 14:34 scan.csv
-rw-r--r-- 1 root root 530 Aug 31 14:34 service.inc
-rw-r--r-- 1 root root 3475 Aug 31 14:34 _templates.csv
-rw-r--r-- 1 root root 727 Aug 31 14:34 tempsetpoints.inc
-rw-r--r-- 1 root root 647 Aug 31 14:34 timercc.inc
-rw-r--r-- 1 root root 677 Aug 31 14:34 timercool.inc
-rw-r--r-- 1 root root 633 Aug 31 14:34 timerhc.inc
-rw-r--r-- 1 root root 647 Aug 31 14:34 timerhwc.inc
-rw-r--r-- 1 root root 979 Aug 31 14:34 timer.inc
-rw-r--r-- 1 root root 667 Aug 31 14:34 timertariff.inc
-rw-r--r-- 1 root root 606 Aug 31 14:34 yield3d43.inc
-rw-r--r-- 1 root root 606 Aug 31 14:34 yield3f40.inc
-rw-r--r-- 1 root root 606 Aug 31 14:34 yield4445.inc
-rw-r--r-- 1 root root 606 Aug 31 14:34 yield8485.inc
-rw-r--r-- 1 root root 630 Aug 31 14:34 yield8485r.inc
Hab gerade alles wieder zurück auf nur --scanconfig gestellt.
Dann mal probiert ein paar Werte per r lesen:
localhost: r CoolingActive
no
localhost: r FanSpeedMax
100
localhost: r FanMode
no
localhost: r DeicingStarts
306
Also dürften die csv's funktionieren, meine falsche Annahme beruhte darauf, dass die meisten Telegramme nicht entschlüsselt werden konnten. Anscheinend werden die ganzen Parameter aber nicht zyklisch ausgelesen und die paar Werte, die ich verstellt habe, dürften noch nicht entschlüsselt sein.
Wie handhabt ihr das?
Werte zyklisch auslesen?
mfg
Wolfgang
Da giebt es meines Wissen nach drei Ansätze:
1. einen Polllevel angeben r1,ciricut,name,remark .... r1 bedeutet hohe priorität, r9 niedriege. Unter den commandlineoptionen/bwz. Option für den Service kann man einen Pollintervall angeben. --pollinterval=10. Das bedeutet dass alle 10 sec ein Poll durchgeführt wird. Die Polllevel habe ich noch nicht ganz verstanden, aber ich vermute, das r9 nur bei jedem 9. Durchlauf ausgeführt wird. Pollen lohnt nur bei sich häufig ändernden Werten, wie Lüfter und Temperaturen. Für Eingestellte Werte wie Warmwassertemperatur ist es nicht optimal, da zu häufig abgefragt wird.
2. evtl. kann man https://github.com/john30/ebusd/wiki/4.9.-Instructions dies nutzen. Vermute aber, dass es ungeeignet ist.
3. mit at aus FHEM heraus ein read auslösten. Habe ich aber auch noch nicht gemacht.
Ich nutze Poll für Durchflussmenge und Rücklauftemperatur der Solaranlage. Da ich den ebus Adapter über WLan betreibe kommt es gelegentlich zu Kollisionen auf dem ebus, was bislang aber noch nie zu Problemen geführt hat.
Gruß,
Burhard
Hallo Burkhard,
danke werde ich versuchsweise mal testen.
Mein Endausbau soll dann so aussehen, dass die Werte per MQTT gesendet und empfangen werden.
Sollte funktionieren, dass ich damit die Betriebsmodi dann per MQTT umschalte oder?
@galileo: Ist deine ebusd-Version vom Image mit MQTT?
mfg
Wolfgang
Hi Wolfgang!
Ich nutze auch MQTT. Direkte reads von FHEM heraus habe ich noch nicht gemacht.
Leider ist es mir mit unser Wolf Anlage noch nicht gelungen irgend einen Wert oder Zustand zu verändern, warte noch immer auf mein zweites Bedienteil um zu sehen wie die sich untereinander unterhalten.
Gruß,
Burkhard
@Eraser
Das Image von Galileo ist ohne mqtt support.
Ich hatte ebusd deinstalliert, in der Datei /etc/apt/sources.list.d/ebusd.list den Pfad Teil "nomqtt" mit "default" ersetzen und anschließend ebusd wieder installieren.
z.B. "deb https://www.ebusd.eu/repos/apt/default/stretch stretch main"
Die Konfigurationen (z.B. /etc/default/ebusd) vor dem deinstallieren sichern.
Ich habe übrigens nicht das Image genommen, sonder das ganze compiliert nach folgender Anleitung:
https://github.com/john30/ebusd/wiki/1.-Build-and-install
Da natürlich mit MQTT support compiliert. Wichtig ist "sudo apt install libmosquitto-dev" VOR dem compilieren auszuführen.
Hat auf Anhieb geklappt.
Gruß,
Burkhard
Zitat von: Eraser am 31 August 2020, 22:00:09
Wie handhabt ihr das?
Werte zyklisch auslesen?
mfg
Wolfgang
Wie ihr schon richtig erwähnt habt, gibt es mehrere Ansätze eine zyklische Abfrage zu realisieren. Hier 2 einfache Möglichkeiten um gezielte Werte abzufragen. Bei mehren Timern kann man auch unterschiedliche Zeiten definieren, zb: den Wasserdruck nur alle Stunden etc.
Ich habe in meiner Konfiguration bei MQTT2 folgenden Timer im Einsatz (alle 5 Minuten folgende Messwerte):
+*00:05: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/getund bei ECMD so wie hier im Wiki (https://wiki.fhem.de/wiki/EBUS-ECMD)beschrieben. ECMD ist etwas aufwändiger weil hier auch zusätzlich eine Konfigfile für die Abfragewerte (bai00.cfg etc) definiert werden muss aber wenn mal konfiguriert, dann ist ECMD auch sehr zuverlässig.
LG
Reinhart
Zitat von: Reinhart am 06 September 2020, 12:26:56
Ich habe in meiner Konfiguration bei MQTT2 folgenden Timer im Einsatz (alle 5 Minuten folgende Messwerte):
+*00:05: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
Hallo Reinhard!
Vielen Dank für das Beispiel. "ebusd/bai/HwcStarts" z.B. soll wohl identisch mit den Eintragungen unter attr ebusMQTT readingList sein oder?
In meiner CVS steht z.B.:
r,solar,ertraege,,07,76,5022,02f902,betriebsstunden,,UIN,,BetriebsstundenIn der readingList demnach:
ebusd/solar/ertraege:.* { json2nameValue($EVENT, 'betriebsstunden', $JSONMAP) }dann müsste ich im Timer:
set ebusMQTT publish ebusd/solar/ertraege/getsetzen. Wäre das so richtig? Scheint zumindest funktioniert zu haben.
Gruß,
Burhard
Mal zum "Timer" noch eine Alternative die man direkt im MQTT2_DEVICE umsetzen kann:
periodicCmd i.V.m dem entsprechenden get-Kommando.
Sollte dann an Hand dem Readinglisteintrag oben so klappen:
attr <MQTT2_DEVICENAME> getList <irgendeinnamefürdengetter>:noArg betriebsstunden ebusd/solar/ertraege/get
attr <MQTT2_DEVICENAME> periodicCmd betriebsstunden:10
Hole die betriebsstunden alle 10 Minuten oder manuell über den getList-Eintrag.
Gruß
Thomas
So, habe nun ebusd komplett deinstalliert und bin dann für die Installation den Weg mit dem gpgkey gegangen:
https://github.com/john30/ebusd-debian/blob/master/README.md
Hat einwandfrei geklappt und nun funktioniert alles wieder.
Danke für eure Hilfe!
Jetzt muss ich mich erstmal in das Thema MQTT bei ebusd genauer einlesen.
Anhand der letzten Beiträge und meinem begrenzten Grundwissen derweil von MQTT ist folgendes meiner Meinung nach nicht möglich:
-) Ein periodisches Auslesen von Werten aus dem Pi von einem externen Gerät aus
=> es muss direkt am Pi das Intervall eingegeben werden
Dies funktioniert so nicht, da MQTT ja darauf aufbaut, dass jemand eine Nachricht nur zum Server sendet und dieser dann je nach Abonnement zu anderen Geräten weiterleitet.
Dadurch gibt es bei MQTT im Endeffekt kein direktes Auslesen oder?
Wie funktioniert dann das Werte schreiben bei MQTT?
Angenommen ich will von einem externen Gerät, dass auch mit dem gleichen MQTT-Broker verbunden ist, einen Wert in die Steuerung schreiben (z.B. Temperatur ändern).
Muss dann im Endeffekt der Pi mit ebusd genauso ein Abonnement von den gleichen Werten haben, die er auch sendet?
mfg
Wolfgang
Man kann sehr wohl periodisch Daten per MQTT abfragen sowie setzen.
Bei mir läuft ebus von john30 auf einem separten Pi, an dem die Therme (Vaillant) über ebus angebunden ist. Von dort findet die Kommunikation zum FHEM-Server auf einem anderen Pi per MQTT statt.
So sieht bei mir das MQTT-Device auf dem FHEM-Server aus:
defmod vaillant MQTT2_DEVICE ebusd_bai
attr vaillant IODev MQTT2_FHEM_Server
attr vaillant devStateStyle style="text-align:left"
attr vaillant event-on-change-reading .*
attr vaillant group Ebus
attr vaillant icon sani_boiler_temp
attr vaillant jsonMap Status01_0_value:Vorlauf Status01_0_name:0\
Status01_1_value:Ruecklauf Status01_1_name:0\
Status01_2_value:Aussentemp Status01_2_name:0\
Status01_3_value:Warmwasser Status01_3_name:0\
Status01_4_value:WWSpeicher Status01_4_name:0\
Status01_5_value:Pumpenstatus Status01_5_name:0\
Flame_0_value:Flame Flame_0_name:0\
Storageloadpump_percent0_value:Storageloadpump\
FlowTempDesired_temp_value:VorlaufSoll\
Hc1HeatCurve_0_value:HeizKennlinie Hc1HeatCurve_0_name:0\
HolidayEndPeriod_hto_value:FerienEnde\
HolidayStartPeriod_hfrom_value:FerienBeginn\
PumpPower_0_value:PumpenLeistung PumpPower_0_name:0\
PrimaryCircuitFlowrate_uin100_value:Umlaufmenge\
z1DayTemp_tempv_value:TagSolltemp\
z1NightTemp_tempv_value:NachtSolltemp\
FanSpeed_0_value:LuefterDrehzahl FanSpeed_0_name:0\
WaterPressure_pressv_value:Wasserdruck\
z1OpMode_opmode_value:Heizmodus
attr vaillant model eBus_bai_jsonmap
attr vaillant readingList ebusd/bai/PumpHours:.* { json2nameValue($EVENT, 'PumpHours_', $JSONMAP) }\
ebusd/bai/WPPostrunTime:.* { json2nameValue($EVENT, 'WPPostrunTime_', $JSONMAP) }\
ebusd/bai/PowerValue:.* { json2nameValue($EVENT, 'PowerValue_', $JSONMAP) }\
ebusd/bai/StorageExitTemp:.* { json2nameValue($EVENT, 'StorageExitTemp_', $JSONMAP) }\
ebusd/global/version:.* version\
ebusd/global/running:.* running\
ebusd/scan\x5c\x2e08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }\
ebusd/scan\x5c\x2e08/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/global/uptime:.* uptime\
ebusd/global/signal:.* signal\
ebusd/scan\x5c\x2e15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/scan\x5c\x2e15/id:.* { json2nameValue($EVENT, 'id_', $JSONMAP) }\
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT, 'FanSpeed_', $JSONMAP) }\
ebusd/bai/PumpPower:.* { json2nameValue($EVENT, 'PumpPower_', $JSONMAP) }\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }\
ebusd/global/updatecheck:.* updatecheck\
ebusd/bai/DCFTimeDate:.* { json2nameValue($EVENT, 'DCFTimeDate_', $JSONMAP) }\
ebusd/bai/PumpPowerDesired:.* { json2nameValue($EVENT, 'PumpPowerDesired_', $JSONMAP) }\
ebusd/bai/HwcImpellorSwitch:.* { json2nameValue($EVENT, 'HwcImpellorSwitch_', $JSONMAP) }\
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT, 'ReturnTemp_', $JSONMAP) }\
ebusd/700/HwcStorageTempBottom:.* { json2nameValue($EVENT, 'HwcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/bai/FanPWMSum:.* { json2nameValue($EVENT, 'FanPWMSum_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HoursTillService:.* { json2nameValue($EVENT, 'HoursTillService_', $JSONMAP) }\
ebusd/bai/PumpHwcFlowNumber:.* { json2nameValue($EVENT, 'PumpHwcFlowNumber_', $JSONMAP) }\
ebusd/bai/WP:.* { json2nameValue($EVENT, 'WP_', $JSONMAP) }\
ebusd/700/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }\
ebusd/bai/PrimaryCircuitFlowrate:.* { json2nameValue($EVENT, 'PrimaryCircuitFlowrate_', $JSONMAP) }\
ebusd/bai/Flame:.* { json2nameValue($EVENT, 'Flame_', $JSONMAP) }\
ebusd/bai/Storageloadpump:.* { json2nameValue($EVENT, 'Storageloadpump_', $JSONMAP) }\
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT, 'FlowTempDesired_', $JSONMAP) }\
ebusd/700/FrostOverRideTime:.* { json2nameValue($EVENT, 'FrostOverRideTime_', $JSONMAP) }\
ebusd/700/Hc1ActualFlowTempDesired:.* { json2nameValue($EVENT, 'Hc1ActualFlowTempDesired_', $JSONMAP) }\
ebusd/700/Hc1AutoOffMode:.* { json2nameValue($EVENT, 'Hc1AutoOffMode_', $JSONMAP) }\
ebusd/700/Hc1CircuitType:.* { json2nameValue($EVENT, 'Hc1CircuitType_', $JSONMAP) }\
ebusd/700/Hc1HeatCurve:.* { json2nameValue($EVENT, 'Hc1HeatCurve_', $JSONMAP) }\
ebusd/700/HcStorageTempBottom:.* { json2nameValue($EVENT, 'HcStorageTempBottom_', $JSONMAP) }\
ebusd/700/HcStorageTempTop:.* { json2nameValue($EVENT, 'HcStorageTempTop_', $JSONMAP) }\
ebusd/700/HolidayTemp:.* { json2nameValue($EVENT, 'HolidayTemp_', $JSONMAP) }\
ebusd/700/OpMode:.* { json2nameValue($EVENT, 'OpMode_', $JSONMAP) }\
ebusd/700/z1RoomTemp:.* { json2nameValue($EVENT, 'z1RoomTemp_', $JSONMAP) }\
ebusd/700/z1SFMode:.* { json2nameValue($EVENT, 'z1SFMode_', $JSONMAP) }\
ebusd/700/z1OpMode:.* { json2nameValue($EVENT, 'z1OpMode_', $JSONMAP) }\
ebusd/700/Time:.* { json2nameValue($EVENT, 'Time_', $JSONMAP) }\
ebusd/bai/EbusVoltage:.* { json2nameValue($EVENT, 'EbusVoltage_', $JSONMAP) }\
ebusd/bai/extWP:.* { json2nameValue($EVENT, 'extWP_', $JSONMAP) }\
ebusd/bai/FanStarts:.* { json2nameValue($EVENT, 'FanStarts_', $JSONMAP) }\
ebusd/700/z1NightTemp:.* { json2nameValue($EVENT, 'z1NightTemp_', $JSONMAP) }\
ebusd/700/z1DayTemp:.* { json2nameValue($EVENT, 'z1DayTemp_', $JSONMAP) }\
ebusd/700/HolidayStartPeriod:.* { json2nameValue($EVENT, 'HolidayStartPeriod_', $JSONMAP) }\
ebusd/700/HolidayEndPeriod:.* { json2nameValue($EVENT, 'HolidayEndPeriod_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHc1:.* { json2nameValue($EVENT, 'PrEnergyCountHc1_', $JSONMAP) }\
ebusd/bai/PrEnergyCountHwc1:.* { json2nameValue($EVENT, 'PrEnergyCountHwc1_', $JSONMAP) }\
ebusd/bai/PrEnergySumHc1:.* { json2nameValue($EVENT, 'PrEnergySumHc1_', $JSONMAP) }\
ebusd/bai/FanHours:.* { json2nameValue($EVENT, 'FanHours_', $JSONMAP) }\
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }\
ebusd/bai/HwcHours:.* { json2nameValue($EVENT, 'HwcHours_', $JSONMAP) }\
ebusd/bai/HcStarts:.* { json2nameValue($EVENT, 'HcStarts_', $JSONMAP) }\
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT, 'HwcStarts_', $JSONMAP) }
attr vaillant room Ebus,MQTT2_DEVICE
attr vaillant setList HeizKennlinie:selectnumbers,0,.1,2,1,lin ebusd/700/Hc1HeatCurve/set $EVTPART1\
TagSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1DayTemp/set $EVTPART1\
NachtSolltemp:selectnumbers,15,1,25,1,lin ebusd/700/z1NightTemp/set $EVTPART1
Und so wurde das periodische Auslesen (MQTT2_FHEM_Server publish ebusd/bai/.../get) und Visualisieren realisiert (Ergebnis siehe Anhang):
defmod di_vaillant DOIF ##{[+00:01];;foreach (qw(FanSpeed Flame PumpPower Storageloadpump PrimaryCircuitFlowrate FlowTempDesired PumpHours HcHours HcPumpStarts)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
{[+00:00:30];;foreach (qw(Flame PrimaryCircuitFlowrate)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
{[00:01];;foreach (qw(PrEnergyCountHc1 PrEnergyCountHwc1 PrEnergySumHc1 PrEnergySumHwc1 FanHours HcHours HwcHours HcStarts HwcStarts)) {fhem_set("MQTT2_FHEM_Server publish ebusd/bai/$_/get")}}\
{[+01:00];;foreach (qw(z1OpMode WaterPressure z1NightTemp z1DayTemp Hc1HeatCurve HwcLockTime HolidayStartPeriod HolidayEndPeriod)) {fhem_set("MQTT2_FHEM_Server publish ebusd/700/$_/get")}}\
{if ([00:05|WE] or [FS20_fa4b02]) {fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayStartPeriod/set $mday.$month.$year");;fhem_set("MQTT2_FHEM_Server publish ebusd/700/BankHolidayEndPeriod/set $mday.$month.$year")}}
attr di_vaillant event-on-change-reading .*
attr di_vaillant room Ebus
attr di_vaillant uiTable {\
package ui_Table;;\
$TC{0..8}="align='center'";;\
$TD{3}{0..1}="colspan=3";;\
$TD{4}{0..1}="colspan=3";;\
$TD{5}{0..2}="colspan=2";;\
$TD{7}{0..1}="colspan=3";;\
$TD{8}{0}="colspan=6";;\
}\
\
style("Außen","Darkorange")|style("Therme","Darkorange")|style("WW-Sp.","Darkorange")|style("Zirk.","Darkorange")|style("Vorlauf","Darkorange")|style("Rücklauf","Darkorange")\
ICON("temp_outside")|\
icon([vaillant:Flame],"sani_boiler_temp","sani_boiler_temp\@Darkorange")|\
ICON([vaillant:Pumpenstatus] eq "4" ? "sani_buffer_temp_down\@Darkorange" : "sani_buffer_temp_down")|\
icon([Zirk],"sani_pump")|\
ICON([vaillant:Pumpenstatus] eq "on" ? "sani_floor_heating_neutral\@Darkorange" : "sani_floor_heating_neutral")|\
ICON("sani_floor_heating_neutral")\
temp_bar([vaillant:Aussentemp],-15,40)|\
temp_bar([vaillant:Vorlauf],15,70)|\
temp_bar([vaillant:WWSpeicher],15,70)|\
temp_bar([ESPEasy_ESP_Temp_Zirkulation:Temperature],15,45)|\
temp_bar([ESPEasy_ESP_Temp_Vorlauf:Temperature],15,45)|\
temp_bar([ESPEasy_ESP_Temp_Keller_Ruecklauf:Temperature],15,45)\
##" "\
style("Umlaufmenge","Darkorange")|style("Wasserdruck","Darkorange")\
ring([vaillant:Umlaufmenge],0,20,120,0,"l/min",120)|ring([vaillant:Wasserdruck],0,3,0,180,"bar",120)\
##" "\
style("Heizkennlinie","Darkorange")|style("Tagtemperatur","Darkorange")|style("Nachttemperatur","Darkorange")\
ICON("time_graph")|WID([vaillant:HeizKennlinie],"selectnumbers,0.4,.1,1,1,lin","set")|\
ICON("scene_day\@yellow")|temp_knob([vaillant:TagSolltemp],"yellow")|\
ICON("scene_night\@#3464eb")|temp_knob([vaillant:NachtSolltemp],"#3464eb")\
[vaillant:HcHours_hoursum2_value]. " Std."|[vaillant:HwcHours_hoursum2_value]." Std."\
##"Ferien"|ICON(::IsWe()?"fa_check\@Darkorange":"fa_check_empty")\
##WID([$SELF:Timer_1],"time")|WID([$SELF:Timer_2],"time")|WID([$SELF:Timer_3],"time")|WID([$SELF:Timer_4],"time")\
::SVG_FwFn("WEBHOME","P01","",{})\
\
Hallo Damian,
super danke, schaut sehr gut aus deine Umsetzung!
Da du ja auch eine Vaillant damit ausliest, bekommst du bei dir auch diese nicht erkennbaren Telegramme?
localhost: grab result all
3105070400 / 0ab5565239323020075703 = 1: scan.05
3105b5090127 / 094e3500000000000000 = 3: scan.05 id
3108070400 / 0ab5484d55303003070403 = 1: scan.08
3108b5090127 / 094e383c3c3c3c3c3c3c = 3: scan.08 id
3115070400 / 0ab5373030303005106403 = 1: scan.15
3115b5090127 / 094e3800000000000000 = 3: scan.15 id
3138070400 / 0ab5563332000001179802 = 1: scan.38
3176070400 / 0ab556575a303003070403 = 1: scan.76
3176b5090127 / 00 = 3907: scan.76 id
03e0070400 / 0ab54f4d55303001315202 = 25: scan.e0
31e0b5090127 / 094e303c3c3c3c3c3c3c = 3: scan.e0 id
1008b51009000000ffffff070000 / 0101 = 922: hmu SetMode
10feb516080016581430080720 = 154: broadcast vdatetime
10feb51603013017 = 153: broadcast outsidetemp
1008b5040100 / 0a0327221230080720a013 = 1: hmu DateTime
1008b507010a / 03828207 = 3
1008b5110100 / 09900114000000000100 = 155
1008b5110101 / 093232a013ff590000ff = 2: hmu Status01
1076b5110101 / 09ff313017ff520000ff = 924
10feb505025c00 = 156
10feb508020900 = 16
10feb510020601 = 31
10feb516080024221230080720 = 1: broadcast vdatetime
3105b5090124 / 09003231313835303030 = 1: scan.05 id
3108b5090124 / 09003231313735303030 = 1: scan.08 id
3115b5090124 / 09003231313830363030 = 1: scan.15 id
3176b5090124 / 00 = 1: scan.76 id
31e0b5090124 / 09003231313830373030 = 1: scan.e0 id
1008b5040100 / 0a03195814300807203017 = 154: hmu DateTime
1008b5110101 / 0932313017ff520000ff = 899: hmu Status01
0008b503020002 / 0affffffffffffffffffff = 9
0008b503020004 / 0affffffffffffffffffff = 10
0015b503020002 / 0affffffffffffffffffff = 10
1008b507020900 / 02a402 = 156
1008b512020064 / 00 = 31
1008b5120204ff / 0101 = 31
1008b513020528 / 0101 = 31
0008b503020001 / 0affffffffffffffffffff = 9: hmu currenterror
0015b503020001 / 0affffffffffffffffffff = 10: 700 currenterror
1076b512030f0201 / 0790020000801405 = 924
1076b51303040d00 / 02ffff = 154
0008b51608100000ff83050000 / 0b00000483051e2900e88049 = 12
0015b51608100000ff41030000 / 0b00000241031e2900000000 = 2
0033b5170608b503020004 = 42
1008b51009000000ffffff070000 / 0101 = 2: hmu SetMode
1076b51009000000ffffff050000 / 0101 = 924
03e0b5210900002214e4ffff4600 / 0b000040013a010700000600 = 280
3300b5180affffffffffffffffffff = 39
3310b5180affffffffffffffffffff = 1
Weißt du etwas genaueres darüber, was diese sind? Alive-Nachrichten? Abragen auf vorhandenen Busteilnehmer?
@Reinhart:
Deine zeitliche Abfrage aus Post#374 wäre eine sehr einfache und leicht handzuhabende Möglichkeit.
Kannst du mir bitte erklären, wo du den geposteten Code hinterlegt hast?
Als Befehle direkt eingegeben oder in einer config-Datei hinterlegt?
Vielen Dank
mfg
Wolfgang
Hallo Reinhart,
hab durch Nachlesen im FHEM-Forum rausgefunden, dass deine Befehle usw. in FHEM eingegeben werden.
Darum kam es mir spanisch vor, weil ich kein FHEM einsetze.
Muss ich wohl eine andere Lösung suchen, aber danke.
Moin,
ich bin gerade dabei, den RPI-Adapter in Betrieb zu nehmen. Folgende Schritte habe ich ausgeführt:
- Spannungen gemessen mit Versorgung am ebus-Eingang und den 5V anstelle des RPI, ok.
- RPI mit tyyebus Treiber versehen und Adapter aufgesteckt.
- Test mit schreiben auf /dev/ttyebus gemacht.
Mit echo "Hello World" > /dev/ttyebus und
while [ 1 ]; do cat /var/log/daemon.log > /dev/ttyebus ; done
- Mit Scope das Signal kontorlliert.
Das sah erstmal gut aus. Jedoch bekomme ich Meldungen , die mich irritiren:
Bei 3X"Hello World" bekomme ich folgende Einträge in den logs:
dmesg:
[ 46.945338] ttyebus: Close at at major 10 minor 61
[ 46.945344] ttyebus: Close exit
[ 55.144820] ttyebus: Close at at major 10 minor 61
[ 55.144830] ttyebus: Close exit
[ 62.680863] ttyebus: Close at at major 10 minor 61
/var/log/messages
Sep 12 12:29:53 rpiebusd kernel: [ 46.945338] ttyebus: Close at at major 10 minor 61
Sep 12 12:30:01 rpiebusd kernel: [ 46.945344] ttyebus: Close exit
Sep 12 12:30:01 rpiebusd kernel: [ 55.144820] ttyebus: Close at at major 10 minor 61
Sep 12 12:30:09 rpiebusd kernel: [ 55.144830] ttyebus: Close exit
Sep 12 12:30:09 rpiebusd kernel: [ 62.680863] ttyebus: Close at at major 10 minor 61
Außerdem hat mich irritiert, dass beim Senden auch imm die Empfangs-LED leuchtet. Ich habe mir die Schaltung daraufhin genauer angeschaut und wenn ich nicht völlig daneben liege, muss dass auch so sein, da die Eingangsstufe des OP-Amps nicht unterscheiden kann, ob der RPI ein Signal auf den Bus gelegt hat, oder eine Therme.
Die Meldungen bedeuten (gemäß anderer Einträge im Thread), dass der Eingangspuffer des UART überläuft. Da holt ja auch kein Prozess etwas ab.
Bevor ich den RPI nun an die Heizung hänge, möchte ich gerne wissen, ob das Verhalten so korrekt ist, weil der ebusd sein eigenes Signal gleich wieder mit ausliest?
Ansonsten bleibt noch ein herzliches Dankeschön an die Macher der Soft- und Hardware!
Viele Grüße
Thomas
Edit: Ich habe doch noch ein wenig weiter nachgedacht (hilft manchmal). Der ebusd muss ja zeitgleich das Busssignal mitlesen, um sein byte mit dem Gelesenen zu vergleichen, damit die Arbitrierung funktioniert ...
Sorry wg. der überflüssigen Frage.
Hi!
Ich würde davon ausgehen, dass das normal ist.
Du brauchst wohl auch keine Angst zu haben, dass etwas passiert, wenn Du die Schaltung mit dem Ebus verbindest. Du wirst dann eine Menge echter Daten empfangen und Deine Anlage nicht iriitieren, solange Du noch nichts selbst sendest.
Aber auch wenn Du sendest dürfte nicht viel passieren. Im schlimmsten Fall würdest Du den Bus blockieren, was Du daran erkennst, dass auf den Anzeigen sich die Werte nicht mehr ändern.
Gruß,
Burkhard
Zitat von: thomas.z am 12 September 2020, 12:56:03
Edit: Ich habe doch noch ein wenig weiter nachgedacht (hilft manchmal). Der ebusd muss ja zeitgleich das Busssignal mitlesen, um sein byte mit dem Gelesenen zu vergleichen, damit die Arbitrierung funktioniert ...
genau
Hallo,
Ich kann nun erfolgreich verschiedene Werte mittels --pollinterval 10 in der config-Datei und danach mittels z.B. r -p 1 HwcStorageTemp in ebusctl den Wert zyklisch auslesen.
Das dies erfolgreich ist, sehe ich aber nur in der ebusd.log, nicht aber mittels dem Befehl listen in ebusctl.
Was ist der Grund hierfür? Kann mir das jemand erklären?
Wie wäre die Vorgehensweise, wenn man mehrere Werte pollen will und dies automatisch auch nach einem Neustart passieren soll?
Nach einem Neustart muss dies das zyklische Auslesen der gewünschten Werte explizit in ebusctl per z.B. r -p 1 HwcStorageTemp wieder gestartet werden.
Ein Skript dafür schreiben?
Danke
mfg Wolfgang
Zitat von: Eraser am 22 September 2020, 06:10:45
Das dies erfolgreich ist, sehe ich aber nur in der ebusd.log, nicht aber mittels dem Befehl listen in ebusctl.
Was ist der Grund hierfür? Kann mir das jemand erklären?
listen führt nur wirklich geänderte Messages auf.
Zitat von: Eraser am 22 September 2020, 06:10:45
Wie wäre die Vorgehensweise, wenn man mehrere Werte pollen will und dies automatisch auch nach einem Neustart passieren soll?
Nach einem Neustart muss dies das zyklische Auslesen der gewünschten Werte explizit in ebusctl per z.B. r -p 1 HwcStorageTemp wieder gestartet werden.
Ein Skript dafür schreiben?
z.B.
alternativ die config files lokal clonen und z.B. r1 fix bei den eintragen, die gepollt werden sollen
Danke für deine Erklärung John,
hab da noch eine andere Frage bzgl. Poll-Intervall auf der github-Seite erstellt:
https://github.com/john30/ebusd/issues/360
Die Frage dabei ist, warum bei r -p 6 <Variable> kein Unterschied zu r -p 1 <Variable> besteht.
Es wird immer im hinterlegten --pollinterval=10 abgefragt und nich bei z.B. 10s*6=60s.
Kannst du dazu noch was sagen?
Danke für deine Hilfe und natürlich für ebusd!
mfg
Wolfgang
Hi John!
Komschröder/Wolf ist ja sehr speziell vorgegangen wenn es um das setzen von Werten per eBus geht.
Um z.B. die Betriebsart der Anlage zu setzen muss ich folgendes senden:
ff3050230984120101005d010000.
ff305023 09 ist ja soweit standard und klar
84 = Prüfziffer, der Wert ist aber letztendlich egal, da die Anlage jeden Wert akzeptiert
1201 = id des Parameters
0100 = eigentlich zu übertragender Wert
5d010000= suffix
Meine Vorstellung wie ein csv Eintrag dafür aussehen könnte:
w,ISM7,Mode,,ff,30,5023,?1201,,mode,,UIN,0x0001=Standby;0x0002=Automatik;0x0003=Heizbetrieb;0x0004=Absenkbetrieb;0x0005=Sommer,mode,suffix,5d010000 #(das Fragezeichen als Platzhalter. Wird dieses Telegram mitgeschnüffelt wird jede Zahl akzeptiert. Soll gesendet werden wird eine zufällige oder feste Zahl gewählt)
damit in ebusctl "write -c ISM7 mode 01" den obigen Hexcode ergibt. Bei diesem write gibt es übrigens keine Antwort von der Anlage.
Wichtig!:
w,ISM7,Standby,,ff,30,5023,84120101005d010000
ebusctl: write -c ISM7 Standby
funktioniert nicht,
r,ISM7,Standby,,ff,30,5023,84120101005d010000
ebusctl: read -c ISM7 Standby
dagegen schon.
Wäre es möglich sowas in ebusd einzubauen?
Gruß,
Burkhard
So, ich unterhalte mich mal wieder weiter mit mir selbst ::).
Wie bereits erwähnt ist die Prüfsumme egal, sie wird nicht gegengeprüft. Jetzt habe ich festgestellt, dass der Anhang "5d010000" auch einfach weggelassen werden kann.
Somit sieht die Zeile in der CSV wie folgt aus:
w,ISM7,Mode,,ff,30,5023,021201,mode,,UIN,0x0001=Standby;0x0002=Automatik;0x0003=Heizbetrieb;0x0004=Absenkbetrieb;0x0005=Sommer,Mode
In ebusctl kann jetzt mit :
write -c ISM7 Mode Automatik
direkt umgestellt werden.
Das mitschnüffeln funktioniert natürlich so nicht, da wir die Prüfziffer nicht vorhersagen können und somit die ID nicht stimmt. Das halte ich aber für verschmerzbar, denn in den regelmäßigen broadcasts werden die neu gesetzten Werte ja regelmäßig bestätigt.
Gruß,
Burkhard
Hi!
Die Heizung sedet einen Wert, der Bitweise kodiert ist. Als Beispiel: bit 0 = 3-Wegeventil, bit1 = Flamme, bit 4 = Kesselkreispumpe.
Ich vermute mal das die datatypes BI0 bis BI7 dafür gedacht sind, aber leider gibt es kein Beispiel für diesen Einsatz.
Kann mich jemand da aufklären?
Hat sich erledigt, mit viel experimentieren hab ich es selbst rausgefunden. Danke.
Gruß,
Burkhard
Zitat von: Eraser am 29 September 2020, 06:09:15
Die Frage dabei ist, warum bei r -p 6 <Variable> kein Unterschied zu r -p 1 <Variable> besteht.
Es wird immer im hinterlegten --pollinterval=10 abgefragt und nich bei z.B. 10s*6=60s.
wie im issue gerade beschrieben: es ist eine
Poll Priorität und kein Faktor auf die Zeit.
es gibt einen neuen Adapter der Version 3.0 (https://forum.fhem.de/index.php/topic,114988.new.html#new) !
LG
Reinhart
Zitat von: galileo am 26 August 2020, 12:25:42
Ich habe alles noch einmal neu auf einem Raspi4 installiert:
Raspbian 4.19.97
ttyebus 1.8
ebusd 3.4.v3.3-51
und es funktioniert einwandfrei. Ich habe *kein* Upgrade vom Raspbian auf die aktuelle Version gemacht, weil ich ja dort das Problem vermute.
Ich habe ein Image (buster4.19.97-ttyebus1.8-ebusd3.4.v3.3-51.rar) gezogen und hier (https://drive.google.com/file/d/1t5DwRCnL9svqCC7si-Y-qeUK_uVIfmuW/view?usp=sharing) abgelegt.
Ich hoffe dass das zu einem Erfolg führt. Feedback erwünscht. Eine genauere Analyse mit anderen Raspbian Versionen werde ich noch anstellen.
LG
Ich scheitere auch gerade am Umzug von Pi3B auf den Pi4B.
Wie auch schon andere User habe ich das "no signal" Problem.
Leider ist das oben genannte Image nicht mehr online verfügbar (laut Google liegt es im Online Papierkorb).
@galileo Könntest du dir das Problem mit dem aktuellen Buster auf dem Pi4 bitte noch einmal genauer anschauen.
Zitat@galileo Könntest du dir das Problem mit dem aktuellen Buster auf dem Pi4 bitte noch einmal genauer anschauen.
Das habe ich bereits getan und ich bin nach vielen Stunden Recherche gescheitert.
Das Problem ist die Zuordnung der seriellen Interrupts welche beim Raspi4 und Raspbian nach 4.19.97 einer anderen Logik gehorchen, die ich nicht nachvollziehen kann.
Sollte hier ein Linux Spezialist mitlesen, wäre seine Hilfe sehr willkommen.
Ansonsten kann ich nur empfehlen, ein altes Raspbian für RASPI4 zu verwenden (funktioniert einwandfrei) oder auf den eBUS3 Adapter umzusteigen, der wieder mit dem ttyAMA0 funktioniert.
https://forum.fhem.de/index.php?topic=114988.msg1092202#msg1092202 (https://forum.fhem.de/index.php?topic=114988.msg1092202#msg1092202)
Das "alte" Raspbian kann übrigens hier heruntergeladen werden:
https://downloads.raspberrypi.org/raspbian/images/ (https://downloads.raspberrypi.org/raspbian/images/)
und ich denke, 2020-02-07 sollte funktionieren.
LG
Zitat von: MGK am 15 Dezember 2020, 12:30:13
Wie auch schon andere User habe ich das "no signal" Problem.
Falls Du das Image (Kernel: 5.x) noch hast, könntest Du bitte folgendes probieren?
Aktiviere bitte
zusätzlich zum ttyebus den UART0 (ttyAMA0) durch den Eintrag enable_uart=1 in der /boot/config.txt.
Die ebusd Koniguration bleibt unverändert "EBUSD_OPTS="-d /dev/ttyebus....:"
Danke.
EDIT: Nach der Anpassung in der config.txt bitte einmal booten und sicherstellen, dass /dev/ttyAMA0 (ls /dev/ttyAMA0) vorhanden ist.
Zitat von: chons am 15 Dezember 2020, 14:28:12
Falls Du das Image (Kernel: 5.x) noch hast, könntest Du bitte folgendes probieren?
Aktiviere bitte zusätzlich zum ttyebus den UART0 (ttyAMA0) durch den Eintrag enable_uart=1 in der /boot/config.txt.
Die ebusd Koniguration bleibt unverändert "EBUSD_OPTS="-d /dev/ttyebus....:"
Danke.
EDIT: Nach der Anpassung in der config.txt bitte einmal booten und sicherstellen, dass /dev/ttyAMA0 (ls /dev/ttyAMA0) vorhanden ist.
Habe ich ausprobiert, leider ohne Erfolg, es findet wieder kein Signal.
Ich werde nun mal ein altes Imae probieren.
Ich habe noch mal ein bisschen weiter experimentiert.
Mit dem aktuellen Image (Kernel 5.4.79-v7l+) und mit ttyAMA0 (ohne ttyebus) findet er das Signal.
version: ebusd 3.4.v3.4-83-gab75329
signal: acquired
symbol rate: 84
max symbol rate: 103
min arbitration micros: 26
max arbitration micros: 42
min symbol latency: 26
max symbol latency: 65
reconnects: 0
masters: 4
messages: 15
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13
address 52: slave
Leider weißt ebusd den Adressen keine CSV zu.
Kann ich den Adressen die richtigen CSV manuell zuweisen?
Meine ebusd config sieht aktuell wie folgt aus:
EBUSD_OPTS="-d /dev/ttyAMA0 -p 8888 --scanconfig --httpport=8889 --latency=100000 --receivetimeout=100000"
Mit dem alten pi3B sieht die ebusctl info so aus:
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available, vaillant/15.700.csv: different version available, vaillant/52.vr_70.csv: different version available
signal: acquired
symbol rate: 22
max symbol rate: 140
min arbitration micros: 7
max arbitration micros: 86
min symbol latency: 4
max symbol latency: 21
reconnects: 0
masters: 4
messages: 677
conditional: 0
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802", loaded "vaillant/38.v32.csv"
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
Auch auf die Gefahr dass ich mich wiederhole:
Das aktuelle Raspbian Image wird mit ttyebus und RASPI 4 nicht funktionieren.
ttyAMA0 funktioniert, aber da bekommst du wahrscheinlich Probleme mit der Latency oder der Arbitrierung oder...
Ich habe die letzte mir bekannte und funktionierende Kombination aus Raspbian (Buster), ttyebus und ebusd nochmals aktiviert
(buster4.19.97-ttyebus1.8-ebusd3.4.v3.3-51.rar) und die kann wieder unter
https://drive.google.com/file/d/1t5DwRCnL9svqCC7si-Y-qeUK_uVIfmuW/view (https://drive.google.com/file/d/1t5DwRCnL9svqCC7si-Y-qeUK_uVIfmuW/view)
runtergeladen werden.
Eventuell müssen aber noch die Konfigurationen angepasst werden, weil dieses Image meinem persönlichen Umfeld entspricht.
LG
Meine Schaltung ist zwar noch nicht da, aber man könnte die SW ja schon mal installieren.
Nur, wie ist das mit root auf dem pi?
pi@raspberrypi:~ $ sudo wget -qO - https://raw.githubusercontent.com/john30/ebusd-debian/master/ebusd.gpg.key|apt-key add -
E: This command can only be used by root.
Ich komme da mit Johns Anleitung nicht weiter
https://github.com/john30/ebusd-debian/blob/master/README.md
pi@raspberrypi:~ $ sudo apt-get update
OK:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
OK:2 http://archive.raspberrypi.org/debian buster InRelease
OK:3 http://packages.microsoft.com/repos/code stable InRelease
Holen:4 https://www.ebusd.eu/repos/apt/default/buster buster InRelease [4.382 B]
Fehl:4 https://www.ebusd.eu/repos/apt/default/buster buster InRelease
Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY E30CF1F4E8C8272C
Paketlisten werden gelesen... Fertig
W: GPG-Fehler: https://www.ebusd.eu/repos/apt/default/buster buster InRelease: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY E30CF1F4E8C8272C
E: Das Depot »https://www.ebusd.eu/repos/apt/default/buster buster InRelease« ist nicht signiert.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
am einfachsten erst sudo su - dann weiter mit dem Befehl. Sonst klappt die Pipe nicht.
sudo su
# Jetzt alle weiteren Befehle ohne sudo davor
wget -qO - https://raw.githubusercontent.com/john30/ebusd-debian/master/ebusd.gpg.key|apt-key add -
Oder sudo bash -c "Dein Befehl"
Zitat von: Otto123 am 10 Februar 2021, 15:57:11
am einfachsten erst sudo su - dann weiter mit dem Befehl. Sonst klappt die Pipe nicht.
Danke, hat geklappt
:)
@DerFrankei
ich würde dich ersuchen alles was den neuen Adapter betrifft dann hier zu posten (https://forum.fhem.de/index.php?topic=118143.msg1125668#msg1125668), sonst bekommen wir die totale Verwirbelung!
LG
OK, ich war nur der Meinung, daß das geschilderte Problem mehr Raspi als Ebus war.
Hallo zusammen,
ich hoffe ihr könnt etwas Klarheit in meine Verwirrung bringen:
Kann man durch eine "falsche OS / Treiber-Config" die Hardware beschädigen?
Fehler: ich kann nicht mehr senden, nur empfangen
Hintergrund:
Seit Ende 2019 läuft bei mir die Ebus-Platine in Kombination mit einem RPI3 sauber und problemlos mit ebusd.
Seit Mitte 2020 auch mit Openhab2 und dem Ebus-Binding, hier aber mit einigen Workarounds (rule zum Neustart des Bindings, etc...)
Jetzt wollte ich am Wochenende die Workarounds ausbauen und habe folgendes gemacht:
Update des ebusd von 3.4.v3.3-51-g57eae05 auf 21.2.v21.2
Update ebus-binding von 2.5.1-6 auf 2.50.11
Update Openhab2 von 2.4.0 auf 2.5.12
Problem:
Nach dem "Update" funktionierte gar nichts mehr.
Durch den dmesg Fehler:
genirq: Flags mismatch irq 81. 00000080 (uart-pl011) vs. 00000000 (ttyebus_irq_handler)
ttyebus: Close at at major 10 minor 58
hab ich festgestellt, dass in der /boot/confix.txt der Eintrag "enable_uart=0" verschwunden war.
Also den wieder eingefügt, und durchgestartet.
Nach dem Reboot (auch mit komplett stromlos versucht) startet der ebusd auch wieder, bringt aber folgende Fehler:
[main error] scan config 08: ERR: arbitration lost
[bus error] send to 08: ERR: arbitration lost
(08 nur als Beispiel, Fehler kommt für alle Bus-Addressen)
Ich bekomme aber weiterhin alle Updates vom Bus mit:
[update notice] received unknown MS cmd: 10ecb504010d / 050000008000
[update notice] received unknown MS cmd: 1025b504010d / 050000100332
[update notice] received unknown MS cmd: 1050b5040101 / 09150100000581000100
[update notice] received read bai Status01 QQ=10: 31.5;31.5;-;-;-;off
dmesg zeigt sporadisch
ttyebus: Close at at major 10 minor 58
ttyebus: Close exit
Ich also kompletten Rollback auf das vorherige Image gemacht (von Mitte der vorigen Woche).
Problem bleibt bestehen.
Der Bus selbst funktioniert.
Eine alte 1.6er Platine an einem FTDI-Adapter lief parallel mit meinem PI 1B "zuverlässig" weiter.
(der läuft noch, weil ein paar nicht migrierte RRDs da liegen)
Daher auch das "received read" in den ebusd logs. Die "read" werden vom also PI1 gesendet.
Und die 1.6er kann auch am PI3 problemlos lesen und schreiben, nur die 2.2er Adapter-Platine will irgendwie nicht mehr
Bei einem Test der Platine mit einem
echo "das ist ein Sendetest" >/dev/ttyebus
Flackert auch die Sende-LED schwach. Die serielle Sende-Verbindung zur Platine scheint also was zu tun...
(flackern, da die um einiges schwacher leuchtet als die beiden anderen)
Habt ihr einen Tip, woran's liegen kann, oder was ich noch in Richtung Fehlersuche unternehmen kann?
Danke, und LG
Hast du zufällig auch dein Raspi OS geupdatet? Kannst du noch genauere Informationen zu Boardversion, OS, ebusd Version und Art der Anbindung geben?
Edit: Du benutzt ttyebus? In welcher Version?
Was steht bei dir in der EBUSD_OPTS Zeile?
Raspi OS wurde nicht angefasst...
Nur ein
sudo apt-get update
für die neuen Links und Packages (sowohl der ebusd als auch Openhab wurden als apt-get package installiert)
Wie prüf ich die ttyebus Version?
Den hab ich seit Anbeginn nicht mehr geändert... GIT-Checkout (liegt noch im Home-Verzeichnis) ist vom 27.10.2019
Den mal neu auschecken und kompilieren?
Wollte jetzt nicht noch mehr Änderungen ins System bringen.
#EBUSD_OPTS="-l /var/log/ebusd.log --log='all error' --log='main notice' --log='bus notice' --log='update notice' -d /dev/ttyebus -p 8888 --httpport=8880 --htmlpath=/var/www --scanconfig --enablehex --pollinterval=300 --mqtthost=192.168.0.99 --mqttport=1883 --mqtttopic=ebusd --mqttretain"
EBUSD_OPTS="-l /var/log/ebusd.log --log='all error' --log='main notice' --log='bus notice' --log='update notice' -d /dev/ttyUSB0 -p 8888 --httpport=8880 --htmlpath=/var/www --scanconfig --enablehex --pollinterval=300 --mqtthost=192.168.0.99 --mqttport=1883 --mqtttopic=ebusd --mqttretain"
Die "#" ist die für die 2.2er Platine (die nicht sendet), die aktuell konfigurierte für die 1.6er mit FTDI.
--log='update notice' aktuell nur zur Fehlersuche
Hallo zusammen,
ich hab ein Problem mit einer eigentlich bis heute Nachmittag tadellos funktionierenden Installation. Ich hab blöderweise ein Upgrade vom Kernel auf meinem Raspi von 5.4.79 auf 5.10.11 (dem letzten Stable) gemacht. Normalerweise kompilier ich dann den ttyebus neu, starte das System durch, und alles ist okay.
Leider hat mich dann, der schon dokumentierte Fehler https://github.com/eBUS/ttyebus/issues/12/ (https://github.com/eBUS/ttyebus/issues/12/) beim make install erwischt.
Hat jemand einen Tip, wie ich sowohl den Kernel, als auch die Kernel-Headers auf dem Raspi wieder zurückdrehen kann? Ich hab bisher nur Infos/Anleitungen dazu gefunden, wie ich den Kernel auf ne spezifische Version per rpi-update bringen kann, aber dann fehlen mir immer noch die Headers, die ich zum kompilieren brauche :(
Hi ich hatte das gleiche Problem mit dem neuen Kernel. Ich habe die Funktion in der Datei umgebaut und das hat dann alles geklappt. Das hat "unnamehere" beschrieben was er geändert hat. Ist halt ein lokaler "hack" ;-)
https://github.com/eBUS/ttyebus/issues/12/#issuecomment-804164612
Hallo Zusammen,
ich habe das Problem das ich irgendwie keine Daten auslesen kann. Das ganze mit ttyebus-Treiber und ebus läuft auf auf einem seperaten raspberry pie 3B+
Die orangene LED leuchtet dauerhaft und die grüne LED pulsiert schnell (Daten am ebus?)
Schaltet man die Vaillant Gastherme vom Netz dann leuchtet die grüne LED dauerhaft also gehe ich davon aus das ebus richtig verkabelt wurde.
Es Sendetest mittels echo "das ist ein Sendetest" >/dev/ttyebus bei ausgeschaltetem ebusd funktioniert auch: Rote LED leuchet kurz rot auf
ebusctl i zeigt jedoch ein "no signal"
pi@raspberrypi:~ $ ebusctl i
version: ebusd 21.2.v21.2-27-gdb524b9
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
EBUSD_OPTS Datei:
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --httpport=8080"
/var/log/ebusd.log
2021-04-07 15:14:54.217 [main notice] ebusd 21.2.v21.2-27-gdb524b9 started with auto scan on device /dev/ttyebus
2021-04-07 15:14:54.354 [bus notice] bus started with own address 31/36
2021-04-07 15:16:59.771 [main notice] update check: revision v21.2 available
Komme leider nicht weiter. Könnte jemand noch einen Tipp geben? Siehe Mini-Video im Anhang.
solange "no signal" auftaucht stimmt noch was mit dem ttyebus Treiber nicht.
kannst du einmal "ls -l /dev" posten und eventuell die komplette /etc/default/ebusd ?
LG
Hallo Reinhart,
pi@raspberrypi:~ $ ls -l /dev
insgesamt 0
crw-r--r-- 1 root root 10, 235 Apr 6 17:17 autofs
drwxr-xr-x 2 root root 640 Apr 6 17:17 block
crw------- 1 root root 10, 234 Apr 6 17:17 btrfs-control
drwxr-xr-x 3 root root 60 Jan 1 1970 bus
crw------- 1 root root 10, 63 Apr 6 17:17 cachefiles
drwxr-xr-x 2 root root 2820 Apr 6 17:28 char
crw------- 1 root root 5, 1 Apr 6 17:17 console
crw------- 1 root root 10, 203 Apr 6 17:17 cuse
drwxr-xr-x 7 root root 140 Apr 6 17:17 disk
drwxr-xr-x 2 root root 80 Jan 1 1970 dma_heap
crw-rw---- 1 root video 29, 0 Apr 6 17:17 fb0
lrwxrwxrwx 1 root root 13 Feb 14 2019 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Apr 6 17:17 full
crw-rw-rw- 1 root root 10, 229 Apr 6 17:28 fuse
crw-rw---- 1 root gpio 254, 0 Apr 6 17:17 gpiochip0
crw-rw---- 1 root gpio 254, 1 Apr 6 17:17 gpiochip1
crw-rw---- 1 root gpio 246, 0 Apr 6 17:17 gpiomem
crw------- 1 root root 10, 183 Apr 6 17:17 hwrng
lrwxrwxrwx 1 root root 12 Feb 14 2019 initctl -> /run/initctl
drwxr-xr-x 2 root root 60 Jan 1 1970 input
crw-r--r-- 1 root root 1, 11 Apr 6 17:17 kmsg
lrwxrwxrwx 1 root root 28 Feb 14 2019 log -> /run/systemd/journal/dev-log
brw-rw---- 1 root disk 7, 0 Apr 6 17:17 loop0
brw-rw---- 1 root disk 7, 1 Apr 6 17:17 loop1
brw-rw---- 1 root disk 7, 2 Apr 6 17:17 loop2
brw-rw---- 1 root disk 7, 3 Apr 6 17:17 loop3
brw-rw---- 1 root disk 7, 4 Apr 6 17:17 loop4
brw-rw---- 1 root disk 7, 5 Apr 6 17:17 loop5
brw-rw---- 1 root disk 7, 6 Apr 6 17:17 loop6
brw-rw---- 1 root disk 7, 7 Apr 6 17:17 loop7
crw-rw---- 1 root disk 10, 237 Apr 6 17:17 loop-control
drwxr-xr-x 2 root root 60 Apr 6 17:17 mapper
crw-rw---- 1 root video 240, 0 Apr 6 17:17 media0
crw-rw---- 1 root video 240, 1 Apr 6 17:17 media1
crw-r----- 1 root kmem 1, 1 Apr 6 17:17 mem
brw-rw---- 1 root disk 179, 0 Apr 6 17:17 mmcblk0
brw-rw---- 1 root disk 179, 1 Apr 6 17:17 mmcblk0p1
brw-rw---- 1 root disk 179, 2 Apr 6 17:17 mmcblk0p2
brw-rw---- 1 root disk 179, 5 Apr 6 17:17 mmcblk0p5
brw-rw---- 1 root disk 179, 6 Apr 6 17:17 mmcblk0p6
brw-rw---- 1 root disk 179, 7 Apr 6 17:17 mmcblk0p7
drwxrwxrwt 2 root root 40 Jan 1 1970 mqueue
drwxr-xr-x 2 root root 60 Apr 6 17:17 net
crw-rw-rw- 1 root root 1, 3 Apr 6 17:17 null
crw------- 1 root root 108, 0 Apr 6 17:17 ppp
crw-rw-rw- 1 root tty 5, 2 Apr 7 19:37 ptmx
drwxr-xr-x 2 root root 0 Feb 14 2019 pts
brw-rw---- 1 root disk 1, 0 Apr 6 17:17 ram0
brw-rw---- 1 root disk 1, 1 Apr 6 17:17 ram1
brw-rw---- 1 root disk 1, 10 Apr 6 17:17 ram10
brw-rw---- 1 root disk 1, 11 Apr 6 17:17 ram11
brw-rw---- 1 root disk 1, 12 Apr 6 17:17 ram12
brw-rw---- 1 root disk 1, 13 Apr 6 17:17 ram13
brw-rw---- 1 root disk 1, 14 Apr 6 17:17 ram14
brw-rw---- 1 root disk 1, 15 Apr 6 17:17 ram15
brw-rw---- 1 root disk 1, 2 Apr 6 17:17 ram2
brw-rw---- 1 root disk 1, 3 Apr 6 17:17 ram3
brw-rw---- 1 root disk 1, 4 Apr 6 17:17 ram4
brw-rw---- 1 root disk 1, 5 Apr 6 17:17 ram5
brw-rw---- 1 root disk 1, 6 Apr 6 17:17 ram6
brw-rw---- 1 root disk 1, 7 Apr 6 17:17 ram7
brw-rw---- 1 root disk 1, 8 Apr 6 17:17 ram8
brw-rw---- 1 root disk 1, 9 Apr 6 17:17 ram9
crw-rw-rw- 1 root root 1, 8 Apr 6 17:17 random
drwxr-xr-x 2 root root 60 Jan 1 1970 raw
crw-rw-r-- 1 root netdev 10, 242 Apr 6 17:17 rfkill
lrwxrwxrwx 1 root root 5 Apr 6 17:17 serial1 -> ttyS0
drwxrwxrwt 2 root root 40 Feb 14 2019 shm
drwxr-xr-x 3 root root 180 Apr 6 17:17 snd
lrwxrwxrwx 1 root root 15 Feb 14 2019 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Feb 14 2019 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Feb 14 2019 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root tty 5, 0 Apr 6 17:17 tty
crw--w---- 1 root tty 4, 0 Apr 6 17:17 tty0
crw------- 1 pi tty 4, 1 Apr 6 17:28 tty1
crw--w---- 1 root tty 4, 10 Apr 6 17:17 tty10
crw--w---- 1 root tty 4, 11 Apr 6 17:17 tty11
crw--w---- 1 root tty 4, 12 Apr 6 17:17 tty12
crw--w---- 1 root tty 4, 13 Apr 6 17:17 tty13
crw--w---- 1 root tty 4, 14 Apr 6 17:17 tty14
crw--w---- 1 root tty 4, 15 Apr 6 17:17 tty15
crw--w---- 1 root tty 4, 16 Apr 6 17:17 tty16
crw--w---- 1 root tty 4, 17 Apr 6 17:17 tty17
crw--w---- 1 root tty 4, 18 Apr 6 17:17 tty18
crw--w---- 1 root tty 4, 19 Apr 6 17:17 tty19
crw--w---- 1 root tty 4, 2 Apr 6 17:17 tty2
crw--w---- 1 root tty 4, 20 Apr 6 17:17 tty20
crw--w---- 1 root tty 4, 21 Apr 6 17:17 tty21
crw--w---- 1 root tty 4, 22 Apr 6 17:17 tty22
crw--w---- 1 root tty 4, 23 Apr 6 17:17 tty23
crw--w---- 1 root tty 4, 24 Apr 6 17:17 tty24
crw--w---- 1 root tty 4, 25 Apr 6 17:17 tty25
crw--w---- 1 root tty 4, 26 Apr 6 17:17 tty26
crw--w---- 1 root tty 4, 27 Apr 6 17:17 tty27
crw--w---- 1 root tty 4, 28 Apr 6 17:17 tty28
crw--w---- 1 root tty 4, 29 Apr 6 17:17 tty29
crw--w---- 1 root tty 4, 3 Apr 6 17:17 tty3
crw--w---- 1 root tty 4, 30 Apr 6 17:17 tty30
crw--w---- 1 root tty 4, 31 Apr 6 17:17 tty31
crw--w---- 1 root tty 4, 32 Apr 6 17:17 tty32
crw--w---- 1 root tty 4, 33 Apr 6 17:17 tty33
crw--w---- 1 root tty 4, 34 Apr 6 17:17 tty34
crw--w---- 1 root tty 4, 35 Apr 6 17:17 tty35
crw--w---- 1 root tty 4, 36 Apr 6 17:17 tty36
crw--w---- 1 root tty 4, 37 Apr 6 17:17 tty37
crw--w---- 1 root tty 4, 38 Apr 6 17:17 tty38
crw--w---- 1 root tty 4, 39 Apr 6 17:17 tty39
crw--w---- 1 root tty 4, 4 Apr 6 17:17 tty4
crw--w---- 1 root tty 4, 40 Apr 6 17:17 tty40
crw--w---- 1 root tty 4, 41 Apr 6 17:17 tty41
crw--w---- 1 root tty 4, 42 Apr 6 17:17 tty42
crw--w---- 1 root tty 4, 43 Apr 6 17:17 tty43
crw--w---- 1 root tty 4, 44 Apr 6 17:17 tty44
crw--w---- 1 root tty 4, 45 Apr 6 17:17 tty45
crw--w---- 1 root tty 4, 46 Apr 6 17:17 tty46
crw--w---- 1 root tty 4, 47 Apr 6 17:17 tty47
crw--w---- 1 root tty 4, 48 Apr 6 17:17 tty48
crw--w---- 1 root tty 4, 49 Apr 6 17:17 tty49
crw--w---- 1 root tty 4, 5 Apr 6 17:17 tty5
crw--w---- 1 root tty 4, 50 Apr 6 17:17 tty50
crw--w---- 1 root tty 4, 51 Apr 6 17:17 tty51
crw--w---- 1 root tty 4, 52 Apr 6 17:17 tty52
crw--w---- 1 root tty 4, 53 Apr 6 17:17 tty53
crw--w---- 1 root tty 4, 54 Apr 6 17:17 tty54
crw--w---- 1 root tty 4, 55 Apr 6 17:17 tty55
crw--w---- 1 root tty 4, 56 Apr 6 17:17 tty56
crw--w---- 1 root tty 4, 57 Apr 6 17:17 tty57
crw--w---- 1 root tty 4, 58 Apr 6 17:17 tty58
crw--w---- 1 root tty 4, 59 Apr 6 17:17 tty59
crw--w---- 1 root tty 4, 6 Apr 6 17:17 tty6
crw--w---- 1 root tty 4, 60 Apr 6 17:17 tty60
crw--w---- 1 root tty 4, 61 Apr 6 17:17 tty61
crw--w---- 1 root tty 4, 62 Apr 6 17:17 tty62
crw--w---- 1 root tty 4, 63 Apr 6 17:17 tty63
crw--w---- 1 root tty 4, 7 Apr 6 17:28 tty7
crw--w---- 1 root tty 4, 8 Apr 6 17:17 tty8
crw--w---- 1 root tty 4, 9 Apr 6 17:17 tty9
crw-rw-rw- 1 root root 10, 62 Apr 6 17:17 ttyebus
crw------- 1 root root 5, 3 Apr 6 17:17 ttyprintk
crw-rw---- 1 root dialout 4, 64 Apr 6 17:28 ttyS0
crw------- 1 root root 10, 239 Apr 6 17:17 uhid
crw------- 1 root root 10, 223 Apr 6 17:17 uinput
crw-rw-rw- 1 root root 1, 9 Apr 6 17:17 urandom
drwxr-xr-x 3 root root 60 Apr 6 17:17 v4l
crw-rw---- 1 root video 243, 0 Apr 6 17:17 vchiq
crw-rw---- 1 root video 247, 0 Apr 6 17:17 vcio
crw------- 1 root root 248, 0 Apr 6 17:17 vc-mem
crw-rw---- 1 root tty 7, 0 Apr 6 17:17 vcs
crw-rw---- 1 root tty 7, 1 Apr 6 17:17 vcs1
crw-rw---- 1 root tty 7, 2 Apr 6 17:17 vcs2
crw-rw---- 1 root tty 7, 3 Apr 6 17:17 vcs3
crw-rw---- 1 root tty 7, 4 Apr 6 17:17 vcs4
crw-rw---- 1 root tty 7, 5 Apr 6 17:17 vcs5
crw-rw---- 1 root tty 7, 6 Apr 6 17:17 vcs6
crw-rw---- 1 root tty 7, 7 Apr 6 17:28 vcs7
crw-rw---- 1 root tty 7, 128 Apr 6 17:17 vcsa
crw-rw---- 1 root tty 7, 129 Apr 6 17:17 vcsa1
crw-rw---- 1 root tty 7, 130 Apr 6 17:17 vcsa2
crw-rw---- 1 root tty 7, 131 Apr 6 17:17 vcsa3
crw-rw---- 1 root tty 7, 132 Apr 6 17:17 vcsa4
crw-rw---- 1 root tty 7, 133 Apr 6 17:17 vcsa5
crw-rw---- 1 root tty 7, 134 Apr 6 17:17 vcsa6
crw-rw---- 1 root tty 7, 135 Apr 6 17:28 vcsa7
crw-rw---- 1 root video 10, 61 Apr 6 17:17 vcsm-cma
crw-rw---- 1 root tty 7, 64 Apr 6 17:17 vcsu
crw-rw---- 1 root tty 7, 65 Apr 6 17:17 vcsu1
crw-rw---- 1 root tty 7, 66 Apr 6 17:17 vcsu2
crw-rw---- 1 root tty 7, 67 Apr 6 17:17 vcsu3
crw-rw---- 1 root tty 7, 68 Apr 6 17:17 vcsu4
crw-rw---- 1 root tty 7, 69 Apr 6 17:17 vcsu5
crw-rw---- 1 root tty 7, 70 Apr 6 17:17 vcsu6
crw-rw---- 1 root tty 7, 71 Apr 6 17:28 vcsu7
crw------- 1 root root 10, 137 Apr 6 17:17 vhci
crw-rw----+ 1 root video 81, 4 Apr 6 17:17 video10
crw-rw----+ 1 root video 81, 5 Apr 6 17:17 video11
crw-rw----+ 1 root video 81, 6 Apr 6 17:17 video12
crw-rw----+ 1 root video 81, 0 Apr 6 17:17 video13
crw-rw----+ 1 root video 81, 1 Apr 6 17:17 video14
crw-rw----+ 1 root video 81, 2 Apr 6 17:17 video15
crw-rw----+ 1 root video 81, 3 Apr 6 17:17 video16
crw------- 1 root root 10, 130 Apr 6 17:17 watchdog
crw------- 1 root root 250, 0 Apr 6 17:17 watchdog0
crw-rw-rw- 1 root root 1, 5 Apr 6 17:17 zero
und
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 --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 -$
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -$
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -$
# 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.
ah ja, du hast ja geschrieben das du einen Raspi3+ verwendest und da wird ja ttyAMA0 für Bluetooth verwendet und die interne ttyS0 und die ist bei dir aktiv. Solange die aktiv ist wird ttyebus nicht funktionieren können.
Ich habe jetzt keinen Pi3 da und kann das nicht weiter testen, aber suche bitte im Netz wie man die ttyS0 gänzlich abschalten kann. Schau aber zuerst in "raspi-config" nach obs nicht eh da schon geht.
LG
Im Netz finde ich ein:
systemctl stop serial-getty@ttyS0.service
und
systemctl disable serial-getty@ttyS0.service
habe ich als root aufgeführt und danach reboot.
ttyS0 ist noch immer aktiv laut ls -l /dev
crw-rw---- 1 root dialout 4, 64 Apr 7 20:47 ttyS0
pi@raspberrypi:~ $ systemctl status serial-getty@ttyS0.service
● serial-getty@ttyS0.service - Serial Getty on ttyS0
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
Hallo Reinhart,
ich habe den service zusätzlich mittels systemctl mask serial-getty@ttyS0.service maskiert. Der ist ja auch nach dem deaktivieren nicht mehr aktiv:
pi@raspberrypi:~ $ systemctl status serial-getty@ttyS0.service
● serial-getty@ttyS0.service
Loaded: masked (Reason: Unit serial-getty@ttyS0.service is masked.)
Active: inactive (dead)
Reicht das nicht aus? Oder muss das ttyS0 komplett aus ls -l /dev verschwinden?
Unter raspi-config kann man allgemein die serielle Schnittstelle deaktivieren und finde keinen Eintrag für ttyS0
(siehe Bilder im Anhang)
so, ich habe mir hier nochmals die Einträge die zur Lösung beim PI3 beigetragen haben gelesen und da habe ich diesen (https://forum.fhem.de/index.php/topic,84636.105.html) gefunden der dann bei vielen funktionierte.
Ich glaube wir brauchen jetzt den ttyS0 nicht so sehr beachten wenn der ttyAma0 weg ist. Ist schon eine Weile her als wir wir uns mit dem ttyebus Treiber beschäftigten.
LG
Meinst Du den Beitrag von diam35 mit Antwort #106?
ja!
Ich habe das mal wie diam135 im Post 106 beschreibt ausgeführt. Dort wird das Ganze aber mittels alter Kernel 4.x Version gemacht. Ich habe jedoch einen 5er Kernel
pi@raspberrypi:~ $ uname -r
5.10.17-v7+
Folgendes habe ich durchgeführt:
$ sudo echo dtoverlay=pi3-miniuart-bt | sudo tee -a /boot/config.txt
In der /boot/config.txt steht nun folgendes drin:
enable_uart=0
#dtoverlay=miniuart-bt
dtoverlay=pi3-miniuart-bt
Das auskommentierte "dtoverlay=miniuart-bt" ist eigentlich ab Raspian Buster OS korrekt. Zumindest steht das so in der Doku für die Treiberinstallation des ttyebus drin.
Ich habe es trotzdem auf "dtoverlay=pi3-miniuart-bt" abgeändert und anschl. reboot.
Trotzdem gibts ein "no signal":
pi@raspberrypi:~ $ ebusctl i
version: ebusd 21.2.v21.2-27-gdb524b9
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
Kann es sein das meine Kernel Version noch nicht mit dem ttyebus Treiber kompatibel ist?
Ich denke dann werde ich wohl ein altes Kernel einspielen müssen und mich von Buster verabschieden müssen...oder doch noch ne Idee?
Hallo Domin2000,
Ich habe schon in mehreren Posts (leider) festgestellt, dass der ttyebus Treiber ab einer bestimmten Buster Version im Zusammenhang mit einem Raspi 4 nicht mehr funktioniert.
Hintergund ist die anders geartete Interrupt Behandlung, die ich nicht mehr beherrschen konnte. Möglicherweise ist das auch eskaliert, indem es nunmehr auch für RASPI 3 nicht mehr funktioniert.
Deshalb leider dieser Hinweis: Bitte nur Buster Versionen vor Februar 2020 für V2 Adapter verwenden, das wird funktionieren. Oder aber einen V3 Adapter, welcher ohne ttyebus mit einem Standard ttyAMA0 in allen Raspi Versionen auskommt.
LG
Domin200 hat einen Raspi3+, aber kann sein das hier auch schon das selbe Problem auftritt.
Wenn alle Stricke reißen, musst du wohl oder übel auf USB ausweichen oder für diesen Zweck einen älteren Raspi nehmen.
LG
Hi galileo,
dabke für die Info. Das dachte ich mir. Ich habe ein paar Seiten davor ein Image "buster4.19.97-ttyebus1.8-ebusd3.4.v3.3-51.zip" von dir gefunden dass ich nun auf die SD Karte kopieren werde um so das Ganze zum laufen zu bekommen.
Mit welchem Image tool kann man das am einfachsten machen? SDCardFormatter + Win32DiskImager?
ZitatMit welchem Image tool kann man das am einfachsten machen? SDCardFormatter + Win32DiskImager?
Win32DiskImager ist perfekt. Dazu darf aber die SD Karte keine (vorher aufgespielten) Partitionen haben, sonst akzeptiert der Win32DiskImager die Karte nicht.
Ob das der SDCardFormatter kann weiss ich nicht.
Ich nehme immer die Windows Datenträgerverwaltung und lösche alle Volumes die auf der Karte sind. Dann das Image drauf.
Hallo galileo,
das Image von galileo ist nun drauf. Was ich nach der Installation noch gemacht habe:
# AMA0 Treiber Service deaktivieren
sudo raspi-config , zuerst hier den Serial Port deaktivieren (2x mit "no" bestätigt)
sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
ttyAMA0 ist danach verschwunden.
Irgendwie ist der ttyebus Treiber in dem Image nicht installiert und nur abgelegt?
Zumindest gibt es die Dateien unter ~/ttyebus aber ttyebus taucht nicht als modul auf.
pi@raspberrypi:~/ttyebus $ modinfo ttyebus
modinfo: ERROR: Module ttyebus not found.
pi@raspberrypi:~/ttyebus $ ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
update check: version 21.2 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
Der ebus Service läuft zwar kann aber den ttyebus nicht finden.
Log:
pi@raspberrypi:~/ttyebus $ tail -f /var/log/ebusd.log
2021-04-12 19:07:01.447 [bus error] unable to open /dev/ttyebus: ERR: element not found
2021-04-12 19:07:01.447 [bus notice] device invalid
2021-04-12 19:07:06.448 [bus error] unable to open /dev/ttyebus: ERR: element not found
2021-04-12 19:07:06.448 [bus notice] device invalid
2021-04-12 19:07:11.448 [bus error] unable to open /dev/ttyebus: ERR: element not found
2021-04-12 19:07:11.450 [bus notice] device invalid
2021-04-12 19:07:16.451 [bus error] unable to open /dev/ttyebus: ERR: element not found
2021-04-12 19:07:16.451 [bus notice] device invalid
2021-04-12 19:07:21.451 [bus error] unable to open /dev/ttyebus: ERR: element not found
2021-04-12 19:07:21.451 [bus notice] device invalid
2021-04-12 19:07:26.452 [bus error] unable to open /dev/ttyebus: ERR: element not found
2021-04-12 19:07:26.452 [bus notice] device invalid
unter ~/ttyebus gibt es aber schon die Dateien:
pi@raspberrypi:~/ttyebus $ ls -l
total 104
-rw-r--r-- 1 pi pi 1223 Aug 26 2020 Makefile
-rw-r--r-- 1 pi pi 35 Aug 26 2020 modules.order
-rw-r--r-- 1 pi pi 0 Aug 26 2020 Module.symvers
-rw-r--r-- 1 pi pi 6499 Aug 26 2020 README.md
-rw-r--r-- 1 pi pi 13580 Aug 26 2020 ttyebus.ko
-rw-r--r-- 1 pi pi 35525 Aug 26 2020 ttyebusm.c
-rw-r--r-- 1 pi pi 11172 Aug 26 2020 ttyebusm.o
-rw-r--r-- 1 pi pi 1853 Aug 26 2020 ttyebus.mod.c
-rw-r--r-- 1 pi pi 4184 Aug 26 2020 ttyebus.mod.o
-rw-r--r-- 1 pi pi 9976 Aug 26 2020 ttyebus.o
Soll ich das hier unten noch ausführen?
sudo apt-get update sudo apt-get -y upgrade
sudo apt-get install raspberrypi-kernel-headers
cd ~ git clone https://github.com/ebus/ttyebus.git
cd ~/ttyebus make
sudo make install
lsmod modinfo ttyebus
Aber dann würde er doch beim upgrade den kernel hochziehen und es würde nix mehr gehen...?
Die unveränderte ebus config Datei:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig -d /dev/ttyebus"
# 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.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# 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.
~
Ich habe nochmal aus dem ttyebus Verzeichnis ein"make" und danach ein "sudo make install" durchgeführt
--> Kernel ist nun kaputt und muss das Image nochmal auf die SD Karte installieren...
Ergebnis:
pi@raspberrypi:~/ttyebus $ make
make -C /lib/modules/4.19.97-v7+/build M=/home/pi/ttyebus modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.97-v7+'
Building modules, stage 2.
MODPOST 1 modules
CC /home/pi/ttyebus/ttyebus.mod.o
LD [M] /home/pi/ttyebus/ttyebus.ko
make[1]: Leaving directory '/usr/src/linux-headers-4.19.97-v7+'
pi@raspberrypi:~/ttyebus $ sudo make install
cp ttyebus.ko /lib/modules/4.19.97-v7+/kernel/drivers/tty/serial/ttyebus.ko
depmod -a
cd /lib/modules/4.19.97-v7+/kernel/drivers/tty/serial/
modprobe ttyebus
sed -i "s/ttyebus//g" /etc/modules
echo "ttyebus" >> /etc/modules
pi@raspberrypi:~/ttyebus $
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.324555] Internal error: Oops: 817 [#1] SMP ARM
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.346489] Process bushandler (pid: 579, stack limit = 0x50bfda62)
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.347708] Stack: (0xb7ed1d40 to 0xb7ed2000)
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.348910] 1d40: 80d63f48 00000039 7f75c088 80d63f48 b7ed1d8c b7ed1d60 805c4d88 7f7 5a5ec
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.351304] 1d60: 805c4c24 8093bdf4 80d04d48 80e1cc1c b9da75c0 b5d6a6f0 b41c7000 000 00000
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.353695] 1d80: b7ed1dc4 b7ed1d90 802d531c 805c4c30 00000039 c215155f b5d6a6f0 b41 c7000
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.356079] 1da0: 00000000 b5d6a6f0 b7ed1f50 b41c7008 802d522c 00000000 b7ed1dec b7e d1dc8
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.358493] 1dc0: 802cbecc 802d5238 00000902 00000000 00000000 b7ed1f50 b41c7000 b7e d1e90
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.361020] 1de0: b7ed1dfc b7ed1df0 802cd3a8 802cbc9c b7ed1e8c b7ed1e00 802dff68 802 cd378
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.363661] 1e00: b7ed1e00 801ae810 b7ed1e54 b7ed1e18 801ae810 801ae428 b7e1e000 b7e d0000
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.366390] 1e20: 8019b460 c215155f 80d04d48 00000041 80d0568c 00000000 00000000 000 00006
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.369259] 1e40: 00000002 b5d6a6f0 b96eb210 b5945990 801af658 801af394 00ebf000 c21 5155f
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.372195] 1e60: 00000001 80d04d48 80d04d48 b7ed1f50 b7ed1e90 00000001 b7ed0000 000 00142
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.375199] 1e80: b7ed1f44 b7ed1e90 802e1e50 802dfb4c b96eb210 b5945990 f5f94e18 000 00007
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.378237] 1ea0: b96f0015 006000c0 00000000 b9ba1110 b5d6a6f0 00000101 00000002 000 00718
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.381262] 1ec0: 00000000 00000000 00000000 b7ed1ed0 00000000 c215155f 00000000 000 00008
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.384289] 1ee0: b9084e00 b9084e18 00000000 00000400 00000902 00000020 b7ed1f34 b7e d1f08
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.387325] 1f00: b96f0000 00000000 00000902 00000002 ffffff9c ffffff9c b96f0000 c21 5155f
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.390360] 1f20: b7ed0000 00000008 80d04d48 ffffff9c b96f0000 801011c4 b7ed1f94 b7e d1f48
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.393394] 1f40: 802cd688 802e1ddc 801b26c0 801b1984 00000902 00000000 00000006 000 00100
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.396428] 1f60: 00000001 c215155f 80101068 00eb8090 76f3d968 00000000 00000142 801 011c4
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.399452] 1f80: b7ed0000 00000142 b7ed1fa4 b7ed1f98 802cd784 802cd554 00000000 b7e d1fa8
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.402482] 1fa0: 80101000 802cd774 00eb8090 76f3d968 ffffff9c 7eb26f1f 00000902 000 00000
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.405517] 1fc0: 00eb8090 76f3d968 00000000 00000142 76b04e1c 00000005 7eb26f1f 000 702f0
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.408552] 1fe0: 00000002 76b04d38 00000000 76edfc5c 80000010 ffffff9c 00000000 000 00000
Message from syslogd@raspberrypi at Apr 12 19:56:46 ...
kernel:[ 788.444713] Code: e3a02001 e5943018 e5842014 f57ff04e (e5835030)
Zumindest ergibt modinfo ttyebus das ttyebus nun installiert ist
pi@raspberrypi:~/ttyebus $ modinfo ttyebus
filename: /lib/modules/4.19.97-v7+/kernel/drivers/tty/serial/ttyebus.ko
version: 1.8
description: Kernel module for the ebusd directly connected through the PL011 UART to the eBus adapter
author: Galileo53
license: GPL
srcversion: 5FAE7FDBE1D6FFAC18CA5A9
depends:
name: ttyebus
vermagic: 4.19.97-v7+ SMP mod_unload modversions ARMv7 p2v8
Ich habe noch etwas rumexperimentiert und mal den ebus Treiber auf ttyAMA0 eingestellt. Ergebnis: Signal aquired!
Aber so wie ich ein paar Seiten hier im Thread früher gelesen habe ist das nicht gut. Die Platine scheint also zu funktionieren nur irgendwie ttyebus mit mit RPI 3B+ :-(
@galileo: Vllt ist das Image nicht kompatibel mit dem RPI 3B+?
ebusctl i
pi@raspberrypi:~ $ ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 23
max symbol rate: 85
reconnects: 0
masters: 2
messages: 12
conditional: 0
poll: 0
update: 4
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
/var/log/ebusd.log
pi@raspberrypi:~ $ tail -f /var/log/ebusd.log
2021-04-12 20:57:35.478 [bus notice] device invalid
2021-04-12 20:57:40.060 [main notice] SIGTERM received
2021-04-12 20:57:40.479 [bus error] unable to open /dev/ttyebus: ERR: element not found
2021-04-12 20:57:40.479 [bus notice] device invalid
2021-04-12 20:57:41.754 [main notice] ebusd stopped
2021-04-12 20:57:46.389 [main notice] ebusd 3.4.v3.3-51-g57eae05 started with auto scan
2021-04-12 20:57:46.726 [bus notice] bus started with own address 31/36
2021-04-12 20:57:46.783 [bus notice] signal acquired
2021-04-12 20:57:49.735 [bus notice] new master 10, master count 2
2021-04-12 20:57:54.748 [main error] scan config 15: ERR: read timeout
2021-04-12 20:58:31.010 [bus notice] max. symbols per second: 101
Zitat@galileo: Vllt ist das Image nicht kompatibel mit dem RPI 3B+?
Ich besitze leider keinen RASPI3+, nur einen RASPI3 und von dem stammt das Image.
Im Netz kann man allerdings Hinweise finden, dass ein auf dem RASPI3 erstelltes System auf dem RASPI3+ nicht lauffähig ist.
Eigentlich sollte das Image so wie du es installiert hast bereits alle Einstellungen und Installationen korrekt haben. Also ttyebus sichtbar, ttyAMA0 weg, etc.
All deine Versuche sollten also überflüssig sein. Wenn dem nicht so ist dann bedeutet es wahrscheinlich wirklich dass das mit dem 3+ nicht kompatibel ist.
In diesem Fall kann ich dir nur vorschlagen: Lade dir "buster 4.19.97" aus dem Netz herunter und installiere es neu auf dem 3+.
Dann folge der Anleitung für ttyebus Installation auf Github. Für ebusd kannst du vermutlich die neueste Version verwenden.
Das sollte dann den gleichen Effekt wie das Image bringen, halt nur angepasst auf den 3+. Einen Erfolg garantieren kann ich damit aber leider nicht weil ich es nicht ausprobieren kann.
LG
Es funktioniert! @Galileo - vielen Dank!!!
Damit kann ich bestätigen dass das Image für Raspi 3B+ funktioniert.
Leider war die ttyebus Installation irgendwie nicht vollständig denn das Modul ttyebus war nicht unter dev/ gelistet.
Was ich gemacht habe:
rm -rf ttyebus/
git clone https://github.com/ebus/ttyebus.git
cd ttyebus/
ls -la
make
ls -la
sudo make install
Daten kommen:
pi@raspberrypi:~ $ tail -f /var/log/ebusd.log
2021-04-13 06:02:47.431 [update notice] received update-write bai SetMode QQ=10: auto;32.5;-;-;0;0;1;0;0;0
2021-04-13 06:02:55.688 [update notice] received read bai Status01 QQ=10: 31.5;32.0;-3.125;-;-;off
2021-04-13 06:02:55.984 [update notice] received read vr_70 SensorData QQ=10: 47.00;25.12;-;-;7.62;21.00;c8 50 00
2021-04-13 06:02:56.257 [update notice] received update-write bai SetMode QQ=10: auto;32.5;-;-;0;0;1;0;0;0
2021-04-13 06:02:56.783 [update notice] received write vr_70 SetActorState QQ=10: off;off;on;off;on;off;off
2021-04-13 06:03:05.714 [update notice] received read bai Status01 QQ=10: 31.5;32.0;-3.125;-;-;off
2021-04-13 06:03:06.010 [update notice] received read vr_70 SensorData QQ=10: 46.94;25.06;-;-;7.50;21.00;c8 50 00
2021-04-13 06:03:06.283 [update notice] received update-write bai SetMode QQ=10: auto;32.5;-;-;0;0;1;0;0;0
2021-04-13 06:03:06.542 [update notice] received read bai Status02 QQ=10: auto;60;75.0;70;70.0
2021-04-13 06:03:06.806 [update notice] received write vr_70 SetActorState QQ=10: off;off;on;off;on;off;off
2021-04-13 06:03:15.731 [update notice] received read bai Status01 QQ=10: 31.5;32.0;-3.125;-;-;off
2021-04-13 06:03:16.025 [update notice] received read vr_70 SensorData QQ=10: 46.94;25.06;-;-;7.38;21.00;c8 50 00
2021-04-13 06:03:16.299 [update notice] received update-write bai SetMode QQ=10: auto;32.5;-;-;0;0;1;0;0;0
2021-04-13 06:03:16.822 [update notice] received write vr_70 SetActorState QQ=10: off;off;on;off;on;off;off
2021-04-13 06:03:25.757 [update notice] received read bai Status01 QQ=10: 31.5;32.0;-3.125;-;-;off
2021-04-13 06:03:26.051 [update notice] received read vr_70 SensorData QQ=10: 46.94;25.06;-;-;7.38;21.00;c8 50 00
2021-04-13 06:03:26.325 [update notice] received update-write bai SetMode QQ=10: auto;32.5;-;-;0;0;1;0;0;0
2021-04-13 06:03:26.846 [update notice] received write vr_70 SetActorState QQ=10: off;off;on;off;on;off;off
2021-04-13 06:03:31.718 [main notice] update check: version 21.2 available
2021-04-13 06:03:35.734 [update notice] received read bai Status01 QQ=10: 31.5;32.0;-3.125;-;-;off
2021-04-13 06:03:36.028 [update notice] received read vr_70 SensorData QQ=10: 46.94;25.06;-;-;7.31;21.00;c8 50 00
2021-04-13 06:03:36.304 [update notice] received read bai DateTime QQ=10: sync;-:-:-;-.-.-;-3.125
2021-04-13 06:03:36.547 [update notice] received update-read broadcast vdatetime QQ=10: 07:03:36;13.04.2021
2021-04-13 06:03:36.820 [update notice] received update-write bai SetMode QQ=10: auto;32.5;-;-;0;0;1;0;0;0
2021-04-13 06:03:37.082 [update notice] received write vr_70 SetActorState QQ=10: off;off;on;off;on;off;off
2021-04-13 06:03:37.339 [update notice] received read bai Status02 QQ=10: auto;60;75.0;70;70.0
2021-04-13 06:03:37.604 [update notice] received unknown MS cmd: 1008b5110100 / 08ff010d0008000003
2021-04-13 06:03:37.850 [update notice] received unknown MS cmd: 1008b5100305ff03 / 0101
2021-04-13 06:03:38.092 [update notice] received update-write bai StatusCirPump QQ=10: on
2021-04-13 06:03:38.328 [update notice] received unknown MS cmd: 1008b5120204ff / 0101
2021-04-13 06:03:42.179 [update notice] received update-read broadcast outsidetemp QQ=10: -3.125
2021-04-13 06:03:45.771 [update notice] received read bai Status01 QQ=10: 31.5;32.0;-3.125;-;-;off
2021-04-13 06:03:46.067 [update notice] received read vr_70 SensorData QQ=10: 46.94;25.06;-;-;7.38;21.00;c8 50 00
2021-04-13 06:03:46.340 [update notice] received update-write bai SetMode QQ=10: auto;32.5;-;-;0;0;1;0;0;0
2021-04-13 06:03:46.860 [update notice] received write vr_70 SetActorState QQ=10: off;off;on;off;on;off;off
Verbindung steht:
pi@raspberrypi:~ $ ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
update check: version 21.2 available
signal: acquired
symbol rate: 49
max symbol rate: 116
min arbitration micros: 7
max arbitration micros: 62
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 3
messages: 640
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
PS: Es wäre cool wenn der Adapter mit ttyebus auch mit den Neusten Kernel funktionieren könnte ;-) Aber Du hast ja vorher geschrieben das dies zu Komplex sei...
Leider habe ich den Rpi 2.2 Adapter erst fast nach 1,5 Jahren aus dem Schrank geholt und mit einem Raspi verbunden. In dieser Zeit ist natürlich viel passiert...
Habe gerade meinen Raspi upgedatet, neu gestartet und stehe wieder ohne Signal da.
root@raspberrypi:/home/pi# ebusctl info
version: ebusd 21.2.v21.2-12-g86b700c
access: *
signal: no signal
reconnects: 1
masters: 4
messages: 64
conditional: 0
poll: 0
update: 10
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=HMU01;SW=0304;HW=8802", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 71: master #9
address 76: slave #9
address e8: slave
address ff: master #25, ebusd
Nur, warum findet er auf der Adresse 08 etwas, wenn er doch kein Signal hat?
vermutlich hatte er Signal, er hat ein csv geladen aber dann ist es wieder verschwunden. Schau doch bitte ins Log, dann weiß man mehr was los war.
Das mit den Updaten beim RPI un dem ttyebus Treiber ist immer eine heiße Sache, wenn beim Kerneltreiber was geändert wird ist dann aus. Beim RPI gilt leider der Spruch, "never touch a running system!"
LG