Open badzz opened 4 years ago
Would this then have the effect of registering all new clusters in the 0x01
endpoint? In order to support new clusters for particular air quality sensors (#313 ), I found that registering three new clusters on that endpoint caused the application to crash during runtime, so I think I was running into a memory limitation on the cluster size. Commenting out other clusters allowed the application to successfully run.
Do you know where there is an inherent limit in the number of clusters an endpoint can support? If so, would it make sense to create an endpoint for each manufacturer specifically to support manufacturer-specific clusters and attributes only (and use endpoint 0x01
for all other clusters).
From my understanding and in order to reduce the load on the firmware, the idea is to delegate to the above layer the management of clusters. At least that is the case for ManufacturerSpecific.
Hello, For me, I have to let the livolo register :( to be ok
@fairecasoimeme are you sure that registering is enough to make it work ? eZLO_RegisterControlBridgeEndPointLivolo does not do anything special as far as I can see Other modification might have broken livolo, no ?
@fairecasoimeme , what excatly is the problem with Livolo.
I got @badzz firmware on an other matter, and did associate the Livolo without any issue. I'm able to command and to get status.
During my tests, when i deleted eZLO_RegisterControlBridgeEndPointLivolo, i could not pair my livolo. But i have to retest...
We used to register each endpoint using the same controlBridge structure. However in the zcl.c, we override to endpoint 0x01. Thus registering would just increase heap footprint with no additional benefit We will have to check in zcl_search if we want to maintain a list of endpoint in eZCL_SearchForEPIndex or just send back the index of endpoint 0x01 everytime