Allow wifi switches for mesh repeaters in AVM Fritz!Box Tools

[mib1185]

Proposed change

This will allow the use of wifi switches even on mesh repeaters. They are disabled by default, because they are an advanced use case.

Type of change

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

Additional information

• This PR fixes or closes issue: fixes AVM FRITZ!Box Tools: no Wifi on/off switches in Access Point mode #118588
• This PR is related to issue:
• Link to documentation pull request: Allow wifi switches on mesh repeaters in AVM Fritz!Box Tools home-assistant.io#36896

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
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format 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.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

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

[home-assistant]

Hey there @AaronDavidSchneider, @chemelli74, mind taking a look at this pull request as it has been labeled with an integration (fritz) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of fritz can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign fritz Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[mib1185]

Scenario "wifi only"

• master: 7530 ax on FritzOS 8.0.0
• slave: 7490 on FritzOS 7.59
• mesh-connection: wifi-only

as expected ... disabling the wifi on the mesh-repeater breaks the mesh, those the repeater becomes unavailable. Further the user is not able to re-enable it via HA ... if then the "button lock" security feature is also activated on the fritzbox, the user can't easy re-enable the wifi on the mesh-repeater anymore.
Further I was not able to find any switch in the mesh-repeaters WebUI to disable the wifi manually - even not with disabled "mesh configuration adoption".
There is also no possibility to reliable determine if the mesh uplink is wifi or lan baes (there is just no information about in the api)

Scenario "mesh with lan-backend"

• master: 7530 ax on FritzOS 8.0.0
• slave: 7490 on FritzOS 7.59
• mesh-connection: lan

in this scenario, disabling the wifi on the mesh-repeater does not cause the the repeater to become unavailable, so the wifi can still be re-enabled via HA.

---

Maybe this was also the reason in the past to consider to have no wifi switches for mesh-repeaters

[mib1185]

Even I've concerns about this, the docs get an explicit warning about WiFi switches in wifi-only mesh setups, further they are disabled by default, so I think we have done everything possible to avoid the user breaks its mesh.

[chemelli74]

Even I've concerns about this, the docs get an explicit warning about WiFi switches in wifi-only mesh setups, further they are disabled by default, so I think we have done everything possible to avoid the user breaks its mesh.

I think hat is such a scenario, we should not even offer the switch. Just specify in the docs why the entity is not created.

[fplanque]

I also tested this and it works as expected: the Wi-Fi entities are disabled by default for slaves in the Mesh and also for access points not part of the Mesh. Once enabled, everything works as expected. Mesh master switch will trickle down to the Mesh slaves but the slaves can also be turned on/off independently. Mesh master does not trickle down to non-meshed access points. Perfect 🥇

Note: my tests were done with a wired connection between master and slaves/repeaters.

[fplanque]

Even I've concerns about this, the docs get an explicit warning about WiFi switches in wifi-only mesh setups, further they are disabled by default, so I think we have done everything possible to avoid the user breaks its mesh.

I think hat is such a scenario, we should not even offer the switch. Just specify in the docs why the entity is not created.

Not offering the switches is taking away functionality offered by AVM and some of us would very much like to use these these.

If you are concerned about accidental enabling of the swicthes by someone who does not understand what they are doing, you could add a checkbox to the integration settings, disabled by default and wording like this: "[ ] Enable Wi-Fi on/off switches for slaves. NEVER ENABLE this if your fritzboxes are connected to each other via Wi-Fi. ONLY enable this if you absolutely need it AND ALL your fritzboxes are connected to each other via Ethernet WIRES. RISK of breaking your Mesh and requiring an Ethernet cable to reenable WiFi."

Please do not take away advanced features because some really dumb user, some day, after having ignored the warnings and after having enabled disabled features might need to connect to his repeater fritzbox with admin password to reenable wifi. Note: the repeater will NOT be the fritzbox that controls his internet access. It's almost harmless if it happens... once in a blue moon. Meanwhile advanced users will enjoy the advanced features every day.

[fplanque]

Actually, when you think about it, there are even move conditions that have to be met before a user could ever run into an issue:

1. he must run a mesh over wi-fi (no ethernet wire) (bad for performance but definitely happens)
2. he must disable the buttons on his fritzbox (already not something most users do, especially the less sophisticated ones)
3. he must want to use switches to disable wifi although he is running 100% on wifi (!!??)
4. he must enable the switches specifically by digging pretty deep into the entities of the integration
5. he must not think at all that disabling wifi via software will actually disable wifi (!!???) and thus break the connection between his fritzboxes

And once that happens, the solution is even simpler than I thought! No reset needed! The user who went through all the trouble above will simply need to:

6. temporarily use an ethernet cable between his 2 fritzboxes 'or between a computer and the repeater) so he can log in to the repeater fritzbox and turn the wifi back on.

I don't think it is the right way to punish advanced users (by removing advanced features) in the name of making sure that any dumb users who has is really looking for trouble by doing all the steps 1 to 5 and who has not read the doc would never ever need to do step 6...

[mib1185]

I think hat is such a scenario, we should not even offer the switch. Just specify in the docs why the entity is not created.

@chemelli74 Even I've some concerns left, I still think it is a reasonable use case to be able to disable the wifi on repeaters. To ensure that a user will not "shutdown its wifi-only mesh" with this, disabling these switches by default and adding a warning in the docs is the most we can do for now. Everything else (like a checkbox in the options or similar) would over-complicate things. Further tbh the scenario, that a user locks out from its wifi-only mesh is very unlikely, since it could only happen, when the user disables the physical switches on the Fritzbox, but this is done on purpose, so they most likely don't want to disable the wifi even not via HA.

[mib1185]

Maybe I found a way how to determine if the mesh uplink is LAN or WiFi based. I'll investigate further in this and adjust this PR as needed

[mib1185]

Tests done - it works on my environment as expected now

• mesh master: 7530 ax (FritzOS 8.00)
• mesh slave: 7490 (FritzOS 7.59)

Mesh with wifi backend

• no wifi switches for 7490 created

Mesh with lan backend

• wifi switches for 7490 created
• switches are disabled by default

[chemelli74]

LGTM !