Almost 
Basically you can never be sure which version you are using from the file that imported it.
Good news everyone!
I just released HABApp 0.30.1!
This is just a small bugfix release
Changelog:
- latitude is now set correctly for sun calculation
- Added missing " for tags in textual thing configuration
- Updated scheduler which fixes an overflow error
- States of openHAB groups are now unpacked correctly
Good news everyone!
I just released HABApp 0.30.2!
This is just a small release which brings some bugfixes and small features
Changelog:
- Item and Thing loading from openHAB is more robust and disconnects now properly if openHAB is only partly ready
- Renamed command line argument â-sâ to â-wosâ or ââwait_os_uptimeâ
Now waits until the system uptime is at least the specified value before starting HABApp - Renamed HABApp.openhab.exceptions to HABApp.openhab.errors
- Updated dependencies
2 Likes
Good news everyone!
I just released HABApp 0.30.3!
This release brings support for a custom mqtt certificate and changes some internal HABApp things
Changelog:
- add support for custom ca cert for MQTT
- Scheduler runs only when the rule file has been loaded properly
- Sync openhab calls raise an error when called from an async context
- Replaced thread check for asyncio with a contextvar
2 Likes
I just moved from OH 2.5 to OH 3.1, and it was made so much easier with having all my rules in HABApp! all my rules just worked after the upgrade. Thank you.
I do have a question about OH 3.1. I used to use the âSystem startedâ trigger (in my one and only DSL rule) to restart HABApp when OH stated up, and whenever I edited an .items file.
Now with OH3.1, this rule does not trigger when an .items file is edited, so the question is - what happens to HABApp if itâs running, and I edit an '.items file? do I need to manually restart HABApp for it to pick up the changes in the .items files? would touching all my rules achieve the same thing? (assuming I havenât changed anything vital, say changing the label or group or adding an item).
Is there a way to set HABApp up so that changing any .items file trigger a rules reload in HABApp (or a restart if that is what is needed).
What would you suggest?
Thanks.
I use the dependency definitions to restart rule if my parameter file are changes.
Example:
# Dependency definitions
# HABApp:
# reloads on:
# - params/thermostats.yml
But i think this is not linked to the openhab files.
I have updated my CreateTimer class to use your new coundown timer. Here it is, if anyone else is interested (this is in my utils.py library).
Basically it makes the basic countdown timer into a persistent, cancellable timer with some added methods and properties.
This solves the problem that you canât cancel() a countdown timer and then restart it, you have to recreate the countdown timer, if you cancel() it early.
import datetime, logging
from eascheduler.const import FAR_FUTURE
from threading import Lock
class createTimer(HABApp.Rule):
'''
General timer class
Restartable Timer, with cancel and reschedule functions
accepts float, int or datetime.timedelta as seconds parameter (not claiming that the timer is that accurate though)
based on countdown timer (new in Habapp V0.30)
'''
def __init__(self, seconds=0.0, exec_func=None, run=False, *args, **kwargs):
super().__init__()
self.log = logging.getLogger('MyRule.'+self.__class__.__name__)
self.t = seconds
self.exec_func = exec_func
self.args = args
self.kwargs = kwargs
self._task = self.run.countdown(self.t, self.exec_func, *args, **kwargs)
self.lock = Lock() #needed to prevent race condition
if run:
self.reset()
@property
def is_running(self):
return self.time_till_run != 0
@property
def time_till_run(self):
if self._task._next_run < FAR_FUTURE:
return (self._task.get_next_run() - datetime.datetime.now()).total_seconds()
return 0
def get_next_run(self):
return self._task.get_next_run()
def reset(self):
with self.lock:
self._task.reset()
def reschedule(self, seconds=0.0):
self.start(seconds)
def start(self, seconds=0.0, *args, **kwargs):
if args:
self.args = args
if kwargs:
self.kwargs = kwargs
if args or kwargs:
self.cancel()
self.countdown(seconds)
self.reset()
def countdown(self, seconds=0.0):
if seconds > 0:
self.t = seconds
with self.lock:
self._task.countdown(self.t)
def cancel(self, job=False):
with self.lock:
if self._task._parent is not None:
self._task.cancel()
if not job:
self._task = self.run.countdown(self.t, self.exec_func, *self.args, **self.kwargs)
You could simplify it more - reset(), reschedule() and start() are all basically the same thing, but I didnât want to make too many changes to my original.
You use this as a drop in replacement for self.run.countdown()
Update: Fixed race conditionâŠ
1 Like
Yep - the only difference to the built in counter is the is_running property and the time_till_run.
But you already had it in place before the new scheduler in HABApp so itâs valid to keep this around.
HABApp will pick up the changed item definitions automatically.
There is no need to restart HABApp if you change the *.items file.
Youâll see the corresponding events on the event bus.
Of course you have to reload the rules that used the existing items.
Any ideas on how to do that? I have 39 rules files, and itâs not easy to know which files uses which items - is there a way of triggering a reload on all rules when any .items file is changed?
Weird things happen if I donât reload after editing .items files.
If its adding items or modifying e.g. a label (not the type/name) it is fine.
Things go south if you rename items or delete existing ones.
The only way I can think of is to take one or two items of every *.items file and listen to the ItemAddedEvent or the ItemRemovedEvent and then issue a FileLoadEvent with all rule names.
But it might be easier to just create a button in openhab and link a shell execute with a systemctl reload HABApp and just flick it once youâre done editing.
1 Like