HABApp - Easy automation with openHAB

A little bit better, yes!
But, does it have to say “Optional”? That still makes me think it’s something I may fill in, not something that comes from openHAB.
Not sure what the limits of the documentation generator are, but if the output was like this:
label (str) – Item Description

…that would be clear as day.
Actually, if we compare it with the “Parameters” description later on the same page, where you describe every comparison operation, I think it should be possible to add descriptions for all the Item class variables, which are a lot less obvious, at least to me. :slight_smile:

Sebastian, thank you again for HABApp! I cannot say this enough times.

It’s funny, although OpenHAB is my basic user interface, and cloud connection, I can say for sure that my house runs on HABApp and MQTT. OpenHAB does very little other than being the user interface. All my devices (many hundreds) are all MQTT. OpenHAB is aware of some items as Things, but for the majority it is only aware of manually created items in .items files, which trigger or are polled by scripts under HABApp scripts which do the actual work of intelligently controlling items in groups, using highly layered, structured logic.

1 Like

It’s the datatype of the variable. It’s an optional str, e.g. it can be None or an instance of str.
If you don’t configure a label in the item definition the attribute is None, else the string you configured.
Keeping the optional is crucial because it provides the information that it can be None

Should be doable - I’ll try to come up with something. For me it was so obvious what it’s supposed to be that I didn’t think a further description is necessary. Writing good docs is hard! :wink:

@leif Like this?

grafik


I’d love to see and talk about your (and other HABApp users) implementations. Maybe we should do a remote HABApp user event where we talk about stuff and some people get to share their ideas, implementation and how they use it?
Is that something that would be interesting? If we get 5+ people to come together it could be a fun event.

1 Like

Great idea :+1:

Good idea! I would also join :slight_smile:

That could be a lot of fun! I’m in.

Your variables description is perfect! Nice job. Very clear.

Good news everyone! HABApp 23.09.0 is out!

1 Like

I’ve migrated from OH 3.4 to 4.0.3 and HABApp to 23.09.02 (Docker).
No Problems with OH so far, but starting up HABApp prints out:

[2023-09-26 21:52:34,365] [                   HABApp]     INFO | HABApp Version 1.0.6
[2023-09-26 21:52:34,370] [   HABApp.mqtt.connection]     INFO | MQTT disabled
[2023-09-26 21:52:34,371] [HABApp.openhab.connection]     INFO | Verify ssl set to False!
[2023-09-26 21:52:34,400] [HABApp.openhab.connection]     INFO | Connected to OpenHAB version 4.0.3 (Release Build)
[2023-09-26 21:52:34,833] [           HABApp.openhab]    ERROR | Error time data '2023-09-26T21:50:17.629834131+0200' does not match format '%Y-%m-%dT%H:%M:%S.%f%z' in map_items:
[2023-09-26 21:52:34,833] [           HABApp.openhab]    ERROR | --------------------------------------------------------------------------------
[2023-09-26 21:52:34,833] [           HABApp.openhab]    ERROR | Traceback (most recent call last):
[2023-09-26 21:52:34,833] [           HABApp.openhab]    ERROR |   File "/usr/local/lib/python3.10/site-packages/HABApp/openhab/map_items.py", line 61, in map_item
[2023-09-26 21:52:34,833] [           HABApp.openhab]    ERROR |     return cls.from_oh(name, value, label=label, tags=tags, groups=groups, metadata=meta)
[2023-09-26 21:52:34,833] [           HABApp.openhab]    ERROR |   File "/usr/local/lib/python3.10/site-packages/HABApp/openhab/items/datetime_item.py", line 25, in from_oh
[2023-09-26 21:52:34,834] [           HABApp.openhab]    ERROR |     dt = datetime.strptime(value, '%Y-%m-%dT%H:%M:%S.%f%z')
[2023-09-26 21:52:34,834] [           HABApp.openhab]    ERROR |   File "/usr/local/lib/python3.10/_strptime.py", line 568, in _strptime_datetime
[2023-09-26 21:52:34,834] [           HABApp.openhab]    ERROR |     tt, fraction, gmtoff_fraction = _strptime(data_string, format)
[2023-09-26 21:52:34,834] [           HABApp.openhab]    ERROR |   File "/usr/local/lib/python3.10/_strptime.py", line 349, in _strptime
[2023-09-26 21:52:34,834] [           HABApp.openhab]    ERROR |     raise ValueError("time data %r does not match format %r" %
[2023-09-26 21:52:34,834] [           HABApp.openhab]    ERROR | ValueError: time data '2023-09-26T21:50:17.629834131+0200' does not match format '%Y-%m-%dT%H:%M:%S.%f%z'
[2023-09-26 21:52:34,837] [     HABApp.openhab.items]     INFO | Updated 314 Items
[2023-09-26 21:52:34,911] [                   HABApp]    ERROR | Error Unknown Event: ItemStateUpdatedEvent for {'topic': 'openhab/items/cellarPowerMeterWatts1/stateupdated', 'payload': '{"type":"Decimal","value":"136.60"}', 'type': 'ItemStateUpdatedEvent'} in on_sse_event:
[2023-09-26 21:52:34,911] [                   HABApp]    ERROR | --------------------------

The last message is reported for every item change.

Any idea how to fix that and why 1.0.6 is shown as version in the line above?
Dockerfile states:

FROM spacemanspiff2007/habapp:23.09.2 as buildimage

dont know if it helps, i use this format code without problems (in this example to receive how long a light is already ON):

        now = datetime.now()
        on_time = mktime(now.timetuple()) - mktime(datetime.strptime(str(light_item_ts),
        "%Y-%m-%dT%H:%M:%S.%f").timetuple())
        return int(on_time)

also not sure but if i am right the ItemStateUpdatedEvent does not exist, now you have to use ItemStateUpdatedEventFilter() at least that is what i find in the docs:
https://habapp.readthedocs.io/en/latest/interface_openhab.html#HABApp.openhab.events.ItemStateUpdatedEventFilter

@bastler Thank you very much for looking into it!!

I’ve messed up the Dockerfile and I suppose that’s why the error messages occured. The messages above appeared without any rules applied.
I’ve started from scratch and now it works fine again!

Many thanks to @Spaceman_Spiff for your work on HABApp!

1 Like

Hello @Spaceman_Spiff,

I try to create a rule that puts items into groups - e.g. depending on tags - so that my system stays consistent automatically.

The problem I face is that with create_item.

I can could not find an update_item but only the create_item. When I update the existing group item though it always removes the category from it.

I can get all information from the existing item, manipulate them - e.g. adding new groups - and pass it again to create_item. But I did not find a way to get the category from an existing item.

So I have to leave it empty - which removed the current category.

Any idea how to solve the problem?

Thanks.

What do you mean with category? There is nothing in the docs about it

You can set the category in the create_item method in HABApp. If you leave it empty a potenially existing category will be removed. The category defines the icon shown in OpenHAB.
It can also be set via the UI (see attached screenshot)

openHAB — HABApp beta documentation has a parameter “category”.

Which I guess refers to Categories | openHAB.

In the UI (code page) I can see that this is part of the item-definition:

label: Thing Status
type: Group
category: status
groupNames: []
groupType: None
function: null
tags: []

after I use the “create_item” call the item definition changes to

label: Thing Status
type: Group
category: None
groupNames: ['parentGroup']
groupType: None
function: null
tags: []

It’s the icon. I guess the openHAB docs and the openHAB api is inconsistent.
What you are looking for is the icon (which seems to equal category).

That’s what I’m trying to do

  • parse the registry
  • add all items that match a pattern to a group
    • e.g. all thing-items to gThingItems
  • leave all other attributes the same

This is in principle my code:

        thing_group_item = GroupItem.get_item("gThingItems")
        ....
        _item = GroupItem.get_item(<itemName>)
        _item_groups = list(_item.groups)
        _item_groups.append(thing_group_item.name)

        log.info("Adding %s to %s", _item.name, thing_group_item.name)

        if not self.openhab.create_item(
            item_type="Group",
            name=_item.name,
            label=_item.label,
   -->      category=_item.category,  <--
            tags=list(_item.tags),
            groups=_item_groups,
        ):

The problem is that I cannot get the data for _item.category - so it will be removed from all items.
I checked your API and could not find how to get the category - or the item - of a known item.
Also the metadata does not contain anything.

Would it be an idea to allow setting any optional parameter to None - which means that the current content will not be changed for an existing item?
Or maybe - not to create an incompatible interface change add a new function update_item that only changes explicitely passed parameters?

Thanks for your thoughts.

The icon (or category) is not exposed because imho it’s not that interesting.
To make you logic work you have to request the item synchronously.
This is not very fast but that shouldn’t matter since you only do this once.

complete_item_definition = self.openhab.get_item('my_name')
complete_item_definition.category

Currently the API is a reflection of the openHAB api.
I’m not sure if it’s worth the effort since it’s possible to use two calls (see above).


What do you mean by that?

Well that did the trick.

I was not aware that

myItem = GroupItem.get_item(<itemName>)

returns a different type than

myItem = self.openhab.get_item(<itemName>)
  • For GroupItem.get_item(<itemName>) I get an error AttributeError: 'GroupItem' object has no attribute 'category'.
  • For self.openhab.get_item(<itemName>) I get the correct category,

Thanks.

FYI: “Also the metadata does not contain anything” - I agree was very misleading. It does contain a lot of data. I was looking through all the metadata and also could not find anything that helped me resolve my category problem.

On returns the HABApp internal item object and the other one makes a rest call to the openHAB api.
Both do different things …

1 Like

Good news everyone! HABApp 23.11.0 is out!

This is a small release that updates the dependencies and fixes some small issues.

5 Likes

With the new release I have problems: the rule files aren’t loaded at startup.
It also looks like that it does not loads the items.
I copied in the rule files manually. That seems to work.

2023-12-01 18:53:49.490 [INFO ] [HABApp                     ] - HABApp Version 23.11.0
2023-12-01 18:53:50.222 [INFO ] [HABApp.connection.mqtt     ] - MQTT disabled
2023-12-01 18:54:54.980 [INFO ] [HABApp.connection.openhab  ] - ... offline!
2023-12-01 19:55:17.636 [INFO ] [HABApp.connection.openhab  ] - Connected to OpenHAB version 4.1.0.M3 (Milestone Build)
2023-12-02 12:55:05.459 [INFO ] [HABApp.Rules               ] - Added rule "RuleMonitor" from rules/helpers/rule_monitor.py
2023-12-02 12:56:46.649 [ERROR] [HABApp.files               ] - File /etc/openhab/habapp/rules/astro.py depends on file that doesn't exist: rules/helpers/util.py
2023-12-02 12:57:14.784 [ERROR] [HABApp.files               ] - File /etc/openhab/habapp/rules/astro.py depends on file that doesn't exist: rules/helpers/util.py
2023-12-02 12:58:06.379 [INFO ] [HABApp.Rules               ] - Added rule "Utils" from rules/helpers/util.py
2023-12-02 12:58:08.697 [ERROR] [HABApp.Rules               ] - Error "Item swi_Astro_Night does not exist!" in load:
2023-12-02 12:58:08.699 [ERROR] [HABApp.Rules               ] - Could not load /etc/openhab/habapp/rules/astro.py!
(...)

With the previous version the startup looks like this:

2023-11-10 19:23:56.938 [INFO ] [HABApp                     ] - HABApp Version 23.09.2
2023-11-10 19:23:57.091 [INFO ] [HABApp.connection.mqtt     ] - MQTT disabled
2023-11-10 19:23:57.307 [INFO ] [HABApp.connection.openhab  ] - Connected to OpenHAB version 4.1.0.M3 (Milestone Build)
2023-11-10 19:23:58.348 [INFO ] [HABApp.openhab.items       ] - Updated 913 Items
2023-11-10 19:23:58.861 [INFO ] [HABApp.openhab.items       ] - Updated 83 Things
2023-11-10 19:23:59.726 [INFO ] [HABApp.openhab.transform   ] - Transformations:
2023-11-10 19:23:59.728 [INFO ] [HABApp.openhab.transform   ] -   Map: de.map, en.map, ups.map
2023-11-10 19:24:04.095 [WARN ] [HABApp.Rules               ] - Found no instances of HABApp.Rule in /etc/openhab/habapp/rules/appliances/__init__.py
2023-11-10 19:24:04.107 [WARN ] [HABApp.Rules               ] - Found no instances of HABApp.Rule in /etc/openhab/habapp/rules/communication/__init__.py
2023-11-10 19:24:04.119 [WARN ] [HABApp.Rules               ] - Found no instances of HABApp.Rule in /etc/openhab/habapp/rules/heating/__init__.py
2023-11-10 19:24:04.133 [WARN ] [HABApp.Rules               ] - Found no instances of HABApp.Rule in /etc/openhab/habapp/rules/helpers/__init__.py
2023-11-10 19:24:04.152 [INFO ] [HABApp.Rules               ] - Added rule "RuleMonitor" from rules/helpers/rule_monitor.py
2023-11-10 19:24:04.171 [INFO ] [HABApp.Rules               ] - Added rule "OH_REST" from rules/helpers/rest.py
2023-11-10 19:24:04.187 [INFO ] [HABApp.Rules               ] - Added rule "Utils" from rules/helpers/util.py
2023-11-10 19:24:04.228 [INFO ] [HABApp.Rules               ] - Added rule "Astro" from rules/astro.py
(...)

How can I help to debug or is there an easy fix?