A predicate cannot reach out to your systems. The engine on the device evaluates time and date, and nothing else. There is no way to call an API or run a command from inside the rule itself.
So reacting to live data works the other way around. Your own code watches the data, and when something changes, it pushes an updated predicate to Screenly. The predicate on a playlist is a plain string field, so changing what a playlist does is a matter of writing a new one.
Say you want a playlist to run through the day while an item is in stock, and to stop the moment it is not. Your integration checks stock on its own schedule, then updates the playlist’s predicate to match:
if in_stock("SKU-1234"):
set_predicate(playlist, "TRUE AND ($TIME BETWEEN {28800000, 79200000})")
else:
set_predicate(playlist, "FALSE")
Here set_predicate stands for a call to the Screenly API that writes a new value to the playlist’s predicate field. The decision lives in your code; the predicate only carries the result. TRUE and FALSE are valid predicates on their own, so stopping a playlist outright means pushing FALSE.
Because every screen holds a live websocket connection to Screenly, an updated predicate lands almost the instant you push it. There is no waiting for the screen to poll for changes; the new rule arrives over the open channel in close to real time.
The tradeoff is that this path needs the screen online. A time-based rule survives an outage because the device evaluates it locally. A pushed change has to be delivered, so a screen that is offline keeps its current predicate until it reconnects, and then takes the latest one.