Unbekanntes MQTT2 Device (readinglist) konfigurieren?

Begonnen von _Niemand_, 03 Juni 2019, 17:22:38

Vorheriges Thema - Nächstes Thema

_Niemand_

Liebes Forum,

leider komme ich allein hier nicht weiter, deshalb die Bitte an die MQTT2-Experten um Hilfe:

Ich habe ein RadmonPlus (Geigerzähler) der MQTT-fähig ist und der seine Meldungen an den FHEM-MQTT2-Server schicken soll.
Diese finde ich auch im Eventmonitor - aber ich habe keinen Plan (bzw. habe schon alles mögliche versucht) diese Meldung in Readings umzuwandeln.
Es sollte drei Readings geben: cpm/dose/rssi

Der Eventlog zeigt folgendes an:
2019-06-03 17:00:59 MQTT2_SERVER MQTT2_SERVER nrclients: 2
2019-06-03 17:00:59 MQTT2_SERVER MQTT2_SERVER UNKNOWNCODE autocreate/Geiger/cpm9
2019-06-03 17:00:59 MQTT2_SERVER MQTT2_SERVER /Geiger/cpm:9
2019-06-03 17:00:59 MQTT2_SERVER MQTT2_SERVER UNKNOWNCODE autocreate/Geiger/dose0.05
2019-06-03 17:00:59 MQTT2_SERVER MQTT2_SERVER /Geiger/dose:0.05
2019-06-03 17:00:59 MQTT2_SERVER MQTT2_SERVER UNKNOWNCODE autocreate/Geiger/rssi-63.00
2019-06-03 17:00:59 MQTT2_SERVER MQTT2_SERVER /Geiger/rssi:-63.00


Im FHEM-Log-File findet sich folgendes:
2019.06.03 17:02:22 5: CONNECT: (16)(30)(0)(4)MQTT(4)(194)(0)(15)(0)(0)(0)(14)MQTT USER NAME(0)(0)
2019.06.03 17:02:22 4: MQTT2_SERVER_192.168.178.93_55153  CONNECT V:4 keepAlive:15 usr:MQTT USER NAME
2019.06.03 17:02:22 5: PUBLISH: 0(15)(0)(11)/Geiger/cpm17
2019.06.03 17:02:22 4: MQTT2_SERVER_192.168.178.93_55153  PUBLISH /Geiger/cpm:17
2019.06.03 17:02:22 5: MQTT2_SERVER: dispatch autocreate\000\000/Geiger/cpm\00017
2019.06.03 17:02:22 3: MQTT2_SERVER: Unknown code autocreate/Geiger/cpm17, help me!
2019.06.03 17:02:22 5: PUBLISH: 0(18)(0)(12)/Geiger/dose0.10
2019.06.03 17:02:22 4: MQTT2_SERVER_192.168.178.93_55153  PUBLISH /Geiger/dose:0.10
2019.06.03 17:02:22 5: MQTT2_SERVER: dispatch autocreate\000\000/Geiger/dose\0000.10
2019.06.03 17:02:22 3: MQTT2_SERVER: Unknown code autocreate/Geiger/dose0.10, help me!
2019.06.03 17:02:22 5: PUBLISH: 0(20)(0)(12)/Geiger/rssi-64.00
2019.06.03 17:02:22 4: MQTT2_SERVER_192.168.178.93_55153  PUBLISH /Geiger/rssi:-64.00
2019.06.03 17:02:22 5: MQTT2_SERVER: dispatch autocreate\000\000/Geiger/rssi\000-64.00
2019.06.03 17:02:22 3: MQTT2_SERVER: Unknown code autocreate/Geiger/rssi-64.00, help me!
2019.06.03 17:02:24 4: Connection closed for MQTT2_SERVER_192.168.178.93_55153: EOF


Also irgendwas mit den "autocreate" scheint ja eigenartig zu sein, aber leider habe ich keine Ahnung was ich da machen soll.

Wie muss ich nun ein MQTT2_DEVICE definieren, damit ich an die Werte von "cpm" und "dose" komme?
Hier ist mein erfolgloser Versuch:
defmod MQTT2_GeigerRadmonPlus MQTT2_DEVICE Geiger
attr MQTT2_GeigerRadmonPlus IODev MQTT2_SERVER
attr MQTT2_GeigerRadmonPlus autocreate 1
attr MQTT2_GeigerRadmonPlus readingList Geiger:/Geiger/LWT.* LWT\
Geiger:/Geiger/cpm:.* CPM\
Geiger:/Geiger/dose:.* DOSE
attr MQTT2_GeigerRadmonPlus room MQTT2_DEVICE


Wie geht es richtig???
Danke!

rudolfkoenig

Ich gehe davon aus, dass du die (mit der initialen fhem.cfg ausgelieferte) autocreate Instanz geloescht hast.
Bitte erneut anlegen mit
define ac autocreateoder selbst eine passende MQTT2_DEVICE/MQTT_GENERIC_BRIDGE Instanz definieren.

_Niemand_

... ich bin mir nicht bewußt, dass ich irgendeine autocreate Instanz gelöst hätte  :-\ (das Einbinden eines TasmotaSonSoff über MQTT2 hat übrigens ganz wunderbar - wie von selbst-  geklappt - das wird doch auch über autocreate gemacht, oder?) - ich habe jetzt das define ac autocreate ausgeführt...

Der Eventlog sieht jetzt leicht geändert aus....

2019-06-03 18:03:20 MQTT2_SERVER MQTT2_SERVER nrclients: 2
2019-06-03 18:03:20 MQTT2_SERVER MQTT2_SERVER UNKNOWNCODE autocreate=simple/Geiger/cpm18
2019-06-03 18:03:20 MQTT2_SERVER MQTT2_SERVER /Geiger/cpm:18
2019-06-03 18:03:20 MQTT2_SERVER MQTT2_SERVER UNKNOWNCODE autocreate=simple/Geiger/dose0.10
2019-06-03 18:03:20 MQTT2_SERVER MQTT2_SERVER /Geiger/dose:0.10
2019-06-03 18:03:20 MQTT2_SERVER MQTT2_SERVER UNKNOWNCODE autocreate=simple/Geiger/rssi-61.00
2019-06-03 18:03:20 MQTT2_SERVER MQTT2_SERVER /Geiger/rssi:-61.00
2019-06-03 18:03:22 MQTT2_SERVER MQTT2_SERVER nrclients: 1


Aber Readings bekomme ich immer noch keine... :'(

... und mein Problem ist ja gerade, dass meine Versuche eine eigene MQTT2_DEVICE Instanz aufzusetzten nicht fruchten...
Wenn man weiß, wie man aus den Meldungen im Log/Eventlog eine funktionierende MQTT2_DEVICE Instanz macht, dann ist das sicher ein Kinderspiel.... ich weiß es leider anscheinend nicht...  :(
Was müsste korrekterweise in der readingList stehen?

Beta-User

Kannst du mal die Versionsausgaben zu MQTT2.* liefern?

@Rudi: irgendwas kommt mir immer noch schräg vor, wenn "/" im Spiel ist als Topic-Beginn. Siehe auch den Nebenthread zu ESPEasy; da sind scheinbar auch die aktuellsten Module verwendet worden, und ich hatte neulich auch ein ähnliches Problem, das sich dann zwar ins Nirwana verabschiedet hat. Ich habe aber immer noch keinen Schimmer, warum...
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

_Niemand_

Aber gerne:

File                      Rev   Last Change

00_MQTT.pm                18719 2019-02-24 20:20:51Z hexenmeister
10_MQTT2_DEVICE.pm        19481 2019-05-29 07:44:56Z rudolfkoenig
00_MQTT2_SERVER.pm        18794 2019-03-05 10:56:08Z rudolfkoenig
10_MQTT_GENERIC_BRIDGE.pm 19528 2019-06-02 00:30:43Z hexenmeister

rudolfkoenig

#5
Sorry fuer den falschen Hinweis.
MQTT2_DEVICE unterschlaegt UNDEFINED (und damit das Anlegen), weil ClientID leer ist.
Das ist laut Spec auch nicht zulaessig: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349242
Hmmm. Wenn man es genau liest, ist ein leeres ClientID doch zulaessig :)

Wenn Du es nicht schaffst, dem Geraet ein nicht leeres MQTT-ClientID zu verpassen, dann muss du MQTT2_DEVICE samt readingsList selbst anlegen. D.h. bei readingsList entweder ":/Geiger/LWT.* LWT" oder "/Geiger/LWT.* LWT" spezifizieren.

Leider kann ich meine Theorie nicht einfach testen: mosquitto_pub weigert sich ein leeres ClientId zu senden.

Beta-User

@Rudi: Danke für's Analysieren.
Soll in die "Praxisbeispiele" ein Hinweis rein, dass man (iVm. MQTT2_SERVER) für autocreate eine CID verwenden muß?

@_niemand_: Schau mal nach, ob du jetzt 2 autocreate-Devices definiert hast. Du brauchst nur eines.
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

rudolfkoenig

ZitatSoll in die "Praxisbeispiele" ein Hinweis rein, dass man (iVm. MQTT2_SERVER) für autocreate eine CID verwenden muß?
Kannst Du gerne machen. Ich koennte auch ins Log was ausgeben, das wuerde aber fuer jedes empfangene, und nicht verstandene Nachricht passieren, deswegen bin ich noch unsicher.

Beta-User

Zitat von: rudolfkoenig am 04 Juni 2019, 09:16:28
Kannst Du gerne machen. Ich koennte auch ins Log was ausgeben, das wuerde aber fuer jedes empfangene, und nicht verstandene Nachricht passieren, deswegen bin ich noch unsicher.
Im Wiki habe ich jetzt einen roten Hinweiskasten eingebaut und gleich die "volatilen" Geräte mit abgefrühstückt...:
ZitatBeachten Sie, dass für autocreate in Verbindung mit MQTT2_SERVER '''zwingend''' jeder über MQTT kommunizierende Client eine ClientID angeben muß. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.
Zu viele log-Ausgaben sind m.E. nicht sinnvoll. Das hier ist nach meiner Kenntnis bisher der einzige Fall, in dem das aufgetreten ist, und das verwendete script kommt mir noch nicht "fertig" vor. Würde also eher dagegen votieren, zumal die Ursache jetzt ja lokalisiert ist und was im Wiki steht. Kann man also wiederfinden, wenn es mal wieder drauf ankäme (und man die logeinträge lesen/deuten kann).
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

rudolfkoenig

Danke.
Off-Topic: Das Wiki empfiehlt das setzten vom autocreate Attribut. Die autocreate Voreinstellung ist fuer MQTT2_SERVER simple, muss also nicht explizit gesetzt werden. Ich moechte vermeiden, dass die Leute das ohne Grund explizit setzen, damit eine Aenderung dieser Voreinstellung (sollte es je notwenidg sein) wirksamer ist.

Beta-User

Danke zurück!
Hab' das autocreate-Thema jetzt geändert und Hinweise zum default sowie simple und complex in eine Fußnote "verbannt". Stammte noch aus meinen MQTT2-Anfangstagen (=> Betriebsblind ::) )
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

_Niemand_

@Beta-User: ja, ich hatte in der Tat zwei autocreates... eins ist jetzt wieder gelöscht...

So.. bei mir läufts jetzt auch... nachdem ich ein paar Änderungen gemacht habe (welche genau die richtige war kann ich aber nicht sagen).
Also... ich habe mein Topic ohne "/" am Anfang eingestellt.
Dann die Readings entsprechend ohne CID am Anfang verändert
Und einmal das "autocreate" für den MQTT2_SERVER auf "complex" gestellt...
Dann kamen die Readings im MQTT2_DEVICE an...  ;D
(so jetzt habe ich das autocreate auf 0 gestellt und das verbose level wieder auf "normale" Werte damit das log nicht zu gemüllt wird).

Und nur der Vollständigkeit halber:
So sieht der log jetzt aus:
2019-06-05 17:43:47 MQTT2_SERVER MQTT2_SERVER nrclients: 2
2019-06-05 17:43:47 MQTT2_DEVICE MQTT2_GeigerRadmonPlus CPM: 19
2019-06-05 17:43:47 MQTT2_SERVER MQTT2_SERVER geiger/feeds/cpm:19
2019-06-05 17:43:47 MQTT2_DEVICE MQTT2_GeigerRadmonPlus DOSIS: 0.11
2019-06-05 17:43:47 MQTT2_SERVER MQTT2_SERVER geiger/feeds/dose:0.11
2019-06-05 17:43:47 MQTT2_DEVICE MQTT2_GeigerRadmonPlus RSSI: -60.00
2019-06-05 17:43:47 MQTT2_SERVER MQTT2_SERVER geiger/feeds/rssi:-60.00


und so das Device:
defmod MQTT2_GeigerRadmonPlus MQTT2_DEVICE geiger
attr MQTT2_GeigerRadmonPlus IODev MQTT2_SERVER
attr MQTT2_GeigerRadmonPlus readingList geiger/feeds/rssi:.* RSSI\
geiger/feeds/cpm:.* CPM\
geiger/feeds/dose:.* DOSIS\

attr MQTT2_GeigerRadmonPlus room MQTT2_DEVICE

setstate MQTT2_GeigerRadmonPlus 2019-06-05 17:43:47 CPM 19
setstate MQTT2_GeigerRadmonPlus 2019-06-05 17:21:33 DOSE 0.08
setstate MQTT2_GeigerRadmonPlus 2019-06-05 17:43:47 DOSIS 0.11
setstate MQTT2_GeigerRadmonPlus 2019-06-05 17:43:47 RSSI -60.00


Einziger Schönheitsfehler ist der "setstate MQTT2_GeigerRadmonPlus 2019-06-05 17:21:33 DOSE 0.08" - da hatte ich das Reading von "DOSE" auf "DOSIS" unbenannt, aber der Eintag ist immer noch da... wie kann man den löschen?

Beta-User

Schön, dass es jetzt geklappt hat, auch wenn "complex" für autocreate sicher nicht die Lösung war ;D .

Zum Rest:
"deletereading" in der commandref suchen (stell' die mal auf modular um, dann sieht man die eigentlich wichtigen Teile besser... ;) ).

Bitte dann den Thread noch als [gelöst] kennzeichnen (ja, kannst du selbst ;) .)
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