Deletion of the `POST /api/{api}/deliveries` endpoint

[Stephan202]

Hi @MikeBrink! Just a heads-up: Picnic plans to drop (without replacement) the POST /api/{api}/deliveries endpoint in the coming 1-2 weeks, thereby dropping support for PicnicAPI.get_deliveries(summary=false).

(The POST /api/{api}/deliveries/summary endpoint remains functional.)

[d-EScape]

Thanks for pointing out this change, @Stephan202!

This change also breaks the .get_current_deliveries() method of this very useful python wrapper. I use the upcoming delivery to integrate the eta in my home automation environment.

As a work-around I am now using the .get_deliveries(summary=True) and check the status of the first item (e.g. delivery[0]['status']=='CURRENT'). I am not sure if this is 100% reliable to get the current delivery(?)

Maybe the .get_current_deliveries() can be adapted to the changes in the Picnic API?

[Stephan202]

Hi @d-EScape! I had a quick look at the code, and CURRENT is a decent-but-not-perfect proxy for testing whether a delivery is "upcoming". Since one may have multiple upcoming deliveries I guess one can additionally check the slot.window_start (= the start of the originally selected one-hour slot) property. Closer to delivery time the 20-minute eta2 window will also be populated. Finally, once delivered the delivery_time field should also be populated; this could be used to filter out CURRENT deliveries that already happened.

Lastly, I see that the endpoint returns deliveries by their creation time, so delivery[0] may not always be the one you're interested in :)

[d-EScape]

That's some very useful info. Thanks again @Stephan202.
eta2 is indeed the next thing I am using (['eta2']['start'] in this python wrapper). I assumed delivery[0] was always the next upcoming delivery, but wasn't sure. I only have a limit set of actual data and no api documentation. So thanks for confirming that it is in fact not always the next upcoming delivery.
Since we normally only have one planned delivery at a time it will do for now. At least my domoticz plugin is no longer crashing on this api change.

Maybe @MikeBrink has a more robust solution for the python wrapper itself.