Thanks for the prompt response.
I think something went wrong during the first pull the docker file even if I used the
latest
tag.
No it looks OK.
Thx
Hi Seb! Long time since I logged on here.
HABApp 1.0.8 and OpenHAB 3.4.4 has been chugging along in the background in docker containers on my PI4 this whole time, working great.
One thing that has plagued it continuously and filling up my logs is these randomly occuring performance related messages:
[2024-04-04 12:13:55,558] [ HABApp.Worker] WARNING | Execution of BatteryStatus.do_run took too long: 0.86s
[2024-04-04 12:37:43,952] [ HABApp.Worker] WARNING | Starting of EnergyMgmt.fnOnGridWatts took too long: 0.38s. Maybe there are not enough threads?
Fair enough. The PI4 is not a powerhouse.
Finally today I migrated OpenHAB, HABApp and Mosquitto to a proper server – a Ryzen 5950X. Four cores are dedicated to an LXC that hosts the docker containers. I’m still running the same versions, and it flies! Wonderful.
But, guess what – I’m still getting these messages.
[2024-04-04 17:31:50,003] [ HABApp.Worker] WARNING | Starting of PoolFlow.fnJsonMessage1 took too long: 0.07s. Maybe there are not enough threads?
0.07 seconds? That’s not too long, that seems perfectly reasonable.
What is the alarm threshold? Is it dynamic somehow? Can I change the threshold and/or add more threads?
One more question. Mosquitto was set to use the latest version, which was now 2.0.18.
I had really weird problems. Non-retained messages published from my devices did not reach HABApp! But, they reached MQTT Explorer. And when I published non-retained from MQTT Explorer, they did reach HABApp. But the next update from the device, even though it showed up fine in MQTT Explorer, again did NOT reach HABApp!
It was completely consistent. The device updates never reached HABApp but if sent from MQTT Explorer it always reached HABApp.
I finally downgraded Mosquitto to 2.0.14 and then everything worked again.
Any idea what’s going on there?
I will update openHAB and HABApp to the latest versions when I have a chance. My entire house runs on HABApp now, including the energy management (solar + batteries, and controlling air conditioning and pool pumps) so I have to pick the right time to upgrade system-level components such as those.
You can update to the latest Version of HABApp. There the warning logic is more intelligent and will not throw this warning when there are plenty of threads available.
Be aware that there was a breaking change which means you should use the ItemStateUpdatedEvent instead of the ItemStateEvent which should not used any more.
Hm - no idea. I am running mosquitto 2.0.18 without issues.
Is this a reproducible issue which persists across restarts?
That sounds awesome! I am glad you are happy with HABApp 
Hello @Spaceman_Spiff, several post above, you wrote that it is possible to load / unload rules via posting particular events on the bus. I am really interested in this, but I cannot get it working. I would expect, that posting RequestFileUnloadEvent will unload the rule and RequestFileLoadEvent will load the rule. But both of them are ending in the rule reloading. My code is very simple:
event = RequestFileUnloadEvent("rules/operator_vents.py")
self.post_event("HABApp.Files", event)
and the output in the HABApp log (DEBUG severity):
[2024-05-10 11:54:24,811] [ HABApp.file.events] DEBUG | FileOpenedEvent(src_path='/habapp/config/rules/operator_vents.py', dest_path='', event_type='opened', is_directory=False, is_synthetic=False)
[2024-05-10 11:54:24,812] [ HABApp.files] DEBUG | rules/operator_vents.py added
[2024-05-10 11:54:25,102] [ HABApp.files] DEBUG | rules/operator_vents.py changed to DEPENDENCIES_OK
[2024-05-10 11:54:25,103] [ HABApp.Rules] DEBUG | Removing file: rules/operator_vents.py
[2024-05-10 11:54:25,108] [ HABApp] DEBUG | Removed event listener for "control/fans/set" (filter=ValueChangeEventFilter())
[2024-05-10 11:54:25,109] [ HABApp] DEBUG | Removed event listener for "control/fanexhaust/set" (filter=ValueChangeEventFilter())
[2024-05-10 11:54:25,109] [ HABApp] DEBUG | Removed event listener for "control/fanintake/set" (filter=ValueChangeEventFilter())
[2024-05-10 11:54:25,109] [ HABApp.Rules] DEBUG | File rules/operator_vents.py successfully unloaded!
[2024-05-10 11:54:25,112] [ HABApp.Rules] DEBUG | Loading file: rules/operator_vents.py
[2024-05-10 11:54:25,114] [ HABApp.file.events] DEBUG | FileOpenedEvent(src_path='/habapp/config/rules/operator_vents.py', dest_path='', event_type='opened', is_directory=False, is_synthetic=False)
[2024-05-10 11:54:25,117] [ HABApp.file.events] DEBUG | FileOpenedEvent(src_path='/habapp/config/rules/operator_vents.py', dest_path='', event_type='opened', is_directory=False, is_synthetic=False)
[2024-05-10 11:54:25,118] [ HABApp.file.events] DEBUG | FileOpenedEvent(src_path='/habapp/config/rules/operator_vents.py', dest_path='', event_type='opened', is_directory=False, is_synthetic=False)
[2024-05-10 11:54:25,127] [ HABApp] DEBUG | Added event listener for "control/fanintake/set" (filter=ValueChangeEventFilter())
[2024-05-10 11:54:25,128] [ HABApp] DEBUG | Added event listener for "control/fanexhaust/set" (filter=ValueChangeEventFilter())
[2024-05-10 11:54:25,129] [ HABApp] DEBUG | Added event listener for "control/fans/set" (filter=ValueChangeEventFilter())
[2024-05-10 11:54:25,129] [ HABApp.Rules] INFO | Added rule "OperatorVentsRule" from rules/operator_vents.py
[2024-05-10 11:54:25,131] [ HABApp.Rules] DEBUG | File rules/operator_vents.py successfully loaded!
[2024-05-10 11:54:25,132] [ HABApp.files] DEBUG | rules/operator_vents.py changed to LOADED
[2024-05-10 11:54:40,574] [ HABApp.files] DEBUG | Worker done!
Any advice how to dynamicly disable / enable rules?
Hope it is okay to warm up this thread.
If I call this, when the key PIN is missing in the parameter file:
Parameter("credentials", "StereoBuero", "PIN", default_value="1234")
I get as result:
<Parameter file: credentials, keys: ('StereoBuero', 'PIN'), value: ToDo
where I was expecting to get ‘1234’ as value.
You could write that first line unconditionally. The default_value will only be generated when the entry is not there.
Immediately after you call this the file should be created with “1234” as an entry.
Then a reload of the file should happen which you should see in the events.
Once the reload is done you should see the value “1234”.
Is that not what you are seeing?
Thanks for the explanation. I was mostly wondering about the value ‘ToDo’. I had set the missing parameter and it was all good.
Now I tried again. It behaved now a bit differently compared to my previous trials. But as I haven’t expected that HABApp is writing into the credential files, I had once ignored the error message I got now.
2025-03-26 20:31:56.324 [INFO ] [HABApp.RuleParameters ] - Updated /etc/openhab/habapp/params/credentials.yml
2025-03-26 20:31:56.396 [ERROR] [HABApp.Rules ] - Error "[Errno 13] Permission denied: '/etc/openhab/habapp/params/credentials.yml'" in load:
2025-03-26 20:31:56.396 [ERROR] [HABApp.Rules ] - Could not load /etc/openhab/habapp/rules/radio/fs_radio.py!
I figured out that I needed to set the permissions of the parameter file to o+w. Now it behaves as you described.
1 Like
Is there a way to control in what order rules are loaded?
I created a file “rules/oh_helper_lib.py” with a rule
class ItemCompare(HABApp.Rule):
.
.
.
ItemCompare()
that I added as dependency to a couple of rules via e.g.:
# HABApp:
# reloads on:
# - params/ikea.yml
# - rules/oh_helper_lib.py
Now I get a lot of warnings during start-up of HABApp that the rule does not exist:
2025-04-26 14:23:45.293 [INFO ] [HABApp ] - HABApp Version 24.11.1
2025-04-26 14:23:45.738 [INFO ] [HABApp.connection.mqtt ] - Connecting to 192.168.178.37:1883
2025-04-26 14:23:45.790 [INFO ] [HABApp.connection.mqtt ] - Connection successful
2025-04-26 14:23:45.848 [INFO ] [HABApp.connection.openhab ] - Connected to OpenHAB version 4.3.4 (Release Build)
2025-04-26 14:23:47.584 [INFO ] [HABApp.openhab.items ] - Updated 1644 Items
2025-04-26 14:23:48.782 [INFO ] [HABApp.openhab.items ] - Updated 135 Things
2025-04-26 14:23:52.426 [INFO ] [HABApp.openhab.transform ] - Transformations:
2025-04-26 14:23:52.427 [INFO ] [HABApp.openhab.transform ] - Map: de.map, en.map, gardena.map, indego.map, thermostat_modes.map, toggle.map
.
.
.
2025-04-26 14:23:56.576 [ERROR] [HABApp ] - Error 'No Rule with name "ItemCompare" found!' in get_rule:
2025-04-26 14:23:56.576 [ERROR] [HABApp ] - File "/opt/habapp/lib/python3.12/site-packages/HABApp/rule_manager/rule_manager.py", line 107 in get_rule
2025-04-26 14:23:56.576 [ERROR] [HABApp ] - --------------------------------------------------------------------------------
2025-04-26 14:23:56.577 [ERROR] [HABApp ] - 90 | @log_exception
2025-04-26 14:23:56.577 [ERROR] [HABApp ] - 91 | def get_rule(self, rule_name):
2025-04-26 14:23:56.577 [ERROR] [HABApp ] - (...)
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - 103 | return found
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - 105 | # if we want a special one throw error
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - 106 | if not found:
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - --> 107 | raise KeyError(f'No Rule with name "{rule_name}" found!')
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - 108 | return found if len(found) > 1 else found[0]
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - ------------------------------------------------------------
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - file = <HABApp.rule_manager.rule_file.RuleFile object at 0xeb047c60>
2025-04-26 14:23:56.578 [ERROR] [HABApp ] - file.rules = {}
2025-04-26 14:23:56.579 [ERROR] [HABApp ] - self = <HABApp.rule_manager.rule_manager.RuleManager object at 0xf23cd318>
2025-04-26 14:23:56.579 [ERROR] [HABApp ] - self.files = {'/etc/openhab/habapp/rules/ChristmasLights.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed77bfc0>, '/etc/openhab/habapp/rules/ContactSwitchMapping.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xf23e10c0>, '/etc/openhab/habapp/rules/TomatoWateringTimer.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed77bf78>, '/etc/openhab/habapp/rules/ZigbeeToMqtt.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xedab3648>, '/etc/openhab/habapp/rules/astral.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed986d08>, '/etc/openhab/habapp/rules/astro.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xedb7cbe8>, '/etc/openhab/habapp/rules/blinds.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed7fd5e8>, '/etc/openhab/habapp/rules/fader.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xf0561d20>, '/etc/openhab/habapp/rules/gardena.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xedab3330>, '/etc/openhab/habapp/rules/groupCheck.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed49acd8>, '/etc/openhab/habapp/rules/habapp_exception.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xedab3870>, '/etc/openhab/habapp/rules/habpanel.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed49ad20>, '/etc/openhab/habapp/rules/holidays.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed4cbc00>, '/etc/openhab/habapp/rules/homematic.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed4cbba0>, '/etc/openhab/habapp/rules/homematic_connection_check.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xeb047708>, '/etc/openhab/habapp/rules/huawei.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed4cba98>, '/etc/openhab/habapp/rules/hue.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xed750d38>, '/etc/openhab/habapp/rules/ikea.py': <HABApp.rule_manager.rule_file.RuleFile object at 0xeb047c60>}
2025-04-26 14:23:56.579 [ERROR] [HABApp ] - found = []
2025-04-26 14:23:56.579 [ERROR] [HABApp ] - len(found) = 0
2025-04-26 14:23:56.579 [ERROR] [HABApp ] - not found = True
2025-04-26 14:23:56.580 [ERROR] [HABApp ] - rule_name = 'ItemCompare'
2025-04-26 14:23:56.580 [ERROR] [HABApp ] - rule_name in file.rules = False
2025-04-26 14:23:56.580 [ERROR] [HABApp ] - len(found) > 1 = False
2025-04-26 14:23:56.580 [ERROR] [HABApp ] - ------------------------------------------------------------
2025-04-26 14:23:56.580 [ERROR] [HABApp ] -
2025-04-26 14:23:56.580 [ERROR] [HABApp ] - --------------------------------------------------------------------------------
2025-04-26 14:23:56.580 [ERROR] [HABApp ] - Traceback (most recent call last):
2025-04-26 14:23:56.580 [ERROR] [HABApp ] - File "/opt/habapp/lib/python3.12/site-packages/HABApp/core/wrapper.py", line 59, in f
2025-04-26 14:23:56.581 [ERROR] [HABApp ] - return func(*args, **kwargs)
2025-04-26 14:23:56.581 [ERROR] [HABApp ] - ^^^^^^^^^^^^^^^^^^^^^
2025-04-26 14:23:56.581 [ERROR] [HABApp ] - File "/opt/habapp/lib/python3.12/site-packages/HABApp/rule_manager/rule_manager.py", line 107, in get_rule
2025-04-26 14:23:56.581 [ERROR] [HABApp ] - raise KeyError(f'No Rule with name "{rule_name}" found!')
2025-04-26 14:23:56.581 [ERROR] [HABApp ] - KeyError: 'No Rule with name "ItemCompare" found!'
2025-04-26 14:23:57.053 [ERROR] [HABApp.Rules ] - Error "'No Rule with name "ItemCompare" found!'" in load:
2025-04-26 14:23:57.053 [ERROR] [HABApp.Rules ] - Could not load /etc/openhab/habapp/rules/ikea.py!
Later on the rules is properly loaded and works as expected. It is just a bit annoying to get all these errors during start.
rules are loaded in alphabetical order.
e.g. i have a rule to oserve errorsv (from other rules) and notitfy me. this i namded _alert_notify.py to ensure it is loaded at first of all rules.
I use a numbering scheme. My rule files starts with 10_, 20_ and so on.
All files that could be loaded in either order start with the same number
You should use the depends on clause:
# HABApp:
# depends on:
# - rules/helpers/rule_monitor.py
# - rules/radio/fs_radio_lowlevel.py
# reloads on:
# - params/credentials.yml
1 Like
Thanks - I didn’t know that. The log shows the order of rules during start-up in kind of a random order.
2025-04-26 16:10:35.067 [INFO ] [HABApp.Rules ] - Added rule "ContactSwitchMapper" from rules/ContactSwitchMapping.py
2025-04-26 16:10:35.090 [INFO ] [HABApp.Rules ] - Added rule "MyTomatoTimer" from rules/TomatoWateringTimer.py
2025-04-26 16:10:35.090 [INFO ] [HABApp.Rules ] - Added rule "MyTomatoTimer.2" from rules/TomatoWateringTimer.py
2025-04-26 16:10:35.412 [INFO ] [HABApp.Rules ] - Added rule "Zigbee2MqttBridge" from rules/ZigbeeToMqtt.py
2025-04-26 16:10:35.420 [INFO ] [HABApp.Rules ] - Added rule "ItemCompare" from rules/_oh_helper_lib.py
2025-04-26 16:10:35.505 [INFO ] [HABApp.Rules ] - Added rule "AstralInfo" from rules/astral.py
2025-04-26 16:10:35.525 [INFO ] [HABApp.Rules ] - Added rule "AstroInfo" from rules/astro.py
But it worked 
. Start-up looks nice again.
Thanks as well.
I will try this additional dependency and have a look.
Now that I “sorted” my files by name, I may not see a direct difference though.
As others have said: file load order is in alphabetical order.
If you have rules that depended on other rules you should always use depends on.
That way when the rule you depend on has errors loading is deferred until the error is fixed.
Thanks for the clarification.
Good news everyone!
HABApp 25.04.0 is out!
1 Like