openHAB 3.0 Release Candidates discussion

There is an open Issue on that. I think it was just forgotten. But I think it needs to be added to core.

It’s not necessarily an error but I’m all but certain you can’t use DateTimes in Conditions like that. You’ll need to create a Script Condition and do it in code. “now” is always going to be > AstroSunData_Rise_StartTime.toString alphabetically which is what that condition does as written.

That explains why the rule is never running.

I think the following will work.

val day_start = AstroSunData_Rise_StartTime.state.toZonedDateTime

Maybe it’s getZonedDateTime. I’m on my phone and can’t look it up easily.

Hi @iLion
I’ve got the same issue (2.5.1 and 3.0) --> like shown in the thread I set up OH2 on a rasperry with UDP binding just for the Keba Connection. Using the Remote openHAB Binding I connected OH2 to OH3 --> working so far.

Regards,
Herbert

Thank you very much for your help and insight. I often rely on your posts for help.

It‘s true that the items were defined that way, but it‘s a way that worked in textual config and breaks in databases config. So either the data should be removed or better converted to the way it needs to be configured in the database.

tomorrows snapshot will bring a couple of fixes wrt automation, see https://ci.openhab.org/job/openHAB-Core/620/changes 33.

Distro #2083 contains those changes - happy testing!

I understand you hesitate now and mid-term (3.1 or so) this area needs improvement (things import and some sort of mass editing, see also this thread) in one way or another.
That’s alright to postpone as it doesn’t affect so many people.
But with a client-side tool, no user who migrates from OH2 can make OH move the label into metadata. And migration is (well, should be :wink: ) a onetime action. So that capability should be in by the time he starts with OH3 (i.e. asap). Please forgive me for urging you, but IMHO it’s pretty important from the UX pov.

I did a upgade with my docker installation from M5 to RC1.
After that upgrade my items were still there, but all installed bindings were gone. So nothing was working anymore.

If you have the userdata volume properly set up the bindings reinstall in the new container.

Not so much, I’m in the process of migrating the demo server’s items into a JSON DB-managed model, and I have several times updated the items with the “add from textual definition”. If the item already exists it will display the little icon but at least in my case it still overwrites the items correctly. The only thing it’s not doing is remove a link or metadata if you specified one and removed it from your definition afterwards.

Just made an upgrade again for Log-Files:

openhab_1 | ++ cmp /openhab/userdata/etc/version.properties /openhab/dist/userdata/etc/version.properties
openhab_1 | + ‘[’ ‘!’ -z ‘/openhab/userdata/etc/version.properties /openhab/dist/userdata/etc/version.properties differ: byte 275, line 8’ ‘]’
openhab_1 | + echo ‘Image and userdata versions differ! Starting an upgrade.’
openhab_1 | + tee /openhab/userdata/logs/update.log
openhab_1 | Image and userdata versions differ! Starting an upgrade.
openhab_1 | ++ date +%FT%H-%M-%S
openhab_1 | + backup_file=userdata-2020-12-17T11-49-28.tar
openhab_1 | + ‘[’ ‘!’ -d /openhab/userdata/backup ‘]’
openhab_1 | + mkdir /openhab/userdata/backup
openhab_1 | + tar --exclude=/openhab/userdata/backup -c -f /openhab/userdata/backup/userdata-2020-12-17T11-49-28.tar /openhab/userdata
openhab_1 | tar: Removing leading `/’ from member names
openhab_1 | + tee -a /openhab/userdata/logs/update.log
openhab_1 | + echo ‘You can find backup of userdata in /openhab/userdata/backup/userdata-2020-12-17T11-49-28.tar’
openhab_1 | You can find backup of userdata in /openhab/userdata/backup/userdata-2020-12-17T11-49-28.tar
openhab_1 | + exec /openhab/runtime/bin/update
openhab_1 | + tee -a /openhab/userdata/logs/update.log
openhab_1 |
openhab_1 | ################################################
openhab_1 | openHAB Docker update script
openhab_1 | ################################################
openhab_1 |
openhab_1 | The script will attempt to update openHAB to version 3.0.0.RC1
openhab_1 | Please read the following notes and warnings:
openhab_1 |
openhab_1 | Replacing userdata system files with newer versions…
openhab_1 | Clearing cache…

openhab_1 | mv: cannot stat ‘/openhab/userdata/jsondb/org.eclipse.smarthome.core.thing.link.ItemChannelLink.json’: No such file or directory
openhab_1 | Replacing: String org.eclipse.smarthome.core to org.openhab.core in file /openhab/userdata/jsondb/org.openhab.core.thing.link.ItemChannelLink.json
openhab_1 | Replacing: String org.eclipse.smarthome to org.openhab.core in file /openhab/userdata/jsondb/org.openhab.core.thing.link.ItemChannelLink.json
openhab_1 | Moving: From /openhab/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json to /openhab/userdata/jsondb/org.openhab.core.thing.Thing.json
openhab_1 | mv: cannot stat ‘/openhab/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json’: No such file or directory
openhab_1 | Replacing: String org.eclipse.smarthome.core to org.openhab.core in file /openhab/userdata/jsondb/org.openhab.core.thing.Thing.json
openhab_1 | Replacing: String org.eclipse.smarthome to org.openhab.core in file /openhab/userdata/jsondb/org.openhab.core.thing.Thing.json
openhab_1 |
openhab_1 |
openhab_1 | SUCCESS: openHAB updated from 3.0.0.M5 to 3.0.0.RC1

Again all the installed bindings are gone

What should be wrong with my userdata volume, same configuration already worked with openhab 2.5.x upgrades

1 Like

I have upgraded OH3 Docker many times but have not yet tried RC1.

Ok, seems like I was too impatient. Now after some minutes all bindings are shown and working

1 Like

Had a rule triggering problem with RC1, with that snapshot it’s working again

@Kai : the last download of the kar file leads to a file with extension .mid and not .kar. Is there a problem ?
https://ci.openhab.org/job/openHAB3-Distribution/lastSuccessfulBuild/artifact/distributions/openhab-addons/target/openhab-addons-3.0.0-SNAPSHOT.kar

the 2083 linuxpkg deb file update is not showing up in sudo apt update. Its still shows 2082 as the latest. the deb file seems to have landed in
https://openhab.jfrog.io/openhab/list/openhab-linuxpkg/pool/main/3.0.0~20201217083906/
instead of
https://openhab.jfrog.io/openhab/list/openhab-linuxpkg/pool/main/3.0.0~S2082/ that could be an issue?

When I moved from RC1 to Build #2083 I forgot to clear the Firefox cache. Using OH3 with http was ok, but with https I had a blank screen and a series of java errors in openhab.log.

In the meantime I’ve cleared the Firefox cache and now it’s ok, but I’ve also deleted openhab.log.

when i add by a item in metadata stateDescription value=[%d %%], there is no % behind the value in the gui.
when i add value=[%.1f \u00B0C] on a temperature item, there is a °C, also when i add [%.1f °C] its working, but not with the %

You don‘t need the square bracket in state description

@rlkoshak I have tried your suggestion for converting DateTime to ZonedDateTime (java.time)

val day_start = AstroSunData_Rise_StartTime.state.toZonedDateTime
Maybe it’s getZonedDateTime. I’m on my phone and can’t look it up easily.

but unfortunately I can’t them to work properly to convert Astro Sunrise to ZoneDateTime in my rule.

rule "Test Astro"
when
    Time cron "/30 * * * * ? *"

then
   // val day_start = now.withHour(6)

  val day_start = AstroSunData_Rise_StartTime.state.toZonedDateTime()
  

    if (now.isAfter(day_start))
        {  
            vFFmpegCamEnableMotion.sendCommand(OFF)            
        } 
end

I’ve tired both toZonedDateTime and getZonedDateTime with and without ending () but I the rule still does not execute properly in OH3 when AstroSunData_Rise_StartTime is the object of camparison with now. I know that this rule can work in OH3 because if I set day_start = now.withHour(6) as shown in the comment within the rule, the rule works fine and I also have several Astro based rules running in OH2 that are coded exactly as this example and they work without issue. I’ve pretty much exhausted my options here as I believe your suggestion should work. I know the Astro.Items contain the proper data because I can see them in UI when I look at the Items. Is it possible there is a bug in the java.utils libaray pertaining to date conversions as incorporated in OH3? I’m open to any and all options to try to get this to work.

It’s getZonedDateTime(). You might need to cast the state to a DateTimeType. Without logs its hard to say.

val day_start = (AstroSunData_Rise_StartTime.state as DateTimeType).getZonedDateTime()

But a bigger question is why it’s coded this way? Why run it every 30 seconds? You can use the event channel on the Astro Thing to trigger the rule at sunrise.