MQTT2_SERVER und QoS

Begonnen von arthur_dent_2015, 20 September 2018, 19:43:05

Vorheriges Thema - Nächstes Thema

psycho160

Konnte das Problem nun beheben, indem ich bei dem MQTT2_Client (der die instabile LTE Anbindung hat) nur jene Topics aboniere die wirklich nötig sind und nicht alle was der Server publisht.
Vermutlich hat sich der Client dann immer mal verabschiedet wenn er so viele Messages bekam (aufgrund von # als default). Weiß aber nicht ob das vor der Erweiterung von Rudi auch schon so war oder nicht, auf jeden Fall läuft es nun seit gestern was gut aussieht.
- 2013@FHEM - 2020 Setup: Pi 4 4GB Systeme: Shelly, Tasmota, Zigbee und mittlerweile nur noch wenig Homematic. Entwicker von: tado-FHEM Modul (perlcritic 3 ^^)(https://git.wolfmajer.at/Public/FHEM-Tado)

rudolfkoenig

Ich habe meinen Zweifel, dass das Problem mit der QoS Aenderung zu tun hat.
Laut Log schaut es so aus, dass in den Datenstrom Muell reinkommt.
Eine Moeglichkeit dafuer waere, dass der Zwischenpuffer beim Verbindungsaufbau nicht initialisiert wird.
Ich habe das nachgeholt und eingecheckt.

Die uebertragene Datenmenge zu reduzieren kann nie schaden, insb. bei einer wackeligen Leitung.

Fuchsbau

Hallo,
habe versucht das Attribut "qosMaxQueueLength"  auf MQTT2_Client zu setzten. Bekomme aber nur:
- MQTT2_MQTT2Client: unknown attribute qosMaxQueueLength. Type 'attr MQTT2_MQTT2Client ?' for a detailed list. -

Mache ich das, bekomme ich:

MQTT2_MQTT2Client: unknown attribute ?, choose one of alias comment eventMap group room suppressReading userReadings verbose IODev autocreate bridgeRegexp devicetopic devPos disable disabledForIntervals getList imageLink jsonMap model periodicCmd readingList setExtensionsEvent setList setStateList event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat timestamp-on-change-reading ASC DbLogExclude DbLogInclude DbLogValueFn cmdIcon devStateIcon devStateIcon devStateStyle icon msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType sortby webCmd webCmdLabel widgetOverride userattr

Die ersten Zeilen der 00_MQTT2_CLIENT.pm meiner FhemInstallation:
##############################################
# $Id: 00_MQTT2_CLIENT.pm 22454 2020-07-23 16:36:36Z rudolfkoenig $
package main;

use strict;
use warnings;
use DevIo;

sub MQTT2_CLIENT_Read($@);
sub MQTT2_CLIENT_Write($$$);
sub MQTT2_CLIENT_Undef($@);
sub MQTT2_CLIENT_doPublish($@);
sub MQTT2_CLIENT_Disco($;$$);

# See also:
# http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html


Das ist augenscheinlich die neueste Version mit dem Attribut "qosMaxQueueLength".

Was kann man hier falsch machen?

RPI4/4GB / 120Gb SSD (boot)
Conbee 2 / Tasmota (div SONOFF und Eigenbau ESP8266) / Shellys (3EM, 1PM, 1, 2.5) / nanoCUL (Homematic Fensterkontakte)

rudolfkoenig

Dein MQTT2_MQTT2Client scheint ein MQTT2_DEVICE zu sein.
Ansonsten kann man noch etliches falsch machen, z.Bsp FHEM nach dem update nicht neu starten.

Fuchsbau

jo,  ??? dem ist so.

Danke, für die schnelle Antwort.
RPI4/4GB / 120Gb SSD (boot)
Conbee 2 / Tasmota (div SONOFF und Eigenbau ESP8266) / Shellys (3EM, 1PM, 1, 2.5) / nanoCUL (Homematic Fensterkontakte)