Dynamic Icons Items (Type: Number)

I am aware that the item, when created, has a null state.

The state is an integer 0-100 with no units.

I have set the state via API PUT item/{itemname}/state.

When I talk about a base/standard, I just mean the type number with no subtypes.

If I change the item type from number to dimmer or vice versa, the state is preserved.
When I create an item with the type Dimmer and then move the Slider, the status is also set.

I am at a loss here. I cannot understand your reluctance to put forth the information that is required in this case. Your answers in the post above are finally informative, however:

That level of information needs to be applied not just to the one piece that was specifically pointed out, but to every piece of your process and experience…every one. I was going to suggest that you take some time to look around the forums in general and read through some posts where questions have been answered to see what level of information is appropriate, but, actually, I don’t think this unclear to you. Looking back at your history you had a question about an error and posted the error code. You had a question about items and gave a wonderfully detailed account of your process with supporting screenshots (and this appears to have resulted in a solution that same day) and in the course of that discussion when a question came up about a widget, you posted the widget code.

This time you have a question about how different types of items interact with widgets and sitemaps and a custom icon. Have you given a entire description of the problem…not yet in detail, you’re inching closer with answers to specific questions, but it’s not worth our time to ask you every single question when you could offer that information up front. Have you posted the widget code…not yet. Have you posted the sitemap definition…not yet. Have you shown us the names of the custom icons…not yet in detail, you did tell us what the naming scheme should be.

It seems you think this is a simple question and only requires simple information. But this is a matter of several distinct parts of a complex system interacting. Your attempts to simplify the information are actually making it worse.

I don’t know if this means “both in BasicUI and in a MainUI Layout Page” or if you are confusing BasicUI and MainUI and implying that you used a layout page in BasicUI (which of course, is nonsensical).

Three different people (with many hundreds of successful solutions between them) have told you it is not a simple question and requires in-depth, detailed information, but you continue to neglect these direct requests. I think it is possible you have discovered a legitimate issue, but I just don’t know yet, because too much information is still missing. If you have discovered a problem and you tried to submit an issue to the repo with this much information missing, I don’t think any of the developers would give it a second look.

Start back with this:

For every single concept in that brief description, every OH entity you interact with, every process you perform, every value you mention, apply the level of detail you just demonstrated in your previous answer. And for every detail you add, ask yourself, “is there some code/log entry/screenshot I can add that re-inforces this?”. Take your time, this seems like it could be a deeply buried complex issue, it will take a complex description to get it across.

1 Like

Why am I reluctant to share information? I realized that the first post was quite short, for me all the relevant information is already there.

Can you please explain why I should post the widget code and sitemap definition if it works there? The problem only occurs in the Location- and Equipment- and Property Card. In the Item and Model Settings also only the default icon is shown, but there the default icons are shown for all ItemTypes.

Why would that help anyone? If I write: temp-0.svg / temp-5.svg / temp-10.svg and so on? The screenshots showed that the icons work. So that can’t be the problem.

The Basic UI and the Main UI are the result of the context. I have not mixed it up. I mean with Basic UI the Sitemap and with Main UI the Webinterface. I think the names of the UI’s are clear in openHAB.

If you already say that this is nonsense, why do you consider this configuration yourself?

We can continue to write about discussions of principle, but I would be interested in a solution.

Between the three people who have replied on this thread we collectively have 25+ years of experience in using, configuring, and helping other people with problems using, and configuring OH. We are also semi active in the code of OH.

All three of us have stated repeatedly what information we need to understand the problem further. Yet you insist that you know better. Well, if you know better, what do you need us for? You clearly seem to know everything that could be going on well enough to decide for us what information we need so clearly you know everything needed to solve this problem yourself.

Or, maybe, just maybe, you can trust that we know what we are talking about. That we know the dozens of things that could be going wrong here and we require the information we’ve request to work through each and eliminate potential options until we narrow things down to the root problem.

Ultimately, you are the one requesting help. You don’t get to decide what information we need to provide that help. It’s arrogant and disrespectful to the people who volunteer their time to help people on this forum.

We are now approaching two days of “please provide us this information” and “no you don’t need that” and are no closer to an explanation for this behavior. We can’t reproduce it with the info provided (if it didn’t work for us we would have already filed an issue).

It will help us understand why it works there which might give us a clue for why it doesn’t work elsewhere.

Because it can help us correlate the setting on the Items and the widgets and potentially see something that might be the problem.

Good luck with that.

Funnily enough we are interested in a solution too! Especially if this is a regression or other type of bug that needs to be fixed. But since you know better than we what information we need to figure that out, clearly you know better than we do how to come to a solution.

The bottom line is we’ve stated what we need to help. We are not obligated to justify why we need each and every little pice of information we request. Provide it and we just might be able to help get to a solution. Refuse and you are on your own.

I won’t do it but I’m seriously tempted to close this thread as a complete waist of time.

3 Likes

OK.

Please remember also to follow up on this thread when you have used all that relevant information to find the solution. I’m quite curious as to the answer and it may be helpful for others in the future.

item.json Dimmer

  "Test_Dimmer": {
    "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
    "value": {
      "groupNames": [
        "Location_Home"
      ],
      "itemType": "Dimmer",
      "tags": [
        "Point"
      ],
      "label": "Test_Dimmer",
      "category": "temp"
    }

Settings Item Dimmer

Settings Item Dimmer

Settings Model Dimmer

Settings Model Dimmer

item.json Number

  "Test_Number": {
    "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
    "value": {
      "groupNames": [
        "Location_Home"
      ],
      "itemType": "Number",
      "tags": [
        "Point"
      ],
      "label": "Test_Number",
      "category": "temp"
    }

Settings Item Number

Settings Item Number

Settings Model Number

Settings Moddel Number

Page Location

Sitemap Test

sitemap page_test label="test" {
      Text item=Test_Number label="Test_Number [%s]"
      Text item=Test_Dimmer label="Test_Dimmer [%s]"
      Slider item=Test_Number label="Test_Number [%s]"
      Slider item=Test_Dimmer label="Test_Dimmer [%s]"
  }

Page Layout

config:
label: test
blocks:
  - component: oh-block
    config: {}
    slots:
      default:
        - component: oh-grid-row
          config: {}
          slots:
            default:
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-label-card
                      config:
                        item: Test_Number
                        icon: temp
                        iconUseState: true
                        title: Test_Number
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-label-card
                      config:
                        item: Test_Dimmer
                        icon: temp
                        iconUseState: true
                        title: Test_Dimmer
                      slots: null
masonry: null
grid: []
canvas: []

Page Layout

Close enough.

Laid out in detail and logically arranged, the issue becomes immediately clear. What you are seeing is not an issue with the semantic cards, it is an issue with the fact that the semantic cards use the default list item for your number items to populate their lists. You would see this same problem on a regular widget if you used the group popup to open up a list of the items in a group.

It comes from this line here:

Where the default list item only sets iconUseState to true for certain types of items. Number, obviously is not on that list.

Now, I don’t know whether Number was left off that list for a particular reason, that’s a question only the javascript authors can answer. But now, if you really need to have the dynamic icons for a number item in the semantic cards you can file an issue on the UI repo and point to exactly what is going on, or even better yet, make the modification yourself and submit a PR.

@JustinG beat me too it and even identified the root cause. I’ll leave what I wrote below the line.

However, I’d like you to perform one quick experiment for me. What happens if you set the Semantic tag to “Measurement”. Then add “Temperature” as the property tag. These need to be done on the Number Item. Does that give it enough context to set the icon properly?

IIRC, the semantic tag hints happen after the Item type hints.


OK, so this icon on the Item’s page is always going to only show the default icon. So no surprised here so far. Same goes for the Number Item.

I’m not sure which screen this comes from, Settings->Items or Model but in either case this too only shows the default icon so this is expected too. Same goes for the Number Item.

what happens if you change the semantic tag on Test_Number to Setpoint? That should make MainUI choose a slider similar to what it chose for Test_Dimmer. You might need to provide a property though so if just using Setpoint doesn’t work, add a property tag of Temperature.

These all look to be displaying correctly.

I’m surprised this is working at all. Unless something has changed, in a MainUI widget the iconUseState property only works with oh icons and your property for the icon property is incorrect. It should be oh:temp to tell MainUI where to get the icon from.

I wonder how it’s getting the right icon? Maybe it defaults to oh: when not supplied? That’s new in OH 4, right @JustinG or has this been defaulting for awhile now? I only use f7: and material: icons so I wouldn’t have noticed the change.

Anyway, it’s clearly working even if based on my understanding it shouldn’t.

I also assumed that. I was mainly concerned with the Location Card

Settings → Model

Measurement

"Test_Number": {
  "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
  "value": {
    "groupNames": [
      "Location_Home"
    ],
    "itemType": "Number",
    "tags": [
      "Measurement",
      "Temperature"
    ],
    "label": "Test_Number",
    "category": "temp"
  }

Setpoint

  "Test_Number": {
    "class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
    "value": {
      "groupNames": [
        "Location_Home"
      ],
      "itemType": "Number",
      "tags": [
        "Setpoint",
        "Temperature"
      ],
      "label": "Test_Number",
      "category": "temp"
    }

That you can omit the oh: also surprised me, but it seems to work

I believe this has been true since the iconify update. That was when all the f7 icon stuff was fully merged into the oh icon, if I recall. And yes, if no prefix is supplied then the icon defaults to an oh icon.

1 Like

Thanks for performing the experiment.

I think we have our answer. For now, for Number you’ll have to supply the iconUseState property manually on the widget.

If you think that should change, you should file an issue or PR on the openhab-webuis repo with a request to add Number to the list that implicitly sets iconUseState to true. It’s a really easy change, you could even create the PR in the browser.

I’m curious why Group is in the list. :thinking: That’s neither here nor there though.

Are all subcategories of numbers included?

I would expect so. The subcategories are defined by a property on the Number Item but a Number:Temperature is still a Number.

However, I don’t know the UI code so I can’t say that for certain. It might be part of the category in which case that may be the reason they didn’t add Number, because there are dozens of categories.

github.com