I’ve not tested it recently, but it’s still in the docs and the wifi code still seems to be there. That issue disabled the wifi menu option in openhabian-config (as I understand it) but doesn’'t necessarily remove the initial configuration of wifi from the first boot.
I might be going through an openHABian install here in the next day or so. I can report back.
Other readers of this thread may not know it though.
I wouldn’t argue against that. But as you are aware, fixing OH startup is way harder (possible at all?). So do we just wait and hope that someday it gets fixed, or fix it in a way we can?
But the problem isn’t necessarily Item activity that causes data to be persisted. If you have a periodic strategy applied, like is required for rrd4j, it can run the “everyMinute” persistence activity even before the Items have started updating. And that will create all the tables for all the Items.
But it’s all philosophical. Removing the persistence add-ons default strategies is how the problem was solved.
Yes, but persistence comes up very early. Way before Things do and the rule engine starts. But if OH happens to be starting on the first second of the minute, and it has an everyMinute strategy, a new file/database table will be created for all your Items that don’t have one already. There probably won’t be anything in it because the Items haven’t started changing, and the Items will still be NULL, but the files/tables for the Items will be there.
Let me try to be more precise: I’m not claiming that any of this is broken or missing, I have just made a “mental note to myself” that this must be looked into before upgrading, which has prevented me from doing so - not because it’s out of my reach to do, but because I haven’t prioritized digging into the details.
When it comes to Frontail, I was never able to conclude what the final status was in the thread where it was discussed. My “plan” has vaguely been to try to improve the MainUI log viewer to the point where I feel that it can fully replace Frontail. I’ve done some things, like dealt with the constant disconnects that made it stop following the log, but the fundamental blocker (for me) is that it doesn’t allow viewing of historical data. I’m not sure how to handle this, since that can be a lot of data, and ideally, it would have to get the information from the log file itself - to avoid “double storage” of large amounts of data.
Everyone was waiting for me to find an alternative. I found a few candidates to test, but then a log viewer was added to MainUI itself. At that point I figured the issue was moot.
It’s been improved significantly since it was first released and further improvements would be most welcome. Just based on what I see posted to the forum I know a lot of people are using it.
I remember seeing a PR or at least an issue looking into ways to do that. I can’t find it so maybe it was just a discussion on another issue or PR.
Thank you, problem solved by installing libttspico-utils.
Why did this happen? I did a clean install of OH 5.1 and then imported my OH 4.3.5 backup file. This also pulled in the necessary bindings automatically - but the manual interference necessary for picoTTS wasn’t brought to my attention.
I haven’t seen the PR, but I’ve studied the problem itself. I don’t quite know how to get around it. Frontail, as far as I know, doesn’t really reformat the content, it just colors and filters what’s there. So, it can easily work with the log file.
The MainUI log viewer doesn’t work this way. It’s registered (via websockets) as a “log appender”, that is a receiver of logging events, just like any other part of the logging system, like a “file appender” that writes data to a file. So, the data received here is without formatting, there are no patterns or other rules for what should and shouldn’t be displayed applied, it’s just the raw data. This lets the MainUI log viewer format the raw data as it pleases.
That’s nice and all, but this isn’t the form of the data in the log file. They are formatted and filtered according to the logging configuration. It’s frankly impossible to “revert” this process and turn them back into “raw data form”. And even if it were to be attempted on a “good enough” basis, it would be a huge undertaking, which would probably fail more than it succeeded. This is why I’m stuck - I’d really need for the data to be kept in their original form for them to “fit” into the MainUI log viewer as it exists - and that means “double storage” of the data. This happens to a small extent already in the OSGi framework, but it only caches the last 100 entries, which is “nothing”. The MainUI log viewer can retrieve these last 100 entries, but it’s essentially pointless. It will give you a few seconds or perhaps a couple of minutes of history only. Certainly not enough to go back to where something failed when you discover it after the fact.
The only other option I can see is to make the MainUI log viewer have “dual mode” - the current functionality for “live” logs, and then something entirely different, that basically shows the content of the log file like Frontail does - with whatever formatting and filtering that applied when the log file was generated. This could be done, but you wouldn’t actually use any of the existing log viewer then, but you would have to make it “look as similar as possible” to the current one to make it more “friendly”. Many things that are possible in the current viewer wouldn’t be possible, and the “table format” would be a no-go. The same with pulling up the details for one entry.
This is where I’m “stuck”, I’m not very tempted to go down the route of “duplicating” as much functionality as possible while making it fundamentally do something different, and “double storing” data for long enough to make it useful feels like a huge waste. It could of course be configurable, but still.
A healthy portion of the 329 messages preceding tthis one relate to the change in persistence defaults. As someone who has had a .persist file since version 1.something, and noticed at some point that things were being persisted that were not in my persistence group (with version 3.?), I stopped adding items to the persistence group - it seems I now have to review the possibly 1-200 items added since then to evaluate whether they should be persisted, or perhaps, add or move a line in my .persist file, which is very simple – one policy for members of one group – but after reading those 329 posts, I’m not sure what to do, but I also think I want to move from the .persist to UI managed persistence while I’m still on 4.3.8.
Pehaps a new thread with moderated posts could summarize in some definitive way what the impact is and the remediation options are, or release notes updated with more detail? There are benefits to threads like this being an extended conversation (and I love the passion and knowledge displayed by those participating), but IMO they have little reference value if you try to pull information from them after they’ve been going on for while.
I’m guesing I’ll end up writing a script that iterates all of the items to generate a list of those not in my persistence group – any more obvious way to do this?
A log error was provided but this error does not help because there is no message displayed, instead you get an object reference, if this is something changed, it was a bad idea.
Offloading persistence related questions off this thread for sure is a good idea.
I’ve created Persistence changes in 5.1, please move all persistence related questions and discussions over there. Thank you.
Please bare with us moderators that we don’t have the time and capacity to moderate contents of discussions. But we will be contributing our knowledge as longtime users, too.
Thank you for your thougts about persistence. I will ignore the warning or adjust my config file.
I have other issues in MainUI with “List Cards”. I wonder if someone else face them?
They appear also on a different browsers, cleaned (OH / Browser) caches and also on OH 5.1.1
I’m not able to add List Items to a new List Card.
If I klick on the “+” Icon of the new List Card, the options appear but an error is shown: ”Action ‘undefined’ not performed while in edit mode”. This is unexpected in my opinion.
If I click on a List Item to add it, the menu disapear as expected, but no Item is added.
Sometimes I’m not able to click the “Edit YAML“ for existing List Cards
Text Color Settings (Style) are not applied to the Item Value anymore, only to title.
Existing List-Card Items are not displayed one below the other anymore in edit mode. In “Run Mode” the arrangement is correct, but colors still only on titles not on item values.
I don’t think that’s a good idea for the same reason it’s not a good idea to have a red warning light lit right next to your oil lamp. When another warning appears, one that you should react to, you probably won’t. So, if just “accepting” them should be the solution, there must be some way to mute selected.
These are two bugs that actually aren’t linked to each other. The error can be ignored.
You can work around the bug that no children can be added by manually addding slots: {} to the empty list item in the code tab.
I will provide fixes for those bugs.
I’ve tried restoring the old behaviour, but that’s not easily possible without introducing other issues. I’d suggest to simply add --f7-list-item-after-text-color: yellow to the style of the oh-*_item.
since 5.1 the rangeColor parameter of the oh-knob component doesn’t work anymore. Below you find an example YAML-Code for a basic Knob-Widget and a screenshot of the result:
uid: widget_cea0032661
props:
parameterGroups: []
parameters:
- name: prop1
label: Prop 1
type: TEXT
description: A text prop
- name: item
label: Item
type: TEXT
context: item
description: An item to control
tags: []
component: oh-knob
config:
borderWidth: 0
endAngle: 270
handleShape: round
handleSize: 30
item: raumklima_diele_Set_Point_Temperature
lineCap: round
max: 30
min: 5
pathColor: green
rangeColor: yellow
readOnly: false
releaseOnly: true
showTooltip: true
size: 170
startAngle: 45
step: 0.5
strokeWidth: 9
tooltipColor: black
