Roadmap to Happiness - What is missing in the core framework

Setup, Configuration and Use Runtime
, ,
65

One can counter with this that the non-standard build was an alfa test intended for testers to exercise the new features in the binding. In the commercial world there simply would not have been and still would not be any support for security until OH 2.4 gets released. What you are describing is not standard operating procedure for typical OH users. It was intended for the alpha and beta testers. The only reason so many people who are not necessarily testers went down that path is because many people would not or could not wait for the fully tested and merged in version became available.

Many on this forum, myself included, would argue there should be two UIs. One UI created for the users of the home automation and one UI created for the builders of the home automation. You don’t want to present a UI designed around managing Things and Items and bindings and such to your house guests.

But ultimately this is not something that OH can control short of shutting off the REST API entirely. Anyone can write any UI they want. It’s an open interface. And it’s an opensource issue. I don’t think you will ever see this addressed until and unless someone creates a commercial offering based on ESH.

OH is and always will be a more open and inclusive platform. And I think that is an important point for people to realize. OH is not intended to become some polished and unified commercial offering. The trademarks and licensing would prevent that. This is why there is an ESH in the first place. So from that perspective, OH is and always will be something more on the bleeding edge and more something used by enthusiasts and hobbiests. That is what it is here for.

You mean something like this?

image
image842×569 40.1 KB

Have you explored the Expire based binding? I’m not arguing against the idea (I like it), just offering less code intensive ways to do this now. See Design Pattern: Expire Binding Based Timers.

I’m still exploring the Experimental Rules Engine but I think this is something that might be doable with a minimum amount of code.

66

Oh man, do I wish I could post some kind of animated emoji or something. But none would be sufficiently grand.

That’s awesome.

1 Like
67

The new rule engine will have delayed execution. You would basically start a rule after the door triggered and execute another rule with a delay. The delay resets on every new trigger.

A counter is not yet implemented.

68

I’m fairly new to OpenHAB but what is making me consider moving away from the platform are the following 2 elements:

1.) Absolute URLs. Absolute URLs are making it difficult to run OpenHAB behind a ReverseProxy. I am having limited success working through this issue (with custom Rewrite Rules and research on some others who are having this problem) but it has been a pain in the butt so far. It is making it hard to use the website remotely and making it really hard to use the Android App remotely which is limiting the functionality of OpenHAB for me. As an example, software like MediaWiki works flawlessly from behind a ReverseProxy with a simple ReverseProxy redirect.

2.) Difficultly with AutoRefresh. For me, my SiteMaps don’t AutoRefresh reliably, which, again is making me consider checking out an alternate platform.

69

Not sure what you’ve configured but I’m inclined to believe the problem is with your proxy setup and not OH.
A lot of people use OH with an nginx proxy, and it’s working well with both, browser and app access. openHABian even has an option to auto-setup nginx.

On 2) not sure what your problem is there, but usually it’s working well.
Now apart from the fact that that should not be a selection criterion for a platform, if it does not work for you, open a thread here and describe your setup and problem. You can also file a Github issue and usually it gets resolved within a reasonable amount of time (if it’s really a bug).
Either way, this is a bug at most so please don’t continue in this thread as this isn’t really a request to the core framework.

70

@mstormi thanks for the quick reply. I posted a bit prematurely, apparently, but I still don’t think I’m totally off base. Using this tutorial (Apache2 reverse-proxy with LDAP-authentication, HTTPS and URL-path-prefix) I was able to get my Reverse Proxy working (ironically in the 10 mins between my first post and this post). But you’ll notice these lines

                RewriteRule "/openhab/openhab/(.*)" "/openhab/$1" [R,L]

		RewriteRule "/openhab/?(.*)" "http://xxx.yyy.zzz:8080/$1" [P,L]

and these lines

                AddOutputFilterByType SUBSTITUTE text/html
		AddOutputFilterByType SUBSTITUTE text/css
		AddOutputFilterByType SUBSTITUTE application/javascript
		AddOutputFilterByType SUBSTITUTE application/json
		Substitute "s|/basicui/|/openhab/basicui/|n"
		Substitute "s|/rest/|/openhab/rest/|n"
		Substitute "s|'/rest'|'/openhab/rest'|n"
		Substitute "s|/paperui/|/openhab/paperui/|n"
		Substitute "s|/inbox/|/openhab/inbox/|n"
		Substitute "s|/icon/|/openhab/icon/|n"
		Substitute "s|http://|https://|n"
		
		Substitute "s|/habpanel/|/openhab/habpanel/|n"
		Substitute "s|/habmin/|/openhab/habmin/|n"
		
		Substitute "s|'/chart'|'/openhab/chart'|n"
		Substitute "s|'/start'|'/openhab/start'|n"

The need for the above types of rules seems, to me, like a shortcoming of the baseline design and not something that people should be expected to do on their own.

I’m still exploring the Auto Refresh problem but it is a problem I’m having right now. Again, perhaps premature but this doesn’t seem like the type of basic functionality that should have problems. Searches on the internet and OpenHAB’s bug tracker suggests that more than just me are having a problem with this (https://www.startpage.com/do/search?q=openhab+sitemap+doesn’t+refresh&rl=ow)

71

THING VERSION

If this is currently accessible, I have definitely missed it.

I’d like to see THINGS incorporate the BINDING version they are associated with. Sometimes when updating bindings you need to rediscover the THINGS. Sometimes I find duplicate things - things I may not have included at one time and left in the Inbox for one reason or another. It would be great if somewhere in the configuration screen there would be a display of the corresponding BINDING version it belongs to, so when it’s time to incorporate the THING i know which one to pick.

Squid

72

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):

Number MyThermostat "MyThermostat" {channel="my:heating", sitemap="setpoint:15:30:2"}
// 15 = minValue
// 30 = maxValue
// 2 = step

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.

1 Like
73

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.

1 Like
74

I don’t agree with this:

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.

1 Like
75

I absolutely agree on this and personally like to add:

Sitemap Widgets for Lists

Examples would be:

  • Last phone calls
  • Log entries
  • Calendar entries

Currently it’s a pain to create lists by using several items and pushing the entries through the items by rules.

76

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.

77

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:

Cheers, David

1 Like
78

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.

Thanks for a very productive thread!

80

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

    • similar to above one bulk edit

3 Likes
81

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… :face_with_raised_eyebrow:

1 Like
82

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.

Cheers, David

83

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.

Check out this page of the docs. Did you ever even get to see that ?

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.

1 Like
84

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.

2 Likes
85

This is starting to be an off topic and I don’t want to do that, I don’t want to argue with you either.

How I started with OH - look, at this video https://www.youtube.com/watch?v=DYB20Y4jXnA

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.

I’m asking don’t create curve like that one: http://i.imgur.com/jj16ThL.jpg

Cheers.