Man/Auto mode switch

This is how I use it and it works

Text item=HeatingBoiler label="Heizungsbrenner [%s]" icon="fire-on" visibility=[ HeatingBoiler==ON]
Text item=HeatingBoiler label="Heizungsbrenner [%s]" icon="fire-off" visibility=[ HeatingBoiler==OFF]

Good idea,
So with …

		Switch 		item=i_HVAC_CH_Switch_Proxy			label="Central heating ON"	 				icon="fire-on"		mappings=[ON="ON",OFF="OFF",AUTO="AUTO"] visibility=[i_HVAC_CH_Switch == ON]	
		Switch 		item=i_HVAC_CH_Switch_Proxy			label="Central heating OFF" 				icon="fire-off"		mappings=[ON="ON",OFF="OFF",AUTO="AUTO"] visibility=[i_HVAC_CH_Switch == OFF]

I get the Central heating OFF and Central Heating ON correctly, but when OFF the fire-on icon is displayed. The screen refreshed because I see *Central heating OFF in AUTO mode. I refreshed the browser for ten times.

? ?

Hover over the icon and find out the image name. I note that fire.svg and fire-on.svg are the same image in default iconset.
Remind of UI in use? Android app?

mm, but you do not have any mappings, and yours are Text not Switch

it is fire-off.svg , but displaying the fire on , bizarrely

both Android, and Chrome browser on PC

Let’s be really clear, you are relying on the built in iconset fire.svg fire-on.svg fire-off svg - and definitely have no icons of those names in your /classic/icons folder?

I still have doubts about the icon picker behaviour here.
It will look for fire-off-auto.svg in the first case.
That’s fine and normal, it will find nothing and go into fallback.
My doubt is whether it then defaults to fire-off.svg (a kind of rule-bender) or to fire.svg (playing by the rules)

My request for what the UI thinks the image was called was dumb by the way - whatever image the iconpicker actually serves up, the UI thinks it is fire-off.svg

Personally I would abandon all this and make two custom icons fireoff.svg and fireon.svg just to get going!

2 Likes

Let’s be really clear, you are relying on the built in iconset fire.svg fire-on.svg fire-off svg - and definitely have no icons of those names in your /classic/icons folder?

Yes I am, and I have zero icons in $OPENHAB_CONF/icons/classic ,i.e. /etc/openhab2/icons/classic

Personally I would abandon all this and make two custom icons fireoff.svg and fireon.svg just to get going!

I have read the icon docs and I’m confused.
Take “fire off”…
do I create fireoff.svg or fire-off.svg and what name do I put in the sitemap’s icon=“<name”> , fireoff fire-off or off when sitemap visibility is set to i_HVAC_Switch==OFF

The hyphen is the magical icon picker part. You are not “supposed” to put hyphens in icon names, for fear of unexpected action by the icon picker. Now we’re trying to avoid that.

someicon.svg in custom icons folder is effectively a one-member iconset. When icon picker is tasked to serve this icon, whatever the associated Item state, it’s the only one it can serve.

In other words, it behaves as a plain simple icon. You put icon=“someicon” in your sitemap, that’s what you get.

So
classic/icons/myfireiconon.svg (a copy of fire-on image)
classic/icons/myfireiconoff.svg (a copy of fire-off image)
will circumvent any picker interference.
You’re specifying the names directly in your sitemap using visibility and do not want picker interfering, do not want states to be considered.

1 Like

ok @rossko57, understand now. And that is what I want, to remove the icon picker. Just looking at the HTML render source …

<div class="mdl-form__row mdl-cell mdl-cell--6-col mdl-cell--8-col-tablet mdl-form__row--hidden">
	<span class="mdl-form__icon">
		<img data-icon="fire-on" src="../icon/fire-on?state=AUTO&format=svg&anyFormat=true" />
	</span>
	<span  class="mdl-form__label">
		Central heating ON
	</span>
	<span  class="mdl-form__value mdl-form__value--group">
		
	</span>
	<div
		class="mdl-form__control mdl-form__buttons"
		data-control-type="buttons"
		data-item="i_HVAC_CH_Switch_Proxy"
		data-has-value="false"
		data-count="3"
		data-widget-id="0002"
	>
		<button 
	class="mdl-button mdl-button--raised mdl-js-button mdl-js-ripple-effect mdl-button" 
	data-value="ON"
>
	ON
</button>
<button 
	class="mdl-button mdl-button--raised mdl-js-button mdl-js-ripple-effect mdl-button" 
	data-value="OFF"
>
	OFF
</button>
<button 
	class="mdl-button mdl-button--raised mdl-js-button mdl-js-ripple-effect mdl-button--accent" 
	data-value="AUTO"
>
	AUTO
</button>

	</div>
</div>
**<div class="mdl-form__row mdl-cell mdl-cell--6-col mdl-cell--8-col-tablet ">**
**	<span class="mdl-form__icon">**
**		<img data-icon="fire-off" src="../icon/fire-off?state=AUTO&format=svg&anyFormat=true" />**
**	</span>**
**	<span  class="mdl-form__label">**
**		Central heating OFF**
**	</span>**
**	<span  class="mdl-form__value mdl-form__value--group">**
		
	</span>
	<div
		class="mdl-form__control mdl-form__buttons"
		data-control-type="buttons"
		data-item="i_HVAC_CH_Switch_Proxy"
		data-has-value="false"
		data-count="3"
		data-widget-id="0003"
	>
		<button 
	class="mdl-button mdl-button--raised mdl-js-button mdl-js-ripple-effect mdl-button" 
	data-value="ON"
>
	ON
</button>
<button 
	class="mdl-button mdl-button--raised mdl-js-button mdl-js-ripple-effect mdl-button" 
	data-value="OFF"
>
	OFF
</button>
<button 
	class="mdl-button mdl-button--raised mdl-js-button mdl-js-ripple-effect mdl-button--accent" 
	data-value="AUTO"
>
	AUTO
</button>

	</div>
</div>

I note the lines I have starred with ** , the icon referenced is fire-off but the state to the icon selector (?) is AUTO so is it looking for fire-off-AUTO.svg (which doesnt exist nor does fire-on-AUTO.svg_ and so it defaults to fire and uses the default on ??
or
Could it be my mappings ON= , OFF= and AUTO= should be on= , off= and auto= possibly?

More or less. The picker takes care of upper/lowercase, just ignore that.

Whether the picker defaults to seeking fire or fire-off is unknown to me, but fire only is consistent with your observations.
Remember, fire happens to look the same as fire-on in this instance.
As I said, the “filename” the UI thinks the image has is not the filename the picker actually got the image from.

I think it works for Hans because his states happen to be on and off, no auto.

1 Like

Quite agree with you on Hans’ setup.

So what icon filenames should I use in the filesystem and what name in the icon= sitemap? or could I use combinations of visibility= to AND the conditions such that I can pick icons when i_HVAC_CH_Swtich==ON and i_HVAC_CG_Switch_Proxy==AUTO ??

I’m baffled here now and loosing the plot :slight_smile:

Anything you like. From the docs - Icon filenames may include lowercase letters, numbers and underscores

I’m not sure what is unclear about

Let’s edit it down

someicon.svg in custom icons folder behaves as a plain simple icon.

You put icon=“someicon” in your sitemap, that’s what you get.

Sorry, I meant I understand what you say but it is not what I seem
because whatever I do, it doesn’t work .
I have ch_on.svg and ch_off.svg and put these in the sitemap icon=
Just didnt work, still showing the fire icons !!! Weird

BUT

I have been using BasicUI and I just went to my Android, OpenHAB app, and with my custom ch_on.svg and ch_off.svg icons , it WORKS !

Back to BasicUI and the fire icons are still being shown , incorrectly.

There’s a bug I’m sure because when I used fire svg icon names and in the sitemap , as above , it didnt work.

Only works by renaming the icon files to something other than fire and only using the android App

How strange

But wait @rossko57 …it gets better…

If I login at www.myopenhab.org and open up BasicUI , it now is correct , the fire icons work as expected. Back to BasicUI on my LAN, and it’s still wrong. Logged out logged back in - same. Reset WiFI network - same. Really really strange

Clear the browser cache perhaps.

2 Likes

hell, didn’t think of that

Yep, that’s done it, works now.

Marked Solved although I really want to mark your and @rossko57 as Solved. Can’t do both :frowning:

Would be interesting if my config works as well at your snstallation after clearing browser cache

For completeness, I experimented

My custom icon set in /classic/icons
beam.png
beam-open.png
beam.closed.png
Each is a visibly different image.

Stealing a URL from my UI and using it directly in OH2.5 e.g.

http://localhost:8080/icon/beam?format=svg&anyFormat=true
(valid name, no state)
displays beam image, as we’d hope.

http://localhost:8080/icon/beam?format=svg&anyFormat=true&state=closed
(valid name, valid state)
displays beam-closed image, as we’d hope.

http://localhost:8080/icon/beam?format=svg&anyFormat=true&state=apple
(valid name, unknown state) displays beam image, again as we’d hope.

Now to “break the rules” …
http://localhost:8080/icon/beam-closed?format=svg&anyFormat=true
(naughty hyphen name but exists, no state)
shows beam-closed image. Naughty, but works.

http://localhost:8080/icon/beam-closed?format=svg&anyFormat=true&state=open
(naughty hyphen name but exists, valid state)
shows beam-open image. Oh, surprise.

http://localhost:8080/icon/beam-closed?format=svg&anyFormat=true&state=apple
(naughty hyphen name but exists, invalid state)
shows beam image, default.

http://localhost:8080/icon/beam-apple?format=svg&anyFormat=true
(invalid hyphenated name, no state)
shows beam image, default

http://localhost:8080/icon/beam-apple?format=svg&anyFormat=true&state=closed
(invalid hyphenated name, valid state)
shows beam-closed image

Conclusions:

If the UI supplies an icon request with no state (I have no idea whether any of the UIs may do that), you can get away with directly addressing a hyphenated icon.
It could happen with sitemap like - (because there is no Item to get the state of)

Text label="for pagination only" icon="myicon-off" {

But if there is a hyphenated icon name AND a state, then the picker discards the hyphenated part of the name (beam-closed) to extract a base name (beam), then builds a state-related name (beam-open). If that exists, serve it. If not, serve base/default version.
I expect the presence of state= in the URL invokes this process.

I was wrong about picker looking for say beam-open-closed.png, tried that and it doesn’t happen.

I’ll stick to my initial pronouncement - specifying hyphenated icon names in sitemap (or Item definitions) breaks the rules with unexpected results.

Does this logic explain your visible experience, Hans ? @hmerk

2 Likes

It surely explains it. I was just using visibility tag for text widgets, so never thought it could be an issue.

1 Like

Well @rossko57 that is a well thought out whitebox test and pretty agreeable conclusive results. I did have hyphens in my custom icon names - at first - and I concur , in that the results were neither predictable nor consistent.But when I replaced the hyphen with underscore, the UI/OH does no further processing and serves up the requested custom icon (provided it exists of course) without applying a suffix for the state when used in a sitemap - yet I think it does (add a state suffix) when using this in the .items definition.

Different functionality when using icon=“abc” (sitemap def, no state added to name), and < abc > (in items def , state is added to name) - at least that is my experience.

I am nowhere near the level of expertise as you, but I have read the dynamic icon text over and over and I am not sure whether your analysis and summary (which I agree with) is accurately documented?
https://www.openhab.org/docs/configuration/items.html#icons ? The way I read, is that it is inferred (re “Hyphens ( - ) are reserved for [Dynamic Icons]” , but not explicitly mentioning unpredictable results, nor does the sitemap syntax validator throw an warning when encountering hyphens in sitemap custom icon names. I am being too anal ??

I do not agree. Note that the functional “getting away with it case” in the sitemap relies on that sitemap line having no primary Item specified to get the state of.
Example

Text label="blargh" icon="rule-bender"`

is the rare exception where rule-bender.svg is served

It is not possible to use the icon specified in an Item definition like <bend-more> without actually specifying that Item in the sitemap

Text label="blargh" item="myItem"

and that’s going to look for bend-myitemstate.svg, defaulting to bend.svg

I did not try out the case of overriding an Item definition with a sitemap definition

Text label="blargh" item="myItem" icon="other-bending"

but I’m fully confident the process applies, and that would look for
other-myItemstate.svg and default to other.svg

It isn’t. It’s irrelevant (if interesting).
This what the docs say

  • Icon filenames may include lowercase letters, numbers and underscores ( _ )
  • Hyphens ( - ) are reserved for Dynamic Icons

Them’s the rules.

2 Likes