Hub variable viewer

Does someone want to write a hub variable viewer? I think it could be useful for diagnosing issues. A simple text box where we could enter the variable and then the output below.

1 Like

Isn't this what the Hub Variables page itself shows in the table? (I might be misunderstanding the request...)

That is for creating and managing variables you create. I would like one to view existing hubitat variables such as "location.hsmStatus." I'm in the process of throwing one together for my immediate need but perhaps someone already has one.

Perhaps you know the answer to this... It's the last little piece of the app I need. I'm trying to figure out the programming structure to return the value of the value. This obviously is incorrect but not sure what it should be.


maybe escape it? EG
log.debug("updatePolling: Setting up schedule with settings: schedule(\"${sched}\",refresh)")


sorry ' there was a snip problem. the code didn't like being copy pasted. let me snap shot that:

Here's a link to the file so far:

What is the value of variable1? From your example, you're looking for things like, which off the top of my head seems tricky since these are properties of the location object (part of why I was confused about the original question, too), and I'm not sure there's a way in the Hubitat environment to just evaluate arbitrary code like that.

But: there are likely a finite, and small at that, number of these objects, so the easiest solution might be to hardcode those references and then just dynamically refer to the rest:

String exp = ""
def (String obj, String prop) = exp.tokenize(".")
switch (obj) {
    case "location":
        log.debug location."$prop"
        log.debug "unknown object $obj"

I don't think that is doing what I want. Schedule is actually a command and sched is the variable with the settings for the command.

I was trying poorly to demonstrate an escaping of a variable within a variable.
Smarter people required!

TBH I was being lazy and didn't want to hardcode all the variables. I was hoping there was an easy way to go about it and was simply a syntax problem. I'm not a programmer I just pretend to know what I'm doing until it works.

1 Like

location.mode is hardcoded in this example for variable1 just to get it to return the variable so I could verify I didn't break something in the app along the way.

def variablefun() {
    variable1Output = "${location.mode}"
    variable2Output = "${variable2}"
    variable3Output = "${variable3}"
    variable4Output = "${variable4}"
    variable5Output = "${variable5}"

These are the ones I was messing with using various combinations trying things.

If that's possible to evaluate directly in the Hubitat Groovy environment, someone who knows a trick I don't will have to chime in. :smiley:

I've been known to poke around in the structures a wee bit, and may still have quick and dirty code laying around - if I can find it. At one time I wrote recursive iteration app that took the top structure and kept drilling down until it was at the last leaf node of the object. Unfortunately most of the interesting stuff are in different objects and at different levels in those objects. Quick way to start digging though is to do a .each on location and The paths to HSM mode and Mode from the Hub Information Driver:

updateAttr("currentHsmMode", location.hsmStatus)

Note that anything that is actually intended for use is documented, so there shouldn't be a need to use introspection and guess: Location Object - Hubitat Documentation

Why not just location.currentMode? (Or location.getMode() or, Groovy-equivalent-ly, location.mode.)

Maybe something fiddly with drivers. I know they are quirky at times when trying to do things like that.

Not sure how I landed there. Probably looking for something else and saw it there and probably missed it somewhere else.