[Gelöst] [3.5.1] Zwei gleiche Logikbausteine aber verschiedene Ergebnisse bei einem der Eingänge

[Robosoc]

@StefanW
Ich glaube, dass Ihr Euch das hier einmal genauer anschauen solltet. Es ist die erste Logik, die ich in Diskussionen gesehen habe, bei denen ein MQTT-Sensor als Eingang dient. Auch wenn es vielleicht nicht die Einzige ist, so ist es dennoch selten und ist daher von der Community nicht so reichhaltig getestet.

Natürlich würden wir hier erstmal Alle meinen, dass es keine Unterschied machen sollte und der Dispatcher alles gleich bahendelt. Aber bei kleinen Bugs sind es ja doch oft die Details , die den Unterschied ausmachen. Hier scheint mir eine Logik anders zu agieren , wenn ein Wert vom MQTT Universum gespeist wird.

Der Verdacht wäre hier aktuell m.E., dass ein U Eingang Werte vom MQTT Sensor nicht wirklich übernimmt.

[zaphood]

Hm, das Problem scheint zu sein, dass die MQTT Daten häufig nicht als Eingangswert für die Logik vom TW gelesen werden. Sobald dann mal ein Wert eintrifft, triggert der Eingang völlig korrekt.

Wenn ich mir längere Zeit die Logik mit dem Doktor ansehe fällt mir auf, dass der Eingang lange Zeit (mehrere Minuten) keinen Wert anzeigt. Da kann dann auch nichts triggern.

Bildschirmfoto 2022-10-31 um 13.13.45.png

Da ich die Feuchte via Influx (andere Instanz, nicht auf dem TW) mitlogge, kann ich sehen, dass der MQTT Sensor (Feuchte Bügelzimmer) brav Daten schickt. Lustig ist, Tasmota scheint sich nicht an die eigenen Default Werte zu halten und schickt die Messergebnisse minütlich und nicht alle 5 min, wie es sie sollte. Das ist aber nur eine Nebenerkenntnis, sollte nichts mit dem Verhalten des Eingangs hier zu tun haben.

Bildschirmfoto 2022-10-31 um 13.20.11.png

Sobald ich als Input z.b. wieder den Feuchtewert Flur (KNX) nutze, kommen Werte und alles geht wie erwartet.


Im MQTT Manager schaut das noch alles prima aus

Bildschirmfoto 2022-10-31 um 13.29.56.png

Hat Robosoc recht und das ist ein Bug im TW?

Danke und Gruss
Frank

[Robosoc]

Hat Robosoc recht und das ist ein Bug im TW?

Ich würde hier gerne noch nur von einem Anfangsverdacht sprechen und möchte nicht behaupten, dass es sicher ein Bug ist. Aus meiner Sicht lässt sich das von Dir geschilderte Verhalten aber zumindest nicht eindeutig logisch erklären.

[zaphood]

War ja auch als Frage formuliert Aber ja, Anfangsverdacht ist sicher richtiger.

[StefanW]

Hallo Frank,

Hm, das Problem scheint zu sein, dass die MQTT Daten häufig nicht als Eingangswert für die Logik vom TW gelesen werden.

in MQTT wird auch nichts gelesen. Logik und Dispatcher lesen ohnehin nicht (nie).

1. In MQTT kann sich ein Client subscriben, also etwas abonnieren. Ob und was er bekommt, ist Sache des Senders und des / der Broker dazwischen

2. Das MQTT Subsystem leitet die so erhaltenen Werte an den Dispatcher weiter

3. Der Dispatcher kann nicht lesen. Es gibt nur eine Richtung und die ist Vorwärts. Rein in den Dispatcher durch ein Subsystem, dann Verteilung an die anderen Subsysteme

4. Die Logik weiß gar nicht, welches Subsystem einen Wert an den Dispatcher übergeben hat, es kann mithin nicht zwischen KNX und MQTT unterscheiden. Die Logik liest auch nicht (es ist keine SPS) sondern reagiert auf Werte die sie erhält (abhängig von den Triggereinstellungen) weil Event-Orientiert.

Ich schlage vor, die MQTT Seite zu untersuchen. Hilfreich wäre es, als Ziel nicht nur die Logik sondern eine Zeitserie anzugeben.

Der Dispatcher und die Logik sind alte, sehr gut abgehangene Software. Bevor das Wort "Bug" in die Welt gesetzt wird, bitte deutlich mehr Informationen liefern.

Stefan

[gbglace]

Da ich die Feuchte via Influx (andere Instanz, nicht auf dem TW) mitlogge, kann ich sehen, dass der MQTT Sensor (Feuchte Bügelzimmer) brav Daten schickt.

Die Frage ist ob das auch an/durch den broker an/durch geht der den TWS mit dem Inhalt versorgt. Prüfung wäre wenn Du entweder den Wert auf ein KNX-Ko gibst oder in eine Timeseries, parallel zur Logik. Kommt es an einen der beiden Test-Ziele zu einem regelmäßigem Wert, dann hängt es an der Dispatcherstrecke zur Logik. Beginnt in dem Monet auch die Logik, dann hängt es auch im Dispatcher. Passiert dann weder am KNX-Ko noch an der Timeseries etwas, dann hängt es auf der Strecke rings um den involvierten Broker, zu diesem Wert.

Man könnte das auch einmal mit einem anderen Wert von dem MQTT Sensor machen.

[zaphood]

Ich schlage vor, die MQTT Seite zu untersuchen. Hilfreich wäre es, als Ziel nicht nur die Logik sondern eine Zeitserie anzugeben.

Was kann ich zum Erkenntnisgewinn beitragen? Was meinst du mit "Zeitserie angeben" genau?" Der Eingangswert ist doch in meinem Post als Grafana Grafik dargestellt?

Der Dispatcher und die Logik sind alte, sehr gut abgehangene Software. Bevor das Wort "Bug" in die Welt gesetzt wird, bitte deutlich mehr Informationen liefern.

Das war jetzt aber die Mutter aller Goldwaagen... es war eine FRAGE ob es einer sein KANN und keine BEHAUPTUNG

Also, wir haben ein für mich im Moment unerklärliches Verhalten eines Eingangs in einer meiner Logiken, der möglicherweise mit Besonderheiten bei einem meiner MQTT Objekte zusammenhängen könnte.
Besser?

CU
Frank

[gbglace]

Der Eingangswert ist doch in meinem Post als Grafana Grafik dargestellt?

Du notiertest aber auch in einer anderen Grafana instanz. Und im MQTT-Objekt war ersichtlich das die Luftfeuchte nur mit der Logik verbunden ist und nicht mit einer TWS-Timeseries.

Insofern was ist das für ein Grafana, welche Datenbank liegt dem zugrunde und ist das der gleiche MQTT Subscribe Mechanismus und der gleiche Broker?

[zaphood]

Insofern was ist das für ein Grafana, welche Datenbank liegt dem zugrunde und ist das der gleiche MQTT Subscribe Mechanismus und der gleiche Broker?

Influx DB 2.40 + Grafana 9.2 als eigene LXC Instanz auf Proxmox. Broker ist derselbe Mosquitto 2.0.11 auf den auch der TW zugreift. Client ist dann noch Openhab 3.3.0 als Subscriber, das dann in die InfluxDB schreibt, woher dann schliesslich mein Grafana Graph stammte.

Was du mit "der gleiche MQTT Subscribe Mechanismus" meinst, verstehe ich leider nicht, daher kann ich das nicht beantworten. Da der Sensor ein JSON Objekt liefert, wird das sowohl auf dem TW als auch unter Openhab entsprechend geparsed und die Ergebnisse in die entsprechenden lokalen Objekte geschrieben. Beantwortet das deine Frage?


Anbei eine Timeserie des MQTT Objekts vom TW wie gewünscht.

Bildschirmfoto 2022-10-31 um 19.26.06.png

Cu
Frank

[zaphood]

Die Frage ist ob das auch an/durch den broker an/durch geht der den TWS mit dem Inhalt versorgt.

Du meinst, ob die KNX Werte auch via MQTT kommen? Nein, die kommen direkt vom KNX Bus.

Prüfung wäre wenn Du entweder den Wert auf ein KNX-Ko gibst oder in eine Timeseries, parallel zur Logik.

Das mache ich ja schon bei der Logik für den zweiten Entfeuchter (hatte ich ja geschrieben, dass der KNX Objekte als Ein- und Ausgang nutzt).

Kommt es an einen der beiden Test-Ziele zu einem regelmäßigem Wert, dann hängt es an der Dispatcherstrecke zur Logik.

In anderen Worten, der Mosquito würden den TW nicht "bedienen" (also dem TW als Subscriber nichts schicken). Dann sollte man das in der Timeseries sehen, verstehe.