Yes, it does happen without the logging as the logging comes on INFO on the “ab.event.ThingStatusInfoChangedEvent”. Only then I switch on the chromecast logs which are actually pretty silent even with trace on (probably not a lot happening when you are not using the device).
I’ll send you a PM and try it out here. I’m probably a good volume use case as I currently have 19 active things on the Chromecast binding. I’m running the Docker image so I might need a little coaching on how to deploy this addon manually.
I hope I can help even a little.
1 Like
Hi,
after upgrade from 3.3. to 3.4, my OH instance is facing two problems:
- Illegal state exceptions from rrd4j database.
- Some rules sporadically does not work anymore.
Illegal state exceptions from rrd4j database.
In my case some of group aggregate function items are affected (Group:Number:AVG) - example:
2022-12-27 18:23:06.975 [WARN ] [d4j.internal.RRD4jPersistenceService] - Failed to open rrd4j database 'gNetstatLatencyAvgUpperFloor' (java.lang.IllegalStateException)
It looks like the same problem as already mentioned here
Some rules sporadically does not work anymore.
At this moment, I do not understand the full pattern behind this error. Currently it looks like this:
- A rule does not work sporadically. As a result, the functionality is not given anymore and the log files contains entries like this:
2022-12-28 17:00:00.003 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule 'raffstore-1': null
- The affected rules have worked until upgrade without any problems.
- Currently I only see rules with that problem, which are the first rule in a rules file.
- I use a couple of rules files. Currently it is not predicable, which rule from which rules file crashes.
I think I may have found the problem with Chromecast going offline/online intermittently and I’ve submitted a PR here
A jar for openhab 3.4 can be downloaded here:
8 Likes
Thanks @JimT for fixing the problem 
I can confirm it is fixed now - no flickering of ONLINE / OFFLINE anymore.
1 Like
Same here regarding rrd4j after moving from 2.5 (
) to 3.4:
2022-12-29 22:29:02.103 [WARN ] [d4j.internal.RRD4jPersistenceService] - Failed to open rrd4j database 'Power_UG_Garagedoor_wattmeter' (java.lang.IllegalArgumentException)
However, this is only the case, when the rrd4j file in question does not exists. As soon as I copied the old rrd4j file to /srv/openhab-userdata/persistence/rrd4j/Power_UG_Garagedoor_wattmeter.rrd the WARN disappeared and the rrd4j file gets updated normally.
But my question is now: What I have to do, that the rrd4j files get initially created? This could be a bug, because before the upgrade I never made something special for the initial rrd4j creation. But RRD4j is the default persistence service since OH 3; because I came from OH 2.5, I can’t say that it is 3.4 related for sure.
(BTW: I started with a new fresh openHABian 1.7.5 image and migrated old stuff manually)
@gd35 and @BananaBender: Same situation for you?
In my case, the rrd files already exists and date of last change is same as for all rrd files in that directory. Maybe I could remove them and restart OH (afaik, this triggers the creation of new “fresh” files)
Dear users,
please allow me to remind you of the forum rules.
Only post to this thread on issues specific to 3.4 code, i.e. issues that were introduced with 3.4 and didn’t exist before (that means in 3.3, not in whatever version you have been running earlier).
Only report issues that you can reproduce and confirm to be general issues with the code and not just issues of yours that you have not analyzed to be caused by the 3.3->3.4 change or that are otherwise specific to your setup.
For anything else, please open your own thread(s).
Help us keep communication clean and effective.
Thank you.
2 Likes
I still seem to have a few small UoM related issues. Some of them I need to investigate more, but this example seems simple and straight-forward, am I missing anything obvious?
After a complete openHAB restart, the first two updates of a non-persisted item:
2022-12-30 23:09:01.780 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Omnipower_RSSI' changed from NULL to -50 W
2022-12-30 23:10:42.556 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Omnipower_RSSI' changed from -50 W to -51 dBm
Why is the unit “W” for the first update? Here is my configuration:
Thing:
Bridge mqtt:broker:mosquitto "MQTT Broker" [host="localhost", secure=false] {
Thing topic omnipower "Kamstrup Omnipower" @ "Entré" {
Channels:
Type number : rssi "RSSI" [ stateTopic="omnipower/rssi", unit="dBm" ]
}
Item:
Number:Power Omnipower_RSSI "RSSI" <qualityofservice> (Omnipower) ["Measurement", "Power"] { channel = "mqtt:topic:mosquitto:omnipower:rssi" }
I know I can configure state description on the item, but it shouldn’t be needed when I can’t have any issues with restoreOnStartup since not persisted?
The default unit for the Power dimension is Watt. If the Item truly isn’t persisted, I’m not sure why the first update from the binding is using the wrong unit.
1 Like
It’s truly not persisted. So yeah, this behavior is strange.
I tried reproducing on a clean 4.0 system with a newly created managed item (and after that an item in a file), but didn’t succeed:
openhab> openhab:status PowerItem
NULL
openhab> openhab:update PowerItem "1 dBm"
Update has been sent successfully.
openhab> openhab:status PowerItem
1 dBm
So I guess it could either be a timing issue during startup or something similar in the MQTT binding.
I also made a manual in a fresh new place and MainUI is displaying the right version.
Sorry, I have no other idea.
Most of mentioned problems have been already fixed: Chromecast status toggling between OFFLINE and ONLINE (even if not a 3.4 regression), Bose Soundtouch, color temperature channel in hue, lifx, nanoleaf and dali bindings, slider/setpoint widgets in BasicUI when %unit% is used (UoM), JDBC service failing in activation (items with invalid name).
For rrd4j, a log was improved to help understanding what is the problem with few users.
Regarding the shelly binding, it is finally not so clear if OH 3.4 broke something or not, the feedbacks are opposite.
Are there other known OH 3.4 regressions that I have not listed ?
Edit: also a stability issue with homekit probably not yet solved.
Edit2: and few users (not all) having a problem with hue becoming slow after a certain time. Not solved.
3 Likes
Thanks for everyone who contributed to the 3.4 release! Since I upgraded to 3.4.0 (from 3.3), I am no longer receiving any updates to the ItemStateChangedEvent events I subscribed to using the REST API.
I am making the following call:
http://[host:port]/rest/events?topics=openhab/items/*/statechanged
get a 200 return code and wait for changed items to come in via SSE. On 3.4 I do not get any data via SSE - on 3.3 I got JSON-Messages describing the item state changes.
I tried various variations of the topic filter as described here: Event Bus | openHAB (e.g. subscribing to specific items or other events) - but I am not receiving any events anymore (but get an HTTP 200) - regardless of the topics I subscribe to. Is anyone else seeing this?
See also RFC: Implement event topic filtering directly in EventHandler · Issue #3234 · openhab/openhab-core · GitHub. I haven’t looked into the REST API event interface, but I certainly can (and should) as part of resolving that issue.
1 Like
3.4 introduced default units for all item types (see release notes).
That effectively assigns a unit to every UoM item on first use when it does not have a unit.
That’s usually on restoring persisted items but isn’t limited to this. It’ll also happen e.g. if a binding sets a value only when the item is still NULL after a restart.
So I just tested, and it’s working fine with 3.4.0 final. I did have to make sure that the host:port I’m using matches the host:port of the web page that is connecting to the EventSource. I put a file test.html in /etc/openhab/html, and then accessed it at http://<localip>:8080/static/test.html:
<!DOCTYPE html>
<html>
<body>
<h1>Getting server updates</h1>
<div id="result"></div>
<script>
if(typeof(EventSource) !== "undefined") {
var source = new EventSource("http://<localip>:8080/rest/events?topics=openhab/items/*/statechanged");
source.onmessage = function(event) {
document.getElementById("result").innerHTML += event.data + "<br>";
};
} else {
document.getElementById("result").innerHTML = "Sorry, your browser does not support server-sent events...";
}
</script>
</body>
</html>