Thanks to all for the release I just want to refer to one issue which is still there in oh5.1
If you want to analyze an item you still get the wrong value to the Cursor
See also here
In my opinion this is not a bug. In your screenshot the latest valid data for this item was yesterday 16:34 and it was 3.139. And this is what the label shows:
What would you expect when moving over chart with no data? Zero? Or not showing a label? Zero would be wrong in my opinion.
The question is why there is no data for today? Did you already share your item and persistence configuration in this community? I did not check older comments/feedback.
1 Like
I agree here and do not see this as a bug as well.
but in this screenshot. The mobile and desktop webpage is not in common. Here is no âpointâ diplayed because itâs out of range
1 Like
It is not about the point. The label shows the latest valid data for this item and this was 22. Dec 2025 17:39 with value 3.139.
You are moving mouse over a chart that has no values/data. Again, what would you expect? If you have no persistence for this item (e.g. rrd4j every minute), then I would expect exactly what I see in your screenshot.
I expected the data on the Cursor and if no data is there nothingâŠlike in any other tool excel, grafana, home assistantâŠ
Ot at least a sentence like last valid data onâŠor the tooltip label in the far left side to show that itâs last valid data
here you see the cursor and the tool tip label is not synchronized. and you get two different dates so now itâs unclear which date is true and your data was valid
something like this (this is how grafana,excel, home assistant, ⊠is doing it) 3 possible options or you can do a mix out of it
otherwise if you dont read all you get confusedâŠ
quick and dirty via js paint on my mobile sorry for no better graphical versionâŠ
1 Like
You can create a feature request on GitHub, and the developers can decide whether or not to implement it in a future version. Itâs a matter of opinion. For me it is not a bug.
2 Likes
Common on 23.12 and 24.12 on the same cursor position should be not possible 
may be because itâs Christmas 
Happy X-Mas
Edit: makes more sense to go back to this version @michaeljoos
Itâs an old screenshotâŠso dates not valid anymore
1 Like
why is everyone doing it âcorrectlyâ??
example:
again it make no sense to have two different date on one point
it make sense here
to snapping it to last data point itâs okay but not perfectly (interpolation would be nice to see but this is a feature I agree on this) but not in the future because the point is not even displayed
why it make no sense:
if you have a quick look on your wall mounted tablet you think there is a value and everything is fine but than you see oh no itâs not
@florian-h05 @michaeljoos let me ask it differentlyâŠwhat is the benefit of doing it the openhab way compared to all different software packages?
1 Like
Here is chat gpts answer:
The maintainers classify it as as feature and not a bug is this correct?
Short answer: they can classify it as a feature, but itâs debatable â and many users would reasonably still call it a bug.
Hereâs the balanced breakdown.
Why maintainers might say âfeatureâ
From a maintainer / library-behavior perspective:
Vue3 framework allows continuous cursor tracking across the X-axis.
The tooltip shows closest stored datapoint.
This behavior is intentional, not a malfunction or regression.
openHAB is not crashing, miscomputing stored data, or losing history.
Under a strict definition:
A bug is something that behaves differently than designed.
If the design is âshow cursor position time,â then technically itâs working as designed â feature.
Why users reasonably call it a bug
From a user and UX correctness perspective:
The UI looks like itâs showing real historical data.
The tooltip does not indicate interpolation or missing data.
Dates shown in the future are especially misleading.
There is no option to disable or constrain this behavior.
That makes it a data integrity / UX bug, even if technically implemented correctly.
Many projects treat this kind of issue as:
bug â when misleading
or enhancement â when changing behavior
Maintainers often choose âfeatureâ to avoid implying data corruption or broken logic.
Is the maintainer classification âcorrectâ?
Technically defensible, but incomplete.
A more precise classification would be:
Type: Enhancement / UX improvement
Problem: Misleading tooltip behavior when no datapoint exists
Impact: Confusing interpretation of historical data
Calling it a âfeatureâ without acknowledging the UX issue can feel dismissive â but itâs not wrong in a narrow technical sense.
How to productively push back (if you want)
Instead of arguing âbug vs feature,â the most effective framing is:
âRegardless of classification, the current behavior is misleading and needs clarification or constraints.â
Good acceptance criteria to propose:
Snap tooltip to nearest real datapoint
Hide tooltip when no datapoint exists
Show explicit label: âInterpolated / no dataâ
Prevent future timestamps beyond last datapoint
Maintainers are much more likely to act on clear UX acceptance criteria than on taxonomy debates.
Bottom line
Maintainers are not wrong to call it a feature
The real issue is missing UX signaling, not broken code
Iâve split this to a new discussion as this is no new behaviour of openHAB 5.1.0 and its therefore off-topic for the release discussion.
1 Like
If you do the same with a switch item it works as expected see screenshot @florian-h05 @michaeljoos is this a feature now or a easter egg?
Iâll give you two options:
- Stop being that passive aggressive with pinging people, calling actual bugs (for example Unable to link item to thing · Issue #3688 · openhab/openhab-webui · GitHub) features.
- Iâll flag you and make sure a moderator steps in.
I have better things to do than to discuss with people who canât accept that other people may have a different opinion.
1 Like
So are you saying that you yourself do not have moderator privileges on this website? Did you not recently use moderator privileges but without revealing yourself as having done so, after another moderator had properly engaged on the same issue you then engaged in?
If you donât want to engage in the discussion, then donât.
Did you not recently endorse the notion that politely phrased differences were deemed insults worthy of abusive responses? I ask because it looked that way to me.
The standard that differences of opinionâeven strong differencesâdeserve harsh threats of silencing is very harmful to constructive discourse. I ask you to reflect and instead encourage participants to speak freely about matters that concern them, regardless of whether you yourself want to engage with those different opinions. Otherwise, participants and users may feel robbed of their good faith investments in trying to help make openHAB better over time.
I have but I donât want to moderate things I am involved in.
What do you refer to?
Did you read the above thread and the linked issue? I have nothing against discussion but pinging people like above and provokely commenting in random bug reports if that wasnât a feature or a easter egg is no part of discussion IMO.
Iâm sure your question to me is asked in entirely good faith, so Iâll leave it there.
Users should feel entirely comfortable at expressing horror, if they feel it, in decisions they believe are very bad. In a climate of scolding and threats, users are less likely to feel they are being dealt with fairly and will understandably give an undertone of hostility.
I think itâs wrong to foster this hostility towards participants from the âcoder class,â for all the harm it does to the potential of constructive dialogue. I see threats of silencing disagreement, even when not expressed in a way you personally like, is part of why dialogue is poor.
I ask again that you and your cohort reflects on this point. Thank you.
According to the moderation log all I did in the last 30 days was:
- Close SNAPSHOT and release discussion topics for old openHAB versions.
- Process report of the automatic spam detection system and delete posts such as
Hubungi Call Center INDODAX dapat diakses melalui nomor O811_3777_29 Whatsap atau email support@indodax.com.
Calling a group of people a âcohortâ could be seen as another insult.
Just pointing it out.
Itâs either meant as an insult or it isnât. (Of course it isnât.) Saying theoretically it could be seen as one (by whom?) is a great example of intimidatory language. And as you say âanother insult,â do you care to list my previous insults to which this might be another?
Please, again, I urge you to reflect on your choices in your interactions. The hostility is misplaced and harmful. Thank you.
Itâs generally agreed upon among the moderators (though I donât think weâve ever formally discussed it) to not take moderator actions on threads we are involved with. It wouldnât be fair to the rest of the users of the forum if moderators took actions on threads they are engaged with.
Part of the problem here is @milo has engaged in a sustained campaign on this thread, the 5.1 release thread and on github on this issue. Their opinion has been expressed, understood, and the maintainers disagree. Yet the postings persist and the tone has become more negative.
At some point this behavior transitions from expressing an opinion to harassment. Especially when many of the posts are somewhere between passive-aggressive to outright hostile.
But note that no moderator has taken any actions any of these posts.
1 Like
IMHO, if there is no colour/line/ point, there should be no value in the tooltip.
If the old/same value is still valid, a graphical representation is mandatory, i.e. a line or point or some other graph component.
1 Like