Material Design Icons

[metbril]

Following the forum thread, I'm proposing an icon set that uses material design icons. Depending on the license (IANAL) we can include it in openHAB or Eclipse SmartHome.

Classic icons can be browsed here: https://github.com/eclipse/smarthome/tree/6dd1df77136a70ec55da6746be05bf65b78ba15b/extensions/ui/iconset/org.eclipse.smarthome.ui.iconset.classic/icons Material icons can be browsed here: https://github.com/Templarian/MaterialDesign/tree/master/icons/svg

[metbril]

Mapping table

classic name (alias)	ESH cat	classic icon	material name	material icon
alarm (siren)	yes (no)		alarm-light
battery	yes		battery
blinds	yes		blinds
colorlight	yes		palette
contact	yes		x
dimmablelight	yes		lightbulb
carbondioxide	yes		x
door	yes		glassdoor
energy	yes		power
fan	yes		fan
fire	yes		fire
flow	yes		waves
garagedoor	yes		garage
gas	yes		gas-cylinder
house	no		home
humidity	yes		water-percent
light (slider, dimmablelight)	?		lightbulb
motion	yes		run-fast
movecontrol	yes		cursor-move

x | ? | | x | x | ? | | x | x | ? | | x |

[kubawolanin]

Here's the list of all ESH icons in the format proposed by @rtvb: Easily manageable Markdown table is also available on my Gist

Click to expand the table

classic name (alias) | ESH cat | classic icon | material name | material icon -|-|-|-|- alarm | ? | | alarm-light | attic | ? | | stairs | baby_1 | ? | | baby | baby_2 | ? | | baby | baby_3 | ? | | baby | baby_4 | ? | | baby | baby_5 | ? | | baby | baby_6 | ? | | baby | bath | ? | | x | battery-0 | ? | | battery-outline | battery-10 | ? | | battery-10 | battery-100 | ? | | battery | battery-20 | ? | | battery-20 | battery-30 | ? | | battery-30 | battery-40 | ? | | battery-40 | battery-50 | ? | | battery-50 | battery-60 | ? | | battery-60 | battery-70 | ? | | battery-70 | battery-80 | ? | | battery-80 | battery-90 | ? | | battery-90 | battery | ? | | battery | bedroom | ? | | hotel | bedroom_blue | ? | | hotel | bedroom_orange | ? | | hotel | bedroom_red | ? | | hotel | blinds | ? | | blinds | bluetooth | ? | | bluetooth | boiler_viessmann | ? | | water-pump | boy_1 | ? | | human-male | boy_2 | ? | | human-male | boy_3 | ? | | human-male | boy_4 | ? | | human-male | boy_5 | ? | | human-male | boy_6 | ? | | human-male | calendar | ? | | calendar | camera | ? | | webcam | carbondioxide | ? | | periodic-table-co2 | cellar | ? | | x | chart | ? | | chart-bar | cinema | ? | | theater | cinemascreen | ? | | projector-screen | cistern | ? | | beaker | climate-on | ? | | snowflake | climate | ? | | snowflake | clock-on | ? | | alarm-check | clock | ? | | alarm | colorlight | ? | | palette | colorwheel | ? | | palette | contact-ajar | ? | | window-open | contact-closed | ? | | window-closed | contact-open | ? | | window-open | contact | ? | | window-closed | corridor | ? | | x | dimmablelight | ? | | lightbulb | door-closed | ? | | x | door-open | ? | | x | door | ? | | glassdoor | dryer | ? | | washing-machine | energy | ? | | power | error | ? | | alert | fan | ? | | fan | fan_box | ? | | air-conditioner | fan_ceiling | ? | | fan | faucet | ? | | water-pump | fire-off | ? | | fire | fire-on | ? | | fire | fire | ? | | fire | firstfloor | ? | | numeric-1-box-multiple-outline | flow | ? | | waves | flowpipe | ? | | arrow-up-bold | frontdoor-closed | ? | | x | frontdoor-open | ? | | x | frontdoor | ? | | x | garage | ? | | garage | garage_detached | ? | | garage | garage_detached_selected | ? | | garage | garagedoor-ajar | ? | | garage-open | garagedoor-closed | ? | | garage | garagedoor-open | ? | | garage-open | garagedoor | ? | | garage | garden | ? | | tree | gas | ? | | gas-cylinder | girl_1 | ? | | human-female | girl_2 | ? | | human-female | girl_3 | ? | | human-female | girl_4 | ? | | human-female | girl_5 | ? | | human-female | girl_6 | ? | | human-female | grass | ? | | leaf | greenhouse | ? | | x | groundfloor | ? | | numeric-0-box-multiple-outline | group | ? | | home | heating-off | ? | | nest-thermostat | heating-on | ? | | nest-thermostat | heating | ? | | nest-thermostat | house | ? | | home | humidity | ? | | water-percent | incline | ? | | x | keyring | ? | | key-variant | kitchen | ? | | pot-mix | light-off | ? | | lightbulb-outline | light-on | ? | | lightbulb-on | light | ? | | lightbulb | line-decline | ? | | trending-down | line-incline | ? | | trending-up | line-stagnation | ? | | trending-neutral | line | ? | | chart-line | lock-closed | ? | | lock | lock-open | ? | | lock-unlocked | lock | ? | | lock | man_1 | ? | | human-male | man_2 | ? | | human-male | man_3 | ? | | human-male | man_4 | ? | | human-male | man_5 | ? | | human-male | man_6 | ? | | human-male | microphone | ? | | microphone | moon | ? | | weather-night | motion | ? | | run-fast | movecontrol | ? | | cursor-move | network-off | ? | | wifi-off | network-on | ? | | wifi | network | ? | | wifi | niveau | ? | | ruler | none | ? | | x | office | ? | | library-books | oil | ? | | oil | outdoorlight | ? | | spotlight-beam | pantry | ? | | format-paint | parents-off | ? | | human-male-female | parents_1_1 | ? | | human-male-female | parents_1_2 | ? | | human-male-female | parents_1_3 | ? | | human-male-female | parents_1_4 | ? | | human-male-female | parents_1_5 | ? | | human-male-female | parents_1_6 | ? | | human-male-female | parents_2_1 | ? | | human-male-female | parents_2_2 | ? | | human-male-female | parents_2_3 | ? | | human-male-female | parents_2_4 | ? | | human-male-female | parents_2_5 | ? | | human-male-female | parents_2_6 | ? | | human-male-female | parents_3_1 | ? | | human-male-female | parents_3_2 | ? | | human-male-female | parents_3_3 | ? | | human-male-female | parents_3_4 | ? | | human-male-female | parents_3_5 | ? | | human-male-female | parents_3_6 | ? | | human-male-female | parents_4_1 | ? | | human-male-female | parents_4_2 | ? | | human-male-female | parents_4_3 | ? | | human-male-female | parents_4_4 | ? | | human-male-female | parents_4_5 | ? | | human-male-female | parents_4_6 | ? | | human-male-female | parents_5_1 | ? | | human-male-female | parents_5_2 | ? | | human-male-female | parents_5_3 | ? | | human-male-female | parents_5_4 | ? | | human-male-female | parents_5_5 | ? | | human-male-female | parents_5_6 | ? | | human-male-female | parents_6_1 | ? | | human-male-female | parents_6_2 | ? | | human-male-female | parents_6_3 | ? | | human-male-female | parents_6_4 | ? | | human-male-female | parents_6_5 | ? | | human-male-female | parents_6_6 | ? | | human-male-female | party | ? | | martini | pie | ? | | chart-pie | piggybank | ? | | coin | player | ? | | music | poweroutlet-off | ? | | power-plug-off | poweroutlet-on | ? | | power-plug | poweroutlet | ? | | power-plug | poweroutlet_au | ? | | power-plug | poweroutlet_eu | ? | | power-plug | poweroutlet_uk | ? | | power-plug | poweroutlet_us | ? | | power-plug | present-off | ? | | home-outline | present | ? | | home | pressure | ? | | gauge | projector_benq | ? | | projector | pump | ? | | water-pump | qualityofservice | ? | | chart-areaspline | radiator | ? | | radiator | rain | ? | | weather-rainy | receiver-off | ? | | led-variant-off | receiver-on | ? | | led-on | receiver | ? | | led-outline | recorder | ? | | microphone | returnpipe | ? | | arrow-down-bold | rgb | ? | | format-color-fill | rollershutter | ? | | blinds | settings | ? | | settings | sewerage | ? | | emoticon-poop | shield-0 | ? | | shield-outline | shield-1 | ? | | shield | shield | ? | | shield-half-full | signal | ? | | signal | siren-off | ? | | bell-off | siren-on | ? | | bell-ring | siren | ? | | bell | slider | ? | | lightbulb | smiley | ? | | emoticon-happy | smoke | ? | | x | sofa | ? | | sofa | softener | ? | | cup-water | solarplant | ? | | white-balance-sunny | soundvolume | ? | | volume-high | soundvolume_mute | ? | | volume-off | status | ? | | checkbox-marked-circle | suitcase | ? | | briefcase | sun | ? | | weather-sunny | sun_clouds | ? | | weather-partlycloudy | sunrise | ? | | weather-sunset-up | sunset | ? | | weather-sunset-down | switch-off | ? | | toggle-switch-off | switch-on | ? | | toggle-switch-on | switch | ? | | toggle-switch-on | television-off | ? | | television | television-on | ? | | television | television | ? | | television | temperature | ? | | thermometer | temperature_cold | ? | | thermometer | temperature_hot | ? | | thermometer | terrace | ? | | x | text | ? | | comment-text-outline | toilet | ? | | x | vacation | ? | | beach | video | ? | | video | wallswitch-off | ? | | toggle-switch-off | wallswitch-on | ? | | toggle-switch-on | wallswitch | ? | | toggle-switch-on | wardrobe | ? | | tshirt-crew | washingmachine | ? | | washing-machine | washingmachine_2-0 | ? | | washing-machine | washingmachine_2-1 | ? | | washing-machine | washingmachine_2-2 | ? | | washing-machine | washingmachine_2-3 | ? | | washing-machine | washingmachine_2 | ? | | washing-machine | water | ? | | water | wind | ? | | weather-windy | window-ajar | ? | | window-open | window-closed | ? | | window-closed | window-open | ? | | window-open | window | ? | | window-closed | woman_1 | ? | | human-female | woman_2 | ? | | human-female | woman_3 | ? | | human-female | woman_4 | ? | | human-female | woman_5 | ? | | human-female | woman_6 | ? | | human-female | zoom | ? | | magnify |

[martinvw]

Sometimes the _1, _2, _3 etc or on / off are mapped to the same icon is that a useful and wise?

[kubawolanin]

@martinvw it's a work in progress. I didn't find an alternative state so left the icon as it is. Feel free to contribute.

[martinvw]

👍

[kubawolanin]

@all if anyone's interested, here's the whole Material iconset mapped to Classic: classic.zip

I think it looks decent:

To use that, simply unpack the content into your /openhab-config/icons/classic.

How did I generate the icons?

I simply downloaded Material icons svg folder and placed iconconvert.bat file there. Then I simply run the script so it's copied with the proper name.

[metbril]

Awesome work @kubawolanin. I haven't had much time lately so thanks for the mapping. I have some suggestions for alternatives. And I had already built a script to convert to svgs to colored versions for example for the lightbulb in use with a percentage.

[kubawolanin]

@rtvb that's awesome! Sure, any suggestions are welcome! I'm thinking of setting up a new iconset bundle project for these. Would you be interested in cooperating? The way I see it is that we would include all mappings for covering ESH icons + we would include more home automation related ones. This way we'll have a nice superset of material icons. How does it sound? ;-)

Cheers!

[kaikreuzer]

Sounds awesome :-)

The license is SIL Open Font License 1.1. I will have to check with Eclipse Legal, but at a first glance it looks fair and I would hope it is compatible with the EPL, so that we could add such an iconset bundle directly to ESH.

[metbril]

I have created a repo with my conversion script. I have not added @kubawolanin 's icon mapping. Feel free to create a PR if you like.

https://github.com/metbril/openhab-mdi

Update: I have added the selected set from @kubawolanin to the repo. It needs some tuning, but it's available.

[mueller-ma]

I've made a simple script that adds a round background to all these icons. What do you think about these icons: (Colors are Material colors)

[mueller-ma]

@kaikreuzer Should new icon sets have exact the same icons than "classic" or can they have more or less?

[metbril]

@mueller-ma I like the background color, but how would we use dynamic icons with different colors for different Item values?

[mueller-ma]

@metbril I took each color from here https://material.io/guidelines/style/color.html#color-color-tool (500 or the brightes one with white text color) and than choose a random color for each item group, e.g. all window icons. I wouldnt use different colors for different states. There should be in most cases a "off" mdi. But we could use different colors for boy-1, boy-2, etc.

I think your scripts are far better, so can you try to implement the background?

[mueller-ma]

I think it might be good to hardcode background color for some items, e.g. Android always green

[htreu]

@mueller-ma the icons look nice with the round colored background. For PaperUI however I guess the background should be generated by CSS and background color set dynamically. For the icon set I would recommend to only add the raw icons and let the different UIs decide on how to provide background (if any).

[mueller-ma]

@htreu I dont really like this idea. Icons should be the same on all clients.

[kaikreuzer]

Hey @metbril and @kubawolanin, thanks again for this gorgeous work!

Should new icon sets have exact the same icons than "classic" or can they have more or less?

That's something that wasn't cleanly defined so far, so I spent the last week to sort this out. You can find the result at https://www.eclipse.org/smarthome/documentation/features/ui/iconset/classic/readme.html.

So all icons that are listed there are considered mandatory for every iconset (while some are even still missing in the Classic Iconset). The only exception are "Other Icons" - these are the ones that the Classic Icon set has on top, but which is not required/standardised.

@kubawolanin It would be cool if you could adapt the mapping to these names!

With this, we should create a PR for an Material Iconset OSGi bundle, which should be similar to https://github.com/eclipse/smarthome/tree/master/extensions/ui/iconset/org.eclipse.smarthome.ui.iconset.classic. We could create it for a start in openhab2-addons, but the goal should be to have it at ESH, so that the Paper UI can make use of it as well. I haven't clarified the license issue yet, I will start this discussion right away now.

For the icon set I would recommend to only add the raw icons

Looking at this screenshot, I would say that the "raw" version even looks good for the Basic UI. But obviously, they would not work for dark themes.

I guess the background should be generated by CSS and background color set dynamically.

@htreu What about the foreground color, could/should that also be defined by the client? If we would want to head that way, we should define the iconset to ONLY provide SVGs, because with PNG we couldn't make this work. The other option is that we make the iconset bundle register different icon sets, e.g. a "light", a "dark" and a "colored" version. In that case, it would be up to the bundle to adapt the SVGs before delivering them to the client - and we could decide there, whether we want colored circles in the background or not.

[mueller-ma]

The other option is that we make the iconset bundle register different icon sets, e.g. a "light", a "dark" and a "colored" version. In that case, it would be up to the bundle to adapt the SVGs before delivering them to the client - and we could decide there, whether we want colored circles in the background or not.

I find this option very interessting. Espacially that different clients can use different themes and get some good looking icons. That's one reason why I still use the bright theme on Android, because some classic icons don't have enough visual difference from a dark background. Should the client draw the background or set a parameter in the GET request to get an icon with background?

[htreu]

we should define the iconset to ONLY provide SVGs

I would prefer it this way. The icon size, color and background should be a decision made on the client. The size might depend on the screen size and with SVGs you can scale without quality loss. The color may depend on the item state, the client theme and cultural interpretation. The background again is a matter of information design. The framework should deliver icons in the most neutral way so clients can adopt whatever style is required. In web ui this is common practice when delivering icon fonts. Here every icon is just an SVG which describes its contour, just like letters in a normal font. Scaling and coloring is up to the client.

[kaikreuzer]

@htreu Please note that this isn't a perfect fit for our icon infrastructure, though - a client is expected to ask for the icon for a specific state as well. So e.g. coloring a bulb to match a certain HSB state should ideally be done by the runtime and not by the client - this way we can easily provide this feature to all clients at once instead of requiring them to individually implement this.

[kaikreuzer]

Should the client draw the background or set a parameter in the GET request to get an icon with background?

No, clients have no way to pass additional wishes besides the iconset id. That's why I said that the iconset bundle should register different iconset ids for different versions.

[htreu]

okay, tnx for the additional information. With icons in SVG format we could easily have both: The UI could request icons for a specific state and will be provided with the colored version. There is still the option to re-color the icon or retrieve it raw and do the coloring client side. That said we gain the most flexibility when delivering SVGs. And for the state dependent request it should be feasible to render colored versions in the framework. This will ensure the same (color) result regardless of the provided icon.

edit: we should think about proper caching then...

[mueller-ma]

clients have no way to pass additional wishes besides the iconset id

Can this behavior be changed?

[htreu]

@mueller-ma what is the purpose of querying an icon with the background already rendered? I think placing an icon on some specific background is up to the client because this a very design/ui targeted decision. In case we would serve icons with a background pre-rendered I doubt this would fit a lot of clients (except the one the backgrounds where designed for). Should the background be squared, round, which diameter, should the icon throw a shadow? Clients can address this very easily, the framework does not.

[mueller-ma]

@htreu Less duplicate code in the clients

IMO some icons should have a specific background color, e.g. Android = green. How can this be achieved?

[mueller-ma]

I've put some work in the script by @metbril, so it now generates mostly all icons needed. The zip file contains 4 folder with different color modes:

1. black => black icons
2. state => color based on the state, e.g. green = on and red = off
3. random => random colors
4. combined => If no state color is set, use random

I would like to hear your feedback

openhab-mdi.zip Code: https://github.com/mueller-ma/openhab-mdi

[mueller-ma]

Not all icons are currently available, but there are PRs for most of them. Black: Combined: Random: State:

[metbril]

I really like what @mueller-ma has achieved with my initial effort. Hopefully this will become a standard feature of openHAB in the future.

[mueller-ma]

@kaikreuzer How should the icons be intergrated in esh? For the classic icon set there are a few sh scripts that convert the icons to png and create aliases. The script by @metbril is written in python and includes the original icons as subrepo. Should the script or the generated icons be included?

[htreu]

I have a question about random and combined (in random mode). Does it mean the colors of the items are randomly chosen? So maybe an ON state icon will be red vs. an OFF state icon may be green?

[mueller-ma]

Random means the icon colors are completly random, so ON could be red. Many icons (e.g. garden, house, etc.) don't have icons for special states, so they are black by default. To color them the mode combined can be used. In combined mode on will be green, off will be red (some other icons have a hardcoded color, e.g. android is always green) and for all icons without state a random color will be choosen. I wouldn't want to include random, maybe combined, state, black and white!?

[htreu]

I want to summarise my opinion on this issue:

• I welcome the material design icons as a separate icon set for openHAB
• The icons should be provided "as is" in SVG format (un-colored) and colored (where applicable, e.g. percentage, on/off) in PNG format. PNG only for backward compatibility.
• Coloring the icons should be completely up to the client. Its clearly in the responsibility of the UI on how to display certain states on icons.

from https://github.com/openhab/openhab2-addons/issues/2139#issuecomment-331102810

What about the foreground color, could/should that also be defined by the client? If we would want to head that way, we should define the iconset to ONLY provide SVGs, because with PNG we couldn't make this work.

Thats the way I strongly suggest. Otherwise:

we make the iconset bundle register different icon sets, e.g. a "light", a "dark" and a "colored" version.

... and the client then has to adopt its whole color theme to the backend defined color set. From an UI pov this is not an option! Fonts are delivered w/o colors for good reasons. And so should icons!

from https://github.com/openhab/openhab2-addons/issues/2139#issuecomment-331398228

So e.g. coloring a bulb to match a certain HSB state should ideally be done by the runtime and not by the client

I'm sorry @kaikreuzer but I disagree. It's not in the backends responsibility and a client could also decide not to color an icon at all. For the HSB state it would actually be a nice move from the backend to also provide some RGB values :-)

The frontend should be well aware of the items state for which an icon is requested. For all HTML5 clients its easy to apply colors by JavaScript. For other UIs capable of handling SVG I assume the same. For everything else (which should not be much) there will be PNGs.

I suggest this PR to provide SVG (uncolored) and PNG in the already known color versions.

[mueller-ma]

I suggest this PR to provide SVG (uncolored) and PNG in the already known color versions.

This way the png files wouldn't match the svg files like in the classic icon set.

Can a client request a specific icon set or check which icon set is used?

[htreu]

Can a client request a specific icon set

Yes, every request to the backend icon provider can include the iconset request parameter which tells the name of the iconset. If not given this falls back to classic.

[kaikreuzer]

Is there actually any reason why this iconset SHOULD support PNG? Afaik, all our clients meanwhile support SVG. Note that iconsets can declare, which formats they support, so PNG is not mandatory.

So e.g. coloring a bulb to match a certain HSB state should ideally be done by the runtime and not by the client

I'm sorry @kaikreuzer but I disagree. It's not in the backends responsibility and a client could also decide not to color an icon at all.

Then let me disagree with your disagreement, @htreu. With the generic approach that we follow, clients are not supposed to have any clue about what they are rendering. Therefore they normally should not be in any better position than the runtime to decide how to color an icon. I don't say that it never must do it - if it wants to support certain standard categories in a nicer way, it can always request the "plain" icon and do the coloring itself (if it knows how).

@kaikreuzer How should the icons be intergrated in esh?

First of all, thanks for all your efforts, it looks great! I am wondering, if we shouldn't put the logic in the iconset bundle as suggested above, i.e. we only have the "raw" svgs as resources and have the bundle adapt the delivered svg according to the requested state and theme (so more or less what the python script is currently doing as a manual pre-process).

[mueller-ma]

I am wondering, if we shouldn't put the logic in the iconset bundle as suggested above, i.e. we only have the "raw" svgs as resources and have the bundle adapt the delivered svg according to the requested state and theme (so more or less what the python script is currently doing as a manual pre-process).

I think that's the best way to do it. When the icon color is generated at runtime, it will be much easier to provide icons for all states (e.g. on=green, off=red). For some icons the color should be hardcoded in the bundle, e.g. light-off is black and light-on is yellow.

[davidgraeff]

Should we close this? If anybody is doing a PR to add more icon sets that's fine but why keeping this Issue open?

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/dynamic-icons-not-updating-when-color-item-state-changes/120645/8