Clarification of Routing Events Charge

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:

image

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!