Issue of the topic:
I “upgraded” from 3.4.4 to 4.0.1. To be precise, because of upgrade issues (Java) I deployed a new installation and imported the configuration from 3.4.4. I’m not sure if this is supportet but most things seem to work as expected. For now there is only one thing I’m confused:
I noticed that different Items changed behaviour in case of QuantityType and thus some if statements do not work anymore. Two examples of a Number:Angle Item and a Number:Temperature Item. In logfile the output looks like this:
My rule compared like this in the past and worked with 3.4.4:
Sonnenstand_Azimut.state < 210|°
Why do I get this Â, which is probably breaking the comparison?
Is this expected behaviour?
I also tried to reinstall OH 3 by using “clonebranch=openhab3” to then try to reperform a upgrade to OH 4. But OH 4 has been installed directly regardless of the “clonebrach” setting.
Hi Rich
Thank you for this. I had to add the userdata folder for the command to run as stated in the documentation.
Unfortunately it didn’t resolve the UoM issue. The log stated the following regarding this particular item:
[main] WARN org.openhab.core.tools.internal.Upgrader - Sonnenstand_Azimut: Could not determine if channel ‘astro:sun:Astronomische_Sonnendaten:position#azimuth’ sets a state description. Check if you need to set unit metadata.
Any other ideas?
Maybe I have to try again to install OH3.4.4 and then try to upgrade.
Well, the upgrade tool is only ever going to be able to handle most cases.And this error is really clear. You have an Item named Sonnenstand_Azimut and it’s linked to an Astro channel. For what ever reason the upgrade tool can’t figure out what unit should be applied, if any. So go set the unit metadata yourself. Azimuth is an angle if I’m not mistaken.
Yes its an angle. But unfortunately the unit metadata does not help. This is the case for different items from different devices and bindings.
If there isn’t another obvious reason for this behaviour, I will try again to setup OH 3.4 and perform a regular upgrade.
There really is no reason to expect that to change anything. And it’s just a warning from the upgrade tool. It doesn’t mean that the Item itself is broken or misconfigured. It’s just telling you that it was unable to create unit metadata for that Item for you as part of the upgrade process so you’ll need to do it yourself.
I understand, but what should I do when the state of the item still contains this  like temperatur 23.5 °C, even if I set the unit °C.
A lot of my rules are impacted by this.
That’s something different that needs further investigation.
By setting the unit metadata we eliminate a whole host of things that could be causing this to occur.
 is not one of the documented units. I’m not certain it’s a unit at all. The closest I can find is Å which is an Angstrom which is a unit of length. It doesn’t make sense to combine a length with angle nor temperature. So I’m not certain that this is a unit problem at all. But by setting the unit properly we can see evidence one way or the other, or it might even clean up the problem.
Once we can eliminate the problem being on the Item’s config side, that narrows the problem down to the Link (Profiles?) and the Binding.
Once the Items all have proper unit metadata and have been updated at least once, from a rule log out the unit.
(Sonnenstand_Azimut.state as QuantityType<?>).getUnit().toString()
I will try.
Right now I tried to reinstall OH 3.4 without success, 4.0.1 is installed. However I want to see what happens if I only restore OH Config and not Influxdb. As stated in the description I was unable to restore influx database. Maybe something breaks the DB as it is not accessible for openhab anymore after restore, but I can see data directly in influx. A rebbot brings it back online but without the restored data.
it’s not being converted to the unit defined by the unit metadata\
no one else has reported anything like this so there has to be something unique about your setup
Make sure you do not have any Profiles defined on the links between the Items and the Channels. That will definitely address that as a source of character.
Try linking it to a String Item.
Or create a simple JS transform that just logs the data passed to it and returns. That will definitively show that the character is coming from the binding or not.
(function(data) {
console.info('Raw value from channel = "' + data + '"');
return data;
})(input)
If it’s coming from the binding, try recreating the Thing and relinking the Items. If that doesn’t work, file an issue with the binding.
@rlkoshak Thank you, i will check as soon as possible.
@alchemist I think this is also a possible option. Is there a way to check/change the encoding?
But I have only UI configured items. Is this relevant in this case?
I already reviewed the profiles and there is only the “standard” profile linked.
I also reset the locale in openhabian config to en_US UTF-8, without any luck.
If I change the Item to just a “Number” or “String” Item, only the number will be displayed, without the  and the quantity type. As soon as i choose “Number:Temperatur” °C is displayed.
The output of the transformation is:
Raw value from channel = “20.8 °C”
This is also the case if the item is only a “Number” item.
Thus it seems to come from the Thing/Binding. I will try reinstall the binding and/or recreate the thing and report back.
EDIT
I recreated the thing and reinstalled the binding (Astro Binding). Unfortunately it is still the same.
Somebody else using this binding? @rlkoshak In this case should I file an issue?
That’s weird. If the Channel is delivering units I would have expected it to deliver it to a String Item too.
Can you show the Link config. It will show what type of Item it expects to be linked to. If it expects to be linked to a Number:Temperature (for example) I would have expected the String Item to get the units too, not just the number.
OK, more weirdness. So it looks like it is in fact removing then units from the String Item. The transformation is showing exactly what’s coming from the binding.
So, it’s taken awhile but we at least now know where it’s coming from. If reinstalling the binding or the Thing doesn’t work, file an issue.
Somehow I can’t believe that it is binding related, because I have several different Bindings/Things how face the same issue (Openweathermap, Astro, Stiebel Eltron (Heat Pump).
I still fear it is related to the config restore of the older OH 3.4.4 Version. But for some reason, I’m unable to install OH 3.x, even by setting the clonebranch=openhab3.
