Feature Request: temporarily "disable" devices

[airdrummingfool]

Is your feature request related to a problem? Please describe

I moved a few months ago, which means I had to take down all of my Zigbee devices, pack them up, and transport them to my new place. After moving in, I was able to easily plug in/put batteries back in each Zigbee device, which reconnected pretty seamlessly to my z2m network without needing to re-pair (I kept the same coordinator, server config, etc). However, I have not yet finished installing some of my devices, so they show up as "offline" in z2m. I also often see errors in the frontend related to the devices I haven't reconnected yet (I think mostly availability pings failing, as well as LQI queries failing).

I'm concerned that these offline devices could somehow affect my network; e.g. if there is extra traffic directed towards those devices that cannot get delivered.

I think this could also be useful if a device breaks or needs to be replaced, or if you want to test what removing a device (e.g. router) would do to your network.

Describe the solution you'd like

It would be nice if there was a way to mark certain devices as "disabled", so that they would be ignored from the network without needing to be fully removed.

"Disabling" a device might not fully remove it from the network as far as the coordinator is concerned, but it seems like the network has reshaped itself so that it no longer expects the missing routers, etc. It might be enough just to stop z2m from pinging them/showing them in the network map, and show them as "disabled" instead of "offline" in the frontend.

There is also the question of "disabling" a device that is currently on the network. Without fully removing it, it would continue to function, so perhaps this feature request is more of an "ignore"?

Describe alternatives you've considered

I could simply remove the devices from the network, however that means when it's time to set them up, I would have to go back through the joining process, as well as re-set up the entity names and usage in Home Assistant. Removal also requires me to power them back on long enough to reconnect so they can be unjoined.

I could also disable the availability feature for each device. This requires some work, but less than full network removal. I don't know if that would actually stop all communication attempts from z2m, which would be ideal.

Additional context

This might be a very niche request, and I completely understand if it is out of scope. Full removal and re-adding later is not an undue burden, this would just make things a bit easier in some situations :) Thanks so much for z2m, it is a great project!

[airdrummingfool]

As I wrote this, I became more and more aware that disabling the availability feature for these specific devices would probably get me 85% of the way to achieving what this request is for. I just tried it and the frontend even shows "Disabled" in the Availability column... huh.

There are only a couple of small differences:

• The availability feature cannot currently be controlled per-device through the frontend (as far as I can tell)
• Does disabling the availability feature for a device stop all z2m-generated communication to that device (e.g. when generating the map, etc)?

Anyways, I'm happy with disabling availability, so I'm going to go ahead and close this. But it's here for the record in case someone else finds it and wants to add on. Thanks again for z2m!!

[airdrummingfool]

OK, I did find one fairly sizable drawback to disabling Availability in order to ignore devices: the device is no longer marked as unavailable in Home Assistant, and thus reports its last known state. In some cases, this triggers alerts in HA that should not be triggered (since the sensor isn't actually reporting).

I think ideally, "disabling" a device in z2m would automatically mark it as unavailable, without doing any actual pinging.

Still a niche request :)

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[smekac95]

Hi, it looks as usefull feature. I woud like to support this request. :-)

[M1cN]

Me too. I would like to see this also.

[ahemwe]

Very useful, since I use several zigbee devices only around christmas.

[git-developer]

I agree, looks like a valid request to me.

I'd appreciate if one of the maintainers could write a few words about the difference between the following scenarios concerning the impact on message routing between other devices:

• a device joined the network but is not available, with availability: false in its configuration
• a device joined the network but is not available, with availability: true in its configuration
• a device is removed from the network

Will there be more or less traffic in either scenario?

[hijamie32]

Same would be great to have this feature - have loads of Christmas stuff which are throwing up errors as no longer powered up.

Cheers

[kira-etiscan]

A small addition to this: If the device reports again, it should be activated automatically. I know I would otherwise forget to do it (e.g. with christmas decorations).

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[GsakuL]

i think this should be re-opened. It seems very usefull.

Also for other cases like: "i try out/pre-configure this device. but i can't put it in yet".

Maybe even expand on the idea: i have a "fancy" table lamp for my bedside. It has a normal E27 socket. But I'd like to turn it off completly, as in "cut the AC". The lamp has a touchable base. I don't really want to put an extra remote on the table; nor would i want to "gut" the touch-electronics. The thing is: I have not found a light bulb, that can do all of what i want (change RGB/temp and brightness; can go really gloomy; be "thin"/not bulky; but start with the last known state from AC loss; be "cheap" (paid around 10€ for the bulb and 12-is€ for the lamp; which came with a simple white bulb) ). So my bedside lamp would be missing from the network, but i want to still change if wanted.

Otherwise I'll just open a new one, an reference this

[zsiti]

I also think that this should be reopened. In addition to the use-case of seasonally used "Christmas lights" scenario, I would like to add that my radiator thermostatic valves are not used during the summer season, and it would be nice to be able to temporarily disable them.

[gpbipin]

I too support the need for this feature.

My use case: I'm currently in the process of building the mesh in my 4- floor house and am testing the sweet spot of router density per floor. Have some Hue bulbs, Tradfri repeaters and bulbs, CC2530+CC2591s, CC2652s, etc, so testing the different types as well depending on the proximity to what works best with what end devices. Sometimes some of them just need to be disabled so that the network map doesnt struggle.

Regarding Availability feature, i haven't set availability. I see all devices showing disabled in the device properties page irrespective of their link status. Is this expected?

[Mr-Groch]

+1 :)

[Isy99]

This feature really would be great. I have about 50 devices, where 10 of them are switched off (not used, e.g. X-Mas stuff, or other reasons) These 10 devices should not be pinged any more, nor showing up in the network map. An automatic "enable" has no sense to me, as it may be necessary to disable a device although it is connected to power.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[Mr-Groch]

I would love to see this feature implemented

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[buanet]

Please keep this open, as this feature is still requested.

And to all watchers: Make sure you gave a thumbs up 👍 to the original request (first post). 😺

Regards, André

[Isy99]

Would be a great help reducing (temporary) system traffic (e.g. ping, maps drawing etc.) due to switched off zigbee devices, e.g. illumination for winter time.

[GroteGehaktBal]

I would like to see this feature too, my offline switches cause extra overhead that is unused. simply disabling a switch would be cleaner and stops the annoying error messages to pop up.

[OZ1SEJ]

I initially paired up all my IKEA outlets, thinking that once that was out of the way, I could just disconnect them, put them in a drawer, and plug them in once I needed them. Now the Z2M map takes forever to draw, because it's apparently waiting for them to respond. If I remove them entirely, I would have to go through the whole pairing process again, when I need them. This feature would allow me to do just what I need.

[MarcoDroll]

+1 for disabling christmas devices

[drifter75]

+1

[Loic691]

+1. I have Hue device wich is not yet installed. Then they in their box. I paired them for testing purpose. Now I have few error messages in Z2M. It would be great to disable device in the GUI list.

[Koenkk]

Given that with the next release (1 Jan) it is time to get rid of the Christmas lights again, this seems to be a good moment to implement this feature.

I was thinking what this feature should do exactly:

• The device will still appear in the frontend but it should be visually clear that the device is disabled (greyed out? CC: @nurikk)
• Device will be excluded from the following features:
  • availability
  • configure (calling the configure() of the definition when it changes)
  • state updates through groups
  • network map
• Device is still included in zigbee2mqtt/bridge/devices (but a property will indicate that the device is disabled) and you can still send messages to it via e.g. zigbee2mqtt/MY_DEVICE/set {"state": "OFF"} (which will give the normal timeout error when the device is not reachable).
• This will become configurable via the device options, e.g.

devices:
  '0x00124b0021b77eea':
    friendly_name: '0x00124b0021b77eea'
    disabled: true

• The biggest question for me is what the HA integration will do with disabled devices (CC @airdrummingfool since you are the OP and are using HA). There are 2 options:
  • Don't discover
    • Con: when enabling them again, you need to reconfigure any options like the icon and friendly name
  • Discover but mark as unavailable
    • Con: you will always have an unavailable device in your HA setup which is not handy. e.g. in my case I use an automation which sends a push message when a device becomes unavailable.

[Loic691]

Hi I vote to discover by HA and will be unvailable. Which is in fact the real state....

[airdrummingfool]

Awesome, thank you!

I also vote to continue to include it in HA discovery marked as unavailable. HA's entity "Advanced settings" include the ability to set an entity's status to Disabled, so if it is causing a problem (e.g. like in your automation) the entity could be disabled on the HA side.

[GsakuL]

Nice to hear.

I am too are in favour of "unavailable in HA". It seems more consistent: it just represents the real state better. The device would also still appear somehow in Z2M frontend. Setting it to "disabled" or "hidden" is "double work", but still waaay better than the "false-positive errors" imo.

Also regarding HA automations: if the device/entity is "disabled" it could be automatically ignored by automations, depending on what you actually do. And if you use a "state-change-to"-trigger approach (like with the event "state_changed" to include all entities), it should report it only once (if not "disabled").

[Koenkk]

Clear, the disabled status is indeed a nice solution!