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.
Blockquote
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.
As I wrote, “from my perspective” and I certainly understand that others will have other requirements. As I do not use ZigBee and zwave (mostly KNX) this is not a requirement for me.
Blockquote
Regarding your requirements: You do not even try to find a solution that only involves one source of truth.
Because it is not I requirements for me, and I stated my requirements for the way I use openHAB. Again, others will have other requirements and maybe some day openHAB will not fullfill my requirements any more, as I am probably not part of the majority. I surly hope not, but I would have to accept that. By the way, I could also hand back your remark with “You see only the developer perspective without trying to find s solution, that will fit all use cases”. I am sure, there are possibilities, but probably no easy ones.
I think, wie should discuss this topic, which certainly is an important one, without any subtle animosity. From my experience it is important to first collect all requirements and prioritize and sort them out later, otherwise important input will get lost. I would not drop requirements right from the beginning, just because currently no resolution can be seen.
Maybe we should move this discussion to an other thread, so that it can be seen more easily by others?
I think, wie should discuss this topic, which certainly is an important one, without any subtle animosity. From my experience it is important to first collect all requirements and prioritize and sort them out later, otherwise important input will get lost. I would not drop requirements right from the beginning, just because currently no resolution can be seen.
I don’t believe everything can be seen.
I prefer a system that makes it easy to change later when we discover new things, as we will (and the world will change)
that does not mean we should not have the discussion now.
And yes on the new thread. I know some people can move parts of a discusion to a new forum. Please do that.
From which post would you like it split?
And what title would you like for the new thread?
1 Like
from @David_Graeff post
https://community.openhab.org/t/it-was-fun-while-it-lasted/60210/78?u=yves
title: next generation design : idea’s & discussions
thanks
I see the developer perspective, of course. It is about maintainability, basically.
I have this suggestion, two folded:
Thing files as input
- Use Thing/Item files for a “first-start” input only, by for example copying those files into an “input/” directory.
- Works on start as well as while OH is running.
- OH consumes those input files and removes them on success (every single line could be imported and didn’t cause a conflict) and let them sit there on failure (maybe creating a thing-file.thing.failed log file).
Sync back to Thing files
- Via a command (openHAB console, REST API [Paper UI]) openHAB can store its current state back to Thing/Item files. Via parameters openHAB can be instructed to split Things to multiple files. Comments for Things are restored, global file comments are restored (if a generated file matches an input/ filename).
Would this approach be viable?
The important part is, that Thing/Item files are not viewed as constant definition files like they are now. Every input should go through the openHAB API and stored internally in however openHAB like it do to for performance and conflict-avoidance reasons.
2 Likes
Wasn’t there a mentioning that the current implementation is based on libs that do allow for reading but not for writing back to .things ? It’s an idea I like but it would probably be a pretty large change[addition] possibly noone is willing to take on.
1 Like
For the maintenance standpoint that would be a huge advantage though as Thing/Item file handling is fully decoupled from openHAB.
If at some point it is dropped from the official distribution (and probably made available as external bundle) it can be maintained by all those who see this very valuable for their setup. Could be made available as addon under the “misc” section, and people could even provide similar bundles that write Yaml, XML, MS word documents for Thing/Item inputs/outputs.
1 Like