Hallo FHEM Team,
hoffe auch für euch gab es zu Weihnachten schöne Überraschungen. Bei mir wurde neue HW genehmigt, wobei damit die Probleme anfangen: ein neuer (alter) Server der ins Rack im Haus kommt. Proxmox läuft schon, Zoneminder, OPNsense und Astersik wartet noch auf das Feintuning (Umzug von kleinem PC auf jeweils eigene VM), für FHEM steht Debian in einer VM (einen Container wollte ich aus div. Gründen nicht) bereit, Ziel ist dort Homematic (Bidcos, nicht IP) mit AES zu betreiben (neben MQTT, IP...). Hintergrund: der Server hängt an einer (kleinen) USV und hat auch mehr CPU Power...
Bis jetzt nutze ich an zentraler Stelle im Haus einen RPi v3 mit HM-MOD-RPI-PCB und kabelgebundenem ETH als I/O-Interface, wobei das Homeatic
a) würde nur per USB Wandler am den Server gehen (wollte ich wg. potentieller Störquelle vermeiden)
b) deckt Rx/Tx technisch nicht das ganze Haus ab (schon mit dem RPi + extra Antenne am Standort des Serverracks ausprobiert)
Wenn FHEM also auf den Server wandern soll, dann muss ich irgendwie im Haus noch die Homematic I/O Interfaces ansprechen können. Da mein Vorhaben für mich Neuland ist, wollte ich nun fragen wie man das am besten auflöst, also Verteilung des Betriebs auf mehrere Orte
- FHEM vom RPi runterschmeißen, ser2net einrichten und dadurch das HW-Interface HM-MOD-RPI-PCB zum Server im Rack übertragen?
- FHEM2FHEM nutzen?
FHEM2FHEM scheidet aber aus meiner Sicht aus, da das ja unidirektional ist und ich somit nur Befehle empfangen (oder senden) könnte (vgl. Wiki).
Wie handhabt man es, wenn FHEM irgendwo läuft, aber von dort nicht alle Geräte erreicht werden können? VCCU liefert mir ja kein I/O-Interface im Haus, bzw. Verbindung von zwei FHEM Instanzen (hier: RPI und Server), oder? Auch wenn immer wieder geschrieben steht, dass die VCCU entscheidet über welches I/O Interface die Daten rausgehen, muss ja immer noch irgendwie der Anschluss erfolgen. Im Grunde bleibt mir ja nur ein RPi (oder Wemos, oder....) an gut positionierten Stellen mit ser2net, oder?
Wenn es ser2net wird: gibt es etwas zu beachten? Würde an der Stelle dann wahrscheinlich zwei Sender (via VCCU und ser2net) nehmen, da die zentrale Position für die Außenbereiche grenzwertig ist und ich häufig Wiederholungen/Neuübertragungen habe.
Gruß, Robert
Ich habe
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Variante_mit_socat
Funktioniert super.
Hallo Robert,
alle Varianten im Wiki funktionieren, ich nehme die ser2net Variante :) so wie im Wiki beschrieben.
FHEM2FHEM funktioniert dafür aus meiner Sicht nicht!
ZitatVCCU liefert mir ja kein I/O-Interface im Haus, bzw. Verbindung von zwei FHEM Instanzen
Ich versteh die Frage nicht ganz, aber: Die VCCU bündelt dir IOs und keine FHEM Instanzen. Sie macht die Arbeit mit mehreren IOs für Homematic für Dich transparent.
Gruß Otto
Hallo,
wow, danke für die schnellen Antworten. Dann lag ich ja völlig richtig bzgl. FHEM2FHEM ;-)
@CoolTux: bitte nicht exakt so, dass
User=root
widerspricht allen Sicherheitsprinzipien. Dann lieber den Nutzer fhem berechtigen.
@Otto: danke für die Bestätigung. Meine Verwirrung kam daher, dass in einigen Beiträgen stand, dass eine VCCU immer automatisch das beste I/O Interface auswählt. Aber das kann ja nur funktionieren, wenn es auch min. zwei HW Interfaces ansprechen kann. Andernfalls ist das ja recht witzlos... Von daher würde ich auf dem Server im Rack dann auf eine VCCU "upgraden" und dieser zwei (per socat oder ser2net) HM-MOD-RPI-PCB zur Verfügung stellen.
Habe gerade noch etwas mehr gelesen: was mich allgemein wundert ist, warum man nicht auf beiden Seiten socat vorschlägt, das macht die Sache ja komplett transparent und bietet gleichzeitig noch Verschlüsselung an, also so etwas:
socat openssl-listen:<freier_port>,keepalive,reuseaddr,cert=$HOME/server.pem,cafile=$HOME/client.crt /dev/<xxx>,raw,echo=0,b115200
und dann ncoh ein
socat PTY,link=/dev/<yyy>,user=fhem,group=dialout,mode=660,nonblock,raw,ignoreof, waitslave openssl-connect:<IP_vom_remote_PI>:<freier_port>,cert/$HOME/client.pem,cafile=$HOME/server.crt
Dann kann man in fhem das I/O Interface komplett transparent ansprechen (so die Theorie...) als sei es lokal dran und hat das gekapselt (=fhem muss ich damit nicht rumschlagen).
Bin ab morgen bis Neujahr auf Weihnachtstour, danach habe ich noch drei Tage zum probieren.
Danke, Gruß und schon mal vorab einen guten Rutsch.
Robert
Hallo Robert,
das mit der VCCU funktioniert auch mit einem IO - wenn nur einer da, dann ist der automatisch der Beste ;)
Die VCCU macht noch Anderes, die ist also auch mit einem IO nicht witzlos.
Das mit socat kannst Du gerne so machen wenn Du es beherrschst. Klingt kompliziert. ;) Was im Wiki steht ist getestet und so nachvollziehbar. Das Modul HMUARTLGW beherrscht ja den Zugriff über Netzwerk, insofern erscheint mir ein Vorbei an dieser Funktion "aufwendig". Jede Komponente mehr macht es nur komplexer.
Gruß Otto
und am besten keine wlan anbindung.
@Otto: werde es einfach mal probieren, wenn es klappt: perfekt. Wenn nein, dann halt nicht ;-) Warum ich das machen möchte: im Endeffekt hängen da halt auch Türen, Heizung u.ä. dran, d.h. die möchte wenn möglich nichts unverschlüsselt übers Netzwerk jagen (auch wenn es Kupfer und kein WLAN ist). Das war damals auch mit einer der Gründe für Homematic: AES Signierung erlaubt zwar das Lesen, aber andere können wg. der Signaturprüfung nicht (so einfach) meine Aktoren schalten. Und hier gibt es genügend Spaßvögel denen ich so "Spielkram" zutraue. Ich schaue ja auch mal ab und an was so an Funk in der Nachbarschaft rumschwirrt...
Und was die Sicherheit angeht: du musst nur ein paar Zertifikat generieren und die austauschen. Wie gesagt: mal sehen ob ich es behersche und zum Laufen bekomme.
@Frank: ok, also kein wemos, Tasmota o.ä. Spielchen. Kupfer liegt eh (auch an den neuen Standorten)
Gruß, Robert
Hallo zusammen,
kurze Rückmeldung zu meinem Vorhaben. Hat etwas länger gedauert, da der RPi (warum auch immer) nicht mehr ohne HDMI booten wollte. Dachte schon das ich ihn gehimmelt habe, weil er nicht mehr erreichbar war. Aber das ist eine andere Geschichte...
Für die Nachwelt:
- RPi an den das HM-MOD-RPI-PCB angeschlossen ist, im folgenden das "Funk_Slave" bezeichnet, aktuelles Debian Buster mit der IP 192.168.123.123
- Server auf dem FHEM läuft, im folgenden als "FHEM_Master" bezeichnet, ebefalls aktuelles Debian
Auf dem "Funk_Slave" fast wie im Wiki vorgehen, ich hatte "nur" keepalive mit aufgenommen und einen anderen Port gewählt.
Zuerst auf dem "Funk_Slave" die serielle Schnittstelle frei machen wie im Wiki beschrieben https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule (https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule)
Dann socat installieren und ein minimal StartScript ohne Verschlüsselung zum Testen erzeugen:
sudo apt install socat
sudo nano /etc/systemd/system/hmlangw.service
Inhalt des Startscripts ist minimal und wie gesagt am Wiki orientiert:
[Install]
WantedBy=multi-user.target
Type=forking
[Service]
ExecStart=/usr/bin/socat TCP4-LISTEN:2345,fork,keepalive,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
User=root
Restart=always
RestartSec=10
Und zum Start hin erlauben/hinzufügen und gleich mal den Status abfragen
sudo systemctl enable hmlangw
sudo systemctl status hmlangw
Status sollte hier natürlich noch inactiv sein. Da ich vorher einen ganzen Haufen Kram installiert hatte, einmal neu starten und erneut den Status abfragen
sudo systemctl reboot
sudo systemctl status hmlangw
Nun sollte der Status activ und running sein, d.h. ab jetzt geht es auf dem "FHEM_Master" weiter. Auch dort socat installieren und ein minimal StartScript ohne Verschlüsselung zum Testen erzeugen:
sudo apt install socat
sudo nano /etc/systemd/system/hmlangw.service
Inhalt der Startdatei ist hier anders, da hier Socat eine virtuelle (serielle) Schnittstelle erzeugen soll:
[Install]
WantedBy=multi-user.target
Type=forking
[Service]
ExecStart=/usr/bin/socat PTY,link=/dev/ttyVirtHMLANGW,user=fhem,group=dialout,mode=660,nonblock,raw,ignoreof,waitslave tcp:192.168.123.123:2345
User=root
Restart=always
RestartSec=10
Und zum Start hin erlauben/hinzufügen und mal den Status abfragen
sudo systemctl enable hmlangw
sudo systemctl status hmlangw
Status sollte hier natürlich auch noch inactiv sein. Da ich auch hier vorher einen ganzen Haufen Kram installiert hatte, einmal neu starten und erneut den Status abfragen:
sudo systemctl reboot
sudo systemctl status hmlangw
Nun sollte der Status activ und running sein, jetzt einmal im FHEM auf dem "FHEM_Master" einloggen und dort das device definieren:
define Virtual_HmUART HMUARTLGW /dev/ttyVirtHMLANGW
Das war es auch schon. Da mein HM-MOD-RPI-PCB recht alt war, konnte es auch gleich über den "FFHEM_Master" geupdated werden (vgl. Wiki). Log schaut gut aus:
2020.01.03 14:08:12 3: Opening Virtual_HmUART device /dev/ttyVirtHMLANGW
2020.01.03 14:08:12 3: Setting Virtual_HmUART serial parameters to 115200,8,N,1
2020.01.03 14:08:12 3: Virtual_HmUART device opened
2020.01.03 14:11:06 3: Virtual_HmUART device closed
2020.01.03 14:11:06 3: Setting Virtual_HmUART serial parameters to 115200,8,N,1
2020.01.03 14:11:06 1: /dev/ttyVirtHMLANGW reappeared (Virtual_HmUART)
2020.01.03 14:11:07 1: HMUARTLGW Virtual_HmUART starting firmware upgrade
2020.01.03 14:11:32 1: HMUARTLGW Virtual_HmUART firmware update successfull
Nun nur noch open-ssl installieren, die Zertifikate erzeugen und die beiden socat Aufrufe um die Angaben der Zertifikate wie im vorherigen Post angegeben ergänzen.
Vorteile dieser "komplizierten" Lösung aus meiner Sicht:
- das Modul ist für das ganze System (FHEM_Master) komplett transparent angeschlossen, d.h. egal was und mit welchen Programmen, Skripten o.ä. man damit (in Zukunft) machen möchte, es verhält sich so als sei es lokal angeschlossen
- die Kommunikation läuft verschlüsselt ab
Gruß und viel Spaß. Muss mich jetzt am WE mal mit VCCU auseinandersetzen, zwei Module zum FHEM Server routen und vor allem dann FHEM auf den Server umziehen.
Robert