[Enhancement] Handle concurrent orders

[eMeF1]

Hey @dvejsada, the integration works perfectly and supports some of our favorite automations.

One thing I noticed is that when there are multiple orders simultaneously, the integration doesn't fetch the one that arrives first.

Could you adjust the logic to account for this?

If you point me to a specific endpoint, I can try to catch what the response looks like in those situations.

Let me know your thoughts.

[dvejsada]

Thanks, I will have a look at this (actually I never had more orders at one time:))

[eMeF1]

We just had three, and I started panicking about why the doors don't open automatically :)

[dvejsada]

@eMeF1 It should be this API endpoint - https://www.rohlik.cz/api/v3/orders/upcoming. If you could provide how response looks with multiple active orders, it would help me a lot.

[eMeF1]

I'll keep that in mind and will get back to you once we have two orders.

[eMeF1]

@dvejsada

[{"id":1113646676,"itemsCount":3,"priceComposition":{"total":{"amount":899.70,"currency":"CZK"}},"orderTime":"2025-11-25T22:10:47.000+0100","deliverySlot":{"id":1091165,"type":"ON_TIME","since":"2025-11-27T06:30:01.000+0100","till":"2025-11-27T06:45:00.000+0100"},"pblLink":null},{"id":1113643600,"itemsCount":11,"priceComposition":{"total":{"amount":770.33,"currency":"CZK"}},"orderTime":"2025-11-25T20:50:44.000+0100","deliverySlot":{"id":1090492,"type":"EXPRESS","since":"2025-11-25T22:15:01.000+0100","till":"2025-11-25T22:30:00.000+0100"},"pblLink":null}]

[eMeF1]

Hi @dvejsada,
I’ve implemented it. The changes add logic to select the order with the earliest delivery time when multiple concurrent orders exist, instead of always using next_order[0].

What I did:

• Added get_earliest_order() utility function that finds the order with the earliest deliverySlot.since time
• Updated NextOrderSince, NextOrderTill, and IsOrderedSensor to use this function
• Handles edge cases (empty lists, missing fields, invalid dates)

Current status:

• Code is implemented and pushed to branch fix/handle-concurrent-orders-53 in my fork
• I'll test it once I have one/multiple concurrent orders

Question:
Would you like me to create a draft pull request so you can test it as well? I can create it now, or wait until I've tested it first. Let me know your preference!

[dvejsada]

Hi @dvejsada, I’ve implemented it. The changes add logic to select the order with the earliest delivery time when multiple concurrent orders exist, instead of always using next_order[0].

What I did:

• Added get_earliest_order() utility function that finds the order with the earliest deliverySlot.since time
• Updated NextOrderSince, NextOrderTill, and IsOrderedSensor to use this function
• Handles edge cases (empty lists, missing fields, invalid dates)

Current status:

• Code is implemented and pushed to branch fix/handle-concurrent-orders-53 in my fork
• I'll test it once I have one/multiple concurrent orders

Question: Would you like me to create a draft pull request so you can test it as well? I can create it now, or wait until I've tested it first. Let me know your preference!

Yes please, submit PR once you test it (we do not have concurrent orders usually).

[eMeF1]

There are still some edge cases when it doesn't work. Specifically the sensor.[device]_delivery_time inherit the value from the announcement which may not always relate to the soonest order.

Furthermore when the announcement is cleared out on the endpoint, the sensor.[device]_delivery_time maintain the last value as long as binary_sensor.[device]_next_order_made is true since this is a logic to prevent that value to be cleared short before the delivery.

We could check if the announcement relates to the soonest order and if not we can fetch the data from the same source as sensor.[device]_delivery_slot_end which works OK.