Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

Begonnen von supernova1963, 23 September 2018, 19:17:21

Vorheriges Thema - Nächstes Thema

KernSani

Zitat von: Beta-User am 25 Februar 2019, 15:26:22
Hallo zusammen,
kurze Frage an die, die das mit den Gruppen schon im Einsatz haben: Jetzt lassen sich zwar die Lampen gruppenweise "wie eine bulb" schalten, aber wenn man das macht, wird der Status der Gruppe nicht sauber akutalisiert, der bleibt im Prinzip auf dem "set_off" usw. stehen, ich sehe auch keine Erfolgsmeldung bei zigbee2mqtt, geschweige denn, dass da was über mqtt käme.
Gibts dafür schon eine Lösung?

Gruß, Beta-User
Bei mir wird der Status der Gruppe teilweise aktualisiert. State, brightness und color kommen zurück, color_temp und saturation nicht.


Kurz, weil mobil
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Beta-User

Zitat von: KernSani am 25 Februar 2019, 15:35:51
Bei mir wird der Status der Gruppe teilweise aktualisiert. State, brightness und color kommen zurück, color_temp und saturation nicht.
Hm, Danke für die Info, dann bin ich vielleicht irgendwie doch noch nicht auf dem allerletzten Stand? (sch.. npm) Mal schauen...
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

KernSani

Zitat von: Beta-User am 25 Februar 2019, 15:45:12
Hm, Danke für die Info, dann bin ich vielleicht irgendwie doch noch nicht auf dem allerletzten Stand? (sch.. npm) Mal schauen...
Ich habe die FW von Januar am Laufen und zigbee2mqtt aus dem Dev-Branch (vor etwa 2 Wochen oder so...). Ich suche auch noch nach Wegen, die Einzel-Lampen der Gruppe zu aktualisieren  (theoretisch müsste es eigentlich gehen, die Gruppenadresse in die ReadingsList mit aufzunehmen, habe ich aber noch nicht ausprobiert)
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Beta-User

Na ja, ich dachte eigentlich, dass ich recht aktuell wäre, sonst würde das ja nach der Anleitung von Richard gar nicht gehen. (firmware vorgestern geflasht, und auch via npm ein update gezogen). Dann hat das Anlegen und Schalten der Gruppen ja funktioniert, allerdings habe ich das nur mit einer aus meinen beiden IKEAs (GU10) soweit getestet, dass ich das template für die Bridge ergänzen konnte, dann war das auf für den Tag genug...
Und beim Schalten dieser einen Gruppe kam dann halt weder off noch sonst was zurück. Also habe ich das erst mal mit dem Stand auf die Seite gepackt, für "später mal", und ganz genau analysiert, was jetzt genau wo aktualisiert wird, hatte ich auch nicht mehr, nur den Dienst manuell gestartet und auf der Konsole verfolgt, was rein- und rausgeht... Das war halt erst mal wenig.

Leider blicke ich bei diesem blöden npm-Gedönse nicht durch, was jetzt der dev-Stand sein soll und was der reguläre. Hatte bislang nicht die Muße, mich da einzudenken (eigentlich will ich ganz weg von diesem Java-Gelumpe, das darf derzeit nur auf einem Pi rumwerkeln >:( ), ist vermutlich auch nicht schwer, und "irgendwie" ging's ja schließlich auch...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

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

Beta-User

Ähm, das ist jetzt hier zwar ziemlich OT, aber: (im Kern also) nix npm + Internet-Datenbank, einfach mit git das Repo clonen, auf dev-Zweig wechseln und dann wieder lokal npm irgendwas (install)?

(Muß mich mal einlesen, die config muß ich ja doch irgendwie sichern und so, aber das sind ja nur ein paar files... Trotzdem ist mir das insgesamt ein Dorn im Auge).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

Hier ist die Anleitung fürs Update. (Nr.6)
https://www.zigbee2mqtt.io/getting_started/running_zigbee2mqtt.html

Statt dem hier:
Zitatgit checkout HEAD -- npm-shrinkwrap.json
git pull
Kannst du doch einfach einen beliebigen Stand hinterlegen.

Warum mach ich das so murksig ? Ich habe den Teil nicht verstanden: "-- npm-shrinkwrap.json" und ehrlich gesagt, ...  >:(


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

R1k4rd

#352
ZitatZu den Farbwerten: Wenn du die color_x und clor_y readings aktualisiert bekommst, müßte sich daraus auch ein Farbwert errechnen lassen. Ein userreading, das auf eine Änderung eines der beiden Werte triggert und Color::xyY2rgb nutzt, müßte eigentlich helfen, auch wenn ich noch keinen Schimmer habe, wo das große "Y" hernehmen...
Das Y müsste für die Helligkeit stehen oder?

ZitatSchade, dass man nicht auch die Gruppe(n) selbst mit MQTT anlegen kann (?)...
Öhm genau über das MQTT2 Device ging es erst nicht, dass hast du aber ja implementiert und soweit ich das gestern getestet habe funktioniert es auch, danke dafür (;

Zitatattr DEVICE userReadings hex:color_y.* {Color::xyY2hex(ReadingsVal($name,"color_x",0),ReadingsVal($name,"color_y",0),ReadingsVal($name,"brightness",254))}
Ist ab morgen im aktualisierten hex-template.
Wer entsprechend was für die rgb-Varianten liefern kann: nur her damit...
So ganz ist mir leider nicht klar was das Ganze machen soll :D es wandelt color_y sowie color_x die ich von Zigbee2MQTT bekomme in Hex um oder wie - dann müsste es doch eigentlich auch einfach mit den rgb templates gehen weil ich da ja auch color_y und x zurückbekomme und dann einfach aus den beiden ein neues reading hex angelegt wird oder nicht? Hab heute ein Fhem Update gemacht, ich glaube im hex template ist es noch nicht mit drin gewesen? Also zumindest im light_rgbcct_hex ist es noch nicht oder?

ZitatPrinzip auf dem "set_off" usw. stehen, ich sehe auch keine Erfolgsmeldung bei zigbee2mqtt, geschweige denn, dass da was über mqtt käme.
Ist vielleicht etwas blöd die Frage aber wo sehe ich was alles am MQTT2-Server ankommt in Fhem? Und soweit ich weiß ist das für Gruppen bei Zigbee2MQTT einfach noch nicht implementiert worden das etwas zurückkommt?
eventuell hilft dir das hier:
attr <devicename> userReadings state {if(ReadingsVal("<devicename>","state","") eq "set_off") {return "off"} else {return "on"}}

@KernSani
ZitatBei mir wird der Status der Gruppe teilweise aktualisiert. State, brightness und color kommen zurück, color_temp und saturation nicht.
Hast du da selber noch irgendwas verändert oder wie funktioniert das bei dir? Also ich meine wo kommt es zurück, erhälst du state, brightness und color als reading bei dem device in Fhem oder siehst du einfach das Zigbee2MQTT etwas an den MQTT2-Server schickt? Ich hatte gestern extra nochmal ein Update bei Zigbee2MQTT gemacht um wirklich auf dem aktuellsten Stand zu sein allerdings erhalte ich wie Beta-User auch keine Rückmeldung?

Und an alle, hat es jemand hinbekommen readings wie
READINGS:
     2019-02-14 14:30:50   associatedWith  mqttZigbee
     2019-02-27 13:44:42   brightness      set 160
     2019-02-27 13:44:37   color           set 59ff91
     2019-02-27 13:44:40   color_temp      set 496
     2019-02-27 13:44:42   color_x         0.195
     2019-02-27 13:44:42   color_y         0.55
     2019-02-27 13:44:42   state           ON
Attributes:
   IODev      mqttServer
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   gassistantName Licht Schrank
   genericDeviceType light
   group      Beleuchtung
   model      L_02e_zigbee2mqtt_light_rgbcct_rgb
   readingList zigbee2mqtt/rgbcct01:.* { json2nameValue($EVENT) }
   realRoom   Richard
   room       Beleuchtung,Sprachsteuerung
   setList    on:noArg zigbee2mqtt/rgbcct01/set {"state":"ON"}
  off:noArg zigbee2mqtt/rgbcct01/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/rgbcct01/set {"state":"on","$EVTPART0":"$EVTPART1"}
  color_temp:colorpicker,CT,154,2,500 zigbee2mqtt/rgbcct01/set {"$EVTPART0":"$EVTPART1"}
  color:colorpicker,RGB {"zigbee2mqtt/rgbcct01/set ".zigbee2mqtt_RGB2JSON($EVTPART1)}
   setStateList on off
   stateFormat {lc ReadingsVal("$name","state",0)}
   webCmd     brightness:color_temp:color:color_temp 500:color_temp 346:color_temp 154

als normale Werte ohne dem "set" davor zu bekommen?
Wenn ich halt setStateList on off setze erhalte ich diese readings mit dem "set" davor aber sind das jetzt wirklich Rückmeldungen von Zigbee2MQTT oder einfach nur halt weil ich diese Werte in Fhem setze? Ich habe das Ganze jetzt mit folgenden userReadings zu "normalen" Werten bekommen ohne dem "set", bin mir aber halt unsicher ob das so der richtig Weg ist.
state {if(ReadingsVal($name,"state","") eq "OFF") {return "off"} else {return "on"}},
brightness {(split ' ',ReadingsVal($name,"brightness",0))[1]},
color {(split ' ',ReadingsVal($name,"color",0))[1]},
color_temp {(split ' ',ReadingsVal($name,"color_temp",0))[1]},

damit sieht es dann so bei mir aus:
READINGS:
     2019-02-14 14:30:50   associatedWith  mqttZigbee
     2019-02-27 13:55:40   brightness      255
     2019-02-27 13:55:44   color           ffff5e
     2019-02-27 13:55:42   color_temp      352
     2019-02-27 13:55:46   color_x         0.427
     2019-02-27 13:55:46   color_y         0.49
     2019-02-27 13:55:46   state           on
Attributes:
   IODev      mqttServer
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   gassistantName Licht Schrank
   genericDeviceType light
   group      Beleuchtung
   model      L_02e_zigbee2mqtt_light_rgbcct_rgb
   readingList zigbee2mqtt/rgbcct01:.* { json2nameValue($EVENT) }
   realRoom   Richard
   room       Beleuchtung,Sprachsteuerung
   setList    on:noArg zigbee2mqtt/rgbcct01/set {"state":"ON"}
  off:noArg zigbee2mqtt/rgbcct01/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/rgbcct01/set {"state":"on","$EVTPART0":"$EVTPART1"}
  color_temp:colorpicker,CT,154,2,500 zigbee2mqtt/rgbcct01/set {"$EVTPART0":"$EVTPART1"}
  color:colorpicker,RGB {"zigbee2mqtt/rgbcct01/set ".zigbee2mqtt_RGB2JSON($EVTPART1)}
   setStateList on off
   stateFormat {lc ReadingsVal("$name","state",0)}
   userReadings state {if(ReadingsVal("lichtSchrank","state","") eq "OFF") {return "off"} else {return "on"}},
brightness {(split ' ',ReadingsVal("lichtSchrank","brightness",0))[1]},
color {(split ' ',ReadingsVal("lichtSchrank","color",0))[1]},
color_temp {(split ' ',ReadingsVal("lichtSchrank","color_temp",0))[1]}
   webCmd     brightness:color_temp:color:color_temp 500:color_temp 346:color_temp 154


Beste Grüße Richard

Beta-User

Zitat von: R1k4rd am 27 Februar 2019, 13:57:57
Das Y müsste für die Helligkeit stehen oder?
Yup, korrekt, habe das zwischenzeitlich auch gefunden, deswegen ist auch so schon in dem einen template drin, aber vermutlich noch nicht in allen (insbes. light_rgbcct_hex nicht). Aber da sollte das userreading eigentlich auch gehen, das macht genau das, dass aus x,y und der Brightness hex abgeleitet wird. Paßt ganz gut bei meiner tint, abgesehen von den reinen Weißtönen, das ist m.E. etwas zu farbig, aber akzeptabel.
Ich habe das nur nicht größer ausgerollt, weil ich nur den einen Typ habe. Wenn ihr getestete Ergänzungen zu den anderen habt: wie immer her damit...
ZitatIst vielleicht etwas blöd die Frage aber wo sehe ich was alles am MQTT2-Server ankommt in Fhem? Und soweit ich weiß ist das für Gruppen bei Zigbee2MQTT einfach noch nicht implementiert worden das etwas zurückkommt?
Kommt wohl auch auf den Entwicklungsstand an, da ist scheinbar ziemlich Bewegung drin im Moment. Der Server wird gesprächig, wenn man dort das rawEvents-Attribut füllt (.*, z.B.) und den Event-Monitor nutzt.
Zitateventuell hilft dir das hier:
attr <devicename> userReadings state {if(ReadingsVal("<devicename>","state","") eq "set_off") {return "off"} else {return "on"}}
Thx, gute Idee, teste ich bei Gelegenheit, allerdings kommt mir der Trigger noch großzügig vor ("state:state.*set_.*").

Zitat von: KernSani am 25 Februar 2019, 16:56:59
Ich habe die FW von Januar am Laufen und zigbee2mqtt aus dem Dev-Branch (vor etwa 2 Wochen oder so...). Ich suche auch noch nach Wegen, die Einzel-Lampen der Gruppe zu aktualisieren  (theoretisch müsste es eigentlich gehen, die Gruppenadresse in die ReadingsList mit aufzunehmen, habe ich aber noch nicht ausprobiert)
Das mache ich bei den MiLights so und ist dafür auch in den templates so zu finden. Ohne das hier auch getestet zu haben: Funktioniert ziemlich sicher.
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

R1k4rd

Zitat
ZitatZitat von: KernSani am 25 Februar 2019, 16:56:59
Ich habe die FW von Januar am Laufen und zigbee2mqtt aus dem Dev-Branch (vor etwa 2 Wochen oder so...). Ich suche auch noch nach Wegen, die Einzel-Lampen der Gruppe zu aktualisieren  (theoretisch müsste es eigentlich gehen, die Gruppenadresse in die ReadingsList mit aufzunehmen, habe ich aber noch nicht ausprobiert)
Das mache ich bei den MiLights so und ist dafür auch in den templates so zu finden. Ohne das hier auch getestet zu haben: Funktioniert ziemlich sicher.
Ja funktionieren sollte es, hab es probiert allerdings bekomme ich ja für eine Gruppe keine Rückgabe über MQTT aus dem Grund ändert sich auch nichts, erneut die Frage wie bekommen hier teilweise einige Rückgaben für Gruppen?

Zu xyY2hex das funktioniert bei meinen Lampen auch, wie schon gesagt es müsste überall da funktionieren wo ein Leuchtmittel mit RGB verwendet wird. Allerdings ist mir aufgefallen das die Eingabe ≠ Ausgabe ist, heißt soviel wie ich setze z.B ein Grün (44FF00) und erhalte dann zurückgerechnet mit den Werten aus color_x sowie color_y folgenden Wert: 62FF17. Klar es ist beides ein Grün und eine Änderung der Lichtfarbe ist nicht zu erkennen aber wo liegt da jetzt der Fehler? Rechnet xyY2hex falsch um oder liegt es daran das Zigbee2MQTT nicht alle beliebigen Farben darstellen kann und aus dem Grund irgendwie rundet und einen ähnlichen Farbton darstellt? Und anschließend dann halt die geänderten Werte auch in color_x und color_y zurückgibt und xyY2hex daraus dann richtig den hex Wert berechnet? Ist das auch bei den hex templates der Fall oder klappt es dort ohne Probleme? Bei den rgb-templates die ich verwende wird zumal ja auch nochmal umgerechnet weil er hex Werte zu rgb umwandelt damit die Leuchtmittel steuerbar sind.

Und dann noch vielleicht eine ganz andere Frage und zwar wo kann ich mir etwas über json2nameValue anlesen bzw. wie es funktioniert oder an welcher Stelle kann ich es testweise nach meinen Wünschen anpassen usw? Es kommt ja unter anderem bei readingList vor:
zigbee2mqtt/rgbcct04:.* { json2nameValue($EVENT) }

Beta-User

Zitat von: R1k4rd am 28 Februar 2019, 14:40:02
Ja funktionieren sollte es, hab es probiert allerdings bekomme ich ja für eine Gruppe keine Rückgabe über MQTT aus dem Grund ändert sich auch nichts, erneut die Frage wie bekommen hier teilweise einige Rückgaben für Gruppen?
So wie ich das verstanden habe, sollte man zigbee2mqtt auf den letzten Stand (dev-Version) bringen, aber dazu bin ich auch noch nicht gekommen. Aber selbst dann scheint es ggf. noch das eine oder andere Problem zu geben. Es gibt dazu auch einen Thread im zigbee-Bereich (?).

ZitatZu xyY2hex [...]
...kann ich wenig sagen; ich hab's so eingebaut, wie das auf die Schnelle plausibel war. Ggf. bitte auch bei den Codeschnipseln mal nachhaken, da kommt der Ausgangscode von KernSani her, der dann in Color.pm gelandet ist.Ganz allgemein: zigbee2mqtt scheint halt nicht in RGB zu "denken", sondern in xyY. Dabei wird es immer zu Umrechnungsproblemen kommen, weil eben auf jeder Stufe gerechnet wird (erst FHEM, dann zigbee2mqtt, dann die Bulb, dann das ganze zurück...).
Aufgrund der Rundungsdifferenzen, die sich schon bei den normalen brightness-Werten zeigen, gehe ich davon aus, dass zigbee2mqtt z.B. intern mit %-Werten arbeitet, aber nach außen mit 0-255, vermutlich weil OpenHAB oä. das gerne so haben möchte und keine %-Werte.
ZitatUnd dann noch vielleicht eine ganz andere Frage und zwar wo kann ich mir etwas über json2nameValue anlesen bzw. wie es funktioniert oder an welcher Stelle kann ich es testweise nach meinen Wünschen anpassen usw? Es kommt ja unter anderem bei readingList vor:
zigbee2mqtt/rgbcct04:.* { json2nameValue($EVENT) }
Das ist eine allgemeine Funktion aus fhem.pl (?), die in mehreren Formen anzutreffen sein kann. Die lange: json2nameValue(JSON-Input, prefix, JSONMAP).
In der Regel benötigt man die lange Form nur bei sehr komplexen Geräten, im Moment kannst du das ggf. am ehesten nachvollziehen, wenn du die template-Beispiele zum ebus ansiehst (ist ein von user Reinhart gestarteter Thread). Wenn ich supporter dazu finde, werde ich versuchen, auch dazu was in die templates einzubauen.
Ansonsten ist es _immer_ so, dass der JSON-Input eigentlich schon alle Infos enthält, über JSONMAP kannst du die sich aus den JSON-Vorgaben ergebenden Readingnamen dann ggf. anpassen, aber nichts umrechnen oder so. Dazu benötigt man dann eben das userreading.

(Ich hoffe, das einigermaßen verständlich erklärt zu haben...)
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

R1k4rd

ZitatSo wie ich das verstanden habe, sollte man zigbee2mqtt auf den letzten Stand (dev-Version) bringen, aber dazu bin ich auch noch nicht gekommen. Aber selbst dann scheint es ggf. noch das eine oder andere Problem zu geben. Es gibt dazu auch einen Thread im zigbee-Bereich (?).
Ok dann werde ich erstmal warten und schauen was so kommt (;

Könntest du dir vielleicht noch ein Device parallel anlegen und mit deiner Lampe mal folgendes testen und mir sagen wie es dir gefällt bzw. ob alles funktioniert, dann würde ich vielleicht nochmal alle templates ein wenig danach anpassen:
Attributes:
   IODev      mqttServer
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   model      L_02c_zigbee2mqtt_light_rgb_hex
   readingList zigbee2mqtt/testdevice:.* { json2nameValue($EVENT) }
   setList    on:noArg zigbee2mqtt/testdevice/set {"state":"ON"}
  off:noArg zigbee2mqtt/testdevice/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/testdevice/set {"state":"on","brightness":"$EVTPART1"}
  color:colorpicker,HEX,0,15,255 zigbee2mqtt/testdevice/set {"state":"on","color":{"hex":"#$EVTPART1"}}
   setStateList on off
   stateFormat {lc ReadingsVal("$name","state",0)}
   userReadings state {if(ReadingsVal($name,"state","") eq "OFF") {return "off"} else {return "on"}},
brightness {(split ' ',ReadingsVal($name,"brightness",0))[1]},
color:color_y.* {Color::xyY2hex(ReadingsVal($name,"color_x",0),ReadingsVal($name,"color_y",0),ReadingsVal($name,"brightness",255))}
   webCmd     toggle:on:off:brightness:color


Und danke für die Informationen zu json2nameValue, ich werde mal schauen was ich da so noch zu herausfinde bzw. hinbekomme um die readings ohne das setzen der userReadings richtig angezeigt zu bekommen  ;D

Omega

Grundsätzlich läuft zigbee2mqtt recht gut – danke dafür.

Allerdings – zumindest bei mir – übersteht es keinen Reboot des Systems ohne händischen Eingriff.
Der Dienst zigbee2mqtt (aktuell bei mir noch die Version 1.0.1) steht zwar im Status ,,active (running)" aber nach dem 2. Startversuch von zigbee-shepherd kommt die Meldung:

Press the reset button on the stick (the one closest to the USB) and start again

Ziehe ich dann den Stick ab, stecke in neu an und starte zigbee2mqtt erneut, funktioniert alles wieder wie zuvor.

Mein System: Debian 8.11 in einer VM, FHEM ist aktuell.

Meine Frage: bin ich der Einzige mit diesem Problem oder haben andere es auch (ggf. mit welcher Lösung)?

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

Tom71

#358
Ich habe gelesen, dass der Osram Plug (AB3257001NJ ) mit zigbee2mqtt laufen laufen soll. Ich habe bereits 2 Stück probiert, aber leider ohne Erfolg.
Ich habe einen CC2531 und zigbee2mqtt und halte am Plug den Einschalter für ca. 10sec gedrückt. Dann klackt der Schalter. Im log von zigbee2mqtt kann ich aber kein neues Device erkennen.
Andere Geräte (Xiaomi MiJia und Müller Licht Tint LED bulb) konnte ich ohne Probleme anlernen.

Firmware auf dem Stick ist: 20190109

Habt ihr noch einen Tip für mich?
Homematic | RaspberryMatic

Ralf W.

Nach klacken (Werkseinstellung) stromlos machen, einen Moment warten und einstecken. Dann wird er erkannt.


Gesendet von meinem SM-T585 mit Tapatalk

http://twitter.com/RWausD
Schon gewusst, dass Haarausfall zu einer Glatze führen kann?

FHEM: NUC7PJYH2, Ubuntu Server 22.04.2 LTS, HMCCU - RaspberryMatic, DE ConBee II, diverse Sensoren und Aktoren.