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

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

Vorheriges Thema - Nächstes Thema

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