openHAB 4.3 Milestone discussion

[Larsen (Locke)]

I discovered a problem with persistent rollershutter items in combination with the rollershutterposition-profile: The position is not restored as numeric e.g. after a system restart.

I guess this started during the milestones (but I’m not sure):
When a rollershutter item (I tried mapdb and rrd4j) is restored after a system restart, the position is not defined as numeric. I noticed this because the rollershutter-profile always failed to change the position after a system restart if the position of a blind is <> 0 (after e full UP it worked again).
My current workaround is to overwrite all items at startup with the current numeric values like this:

current workaround

configuration: {}
triggers:
  - id: "1"
    configuration:
      startlevel: 70
    type: core.SystemStartlevelTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    label: overwrite blinds
    configuration:
      type: application/javascript
      script: |
  var rolloX;
  var rolloX_list = items.getItem('RollosAlleG').members;
  for (var rolloX_index in rolloX_list) {
    rolloX = rolloX_list[rolloX_index];
    if (rolloX.numericState != 0) {
      rolloX.sendCommand(rolloX.numericState);
      console.debug(rolloX.name);
    }
  }
    type: script.ScriptAction

I’m not sure if this only happens for blinds, maybe somebody noticed something similar.

[mstormi (Markus Storm)]

@Larsen

I discovered a problem with persistent rollershutter items: The position is not restored as numeric e.g. after a system restart.

Err not sure what you mean. “The position” is stored in the actuator and propagated via a channel to an item as soon as the thing/channel gets online. You can use but don’t need persistence to restore it.

Also, persistence only restores item values but does not issue a send command so if you restore a persisted position value of x but the rollershutter is at y, blinds won’t change to x (restoration is no “send”, just “update”).

And to the best of my knowledge it has been like that more or less ever.

[Larsen (Locke)]

Sorry if this is off-topic for milestones. I could start a new post too.
The position is tracked by the rollershutterposition-profile from the addon-store (sorry, I didn’t provide that information). This is a profile (part of the release) to track the position even for shutters that don’t have hardware for that. The profile manages the position by controlling the time the shutter needs for UP and DOWN-movements. As the hardware has no position you need persistence if the position should be available after a restart.

I can of course live with my workaround but I thought it might be good to provide the information of this little bug. I saw in git that the profile was not touched for a year so maybe it’s always been like that and I just didn’t notice.

[Bernd_Ritter]

Could someone check the issue with duplicate binding names, mentioned here

Broadlink binding [4.1.0.0;4.3.x)

I have installed OpenHAB 4.3.0 RC1 and I installed the broadlink binding. I noticed, though, that there actually are two bindings with the same name: this one and an older one related to a broadlink thermostat. During first installation they cannot be distinguished. When using the add-on store distinction is easy. Is there a way to solve this minor issue? Thanks for your hard work, Lionello

[helmar74 (Helmar)]

Hi, I just upgraded 4.3.0-1.
I get the error message:
2024-12-15 20:18:36.920 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model ‘fussball.rules’, using it anyway:
The method getZonedDateTime() from the type DateTimeType is deprecated
The method getZonedDateTime() from the type DateTimeType is deprecated

The code in the rule is:
val Number Differenz = ( ( (i_fb_naechstes_Bayernspiel.state as DateTimeType).zonedDateTime.toInstant.toEpochMilli) -( (Jetzt).zonedDateTime.toInstant.toEpochMilli) ) / 1000

I think I should use getZonedDateTime(ZoneId.systemDefault()) instead.

Can someone assist to find the correct syntax for the rule above?

Thanks in advance!

UPDATE:
I changed it to this:
val Number Differenz = ( ( (i_fb_naechstes_Bayernspiel.state as DateTimeType).getZonedDateTime(ZoneId.systemDefault()).toInstant.toEpochMilli) -( (Jetzt).getZonedDateTime(ZoneId.systemDefault()).toInstant.toEpochMilli) ) / 1000

Not quite sure if it is ok, that way?

[sihui]

@helmar74

Not quite sure if it is ok, that way?

The method getZonedDateTime() from the type DateTimeType is deprecated

oH 4.3.0.M5 if (now.isAfter((Astro_DaylightStart_Time.state as DateTimeType).getZonedDateTime())) {... I use this statement and it works fine, but I get for every occurrence the topic info in the log. What is the correct instruction for the future? I can only find this way to compare with now.

[laursen (Jacob Laursen)]

@helmar74

DateTimeType).zonedDateTime.toInstant.toEpochMilli) -( (Jetzt).zonedDateTime.toInstant.toEpochMilli) ) / 1000

This could be simplified:

DateTimeType).instant.toEpochMilli) -( (Jetzt).instant.toEpochMilli) ) / 1000

[mstormi (Markus Storm)]

@helmar74

Not quite sure if it is ok, that way?

Yes. It’s mentioned in the release notes.

[mstormi (Markus Storm)]

Then again, I also replaced with getZonedDateTime(ZoneId.systemDefault()) but still keep seeing deprecated warnings.
So is the replacement wrong or the warning ?

[laursen (Jacob Laursen)]

@mstormi

Then again, I also replaced with getZonedDateTime(ZoneId.systemDefault()) but still keep seeing deprecated warnings.
So is the replacement wrong or the warning ?

My guess would be that you still have at least one usage of getZonedDateTime() somewhere, can you show the warning and the complete rule/file?

[digitaldan (Dan Cunningham)]

Is there a 4.3.1 snapshot branch yet to continue building against 4.3 ?