Global Moderators group | Smart Home

toggledbits

OK, everyone, it's almost time. Sorry for the long pause. Life takes over sometimes.

The aforementioned updates will be in the next build, and I am working on wrapping everything up to get that build out later this week.

Please make backups of your Reactor data as advised in the head post here. As I said then/there, I've been working with this for months now, with no issues, but my world is not your world or everyone else's world, so there's always the possibility I don't see or have an issue that you do.

Prior to releasing this new build in the latest channel, the 26011 build will become the stable channel head. In addition to your backups, that gives you a relatively quick path (especially docker users) to get back onto 26011 if there's a showstopper.

This build will also include unified room groups: DynamicGroupController will manage "rooms" (or areas or locations or whatever your hub calls them). If you have two different hubs with devices in the "Living Room," there will be one "Living Room" group with the combined set of devices. The per-controller room groups generated by VeraController and EzloController will be disabled by default, and existing room groups created by these controllers will be marked as dead entities (and eventually purged). If you already use DynamicGroupController to manually create your own room groups via configuration, you can either keep that (and disable DGC's new behavior, if you wish) or switch to DGC's version. An updated version of ZWaveJSController that supports this functionality will be released simultaneously with the core build.

CatmanV2

Just an update. Nothing apparent issue wise since my update yesterday

C

CatmanV2

Super, TYVM

My NAS blew a drive just after I arrived back in the country so I'll get the replacement sorted and upgrade next week

As ever, much appreciated!

C

toggledbits

OK. If it helps, I haven't had to make any compatiblity changes to HassController since HA 2026.1.0 up to 2026.4.0. They did change some service data information, but not in a way that's incompatible, rather, they improved the content of the data in a way that I have now modified both HassController and the UI to offer more guidance (suggested values) for parameters in some services. They are taking a new direction that I imagine provides better and more consistent support for themselves in Lovelace, and I'm following that path with them. So you can probably go to at least 2026.4 and, if you can tolerate Reactor warning you about it, may not have any issues, but again, I don't have every device/integration, so there's always something you may have that I don't and therefore don't see (but that's a risk whether I "bless" the HA release or not, and as you know, I try to react as quickly as possible when those things come up).

TL;DR You can probably upgrade HA to 2026.4 safely, just ignore Reactor's warnings. If there's any issue, let me know and I'll address it.

CatmanV2

Ah I probably mis-spoke. I'm not aware of a break between HA / MSR, however some of my cards and integrations can't be updated without updating to core 2026.4.1 (although that's latest) and HAOS 17.1

Does that make more sense?

I was more concerned about upgrading to an un-blessed version of HA

Cheers

C

toggledbits

Well, first, let me know in detail what the breaking change is. I'm working with 2026.4.0 at the moment and haven't had any issues, but there are so many integrations and devices supported that of course I can simply not have something you may have.

I've been running the future build for the last six weeks, and many of the bigger changes I alluded to in earlier posts even longer than that, and I'm pretty satisfied with how it's going. I'm almost ready to release, but I'm always prepared to do an interim release to provide specific relief for things like the above.

CatmanV2

Morning. Do we have a roadmap for the next release, at all? I only ask as there's a breaking HA change and I have many packages now out of date.

Cheers!

C

toggledbits

Grab ZWaveJSController build 26048. It will publish the location in zwave_device.location. It will not create groups automatically (yet), so you'll need to use DynamicGroupController to make your own.

Rooms are going to be handled very differently in future. Right now, controllers great groups they own for rooms, and that prevents sharing of rooms between controllers (they can't modify another's groups), so you have to use DGC to manually create unified groups across controllers. That will be more automated in future.

toggledbits

@Crille said in Do you Matter?:

@toggledbits any considerations of a MatterController?

Absolutely. No idea on timing though, yet. Right now, I'm tied on an ESP-IDF project.

toggledbits

Ahhh... I see what you're getting at...

Move the actions in StartWindowNotArmed to an independent Reaction (in the same Rule Set), and have StartWindowNotArmed start that Reaction without waiting for completion. That will allow the Set Reaction for the rule to keep executing and find the Action group on each pulse. That will also require osc_timer_armed to be global, since an independent Reaction can't touch local variables inside a Rule.

Make sure your Reset Reaction is completely empty, not even a comment. This is important, because if it contains anything at all, the reset caused by the pulse will interrupt/cancel the Set Reaction.

And you are correct! My error... in the case of Rule Reactions, the Engine already knows the Rule's Set Reaction is running, so it won't stop it, and it won't run it again until the Rule itself goes through the Reset state. The UI error message cause is still the same regardless (the running Reaction doesn't finish within the UI's waiting period for a response.

Of couse, you might be able to avoid all of this complexity by simply having a Rule to detect the low-frequency oscillation (pulse output -- the conditions as you have them will probably work) with no actions at all, and a second rule with a Ruie State condition looking at the former and using the "must repeat 6 times within 1800 seconds" condition option...

Edit: I think you can just do it in one rule, too, if you group the two conditions and apply the pulse on the group rather than the conditions individually.

Global Moderators

Posts

Member List