Event type/reason for charger drop-off

[openmobilityfoundation]

Event type/reason for charger drop-off

[thekaveman]

Now that I think about it, a follow-up clarification is for the event that identifies the actual pickup of the device that has a low battery.

It seems like unavailable:low_battery just says that the device can't be reserved by a user, but it doesn't say that the device has been collected by a charger.

I think this all comes down to how MDS defines "maintenance" - does charging include maintenance, or is maintenance strictly for replacing/repairing parts etc.?

Assuming "maintenance" is exclusive of charging, one path forward is to extend event_type and event_type_reason as follows:

| `event_type` | Description | `event_type_reason` | Description |
| ---------- | ---------------------- | ------- | ------------------ |
| `available`    | A device becomes available for customer use    | `service_start` | Device introduced into service at the beginning of the day (if program does not operate 24/7) |
| | | `user_drop_off` | User ends reservation |
| | | `rebalance_drop_off` | Device moved for rebalancing |
| | | `maintenance_drop_off` | Device introduced into service after being removed for maintenance |
+| | | `charger_drop_off` | Device introduced into service after being removed for recharging |
| `removed` | A device is removed from the street and unavailable for customer use | `service_end` | Device removed from street because service has ended for the day (if program does not operate 24/7) |
| | | `rebalance_pick_up` | Device removed from street and will be placed at another location to rebalance service |
-| | | `maintenance_pick_up` | Device removed from street so it can be worked on |
+| | | `maintenance_pick_up` | Device removed from street so it can be repaired or replaced |
+| | | `charger_pick_up` | Device removed from street so it can be recharged  |

If "maintenance" is inclusive of charging, then it seems like available:maintenance_drop_off and unavailable:maintenance_pick_up cover it.

[noonhub]

I believe that the main motive for these events and their reasons is to distinguish between events that take a device on and off the network by a user action vs an operations or provider action.

Some providers may not track or have a reason to track events at the granularity that the spec is suggesting, separate events for maintenance, rebalancing, and charging. If the spec could be flexible to allow for this granularity but not require it, that would be great.

I suggest that we have sort of hierarchy to the event_type_reason. Generic events such as provider_[pickup, drop_off] & user_[pickup, drop_off] that cover the two base cases and then potentially more specific events that providers can leverage if they have the data.

[hunterowens]

5/23 call seems to indicate that cities / providers have what they need to track the prow, so we can finally close this issue!