Feature Request: temporarily "disable" devices

airdrummingfool commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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] commented 2 years ago

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 commented 2 years ago

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

M1cN commented 2 years ago

Me too. I would like to see this also.

ahemwe commented 2 years ago

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

git-developer commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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] commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

+1 :)

Isy99 commented 2 years ago

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] commented 2 years ago

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 commented 2 years ago

I would love to see this feature implemented

github-actions[bot] commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

+1 for disabling christmas devices

drifter75 commented 1 year ago

+1

Loic691 commented 1 year ago

+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 commented 1 year ago

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 commented 1 year ago

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

airdrummingfool commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Clear, the disabled status is indeed a nice solution!

happyjaxx commented 1 year ago

(post)Christmas is saved !

Koenkk commented 1 year ago

Implemented! Right in time before Xmas. You can find this option under the frontend -> device -> settings page. Make sure to not forget pressing "restart" in the right top after enabling this.

Happy Xmas all! 🎄 🎅

Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)

zsiti commented 1 year ago

Thank you @Koenkk! Merry Xmas! 🎄

M1cN commented 1 year ago

Hi Koenkk, thanks happy Christmas to you too.

Op za 24 dec. 2022 00:32 schreef András Zsitko @.***>:

Thank you @Koenkk https://github.com/Koenkk! Merry Xmas! 🎄

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/10003#issuecomment-1364409670, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3ULYBAQXV4OV4NZZGDPYTWOYZBRANCNFSM5JLYPFRQ . You are receiving this because you commented.Message ID: @.***>

airdrummingfool commented 1 year ago

This is awesome! It's a huge usability improvement with devices that aren't needed year-round, thank you!

A bit of feedback for thought - I can try to work up a PR for these at some point:

The location of the Disabled switch in the Settings tab is a bit awkward - it is right in between what appear to be related settings: a "Retain" checkbox and then the "Retention" input box. Perhaps it could be shifted to above the Retain checkbox, or even above the "Friendly Name" field?
The frontend still flashes "Offline" in the device list's Availability column and on the device About page. Could that be changed e.g. to a grayed-out Disabled?

Also, I've seen a couple (two?) "Failed to ping" message since disabling my inactive devices. I disabled them a few hours ago, and as recently as a couple minutes ago I received this message in the logs:

Warning 2022-12-23 21:26:38Failed to ping 'Dining Room Light 3' (attempt 1/1, Read 0xb0ce18140362db83/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205)))

the device is disabled (it has the little circle with a slash through it by the image).

Thanks again for implementing this! And Merry Christmas!

Koenkk commented 1 year ago

I'll check about the UI points.

Regarding the pinging, did you restart z2m after setting it? (the frontend should show a red restart button at the right-top)

airdrummingfool commented 1 year ago

Regarding the pinging, did you restart z2m after setting it? (the frontend should show a red restart button at the right-top)

I thought I had (and the restart button was not showing), but I haven't been able to reproduce it after another restart, so perhaps I hadn't restarted, or maybe it was a fluke. I'll keep an eye on it (later 😄 ) and report back if I see it again.

Thanks again and Merry Christmas, y'all!

airdrummingfool commented 1 year ago

I pulled the frontend tweaks and they look great, thanks @Koenkk! Happy New Year!

Koenkk commented 1 year ago

@airdrummingfool happy new year 🎉 This feature is now available in z2m 1.29.0, I assume this can be closed now.

Loic691 commented 1 year ago

Thanks @Koenkk for this feature implements in the 1.29.0 It's great to have this becasuse in my own side i have always devices off line (summer electric line which is power off in winter, tests of module,..)

And happy new year 😃

RubenKelevra commented 1 year ago

Super great idea! Thanks for implementing this to @Koenkk and thanks to @nurikk, too!

Isy99 commented 1 year ago

Mni thanks for adding that feature, works fine to me.

Bolukan commented 1 year ago

Great feature, not only for christmas trees. Also for people who buy a batch of devices, register them all, and deploy them gradually (or buy too much, lol) or in temporary configurations (like christmas trees). Happy new year.

gpbipin commented 1 year ago

Thanks for adding this great feature which makes life easy in many cases. Shout out to all involved. Big Thanks and have a great year in 2023!!!

E30M20B20 commented 4 months ago

The function is really great, but I have to ask possibility to do device disabling using automation scripts. Why I need this: if you want enable/disable christmas tree lights one time a year, this is OK. But if power supply lost several times a day (I'm from Kiev), about 15 devices are lost/found by z2m and pings to lost 15 devices seriously bores my system

Koenkk / zigbee2mqtt