awesome-ha-blueprints icon indicating copy to clipboard operation
awesome-ha-blueprints copied to clipboard

Enhancement - Use Brightness Value From Symonfisk Payload Directly to control Volume/Brightness

Open stquinn opened this issue 2 years ago • 3 comments

Blueprint name

Controller - IKEA E1744 SYMFONISK Rotary Remote

Description

Hi, I have been using your automations and they are great - thanks for the work @EPMatt 👍

When I use the symonfisk rotary remote - I am struggling to get a nice smooth volume action. Now I know most of my issue is probably the fact that I am dealing with latency as the media player I am using is spotify and so there are several hops which I think are affecting my smoothness: remote->zigbee2mqtt->home assistant->spotify->speaker

However there is one feature of this remote which I think could help my use case as well as others.

When you use this device with zigbee2MQTT there is a brightness value published. So as you spin the dial - zigbee2mqtt is creating a brightness value to represent the current position.

The brightness value is part of the mqtt payload and its value is between between 0-255.
So this would give an exact representation of the brightness/volume rather than the looping, catching events and sometimes missed interactions.

The mqtt payload looks like:

{
  "action" : "",
  "battery" : 74,
  "brightness" : 15,  //BRIGHTNESS VALUE HERE
  "last_seen" : "2021-11-10T09:39:06.242Z",
  "linkquality" : 115,
  "rate" : 195,
  "update" : {
    "state" : "idle"
  },
  "update_available" : false
}

It might be nice to expose and use this as it might give a more exact representation of the current volume.

So every-time the remote posts a new event to mqtt - you have the actual representation of the brightness value as presented by physical position of the remote - rather than catching events and looping them.

Automation YAML config

No response

Implementation

No response

Additional Details

  • [x] I'd like to help developing this feature/improvement.

Useful resources

No response

Additional context

No response

stquinn avatar Nov 10 '21 10:11 stquinn

Hi @stquinn,

thank you so much for your suggestion! Using such information might be useful for improving the responsiveness and usability of such controller. Do you know whether the brightness value is exposed also with ZHA and deCONZ?

We should also be aware that lights / media players might be updated by other agents different from the controller itself. Therefore the brightness value reported by the controller might not always be synced with the actual brightness/volume setting of the device associated via e.g. a hook automation.

Thanks!

EPMatt avatar Nov 19 '21 11:11 EPMatt

@EPMatt I dont have access ot either ZHA or deCONZ so do not know. I have a feeling it might be zigbee2MQTT specific.

We should also be aware that lights / media players might be updated by other agents different from the controller itself. Therefore the brightness value reported by the controller might not always be synced with the actual brightness/volume setting of the device associated via e.g. a hook automation.

Yeah that is a fair point. I guess in many/most cases the User would be controlling the volume by one means at a time - rather than controlling the volume in multiple different mechanisms at the same time - even though it is of course possible.

So if we were going to do something like this then it would need to be used in conjunction with a rotation action, before we could apply the brightness value. The rotation would be the signal that the user meant to manipulate the brightness/volume with this controller. You couldn't just apply the value every time it was reported with a different action as you would have no idea if the User actually meant to manipulate the volume and thus interfere with whatever value was set using the alternate mechanism.

stquinn avatar Nov 24 '21 16:11 stquinn

Using a Symfonisk is probably just an option, because you can use the hardware buttons of the speaker, music or speaker apps or Alexa/Hey Google. W/o being able to initially (on start of rotation) set a reference starting value (taken from the actual speaker volume at that point), I don't think this is really helpful. Too much "danger" of starting with 255 when switching the speaker on when people played with the knob while music was still off.

habitoti avatar Jun 09 '22 13:06 habitoti