HABApp 1.1

Apps & Services 3rd Party
1

Good news everyone! I’ve finished working on a new version:

HABApp 1.1.0

This is a breaking release that brings official support for openHAB 4.0

Migration

  • Rename GroupItemStateChangedEvent to GroupStateChangedEvent
  • Rename ItemStateEvent to ItemStateUpdatedEvent
  • Rename ItemStateEventFilter to ItemStateUpdatedEventFilter

Changelog

  • Renamed GroupItemStateChangedEvent to GroupStateChangedEvent
  • Groups issue a GroupStateUpdateEvent when the state updates on OH3 (consistent with OH4 behavior)
  • Groups work now with ValueUpdateEvent and ValueChangedEvent as expected
  • Renamed ItemStateEvent to ItemStateUpdatedEvent
  • Ignored ItemStateEvent on OH4
  • Fewer warnings for long-running functions (execution of <FUNC_NAME> took too long)
  • Thing status and status_detail are now an Enum
  • Added status_detail to Thing
  • LocationItem now provides the location as a tuple
  • Added support for Point events
  • Improved item sync from openHAB (no more false item state None after startup)
  • Improved startup behavior when openHAB and HABApp get started together (e.g. after reboot)
  • Fixed an issue with short tracebacks for HABApp internal files
  • Doc improvements

Many thanks to @bastler who helped out multiple times with testing and providing logs!

Edit:
I have not renamed the ItemStateEvent to ItemStateUpdatedEvent.
That is a mistake in the Changelog.

10 Likes
2

Thanks for your work and the release :slight_smile:

One question: is HABApp 1.1.0 still working for OH3?

3

Yes - it’s still working.

You can do the rules migration and then on OH4 release it should just be a matter of switching the openHAB instance (or at least let’s hope so)

@dan12345:
Please let me know if the new mechanism to omit warnings works without your threads :wink:

4

thank you! Yes, a quick test shows that a ten second delay doesn’t trigger a warning.

Great news - I can junk all my threaded rules!

5

Thank you.

Does the improved start up behavior apply to OH 3.4 also, or do I need to wait for OH 4?

And did you add something regarding quantity types, e.g. can I get the (capped) unit from an OpenhabItem?

6

Yes - the improved startup is available for all version

With OH4.0 you can get the unit of a NumberItem, but only if you have the metadata properly set.
HABApp will also issue a warning if it’s missing.

7

Sorry to ask again. But why is this not version 2.0.0?
There are braking changes :frowning:

8

Thanks @Spaceman_Spiff again for your great work. HABApp 1.1.0 is running on my production system without any issues (so far still on OH 3.4).
I really like I could also get rid of some of my threaded rules!

9

And as expected - as soon as I make the release another bug appears :smiley:

HABApp 1.1.1 is out.
It fixes an issue where the rule context is not found

The first couple of changes were non-breaking and then I just forgot to increase the version number :man_shrugging:

10

It seems like nobody payed attention to the change log because I obviously did not rename ItemStateEvent to ItemStateUpdatedEvent. :wink: It still gets emitted as expected on OH3 instances.

So HABApp 1.1.2 is out, which fixes the information in the change log and as a small bonus improves the DateTime value parsing.

3 Likes
11

Hello Seb,

I saw that in 1.1.2 the event continues to be ItemStateEvent. However in OH4, I see this note:

  • Rules are now triggered by ItemStateUpdatedEvent instead of ItemStateEvent. If you use JSR223 scripting without helper libraries and expect a certain Java type, code changes might be needed.

Would 1.1.2 continue to work with OH4?

Thanks,

12

After 15’, it looks like my system continues to function. So I am a bit at loss on the impact of the above statement from the release note. I think perhaps it is JSR223 specific.

13

With OH4 the ItemStateEvent is automatically discharged and the ItemStateUpdatedEvent is used. If you use the ValueUpdateEvent there are no changes needed and and subscribing will work as before, if you migrate from OH3 and use the ItemStateEvent you need to replace it with the ItemStateUpdatedEvent. If you use the event value you have to check your code, too (e.g. if event.value == 'ON') because the event now reports the item state instead e.g. the command.

1 Like
14

Thanks for the explanation. I’ve made the change to my code.

15

Hi all,
I already use Habapp together with OH3.4. This installation is still running.

In parallel I setup a new Hardware ( New Pi) installed OH4 from scratch and
first time installed Habapp from openhabian.

Now I have problems that habapp is not able to connect to openhab.

In the config.yml I entred the username and pw for OH. But everytime get get Errors with 401 for access to rest api.
If I did thjis from my pc just with http://x.x.x.x:8080/restapi I saw the answer.

Also I tried all combinations from username and pw inside the config file.
Username/PW from openhab and Username/PW from RaspPi.

I also change the url setting from localhost to the real ip adr.

So what could be wrong?

Again, on OH3.4 it is still running. Only diffrence: in the old setup I have habapp and OH running on diffrent pi’s. Now it is on the same machine

16

Did you do the additional configuration?

17

hmm, I think not. But to be honest, I’m not shure. Is this a change compared to oh3?

I just installed it, added the credentials, like in the old installation.
But, thanks for the tip. Will test it in the evening

18

No - this has always been required.
I suspect you did it when you set up your old installation and simply forgot. :smiley:
We’ll see.

19

OK, that was it. Thanks.
Could not remember to use this setting before :slight_smile: But as you mentioned it, I simply forget it, because the old OH version was running for a long time.
So everything is working perfect .

1 Like
20

So if I want the equivalent of a trigger when ‘received command’ rule, for a switch item, what is the appropriate way to actually get the command sent, not the value of the item state. I’m having problems where using item.value or event.value give me the old state because they haven’t had time to update yet. How do I get the commanded state if I don’t care about the value (yet). Is there a event.commanded_state or something like it?

I just read the source code on ItemCommandEvent() and it appears that it’s only methods (not the right word?) are name and value, and value doesn’t actually hold the commanded value from what you’re saying above.

In rules dsl and jython we could get the actual received command regardless of what the state was using ‘receivedCommand’ or something like it. I’m sure I’m missing something here…