Skip to content

tech details

Jump to bottom
TranQuiL edited this page Jun 11, 2026 · 1 revision

🛠️ Architecture & The Optimistic UI

The Grocy God-Tier Overhaul isn't just a reskin—it is a fundamental rewrite of how Home Assistant interacts with your Grocy server. Here is how the engine works under the hood.

⚡ The Optimistic UI Cache

Standard Home Assistant dashboards suffer from Polling Lag. If you click a button to complete a task, the UI sends the command, but the visual state on your screen won't change until Home Assistant's next 60-second polling cycle.

The grocy-action-card solves this using an Optimistic Execution Cache:

  1. You click "Consume".
  2. The JavaScript immediately intercepts the click, visually hides the item from your screen, and updates the "Total" counters instantly.
  3. It sends the payload to the Python backend in the background.
  4. It feels as fast and responsive as a native mobile app.

🎯 Direct API Strikes

The original integration relied on a 3rd-party library called pygrocy. As Grocy updated over the years, pygrocy fell behind, leading to silent crashes when attempting to delete items or execute chores.

Our new backend features a Direct API Strike fallback mechanism:

  1. Python attempts to use the standard library.
  2. If the library crashes or throws a TypeError, our code catches the failure.
  3. The backend bypasses the library entirely, constructs a perfectly formatted raw HTTP POST/DELETE request using your core CONF_URL and CONF_PORT, and fires it directly into your Grocy database.

🔄 The Delayed Refresh Engine

To prevent "Ghost Items" (items reappearing on your dashboard if you refresh the page before the next 60-second polling cycle), the backend implements a async_delayed_refresh task.

Exactly 2.0 seconds after you click any button, the Python integration quietly forces Home Assistant to fetch a fresh database pull from Grocy, perfectly syncing your dashboard state with reality.

Clone this wiki locally