Beiträge von JoergZ

Hab mich ein wenig mit threading und Event befasst. Damit geht es auch. Und ist mehr pythonic

Danke für den Hinweis! Ich hatte auch schon Fälle, wo MQTT benutzbar war, obwohl die Weboberfläche nicht erreichbar war. Meistens hatte der MQTT Trigger dann auch den Effekt, dass anschließend das WebUI wieder lief. Da ich sowieso den MQTT-Skill noch einmal anfassen werde, wird es auch eine MQTT basierende Lösung für OVOS geben.

Doch, doch, den Skill habe ich schon. Steht auch online (für Mycroft). Aber HTTP bzw. die urllib3 Bibliothek von Python lässt sich einfacher handeln, weil sie einer Unterfunktion in einem anderen Skript ist. paho-mqtt ist da eigenwilliger und will gerne die Macht haben. Letztendlich werde ich beide Tasmota Skills für OVOS fertig machen und online stellen.

Danke euch! Falls es auch interessiert wofür ich das mache: Ich habe mich seit einigen Jahren mit Mycroft (mycroft.ai) beschäftigt und nachdem dieses Projekt Anfang des Jahres leider eingestellt wurde zu dessen Fork OVOS - OpenVoice Operating System (https://github.com/OpenVoiceOS) gewechselt. Für den internen Gebrauch habe ich ein paar Skills geschrieben, die ich gerade für OVOS anpasse und überarbeite (man wird ja nicht dümmer, wenn man programmiert), so z. B. für Tasmota weg von MQTT hin zur Steuerung mittels HTTP. Das funktioniert schon ganz gut für einfache Befehle wie an/aus (Hey Mycroft, schalte den Drucker ein), Abrufen (und ansagen lassen) von Sensordaten (Hey Mycroft, wie sind die Sensordaten vom Außenthermometer) oder Abrufen von aktivierten Zeitplänen. Mit anderen Skills steuere ich mein(e) MPD-Radio(s), meinen Samsung Fernseher und fülle eine Sqlite-Datenbank mit Informationen, wo ich mal wieder meine Werkzeuge und Materialien hingelegt habe. Wie gesagt, bei Interesse schickt mir eine PM. Ich will das Forum hier nicht für andere Projekte (weiter) missbrauchen.

Besten Dank erst einmal. Hat vielleicht noch jemand ein Beispiel für eine steuerbare LED-Leuchtmittel mit RGB-Werten oder für ein WS2812B LED-Lichtband.

mafrei und efanst : Wofür steht der Parameter Illuminance? Für Helligkeit? 0 - 100 oder 0 bis 255?

Für ein Sprachsteuerungsprojekt für Tasmota-Firmware hätte ich gern ein paar Beispiele der JSON-Messages, die man mit status 10 abrufen kann. Ich selbst habe nur zwei Umweltsensoren DHT11 und SI7021. Es gibt noch ein paar mehr, z. B. welche die auch den Luftdruck ausgeben. Mich würde es auch interessieren, welche payloads von Bewegungssensoren abgegeben werden. Außer Temperatur und Luftfeuchtigkeit habe ich noch den Energiesensor vom Sonoff POW. Hier ein paar Beispiele was ich meine:

Sensorwerte des DH11 abgefragt mit status 10 auf der Konsole:

{"StatusSNS":{"Time":"2023-10-13T15:18:46","DHT11":{"Temperature":13.0,"Humidity":95.0,"DewPoint":12.2},"TempUnit":"C"}}

Sensorwerte des SI7021:

{"StatusSNS":{"Time":"2023-10-13T15:20:39","SI7021":{"Temperature":21.1,"Humidity":93.8,"DewPoint":20.1},"TempUnit":"C"}}

Sensorwerte Sonoff POW:
{"StatusSNS":{"Time":"2023-10-13T14:19:51","ENERGY":{"TotalStartTime":"2023-02-10T14:53:27","Total":1.070,"Yesterday":0.101,"Today":0.060,"Power":4,"ApparentPower":16,"ReactivePower":15,"Factor":0.27,"Voltage":237,"Current":0.066}}}

Wer kann mir noch ein paar Beispiele anderer Sensoren (Umwelt, Bewegung, Tür-/Fenstersensoren, Geräusche, etc) liefern?

Auch Daten der einer Lichtsteuerung (Abfrage der Einstellungen) wären interessant für mich. Bitte immer den Namen des Sensors oder was auch immer zur Geräteidentifizierung benutzt wird, mit angeben! Danke!

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.

Dann ist die Subskription beim Sonoff Adapter wohl hart kodiert. Oder gibt es eine Konfigurationsmöglichkeit?

Zitat von Bulli1308

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

Zitat von nahno

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.

Zitat von nahno

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:

 nmap [IP...] --max-retries=2 >test1.log

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.

Zitat von premo

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:

 nmap 192.168.178.0/24 --max-retries=2

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?