FHEM Forum

FHEM - Hausautomations-Systeme => MQTT => Thema gestartet von: betateilchen am 10 August 2018, 18:01:33

Titel: [Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 10 August 2018, 18:01:33
Index: 00_MQTT2_SERVER.pm
===================================================================
--- 00_MQTT2_SERVER.pm  (Revision 17119)
+++ 00_MQTT2_SERVER.pm  (Arbeitskopie)
@@ -72,7 +72,7 @@
 {
   my ($hash) = @_;
   my $now = gettimeofday();
-  foreach my $clName (keys $hash->{clients}) {
+  foreach my $clName (keys %{$hash->{clients}}) {
     my $cHash = $defs{$clName};
     next if(!$cHash || !$cHash->{keepalive} ||
              $now < $cHash->{lastMsgTime}+$cHash->{keepalive}*1.5 );
@@ -335,7 +335,7 @@
     $hash->{retain}{$tp} = \%h;
   }
 
-  foreach my $clName (keys $hash->{clients}) {
+  foreach my $clName (keys %{$hash->{clients}}) {
     MQTT2_SERVER_sendto($defs{$clName}, $tp, $val) if(!$src || $src ne $clName);
   }
 
@@ -353,7 +353,7 @@
   my ($hash, $topic, $val) = @_;
   return if(IsDisabled($hash->{NAME}));
   $val = "" if(!defined($val));
-  foreach my $s (keys $hash->{subscriptions}) {
+  foreach my $s (keys %{$hash->{subscriptions}}) {
     my $re = $s;
     $re =~ s,/?#,\\b.*,g;
     $re =~ s,\+,\\b[^/]+\\b,g;
Titel: Antw:[Bug] 00_MQTT2_SERVER
Beitrag von: rudolfkoenig am 10 August 2018, 18:09:40
Danke, eingecheckt
Titel: Antw:[Bug] 00_MQTT2_SERVER
Beitrag von: betateilchen am 10 August 2018, 18:25:04
Haengt vom Perl version wohl ab, 5.18 meldet keine Fehler, 5.26 mag tatsaechlich nicht.

Naja, das Problem mit dieser Fehlermeldung diskutieren wir hier im Forum schon seit ca. 3 Jahren... (ich glaube, seit perl 5.24)



funktioniert:

readingList
obi/tele/08/STATE.* { MQTT2_JSON($EVENT) }

funktioniert nicht:

readingList
obi/tele/08/STATE { MQTT2_JSON($EVENT) }



In der commandref zum Server steht noch

Zitat
define <name> MQTT2_SERVER <tcp-portnr> [global|IP]

Enable the server on port <tcp-portnr>. If global is specified, then requests from all interfaces (not only localhost / 127.0.0.1) are serviced. If IP is specified, then FHEMWEB will only listen on this IP.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 10 August 2018, 19:10:03
2018.08.10 18:58:08 5: m2s: dispatch obi/tele/08/STATE:{"Time":"2018-08-10T17:58:08","Uptime":"0T00:42:57","Vcc":3.274,"POWER":"off","Wifi":{"AP":1,"SSId":"mowg","RSSI":100,"APMac":"CC:CE:1E:EA:A3:60"}}
2018.08.10 18:58:08 1: ERROR: empty name in readingsBeginUpdate
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBeginUpdate           called by ./FHEM/10_MQTT2_DEVICE.pm (87)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,Time,2018-08-10T17:58:08) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,Wifi_SSId,mowg) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,Uptime,0T00:42:57) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,Vcc,3.274) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,Wifi_APMac,CC:CE:1E:EA:A3:60) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,Wifi_AP,1) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,POWER,off) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: readingsUpdate(,Wifi_RSSI,100) missed to call readingsBeginUpdate first.
2018.08.10 18:58:08 1: stacktrace:
2018.08.10 18:58:08 1:     main::readingsBulkUpdate            called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2018.08.10 18:58:08 1:     main::MQTT2_DEVICE_Parse            called by fhem.pl (3783)
2018.08.10 18:58:08 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (342)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (279)
2018.08.10 18:58:08 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3587)
2018.08.10 18:58:08 1:     main::CallFn                        called by fhem.pl (723)
2018.08.10 18:58:08 1: ERROR: >mqtt_test< returned by the MQTT2_DEVICE ParseFn is invalid, notify the module maintainer

Ich habe den Verdacht, dass Änderungen an readingList und am device selbst (z.B. Löschen eines devices und späteres Neuanlegen mit gleichem Namen, aber anderer readingList) nicht richtig verarbeitet werden.



Es ist mir nun gelungen, eine umgeflashte Obi Steckdose in FHEM zu integrieren, allerdings - rein gefühlsmässig - ist die Reaktionszeit mit den neuen Modulen hier im lokalen Netzwerk langsamer als über einen mosquitto Server bei Amazon in Irland.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 10 August 2018, 19:25:15
Ist es eigentlich Absicht, dass das DEVICE Modul auch die 00_ am Anfang trägt?

äh... vergiss es :)

Du solltest aber den Eintrag in der MAINTAINER.txt für MQTT2_DEVICE korrigieren - da steht tatsächlich 00_MQTT2_DEVICE und wird deshalb auch in "help" so angezeigt. Das hatte mich irritiert.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 10 August 2018, 21:43:47
Danke fuer die Hinweise.
- MAINTAINER: korrigiert
- Doku fuer readingsList korrigiert, obi/tele/08/STATE.* ist richtig (sollte analog zu notify topic:message matchen)
- Doku fuer define MQTT2_SERVER korrigiert.
- delete Bug gefixt
- rename Bug gefixt (das habe ich selbst gefunden :) )
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 10 August 2018, 21:54:02
- Doku fuer readingsList korrigiert,

nur der Klarheit halber: readingList, ohne "s" in der Mitte (in der Doku steht es richtig)



Vorgestern habe ich mir extra noch einen lokalen mosquitto aufgesetzt, weil meine Steckdosen nicht ins Internet brauchen (und auch nicht kommen). Hätte ich gewusst, dass FHEM das ab heute selbst kann, hätte ich mir die Arbeit sparen können  8)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 10 August 2018, 22:11:07
für MQTT2_SERVER habe ich zwei Wünsche:


Edit:

* gefunden: STATE kommt aus TcpServerUtils.pm
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 11 August 2018, 09:01:43
Habe TcpServerUtils modifiziert, setze da state mit readingsSingleUpdate, allerdings ohne trigger. Bin auf Nebeneffekte gespannt.
In MQTT2_SERVER gibts jetzt ein NRCLIENTS.

Falls irgendwer bei SSL/TLS helfen will, wuerde ich mich freuen: in MQTT2_SERVER ist zwar TLS mit dem SSL Attribut aktivierbar, aber ich habe mit mosquitto_pub noch keine Verbindung herstellen koennen, und weiss nicht genau, wo das Problem liegt, ausser "es geht nicht".
Habe weiterhin FD in FileLog und global (fuer logfile) eingebaut, damit "list .* FD" bessere Daten liefert.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 11 August 2018, 10:44:29
In MQTT2_SERVER gibts jetzt ein NRCLIENTS.

Ja, aber als zusätzliches internal und nicht als reading. Das hilft mir nicht weiter :(

Szenario: Es geht darum, auf die Änderung der Anzahl ein notify triggern zu können, insbesondere für monitoring-Zwecke.
Beispiel: Wenn ich weiß, dass es 7 Steckdosen gibt und die Anzahl plötzlich auf 6 sinkt, weiss, ich dass etwas nicht stimmt.

Habe TcpServerUtils modifiziert, setze da state mit readingsSingleUpdate, allerdings ohne trigger.

Danke.

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Billy am 11 August 2018, 16:03:13
Frage, läuft 00_MQTT2_SERVER

auch mit 10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm?

Gruß Billy
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 11 August 2018, 16:32:02
Versuch macht kluch... aber ich würde mal auf "nein" tippen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: hexenmeister am 11 August 2018, 16:41:39
Wird nicht funktionieren. Die bisherigen Module sind sehr eng miteinander gekoppelt.
Die GenericBrigde ist von mir. Ich muss mir die neuen ansehen, evtl kann ich eine entsprechende Anpassung für die neuen Module erstellen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Billy am 11 August 2018, 17:04:36
Ich finde gut, dass das MQTT Thema jetzt in FHEM an Fahrt gewinnt!

Eine Bereinigung wäre für Neueinsteiger sicher sinnvoll.

Wenn ich das richtig verstanden habe ist "00_MQTT2_SERVER / 10_MQTT2_DEVICE"
nicht mit den bisherigen Bridges (10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm) verwendbar? schade  :-\

Eine MQTT2_GENERIC_BRIDGE.pm wäre dann die Lösung. ;)

Billy

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 11 August 2018, 17:12:37
Eine MQTT2_GENERIC_BRIDGE.pm wäre dann die Lösung. ;)

ich glaube man braucht das gar nicht, weil sich das meiste per notify lösen lässt :)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 11 August 2018, 17:14:06
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.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: hexenmeister am 11 August 2018, 17:23:51
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.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Billy am 11 August 2018, 17:35:34
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
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 11 August 2018, 21:55:23
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.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 12 August 2018, 12:59:57
*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.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 12 August 2018, 14:00:21
Zitat
2018.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.


Zitat
Frage, 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 (https://xkcd.com/2021/) erinnert :)define mq MQTT2_SERVER 1883
attr mq verbose 4
define mqcl MQTT localhost:1883
Im fhem-log sehe ich:
Zitat
2018.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


Zitat
Ja, 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

 
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 12 August 2018, 14:08:31
Ich habe zwar keine Ahnung, wie du das hingekriegt hast,

ich auch nicht.

Habs zu reading geaendert, bin aber unsicher, ob es keine Nebeneffekte hat (z.Bsp. bei shutdown). Wir werden es sehen.

Danke.

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)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: eldrik am 13 August 2018, 09:11:16
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
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Billy am 13 August 2018, 10:47:51
Zitat
Frage, 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 (https://xkcd.com/2021/) 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

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 13 August 2018, 14:12:14
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.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 13 August 2018, 14:42:38
Zitat
2018.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?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 13 August 2018, 14:48:55
Zitat
Was 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.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 13 August 2018, 14:52:37
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)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: hexenmeister am 13 August 2018, 15:01:30
[...] 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?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 13 August 2018, 15:17:16
Zitat
Ist 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.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: eldrik am 13 August 2018, 17:02:51
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?

Das mit der Implementierung habe ich mir gedacht  ;) und das Programm bediene ich ja, in dem Moment, selber um zu testen was bei einem Usubscribe passiert, theoretisch könnte ja jedes Mqtt Device Topics unsubscriben, ohne das es die Verbindung zum Broker vollständig beenden will.

Das deshalb die komplette Verbindung gedroped wird mag ein wenig hart sein.  :)

Mqtt.fx ist meine ich eine Java Anwendung, die Installation in meiner Mac VM hat keine 5Minuten gedauert, mit anderen Clients kann ich nicht dienen. Alternativ hat vl. Espeasy einen mqtt Client mit dem man Subscriben und Unsubscriben kann?

Greetz
Eldrik
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 13 August 2018, 18:02:12
Ansonsten hat die SAP Cloud Platform einen mqtt Client :)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Billy am 13 August 2018, 18:26:59
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.
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.
Danke für Eure Antworten, werde ich ausgiebig testen!
Billy
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: CoolTux am 13 August 2018, 20:27:53
Habe TcpServerUtils modifiziert, setze da state mit readingsSingleUpdate, allerdings ohne trigger. Bin auf Nebeneffekte gespannt.

Nebeneffekt???

https://forum.fhem.de/index.php/topic,90221.0.html
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 14 August 2018, 11:56:51
1)
Der Versuch ein gesetztes Attribut getList/setList/readingList für ein MQTT2_DEVICE zu löschen führt zu folgendem Fehler:
Sonoff_Testdevice attr getList/setList/readingList: more parameters needed
2)
Beim Versuch die Variable $name in getList/setList/readingList zu verwenden, erhalte ich einen Fehler:
on { "cmnd/".AttrVal($name,"MQTTName","")."/POWER on" }
off { "cmnd/".AttrVal($name,"MQTTName","")."/POWER off" }
Global symbol "$name" requires explicit package name at (eval 377) line 1.

LG Thomas
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 14 August 2018, 13:39:35
zu 1: es wäre schön, wenn Du geschrieben hättest, wie Du das Attribut löschen wolltest - funktioniert das "deleteattr" hinter der Anzeige nicht?
zu 2: die Variable heißt $NAME und nicht $name

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 14 August 2018, 14:26:45
zu 1: es wäre schön, wenn Du geschrieben hättest, wie Du das Attribut löschen wolltest - funktioniert das "deleteattr" hinter der Anzeige nicht?

deleteattr hinter der Anzeige oder alternativ deleteattr Devicename setList

zu 2: die Variable heißt $NAME und nicht $name

Ergebnis nach Änderung:
Global symbol "$NAME" requires explicit package name at (eval 28) line 1.
LG Thomas
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 14 August 2018, 14:54:51
deleteattr hinter der Anzeige oder alternativ deleteattr Devicename setList

Wie konntest Du überhaupt ein Attribut mit zu wenigen Parametern setzen, das Du jetzt löschen möchtest? Das muss sich wohl Rudi anschauen.

Ergebnis nach Änderung:
Global symbol "$NAME" requires explicit package name at (eval 28) line 1.

Dann schreib halt das Topic komplett mit dem tatsächlichen Namen in das Attribut.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 14 August 2018, 15:07:03
Wie konntest Du überhaupt ein Attribut mit zu wenigen Parametern setzen, das Du jetzt löschen möchtest? Das muss sich wohl Rudi anschauen.

Gar nicht. Ich hab's mit dem Code aus Rudis Ankündigung versucht und hätte somit gehofft dass du das Verhalten reproduzieren kannst.
define sonoff_th10 MQTT2_DEVICE
attr sonoff_th10 readingList tele/sonoff/S.* { MQTT2_JSON($EVENT) }
attr sonoff_th10 setList\
on tasmota/sonoff/cmnd/Power1 on\
off tasmota/sonoff/cmnd/Power1 off

deleteattr sonoff_th10 readingList
Ergebnis:  sonoff_th10 attr readingList: more parameters needed


LG Thomas
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 14 August 2018, 15:35:21
 ;D

Da hat Rudi sich selbst ausgetrickst...

  my ($type, $dev, $attrName, $param) = @_;

  if($attrName =~ m/(.*)List/) {
    my $type = $1;

    if($type eq "del") {
      MQTT2_DEVICE_delReading($dev) if($type eq "reading");
      return undef;
    }

Erst wird geprüft, ob $type eq "del" und dann auch gleichzeitig noch eq "reading" ist? Das wird schwierig zu erfüllen sein.

Lösungsvorschlag:

Index: 10_MQTT2_DEVICE.pm
===================================================================
--- 10_MQTT2_DEVICE.pm  (revision 17135)
+++ 10_MQTT2_DEVICE.pm  (working copy)
@@ -290,10 +290,10 @@
   my ($type, $dev, $attrName, $param) = @_;
 
   if($attrName =~ m/(.*)List/) {
-    my $type = $1;
+    my $atype = $1;
 
     if($type eq "del") {
-      MQTT2_DEVICE_delReading($dev) if($type eq "reading");
+      MQTT2_DEVICE_delReading($dev) if($atype eq "reading");
       return undef;
     }
 

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 14 August 2018, 19:37:15
Bei meinem anderen MQTT Server bekomme ich eine LWT Meldung. Bei dem hier leider nicht, ist das ein Fehler meinerseits oder liegt es am Server?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 14 August 2018, 20:53:33
die LWT gibt es in diesem Server auch. Mach mal ein "list <serverName>" dann siehst Du sie in den Internals unter "retain"
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 14 August 2018, 21:08:02
Ok da habe ich es gefunden, aber warum erstellt er unter dem eigentlichen Gerät kein eigenes Reading?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 14 August 2018, 22:16:07
Zitat
MQTT2_JSON() wünsche ich mir als Funktion json2reading() in fhem.pl und dazu noch CommandSetReadingFromHash()
Ich habe MQTT2_JSON als json2nameValue() nach fhem.pl kopiert, und da auch eine weitere Funktion json2reading implementiert, die mit dem has/Namen eines FHEM Geraetes und dem JSON aufgerufen werden muss. Ich habe MQTT2_JSON als Wrapper behalten, aber die Doku angepasst, d.h. MQTT2_JSON is deprecated. Achtung: json2nameValue ist _nicht_ die Umkehrfunktion zu toJSON, und soll es auch nicht sein.

Zitat
Das deshalb die komplette Verbindung gedroped wird mag ein wenig hart sein.  :)
Na was sonst soll ich machen? Die andere Seite erwartet eine klare Antwort, wenn ich nichts antworte, dann beendet sie die Verbindung. Ich habe jetzt UNSUBSCRIBE implementiert, kann es aber nicht testen, da ich nicht weiss, womit. SAP ist bei mir in der Kategorie "Tage mit Installation von Programmen verbringen"

Zitat
Da hat Rudi sich selbst ausgetrickst...
Das ist nicht zu leugnen. Habe mich von deinem Patch inspirieren lassen, und es hoffentlich gefixt.


Zitat
Global symbol "$NAME" requires explicit package name at (eval 28) line
Das habe ich nirgendwo zugesagt. Ich habe es jetzt an 4 Stellen eingebaut, allerdings nur oeberflaechlich getestet. Feedback is welcome.

Zitat
Ok da habe ich es gefunden, aber warum erstellt er unter dem eigentlichen Gerät kein eigenes Reading?
Weil die Geraete, wo LWT gespeichert wird, temporaer sind. MQTT2_DEVICE entspricht nicht 1:1 einer Verbindung zu MQTT2_SERVER. Das kann man zwar so konfigurieren, muss man aber nicht.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 14 August 2018, 22:36:43
Vielen Dank Rudi erstmal für die beiden Module, top!!!

Das habe ich nirgendwo zugesagt. Ich habe es jetzt an 4 Stellen eingebaut, allerdings nur oeberflaechlich getestet. Feedback is welcome.

Ich war am Holzweg und du zu schnell  :-[
Mea culpa!

Meine Idee war über ein User-Attribut "DeviceTopic" einen Teil des MQTT Topic vorzugeben und diesen dann für get,set,reading zu verwenden.
Mit AttrVal($NAME,....) ist das aber zu umständlich und spätestens bei den Readings klappt es nicht mehr.

Ich habe dann für mich testweise das Modul so umgeschrieben, dass es in getList/setList/readingList %TOPIC% durch den Wert des Attributes DeviceTopic ersetzt.
So sieht es dann für ein Sonoff/Tasmota-Device aus:
defmod HAUS.SONF.Steckdose MQTT2_DEVICE
attr HAUS.SONF.Steckdose DeviceTopic Sonoff-123456
attr HAUS.SONF.Steckdose IODev MQTTBroker
attr HAUS.SONF.Steckdose readingList tele/%TOPIC%/STATE:.* { MQTT2_JSON($EVENT) }\
stat/%TOPIC%/STATUS5:.* { MQTT2_JSON($EVENT) }\
stat/%TOPIC%/POWER:.* state\
tele/%TOPIC%/LWT:.* presence
attr HAUS.SONF.Steckdose setList on cmnd/%TOPIC%/POWER on\
off cmnd/%TOPIC%/POWER off\
statusRequest cmnd/%TOPIC%/Status 5

Würde es begrüssen wenn du das einbauen könntest, meinen Patch poste ich dann gerne.

LG Thomas
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 15 August 2018, 08:27:32
@ThoTo: kannst du mir erklaeren, warum man %TOPIC (was vmtl $NAME ist) im Topic ersetzt haben will?
Wenn ich es verstanden, und nicht fuer einen Sonderfall halte, baue ich es gerne ein.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 15 August 2018, 09:29:46
@ThoTo: kannst du mir erklaeren, warum man %TOPIC (was vmtl $NAME ist) im Topic ersetzt haben will?
Wenn ich es verstanden, und nicht fuer einen Sonderfall halte, baue ich es gerne ein.

Meine Geräte mit Tasmota haben um sie einfach zuordnen zu können als MQTT Topic "Sonoff-[MAC]" konfiguriert: Sonoff-AB12CF, Sonoff-450AF1 usw.
Schaltbefehle entsprechend mit cmnd/Sonoff-[MAC]/POWER, Status Messages kommen über tele/Sonoff-[MAC]/STATE herein.

In jedem MQTT2_DEVICE kommt das idente Topic in setList, getList, readingList mehrfach vor.
Ein konfigurierbares Topic (bzw. Topic Level) pro MQTT2_DEVICE kann einfach an einer Stelle geändert werden und muss eben nicht in x Attributen angepasst werden.

Mein Patch dazu sieht im Moment so aus:
Index: 10_MQTT2_DEVICE.pm
===================================================================
--- 10_MQTT2_DEVICE.pm  (revision 17140)
+++ 10_MQTT2_DEVICE.pm  (working copy)
@@ -40,11 +40,17 @@
 {
   my ($hash, $def) = @_;
   my @a = split("[ \t][ \t]*", $def);
-  my $name = shift @a;
-  my $type = shift @a; # always MQTT2_DEVICE
+
+  my ($name, $type, $dTopic) = @a;
   shift(@a) if(@a && $a[0] eq "autocreated");

-  return "wrong syntax for $name: define <name> MQTT2_DEVICE" if(int(@a));
+  return "wrong syntax for $name: define <name> MQTT2_DEVICE [<devicetopic>]" if(int(@a)>3);
+
+  if (defined($dTopic) && $dTopic ne "") {
+     $hash->{DEVICETOPIC} = $dTopic;
+  } else {
+     $hash->{DEVICETOPIC} = $name;
+  }

   AssignIoPort($hash);
   return undef;
@@ -57,6 +63,8 @@
   my ($iodev, $msg) = @_;
   my $ioname = $iodev->{NAME};
   my @ret;
+  my $dTopic;
+  my $code;

   sub
   checkForGet($$$)
@@ -71,15 +79,28 @@

   my ($cid, $topic, $value) = split(":", $msg, 3);
   my $dp = $modules{MQTT2_DEVICE}{defptr};
-  foreach my $re (keys %{$dp}) {
+  PARENT: foreach my $re (keys %{$dp}) {
+    my $rea = $re;
+    my $reb = $re;
+    $re =~ s/%DEVICETOPIC%/\.\*/g;
+
     next if(!("$topic:$value" =~ m/^$re$/s ||
               "$cid:$topic:$value" =~ m/^$re$/s));
-    foreach my $dev (keys %{$dp->{$re}}) {
+    foreach my $dev (keys %{$dp->{$rea}}) {
+      my $hash = $defs{$dev};
+
+      $dTopic = $hash->{DEVICETOPIC};
+      $code = $dp->{$rea}{$dev};
+      $reb = $rea;
+      $reb =~ s/%DEVICETOPIC%/$dTopic/g;
+
+      next if(!("$topic:$value" =~ m/^$reb$/s ||
+                "$cid:$topic:$value" =~ m/^$reb$/s));
+
       next if(IsDisabled($dev));
       my @retData;
-      my $code = $dp->{$re}{$dev};
+
       Log3 $dev, 4, "MQTT2_DEVICE_Parse: $dev $topic => $code";
-      my $hash = $defs{$dev};

       if($code =~ m/^{.*}$/s) {
         $code = EvalSpecials($code,
@@ -169,6 +190,9 @@
     shift @a;
     $cmd .= " ".join(" ",@a) if(@a);
   }
+
+  my $dTopic = $hash->{DEVICETOPIC};
+  $cmd =~ s/%DEVICETOPIC%/$dTopic/g;

   IOWrite($hash, split(" ",$cmd,2));
   return undef;
@@ -198,6 +222,10 @@
     shift @a;
     $cmd .= " ".join(" ",@a) if(@a);
   }
+
+  my $dTopic = $hash->{DEVICETOPIC};
+  $cmd =~ s/%DEVICETOPIC%/$dTopic/g;
+
   IOWrite($hash, split(" ",$cmd,2));
   return undef;
 }
@@ -306,7 +334,7 @@
   <a name="MQTT2_DEVICEdefine"></a>
   <b>Define</b>
   <ul>
-    <code>define &lt;name&gt; MQTT2_DEVICE</code>
+    <code>define &lt;name&gt; MQTT2_DEVICE [&lt;devicetopic&gt;]</code>
     <br><br>
     To enable a meaningful function you will need to set at least one of the
     readingList, setList or getList attributes below.<br>

Idee wäre das DeviceTopic als Parameter für define zu nehmen, das habe ich aber noch nicht eingebaut. Wird der Parameter im Define nicht gesetzt, wird %DEVICETOPIC% durch den Devicenamen, also Sonoff_Test ersetzt. Verwendung immer optional, da ja nur %DEVICETOPIC% ersetzt wird.

define Sonoff_Test MQTT2_DEVICE Test/Sub/Sonoff-123456
attr Sonoff_Test setList on cmnd/%DEVICETOPIC%/POWER on
Ergebnis: cmnd/Test/Sub/Sonoff-123456/POWER on

define Sonoff_Test MQTT2_DEVICE
attr Sonoff_Test setList on cmnd/%DEVICETOPIC%/POWER on
Ergebnis: cmnd/Sonoff_Test/POWER on


Ich hoffe etwas mehr Licht ins Dunkle gebracht zu haben  :D

Update: Patch angepasst, DEVICETOPIC kann im define mitangegeben werden.

LG Thomas
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 15 August 2018, 10:26:30
da ich nicht weiss, womit.

Auf meinem Android Telefon habe ich einen mqtt Client, mit dem ich beliebige topics subscriben und auch wieder unsubscriben (schreckliches Deutsch...) kann.

https://play.google.com/store/apps/details?id=in.dc297.mqttclpro

SAP ist bei mir in der Kategorie "Tage mit Installation von Programmen verbringen"

Das ist aber das Denken von SAP Leuten, die SAP seit 20 Jahren oder noch länger machen und den aktuellen Stand der Entwicklung in den vergangenen 10 Jahren nicht vollumfänglich kennen. Für die Nutzung der SAP Cloud Platform zu Testzwecken reicht ein S-User (bzw. sogar schon ein kostenfreier P-User). Alles andere passiert online und Du brauchst nur einen Browser auf Deinem Laptop.

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 15 August 2018, 10:28:56
Wenn ich es verstanden, und nicht fuer einen Sonderfall halte, baue ich es gerne ein.

Ich halte das für einen Sonderfall. Normalerweise wird man in den topics der Geräte einen "sprechenderen" Namen konfigurieren, um sie auseinanderhalten zu können und nicht die letzten 6 Stellen der MAC Adresse.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 15 August 2018, 10:35:44
Ich halte das für einen Sonderfall. Normalerweise wird man in den topics der Geräte einen "sprechenderen" Namen konfigurieren, um sie auseinanderhalten zu können und nicht die letzten 6 Stellen der MAC Adresse.

Gut, dann gehen wir vom "Normalfall", also einem sprechenden Devicenamen "Gartenleuchte1" aus.
Das Attribut readingList wäre dann trotzdem mehrfach damit befüllt oder habe ich gerade einen Denkfehler?
tele/Gartenleuchte1/STATE:.* { MQTT2_JSON($EVENT) }
stat/Gartenleuchte1/STATUS5:.* { MQTT2_JSON($EVENT) }
stat/Gartenleuchte1/POWER:.* state
tele/Gartenleuchte1/LWT:.* presence

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 15 August 2018, 11:20:46
Das Attribut readingList wäre dann trotzdem mehrfach damit befüllt oder habe ich gerade einen Denkfehler?

Genau dafür und in dieser Form ist das Attribut vorgesehen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: hexenmeister am 15 August 2018, 11:35:27
Ich würde eine entsprechende Umsetzung auch befürworten. Macht alles kürzer, übersichtlicher und bei einem eventuellen Änderungsbedarf leichter und weniger fehleranfällig.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 15 August 2018, 11:41:34
Genau dafür und in dieser Form ist das Attribut vorgesehen.

Alles klar, hatte mich somit nicht ganz getäuscht.

Dann vereinfacht und generalisiert meine vorgeschlagene Änderung die Nutzung der Attribute indem Topic bzw. Topic Level nur mehr einmal pro MQTT2_DEVICE konfiguriert und in den einzelnen Attributen der Platzhalter %DEVICETOPIC% verwendet wird.


LG Thomas
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 15 August 2018, 17:56:38
Ok, die Idee mit dem DEVICETOPIC finde ich auch gut - der erste Ansatz mit dem Attribut-Gedöns war aber wirklich ein Holzweg :)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: eldrik am 16 August 2018, 09:24:46
Na was sonst soll ich machen? Die andere Seite erwartet eine klare Antwort, wenn ich nichts antworte, dann beendet sie die Verbindung. Ich habe jetzt UNSUBSCRIBE implementiert.
2018.08.16 09:19:51.311 4: mqtt_10.0.81.60_49738 MQTT_FX_Client SUBSCRIBE
2018.08.16 09:19:51.311 4:   topic:home/garden/fountain qos:0
2018.08.16 09:19:56.932 4: mqtt_10.0.81.60_49738 MQTT_FX_Client UNSUBSCRIBE
2018.08.16 09:19:56.933 4:   topic:home/garden/fountain

Danke funktioniert.

Greetz
Eldrik
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 16 August 2018, 09:57:29
Ok, die Idee mit dem DEVICETOPIC finde ich auch gut - der erste Ansatz mit dem Attribut-Gedöns war aber wirklich ein Holzweg :)

Sag ich doch  8)


Kurzes allgemeins Update:
Ich habe nun seit 24 Stunden meine Geräte von den alten MQTT Modulen auf MQTT2 inkl. dem Patch umgebaut sowie getestet und dabei keine Auffälligkeiten festgestellt.
Verhalten ist wie beabsichtigt, insbes. die Readings werden sauber erstellt/aktualisiert.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 17 August 2018, 00:44:34
Ich habe $DEVICETOPIC (Achtung, nicht %DEVICETOPIC) hinzugefuegt, da ueberall sonst auch $ verwendet wird. Der Wert ist entweder $NAME, oder das Attribut devicetopic, falls gesetzt. $DEVICETOPIC kann auch im perl Ausdruck verwendet werden.

Falls das Attribut autocreate beim MQTT2_SERVER gesetzt ist, und ein published topic nirgendwo verwendet wird, dann wird ein MQTT2_DEVICE mit dem clientId angelegt (optionaler Parameter beim define). Das readingList von diesem Geraet wird nach und nach so erweitert, dass es alle topics von dieser Quelle akzeptiert. Die so angelegten Geraete koennen auch umbenannt werden, da die Identifizierung anhand der clientid durchgefuehrt wird. Fuer den Normallfall empfehle ich den MQTT2_SERVER mit diesem Attribut anzulegen. Die Voreinstellung ist z.Zt. noch aus.

Weiternhin habe ich beim PUBLISH ein Bug gefixt, die Laenge fuer Daten > 127 Bytes wird jetzt richtig berechnet. Bisher ist bei solchen Daten mosquitto_sub mit dem Text "Error: A network protocol error occurred when communicating with the broker" abgebrochen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 17 August 2018, 18:44:56
Kann mir mal einer bitte den Platzhalter mit $NAME erklären!

defmod sonoff_bu_led MQTT2_DEVICE DVES_CCD0A7
attr sonoff_bu_led IODev m2s
attr sonoff_bu_led devicetopic sonoff_bu_led
attr sonoff_bu_led event-on-change-reading .*
attr sonoff_bu_led eventMap on:ON off:OFF
attr sonoff_bu_led readingList DVES_CCD0A7:tele/sonoff_bu_led/STATE:.* { json2nameValue($EVENT) }\
DVES_CCD0A7:tele/sonoff_bu_led/LWT:.* sonoff_bu_led/LWT\
DVES_CCD0A7:cmnd/sonoff_bu_led/POWER:.* sonoff_bu_led/POWER\
DVES_CCD0A7:tele/sonoff_bu_led/INFO1:.* { json2nameValue($EVENT) }\
DVES_CCD0A7:tele/sonoff_bu_led/INFO2:.* { json2nameValue($EVENT) }\
DVES_CCD0A7:tele/sonoff_bu_led/INFO3:.* { json2nameValue($EVENT) }\
DVES_CCD0A7:stat/sonoff_bu_led/RESULT:.* { json2nameValue($EVENT) }\
DVES_CCD0A7:stat/sonoff_bu_led/POWER1:.* sonoff_bu_led/POWER1\
DVES_CCD0A7:tele/sonoff_bu_led/UPTIME:.* { json2nameValue($EVENT) }
attr sonoff_bu_led room MQTT2_DEVICE
attr sonoff_bu_led setList on cmnd/$NAME/POWER1 on\
off cmnd/$NAME/POWER1 off
attr sonoff_bu_led stateFormat POWER1

$NAME wird bei mir einfach so weiter geleitet.

$DEVICETOPIC funktioniert bei mir,

und LWT wird leider immer noch nicht im Device angezeigt trotz per Autocreate erstelle readingList.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 17 August 2018, 19:15:15
ach und noch etwas,
z.B. bei dem Topic
tele/sonoff_bu_led/INFO1
{"Module":"Sonoff S2X","Version":"6.1.1c","FallbackTopic":"DVES_CCD0A7","GroupTopic":"sonoffs"}

werden keine Readings erzeugt.
Versucht habe ich
DVES_CCD0A7:tele/sonoff_bu_led/INFO1:.* { MQTT2_JSON($EVENT) }oder
DVES_CCD0A7:tele/sonoff_bu_led/INFO1:.* { json2nameValue($EVENT) }
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 17 August 2018, 19:18:59
Zitat
Kann mir mal einer bitte den Platzhalter mit $NAME erklären!
Ist der Name der MQTT2_DEVICE Instanz. Kann im readingsList verwendet werden, wenn es Perl ist.

Zitat
und LWT wird leider immer noch nicht im Device angezeigt trotz per Autocreate erstelle readingList.
Beim autocreate ging der erste Wert eines Topics verloren, das habe ich jetzt gefixt.
Weiterhin gab es ein Problem beim bestimmen des Reading-Namens fuer einfache (nicht JavaScript) Readings, er sollte kein / enthalten. Das habe ich jetzt auch gefixt.

In deinem Fall muesstest du entweder readingList direkt anpassen, oder auf dem update morgen warten, und nach dem FHEM-Neustart readingList entfernen.

Wg. dem DVES_CCD0A7 Readings: versuch es ohne CID, oder bitte anhand "list TYPE=MQTT2_SERVER" & Detailansicht verifizieren, dass CID richtig ist.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 17 August 2018, 19:25:42
Ok dann warte ich mal aufs update :)
Danke
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 17 August 2018, 19:58:02
Konnte nicht warten  ;D
Habe es aus dem SVN genommen, nun läuft alles super (Für meine zwecke) ;)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: warp10 am 17 August 2018, 23:07:53
Hi,
erstmal vielen Dank für das neue Modul! Das sollte für die meisten Fälle locker ausreichen!

Bin gerade am rumspielen und bekomme immer nur folgendes im Log:

2018.08.17 22:45:36 4: Connection accepted from mqtt2_server_192.168.2.104_56853
2018.08.17 22:45:36 4: mqtt2_server_192.168.2.104_56853  CONNECT V:4 keepAlive:60
2018.08.17 22:45:44 2: mqtt2_server_192.168.2.104_56853 PUBLISH before CONNECT, disconnecting

Grüße, Thorsten
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 18 August 2018, 08:11:59
Zitat
PUBLISH before CONNECT, disconnecting
Was ist das fuer ein Client?
Kriegst du den clientId sonst raus?
Koenntest du den Verkehr irgendwie mitprotokollieren?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: warp10 am 18 August 2018, 13:47:42
Der Client ist ein python-Script um die Temperaturwerte von einem Bluetooth Grillthermometer zu erhalten. (siehe https://github.com/bjoernhoefer/igrill (https://github.com/bjoernhoefer/igrill))
Die relevanten Zeilen sind diese hier:
import time
import paho.mqtt.client as mqtt

mqtt_server = "127.0.0.1"
INTERVAL = 15

# MQTT Section
client = mqtt.Client()
client.connect(mqtt_server, 1883, 60)
client.loop_start()

if __name__ == '__main__':
 periph = IGrillV2Peripheral(ADDRESS)
 while True:
  temperature=periph.read_temperature()
  # Probe 1
  if temperature[1] != 63536.0:
   client.publish("bbq/probe1", temperature[1])

  # Probe 2
  if temperature[2] != 63536.0:
   client.publish("bbq/probe2", temperature[2])

  # Probe 3
  if temperature[3] != 63536.0:
   client.publish("bbq/probe3", temperature[3])

  # Probe 4
  if temperature[4] != 63536.0:
   client.publish("bbq/probe4", temperature[4])

  client.publish("bbq/battery", periph.read_battery())

  time.sleep(INTERVAL)

Mitprotokollieren muss ich mal schauen ob und was an der mosquitto config geändert werden muss.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 18 August 2018, 16:55:34
Habs gefixt. Workaround in deinem Script bis zum update:
client = mqtt.Client(client_id="myscript")
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: meier81 am 18 August 2018, 20:08:12
Hallo und guten Abend,

echt super Arbeit die du da gemacht hast, reicht für meine Sonoff-Geräte und mein Jarolift-Gateway locker aus. Habe nur eine Frage bezüglich LWT, mit mosquitto bekomme ich von meinen Geräten ein online bzw. offline im LWT-Reading nach kurzer Zeit sobald ich das Device trenne, das funktioniert aber mit dem MQTT2_DEVICE leider irgendwie nicht, habe da leider keine Idee mehr. Meine Definition sieht so aus zur Zeit:

define MQTT_Server MQTT2_SERVER 1883 global

define JaroliftDongle MQTT2_DEVICE
attr JaroliftDongle IODev MQTT_Server
attr JaroliftDongle readingList tele/jarolift-test/LWT:.* state\
  stat/jarolift-test/devicecounter:.* devicecounter

Sollte doch soweit alles korrekt sein. Der Wert online funktioniert auch, reading wird erneuert sobald ich den JaroliftDongle wieder unter Spannung setze, wenn ich ihn spannungslos mache sehe ich auch beim MQTT2_SERVER das die nrclients eins weniger werden, aber das reading bleibt auf online und ändert sich nicht zu offline.

Hat da jemand eine Idee von euch?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 18 August 2018, 20:16:06
Nimm mal:
attr JaroliftDongle readingList tele/jarolift-test/LWT:.* LWT
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: meier81 am 18 August 2018, 20:31:06
Nimm mal:
attr JaroliftDongle readingList tele/jarolift-test/LWT:.* LWT

Hab ich eben auch schon probiert, leider auch keine Änderung.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: meier81 am 18 August 2018, 20:43:33
Hab eben mal ein anderes Device ausprobiert, eine Sonoff S20 Steckdose mit Tasmota drauf, gleiches Problem. Hier die Config:

define SteckdoseMQTT2 MQTT2_DEVICE
attr SteckdoseMQTT2 IODev MQTT_Server
attr SteckdoseMQTT2 eventMap ON:on OFF:off
attr SteckdoseMQTT2 readingList tele/steckdose/LWT:.* LWT\
  stat/steckdose/POWER:.* state
attr SteckdoseMQTT2 room MQTT
attr SteckdoseMQTT2 setList ON cmnd/steckdose/POWER ON\
  OFF cmnd/steckdose/POWER OFF
attr SteckdoseMQTT2 webCmd on:off
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 18 August 2018, 20:47:15
lass mal den "\" hinter LWT\ weg
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: meier81 am 18 August 2018, 20:51:53
lass mal den "\" hinter LWT\ weg


Den brauch ich aber doch, habe doch zwei Einträge in readingList, da werden die Zeilen doch mit "\" getrennt. Ist aber auch nur die Ansicht der fhem.cfg, im Device im attr readingList sieht das ganze so aus:

tele/jarolift-test/LWT:.* LWT
stat/jarolift-test/devicecounter:.* devicecounter
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: warp10 am 18 August 2018, 22:10:52
Habs gefixt. Workaround in deinem Script bis zum update:

Top! Vielen Dank!
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 19 August 2018, 11:12:39
Zitat
mit mosquitto bekomme ich von meinen Geräten ein online bzw. offline im LWT-Reading nach kurzer Zeit sobald ich das Device trenne, das funktioniert aber mit dem MQTT2_DEVICE leider irgendwie nicht
War ein Bug, LWT wurde zwar an die MQTT Verbindungen geschickt, nicht aber an die MQTT2_DEVICE Instanzen.
Habs gefixt und eingecheckt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: meier81 am 19 August 2018, 13:20:00
War ein Bug, LWT wurde zwar an die MQTT Verbindungen geschickt, nicht aber an die MQTT2_DEVICE Instanzen.
Habs gefixt und eingecheckt.


Hab´s mir eben mal vom SVN runtergeladen und probiert, funktioniert einwandfrei! Echt super Arbeit, werde heute Abend mal den mosquitto deinstallieren.


Gruß Markus
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: MarkusN am 19 August 2018, 14:15:43
Sieht super aus, habe gerade erfolgreich ein device auf diese neuen Module umgezogen. Wie verhält es sich eigentlich mit dem retain flag? So wie ich es sehe gibt es bei einem manuellen publish die möglichkeit das retain flag zu setzen. Gibt es dafür auch ein Attribut pro device? Bei den meisten meiner Geräte nutze ich nämlich retain, da die sonoffs nicht die stabilste WLAN Verbindung haben.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 19 August 2018, 20:30:42
Habe mir die Version auch aus dem SVN geladen. Aber komischerweise kommt jetzt wenn ich den sonoff neu starte kurz eine Nachricht LWT Online und direkt danach LWT Offline.
Aber funktionieren noch...

Starte ich FHEM neu werden alle sonoffs als Online angezeigt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: eldrik am 20 August 2018, 15:04:25
Hi,

ich habe heute einmal den Test gewagt und wollte im ersten Anlauf das MQTT Modul sich mit dem MQTT2_SERVER Modul verbinden lassen, nach ein paar Minuten ist FHEM jedoch mit folgender Meldung im Log abgeschmiert.

2018.08.20 14:58:06.395 4: mqtt_10.0.83.104_49299 multi_1w_ds2408_voltA_D_water1_5_mqtt_KG PUBLISH multi_1w_ds2408_voltA_D_water1_5_mqtt_KG/volt.A:229.00
2018.08.20 14:58:06.397 5: mqtt: dispatch multi_1w_ds2408_voltA_D_water1_5_mqtt_KG:multi_1w_ds2408_voltA_D_water1_5_mqtt_KG/volt.A:229.00
decode_string: insufficient data at /usr/local/share/perl/5.24.1/Net/MQTT/Message/Publish.pm line 36.

Ist mein Perl zu alt?

Greetz
Eldrik
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: betateilchen am 20 August 2018, 16:47:16
und wollte im ersten Anlauf das MQTT Modul sich mit dem MQTT2_SERVER Modul verbinden lassen

wozu?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 20 August 2018, 19:05:15
Zitat
insufficient data at /usr/local/share/perl/5.24.1/Net/MQTT/Message/Publish.pm line 36.
Zur Klarstellung: das ist kein direktes Problem in den hier behandelten MQTT2* Modulen, es entsteht, wenn FHEM mit sich selbst ueber das MQTT Protokoll unterhaelt.

Zitat
wozu?
Eine solche Verbindung kann reizvoll sein, wenn man die "alten" MQTT_DEVICE Definitionen behalten moechte, und den externen MQTT Server (mosquitto) entfernen will. Allerdings will ich keine Energie hier reinstecken (vulgo: ich will es nicht debuggen), da diese Loesung ineffizient ist.

Zitat
Wie verhält es sich eigentlich mit dem retain flag?
Messages mit retain Flag werden jedem, der sich neu via MQTT verbindet, mitgeteilt, aber solche Messages ueberleben kein FHEM-Neustart . Diese Nachrichten werden ueber Dispatch (dir FHEM-Interne Verteilung der Nachrichten) nicht speziell gekennzeichnet, d.h. MQTT2_DEVICE Instanzen kriegen das nicht mit. Mit dem MQTT2_SERVER set kann man mit -r diesen Flag setzen.

Zitat
da die sonoffs nicht die stabilste WLAN Verbindung haben.
Wenn ich es richtig verstehe, geht es dir vornehmlich ums Senden, d.h. power soll explizit mitgeteilt werden, wenn ein sonoff sich neu verbindet.


Neu:
- Messages mit retain flag werden gespeichert, indem das RETAIN Reading vom Modul gesetzt wird. Achtung: dieses Reading erzeugt kein Event.
- falls man bei MQTT2_DEVICE setList den Topic mit dem :r Suffix versieht, dann wird das retain Flag gesetzt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: hexenmeister am 20 August 2018, 19:24:56
<OT>
Für einfache kleine MQTT-Szenarien (eine Handvoll MQTT-Clients) sind die neuen Module eine tolle Sache - schnelle und einfache Installation.
Allerdings verstehe ich nicht, welche Beweggründe man hat, wenn man bestehende Installationen auf die neuen Module umzieht. :o
Da FHEM nun Mal eine Single-Threaded-Anwendung ist, ist es generell eher eine bessere Idee, Funktionalität aus der FHEM-Installation auszulagern, nicht andersrum. Und dann kommen Klagen über eine schlechte Performance :(
</OT>
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: eldrik am 20 August 2018, 20:07:40
wozu?
wie Rudolf schon schrieb um im ersten Rutsch die bestehenden Devices nicht abändern oder gar doppelte Devices anlegen zu müssen.

Ich habe keine Bauchschmerzen mit meinem jetzigen Setup aus mosquitto und den jetzigen MQTT Modulen, wollte hier lediglich etwas zur Robustheit der neuen Module beitragen.

Greetz
Eldrik
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 20 August 2018, 23:08:31
Ich habe noch ein kleines problem:
Ich Steuer über MQTT meinen Fernseher doch leider ist in dem Befehl eine geschweifte klammer mit drin.

KEY_POWER cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772793023}Jetzt habe ich immer im log folgende Zeilen
2018.08.20 22:44:58 1: PERL WARNING: Argument "1T06:05:15" isn't numeric in numeric gt (>) at (eval 28497) line 4.
Kann ich in dem fall FHEM sagen er soll die Perl ebene ignorieren?

Edit: Der kam heute vorangestellt an die alte Meldung.
2018.08.21 09:10:57 1: PERL WARNING: Use of uninitialized value $k in hash element at ./FHEM/10_MQTT2_DEVICE.pm line 209.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: MarkusN am 21 August 2018, 14:49:32
Wenn ich es richtig verstehe, geht es dir vornehmlich ums Senden, d.h. power soll explizit mitgeteilt werden, wenn ein sonoff sich neu verbindet.

Neu:
- Messages mit retain flag werden gespeichert, indem das RETAIN Reading vom Modul gesetzt wird. Achtung: dieses Reading erzeugt kein Event.
- falls man bei MQTT2_DEVICE setList den Topic mit dem :r Suffix versieht, dann wird das retain Flag gesetzt.

Korrekt, und danke für die implementierung, scheint zu funktionieren. Im retain reading vom MQTT2_SERVER sehe ich allerdings zwei Einträge welche ich mir nicht erklären kann. ???
{"cmnd/sonoff2/power":"OFF","homeassistant/switch/sonoff2/config":"","homeassistant/switch/sonoff4/config":"","tele/sonoff2/LWT":"Offline","tele/sonoff4/LWT":"Offline"}Ich bin mir ziemlich sicher dass die beiden Topics mit "homeassistant" nicht aus meiner Konfiguration oder aus meinen Sonoffs kommen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 21 August 2018, 19:35:20
Zitat
Im retain reading vom MQTT2_SERVER sehe ich allerdings zwei Einträge welche ich mir nicht erklären kann
Ich leider auch nicht, ich kann dir aber zusichern, dass sowas nicht im Modul hartkodiert ist.
Wenn es Dir sorgen macht, dann ist die Aktivierung von allowed eine Option.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 21 August 2018, 20:04:18
@SamNitro: ich kann dein Problem anhand der gezeigten Daten nicht nachstellen, kannst du mir die komplette Definition der MQTT2_DEVICE und MQTT2_SERVER zeigen? Und bitte genau beschreiben, was man machen muss, um die Meldung zu provozieren.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 21 August 2018, 21:10:12
@SamNitro: ich kann dein Problem anhand der gezeigten Daten nicht nachstellen, kannst du mir die komplette Definition der MQTT2_DEVICE und MQTT2_SERVER zeigen? Und bitte genau beschreiben, was man machen muss, um die Meldung zu provozieren.

Ja, hier das Device:
defmod sonoff_TV_IR MQTT2_DEVICE DVES_0786C1
attr sonoff_TV_IR IODev m2s
attr sonoff_TV_IR devStateIcon ON:on OFF:off
attr sonoff_TV_IR devicetopic sonoff_TV_IR
attr sonoff_TV_IR event-on-change-reading .*
attr sonoff_TV_IR eventMap on:ON off:OFF
attr sonoff_TV_IR mqttPublish *:topic={"/out/$device/$reading"}
attr sonoff_TV_IR mqttSubscribe *:stopic={"/in/$device/$reading"}
attr sonoff_TV_IR readingList DVES_0786C1:tele/sonoff_TV_IR/LWT:.* LWT\
DVES_0786C1:cmnd/sonoff_TV_IR/POWER:.* POWER\
DVES_0786C1:tele/sonoff_TV_IR/STATE:.* { json2nameValue($EVENT) }\
DVES_0786C1:stat/sonoff_TV_IR/RESULT:.* { json2nameValue($EVENT) }\
DVES_0786C1:tele/sonoff_TV_IR/INFO1:.* { json2nameValue($EVENT) }\
DVES_0786C1:tele/sonoff_TV_IR/INFO2:.* { json2nameValue($EVENT) }\
DVES_0786C1:tele/sonoff_TV_IR/INFO3:.* { json2nameValue($EVENT) }\
DVES_0786C1:stat/sonoff_TV_IR/POWER:.* POWER\
DVES_0786C1:tele/sonoff_TV_IR/UPTIME:.* { json2nameValue($EVENT) }\
DVES_0786C1:stat/sonoff_TV_IR/UPGRADE:.* UPGRADE
attr sonoff_TV_IR room MQTT2_DEVICE,TV
attr sonoff_TV_IR setList on cmnd/$DEVICETOPIC/POWER on\
off cmnd/$DEVICETOPIC/POWER off\
reboot cmnd/$DEVICETOPIC/Restart 1\
otaurl cmnd/$DEVICETOPIC/otaurl\
update cmnd/$DEVICETOPIC/upgrade 1\
\
KEY_POWER cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772793023}\
KEY_VOLUP cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772833823}\
KEY_VOLDOWN cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772829743}\
KEY_MUTE cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772837903}\
KEY_1 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772784863}\
KEY_2 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772817503}\
KEY_3 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772801183}\
KEY_4 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772780783}\
KEY_5 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772813423}\
KEY_6 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772797103}\
KEY_7 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772788943}\
KEY_8 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772821583}\
KEY_9 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772805263}\
KEY_0 cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772811383}\
KEY_CHUP cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772795063}\
KEY_CHDOWN cmnd/sonoff_TV_IR/IRSend {"protocol": "SAMSUNG","bits": 32, "data": 3772778743}
attr sonoff_TV_IR stateFormat POWER

setstate sonoff_TV_IR 2018-08-21 10:41:44 FallbackTopic DVES_0786C1
setstate sonoff_TV_IR 2018-08-21 10:41:44 GroupTopic sonoffs
setstate sonoff_TV_IR 2018-08-21 10:41:44 Hostname sonoff_TV_IR-1729
setstate sonoff_TV_IR 2018-08-21 10:41:44 IPAddress 192.168.1.207
setstate sonoff_TV_IR 2018-08-21 10:32:05 IRSend Done
setstate sonoff_TV_IR 2018-08-21 10:43:02 LWT Offline
setstate sonoff_TV_IR 2018-08-21 10:41:44 Module Sonoff Basic
setstate sonoff_TV_IR 2018-08-21 10:40:49 OtaUrl http://192.168.1.2:80/firmware.bin
setstate sonoff_TV_IR 2018-08-21 10:42:14 POWER
setstate sonoff_TV_IR 2018-08-21 00:11:27 Restart Restarting
setstate sonoff_TV_IR 2018-08-21 10:41:44 RestartReason Software/System restart
setstate sonoff_TV_IR 2018-08-21 10:41:52 Time 1970-01-01T00:00:17
setstate sonoff_TV_IR 2018-08-21 10:41:22 UPGRADE Successful. Restarting
setstate sonoff_TV_IR 2018-08-21 10:40:57 Upgrade Version 6.1.1-minimal from http://192.168.1.2:80/firmware.bin
setstate sonoff_TV_IR 2018-08-21 10:41:52 Uptime 0T00:00:17
setstate sonoff_TV_IR 2018-08-21 10:41:52 Vcc 3.195
setstate sonoff_TV_IR 2018-08-21 10:41:44 Version 6.1.1.7
setstate sonoff_TV_IR 2018-08-21 10:41:44 WebServerMode Admin
setstate sonoff_TV_IR 2018-08-21 10:41:52 Wifi_AP 1
setstate sonoff_TV_IR 2018-08-21 10:41:52 Wifi_APMac E0:28:6D:24:E5:B0
setstate sonoff_TV_IR 2018-08-21 10:41:52 Wifi_RSSI 100
setstate sonoff_TV_IR 2018-08-21 10:41:52 Wifi_SSId PC

Hier der Server:
defmod m2s MQTT2_SERVER 1883 global
attr m2s autocreate 1
attr m2s room MQTT2,

setstate m2s 2018-08-21 21:05:05 RETAIN {"tele/sonoff_TV_IR/LWT":"Offline","tele/sonoff_bu_led/LWT":"Online","tele/sonoff_garage/LWT":"Online","tele/sonoff_ku_led/LWT":"Offline","tele/sonoff_trockner/LWT":"Offline","tele/sonoff_waschmaschine/LWT":"Offline"}
setstate m2s 2018-08-21 21:05:05 nrclients 7
setstate m2s 2018-08-21 10:29:33 state Initialized

Das komische ist das er zwischenzeitlich alleine produziert wird, aber auch immer wenn ich einen nicht Standard Befehl absetze. Sprich bei On/Off nicht aber z.B. Beim reboot(Sonoff) oder Key_1
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 22 August 2018, 08:47:56
Das Problem liegt an der leeren Zeile in setList zwischen upgrade und KEY_POWER, keiner hat gesagt, dass sowas zulaessig ist.

Ich habe das Modul geaendert, damit in solchen Faellen keine Warnung kommt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 22 August 2018, 12:43:11
Das Problem liegt an der leeren Zeile in setList zwischen upgrade und KEY_POWER, keiner hat gesagt, dass sowas zulaessig ist.

Ich habe das Modul geaendert, damit in solchen Faellen keine Warnung kommt.

Danke für deine mühe und Arbeit, da bei mir mein Garagen Kontakt keine Meldung mehr von sich gegeben hat per MQTT bin ich mal auf meine alte Konfiguration zurück gegangen, und muss zum bedauern feststellen das ich die Meldungen da auch schon hatte.

Doch leider kann ich bis jetzt den Ursprung nicht ermitteln, werde später dafür aber einen neuen Beitrag erstellen.

Sorry für die umstände.  :-[
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: gloob am 23 August 2018, 17:16:00
Hat jemand eine Idee, warum ich mein Tasmota nur OFF schalten kann aber nicht ON?

Eigentlich sollte er OFF schaltet werden und das passiert auch. Drücke ich allerdings auf ON, passiert nichts.

2018.08.23 17:14:07 4: mqtt_server_local_192.168.1.165_24791 DVES_4B76BD PUBLISH stat/sonoff11/RESULT:{"POWER":"OFF"}
2018.08.23 17:14:07 5: mqtt_server_local: dispatch autocreate:DVES_4B76BD:stat/sonoff11/RESULT:{"POWER":"OFF"}
2018.08.23 17:14:07 4: MQTT2_DEVICE_Parse: MQTT2_DVES_4B76BD stat/sonoff11/RESULT => { json2nameValue($EVENT) }
2018.08.23 17:14:07 4: mqtt_server_local_192.168.1.165_24791 DVES_4B76BD PUBLISH stat/sonoff11/POWER:OFF
2018.08.23 17:14:07 5: mqtt_server_local: dispatch autocreate:DVES_4B76BD:stat/sonoff11/POWER:OFF
2018.08.23 17:14:07 4: MQTT2_DEVICE_Parse: MQTT2_DVES_4B76BD stat/sonoff11/POWER => POWER
2018.08.23 17:14:09 4: mqtt_server_local_192.168.1.165_24791 DVES_4B76BD PUBLISH stat/sonoff11/RESULT:{"POWER":"OFF"}
2018.08.23 17:14:09 5: mqtt_server_local: dispatch autocreate:DVES_4B76BD:stat/sonoff11/RESULT:{"POWER":"OFF"}
2018.08.23 17:14:09 4: MQTT2_DEVICE_Parse: MQTT2_DVES_4B76BD stat/sonoff11/RESULT => { json2nameValue($EVENT) }
2018.08.23 17:14:09 4: mqtt_server_local_192.168.1.165_24791 DVES_4B76BD PUBLISH stat/sonoff11/POWER:OFF
2018.08.23 17:14:09 5: mqtt_server_local: dispatch autocreate:DVES_4B76BD:stat/sonoff11/POWER:OFF
2018.08.23 17:14:09 4: MQTT2_DEVICE_Parse: MQTT2_DVES_4B76BD stat/sonoff11/POWER => POWER
2018.08.23 17:14:10 4: mqtt_server_local_192.168.1.165_24791 DVES_4B76BD PUBLISH tele/sonoff11/SENSOR:{"Time":"2018-08-23T16:14:09","ENERGY":{"Total":0.349,"Yesterday":0.079,"Today":0.045,"Power":0,"Factor":0.00,"Voltage":0,"Current":0.000}}
2018.08.23 17:14:10 5: mqtt_server_local: dispatch autocreate:DVES_4B76BD:tele/sonoff11/SENSOR:{"Time":"2018-08-23T16:14:09","ENERGY":{"Total":0.349,"Yesterday":0.079,"Today":0.045,"Power":0,"Factor":0.00,"Voltage":0,"Current":0.000}}
2018.08.23 17:14:10 4: MQTT2_DEVICE_Parse: MQTT2_DVES_4B76BD tele/sonoff11/SENSOR => { json2nameValue($EVENT) }

Internals:
   CID        DVES_4B76BD
   DEF        DVES_4B76BD
   DEVICETOPIC MQTT2_DVES_4B76BD
   IODev      mqtt_server_local
   LASTInputDev mqtt_server_local
   MSGCNT     128
   NAME       MQTT2_DVES_4B76BD
   NR         817
   STATE      OFF
   TYPE       MQTT2_DEVICE
   mqtt_server_local_MSGCNT 128
   mqtt_server_local_TIME 2018-08-23 17:14:10
   READINGS:
     2018-08-23 17:14:10   ENERGY_Current  0.000
     2018-08-23 17:14:10   ENERGY_Factor   0.00
     2018-08-23 17:12:31   ENERGY_Period   1
     2018-08-23 17:14:10   ENERGY_Power    0
     2018-08-23 17:14:10   ENERGY_Today    0.045
     2018-08-23 17:14:10   ENERGY_Total    0.349
     2018-08-23 17:14:10   ENERGY_Voltage  0
     2018-08-23 17:14:10   ENERGY_Yesterday 0.079
     2018-08-23 12:02:01   FallbackTopic   DVES_4B76BD
     2018-08-23 12:02:01   GroupTopic      sonoffs
     2018-08-23 12:02:01   Hostname        sonoff11-5821
     2018-08-23 12:02:01   IPAddress       192.168.1.165
     2018-08-23 13:56:15   LWT             online
     2018-08-23 12:02:01   Module          BlitzWolf SHP2
     2018-08-23 17:14:09   POWER           OFF
     2018-08-23 12:02:01   RestartReason   Software/System restart
     2018-08-23 17:14:10   Time            2018-08-23T16:14:09
     2018-08-23 17:12:31   Uptime          0T05:10:35
     2018-08-23 17:12:31   Vcc             3.152
     2018-08-23 12:02:01   Version         6.1.1
     2018-08-23 12:02:01   WebServerMode   Admin
     2018-08-23 17:12:31   Wifi_AP         1
     2018-08-23 17:12:31   Wifi_APMac      F0:9F:C2:F4:E7:45
     2018-08-23 17:12:31   Wifi_RSSI       74
     2018-08-23 17:12:31   Wifi_SSId       HasenpupsExtreme
Attributes:
   IODev      mqtt_server_local
   devStateIcon ON:rc_GREEN:off OFF:rc_RED:on offline:rc_BLUE:off
   icon       message_socket
   readingList DVES_4B76BD:tele/sonoff11/LWT:.* LWT
DVES_4B76BD:cmnd/sonoff11/POWER:.* POWER
DVES_4B76BD:tele/sonoff11/INFO1:.* { json2nameValue($EVENT) }
DVES_4B76BD:tele/sonoff11/INFO2:.* { json2nameValue($EVENT) }
DVES_4B76BD:tele/sonoff11/INFO3:.* { json2nameValue($EVENT) }
DVES_4B76BD:stat/sonoff11/RESULT:.* { json2nameValue($EVENT) }
DVES_4B76BD:stat/sonoff11/POWER:.* POWER
DVES_4B76BD:tele/sonoff11/UPTIME:.* { json2nameValue($EVENT) }
DVES_4B76BD:tele/sonoff11/STATE:.* { json2nameValue($EVENT) }
DVES_4B76BD:tele/sonoff11/SENSOR:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    on cmnd/sonoff11/POWER on\
off cmnd/sonoff11/POWER off
   stateFormat {ReadingsVal($name,"precence","") eq "offline" ? "offline" : ReadingsVal($name,"POWER","")}
   verbose    5
   webCmd     on:off

Das folgende ist der Log für einmal ON:

2018.08.23 17:16:35 4: mqtt_server_local_192.168.1.165_24791 DVES_4B76BD PUBLISH stat/sonoff11/RESULT:{"POWER":"OFF"}
2018.08.23 17:16:35 5: mqtt_server_local: dispatch autocreate:DVES_4B76BD:stat/sonoff11/RESULT:{"POWER":"OFF"}
2018.08.23 17:16:35 4: MQTT2_DEVICE_Parse: MQTT2_DVES_4B76BD stat/sonoff11/RESULT => { json2nameValue($EVENT) }
2018.08.23 17:16:35 4: mqtt_server_local_192.168.1.165_24791 DVES_4B76BD PUBLISH stat/sonoff11/POWER:OFF
2018.08.23 17:16:35 5: mqtt_server_local: dispatch autocreate:DVES_4B76BD:stat/sonoff11/POWER:OFF
2018.08.23 17:16:35 4: MQTT2_DEVICE_Parse: MQTT2_DVES_4B76BD stat/sonoff11/POWER => POWER
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: schwatter am 23 August 2018, 18:14:30
Das sollte helfen:

falsch

on cmnd/sonoff11/POWER on\
off cmnd/sonoff11/POWER off

richtig

on cmnd/sonoff11/POWER on
off cmnd/sonoff11/POWER off

edit:

Außerdem konnte ich eben nachstellen, das z.B nach "POWER on" kein Leerzeichen sein darf.

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: schwatter am 23 August 2018, 18:44:32
Problem mit "state". Dieser ist immer "?.?.?."
Erst wenn z.B eine ReadingsVal gesetzt wird, habe ich meinen State.
Beabsichtigt oder Bug?

Zitat
attr Mqttdevice stateFormat {ReadingsVal($name,"LWT","") eq "offline" ? "offline" : ReadingsVal($name,"POWER","")}

Außerdem besteht das LWT- Onlineproblem immer noch. Shutdown restart hilft weiterhin hier.

Danke hier, für die Module :)

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 23 August 2018, 18:47:58

Außerdem besteht das LWT- Onlineproblem immer noch. Shutdown restart hilft weiterhin hier.


Ja war bei mir leider auch, und mein Read Kontakt von der Garage gab keine Meldung weiter.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 23 August 2018, 20:01:19
Zitat
Problem mit "state". Dieser ist immer "?.?.?."
state wird nicht gesetzt, es sei denn der Benutzer hat es konfiguriert.
Zitat
Außerdem besteht das LWT- Onlineproblem immer noch. Shutdown restart hilft weiterhin hier.
Was ist das "LWT-Onlineproblem?

Zu richtig vs. falsch: \ braucht man, wenn man fhem.cfg direkt editiert, oder in "raw definition". Sonst braucht mein kein \.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 23 August 2018, 20:13:30
Was ist das "LWT-Onlineproblem?
Er meint den ganz normalen LWT Status ob das Gerät Online oder Offline ist.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 23 August 2018, 20:22:35
Zitat
Er meint den ganz normalen LWT Status ob das Gerät Online oder Offline ist.
Das funktioniert bei mir, d.h. ich brauche ein "attr global verbose 5" FHEM-Log.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 23 August 2018, 22:04:07
Hatte jetzt mal eine alte Steckdose genommen mit einer alten Tasmota Firmware da schien es beim ersten mal zu gehen mit der neuen Firmware habe ich bei verbose 5 vom m2s diesen log:


2018.08.23 21:59:23 4: m2s_192.168.1.20_55363 MQTT_FX_Client PINGREQ
2018.08.23 21:59:25 4: Connection accepted from m2s_192.168.1.40_14569
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 CONNECT V:4 keepAlive:15 LWT:tele/sonoff_test/LWT:Offline usr:DVES_USER
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH tele/sonoff_test/LWT:Online
2018.08.23 21:59:25 5: m2s: dispatch autocreate:DVES_9F4497:tele/sonoff_test/LWT:Online
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH cmnd/sonoff_test/POWER:
2018.08.23 21:59:25 5: m2s: dispatch autocreate:DVES_9F4497:cmnd/sonoff_test/POWER:
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 SUBSCRIBE
2018.08.23 21:59:25 4:   topic:cmnd/sonoff_test/# qos:0
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 SUBSCRIBE
2018.08.23 21:59:25 4:   topic:cmnd/sonoffs/# qos:0
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 SUBSCRIBE
2018.08.23 21:59:25 4:   topic:cmnd/DVES_9F4497/# qos:0
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH tele/sonoff_test/INFO1:{"Module":"Sonoff S2X","Version":"6.1.1","FallbackTopic":"DVES_9F4497","GroupTopic":"sonoffs"}
2018.08.23 21:59:25 5: m2s: dispatch autocreate:DVES_9F4497:tele/sonoff_test/INFO1:{"Module":"Sonoff S2X","Version":"6.1.1","FallbackTopic":"DVES_9F4497","GroupTopic":"sonoffs"}
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH tele/sonoff_test/INFO2:{"WebServerMode":"Admin","Hostname":"sonoff_test-1175","IPAddress":"192.168.1.40"}
2018.08.23 21:59:25 5: m2s: dispatch autocreate:DVES_9F4497:tele/sonoff_test/INFO2:{"WebServerMode":"Admin","Hostname":"sonoff_test-1175","IPAddress":"192.168.1.40"}
2018.08.23 21:59:25 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH tele/sonoff_test/INFO3:{"RestartReason":"Power on"}
2018.08.23 21:59:25 5: m2s: dispatch autocreate:DVES_9F4497:tele/sonoff_test/INFO3:{"RestartReason":"Power on"}
2018.08.23 21:59:25 5: m2s: dispatch autocreate:DVES_9F4497:tele/sonoff_test/LWT:Offline
2018.08.23 21:59:25 4: Connection closed for m2s_192.168.1.40_19298: Connection reset by peer
2018.08.23 21:59:27 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH stat/sonoff_test/RESULT:{"POWER":"OFF"}
2018.08.23 21:59:27 5: m2s: dispatch autocreate:DVES_9F4497:stat/sonoff_test/RESULT:{"POWER":"OFF"}
2018.08.23 21:59:27 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH stat/sonoff_test/POWER:OFF
2018.08.23 21:59:27 5: m2s: dispatch autocreate:DVES_9F4497:stat/sonoff_test/POWER:OFF
2018.08.23 21:59:34 4: m2s_192.168.1.40_14569 DVES_9F4497 PUBLISH tele/sonoff_test/STATE:{"Time":"2018-08-23T20:59:33","Uptime":"0T00:00:15","Vcc":3.178,"POWER":"OFF","Wifi":{"AP":1,"SSId":"PC","RSSI":100,"APMac":"E0:28:6D:24:E5:B0"}}
2018.08.23 21:59:34 5: m2s: dispatch autocreate:DVES_9F4497:tele/sonoff_test/STATE:{"Time":"2018-08-23T20:59:33","Uptime":"0T00:00:15","Vcc":3.178,"POWER":"OFF","Wifi":{"AP":1,"SSId":"PC","RSSI":100,"APMac":"E0:28:6D:24:E5:B0"}}
2018.08.23 21:59:40 4: m2s_192.168.1.40_14569 DVES_9F4497 PINGREQ
2018.08.23 21:59:55 4: m2s_192.168.1.40_14569 DVES_9F4497 PINGREQ
2018.08.23 22:00:10 4: m2s_192.168.1.40_14569 DVES_9F4497 PINGREQ


Als würden die Geräte einen Offline senden was sie aber beim Mosquitto nicht tun!


bei global verbose 5: (mein gerät heißt sonoff_test)
Siehe Anhang
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 24 August 2018, 08:14:15
Zitat
...da schien es beim ersten mal zu gehen...
Ich betrachte das Problem als nicht vorhanden, bis ein Log das Gegenteil beweist :)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 24 August 2018, 11:13:00
Das einzige was ich anbieten kann ist der MQTT log bei einem Neustart des Device:

vom m2s Server:
pi@FHEM:~ $ mosquitto_sub -v -h localhost -p 1884 -t '+/sonoff_test/#'
tele/sonoff_test/LWT Offline
cmnd/sonoff_test/Restart 1
stat/sonoff_test/RESULT {"Restart":"Restarting"}
tele/sonoff_test/LWT Online
cmnd/sonoff_test/POWER (null)
tele/sonoff_test/INFO1 {"Module":"Sonoff S2X","Version":"6.1.1","FallbackTopic":"DVES_9F4497","GroupTopic":"sonoffs"}
tele/sonoff_test/INFO2 {"WebServerMode":"Admin","Hostname":"sonoff_test-1175","IPAddress":"192.168.1.40"}
tele/sonoff_test/INFO3 {"RestartReason":"Software/System restart"}
tele/sonoff_test/LWT Offline
stat/sonoff_test/RESULT {"POWER":"OFF"}
stat/sonoff_test/POWER OFF
tele/sonoff_test/STATE {"Time":"2018-08-24T09:59:20","Uptime":"0T00:00:15","Vcc":3.178,"POWER":"OFF","Wifi":{"AP":1,"SSId":"PC","RSSI":100,"APMac":"E0:28:6D:24:E5:B0"}}

vom mosquitto Server:
pi@FHEM:~ $ mosquitto_sub -v -h localhost -p 1883 -t '+/sonoff_test/#'
tele/sonoff_test/LWT Online
cmnd/sonoff_test/Restart 1
stat/sonoff_test/RESULT {"Restart":"Restarting"}
tele/sonoff_test/LWT Online
cmnd/sonoff_test/POWER (null)
tele/sonoff_test/INFO1 {"Module":"Sonoff S2X","Version":"6.1.1","FallbackTopic":"DVES_9F4497","GroupTopic":"sonoffs"}
tele/sonoff_test/INFO2 {"WebServerMode":"Admin","Hostname":"sonoff_test-1175","IPAddress":"192.168.1.40"}
tele/sonoff_test/INFO3 {"RestartReason":"Software/System restart"}
stat/sonoff_test/RESULT {"POWER":"OFF"}
stat/sonoff_test/POWER OFF
tele/sonoff_test/STATE {"Time":"2018-08-24T10:07:13","Uptime":"0T00:00:15","Vcc":3.178,"POWER":"OFF","Wifi":{"AP":1,"SSId":"PC","RSSI":100,"APMac":"E0:28:6D:24:E5:B0"}}

Kann es sein das der die Offline Nachricht nicht überschreibt oder im Speicher behält?
Wenn ich FHEM Neustarte dann sind die Nachrichten fürs erste korrekt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: MarkusN am 24 August 2018, 13:39:29
Ich habe ein ähnliches Problem, die meisten meiner Sonoffs zeigen im Reading LWT "offline" an, nur manchmal springen sie kurz auf online. Hier ein Beispiel aus dem Eventmonitor:

2018-08-24 13:35:29 MQTT2_SERVER mqtt_server nrclients: 6
2018-08-24 13:35:29 MQTT2_DEVICE sonoff4 LWT: Online
2018-08-24 13:35:29 MQTT2_DEVICE sonoff4 POWER:
2018-08-24 13:35:29 MQTT2_SERVER mqtt_server nrclients: 5
2018-08-24 13:35:29 MQTT2_DEVICE sonoff4 LWT: Offline
2018-08-24 13:35:30 MQTT2_DEVICE sonoff4 POWER: off

Hier sind zwei Dinge seltsam:
- MQTT2_SERVER meldet erst 6 devices (ich habe allerdings nur 5 MQTT2_DEVICE definiert), im weiteren Verlauf dann korrekterweise 5.
- Bevor das MQTT2_DEVICE auf offline geht kommt immer ein leeres POWER reading als Antwort.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 24 August 2018, 18:51:40
Zitat
- MQTT2_SERVER meldet erst 6 devices (ich habe allerdings nur 5 MQTT2_DEVICE definiert), im weiteren Verlauf dann korrekterweise 5.
Achtung, das sind nicht 6 Geraete, sondern 6 bestehende Netzwerkverbindungen. Wenn z.Bsp. einer der Geraete meint, die Netzwerkverbindung waere kaputt, und oeffnet eine Neue, ohne die Alte zu schliessen, dann sind eine Zeit lang mehr Verbindungen als Geraete.

Zitat
- Bevor das MQTT2_DEVICE auf offline geht kommt immer ein leeres POWER reading als Antwort.
Was ist eine "Antwort" in diesem Kontext?
Was ist der LWT der Verbindung (nicht Device!). Siehe "list TYPE=MQTT2_SERVER lwt"


Zitat
Kann es sein das der die Offline Nachricht nicht überschreibt oder im Speicher behält?
Ja, je nach Retain Flag Kombination. Z.Bsp. wenn das Geraet im CONNECT LWT als "Offline" ohne retain schickt und den gleichen Topic in darauffolgenden PUBLISH als "Online" mit retain, dann wird beim Verbindungsabbruch Offline gemeldet, aber neue MQTT-Clients bekommen Online.
Kannst du bitte die Ausgaben folgender Befehle hier anhaengen:list TYPE=MQTT2_SERVER lwt
list TYPE=MQTT2_SERVER cflags
list TYPE=MQTT2_SERVER RETAIN
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 24 August 2018, 19:01:14
list TYPE=MQTT2_SERVER lwt
m2s_192.168.1.40_20042     tele/sonoff_test/LWT:Offline
list TYPE=MQTT2_SERVER cflags
m2s_192.168.1.40_20042     238
list TYPE=MQTT2_SERVER RETAIN
m2s                  2018-08-24 18:57:43    {"tele/sonoff/LWT":"Offline","tele/sonoff_TV_IR_Reserve/LWT":"Offline","tele/sonoff_test/LWT":"Offline"}
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 24 August 2018, 19:22:04
238 bedeutet Retain bei LWT, d.h. das LWT muesste beim Verbindungsabbruch andere Meldungen mit diesem Topic ueberschreiben, aber laut RETAIN gibt es keine Anderen.

Ich habe deinen alten FHEM-Log sorgfaeltiger durchgelesen:
Zitat
2018.08.23 21:59:25 4: Connection accepted from m2s_192.168.1.40_14569
...
2018.08.23 21:59:25 4: Connection closed for m2s_192.168.1.40_19298: Connection reset by peer
=> Wichtig: 14569 != 19298. D.h. das Geraet mit der IP 192.168.1.40 hat eine zweite Verbindung aufgebaut, und danach die Erste zugemacht.
Beim jedem Disconnct sendet der MQTT2_SERVER das LWT, was hier vermutlich nicht so gewollt ist.

Ich muss noch darueber meditieren, wie man die zwei Verbindungen als "das gleiche Geraet" indentifizieren kann, vmtl. ueber clientID+IP. Oder nur clientID?
Wenn jemand die "richtige" Idee hat, der soll sich melden.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 24 August 2018, 19:34:40
Bin da jetzt nicht so versiert, aber beides denke ich mal wird schwierig sein:

Die ClientID wird es bestimmt nur bei der Tasmota Firmware geben, aber was ist mit der EspEasy Firmware? Die habe ich zur Zeit leider nicht am laufen!
Die IP schwankt ab und zu mal (sollte aber eigentlich nicht passieren) je nachdem wie oft ein Neustart des Device durchgeführt wird. (Bei jeder Änderung der Einstellung)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: supernova1963 am 25 August 2018, 08:49:38
Nur zur Info:

da ich sehr an diesem fhem <-> mqtt Ansatz mit großem Interesse verfolge, habe eins meiner ESPEasy devices mal umkonfiguriert (s.u.).
Es funktioniert soweit. ESPEasy sendet jedoch nicht ganz so viele Daten, wie tasmota.
Die Befehle "URL:<espeasyip>/json" bzw. "URL:<espeasyip>/sysinfo" sind leider scheinbar nur für HTTP verfügbar.

Ergebnis (list <device>):
Internals:
   CID        ESPClient_5C_CF_7F_1D_F3_63
   DEF        ESPClient_5C_CF_7F_1D_F3_63
   DEVICETOPIC MQTT2_ESPClient_5C_CF_7F_1D_F3_63
   IODev      mqttserver
   LASTInputDev mqttserver
   MSGCNT     28
   NAME       MQTT2_ESPClient_5C_CF_7F_1D_F3_63
   NR         109
   STATE      0
   TYPE       MQTT2_DEVICE
   mqttserver_MSGCNT 28
   mqttserver_TIME 2018-08-25 07:41:02
   OLDREADINGS:
   READINGS:
     2018-08-25 07:41:01   Empfang         -44
     2018-08-25 07:41:00   Online          6
     2018-08-25 07:41:02   Schalter        0
     2018-08-25 07:35:05   lwl             online
Attributes:
   IODev      mqttserver
   alias      Dunstabzugshaube
   devStateIcon 1:radio_checked@#e56524:off 0:radio_unchecked:on .*:message_attention@red
   readingList ESPClient_5C_CF_7F_1D_F3_63:/fhem/03_Kueche/Dunstabzugshaube/tele/lwl:.* lwl
ESPClient_5C_CF_7F_1D_F3_63:/fhem/03_Kueche/Dunstabzugshaube/Status/Online:.* Online
ESPClient_5C_CF_7F_1D_F3_63:/fhem/03_Kueche/Dunstabzugshaube/Status/Empfang:.* Empfang
ESPClient_5C_CF_7F_1D_F3_63:/fhem/03_Kueche/Dunstabzugshaube/Strom/Schalter:.* Schalter
   room       MQTT2_DEVICE
   setList    on /fhem/03_Kueche/Dunstabzugshaube/cmd GPIO,5,0
off /fhem/03_Kueche/Dunstabzugshaube/cmd GPIO,5,1
   stateFormat Schalter

Gernot
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: hexenmeister am 25 August 2018, 12:07:37
Die Befehle "URL:<espeasyip>/json" bzw. "URL:<espeasyip>/sysinfo" sind leider scheinbar nur für HTTP verfügbar.
Du kannst praktisch selbe Informationen auch per MQTT haben. Dafür musst du entsprechende "Sensoren" anlegen. "Generic System" oder so.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: supernova1963 am 25 August 2018, 13:22:05
Du kannst praktisch selbe Informationen auch per MQTT haben. Dafür musst du entsprechende "Sensoren" anlegen. "Generic System" oder so.

Als Generic - System Info habe ich bereits Online Zeit (Uptime) und Empfangsqualität (WIFI RSSI) genutzt. Die derzeit möglichen Generic - System Info sind auf die beiden und WebActivity, InputVCC, System
Load und IP beschränkt.

Das wären die json Informationen:
{"System":{
"Build":20102,
"Git Build":"",
"System libraries":"ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3",
"Plugins":48,
"Plugin description":" [Normal]",
"Local time":"2018-08-25 13:14:51",
"Unit":24,
"Name":"Dunstabzugshaube",
"Uptime":338,
"Last boot cause":"Manual reboot",
"Reset Reason":"Software/System restart",
"Load":13.40,
"Load LC":12518,
"Free RAM":15800
},
"WiFi":{
"Hostname":"Dunstabzugshaube-24",
"IP config":"Static",
"IP":"192.168.1.24",
"Subnet Mask":"255.255.255.0",
"Gateway IP":"192.168.1.1",
"MAC address":"5C:CF:7F:1D:F3:63",
"DNS 1":"192.168.1.1",
"DNS 2":"0.0.0.0",
"SSID":"RAUNET WLAN",
"BSSID":"20:C9:D0:AE:70:CA",
"Channel":6,
"Connected msec":20388969,
"Last Disconnect Reason":1,
"Last Disconnect Reason str":"(1) Unspecified",
"Number reconnects":0,
"RSSI":-43
},
"Sensors":[
{
"TaskValues": [
{"ValueNumber":1,
"Name":"Online",
"NrDecimals":0,
"Value":337
}],
"DataAcquisition": [
{"Controller":1,
"IDX":0,
"Enabled":"true"
},
{"Controller":2,
"IDX":0,
"Enabled":"true"
},
{"Controller":3,
"IDX":0,
"Enabled":"false"
}],
"TaskInterval":60,
"Type":"Generic - System Info",
"TaskName":"Status",
"TaskEnabled":"true",
"TaskNumber":1
},
{
"TaskValues": [
{"ValueNumber":1,
"Name":"Empfang",
"NrDecimals":0,
"Value":-45
}],
"DataAcquisition": [
{"Controller":1,
"IDX":0,
"Enabled":"true"
},
{"Controller":2,
"IDX":0,
"Enabled":"true"
},
{"Controller":3,
"IDX":0,
"Enabled":"false"
}],
"TaskInterval":60,
"Type":"Generic - System Info",
"TaskName":"Status",
"TaskEnabled":"true",
"TaskNumber":2
},
{
"TaskValues": [
{"ValueNumber":1,
"Name":"Schalter",
"NrDecimals":0,
"Value":0
}],
"DataAcquisition": [
{"Controller":1,
"IDX":0,
"Enabled":"true"
},
{"Controller":2,
"IDX":0,
"Enabled":"true"
},
{"Controller":3,
"IDX":0,
"Enabled":"false"
}],
"TaskInterval":60,
"Type":"Switch input - Switch",
"TaskName":"Strom",
"TaskEnabled":"true",
"TaskNumber":3
}
],
"TTL":60000
}

Wirklich wichtig war mir, dass es auch mit ESPEASY funktioniert.
Ein Hinweis noch: MQTT muss der 1. Controler definiert sein.

Gernot
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 25 August 2018, 16:39:58
Zitat
Das wären die json Informationen:
Habe json2nameValue erweitert, damit auch mit diesen Daten (insb. Arrays) zurechtkommt, und was Sinnvolles zurueckliefert, z.Bsp. sowas wie "Sensors_3_DataAcquisition_1_Enabled true". Aus den gezeigten JSON entstehen 85 Readings.

Zitat
D.h. das Geraet mit der IP 192.168.1.40 hat eine zweite Verbindung aufgebaut, und danach die Erste zugemacht.
Ab sofort wird LWT nur dann gesendet, falls keine weitere Verbindung vom gleichen IP mit dem gleichen clientID existiert.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 25 August 2018, 18:45:47
.
Ab sofort wird LWT nur dann gesendet, falls keine weitere Verbindung vom gleichen IP mit dem gleichen clientID existiert.

Jetzt läuft alles bei mir :) selbst der Reed-Kontakt an der Garage.
Dankeschön
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SusisStrolch am 26 August 2018, 13:12:39
Hmm, ich habe da noch ein kleines Problemchen...
2018.08.26 13:05:29.708 4: m2s_192.168.254.65_30194 DVES_22EC54 PUBLISH tele/gosund/STATE:{"Time":"2018-08-26T12:05:29","Uptime":"0T00:33:26","Vcc":3.152,"POWER":"on","Wifi":{"AP":1,"SSId":"SusiconStrolch","RSSI":100,"APMac":"38:10:D5:B2:22:1E"}}
2018.08.26 13:05:29.712 4: MQTT2_DEVICE_Parse: WZ.Subwoofer tele/gosund/STATE => { json2nameValue($EVENT) }
2018.08.26 13:05:29.718 1: PERL WARNING: Invalid conversion in sprintf: end of string at (eval 29620) line 3.

MQTT-Client ist ein Sonoff-Tasmota (GoSund). Klemmts da irgendwie im "jason2nameValue"?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 26 August 2018, 13:47:48
Das Problem muss anderswo herkommen, ich sehe kein WARNING:fhem> { my $h = json2nameValue('{"Time":"2018-08-26T12:05:29","Uptime":"0T00:33:26","Vcc":3.152,"POWER":"on","Wifi":{"AP":1,"SSId":"SusiconStrolch","RSSI":100,"APMac":"38:10:D5:B2:22:1E"}}');; join("\n", map { "$_ => $h->{$_}" } keys %{$h}) }
Wifi_APMac => 38:10:D5:B2:22:1E
Uptime => 0T00:33:26
Time => 2018-08-26T12:05:29
Vcc => 3.152
Wifi_RSSI => 100
Wifi_AP => 1
Wifi_SSId => SusiconStrolch
POWER => on
Set mal "attr global stacktrace".
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Wallmeier am 26 August 2018, 15:02:14
Wenn ich fhem neustarte bekomme ich das Log zugemüllt mit:
2018.08.26 13:13:27 2: mqttServer_192.168.1.27_12299 wants unclean session, disconnecting
2018.08.26 13:13:28 2: mqttServer_192.168.1.27_19499 wants unclean session, disconnecting
2018.08.26 13:13:29 2: mqttServer_192.168.1.27_43012 wants unclean session, disconnecting
Die IP 192.168.1.27 ist ein esp-link (https://github.com/jeelabs/esp-link (https://github.com/jeelabs/esp-link)). Kann man da noch etwas dran machen?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SusisStrolch am 26 August 2018, 15:44:27
Das Problem muss anderswo herkommen, ich sehe kein WARNING:
Danke - der Stacktrace hat es an den Tag gebracht - Fehler im stateFormat...
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 26 August 2018, 16:42:06
Zitat
Kann man da noch etwas dran machen?
Ich vermute es dauert 1-2 Stunden Doku Lesen, Implementieren, und Testen.
Kann man es bei esp-link nicht abschalten?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Wallmeier am 26 August 2018, 20:57:44
Ich vermute es dauert 1-2 Stunden Doku Lesen, Implementieren, und Testen.
Kann man es bei esp-link nicht abschalten?
Ich habe im WebInterface leider keine Möglichkeit gefunden, es abzuschalten... Da ein Restart im Normalfall geplant ist, kann ich damit leben.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: schwatter am 28 August 2018, 18:41:46
Ich habe ein Problem beim einlesen der "/fhem?XHR=1&cmd=jsonlist+","/fhem?XHR=1&cmd=jsonlist2+" bezüglich MQTT2_DEVICE.
Und zwar nutze ich das Plugin von Waldmensch für Enigma2, welches ich jetzt seit ca. einem Jahr weiterpflege und Devices hinzufüge.
Versuche ich anstatt MQTT_DEVICE das neue MQTT2_DEVICE einzulesen, kommt nichts an. Selbst bei MQTT2_SERVER erhalte ich Readings.
Zum einlesen verwende ich folgende Readings um das Device dazustellen:

Zum TYPE einlesen
def getType(self):
return str(self.Data["Internals"]["TYPE"])

Zum READINGS einlesen

def getReadings(self):
return self.Data["Readings"]

def getReadingState(self):
type = self.getType()
try:
if type == "MQTT2_DEVICE":
return str(self.Data["Readings"]["state"]["Value"])
else:
return ""
except:
return "no prop"

Ich habe mir die Jsonlist auf meinem Fhemserver soweit angeschaut, und diese mit MQTT_DEVICE verglichen. Schaut bis auf ein paar
mehr Infos gleich aus. Hat wer einen wink mit dem Zaunpfahl?  ;D
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 29 August 2018, 07:06:25
Kannst du bitte die "Raw Definition" der beiden Varianten (MQTT_DEVICE und MQTT2_DEVICE ) hier anhaengen?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: MarkusN am 29 August 2018, 10:36:10
Ab sofort wird LWT nur dann gesendet, falls keine weitere Verbindung vom gleichen IP mit dem gleichen clientID existiert.

Jetzt scheint LWT so zu funktionieren wie erwartet, danke  8)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: schwatter am 29 August 2018, 18:27:29
Kannst du bitte die "Raw Definition" der beiden Varianten (MQTT_DEVICE und MQTT2_DEVICE ) hier anhaengen?

Hier sind die Raw Definitionen. Wobei ich bei MQTT2 jetzt dein Autocreate nutze, das funktioniert super.
Ein paar Attribute habe ich ergänzt. Finde alles unauffällig auf dem ersten Blick.

MQTT

defmod Gosund_Wasserkocher MQTT_DEVICE
attr Gosund_Wasserkocher IODev myBroker
attr Gosund_Wasserkocher devStateIcon on:rc_GREEN:off off:rc_RED:on offline:rc_BLUE:off
attr Gosund_Wasserkocher icon message_socket
attr Gosund_Wasserkocher publishSet on off cmnd/Gosund_Wasserkocher/POWER
attr Gosund_Wasserkocher room 2. Küche,MQTT
attr Gosund_Wasserkocher stateFormat {ReadingsVal($name,"precence","") eq "offline" ? "offline" : ReadingsVal($name,"state","")}
attr Gosund_Wasserkocher subscribeReading_precence tele/Gosund_Wasserkocher/LWT
attr Gosund_Wasserkocher subscribeReading_sensor tele/Gosund_Wasserkocher/SENSOR
attr Gosund_Wasserkocher subscribeReading_setup tele/Gosund_Wasserkocher/STATE
attr Gosund_Wasserkocher subscribeReading_state stat/Gosund_Wasserkocher/POWER
attr Gosund_Wasserkocher webCmd on:off

setstate Gosund_Wasserkocher off
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Current 0
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Factor 0
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Period 0
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Power 0
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Today 0
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Total 0.105
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Voltage 243
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 ENERGY_Yesterday 0
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 POWER off
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 Time 2018-08-29T21:07:24
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 Uptime 0T23:15:54
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 Vcc 3.148
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 Wifi_AP 1
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 Wifi_APMac CC:CE:1E:50:CA:A6
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 Wifi_RSSI 52
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 Wifi_SSId FRITZ!Box1313
setstate Gosund_Wasserkocher 2018-08-28 21:51:38 precence online
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 sensor {"Time":"2018-08-29T21:07:24","ENERGY":{"Total":0.105,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":0,"Factor":0.00,"Voltage":243,"Current":0.000}}
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 setup {"Time":"2018-08-29T21:07:24","Uptime":"0T23:15:54","Vcc":3.148,"POWER":"off","Wifi":{"AP":1,"SSId":"FRITZ!Box1313","RSSI":52,"APMac":"CC:CE:1E:50:CA:A6"}}
setstate Gosund_Wasserkocher 2018-08-28 21:51:38 state off
setstate Gosund_Wasserkocher 2018-08-29 21:07:25 transmission-state incoming publish received

Und hier MQTT2

defmod Gosund_Trockner MQTT2_DEVICE DVES_7FBBEB
attr Gosund_Trockner IODev myFhembroker
attr Gosund_Trockner devStateIcon on:rc_GREEN off:rc_RED offline:rc_BLUE reboot:rc_YELLOW
attr Gosund_Trockner icon message_socket
attr Gosund_Trockner readingList DVES_7FBBEB:tele/Gosund_Trockner/LWT:.* LWT\
DVES_7FBBEB:cmnd/Gosund_Trockner/POWER:.* POWER\
DVES_7FBBEB:tele/Gosund_Trockner/INFO1:.* { json2nameValue($EVENT) }\
DVES_7FBBEB:tele/Gosund_Trockner/INFO2:.* { json2nameValue($EVENT) }\
DVES_7FBBEB:tele/Gosund_Trockner/INFO3:.* { json2nameValue($EVENT) }\
DVES_7FBBEB:stat/Gosund_Trockner/RESULT:.* { json2nameValue($EVENT) }\
DVES_7FBBEB:stat/Gosund_Trockner/POWER:.* POWER\
DVES_7FBBEB:tele/Gosund_Trockner/STATE:.* { json2nameValue($EVENT) }\
DVES_7FBBEB:tele/Gosund_Trockner/SENSOR:.* { json2nameValue($EVENT) }\
DVES_7FBBEB:tele/Gosund_Trockner/UPTIME:.* { json2nameValue($EVENT) }
attr Gosund_Trockner room 5. Waschküche,MQTT2_DEVICE
attr Gosund_Trockner setList on cmnd/Gosund_Trockner/POWER on\
off cmnd/Gosund_Trockner/POWER off\
reboot cmnd/Gosund_Trockner/Restart 1
attr Gosund_Trockner stateFormat { \
  my $state = ReadingsVal($name, "state", "off");;   \
  return '<img src="/fhem/images/fhemSVG/rc_GREEN.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "on");;   \
  return '<img src="/fhem/images/fhemSVG/rc_RED.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "off");;     \
  return '<img src="/fhem/images/fhemSVG/rc_YELLOW.svg",img width="32" height="32"<div>'..sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "reboot");; \
  return '<img src="/fhem/images/fhemSVG/rc_BLUE.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "offline");;   \
}
attr Gosund_Trockner webCmd on:off:reboot

setstate Gosund_Trockner <img src="/fhem/images/fhemSVG/rc_GREEN.svg",img width="32" height="32"<div>&nbsp;;&nbsp;;Spannung: 228 V &nbsp;;&nbsp;;Stromstärke: 0.000 A &nbsp;;&nbsp;;Leistung: 0 W &nbsp;;&nbsp;;Wifi_RSSI: 22 %</div>
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Current 0.000
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Factor 0.00
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Period 0
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Power 0
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Today 0.000
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Total 1.095
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Voltage 228
setstate Gosund_Trockner 2018-08-29 21:11:09 ENERGY_Yesterday 0.000
setstate Gosund_Trockner 2018-08-28 21:55:07 FallbackTopic DVES_7FBBEB
setstate Gosund_Trockner 2018-08-28 21:55:07 GroupTopic sonoffs
setstate Gosund_Trockner 2018-08-28 21:55:07 Hostname Gosund_Trockner-7147
setstate Gosund_Trockner 2018-08-28 21:55:07 IPAddress 192.168.178.48
setstate Gosund_Trockner 2018-08-28 23:30:12 LWT online
setstate Gosund_Trockner 2018-08-28 21:55:07 Module BlitzWolf SHP2
setstate Gosund_Trockner 2018-08-29 21:11:09 POWER on
setstate Gosund_Trockner 2018-08-25 17:22:01 Restart Restarting
setstate Gosund_Trockner 2018-08-28 21:55:07 RestartReason Software/System restart
setstate Gosund_Trockner 2018-08-26 15:24:36 SetOption0 off
setstate Gosund_Trockner 2018-08-26 15:20:18 SetOption1 off
setstate Gosund_Trockner 2018-08-26 15:22:16 SetOption15 on
setstate Gosund_Trockner 2018-08-26 15:17:51 Sleep 50 (50)
setstate Gosund_Trockner 2018-08-29 21:11:09 Time 2018-08-29T20:11:09
setstate Gosund_Trockner 2018-08-29 21:11:09 Uptime 0T23:16:10
setstate Gosund_Trockner 2018-08-29 21:11:09 Vcc 3.238
setstate Gosund_Trockner 2018-08-28 21:55:07 Version 6.1.1.13
setstate Gosund_Trockner 2018-08-28 21:55:07 WebServerMode Admin
setstate Gosund_Trockner 2018-08-29 21:11:09 Wifi_AP 1
setstate Gosund_Trockner 2018-08-29 21:11:09 Wifi_APMac 44:4E:6D:17:8C:C7
setstate Gosund_Trockner 2018-08-29 21:11:09 Wifi_RSSI 22
setstate Gosund_Trockner 2018-08-29 21:11:09 Wifi_SSId FRITZ1313
setstate Gosund_Trockner 2018-08-27 18:21:01 state on
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 29 August 2018, 19:57:21
Ich meinte die _komplette_ Raw Definition, also auch die setstate Zeilen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: schwatter am 29 August 2018, 21:13:51
Ok, verstanden. Habe es oben angepasst.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 29 August 2018, 21:22:01
state wird nicht gesetzt, es sei denn der Benutzer hat es konfiguriert.

Ich habe heute geupdatet und beobachte dass das State-Reading mit dem letzten Set aktualisiert wird - trotz stat/$DEVICETOPIC/POWER:.* state im Attribut readingList.

Das war in der "alten" Version der Module nicht der Fall.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 30 August 2018, 15:05:37
@ThoTo: Stimmt, ich habs ja auf Wunsch geaendert und in diesem Thread dokumentiert. Falls man es anders haben will: Status in einem anderen Reading schreiben, und stateFormat verwenden.

@schwatter: ist eigentlich ein Thema fuer JsonList2: \n und " soll wohl in JSON nicht mit \u000a und \u0022 dargestellt werden sondern als \n und \".
Finde ich etwas kleinkariert, aber ich habs jetzt geaendert.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: ThoTo am 30 August 2018, 15:40:10
@ThoTo: Stimmt, ich habs ja auf Wunsch geaendert und in diesem Thread dokumentiert. Falls man es anders haben will: Status in einem anderen Reading schreiben, und stateFormat verwenden.

Ich hab's überlesen.... Danke, alles gut  8) 8)

LG Thomas
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: schwatter am 30 August 2018, 21:02:51
@rudolfkoenig

Danke für das anpassen bezüglich Jsonlist2. Ich bin leider noch nicht so lange bei Fhem, das ich bemerkt hätte,
das Jsonlist ausläuft und nur noch Jsonlist2 weiter supportet wird. Da muss ich einiges nachholen und wohl
bei mir anpassen.

edit:

Vielleicht hat wer einen Tip zu Jsonlist2, ich bekomme keine Werte zurück. Bitte dazu hier Antworten.

https://forum.fhem.de/index.php/topic,33280.0.html
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: arran am 03 September 2018, 10:52:08
Hallo zusammen,

Ich habe meine Gosund Steckdosen wie im Beitrag #119 mit MQTT2 in Fhem eingebunden. Das Schalten aus Fhem klappt ohne Probleme. Wenn die Steckdose über den Knopf Ein/Aus geschaltet wird kommt das in der Statusanzeige von Fhem nicht an. Hat jemand eine Idee wie das behoben werden kann?

Vielen Dank,


Gesendet von iPhone mit Tapatalk
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 03 September 2018, 10:55:36
Kannst du bitte die "Raw definition" vom Geraet hier anhaengen, und den Inhalt des Event-Monitors beim Schalten der Steckdose?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: arran am 03 September 2018, 11:30:07
Hi,

Ich bin jetzt in der Arbeit aber heute Abend poste ich die Daten... Du meinst „list device“ oder?

Gruß,


Gesendet von iPhone mit Tapatalk
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Matze66 am 03 September 2018, 12:18:43
Hi,

In der Konsole des Tasmotadevice folgendes ausführen:

StateText1 off
StateText2 on
StateText3 toggle
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 03 September 2018, 12:51:13
Hallo zusammen,

Ich habe meine Gosund Steckdosen wie im Beitrag #119 mit MQTT2 in Fhem eingebunden. Das Schalten aus Fhem klappt ohne Probleme. Wenn die Steckdose über den Knopf Ein/Aus geschaltet wird kommt das in der Statusanzeige von Fhem nicht an. Hat jemand eine Idee wie das behoben werden kann?

Ich mache es mit:
attr <DEVICE> stateFormat POWER
attr <DEVICE> eventMap on:ON off:OFF

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 03 September 2018, 13:39:26
Zitat
Du meinst „list device“ oder?
Nein, entweder "list -r device", oder in FHEMWEB, DetailAnsicht, unten, Raw Definition (was list -r ausfuehrt)
Titel: [Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: arran am 03 September 2018, 19:53:37
Nein, entweder "list -r device", oder in FHEMWEB, DetailAnsicht, unten, Raw Definition (was list -r ausfuehrt)

Hallo,

hiermit die raw Ausgabe:

define GosundST1 MQTT2_DEVICE DVES_93A82B
attr GosundST1 IODev m2s
attr GosundST1 alias GsdST1
attr GosundST1 devStateIcon on:rc_GREEN off:rc_RED offline:rc_BLUE reboot:rc_YELLOW
attr GosundST1 icon message_socket
attr GosundST1 readingList DVES_93A82B:tele/sonoff/LWT:.* LWT\
DVES_93A82B:cmnd/sonoff/POWER:.* POWER\
DVES_93A82B:tele/sonoff/INFO1:.* { json2nameValue($EVENT) }\
DVES_93A82B:tele/sonoff/INFO2:.* { json2nameValue($EVENT) }\
DVES_93A82B:tele/sonoff/INFO3:.* { json2nameValue($EVENT) }\
DVES_93A82B:stat/sonoff/RESULT:.* { json2nameValue($EVENT) }\
DVES_93A82B:stat/sonoff/POWER:.* POWER\
DVES_93A82B:tele/sonoff/STATE:.* { json2nameValue($EVENT) }\
DVES_93A82B:tele/sonoff/SENSOR:.* { json2nameValue($EVENT) }\
DVES_93A82B:tele/sonoff/LWT:.* LWT\
DVES_93A82B:tele/sonoff/UPTIME:.* { json2nameValue($EVENT) }\
DVES_93A82B:stat/DVES_93A82B/RESULT:.* { json2nameValue($EVENT) }\
DVES_93A82B:stat/DVES_93A82B/POWER:.* POWER\
DVES_93A82B:stat/sonoff/UPGRADE:.* UPGRADE
attr GosundST1 room Gosund
attr GosundST1 setList on cmnd/DVES_93A82B/POWER on\
off cmnd/DVES_93A82B/POWER off\
reboot cmnd/DVES_93A82B/RESTART 1
attr GosundST1 stateFormat { \
  my $state = ReadingsVal($name, "state", "off");;   \
  return '<img src="/fhem/images/fhemSVG/rc_GREEN.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "on");;   \
  return '<img src="/fhem/images/fhemSVG/rc_RED.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "off");;     \
  return '<img src="/fhem/images/fhemSVG/rc_YELLOW.svg",img width="32" height="32"<div>'..sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "reboot");; \
  return '<img src="/fhem/images/fhemSVG/rc_BLUE.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "offline");;   \
}
attr GosundST1 webCmd on:off:reboot

setstate GosundST1 <img src="/fhem/images/fhemSVG/rc_RED.svg",img width="32" height="32"<div>&nbsp;;&nbsp;;Spannung: 0 V &nbsp;;&nbsp;;Stromstärke: 0.000 A &nbsp;;&nbsp;;Leistung: 0 W &nbsp;;&nbsp;;Wifi_RSSI: 90 %</div>
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Current 0.000
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Factor 0.00
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Period 0
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Power 0
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Today 0.001
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Total 0.001
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Voltage 0
setstate GosundST1 2018-09-03 19:36:52 ENERGY_Yesterday 0.000
setstate GosundST1 2018-09-03 19:26:44 FallbackTopic DVES_93A82B
setstate GosundST1 2018-09-03 19:26:44 GroupTopic sonoffs
setstate GosundST1 2018-09-03 19:26:44 Hostname sonoff-2091
setstate GosundST1 2018-09-03 19:26:44 IPAddress 192.aaa.bbb.ccc
setstate GosundST1 2018-09-03 19:26:44 LWT online
setstate GosundST1 2018-09-03 19:26:44 Module BlitzWolf SHP2
setstate GosundST1 2018-09-02 23:28:42 OtaUrl http://sonoff.maddox.co.uk/tasmota/sonoff-minimal.bin
setstate GosundST1 2018-09-03 19:36:52 POWER off
setstate GosundST1 2018-09-02 23:34:03 Restart Restarting
setstate GosundST1 2018-09-03 19:26:44 RestartReason Power on
setstate GosundST1 2018-09-03 19:36:52 Time 2018-09-03T18:36:52
setstate GosundST1 2018-09-02 23:28:55 UPGRADE Failed Update error: ERROR[8]: Flash config wrong real: 1048576 IDE: 4194304
setstate GosundST1 2018-09-02 23:28:42 Upgrade Version 6.1.1 from http://sonoff.maddox.co.uk/tasmota/sonoff-minimal.bin
setstate GosundST1 2018-09-03 19:36:52 Uptime 0T00:10:13
setstate GosundST1 2018-09-03 19:36:52 Vcc 3.238
setstate GosundST1 2018-09-03 19:26:44 Version 6.1.1
setstate GosundST1 2018-09-03 19:26:44 WebServerMode Admin
setstate GosundST1 2018-09-03 19:36:52 Wifi_AP 1
setstate GosundST1 2018-09-03 19:36:52 Wifi_APMac XX:XX:XX:XX:XX:XX
setstate GosundST1 2018-09-03 19:36:52 Wifi_RSSI 90
setstate GosundST1 2018-09-03 19:36:52 Wifi_SSId aldebaran
setstate GosundST1 2018-09-03 19:36:21 state off

Und hier die events:
- aus aus fhem:
2018-09-03 19:50:51.605 MQTT2_DEVICE GosundST1 off
2018-09-03 19:50:51.719 MQTT2_DEVICE GosundST1 POWER: off
2018-09-03 19:50:51.745 MQTT2_DEVICE GosundST1 POWER: off
- von dem Knopf an der Steckdose:
2018-09-03 19:50:54.935 MQTT2_DEVICE GosundST1 POWER: on
2018-09-03 19:50:54.959 MQTT2_DEVICE GosundST1 POWER: on

Gruß,
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: schwatter am 03 September 2018, 20:34:24
Das liegt daran, das der "state" nicht von MQTT2 gesetzt wird.
Helfen würde dir, das stateFormat zu ändern.

siehe hier die Antwort von rudolfkoenig

https://forum.fhem.de/index.php/topic,90145.msg829664.html#msg829664

edit:
Wegen Blödsinn
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 03 September 2018, 21:19:35
Z.Bsp. mitattr GosundST1 stateFormat POWER
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: arran am 03 September 2018, 21:56:10
Vielen Dank für die Hinweise - es  hat geklappt  8)

Ich habe mein stateFormat folgendermaßen geändert:

attr GosundST1 stateFormat { \
  my $state = ReadingsVal($name,"LWT","") eq "offline" ? "offline" : ReadingsVal($name,"POWER","");;   \
  return '<img src="/fhem/images/fhemSVG/rc_GREEN.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "on");;   \
  return '<img src="/fhem/images/fhemSVG/rc_RED.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "off");;     \
  return '<img src="/fhem/images/fhemSVG/rc_YELLOW.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "reboot");; \
  return '<img src="/fhem/images/fhemSVG/rc_BLUE.svg",img width="32" height="32"<div>'.sprintf("&nbsp;;&nbsp;;Spannung: %.0f V &nbsp;;&nbsp;;Stromstärke: %.3f A &nbsp;;&nbsp;;Leistung: %.0f W &nbsp;;&nbsp;;Wifi_RSSI: %.0f %%", ReadingsVal($name,"ENERGY_Voltage",0), ReadingsVal($name,"ENERGY_Current",0), ReadingsVal($name,"ENERGY_Power",0), ReadingsVal($name,"Wifi_RSSI",0)).'</div>' if($state eq "offline");;   \
}

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: projectsun am 10 September 2018, 20:47:39
Hallo, ich würde die Module gern testen.

Beim reload: Too many arguments for main::Dispatch at ./FHEM/00_MQTT2_SERVER.pm line 404, near "$ac)"

was diese Zeile wäre: Dispatch($tgt, "$ac$cid:$tp:$val", undef, !$ac);

Das 10_MQTT2_DEVICE hat er immerhin schon mal geladen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 10 September 2018, 21:50:35
https://forum.fhem.de/index.php/topic,90634.msg831019.html#msg831019
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: projectsun am 10 September 2018, 22:50:59
Danke, läuft!
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: FunkOdyssey am 21 September 2018, 17:31:32
Ich nutze die MQTT-Version von eBusd (https://github.com/john30/ebusd/wiki/3.3.-MQTT-client) und dort steht u.a. auch ein uptime-Topic zur Verfügung.
Nur müllt mir dies natürlich mein MQTT2_DEVICE voll und daher habe ich es in der readingList entfernt. Dennoch wird dieses Reading immer wieder neu erzeugt. Nicht im Attribut readingList, sondern als Reading.

Werde ich das nur los, indem ich im MQTT2_SERVER das autocreate deaktiviere?
Es reicht also nicht, es aus dem Attribut readingList zu entfernen?



Wofür steht die CID (hier: ebusd_3.2_1) eigentlich vor jeder Zeile in readingList?
ebusd_3.2_1:ebusd/global/uptime:.* uptime
Ich konnte dieses Präfix überall entfernen und frage mich nun aber, ob dies zukünftig irgendwelche Probleme macht.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 21 September 2018, 19:07:44
Zitat
Nur müllt mir dies natürlich mein MQTT2_DEVICE voll
Was genau heisst das?

Zitat
Werde ich das nur los, indem ich im MQTT2_SERVER das autocreate deaktiviere?
Ja.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: FunkOdyssey am 21 September 2018, 19:32:15
Nicht wirklich vollmüllen. Aber alle 5sec ein Reading hochzählen, welches vermutlich als Event reinkommt und dann nur mit Aufwand aus dem Log entfernt werden kann, ist für mich ärgerlich.

Klar kann ich mit event-on-change-... und FileLog RegEx ausschließen. Aber dafür müsste ich ja alle Positiv-Readings aufzählen (Whitelist) und kann nicht per Blacklist das "uptime" loswerden. Daher ist für mich der einfachste Weg, das Reading aus dem Attribut readingList zu löschen. Aber es kommt ja wieder. 😄
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 21 September 2018, 20:22:06
Zitat
Wofür steht die CID (hier: ebusd_3.2_1) eigentlich vor jeder Zeile in readingList?
ClientId, wird bei CONNECT geschickt, und automatisch angelegte MQTT2_DEVICE Instanzen verwenden es zur genaueren Unterscheidung der Nachrichten. Kann aus dem Regexp entfernt werden, wenn sichergestellt ist, dass alle verbundenen Geraete unterschiedliche Topics verwenden, was fuer einen "normalen" MQTT Server auch der Fall sein muss.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: blueberry63 am 24 September 2018, 20:00:51
Ich habe den MQTT2 Server mit "autocreate" konfiguriert. Wenn ich nun ein automatisch angelegtes Device lösche, kann ich es danach nochmal anlegen lassen?

Gruß
Blueberry63
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 24 September 2018, 20:38:20
Wenn autocreate im MQTT2_SERVER an ist, dann wird das Geraet immer wieder angelegt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: blueberry63 am 25 September 2018, 13:50:12
Das Gerät wird leider nicht wieder angelegt. Deshalb habe ich mich gemeldet. Ich finde zwar unter der Kategorie "Everything" das Gerät mit dem Namen "mqtt2srv_192.168.x.x" (Room: hidden), aber als "echtes" Gerät ist es nicht angelegt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 25 September 2018, 14:59:50
Kannst du bitte ein "attr MQTT2_SERVER verbose 5" log hier anhaengen?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: blueberry63 am 25 September 2018, 21:29:20
Wie gewünscht  :)
(wie Du siehst, handelt es sich hier um 2 Geräte (Webcams), die ich gelöscht und gerne wieder angelegt hätte)

2018.09.25 21:17:41 4: Connection accepted from mqtt2srv_192.168.99.57_60442
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.57_60442 mosqpub|16131-WebcamGH CONNECT V:3 keepAlive:60 usr:
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.57_60442 mosqpub|16131-WebcamGH PUBLISH myhome/CamGH/brightness:23
2018.09.25 21:17:41 5: mqtt2srv_192.168.99.57_60083 mosqsub|271-WebcamGH => myhome/CamGH/brightness:23
2018.09.25 21:17:41 5: mqtt2srv: dispatch autocreate:mosqpub_16131_WebcamGH:myhome/CamGH/brightness:23
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.57_60442 mosqpub|16131-WebcamGH DISCONNECT
2018.09.25 21:17:41 4: Connection accepted from mqtt2srv_192.168.99.57_60443
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.57_60443 mosqpub|16146-WebcamGH CONNECT V:3 keepAlive:60 usr:
2018.09.25 21:17:41 4: Connection accepted from mqtt2srv_192.168.99.58_39733
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.58_39733 mosqpub|6502-WebcamTer CONNECT V:3 keepAlive:60 usr:
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.57_60443 mosqpub|16146-WebcamGH PUBLISH myhome/CamGH/rtsp_h264_server:ON
2018.09.25 21:17:41 5: mqtt2srv_192.168.99.57_60083 mosqsub|271-WebcamGH => myhome/CamGH/rtsp_h264_server:ON
2018.09.25 21:17:41 5: mqtt2srv: dispatch autocreate:mosqpub_16146_WebcamGH:myhome/CamGH/rtsp_h264_server:ON
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.57_60443 mosqpub|16146-WebcamGH DISCONNECT
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.58_39733 mosqpub|6502-WebcamTer PUBLISH myhome/CamTer/leds/blue:ON
2018.09.25 21:17:41 5: mqtt2srv_192.168.99.58_39419 mosqsub|274-WebcamGH => myhome/CamTer/leds/blue:ON
2018.09.25 21:17:41 5: mqtt2srv: dispatch autocreate:mosqpub_6502_WebcamTer:myhome/CamTer/leds/blue:ON
2018.09.25 21:17:41 4: mqtt2srv_192.168.99.58_39733 mosqpub|6502-WebcamTer DISCONNECT
2018.09.25 21:17:41 4: Connection accepted from mqtt2srv_192.168.99.58_39734
2018.09.25 21:17:41 4: Connection accepted from mqtt2srv_192.168.99.57_60444
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.58_39734 mosqpub|6506-WebcamTer CONNECT V:3 keepAlive:60 usr:
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.57_60444 mosqpub|16166-WebcamGH CONNECT V:3 keepAlive:60 usr:
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.58_39734 mosqpub|6506-WebcamTer PUBLISH myhome/CamTer/leds/yellow:OFF
2018.09.25 21:17:42 5: mqtt2srv_192.168.99.58_39419 mosqsub|274-WebcamGH => myhome/CamTer/leds/yellow:OFF
2018.09.25 21:17:42 5: mqtt2srv: dispatch autocreate:mosqpub_6506_WebcamTer:myhome/CamTer/leds/yellow:OFF
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.58_39734 mosqpub|6506-WebcamTer DISCONNECT
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.57_60444 mosqpub|16166-WebcamGH PUBLISH myhome/CamGH/rtsp_mjpeg_server:OFF
2018.09.25 21:17:42 5: mqtt2srv_192.168.99.57_60083 mosqsub|271-WebcamGH => myhome/CamGH/rtsp_mjpeg_server:OFF
2018.09.25 21:17:42 5: mqtt2srv: dispatch autocreate:mosqpub_16166_WebcamGH:myhome/CamGH/rtsp_mjpeg_server:OFF
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.57_60444 mosqpub|16166-WebcamGH DISCONNECT
2018.09.25 21:17:42 4: Connection accepted from mqtt2srv_192.168.99.58_39735
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.58_39735 mosqpub|6510-WebcamTer CONNECT V:3 keepAlive:60 usr:
2018.09.25 21:17:42 4: Connection accepted from mqtt2srv_192.168.99.57_60445
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.57_60445 mosqpub|16169-WebcamGH CONNECT V:3 keepAlive:60 usr:
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.58_39735 mosqpub|6510-WebcamTer PUBLISH myhome/CamTer/leds/ir:ON
2018.09.25 21:17:42 5: mqtt2srv_192.168.99.58_39419 mosqsub|274-WebcamGH => myhome/CamTer/leds/ir:ON
2018.09.25 21:17:42 5: mqtt2srv: dispatch autocreate:mosqpub_6510_WebcamTer:myhome/CamTer/leds/ir:ON
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.58_39735 mosqpub|6510-WebcamTer DISCONNECT
2018.09.25 21:17:42 4: Connection accepted from mqtt2srv_192.168.99.57_60446
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.57_60445 mosqpub|16169-WebcamGH PUBLISH myhome/CamGH/night_mode:ON
2018.09.25 21:17:42 5: mqtt2srv_192.168.99.57_60083 mosqsub|271-WebcamGH => myhome/CamGH/night_mode:ON
2018.09.25 21:17:42 5: mqtt2srv: dispatch autocreate:mosqpub_16169_WebcamGH:myhome/CamGH/night_mode:ON
2018.09.25 21:17:42 4: mqtt2srv_192.168.99.57_60445 mosqpub|16169-WebcamGH DISCONNECT
2018.09.25 21:17:42 4: Connection accepted from mqtt2srv_192.168.99.58_39736
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 25 September 2018, 22:16:14
Ich habe 8 unterschiedliche clientIds gezaehlt:
Zitat
mosqpub|16131-WebcamGH PUBLISH myhome/CamGH/brightness:23
mosqpub|16146-WebcamGH PUBLISH myhome/CamGH/rtsp_h264_server:ON
mosqpub|16166-WebcamGH PUBLISH myhome/CamGH/rtsp_mjpeg_server:OFF
mosqpub|16169-WebcamGH PUBLISH myhome/CamGH/night_mode:ON
mosqpub|6502-WebcamTer PUBLISH myhome/CamTer/leds/blue:ON
mosqpub|6506-WebcamTer PUBLISH myhome/CamTer/leds/yellow:OFF
mosqpub|6510-WebcamTer PUBLISH myhome/CamTer/leds/ir:ON
Dabei ist der Praefix mosqpub stoerend: MQTT2_DEVICE legt nichts an, wenn clientId mit mosqpub anfaengt, weil das der mosquitto_pub default clientId ist. Insofern ist das Problem nicht, dass es nicht _wieder_ angelegt wird, sondern dass es ueberhaupt nicht angelegt wird.

Ich empfehle clientId zu aendern, wenn das nicht geht, muss das Geraet manuell in FHEM angelegt werden.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rih am 02 Oktober 2018, 10:22:13
Habe ein eher unkritisches Problem zu melden (sofern es überhaupt eines ist und ich es nur missverstehe):

2018.10.01 20:20:51 3: MQTT_Broker: MQTT_Broker_192.168.0.27_50768 left us (keepalive check
Die Meldung kommt, wenn ich das Device abschalte. Sollte das nicht so aussehen (man beachte das Device):

2018.10.01 20:20:51 3: MQTT_Broker: MQTT_Device_192.168.0.27_50768 left us (keepalive check
2. Frage: ich hatte anfangs einen Schreibfehler in meiner readingslist. Das fehlerhafte Reading habe ich mit deletereading gelöscht, doch es erscheint sporadisch immer wieder zusammen mit dem Reading in der richtigen Schreibweise. Wie kann ich das falsche Reading entgültig loswerden?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 02 Oktober 2018, 12:54:59
Zitat
Sollte das nicht so aussehen (man beachte das Device)
MQTT_Broker_192.168.0.27_50768 ist der Name der FHEM-Instanz des Typs MQTT2_SERVER(!), was die TCP/IP Verbindung representiert. Diese Instanzen sind temporaer, und werden nie gespeichert. Bei der o.g. Meldung wird diese Instanz entfernt. autocreate in MQTT2_SERVER legt ein MQTT2_DEVICE an (was clientId der Verbindung im Namen enthaelt, nicht die IP-Adresse), was fuer den Benutzer dieses Geraet (nicht die Verbindung) representiert.

Zitat
Wie kann ich das falsche Reading entgültig loswerden?
Nach dem Loeschen des Readings FHEM neustarten.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Prof. Dr. Peter Henning am 07 Oktober 2018, 08:59:34
1.Problem in MQTT2_DEVICE:

Eine Kommandodefinition
attr <device> setList relay_0 shellies/shelly4pro-061D51/relay/0/commanderzeugt korrekterweise im FHEMWEB eine Drop-Down-Liste mit "relay_0" als Kommando und einem Textfeld für einen Parameter dahinter. Bei Eingabe von z.B. "on" oder "off" im Textfeld wird das betreffende Device richtig geschaltet.

Wenn man nun setzt
attr <device> setList relay_0:on,off shellies/shelly4pro-061D51/relay/0/commanderzeugt dies im FHEMWEB eine Drop-Down-Liste mit "relay_0" als Kommando und einer weiteren Drop-Down-Liste mit der Auswahl zwischen "on" und "off". Bei der Ausführung allerdings steigt die "Set"-Routine in Zeile 218 des Moduls aus mit der Fehlermeldung
Zitat
Unknown argument relay_0, choose one of relay_0:on,off ...
.

Edit: Problem gelöst, danke.

LG

pah
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Prof. Dr. Peter Henning am 07 Oktober 2018, 09:10:31
2. Problem im Zusammenspiel zwischen MQTT2_DEVICE und MQTT2_SERVER:

Das per autocreate erzeugte Device" shelly4pro_061D51" habe ich (natürlich aus Schreibfaulheit) umbenannt in "shellypro", die Definition im cfg-File lautet also
    
define shellypro MQTT2_DEVICE shelly4pro_061D51
Jetzt gibt es im Log aber von Zeit zu Zeit so etwas hier
Zitat
2018.10.07 08:45:45 3: mqtt: mqtt_192.168.0.170_57333 left us (keepalive check)
2018.10.07 08:51:42 1: M2: Unhandled packet PUBACK, disconneting mqtt_192.168.0.170_55990
2018.10.07 08:51:42 2: autocreate: define MQTT2_shelly4pro_061D51 MQTT2_DEVICE shelly4pro_061D51
2018.10.07 08:51:42 2: autocreate: define FileLog_MQTT2_shelly4pro_061D51 FileLog ./log/MQTT2_shelly4pro_061D51-%Y.log MQTT2_shelly4pro_061D51
2018.10.07 08:51:46 1: M2: Unhandled packet PUBACK, disconneting mqtt_192.168.0.170_55381

Klar kann man das Neuanlegen durch autocreate=0 unterdrücken. Allerdings will man ja von Zeit wirklich ein neues Device anbinden - und dann werden alle anderen Devices, die gerade mal nicht erreichbar sind, neu angelegt.

LG

pah
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 07 Oktober 2018, 12:33:59
attr <device> setList relay_0:on,off shellies/shelly4pro-061D51/relay/0/commandAn diese Variante habe ich nicht gedacht, hab sie jetzt aber implementiert und eingecheckt.
Workaround: widgetOverride verwenden.

Weiterhin gefixt: WARNING falls man MQTT2_SERVER mit allowed verwendet.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 07 Oktober 2018, 12:46:48
2018.10.07 08:51:42 1: M2: Unhandled packet PUBACK, disconneting mqtt_192.168.0.170_55990
2018.10.07 08:51:42 2: autocreate: define MQTT2_shelly4pro_061D51 MQTT2_DEVICE shelly4pro_061D51
Ich habe PUBACK jetzt ignoriert, es wird kein disconnect erzwungen.

Das sollte aber kein Grund fuer autocreate sein. Um das zu verstehen brauche ich ein "attr mqtt verbose 5" Log, direkt vor dem autocreate, noch besser mit auskommentierten "Lowlevel debugging" in 00_MQTT2_SERVER.pm. Die Umbenennung sollte nicht die Ursache sein, insb. wenn man clientId nicht entfernt hat.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Prof. Dr. Peter Henning am 07 Oktober 2018, 13:18:21
Ich schau mal, ob ich das kurzfristig liefern kann. Ansonsten Danke für den Fix.

Edit: Hier ein Schaltvorgang mit verbose 5 beim Device und beim Server. autocreate ist 0. Ich habe nichts gesehen, aus dem ich schlau würde.
2018.10.07 13:23:06 5: mqtt_192.168.0.170_55697 shelly4pro-061D51 => shellies/shelly4pro-061D51/relay/0/command:on
2018.10.07 13:23:06 1: M2: Unhandled packet PUBACK, disconneting mqtt_192.168.0.170_55697
2018.10.07 13:23:06 4: mqtt_192.168.0.170_55697 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/0:on
2018.10.07 13:23:06 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/0:on
2018.10.07 13:23:08 4: Connection accepted from mqtt_192.168.0.170_61038
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 CONNECT V:4 keepAlive:60
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/0/power:29.52
2018.10.07 13:23:08 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/0/power:29.52
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/0/energy:1
2018.10.07 13:23:08 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/0/energy:1
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/0:on
2018.10.07 13:23:08 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/0:on
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/1:off
2018.10.07 13:23:08 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/1:off
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/2:off
2018.10.07 13:23:08 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/2:off
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/3:off
2018.10.07 13:23:08 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/3:off
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:08 4:   topic:shellies/shelly4pro-061D51/relay/3/command qos:1
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:08 4:   topic:shellies/shelly4pro-061D51/relay/2/command qos:1
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:08 4:   topic:shellies/shelly4pro-061D51/relay/1/command qos:1
2018.10.07 13:23:08 4: mqtt_192.168.0.170_61038 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:08 4:   topic:shellies/shelly4pro-061D51/relay/0/command qos:1
2018.10.07 13:23:13 5: mqtt_192.168.0.170_61038 shelly4pro-061D51 => shellies/shelly4pro-061D51/relay/0/command:off
2018.10.07 13:23:13 1: M2: Unhandled packet PUBACK, disconneting mqtt_192.168.0.170_61038
2018.10.07 13:23:15 4: Connection accepted from mqtt_192.168.0.170_63638
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 CONNECT V:4 keepAlive:60
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/0:off
2018.10.07 13:23:15 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/0:off
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/1:off
2018.10.07 13:23:15 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/1:off
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/2:off
2018.10.07 13:23:15 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/2:off
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 PUBLISH shellies/shelly4pro-061D51/relay/3:off
2018.10.07 13:23:15 5: mqtt: dispatch shelly4pro_061D51:shellies/shelly4pro-061D51/relay/3:off
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:15 4:   topic:shellies/shelly4pro-061D51/relay/3/command qos:1
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:15 4:   topic:shellies/shelly4pro-061D51/relay/2/command qos:1
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:15 4:   topic:shellies/shelly4pro-061D51/relay/1/command qos:1
2018.10.07 13:23:15 4: mqtt_192.168.0.170_63638 shelly4pro-061D51 SUBSCRIBE
2018.10.07 13:23:15 4:   topic:shellies/shelly4pro-061D51/relay/0/command qos:1

LG

pah
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 07 Oktober 2018, 23:11:33
Sorry, nachtraeglich modifizierte Beitraege uebersehe ich fast immer, da ich keine Email-Nachricht bekomme.

autocreate wird aufgerufen, falls das Attribut in MQTT2_SERVER gesetzt ist, kein MQTT2_DEVICE den betroffenen Topic per readingsList "abonniert", und noch kein Geraet mit diesem clientId angelegt ist. Da bei der Umbenennung clientId nicht verlorengeht, und alle dispatch Meldungen mit dem im define spezifizierten clientId (shelly4pro_061D51) erstellt wurden, sehe ich keinen Grund fuer autocreate.

Ich brauche zum Nachweis das Log mit "attr mqtt autocreate 1".Wurde FHEM nach dem Umbenennen neu gestartet?Es sollte mit und ohne funktionieren, ich will es nur beim debuggen leichter haben.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: kadettilac89 am 12 Oktober 2018, 10:52:31
Ich habe mal zum Test das Server / Broker-Modul eingebunden. Sobald ich eine Msg pushe crasht Fhem (Connection lost ... retry 5 seconds).

Verbose 5 ist gesetzt, Log ist aber ohne Eintrag ... nur dass Fhem neu gestartet wurde, und der Reconnect des MQTT-Clients

Gibt es zu Perl irgendwo noch Logs in denen ich nachsehen kann was genau abgebrochen ist? In /var/log gibt es keine Datei die zum Zeitpunkt des (der) Abbrüche geändert wurde.

Definition
defmod MQTT MQTT2_SERVER 8090 global
attr MQTT autocreate 1
attr MQTT room Test
attr MQTT verbose 5

setstate MQTT 2018-10-12 10:45:03 nrclients 1
setstate MQTT 2018-10-12 10:44:40 state Initialized

SystemD Log
Okt 12 10:44:22 raspfhem.home systemd[1]: fhem.service: Main process exited, code=exited, status=255/n/a
Okt 12 10:44:22 raspfhem.home systemd[1]: fhem.service: Unit entered failed state.
Okt 12 10:44:22 raspfhem.home systemd[1]: fhem.service: Failed with result 'exit-code'.
Okt 12 10:44:27 raspfhem.home systemd[1]: fhem.service: Service hold-off time over, scheduling restart.
Okt 12 10:44:27 raspfhem.home systemd[1]: Stopped FHEM Home Automation.
Okt 12 10:44:27 raspfhem.home systemd[1]: Starting FHEM Home Automation...

Perl  "This is perl 5, version 24, subversion 1 (v5.24.1) built for arm-linux-gnueabihf-thread-multi-64int"
Raspbian aktuellste Version
Raspberry PI 3
Fhem aktuellste Version
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 12 Oktober 2018, 11:49:54
Starte FHEM im Terminal mit "perl fhem.pl -d fhem.cfg"
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: kadettilac89 am 12 Oktober 2018, 14:34:36
Starte FHEM im Terminal mit "perl fhem.pl -d fhem.cfg"

2 Mal getestet:
topic: test

2018.10.12 14:05:54.291 4: Connection accepted from MQTT_192.168.0.46_56856
2018.10.12 14:05:54.293 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 1
2018.10.12 14:05:54.293 5: createNotifyHash
2018.10.12 14:05:54.304 5: ----------------------------------------
2018.10.12 14:05:54.305 5: myMSwitch: eingehendes Event von -> MQTT
2018.10.12 14:05:54.305 5: ----------------------------------------
2018.10.12 14:05:54.308 4: DbLog myDbLog -> ################################################################
2018.10.12 14:05:54.308 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:05:54.308 4: DbLog myDbLog -> ################################################################
2018.10.12 14:05:54.308 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:05:54.309 4: DbLog myDbLog -> check Device: MQTT , Event: nrclients: 1
2018.10.12 14:05:54.317 5: End notify loop for MQTT
2018.10.12 14:05:54.320 4: MQTT_192.168.0.46_56856 root.1539345952240 CONNECT V:3 keepAlive:60
2018.10.12 14:05:54.823 4: MQTT_192.168.0.46_56856 root.1539345952240 SUBSCRIBE
2018.10.12 14:05:55.892 4: MQTT_192.168.0.46_56856 root.1539345952240 DISCONNECT
2018.10.12 14:05:55.893 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 0
2018.10.12 14:05:55.894 5: ----------------------------------------
2018.10.12 14:05:55.894 5: myMSwitch: eingehendes Event von -> MQTT
2018.10.12 14:05:55.894 5: ----------------------------------------
2018.10.12 14:05:55.897 4: DbLog myDbLog -> ################################################################
2018.10.12 14:05:55.897 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:05:55.897 4: DbLog myDbLog -> ################################################################
2018.10.12 14:05:55.897 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:05:55.898 4: DbLog myDbLog -> check Device: MQTT , Event: nrclients: 0
2018.10.12 14:05:55.905 5: End notify loop for MQTT
2018.10.12 14:05:56.085 4: Connection accepted from MQTT_192.168.0.46_56860
2018.10.12 14:05:56.086 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 1
2018.10.12 14:05:56.087 5: ----------------------------------------
2018.10.12 14:05:56.087 5: myMSwitch: eingehendes Event von -> MQTT
2018.10.12 14:05:56.087 5: ----------------------------------------
2018.10.12 14:05:56.090 4: DbLog myDbLog -> ################################################################
2018.10.12 14:05:56.090 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:05:56.090 4: DbLog myDbLog -> ################################################################
2018.10.12 14:05:56.090 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:05:56.090 4: DbLog myDbLog -> check Device: MQTT , Event: nrclients: 1
2018.10.12 14:05:56.098 5: End notify loop for MQTT
2018.10.12 14:05:56.100 4: MQTT_192.168.0.46_56860 root.1539345953808 CONNECT V:3 keepAlive:60
2018.10.12 14:06:05.858 4: MQTT_192.168.0.46_56860 root.1539345953808 PUBLISH test:abc
2018.10.12 14:06:05.859 5: MQTT: dispatch autocreate:root.1539345953808:test:abc
2018.10.12 14:06:05.914 5: Loading ./FHEM/10_MQTT2_DEVICE.pm
2018.10.12 14:06:05.938 5: Starting notify loop for global, 1 event(s), first is UNDEFINED MQTT2_root.1539345953808 MQTT2_DEVICE root.1539345953808
2018.10.12 14:06:05.938 5: ----------------------------------------
2018.10.12 14:06:05.938 5: myMSwitch: eingehendes Event von -> global
2018.10.12 14:06:05.938 5: ----------------------------------------
2018.10.12 14:06:05.942 4: DbLog myDbLog -> ################################################################
2018.10.12 14:06:05.942 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:06:05.942 4: DbLog myDbLog -> ################################################################
2018.10.12 14:06:05.942 4: DbLog myDbLog -> number of events received: 1 for device: global
2018.10.12 14:06:05.942 4: DbLog myDbLog -> check Device: global , Event: UNDEFINED MQTT2_root.1539345953808 MQTT2_DEVICE root.1539345953808
2018.10.12 14:06:05.958 5: End notify loop for global
2018.10.12 14:06:05.958 5: Starting notify loop for MQTT, 1 event(s), first is test:abc
2018.10.12 14:06:05.958 5: ----------------------------------------
2018.10.12 14:06:05.958 5: myMSwitch: eingehendes Event von -> MQTT
2018.10.12 14:06:05.958 5: ----------------------------------------
2018.10.12 14:06:05.960 4: DbLog myDbLog -> ################################################################
2018.10.12 14:06:05.960 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:06:05.960 4: DbLog myDbLog -> ################################################################
2018.10.12 14:06:05.960 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:06:05.960 4: DbLog myDbLog -> check Device: MQTT , Event: test:abc
2018.10.12 14:06:05.964 5: End notify loop for MQTT

myMSwitch habe ich disabled da es kurz vor dem Absturz abgearbeitet wurde

2018.10.12 14:19:51.147 4: Connection accepted from MQTT_192.168.0.46_57042
2018.10.12 14:19:51.149 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 1
2018.10.12 14:19:51.149 5: createNotifyHash
2018.10.12 14:19:51.171 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:51.171 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:19:51.171 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:51.171 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:19:51.172 4: DbLog myDbLog -> check Device: MQTT , Event: nrclients: 1
2018.10.12 14:19:51.182 5: End notify loop for MQTT
2018.10.12 14:19:51.185 4: MQTT_192.168.0.46_57042 root.1539346789386 CONNECT V:3 keepAlive:60
2018.10.12 14:19:51.197 4: MQTT_192.168.0.46_57042 root.1539346789386 SUBSCRIBE
2018.10.12 14:19:53.553 4: MQTT_192.168.0.46_57042 root.1539346789386 DISCONNECT
2018.10.12 14:19:53.555 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 0
2018.10.12 14:19:53.558 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:53.559 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:19:53.559 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:53.559 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:19:53.560 4: DbLog myDbLog -> check Device: MQTT , Event: nrclients: 0
2018.10.12 14:19:53.569 5: End notify loop for MQTT
2018.10.12 14:19:53.573 4: Connection accepted from MQTT_192.168.0.46_57056
2018.10.12 14:19:53.574 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 1
2018.10.12 14:19:53.577 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:53.577 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:19:53.577 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:53.577 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:19:53.578 4: DbLog myDbLog -> check Device: MQTT , Event: nrclients: 1
2018.10.12 14:19:53.587 5: End notify loop for MQTT
2018.10.12 14:19:53.589 4: MQTT_192.168.0.46_57056 root.1539346791825 CONNECT V:3 keepAlive:60
2018.10.12 14:19:58.646 4: MQTT_192.168.0.46_57056 root.1539346791825 PUBLISH test:hhz
2018.10.12 14:19:58.647 5: MQTT: dispatch autocreate:root.1539346791825:test:hhz
2018.10.12 14:19:58.713 5: Loading ./FHEM/10_MQTT2_DEVICE.pm
2018.10.12 14:19:58.738 5: Starting notify loop for global, 1 event(s), first is UNDEFINED MQTT2_root.1539346791825 MQTT2_DEVICE root.1539346791825
2018.10.12 14:19:58.742 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:58.742 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:19:58.742 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:58.742 4: DbLog myDbLog -> number of events received: 1 for device: global
2018.10.12 14:19:58.742 4: DbLog myDbLog -> check Device: global , Event: UNDEFINED MQTT2_root.1539346791825 MQTT2_DEVICE root.1539346791825
2018.10.12 14:19:58.758 5: End notify loop for global
2018.10.12 14:19:58.759 5: Starting notify loop for MQTT, 1 event(s), first is test:hhz
2018.10.12 14:19:58.760 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:58.760 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 14:19:58.760 4: DbLog myDbLog -> ################################################################
2018.10.12 14:19:58.760 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 14:19:58.761 4: DbLog myDbLog -> check Device: MQTT , Event: test:hhz
2018.10.12 14:19:58.765 5: End notify loop for MQTT
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 12 Oktober 2018, 16:31:52
Ich kann da keine Probleme entdecken. Hat sich FHEM auch diesmal beendet?

Wenn ja, dann bitte in FHEM/00_MQTT2_SERVER.pm die Zeilen unter "#Lowlevel debugging" aktivieren, und das Problem erneut mit "perl fhem.pl -d fhem.cfg" reproduzieren.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: kadettilac89 am 12 Oktober 2018, 17:22:04
Ich kann da keine Probleme entdecken. Hat sich FHEM auch diesmal beendet?

Wenn ja, dann bitte in FHEM/00_MQTT2_SERVER.pm die Zeilen unter "#Lowlevel debugging" aktivieren, und das Problem erneut mit "perl fhem.pl -d fhem.cfg" reproduzieren.

hätte ich dazu schreiben können, ja, auch mit deaktiviertem MSwitch crasht Fhem

Einkommentierte Zeilen ...
  # Lowlevel debugging
   my $pltxt = $pl;
   $pltxt =~ s/([^ -~])/"(".ord($1).")"/ge;
   Log3 $sname, 5, "$pltxt";

Nun 2 weitere Test, jedesmal endet es mit Crash

selber Test wie vorher ....

2018.10.12 16:50:25.467 4: Connection accepted from MQTT_192.168.0.46_59000
2018.10.12 16:50:25.468 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 1
2018.10.12 16:50:25.471 4: DbLog myDbLog -> ################################################################
2018.10.12 16:50:25.471 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 16:50:25.472 4: DbLog myDbLog -> ################################################################
2018.10.12 16:50:25.472 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 16:50:25.472 4: DbLog myDbLog -> check Device: MQTT , Event: nrclients: 1
2018.10.12 16:50:25.481 5: End notify loop for MQTT
2018.10.12 16:50:25.483 5: (0)(6)MQIsdp(3)(2)(0)<(0)(18)root.1539355822256
2018.10.12 16:50:25.484 4: MQTT_192.168.0.46_59000 root.1539355822256 CONNECT V:3 keepAlive:60
2018.10.12 16:50:25.498 5: (0)(1)(0)(4)test(1)
2018.10.12 16:50:25.498 4: MQTT_192.168.0.46_59000 root.1539355822256 SUBSCRIBE
2018.10.12 16:50:25.498 4:   topic:test qos:1
2018.10.12 16:50:35.484 5: IP: 192.168.0.36 -> 192.168.0.36
2018.10.12 16:50:36.325 5: (0)(8)test/abcmsg
2018.10.12 16:50:36.326 4: MQTT_192.168.0.46_59000 root.1539355822256 PUBLISH test/abc:msg
2018.10.12 16:50:36.326 5: MQTT: dispatch autocreate:root.1539355822256:test/abc:msg
2018.10.12 16:50:36.392 5: Loading ./FHEM/10_MQTT2_DEVICE.pm
2018.10.12 16:50:36.416 5: Starting notify loop for global, 1 event(s), first is UNDEFINED MQTT2_root.1539355822256 MQTT2_DEVICE root.1539355822256
2018.10.12 16:50:36.420 4: DbLog myDbLog -> ################################################################
2018.10.12 16:50:36.420 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 16:50:36.420 4: DbLog myDbLog -> ################################################################
2018.10.12 16:50:36.420 4: DbLog myDbLog -> number of events received: 1 for device: global
2018.10.12 16:50:36.420 4: DbLog myDbLog -> check Device: global , Event: UNDEFINED MQTT2_root.1539355822256 MQTT2_DEVICE root.1539355822256
2018.10.12 16:50:36.437 5: End notify loop for global
2018.10.12 16:50:36.437 5: Starting notify loop for MQTT, 1 event(s), first is test/abc:msg
2018.10.12 16:50:36.439 4: DbLog myDbLog -> ################################################################
2018.10.12 16:50:36.439 4: DbLog myDbLog -> ###              start of new Logcycle                       ###
2018.10.12 16:50:36.439 4: DbLog myDbLog -> ################################################################
2018.10.12 16:50:36.439 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.12 16:50:36.439 4: DbLog myDbLog -> check Device: MQTT , Event: test/abc:msg
2018.10.12 16:50:36.443 5: End notify loop for MQTT


deaktiviertes DBLog (attr. disable 1)

ich weiß, dass syslog oder Thermostate erstmal nichts damit zu tun haben, ich habe aus dem Log nichts gelöscht ...

2018.10.12 17:01:07.105 4: Connection accepted from MQTT_192.168.0.46_59194
2018.10.12 17:01:07.106 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 1
2018.10.12 17:01:07.106 5: createNotifyHash
2018.10.12 17:01:07.132 5: End notify loop for MQTT
2018.10.12 17:01:07.134 5: (0)(6)MQIsdp(3)(2)(0)<(0)(18)root.1539356465317
2018.10.12 17:01:07.135 4: MQTT_192.168.0.46_59194 root.1539356465317 CONNECT V:3 keepAlive:60
2018.10.12 17:01:07.544 5: (0)(1)(0)(4)test(1)
2018.10.12 17:01:07.545 4: MQTT_192.168.0.46_59194 root.1539356465317 SUBSCRIBE
2018.10.12 17:01:07.545 4:   topic:test qos:1
2018.10.12 17:01:13.354 5: SYSMON sysmon: updateReadings.1060
2018.10.12 17:01:13.370 4: BlockingCall (SYSMON_blockingCall): created child (20322), uses telnetPort to connect back
2018.10.12 17:01:13.390 4: Connection accepted from telnetPort_127.0.0.1_50432
2018.10.12 17:01:13.394 5: Cmd: >{BlockingRegisterTelnet($cl,14)}<
2018.10.12 17:01:13.397 5: SYSMON sysmon: blockingCall.954 sysmon,
2018.10.12 17:01:13.398 5: SYSMON sysmon: Exec_Local.4151 Execute '[ -d /proc/ ] && echo 1 || echo 0'
2018.10.12 17:01:13.427 5: SYSMON sysmon: Exec_Local.4164 Result '1'
2018.10.12 17:01:13.428 5: SYSMON sysmon: Exec_Local.4151 Execute 'cat /proc/uptime'
2018.10.12 17:01:13.457 5: SYSMON sysmon: Exec_Local.4164 Result '24443.78 95789.40'
2018.10.12 17:01:13.457 5: SYSMON sysmon: Exec_Local.4151 Execute 'cat /proc/stat|grep 'cpu ''
2018.10.12 17:01:13.495 5: SYSMON sysmon: Exec_Local.4164 Result 'cpu  121441 778 48041 9427590 16082 0 11023 0 0 0'
2018.10.12 17:01:13.496 5: SYSMON sysmon: Exec_Local.4151 Execute '[ -f /sys/devices/system/cpu/kernel_max ] && echo 1 || echo 0'
2018.10.12 17:01:13.524 5: SYSMON sysmon: Exec_Local.4164 Result '1'
2018.10.12 17:01:13.525 5: SYSMON sysmon: Exec_Local.4151 Execute 'cat /sys/devices/system/cpu/kernel_max'
2018.10.12 17:01:13.554 5: SYSMON sysmon: Exec_Local.4164 Result '3'
2018.10.12 17:01:13.556 5: SYSMON sysmon: obtainParameters_intern.1350 User-Defined Reading: [certExpires][720][certExpires][cat /opt/fhem/log/cert_age.txt]
2018.10.12 17:01:13.556 5: SYSMON sysmon: obtainParameters_intern.1358 User-Defined Reading: [certExpires][720][certExpires][cat /opt/fhem/log/cert_age.txt] out of refresh interval
2018.10.12 17:01:13.556 5: SYSMON sysmon: obtainParameters_intern.1350 User-Defined Reading: [updateStatus][720][updateStatus][cat /opt/fhem/log/updatestatus.txt | head -n1]
2018.10.12 17:01:13.556 5: SYSMON sysmon: obtainParameters_intern.1358 User-Defined Reading: [updateStatus][720][updateStatus][cat /opt/fhem/log/updatestatus.txt | head -n1] out of refresh interval
2018.10.12 17:01:13.556 5: SYSMON sysmon: obtainParameters_intern.1350 User-Defined Reading: [updateStatusList][720][updateStatusList][cat /opt/fhem/log/updatestatus.txt | tail -n +3]
2018.10.12 17:01:13.556 5: SYSMON sysmon: obtainParameters_intern.1358 User-Defined Reading: [updateStatusList][720][updateStatusList][cat /opt/fhem/log/updatestatus.txt | tail -n +3] out of refresh interval
2018.10.12 17:01:13.557 5: SYSMON sysmon: obtainParameters_intern.1372 User-Defined Fn: [backupAge][720]
2018.10.12 17:01:13.557 5: SYSMON sysmon: obtainParameters_intern.1380 User-Defined Fn: [backupAge][720] out of refresh interval
2018.10.12 17:01:13.558 5: Cmd: >{BlockingStart('14')}<
2018.10.12 17:01:13.562 5: Cmd: >{SYSMON_blockingFinish('name|sysmon|uptime|24443|fhemuptime_text|0 days, 00 hours, 01 minutes|fhemstarttime|1539356354|uptime_text|0 days, 06 hours, 47 minutes|starttime|1539332029|starttime_text|12.10.2018 10:13:49|idletime|23568 96.42 %|fhemstarttime_text|12.10.2018 16:59:14|idletime_text|0 days, 06 hours, 32 minutes (96.42 %)|fhemuptime|119')}<
2018.10.12 17:01:13.563 5: SYSMON sysmon: blockingFinish.1041 name|sysmon|uptime|24443|fhemuptime_text|0 days, 00 hours, 01 minutes|fhemstarttime|1539356354|uptime_text|0 days, 06 hours, 47 minutes|starttime|1539332029|starttime_text|12.10.2018 10:13:49|idletime|23568 96.42 %|fhemstarttime_text|12.10.2018 16:59:14|idletime_text|0 days, 06 hours, 32 minutes (96.42 %)|fhemuptime|119
2018.10.12 17:01:13.563 5: SYSMON sysmon: updateReadings.1060
2018.10.12 17:01:16.896 5: (0)(8)test/abcmsg
2018.10.12 17:01:16.896 4: MQTT_192.168.0.46_59194 root.1539356465317 PUBLISH test/abc:msg
2018.10.12 17:01:16.897 5: MQTT: dispatch autocreate:root.1539356465317:test/abc:msg
2018.10.12 17:01:16.955 5: Loading ./FHEM/10_MQTT2_DEVICE.pm
2018.10.12 17:01:16.990 5: Starting notify loop for global, 1 event(s), first is UNDEFINED MQTT2_root.1539356465317 MQTT2_DEVICE root.1539356465317
2018.10.12 17:01:16.998 4: wp_schlafzimmer(getDeviceType): dy_Reboot is not supported
2018.10.12 17:01:16.998 4: wp_schlafzimmer(getDeviceType): Heizung_Wohnzimmer, model HM-CC-RT-DN has no chanNo
2018.10.12 17:01:16.998 4: wp_schlafzimmer(getDeviceType): Programm_SZ is not supported
2018.10.12 17:01:16.998 5: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_WindowRec, HM-CC-RT-DN, 3
2018.10.12 17:01:16.998 4: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_WindowRec is not supported
2018.10.12 17:01:16.999 5: wp_schlafzimmer(getDeviceType): Heizung_Wohnzimmer_Clima, HM-CC-RT-DN, 4
2018.10.12 17:01:16.999 4: wp_schlafzimmer(getDeviceType): Heizung_Wohnzimmer_Clima is type CUL_HM
2018.10.12 17:01:16.999 4: wp_schlafzimmer(getDeviceType): dy_test1 is not supported
2018.10.12 17:01:16.999 4: wp_schlafzimmer(getDeviceType): HMTempSensor2, model HB-UNI-Sensor1 is not supported
2018.10.12 17:01:16.999 4: wp_schlafzimmer(getDeviceType): dy_eventlog is not supported
2018.10.12 17:01:16.999 5: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_Climate, HM-CC-RT-DN, 2
2018.10.12 17:01:16.999 4: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_Climate is not supported
2018.10.12 17:01:16.999 4: wp_schlafzimmer(getDeviceType): TVTimer is not supported
2018.10.12 17:01:17.000 4: wp_schlafzimmer(getDeviceType): Programm_WZ is not supported
2018.10.12 17:01:17.000 5: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_ClimaTeam, HM-CC-RT-DN, 5
2018.10.12 17:01:17.000 4: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_ClimaTeam is not supported
2018.10.12 17:01:17.000 4: wp_schlafzimmer(getDeviceType): ActionDetector, model ActionDetector is not supported
2018.10.12 17:01:17.000 5: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_Clima, HM-CC-RT-DN, 4
2018.10.12 17:01:17.000 4: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_Clima is type CUL_HM
2018.10.12 17:01:17.000 4: wp_schlafzimmer(getDeviceType): HMTempSensor4, model HB-UNI-Sensor1 is not supported
2018.10.12 17:01:17.001 4: wp_schlafzimmer(getDeviceType): dy_test3 is not supported
2018.10.12 17:01:17.001 5: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_remote, HM-CC-RT-DN, 6
2018.10.12 17:01:17.001 4: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_remote is not supported
2018.10.12 17:01:17.001 4: wp_schlafzimmer(getDeviceType): dy_autocreate is not supported
2018.10.12 17:01:17.001 4: wp_schlafzimmer(getDeviceType): dy_daylight is not supported
2018.10.12 17:01:17.001 4: wp_schlafzimmer(getDeviceType): dy_Dimmer is not supported
2018.10.12 17:01:17.001 4: wp_schlafzimmer(getDeviceType): dy_GHome is not supported
2018.10.12 17:01:17.002 4: wp_schlafzimmer(getDeviceType): dy_test2 is not supported
2018.10.12 17:01:17.002 4: wp_schlafzimmer(getDeviceType): wp_wohnzimmer is type WEEKPROFILE
2018.10.12 17:01:17.002 4: wp_schlafzimmer(getDeviceType): hm_door1, model HM-SEC-RHS is not supported
2018.10.12 17:01:17.002 4: wp_schlafzimmer(getDeviceType): dy_Dimmer2 is not supported
2018.10.12 17:01:17.002 4: wp_schlafzimmer(getDeviceType): HMTempSensor3, model HB-UNI-Sensor1 is not supported
2018.10.12 17:01:17.003 4: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer, model HM-CC-RT-DN has no chanNo
2018.10.12 17:01:17.003 4: wp_schlafzimmer(getDeviceType): dy_Farbwechsel is not supported
2018.10.12 17:01:17.003 4: wp_schlafzimmer(getDeviceType): dy_Kodi is not supported
2018.10.12 17:01:17.003 5: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_Weather, HM-CC-RT-DN, 1
2018.10.12 17:01:17.003 4: wp_schlafzimmer(getDeviceType): Heizung_Schlafzimmer_Weather is not supported
2018.10.12 17:01:17.007 5: End notify loop for global
2018.10.12 17:01:17.007 5: Starting notify loop for MQTT, 1 event(s), first is test/abc:msg
2018.10.12 17:01:17.012 5: End notify loop for MQTT

Um es weiter einzugrenzen habe ich Fhem mit der Demo-Config (fhem.cfg.demo) gestartet und das Modul dort identisch eingebunden
==> KEIN Crash.

Es gibt also Abhängigkeiten zu einem anderen Modul.

Log fhem.cfg.demo (ohne Crash)
2018.10.12 17:11:44.184 4: Connection accepted from MQTT_192.168.0.46_59448
2018.10.12 17:11:44.185 5: Starting notify loop for MQTT, 1 event(s), first is nrclients: 1
2018.10.12 17:11:44.186 4: dewpoint_notify: cmd_type=dewpoint devname=MQTT dewname=dew_all, dev=MQTT, dev_regex=.* temp_name=temperature hum_name=humidity
2018.10.12 17:11:44.186 5: dewpoint_notify: s='nrclients: 1'
2018.10.12 17:11:44.186 5: dewpoint_notify: evName='nrclients:' val=1'
2018.10.12 17:11:44.186 5: dewpoint max_timediff=1
2018.10.12 17:11:44.190 5: End notify loop for MQTT
2018.10.12 17:11:44.191 5: (0)(6)MQIsdp(3)(2)(0)<(0)(18)root.1539357102436
2018.10.12 17:11:44.191 4: MQTT_192.168.0.46_59448 root.1539357102436 CONNECT V:3 keepAlive:60
2018.10.12 17:11:44.207 5: (0)(1)(0)(4)test(1)
2018.10.12 17:11:44.207 4: MQTT_192.168.0.46_59448 root.1539357102436 SUBSCRIBE
2018.10.12 17:11:44.207 4:   topic:test qos:1
2018.10.12 17:11:54.764 5: (0)(8)test/abcmsg
2018.10.12 17:11:54.765 4: MQTT_192.168.0.46_59448 root.1539357102436 PUBLISH test/abc:msg
2018.10.12 17:11:54.765 5: MQTT: dispatch autocreate:root.1539357102436:test/abc:msg
2018.10.12 17:11:54.824 5: Starting notify loop for global, 1 event(s), first is UNDEFINED MQTT2_root.1539357102436 MQTT2_DEVICE root.1539357102436
2018.10.12 17:11:54.825 4: dewpoint_notify: cmd_type=dewpoint devname=global dewname=dew_all, dev=global, dev_regex=.* temp_name=temperature hum_name=humidity
2018.10.12 17:11:54.825 5: dewpoint_notify: s='UNDEFINED MQTT2_root.1539357102436 MQTT2_DEVICE root.1539357102436'
2018.10.12 17:11:54.825 5: dewpoint_notify: evName='UNDEFINED' val=MQTT2_root.1539357102436'
2018.10.12 17:11:54.825 5: dewpoint max_timediff=1
2018.10.12 17:11:54.828 2: autocreate: define MQTT2_root.1539357102436 MQTT2_DEVICE root.1539357102436
2018.10.12 17:11:54.849 5: End notify loop for global
2018.10.12 17:11:54.850 5: Starting notify loop for global, 1 event(s), first is ATTR MQTT2_root.1539357102436 readingList root.1539357102436:test/abc:.* abc
2018.10.12 17:11:54.850 5: createNotifyHash
2018.10.12 17:11:54.852 4: dewpoint_notify: cmd_type=dewpoint devname=global dewname=dew_all, dev=global, dev_regex=.* temp_name=temperature hum_name=humidity
2018.10.12 17:11:54.852 5: dewpoint_notify: s='ATTR MQTT2_root.1539357102436 readingList root.1539357102436:test/abc:.* abc'
2018.10.12 17:11:54.852 5: dewpoint_notify: evName='ATTR' val=MQTT2_root.1539357102436'
2018.10.12 17:11:54.852 5: dewpoint max_timediff=1
2018.10.12 17:11:54.855 5: End notify loop for global
2018.10.12 17:11:54.856 4: MQTT2_DEVICE_Parse: MQTT2_root.1539357102436 test/abc => abc
2018.10.12 17:11:54.856 5: Starting notify loop for MQTT2_root.1539357102436, 1 event(s), first is abc: msg
2018.10.12 17:11:54.856 4: dewpoint_notify: cmd_type=dewpoint devname=MQTT2_root.1539357102436 dewname=dew_all, dev=MQTT2_root.1539357102436, dev_regex=.* temp_name=temperature hum_name=humidity
2018.10.12 17:11:54.856 5: dewpoint_notify: s='abc: msg'
2018.10.12 17:11:54.856 5: dewpoint_notify: evName='abc:' val=msg'
2018.10.12 17:11:54.857 5: dewpoint max_timediff=1
2018.10.12 17:11:54.858 5: End notify loop for MQTT2_root.1539357102436


Hier meine Module ... alle ohne explizite Namen haben mehr als 2 Devices, wollte die Liste nicht zu lange machen
Global:
  global               (no definition)

CUL:

MQTT2_SERVER:
  MQTT                 (Initialized)

FHEMWEB:

HTTPSRV:
  TABLETUI             (TABLETUI)

CUL_HM:

IT:

RESIDENTS:
  Residents            (home)

CUL_TCM97001:
  TempSensor1          (T: 19.1 H: 52)

ROOMMATE:

EspLedController:
  LED_rgb              (disconnected)

speedtest:
  speedtest            (Initialized)

readingsChange:
  rc_test1             (active)

readingsGroup:

ESPEasy:

Spotify:
  Spotify              (connected)

SYSMON:
  sysmon               (Initialized)
  sysmon_BPI           (Inactive)

CALVIEW:
  myFhemCal_view       (t: 5 td: 0 tm: 0)

Calendar:
  myFhemCal            (triggered)

Twilight:
  twilight             (6)

Weather:

ENIGMA2:
  enigma2              (absent)

KODI:
  kodi                 (Initialized)

Pushover:
  pushover             (disconnected)

PRESENCE:

at:

eventTypes:
  eventTypes           (active)

notify:

watchdog:

FileLog:

DbLog:
  myDbLog              (connected)

DbRep:
  myDbRep              (connected)
  myDbRepAgent         (connected » ProcTime: 0.0014 sec)

remotecontrol:
  kodi_rc              (initialized)

allowed:
  allowed_WEBCMD       (validFor:WEBCMD)

DOIF:

GEOFANCY:
  geofancy             (initialized)

HMinfo:
  hm                   (updated:2017-04-15 11:38:35)

HMtemplate:
  ht                   (init)

MSwitch:
  myMSwitch            (off)

SVG:

WOL:

autocreate:
  autocreate           (disabled)

dummy:

freezemon:
  myFreezemon          (inactive)

structure:
  Programm             (Aus)

telnet:
  telnetPort           (Initialized)
  telnetPort_127.0.0.1_50720 (Connected)

weblink:

weekprofile:

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 13 Oktober 2018, 11:17:00
Zitat
Nun 2 weitere Test, jedesmal endet es mit Crash
Ich sehe leider da auch nicht mehr.

Was mir komisch vorkommt: wenn FHEM abstuerzt, dann ist entweder ein schwerwiegender Perl-Programmierfehler dran Schuld, oder ein Fehler im perl-binary oder in einen der verwendeten C-Bibliotheken. Im ersten Fall gibt das Perl-Binary auf der Konsole eine Fehlermeldung aus, im zweiten Fall das Betriebsystem bzw. der Shell, von wo man perl gestartet hat. In deinem Fall ist aber nichts davon zu sehen: startest du FHEM aus der Kommandozeile (wie ich es gedacht habe), oder schaust du nur nachtraeglich die Logs an?

Falls Kommandozeile, und keine weiteren Daten:
- bitte Prozess-Rueckgabewert nach dem FHEM-Crash ausgeben mit: echo $!
- FHEM unter strace starten, und die strace logs hier anhaengen:
strace -f -o /tmp/fhem.strace.log perl fhem.pl -d fhem.cfg
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: kadettilac89 am 13 Oktober 2018, 11:42:33
habe direkt auf der Commandline gestartet ...

Fehler gefunden. Danke für die Unterstützung.

Apptime deaktiviert und es funktioniert. Apptime ist mir nicht wichtig, ich lasse es aus.

mit "echo $!" erscheinte folgende Ausgabe: (letzen Zeilen des Logs wie gehabt).
.....
2018.10.13 11:30:10.177 4: DbLog myDbLog -> number of events received: 1 for device: MQTT
2018.10.13 11:30:10.178 4: DbLog myDbLog -> check Device: MQTT , Event: test/ggg:vvv
2018.10.13 11:30:10.184 5: End notify loop for MQTT
fhem@raspfhem:~$ echo $!
argument is not a reference at ./FHEM/98_apptime.pm line 127.

fhem@raspfhem:~$

Sourcecode aus apptime
  if(%prioQueues) {
    my $nice = minNum(keys %prioQueues);
    my $entry = shift(@{$prioQueues{$nice}});
    delete $prioQueues{$nice} if(!@{$prioQueues{$nice}});

127 --->>    $cv = svref_2object($entry->{fn});  <<---
    $fnname = $cv->GV->NAME;
    $shortarg = (defined($entry->{arg})?$entry->{arg}:"");
    $shortarg = "HASH_unnamed" if (   (ref($shortarg) eq "HASH")
                                   && !defined($shortarg->{NAME}) );
    ($shortarg,undef) = split(/:|;/,$shortarg,2);
    apptime_getTiming("global","nice-".$fnname.";".$shortarg, $entry->{fn}, $now, $entry->{arg});

    $nextat = 1 if(%prioQueues);
  }
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 13 Oktober 2018, 12:27:00
argument is not a reference at ./FHEM/98_apptime.pm line 127.Das muss ich mir merken. Danke fuer dein Ausdauer!
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: MarkusN am 15 Oktober 2018, 20:19:57
Wie genau verhält es sich mit den retained messages? Soweit ich weiß werden retained messages gelöscht wenn FHEM neu gestartet wird. Bei mir bleibt das retained reading im MQTT2_SERVER device jedoch bestehen wenn ich fhem restarte, und auch die clients handeln entsprechend wenn sie sich mit dem Server verbinden.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 15 Oktober 2018, 20:47:54
Das Modul speichert inzwischen die retained Meldungen in dem Reading mit dem Namen RETAIN, damit werden diese auch gespeichert, und stehen nach einem FHEM-Start wieder zur Verfuegung. Ich habe die Doku angepasst.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: MarkusN am 16 Oktober 2018, 19:37:50
Was wäre denn die korrekte Herangehensweise wenn ich retained messages entfernen will? Mit deletereading das ganze Reading im MQTT2_SERVER löschen?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 16 Oktober 2018, 22:03:51
Ja, mit deletereading alles entfernen, oder mit setreading den Wert aendern.
Der Wert der RETAINED Readings muss aber weiterhin ein gueltiger JSON sein.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: der-pw am 24 November 2018, 10:51:23
Bitte um Rücksicht, falls das schon bekannt ist. Ich habe mich jetzt nicht durch den gesamten Thread gelesen und gefunden habe ich nichts.

Wenn ich über readingList einen Topic abonniere bspw. "DVES_9D7CEE:stat/sonoff_wz_dual/POWER1:.* POWER1", einen weiteren anlege, bspw. "DVES_9D7CEE:stat/sonoff_wz_dual/POWER2:.* POWER2",
den "POWER2" dann wieder lösche, wird er fleißig weiter abonniert. Erst "shutdown restart" oder das Löschen und Neuanlegen von "readingList" löst das Problem.

Ist das bekannt/bewusst, oder liegt der Fehler irgendwo zwischen meinem rechten und linken Ohr?

Schöne Grüße,
Patrick
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Beta-User am 24 November 2018, 11:26:39
Dürfte denselben Hintergrund haben wie das bereits häufiger beschriebene Phänomen, dass nach einem "copy" und Änderungen der Topics auch das mit copy angelegte Device alle Aktualisierungen erhält (hatte ich z.B. beim Kopieren der IKEA-zigbee-Bulb bereits beschrieben). Scheint an mit übernommenen internals zu liegen.

Das Problem wird auch durch einen Reload des MQTT2_DEVICE-Moduls behoben, shutdown+restart ist nicht erforderlich.

@Rudi, da das häufiger (hier mind. Fall 3) zu Irritationen führt: Kann man daran was ändern (als Nicht-Experte ich würde auf die notifydev als Ursache tippen, die nach copy bzw. der Änderung der readingList neu zu generieren wäre).
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 24 November 2018, 16:10:21
Ich meine das Problem behoben zu haben, bitte um Test und Feedback.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: der-pw am 24 November 2018, 21:48:41
Mit der aktuellen Version aus dem trunk soeben getestet.

Sobald ich das zusätzliche Topic wieder lösche, ist nun auch sofort Funkstille auf dem Reading.
Super! :)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: essera am 02 Dezember 2018, 01:02:34
Ich habe seit ein paar Tagen auf meinem Testsystem von Mosquitto auf MQTT2 Server und MQTT2_DEVICES umgestellt. Das Ganze funktioniert , auch Dank der Infos aus dem Thread sehr gut - danke dafür!
Nun möchte ich auch eine farbige Leuchte von HUE einbinden.
Das dazugehörige Device habe ich erstellt.

DEVICETOPIC test_hue
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 87
   MQTT2_FHEM_Server_TIME 2018-12-02 00:46:30
   MSGCNT     87
   NAME       test_hue
   NR         28
   STATE      ON
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-02 00:46:30   brightness      15
     2018-12-02 00:46:30   color_temp      153
     2018-12-02 00:46:30   color_x         0.153
     2018-12-02 00:46:30   color_y         0.048
     2018-12-02 00:46:30   state           ON
Attributes:
   IODev      MQTT2_FHEM_Server
   icon       light_control
   readingList zigbee_pi:zigbee2mqtt/0x0017880102784501:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    on:noArg zigbee2mqtt/0x0017880102784501/set {"state":"ON"}
  off:noArg zigbee2mqtt/0x0017880102784501/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x0017880102784501/set {"state":"on","$EVTPART0":"$EVTPART1"}
  color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/0x0017880102784501/set {"$EVTPART0":"$EVTPART1"}
  hue:colorpicker,HUE,0,1,359 zigbee2mqtt/0x0017880102784501/set {"color":"$EVTPART1"}
   webCmd     brightness:color_temp:hue:on:off
On, off, brightness und color_temp funktionieren einwandfrei. Ich habe nur Probleme mit der eigentlichen Farbeinstellung.
Setze ich z.B.
{"color_temp":"454"}  erhalte ich als Antwort auch: {"state":"ON","brightness":105,"color_temp":454,"color":{"x":0.505,"y":0.415}}

Setze ich jedoch {"color":"115"} erhalte ich als Antwort: {"state":"ON","brightness":105,"color_temp":153,"color":{"x":0.153,"y":0.048}}
Egal welchen Wert ich für Color nehme ist die color_temp immer 153 - und der entsprechende x-Wert ist auch 0.153, y-Wert verändert sich.

Hat jemand eine Rat ?
btw, der Colorpicker mit RGB Werten funktioniert auch nicht.


Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 02 Dezember 2018, 21:25:57
Zitat
Setze ich jedoch {"color":"115"} erhalte ich als Antwort: {"state":"ON","brightness":105,"color_temp":153,"color":{"x":0.153,"y":0.048}}
Das schaut fuer mich nicht nach einem MQTT2_SERVER oder MQTT2_DEVICE Problem aus, sondern nach einem HUE bs. zigbee2mqtt Problem.

Die mit attrTemplate setzbare zigbee2mqtt2_colorbulb enthaelt kein hue Befehl.
Woher stammt die Idee, dass es so funktionieren sollte?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: essera am 04 Dezember 2018, 22:40:36
War ein Fehler meinerseits mit dem falschen Thread. Ich wollte eigentlich hier posten:  "Thema: Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE"
und hatte wohl zu viele Fenster auf und bin falsch gelandet. Evtl. kannst du den Post verschieben...

Zitat
Woher stammt die Idee, dass es so funktionieren sollte?
Die Idee es so zu versuchen stammt von mir - weil es nicht klappt hatte ich ja um Hilfe gebeten.

Ich habe inzwischen dein anderes MQTT_DEVICE Template ausprobiert: "zigbee2mqtt_ColorbulbWithout_Color_Temp"

Dann sieht das Device so aus:
Internals:
   DEVICETOPIC test_hue
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 38
   MQTT2_FHEM_Server_TIME 2018-12-04 22:24:39
   MSGCNT     38
   NAME       test_hue
   NR         22
   STATE      color
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-04 22:24:39   brightness      225
     2018-12-04 22:24:39   color_temp      153
     2018-12-04 22:24:39   color_x         0.153
     2018-12-04 22:24:39   color_y         0.048
     2018-12-04 22:26:45   state           color
Attributes:
   IODev      MQTT2_FHEM_Server
   devStateIcon {devStateIcon255($name)}
   icon       hue_filled_white_and_color_e27_b22
   readingList zigbee_pi:zigbee2mqtt/0x0017880102784501:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    on:noArg zigbee2mqtt/0x0017880102784501/set {"state":"ON"}
  off:noArg zigbee2mqtt/0x0017880102784501/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x0017880102784501/set {"state":"on","$EVTPART0":"$EVTPART1"}
  color:colorpicker,RGB {"zigbee2mqtt/0x0017880102784501/set " . encode_json(convertRGBtoR_G_B($EVTPART1))}
   stateFormat {lc ReadingsVal("$name","state",0)}
   webCmd     toggle:on:off:brightness:color

Ich erhalte aber schon bei der Ausführung des Templates im Event Log folgende Fehler:
2018.12.04 22:33:35.260 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 560) line 1.
2018-12-04 22:33:35.266 Global global ATTR test_hue icon hue_filled_white_and_color_e27_b22
2018.12.04 22:33:35.268 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 561) line 1.
2018.12.04 22:33:35.278 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 564) line 1.
2018-12-04 22:33:35.284 Global global ATTR test_hue stateFormat {lc ReadingsVal("$name","state",0)}
2018.12.04 22:33:35.286 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 565) line 1.
2018.12.04 22:33:35.297 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 567) line 1.
2018-12-04 22:33:35.302 Global global ATTR test_hue devStateIcon {devStateIcon255($name)}
2018.12.04 22:33:35.304 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 568) line 1.
2018.12.04 22:33:35.314 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 569) line 1.
2018-12-04 22:33:35.318 Global global ATTR test_hue webCmd toggle:on:off:brightness:color
2018.12.04 22:33:35.319 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 570) line 1.
2018.12.04 22:33:35.326 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 572) line 1.
2018-12-04 22:33:35.329 Global global ATTR test_hue setList on:noArg zigbee2mqtt/0x0017880102784501/set {"state":"ON"}   off:noArg zigbee2mqtt/0x0017880102784501/set {"state":"OFF"}   brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x0017880102784501/set {"state":"on","$EVTPART0":"$EVTPART1"}   color:colorpicker,RGB {"zigbee2mqtt/0x0017880102784501/set " . encode_json(convertRGBtoR_G_B($EVTPART1))}
2018.12.04 22:33:35.330 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 573) line 1.
2018.12.04 22:33:35.335 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 574) line 1.
2018-12-04 22:33:35.337 MQTT2_DEVICE test_hue attrTemplate zigbee2mqtt_colorbulbWithoutColorTemp
2018.12.04 22:33:35.339 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 575) line 1.
2018.12.04 22:33:35.362 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 576) line 1.
2018.12.04 22:33:35.547 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 579) line 1.

Das Ein/ Auschalten geht auch. Wenn ich jedoch eine Farbe auswähle und setzen mochte kommt anschließend noch folgender Fehler:

2018.12.04 22:36:16.988 1 : ERROR evaluating my $EVENT='color ffaf54';my $EVTPART0='color';my $NAME='test_hue';my $EVTPART1='ffaf54';{"zigbee2mqtt/0x0017880102784501/set " . encode_json(convertRGBtoR_G_B($EVTPART1))}: Undefined subroutine &main::convertRGBtoR_G_B called at (eval 592) line 1.
2018.12.04 22:36:16.997 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 594) line 1.
2018.12.04 22:36:16.999 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 595) line 1.

Liegts an mir oder hat das Template noch eine kleine Macke ..?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: essera am 04 Dezember 2018, 23:51:37
So - zu den Fehlermeldungen habe ich selber was gefunden.
Zitat
2018.12.04 22:33:35.268 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 561) line 1.
2018.12.04 22:33:35.278 1 : devStateIcon test_hue: Undefined subroutine &main::devStateIcon255 called at (eval 564) line 1.
Habe das Attr devStateIcon raus geschmissen weil ich die Sub Routine nicht in der 99_myUtils.pm hatte

Zitat
ERROR evaluating my $EVENT='color ffaf54';my $EVTPART0='color';my $NAME='test_hue';my $EVTPART1='ffaf54';{"zigbee2mqtt/0x0017880102784501/set " . encode_json(convertRGBtoR_G_B($EVTPART1))}: Undefined subroutine &main::convertRGBtoR_G_B called at (eval 592) line 1.
Hier habe ich die Sub convertRGBtoR_G_B() in der 99_myUtils.pm auch ergänzt.

Leider kann ich zur Sub encode_json() nichts wirklich richtiges finden. Den Hinweis es statt dessen mit der sub toJSON() zu versuchen führt zu diesem merkwürdigen Befehl
zigbee2mqtt/0x0017880102784501/set {"color":{"b":"0.729411764705882","g":"1","r":"0.937254901960784"},"transition":"1"}

mit dieser Rückmeldung: {"state":"ON","brightness":180,"color_temp":153,"color":{"x":0.153,"y":0.048}}



Also ein Stück weiter aber noch nicht am Ende..... hoffentlich..
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 06 Dezember 2018, 13:30:52
encode_json gibt es nach einem { use JSON } (und die JSON Perl-Bibliothek muss installiert sein)
Ich habe jetzt in 10_MQTT2_DEVICE.pm eine zigbee2mqtt_RGB2JSON() Funktion eingebaut, was  encode_json(convertRGBtoR_G_B())  ersetzt, und mqtt2.template angepasst.

Auch devStateIcon255 gibt es jetzt als zigbee2mqtt_devStateIcon255 aus MQTT2_DEVICE, mit angepassten mqtt2.template.

Ueber Feedback wuerde ich mich freuen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Beta-User am 06 Dezember 2018, 14:59:17
Ueber Feedback wuerde ich mich freuen.
Vorab mal ein Dankeschön :) .

Werde es (soweit mir möglich, ich habe keine farbigen/color_temp) austesten und dann auch ins Wiki packen. Was mir aufgefallen ist:
attr DEVICE devStateIcon {zigbee2mqtt_devStateIcon255($name)}wird nur in zigbee2mqtt_colorbulbWithoutColorTemp verwendet, nicht in den anderen beiden davorstehenden bulb-Typen. Absicht?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 06 Dezember 2018, 16:10:56
Nicht wirklich, ich habe diese Daten (mangels Hardware ohne Testen) uebernommen, damit die Template-Datei nicht so leer ist.
Falls jemand bessere Vorschlaege hat, bitte melden.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: essera am 06 Dezember 2018, 17:20:12
Zitat
Ueber Feedback wuerde ich mich freuen.

Erst mal danke für die schnelle Anpassungen.
Feedback gebe ich gerne: Checkst du denn die Änderungen noch ein oder muss ich die vorab irgendwo runter ziehen ? (im Update Check waren sie eben noch nicht drin)


Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Beta-User am 06 Dezember 2018, 17:34:26
Erst mal danke für die schnelle Anpassungen.
Feedback gebe ich gerne: Checkst du denn die Änderungen noch ein oder muss ich die vorab irgendwo runter ziehen ? (im Update Check waren sie eben noch nicht drin)
Sind im svn (und dann ab 7:45 morgen per update verfügbar, wer's vorher braucht dann aber auch die ...DEVICE mit runterziehen...).

@rudolfkoenig:
Da der originale "255-er"-code mal für meine "dummen" dimmbaren einfachen bulbs war, nehme ich an, dass das devStateIcon für alle drei Typen paßt. M.E. kann man das auch gleich noch einchecken, damit die template-Datei sich sinnvoll füllt ;) . Ich werde aber auch noch testen (nach dem update vermutlich) und dann berichten, wenn das erforderlich ist.... (Bei der Gelegenheit noch "BRIDGENAME" durch "bridge" ersetzen?)

Eine Anmerkung noch: Um die Datei nicht zu überfüllen, könnte es eine Idee sein, eine Art "parent" + "children"-Funktionalität einzubauen, also "name:tasmota_1channel" ("child") entspricht "name:tasmota_basic", und dann nur die Unterschiede (hier: nur noch Zeilen 98+99) zu benennen. Ist aber definitiv Prio "ganz weit hinten"
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: essera am 07 Dezember 2018, 19:47:47
So habe die Änderungen getestet:
Mit Spannung erwartet, dass meine farbige HUE funktioniert...
Bin vorsichtig ran gegangen und habe aus einer minimal Definition per Template erst mal "zigbee2mqqt_bulb" und "zigbee2mqqt_colorbulb" aufgerufen.

Internals:
   DEVICETOPIC test_hue
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 101
   MQTT2_FHEM_Server_TIME 2018-12-07 19:27:24
   MSGCNT     101
   NAME       test_hue
   NR         22
   STATE      on
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-07 19:27:24   brightness      150
     2018-12-07 19:27:24   color_temp      454
     2018-12-07 19:27:24   color_x         0.505
     2018-12-07 19:27:24   color_y         0.415
     2018-12-07 19:27:24   state           ON
Attributes:
   IODev      MQTT2_FHEM_Server
   devStateIcon {zigbee2mqtt_devStateIcon255($name)}
   icon       light_control
   readingList zigbee_pi:zigbee2mqtt/0x0017880102784501:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    on:noArg zigbee2mqtt/0x0017880102784501/set {"state":"ON"}
  off:noArg zigbee2mqtt/0x0017880102784501/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x0017880102784501/set {"state":"on","$EVTPART0":"$EVTPART1"}
  color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/0x0017880102784501/set {"$EVTPART0":"$EVTPART1"}
   stateFormat {lc ReadingsVal("$name","state",0)}
   verbose    5
   webCmd     brightness:color_temp

Ergebnis funktioniert! Anmerkung bei beiden Templates fehlt mir im webCmd  on bzw off.

Wenn ich nun versucht habe das Template "zigbee2mqqt_colorbulbWithoutColorTemp" aufzurufen erschien im Browser ein Fenster mit dem Fehler:

syntax error at (eval 901) line 1, near "))"

Der zugehörige Logeintrag sah so aus:

2018.12.07 19:10:36.417 1 : ERROR evaluating my $EVTPART1='1';my $EVTPART5='5';my $EVTPART2='2';my $EVTPART4='4';my $EVTPART0='0';my $EVTPART9='9';my $EVTPART6='6';my $EVTPART3='3';my $EVTPART7='7';my $EVTPART8='8';my $EVENT='0 1 2 3 4 5 6 7 8 9';{return undef; {"zigbee2mqtt/0x0017880102784501/set " . zigbee2mqtt_RGB2JSON($EVTPART1))}}: syntax error at (eval 635) line 1, near "))"



So wie ich das sehe ist beim Zusammenbau des Subaufruf 
{return undef; {"zigbee2mqtt/0x0017880102784501/set " . zigbee2mqtt_RGB2JSON($EVTPART1))}}
eine runde Klammer zuviel rein gekommen.


Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 07 Dezember 2018, 20:19:06
Zitat
Anmerkung bei beiden Templates fehlt mir im webCmd  on bzw off.
Ich habe jetzt bei allen drei bulbs toggle:on:off hinzugefuegt.

Zitat
eine runde Klammer zuviel rein gekommen.
Danke fuer den Hinweis, habs entfernt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 08 Dezember 2018, 22:16:36
Hallo habe seit einer Weile ein Problem dass nach einem Neustart nur manche Geräte schaltbar sind. Andere Geräte jedoch nicht. Stati werde immer korrekt angezeigt.

Ich vermute dass es bei irgendeinem Gerät ein Problem gibt, eventuell hängt das mit der folgenden Warnung zusammen?

PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_MQTT2_DEVICE.pm line 119.

Nach einem Neustart gehen dann andere Geräte ...

Was kann ich tun und wie kann ich rausfinden welches Gerät die Warnung auslöst?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 09 Dezember 2018, 00:21:00
Das Problem hatte wohl nichts mit der Warnung zu tun. Hat mich aber fast kirre gemacht.

Habe jetzt statt MQTT2_SERVER auf MQTT2_CLIENT mit mosquitto umgestellt und das Problem war weg.

Die MQTT2_Devices per attr sonoff.* IODEV einfach umgehängt. readingList angepasst und es lief. Das Problem trat erst seit ein paar Tagen auf. Kann an neuerer fhem Version oder dass ich nochmal einige neue Tasmota Geräte hinzugefügt habe liegen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: roelleke am 09 Dezember 2018, 10:19:09
Hallo,
Nach dem Update von MQTT2 gestern habe ich das gleiche Problem. Nach einem Restore funktioniert wieder alles.
Bei den betroffenen Devices scheint nichts gepublisht zu werden.
Sie nach jedem Neustart anders aus.
Ich habe zunächst MQTT2 vom Update ausgeschlossen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Beta-User am 09 Dezember 2018, 10:21:15
EDIT:
das mit dem Kommunikationsproblem wurde evtl. gefunden: https://forum.fhem.de/index.php/topic,91394.msg869471.html#msg869471

Rückmeldung zu dem devStateIcon-Thema wäre aber nett...
/EDIT

Hatte gestern auch das Problem, dass sich die zigbee-Lampen nicht mehr schalten ließen. Dachte erst, das würde damit zusammenhängen, dass ich dann noch eine Fernbedienung an die zigbee-Lampen angelernt habe, aber das scheint es nicht gewesen zu sein.
Der Sendebefehl an sich wird gepublisht (sehe ich jedenfalls mit mosquitto_sub), aber der zigbee-Dienst antwortet nicht. Ein Reload des 00_MQTT2_SERVER-Moduls hat mir dann statt 4 8 clients gemeldet, FHEM-Neustart und Neustart des zigbee-Pi haben nichts neues gebracht (aber eingehende Messages, insbes. "online" sehe ich auch in FHEM).

Wirkt auf mich so, als würde MQTT2-Server seine Clients teilweise vergessen und dann nicht mehr alle subsripted clients bedienen. Bei den "alten" MiLight-Definitionen noch ohne CID-Angabe konnte ich schalten, es wurden dann aber von autocreate wieder neue Devices angelegt (mit CID).

Auch ein direktes publish über MQTT2_SERVER klappt nicht, kurzer Auszug aus dem Event-Monitor:

2018-12-09 10:17:04 MQTT2_DEVICE Zigbee_Pi log_type: pairing
 2018-12-09 10:17:04 MQTT2_DEVICE Zigbee_Pi log_message: device incoming
 2018-12-09 10:17:06 MQTT2_SERVER MQTT2_FHEM_Server publish zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON","brightness":60}
 2018-12-09 10:17:30 MQTT2_DEVICE Zigbee_Pi log_message: device incoming
 2018-12-09 10:17:30 MQTT2_DEVICE Zigbee_Pi log_type: pairing
 2018-12-09 10:17:35 MQTT2_SERVER MQTT2_FHEM_Server publish zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"OFF","brightness":60}
(Das Pairing kommt immer, wenn man die Lampen ans Netz hängt, der zigbee-Dienst läuft also.)

Kann mich leider auch im Moment nicht umfassend eindenken oder weiter testen, aber evtl. hilft das ja schon; ansonsten bitte um Rückmeldung, was ich ggf. Mitte nächster Woche liefern soll.

Ich habe jetzt bei allen drei bulbs toggle:on:off hinzugefuegt.
Vorschlag im anderen Thread: Das wieder weg und dafür das devStateIcon? Darüber kann man schalten und sieht auch den Dimmer-Status...
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 09 Dezember 2018, 12:07:39
Zitat
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_MQTT2_DEVICE.pm line 119.
Ich meine das Problem gefixt zu haben, allerdings waere ich sehr dankbar, wenn jemand mir helfen wuerde es zu reproduzieren, da ich keine Ahnung habe, wie das ausgeloest werden kann. Dazu muesste reichen "attr MQTT2_SERVER verbose 5" zu setzen, und ein paar Zeilen vor der Warnung hier anhaengen.

Das von Beta-User verlinkte Fix ist jetzt eingecheckt, ich meine/hoffe dass die da und hier beschriebenen Probleme die gleiche Ursache haben.

Wenn es nach diesem Fix immer noch Probleme gibt, bitte melden, ich meine z.Zt. keine offenen Punkte bezueglich MQTT2 zu haben.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 10 Dezember 2018, 12:54:47
Angefangen hatte es bei mir eigentlich, bei neuen Modulen mit Autocreate seit die Meldungen mit Präfix (woher sie kommen) versehen werden. Plötzlich kamen zum Teil die Power-Meldungen nicht mehr rein.

Ich habe dann wieder sonoffABC:stat/sonoffABC/RESULT:.* { json2nameValue($EVENT) } eingetragen statt mit dem STAT_ Prefix und es ging wieder wie normal.

Ich finde das Präfixen zwar korrekter da klar ist woher ein Status genau kommt aber vorher war halt besser falls es mal zu Problemen kam.

Das heißt wurde bei einem Gerät POWER auf on gesetzt (egal wie, per button, per web, ...) und irgendetwas ging schief, dann war der Status spätestens nach der nächsten Statusmeldung wieder off (die kommen ja alle ca. 5 Minuten bei Tasmota standardmäßig). Da der cmnd selber, aber auch RESULT-Element und STATE den Power Status setzen.

Das war gerade auch eine tolle Sache gegenüber ZWAVE wo keine solch automatischen Statusmeldungen erfolgen. Mitunter eine Heizung dann halt mal anblieb auf ewig weil der off-Befehl nicht durchging und in FHEM dann auf off stand. Bei Tasmota durch die regelmäßigen Stati bereinigt sich das selbst und fhem kann das erkennen und nochmal schalten. Auch wenn Tasmota viel zuverlässiger funktioniert als der ZWAVE Kram.

Aktuell verwende ich bei allen Tasmota-Modulen nur noch:
tele/sonoffxxxOG/LWT:.* LWT
stat/sonoffxxxOG/RESULT:.* { json2nameValue($EVENT) }
tele/sonoffxxxOG/STATE:.* { json2nameValue($EVENT) }
tele/sonoffxxxOG/SENSOR:.* { json2nameValue($EVENT) }

Damit kommen alle Sensoren und es klappt super. Ganz Klasse wäre wenn man das Gerät (sonoffxxxOG) nicht mitgeben müsste sondern dafür einen Platzhalter setzen könnte damit stattdessen, automatisch der Gerätename verwendet wird. Dann könnte man das generell überall fest reinkopieren und müsste das nicht bei jedem neuen Gerät manuell anpassen.

Nochbesser wäre natürlich wenn autocreate das so macht. Autocreate war toll nur mit den Präfixen ist es für mich unpraktisch geworden. Eine Abfrage für einen Temperatursensor irgendwo in eine DOIF muss deswegen auch immer mit SENSOR_ gepräfixed werden...

POWER etc. subscribe ich nicht. Wer braucht das schon? Kommt doch eh über die anderen? eventMap für ON auf on etc. ist etwas lästig, aber ich setze eine angepasst Tasmota-Version ein die on statt ON erwartet und auch zurückgibt. Damit entfällt die eventMap ;-)

Was ich auch mache, ich lege die Geräte nur einmal, also wenn ein Gerät 4 Relays hat und noch einen Temperatursensor dann lege ich mit webCmd etc. Befehle für jeden Kanal fest und ich brauche fhem nicht unnötig mit Geräten vollzublasen die die Sache nur unübersichtlich machen. ein set sonoffxxOG BadOn schaltet mir dann die Heizung im Bad an und ein set sonoffxxOH SchlafOn entsprechend im Schlafzimmer. Ich habe so schon genug Geräte in fhem da brauche ich nicht für jedes Relay extra eines anzulegen und subscribe etc pp nochmal zu definieren.

Von daher fand ich die templates für sonoffs mit 2 Kanälen schon etwas befremdlich ;-)

Ansonsten FHEM ist KLASSE!
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 10 Dezember 2018, 13:08:15
Zitat
Plötzlich kamen zum Teil die Power-Meldungen nicht mehr rein.
Das haette ich gerne mit einem "attr IODEV verbose 5" unterlegt.

Zitat
Das war gerade auch eine tolle Sache gegenüber ZWAVE wo keine solch automatischen Statusmeldungen erfolgen.
Das kann man so generell nicht sagen, die meisten ZWave Geraete melden die Statusaenderung explizit zurueck.
Wenn ein Befehl nicht bestaetigt wurde, steht transmit auf NO_ACK.

Zitat
Ganz Klasse wäre wenn man das Gerät (sonoffxxxOG) nicht mitgeben müsste sondern dafür einen Platzhalter setzen könnte damit stattdessen, automatisch der Gerätename verwendet wird. Dann könnte man das generell überall fest reinkopieren und müsste das nicht bei jedem neuen Gerät manuell anpassen.
Vorschlag: einen eigenen AttrTemplate (FHEM/lib/AttrTemplate/my.template) anlegen.


Zitat
Von daher fand ich die templates für sonoffs mit 2 Kanälen schon etwas befremdlich ;-)
Ein Kombi-Geraet macht die Status-Visualisierung und die Steuerung vom Frontend aus kompliziert, auch Logging/Notify etc ist komplizierter/ungewoehnlicher. Man ist aber nicht gezwungen, es so zu verwenden.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Beta-User am 10 Dezember 2018, 13:51:57
Von daher fand ich die templates für sonoffs mit 2 Kanälen schon etwas befremdlich ;-)
Es spräche doch nichts dagegen, ein template zu bauen, das einen "unified" sonoff mit 2 Kanälen bietet. Da kannst du auch die setList so anpassen, damit es zu den bisherigen Vorgaben paßt.
Zitat
Damit kommen alle Sensoren und es klappt super. Ganz Klasse wäre wenn man das Gerät (sonoffxxxOG) nicht mitgeben müsste sondern dafür einen Platzhalter setzen könnte damit stattdessen, automatisch der Gerätename verwendet wird. Dann könnte man das generell überall fest reinkopieren und müsste das nicht bei jedem neuen Gerät manuell anpassen.
Das ist genau das, was das template tun könnte...
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 10 Dezember 2018, 15:35:57
Das kann man so generell nicht sagen, die meisten ZWave Geraete melden die Statusaenderung explizit zurueck.
Wenn ein Befehl nicht bestaetigt wurde, steht transmit auf NO_ACK.

Ja aber es gibt genug Fälle wo das nichts nützt. Bzw. man müsste das kompliziert abfangen. Wenn nach dem drücken einer Taste in der Weboberfläche ein NO_ACK passiert war glaube ich der Status in der Weboberfläche trotzdem geändert. Umgekehrt wenn ich die Hardware-Taste drücke und der Befehl nicht durchgeht wegen Funkproblemen oder Raspberry wird gerade upgedatet oder FHEM wird upgedatet, ... und der Funkbefehl kommt deswegen in fhem nicht an, dann stimmt der Status in FHEM auch nicht.

Bei Tasmota ist das, wenn STATE auch den POWER setzt kein Problem. Wenn man an die 100 Z-Wave Geräte im Einsatz hatte passiert sowas ab und zu.

Mein 2.4GHz WLAN extra für die Wemos, Sonoffs etc. funktioniert grundsätzlich schonmal viel zuverlässiger als ZWAVE, dazu noch diese "Redundanz" ist schon eine andere Welt.

Vorschlag: einen eigenen AttrTemplate (FHEM/lib/AttrTemplate/my.template) anlegen.

Das ist perfekt!!! Zusammen mit deaktiviertem autocreate ist das ein Traum. Hatte zwar die Templates schon gesehen (sind ja noch recht neu), war mir aber über die Tragweite und dass man das einfach selber über my.template erweitern kann, nicht im klaren ;-)

Ein Kombi-Geraet macht die Status-Visualisierung und die Steuerung vom Frontend aus kompliziert, auch Logging/Notify etc ist komplizierter/ungewoehnlicher. Man ist aber nicht gezwungen, es so zu verwenden.

ungewöhnlich OK, dem Rest kann ich nicht zustimmen ;-)

Das einzig komplizierte ist das stateFormat. Ist vielleicht nichts für den Normaluser. Da ich aktuelle allein 5 Kombigeräte habe mit je 4 Relay, brauche ich so 20 Geräte weniger in FHEM, dazu dann noch die ganzen 2 Port-Geräte und Geräte mit Sensoren... Das läppert sich. Da ist ein zusammengebautes stateFormat echt das kleinere Übel. So habe ich dann auch nur Geräte die es wirklich gibt und muss nicht etliche topics mehrfach subscriben.

Bei einem DOIF sehe ich da auch keinen Unterschied:

([sonoffTestUGGang:SI7021_Temperature:d] >= 19) oder
set sonoffTestUGGang HeizGast statt set sonoffTestUGGangHeizGast on

und per webcmd eingerichtet bei sonoffTestUGGang dann HeizGast HeizBuero ... antippen ist auch nicht schlecht und übersichtlicher mit einem Gerät als mit 4. Mit einem stateFormat mit up/down icon ist das auch gut zu visualisieren.

Nochmal vielen Dank für FHEM.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: netbus am 14 Dezember 2018, 14:18:30
Hi,
ich habe das Problem, dass meine Devices angeblich den Keepalive Check nicht beantworten.
Unter Mosquitto gab es das Problem überhaupt nicht und auch mein WLAN Controller zeigt mir, dass es keine disconnects gab.
Woran kann das liegen?

defmod MQTT2_FHEM_Server MQTT2_SERVER 1883 global
attr MQTT2_FHEM_Server autocreate 1
attr MQTT2_FHEM_Server room MQTT2_DEVICE

2018.12.14 07:15:12.790 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.107_13814/wohnzimmer left us (keepalive check)
2018.12.14 07:15:12.856 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.125_7506/beamer left us (keepalive check)
2018.12.14 07:15:12.899 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.112_17000/kueche left us (keepalive check)
2018.12.14 07:15:12.939 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.111_24667/wc left us (keepalive check)
2018.12.14 07:15:12.979 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.104_3577/werkbank left us (keepalive check)
2018.12.14 07:15:13.019 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.123_10242/DVES_152901 left us (keepalive check)
2018.12.14 07:15:13.060 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.114_30810/vorzimmer left us (keepalive check)
2018.12.14 07:20:10.052 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.116_9662/eg-stiege left us (keepalive check)
2018.12.14 07:20:10.126 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.107_25725/wohnzimmer left us (keepalive check)
2018.12.14 07:20:10.187 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.125_11892/beamer left us (keepalive check)
2018.12.14 07:20:10.227 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.104_4381/werkbank left us (keepalive check)
2018.12.14 07:20:10.266 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.111_9363/wc left us (keepalive check)
2018.12.14 07:20:10.304 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.103_4968/wcheizung left us (keepalive check)
2018.12.14 07:20:10.343 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.123_1610/DVES_152901 left us (keepalive check)
2018.12.14 07:23:06.273 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.107_16300/wohnzimmer left us (keepalive check)
2018.12.14 07:27:06.795 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.112_7633/kueche left us (keepalive check)
2018.12.14 07:27:06.869 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.114_12991/vorzimmer left us (keepalive check)
2018.12.14 07:27:06.925 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.123_30657/DVES_152901 left us (keepalive check)
2018.12.14 07:27:06.964 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.122_10959/eingangstuere left us (keepalive check)
2018.12.14 07:27:07.003 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.110_31536/keller left us (keepalive check)
2018.12.14 07:27:07.052 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.105_17997/terrasse left us (keepalive check)
2018.12.14 07:27:07.090 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.107_9328/wohnzimmer left us (keepalive check)
2018.12.14 07:27:07.137 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.103_27253/wcheizung left us (keepalive check)
2018.12.14 07:27:16.798 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.109_4502/poollicht left us (keepalive check)
2018.12.14 07:27:16.869 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.106_1294/infrarot left us (keepalive check)
2018.12.14 07:27:16.908 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.101_17329/Waschmaschine left us (keepalive check)
2018.12.14 07:27:16.938 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.116_26204/eg-stiege left us (keepalive check)
2018.12.14 07:27:16.975 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.100_24676/stehlampe left us (keepalive check)
2018.12.14 07:27:17.012 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.125_26155/beamer left us (keepalive check)
2018.12.14 07:27:17.050 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.111_29670/wc left us (keepalive check)
2018.12.14 07:27:17.087 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.104_5280/werkbank left us (keepalive check)
2018.12.14 07:31:09.760 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.2.107_24076/wohnzimmer left us (keepalive check)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 14 Dezember 2018, 18:37:26
Zitat
ich habe das Problem, dass meine Devices angeblich den Keepalive Check nicht beantworten.
Das ist so nicht richtig formuliert.
Beim Verbindungsaufbau spezifiziert jedes MQTT Geraet, nach wievielen Sekunden sie ein PINGREQ schickt (keepalive). Die konkreten Zahlen kann man mit "list TYPE=MQTT2_SERVER cid keepalive" anschauen. Wenn nach 1.5-mal den spezifizierten Zeitraum nichts kommt, soll der Server die Verbindung zumachen  (steht so im MQTT Spec). Es gibt ein MQTT2_SERVER Attribut keepaliveFactor: https://fhem.de/commandref_modular.html#keepaliveFactor, um das Verhalten zu modifizieren.
Mit "attr MQTT2_SERVER verbose 5" kann man im Log diese PINGREQ Meldungen sehen, wenn du sicher bist, dass die Geraete die Daten schicken, dann bitte hier ein Log anhaengen.

Zitat
Unter Mosquitto gab es das Problem überhaupt nicht
Das haette ich gerne nachgewiesen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 14 Dezember 2018, 19:06:27
ich habe das Problem, dass meine Devices angeblich den Keepalive Check nicht beantworten.
Unter Mosquitto gab es das Problem überhaupt nicht und auch mein WLAN Controller zeigt mir, dass es keine disconnects gab.
Woran kann das liegen?

Ähnliche Probleme hatte ich letzte Woche mehr oder weniger plötzlich auch. Da meine Heizung davon abhängt bin ich nach einigem rumprobieren zu MQTT2_CLIENT mit mosquitto gewechselt. Danach lief alles sofort wieder stabil. Früher hatte ich MQTT_ mit mosquitto benutzt. Aber auf den Komfort von MQTT2 wollte ich nur ungern verzichten. Zudem war die Migration von MQTT2_SERVER zu MQTT2_CLIENT mit wenig Aufwand möglich. Habe mir im Versionscontrollsystem mal die Änderungen von MQTT2_SERVER angesehen aber keine Idee was das auslöst.

Gefühlt/Zeitlich haben die Probleme mit der Einführung der Präfixe bei mir angefangen. Ich bin mir auch nicht sicher ob es eine Änderung in MQTT2_Server-Code ist oder das Problem mit einer bestimmten Menge an Geräten auftritt. Ich hatte die letzten Tage etliche neu in Betrieb genommen.

Was für Geräte hast du denn im Einsatz? Meines sind alles Geräte mit Tasmota Firmware. Die Meldungen von den Geräten kamen weiter rein, nur die cmnd-Befehle wurden dann nicht mehr ausgeführt.

Wenn es nicht mehr so kalt ist kann ich das mal auf MQTT2_SERVER zurückstellen um die logs zu erzeugen. Mit einer Installation mit nur einer Hand voll Tasmota-Geräten tritt das Problem nicht auf.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: netbus am 16 Dezember 2018, 20:00:13
Hier mal ein Log.

Ich habe keepaliveFactor mit 3 probiert und da hat es sich ein bisschen beruhigt aber Timeouts kamen immer noch.
Was für Geräte hast du denn im Einsatz?
Ich habe Shelly1/2 und Sonoff S20 im Einsatz und alle mit Tasmota Firmware.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 16 Dezember 2018, 20:36:20
Zitat
Hier mal ein Log.
In den 85 Minuten langen log habe ich eine "left us" Meldung gesehen.

Das Geraet wurde von MQTT2_SERVER 15 Sekunden nach dem letzten PINGREQ abgemeldet. Vorher kamen die PINGREQs alle 10 Sekunden, ich gehe also von einem per CONNECT bestellten keepalive von 10s aus. Da ich keine CONNECT Zeile gesehen habe, und mir auch die Ausgabe von "list TYPE=MQTT2_SERVER cid keepalive" nicht vorliegt, bin ich dabei nicht ganz sicher. Wenn meine Vermutung stimmt, dann ist das Verhalten von MQTT2_SERVER korrekt.

Ein keepalive von 10s schreit nach Problem, insb wenn, wie hier, 17 Geraete mit einem aehnlichen keepalive angebunden sind.
Ich wuerde ein keepalive von 60 oder 120 Sekunden favorisieren.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: netbus am 16 Dezember 2018, 21:44:01
da gebe ich dir recht, dass 10 Sekunden zu kurz sind aber ich weiß leider nicht wie ich das in Tasmota ändern kann.

keepalive       60
                 cid             stehlampe
 keepalive       15
                  cid             Waschmaschine
 keepalive       15
                  cid             wcheizung
 keepalive       15
                  cid             werkbank
 keepalive       15
                  cid             terrasse
 keepalive       15
                 cid             infrarot
 keepalive       15
                  cid             wohnzimmer
 keepalive       10
                  cid             poollicht
 keepalive       15
                  cid             keller
 keepalive       10
                  cid             wc
 keepalive       10
                  cid             kueche
 keepalive       10
                  cid             vorzimmer
 keepalive       10
                  cid             eg-stiege
 keepalive       10
                  cid             eingangstuere
 keepalive       15
                 cid             lounge
 keepalive       15
                  cid             beamer
 keepalive       15
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 16 Dezember 2018, 22:25:57
Das mit den 10 Sekunden kann ich bestätigen. Mit mehr Geräten geht dann MQTT2_SERVER in die Knie? Habe hier so um die 50 aktuell aktiv. So bis zur Hälfte hatte ich wohl keine Probleme. Zumindest waren Sie nicht besonders offensichtlich. Also wohl eher ein Mengen Problem als irgendwelche Änderungen im Code? Mit MQTT2_CLIENT und mosquitto habe ich keine Probleme.

Die besagte Einstellung bei Tasmota ließe sich ändern:

MqttRetry      Show current MQTT connection retry timer in seconds
MqttRetry   10   (default) Set MQTT connection retry timer in seconds
MqttRetry   10..32000   Set MQTT connection retry timer in seconds

Befehl um das per publish zu ändern wäre:

cmnd/<topic>/MqttRetry 60

um es auf 60 Sekunden zu erhöhen. MqttRetry kann, wie immer bei Tasmota, groß/klein sonstwie geschrieben werden.

Wäre kein Problem das ins Template mit auf zu nehmen. Ist das denn bei anderen mqtt Geräten standardmäßig wirklich höher? Die Last bei WLAN für ein keepalive ist ja nicht wirklich groß.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 16 Dezember 2018, 23:10:01
Zitat
Mit mehr Geräten geht dann MQTT2_SERVER in die Knie?
Das waere noch nachzuweisen, ich glaube nicht daran.
Eher daran, dass mosquitto diesen Parameter ignoriert, oder anders auswertet.

Zitat
Die Last bei WLAN für ein keepalive ist ja nicht wirklich groß.
Mag sein, aber wenn jede Sekunde 5 Geraete was senden, kann zu Problemen kommen. Wobei ich eher an Probleme in der Tasmota Firmware/TCP Implementierung denke, und nicht an FHEM, der den Linux TCP Stack verwendet.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: netbus am 17 Dezember 2018, 13:56:48
Die besagte Einstellung bei Tasmota ließe sich ändern:

MqttRetry      Show current MQTT connection retry timer in seconds
MqttRetry   10   (default) Set MQTT connection retry timer in seconds
MqttRetry   10..32000   Set MQTT connection retry timer in seconds
Habe ich geändert doch der Server schickt noch immer alle 10 Sekunden einen Request. Auch die cid keepalive Werte sind unverändert.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 17 Dezember 2018, 21:10:35
Habe da nur die Tasmota-Wiki mal durchstöbert. Weitere Parameter als den mqttretry habe ich nicht gefunden.

Was ist denn so bei anderen mqtt-Geräten üblich?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: binford6000 am 20 Dezember 2018, 15:25:19
Hallo Zusammen,
bin mir nicht sicher ob es seit dem letzten oder vorletzten Update so ist:
Bei meinen zwei MQTT2_DEVICEs fehlt die DEVICEOVERVIEW und der STATE bleibt leer.

Hier mal ein List eines der Devices:
Internals:
   CID        Schreibtischlampe_0E3428
   DEF        Schreibtischlampe_0E3428
   DEVICETOPIC bu_schreibtisch_licht
   IODev      mqtt2_server
   LASTInputDev mqtt2_server
   MSGCNT     5
   NAME       bu_schreibtisch_licht
   NR         362
   STATE     
   TYPE       MQTT2_DEVICE
   mqtt2_server_MSGCNT 5
   mqtt2_server_TIME 2018-12-20 14:51:25
   OLDREADINGS:
   READINGS:
     2018-12-20 14:51:25   POWER           ON
     2018-12-20 14:51:25   power           on
     2018-12-20 14:51:25   state           on
Attributes:
   IODev      mqtt2_server
   alexaName  Schreibtisch
   alexaRoom  Büro
   autocreate 0
   building   wohnung_lichter
   devStateIcon on:light_light_dim_100@red off:light_light_dim_00
   event-on-change-reading .*
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   genericDeviceType light
   group      Licht
   icon       light_office_desk
   model      A_01a_tasmota_basic_state_power1
   readingList tele/Schreibtischlampe_0E3428/LWT:.* LWT
  tele/Schreibtischlampe_0E3428/STATE:.* { json2nameValue($EVENT) }
  tele/Schreibtischlampe_0E3428/SENSOR:.* { json2nameValue($EVENT) }
  tele/Schreibtischlampe_0E3428/INFO.:.* { json2nameValue($EVENT) }
  stat/Schreibtischlampe_0E3428/RESULT:.* { json2nameValue($EVENT) }
   room       02_Tablet,20_Licht,Alexa,Homekit
   room_map   power
   setList    off:noArg    cmnd/Schreibtischlampe_0E3428/POWER1 0
  on:noArg     cmnd/Schreibtischlampe_0E3428/POWER1 1
  toggle:noArg cmnd/Schreibtischlampe_0E3428/POWER1 2
  mqttRetry   cmnd/Schreibtischlampe_0E3428/MqttRetry
   stateFormat {lc ReadingsVal("$name","POWER1","") }
   userReadings power {lc(ReadingsVal("bu_schreibtisch_licht","state",""));;}
   userattr   building building_map lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 room_map structexclude subscribeReading_state
   webCmd     on:off:toggle

Bug oder Feature?
VG Sebastian

Version:
10_MQTT2_DEVICE.pm    18005 2018-12-19 20:51:59Z rudolfkoenig
00_MQTT2_SERVER.pm    17953 2018-12-11 14:44:34Z rudolfkoenig
AttrTemplate.pm       17973 2018-12-14 18:19:05Z rudolfkoenig
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 20 Dezember 2018, 16:20:33
Laut stateFormat soll POWER1 angezeigt werden, du hast aber "nur" ein POWER Reading.
Ich meine nicht, dass ein FHEM-Update das Problem verursacht.
Es gab kuerzlich hier eine Diskussion, dass bei Tasmota konfigurieren kann, ob der erste Schalter sich als POWER oder POWER1 zurueckmeldet.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 20 Dezember 2018, 18:46:49
Hallo Zusammen,
bin mir nicht sicher ob es seit dem letzten oder vorletzten Update so ist:
Bei meinen zwei MQTT2_DEVICEs fehlt die DEVICEOVERVIEW und der STATE bleibt leer.

du musst das Template tasmota basic power verwenden nicht power1. Du hast ein Gerät mit einem Relay, da liefert Tasmota standardmäßig POWER nicht POWER1.

Also das Problem ist nicht das Update sondern dass du das falsche Template ausgewählt hast für dein Gerät.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: binford6000 am 20 Dezember 2018, 21:41:54
du musst das Template tasmota basic power verwenden nicht power1. Du hast ein Gerät mit einem Relay, da liefert Tasmota standardmäßig POWER nicht POWER1.

Also das Problem ist nicht das Update sondern dass du das falsche Template ausgewählt hast für dein Gerät.

OK Danke, STATE ist wieder da mit dem richtigen Template "A_01_tasmota_basic".
Aber wo ist die Device Overview hin?
VG Sebastian
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 21 Dezember 2018, 12:13:06
OK Danke, STATE ist wieder da mit dem richtigen Template "A_01_tasmota_basic".
Aber wo ist die Device Overview hin?
VG Sebastian

seit gestern habe ich das Problem mit fehlendem DeviceOverview auch. In einer 2. Installation komischerweise erst seit heute. Beide wurden gestern und heute upgedatet.

Das Problem besteht bei mir bei allen MQTT2-DEVICE Geräten. In einer Installation über MQTT2-CLIENT (da war das Problem schon gestern) und in einer über MQTT2-SERVER (da ist das Problem erst seit heute)

Bei keinem habe ich seither ein template zugewiesen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 21 Dezember 2018, 12:35:19
Was ist ein "Device Overview"?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 21 Dezember 2018, 12:57:17
Was ist ein "Device Overview"?

in der Nachricht vorher war ein Screenshot ohne und hier jetzt noch einer mit deviceoverview. Hier von einem ZWave-Gerät bei dem das noch kommt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: binford6000 am 21 Dezember 2018, 12:57:43
Was ist ein "Device Overview"?
Quasi die Ansicht eines devices innerhalb eines Raums. Siehe Screenshots.
Bei allen MQTT2_DEVICEs fehlt dies (nun).

VG Sebastian
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 21 Dezember 2018, 14:13:23
Danke fuer den Hinweis, habs jetzt wieder eingebaut.
Kam mit dem "Show Neighbor Map" Patch rein.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: mark79 am 22 Dezember 2018, 11:46:43
Zur Klarstellung: das ist kein direktes Problem in den hier behandelten MQTT2* Modulen, es entsteht, wenn FHEM mit sich selbst ueber das MQTT Protokoll unterhaelt.

Das Problem habe ich nun auch. Über Nacht ist mein Fhem abgeschmiert und wenn ich es starte, schmiert er mit genau dieser Fehlermeldung ab.
Also im Log ist es das letzte was dort auftaucht.

decode_string: insufficient data at /usr/local/share/perl/5.24.1/Net/MQTT/Message/Publish.pm line 36.

Ich habe jetzt schon die neuen MQTT devices aus der fhem.cfg per Hand gelöscht, aber trotzdem startet es nicht.
Auch habe ich die Fhem Module auf den neusten Stand geupdaet.

Hat jemand eine Idee, wie ich den Fehler behoben bekomme?

EDIT: wenn ich den Ordner /usr/local/share/perl/5.24.1/Net/MQTT/ umbenenne, dann startet Fhem korrekt. Nur dann werden die MQTT Module nicht mehr geladen:
configfile: Cannot load module MQTT
Cannot load module MQTT_DEVICE
...
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 22 Dezember 2018, 12:50:45
Zitat
Ich habe jetzt schon die neuen MQTT devices aus der fhem.cfg per Hand gelöscht, aber trotzdem startet es nicht.
...
EDIT: wenn ich den Ordner /usr/local/share/perl/5.24.1/Net/MQTT/ umbenenne, dann startet Fhem korrekt. Nur dann werden die MQTT Module nicht mehr geladen:
Ich sehe da einen gewissen Widerspruch.

Ich meine, das ist kein MQTT2 Problem, und sollte dem MQTT Maintainer gemeldet werden, sinnvollerweise mit einem passenden Betreff.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: mark79 am 22 Dezember 2018, 13:38:59
Ich sehe da einen gewissen Widerspruch.

Ich meine, das ist kein MQTT2 Problem, und sollte dem MQTT Maintainer gemeldet werden, sinnvollerweise mit einem passenden Betreff.

Ich wusste erst nicht, welches Modul schuld daran ist und da die Fehlermeldung hier schon mal aufgetaucht ist, habe ich es hier rein gepackt.

Ich glaube ich stell dann mal auf mqtt2_client um. Hast du ein Tipp, wie ich alle Geräte migrieren kann?
Würde es nicht gehen, wenn man die vorhandenen einfach in MQTT2_CLIENT umschreibt?

### WZ_TV ###
define WZ_TV_Sonoff MQTT_DEVICE
attr WZ_TV_Sonoff DbLogExclude .*
attr WZ_TV_Sonoff IODev myBroker
attr WZ_TV_Sonoff devStateIcon ON:FS20.on OFF:FS20.off
attr WZ_TV_Sonoff icon ge_wht_steckdose
attr WZ_TV_Sonoff publishSet ON OFF cmnd/4ch/POWER1
attr WZ_TV_Sonoff room Geräte
attr WZ_TV_Sonoff stateFormat state
attr WZ_TV_Sonoff subscribeReading_state stat/4ch/POWER1
attr WZ_TV_Sonoff webCmd ON:OFF
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 22 Dezember 2018, 14:08:17
Zitat
Würde es nicht gehen, wenn man die vorhandenen einfach in MQTT2_CLIENT umschreibt?
Die beiden Module unterstuetzen unterschiedliche Attribtue, z.Bsp. muss publishSet nach setList und subscribeReading_state nach readingList und stateFormat gewandelt werden. Da du einen externen MQTT-Server verwendest, ist autocreate begrenzt.

Ich wuerde erst eine Instanz ueber FHEMWEB komplett konvertieren und testen, und danach die anderen in fhem.cfg mit einem Editor umbauen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: osr am 22 Dezember 2018, 14:30:38
Die beiden Module unterstuetzen unterschiedliche Attribtue, z.Bsp. muss publishSet nach setList und subscribeReading_state nach readingList und stateFormat gewandelt werden. Da du einen externen MQTT-Server verwendest, ist autocreate begrenzt.

Ich wuerde erst eine Instanz ueber FHEMWEB komplett konvertieren und testen, und danach die anderen in fhem.cfg mit einem Editor umbauen.

Ja es geht definitiv nicht ohne einige Handarbeit. Ich habe das so gemacht, dass ich MQTT2_Server auf einem anderen Port installiert habe und bei einem Tasmota-Gerät den Port ebenfalls abgeändert habe. Dann habe ich mich mit der unterschiedlichen Handhabung vertraut gemacht. Danach habe ich mosquitto deaktiviert, den Port vom MQTT2_Server umgestellt, so dass sich die Geräte mit dem MQTT2_Server verbinden. Durch autocreate wurden die Geräte dann angelegt. Ich habe dann die Einstellungen vom alten MQTT Gerät in das neu angelegt MQTT2_DEVICE übernommen und doifs angepasst, dann das alte Gerät gelöscht. Zum Glück hatte ich da noch nicht so viele Geräte online.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: mark79 am 22 Dezember 2018, 17:19:02
Danke euch erstmal für die Tipps, aber ich habe das Problem nun doch gefunden und kann den Umzug noch etwas verschieben. :)

Schuld war meine eigene Schussligkeit...  ::) ich hatte vor ein paar Tagen versucht, ein mqtt bridge zur amazon aws cloud herstzustellen und da habe ich wohl den falschen lxc Container mit Fhem erwischt und in das reguläre mosquitto server Verzeichniss die bridge.conf mit reinkopiert.
Dann hat wohl der systemctl den mosquitto Dienst anscheinend über Nacht neu geladen und ihn dadurch stillgelegt.

Das ist mir vorhin aufgefallen, da ich mit mosquitto_sub auch nicht mehr auf meinen mosquitto Server drauf kam.

Ich habe die bridge.conf nun gelöscht und jetzt ist der Fhem Fehler auch verschwunden.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Omega am 24 Dezember 2018, 10:05:53
Ich habe einen CC2531-Router, der aber momentan nicht im Einsatz ist (disabled per attr).
Bei jedem shutdown restart (die mache ich aktuell häufig   :) ) bekomme ich in diesem Device 2 - bereits vorhandene - Readings spendiert und das Änderungsflag wird gesetzt.

Das Device:
define mq2.cc2531.Router MQTT2_DEVICE zigbee_0x00124b0018ed2581
attr mq2.cc2531.Router IODev MQTT2_FHEM_Server
attr mq2.cc2531.Router disable 1
attr mq2.cc2531.Router readingList zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }\
zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr mq2.cc2531.Router room MQTT

setstate mq2.cc2531.Router false
setstate mq2.cc2531.Router 2018-12-24 09:47:00 associatedWith MQTT2_zigbee_pi
setstate mq2.cc2531.Router 2018-12-18 11:59:37 linkquality 55
setstate mq2.cc2531.Router 2018-12-18 11:59:37 state false

Auszug aus dem Log:
2018.12.24 09:46:47 3 : CUL_HM set Az.Jalousie_rechts statusRequest
2018-12-24 09:46:47 Global global ATTR mq2.cc2531.Router readingList zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }
2018.12.24 09:46:49 3 : CUL_HM set Kueche.Jalousie statusRequest
...
2018.12.24 09:47:00 3 : CUL_HM set RM_Kellerflur_Heizung statusRequest
2018-12-24 09:47:00 Global global ATTR mq2.cc2531.Router readingList zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '') } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) } zigbee2mqtt/0x00124b0018ed2581:.* { json2nameValue($EVENT, '', $JSONMAP) }

Das ist jetzt bestimmt nicht wichtig - nur irgendwo scheint im Ablauf etwas nicht zu passen.

LG
Holger
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: john30 am 26 Dezember 2018, 11:37:46
Ich hätte einen change request für FHEM/10_MQTT2_DEVICE.pm (rev 18056) Zeile 171, um auch JSON erkennen zu können, in welchem Zeilenumbrüche zwischen Elementen enthalten ist.
Dazu müsste die o.g. Zeile m.E. von
if($value =~ m/^{.*}$/) {auf
if($value =~ m/^{.*}$/s) {geändert werden.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 26 Dezember 2018, 12:06:53
Danke fuer den Hinweis, habs eingebaut.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: john30 am 26 Dezember 2018, 12:16:11
Danke fuer den Hinweis, habs eingebaut.
Gerne & Danke :)
Titel: MQTT2 und Owntrack
Beitrag von: m0urs am 29 Januar 2019, 08:13:17
Ich habe gerade mal versucht, Owntracks für iOS (https://owntracks.org/) mit MQTT2 Server zu verbinden. Beim Verbindungsaufbau kommt folgende Fehlermeldung in FHEM:

2019.01.29 08:03:28 4: Connection accepted from MQTT2_192.168.1.36_64508
2019.01.29 08:03:28 5: CONNECT: (0)(6)MQIsdp(3)(204)(0)<(0)(14)mqtttestdevice(0)(25)owntracks/mqtt/testdevice(0)"{"tst":"1548745369","_type":"lwt"}(0)(4)mqtt_user(0)(20)mqtt_password
2019.01.29 08:03:28 2: MQTT2_192.168.1.36_64508 wants unclean session, disconnecting
In der App erscheint die folgende Meldung:

MQTT CONNACK: unacceptable protocol version { NSLocalizedDescription = "MQTT CONNACK: unacceptable protocol version";
Ich habe Protokoll-Version 3 und 4 in der App ausprobiert.

Kann mir bitte jemand auf die Sprünge helfen? Danke!


Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Mitch am 29 Januar 2019, 15:03:32
mit heutigem Update kommt folgende Fehlermeldung:
ERROR: >< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 30 Januar 2019, 21:20:16
@Mitch: kannst du bitte ein "attr global verbose 5" Log hinzufuegen, oder einen Weg nennen, wie ich das nachstellen kann?

@m0urs: Ich will kein "unclean sesssion" unterstuetzen. Aber nachdem ich die RFC nochmal genauer gelesen habe, meine ich, dass man das nicht als Fehler meldet, sondern als "ich habe kein Session, aber connect ist OK". Habe das Modul geaendert (morgen ab 8 per update verfuegbar), bitte um Feedback.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Mitch am 30 Januar 2019, 21:28:23
@Mitch: kannst du bitte ein "attr global verbose 5" Log hinzufuegen, oder einen Weg nennen, wie ich das nachstellen kann?

Hier mal ein Ausschnitt des Fehlers:
2019.01.30 21:26:28 1: ERROR: >< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer
2019.01.30 21:26:28 5: End notify loop for MQTT2_DVES_E895AC
2019.01.30 21:26:28 5: End notify loop for Verbrauch
2019.01.30 21:26:28 5: Starting notify loop for Verbrauch, 1 event(s), first is MQTT2_DVES_E895AC.SENSOR_ENERGY_Power: <html><div style="width:500px; text-align:center; border: 1px solid #ccc; background:-webkit-linear-gradient(left, red 0%, rgba(0,0,0,0) 0%)">0 Watt</div></html>
2019.01.30 21:26:28 5: Starting notify loop for MQTT2_DVES_E895AC, 3 event(s), first is SENSOR_Time: 2019-01-30T21:26:29
2019.01.30 21:26:28 1: ERROR: >< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer
2019.01.30 21:26:28 5: End notify loop for MQTT2_DVES_E895AC
2019.01.30 21:26:28 5: createNotifyHash
2019.01.30 21:26:28 5: Starting notify loop for MQTT2_DVES_E895AC, 4 event(s), first is STATE_Wifi_RSSI: 86
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 30 Januar 2019, 22:48:00
Danke, habs gefixt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Mitch am 31 Januar 2019, 09:49:02
Sieht gut aus, vielen Dank Rudi!
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: m0urs am 05 Februar 2019, 06:55:43
@m0urs: Ich will kein "unclean sesssion" unterstuetzen. Aber nachdem ich die RFC nochmal genauer gelesen habe, meine ich, dass man das nicht als Fehler meldet, sondern als "ich habe kein Session, aber connect ist OK". Habe das Modul geaendert (morgen ab 8 per update verfuegbar), bitte um Feedback.

Ganz vielen Dank! Mit der neuen Version funktioniert der Connect von Owntracks, es wurde ein Device erzeugt und Readings aktualisiert. Damit komme ich sicher erst einmal weiter. Ggf. melde ich mich wieder ;-)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: OppiM am 07 Februar 2019, 08:20:00
Hi,

ich hab in letzter Zeit vermehrt komplette Abstürze von FHEM. Die letzten Eintrage im Log sehen in der Regel so aus:

2019.02.07 07:23:02.178 1: PERL WARNING: Wide character in print at ./FHEM/92_FileLog.pm line 214.
2019.02.07 07:23:02.178 1: stacktrace:
2019.02.07 07:23:02.178 1:     main::__ANON__                      called by ./FHEM/92_FileLog.pm (214)
2019.02.07 07:23:02.178 1:     main::FileLog_Log                   called by fhem.pl (3684)
2019.02.07 07:23:02.178 1:     main::CallFn                        called by fhem.pl (3604)
2019.02.07 07:23:02.178 1:     main::DoTrigger                     called by fhem.pl (3970)
2019.02.07 07:23:02.178 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_SERVER.pm (431)
2019.02.07 07:23:02.178 1:     main::MQTT2_SERVER_doPublish        called by ./FHEM/00_MQTT2_SERVER.pm (327)
2019.02.07 07:23:02.178 1:     main::MQTT2_SERVER_Read             called by fhem.pl (3684)
2019.02.07 07:23:02.178 1:     main::CallFn                        called by fhem.pl (737)
Wide character in syswrite at FHEM/TcpServerUtils.pm line 296.

Ich hab dann mal VERBOSE 5 für das MQTT2_SERVER Device gesetzt, die letzten Einträge sahen dann so aus (komischerweise wurde dann der Stacktrace nicht mehr ausgegeben?!):

2019.02.07 07:16:55.762 5: PUBLISH: 0(234)(1)(0)(21)/Tasmota_1/tele/STATE{"Time":"2019-02-07T07:16:56","Uptime":"20T11:29:22","Vcc":3.423,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"on","Wifi":{"AP":1,"SSId":"xxx","BSSId":"xxx","Channel":1,"RSSI":7
2019.02.07 07:16:55.762 4: m2s_192.168.xx.xx_52234 Tasmota_1 PUBLISH /Tasmota_1/tele/STATE:{"Time":"2019-02-07T07:16:56","Uptime":"20T11:29:22","Vcc":3.423,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"on","Wifi":{"AP":1,"SSId":"xxx","BSSId":"xxx","Channel":1,"RSSI":76}}
2019.02.07 07:16:55.763 5: m2s: dispatch autocreate\000Tasmota_1\000/Tasmota_1/tele/STATE\000{"Time":"2019-02-07T07:16:56","Uptime":"20T11:29:22","Vcc":3.423,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"on","Wifi":{"AP":1,"SSId":"xxx","BSSId":"xxx","Channel":1,"RSSI":76}}
Wide character in syswrite at FHEM/TcpServerUtils.pm line 296.

Das die erste Zeile abgeschnitten ist ist kein Copy/Paste-Fehler, so steht es im Log.

Was kann ich tun, um die Fehlerquelle noch mehr einzugrenzen?

Gruß,
Michael
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 08 Februar 2019, 12:44:56
Zitat
komischerweise wurde dann der Stacktrace nicht mehr ausgegeben?!
Dein Stacktrace gehoert zu FileLog, weil im ersten Fall noch was zu loggen war, im zweiten Fall aber nicht mehr.
Der Absturz ist anderswo (TcpServerUtils, vmtl.), und das wurde nicht abgefangen.

Das habe ich jetzt geaendert, im Problemfall wird der Text ausgegeben, und ein stacktrace generiert.
Die abgeschnittene Debug-Zeile habe ich auch gefixt.

Da ich keine Idee habe, woran das Problem liegt (ich vermute die Ursache nicht in MQTT2_SERVER, auch wenn der Stacktrace das suggeriert), schlage ich vor mit dem aktualisierten Version (ab morgen um 8 per FHEM-update) einen neuen Versuch zu starten, und die Fehlermeldung hier zu zeigen.




Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: OppiM am 16 Februar 2019, 09:44:23
Hi,

ich hatte jetzt wieder zwei Abstürze, diesmal allerdings mit anderem Fehler.


2019.02.15 22:50:03.446 5: PUBLISH: 0(135)(1)(0) /OpenMQTTGateway/OMG_3/SYStoMQTT{"uptime":24480,"freeMem":85444,"rssi":-74,"SSID":"Oppenheimer","IP":"192.168.18.223","modules":"BT"}
2019.02.15 22:50:03.446 4: m2s_192.168.18.223_64348 OMG_3 PUBLISH /OpenMQTTGateway/OMG_3/SYStoMQTT:{"uptime":24480,"freeMem":85444,"rssi":-74,"SSID":"Oppenheimer","IP":"192.168.18.223","modules":"BT"}
2019.02.15 22:50:03.447 5: m2s: dispatch autocreate\000OMG_3\000/OpenMQTTGateway/OMG_3/SYStoMQTT\000{"uptime":24480,"freeMem":85444,"rssi":-74,"SSID":"Oppenheimer","IP":"192.168.18.223","modules":"BT"}
2019.02.15 22:50:03.593 5: PUBLISH: 0k(0)$/OpenMQTTGateway/home_presence/OMG_6{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737}
2019.02.15 22:50:03.593 4: m2s_192.168.18.129_54398 OMG_6 PUBLISH /OpenMQTTGateway/home_presence/OMG_6:{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737}
2019.02.15 22:50:03.594 5: m2s: dispatch autocreate\000OMG_6\000/OpenMQTTGateway/home_presence/OMG_6\000{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737}
2019.02.15 22:50:03.914 5: PUBLISH: 0(217)(1)(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737,"servicedata":"712098008ce7ac668d7cc40d0910020000","servicedatauuid":"0000fe95-00
00-1000-8000-00805f9b34fb"}
2019.02.15 22:50:03.914 4: m2s_192.168.18.129_54398 OMG_6 PUBLISH /OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7:{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737,"servicedata":"712098008ce7ac668d7cc40d0910020000","servicedata
uuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.15 22:50:03.915 5: m2s: dispatch autocreate\000OMG_6\000/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7\000{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737,"servicedata":"712098008ce7ac668d7cc40d0910020000","servicedat
auuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.15 22:50:03.922 5: PUBLISH: 003(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"fer":
2019.02.15 22:50:03.922 4: m2s_192.168.18.129_54398 OMG_6 PUBLISH &/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"fer"::
2019.02.15 22:50:03.923 5: m2s: dispatch autocreate\000OMG_6\000&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"fer"_\000
2019.02.15 22:50:03.927 5: CONNACK: "0"}freeMem":82852,"rssi":-49,"SSID":"Oppenheimer"
2019.02.15 22:50:03.927 1: ERROR: Unhandled packet CONNACK, disconneting m2s_192.168.18.129_54398
2019.02.15 22:50:03.993 5: m2s: dispatch autocreate\000OMG_6\000/OpenMQTTGateway/OMG_6/LWT\000Offline
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/^OMG_6:&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{ <-- HERE "fer"_:.*$/ at ./FHEM/10_MQTT2_DEVICE.pm line 104.

2019.02.16 06:20:28.712 5: PUBLISH: 0(127)(0)$/OpenMQTTGateway/home_presence/OMG_3{"id":"c4:7c:8d:66:b3:49","name":"Flower care","rssi_OMG_3":-78,"distance_OMG_3":7.85288}
2019.02.16 06:20:28.712 4: m2s_192.168.18.223_64463 OMG_3 PUBLISH /OpenMQTTGateway/home_presence/OMG_3:{"id":"c4:7c:8d:66:b3:49","name":"Flower care","rssi_OMG_3":-78,"distance_OMG_3":7.85288}
2019.02.16 06:20:28.712 5: m2s: dispatch autocreate\000OMG_3\000/OpenMQTTGateway/home_presence/OMG_3\000{"id":"c4:7c:8d:66:b3:49","name":"Flower care","rssi_OMG_3":-78,"distance_OMG_3":7.85288}
2019.02.16 06:20:28.844 5: PUBLISH: 0(135)(1)(0) /OpenMQTTGateway/OMG_6/SYStoMQTT{"uptime":50904,"freeMem":84516,"rssi":-79,"SSID":"Oppenheimer","IP":"192.168.18.129","modules":"BT"}
2019.02.16 06:20:28.844 4: m2s_192.168.18.129_61607 OMG_6 PUBLISH /OpenMQTTGateway/OMG_6/SYStoMQTT:{"uptime":50904,"freeMem":84516,"rssi":-79,"SSID":"Oppenheimer","IP":"192.168.18.129","modules":"BT"}
2019.02.16 06:20:28.845 5: m2s: dispatch autocreate\000OMG_6\000/OpenMQTTGateway/OMG_6/SYStoMQTT\000{"uptime":50904,"freeMem":84516,"rssi":-79,"SSID":"Oppenheimer","IP":"192.168.18.129","modules":"BT"}
2019.02.16 06:20:28.923 5: PUBLISH: 0(237)(1)(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D66B349{"id":"c4:7c:8d:66:b3:49","name":"Flower care","rssi_OMG_3":-78,"distance_OMG_3":7.85288,"servicedata":"71209800e049b3668d7cc40d0910027b00","servicedatauuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.16 06:20:28.923 4: m2s_192.168.18.223_64463 OMG_3 PUBLISH /OpenMQTTGateway/BTtoMQTT/C47C8D66B349:{"id":"c4:7c:8d:66:b3:49","name":"Flower care","rssi_OMG_3":-78,"distance_OMG_3":7.85288,"servicedata":"71209800e049b3668d7cc40d0910027b00","servicedatauuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.16 06:20:28.924 5: m2s: dispatch autocreate\000OMG_3\000/OpenMQTTGateway/BTtoMQTT/C47C8D66B349\000{"id":"c4:7c:8d:66:b3:49","name":"Flower care","rssi_OMG_3":-78,"distance_OMG_3":7.85288,"servicedata":"71209800e049b3668d7cc40d0910027b00","servicedatauuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.16 06:20:28.930 5: PUBLISH: 005(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D66B349{"fer":
2019.02.16 06:20:28.930 4: m2s_192.168.18.223_64463 OMG_3 PUBLISH &/OpenMQTTGateway/BTtoMQTT/C47C8D66B349{"fer"::
2019.02.16 06:20:28.930 5: m2s: dispatch autocreate\000OMG_3\000&/OpenMQTTGateway/BTtoMQTT/C47C8D66B349{"fer"_\000
2019.02.16 06:20:28.932 5: CONNACK: "123"}eeMem":81140,"rssi":-75,"SSID":"Oppenheimer",
2019.02.16 06:20:28.932 1: ERROR: Unhandled packet CONNACK, disconneting m2s_192.168.18.223_64463
2019.02.16 06:20:28.939 5: m2s: dispatch autocreate\000OMG_3\000/OpenMQTTGateway/OMG_3/LWT\000Offline
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/^OMG_3:&/OpenMQTTGateway/BTtoMQTT/C47C8D66B349{ <-- HERE "fer"_:.*$/ at ./FHEM/10_MQTT2_DEVICE.pm line 104.

So sieht eine "normaler" Empfang aus (gleicher Sensor wie beim 1. Absturz).

2019.02.15 22:46:47.444 5: PUBLISH: 0k(0)$/OpenMQTTGateway/home_presence/OMG_6{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737}
2019.02.15 22:46:47.444 4: m2s_192.168.18.129_54398 OMG_6 PUBLISH /OpenMQTTGateway/home_presence/OMG_6:{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737}
2019.02.15 22:46:47.444 5: m2s: dispatch autocreate\000OMG_6\000/OpenMQTTGateway/home_presence/OMG_6\000{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737}
2019.02.15 22:46:47.541 5: PUBLISH: 0(217)(1)(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737,"servicedata":"7120980078e7ac668d7cc40d0910020000","servicedatauuid":"0000fe95-00
00-1000-8000-00805f9b34fb"}
2019.02.15 22:46:47.541 4: m2s_192.168.18.129_54398 OMG_6 PUBLISH /OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7:{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737,"servicedata":"7120980078e7ac668d7cc40d0910020000","servicedata
uuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.15 22:46:47.542 5: m2s: dispatch autocreate\000OMG_6\000/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7\000{"id":"c4:7c:8d:66:ac:e7","rssi_OMG_6":-75,"distance_OMG_6":5.832737,"servicedata":"7120980078e7ac668d7cc40d0910020000","servicedat
auuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.15 22:46:47.545 5: PUBLISH: 03(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"fer":"0"}
2019.02.15 22:46:47.545 4: m2s_192.168.18.129_54398 OMG_6 PUBLISH /OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7:{"fer":"0"}
2019.02.15 22:46:47.545 5: m2s: dispatch autocreate\000OMG_6\000/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7\000{"fer":"0"}

Gruß,
Michael
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 16 Februar 2019, 11:33:54
- die Meldung sagt es eigentlich: dieser Regexp ist falsch, man muss es korrigieren.
- wurde der regexp per autocreate angelegt? Wenn ja, bitte das passende Topic/Message hier anhaengen
- perl 5.18 hat das Problem nicht, perl 5.28 meldet eine Warnung, die ich aber nicht abfangen kann(??), einen Absturz sehe ich nicht. Welche Perl Version verwendest Du?
- ich habe fuer readingsList eine Regexp-Pruefung eingebaut, damit man sowas beim Setzen der Attribute sieht: kannst du bitte pruefen, ob es hilft?
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: OppiM am 16 Februar 2019, 16:05:33
Hi,

hier ein List des Device:
Internals:
   CHANGED   
   CID        FlowerCare_C47C8D66ACE7
   DEF        FlowerCare_C47C8D66ACE7
   DEVICETOPIC Xiaomi_FlowerCare_3
   FUUID      5c447c92-f33f-7215-12f6-6a4c60ed59c904e8
   IODev      m2s
   LASTInputDev m2s
   MSGCNT     1814
   NAME       Xiaomi_FlowerCare_3
   NR         644
   STATE      T: 21.9°C - M: 0% - L: 35 - F: 0
   TYPE       MQTT2_DEVICE
   m2s_MSGCNT 1814
   m2s_TIME   2019-02-16 15:37:27
   Helper:
     DBLOG:
       Lux:
         logdb:
           TIME       1550327588.94835
           VALUE      35
       Temperature:
         logdb:
           TIME       1550327813.84116
           VALUE      21.9
   OLDREADINGS:
     2019-02-16 15:36:53   LastMessage     Sat Feb 16 15:36:53 2019
   READINGS:
     2019-02-16 15:37:27   Fertility       0
     2019-02-16 15:37:27   LastMessage     Sat Feb 16 15:37:27 2019
     2019-02-16 15:37:27   LastOldMessage  Sat Feb 16 15:36:53 2019
     2019-02-16 15:37:27   Lux             35
     2019-02-16 15:37:27   Moisture        0
     2019-02-16 15:37:27   Temperature     21.9
     2019-02-16 15:37:27   distance_OMG_3  32.73764
     2019-02-16 15:36:53   distance_OMG_5  1.01076
     2019-02-16 15:36:45   distance_OMG_6  6.44788
     2019-02-16 15:37:27   fer             0
     2019-02-16 15:37:27   id              c4:7c:8d:66:ac:e7
     2019-02-16 15:36:27   lux             35
     2019-02-16 15:35:48   moi             0
     2019-02-16 15:37:27   name            Flower care
     2019-02-16 15:37:27   rssi_OMG_3      -94
     2019-02-16 15:36:53   rssi_OMG_5      -59
     2019-02-16 15:36:45   rssi_OMG_6      -76
     2019-02-16 15:37:27   servicedata     7120980028e7ac668d7cc40d0910020000
     2019-02-16 15:37:27   servicedatauuid 0000fe95-0000-1000-8000-00805f9b34fb
     2019-02-16 15:36:53   tem             21.9
Attributes:
   IODev      m2s
   alias      Feigen
   event-on-change-reading Temperature,Moisture,Lux,Fertility
   group      Sensoren
   oldreadings LastMessage
   readingList /OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7:.* { json2nameValue($EVENT) }
   room       FlowerCare,MQTT2_DEVICE
   stateFormat T: Temperature°C - M: Moisture% - L: Lux - F: Fertility
   userReadings LastMessage {localtime},
LastOldMessage {OldReadingsVal($name,"LastMessage","")},
Temperature {ReadingsVal($name,"tem","")},
Moisture {ReadingsVal($name,"moi","")},
Lux {ReadingsVal($name,"lux","")},
Fertility {ReadingsVal($name,"fer","")}

Perl ist v5.26.1.

Gruß,
Michael
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 16 Februar 2019, 23:04:25
Sorry, kann das gemeldete Problem nicht nachstellen, ich bekomme keine Fehler.

Folgende Daten werden vom FHEM Modul offensichtlich anders interpretiert, als es beabsichtigt war:
Zitat
2019.02.15 22:50:03.922 5: PUBLISH: 003(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"fer":
Entweder ich oder der Sender hat die Doku (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718023) nicht verstanden.


Welches Programm schickt diese Daten?
Und mit welchem MQTT Protokoll Version? Auf der FHEM-Seite sieht man das in der "echten" CONNECT Meldung.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: OppiM am 17 Februar 2019, 18:37:21
Hi,

Der Sender ist ein OpenMQTTGateway (https://github.com/1technophile/OpenMQTTGateway (https://github.com/1technophile/OpenMQTTGateway)).

Hier ein Mitschnitt des Connect:
2019.02.17 18:05:12.361 4: Connection accepted from m2s_192.168.18.131_65256
2019.02.17 18:05:12.373 5: CONNECT: (16)T(0)(4)MQTT(4)(230)(0)(15)(0)(5)OMG_5(0)(26)/OpenMQTTGateway/OMG_5/LWT(0)(7)Offline(0)(13)your_username(0)(13)your_password
2019.02.17 18:05:12.373 4: m2s_192.168.18.131_65256 OMG_5 CONNECT V:4 keepAlive:15 LWT:/OpenMQTTGateway/OMG_5/LWT:Offline usr:your_username

Ich habe nochmal alle in Frage kommenden MQTT2-Devices aufgeräumt und evt. falsche/überflüssige RegEx entfernt.

Hier mal ein Log von der Senderseite, die einen Absturz produziert hat, da seh ich keine Auffälligkeiten:
17:35:10.521 -> Pub json into:
17:35:10.521 -> /OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7
17:35:10.521 -> {"moi":"0"}

Hier der dazugehörige Absturz von FHEM (leider nur Verbose 4...):
2019.02.17 17:35:10.782 4: m2s_192.168.18.131_53496 OMG_5 PUBLISH &/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"moi"::
2019.02.17 17:35:10.784 1: ERROR: Unhandled packet CONNACK, disconneting m2s_192.168.18.131_53496
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/^OMG_5:&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{ <-- HERE "moi"_:.*$/ at ./FHEM/10_MQTT2_DEVICE.pm line 104.

Für mich sieht das so aus, als ob die Daten irgendwie verstümmelt werden, das MQTT2-Device versucht dann aber trotzdem die Daten weiterzuverarbeiten und dann kommt es zum Crash. Ich hab auch mal versucht, FHEM selber per MQTTSpy eine solche verstümmelte Nachricht zu schicken, die wird anstandslos als fehlerhaft aussortiert und FHEM läuft einfach weiter.

Wie sollte denn eine "normale" CONNACK-Nachricht aussehen? Leider find ich im Log nur die Ausgaben bei den Abstürzen. Und die sehen immer so aus, als wäre da der Rest der verstümmelten Nachricht mit drin.

2019.02.15 22:50:03.922 4: m2s_192.168.18.129_54398 OMG_6 PUBLISH &/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"fer"::
2019.02.15 22:50:03.927 5: CONNACK: "0"}freeMem":82852,"rssi":-49,"SSID":"Oppenheimer"

Gruß,
Michael
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 17 Februar 2019, 20:31:58
(4)MQTT bedeutet Version 3.1.1, das ist genau das, was ich implementiert habe. Ich meine das gesendete PUBLISH Paket vom OpenMQTTGateway ist kaputt, da die Laengenangabe ohne gesetzten Bit 7 (wie bei 0x30) nur ein Byte ist, siehe verlinkte Dokumentation im vorherigen Beitrag.
Die nachfolgend als CONNACK interpretierte Daten sind nur eine Folge der kaputten PUBLISH-Message.

Was mich wundert, sind deine Abstuerze, die ich selbst nicht reproduzieren kann.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: OppiM am 20 Februar 2019, 12:57:38
Hi,

ich hab jetzt alles, was mit den OpenMQTTGateways zu tun hat, auf ein Testsystem umgezogen. Dieses läuft unter Docker mit einer anderen Perl-Version (5.24.1).

Das System geht mit der kaputten Nachricht souverän um und läuft munter weiter:
2019.02.20 08:08:43.680 5: PUBLISH: 0(127)(0)$/OpenMQTTGateway/home_presence/OMG_1{"id":"c4:7c:8d:66:2e:96","name":"Flower care","rssi_OMG_1":-88,"distance_OMG_1":19.7325}
2019.02.20 08:08:43.680 4: m2s_192.168.18.221_49180 OMG_1 PUBLISH /OpenMQTTGateway/home_presence/OMG_1:{"id":"c4:7c:8d:66:2e:96","name":"Flower care","rssi_OMG_1":-88,"distance_OMG_1":19.7325}
2019.02.20 08:08:43.682 5: m2s: dispatch autocreate\000OMG_1\000/OpenMQTTGateway/home_presence/OMG_1\000{"id":"c4:7c:8d:66:2e:96","name":"Flower care","rssi_OMG_1":-88,"distance_OMG_1":19.7325}
2019.02.20 08:08:43.919 5: PUBLISH: 0(237)(1)(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D662E96{"id":"c4:7c:8d:66:2e:96","name":"Flower care","rssi_OMG_1":-88,"distance_OMG_1":19.7325,"servicedata":"71209800d5962e668d7cc40d0910022b01","servicedatauuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.20 08:08:43.919 4: m2s_192.168.18.221_49180 OMG_1 PUBLISH /OpenMQTTGateway/BTtoMQTT/C47C8D662E96:{"id":"c4:7c:8d:66:2e:96","name":"Flower care","rssi_OMG_1":-88,"distance_OMG_1":19.7325,"servicedata":"71209800d5962e668d7cc40d0910022b01","servicedatauuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.20 08:08:43.921 5: m2s: dispatch autocreate\000OMG_1\000/OpenMQTTGateway/BTtoMQTT/C47C8D662E96\000{"id":"c4:7c:8d:66:2e:96","name":"Flower care","rssi_OMG_1":-88,"distance_OMG_1":19.7325,"servicedata":"71209800d5962e668d7cc40d0910022b01","servicedatauuid":"0000fe95-0000-1000-8000-00805f9b34fb"}
2019.02.20 08:08:43.923 5: PUBLISH: 005(0)&/OpenMQTTGateway/BTtoMQTT/C47C8D662E96{"fer":
2019.02.20 08:08:43.923 4: m2s_192.168.18.221_49180 OMG_1 PUBLISH &/OpenMQTTGateway/BTtoMQTT/C47C8D662E96{"fer"::
2019.02.20 08:08:43.924 5: m2s: dispatch autocreate\000OMG_1\000&/OpenMQTTGateway/BTtoMQTT/C47C8D662E96{"fer"_\000
2019.02.20 08:08:43.925 5: CONNACK: "299"}reeMem":80960,"rssi":-51,"SSID":"Oppenheimer",
2019.02.20 08:08:43.925 1: ERROR: Unhandled packet CONNACK, disconneting m2s_192.168.18.221_49180
2019.02.20 08:08:43.928 5: m2s: dispatch autocreate\000OMG_1\000/OpenMQTTGateway/OMG_1/LWT\000Offline
2019.02.20 08:08:43.931 4: Connection accepted from m2s_192.168.18.221_50117
2019.02.20 08:08:43.932 5: CONNECT: (16)T(0)(4)MQTT(4)(230)(0)(15)(0)(5)OMG_1(0)(26)/OpenMQTTGateway/OMG_1/LWT(0)(7)Offline(0)(13)your_username(0)(13)your_password
2019.02.20 08:08:43.932 4: m2s_192.168.18.221_50117 OMG_1 CONNECT V:4 keepAlive:15 LWT:/OpenMQTTGateway/OMG_1/LWT:Offline usr:your_username
2019.02.20 08:08:43.935 5: PUBLISH: 1"(0)(26)/OpenMQTTGateway/OMG_1/LWTOnline
2019.02.20 08:08:43.935 4: m2s_192.168.18.221_50117 OMG_1 PUBLISH /OpenMQTTGateway/OMG_1/LWT:Online
2019.02.20 08:08:43.936 5: m2s: dispatch autocreate\000OMG_1\000/OpenMQTTGateway/OMG_1/LWT\000Online

Aber ich denke, ich hab jetzt besser verstanden, was den Absturz verursacht. Durch 2019.02.20 08:08:43.924 5: m2s: dispatch autocreate\000OMG_1\000&/OpenMQTTGateway/BTtoMQTT/C47C8D662E96{"fer"_\000
wird per Autocreate ein fehlerhafter Eintrag zur readingList hinzugefügt.

In den 2 Tagen hat sich in den readingList schon einiges fehlerhaftes angesammelt. Hier mal ein Beispiel (die ersten 3 Zeilen waren von mir so definiert):
OMG_3:/OpenMQTTGateway/OMG_3/SYStoMQTT:.* { json2nameValue($EVENT) }\
OMG_3:/OpenMQTTGateway/OMG_3/LWT:.* LWT\
OMG_3:/OpenMQTTGateway/OMG_3/version:.* version\
OMG_3:&/OpenMQTTGateway/BTtoMQTT/C47C8D66ACE7{"fer"_:.* C47C8D66ACE7__fer__\
OMG_3:\$/OpenMQTTGateway/home_presence/OMG_3{"id"_"c4:.* OMG_3__id___c4\
OMG_3:8d_66_ac_e7","rssi_OMG_3"_-91,"distance_OMG_3"_25\.519:.* 8d_66_ac_e7___rssi_OMG_3__-91__distance_OMG_3__25.519\
OMG_3:168\.18\.223","modules"_"BT0k:.* 168.18.223___modules___BT0k

Ich hab jetzt bei allen OpenMQTTGateway-Devices die readingList wieder aufgeräumt und Autocreate abgeschaltet, mal sehen, ob das mein Problem behebt.

Wenn das Testsystem dann stabil läuft, versuch ich es wieder im Produktivsystem.

Gruß,
Michael
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 20 Februar 2019, 15:40:53
Zitat
wird per Autocreate ein fehlerhafter Eintrag zur readingList hinzugefügt.
Das kann aber MQTT2_DEVICE nicht erkennen.
Die Ursache liegt (wie vorhin geschrieben) an in bestimmten Faellen unterschiedliche Auffassung der Syntax zwischen MQTT2_SERVER und OpenMQTTGateway.
Solange das nicht geklaert ist, wuerde ich mit "produktiv" vorsichtig sein.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: cc13 am 04 März 2019, 18:16:01
Hallo,

nachdem ich letzte Woche vier Gosund SP1 v23 Module bekam, habe ich eine davon mit der c't Lösung und dem Raspberry ota geflasht. Hat soweit funktioniert und auch mit Hilfe dieses Forums konnte ich die Steckdose per mqtt2 an mein fhem binden. Danke für eure Arbeit.

Wenn ich die Steckdose nun per on/off von fhem ein/ausschalten möchte, funktioniert das nicht bei jedem klick. Die Kleinschreibung habe ich schon mit StateText1 off usw. in der Gosung gesetzt.

Im Sonoff-Console-Log sind mir folgende Meldungen aufgefallen und ich frage hier mal, ob es damit zusammenhängen kann, dass fhem die Steckdose nicht immer zuverlässig ein/ausschaltet:

08:39:17 MQT: Attempting connection...
08:39:22 MQT: Connect failed to 192.168.1.3:1883, rc -2. Retry in 10 sec
...
08:39:46 MQT: Attempting connection...
08:39:46 MQT: Connect failed to 192.168.1.3:1883, rc -2. Retry in 10 sec
08:39:50 UPP: Multicast (re)joined
...
08:40:31 WIF: Connecting to AP1 MEIN_WLAN in mode 11N as sonoff-2154...
08:40:35 WIF: Connected
08:40:35 UPP: Multicast (re)joined
08:40:36 MQT: Attempting connection...
08:40:36 MQT: Connected

Ich habe probehalber mal auf einen MQTT-Server gewechselt, der in einem Container auf meinem NAS läuft und dort kommt diese Fehlermeldung nicht. Was soll/kann ich testen, um weiterzukommen?

Installiert ist mqtt2 in einer FHEM Umgebung, die auf einem ZeroW mit DietPi läuft.

Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 04 März 2019, 18:18:30
"attr mqtt2_server verbose 5" setzen, und FHEM-Log-Ausschnitt hier anhaengen.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: cc13 am 05 März 2019, 14:06:14
Nachdem es mit dem MQTT auf dem NAS funktionierte, habe ich es wieder mit dem mqtt2 in fhem verbunden. Außerdem steckt die Steckdose jetzt an einem anderen Ort (weiter weg vom Router), die Meldungen kommen nicht mehr.

Meine Anfrage kann also erstmal zu den Akten gelegt werden.

Danke.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: majorshark am 11 März 2019, 08:45:06
Ich habe mal eine Frage zum Attribut "keepaliveFactor".
So wie es sehe bezieht sich das Attribut auf den gesamten MQTT2 Server. Wie könnte man dann den "keepalive check" für einen bestimmten Client abschalten oder ändern?
Hintergrund ist ein MQTT-Client der auf Akku läuft und deswegen die meiste Zeit im DeepSleep ist. Dieser ist dann logischerweise für den Server nicht mehr erreichbar. Wenn ich die keepalive Zeit auf diesen Client ausrichte, wäre das kontraproduktiv für die Überprüfung der restlichen Clients.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 11 März 2019, 08:50:15
Zitat
Wie könnte man dann den "keepalive check" für einen bestimmten Client abschalten oder ändern?
Das ist z.Zt. nicht moeglich.
Ich empfehle keepAlive im Client anzupassen, eigentlich ist das auch die richtige Stelle dafuer.

Nachtrag:
Zitat
Dieser ist dann logischerweise für den Server nicht mehr erreichbar.
Das ist falsch formuliert. keepAlive ist ein Versprechen des Clients, alle X Sekunden sich zu melden, der Server versucht keine Kommunikation mit dem Client.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: majorshark am 11 März 2019, 09:14:38
Zitat
Das ist z.Zt. nicht moeglich.
Ich empfehle keepAlive im Client anzupassen, eigentlich ist das auch die richtige Stelle dafuer.

Ah, ok. Das ist eigentlich logisch, das das der Client dem Server mitteilen sollte wann er gedenkt sich wieder zu melden. Mal sehen ob das ESPEasy überhaupt kann.

Danke
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: juppzupp am 14 März 2019, 18:23:01
Ich vermute es dauert 1-2 Stunden Doku Lesen, Implementieren, und Testen.
Kann man es bei esp-link nicht abschalten?
Müsste nochmal nachfragen, wie das genau gemeint ist ?
Habe eine Gosund sp111 mit espurna 1.13.5, undes sieht auch so aus.
tasmota/mqtt funktioniert, macht dafür aber probleme im/mit dem wlan.

logfile :
2019.03.14 18:14:49 2: mqtt_server_192.168.0.111_6227 wants unclean session, disconnecting
2019.03.14 18:15:44 4: Connection accepted from mqtt_server_192.168.0.111_2359
2019.03.14 18:15:44 2: mqtt_server_192.168.0.111_2359 wants unclean session, disconnecting
2019.03.14 18:16:44 4: Connection accepted from mqtt_server_192.168.0.111_29802
2019.03.14 18:16:44 2: mqtt_server_192.168.0.111_29802 wants unclean session, disconnecting

event monitor :
2019-03-14 18:18:59 MQTT2_SERVER mqtt_server nrclients: 1
2019-03-14 18:18:59 MQTT2_SERVER mqtt_server nrclients: 0

list :

 Internals:
   CONNECTS   17
   DEF        1883 global
   FD         9
   NAME       mqtt_server
   NR         20
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   Helper:
     DBLOG:
       nrclients:
         logdb:
           TIME       1552584014.52619
           VALUE      0
   READINGS:
     2019-03-14 18:20:14   nrclients       0
     2019-03-14 18:09:07   state           Initialized
   clients:
   retain:
Attributes:
   autocreate 1
   verbose    5

danke.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 14 März 2019, 19:06:26
2019.03.14 18:14:49 2: mqtt_server_192.168.0.111_6227 wants unclean session, disconnectingDas Problem sollte seit einem Monat nicht mehr vorkommen (siehe https://forum.fhem.de/index.php/topic,90145.msg898357.html#msg898357), bitte ein FHEM update durchfuehren.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: juppzupp am 14 März 2019, 19:21:46
2019.03.14 18:14:49 2: mqtt_server_192.168.0.111_6227 wants unclean session, disconnectingDas Problem sollte seit einem Monat nicht mehr vorkommen (siehe https://forum.fhem.de/index.php/topic,90145.msg898357.html#msg898357), bitte ein FHEM update durchfuehren.
danke. hatte vergessen das testsystem zu updaten. mea culpa.
läuft jetzt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: SamNitro am 15 März 2019, 19:42:59
Hallo, ich habe eine Steckdose am laufen wo ich nur 2 werte loggen möchte,
-POWER (on/off)
-ENERGY_Power (Verbrauch)
Internals:
   CID        DVES_2ACCCD
   DEF        DVES_2ACCCD
   DEVICETOPIC gosund_trockner
   FUUID      5c473504-f33f-19ae-cb8e-557064339709d65e
   IODev      m2s
   LASTInputDev m2s
   MSGCNT     4854
   NAME       gosund_trockner
   NR         96
   STATE      ON
   TYPE       MQTT2_DEVICE
   m2s_MSGCNT 4854
   m2s_TIME   2019-03-15 19:39:37
   Helper:
     DBLOG:
       ENERGY_Power:
         DBLogging:
           TIME       1552553132.32963
           VALUE      0
       POWER:
         DBLogging:
           TIME       1552675176.94179
           VALUE      ON
       state:
         DBLogging:
           TIME       1552562978.71787
           VALUE      POWER:
   READINGS:
     2019-03-15 19:39:37   ENERGY_ApparentPower 0
     2019-03-15 19:39:37   ENERGY_Current  0.000
     2019-03-15 19:39:37   ENERGY_Factor   0.00
     2019-03-15 19:39:37   ENERGY_Period   0
     2019-03-15 19:39:37   ENERGY_Power    0
     2019-03-15 19:39:37   ENERGY_ReactivePower 0
     2019-03-15 19:39:37   ENERGY_Today    0.000
     2019-03-15 19:39:37   ENERGY_Total    0.003
     2019-03-15 19:39:37   ENERGY_TotalStartTime 2019-03-12T18:31:36
     2019-03-15 19:39:37   ENERGY_Voltage  231
     2019-03-15 19:39:37   ENERGY_Yesterday 0.000
     2019-03-12 18:50:51   FallbackTopic   cmnd/DVES_2ACCCD_fb/
     2019-03-12 18:50:51   GroupTopic      sonoffs
     2019-03-12 18:50:51   Hostname        gosund_trockner-3277
     2019-03-12 18:50:51   IPAddress       10.1.1.45
     2019-03-15 19:38:46   LWT             Online
     2019-03-15 19:39:36   LoadAvg         19
     2019-03-12 18:50:51   Module          BlitzWolf SHP
     2019-03-12 18:29:07   OtaUrl          http://sonoff.maddox.co.uk/tasmota/sonoff.bin
     2019-03-15 19:39:36   POWER           ON
     2018-08-29 19:15:06   Restart         Restarting
     2019-03-12 18:50:51   RestartReason   Power on
     2019-03-15 19:39:36   Sleep           50
     2019-03-15 19:39:36   SleepMode       Dynamic
     2019-03-15 19:39:37   Time            2019-03-15T19:39:36
     2019-03-12 18:30:21   UPGRADE         Failed HTTP error: read Timeout
     2019-03-12 18:29:07   Upgrade         Version 6.1.1 from http://sonoff.maddox.co.uk/tasmota/sonoff.bin
     2019-03-15 19:39:36   Uptime          3T00:48:51
     2019-03-15 19:39:36   Vcc             3.448
     2019-03-12 18:50:51   Version         6.4.1(sonoff)
     2019-03-12 18:50:51   WebServerMode   Admin
     2019-03-15 19:39:36   Wifi_AP         1
     2019-03-12 18:25:40   Wifi_APMac      xxx
     2019-03-15 19:39:36   Wifi_BSSId      xxx
     2019-03-15 19:39:36   Wifi_Channel    6
     2019-03-15 19:39:36   Wifi_RSSI       68
     2019-03-15 19:39:36   Wifi_SSId       PC
     2019-03-12 18:49:11   state           off
Attributes:
   DbLogInclude POWER,ENERGY_Power
   IODev      m2s
   devStateIcon ON:black_Steckdose.on OFF:black_Steckdose.off .*:black_Steckdose.off
   devicetopic gosund_trockner
   event-on-change-reading .*
   eventMap   on:ON off:OFF
   readingList DVES_2ACCCD:tele/gosund_trockner/LWT:.* LWT
DVES_2ACCCD:cmnd/gosund_trockner/POWER:.* POWER
DVES_2ACCCD:tele/gosund_trockner/INFO1:.* { json2nameValue($EVENT) }
DVES_2ACCCD:tele/gosund_trockner/INFO2:.* { json2nameValue($EVENT) }
DVES_2ACCCD:tele/gosund_trockner/INFO3:.* { json2nameValue($EVENT) }
DVES_2ACCCD:stat/gosund_trockner/RESULT:.* { json2nameValue($EVENT) }
DVES_2ACCCD:stat/gosund_trockner/POWER:.* POWER
DVES_2ACCCD:tele/gosund_trockner/STATE:.* { json2nameValue($EVENT) }
DVES_2ACCCD:tele/gosund_trockner/SENSOR:.* { json2nameValue($EVENT) }
DVES_2ACCCD:stat/gosund_trockner/UPGRADE:.* UPGRADE
DVES_2ACCCD:tele/gosund_trockner/UPTIME:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    on cmnd/$DEVICETOPIC/POWER on
off cmnd/$DEVICETOPIC/POWER off
reboot cmnd/$DEVICETOPIC/Restart 1
   stateFormat POWER

trotz event-on-change-reading .* loggt er mir immer wieder den state POWER
2019-03-15 14:16:37 gosund_trockner MQTT2_DEVICE POWER: ON POWER ON
2019-03-15 12:43:37 gosund_trockner MQTT2_DEVICE POWER: ON POWER ON
2019-03-15 11:27:36 gosund_trockner MQTT2_DEVICE POWER: ON POWER ON
2019-03-15 11:26:36 gosund_trockner MQTT2_DEVICE POWER: ON POWER ON
2019-03-15 11:02:36 gosund_trockner MQTT2_DEVICE POWER: ON POWER ON
2019-03-15 10:59:36 gosund_trockner MQTT2_DEVICE POWER: ON POWER ON
2019-03-15 10:37:36 gosund_trockner MQTT2_DEVICE POWER: ON POWER ON

kann es sein weil das als Paket geloggt wird?
19:35:36 MQT: tele/gosund_trockner/STATE = {"Time":"2019-03-15T19:35:36","Uptime":"3T00:44:51","Vcc":3.454,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Wifi":{"AP":1,"SSId":"xxx","BSSId":"xxx","Channel":6,"RSSI":68}}
Gruß Patrick
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: vbs am 17 März 2019, 23:11:17
Folgendes Verhalten beobachtet (sieht für mich ungewollt aus):

Ich hab ein MQTT2_DEVICE mit Namen "MQTT2_vibration2":
Internals:
   CFGFN     
   CID        zigbee_0x00158d0002b5f43a
   DEF        zigbee_0x00158d0002b5f43a
   DEVICETOPIC MQTT2_vibration2
   FUUID      5c8d865d-f33f-af31-34a4-4d9dca636d8e2dea
   IODev      sys_mqtt
   LASTInputDev sys_mqtt
   MSGCNT     151
   NAME       MQTT2_vibration2
   NR         1049
   STATE      Action: vibration
   TYPE       MQTT2_DEVICE
   sys_mqtt_MSGCNT 151
   sys_mqtt_TIME 2019-03-17 23:05:42
   OLDREADINGS:
   READINGS:
     2019-03-17 23:05:42   action          vibration
     2019-03-17 17:18:08   angle           83
     2019-03-17 23:05:42   angle_x         0
     2019-03-17 23:05:42   angle_x_absolute 90
     2019-03-17 23:05:42   angle_y         0
     2019-03-17 23:05:42   angle_y_absolute 90
     2019-03-17 23:05:42   angle_z         90
     2019-03-17 00:55:20   associatedWith  env_zigbee
     2019-03-17 23:05:42   battery         100
     2019-03-17 23:05:42   linkquality     55
     2019-03-17 00:55:20   set_sensitivity medium
     2019-03-17 00:55:20   state           sensitivity
     2019-03-17 23:05:42   voltage         3065
Attributes:
   IODev      sys_mqtt
   model      L_15_vibration_sensor
   readingList zigbee2mqtt/0x00158d0002b5f43a:.* { json2nameValue($EVENT) }
zigbee2mqtt/0x00158d0002b5f43a/set:.* { json2nameValue($EVENT, 'set_', $JSONMAP) }
   room       MQTT2_DEVICE
   setList    sensitivity:low,medium,high zigbee2mqtt/0x00158d0002b5f43a/set {"sensitivity": "$EVTPART1"}
   stateFormat Action: action

Jetzt mache ich ein "rename MQTT2_vibration2 MQTT2_vibration3":
Internals:
   CFGFN     
   CID        zigbee_0x00158d0002b5f43a
   DEF        zigbee_0x00158d0002b5f43a
   DEVICETOPIC MQTT2_vibration2
   FUUID      5c8d865d-f33f-af31-34a4-4d9dca636d8e2dea
   IODev      sys_mqtt
   LASTInputDev sys_mqtt
   MSGCNT     151
   NAME       MQTT2_vibration3
   NR         1049
   STATE      Action: vibration
   TYPE       MQTT2_DEVICE
   sys_mqtt_MSGCNT 151
   sys_mqtt_TIME 2019-03-17 23:05:42
   OLDREADINGS:
   READINGS:
     2019-03-17 23:05:42   action          vibration
     2019-03-17 17:18:08   angle           83
     2019-03-17 23:05:42   angle_x         0
     2019-03-17 23:05:42   angle_x_absolute 90
     2019-03-17 23:05:42   angle_y         0
     2019-03-17 23:05:42   angle_y_absolute 90
     2019-03-17 23:05:42   angle_z         90
     2019-03-17 00:55:20   associatedWith  env_zigbee
     2019-03-17 23:05:42   battery         100
     2019-03-17 23:05:42   linkquality     55
     2019-03-17 00:55:20   set_sensitivity medium
     2019-03-17 00:55:20   state           sensitivity
     2019-03-17 23:05:42   voltage         3065
Attributes:
   IODev      sys_mqtt
   model      L_15_vibration_sensor
   readingList zigbee2mqtt/0x00158d0002b5f43a:.* { json2nameValue($EVENT) }
zigbee2mqtt/0x00158d0002b5f43a/set:.* { json2nameValue($EVENT, 'set_', $JSONMAP) }
   room       MQTT2_DEVICE
   setList    sensitivity:low,medium,high zigbee2mqtt/0x00158d0002b5f43a/set {"sensitivity": "$EVTPART1"}
   stateFormat Action: action

Man beachte, dass DEVICETOPIC weiterhin "MQTT2_vibration2" ist.

Erst wenn ich dann das Define editiere (Button "DEF") und ohne etwas zu ändern "modify MQTT_vibration3" drücke, springt DEVICETOPIC um:
Internals:
   CFGFN     
   CID        zigbee_0x00158d0002b5f43a
   DEF        zigbee_0x00158d0002b5f43a
   DEVICETOPIC MQTT2_vibration3
   FUUID      5c8d865d-f33f-af31-34a4-4d9dca636d8e2dea
   IODev      sys_mqtt
   LASTInputDev sys_mqtt
   MSGCNT     151
   NAME       MQTT2_vibration3
   NR         1049
   STATE      Action: vibration
   TYPE       MQTT2_DEVICE
   sys_mqtt_MSGCNT 151
   sys_mqtt_TIME 2019-03-17 23:05:42
   OLDREADINGS:
   READINGS:
     2019-03-17 23:05:42   action          vibration
     2019-03-17 17:18:08   angle           83
     2019-03-17 23:05:42   angle_x         0
     2019-03-17 23:05:42   angle_x_absolute 90
     2019-03-17 23:05:42   angle_y         0
     2019-03-17 23:05:42   angle_y_absolute 90
     2019-03-17 23:05:42   angle_z         90
     2019-03-17 00:55:20   associatedWith  env_zigbee
     2019-03-17 23:05:42   battery         100
     2019-03-17 23:05:42   linkquality     55
     2019-03-17 00:55:20   set_sensitivity medium
     2019-03-17 00:55:20   state           sensitivity
     2019-03-17 23:05:42   voltage         3065
Attributes:
   IODev      sys_mqtt
   model      L_15_vibration_sensor
   readingList zigbee2mqtt/0x00158d0002b5f43a:.* { json2nameValue($EVENT) }
zigbee2mqtt/0x00158d0002b5f43a/set:.* { json2nameValue($EVENT, 'set_', $JSONMAP) }
   room       MQTT2_DEVICE
   setList    sensitivity:low,medium,high zigbee2mqtt/0x00158d0002b5f43a/set {"sensitivity": "$EVTPART1"}
   stateFormat Action: action

Könnt mich gerne korrigieren, aber meine Erwartung wäre gewesen, dass:
* DEVICETOPIC schon beim Umbennen mitgeführt wird
* ein Speichern des Defines, ohne etwas am Define geändert zu haben, das Gerät nicht verändert
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 17 März 2019, 23:37:48
Danke fuer den Hinweis, habs gefixt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: supernova1963 am 18 März 2019, 06:46:38
Hallo rudolfkoenig,

ist jetzt DEVICETOPIC = NAME ?

Danke,

Gernot
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 18 März 2019, 08:46:28
Falls das eine direkte Frage war: nein.
Falls das eine rhetorische Frage war: habs (nochmal) gefixt.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: supernova1963 am 18 März 2019, 16:01:28
Es war eher reflektierend gemeint.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: pink99panther am 19 Juli 2019, 17:23:21
Hallo,

bin im Moment dabei mein fhem auf einen neuen Raspi händisch umzuziehen.
Dabei habe ich festgestellt, dass autocreate complex unter dem Style f18 erst richtig richtig funktioniert hat,
nachdem ich den Style einmal auf dark umgestellt hatte.
Es fehlen SENSOR_, $JSONMAP in { json2nameValue($EVENT, SENSOR_, $JSONMAP) }

LG
p99p
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 19 Juli 2019, 18:16:27
Im Moment wuerde ich viel Geld darauf verwetten, dass ein MQTT2/autocreate Problem nichts mit dem f18 Style zu tun hat, auch wenn die Beschreibung des Problems mehr als lueckenhaft ist.

Uebrigens: es heisst "SENSOR_" und nicht SENSOR_.
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: pink99panther am 19 Juli 2019, 19:21:40
Das Problem ist ja jetzt weg.
Die readingList wird ja jetzt richtig erzeugt.
Wollte nur Bescheid sagen, dass es hier geklemmt hat (unvollständige Einträge vor dem ersten Stylewechsel)
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: fruemmel am 20 August 2019, 20:43:30
Hallo,

im Modul 00_MQTT2_Server hat sich wohl ein Fehler eingeschlichen. Das Attribut keepaliveFactor wird nicht ausgewertet, da in Zeile 85 die Funktion AttrVal als erstem Parameter mit dem Hash und nicht mit dem Namen aufgerufen wird:
my $multiplier = AttrVal($hash, "keepaliveFactor", 1.5);Sollte m.E. so aussehen:
my $multiplier = AttrVal($hash->{NAME}, "keepaliveFactor", 1.5);Wäre schön, wenn das ein Profi prüfen und ggfls. korrigieren und einchecken könnte.

Gruß Wolfgang
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 20 August 2019, 23:06:10
Danke fuer den Hinweis, habs eingecheckt
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: Karflyer am 23 Dezember 2019, 08:45:59
Ich habe immer wieder eine Fehlermeldung im Log nachdem ich das folgende MQTT2-Device selbst angelegt habe:
Internals:
   CHANGED   
   DEVICETOPIC application/1/device/00e0060e9fdea2c4
   FUUID      5dfb7a62-f33f-bb67-2808-d9f2812f1987e178
   FVERSION   10_MQTT2_DEVICE.pm:0.207940/2019-12-21
   IODev      MQTT2_CLIENT
   LASTInputDev MQTT2_CLIENT
   MQTT2_CLIENT_MSGCNT 4
   MQTT2_CLIENT_TIME 2019-12-23 08:37:53
   MSGCNT     4
   NAME       lora_heltec32
   NR         737
   STATE      T: 14.5 °C H: 63 % di: 0 do: 0
   TYPE       MQTT2_DEVICE
   JSONMAP:
     object_digitalInput_3 DI
     object_digitalOutput_4 DO
     object_humiditySensor_2 humidity
     object_temperatureSensor_1 temperature
   READINGS:
     2019-12-23 08:37:53   DI              0
     2019-12-23 08:37:53   DO              0
     2019-12-23 08:42:09   activ           1
     2019-12-23 08:37:53   adr             true
     2019-12-23 08:37:53   applicationID   1
     2019-12-23 08:37:53   applicationName lora_lpp_app
     2019-12-23 08:37:53   data            AWcAkQJofgMAAAQBAA==
     2019-12-23 08:37:53   devEUI          00e0060e9fdea2c4
     2019-12-23 08:37:53   deviceName      heltec32
     2019-12-23 08:37:53   fCnt            0
     2019-12-23 08:37:53   fPort           1
     2019-12-23 08:37:53   humidity        63
     2019-12-23 08:37:53   rxInfo_1_gatewayID b827ebfffecdeefa
     2019-12-23 08:37:53   rxInfo_1_loRaSNR 8.8
     2019-12-23 08:37:53   rxInfo_1_location_altitude 116
     2019-12-23 08:37:53   rxInfo_1_location_latitude 48.92664
     2019-12-23 08:37:53   rxInfo_1_location_longitude 8.3679
     2019-12-23 08:37:53   rxInfo_1_name   lorawan-gateway
     2019-12-23 08:37:53   rxInfo_1_rssi   -71
     2019-12-22 20:47:06   rxInfo_1_time   2019-12-22T20:29:28.770642Z
     2019-12-23 08:37:53   rxInfo_1_uplinkID bdad8503-7e80-4262-803e-f692c4b4e0f2
     2019-12-23 08:37:53   temperature     14.5
     2019-12-23 08:37:53   txInfo_dr       5
     2019-12-23 08:37:53   txInfo_frequency 867100000
Attributes:
   DbLogExclude .*
   IODev      MQTT2_CLIENT
   autocreate 0
   devicetopic application/1/device/00e0060e9fdea2c4
   event-on-change-reading .*
   event-on-update-reading temperature
   jsonMap    object_temperatureSensor_1:temperature
object_humiditySensor_2:humidity
object_digitalInput_3:DI
object_digitalOutput_4:DO
   readingList $DEVICETOPIC/rx:.* { json2nameValue($EVENT, '', $JSONMAP) }
   readingsWatcher 900,,temperature
   room       MQTT
   stateFormat T: temperature °C H: humidity % di: DI do: DO

Die Fehlermeldung sieht so aus:
2019.12.23 08:33:58 1: PERL WARNING: Use of uninitialized value $cid in concatenation (.) or string at ./FHEM/10_MQTT2_DEVICE.pm line 520.
2019.12.23 08:33:58 1: stacktrace:
2019.12.23 08:33:58 1:     main::__ANON__                      called by ./FHEM/10_MQTT2_DEVICE.pm (520)
2019.12.23 08:33:58 1:     main::MQTT2_DEVICE_delReading       called by ./FHEM/10_MQTT2_DEVICE.pm (537)
2019.12.23 08:33:58 1:     main::MQTT2_DEVICE_addReading       called by ./FHEM/10_MQTT2_DEVICE.pm (463)
2019.12.23 08:33:58 1:     main::MQTT2_DEVICE_Attr             called by fhem.pl (3754)
2019.12.23 08:33:58 1:     main::CallFn                        called by fhem.pl (2996)
2019.12.23 08:33:58 1:     main::CommandAttr                   called by fhem.pl (1242)
2019.12.23 08:33:58 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2685)
2019.12.23 08:33:58 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (913)
2019.12.23 08:33:58 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (582)
2019.12.23 08:33:58 1:     main::FW_Read                       called by fhem.pl (3754)
2019.12.23 08:33:58 1:     main::CallFn                        called by fhem.pl (754)

ich sehe nicht was die Fehlermeldung verursacht (was fehlt). Hat jemand eine Idee?

Gruß
Stefan
Titel: Antw:[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE
Beitrag von: rudolfkoenig am 23 Dezember 2019, 09:59:07
Die Fehlermeldung wurde vom fehlenden clientId in der Definition verursacht, und ist ein Fehler im Modul, was ich jetzt hoffentlich behoben habe.
Danke fuer die Meldung.