Beratung und Grundsatzfragen zum Hardwarekauf

[FHEM_ASB]

Hallo Zusammen,
mein Name ist Roland und ich bin ein (mittlerweile gestresster) QIVICON bzw. Telekom SmartHome User. Die Installation läuft knapp zwei Jahre und war mein Einstieg in das Thema Hausautomation. Anfangs recht zufrieden stört mich nun aber, das die Qivicon Programmierer darüber entscheiden, was ich nutzen darf und was nicht. Z.B. Würde ich gerne mehr auf Homematic IP setzen, kann die Komponenten aber nicht anlernen, weil nicht unterstützt. Und die Aussagen, wann etwas kommt oder nicht sind allesamt wertlos.

Aktuell besitze ich:
- Homematic und Homematic IP Komponenten zur Haussicherung (Bewegungsmeldern, Fenstersensoren, Handsender)
- einen HMIP Accesspoint
- Logitech Circle 2 Kameras
- HUE Lampen
- Alexa
- Bose

Kommen soll noch:
- HMIP Fußbodenheizungssteuerung und Wandthermostate für alle Räume
- Rolladensteuerung
- Wetterstation
- Steuerung für Gartenbewässerung

Ich beabsichtige einen Raspberry einzusetzen und benötige in der ersten Ausbaustufe zwingend die Möglichkeit für Homematic UND Homematic IP Komponenten. Aber egal wieviel ich lese, ich komme nicht durch den Dschungel an Infos. Immer wenn ich denke, jetzt weiß ich es, kommt eine irgendeine Einschränkung oder ich bin nicht sicher, ob beides auf einem Raspberry läuft und auch kompatibel ist.

Was genau benötige ich zusätzlich zum Raspberry um beides zu nutzen? Einen CUL für HM und einen für HMiP? Oder einen Software CUL? Oder brauche ich 2 Raspberrys? Kann ich den Accesspoint für irgendwas nutzen?

Sorry für soviel Input und Vielen Dank für eure Inspirationen

[Neuhier]

Für Raspi gibts einen HM-Aufsatz.
ZigBee ist als Stick mit zigbee2mqtt machbar - für z.B. Osram, HUE, Xiaomi/ Aqara....

Von HMIP halte ich nix, ist deren Server down, sind Deine Komponenten nicht erreichbar.
Kann sein, daß da mittlerweile die Freaks was haben, ist aber nicht mein Interessenfeld.

[MadMax-FHEM]

Für HMIP brauchst du unbedingt eine CCU!

Es gibt die Möglichkeit auf Basis eines PI mit dem Aufsteckmodul für den Bausatz "Charly" von ELV eine CCU3 selbst zu "bauen" und darauf dann theoretisch auch fhem laufen zu lassen.

Ist aber wohl u.U. nicht so einfach (also fhem auch noch drauf zu packen).

Gibt einen releativ neuen Thread zu dem Thema...
...irgendwas wie: fhem auf CCU3...

Ansonsten gibt es die auf jeden Fall funktionierende Möglichkeit: CCU2 oder CCU3 (wahrschinlich besser gleich das zu machen) und dann per HMCCU in fhem einbinden (musst du auch tun, wenn fhem auf der CCU läuft). Also 2 verschiedene Systeme: CCU2/CCU3 (selbstbau) und fhem.

Die HomeMatic Komponenten (OHNE IP) könntest du auch direkt an fhem anbinden...
...aber ich würde da nicht mischen: also HMohneIP an fhem und HMmitIP dann an CCU und per HMCCU in fhem...
...sondern gleich alles an die CCU und dann per HMCCU-Modul in fhem.

Soweit mir bekannt läuft HomeMatic IP mit CCU auch lokal ohne Internet und Cloud...
...aber da vielleicht noch mal im Internet recherieren (habe kein HomeMatic IP).

Ich lese grad (noch mal): du hast ja schon eine HMIP-Zentrale!? CCU2/CCU3? Die dann "einfach" per HMCCU-Modul in fhem einbinden...

TIPP: lass die Finger von einem CUL für HomeMatic!!

Für Zigbee gibt es neben der erwähnten Variante auch noch das RaspBee Modul von Dresden Elektronik und das dann als HUE-Bridge einbinden.
Mache ich so, habe aber nur HUE...
...und ich habe einen extra PI dafür (weiß aber nicht, ob das ein MUSS ist).

Wenn du auch bereits eine HUE-Bridge hast, dann kannst du die nat. auch gleich direkt mittels HUE-Bridge-Modul einbinden...

Für Alexa gibt es (mind.) 2 Möglichkeiten: ha-bridge bzw. alexa-fhem. Damit sind dann praktisch alle in fhem vorhandenen und schaltbaren Geräte per Alexa steuerbar...

Gruß, Joachim

[FHEM_ASB]

Vielen Dank. Mir war nicht klar, das HMIP ausschließlich mit einer CCU betrieben werden kann. Dann verstehe ich auch, warum viele auf HM ohne IP setzen. Ich habe leider keine VCu, sondern den Access Point. Der dürfte dann wohl nicht ausreichen.

[MadMax-FHEM]

Ich kenne jetzt den "Accesspoint" nicht.
Habe aber eben mal bei ELV geschaut: wird wohl nicht klappen diesen einzubinden.

Und es ist damit wohl/vermutlich so, wie Neuhier geschrieben hat: ohne Cloud (und die war schon immer wieder mal einige Zeit [Stunden/Tage] weg) geht dann wohl nicht mehr viel...

Aber wenn du weiterhin eher HM-IP einsetzen willst und auch fhem, dann wirst du wohl an einer CCU (evtl. selbstbau "Charly" https://www.elv.de/homematic-funk-modulplatine-fuer-raspberry-pi-3-rpi-rf-mod-komplettbausatz.html bzw. https://www.elv.de/elv-smart-home-zentrale-charly-starter-set-bausatz.html) vorbei kommen.

Hinweis: vccu ist hat NICHTS mit CCU zu tun!

Gruß, Joachim

[Beta-User]

@Joachim:Bist du sicher, dass nur der Charly für eine CCU funktioniert? Nach meinem Kennstnisstand sollte eine (ggf. z.B. mit piVCCU) virtualisierte CCU auf demselben Rechner auch mit dem "alten" PI-PCB laufen, ohne dass man wesentliche Nachteile hat. Die Behauptung von eQ-3, das Ding habe eine bessere Funkleistung wurde jedenfalls neulich mal von jemandem getestet und hat die Stichprobe nicht bestanden . (eQ-3 halt, wage ich mal zu behaupten...) (und piVCCU ist auch was anderes als VCCU!)

Insgesamt bin ich aber auch kein Freund von HM-IP und würde eher zu ZWave raten. Kommt aber darauf an, was du schon hast und ob es Geräte gibt, die den angedachten Zweck auch erfüllen (Alternativen für FB-Heizung war schwierig).

@TE:
Überhaupt: Nimm dir den Zoo vor, den du bereits hast und schau bei jedem Gerät (insbesondere den Schnittstellen wie z.B. HUE-Bridge), ob das nicht direkt unterstützt wird. Dürfte einfacher sein, als jedes Mal das Rad neu zu erfinden...

[Wetterhexe]

FHEM und CCU auf einem raspi parallel würde ich nicht betreiben, schon allein wg. performance.

Die HomeMatic Komponenten (OHNE IP) könntest du auch direkt an fhem anbinden...
...aber ich würde da nicht mischen: also HMohneIP an fhem und HMmitIP dann an CCU und per HMCCU in fhem...
...sondern gleich alles an die CCU und dann per HMCCU-Modul in fhem.

Mischbetrieb läuft seit einigen Wochen bei mir im Echtbetrieb ohne Probleme. Ok ich war zu faul >80 devices ab- und wieder anzulernen, und Dutzende notify's zu ändern

Soweit mir bekannt läuft HomeMatic IP mit CCU auch lokal ohne Internet und Cloud...
...aber da vielleicht noch mal im Internet recherieren (habe kein HomeMatic IP).

ja das geht, nur das anlernen von neuen Komponenten ist mühsam (benötigt KEY und SGTIN, wird beides mitgeliefert). Mit Internet ist es ein Tastendruck. Cloud brauchts dafür keine

Ich lese grad (noch mal): du hast ja schon eine HMIP-Zentrale!? CCU2/CCU3? Die dann "einfach" per HMCCU-Modul in fhem einbinden...

der HmIP Hub geht nicht mit FHEM, er braucht eine CCU

Ich habe lange überlegt ob ich HmIP einsetze oder doch lieber zwave. HmIP hat aber mittlerweile Komponenten die ich schon länger haben wollte, (zB. BSL oder SPDR), die gibts bei keinem anderen System

[Beta-User]

FHEM und CCU auf einem raspi parallel würde ich nicht betreiben, schon allein wg. performance.

Es scheint einige zu geben, die das so nutzen, kommt wohl auf den Anwendungsfall an. Würde eh' grundsätzlich überlegen, ob es wirklich ein Pi sein soll (ein OCCU-Container sollte auch auf einer x86-Hardware laufen und man ist alle Performance-Themen und die SD-Karte tendenziell los, muß das PCB dann halt an einen USB-Seriell-Wandler ranbasteln).

Wenn man aber einsteigt und bisher keine CUL_HM-Devices hat, würde ich eher vom Mischbetrieb abraten (bin wie gesagt aber gar kein CCU-Freund! HM_CUL ist super, wenn man nur BidCoS einsetzt...).

Irgendwo gab es auch ein script, um den HmIP-Hub einzubinden, ist aber eine Variante, die vermutlich nicht den Aufwand lohnt (cloud-Abhängigkeit und dann ein wenig genutzes script...).

[Wetterhexe]

Würde eh' grundsätzlich überlegen, ob es wirklich ein Pi sein soll (ein OCCU-Container sollte auch auf einer x86-Hardware laufen und man ist alle Performance-Themen und die SD-Karte tendenziell los, muß das PCB dann halt an einen USB-Seriell-Wandler ranbasteln).

also ich mag Pi's, aber FHEM würde ich auch nicht drauf laufen lassen (hab ich auf x86). Spätestens mit Grafana/mysql ist ein Pi sowieso überfordert.

Pi und SD-Karte ist nicht die große Liebe, da hab ich im Lauf der Jahre auch einiges verschlissen. Deswegen unbedingt mit einem vollautomatischen (und überwachten!) backup und getestetem(!) restore.
Vor zwei Wochen hats eine SD-Karte gegrillt, nach 1 Std. war alles wieder up.

[MadMax-FHEM]

@Beta-User:

jaja hast schon recht es geht das "alte" Modul auch für eine CCU dann aber eher CCU2, oder!?

Mit dem neuen ist es ja dann quasi Charly also CCU3...

Bin aber bzgl. HomeMatic nicht so tief drin, wenn es drum geht: CCU und HMCCU...
...ich habe alle HomeMatic die ich habe direkt per HM-CFG-USB / HM-PCB an meinen Systemen...

@Wetterhexe & Beta-User:

Ich habe auch schon oft gelesen, dass beides auf einem PI wohl gut läuft.
Habe allerdings keine Ahnung wie groß die Installationen jeweils sind/waren.

Ich selbst würde auch nicht zu viel auf eine HW packen...
...noch dazu wenn (evtl.) ein "spezielles" (angepasstes) Linux drunter läuft/laufen muss...

Zu viele evtl./mögliche Probleme mit Abhängigkeiten...

Und wenn mal eines der beiden Systeme die Grätsche macht (z.B. weil ein Update etc. "Müll" ist) muss man (meist) gleich alles neu aufsetzen...

Gruß, Joachim

[Beta-User]

Keine Ahnung was CCU2/CCU3 angeht. So wie ich das verstanden habe, ist eine CCU3 halt eigentlich ein Pi3 (bisher: irgendwas lahmes anderes) - damit soll (?) der Kritik begegnet werden, die CCU2 wäre lahm...
Spielt alles m.E. keine Rolle, wenn man eine potente Plattform drunter legt . Ob das Funkmodul groß anders ist?

Was das Einrichten usw. angeht: Man erkauft sich halt immer beide Seiten der Medaille: Entweder nur ein Gerät (ohne z.B. zu große Abhängigkeit vom LAN/Router, dafür aber komplexer) oder eben zwei zu wartende Geräte.

Aber wie man das am besten aufzieht: k.A., OCCU gibt's z.B. als Docker (?).
Meine persönliche Device: Hände weg von eQ-3 und ganz speziell von HM-IP (ich sag' nur: Kondensatoren, und für tolle firmware sind die auch nicht berühmt...). Deswegen für Anfänger eher was, was "direkt" geht => ZWave, z.B.....

Just my2ct

[FHEM_ASB]

So, wollte mich mal melden und Feedback geben. Habe nun als Hardware einen Rasperry B+ mit RPI-RF-MOD am laufen. Als Software laufen piVCCU3 und FHEM. Läuft bislang bestens, ist aber natürlich nicht ansatzweise ausgelastet. Habe testweise einige HM sowie HMIP Geräte bei Qivicon abgemeldet und an der piVCCU angemeldet. Bin zuerst erstaunt über die Optionsvielfalt der Geräte.

Nächster Schritt, FHEM soll genutzt werden, Ziel sind Technoline Sensoren, Schaltsteckdosen sowie die Schellenberg Rollladensteuerung. Allerdings scheint es dafür kein Steuerungsmodul zu geben. Werde erstmal einen Cul bestellen und weitersehen. Vielen Dank an euch

[Prof. Dr. Peter Henning]

Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).

LG

pah

[gloob]

Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).

LG

pah

Für den Raspbee von Dresden Elektronik kann man auch wunderbar einen Raspberry Pi Zero nehmen. Schön klein und das Modul steckt einfach oben drauf.

[Beta-User]

Für den Raspbee von Dresden Elektronik kann man auch wunderbar einen Raspberry Pi Zero nehmen. Schön klein und das Modul steckt einfach oben drauf.

Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).

...und dabei immer dran denken, dass man jeweils die gesamte Software (insbesondere das OS) stets aktuell hält .

[Guzzi-Charlie]

Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).

LG

pah

Hallo,
Ich bin auf der Suche nach Tips und Antworten auf diesen alten Beitrag gestoßen. Ich habe ähnliche Vorstellungen einer Zusammenarbeit von FHEM und Homematic IP auf EINEM RasPi.

Ich habe aktuell ein FHEM-System mit verschiedenen Ankopplungen (Jeelink, One-Wire, MQTT2, etc. am Laufen). Jetzt soll der neue Fußbodenheizungsaktor "https://www.elv.de/homematic-ip-fussbodenheizungsaktor-12-fach-motorisch-hmip-falmot-c12.html" hinzukommen (und NUR der, keine weiteren HM- oder HMIP-Geräte) und diesen möchte ich dann per HMCCU-Modul einbinden. Von Homematic habe ich bisher überhaupt keine Ahnung, deshalb könnte ich ein wenig Unterstützung bei den folgenden Fragen gebrauchen damit ich wenigsten weiß das ich auf dem richtigen Weg bin. Wenn ich das was ich bisher gefunden und gelesen habe richtig verstanden habe dann sollte doch die folgende Konfi funktionieren, oder?

- RasPi 3+ auf dem FHEM und piVCCU3 läuft
- Als Funkgateway zu den HM-Aktoren der USB-Stick "https://www.elv.de/elv-homematic-ip-rf-usb-stick-hmip-rfusb-fuer-alternative-steuerungsplattformen-arr-bausatz.html/bereich/-3"
- Als Verbindung zu FHEM dann das HMCCU-Modul

Ist das so machbar und/oder sind dabei irgendwelche grundsätzlichen Probleme zu erwarten?

[Ralph]

Moin, auch ich wecke das hier nochmal auf, weil ich nichts passenderes fand.

.... Ich habe ähnliche Vorstellungen einer Zusammenarbeit von FHEM und Homematic IP auf EINEM RasPi.

Sowas schwebt mir auch vor.
Grund: Erweiterung / Aufstockung - habe vieles Altes, das gut läuft, aber manches ist nicht mehr greifbar und Neues gibts ja auch.

Habe heute laufend:
FS20, FS20V, HMS, WS_THs, WS_SD; FHTs, SignalDuino 433 mit IT und Flamingos, HM (ohne IP) mit VCCU und Modulplatine, alles mit FHEM auf RasPi 3+

Wunsch ist: HomeMatic IP - Komponenten sollen auch verwaltet und bedient werden, das "alte" muss und soll aber weiterlaufen.

Problem: es gibt wohl viele Wege, wovon ich keinen vollständig verstanden habe, und nun suche ich Rat.

Was muss ich wie mit was umbauen / installieren? Bitte als Kochrezept für Doofe.

Ich denke, das wird über kurz oder lang auf Alle zukommen.
Es gibt ja schon heute Komponenten Homematic (ohne IP) schon nicht mehr.
Von älteren will ich schon gar nicht mehr reden.
Ausflüge in andere Welten wie Shelly sind bei mir schon kläglich gewscheitert.

[Beta-User]

Wunsch ist: HomeMatic IP - Komponenten sollen auch verwaltet und bedient werden, das "alte" muss und soll aber weiterlaufen.
[...]
Ich denke, das wird über kurz oder lang auf Alle zukommen.

Zu HM-IP hat Horti dankenswerterweise alles hier zusammengefaßt:
https://forum.fhem.de/index.php/topic,116424.0.html

Ansonsten ist es vermutlich schon so, dass HM-Classic (bis auf den Selberbau-Bereich) mittelfristig tot ist, aber an HM-IP als echte Alternative glaube ich persönlich nicht, und das ZigBee-Zeug ist für Sensorik ziemlich gut und Beleuchtung häufig (fast) alternativlos, wenn man kein WLAN-Gedöns will, aber perfekt ist m.E. weder zigbee2mqtt noch deconz (CC253x-basierte Coordinator sollte man aber wirklich nicht mehr kaufen).

Ausflüge in andere Welten wie Shelly sind bei mir schon kläglich gewscheitert.

Das perfekte System gibt es nicht, und wenn das WLAN-Zeug (mit MQTT2-Modulen oder dem Shelly-Modul) schon in der Einarbeitung zu schwierig ist, bin ich sehr in Zweifel, was dann eine empfehlenswerte Alternative sein soll. M.E. ist derzeit CUL_HM kaum an Komfort zu schlagen (HUEDevice ist ähnlich einfach, aber die dahinterliegende Technik ist es eben nicht in gleichem Maße).

[Ralph]

Uff, bei #17 und #18 habe ich erstmal heftig ein- und ausgeschnauft.

FS20 kann ich nicht abschaffen aus 2 Gründen:
1.) es steckt zuviel Geld drin.
2.) auf FS20V kann ich wegen zahlreicher Batterie-Überwachungen nicht mehr verzichten. Eine Alternative dazu fand ich noch nicht.

Mit MQTT bin ich sowas von heftig auf die Schnauze gefallen, dass ich aus Backups re-installieren musste.

In

Zu HM-IP hat Horti dankenswerterweise alles hier zusammengefaßt:
https://forum.fhem.de/index.php/topic,116424.0.html

werde ich mich einlesen. Liest sich schonmal gut.

Ohne es zu kennen gefällt mir debmatic aus den Empfehlungen schon mal ganz gut.

Die HUE-Lichtorgien brauche ich nicht.

Euch danke ich für die Aufmerksamkeit und die Vorschläge.
Bis neulich ....

[frank]

Ich auch nicht, aber manche Lampen sind alternativlos. Alte Lampe raus, neue Lampe rein, fertig. Kein Zwischenstecker, kein Zwischensockel o.ä.

aber alle vorhandenen lichtschalter werden sinnlos, oder? 

[Beta-User]

Sorry @Ralph,

wollte dich nicht erschrecken oder gar angreifen.

Ich hätte beim Einstieg auch nie vermutet, dass ich mal so einen bunten Zoo beieinander haben würde (für Sensorik gibt's auch noch Bluetooth...).

Manches habe ich mir auch nur angetan, um eben solche Fragen halbwegs fundiert beantworten zu können.

Warum es mit MQTT so ein Fiasko war, würde mich interessieren. Weniger, weil ich Werbung für das WLAN-Gedönse machen will, sondern eher, weil mich interessiert, wie man ggf. diese Dinge besser erklären kann. Es ist zugegebenermaßen verwirrend, dass es so viele Module gibt und man zum Einstieg erst mal wissen muss, dass man schlicht einen MQTT2_SERVER mit global definieren muss, damit vieles fast von alleine geht, aber das feedback fast aller "Umsteiger" von MQTT-"alt" zu den MQTT2_.*-Modulen fanden es sehr viel einfacher, und die, die es direkt gemacht haben, waren in der Regel auch schnell produktiv mit ihren Geräten.

Aber auch hier: sowas sollte man erst mal in einer Testinstallation kennenlernen, ein zweiter (ggf. nicht so leistungsfähiger) Pi als Testsystem ist auf alle Fälle eine gute Idee.

@kpwg: Es gibt auch Leuchtmittel für Standardfassungen in ZWave. Die sind nur leider unverhältnismäßig teuer...

aber alle vorhandenen lichtschalter werden sinnlos, oder? 

Na ja, da spielt auch die Gewohnheit stark rein (das Abschalten von Leuchtmitteln macht ZigBee als Mesh aber zugegebenermaßen nicht unbedingt zuverlässiger... Wobei ich die meisten Probleme mit einer Bulb habe, die ziemlich nahe am IO sitzt und "immer on" ist - "Gruscht" vom gelben Möbelhaus halt...)

[Ralph]

Keine Angst, trotz meines Alters werde ich es überleben.
Aber digitale Einläufe verarbeite ich zunehmend langsamer.

Mich hat an FS20 die fehlende Rückmeldung gestört

Mich auch. Aber alle (sich) nicht automatisch / zyklisch meldenden Teile sind schon raus.
Auf FHT(TK)s und TH300 braucht man ja nicht zu verzichten, einer misst bei mir bis -22°C in der TK-T.
An Aktoren habe ich nur noch optisch sichtbare, da kommt die Rückmeldung über die Augen.

Bei MQTT muss ich mich irgendwie verstrickt haben auf Linux-Ebene, plötzlich ging gar nix mehr, ich war in einer Loop.
Keine Ahnung. Wenn ich das gewollt hätte, dann wäre mir das gewiß nicht gelungen.

Ich habe einen 2ten RasPi, der wird gequält.

Seid gewiß, ich werde noch viele Fragen haben ...

[Wernieman]

Wieso, ist doch eine berechtigte Frage?

[frank]

Ich halte eher den Kommentar für sinnlos. Genau das brauchen wir hier...

was soll das jetzt?

wenn ich so eine bulb, mit eingebautem aktor, in meine bestehenden lichtkreise einschraube, verlieren alle vorhandenen schalter dieses lichtkreises ihre funktion.

schlimmer noch. ich muss sogar alle lichtschalter totlegen und umbauen, damit die bulb dauerspannung bekommt.

zusätzlich muss ich für jede schaltstelle neue sender (schalter) besorgen und einbauen.

jetzt fängt das "chaos" an.
vom selben hersteller gibt es in der regel keine sender, bestenfalls fernbedienungen.
wenn ich beta-users threads so verfolge, gibt es viele sender aus fernost, die eventuell nicht vom gateway unterstützt werden.

man braucht also schon mal das "richtige" gateway, scheinbar conbee2, um die grösst mögliche wahrscheinlichkeit zu haben, dass ein sender auch nutzbar wird.
dazu dann noch ordentlich software zum konfigurieren der devices. scheinbar sehr umfangreich, so dass ich sogar wahrscheinlich einen zusätzlichen pi bräuchte.

alles in allem empfinde ich zigbee als grosses experimentierfeld, nach meinen bisherigen recherchen.


da finde ich es eigentlich schon "frech" von dir, zu behaupten, man bräuchte nur die bulb zu wechsen, und fertig.
und das noch zu jemandem, der schon sagt, dass er probleme mit shellys hat.


gruss frank

[Beta-User]

Ich halte eher den Kommentar für sinnlos. Genau das brauchen wir hier...

Ich halte den Kommentar ausdrücklich nicht für sinnlos. Man sollte sich nämlich bei ZigBee (und anderen Mesh-Systemen) schon überlegen, wie man es haben will, um bestimmte Probleme zu vermeiden!

Da gibt es tatsächlich eine Fraktion, die das komplette Stilllegen der alten "analogen" Schalter befürwortet (ganz ähnlich wie das bei MiLight der Fall war/ist). Bin noch nicht abschließend zu einem Fazit gelangt, aber bisher habe ich mich dagegen entschieden, Schalter usw. stillzulegen.

Hier mal meine _vorläufige_ Meinung zu den Thesen von frank:
- Schalter werden nicht funktionslos. Alle Bulbs, die ich bisher "irgendwo" gekauft habe, lassen sich "klassisch" einschalten, wenn man die _immer_ klassisch über die Stromzufuhr ein- und ausschaltet. "Seltsam" fühlt es sich nur an, wenn die softwaremäßig aus waren, weil man dann über den "klassischen Schalter" 2x schalten muss, nämlich Stom weg/Strom an, damit sie angehen. Man sollte also entscheiden, ob man bestimmte Ecken mit Schalter oder "anders" bedienen will.
- Bulbs ohne ständige 230V dienen aber nicht mehr als Repeater im Mesh, was das uU. aus dem Tritt bringen kann. Ich kann dazu noch nichts abschließendes sagen, weil der "schaltbare" Teil meiner Bulbs etwas abseits untergebracht ist und z.B. die Sensorik daher sowieso über den "immer on"-Teil des Mesh läuft.
- Ganz ohne Schaltoption (außerhalb des Schaltschranks) mag ich das eigentlich nicht haben, weil ich mind. eine (dauerbestromte) Bulb habe, die sich immer mal wieder "weghängt" und dann "hart" aus- und wieder angeschaltet werden muss. Das ist in dem Fall kein großes Problem, weil da ein Bewegungsmelder mit Schiebeschalter für "off" davor hängt, aber es sorgt immer mal wieder für Irritationen, dass das Ding halt nicht bewegungsmeldergesteuert angeht, wenn es sich weggehängt hat. Vermutlich ist das aber eher ein Defekt an dieser einen Bulb, und ich sollte die schlicht austauschen .

- "Mein Thread" ([unboxing], und vermutlich auch die zu opple und dem Jung) ist/sind nicht unbedingt representativ, weil ich (jeweils) relativ früh halt "irgendwelches Zeug" gekauft habe, um damit rumzuexperimentieren. Grundsätzlich ist ZigBee hochgradig standardisiert, und das meiste (auch unbekanntes Zeug), das sich an die Standards hält, wird auch erkannt. Das ganze mit zigbee2mqtt und deconz jeweils, ohne dass man (abgesehen vom Interface selbst) zusätzliche Hardware bräuchte. Und die verfügbare (und unterstützte) Hardware nimmt stetig zu, so dass man zunehmend auch Geräte für "spezielle Fälle" wählen kann, ohne (!) in eine Falle zu laufen.

- zigbee2mqtt war - als ich es noch genutzt habe - schon ziemlich cool und extrem schnell in der Integration von "allem möglichen", und in Kombination mit MQTT2_SERVER und MQTT2_DEVICE/attrTemplate ist es eigentlich auch sehr "easy" in der Integration in FHEM. Es fehlt eventuell noch ein attrTemplate für HUE-Lichttypen, aber sonst gibt es nichts, was man vermissen würde - sogar Selbst-Bau-Devices (derzeit nur) auf CC2530-Basis sind (mindestens damit (!)) möglich!

- deconz bringt für "ausgereifte" Devices mit phoscon eine sehr anwenderfreuntliche "App" mit und ist mit den HUE.*-Modulen sehr gut in FHEM integriert. Doku für spezielle Fälle könnte man eventuell verbessern, aber ansonsten ist DAS DIE Einsteiger-Lösung schlechthin, vorausgesetzt, man beschränkt sich auf die Hardware, die als "funktionierend" bekannt ist.

"Mankos" von ZigBee (neben dem 230V-Schalter-Thema):
-- Wie die Verknüpfungen zwischen den Geräten laufen, ist manchmal etwas dubios, und für "mache das Licht bei Bewegung nur an, wenn es dunkel ist" braucht man zwingend einen laufenden Server (ist wohl bei allen ZigBee-Lösungen so; das können derzeit nur - neben BidCoS-Geräten - manche (!) ZWave-Geräte (von einem Steinel kann ich das jedenfalls bestätigen) ).
-- 2.4GHz
-- HUEDevice bildet eine Hardware uU. auf mehrere Channel-Devices ab, deren innerer Zusammenhang nicht immer einfach zu erkennen ist (da ist zigbee2mqtt "einfacher").
-- "echte" Schalterprogrammintegration ist ohne Bastelei eher (noch) die Ausnahme. Würde aber wetten, dass irgendwann die Chinesen neben dem europäischen Dosenmaß auch irgendwann die Bedeutung des "55-er"-Maßes erkennen werden.

Ergo ist die verkürzte Schreibweise "Tausche die Bulb, und gut ist...!" eigentlich eine legitime Rückmeldung an jemanden, der mit der früheren (!) MQTT-Implementierung Schwierigkeiten hatte. Jedenfalls würde ich wetten, dass HUEDevice bzw. MQTT2_.* tendenziell einfacher zu verstehen und einzurichten ist wie HMCCU.*, und anders als dort "braucht" man weder einen Pi noch irgendwelche Spezialplatinen, sondern kann das an jeder x64-Hardware per USB-Dongle zum laufen bringen auf dem "einfachen" debian-way!

Aber nochmal auch der deutliche Hinweis: Perfekt ist anders!

[MadMax-FHEM]

"Mankos" von ZigBee (neben dem 230V-Schalter-Thema):
-- Wie die Verknüpfungen zwischen den Geräten laufen, ist manchmal etwas dubios, und für "mache das Licht bei Bewegung nur an, wenn es dunkel ist" braucht man zwingend einen laufenden Server (ist wohl bei allen ZigBee-Lösungen so; das können derzeit nur - neben BidCoS-Geräten - manche (!) ZWave-Geräte (von einem Steinel kann ich das jedenfalls bestätigen) ).
-- 2.4GHz
-- HUEDevice bildet eine Hardware uU. auf mehrere Channel-Devices ab, deren innerer Zusammenhang nicht immer einfach zu erkennen ist (da ist zigbee2mqtt "einfacher").
-- "echte" Schalterprogrammintegration ist ohne Bastelei eher (noch) die Ausnahme. Würde aber wetten, dass irgendwann die Chinesen neben dem europäischen Dosenmaß auch irgendwann die Bedeutung des "55-er"-Maßes erkennen werden.

Hier kann ich nur zustimmen!
Die Schalterei/Verknüpferei ist mir auch immer noch ein Rätsel (also bei Zigbee / also wann geht es OHNE Bridge [in meinem Fall deCONZ] und wann muss sie laufen / experimetiere da immer noch mit einem Testsystem rum)...

ABER: ich habe mittlerweile eine brauchbare (so hoffe ich: Test steht noch aus) ZigBee-Schalter-Lösung gefunden https://hueblog.com/2020/09/09/not-quite-official-in-wall-switch-with-friends-of-hue-technology/ und es gibt wohl auch (zumindest für mein Schalterprogramm Gira) ähnliches wie bei EnOcen (und mittlerweile wohl auch ZWave) auch für ZigBee, Schalter/Taster die die Energie aus dem "Drücken der Taste nehmen"...

Zuvor hatte ich ja mehrfach (nicht erfolgreich) versucht eine Ikea-Tradfri-FB "umzubauen" (also ohne Batterie und verbunden mit "normalem" Schalter/Taster)...
https://forum.fhem.de/index.php/topic,96578.msg896341.html#msg896341

Weil genau das: fehlende SCHALTER bzw. "Sender" die unter/hinter einen vorhandenen Schalter (oder wenigstens Taster) funktionieren OHNE Batterie ist echt schwer zu finden und hat mich "abgeschreckt" mehr als ein paar "Dekolichter" im Wohnzimmer auf ZigBee "umzurüsten"...

Gruß, Joachim

[frank]

hi beta-user, danke für die hinweise.

- Schalter werden nicht funktionslos. Alle Bulbs, die ich bisher "irgendwo" gekauft habe, lassen sich "klassisch" einschalten, wenn man die _immer_ klassisch über die Stromzufuhr ein- und ausschaltet. "Seltsam" fühlt es sich nur an, wenn die softwaremäßig aus waren, weil man dann über den "klassischen Schalter" 2x schalten muss, nämlich Stom weg/Strom an, damit sie angehen. Man sollte also entscheiden, ob man bestimmte Ecken mit Schalter oder "anders" bedienen will.

ok, das ist ja schon etwas besser, als bisher gedacht.

doppeltes einschalten kann für den systembetreiber ja ok sein, aber dritten möchte ich das nicht zumuten wollen.
wenn ein gast nachts aufwacht, muss sichergestellt sein, dass er intuitiv licht einschalten kann.

schlaftrunken in einem fremden zimmer bei rauchmelderalarm aufzuwachen und einen lichtschalter zu finden, kann schon eine herausforderung sein. dann sollte dieser auch "normal" und sicher funktionieren.


allerdings bleibt auch das entscheidende manko, dass eine über den klassischen schalter ausgeschaltete bulb nicht mehr über gateway einschaltbar ist.

automatisierungen sind also glückssache, abhängig von der schalterstellung. genau genommen sind nur automatische on-schaltungen glückssache.


bisher sehe ich die zigbee lichtsysteme bestenfalls als zusätzliche "deko"-beleuchtung.


gruss frank

[Wernieman]

Im Grunde sehe ich solche Mischsysteme (Egal welches Produkt) genau deshalb als Problematisch. Man hat 2 Unabhängige Möglichkeiten, es ein/auszuschalten, die sich dann auch gegenseitig beharken. Es sollte nur einen "Kommunikationsweg" gehen. Und das schalten sollte auch unabhängig von einer Zentrale funktionieren.

[Beta-User]

doppeltes einschalten kann für den systembetreiber ja ok sein, aber dritten möchte ich das nicht zumuten wollen.

fully agreed!

Sehe zwei Auswege:
Entweder man ersetzt den ursprünglichen Schalter durch einen "immer-on" Taster - da wissen die meisten, dass man den ggf. wieder loslassen muss, kann aber darüber nicht ausschalten (aber man hat "Licht", um den "software"-Taster zu finden).

Oder man packt einen ZigBee-Aktor hinter den Schalter; auch da gibt es zwischenzeitlich Lösungen (sogar "without neutral"). Man muss da nur aufpassen, dass die Schaltleistung passt, aber für Licht reicht es in der Regel...
Dann hat man allerdings entweder ein "dummes" Leuchtmittel oder wieder die Situation, dass zwei hintereinandergeschaltete "smarte" Elemente irgendwie unschön sind. Aber man könnte dann z.B. mit einem zwei-kanaligen Aktor einmal den Schalter abfangen (=> Event für die Bulb-Steuerung) und den 2. Kanal für die Notabschaltung nehmen...
(Das ganze ist aber bei allen Systemen ein Problem und nicht ZigBee-Spezifisch).

Im Grunde sehe ich solche Mischsysteme (Egal welches Produkt) genau deshalb als Problematisch. Man hat 2 Unabhängige Möglichkeiten, es ein/auszuschalten, die sich dann auch gegenseitig beharken. Es sollte nur einen "Kommunikationsweg" gehen. Und das schalten sollte auch unabhängig von einer Zentrale funktionieren.

Auch hier: volle Zustimmung. Deswegen sind die Schalter noch dran und das ganze nur da im Einsatz, wo man sich normalerweise nur aufhält, wenn man halbwegs bei Bewusstsein ist . Außerdem wird eben da gewohnheitsmäßig auch per 230V-Schalter ausgeschaltet...
Emotional hätte ich jetzt kein großes Problem mehr, z.B. an den Stellen, an denen heute ein ZWave-Aktor sitzt, einen in ZigBee einzubauen. HM kam da übrigens nicht in Frage, weil ich dann die ganzen Schalter in Taster hätte wechseln müssen, und in ZigBee gibt es das (bezahlbar) noch nicht so lange. Das mit den Tastern werde ich evtl. aus optischen Gründen noch nachholen, aber das ist ein ganz anderes Thema und hat auch was damit zu tun, dass man dann gleich noch einen Scene-Controller hat...

Klar ist nicht einschaltbar, was "offline" ist, aber immerhin weiß das deconz und FHEM (und bei zigbee2mqtt kann man FHEM wissend machen).

Was Sensorik angeht, ist ZigBee übrigens m.E. kaum zu schlagen. Insbesondere das Xiaomi-Zeug ist günstig, recht genau, batterieschonend und ziemlich zuverlässig, und aus dem Augenwinkel habe ich wahrgenommen, dass es zwischenzeitlich sogar Temp/Hum-Sensoren mit Display  gibt (bisher nur BTLE, die aber ebenfalls m.E. gut zu gebrauchen sind). Dazu vergleichsweise "optisch ok" und v.a. der Bewegungsmelder ist funktional gelungen: guter Erfassungsbereich, superpraktisch, was die Anbringung und Ausrichtung angeht und recht klein. Das einzige, was ich "vermisse", ist diese "sende an peer, wenn dunkel"-Geschichte...