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;
Danke, eingecheckt
Zitat von: rudolfkoenig am 10 August 2018, 18:13:52
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
Zitatdefine <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.
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.
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.
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 :) )
Zitat von: rudolfkoenig am 10 August 2018, 21:43:47
- 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)
für MQTT2_SERVER habe ich zwei Wünsche:
- ein reading "state" und readingFnAttributes anstatt hartcodiertem STATE
(wo wird das eigentlich gesetzt ?)* - ein reading mit der Anzahl verbundener clients
Edit:
* gefunden: STATE kommt aus TcpServerUtils.pm
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.
Zitat von: rudolfkoenig am 11 August 2018, 09:01:43
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.
Zitat von: rudolfkoenig am 11 August 2018, 09:01:43
Habe TcpServerUtils modifiziert, setze da state mit readingsSingleUpdate, allerdings ohne trigger.
Danke.
Frage, läuft 00_MQTT2_SERVER
auch mit 10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm?
Gruß Billy
Versuch macht kluch... aber ich würde mal auf "nein" tippen.
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.
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
Zitat von: Billy am 11 August 2018, 17:04:36
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 :)
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.
Zitat von: betateilchen am 11 August 2018, 17:12:37
ich glaube man braucht das gar nicht, weil sich das meiste per notify lösen lässt :)
Grundsätzlich schon, es geht jedoch um Bequemlichkeit und ggf eine Reduzierung von Gerätezahl.
Zitat von: hexenmeister am 11 August 2018, 17:23:51
Grundsätzlich schon, es geht jedoch um Bequemlichkeit und ggf eine Reduzierung von Gerätezahl.
Und auch Benutzerfreundlichkeit für Otto Normalverbraucher.
Was natürlich für Profis wie "Betateilchen" anders aussieht.
Billy
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.
*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.
Zitat2018.08.11 10:59:19 1: PERL WARNING: Use of uninitialized value $param in split at ./FHEM/10_MQTT2_DEVICE.pm line 277.
Ich habe zwar keine Ahnung, wie du das hingekriegt hast, aber ich pruefe jetzt $param, und die Warnung sollte nicht mehr auftreten.
Eigentlich verhindert das attr Befehl, dass man diese Funktion ohne gesetzten $param aufruft.
ZitatFrage, läuft 00_MQTT2_SERVER auch mit 10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm?
Scheint zu klappen, auch wenn es an den neulichen xkcd (https://xkcd.com/2021/) erinnert :)
define mq MQTT2_SERVER 1883
attr mq verbose 4
define mqcl MQTT localhost:1883
Im fhem-log sehe ich:
Zitat2018.08.12 11:04:23 4: mq_127.0.0.1_54781 Net::MQTT::Message[79791] CONNECT V:3 keepAlive:60
2018.08.12 11:04:23 4: mq_127.0.0.1_54781 Net::MQTT::Message[79791] PINGREQ
ZitatJa, aber als zusätzliches internal und nicht als reading. Das hilft mir nicht weiter.
Habs zu reading geaendert, bin aber unsicher, ob es keine Nebeneffekte hat (z.Bsp. bei shutdown). Wir werden es sehen.
Weitere Aenderungen:
- es gibt jetzt ein keepaliveFactor Attribut bei MQTT2_SERVER, mit dem man das von oasis geforderte "disconnect, falls nach 1.5-mal keepalive keine Daten gekommen sind" aendern kann.
- das readingList regexp prueft jetzt auch gegen clientid:topic:message.
- ich habe erst autocreate eingebaut, und dann wieder aus :) => es gibt zu viele unterschiedliche topics, die man alle spezifizieren muss, alternativ darf man das automatisch angelegte Geraet nicht umbenennen, beide sind es nicht Wert.
- FHEM2FHEM modifiziert, damit man es mit RAW autocreate Module laedt. Leider beisst sich die Benutzung von FHEM2FHEM mit kein Support von autocreate, damit wird FHEM2FHEM fuer MQTT2_SERVER nur fuer Hartnaeckige empfohlen.
- die readingList perl Auswertung ist jetzt stabiler, bei Benutzerfehlern sollte FHEM nicht abstuerzen.
Wg. MQTT2_JSON: ich teste sowas in der Eingabezeile mit
fhem> { my $r = MQTT2_JSON('{"bla":"blaeh","hallo":"leute"}');; join("\n", map { "$_:$r->{$_}" } keys %{$r}) }
bla:blaeh
hallo:leute
Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
Ich habe zwar keine Ahnung, wie du das hingekriegt hast,
ich auch nicht.
Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
Habs zu reading geaendert, bin aber unsicher, ob es keine Nebeneffekte hat (z.Bsp. bei shutdown). Wir werden es sehen.
Danke.
Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
Wg. MQTT2_JSON: ich teste sowas in der Eingabezeile mit
fhem> { my $r = MQTT2_JSON('{"bla":"blaeh","hallo":"leute"}');; join("\n", map { "$_:$r->{$_}" } keys %{$r}) }
bla:blaeh
hallo:leute
MQTT2_JSON() wünsche ich mir als Funktion json2reading() in fhem.pl und dazu noch CommandSetReadingFromHash()
(oder eine entsprechend modifizierte Variante von CommandSetReading(), die einen hash akzeptiert)
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
Zitat von: rudolfkoenig am 12 August 2018, 14:00:21
ZitatFrage, läuft 00_MQTT2_SERVER auch mit 10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm?
Scheint zu klappen, auch wenn es an den neulichen xkcd (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
Zitat von: Billy am 13 August 2018, 10:47:51
Was macht
define mqcl MQTT localhost:1883
Ist mir nicht ganz klar.
Naja, mit dem ersten define (MQTT2_SERVER) instanziierst Du zuerst einen MQTT Server (der von FHEM gebildet wird). (Quasi der Ersatz für den mosquitto)
Im zweiten define benutzt Du dann das bisher übliche Modul MQTT, um FHEM mit diesem Server (also sich selbst) zu verbinden.
Alle anschließend definierten Geräte MQTT_DEVICE (nicht MQTT2_DEVICE !) und MQTT_BRIDGE müssen dann das mit MQTT definierte IODev verwenden.
Zitat2018.08.13 09:06:14.641 1: M2: Unhandled packet UNSUBSCRIBE, disconneting mqtt_10.0.81.60_49768
Wie es schon da steht: UNSUBSCRIBE habe ich nicht implementiert.
Kannst du dein Programm nicht ueberzeugen, es nicht zu senden? Und wozu macht es direkt nach SUBSCRIBE ein USUBSCRIBE? Ein DISCONNECT reicht doch :)
Wenn nicht, kannst du mir zeigen, wie ich das nachstellen kann, ohne Tage mit Installation von Programmen zu verbringen?
ZitatWas macht "define mqcl MQTT localhost:1883"
Eine Verbindung zum MQTT Server aufbauen. Soweit ich als Laie sehe, brauchen beide (10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm) eine MQTT Instanz.
Zitat von: rudolfkoenig am 13 August 2018, 14:42:38
Wie es schon da steht: UNSUBSCRIBE habe ich nicht implementiert.
Das ist ja nicht schlimm, aber es ist auch kein Grund, deshalb die Verbindung abzubrechen 8)
Zitat von: rudolfkoenig am 13 August 2018, 14:48:55
[...] brauchen beide (10_MQTT_BRIDGE.pm oder 10_MQTT_GENERIC_BRIDGE.pm) eine MQTT Instanz.
Ja. Dort wird leider kein fhem-dispath Mechanismus implementiert. Die Module sind sehr eng miteinander gekoppelt. :(
Btw. Ist es ein Modul angedacht, mit dem man bestehende (externe) mqtt-Server (Broker) mit dem neuen MQTT2_DEVICE verwenden kann?
ZitatIst es ein Modul angedacht, mit dem man bestehende (externe) mqtt-Server (Broker) mit dem neuen MQTT2_DEVICE verwenden kann?
Nicht von mir, sollte aber einfach sein, man muss Dispatch mit "clientid:topic:message" aufrufen, und MQTT2_DEVICE in Clients eintragen. Ueber einen externen MQTT Server duerfte clientid nicht bekannt sein, man muss als einen dummy verwenden. Wenn jemand so eine Erweiterung macht, bitte mir den Namen den Namen der dummy-clientid sagen (oder mosqpub.* verwenden), da ich mit dem "richtigen" clientid autocreate versuchen werde.
Zitat von: rudolfkoenig am 13 August 2018, 14:42:38
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
Ansonsten hat die SAP Cloud Platform einen mqtt Client :)
Was macht define mqcl MQTT localhost:1883
Ist mir nicht ganz klar.
Zitat von: betateilchen am 13 August 2018, 14:12:14
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.
Zitat von: rudolfkoenig am 13 August 2018, 14:48:55
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
Zitat von: rudolfkoenig am 11 August 2018, 09:01:43
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
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
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
Zitat 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?
deleteattr hinter der Anzeige oder alternativ
deleteattr Devicename setListZitat von: betateilchen am 14 August 2018, 13:39:35
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
Zitat von: ThoTo am 14 August 2018, 14:26:45
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.
Zitat von: ThoTo am 14 August 2018, 14:26:45
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.
Zitat von: betateilchen am 14 August 2018, 14:54:51
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
;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;
}
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?
die LWT gibt es in diesem Server auch. Mach mal ein "list <serverName>" dann siehst Du sie in den Internals unter "retain"
Ok da habe ich es gefunden, aber warum erstellt er unter dem eigentlichen Gerät kein eigenes Reading?
ZitatMQTT2_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.
ZitatDas 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"
ZitatDa hat Rudi sich selbst ausgetrickst...
Das ist nicht zu leugnen. Habe mich von deinem Patch inspirieren lassen, und es hoffentlich gefixt.
ZitatGlobal 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.
ZitatOk 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.
Vielen Dank Rudi erstmal für die beiden Module, top!!!
Zitat von: rudolfkoenig am 14 August 2018, 22:16:07
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
@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.
Zitat 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.
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 <name> MQTT2_DEVICE</code>
+ <code>define <name> MQTT2_DEVICE [<devicetopic>]</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 ondefine Sonoff_Test MQTT2_DEVICE
attr Sonoff_Test setList on cmnd/%DEVICETOPIC%/POWER on
Ergebnis: cmnd/Sonoff_Test/POWER onIch hoffe etwas mehr Licht ins Dunkle gebracht zu haben :D
Update: Patch angepasst, DEVICETOPIC kann im define mitangegeben werden.
LG Thomas
Zitat von: rudolfkoenig am 14 August 2018, 22:16:07
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
Zitat von: rudolfkoenig am 14 August 2018, 22:16:07
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.
Zitat von: rudolfkoenig am 15 August 2018, 08:27:32
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.
Zitat von: betateilchen am 15 August 2018, 10:28:56
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
Zitat von: ThoTo am 15 August 2018, 10:35:44
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.
Ich würde eine entsprechende Umsetzung auch befürworten. Macht alles kürzer, übersichtlicher und bei einem eventuellen Änderungsbedarf leichter und weniger fehleranfällig.
Zitat von: betateilchen am 15 August 2018, 11:20:46
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
Ok, die Idee mit dem DEVICETOPIC finde ich auch gut - der erste Ansatz mit dem Attribut-Gedöns war aber wirklich ein Holzweg :)
Zitat von: rudolfkoenig am 14 August 2018, 22:16:07
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
Zitat 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 :)
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.
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.
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.
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) }
ZitatKann 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.
Zitatund 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.
Ok dann warte ich mal aufs update :)
Danke
Konnte nicht warten ;D
Habe es aus dem SVN genommen, nun läuft alles super (Für meine zwecke) ;)
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
ZitatPUBLISH before CONNECT, disconnecting
Was ist das fuer ein Client?
Kriegst du den clientId sonst raus?
Koenntest du den Verkehr irgendwie mitprotokollieren?
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.
Habs gefixt. Workaround in deinem Script bis zum update:
client = mqtt.Client(client_id="myscript")
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?
Nimm mal:
attr JaroliftDongle readingList tele/jarolift-test/LWT:.* LWT
Zitat von: SamNitro am 18 August 2018, 20:16:06
Nimm mal:
attr JaroliftDongle readingList tele/jarolift-test/LWT:.* LWT
Hab ich eben auch schon probiert, leider auch keine Änderung.
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
lass mal den "\" hinter LWT\ weg
Zitat von: SamNitro am 18 August 2018, 20:47:15
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
Zitat von: rudolfkoenig am 18 August 2018, 16:55:34
Habs gefixt. Workaround in deinem Script bis zum update:
Top! Vielen Dank!
Zitatmit 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.
Zitat von: rudolfkoenig am 19 August 2018, 11:12:39
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
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.
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.
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
Zitat von: eldrik am 20 August 2018, 15:04:25
und wollte im ersten Anlauf das MQTT Modul sich mit dem MQTT2_SERVER Modul verbinden lassen
wozu?
Zitatinsufficient 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.
Zitatwozu?
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.
ZitatWie 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.
Zitatda 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.
<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>
Zitat von: betateilchen am 20 August 2018, 16:47:16
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
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.
Zitat von: rudolfkoenig am 20 August 2018, 19:05:15
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.
ZitatIm 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.
@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.
Zitat 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.
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
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.
Zitat 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.
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. :-[
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
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.
Problem mit "state". Dieser ist immer "?.?.?."
Erst wenn z.B eine ReadingsVal gesetzt wird, habe ich meinen State.
Beabsichtigt oder Bug?
Zitatattr 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 :)
Zitat von: schwatter am 23 August 2018, 18:44:32
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.
ZitatProblem mit "state". Dieser ist immer "?.?.?."
state wird nicht gesetzt, es sei denn der Benutzer hat es konfiguriert.
ZitatAuß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 \.
Zitat von: rudolfkoenig am 23 August 2018, 20:01:19
Was ist das "LWT-Onlineproblem?
Er meint den ganz normalen LWT Status ob das Gerät Online oder Offline ist.
ZitatEr 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.
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
Zitat...da schien es beim ersten mal zu gehen...
Ich betrachte das Problem als nicht vorhanden, bis ein Log das Gegenteil beweist :)
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.
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.
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"
ZitatKann 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
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"}
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:
Zitat2018.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.
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)
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
Zitat von: supernova1963 am 25 August 2018, 08:49:38
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.
Zitat von: hexenmeister am 25 August 2018, 12:07:37
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
ZitatDas 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.
ZitatD.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.
Zitat von: rudolfkoenig am 25 August 2018, 16:39:58.
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
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"?
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".
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?
Zitat von: rudolfkoenig am 26 August 2018, 13:47:48
Das Problem muss anderswo herkommen, ich sehe kein WARNING:
Danke - der Stacktrace hat es an den Tag gebracht - Fehler im stateFormat...
ZitatKann 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?
Zitat von: rudolfkoenig am 26 August 2018, 16:42:06
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.
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
Kannst du bitte die "Raw Definition" der beiden Varianten (MQTT_DEVICE und MQTT2_DEVICE ) hier anhaengen?
Zitat von: rudolfkoenig am 25 August 2018, 16:39:58
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)
Zitat 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?
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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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> ; ;Spannung: 228 V ; ;Stromstärke: 0.000 A ; ;Leistung: 0 W ; ;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
Ich meinte die _komplette_ Raw Definition, also auch die setstate Zeilen.
Ok, verstanden. Habe es oben angepasst.
Zitat von: rudolfkoenig am 23 August 2018, 20:01:19
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.
@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.
Zitat 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.
Ich hab's überlesen.... Danke, alles gut 8) 8)
LG Thomas
@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
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
Kannst du bitte die "Raw definition" vom Geraet hier anhaengen, und den Inhalt des Event-Monitors beim Schalten der Steckdose?
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
Hi,
In der Konsole des Tasmotadevice folgendes ausführen:
StateText1 off
StateText2 on
StateText3 toggle
Zitat 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?
Ich mache es mit:
attr <DEVICE> stateFormat POWER
attr <DEVICE> eventMap on:ON off:OFF
ZitatDu meinst ,,list device" oder?
Nein, entweder "list -r device", oder in FHEMWEB, DetailAnsicht, unten, Raw Definition (was list -r ausfuehrt)
Zitat von: rudolfkoenig am 03 September 2018, 13:39:26
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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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> ; ;Spannung: 0 V ; ;Stromstärke: 0.000 A ; ;Leistung: 0 W ; ;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ß,
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
Z.Bsp. mitattr GosundST1 stateFormat POWER
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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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(" ; ;Spannung: %.0f V ; ;Stromstärke: %.3f A ; ;Leistung: %.0f W ; ;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");; \
}
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.
https://forum.fhem.de/index.php/topic,90634.msg831019.html#msg831019
Danke, läuft!
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.
ZitatNur müllt mir dies natürlich mein MQTT2_DEVICE voll
Was genau heisst das?
ZitatWerde ich das nur los, indem ich im MQTT2_SERVER das autocreate deaktiviere?
Ja.
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. 😄
ZitatWofü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.
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
Wenn autocreate im MQTT2_SERVER an ist, dann wird das Geraet immer wieder angelegt.
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.
Kannst du bitte ein "attr MQTT2_SERVER verbose 5" log hier anhaengen?
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
Ich habe 8 unterschiedliche clientIds gezaehlt:
Zitatmosqpub|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.
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?
ZitatSollte 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.
ZitatWie kann ich das falsche Reading entgültig loswerden?
Nach dem Loeschen des Readings FHEM neustarten.
1.Problem in MQTT2_DEVICE:
Eine Kommandodefinition
attr <device> setList relay_0 shellies/shelly4pro-061D51/relay/0/command
erzeugt 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/command
erzeugt 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
ZitatUnknown argument relay_0, choose one of relay_0:on,off ...
.
Edit: Problem gelöst, danke.
LG
pah
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
Zitat2018.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
attr <device> setList relay_0:on,off shellies/shelly4pro-061D51/relay/0/command
An 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.
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.
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
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.
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
Starte FHEM im Terminal mit "perl fhem.pl -d fhem.cfg"
Zitat von: rudolfkoenig am 12 Oktober 2018, 11:49:54
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
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.
Zitat 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.
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:
ZitatNun 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
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);
}
argument is not a reference at ./FHEM/98_apptime.pm line 127.
Das muss ich mir merken. Danke fuer dein Ausdauer!
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.
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.
Was wäre denn die korrekte Herangehensweise wenn ich retained messages entfernen will? Mit deletereading das ganze Reading im MQTT2_SERVER löschen?
Ja, mit deletereading alles entfernen, oder mit setreading den Wert aendern.
Der Wert der RETAINED Readings muss aber weiterhin ein gueltiger JSON sein.
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
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).
Ich meine das Problem behoben zu haben, bitte um Test und Feedback.
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! :)
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.
ZitatSetze 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?
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...
ZitatWoher 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 ..?
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..
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.
Zitat von: rudolfkoenig am 06 Dezember 2018, 13:30:52
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?
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.
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)
Zitat von: essera am 06 Dezember 2018, 17:20:12
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"
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.
ZitatAnmerkung bei beiden Templates fehlt mir im webCmd on bzw off.
Ich habe jetzt bei allen drei bulbs toggle:on:off hinzugefuegt.
Zitateine runde Klammer zuviel rein gekommen.
Danke fuer den Hinweis, habs entfernt.
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?
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.
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.
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.
Zitat von: rudolfkoenig am 07 Dezember 2018, 20:19:06Ich 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...
ZitatPERL 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.
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!
ZitatPlötzlich kamen zum Teil die Power-Meldungen nicht mehr rein.
Das haette ich gerne mit einem "attr IODEV verbose 5" unterlegt.
ZitatDas 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.
ZitatGanz 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.
ZitatVon 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.
Zitat von: osr am 10 Dezember 2018, 12:54:47
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.
ZitatDamit 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...
Zitat von: rudolfkoenig am 10 Dezember 2018, 13:08:15
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.
Zitat von: rudolfkoenig am 10 Dezember 2018, 13:08:15
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 ;-)
Zitat von: rudolfkoenig am 10 Dezember 2018, 13:08:15
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.
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)
Zitatich 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.
ZitatUnter Mosquitto gab es das Problem überhaupt nicht
Das haette ich gerne nachgewiesen.
Zitat von: netbus am 14 Dezember 2018, 14:18:30
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.
Hier mal ein Log.
Ich habe keepaliveFactor mit 3 probiert und da hat es sich ein bisschen beruhigt aber Timeouts kamen immer noch.
Zitat von: osr am 14 Dezember 2018, 19:06:27
Was für Geräte hast du denn im Einsatz?
Ich habe Shelly1/2 und Sonoff S20 im Einsatz und alle mit Tasmota Firmware.
ZitatHier 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.
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
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ß.
ZitatMit 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.
ZitatDie 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.
Zitat von: osr am 16 Dezember 2018, 22:25:57
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.
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?
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
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.
Zitat 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.
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.
Zitat von: osr am 20 Dezember 2018, 18:46:49
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
Zitat von: binford6000 am 20 Dezember 2018, 21:41:54
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.
Was ist ein "Device Overview"?
Zitat von: rudolfkoenig am 21 Dezember 2018, 12:35:19
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.
Zitat von: rudolfkoenig am 21 Dezember 2018, 12:35:19
Was ist ein "Device Overview"?
Quasi die Ansicht eines devices innerhalb eines Raums. Siehe Screenshots.
Bei allen MQTT2_DEVICEs fehlt dies (nun).
VG Sebastian
Danke fuer den Hinweis, habs jetzt wieder eingebaut.
Kam mit dem "Show Neighbor Map" Patch rein.
Zitat von: rudolfkoenig am 20 August 2018, 19:05:15
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
...
ZitatIch 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.
Zitat von: rudolfkoenig am 22 Dezember 2018, 12:50:45
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
ZitatWü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.
Zitat von: rudolfkoenig am 22 Dezember 2018, 14:08:17
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.
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.
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
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.
Danke fuer den Hinweis, habs eingebaut.
Zitat von: rudolfkoenig am 26 Dezember 2018, 12:06:53
Danke fuer den Hinweis, habs eingebaut.
Gerne & Danke :)
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!
mit heutigem Update kommt folgende Fehlermeldung:
ERROR: >< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer
@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.
Zitat 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?
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
Danke, habs gefixt.
Sieht gut aus, vielen Dank Rudi!
Zitat von: rudolfkoenig am 30 Januar 2019, 21:20:16
@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 ;-)
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
Zitatkomischerweise 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.
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
- 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?
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
Sorry, kann das gemeldete Problem nicht nachstellen, ich bekomme keine Fehler.
Folgende Daten werden vom FHEM Modul offensichtlich anders interpretiert, als es beabsichtigt war:
Zitat2019.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.
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
(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.
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
Zitatwird 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.
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.
"attr mqtt2_server verbose 5" setzen, und FHEM-Log-Ausschnitt hier anhaengen.
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.
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.
ZitatWie 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:
ZitatDieser 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.
ZitatDas 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
Zitat von: rudolfkoenig am 26 August 2018, 16:42:06
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.
2019.03.14 18:14:49 2: mqtt_server_192.168.0.111_6227 wants unclean session, disconnecting
Das 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.
Zitat 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, disconnecting
Das 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.
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
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
Danke fuer den Hinweis, habs gefixt.
Hallo rudolfkoenig,
ist jetzt DEVICETOPIC = NAME ?
Danke,
Gernot
Falls das eine direkte Frage war: nein.
Falls das eine rhetorische Frage war: habs (nochmal) gefixt.
Es war eher reflektierend gemeint.
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
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_.
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)
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
Danke fuer den Hinweis, habs eingecheckt
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
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.