[Feature Idea] Rearranging the configuration structure

[Mrredstone5230]

Alright, so I didn't code it yet, but I find the way the configuration is organized to be a little confusing to my liking.

What I'm proposing is a configuration based on components instead of "texts, images, channel, etc"... I think if every page was just a list of components instead of just one big page only, it would allow some more creativity and power for the users. (That would for example allow people to make the PV page fully in the configuration page using components, and not having to code it in in python). This could also allow you to add some more custom components instead of custom pages entirely. (and I have some ideas for those too!). It could also allow users to control the overlap, if it occurs. This new formatting should also be used in the services for continuity, if implemented.

This is what I'm thinking a new config should look like. Still pages based, but inside the pages is components.

- page: 1
  components:
  - type: text
    position: [17, 18]
    content: '{{ states.sensor.YOUR_SENSOR.state }}'
    color: '{{ "red" if float(states.sensor.YOUR_SENSOR.state) <= 1 else "green"}}'
    font: PICO_8

  - type: image
    position: [1, 16]
    image_path: '{% set num = float(states.input_number.test.state) %} {% if num >= 80 %} /config/custom_components/divoom_pixoo/img/akku80-100.png {% elif num >= 100 %} /config/custom_components/divoom_pixoo/img/akku60-80.png {% else %} /config/custom_components/divoom_pixoo/img/akku40-60.png {% endif %}'

#etc for the PV page, for example.

- page: 2
  components:
  - type: text
    position: [0, 10]
    content: "github/gickowtf"
    font: PICO_8
    color: [255, 0, 0] # or write "red"

  - type: text
    content: "Thx 4 Support"
    position: [0, 30]
    font: PICO_8
    color: [255, 0, 0]  # red

  - type: image
    position: [30, 10]
    image_path: "/config/img/anyPicture.png" #max 64 x 64 Pixel

- page: 3
  components:
  - type: channel
    id: 2
  #Of course, here it's theoretically possible to add more components, although it would override the 'channel' component.

- page : 4
  components:
  - type: clock
    id: 39
  # same story than page 3 here.

Now as you can see, it's not a perfect solution: There is quite a lot of coding still (mostly in the "PV remake") But, I believe that this is a better solution than before, since now people can just share their solutions with each other in plain text instead of relying on this extension to add the page they want.

(PS: I do know that the PV page if already implementable currently, but I think that the general way of organizing the data is a bit nicer/clearer here.)

Let me know what you think!

[gickowtf]

hey, of course i can understand you, the problem is that a lot of people have already configured the integration and if we change this further now, people will have problems with an update. i am still open to everything. have just created a new font but still have to adapt the readme accordingly.

[Mrredstone5230]

Yeahhh, I understand this, and you're 1000% right. The problem though is that I believe the old config structure is a little bit limiting for future use. So, keeping it now is a little bit limiting for innovation. Maybe we should wait a bit for users to download 1.4.0, and we release it later after some time passed.

[gickowtf]

Originally I wanted to make more pages like the PV page... i.e. prefabricated and user-friendly. Not every user is equally creative, but your idea is also conducive to the exchange of creative things. Maybe we should try to develop the whole thing. But if possible in such a way that prefabricated pages are still possible. Thanks again for reviving the project :D

[ireneybean]

Maybe it would it be possible to version the config to allow users to opt-in to the newer version while maintaining backwards compatibility. Possibly by including version: 2 in the yaml (or maybe a separate field since the current config appears to be expecting a list of pages).

[Mrredstone5230]

Hmmm.. I mean, it would be quite annoying to have to maintain an old version of the config, but this is obviously possible. But, I do agree that something would need to be done if something changes. I'm proposing to use the HA migration tool (for config entries), which could handle the config change, but if people didn't update the integration before the config re-structure, that wouldn't get triggered.

(Basically, the Version Entries have a hidden Version already. But, on second thoughts, maybe it could be possible to force migration, even on newer versions of the integration, if it detects a certain tag that would be deprecated...)

[Mrredstone5230]

Originally I wanted to make more pages like the PV page... i.e. prefabricated and user-friendly. Not every user is equally creative, but your idea is also conducive to the exchange of creative things. Maybe we should try to develop the whole thing. But if possible in such a way that prefabricated pages are still possible. Thanks again for reviving the project :D

Alright, I was thinking about it, and I kind of agree with you. Old pages should work, and I also realized that, in some ways, the "clock" and "channel" "components" are actually more like pages. So, here's maybe a better idea, that maybe could help with @ireneybean's issue too! (With the "enabled" tag)

- page_type: PV
  power: "{{ states.sensor.YOUR_SENSOR.state }}"
  storage: "{{ states.sensor.YOUR_SENSOR.state }}"
  discharge: "{{ states.sensor.YOUR_SENSOR.state }}"
  powerhousetotal: "{{ states.sensor.YOUR_SENSOR.state }}"   
  vomNetz: "{{ states.sensor.YOUR_SENSOR.state }}"
  time: "{{ now().strftime('%H:%M') }}"  #Format HH:MM

#etc for the PV page, for example.

- page_type: components  #or custom, I'm not sure what's better because of Custom Channels..
  components:
  - type: text
    position: [0, 10]
    content: "github/gickowtf"
    font: PICO_8
    color: [255, 0, 0] # or write "red"

  - type: text
    position: [17, 18]
    content: '{{ states.sensor.YOUR_SENSOR.state }}'
    color: '{{ "red" if float(states.sensor.YOUR_SENSOR.state) <= 1 else "green"}}'
    font: PICO_8

  - type: image
    position: [1, 16]
    image_path: '{% set num = float(states.input_number.test.state) %} {% if num >= 80 %} /config/custom_components/divoom_pixoo/img/akku80-100.png {% elif num >= 100 %} /config/custom_components/divoom_pixoo/img/akku60-80.png {% else %} /config/custom_components/divoom_pixoo/img/akku40-60.png {% endif %}'
# This is just an example with Templates. The old PV page would still work (as shown above).

- page_type: channel
  id: 2

- page_type: clock
  enabled: False  # This would disable the integration to render the page. Of course, this would accept Templates. This 'tag' would True by default (and of course optional), and be available for every page.
  id: 39

What do you all think ?

[gickowtf]

Ok, that sounds good with the enable tag. Perhaps it would be possible to have an extra text field for each page, which can then be activated or deactivated accordingly with a binary entity. Or what exactly do you mean? With this binary entity you could then also write automation, e.g. activate page 3 at time of day XY or activate page 4 when flushing mesh is running and so on. the whole thing would be really useful. i had tried to develop conditions at the time but unfortunately it was then the case that if a condition was not true and the page should not be displayed accordingly, the previous page was displayed twice as long. at the moment i just don't know what the best approach would be to implement this. it would be best if the config was variable. and i think that could be implemented really well with your idea enable/disable.

[kongo09]

I like this suggestion a lot. I also noticed that it removes the page numbers, something I didn't really understand what it is for, as in the end the configuration will be an ordered list anyhow in yaml.

[gickowtf]

I'm currently working on a solution, but so far it's all just basic ideas and progress is rather slow. The enable tag works partially but there is still a bug somewhere. I can no longer say what I was thinking when I numbered the individual pages 🤦‍♂️

[gickowtf]

Please Check #27 I'm not really getting anywhere here. I'm still despairing about the restart error. Otherwise the enable tag is working fine.

[ireneybean]

I'll try to take a look if I can get some time today. I'm an ace troubleshooter but being new to ha makes it an extra challenge.

I had the grand idea to write some basic tests for the project as a first contribution and to get familiar with the code. I'm at that phase where I am just struggling with figuring out basic Python dependency management stuff. (Not asking for help, struggling is how I learn, lol)

[gickowtf]

i think i got it. i forgot initial_index and compared it wrong -.-... #27

@Mrredstone5230 Do you already have approaches for the page_type?

[Mrredstone5230]

I unfortunately don't. I had problems with my computer today, but now they're fixed. I'm gonna take a look now.

[gickowtf]

oh man PC problems are annoying. i have now made a push in the PR for the last time. from now on you can use the keyword enable with template. and if you leave it out it is true by default. i really like it but maybe you still have something better :D

- page: 1 #with enable tag helper entity on/off switch named test
  enable: "{{ states.input_boolean.test.state }}"
  texts:
    - text: "github/gickowtf"
      position: [0, 10]
      font: FONT_PICO_8
      font_color: [255, 0, 0]  # red
    - text: "Thx 4 Support"
      position: [0, 30]
      font: FONT_PICO_8
      font_color: [255, 0, 0]  # red
  images:
    - image: "/config/img/anyPicture.png" #max 64 x 64 Pixel
      position: [30, 10]
- page: 2 #without enable tag
  clockId:
    - number: 182