Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[MarcIO]

@liv-in-sky
Das war's leider nicht. Es sollte ein ">" sein, aber danke dafür.
Sonst irgendwelche Auffälligkeiten?

Zuvor sah es eben mit einem einzelnen Wert so aus:

{val:path;
val<=8 ? "lightgreen" : val<=8.5 ? "yellow" : val>8.5 ? "#ff6633" : "#ff6633"}

und da hat alles gepasst. Die weiteren Werte werden eben deklariert und nur mit logischen Verknüpfungen verglichen. Wüsste nicht, was das für Probleme machen sollte.

Mein Ziel ist es grün für alles im 1. Bereich, sobald ein Wert allerdings überschreitet soll rot oder gelb (je nach Wert) angezeigt werden.

[liv-in-sky]

@marcio

öffne mal die seite mit chrome - dann unter entwicklertools unter dem tab console einen refresh der seite machen und das log zeigen

[OliverIO]

@marcio sagte in Javascript in VIS ausführen:

3 Werten berechnen

hm, das könnte aber etwas aufwändig werden.
allein wenn jeder wert nur wahr oder falsch einnehmen kann, hast du schon 6 kombinationen.
wenn jeder wert aber noch mit mehreren möglichkeiten an brandbreiten auf der zahlenreihe hat, dann explodieren die kombinationen.

wenn man sich quälen möchte, dann bekommt man das schon hin, aber richtig les- und wartbar ist das nicht.

evtl beschreibst du uns was das für werte sind und was du da genau darstellen möchtest. evtl gibt es eine andere/einfachere lösung.
alternativ kannst du selbst mal eine logiktabelle erstellen, bei der du für jeden wert alle alternativen aufschreibst und das in einer tabelle durchkombinierst. da wirst du schon sehen, das du das nicht willst. :) bzw. wir das in eine javascript funktion packen müssen, die dann im binding aufgerufen wird und das richtige ergebnis liefert.

[OliverIO]

@marcio sagte in Javascript in VIS ausführen:

{val:path; val<=8 ? "lightgreen" : val<=8.5 ? "yellow" : val>8.5 ? "#ff6633" : "#ff6633"}

zu diesem ausdruck evtl noch hinweise, die dir helfen können:

• oft kommen die werte nicht als nummerische werte an, sondern als string. daher muss man den wert jeweils noch in ein parseFloat(val) packen.
• bei der letzten prüfung mit >8.5 hast du jeweils die gleichen farben stehen. wenn das so ist, kann man es auch weglassen und direkt die farbei eintragen

{val:path;                                                                                                                                                                            parseFloat(val)<=8 ? "lightgreen" : parseFloat(val)<=8.5 ? "yellow" : "#ff6633" }

[MarcIO]

@liv-in-sky @OliverIO
Vielen Dank für die Rückmeldungen!

Also ich habe gestern noch etwas umgestellt und es hat tatsächlich so funktioniert:

{val1:0_userdata.0.Garage.Motor1_Friction; val2:0_userdata.0.Garage.Motor1_Impact; val3:0_userdata.0.Garage.Motor1_Temperature; val1<=8 && val2<=23 && val3<=42 ? "lightgreen" : val1>8.5 || val2>24 || val3>43 ? "#ff6633" : "yellow"}

Weiß natürlich nicht warum es auf dieser Variante funktioniert hat, aber das nehm ich nun so an.

@OliverIO Meinst du es gibt eine effizientere Lösung? Mir ist natürlich klar, dass durch so viele Einsätze von Variablen es immer wieder zu Verzögerungen kommt. Vor allem steht in der Planung diese Auswertung für andere Motoren noch auszuweiten.

Ich möchte eben gerne alle Werte in einer Übersicht im Blick haben.

[OliverIO]

@marcio wenn es nur bei diesen drei Entscheidung fällen bleibt, ist es okay.
Als generelle Rückfallebene. Für alle Kombinationen, die du nicht prüfst, hast du ja Yellow.

Wenn du mehr Kombinationen hättest, dann wird dieser so genannte ternary Operator schnell unübersichtlich.
Dann ist es besser, eine klassische Java Skript Funktion zu schreiben, mit dem man alles mit if then else prüft und nur diese dann in das Binding einfügt

[Ro75]

Wenn ich Skripte in der VIS eintrage, dann wird das ganze später doch auch auf dem Rechner ausgeführt wo die VIS - Runtime läuft.

JS und Alias laufen auf dem Rechner wo der ioBroker läuft.

Also ich hatte in der Vergangenheit da so meine Probleme, was letztlich die Performance angeht - speziell wenn davon ggfs. mehrere existieren. Ich habe alles berechnende aus der VIS, zurück zu Alias und/oder JS gebracht, damit auf dem Computer wo die Runtime läuft so wenig wie möglich laufen muss, außer das was muss.

Ro75.

[OliverIO]

@ro75

wenn du den javascript reiter im iobroker meinst, hast du recht. das wird auf dem server ausgeführt
ich spreche vom script-Reiter in vis, da kann man auch javascript reinschreiben und das wird auf dem client ausgeführt.

die bindings werden im hintergrund ebenfalls in javascript übersetzt und sind leider sehr unperformant

[Ro75]

@oliverio nein, ich meine genau diesen Reiter.

Ro75.

[MartinP]

@oliverio meines Wissens ist das, was @Ro75 schreibt korrekt - javascript aus VIS wird jeweils im Browser ausgeführt, auf dem die VIS Seite dargestellt wird ... Das kann dann zum Teil schon "interessant" werden, wenn man irgendwelche steinalten abgelegten Tablets mit Android 4.4 zur Darstellung der VIS-Seiten nutzen will ...

[OliverIO]

@martinp sagte in Javascript in VIS ausführen:

meines Wissens ist das, was @Ro75 schreibt korrekt

hab nix anderes geschrieben.

die performance hängt aber nicht allein von der Anzahl an Bindings oder skripte im skripte tab zusammen.
jedes einzelne widget ist ja ebenfalls per javascript definiert und führt zu mehr Belastung auf dem Rechner und irgendwann ist bei jedem Rechner schluss wo es noch Spaß macht

[Ro75]

@oliverio du hast aber leider deinen Beitrag nachträglich geändert gehabt. Jetzt steht es etwas anders da, bezogen auf den letzten Satz. EDIT ohne Hinweis ist für alle Lesenden schlecht.

Ro75.

[OliverIO]

@ro75
ja korrekt.
der edit erfolgte wenige sekunden nach dem ersten post.
wenn ich korrektur lese, dann fällt mir meist noch was ein

in der korrektur habe ich aber den sinn nicht verändert, sondern nur verdeutlicht.
bspw skripte tab iobroker ergänzt mit wird auf dem server ausgeführt, und das selbe entsprechend mit dem client ergänzt

[MarcIO]

@oliverio said in Javascript in VIS ausführen:

Wenn du mehr Kombinationen hättest, dann wird dieser so genannte ternary Operator schnell unübersichtlich.

Mehrere Kombinationen sind nicht nötig, aber mehr Variablen würden in Frage kommen. Sollte ich die Struktur beibehalten, wenn ich mal angenommen das selbe Spiel mit 10 Variablen mache?

[OliverIO]

@marcio

Hatte ich direkt darunter geschrieben. Darüber sind wir auf das Script Thema gekommen.
Dann baut man am besten im Skript Tab eine eigene javascriptfunktion die man dann direkt aus demnbinding heraus aufrufen und verwenden kann

[Homoran]

@oliverio
@Ro75

ja, fehlende Kennzeichnung von Edits ist immer unschön!

und ja! in diesem Fall war da keine Änderung des Inhaltes, nur eine Ergänzung.
Das geht.

[MarcIO]

@oliverio

Dieser Code hat leider nicht funktioniert

var M1_Friction = getState("0_userdata.0.Garage.Motor1_Friction").val;
var M1_Impact = getState("0_userdata.0.Garage.Motor1_Impact").val;
var M1_Temperature = getState("0_userdata.0.Garage.Motor1_Temperature").val;

if (M1_Friction<=8 && M1_Impact<=23 && M1_Temperature<=42)
{
    setState("td_css_background-color",'lightgreen');
}
 else if (M1_Friction>8.5 || M1_Impact>24 || M1_Temperature>43)
 {
    setState("td_css_background-color",'#ff6633');
 }
 else 
 {
    setState("td_css_background-color",'yellow');
 }

Ne Idee was hier verkehrt ist?

[OliverIO]

@marcio

Hast du eine Fehlermeldung?
Wenn nein, dann sind die Werte in einem Bereich, der durch die Abfragen nicht abgedeckt sind
Baue bitte mal noch die Ausgabe der Werte auf der console mit ein, dann kann man das auch prüfen.

[MarcIO]

@oliverio

Ja schaut so aus

Kann es sein, dass die getState-Funktion nicht kompatibel ist?

[Ro75]

@marcio das was im JS-Adapter möglich ist, funktioniert nicht gleichbedeutend im Tab "Scripte" der VIS.

Deswegen wäre esaus meiner Sicht günstiger, alles in JS-Dapte zumachen, das Ergebnis in einen DP zu speichern und diesen dann per {Datenpunkt} in der VIS einbinden.

Ro75.