Zigbee Gateway (deCONZ) auto Connect nach FHEM Start

Knobbas · 18 Juli 2020, 12:32:50

Hallo zusammen

ich habe gerade angefangen mich ein wenig mit FHEM und Zigbee auseinanderzusetzen. Bin was FHEM betrifft also ein absoluter Neuling. Deshalb stolpere ich gerade über das ein oder andere Problem

Ich habe mir ein Zigbee Gateway mit deCONZ aufgesetzt um ein bisschen zu spielen und zu testen. FHEM soll dann alles managen.
FHEM und deCONZ laufen auf verschiedenen Raspberrys, pairing habe ich durchgeführt und die Sensoren liefern auch Werte. Bis hierhin also alles gut

Aktuell stehe ich jedoch vor dem Problem, dass nach einem Reboot des FHEM Raspberry deCONZ auf "Initialized" stehen bleibt. Mit einem "set deCONZ active" ist wieder alles prima, aber das sollte sich doch auch irgendwie automatisch machen lassen, oder?
Wäre ja fatal, wenn man außer Haus ist und nach einem Stromausfall das System nicht mehr hochkommt.

Wäre nett wenn jemand helfen könnte

Danke euch, Oliver

MadMax-FHEM · 18 Juli 2020, 12:45:04

Wie du schon schreibst, sollte das autom. wieder verbinden...

Bzw. funktioniert es denn im Zustand initialized nicht!?

Ansonsten: notify auf global:INITIALIZED (das teilt mit, dass fehm neu gestartet wurde) eben den set Befehl absetzen...

EDIT: eben getestet. Ist bei mir nach fhem Neustart wieder connected...

Gruß, Joachim

Knobbas · 18 Juli 2020, 13:23:56

Echt ne seltsame Sache...
Nach FHEM restart bleibt es bei mir auch connected.
Wenn ich den Raspberry reboote bleibts auf initialized stehen und es werden keine Sensordaten empfangen

Das mit dem notify auf global:INITIALIZED funktioniert auch nur bedingt. Wenn nur der FHEM Raspi rebootet klappts, wenn FHEM aber schneller up ist wie das Gateway klappts nicht mehr. Dann steht deCONZ auf "active" und es werden keine Daten empfangen.

Code Auswählen

define deCONZreconnect notify global:INITIALIZED { fhem("set deCONZ active") }

Ich bin jetzt am überlegen ob man nicht nen notify auf deCONZ:state != connected machen kann

Die Frage ist nur wie und wenn ja müsste da ja auch ein polling mit rein, damit FHEM den reconnect nur alle 5 minuten oder so versucht ...

Ich muss aber auch zugeben, dass ich aktuell mit FHEM noch ein wenig überfordert bin. Also mit notify hab ich schon ein klein wenig gespielt, so richtig schlüssig ist mir das Ganze aber noch nicht (bin mit der Syntax noch ein wenig überfordert)

MadMax-FHEM · 18 Juli 2020, 19:54:47

Die geschweiften Klammern sind unnötig, wenn du dann doch nur ein fhem Kommando absetzt, das hier reicht völlig:

Code Auswählen


define deCONZreconnect notify global:INITIALIZED set deCONZ active

https://wiki.fhem.de/wiki/Klammerebenen

Ein Notify wie gewünscht geht ganz einfach: Eventmonitor öffnen (Filter setzen) und auf den passenden Event warten, dann markieren und "create/modify" -> Kommando ergänzen fertig...

https://wiki.fhem.de/wiki/Event_monitor

Ich probiere das dann auch mal wie es sich bei mir verhält, wobei ich ja schon nicht mal den Notify für fhem Restart brauche...

Poste doch mal ein list von deinem deCONZ Device...

Gruß, Joachim

Ma_Bo · 19 Juli 2020, 02:50:56

Ich habe die gleichen Beobachtungen wie Knobbas gemacht, natürlich könnte man das jetzt mit dem notify machen, aber es wäre eleganter wenn es automatisch funktionieren würde.

Bei mir ist auch das Problem, wenn Deconz mal nicht erreichbar ist (Backup im Stop Mode), dann habe ich 2-3 Sekunden freezes, auch wenn ich das Gateway attr disable 1 setze und auch wenn ich es über den set Befehl auf inactive setze.

####EDIT
Hinzu kommt wenn Deconz abgeschaltet ist, springt bei mir das Gateway nicht auf disconnect sondern bleibt dauerhaft auf connected

Grüße Marcel

Knobbas · 19 Juli 2020, 08:26:41

Moin, ich hoffe ich hab die richtigen Daten

Hab meinen FHEM Raspi gerade mal eingeschaltet (notify auf global:INITIALIZED ist aktuell nicht drin).
So sieht es dann nach dem Boot des Raspi:

Code Auswählen

Internals			
DEF		192.168.178.38	
			
FUUID		5f10adaf-f33f-6b2e-82d2-035ca8d9bda44b32	
FVERSION		30_HUEBridge.pm:0.213660/2020-03-06	
INTERVAL		60	
NAME		deCONZ	
NOTIFYDEV		global	
NR		19	
NTFY_ORDER		50-deCONZ	
STATE		initialized	
TYPE		HUEBridge	
host		192.168.178.38	
Readings			
lastError	link button not pressed		16.07.20 21:43
state	initialized		19.07.20 00:26

Aufgefallen ist mir das auch nur weil ich momentan noch auf einem Test-PI arbeite. Auf meinem live Pi habe ich noch ne zwave.me Installation am laufen, die muss erst weg bevor ich da FHEM installieren kann. Gleichzeitig muss ich dann aber auch alle z-wave Sensoren/Aktoren gegen zigbee tauschen. Hab ein paar defekte z-wave Geräte und die zu ersetzen ist mir zu teuer.
Nur so als Hintergrund

Grüße, Oliver

MadMax-FHEM · 19 Juli 2020, 10:12:57

Hallo Oliver,

bei dem list fehlt doch was!!?

Bitte komplett posten, danke.

@Marcel: ebenfalls mal ein list. Hast du das Attribut httpUtils gesetzt!? Dann arbeitet das HUEBridge-Modul nonblocking. Wenn trotzdem Freezes gemeldet werden würde ich mal behaupten sind das "false positive". Du brauchst dann eigentl. für die kurze Zeit auch kein disabled Attribut setzen. Wobei da dann "set Name inactive" zu bevorzugen wäre (meine Meinung) weil sonst das "rote Fragezeichen" kommt...

Gruß, Joachim

Ma_Bo · 19 Juli 2020, 11:09:16

Zitat von: MadMax-FHEM am 19 Juli 2020, 10:12:57
@Marcel: ebenfalls mal ein list. Hast du das Attribut httpUtils gesetzt!? Dann arbeitet das HUEBridge-Modul nonblocking. Wenn trotzdem Freezes gemeldet werden würde ich mal behaupten sind das "false positive". Du brauchst dann eigentl. für die kurze Zeit auch kein disabled Attribut setzen. Wobei da dann "set Name inactive" zu bevorzugen wäre (meine Meinung) weil sonst das "rote Fragezeichen" kommt...

Gruß, Joachim

Hallo Joachim,

hier das list, die einzelnen Devices welche mit aufgelistet sind, habe ich nicht im list mit drin, den KEY unkenntlich gemacht:

Code Auswählen

Internals:
   .FhemMetaInternals 1
   .triggerUsed 1
   DEF        192.168.178.65
   FD         4
   FUUID      5e9b7fa9-f33f-5000-b895-8675f871f380c26a
   FVERSION   30_HUEBridge.pm:0.213660/2020-03-06
   INTERVAL   60
   NAME       Conbee2_USB_Stick
   NOTIFYDEV  global
   NR         5152
   NTFY_ORDER 50-Conbee2_USB_Stick
   PORT       47282
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.16.0
   host       192.168.178.65
   mac        0e:10:df:31:02:c7
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   modelid    deCONZ
   name       Conbee2
   swversion  2.5.75
   updatestate 0
   websocket  1
   websocketport 443
   zigbeechannel 11
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2020-07-14 17:02:57   lastError       resource, /lights/22, not available
     2020-07-19 10:56:05   state           connected
   helper:
     apiversion 69632
     count      0
     last_config_timestamp 1595148965
     offsetUTC  7200
     updatestate 0
     groups:
.
.
.
.

      scenes:
Attributes:
   event-on-change-reading .*
   group      Conbee und Repeater
   httpUtils  1
   key        xxxxxxxxxx
   noshutdown 1
   room       4.38_Conbee2
   verbose    0

Wie man sieht ist httpUtils gesetzt und ja es kommen trotz dass ich "set Name inactive" oder "disable 1" setze weiterhin freezes.
In "global" ist auch "attr dnsServer" gesetzt.

Das komische ist auch, dass das Gateway nicht auf "disconnected" springt, es bleibt weiterhin auf "connected" und es kommen 2-3 Sekunden freezes.

Grüße Marcel

Knobbas · 19 Juli 2020, 11:40:40

Zitat von: MadMax-FHEM am 19 Juli 2020, 10:12:57
bei dem list fehlt doch was!!?

Bitte komplett posten, danke.

Nein, eigentlich fehlt da nichts

Hier nochmal alles was der list liefert

Code Auswählen


Internals:
   DEF        192.168.178.38
   FUUID      5f10adaf-f33f-6b2e-82d2-035ca8d9bda44b32
   FVERSION   30_HUEBridge.pm:0.213660/2020-03-06
   INTERVAL   60
   NAME       deCONZ
   NOTIFYDEV  global
   NR         19
   NTFY_ORDER 50-deCONZ
   STATE      initialized
   TYPE       HUEBridge
   host       192.168.178.38
   READINGS:
     2020-07-16 21:43:23   lastError       link button not pressed
     2020-07-19 11:27:46   state           initialized
   helper:
     count      0
     last_config_timestamp 0
Attributes:
   httpUtils  1
   key        xxx

Oder meinst du die Werte hier ? Die kommen erst dazu wenn der Status auf connected ist

Code Auswählen


Internals:
   DEF        192.168.178.38
   FD         10
   FUUID      5f10adaf-f33f-6b2e-82d2-035ca8d9bda44b32
   FVERSION   30_HUEBridge.pm:0.213660/2020-03-06
   INTERVAL   60
   NAME       deCONZ
   NOTIFYDEV  global
   NR         19
   NTFY_ORDER 50-deCONZ
   PORT       42832
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.16.0
   buf        
   host       192.168.178.38
   mac        b8:27:eb:ed:94:8d
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   modelid    deCONZ
   name       Phoscon-GW
   swversion  2.5.78
   updatestate 0
   websocket  1
   websocketport 443
   zigbeechannel 15
   READINGS:
     2020-07-16 21:43:23   lastError       link button not pressed
     2020-07-19 11:36:40   state           connected
   helper:
     apiversion 69632
     count      0
     last_config_timestamp 1595151399
     offsetUTC  -3600
     updatestate 0
     groups:
       4:
         etag       bd05655c857e1540162cf93d4063e8df
         id         4
         name       Wohnzimmer
         type       LightGroup
         action:
           bri        127
           colormode  hs
           ct         0
           effect     none
           hue        0
           sat        127
           scene      
           xy:
             0
             0
         devicemembership:
         lights:
         scenes:
         state:
     lights:
       1:
         etag       5d2fea70031b7756c6cd25172af57bc2
         lastannounced 
         lastseen   2020-07-19T09:36:36Z
         manufacturername dresden elektronik
         modelid    ConBee II
         name       Configuration tool 1
         swversion  0x26580700
         type       Configuration tool
         uniqueid   00:21:2e:ff:ff:05:dd:82-01
         state:
     scenes:
Attributes:
   httpUtils  1
   key        xxx

MadMax-FHEM · 19 Juli 2020, 11:52:16

@Marcel: wie geschrieben, ich bin fest davon überzeugt, dass die gemeldetetn Freezes nur "false positive" sind. Evtl. das in einem gesonderten Thread zusammen mit dem Entwickler von FreezeMon klären/analysieren. Ich glaube nicht, dass Andre/justme1968 das Attribut angibt und dann trotzdem "blocking" implementiert hat... Und da das dnsServer Attribut gesetzt ist, wäre auch eine DNS-Abfrage non-blocking (ist aber eh überflüssig, weil ja deCONZ mit IP angegeben ist)...

@Oliver: naja beim ersten Post haben auf jeden Fall die Attribute gefehlt...

Und die kommen nicht erst, wenn connected ist

Du kannst ja mal zusätzlich das Attribut noShutdown setzen. Ansonsten werde ich mal später (aber verm. erst morgen) mal "durchbooten" und mal sehen was da so bei mir passiert...

Aber: wie oft passiert es, dass du beide Systeme "gleichzeitig" durchbootest!? Und es dann "Glückssache" ist, ob es mit dem INITIALIZED geht oder nicht (wobei das bei mir UNNÖTIG ist, den Test habe ich schon durch)!? Und wenn nach einem Stromausfall (wie oft hast du das!?) beide booten bzw. eher "davor": da hätte ich eher "Angst", dass die SDs der PIs "hopps" gehen als, dass danach eine "Unstimmigkeit" ist

Und: wie das Erzeugen eines Notify bei "disconnected" etc. geht habe ich ja geschrieben...

Gruß, Joachim

Knobbas · 19 Juli 2020, 16:48:18

Zitat von: MadMax-FHEM am 19 Juli 2020, 11:52:16

Aber: wie oft passiert es, dass du beide Systeme "gleichzeitig" durchbootest!? Und es dann "Glückssache" ist, ob es mit dem INITIALIZED geht oder nicht (wobei das bei mir UNNÖTIG ist, den Test habe ich schon durch)!? Und wenn nach einem Stromausfall (wie oft hast du das!?) beide booten bzw. eher "davor": da hätte ich eher "Angst", dass die SDs der PIs "hopps" gehen als, dass danach eine "Unstimmigkeit" ist

Naja, das ist eben genau das Problem an der Sache - es kommt so gut wie nie vor. Und wenn es dann doch mal passiert denkt man nicht daran, dass evtl was nicht funktioniert.
Das mit dem notify funktioniert bei mir ja auch nur dann zuverlässig, wenn "nur" der FHEM Raspberry rebootet.
noshutdown habe ich inzwischen gesetzt, aber einen wirklichen Unterschied kann ich nicht feststellen.
Letztendlich brauchts also eigentlich nen Watchdog der permanent die Verbindung zwischen FHEM und Gateway überwacht um im Bedarfsfall restartet.

MadMax-FHEM · 19 Juli 2020, 16:58:05

Du kannst ja auch ein Presence auf den deCONZ PI machen und beim Wechsel von absent auf present ein Reconnect...

Aber das alles ist (in meinen Augen) nur Symptombekämpfung...

Weil ich zumindest bei fhem Neustart (Reboot noch nicht getestet) kein Problem habe...
Booten von deCONZ teste ich auch noch, mal sehen...

Gruß, Joachim

Knobbas · 19 Juli 2020, 18:36:25

Ja, es ist Symptombekämpfung. Aber in meinen Augen unverzichtbar wenn sich die Verbindung nicht zuverlässig selbst reinitialisiert.

Du weißt ja, ein gebranntes Kind scheut das Feuer

Ich hatte das schonmal. Da hat die Überwachnung der Solaranlage versagt und wie es der Teufel so will ist dann die Hauptsicherung gefallen, die Solaranlage hat 6 Wochen keinen Strom produziert und niemand hats bemerkt.

Wenn mein Funklichtschalter nicht funktioniert weil das Gateway tot ist, dann ist mir das egal, da kann ich eingreifen und gegensteuern. Aber wenn ich nicht zu Hause bin und der Wasserschlauch der Waschmaschine platzt dann will ich da zuverlässig eine Info bekommen.
Ich habe hauptsächlich Sensoren und kaum Aktoren verbaut. FHEM soll mich eher über potentielle Gefahren informieren.
Heizung an bei Fenster offen
Kühlschrank nicht geschlossen
Überschwemmung in Bad/Küche
Luftfeuchte zu Hoch
...

Aktueller Stand:
Restart FHEM -> kein Problem
Reboot FHEM -> kein Problem dank notify auf global:INITIALIZED
Reboot/Restart deCONZ -> kein Problem, da merkt FHEM nichtmal was davon
Reboot/Restart FHEM während deCONZ noch nicht up -> hier knallts. Status bleibt auf Initialized, es werden keine Sensordaten empfangen

für den Fall, dass zwischendrin mal die Verbindung wegbricht habe ich testweise einen notify auf Status != connected eingefügt.

Code Auswählen

define deCONZreconnect notify deCONZ:.* { if($EVTPART0 ne "connected") { fhem("set deCONZ active")} }
Wobei ich nicht glaube, dass der jemals anschlägt, da auch wenn ich den deCONZ ausschalte der Status weiterhin auf connected stehen bleibt. FHEM prüft das scheinbar nicht fortlaufend, also hab ich das wieder entfernt

Ein Watchdog der alle 5 Minuten den Status prüft wird wohl nicht funktionieren, da FHEM ja nicht bemerkt, dass die Verbindung weg ist. Daher setze ich jetzt einfach mal alle 5 Minuten deCONZ active.

Code Auswählen

define deCONZwatchdowg at +*00:05 fhem("set deCONZ active")

Die Lösung gefällt mir zwar nicht wirklich, funktioniert aber erstmal.

Hätte noch jemand ne Idee wie man nen echten Watchdoch basteln könnte der die Verbindung aktiv testet und bei Bedarf reinitialisiert ?

Grüße, Oliver

MadMax-FHEM · 19 Juli 2020, 19:41:27

Also wenn es dir nur um Symtombekämpfung geht oder du sicher, sicher gehen willst: alle paar Minuten, Stunden, ... ein get HUEBridgeName statusRequest und dann evtl. noch notify auf "nicht (wirklich) verbunden"...

Weil nach einem statusRequest sollte der Status auf jeden Fall passen (also auch, wenn tatsächlich nicht verbunden)...

Und wenn nur nicht "richtig" verbunden, dann hilft der statisRequest norm. auch "daüber hinweg"...

Gruß, Joachim

MadMax-FHEM · 20 Juli 2020, 13:18:55

Also, bin wieder zuhause und hatte Zeit und hab ein wenig rumprobiert (übernehme aber keine Garantie, dass die Tests nicht von einigen parallelen Updates beeinflusst wurden: OS-Update fhem PI und OS/deCONZ Update auf dem RaspBee und OS/Unifi Update auf dem Unifi Controller / wenn ich schon mal Zeit habe

)

fhem ist NICHT aktuell, letzter Update: 31.05. 2020 17:03:51

Aktuell ist mir bzgl. Homematic zu viel los...
...da warte ich noch...

Denke aber nicht (oder hoffe), dass das viel macht...

deCONZ auf PI Buster mit dem RaspBee-Aufsteckmodul auf aktuellstem Stand (war quasi der RaspBee-Reboot-Test

)...

EDIT: alle Tests ohne irgendwelche "Reconnect-notify"...

1. Test:

Update OS/deCONZ auf RaspBee, danach reboot -> kein Problem

Status blieb connected (kann aber ok sein, kommt ja drauf an, wann das HUE-Bridge Modul immer so nachsieht, wobei ich dachte ich wäre auf push-API!?)

Sensor Daten kamen ganz normal (Vibrationssensor war mein Testsensor)

2. Test:

shutdown RaspBee

Status bleibt connected, im Log:

Code Auswählen


2020.07.20 11:55:54 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 11:56:19 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 11:56:39 2: HUEBridge_OpenDev: error reading description: http://192.168.1.90:80/description.xml: Can't connect(1) to http://192.168.1.90:80: IO::Socket::INET: connect: timeout
2020.07.20 11:56:40 2: RaspBee: empty answer received for http://192.168.1.90:80/api/d3ddde404fbd5cd6c914afa575ca06a5/config
2020.07.20 11:56:40 2: HUEBridge_OpenDev: got empty config

Dann folgendes beim RaspBee-Device (HUE-Bridge-Device in fhem):

set RaspBee statusRequest -> nichts

set RaspBee active -> active

Dann Neustart des RaspBee, folgendes im Log:

Code Auswählen


2020.07.20 11:59:19 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 12:00:00 1: 192.168.1.90:5333 reappeared (gtagIch)

Hab das gtagIch nur drin gelassen, weil auf dem RaspBee seit einiger Zeit auch mein leprecenced läuft

Man sieht also: RaspBee wieder da...
(die "fehlerhafte" Abfrage kurz zuvor kann schon sein: kommt halt drauf an wann das RaspBee-Modul in fhem abfragt, evtl. halt noch knapp zu fürh

)

Dann habe ich folgendes gemacht:

Status bleibt "active"

Sensor wird aber empfangen

set RaspBee statusRequest -> nichts

set RaspBee active -> connected

Eigenartig, ich glaube mich zu erinnern, dass das mit dem statusRequest auch schon mal anders/besser war...
...drum hab ich das ja "empfohlen"...
Hmmm...

3. Test:

Shutdown RaspBee / reboot fhem

Während fhem Start (und bis kurz danach) folgendes im Log:

Code Auswählen


scription: http://192.168.1.90:80/description.xml: Can't connect(1) to http://192.168.1.90:80: IO::Socket::INET: connect: timeout
2020.07.20 12:14:32 2: RaspBee: empty answer received for http://192.168.1.90:80/api/d3ddde404fbd5cd6c914afa575ca06a5/config
2020.07.20 12:14:32 2: HUEBridge_OpenDev: got empty config

...

2020.07.20 12:14:41 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 12:14:41 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 12:14:41 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 12:14:41 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 12:14:41 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)
2020.07.20 12:14:41 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)

...

2020.07.20 12:14:42 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)

Status: Initialized

set RaspBee statusRequest -> Initialized

Code Auswählen


2020.07.20 12:19:25 2: RaspBee: http request failed: 192.168.1.90: No route to host (113)

set RaspBee active -> active

Code Auswählen


2020.07.20 12:20:51 2: HUEBridge_OpenDev: error reading description: http://192.168.1.90:80/description.xml: Can't connect(1) to http://192.168.1.90:80: IO::Socket::INET: connect: timeout
2020.07.20 12:20:52 2: RaspBee: empty answer received for http://192.168.1.90:80/api/d3ddde404fbd5cd6c914afa575ca06a5/config
2020.07.20 12:20:52 2: HUEBridge_OpenDev: got empty config
2020.07.20 12:20:59 2: HUEBridge_OpenDev: error reading description: http://192.168.1.90:80/description.xml: Can't connect(1) to http://192.168.1.90:80: IO::Socket::INET: connect: timeout
2020.07.20 12:20:59 2: RaspBee: empty answer received for http://192.168.1.90:80/api/d3ddde404fbd5cd6c914afa575ca06a5/config
2020.07.20 12:20:59 2: HUEBridge_OpenDev: got empty config

Neustart RaspBee

Status bleibt active

Keine Sensordaten

Lichter sind in undefiniertem Zustand und lassen sich nicht schalten.
Hat aber (in dem Fall) nichts mit fhem bzw. dem HUE-Modul zu tun, auch deCONZ hat keine Verbindung zu den Lampen...

(hatte ich bei "intensiven" Tests auch schon mal, muss dann [entweder warten!? oder] die Lampen "nue starten" [stromlos] / drum nehme ich für Tests normalerweise auch meine Testumgebung / aber nachdem ich wegen OS etc. Updates eh "rumgetan" hab, hab ich das mal am "Live-System" gemacht)

Also ich dann doch einfach die Lichter geschalten habe (noch vor dem "Neustart" der Lampen) war folgendes in den Readimgs:

Code Auswählen


lastError resource, /lights/1, not available 2020-07-20 12:29:50
state active 2020-07-20 12:20:56

Also Status hat sich nicht geändert, es kam aber das Fehler-Reading dazu...

-------------------------------------------------------------

Nach einem erneuten set RaspBee active (vorher halt deCONZ und meine Lampen wieder "glücklich" gemacht) passt es wieder...

Da ich keine "wichtigen" Sensoren per ZigBee habe, kann ich leben wie es ist, bzw. stecke keine Energie rein da was zu ändern.

Wenn Andre/justme1968 hier drüber stolpert (oder drüber gestolpert wird

) und Infos braucht, dann packe ich halt mal ein Testsystem aus, da dann auch mit aktuellstem fhem...

ZigBee ist ja ganz nett bzgl. Beleuchtung, wobei auch da fehlt mir Entscheidendes: eine einfache Möglichkeit vorhandene Schalter zu nutzen OHNE einen Batterie-Schalter hinter einen vorhandenen Schalter zu klemmen...

Daher habe ich aktuell auch noch nicht viel ZigBee und die Lampen schalte ich entweder automatisch (bestimmte Bedingungen) oder per FB (Harmony und fakeroku) oder per Sprache (alexa-fhem)...

Bei den Sensoren habe ich halt den Vibrations-Sensor (war gedacht für Briefkasten, baut aber zu groß) und einen "Regensensor" ("umgebauter" Wasser-Sensor).
Aber die sind mehr "Spielerei" bzw. habe ich sie, weil die nicht teuer waren...

Ansonsten habe ich bzgl. Sensoren "ausgereiftere" Systeme: Homematic, ZWave

So, das war's erst mal...

Gruß, Joachim