@Jue_Wis I would like to add pe.changedSince and pe.minimumSInce/maximumSince to your list of missing functionality from OH1. 
I have found out that the missing functions are in package org.eclipse.smarthome.model.persistence.extensions, but I’m lacking the python skills to extend the library @steve1 has created for the persistence extensions.
If you can spare some time, would you take a look and extend your library for these functions, please?
in JavaScript I use:
var DateTime = Java.type("org.joda.time.DateTime");
var pe= Java.type("org.eclipse.smarthome.model.persistence.extensions.PersistenceExtensions");
print("changedSince: " + pe.changedSince( [ANY ITEM SAVED IN DB], DateTime.now().minusDays(3) ) );
Similar in jython: (untested!!)
from org.joda.time import DateTime
from org.eclipse.smarthome.model.persistence.extensions import PersistenceExtensions
print "changedSince: " + PersistenceExtensions.changedSince( [ANY ITEM SAVED IN DB], DateTime.now().minusDays(3))
Hope this helps.
Helmut
@lewie and @ralle Thank you for the helpful tips.
Access to historicState is now working with jython.
maximumSince, minimumSice and changedSince work in the same way.
scriptExtension.importPreset("RuleSupport")
scriptExtension.importPreset("RuleSimple")
import org.joda.time.DateTime
from org.slf4j import LoggerFactory
from openhab.rules import set_uid_prefix
from org.eclipse.smarthome.model.persistence.extensions import PersistenceExtensions
class OnWeatherUpdate(SimpleRule):
def __init__(self):
set_uid_prefix(self)
self.name = 'OnWeatherUpdate'
self.id = 'weatherupdaterule'
self.description = 'rule to execute when the rain item is updated'
self.triggers = [
Trigger("OnUpdate", "core.ItemStateUpdateTrigger",
Configuration({ "itemName": "Niederschlag"}))
]
def execute(self, module, input):
_item = ir.getItem("Niederschlag")
_rainlasth = PersistenceExtensions.historicState(_item, DateTime.now().minusMinutes(60)).state
events.postUpdate(ir.getItem("Rain_Last_H"), _rainlasth)
_rainlast12h = PersistenceExtensions.historicState(_item, DateTime.now().minusMinutes(720)).state
events.postUpdate(ir.getItem("Rain_Last_12H"), _rainlast12h)
_rainlast24h = PersistenceExtensions.historicState(_item, DateTime.now().minusMinutes(1440)).state
events.postUpdate(ir.getItem("Rain_Last_24H"), _rainlast24h)
LoggerFactory.getLogger("org.eclipse.smarthome.automation.weatherupdate").info('{} {}'.format(_item.label, "was updated"))
automationManager.addRule(OnWeatherUpdate())
Now the time has come to retire the openHAB 1 server.
Thanks again for your help.
@Jue_Wis Thanks for your code sample.
Has anybody found out how to create a timer in jython? That seems to be the last roadblock on my way to switch off OH1.
Have you tried using standard Python Timers or the sched module? I haven’t tried it (and my computers are packed for a move) but it should work. Also note that one advantage of Jython is that there is no Global Interpreter Lock (GIL) so threaded programs work even better than CPython.
https://docs.python.org/2/library/threading.html#timer-objects
@steve1 your solution works for me. Thanks for pointing me towards this direction.
Here’s my sample code:
from threading import Timer
def timerScript():
logging.info("Timer fired")
myTimer=Timer(10,timerScript)
myTimer.start()
logging.info("Timer created")
myTimer.cancel() will cancel the running timer.
I was trying to replace a bunch of rules with one jython script and added multiple triggers to the list of triggers.
It seems that only the first trigger is registered and executed.
It that the intended behaviour?
ITEMLIST = ['Temperature_GF_Library','Temperature_GF_Wigarden','Temperature_GF_Corridor',
'Temperature_GF_Toilet','Temperature_GF_Living','Temperature_GF_Eating','Temperature_GF_Kitchen',
'Temperature_FF_Bath','Temperature_FF_Office','Temperature_FF_Child','Temperature_FF_Bed','CC_humi','Temperature_Outside']
...
self.triggers = [Trigger("OnUpdate", "core.ItemStateUpdateTrigger",
Configuration({ "itemName": _item})) for _item in ITEMLIST]
@Jue_Wis I do the same like this:
self.triggers = []
for item in list:
self.triggers.append( ItemStateChangeTrigger( item, None, item ) )
(this is typed from memory, and therefor untested )
BTW the above is using @steve1 library code.
I’m not sure, but it may be a requirement to have a unique identifier for each trigger of a rule (my wrappers generate a unique ID).
Looks like there has been tremendous progress on this since I last checked in. I pulled down the Docker image of the latest 2.2.0 snapshot, added the experimental rules engine, added the Groovy jar files, and magic, the example script worked. Nice.
I’m going to start playing around with porting my 1.x groovy rules, but need a little guidance.
What is the best and/or easiest way to create a jar file such that the classes are available from my groovy rules?
I have some “base classes” that I have written (in Java) to share common functionality and easily create new rules for specific use cases For OH 1, I had to fork the openhab1-addons repo and add my classes. Since OH2 has significant architecture changes, I thought there might be a better way.
Thanks,
Doug
I’ve never used Groovy, but it looks like some interesting ideas on this page:
It sounds like it might be possible to put the jars into $OPENHAB_HOME/.groovy/lib too (???).
It didn’t work under OH1. Something was preventing them from actually getting on the classpath used by the rules. Something with the framework, I think.
Honestly, I should have tried that before I posted… It’s an easy thing to try - create a jar file and throw it in with the rest of the groovy libs. I’ll give it a shot tonight.
No luck just dropping a jar in with the groovy ones. I think OGSi prevents that. I read a bit about creating “bundles” and whatnot, but looks like I have a lot of reading to do before I can go down that route.
Doug
Did you try the RootLoader technique described in the article?
Yes. I thought that had a good shot at working since it wasn’t something I had tried with OH1. It’s also entirely possible I messed something up as there were a fair number of distractions at home when I was trying it. I’ll try it again if I get a chance, as it’s a good technique to have in the toolbox.
For now, I ended up using the same approach I used on OH1, which is just to put them inside the existing rule engine bundle, build via maven, and replace the distribution jar with my own. That took longer than it should have because I didn’t know I needed to delete the OH2 cache directory for it to pick up my changes. (Maybe deleting the cache would have helped with the RootLoader approach?) I wasted a couple of hours because of that.
My current plan is to fork the smarthome repo and push some changes up for comments once I get a little further with my approach.
Thanks,
Doug
In OH1, I could
import org.openhab.core.jsr223.internal.shared.Openhab;
then in my base class do something like:
Openhab.sendCommand(item, commandString);
to access the sendCommand and/or postUpdate functions.
In OH2, sendCommand() and postUpdate() are passed into the JSR223 script in a “magic” events variable, which seems to be of type org.eclipse.smarthome.automation.module.script.defaultscope.internal.ScriptBusEvent
I want to sendCommand() and postUpdate() from my base class, which exists outside of the script.
I searched through a lot of code in the IDE, and I could not find a similar static way to instantiate the events variable - type ScriptBusEvent. There is a BusEvent class, which does have static operations for sendCommand() and postUpdate() but that’s not in the imports for the bundle… It looks very similar to ScriptBusEvent, other than it is has static methods and ScriptBusEvent does not.
Any ideas on how I can call sendCommand() and postUpdate() outside of the scope a script? That is, in my own external base class? I could probably require the events variable to be passed via constructor, but I was hoping just to “take care of it” internally.
Thanks,
Doug
I tried something it little different last night. I used the 000script approach from Simon’s examples to create a Groovy
script that always executes first. In that script, I defined my base class, ItemRule. Since the script has access to the events variable, I can push that into ItemRule, and then it will be able to sendCommand() and postUpdate(). Then in the same file I created a new class extending ScriptExtensionProvider and created a preset with my class in it. Then my other scripts could importPreset(“Doug”) and access my class definition.
def onRule2 = ItemRule.newInstance("MySwitch")
automationManager.addRule(onRule2)
As convoluted as that sounded, it worked. BUT…
I don’t want to just create a new instance. I want to extend it. But
class ItemRule2 extends ItemRule { }
won’t compile because of “unable to resolve class ItemRule”
I learned a lot, but I think I’m stuck with this approach. I tried a bunch of different things (imports, etc.), but just couldn’t get ItemRule visible as something I could extend.
I think i’m just going to move on and accept that I’m going to pass the events variable in the constructor to my base classes for now.
Anybody know how to find and use an Action from groovy?
I suspect that will be the next thing I bump into. I took a look through Steve’s OSGi python classes, but couldn’t mentally translate that into a Groovy approach due to a lack of experience with bouth OSGi and Python.
Thanks,
Doug
Answering my own question after more than a bit of reading code…
My solution was to just use BusEvent and its static methods in my base class. And I’m using ScriptServiceUtil to get the item registry, so I don’t need to pass that in either.
So, I’m making progress on moving my base classes over from OH1 to OH2.
Doug
@steve1 I noticed you added a rule decorator to your library in openhab.rules. Could you please add an usage example to your Readme? I tried using the decorator in the same way as your decorator for Jython/OH1.8, but that doesn’t work.