Introducing Blynk Energy - first paid services

Dear Blynkers,

Today we are introducing :battery:Blynk Energy.
When you update Blynk app today, you’ll notice that every widget and some features have an :battery:Energy indication. iOS users would need to wait for a couple of days, sorry.

:ok_hand:How it works:
• As said, each widget will need :battery:Energy to operate
• When you delete a widget, it gets :recycle: “recycled" and you get energy back.- Stay​:herb:!
• If you are running out of power - get more from the Energy Store

No hidden payments or recurring payments.

:sun_with_face:You will get some free Energy to power up your next experiment.

All of your existing projects and widgets stay with you.

We hope that it will power up Blynk development and help us to make it even better.

If you like Blynk and would like to see new features, widgets and other cool ideas we have in mind - support us by making your first Energy purchase


Please provide a cost table that cleary outlines how much “energy” each widget will consume and how much money a unit of “energy” will cost. If this cost structure becomes convoluted like a shady insurance company, airline, or cell phone provider; this relationship between Blynk and its users is over.

1 Like

You can check by just downloading Android app – everything is there. We tried to be as transparent as possible.

Is it true if I want to play around and remove and add widgets to tweak my project removing a widget only gets a portion of the cost back? I’m not always sure witch widgets will work for me when designing a project.

1 Like

I like the idea but i also have @julieisdead concerns. Maybe energy return decay over time?

@julieisdead @glorifiedg 80% of Energy is returned back on widget removal (but only for newly created projects).


@Pavel … must say i like the idea. It’s a nice middle ground for all the concerns about the subscription there has been (you sneaky guys have probably planned it all along, presenting the worst solution just to make way for the real one ;):smile:

But one thing. Will engery used for a widget in an “old” project be lost forever? i just tried with a cheap LED. couldn’t recycle it.


As mentioned here:

thanks… missed that one :slight_smile:

I could though see a possible downside about this way of running it. Im in the middle of testing a new project. And i found myself adding and deleting some widgets quite a few times just for testing different mehtods. Would you consider some kind of “full refund period” if you add a widget just for some testing purpose. I know it probably isn’t a big issue but still i think it would be nice.


Think the idea is good, but it was poorly documented in the update email. This is still not clear to me. Let me use an example. I see I have 2000 energy. If I make a single app with 1 button (costs 200 energy), does that mean that I can run that app free forever? Or does are there additional costs with using the app where the remaining 1800 energy drains? If so, can you provide us with info as to how that energy drains? by the hour? day? Usage? what?

Again, I like the idea, but you have not painted a clear picture as to what we can expect to pay over time by using an app.


1 Like


You are just overthinking. What you see is what you get. Just 2 rules, no hidden payments or recurring payments.

If some service like this will be added, for example: SMS - we will definitely inform about that.


This is very nice idea. thank you for sharing.
Our model is new and will be adjusted over time, for sure!


I also would like to have some time to play with a widget before committing. @iclimb has a great idea. I must have redesigned my project a dozen times before I settled on a layout. It would hurt if I lost 20% of the money I spent on unused widgets.

1 Like

@Pavel. Thanks… Seems ok. However, I like @iclimb’s idea as well. I recycle widgets many times before I land on a final project. There should be some grace.


If 1,000 Energy cost you $1, then trying the most expensive widget would cost you < 10 cents
If it’s a button, it’s less then 2 cents …

I wouldn’t blame us for thinking into this too much, but rather own up to the misleading verbiage that was used. “As said, each widget will need :battery:Energy to operate” this assumes it cost energy to run a widget over a certain period of time. When it actually sounds like we only pay upfront per widget per project. But that could be just me reading too much/too little into this pricing structure.

1 Like

Pay as you go looks to me like a fair way of heading.No Monthly charges or subscriptions and your in control of how much you spend/use widgets. If I understand correctly there’s nothing to stop you from having a couple of dashboards with one or two of each widget and keep them just for testing and only commit to a project when your ready?


I’m just trying to wrap my head around the pricing model and it’s reason. I understand how it works, just not the why. From a pure cost standpoint (and granted we may be talking about cents here): Why is money “lost” when a widget is recycled? Is there a resource that’s burned, or a cost incurred by Blynk each time this happens? Or is this intended just to discourage people playing around with it to much… which leads to the question: why?

One of the comments eluded to this structure being some kind of compromise… it being in lieu of a flat monthly cost. I do like that but I just don’t understand the philosophy of not regaining the full value of a widget after it’s recycled.

I apologize if this pricing model is standard in some other places and I haven’t run into it. I’m still planning on using the service, of course, but I just want to be able to explain/justify it to those I recommend it to.

I like the idea of PAYG much more than the previously discussed model but I think an API model would have worked better. e.g. The Dark Sky Forecast API. Their pricing is 1k API calls for free, then $0.0001/call after that. It’s palatable for developers since it ties well to both something they can control as well as the perceived “cost” to provide the service (ignoring development, Blynk costs are going to scale pretty closely to API calls and the cost to operate the service will, hopefully/eventually, be the dominant cost driver). When designing, you can decide how “chatty” you want your project/widgets to be (pinging thousands of times per minute vs once per hour vs anywhere in the middle).

This “energy” model discourages development and experimentation. Imagine a user who builds a dead-simple project (so < $1) but with settings that ping the Blynk servers just below the throttle rate 24/7. Assuming there’s no interface changes, this user doesn’t pay again even though they’re continuing to use Blynk resources (heavily). Contrast this with the hobbyist who builds little apps for personal use, sets pings reasonably, and continues to incur cost as they tinker. Maybe it’s not a lot of $ at the end of the day, but there’s a sense of “unfair” to it.

1 Like