search

tykeal / homeassistant-rental-control

Rental Control system for Home Assistant
39 stars 4 forks source link

Clarify on `_event_x` entities #215

Open jamesshannon opened 1 month ago

jamesshannon commented 1 month ago

I'm hoping for some clarity on the customizable event sensors. I'm a bit confused. Once I understand better I can update the documentation, if you'd like.

According to the docs:

Creates a customizable number of event sensors that are the current and upcoming events
sensor.rental_control_my_calendar_event_0
sensor.rental_control_my_calendar_event_1
sensor.rental_control_my_calendar_event_2
(...)

My assumption is the _event_0 refers to the current or next-upcoming event, _event_1 refers to the one after that, etc.

I had someone check out today (calendar entry ends at 12pm) and someone check in today (at 4pm). It's currently 4:35pm. Accordingly, I would expect _event_0 to refer to the today-checkin event. And the event for the person who checked out today shouldn't be associated with any sensor. Ie, sensors don't refer to past events. I would expect that this would have happened at 12pm, or shortly after.

However _event_0 refers to the event for the person who checked out today.

Maybe the "switch" happens at midnight, or something?

FYI: The reason it's important to understand this is because I have an automation to set the wifi password to the last-4 digits of the guest who's checking in. It's triggered by the calendar event but the calendar event doesn't have the "last 4" attribute, so I'm getting the attribute from _event_0.

tykeal commented 2 weeks ago

_event_0 is always the oldest event that is still relevant. An event is relevant until midnight of the event ending.

So, if you have a guest checking out and one checking in on the same day then the one checking out will be in _event_0 and the one checking in will in _event_1 at midnight all the events will move down a sensor. So _event_0 will be replaced with the data for _event_1.

So, yes, the switch over happens at midnight. If you want some example automations that know how to deal with this you can take a look at any of the following blueprints that I have using data from the event sensors:

https://github.com/tykeal/homeassistant-blueprints/blob/main/thermostat-schedules.yaml https://github.com/tykeal/homeassistant-blueprints/blob/main/schedule-notifier.yaml https://github.com/tykeal/homeassistant-blueprints/blob/main/waste-can-notices.yaml

All three of those blueprints utilize both of the _event_0 and _event_1 sensors to know how to handle various changes or notifications to my property support personnel via a free Zulip instance I've got for this purpose.

Of the three, the waste can notices is probably the most interesting as it does different things depending on our guest states:

No guests in the house: send message to the "owner" (me) Guests checking out on day before garbage: send message to cleaning staff Guests in the property: send message to property manager to contact the guest

jamesshannon commented 2 weeks ago

Thanks for the clarification.

So it looks like you're using eta_days in your automation to determine if event_0 is the current or upcoming event?

I'd propose a more stable way to identify the current/upcoming/starting events that does't require looking more than one event, like an sensor "alias" (ie, a copy). So (in some cases) sensor.rental_control_my_calendar_event_0 would be the same as sensor.rental_control_my_calendar_event_current.

Is this something you'd be supportive of? (Note to self if I were to implement this -- the sensor creation code is here.)

The concept seems like the right way forward to me, though I'm not sure about the naming, mostly because of the ambiguity caused by the check-out / check-in gap. Ie, "current" makes certain makes sense before check-out and after check-in, but what about in the interim time? "Upcoming" seems like it'd make sense, but then after check-in is the current reservation still "upcoming"? You could have "current_upcoming"? Maybe "checks in today" and "checks out today"? So you'd have sensor.rental_control_my_calendar_event_x PLUS sensor.rental_control_my_calendar_event_checks_out_today and sensor.rental_control_my_calendar_event_checks_in_today.

tykeal commented 1 week ago

No, I'm not particularly supportive of it, mostly because of all the nuances that your final paragraph goes on about. With the pure numbered sensors, it's a logical progression of events. That being said, I would be willing look over a PR related to it. I wouldn't want the sensor to be a copy of an existing sensor, just a pointer to whatever the sensor that should actually be used is. Otherwise we run into sensor synchronization issues since all the sensors are on their own event loop after initial setup.

I use eta_days for the thermostat modifications as I want to make sure that I'm dealing with setting the thermostat to appropriate schedules depending our guest schedule. The waste can notifier blueprint does not make use of that attribute, just the dates related to the events. The schedule notifier doesn't even care about that, just if there are events defined. All of the blueprints were meant to be examples.

Given your specific use case my logic would be to actually trigger on ETA minutes for event_0 or event_1 dropping below a given threshold (probably 15 minutes). That way everything is in place before the guest is scheduled to arrive, not as they are arriving.

Alternatively, you could do something more along the lines of:

https://github.com/tykeal/homeassistant-blueprints/blob/main/guest-entry-notifier.yaml

Which sends a notification on the first time the guest uses their door code and not after that. Using this method, you'll be capturing an event from Keymaster which will then inform you as to what the slot_name is which you can back reference to the appropriate attribute off of event_0 or event_1 to pull the relevant information additional information that you're after and configure the wifi password only when the guest actually arrives.