Umstieg CCU2 auf Debian X86 OCCU

[wuffzack]

wenn du das HM-MOD-RPI Modul meinst - die Ansteuerung des seriellen Moduls ist mit der CCU2 identisch, und es läuft wunderbar mit ein paar Kniffen mit LXCCU (mit mknod die serielle Schnittstelle bereitstellen, GPIO 18 als reset file in rfd.ini eintragen, fertig).

Es wäre schön wenn du die entsprechenden "Kniffe" bzw. Kommandos um das HM-MOD-RPI-PCB unter LXCCU zum laufen zu bekommen hier posten könntest damit andere davon auch profitieren können und ggf. die LXCCU Macher das dann auch integrieren können.

Das ist unter "Umstieg CCU2 auf Debian X86 OCCU" ein bisserl off-topic, aber ganz kurz:
Ich kann es gerade nicht am "lebenden" raspi kontrollieren, was ich hier schreibe, da ich das HM-MOD-RPI-PCB im Moment an einem USB-seriell Wandler (elv UM2102, der macht gleich 3.3V für das Modul) unter lxccu betreibe. Macht die Platzierung der Antenne einfacher. Aber das ist im Prinzip ja egal, ich hatte zuerst intern probiert, und es funktioniert natürlich genauso.

Ich hab es mal in script form geschrieben, dann kann man es eventuell in rc.local tun. lxccu sollte aber erst anschliessend gestartet werden.
EDIT: einige Befehle setzen vermutlich root Rechte voraus, also entsprechend 'sudo' davor, wenn man nicht als root eingelogged ist.

1.) Reset Leitung des Moduls vorbereiten (optional, man kann natürlich als reset file in rfd.ini auch /dev/null eintragen, dann darf GPIO18 nicht auf low gezogen werden):

Code: Alles auswählen

if [ ! -d /sys/class/gpio/gpio18 ]
    then
    echo "Preparing GPIO for HM-MOD-UART..."
    echo 18 > /sys/class/gpio/export
    echo out > /sys/class/gpio/gpio18/direction
    echo "Preparing GPIO for HM-MOD-UART done!"
fi
# hold reset until rfd starts
echo 0 > /sys/class/gpio/gpio18/value

2.) Die serielle Schnittstelle dem container zur Verfügung stellen (muss man nur einmal machen, nachdem lxccu installiert wurde).
Wird auf dem host ausgeführt:

Code: Alles auswählen

if [ ! -e /var/lib/lxc/lxccu/root/dev/ttyAPP0 ]
    then
    echo "Creating lxccu /dev/ttyAPPO"
    mknod -m 666 /var/lib/lxc/lxccu/root/dev/ttyAPP0 c 204 64
fi

In die rfd.ini kommt dann das reset file in den original "CCU2" Eintrag. "Serial Number" ist optional, ich finde es praktisch, denn man kann die Nummer der original CCU2 eintragen, wenn man "umzieht".
Ohne reset file geht es auch, dann kommt in "ResetFile" /dev/null

Code: Alles auswählen

[Interface 0]
Type = CCU2
Serial Number = ABC123456
Description = CCU2-Coprocessor
Name = CCU2 Internal Interface
ComPortFile = /dev/ttyAPP0
AccessFile = /dev/null
ResetFile = /sys/class/gpio/gpio18/value

[wuffzack]

P.S. (Nörgel-Modus):
Im Moment ist lxccu für mich - mit Abstand - die beste Lösung.

OCCU ist einfach eine Lachnummer, ich weiss wirklich nicht, was daran "open" sein soll. rfd zum selberkompilieren? Fehlanzeige. D.h. das Protokoll zum seriellen Sendemodul wird vermutlich für immer ein Geheimnis bleiben, ausser Jemand erbarmt sich und reverse-engineered es, wie mit HM-CFG-USB/LAN geschehen.
Ich hätte mich sofort freiwillig an einen nativen Windows port gesetzt, da ich Eventghost für alle Steueraufgaben verwende, und deshalb sowieso eine Windows Kiste laufen muss. Aber nö...

Berry-matic ist mir zu abgeschottet, da irgendwas drauf zu installieren (Java, Python, Gcc, ...) ist ja ein Riesenschmerz. Da kann ich auch gleich bei der CCU2 bleiben.
Die "guten Teile" aus dem Berry-matic image rausholen und unter raspbian laufen lassen, ja das geht so einigermassen, erfordert aber reichlich Anpassungen (Pfade, und der Teufen steckt im Detail), und bei jedem Update wieder rumfummeln? Ach nö...

Solange es keine OCCU "aktuell" (nicht 6 Monate alt) als Debian Paket (oder in ähnlicher Form) gibt, ist lxccu wirklich Klasse. Was mir bei der CCU2 fehlt, lasse ich einfach auf dem Host laufen.

[jmaus]

Es wäre schön wenn du die entsprechenden "Kniffe" bzw. Kommandos um das HM-MOD-RPI-PCB unter LXCCU zum laufen zu bekommen hier posten könntest damit andere davon auch profitieren können und ggf. die LXCCU Macher das dann auch integrieren können.

Das ist unter "Umstieg CCU2 auf Debian X86 OCCU" ein bisserl off-topic, aber ganz kurz:
Ich kann es gerade nicht am "lebenden" raspi kontrollieren, was ich hier schreibe, da ich das HM-MOD-RPI-PCB im Moment an einem USB-seriell Wandler (elv UM2102, der macht gleich 3.3V für das Modul) unter lxccu betreibe. Macht die Platzierung der Antenne einfacher. Aber das ist im Prinzip ja egal, ich hatte zuerst intern probiert, und es funktioniert natürlich genauso.

Du hast es sicher gesehen, aber ich hab einfach bei mir eine bessere, externe Antenne an das Funkmodul gelötet: http://homematic-forum.de/forum/viewtop ... 27&t=27287 Das hat den erhofften Erfolg gebracht und ich hab jetzt keinerlei Servicemeldungen mehr.

Ich hab es mal in script form geschrieben, dann kann man es eventuell in rc.local tun. lxccu sollte aber erst anschliessend gestartet werden.
EDIT: einige Befehle setzen vermutlich root Rechte voraus, also entsprechend 'sudo' davor, wenn man nicht als root eingelogged ist.
[...]

Danke für die Anleitung. Ich werde das probieren sobald ich meinen zweiten RaspberryPi2 hier habe um darauf dann LXCCU zu betreiben. Ich bin schon ganz gespannt welche Lösung mir da dauerhaft mehr zusagt.

[jmaus]

P.S. (Nörgel-Modus):
Im Moment ist lxccu für mich - mit Abstand - die beste Lösung.

Das kann ich vom technischen Standpunkt aus sicherlich verstehen (vollwertiges Linux usw.). Allerdings muss ich auch sagen das gute Dokumentation und Anleitungen bzgl. LXCCU schwer rahr und leider schwer zu finden sind. Auch muss man leider sagen, das LXCCU auch nicht die Offenheit in der Person ist. Schaut man sich das dazu passende Github repository an (https://github.com/bullshit/lxccu) so sieht man das dort auch das letzte mal im Mai ein push von Änderungen erfolgt ist. Hier würde ich mir mehr aussenwirksame Verändungen wünschen und besser Dokumentation/Gesamtpakete damit sich LXCCU breiter verbreiten kann als es zur Zeit der Fall ist.

OCCU ist einfach eine Lachnummer, ich weiss wirklich nicht, was daran "open" sein soll. rfd zum selberkompilieren? Fehlanzeige. D.h. das Protokoll zum seriellen Sendemodul wird vermutlich für immer ein Geheimnis bleiben, ausser Jemand erbarmt sich und reverse-engineered es, wie mit HM-CFG-USB/LAN geschehen.

Eine "Lachnummer" würde ich es jetzt vielleicht nicht nennen, aber es gibt in der Tat im Bezug auf OpenSource noch einiges an Nachholbedarf. Und was das Protokoll zum seriellen Sendemodul angeht, hast du diesbzgl. schon bei eQ3 angefragt? Ich könnte mir vorstellen das die dort vllt. gar nicht so abgeneigt sind dieses offen zu legen.

Was allerdings 'rfd' und das eigentlich Funkprotokoll angeht so kann ich aber auch gut verstehen das ELV/eq3 das closed halten will weil dort eben das know-how und konkurrenzfähiges IP drinsteckt. Mich würde vielmehr eine Offenlegung von ReGaHSS interessieren damit man mal strukturiert die Fehler beseitigen kann die es leider noch vielerorts in der Software gibt. Auch HMServer wäre toll das von Java zu befreien und einen reinen C-Port zu machen. Allerdings ist es aber so das ELV/eq3 daran nicht alleine die Rechte besitzt und wohl drittanbieter-software darin einsetzt die sie anscheinend nicht offenlegen können. Leider, muss man sagen!

Ich hätte mich sofort freiwillig an einen nativen Windows port gesetzt, da ich Eventghost für alle Steueraufgaben verwende, und deshalb sowieso eine Windows Kiste laufen muss. Aber nö...

Nun, da spricht du leider mit dem Falschen darüber. Windows ist und war für mich noch nie eine gute Alternative und ein Windows Port wäre das letzte worüber ich nachdenken würde

Berry-matic ist mir zu abgeschottet, da irgendwas drauf zu installieren (Java, Python, Gcc, ...) ist ja ein Riesenschmerz. Da kann ich auch gleich bei der CCU2 bleiben.

So ein Riesenschmerz ist das gar nicht wenn man das einmal umgesetzt hat. Ein guter Vorteil von RaspberryMatic ist das es auf "buildroot" aufsetzt welches zwar mit einer limitierten Linux-Umgebung daherkommt (wie jedes gute NAS system z.B.), allerdings gibt es zu "buildroot" genug Dokumentation und man kann sich auch eine sehr gute Cross-Compiler Umgebung bauen um dann dafür jedes Linux-Programm auch dafür zu kompilieren. Es wäre also z.B. ohne großen aufwand möglich Addons für RaspberryMatic anzubieten das es zu einem Vollwertigeren Linux "aufrüstet" und alle notwendige Dinge dann mitbringt (apache, python, etc.) um Sachen wie ccu.io oder iobroker direkt darauf betreiben zu können. Wenn du es nicht gesehen hast, ich habe nämlich eine solche buildroot cross-compiler Umgebung passend für CCU2 und RaspberryMatic auf Github veröffentlicht: https://github.com/jens-maus/hm-buildroot
Damit kannst du dann unter einem x86 Linux problemlos und ohne großen aufwand binaries für die ARM hard float Umgebung von RaspberryMatic kompilieren. Und in der Tat denke ich gerade darüber nach für RaspberryMatic ein Addon zu bauen mit dem man dann dieses zu einem vollwertigerem Linux aufrüsten kann.

Die "guten Teile" aus dem Berry-matic image rausholen und unter raspbian laufen lassen, ja das geht so einigermassen, erfordert aber reichlich Anpassungen (Pfade, und der Teufen steckt im Detail), und bei jedem Update wieder rumfummeln? Ach nö...

Auch das wäre IMHO mit nicht so sehr viel aufwand zumindest teilautomatisch möglich. Muss man halt nur gute Buildscripte bauen und tools die aus einer RaspberryMatic image dann alle notwendigen dinge rausholt und in Debian Pakete für eine standard raspbian installation rausholt. Anscheinend arbeitet aber ELV/eq3 selber daran gerade und es bleibt abzuwarten was und wie das dann kommt.

Solange es keine OCCU "aktuell" (nicht 6 Monate alt) als Debian Paket (oder in ähnlicher Form) gibt, ist lxccu wirklich Klasse. Was mir bei der CCU2 fehlt, lasse ich einfach auf dem Host laufen.

Ich geb dir vollkommen recht. Alleine die Tatsache das eq3 nicht wirklich in dem Github repository tagesaktuell entwickelt lässt einen stark an der OpenSource Philosophie von eq3 zweifeln. Ich würde auch sagen das mehr community machen entstehen würden wenn eq3 mehr in dem Github repository arbeiten würde anstatt das als release repository zu verstehen wo man 1x im Jahr etwas aktualisiert. Hier bleibt nur zu hoffen das eq3 hier nachliefert und sein OpenSource Engagement verbessert und sich vielleicht auch darauf konzentriert was sie am besten können: HomeMatic Hardware zu entwickeln und eine reine Referenzplatform für die Ansteuerung dieser Komponenten zu entwickeln (CCU & Co). Alles weitere sollten sie der OpenSource Community überlassen denn die Community hat in der Vergangenheit schon mehrfach bewiesen das dort Leute mit sehr viel und gutem technischen KnowHow arbeiten (siehe z.B. CUxD, ccu.io, iobroker) die die HomeMatic Platform wesentlich voranbringen könnte.

[grissli1]

Hi,
also Anleitungen usw zu LXCCU sind doch nicht schwer zu finden. Eine super einfache Anleitung ist doch auf lxccu.com zu finden. Mit allem drum und dran. Wenn man sich komplett daran hält und des lesens mächtig ist, schafft das jeder Linux Noob (so wie ich auch).

Warum auf github die letzten Änderungen im Mai sind kann ich nicht nachvollziehen, weil diese Woche schon die aktuelle FW der CCU für die LXCCCU bereit bestellt wurde.

Ich werde aber auf einem zweiten Raspi mal auch RaspberryMatic probieren. OCCU ist ja noch ein weilchen nicht so weit wie mir scheint.

Super wäre es, wenn eq3 komplett auf die CCU verzichten würde und ein Image für Raspi macht bzw ein Paket aus Raspi, Funkmodul und eigenem Gehäuse anbieten würde. Das wäre mal ein Fortschritt.

Viele Grüße
Chris

Unterwegs @ G-Pad

[Homoran]

Im Prinzip besteht die Installation von lxccu fas nur aus einem Befehl.

Installation der LXCCU Stable
Jetzt kommen wir dank bullshit zum leichtesten Teil der Anleitung, entweder seht auf dieser Seite nach. http://www.lxccu.com
Oder führt gleich folgenden Befehl als root / mit root Rechten auf eurem Einplatinencomputer zur installation der Stabilen version aus:
wget -nv -O- http://www.lxccu.com/setup.sh | bash -

Ich habe gestern sogar direkt ganz mutig die meueste testing auf mein Produktivsystem gespielt und damit die 2.15.5 drauf - ohne Probleme!

Ich werde aber auf einem zweiten Raspi mal auch RaspberryMatic probieren. OCCU ist ja noch ein weilchen nicht so weit wie mir scheint.

Habe ich auch gemacht - sieht nett aus, fehlt aber leider noch was.
Ich warte da, bis anli & Co. die Debian-Variante fertig haben, aber für mich ist die lxccu das Maß aller Dinge

und ein Image für Raspi macht bzw ein Paket aus Raspi, Funkmodul und eigenem Gehäuse anbieten würde. Das wäre mal ein Fortschritt.

ist im letzten Prospekt so in etwa drin gewesen, Funkmodul passt in Plexiglasgehäuse für Raspi2.

Allerdings ist das EQ-3 image kein vollständiges Linux.

Daher ist dieser Thread auch eigentlich nicht für das EQ-3 image gedacht.


Gruß
Rainer

[PaulG4H]

Hallo wuffzack,

Das ist unter "Umstieg CCU2 auf Debian X86 OCCU" ein bisserl off-topic, aber ganz kurz:
Ich kann es gerade nicht am "lebenden" raspi kontrollieren, was ich hier schreibe, da ich das HM-MOD-RPI-PCB im Moment an einem USB-seriell Wandler (elv UM2102, der macht gleich 3.3V für das Modul) unter lxccu betreibe. Macht die Platzierung der Antenne einfacher. Aber das ist im Prinzip ja egal, ich hatte zuerst intern probiert, und es funktioniert natürlich genauso.

Ich hab es mal in script form geschrieben, dann kann man es eventuell in rc.local tun. lxccu sollte aber erst anschliessend gestartet werden.
EDIT: einige Befehle setzen vermutlich root Rechte voraus, also entsprechend 'sudo' davor, wenn man nicht als root eingelogged ist.

1.) Reset Leitung des Moduls vorbereiten (optional, man kann natürlich als reset file in rfd.ini auch /dev/null eintragen, dann darf GPIO18 nicht auf low gezogen werden):

Code: Alles auswählen

if [ ! -d /sys/class/gpio/gpio18 ]
    then
    echo "Preparing GPIO for HM-MOD-UART..."
    echo 18 > /sys/class/gpio/export
    echo out > /sys/class/gpio/gpio18/direction
    echo "Preparing GPIO for HM-MOD-UART done!"
fi
# hold reset until rfd starts
echo 0 > /sys/class/gpio/gpio18/value

2.) Die serielle Schnittstelle dem container zur Verfügung stellen (muss man nur einmal machen, nachdem lxccu installiert wurde).
Wird auf dem host ausgeführt:

Code: Alles auswählen

if [ ! -e /var/lib/lxc/lxccu/root/dev/ttyAPP0 ]
    then
    echo "Creating lxccu /dev/ttyAPPO"
    mknod -m 666 /var/lib/lxc/lxccu/root/dev/ttyAPP0 c 204 64
fi

In die rfd.ini kommt dann das reset file in den original "CCU2" Eintrag. "Serial Number" ist optional, ich finde es praktisch, denn man kann die Nummer der original CCU2 eintragen, wenn man "umzieht".
Ohne reset file geht es auch, dann kommt in "ResetFile" /dev/null

Code: Alles auswählen

[Interface 0]
Type = CCU2
Serial Number = ABC123456
Description = CCU2-Coprocessor
Name = CCU2 Internal Interface
ComPortFile = /dev/ttyAPP0
AccessFile = /dev/null
ResetFile = /sys/class/gpio/gpio18/value

Vielen Dank für die Infos!

Ich werde das nächste Woche mal testen und wenn es Funktioniert auch dieses "Feature" in die lxccu integrieren oder zumindest als Optionales Script / Paket / Anleitung bereitstellen.

So nun zum OT Teil: Ich habe mich inzwischen als Zentralen Logik für IP Symcon 4 entschieden weil dies ist nun native unter Linux (Raspbian) lauffähig ist (direkt auf meinem LXCCU Raspi) und es gibt dafür für alle aktuell und in Zukunft gewünschten Hardware Kompoenenten bereits Scripte / Module usw. Klar kostet es was aber dafür bekomme ich auch support und das ist es mir Wert. Auch bin ich da bei jmaus ich möchte nie wieder ein Windows System 24/7 zuhause laufen haben und es ist inzwischen schon fast Fahrlässig Windows nicht Virtualisiert zu betreiben...

Paul

[wuffzack]

P.S. (Nörgel-Modus):
Im Moment ist lxccu für mich - mit Abstand - die beste Lösung.

Das kann ich vom technischen Standpunkt aus sicherlich verstehen (vollwertiges Linux usw.). Allerdings muss ich auch sagen das gute Dokumentation und Anleitungen bzgl. LXCCU schwer rahr und leider schwer zu finden sind. Auch muss man leider sagen, das LXCCU auch nicht die Offenheit in der Person ist. Schaut man sich das dazu passende Github repository an (https://github.com/bullshit/lxccu) so sieht man das dort auch das letzte mal im Mai ein push von Änderungen erfolgt ist. Hier würde ich mir mehr aussenwirksame Verändungen wünschen und besser Dokumentation/Gesamtpakete damit sich LXCCU breiter verbreiten kann als es zur Zeit der Fall ist.

Naja, ich bin zwar nicht ganz unerfahren was Computerkram angeht, aber in Sachen Linux ganz bestimmt nicht der Hellste. Wenn ich das mit der vorhandenen Doku geschafft habe, kann die sooo schlecht nicht sein.

OCCU ist einfach eine Lachnummer, ich weiss wirklich nicht, was daran "open" sein soll. rfd zum selberkompilieren? Fehlanzeige. D.h. das Protokoll zum seriellen Sendemodul wird vermutlich für immer ein Geheimnis bleiben, ausser Jemand erbarmt sich und reverse-engineered es, wie mit HM-CFG-USB/LAN geschehen.

Eine "Lachnummer" würde ich es jetzt vielleicht nicht nennen, aber es gibt in der Tat im Bezug auf OpenSource noch einiges an Nachholbedarf.

Nachholbedarf ist gut. Von den elv/eq3 binaries ist gar nix als Open Source verfügbar.

Und was das Protokoll zum seriellen Sendemodul angeht, hast du diesbzgl. schon bei eQ3 angefragt? Ich könnte mir vorstellen das die dort vllt. gar nicht so abgeneigt sind dieses offen zu legen.

Nein, denn ich bin bisher bei allen Kommunikationsversuchen (bugreports bzgl. HM-CFG-USB und rfd) immer an der "Support Mauer" von eq3 abgeprallt. Das ging in etwa so: "Vielen Dank für Ihre Nachricht, bitte wenden Sie sich an Ihren Händler, schönen Tag noch, tschüss.". Da verliere ich ein bisserl die Lust.

Was allerdings 'rfd' und das eigentlich Funkprotokoll angeht so kann ich aber auch gut verstehen das ELV/eq3 das closed halten will weil dort eben das know-how und konkurrenzfähiges IP drinsteckt.

Naja, es gibt ja schon rfd "ports" von Anderen (hab den Namen vergessen), und FHEM macht es ja wohl auch direkt. Also so "geheim" ist da nix mehr. Soweit ich weiss ist auch der default AES Schlüssel nicht im code, sondern in den Aktoren/CFG-Adaptern/Funkmodul/Coprozessor.
Mit dem rfd source könnte man z.B. das serielle Funkmodul zu "Konfig-Adaptern" machen. Oder das schreckliche "roaming" fixen, was nicht merkt, wenn ein Konfig Adapter vom Netz fällt. Ich hab das roaming in rfd immer aus, und mach es jetzt selber - in Python auf dem Host.
Und das würde doch elv/eq3 nur gut tun. Mehr Möglichkeiten zur Steuerung können doch nur gut sein für die Verkäufe von Aktoren/LAN Adaptern/was weiss ich.
Wenn ich die Wahl habe, nehme ich gern ein "offenes" System. Statt eines Konkurrenzproduktes.
Das war an FS20 so toll. Das war zwar nicht offen, aber komplett reverse-engineered. Da habe ich ganz wilde Dinge gebaut, z.B. Steuerungen für Klimageräte mit eigenen Aktoren Funk->IR, da es keine fertige Lösung gab, die funktioniert hat. Ist auch immer noch in Betrieb, da mit Homematic sowas nicht geht, und wohl auch nie gehen wird.

Mich würde vielmehr eine Offenlegung von ReGaHSS interessieren damit man mal strukturiert die Fehler beseitigen kann die es leider noch vielerorts in der Software gibt. Auch HMServer wäre toll das von Java zu befreien und einen reinen C-Port zu machen. Allerdings ist es aber so das ELV/eq3 daran nicht alleine die Rechte besitzt und wohl drittanbieter-software darin einsetzt die sie anscheinend nicht offenlegen können. Leider, muss man sagen!

Dann können wir uns ja die Arbeit teilen. ReGaHSS interessiert mich gar nicht (Windows, Eventghost, historische Gründe...), und das HM script finde ich auch eher ... seltsam, um es mal höflich zu sagen. Der HMServer ist nett für die Heizkörper Steuerung, aber den würde ich eigentlich gerne loswerden.

Ich hätte mich sofort freiwillig an einen nativen Windows port gesetzt, da ich Eventghost für alle Steueraufgaben verwende, und deshalb sowieso eine Windows Kiste laufen muss. Aber nö...

Nun, da spricht du leider mit dem Falschen darüber. Windows ist und war für mich noch nie eine gute Alternative und ein Windows Port wäre das letzte worüber ich nachdenken würde

Das hat "historische Gründe". Das das nicht "normal" ist, ist mir klar.

[wuffzack]

Du hast es sicher gesehen, aber ich hab einfach bei mir eine bessere, externe Antenne an das Funkmodul gelötet: http://homematic-forum.de/forum/viewtop ... 27&t=27287 Das hat den erhofften Erfolg gebracht und ich hab jetzt keinerlei Servicemeldungen mehr.

Klar, die externe Antenne ist bestimmt prima. Nur ich hab mir gedacht (in Ermangelung der passenden Teile), dass man das Sendemodul zur Antenne machen kann. Und ich hab noch ein paar UM2102 in der Bastelschublade.
Also Sendemodul dran, USB Kabel durch Ferrit Kern damit der Raspi nicht reinstrahlt. An das Abschirmblech des Moduls hab ich die 4 Radials (ca. 7cm) gelötet, und den original Antennendraht durch ca. 8 cm langen steifen Draht ersetzt.
Das Ding sieht also fast genauso aus wie deine Antenne, nur mit USB Anschluss. Okay, es ist lange nicht so hübsch. Dass das Sendemodul selber stark stört, glaube ich nicht, die Elektronik sitzt ja komplett in der Blechkiste, und der Mikrocontroller ist bestimmt niedrig getaktet.
Ob es schlechter oder besser als deine Antenne ist, weiss ich nicht. Ich spare mir jedenfalls Verluste durch Antennenkabel / Lötstellen / Stecker. Es funktioniert jedenfalls ziemlich gut.

[wuffzack]

Vielen Dank für die Infos!

Bitte!

So nun zum OT Teil: Ich habe mich inzwischen als Zentralen Logik für IP Symcon 4 entschieden weil dies ist nun native unter Linux (Raspbian) lauffähig ist (direkt auf meinem LXCCU Raspi) und es gibt dafür für alle aktuell und in Zukunft gewünschten Hardware Kompoenenten bereits Scripte / Module usw. Klar kostet es was aber dafür bekomme ich auch support und das ist es mir Wert. Auch bin ich da bei jmaus ich möchte nie wieder ein Windows System 24/7 zuhause laufen haben und es ist inzwischen schon fast Fahrlässig Windows nicht Virtualisiert zu betreiben...

"Fahrlässig" ist vielleicht etwas böse, aber ich bin eigentlich auch ganz bei dir und jmaus. Bei mir sind es Altlasten, die unmöglich sind umzuziehen. Und solange die Windows Box wie ein embedded system vor sich hinläuft, braucht man da eigentlich auch nix virtualisieren.
Aber du hast Recht, ohne die "Altlasten" würde ich auch niemals auf die Idee kommen, einen Windows Server (WHS2011, um genau zu sein) zu verwenden.