Dashboard - level vertical tile not working with SwitchLevel device

[samburner3]

I have a custom device with a SwitchLevel state:

The most relevant title I could find for the dashboard is Level Vertical.
It is displayed as a slider with %.
However it is not working as expected. Changing the slider works and updates the device state, however when the device is changed (via device directly) the slider won't update.

I did some digging, in Settings > advanced > devices > (my device with SwitchLevel state)
It shows under current states as switch:off.

Should this not be SwitchLevel : 22 ??
It should reflect the device's status/attributes right??

Maybe this is why the slider is not receiving a switchLevel / % as it is only receiving switch: boolean.

I wrote the driver for this device myself. I think I have everything correct as its showing on the device page as expected.

[Inge_Jones]

How did you get the Tile Builder tab? I don't have that there.

[TechMedX]

yeah I don't have a lot of that on mine. Is that C-7? I gotta open that box lol, but moving all my devices

[Inge_Jones]

I have C7 but still don't have the Tile Builder tab on that screen

[neonturbo]

@samburner3

Level Vertical

I always thought that was an indicator tile rather than a tile you can set. I use it for my propane tank level for example.

[bertabcd1234]

@samburner3

SwitchLevel state:

SwitchLevel is not a standard attribute. SwitchLevel is a standard capability (see: capability docs), with a required level attribute. That is the attribute that the "Level" and "Level Vertical" Dashboard templates will display (and via the also-required-for-this-capability setLevel() command also manipulate when changed). Did you intend to use level in your driver instead?

Perhaps you already know the above and are using a custom attribute intentionally. In that case, no standard Dashboard tile template will work with this attribute for manipulation (at least not without workarounds--like a button that sends the appropriate commands). However, you can still make it display the current value with the "Attribute" template, providing the name of this custom attribute when asked.

[samburner3]

Yes I want level to be changed / reflected. I understand now SwitchLevel is a standard capability with a level attribute.
I am using setLevel on change. I do want to use level yes, not sure about the relationship between the two as there is limited documentation, this is my first driver. Help would be appreciated.

I will post my relevant code below:

metadata {
definition(
    name: "Rpi LightMessage", 
    namespace: "community", 
    author: "Sam Turner", 
    description: "Control the led matrix"
) {
    capability "SwitchLevel"
}
preferences {
    input name: "mqttBroker", type: "text", title: "MQTT broker IP:Port", required: true
    input name: "mqttClientID", type: "text", title: "MQTT Client ID", required: true
    input name: "logEnable", type: "bool", title: "Enable debug logging", defaultValue: true
}
}

And the setLevel code:

def setLevel(level,duration=null) {
//if (logEnable) 
log.debug "Sending MQTT request to ${settings.mqttClientID} ${level}"
try {
    interfaces.mqtt.publish("samBedroomWallSign/brightness", "${level}")
    sendEvent(name: "SwitchLevel", value: level, isStateChange: true)
} catch (Exception e) {
    log.warn "Call to setLevel failed: ${e.message}"
}
}

[samburner3]

Ok I was able to resolve by changing

sendEvent(name: "SwitchLevel", value: level, isStateChange: true)

to

sendEvent(name: "level", value: level, isStateChange: true)

SendEvent is not documented; Additional to be documented so I had no idea it could be a custom string, thought it had to be tied to the capability.

Is sendEvent the standard way to update the state of devices? If so, it's surprising this core function is not documented.

[bertabcd1234]

@samburner3

sendEvent(name: "SwitchLevel"

"SwitchLevel" here should be "level". The name parameter in sendEvent is the name of the attribute you are generating an event for. Generating events is (more or less; you do have some control over whether it actually counts as an event) is how attribute valúes are changed. Aside from declaration in the metadata, the capability name doesn't matter--just the attributes and commands the capability requires.

[samburner3]

Thanks @bertabcd1234 for above.

Next problem involving switchLevel:
A device with switchLevel as the only capability won't show up under Authorize {app} to access your Hubitat Devices:

    ) {
    capability "SwitchLevel"
    
    attribute "level", "number"
}

However if I add switch as a capability, it shows up.

    ) {
    capability "SwitchLevel"
    capability "Switch"
    
    attribute "level", "number"
}

So how do I add a device that only has the SwitchLevel capability? As the only control I want my sign to do is dimming.

[bertabcd1234]

I can't speak to how the SharpTools device selector works, but from your screenshots, it appears that it's looking for devices that implement "Switch" and not (only) "SwitchLevel." Capabilities are the most common method by which apps prompt users to select devices (to ensure you're choosing a device appropriate for the task at hand, like a motion sensor for a motion-lighting app). If SharpTools only specifically allows "Switch," it's likely because nearly any device that implements "SwitchLevel" also implements "Switch" (presumably the most common application of this is a dimmer switch or dimmable smart bulb: on/off control from Switch, plus level control from SwitchLevel), a design choice on their part.

Have you tried capability "Actuator" to see if that shows up anywhere in this selector? (This capability is kind of a catch-all that requires no attributes or commands but generally is something "implemented" by any device that can receive commands. Some apps further use it as a last-resort device-selection mechanism.) If you really need to, you could implement "Switch" and just implement dummy/stub "on"/"off" methods (and set the "switch" attribute to something), though perhaps another capability would make it show up somewhere here. But again, I can't really speak to what specific capabilities the various selectors are looking for here.

PS -

@samburner3

attribute "level", "number"

You only need to declare custom attributes, i.e., ones that are not part of a "standard" capability you are implementing, so you could leave this line out. In my experience, Hubitat is graceful about ignoring (or otherwise handling) the re-declaration of an attribute that is already there, but it's still less typing.

[josh]

@bertabcd1234 nailed it on everything.

The reasoning that nearly every device that implements SwitchLevel also implements Switch is spot on. Otherwise showing a separate SwitchLevel section in the authorizations would result in duplicates for most people.

Side note: If your device driver has the ability to set the level to 0, you could map that to off and anything above 0 to on. Similarly, an off() command could map to a setLevel(0) and if you wanted to get fancy, you could store the last level in state and when you send an on() command, you could restore that state eg. setLevel(previousLevel)

The SharpTools web based authorization flow presents the core list of capabilities (Switch, Contact, MotionSensor, Lock, etc). You can also manually authorize devices which implement either of the Actuator or Sensor generic capabilities.

How to Authorize Unrecognized Things - SharpTools

[rdstov]

Any Answer on the "Tile Builder" Option, i cannot seem to find any such plugin or option. I have the C7 as well.