Closed Nerivec closed 6 days ago
Some quick (i.e. imprecise) performance tests (x1000000):
BuffaloZcl | Before | After | Change |
---|---|---|---|
read uint8 | ~270ms | ~200ms | -25% |
write uint8 | ~190ms | ~130ms | -31% |
read array | ~680ms | ~350ms | -48% |
write array | ~750ms | ~300ms | -60% |
read enum8 | ~290ms | ~200ms | -31% |
write enum8 | ~220ms | ~130ms | -40% |
read buffer | ~310ms | ~310ms | - |
write buffer | ~530ms | ~340ms | -35% |
DataType
(long overdue) and added some comments for good measureBuffalo
andBuffaloZcl
so they no longer have traces of zstack-specific logic.Buffalo
deals with base types and holds the generic functions.BuffaloZcl
adds support for Zcl-specific types.read
/write
toBuffaloZcl
with tests.read
/write
.options
-dependent and "non-value"read
/write
and tests to go with it.write
are still missing "non-value" support, impossible because of current implementations. Requires refactoring.BuffaloZcl
support and tests.TODO:
LONG_OCTET_STR
was previously using the sameread
/write
asLONG_CHAR_STR
, changed tonumber[]
/Buffer
. Need to check on the 2 use cases:Clusters.liXeePrivate.attributes.daysProfileCurrentCalendar
Clusters.liXeePrivate.attributes.daysProfileNextCalendar
read
/write
fromBuffaloZcl
toBuffalo
. Should probably be in another PR, will affect more than the Zcl definition.NOTE: zigate missing
ParameterType
values were added arbitrarily to allow compiling. It seems to also be missing types support. Code looks broken overall.