As I dial in more on my app and driver - I learned something today I want to share - in case others are interested.
It seems that there is legacy about level and volume when it comes to Echo devices.
As I streamlined my GUI and operational commands for all the echo devices - I stumbled on a confusing point - setLevel vs setVolume. In the code they are tied to each other - basically two things that do the same thing. My AI research tells me that setLevel is used and part of the Standard Hubitat Compliance (whatever that might be) but in fact, at least in my testing it is no longer true.
The Difference Between Level and Volume
-
Level(SwitchLevel Capability)-
Role: Platform-generic level control (0–100%).
-
Why it exists: Hubitat uses
SwitchLevelas its universal platform standard for anything that has a percentage state (dimmers, shade position, fan speed, and audio devices). -
Primary use: Dashboard sliders, Rule Machine generic actions ("Set Level"), and third-party integrations (like Home Assistant or Apple HomeKit via Hubitat's bridge) that expect a standard
SwitchLevelcontrol.
-
-
Volume(AudioVolume / MusicPlayer Capabilities)-
Role: Domain-specific audio control (0–100%).
-
Why it exists:
AudioVolumeandMusicPlayerare specific capability interfaces designed explicitly for sound-producing devices. -
Primary use: Dedicated audio rules, voice assistant integrations, and audio-specific dashboard tiles.
-
Why Both Are Needed in This Driver
-
Rule Machine & Dashboard Compatibility If a user adds an Echo device to a Hubitat Dashboard tile configured as a Dimmer / Level slider or writes a Rule Machine automation using generic level commands, Hubitat issues
setLevel(). By keepingSwitchLevelin the driver metadata,setLevel()simply maps directly tosetVolume(), ensuring the command never fails or gets dropped. -
Attribute Synchronization When your Echo Dot or Show changes volume, the driver updates both attributes simultaneously:
Groovy
sendEvent(name: "volume", value: vol, unit: "%") sendEvent(name: "level", value: vol, unit: "%")This guarantees that whether a rule is watching
device.currentValue("volume")ordevice.currentValue("level"), both state values stay perfectly in sync. -
Platform Standards Compliance Standard Hubitat capability definitions expect
MusicPlayer/AudioVolumedrivers to exposevolume, whileSwitchLeveldrivers expectlevel. Exposing both ensures your driver works seamlessly across every built-in Hubitat app, Rule Machine trigger, and dashboard tile without requiring custom workarounds.
My logic is different. setLevel would be applicable for possibly changing the brightness on the Echo Show or Fire displays but it has nothing to do with Audio volume. I built a test driver that doesn't handle volume and wrote a rule that adjusts volume and it worked perfectly without setLevel. And a deeper test of the API on the new Amazon we learn that Echo show /FireTV brightness is hardware specific (ie; tied to the device itself) and is not programmatically adjustable as far as I can tell!
Not with the server as it currently stands.
I checked the current alexa-remote2 ecosystem and there is support for Echo device commands such as volume, play/pause, etc., but I don't see a documented alexa.sendCommand(..., "brightness", ...) capability for changing the Echo Show's display brightness. The brightness references I found are for Alexa smart-home device brightness, not the Echo Show's own screen.
So I would not add a brightness command to our server yet by guessing at an Amazon API call.
The important distinction is:
- Smart-light brightness: Alexa brightness control exists.
- Echo Show screen brightness: different device-level functionality.
- Our server: currently has no verified command for the latter.
If you want, I can specifically dig into the alexa-remote2 source/API and Amazon's internal Echo Show commands to determine whether there is a usable screen-brightness command we can add to our server.
Drat - the slider is used on the Tile in HD+. Well that just blows.