No, because of the new connect mechanism this is 3.3 only.
Shouldn’t it actually work if one turns of the “wait for OH” flag?
Hi,
I’ll certainty be looking forward to implementing this - Ive had to revert to OH3.2 
I saw mentioned earlier in this post that there is a “wait for openhab to start” and that would help me, as i find i have to restart habapp once the openhab ui starts responding after restarting opnhab.
Looking at some of the changes i guess I’ll have to modify my scripts, but not a major problem.
Thanks,
Richie
Hm - I see why you could think that.
If the flag is set (default) HABApp waits for an successful openhab connection before the initial load of the rule files. This can be turned on or off.
If openhab is already started the connection is established very quickly and there is no additional wait time.
This is helpful if e.g. during a reboot HABApp starts quicker than openHAB.
With the next HABApp version it’s possible to reliably (at least I hope so) detect when openhab is started.
So HABApp now will always wait until the specified startlevel before loading the items and subscribing to events (successful openhab connection).
Since this is much better way than what I used before I deleted the old code path since I could optimize some connect parts.
tl;dr:
“wait for openhab” only ensure that e.g. the items from openhab have been loaded before initally loading the rules.
It actually was changed with OH 3.3. See Fix SSE topic filters by J-N-K · Pull Request #2986 · openhab/openhab-core · GitHub.
I created a PR for HABApp to fix it.
1 Like
@Dominik_Bernhardt
Thanks for the help and the correct topics. It’s mind boggling that I somehow did not run my tests with the 3.3 Release.
I fixed the topics and pushed the fix to the dev branch.
If you reinstall HABApp it should work now out of the box.
@imaginator: This should also fix your issues, so you can mark the thread as solved.
Edit:
Can you confirm that this fixes the issue?
Just updated to latest develop. Works like a charm
It would be nice to also get general feedback of the new features and/or the current state of HABApp.
Do you like the new EventFilter Syntax? Does it make it easier to provide additional values to the filter?
What about the new traceback?
@Spaceman_Spiff it looks like a regression (running the latest from Develop branch) or perhaps we are doing something wrong (again 
). Before the fix we were at least able to get_item now, this method throws an item not found error.
from HABApp import Rule
from HABApp.core.events import ValueUpdateEvent, ValueChangeEvent
from HABApp.openhab.events import ItemStateChangedEvent,ItemStateChangedEventFilter
from HABApp.openhab.items import NumberItem, OpenhabItem
class MyRule(Rule):
def __init__(self):
super().__init__()
# Get the item or create it if it does not exist
self.my_item = OpenhabItem.get_item('AstroSunPositionElevation')
print(self.my_item)
e = self.my_item.listen_event(self.item_changed, ItemStateChangedEventFilter())
print(e.__dict__["func"].__dict__)
def item_changed(self, event: ItemStateChangedEvent):
print("GOT EVENT")
print(f'{event.name} changed from "{event.old_value}" to "{event.value}"')
print(f'Last change of {self.my_item.name}: {self.my_item.last_change}')
MyRule()
What’s in the HABApp log? Your instance might not be connected yet.
From the log it looks like it’s connected. I can confirm that the item AstroSunPositionElevation definitely exits. I also see network traffic from HABapp to the server. Let me know if there is anything else I can send to help debug.
No - it is not completely connected. You manually dropped the file so it gets loaded before the the connection is complete. It’s the same issue as above in the thread.
@Dominik_Bernhardt
Have you already created an issue for openhab? I’ve not found the link in the 3.3 release thread.
Were you able to reproduce the issue?
What’s it doing during the connection? How long should one wait for startup? When I use the master branch I am connected and able to retrieve a value just not updates.
Waiting until openhab ist fully started.
Depends on your openhab installation size.
Dominik described the issue nicely.
So adding the mentioned min_start_level to 60 seems to have worked. I’ve not changed any OH runlevel bits so I would have assumed that since it’s been running for a few days, it was “started”.
Anyway this is great and we’re now getting events coming though. Thanks for the help.
I’ll investigate why my OH instance was only getting as far as runlevel 70.
So it looks like you are experiencing the same openHAB bug/issue as Dominik.
Could you try to reproduce the issue (probably a thing that doesn’t initialize well) and open an issue in the openhab repo, please?
Trying to get going for testing on a less-critical system but running into installation problems on an OpenHABian install. I realize this is not specifically a HABApp issue, but can’t get through it. Any ideas?
Cloning https://github.com/spacemanspiff2007/HABApp.git (to revision Develop) to /tmp/pip-req-build-uq6tdhj8
Running command git clone --filter=blob:none --quiet https://github.com/spacemanspiff2007/HABApp.git /tmp/pip-req-build-uq6tdhj8
Running command git checkout -b Develop --track origin/Develop
Switched to a new branch 'Develop'
Branch 'Develop' set up to track remote branch 'Develop' from 'origin'.
Resolved https://github.com/spacemanspiff2007/HABApp.git to commit a278927d149c33141ac67a5e500dc8cc26c89d06
Preparing metadata (setup.py) ... done
Requirement already satisfied: aiohttp-sse-client==0.2.1 in ./lib/python3.7/site-packages (from HABApp==0.31.3.Dev) (0.2.1)
Collecting aiohttp<3.9,>=3.8
Using cached https://www.piwheels.org/simple/aiohttp/aiohttp-3.8.1-cp37-cp37m-linux_armv7l.whl (1.1 MB)
Collecting bidict<0.23,>=0.22
Using cached https://www.piwheels.org/simple/bidict/bidict-0.22.0-py3-none-any.whl (36 kB)
Collecting eascheduler==0.1.5
Using cached https://www.piwheels.org/simple/eascheduler/EAScheduler-0.1.5-py3-none-any.whl (20 kB)
ERROR: Ignored the following versions that require a different python version: 0.2.1 Requires-Python >=3.8; 0.2.2 Requires-Python >=3.8; 0.2.3 Requires-Python >=3.8; 0.2.4 Requires-Python >=3.8
ERROR: Could not find a version that satisfies the requirement easyconfig==0.2.4 (from habapp) (from versions: 0.0.1, 0.0.2, 0.1.0, 0.1.1, 0.1.2, 0.2.0)
ERROR: No matching distribution found for easyconfig==0.2.4
WARNING: Ignoring invalid distribution -ip (/opt/habapp/lib/python3.7/site-packages)
WARNING: Ignoring invalid distribution -abapp (/opt/habapp/lib/python3.7/site-packages)
WARNING: Ignoring invalid distribution -ip (/opt/habapp/lib/python3.7/site-packages)
WARNING: Ignoring invalid distribution -abapp (/opt/habapp/lib/python3.7/site-packages)
WARNING: Ignoring invalid distribution -ip (/opt/habapp/lib/python3.7/site-packages)
WARNING: Ignoring invalid distribution -abapp (/opt/habapp/lib/python3.7/site-packages)
I’ve tried a few things but can’t get 3.8 or 3.9 to install and I’m not sure I want to go the route of compiling my own install yet… am I missing something simple?
Python 3.8 should be the standard python for (almost) all distributions by now.
If you don’t want to / can’t upgrade your distribution you can just download the python binaries and install them. There is no need to compile python yourself.
E.g. this will install python 3.10.2 - just make sure to use the latest version which would be 3.10.5 and modify the script accordingly. This would be a step by step tutorial.
Is this a fresh install or an existing, older install of openhabian?
Raspberry Pi reference 2021-03-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 461109415073d2eb67083709662ba983cc191f14, stage2
fresh install onto an unused Pi resulted in 3.9.2
1 Like