Rule not firing - sun setting

Last weekend I made little test setup made off with a wall switch, lightbulb, fibaro Z-Wave actuator and an Aeon Z-Wave USB stick. I’m running openHAB on a raspberry pi 3+

I have installed the Astro and Z-Wave binding.

After some struggling with the inclusion of the Z-Wave device I can switch on the lightbulb using the Paper UI interface.

After that I made 2 rules:
1 to switch on the lightbulb when the sun sets
1 to switch off the lightbulb at 23:30h

As the lightbulb didn’t turn on when the sun set this weekend (around 19:40 this time of year), I made a test rule to switch on the bulb at a give time (20:00h).

The lightbulb switches nicely on at 20:00 and turns correctly off at 23:30 but the rule when the sun is setting doesn’t seem to fire.

I made the rules using the Rule Engine (Experimental) (misc-ruleengine - 2.3.0). I haven’t messed with config files (rules files).

The rule looks like this:

Any idea why the rule isn’t working?

Try setting the channel trigger event to START. There is an example in the docs that has the event in capitals, and this also works for me using unmanaged rules (rule files).

Try setting the channel trigger event to START. There is an example in the docs that has the event in capitals, and this also works for me using unmanaged rules (rule files).

I believe I selected the ‘start’ value from the dropdown menu. I’ll check tonight if I can manually type START into that field…

That’s key. It’s the experimental rules engine you’re using.
Anybody else including the docs is using/referring to the standard rules engine which is what you get when you textually setup rules in .rules files.
So while you might or might not get this to work, you should refrain from continuing to use that engine.
While it may look easier to use at first glance (just because it’s graphical) that does not mean it is.
That’s particularly true for a beginner. You are well about to hit many more issues if you stick with that.
Might change one day when that engine has matured and there’s more people to use it, but for now I can just strongly advise to switch to the standard engine.

I think you might be being a bit too cautious, since by that logic, nobody should use the snapshot builds either! We need more people using the new rule engine to flush out the issues. If anything, it would be best for @Dinobe to update to a snapshot build to get the significant updates that have gone into the new rule engine since 2.3.

Thanks for the info. I decided to use the Rule Engine after watching a youtube video yoyotech

In this video he only shows switching the lightbulb on and off on a given time. This also works for me.
I want to switch the light on when an event happens (sun set start).

When I get home tonight I will try to change the start value to START.

If this doesn’t work, I will try creating a .rules file

Keep you updated!

I decided to install the stable build, not aware that this Rule Engine might not fully work (if though it says Experimental).

I’m also very new to this matter, so I take it slowly and carefully. I have restarted already a couple of times due to my own mistakes and errors.

No that’s where a different logic applies. Users to qualify themselves to be beginners shouldn’t use snapshots either IMHO.
Either way, the advanced-experimental-whatever version is not what anyone should start with.

Got to answer a lot of requests like this, consuming quite a lot of my time to answer, that would be less and less challenging to explain basics if at least beginners did stick with the mainstream.

I tend to agree with Markus on this sentiment largely because new users will not find the two things they need most to be successful with the ERE: documentation and a community of users who can help.

Until both of these are addressed I cannot recommend the ERE to new users.

But this does mean we need some pioneers to start using the ERE and building up experience with it and writing some documentation. I plan on being one such pioneer at some point, I just haven’t had time to really explore it since I have to go to the source code to figure out if a problem I’m seeing is because of me, because of a bug, or just something that hasn’t been implemented yet. I’m also not familiar with JSR223 JavaScript or the API so it isn’t clear to me how to actually code the JS part of the Rules.

I have learned a little. The Rules are saved to JSONDB. Some very powerful behaviors can be created without even needing to be coded in scripts thanks to the when but only if and the ability to turn Rules on and off.

As for the snapshots, new users should not be using them either. The purpose of the snapshots is for more experienced users to alpha and beta test out and report errors when they occur. New users do not have the knowledge nor the skill yet to do this. And since the snapshots can have bugs introduced on a daily basis, it is a really bad choice foe new users who need a stable working environment in which to learn.

Just to keep you updated: yesterday evening I built the basic UI interface with some things and items. It shows some basic info like sunset, sunrise, etc and I have added a switch to switch on my test lightbulb. Everything works fine. I got my first rule set up, but I couldn’t test it last night. I’ll keep you updated if the rules works tonight…

I also removed the rule engine from my installation

I’ve been reading in this community for quite a while now and this topic made me set up an account. I started with OpenHAB 2 about 2,5 years ago but I do not have a lot of devices in my house but I also have a few things working that use data from other sources like weather, astro, gas prices, google calendar. Unfortunately I don’t have knowledge in programming except HTML & CSS. Reading, understanding and adjusting tutorial code is quite possible for me but writing new code for textual rules seems quite hard for me and needs to invest a lot of time I often don’t have. So I think I am quite of an average user OpenHAB 2(!) is made for. The graphical interface is easier for people like me and makes OpenHAB more attractive to a lot of people.
So I think that the development of the rule engine in PaperUI is important for the software as a whole in my opinion. I think I’ve spotted the aim for the OpenHAB foundation that they want to bring it to the more average users instead of sophisticated programmers. So it would be a huge improvement if the specialists here in the community do not drop the graphical interface but help develop it so it can replace the textual rules one day completely.

PaperUI with its graphical interface makes it possible for people with lower skills and interest than me to do changes in home automation. My wife for example would easily be able to change or stop a rule in our home if necessary and I’m in hospital, a while away,…

To the specific problem in this thread I can say, that I have set up a rule in PaperUI that uses the sunrise time to open my rollershutters with an offset. So the OP could have made it work with a little bit more testing, but now he uninstalled the ERE. :frowning:

I actually maybe found a problem in the ERE myself that is related to this. The described behaviour is setup to do so from monday till friday and not on the weekend. This worked one week and than the rule stopped working. As I don’t have the time and good knowledge at the moment to dive deep in the logs and check what happens in the morning I don’t know much more about it. After a reboot of my Raspberry Pi and initalizing the rules in PaperUI it works again. I’ve done this 2 times now and probably it will stop next monday again.

Maybe the problem is solved in a newer version of OpenHAB, that I as a lame user did not install for a long time.
I hope users like me that know nearly nothing about linux, with limited programming skills and who do not master the system but try hard to have it working as they want it are accepted with their problems and needs. I really love OpenHAB and appreciate the community with its input and contribution to the project and in this forum. That’s why I chose OpenHAB over FHEM and other home automation systems. Keep going please!


We don’t drop it but we’re saying it’s definitely not ready for prime time so no beginner should seriously consider using it at the moment as that’ll (likely) just end up in more work and frustration than to start with the standard files based engine.
Don’t be misguided: the fact alone that ERE has a GUI does not mean it is a suitable tool for beginners or that it is working at all. And note I’m not claiming the opposite either. It is experimental, hence its name.
Anyone willing to play with the ERE is welcome, but we can’t support him for a number of reasons:
Because we haven’t used it ourselves. Because we’re busy supporting mainstream users.

This task both of you are up to is a good example to explain why I recommend anyone to go with the mainstream.
I don’t know for sure but quite likely both of you aren’t suffering from ERE problems but “traditional” ones.
You have to use the right item config, trigger names, cron (time) expressions, data types etc. no matter what GUI or engine you’re using (ERE or the standard rules engine or any code-generating frontend tool such as ESH Smarthome Designer or habmin).
But when it doesn’t work, a beginner has no idea where to look for: is it the engine to be the problem ? Is it the OH framework ? Is it the code generator generating bad code ? or is it rather the user-supplied parameters and code fractions to not work ?
That’s even true if you’re say an experienced programmer. But most users will not even know how to setup OH to generate meaningful log output, and without those even no pro can answer these questions.

Again, we welcome anyone to join the party and play with the new and experimental stuff like ERE.
But you must be well aware of that. And you have be familiar enough with the OH basics and dependencies to make sure these won’t be pitfalls.

Please, it was never my intention to start a debate on the experimental rule engine.

I decided to use it because I’m completely new to this matter and as a beginner I did’t really get the impact of this experimental plugin. Also I got some info from Youtube videos where someone used this plugin.

As with a lot of open source projects, they can be fantastic but you’ll need to invest time to learn.
That is also my approach to what I’m doing right now. I wanted to see if I could make a home automation system to solve a small problem I have. Investing a little money and investing some time. Also it seemed fun to get this working.
I respect that a community can achieve such fantastic products.

I have over 8 years experience in java programming and over 6 yeas as system engineer. So building a Basic UI isn’t really a problem, but I didn’t see the need for it, I just wanted some basic thing working. That’s why I went with the rule engine.

When I get home tonight I will post some screenshots from what I made and I
will test if my code works.

So, got back home, made some smaller modifications and everything works:
For now I have the lightbulb turn of at 21h purely as a test case.

rule “Turn on light front door when the sun sets”
Channel “astro:sun:local:set#event” triggered START

rule “Turn off light front door at midnight”
Time cron “0 0 21 1/1 * ? *”

The basic ui looks like this:

FWIW, you can add additional astro things with different offset times.
Should help a lot with testing as your current development process will only allow for a single test per day :slight_smile:

It would be simpler to just manually trigger the channel events in Karaf…

smarthome:things trigger astro:sun:local:set#event START

To repeat the test, you need to trigger the END event before it can start again…

smarthome:things trigger astro:sun:local:set#event END

Right that’s simpler. Forgot about, thanks for pointing out.

In my opinion this recommendation comes to early. Especially beginners start with easy rules like mine and Dinobe’s. It is clearly stated that it is an experimental rule engine. So nearly everybody will recognize this when searching for help and will understand that there might be problems and reduced functionality. If even the beginners are recommended to textual rules there will only be a few people developing the PaperUI rules. Users who are already quite familiar with text files will not go back to the (at the moment) less capable engine.
But maybe I’m wrong with this and most users are not as comprehensive and patient in trouble researching like me.

Personally I know that the engine is new, experimental and maybe buggy. But as long as it works good for me and I don’t need more complex rules I will stick with the graphical interface because it doesn’t require learning syntax and expressions. Switching items at a time, at astro events or at item updates work flawless for me with PaperUI rules. The first exception was my described problem when I added the if condition to the rule.

1 Like

Do you see the START trigger for sunset in the log?

No, it comes after @Dinobe failed because of a ‘traditional’ issue that had nothing to do with him using ERE (or ‘experimental stuff’ in a generalised sense).

Well, quite some people just don’t read even THAT, they start right away.
My recommendation also comes after me answering many posts painfully having to help and explain OH beginners that started even way more naive on this whole matter.
In total, that’s creating trouble and need for support to a far greater extent than if some experienced OH user started on this stuff.
As I said I don’t mind anyone to be aware of the implications to try (like yourself as you claim you do and are willing to invest in troublehooting). @Dinobe started a little naive, too, but understood and moved to traditional rules instead.
It’s the combination of beginnership and experimental stuff I still strongly advise against.
The ERE GUI is tempting, but that is just hiding that using it is still beta if not alpha quality and vastly undocumented and thus using it is a bad idea at this stage of its development and even more so if your knowhow is beginner level.
It will not help advancing development either as beginners aren’t capable of understanding let alone fixing most problems for themselves or to properly identify bugs and explain them to developers. No pun intended: if you’re willing to do that you’re highly welcome.
Submit GitHub issues when you find bugs and maybe write a couple of docs pages while you’re there. That point of yours is valid: there’s no docs because noone’s using it so noone’s capable of and willing to document usage.