Mithilfe erbeten: Übersicht: Zigbee - Technik / Einbindungsmöglichkeiten in FHEM

Begonnen von Ranseyer, 15 November 2018, 09:10:44

Vorheriges Thema - Nächstes Thema

Ranseyer

Da ich oft per PN gefragt werde ein Artikel: https://wiki.fhem.de/wiki/Zigbee

Eigentlich ging es mir nur um
- Reichweite => einigermaßen beschrieben
- Sicherheit => da tue ich mich etwas schwer weil ich nicht so recht weiß was ich schreiben darf bzw. wie den Experten aus dem Link zitieren. Ich glaube ich lass das mal lieber aus rechtlichen Gründen... Es ist ja angedeutet was Sache ist...

Feedback oder besser Mithilfe ist sehr gerne gesehen !

FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

ph1959de

Ist das jetzt


  • eine Ankündigung der (eines neuen) Wiki Seite
  • die Bitte um Korrekturlesen
  • ...?

Rückmeldung von mir auf jeden Fall schon mal: bitte die Relevanz für FHEM einfügen (verlinken eines Moduls, sofern es eines gibt, Einsatz / Unterstützung in FHEM, ...).

Und natürlich: Danke für die Mitarbeit im Wiki.

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Beta-User

Gute Initiative, wurde mal Zeit... ;)

Was die Strukturierung angeht, greift der Einbindungsteil m.E. deutlich zu kurz:

-Hue
-xiaomi-Bridge (?)
-Tradfry-Modul
- ...?
-Dresden-Elektronik-Modul (HW+Serverkomponente?)
-zigbee2mqtt mit den beiden Varianten
-- neumann-Modul + klassisches mqtt-modul
-- mqtt2-device wie bereit im Wiki kurz dargestellt (ergänzt um die Einstellungen in der yaml bzw. zu aktualisieren).

Kann man das als Kategorie-Seite nehmen und dann das, was es ggf. dazu schon gibt mit der Kategorie "Zigbee" versehen?

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

gvzdus

Ich finde die Seite gut, wie jede Wiki-Seite.
Allerdings ist sie mir zu akademisch.

       
  • Ich würde mir recht früh eine kurze Liste der gängigen Marken (Philips Hue, Tradfri, Lightify u.s.w.) und einen Verweis auf einen Einkaufsguide wie den von iConnectHue (https://iconnecthue.com/supported-devices/) wünschen
  • Vielleicht ein grundsätzliches Reflektieren über die Vorteile von ZigBee - vor allem im Vergleich zu Wifi-Birnen
  • Ich bin im Prinzip so vorgegangen: Hue-Starterset gekauft, dann etwas heterogen das heimische Netz ausgebaut. Heute frage ich mich, ob es schlau war, auf die Hue-Bridge von Philips zu setzen. Denn seit dem Kauf von MotionSensor und Dimmer-Switch ärgere ich mich wie andere auch darüber, dass die Hue-Bridge zwar willig Kommandos befolgt und die API dafür okay ist, aber nichts und gar nichts - außer per Pollen - nach außen dringen lässt. Meine Switches und Sensoren kann ich daher nur innerhalb der Hue-Bridge einsetzen. Daher wäre ich glücklich, wenn man auf so einer Seite auch Tipps für die Entscheidung "Hue-Bridge" versus Rasbee versus XY finden kann.

Beta-User

Hmmm, das mit Vor- und Nachteilen wäre nicht schlecht, aber: zum einen ist das manchmal schnell überholt, zum anderen manchmal subjektiv.
M.E. sollte sowas nur an einer Stelle stehen, sonst kann man das erfahrungsgemäß nicht aktuell halten; das gehört zum jeweiligen Modul-Artikel (dass leider viele Artikel sowas nicht haben, ist eine andere Geschichte).

Ob und wieviel "akademisches Wissen" reingehört, ist eine Geschmackssache; persönlich würde mir eine Kurzfassung der relevanten Punkte iVm. einem Wikipedia-Verweis reichen (so es sowas gibt). Da sich das aber auch nicht ändert, schadet es auch nicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

gvzdus

Etwas offtopic, aber relevant für die Frage, was gehört in einen Wiki:
Bei mir steht die 5-stellige Investition in eine neue Gas-Heizung im EFH an. Und an die habe ich natürlich die Erwartung: Alles, was ich als Endanwender einsehen und steuern kann (Temperaturen, Zustand, etc.), muss auch mit FHEM laufen. Nun war mein erster Google-Treffer hier ins Forum ein Link auf jemanden, der genau meine unschuldige Frage gestellt hatte, und mit einem "Lies Dir die Infos zu den jeweiligen Modulen selber durch" abgespeist wurde.
Natürlich kann und sollte man sich einige Stunden informieren, bevor man 10.000 Euro in die Hand nimmt. Inzwischen bin ich halbwegs durch und habe den Eindruck gewonnen: Viessmann Vcontrol geht, und zwar entweder mit FHEM ohne Viessmann-Cloud, oder ohne FHEM mit Viessmann-Cloud. Ebus hingegen ist spannender. Diese Suche führt dann i.d.R. zu einem Thread, der auf Seite 1 mit "Jungs, ich habe die ersten Schritte gemacht" beginnt, und auf Seite 150 den Beitrag von User Y enthält, "Weisst Du, was im Register X der Wert Y heissen könnte?". Dazwischen sich einen echten *Stand* der Dinge zu extrahieren, eine Aussage der Art "Du wirst mit einer SchnurzX-Heizung FHEM-technisch auf einen guten Stand treffen" abzuleiten - ist schmerzhaft.

Zurück zu Zigbee: Ich habe hier schrittweise gelernt, wo die Grenzen der hue-Bridge liegen. Ich weiß noch nicht, ob ich eher mit einem Dresden Elektronik oder Rasbee glücklicher würde  - und da könnte ein Wiki-Artikel viele Stunden Recherche sparen. Und so alt wie Wikipedia ist ja der Streit über das, was drin steht. Nur anders als hier im Forum stehen als Resultat dann nicht 30 weitere Seiten in einem Thread vor dem Neuankommenden / Ratsuchenden, sondern eine ggf. in der Diskussion ausgewogenen Gesamteinschätzung zu Vor- und Nachteilen.

PeMue

Hallo zusammen,

da ich in dem Thema ZigBee überhaupt nicht drin bin, hier mein Vorschlag:

Ich habe einen CC2531 Stick und ein paar Ikea Tradfri Lampen inkl Fernbedieungen und keine Ahnung vom Thema.
Daher würde ich mir das Wiki mal anschauen und mal schauen, ob ich die Lampen (inkl. Fernbedienung) in FHEM integriert bekomme.

Aus meiner Sicht gibt es mehrere Sichtweisen im Wiki:
- Beschreibung, wie etwas funktioniert (Überblick)
- Beschreibung, wie man etwas einrichten könnte (das, was vermutlich die meisten interessiert), könnte aber ausufertn, da die Möglichkeiten quasi unbegrenzt sind
- Einzelbeschreibung von Geräten (z.B. wie bei Homematic)

Mit dem Überblick fängt derjenige, der etwas einrichten kann, nichts an, ggf. ist die Einzelbeschreibung zu wenig.

Was meint ihr?

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Beta-User

Na ja, mit HM kann man es nicht vergleichen: Da gibt es nur einen Hersteller und im wiki steht fast ausschließlich was zur Einbindung mit CUL_HM. Ist historisch so gewachsen, jetzt aber nicht mehr vollständig, egal wie man zu ccu2/3 steht...

Mit dem Stick geht "nur" zigbee2mqtt" - da ist feedback zu beiden Varianten gerne willkommen (das allerdings zu den Praxisbeispielen jedenfalls auch gehört - dort fehlt nur die klassische Variante, wo es ähnlich ist: man muss sich aus x-hundert Beiträgen alles zusammensuchen... M.E. ein Grund - zusammen mit der gehenden CR, davon ausdrücklich abzuraten. Ist (jetzt) nur (noch) eine unnötige Sonderlocke.

Wer jetzt in das Thema einsteigt, ist mit mqtt2-devices gut bedient, allerdings mit min. 2 Haken: rgb-Geräte gehen nur mit eigenem coding, bis der erste den Transfer veröffentlicht hat und keine updates (u.uU. keine direkten Verknüpfungen zwischen einzelnen Geräten). Das updatethema ist eh ein Fall für sich: da kocht jeder Hersteller wieder sein eigenes Süppchen, Fremd-hw kann gehen, tut es aber idr. nicht. Dto, wenn auch weniger ausgeprägt gilt das auch für die Anbindung von Geräten verschiedener Hersteller...

Das bringt mich zum letzten Punkt: leider kennt keiner alles, den Königsweg gibt es nicht. Was man leisten kann, ist eine Art Start- und Orientierungsseite zu schaffen, um wenigstens das zu haben. U.a. deswegen der Vorschlag, das wie vorgeschlagen als Kategorien-Seite zu gestalten (sonst ist der Serientitel bitte anzupassen).

Letztlich entscheiden muss der informierte user, der dann eben entweder die Luxus-Variante nach Lektüre des mega-threads konfiguriert bekommt oder die gut dokumentierte Einfachversion nimmt.

Zu den ebus-Dingen gibt es btw. nach meinem Kenntnisstand ein gutes wiki - da steht nur nicht, ob man die hw-Schnittstelle auch für HT3-Bus-Geräte verwenden kann...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Cool, die Diskussion die ich da losgetreten habe freut mich.

Zitatist sie mir zu akademisch.
Ich habe den Anfang noch etwas gekürzt. Leider muss man trotzdem die Gerätetypen verstehen um das Richtige zu kaufen. (Vom Endgerät mal abgesehen, das sollte klar sein)

Zitat
-Hue
-xiaomi-Bridge (?)
-Tradfry-Modul
- ...?
-Dresden-Elektronik-Modul (HW+Serverkomponente?)
-zigbee2mqtt mit den beiden Varianten
-- neumann-Modul + klassisches mqtt-modul
-- mqtt2-device wie bereit im Wiki kurz dargestellt (ergänzt um die Einstellungen in der yaml bzw. zu aktualisieren).

Gerne wenn davon jemand Ahnung hat nachtragen/ Umbauen.

ZitatKann man das als Kategorie-Seite nehmen und dann das, was es ggf. dazu schon gibt mit der Kategorie "Zigbee" versehen?
Gern.

Zitatob ich eher mit einem Dresden Elektronik oder Rasbee glücklicher würde  - und da könnte ein Wiki-Artikel viele Stunden Recherche sparen.
Gern ergänzen...


ZitatDaher würde ich mir das Wiki mal anschauen und mal schauen, ob ich die Lampen (inkl. Fernbedienung) in FHEM integriert bekomme.
Das glaube ich kaum. Wenn du Homematic gernell verstanden hast kannst du es auch noch nicht so unbedingt einrichten. (Auch da ist die Frage mit/ohne CCU, oder gar per MQTT und anderem bei Langeweile)

Ich würde als Ziel sehen: Zigbee verstehen:
-die Theorie soweit nötig
-verfügbare Lösungen für FHEM kurz angerissen + ggf- Link auf andere Artikel
-Frequenz um Antennen zu missbrauchen
-Sicherheit um Zigbee ggf auch mal nicht zu nutzen
-Geräte würde ich hier keinesfalls beschreiben. Man kauft wozu man gerade Lust hat von dem Hersteller der gerade passt => weiterer Artikel  falls jemand Lust hat ???

Ich würde das wie Beta-User sehen: Etwas breitere Sprungseite als Überblick mit den nötigen Grundlagen...

PS: Zu HUE und Co kann ich nichts schreiben weil ich zu den speziellen Lösungen ähnlich wie zum Raspberry stehe und daher keine Ahnung habe. Ergänzungen willkommen !
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

gvzdus

So, jetzt habe ich nach Deiner Ermutigung mal "live" im Wiki unter Gateways skizziert, wie ich mir das vorstelle:
- "Hersteller": Da gibt es noch 1 - 2 andere, zu denen sich im Forum was findet.

Bei "Freie Lösungen" fehlte mir bei Dir eine Skizze, was da überhaupt passiert. Ich denke, man sollte hier DeCONZ und zigbee2mqtt mindestens anführen, und anreißen, wo der Unterschied ist (DeCONZ = komplett mit GUI und Co, zigbee2mqtt = saubere Transformation auf ein Standardprotokoll ohne Endanwenderschnittstelle).

Ich hab' "zwischencommitted" in der Sorge, dass Du auch gerade dran bist. Warte auf ein "Mach weiter" oder "Finger wech".

Beta-User

...das was ich im Moment sehen kann, geht schon mal deutlich in die richtige Richtung (Meinung!).

Zigbee2mqtt-Hardware sind einige wenige TI-"Chips". Das kann man m.E. auch vage lassen und auf das wiki bei github verlinkten (Fußnote?).

Kann mal jemand diesen und den Praxis-Beispiele-Thread mit der Kategorie "Zigbee" versehen und dann die Kategorie-Seite aufrufen? (Ggf. danach den Inhalt auf diese neue Seite ziehen und den bisherigen löschen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Zitat von: gvzdus am 15 November 2018, 20:04:00
Ich hab' "zwischencommitted" in der Sorge, dass Du auch gerade dran bist. Warte auf ein "Mach weiter" oder "Finger wech".


Danke ! Gerne weiter!
Ich habe aktuell nur das Sicherheitsthema bearbeitet. Vor allem die Credits.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

Danke, denke das ist doch nun schon mal ein Anfang den man so lassen kann und auf die normalen Verbesserungen durch die Leser hoffen...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

So, habe mal die Seite zur Kategorienseite umgebaut bzw. eine Weiterleitung eingerichtet.
Ok so?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Prof. Dr. Peter Henning

ZitatDiese Suche führt dann i.d.R. zu einem Thread, der auf Seite 1 mit "Jungs, ich habe die ersten Schritte gemacht" beginnt, und auf Seite 150 den Beitrag von User Y enthält, "Weisst Du, was im Register X der Wert Y heissen könnte?".

Das liegt daran, dass sowohl der Ersteller des Threads (ich) als auch derjenige, der die Hauptentwicklungsarbeit am ebusd macht (john30) nicht die Zeit haben, alle Threads nach Supportanfragen zu durchsuchen... Außerdem gibt es gerade dazu sehr gute Dokumentation außerhalb von FHEM.

LG

pah