If you would show us the complete item definition, and don‘t say nothing special, as you mentioned to have used as custom icon (temp.svg) but not showing the category setings and the widget yaml config, we could.
But as you are not giving this information, we cannot reproduce what you are seeing.
Not really, no. Nobody can attempt to replicate what’s going on because you still haven’t really provided the details. You need to take the time to be as detailed and explicit as possible. You have been quite forthcoming with numerous vague descriptions, but this has to be a “don’t tell us, show us” kind of situation.
For example, you haven’t even at any point yet, fully articulated the question here. Your initial post contains no question. You are expecting us to assume a lot.
You are not being targeted or attacked here, but the fact of the matter is that if we’re going to be able to work to a solution we have to be working from information not guesses.
I suggest just starting over completely. Assume that you have given us no information at all. Take the time to express your question clearly then give us the supporting evidence. Something doesn’t work? Ok, then tell us exactly what you expect to see, and show us what you see instead. Give us the full rundown of every part. If this involves an item show us the item configuration file or the page in the UI.
If this involves a widget show us the complete config for the widget. You cannot give us too much information. Pile it on and let us sort through, don’t try to filter it yourself.
works:
"Test_Test": {
"class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
"value": {
"groupNames": [
"Location_Home"
],
"itemType": "Dimmer",
"tags": [
"Point"
],
"label": "Test Test",
"category": "temp"
}
does not work
"Test_Test": {
"class": "org.openhab.core.items.ManagedItemProvider$PersistedItem",
"value": {
"groupNames": [
"Location_Home"
],
"itemType": "Number",
"tags": [
"Point"
],
"label": "Test Test",
"category": "temp"
}
This is what I mean. It’s great a great start that you have included the item JSON, but “works” vs “does not work” gives us nothing.
This forum is about communication. Single words or basic phrases do not communicate anything. If we don’t know what “works” and what “does not work” we cannot, even though we would very much like to, help you find a solution.
Please stop writing minimally, and start actually communicating in detail. Start from the top and tell us the complete story, not the summary.
Alright, I’ll start from the beginning.
I have since noticed that the temperatures icons, although dynamically configured, are only displayed in the default design. Item Setting / Model Settings / Location Card
So, I created a Test item to investigate this behavior. First try an item with type Number, this showed the above behavior, but in the Basic UI / Page Layout site (Label Card with setting iconUseState: true) the dynamic icon was displayed with ItemType: Number.
In the Location Card I had other dynamic icons configured. The ItemType were Switch and Dimmer and these changed the design when the state changed. Then I changed the type of the TestItem to Dimmer and then the icon was also updated.
We appreciate that you’re trying here, but something is just not getting through. There is more in this post than any of the previous ones, but still not really the level of detail we’ve been fairly explicit about.
It is clear that you believe that just telling us you’ve done something “standard” is supplying information, but it really isn’t. The problem is that OH is an extremely complex system. It is very easy (and common) even when using the UI to make a mistake when doing something “standard”. You would be surprised how many confusing problems just come down to a typo in a “standard” configuration. You are still just telling us and, no offense, but we can’t take your word for it because we know we all make simple, silly mistakes sometimes. We have to see it to know what’s going on.
Here is one instance of how what you’ve given us is still lacking in a great deal of information. From one single statement, I can produce at least 6 relevant questions you have yet to address:
null state?Dynamic icons are not displayed in some of the areas you list (if I understand your shorthand correctly, again, it’s not really clear). For example, the Item Detail Pane in the Model Page will not have a dynamic icon; it’s just not configured that way. However, it is possible that you have uncovered some part of the system where this isn’t working and if so it’s important that we work through it and figure it out.
Referring back to Rich’s analogy:
We’ve established now that it’s a car, that’s progress. But you’re still just telling the mechanic, “When I drive my car in the standard way that everyone does sometimes it makes a noise.”
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.
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.
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 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 Model 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: []
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.
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. 
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.
