Hm, afaik it writes periodically (every 5 mins or so?) and on Thing changes it accumulates for a bit and then writes as well. But Thing properties are changed quite often (at least I’m doing that in my bindings to visualise state that would get lost in the log).
Next Gen Rules Engine.
I have been avoiding it for now, for two reasons.
-
I understood it was not ready fro prime tiùe
-
so far, I can do everything I want with the current rules.
Yes the language takes some use, yet I think it’s also easier to understand for non programmers.
Better testing for rules would be usefull
OH1 bindings
I have +20 anel hut’s in my house. Very happy with the devices (and would not be able to replace them now) yet it seems that the original developer has lost interest (or at least has no interest in moving it to openhab 2.)
I don’t know enough java to do more then look at the code and spot some small errors.
The (old) XTend rule engine is slower and more resource intensive then the new one.
I mean there is a reason why there is a new one, right 
1 Like
You don’t understand. For a reliable system configuration need to be pulled from one source of truth.
That I understand very well. That was already taking into my consideration.
Like I said , I don’t have paperUI install, that is one of the reasons
I’m using only the text files as way to change the system.
nothing else, because I want only one truth
JSON as a format don’t need to stay. It can also be yaml or xml. Doesn’t matter for the backend. But it need to be machine readable on start-up
And the current files do just that. except from what I understand, OH developers don’t want to keep that format
(and I have no objection to that, I never had.)
Not necessarily paper UI.
Like I said in most of the discussion I felt pushed for paperUI, not for the json and I think this is the second time someone mentions REST api
(REST has it’s own version problems if I remember correctly some of the discussion we had a few months ago at a client)
openHAB has a service called “Configuration Admin” that reads all .cfg files in and stores its state periodically
when I change a cfg file, it seems to be reflected almost instantly in openhab.
The (old) XTend rule engine is slower and more resource intensive then the new one.
I mean there is a reason why there is a new one, right
Usually by the time new software is finished that is faster, the hardware has improved faster.
Yup there is a file watcher installed, that reads a modified file again.
You cut off my sentence, how rude 
The second part was important. It need to be writable as well. There is no code in openHAB to write to those custom syntax thing files. But how should OH persist Thing changes then (like auto discovered Things or Thing property changes caused by bindings).
Since we sort of doing a survey on the potential of taking away the advance usage scenarios, I’d like to chip in another voice to retain the ability to hand-craft the .things file. It gives advance users lots of control on how to configure things without having to touch the UI. As other has said, the .things file can be checked in version control.
All my devices/services are configured manually. The only things not possible yet are the ZWave devices; @chris thank you for all the hardwork you put into the binding, is this function possible yet? I imagine if we can configure the .things file manually, the move from 2.3 to 2.4 woudn’t have required user to re-add all the items.
If it does write the jsondb on a schedule then we do have a problem. But why would it do that? I don’t see the point. It’s not creating a backup for all of those writes. It Durant make sense to me to dump to the file when nothing has changed. It just increases the likelihood of a write failing and corrupting the files.
I don’t see how the benefits or weight the risks.
It sure seems reasonable to cache up a bunch of changes before dumping then to file. There is a small risk of losing a change in a power failure but I’m sure the backup and write of the file is expensive.
This cannot be emphasized enough. OH users on an RPi can see rules file load times in the tens of minutes to over an hour. And the problem compounds of you change a file while it’s still loading from a previous file the changes get queued up and the RPi and OH can be brought to its knees for hours.
The faster and with less resources issue isn’t just a nice to have upgrade. It’s a very significant problem for a large portion of OH users. A problem that must be fixed.
And if I understand correctly, the problem lies in code we don’t own so a fix is not necessarily under our control.
In general the developers of OH have really good reasons for decisions to make charges like these.
I don’t think we are talking about that at all. I think we are talking about keeping the advanced usage scenarios while also:
- unifying, or maybe normalizing the configs is a better term
- providing a way to trasition beginner users who start in the UIs to what Yves is calling “the expert UI”, i.e. something programmers would be more interested in
- providing a config format that can be both read and written by OH
The .things file cannot remain as it is. We are talking about ways to support something the ability to hand craft Things (I still don’t see the attraction personally).
And once again. JSONDB IS A TEXT FILE. You can check it into source control. I do this now.
No, it would have just required you to go and manually change all your Things instead of letting the software do that for you with autodiscovery. If I understand correctly, you had to remove and readd the Things because the new binding requires more or different fields than the old one did.
1 Like
Yes - this is possible with ZWave in 2.4.
Even if we now have automatic discovery with OpenHAB 2, I still like to do it manually. I once used network item auto discovery and what happened? It hardcoded the devices IP addresses - worst way to do it, because they will change. I’d rather like to use hostnames, and that’s what I (only?) can do manually, so I stick to manual configuration. Just as one example, it’s the details that matter
1 Like
Only if “we” excludes the ESH developers. See major reprocessing on items addition · Issue #6410 · eclipse-archived/smarthome · GitHub for a premature analysis. I’m waiting for @kai to jump the bandwagon. Yes it’s a severe problem.
108 messages multiplied by an average of 10 minutes reaction time is around 1080 minutes or the equivalent of 18 hours. A lot of additional documentation, improvements and PRs could have been created. Just imagine …
2 Likes
In one way yes, in other way there are two ways to do things, e.g. for the MQTT binding. There is mqtt1 and there is mqtt v2
If it wouldn’t be so much error prone work to switch between both bindings, I would switch immediately. (Read as: Give me a tool that changes my Items configuration, and I will use that).
I have seen that with Abseil philosophy, they have two principles:
- If your code behaves according to our compatibility guidelines, it shouldn’t break in the face of our changes.
- If we need to refactor an API that you depend on, we will provide a tool that should be able to perform the refactoring for well-behaved code.
Yeah I know, there’s a large company (Google) behind that project, and yeah, having this philosophy will create additional work in development.
1 Like
Thank you, appreciated!!
It’s not, I use both seamlessly.
The only breaking change is the MQTT action
To be more precise: It is error-prone to misstyping and syntax errors to edit all my items and config to use the new binding. That’s a thing a computer could doe much faster and much better than me.
OpenHAB itself works well there
1 Like
@ rlkoshak
juelicher:
Editing text files can be done, when needed (in fact, just today), using ssh and e.g. joe from my phone, where screen size would probably be to small for a full grown web interface
To repeat what David said, JSONDB is a text file. You can do all of this with it.
My reply was intended to answer this question from David_Graeff: " Imagine you have a Paper UI that does allow you to edit Things/Items in a textual way (so you have view mode “List” and “Text”). Copy&Paste works. Automatic validation before submitting is included. Auto-completion… maybe works as well.Would you still edit files on disk, and why would you do that?"
To be more precise my requirements would be as following:
-
Plain text format, UTF8 encoded
-
Human readable and human editable.
-
I know, that this is a soft requirement. But it implies, that the structure is not to fancy, that there are some whitespaces to make it readable but not too much as to make it confusing. Identifier should have meaningful names, e.g. not using a GUID as identifier name
-
Must not oppose editing with sed/awk and other tools
-
Again a soft requirement. But e.g a file format with a lot and a variable number of lines or changing line order would make it more difficult than necessary
-
There should be the possibility of line and block comments. On one side for documentation the file, on the other hand for temporary disabling parts of the file.
-
There should be the possibility to have more than one file and to structure its contents logically. File names should describe the contents. E.g. I have, beside others, a knx.things and a hue.things, which is a lot better than 91a93ede-313d-4b46-ab5d-902bf208c853.db
-
When removing a file, the contents of this file should be temporary disabled. By restoring it, its contents should be restored (e.g. for testing)
-
The files should not oppose being managed in a source control system. So small changes in the configuration should only result in small changes in the file. The files must maintain the order of its contents on saving the file, so that they can be “diffed” against older versions
-
It should be possible to (partly) copy files from one openHAB instance to another, e.g. for testing. So no “hard binding”, e.g. a machine identifier, to the machine it is running on, except storing the files in the right place
Json may or may not be the right format for this. This depends on how the actual data is logically and physically written to the file and of course there are a lot of other requirements for the file format from the developer perspective.
For some reason I am a bit skeptical if Json is really the right choice:
- The order of items is not definied and may vary when saving the file, as I had to learn myself. Even when the order is maintained in one version of openHAB it may change when using a new version of the Json library or an other Library
- I have seen Json files, that had such an awkward structure, that it was nearly impossible for a human to understand and edit it. This would be a question of how the data structures are definied.
An other topic would be the migration of the existing configuration to the new format.
This is something I’ve been fighting for months. I think a bunch of old timers are remembering all the pain there was for a few months back in the day when we were using MapDB instead of JSONDB, and MapDB was slow, stored everything in an opaque binary blob, and became corrupted easily. When MapDB was replaced with JSONDB to fix these problems and address the concerns that many of us had, myself include, to keep a history of changes in source control and have the ability to edit them by hand. But people still see those old postings and old timers still think that we have MapDB running all of this stuff and make statements that are not true.
Yes and no. There are these concerns regarding PaperUI edits in the back of my brain. But on the other hand text file editing works very well for me. So I see no need to learn how to properly use the Paper UI for advanced tasks. A concern for me, when using PaperUI for changing the configuration, would be, that I can not really grasp what happens “under the hood”, whereas this is completely clear when using text files e.g. for linking items to channels.
Editing text files can be done, when needed (in fact, just today), using ssh and e.g. joe from my phone, where screen size would probably be to small for a full grown web interface
To repeat what David said, JSONDB is a text file. You can do all of this with it.
My reply was intended to answer this question from David_Graeff: " Imagine you have a Paper UI that does allow you to edit Things/Items in a textual way (so you have view mode “List” and “Text”). Copy&Paste works. Automatic validation before submitting is included. Auto-completion… maybe works as well.Would you still edit files on disk, and why would you do that?"
To be more precise my requirements would be as following:
-
Plain text format, UTF8 encoded
-
Human readable and human editable.
I know, that this is a soft requirement. But it implies, that the structure is not to fancy, that there are some whitespaces to make it readable but not too much as to make it confusing. Identifier should have meaningful names, e.g. not using a GUID as identifier name -
Editable with the text editor of choice.
I use joe over an ssh connection a lot to make small changes to my configuration. Using a browser based editor would very practicable from my mobile phone. -
Must not oppose editing with sed/awk and other tools
Again a soft requirement. But e.g a file format with a lot and a variable number of lines or changing line order would make it more difficult than necessary -
There should be the possibility of line and block comments. On one side for documentation the file, on the other hand for temporary disabling parts of the file.
-
There should be the possibility to have more than one file and to structure its contents logically. File names should describe the contents. E.g. I have, beside others, a knx.things and a hue.things, which is a lot better than 91a93ede-313d-4b46-ab5d-902bf208c853.db
-
When removing a file, the contents of this file should be temporary disabled. By restoring it, its contents should be restored (e.g. for testing)
-
The files should not oppose being managed in a source control system. So small changes in the configuration should only result in small changes in the file. The files must maintain the order of its contents on saving the file, so that they can be “diffed” against older versions
-
It should be possible to (partly) copy files from one openHAB instance to another, e.g. for testing. So no “hard binding”, e.g. a machine identifier, to the machine it is running on, except storing the files in the right place
I certainly know, that probably not all of these requirements can be fulfilled. To set a priority, text editor based editing and source code control are a must for me, with all the implications this may have.
Json may or may not be the right format for this. This depends on how the actual data is logically and physically written to the file and of course there are a lot of other requirements for the file format from the developer perspective.
For some reason I am a bit skeptical if Json is really the right choice:
- The order of items is not definied and may vary when saving the file, as I had to learn myself. Even when the order is maintained in one version of openHAB it may change when using a new version of the Json library or an other Library
- I have seen Json files, that had such an awkward structure, that it was nearly impossible for a human to understand and edit it. This would be a question of how the data structures are definied.
An other topic would be the migration of the existing configuration to the new format.
This is something I’ve been fighting for months. I think a bunch of old timers are remembering all the pain there was for a few months back in the day when we were using MapDB instead of JSONDB, and MapDB was slow, stored everything in an opaque binary blob, and became corrupted easily. When MapDB was replaced with JSONDB to fix these problems and address the concerns that many of us had, myself include, to keep a history of changes in source control and have the ability to edit them by hand. But people still see those old postings and old timers still think that we have MapDB running all of this stuff and make statements that are not true.
Yes and no. There are these concerns regarding PaperUI edits in the back of my brain. But on the other hand text file editing works very well for me. So I see no need to learn how to properly use the Paper UI for advanced tasks. A concern for me, when using PaperUI for changing the configuration, would be, that I can not really grasp what happens “under the hood”, whereas this is completely clear when using text files e.g. for linking items to channels.
If you want to use the “expert ui” version of it now, it’s JSR223 Rules.
Which, for an advanced user, I can really recommend trying out!
So how much effort is necessary and worth it to solve the file locking problem? It would only be a problem is there is more than one user administering OH at the same time in two different ways. Is this a common occurrence?
For my use case it would be no problem to lock the database for writing when doing manual edits, as I am the only person in my household who would edit the openHAB configuration. What I would not want to loose is the ability to change the configuration in a running openHAB instance without restarting openHAB.
Even if we now have automatic discovery with OpenHAB 2, I still like to do it manually. I once used network item auto discovery and what happened? It hardcoded the devices IP addresses - worst way to do it, because they will change. I’d rather like to use hostnames, and that’s what I (only?) can do manually, so I stick to manual configuration. Just as one example, it’s the details that matter
Same here, I never ever used auto discovery and I do not see, why I should. From my perspective this feature could be removed immediately, but I certainly see the advantages for new users. So this would not be an option!
3 Likes
You are a true openHAB 1 user ^^. Nothing bad about it, but I wonder how you handle a ZigBee or zwave network with a hundred devices without auto discovery.
Regarding your requirements: You do not even try to find a solution that only involves one source of truth. Your requirements are contractionary to that goal. If we use a file format that matches most of your requirements and allow openHAB to sync its internal state to it (yes openHAB WILL change your things, no discussion about this), you also have Thing definitions moving around, removed or moved comments, and different layout overall. A machine stores different than humans, that’s how it is.
I wonder how you handle a ZigBee or zwave network with a hundred devices without auto discovery.
I don’t use zigbee or zwave.
I have about 20 Anel hut, that is 20 * 8 buttons like and 20* 8 controls, all manual configured.
A lot of work, yes, yet completly under the control of our family.
You do not even try to find a solution that only involves one source of truth. Your requirements are contractionary to that goal.
I disagree.
Hard to do with one single truth , yes.
you also have Thing definitions moving around, removed or moved comments, and different layout overall. A machine stores different than humans, that’s how it is.
I disagree, programmers make the decisions in what order things are stored.
F ex You can add an order ID. if that is needed.