Freie Parameter bei Makros

[saft6luck]

Auf welche soll er denn überhaupt antworten? Wenn das so ist, dann müsste man das ja auch in der ETS programmieren.

Der eibPC bekommt ja eh alle Telegramme mit und dann muss er halt auf dieses Telegramm mit dem aktuellen Inhalt antworten ODER (und das finde ich besser aber das ist halt wieder so eine Lösung mit Funktionen) er ruft die Funktion auf, die für diesen Fall definiert ist. Die kann dann den Inhalt aktualisieren und dann senden. Aber die einfache Lösung reicht schon mal. BTW. Wenn man dem aktuellen Konzept folgt, würde ich mir eine Funktion IsReadEvent() vorstellen können, die dann für einen Zyklus auf 1b1 geht. Dann bräuchte man noch ein Answer() (analog zu write()). Sollte je recht einfach zu implementieren sein. Aber evtl. zu simpel für die "großen" Projekte?

Was soll denn in der ETS programmiert werden? Die GA evtl. anlegen und sonst? Oder gibt es für irgend eine andere Aufgabe des eibPC eine "Programmierung" in der ETS? Also.

setreadflag("GA-1/2/3), also das Leseflag für den EibPC setzen.

Ist für mich der Schritt in die richtige Richtung. Ich sehe auch eher selten Bedarf für lesende GAs (aus dem eibPC heraus), aber es kommt vor.
Z.B. Uhrzeit auslesen: Wenn ich schon eine ntp-Zeit im eibPC habe, könnte doch die Leseanforderung, die momentan mein ABB Logik-Zeit-Modul bedient, gleich vom eibPC bedient werden, oder?

[Uwe!]

Nö, das ist der Standard!
Aktor schaltet -> Aktor schaltet eigenständig aus -> Status kommt auf anderer GA -> Schalt-GA stimmt nicht mehr.

Das mein ich doch! Auch völlig ohne EibPC spiegelt eine "Schalt-GA" nicht unbedingt den Status wieder! Und im EibPC eben auch nicht.

[Tessi]

Auf welche soll er denn überhaupt antworten?

Auf die, für die das der jeweilige Anwendungs-Programmierer vorsehen will.

Wenn das so ist, dann müsste man das ja auch in der ETS programmieren.

Wie man es dem EibPC "beibringt" ist doch noch offen. Das muß ja nicht per ETS geschehen, denn es ist dort ja gar keine Eigenschaft der GA's sondern der damit verknüpften KO's, und so etwas besitzt der EibPC ja nicht. Also werden wohl andere Wege gebraucht (siehe weiter unten).

Wie ist das denn bei den anderen Geräten ... Bei meinem BJ Panel sind alle GA auf sendend geschalten - das nervt, weil die meisten Verknüpfungen einfach was melden (auch Statusobjekte etc.).

Ob auf eine read-Anfrage geantwortet wird, sollte ja auch immer einstellbar sein. Falls das bei BJ Panels nicht geht ist das ein erheblicher Schwachpunkt.

Auch bei den Logikmodulen muss ich explizit angeben, welche beim Start gelesen werden sollen.

Ja, und was ist daran verkehrt?

Man kann natürlich ein Feature machen:
setreadflag("GA-1/2/3), also das Leseflag für den EibPC setzen.

Ja, wäre eine Möglichkeit.

Deine Argumente versteh ich nicht.

Welche denn konkret? Oder etwas alle?

Dazu sag ich nix und bin raus.

Aber auch das ist schon eine Aussage.

PLONK.

??? Welche der möglichen Interpretationen dieser Zeichenfolge ist denn hier gemeint?

Was ist den das für ein Unsinn!!!

Etwas als Unsinn zu deklarieren nur weil man für sich persönlich keinen Nutzen darin finden kann ist nicht besonders weise...

Entweder man hat ein "Parametrierbares KNX-Gerät" welches man in der ETS (und ggf. zusätzlich in einerr Applikation) programmiert

ODER

Man nutzt den OPC-Export-ESF-Datei-Möglichkeit!

Beides gleichzeitig man keinen Sinn

Die Welt ist nicht schwarz-weiß. Und hier gibt es kein entweder-oder. Mann könnte sehr wohl beides kombinieren. Aber darum geht es doch gar nicht. Auf dem Bus sehe ich nur GAs mit Daten. Einige Geräte senden, einige höre zu, einige fragen und manche antworten sogar. Das hat rein gar nichts mit ETS zu tun und auch nicht mit der Art und Weise wie ich einem Gerät das gewünschte Verhalten "beibringe"

und wird auch von keinen QUASI-HOMESERVER
oder von einer OPC-VISU verwendet.

Weiß ich jetzt nicht, ist mir aber auch egal. Wenn ich in eines dieser Geräte eine Logik implementiere und deren Status von z.B. einer Visu gelesen werden soll, dann muß das Gerät auch solche Leseanfragen beantworten können. Die Frage nach dem Sinn stellt sich in erster Linie nur für den Anwender des Gerätes, der Hersteller sollte hier die Kreativität seiner Kunden niemals unterschätzen.

keine externe VISU oder kein HOMESERVER von außen auslesbar ist.

Ich betrachte den EibPC inklusive einer Busschnitstelle aber nicht als "extern", wieso auch?

Solche Geräte sind quasi versteckt am BUS und haben nur indirekt
eine Adresse, nämlich die vom IP- oder RS232-GW

Und? Hinter dieser physikalische Adresse steht ja auch nur das Gerät an sich. Ob man eine physikalische Adresse auslesen kann, weiß ich nicht, alle Infos beziehen sich immer auf GA's. Und hinter jeder GA steht ein zuletzt gesendetes Datum, ob das von irgendeinem Gerät auf eine Leseanforderung hin gesendet wird, hat rein gar nichts mit der physikalischen Bus-Anbindung des antwortenden Gerätes zu tun.

Ja, dann nehme einfach ein Logikmodul von APP, dann ist dir geholfen

Ich will schon was frei programmierbares. Aber so frei, das eben alles realisierbar ist!

Nein!!!!
Den EibPC von aussen auslesen zu wollen ist nun wirklich Unsinn.

Siehe oben: Das hat der Anwender zu entscheiden...
Aber wenn denn unbedingt eine reale Anwendung als Beispiel gebraucht wird:
Nehmen wir ein Rolladenpositionsmodul, welches einen "dummen" Aktor (kennt nur move) um die Funktion einer wählbaren Position erweitert und auch bei manuellen Fahrten per move und stop immer die Position bestimmt. Der aktuelle Istwert der Position wäre für eine Visu interessant und könnte von dieser abgefragt werden.

Diese Funktion hat KEIN ESF-an Gerät oder OPC-Server.

Und? In wie fern ist das ein Argument generell für oder gegen ein solches Feature?

Das schöne ist ja gerade, das man solche Arten von Geräten und Software losgelöst von der ETS programmieren können.

Moment mal, ob ein Gerät eine Leseanfrage auf eine GA beantwortet oder ignoriert hat nichts mit der ETS zu tun.

Was soll die Unterscheidung nach "OPC"-artig oder nicht? Wen interessiert das? Ich muss kein Gerät über die ETS programmieren, um GAs lesen zu können, ich muss auch kein Gerät über einen Datenexport programmieren, damit das nicht mehr geht. Das ist schlicht und einfach irrelevant.

Wenn ich Daten aus dem eibPC auslesen können will, z.B. weil meine Logiken jetzt in einem eibPC sind, z.B. die aktuelle Uhrzeit, dann ist die Art der Programmierung egal. Dann lege ich halt eine GA in der ETS an für die Abfrage und/oder die Antwort und gut ist. Da brauch ich auch nicht auf ein ABB Logikmodul downgraden.

Ja, genau das meine ich auch. Schön, das ich nicht ganz allein bin...

Der eibPC bekommt ja eh alle Telegramme mit und dann muss er halt auf dieses Telegramm mit dem aktuellen Inhalt antworten ODER (und das finde ich besser aber das ist halt wieder so eine Lösung mit Funktionen) er ruft die Funktion auf, die für diesen Fall definiert ist. Die kann dann den Inhalt aktualisieren und dann senden. Aber die einfache Lösung reicht schon mal. BTW. Wenn man dem aktuellen Konzept folgt, würde ich mir eine Funktion IsReadEvent() vorstellen können, die dann für einen Zyklus auf 1b1 geht. Dann bräuchte man noch ein Answer() (analog zu write()). Sollte je recht einfach zu implementieren sein. Aber evtl. zu simpel für die "großen" Projekte?

Ggf. ein write(), das per zusätzlichem Parameter wahlweise "normal" oder als Antwort sendet. Ein Callback ist natürlich die flexibelste Lösung, erlaubt das doch, sogar auf einer anderen GA zu antworten - und ja, das wird sicher noch seltener gebraucht, aber es erlaubt das Verhalten von KO's mit mehreren GA's bei Anfrage an eine nur hörende GA zu immitieren und dafür hätte ich sogar einen Anwendungsfall.
Nur, bevor es Sinn macht, sich über das wie allzuviele Geganken zu machen, muß der Hersteller erst einmal generell vom Nutzen überzeugt werden - sonst bekommen wir gar nichts - nicht einmal die minimalste Lösung.

Was soll denn in der ETS programmiert werden? Die GA evtl. anlegen und sonst?

Genau das, sofern sie nicht ohnehin schon existiert (siehe oben).

Ist für mich der Schritt in die richtige Richtung. Ich sehe auch eher selten Bedarf für lesende GAs (aus dem eibPC heraus), aber es kommt vor.

Das ist der Punkt! Es kommt vor...


Und um das Thema noch etwas zu erweitern:
Man kann üblicherweise auch das Verhalten von Geräten bei Empfang einer Antwort konfigurieren - also ob sie diese ignorieren oder wie einen Schreibbefehl behandeln sollen. Ich konnte der Dokumentation bisher nicht entnehmen, das dies beim EibPC irgendwie beeinflußt werden kann. Da er aber Anfragen initiieren kann und die Antworten ja auch zur Kenntnis genommen werden, vermute ich mal, das Antworten und Schreibbefehle generell gleich behandelt werden, etwas das auch einige (meist ältere) Busgeräte so handhaben, was aber in einigen Fällen zu Problemen geführt hat, weshalb heute fast alle Geräte das A-Flag auch korrekt umsetzen. Es wäre ratsam, diese Unterscheidung auch irgendwie im EibPC zu haben.
Konkretes Beispiel:
Ich will nicht, das ein delay() nachgetriggert wird, nur weil ein Gerät die Trigger-GA lesen wollte und irgend ein anderes darauf geantwortet hat. Dazu muß ich diese GA gegen Änderungen durch Antworten sperren und nur für Schreibbefehle freigeben.

Ich verlange ja nicht, das der EibPC KO's bekommen soll, aber es sollte möglich sein, deren mögliches Verhalten nach außen komplett imitieren zu können. Und das gelingt mit den bisherigen Mitteln nicht vollständig.