T
Depends on what you mean by "fire". If you look at the logs (not in pulse output mode, but in the default "follow"), you will probably see it being re-evaluated every 10 seconds, but because your result is a constant true, the rule SETs and never RESETs. Changing it to pulse output, of course, changes that.
The thing to notice, though, is that the expression IS being evaluated every 10 seconds, regardless of the output mode of the condition.
Ahhh... the subtlies of Pi. I have on my Pi4 build system:
root@rpi4-1:~# uname -m
aarch64
root@rpi4-1:~# dpkg-architecture -q DEB_HOST_ARCH
armhf
root@rpi4-1:~#
And never noticed. I guess I'll be rebuilding that host.
Image is up for arm64 using Bookworm (slim). I've always done builds directly on target hosts; this one was built on x86_64 cross-platform, so I'm eager to hear if it works for you. I can't run it on that Pi4 in its current condition.
Yes, that's correct!
You should be able to go back to something similar to what you were doing originally, just in Script conditions. Give it a try!
NOTE FOR HOME ASSISTANT USERS: Versions of Home Assistant prior to 2025.01 are no longer supported as of this build. They may continue to work, but no effort will be expended to maintain compatibility going forward.
alarm() function works in it, too! And it holds more secrets... see docs WARNING: This is a "bleeding edge" new feature; it may be subject to breaking changes as it evolves into final form.print() function to assist troubleshooting of complex expressions.input_datetime entities and other similar.Got it. Multiple layers of this. It actually is related to the other PR, but again, that's also not the only issue. They also introduced a new selector type specifically for time and HassController is not handling it properly.
I'll have a new full build out later today. No more respins on 25310.
OK. So this is not the whole mystery, but it addresses one part... the service call looks like it depends on the configuration of the entity. The integration has two properties for its entities has_date and has_time, and if one is false and you attempt to set that field, you get an error. I just created another input_datetime with has_date: false and has_time: true and the service call works fine.
HassController is still not happy, though... still looking...
Different. I'm looking into this. Using HA's own developer tools UI, this service fails as well when trying to set only the time component... 
I'm working for you. You also gave me an idea that I think could create a very useful alternative way to get to where you want to go. More to come...
@CatmanV2 said in Help resolve change in behaviour post update:
My assumption is it will go false at, or immediately after midnight?
No. If your GlobalAlarmTime will always show time only (no date components), then you can safely add an alarm() call to GlobalHeatTime as well.
@CatmanV2 said in Help resolve change in behaviour post update:
Will I see it updating in the logs?
Yes, and on the Expressions page.
@CatmanV2 said in Help resolve change in behaviour post update:
I'm further guessing that I'd set up a new global variable to replace HeatTime and have something like
GlobalHeatTime = alarm ( 900) , time(GlobalAlarmTime) - 3600000
You're on the right track. If I understand your description, something like this should work (all globals):
gAlarmTime = getEntity( ... )
gHeatTime = time(gAlarmTime) - 3600000
gHeatOn = alarm(900), time() >= gHeatTime
gAlarmTime will be updated any time the dependent entity changes. gHeatTime will change any time gAlarmTime changes (reference to another variable creates a dependency on that variable). gHeatOn will be updated by the periodic alarm() tripping.
@gwp1 yes!
Whew! If that was anything, it was the work of an aging magician. 
Thanks for sticking with it and supplying good info.
OK. Please pull 25310 (aka latest) again. I've patched HassController for this change.
OK. I think I've got it. Pull it once again and restart... this time for sure!!!
It's not mentioned in a substitution somewhere?
Where else are you using that variable, and how?
No errors now?
Yes, please reproduce. Level 4 is fine. You can also set gvar_debug: true in the engine config section -- that will be verbose but a lot less verbose than level 5.