I doubt there is some (cheap) third-party service that supports this out of the box, so you will need (someone) to write your own application code, on some server outside of TTN. Sure, that could use Node-RED, but anything else can be used too. There are even free services that offer both handling of incoming HTTP data (for the uplinks), SQL database storage, and invoking webhooks (to schedule the downlink), such as pipedream†.
To get data into your own server use the MQTT Data API or the HTTP Integration.
However:
-
LoRaWAN is radio, so you never know if a transmission is received. The uplink counter will give you some clue about that (but a missing value might also indicate that the device used an empty uplink to respond to some LoRaWAN network command). Does your use case really need to rely on radio?
-
The TTN community network only supports Class A devices, hence a device needs to send an uplink to receive a downlink. However, see My application's downlink is always queued for next uplink.
-
You can only send at most 10 downlinks per day per device; see Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair Access Policy [guidelines].
If this is about two subsequent sensor readings of a single device then I think you’d better have the device itself implement that logic. If the trigger level might change over time, then you can use downlinks to configure the threshold that the device uses.
† Pipedream SQL stores data for 30 days, but may take up to a minute to persist data. Pipedream workflows also have a state that does not need any database at all. All great for proof of concepts, or maybe even production workflows once they offer paid plans with their paid plans.