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

[RalfEngelberth]

@mickym sagte in MQTT: Message xxx deleted after 11 retries:

@valbuz Der Adapter hat als broker ein prinzipielles Problem. Das Problem sind Änderungen ohne ACK-Flag.
Ich habe kein issue aufgemacht - weil mich das ganze mehrere Wochen an Nerven gekostet hat. Man denkt ja erst mal dass man selber einen Fehler gemacht hat.

Hier https://forum.iobroker.net/topic/32143/mqtt-problem hatte jemand das gleiche Problem. Ich habe nun mosquitto installiert und nutze den mqtt Adapter als Client - damit funktioniert alles.

Hallo, danke für die Info.
Dass der Adapter ein Problem hat, ist mir auch schon aufgefallen. Z.B. funktioniert die Onlinerückmeldung nicht immer.
Das war aber auch der Grund, weshalb ich von dem mqtt Adapter auf den sonoff-Adapter geändert habe.

Ich werde mir den mosquitto mal ansehen.

[mickym]

Tasmota mit sonoff Geräten und mqtt mit dem mosquitto Server und dem mqtt Client-Adapter, um Ereignisse im iobroker weiter zu verarbeiten funktioniert bei mir einwandfrei. Es ist dann auch kein besonderer Adapter mehr erforderlich.
Ich nutzte mqtt nun für Tasmota und Shellies ohne Adapter. Kommt natürlich auf die Logik-Engine an. Ich nutze node-red unter iobroker und via node-red kann ich auch direkt auf den mqtt- Server (broker = mosquitto) zugreifen.

[RalfEngelberth]

@mickym Danke für die Info.
Dann werde ich mal testen

[valbuz]

@mickym Seit ich den ESP näher zum Accesspoint legte und der Empfang besser ist, hatte ich keine solche Meldungen mehr.

[Berzi]

@valbuz Ich habe diese Fehlermeldungen auch und vermute ebenfalls, dass es an einer schlechten Verbindung liegt.
Kannst du mir sagen, ob du hier von einer Verbesserung der WLAN-Konnektivität oder der MQTT-Verbindung zum (in meinem Falle) Raspberry sprichst? Oder ist meine Frage dämlich und das MQTT läuft sowieso mit über das WLAN und stellt gar kein eigene Funkverbindung her, sondern ist nur ein Protokoll welches sich einer vorhandenen Netzwerkverbindung bedient?

[valbuz]

@Berzi sagte in MQTT: Message xxx deleted after 11 retries:

@valbuz Ich habe diese Fehlermeldungen auch und vermute ebenfalls, dass es an einer schlechten Verbindung liegt.
Kannst du mir sagen, ob du hier von einer Verbesserung der WLAN-Konnektivität oder der MQTT-Verbindung zum (in meinem Falle) Raspberry sprichst? Oder ist meine Frage dämlich und das MQTT läuft sowieso mit über das WLAN und stellt gar kein eigene Funkverbindung her, sondern ist nur ein Protokoll welches sich einer vorhandenen Netzwerkverbindung bedient?

Wenn Du gute WLAN Abdeckung hast, läuft Dein MQTT autom. auch besser

[peterfido]

Hallo,

bei mir hat der MQTT-Adapter auch das Log zugemüllt. Habe jetzt die Logstufe auf error geändert.

mqtt.0	2021-03-07 12:44:03.417	warn	(1007) Client [shellyht-58F7D8] Message 44 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.417	warn	(1007) Client [shellyht-58F7D8] Message 45 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.406	warn	(1007) Client [shellyht-58F7D8] Message 43 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.395	warn	(1007) Client [shellyht-58F7D8] Message 42 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.384	warn	(1007) Client [shellyht-58F7D8] Message 41 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.372	warn	(1007) Client [shellyht-58F7D8] Message 40 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.362	warn	(1007) Client [shellyht-58F7D8] Message 39 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.352	warn	(1007) Client [shellyht-58F7D8] Message 38 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.342	warn	(1007) Client [shellyht-58F7D8] Message 37 deleted after 12 retries
mqtt.0	2021-03-07 12:44:03.332	warn	(1007) Client [shellyht-58F7D8] Message 36 deleted after 11 retries
mqtt.0	2021-03-07 12:44:03.321	warn	(1007) Client [shellyht-58F7D8] Message 35 deleted after 11 retries
mqtt.0	2021-03-07 12:44:03.310	warn	(1007) Client [shellyht-58F7D8] Message 34 deleted after 11 retries
mqtt.0	2021-03-07 12:44:03.300	warn	(1007) Client [shellyht-58F7D8] Message 33 deleted after 11 retries
mqtt.0	2021-03-07 12:44:03.290	warn	(1007) Client [shellyht-58F7D8] Message 32 deleted after 11 retries

[mickym]

@peterfido Das ist in diesem Fall aber schlecht, da es nämlich genau das Problem darstellt, dass ich mit diesem Adapter als Broker habe. Diese Nachrichten werden einfach gelöscht und somit hast Du nicht mehr den aktuellen Status. Der Adapter kann einfach in bestimmten Fällen nicht mit dem ACK-Flag umgehen und man will eben nicht die Zustände schicken, um keine Endlosschleifen zu erzeugen.
In diesem Fall wirst Du halt nicht mitbekommen, was Dir Dein Shelly mitteilen wollte.

Ich rate Dir mosquitto zu installieren und diesen Adapter nur als Client zu betreiben. Das Problem scheint ja immer noch nicht behoben zu sein, wenn es immer noch vorkommt.

[peterfido]

@mickym
Hallo,

danke für den Tipp. Allerdings müsste ich dann noch einiges mehr umstellen. Besser wäre, wenn der Adapter da angepasst werden würde. Solange alles läuft, also die Shellys schalten, lasse ich es so, da ich damit leben kann.

OT:
Was mehr nervt ist der Hue-Adapter. Wobei es nicht am Adapter liegt. Die Bewegungsmelder melden sich in letzter Zeit sogar von der Hue-Bridge ab. Da überlege ich echt, ob ich die Hue-Geschichte wegen "teuer aber unzuverlässig" sein lasse.

[mickym]

@peterfido Ich halte den Umstellungsaufwand für gering. Die Shellies würden gar nicht mitbekommen, wenn Du jetzt schon über den MQTT-Adapter als Broker arbeitest. Und den MQTT Adapter verwendest Du ja als Client und hast deshalb die gleichen Datenpunkte - selbst dann unter der gleichen Instanz, sodass Du auch die gleichen Pfade im Blockly etc. hast.

Ich würde halt ein Backup / Image machen bzw. auf einer kopierten SD Karte oder Image das Ganze ausprobieren.

[peterfido]

@mickym

In letzter Zeit "zicken" die Shellies wieder rum. Per Easy E4 werden Taster abgefragt und dann in ioBroker "weiterverarbeitet". Die Tasterdrücke kommen in ioBroker an. Die Shellies schalten mal und mal nicht. Der Shelly-Adapter selbst bringt da leider auch keine Besserung.

Shellies sollen ja Probleme mit Unifi-Access-Point haben. Allerdings funktionieren die Shellies per Webinterface, sodass die Verbindungen an sich stehen. Auch Pings sind unauffällig. Neulich habe ich im Haus VDE0100 Prüfungen durchgeführt und die Shellies waren dadurch mehrfach stromlos (aber nicht so oft, dass sie zurückgesetzt werden). Anschließend ließen die sich gar nicht per mqtt Schalten. Erst ein Neustart des mqtt-Adapter brachte das wieder zum Laufen.

Hausautomation muss zuverlässig laufen. Wenn die Dame des Hauses oder die Jungs was schalten (wollen), und danach zu mir kommen und fragen, warum das gerade nicht geht, ist das schlecht.

Daher werde ich mal den Mosquitto probieren. Alternativ fliegen die 1-er Shellies raus. Mit den Shelly HT gibt es keine Probleme und auch ein ESP32, welcher per mqtt Temperaturen sendet, läuft zuverlässig. - Hm, evtl. könnte es reichen, wenn ich Tasmota auf die Shellies bügele.? Hat da jemand Erfahrungen?

[mickym]

@peterfido Ich nutze nur die Originalfirmware auf den Shellies, habe aber auch 3 Geräte (allerdings keine Shellies!!!) mit Tasmota im Einsatz. Alles läuft über mosquitto und dem MQTT-Adapter als Client im iobroker.

Habe sicher nicht soviele wie Du im Einsatz, aber sowohl Shell1, Shelly1PM, ShellyDimmer, Shelly2.5 und eine Menge Shell-PlugS im Einsatz und das tut absolut zuverlässig.

Der Umstellungsaufwand ist meines Erachtens gering, weil der mosquitto ja auf gleicher IP und Port läuft. Den MQTT Adapter auf client umstellen und alle Haken in der Konfig raus machen - das wars.

EDIT: Shellies sind nicht mit Tasmota geflasht

[peterfido]

@mickym

Die Umstellung ist ja wirklich einfach. Den Adapter auf Client gestellt, alle Haken raus.

Dann in der Konsole

sudo apt update
sudo apt install mosquitto mosquitto-clients

und schon läuft es.

Wären allerdings Benutzername und Passwort für mqtt eingerichtet gewesen, wäre es aufwändiger geworden.

Ich teste jetzt mal ein paar Tage.

Vielen Dank.

PS: Die Shellies auf Tasmota zu bringen wäre wesentlich aufwändiger. Das geht per OTA nicht. Zumindest habe ich kurz probiert und dann abgebrochen. Die BIN austauschen, SHAs neu berechnen und neben der neuen Größe in die manifest.json eintragen, hat nicht gereicht...

[mickym]

@peterfido die mosquitto-clients hätte es nicht unbedingt gebraucht und das mit den Benutzernamen ist easy.
Man erstellt eine Passwort-Datei mit Benutzer: Passwort Pärchen, lässt diese mit dem mosquitto eigenen Programm verschlüsseln und gibt das noch in der Konfigdatei an.

Aber brauchst ja nicht - aber falls gibt es genügend Anleitungen im Netz. (zum Beispiel: http://www.steves-internet-guide.com/mqtt-username-password-example/)

Aber das ist nicht unbedingt notwendig - zumindest zum Test. Wenn es dann zufriedenstellend läuft, kannst Du es später immer noch absichern.

[watcherkb]

@mickym @peterfido
Thread ist zwar etwas älter aber wollte für mein Problem nicht noch ein neues Thema erstellen.
Ich habe nun auch den mosquitto Server aufgesetzt. Im ioBroker mqtt pausiert und sehe auch im mosquitto log das dort messages reinkommen. Wenn ich jetzt im ioBroker die mqtt instanz auf "Client" umstelle, hat mosquitto ein Problem und sagt dass die Verbindung nicht mehr hergestellt werden konnte (oder so ähnlich, ich musste mosquitto wieder löschen da sonst mein mqtt im ioBroker nicht mehr lief). Also scheint es mir als ob der mqtt Adapter nicht korrekt auf "Client" wechselt und somit den Port 1883 weiterhin blockiert. Habt ihr eine Idee woran das liegen kann?

[mickym]

@watcherkb Hmm - er der Adapter muss halt nicht nur pausiert, sondern richtig umgestellt werden. Und halt schauen, dass sonst kein Adapter wie Shelly, Sonoff läuft. Die simulieren ja auch alle einen mqtt-Broker.

Der mqtt-Adapter muss ja auch 1883 laufen, das ist schon richtig.

Ich mosquitto log siehst Du doch auch ob sich der mqtt-Adapter (anhand der Client ID) mit mosquitto verbindet?

[watcherkb]

@mickym ja hab schon auf Client umgestellt. Aber keine Besserung.
Sonoff-Adapter habe ich auch, aber auf Port 1884
Und beim Shelly-Adapter ist der Port auf 1882

Leider sehe ich im Log nur die Clients und deren Messages, aber NICHT den Mqtt Client aus ioBroker.

[mickym]

@watcherkb Na wenn es wirklich so ist, dass der mqtt Adapter den Port 1883 sich schnappt und nichts anderes (also Du das merkst, wenn Du den Adapter aus und einschaltest, vielleicht muss man den Adapter ganz raus schmeissen und noch mal neu installieren. Es muss ja rauszufinden sein, wer den Port noch belegt.

[watcherkb]

@mickym hab jetzt nochmal mosquitto installiert, aber vorher mqtt Adapter gestoppt. Jetzt scheint auch alles zu laufen, aber die log-Datei sieht für mich nicht sauber aus. Ich nutze KEINE Authentification. Iobroker und der ganze Server ist dabei total ausgelastet, Ram und CPU sind am Limit.

1642433853: New client connected from 127.0.0.1 as iobroker.mqtt.0 (c1, k1000).
1642433853: Socket error on client iobroker.mqtt.0, disconnecting.
1642433853: New connection from 127.0.0.1 on port 1883.
1642433853: New client connected from 127.0.0.1 as iobroker.mqtt.0 (c1, k1000).
1642433856: Socket error on client iobroker.mqtt.0, disconnecting.

[mickym]

@watcherkb Ja aber dann ist da immer noch was nicht in Ordnung. Die log Datei ist nicht sauber - das schaut für mich aus, als ob da dauernd der mqtt Adapter andocken will aber nicht geht.

Hast Du explitzit in Deiner mosquitto conf angegen

allow_anonymous true