search

Baldhor / Homey-ESPhome-Enhanced

This is an Homey app which adds support for ESPHome devices. ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems. More information on their homepage: https://www.esphome.io/
GNU General Public License v3.0
5 stars 3 forks source link

Material Design Icons support #51

Open Baldhor opened 7 months ago

Baldhor commented 7 months ago 
          Maybe make use of the Material Design icons?

Ronny already uses for his capabilities. This was added in version 0.2.0 of his app. This is a diff of version 0.1.9 and 0.2.0 https://github.com/RonnyWinkler/io.home-assistant.community/compare/0.1.9...0.2.0

Originally posted by @RoadXY in https://github.com/Baldhor/Homey-ESPhome-Enhanced/issues/41#issuecomment-1717755156

Baldhor commented 7 months ago

The purpose here is to offer a way for the user to choose an icon from https://pictogrammers.com/library/mdi/ directly from the wizard!

Baldhor commented 7 months ago

So I explorered a little what others did:

1/ Seems MQTT Hub introduced the first implementation to support MDI in a Homey application Looking at the code, the icon can be set only at creation time, modification is not supported afterward.

2/ io.home-assistant.community took the code from MQTT Hub But also added icon change support through the repair function. Meaning you can change the icon afterward. => proof if needed that we can change icon "after creation".


The implementation for both is based on Vue.js, but I use Petite Vue.js.

It will require some code rework, but not so much apparently.

The icon file is downloaded and stored in the application file storage.

That's the good way to do it in my opinion.

From user point of view it goes through a search tool inside the Homey interface

Great!

The interface doesn't show all the icons, but only the one selected

Unsure about it

Anyway, it's good enough

The code allows to input directly the url of a specific SVG file

Seems not limited to MDI

I cannot find the interface element, so I'm unsure if it is fully implemented

In my opinion, that's useless anyway (MDI has enough icons available)

If the same icon is used several times, the icon is duplicated, the file is named on the device unique identifier.

This can lead to a lot of space used ...

I need to rework that part. I just cannot accept it ...

The file is deleted when the device is deleted.

What if it fails in the middle ? (the file is never removed ???)

I need to rework that part too, mostly because of previous point :)

I want to allow MDI for capabilities too,

I didn't find anything, and so I don't know if it is possible or not

Need to test it seems, nobody answered me on Slack

Baldhor commented 7 months ago

First estimation of the work load: about 10h (dev) + 5h of support (bugs, wiki, ...). As for capabilities, probably around 3h for testing if it is possible.

Baldhor commented 6 months ago

Ok so here is my idea after thikking about it a little while.

In ESPhome firmaware, you can actually configure an icon at the entity level. In the ESPhome for Homey app, I consider "native capabilities", not entities.

Reminder: a native capability is "an attribut of an entity"

So the native capabilities will inherite from the icon of the entity.

In Homey, you can set the icon of a device, but I'm unsure about the icon of a capability (only further test will confirm if it is possible).

1. The Wizard will propose for each device:

And so maybe also for the capabilities, it depends if it is possible or not

2. The Wizard will have a new "Manage your local icon library"

If the user delete an icon used, the device (and/or capability) using it will be back to default

Add and replace will allow: to search an icon in the mdi library, or input an url to a svg file

3. The download of the icons will be asynchronous

So an icon in the local library will have 3 states: downloading, unavailable (error), available

If unavaialable, the user can "try again", replace it, or just delete it


From an user experience point of view: It's probably better if the user download a new icon before creation of the devices. But he can edit the device icon later if needed!

I believe, if the user download an icon, he must have the choice to use it right now or later. Deletion of an icon should not be automatic but a decision of the user!


From implementation point of view: It makes it much easier to avoid downloading several times the same icon.