from HABApp.core.types import RGB
col = RGB(5, 15, 255)
print(col)
print(col.red) # red value
print(col.r) # short name for red value
print(col[0]) # access of red value through numeric index
new_col = col.replace(red=22)
print(new_col)
print(new_col.to_hsb())
The main benefit is that the types can be posted directly to openHAB and will automatically get converted to the appropriate openHAB representation.
E.g.
from HABApp.openhab.events import (GroupItemStateChangedEvent, ItemStateChangedEventFilter)
# Get the group items to trigger on
for subgroup in self.openhab.get_item('gArea_Trigger').members:
group_item = GroupItem.get_item(subgroup.name)
# Trigger on item changes
group_item.listen_event(self.group_item_state_change, GroupItemStateChangedEvent)
self.log.debug(group_item.name)
now throws an error:
ValueError: Argument event_filter must be an instance of event filter (is <class 'HABApp.openhab.events.item_events.GroupItemStateChangedEvent'>)
Cannot upgrade habapp from 0.31.2 to 1.0.4
i was using openhab 3.3.0 M4 and i decided to upgrade to 3.3.0 release.
I’ve read that habapp needs to be updated but apparently i cannot either by using openhabian-config or following the instructions of the habapp readthedocs site.
python3 -m pip install --upgrade habapp
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already satisfied: habapp in ./lib/python3.7/site-packages (0.31.2)
I have also tried to uninstall with openhabian but with no success.
Is my installation too old and I need a fresh install?
Yes, from 1.0 on >= python 3.8 is required, that’s why it won’t update your installation because the last supported HABApp version for python 3.7 is 0.31.2.
Hey Habapp looks very cool. At the moment i am using JSR223 Jython Scripting, but i am annoyed that it is stuck on Python 2 and that the helper libraries are not maintained anymore. Thats why i am considering to go for Habapp.
What major limitations do i have to expect? Is there maybe already a list about limitations?
Is Habapp fast so that there are no big delays for example when i switch on a light via a Habapp rule?
Are there already rule decorators or are these planned? I liked these a lot when using the Jython helper libraries .
Typical round trip time (HABApp → openHAB → HABApp) is between 20 and 50ms on my odroid.
I don’t know. But since I wrote it I’m biased und use HABApp how I intended it to be used.
No - I explicitly chose not to use these.
Every rule is a HABApp.Rule instance.
It’s much clearer how things work that way.
Be aware: HABApp is not jsr223 nor does it attempt to re-implement the helper libraries.
It’s a stand alone rule engine and things work different than in jsr223.
It’s better, but that’s of course my personal opinion.
Just take the time and effort to read (all!) the docs and follow the examples.
Don’t try to migrate jsr223 rules one to one to HABApp but rather use the different techniques HABApp provides to slim your existing rules, e.g.:
A less biased answer - habapp is much much faster than openhab rules or using the jsr223 helper libraries. Easier, too. And fantastic to be able to use any python library you want, and not be limited to the few available for jython.
Only disadvantage is that it can’t run actions, so you need a few simple Rules DSL scripts to do that. Not really a problem.
is out!
I’ve added some convenience functions and implemented some cleanup.
# This construct
if self.my_item != 'overwrite value':
self.my_item.post_value('Test')
# ... is equivalent to
self.my_item.post_value_if('Test', not_equal='overwrite value')
# This construct
if self.my_item == 'overwrite value':
self.my_item.post_value('Test')
# ... is equivalent to
self.my_item.post_value_if('Test', equal='overwrite value')
Changelog
Added new item function post_value_if and oh_post_update_if to conditionally update an item
Added support for new alive event with openHAB 3.4
Reworked file writer for textual thing config
Added support for ThingConfigStatusInfoEvent
MultiModeValue returns True/False if item value was changed
Can I please bother you with a quick feature request?
I’ve an MQTT-triggered habapp rule which, amongst other things, loads an image file from the network into a variable. Problem is that, if there’s an error, the habapp log becomes filled with the image file binary, which makes my log reader cry. Is there anyway to cap habapp logging so any lines longer than (say) 1,000 characters are trimmed?
Is there any backward incompatibility? Your framework has more users now than before (great! but is also a curse) so it would be great to document that, even if it is simply a line that say “Backward compatible with existing code.”
I don’t fully understand. Do you get an error when updating the image and the image is included in the trace back or do you get any error and the image is included?
I try to do semantic versioning meaning that 1.0.X should all be compatible.
Also if there is nothing about a breaking change in the change log it means that it’s backwards compatible.
However due to the great flexibility of HABApp sometimes changes have unexpected side effects depending on the usage by the user.
So I try to do my best to communicate breaking changes and most of the time everything is backwards compatible.
Hi - I mean that if I have any kind of error (in my case it was a KeyError), the debug logging includes the complete contents of all variables, and if one of the variables is enormous (an image file) then the log becomes a problem. Is there any way to e.g. put a maximum length on each line of the log?
