I’ve been tinkering with a particle electron, a cellular enabled board that ideally pushes the bare minimum number of bytes across the air to get the job done, for the sake of data costs. I’ve been trying to make a program that doesn’t send any data until initiated by a blynk_write button press from the app. What kind of data usage should I expect for the hardware ‘heartbeat’, or in other words, for the hardware to communicate with the blynk server to tell it that it is still online?
I found a previous discussion concerning the expected data usage from the app to the blynk server when ‘nothing’ is being done (which sounds like there is no data traffic, makes sense). But I couldn’t spot any discussions that explained the expected data usage from the hardware side when ‘nothing’ is happening, but the hardware is only idly connected to the blynk server … I highly suspect that the data usage from the hardware side is not zero =D, and actually is in the range of a couple hundred kilobytes per day. Any direction would be helpful!
Hello. By default heartbeat interval is 5 seconds. Heartbeat packet size is 5 bytes + TCP/IP packet size itself 20 bytes. So 1 heartbeat packet is 25 bytes. So it is 300 bytes per minute. You can also change heartbeat interval and increase it in order to minimize traffic.
So around 420kb / day with 5 second heartbeat.
@Dmitriy one of my projects shows the following details from the API:
I don’t remember setting a 10 second heartbeat but for me it is ok. What is the syntax to change the hearbeatInterval?
My bad. Default heartbeat interval now is 10 seconds. You can manually change it in
@Dmitriy Perfect, just what I was looking for! One last question to save myself and hopefully others some trouble… Is there an upper limit to the heartbeat interval? It sounds like the particle electron only has to push data every 23 minutes in order to keep connection active on cell network when using the particle mvno network. Could I define heartbeat at 22 minutes without the blynk server getting mad at me? For my purposes, once I initiate a ‘get data’ button press from the app, I’ll be able to tell if my hardware is online by seeing the data get pushed.
thanks for quick and meaningful response, blynk is BY FAR (WAY WAY BY FAR) my best Kickstarter backing! Keep up the great work guys!
You can find upper limit for your provider/hardware experimentally. In general, we do not recommend setting it to more than 30 or 60 seconds.
But in some cases even 5 minutes can work fine.
@evancraig22 well, I can say only that server itself will not drop connection and there is no limit for heatbeat. And in theory heartbeat interval can be as big as you need. However I just wondering - are you really need this? Is problem with traffic or something else?
I think particle just opens connection every 23 minutes. It seems more logical for me.
@Dmitriy You are probably right concerning the cellular activity. Perhaps ‘push data’ wasn’t the best term, but some connectivity between the hardware and cellular network to maintain active connection status.
I’ve been running hardware with a 20 minutes (1200 sec) heartbeat now for almost a day, and everything appears to be working just fine! Woohoo! Data usage in the last 22 hours has been… 0.04 megabytes (with quite a few data requests to keep checking if it is working =D)
@Dmitriy @vshymanskyy Is is possible to communicate with blynk server using UDP protocol to cut down on all the tcp/ip overhead? I’m feeling pretty comfortable with my current data demands, but am just curious?
@Dmitriy To more fully answer your previous question, I am strictly trying to reduce traffic. The minimum Particle cellular plan that Particle sells with the electron is 1mb of data a month for $3, with each additional Mb costing $1. (I’m working through 3rd party alternatives right now…which perhaps I will give an update in regards to this when I have had a chance to test some options). But, if I want to maintain constant connection to be able to access data whenever I so please, 200 kb/day of strictly data ‘overhead’ would add up to 6 Mb a month, way more than what I want to be paying.
UDP is not supported.
do you mean TCP and UDP difference in header size?
Hm. That’s interesting and makes sense…
Could you please explain what do you mean here? Does your hardware just push data or you also want to read data on demand?
@Dmitriy I’m not going to pretend to be an expert in internet protocols besides having a very high level undertstanding that UDP requires less data at the expense of packet validation.
I began the project by having it push data at a regular interval, and quickly discovered that this was not going to be feasible in the sub-Mb/month data usage range. So now I just read on demand, which is fine for this scenario (remote controlled sauna…) =D What I meant by ‘maintain constant connection’ is that I do not want to opt to put my hardware to sleep for a portion of each day for the sake of saving data, I would prefer just to keep it active/on/connected to cellular network and blynk server at all times. Again, with the heartbeat interval severely reduced, I think I should be good to go now.
Ok, got it. Seems reasonable.
Hi all, I thought I would give a quick update concerning the use of third party sims with the particle electron. After doing a fair amount of research, I am pretty convinced that Truphone’s International Sim is a shoe-in for the IoT world. This is based on a few factors. The Truphone sim is a pay-as-you-go style sim card, except unlike the vast majority of pay-as-you-go providers, your balance never expires!! As long as the sim card is used at least once every few months (ie turn on your electron), your balance will stay active! Secondly, the going rate for Truphone data is 0.09 cents/MB, which is relatively standard, but is billed out to the nearest 1 KB, a much higher resolution than most pay-as-you-go providers. Thirdly, it uses AT&T network here in the US, which was critical for my application seeing that I am in a relatively remote area and AT&T has by far the best coverage here. Fourthly, You can see your day-by-day data usage and the amount billed on your Truphone account, a nicety that is often lacking in smaller MVNO network websites.
The truphone international sim initial cost is a little steep however. It is $30 dollars to purchase the sim, and it comes with $15 dollars pre-loaded to your account.
Now the one gripe I have, which I am not positive if its a Truphone network issue, or possibly a hardware issue. When I am running my particle electron with the Truphone sim, every 24 minutes my electron disconnects from the the cell tower, loses its data connection, but then immediately reconnects and re-establishes connection, regardless of how much data I have transmitted in that timeframe. From an application functionality standpoint, this is not a real big deal. But the overhead in data usage this causes is a little annoying. If I have my electron running all day, connected to blynk server with a 10 minute heartbeat, and zero additional traffic pushed to or from the hardware, I still use approximately 300 KB per day, which I believe is all the data it takes to talk to the cell network every 24 minutes and re-establish connections with the cell tower and then with the blynk server.
So currently, my typical daily charge pushing data every 10 minutes is $0.04. So even with the relatively large background data usage, I would expect to get approximately 375 days of usage from the initial $15 charge (which actually cost $30 dollars the first time). Still beats the particle going rate and you get WAY more data (167 MB per $15 charge used at your own discretion as compared to Particle’s 1MB/month for $3)
I like your idea of using Truphone evancraig22.
But, what’s the easiest way to edit the BlynkConfig.h file to a greater Heartbeat time?
do i need to include the
#define PARTICLE_KEEPALIVE 20
or just the
#define BLYNK_HEARTBEAT 60
and what the particle_keepalive does in this case ?
if i increase it the timed out time will be increase? and connection work better?
And so What is this part?
// Uncomment to force-enable 128 virtual pins
Yes, and maybe
Forces use of all 128 vPins on smaller Arduino boards that otherwise would not recognise that many.