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.
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:
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?
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>
Thanks for testing it on your machine! I can confirm that your test.html works on my openhab 3.4.0 final installation as well - so I suspect that my client must be doing something different (and postman as well) that does not work with 3.4.0. I will look for differences in the requests your script and my Java client make. Thanks again for your efforts, ccutrer!
Ok - I found the problem - and apologies, it was not the subscription process, but rather my client code that did not properly cope with the payload.
It seems that there is a new event coming in (did not see it before Openhab 3.4.0):
{"type":"ALIVE","interval":10}
that my client code was not able to digest properly. Thanks for all your help.
does OpenHab 3.4 convert the the numbers it receives froim the binding (Homematic) before writing them to the persistant storage (InfluxDB2)? E.g. from Wh to kWh?
OpenHAB (3.3) did write Wh to the persistant storage before the update to.
Now OpenHAB 3.4 seems to write kWh to the persistant storage instead of Wh.
The server in the plot uses on average 140 W which should yield around 3 kWh in 24 hours and not around 3 Wh. If I change the unit in Grafana to kWh, the number is correct.
If this is the case, how can I revert this behaviour to store Wh again instead of kWh?
Plot over 24 hours before the update (using Wh as unit)
Correct overall usage of ~2.8 kWh
Plot over 30 days using Wh as unit.
The slope after the 2022-12-20 is basically flat as the units are now stored in kWh instead of Wh
Last value before the update: 45.6292 kWh
Last at the point of writing this: 45.6693 kWh
I am not a big fan of using third party services. Once they are down or disappeared, a post might be worth nothing and not might help others to resolve the issues without the images which are lost for good.
I just went through the release notes and found this under “Breaking Changes that Require Manual Interaction after the Upgrade”:
Core Runtime
Default units have been added for all dimensions. A state description defining the unit should be added to each item that uses a different unit.
I think this is what you are referring to, right?
I must admit, that I am lost at that point as I wasn’t able to find a place in the OpenHAB UI to define those descriptions
Could you give me a pointer to the page where I can define this?
I use three types of EnOcean devices. Lights, dimmers and rollershutters. With openHAB 3.3 everything worked as desired.
But after the update to openHAB 3.4 the dimmers and rollershutters are only shown as switches.
Previously, I had a slider for the dimmer. Now a switch is displayed, which of course does not work.
At the rollershutter I had the up/stop/down buttons. Now a switch is displayed, which of course does not work either.
Only the lights (switches) still work.
Does anyone have any ideas?
The unit of measurement handling in OpenHab always confused me.
Does the StateDescription.Pattern (“for display purposes”) property effect how a value is stored in persistence?
I would asssume that this pattern is applied to all values retrieved from persistence.
