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

[nanocosmos]

Ich meine mal gelesen zu haben, dass man Debian Strech nutzen sollte.

[Byte09]

Ich meine mal gelesen zu haben, dass man Debian Strech nutzen sollte.

ja, steht irgendwo , läuft bei mir aber mit jessie problemlos .
stretch kann ich leider nicht nutzen , aufgrund des gattoo-lproblems.

gruss Byte09

[Omega]

@Byte09
- you made my day !!

Genau das war es.

Das mit Stretch bzw. Jessie hatte ich auch irgendwo gelesen. Das bezog sich aber mMn nur auf den Raspi. Und ich setze klassisch Debian in einer VM auf einem NUC ein.

LG
Holger

[eikehkb]

Hallo Forum,

ich habe hier von IKEA TRADFRI diese runde Fernbedienung https://www.ikea.com/de/de/catalog/products/30338849/. Hat das Jemand mit dem cc2531 ans Laufen gebracht?

Im FHEM wird die Fernbedienung erkannt. Bild im Anhang.
Es werden jedoch keine Tastenbefehle empfangen.

[Omega]

Kleines Feedback (hin und wieder taucht ja die Frage zu MQTT2 im thread auf):

Meine 1. Tests habe ich mit MQTT2 durchgeführt. Solange nur 1 Sensor im Spiel war, lief auch alles einwandfrei.
Probleme habe ich erst bekommen, als ich versucht habe, einen 2. Sensor mit einzubinden. Das schien auch zunächst funktioniert zu haben bis auf einmal immer andere Probleme auftauchten.
Ein Device war nicht mehr erreichbar, hatte jetzt ein Reading ,,type pairing". Trotz etlicher Anlernversuche bin ich nie über diesen Status hinweggekommen.
Im attr readingList des 2. Sensors waren beide Sensoren aufgeführt. Ich kenne mich mit MQTT nicht wirklich aus, es erschien mir aber merkwürdig, dass ein Sensor gleichzeitig auch auf einen anderen hören soll.
Nach einem "shutdown restart" wurde auf einmal wieder ein neues MQTT2-Device erkannt (dafür lief dann das bisher eingerichtete nicht mehr). Ich habe mehrfach neu aufgesetzt (vom Löschen der Sensoren mit anschließendem Neuanlernen bis zum Löschen der database.db.
Löschen der db hat allerdings nicht viel bewirkt. Nach einem Neustart war automatisch wieder alles da.

Heute habe ich noch einmal alles weggeschmissen und neu aufgesetzt (diesmal MQTT als Broker). Und mit dem hat dann auch alles funktioniert. 

Wo die Probleme letztendlich herkommen (MQTT2, zigbee2mqtt oder xBridge) kann ich nicht sagen, aber zumindest ist dieses Zusammenspiel (im Gegensatz zu MQTT) noch verbesserungsfähig.

LG
Holger

[Beta-User]

Hättest du eine ID vergeben in der yaml?

Für mqtt2 ist das nach meinen bisherigen Erfahrungen essentiell, im übrigen ist es einfacher zu handhaben...

[Neuhier]

MQTT2 ist IMHO noch Baustelle.
Habe auch tagelang experimentiert, eh es einigermaßen lief.
Das Bild ist gleich:
1 Sensor = keine Probleme
2. Sensor = wird erkannt, aber die Werte nur von Sensor 1 angezeigt.
Die Sensoren sind vereinzelt, falls danach gefragt werden sollte.
Wobei in der Anleitung dazu nix über Sensoren steht.
Egal. Erledigt. Abgehakt.

Mit MQTT selber ging es tagelang ohne Zicken. Das habe ich auch wieder draufgemacht - fertig.

[Beta-User]

Zu Sensoren kann ich nix sagen, gehe aber davon aus, dass - wie bei den Lampen auch - jeder seinen Pfad hat, auf den die messages mit den Readings kommen. Ein list von den vereinzelten Devices und dem Bridge-Gerät wäre gut, um deine These hier zu belegen, dass die Mqtt2-Module das durcheinander bringen und diesbezügliche Unklarheiten zu beseitigen - das klang von anderer Seite nämlich anders...

Nach meinem Eindruck ist es nicht MQTT2 gewesen, warum das tagelanges Experimentieren war. Bitte lass die Kirche im Dorf und bleibe fair! Dass die Doku dazu ggf. noch ergänzt werden kann, ist ausdrücklich was anderes...

[Omega]

Hättest du eine ID vergeben in der yaml?

Wenn du mit ID friendly_name meinst: ja, war eingestellt. In MQTT2 konnte ich aber keine Verbindung herstellen vom friendly_name zum Sensor. Beispiel: friendly_name: '0x00158d00022fdcd9' meldet sich per autocreate als MQTT2_mqttjs_ccfc4e0e. Im Device selber war weder in den Internals noch Readings eine Verbindung zwischen den beiden Bezeichnungen zu finden. Bei einem Sensor kein Problem, bei mehreren aber wohl. Ich habe dann den friendly_name in der yaml geändert. Den Sensor musste ich anschließend neu zuordnen, war aber kein Problem. Erst mit einem 2. Sensor wurde es dann problematisch - wie beschrieben.
Unter MQTT habe ich '0x00158d00022fdcd9' in den Internals stehen. So kann ich immer Rückschlüsse ziehen auf das eigentliche Device.

Grundsätzlich bin ich von MQTT2 überzeugt. Für FHEM ist das der richtige Weg, meine Tasmota-Devices laufen alle problemlos. Für mich als nicht MQTT-Versteher ist alles prinzipiell wesentlich einfacher. Nur eben nicht im Zusammenspiel von Xiaomi. Diese Verbindung ist verbesserungsfähig. Wie schon geschrieben weiß ich aber nicht, wo die Probleme tatsächlich zu suchen sind.

Lists kann ich leider nicht mehr zur Verfügung stellen (ich weiß, das wäre hilfreich) - momentan brauche ich auch ein wenig Abstand. Habe für diese eigentlich kleine Ergänzung erst mal viel zu viel Zeit verbraten.

LG
Holger

[Beta-User]

Nein, mit ID war was gemeint was client_id oder so ähnlich heißt; es handelt sich um eine eindeutige Kennung für dieses mqtt-Gerät...

[Neuhier]

@Beta-user
Müßte neues Thema werden, fehlt aber dann der Zusammenhang? Wenn doch, bitte verschieben.
MQTT2 mit Xiaomi/ Aqara wäre eine Idee.

MQTT2 liest 4 Sensoren ein, alle vorher entpairt, dann neu gepairt, da die ja schon bekannt waren.
Es erscheint im zigbee_pi aktuell 1 Sensor, die restlichen 3 werden bei Device_list aufgeführt.
Die Werte des, aktuell angezeigten, Devices werden auch sauber aufgeführt.
Aber auch nur diese, keine der anderen Sensoren.
Alles in/ aus den Readings im zigbee_pi.

Vereinzelt hatte ich über den Eintrag, der in zigbee_pi in ReadingsList steht ( untere Zeile ).
Beispiel:

Code Auswählen Erweitern

define 0x00158d0001d3887b MQTT2_DEVICE
attr 0x00158d0001d3887b readingList zigbee_pi:zigbee2mqtt/0x00158d0001d3887b:.* { json2nameValue($EVENT) }
So weit, so richtig?

In dem, von Dir erwähnten Beitrag meinerseits, ging es darum, daß ich den Stick nicht verbunden/ eingerichtet bekam.
Nach Löschung des Eintrages:

Code Auswählen Erweitern

include_device_information: true
bekam ich einen neuen MQTT2_Server angezeigt:

Code Auswählen Erweitern

mqtt2_fhem_server_127.0.0.1_48000
Seither geht der Stick wie erhofft.

Das hat aber keinen Einfluß auf die Devices, außer, daß die nun gelesen werden. 

Also klärend: MQTT2 ist mit Xiaomi anspruchsvoller, als erwartet.
Der Fehler sitzt immer wieder mal vor dem Monitor.
Die Aqara-Sensoren unter MQTT einbinden ist einfacher.

[Beta-User]

Du kannst das gerne in dem "läuft..." thread diskutieren.
Bei jedem der Sensoren müßte die Sensor-ID ("0x...") in der readingList eine andere sein (und nur diese eine enthalten). Ob das so ist, müsstest du nachsehen...

[Neuhier]

Ok, den obigen Beitrag nach "Läuft.." verlinken?

[mark79]

Ok, den obigen Beitrag nach "Läuft.." verlinken?

Gerne: https://forum.fhem.de/index.php/topic,91394.msg853541.html#msg853541

[sprudelverduenner]

Guten Abend zusammen,

ich hoffe Ihr könnt mir helfen. Seit 2 Tagen versuche ich schlussendlich den Xiaomi Cube mit dem Zigbee-USB-Stick in FHEM einzubinden - leider geht bei mir gar nichts und sehe vor lauter Anleitungen nicht mehr den Wald vor lauter Bäumen ....

Aber der Reihe nach. Ich denke das 1. Problem habe ich hier - wenn ich eingebe:

Code Auswählen Erweitern

cd /opt/zigbee2mqtt
npm start

Dann erhalte ich folgende Ausgabe:

Code Auswählen Erweitern

0 info it worked if it ends with ok
1 verbose cli [ '/root/.nvm/versions/node/v11.1.0/bin/node',
1 verbose cli   '/root/.nvm/versions/node/v11.1.0/bin/npm',
1 verbose cli   'start' ]
2 info using npm@6.4.1
3 info using node@v11.1.0
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle zigbee2mqtt@0.1.8~prestart: zigbee2mqtt@0.1.8
6 info lifecycle zigbee2mqtt@0.1.8~start: zigbee2mqtt@0.1.8
7 verbose lifecycle zigbee2mqtt@0.1.8~start: unsafe-perm in lifecycle true
8 verbose lifecycle zigbee2mqtt@0.1.8~start: PATH: /root/.nvm/versions/node/v11.1.0/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/opt/zigbee2mqtt/node_modules/.bin:/root/.nvm/versions/node/v11.1.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
9 verbose lifecycle zigbee2mqtt@0.1.8~start: CWD: /opt/zigbee2mqtt
10 silly lifecycle zigbee2mqtt@0.1.8~start: Args: [ '-c', 'node index.js' ]
11 silly lifecycle zigbee2mqtt@0.1.8~start: Returned: code: 1  signal: null
12 info lifecycle zigbee2mqtt@0.1.8~start: Failed to exec start script
13 verbose stack Error: zigbee2mqtt@0.1.8 start: `node index.js`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/root/.nvm/versions/node/v11.1.0/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:301:16)
13 verbose stack     at EventEmitter.emit (events.js:182:13)
13 verbose stack     at ChildProcess.<anonymous> (/root/.nvm/versions/node/v11.1.0/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:182:13)
13 verbose stack     at maybeClose (internal/child_process.js:970:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:257:5)
14 verbose pkgid zigbee2mqtt@0.1.8
15 verbose cwd /opt/zigbee2mqtt
16 verbose Linux 4.14.71-v7+
17 verbose argv "/root/.nvm/versions/node/v11.1.0/bin/node" "/root/.nvm/versions/node/v11.1.0/bin/npm" "start"
18 verbose node v11.1.0
19 verbose npm  v6.4.1
20 error code ELIFECYCLE
21 error errno 1
22 error zigbee2mqtt@0.1.8 start: `node index.js`
22 error Exit status 1
23 error Failed at the zigbee2mqtt@0.1.8 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]


Das ganze läuft auf einem RasPi 3.

Ich bin für jede Hilfe dankbar.

LG, Sprudelverduenner