HABApp - Easy automation with openHAB

Apps & Services 3rd Party
,
243

Good news everyone!

I switched the build pipeline to github actions, so there are now arm builds, too (@Tomibeck).

@nick_wootton:
With the updated dependencies it should also run on python 3.9.

0.16.2

  • updated dependencies
  • added armv7 and armv6 as docker builds
  • small fixes
  • activated tests for python 3.9
2 Likes
244

The main selling point for HABApp is that you can use python :wink:

Besides Python 3.x vs Python 2.x, how would one pick between HABApp and the JSR 223 support for Jython?

245

I do not mean this in any way to disrespect Sebastian, who has put a lot of time and effort into HABapp, but scripted automation with Jython can do everything HABapp can do and a LOT more. This is due to HABApp being limited by its use of the REST API to communicate with OH, which is also what is used by the UIs. Scripted automation, which can be used with several scripting languages, uses the automation API for creating rules, but it also has full access to not only all of the OH classes, interfaces, and services, but any Java or Python2 libraries that you’d like to use. The Jython interpreter is based on Python 2.7, but when it comes to writing automation, this is not much of a limitation. Jython3 is also being developed and graal-python will be integrated.

246

HABApp is written in pure Python which means you can do anything you can do in python.
It’s possibly to import any library from pypi and use it together with your rule.
What initially started as an abstraction of the openhab connection has become a general purpose rule engine.
The focus of HABApp is to quickly create error free rules and to achieve this it provides full type hinting, auto complete and checks when used with an IDE and abstracts certain functionality:

  • want to use the timestamp when it was the last time an item was changed

    SwitchItem.get_item('MySwitch').last_change

  • want to run something on weekends at 8

    self.run_on_weekends(time(hour=8), my_func)

  • want to run something every two hours but only between 8 and 16 o’clock

    self.run_every(timedelta(hours=2), my_func).earliest(time(hour=8).latest(time(hour=16))

  • 


As Scott pointed out, it’s not possible to do everything with HABApp, because unfortunately the REST-API is in some aspects quite buggy and incomplete e.g. the maintainers don’t expose an “actions” endpoint.
For me it’s not a problem because I can always link an item to a channel and then use the item to interact with the device instead of the action. But it’s still a valid point.

While there might not be much difference and limitation for you, I wouldn’t have spent hundreds of hours developing HABApp if this were true (for me). Python 2.7 was released 2010 and many aspects of the syntax have been deprecated since.

To answer your initial question:
I guess it comes down to your personal preference! I could never go back to using jsr223 and for Scott it’s sufficient. But I guess we’re both biased so you have to try them out yourself.

247

Have you thought about contributing an actions endpoint to the REST API?

I do see the value of Pyhon 3.x and it would be fun to see if I could do something like hook up TensorFlow into my home automation some day. Right now I’m only at the beginning.

248

I don’t know any java so unfortunately I can’t help there.

249

Languages are easy to learn :slight_smile:. But you’re likely very busy with HABApp.

250

I tried creating a DMX binding once and I really didn’t like it.
Maybe you can jump in 
 :wink:

251

If I use HABApp and it limits me, sure. Right now though I am trying to learn the concepts using OH3 which isn’t very documented
 so it’s slow.

252

There really is no limitation at all, since you can use executeCommandLine in scripted automation, using any scripting language, to call Python3 scripts. I do not have empirical evidence to support this, but because HABapp interacts with OH through the REST API, I expect that you will find that scripted automation is significantly faster, which is a very important factor for automation. It all comes down to a personal choice though
 but both can be used simultaneously!

253

I just switched over to HABApp only two weeks ago and already have migrated all my automation I previously had in openhab. Python 2.7 would have been a major limitation for me. I like the modern python 3 approach in HABApp, the error handling capabilities, the ability to use every library from the python universe via pip.
@5iver Regarding the use of execute Commandline there is a fundamental difference. While HABApp has instances of rules and therefore can have internal state a simple CLI would be stateless. Prior knowing HABApp I even created for more complex automation tasks python solutions that had a rest interface and communicated with those from openhab with the HTTP binding.

At the end it really is about personal preference and I won’t say the one is better than the other. Communicating via a rest interface is for me no disadvantage as it is the default interface in a services world. Regarding speed you might be right and it would depend on the task you won’t to accomplish. For me the roundtrip times are absolutely sufficient.

1 Like
254

Just my 2 cents, additionally to what was said already, as I am using a mix of both systems:

cool in HABapp:

  • I really like to be able to debug in HABapp via Intellij. Makes it much faster to develop for me.
  • HABapp has some nice helpers for larger installations, eg to automatically add specific channels / items to a certain type of sensor
  • HABapp can be run / debugged on a different machine in addition to the main instance on the OH server. This allows adding new rules in a development mode without disturbing the old ones
  • HABapp never had problems with the startup sequence (where there was always problems for me with JSR223, only solved by adding a large delay or restarting OH)
  • Keeps REST development on track as its (probably) most demanding user
  • Very good maintenance by @Spaceman_Spiff

cool in OH3:

  • The new OH3 internal scripting does not require any additional installation / updating of anything
  • An Editor in the UI does not need any IDE installations / deployment of scripts and can potentially also check / help / inform about dynamic fields like item names etc which is hard (but possible, see VSC sitemap plugin) in HABapp IDEs
  • Internal should mean less moving parts, eg reusing of OSGI livecycle, and less resource usage
  • Can probably use new features / entities immediately, does not have to wait on REST updates
  • Might allow interaction with UI-built automation elements (eg Blocky rules)
  • Visibility by core devs can result in good quality
  • Very good maintenance by @5iver
4 Likes
255

Yup using HABApp with Python 3.9 seems to start OK. My few simple rules run without issue.

1 Like
256

Thanks for reporting back @nick_wootton

257

I don’t see any support for metadata. Is this planned or currently in the works?

Found it, but it’s not listed anywhere in the docs.

Found in HABApp.openhab.connection_handler.func_sync but exposed as HABApp.openhab.interface.get_item

def get_item(item_name: str, metadata: Optional[str] = None) -> OpenhabItemDefinition:

The return format is not clear though, even in OpenhabItemDefinition:

class OpenhabItemDefinition(BaseModel):
    ...
    metadata: Dict[str, Any] = {}

The metadata property of OpenhabItemDefinition is the raw content of the metadata key in the REST response turned into a dict:

{
    'namespace': {
        'value': '', 
        'config': {
            'key': 'value'
        }
    }
}
258

I definitly want to try habapp, but at the moment have problems to install it on my system and i am at the very first beginning with python environments. Maybe someon is able to give me some hints to do it in a god / right / professional way.

My Problem: I am running a Debian 11 VM on a Synology Rackstation. This works so far very well. Python 3.8.6 is installed and i found the information that the venv needs to be installed prior any other tasks. Checked and Done.

Now starts the problem. As a standard user i change to “/opt” and try “python3 -m venv habapp”. Then i get a no permissions error what i am able to understand, because “/opt” belongs to root and my user is not root.

If i add “sudo” in front of the command the venv is created. Activation then works without “sudo”. With “sudo” it does not work.

Next step is to update pip and this does not work. As user i get a permissions error, with sudo the command doesn not work.

So i think there should be a “right” way to start a vens in “/opt” on a debian sytsem, but i can’t find it until now.

So any help is appreciated.

Thomas

259

Can’t you use the docker image on your Rackstation? Then you only have to mount the folder into the container and everything else is done for you.

The folder /opt/ is only a suggestion, because it works out of the box with openhabian.
You can use any folder you like. I’d create a suitable one and set the permissions correctly.
Make sure your used user (e.g. openhab) has read/write access. I use the conf folder from openhab and just created a subfolder HABApp.

260

Maybe the hint to openhabian is the right one for me. I will describe my configuration later.

Thanks

261

The hint to openhabian did the trick. openhabian changes the ownership of the /opt folder from root to openhab. and then installatione worked as decribed.

Now i start to configure habapp. rule into oh conf folder, logs to the /var/log/
 folder and so on.

Thanks for your help

262

Now i get the following error

Nov 12 21:44:37 openhab habapp[118303]: AssertionError: /opt/habapp/conf
Nov 12 21:44:38 openhab habapp[118303]: Error loading logging config: Unable to configure handler 'EventFile'
Nov 12 21:44:38 openhab habapp[118303]: /opt/habapp/conf

and i have no clue where to search. The logging yaml is the default created. Any hints? Any missing information?