Configure `client-lvgl` using HA Panel (read panel config, render in voorkant)

[cyclops1982]

This item is logged to discuss/document how we're going to do configuration of the UI.

In short, the ideal is that you point voorkant to a HA-instance and it then shows a nice interface (after probably some authentication). This issue is about the UI shown after authentication.

In HA, you can configure cards (ui components) to show one or more ha entities. These cards are on a dashboard and you can configure dashboards manually.

The cards execute services on a domain, so HA does allow you to create a card like so:

type: button
entity: vacuum.1_first_floor

This then tries to call turn_on/turn_off on the vacuum, which it doesn't have and fails.

As said, you can configure dashboards in HA. These dashboards hold the cards. You can retrieve a dashboard with our client-cli like so: client-cli dump-command "lovelace/config" '{"url_path":"dashboard-test"}' which results in the following json:

{
  "id": 1,
  "result": {
    "views": [
      {
        "cards": [
          {
            "entity": "light.bed_light",
            "name": "Bed Light",
            "show_icon": true,
            "show_name": true,
            "tap_action": {
              "action": "toggle"
            },
            "type": "button"
          },
          {
            "entities": [
              "light.living_room_rgbww_lights"
            ],
            "type": "entities"
          }
        ],
        "title": "Home"
      }
    ]
  },
  "success": true,
  "type": "result"
}

We could simply parse this output and generate a UI from this. This would mean that our UI components are likely to become LVGL implementations of the HA cards.

[Habbie]

9 is related

[Habbie]

implementations of the HA cards.

including, as discussed on IRC, I suspect we will make a lot of friends if we can handle apexcharts configs and plot them

[cyclops1982]

Earlier on in our design of voorkant, we considered other home automation systems like openhab. If we now simply parse the panels from HA, then this is out of the window. We also would be commiting to following their UI quite closely. (we'd have to do work to follow their UI changes, etc). I think this might become tedious. I also think this is not needed, we might say that climate can do without aircon settings because frankly, in NL not a lot of people have a climate system like that. This makes me think that we shouldn't just parse the panel/dashboard config in HA and render it, but convert it to some configuration that /we/ support. i also believe that this makes it easier to handle things on our side. So we'd have one place where HA Panels are converted to our configuration and that's what voorkant understands.

Having our own config would also allow us to store/retrieve it somewhere else for other home automation systems.

[Habbie]

I'm open to a conversion step. We can likely automate it, so people who just want to drag things in HA get their way, without tying us and power users to it. Then when we look at other backends, we can write another converter.

[cyclops1982]

I'm open to a conversion step. We can likely automate it, so people who just want to drag things in HA get their way, without tying us and power users to it. Then when we look at other backends, we can write another converter.

Yes, this is what i was thinking as well. We don't want to burden the end-user with this, but we do want to keep our own format for the configuration that aligns with our capabilities.

[cyclops1982]

we might not need a converter from Json to json, but maybe from json to an object model that we use internally. This would mean just 'parsing' the json.... ?

[Habbie]

we might not need a converter from Json to json, but maybe from json to an object model that we use internally. This would mean just 'parsing' the json.... ?

Yes, I think this is the way, at least for now. We can add more converters (for openhab, etc.) later, likely expanding our internal representation a bit at that time.

[cyclops1982]

This does mean that we should have 'how do we get config' per backend type.

So, first step would be to get HABackend get the panel and parse that.. and than the backend should expose something that we can start creating uicomponents from... i think...

[Habbie]

client-cli dump-command "lovelace/config" '{"url_path":"dashboard-test"}'

you can get the url_paths like this:

$ build/client-cli dump-command get_panels | jq '.result[] | select(.component_name == "lovelace")' 

{
  "component_name": "lovelace",
  "config": {
    "mode": "storage"
  },
  "config_panel_domain": null,
  "icon": "hass:view-dashboard",
  "require_admin": false,
  "title": "apex",
  "url_path": "dashboard-apex"
}
{
  "component_name": "lovelace",
  "config": {
    "mode": "storage"
  },
  "config_panel_domain": null,
  "icon": null,
  "require_admin": false,
  "title": null,
  "url_path": "lovelace"
}

[cyclops1982]

We currently have some subcommands on the client-lvgl and we should keep them. For example, we can do client-lvgl entity light.* and we want to retain that. So this item should introduce something like client-lvgl dashboard <name>.

This should then read the dashboard and render whatever control we can render, and use the dummy control for things we don't know.

[Habbie]

you can get the url_paths like this:

In my test setup, this returns two panels - the default url_path=lovelace one, and a custom one I added. For the custom one, dump-command lovelace/config $(jo url_path=dashboard-charts) works, but for the default one, build/client-cli dump-command lovelace/config $(jo url_path=lovelace) does not.

[cyclops1982]

We already know we can't support the standard lovelace standard dashboard.

This is the example of client-cli dump-command lovelace/config $(jo url_path=dashboard-test) output:

{
  "id": 1,
  "result": {
    "views": [
      {
        "cards": [
          {
            "entities": [
              {
                "entity": "light.bed_light"
              },
              {
                "entity": "light.ceiling_lights"
              }
            ],
            "type": "entities"
          }
        ],
        "title": "Home"
      },
      {
        "cards": [
          {
            "entity": "light.ceiling_lights",
            "show_icon": true,
            "show_name": true,
            "tap_action": {
              "action": "toggle"
            },
            "type": "button"
          }
        ],
        "path": "view1",
        "title": "View1"
      }
    ]
  },
  "success": true,
  "type": "result"
}

This has 2 tabs/views, and on each view a card.

[Habbie]

74 does a big chunk of this. Items left:

• pick up panel changes
• handle entities cards as cards, instead of just as a bunch of entities
• handle views (shown as tabs in HAweb)