The main one dynamically adjusts parameters on my solar inverter based on power flow in order to prevent battery from charging rapidly on a sunny day — which allows me to have a sink for excess PV power above my power limit. If the battery fills ip before solar noon (as it typically does on sunny days), I am limited by the inverter’s AC capability. Having headroom on batter can mean an extra 1-3 hours of peak solar generation which can amount to an extra 15kWh generated in a day.
The other automation at that frequency actually can probably be deprecated with the latest release as it was parsing BLE packets from ESP receivers, but this is all mainlined with the new BTHome stuff — I just haven’t looked into what I have to do to change it yet.
That isn’t a good reason to assume it’s a browser issue. Why are you assuming it’s the browser and not a frontend issue. It clearly is a frontend problem since it only happened after the update. All other sites behaving properly.
PS. resizing window doesn’t fix for me.
It just keeps getting even better! Automations are so easy and loving the improvements. Bluetooth, love it and can’t wait to see this get even better. Updated & everything works perfectly
Does anyone know if every version of the zwavejs2mqtt Docker image past 6.16.0 runs zwavejs v10 or is there an option that runs v9.x that is compatible with this latest HA version?
it seems there’s a fairly serious bug in zwavejs v10 that causes many sensors to setup/communicate improperly with the server and it is breaking many users installs, including one sensor of mine that stopped working.
I’m looking for a way to be able to upgrade HA to the latest version but not breaking my zwavejs integration.
I ended up needing to revert to my previous zwavejs to get the sensor to work and then trying to update HA it failed to run the zwavejs integration due to the version compatibility.
So is it comms between the integration and the zwavejs server that’s the issue?
I assumed it was on the server side that wasn’t working since the issue report was filed there.
I guess another thing I don’t get is why was the server version requirement updated with a known significant flaw in the server-HA comm for this release? Couldn’t it wait till the bug got fixed before the server version update was forced?
I haven’t checked, but that’s typically how you can get around issues that are on HA’s side. If the issue is in JS, then you’d have to use 9 with all entities via MQTT with the latest HA.
Nothing is ever known until beta hits. No one is intentionally pushing through bugs unless they have no choice.
The issue was first reported “18 days ago” according to github.
that was before the general monthly release 11 days ago.
I would think that should have been enough time to roll back the zwavejs update requirement but maybe not I guess.
It just seems to be cutting it close by requiring users to update to a brand new release of zwavejs that wasn’t even released until just before the HA release requiring the update. There’s not much chance to work out the bugs like that.
I thought we usually get the forced update after a good amount of time so we can consider the zwavejs (or any other outside app) “stable”.
Probably not when the release was specifically targeting firmware updates, which required the update to zwave js.
Please don’t start another argument. It’s done. Bugs happen. If this sensor is important to you, exercise patience and wait until a fix is delivered and update from 2022.8 to whatever version it’s released in.
Beta for what? HA for next month (2022.10) or this month (2022.10)?
Sorry for asking questions in the release thread where the issue happened.
What do you think I’m doing now?
It’s not just for me. I’ve seen several other threads of users asking about and reporting the same issues and they don’t know there is an outstanding issue or why they are seeing failures.
I was responding to your ‘found 18 days ago’ when the beta of HA using the version started 19 days ago. Just pointing that out.
Lets focus on the path forward instead of “Who did it? Why did that do it? Lets punish them”.
I think you should direct your questions in the issue on node-zwave-js. I just found it and it indeed is a Zwave JS bug. So, all you have to do is wait for node-zwave-js to get the update, then both addons to get the new version of node-zwave-js. At that point, you can update to the latest HA.
If you do not want to wait, stick with the old addon and use MQTT to push your zstack to home assistant.
can I re-post this copy from a Discord post of mine (which might have been in the wrong channel), to ask for some reflection/guidance on the BT addresses in core:
Do we have any insight in the available BT addresses of our devices? I mean, whenever I activate the ble tracker, I get hundreds of devices, only listed by a bt address, so no way to identify which is which. Otoh, the devices that are included in the Integrations list on a BT tracker dont show their BT address…
Even the advised Olimex Proxy boards dont show that (also tried the diagnostics of that). Or, the new BTHome integration, it finds several devices, named and unnamed, but none of them show a BT address combined with a device name, only a RSSI sensor entity sensor.44_4c_e8_08_cf_e1_cfe1_signal_strength …
btw, notice the last 4 digits not being split-up in duplets and copied. whats does that indicate?
