[Bugs] 00_MQTT2_SERVER / 10_MQTT2_DEVICE

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

Vorheriges Thema - Nächstes Thema

Beta-User

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"
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

essera

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.



rudolfkoenig

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.

osr

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?

osr

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.

roelleke

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.

Beta-User

#186
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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.

osr

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!

rudolfkoenig

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.

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

osr

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.

netbus

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)

rudolfkoenig

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.

osr

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.