All I’ll mention is that most of the struggles you’ve had in this thread are with Scott’s Mode library, not with the Rules engine and Python code itself. That part is mature.
An I’ll add (as usual) that there are other ways to do home automation in python 
Actually, the groups & triggers too. 
Did you ever figure out how to call Actions?
What about Gross and triggers are causing problems? From what I’ve seen in this thread, the triggers and Groups problems are also specific to Scott’s library.
All the testing I’ve done so far, Groups and triggers behave identically in Rules DSL and NGRE.
The groups & triggers combined with timers.
If I can get it functional I may still try your EXPIRE binding replacement.
As of a few minutes ago, I have moved this system into Production with Rules DSL & EXPIRE…
Groups and triggers and Timers are all completely different concepts. So break it down.
What is it about Groups that does’t work?
What is it about Triggers that doesn’t work?
What is it about Timers that doesn’t work?
Except for the triggers, these are independent from Rules. And all three work the same as they do in Rules DSL.
And there is nothing that says you can’t use the Expire binding with Scripted Automation.
Should you desire to, you can do a one-to-one translation of your rules to Python and they will work and likely look very much like your existing rules.
And they are all combined in this rule that would not work as designed. The timer ran continuously, not when triggered. All Items are switches.
from core.metadata import set_metadata
set_metadata("papillon_light", "area_triggers_and_actions", {
"modes": {
"Morning": {"brightness": 98},
"Day": {"brightness": 0},# if there is motion during Day mode, the light will not turn on
"Evening": {"brightness": 98},
"Night": {"brightness": 98}
},
"actions": {
"light_action": {"OFF": {"delay": 300}}# the turning off of the light will be delayed by 5 minutes
}
},
This rule should be strictly time & event based but Scott added a switch trigger. The lights never turned off.
set_metadata("basement_light", "area_triggers_and_actions", {# there is no modes metadata, so the default values in configuration.area_triggers_and_actions_dict will be used
"actions": {
"light_action": {"OFF": {"delay": 120}}
}
}, overwrite=True)
Both are using this dict for Mode.
mode_dict = OrderedDict([
("Morning", {"hour": 5, "minute": 45, "second": 0}),
("Day", {"channel": "astro:sun:local:rise#event", "event": "START"}),
("Evening", {"channel": "astro:sun:local:set#event", "event": "START"}),
("Night" , {"hour": 21, "minute": 30, "second": 0})
])
And like I said, this is specific to Scott’s library, not Scripted Automation and Python Rules in general. And the code you posted are neither Groups nor Triggers nor Rules. They are lines of code that set Item metadata which, in Scott’s library, is used to carry configuration that drives the library. They are very specific to Scott’s library and not at all required or in general use by Scripted Automation writ large. Of the dozen or so Community libraries I’ve built (not all have been submitted to GitHub yet) only two make any use of metadata gh
All of the problems you had above are specific to Scott’s library, not Scripted Automation in general. So rather than throwing the baby out with the bath water, let’s step back, regroup, and start simpler. Maybe a better approach would be to indeed do a one-for-one translation of your existing Rules to Python and then look for optimizations, consolidations, and the like.
I plan on doing that now I have moved my production to the new server. As a first step I have installed your expire binding, making the necessary change needed to not install some 1.x pieces. Details are in your thread.
I now need to setup a test case triggering a timer to verify.
Don’t ignore the caveat with the Expire binding replacement. As it is written right now, you must reload the expire.py script to pick up changes to your Item’s Expire config. I’m still pondering ways to avoid that requirement without placing too much of a load on the system but plan on waiting until the library as is is accepted before I address that.
Let me know if you have any problems. I’ve been running with it successfully for weeks, but everyone’s system is different.
Thanks. I only have 2 timers in use right now.
I know Scott got excited but you guys like diving deep into the programming but I am not that skilled. I am more interested in getting things to work well & reliably.
I am now running on a Debian Hyper-V VM on my son’s Windows server using a Zooz controller I received for free to add to our database. Zooz and their store thesmartesthouse.com are really working to recognize OpenHAB as a supported system They have sent me 2 updated wall switches and promise new products on the day of release so we can add them.
https://www.thesmartesthouse.com/collections/works-with-openhab
We really need to get some support documentation on the Zooz site for including the devices. The store has some discontinued European devices I am trying to get for the Foundation to use in demonstrations.
I tried to get more basic and have most things working in testing except for the first rule suggested by Scott. I modified which astro events are used and now it will not trigger the switch ON. Where did I go wrong?
from core.rules import rule
from core.triggers import when
@rule("Jython IsItDark)", description="This triggers the IsItDark Switch based on sunrise and sunset times")
@when("Channel astro:sun:local:civilDusk#event triggered START")
@when("Channel astro:sun:local:civilDawn#event triggered START")
def is_it_dark(event):
events.sendCommand("IsItDark", "ON" if "civilDusk" in str(event.channel).split(":") else "OFF")
I don’t see anything wrong. I’d start with adding some loging to the Rule. If the Rule is triggering, break the line up a bit. Log out what event.channel is, for example.
I think I will break it out into 2 rules if it fails again this evening.
The original rule early on here used set but I think I will prefer civilDusk. The rule triggers, but is always OFF.
OK, if it is always getting an OFF command that means that “civilDusk” isn’t in str(event.channel).split(":"), so log that out to see what event.channel actually is.
I think this says it should be.
2019-11-05 17:17:00.009 [vent.ChannelTriggeredEvent] - astro:sun:local:civilDusk#event triggered START
2019-11-05 17:17:00.016 [.event.RuleStatusInfoEvent] - ad0ffaae-6c0c-473b-a371-9ce039267a14 updated: RUNNING
2019-11-05 17:17:00.022 [vent.ChannelTriggeredEvent] - astro:sun:local:set#event triggered END
2019-11-05 17:17:00.030 [ome.event.ItemCommandEvent] - Item 'IsItDark' received command OFF
2019-11-05 17:17:00.034 [.event.RuleStatusInfoEvent] - ad0ffaae-6c0c-473b-a371-9ce039267a14 updated: IDLE
No, “civilDusk” isn’t in that array, “civilDusk#event” is. You only split on “:” so the last element of the split is everything after the last “:”.
But that is the events.log, not a log from your actual Rule. It is always best to find out what stuff is as close as possible to where the problem occurs rather than relying on “evidence” from farther away. You have no idea if whatever populates event.channel uses the same syntax or modifies the event from how it’s logged by the event bus in events.log.
But the same statement worked with set which had the same suffix.
The rule here worked.
Which is why it is important to see exactly what event.channel is. Right now all you know is “civilDusk” is not in str(event.channel).split(":"). I don’t care what worked before. I don’t care what events.log says. I don’t care what you think should work.
It’s not working. To find out why, you need to log out what event.channel is. Nothing else is going to tell you why it isn’t working.
When debugging coding problems, don’t reason about it, don’t think about it, don’t assume you understand what is going on (if you did there wouldn’t be a problem). You need to test and verify everything systematically to find out what is different between what you think is supposed to happen and what is actually happening.
I set a log entry like this for tomorrow.
from core.rules import rule
from core.triggers import when
@rule("Jython IsItDark)", description="This triggers the IsItDark Switch based on sunrise and sunset times")
@when("Channel astro:sun:local:civilDusk#event triggered START")
@when("Channel astro:sun:local:civilDawn#event triggered START")
def is_it_dark(event):
is_it_dark.log.info(str(event.channel).split(":"))
events.sendCommand("IsItDark", "ON" if "civilDusk" in str(event.channel).split(":") else "OFF")