One important usage of this forum is solution sharing. How can this be done if everything is migrated to the new UI ? For example, your design patterns.
Another aspect is migration. I’ve migrated from OH2 to OH3 with no problems besides DateTimes. If everything is in jsondb is it easy to migrate ? And take backup ?
One important usage of this forum is solution sharing. How can this be done if everything is migrated to the new UI ? For example, your design patterns.
In the main UI you can export the configuration and share this. On each rule, thing etc. you ahve a page “Code” that shows the configuration of your thing/rule. You can copy this and share it here with others. Also for old ITEM configuration files, theyy can be imported on OH3 on an admin page, so also the old design patterns can be shared.
Another aspect is migration. I’ve migrated from OH2 to OH3 with no problems besides DateTimes. If everything is in jsondb is it easy to migrate ? And take backup ?
Before updating to OH3 you should perform an backup in any case. So copy the userdata, conf and addons folder to another location in case you need them or the OH3 installation fails. As you mentioned the main change in the rules is the Joda time to ZonedDateTime. All other stuff from your rules should still run, unless if in jsondb or on a rules file.
Design Patterns are a generic way to solve common problems in OH. As such they are, with only a couple of exceptions, independent of the programming language rules are written in and how the rules are written (text based or through the UI).
All of the DPs have a Pyton example already added and I’ve started providing JavaScript YAML examples (Time of Day is the only one I’ve posted so far). In each case I try to write the example in a way that shows off the strength of the Language so, for example, the YAML/JavaScript Time of Day example is written to use Ephemeris and uses Item metadata.
With the exception of Items right now, everything in MainUI has a code tab that shows the entity encoded as YAML for sharing in the forum and elsewhere. The entity can be edited in the code view by hand if desired as well (great fit cases where one needs to copy/paste/edit a bunch of Things for example).
I’m not migrating and am instead rebuilding so I don’t know. I think there are some namespaces in the JSONDB fingers that need to be changed.
Backups are the same as ever. In fact they are even better as the JSONDB file are backed up automatically for you on every change so if you encounter a corruption (e. g. the machine crashed while writing out one of the files) there will be a backup created a moment before the failed write.
And the JSONDB files are just text and can be checked in to source control. I do this myself.
@buschif4 & @rlkoshak - would you be able to share how OH automatically generates the pages for the semantic model? Is it based on the item groups? In the past there have been two common approaches to group items together into a zone:
EventHandler] - Dispatching event to subscriber ‘org.openhab.core.automation.internal.module.handler.ItemStateTriggerHandler@18c1509e’ takes more than 5000ms.
I’m still getting it with last snapshot - 2039
Openhab is almost unusable.
script execution of rule with UID 'ephemeris-1' failed: An error occurred during the script execution: Could not invoke method: org.openhab.core.model.script.actions.BusEvent.postUpdate(org.openhab.core.items.Item,org.openhab.core.types.State) on instance: null in ephemeris
how do i know which rule is ephermis-1 ??? and what is there all about?
There is an issue to address that and use the rule name instead of UID in those errors. In the mean time you can query the REST API for the rule with that UID and you should be able to tell from the JSON you get back which rule is the problem.
I would expect you have a rule names or containing “ephemeris” in the name.
It’s no more or less legible than the .things file syntax and .rules file syntax. Don’t confuse familiarity with legibility.
And it’s not more complex than opening a text editor, opening the .rules file, and copy and paste the rule into the forum.
The steps are literally just open MainUI, browse to the rule, click on “code”, copy and paste the rule into the forum. There’s only one extra click.
I’ve already opened an issue for import of the YAML files.
I don’t know if there is an issue for bulk import/export. I’m not sure it makes a lot of sense. If you are working with bulk like that it may make more sense to use the raw JSON and REST API, the JSONDB files themselves, or just stick to your text based configs in the first place. But a feature request can be made by anyone.
The only code here is in the conditions. That’s the most likely source of the error. I can think of a few ways to debug this.
First make sure Morning_Scene is properly defined. I’m assuming you selected the Item through the UI so it’s probably fine but if you edited the YAML in the code tab it might have a typo or something.
Simplify the script condition. Just check for Holiday_Scene first. If that works add in the isWeekend and then the isBankHoliday. That should tell you which call is failing or if there is something fundamentally wrong with the script over all if Holiday_Scene.state == ON fails.
There is nothing obviously wrong with the rule over all. But I’ve no experience writing Rules DSL in MainUI so there may be something I don’t know that is acting weird. We need to find which of those three calls is failing to determine if a bug needs to be filed I think.