Next generation design : Ideas & Discussions

OpenHAB provides the framework and accessibility to the parts to build a complex system. It is not designed as a prebuilt system for beginners. Somebody needs to work and learn how to best use this powerful complex system to satisfy their Smart Home desires.

Yes but the long term goal it to make it more accessible to less tech savvy users.
A “simple” scheduling tool would be a big step towrds that

cron is fixed in rules and not a scheduling tool
caldav depends either on a cloud calendar with hoops to jumps though to authorise access (google…) or you own caldav server (Not beginner friendly…)

3 Likes

Perhaps there are some modules in Python or some other language that can be used instead of the default rules DSL. That is the flexibility of OH.
I moved here from another system that is focused on beginners and adding feature support. Unfortunately they neglect stability and functionality. Many themes they need to release a patch release within 24 hours of a release. They never get one version stable before they release again.

Of course, there’s also the REST API that you can use from any outside system.

1 Like

I fully support this.

1 Like

It could be built as a UI of the NGRE (Next Generation Rules Engine) is you want something graphical.
Since NGRE is already available now, feel free with making something around that.

Thats rubbish, no disrepect @Bruce_Osborne. Very few people want to learn java, python etc. Scheduling in automation is bread and butter, if it’s not a system beginners will use it will eventually die and no one wants that.

Caldev/cron doesnt even scratch the surface and are not solutions. The virtual thermostat stuff i mentioned has come quite close. They are tools that could be used to augment a proper scheduling system but it just doesn’t exist.

CalDav is a 1.x version binding and based on the number of threads exceptionally challenging for many users to get set up and configured.

I can’t tell my wife to edit a cron expression in some Rule file to change when she wants something to happen. And even for CalDav the strict formatting of the events can be a problem.

So what is missing?

  • A 2.x CalDav binding that can be reliably installed, configured, and used, or an equivalent of a calendar built into OH.
  • The ability to set a DateTime Item from a sitemap. Changing when something is scheduled to occur is not just an administrator’s task. It is also something that general users may need to do in some situations.
  • The ability to trigger some event based on the state of a DateTime Item. This can be worked around using Rules and Timers but it would be far easier for most users if this was built in.

I think the point is that scheduling something to occur is not just an administration task. It’s also something that an average user of the house may need to do. OH provides no way to allow this to happen without a lot of extra work which shouldn’t be required. As I said above, I can’t tell my wife to go edit some Python code if they want to change when the lights turn on.

Now, using JSR223 Rules, part of this could be implemented. But the UI parts do not exist.

And scheduling like this is, IMHO, something that should be built in, or at least much easier to add in and use than is currently possible.

3 Likes

I would second this.

Scheduling is such a fundamental thing that should be possible in a native
and easy to use way. (@ysc -> we talked about that at froscon with wido, if you remember. :slightly_smiling_face:)

Some communication standards like BACnet seem to see this importance too and added “schedule” as an own entity in their reference.
This is something we could/should learn from.

Dead-simple scheduling for end users was the intended purpose of this piece of UI in HABot :wink:

image
It creates time-based NGRE rules on the fly - which would self-disable themselves after running if there was no recurrence needed, i.e. ad-hoc rules like “switch on the light when the washing machine has finished”. I’ve found them to be quite unreliable at the time (for example they would re-enable themselves when openHAB got restarted), so I didn’t develop it further, maybe this has changed since.

Managing them after creation should be a must, I think a weekly view of cron-triggered rules added in a certain so-called NGRE rules namespace (prefix in the ID and a colon) could be enough.

3 Likes

That particular issue has been resolved. :slightly_smiling_face:

1 Like

I was under the impression that a discussion about a built in scheduling system had already begun. I thought I remembered being refered to an issue or PR on git
It maybe got nowhere
obviously this is an important addition for OH
I think it is pretty much universally approved of by all

Since it’s been a while and I recently resumed working on the new UI after a period of inactivity, here’s a 15-minutes video where I go from practically nothing to a few things added in a semantic model using only the new UI… watch me as I run into bugs :laughing:

https://vimeo.com/359677006

ICYMI, that was the previous one showcasing how it works on different devices:

https://vimeo.com/342616345

10 Likes

Pretty awesome :+1:

Been playing with this simple scheduler idea yesterday, and here is an experimental and early implementation of what I had in mind:

For now it only considers rules with GenericCronTriggers (time-of-day and day-of-week triggers & conditions are not supported yet) and will compute the occurrences expected for the next 30 days, with a current limit of 100 per rule. I haven’t exprimented much with JSR223 rules but since they’re appearing in the REST API they seem to be displayed as well, however the rule editor doesn’t know it cannot edit them.

The calendar should ultimately only display rules tagged with a specific tag, or those in a specific namespace, to avoid cluttering it with often-repeated jobs which would lead to usability and performance problems. There are also unfortunately bugs due to mismatches of functionality between Quartz, used by openHAB’s scheduler, and the JS libraries parsing cron expressions, notably with the L (last) and W (weekday) special characters.

You’ll note the effort made in providing tools helping the user with cron expressions in the rule editor, including an expression builder ported from this one and human readable descriptions of the expression provided by cronstrue.

14 Likes

:+1::+1::+1:

Is there a chance we will see that as part of the next releases? :slight_smile:

I missed this topic, so I’m issuing a refresh command :slight_smile: indeed schedule is an important part and I see lack of it as one of big disadvantages for bigger projects. Usual house has at least two schedules - heating and irrigation. Navigating of these two is now buried in bindings, hab panels and other things with convoluted combination of jsons, custom files and other ways which do not stand for advanced integration solution such as openhab!

I will also bring here an alarming possibility - to have an easy way to define alarm levels and their severity without rules.

1 Like

I think part of the reason is that scheduling these things is not trivial.
It’s not Mo-Fr 9:00 start irrigation but rather check weather forecast, check temperature, check soil humidity and then irrigate a little bit. Don’t get me started on heading.

But if there is a scheduler there has to be a possibility to restrict the scheduler to certain items, otherwise the scheduler will interfere with your normal rules which relay on certain states and create undesired behavior that is very hard to reproduce.

I don’t think we need checks and alarm levels with logic built in. Rather we need a proper fronted which has a way of displaying alerts so the user is properly notified. And it’s behavior needs to be properly configurable.

Make small independent units which do little but work well and let the user glue them together.

This is exactly, what a bacnet alarm specification implementation would bring.
Configurable -> alaram level
Frontend -> The informations that should be displayed would have to come “somewhere” anyways, which would also lead to some kind of alarming. I don’t think that it would be useful to use error logging entries in a native way for this.

This is a behavior that the bacnet standard has implemented already (at least partly).
You can define so called “exceptions” in a schedule.
If you want to override a scheduled behavior, bacnet could solve that too.
Bacnet standard knows so called “priorities”, which are send with a command in parallel.
See: http://www.bacnetwiki.com/wiki/index.php?title=Priority_Array

So you could more or less easily set up some kind of schedule with a low priority and override it in case of some situation (no one present, holiday, …) that has a higher priority.