New radio API #848
New radio API #848
Conversation
|
Should we have an API for setting the manufacturer id ib the node descriptor? EZSP protocol has a command for it. ConBee serial protocol just added a command for it and ZNP would release (unless it already happened) a modification to firmware to allow setting the mfg id. Right now the only unknown if it should be set permanently or dynamically. Thoughts? @dmulcahey for visibility |
|
Sure, I don't see why not. The deCONZ serial spec doesn't say what part of the node descriptor response is configurable so maybe it would allow zigpy to respond with the whole thing?
It's baked into the firmware, unfortunately: https://github.com/Koenkk/Z-Stack-firmware/blob/62692f2c3d06054eaa3a263ecda0b573fe60223e/coordinator/Z-Stack_3.x.0/firmware.patch#L525 |
should we make this an option in the UI in HA? Documented Flow could be something like:
Or should we look for a way to make this dynamic similar to what Z2M did In the TI firmware so that users don't have to deal with it at all... |
|
Need to try what does setting the mfg id to 0x0000 on ezsp do. Does it actually sets to all zeroes or resets to the standard one. |
Are there any other devices like these Aqara sensors? Seems like an awfully specialized user-facing setting.
What happens if we globally set an Aqara manufacturer ID on startup and never change it back to the stack default? |
I think it’s all E series Aqara sensors. I’m not sure what happens if we leave it… |
|
I think i have reading that some other device need having replay with there manufacture number for some requests for working OK but i dont remember winch device it was (I think it was in deCONZ form). |
|
This is what Deconz does. I guess they leave it up to the application to send the response? |
|
How do you feel about moving probing and the bellows baudrate override into ZHA? RADIO_PROBE_CONFIGS = {
bellows.zigbee.ControllerApplication: [{}, {zigpy.config.CONF_DEVICE_BAUDRATE: 115200}],
zigpy_deconz.zigbee.ControllerApplication: [{}],
zigpy_znp.zigbee.ControllerApplication: [{}],
zigpy_zigate.zigbee.ControllerApplication: [{}],
zigpy_xbee.zigbee.ControllerApplication: [{}],
}
async def find_compatible_radio(path: pathlib.Path | str) -> tuple[
zigpy.application.ControllerApplication, ConfigType
]:
for radio, overrides in RADIO_PROBE_CONFIGS.items():
for override in overrides:
config = {zigpy.config.CONF_DEVICE_PATH: str(path), **override}
radio = ControllerApplication(config)
try:
await radio.connect()
except Exception:
LOGGER.debug("Failed to probe %s with %s", config, radio, exc_info=True)
else:
return radio, config
finally:
await radio.disconnect()
else:
raise ValueError("Failed to find compatible radio module for %s", path) |
I don't have strong preference, the idea was that the "radio lib" would have specific knowledge to auto detect settings were applicable and then in this case should return the config back to ZHA. in other words ZHA is not supposed to know all possible radio configs, current of the future. The radio lib may poses that knowledge. |
|
That makes sense. My main goal was to remove unnecessary duplication between the radio libraries (all of them just connect/disconnect with the exception of bellows) so I guess something like this would work too as an override in the radio library: @classmethod
async def probe(cls, device_config):
result = await super().probe(device_config)
if result:
return result
return await super().probe({**device_config, CONF_DEVICE_BAUDRATE: 115200})On the other hand, each radio library may have different probe timeouts (e.g. ZNP's startup time is a lot longer than bellows) so maybe it's best to just leave it alone. |
Codecov Report
@@ Coverage Diff @@
## dev #848 +/- ##
==========================================
- Coverage 99.75% 99.62% -0.13%
==========================================
Files 45 45
Lines 6802 6951 +149
==========================================
+ Hits 6785 6925 +140
- Misses 17 26 +9
Continue to review full report at Codecov.
|
puddly
force-pushed
the
puddly/new-radio-settings-api
branch
from
b350c32
to
16fcaf2
Compare
If I can share what Zigate is doing, and that was a surprise when I saw 0000 when using the first ZNP one. Zigate is set to 0x1147. The best would be indeed to be able to set the manufacture code on the fly via an API. I would imagine to do it when receiving an handle_join() then I would set the manufacturer to whatever is needed so at the time the device query it, it will get what I put. |
puddly
force-pushed
the
puddly/new-radio-settings-api
branch
2 times, most recently
from
358e5ad
to
75f494e
Compare
|
Any plan or targeted date when it will be released ? |
FYI, puddy's GitHub project (kanban board) under zigpy org with progress overview -> https://github.com/orgs/zigpy/projects/2 Originally posted by @puddly in zigpy/zigpy-zigate#117 (comment)
|
There was a problem hiding this comment.
@puddly, while I understand Endpoint 0x01, what is the purpose of Ep: 0x02 ?
await self.add_endpoint(
zdo_types.SimpleDescriptor(
endpoint=2,
profile=zigpy.profiles.zll.PROFILE_ID,
device_type=zigpy.profiles.zll.DeviceType.CONTROLLER,
device_version=0b0000,
input_clusters=[zigpy.zcl.clusters.general.Basic.cluster_id],
output_clusters=[],
)
|
Alright, this PR is about as ready as it will ever be. Any final thoughts before I merge this and the corresponding PRs in all of the other radio libraries? |
|
Let's go!
|
|
I just did a re-run of my new-radio-API test bed updating it with your own repository and at least it is still working. I do hope that a number of issues that we have on the legacy API will be solved, and the features that we are looking for deConz are available Happy to test on the upstream dev branch |
|
For what its worth: I just instelled zigpy, zigpy-znp and bellows from the new radio settings branches:
This might be a psychogical thing or maybe it is due to the fact that the network was offline for 30m but I feel like the network is more responsive and reliable |
This is a WIP implementation of #842. Database changes will come in a future PR.
Since we're going to have to edit every radio library to accommodate these changes anyways, I've renamed
pre_shutdowntoshutdownand also shortenedNetworkInformationtoNetworkInfo(and the associated state attributes). The rest of the changes more or less match what's in the linked RFC issue.