That sounds like you should rather use RuleClasses and pass Parameters to the instances or create the Rule Instances from a Parameter file.
Be aware this is a beta and there are issues to expected!!
Safe you and your wife some headache and try things out locally first!
Just create an openhab instance with habapp on your main machine and play around a little bit.
Thanks, I’ll try to spin up another pi to do some testing… time always limited.
I think I’m using the process you describe above and it is working well. I do have some questions, but would rather you use your limited time on stabilizing this release before helping lousy coders like me.
Thanks a lot. Will give it a try the next days
[2022-06-28T22:36:23+0200] [HABApp ] INFO | HABApp Version 0.31.3 Dev
[2022-06-28T22:36:23+0200] [HABApp.mqtt.connection ] INFO | Connecting to mqtt:8883
[2022-06-28T22:36:23+0200] [HABApp.openhab.connection ] INFO | Connected to OpenHAB version 3.3.0 (Release Build)
[2022-06-28T22:36:23+0200] [HABApp.openhab.connection ] INFO | Waiting for openHAB startup to be complete
Result of systeminfo endpoint:
{
"systemInfo": {
"configFolder": "/openhab/conf",
"userdataFolder": "/openhab/userdata",
"logFolder": "/openhab/userdata/logs",
"javaVersion": "11.0.15",
"javaVendor": "Eclipse Adoptium",
"javaVendorVersion": "Temurin-11.0.15+10",
"osName": "Linux",
"osVersion": "5.10.92-v8+",
"osArchitecture": "aarch64",
"availableProcessors": 4,
"freeMemory": 80119376,
"totalMemory": 196083712,
"startLevel": 70
}
}
Does it never get past this message or does it start eventually?
No it does not get passed this point. However it rather seems to be an OH issue: openHAB 3.3 Release discussion - #45 by Dominik_Bernhardt
Do you think it makes sense to make this configurable?
While I have fixed my issue (It was a thing that could not be initialized) I think waiting only until startlevel 70 would for me be a good idea. Otherwise a thing causing issues would block the whole startup of my smart home and I could not even send a notification.
At the end I actually think it is a bug in OH. One failed thing should not stop the complete startup sequence.
I just came across another breaking change:
I my code I use something like:
for item in HABApp.core.Items.get_all_items():
if isinstance(item, OpenhabItem):
...
However, get_all_items seems to not exist anymore. What would be the recommended replacement?
Update:
Ok, found the solution. It’s as simple as this:
from HABApp.core import Items
for item in Items.get_items ():
The idea was to wait until the restore from the persistence service is done and only then connect to openhab so the items have already a defined state. I guess I’ll add a configuration option for which a default is not created in the config file. So you can manually add min_start_level in the config file and it’s also described in the docs but it’s not created by default.
I only try to keep things inside the rule consistent. If other things change I’ll gladly help you out but I don’t consider it a breaking change. It’s impossible to keep all the modules stable and do development.
But since it’s only advanced coders who use this any way (like you) they’ll figure it out anyway (like you) 
It probably makes sense so make the method from the rule self.get_items directly available on the item registry. Wdyt?
Can you reproduce the issue? Then we could create a bug in the oh repo.
At lesat someone else reported the same issue in the 3.3 release thread. I’ll try to reproduce and file a bug.
And one more thing…
I got habapp starting without and error messages and updated my first rules to use the new EventFilter syntax but I don’t see any events 
Habapp is successfully querrying all Items and things from OH but the eventlog is empty beside ThingStatusEvents.
I though you’d announce same great PR that fixes all my bugs.
That’s really strange. I can not reproduce the issue.
Is it just with logging e.g. do your rules process the events correctly?
Or does openHAB emit events but HABApp somehow doesn’t subscribe to them?
Dockerfile also changed to a multi stage build and it now can run without root privileges.
However the volume mounts changed so it would be nice if someone could test this and write a short text how to migrate to the new docker file.
At least I setup an environment to debug HABApp to better analyse the issues. Not yet there to provide any meanigfull PR
It actually seems to be on the OH side. Also when having breakpoints in the eventhandle I can only see ALIVE, and ThingEvents. No single item event is comming through. On the OH UI though I can see the stream of events in the developer tools.
I also tested with the latest stable HABApp release and I have the same issue there. At least it is not related to the Beta.
It was just a small joke because apple used to announce the new and exiting stuff this way.
Does it work with OH3.2?
Maybe the event topic filter is incorrect and there were some changes on the OH side how the subscription was evaluated.
I’ll try to investigate further, too.
Seb, is it this version still compatible with OH 3.2? I still haven’t migrated to 3.3 yet.
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