openHAB 3.4 Milestone discussion

Setup, Configuration and Use News & Important Changes
63

Seeing the same behavior here. openhab-3.4.0~S3124 updated this morning and can’t login now. Running it on a Rocky Linux 8.6 system. I reset the password using the console and still can’t login.

The log is showing:

2022-10-12 08:48:24.605 [WARN ] [uth.internal.AbstractAuthPageServlet] - Authentication failed from [ipv6 address]: Wrong password for user username
64

It’s a known error, please try this workaroud until it is fixed:

1 Like
65

Yep, added that and got webUI access again.

66

Upgraded to 3.4.0.M3 and started getting the errors:

2022-10-17 20:15:00.176 [ERROR] [hab.automation.script.file.garage.js] - Failed to execute rule Garage-Doors---Check-Every-5-Minutes-234f36c9-33db-430f-abdb-25c78dd8c074: TypeError: (intermediate value).get is not a function: TypeError: (intermediate value).get is not a function
        at execute (garage.js:56)
        at doExecute (webpack://openhab/./node_modules/openhab/rules/rules.js?:243)
2022-10-17 20:15:00.195 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule 'Garage-Doors---Check-Every-5-Minutes-234f36c9-33db-430f-abdb-25c78dd8c074': Fail to execute action: 1

the offending line is:

if (actions.get('astro', 'astro:sun:home').getElevation(null) > 0) {

I downgraded to 3.4.0.M2 and the errors stopped occurring,

67
68

I have to inform that Shelly support for Shelly 1 devices (not Plus/Pro) is broken in 3.4M3 due to the updated Californium libs (2.0.0 → 2.7.3) included in the dist. The code compiles, bit the binding doesn‘t receives Coap traffic.

I noticed the merged issue by mistake, but hadn‘t the chance to test before M3 was closed.

@openhab-core-maintainers: Please inform binding authors on changes like that. Every update of included libraries could break binding compatibility and should be verified by the binding author/

2 Likes
69

@markus7017 Sorry, Markus, you’re obviously right, we should have done so. :frowning:
Do you see any chance to fix those issues in Shelly or would we need to downgrade Californium again?

70

I need to investigate. I did some testing and found out that it works in general, but the events are delayed by 5-10sec compared to 100…500ms before. This is not acceptable for the user. I have no clue if this is related to an architectural change, missing initialization setting, comm problem etc. Maybe I need to contact the Californium project.

I would prefer to revert the change before M5 is coming and I was not able to fix it. I‘ll spend some time at the weekend on this.

By the way: The Tradfi binding might also be affected, it also uses Californium

72

Ok, I was able to fix the problem. The multicast initialization needed another parameter with Californium 2.7.3. @fwolter I submitted a PR and requested your review. Maybe we could push this a little bit as a hot fix for M3 users.

@wborn I noticed that there is Californium 2.7.4. If you consider to bump to the latest version let me know. If so we should do it now and test, so M3 is broken for Shelly and M4 works with changes in sync.

5 Likes
73

@Kai pls update download page to include M4

74

I already did, but for some reason, the website build fails… We’re on it.

75

Should be solved now.

2 Likes
76

@Kai @Confectrician not yet

https://github.com/openhab/openhab-distro/releases/download/3.4.0.M4/openhab-3.4.0.M4.zip not found

77

Seems like the uploads are missing or went wrong.
I have no access to upload, but @Kai can take care of it later. The download urls should be working then right away.

78

Mea culpa. I am still not used to do the additional step of uploading the artifacts to Gitlab after a release… Now they are there!

1 Like
79

Good morning!

Yersterday I did an update. First to the M3, later to the M4 version.
After updating to M3 I had a problem with the sonos binding. Maybe its caused to the Upnp.
In the Karaf Console some states are “Waiting”

257 │ Waiting │  80 │ 2.6.1                  │ JUPnP Library
277 │ Waiting │  80 │ 3.4.0.M4               │ openHAB Add-ons :: Bundles :: Sonos Binding
279 │ Waiting │  80 │ 3.4.0.M4               │ openHAB Core :: Bundles :: Configuration UPnP Discovery
287 │ Waiting │  80 │ 3.4.0.M4               │ openHAB Core :: Bundles :: UPnP Transport

I came from 3.4M2. In M2 everything was working fine. What can I do to solve this problem?

The problem looks solved. I restored the backup from 3.4M2 and everything is working fine now.

80

There haven’t been any changes wrt JUPnP nor Sonos, so I doubt that this issue is newly introduced.
Could you try to manually stop/start the bundles and check, what service they are waiting for?

81

Yesterday I did start/stop the bundles. Nothing happend, they were still in Waiting status. Today I restored the backup zip file from yesterday (3.4M2) and after that all the bundles went to Active, also Sonos is working again.

1 Like
82

There’s now openhab-core#3147 to upgrade to it.
It would be nice if you can give it a test again. :slight_smile:

83

i have problem with ECMA 11 in M4 events.ItemName does not work.

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: NP_DA_RANGE
    type: core.ItemStateChangeTrigger
  - id: "2"
    configuration:
      itemName: NP_DA_RANGE_D
    type: core.ItemStateChangeTrigger
  - id: "3"
    configuration:
      itemName: NP_DA_RANGE_14D
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "1"
    configuration:
      type: application/javascript;version=ECMAScript-2021
      script: >-
        var logger =
        Java.type("org.slf4j.LoggerFactory").getLogger('org.openhab.rule.nordpool');


        logger.info(event.itemName);

    type: script.ScriptAction

gives

2022-11-08 20:00:00.632 [INFO ] [org.openhab.rule.nordpool           ] - null