Data I/O overage from SmartThings374
Pages:
1
|
jlv private msg quote post Address this user | |
| I'm uploading data from SmartThings, using the SmartApp that is batching up data (to avoid many small requesting eating into the monthly limit). I'm using a free account with just 5MB of monthly I/O. I'm still only in the experimenting phase just playing to see what I can do. I was trying to merge the data of 2 components (I renamed one and the data got split between the new name and the old name). I'm not sure exactly what I did; one thing was to decide for some components just to lost a few hours of data, so I deleted the new name and renamed the old one to the new name. Something caused my API uploads to start failing. The SmartApp just retries all the data it has batched when the upload fails. So every time it tried to upload, it did so with all the data since the first failed upload. The result was an explosive size in the upload request:  Eventually the Grovestreams backend blocked the data I/O when the 5MB limit was exceeded... but not quickly enough. As you can see, it did not stop until I'd used 165MB. If I was on a personal account and not a free account, this would have cost me $80!! |
||
| Post 1 • IP flag post | ||
|
MikeMills private msg quote post Address this user | |
| Send an email to support and we will reset your metrics until you figure things out. Which SmartThings example code did you use? The one from the ST forum or the GroveStreams SmartThings Quickstart? One user said the ST forum code incurred a lot of I/O. He switched to the GS code and his I/O was much lower. |
||
| Post 2 • IP flag post | ||
|
|
jlv private msg quote post Address this user | |
| Some there was already kind enough to reset my usage. Thank you! I am not using the SmartApp from the quickstart, because (as I mentioned above) that makes 1 PUT request per stream. This uses much more I/O. I am using this one, which queues up multiple values and sends 1 PUT updating multiple streams at once. This does result in fewer I/O bytes and transactions, as long as everything is working. The quickstart version will drop the value if there is a PUT error, while the queuing version will keep retrying the same data over and over, leading to this massive data usage. What I have done to avoid this meltdown again is modify my version of the queuing SmartApp to discard the queue if there is a PUT error. This was just a quick (1-line) change. Sometime in the future I plan to revisit this to be smarter and only drop the queue on consecutive errors. |
||
| Post 3 • IP flag post | ||
Pages:
1