Refactor lightToMap() and sensorToMap()
#7979
Conversation
ZclFrame.at(0) is status.
- Description - Image Notify payload.
- Description
- Description
Set framecontrol for _Image Notify_.
Add support for Hue Lightguide E27 Edison ST72, see dresden-elektronik#7969.
Add support for LOM001, see dresden-elektronik#7968.
Set items not to be shown in API as non-public.
Return the (sub-)map and key where the value needs to be inserted, creating any intermediate sub-maps where needed.
Refector `lightToMap()`.
Refactor `sensorToMap()`
|
Hey @ebaauw, thanks for your pull request! Tip Modified bundles can be downloaded here. DDB changesModified
ValidationTip Everything is fine ! 🦆 Updated for commit 4b10c22 |
ebaauw
changed the title
lightToMap() and semsorToMap()lightToMap() and sensorToMap()
- Include top-level key in `ApiAttribute`; - Optional `event` parameter to use separate `attr` submap.
- Optional `event` parameter to handle web socket notifications; - `LightNode *` parameter is no longer `const`, since the `needPushChange` property of the underlying resource items will be cleared.
Leverage `lightToMap()` in `handleLightEvent()`.
- Optional `event` parameter to handle web socket notifications; - `Sensor *` parameter is no longer `const`, since the `needPushChange` property of the underlying resource items will be cleared.
This PR refactors the construction of the API responses to GET
/lights and GET/sensorsand of web socket notifications for/lightsand/sensors`. It builds on #7961, which should be merged first.Changes
This PR makes the following changes:
attr/id;attr/otaversion;cap/bri/move_with_onoff;cap/on/off_with_effect;config/bri/options.ResourceItemDescriptor::toApi(), which returns a pointer to the (sub-)map and the key where the value of the corresponding item should be inserted in the API response map. Any intermediate sub-maps are created where needed. It returns a small helper classApiAttributecontaining a QVariantMap pointer (to the sub-map) and two QString (for the key and top-level key).lightsToMap()andsensorsToMap():toVariant(). The entire multi-level map structure is now built dynamically. This leaves only two types of whitelisted resource items:config/on/startup, that's either a boolean or"default");state/xy, built fromstate/xandstate/y).lightsorsensorsresource items are processed, so these might override the parent values. In practice, this causes the following additional keys in the API response:attr/ddf_hash,attr/ddf_policy,attr/extaddress,attr/nwkaddress,cap/sleeper, and (for/sensors)state/reachable. Note that non-Zigbeesensorsdon't have a parent device.ApiModeHue). Afaik the Hue app hasn't been working with deCONZ for a long time anyway, and there are alternatives, like Hue Essentials./devices. Currently they aren't, and the hook would be obsolete once we move those items from the sub-devices to the device.needPushChangelogic to support web socket notifications.handleLightEvent()to leveragelightToMap().handleSensorEvent()to leveragesensorToMap().QLatin1Stringinstances.Discussion
/devices? Would we want a single notification on the device level, or a separate notifications on each sub device? In the latter case, I think we would need "slave" resource items on the sub-devices to keep track of what's already been notified.config/reachable(for/sensors) in favour ofstate/reachable? Same forconfig/alert?Next Steps
attr/lastannouced,attr/lastseen;attr/otau/...(orcap/otau/...);cap/alerts,state/alert,config/alert: in theory these could be per endpoint (with Identify cluster)