Adds useful attributes to RainMachine programs and zones

[bachya]

Description:

This PR adds several useful attributes to RainMachine programs and zones, including:

• Restrictions
• Cycles
• Capacities
• Sun Type
• Soil Type
• Vegetation Type

Additionally, under the hood, the process of migrating common RainMachine data/logic into the component created by #14225 starts.

Related issue (if applicable): N/A

Pull request in home-assistant.github.io with documentation (if applicable): N/A

Example entry for configuration.yaml (if applicable):

rainmachine:
  ip_address: 192.168.1.100
  password: abc123

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:
- [ ] New dependencies have been added to the REQUIREMENTS variable (example).
- [ ] New dependencies are only imported inside functions that use them (example).
- [ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
- [ ] New files were added to .coveragerc.

[balloob]

We should just use mac and type. I don't know what entity id is ?

[bachya]

MAC and type aren't sufficient – in that case, every program would have the same unique ID (e.g., "abcdef1234_program"). Same with zones. entity_id is the ID of that specific program or zone, which gives results like "abcdef1234_program_2". Let me know if I'm thinking about this wrong or doing the job in a confusing manner.

[balloob]

That makes sense. Got confused because Home Assistant also has the concept of entity ids.

[balloob]

We should never have relative time in the attributes.

[bachya]

10-4.

[balloob]

We should only store information in the attributes that is relevant in further explaining the state.

[balloob]

Just because we have the data, doesn't mean that we should add it to our state machine.

[bachya]

I've been a tad over-zealous. 😄 Question: what about attributes that don't relate directly to the state, but would still be useful in influencing the state? Example: I have an attribute for soil type; it'd be great to use this in my automations for the switch itself (e.g., "If the temperature goes above 80 degrees, stop watering zones with Clay Loam soil").

[balloob]

That can stay. I guess that is similar to things like max_temp for climate devices.

[bachya]

Thanks, @balloob. I've removed all frivolous attributes and all attributes that (a) aren't directly related to the state and (b) aren't useful in influencing the state through automation. Let me know your thoughts?

[MartinHjelmare]

Use async_schedule_update_ha_state.

[bachya]

Got it. For my own knowledge, this is because the @callback decorator declares that anything in the method body is safe for the event loop, yes?

[MartinHjelmare]

Yes! When the dispatcher calls this method it uses the core method async_add_job which checks if the function/method has been decorated with callback, and if so, schedules a call to it on the event loop. Otherwise it will be run in the thread pool (if it's not a coroutine or coroutine function).

[MartinHjelmare]

Looks good!