QNAP QIoT

ChristianKnorr · 19 Mai 2019, 19:05:12

Hallo Zusammen, das sind meine ersten Schritte mit MQTT, bitte nicht schlagen

fhem läuft auf einem Raspberry Pi mit USB-CUL und tut was er soll.
Ich möchte nun einzelne Readings an mein MQTT Server (QNAP QIoT Suite) senden, um im weiteren Schritt LED-Helligkeit eines ESP zu ändern.

In fhem habe ich 2 devices (MQTT + MQTT2_CLIENT) definiert, die auch beide "opened" anzeigen.
In einem TestDummy habe ich einen Slider 0-100 definiert.
Nun ist mir aber nicht klar wie dieser Wert den Server erreicht $:-\$
Im Dummy habe ich noch

Code Auswählen

mqttDefaults base={"fhem/testslider"} pub:qos=0 sub:qos=2 retain=0
mqttPublish state:topic={"/$base/$name"} state:qos=1 state:retain=0

Kann mir einer sagen was ich am NAS einstellen muss?

Tedious · 20 Mai 2019, 09:19:54

Wo läuft denn dein Broker? Auf FHEM oder aur NAS? Prinzipiell übermitteln alle Geräte Ihre Statusmeldung an den Broker, der wird wiederum von anderen Geräten abonniert die auf spiezifische Topics lauschen. Da Du MQTT2_Server nicht anführst gehe ich mal davon aus das entweder Mosquitto auf dem RPI oder ein anderer Broker auf dem NAS läuft? Das ist mir nach Deiner Beschreibung nicht ganz klar, ist das im Service QNAP QIoT Suite integriert?...

Was hast Du denn definiert? Im WIKI steht ja

Zitatdefine myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen

Die IP vom NAS? Läuft da der Broker?

Installier doch mal einen MQTT Client auf einem Rechner und lass ihn mal auf alles lauschen. Z.B. MQTT.fx

Beta-User · 20 Mai 2019, 09:48:51

Hmm, m.E. solltest du einen der möglichen Wege erst mal vollst. gehen (eigentlich brauchst du nicht 2 versch. IO-Typen, und eigentlich sollte es ohne weitere Konfiguration an deinem Broker funktionieren, oder braucht der eine Autentifizierung mit username/passowort => (für MQTT2_CLIENT:) allowed?).

Hier könntest du MQTT2_CLIENT mal auf autocreate "simple" stellen. Dann sollte ein Device angelegt werden. Bitte die Hinweise im Wiki bei MQTT2_CLIENT beachten (zu den "bridge- und Sammel Devices").

Wenn du nicht klarkommst oder Hilfe beim Anlegen/Erweitern einer für deinen Anwendungsfall passenden bridgeRegexp brauchst: bitte melden, am besten RAW-Definitionen hier einstellen.

ChristianKnorr · 20 Mai 2019, 18:41:56

QNAP QIoT ist der Broker, also auf dem NAS.

Code Auswählen

define mqttnas2 MQTT 192.168.178.48:21883
setuuid mqttnas2 <blabla>
attr mqttnas2 client-id <blabla>
attr mqttnas2 room MQTT

Ersetze blabla durch richtige Werte, wie gesagt, er zeigt "opened". Somit sind auch Username und Passwort richtig.
Mein Problem liegt wohl erstmal da, dass ich am Broker nichts empfange.

Beta-User · 20 Mai 2019, 19:09:41

OK, also nicht MQTT2_CLIENT, sondern die klassischen MQTT-Module...

Also müßte es entweder eine MQTT_GENERIC_BRIDGE geben oder eine MQTT_BRIDGE für den Dummy.

Hast du dazu ein list?

ChristianKnorr · 20 Mai 2019, 19:14:40

Habe mqtt.fx installiert.
Ich kann mein erstelltes "qiot/things/admin/aussenhelligkeit" abonnieren. Stattdessen auch "qiot/things/admin/+". Aber ich möchte doch "fhem/twilight/twilight" senden. Und da verlässt mich mein Grundlagenwissen

Ich verstehe das so, dass ich am Broker ein sendendes Device erstelle, und mit den dann erstellten Daten den Sender fütter'. Finde ich aber unlogisch, einen Sender gibt es doch schon, also muss ich doch am Broker einstellen: lausche auf fhem/raum/sensor oder liege ich da falsch?

Hier noch mein Twilight-Device, erweitert um mqttDefaults und mqttPublish (Werte in <> wie immer anonymisiert, aber richtig):

Code Auswählen

define Twilight Twilight <lat> <lon> 1 <wetter>
setuuid Twilight <id>
attr Twilight fp_Garten 237,281,1,
attr Twilight group Wetter
attr Twilight icon day_night
attr Twilight mqttDefaults base={"fhem/twilight"} pub:qos=0 sub:qos=2 retain=0
attr Twilight mqttPublish twilight|azimuth|elevation:topic={"/$base/$name"} twilight|azimuth|elevation:qos=1 twilight|azimuth|elevation:retain=0
attr Twilight room Garten,MQTT
attr Twilight stateFormat Außenlicht: twilight_weather%<br>Sonnenposition: azimuth°,<br>-höhe elevation°

ChristianKnorr · 20 Mai 2019, 19:21:19

Zitat von: Beta-User am 20 Mai 2019, 19:09:41
OK, also nicht MQTT2_CLIENT, sondern die klassischen MQTT-Module...

Hmmm da bin ich nicht sicher, ich habe ja sowohl MQTT als auch MQTT2_CLIENT. Sinnvoll??
Habe jedenfalls testweise das MQTT2_CLIENT gelöscht, und damit verschwinden auch die mqttDefaults und mqttPublish Einträge im Device. Also war MQTT2_CLIENT doch das Richtige?
EDIT: ne, mqttDefaults und mqttPublish war vorher schon weg :/ ich suche mal danach...

Zitat von: Beta-User am 20 Mai 2019, 19:09:41Also müßte es entweder eine MQTT_GENERIC_BRIDGE geben oder eine MQTT_BRIDGE für den Dummy.

Hast du dazu ein list?

Beta-User · 20 Mai 2019, 19:25:02

Zitat von: ChristianKnorr am 20 Mai 2019, 19:14:40
Ich verstehe das so, dass ich am Broker ein sendendes Device erstelle, und mit den dann erstellten Daten den Sender fütter'. Finde ich aber unlogisch, einen Sender gibt es doch schon, also muss ich doch am Broker einstellen: lausche auf fhem/raum/sensor oder liege ich da falsch?

Nope, der Broker ist einfach nur "dumm" und leitet ggf. weiter, was er erhält (an den, der sich für das interessiert).

Und bitte: Bleibe bei EINER Sache, komm nicht ständig mit was neuem.

Zitat von: Beta-User am 20 Mai 2019, 19:09:41
Also müßte es entweder eine MQTT_GENERIC_BRIDGE geben oder eine MQTT_BRIDGE für den Dummy.

Hast du dazu ein list?

Du scheinst also MQTT_GENERIC_BRIDGE-Device definiert gehabt zu haben. Das brauchst du, wenn du FHEM-Geräte "ver-mqtt-en" willst. Wenn es "nur" darum geht, MQTT sprechende Geräte (via externem Broker, mit MQTT2_SERVER könnte FHEM das auch ohne) einzubinden, bist du (m.E.) mit MQTT2_CLIENT einfacher dran.

ChristianKnorr · 20 Mai 2019, 19:49:45

Sorry für die Verwirrung, bin da noch neu in mqtt

Folgender ist-Zustand:
Ich habe ein MQTT definiert ("opened" also verbunden)
Ich habe eine MQTT_GENERIC_BRIDGE ...

... und wo ich so schreibe und in fhem gucke ... tot

Jetzt muss ich erstmal fhem reparieren, hab da wohl was kaputt gemacht

ChristianKnorr · 20 Mai 2019, 20:08:24

Okay, repariert. Habe alles was auf mqtt hört gelöscht. fhem läuft ohne Fehlermeldung.

Da Du mir ja mehrfach vorgeworfen zu viel auf einmal zu machen

.
Ich finde MQTT2_CLIENT aber nicht logisch, da ich dafür extra Devices anlegen muss. Richtig, oder vertue ich mich da?
Mein Favorit wäre MQTT, damit ich einzelne Devices die schon vorhanden sind mit mqtt nachrüsten kann.
Korrekt?

ChristianKnorr · 20 Mai 2019, 20:17:01

Code Auswählen

define mqttnas MQTT 192.168.178.48:21883
setuuid mqttnas 5ce2edb3-f33f-de61-747a-e60965e180408b29
attr mqttnas client-id <id>
attr mqttnas room MQTT

Steht auf "opened".
Die mqttDefaults und mqttPublish Attribute sind wieder da.

ChristianKnorr · 20 Mai 2019, 20:26:49

mqtt.fx habe ich QIoT vorgestellt und er verbindet richtig.
Ich habe qiot/things/admin/+ und qiot/things/admin/fhem/+ subscribed.
Aber wenn ich fhem hören will muss ich doch fhem/twilight/+ subsrciben. Das geht aber nicht.

Muss ich denn dem Broker nicht sagen: höre auf fhem/twilight/+ ?
Oben hieß es ja, der Broker ist dumm.
Da komm' ich nicht weiter

Beta-User · 20 Mai 2019, 20:28:07

Zitat von: ChristianKnorr am 20 Mai 2019, 20:08:24
Ich finde MQTT2_CLIENT aber nicht logisch, da ich dafür extra Devices anlegen muss. Richtig, oder vertue ich mich da?
Mein Favorit wäre MQTT, damit ich einzelne Devices die schon vorhanden sind mit mqtt nachrüsten kann.
Korrekt?

Nicht ganz. Siehe für einen Überblick https://wiki.fhem.de/wiki/MQTT#FHEM_und_MQTT.

Du kannst also genausogut CLIENT+GenericBridge zusammen nutzen (scheinbar dein Haupt-Usecase, anders als der erste Post suggeriert). "Richtig" unterschiedlich wird das eigentlich erst, wenn du "native" MQTT-Devices nutzt. Aber mit einer GenericBridge sollte autocreate abgeschaltet bleiben.

Zitat von: ChristianKnorr am 20 Mai 2019, 20:17:01
Code Auswählen Erweitern
define mqttnas MQTT 192.168.178.48:21883 setuuid mqttnas 5ce2edb3-f33f-de61-747a-e60965e180408b29 attr mqttnas client-id <id> attr mqttnas room MQTTSteht auf "opened".
Die mqttDefaults und mqttPublish Attribute sind wieder da.

Das sind aber 2 Paar Stiefel! Die Attribute kommen mWn NICHT von einem Device des TYPE MQTT...

Lies dich bitte ein, das hat so stochastisch kaum einen Sinn, die Stichworte sind alle mehrfach gefallen.

ChristianKnorr · 20 Mai 2019, 22:44:22

Mein Ziel ist es, einzelne Devices, die ich schon in fhem habe dazu bringen ihren Status (oder einzelne Readings) an einen mqtt Server zu senden.
Also habe ich mich entschieden ein Device des Types MQTT zu erstellen, und eben in jenen Devices mit mqttDefaults und mqttPublish zu arbeiten.
Eine Bridge - dachte ich - brauche ich dazu nicht.
Ist daran was falsch?

mqtt.fx empfängt jedenfalls nichts. $:-\$

Beta-User · 20 Mai 2019, 23:02:27

Zitat von: ChristianKnorr am 20 Mai 2019, 22:44:22
Eine Bridge - dachte ich - brauche ich dazu nicht.
Ist daran was falsch?

Ja, du brauchst entweder zusätzlich zum IO-Modul (gewählter TYPE hier: MQTT) eine MQTT_GENERIC_BRIDGE, oder (alt:) mehrere MQTT_BRIDGE-Devices; das müßte aber vorhanden sein, da du sonst die Attribute in (den eigentlich zu versendenden) Devices nicht hättest

Also nochmal: wir brauchen das Bridge-Device, bitte ein list davon liefern... und dann eben von einem weiteren Device, von mir aus das twilight-Dingens.
Hatte ich aber doch schon geschrieben und das steht auch alles auch in dem Anwendungs-Beispiel-Thread von Hexenmeister

.