Forum wide moderators
Hey @toggledbits.
I found a strange bug while sending boolean MQTT payloads in actions. Latest MQTT/Reactor builds.
Basically, if I send a true/false, it gets logged but it's not sent:
[latest-25328]2025-12-31T11:36:23.958Z <MQTTController:INFO> MQTTController#mqtt x_mqtt.publish publishing foo/cmd/foo payload false
If I change to ${{ str(1 == 1) }}, it goes thru. No apparent errors in logs.
I did a "replace script" that's parsing JSON files and replacing references. Every time I change a device (i.e.: I pair a new Zwave device or replace some Wi-Fi thing with ZigBee/Zwave), I run it with old device and new device as params. Back in the days I mostly did it manually.
Here's the todo list:
I agree a much needed feature will be the ability to filter rules by device. At least you'll easily spot the ones not used in code blocks and that will be useful when you don't remember the exact rule that is doing something with a particular device.
No idea how easy this would be. During my migration away from Z-wave I've been replacing the Z-wave devices with Sonoff which has broken some of my automations.
Any chance of a 'Test Reaction' function to call out which ones are broken because an entity no longer exists? Without actually running the reaction?
Or does this exist already and I'm just not aware of how to do it? Obviously I can see entities that are no longer available, but not quite what I'm looking for.
I guess it's something of an edge case so no huge issue.
TIA!
C
I tried different things and after all I’ve just switched to my own emulated hue bridge, calling reactor HTTP endpoints. I was toying with the idea of sending MQTT commands, but HTTP just works. I did my own bridge because I have 100 switches/scenes/virtual switches mapped to Alexa and ha-bridge has not the ability to define multiple bridges on the same host, so I wrote mine 
But ha-bridge should just work. Never tried HASS native hue emulation. I tried matter bridge and unfortunately Alexa will only see 20 devices.
So far just keeps getting better. I thought I'd hit a snag yesterday wit the newly installed garage light switch being slow to trigger (IRO 6 seconds) but realised I was using the wrong HASS sensor attribute (durrr) once I sorted that, it's all sorted. Typical response times are sub second.
Some oddities in where I've migrated with some hacky virtual switches which I need to track down. I'd get rid of them but trying to expose HA entities to Alexa seems a bit hit and miss...
C
That sounds very clever @Crille !. Does the light level actually increase in your case? I'd have more expected it to be constant once the lights are on? @Pabla is there actually a spike, or is the sensor reading the (one would expect) increased light level? This is assuming the sensor is within the zone of the lights....
C
Back in the days I used an illuminance binary sensor to do this (linked to a fibaro relay), but now I’m using civil dawn/dusk and called it a day.
All that said, I’m still using an illuminance sensor indoor in my office to drive my blinds.
My logic is like the one you mentioned: once triggered, the low light state stays true for at least two hours. When driving lights/blinds, hysteresis is fundamental.
I was toying with the idea of using a time series, so I could get let’s say a trend and/or the avg in the latest 15 minutes or so, but it seemed overkill for this simple situation.
In the version you are using, it is still required; that's the docs leading the released code by a step (sorry). The version you are using also doesn't enforce limits well, so it allows values that could produce no result, or store more data than needed.
For example, given your retention of 60 and interval of 5, there would be r/i+1 = 13 samples in the series. But if you specify depth of 2, then only the most recent 2d-1 = 3 samples are considered... the other 10 samples don't contribute to the result value. A depth of 7 would be the best match for the given interval and retention (just mathematically, ignoring your semantic goals).
