Test lovelace 4.x

[kipferl]

@garfonso

So, hab das soweit hinbekommen, das es zumindest funktional ist, wenn auch nicht besonders elegant.

Für die, die das nachmachen wollen beim daikin cloud adapter:

Ich habe zuerst mal die states richtig gesetzt im Objekt von der Klimaanlage direkt, die waren warum auch immer bei mir nicht korrekt.

Dann hab ich mittels Geräte Adapter wie oben beschrieben ein Klimagerät angelegt und hier im alias objekt einen 5 state für "OFF" hinzugefügt.

Damit wird das richtig in Lovelace erkannt, da ein/ausschalten bei der Daikin kein Mode ist. Mit diesem Blockly funktioniert dann die Steuerung soweit richtig.

Die bei der daikin für die 3 Temperatur Modes je eine eigene Temperatur gespeichert wird, hab ich hier im unteren Teil das einfach an die "cool" Temperatur angeglichen, da ich die Klima primär in dem Modus verwende, sollte das auch nicht zu viel Konflikte mit der Daikin App haben. Ich weiß, nicht besonders elegant, aber momentan für mich ausreichend.

[Garfonso]

@kipferl
Ich würde nur die States hinzufügen, die du auch unterstützt. Und der lovelace-Adapter baut dir den extra on/off state auch in die Modes ein, wenn der im Gerät richtig drin ist (also als Power-State).

[kipferl]

@garfonso

alles klar, hab ich ausprobiert, der schickt mir aber nur "ausschalten" soll das so sein?

[Garfonso]

@kipferl

Was meinst du genau? Also so sieht bei mir das Gerät aus (im Geräte-Tab editiert, unten ist auch noch swing bzw. die Zustände für aktuelle Temperatur usw., an der Lüftergeschwindigkeit musste ich offensichtlich auch etwas fummeln, ich glaube, die kann ich in % einstellen und lovelace / ioBroker erwartet da feste states):

Der Mode-State sieht so aus:

{
  "type": "state",
  "common": {
    "name": "Büro mode",
    "read": true,
    "write": true,
    "role": "level.mode.airconditioner",
    "states": {
      "0": "AUTO",
      "3": "COOL",
      "9": "FAN_ONLY",
      "14": "DRY"
    },
    "type": "number",
    "alias": {
      "id": {
        "write": "openknx.0.Klima.Büro.Mode",
        "read": "openknx.0.Klima.Büro.Mode_Status"
      }
    },
  }
  "native": {},
  "_id": "alias.0.aircondition.Buero.mode",
  "from": "system.adapter.javascript.1",
  "user": "system.user.admin",
  "ts": 1660499900658,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

so sieht das erstellte Entity mit den Attributen aus:

so sieht das in der UI aus (normale Thermostat-Karte, allerdings etwas schmaler, weil in einem horizontal stack):

Man sieht für die (lovelace bekannten) States einzelne Knöpfe im UI. Wenn ich auf einen klicke, wir der Power-State auf "true" gestellt und, falls notwendig, mode gesetzt. Und wenn ich auf den aus-Knopf drücke, wird der Power-State auf false gesetzt.

Was davon funktioniert bei dir genau nicht?

[kipferl]

@garfonso
Das funktioniert bei mir auch genau so. Der Ein/Aus schalter, schaltet bei mir nur aus, also ist es eigentlich ein Aus Schalter. Wollte nur wissen ob das so gedacht ist.

[Jey Cee]

Hat schon mal jemand die Logbuch Karte genutzt?

Wo muss man das aus der Meldung eintragen?

[Garfonso]

@jey-cee

Wenn ich das richtig verstehe, geht das im ioBroker nicht über die config. Der Adapter liefert eine feste Liste an Komponenten aus. Das liegt auch daran, dass die Komponenten immer auch support im Adapter brauchen (i.e. eigene Requests schicken, die der Adapter beantworten muss).

Beim logbook ist das schon einiges und die struktur unserer "history" ist halt deutlich anders. Keine Ahnung, ob man da alle Einträge nach Zeitraum abrufen kann (und ob der user da verzeichnet ist, weiß ich auch nicht... ).

[Jey Cee]

@garfonso ok dann brauch ich da nicht weiter Testen. Wäre halt schon sehr cool gewesen, vielleicht irgendwann in der Zukunft.

Danke für deine Antwort.

[Garfonso]

@david-g
dazu nochmal:

• ich konnte auch, obwohl er gemeckert hat, mit dem UI Editor einen relativen Pfad eintragen. Ansonsten halt mit dem Code-Editor
• wenn ich /adapter/ vorne an den Pfad hänge, wird die Seite lokal geladen (hat mir allerdings den Browser-Tab erstmal unbrauchbar gemacht, das kann aber auch dran liegen, dass das im Debug-Testssystem war, was eh aktuell etwas zerschossen ist...)

-> ich hab aber auch keine Ahnung von eCharts und weiß nicht, was da gehen muss.
kannst du das damit nochmal versuchen?

[David G.]

@garfonso

Nochmal getestet.
Am Desktop konnte ich das jetzt auch eintragen (Evtl war ich am Smartphone auch was zu ......).

Das Ergebnis sieht dann folgendermaßen aus:

Die Karte zeigt mir unknown an.

Bei der kompletten URL zeigt er es dann an:

[Garfonso]

Ansonsten: ein kurzes Status-Update / frustriertes Jammern / Meinungsabfrage.

Neues Frontent (Status)

Ich bin gerade dabei das frontend zu aktualisieren auf eine 2023.06.* Version. Aktuell gibt es noch einen großen Blocker: Die sidebar mag nicht weggehen... Da hat sich was am Code geändert. Ich bin leicht versucht es aufzugeben und zu gucken, ob wir die nicht lassen und damit auch Dashboardsunterstützung bekommen und gucken, ob wir da nicht einfach alles unnötige rausschmeißen können. Aber... äh.. das ist nur gerade eine fixe Idee.
Für eine Visualisierung auf einem Wand-Tablet ist das vielleicht auch blöd. Wie machen das denn die HomeAssistant Leute? Haben die echt die ganze UI auf so einem Wand-Tablet oder kann man Dashboards gezielt einzeln anzeigen (das wäre vielleicht sogar die einfachste Lösung.
Aber eine gute Nachricht: Bisher hat der Adapter immer behauptet, dass er ein uraltes HomeAssistant ist, sonst wurde das UI nie fertig geladen. Das konnte ich jetzt mal analysieren & beheben. Auf den ersten Blick ändert das nicht viel... aber es gibt schon ein paar Stellen, wo das Frontend sich die Version angucken. Mal sehen

Entity Settings & Entity ID

Dann hatte ich überlegt, aktuell sind die "entity-Settings" komplett ausgeblendet. Das könnte ich ändern und die settings einfach in einem State (oder sowas) speichern. Damit könnte man dann im UI Namen und Symbol für ein entity anpassen und müsste das nicht auf jeder Karte einzeln machen (oder in den Objekten fummeln, bis es passt). So sieht das im Original aus:

Vermutlich sollte man da einige Sachen ausblenden (insbesondere das "deaktivieren", das hat mich einige Zeit gekostet ein entity dann wieder zu aktivieren in HomeAssistant beim rumspielen. g). Dazu Meinungen? (Wäre über ein Zahnrad-Symbol im more-info vom entity zu erreichen).
Damit verbunden denke ich auch aktuell wieder über die entity_ids nach... irgendwie knallt es mir da zu oft (also gleiche IDs). Wenn ich aber eh pro entity (potentiell) ein Setting speichere, brauche ich da eine eindeutige ID (hat HomeAssistant auch) -> die würde ich dann aus der ObjektID generieren und könnte damit Konflikteauflösen und die entity_id abwandeln und dauerhauft speichern (aktuell geht das nicht, wenn ich z.B. einfach eine 1 anhänge, könnte es bei einem Neustart dazu kommen, dass die entities in anderer Reihenfolge erstellt werden und daher light.xy und light.xy1 ständig die ioBroker-Objekte tauschen g).
Man könnte dann in den entity-settings auch die ID selber festlegen (inklusive Prüfung durch das frontend ob die ID schon existiert, yay). Und die ID würde sich auch nicht ändern, wenn man den Namen vom Objekt ändert. Vielleicht mache ich dann auch eine Option, wie man die IDs gerne (erstmalig) generiert haben will. Hm. (wobei ich vielleicht sogar die Einstellungen auf eine neue ID konvertieren könnte).

Logbook

Vielleicht kriege ich es doch hin. Die Karte will ja eine liste von entities (es gibt noch ein Dashboard, was alle Änderungen zeigt, aber auch das könnte gehen, auch wenn das einige Abfragen wären)...

So sieht das aktuell in meinem recht leeren HASS-Testsystem aus. Ich glaube, User bekomme ich in ioBroker nicht, aber den adapter, der es geändert hat. Wie ist da die Meinung bei euch? Das mit dem "ausgelöst durch Dienst" finde ich nicht sehr hübsch. Aktuell tendiere ich dazu zu gucken, ob ich den Adapter nicht dahin bekomme, wo der User steht (was allerdings komplizierter sein könnte). Hm.

So, das nur als kleines Update und eure Meinung zu den Ideen (entity settings, Dashboards und Logbook) würden mich interessieren.

Ob ich vor dem Urlaub nochwas brauchbares zum Testen hinbekomme, weiß ich noch nicht genau, das ist aber eigentlich mein Ziel. (achja, wer testen möchte, sollte schonmal für alle custom_cards nach Updates gucken).

[A Former User]

Für eine Visualisierung auf einem Wand-Tablet ist das vielleicht auch blöd. Wie machen das denn die HomeAssistant Leute? Haben die echt die ganze UI auf so einem Wand-Tablet oder kann man Dashboards gezielt einzeln anzeigen (das wäre vielleicht sogar die einfachste Lösung.

Um die frage zu beantworten:
Man kann die Seitenleiste ausblenden, der Button ist dann oben links womit man sich die wieder anzeigen lassen kann. Um das und das andere Zeugs in der Menübar komplett auszublenden braucht man das Addon browser mod. Anders geht das soweit ich weiss nicht in HA.

[David G.]

@garfonso sagte in Test lovelace 3.x:

Die sidebar mag nicht weggehen...

Meinst du diese Sidebar?

Wenn man die konfigurieren kann wäre die schon cool.
Wenn man darüber zB die obere Navigation ändern könnte (was vermutlich nicht geht).
Am Rand den Raum auswählen und oben dann Licht - Sicherheit - etc

@garfonso sagte in Test lovelace 3.x:

Damit könnte man dann im UI Namen und Symbol für ein entity anpassen und müsste das nicht auf jeder Karte einzeln machen

Fand ich cool (auch wenn ich es nicht bräuchte, da ich wenige Sachen doppelt habe)

@garfonso sagte in Test lovelace 3.x:

So sieht das aktuell in meinem recht leeren HASS-Testsystem aus. Ich glaube, User bekomme ich in ioBroker nicht, aber den adapter, der es geändert hat. Wie ist da die Meinung bei euch? Das mit dem "ausgelöst durch Dienst" finde ich nicht sehr hübsch. Aktuell tendiere ich dazu zu gucken, ob ich den Adapter nicht dahin bekomme, wo der User steht (was allerdings komplizierter sein könnte). Hm.

Das Logbook ist auch cool^^.
Aber nur, wenn man definieren kann welche States angezeigt werden.
Für mich müsste man dort garkeinen Namen oder Adapter stehen haben. Was bringt es mir, wenn da javascript.0 oder lovelace steht, mehr würde es bei mir seltenst sein. User habe ich im ioBroker nicht gepflegt.

[Garfonso]

Nochmal ein update.

Sidebar bekomme ich jetzt doch ausgeblendet.
@David-G:
Ja, das meine ich. Man kann (zusätzliche) dashboards definieren, die dann da angezeigt werden. -> damit könnte man dann rechts ein Menü haben und obendrüber. Hm.

Beim Logbook bin ich auch weiter gekommen. Allerdings verstehe ich gerade nicht, warum ein live-update nicht geht... das frontend unsubscribed die Änderungen immer, wenn ich ein Update schicken will... Hab bisher noch nicht rausgefunden, was HASS da anders macht. Vermutlich irgendwo was subtiles.

So sieht es aktuell aus (mit dem adapter da klein, finde ich schon ganz nice):

[Jey Cee]

@garfonso sagte in Test lovelace 3.x:

Entity Settings & Entity ID

Ich frag jetzt mal ganz Dumm: Warum ist es nicht möglich einfach ioBroker Objekte direkt in Lovelace zu verwenden?
Das einzeln zu Aktivieren finde ich schon Mühsam.
Klar man müsste immer noch den Entitätstyp und den Modus anpassen können, aber die Automatische Erkennung ist ja schon ziemlich gut.

Es wäre auch super wenn die Entity ID einfach die ioBroker ID ist.

@garfonso sagte in Test lovelace 3.x:

Ich glaube, User bekomme ich in ioBroker nicht, aber den adapter, der es geändert hat. Wie ist da die Meinung bei euch?

Ich fände es schon gut wenn man den User da auch rein bekommt.

@garfonso sagte in Test lovelace 3.x:

Beim Logbook bin ich auch weiter gekommen.

Hey du bist Super. Danke für die Bemühungen.

[David G.]

@jey-cee sagte in Test lovelace 3.x:

Ich frag jetzt mal ganz Dumm: Warum ist es nicht möglich einfach ioBroker Objekte direkt in Lovelace zu verwenden?

Das wäre ein Träumchen.
Wobei es dann in dem Dropdown in Lovelace sehr viel und unübersichtlich würde. Mn kann dort ja nicht seine Ordnerstrucktur durchgehen um einen DP zu finden.

[Garfonso]

@jey-cee said in Test lovelace 3.x:

Das einzeln zu Aktivieren finde ich schon Mühsam.

Wenn du Zeug einzeln aktivierst, dann machst in den meisten Fällen was falsch. Nutze die Geräte Ansicht + Raum & Funktion, dann geht doch das meiste völlig alleine.

Und damit sind wir auch schon beim Hintergrund:
wenn alles automatisch geht, hast du deinen ioBroker halbwegs aufgeräumt oder nutzt Adapter, die z.B. Rollen halbwegs ordentlich vergeben und sich so verhalten, dass type-detector eine Chance hat. Dann weiß auch der lovelace-adapter, was das für Zeug sein soll, was du da hast und kann das automatisch in HomeAssistant Geräte (entities) zusammen basteln (z.B. eine Lampe, die auch Farbe und Helligkeit steuern kann usw.). Da sind die Geräte halt viel statischer, das hat den Vorteil, dass das frontend besser darauf reagieren kann (z.B. ein binärer-sensor bei einer Tür, sagt dann im Frontend, dass die Tür zu ist und nicht dass der Sensor wahr/falsch ist). Aber umgekehrt muss der lovelace-adapter die ioBroker-Anarchie bewältigen und da irgendwie reinfummeln.

Braucht ihr wirklich alle ioBroker Objekte? Was sollten die dann für entitäten sein? So wie die default Funktion das macht für custom? Ich könnte das als Option machen.

@david-g said in Test lovelace 3.x:

Wobei es dann in dem Dropdown in Lovelace sehr viel und unübersichtlich würde. Mn kann dort ja nicht seine Ordnerstrucktur durchgehen um einen DP zu finden.

Ne, gibt es nicht.
Es gibt zwar mittlerweile irgendwie Geräte, die entities zusammen fassen. Aber das ist nochmal etwas anders.

@jey-cee said in Test lovelace 3.x:

Es wäre auch super wenn die Entity ID einfach die ioBroker ID ist.

Ja, das überlege ich (also es müsste halt noch die Domain davor). Früher war das nervig, weil man die oft tippen musste. Aber mittlerweile sollte das recht easy sein. Eigentlich (tm) müsste ich die auch konvertieren können.

@jey-cee said in Test lovelace 3.x:

Ich fände es schon gut wenn man den User da auch rein bekommt.

Ich guck mal, ob history den User speichert.

[David G.]

@garfonso sagte in Test lovelace 3.x:

Ich guck mal, ob history den User speichert.

So weit ich weiß nur die Herkunft vom Adapter.

EDIT

[Jey Cee]

@garfonso sagte in Test lovelace 3.x:

Braucht ihr wirklich alle ioBroker Objekte?

Nein nicht unbedingt, es wäre ja schon ausreichend wenn er dann die nimmt die sich Automatisch erkennen lassen.
Das als default und man kann sofort Anfangen Dashboards zu Bauen.

@garfonso sagte in Test lovelace 3.x:

Nutze die Geräte Ansicht + Raum & Funktion, dann geht doch das meiste völlig alleine.

Ehrlich gesagt weis ich jetzt gerade nicht mal wo das ist.

[David G.]

@jey-cee sagte in Test lovelace 3.x:

Ehrlich gesagt weis ich jetzt gerade nicht mal wo das ist.

Wenn du deinen DPs Raum und Funktion gibst, werden die Geräte automatisch vom Type Detektor im iobroker erkannt auch in Lovelace bereitgestellt.

Macht besonders Sinn bei Geräten, die mehrere DPs haben. Zb Lampen, dort gibt's ja oft an/aus / Helligkeit / Farbe etc. Dann kann man das alles über die eine entity steuern.

Viele Adapter legen alles schon entsprechend an (Zb Zigbee), dort muss man nur einen Raum vergeben.
Falls nicht muss man sich über den Devices Adapter (oder ein Alias) das Gerät selber erstellen.

Hab aber selber auch gaaaanz viele DPs über das Zahnrad hinzugefügt. Finde ich oft schneller als alles zu vergeben. Besonders wenn ich mir selber Karten zusammenbastel.