Currently the usecase implementations code in the events.go files trigger bindings, subscriptions and reads (e.g. in eg/lpc/ ) when a specific feature in that entity is found ignoring if the full set of required features is available or even if the usecase is reported to be supported in this enttiy.
This leads to bindings, subscriptions, reads to be triggerd e.g. from en LPC energy guard implementation to another devices LPC energy guard implementations.
We should rework this initial process to make sure it only runs on compatible entities by also knowing the usecase is reported to be supported. But issue on that will be, that the usecase information may not contain the entity address at all (previous to 1.3 or due to bugs), contain the parent entity address (which is allowed by the spec) or the device.
We could use IsScenarioAvailableAtEntity to check if the required server features are available, which would help differentiate client and server usecase implementations already.
Currently the usecase implementations code in the
events.gofiles trigger bindings, subscriptions and reads (e.g. ineg/lpc/) when a specific feature in that entity is found ignoring if the full set of required features is available or even if the usecase is reported to be supported in this enttiy.This leads to bindings, subscriptions, reads to be triggerd e.g. from en LPC energy guard implementation to another devices LPC energy guard implementations.
We should rework this initial process to make sure it only runs on compatible entities by also knowing the usecase is reported to be supported. But issue on that will be, that the usecase information may not contain the entity address at all (previous to 1.3 or due to bugs), contain the parent entity address (which is allowed by the spec) or the device.
We could use
IsScenarioAvailableAtEntityto check if the required server features are available, which would help differentiate client and server usecase implementations already.