For a couple of years now I’ve been trying to make peace with the scene editor and scenes in general. I’m about to spend hours switching to either automations or back to appdaemon scripts and wanted to see if maybe I just don’t understand the model and there’s a better way to use it.
I keep getting burned by unexpected changes to entities and devices and just plain wrong output that appears to only be fixable by removing and re adding devices or entities in specific orders (root cause is #2 below).
Use case is pretty table stakes for HA: I want to operate about 80 ‘common area’ lighting devices in a large house on global events (lights on at sunset, off in the morning for example).
-Bp9
Tldr; Details
I have about 120 distinct lighting devices on several integrations (wled, MQTT, ISY, and zwave) many with dozens of entities; and another 50 devices/600 entities unrelated to lighting. I’m running the hassos image on a VM on a Rocky Linux intel server with plenty of memory and cores (I used a PI 4B with an SSD for a while but it didn’t have enough CPU for the heavyweight Python code in HA).
Issue #1: scene editor interference
The scene editor on the client sort of checks out a scene and sets all the devices up to match it in real-time, if you end up with multiple tabs open in the same scene changes get lost overwritten when the web socket disconnects - this is PEBCAK (user error) but it’s really hard in practice to deal with
Issue #2: Conflicting entity state
I have 30 or so WLED devices on the wled integration. These each provide multiple entities that are in conflict with each other per device (preset select vs segment power state for example).
When the scene editor tries to save all this state it writes conflicting state on the multiple entities on the same device. One could say I should disable the dozens of entities on each of the 30 devices but that is hours of work in the clunky ui; I read the code and found where the JSON config files are hidden now, but it’s still painful to work with because “ha core restart” takes a couple of minutes to test each change. I also frequently do want the multiple ‘conflicting’ entities (manual dashboard control on one, presets on scenes).
There isn’t enough data in the entities to really capture the state and with WLED the entities come and go dynamically (depending on the number of segments defined in a wled preset and where it is in a playlist). In this case I can put the blame on my edge case use of the wled integration and its immature state. This all got a lot better when you were allowed to set entities in scenes instead of whole devices, but it’s a huge amount on manual ui drudge work to go and rework 30 devices, and I’ve tried and not yet succeeded several times due to the next issue…
Issue #3: scene corruption while editing live
There is no way to edit a scene without having it active, and if anything changes while it’s active the changes are written to the scene. This is impractical if you have motion detectors or other automations running while trying to make a large change (or a user is annoyed when a light goes on or off as you edit the scene and flips it back the way they want it before you finish your edit). It also means you can’t edit scenes at night with people in the house.
Yeah, I feel your pain.
This is why I quickly abandoned automations and scenes in HA. HA is pretty much my device communication hub, state machine, and web interface. My logic is all in NodeRED.
Yeah, same boat here.
I absolutely love how Home Assistant can handle virtually any device or integration you throw at it, but for the time being, I’m keeping all my logic in webCoRE on Hubitat.
How does nodered integrate with HA? MQTT or tighter?
There’s a Home Assistant module for NodeRED. NR uses HA’s HTTP API to listen for state changes, events, call services, etc.
The blue blocks top-right are state change events from HA. e.g. changing a toggle/slider in the HA UI. They fire off and send the current state data to the next block.
The orange blocks in the middle are Javascript blocks where I put the logic and craft the series of commands to send back to HA. Multiple commands are queued up in an array.
The next block is a short random delay to make sure HA doesn’t get overwhelmed with messages.
Finally, it sends each command in the array back to HA.
That’s pretty slick, it looks like there’s a hassos addon container for NodeRed which will make this super easy to set up. Thanks!
I too have found node-red much faster to learn, and easier to debug than using the built in HA automations and scripts. I can also keep things very organized with different flows (the tabs at the top) and lots of commenting (the white boxes you see.)
I spent the weekend moving scenes, automations, and appdaemon scripts over to node red. I really like it. Its a really nice setup and so far (after a learning curve on how the included FSM module deals with invalid triggers) is much nicer to work with than the built in stuff and python.
The only bits of friction I ran into are likely just unfamiliarity with the right patterns to use:
- Looking up entity names in fields that are not intended as entities (ie: inject node) needs a separate window open on the HA entities search screen; its especially hard to find select entities but that’s more of a naming issue inside HA.
- How on earth do you take a trigger message as input, then just create a whole new message as output (other than writing it as a function node)? The change node has no way to just start with a new message, and the inject node can’t be triggered. In a complex pipeline the message kept building up goop and I just wanted to emit a simple message at the end of it.
- A lot of examples in the built in docs show use of top level message properties other than ‘payload’, and some require it (like Trigger uses the top level ‘delay’ property), but this pattern of using top level properties isn’t well supported in some nodes.
