HACS Entity Cards

[tsb2001]

Anbei wie immer der YAML-Code, aber derzeit noch ohne Sensoren also mit hardcodierten Werten.

Ich habe es jetzt mal eingefügt. Ist genial.
Wo ich aber grade dran scheitere, ist die Verknüpfung mit den Entitäten bei "label" und bei "custom_fields".
Die sind ja mit 1,3kWh bzw 90% festgeschrieben. Wie bekomme ich da die Entitäten rein?

[scw2wi]

Wie bekomme ich da die Entitäten rein?

Was genau ist die Frage?

Es geht ja wohl nicht darum, wie man so Zeile wie

entity: input_number.dummy_leistung
return '1.3 kW';

durch

entity: sensor.meine_leistung
return states['sensor.meine_leistung'].state;

ersetzen kann, oder doch?

[tsb2001]

ersetzen kann, oder doch?

Doch! Genau das!
Ich habe deinen Code kopiert, bin aber absolut zu dämlich, die Stelle zu finden, wo die Entitäten wie definiert werden und wie deren Rückgabewert an die passenden Positionen gerückt werden können.

Hier:

      show_label: true
      label: |-
        [[[
          return '9.5 kW';
        ]]]​

setzt du zum Beispiel den Wert der PV auf 9,5kW fest. Ich habe absolut keinen Plan, wie ich die 9,5kW dort gegen die Variable der tatsächlichen Leistung (wäre bei mir sensor.fronius_mppt_module_3_dc_power) austausche.

[scw2wi]

Ich habe absolut keinen Plan, wie ich die 9,5kW dort gegen die Variable der tatsächlichen Leistung (wäre bei mir sensor.fronius_mppt_module_3_dc_power) austausche.

Versuch mal, die hardcoded Zeile durch sowas zu ersetzten.

      show_label: true
      label: |-
        [[[
          const val = parseFloat(states['sensor.fronius_mppt_module_3_dc_power'].state);
          return (val / 1000).toFixed(1) + " kW";
        ]]]
​​

und passe auf, dass die Einrückungen exakt erhalten bleiben.

Ich hab festgestellt, dass die meisten KIs solche simplen Fragen präzise und ohne Halluzination beantworten können, da sie sehr gut mit js- (und auch jinja-) Templating umgehen können. Du kannst es ja einfach mal ausprobieren, was sie dir antworten.

[tsb2001]

scw2wi
Genau danach habe ich gesucht.
Das hat zwar erst nicht funktioniert, da ich nur noch einen drehenden Kreis anstatt die Vorschau hatte - speichern war nicht möglich.
Dann habe ich den Code noch bei ChatGPT eingekippt und heraus kam das (was auch funktioniert):

show_label: true
label: >
  [[[
    const x = parseFloat(
      states['sensor.fronius_mppt_module_3_dc_power']?.state || 0
    );
    return (x / 1000).toFixed(1) + ' kW';
  ]]]
​

Da musste ich zwar erst noch die Einrückungen passend setzen, aber dann kam auch direkt der Wert in der Vorschau.

Ich wusste einfach nicht, das man die Variable mit parseFloat holen kann und dann den Rückgabewert mit return als Ergebnis einblenden kann.

Vielen Dank!!!

[Tom Bombadil]

Die eckigen Klammern `[[[ ]]]` kennzeichnen den Einsatz einer JavaScript-Funktion (statt festem Text). Will man deren Ergebnis als Wert verwenden, muss sie an die "aufrufende Stelle" per `return <wert/funktion>` zurückgeben. Innerhalb der Klammern stehen die ganze Welt und alle Möglichkeiten von JS zur Verfügung.

Das ist übrigens von Rom Rider spezifisch so in der custom:button-card implementiert. Andere Karten beherrschen die Integration von JS entweder gar nicht, oder rufen JS anders auf (z.B. per `$fn(JS)` in plotly-Graphen). Pro Tip dazu: Wenn man "Nicht-JS-fähige-Karten" als Unterelemente auf einer button-card platziert, "erben" diese Karten die JS-Funktionalität, und man kann trotzdem überall [[[ ]]] verwenden.

Mehr Beispiele in der Doku - ich empfehle auch sehr, mal über diesen langen Thread mit extrem vielen Beispielen und Lösungen drüberzufliegen.

/tom

[scw2wi]

Manche sagen, dass man durch ChatGPT nichts mehr lernt, bei mir war genau das Gegenteil der Fall, ohne ChatGPT hätte ich das alles nicht so rasch gelernt.
Du kannst dir auch noch überlegen, ob du bei Nicht-Verfügbarkeit des Sensors einfach 0 anzeigen möchtest, oder nicht. Beides hat Vor- und Nachteile.

[tsb2001]

Andere Karten beherrschen die Integration von JS entweder gar nicht, oder rufen JS anders auf (z.B. per `$fn(JS)` in plotly-Graphen).

Und damit begann grundsätzlich mein Problem:
Ich wusste nichtmal, dass diese drei eckigen Klammern bei genau dieser Karte eine JS-Funktionalität beinhalten.
Und wenn man nicht weiß, was man chatGPT fragen muss, weil die Grundlage fehlt, kommt auch da kein brauchbares Ergebnis bei raus…
Die Initialzündung habe ich nun dankenswerterweise durch dich und scw2wi erhalten und habe den Rest problemlos anpassen können.
Manchmal sind es die kleinen Dinge, die vorausgesetzt werden, aber einfach nicht vorhanden sind…

[scw2wi]

Templating ist bei HA leider nie konsistent eingeführt worden, und bei HACS macht ohnehin jeder was er will. Es wäre nicht schlecht, wenn einfach jede HA-Standard-Card das Jinja-Templating beherrschen würde, dann könnte man sich etliche Templating Sensoren sparen. Ich hab nur das Gefühl, dass HA gerade in der Gegenrichtung unterwegs ist, und stark von YAML in Richtung GUI-only tendiert. Das macht die Sache zwar für Einsteiger etwas leichter und hat auch Vorteile bei Breaking-Changes, aber viele verlieren bei GUI-only zu rasch den Überblick und auch ich bin schon lange von den YAML-Vorteilen überzeugt.

[Tom Bombadil]

Ich hab nur das Gefühl, dass HA gerade in der Gegenrichtung unterwegs ist, und stark von YAML in Richtung GUI-only tendiert.

Ja, genau das beobachte ich derzeit auch (mit Sorge). Mehr 'GUI', weniger 'YAML' wird die Möglichkeiten von Lovelace sehr wahrscheinlich weiter limitieren, statt sie zu erweitern. Dabei bleiben andere, in meinen Augen wichtige Dinge (wie z.B. include von externen Dateien im YAML, Unterstützung von YAML-Ankern, wie sie das HA-Backend schon lange kennt) leider seit Jahren auf der Strecke ...

/tom

[tsb2001]

Standard-Card das Jinja-Templating beherrschen würde

Dann hätte ich die Frage gar nicht stellen müssen…

Tom Bombadil : Ich versuche alles noch in yaml zu halten. Es macht zwar mehr Tipparbeit, am Ende ist es aber eindeutig.
Ich hatte als Zwischenlösung von Homematic im Bad einen Heizkörperthermostat, der natürlich darüber durchs GUI konfiguriert wurde. Alleine diesen komplett zu eliminieren und auf KNX umzuziehen, hat die Climate-Funktion fürs Bad durch das Umkonfigurieren drei mal angelegt.
In yaml eine unique_id für Climate des Raumes angelegt und man könnte einfach umziehen. Egal ob die Basis Homematic oder KNX sein würde…

[tsb2001]

Ich hab da noch ein ganz anderes Problem:
Eigentlich wollte ich die Karte auf dem NSPanel Pro darstellen. Offensichtlich ist aber in dem Android WebView JavaScript deaktiviert. Unter normalen Browsern sieht es normal aus:
IMG_0084.jpg
auf dem NS-Panel so (die Qualität ist natürlich besser):
IMG_4271.jpg
Schade, denn es scheint nicht möglich zu sein, das zu aktivieren…
Daher werden offensichtlich die JS-Bereiche blockiert und nicht angezeigt.

[Tom Bombadil]

tsb2001Schau Dir mal nochmal den Post #5 in diesem Thread an (ggf. auch #3 gleich darüber). Da hatte ich mal versucht, die Zusammenhänge YAML + Jinja Templates (HA Backend) sowie YAML + Javascript (Lovelace Frontend) zu erklären.
Die Sache mit [[[ ]]] war da auch schon erklärt, hab sogar Bilder dafür gemalt ...

/tom

[tsb2001]

Die Sache mit [[[ ]]] war da auch schon erklärt, hab sogar Bilder dafür gemalt ...

Kennst du das?
Du suchst gewaltsam an einer Lösung, möchtest Ergebnisse haben und hast irgendwann 20 Tabs auf, ließt derweilen alles nur noch quer und siehst dabei den Wald vor lauter Bäumen nicht mehr?
Genauso geht es mir häufig.
Teilweise sind da brauchbare Treffer bei, die man verwendet. Manchmal stehen die direkt vor einem in irgendeinem Thread, aber man übersieht das…

Nun habe ich es verstanden. Vom Grundsatz her tatsächlich gar nicht mal so schwer.

Was mich jetzt noch interessieren würde:
Bei der custom:button-card hat der Entwickler die Karte so programmiert, dass mit der Einleitung der eckigen Klammern dieser Code als JS verstanden und abgearbeitet wird. Damit kann man direkt via JS auf die Entitäten innerhalb Homeassistant zugreifen. Soweit richtig?

Nun frage ich mich aber: wie „holen“ sich die anderen Karten ohne JS die Daten aus der Datenbank ab?

Die Frage kommt deshalb auf, da mir auf dem NS-Panel Pro alle Karten sauber mit Werten dargestellt werden, die Karte mit JS allerdings die Werte nicht anzeigt. Also muss es ja eine weitere Möglichkeit geben, auf die Entitäten zuzugreifen. Muss das in der custom:button-card unbedingt JS sein, oder kann man das auch via „entity:“ im abfragen?
Sprich: gibt es eine Möglichkeit hinter dem „label:“ auch ohne der eckige Klammern und somit ohne JS an die Werte zu kommen?

[Tom Bombadil]

Bin unterwegs, daher nur kurz: Karten sind nichts anderes als grosse JavaScripts, siehe zB diese Karte (Screenshots findest Du auf der Hauptseite des Repos). Wenn Du einen neuen Kartentyp zu Lovelace hinzufügst, passiert das immer im Hintergrund über den Import eines weiteren JS.

Aber nicht alle Karten lassen Dich zusätzliches, eigenes JS schreiben - und wenn, dann oft auch nicht bei allen innnerhalb der Karte definierten Attributen. Ich vermute, das macht einiges an Mehraufwand, insbesondere im Hinblick auf Sicherheitsfragen.

Warum das in Deinem NS Panel Pro nicht funktioniert, ist aus der Ferne schwer zu sagen (grundsätzlich beherrscht das Ding ja JS, vielleicht in einer Sandbox, vielleicht beschnittener Befehlssatz - keine Ahnung). Bin aber auch kein 'Kartenprogrammierer, vielleicht hat da jemand anderes bessere Ideen ...

/tom