eBus Schaltung Rpi in Betrieb nehmen!

[jkyprian]

Mit

Code Auswählen Erweitern

watch -n1 "cat /proc/interrupts"
könntest du feststellen, ob der Linux Kernel die Interrupts überhaupt noch sieht...

Code Auswählen Erweitern

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?

[galileo]

Heiß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

[jkyprian]

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:

Code Auswählen Erweitern


UART_RX_ERR = 0x8 = 1000

Die Doku sagt dazu:

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...

[jkyprian]

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.

[jkyprian]

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?

[galileo]

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 !!!

Spricht 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

[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 !!!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

[john30]

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.

[MarkusEd]

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:

Code Auswählen Erweitern

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 scheiter an:

Code Auswählen Erweitern

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

[Reinhart]

Hallo MarkusEd

Es gibt da mehre Möglichkeiten die Messwerte auf den richtigen PI zu bringen, ich mache das mit Fhem2Fhem und Remotepi.

Code Auswählen Erweitern

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

[MarkusEd]

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:

Code Auswählen Erweitern

pi@raspberrypi:~ $ ls /usr/src/
linux-headers-4.9.80+  linux-headers-4.9.80-v7+

CIAO
Markus

[galileo]

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 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

[Reinhart]

@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.

Code Auswählen Erweitern

#################################################
#            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

[MarkusEd]

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.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


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

[Reinhart]

Code Auswählen Erweitern

define RemotePI FHEM2FHEM 192.168.2.63:7072 LOG:.*(temperature).
dir fehlt hinten ein Stern

Code Auswählen Erweitern

define RemotePI FHEM2FHEM 192.168.2.63:7072 LOG:.*(temperature).*
so
LG