One of the attractive aspects of the Notecard is the 500 MByte 10 year data plan. Following on this thread Charge for Routing Blues now charges $0.00075 to $0.0005/event.
As I understand it this means that if my application reports via 100 byte packets (to chose a number) the cost of the data is now and additional $2,500 ((500,000,000 / 100) * 0.0005 ) over the 10 year life.
Is this correct or am I missing something?
This is also what I think. However, there is so much overhead that it will not be possible to reach 500,000 events per year. Especially if there are multiple connection / disconnection cycles. A more realistic maximum would be around 100,000 events per year.
To have a cost of $ 0.0005 per event, you must include a project cost of $ 499 per month. The cost difference represents approximately 24,000,000 events per year. Thus, it takes a fleet of more than 240 devices for it to be worth it (on the other hand, it has other advantages that come with this monthly cost).
So if we choose 100,000 events per year at $ 0.00075 per event, we end up with an additional cost of $750 after 10 years.
Thatās why I find marketing biased. Sending a 500MB of cellular data to the notehub is useless if it stays there. We should rather see something like this:
This model of service is not beneficial when there are a lot of events. It is especially advantageous with a use case where there are few events. With 2 to 5 routed events per day, we now find a cost of $6 to $14 after 10 years.
Well, weāll see if anybody from Blues chimes in. I know my use case is no longer economically viable. In fact I canāt really see an economically viable use case if this is the pricing. IoT is only enabled by affordable communications: once you take that away, there isnāt much left.
Fortunately my hardware was designed to be stacked for space and the Notecard is on a standalone board with a few other parts so I can investigate alternatives.
Unfortunately, I spent a lot of time and money figuring everything out and get boards made. Lesson learned.
Brian & Alec,
Thank you for your thoughtful analysis. Let me please share a bit of background, and ask your assistance if I may.
When we updated the pricing, we needed to do so to match our actual COGS for low-volume projects. (Because of some things in our back-end implementation, it is much, much less expensive for us to operate high volume projects than low volume projects.)
We are committed to delivering highly-favorable consumption-centric IaaS-style pricing for event data flow, and we also need to run a viable and healthy business. This was at the core of the changes. As we do more and more refinement of our implementation over time, I expect that we will pass savings on to you.
As you have pointed out, the simplicity of the currently-published event pricing model does not work for high-volume usage. You laid this out quite well, although I have one small ask below.
Since those prices were published, we have been working closely with several very high-volume enterprise customers to refine a very simple discount schedule based on event volume that is both sensitive to our COGS and also which matches the volume deals we have actually been signing.
We will be revising the pricing pages to show these simple discount schedules soon, we are very happy to share our work-in-progress with you privately to get your feedback before things are locked. Please do drop a note here if youāre interested in doing so, because I suspect that youāll find them quite good.
I do have one ask of you, if I may. Your methodology of starting with 500MB and dividing things down into an āevent countā by just using 100 bytes per message is certainly one way to do simple math, but respectfully it doesnāt match the reality of how weāve seen customers deploy the product. To take your method to the extreme, if a customer has an existing LoRa application that sends 10-byte payloads a few times every day (as LoRa applications tend to do), they arenāt going to consume 500MB in 10 years. Should they be redesigning their app to send 10 messages per minute, rather than a few times a day, just to consume the 500MB?
We chose to include 500MB and the event-based pricing model to reflect the fact that both of them work super-well for the vast majority of narrowband use cases, which tend to send relatively small amounts of data occasionally, conserving power between those transmissions. There are certainly many high-bandwidth or high-rate or streaming applications where different pricing models (and different infrastructure architectures) may be appropriate.
The example you laid out would send a message about every 5m, continuously for 10 years. This certainly isnāt unreasonable in any way, but obviously this would be connected to the cell network constantly and obviously it isnāt going to be battery powered.
What would be incredibly helpful for us is to understand more details about the use case. The nature of the device, how it is powered, why it needs to report every 5m, the needed latency from an event happening until it appears in your cloud, etc. The better we understand use cases, the more we can make sure that our architecture and our pricing is best tuned for reality.
Can you please share this info privately with our team?
Thank you for your patience with us; weāre listening and learning as we grow.
Ray
The point I wanted to bring here is that your philosophy āNo monthly device charges or hidden feesā is not the reality if we want to get the data out of the notehub (and we want it because it becomes useless if we leave it there).
I canāt speak for @BrianP but for my part, I was working on a tracking device last year that requested near real-time messages (every 9 minutes) and it was viable with a price of $ 0.000003 per routed event but when the prices were multiplied by 250 to become $ 0.0075, I gave up on the idea of using the notecard. I was lucky that this happened while I was in the design phase.
I understand you have to pay the bills but please donāt let people think they are paying $49 and that they are good for 10 years ā¦
Iād be really, really grateful for sample use cases that model data / routing costs upon which reasonable assessments could be made for planned projects.
My understanding is that routing is just one moving components of the final cost.
What I find even more difficult to predict is the data overhead of the cellular communication.
It is easy to measure and control the size and frequency of the data packages you are intended to send. The data consumption of the cellular overhead, however, is far less transparent.
It would be incorrect to assume that the maximum number of events that the included data allows to execute simply equals the division of 500MB by the size of one data packet, because it ignores the cellular overhead.
Iād appreciate if someone could help to model reasonable calculations for future projects where clients want to choose from alternative scenarios.
Hey @LBBD, this is a good idea and reasonable request. Iāll add this to our content backlog and we can have something available in early December that weāll include at dev.blues.io and share here.
Thank you, much appreciated!
Hi folks,
I wanted to circle back on this thread and make sure everyone is aware that weāve made some improvements to Notehub pricing that are relevant to this discussion: removing per-project platform subscription fees and limits, a consumption-based event model, and free credits for each account. You can read more here and here, and let us know if you have any questions!
Brandon
Hi @bsatrom,
Iām having some trouble understanding the billing model so Iām hoping you can clarify.
Given a project with a single device that generates 100 events per day I have the following options to get the events into my backend:
Scenario A
Scenario B
https://api.notefile.net/v1/projects/<projectUID>/events one time per day retrieving all 100 events in a single callAre my assumptions accurate?
Does an events call also count towards the 1000 API requests = 1 CC criteria?
I assume authentication counts towards that 1000 API request limit; if so what is the lifetime of the session token?
Hi @CoryCharlton, and welcome to the Blues community 
Are my assumptions accurate?
Your assumptions for scenario A are correct. Scenario B, however, would also cost 100 CC, as we charge 1 CC for each event returned by the /events API.
Does an
eventscall also count towards the 1000 API requests = 1 CC criteria?
No
I assume authentication counts towards that 1000 API request limit;
Correct.
if so what is the lifetime of the session token?
Session tokens only expire when you generate a new token, so you can generate one token and use it forever if youād like.
Let us know if you have any other questions.
TJ
Thanks for clarifying @tjvantoll,
The wording ofā¦
Event API retrieval āpulledā from Notehub
ā¦was not clear but I did sort of assume it was per event retrieved as it didnāt make sense to have a billing workaround like I suggested.
That said it might be more clear if it was worded like:
Event āpulledā from Notehub Event API
It was the word āretrievalā that made it ambiguous to me.
In any case it sounds like the route option, in additional to rate-limiting/batching my data points, is the most effective way to manage cost.
Thanks for the feedback @CoryCharlton. I agree the wording could be more clear so Iāll follow up on that.
In any case it sounds like the route option, in additional to rate-limiting/batching my data points, is the most effective way to manage cost.
Itās a good default. If youāre concerned about CC usage we have a lot of options for filtering exactly what data you want to route.
For advanced filtering we even have a $doNotRoute() function you can use through JSONata (Using JSONata to Transform JSON - Blues Developers). That function allows you to do things like, only route this event if a certain data point exists, so you have a lot of control.
TJ