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 c6b836f |
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()`.
Change data type to Double.
Change data type to Double.
Fix description
Fix range and description
For IKEA INSPELNING smart plug, that actually changes the divisor based on the measured power.
Change data type to Double.
Change data type to Double.
Change data type to Double.
Fix range and description
Change data type to Double.
Add RStatePowerDivisor
Add RStatePowerDivisor; Change data type to Double for: - RStateCurrent and variants; - RStatePressure and bis; - RStatePower; - RStateVoltage.
Fix validation error.
|
I resolved conflicts and validation errors after recent merges of other PRs. And I double-checked that this PR still compiles. |
Don't introduce `state/reachable` to `sensors` resources.
Update CLIP sensors to use Double values as well for updated items.
This seems to break rules evaluation with `gt` or `lt` conditions on the real items.
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.Change the data type to Double for the following items:Canceled for now, as this breaks the evaluation ofgtandltrule conditions on these items.state/consumptionand variants;state/currentand variants;state/power;state/pressureand bis;state/voltage.state/power_divisorfor the IKEA INSPELNING (see IKEA INSPELNING Smart Plug with kWh meter #7948). Note that this needs to be defined in C++ for it to be used in expressions in the DDF.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;cap/otau/...;cap/alerts,state/alert,config/alert: in theory these could be per endpoint (with Identify cluster);state/reachableandconfig/reachable.