Is that a requirement? I personally would see more benefit in not having things overridden. Maybe it’s better for 90% of Bond customers to standardize, but I would say if you’re the kind of person who is POST’ing or PATCH’ing, you should be given more freedom and less Bond-enforcing-overrides. ![]()
I suppose I should map out each scenario very carefully. I can use these States, I think. Am I missing any?
And these correspond to the Feedback boolean expressions to see if the Icon should be lit up or dark?
- state.timer
- state.direction
- state.down_light
- state.flame
- state.fpfan_power
- state.fpfan_speed
- state.light
- state.open
- state.power
- state.speed
- state.up_light
I’d kind of like the ability to make custom States (and even Actions!)- such as a “color” or “temperature” State for tracking bulb colors on Fans / Fireplaces / Lamps (and an Action to change it!).
I tried making an expression with a custom “feedback” State in a POST command creation, but it discarded any State which wasn’t known, it seems.
"feedback\":\"state.light==1 and state.up_light==1 and state.down_light==0 and state.color_light==3400"
Thinking maybe I needed to PATCH a State to create a custom one, I ran into a different error response - so it basically reinforces the idea that States are only allowed if they already exist on the Device (perhaps even limited to the Type of device it is) / no custom States:
{"_error_id":153,"_error_msg":"requested state does not exist"}