Wenn TCP/IP und HTTP/HTTPS läuft, kann es eigentlich nur an Konfigurationsproblemen liegen. Bei der Benutzung von Docker muss der MQTT-Port nach außen geleitet werden. Mit Tools wie mosquitto_sub und mosquitto_pub (gibt's auch für Windows) kann man beliebige Topics abonnieren bzw. veröffentlichen. Dann gibt es noch grafische Tools wie z. B. MQTT Explorer oder MQTT.fx. Leider kann ich weder zu Docker, noch zu IOB oder HA was sagen, weil ich all das nicht nutze. Zu MQTT im Allgemeinen habe ich was im Wiki hinterlassen.
Beiträge von JoergZ
-
-
Dann ist die Subskription beim Sonoff Adapter wohl hart kodiert. Oder gibt es eine Konfigurationsmöglichkeit?
-
das man eigene Fulltopic (z. B. HA/GA/TER/%topic%/%prefix%/) angeben kann, das finde ich übersichtlicher.
Das geht so: Du gehst auf den Tasmota-Geräten auf Einstellungen -> MQTT-Einstellungen und definierst im untersten Eingabefeld (full-topic) die Struktur, die du haben willst. Da kannst du ach harten Text eintragen oder Variablen (%topic%):
-
Eine andere Möglichkeit wäre es, über ein externes Skript die Temperatur im Sekunden Rhythmus abzufragen aber wie gesagt dazu muss extern ein Skript laufen. Andere Idee: du reduzierst die Abschalttemperatur so, dass deine Heizung eher abschaltet und mit Nachlaufzeit der Sollwert nicht überschritten wird.
-
OK, ich hatte es so verstanden, dass du Ergebnis nur im IOBroker beobachtet hast. Das, was du beschreibst, bleibt irritierend, aber wenn auf Port 1885 die Kommunikation läuft, würde ich dann einfach Broker und Clients auf 1885 umstellen. Der Port ist standardmäßig keinem bestimmten Dienst zugeordnet. Oder spricht etwas dagegen?
PS: Ich glaube dennoch, dass es eher ein Empfängerproblem (IOBroker) ist: Wenn die Geraäte über MQTT einen Status absetzen und dieser nicht im IOBroker ankommt/ausgewertet wird muss es m. E. am IOB liegen. Kannst du irgendwo in deinem Netz im Terminal einen MQTT-Client luafen lassen, der einfach nur am Broker auf alle Topics lauscht?
-
Teste do9ch erst einmal über die Konsole verschiedener Geräte, ob bei einem abgesetzten Kommando eine Statusmeldung generiert wird. Also wenn du auf der Konsole power1 1 eingibst, sollte eine Statusmeldung stat/MQTTNAME/RESULT = {"POWER":"ON"} und stat/Schalter/POWER = ON erscheinen oder bei Sensorabfragen nach status 8 auf der Konsole sollte so etwas wie stat/MQTTNAME/STATUS8 = {"StatusSNS":{"Time":"2023-03-20T17:30:52","DHT11":{"Temperature":6.0,"Humidity":95.0,"DewPoint":5.3},"TempUnit":"C"}} erscheinen. Dann weißt du zumindest, das Tasmota entsprechende Meldungen generiert und der Fehler wohl beim IOBroker steckt. Der Port dürfte eigentlich keinen Einfluss darauf haben, es sei denn es laufen mehrere MQTT-Broker, die auf unterschiedlichen Ports lauschen, die parallel im IOBroker oder außerhalb arbeiten.
-
Du kannst auch erst einmal einen Netzwerkscanner dein lokales Netz durchsuchen lassen. Mal schauen, welche Geräte der findet. Hast du vorher bestimmte IP-Bereiche in der FritzBox von DHCP ausgeklammert und wenn ja, hast du nun dieselben Einstellungen? Hast du mit der alten FritzBox mit der Funktion "Immer dieselbe IP-Adresse zuweisen" gearbeitet? Wenn ja, dann sind die Zuweisungen jetzt natürlich futsch und die Geräte haben andere IPs. Das fällt mir dazu noch ein...
-
Geht auch die gzip mini nicht?
-
z. B. Mycroft (oder Picroft): https://www.mycroft.ai setzte ich selbst ein mit einem selb geschriebenem Skill zur Steuerung von Tasmota-Geräten (via MQTT).
-
DeepSleep hilft dir da nicht weiter. WLAN kannst du in einer FritzBox zu gewünschten Zeiten schlafen legen. Aber dann versucht das Tasmota-Gerät immer noch ein WLAN zu erreichen und funkt wahrscheinlich mit einem Maximum an Leistung. Ich fürchte, du musst eine elektromechanische Zeitschaltuhr vor dem SV anbringen, die den Saft zwischen 22:45 und 06:00 (?) Uhr abdreht. Dann ist Ruhe - bis auf evt. mechanische Geräusche von dem Hardware-Timer...
-
Oder mit WSL (Windows Subsystem for Linux). Dann kann fast (alle) Terminalprogramme (mosquitto-clients, curl, wget, ...) unter Windows benutzen. Mittlerweile geht sogar ein grafischer Desktop. Aber wer braucht das schon
-
Mit nmap findet der raspi alle 12, aber bei allen bekomme ich Warning: 192.168.178.XX giving up on port because retransmission cap hit (2). gefolgt von
Das ist "normal", deshalb die Einschränkung der Kontaktversuche (--max-retries) auf zwei oder drei.
Nmap scan report for shellyXXX.fritz.box (192.168.178.XX) Host is up (0.0044s latency).
Not shown: 744 closed tcp ports (conn-refused), 255 filtered tcp ports (no-response)
PORT STATE SERVICE
8081/tcp open blackice-icecap
Das der Port 8081 offen ist, ist ungewöhnlich, kann aber eine Shelly-Besonderheit sein, eigentlich sollte an allen Geräten der Port 80 als offen gemeldet werden. Das ist der standardmäßige HTTP-Port. 8081 ist ein alternativer HTTP-Port.
Merkwürdig hoch ist auch der RTT-Wert (roundtrip time). Das deutet eher auf tiefer liegende Netzwerkprobleme (routing) hin. Schau mal in der Fritzbox nach, auf welchen Kanälen die WLAN-Netze funken. Steht die Kanalwahl auf auto? Wenn du manuelle Kanalwahl einstellst, dann sollten immer mindestens 4 Kanäle Abstand sein zwischen den Netzen. (Bei einem Mesh sollte alles automatisch geschehen.)
Kannst du die Gastnetze mal alle abschalten. Es sind einfach viele Netze auf engstem Raum. Das könnte ein häufiges Wiederholen von Paketen nach sich ziehen und die hohe Signallaufzeiten erklären.
Und zum letzten: Kannst du den Raspi mal ins Kellernetz einhängen und die Zeiten mit den Zeiten vom Wohnungsnetz und die Erreichbarkeit vergleichen. Mit folgendem Befehl kannst du die Messergebnisse aufzeichnen:
Damit schreibst du die Messergebnisse in die Datei test1.log. Bitte bei jedem Messdurchlauf den Dateinamen ändern (test2.log, test3.log, ...). Die Ping-Werte könntest du auf dieselbe Weise in Dateien speichern.
Sind die Shellys in Unterputzdosen hinter Steckdosen verbaut? Gibt es einen Potenzialausgleich zwischen Keller-Stromnetz und Wohnungs-Stromnetz. Powerline-Technik ist diesbezüglich ziemlich empfindlich, wie auch für andere Störungen, denn das Stromnetz ist eine riesige Antenne, die alles Mögliche einfängt. Meine Experimente mit Powerline in unserem Haus mit Marken- und No-Name-Geräten waren echt enttäuschend, sodass ich mehrere Router hängen habe. Zum Glück sind beim Bau des Hauses auch gleich genügend Cat. 5 Netzwerkkabel verlegt worden :-).
Auch mal beobachten, ob die Shellys sich häufig in andere Netze einwählen wollen.
-
Probieren geht über Studieren !!
Ein guter Tipp! Und nicht alles auf einmal probieren (verändern), sondern Schritt für Schritt, immer nur eine (1) Veränderung vornehmen und schauen, was passiert.
Dass es zu viele Geräte sind, glaube ich nicht.
Du hast einen Raspberry Pi im Betrieb. Installiere dort mal das Paket nmap und gib dann folgenden Befehl ein:
wobei 192.168.178.0 nur gilt, wenn die Fritzbox die IP 192.168.178.1 hat. Wenn du einen anderen Nummernkreis benutzt, muss man die Basis IP und die Netzmaske ändern. Siehst du alle Geräte aufgelistet? Die Zahl hinter --max-retries kannst du erhöhen, wenn Geräte fehlen. Aber bei 5 sollten alle Geräte funktionieren.
(Du kannst natürlich auch alle Geräte mal versuchen anzupingen. Es geht hier zunächst einmal nur um die schnöde Erreichbarkeit ohne weitere Protokoll- und Port-Finessen.)
(Wenn nmap nicht alle Geräte anzeigt, dann mal mit dem Raspi in den Keller gehen und ans PowerLine anhängen und dasselbe nochmal machen. Gibt es Unterschiede?)
Hast du 5 Ghz überall abgeschaltet?
Ist das Powerline Gerät wirklich tranparent im Mesh oder vielleicht doch als AccessPoint mit eigenen DHCP-Server installiert?
Auch die Antwort auf die Frage von Noschvie wäre hier von Interesse....
-
Es "riecht" eher nach einem IP- oder DNS-Problem. Ist irgendein zweiter DHCP-Server aktiv? Eventuell ist das dein PowerLan Adapter. Dann hast du vermutlich zwei Netze. Vielleicht hilft es alle Geräte neu zu starten. Am besten mit dem Power-Lan Gerät anfangen. Ich hoffe die Shellys sind nicht alle tief verbaut sondern lassen sich gut erreichen. Also am besten Strom abklemmen, ein paar Sekündchen warten und Strom wieder auflegen. Kannst du dich mit einem Handy in das Keller-WLAN einbuchen und ist das Internet (oder die Shellys) dann erreichbar (Es muss aber sichergestellt ein, dass du die WLAN-Verbindung nutzt und nicht die Mobilfunkverbindung.) Ist im Stromkreis des Kellers ein neues Elektrogerät hinzugekommen, dass evt. Störsignale in die Stromleitung sendet? Kannst du im Keller-WLAN bzw. im anderen WLAN mal einen Gerätescan bzw. Portscan machen. Welche IP-Mummern sind in den beiden Netzen belegt?
-
Jede Hausautomatisierungssoftware (IOBroker, Homeassistent, Domoticz, etc.) kann so etwas. Eigenes Skript schreiben, wenn es nur um dieses einzelne Gerät geht, geht auch.
-
Nicht dass ich wüsste. Da musst du dir selbst eine Lösung mit irgend einer Programmiersprache basteln.
-
Klar geht das:
http://192.168.2.60/cm?cmnd=status%208. Im Firefox wird es dir dann als recht gut aufbereitetes JSON angezeigt. Weiß aber nicht, wie das mit Edge oder anderen Browsern aussieht.
-
sondern meine feste, vom Provider zugeteilte IP:Port (Port der im Router freigegeben ist)? Und der Router leitet automatisch auf den Pi mit der IP im Netz (192.....)?
Müsste so funktionieren (habe ich allerdings selbst noch nie angewendet
)
-
Error: Wind: Invalid/Unhandled data received! (Topic: domoticz/in, Message: 9.48)
Es scheint ja was gesendet zu werden. Was sagt denn die Tasmota-Konsole dazu? Kopier doch da mal die Sensormeldung (müsste über die Eingane status 8 abrufbar sein) bzw. den Strinmg, der an Domoticz gesendet wird.
-
den Windmesser mit diesen Script
In Domoticz Protokoll kommen die Werte an.
Kannst du mal den Inhalt von "Script" und "Protokoll" - also die relevanten Abschnitte - posten. Das könnte bei der Lösungssuche helfen.
EDIT: Wenn mit Script das Script von premo gemient ist, brauchst du das nicht zu posten.