Freie Parameter bei Makros

[enertegus]

So gesehen wird die event()-Abfrage wohl noch sehr
oft in den nächsten Wochen getippt werden müssen.

Wir hatten es auch mit den Betatestern drüber - naja vielleicht kann ich den ein oder anderen am Seminar überzeugen.

Michael

[Uwe!]

Also ich bin schon ziemlich überzeugt! "Ziemlich", weil ich noch nicht dazu gekommen bin alles zu programmieren, was mir noch so im Kopf rum schwirrt.
Korrekt ist aber, dass das, wenn man "normale" Programmierung gewohnt ist, erst mal ein völlig neues Konzept ist! Ich hab auch etwas gebraucht. Aber es ist auf KNX recht gut abgestimmt, wie immer natürlich mit Raum für Verbesserungen.
Was mir, wie schon mal gesagt, wichtig ist: Ich bin heil froh, dass ich den EibPC nicht in C++/C# oder ähnliches Programmieren muss!

[JoeHorn]

Leider ist es nicht so einfach, denn es wird auch noch auf gültig abgefragt, siehe Anleitung S. 34.

Hatte ich auch nicht erwartet. Das war jetzt aus der Hüfte geschossen eine erste Annahme. Aber genau das ist es, trotz aller Erklärungsversuche des Handbuchs ist nicht jedem hier klar, was da wirklich hinter den Kulissen eines harmlos aussehenden Vergleichs tatsächlich stattfindet. Daher werden auch viele Konstrukte nicht so funktionieren, wie sich die meisten Programmierer das zunächst einmal vorgestellen werden.

Wenn ich meiner Frau zeige:
if "KücheLicht-1/2/3"==EIN then write("KücheDuntabzug-1/2/2", EIN) endif

versteht sie es sofort. Sie denkt nicht drüber nach, [...]

Mit dieser geistigen Grundhaltung wurde die Programmiersprache des EibPC entworfen, um die vielen Notwendigkeiten im Komforthaus optimal und schnell zu automatisieren. Das ist der Kern des EibPC.

Die "Notwendigkeiten" konnte ich schon mit den Fähigkeiten meiner Sensoren und Aktoren allein realisierten. Die können auch einfache Logiken umsetzen - ganz ohne programmieren nur per ETS. Den EibPC bräuchte ich für die komplexeren Dinge, und die sind wiederum anscheinend gar nicht mehr so einfach und intuitiv umsetzbar, einfach weil das Gerät manches anders handhabt, als man es aus der Syntax herauslesen würde - wenn man schon Programmiererfahrung hat - aber auch Deine Frau würde
if "KücheLicht-1/2/3"==EIN then if "KücheFenster-1/2/4"==OFFEN then write("KücheDuntabzug-1/2/2", EIN) endif endiff
als identisch zu
if ("KücheLicht-1/2/3"==EIN) AND ("KücheFenster-1/2/4"==OFFEN) then write("KücheDuntabzug-1/2/2", EIN) endif
interpretieren. Nicht weil sie es so aus anderen Sprachen gewohnt ist sondern weil auch im normalen Leben Bedingungen im allgemeinen statisch betrachtet werden, es also keine Rolle spielt, wann sie sich das letzte mal geändert haben. Auch sie würde unvoreingenommen nicht erwarten, das im ersten Fall die Dunstabzugshaube nur dann angeht, wenn beide Signale sich im selben Schleifendurchlauf ändern - was bei 1ms-Zyklen schon daran scheitert, das in der Zeit gar nicht mehr als eine Botschaft empfangen werden kann. Wer außer Enertex-Mitarbeiter würde erwarten, das die erste Version praktisch toter Code ist?
Bevor es wieder zitiert wird: Ja, ich habe im Handbuch die entsprechenden Hinweise nicht übersehen, aber intuitiv ist das, was ich ohne Handbuch verstehe! Oder anders herum: Je ausdrücklicher auf etwas hingewiesen werden muß desto weniger intuitiv ist es offenbar.

Wenn ich nicht darüber nachdenke, könnte ich das einfach und logisch finden. (Könnte ich ja auch per ETS implementieren.) Aber, ein bisschen länger gedacht und schon kommen die Fragen: [...]
Sprich, wenn ich das Ding für eine Automatisierung verwenden will, komme ich um die Zusammenhänge nicht herum.

Da frage ich mich, warum es dann nicht konsequent heißt:
if ( event("KücheLicht-1/2/3") and ("KücheLicht-1/2/3" == EIN)) then write("KücheDuntabzug-1/2/2", EIN)

wenn das zu umständlich ist, muss ich eben einen Befehl für diese Abfrage erfinden und nicht implizit etwas annehmen, dass dann in allen anderen Fällen vom Programmierer unerwartet ist.
[...]

Wie gesagt, es ist nicht mein Thema. Bisher habe ich noch immer eine Lösung gefunden aber die Sprache bleibt, sagen wir mal, "gewöhnungsbedürftig"
P.s. Alle Beispiele ungetestet.

Dem schließe ich mich an. Um Einfache Dinge vermeintlich noch einfacher zu machen, wurden Konstrukte entwickelt, die Komplexeres noch komplizierter oder möglicherweise sogar unlösbar machen.

Also ich bin schon ziemlich überzeugt! "Ziemlich", weil ich noch nicht dazu gekommen bin alles zu programmieren, was mir noch so im Kopf rum schwirrt.
Korrekt ist aber, dass das, wenn man "normale" Programmierung gewohnt ist, erst mal ein völlig neues Konzept ist! Ich hab auch etwas gebraucht. Aber es ist auf KNX recht gut abgestimmt, wie immer natürlich mit Raum für Verbesserungen.
Was mir, wie schon mal gesagt, wichtig ist: Ich bin heil froh, dass ich den EibPC nicht in C++/C# oder ähnliches Programmieren muss!

Das viele vor C o.ä. zurückschrecken, kann ich schon verstehen, deshalb wird KNX ja per ETS konfiguriert und deswegen nutzt KNX auch das Konzept der Kommunikationsobjekte, die man einfach wie gewöhnliche Variablen benutzen kann und die versteckt einen Mechanismus implementieren, diese per GA verknüpft im Hintergrund automatisch busweit abzugleichen.

Leider fehlen im EibPC solche KOs.
Leider, weil diese ohne die Notwendigkeit der speziellen if-Konstruktion ebenfalls überflüssiges Senden vermieden hätten.

Deswegen halte ich das Konzept hier für unglücklich.
Ich hätte die KOs beibehalten und Änderungen einmal pro Schleife auf den Bus gesendet bzw. von diesem übernommen, dafür hätten alle Konstrukte innerhalb der Schleife nach Lust und Laune ein KO so oft überschreiben oder abfragen können, wie sie wollen. Und auch das Problem mit Zentral-GAs wäre dann KNX-typisch über mehrere GAs für ein KO zu lösen, statt dafür interne Variablen haben zu müssen, die dann durch mehrere ifs an die verschiedenen GA angebunden werden müssen. Das ist umständlich, fehlerträchtig und nicht einmal intuitiver als die Flagkonfiguration von KOs.
Sicher, "echte" Programmierer lösen das Problem schon irgendwie. Aber es soll ja eigentlich gerade auch den nicht so geübten Leuten möglich sein, ihre Probleme zu lösen.

Da ich aber zum jetzigen Zeitpunkt der Entwicklung keine Hoffnung mehr auf "Besserung" habe - zu viel Arbeit wurde schon investiert um jetzt noch grundsätzliche Änderungen zu machen wie eine Änderung des if - müssen wir nun nach Workarounds suchen, die zukünftige Nutzungen erleichtert.

Dazu stellen sich mir ein paar Fragen:
Kann man - z.B. per Macros - die fehlenden KOs nachrüsten?
Wie kann ich statisch Bedingungen abfragen? Also eben nicht:
Wenn X sich ändert und gleich y ist dann ...
sondern:
Solange X gleich y ist tue dies, andernfalls tue etwas anderes und zwar bei jedem Schleifendurchlauf...

Und um zum eigentlichen Thema zurückzukehren:
Wie kann ich nach den Einschalten des EibPCs diesen so lange an der Ausführung aller uhrzeitabhängigen Aufgaben abhalten, bist diese dann gültig gesetzt ist?
Es ist ja OK, das ich im Startup die Zeit vom Bus erfrage, nur benötigen ja jedes andere Gerät auch eine ungewisse Zeit um zu antworten. Bis dahin kann der EibPC seine normale Schleife schon einige Male mit der ungültigen Zeit durchlaufen haben.
Abgesehen davon muß ich ggf. im Startup einige Dinge entsprechend der aktuellen Zeit neu initialisieren, damit das Timing in der normalen Schleife anschließend stimmt. Wie warte ich im Startup, bis die Zeit gesetzt wurde?

Nebenbei: Mir sind die Möglichkeiten Daten zu verwenden zu eingeschränkt! Convert() deckt nicht alles ab, vor allem aber fehlt Typecasting, die Interpretation eines Datentyps als einenen anderen, es fehlen Bit- und Bytearrays, mit deren Hilfe man andere Datentypen "sezieren" oder "zusammenbasteln" könnte. 3-Byte-Werte können überhaupt nicht manipuliert werden! Wie schon gesagt, das Gerät soll nicht schon vorhandene Funktionen anderer Geräte ersetzen, es soll das können, was anders nicht geht! Wozu ist es sonst gut? Es ist kein Sensor, es ist kein Aktor, und der Webserver muß noch wachsen bis das halbwegs als Visu durchgehen kann. Es kann derzeit nur Daten verarbeiten, da sollte es das wenigstens nach allen Regeln normaler PC-Sprachen können.

Das ist zumindest meine Meinung.

Aber vielleicht startet ja mal jemand eine Abstimmung darüber, was die Mehrheit jetzt lieber hätte:
Halbwegs einfach, aber dafür beschränkt oder möglichst flexibel und dafür manchmal etwas anspruchsvoller.

Ich weiß, die Entwicklung und ihre Richtung wird hier nicht demokratisch entschieden. Aber vielleicht interessiert das ja nicht nur mich.

[enertegus]

Dazu stellen sich mir ein paar Fragen:
Kann man - z.B. per Macros - die fehlenden KOs nachrüsten?
Wie kann ich statisch Bedingungen abfragen? Also eben nicht:
Wenn X sich ändert und gleich y ist dann ...
sondern:
Solange X gleich y ist tue dies, andernfalls tue etwas anderes und zwar bei jedem Schleifendurchlauf...

Wäre denkbar. Es wäre auch denkbar, eine spezielle if-Funktion zu bauen, die automatisch auf events getriggert wird. Aber ob das wirklich hilft.

Wie kann ich nach den Einschalten des EibPCs diesen so lange an der Ausführung aller uhrzeitabhängigen Aufgaben abhalten, bist diese dann gültig gesetzt ist?

Das wäre doch mal was für nen handfesten Featurewunsch?

Nebenbei: Mir sind die Möglichkeiten Daten zu verwenden zu eingeschränkt! Convert() deckt nicht alles ab, vor allem aber fehlt Typecasting

Es gibt bald stringcast() hierzu.

Vielleicht sind deine Erwartungen hinsichtlich der Programmierkünste der Anwender doch recht hoch. Aber wenn ich so die Mehrheit der Postings ansehe, scheint der EibPC ja doch so den Wünschen zu entsprechen.

Michael

[JoeHorn]

Vielleicht sind deine Erwartungen hinsichtlich der Programmierkünste der Anwender doch recht hoch. Aber wenn ich so die Mehrheit der Postings ansehe, scheint der EibPC ja doch so den Wünschen zu entsprechen.

Ja und ja. Wenn sich jemand an ein Gerät wie dieses wagt, erwarte ich tatsächlich schon Erfahrung im Programmieren, sonst wird es ziemlich viel try-and-error...
Und ich bin etwas erstaunt darüber, das anscheinend tatsächlich so viele fast wunschlos glücklich mit dem schon vorhandenen sind.
Denn mir fallen schon jetzt aus dem Stand Anwendungen ein, bei denen ich jetzt mit Handbuch-Wissen noch keine Lösung entwickeln könnte, bzw. wo etwas an sich einfaches wohl ziemlich aufwändig werden würde.

[IBFS]

Und ich bin etwas erstaunt darüber, das anscheinend tatsächlich so viele fast wunschlos glücklich mit dem schon vorhandenen sind.

Das wundert mich auch!

Vor allem, wenn das EibPC-Dimmer-Problem vom Mikey
und die daraus gewachsenen Codes als sonst wie exotisch
angesehen werden. Das sind nunmal reale Programmideen.

Und die Frage:

Macht mal (so gut wie) alle Zentralbefehle und SZENEN
konsquent nurnoch im EibPC

oder

Belässt man es bei der (teilweise gewachsenen) Mischprogrammierung
sowohl in den Sensoren und Aktoren als auch im EibPC.

Dazu gibt noch viel zu wenige Meinungen. Aber gerade diese
Grundsatzentscheidung beeinflusst die Art und Struktur
des Codes im EibPC schon sehr entscheidend.


Im Prinzip kann man sehr viele Funktionen des HS auch im EibPC
nachbilden. Damit aber jeder Einzelne nicht sinnlos, planlos nach
dem 'try and error'- Prinzip vorgehen muss, sind eine Sammlung von
echten Applikationbeispielen doch eine gut Sache. Beim HS geht das
doch auch.


Gruß

Frank

[enertegus]

Belässt man es bei der (teilweise gewachsenen) Mischprogrammierung
sowohl in den Sensoren und Aktoren als auch im EibPC.

Das wäre meine Empfehlung. Eine einzelne Zentrale ist das gegenteil von dezentraler Technik, wie KNX sein soll.

Im Prinzip kann man sehr viele Funktionen des HS auch im EibPC
nachbilden. Damit aber jeder Einzelne nicht sinnlos, planlos nach
dem 'try and error'- Prinzip vorgehen muss, sind eine Sammlung von
echten Applikationbeispielen doch eine gut Sache. Beim HS geht das
doch auch.

Dazu braucht man einige konkrete Aufgaben.
Beim Dimmer ist das "richitge" Vorgehen ein 4-Bit Dimmobjekt und/oder ein Statusobjekt (das hat der Dimmer bestimmt). Das Statusobjekt abfragen mit dem EibPC - das ist einfacher und direkter.
So wie das über mehrere GA implementiert wurde, ist das nicht sicher optimal.
Für 10 Wochen am Markt ist die rege Teilnahme hier aber doch schon recht gut...


Michael

[saft6luck]

Wäre denkbar. Es wäre auch denkbar, eine spezielle if-Funktion zu bauen, die automatisch auf events getriggert wird. Aber ob das wirklich hilft.

Eine "neue" Funktionalität mit einem sehr bekannten Kommando zu besetzen ist das ursächliche Problem.

if ist ein Vergleich, überwiegend statisch verwendet

if event( "blahblub-x.y.z" == EIN ) then write ... (analog zu anderen eibPC Befehlen, wie after())

ist neu, und könnte leicht erklärt werden. Dann hat man das "if" für statische Abfragen verfügbar.
Natürlich könnte ich mir auch etwas wie:

on event( "blahblub-x.y.z" == EIN ) write ...

vorstellen. Dann kommt auch keiner auf die Idee eines "else".

Aber das Kind ist eben schon in den Brunnen gefallen (jedenfalls für mich) und dann helfen nur noch work arounds wie z.B.

if ( value( "blahblub-x.y.z" ) == EIN ) then ...

um statische Abfragen zu ermöglichen, wenn das if mitspielt.

Das wäre doch mal was für nen handfesten Featurewunsch?

Hatte ich auch schon vorgeschlagen. Mein Ansatz ist ja den gesamten Systemstart zu entzerren, was dann noch viele weitere Probleme mit Zeit und Objektzustand (Haus?) lösen hilft.

[enertegus]

Um hier etwas Vereinfachung zu bringen, habe ich in der Entwicklerversion des Kompilers folgende "KO"s eingebaut:

a=comobject("Licht-1/2/3", "AlleLichterAus-2/3/4", "OGLichter-5/3/2")

a nimmt immer den neuesten Zustand an.

if (a==EIN) then ... endif

Damit würde nun a bei Änderung einer der GAs den "neuesten" Wert annehmen und ggf. die If-Abfrage auslösen.

Wäre das eine Vereinfachung in Eurem Sinne?

Michael
P.S: Neue Version gibts bald - werden da mal zunächst unser Betaforum strapazieren und dann wohl nächste Woche ... ob dieses Feature schon dabei ist, kann ich erst nach den ersten Tests sagen.

[saft6luck]

Um hier etwas Vereinfachung zu bringen, habe ich in der Entwicklerversion des Kompilers folgende "KO"s eingebaut:

a=comobject("Licht-1/2/3", "AlleLichterAus-2/3/4", "OGLichter-5/3/2")

a nimmt immer den neuesten Zustand an.

if (a==EIN) then ... endif

Damit würde nun a bei Änderung einer der GAs den "neuesten" Wert annehmen und ggf. die If-Abfrage auslösen.

Wäre das eine Vereinfachung in Eurem Sinne?

Ich vermute, dass diese Lösung auf das Problem https://knx-user-forum.de/eibpc/7623...-adressen.html besser passt.

Ansonsten finde ich die Idee sehr gut - hat mich schon viel Zeit gekostet, die Status-GAs zu erfassen.

Gibt es schon eine Funktion, die immer einen "event" auslöst WENN eine angegebene Bedingung erfüllt ist? Analog des "value()" aus meinem vorherigen Posting?

[Tessi]

Im allgemeinen kann man KOs über den Bus lesen (sofern das Leseflag gesetzt ist). Gibt es beim EibPC eine vergleichbare Fähigkeit, d.h. kann dieser auf eine Leseanforderung an eine GA antworten, z.B. mit dem Wert einer Variablen?

[enertegus]

Im allgemeinen kann man KOs über den Bus lesen (sofern das Leseflag gesetzt ist). Gibt es beim EibPC eine vergleichbare Fähigkeit, d.h. kann dieser auf eine Leseanforderung an eine GA antworten, z.B. mit dem Wert einer Variablen?

Nein - nur bei einer Anforderung der "eingebauten" Szenenaktoren gibt es schreiben und lesen.

[enertegus]

Gibt es schon eine Funktion, die immer einen "event" auslöst WENN eine angegebene Bedingung erfüllt ist? Analog des "value()" aus meinem vorherigen Posting?

Versteh ich nicht, was Du meinst

[saft6luck]

Versteh ich nicht, was Du meinst

Auf die Schnelle:

if "blah blubber-1/0/1" == TRUE then ...

löst nur einen "event" aus, wenn "blah blubber-1/0/1" empfangen wird. Wenn es dann noch TRUE ist wird der Teil hinter then ausgeführt, ansonsten der hinter else.

Was fehlt ist eine Möglichkeit der statischen analyse. Evtl. hilft ein anderer Name für die Funktion, also jetzt eval():

if eval( "blah blubber-1/0/1" == TRUE ) then ...

soll immer einen "event" auslösen, wenn der code ausgeführt wird. Wenn es dann noch TRUE ist wird der Teil hinter dem then ausgeführt, ansonsten der hinter else.

[enertegus]

Auf die Schnelle:
if eval( "blah blubber-1/0/1" == TRUE ) then ...

Damit programmiert man sehr schnell unbedacht Endlosschleifen ... Genau aus dem Grund haben wir das Validiierungsschema eingeführt.
Michael