Update general.py

[MattWestb]

Making ZHA long pull little more realistic by 4.88 min instead of 6 seconds.

Breaking change

Proposed change

Making EZSP coordinators less keen losing sleeping end device and battery draining for IKEA because the NCP is "busy" and not acking network frames => devices is leaving.

Type of change

What type of change does your PR introduce to Home Assistant?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

• This PR fixes or closes issue: fixes Ikea switches and remotes consume batteries very fast and stop responding after replacing the batteries #43969
• This PR is related to issue:
• Link to documentation pull request: [Bug report / Enhancement request] Broken configuration and batteries draining of all IKEA controlling device zigpy/zigpy#679 Configuring IKEA controlling devices. zigpy/zigpy#604

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[homeassistant]

Hi @MattWestb,

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[probot-home-assistant]

Hey there @dmulcahey, @Adminiuga, mind taking a look at this pull request as its been labeled with an integration (zha) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[Adminiuga]

This would yale locks to miss the commands. This change should only apply to Ikea devices. Check for the manufacturer name or manufacturer Id and apply custom long poll only to Ikea

[MattWestb]

I agree with you for 110% for no EZSP coordinators !!

Or better only for Zigbee light controllers (from ZigBee Lighting & Occupancy
Device Specification) that all other brands is also being hitted like Philips Hue and exceptions for controllers that is not light controller and opposite and being configured in the ZHAQuirk but need large changes in ZHA and underlying libs.

But then EZSP coordinators is oft "lazy" and is not acking frames also down in the IEEE 802.15.4 layer that the pulls is as i have writing in some post like zigpy/zigpy#604 (reply in thread) and later post in the same issue for (one sleeping end device) longer time is sleeping end device is very likely leaving network if not having one router that is OK in its range and eating batteries because one bug in there firmware (Is on the Silabbs fixed list on newer EZSP).

Its looks working better with EZSP 6.7.8.0 but not 100%.
If the sleeping end device is connected to one router its looks working OK if the router is not one lazy one.

If someone is doing one "IKEA fix" you is getting problems with other sleeping end device that doing check ins and ZHA is setting the long pull to 24 = 6 seconds that is direct connected to one EZSP coordinators. (Perhaps Xiaomi sensors without routers that i have seen many have problem with then being direct connected to the coordinator is being triggered of the "fast long pull").

As you is knowing im not one code worrier so i cant helping implanting some more advanced code in ZHA so its ending that you must living with user having the "IKEA battery draining " problem.

I can only recommending and i have putting over 100 hours of sniffing in in Zigpy git with analyses and if you need more im willing providing more for you.

Thanks for you attention and say if i shall deleting this PR then its only making ZHA working worse.

Regard.

Mattias

[MattWestb]

One thing bellow v8 is having the timeout for sleeping end device set to over 4 hours so it cant being problem with 8 minutes pulls from end device (if they is doing it OK).

[dmulcahey]

This would yale locks to miss the commands. This change should only apply to Ikea devices. Check for the manufacturer name or manufacturer Id and apply custom long poll only to Ikea

should we only do non mains IKEA devices?

[Adminiuga]

Yes, Just for Ikea would suffice as mains powered devices don't have poll control 99.9%

[MattWestb]

@dmulcahey Pulling is only done by end device if being configuration and if its parent is supporting it.

I have changing my test to time 1160 (4.88 min) that is "IKEA default" then not being configuration then the end devices was rejoining most times then doing pulls.
zigpy/zigpy#604 (reply in thread)

I need little more time for see if its working OK for saying its good or not.

[MattWestb]

@Adminiuga I think all "controller" device can having it but the problem is the the blinds that is one end device (sleeping or not) but need getting commands from its parent.

Or excluding it in the first "round" for playing safe.

[Adminiuga]

I have trouble understanding what do you mean. I'm just saying to apply the longer long poll interval for Ikea and leave the curry one for all other devices

[MattWestb]

Yes that sound very good.

But Im only concern of the IKEA blinds that perhaps can needing faster long pull (wot i knowing they is one end device sleeping or not).

I dont have some on for testing and cant reading the code wot setting they is getting from ZHA.

If being possible setting it in quirk its no problem "adjusting" it / device type / model.

[Adminiuga]

What's the default setting on blinds and do they have this cluster?

[MattWestb]

If ZHA is not configuring pull control OK (its the normal then pairing IKEA devices) i expect ~ 5 minute (1160) but i cant verifying that.
If pull control is working (after reconfigure) they is getting the 6 second (24) from ZHA every check in.

They is having pull control cluster.
https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/ikea/blinds.py

[Adminiuga]

In other words there should be no problem blacklisting Ikea poll control config

[MattWestb]

Is it possible making the long pull interval getting overrides from quirk ?

Than its possible putting "custom" pull interval in the device quirk and all other devices is untouched and is using "ZHA default".

I think its one nice way implanting it but i cant coding it in the ZHA end (but very likely in the quirk with little help).

[Adminiuga]

It's far easier to do this here in the channel. I'll submit a PR later

[MattWestb]

Great and thanks !!!

I have running 3 different remotes for 25 hours connected to on router with 1160 (near 5 minutes = "IKEA default") and no problem ( = no rejoining or leaving and OK check ins, attribute reporting and OTA requests and only some repeated pulls that was not acked but no time out).

I putting the logs and analyses in the config IKEA controller discussion for documentation.

I need letting them running some more hours and then one new pass force connected to coordinator (after removing the router and repairing the remotes for getting it "clean") without routers for verifying its 100 % OK or 110 % better then "intense long pull" for IKEA controllers.

[MattWestb]

I was reading little more and disabling pull control cluster and losing the functionality is not god in one real Zigbee 3 network.

ZHA is normally not setting up pull control OK on IKEA controllers then pairing but it doing OK the doing one reconfigure and binding its to the coordinator.

Then the coordinator have the SEDs pull control cluster bonded and like sending one message to the SED its waiting for the SED doing on check and getting it from the SEDs parent then the SED is doing one check in,and then the coordinator is setting the SED in fast pull mode and sending the message and then ending with sending one long pull to the SED = no message i missed but it can taking some time until the SED is doing one check in and getting the waiting message from the coordinator.

Have still not finding the recommendations for wot long poll is recommended for different Zigbee profiles but it shall being adapted to the profile and device type.

I keep looking around and see if i can finding some useful information.

Best fund Silabs KB https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2018/11/29/a_reliable_way_fors-OTah

[MattWestb]

#48667 is in the pipe so closing this.