How do I fix a dispenser update that appears "stuck" in processing?

When an dispenser update is pushed through the application - like when you update a dispenser’s Room Type - the message is sent to the selected dispenser(s) for processing. Database updates can also occur independently, however, in response to a dispenser’s own API calls. As a result, there can be instances where multiple messages sent to a dispenser in rapid succession can cause a conflict. This makes the application appear to “stick,” leaving the request unresolved for longer than expected. This is particularly true for the Pending flags for Configuration, OTA, and Wi-Fi Setting updates.

To prevent these kinds of conflicts from happening, Users should not push new updates if a Pending field is “Yes.” For example: do not change a Room Type on a given Dispenser while the Room Type Update Pending field already says yes - i.e., there’s already one update pending in the system.

Always wait for the Room Type Update Pending field to become “No” before scheduling another update for Room Type, etc.

In an instance where a request has already been pending for longer than usual, you may attempt to edit the dispenser record then change the Pending field to “No,” which could clear the pending request and allow for a fresh start.

For further troubleshooting, please submit a ticket for Support assistance.