if scope.UnDefType.NULL == bodyState or scope.UnDefType.UNDEF == bodyState:
body = ''
PE.logInfo("*** body is bad: {}".format(scope.items['EmailBody'].toString()))
else:
body = bodyState.toString()
In OH, a post_update doesn’t trigger an event on the event bus but a send_command does. I am a bit surprised that both oh_post_update and oh_send_command work in the same way. My guess is that to OH, this is a value change and as such it triggers an event. But from the HABapp point of view, an oh_post_update won’t trigger an event within HABapp. Am I correct?
Of course it does, you just might not see it in the event.log.
It’ll create an event in OH and this event is then mirrored back to HABApp.
It can be a timing issue since immediate requests can be processed out of order.
Just send the final update that you trigger upon a little bit later
How’s everyone doing? It’s been a while since we see traffic in this thread.
I just deprecated all my Jython rules and modules; almost all of them had been migrated to HABApp-based framework (close to 10K of code). And everything has been going great!
I think this is a good sign. Things seem to be mostly stable and while the docs still could use some overhaul they seem to answer most of the questions.
One of the last missing puzzle pieces was the event filter which further reduces the logic in the rules.
For the future I’ll focus on fixing bugs (and probably introducing new ones ) and reworking some old logic (e.g. scheduler is high on my list).
And as always - If someone needs help with a rule just ping me here.
Jython is python 2.x and this is end of life for quite some while (Sunsetting Python 2 | Python.org)
With a native python 3.x solution it is easy to integrate any modern python library.
I took a little look at HABApp a while ago, but couldn’t see an obvious way to have events triggered by multiple items or groups, and then identify the item that had triggered the event. Can that now be done?
Here you can see that the event passed into the callback contains the triggering item.
You can subscribe with the same callback to multiple items or create a rule that groups things logically.
e.g.
for name in ('MySwitch1', 'MySwitch2', 'MySwitch3'):
SwitchItem.get_item(name).listen_event(self.my_callback, ValueChangeEvent)
# or if its different items you can use the base class
OpenhabItem.get_item(name).listen_event(self.my_callback, ValueChangeEvent)
Also HABApp allows you to trigger when an item is constant since last update/change for a certain ammount of time which makes so much timer stuff obsolete it’s mind blowing
Dan, it is good that Jython is working fine for you. It was mainly working for me as well, but there were a few annoying issues with the integration of the script engine and OH, and then there is the issue of the Jython implementation of Python itself. I wrote a post comparing the two at HABApp vs JSR223 Jython. Ultimately it is a personal choice .
@yfaway Sort of:
I’ve a small PR open since 11th of January that fixes the performance issues for basic auth in openhab but somehow the openhab maintainers are very selective of whom they want to contribute and refuse to review the PR (this is the second PR which got some improvements, the first PR was opened even earlier).
This would have been a quick fix for all the basic auth issues and make HABApp work with the expected speed again.
Using a token in the header is on my list, but I have to do some investigation first because I’m using multiple libraries and I am currently worried that I have to implement the handling in one of them (SSE event listener) myself.
It definitely is.
On the one hand it adds additional complexity since it’s an additional tool and also not everything is exposed through the rest api (e.g. actions) so for very rare cases it’s necessary to work with proxy items.
On the other hand it’s a complete home automation rule engine written in python and while it does almost everything different than the build in rule engine it (imho) does everything better:
Error messages, timers, multiple “expires” per item, time stamps for last_change and last_update of an item, dynamic rule creation, accessing item per name, parameter files, textual thing configuration etc…
@dan12345
It’s a steep learning curve but I really encourage you to try it out. I’ve been on the jsr223 track since openhab 1.8 and after the first enthusiasm it almost killed my excitement for home automation.
You can install HABApp on your main PC and connect remotely to your openhab instance (if you want in listen_only mode so it doesn’t make changes). That way you can play around and try to get the hang of it without having to make changes to your installation.
This rule shows you that it’s possible to write very compact and readable code that covers a somewhat complex use case.
) and reworking some old logic (e.g. scheduler is high on my list).
.