Physical Device versus Homey Device

[Baldhor]

Current situation

As of current situation, which is actually the default behaviour for all Homey devices, a physical device (real world device) is linked to one and only one device in Homey. All capabilities of the physical device are directly linked to the Homey device.

Let's consider a physical device which include a temperature, humidity and air pressure sensor. In Homey, it will appear as one device which those 3 capabilities.

Above, you can see a Xiaomi sensor. On room view, only the temperature appear. To check the other capabilities, you need to go "inside" the device!

Example with Athom sw03

An ESPhome device can have a lot of entities. For example if you consider the device I use to control my covers:

This device has:

• 3 buttons
• 3 leds
• 3 switch
• a text_sensor for wifi info
• a text sensor for uptime
• a cover => the "main" entity
• a number for prefered position
• a number for open duration
• a number for close duration
• ...

(You can find the configuration I use here: https://github.com/Baldhor/Homey-ESPhome-Enhanced/tree/main/esphome-config)

I could actually modify the configuration to handle the cover with a simple button, and use the 2 others for whatever purpose:

• turn on alarm
• turn on light
• turn on tv
• ...

So why those "entities" should all appear in a single "Homey device"!?

Example with Sonoff 4CH

Another example, I'm using many Sonoff 4CH to control all my heaters.

Each physical device control up to 4 heaters which can be in different rooms.

Currently, I have no choice, I'm using virtual device and many many many flows to "copy" the events from the virtual device to the "homey device", and the opposite ...

Here are the flows, just for my ground floor (yes, I have a big house ...)

Remark: they are currently running Tasmota, not ESPhome. If I change to ESPhome, I will need to modify about 50 flows!

What I want

I want during pair time to have the ability to split the physical device entities into different Homey devices

Remark: the user should have the right to handle several entities (capabilities) into the same Homey device, but he should also have the right to split them as he want!

Different kind of entities

In ESPhome, an entity can serve many different use. Let's take the exemple of my Athom SW03 configuration for cover:

• 3 buttons => I should be able have them exposed as 3 differents buttons in Homey, or just hide them (ie. do not expose this entity in Homey)
• 3 leds
• 3 switch
• a text_sensor for wifi info => I should be able to configure it in Homey as "device information" (can be seen in setting screen of the device)
• a text sensor for uptime => same as wifi info
• a cover => the "main" entity should appear as a device in Homey
• a number for prefered position => could appear as setting of the cover device, or as a separate device
• a button for "move to prefered position"
• a number for open duration => setting of cover device
• a number for close duration => setting of cover device
• a restart button => many choice here could be possible: hide, independant device, setting of cover, ...
• a reset button => same as restart button
• ...

When exposed as settings, I should be able to configure it as "read only" or "read/write".

Different kind of entity options

For exemple "open duration", has 3 options configured:

• min
• max
• step

Sensor (like uptime) have many options:

• Unit
• accuracy_decimals: number of digit after the comma to show in the UI

We should be able to modify those options in the device settings screen.

An ESPhome physical device configuration can be modified easily

To make it short: The strengh of ESPhome is the abilioty given to easily modify our device behaviours! Everytime we change such configuration on the physical device, we should not have to delete and pair again the device! We should be able to "update" ...

[Baldhor]

This enhancement imply a big rework of the application

[Baldhor]

It's working ...

I made 2 devices with 2 capabilities each based on the same physical device:

1. Cover and humidity
2. Temperature and Battery

The cover is working very well, same for the 3 sensors.

Still many things to test and fix ... but already a lot of functionnalities ... => Connect to new physical device and configure virtual devices, their capabilities and options

More to come: => Modify / Delete existing virtual devices ...

Broken:

• Custom number and text: no trigger, ...
• Several capabilities of the same kind on the same virtual device (however, it works fine if different virtual devices)

[Baldhor]

For those interrested, I published a test version: https://homey.app/fr-fr/app/nl.inversion.esphome/ESPhome/test/

[Baldhor]

4.0.1 published for test: https://homey.app/fr-fr/app/nl.inversion.esphome/ESPhome/test/ Many refacto to make next steps easier. Imply a breaking change, which I could not avoid, sorry. => Need to delete device created with version 4.0.0 through the wizard driver

[RoadXY]

Anything specific I need to test?

[Baldhor]

@RoadXY just new device, anything you can think of :)

I'm working on the existing device functions

[Baldhor]

Published TEST version 0.4.2: https://homey.app/fr-fr/app/nl.inversion.esphome/ESPhome/test/

Wizard is fully implemented!

What it CANNOT DO

• Cannot delete virtual device: This is restricted by Athom BV design! => use the virtual device setting screen to delete a device

What is LIMITED

• You can change the settings (IP address, port, password) of a virtual device in the "setting view" of the virtual device, but it will not propagate to other virtual device associated to the same physical device. This can lead to inconsistency

What YOU can do

• Add virtual device(s)
• Add capability to a virtual device (existing or new one)
• Modify the options associated to a capability (existing or new one)
• Remove a capability from a virtual device (existing or new one)

What it does FOR YOU

• Update the capabilities of an existing virtual device with:
  • The physical device native capabilities => the wizard propose you to delete the incompatible capability
  • The configuration of the Wizard itself => the configuration may change overtime, so it's important to have a way to 'update'
• To be implemented When in new physical device mode, the wizard should propose a "default" configuration (ie. virtual devices with their capabilities). So you can just "confirm" or "modify" as you wish

HELP WANTED

I cannot test every single use case by myself, there are many devices I do not have. Using mock (add random behaviour to the physical device through its firmware configuration) has its limits!

I didn't tested flows yet (trigger, condition, actions), and also need to test if there are several times the same "capability" on a virtual device.

[Baldhor]

0.4.3 published: Fix: add capability listener Fix: solved a few bugs related to the modification of a capability. If you change the type, it actually means a delete and a add, not a modify. Was missing Homey.done();

[Baldhor]

0.4.4 published and I asked for certification Seems stable enough.

I also made a community in homey forums

[Baldhor]

Last commit add support for title, preventInsights and preventTag options for all capabilities. To be honest, I'm unsure who would use preventInsights and preventTag ...

But title allows to distinguish two capability of the same type! Here is an exemple for temperature:

And in flows:

And this is possible because in the wizard, I configured:

(Difficult to make a nice screenshot with this wizard ... who designed it!?)

[Baldhor]

Published 0.5.1: legacy driver is now deprecated, and only the wizard can be used for new devices.