openHAB 3.0 Release Candidates discussion

you mean in the “add items from textual definition” screen?

yep

Well, I understand it would be practical but it’s certainly not a bug that the items were added the way they are defined. I’m a little lukewarm on adding some text-parsing behind-the-scenes black magic at the last minute, tbh.

I feel that sounds more like the job of a sed command or a text editor like vim.

A couple more observations as I am trying to learn and use the UI to construct rules. In the following test rule, only the first command (setting vFFmpegCamEnableMotion to OFF) is executed. The Dimmer command (setting vFFmpegMotionThreshold to 12) does not execute. Also, I see no postUpdate option in the rule UI. Is that by design or something that could be added in the future?

triggers:
  - id: "1"
    configuration:
      cronExpression: 0/30 * * * * ? *
    type: timer.GenericCronTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: AstroSunData_Rise_StartTime
      state: now
      operator: <
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: vFFmpegCamEnableMotion
      command: OFF
    type: core.ItemCommandAction
  - id: "4"
    configuration:
      itemName: vFFmpegMotionThreshold
      command: 12
    type: core.ItemCommandAction


Nothing in the logs indicates any sort of error and I have full TRACE enabled

log file

2020-12-16 18:33:45.974 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'vFFmpegCamEnableMotion' received command ON
2020-12-16 18:33:45.975 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'vFFmpegCamEnableMotion' predicted to become ON
2020-12-16 18:33:45.975 [INFO ] [openhab.event.ItemStateEvent        ] - Item 'vFFmpegCamEnableMotion' updated to ON
2020-12-16 18:33:45.976 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'vFFmpegCamEnableMotion' changed from OFF to ON
2020-12-16 18:33:49.449 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'vFFmpegCamEnableMotion' received command OFF
2020-12-16 18:33:49.451 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'vFFmpegCamEnableMotion' predicted to become OFF
2020-12-16 18:33:49.451 [INFO ] [openhab.event.ItemStateEvent        ] - Item 'vFFmpegCamEnableMotion' updated to OFF
2020-12-16 18:33:49.452 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'vFFmpegCamEnableMotion' changed from ON to OFF
2020-12-16 18:33:49.456 [INFO ] [openhab.event.ItemStateEvent        ] - Item 'vCamFFMpegAlarm' updated to OFF

Finally, I have a number of DSL rules that use Astro sunrise and sunset conditional comparisons with now() (ie now.isAfter(sunrise) type commands) that I carried over from OH2 and none of them work. I’m assuming this has something to do with move to from Joda to Java time, but I haven’t been successful in figuring the proper syntax to make such conditional comparisons work. Any help here would really be appreciated.

val day_start = new DateTime(AstroSunData_Rise_StartTime.state.toString) 
val evening_start = new DateTime(AstroSunData_Set_StartTime.state.toString) 
 
    if (now.isAfter(day_start) && now.isBefore(evening_start))

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.