I’m making a few changes. Feel free to reverse any of them.
I think we should avoid too much comparison of OH 3 to OH 2 in the core documents like these. There will be a growing number of users whose first exposure to OH is going to be through OH 3 and calling back to OH 2 to help explain core concepts may add to their confusion rather than add clarity. I would hope that those who are proficient in OH 2 would recognize when there are similarities or minor differences.
We could also create a migration tutorial again and centralize all those subtle differences in one place that a new user to OH 3 would never look at.
It’s always hardest to write the first draft. It’s a good document. I’ve inserted a couple of notes/comments above inline.
Mainly, I’m not sure how to put it all together in the first section. Maybe a comprehensive example would help showing a UI with a bunch of elements and the YAML that generates it would help.
I’ve a question at the end of section 2 regarding what you meant by “does not have access to the file”. If I understand correctly maybe it would be more clear to write the sentence as
Note that this doesn’t prevent writing them in files with the dedicated syntax [add link to sitemap docs] but any sitemap defined in a .sitemap file will note appear in the main UI and can only be edited through changes to the .sitemap file itself.
I understand, as mentioned it’s a overall view of the general concept which is all-important for what’s coming - all this is allowed because of a generic API is now available for UIs to store their stuff, really. And since that component structure will be encountered everywhere when editing page-related things in “code view” I thought it might be valuable to describe it first - maybe at the risk of putting off some users, that could be an issue for sure, I agree.
Yes indeed, in openHAB there are “sitemap providers”, there was the one which provided a thing-oriented “_default” sitemap in OH2; this one has been removed AFAIK, but there’s still the provider parsing .sitemap files and now there’s the “managed” UI components one. The resulting set from all sitemap providers is fed to the clients as one unified set; but a sitemap from one provider can’t be changed by another provider, in other words, you cannot change your file-based sitemaps from the UI, or the other way around (unless you edit the JSON DB).
Not with native controls, but I’m sure the Android app will be able to show the UI (like it does with HABPanel) eventually. It works good enough as a web app, and you can already add it to the home screen and run it fullscreen.
And furthermore its possible to change the command that rollershutter widget send?
The widget send the command DOWN , I want send command close instead
The rollershutter control is little more than segmented buttons but tailored to control a standard Rollershutter item, if you have a different situation it’s likely possible to reproduce its functionality in a custom widget using f7-segmented and f7-button with your specific commands.
What string i should insert into icon fileds if i want to use icon in icon/classic folder?
The same for floorplan images, it works if I put an external url, but if I insert localhost/image.png it doesn’t show nothing (standard missing image icon)
What is the url for local file?
And how to show different color for icon based on item values? The example in expression doesn’t work in standard widgets
@livio You should be able to access local icons (…/openhab/icons/classic/) by using the ‘oh-icon’ component with the config parameter ‘icon: YOURICON’.
There is currently no option to change the icon color (for local icons) with styling params like ‘color:’ AFAIK (at least, not for the oh-icon component) - I think it has something to do with the fact that icons gets imported as images and not as a font (like the f7-icons do).
But you could use ‘filter:’ as a style to trick a bit (with good support for the most browsers)
Here is a great Codepen, which should help you, finding the correct filters to apply to set your desired color.
For example, setting your icon color to red (#ff0000):
To show/hide the respective icon based on the item state it should be possible to do that with the visible param… e.g.: ‘visible: =items[props.item].state === “OFF”’
This Is clear that the new UI does not allow editing an existing sitemap. But does it at least allow rendering such a sitemap so that we can control our home in the new main UI as before without a full redesign?
Of course, we have still the old UIs and this will not not be a full break even if control of existing sitemap not possible in the new main UI could be very deceiving for most of users in a first time.
Yes, it’s still undecided. The way things are now, you have a single implementation of a sitemap renderer for each platform: native apps for iOS and Android, and Basic UI for the web. If the main UI offers its implementation as well, and the mobile apps can show that UI (it’s planned), then you would have 2 implementations (a web-based in the main UI and the current native controls) on mobile, and 2 web implementations. So I guess it could become a bit confusing again… And there’s still a lot of work in other areas so even when it’s deemed necessary I don’t really consider it a priority. That can be discussed though.
