Schwieriger Umstieg von Edomi zu Home Assistant - Erfahrung

[henfri]

und nicht meine ganze Tagesfreizeit mit irgendwelchen Nerd Programmierungen vergeuden.

Wir ging es bei EDOMI so, dass ich das Gefühl hatte Zeit zu verschwenden.
Ich denke mittlerweile, das ist eine Geschmacksfrage, wozu man einen besseren Zugang findet.

[tsb2001]

positioniert, also auch das geht, wenn man CSS kann.

Unvermögen des Users als des Tools.

Wenn ich css als Quasi-„Programmiersprache“ brauche, ist das kein Tool für Drag&Drop wie in EDOMI, sondern eine Entwicklungsumgebung und hat dann weniger mit Unvermögen des Users zu tun, sondern ist eher ein Äpfel-Birnen-Vergleich.

Ich habe selbst EDOMI nur kurz genutzt, weil ich keine Lust an diesem Anti-Responsive Gedöns hatte.
Ich habe es mal installiert und abgewogen, was besser für die Zukunft ist: alles auf eine Karte eines einzigen Entwicklers zu setzen; mit beschränkten Integrationsmöglichkeiten fremder Dinge und einem fixen Design, allerdings dann Pixelgenau. Erstgenanntes hat mich abgeschreckt; der Rest wäre zu verschmerzen gewesen.

Daher habe ich das nach zwei Wochen experimentierfreudigen Versuchen verworfen und bin zu HA gewechselt.
Das kann viel, aber ich tu mich unwahrscheinlich schwer, aus allen Karten irgend etwas brauchbares an Dashboards zu basteln, da einfaches Drag&Drop nicht möglich ist. Und das fehlt Homeassistant. Und da ich die Erfahrung in EDOMI machen konnte (das ging da viel einfacher), werden die Umsteiger damit nicht glücklich werden können. Homeassistant so zu verbiegen, dass da was ähnliches herauskommt, halte ich eher für unmöglich. Ich lasse mich aber gerne durch Ergebnisse überzeugen…

EDIT: Achso, css reicht ja nicht alleine, man sollte auch Fragmente von JavaScript beherrschen, denn auf selbstgestylten Karten geht die flexibel Positionierung nur, wenn man mittels JS die Daten aus Homeassistant holt.
In EDOMI ging’s mit einem einfachen Eintrag der „Entität“ in dem passenden Feld.

[scw2wi]

und nicht meine ganze Tagesfreizeit mit irgendwelchen Nerd Programmierungen vergeuden.

Es gibt viele Möglichkeiten, um zum Ziel zu kommen.

Edomi bietet dir ein pixelgenaues Dashboard maßgeschneidert für jedes deiner Devices. Das Ergebnis ist mit Sicherheit sehr individuell, da Wiederverwendung in Edomi den Aufwand auch nicht so stark vermindert.

HA bietet dir wesentlich rascher ein Dashboard mit dem HA typischen Look & Feel der Standard-Karten und lauffähig auf unterschiedlichen Devices. Dieses Look&Feel wollte ich jedoch nie, daher war mir seit langem Edomi immer lieber als HA.

Heute kann ich mit HA umgehen, habe ein individuelles Dashboard mit hohem WAF, ohne den HA typischen Look und trotzdem responsive wie jede moderne Website.

Ich bin aber auch sehr rasch von den integrierten Cards auf Mushroom und custom:button-card umgestiegen, da die einfach out-of-the-box wesentlich mächtiger sind und daher viel Zeit sparen. Die Bubble-Cards bieten noch mehr Möglichkeiten, haben aber einen anderen Default-Look, den man jedoch (seit kurzem) sehr einfach anpassen kann. Ich hab zu all dem auch entsprechende Threads erstellt, die kann jeder hier lesen.

Ohne entsprechenden Zeitaufwand wird du in HA höchstens bei einem 0815-Dashboard landen, bei Edomi aber auch nicht sehr weit kommen, denn auch pixelgenaue Dashboards fallen nicht einfach so vom Himmel.

Ich stehe also weiterhin zu meiner Aussage, die Einschränkungen sind mehr in deinem Kopf als im Tool.

[scw2wi]

Wenn ich css als Quasi-„Programmiersprache“ brauche

Ich hab pixelgenaue Angaben dort verwendet, wo es Abweichungen zwischen Bildschirm und Handy gegeben hat, die ich anders nicht lösen konnte.

also so etwas

top = (window.innerWidth <= 800) ? 39 : 41;

Du hast aber schon recht, Edomi ist der Master für pixelgenaue Dashboard, in HA kannst du mit dem Standard Lovelace-Dashboard nur responsive Seiten bauen. Das ist ein fundamentaler Unterschied und jeder muss einfach wissen, was er möchte. Ich wollte halt beides, sowohl responsive als auch pixelgenau dort, wo es mir darauf ankommt, und genau das geht mit Lovelace + CSS.

denn auf selbstgestylten Karten geht die flexibel Positionierung nur, wenn man mittels JS die Daten aus Homeassistant holt.

Dieser Aussage würde ich nicht zustimmen, so eine Einschränkung kenne ich eher bei dynamischer Farbänderung.

[henfri]

Hallo,

ich sehe es ähnlich wie scw2wi Die Dashboards von HA und Edomi unterscheiden sich fundermental.
Wenn man mit HA ein Edomi-Dashboard nachbauen will dann ist es ein Krampf.

Man kommt bei HA sehr weit ohne "programmieren zu können". Man kann sich sowohl Logiken als auch das Dashboard zusammenklicken.
Wenn man aber die Solltemperatur oben rechts statt unten links haben will, dann muss man halt ran.... Das muss man wissen und dann die eine (CSS lernen) oder die andere (unten links lassen) schlucken.

Das Einzige, wo man zwingend noch YAML braucht ist, um die GAs rein zu bringen. Vieles geht da aber auch schon über das GUI. Allerdings: Es geht per Text und Copy&Paste (oder per KI) schneller.

Gruß,
Hendrik

[tsb2001]

Dieser Aussage würde ich nicht zustimmen, so eine Einschränkung kenne ich eher bei dynamischer Farbänderung.

Stimmt.
War ein blöder Schreibfehler. In den custom:button-cards kommst du nur an die Variablen, wenn du die über JavaScript abfragst.
Ohne JavaScript wird es statisch...

Ich bin aber auch sehr rasch von den integrierten Cards auf Mushroom und custom:button-card umgestiegen, da die einfach out-of-the-box wesentlich mächtiger sind und daher viel Zeit sparen.

Genau da liegt ja das Problem: die Karten sind dann nur mächtig, wenn man die mit css und JavaSchript befüllt. Edomi kommt aber von der Basis drag and drop.

Beispiel:
Haus.png
wären in Edomi 5 Dinge einfach untereinander gepappt, in dem man es einfach untereinander auf dem Dashbord platziert hätte:

1. Textfeld mit statischem Text
2. Image mit Icon eines Hauses
3. Textfeld mit der Variable des momentanen Verbrauchs
4. Textfeld mit der Variable des täglichen Bezugs
5. Textfeld mit der Variable der täglichen Einspeisung

Drag&Drop, genau positioniert, Schriftgröße, Bildgröße und Farben angepasst, fertig! 5 Minuten und das Ergebnis sieht so aus.

Vergleich HA: in der custom:button-card muss das geschrieben werden, um gleiches Ergebnis zu erhalten:

  haus:
    card:
      type: custom:button-card
      size: 25px
      name: Haus
      alias: Verbrauch Haus gesamt ohne Wallbox
      icon: mdi:home-outline
      show_label: true
      label: |
        [[[
          const x = parseFloat(states['sensor.nshv_leistung_haus_komplett_inkl_wallbox']?.state || 0);
          return (x / 1000).toFixed(1) + ' kW';
        ]]]
      styles:
        card:
          - border-width: 0px
          - width: 120%
        grid:
          - grid-template-areas: "'n' 'i' 's' 'l' 'bezug' 'einspeisung'"
          - grid-template-rows: min-content 1fr min-content min-content
          - grid-template-columns: 1fr
        name:
          - font-size: 12px
        img_cell: null
        icon:
          - color: |
              [[[
                return 'SteelBlue';
              ]]]
        label:
          - font-size: 12px
        custom_fields:
          bezug:
            - align_self: middle
            - font-size: 12px
            - color: green
          einspeisung:
            - align_self: middle
            - font-size: 12px
            - color: red
      custom_fields:
        bezug: |
          [[[
            const x = parseFloat(states['sensor.strom_bezug_taglich'].state || 0);
            return x + ' kWh';
          ]]]
        einspeisung: |
          [[[
            const x = parseFloat(states['sensor.strom_einspeisung_taglich'].state || 0).toFixed(1);
            return x + ' kWh';
          ]]]    
​

Und nun erklärst du mal jemandem "verwöhnten Drag&Dropper" aus Edomi, dass es das braucht, um die 4 Texte und ein Symbol in Edomi gleichwertig in Homeassistant zu ersetzen.

Ich will hier keinem die Idee madig machen, aber wenn man schon die komplette Designstruktur der Oberfläche und den Logikeditor neu kreieren muß, dann verstehe ich nicht, warum Homeassistant dann überhaupt als Backend genutzt werden sollte, und das Ganze nicht Standalone aufgsetzt wird? Die Integrationen darauf aufbauend sollten doch dann nicht das entscheidende Kriterium sein.

[scw2wi]

Drag&Drop, genau positioniert, Schriftgröße, Bildgröße und Farben angepasst, fertig!

Genau das wundert mich auch, das bestimmte Dinge in HA nur sehr mühsam funktionieren. Geht das niemandem ab, kennt das niemand besser?

Die Button-Card ist auch das extrem-Beispiel, die kann einfach alles und ist auch beliebig komplex.

Es gibt ein Projekt das exakt darauf abzielt, Karten genau so mit Drag&Drop zu erstellen wie man es auch von Web-Tools her kennt, nur kann man das meines Wissens nach nicht mit Lovelace kombinieren und es erschien mir auch nicht sehr aktiv gepflegt. Ich hab mir bisher auch noch nicht die Zeit genommen, das mal näher anzusehen. Es scheint aber auch dort kein pixelgenaues Design möglich zu sein.

[henfri]

Hallo,
du hast das Problem gut gezeigt:
Wenn man genau das erreichen will, braucht man ewig.
Wenn man aber etwas flexibler ist, dann kommt man schon recht weit:

type: tile
entity: sensor.haus_leistung  # Dein Hauptwert (kW)
name: Haus
icon: mdi:home
features:
  - type: sensor-value
    entity: sensor.haus_energie_import # Der 10 kWh Wert
  - type: sensor-value
    entity: sensor.haus_energie_export # Der 0.0 kWh Wert​

Was mich an Edomi gestört hat (war aber ganz am Anfang und mag sich geändert haben)
[QUOTE]Drag&Drop, genau positioniert, Schriftgröße, Bildgröße und Farben angepasst, fertig! 5 Minuten und das Ergebnis sieht so aus.[/QUOTE
Und wenn ich das gleiche viermal haben will, mache ich die genannten Schritte viermal.
Und wenn ich dann noch was hinzufügen will, dann ändere ich das viermal. Und muss viermal dafür Platz schaffen. Und das Ganze für Desktop UND Mobil.

Hat sich das später geändert?

Auch nett übrigens:
decluttering card: Damit kann man verschiedene Grundelemente zu einem neuen Visuelement zusammen stellen und dann immer wieder verwenden.
Beispiel: Ich hab mir ein Element für die Heizung erstellt, bestehend aus Einstellung, Status und Mini-Diagramm
image.png

Der Aufruf ist so:

          - type: custom:decluttering-card
            template: heizungs_karte
            variables:
              - entity: climate.eg_schuppen_heizung_2
              - sensor_entity: sensor.eg_schuppen_heizung_stellwert
              - name: Schuppen
              - icon: mdi:home

Und überall in der Visu sieht das gleich aus. Und wenn ich es ändere, ändere ich es an einer Stelle zentral.

Das ist auch tolle an HA: Ich brauch nicht 15 GAs bei jeder Nutzung. Ich brauche nur zwei Entitäten - alle GAs sind dort hinterlegt und die Werte sind als Attribute verfügbar.

Gruß,
Hendrik

[scw2wi]

dann verstehe ich nicht, warum Homeassistant dann überhaupt als Backend genutzt werden sollte, und das Ganze nicht Standalone aufgsetzt wird?

Da hast du etwas falsch verstanden.

Node-Red ist ein Standalone System, das aber sehr einfach auch als HA Add-On fungieren kann.
Grafana ist genauso ein Standalone System das optional auch als HA Add-On installiert werden kann.

Wenn man also ein OpenEdomi hätte, das sowohl als Standalone System funktioniert, als auch als HA Add-On, dann gibt's da keine Einschränkungen. Jeder kann es nutzen wie er möchte.

Selbst wenn Edomi und HA beide nebeneinander laufen, dann können sie trotzdem über MQTT Daten austauschen, aber halt keine Entitäten als Objekte und damit ginge viel Zusatznutzen verloren.

Grundsätzlich kann zwar jede Container-SW auch als HA Add-On laufen, so richtig vorteilhaft wird das aber nur dann, wenn sie auch miteinander interagieren können, im Fall von Node-Red z.B. über Configuration-Nodes, das läuft dann soweit mir bekannt über Websocket.

Die Integrationen darauf aufbauend sollten doch dann nicht das entscheidende Kriterium sein.

Das hätte ich anders eingeschätzt, lass mich aber gerne auch von anderen Ideen überzeugen.

[BadSmiley]

Machen ist wie wollen, nur krasser! Wenn keiner anfängt... ja dann.

[oefchen]

Und wenn ich das gleiche viermal haben will, mache ich die genannten Schritte viermal.
Und wenn ich dann noch was hinzufügen will, dann ändere ich das viermal. Und muss viermal dafür Platz schaffen. Und das Ganze für Desktop UND Mobil.

Hat sich das später geändert?

ja, hat sich geändert Objekt einmal anlegen, zigfach kopieren (+Ga´s ändern) und bei Änderungen nur die Vorlage ändern...alle Objekte ändern sich global

[starwarsfan]

Hallo miteinander

Derjenige, der meinen Beitrag als erstes geliked hat, wäre aus meiner Sicht auch der beste, so ein Projekt zu koordinieren.

Na ok, dann fühle ich mich mal angesprochen.

Lasst uns das ein wenig kanalisieren und zusammenfassen.

Die IST-Situation:

1. Edomi ist seitens Weiterentwicklung tot, weil der Entwickler via Lizenzmodell höchstselbst das Kind in den Brunnen geworfen hat. Wer Details möchte, siehe hier. Bitte jetzt keine Diskussion wieso, weshalb und warum, ich will und werde dbzgl. nicht mehr zurück sondern vorwärts schauen und es ist wie es ist. Period.
2. Edomi läuft im Moment stabil "as is" aber es treten die ersten Probleme mit nicht mehr funktionierenden APIs auf
3. Sehr viele Community-Bausteine sind offiziell nicht mehr verfügbar
4. Die restliche Community arbeitet so gut es geht nach dem Motto "help yourself"
5. Ob bzw. wie lange sich meine Container-Templates noch bauen/aktualisieren lassen, steht in den Sternen

Das bringt uns zur SOLL-Situation. Auf der "haben-wollen Seite" gibt es IMHO nur diese beiden Bereiche:

1. Edomi-Visu
2. Edomi-Logikeditor + Logik-Bausteine

Und damit stellt sich die Frage, wie man weiter vorgeht.

Ich halte es für utopisch, ein komplett eigenständiges Projekt hochzuziehen. Dafür ist das Featureset und die Manpower hinter Projekten wie HA und dergleichen viel zu gross. Sowohl HA als auch NodeRed haben beide ihren Ursprung so um das Jahr 2013 und sind dementsprechend schon über zehn Jahre gewachsen und gereift. NodeRed wurde mittlerweile an HA angebunden bzw. integriert. Bei einem eigenständigen Projekt ist der Overhead viel zu gross, all das nochmal zu implementieren, was es zwingend braucht, die anderen aber schon können. Daher erscheint mir als der einzige sinnvolle Weg, sich das bestehende Ökosystem zu nutze zu machen und darauf aufzubauen.

Sofern es sich als gangbarer Weg abzeichnet, wären das für mich zwei separate Folgeprojekte:

1. OpenEdomi-Visu
2. OpenEdomi-Logik

Bitte weiter im Brainstorm-Modus! Code schreiben können wir noch früh genug...

[boonkerz]

https://github.com/koosoli/ESPHomeDesigner Wäre das nicht was?

für die Logic wäre ja node red das equivalent oder?

[scw2wi]

Die Frage ist dann, was wichtiger ist.

Müssen OpenEdomi-Visu und -Logik vollständig kompatibel sein oder genügt es, wenn die beiden Nachfolger vergleichbare Möglichkeiten bieten?

Was wären die Vor/Nachteile dieser beiden Optionen?

[starwarsfan]

Hi

Müssen OpenEdomi-Visu und -Logik vollständig kompatibel sein oder genügt es, wenn die beiden Nachfolger vergleichbare Möglichkeiten bieten?

Was genau meinst Du mit vollständig kompatibel?