Marketplace on OH3.4
1 Like
Anyone else observing this (M1 and latest snapshot as well):
openhab> bundle:list
START LEVEL 100 , List Threshold: 50
Error executing command: java.lang.NoSuchMethodError: 'java.lang.Object org.osgi.framework.ServiceReference.adapt(java.lang.Class)'
I believe the issue is that the add-on developer needs to compile separate jar files for 3.4 and 4.0. This has been done for all the official addons but itâs up to each individual developer of marketplace addons to do this.
For now at least, on the marketplace two entries are needed, one for 3.4 and one for 4.0. The marketplace titles can include a Maven style version range that OH will see and follow, only showing the entries for versions of the add-on compatible.
There is nothing you can do to make a 3.4 add-on jar work on 4.0 unless you rebuild the jar file yourself.
1 Like
Hi,
if found a Blockly JavaScript Problem with OH4 regarding calulations:
I created a little script
We see that the state of an item is saved in a variable named âoldâ. The Item is a Number.
We see also ne variable named ânewâ which is calculeted from old and new value of another item of type number. Finally both variables are added.
With the âoldâ script engine from OH3 the result looks like this:
2023-03-12 17:28:19.046 [INFO ] [org.openhab.rule.db19777b97 ] - 518
2023-03-12 17:28:19.069 [INFO ] [org.openhab.rule.db19777b97 ] - 0.09999999999999964
2023-03-12 17:28:19.074 [INFO ] [org.openhab.rule.db19777b97 ] - 518.1
With the ânewâ script engine from OH4 the result looks like this:
2023-03-12 17:23:03.001 [INFO ] [org.openhab.automation.script.ui.db19777b97 ] - 518
2023-03-12 17:23:03.004 [INFO ] [org.openhab.automation.script.ui.db19777b97 ] - 0.10000000000000009
2023-03-12 17:23:03.006 [INFO ] [org.openhab.automation.script.ui.db19777b97 ] - 5180.10000000000000009
You can see that the strings are concated instead of calculating the numbers. Is there a chance to migrate such scripts? I didnât find a solution.
If the developer compiles the jar with the following options it will work on 3.2.0 through 4.0.0
-Dohc.version=3.2.0 -Dmaven.compiler.source=11 -Dmaven.compiler.target=11 -Dkaraf.version=4.3.7
EDIT: you also need to readd the binding.xml file (dont delete the addon.xml)
Show the code this compiles into by clicking the little page icon in the bottom right. I think I know whatâs going on but need to see the JS code to confirm.
In JS Scripting, the default state of an Item is always converted to a String. So old is a String. However, when you start to do operations itâs able to convert from the String to a Number on the fly so it was able to convert the operands and therefore the value for new to numbers. But for result, the first operand usually dictates the type of operation performed. Because old is a String a + with Strings means concatenation it converts new to a string and concatenates them.
I bet if you swap so new comes first it will work.
Note, new is a reserved word in JS (and most other languages). I canât rule out that using it as a variable name isnât causing problems too.
no problem (of course i changed the names of the variables):
Old engine:
var oldValue, newValue, result;
var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);
oldValue = itemRegistry.getItem('WeatherStation_RainCounter').getState();
newValue = event.itemState - event.oldItemState;
result = newValue + oldValue;
logger.info(oldValue);
logger.info(newValue);
logger.info(result);
new engine:
var oldValue, newValue, result;
oldValue = items.getItem('WeatherStation_RainCounter').state;
newValue = event.itemState - event.oldItemState;
result = newValue + oldValue;
console.info(oldValue);
console.info(newValue);
console.info(result);
I swapped the variables. The result is the same:
2023-03-12 18:02:07.978 [INFO ] [org.openhab.automation.script.ui.db19777b97 ] - 518
2023-03-12 18:02:08.046 [INFO ] [org.openhab.automation.script.ui.db19777b97 ] - 0.10000000000000009
2023-03-12 18:02:08.048 [INFO ] [org.openhab.automation.script.ui.db19777b97 ] - 0.10000000000000009518
OK, so oldValue is definitely a string and newValue is the result of a calculation of two Java Objects. @florian-h05, @stefan.hoehn, would it make sense to add an option to get the numbericState and quantityState to the âget state of Itemâ block?
Or perhaps access to a parseFloat block?
I suspect this is going to hit a number of users.
In the mean time you can use an inline script block with:
oldValue = items.getItem('WeatherStation_RainCounter').numericState
1 Like
just wanted to share I upgraded successfully from openHAB 3.4.1 runningon 32bit arm orange pi, to 4.0 M1 running as Docker container on x86 architecture. only issue I had was to create the logs directory in the userdata directory, otherwise the upgrade process wasnât started.
Ok. Many thanks. Should i create an issue in github?
Updated from 3.4.2 to 4.0.0.M1 on Docker.
Everything is working great.
Exept Iâm missing the shelly manager.
Is the shelly manager not part of 4.0.0.M1 anymore?
http://<openHAB IP address>:8080/shelly/manager
3 Likes
I get the same.
Same here, shelly manager is not found.
It wouldnât hurt.
Thx, Christian.
Can you please add the OH3 and OH4 code as well to the issue and a link to the forum here. I will look into the problem eventually with @florian-h05 .
2 Likes
Of Course! I added the JavaScript code
Hello,
I performed the upgrade to 4.0.M1. However, I have the following remnant from the darksky binding in my startup log. While it is little more than an annoyance I canât find anywhere to surpress it. Any assistance would be appreciated.
2023-03-13 13:39:27.248 [WARN ] [core.karaf.internal.FeatureInstaller] - The binding add-on 'darksky' does not exist - ignoring it.
Kr,