From the source code, it appears that the automationManager does some adaptation to the registered rule for scripting purposes. Adding the rule directly to the ruleRegistry may have been the original issue. Grabbing the last registered rule will work most of the time but it also may fail nondeterministically since the registry could be updated from other threads and the most recent rule may not be the one you want.
I have setup -Dpython.path=c:/Progs/Openhab2/conf/automation/lib
and put different libraries in the lib folder.
in the \jsr223\ - folder I have two files and in both I do an import testModule
Library seems to be loaded twice and does not share any variables between instances.
This seems to be a very odd behavior. How do I properly share the module?
Please share! Also, include your OH version because I this area of the code has been/is being refactored. With a recent snapshot build, I can get the UID, but haven’t tried enable/disable/remove.
I’m on vacation so I can’t try out the code. Just looking at it though, my guess is the issue is related to circular dependency between the testModule package (which imports the test_file module) and the test_file module (which imports the testModule package). Jython might not handle this scenario gracefully.
Hey can you share a code example how you set a custom UID to your rule? Rule Class seems to have a constructor which supports adding a custom UID, but SimpleRule Class seems not.
Do you use SimpleRule? If i pass a string to it, it complains about not expecting an argument.
from org.eclipse.smarthome.automation import Rule as OpenhabRule
def set_UID(self, val):
# set as UUID of Rule
uid_field = type(OpenhabRule).getClass(OpenhabRule).getDeclaredField(OpenhabRule, "uid")
uid_field.setAccessible(True)
uid_field.set(self, val)
Unfortunately this does not work anymore: java.lang.NoSuchFieldException: java.lang.NoSuchFieldException: uid
Has anyone figured out another way to set the UID?
I poked at this for a bit, but in the end decided it was not worth more effort. It was really the Name and Description fields that were useful for me. I removed the setting of the Rule UID here, since it was throwing the NoSuchFieldException, and plan to change the logging to include the Rule Name to make the logs more readable. Your post reminded me of the logging, which I’d completely forgotten about!
No. I haven’t dug into it since I just launch functions on script startup, rather than using a rule.
The tricky part is getting the uid, which is a string. You could paste them in from Paper UI, or if you know the name of the rule and you’ve kept them unique, you can do this…
scriptExtension.importPreset("RuleSupport")
ruleUID = filter(lambda rule: rule.name == "Alert: TV turn off timer alert", rules.getAll())[0].UID
from openhab import osgi
ruleEngine = osgi.get_service("org.eclipse.smarthome.automation.RuleManager")
ruleEngine.setEnabled(ruleUID, True)# enable rule
ruleEngine.setEnabled(ruleUID, False)# disable rule
Unless I’m mistaken, you should be able to get the rule’s UID by invoking the method getUID() on the object returned by the method addRule(). That UID could then be added as a new attribute of the function object or, perhaps more useful, saved to a module-scope dictionary of rule-name:rule-uid key-value pairs before returning from the rule() decorator.
What I was meaning as tricky was the actual use of them. I was curious how Sebastian was planning to use them.
One use case would be to have a TimeOfDay type rule, and when the ToD changes, you could enable/disable certain rules. For this, I’m thinking of adding a tag to each pertinent rule to group them. Then to perform and action on them, such as enable/disable, you could filter all rules from the registry by a particular tag, and iterate through them to pull out the UID and enable/disable.
Having the UID as a function attribute or in a UID:name dict are good ideas and might be helpful, but I’m not clear on how/if it would be used. I think tagging the rules could be more useful. Having a UI to add/remove rule tags would be really nice. BTW… in case people haven’t noticed… we can enable/disable Jython rules through PaperUI.
One use that came to mind was as a means of implementing a one-shot trigger rule when the rule UID is saved as an attribute of the callable object known as function in the rule decorator. A one-shot trigger rule’s action could disable the rule as it’s final act before returning.
That would be handy! I was thinking it would be cleaner to just include the rule UID in the event object, but I couldn’t get that to work. So, I added the rule UID as an attribute of the function. I also added a tags parameter to the rule decorator. I’ve tested them but haven’t merged, if you’d like to review.