Verständnisfrage HomematicIP

Begonnen von JudgeDredd, 11 Oktober 2022, 13:01:19

Vorheriges Thema - Nächstes Thema

fiedel

#15
Ist ja irre! Damit hat er nun überhaupt keinen Grund mehr das Protokoll, bzw. den Schlüssel geheim zu halten.
So erschafft er passiv einen riesigen Zombizoo voller HMIP Geräte mit unsicherem Protokoll.
In Einzelfällen und für Zweckentfremdung mag das nützlich und sinnvoll sein, aber um HMIP als HM zu nutzen...
Ich hoffe Herr Redeker will Geld verdienen UND die Welt ein bisschen besser machen!?  ;)
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

Beta-User

Zitat von: fiedel am 14 Oktober 2022, 11:31:24
Herr Redeker will [...] UND die Welt ein bisschen besser machen!?  ;)
...wenn er das wollte, (oder wenigstens an der Auslieferung von guter Qualität interessiert wäre!) müßte er nämlich seinen Entwicklern mehr Druck machen...

Interessanterweise beschäftigt sich der von Frank verlinkte Thread ja nicht originär mit HM-IP-Produkten, sondern? - Genau: Mit einer der "Oberzicken" aus der BidCoS-Welt! Versprechen des Services aus 2019: wir kümmern uns.
Feststellung 2022: Es ist nicht nur "nichts" in der BidCoS-Welt passiert, nein, _derselbe Bug_ ist auch in den HM-IP-Produkten zu finden. (Alter Wein in neuem Schlauch...)

Da kann man auch gleich "Wundertüten" in Fernost für einen Bruchteil besorgen (falls es was vergleichbares gibt).

Jedenfalls glaube ich weiter nicht daran, dass irgendjemand wegen ein paar maulender "Wissender" (die sich so oder so selbst zu helfen wissen) seine grundsätzliche Geschäftspolitik überdenkt :P .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

JudgeDredd

Hallo,
so, ich habe mir den Thread mal ein paar Tage unters Kopfkissen gelegt und drüber geschlafen  ;)
Zitat von: MadMax-FHEM am 12 Oktober 2022, 14:57:54
Genau.
Ein Gerät kann nur mit EINER Zentralen verbunden werden.
OK, dann habe ich das also richtig verstanden.
Ist aber sicherlich etwas schade, da ich einen Homematic Handsender zum öffnen meiner Garage verwende. Je nachdem von welcher Seite ich mich nun meinem Grundstück nähere, war es bisher so, das das nächste HM-UART-LGW den Empfang übernommen hat und die Reichweite immer gleich war.
Wenn ich den Handsender künftig mit einer CCUx-Zentrale fest pairen muss, dann würde das bedeuten, das die Reichweite in einer Richtung künftig schlechter ist ?
Zitat von: Beta-User am 12 Oktober 2022, 15:06:06
Na ja, zu WLAN allgemein kann man stehen wie man will, aber falls damit gemeint sein sollte, dass es ein Problem darstellen könnte, ein INTELIGENTES IO-Modul irgendwo abzusetzen: eher nicht (wenn das WLAN nicht allgemein wackelig ist). Denn der zeitkritische Teil läuft da AUF dem Gerät...
Ich behaupte mal, das mein Haus über mehrere WLAN-APs recht gut ausgeleuchtet ist.
Zitat von: Beta-User am 12 Oktober 2022, 15:06:06
Meine Schlussfolgerung aus dem Ganzen Hackel mit eQ-3 (auch was Qualität iVm. Preispolitik angeht) war, dass ich neue Geräte in der Regel nur noch in ZWave oder ZigBee kaufe...
Da wäre ich sofort bei Dir und würde auch gerne Homematic den Rücken kehren.
Bei mir kommt allerdings Homematic fast zu 100% in Fenster-/Türkontakten (mit rausgeführtem Sabotagekontakt zur Erkennung von Auf/Kipp/zu) zum Einsatz.
Da ich den HmIP-SWDO-I (verdeckter Fensterkontakt) schon ziehmlich "scharf" finde :D und diese Bauart leider bei keinem anderen Hersteller (Zigbee, zWave) zu finden ist, bin ich gezwungener Maßen etwas auf HomematicIP fixiert.
Sollte ich da was übersehen habe, dann würde ich mich über einen Hinweis (Link) freuen.
Zitat von: frank am 14 Oktober 2022, 10:40:15
der aktuelle trend ist hmip devices auf bidcos umflashen.  8)
Wenn das zuverlässig funktioniert, wäre es natürlich TOP !
Da werde ich mich mal einlesen und evtl. einen HmIP-SWDO-I bestellen und versuchen diesen mit HomematicRF zu integrieren.
Aus der Reaktionen der anderen Schreiber, schließe ich aber, das dieses Thema hier im Forum noch unbekannt ist und keine Erfahrungen/Hilfe existiert.

Nochmal zu meinem (möglicherweise) geplanten umstieg auf HomematicIP:
Mein Hirn ist jetzt auf dem Stand, das ich min. eine CCUx benötige (originale Hardware oder sonstige Hard-/Sofwarelösung)
Was mir leider immer noch nicht ganz klar ist, sind diese AccessPoints (HMIP-HAP / HMIP-HAP-WLAN).
Agieren die aus technischer Sicht eher als Repeater ?
Wenn ich also eine CCUx habe und 2 HMIP-HAP. Dann würde ich alle Devices mit der CCUx pairen und die Kommunikation erfolgt ggf. automatisch über die AccesPoint ?

Gruß,
JudgeDredd
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

MadMax-FHEM

Zitat von: JudgeDredd am 16 Oktober 2022, 11:47:15
Ist aber sicherlich etwas schade, da ich einen Homematic Handsender zum öffnen meiner Garage verwende. Je nachdem von welcher Seite ich mich nun meinem Grundstück nähere, war es bisher so, das das nächste HM-UART-LGW den Empfang übernommen hat und die Reichweite immer gleich war.
Wenn ich den Handsender künftig mit einer CCUx-Zentrale fest pairen muss, dann würde das bedeuten, das die Reichweite in einer Richtung künftig schlechter ist ?Ich behaupte mal, das mein Haus über mehrere

Ich nehme ja mal an, dass du den Handsender DIREKT mit dem Aktor (wenn es auch Homematic ist) verbunden (gepeert) hast/hattest?

Dabei geht ja das Funksignal DIREEKT zum Aktor, da hat eine Zentrale (außer Mithören) nichts dran zu schaffen.

Ist (ür mich) der Grund warum ich bei (wichtigen) Automatisierungen usw. (versuchsweise) Komponenten EINES Systems nehme, damit diese auch direkt OHNE Zentrale funktionieren.

Zentrale "hört" mit (-> Daten für Verbesserungen u.ä.) und macht Zusatzfunktionen, die "bequem" sind aber nicht (lebens)notwendig.

Würde ja bei HomematicIP auch so gehen.
Dann halt FB und Aktor von HomematicIP oder einfach die alten weiter verwenden und direkt gepeert lassen...

Was nicht geht: Homematic bisCos und HomematicIP Geräte direkt verbinden (peeren)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

zap

Ein HmIP-HAP kann verwendet werden für Geräte, die zu weit von der CCU entfernt sind. Man kann in der CCU für jedes Gerät festlegen und und mit welchem HmIP-HAP es kommunizieren soll.

Häufig ist jedoch gar kein HmIP-HAP erforderlich, denn mittlerweile unterstützen viele HmIP-Geräte Routing, d.h. leiten die Kommunikation an andere Geräte weiter.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

JudgeDredd

Zitat von: MadMax-FHEM am 16 Oktober 2022, 12:29:10
Ich nehme ja mal an, dass du den Handsender DIREKT mit dem Aktor (wenn es auch Homematic ist) verbunden (gepeert) hast/hattest?
Nein, die Annahme ist falsch und Ja, das hatte ich leider nicht erwähnt.
Der Handsender ist direkt mit der vCCU gepairt. Die Garagenöffnung wird durch den Tastereingang ausgelöst, in welcher ein Shelly verbaut ist und über die FHEM-Logik ausgelöst wird.

Wenn tatsächlich mal der Funk ausfallen sollte, dann muss ich entweder per Hand den Taster drücken (innen) oder den Schlüssel drehen (außen)
Zitat von: zap am 16 Oktober 2022, 14:22:45
Ein HmIP-HAP kann verwendet werden für Geräte, die zu weit von der CCU entfernt sind.
Das wäre bei mir ja der Fall
Zitat von: zap am 16 Oktober 2022, 14:22:45Man kann in der CCU für jedes Gerät festlegen und und mit welchem HmIP-HAP es kommunizieren soll.
Ist das wirklich ein kann oder ein muss ?
Zitat von: zap am 16 Oktober 2022, 14:22:45
Häufig ist jedoch gar kein HmIP-HAP erforderlich, denn mittlerweile unterstützen viele HmIP-Geräte Routing, d.h. leiten die Kommunikation an andere Geräte weiter.
Ja, das habe ich weiter am Anfang des Threads schon gelernt, allerdings nur bei Dauerbestromten Devices, welche ich aber nicht habe/einsetze.

Für mein Vorhaben gilt dann also entweder(1) oder (2):

  • virtualisierte CCUx inkl. 3 AccesPointsIP (~50 EUR) = ~150 EUR
  • Hardware CCUx (~150 EUR) inkl. 2 AccesspointsIP (á ~50 EUR) = ~250 EUR
Ein Parallelbetrieb von HomematicRF und HomematicIP wäre dann aber nur möglich, wenn ich meine jetztigen Tür-/Fensterkontakte im Fall (2) direkt mit der CCUx paire ?
Oder ist es auch möglich ein HM-LGW-O-TW-W-EU mit der CCUx zu pairen ?

Irgendwelche Enwände/Korrekturen ?
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

MadMax-FHEM

#21
Zitat von: JudgeDredd am 16 Oktober 2022, 18:17:46
Für mein Vorhaben gilt dann also entweder(1) oder (2):

  • virtualisierte CCUx inkl. 3 AccesPointsIP (~50 EUR) = ~150 EUR
  • Hardware CCUx (~150 EUR) inkl. 2 AccesspointsIP (á ~50 EUR) = ~250 EUR
Ein Parallelbetrieb von HomematicRF und HomematicIP wäre dann aber nur möglich, wenn ich meine jetztigen Tür-/Fensterkontakte im Fall (2) direkt mit der CCUx paire ?
Oder ist es auch möglich ein HM-LGW-O-TW-W-EU mit der CCUx zu pairen ?

Ich sehe zwischen 1 und 2 keinen (deutlichen) Unterschied bzw.:

Irgendwie habe ich das Gefühl dir ist (immer noch) nicht klar, dass es zwischen einer "echten" CCUx und einer virtualisierten CCUx keinen wirklichen Unterschied gibt.

Beides hat die CCUx Oberfläche und beides wird IDENTISCH per HMCCU in fhem eingebunden.

Daher verstehe ich nicht, warum du bei der virtualisierten CCUx 3 APs "brauchst" und bei der "echten" CCUx mit 2 auskommst?

Für Homematic IP brauchst du zwingend eine CCUx (egal ob in "echt" teuer und quasi proprietär gekauft oder "selber zusammengebastelt").

EDIT: (noch mal) eine "echte" CCUx wobei es eine CCU3 sein sollte (wird, gibt es eine CCU2 noch neu? Bzw. macht das keinen Sinn [mehr] als Zentrale) ist ein PI mit Funkmodul und einem vorgefertigten System auf SD. Eine virtualisierte CCUx ist ein PI mit Funkmodul und dann eben der CCUx-SW "selbst aufgespielt" (bzw. eben einem "Clone" davon)... Ist also für den, der es nicht genau weiß überhaupt kein Unterschied! ;)

Homematic BidCos kannst du entweder (weiterhin) nehmen was in fhem bereits läuft, dann halt weiterhin per CUL_HM...
...oder (ablernen) und dann bei der CCUx ("echt" oder "virtuell"/"eigenbau") anlernen und dann (neu) in fhem einbinden, diesmal halt per HMCCU.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

JudgeDredd

Zitat von: MadMax-FHEM am 16 Oktober 2022, 18:25:37
Daher verstehe ich nicht, warum du bei der virtualisierten CCUx 3 APs "brauchst" und bei der "echten" CCUx mit 2 auskommst?
Aktuell benötige ich 3 Zugangspunkte für meine Devices um alles Lückenlos abzudecken.

Ich war/bin der Meinung, das bei einer "echten" CCU3 ein Funkmodul mit an Board wäre und bei einer virtualisierten brauche ich dann rechnerisch eben noch ein weiteres Funkmodul (in Form eines Access Points) um auf 3 Zugangspunkte zu kommen.

Bitte sag jetzt nicht, ich hab es schon wieder nicht kapiert  :-\
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

MadMax-FHEM

#23
Zitat von: JudgeDredd am 16 Oktober 2022, 18:45:26
Ich war/bin der Meinung, das bei einer "echten" CCU3 ein Funkmodul mit an Board wäre und bei einer virtualisierten brauche ich dann rechnerisch eben noch ein weiteres Funkmodul (in Form eines Access Points) um auf 3 Zugangspunkte zu kommen.

Auf die virtuelle CCUx kommen potentiell dieselben Funkmodule wie bei der "echten" CCUx in Frage.
Also KEIN AP sondern ein "echtes" Funkmodul.

Welche bei den (diversen) virtuellen CCUx gehen steht im Wiki oder in einem (bereits verlinkten?) Thread.
EDIT: jep, gleich zu Beginn https://forum.fhem.de/index.php/topic,116424.0.html Da sollte doch alles stehen?

Es geht das HMOD-PCB, das "spezielle" HMOD-PCB (RPI-RF-MOD) und der USB-Stick...
EDIT: welche Funkmodule jeweisl gehen usw. steht dann bei der jeweiligen Plattform (debMatic, piVccu, ...). Bei der "echten" CCU3 ist mWn ein RPI-RF-MOD dabei. Also eine virtuelle CCUx basierend auf z.B. debMatic (oder auch piVccu usw.) mit eben diesem Funkmodul RPI-RF-MOD ist quasi fast 100% identisch ;)

Zitat von: JudgeDredd am 16 Oktober 2022, 18:45:26
Bitte sag jetzt nicht, ich hab es schon wieder nicht kapiert  :-\

Entscheide selbst ;) :D

EDIT: also noch mal ganz kurz: der einzige Unterschied zwischen einer "echten" fertig gekauften CCUx und einer virtuellen CCUx ist eben: selber einiges machen vs. fertig kaufen und nur zusammenstecken ;)
EDIT: und nat. dass bei einer virtuellen CCUx (etwas) mehr "Freiheit" vorhanden ist ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

frank

Zitat1. virtualisierte CCUx inkl. 3 AccesPointsIP (~50 EUR) = ~150 EUR
so nicht, siehe sreenshot.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

JudgeDredd

Zitat von: MadMax-FHEM am 16 Oktober 2022, 18:53:20
EDIT: und nat. dass bei einer virtuellen CCUx (etwas) mehr "Freiheit" vorhanden ist ;)
OK, hast Du ein Beispiel, was mit mehr Freiheit gemeint ist. Oder gilt das eher für eine Umgebung bei der der RPI möglichst viele andere Dinge erledigen soll ?
In meinem Netz laufen DomainController, ApplicationServer und FileServer.
Da denke ich ist genug "Freiheit" für mich vorhanden.
Für mich ist der große Vorteil einer Standard Hardware CCU3 einfach der, das sie sich optisch besser in eine weiße Zimmerdecke "integriert".
Sicher könnte man da auch was mit selbstgedruckten RPI Gehäusen erreichen, aber da ist der Aufwand höher.

Zitat von: frank am 17 Oktober 2022, 09:57:31
so nicht, siehe sreenshot.
Oha, das ist wirklich ein sehr guter Hinweis. Damit wird es etwas konkreter was mein Umsetzen angeht.
(Woher hast Du den Screenshot ? Im Wiki und den angepinnten Threads hier im Unterforum habe ich den nicht gefunden.)

Dann wäre das Setup:
FHEM (HMCCU) => HmIP-CCU3 + 2 x HMIP-HAP => HomematicRF + HomematicIP Devices

Am nächsten an meiner aktuellen Installation dran:
FHEM (CUL_HM) => 3 x HM-LGW-O-TW-W-EU-2 => HomematicRF Devices
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

Beta-User

Zitat von: JudgeDredd am 17 Oktober 2022, 11:42:45
Dann wäre das Setup:
FHEM (HMCCU) => HmIP-CCU3 + 2 x HMIP-HAP => HomematicRF + HomematicIP Devices
Jein. "HomematicRF"-Devices (BidCoS?!?!) kannst du dann funktechnisch NUR von der CCU3 aus erreichen, was dir im Moment ja NICHT ausreicht. Wenn du die alten Geräte also weiter nutzen willst, musst du AUCH noch 2 von einen HM-LGW-O-TW-W-EU-2 weiter laufen lassen!

(Die Grafik ist ganz nett und vermutlich auf den Seiten des Herstellers zu finden. Der verrät einem aber nicht, dass afaik die HM-Ip-Wlan-AP umflashbar sind).

(Und so ganz nachvollziehen kann ich es auch nicht, dass nicht in der Nähe vom potentiellen Aufstellort der HMIP-HAP irgendwo Verwendung sein könnte für Router-fähige Geräte, die genau dasselbe bewirken, aber für den Preis dann wenigstens noch einen Zusatznutzen bieten würden).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

JudgeDredd

Zitat von: Beta-User am 17 Oktober 2022, 12:10:14
Jein. "HomematicRF"-Devices (BidCoS?!?!) kannst du dann funktechnisch NUR von der CCU3 aus erreichen, was dir im Moment ja NICHT ausreicht. Wenn du die alten Geräte also weiter nutzen willst, musst du AUCH noch 2 von einen HM-LGW-O-TW-W-EU-2 weiter laufen lassen!
Japp, sehr guter Einwand ! Bevor ich die HM-LGW-O-TW-W-EU-2 entsorge wird ja noch etwas Zeit vergehen.
Zitat von: Beta-User am 17 Oktober 2022, 12:10:14
(... Der verrät einem aber nicht, dass afaik die HM-Ip-Wlan-AP umflashbar sind).
Böser Hersteller aber auch  ;)

Bevor ich, dank Euch, mein erlangtes hmIP-Diplom in die Praxis umsetze, überlege ich mir ernsthaft mal ein hmIP Device zu Bestellen und es auf BidCos umzuflashen.
Das erscheint mir doch recht attraktiv, ich aber nicht einschätzen kann, ob es auch tatsächlich gut funktioniert.
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

MadMax-FHEM

Zitat von: JudgeDredd am 17 Oktober 2022, 11:42:45
OK, hast Du ein Beispiel, was mit mehr Freiheit gemeint ist. Oder gilt das eher für eine Umgebung bei der der RPI möglichst viele andere Dinge erledigen soll ?
In meinem Netz laufen DomainController, ApplicationServer und FileServer.
Da denke ich ist genug "Freiheit" für mich vorhanden.

Ok, vielleicht falsch ausgedrückt ;)

Auf einer echten CCU3 musst du halt sehen, wie du andere Dinge installiert bekommst, schon fhem wäre eine Herausforderung wie ja weiter oben bereits genannt...
...bei einer virtuellen CCUx ist halt die Basis (meist) ein "normaler" PI inkl. "normalem" Raspbian-OS wo dann eben eine "CCU-SW" "installiert" wird...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

JudgeDredd

Zitat von: MadMax-FHEM am 17 Oktober 2022, 12:57:52
Ok, vielleicht falsch ausgedrückt ;)
Nein, alles gut, ich habe es schon richtig Verstanden.
Zitat von: MadMax-FHEM am 17 Oktober 2022, 12:57:52
Auf einer echten CCU3 musst du halt sehen, wie du andere Dinge installiert bekommst, schon fhem wäre eine Herausforderung wie ja weiter oben bereits genannt...
...bei einer virtuellen CCUx ist halt die Basis (meist) ein "normaler" PI inkl. "normalem" Raspbian-OS wo dann eben eine "CCU-SW" "installiert" wird...
Meine (künftige) CCU3 wird ausser Funkmodul zu sein keine weiteren Aufgaben bekommen.
Das einzige, was ich schauen muss, ob ich das Ding mit POE stabil ans laufen bekomme. (5VDC max. 12,5W)
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)