openHAB 3.0 Milestone 2 discussion

Thank you very much for the remoteopenhab binding. For me and many others (I guess) a “game-changer” :grinning:!

Next to OH2 compatibility this will bring us solutions for multiple locations and when dealing with range limitations of wireless protocols. Auto discovery of multiple OH servers and items on these works fine.

Really appreciate it!!

To do that you would need encrypted communications. This binding is unencrypted http only.

Agree, but at least my use cases concern multiple locations on the same LAN. Multiple LAN’s can be tied together using VPN connections if necessary.

2 Likes

i have an Issue with the Main UI.
When i connect to openhab via myopenhab or via nginx reverse proxy from outside my Network.
I don’t see item states, only a “-” if work inside my LAN i see the itemstates in MainUI.

im working on Docker with OH 3 M2

Hi,
I am very excited about M2 of openhab3 and make my progress with the setup. During this I have recognized some points to imptove the ease of use.

  1. The possibilitiy to change the hierachy inside the semantic model afterwards, during the conception this is very important I think (drag and drop)
  2. The possibilty to easily copy items, channels and thing names. (like in paper ui)
  3. Display of the columns inside a script (impotant for the analyses of a failure)
  4. The possibilty to change the size of the script editor

Thank you very much to all the programmers for this nice piece of software!!!

3 Likes

I have been away too long from the cutting edge in terms of deploying snapshot builds; Is there a way to trigger an update of the openhab-core bundles in the karaf runtime?

Have you solved this problem? I’m getting the same error.

Problem with MergeList /var/lib/apt/lists/openhab.jfrog.io_openhab_openhab-linuxpkg_dists_testing_main_binary-i386_Packages

Can't call method "policy" on an undefined value at /usr/bin/apt-show-versions line 56.

Thanks

I didn’t solve it and did a manual install to try 3.0.0-M2 . Something seems wrong with the testing distribution, because unstable updates without problems

What do you mean by “part of OH3”? Node-RED works fine together with OH, e.g. using these nodes. But I don’t think we’ll see OH spinning up a whole NR instance itself.

Why not just update the whole snapshot the following day?

To do that you would need encrypted communications. This binding is unencrypted http only.

This is only the current state. Improvements are already in progress for this binding, to not say already being reviewed.
Support of HTTPS is on the todo list but not yet implemented.

4 Likes

Mmmhh the distribution does not include the core, and it is running behind

How can you install the distribution and run it without the core ?? :face_with_raised_eyebrow: :roll_eyes:

You appear to be doing something odd in your installation or there is some confusion. You cannot upgrade the core from the karaf console. You can upgrade everything using what ever installation method you originally used. For example, if installed using apt, change the repo to point to the snapshots apt repo and run apt upgrade and it will pull down the latest OH snapshot.

1 Like

I’m seeing odd issues with MS2 with the use of triggeringItem in my rules. It appears to be pointing at incorrect items. For instance a rule may be waiting for a change on item A or item B and when I check triggeringItem it give me a random item (not A or B). I am seeing this across different rules.

I suspect this starting happening whilst using MS 1 prior to upgrade but have no way of proving that.

Anyone seeing anything similar? Any suggestions on how I move forward?

Cheers,

James

I think you should report this at


It is clear that OH3 triggeringItem is derived in a different way

and this is worrying. I’d guess you might be seeing “old” values there.

I mean that in OH2, NodeRed could be installed and integrated by a mouse click. Will this be as easy in OH3?

I do run 3.0.0-SNAPSHOT - Build #2004, which originated on 02-Nov-2020 11:46:30 @ https://ci.openhab.org/job/openHAB3-Distribution/2004/, in order to have https://github.com/openhab/openhab-core/commit/5a9c5e7d87716406302d5b1eb1e5966bab8195b8 in my operational system. That commit is part of https://ci.openhab.org/job/openHAB-Core/561/ , which originated on 01-Nov-2020 00:53:22, witch is before #2004 of the distribution. Moreover, when I inspect https://ci.openhab.org/job/openHAB-Core/ it seems that this is not part of the upstream projects of https://ci.openhab.org/job/openHAB3-Distribution/ . Just asking the question, because in the org.smarthome days I remember this required a manual intervention in the build process [#Update - I was looking at a wrong bundle when doing a bundle:list -s in my environment)

Anyways, what I want to solve is the following: in my rules I have some Item.historicState() which, I presume, return a Number with a QuantityType if the Item is defined with an UoM. However, when I do some checks on “instanceOf QuantityType” and “instanceOf DecimalType”, these both return false (I refer hereby to https://www.openhab.org/docs/configuration/rules-dsl.html#number-item)

I also see a

2020-11-05 08:38:14.047 [ERROR] [g.openhab.persistence.rrd4j.internal.RRD4jPersistenceService] - Could not create rrd4j database file ‘/var/lib/openhab/persistence/rrd4j/TeslaOdometer.rrd’: null

in my logs, which I don’t know what I that is happening (all other .rrd seem to be fine)

[Disclaimer : I come from the pre-UoM era, discovering a lot of new stuff after some years of absence]

The method historicState() returns a HistoricItem. Try to check on QuantityType or DecimalType against the return value of its getState() method.

1 Like

Check, I noticed this mistake after my post

I also forgot to remove all .rrd4j files after the fixes pushed on 01 nov, e.g. it still had all the data/strings with UoM in them.

on a separate note, why do we still have both .state and .getState() ? for consistency reasons you would rather expect .state not to be supported anymore