HABApp 25

Apps & Services 3rd Party
104

I have another instance of HABApp stops triggering with OpenHab 5.1. There is a more closely correlated error message with WebSocket.

Here’s the HABApps logs; note the entries at 6:37.

[2026-01-05 04:57:51,537] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 04:57:51,789] [     HABApp.openhab.items]     INFO | Updated 363 Items
[2026-01-05 04:57:51,900] [     HABApp.openhab.items]     INFO | Updated 63 Things
[2026-01-05 04:57:52,335] [ HABApp.openhab.transform]     INFO | Transformations:
[2026-01-05 04:57:52,335] [ HABApp.openhab.transform]     INFO |   Map: de.map, en.map, scalar-15618683d7d2.map
[2026-01-05 05:37:54,391] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 05:37:54,665] [     HABApp.openhab.items]     INFO | Updated 363 Items
[2026-01-05 05:37:54,741] [     HABApp.openhab.items]     INFO | Updated 63 Things
[2026-01-05 05:37:55,213] [ HABApp.openhab.transform]     INFO | Transformations:
[2026-01-05 05:37:55,213] [ HABApp.openhab.transform]     INFO |   Map: de.map, en.map, scalar-15618683d7d2.map
[2026-01-05 06:00:57,967] [                 ZoneApis]     INFO | SetTimeOfDay: Set day period to MORNING
[2026-01-05 06:07:56,460] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 06:07:56,718] [     HABApp.openhab.items]     INFO | Updated 363 Items
[2026-01-05 06:07:56,819] [     HABApp.openhab.items]     INFO | Updated 63 Things
[2026-01-05 06:07:57,290] [ HABApp.openhab.transform]     INFO | Transformations:
[2026-01-05 06:07:57,290] [ HABApp.openhab.transform]     INFO |   Map: de.map, en.map, scalar-15618683d7d2.map
[2026-01-05 06:37:58,601] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 06:37:58,853] [     HABApp.openhab.items]     INFO | Updated 363 Items
[2026-01-05 06:37:58,919] [     HABApp.openhab.items]     INFO | Updated 63 Things
[2026-01-05 06:37:59,380] [ HABApp.openhab.transform]     INFO | Transformations:
[2026-01-05 06:37:59,381] [ HABApp.openhab.transform]     INFO |   Map: de.map, en.map, scalar-15618683d7d2.map

I was doing development work yesterday, so HABApps was restarted around 9:30 PM. Notice how many times it reconnects to OpenHab. I didn’t notice this behavior with the previous version of OpenHab.

[2026-01-04 21:42:16,707] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-04 22:17:23,929] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-04 22:32:24,929] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-04 22:47:25,881] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-04 23:27:28,514] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-04 23:42:29,481] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 01:22:35,893] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 01:42:37,097] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 02:07:39,374] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 02:12:39,719] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 02:17:40,089] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 02:32:41,174] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 03:12:44,029] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 03:57:47,246] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 04:40:24,812] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 04:47:50,771] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 04:57:51,537] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 05:37:54,391] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 06:07:56,460] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)
[2026-01-05 06:37:58,601] [HABApp.connection.openhab]     INFO | Connected to OpenHAB version 5.1.0 (Release Build)

Below is the WebSocket errors on the OpenHab side. Notice the strong correlation between the timestamp there and the Connected to OpenHab messages on the HABApp side.

2026-01-04 21:39:15.337 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-04 21:40:39.824 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-04 22:17:22.817 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-04 22:32:23.848 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-04 22:47:24.797 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-04 23:27:27.417 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-04 23:42:28.397 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 01:22:34.793 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 01:42:36.013 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 02:07:38.288 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 02:12:38.641 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 02:17:39.014 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 02:32:40.094 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 03:12:42.929 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 03:57:46.146 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 04:40:23.704 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 04:47:49.690 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 04:57:50.452 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 05:37:53.294 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 06:07:55.376 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 06:37:57.530 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: Blocking message pending 10000 for BLOCKING
2026-01-05 07:49:37.761 [INFO ] [re.io.websocket.event.EventWebSocket] - WebSocket error: java.util.concurrent.TimeoutException: Idle timeout expired: 10001/10000 ms

HABApp stops updating the beacon at 6:37 AM. The WebSocket error stops around an hour later.

The gist is that OpenHab 5.1 seems to make HABApp less stable in certain circumstances (I haven’t nailed it down yet). But logs on both side indicate a strong correlation in WebSocket behavior changes. The only way to fix it is to re-start both components.

105

Are you sure that you’re still using my modified bundle when you get these results? I’m not sure if the bundle survives an OH restart, or if the standard bundle will be reinstalled then. I know that bundles can “revert” to the standard version even without a restart, if you do other changes to the system, like installing an add-on for example.

The logs shown above absolutely looks to be related to the same problem, which is why it’s essential to know that you’re using the “fixed” bundle.

106

I think you’re right. I was using bundle:update before and of course restarted OH multiple times since. I just did a bundle:list | grep Web and it was showing 5.1.0, which is incorrect. I just put it in again. This is a bit painful to remember to do this every time I restart OpenHab, but it will have to do till we get an updated 5.1. I will let you know if the issue happens again. Thanks again.

107

There are other ways, I’m just not an expert on Karaf, so I’m a bit unsure. I think that it will actually work “automatically” if you place the custom bundle in the addons folder, but you would have to verify that it actually does what it should. If that works like I think, you won’t have to do anything from the Karaf console.

108

Yes, this time I placed it in the addon folder and did the bundle stop/start. Let’s see if this lasts over restart. I am short on time now so I can’t try yet.

109

openHAB 5.1.1 was just release which should work out of the box

110

Sebastian, I have a quick question about the scheduler, specifically the countdown timer. I use it to turn lights off once the timer expires. It works the first time but subsequent calls to reset the timer end up with this error traceback and the timer fails (eascheduler.errors.errors.JobNotLinkedToSchedulerError). Any ideas?

2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] | Traceback (most recent call last):
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/opt/habapp/lib/python3.12/site-packages/HABApp/core/internals/wrapped_function/wrapped_thread.py", line 104, in run
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     ret = self.func_obj(*self.func_args, **self.func_kwargs)
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/etc/openhab/habapp/rules/lighting-garage.py", line 174, in Lights_Changed
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     self.reset_GL_Timer()                           # ---- Start Timer ----
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     ^^^^^^^^^^^^^^^^^^^^^
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/etc/openhab/habapp/rules/lighting-garage.py", line 116, in reset_GL_Timer
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     self.GL_Timer.reset()       # Start Timer
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     ^^^^^^^^^^^^^^^^^^^^^
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/opt/habapp/lib/python3.12/site-packages/HABApp/rule/scheduler/job_ctrl.py", line 107, in reset
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     run_func_from_async(self._job.reset)
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/opt/habapp/lib/python3.12/site-packages/HABApp/core/asyncio.py", line 133, in run_func_from_async
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     return future.result()
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |            ^^^^^^^^^^^^^^^
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/usr/lib/python3.12/concurrent/futures/_base.py", line 456, in result
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     return self.__get_result()
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |            ^^^^^^^^^^^^^^^^^^^
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/usr/lib/python3.12/concurrent/futures/_base.py", line 401, in __get_result
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     raise self._exception
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/opt/habapp/lib/python3.12/site-packages/HABApp/core/asyncio.py", line 141, in _async_execute_func
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     return func(*args, **kwargs)
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |            ^^^^^^^^^^^^^^^^^^^^^
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |   File "/opt/habapp/lib/python3.12/site-packages/eascheduler/jobs/job_countdown.py", line 35, in reset
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] |     raise JobNotLinkedToSchedulerError()
2026-02-09 08:15:47,631 [ERROR   ] [HABApp.Worker             ] | eascheduler.errors.errors.JobNotLinkedToSchedulerError
111

Do you by chance accidentally cancel the countdown job instead of stopping it?
E.g. call .cancel() instead of .stop() ?

112

Yes! .cancel() is what I’m calling! I didn’t look at the docs close enough. I never want to totally kill the job. What I want to do is stop the timer and then be able to reset it the next time a door opens. I’m going to try it now…

… That did it! Thank you!

113

At the moment I try to write a rule for sun protection. For each shutter i want to define the beginning and the end azimuth angle for activating and deactivating sun protection.

I tried with this code:

self.listener_azimuth_start = self.run.at(trigger.sun_azimuth(start_azimuth_value), self.azimuth_triggered)
self.listener_azimuth_end = self.run.at(trigger.sun_azimuth(end_azimuth_value), self.azimuth_triggered)

This only works if the actual azimuth angle is before (smaller) than the two values. If it is already higher then HABApp crashes completely.

I thought, if for today e.g. the start_azimuth_value was already passed, then the trigger would be tomorrow.

Did I do something wrong?

114

I don’t know HABApp or the circumstances here, but I can say that if these data come from the Astro binding, then most “events” are start or end times of “ranges”. The ranges must have a start that is before the end, they can’t be “inverted”, so that the behavior won’t be quite what you expect. You will get the start and end of the range/period that was calculated, and that is usually those that exist within the “current date”. These ranges are then recalculated right after midnight every night.

115

Thank you for the explanation!

If I understand correct this could be the reason why the rule works without problems if the actual azimuth is smaller, then even on following days it triggers again. I just must not run the code if one of my trigger azimuths already was passed.

In this case I will have to change my rule: if a azimuth already was passed then the listener has to be initialized after midnight.

116

The regeneration doesn’t run at midnight, but around 00:00:30. So, you might want to wait to a couple of minutes after midnight.

117

That’s rather unexpected and sounds like a bug. Can you PM me the error message and or your example values?

Here the data does not come from the astro binding but the HABApp scheduler.
It should work out of the box so this sounds like a bug.
So running it after midnight should fix the issue, but I would like to fix it non-the-less.

@bastler your understanding and assumption is correct. This is most likely an issue on the HABApp side.