Habe Schwierigkeiten mit Shelly und MQTT2

Begonnen von Zrrronggg!, 06 November 2026, 19:59:54

Vorheriges Thema - Nächstes Thema

Zrrronggg!

Bin Anfänger was MQTT2 betrifft. (bin eigentlich bei allem Anfänger  ;D  )

Idee: Shelly EM Mini Gen4 per MQTT einbinden
FHEM lauft auf RPI mit 192.169.198.68

Zuerst MQTT2_SERVER definiert,

define MQTTSERV MQTT2_SERVER 1883 global
attr MQTTSERV autocreate simple

FHEM zeigt ihn als "initialised"

Ausserdem:
define autocreate autocreate
attr autocreate device_room %TYPE
attr autocreate filelog test2/log/%NAME-%Y.log
attr autocreate weblink
attr autocreate weblink_room Plots

Shelly hat 192.168.198.126, MQTT aktiviert, IP des Servers mit Port eingetragen, kein allow, kein SSL, dann Shelly reboot



An sich sollte es jetzt losgehen wenn ich alles richtig kapiert habe, aber:

Es wird nix autocreated.
Show MQTT traffic zeigt nichts.

auf RPI tcpdump installiert
sudo tcpdump -ni any port 1883 and host 192.168.198.126 wie gesagt: 126 ist der Shelly, 68 der FHEM server. 
Output ist:
19:27:48.825084 eth0  In  IP 192.168.198.126.61427 > 192.168.198.68.1883: Flags [S], seq 849634628, win 5760, options [mss 1440], length 0
19:27:48.825197 eth0  Out IP 192.168.198.68.1883 > 192.168.198.126.61427: Flags [S.], seq 19797658, ack 849634629, win 64240, options [mss 1460], length 0
19:27:48.827687 eth0  In  IP 192.168.198.126.61427 > 192.168.198.68.1883: Flags [P.], seq 1:85, ack 1, win 5760, length 84
19:27:48.827801 eth0  Out IP 192.168.198.68.1883 > 192.168.198.126.61427: Flags [.], ack 85, win 64156, length 0
19:27:48.829209 eth0  Out IP 192.168.198.68.1883 > 192.168.198.126.61427: Flags [R.], seq 1, ack 85, win 64156, length 0

Ich bin Laie - aber interpretiere das so, dass es zwar gut losgeht, aber der FHEM Server dann anstatt CONNACK ein reset sendet: Flags [R.]


Wieso könnte FHEM das machen? Oder interpretiere ich falsch? Was kann ich testen? Sonstige Vorschläge?

FHEM auf RPi3B+, CUL 868 SlowRF, 2xCUL 868 RFR, 2x CUL 433 für IT, 2xHMLAN Configurator  + USB_HmUART mit VCCU, ITV-100 Repeater, Sender, Sensoren und Aktoren von FS20, S300, HM, IT, RSL, Blink

Beta-User

Falls fhem aktuell ist und es die Option auf dem Shelly gibt, MQTT V. 3.1.1 zu aktivieren, versuche es mal damit.
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Zrrronggg!

#2
Angeblich machen Shelly Gen4 Geräte MQTT V3.1.1, was anderes einstellen oder konfigurieren kann man aber sowieso nicht (man kann nicht mal den Shelly abfragen, welche MQTT Version er unterstützt

Das FHEM Log sagt dazu übrigens:

Connection refused from the non-local address 192.168.198.126:55803, as there is no working allowed instance defined for it
Hm. Das sieht nach einem allowed-Thema aus. Ich habe da nur nix definiert und dann sollte ... moment ich check nochmal die cfg falls ich eine Erinnerungslücke haben sollte ... stimmt: nichts mit allowed.

Soweit ich weiss heist "nix configuriert" doch allow alles und jede IP. Oder?
Security Check sagt auch
WebGUI is not password protected
telnetPort is not password protected
MQTTSERV is not password protected
FHEM auf RPi3B+, CUL 868 SlowRF, 2xCUL 868 RFR, 2x CUL 433 für IT, 2xHMLAN Configurator  + USB_HmUART mit VCCU, ITV-100 Repeater, Sender, Sensoren und Aktoren von FS20, S300, HM, IT, RSL, Blink

rudolfkoenig

ZitatConnection refused from the non-local address 192.168.198.126:55803, as there is no working allowed instance defined for it

192.168.198.126 ist eine lokale Adresse, und soweit ich sehe, die Pruefung in TcpServerUtils.pm (Zeile 277 und Folgende) prueft das auch richtig.
Auch der explizite Test dieses Wertes in der FHEM Eingabezeile liefert 1 mit
fhem> { my $re="^(::ffff:)?(127|192.168|172.(1[6-9]|2[0-9]|3[01])|10|169.254)\\.|^(f[cde]|::1)";; "192.168.198.126"=~m/$re/ }
1
Dieser RegExp ist im Code seit 9 Jahren unveraendert, womoeglich liegt es an deiner perl Version?

Zrrronggg!

#4
Nein es liegt womöglich an einer Mischung aus: Ich habe euch angelogen und die commandref ist - äh - ggf nicht so eindeutig.

Konkret: Ich nutze keine PrivateIPs sondern ich habe ein Class-C /24
Ich habe in meinem Beispiel eine Zahl geändert, weil ich natürlich nicht direkt sagen will welches Netz das ist.
D.H. die die Geräte sind *nicht* in einem private IP Netz.

In der Commandref ist das meiner Auffassung nach nicht so gut dargestellt.
Da heisst es zwar:
ZitatNotes:
to set user/password use an allowed instance and its basicAuth feature (set/attr)

Aber nicht, dass man das machen muss, weil sonst gar nix geht, falls das Netz nicht PrivatIP ist.
Ich hatte nach
ZitatIf global is specified, then requests from all interfaces (not only localhost / 127.0.0.1) are serviced
den Eindruck, dass global und keine allowed instance bedeutet, dass jedes Geräte ohne name/PW kommunizieren kann. Klar, das steht da streng genommen nicht, aber da steht eben auch nicht, das man eine allowed Instanz machen *muss* weil sonst abgelehnt wird.  Auch im Wiki steht immer nur "kann" aber nicht "muss".

Okay, sicher mein Fehler, aber ggf kann man das in der Commandref nochmal erwähnen.

So, allowed angelegt.
Und dann kommt zumindest schon mal
Global global UNDEFINED shellyemminig4_d885acf108f9 MQTT2_DEVICE shellyemminig4_d885acf108f9 MQTTSERV


Und Autocreate geht trotzdem noch nicht, aber da kümmer ich mich morgen drum.

Eure Antworten haben mich trotzdem auf die richtige Spur gebracht, danke.
FHEM auf RPi3B+, CUL 868 SlowRF, 2xCUL 868 RFR, 2x CUL 433 für IT, 2xHMLAN Configurator  + USB_HmUART mit VCCU, ITV-100 Repeater, Sender, Sensoren und Aktoren von FS20, S300, HM, IT, RSL, Blink

rudolfkoenig

ZitatNun ist es offenbar so, dass Telnet und WebGUI keine Problem damit haben, Anfragen ohne Allowed zu beantworten, wenn das Netz lokal ist, also zwar kein PrivateIP aber die Anfrage aus der gleichen /24 kommt.
MQTT2_SERVER verhält sich aber offenbar anders, hier braucht's soweit ich das sehe eine allowed Instanz, wenn das Netzwerk aus dem die Anfragen kommen kein privateIP ist, selbst wenn FHEM-Server und Shelly im selben Netz sind.
Negativ: alle drei Module nutzen die gleiche Funktion aus TcpServerUtils.pm.
Eine Pruefung auf sowas wie "im selben Netz" findet nicht statt.

ZitatUnd Autocreate geht trotzdem noch nicht, aber da kümmer ich mich morgen drum.
Liegt vmtl. an dem abgeschalteten autocreate Instanz.
Das autocreate Attribut fuer MQTT2_SERVER regelt eher Feinheiten, und man braucht es nicht zu setzen.

Zrrronggg!

#6
Du hast recht... ich war "früher mal"TM schlauer als heute und hatte ein allowfrom auf WebGUI gesetzt. Daher hab ich den Post schnell geändert, aber du warst schneller. ;)

Darf ich trotzdem anregen in der commandref hinter
Attributes
• allowfrom
kurz zu schreiben das man das z.b. setzen muss wenn man keine PrivateIP nutzt? So wie es auch bei FHEMWEB steht?

ZitatLiegt vmtl. an dem abgeschalteten autocreate Instanz.

Korrekt. Die hatte ich zwar extra installiert vor meinem MQTT Experimenten, aber dann im laufe der Test irgendwann versehentlich abgeschaltet. Dass autocreate in MQTT2 default auf simple steht (was für mich wohl ausreicht) hatte ich geschnallt.
FHEM auf RPi3B+, CUL 868 SlowRF, 2xCUL 868 RFR, 2x CUL 433 für IT, 2xHMLAN Configurator  + USB_HmUART mit VCCU, ITV-100 Repeater, Sender, Sensoren und Aktoren von FS20, S300, HM, IT, RSL, Blink