[OH 2.4.0 M7] Testing Results

The issue with the charts is that it defaults to mapdb for some reason, even though it doesn’t make sense at all as the mapdb doesn’t store historical values. This solution was provided by someone in the github issue.

Then please explain why this wasn’t an issue until now, it was working since I started with version 2, it never used mapdb for that.

No one with any suggestions to the above problem??

If the binding expects this, I would consider it a bug in the binding. The channelLinked() method is only meant for dynamic updates during runtime. It is absolutely ok that it is never called for channels, which are already linked at startup while the handler isn’t yet initialised.

Ok, then I have misunderstand the channelLinked method use.

Kai fixed it: https://github.com/eclipse/smarthome/pull/6638 ! :+1:

PR was merged 4 hours ago
We wait now for the new OH 2.4.0 Snapshot that will include the new ESH build
Maybe another Milestone #8 before 2.4.0 Stable also? :slight_smile:

1 Like

There’s quite a lot that got fixed, not putting out another Milestone is kinda risky. Also I still consider the changed behaviour of the chart an issue, mapdb has been my default forever and now it’s starting to cause issues and it’s documented absolutely nowhere that this might break during an upgrade (so maybe someone should start writing documentation instead of complaining that people don’t read documentation, pun intended).

If you’re telling people to read the documentation you should make sure the documentation people should read is there.

As long as you make sure in future that the documentation exists before you tell people to read it I’m fine with that. It’s a jerk move to say people haven’t read the documentation when there is no documentation at all about that particular topic.

So in conclusion: There should be at least some kind of note that the chart now respects the default persistence service (even if it doesn’t make sense at all), otherwise this probably won’t be the last message about this issue (and pointing to the documentation is not an appropriate reaction because it’s not documented anywhere).

I´ve updated to M7 a few days ago and found a weird behaviour in the webviews…

.
*.sitemap

...
    Frame label="Test 123..." {
        Webview url="http://www.openhab.org" height=5
    }
...

Chrome told me, the webview is looking for a missing svg icon:

Am I doing something wrong? Or is this already a known bug, that I´ve missed in my forum search?

I have seen this before: the webview.svg does not exist anymore in the classic icon set

Ref:

  1. https://github.com/eclipse/smarthome/tree/master/extensions/ui/iconset/org.eclipse.smarthome.ui.iconset.classic/icons
  2. https://github.com/eclipse/smarthome/pull/6046

Maybe open up an issue on: https://github.com/eclipse/smarthome/issues

The 404 is due to this: src="../icon/webview?format=svg"

here is a trick to make it work:

wget "https://raw.githubusercontent.com/elementary/icons/master/status/128/dialog-information.svg" -O /etc/openhab2/icons/classic/webview.svg
1 Like

I´ll do so - thanks for your answer and the links! I could define a placeholder icon in the sitemap as a workaround.

But I understand it correctly that there should be neither an icon nor a label if I don´t define one in my sitemap, correct?

I think that if you don’t specify an icon, it will (try to) load the webview.svg

You can specify your own icon of course:

Webview url="http://www.openhab.org" height=5 icon="light"

but I don’t know how you can avoid completely the icon :slight_smile: (maybe use: icon="none"… it will still take up space since it will actually load a blank icon)

btw: I don’t think that this issue is specific to M7. It has been like this (missing webview.svg) for a while now… just no-one opened an issue since its too minor :slight_smile:

Hmm, good to know. This seems like a new “feature” to me - I think I never had an icon on my webviews before. But I´m old - so you never know… (and after looking on the date of the merged request… I´m more or less right) :smiley:

“none” or a fake transparent png did the trick for hiding the browsers default error icon - but the space for the icon and label inside the webview is still used.

Honestly, I have to say that I would like it more without the need for an icon/label.

1 Like

Open an issue and ask the ESH team to modify/revert this PR: https://github.com/eclipse/smarthome/pull/6046 (and to add the webview icons)

I think that this one added (recently: Aug/18) an icon to the webview :slight_smile:

1 Like

Issue links, for everyone who´s interested in:
https://github.com/eclipse/smarthome/issues/6639 - Missing webview *.svg
https://github.com/eclipse/smarthome/issues/6640 - Possibility to remove icon / label from webview completely

Thanks for your help again @Dim

1 Like

Actually it is in the docs. From the docs on the Chart element:

service sets the persistence service to use. If no service is specified, openHAB will use the first queryable persistence service it finds.

I interpret that to mean that you can’t know a priori what persistence service will be selected. But MapDB and RRD4J are both queriable so I suspect it was just a fluke that that it worked before and that it isn’t now. For what ever reason, it’s finding MapDB first after the upgrade. But the docs indicate that if you have more than one queriable Persistence, it is indeterminate which one gets select for building charts if you don’t specify the service.

There is nothing broken here and I doubt the behavior had changed in this release. You’ve just been lucky to this point that it found the persistence you actually wanted to have it use.

So is it “the first queryable persistence service it finds” or “the one that’s specified as the default”?

Seems like @Dim needs to read the documentation then aswell before asking others to do so, because

the reason is: your default persistence that you set in PaperUI

is not the reason according to the docs. So before pointing fingers you should do yourself what you ask others to do!

Anyways: By reading the docs, this is definitely not clear! Also as far as I can see the changelogs don’t indicate that anything in that area was changed, so doing what a person who actually reads the docs (like me) does, which is reading the changelogs, doesn’t help.

If the docs aren’t making sense, or you feel are lacking in any information, then you are more than welcome to add this information yourself. I learnt how to and it’s pretty easy. It would be helpful for others if you do so as I suspect you probably aren’t first, nor will you be the last, to encounter such a situation as you find yourself in.

1 Like

The point in adding things to the docs is, you don’t want to add false information. I posted in this thread and asked others to check if they encounter the same behaviour, somehow someone read “HELP ME I DO NOT READ DOCS I WANT HELP WHAT DO I DO NOW?” in my message and then made an inappropriate comment about that.

If this is how people are supposed to be treated in the Forum if they are asking if others are having the same behaviour, I will no longer ask questions in here and just go ahead and change the docs (others should do that aswell). The result will be docs that are based on how people think stuff works or how it works on some devices but not docs that actually describe how it’s supposed to work and how it’s intended to be used. You might notice what’s wrong with that…