home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.18k stars 30.57k forks source link

Automations referencing non-existing devices do not work after installing 2023.11.0b1 #102937

Closed iridris closed 2 weeks ago

iridris commented 1 year ago

The problem

After upgrading to 2023.11.0b1 from b0, multiple device IDs changed. This caused multiple automations to break. Devices that had their IDs changed were from both Zigbee2MQTT and ZwaveJS-UI. There may be devices from other integrations as well, but those are the only 2 that impacted me via automations.

What version of Home Assistant Core has the issue?

2023.11.0b1

What was the last working version of Home Assistant Core?

2023.11.0b0

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Zigbee2MQTT, ZwaveJS-UI

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2023-10-27 18:02:34.118 ERROR (MainThread) [homeassistant.components.automation] Automation with alias 'Worker - Bedroom Low Light' failed to setup actions and has been disabled: Unknown device 'f559286722b67dfb86349bb409f3806e'
2023-10-27 18:02:34.134 ERROR (MainThread) [homeassistant.components.automation] Automation with alias 'Presence - Arrived Home' failed to setup actions and has been disabled: Unknown device '491487c43244c1c27f2e48a961bad702'
2023-10-27 18:02:34.135 ERROR (MainThread) [homeassistant.components.automation] Automation with alias 'Mode Trigger - Night' failed to setup actions and has been disabled: Unknown device '491487c43244c1c27f2e48a961bad702'
2023-10-27 18:02:34.182 ERROR (MainThread) [homeassistant.components.automation] Automation with alias 'Worker - Master Closet Light v2' failed to setup actions and has been disabled: Unknown device 'f61ed5009889ffbb96884c8d9f4a60f9'
2023-10-27 18:02:34.827 ERROR (MainThread) [homeassistant.components.automation] Automation with alias 'Lock - Do stuff when code used' failed to setup actions and has been disabled: Unknown device '02510f7e01be61614d6e50dcf497ce4c'
2023-10-27 18:02:35.737 ERROR (MainThread) [homeassistant.components.automation] Automation with alias 'Lighting - Office Button' failed to setup actions and has been disabled: Unknown device '3271e90d5dc11f6f439840dd4ac8af39'

Additional information

No response

boehser-enkel commented 11 months ago

So i created automations via the GUI via device. No it's wrong and it's my fault and i have to rebuild my entire automations??

Renegade605 commented 11 months ago

So ultimately, at least for my case, this doesn't look like it was caused by this beta - but this beta is bringing the issue to the surface. Which is a good thing, but is probably worth calling out as there will likely be more people that discover they have broken automations after this version.

For me, the device IDs remained unchanged which makes sense, as 2023.11 does not change device IDs, just adds some extra checks for device IDs.

@nohn thanks for this, this is exactly what it is intended by the mentioned change in #102937 (comment) Those the automations should already be broken before 2023.11, but with 2023.11 you get notified about them.

These automations for me were not broken and worked just fine right up until the update.

able to go back to 2023.10.3 and the issue has gone away

@Campagne8758 further, please could you verify, if the the supposedly in 2023.11 broken automations are really working again after the rollback?

Rolling back to 2023.10.5 made the automations work again for me without making any changes to them whatsoever.

Maybe delete the boolean helper and create a new one giving it the same entity name will solve it πŸ€”

that could indeed work, but I have tons of devices with this problem. I really do not want to recreate them all ;) Its a pity that som HA changes in a past version lead to this user unfriendly behavior :( I still hope for a "fix".

Yes well it is not ideal, no idea if a fix will come, because fix just will mean going back to ignore "faults" in automation. My idea is still better fix the automations now one way or a other because even if they gonna fix it by ignore the faulty automations you never know what happens in the future .... I would say better be safe as sorry πŸ˜‰

What "faults" though? I had automations working fine that are suddenly "broken" in 2023.11. The update did something to the device IDs that causes them to fail; there were no faults in the automations at all.

So enhanced validations in #102766 seems to be the culprit, but it just raises errors and logs. Is this something that would be a good candidate for the 'Repairs' system? As in, 'we found x won't work because y no longer exists: click here to delete y and fix the issue'. I'm interested in digging into this as a possible solution.

Better feedback is absolutely required, as all I could see in the UI is "automation disabled" without explanation. The triggers that were the cause also appeared to be fine until expanded. The header of the triggers maintained the text explanation and only upon expanding them was the device field revealed to be blank.

image image

Better feedback to the user on the cause is absolutely required. But, ideally, the update just wouldn't break the automations at all.

So i created automations via the GUI via device. No it's wrong and it's my fault and i have to rebuild my entire automations??

I also created my automations with the GUI. If using a device trigger is "incorrect", the GUI should not let us do it.

stamandr commented 11 months ago

I have over a hundred automations affected. I am slowly rebuilding everything, but keep shaking my head over the fact that even if you disable the problem device or entity the automation remains "unavailable" This just doesn't make any sense to me. For example if you have a device that dies, then it kills your automation, which could have a dozen or so other entries in it that do work. You should just be able to disable the problem entry and the automation should continue to run....

Renegade605 commented 11 months ago

For example if you have a device that dies, then it kills your automation, which could have a dozen or so other entries in it that do work. You should just be able to disable the problem entry and the automation should continue to run....

I agree with this as well. I'm all for being alerted to a problem with my server (something HA already doesn't do nearly enough). But, automations (everything in Home Assistant, really) should continue to run as best as possible while any fault condition exists to avoid disrupting the users.

Failing silently is bad. Shutting down everything over faults with part of the system is also bad.

szyszyla commented 11 months ago

I have exect same problem. All automations works just fine in 2023.10.

pove commented 11 months ago

I've found this issue late, I already docummented here my issue: https://github.com/home-assistant/core/issues/103720#issuecomment-1812092350

clueo8 commented 11 months ago

Do we have a workaround for this?

Will replacing all device IDs with the corresponding entity IDs fix it? https://github.com/home-assistant/core/issues/102937#issuecomment-1793451711

pove commented 11 months ago

Do we have a workaround for this?

Will replacing all device IDs with the corresponding entity IDs fix it? #102937 (comment)

Yes, it worked for me in all my automations and scripts that were unavailable.

boehser-enkel commented 11 months ago

Is there a short way to get these (instead of creating new)?

clueo8 commented 11 months ago

For me, all the automations that had "Unknown Device" errors were using the "Device" trigger/action. When editing in GUI, it was just missing the device, as if I just added a new trigger/action/condition for a device. I simply just selected the device I needed and saved. I had about 10 to fix manually.

boehser-enkel commented 11 months ago

So it got changed by HA that newly created device trigger use device_id: ID instead of device_id: entity ID Name but the entries where not corrected. No it's the users fault?

sanderlv commented 11 months ago

Where can a device id be found? (might be a stupid question but I cannot find it).

I am looking for the device id of a phone since recent updates of HA my automation (blueprint) does not work. Situation: https://community.home-assistant.io/t/blueprint-automation-automation-is-unavailable/641625

sanderlv commented 11 months ago

Do we have a workaround for this? Will replacing all device IDs with the corresponding entity IDs fix it? #102937 (comment)

Yes, it worked for me in all my automations and scripts that were unavailable.

Hi, where do you find device IDs? I can find it for a mobile device.... (companion app).

HVR88 commented 11 months ago

When editing in GUI, it was just missing the device, as if I just added a new trigger/action/condition for a device. I simply just selected the device I needed and saved.

That's not the case over here.

Is anyone looking at getting this fixed so that users can migrate to new releases without trashing or manually repairing all affected automations?

stamandr commented 11 months ago

I truly hope someone is looking into this. I have to many automations to fix. I'm still bugged by the fact that even if you disable the problem device or entity the automation remains "unavailable" This just doesn't make any sense to me. For example if you have a device that dies, then it kills your automation, which could have a dozen or so other entries in it that do work. You should just be able to disable the problem entry and the automation should continue to run....

mefranklin6 commented 11 months ago

When editing in GUI, it was just missing the device, as if I just added a new trigger/action/condition for a device. I simply just selected the device I needed and saved.

That's not the case over here.

Is anyone looking at getting this fixed so that users can migrate to new releases without trashing or manually repairing all affected automations?

I sort of hit a wall when looking into it, but it's really my first time looking at the codebase.

I'm unsure of how raising InvalidDeviceAutomationConfig actually disables the automation.

villasenor commented 11 months ago

I've also noticed this, and it has broken many automations. For me, the presence of invalid triggers/IDs is irrelevant, because this also breaks the automation for valid triggers. For example, if I have a button that triggers an automation and a location-based trigger from the iOS app, if the button ID becomes invalid, it shouldn't prevent the valid location-based trigger from being able to run the automation...but that's what happens today because the entire automation gets disabled. Home Assistant's automation experience has come so far, but maybe this will be the thing that finally pushes me over to Node-RED for automation :)

zebraelch commented 11 months ago

I think underlying this issue is a fundamental problem, it's that programmers want these scrambled IDs to make it more logical for them, while users want human readable and identifiable IDs that make sense to them and allow with one look to know what's going on. Now the question is, who is home assistant for.. I for one are not a machine or programming scientist..that's why I have still not updated to anything 2022.11 as it broke 60% of my automations. As I understand this issue came to light due to a change from deviceId to entity I'd, but the problem for me is, any broken automation in 2022.11 only gives me that unreadable machine code I'd, so how the heck am I to know which entity I'm supposed to enter there? I won't go and manually write down the device IDs for 50 automations in 2022.10 to be able to find them in 2022.11, I might as well start all over. I simply don't get why these scrambled IDs have to be there at all, when it's enough to make sure the human readable IDs are unique. You tell me which of the below pictures makes sense to a human, I for one can't make anny sense of those yaml IDs at all, why do they need to be there?

Screenshot_2023-12-02-10-07-50-50_40deb401b9ffe8e1df2f1cc5ba480b12 Screenshot_2023-12-02-10-07-56-47_40deb401b9ffe8e1df2f1cc5ba480b12

wittzer commented 10 months ago

Any updates on this? I have 30% automations failed. deselect & reselect the device in dropdown list doesn't help. Thanks anyway for anyone who fixed this.

ThatTallGuy21 commented 10 months ago

Just chiming in that this also impacted my automations as well and am currently going through and manually fixing things. No idea why this is happening or when. I'm on 2023.11.3. Pretty annoying.

Edit: Looks like something changed in HA with my Robot Vacuum at an entity level. So I had to go and update each automation manually that referenced it as a device.

mefranklin6 commented 10 months ago

For those of you asking if someone is looking into this, yes I am still looking into it but this would be my first contribution and like most developers here, am working here completely in my free time. Since it is my first time even looking at the codebase, there's extra steps I have to go through. I would love to collab with someone more experienced, but if I'm indeed the only one, then here's my progress:

My goal is to turn this into an actionable repair issue, where you can just click a button and the repair system would remove the reference to the non-existent device so your automations/scripts no longer fail. (BTW this affects scripts as well, maybe scenes too)

Progress:

w1ld3r commented 10 months ago

If using Docker, by removing the unknown device from /config/automations.yaml file relove my issue.

tonymaro commented 9 months ago

The devs do a great job on this project and I'm thankful for it every day. I'd like to point out a scenario or two that suggests more critical thinking when making a change like this.

In most cases this change caused people to lose automation on light switches. No big deal. Some of us use HA for a few more critical things like monitoring for water leaks or maintaining other equipment, or locking doors at night.

In my case I upgraded yesterday (I use docker-compose) to grab the latest. Like always, I go through after the upgrade and verify my switches work in the UI on the app. Everything functioned. I went to bed, with zero indication that 2/3 of my automations didn't work. No, I didn't go to the automations tab or I would have seen them all in red, but there was no notification and since the UI functioned fine and controlled all my devices, including the pool pump, I didn't worry about it. Upgrade success!

One of my automations triggers the pool pump to come on if it drops below 34F to keep it from freezing. Last night we were below freezing.

No, I didn't burst a pipe, and shame on me for trusting an OSS project as if it were commercial grade anyway.

All but one or two of my configs were created using the UI, set once, and left alone for months or years now. To suddenly have 2/3 of my automations fail because device ID's set with the UI suddenly change is disappointing at best. The lack of any feedback that there was a problem in the notifications screen was a total failure in QA and UI design. I'm sure one or more devs realized this was going to happen to some degree and brushed it off as unimportant and a one-time glitch.

Considering the system disables the automations as "unavailable" when that happened or at startup the addition of an alert notification when it does something like that could save a lot of people major headaches, and at least let others realize there's problems right away instead of finding out hours or days later when something fails to occur.

I'm sure like me there are people who don't upgrade immediately following a new role-out. Adding that notification alone when an automation becomes unavailable would save a lot of people headaches in the future as they finally upgrade past this release, and probably come in handy for some future changes or problems as well.

stevedngo commented 6 months ago

Have we made any progress in fixing this issue? I've been holding off from upgrading but if this isn't going to be resolved then I might have to bite the bullet by upgrading and manually entering all my device IDs.

issue-triage-workflows[bot] commented 3 months ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment πŸ‘ This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

stamandr commented 3 months ago

Please don't close this. I updated to 24.7 the other day. It changed a bunch of device ID's again. Some automations (blueprints) don't allow for entities and I had to use devices, which of course is now screwed up again.

rbeumer commented 3 months ago

I also have this issue right now, it began after I did the update from 2024.6.1 to 2024.7.1. The trigger device id is unknown and the lights that should be turned on are empty in some automations

bphillips09 commented 3 months ago

Same, this just happened to me with dozens of automations.

stamandr commented 3 months ago

Did you have device ID's change ?

issue-triage-workflows[bot] commented 3 weeks ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment πŸ‘ This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.