@Kim_Andersen have meet following tricky problem with M7 release. Problem have not seen with earlier versions.
IHC Binding doesn’t get all channelLinked “events” from OH/SmartHome core during OH full start, but if binding is restarted after OH start, the binding get all channelLinked events.
Most of the bindings are not interested by the channelLinked events, but IHC binding is.
IHC binding have couple of static channels (introduced by the thing defination)
and rest of the channels are generated on the fly (there can be hundreds of channels at the end).
It seems that only those static channels receive the channelLinked events on startup, but not others.
I can’t reproduce this problem on my development environment (Macbook pro). So this problem might be related to timing as Kim is testing this in Raspberry Pi.
@Kaihave there been recently any changes on OH/SmartHome core which could have impact to thing channelLinked events?
I run Rpi 3B+ with apt-get openhabian hasslefree.
I started off with a clean openhab 2.3 install, upgraded to #1445 and then #1447, and latest the Milestone M7.
I think the problem Pauli speak of could have been represented in #1447 and maybe even #1445. I just didnt pay enough attention due to some testing where I used the disable/enable button alot. (I can try downgrade and test if necessary??).
The IHC binding is the only extra binding installed, since my main purpose with this test setup was to test the new IHC binding only.
I can reproduce the problem even by restarting openhab, (I dont have to reboot).
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.
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.
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?
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).
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).
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
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.
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.
(maybe use: 