config option to enable scene calls to mqtt

[holli73]

as requested here is the topic. it would be cool - if through the config the received scene calls are published as well. why? i use vdcd/vdsm and have apx. 100 lights connected to dss (using deconz) once the switch is pushed it takes apx. 2 seconds till the vdcd receives the call and then my shell script/interface will trigger the needed scene call on deconz (f.ex. for important lights i already put yellow devices in place and stored the default power on light settings (color temp/brightness) but this has the limitation that i takes some time till connected and further light options can be send (f.ex. different brightness because of day/night/evening,..)... on my deconz groups i use scene's as well - f.ex. dss stimmung1 for room kitchen fits deconz lightgroup kitchen scene Stimmung1 - so it would be super easy to place the calls from the mqtt to deconz - just need to make the mappings and would not need to use the yellow GE-KM200 (i will still have them in place for resetting and admin but not for controlling)

hope this makes sense thanks holli

[gaetancollaud]

So, this software trying to get rid of the scene by targeting devices directly. But I can understand that he can be useful for you.

The event API gives scene number, but I guess it's not really what you want. How do you see the topics ?

Easy things for me is just having one digitalstrom/scene/id and publish the scene number, but I guess it's not enough for you? Do you put names on your scene?

[holli73]

for me it would be enough to get f.ex.:

2021-05-31T11:13:33+02:00 INF Event received, updating devices SceneId=5 ZoneId=16797
2021-05-31T11:13:36+02:00 INF Event received, updating devices SceneId=17 ZoneId=16797
2021-05-31T11:13:38+02:00 INF Event received, updating devices SceneId=18 ZoneId=16797
2021-05-31T11:13:42+02:00 INF Event received, updating devices SceneId=19 ZoneId=16797
2021-05-31T11:13:44+02:00 INF Event received, updating devices SceneId=0 ZoneId=16797

this would be

/digitalstrom/scene/id  - zoneid
/digitalstrom/scene/5 16797

i tried some rooms and 5 = stimmung1 / 17 = stimmung2 / 18=stimmung3 / 19=stimmung4 / 0 = off i would perform the mapping of sceneId / zoneid on my end no need to have it on the mqtt as i do have already mappings for zoneId

thanks holli

[gaetancollaud]

I honestly don't feel comfortable using ids. I would rather use the zone name and scene name (if possible). And maybe have the zone before the scene. Something like:

digitalstrom/scene/{zone_name}/{scene_name}
digitalstrom/scene/zimmer1/stimmung1

But I have to check if we have a way to find the zone name and scene name. I will have a look at the API again.

[holli73]

hello,

i would call this as nice to have - for a quick (dirty) solution - if already printed to dbg and just place it on the mqtt would be fine for me - but for sure having naming would make it more readable - but if this will cost additional calls to dss - you might add delays again by just firing.

the goal should be to get the events as fast as possible - so i can call my actions on needed devices.

by having the zoneid as the topic and the called scene as value is fine to me as well - as i would anyway have '#' on listening for these events and must make all logical decisions within my app

hope this makes sense thanks holli

[gaetancollaud]

So I had another look at the API.

• It's possible to get zone name easily
• It's possible to get custom scene names easily (but I guess no one renames the scene anyway...)
• It's hard/impossible to get the default scene name.

Ex of renamed scenes:

So I tried to do something as mentioned above. But I wanted to follow the topic format. So the final topic is something like this:

digitalstrom/scenes/{zone_name}/{scene_id}/event

Result:

I'm not happy with the result. It looks half-finished. Also, I'm not sure what to put in the body. For now, I repeat the info that I have.

I created a branch feature/scene-events with the commit e84cf09f9ea500991a7031faa31eb3ae637619d9

[holli73]

hello,

i just got the branch up and running - and it is super responsive - i had a tail running on the vdcd and the std out of the go session and there is apx. a delay of 2 seconds on the vdcd interface to your's - very cool so this is what i would expect (my wife) when hitting a wall switch to get the lights on...

as i will listen to any of this events anyway - maybe it would be better to have just the topic for the scene event and all details within the message?

[/dssip/scenes/og-wohnzimmer/0/event : msg.payload : string[55]
"{"ZoneId":16844,"ZoneName":"og-wohnzimmer","SceneId":0}" 
vs
/dssip/scenes/event : msg.payload : string[55]
"{"ZoneId":16844,"ZoneName":"og-wohnzimmer","SceneId":0}"]

as a mapping must be done anyway - so we only have the data once and the json can be parsed easily

thanks holli

PS: i just created a simple flow - based on the event data - convert the json to js.object and use switches to decided what to do. it is easy to implement and looks verry redable the first switch is secenid 0/... and the next is based on zonename - this is all i would need

[gaetancollaud]

Glad that it solves an issue for you. I updated it a bit. I know put the scene name on the topic (if provided, otherwise I fallback to the id). I also added the groupId and group name in the payload (not sure if useful). See screenshots below.

But for you, it will not change anything since you're using only the payload anyway.

[gaetancollaud]

I have done a release with the fix for this issue. I will close it if it's ok for you @holli73

[holli73]

@gaetancollaud - thanks a lot