I would like to have the ability to give some more “design”-power to Items
The reason is explained basically here:
If one has a well designed Group structure, he/she can design a structured sitemap with only a few lines.
But it gets difficult, when you want some more than just the default item representation in your sitemap.
A good example for this is a temperature control with a setpoint-sitemap-type.
If i am fine with my group based sitemap and want to add control to my thermostat, if have no other chance than to write the group sitemap definition completely by hand.
It would be nice to have something like (just a rough concept idea):
Which then would override the number peresentation with a setpoint presentation within my sitemap.
This would keep the Sitemap definition flat and you wouldn’t have to maintain the sitemap file, when something changes in the items that are connected through this group.
HabPanel, as suggested in the thread linked above,
can’t (and shouldn’t) be the only solution for things that are not possible with items/sitemaps currently.
I like the idea but really don’t like putting that config in the binding/channel link part of the Item definition.
Since we can define the icon and the label on the Item there really isn’t any good argument for consistency why we shouldn’t also be able to define the sitemap element that the Item should use by default so when we put it on the sitemap using Group or put it on the sitemap using Default we have a bit more control.
But, unfortunately, this would only be a partial solution because we still can’t control the order the Items appear on the sitemap.
When I have a technical issue with something not running as expected it is in most cases not related to the UI itself. And I think the approach to have administrational stuff splited from the regular use interface is good and IMO the one and only (i.e. Joomla is doing the same).
I would be even very happy if the customizing of openHAB UI would be more easy. Currently it’s more a nightmare than simply done. Even with longtime experience in IT, unix, scripting aso.
I currently work on my LCARS based approach of an interface (if I find time), but I still don’t have a working environment that is far enough to say it’s an alpha. The design itself is more or less ready, but only using PHP and REST which is not the road that I would like to go.
I think that it handled with the bullet point “Update Thing definitions automatically”. Duplicates shouldn’t be possible anymore. OH 2.3 introduced a way to prevent it, but the binding does need to support this feature.
I like to close this open discussion at this point. I have read through all comments, and although some issues are annoying, they are more UI and usability related than core issues.
Personally I also think that it is harder than necessary to contribute to the web UIs like PaperUI and classic UI. But that is another discussion.
I will now assign each problem to the relevant GitHub issues or create Issues if required. Those problems might be perfect matches for the Hackathon that might happen in the near future:
Before fully closing, it would be awesome to provide the links to the issues opened to make them easier to find. Never mind. I should have re looked at the OP. They are all there.
I reviewed all the comments here and would like to add my 5 cents to overall discussion. I fairly new to the software so many things are not intuitive for me. I have been testing software for over 10 years in my professional carrier so I think I have “some experience” in describing basic feel.
starting point installation
simple on raspberry
(with asterix) - I haven’t heard about xz compression - image in zip/7z/tar would be far more intuitive for beginner
link to what is that one should be added (I went to wiki)
first setup
basic UI/paper UI/habmin
like it was said earlier there is way to many of those UI that creates confusion
at first I didn’t knew where to start - what is home builder - why do I need it?
where is the starting point
paperUI vs .items files
again some tutorials state about creation of items files another about paperUI things/items - another confusion
what is the default pick for user - when should I pick paper vs items
paperUI doesn’t support groups? or I couldn’t figure it out on my own without spending too much time on it
how to create virtual thing ? - like switch (combobox) to control multiple things at once
paperUI “cleanup” - deleting thing should delete items if those are not used in any other place - I had to clean up everything manually and it was pain having 8 z-wave things with 9 items (72 items)
group items by parent or don’t reload filter on deletion - I want to modify node3 configurations if I remember correctly filter was cleared
smaller openHab releases or thing releases (micro components?)
my Eurotronic Spirit thermostat was properly supported in snapshot version this is only reason I had to pick it
few days after installation and initial configuration I updated it - just to be noticed that z-wave binding was redesigned and I should start configuration from scratch
I can only confirm to something that was said this should be done in automatic fashion - you shouldn’t break things or provide way to smoothly migrate
paperUI simple bindings vs manual bindings
the automatic naming convention is afoul - who will know that zwave_device_512_node5_switch_dimmer is the one in living room?
the “manual” creator takes the name of the thing and creates something like LivingRoomThermostatNode5_Dimmer based on my name LivingRoom:Thermostat:Node5 there should be at least thing prefix in the automatic bindings
the naming convention could take thing
type:Thermostatic Valve,
prefix: LivingRoom,
zwave_nodeid:5,
once the simple binding is created and you would like to edit it - some of the properties doesn’t show up I don’t know why
Enforce auto update - I think that this helps in propagating thing properties - how to enable that one in simple mode?
rules for beginner
as a newcomer I used experimental rules engine
it needs to support sending multiple commands in one rule in easier way
writing the script for each one of the rules is not intuitive
because the z-wave binding and all the changes between snapshot versions I had to create all the things from scratch
in the first attempt I used manual items creation in second simple binding
the naming convention is different so all the rules stopped to work
this caused that I switched to file based approach where changing the name of the item is way easier
checkbox button next to item/rule/thing - and then delete all checked would be nice feature
Sorry to ‘bark back’ but I think to quite some extent your experiences are because you did not properly invest enough into reading the docs and understanding OH concepts before you started.
First, please stay on topic. This thread is not on OH in general but on the core framework. That has got nothing to do with server setup or even general computer or home automation education.
Check out this page of the docs. Did you ever even get to see that ?
Granted there’s always room for improvement but it’s challenging to keep docs consistent and up to date with development.
Show me any SW that is as flexible and still as well documented as OH, let alone open source ones.
That’s a little bit of unlucky timing, but since you were using snapshots this means you should have been prepared for that to happen. Plus your approach was too risky, why did you go for snapshots as a beginner?
Every once in a while, there’s breaking changes in every SW, so it cannot be avoided altogether.
OH cannot know about semantics. It’s as good as it can get without additional input from your side.
Note names can easily be changed and it’s a user’s task anyway (not OH’s) to get that right. It isn’t part of the OH core either.
That’s as if you wanted some programming language to automatically create names of your variables.
Now read that statement again please and tell me what you think yourself where the error was…
Thank you for participating, but you missed the point of this thread. It is meant for making the core better, not usability problems that we clearly still have in OH. But home automation is something that doesn’t have conventions yet that we can build on. Imagine you hand someone a car who hasn’t seen a car before in his life. We take a lot granted, because we are used to it, but for home automation you need to read documentation first.
Sorry to ‘bark back’ but I think to quite some extent your experiences are because you did not properly invest enough into reading the docs and understanding OH concepts before you started.
No offense taken. I suppose this thread is for discussion purposes. All in all I think you are doing great job if I think that everything here is for free.
This is exactly my point. How much time do I need to invest in order to understand basic concept of openHab. In today’s word applications are written to be easily picked up. Just like OH application on Android. It automatically discovered my instance and showed things - that was suberb! Before I picked openHab I looked at Vera/Fibaro/Domoticz. OH seemed to be most promising when it comes to support of new things.
In the same time I think that all competitors have one UI for configuring everything.
You pointed me to documentation that is creating confusion. There are 5 columns describing 5 different approaches. What is the future? Where should I invest my time in configuration? Will the .items files be migrated to jsondb and marked as depreciated? This is my point - provide guidance for newbies like me what should I pick or pick it for me because I’m newbie.
There is stated “Do not autocreate Items” while in some places in the forum I read - “I don’t understand why people aren’t using simple binding”
Everything around ease of configuration (things/bindings) should be in core of the system. I don’t even know “PaperUI” is core or it’s only “Textual Configuration”?
Plus your approach was too risky, why did you go for snapshots as a beginner?
“Winter is coming” - I suppose multiple users will come here for “simple” automation of the heaters. On forum of my housing estate community multiple people were asking “have anyone has experience with heater automation” and they are buying danfoss/bluettooth devices to control it. I came here for same reason. Problem was like I stated - proper support of my device is only in snapshot version. I used nightly builds a lot on early android devices and right now I cured out of it - I want simple stability.
Now read that statement again please and tell me what you think yourself where the error was…
Again going back to question what is OH future. I hoped that new rules will be something that I might use when stable version will come out. I immediately thought that migrating from rules files to json will be paintfull. I’m not long here so it’s hard to asses what Experimental means sometimes:
not everything is working but we are getting it done
or
this might be rewritten few times till we make it working - don’t use it for core automation
Looking at it from time perspective for sure was my bad choice.
It is meant for making the core better, not usability problems that we clearly still have in OH
Isn’t usability also core of the system? Imagine using Linux with lynx instead of “proper” browser. If that’s not the case then for sure I don’t what core you had in mind. Especially when in the first post I clearly see Logview/Notifications about errors/multi user support. For me those are clearly usability items.
One of the applications I heard in my company was named superb app but what was killing it was hundreds of small issues that at the end was killing user experience.
home automation is something that doesn’t have conventions yet that we can build on
I disagree - some of you do it for over 4 years - that is plenty of time. You have ton of experience how to do certain tasks and what is improper way of doing things.
Imagine that I came to openHab install it to SD card and I’m asked what do you want to do? Heating automation → discovery process - what is your heater ? → how you would like to set up heating hours? Now wait few seconds I’m doing it for you.
For me core would be template engine of such story. Thing/bindings/rules. Everything out of the box > now when I need to modify it for sure I need to learn way less pieces of system at once but I can assume that it was done properly by engine out of the box.
Enough from me - I just hope some of those will be addressed in future so new comers will have easier start.
Because home automation is a complex matter and that requires a complex system to handle that matter well.
OH is as simple as it can get because it is the most flexible of all of them, to cover so many potential use cases, and that is very much intentional and way more important to attract people and make them happy with it in the long run than to save some 10s of minutes on reading docs, but seems you didn’t get that point.
OH is meant to work for a large number of users of different knowledge level. It is your own job to invest the time it takes to find out how a config and ruleset would need to look like that matches your knowledge and needs. Noone can do that but yourself.
So even now that I pointed you at it, you didn’t read the text carefully enough. See that part below the table, it IS actually giving that guidance to newbies.
But bottom line is there is no single config, naming scheme, ruleset to fit all or even just all basic-most requirements/use cases. We won’t sacrifice flexibility by mandating and writing down you must do it one specific way or another which is what most (all?) other HA systems do. There is no fast, effortless success. If that’s what you’re looking for stick with Vera, SmartThings and the like and see/understand why they fail to provide proper solutions to so many people.
So there’s an official statement from the docs and someone’s personal statement in some forum.
Now guess which one I will tell you to believe in ? Or do you want us to censor forum posts ?
Do you reckon the naiveness how you and the others you refer to are approaching this whole HA SW universum ? That’s not the OH way.
No [sic].
And as David pointed out, you completely missed the point that this thread is not on UIs or usability.
And it isn’t meant to discuss OH principles.
Person conducting the presentation is using simple item linking as well is using PaperUI rules to do basic things. He moves to files editing once he wan’t to do something more advanced. Setting up heater at 6:00 in the morning seems to be rather trivial case to do. Looking at the video I would say this is why many of new users can think that things should be done in such way (there are more examples like that one).
It was said that it’s hard to keep up to date documentation - I can only agree with that one. In the same time I can’t be sure that documentation that is for stable release is actual for snapshot that I had to use.
The only thing I’m asking you is to make the learning curve little bit easier. As a user I’m at the very beginning fighting on to many fronts:
with OH (binding/links/rules),
devices (heater turning on below set heat point/device not updating status / node disconnecting / ghost devices),
finally time because I’m working on living organism.
It is really challenging to figure out what docs you are following or looking at. You mention a wiki but the only wiki is for OH 1.x and is no longer maintained. It says that on the wiki.
Where are you seeing five columns with five approaches?
Almost certainly not. Or if that time comes there will be an automated migration script or some such. PaperUI had a long way to come still before anyone can even think about this though.
There is a beginners tutorial. While it is admittedly incomplete, it does present one approach for your initial set up and configuration.
It does say right at the top of the docs for the ERE
Note: If you use it, this is at your own risk. Especially, you should not expect any documentation besides what is available on the Eclipse SmartHome website.
The ERE is the future but so are a lot of things. That doesn’t mean they are ready for general use. Hence the name Experimental. There are maybe five people on this entire forum who can make it do much of anything right now.
But again, there will be an automated or semiautomated migration from Rules DSL to the ERE before the Rules DSL ever gets deprecated. Kai himself stated this. So those of us with lots of Rules DSL code will be fine.
But that should not be taken to mean we don’t care about making usability improvement too. They just are out if scope for this particular thread.
For the purposes of this thread the core framework I understand to mean the OH server up to the REST. All of the UIs are built on top of the REST API and are therefore it off scope. There are a few cross cutting features that will need support from both the core and UIs that were mentioned which is why I believe they remain in scope.
Needs a startup sequence that can be define in config file or something like that. In OH 2 startup, rules can start before items files are loaded and scripts called before they are loaded. Map files are loaded when ??? For me, this is a problem.
My 2cent, having used OpenHAB now for a bit. No really big project, just a few devices, but enough to get an impression.
My number one gripe ist the scripting engine. Sorry to say that, but the current one is a PITA. Spent hours to do things which should be obvious, like adding two numbers… Glad to hear, that this point will be solved with 2.4. If I got it right. Standard languages like Python or JS are a great step forward! Though if I read terms like JSR223, Jython, Nashorn Javascript, I get worried again, if this might be some awkward dialects … Also the simple examples on https://github.com/eclipse/smarthome/wiki/Scripted-Rule-Support lack a lot of clarity and seem to involve lots of boilerplate code. Maybe this could be hidden behind an interface like the current rules, just with the bodies in JS instead of the current language? Also I think there should be a clear number 1 scripting language, probably JS.
Another point is to make it easier to create reusable components, of items and rules, maybe UI. There are many design patterns with describe solutions to achieve this, written with the best intent. But really they are just creative workarounds. And if I read many of them I only want to scream and run away, wondering why it has to be so complicated And usually they require a complete redesign of what you just created. Leave alone that maintenance will be a nightmare, when you get back to such code years later trying to figure it out again. Maybe some sort of templating? Where you can write your items and rules once, test it, make it work, and then turn it into a template which I can instantiate multiple times with a different name and a set of parameters. Basically the engine in the background is taking care of the replication logic.
Simplification. My other number one, actually. Common things should be simple, more advanced things should be possible. There is no single point or single answer here, and this probably goes through many layers not just what you call the core. But I’m sure some things also touch the core. This is really a pain point, esp. for new users, as others already wrote here. Already relatively simple things take a lot of reading, time and effort to get implemented. Although OH looks simple on the first look, it has a steep learning curve. Sure, there is a lot of documentation (That’s a clear for the project!), and I’ve read quite a bunch of it. And you usually have to read it more than once. Still there are core concepts not entirely clear to me. And sometimes this is also just a sign that something is more complicated than it should or could be, or that something is conceptually wrong or could be improved. Take for instance implicit variables, like receivedCommand. I did that wrong first, and accessed the <item>.state, probably just like many other first time users, getting weird behavior, hard and time consuming to debug. If the rule had a forced (or at least optional) parameter with the received command instead, my code would have likely been correct the at first time. Without even thinking about it. Or call the rule after the item was updated and I can just use <item>.state. And zap, you can remove that part of documentation. Or this awkward thread locking I need to do. Shouldn’t be needed => doesn’t need to be documented. So telling the user he’s wrong and point him to some lengthy doc is not always the answer.
No one is expected to write the JSON by hand. There is a UI in PaperUI for creating Rules and eventually there will probably be a couple of choices.
All three of the JSR223 languages as well as legacy Rules DSL Rules will be supported.
If one is already using JSR223 Rules, they are already using the base NGRE.
JSR223 is just a name for the mechanism that allows one to run non-java programming languages in the Java Runtime Environment (JRE). Nashorn is the JSR223 implementation of JavaScript. Jython is a version of Python that runs on the JRE. OH is a Java application. Whatever language Rules are written in must run in that environment.
The Rules DSL is its own language and it has its own preferred way of structuring code. This is true of any programming language. The DPs are not work arounds. They illustrate the proper way to structure Rules DSL code. Indeed, if you try to structure your solution in a different way, you will probably have to restructure your approach, sometimes significantly. You sound like a programmer and for years I have pushed programmers away from the Rules DSL and to JSR223 Rules because most of the time people who already know how to program cannot or will not structure their code in a way that works well in Rules DSL.
NGRE has support for Rule templates (I’m not sure how it works yet) as well as libraries. But this will only be for Rules. You will have to manage your Items separately.
In the NGRE Rules can call Rules, Rules can be enabled and disabled, and of course there is support for libraries. But in Rules DSL, you shouldn’t have any duplicated code either. Using Groups, Member of triggers, and the like you should only need the one Rule in the first place.
In neither the Rules DSL nor the NGRE should there be replication of logic.
The NGRE takes a really different approach to implicit variables. They are still there but not you have an event Object that encapsulates everything you can know about the event that caused the Rule to trigger. For convenience, some of those properties are exposed as variables (e.g. on a changed triggered Rule there will be a newState and previousState variable populated).
I’m not sure I understand what you are suggesting though by a forces parameter with received command. Regardless, there is a reason why it is the way it is. There are circumstances where one needs received command to work exactly like it currently does. Any change to this breaks those cases. For example, imagine you have a device that always reports it’s new state. With such a device one will likely want to use autoupdate=false which will prevent the Item itself from being updated or changing state on the command and instead waiting until the device reports back that it changed state. So, in this case, you can’t rely on an update to trigger your Rule and you can’t rely on a state change to trigger your Rule when you need to have a Rule triggered when the Item receives a command but you don’t want to or need to wait for the state change. The only way to trigger a Rule in this circumstance is to trigger it based on the actual received command event independently of what the Item’s state is doing. But this also means you can’t rely on MyItem.state in that Rule, hence the variable.
Sometimes the complexity is deliberate, well thought out, and required.
You shouldn’t be doing much locking. It’s dangerous and prone to errors. If you need the locking then my recommendation would be that there might be a better approach or you should be using JSR223 Rules.
One can counter with just because one doesn’t understand why something is complicated doesn’t mean it can be made simpler.
I’m not arguing that there are not areas where OH can’t use some simplification and it has frankly come a really long way in only a couple of years. But it needs to support a lot of use cases and that adds complexity.
Based on the description I really think you would be better off using JSR223 Rules or, if you are adventurous you can start to experiment with the NGRE. There are a few things it can’t handle just yet but it’s pretty capable.
As @rlkoshak, I’m in favor of Dynamic Scheduler, but I’d like to extend this idea.
I’d like to give the non-developer user (my wife) the ability to change some scheduled tasks.
As an example, I’d like to have a scheduler for temperatures or scheduler with on/off status for Christmas lights.
Right now I must use CRON so setup thing and when I want to change timing I must edit rules.
Take a look at Sonoff, You are able to define scheduler in which You want to turn on the light, or in heating systems, You are able to specify a lower temperature for Your house when You are at work.
All of this is done using UI, not in code or scripts.
I agree. This feature is missing. But we have been talking about this subject within this topic and linked topics. It needs to be defined what timers are, maybe separate them from “delay”/“delayed execute”. There is a Github issue already to keep track of this feature.
@David_Graeff could You link this issue here? I’d like to subscribe to notifications.
I’m a C# developer, but I can help with basics. I must start with something
If I got it right. Standard languages like Python or JS are a great step forward! Though if I read terms like JSR223, Jython, Nashorn Javascript, I get worried again, if this might be some awkward dialects … Also the simple examples on 
And usually they require a complete redesign of what you just created. Leave alone that maintenance will be a nightmare, when you get back to such code years later trying to figure it out again. Maybe some sort of templating? Where you can write your items and rules once, test it, make it work, and then turn it into a template which I can instantiate multiple times with a different name and a set of parameters. Basically the engine in the background is taking care of the replication logic.
