[OH 2.4.0 M7] Testing Results

[Simson]

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?

[Dim (Angelos)]

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

[Simson]

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?

[Dim (Angelos)]

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 (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

[Simson]

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)

“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.

[Dim (Angelos)]

@Simson

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

Open an issue and ask the ESH team to modify/revert this PR: [Basic UI] Show label and icon for Webview widgets by cweitkamp · Pull Request #6046 · eclipse-archived/smarthome · GitHub (and to add the webview icons)

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

[Simson]

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

[rlkoshak (Rich Koshak)]

@Flole

As long as you make sure in future that the documentation exists before you tell people to read it I’m fine with that.

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.

[Flole]

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.

[pahansen (Paul Hansen)]

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.

[Flole]

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…

[rlkoshak (Rich Koshak)]

@Flole

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

So you can continue to harp on this issue and feel injured because Dim made a mistake or you can let this drop.

Honestly, the expected behavior is that the Chart element would use the default persistence instead of whatever one it happens to find first. But even back as far as OH 1.8 the docs for the chart element has said the same thing as I quoted above. It has always worked this way and it continues to work this way.

The behavior of the chart element has not changed and by all evidence presented so far it is behaving as it always had. There is no bug. There is no regression. There might be a need to clarify that if you have more than one persistence DBs in use and you don’t specify the service in the Chart element the one chosen is somewhat random (see Paul’s post).

So you can accept the answer to your original problem, or you can continue to be aggrieved try to pick a fight with one of the top contributors of the forum for making a mistake.

[Kai (Kai Kreuzer)]

@Dim

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

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?

Just running a new ESH stable right now, so the next snapshot will include it - M8 planned for this weekend then.

[puzzle-star (Pedro Garcia)]

@Kai

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.

Hi @Kai,

Then, may I be misunderstanding this, from ESH documentation?

The channelLinked method is called, even if the link existed before the handler was initialized. It will be called only after the initialized method has been executed successfully and the handler was registered as OSGi service. To check if a channel is linked at the time when channelLinked or channelUnlinked is called, you can use the isLinked(String channelID) method from the BaseThingHandler class

[Dim (Angelos)]

M7 Thread still open for testing results !

In anticipation of M8:

Summary here:

[OH2.4.0.M#] Milestone Testing Summary

[WIP] Summarizing the identified issues from both Milestone Testing threads: M6 & M7: If you have identified some extra stuff that I missed (from the forum or github), please reply here with a link to the relevant forum post. They need to be: (i) bugs (not config mistakes due to vague docs) & (ii) reproduce-able. I haven’t listed the ones that were already fixed (e.g. PR#6638 & PR#4324, PR#6583 and many others) My (personal) conclusions: No (red hot) blocking issues that are going to be c…

[Kai (Kai Kreuzer)]

@puzzle-star

Then, may I be misunderstanding this, from ESH documentation?

Hm, valid remark. I guess this is outdated though as the JavaDoc says something different:

This method is only called, if the thing has been initialized (status ONLINE/OFFLINE/UNKNOWN).

I have updated the documentation accordingly.

[Dim (Angelos)]

edit

[Kai (Kai Kreuzer)]

@Dim & @Flole Please let us calm down and return to discussing testing results and find critical regressions of M7 - thanks!

[marcel_verpaalen (Marcel)]

Scanned this topic, did not spot this issue

I have many errors like this

23:34:42.528 [ERROR] [ge.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent. 23:34:42.534 [ERROR] [ge.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent.

seems the commands send by the OH android app are not getting processed.
any suggestions?