Probleme bei einer SQL Abfrage wenn eine Entität involviert ist

[Dirk069]

Hallo an alle

Nachdem ich mich nun unzählige Tage code testend und probierend durch etliche Foren gequält habe, wende ich mich nun mit meinem Problem an euch, in der Hoffnung, dass sich jemand auskennt und mir weiterhelfen kann

Mein HA-Recorder läuft über MariaDB, so dass ich auf dem Intel NUC, auf dem HA läuft, somit ja schon eine Datenbank zur Verfügung habe.
Ich möchte hier auch externe Daten einbauen, so dass ich der Einfachheit halber einfach in die Homeassistant Datenbank eine weitere Tabelle hinzugefügt habe, wo diese von mir eingetragen werden können.
Ich automatisiere mit HA u.a. mein Heimkino, und möchte zu Filmen, die auf der xBox abgespielt werden, weitere Daten heranziehen, die ich zu Automationszwecken nutzen möchte und in dieser Datenbank speichere (Bildformat, Spieldauer etc).

Ich sauge mir für die Automationen dynamisch aus den Attributen des xBox media player eigene Entitäten, welche ich in einer templates.yaml definiert habe. Funzt prima, und die hieraus entstandenen Automationen laufen auch super.

Für einige Daten, welche nicht “live” aus der xBox kommen können, brauche ich diese Datenbank. Hier möchte ich nun anhand des Titels den dazu passenden Datenbankeintrag anzeigen lassen mit den dort hinterlegten Daten.

Ich habe hierzu eine sql.yaml erstellt, auf die ich von der configuration.yaml aus verwiesen habe, wo ich meine SQL Abfragen Entitäten bilden möchte, was auch funktioniert.

Nun zum Problem:
Wenn ich als WHERE clause eine Entität heranziehe (die den Filmtitel enthält, nach dem ich suchen will), wirft mir die hier entstandene Entität ein “unknown” als Ergebnis aus.
Benutze ich genau die gleiche Abfrage, und tausche die Filmtitelentität gegen Worte aus (ich schreibe quasi einen Filmtitel direkt in die WHERE clause), kommt dagegen problemlos das Ergebnis mit den entsprechenden Daten aus der Datenbank.

Das hier funktioniert nicht, Ergebnis: “unknown”

- name: SQL_FilmDaten
  query: >
    SELECT
      *
    FROM
      x_kino_movies
    WHERE
      name = 'sensor.xbox_filmtitel'
    LIMIT
      1;
  column: "name"
  unique_id: "sql_filmdaten"

Das hier dagegen funktioniert:

- name: SQL_FilmDaten
  query: >
    SELECT
      *
    FROM
      x_kino_movies
    WHERE
      name = 'Ich bin ein Filmtitel'
    LIMIT
      1;
  column: "name"
  unique_id: "sql_filmdaten"

Die Entität “sensor.xbox_filmtitel” enthält auch den Filmtitel als Wert, wird auch nicht anders geschrieben als von mir im unteren Beispiel.

Ich bin mit meinem Latein am Ende. Übersehe ich etwas zu offensichtliches?

Danke für eure Hilfe!

 

[Nival]

Eventuell - nicht getestet - funktioniert es, wenn Du sensor.xbox_filmtitel austauschst durch {{ states("sensor.xbox_filmtitel") }}.

 

[Dirk069]

Leider ebenfalls erfolglos.Ich lasse inzwischen sogar nach der MediaContentID suchen, um evtl Missverständnisse beim Titel zu vermeiden. Auch wenn eine Abfrage ja zumindest ein Ergebnis hervorbringen sollte, wenn der Titel einen Eintrag hat.

Wie gesagt, auch hier, wird die Entität direkt durch den Wert ersetzt, geht's. Also muss die Abfrage ja funktionieren. Und die Entitäten haben ja Werte hinterlegt, ich lasse sie mir ja auch anzeigen:



Ich verstehe nicht, wie sich diese Abfragen jeglicher Logik entziehen Auch so eine logische Idee wie von dir.... Danke dafür dennoch!

 

[Nival]

Du hast in diesem Fall die einfachen Anführungsstriche drumherum ebenfalls mit weg gelöscht, das kann so in der Tat nicht funktionieren

name = '{{ states("sensor.xbox_filmtitel") }}' wäre es, wenn - SQL benötigt bei Strings zwingend die Anführungsstriche drumherum (bei Zahlen nicht zwingend).

Wenn Du {{ states("sensor.xbox_filmtitel") }} in den Entwicklerwerkzeugen unter Template einträgst wird rechts der richtige Name ausgegeben, richtig? Da der Name dieses Sensors auf Deinen Screenshots nicht erscheint ist die Frage notwendig

 

[carsten_h]

Ich habe nur zwei Dinge zu der SQL Abfrage, die aber mit Deinem Problem nichts direkt zu tun haben.
Das erste ist das „select *“. Damit werden ja sämtliche Felder in der Definitionsreihenfolge selektiert. Sobald man die Tabelle ändert, kann man hierbei auf die Nase fallen. Daher sollte man für „produktive“ Abfragen immer die richtigen Felder in der gewünschten Reihenfolge angeben.
Das zweite ist das „Limit 1“, das ich genauso gerne sehe wie „distinct“. Es ist dabei bei eigentlich mehreren Datensätzen nicht vorhersagbar welchen Datensatz man zurückgeliefert bekommt. Das kann der physikalisch erste Satz, durch Sortierung aber auch irgendein Satz sein, je nachdem wie der Optimizer der Datenbank sich gerade fühlt.

Das aber nur als Randbemerkung von einem, der sich seit 1988 mit SQL (meist Oracle) beschäftigt und gerade nichts besseres zu tun hat. Aber gleich geht es ans Meer auch wenn es eigentlich nur ein See ist.

 

[Dirk069]

Wenn Du {{ states("sensor.xbox_filmtitel") }} in den Entwicklerwerkzeugen unter Template einträgst wird rechts der richtige Name ausgegeben, richtig? Da der Name dieses Sensors auf Deinen Screenshots nicht erscheint ist die Frage notwendig

Ja das funktioniert

Ich hab jetzt auch mal die einfachen Anführungszeichen dringelassen, jedoch nach wie vor kein Erfolg:



Das Gleiche nochmal mit Klartext in den Definitionen:




Woraus ich schonmal schliesse, dass die Abfrage an sich funktioniert.
Ist nur , dass er meine Variablen nicht schluckt, auch wenn sie an sich den gleichen Inhalt haben

 

[Nival]

Sieht nach den Logs leider wirklich so aus, als ob da nichts übersetzt wird - die Verwendung von Variablen scheint nicht vorgesehen zu sein.

Wenn man etwas weiter sucht gibts auch andere Personen mit dem gleichen Problem und ohne Lösung: https://community.home-assistant.io/t/add-support-for-query-template-to-sql-integration/188760/7

 

[Dirk069]

Das ist echt Mist

Ich hab mal in deinem angehängten Forum Post gevoted, in der Hoffnung ein Entwickler nimmt sich der Sache mal an.
Echt blöd, in einer Sackgasse zu verenden

Immerhin war mein ursprünglicher Ansatz wohl nicht unbedingt Schuld, das beruhigt.

Danke auch für deine Hilfe, ich behalte die beiden Varianten im Auge, falls sich von der Entwicklerseite was tun sollte irgendwann