openhabforum.de

Ich bin da nicht so firm in der Materie. Ich kenn das auch nur von Tasmota und das wiederum habe ich von Udo gelernt

. Der ist da eigentlich der Crack.

Was mir dazu aber noch einfällt; du kannst ja mal schauen was da in "mqtt.fx" "subscribt" wird, wenn du dein Topic mit Payload "publischst".

Das sieht bei mir dann so aus, wenn ich das Relais einschalte(ON = 1) :

pubsub.jpg

und im mqtt.LOG

Code: Alles auswählen

2021-07-18 10:14:40,224  INFO --- MqttFX ClientModel             : attempt to add PublishTopic
2021-07-18 10:14:40,225  INFO --- MqttFX ClientModel             : sucessfully published message 1

 to topic cmnd/esp32_01/POWER1 (QoS 0, Retained: false)
2021-07-18 10:14:40,225  INFO --- MqttFX ClientModel             : messageArrived() with topic: cmnd/esp32_01/POWER1
2021-07-18 10:14:40,225  INFO --- MqttFX ClientModel             : messageArrived() added: message #110 to topic 'cmnd/esp32_01/POWER1'
2021-07-18 10:14:40,340  INFO --- MqttFX ClientModel             : messageArrived() with topic: stat/esp32_01/RESULT
2021-07-18 10:14:40,341  INFO --- MqttFX ClientModel             : messageArrived() added: message #111 to topic 'stat/esp32_01/RESULT'
2021-07-18 10:14:40,381  INFO --- MqttFX ClientModel             : messageArrived() with topic: stat/esp32_01/POWER1
2021-07-18 10:14:40,381  INFO --- MqttFX ClientModel             : messageArrived() added: message #112 to topic 'stat/esp32_01/POWER1'

Vielleicht kannst du daraus was ableiten.

Danke udo1toni und peter-pan

Auf dem ersten Blick ist das einleuchtend, wenn Befehl empfangen dann Vollzug melden das was angekommen ist. Ich verstehe aber noch nicht, wie das mein Problem löst, dass manchmal nicht gesendet wird, obwohl der virtuelle Schalter umgeschaltet wurde.

Mal angenommen, der ESP existiert noch nicht und kann entsprechend keinen Vollzug melden. Dann habe ich nur die Möglichkeit mit MQTT.fx zu prüfen, ob etwas auf dem Kanal gesendet wurde, wenn der virt.Schalter umgeschaltet wird. So prüfe ich das derzeit auch und manchmal kommt nichts an

Habe ich das vielleicht doch noch falsch verstanden, dass der Vollzug (publish) nicht vom ESP sondern irgendwo anders gemeldet wird

Vielen Dank für Eure Geduld mit mir

KiWi22 hat geschrieben: ↑18. Jul 2021 15:17 ESP sondern irgendwo anders gemeldet wird

Ich denke schon, dass der Status vom ESP(-Channel) kommt, aber an diesem Channel muss auch ein Schalter(Relais) hängen. Der ESP kann dir ja nichts melden, wenn keine Pins(GPIOS) angesprochen(adressiert) werden.

Die Rückmeldung kommt vom Client. Wenn es richtig konfiguriert ist, wird zwar z.B. ein ON-Befehl gesendet, anschließend springt die Anzeige aber wieder auf OFF zurück, weil kein ON-Status empfangen wurde. Wenn Du dann in mqtt.fx den korrekten Status sendest, spingt der Schalter in openHAB um, ganz ohne dass Du ihn betätigt hast.

Warum die Befehle sporadisch nicht gesendet werden, hat damit aber vermutlich nichts zu tun. Da müsste man halt tiefer ins System eintauchen, um den Fehler zu finden.

Vielen Dank für Eure Antworten

Leider habe ich meinen D1 mini geschrottet und kann derzeit nicht testen

Ersatz ist unterwegs, dann geht's weiter...

Wenn euch vielleicht noch Ideen kommen, wie ich aus dem "sporadischen" ein "verlässliches" Signal bekomme, könnte ich das auch ohne Hardware mit MQTT.fx testen.

DANKE

Eine Sache ist bei meinem OH noch auffällig, die vermutlich die gleiche Ursache hat

Ich habe einige Shelly 2.5 als Rollershoter im Einsatz. Gestern Abend habe ich testweise einige einfache Rules angelegt, die zu unterschiedlichen Zeiten die Jalousien auf unterschiedliche Positionen fahren lassen (Jalousie A 9:15 20% (fast geschlossen), B 9:30 50%, C 10:00 80%). Tatsächlich bewegt hat sich nur Jalousie C zu der eingestellten Zeit. Alle Rules sind gleich aufgebaut, auch technisch funktionieren alle Shellys. Vor längerer Zeit hatte ich bereits auch die Probleme, da hatte ich zwei Rules, eine zum Hoch- und eine zum Runterfahren aller Jalousien zu einer fest eingestellten Zeit. Mal hat es es funktioniert, mal wieder nicht.
Vielleicht lässt sich damit erahnen, wo der Fehler steckt. Die Shellys werden ja auch gesteuert über MQTT und melden ihre Positionen zurück.
Gibt es in OH3 vielleicht eine Energiesparfunktion oder einstellbare Pausen, in denen Befehle verloren gehen können? Eventuell auch eine Obergrenze an MQTT Ereignissen pro Sekunde/Millisekunde die verarbeitet werden können? Ich habe 12 Shellys und einige Temperatur Sensoren im Einsatz, die eine ganze Menge Infos über MQTT austauschen. Wenn man mit MQTT.fx nur bei einem Shelly lauscht, ist dort ganz schön traffic

Ich würde mich feuen, wenn ihr Lösungsansätze für mich habt, damit ich OH wieder vertrauen kann

Nein, außer, dass Dein System offensichtlich nicht zuverlässig läuft, lässt sich da nichts eingrenzen. Mögliche Ursachen fangen bei einem schlechten oder defekten Netzteil an, gehen über eine schlechte oder defekte (Mikro-) SD-Karte und defekte Hardware allgemein bis hin zu einer defekten Installation.

Den RP4 habe ich Anfang des Jahres im Set gekauft mit 3A Netzteil und 32GB Class 10 Micro SD. Kühlkörper, Lüfter und Gehäuse habe ich nicht verbaut.
Vielleicht sollte ich mal "sudo apt-get update" durchführen? Gibt es für OH3 auch eine Update Funktion?

Was ich erstaunlich finde, dass aus OH3 heraus die MQTT-Befehle sporadisch gesendet werden, über MQTT.fx aber alles sauber läuft. Beides läuft über den identischen Broker, der auf dem selben RP4 läuft wie OH3

KiWi22 hat geschrieben: ↑22. Jul 2021 15:52 Den RP4 habe ich Anfang des Jahres im Set gekauft mit 3A Netzteil und 32GB Class 10 Micro SD. Kühlkörper, Lüfter und Gehäuse habe ich nicht verbaut.
Vielleicht sollte ich mal "sudo apt-get update" durchführen? Gibt es für OH3 auch eine Update Funktion?

Was ich erstaunlich finde, dass aus OH3 heraus die MQTT-Befehle sporadisch gesendet werden, über MQTT.fx aber alles sauber läuft. Beides läuft über den identischen Broker, der auf dem selben RP4 läuft wie OH3

Ein

Code: Alles auswählen

sudo apt update && sudo apt -y upgrade && sudo apt -y full-upgrade

ist ohnehin immer eine gute Idee (vielleicht nicht gerade täglich, aber ab und zu), wobei man natürlich aufpassen muss, was da so abläuft, aber grundsätzlich...

Je nachdem, welche Geschmacksrichtung von openHAB Du installiert hat (und wie Du sie installiert hat), kommen die Updates für openHAB bei obigem Befehl automatisch mit.
stable -> gewöhnlich zwei mal im Jahr, Juni und Dezember
testing (oder Milestone) -> gewöhnlich monatlich
unstable (oder nightly) -> fast täglich

Dabei bedeutet "stable" vor allem, dass der Code nicht mehr verändert wird, nicht, dass diese Version besonders stabil läuft.
"testing" bedeutet, dass der Code schon geprüft wurde, aber eben nicht unbedingt vollständig. Man kann erwarten, dass die Version einigermaßen problemlos läuft.
"unstable" bedeutet lediglich, dass der Code ständig verändert werden könnte. Sobald ein Fehler gefunden wird, wird der Fehler beseitigt, wenn Verbesserungen angenommen werden, fließen diese direkt in den Code ein. Man kann sich also nicht darauf verlassen, dass ein Fehler, den man gerade entdeckt hat, überhaupt noch im Code vorhanden ist, es sei denn, man hat gerade eben erst ein upgrade ausgeführt.

Du kannst also bei stable etwa alle sechs Monate mit einem Update rechnen (solange die Hauptversion nicht end of Live ist, wie z.B. OH2. Das Upgrade von OH3.0 auf OH3.1 sollte aber automatisch ausgeführt werden.
Umgekehrt bei unstable sollte fast täglich eine geänderte Version installiert werden, wenn man das upgrade ausführt.

Dabei ist natürlich zu beachten, dass es schon mal Änderungen gibt, die auch Auswirkungen auf die Konfiguration haben (also in dem Sinne, dass man anschließend die Konfiguration anpssen muss, damit openHAB wieder wie gewünscht läuft). Man muss also immer etwas Zeit für "Reparaturen" einplanen.

Hallo udo1toni,
ich habe folgende Meldungen erhalten, womit ich nicht viel anfangen kann.

Code: Alles auswählen

openhabian@openhabian:~ $ sudo apt update && sudo apt -y upgrade && sudo apt -y                                               full-upgrade
[sudo] password for openhabian:
Hit:1 http://davesteele.github.io/comitup/repo comitup InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:3 http://archive.raspberrypi.org/debian buster InRelease
Hit:4 http://packages.microsoft.com/repos/code stable InRelease
Hit:5 https://deb.nodesource.com/node_12.x buster InRelease
Err:6 https://dl.bintray.com/openhab/apt-repo2 stable InRelease
  403  Forbidden [IP: 52.38.32.109 443]
Reading package lists... Done
E: Failed to fetch https://dl.bintray.com/openhab/apt-repo2/dists/stable/InRelea                                              se  403  Forbidden [IP: 52.38.32.109 443]
E: The repository 'https://dl.bintray.com/openhab/apt-repo2 stable InRelease' is                                               no longer signed.
N: Updating from such a repository can't be done securely, and is therefore disa                                              bled by default.
N: See apt-secure(8) manpage for repository creation and user configuration deta                                              ils.

Muss ich das vielleicht mit Root Rechten durchführen? Das wäre dann vorher "sudo -i"?
Sorry für die vielen Fragezeichen in meinem Kopf aber ich kenne mich nicht so gut damit aus

openhabforum.de

OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch

Re: OH3 schaltet MQTT nur sporadisch