Test lovelace 4.x
-
@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.
-
@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. -
@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.
-
@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
-
@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.
-
@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.
-
@jey-cee said in Test lovelace 3.x:
Nein nicht unbedingt, es wäre ja schon ausreichend wenn er dann die nimmt die sich Automatisch erkennen lassen.
Das macht er.
Alle Objekte, die Raum & Funktion zugewiesen haben (das könnte man diskutieren, ob man das weglässt) und die der type-detector als irgendwas erkennt, kommen als automatisch generierte Entities rein.Was der type-detector so erkennt, kannst du im Admin im Geräte-Tab sehen (ist keine lovelace spezifische Sache, das nutzt auch iot & materialize -> wenn die Geräte einmal "aufgeräumt" sind, geht es direkt mit mehreren Adapter automatisch). Wie gesagt, wie gut das mit den vorhandenen Objekten funktioniert, hängt leider etwas vom Adapter ab, wo die herkommen (und ob er überhaupt ne Chance hat, z.B. KNX kann dir kaum was über die Datenpunkte sagen). Jenachdem muss man dann halt mit Alias-Geräten basteln.
Ich hab überlegt, ich könnte versuchen einzubauen, dass der Adapter guckt, ob er ein ioBroker-Objekt mit der ID findet, wenn er eine unbekannte entity_id gibt und das dann einfach aktiviert. Dann könnte man einfach eine entity_id z.B.
binary_sensor.adapter.0.info.connectionim Frontend eintippen / einfügen und der Adapter aktiviert dann custom für das Objekt, falls es das noch nicht gab. kopfkratz (dann würde das "entity nicht gefunden" nach dem Speichern der Änderung im frontend dann plötzlich weggehen und der Wert dafür auftauchen, so zumindest in meinem Kopft -> während der Bearbeitung wäre die Vorschau dann aber noch nicht möglich, glaube ich, erst beim speichern). -
@garfonso
Nach ewiger Suche (Nummer !== String) geht nun logbook live update... yay
Den Rest hab ich erstmal so gelassen, wie er ist (sidebar hab ich geschafft auszublenden). Wer mag, kann von github installieren und mal gucken, wie das neue Frontend so ist und ob irgendwelche Fehler auffallen (könnte sein, dass da noch Zeug nicht geht, ich konnte bisher noch nicht alles testen).
Bei custom_cards könnte es sein, dass ihr da updates braucht. Die polymer-Bibliothek ist komplett rausgeflogen, das führt bei mir zu Fehlern bei einigen Karten (die in der Browser Konsole ausgegeben werden).
-
Wenn ich wie gewohnt von https://github.com/Garfonso/ioBroker.lovelace/tree/dev installiere Lande ich auf der 2.0.5?
Falscher link?
EDIT
Okay, dev war falsch ^^.EDIT 2
Bei mir scheint am ersten Blick alles zu klappen.
Nur die Farbe mancher Icons hat sich geändert. Mal sehen, was das ist.
Und einige Lampen zeigen negative Werte bei der Helligkeit an.Spiele heute Abend mal was mit rum.
-
Aus meiner Sicht läuft alles rund.
Was ich festgestellt habe
-
Manche Schaltflächen haben andere Farben als vorher (vermutlich muss das Theme aktualisiert werden)
-
Die Log Karte klappt wunderbar. Ich finde jedoch den Ursprung eher störend. Überlege was man sich so anzeigen lässt. Fenster, Türen etc. Diese Dinge haben meistens den selben Adapter. Bei den Fenstern sehe ich eben zig mal rpc.0
- Ich kann bei vielen Lampen die Helligkeit einstellen welche es eigentlich nicht können (vermutlich auch schon bei vorherigen Versionen?). Es betrifft Zb alle Lampen die an Steckdosen von Sonoff Adapter geschaltet werden. Dort gibt es zig Datenpunkte mit der Rolle "value" (rssi etc). Da nimmt er immer einen von als Helligkeit.
- Die Farben bei der Farbtemperarur werden anders dargestellt (liegt aber vermutlich an lovelace selber dass es dort geändert wurde). Früher konnte man von bläulich (kaltweiß) über weiß bis gelblich (warmes gelb) einstellen.
Jetzt sieht man optisch nur ich von weiß bis gelb im neuen Dialog.
EDIT
Kann man im Logbuch auch die Namen der entitys ändern?- nameklappt nicht und das neue Menü zum Namen und Symbol vergeben gibt's nicht. Hab überall recht lange Namen die das Gerät beschreiben.
-
-
@david-g sagte in Test lovelace 3.x:
Die Log Karte klappt wunderbar. Ich finde jedoch den Ursprung eher störend. Überlege was man sich so anzeigen lässt. Fenster, Türen etc. Diese Dinge haben meistens den selben Adapter. Bei den Fenstern sehe ich eben zig mal rpc.0
Ich hab nach der Karte gefragt weil ich Anzeigen wollte wer zuletzt eine Tür mit einem QR code geöffnet hat.
Dafür ist die Karte die einfachste Variante. -
Da würde mir über einen Umweg eine Lösung einfallen.
OFFTOPIC AN
Könnte klappen, noch nie so gemacht.Der angezeigte Adapter stammt ja aus der Histoty.
In der DB sind alle Adapter durchnummeriert angelegt.
Dort kannst du noch eigene "Adapter" hinzufügen. Diese könntest du nach Namen benennen.
Wenn du die Änderungen per Skript in die DB sendest (mache ich dir manches) kannst du die Nummern der Adapter mitsenden.Auf diesem Weg kannst du Namen anzeigen lassen.
EDIT
An sich klappt es.
Allerdings steht in der Log Karte jetzt nichts beim Adapter. Evtl holt sich lovelace den Namen nicht aus der History und die Werte sind im System auch nochmal hinterlegt welche Nummer welchem Adapter gehört....
Müsste man sich einen Pseudoadapter mit den Namen erstellen ^^
EDIT 2
Die QR-Codes lösen ja vermutlich ein Skript aus.
Man könnte ja für jede Person einen DP erstellen und parallel mit schalten und in die History schreiben. Den DP könnte man dann ja Zb "Tür von @jey-cee betätigt" nennen. -
@david-g said in Test lovelace 3.x:
Kann man im Logbuch auch die Namen der entitys ändern?
Der Name kommt entweder aus dem Objekt-Name oder common.smartName kann den auch setzen, meine ich.
Ja, das mit den entity settings hab ich noch nicht implementiert und das Zahnrad ist daher auch nicht drinnen (das hatte ich schon raus).@jey-cee said in Test lovelace 3.x:
Ich hab nach der Karte gefragt weil ich Anzeigen wollte wer zuletzt eine Tür mit einem QR code geöffnet hat.
Dafür ist die Karte die einfachste Variante.Das kann dann aber nur bei Änderungen, die passiert sind, während der Adapter lief (i.e. wo er die Änderung mit onStateChange mitbekommen hat -> da ist der User mit drinnen). Aus der History hab ich den User bisher nicht bekommen (es gibt zwar ein undokumentiertes User-Flag, was ich mal auf true gesetzt habe, aber ich vermute, dass User halt einfach nicht gespeichert wird, aktuell. Vielleicht bei anderen Daten-Speichern?).
Ich hab vor das als Option einzubauen, also dass man User oder Adapter oder nix (?) da sehen kann.@david-g said in Test lovelace 3.x:
Ich kann bei vielen Lampen die Helligkeit einstellen welche es eigentlich nicht können (vermutlich auch schon bei vorherigen Versionen?). Es betrifft Zb alle Lampen die an Steckdosen von Sonoff Adapter geschaltet werden. Dort gibt es zig Datenpunkte mit der Rolle "value" (rssi etc). Da nimmt er immer einen von als Helligkeit.
Vermutlich, an der Stelle hat sich nichts geändert...
@david-g said in Test lovelace 3.x:
Ich finde jedoch den Ursprung eher störend. Überlege was man sich so anzeigen lässt. Fenster, Türen etc. Diese Dinge haben meistens den selben Adapter. Bei den Fenstern sehe ich eben zig mal rpc.0
Naja, die Zeile bleibt eh da, egal ob da eine Quelle steht oder nicht (da steht ja auch die Zeit).
@david-g said in Test lovelace 3.x:
Allerdings steht in der Log Karte jetzt nichts beim Adapter. Evtl holt sich lovelace den Namen nicht aus der History und die Werte sind im System auch nochmal hinterlegt welche Nummer welchem Adapter gehört....
Müsste man sich einen Pseudoadapter mit den Namen erstellen ^^Der Adapter holt sich einmal beim Start alle Instanzen und macht diese dem frontend bekannt und schickt danach einfach das, was in state.from steht als "id" mit. Vielleicht reicht ein Neustart? Bzw. es muss auch ein Instanz-Objekt sein (keine Ahnung, ob das nicht Probleme gibt, wenn man da was reinbastelt? kopfkratz) -> aber ich mach ja ne Option, wo der User statt den Instanzen genommen wird. Sollte relativ einfach gehen.
-
So, Option für Logbook ist im github.
Adapter, User, Nix. -
@david-g danke für den Vorschlag, das ist eine Interessante Vorgehensweise.
Aber Tatsächlich schreibe ich sowohl den Namen, als auch den Code in einen Datenpunkt. -
@garfonso sagte in Test lovelace 3.x:
@david-g said in Test lovelace 3.x:
Ich kann bei vielen Lampen die Helligkeit einstellen welche es eigentlich nicht können (vermutlich auch schon bei vorherigen Versionen?). Es betrifft Zb alle Lampen die an Steckdosen von Sonoff Adapter geschaltet werden. Dort gibt es zig Datenpunkte mit der Rolle "value" (rssi etc). Da nimmt er immer einen von als Helligkeit.
Vermutlich, an der Stelle hat sich nichts geändert...
Ich frage mich nur, warum er jedes value nimmt. Musste ja eigentlich value.brughtnes oder so sein....
@garfonso sagte in Test lovelace 3.x:
Vielleicht reicht ein Neustart? Bzw. es muss auch ein Instanz-Objekt sein (keine Ahnung, ob das nicht Probleme gibt, wenn man da was reinbastelt? kopfkratz)
Neustart habe ich getestet. Ich vermute den "Adapter" muss es in echt geben.
-
@david-g said in Test lovelace 3.x:
Ich frage mich nur, warum er jedes value nimmt. Musste ja eigentlich value.brughtnes oder so sein....
Alles was zu dem regulären Ausdruck passt:
/^level(\.dimmer)?$｜^level\.brightness$/durch das?hinter der ersten Klammer ist auch einfach nurlevelerlaubt (ich fürchte, dass das historische Gründe hat?). -
Dann bastel in mir bei den Steckdosen ein Alias.
Hatte ich da nicht, da man bei einer neuen Steckdose genau den selben Namen vergeben kann.@Garfonso @all
Kann es sein, dass in der neuen Version die Verlaufsdaten auf der Map nicht angezeigt werden.
Diese fehlen mit komplett. -
mit der Map kann ich bestätigen Standort stimmt aber keine Verlaufsdaten
EDIT: generell gehen keine Verlaufsdaten (auch bei Temperatur etc.) wenn nicht gerade eine Mod.Card verwendet wird.
-
Bei mir haben die immer beklappt.
Bei allen Karten....
