I recently saw something added to the cookbook that explains how templates are evaluated. I feel that belongs in the official documentation (in the Rate Limiting Updates section) where this topic is introduced and explained.
I feel there should be a clear division between the cookbook and the documentation. The docs explain basic concepts whereas the cookbook shows how to apply those concepts. Otherwise we will have two references explaining concepts and neither is complete (i.e. you will have to read both to fully understand a basic concept).
Good point - and a good distinction. Perhaps something based on the cookbook post should be submitted for the docs, which might benefit from a summary section.
Cookbook posts should certainly include links to the documentation (which I’ve added in this case).
Thoughts, anyone?
Edit: The original post by @petro was in response to a question, not a community guide.
@123
Ya I translated it and attributed it on a request, but do whatever needs doing.
I personally don’t know the answers there.
It was @parautenbach 's request originally.
My first instinct was to add it to Templating, but what he wrote is a combination of the states object and templating functions.
Ideally one would like to keep this all together, but it kind of sits between the two pages. That rate-limiting section mentions the state object, but I think adding a list of template functions in there will be rejected in a PR.
I would like to suggest that Getting Started with HA and Setting up HA to be separate sections because it’s quite a huge scope from a beginner’s point of view.
Looks like you can add comments to posts by enclosing them in angle brackets - have I got this right?
Used sparingly this might be useful in the index post - to indicate where a link appears in more than one section, for example. (I’ve added a couple of comments in the Troubleshooting section.)
They only seem to be visible in the edit box - not in edit history.
Now that I see your new addition I’m thinking we need something for using the context of a trigger too. Many people want to know which user did something, or whether a physical switch was flipped.
It is kind of documented, and perhaps here we can argue too that the docs should just be improved.
Anyway, there are numerous posts about this, but here are two of interest:
