Global Moderators group | Smart Home

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.

toggledbits

@tunnus said in Variables not updating properly:

My hypothesis is that the first instance of the rule (running reaction) is locking these variables and other instances cannot modify them? Although could this even happen with global variables?

No, it doesn't work that way. When you try to re-run the reaction, it stops the running reaction and restarts a new thread. The timeout is simply because of the long delay. That's on the UI side. The UI is waiting for a "finished" response and the reaction is taking longer than the wait time. That's harmless. It has no effect on the variables.

Every test case I've tried doing this is working fine for both local and global. I assume you've restarted Reactor as part of the testing? The only issue I see is that some variable value display updates are not happening correctly while editing the rule (i.e. in the rule editor, so don't rely on those at the moment), but they are correct if you expand the rule detail in the Rules list, and the global variables are updating correctly in the Expressions list.

Your computation of g_oscFlag is... puzzling. First of all, there's no need for using g_oscCount ?? 0 in that second expression, because the first expression assures that a value is set on g_oscCount (so the ?? 0 will never be used). But more to focus on is (g_oscFlag ?? 0) as the false side expression of the ternary operator (cond ? true : false). Here, g_oscFlag will be zero until g_oscCount is >= 6, when it will become 1, but then, it will be 1 forever more, because if g_oscCount is reset to zero, for example, then the false condition will simply set g_oscFlag to itself, which is 1, not 0. Not really sure this is what you intended, and could explain why you're not getting your desired behavior. Also the variable name used in the first group isn't shown in any of the expressions, but I assume that's just a left-over of much editing/trials. Still, check that as well.

Also, in this case, you may want to use the ?# operator instead of ??. That ensures that the left side operands can be evaluated to a numeric value. If not, the expression result is the right side operator. That will handle any non-numeric values in g_oscCount (not just null).

Global Moderators

Posts

Member List