Monatsrückblick Januar/Februar 2026 ist online!

[Homoran]

@Zerpmaster gut.
also wie ich vermutet hatte geht es um den mqtt-Adapter.

Wie ist der Deckenfluter_Stube angebunden?
dort steht invalid messageID.

Ist der MQTT.0 als Broker konfiguriert?

[Zerpmaster]

Auf dem Iobroker läuft der MQTT als Server,

Aktuell habe ich zum Testen kein Username und PW drin.

Das gleiche Problem tritt auch beim Terrarium auf.

mqtt.0	2019-03-10 19:38:51.635	info	Client [DeckenfluterStube] connection closed: Error: Invalid messageId
mqtt.0	2019-03-10 19:38:51.605	info	Client [DeckenfluterStube] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:51.605	info	Client [DeckenfluterStube] subscribes on "cmnd/DeckenfluterStube_fb/#" with regex /^mqtt\.0\.cmnd\.DeckenfluterStube_fb\..*/
mqtt.0	2019-03-10 19:38:51.605	info	Client [DeckenfluterStube] subscribes on "cmnd/DeckenfluterStube_fb/#" with regex /^cmnd\.DeckenfluterStube_fb\..*/
mqtt.0	2019-03-10 19:38:51.595	info	Client [DeckenfluterStube] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:51.595	info	Client [DeckenfluterStube] subscribes on "cmnd/sonoffs/#" with regex /^mqtt\.0\.cmnd\.sonoffs\..*/
mqtt.0	2019-03-10 19:38:51.595	info	Client [DeckenfluterStube] subscribes on "cmnd/sonoffs/#" with regex /^cmnd\.sonoffs\..*/
mqtt.0	2019-03-10 19:38:51.585	info	Client [DeckenfluterStube] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:51.585	info	Client [DeckenfluterStube] subscribes on "cmnd/DeckenfluterStube/#" with regex /^mqtt\.0\.cmnd\.DeckenfluterStube\..*/
mqtt.0	2019-03-10 19:38:51.584	info	Client [DeckenfluterStube] subscribes on "cmnd/DeckenfluterStube/#" with regex /^cmnd\.DeckenfluterStube\..*/
mqtt.0	2019-03-10 19:38:51.534	info	Client [DeckenfluterStube] connected with secret 1552243131522_6370
mqtt.0	2019-03-10 19:38:51.370	info	Client [Terrarium] connection closed: Error: Invalid messageId
mqtt.0	2019-03-10 19:38:51.342	info	Client [Terrarium] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:51.342	info	Client [Terrarium] subscribes on "cmnd/Terrarium_fb/#" with regex /^mqtt\.0\.cmnd\.Terrarium_fb\..*/
mqtt.0	2019-03-10 19:38:51.342	info	Client [Terrarium] subscribes on "cmnd/Terrarium_fb/#" with regex /^cmnd\.Terrarium_fb\..*/
mqtt.0	2019-03-10 19:38:51.332	info	Client [Terrarium] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:51.332	info	Client [Terrarium] subscribes on "cmnd/sonoffs/#" with regex /^mqtt\.0\.cmnd\.sonoffs\..*/
mqtt.0	2019-03-10 19:38:51.332	info	Client [Terrarium] subscribes on "cmnd/sonoffs/#" with regex /^cmnd\.sonoffs\..*/
mqtt.0	2019-03-10 19:38:51.322	info	Client [Terrarium] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:51.322	info	Client [Terrarium] subscribes on "cmnd/Terrarium/#" with regex /^mqtt\.0\.cmnd\.Terrarium\..*/
mqtt.0	2019-03-10 19:38:51.320	info	Client [Terrarium] subscribes on "cmnd/Terrarium/#" with regex /^cmnd\.Terrarium\..*/
mqtt.0	2019-03-10 19:38:51.268	info	Client [Terrarium] connected with secret 1552243131267_3689
mqtt.0	2019-03-10 19:38:51.139	info	Client [PoolPumpe] connection closed: Error: Invalid messageId
mqtt.0	2019-03-10 19:38:51.036	info	Client [PoolPumpe] connected with secret 1552243131036_7253
mqtt.0	2019-03-10 19:38:50.618	info	Client [DeckenfluterStube] connection closed: Error: Invalid messageId
mqtt.0	2019-03-10 19:38:50.593	info	Client [DeckenfluterStube] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:50.593	info	Client [DeckenfluterStube] subscribes on "cmnd/DeckenfluterStube_fb/#" with regex /^mqtt\.0\.cmnd\.DeckenfluterStube_fb\..*/
mqtt.0	2019-03-10 19:38:50.593	info	Client [DeckenfluterStube] subscribes on "cmnd/DeckenfluterStube_fb/#" with regex /^cmnd\.DeckenfluterStube_fb\..*/
mqtt.0	2019-03-10 19:38:50.582	info	Client [DeckenfluterStube] publishOnSubscribe send all known states
mqtt.0	2019-03-10 19:38:50.582	info	Client [DeckenfluterStube] subscribes on "cmnd/sonoffs/#" with regex /^mqtt\.0\.cmnd\.sonoffs\..*/
mqtt.0	2019-03-10 19:38:50.582	info	Client [DeckenfluterStube] subscribes on "cmnd/sonoffs/#" with regex /^cmnd\.sonoffs\..*/
mqtt.0	2019-03-10 19:38:50.571	info	Client [DeckenfluterStube] publishOnSubscribe send all known states

Und die PoolPumpe ist eben auch im Log erschienen.

[Homoran]

@Zerpmaster

Bitte code als code markieren - habe ich eben für dich gemacht.

bleibt die Frage wie der Broker an die Daten kommt?
Die MQTT-Einstellungen hast du nicht gezeigt.

Ist publish on subscribe gewollt?

[Zerpmaster]

Ich bin noch Anfänger.

Hier die Einstellungen vom MQTT im Iobroker

Hier die Einstellungen vom Teckin SP 22 Tasmota (Deckfluter undTerrarium)

was meinst du mit "Ist publish on subscribe gewollt?"

[Zerpmaster]

kann mir keiner helfen?

Mein Log schreibt sich mega voll

[Wildbill]

Hi,

da Du Tasmota verwendest kann ich Dir nur den Tipp geben, anstatt des MQTT-Adapters den Sonoff-Adapter im iobroker zu verwenden. Der erstellt alle benötigten Datenpunkte und läuft problemlos. Geht aber auch nur mit Tasmota-Geräten. Der Topic sollte dann aber AFAIK sonoff lauten. Falls Du noch andere Geräte via MQTT bedienst, dann musst Du bei einem Adapter (und den entsprechenden Geräten) einen anderen Port wählen, da der MQTT-Adapter und Sonoff-Adapter standardmäßig den gleichen Port verwenden (sind ja beide MQTT, der Sonoff nur spezialisiert).

Alternativ könntest Du auch mal versuchen, im iobroker-MQTT-Adapter und dann auch im Tasmota-Gerät einen User und Passwort einzutragen, vielleicht beisst sich da schon was mit dem DVES_USER.

Gruss, Jürgen

[chrisblu]

Hallo Zusammen,
ich denke, ich habe das gleiche Problem, das Zerpmaster anspricht, dass sich das Log ohne Ende füllt. Allerdings nicht mit Sonoff, sondern einem selbst erstelltem ESP8266 Sensor, dem ich gleichzeitig einen Pin zum schalten (derzeit Buildtin-Led) mitgegeben habe.
Ich verwende auch den Standart MQTT-Adapter

Der Codeschnippsel sieht so aus:

#define led_switch "NodeMCU1/LED_Switch" 
...
void loop() {
...
if (now - lastRecu > 100 ) {
    lastRecu = now;
    client.subscribe(led_switch);
  }
...
}

Es wird also alle 100ms der Status des led_switches abgefragt.
Soweit funktioniert das auch alles super, aber alle 100ms werden 2 Zeilen von der mqtt.0 info in das Log vom iobroker geschrieben, so dass das Log über Nacht von 0 auf 28 MB angewachsen ist:

2019-03-20 00:00:00.134  - [32minfo [39m: mqtt.0 Client [ESP8266Client-a857] subscribes on "mqtt.0.NodeMCU1.LED_Switch"
2019-03-20 00:00:00.134  -  [32minfo [39m: mqtt.0 Client [ESP8266Client-a857] publishOnSubscribe
2019-03-20 00:00:00.235  -  [32minfo [39m: mqtt.0 Client [ESP8266Client-a857] subscribes on "mqtt.0.NodeMCU1.LED_Switch"
2019-03-20 00:00:00.235  -  [32minfo [39m: mqtt.0 Client [ESP8266Client-a857] publishOnSubscribe
2019-03-20 00:00:00.336  -  [32minfo [39m: mqtt.0 Client [ESP8266Client-a857] subscribes on "mqtt.0.NodeMCU1.LED_Switch"

Kann man das verhindern? Mache ich beim Subscribe etwas falsch?

Vielen Dank für Eure Hilfe,

Christian

[Wildbill]

Hi,

Du könntest auch den MQTT-Adapter (auf der Adapter-Seite im iobroker) so einstellen, dass er nur noch errors loggt. Dann kommen bei normalen Vorgängen keine Einträge mehr ins Log.

Aber, ist alle 100ms nicht etwas sehr oft? Da kommen die Daten ja kaum mit dem Fliessen hinterher.

Gruss, Jürgen

Edit: Es ist die Instanzen-Seite!

[chrisblu]

Hallo Jürgen,
danke für den Tipp, dass mit den Errors loggen werde ich mal ausprobieren.
Und über den Intervall habe ich mir auch schon Gedanken gemacht. Ich hatte da ein bestehendes Beispiel übernommen. 1-2 sec werden auch reichen.
Aber das zeigt ja auch, dass hier ständig etwas Traffic über die Verbindung fließt. Das ist wohl ein Problem von dem MQTT-Protokoll, oder? Weil man könnte das Gerät ja vielleicht bei Änderung anpingen, anstatt ständig einen Status abzufragen.
Viele Grüße,
Christian

[Wildbill]

Naja, jede Anfrage per MQTT erzeugt natürgemäß Traffic. iobroker sendet Anfrage --> Gerät antwortet. Und das dann alle 100ms ist schon etwas deftig...

Aus eigener Erfahrung kann ich nur sagen, dass sinnvolle Trigger auf irgendwelche Änderungen einem permanenten Abfragen (CRON oder sowas) und notfalls stoppen immer vorzuziehen sind!
Ersteres macht gar nix, solange die Trigger-Bedingung nicht erfüllt ist. letzteres erzeugt permanent Anfragen oder löst Dinge aus, die dann doch wieder gestoppt werden oder einen Wert aktualisieren, der sich gar nicht geändert hat. Und das dann ins Log schreiben...

Gruss, Jürgen

[paul53]

@Wildbill sagte:

so einstellen, dass er nur noch errors loggt.

Alle Instanzen - außer Javascript - auf "Warning" reduziert die Zahl der Log-Einträge enorm. In meinem Produktiv-System sind es nur noch 3 Einträge pro Tag.

[chrisblu]

Hallo Zusammen,
danke nochmal für Eure Hilfe. Der Tipp mit den Warnings ist auch super.
Ich konnte das Problem aber ohne Änderung des Loglevels beheben.
Ich habe wohl ein ungünstiges Beispiel als Vorlage für mein Projekt verwendet. Ich habe herausgefunden, dass es reicht, den client.subscribe nur einmal nach Anmeldung am MQTT-Server aufzurufen anstatt in der Schleife.. Nachdem ich das geändert hatte, gab es nur noch drei Zeilen im Log von meinem Sensor.
Viele Grüße,
Christian