Funkmodul auf Remote-Raspi per ser2net in RasperryMatic nutzen

[f0obar]

Hallo,

ich habe mal eine spezielle Frage: ich betreibe an einer zentralen Stelle in meinem Haus bereits einen alten Raspi (Raspberry Pi 1, Model B) per POE, der derzeit nix anderes macht, als mir einen angeschlossenen Zigbee-USB-Stick per ser2net über Netzwerk an meinen Heimserver zu reichen.

Dafür reicht die Leistung des alten Raspis ganz locker. Ich habe mir mittels buildroot auch ein speziell angepasstes System dafür gebaut (read-only rootfs), sodass das Ganze auch wahnsinnig zuverlässig läuft. Muss ja auch nix weiter können.

Auf diesen Raspi würde ich nun gern noch das "alte" Funkmodul (HM-MOD-RPI-PCB) stecken und dieses ebenfalls per Netzwerk an eine RasperryMatic-VM durchleiten, die ebenfalls auf dem Heimserver laufen soll. Das neuere Funkmodul (RPI-RF-MOD) passt ja wegen fehlenden GPIO-PINs nicht auf den alten Raspi. Alternativ würde ich aber auch den HMIP-Funkstick nehmen, sofern das hilft (der kann ja offenbar seit neustem sowohl HM-Classic als auch HM-IP).

Fragen:

1. Ist das HM-MOD-RPI-PCB wirklich nur ein serielles Gerät, was man auf diese Weise per ser2net exposen kann?
2. Geht das grundsätzlich mit RaspberryMatic? Das HB-RF-ETH von Alex Reinert geht ja offenbar (sehr cooles Gerät!), passen die Anleitungen dafür oder nutzt das ein anderes Protokoll?
3. Würde man auf dem Raspi noch spezielle Kernel-Module benötigen oder würde das alles in der RaspberryMatic-VM gemacht werden?

Grüße,
f0obar

[jmaus]

Dieses Thema wurde hier an verschiedenen Stellen im Forum bereits mehrfach durchgekaut und mit entsprechenden Suchparametern solltest du diese Beiträge finden können.

Resümee des ganzes war: Geht nicht! Die Homematic/GPIO Funkmodule nutzen zwar serielle Kommunikation aber es gibt durchaus einen Grund wieso spezielle Kernelmodule gebraucht werden (generic_raw_uart). Und das liegt einfach daran, das das Homematic Funkprotokoll gewisse Anforderungen an Latenzzeiten bei der Kommunikation hat und da kommt es auf jede Millisekunde an. Und die Linux eigenen seriellen Treiber (ttyXXX) sind dafür einfach zu lahm bzw haben wegen tty zuviel Overhead. Das ist genau der Grund warum es diesen raw_uart Kerneltreiber gibt. Damit werden diese benötigten minimalen Latenzen entsprechend eingehalten.

Und wenn man jetzt denkt das man „ser2net“ doch einfach einsetzen könnte um das Funkmodul wie beim HB-RF-ETH abgesetzt woanders im LAN zu betreiben, so hat man die Rechnung eben an der falschen Stelle getan und diesen Fakt ausser Acht gelassen.

Also nein, es geht nicht und wird auch nicht gehen! Und auch wenn du es irgendwie zum laufen bekommst um die paar Euro für ein HB-RF-ETH zu sparen, wirst du früher oder später bei mehr und mehr Traffic genau über dieses Problem stoßen.

Ergo: Besorg dir ein HB-RF-ETH und verlass dich darauf das da jemand sich schon einen Kopf gemacht hat warum eine wxtra Hardwareentwicklung und extra Kerneltreiber angesagt ist

[f0obar]

Hallo,

danke erstmal für die schnelle Antwort. Echt stark, wie engagiert du bist!

Dieses Thema wurde hier an verschiedenen Stellen im Forum bereits mehrfach durchgekaut und mit entsprechenden Suchparametern solltest du diese Beiträge finden können.

Hmm, okay. Ich hatte bisher nach ser2net gesucht und wurde mit Ergebnissen überflutet, weil "ser2net" offenbar auch in RaspberryMatic enthalten ist aber nix mit meinem Anliegen zu tun hat.

Aber wenn du mir das so erklärst, dann glaube ich dir das natürlich, dass das nicht geht. Du musst es ja wissen

Und das liegt einfach daran, das das Homematic Funkprotokoll gewisse Anforderungen an Latenzzeiten bei der Kommunikation hat und da kommt es auf jede Millisekunde an.

Eine Frage dazu habe ich aber trotzdem (nur fürs Verständnis): Auf die Idee bin ich eigentlich erst über das FHEM-Wiki gekommen. Dort ist genau dieser Weg mit ser2net beschrieben, allerdings verwenden die ja keine CCU-Software sondern ihr eigenes HMUARTLGW. Das HMUARTLGW von FHEM ist wohl einfach nicht so empfindlich bezüglich Latenzen, wie die volle CCU-Software, oder?

BTW: Es geht mir gar nicht ums Geld sparen für die Hardware, sondern eher darum, ein Gerät weniger betreiben zu müssen. Das spart dann dauerhaft PoE-Budget (Strom) und einen Switch-Port (nochmal Strom und obendrauf eine knappe Ressource) und hätte zudem die Umwelt etwas geschont, weil ich den vorhandenen Raspi hätte upcyceln können.

[jp112sdl]

Das HMUARTLGW von FHEM

spricht nur BidCos, kein HmIP und geht nur mit FW 1.4.1 - die letzte Version ohne DualCoPro Unterstützung.

Wenn dir dieser "legacy" Support reicht, dann kannst du dir auch was mit ser2net bauen.

[f0obar]

Das HMUARTLGW von FHEM

spricht nur BidCos, kein HmIP und geht nur mit FW 1.4.1 - die letzte Version ohne DualCoPro Unterstützung.

Wenn dir dieser "legacy" Support reicht, dann kannst du dir auch was mit ser2net bauen.

OK, dass damit nur BidCos geht, war mir bekannt. Aber das mit FW 1.4.1 und der fehlenden DualCoPro-Unterstützung war mir neu (auf der FHEM-Seite steht, dass sie dringend neuere Firmware empfehlen?). Aber gut, sei es drum. Ich bleibe da vorerst bei meiner PoE-gespeisten CCU2.

[stan23]

Doch, genau das steht dort
https://wiki.fhem.de/wiki/HM-MOD-RPI-PC ... s_mit_FHEM