[Neues Modul] Xiaomi Smart Home ohne Gateway direkt an FHEM

Begonnen von neumann, 22 Februar 2018, 18:00:22

Vorheriges Thema - Nächstes Thema

Beta-User

@Rudi:
Die xiaomi-bridge ist nur ein modifiziertes mqtt(1)-Device mit administrativen Aufgaben. Die eigentliche Datenquelle ist zigbee2mqtt - also genau das, was dir als Blaupause für das bridge-Attribut gedient hat.
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

mark79

Zitat von: rudolfkoenig am 08 November 2018, 23:42:07
Ja, bis man den richtigen bridgeRegexp gesetzt hat, da MQTT2_DEVICE sonst nicht weiss, wie man die Nachrichten zuordnen soll.

Wenn meine Vermutung stimmt, und der xiaomi Bridge alle Daten ueber die gleiche MQTT Verbindung sendet, dann wird auch beim MQTT2_SERVER nur ein MQTT2_DEVICE fuer die Bridge angelegt, und auch in diesem Fall muss man bridgeRegexp setzen.

Ich habe den MQTT2_Client ausprobiert, autocreate ist dort aktiviert. Das Modul hat mir ein MQTT2_mosquitto (MQTT2_DEVICE) erstellt, wo er alle Readings rein schreibt.

Ist das denn so richtig, wenn man in dieses MQTT2_DEVICE das bridgeRegexp attr setzt: attr MQTT2_mosquitto bridgeRegexp zigbee2mqtt/0x00158d0002([^:]*):.* "zigbee_$1"
mosquitto_sub: zigbee2mqtt/0x00158d0002006aa6 {"illuminance":54,"occupancy":true}


Weil gesplittet hat er mir damit leider nichts, also ein neues Device erstellt.

In Zigbee2mqtt unter mqtt habe ich eine client_id vergeben: client_id: 'zigbee'

Zitat von: Beta-User am 08 November 2018, 23:09:40
@mark79: Danke für's testen...
Gerne. :)
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

rudolfkoenig

ZitatIst das denn so richtig, wenn man in dieses MQTT2_DEVICE das bridgeRegexp attr setzt:
Eigentlich ja, aber dein MQTT2_mosquitto hat schon das passende readingsList gesetzt, deswegen wird autocreate nicht getriggert.
Ich habe es nachgestellt:

% mosquitto
...
fhem> define mc MQTT2_CLIENT 172.16.100.217:1883
fhem> attr mc autocreate
fhem> define ac autocreate
...
% mosquitto_pub -i zigbee_pi -h 172.16.100.217 -t zigbee2mqtt/0x00158d0002006aa6 -m '{"illuminance":54,"occupancy":true}'
...
# in FHEM wird ein MQTT2_mc angelegt. Wir entfernen die automatisch angelegte readingList und die Readings illuminance und occupancy
fhem> deleteattr MQTT2_mc readingList
fhem> deletereading MQTT2_mc .*
fhem> attr MQTT2_mc bridgeRegexp zigbee2mqtt/0x00158d0002([^:]*):.* "zigbee_$1"
...
% mosquitto_pub -i zigbee_pi -h 172.16.100.217 -t zigbee2mqtt/0x00158d0002006aa6 -m '{"illuminance":54,"occupancy":true}'
...
# Jetzt wird in FHEM das "richtige" MQTT2_zigbee_006aa6 angelegt, samt Attribut und Readings


Um diese Falle zu vermeiden habe ich MQTT2_DEVICE gerade angepasst: beim Setzen des bridgeRegexp Attributes wird readingList entfernt, und auch alle Readings, also das was ich hier manuell durchgefuehrt habe, entfaellt nach dem naechsten update (morgen ab 8).

mark79

Danke dir erstmal für die Mühe und Erklärung. :)

Ich habe mir die neue 00_MQTT2_CLIENT.pm und 10_MQTT2_DEVICE.pm aus dem SVN gezogen: https://svn.fhem.de/trac/changeset/17712/
Das scheint auf die schnelle zu funktionieren, also er hat mir zwei Devices angelegt. :)

Hat MQTT2_Client den selben Funktionsumfang wie der MQTT2_Server? Wichtig wäre mir on-for-timer bei den Ikea Zigbee Birnen und z.B. die Helligkeitsregelung aus dem Wiki, ob das auch mit MQTT2_Client funktioniert: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#IKEA-Tradfri-Birne

Ich habe hier leider gerade kein passendes Gerät, womit ich das Testen könnte.
Dann würde ich evtl. mein Hauptsystem am Wochenende darauf umstellen. Aber ich bin noch unsicher, ob ich MQTT2_Server oder MQTT2_Client verwenden soll. Ich persönlich würde eher den Client bevorzugen.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

rudolfkoenig

Deine Feature-Wuensche werden vom MQTT2_DEVICE bereitgestellt, ob es ueber MQTT2_CLIENT oder MQTT2_SERVER seine Daten bekommt, ist irrelevant.

MQTT2_CLIENT bietet nur bei autocreate einen schlechteren Service als MQTT2_SERVER, weil es nicht ueber die clientId der einzelnen MQTT Verbdindungen verfuegt. D.h. wenn du 100 "richtige" MQTT Geraete (z.Bsp. Sonoffs mit Tasmota) anbinden willst, dann wird MQTT2_SERVER fuer alle automatisch ein MQTT2_DEVICE erstellen, mit MQTT2_CLIENT darfst du alle manuell anlegen. Bei der Anbindung ueber Bridge gibt es keinen Unterschied.

mark79

@rudolfkoenig ok, das MQTT2_DEVICE das verarbeitet habe ich auch nicht gewusst, ich dachte das macht der SERVER/CLIENT.

Dann überlege ich mir das noch mal, ich bin zwar noch locker unter hundert Devices und habe bisher alles per Hand angelegt.. Aber ist es, für später evtl. geplant, das es auch für bekannte MQTT Geräte (Tasmota, ESPeasy, Zigbee2MQTT) ein autocreate über die Client clientId geben wird?

Ich finde einen externen Broker schon besser, wenn Fhem mal abschmieren sollte, dann funktioniert wenigstens noch die MQTT Verbindung untereinander. Der mosquitto-server ist sehr performant und sparsam an Ressourcen. Bei Snips (alexa in Opensource und lokal) werden z.B. die Audio Daten darüber übertragen und abgeschmiert, ist der mosquitto-server bei mir noch nie.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

rudolfkoenig

#531
ZitatAber ist es, für später evtl. geplant, das es auch für bekannte MQTT Geräte (Tasmota, ESPeasy, Zigbee2MQTT) ein autocreate über die Client clientId geben wird?
Das geht  mW nicht, das man vom clientId nicht auf dem Typ schliessen kann.
Aber ich habe vor ein Template Mechanismus zu bauen, mit dem man einfach(er) die Attribute setzen kann, weiterhin manuell.

ZitatBei Snips (alexa in Opensource und lokal) werden z.B. die Audio Daten darüber übertragen
Fuer sowas ist MQTT2_SERVER definitiv nicht vorgesehen.
Wie uebrigens auch das MQTT Protocol nicht.

mark79

Zitat von: rudolfkoenig am 09 November 2018, 20:51:20
Das geht  mW nicht, das man vom clientId nicht auf dem Typ schliessen kann.

Aber ich habe vor ein Template Mechanismus zu bauen, mit dem man einfach(er) die Attribute setzen kann, weiterhin manuell.
Fuer sowas ist MQTT2_SERVER definitiv nicht vorgesehen.
Wie uebrigens auch das MQTT Protocol nicht.
Man müsste die Geräte alle speziell benennen, habe ich bei mir aber nicht gemacht. Die heißen bei mir WZ_TV, KU_Kaffee etc. (die meistens laufen mit Tasmota und einige wenige mit ESPeasy).
Ein Template hört sich gut an. Ich lass mich mal überraschen, jedenfalls finde ich gut, das in MQTT mal Aufschwung aufkommt. :)

Und bzgl. Audio Übertragung über MQTT, das ist schon böse, aber beweist das der mosquito-server viel aushält. :D
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

sprudelverduenner

#533
Zitat von: Beta-User am 08 November 2018, 23:09:40
Du musst in der yaml eine ID vergeben, damit mqtt2_Server das identifiziert bekommt.

Danke für den Hinweis - auch das habe ich nun gelöst.

Mein wahrscheinlich letztes Problem ist der automatische Systemstart von npm.
Ich habe mich hier an die Wiki Anleitung gehalten und
Punkt 5. (Optional) Running as a daemon with systemctl
schon mehrmals durchgegangen - aber nach einem Neustart des Pi muss ich immer erst
systemctl status zigbee2mqtt.service
bevor es funktioniert...

Was könnte ich an Ausgabe posten oder wie aktiviere ich den LOG um der Sache auf die Schliche zu kommen?
Vielen Dank für Eure Hilfe vorab!

EDIT / Ergänzung:
Mit den Befehlen
sudo systemctl start zigbee2mqtt
oder
sudo systemctl stop zigbee2mqtt
kann ich jeweils den Dienst starten oder beenden. Ich sehe zwar keine LOG-Ausgaben in Putty - aber mein Xiaomi Device funktioniert wenn der Start Befehl gemacht wurde und geht nicht mehr wenn der Stop Befehl kam.
FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

gloob

Zitat von: sprudelverduenner am 10 November 2018, 10:53:27
Danke für den Hinweis - auch das habe ich nun gelöst.

Mein wahrscheinlich letztes Problem ist der automatische Systemstart von npm.
Ich habe mich hier an die Wiki Anleitung gehalten und
Punkt 5. (Optional) Running as a daemon with systemctl
schon mehrmals durchgegangen - aber nach einem Neustart des Pi muss ich immer erst
systemctl status zigbee2mqtt.service
bevor es funktioniert...

Was könnte ich an Ausgabe posten oder wie aktiviere ich den LOG um der Sache auf die Schliche zu kommen?
Vielen Dank für Eure Hilfe vorab!

Sicher, dass der Service nicht läuft?

Folgender Befehl fragt eigentlich nur den Status ab und startet den Service nicht.
systemctl status zigbee2mqtt.service
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

sprudelverduenner

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhh - Kommando zurück!

Alles geht - ich war lediglich zu ungeduldig. Mein Xiaomi Device ging ca. 30 Sekunden nach dem FHEM schon erreichbar war erst als Online an den Start.
Es scheint zu funzen.....

Danke Euch allen!
FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

mark79

Vielleicht hast du das enable vergessen, wenn der Dienst beim Neustart nicht startet:
ZitatNow that everything works, we want systemctl to start zigbee2mqtt automatically on boot, this can be done by executing:

sudo systemctl enable zigbee2mqtt.service
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

sprudelverduenner

 @mark79

Danke. Diesen Befehl hatte ich auch eingegeben .
Wie bereits geschrieben muss ich nach einem Neustart einfach mal 60 Sekunden warten bis von selber der Status des Viaomi Device von offline nach online wechselst.
FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

Mave

Moin,

ich nutze das klassische zigbee2mqtt Device und wollte jetzt eine Osram Steckdose über ein mqtt_device steuern.

Da zigbee2mqtt einen Wert im JSON Format erwartet, ist mir nicht klar, wie ich über publishSet einen JSON Wert übergeben kann.

Könnte mir bitte jemand den richtigen Weg zeigen?

Vielen Dank.

daniel2311

Hallo zusammen,
ich habe mal eine Anfängerfrage - ich habe so einen Xiaomi-Button (WXKG11LM).
Leider wird das Gerät, wenn ich einmal die Taste drücke, teileweise 5-6 events gefeuert! Ist das normal? Mache ich was falsch oder müsste ich irgendwie sagen, wenn das Event in einem gewissen Zeitraum x-mal gefeuert wird, führe ich meine Aktion nicht mehrfach aus?