Device current volume

[leikoilja]

Would also be great to know the current alarm volume in either another sensor or as part of an attribute of another sensor

Originally posted by @gary-reyes in #192 (comment)

[leikoilja]

I propose instead of creating a whole new sensor we fetch the volume data and save in a "generic" device sensor that can collect all such data. We currently have timers, alarms and token sensors, but how about leaving timers and alarms as are but creating a sensor called device or smth that will hold the token and data like current volume for now. And then device-specific info can go here as we grow? :)
Thoughts, @DurgNomis-drol, @KapJI?

[KapJI]

Alarm volume is more related to alarms sensor, IMO. I'd add it there.

[leikoilja]

Oh right, I was actually getting confused between two concepts: alarm/timer volume and device volume. The alarm/timers volume defs should go into alarm/timer sensor, but do we have a way to tweak device volume like playback volume? 🤔

[gary-reyes]

The current volume also applies to timer volume.

My two cents would be to have a generic sensor to hold misc things. The few things left to implement using the local API are things like the Equalizer levels. If that's something that's ever wanted, then having them in a device sensor makes sense

[gary-reyes]

Oh right, I was actually getting confused between two concepts: alarm/timer volume and device volume. The alarm/timers volume defs should go into alarm/timer sensor, but do we have a way to tweak device volume like playback volume? 🤔

Yes. You can change the normal volume using the cast integration. I use this to change the do not disturb settings and lower volume when I go to sleep and reset when I wake up

[KapJI]

Well, if alarm volume is also applied to timers volume, let's add it to device sensor which we already have.

Device volume is a different setting as I understand it. But it should be possible to set it as well.

[leikoilja]

Exactly. So as proposed earlier we could for now just have those 'common' stuff under device sensor.

[DurgNomis-drol]

Should alarm volume just be an attribute then? And then keep tokens as state or should we move token to an attribute instead? I think volume is probably more useful 😊

[KapJI]

I think we should make token an attribute and state should be something like device available (maybe ip address)/unavailable.

[leikoilja]

Yeh i agree with the state being ip address or unavailable while both token and volume being attributed :)

[DurgNomis-drol]

But i think right now that fixing the bugs is more important.

On a side note, i am also spending sometime rewriting my card to be able to take advantage of the new features and want to catch up there before we implement more 😊

[KapJI]

Yeah, this is defininely not urgent 🙂

[kaosmagix]

Not that important indeed, but I do not like my device token to be directly visible in the automatic GUI. I also think the default status when no timers or alarms should be None or something and not Unavailable

[ArnyminerZ]

but do we have a way to tweak device volume like playback volume? 🤔

Yeah, it's done through Eureka, not tested, but seems like the correct approach, take a look at GHLAPI

There's a parameter for volume, I assume that's playback volume.

[ArnyminerZ]

The alarm volume attribute has been added to the GoogleHomeAlarmsSensor's attributes list in 31d6c29, see #250. Main volume still has to be implemented, but I don't find it correct to implement it in #250, maybe a new PR with that change should do the trick with all the generic attributes stuff you have been discussing.

[leikoilja]

Edit: I have tried asking google "what's your alarm volume" and "what's your current volume" and she replied two different values. It indeed has two separate setting for google device volume and alarm volumes.

[DurgNomis-drol]

@leikoilja yes it does indeed. I believe there is some info about it in here