16340-taking into account group and active scenes to getReachableScenes

A basic implementation that now reachable scenes are connected to group and its behavior(based on applicationType).

@mtross please check if the scenesPerButtonId are valid for both default and ventilation behavior. Also still scenes in buttonId 15 and for black devices are interesting.

Closes #16340

added 2 commits

• c016ade2 - moved the getSceneName from event plugin to scene helper
• 1e40ac44 - updated the getReachable scenes method to return also names of the

Compare with previous version

Adding the names to the scenes is not really final - I reused the getSceneName from eventinterpretersystemplugin but the names are a little bit weird there. Please let me know if the names should be generic or group specific (for temperature and ventilation they will have different values and it makes requests only to zone more difficult - one scene number can have 2 names).

I think it's correct to return different scene names depending on the groupId (application type). But as you said, some names are a bit weird...

added 21 commits

• 1e40ac44...96175088 - 20 commits from branch dss:master
• 0fbd1781 - updated getReachableScenes for new groups, add scene names

Compare with previous version

Rebased, reworked and squashed. Please take a look at current implementation:

1. it uses different reachable scene tales for normal groups, ventilation, joker and temperature control
2. it checks if the scene is active based on selected application type
3. it returns names of the scene depending on current group (for temperature and ventilation names are redefined)
4. it returns custom scene name if it is provided

I have change the C-style arrays for static const std::map to make it easier to manage the mappings, but this have of course runtime performance impact.

Still WIP because I do not know if the buttonID-group-scene mappings are valid.

@mtross @brano what do you think about this?

added 1 commit

• 05842da4 - getReachableScenes update

Compare with previous version

Please, verify that this compiles on oe-core. I experienced problems with some forms of {} initialization. But I don't really know what works and what not.

I think that the variable reachableScenes is redundant. You can create reachableScenes json output from reachableScenesWithNames.

the problem is that in case this call is executed without group id - so get reachable scenes for all groups in the zone then we can have one id with multiple strings (depending if group ventilation or Joker will be there). then we cannot directly use the reachableScenesWithNames there because it will contain repetitions and we will need to have local vector and run unique on it so it will be the same..

I am open to suggestions but I did not find a viable alternative..

So you care about being able to return more scene names for the same sceneId?

@mtr Please confirm this public api extension, you asked for it in the ticket. Looks good to me, but I did not check for consistency with other parts.

added 1 commit

• 8ee5c4cf - small review fixes

Compare with previous version

+1 review

added 1 commit

• 590af865 - send only user defined scene names in response of getReachableScenes

Compare with previous version

added 17 commits

• 590af865...b2dcaa11 - 16 commits from branch dss:master
• b0a39257 - updated getReachableScenes for new groups, add scene names

Compare with previous version

Rebased, squashed and updated the getReachableScenes to require the group id as parameter. Current response looks like this:

{"result":{"reachableScenes":[0,5,17,18,19],"userSceneNames":[{"sceneNr":5,"sceneName":"light 1"}]},"ok":true}

the scene names are only displayed in case user name is assigned.

unmarked as a Work In Progress

Build finished. Tests FAILED. Build results available at: http://dsjenkins.cloudapp.net/jenkins/job/dSS_MR/891/

+1 lgtm, verified on my pc build