I just tried pasting in my old sitemap and it worked after I took out all my comments I had in it.
The new UI version of sitemap doesn’t seem to like // as a comment.
It also didn’t like spaces after the = sign like this Frame label= “Power”
Fixed up the errors and all good.
Other than that it worked fine.
Bonus is it does syntax checking of the sitemap.
I probably still won’t use it but you never know. 
1 Like
This is a general problem with YAML files…
Can you put comments into the yaml file? If so how?
Not as far as I know.
The issue isn’t with YAML files. YAML supports comments with #. But YAML in OH is just a representation in the UI of the JSON format send/received through the OH REST API. And that does not support comments. OH does not store comments in its managed json database and has no mechanism to accept comments.
I could probably add logic in OH to ignore // in sitemap text copied in to avoid having to delete them manually. The comment would be lost after saving and moving away from the code page.
Create an issue in the webui repository for this, so it is not forgotten. I can see if I can fix this.
2 Likes
Sorry, and thanks adding more info.
There was a workaround somewhere whitin the widget topics, where “unsupported” components have been used for adding comments.
the new ui cannot display/render sitemaps at the moment anyway…
I am also using only a BasicUI sitemap. It is also just good enough. The thing is that the benefit I am getting and using from openHAB is much more the automation that comes from rules than interacting with an UI. Additionally, the rest of the family doesn’t even know how to access the sitemap or any other UI.
1 Like
I’m using mostly basic UI too, because it is a combination of manual defined ui, plus some kind of automatic structured one, if you use groups.
I have to handle 869 items and this makes it some kind of difficult to design everything with widgets.
That’s because you are building a sitemap. It’s just a UI front end to build a sitemap. Anything you build here will only be displayable in BasicUI and the phone apps.
That’s not how you build a MainUI Page. Building a MainUI page looks like:
where you have masonary, columns, rows, blocks, cells, and widgets. Here is my list of usable widgets:
It looks complicated but it really isn’t. The masonry, columns, and blocks is just a way to create a space for a widget to live and the only reason my list of widgets is so long is because I have a lot of custom ones.
If all you are talking about is importing a .sitemap file to convert it from being file based to being managed, that’s a good idea. But it’s not going to eliminate the need for BasicUI.
You are still building a sitemap.
Excellent feature and good to know. I wish it were more consistent with “create Item from text definition” but it’s better than nothing.
The work around is to add new elements to the yaml to represent the comments. Something along the lines of
component: oh-repeater
config:
filter: Number.parseFloat(items[loop.item.name].state) <= props.max
for: item
fragment: true
groupItem: =props.minLevel
sourceType: itemsInGroup
slots:
default:
- component: oh-list-item
config:
comment: "This is a comment"
badge: "=(items[loop.item.name].displayState === undefined) ? loop.item.state :
items[loop.item.name].displayState"
comment: "This is another comment"
badgeColor: '=(Number.parseFloat(loop.item.state) > props.green) ? "green" :
(Number.parseFloat(loop.item.state) > props.orange) ? "orange" :
"red"'
icon: '=(Number.parseFloat(loop.item.state) > props.green) ? "f7:battery_100" :
(Number.parseFloat(loop.item.state) > props.orange) ? "f7:battery_25"
: "f7:battery_0"'
iconColor: '=(Number.parseFloat(loop.item.state) > props.green) ? "green" :
(Number.parseFloat(loop.item.state) > props.orange) ? "orange" :
"red"'
item: =loop.item.name
title: =loop.item.label
The trick is that MainUI doesn’t pay attention to fields it’s not expecting to be there so if you add fields they will be ignored. It’s not ideal but better than nothing at all. I don’t know if this works universally or just for UI widgets.
@Mherwege, if there were a way to preserve the comments instead of silently removing them I think that would be awesome!
That’s why the semantic model was used as a means to build the overview page.
yes, I’m aware the differences between mainui overview and sitemap, i have build semantic model and built an overview page.
i was just asking can I import my old sitemap here in this GUI so i dont have it in the files, but manage from here, and that question was answered, yes it can be copy pasted so great.
now i have a problem that my overview page works only on local network on android app, or via vpn, but via reverse proxy its just a blank page.
it also works via web browser both inside and outside of network.
So i will have to stick with basicui sitemap for now, as that works both inside and outside via OH app on android
Please file an issue on the Android app. How to file an Issue. It should work and the last time I tried it worked for me (I’m pretty much always connected via tailscale when not at home) but I have seen that behavior on rare occasion. I was never in a position to file an issue at the times I’ve encountered the problem.
Yes, agree. There are too many slightly different ways in MainUI to get text definitions of settings in:
- Items:
explicit import function for items
copy in text definitions generates the items, channels and metadata, only import
code tab shows YAML - Sitemaps:
ability to copy textual definition into code tab
switching to code tab shows textual definition and JSON, no YAML
textual definition is generated from UI definition - Things:
no import possible
code tab shows YAML - Transformations:
only show textual definition of transformation, format the same is in file definitions
no code tab - Persistence:
no import of textual definitions
code tab shows YAML
persistence strategies defined in text files are visible read only in code tab as YAML, and can be copied in the code tab to create pure UI definitions (open the persistence definition, copy the YAML, remove the persistence file for the persistence service and create the persistence strategy for the service in the UI, copying in the YAML)
This is something that may be candidate for some standardization also in the context of RFC: YAML configuration · Issue #3666 · openhab/openhab-core · GitHub.
interesting that in demo mode everything works, I can even see those bottom tabs, and obviously I am accessing it from outside network, I dont know the configuration of the demo cloud, so not sure if they use reverse proxy.
1 Like
I’m kind of hoping the same. If that issue gets some traction it’s a great opportunity towards normalizing all this stuff and scratching a few other itches as well.
I didn’t know about the persistence strategy trick. I tried to recreate mine through the UI and messed something up. This can help me figure out if the problem was mine or there is a bug.
Here, I’m using MainUI for configuration and usage on a PC based web browser, but sitemap in the Android app as I find it leaner to display and easier to setup.
I started developing a persistence strategy textual definition import. These parsers are highly complex, and while I could probably finish it, I concluded it is probably not worth the effort at this time. It generates quite a bit of maintenance effort.
As an examle, sitemap definitions have evolved, and each time, it needs to be added in Java code in core: the XText parser, the REST API for using the sitemap, the REST API for creating managed sitemaps. In the webui repository the parser also has to be change in sync with the XText parser. And for sitemaps, also the text definition builder code in the webui needs to be adapted. XText and the parser in javascript (nearly lexer) for the UI have their own and different ideosyncrancies, making the whole thing a lot of effort to maintain.
While the effort for sitemaps is worth it for me, I am reluctant to start doing it for other things beyond what is there. I hope a common YAML format will make this easier. Ideally it would show all unmanaged artifacts read only as YAML with an option to save to managed (could be called import as managed or something like that also). That would allow removal of all specific textual import and generation code from the UI, very much simplifying things.
Why not use xtext itself to parse it. If you don’t want to drag the xtext dependency in, maybe have a rest endpoint for parsers?
As far as I can tell, validation could be done using an xtext servlet. But it still does not solve the issue of persisting. At the moment, the xtext parser in core creates objects in memory from the parsed xtext. These objects are not stored in the jsondb. There is no persistence implemented in all of the xtext code in core.
To persist in the jsondb, it is required not only to validate, but also to interpret and transform into json objects for the REST API calls, that then get stored in the jsondb. That’s what nearly is currently doing. And validation happens in the same step anyway.
Other choices could have been made, but with the current state, I think it is a massive change to implement persistence with xtext in core. I have the feeling not many people are ready to do much but a few maintenance adjustments in the xtext code and dsl’s. Having file formats in YAML, that is easily translateable to json and the inverse, would offer an opportunity to eliminate the nearly parsers from the UI and could, in the far future maybe, eliminate the xtext code from core. I see that as strategy and solution that is easier to maintain in the long run.