UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[romgen]

Ich habe das gleiche Problem mit dem MQTT Adapter, auch mehrfach täglich.

Mein FullTopic ist einfach nur einfach "%prefix%/%topic%", wie auch bei Tasmota vorgegeben.

Ein Neustart des Adapter löst das Problem meistens. Vielleicht kann ich ja selbst helfen.

Leider konnte ich noch nicht herausfinden welche MQTT Message jetzt eigentlich das Problem ist.

Update:

Dank eines alten Post von Bluefox (mit Tipps zum Debuggen) komme ich weiter.

Hier ein output mit debug enabled, trace kommt später:

2018-12-31 01:47:03.286  - info: mqtt.0 Client [DVES_6B3BFF] connected with secret 1546217223283_4092
2018-12-31 01:47:03.290  - debug: mqtt.0 stateChange mqtt.0.info.connection: {"val":"DVES_9C67D9,DVES_6B3BFF","ack":true,"ts":1546217223287,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223287}
2018-12-31 01:47:03.297  - debug: mqtt.0 stateChange mqtt.0.tele.sonoff3.LWT: {"val":"Online","ack":true,"ts":1546217223296,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223296}
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoff3/#" with regex /^cmnd\.sonoff3\..*/
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoff3/#"  with regex /^mqtt\.0\.cmnd\.sonoff3\..*/
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] publishOnSubscribe send all known states
2018-12-31 01:47:03.343  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoffs/#" with regex /^cmnd\.sonoffs\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/sonoffs/#"  with regex /^mqtt\.0\.cmnd\.sonoffs\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] publishOnSubscribe send all known states
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/DVES_6B3BFF_fb/#" with regex /^cmnd\.DVES_6B3BFF_fb\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] subscribes on "cmnd/DVES_6B3BFF_fb/#"  with regex /^mqtt\.0\.cmnd\.DVES_6B3BFF_fb\..*/
2018-12-31 01:47:03.344  - info: mqtt.0 Client [DVES_6B3BFF] publishOnSubscribe send all known states
2018-12-31 01:47:03.344  - debug: mqtt.0 stateChange mqtt.0.cmnd.sonoff3.POWER: {"val":"","ack":true,"ts":1546217223342,"q":0,"from":"system.adapter.mqtt.0","lc":1546211354064}
2018-12-31 01:47:03.371  - debug: mqtt.0 stateChange mqtt.0.stat.sonoff3.RESULT: {"val":"{\"POWER\":\"ON\"}","ack":true,"ts":1546217223370,"q":0,"from":"system.adapter.mqtt.0","lc":1546183229931}
2018-12-31 01:47:03.389  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff1/LWT = [object Object]
2018-12-31 01:47:03.389  - info: mqtt.0 Client [DVES_6B3BFF] connection closed: Error: Invalid messageId
2018-12-31 01:47:03.397  - debug: mqtt.0 stateChange mqtt.0.info.connection: {"val":"DVES_9C67D9","ack":true,"ts":1546217223390,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223390}
2018-12-31 01:47:03.399  - debug: mqtt.0 stateChange mqtt.0.tele.sonoff3.LWT: {"val":"[object Object]","ack":true,"ts":1546217223398,"q":0,"from":"system.adapter.mqtt.0","lc":1546217223398}
2018-12-31 01:47:03.407  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff2/LWT = [object Object]
2018-12-31 01:47:03.417  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff1/LWT = [object Object]
2018-12-31 01:47:03.427  - debug: mqtt.0 Client [DVES_6B3BFF] Resend messages on connect: tele/sonoff2/LWT = [object Object]

Update2:

Ok, Ich glaube, dass ich den Fehler gefunden habe.

Und zwar kommt iobroker / mqtt nicht damit klar, wenn der client ein LWT message-topic mit einem "object" payload schickt. Im Falle von Tasmota ist der "LWT" = '{"POWER":"ON"}' (bzw OFF).

Für alle interessierten: Ich habe mal einen Bug report aufgemacht. https://github.com/ioBroker/ioBroker.mqtt/issues/31

[Fischler]

Ich habe Tasmota Version 6.4.1 installiert und es läuft mittlerweile ohne Probleme.

Laut dem Debug scheint das Prefix und Topic noch vertauscht zu sein.

> stateChange mqtt.0.cmnd.sonoff3.POWER

richtig wäre allerdings:

> stateChange mqtt.0.sonoff3.cmnd.POWER

Postet doch mal das gesamte "aufgeklappte" Objekt <u>eines</u> Sonoff-Devices und die Infoseite von dem Sonoff-Device Hauptmenü -> Informationen

[Skydream]

Hi,

Warum soll das eine “richtig” und das andere “falsch” sein?

Laut beschreibung sind beide varianten gültig.

Ich kann mir auch schlecht vorstellen dass das Problem so trivial ist….mein letzter Neustart war am 28.12,

Seitdem läuft wieder alles ohne Problem.....mit 10 mqtt Clients, welche auch benutzt werden.

Es währe spannend zu sehen ob es User gubt die auch cmnd.NAME.Power etc benutzen aber trotzdem keine Probleme haben.

Gruss

Sky

[romgen]

Hey,

Ja, mal schauen, ich probiere natürlich alles aus.

Angefangen habe ich mit dem Sonoff MQTT Adapter, aber der ist ja sehr sensibel. :lol: Der braucht ja auch eine ganz spezielle Reihenfolge von prefix und topic. Ich will da nichts aussschließen ^^

Im Moment habe ich den code einfach angepasst, dass alle Messages ohne gültige id einfach gelöscht werden. Läuft auch ohne Probleme ist aber auch nur ein "hack". Nur doof für alle anderen, die nicht eben mal den Code anpassen können.

Vielen Dank für das Feedback!

[Lazybone]

Gibt es eine Lösung. Ich habe mittlerweile selbst nach einen Neustart von MQTT den Fehler nach wenigen Minuten erneut.

Mehrere Sonoff Geräte mit Tasmota 6.4.1 im Einsatz.

[Hhjung16]

@romgen:

Hey,

Ja, mal schauen, ich probiere natürlich alles aus.

Angefangen habe ich mit dem Sonoff MQTT Adapter, aber der ist ja sehr sensibel. [emoji38] Der braucht ja auch eine ganz spezielle Reihenfolge von prefix und topic. Ich will da nichts aussschließen ^^

Im Moment habe ich den code einfach angepasst, dass alle Messages ohne gültige id einfach gelöscht werden. Läuft auch ohne Probleme ist aber auch nur ein "hack". Nur doof für alle anderen, die nicht eben mal den Code anpassen können.

Vielen Dank für das Feedback! ` Moin

Ich muss sagen, ich bin auf den Sonoff Adapter umgestiegen und habe die Probleme seitdem nicht mehr, Tasmota 6.4.1 auf GosundSp111 und Sonoff Basic.

[gami82]

Bei mir gleichen Problem, sporadisch "connection closed: Error: Invalid messageId"

Konnte zumindest den Fehler bewusst herbeiführen. Sieht so aus, sobald der Client die (WLAN)Verbindung verliert (auch wenn nur kurz, ausgehend vom Client? oder Router->checked), kommt es zum Fehler.

Hatte Wlan Einstellungen meiner Fritzbox geändert ("WLAN-Zugang auf die bekannten WLAN-Geräte beschränken" auf "Alle neuen WLAN-Geräte zulassen"), dabei wurde die Verbindung kurz unterbrochen, danach Fehler "connection closed: Error: Invalid messageId" im Log.

Nach Neustart MQTT Adapter lief wieder alles.

MQTT 2.04

Node.js: v8.15.0

NPM: 6.4.1

Tasmota: 6.4.1

[Skydream]

Ich habe das mal Testweise ausprobiert. Beim Umstellen von "Alle neuen WLAN-Geräte zulassen" auf "WLAN-Zugang auf die bekanten WLAN-Geräte beschränken" ist es nicht zu ausfällen gekommen.

Als ich aber nach ein paar Minuten wider zurück auf "Alle neuen WLAN-Geräte zulassen" gestellt hat

ist mir sofort der MQTT Adapter um die Ohren geflogen.

Also lässt ich der Fehler reproduzieren….das ist ja schon mal gut.

Gruss

Sky

Nachtrag: Dieses mal war es kein sonoff Tasmota device, sondern eine "Eigenkreation". Allerdings auch ein esp8266

[gami82]

node_modules/iobroker.mqtt/lib/server.js

Funtkion function clientClose(client, reason)

Zeile receivedTopic(client._will, client, () => client.destroy()); erstmal auskommentiert. Ergebnis: läuft ohne Fehler.

Mich würde interessieren, wie oft ein "Verbindungsabbruch" Clientseitig, also ohne bewusstes herbeiführen vorkommt. Liegt es evtl. an Tasmota 6.4.x? Soweit mir bekannt ist, wurde doch dort eine dynamic Sleep implementiert (Add command SetOption60 0/1 to select dynamic sleep (0) or sleep (1) (#4497)). Ist also Sleep nicht mehr deaktiviertbar? Weiß das jemand?

[Skydream]

Werde ich morgen mal ausprobieren, danke für die Info.

Zur Häufigkeit….bei mir geschätzt alle 2-4 Wochen.

So das es nervt, aber noch kein KO Kriterium ist.

Bei meinem letzten Test war der Client, welcher als erstest in den Fehlermeldungen auftauchte, kein Tasmota Device!

Daher denke ich eher an ein Problem zwischen den Mqtt/WiFi Modulen für die ESP Bausteine und dem Mqtt Modul von iobroker.

Gruss

Sky

[romgen]

Ich bin jetzt auch auf den Sonoff Adapter wieder umgestiegen, seitdem keine Probleme mehr.

Dennoch ist das natürlich nicht die beste Lösung. Ich teste mal den Patch mit dem "will", da hatte ich ja auch gepatcht. Sonst einfach github mit in meinen issue reinposten.

Ist ja keine Lösung, dass der "generelle" MQTT Adapter hier mehr Fehler hat, als der Sonoff MQTT Adapter, der schon extrem simplifiziert ist (von wegen prefix/topic Reihenfolge usw).

Die Abbrüche kann man im Prinzip auch gut simulieren, indem man eine wackelige Wifi Verbindung hat, so war das bei mir. Vermutlich sind die Abbrüche dann schneller, als der Adapter das handlen kann - und stirbt dann an der "will" Message. Keine Ahnung :D

Zum Patch:

Ganz korrekt müsste es so ein, oder?

anstatt dem von dir komplett kommentierten Zeile:

// receivedTopic(...)

sollte man diese besser ersetzen durch

client.destroy();

Das Problem ist meiner Meinung nach nämlich nicht das client.destroy, sondern dass dabei die "client._will" verschickt wird. Feedback dazu? :idea:

[berndmr]

Ich habe nur nen Text als LastWill (Offline), und leider auch gelegentlich das Problem.

Aber erst als ich vom PubSubClient auf den Arduino MQTT ungestiegen bin.

Lass jetzt mal den Adapter im Debug laufen und schaue, ob ich es wieder treffe.

[berndmr]

Welche Version des Adapters?

Seit 25.01. ist eine Änderung im Master. Vorher hat bei mir der LastWill garnicht funktioniert.

[pfuhsy]

Hallo zusammen,

ich hab das selbe Problem. Gibt es dazu bereits eine Lösung ?
Gruss

[capitaenz]

Ich habe auch die Meldung "connection closed: Error: Invalid messageId" bis ich den MQTT-Adapter neu starte.
Dieses Problem tritt auf, wenn die Wlan-Fritz-Repeater einen neuen Kanal suchen, oder wenn ich den Stecker vom Wlan-Fritz-Repeater ziehe und die MQTT-Clients die Verbindung verlieren.

Habe jetzt die Adapter in den Versionen 2.1.1 und 2.0.4 probiert.
Node.js v10.19.0

Gibt es eine Lösung?

VG
Leif

[rhodan76]

@capitaenz versuchs mal mit dem oben beschriebenen Patch.

Mich hat das gleiche Problem zu diesem Thread geführt, die beschriebenen Änderungen haben dann für Ruhe gesorgt.
Entstehen tut das Ganze scheinbar durch eine mittelprächtige Anbindung ans WLAN, nur daran kann ich an der Stelle wenig ändern.

[capitaenz]

@rhodan76

ich habe den "Patch" durchgeführt, hatte allerdings auf etwas offizielles gehofft.
Ich werde berichten, ob es hilft.

[mar565]

Sehe ich das richtig, dass der "Patch" die last-will Funktion unbrauchbar macht?

[capitaenz]

Ob die Funktion komplett unbrauchbar gemacht wird, kann ich zwar nicht beantworten, aber bei mir funktioniert seit dem alles wie es soll und der Fehler ist nicht mehr aufgetreten.

[tcj]

Gibt es mittlerweile eine "offizielle" Lösung?