It isn’t just that it’s slow but it is easy to get stuck with a queue of reloads that can bring just about everything to a halt for hours.
is that pure speed or is that more a memory problem?
It seems to be a CPU problem but I’m not really sure as I don’t run on an RPi and it appears to be mainly a problem on that platform. I believe at least part of the source of the slowdown comes from the Xtend libraries themselves. I do know that use of primitives in Rules will exacerbate the problem for some reason (I have theories but they are unsubstantiated) which would be from the Xtend libraries. But I think there are also some problems with how OH does file polling and reloads as well.
The way people run into trouble is:
- Edit file and save
- OH starts to load and parse all the files, this can take several minutes,.
- Edit and save a file while 2 is still ongoing
- OH queues a new load and parse of all the files to take place once 2 is done.
The edit of a few .rules files can put OH into a loading state for hours if one is not careful.
A work around is to do all your edits “offline” and then move them all over in bulk so there is only one load and parse.
A work around is to do all your edits “offline” and then move them all over in bulk so there is only one load and parse.
By working on my machine and uploading them to a source control system to then download them on my openhab, I’m kind of working that way.
I have an PINE64, which is a little bigger, yet not that much.
indeed starting up takes some time, yet I consider that normal.
yet when I download a changed file, it does not seem that openhab starts to load all files.
Is that true for all files ?
or just rules?
I don’t know. I think just rules. And the more powerful machine may get you past it. I’m on a VM (two cores CPU, 8 gig ram) and my startup time is less than a minute. When I heard that RPi users routinely see load times in the tens of minutes I was very surprised. I would not be surprised is there is something about how the ARM processors on SBCs work that could be a problem. I should note that I only recently added a core to this VM because I plan on running IP Camera stuff on it (up to four cameras). I was seeing similar performance with only one CPU. And it has WAY more RAM than it needs, but I’ve plenty of ram to spare on the host.
1 Like
Rich, that speed statement is in the context of making backward-incompatible changes. I do see strange issues as well, and when the system acts up, the solution is to restart OH. It’s definitely not the proper way to fix it, but IMO this only affects a small set of people making changes on the production machine.
I also believe if we look deeply at the problem, the issue is not because of the slow loading of the xtend rules. It is likely caused by a lock or unsynchronized states. The slow hardware just makes the problem more likely to happen.
No need to apologize. Just because I’ve been around longer does not mean that I’m more important that you are. In my opinion we’re all equal sharing the same goal, we just have different opinions on some things. These different opinions can only make openHAB a better product.
So you don’t count, because you didn’t complain. That’s my point. The people that complain are usually not the ones stepping up and take action. And those that take action usually do not complain because they simply fix what is wrong.
If I read ‘imagine’ as in ‘dream’ then for me that would be a nightmare 
I didn’t understand it that way, but maybe I was put on the wrong foot when David wrote that he wasn’t going to write a JavaScript parser for the current syntax. That to me seemed like the parsing was going to be part of PaperUI-NG, not a separate tool. But maybe he meant to use the parser for syntax highlighting and verification.
Exactly. If I want to support a textual mode in Paper UI with the current .thing / .item syntax, I would need to write a parser for that syntax. And that is a nightmare.
Because this thread is going out of hands a bit (a lot of repetitive comments), does it perhaps make sense to close this as resolved and open another Thread with the same name?
I would then summarise my proposal again, considering all comments. Unfortunately I can’t please Markus @mstormi in my proposal and let the current .thing / .item files stay as they are. XTend really needs to go. Starting up OH shouldn’t take half an hour for a decent setup.
5 Likes
I don’t feel this to be that much of a repetition. No I don’t think that makes sense as it likely won’t change anyone’s position.
I do think that it makes the most sense to wait for @Kai to come up with his view on things as he announced.
3 Likes
He’s not exactly talking about this topic, more about the generell forward direction as some things have changed.
Will still need to find a solution for this particular subject.
Blockquote
Unfortunately I can’t please Markus @mstormi in my proposal and let the current .thing / .item files stay as they are. XTend really needs to go. Starting up OH shouldn’t take half an hour for a decent setup.
I understand the need for removing XTend and I agree with that. I am also not opposed to change the file format, if this has benefits. ( so, not a total die hard old timer and btw. I just finished rewriting all of my rules in Jython). I just prefer having editable files in text format.
I agree with what rlkoshak wrote, some tools for making the migration easier would be needed, as nobody likes spending hours and hours, just to have I system with the exact same functionality as before.
What I would like to understand, just to get a better insight is, why there is such a big dependency between XTend and the current file syntax. Would it not be possible to rewrite the parser using one of the parser generators available? Of course this would leave the problem, that this solution would have to o be maintained by the openHAB developers.
That is possible. The grammar need to be written though. And there is still the problem that there is no tooling for our custom syntax. xTend is not the only problem. There is no file writer existing for exporting the internal openHAB state back to files. And if you read through the forum you will find especially newcomers to struggle with the syntax. It is not structured enough, to be honest. But you will find all of this discussed in this thread already.
I am completely new to OpenHAB, just installed a week ago. I tried to use PaperUI for about 2 hours, before I gave up on it and switched to edit files in /etc/openhab2 - not just because I have to use some v1 bindings, but because of the amount of clicks/interactions needed to add things/items and the fact that it does store the created objects in a different location than /etc.
If there was an editor in the browser UI which is editing the files in /etc, that supports syntax highlighting and is showing contextual help for the type of object I am currently editing, so I don’t have to open a browser window next to it, I would use it.
1 Like
It’s really Xtext I think which is the base language parser that is used to define the syntax for both. In short, we currently have the exact situation you describe with Xtext being the parser generator that was used for the config files. Xtend is a programming language whose parser was also generated using Xtext.
So moving to some other parser generator doesn’t really improve things all that much because we are still on the hook to maintain a custom grammar and reliant on a single source for the parser generator libraries.
And the parser generator only gives you half of the problem (reading). We still need to be able to write in order to have a migration path between text and UI configs.
In short, IMHO, moving to some other parser generator will be a lot of work for very little long term benefit.
Though I’m only halfway through the thread, as a user since 1.5, I would prefer a GUI solution. I’m on board with your solution.
When Paper UI arrived i started to use GUI for both things and items.
After a while i went back to text files depending on that i had to recreate many things when i updated different bindings- When i use text files i do not have to recreate things when updating.
I we can solve that issue i think it is best for general users (the ones that is not daily here 
) to use gui for configuration.
/Mike
1 Like
Yes that’s a known issue in the core that hopefully is resolved some day. In the meantime a simple “Recreate that Thing” action in the openhab-cli or via GUI would already be helpful.
1 Like
+1 yes would be really helpfull 
And perhaps (should be easy if the other thing can be done) „change thing type“.
Aren’t comments an issue with JSON currently? Does yaml allow comments?