[Gelöst] TPUART USB Modul KNX/EIB - Hohe CPU Auslastung - FHEM stürzt ab

Begonnen von TimoWer, 06 Juni 2017, 16:43:06

Vorheriges Thema - Nächstes Thema

TimoWer

Hallo zusammen, ich muss mich mit meinem Problem nach langer Recherche und nach langem hin und her doch ans Forum wenden und euer Wissen nutzen  :-X

Ich hatte mir den BUS-Ankoppler von Busware.de besorgt und die diesen direkt am USB Port meines Raspberry Pi 3 angeschlossen. Soweit so gut...

Per Define nach der Anleitung auf https://wiki.fhem.de/wiki/EIB_/_KNX habe ich den Stick in Fhem eingebunden. Anschließend habe ich von EIB auf KNXD umgestellt. Als Orientierungshilfe habe ich mich an die Anleitungen aus dem FHEM Wiki sowie die der Github Seite gehalten
https://wiki.fhem.de/wiki/Knxd
https://github.com/knxd/knxd

Nun zu meinem Problem...

Anfangs lief die Einbindung der KNX-Geräte (Lampen / Rolläden) Problemlos alles ließ sich schalten bzw. steuern. Dazu habe ich mich an der autocreate Funktion vergriffen. Nach einem Update Befehl in FHEM ging nichtsmehr bei Versuch eine Lampe zu schalten hat sich FHEM aufgehängt (CPU) Auslastung bei 100% - Nur Neustart hat geholfen...

Nun habe ich den RaPi neu aufgesetzt FHEM neu aufgespielt und stehe vor dem gleichen Problem:

FHEM Läuft
TUL-Stick eingebunden (definde EIB...)
autocreate aktiv
KNX Geräte werden erkannt
Aber die CPU Auslastung wieder bei 100%

Sobald ich die Busleitung vom Stick entferne normalisiert sich die CPU Auslastung wieder und ist gegen 0

Ich weiß an dieser Stelle leider nicht mehr weiter und hoffe ihr konnt mir helfen...

Grüße
Timo

Michael Schmidt

Du hast vermutlich die Geräte noch angelegt wie bei EIB.

define testgeraet EIB 1/2/3
attr testgeraet IODEV ...

richtig ist nun
define testgeraet KNX 1/2/3:dpt1 z.B.

LG

TimoWer

Okay gleich mal schauen... denke mal die autocreate zu deaktivieren ist an dieser stelle sinnvoll oder?

Michael Schmidt


Andi291

Kann mich Jens nur anschließen. Wenn EIB Geräte angelegt sind, aber nur knx aktiv ist, werden die eib-nachrichten nie aus der queue geholt. Die läuft dann voll...

Elgardo

Ich habe das selbe Problem. Nach einem Update steigt die CPU Auslastung auf 100% sobald ich versuche eine Lampe einzuschalten.
Sämtliche Geräte habe ich als KNX Devices wie folgt angelegt:

define Licht KNX 0/0/5:dpt1
attr Licht IODev tul

Den TUL selbst:

define tul TUL tul:/dev/ttyACM0 1.1.249
attr tul useEIB 0

Parallel dazu ist für meine Homematic Rauchmelder in meine FHEM-Installation ein CUL eingebunden.

Mit den "alten" 00_tul.pm und 10_KNX.pm Dateien funktioniert alles einwandfrei.

Die FHEM Installation läuft auf einem Raspberry 2 mit Raspbian Jessie.

Stimmt irgendetwas an meinen Gerätedefinitionen nicht?
Für Tipps die mir zur Problemlösung weiterhelfen bin ich sehr dankbar.

LG
Martin

TimoWer

Zitat von: Elgardo am 08 Juni 2017, 13:53:29
Ich habe das selbe Problem. Nach einem Update steigt die CPU Auslastung auf 100% sobald ich versuche eine Lampe einzuschalten.
Sämtliche Geräte habe ich als KNX Devices wie folgt angelegt:

define Licht KNX 0/0/5:dpt1
attr Licht IODev tul

Den TUL selbst:

define tul TUL tul:/dev/ttyACM0 1.1.249
attr tul useEIB 0

Parallel dazu ist für meine Homematic Rauchmelder in meine FHEM-Installation ein CUL eingebunden.

Mit den "alten" 00_tul.pm und 10_KNX.pm Dateien funktioniert alles einwandfrei.

Die FHEM Installation läuft auf einem Raspberry 2 mit Raspbian Jessie.

Stimmt irgendetwas an meinen Gerätedefinitionen nicht?
Für Tipps die mir zur Problemlösung weiterhelfen bin ich sehr dankbar.

LG
Martin

Wie stelle ich den auf die ""alten" 00_tul.pm und 10_KNX.pm Dateien" um? Kannst du mir das erklären? Das wäre super  :D

Noch eine Anmerkung zu meinem Problem: Kann es sein das es mit den Schreibrechten der "fhem.cfg" Zusammenhängt hatte diese nach der Installation von Fhem nicht für die WEB-Oberfläche eingetragen. Weil in den KNX Geräten welche ich angelegt habe ist nach wie vor das model attr hinterlegt so z.B. auch "Blink" das sollte ja mit der Umstellung auf KNX nicht mehr vorhanden sein...

TimoWer

Im übrigen habe ich meinen TUL wie folgt in FHEM eingebunden:

define EIB TUL tul:/dev/ttyACM0@57600 1.1.251

Da es wie bereits geschrieben eine Anfangs (Bis zum update Befehl in FHEM) funktionierte gehe ich nicht davon aus das sich hier ein Fehler eingeschlichen hat... Oder liege ich da flasch ?!

Bin echt am verzweifeln  :o

Andi291

Servus!

An einen systematischen Fehler glaube ich nicht. Ich würde auch Dir empfehlen, den knxd zu verwenden...

Andi291

Zwei Ansätze hab ich:

1. in der fhem.cfg darf KEIN EINZIGES define mit EIB stehen, wenn in der TUL useEIB auf 0 steht. Wenn in der TUL useEIB auf 1 steht, muss mindestens ein EIB-Define vorhanden sein. Sonst müllt es den Speicher voll.
2. 10_knx und 00_tul müssen zueinander passen. Seit Umstellung auf den erweiterten Adressbereich verträgt es hier keine Inkompatibilitäten mehr.

Was ich nicht sicher auschließen kann, ist dass das Modul 10_eib mit der TUL nicht mehr sauber kann - wegen der erweiterten Gruppenadressen...

Grüße, Andi

P.S.: Besser als raten und hilfreicher als Orakeln sind meist Logs mit Level 5 zum Fehlerzeitpunkt...

CQuadrat

#10
Ich hatte nach dem letzten Update ein ähnliches Problem.

Eine Konkretisierung von dpt1 auf dpt1.008 half bei mir.
Musst Du ggf. natürlich an den Device-Typ anpassen.

FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Andi291

DAS kann ich mir nicht erklären - das darf keinen Unterschied machen. Ich selbst habe etliche dpt1 im Einsatz.

Code:

"dpt1" => {CODE=>"dpt1", UNIT=>"", FACTOR=>undef, OFFSET=>undef, PATTERN=>qr/([oO][nN])|([oO][fF][fF])|(0?1)|(0?0)/, MIN=>"off", MAX=>"on"}, 
"dpt1.001" => {CODE=>"dpt1", UNIT=>"", FACTOR=>undef, OFFSET=>undef, PATTERN=>qr/([oO][nN])|([oO][fF][fF])|(0?1)|(0?0)/, MIN=>"off", MAX=>"on"},

CQuadrat

Und .008?

War aber definitiv ein Problem bei mir. Ich benutze aber auch noch den eibd, falls das hier überhaupt eine Rolle spielt.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue

Andi291

Syntaktisch das gleiche...das KANN nichts machen. Da muss der Hund woanders begraben gewesen sein.

CQuadrat

Zitat von: Andi291 am 08 Juni 2017, 20:36:58
Syntaktisch das gleiche...das KANN nichts machen. Da muss der Hund woanders begraben gewesen sein.

Vielleicht drehe ich es am Wochenende nochmal zurück, um den Freeze/Absturz zu provozieren.
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), KM271 (per ser2net), SONOS (div. Gimmicks), OneWire, Hue