[sitemap] AND operator accepted in any condition + added optional conditional rules for icon

[lolodomo]

Allow multiple conditions with AND operator in visibility/color/icon rules

Closes #3058

Also allow dynamic icon based on other item states.
Allow dynamic icon even with non OH icon sources.

Example: icon=[item1>0=temperature,==0=material:settings,f7:house]

Related to openhab/openhab-webui#1938

Unit tests added or extended to cover the new features.

Signed-off-by: Laurent Garnier lg.hc@free.fr

[lolodomo]

@openhab/android-maintainers
@openhab/ios-maintainers

For sitemap UIs, the only change to consider is that SSE events will now have a field icon set when the icon is not defined as static in the sitemap element. This field was already existing but was never set by the server. So the UI should now consider it when reloading the icon of an element.

[lolodomo]

I just realized that if icon rules are defined, the UI should then call the OH icon servlet without passing the item state. So the sitemap REST API should provide this information to UIs to allow distinguishing dynamic icon with rules from dynamic OH icon without rules. I will enhance that.

[maniac103]

So the UI should now consider it when reloading the icon of an element.

FWIW, Android app already does that, see here

I just realized that if icon rules are defined, the UI should then call the OH icon servlet without passing the item state.

Why? Can't the servlet not figure that out by itself? It would be great if we made the icon logic not even more complex than it already is ;-)

[lolodomo]

Why? Can't the servlet not figure that out by itself? It would be great if we made the icon logic not even more complex than it already is ;-)

No because the icon servlet is fully independent of sitemap concept.
As I introduce a new dynamic way to do for icons, we have to be sure, if used, that UIs will not use the other dynamic way at the same time.
By the way, this is not something introduced by this enhancement but by the previous enhancement that added the staticIcon parameter.
I will now add another boolean "iconIgnoreState" to the sitemap REST API.
So "staticIcon" will tell you if you have to reload or not the icon when receiving updates.
"iconIgnoreState" will tell you if you have to ignore the state or not when reloading the icon.

[lolodomo]

I will now add another boolean "iconIgnoreState" to the sitemap REST API.

Done

[maniac103]

So "staticIcon" will tell you if you have to reload or not the icon when receiving updates.
"iconIgnoreState" will tell you if you have to ignore the state or not when reloading the icon.

Are all 4 combinations of those 2 values valid? E.g. staticIcon=true combined with iconIgnoreState=false doesn't seem to make sense? Also I'm not sure if that second flag triggering a reload will work properly, since - as long as the URL stays the same - caching is likely to swallow reloads anyway (and, in the case of the Android app, we rely on that behavior to make sure icons aren't loaded over and over when scrolling through lists). IMO it would be better to just require the UI to select whether or not to pass state when fetching icons.

[lolodomo]

I am reverting the last change. The field "staticIcon" is sufficient.
The boolean "staticIcon" returned by the sitemap REST API will tell you if you have to use or not the item state when requesting the icon.
With this new change, when receiving SSE updates, either the icon field is filled and you must reload the icon, or it is null and you must not reload the icon.

[lolodomo]

Regarding the ability to use multiple AND conditions, this is something fully handled by the core framework and there is nothing to change in sitemap UIs. And the sitemap syntax remains fully backward compatible.

[lolodomo]

I am going to extract the feature about AND conditions in a separate PR.

[lolodomo]

I close this PR. A new one will be opened.