Why my devices lose published events? I am publishing through the cloud API and I get a valid response (ok:True). The ttl of these events are large enough to counter random disconnects. Isn’t supposed for the cloud to persist those events for this ttl period so the device can read them when it connects back?
Unfortunately:
ttl (time to live, 0–16777215 seconds, default 60) !! NOTE: The user-specified ttl value is not yet implemented, so changing this property will not currently have any impact.
https://docs.particle.io/reference/device-os/firmware/argon/#particle-publish-
Hello, from what I understand the default=60 means that ttl = 60 seconds at least. Am I wrong ? Because it seems that is not implemented at all …
OK, re-reading it from a different perspective, the “user-specified” part may be misleading - I’ll change that.
Committed this reworded version just now - should go online soon
2 Likes
I would even re-phrase is as:
NOTE: The ttl feature is not yet implemented. Events would be lost if you haven't subscribed to the event topic before calling publish (from the device or cloud).
I may have a different idea on what ttl means, but from what I understand, it is that messages should persist (from device to cloud and cloud to device for the ttl seconds). When saying default ttl=60, it may makes sense for you, that the firmware function signature is:
publish (const char * topic, const char * event, unsigned int ttl=60)
and that is where the default=60 comes from, but for me, it means that:
yes the messages persist for 60 seconds, but you cannot use a different value
which would not be the case, since messages do not persist at all (that is why I reported this behavior initially). Sorry for this back and forth, but I want to make sure we are on the same page.
I know it’s been a while since this thread was last active, but running into a similar problem - the application I’m working on requires regular short sleeps to reduce power consumption (5-30s range), with brief wake up periods to log data and check for subscribed events.
I’m publishing events with the cloud API to update device config, and I’ve seen some conflicting behaviour - sometimes the device subscribe function will happily respond to those events, and sometimes they’ll go unnoticed.
They’re responded to often enough that it’s very unlikely I’m always publishing exactly when the device is awake, so it appears there is some amount of persistence of the events, and if so does anyone have an idea how long that persistence is?
I’d also note that the Cloud API docs do not acknowledge that ttl is not yet implemented:
https://docs.particle.io/reference/device-cloud/api/#publish-an-event
@ScruffR would it be possible to get that updated?
I’d rather leave that to the officials like @rickkas7
1 Like
The TTL is not supported in either direction. If your device is not awake at the moment that an event is sent, the event will be discarded and you will not see it on your on-device subscribe handler.
2 Likes
I know there have been a bunch of threads on this, but I couldn't find definitive evidence for the cloud API, thanks for the clarification @rickkas7!
I'd still suggest updating the docs for the device cloud API since there is still no mention there that TTL is not implemented, so they lead people (my past self included) to believe that this feature can be used with API events.
Hi all,
I’m working with @ExF and our eventual solution to the OP’s core problem was to set up our own MQTT solution.
We went with Mosquitto for the MQTT broker; that way we can customise how our pub/sub events are handled by having control over the QOS and '‘clean session’ flag.