WTH can’t we easily replace devices

Agreed, a simple replace button would be amazing and something I’ve been thinking about too. Even for just moving devices around it would help a lot.

1 Like

Not just devices please, entities as well.

I was tinkering with MQTT sensors, and I don’t know how or why, but HA created sensor.entitiy_2 from sensor.entitiy. I see no way to restore this, and therefore the history of this entity is split into 2 parts.

But yes, having an easy way to replace hardware, and have them continue producing data on existing entities would be heaven. Case in point: I use several Shelly plugs, and their energy data goes into the energy dashboard. I had two of them break and could see no easy way to do what I just described. Someone on a forum pointed out to me that I could delete the broken Shelly from the integration, and give the new one the same name. It worked, but I find that a very stressful way to do such a seemingly simple action.

Other example: I switched from a cloud-based integration to a local integration for my SolarEdge solar inverter. I could not find a way to have the local integration producy energy data on the old entity, so now I still have both entities in my energy dashboard; one dormant and one actively producing data. There is an ugly color switch if you look at a year.

Final example: in the beginning I didn’t know what I was doing with ESPHOME, and my water meter sensor gave me a lot of problems. Too make a long story short: after a lot of config tinkering in ESPHOME and 1 hardware replacement I have three water meter entities, two of them dormant and ont currently producing data. So if you look in my energy dashboard at the water section, you see three colours of blue, and if you look at the config page of the energy dasboard, it’s a nasty mess of sensors. I would like an easy way to merge all those dormant sensors into the current one.

1 Like

I just posted this in WTH is it difficult to replace a phone (or user's device)? but I think it applies here too:

I think it’s actually quite easy to replace a phone or any other device. Just give it the same name as the device you’re replacing.

Name your phone “Keiths Phone” instead of “Samsung S22”
Name your living room TV “Living Room TV” instead of “Sony Bravia 3”
Name your kitchen light “Kitchen Light” instead of “EcoDim BV Dimmer-Switch-ZB3.0”

etcetera

Then when you replace any device just remove the old one and give the new one the same name.

1 Like

And I’ll say again here

Yes. It’s easy. Now please make it easier!!

Good is not good enough

EDIT

Added please. Definitely Not a demand😁

2 Likes

Any chance of a link to these please as searching brings up totally unrelated stuff? Thanks in advance and no drama’s if not.

1 Like

Easy one first, device ids: Why and how to avoid device_ids in automations and scripts

As for notification groups: How to transfer push notifications to new phone? - #3 by tom_l

1 Like

The entity id trick is a decent workaround in many cases. However, some devices (first type that comes to mind is zigbee wireless switches) don’t have entities that are useful in automations.

Switches or buttons?

Switches most definitely have entities.

Buttons generate events. Which you can use (event trigger) instead of device triggers. Or they should have an associated binary_sensor you can use in a state trigger (easier).

Buttons or switches? What’s in a name? Many of the battery-powered devices with no physical switches in them have name that includes ‘switch’. I guess that is since for most users, a light switch is a button on the wall, not the thing that it operates. Just an example: Aqara Wireless Mini Switch - Aqara

The event triggers still include data that is specific to the device. At least in ZHA, it’s the device name or IEEE that identifies the device. So when you switch out the device you still need to change the automations, there’s no entity workaround. Here’s an example of a trigger event for one of my buttonswitchthingies:

data:
  device_ieee: 84:ba:20:ff:fe:a7:e6:e7
  unique_id: 84:ba:20:ff:fe:a7:e6:e7:1:0x0008
  device_id: 642a1ac495a88439fecf8620e4a18393
  endpoint_id: 1

A lot in HA. Completely different domain with different triggers and actions. Switches hold their state, buttons are momentary.

What the manufacturer chooses however may not be as well defined.

:roll_eyes:

Can you please go to the device card on the integration page for that button/switch (Settings → Devices & Services). Share a screen-shot.

Well, HA is just a small part of the world. To most people, a state is a part of a country.
Here’s the screenshot. I’m not sure what you want to see here, perhaps we’re drifting off topic a bit

Ah ok I seem to have mis-remembered. I thought binary sensors were created. But they are event entities. Which I would still expect to have seen on that page.

Can you check Developer Tools → States and search for "event. " (including the period). See if your button creates any event entities.

Well you are in that small part now. There is no escape. Best to learn the lingo.

Nope. I don’t use Zigbee2MQTT but I think that does make entities for some of these devices? Or maybe one of the other integrations that can deal with buttons? But not ZHA for as far as I have seen.

ZHA should too. If not that’s a definite WTH.

“WTH does ZHA not create event entities?”

I know the lingo when it comes to the HA domains. But I was talking about the physical devices. A switch in HA is not a device, and neither is a button. I’m not sure where this dicussion is supposed to lead. I don’t have a question.

Maybe the people that develop ZHA should have a coffee together with the people that develop HA and talk about what they should or should not do? :rofl: :wink:

They’re the same people!

I know. That’s why I used the wink emoticon. My bad. I’ve been on the internet for 30 years and still haven’t learned that irony usually falls dead in text-based interactions.

But maybe we should stop going so far off topic before a moderator steps in and gets mad at us :wink: :wink: :wink: :wink: :wink: :wink: :wink: :wink: :wink: :wink: :wink:

1 Like

I think working around a dead device by adding a new one with the entities named the same is possible through some sort of careful exercise (it even can continue picking up the old one’s long-term stats if you don’t delete them). You just have to make sure that the entities corresponding to the future name are deleted.

But today I have just run into a conundrum I don’t I can solve. Old radiator valve died, new one doesn’t fit. So I have to move one functioning device to replace the dead one and introduce the new one in place of the old one. For this I think keeping the correct long-term statistics is just not possible currently.

1 Like