Support for more than 8 components with Zigbee nRF52

[Viproz]

Describe your idea

Hey, I was a bit frustrated with the maximum 8 components supported per zigbee device on nrf52 so I dug a bit deeper.
Currently this limitation comes from two things:

1. The library we use only allows 8 endpoints per device
2. We only use one cluster per endpoint.

Point 1 is a limit that cannot be changed. Point 2 comes from the fact that we use standard clusters definition (like 0x000F = "binary input cluster" for binary sensors and so on), so we could in theory mix components types in a cluster but we would still only be able to put 8 of each component type per device.

How about we create a custom external converter that takes advantage of the manufacturer range of clusters (0xFC00 -> 0xFFFF = 1024 values) where we would define that 0xFC00 -> 0xFC0F is for binary sensors, 0xFC10 -> 0xFC1F is for sensors (analog input) and so on?

This would require manufacturer (always "esphome" currently) and model (currently friendly name of device) to be constant.

Why is this exciting?

No more hard limits on nRF52 zigbee devices! 8*16 = 128 components per devices would be possible.

Additionally support for other component types would become easier to implement as we could move away from standard cluster IDs

Potential use cases

Low power device returning lots of data of the same type (LinkyTIC for example)

Anything else?

Is this a direction you would be interested in going?
I am currently trying to do a proof of concept using AI but I may not be able to provide robust enough code for final implementation.

[tomaszduda23]

Point 1 - it is possible to get access to source code if someone willing pay fee. It was couple of k$. And it would not be certified anymore.

we could in theory mix components types in a cluster but we would still only be able to put 8 of each component type per device.

This is something that I considered but to simplify implementation it was not done. Feel free to prepare PR :)

How about we create a custom external converter that takes advantage of the manufacturer range of clusters (0xFC00 -> 0xFFFF = 1024 values) where we would define that 0xFC00 -> 0xFC0F is for binary sensors, 0xFC10 -> 0xFC1F is for sensors (analog input) and so on?

That would required changes in zha and z2m to make it user friendly. It is possible but first I would reuse endpoints.

This would require manufacturer (always "esphome" currently) and model (currently friendly name of device) to be constant.

@luar123 we discussed this before and consensus to not relay on that.

[luar123]

Fully agree, once the new zigbee stack is implemented I want to implement the endpoint merging for esp32. Additionally, I want to allow to optionally use the default clusters (temperature, pressure, etc) with the drawback of not having name support. Both will decrease the number of endpoints needed, but of course won't help for nrf52 or if you need 20 switches. So for now (soon), better use esp32 if you have very big configs.

There might be another limitation: bind table size
Typically, each cluster that needs to report changes to the coordinator (e.g. sensors) needs to be bound. Is this configurable for nrf52? For esp32 it is.

For mid/long term: I would like to add some custom implementations like name support for default clusters or an esphome cluster with additional information. However, I did not look into how these could be implemented in ZHA/Z2M, because they should not rely on manufacturer/model id (maybe on manufacturer code, not sure if OHF could get one from CSA).