ElabNET Technik Forum

Puh

So als Hobby Automatisierer im eigenen Haus überforderst du mich grad
Ich hoffe ihr schlagt die Hände nicht über dem Kopf zusammen!

@starwarsfan
Bitte nicht persönlich nehmen, aber "broken by design" mag das zwar zutreffend beschreiben aber woher soll ich denn die KO Zaubern wenn sie mir nicht zur Verfügung stehen

Bei meinem Heizungsaktor MDT AKH-0800.02 Habe Ich genau 1 KO für die Umschaltung Sommer / Winter An dem Design der KNX Objekte kann Ich doch nichts ändern?

Ausser man nimmt den Anstaz den @gbglace glaube Ich meint (wenn Ich ihn richtig verstanden habe!

Ich reiß ihn kurz nach meinem Verständnis ab:
Ich baue mir einen Virtuellen Status indem Ich den zustand über eine Logik bzw. ein Binding in eine andere GA kopiere / kopieren lasse

Ich Schreibe in die Original GA und lese die Kopierte aus, damit habe Ich keinen Zirkelbezug mehr .... korrekt soweit?
Ich glaube Ich habe nicht deinen ganzen Ansatz verstanden da steigt mein Corona Hirn ( Bion grad in Tag 3) ein wenig aus!

Den Ansatz habe Ich mir auch schonmal überlegt, aber Ich finde den Aufwand den man hierfür betreiben muss enorm!

Und meiner Meinung nach muss eine Technische Lösung verändert oder vereinfacht werden bzw. es muss andere Lösungsansätze geben welche das ganze einfacher bewerkstelligen
Es ist mir bewusst, dass KNX nicht dafür Konzipiert wurde in komplexen Installationen zu Arbeiten mit mehreren Fremdsystemen (außer über die Gateways) und daher kommt das Problem denke Ich hauptsächlich, warum man immer wieder einen Workaround braucht

Vlt. stehe Ich auch komplett auf dem Schlauch, weshalb Ich nochmals um Verständnis bitte

Danke jedem der sich mit dem Thema Beschäftigt

Hi

Nachdem Ich jetzt Parallel nach allen möglichen Lösung Ansätzen geschaut habe ist mir folgendes unter die Augen gekommen:
Das erste was Ich gefunden habe:
Publish and Subscribe Questions and Answers
Q- Can I publish and subscribe to the same topic?
A– Yes. In MQTT version 5 you can prevent messages that a client publishes from being received (no local subscriptions).

Das 2. Dazu
No Local option
In the MQTT v3.1.1, if you subscribe to the topic published by yourself, you will receive all messages that you published.

However, in the MQTT v5, if you set this option as 1 when subscribing, the server will not forward the message you published to you.

und 3.:
The MQTT_SUB_OPT_NO_LOCAL option applies to a specific subscription for a single struct mosquitto only. It only works with MQTT v5 clients. You would use it as follows:

mosquitto_subscribe(mosq, NULL, "my/topic", MQTT_SUB_OPT_NO_LOCAL | qos);
If you use that option, then any messages that mosq sends to the my/topic topic will not be sent back to it.

Wenn Ich das richtig verstanden habe, bekommt der client welcher mit no local subscribt seine eigenen Publish Nachrichten nicht zurück, aber alle anderen!
Ich kann nur grad net ganz umreisßen, ob das wirklich eine lösung ist ... glaube aber schon?!

Zelkin hat geschrieben: ↑Mi Aug 31, 2022 3:47 pm Ich reiß ihn kurz nach meinem Verständnis ab:
Ich baue mir einen Virtuellen Status indem Ich den zustand über eine Logik bzw. ein Binding in eine andere GA kopiere / kopieren lasse

Ich Schreibe in die Original GA und lese die Kopierte aus, damit habe Ich keinen Zirkelbezug mehr .... korrekt soweit?

Streiche im letzten Satz GA und verwende KO dann passt das. Das gilt aber ganz allgemein im KNX. Man schreibt/sendet nichts in, an, auf, eine GA. Man schreibt in, auf, an, mit, einem KO. Was auf den Bus und das was geschrieben/gesendet wird ist die GA zusammen mit dem Wert 0/1 z.B..

Zelkin hat geschrieben: ↑Mi Aug 31, 2022 3:47 pm Und meiner Meinung nach muss eine Technische Lösung verändert oder vereinfacht werden bzw. es muss andere Lösungsansätze geben welche das ganze einfacher bewerkstelligen
Es ist mir bewusst, dass KNX nicht dafür Konzipiert wurde in komplexen Installationen zu Arbeiten mit mehreren Fremdsystemen (außer über die Gateways)

Ja alles richtig und der TWS ist nun ein multi-GW und an allen ecken sehr flexibel. Aber bei einer Verbindung zur KNX-Technologie brauchst halt eine solche skizzierte Lösung.

bzw. eine Analyse wo entsteht der loop. weil das MQTT in sich den loop verursacht oder das KNX-KO mit dem KNX-Stack im TWS.

MQTT kenne ich nicht so im Detail, ist halt IP. Da hast ja ggf. die richtigen Stellschrauben gegoogelt und kannst das mal probieren ob es Besserung gibt.

Hallo miteinander

Zelkin hat geschrieben: ↑Mi Aug 31, 2022 3:47 pm @starwarsfan
Bitte nicht persönlich nehmen,

Kein Ding, alles gut. Eine etwas drastischere Wortwahl hilft i.d.R., das Problem nochmal aus einer grösseren Entfernung oder einem anderen Blickwinkel zu betrachten.

Zelkin hat geschrieben: ↑Mi Aug 31, 2022 3:47 pm Bei meinem Heizungsaktor MDT AKH-0800.02 Habe Ich genau 1 KO für die Umschaltung Sommer / Winter An dem Design der KNX Objekte kann Ich doch nichts ändern?

Nun, das ist schlichtweg nicht korrekt. Habe mal schnell einen Blick in die Doku zum genannten Aktor geworfen. Dort findest Du auf Seite 13 eine Tabelle mit den allgemeingültigen Objekten des Aktors und das sieht im Detail so aus:

- KO 161: Umschaltung/Übersteuerung Sommer/Winter, S-Flag gesetzt
- KO 162: Sommer/Winter Status, L-Flag gesetzt.

Und damit wird genau das realisiert, was ich bisher beschrieben habe. Sprich, auf KO 161 kannst Du schreiben und setzt damit die Sommer-/Winter-Umschaltung. KO 162 kannst Du lesen und bekommst damit den aktuellen Status zurück. Somit verbindest Du eine GA zum setzen des Status mit KO 161 und eine zweite GA zum lesen Status mit KO 162 und alles ist (zumindest auf Seite KNX) in Butter.

Zelkin hat geschrieben: ↑Mi Aug 31, 2022 3:47 pm Danke jedem der sich mit dem Thema Beschäftigt

Gerne doch!

@starwarsfan

https://www.mdt.de/fileadmin/user_uploa ... tor_02.pdf

Meiner is gen 2 und nicht gen 3

Hier findest du 1 kommunikationsobjekt Sommer Winter 80/160 je nachdem ob 4 oder 8 kanal

PS.: 13 / 14 / 15 sind die ko zur Steuerung der betreibsart welche ich am Anfang gemeint habe! Einen auf true setzen werden die anderen false

@gbglace
Ich denke der loop entsteht in dem moment auf der mqtt seite.....
Bzw. Eigentlich gleichermaßen auf beiden seiten! Ich denke aber das mqtt hier nicht umsonst schon ne Lösung anbietet bzw. Dann der einfachere weg ist Anpassungen zu machen

Hi,

ich lass' nicht locker, gell?

Zelkin hat geschrieben: ↑Mi Aug 31, 2022 5:03 pm @starwarsfan

https://www.mdt.de/fileadmin/user_uploa ... tor_02.pdf

Meiner is gen 2 und nicht gen 3

Ah ärgerlich. Nach dem was dort auf Seite 22 steht:

Mit dem Verhalten bei Busspannungswiederkehr kann festgelegt werden, welche Werte im Falle der
Busspannungswiederkehr abgefragt werden sollen. Werden keine Werte abgefragt, so arbeitet der
Aktor nach einer Busspannungswiederkehr einfach so weiter, als wenn sich die Ventile in den
Default-Einstellungen befänden, also alle Ventile geschlossen wären. Mit den anderen Einstellungen
kann entweder das „Sommer/Winter“ Objekt abgefragt werden oder aber fest im Sommer- bzw.
Winterbetrieb fortgefahren.

Heisst das also, dass man mit diesem Settings explizit einschalten muss, dass dieses KO sowohl lese- als auch schreibbar ist. Da werden die Jungs bei MDT wohl damals schon gewusst haben, dass das nicht sauber ist und haben es per default abgeschaltet. In der aktuellen Aktor-Generation ist es nun also richtig, auch wenn Dir das in dem Fall wenig nützt.

Sorry, ich habe alles versucht...

Es geht im KNX auch auf einem KO, man muss nur die Status-GA als erste verbinden, und die Befehls GA als zweite. Dann braucht es kein explizites Status-KO. Das funktioniert aber nur im KNX. am TWS-internen KNX-KO zum Übergang MQTT hilft das nichts, da es mit dem KNX-KO nur eine Kontaktstelle/Information gibt.

@starwarsfan
Gerne hartnäckig....... Fuhrt oft zu besseren Ergebnissen als "isso, mach mer halt so"

Ich lasse das Objekt immer abfragen bei spannungswiederkehr und lasse einen der Aktoren mi it nem lesen flag in der ga

Das will ich jetzt noch auf das ko vom tws umstellen um hier eine zuverlässigere Quelle des zustands zu haben!

Keine Ahnung was die sich dabei gedacht hatten.... Aber man entwickelt sich halt weiter.... Deswegen tausche ich die Aktoren jetzt net aus

Das Thema Sommer/Winter-Umschaltung ist ein gutes Beispiel, bleiben wir mal da dabei.

Ganz grundsätzlich muss man sich klar machen (nicht nur bei KNX, sondern ganz allgemein bei der Automatisierung; wobei manche Systeme das ziemlich verstecken): Was ist ein "Zustand" (und wenn man damit auch noch rechnen möchte muss man es eigentlich auftrennen in: was ist eine Bestandsgröße / Potentialgröße und was die davon abgeleiteten Flussgrößen / Stromgrößen?) und was ist ein "Ereignis" (Event)?

• Ein Zustand ist etwas, da kann ich zu jedem Zeitpunkt mit einem geeigneten Messgerät hingehen und diesen Zustand messen.
  Beispiel: Mit einem Kalender kann ich messen ob Sommer oder Winter ist
• Ein Event ist etwas, was einen Zeitpunkt hat, sonst nichts. (Man kann es erweitert auffassen, so dass der Zeitpunkt auch noch einen Wert hat).
  Beispiel: der Zeitpunkt des Wechsels von Sommer auf Winter

Damit ist auch klar: einen Event kann man nicht lesen. Er ist da oder eben nicht.
Man kann höchstens in der Vergangenheit nachschlagen wann der Event jeweils kam, oder vorhersagen wann mal wieder einer kommen wird. Das ist dann aber kein Event mehr, diese Informationen sind dann eigentlich schon wieder Zustände.
Oft ist die Information relevant welchen Wert der letzte Event hatte. Diese Information ist dann aber eben ein Zustand. (Z.B. bei einem KNX Block für eine UND-Verknüpfung: der kann nur bei einem Event auf einem Eingang das mit dem letzten Wert auf dem anderen verknüpfen - was aber eben kein Event mehr ist, sondern ein Zustand.)

Anderes Beispiel (weil Wikipedia da das Zustandsdiagramm für hat) ist eine Tür. Die kann offen oder zu sein. Das ist der Zustand. Den kann ich messen. Der Wechsel zwischen geschlossen und offen ist dagegen ein Event. Das ist (in diesem einfachen Modell) nicht mehr messbar, sondern nur ein Zeitpunkt. In Grafisch ist dass dann:


Nach der Definition folgen die Konsequenzen daraus:

• Ein Event ist prinzipbedingt nicht lesbar
• Ein Zustand sollte es nur an exakt einer Stelle geben - wenn es Redundanzen gibt, dann ist die Gefahr hoch, dass sich diese widersprechen. Das muss zwingend vermieden werden!
• Das lässt sich nur vermeiden, wenn bei mehreren potentiellen Quellen eine einzige als gültig definiert ist

Und damit sind wir beim Problem Sommer/Winter und dem Heizungsaktor.
Ist der Heizungsaktor die einzige gültige Quelle für den Zustand ob Sommer oder Winter ist?
Das wäre für mich ein unlogisches Systemdesign (ich hätte diese Information eher bei irgend einer Zeitquelle vermutet), aber möglich. Und schon bei zwei Heizungsaktoren (z.B. weil die Zahl der Heizkreise nicht mehr nur auf einen passen) problematisch: wer von beiden hat denn nun recht, wenn sich die Werte unterscheiden?

KNX bietet hier das notwendige Werkzeug um mit dem Thema Event und Zustand korrekt umzugehen:
Die normalen Telegramme sind Events. Beispielsweise das Event: "Licht EIN" vom Lichtschalter. Der hat aber keinen Zustand, da der gar nicht wissen kann was das Relais im Schaltaktor so macht. Das Telegramm geht zum Schaltaktor, der hat nämlich nun einen Zustand (Relais ist an oder aus). Wenn der Schaltaktor nun geschaltet hat, so stellt der auf einem anderen KO diesen Status bereit. Gerne sendet er den gleich mal bei einer Änderung. Aber er lässt sich auch mit einem Lese-Telegramm auf diesem anderen KO abfragen.
Das Telegramm von diesem anderen KO des Schaltaktors geht nun wieder zurück an den Taster für dessen Status-Eingang. Damit kann der Taster nämlich seine LED ändern, die (hoffentlich!) immer dem Relais-Zustand des Schaltaktors entspricht.
Und, jetzt kommt das geniale bei KNX, lässt sich damit auch leicht die "Alles Aus" Funktion realisieren: man gibt dem Schaltaktor-Event-KO einfach eine weitere GA, die Alles-Aus-GA, auf die der hören soll.
Drückt nun jemand die Alles-Aus-Taste, geht das Aus-Event über die Alles-Aus-GA auf das Event-KO des Schaltaktors. Dem ist vollkommen egal, welches Event das ist, der schaltet nun aus. Ändert folglich ggf. seinen Status. Und gibt diese Info über das Status-KO an die sendende GA da dran. Die ist mit dem Taster-Status-Eingang verbunden. Und somit weiß der Taster, dass nun das Licht aus ist, obwohl er selbst nicht betätigt wurde. Und folglich ist der nächste Tastendruck ein EIN (obwohl der letzte Tastendruck auch schon ein EIN war).
=> Der KNX trennt zwischen Event und Zustand
=> Der KNX kann damit umgehen, wenn zwei getrennte Geräte eigentlich den gleichen Zustand haben sollten (Relais Schaltaktor + LED im Taster)

Wenn manche KNX Geräte das nicht können, oder andere Bus Systeme das grundsätzlich nicht können, so ist das ein reales Problem. Am besten einen Bogen drum machen und etwas nehmen, was das kann.
Und immer überlegen: Ist das ein Event oder ein Zustand? Und wenn es ein Zustand ist: wer ist der Master?

@Chris M.
Wow...... Danke für die Mühe

Nach deinem Bsp. Sollte ich also einfach fire and forgett verwenden
Also den Wert schreiben (wird durch ein Script in Abhängigkeit der duechschnittstemp der letzten Woche erledigt) und davon ausgehen dass der Wert immer passt...... Würde hier grundsätzlich sogar gehen!

Dann gehen wir einen Schritt weiter, Betriebsmodi
Das Event ist z. B. Haus ist verlassen (Knopf an der tür oder aus der visu am Handy weil man den Knopf vergessen hat oder durch Erkennung dass die Handys aus dem Haus sind)

Nun ist standby zu beschreiben mit true damit wechseln die beiden anderen auf false..... Event ist klar zustand ist dann standby
Um diesen auslesen zu können muss ich aber alle 3 abfragen da der visu NUR die true schaltungen bekannt sind (iss ja nur publish) steht mir diese info nicht zur Verfügung

Einzig gültige Quelle sind die 3 ko des heizungsaktor..... Um eine Änderung des zustands herbeizuführen muss bei einem Event eine der ko's verändert werden wobei die anderen in dem Moment reagieren

Also bei allem was du geschrieben hast gebe ich dir erst mal grundsätzlich recht!

Aber dein Abschluss sehe ich anders!
Die Probleme zu identifizieren und Alternativen zu suchen um Kompatibilität herzustellen ist doch sinnvoller als zu sagen nimm was anderes.

Bei mir ist iobroker die zentrale für alle Systeme! Am Anfang mit dem knx Adapter alles kein thema.... Bis auf die verbindungsstabilitat
Aber alles drumherum an Scripten habe ich nun mal auf das System ausgelegt
Der tws sollte die Verbindung stabiler machen indem er nativ eingebunden ist jetzt muss der Datenaustausch hakt noch klappen!
In einer Hinsicht gebe ich dir aber wiederum recht..... Aber es muss nicht mqtt sein..... Gerne auch API oder sonst was..... Da habe ich aber leider gar keinen Ansatz

Iss vom Handy gesendet