openHAB 3.1 Milestone discussion

[NCO (E. Gerland)]

@rossko57

no-one may be interested in DSL any more

I am!

[NCO (E. Gerland)]

@AndrewFG

There is no context to infer the closure’s argument types from

I get this as well.

In my case it’s not related to createTimer, but to .members. stuff like this:

G_Lights.members.forEach[light | light.sendCommand(light.historicState(now.minusDays(days)).state.toString)]

Obviously this is just popping up in the logs during initial startup.
Triggering a reload of one of the specific rules later on does not create this message.

[rossko57]

That’s exactly the case I outlined earlier; the parser cannot guess what kind of Item the abstract light will turn out to be.

openHAB 3.1 Milestone discussion

Not necessarily, it might be pickier now about things that it let slide before. Example someGroup.members.forEach[ x | { ... process x ... } ] At validation time, it is not possible to guess what kind of Item x will be - a Switch type perhaps, or a DateTime, or? That means the validator can’t properly validate the processing code, is it doing legitimate things with/to x? At runtime each member, each x, will of course be whatever it be, and you’ll either process it appropriately or blow up…

[NCO (E. Gerland)]

@rossko57

I outlined earlier

you are right - sorry for that.
Thank you, I will try to adjust it accordingly.

By the way (talking about DSL rules).
I did not find yet a thread with recommendations which rule engine to use instead.
Do you have a recommendation?

[rossko57]

There’s only one rule engine in OH3. You get a choice of languages to code your rules in, including DSL.

[NCO (E. Gerland)]

Alright - thank you, I will look into this then.

[hobaka]

Network Binding in 3.1 no Ping within Docker.
I will go back to 3.0.

Raspi 4+ with Docker

[yfaway (YF)]

Just upgraded from 3.0 to 3.1. After the first restart, quite a number of components were missing including basicui. Second restart restored everything.

Thanks everyone.

[janwo (Jan Wolf)]

I also haven’t fixed this problem. That’s why I reinitialize rules on item changes, maybe this can help? Example code can be found here: SmartBerry 🍓 - Smart home framework for openHAB

[lipp_markus]

Upgraded successfully; also for me, basicUI and other components were reported missing immediately after upgrade, a second restart cured it all. My heartfelt thanks to all maintainers, developers and everyone else who contributed!!!

[Arno1st (Arnaud Gautier)]

Hi all,

I have just upgraded my OH 3.0.2 to the 3.1.0. Both on Docker through Synology.

Everything is OK except these two error lines (in ‘openhab.log’):

2021-07-04 20:42:29.452 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@3f172cc3[provider=null,keyStore=null,trustStore=null]
2021-07-04 20:42:29.459 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@3f172cc3[provider=null,keyStore=null,trustStore=null]

Is there a way to solve this problem?

I read some previous comments about the same problem but I did not find a solution.

Thanks a lot for your help.

Arnaud

[kristofejro (Kris)]

It was already present in 3.0.1.M3
I have also never found solution for this.

[alexkarageorgis (Alexandros Karageorgis)]

hello, trying to decide how i setup my RPI with OH3, can someone kindly explain what the difference is between main/stable and the milestone versions? if i undertand. you can be on 3.1 stable for production. if you pick main then you could end up with a 3.1.1 or something like that which isnt released. But you can also pick to be on 3.2 milstone (which is a pre-release candidate.) but this make the main/stable side of things irrelevant?

[rlkoshak (Rich Koshak)]

@alexkarageorgis

if i undertand. you can be on 3.1 stable for production. if you pick main then you could end up with a 3.1.1 or something like that which isnt released. But you can also pick to be on 3.2 milstone (which is a pre-release candidate.) but this make the main/stable side of things irrelevant?

This is incorrect.

• Main/Stable: released twice a year after a month or so freeze to work off any major bugs. It’s stable in that it rarely changes unless there is a major bug discovered after the release that needs to be back ported. That bug patch will be a third point release (e.g. if there is one for the current OH 3.1.1 the new stable version will become 3.1.2).

• Milestones: released monthly without a freeze. The open issues are looked at and if there are no major ones to be worked a new milestone is released.I believe the current milestone is 3.2 M2.

• Snapshots: release nearly daily and contain all the changes merged into the baseline up to the prior day.

All three of these are “released”. The major difference is the frequency in which they are released. In practice I find the milestones to be as stable and free from bugs as the release.

[alexkarageorgis (Alexandros Karageorgis)]

@rlkoshak thanks! Milestone aside (which is what i am on) what is the difference then between main and stable? or isnt one? the configuration menu gives you a choice. - does it affect something on milestone?

[Udo_Hartmann]

I may be wrong, but I think it‘s when upgrading from OH2 to OH3. There was the old stable build and the new stable build.

[mstormi (Markus Storm)]

@alexkarageorgis

what is the difference then between main and stable? or isnt one? the configuration menu gives you a choice.

You are confusing openHABian (the underlying operating system, that is) with openHAB (the application that is). (note: this thread is on the application only so whenever someone replies, he refers to that).
openHAB is really release-milestone-snapshot. While release is also often called “stable” because that by nature it is in fact, it’s not a good term for this as it quickly leads to confusion. The term “main” is even worse. While not completely wrong either, it has multiple more meanings on multiple levels.

There are also 3 maintained variants of the Operating System, openHABian, called ‘branches’:
‘openHAB3’, ‘main’ and ‘stable’.
These you can select from when you start openhabian-config via menu 01 (plus changing branch is offered on start wheneever there is updates).

‘stable’ is the branch you need to use when you still want to run openHAB 2 application.
‘openHAB3’ and ‘main’ are the right branches if you run openHAB 3.
‘openHAB3’ is the (attention, word play) stable equivalent of what ‘release’ is for the application layer and ‘main’ is the ‘snapshot’ equivalent.

[alexkarageorgis (Alexandros Karageorgis)]

gotsa! ty @mstormi

[Matthias_Marx]

Anybody has fixed the issue with the source locator path issue? I am having on Windows with OH 3.4.0 and 3.4.1. Everything is working but if I install Hue emulation the system is useless.

[hmerk (Hans-Jörg Merk)]

Posted to the wrong topic, as your issue is not 3.1 Milestone related.