Direction and focus

Hi,
I’ve been using OH1 for some time, and now (partially) moved to OH2.
Partially because I’ve relied on the Astro binding.

I’d like to read more about the automation part of OH.
what is the design idea, the strategy behind it, and the road ahead.

The reason I ask is that, for me, the first step into automation is to do
things by clock and related to sunset and sunrise.
But OH(2) lacks a functional Astro binding, and also lacks an Event Scheduler.
OH2 is strong on bindings and other technical stuff. But the actual automation part
seems to be lagging behind.

(For me, moving the UI for a switch from the wall to the phone is not automation …)

Interesting…I’ve been using Astro on my OH2 setup for quite a while now. I have a number rules to turn on lights based on sun rise/set times that work flawlessly.

Here’s me thinking that automation was very much a focus of OH2. Everything in my setup runs on events. I even have astro rules setup so that if the sun is shining in a particular window, the blinds are moved down.

Where did you get these impressions from?

The Asto 2.0 binding lacks one feature that the Astro 1.9 binding has which is the ability to toggle a Switch at a given time (e.g. sunrise). This is because OH is currently implementing a system wide method for generating this sort of event rather than having each binding implement it in their own way.

In the meantime, you can just install and use the Astro 1.9 SNAPSHOT binding (you may need to enable showing 1.9 versions of bindings when a 2.0 binding is available setting in PaperUI or the console).

Automation in OH is driven by events and Rules. Events can be based on an Item’s state being updated or receiving a command, Time, or system events.

As you know, the 1.9 binding uses a Switch (i.e. Item based events) to inject events at certain times. I assume this is what makes the Astro 2.0 binding non-functional for you right now.

For hard coded scheduled times (e.g. every hour, every weekday at 05:22, every morning at 06:00, etc.) there are Time cron Rule triggers which lets you use the full range of cron expressions to schedule rules to trigger based on time and date.

For Time based events where you would like to be able to set the time using elements on your sitemap I agree, OH is lacking. It isn’t that it is impossible it just isn’t super easy. Look at the Alarm Clock examples for how to implement this. I would like to see this scenario easier to handle.

But, like @Benjy, I don’t understand where your impressions come from. OH is all about automation. However, perhaps you are not looking in the right place. All the automation in OH (1.x and 2.0) is contained and implemented in the Rules. And within Rules there are all the ways I described above to trigger a Rule plus Timers which let you schedule code to run at sometime in the future.

Except for the one use case I described above which I think could be better, OH 2.0 provides the full range of automation one HA system could need. And this is spoken as someone who doesn’t even use the UIs for controlling his automation, only for administration and debug. My house just does its thing automatically without or with minimal direct human interaction. And my automation is driven by time based events (including sunrise and sunset) as well as presence, weather, temperature, etc.

Given this, what automation scenario do you find lacking?

1 Like

@feens, @Benjy, @rlkoshak .

You are of course all correct, and my question was ‘harsh’ (sorry for my english).

Yes, automation in terms of acting on input from sensors is absolutely there, and is one of the strong points with OH.
As for Astro2: To me, this kind of coding indicates it is not functional: (but it most probably works):

An later:
"In the binding you can set the update period (default 300 sec I think). I use this value to check If the sun has set."
Which of course also works, but for such an mandatory part: Reacting to sunrise and sunset. It seems more like an afterthought than a core design decision. But it works.

Much the same with events.
OH is a long way from a GUI that allows you to schedule lamps to turn on 40 minutes before sunset, for instance.
But it can be done. So it works.

But I still think that many other Home Automation software’s are easier and better when it comes to scheduling, especially relating to the suns position.
And for me that is a core functionality in any HA set up, hence the question about direct and plans.

Sorry for upsetting you all.

Edit:
Some (Swedish) examples of how a scheduler might look:

http://www.switchking.se/sv/screenshots

http://nexahome.se/manual/
or

(And I’m sure there a re many out there that are better than this)

That is a non-standard use of Astro binding. If using the 1.9 binding, to trigger a rule at sunset is as simple as:

Switch Sunset_Event { astro="planet=sun, type=set, property=start" }


rule "Sunset!"
when
    Item Sunset_Event received update ON
then
    // do sunset stuff
end

And as I said, for the OH 2 binding this sort of event triggering is in work only it is being implemented as a core OH 2 capability, not an Astro binding only thing. This is why the Astro 2.0 binding does not currently support the Event Switches. But ultimately, and soon based on what I’m seeing with the new Dash Button binding, I think we will see this capability restored to Astro 2.0.

So indeed, this is not a core design function. This is a work around to force the Astro 2.0 binding to generate the events that the Astro 1.9 binding does. It is a work around, a temporary one at that. It is not intended to work this way.

You original post made no mention of GUI. If you are looking for creating rules from a GUI indeed OH has a long way to go. I don’t think anyone will argue that. Your original posting though indicated that this sort of automation is impossible. That is where we are pushing back.

So my question is, why not just use the 1.9 Astro binding until such time that the 2.0 binding gets events again? Except for the pretty GUI it will do everything you are asking for.

Almost all of my time based home automation runs off of sunrise, sunset and other timers relative to sunset (e.g. 90 minutes before sunset). It works great.

1 Like

Sorry for not mentioning GUI. I was aiming for the ease of doing this kind of things. Gui may or may not be the solution.
Yes I did most of these things myself in OH1.

To me it seems like a good area for improvement to facilitate a well integrated scheduler that can correlate events to the sun.
I’d even go as far as to say it is essential for a true success and widespread use.

The fact that there is so many bindings and different supported items but very little done in the usability area speaks for itself a little, wouldn’t you agree?

But then again, if I’m the only one seeing it this way, then OH is heading in the right direction.
All the best!

Current use of OH would argue against this statement. OH is incredibly popular and becoming more so without that feature. Personally I would probably never use such a UI. I suspect a lot of users would agree. And even if it did, scheduling things based on the sun makes up such a small portion of my automation that I probably wouldn’t miss it if that capability were removed.

That isn’t saying that it isn’t a good idea. Just that everyone’s needs are different. Your needs and desires may or may not match up with the bulk of the HA population. I know mine don’t in a lot of areas.

There is a TON being done to improve usability. The main reason OH 2 even exists is to improve usability. PaperUI, Habmin2, HabPanel, etc. All of these are making great strides in improving the usability of OH. To say “very little done” is a little bit insulting, though I know you don’t mean it to be. Almost everything being done in OH 2 is either directly or indirectly there to improve usability.

I admit, in your one use case, scheduling things based on the sun, little has been done to make it easier. But that is IMHO a second or third tier priority compared to other usability improvement needs like backup and restore, non-text based rules options, sitemap generation, reusable rules libraries, meaningful error messages in Rules, etc.

If you feel strongly that this needs to be addressed, I encourage you to take a shot at implementing it or at least submitting an Issue.

I’ve looked at doing that, atleast been playing with the idea. But I haven’t found out how to programmatically schedule an event to fire at a certain time every day…
But I haven’t searched that long either.

Here is how I schedule things in my automation.

Firstly, OH2 supports the same rules as OH1, so by moving you are not losing anything.
Secondly, a new rule engine is being worked on. It should be possible to come up with user-friendly schedulers as it is very modular and extensible. Here are some links regarding design idea, strategy and road ahead:

You should note that openHAB does not evolve by itself. It is the community of developers that together move the project forward - it only lives through the many contributions from individual. So if you feel that something important is missing: Get to your keyboard and start contributing :slight_smile:

I understand that this is a open source project and that gives it both some freedoms and some limitations.
For instance the Astro binding came in rather late into OH1.

As for me, it was 20 years since I did larger scale programmming, and that was i C++.
So whilst I can manage to write some rules, I would hesitate in trying to write a GUI that injects scheduled events. - It’s not a great idea.
Hence the question was asked around design ideas, strategy and the planned way forward.
Simply becase I couldn’t see it.