5.2 enabled ESLint to check JS code … now such issues are highlighted, but that’s only a change in appearance.
The code works same as before (or I’d rather expect it not to work due to incorrect variable declarations. let declares a block scope variable, and you’ve declared it inside a different block then used it.)
The Items page always shows the actual state of the of Item. When you click through to the Item it shows the “state description” formatted state.
This Item lacks a unit metadata and therefore is defaulting to ONE as the unit (a simple ratio). Your state description pattern is something like %.0f %% meaning show the state with no decimal places using unit %.
0.7 ONE == 70 %
Note, the ONE unit is not shown.
If you add unit metadata to set the unit of the Item to % it will show 70 % in both places. However, it might mess up your persistence because instead of .7 it will store 70 and changing the unit metadata does not change the previously saved values in persistence (this is why there is a warning when you try to set the unit on a Item in MainUI.
It has been this way since the UoM overhaul in OH 4.x (I can’t remember exactly which version, maybe 4.0?)
Working as designed.
Not for OH 2 or 3. There was a major overhaul of UoM sometime in the OH 4 series. Previously UoM was a mess:
- A normal Number Item could suddenly carry a QuantityType instead of a DecimalType. The same for a Number:X, which could suddenly carry a DecimalType instead of a QuantityType. All it took was posting an update of the wrong type to the Item.
- The unit of the Item was determined by the state description pattern. Only it only half worked and lots of cases were not handled well.
This made knowing the unit of the Item non-determinisitic. Sometimes it would be this, sometimes it would be that.
After the overhaul now there are a strict set of rules for how units are applied.
I think it was a deliberate design choice so there is at least one place to see exactly what state the Item is carrying unaltered by state description formatting.
It was always incorrect though. If this worked before, perhaps they were defined as var instead of let?
So you have a place where you can see the actual state of the Item unaltered by transformations and state description patterns.
I want to thank everybody for the hard work, have done the upgrade couple of days ago. OH5.2.0 came up properly after the upgrade and seemed to work directly flawless.
We discovered one bug in mcp integration, I opened an issue at github what got solved already for OH5.2.1, if I read that correctly:
But there is another annoying thing, something with Shelly Binding got screwed up. Some Shelly devices (Shelly PlusPlug Gen2, PlusEM Gen3, EM Mini Gen4) are loosing or not showing the telemetric / messurements channels with OH5.2.0 every day. I assume after the nightly backup window, when OH get stopped and restarted.
PlusPlug Gen2 & Plus EM Gen3 I can reboot and enable / disable the corrosponding thing to make them work again, not what I want to do. The EM Mini Gen4, is not showing telemetric / messurement channels at all with OH5.2.0.
Frankly spoken this is more then annoying, this is real regression, as it completly screws my energy messurements as also some of my rules. Therefore I have no choice to role back to the last OH5.1.x version available, as everything(!) was working flawless with that. I have no time to deal with beta versions or to sit there every day and proof every of my things & items working …
Thanks I forgot the meta data on these channels now it’s working
Yes I think I did have them declared as var but I changed then to let.
That’s actually the main difference between var and let. var defines a variable globally so no matter where it’s defined it exists everywhere. let limits the existence of the variable to the current context in the code. So if you define a variable with let inside an if statement, it only exists inside that if statement and nowhere else. And of course you’d use const to define a variable that cannot be changed after it’s defined. I actually don’t know if const behaves like var or let but would guess it behaves like let.
It is always better to limit the scope of a variable so let and const should be used when possible over var.
To avoid this, next time please help by testing the milestones and report issues early. It’s our only way to test things on a variety of installations as we don’t have full time paid QA testers.
Thanks for the explanation. I think I read somewhere that var was going to be fazed out so I changed all my rules to let and was oblivious to the fact that if they are in a block it shouldn’t work. Oh well, live and learn. Now I can go through all my rules again and fix them.
I sounds like var is still going to be used but it is a global variable.
You don’t need to use var at all, I’d dare claim, because many other programming languages don’t have anything with those scoping rules, and are still fully functional.
But, you must think about the scope when you declare a variable. If you use let/const, it will only be valid where you define it and in “child scopes”. So, if you want a variable to be “function global”, make sure to define it at the “function level”, not inside a block. That’s all really. Just move the declaration to a location where it is valid everywhere you need to use it.
Have these problems been reported on github? See: Issues · openhab/openhab-addons · GitHub
I’m not familiar with Shelly, just providing the link.
var isn’t going away, it’s still supported by the JS language but let and const are better style and every production codebase that supports let and const will encourage you to use them.
Went over it, its a lot, but that PR merge, from yesterday, does address my issues described above:
To my understanding, OH5.2.x backport seems unclear, so next stop OH5.3.x … ?
To my understanding, OH5.2.x backport seems unclear, so next stop OH5.3.x … ?
This fix will become available on release 5.2.1, if that is your question.
I had to downgrade to 5.1.4 as my web interface wasn’t working. I could get into settings menus via the android app, but not via a computer and web browser.
At first the overview page simply wouldn’t load. Later, the webpage wouldn’t load at all.
For some reason my items connected to MQTT channels wouldn’t update their states.
Downgrading to 5.1.4 seems to have restored previous functionality. Perhaps with another 5.2 update I will also do a completely new install on the RPi.
If anybody is going to learn anything about went wrong, you must keep log files from when ran 5.2.0. It’s hard to understand that it should be necessary to do a “clean install” of 5.2.0, so there’s probably one or more concrete reasons why things failed for you. But nobody can guess what they are without any information.
A common cause for such “complete failures” is that you have older files in your addons folder. They might clash with the new versions and prevent things from starting.
I’ve looked through the logs and also gathered what info I could from the openhab-cli console. The system reached a start level of 100, no errors that I could see in the logs, and clearing the cache didn’t help. I had a solid crack at troubleshooting since 5.2 was released with no luck.
That makes it sound like everything went well. Did you try clearing the browser cache on one of the browsers?
All of them (ie multiple computers). But as I mentioned the Android app also couldn’t display the overview page, so something more was amiss.
It’s very strange if something “major” failed but nothing was logged. Did you check bundle:list in the Karaf console to see if there were bundles that didn’t start?