gaetancollaud / digitalstrom-mqtt

Bridge between digitalSTROM and MQTT
GNU Affero General Public License v3.0
24 stars 4 forks source link

config option to enable scene calls to mqtt #12

Closed holli73 closed 3 years ago

holli73 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

image

thanks holli

gaetancollaud commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

So I had another look at the API.

Ex of renamed scenes: Screenshot from 2021-05-31 21-13-54

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: Screenshot from 2021-05-31 21-15-40

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 commented 3 years ago

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. image 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 commented 3 years ago

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. Screenshot from 2021-06-01 20-51-53 Screenshot from 2021-06-01 20-54-08

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

gaetancollaud commented 3 years ago

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

holli73 commented 3 years ago

@gaetancollaud - thanks a lot