Thank you @steve for your sample code! Your openhab.actions jython module solved my problem with actions which was using the pushover action. Your module makes it really simple:
from openhab.actions import Pushover
Pushover.pushover("Test")
This is impressively easy :). I think I can finally start converting my jython code over to OH2!
Can anybody tell me how to set a rule’s id? My logging shows a lot of lines alike
2017-07-28 21:44:46.058 [DEBUG] [.automation.core.internal.RuleEngine] - The trigger 'wRegen' of rule '16d0f281-d8fb-4649-a064-eedd8cbcb2b0' is triggered.
I’m using @steve1’s openhab2-jython library where I’ve found the correct place to set the trigger name, but even setting
self.name or self.id won’t change the above logging to a more readable form. My rule init looks like this:
An internally-generated unique SmartHome Rule UID is what’s logged from the rule status events, not the rule name. I’ve added a small utility function to my openhab2-jython repository that will add a prefix to this UID so that logs are easier to interpret.
The following example shows how to use it (see openhab.rules.set_uid_prefix). By default, the function uses the rule type name as the prefix. However, you can provide an optional second argument to specify a custom prefix.
scriptExtension.importPreset("RuleSimple")
scriptExtension.importPreset("RuleSupport")
from openhab.rules import set_uid_prefix
class TestRuleWithUidPrefix(SimpleRule):
def __init__(self):
set_uid_prefix(self)
# Only for logging side-effects
automationManager.addRule(TestRuleWithUidPrefix())
I would just like to send a thank you to all of you who have contributed to the JSR223 bundle. Finally I can avoid having two openHAB installations! Actually I have killed my openHAB 1.8.3 in the beginning of the week, and today I have finalised a first rough port of my scripts in openHAB1. Actually I have started from scratch, bot I now have the close to 100% coverage of what I had in openHAB1. I am very happy!
I was just wondering if there would be some place to share script libraries that we create. @steve1 has already shared his work on GitHub, that have been to great help to me (thanks for that!)
I need to clean my code and then I would also like to share my work as well - hopefully somebody would be inspired or maybe even want to use the code.
What I have until now is án advaced mechanishm to control my indoor and outdoor light (When I am out the light can run on a schedule, and when I am home, it doesn’t. I also have rules, that would cause light to turn on when a pir sensor registers activity.
I’m trying to get at an item.historicState that was PersistenceExtensions (alias: pe) in OH1.
Is this also available yet in OH2? Could you give advice how to use it?
Thank you for your support and making jython scripting work.
@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?
@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.
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.
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]
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.
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.