[doch ungelöst] deCONZ und div. Scene-Controller => Amnesie...?

Begonnen von Beta-User, 13 November 2019, 23:20:54

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

bin etwas verloren, was die effektivste Vorgehensweise wäre, um folgendes zu erreichen:

Eine Wohnküche mit (die ersten paar alle ZigBee, vom Server allerdings nur über mind. eine Router-Station zu erreichen, die tradfris sind gruppenweise unterschiedliche Typen):
- einer 2-er Gruppe von Leuchtmitteln über dem Esstisch (tint)
- einer 2-er Gruppe von Leuchtmitteln an einer Wand (tradfri)
- einem Leuchtmittel über der Spüle (tradfri)
- einer 2-er Gruppe von Leuchtmitteln über einem Durchgangsbereich (tradfri)
(+ potentiell noch:
2 weiteren LM-Gruppen (ZigBee denkbar), eine weitere Einzelleuchte + Dunstabzug (beide schaltbar mit 433MHz))

Vorhanden sind zwei Schalter-Batterien (im Zugangsbereich und im Küchenbereich).
Bisher waren in der Wohnküche hauptsächlich MiLights verbaut, Ein- und Ausschalten erfolgte fast ausschließlich über die Schalter (Spannung wegschalten, was für MiLights "na ja" ist...). Jetzt wollte ich die MiLights gegen diverse ZigBee-Leuchten tauschen (bisher vorhandene Gruppen: s.o.) und die Schalter tendenziell funktionslos machen (also die Leuchtmittel mit Dauerspannung versorgen) und das ganze dann an der Hauptschalterbatterie mit einem Jung-8-fach-Taster (ZLLCD5004M) "familienfreundlich" am bekannten Ort schaltbar (und optimalerweise dimmbar) machen (und evtl. weitere ZigBee-Taster vom blauen "Möbelhaus" an den Orten anbringen, wo es Sinn macht (über der Spüle, z.B.).

Dabei war der Plan, jeder LM-Gruppe an dem zentralen Jung-Schalterfeld am Eingang eine Taste für an/aus und dimmen zuzuordnen, das für ZigBee in Hardware zu organisieren, damit es in jedem Fall schnell geht und v.a. auch ohne laufenden FHEM/deCONZ-Server und ggf. für die "Spezialfunktionen" noch über FHEM indirekte Eventhandler zu basteln; falls jemand Farbe haben will, wäre das dann auch indirekt über die MiLight-FB (FHEM) möglich.

Für die ersten zwei Gruppen klappte der ZigBee-Teil recht problemlos (das obere Tastenpaar), man kann zwei Gruppen schalten und dimmen, das ganze ist mit der Gruppenfunktion in phoscon ja komfortabel einzurichten.

Gut, dachte ich und habe das nächste Tastenpaar dann für zwei weitere phoscon-Gruppen konfiguriert. Leider gab's da schon kein an+hochdimmen/aus+runterdimmen mehr im Konfigurationsangebot einzelner Tasten  :( .

Das ginge ja grade noch, aber beim Rumtesten mußte ich dann feststellen, dass das ganze plötzlich mit teils unerträglichen Latenzen verbunden war :o . Dabei scheint es keine große Regeln zu geben, nach denen die Latenzen auftreten (oder eben auch nicht). Kann (gefühlt) bis zu 15 Sek. ausmachen, wobei die Tendenz zu sein scheint, dass mehr Schaltvorgänge den Effekt begünstigen, v.a., wenn man Tasten gedrückt hält zum Dimmen...
Nachdem das hier weitestgehend geschrieben war, habe ich das eben nochmal ausgetestet: Jetzt ging's ganz überwiegend zackig, max. ein paar 100stel Sekunden, aber manches will auch nicht. Z.B. die Gruppe auf Taster 2 reagiert nicht auf "gedrückt-halten" wenn ausgeschaltet, und so richtig befriedigende Dimmläufe (von ganz hell nach ganz dunkel und umgekehrt) kann man auch nicht beobachten....

Hat jemand ähnliche Erfahrungen gemacht und einen Tipp, was man da machen kann? Beruhigt sich das von alleine?

Kann man sowas besser mit  Szenenfunktionen (in phoscon) lösen statt der klassischen Zuordnung 1 Taste <=> eine LM-Gruppe?

Bin für jeden Tipp dankbar...

Gruß, Beta-User
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

Beta-User

Drama zweiter Teil zur Info:

Gestern abend dann alles via Insta/Jung-Taster ausgeschaltet. Heute morgen dann versucht, die Hauptgruppe zu schalten => Fehlanzeige...
Dann alle anderen getestet => nix geht.
Strom weg, wieder eingeschaltet => via Jung-Taster geht immer noch nichts >:( .

Der Jung-Taster scheint also unter Amndesie zu leiden. Der (eckige) Ikea-Taster-Dimmer, den ich danach angelernt hatte und mit der bulb über der Spüle verbunden hatte, funktioniert problemlos, es lassen sich auch alle Leuchtmittel via FHEM oder phoscon schalten.

Das Problem scheint also der Jung-Taster zu sein.  >:( >:( >:(
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

eisenhauer1987

Hi,

ich kann deine Probleme nicht nachvollziehen. Ich habe seit mehreren Wochen einen Jung ZLL A 5004 M an einem ConbeeII quasi problemlos im Einsatz. Das einzige Problem ist, das nach dem Dimmen für ca 1s kein weiterer Schaltbefehl akzeptiert wird. Dieses Szenario ist aber auch eher theoretischer Natur. Im Normalfall liegt die Reaktionszeit immer unter einer halben Sekunde. Die Lichter werden direkt in Phoscon geschalten. Ich schalte aber auch Rolläden über fhem.

Beta-User

Danke erst mal für die Rückmeldung.

Nach dem Dimmen kurz zu warten wäre kein Problem...

Fragen:
Nutzt du den Jung für ein Leuchtmittel (bzw. eine Gruppe) oder auch mehrere Tasten für mehrere Leuchtmittelgruppen (jeweils mit der Gruppenfunktion in phoscon)?

Hast du auch Routergeräte zwischen den Conbee II und dem "Ort des Geschehens"?

Was das hier angeht:
Zitat von: eisenhauer1987 am 14 November 2019, 10:02:14
Die Lichter werden direkt in Phoscon geschalten.
Bisher war mein Verständnis von ZigBee, dass das nach dem Anlernen gar nicht mehr über die App läuft, die wird (wenn sie läuft) nur informiert, dass ein Schaltvorgang stattgefunden hat, und bekommt ggf. auch das FB-Signal - das scheinst du ja (für nicht "assoziierte" (ZWave-Sprech) / "gepeerte" (HM-Sprech) Tasten) zu nutzen, um Rollläden zu steuern.
Habe ich das was falsch verstanden, was die Funktionsweise von ZigBee angeht?
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

eisenhauer1987

#4
Hi,

also ich nutze den Taster wie folgt in Phoscon konfiguriert:

Konfig in Gruppen:

Links                                   Reihe           rechts
Kurz drücken gruppe 1 aus       1             kurz drücken szene in gruppe 1 vor
Kurz drücken gruppe 2 aus       2             kurz drücken szene in gruppe 2 vor
Kurz drücken gruppe 3 aus       3             kurz drücken szene in gruppe 3 vor

Konfig des Schalters:

Reihe 1 dimmt bei lamgen druck die aktiven lichter weil die alle Lampen von gruppe 1 2 und 3 dem schalter zugewiesen habe. Ausgeschaltere Lampen werden beim dimmen nicht aktiviert

Konfig in Fhem:

Schalter eingebunden und Tastendruck mit DOIF auswerten um Enocean zu schalten:

Links                                   Reihe           rechts
Kurz drücken Rollo zu               4             kurz drücken Rollo auf

Ich hoffe das ist verständlich.

Insgesamt habe ich knapp 40 Zigbee Geräte. Lampen sind auch zwischen Conbee und Taster. Ich habe es bisher so verstanden das Gruppen mit Szenen über Phoscon laufen, das Dimmen der dem Schalter hinzugefügten Lampen aber über dem Schalter direkt, ist aber nur eine Annahme.

Beta-User

Hm, ok, Danke erst mal.

Das mit den Szenen in Hue muß ich mir wohl mal näher anschauen, das habe ich noch kein Gefühl für das Konzept dahinter.

Das mit "Reihe 1 dimmt bei ... weil ..." habe ich noch nicht recht verstanden.
Es gibt also eine "Gruppe 4", in der alle Lampen aus Gruppe 1 -3 und die oberen beiden Tasten sind (mit Tasteraktion für lang = nur "hoch"- bzw. "runterdimmen")?
Ich hatte bisher nur die folgenden Option gefunden: "heller und an", "dunkler und aus" bzw. das ganze abwechselnd (was ich "ein-Tasten-Bedienung" nennen würde). Aber da scheint was anderes gemeint zu sein?
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

eisenhauer1987

Für das Dimmen nicht die Gruppen nehmen oder Tasten belegen. In der Hauptansicht an unten scrollen bis der Wandsender erscheint, dann bearbeiten und Lichter verwalten. Alle Lichter die gedämmt werden sollen hinzufügen der erst passiert "automatisch". Die Erste Tasterreihe wir quasi indirekt belegt,

Siehe Anhang

Beta-User

 :)
Das mit der Zuordnung der Bulbs zu dem Wandsender scheint der Trick gewesen zu sein, vielen Dank für den Schubs! Jetzt funktionieren jedenfalls auch alle vorher definierten Tastenzuordnungen wieder...

Muß damit noch etwas experimentieren, aber vermutlich wäre es das beste, die obere Reihe ganz aus einer konkreten Gruppenzuordnung zu nehmen, die Dimmfunktion scheint sowieso (fast?) alle anderen Zuordnungen zu überspielen (nur das mit der Taste 1 zum Einschalten von Gruppe 1 (wenn alles andere aus ist) funktioniert; aber beim ausschalten geht auch alles andere aus, dimup schaltet alle anderen auch ein... Das scheint mir nicht intuitiv zu benutzen zu sein.
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

Beta-User

Zwischenstand: Heute morgen wollte ich anschalten => ging mit merklicher Verzögerung ("Hauptschalter" oben rechts). Aber immerhin: Es ging (noch!)...

Danach war finis: Keine Reaktion mehr auf irgendeine Taste, ganz egal, ob alle dem Schalter zugewiesenen Geräte (oberes Tastenpaar), die nächsten 4 (toggle der diversen Gruppen m. 1 bzw. 2 Bulbs) oder der als Szenentaster angelegte 7. Taster >:( .

(An der Zahl der Bulbs sollte es nicht liegen, das sind aktuell 7, die über den Taster geschaltet werden; muß mal in die Bedienungsanleitung schauen, aber das wäre ja lächerlich ).
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

eisenhauer1987

Hi,

die Tastenreihe oben schaltet immer alle Lampen. Bei mir ist das kein Problem, weil ich das auch so nutzen wollte ( Wohnzimmer Esszimmer) und die anderen Schalter dann die Gruppe Wohnzimmer und Esszimmer getrennt schalten können. Ich habe 4 Lampen zugewiesen.

Vielleicht resettest den Schalter noch einmal komplett. Das er funktionslos wird nach dem Drücken sollte ja nie passieren.

slor

Funktioniert das Schalten mit Hue Schaltern immer auf Anhieb?
Ich habe oft das Phänomen, dass z.B. Aqara schalter nicht oder erst nach dem 5x drücken schalten. Schalte ich einmal einen Hue Schalter geht es sofort danach.
Ich konfiguriere übrigens gerne mit der App Hue Essentials. Da geht mehr als mit Phoscon.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

binford6000

ZitatIch habe oft das Phänomen, dass z.B. Aqara schalter nicht oder erst nach dem 5x drücken schalten. Schalte ich einmal einen Hue Schalter geht es sofort danach.
Gleiches gilt nach meinen Erfahrungen auch für die IKEA-Produkte.

slor

Ja, wobei leuchten zuverlässiger funktionieren als Taster.
Ich mache fast nur noch: Homematic Taster - Fhem - Phoscon - lampe
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

Beta-User

*grummel*, aber in jeden Fall Danke für eure Erfahrungswerte!
Zitat von: slor am 15 November 2019, 10:51:44
Ich mache fast nur noch: Homematic Taster - Fhem - Phoscon - lampe
Das wollte ich grade verhindern. FHEM läuft zwar super zuverlässig, aber in bestimmten Ecken will ich "Funktionalität in Hardware" haben. FHEM soll/darf "mitlesen" oder auch steuern, aber es MUSS auch ohne gehen.

Was diverse Hersteller angeht, sind hier vorhanden:
- Aktoren:
-- tints und tradfri (Leuchtmittel),
-- innr SP 120 (Steckdoseneinsätze),
- Taster/"Schalter":
-- (bisher) 2x die eckigen tradfri, (weitere liegen hier noch rum, wie gesagt, ich will manches "in Funkhardware" abbilden, was bisher (ungeschickt) verkabelt war).
-- (die große runde ist zwar eingebunden, aber nicht ausgetestet)
-- der Jung
- Sensoren
-- motion: tradfri + Xiaomi
-- Xiaomi Hum+Temp+Luftdruck.

Probleme hatte ich bisher nur folgende:
- kurz bei tradfri-motion zu tradfri-Bulb. Das habe ich aber auf die Ausrichtung des Motion-Sensors zurückgeführt (=> geändert, seitdem (=ca 2 Wochen) keine Klagen mehr, aber auch nicht mehr groß überprüft)
- Anlernen der Bulbs neulich in der Essküche; da habe ich die alle jeweils zurückgesetzt, dann ging das (teils erst nach mehrmaligen Versuchen) irgendwann durch (wie gesagt: aus phoscon schalten geht - soweit erkennbar ohne Ausfälle - überall, selten sehr kurze delays, bei Gruppenschaltungen leider teilweise sichtbaren zeitlichen Versatz zwischen den einzelnen Gruppenmitgliedern).
- in meinem "Zweit-deCONZ" waren nicht alle angelernten Geräte sichtbar bzw. das ist im Hinblick auf OTA reichlich unübersichtlich...

Den Jung hatte ich gestern abend schon zurückgesetzt, das mache ich jetzt halt nochmal, aber wenn er dann wieder "vergesslich" ist, bin ich mit meinem Latein dazu (fast) am Ende... Ggf. schaue ich nochmal, ob es für die tradfri updates gibt, ansonsten schreibe ich Jung mal an, ob denen was einfällt. Aktuellere (?) Firmware scheinen die keine bereitzustellen, oder habe ich was übersehen?

Die App schaue ich mir mal an, aber an sich finde ich phoscon auch ok; man muß halt wissen, wie man bei manchen Sachen vorgeht (wie der "Schaltergruppe"), aber das ist woanders auch nicht wesentlich anders, das ergibt sich vermutlich schlicht aus der Technik.
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

eisenhauer1987

Als Zigbee Schalter habe ich:

Hue Dimmer 2x
Ikea on off Switch 1x
Aqara Switch 2x
Jung Taster

Alle Schalten beim ersten mal drücken und in der Regel im ms Sekunden bereich.



slor

Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

Beta-User

Na ja, ich nutze deCONZ, und das dümpelt lt. top weiter bei unter 6% rum...
Prozessorleistung der Bridge würde ich daher nicht als naheliegende Ursache ansehen.

Habe das Ding also vorhin nochmal resettet, vorher auch in deCONZ gelöscht (in der Annahme, das sei sowas wie eine Exclusion bei ZWave - oder gar ein factory Reset bei HM). Wei gesagt, auch am Schalter resettet lt Bedienungsanleitung.
Dann neu eingebunden (diesmal habe ich das in dem Raum gemacht, in dem auch der deCONZ-Server steht) und die Leuchten wieder der Gruppe zugeordnet. Dann in den "Zielraum": Alles lies sich wieder schalten, aber zu meiner großen Überraschung nicht nur alle gemeinsam, sondern auch die 4 Gruppen haben direkt wieder auf Tasten 1-4 reagiert. Die Szene auf Taste 5 war aber weg!?!

Das wirkt insgesamt nicht eben ausgereift... Mal sehen, was morgen früh Stand der Dinge ist und was wieder dem Vergessen anheimgefallen ;D .
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

Beta-User

Wieder dasselbe wie gestern morgen: Alle Bulbs mit einer Taste einschalten ging, danach war "babela".
Vielleicht habe ich einfach ein Montagsgerät erwischt...
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

P.A.Trick

Zitat von: Beta-User am 16 November 2019, 07:54:42
Wieder dasselbe wie gestern morgen: Alle Bulbs mit einer Taste einschalten ging, danach war "babela".
Vielleicht habe ich einfach ein Montagsgerät erwischt...

Ich klinke mich mal ein. Ich habe auch seit einigen Wochen einen ConbeeII mit deCONZ laufen. So richtig stabil läuft es leider nicht. Ich habe extreme Probleme mit OSRAM Leuchten. Nach einer Weile lassen sie sich einfach nicht mehr steuern.
Ikea und Philips dagegen laufen ohne Probleme. Meine vorherige Philips Hue Bridge hatte vorher keine Probleme.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

Beta-User

Was Leuchten angeht, funktioniert das hier soweit.

Habe eben nochmal den vor einigen Tagen eingebundenen tradfri-Taster getestet. Das ist nur eine Option, in der Regel schaltet hier ein  Bewegungsmelder: auch da gab es teilweise leichte Verzögerungen, aber immerhin hatte der seinen Partner noch gekannt. Rückfrage bei denen, die da die Zielgruppe sind hat ergeben: Der Bewegungsmelder reagiert, es könnte aber schneller sein... (Da ist eine Tag/Nacht-Steuerung über phoscon beteiligt).

Das ganze erschließt sich mir nur bedingt, bisher bin ich davon ausgegangen, dass die beteiligten Geräte (zumindest, was Taster/Fernbedienungen usw. angeht) ihre Partner "in Hardware" kennen und daher auch keine Zentrale brauchen (bzw. nur zu Konfigurationszwecken).
Jetzt habe ich das mit den beiden tradfri-Tastern nochmal bei abgestöpseltem ConBee II getestet: Keine Reaktion... Also scheint entweder mein Systemverständnis falsch zu sein, oder da ist irgendwas noch nicht korrekt konfiguriert.

Wenn die ganze Logik sowieso auf dem Server säße (laut grummel), stellt sich die Frage, auf welchem System das dann besser ist: deCONZ oder FHEM. (Tendenz dann ziemlich eindeutig FHEM, schon weil  deCONZ anscheinend so vergesslich ist.). Aber insgesamt wäre das ein deutlicher Minuspunkt für ZigBee als Technologie. (Wäre interessant, wie das mit den groups in zigbee2mqtt gelöst ist).
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

slor

Nur Geräte des gleichen Herstellers lassen sich direkt verknüpfen. Ich mach das wie schon geschrieben via Android-App
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

MadMax-FHEM

#21
Zitat von: slor am 16 November 2019, 13:15:07
Nur Geräte des gleichen Herstellers lassen sich direkt verknüpfen. Ich mach das wie schon geschrieben via Android-App

Also ich hab ein RaspBee Aufsteckmodul und deCONZ...

Hatte zunächst auch gedacht es geht nur mit Zentrale...
Also angelernt dann dachte ich "verknüpft" zu haben...
Solange deCONZ lief alles gut...
deCONZ aus: nix...

Dann noch mal alles resettet und neu angelernt:

Tradfri FB
Paulmann RGB
Osram RGBW-Stipe

Alles in einen Raum/Gruppe dann die FB über deCONZ gekoppelt (weiß allerdings aus dem Kopf nicht mehr wie genau) und es geht auch ohne deCONZ...

EDIT: allerdings hatte ich mir von Zigbee auch mehr versprochen... Beleuchtung etc. ist ja wirklich toll... Aber bzgl. Lichtschalter, gerade wenn man das vorhandene Schalterprogramm weiter verwenden will: eieiei...

EDIT2: drum hab ich mal an einer Tradfri FB (weil günstig) rumgebastelt: https://forum.fhem.de/index.php/topic,96578.msg896341.html#msg896341 / hab aber mittlerweile schon 3 "geschossen" und bin/gehe dazu über die FB-Innerei komplett zu verwenden (statt nur dem Funkmodul)... Allerdings sehen die zuletzt gekauften innen schon wieder ganz anders aus und lassen sich auch nicht mehr so schön öffnen :-| Naja mal sehen... Evtl. doch Homematic Schalter oder EnOcean und dann per fhem...

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)

sinus61

Also ich hab auch schon Mal meinen Raspbee komplett runtergefahren und ich konnte trotzdem weiter mein Licht einschalten, herstellerunabhängig (Aqara, Tradfri, Hue, Innr). Ist für mich auf jeden Fall ein Vorteil gegenüber einer Lösung die nur über Fhem funktioniert.

Beta-User

#23
Grummel, diese Stochastik liegt mir nicht, es muß doch eine strukturierte Vorgehensweise geben, um da zuverlässig Ergebnisse zu bekommen...

Aber die Bestätigungen, dass das Ziel erreichbar ist, sind doch schon mal ein Hoffnungsschimmer :) .

Die Hardware (auch der Jung) ist auch so designed, dass es ohne Zentrale geht, kann mir irgendwie nicht vorstellen, dass die unbrauchbaren Gruscht verkaufen; doch nicht bei den Preisen, die die da empfehlen?

Habe mal die Hue App installiert, aber viel mehr Optionen zu direkten Verknüpfungen als bei phoscon konnte ich da auch nicht finden. Braucht das irgendwelche speziellen Plugins?

Jetzt habe ich mal ohne Reset die FB nochmal (mit phoscon) verbunden. Danach war
- das Schalten der Gruppen über Tasten #1-4 direkt (ohne weitere phoscon-Aktionen meinerseits) wieder möglich....
- nochmalige  Verbindungsversuche erfolglos (also ist es wahrscheinlich, dass tatsächlich irgendwo eine Info - tendenziell auf dem Jung - verlustigt gegangen ist), und
- die Gruppe für die obersten Tasten aus phoscon verschwunden.
Die habe ich jetzt nochmal neu erstellt, jetzt funktioniert erst mal soweit wieder alles; mal sehen, was der Zahn der Zeit bis morgen abgenagt haben wird...

EDIT: Eine Sache habe ich noch gefunden, die nicht optimal war: Eine der innr SP 120 war nicht mehr erreichbar gewesen - die sitzt zu allem Überfluss funktechnisch in der Strecke zwischen der Essküche und den ConBee II. Mal schauen, jetzt ist der Zwischenstecker jedenfalls auch wieder online.
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

Beta-User

Teilerfolg:

Die Jung hat auch heute morgen noch Aktionen ausgelöst :) .

Um die wichtigste Gruppe ohne FHEM- oder phoscon-Zugriff steuern zu können, hatte ich gestern dann noch meine Test-tradfri (die große runde mit 5 Tasten) angelernt bzw. dieser Gruppe zugeordnet.

Etwas irritierend ist, dass die Tastenkonfiguration über die Gruppe jetzt bei diesen beiden verschwunden ist. Schließe daraus, dass in phoscon ein Scene-Controller allgemein anders "tickt" (da gibt es immer eine entsprechende eigene Gruppe) als die einfachen on/off-Fernbedienungen-tradfri (die haben keine eigene Gruppe).
Eventuell könnte die Reihenfolge der Schlüssel  sein: Bei den Scenecontrollern scheint es wichtig zu sein, dass man erst die Lichter zu deren Gruppe hinzufügt, und erst danach alles andere einrichtet.

Na ja, jedenfalls scheine ich einen oder zwei Schritte weiter zu sein...
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

Beta-User

So, hab's mal auf "weitgehend gelöst" gesetzt:
Die Vergesslichkeit scheint Vergangenheit zu sein, und zumindest die "all on" und "all off"-Option funktioniert auch ohne Server. Leider nicht die Einzeltasten, aber das kann ich notfalls verschmerzen (wie gesagt: der Server läuft zuverlässing...)

Danke nochmal für eure Rückmeldungen und Erfahrungswerte!
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

slor

wird die direkte Verbindung zwischen Geräten automatisch erstellt, oder muss man eine bestimmte Reihenfolge mit Anlernen etc. einhalten?

Mein Statement mit alles nur übers Gateway war dann wohl falsch. Ich teste bei Gelegenheit mal, was bei mir noch ohne Gateway geht.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

Beta-User

Meine "Theorie" zu dem ganzen:

Es gibt eine Art "Ober-Controller-Gerät". Nur mit dessen "Zustimmung" kann man "Unter-Controller-Geräte" dazu bewegen, andere Geräte zu kontrollieren (die müssen das auch alleine können, und theoretisch können die auch schon "Sklaven" haben; aber dann sind die aus Sicht der "Sklaven" der "Ober", was Probleme verursachen kann; z.B. zigbee2mqtt kann damit afaik nicht umgehen, da muß man "Unter" und "Sklaven" jeweils resetten).

Man sollte daher erst alle "Unter" den "Ober" unterordnen und dann die zu kontrollierenden Geräte der (automatisch erstellten)  "Unter"-Gruppe. Dann hat der "Ober" die Möglichkeit, das den "Untern" und "Sklaven" mitzuteilen.

Aber evtl. ist ja jemand so nett und hat einen link auf valide Doku dazu?
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

Beta-User

Hallo zusammen,

jetzt doch keine Entwarnung, was das Thema angeht: Der Jung hat wieder alles vergessen, und auch die danach angelernte runde IKEA-Fernbedienung (die große mit den 5 Tasten) zeigt teilweise ähnliche Symptome...

=> das scheint kein auf den Jung begrenztes Phänomen zu sein, Titel daher geändert.

Das jüngste update für deCONZ ist auf dem Server drauf, viel mehr ist zwischenzeitlich nicht passiert. (*Grummel* so macht das keine Spaß. Dabei hatte meine bessere Hälfte schon im uneingebauten Zustand angemerkt, dass der Jung-Taster (im Gegensatz zu den HM-Teilen) ja mal direkt hübsch aussähe...)
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

Beta-User

Ok, ich bin nicht der einzige mit dem Problem...

Ursache scheint eine nicht ZigBee3-konforme firmware zu sein, mehr Details hier: https://forum.fhem.de/index.php/topic,100772.0.html
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