Stuff you configure in the UI is mostly stored in the database, not as YAML. Nearly everything you’ve configured using YAML is not editable from the UI. Whenever an integration moves from YAML to the UI (like the Proximity integration in a recent release), the YAML config is deprecated.
There’s a few exceptions where YAML is stored in the DB (like if you have dashboard cards with custom configs) but YAML is going away over time as the UI gets more powerful, and is mostly just becoming a power-user thing.
Oh yeah, good point. It might make sense for those to remain YAML to allow for more advanced tweaks. I learned programming in Excel 97 by recording macros and then viewing and tweaking the VBA code behind them, and this feels kinda similar (although YAML isn’t a programming language).
It’s still all stored as YAML, there’s just a lot more help on the frontend
Stuff you configure in the UI is mostly stored in the database, not as YAML. Nearly everything you’ve configured using YAML is not editable from the UI. Whenever an integration moves from YAML to the UI (like the Proximity integration in a recent release), the YAML config is deprecated.
There’s a few exceptions where YAML is stored in the DB (like if you have dashboard cards with custom configs) but YAML is going away over time as the UI gets more powerful, and is mostly just becoming a power-user thing.
That’s true, I was thinking more about automations and scripts, which are still stored as YAML
Oh yeah, good point. It might make sense for those to remain YAML to allow for more advanced tweaks. I learned programming in Excel 97 by recording macros and then viewing and tweaking the VBA code behind them, and this feels kinda similar (although YAML isn’t a programming language).
Oh wow, that must’ve been painful