The general design of default icons

Icon design is a matter of taste. But of course, one main design issue is the information to be perceived.
E.g. a contact would typically have three relevant states:

  • null/UnDef
  • OPEN
  • CLOSED

And in case of a door- or window-contact, OPEN is typically more critical than CLOSED. But how about null/Undef? If you do not know what state some item has and you are limited to two icons, the pessimistic view is surely more appropriate: Show it as something critical.
So for many icons, the default icon shows the more critical of the ON/OFF or OPEN/CLOSED variants.

But what I don’t like about it, is that I cannot distinguish between an OPEN or a null state (Admittedly the value [%s] might be shown as well and add to that information, especially with valuecolor).

Does anybody know of icon sets, which are more precise with this information, i.e. showing three different variants for a Contact, e.g. with a small question mark annotation or in a gray/red/green style? Or am I the only one liking a distinguishable representation of null state?

All dynamic icons have a default icon and it is this default that gets chosen when an item is NULL. I don’t know what the default icon is for does and windows but I think of you drop a new door.png into icons/classic it will replace the built in one. If that doesn’t work, you will need to drop in the door-on.png and door-off.png as well.

I have done exactly that and it works fine.

But for many icons, the default icon in the standard classic icon set is not “special”, so I’d really have to design a lot of icons.
E.g. the default icon for fire is same as for fire on, the default icon for doors/windows is the same like open, the default icon for dimmer is the same as for 100% and so on.

If I find nothing else I will, in fact, try to design special “unknown” icon variants for unknown/uninitialized/null values, but every time something doesn’t seem to fit, I’d rather drop a note in the forum; sometimes the answer might be: “rather don’t do it, it is like it is for a reason”.

When it comes to icons, with very few exceptions, the answer is because no one has done it yet.

Most of the advanced users I think download icon sets from here and there on the internet and largely abandon the default set. I design my HA to not require a UI at all so my sitemap is just status information for me. I’m not going to spend a lot of time on the aesthetics of such a display so haven’t looked into using alternative icon sets.

This is probably right; I just wanted to be a bit more sure about it. Lacking a “don’t do it” answer in this thread, I feel more confident that my effort is not misguided.

BTW: In addition to “ternary state” icons, I’d often like to have a “category” icon, used in hierarchies or for groups, when you don’t even have a state (and never will have). For the existing icons set there are some interesting icons, where the default icon is empty, so you cannot use them for cases where you do not have a state. But then again with more work on my groups, most of them could have an aggregated state like OR(ON, OFF), so I’d really have a state.

Nice, if you can get it. Maybe that should be the final state of many home automation projects if two conditions can hold:

  • enough sensors, actors, and rules to do it “the right way”
  • going beyond the nerdy phase where you like to play with and show every little switch on a large sitemap

Currently, I fail on both criteria, even if most of what I started works fine in between and I have a lot of fun.

I’m very deliberate on what I will and will not automate so I can stick to this principal. Any automation I do has to be easier to accomplish than the traditional manual way of doing it or accomplish something impossible to do manually. If step on in the"automated" interface is open your phone and browse to the OH app I’m usually well past this principal.

So there are a lot of things I will not automate (e.g audio/video).