No triggers listed for devices in creating new automations

Configuration Z-Wave
,
1

I am running Home Assistant 2023.1.1 in a Docker container on a Synology NAS. I have zwaveJS running in a Docker container on a raspberry Pi. TLDR: suddenly, I lost the ability to list triggers associated with devices when creating new automations. Every device says “No triggers” and I see the error below in the logs. I also lost the ZWave Info dropdown from the Device Info page (see screenshot below).

(Sorry for the very long explanation, the next two paragraphs are likely not relevant, but I wanted to provide the context).
I was previously using an older raspberry Pi with Homeseer Smartstick+ ZWave USB stick, but the whole setup suddenly got incredibly flaky—the stick would suddenly not be present as a device on the raspberry Pi at times, the stick seemed to be resetting constantly, the Raspberry Pi was constantly at 100% CPU, and Home Assistant could only connect intermittently. I couldn’t see any ZWave devices on HA.

After a long and painful process of debugging, I moved to a new Zooz 800-series stick. I excluded and re-added all my devices to avoid potential issues with backing up and restoring when moving to an 800 series stick. This was only partly successful with the old Pi, so I finally got a new Raspberry Pi as well, moved the stick and copied over the store directory. Perhaps stupidly, I gave the new Pi a different IP address and added a new Zwave integration (disabling the old one) rather just leaving the old integration in place and changing the associated IP address, which probably would have been the better way. Anyway, finally, everything was working except for one small thing and tugging that thread unraveled the sweater.

(Here is the most relevant stuff)
For some reason, automations involving one of my Zooz ZEN32 scene controllers failed to work after the move (another one was working fine). In the UI, it said “Unknown trigger” for automations involving the scene buttons (other triggers were listed, just not the ones involving the scene buttons). I tried to exclude and re-add the device. Despite the Zooz stick being right next to the switch, this failed repeatedly and right after the first failed attempt to remove the device was when I started having the issue I’m asking for help with: suddenly, when creating automations, I couldn’t see the list of triggers for any device when creating a new automation, though existing automations were still working (and I suspect that I could probably create new automations in YAML editing mode).

After a few days of trying, I was able to finally exclude the ZEN32 and re-add it, after which that device was fully functioning again and was now the only device for which I could list triggers!

Looking at the logs, anytime I try to add a device as a trigger in a new automation, the follow error occurs.

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 27, in _handle_async_response
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/device_automation/__init__.py", line 331, in with_error_handling
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/device_automation/__init__.py", line 458, in websocket_device_automation_get_trigger_capabilities
    capabilities = await _async_get_device_automation_capabilities(
  File "/usr/src/homeassistant/homeassistant/components/device_automation/__init__.py", line 303, in _async_get_device_automation_capabilities
    capabilities = await getattr(platform, function_name)(hass, automation)
  File "/usr/src/homeassistant/homeassistant/components/zwave_js/device_trigger.py", line 466, in async_get_trigger_capabilities
    node = async_get_node_from_device_id(hass, config[CONF_DEVICE_ID])
  File "/usr/src/homeassistant/homeassistant/components/zwave_js/helpers.py", line 225, in async_get_node_from_device_id
    raise ValueError(f"Device {device_id} config entry is not loaded")
ValueError: Device 99a683a52e75baadcc700f1d50659c94 config entry is not loaded

I could trace it to this line of code on my version of HA:

I have Googled this error and related phrases repeatedly, getting very few hits and nothing that seems related to my issue. I can guess what it means that the config entry is not loaded, but I don’t know why.

What the function seems to be doing is trying to convert the device ID in HA to a Device ID on the ZwaveJS server (this is just an index from 1 to 89 on my server). It apparently needs this to query the server for a list of triggers, which are not cached locally in HA. So perhaps the most important symptom that has nothing to do with automations is that the ZWave Info drop-down that used to in the Device Info for every device just suddenly disappeared (except for the two devices that are working). These screen shots show what I mean.

Screenshot_20240408-154431_Home Assistant.jpg_compressed
Screenshot_20240408-154431_Home Assistant.jpg_compressed1080×2280 133 KB

Screenshot_20240408-154417_Home Assistant.jpg_compressed
Screenshot_20240408-154417_Home Assistant.jpg_compressed1080×2280 143 KB

The one above has no ZWave Info section, while the one below does have it (and you can see the ZwaveJS server ID listed there: 89). They all had it before this issue arose.

I back up my home assistant configuration daily so I’ve done a diff of all the files in the config/.storage directory from before and after. There were many more differences than I would have expected, especially in core.entity_registry, but most look pretty innocuous and there was no smoking gun I could see.

I also tried updating to the latest version of the HA container, but that did not go smoothly (perhaps due to the same corruption that is causing my current issue) and I decided it’s best to try to debug this in the version I have, which is working smoothly except for the fact that I can’t add mew automations (using the UI).

I’m sure that someone familiar with the code and exactly how all this hangs together will be able to help me figure out this error easily. It’s got to be something “obvious.” I really enjoy the DIY nature of HA and this is the very first thing I’ve come up against that I was not able to figure out on my own. I can’t believe this is a problem unique to only me. Anyone out there have any ideas?

2

If this is a pre-existing automation, you will need to delete the trigger and re-create it so the new replacement device is selected, or else edit the trigger in YAML and update the device_id. Your scenario is effectively a device replacement, which is not supported. If that’s the case the device currently selected corresponds to the disabled integration. This is one of the problems with using device triggers/conditions/automations.

IMO, better to use state triggers so you can just update entity names in case of device replacement.

1 Like
3

Thanks, yes, I should have mentioned that I am aware of the need to fix up the automations after re-adding the devices (these were mostly broken at first, as expected). I did that and as mentioned, existing automations are now working fine. The only thing that is not working is the drop-down menu listing the triggers associated with each device. The exception are two devices I excluded and re-added once more since I started to have this problem. Those are working. I could re-ad all my devices one more time, but I want to avoid that, since I have almost 80 devices.

4

What does your YAML look like? According to the message, 99a683a52e75baadcc700f1d50659c94 is the problematic device ID. Did you relace that ID that in all places?

5

Cannot stress this enough. Entity states > device triggers (by 10000000x). Way less problematic, especially if you are using MQTT for devices.

6

I get the same error with all devices (but the two devices added since I started having this issue). The error is not specific to any one device and all existing automations are working fine, so the YAML itself is also not the problem.

It seems that the list of triggers associated with each device is retrieved from the ZwaveJS server in real time rather than being cached in HA. The failing function call seems to be trying to convert that device ID into the index on the Zwave JS server, so it can make the query. That is what is failing.

And actually, that is an important part I neglected to mention. All devices used to have a “ZWave Info” drop down that listed the ZWave ID on the ZWave JS server (an index between 1 and 100). All the Zwave Info drop-downs also diappeared suddenly except for those two devices that are working.

I now added some screenshots above in the original post to show what I mean.

7

I hear you, but it’s very difficult to determine the correct entity state to look at with the Zooz scene controllers in particular and device triggers are much easier (for me, anyway). But in any case, automations and triggers are perhaps not really the central issue. A more obvious symptom is just that the ZWave Info drop-down for each device, that used to list the device ID on the ZWave JS server, just suddenly disappeared and this is what seems to have broken things. I added some screenshots and more info above.

8

Is it the same device ID every time? I was suggesting you check your automations for that device ID and see if removing/replacing it improves anything.

Yes, it’s getting the z-wave node for a given device ID, but there’s no communication with the z-wave js server, the server doesn’t know anything about device triggers. The error shown is HA complaining because there is no loaded config entry for the device ID, i.e. there’s no matching loaded Z-Wave integration for that device.

If you look at the file .storage/core.device_registry you can see all of the devices that exist and which integration instance (config entry) they map to. Maybe something got wrong there.

Basically the same problem. The frontend asks HA about the device, and the integration says it doesn’t know about the device.

It’s almost as if you are accessing devices for the disabled integration. Usually those will be hidden.

2 Likes
9

Suggest you update to something a bit more recent. A lot of changes have been made in the last 15 months…

Note the new source for the Docker container image:

10

No, it is always the device ID of the device I am choosing as the trigger device for some new automation. I start to create an automation, choose a device as the trigger, then the drop-down list of triggers says “No Triggers” and right at that moment, the error appears in the log. I’ve checked the device ID in .storage/core.device_registry and it’s the correct device ID, the one associated with the newly created device. This was all working correctly with all the new devices and automations before I tried to exclude the scene controller.

Sure, I see that this function is not itself communicating with the server, it looks like it’s gathering information it needs to communicate with the server at some later point in the process. The error does indicate something was not loaded, but these devices are all loaded and associated with the new Zwave integration. I verified this manually by looking at their entries in .storage/core.device_registry. They are functioning properly in every way except this one. For most of them, nothing changed between the configuration when they were working and when they weren’t. Here is an example entry

      {
        "area_id": "hallway_and_stairs",
        "config_entries": [
          "2806b955e3b5150a80fbb7acc847fee3",
          "c34746a28b13784bcdcbf75573a9eafa"
        ],
        "configuration_url": null,
        "connections": [],
        "disabled_by": null,
        "entry_type": null,
        "hw_version": null,
        "id": "be7c493e8ca3099615d1f0c36857f278",
        "identifiers": [
          [
            "zwave_js",
            "3980992797-17"
          ],
          [
            "zwave_js",
            "3980992797-17-99:18756:12344"
          ]
        ],
        "manufacturer": "GE",
        "model": "14294 / ZW3005",
        "name_by_user": "Main Entrance",
        "name": "In-Wall Paddle Dimmer, 500S",
        "sw_version": "5.29",
        "via_device_id": "4402f28612d4bf1145f8cbbd7e826041"
      },

The two entries in config_entries are the old and new ZWave integrations and they are both listed in .storage/core.config_entries. I did wonder if having devices associated with both the old and new integrations could be causing the problem, but deleting the old entry from some devices didn’t seem to fix anything.

I wanted to just delete the old integration altogether, but I read that this deletes all devices associated with it and those devices shouldn’t be deleted, as they are still in use with the new integration, Maybe they will only be deleted if the devices are associated only with the deleted integration?

11

Yes, I did try upgrading, but this resulted in wholesale changes to the files in .storage and enough stuff appeared broken that it really didn’t appear as though that would be a fruitful avenue to debug. I could go down that path again as a last resort, but it seemed easier to debug first, then upgrade.

12

If the config entries really are both Z-Wave integrations, then this is exactly the problem. It is not expected that a single device be associated with multiple Z-Wave integrations. The error you are seeing is because the old integration is disabled.

There can be multiple config entries, for example for “switch as X”, when you assign a switch as a light, for example.

Since you moved to a new stick and re-added the devices, there was no reason to keep the integration, everything is new anyways.

13

It certainly occurred to me that this might be the issue, but at the same time, I can’t explain why the devices then appear to be loaded and functioning properly, as well as appear in the list of devices I get when I ask for devices associated with the active ZWave integration? And why it was working well until I attempted to remove the scene controller? Why are there no other errors/warnings on start-up about this? Why would it even be made possible by HA for a device to be associated with two different Zwave integrations? I guess there are good reason to allow multiple config entries, but shouldn’t there be a check for whether there are two Zwave integrations? Maybe this just never came up before.

But anyway, I am willing to go down this path, but what is the way forward? If I delete the old integration, is that going to delete the devices or not? I can easily edit .storage/core.device_registry and remove all the config entries that point to the old Zwave integration, but I did try that with a few devices and it didn’t make a difference. Maybe it needs to be done with all devices to really fix the problem? I guess I can always back up everything and then restore the old configuration is needed.

Yes, but the devices were actually re-added to what was the old integration because that was when I was using my old Raspberry Pi with the new stick. When I bought the new Pi, I moved the new stick and the new store directory over to the new Pi, which was then detected as a new integration. My fatal error was not to just ignore that and simply point the old integration to the new IP address. I guess I was trying to preserve my ability to go back incase something didn’t work. That is the mistake I’m now paying for. And since all the devices were re-added to the old integration before moving the new Pi, I didn’t want to delete the old integration for fear of losing all the newly added devices. If this indeed the issue, then I will have paid dearly for that one fatal mistake :).

14

I would make a backup and just delete the old integration, see if that solves it, quick and easy. If that doesn’t, then I’d hand-edit the storage files and remove the unwanted config_entry and then integration (core.config_entries file).

Except the way you did it is exactly how you reconfigure the integration. I see nothing wrong with it. Normally you will get a “Device already configured” message and the existing integration will just be reconfigured. HA detects the home ID and matches it with the existing entry.

15

Ugh, deleting the old integration did fix it! I had already started to do that exact thing long back and now I realize should have just pulled the trigger. I was stopped in my tracks by the very ominous pop-up warning that all entities and devices associated with the integration would be deleted. Even this should not have stopped me trying, as I could always have restored from backup. Anyway, it seems that the devices are indeed only deleted if they are associated with only the integration being deleted, which makes sense.

It seems not to have happened quite the way you would think it should have. I did not actually get any kind of “device already configured” message. It did obviously detect that the devices were the same ones, but instead of just moving them over to the new integration (and deleting from the old) or issuing some kind of error/warning that the device is now associated with two different integrations (which is obviously a problem), it just silently associated them with both. And this mostly did not cause problems, only manifesting itself in a very subtle way. I still don’t really understand it. I guess this could be considered a subtle “bug.” Maybe I’ll actually look at the code and try to figure out how it could be fixed.

There’s a lot of other stuff that happened along the way that I still can’t really explain. Why was everything working fine, even after moving to the new Pi and creating the new integration, right up until the moment that I tried (unsuccessfully) to exclude the scene controller, if that was a red herring? I also have about half as many entities associated with the new integration as I had with the old, though the actual devices are the same. A bunch of entities got deleted somehow, though they are not ones I am depending on for anything.

Anyway, thanks for pushing me towards a fix! Your help is very much appreciated. I wasted a lot of time on this, but I sure understand the internals of home assistant much better than I did!