Is there a way to access the P2 filesystem directly? Otherwise I was planning on trying out the binary type publish, but since the size of the file may be larger than the publish limit I'd have to consider working around that. Just wondering if there was a simple way before I dive into trying a few different things.
Hey, I've read there is no way to access the file system.
Another option to the one you mention is using a TCP client (unsure if such a library works on a p2).
Best,
Got it. Right now I can just log dump the bytes over serial or the binary publish but I was wondering if something more sophisticated could be (easily) achieved using cloud resources. Could I use logic or some other webhook to parse the incoming binary events and combine them into a file?
Though if the file is large enough it would probably take too long to send as multiple publishes.
Increased publish size and rate limit will be coming in Device OS 6.3.0 as a preview release, possibly next week. You may still have to do recombination if your files are large, but a lot less than before.
Ooo interesting. Will the rate limit increase only be available on 6.3.0 or will it be released for other versions/platforms?
And can you tell us what that size limit will be or is that a surprise?
Only 6.3.0 and later.
The event size will be 16384 bytes of binary or text payload. Each 1024 bytes is a data operation, so sending a 2000 byte event is 2 data operations.
Instead of the fixed rate limit, you'll be limited to 32 Kbytes of data in transit. Thus slower cellular devices (LTE Cat M1 for example) will have a lower rate than Ethernet, Wi-Fi, and LTE Cat 1. There's a new API to see if the device can publish a given size if requested right now.
Will larger messages have the 1 second delay between 1,000 byte messages? Such as the 16k message take at least 16 seconds?
You do not need to delay 1 second between publishes with 6.3.0 and later. The limit is that only 32 Kbytes of data can be in the process of being sent at a time.
Also all publishes are asynchronous, though you can wait for completion to simulate the old behavior if you want to.
This is huge for me! Looking forward to it. Thank you team
On 6.3.0 I reduced my publish delay from 1 second to 100 ms, and it still rate limited the publishes after 4. Outside of looking at the commits, is there documentation on the new publishing API? I'm assuming the new limits and data in transit are exclusive to the new API usage.
The documentation will be out this coming week.
Prior to Device OS 6.3.0, there was a rate limit of approximately 1 publish for second, with greater bursts.
With Device OS 6.3.0 and extended publish, there is a limit of approximately 32 Kbytes of data in transit at a time. It is no longer necessary to wait a specific amount of time.
The canPublish()
method can be used to check if a publish of a given size would be allowed at the current time. It it returns false, you should wait and check again later after the queued data has been sent.
More specifically, the limit is 32 logical blocks of data, rounded up to 1024 bytes. An event without payload data takes 1 block, 1024 bytes of payload data is still 1 block, 1025 bytes is 2 blocks, and so on. If there are 32 logical data blocks in flight already, canPublish will return false or an attempt to publish without checking will fail.