[FEATURE REQUEST] Add vehicle status in notifications

[edwinvandenbelt]

Is your feature request related to a problem? Please describe.

The MP can request operations on a leg, to change the status (like set_in_use). It is not possible for the TO to notify the MP (and end user) on a clear, uniform way the status of the asset (like 'it is unlocked now').

Urgency

Major (the TOMP API works as advertised but this is really necessary to implement), because this is standardisable.

Additional context

The status lock of the bike is remotely monitored, and standardized messages of the status of the asset should be send to the MP.

Describe the solution you'd like

Add new notificationTypes: corresponding with the leg status, including some more details like 'locked' and 'unlocked'

Describe alternatives you've considered

Call /legs/{id}/events on the MP side, but this has another meaning

Possible Implementation

Add to notification.type: LOCKED, UNLOCKED, PAUSED, PREPARING, IN_USE, RESUMED, FINISHING, FINISHED (and maybe some additional ones for support use cases?)

[matt-wirtz]

Trying to make the sequence of the proposed new notification type more clearly. I had in mind a bike with a lock that can be closed manually. Generally should be transferable to a car as well. I still don't really see how this could improve the UX. With the response to SET_IN_USE the TO can already give a definite answer if the unlocking of the vehicle was successful or not. Is there an additional notification helpful?

[edwinvandenbelt]

Hello Matthias,

I don't know, is the end user not interested in a confirmation, and a confirmation of 'SET_IN_USE' is a confirmation that the leg has been started. And, what I understood is that the end user cannot unlock until the bike is prepared to do so. So, the end user must be informed that the lock can be opened manually. Or did I misinterpreted the process?

And if you detect it is manually locked, you can changed the state in the backend to paused to stop optionally the paid part. And, of course, when it is unlocked again, it should be again IN_USE.

At the end use should - I think - in your case always send a 'finish' operation, otherwise you don't know when the usage has ended (it could be paused as well).

Is this an answer to your question?

Regards, Edwin

---

Van: matt-wirtz @.> Verzonden: woensdag 20 maart 2024 11:50 Aan: TOMP-WG/TOMP-API @.> CC: Edwin van den Belt @.>; Author @.> Onderwerp: Re: [TOMP-WG/TOMP-API] [FEATURE REQUEST] Add vehicle status in notifications (Issue #541)

Trying to make the sequence of the proposed new notification type more clearly. I had in mind a bike with a lock that can be closed manually. Generally should be transferable to a car as well. I still don't really see how this could improve the UX. With the response to SET_IN_USE the TO can already give a definite answer if the unlocking of the vehicle was successful or not. Is there an additional notification helpful? tomp_issue541_vehicle_status_in_notification.png (view on web)https://github.com/TOMP-WG/TOMP-API/assets/13720157/b711ee9c-399e-45d5-81a7-6546216850ac

— Reply to this email directly, view it on GitHubhttps://github.com/TOMP-WG/TOMP-API/issues/541#issuecomment-2009262592, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPLCNWH4DOQLC6VFONIGG3YZFSYXAVCNFSM6AAAAABETWKVFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBZGI3DENJZGI. You are receiving this because you authored the thread.Message ID: @.***>

[matt-wirtz]

Hi Edwin, yes there are locking systems - I think especially for bikes - where the lock does not snap open when it's unlocked. Typically there is a bolt or pin blocking the wheel from spinning which has to be removed by the user manually. And this can only be done, when the bolt has been unlocked. I think in this case it should be part of the process identifiers like UNLOCK_TRUNK or TAKE_HELMET. There could be an additional identifier e.g. REMOVE_LOCKING_BOLT or UNLOCK_BIKE. Maybe UNLOCK_BIKE would be better because there is already an UNLOCK_LOCKER and UNLOCK_TRUNK. Does that make sense? And yes, I stopped with my sequence diagram in the middle of the trip execution when I realized that the notifications don't add any value. At least I should have put some points at the end (...) indicating that I omitted some parts.

[matt-wirtz]

@zerwuff Hi! We discussed this issue at our last WT meeting. If we understand it correctly it's related to manually operated bike locks where typically there is a bolt or pin blocking the wheel from spinning which has to be removed by the user manually. And this can only be done, after the bolt/pin has been unlocked remotely. The process of remotely unlocking is taking time and should/can not be safely completed in between the calls of /legs/{id}/events { "event": "SET_IN_USE" } and it's response. Therefore the initial idea to later send a notification once the lock was remotely unlocked is logically. The problem we see is that in this case the response to /legs/{id}/events { "event": "SET_IN_USE" } would be a 200 { leg object: "state": "IN_USE" } which indicates to the MP that the bike is "IN_USE", it's unlocked and can be used. But that is not the case since the unlocking takes more time. We therefore suggest to not make use of notifications but rather wait to send the 200 { leg object: "state": "IN_USE" } response until the lock has been remotely unlocked. See the sequence diagram below. Would this be a solution for your case?

[zerwuff]

hello @matt-wirtz, this looks much simpler. As i understood, the idea is not to push any notifications back from TO to MP, but let the MP use long polling the TO until the TO response switches from 503 to 200. This would indicate that the set in use process has been 2-face-commited by the end user (open-lock) and the ride is ready to go (CONFIRMED). I think this would solve our problem, thanks a lot