dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 502 forks source link

Refactor `lightToMap()` and `sensorToMap()` #7979

Open ebaauw opened 1 week ago

ebaauw commented 1 week ago

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:

Discussion

Next Steps

github-actions[bot] commented 1 week ago

Hey @ebaauw, thanks for your pull request!

[!TIP] Modified bundles can be downloaded here. Relative expire date

DDB changes

Modified

Validation

[!TIP] Everything is fine !

:clock6: Updated for commit 281aea717a9c48046a7f032589f3447ec7d1ec9c

manup commented 3 days ago

Thanks a lot for the PR. From a first coarse look the direction where this goes is pretty good. I don't understand every detail yet and need to dig deeper, but if we can build outgoing API data with less item/device specific C++ code that's wonderful.

Ideally using logic and structure from the dynamic objects which are described in DDF items. Looking at the PR and toApi() function the JSON files describing DDF items could be extended in future:

Complex "virtual" items: like state/xy could be described right in the DDF item JSON file as expression:

{
  "schema": "resourceitem1.schema.json",
  "id": "state/xy",
  "datatype": "Array",
  "to_api_expr": "[ R.item('state/x').val, R.item('state/y').val ];" 
}

Where the default only returns .val of the current item.

A handler of these would further reduce the needPushChange() and clearNeedPush() calls. The implicit task that state/xy depends on state/x and state/y and should be pushed if one of those is "dirty" could be handled automatically without extra noise in JSON description.