Find out.
Look in your events.log for trigger events.
Look in your openhab.log for the messages your rule produces.
Share that info with us.
Add further diagnostic logs to your rule, to see progress and to see key values, for example
val amanecer = new DateTime(Amanecer_civil.state.toString)
logInfo(logName, "datetime...{}", amanecer)
val atardecer = new DateTime(Atardecer_civil.state.toString)
logInfo(logName, "datetime...{}", atardecer)
Thank you.
Found my issue. it was the afternoon reading.
How do i get my Afternoon corected as it is the same as my evining time ?
Today morning logs are:
Events.log
2020-05-25 07:22:00.001 [vent.ChannelTriggeredEvent] - astro:sun:casa:civilDawn#event triggered START
2020-05-25 07:22:02.011 [ome.event.ItemCommandEvent] - Item 'dia' received command Noche
openhab.log
2020-05-25 07:22:01.005 [INFO ] [arthome.model.script.Momento del Dia] - Calculando...
2020-05-25 07:22:02.009 [INFO ] [arthome.model.script.Momento del Dia] - El momento del dia es Noche
My new rule is with logs is:
val logName = "Momento del Dia"
rule "Dia y Noche"
when
System started or
Channel 'astro:sun:casa:civilDawn#event' triggered START or
Channel 'astro:sun:casa:civilDusk#event' triggered START
then
Thread::sleep(1000)
logInfo(logName, "Calculando...")
val amanecer = new DateTime(Amanecer_civil.state.toString)
val atardecer = new DateTime(Atardecer_civil.state.toString)
val ahora = new DateTime(now.toString)
Thread::sleep(1000)
var curr = "UNKNOWN"
logInfo(logName, "Amanecer: {}", amanecer)
logInfo(logName, "atardecer: {}", atardecer)
logInfo(logName, "ahora: {}", ahora)
switch now {
case now.isAfter(amanecer) && now.isBefore(atardecer): curr = "Dia"
case now.isAfter(atardecer) || now.isBefore(amanecer): curr = "Noche"
}
logInfo(logName, "El momento del dia es " + curr)
dia.sendCommand(curr)
end
Two other things, first civildusk event work perfect, only civilDawn have has problems.
Second the trigger more times than it should and when it does run sevel times. I leave the logs.
events.log
2020-05-25 17:55:00.002 [vent.ChannelTriggeredEvent] - astro:sun:casa:civilDusk#event triggered START
The first two lines match the trigger event, everithing is perfect, the others run some minutes later and sevel times. This happens few times everyday.
openhab.log
2020-05-25 17:55:01.004 [INFO ] [arthome.model.script.Momento del Dia] - Calculando...
2020-05-25 17:55:02.007 [INFO ] [arthome.model.script.Momento del Dia] - El momento del dia es Noche
2020-05-25 17:59:19.375 [INFO ] [arthome.model.script.Momento del Dia] - Calculando...
2020-05-25 17:59:20.379 [INFO ] [arthome.model.script.Momento del Dia] - El momento del dia es Noche
2020-05-25 17:59:21.360 [INFO ] [arthome.model.script.Momento del Dia] - Calculando...
2020-05-25 17:59:22.364 [INFO ] [arthome.model.script.Momento del Dia] - El momento del dia es Noche
2020-05-25 18:16:18.935 [INFO ] [arthome.model.script.Momento del Dia] - Calculando...
2020-05-25 18:16:18.935 [INFO ] [arthome.model.script.Momento del Dia] - Calculando...
2020-05-25 18:16:19.941 [INFO ] [arthome.model.script.Momento del Dia] - El momento del dia es Noche
2020-05-25 18:16:19.942 [INFO ] [arthome.model.script.Momento del Dia] - El momento del dia es Noche
2020-05-25 18:16:20.915 [INFO ] [arthome.model.script.Momento del Dia] - Calculando...
2020-05-25 18:16:21.920 [INFO ] [arthome.model.script.Momento del Dia] - El momento del dia es Noche
The most interesting thing about that. is the complete absence of three logInfo() outputs that are in the rule you show us.
The most likely explanation of that is either -
your last rules edit did not upload properly, an old version is still in use - check your openhab.log for your xxx.rules file refresh message.
or
you have more than one rule with the same “name”. Only one will work.
Looks like you get multiple System started events. That usually happens if you are editing files, and can also happen in some configuration situations. Look out for Thing updates (not Thing status updates) in your logs.
The first log are from this moorning and i edit the rules this afternoon. So new logs will be ready tomorrow morning.
Sorry.
Don’t know. What would you like it be?
I expect you want to apply an offset to your minus90 Thing?
Might help -
Hello Rich,
Having switched to openhab3, I noticed that the method for calculating time used in the Design Pattern is not supported anymore. Specifically, these lines:
val morning_start = now.withTimeAtStartOfDay.plusDays(1).minusHours(18)
vMorning_Time.postUpdate(morning_start.toString)
The solution seems to be to use the Java Class ZonedDateTime, however, I am unable to figure out how that needs to be formatted exactly to be read by the openhab-items.
Does anyone have a hint on how to calculate the times for the “Time of Day” Design Pattern?
Thanks!
If you are on OH 3 I would recommend switching to the MainUI JavaScript implementation (link and description now in the top post). I don’t use Rules DSL any more and have not yet decided whether I’m going to go through all the DPs and update the Rules DSL versions for all of them. And the JavaScript and Python version are so much easier for you to use as is without code changes.
But the ZonedDateTime equivalent to that line of code would be
val morning_start = now.withHour(6)
That should handle the change in daylight savings without needing to jump forward than subtract back.
Rich,
thank you very much, I will have a look at the MainUI Javascript version (just as I was getting proficient in DSL rules…).
If I see this correctly, this is all driven by the different TimesOfDay items (Morning, Day, etc.), right? So I just need to figure out a way to populate those. Currently, I don’t think I have grasped the concept far enough to tell where that is done. Where or how do I define when Bedtime for a weekday is? Or for a weekend?
I’m not sure if that “How to boot strap the state of an Item” is what I need here.
I figured the ZoneDateTime variables out last night, but got stuck on importing the astro time in a correct format, kept getting all sorts of “cannot compare date” errors. So I’m definitively going to give the JavaScript a try.
Thanks!
You don’t have to abandon the Rules DSL code. The advantage of the the JavaScript and Jython versions is that you never have to even look at the code. You just import them to your OH and configure your Items. So you can import those that are useful to you and use them and write your own stuff in Rules DSL if that suits you.
You define a DateTime Item for the start time of each time of day. If you want a different set of times for different types of day (as defined in Ephemeris: Actions | openHAB) you define a set of DateTime Items for each type of day. The example in the top post shows a set of DateTime Items for deafult, weekend, a custom day set called trash, holiday, and a custom holiday defined in the /openhab/conf/services/custom1.xml. See the Ephemeris docs (link above) for how to configure Ephemeris and define a custom dayset or custom holidays.
Each Item is a member of the TimesOfDay.
Each Item has an etod metadata. The etod metadata defines the name of the time of day that starts at that time, and what type of day type it applies to. If using a custom dayset or custom holiday there are additional parameters.
Everything is defined at the Item. The start time is the state of the Item. The rest is metadata defined on the Item.
You would need to bootstrap the state of the Item if it doesn’t have a state and doesn’t get a state from somewhere else (e.g. the Astro binding). Somehow the Item needs to get a valid date time value.
To get a ZonedDateTime from a DateTimeType just call zonedDateTime. For example MyDateTime.state.zonedDateTime. You might need to cast it to DateTimeType first. (MyDateTime.state as DateTimeType).zonedDateTime.
But you don’t have to mess with any of this with the JavaScript or Jython version. It’s already implemented for you.
Everything is defined at the Item. The start time is the state of the Item. The rest is metadata defined on the Item.
Yes, that’s how I understood it. So for those times that do not get updated automatically (like Astro) I still need a rule of some sort that updates the state of the (fixed) items, preferably once at the start of the day. I suppose that has to run daily to update the states with the correct date/time. But I think I can figure that out with ZonedDateTime, as I already did with the original rule.
I can see that the use of Ephemeris expands the usefulness of this to different types of days (weekends, holidays, even trash days).
Thanks!
Only the time has to be right. The JavaScript and Python rule will automatically move the date time to today for you.
If you are running OH 3, see OH 3 Examples: How to boot strap the state of an Item. You can define a card that lets you enter the DateTime from the UI. Then you can change it later without messing with Rules.
Of course you can do it with a rule too, but that’s not the only nor even the best way.
Even better. That way it could even be static. But yes, defining a card (or sitemap section) to set these times from the UI has a neat touch to it, too.
I’m running OH3 Milestone 4, btw.
Ultimately, I decided against using the JavaScript. It really seemed to be a lot of hassle to get it working, not all of it applicable to everybody:
TBH, that seemed to be a lot of issues just to get the TimeOfDay. I do realize that the new method gives much more possibilities (weekends/holidays and such), though.
And as I was able to McGyver the DSL script with ZonedDateTime and get the Astro items in the right format (not pretty, but works), I guess I’ll stick with the old script for now.
But thanks for the explanation.
The whole point of a library like this is you don’t need to know JavaScript. You should never have to even look at the code.
There is no test script required. The readme should be clear on that. The helper libraries are required though.
??? You don’t have move away from file based .items files at all. You can define metadata using .items files. It goes in between the { }, just like the metadata required for Google Assistant and Alexa goes.
If it works for you that’s great. But I’m eventually going to be unable/unwilling to support Rules DSL at some point in the not too distant future. At that time I’ll probably be removing them Rules DSL examples from all of my Design Patterns.
I might think about it.
For me, a rather simple DSL rule plus a few items is a lot simpler and easier to understand what it does. Maybe that’s just me 
I understand that the DSL rules might not be supported anymore in the future since you’re focused on a different approach.
Hi Rich,
Ok, so I gave it another shot and seem to come back to my conclusion that while I do understand some JavaScript, obviously not enough to troubleshoot OH3. Or maybe it’s a bug in M4 I can’t do anything about.
I tried to get your time_utils as one of the required libraries to run.
While I understand what the JS testscript is trying to do, it fails halfway:
18:51:01.753 [INFO ] [org.openhab.model.script.Rules.Tests ] - parsing the duration
18:51:02.175 [INFO ] [org.openhab.model.script.Rules.Tests ] - PT26H10S
18:51:02.325 [INFO ] [org.openhab.model.script.Rules.Tests ] - 2020-12-03T20:51:12.206312-06:00[America/Chicago]
18:51:02.413 [INFO ] [org.openhab.model.script.Rules.Tests ] - PT243H0.2S
18:51:02.449 [INFO ] [org.openhab.model.script.Rules.Tests ] - It's ISO8601!
18:51:02.462 [INFO ] [org.openhab.model.script.Rules.Tests ] - It's not ISO8601!
18:51:02.477 [ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID 'timetest' failed: ReferenceError: "ZonedDateTime" is not defined in <eval> at line number 21
So it gets to the point of “dt = ZonedDateTime.now()” where the current date/time is written into the variable dt, but I really don’t get why it thinks that ZonedDateTime.now() would need to be defined.
commenting out those two lines:
//dt = ZonedDateTime.now()
//logger.info("Already ZDT: " + toDateTime(dt));
lets the script complete.
I usually don’t give up easy, but I feel that as this is probably just the first hiccup getting this to run, I really cannot expect your time to help me limp along
(And out of curiosity, isn’t that line 21 missing its semicolon at the end?)
Well, again, why mess with the test scripts in the first place? Those are for testing and indeed this is something I need to look into (are you on the latest milestone? it makes a difference as the way you trigger a rule on earlier versions of OH 3 can cause certain things to not be available). But it’s not something you need to worry about. The Time of Day rule doesn’t use that part of the library anyway. It only uses the toToday function. The TimerMgr class uses the toDateTime function.
The tests may be failing but they are irrelevant to getting the rule running. And I know the library code and the rule work because I’m using the timeUtils.js library in about half a dozen of my currently running rules, the timerMgr class in four rules, and of course I’m using the Time of Day rule itself.
All you need to do is (assuming you’ve cloned the repo successfully and created the Items):
cp automation/* /etc/openhab2/automation
cp automation/* /etc/openhab2/automation
You may be running into a hickup, but it’s not a hickup that is related to anything that you should be messing with in the first place.
Thanks.
Being the cautious type, I learned that if part of a system doesn’t run, chances are good that the whole thing itself doesn’t run, either. So, understandably, I was worried when the test didn’t complete…
It was the latest Milestone (M4), btw.
(so $OPENHAB_CONF points to /etc/openhab with out a “2”)
Hmm, seems to work partly. It switched to the fixed-time items, but failed on the dynamic ones from the astro binding. Also, the logs show:
10:20:46.301 [ERROR] [re.automation.internal.RuleEngineImpl] - Failed to execute rule 'timesofdayjs': Fail to execute action: 3