Homee-Würfel

[Superposchi]

Keine Ahnung, wahrscheinlich wieder mal das falsche Unterforum, trotzdem die Frage hier da ja auf mehrere Systeme Bezug genommen wird.

Ich interessiere mich für die Homee-Gateways, die ja erweiterbar für verschiedene Systeme sind.
Beispielsweise: https://www.amazon.de/homee-SMART-STARTERSET-Brain-EnOcean/dp/B076CNL3J2/ref=sr_1_5?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=homee+Smart+Home&qid=1621179381&s=ce-de&sr=1-5

Sind die einzelenen Würfel (Gateways) kompatibel zu den Original-Gateways?
Ist speziell der EnOcean-Würfel mit dem EnOcean-Modul hier in Fhem nutzbar?

Hat da jemand Erfahrungen mit gemacht?

[Esjay]

Servus. Ich bin mir noch nicht richtig sicher ob ich dich richtig verstanden habe.
Basis ist ja immer der Brain Cube. Den könnte man wohl per Node-Red per Mqtt an Fhem anbinden. Dann sollten sich darüber auch die jeweiligen Gateways steuern lassen.
Ist halt schon ein Klimmzug.

Aber warum gibt man so viel Geld für Gateways aus? Das geht doch um einiges günstiger.

Grüße

[Superposchi]

So wie ich das verstanden habe ist der "Brain Cube" doch lediglich die Verbindung zum Netzwerk und die einzelnen Modulwürfel die darauf aufgestöpselt werden können sind die Gateways für die einzelnen Systeme, oder ist das Falsch. Den "Brain Cube" selbst braucht man doch gar nicht in Fhem einbinden, oder?

Die Frage nach dem Warum lässt sich nicht einfach so beantworten, da gibt es viele Variationen. Zum einen reizt mich das Kompakte Design und der geringe Platzverbrauch ( Ich habe aktuell an 2 Verschiedenen Plätzen jeweils min. 3 Gateways hängen). Zum anderen, dass ich bei meiner Konfiguration mit Docker nicht eben so EnOcean per Conbee-Stick ans Laufen bekomme.

[MadMax-FHEM]

So wie ich das verstanden habe ist der "Brain Cube" doch lediglich die Verbindung zum Netzwerk und die einzelnen Modulwürfel die darauf aufgestöpselt werden können sind die Gateways für die einzelnen Systeme, oder ist das Falsch. Den "Brain Cube" selbst braucht man doch gar nicht in Fhem einbinden, oder?

Natürlich brauchst/musst du HomeeBrain nicht an/mit fhem koppeln.
Dann kannst du aber auch nur DORT "automatisieren" mit den DORT angelernten Geräten...
...und (parallel) in fhem eben alles was an fhem "angeschlossen"/angelernt ist.

Also nicht einen per Homee gekoppelten Sensor nutzen um einen an fhem angelerten Aktor zu schalten etc.

Und ob Homee an fhem gekoppelt werden kann: keine Ahnung.

Ist vergleichbar mit einer CCUx bei Homematic (außer, dass die halt nur Homematic BidCoss und IP kann und sonst nix)...
...du kannst beides getrennt/parallel betreiben oder eben koppeln.

Also HomeeBrain ist die Zentrale von/für Homee.
Du kannst dort automatisieren etc. ebenso wie in fhem.

Man kann ja an 2 oder mehreren Stellen "automatisieren" etc. aber ich selber hab da lieber nur eine Stelle...
Finde ich übersichtlicher.

Zum anderen, dass ich bei meiner Konfiguration mit Docker nicht eben so EnOcean per Conbee-Stick ans Laufen bekomme.

EnOcean und Conbee?
Conbee ist doch ZigBee.

An anderer Stelle ja schon geschrieben (wenn ich mich nicht täusche): evtl. kann man z.B. EnOcean-PI und RaspBee auch per TTL-LAN-Adapter einbinden, also wie einen HM-CFG-LAN...

Gruß, Joachim

[Superposchi]

Conbee ist doch ZigBee

Kann sein das ich mich da irre. Hatte nur was im Kopf von EnOcean und USB-Stick als Gateway.

EnOcean-PI und RaspBee

Sagt mir beides nichts. Ich kenne nur EnOcean als Protokoll/Funknetz und als Modul.

[Beta-User]

Kann sein das ich mich da irre. Hatte nur was im Kopf von EnOcean und USB-Stick als Gateway.

Es gibt für alle möglichen Protokolle (und Frequenzen) USB-Dongles, oder eben häufig alternativ Module für den Pi (und andere "GPIO-Bastelrechner"), die eine direkte serielle Anbindung benötigen.

Die Verbindungen zwischen den "Homee"-Würfeln sehen sehr nach serieller Verbindung zwischen den Modulen aus (4 PINs für GND, Power (vermutlich 5V oder 3.3V) und RX/TX). Wahrscheinlich gibt es irgendeinen Software-Weg, um auch sowas wie die Homee-Zentrale anzubinden, aber vermutlich lohnt das nicht, und die Module sind ein Risiko, weil man  uU. erst mal rausfinden muss, wie genau die Daten zu verstehen sind, die darüber ausgetauscht werden. Ergo: Nimm' lieber was "bekanntes" (und in der Regel deutlich billigeres).

Das mit dem NAS ist kein wirkliches Problem, wenn du nicht grade Homematic-IP machen willst. Für alles andere gilt mal wieder die Empfehlung: Kauf' einen Rechner mit USB-Schnittstellen (z.B. einen Pi) und installiere darauf FHEM _oder_ reiche die USB-Schnittstellen mit ser2net an dein NAS durch. Das wäre die für Einsteiger empfohlene Variante!
Alternativ kann man viele der "bekannten seriellen Pi-Module" über einen TTL-LAN-Adapter, ESP8266 oder MapleCUN "irgendwie" ans Heimnetz anbinden und dann darüber ansprechen. Das wäre die "Geld-Spar-Bastler"-Variante (geeignet aber nur für Leute, die solchen Stichworten wie den von MadMax-FHEM genannten TTL-LAN-Adapter aus eigener Initiative was abgewinnen können; auf der FHEM-(NAS)-Seite sind beide Varianten praktisch gleich zu handhaben).

[MadMax-FHEM]

Zitat
    EnOcean-PI und RaspBee

Sagt mir beides nichts. Ich kenne nur EnOcean als Protokoll/Funknetz und als Modul.

Google kennst du aber?

Google -> Raspbee: https://phoscon.de/de/raspbee2

Google -> Enoceanpi: https://www.rasppishop.de/ENOCEAN-PI-868-Das-868MHz-Transceiver-Modul-fuer-Raspberry-Pi

Jeweils nur einfach so die ersten beiden Treffer (meiner Suche)...

EDIT:
TTL-LAN-Adapter: https://www.waveshare.com/uart-to-eth.htm
(ebenfalls "wahllos" irgendeiner)

Anschließbar evtl. wie das HMOD-PCB: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_.C3.BCber_das_Netzwerk
oder
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler

Alles weitere hat Beta-User ausgeführt...

Gruß, Joachim

[Beta-User]

Anschließbar evtl. wie das HMOD-PCB: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_.C3.BCber_das_Netzwerk
oder
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler

Deinen Eifer in Ehren, aber
a) ist Superposchi nach eigener Auskunft sehr geübt darin, Suchmaschinen zu bedienen und (vor allem!)
b) ist gerade das Homematic-Modul (zwischenzeitlich) ein SCHLECHTES BEIPIEL für ein via LAN-TTL-Anbindung abgesetztes Interface (geworden), weil es (afaik) als auf diese Weise abgesetztes IO NICHT für HM-IP geeignet ist! Die timings passen nicht über das Netzwerk, HM-IP ist da (zu) empfindlich!
(Alles weitere zu dieser sehr speziellen und hier auch nicht gefragten (!) Variante ist in horti's vorzüglicher Zusammenfassung zu finden, die im HM-Bereich des Forums angepinnt ist. Darüber sind dann auch die Beiträge zum Thema HM-IP und timing zu finden).

(Ansonsten: Ja, das Modul ist für CUL_HM (die Hardare aka: Homematic-Classic)  sehr gut geeignet und hängt bei mir an einem USB-Seriell-Wandler an einem uralt-x86-Debian-Server - nur ist eben Homematic-Classic irgendwie am auslaufen oder schon abgekündigt).

[MadMax-FHEM]

EDIT: ja klar, das mit Suchmaschine... War ja auch mit ' ' "versehen... Aber warum dann: sagt mir nix, weil nach 2s Suche wäre klar gewesen worum es sich handelt...

Das Hmod-Pcb war ja nur als ANSCHLUSSBEISPIEL gedacht

NICHT zur Verwendung als IO.
Weil klar: DARUM ging es (nat.) nicht

EDIT: gut hierum auch nicht. Sorry für's Abschweifen...

Gruß, Joachim

[Beta-User]

Aber warum dann [...]

Über manche Dinge ist es schlauer zu schweigen, dann bleibt der Thread vielleicht bei der Sache ...

[...] war ja nur als ANSCHLUSSBEISPIEL gedacht

GESUCHT war aber sinngemäß: "nicht noch ein GW, sondern irgendas kompaktes und hübsches (fertiges)", möglichst ohne zusätzlichen "Hackel" wegen des NAS, auf dem FHEM läuft (bzw. unbedingt laufen muss, wie uns an anderer Stelle bereits deutlichst mitgeteilt wurde).

Kurze Antwort nochmal zur eigentlichen Frage: So ein Homee-_Interface_-Würfel (z.B. für EnOcean ODER ZigBee) ist vermutlich nicht alleine lauffähig, man braucht eigentlich immer:
- eine Art Treiber für das eigentliche Interface und
- Software, die aus den über den "Treiber" gewonnenen Daten "Geräte" macht.
In FHEMe eben typischerweise ein GW-Modul (z.B TCM für EnOcean, https://wiki.fhem.de/wiki/EnOcean_Starter_Guide#Definition_von_TCM_.2F_Gateway), und dann eben entsprechend viele Instanzen eines Client-Moduls (EnOcean).
Nimmt man was "fremdes" (also auch den "Brain"-Baustein), kann man z.B. den vorgeschlagenen Weg verfolgen, und das "externe Zeug" via MQTT in FHEM bringen, hat dann aber "noch ein Interface" (wie die bei Superposchi schon vorhandenen Xiaomi- etc-pp Gateways). Da wir (vermutlich) nicht wissen, was in dem Homee-Würfel steckt, kann auch keiner sagen, ob ein "FHEM-interner Treiber" dafür passen würde. Wenn doch, bliebe die Frage, welchen Vorteil der Würfel gg. einem USB-Dongle hätte.

MAn. ist das der falsche Ansatz, wenn einem die Zahl der Gateways schon jetzt zu groß ist; dann sollte man lieber sehen, dass man die "Manufacturer-specific" Spionage-GW's loswird. Aber diesen Weg will mancher User eben nicht gehen...
Aber wenn man ihn gehen will, sind USB-Interfaces eigentlich ideal, und ein einfacher Pi der 1. Generation sollte ausreichen, (über einen aktiven USB-Hub (!) ) mehr USB-Interfaces anzubinden, als in einer 75m²-Wohnung sinnvoll sind. Kostenpunkt: 30-50 Euro zzgl. der Kosten für jedes Dongle. Ergo: Schon mit nur einem (der teureren) USB-Dongles  fährt man mit der Pi-Lösung günstiger und ist kaum größer als die 5x5x5 cm für so einen Homee-Würfel.