Disable dynamic icon for specific item (BasicUI)

Setup, Configuration and Use Items & Sitemaps
1

Hello,

I have temperature sensors that are publishing their value as soon as its available (~ 800ms) as I am drawing a realtime graph in Grafana.
Problem is, that BasicUI is trying to fetch a new icon with every item update (which is useless in this case as there is only a default icon for temperature icon):

image
image1285×694 48.2 KB 

Group:Number:AVG OutsideTemp "Outside temperature [%.2f C°]" <temperature> (Outside, Temperatures) ["CurrentTemperature"]

sitemap house label="House"
{
	Frame label="Sensors" {
		Default item=OutsideTemp
	}
}

I have tried copying temperature.svg icon in icons/classic folder, but it changed nothing.
Is there a way to disable icon updates for specific items?

Running on openhab2/testing 2.5.0-1

2

That would be an enhancement request for BasicUI. I suppose it would require some kind of option for a sitemap entry to suppress dynamic icons, perhaps using the existing icon= parameter in some way.
The other sitemap based UIs would also need enhancement to work with this kind of change.

It’s not going to stop much UI traffic, as the root issue is frequent item state updates. But I suppose it could roughly halve it.

What actual problem do you experience?

3

Well its not actually a problem - just annoyance:

  1. In Android OpenHab app the item icon is constantly flickering - probably because its re-rendering it this often.
  2. Its wasting bandwidth in cases of slow connection (like bad 2G we re having here if 4G drops for some reason) - this bandwidth could be used for example to successfully post command to open the gate when I am freezing outside trying to open it… :joy:
4

Have you tried renaming the copied icon? Maybe it stops trying to fetch the icon if no dynamic variant is there.

5

Sure… I know… I could have a separate sitemap just for this high-speed sensors.
I also could create proxy item which would update its state from the real item only once a minute…

But add option to disable icon updates - ideally automatically if there are no state dependent icons - seems like proper solution.

6

Perhaps the app could be improved there, I don’t know how it works. It could be refreshing the whole sitemap entry because the state was updated, not just icon.

Fair enough.
But look to your system design. If bandwidth is precious, why have you chosen to put a sub-second updating Item(s) on your UI? Do you really need to know temperature every 800mS? This is a home automation system, not realtime process control.
The most effective workaround (work for any UI) would be to create a less frequently updated dummy item(s), perhaps that could usefully show a five minute average or similar.

7

That does not work. I have tried that.

8

You may need to qualify “that”.

9

Can you create a rule that does a sum of last 100. Then use that item in Basic UI.

10

You may need to qualify “that”.

I was responding to comment from curlyel - renaming icon does not helped.

But look to your system design. This is a home automation system, not realtime process control.

Fair enough :wink:.
This kind of bandwidth is not really a problem until somebody is trying to access the sitemap over ultra-slow connection.
I will create another item + rule to update them, lets say once a minute, just for sitemap purpose.
It seems like the BasicUI is updating icons only for items on current page (block created using {}) - So I could display the average value on the root page and create sub-page with the realtime values.

But it would be great if this could be handled in some of the future release.
Or at least do not try to update the icon if the value was not changed (reloading icon if value was updated from 4.000 to 4.000)…

11

Yep. I’m not sure all sitemap based UIs would behave the same, I.e. not fetching icon updates for currently “hidden” items.

That’s only part of the traffic - I do not know if any of the UIs remain registered to be pushed updates for hidden items. (The OH end does not know what page you are looking at)
I suspect it should - you may be using an item state in a visibility= option for something else, even if hidden.

Only fetching icon on state changes seems a reasonable enhancement to request.

These are just nibbling at the edges, don’t lose sight that the underlying problem is you choosing to place sub-second updating items in your UI. openHAB will not be optimised for this.

12

You might also consider tackling this from the other end.
As a modbus user, devices are typically polled once a second. With many Items, many updates, causing overheads on events bus, persistence, etc. Presumably UI too!
A binding option was introduced to inhibit updates-with-no-change ( per channel). It’s pretty much essential to use this when hundreds of Items are involved.

Perhaps whatever binding or device is involved here would benefit from such an enhancement.

13

If using Scripted Automation, I wrote a module for the Helper Library that will basically implement this Rule for you. Rate Limiting. by rkoshak · Pull Request #255 · openhab-scripters/openhab-helper-libraries · GitHub. There is a Rules DSL version at Design Pattern: Rule Latching.