Paulus Schoutsen

Instead of making things official attributes, the few platforms that have it can add it to their forecast data. Making something official means we need to add UI support.

So if this is for just the frontend, we could consider just adding such a button. There would be no need to change the backend for that.

I'm wondering here if we should add a new `cycle_X` service (And end up adding such a service for every list) or that we should template methods `cycle_next` and `cycle_prev`...

They would work as template methods. So if you are templating service data, you could just cycle to the next. With a generic approach it will also work for input_select,...

That's assuming given any state, we know if we need to cycle the state or an attribute, and that we know the right service to call to change it, and...

I think that if we talk about speed conversion, we can't do it automatically anymore inside `Entity#update_ha_state`. Instead, for example the weather component will have to take charge, look at...

I think it makes sense to add a speed preference and then people will have to update each component to do contextual conversion.

We should only have 1 speed preference. It will be up to the component to use that speed preference to create the right value based on the context. That is...

I think that if a sensor would show vertical speed (can't think of a use case tbh), it would be fine for the sensor to judge which unit to use...

I think that adding a property to not do something is silly. I think that instead, and this is a bit more impactful, we should extract the entity conversion logic...