FHEM + ODROID-XU4 + COC + USB?

Begonnen von alanblack, 16 Februar 2019, 19:02:39

Vorheriges Thema - Nächstes Thema

alanblack

"Nicht schon wieder ein Umzugsthread!"

Im Grunde schon, aber ich versuche den "langweiligen Teil" wegzulassen.  ;)

[eilige überlesen das Folgende]
Trotzdem will ich ein paar Hintergrundinfos liefern, die vielleicht aber vielleicht auch nicht eine Rolle spielen:
Mein RPi2, auf dem (ausschließlich) FHEM läuft wird so langsam etwas träge. Ich mute dem kleinen Schätzchen allerdings auch mehr und mehr zu. Alleine die genutzten Komponenten mögen hier manchem die Nackenhaare aufstellen: am dem Pi hängen ein HMUART (per USB), ein LaCrosse, ein BTLE, ein COC für FS20 und IT sowie eine FHZ noch für FS20 und das eine oder andere HMLAN. Mit dem Mix kommt er halbwegs klar, aber die Mustererkennung, die ich jetzt angefangen habe, zu implementieren, zieht einfach zuviel Last. perl steht teilweise minutenlang im Bereich >50% bei top und kommt selten unter die 10%-Marke. Dann kommen natürlich Reaktionen auch durchaus mal etwas verspätet - man bemerkt es vor allem bei Lichtern, die halt erst mit Verzögerung angehen.
Dadurch dass ich auch noch mit Xiaomi liebäugele (die Dinger haben gegenüber bspw. LaCrosse einen 1a-WAF), besteht für mich hier zeitnah Handlungsbedarf. 1. wegen des angesprochenen Laggings und 2. weil der RPi noch auf Wheezy läuft, Xiaomi aber mindestens Jessie möchte.
[Ende der Hintergrundinfos]

Testweise habe ich eine FHEM-Spielwiese mal auf meinem ODROID-XU4 (DVB-S2-Server) installiert und dort (unter Stretch) mal Xiaomi antestet. Das ist in den Griff zu kriegen. Wenn ich Lösungen für alle relevanten Einzelprobleme habe bekommt FHEM einen eigenen XU4. Den möchte ich aber nicht dorthin bauen, wo der RPi jetzt hängt, möchte aber den Funkstandort des RPi weiter nutzen. Also meine Fragen, die ich bisher nicht durch googlen gelöst bekommen habe:

Die ganzen "Sticks", welche im RPi stecken, sind wahrscheinlich über http://usbip.sourceforge.net/ mit dem XU4 nutzbar. Hat das schon einmal jemand getestet? Oder gibt es eine einfachere oder irgendwie bessere Lösung, die mir noch nicht über den Weg gelaufen ist?

Gibt es irgendeine ähnliche Lösung für den COC? Oder muss ich, vorausgesetzt, dass das USB-IP-Project funktioniert, hier einen CUL kaufen?

Danke für Eure Ideen/Meinungen/Antworten!
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

alanblack

Falls irgendwer über diesen Thread stolpert und sich fragt, ob es für folgende Probleme eine gemeinsame Lösung gibt:
1. FHEM auf raspberryPI trotz Optimierung zu langsam
2. Funkstandort für größere FHEM-Computer ungeeignet (z.B. wegen WAF)
3. nebenbei Xiaomi einbinden

Meine Lösung sieht in Kurzform folgendermaßen aus:
deCONZ (Lösung für Detailproblem gibt es hier:https://github.com/dresden-elektronik/deconz-rest-plugin/issues/284) läuft mit FHEM zusammen auf einem XU4. deCONZ lässt sich problemlos von anderen Hosts nutzen.
Auf dem "alten" PI läuft FHEM quasi nur noch als Funkschnittstelle, sprich: alle physikalischen Geräte sind hier "define"d.
Alle logischen Geräte wie Dummies, ATs, Notifies... sowie sämtliche Programmlogik laufen auf dem XU4. Dieser hängt per FHEM2FHEM am PI.
Der XU4 steuert den PI bzw. die Geräte daran per HttpNonBlockingGet.
Damit sind die Antwortzeiten wieder im "nicht störenden Bereich".

Was nebenbei noch zusätzlich geht, ist dass der PI den XU4 überwacht und zur Not automatisch wieder alleine die Haussteuerung betreibt.
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons