[gelöst] Elegantere Programmierung?

[paul53]

@skorpil sagte: Licht "AussenSchlaf" oder das Lich "HinterTV" einschalte, soll etwas passieren.

on({id: [IDLichtschalterAussenSchlaf, IDLichtschalterHinterTV], change: 'gt'}, function () { // triggert bei Wertänderung false --> true

[skorpil]

@paul53 was war an meiner Variante mit den "||" falsch?

[paul53]

@skorpil
Laut Doku kein zulässiges Muster.

[skorpil]

@paul53 ...und wie wäre das so gegangen?

u can use following parameters to specify the trigger:

parameter	type/value	description
logic	string	"and" or "or" logic to combine the conditions (default: "and")

[paul53]

@skorpil sagte in [gelöst] Elegantere Programmierung?:

wäre das so gegangen?

Nein, das bezieht sich auf die verschiedenen Bedingungen.

on({id: ID1, val: true, ack: true}, function() {});

bedeutet: Wert == true UND Bestätigung == true.
Das kann man ändern in Wert == true ODER Bestätigung == true:

on({id: ID1, logic: 'or', val: true, ack: true}, function() {});

Habe ich selbst noch nie gemacht.

[skorpil]

in der WebUI der homematic gibt es die Formulierung "wenn" und "sonst".

Ich habe jetzt so einen Fall, wo ich dies einsetzen möchte. Momentan habe ich das in JavaScript mit zwei On Anweisungen in einem Script gelöst:

on({id: IDAussenbeleuchtung , val: true}, function () {

on({id: IDAussenbeleuchtung , val: false}, function () {

also den false Fall in einer weiteren ON Anweisungen. Geht das? Ist das so richtig?

Oder besser mit

on({id: IDAussenbeleuchtung , change: 'ne'}, function () {

und einer folgenden if Abfrage?

[haus-automatisierung]

@skorpil sagte in [gelöst] Elegantere Programmierung?:

also den false Fall in einer weiteren ON Anweisungen. Geht das? Ist das so richtig?

Sorry, aber liest Du überhaupt die Antworten hier? Das hast Du doch schon 2x gefragt.

on({id: IDAussenbeleuchtung, change: 'ne'}, function (data) {
    if(data.state.val) {
        // ist true
    } else {
        // ist false
    }
});

[skorpil]

@haus-automatisierung sagte in [gelöst] Elegantere Programmierung?:

Sorry, aber liest Du überhaupt die Antworten hier?

Ja, natürlich. Entschuldigung. Dann habe ich was übersehen. Ich war jetzt an einem neuen Script und hatte es offenbar verdrängt. Sorry und Danke!

[skorpil]

@haus-automatisierung dennoch nochmal die Frage: sind zwei ON Anweisungen falsch? Elegant ist das sicher nicht, das geht mit IF und ELSE, wie Du beschrieben hast, sicher besser. Mich interessiert jedoch, ob das mit den zwei ON funktionieren würde.

[paul53]

@skorpil sagte: ob das mit den zwei ON funktionieren würde.

Es funktioniert, aber 2 Trigger auf den gleichen Datenpunkt in einem Skript ist Ressourcenverschwendung.

[skorpil]

@paul53 Danke. Kapiert!

[Codierknecht]

@skorpil sagte in [gelöst] Elegantere Programmierung?:

Mich interessiert jedoch, ob das mit den zwei ON funktionieren würde

Theoretisch ja.
Der Trigger feuert dann aber bei jeder Aktualisierung.
Soll heißen: Es kann passieren, dass der DP aktualisiert wird. Der Wert ändert sich dabei nicht - er erhält lediglich einen aktuelleren Zeitstempel.
Dein Trigger feuert aber trotzdem.

Mit dem Trigger "OnChange" bist Du da eher auf der sicheren Seite. Der feuert nur, wenn der Wert sich ändert.

Wenn etwas mit einem einzigen Trigger erledigt werden kann, sollte man das auch so machen.
Zwei Trigger sind hier unnötig. Könnte mir gut vorstellen, dass zu viele Trigger das Gesamtsystem unnötig belasten, aber da stecke ich nicht tief genug drin.

[skorpil]

@codierknecht klasse, danke!

[skorpil]

Eine Frage, die ich mir vermutlich schon selber beantwortet habe, möchte ich dennoch noch einmal in den Raum stellen:

ich habe folgende ON Anweisung angelegt:

on({id: idBewMldrGarten, val : true}, function () {

Offenbar wird sie JEDESMAL, wenn der BewMldr einen Wert sendet, egal ob er vorher schon "true" war, erneut ausgelöst. Ich tippe darauf, ich muß auch hier mit

on({id: idBewMldrGarten,  change: 'ne' }, function () {

und einer folgenden IF Anweisung arbeiten? Richtig?

[Codierknecht]

@skorpil sagte in [gelöst] Elegantere Programmierung?:

Ich tippe darauf, ich muß auch hier mit
...
und einer folgenden IF Anweisung arbeiten? Richtig?

Korrekt.
Genau das ist der beschriebene Effekt. Der Trigger feuert bei jeder Aktualisierung. Ob der Wert auch vorher schon true war ist ihm völlig Latte.

[haus-automatisierung]

@skorpil sagte in [gelöst] Elegantere Programmierung?:

Offenbar wird sie JEDESMAL, wenn der BewMldr einen Wert sendet, egal ob er vorher schon "true" war, erneut ausgelöst.

Richtig. Kombinier doch einfach beide Attribute:

on({id: idBewMldrGarten, change: 'ne', val: true}, function () {

Heißt:

• Der Wert muss unterschiedlich zum vorigen sein ('ne' => 'not equals')
• und der neue Wert muss true sein, damit die Callback-Funktion aufgerufen wird

[YunaKato]

@haus-automatisierung

on({id: idBewMldrGarten, change: 'gt' }, function () {

wäre das in dem Fall nicht einfacher ?

[haus-automatisierung]

@yunakato sagte in [gelöst] Elegantere Programmierung?:

wäre das in dem Fall nicht einfacher ?

Also ich persönlich weigere mich, solche Vergleiche auf boolsche Datenpunkte anzuwenden Würde ich in der Programmierung ja auch nirgendwo so machen.

true > false. Ist nicht schön (meine Meinung). Aber funktioniert auch.
Ob das "einfacher" ist, sei mal dahingestellt Ich finde es schwerer zu verstehen.

Ich programmiere nun über 20 Jahre, aber habe noch nie gesehen, dass jemand mit > false auf true prüft Zum Glück...

Wenn man sich nicht an Typen hält und die bunt mischt, kommen lustige Dinge raus. '3' + 2 ergibt z.B. 32 (als String) und '3' - 2 ergibt 1 (als Number) - siehe "Implicit Conversions". Damit muss man sich dann erstmal auseinandersetzen.

[Codierknecht]

@haus-automatisierung sagte in [gelöst] Elegantere Programmierung?:

Also ich persönlich weigere mich, solche Vergleiche auf boolsche Datenpunkte anzuwenden Würde ich in der Programmierung ja auch nirgendwo so machen.
true > false. Ist nicht schön (meine Meinung). Aber funktioniert auch.

Darum habe ich so meine Probleme mit un- oder nur schwach typisierten Sprachen.
Strenge Typisierung und ein vernünftiger Compiler/Interpreter machen die Dinge deutlich einfacher und vor allem stabiler.
Da passieren sonst gerne mal die aberwitzigsten Dinge ... die man vermutlich erst nach stundenlangen Debug-Sessions findet.

[skorpil]

@codierknecht dankeschön. Ich meine ja, man müßte die Doku für JavaScript im IObroker mal überarbeiten. Viele dieser Infos sind da in der Form nicht vorhanden (oder habe ich da was übersehen?). Solche Effekte müssten m.E. dort intensiver, eben auch für Dummies wie mich, besser dokumentiert werden.

Ich bin leider nicht Fachmann genug, um mich an sowas heranzuwagen, wäre aber gerne bereit, zu helfen.