[unboxing] - neue ZigBee-Devices

[Beta-User]

Hallo zusammen,

"neulich in der Bucht" sind mir ein paar Gadgets über den Weg gelaufen, die ganz interessant ausgesehen haben. Da auch der eine oder andere potentielle "Problemlöser" dabei war, konnte ich nicht widerstehen und werde an dieser Stelle berichten, ob und wie sich die Teile integrieren lassen.

Den Anfang machen zwei Relais "without neutral", eines mit "1 Gang", eines mit "2 Gang", Modellbezeichnungen QS-Zigbee-S05-L und QS-Zigbee-S04-2C-L, Bilder anbei. Beide sollten in hierzulande übliche Unterputzdosen passen, sie sind aber etwas größer als z.B. die Z-Wave-Geräte von Fibaro oder ein Shelly 1, aber niedriger wie die eQ-3-HomeMatic-Teile, müßten daher wirklich hinter dem Schalter noch reinpassen.

Zuerst hatte ich versucht, den QS-Zigbee-S04-2C-L via deconz zu integrieren, was nicht richtig funktioniert hat. Habe dann ein update auf den letzten Stand gemacht (2.6.0), was leider auch nicht wirklich was gebracht hat. Es bindet sich zwar ins Mesh ein (in der deCONZ-GUI auf dem Laptop war es zu sehen und blinkt dort auch kurz und artig, wenn man das Relay über den Schalter betätigt, aber es gibt weder in phoscon noch in FHEM irgendwas, was man bedienen könnte. Ergo: Derzeit entweder in deconz noch Fehlanzeige oder schlicht kaputt (hier hatte jemand ähnliche Erfahrungen gemacht: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3008#issuecomment-708573766). Mal sehen, was der Verkäufer dazu meint bzw. ob es zu gegebener Zeit via tasmota2zigbee geht...

Der QS-Zigbee-S05-L (1 Relay) war dagegen herrlich unkompliziert: Anlernprozess angeschubst, schwupps, war er in deconz und FHEM vorhanden. Der "manufacturername" ist mit "_TZ3000_pmvbt5hh" zwar eigenartig, aber immerhin kann man das Relay von FHEM aus auch schalten, "modelid"    ist "TS0011".

Mal sehen, wie sich das Teil im Dauereinsatz schlagen wird.

Fortsetzung folgt, und falls wer andere Gadgets rumliegen hat, über die er berichten will: feel free, der Thread hier soll auch dazu da sein, sich über solche Experimente auszutauschen .

Grüße,
Beta-User

[Beta-User]

Moin,

Teil 2: Tuya ZigBee Remote Scene Controller 4-Gang-WLAN-12-Szenen-Switch EU / UK...

Optischer Eindruck: Das Teil ist wirklich so riesig, wie es in der Bucht angekündigt war - meine Hoffnung war gewesen, dass da noch so eine Art Einbaurahmen drumrum ist und der eigentliche Tasterbereich deutlich kleiner. Fehlanzeige... Dafür hat das Ding 4 ordentlich große Tasten, die je per eigener LED signalisieren, wenn sie gedrückt werden; nach längerem Tastendruck geht die LED dann aus, nach 10 Sek. auf Taste 1 (links unten...) geht es in den Pairing Mode.
Druckpunkte und Verarbeitung wirken sehr gut, nicht so toll finde ich die graue Grundplatte, die aber sauber mit dem Gehäuse abschließt. Für <15 Euro (zzgl. Batterie, die muß man extra ordern) sollte man damit sehr zufrieden sein können.

Auch hier: erst mal kein Glück mit deconz, ein echter Funktionstest auf der ZigBee-Ebene steht daher noch aus. Laut Bucht-Beschreibung soll das bis zu 12 Szenen schalten können, was auch immer das konkret bedeutet (lang oder dreifach-Klick, das ist die Frage... Oder doch beides? Wir werden es vermutlich irgendwann wissen).


Da das Teil so (@deconz noch) nicht benutzbar ist, und auch zu groß für eine Schalterintegration in Jung, habe ich's mal auseinandergenommen, und weil's grade so schön war, dasselbe auch noch mit dem 1-Gang gemacht, Bildchen anbei.

Das eigentlich PCB ist etwas kleiner, aber immer noch recht groß, so dass sich das wohl auch nicht so einfach "zurechtschnitzen" läßt, um es irgendwie hinter normale Taster unterzubringen. Schade eigentlich...

ABER: Weitaus interessanter (aber eigentlich wenig überraschend) war, dass auf beiden Geräten derselbe Basis-Modul-Typ zu finden ist: TYZS3. Erinnert äußerlich etwas an ESP01, bietet 9 GPIO's (3 PWM-fähig) und zusätzlich einen ADC-PIN (12 Bit), ein PDF dazu gibt es unter https://fccid.io/2ANDL-TYZS3/User-Manual/User-Manual-4447178, Tuya hat developer-Infos hier im Angebot: https://developer.tuya.com/en/docs/iot/device-development/module/zigbee-module/zigbeetyzs3ipexmodule?id=K989rjm3c1z55.
Scheint so, dass das ein Chip/Modul-Typ ist, den man sich (auch für Bastelzwecke!) merken muss.

CU, Beta-User

[Beta-User]

Teil 3 - Sonoff Bewegungsmelder (SNZB-03):

Die sind tatsächlich relativ klein . Nur leider werden sie - derzeit & entgegen der Angabe bei blakadder - von deconz auch noch nicht unterstützt, es gelang mir nicht mal, da die Detailinfos zu Manufacturer und Produkt-ID über deCONZ-GUI rauszufinden, integrieren ließen sie sich aber.

Dann muss man das Gehäuse mit Werkzeug aufhebeln, um die Batterie-Kontaktunterbrechungs-Lasche zu entfernen, und beim einen von den beiden war es dann noch so, dass ich die Kontakte etwas verbiegen mußte, dass das Teil dann tatsächlich Saft bekam. Murks!
Intern verbaut ist übrigens ein CC2530, Batterieformat ist CR2450, die Batterie wird über den hinteren Deckel an Position gehalten.
Na ja, eigentlich wollte ich die an ein paar Stellen an die Decke kleben, was aber ggf. nur mit einem Magneten sinnvoll ist, denn wenn man sie verklebt, gibt das Probleme beim Batterietausch usw.. Schade!

Dafür konnte ich den "2 Gang without neutral" zumindest über die deCONZ-GUI dazu bewegen, das Relay auszumachen, das Ding funktioniert also prinzipiell . Muß dann halt bei Gelegenheit noch eine suport-Anfrage bei de machen.

Auch der 4-fach-Scene-Switch ist im Mesh zu sehen, aber auch hier bin ich erst mal nicht so recht schlau geworden aus dem, was mit deCONZ-GUI rauszufinden war. Muss mich da wohl auch erst mal orientieren, bisher ging's ohne...

Das war's vorerst mal, bis die aus dieser Bestell-Serie noch fehlende Sonoff-ZigBee-Bridge kommt, wird es wohl etwas dauern, und notfalls binde ich das Zeug halt mit tasmota2zigbee ein...
Wenn es sonstige Fortschritte mit dem bisher vorgestellten Material geben sollte, werde ich das hier dann auch melden.

Ihr dürft den Thread aber gerne dazu nutzen, anderes - potentiell interessantes - Zeug hier vorzustellen.

Grüße, Beta-User

[Beta-User]

Weil per pm die Frage kam, warum ich mir die (im Vergleich zu den Aqara) hässlicheren Sonoff "reingezogen" habe und das ggf. auch den einen oder anderen User noch interessiert:

An der avisierten Einbauposition an der Decke hätten die tendenziell ganz ok ausgesehen, außerdem kosten die nur die Hälfte. Außerdem  bin ich halt ein neugieriges Spielkind und brauche z.B. den Helligkeitswert nicht....

Zudem nervt mich etwas, dass Xiaomi beim Thema firmware-updates nicht unbedingt transparent ist - aber das Zeug, was hier von denen im Einsatz ist, funktioniert klaglos und mit guten Batterie-Laufzeiten. Von daher besteht auch kein echter Bedarf für updates und es gilt: Wer stressfreie Hardware sucht, sollte (vorerst) besser die Aqara einsetzen.

itead dagegen scheint (immer mehr) offen für open-Source-Fragen zu sein, und da das Ding auf CC2530-Basis ist, müßte sich auch sowas wie eine "custom firmware" entwickeln lassen (wobei ich nicht aufgepaßt habe, ob es Zugriffspunkte gäbe, z.B. um I2C-Sensorik oder 1wire anzubinden.

[Beta-User]

Kleines Zwischenupdate noch zu dem 4-fach-Taster (Tuya ZigBee Remote Scene Controller 4-Gang-WLAN-12-Szenen-Switch):

Bin mal wieder über "deCONZ" ne "phoscon" gestolpert. Nachdem ich in deCONZ-GUI ein wenig rumgespielt habe und auch die Detailinfos zu den Kanälen irgendwann irgendwie abgerufen waren (k.A., wie genau, und ob bzw. wieviele/welche weitere Tastendrücke im Detail erforderlich waren), war das Ding in der HUEBridge als Sensor gelistet und konnte dann auch als HUEDevice angelegt werden.

ABER: Es "kann" kurz, Doppelklick und lang, wobei "Lang" wirklich "Lang" bedeutet und nur der Release-Event gefeuert wird (aber gefühlt auch nicht immer). Insgesamt kommt mir das ganze "träge" vor.

Fazit: Jedenfalls mit der vorliegenden firmware ist der keine ernsthafte Konkurrenz zu dem opple, der nur unwesentlich mehr kostet.


OT:
Ich muß immer den Stick umziehen, wenn ich deCONZ-GUI haben will, weil ich (noch) keinen Schimmer habe, wie man ggf. auf dem ansonsten headless laufenden FHEM-Server einen Minimalst-xserver aufzieht und ggf. die GUI darüber an einem anderen, entfernten Rechner verfügbar macht. Also falls da jemand irgendwo was DAU-verständliches in seiner Linkliste stehen hat und das posten könnte, würde mir das das Leben mit diesen chinesischen Drachen insgesamt erleichtern. Evtl. bekommt man so dann auch die anderen Biester gebändigt, denn wie gesagt: die sind schon ins Mesh eingebunden, nur eben nicht so ohne weiteres steuer- bzw. auslesbar...

[KyleK]

Teil 3 - Sonoff Bewegungsmelder (SNZB-03):

Die sind tatsächlich relativ klein . Nur leider werden sie - derzeit & entgegen der Angabe bei blakadder - von deconz auch noch nicht unterstützt, es gelang mir nicht mal, da die Detailinfos zu Manufacturer und Produkt-ID über deCONZ-GUI rauszufinden, integrieren ließen sie sich aber.

Mein SNZB-03 kam heute, und er lies sich ohne Probleme in deCONZ (v2.5.88) einbinden.
Wird in Phoscon angezeigt, und in FHEM lässt er sich auch einbinden.

Nur sein Verhalten ist etwas...seltsam.
Ich hab den Eindruck der löst nicht sehr zuverlässig aus.
Ich beobachte.

[Beta-User]

Es gibt die Dinger wohl unter zwei verschiedenen Hersteller- (oder Produkt-)Nummern, die 2. kommt mit dem nächsten update, wenn ich das richtig rausgelesen habe. Eilt aber nicht...

Aber das mit dem komischen Meldeverhalten war/ist auch da ein Thema.

[Beta-User]

So, eine Sonoff-ZigBee-Bridge hat mich nun auch erreicht. Selbstredend bekam die dann gleich zigbee2tasmota verpasst, und nach etwas rumspielen haben sich dann auch die Bewegungsmelderchen über diesen Weg einbinden lassen.

Eine Anleitung zum Flashen  siehe hier: https://zigbee.blakadder.com/Sonoff_ZBBridge.html.

Habe dann noch etwas an der tasmota2zigbee-attrTemplate-Geschichte rumgeschraubt und bei der Gelegenheit dann gleich auch eine erste Version für die Bewegungsmelder mit reingenommen. Unklar ist mir aber, ob nicht einer von denen beim Rumspielen seine ID geändert hat - war irgendwie komisch, aber näher untersuchen werde ich das erst mal nicht.

Da ich grade dabei war, gab's dann auch eine erste (ungetestete) Version für den Eurotronic Spirit, Details zum Entstehen (und ggf. zur Weiterentwicklung) gäbe es hier: https://forum.fhem.de/index.php/topic,116094.0.html.

Fazit dazu:
Wenn man zigbee2tasmota machen will, ist das m.E. die derzeit beste/einfachste Variante mit dem Sonoff-Teil, aber groß vertiefen werde ich selbst das nicht. Vermutlich werde ich bei Gelegenheit  nochmal die "without neutral" rausholen, v.a. um noch was mit dem zweikanaligen rumzuspielen.

Insgesamt ist die Aufbereitung der Infos aber auf diesem Weg relativ unkomfortabel, von daher werde ich jetzt darauf hoffen, dass die Sonoff dann mit der nächsten (beta-) deconz-Version gehen werden. Bis dahin wandern auch die in die "vielleicht für später"-Kiste.

CU,
Beta-User

[Mihca]

Ich habe kürzlich eine Sonoff-ZigBee-Bridge mit Tasmota geflasht und einen SONOFF SNZB-02 Temperatur-Feuchtigkeit Sensor angebunden. Funktioniert soweit. Allerdings verabschiedet sich der Sensor nach einigen Stunden und sendet nicht mehr. Als Gegenmaßnahme läuft ein Timer, der alle 30 Minuten nachsieht ob Readings aktualisiert wurden. Wenn nicht, wird ein "Restart" der Bridge durchgeführt. Danach empfängt die Bridge wieder. Für den Restart habe ich in der "setList" der Bridge Folgendes ergänzt (wäre ggfs. auch etwas für das Template):

Code Auswählen Erweitern

Restart:noArg cmnd/tasmota_D8DE0E/Restart 1

Bald erhalte ich SONOFF Door/Window Sensor SNZB-04. Melde mich nach Erfahrungen.

VG Achim

[Beta-User]

Danke für den Input, das mit restart kommt auf die "todo".

Für den SNZB-02 hätte mich interessiert, was der für Readings generiert bzw. ob das tasmota_zigbee2tasmota_generic_battery_sensor soweit paßt? (Wenn nein: Sollten wir aber an anderer Stelle vertiefen). Überhaupt sollte "man" sich mal betr. Reading-Benennung und Inhalt Gedanken machen, was wie in FHEM landen soll. Man kann zwar in FHEM prinzipiell jedes Event verwerten, aber für readingsGroups etc. oder das spätere Ersetzen von Devices ist es einfach zielführender, wenn das Zeug von vornherein "einheitlich" tickt; siehe akutell z.B. betr. Bewegungsmelder https://forum.fhem.de/index.php/topic,116310.0/topicseen.html.

Den SNZB-04 habe ich auch noch im Zulauf, aber der soll eigentlich auch am Ende via deconz eingebunden werden (und dann einen "wackeligen" CUL_HM-Sensor ersetzen).

[Mihca]

Der Sensor wurde nach Pairing mit der Bridge von Fhem automatisch mit den richtigen Readings angelegt. Hier die Readings:

Code Auswählen Erweitern

ZbReceived_0xE268_BatteryPercentage
ZbReceived_0xE268_BatteryVoltage
ZbReceived_0xE268_Device
ZbReceived_0xE268_Endpoint
ZbReceived_0xE268_Humidity
ZbReceived_0xE268_LinkQuality
ZbReceived_0xE268_Manufacturer
ZbReceived_0xE268_ModelId
ZbReceived_0xE268_Temperature

Darüber hinaus habe ich z.B wegen readingsGroup folgende Readings erzeugt:

Code Auswählen Erweitern

LWT wird als UserReading aus der Bridge geholt
Activity =LWT wird als UserReading aus der Bridge geholt)
battery wird wird von einem Timer als Setreading auf "ok" oder "low" (<2.4) gesetzt
batteryLevel wird als userReading aus dem Device geholt
humidity wird als userReading aus dem Device geholt
temperature wird als userReading aus dem Device geholt

VG Achim

[Beta-User]

...das nennst du "richtige Readings"...? Staun...

Versuch's mal mit dem attrTemplate "tasmota_zigbee2tasmota_generic_battery_sensor"

[Mihca]

... mit dem attrTemplate "tasmota_zigbee2tasmota_generic_battery_sensor" kommen keine Readings mehr an.

[Beta-User]

  ...muss ich mir ansehen; irgendwas ist da faul, wobei ich mir noch nicht sicher bin, ob das am attTemplate liegt oder an den Sensoren... (ich hatte neulich einen ähnlichen Effekt, aber dann festgestellt, dass sich mit ziemlicher Sicherheit die ID des betreffenden Sensors (in Tasmota/dem Topic) geändert hatte...!)

Kannst du dazu mal einen neuen Thread aufmachen und da je ein "vorher" und "nachher"-RAW-listing einstellen?

[Mihca]

Ich war voreilig. Mit dem attrTemplate "tasmota_zigbee2tasmota_generic_battery_sensor" kommen Readings. Die ausbleibenden Readings lagen an der Bridge. Die Readingbezeichnungen sind ok. Ich habe bei mir noch das Reading "batteryLevel" (wie bei HomeMatic) ergänzt.