[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE

Begonnen von betateilchen, 10 August 2018, 18:01:33

Vorheriges Thema - Nächstes Thema

betateilchen

In meinem Log habe ich folgende Meldung entdeckt, aber was da kurz vor 11 passiert ist, weiss ich nicht mehr.
Offenbar wurde irgendwo versucht, ein Attribut ohne einen Wert zu setzen.


2018.08.11 10:59:19 1: PERL WARNING: Use of uninitialized value $param in split at ./FHEM/10_MQTT2_DEVICE.pm line 277.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

Zitat von: betateilchen am 11 August 2018, 17:12:37
ich glaube man braucht das gar nicht, weil sich das meiste per notify lösen lässt :)
Grundsätzlich schon, es geht jedoch um Bequemlichkeit und ggf eine Reduzierung von Gerätezahl.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Billy

Zitat von: hexenmeister am 11 August 2018, 17:23:51
Grundsätzlich schon, es geht jedoch um Bequemlichkeit und ggf eine Reduzierung von Gerätezahl.
Und auch Benutzerfreundlichkeit für Otto Normalverbraucher.
Was natürlich für Profis wie "Betateilchen" anders aussieht.

Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

betateilchen

Es gibt nix benutzerfreundlicheres als ein notify, bei dem sich der Nutzer selbst darüber Gedanken macht, was er tun möchte und dann auch irgendwann versteht, was er tut.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#19
*grübel*

Warum funktioniert das sehr geniale MQTT2_JSON() eigentlich nicht, wenn man es mit $EVENT in einem notify ausserhalb eines MQTT2_DEVICE verwendet? Es kommt immer ein leerer hash zurück.

Edit: mit $EVTPART1 klappt es.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitat2018.08.11 10:59:19 1: PERL WARNING: Use of uninitialized value $param in split at ./FHEM/10_MQTT2_DEVICE.pm line 277.
Ich habe zwar keine Ahnung, wie du das hingekriegt hast, aber ich pruefe jetzt $param, und die Warnung sollte nicht mehr auftreten.
Eigentlich verhindert das attr Befehl, dass man diese Funktion ohne gesetzten $param aufruft.


ZitatFrage, läuft 00_MQTT2_SERVER auch mit 10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm?
Scheint zu klappen, auch wenn es an den neulichen xkcd erinnert :)define mq MQTT2_SERVER 1883
attr mq verbose 4
define mqcl MQTT localhost:1883
Im fhem-log sehe ich:
Zitat2018.08.12 11:04:23 4: mq_127.0.0.1_54781 Net::MQTT::Message[79791] CONNECT V:3 keepAlive:60
2018.08.12 11:04:23 4: mq_127.0.0.1_54781 Net::MQTT::Message[79791] PINGREQ


ZitatJa, aber als zusätzliches internal und nicht als reading. Das hilft mir nicht weiter.
Habs zu reading geaendert, bin aber unsicher, ob es keine Nebeneffekte hat (z.Bsp. bei shutdown). Wir werden es sehen.

Weitere Aenderungen:
- es gibt jetzt ein keepaliveFactor Attribut bei MQTT2_SERVER, mit dem man das von oasis geforderte "disconnect, falls nach 1.5-mal  keepalive keine Daten gekommen sind" aendern kann.
- das readingList regexp prueft jetzt auch gegen clientid:topic:message.
- ich habe erst autocreate eingebaut, und dann wieder aus :) => es gibt zu viele unterschiedliche topics, die man alle spezifizieren muss, alternativ darf man das automatisch angelegte Geraet nicht umbenennen, beide sind es nicht Wert.
- FHEM2FHEM modifiziert, damit man es mit RAW autocreate Module laedt. Leider beisst sich die Benutzung von FHEM2FHEM mit kein Support von autocreate, damit wird FHEM2FHEM fuer MQTT2_SERVER nur fuer Hartnaeckige empfohlen.
- die readingList perl Auswertung ist jetzt stabiler, bei Benutzerfehlern sollte FHEM nicht abstuerzen.

Wg. MQTT2_JSON: ich teste sowas in der Eingabezeile mit
fhem> { my $r = MQTT2_JSON('{"bla":"blaeh","hallo":"leute"}');; join("\n", map { "$_:$r->{$_}" } keys %{$r}) }
bla:blaeh
hallo:leute



betateilchen

Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
Ich habe zwar keine Ahnung, wie du das hingekriegt hast,

ich auch nicht.

Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
Habs zu reading geaendert, bin aber unsicher, ob es keine Nebeneffekte hat (z.Bsp. bei shutdown). Wir werden es sehen.

Danke.

Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
Wg. MQTT2_JSON: ich teste sowas in der Eingabezeile mit
fhem> { my $r = MQTT2_JSON('{"bla":"blaeh","hallo":"leute"}');; join("\n", map { "$_:$r->{$_}" } keys %{$r}) }
bla:blaeh
hallo:leute


MQTT2_JSON() wünsche ich mir als Funktion json2reading() in fhem.pl und dazu noch CommandSetReadingFromHash()
(oder eine entsprechend modifizierte Variante von CommandSetReading(), die einen hash akzeptiert)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

eldrik

Moin,

ich teste MQTT2_SERVER gerade um zu validieren ob ich auf Mosquitto verzichten kann.

Derzeit teste ich mit MQTT.FX und der Client verliert nachvollziehbar nach einem UNSUBSCRIBE die Verbindung zum Broker/Server.

Anbei das verbose 5 Log.

018.08.13 08:56:34.784 3: mqtt: port 1884 opened
2018.08.13 09:06:11.827 4: Connection accepted from mqtt_10.0.81.60_49768
2018.08.13 09:06:11.839 4: mqtt_10.0.81.60_49768 MQTT_FX_Client CONNECT V:3 keepAlive:60
2018.08.13 09:06:13.092 4: mqtt_10.0.81.60_49768 MQTT_FX_Client SUBSCRIBE
2018.08.13 09:06:13.092 4:   topic:home/garden/fountain qos:0
2018.08.13 09:06:14.641 1: M2: Unhandled packet UNSUBSCRIBE, disconneting mqtt_10.0.81.60_49768


Greetz
Eldrik

Billy

#23
Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
ZitatFrage, läuft 00_MQTT2_SERVER auch mit 10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm?
Scheint zu klappen, auch wenn es an den neulichen xkcd erinnert :)define mq MQTT2_SERVER 1883
attr mq verbose 4
define mqcl MQTT localhost:1883

[/code]
Den Wink mit dem Zaunpfahl "xkcd" habe ich verstanden.

Was macht
define mqcl MQTT localhost:1883

Ist mir nicht ganz klar.

Billy

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

betateilchen

Zitat von: Billy am 13 August 2018, 10:47:51
Was macht
define mqcl MQTT localhost:1883

Ist mir nicht ganz klar.

Naja, mit dem ersten define (MQTT2_SERVER) instanziierst Du zuerst einen MQTT Server (der von FHEM gebildet wird). (Quasi der Ersatz für den mosquitto)

Im zweiten define benutzt Du dann das bisher übliche Modul MQTT, um FHEM mit diesem Server (also sich selbst) zu verbinden.

Alle anschließend definierten Geräte MQTT_DEVICE (nicht MQTT2_DEVICE !) und MQTT_BRIDGE müssen dann das mit MQTT definierte IODev verwenden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitat2018.08.13 09:06:14.641 1: M2: Unhandled packet UNSUBSCRIBE, disconneting mqtt_10.0.81.60_49768
Wie es schon da steht: UNSUBSCRIBE habe ich nicht implementiert.
Kannst du dein Programm nicht ueberzeugen, es nicht zu senden? Und wozu macht es direkt nach SUBSCRIBE ein USUBSCRIBE? Ein DISCONNECT reicht doch :)
Wenn nicht, kannst du mir zeigen, wie ich das nachstellen kann, ohne Tage mit Installation von Programmen zu verbringen?

rudolfkoenig

ZitatWas macht "define mqcl MQTT localhost:1883"
Eine Verbindung zum MQTT Server aufbauen. Soweit ich als Laie sehe, brauchen beide (10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm) eine MQTT Instanz.

betateilchen

Zitat von: rudolfkoenig am 13 August 2018, 14:42:38
Wie es schon da steht: UNSUBSCRIBE habe ich nicht implementiert.

Das ist ja nicht schlimm, aber es ist auch kein Grund, deshalb die Verbindung abzubrechen  8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

hexenmeister

Zitat von: rudolfkoenig am 13 August 2018, 14:48:55
[...] brauchen beide (10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm) eine MQTT Instanz.
Ja. Dort wird leider kein fhem-dispath Mechanismus implementiert. Die Module sind sehr eng miteinander gekoppelt.  :(
Btw. Ist es ein Modul angedacht, mit dem man bestehende (externe) mqtt-Server (Broker) mit dem neuen MQTT2_DEVICE verwenden kann?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

ZitatIst es ein Modul angedacht, mit dem man bestehende (externe) mqtt-Server (Broker) mit dem neuen MQTT2_DEVICE verwenden kann?
Nicht von mir, sollte aber einfach sein, man muss Dispatch mit "clientid:topic:message" aufrufen, und MQTT2_DEVICE in Clients eintragen. Ueber einen externen MQTT Server duerfte clientid nicht bekannt sein, man muss als einen dummy verwenden. Wenn jemand so eine Erweiterung macht, bitte mir den Namen den Namen der dummy-clientid sagen (oder mosqpub.* verwenden), da ich mit dem "richtigen" clientid autocreate versuchen werde.