Closed koying closed 1 month ago
Indeed, it's by design. To allow users to make the difference between a warning currently going on and a future warning I plan to keep it this way.
However, an additional sensor exists to help you anticipate (related to #21). The sensor is called sensor.home_next_warning
and the state is the timestamp at which the next warning starts. It turns to unknown
as soon as the warning starts but the warning is visible with the sensor you mention.
Would that fit your use case?
Thanks for your answer.
Having the binary_sensor just made my life easier but I'll manage one way or the other (and thanks for the hint regarding "next warning", I'll probably use that).
Thanks for this great integration. It makes the quality of weather predictions for Belgians miles ahead of what we had before 😍
I guess it's by design, but that alert binary sensor is only "on" during the event, which is not great when trying to anticipate ;) For reference, the
meteoalarm
integration is "on" as soon as an event is foreseen.Would you consider following the same logic?
Thanks