That makes sense - and I understand it’s a major headache to get things working in a consistent way behind-the-scenes to what the user sees. I suppose what I’m thinking isn’t so much a change in the logic that has been decided upon - I gather that makes sense, for all that I’d got everything working very nicely prior to the change. However I’d suggest that it might make sense to interpret .items files differently so that they are more likely to behave as expected from one version to the next. My suggestion would be to handle units on items as follows:
Item displays in mm and persisted in mm. The system infers that if no unit is specified in the metadata, it should be the same as what is used for display. Thus it behaves identically to the following:
At present, my understanding of M3+ is that if the unit isn’t specified in the metadata, then it now reverts to the system default units, which I believe is only the appropriate behaviour if units are also not specified in the state description.
re-copied all the .items files that I’d previously edited to include unit metadata into the conf/items folder
started OH
… and it’s working! log:tail is showing everything it used to.
But wait …
stopped OH
started OH
… and it’s not showing any item updates in the log any more. I literally did nothing except stop OH and start it again. Behind the scenes I believe it’s still working, but the log not showing anything is not acceptable. At least now I have confirmed it’s nothing to do with the items files being changed, because I changed nothing between the first run and the second. My problem is that the first run after upgrading to M4 works, and the second and subsequent runs, the logging - while still operating for certain things, is failing to log anything relating to items updates.
I’ve had a look for that log4j2.xml file you mentioned - in my OH installation, it appears to be in userdata/etc… and it appears that Karaf itself added some entries at the end of the file, including what appeared to be a blanket nothing rule for item updates. The file I had was quite different in a number of respects to the version you gave a link to, so I replaced it with that linked file… and the log continues not to show item state changes. It’s a rather annoying bug, but at least the rest of OH seems to be running properly for now, so I’ll leave it running M4.
Further update: I’m obviously reporting on things as I test them, but I think in fact there’s something more fundamentally wrong with M4, at least as far as what it’s doing with my installation. I have a number of values in my system that are persisted, and I can see that there is a subset (which are calculated by rules rather than fed in directly from bindings) which are no longer being updated since the first stop-and-start which killed item change logging. So it is as if the system is in fact failing to recognise that items are changing at all - it persists the changed value, and when I look at the value in the sitemap it is correct, but anything triggered by a value changing fails to be triggered - including both rules and logging. That is of course a much, much bigger problem, so I think it’s time to roll everything back to the working M2 installation.
You of course are free to create a PR to request that change, but that approach was rejected during discussions. I don’t remember the specifics but I think it had to do with technical limitations and not wanting two different implementations in core. Also, ultimately what you describe is largely how it works now so your suggestion would ultimately mean “let’s leave this problem mostly unfixed for text file based users.”
The behavior is as follows.
Managed Items:
The upgrade tool finds all the managed Number:X Items and for each one creates unit metadata as follows.
Uses the unit from the State Description Pattern
If the unit is %unit% or there is no State Description Pattern, use the unit the Channel publishes
If 1 and 2 don’t exist use the system default.
The unit can be overridden at any time by the end user.
Text based Items:
The unit metadata must be added manually, either in the file or through the REST API/MainUI (metadata can be managed while Items are in text files, though I don’t recommend it).
At runtime, if the unit doesn’t exist the unit used follows this hierarchy.
The unit published in the state update.
The system default.
It mainly works differently from managed in that the upgrade tool makes sure the Items have unit metadata while for text file based users it’s up to you to make that happen.
Did you issue any other log: commands from the Karaf console? If, for example, you issued a command to change the logging level of a given logger name, that actually adds lines to that log4j2.xml files. That’s really the only way I know of that that file will change outside of manually editing the file yourself (or changing the logging level of a binding through the UI or REST API but I think we can exclude that case here).
It might help if you describe exactly how you’ve installed this and on what operating system.
You can verify that the events are occurring through the developer sidebar. You can see the raw unfiltered event stream there (and of course you can filter if as needed). That will confirm whether or not the events are happening.
But it might be time to move this to another thread to further research. No one else has reported anything like this yet so it’s going to take some research and experimentation to figure out what’s going on.
I’ve now done that, and it seems to have worked. As a once-off thing that should be future-resistant, it was somewhat annoying but now it’s done. I trust that the reasons for the logic of items files was sound, definitely not worth a PR to re-open that can of worms.
Actually I think the issue is not fundamentally a logging issue - I did try using log:set to explicitly set the log level for item state changes, but I’m pretty sure we need to look elsewhere.
I didn’t know about that - I shall fire that up and see what I can discover. And I agree - it sounds like this now belongs in its own thread. Time to upgrade to M4 again and continue testing.
All of the issues that I identified in moving from M3 to M4 have been corrected in latest SNAPSHOT build. Kudos to the development team for the ability to quickly respond, identify the root cause and implement a fix. Very Impressive!
Other than that seems ok. Will test further later on.
Have a lot of these errors now but that is probably because I changes the json file:
2023-07-08 10:21:09.105 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript;version=ECMAScript-5.1' could not be found for identifier: 107fce72-0845-4f8f-a377-61a9e72fe5a4
2023-07-08 10:21:40.528 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript;version=ECMAScript-5.1' could not be found for identifier: 2fc3dedc-efa6-484b-a046-e33dc89b0717
2023-07-08 10:21:40.650 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript;version=ECMAScript-5.1' could not be found for identifier: 107fce72-0845-4f8f-a377-61a9e72fe5a4
I also noticed another thing, which didn’t happened in 4M2 - although I’m not sure whether it is Openhab issue or something with Influxdb itself.
In any case, since M4, storing of state change state takes bit longer than it used to and in one rule I had to increase delay for correct reading of persistence from 500ms to 3500ms. I admit, I have bunch of items, some of them are stored on change but such problem did not exist in M2.
Additionally, I get following errors with RRD4J now, which sort of suggest, that items are also not persisted in order any more too. I’m using default RRD4J persistence settings
2023-07-07 10:48:00.622 [WARN ] [d4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688719680, last update=1688719681. Discarding LogViewer_ManualUpdate - 0.0
2023-07-07 10:20:00.542 [WARN ] [d4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688718000, last update=1688718001. Discarding PowerPlug_07_Power - 1792.0
2023-07-07 10:07:32.802 [WARN ] [d4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688717252, last update=1688717253. Discarding MotionSensor_09_LinkQuality - 105.0
2023-07-07 10:07:32.777 [WARN ] [d4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688717252, last update=1688717253. Discarding MotionSensor_09_LinkQuality - 98.0
2023-07-07 09:59:23.096 [WARN ] [d4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688716763, last update=1688716764. Discarding PowerPlug_09_Quality - 91.0
2023-07-07 09:37:39.472 [WARN ] [d4j.internal.RRD4jPersistenceService] - RRD4J does not support adding past value this=1688715459, last update=1688715460. Discarding PowerPlug_09_Quality - 83.0
I’m seeing @reyhard’s messages too.
I have opened Persistence warnings · Issue #3697 · openhab/openhab-core · GitHub.
Various items, nothing special about them. Maybe except that all of them are UoM items and have unit metadata set.
But I think the key is the warning only appears when they’re updated (or rather persisted as specified on every change) multiple times in a second.
Anyone else having issues with state descriptions? In the webui, I can’t select/change them, but if I navigate from the model into the item itself, it works as expected. I think this started on 4.0.0.M4.
I’m not sure what you mean here. As far as I’m aware, the only way that has ever been supported to change an Item’s state description is by navigating to the Item’s page, whether you navigate to it from the Model or from somewhere else. It’s Item metadata after all and the Item page is the only place where Item metadata can be edited.
Rich,
My apologies. I didn’t do a very good job explaining my issue. I’m not trying to change the state descriptions, but rather click on the default list item widget to issue a command to the item. The state description label list does not pop up. The item acts as if it is read only. It does properly display the correct state description label. In the item page itself, it works like normal.
So it works with the default stand alone widget which is shown in the screen shot.
Show the default list Item widget configuration since that’s the one that’s broken. Note that the list will only show up for a oh-label-item with an action of options.
Yes, I can confirm this. But was not sure if I need to change something in my configuration.
It has changed definitively from M3 to M4 and I see this behaviour e.g. for Roborock Vacuum Control and Sonos Favorites. In Item page it works, in Main UI it’s read only. But did not have time yet to check more in detaill.
In MainUI (Locations and Equipment), the same item is read only and no selection is possible.
I’m quite sure it would be possible to fix with “Default List Item Widget”. But in M3 it was not needed.
Before installing the Ambient Weather binding:
openhab> list -s -t 0 | grep -i json
17 │ Active │ 11 │ 1.0.6 │ org.apache.felix.cm.json
132 │ Active │ 80 │ 0.19.0.v20221118-0359 │ org.eclipse.lsp4j.jsonrpc
210 │ Active │ 80 │ 4.0.0.202307080306 │ org.openhab.core.storage.json
239 │ Active │ 80 │ 20180813.0.0 │ json
274 │ Active │ 75 │ 4.0.0.202307100418 │ org.openhab.transform.jsonpath
After installing the binding:
openhab> list -s -t 0 | grep -i json
17 │ Active │ 11 │ 1.0.6 │ org.apache.felix.cm.json
132 │ Active │ 80 │ 0.19.0.v20221118-0359 │ org.eclipse.lsp4j.jsonrpc
210 │ Active │ 80 │ 4.0.0.202307080306 │ org.openhab.core.storage.json
239 │ Active │ 80 │ 20180813.0.0 │ json
274 │ Active │ 75 │ 4.0.0.202307100418 │ org.openhab.transform.jsonpath
283 │ Active │ 80 │ 20230227.0.0 │ json
I tried stopping 283 but it didn’t help.
Still persisting in M4 and Snapshot 3533
I also noticed it restarts my OH cloud connection when it installs and removes. The actual log message seems to be related to that, not the Ambient Weather binding.
