Question from the beginner.
Do not ask me why this is necessary.
Is it possible to make the main devices in HA (lights, switches, sensors, etc.) virtual, and then just connect physical ones to them?
For example, to quickly replace devices, without overwriting automation, without losing history, etc.
2 Likes
That’s a neat idea but no it is not possible AFAIK.
You might like to suggest it:
I created a new topic in “Feature Requests”. Who cares, vote me.
I have a feeling that for the most from your list you can use template integrations and they’ll do what you want.
Yes, I tried templates, for example:
- platform: template
lights:
bedroom_desklamp_1:
friendly_name: Настольная лампа 1
value_template: "{{ is_state('switch.iotp040102_relay', 'on') }}"
availability_template: "{{ not is_state('switch.iotp040102_relay', 'unavailable') }}"
turn_on:
service: switch.turn_on
data:
entity_id: switch.iotp040102_relay
turn_off:
service: switch.turn_off
data:
entity_id: switch.iotp040102_relay
It even conveys the state of available / unavailable .
But this is somehow very DIY …
1 Like
i don’t understand what’s the issue here. You have a physical light with entity_id light.xyz_whatever, you rename it to light.ceiling_living_room. You then use this new name in your history, automations etc. Then you get a new bulb that uses a different integration, you get entity_id light.xyz_new_name_blabla, you rename it to light.ceiling_living_room and your automations etc. will still work.
To make the story short, it’s not DIY, it’s “flexible”. there’s nothing wrong with it, especially because there as many different use cases/requirements as the number of users.
As you justshowed, we have an option. And because there are still so many use cases, it would be quite difficult to cover all needs in one standard integration.
HA core has enough to create things that suit one’s particulate needs and constantly increasing the number of core integrations is not a good idea because of performance issues/maintenance/compatibility etc.
And if it’s not enough, one can always create/use a custom component without worsening core HA capabilities for everyone.
Imho that’s how it works with HA.
1 Like
Agree with @Burningstone - for entities you can rename, you can now get what you want. Before that was available, I used to use groups for this. Ie, my automation for controlling a light would actually control the group - then I could just drop in new devices into the group. Sort of works, but not great for reading the state of devices.
I still haven’t figured out exactly which entities allow renaming and which don’t. So you might be limited there.
Sorry to bring up an old topic but I have a question around virtual devices. I use to use Homeseer and they allowed you to create a virtual device. I want to recreate one of my automation in HA and not sure how I can go about doing it. In Homeseer, I had a Virtual device call house occupied. I then used my motion sensors around the house to set my home or away status. So if all of the sensors had not triggered in the last 10 min, I would set the status away or off. As soon as one was triggers I would set it back to on/home. Then I would do triggers like set AC or turn lights on or off based on the Occupancy status changing. How would this best be done is HA? Still learning and I know someone has probably done something similar!
1 Like
Still trying to figure this out .
Also , are enum states mapped to a value ? ex. away(0), vacancy(1), home(2) ? So I can write automation based on number instead of enumerating every state :
If state change and is less than 2 , than turn off all the light.
I do this all the time with virtual devices where my flows are complex, I use a virtual device. I started doing this when my wifi iot devices would come and go on my network and that would trigger things in HA, but after fixing my wifi network, I still use virtual devices in the complex flows as I had originally a bunch of Gosund devices (first gen) that I eventually replaced with newer devices, since I have use virtuals for other reasons originally I already had them there, but they really helped me easily replace these older devices, so I kept doing it when I have a complex flow.
I fully support this idea.
Let me give you a simple example.
I have several Tuya devices. These are switches and light bulbs.
Unfortunately, the standard Tuya integration does not work well, and some devices periodically become inaccessible.
There are two alternative integrations of Tuya. They are called “LocalTuya” and “Tuya Local” (aren’t they almost the same names, but they are completely different integrations). Both of these integrations have their pros and cons, but their main drawback is this: some devices periodically become inaccessible.
All my Tuya devices are registered through all three of these integrations, and have different entity_ids (for example: switch.tuya_bedroom_light, switch.lt_bedroom_light, switch.tl_bedroom_light).
The main paradox is that at some point in time the same device (for example, a switch) may be available in one of the three integrations and not available in the other two. Or available in two and not available in one. Or available everywhere.
If it were possible to combine these entity_ids by group type into virtual objects, then it would be possible to manage the device based on availability (and also set integration priority by order from first to last in case the device is available in several integrations at once).
It might look like this:
switch:
- platform: virtual
name: bedroom_light
entities:
- switch.tuya_bedroom_light
- switch.lt_bedroom_light
- switch.tl_bedroom_light
or
light:
- platform: virtual
name: my_bulb
entities:
- light.tuya_my_bulb
- light.lt_my_bulb
- light.tl_my_bulb
Another example.
In a certain room there are two temperature sensors registered in Home Assistant through two different integrations (for example, the first thermometer works via ZigBee, and the second via Bluetooth). Room temperature is very important criteria on the basis of which the home heating system operates. If the temperature sensor fails, the heating system will think that the room has cooled down to zero degrees and will begin to heat the room with great force.
To prevent this from happening, you need to somehow use the second temperature sensor. Currently, to do this, you need to build a cumbersome structure from templates, where you specify numerous “if”, “else” and so on, describing the conditions under which the second sensor will become operational.
But how wonderful it would be if, instead of this construction, you could simply write:
sensor:
- platform: virtual
name: room_temperature
entities:
- sensor.zigbee_thermometer
- sensor.bluetooth_thermometer
1 Like