Thank you very much for the remoteopenhab binding. For me and many others (I guess) a “game-changer” !
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.
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.
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.
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.
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.
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.
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?
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]
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