[OH 2.4.0 M7] Testing Results

Setup, Configuration and Use Runtime
, ,
70

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?

71

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:

72

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
73

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 :slight_smile:

1 Like
74

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
75

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.

76

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.

77

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
78

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…

79

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.

81

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

1 Like
82

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

83

M7 Thread still open for testing results !

In anticipation of M8:

Summary here:

84

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.

86

edit

92

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

3 Likes
93

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?

94

Don’t know why, but I can’t upgrade to 2.4.0 M7

sudo apt-get install openhab2=2.4.0~M7-1

gets me:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '2.4.0~M7-1' for 'openhab2' was not found

Ok, got it :slight_smile:

Forgot to add the openHAB 2 Beta Repository to sources list

95

I’ve created an issue for this: