API request

I would like to be able to display a status icon in the DEVICES state column without any associated data.

This, hopefully simple, feature might possibly be accomplished by adding a few keywords to the icon selection table (bottom of the API v1.11 release notes). Something like onnp, offnp, activenp, inactivenp, etc. (where np might mean no print). Or, perhaps an option to updateStateOnServer() like:

device.updateStateOnServer(key='state', value=0 displayData=False)

This feature would allow visual state display without the, often meaningless, associated data. For example, a plugin might alternately turn on and off a green dot each time a power sensor pulsed. Or, a simple red or green dot might signify the state of a lock. I can do the pulse now, but it ends up displaying a 1 or 0 (or true or false) along with the gray/green dot.

Thanks for considering this.

EDIT: BTW, I tried using uiValue to quash the display, but it didn't work. Oddly, with value=1, uiValue=' ', I get no display at all. value=0, uiValue=' ' displays the gray dot, and the 0. I also tried None and '' (the empty string) as values for uiValue, but they were all simply ignored. All of this is on Indigo 6.0.2

[matt (support)]

The API change you outlined isn't quite the approach we want to take, but I'll add to our feature request list a couple of items: 1) ability for a plugin to have a device provide some type of real time animation signal/flash (for your pulse example), 2) additional icons (lock/unlock) for boolean device states.

Thanks for the feature request.

The API change you outlined isn't quite the approach we want to take...

Yeah, I knew that from the previous discussion on this general topic. I was just hoping that while you work on a more generalized solution, this (hopefully minor) change might solve the need for the short term.

[jay (support)]

BTW, you probably always want a reasonable text description of the state for a couple of reasons:

• Visually impaired people will be using accessibility to read the selected line to them - an icon only would be useless
• Color-blind people will have a hard time distinguishing the difference in color (if that's the only difference) so if text is there then they can use that

I'd highly recommend using a more wordy state value for these reasons - the state value shouldn't be useless.

[matt (support)]

The API change you outlined isn't quite the approach we want to take...

Yeah, I knew that from the previous discussion on this general topic. I was just hoping that while you work on a more generalized solution, this (hopefully minor) change might solve the need for the short term.

Unfortunately, we have to be very careful about how the API evolves and trying to add temporary solutions isn't something we want to try to do (for several reasons).

Unfortunately, we have to be very careful about how the API evolves and trying to add temporary solutions isn't something we want to try to do (for several reasons).

That's what you said about the current implementation/hack

BTW, you probably always want a reasonable text description of the state...
...I'd highly recommend using a more wordy state value...

Actually, the Phidgets plugin (where I am using graphics in the state column) gives the user a choice of the value/graphic that will appear in the state display. In the case of the Frequency Counter, they can have: Frequency, Count, Time, or a "pulsing dot". In the case of the pulsing dot, the keywords (from the limited available set) that are used (1/0) are meaningless. I could have used on/off, but they might convey a meaning that isn't really there.

Anyway, it's good to know you are working in this area and I'll see what surprises you have in store.

[jay (support)]

That's what you said about the current implementation/hack

Eh?

In the case of the pulsing dot, the keywords (from the limited available set) that are used (1/0) are meaningless. I could have used on/off, but they might convey a meaning that isn't really there.

Your hack is useless for visually impaired people (switching states fast enough to make it look like it's flashing) and it's causing a significant amount of IPC between the plugin process and the server for what seems to be of very little benefit. And in clients other than the Mac client (IWS, Indigo Touch) it's not really gonna work very well anyway since we don't refresh that often.

I reiterate: state text shouldn't be meaningless, particularly if it's only purpose it to hack in a questionable feature.

When Matt, or maybe it was you, announced the current means of supporting graphic symbols it was noted it was a quick way to a partial solution and was not your long term scheme - as Matt reiterated below, and which I fully support. Mostly, I wanted to say I'd like to have plugins given more graphic control over the UI. I probably made the request more specific than necessary, but I wanted to at least make the idea clear

As to the pulsing symbol and visual impairment, That is a non issue, as I noted, the user has a choice of what is displayed in the state column. Yes, if a visually impaired person chose a dot that alternated gray and green, they might have problems. But, why would they choose that when they could see the actual count instead? Also, the actual means of managing the "flash" I am using is to alternately turn the green dot on (1) and off (0) on each pulse. So, It does not exactly "flash" rather, it alternates between green and gray at intervals ranging from 1 to 5+ seconds. For many users the ability to determine something is active is all they want. Especially if the detailed data is available in a window lower down on the same screen.

Frankly, all I did was make a simple feature request. It may be a good idea, it may be terrible. You guys are free to do whatever you want with it. But, I really don't think I should have to defend it. Especially since my goal, and yours, is to get more people using Indigo to make their lives better.

[matt (support)]

We aren't asking you to defend your feature request. We are just defending our position of not wanting to implement it the way you outlined it in your example. We want to wait and have a more complete solution than to try to hack a temporary solution in. We appreciate your feedback and feature requests.