Improved UI

[Baldhor]

Is your feature request related to a problem? Please describe. To be honest, the Wizard is looking just bad ... I tried using the homey css style, but the result is just not good.

Describe the solution you'd like I'm thinking about using https://github.com/vuejs/petite-vue. Try to obtain a result looking like HomeKitty:

Basically it means:

• A full rewrite of the views into a single view,
• Backend services used to collect info and apply configuration should be ok.

Additional features At the same time, I think the wizard should allow to match a native capability to several capabilities. Within a single virtual device or not => the wizard should give a warning, but not an alert (blocking). However, the same native capability should not be matched several times on the same capability "on a single virtual device".

Examples: 1/ The cover position is used as windowcoverings_set capability. If "also" matched to a number capability, it could be used to indicate the " %" as a state indicator.

2/ The status of the physical device could be matched to a capability on every virtual device Same for wifi status ...

[Baldhor]

Just a short pick at the state of the improved UI:

Work is in progress for the virtual device list.

[RoadXY]

Nice work, well done!

Could the first screen have explanation, right below the button 'List of physical devices', in the red box (see screenshot below)? Suggestion for explanation text: If you want to add a new physical device, use 'List of virtual device'.

A physical device is the device it self and can contain one or more virtual devices. This way you can split up your device for Homey when you have, for example, a ESPHome device which controls the roller shutters AND has a temperature and humidity sensor connected to it.

[Baldhor]

@RoadXY Well the new version of the wizard will allow even more. Usually with homey : ONE "homey" device is ONE physical device. The current implementation of ESPhome app allows : SEVERAL "homey" devices are linked to ONE physicial device Improved UI will make it one step further : SEVERAL "homey" deviced can be linked to SEVERAL physical devices, AND the same physical device capability can be used several times for different purpose (within the same"homey" device or not) !

Let's for exemple consider a cover, the position state could be used for the windowcoverings_set capability, but also as "measure_current" with unit defined as "%". The result could be something like:

You can also imagine to use a capability "measure_poàwer" in "kWH" with precision of 0 (for main page) and another with precision of 3 for a more detailed measure ...

Talking about enhancement request #39, the same native capability could be matched to a "cumulative capability" and a "not cumulative capability".

You can imagine a device which list the wifi status of all your ESPhome devices.s

Anyway, I'm very unsure what peoples will do with it, I just do not see any reason to limit it.

[Baldhor]

I plan a wiki page with pictures to explain the different screens and what they can do.

[Baldhor]

List of virtual device and new physical device are implemented:

No idea why but I just cannot retrieve the zone of a device ... getDevices()[0].zoneName or zone returns undefined ...

Connection to the new physical device or failure to do so are fully functionnal (including timeout).

Next step is the ability to edit a virtual device, which is going to be hard work ...

[Baldhor]

Renamed the main menu choice, and reviewed the "Manage your virtual devices" view

[Baldhor]

New virtual device view is implemented and functionnal:

Next steps:

• edit virtual device view (the most complex)
• and need implement the "update processing" (ie. when an ESPhome configuration change (new entity, removed entity, ...)

[Baldhor]

So I'm fully blocked at the moment because of a strange bug in petite-vue:

VM20:1 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'insertBefore')
    at ze (<anonymous>:1:10577)
    at De (<anonymous>:1:12721)
    at Ge (<anonymous>:1:13472)
    at De (<anonymous>:1:13423)
    at new nt (<anonymous>:1:15203)
    at $ (<anonymous>:1:11192)
    at W.fn (<anonymous>:1:11670)
    at W.run (<anonymous>:1:2309)
    at me (<anonymous>:1:6108)

Spent too many hours on it already ... I oversee only 2 solutions: 1/ Reorganize everything as components, but no idea if it will make the issue disappear 2/ Remove petite-vue ...

[Baldhor]

found the root cause of the bug ... moving on

[Baldhor]

Working on the capability page (add / edit), it's about 50% done (see below). It's just missing the input fields to set the capability options, should be straigh forward.

Then it will remains:

• Update processing (when your physical device's native capabilities change!) => just need to pick the existing code
• Ability to save an edited virtual device => not so easy, but mostly copy/paste of existing code
• Ability to delete a capability or a virtual device => easy (hopefully homey api work out as expected :) )
• A welcome page to explain the changes and point to the FAQ => easy
• A FAQ to explain how that crazy thing works ...

[Baldhor]

Capability page fully implemented, see below. Tested at 90%, a few bugs left probably.

I added a "hide or show" ability for native capability configs and constraints. It helps keep the page smaller.

[RoadXY]

Wow, nice work! 👍

[Baldhor]

A proof it works :)

[RoadXY]

Nice 👍 Can't wait to try it out!

[Baldhor]

Capability page is fully tested and functionnal. Just need clean up physical device if they become useless :)

Remaining tasks:

1. Update processing (when your physical device's native capabilities change!) => just need to pick the existing code
2. Ability to save an edited virtual device => easy
3. Ability to delete a capability or a virtual device => easy (hopefully homey api work out as expected :) )
4. A welcome page to explain the changes and point to the FAQ => easy
5. A FAQ to explain how that crazy thing works ...

[Baldhor]

Implemented ability to modify the name, zone and class of a device. see below ...

However: Modification of the name and zone require to go through the Web API, which require your bearer token.

It means I will need to allow setting YOUR bearer token in the app setting screen, and until you do so, the name and zone fields will be "locked". So I need to implement a "lock" functionnality (how cool).

Thanks Athom BV engineers for your great api consistency ...

[Baldhor]

Deletion of virtual device implemented, see below. /!\ require bearer token!

[RoadXY]

Nice! How do you acquire an bearer token?

[Baldhor]

Nice! How do you acquire an bearer token?

@RoadXY That's the main issue :

1. Go to : https://my.homey.app/
2. Press F11 (or F12 depends of your browser) to open the developper tool
3. Go to network tab
4. Look for a request with the bearer token in its headers

See pictures As you can imagine, many users will have issues to find it ... edit: and the token change "often" (like once every 2 weeks hopefully, but maybe less)

[Baldhor]

Deletion of capability is implement.

Added ability to input a bearer token:

1. Not saved: the user need to input it everytime he wants to access "advanced" functionnalies
2. Advanced functionnalities are: -- Modification of a virtual device name or zone -- Creation of a virtual device in a specific zone, by default it will go into curent zone -- Deletion of a virtual device directly from the wizard

[Baldhor]

@RoadXY I will publish 1.0.0 as beta version if you are willing to test it out :) Please note:

• Expect a few bugs, but it's mostly working!
• There are no way back excepted removing all your ESPhome devices ...

I will not publish officialy until the welcome pages and a FAQ/Wiki is ready.

[Baldhor]

1.0.0 is published FOR TEST PURPOSE: https://homey.app/a/nl.inversion.esphome/test/ This thread is closed, please open new issues if you have the courage to test it out :)

[Baldhor]

Started a guide: https://github.com/Baldhor/Homey-ESPhome-Enhanced/wiki/About-release-1.0.0

[RoadXY]

Nice! How do you acquire an bearer token?

@RoadXY That's the main issue :

1. Go to : https://my.homey.app/
2. Press F11 (or F12 depends of your browser) to open the developper tool
3. Go to network tab
4. Look for a request with the bearer token in its headers

See pictures As you can imagine, many users will have issues to find it ... edit: and the token change "often" (like once every 2 weeks hopefully, but maybe less)

The Homey Pro 2023 has an option for creation of an API key local. The previous models, however, dont. https://community.homey.app/t/app-pro-dashboards-custom-dashboards-for-your-homey/84837/2?u=robin_van_kekem