[wiregate] - √ - Frage zur physikalischen Adresse des WG

[Fry]

Hallo zusammen,

Kein großes Ding, aber:

In meinem eib.log steht jedes Telegramm, das vom Wiregate kommt, mit
der physikalischen Adresse 0.0.0, obwohl die Backend-Adresse des eibd als 1.1.254 konfiguriert ist (und schon immer war). Auch in /etc/default/eibd steht 1.1.254.

Irgendwelche Tipps?

Und: wie kann man auf diese Adresse in einem Plugin zugreifen?

VG,
Fry

[makki]

Recht einfach: Bei TP-UART greift die Einstellung der PA (steht in $msg{'src'}), bei allen anderen Schnittstellen nicht;
Bei USB/FT1.2 gilt die lokal in der SS programmierte PA, bei IP ist es immer 0.0.0 (ob das nun perfekt ist steht auf nem anderen Blatt, ist aber Stand heute so..)

Makki

[Fry]

Dann will ich mal kurz den Hintergrund meiner Frage erklären: um in der Logikengine einfachste Zirkelbeziehungen zu vermeiden, nämlich dass ein Ergebnistelegramm einer Logik die gleiche Logik gerade wieder auslöst, wäre es sinnvoll, wenn man prüfen könnte, woher ein Telegramm kommt.

Gibt es eine Möglichkeit, ein Telegramm daraufhin zu überprüfen, ob es vom Wiregate selbst kommt?

Grüße, Fry

[makki]

Der Hintergrund war mir schon klar

Es geht so einfach nicht, zumindest nicht in unbekannten Umgebungen, sinnvoll flaggen kann man die Telegramme nicht wirklich ausser durch die PA und mehrfache kann ma auch nicht einfach wegwerfen, könnten ja zwei gewollte klicks sein..

Makki

[mumpf]

Hi,

ich habe ein ähnliches Problem (ich versuche, 2 verschiedene Bussysteme über das WG zu "verheiraten"). Ich habe es so gelöst, dass ich das "flaggen" über zusätzliche GA's mache. Alle Adressen des fremden Bussystems sind auf dem KNX über 1/x/y abgebildet, und jedesmal, wenn diese über den fremden Bus gesetzt werden, setze ich die passende 12/x/y auf 1. Dadurch weiss ich, dass ich den Wert von 1/x/y nicht auf den anderen Bus wieder zurückschicken muss, sondern nur die 12/x/y auf null setzten muss.

Ist keine generelle Lösung, aber vielleicht für Spezialfälle trotzdem denkbar.

Gruß, Waldemar

[makki]

Nun, ein durchaus sinnvolles Grundprinzip von EIB/KNX ist:
Es gibt strikt zu trennende sendende (Schalten, absolut Dimmen usw.) und hörende GA's (z.B. Status-rückmeldung für Schalten/Dimmwert) - je länger man damit zu tun hat und darüber nachdenkt, desto mehr versteht man den Sinn - dann ergibt sich das Problem garnicht

Makki

[haegar80]

Es gibt strikt zu trennende sendende (Schalten, absolut Dimmen usw.) und hörende GA's (z.B. Status-rückmeldung für Schalten/Dimmwert) - je länger man damit zu tun hat und darüber nachdenkt, desto mehr versteht man den Sinn - dann ergibt sich das Problem garnicht

Hallo zusammen,

ich kann Makki hier nur zustimmen, habe das gleiche Problem bei der Schnittstelle zu meinem Heizkessel gehabt. Ich bin fast verzweifelt an Zirkelbezügen.

Dann habe ich mich auf die Grundlagen besonnen (so machen es ja die Kommunikationsobjekte der Aktoren auch) und mit getrennten GA war es auf einmal ganz einfach.

So das waren meine 2ct...

Gruß
Sascha

[Fry]

Alles richtig, aber folgendes ist auch richtig:

manche Logiken sind ja "Krücken", um Shortcomings anderer KNX-Geräte auszugleichen. Zum Beispiel indem man bestimmten gesendeten Werten (zB Dimmwert) gleich andere, "korrigierte" Werte hinterherfeuert. Nicht die feinste Art und natürlich lässt sich das auch anders lösen. Die Lösung mit zusätzlichen GAs beispielsweise ist formal sauber aber potenziell ebenfalls verwirrend, außerdem hängt damit die Grundfunktion (Licht an) am Wiregate, und es ist wohl besser, nur die Komfortfunktion (gleich auf korrekten Wert dimmen) vom Wiregate abhängig zu machen.
Dabei würde eine Methode wie beschrieben helfen, Zirkel zu vermeiden. (eine andere Möglichkeit wäre eine Limitierung der Logikfrequenz - Logik wird ignoriert wenn zweimal innerhalb 1 Sekunde aufgerufen.

Grüße, Fry

PS. ein zweites, sehr ähnliches Beispiel ist die Treppenlichtfunktion

[Fry]

Ich hake das Thema jetzt aber mal ab.
Fry

[mumpf]

Hallo Fry,

auch wenn es Dir nicht wirklich weiter hilft: Ich realisiere einen Teil meiner Logiken (trotz meines generischen 2GA Konzepts) über linknx - weil dort regeln formulierbar sind, die sich auf physikalische Adressen beziehen - so bekomm ich die "Krücken" hin.

Witzigerweise hab ich, als ich die Doku zu linknx gelesen habe, bei dem Feature "Physikalische Adresse" noch gedacht: "Was für ein Unsinn, man arbeitet ja mit GA's"

Tja, durch die Praxis lernt man sehr schnell die Theorie zu hinterfragen...

Gruß, Waldemar

[makki]

Nochmal: man kann die PA sehr wohl auswerten & berücksichtigen, nur wird das je nach Konstellation nicht tauglich sein um recursives zu vermeiden; (man stelle sich 2 eibd vor, einer greift über den anderen auf den TP1..)

Natürlich kann man aber schaun, ob das Telegramm vom Taster/PM oder jemand anderem kam!

Makki

[Fry]

So ein Feature wäre sehr einfach auch in das Logikprozessor-Plugin zu implementieren. Aber ich zögere noch damit... nicht alles was geht, ist eine gute Idee.
Fry

[mumpf]

Nochmal: man kann die PA sehr wohl auswerten & berücksichtigen

Hmmm, dann muss ich mir die msg vom WG wohl nochmal genauer ansehen - danke für den Tip.

Gruß, Waldemar

[Fry]

Guckst du auf $msg{src}
Fry

[makki]

Aber ich zögere noch damit... nicht alles was geht, ist eine gute Idee.
Fry

Richtig so, weil: Jein.
Wenn man es gezielt und sinnvoll einsetzt, kann das sehr sinnvoll sein (eben für quirks, wenn ich nur das Telegramm des PM auswerten will, weil A oder B dies oder jenes nicht können o.ä.)
Aber zuallererst sollte man sich immer die Frage stellen: Brauchts das wirklich oder gehts nicht auch ohne ext. Logik!
Ich spreche aus Erfahrung, ich finde heute noch teils Logiken von 2008, wo ich jetzt den Kopf schüttel und mir denke "warum haste da nicht KNX direkt verwendet.."

Makki

P.S.: Aber deswegen - alles ist möglich - läuft dahinter ein Busmonitor der wirklich alles durchreicht, kein Gruppenmonitor; man kann wenn man will