Picture this. You’ve deployed coverage on the Helium Network using one of the approved Hotspots. As is common for members of The People’s Network, you quickly realize that deploying sensors and conferring utility on the coverage you’ve created is the next best step. You decide to keep it simple and start capturing temperature and humidity data in your neighborhood. The LHT65 from Dragino is an excellent option for this. You start slow, but before you know it you’ve got an entire fleet of sensors transmitting real-time temperature and humidity data. And to make use of all this, you’ve built a simple application for capturing hyper-local environmental data monitoring in your neighborhood. Life is good. But could it be better? Yes.

Enter Streamr. Streamr is a decentralized platform for real-time data. In short, the Streamr protocol lets you transport, broadcast, and monetize data. There is a massive market for well-organized, specific data — with IoT data arguably being the biggest type. In addition to the base Streamr protocol, they’ve built Data Unions — a higher-level framework that enables large groups of people to productize and find markets for data they produce together. And all transactions are facilitated by $DATA, Streamr’s ERC-20 compatible token that makes settlements and distribution of data streams simple and decentralized.

Recently the team at Streamr put together a simple, powerful demo to showcase the potential of marrying Helium, the world’s largest and fastest-growing LoRaWAN network, with Streamr. What this means is that now you can distribute and monetize that hyper-local environmental data, and potentially endless other data streams you could produce on the Helium Network.

Connecting Data from Helium to Streamr

Here’s how it works. In a nutshell, data from sensors deployed to the Helium Network is piped to the Streamr Network via Helium Console’s MQTT integration and the MQTT interface on Streamr nodes.

Immediately after data flows into the Streamr Network, all the options in the ecosystem become available, such as broadcasting the data to applications, packaging it as a data product on the Marketplace, or joining a Data Union to package and sell the data with other, similar data. Let’s take a look at how to configure the integration in practice.

First, you need a sensor within range of the Helium Network. It will be able to join the network and show up in the Helium Console. In the demo, we had an LHT65 LoRaWAN Temperature & Humidity Sensor connected to the Ambitious Ocean Panda Hotspot located in Helsinki, Finland.

Here’s what our LHT65 looks like when it’s onboarded to the Network.

And shortly after, here’s what it looks like when data flows in:

Once connected, you’ll also need to run a piece of software to bridge data to/from the Streamr Network. At the moment, you need the helium-mqtt-adapter which will bridge incoming MQTT data to Streamr nodes run by others. Later this year you’ll be able to actually run your own Streamr node instead, which will ship with an MQTT interface also suitable for this setup.

Once you have your device and the adapter up and running, you’re ready to create a stream in Streamr Core. On your way there, you’ll need an Ethereum wallet like MetaMask, as this will provide you with an identity in both the Streamr and Ethereum networks. The stream you create will be the stream that contains your data once the integration is complete. In the stream settings, you can also enable storage to keep a history of the data.

The integration will leverage the off-the-shelf MQTT integration available in the Helium Console, so the next step is to go to Integrations and add MQTT. Configure the integration as follows:

• Integration name: “My Streamr node” (or whatever you want)
• Endpoint: an URL pointing to the IP address where you’re running the helium-mqtt-adapter. For example mqtt://username:password@1.2.3.4. Here, username and password are environment variables you set earlier when configuring the helium-mqtt-adapter to secure it.
• Uplink Topic: copy-paste here the ID of the stream you created in Streamr Core, for example 0x…/helium/lht65.
• Downlink Topic: paste here the same stream ID as above.

Finally, in the Helium Console, create a Label and add your Device and Integration to it. Here’s an example:

As soon as the sensor sends new measurements, the data points will flow to the Streamr Network, appearing in real-time in the stream inspector, as shown below:

If things are working so far, you’re basically done! One additional recommendation though: the sensor is sending its readings in encoded form by default, so to make your data easier to consume, you probably want to convert those values to human-readable form. To do this, you can add a Function in the Helium Console, and apply it to the Label you created earlier. The exact code of the Function depends on what sensor you’re using, but here’s the code for the LHT65 sensor we used in the demo.

Opportunities in the Streamr ecosystem

Now that your data stream is connected to Streamr, you can use the whole ecosystem to your advantage and make your data go further. You can, for example, connect the data to web apps in real-time using the client library for JS, plug it into Grafana for visualizations, connect to IFTTT for automation using community-built tools, or connect the data to smart contracts with Chainlink and soon API3.

For data monetization, you can wrap your stream(s) into a product and sell it on the Streamr Marketplace. Other people will then be able to pay you a reward of your choosing for continuous access to your streams. If the data from your devices alone is not enough to make a compelling product, you can join (or start!) a Data Union, a framework that allows you to join forces with others producing similar data, and “crowdsell” it together using a revenue sharing model implemented by Data Unions.

By realizing this integration, both Helium and Streamr can provide their users with a fully decentralized and trustless global data infrastructure for a “first-to-last-mile” IoT pipeline. Users gain benefits from the network effects of composable ecosystems, and no longer need to accept vendor lock-in or privacy issues inherent with centralized cloud services in order to connect their data to applications and to data consumers. Instead, users can leverage networks made for, and operated by, the people. They stay in control of the data they’re producing, and they gain the opportunity to participate in the emerging data economy.

Helium & Streamr: An End-to-End Pipeline for Connecting, Delivering, and Monetizing IoT Data was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Update: This blog details connection to the centralized and deprecated Streamr Network. Checkout the new blog detailing the connection between the decentralized Streamr Network and Helium: https://blog.helium.com/helium-x-streamr-ea89c4b61a14

Picture this. You’ve deployed coverage on the Helium Network using one of the approved Hotspots. As is common for members of The People’s Network, you quickly realize that deploying sensors and conferring utility on the coverage you’ve created is the next best step. You decide to keep it simple and start capturing temperature and humidity data in your neighborhood. The LHT65 from Dragino is an excellent option for this. You start slow, but before you know it you’ve got an entire fleet of sensors transmitting real-time temperature and humidity data. And to make use of all this, you’ve built a simple application for capturing hyper-local environmental data monitoring in your neighborhood. Life is good. But could it be better? Yes.

Enter Streamr. Streamr is a decentralized platform for real-time data. In short, the Streamr protocol lets you transport, broadcast, and monetize data. There is a massive market for well-organized, specific data — with IoT data arguably being the biggest type. In addition to the base Streamr protocol, they’ve built Data Unions — a higher-level framework that enables large groups of people to productize and find markets for data they produce together. And all transactions are facilitated by $DATA, Streamr’s ERC-20 compatible token that makes settlements and distribution of data streams simple and decentralized.

Recently the team at Streamr put together a simple, powerful demo to showcase the potential of marrying Helium, the world’s largest and fastest-growing LoRaWAN network, with Streamr. What this means is that now you can distribute and monetize that hyper-local environmental data, and potentially endless other data streams you could produce on the Helium Network.

Connecting Data from Helium to Streamr

Here’s how it works. In a nutshell, data from sensors deployed to the Helium Network is piped to the Streamr Network via Helium Console’s MQTT integration and the MQTT interface on Streamr nodes.

Immediately after data flows into the Streamr Network, all the options in the ecosystem become available, such as broadcasting the data to applications, packaging it as a data product on the Marketplace, or joining a Data Union to package and sell the data with other, similar data. Let’s take a look at how to configure the integration in practice.

First, you need a sensor within range of the Helium Network. It will be able to join the network and show up in the Helium Console. In the demo, we had an LHT65 LoRaWAN Temperature & Humidity Sensor connected to the Ambitious Ocean Panda Hotspot located in Helsinki, Finland.

Here’s what our LHT65 looks like when it’s onboarded to the Network.

And shortly after, here’s what it looks like when data flows in:

Once connected, you’ll also need to run a piece of software to bridge data to/from the Streamr Network. At the moment, you need the helium-mqtt-adapter which will bridge incoming MQTT data to Streamr nodes run by others. Later this year you’ll be able to actually run your own Streamr node instead, which will ship with an MQTT interface also suitable for this setup.

Once you have your device and the adapter up and running, you’re ready to create a stream in Streamr Core. On your way there, you’ll need an Ethereum wallet like MetaMask, as this will provide you with an identity in both the Streamr and Ethereum networks. The stream you create will be the stream that contains your data once the integration is complete. In the stream settings, you can also enable storage to keep a history of the data.

The integration will leverage the off-the-shelf MQTT integration available in the Helium Console, so the next step is to go to Integrations and add MQTT. Configure the integration as follows:

• Integration name: “My Streamr node” (or whatever you want)
• Endpoint: an URL pointing to the IP address where you’re running the helium-mqtt-adapter. For example mqtt://username:password@1.2.3.4. Here, username and password are environment variables you set earlier when configuring the helium-mqtt-adapter to secure it.
• Uplink Topic: copy-paste here the ID of the stream you created in Streamr Core, for example 0x…/helium/lht65.
• Downlink Topic: paste here the same stream ID as above.

Finally, in the Helium Console, create a Label and add your Device and Integration to it. Here’s an example:

As soon as the sensor sends new measurements, the data points will flow to the Streamr Network, appearing in real-time in the stream inspector, as shown below:

If things are working so far, you’re basically done! One additional recommendation though: the sensor is sending its readings in encoded form by default, so to make your data easier to consume, you probably want to convert those values to human-readable form. To do this, you can add a Function in the Helium Console, and apply it to the Label you created earlier. The exact code of the Function depends on what sensor you’re using, but here’s the code for the LHT65 sensor we used in the demo.

Opportunities in the Streamr ecosystem

Now that your data stream is connected to Streamr, you can use the whole ecosystem to your advantage and make your data go further. You can, for example, connect the data to web apps in real-time using the client library for JS, plug it into Grafana for visualizations, connect to IFTTT for automation using community-built tools, or connect the data to smart contracts with Chainlink and soon API3.

For data monetization, you can wrap your stream(s) into a product and sell it on the Streamr Marketplace. Other people will then be able to pay you a reward of your choosing for continuous access to your streams. If the data from your devices alone is not enough to make a compelling product, you can join (or start!) a Data Union, a framework that allows you to join forces with others producing similar data, and “crowdsell” it together using a revenue sharing model implemented by Data Unions.

By realizing this integration, both Helium and Streamr can provide their users with a fully decentralized and trustless global data infrastructure for a “first-to-last-mile” IoT pipeline. Users gain benefits from the network effects of composable ecosystems, and no longer need to accept vendor lock-in or privacy issues inherent with centralized cloud services in order to connect their data to applications and to data consumers. Instead, users can leverage networks made for, and operated by, the people. They stay in control of the data they’re producing, and they gain the opportunity to participate in the emerging data economy.

Originally published at blog.streamr.network on March 29, 2021.

Helium & Streamr: An End-to-End Pipeline for Connecting, Delivering, and Monetizing IoT Data was originally published in Streamr on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post introduced Data Credits, a fundamental piece of the Helium Network that is about to go live. There is a FAQ at the bottom of the post if you want to skip the witty prose.

Helium historians will recall that the original Helium Whitepaper (which some have called “the greatest crypto whitepaper”) talks a fair amount about the native protocol token of the Helium blockchain — now called “HNT”, but called “ATOM” and “HLM” at various times — and how it would be used for paying the various fees on the Network. As described in section 5.3, “Types of Fees in Helium”, the token was to be used to pay for three distinct types of fees:

• Transport Fees: Sending sensor data to and from device;
• Transaction Fees: These are your typical blockchain fees, like sending HNT from wallet to wallet;
• Staking Fees: Adding a Hotspot to the blockchain, asserting its location, buying a blockchain OUI, and buying a blockchain Subnet;
• Blockchain Routing Fees: Buy OUIs and subnet blocks

Since launching the Network in August of last year, Helium Inc has been paying staking fees on behalf of our users, and we’ve kept the transaction and transport fees at zero. This was primarily for two reasons:

1. We didn’t want to inhibit growth by charging fees on day one;
2. The infrastructure to enable fees for transactions was complicated and getting the network running, growing, and stable took precedence.

The Whitepaper describes the native protocol token of the Helium blockchain being used to pay for fees directly. While that would work, we ultimately landed on something called a Data Credit, which is derived from HNT in an on-chain burn process. (We’ve been talking about Data Credits for some time, and they are already documented in a few places.)

So, to date, when you’ve sent data from a temperature sensor to your AWS IoT Core instance, or transferred some HNT to your sister, or added a Hotspot to the blockchain, fees were paid on your behalf, in the background, by Helium Inc. But given the maturity of the network and the blockchain, we are now ready to deploy a fully implemented transaction fee system.

This is a huge development for the Network.

Where do DCs come from? Why do we need them?

In short, they come from HNT. The blockchain produces roughly 5MM HNT per month. In turn, DCs are produced by burning HNT at a conversion rate defined by two on-chain variables:

• The price of DCs in $USD — fixed at $0.00001 per 1 DC
• The price of HNT in $USD, as established by the HNT price oracle mechanism

To figure out how many DCs a given amount of HNT will produce, simply divide the amount of HNT (priced in $USD terms) by the fixed DC price of $.00001. For example, if the HNT/$USD Price is $0.315, burning one HNT will produce 31,500 DCs. Once burned, that HNT is gone forever, taken out of the global supply, never to return. (For the curious reader, this system of burning a fixed amount HNT to produce a variable amount of DCs is based on something called Burn and Mint Equilibrium.)

Data Credits are like Cell Phone Minutes

Once created, DCs are non-transferable and can only be used by the address that took delivery on them. (The HNT / DC burn transaction happens in the name of a specific wallet address.) And because they are non-transferable, they cannot be speculated on.

Remember when you used to buy cell phone minutes? DCs work the same way. You buy a certain amount, use them, and buy more as needed. You always knew how many minutes you had to spend, and the cost was fixed. We designed DCs to operate in precisely the same way.

How many Data Credits will a specific transaction cost?

Here’s what is currently planned for transactions and their specific costs (in DCs and their $USD equivalents):

(Note: Any Helium-manufactured Hotspot will always come pre-provisioned with enough Data Credits to add the Hotspot to the blockchain and assert its location (one time). The purchaser is not required to pay these fees. There is a full breakdown of how transaction fees work and how they get paid on the Helium Developer Docs.)

Seeing Data Credits Being Used

If you’re one of the thousands of people that are part of our community Discord Server (and have been paying attention), you’ve likely already seen the DC infrastructure come online and be integrated into the blockchain and network monitoring tools.

• The Helium blockchain explorer now shows a trailing seven day count of both the total LongFi Packets across the Network (these are packets from sensors using the Network); and the total number of DCs spent over the past seven days. We’re already well into the millions for both of the metrics and they are growing exponentially.
• The new on-chain mechanism that allows for data credit metering and spending is called a “State Channel”. (These are modeled on how Ether does State Channels. We’ll write a full post on Helium State Channels as time allows) And we’ve added the ability to view State Channels and DCs used / Packet transferred in the Explorer. A summary of all the State Channels and their DC statistics can be viewed here. And here’s a full look at a specific state channel and all the DCs spent through it.

And in addition to this, we fully expect the community to produce better DC monitoring and visualization tools. They are usually a few steps ahead of us here, pestering us for docs and APIs before they are finished (and this is why we love you, James).

What’s Next?

As mentioned above, we’re about to make Data Credits live. For the exact timing, and all other sorts of new hotness, join us in the Helium Discord Server.

Complete FAQ is below. Thanks for being a part of Helium.

Helium Data Credits FAQ

Device data transfer fees

Charging devices to transfer data and reward Hotspot owners that forward device data is a big milestone that is approaching soon.

Currently users of the network can transfer data for free, however, in the coming weeks any device that transfers data over the network will need to use Data Credits.

When will I need to pay for data device transfer?

We are targeting the end of July AFTER we deploy the ability to purchase Data Credits with credit cards directly from Console.

How much packet data can I send with 1 Data Credit?

There will always be one DC per transmission minimum. One Data Credit equals 24 bytes of payload. So a packet may be larger with other networking information, but if the payload is 24 bytes of data or less, it still costs one Data Credit.

What if my payload is more than 24 bytes, how many Data Credits will it cost?

Any number that exceeds 24 bytes is rounded up, so a packet with 25 bytes would cost the same as one with 47 bytes, i.e., 2 Data Credits. See table for examples:

What about Downlink packets? Do they cost Data Credits too?

No. Only uplinks cost Data Credits.

What about initial Join Uplink?

Yes, these will cost Data Credits as well, one for Join Uplink. Data Credits are not needed for ACKs.

How can I acquire Data Credits?

You can directly acquire Data Credits using Console either using a credit card or converting HNT. We are targeting the Console Data Credit purchase with credit cards for 7/13.

To be clear the only way Data Credits are created is by converting HNT, however, Helium Inc. is making it easy for customers to purchase Data Credits with a credit card.

During the credit card purchase process Helium Inc converts the required number of HNT into Data Credits for the customer and deposits them into their Console account.

When can I acquire Data Credits using HNT?

After the work for credit card payment has completed, the team will focus on the capability to use HNT to acquire Data Credits. We anticipate the work will be completed in July.

Will I still need to pay to test devices?

Regardless of production or testing if you’re sending data over the network you will need a Data Credit balance.

Every signed up Helium Console account will receive an initial free 10,000 Data Credits total for use within a single Organization defined during Console signup.

After a user acquires Data Credits either with a credit card or HNT, these free Data Credits will be added to the overall Data Credit pool.

Existing Console accounts will also receive this free balance. If an existing Console account has multiple Organizations then the Organization with the most devices will receive these Data Credits.

Who pays the credit card fees? For example if I pay $10 how much of that will get converted to Data Credits?

Helium pays the credit card fees.

Is there a minimum amount I need to pay for Data Credits?

Yes, the minimum you can add both initially and for auto renewal is $10.

What happens if I don’t have enough Data Credits?

If your balance is zero your devices will be unable to transfer data on the Helium Network. Device data will be dropped and not be forwarded onto their desired destination. We’ll notify you when your balance is at $5 and when it reaches $0.

Is there an autopayment option to avoid running out of Data Credits?

Yes, in Console you can define an autopayment option when your balance reaches the equivalent of $5 worth of Data Credits remaining.

Are taxes included in the price?

No. The pricing does not include taxes. We may be required to collect taxes in certain jurisdictions where local regulations require us to collect them.

Do Data Credits expire?

No. Data Credits never expire.

Can I share my Data Credits with someone else or to another Helium Account or resell them?

No. Data Credits are non-transferable, are not resellable, and cannot be used for anything other than paying for the blockchain fees listed above.

Can I convert Data Credits back to HNT?

No. HNT to Data Credits is a one-way conversion. It is not possible to convert Data Credits to HNT.

Can I transfer Data Credits to other Organizations?

Yes. Any Data Credits you acquire either with a credit card or with HNT can be shared among other Organizations. However, initial Data Credits included free with Console for use within a single organization.

Once you acquire Data Credits with a credit card or with HNT, the free Data Credits will be automatically added to your overall pool and can be transferred to other Organizations.

What about users who want to try or test and not enter a credit card?

In the coming weeks, to minimize friction from users trying Console and the network we’ll provide 10,000 Data Credits to:

• new user sign ups
• existing Console users

Are there any tax or legal implications of these free Data Credits?

We advise users to consult tax or legal professionals on any implications of receiving these free Data Credits.

What if I set up multiple integrations? Will I be charged for multiple packets?

No. Users will only be charged for the initial payload sent from the device to the Hotspot even if it is forwarded to multiple integrations.

Data Credits Will Soon Be Live on the Helium Network was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is the Helium Hotspot? What does it do?

The Helium Hotspot is a small hardware device that creates a large wireless network for devices that use Helium’s network. Think of it like a Wi-Fi router, but for devices sending small amounts of data over long ranges. These devices are part of what’s usually called the IoT — or the “Internet of Things.”

Why deploy a Hotspot?

Hotspots provide internet connectivity for all sorts of IoT devices: bikes, scooters, temperature sensors, location trackers for pets, elevators, wildfire sensors, and much more. Your Hotspot earns a new cryptocurrency called Helium for providing network services to these devices.

How do I deploy the Hotspot? What are the requirements for running it?

It’s simple. Just plug it into a power source and connect to Wi-Fi. If there’s no Wi-Fi available you can directly plug into an Ethernet port. Once this is done, use the Helium Mobile app to finish the setup process.

Where is the ideal location for the Hotspot?

Hotspots like to be deployed high up, overlooking wide-open spaces. If you have a house or apartment building with multiple floors, aim for the highest floor with a window. Ideally, your Hotspot has a clear view of the sky.

Avoid putting the Hotspot in locations where it can’t see the outside world: in basements, in cabinets, behind TVs, metal screens, or ‘cyberglass’ in skyscrapers and things like that.

How far apart do Hotspots need to be placed?

Hotspots should not be deployed too close to one another. A good rule of thumb is to provide a minimum distance of 300 to 500 meters between Hotspots though this could vary depending on the environment (in a dense city closer, and in a more rural environment farther).

How much will it cost me to run?

There is nearly zero cost. The Hotspot uses a small amount of power, roughly 5W at peak. This is less than a standard LED light bulb. In a city like San Francisco, it will cost you less than $.05 per day to run.

How do I maintain my Hotspot?

You don’t need to do anything. The Hotspot runs quietly in the background, creating coverage and routing data. Just make sure it’s always plugged into power and connected to Wi-Fi. The mobile app allows you to see status for a single or multiple Hotspots.

Helium Hotspot 101 was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Helium recently announced that the next generation of our network will be built on a blockchain. It’s a new blockchain we’ve designed from the ground up to cater to physical assets in the real world while also turning the idea of wasteful proof of work on its head. For more details on the Helium blockchain, start with this blog post from Andrew Thompson then go really deep with the Helium Whitepaper.

When talking through our plans with existing customers, prospects, and other interested parties, there is inevitably a point in the conversation where the line of questioning goes something like this:

“Is your blockchain scalable? Won’t my sensor data take forever to arrive while you mine blocks? The bitcoin and Ethereum blockchains have trouble scaling transactions. How will yours be any better?”

These are good questions. Even casual observers of bitcoin and Ethereum, arguably the two most visible blockchains, have seen stats and headlines about their transaction rates. At the time of writing it was roughly 3.3 and 9.2 per second, respectively. So how will the Helium blockchain do any better? How will it scale when millions of devices try to send sensor data across the network in parallel?

Machine Application Data and Blockchain Transactions Are Different

To answer these questions, it is important to note that within the Helium network there are two subsystems working in parallel:

• The subsystem that routes what we can call machine application data;
• The Helium blockchain itself.

We’ll examine both of these and their scalability characteristics in a moment, but the main takeaway is that the data sent from sensors gets routed in near-real time to your cloud-based applications while the Helium blockchain is processing the related transactions asynchronously.

A Quick Primer on the Helium Network

Before we move any further, let’s review a few high-level components of Helium’s network design. Read the full Whitepaper for a complete discussion of these, but most of the major components are as follows:

• Machine — Also called end node, sensor, device, etc. Machines send and receive data using the LongFi protocol. For example, a machine could be a water cooler transmitting location and fill-level data periodically.
• LongFi — A new, open source, wireless networking protocol designed for machines that need to send encrypted data over long ranges.
• Hotspot — Physical hardware that creates wireless coverage for machines using the LongFi protocol while also mining on the Helium blockchain and producing Helium tokens for operators.
• Router — Cloud-based applications that receive packets from machines via Hotspots and route them to appropriate destinations such as an HTTP or MQTT endpoint. They also act as full nodes for the blockchain network.
• Helium blockchain — The decentralized transaction processing system optimized for physical-world machines that runs across Hotspots and routers.

With these in mind, let’s look deeper at the two subsystems mentioned earlier and their scalability characteristics.

Machine Application Data

Machine application data can be thought of as data your sensors send from the edge. This is your application payload data, captured by the devices you have deployed in the field. Typically this data powers cloud-based applications that expect data in near real time. As such, it’s important to minimize the latency between a sensor reading and that data arriving at your data store or analytics application. Here’s how this works in the Helium network:

Imagine, if you will, a water cooler equipped with a sensor to determine the level of water in real time. Your sensor takes readings every 30 minutes, and the onboard Helium module and SDK converts that sensor reading into an encrypted RF packet that gets transmitted via the LongFi protocol.

A Hotspot in range receives this packet, and using the packet’s header data, determines which router should receive the packet based on data stored on the Helium blockchain. Once this is determined, the Hotspot forwards that packet onto the target router in exchange for a negotiated amount of Helium token, and the transaction is complete. The entire process takes milliseconds. Put another way, the speed of machine application data transmission from the edge to the cloud is as fast as the wireless link from the sensor to the Hotspot and the backhaul link from the Hotspot to cloud can take it.

Helium blockchain transactions

At the same time the network is routing machine application data to cloud-based applications, Helium Hotspots and routers are handling many transactions (both in terms of type and volume) that make up the Helium blockchain.

To grossly simplify the main functions of the Helium blockchain (again, read the whitepaper for full details), it’s responsible for recording and verifying transactions involved in the operation of the Helium network; and enables the incentive mechanisms we believe are necessary to build the network.

The machine application data transaction we examined above is just one of many Helium blockchain transactions. Other types that could end up in each block include:

• End node asserting location;
• Hotspot registration;
• Hotspot asserting location;
• End node joins the network;
• Payment for device traffic;
• Token rewards for block mining;
• Transaction fees paid to miners after blocks have been mined.

As these happen, they are added to a block that is set to be mined by the blockchain’s pre-selected consensus group. Mining happens every N seconds. Once that block is mined, it is broadcast to the rest of the miners in the network, added to the blockchain, and the next set of transactions are queued for mining.

So how many transactions per second can the Helium blockchain do? In early testing, we’re seeing ten of thousands of requests per second. And if you want to take a look at the consensus code, grab a beer and get acquainted with our implementation of the Honeybadger BFT.

In Helium, Machine Application Data Transactions can be Asynchronous with blockchain Transactions

In the above list of transactions that are mined in each block, take special note of “payment for device traffic”. Devices, via their dedicated Helium organization and router, are responsible for paying Hotspot operators to send or receive data. This payment transaction serves as both a record that the packet traversed the network AND that the payment was remitted to the Hotspot operator. That payment may not clear instantaneously but since amounts are small, and devices aren’t able to transact with Hotspots unless their Helium organization has enough Data Credits on hand, Hotspots can forward the packet in real-time and feel comfortable they will be remitted in the future when the subsequent block is mined.

Also, in the rare instance that the Hotspot fails to deliver on its promise to route device data after the payment transaction was made, the blockchain has a record of it and it can be dealt with after the fact. Additionally, that Hotspot’s reputation will start to decay, making it less likely that devices will trust it in the future. This is comparable to how sellers on eBay are less trusted by potential buyers. (Bitcoin, by comparison, can’t allow unconfirmed transactions due to its lack of reputation system.)

So, is your blockchain scalable?

Yes. But the better question to ask is “Does the Helium blockchain slow down my ability to get sensor data from the edge to the cloud as fast as possible?” The answer is no because it’s possible to allow machine application data to pass through the network before the related payment transaction has been confirmed in a block.

In future posts and documentation, we’ll share details about the number of machine application data transactions a single Helium Hotspot can handle; and how just four Hotspots can route millions of wireless machine data packets an hour.

And expect to see precise scalability and throughput metrics for the Helium blockchain as we open source the blockchain itself.

Until then, if you want to get involved or have questions:

• Sign up for the Helium Mailing List
• Commit the white paper to memory
• Hop into the Helium Telegram channel
• Get on the Helium Hotspot Waitlist
• Email me — mark@helium.com

Helium Blockchain Scalability and Machine Application Data was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

On the November 1st we held a webinar with our partners from Google Cloud IoT and Wallo. Though 30 minutes proved to be at touch too short for the discussion (expect 45–60 minutes for future Webinars), we covered a ton of details that any company building a connected sensing and control product should find valuable.

As discussed in webinar, Wallo is beginning to take their product — a sensing and control application for communities — to market in the coming months. The foundational technology components they’ve chosen are:

• Raspberry Pi for the sensor hardware platform.
• Helium Atom Modules, Element Gateways, and Dashboard for the edge-to-cloud, bi-directional data flow.
• Google Cloud IoT Core and Cloud Functions for device / state management data processing.
• Python for sensor application logic; and Node.js to power their application logic on the cloud side.

Full details are available in the recording and slides, both available below the jump.

Our next webinar is scheduled for December 7th at 11AM PT / 2PM ET. Helium and our partner Kinetic Vision will be taking a look at what to look for when building a connected product along side a hardware/software consultancy that is brought on to help expedite the development of physical and digital components of an IoT application.

Enjoy and get in touch if you want to talk about your connected sensing use case.

Recording Now Available for November’s IoT Prototyping Webinar was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re excited to announce that we’re launching a monthly Webinar series aimed to help developers and companies build connected applications. The first will take place Wednesday, November 1st, at 11AM Pacific, and will highlight best practices for rapid prototyping of an IoT product or service.

Register here.

Mark Phillips from Helium will moderate a discussion with Travis Hagens from Google Cloud IoT along with Sunil Shah and Jimmy Chan, founders of Wallo.io. In the 30 minute webinar they’ll share how the Wallo team used Helium, Google Cloud IoT, and various other pieces of technology to accelerate turning an idea into a prototype that could be deployed in the field.

If you’re a developer or founder working on a connected product — or considering working on one — you won’t want to miss this.

Register here to join us on November 1st.

You have no excuse. The content will be top notch and, as icing on the cake, we’ll be giving away one (1) free Helium Starter kit to a lucky attendee.

Best Practices for IoT Prototyping from Google Cloud IoT, Wallo and Helium was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Can we go from unboxing new Helium hardware to sending hardware-encrypted data to an Azure IoT Hub in under five minutes?

Securing your devices and sensors should be top of mind when considering any IoT wireless and cloud platform. Sound, proven hardware-based encryption and authentication practices specifically are what should set an IoT service apart. X-509 certificates (and their sister mechanism JSON Web Tokens) are the standard when it comes to device-level authentication for big-ticket cloud providers. Both Azure IoT and AWS IoT both use X-509 certificates as their gold standard when authenticating devices. And Google Cloud IoT does the same with JSON Web Tokens.

Device-level X-509s are Very Hard

But building full X-509 cert-based encryption and authentication into a low-power embedded device and securely managing the lifecycle of these certificates can be cumbersome for even the most capable developers. For starters, here’s how Azure IoT recommends you implement security at the device level. To really drive home how hard this is to do on your own with a wireless device like the Atom on a LPWAN like Helium, your end device needs a full TLS stack, a client certificate, and a MQTT client. And you need to keep the MQTT connection alive between the device and the cloud. The radio usage alone will crush your battery and this assumes your sensor is driven by a sufficient MCU. The processing and networking requirements are enough that the official Azure IoT Arduino Library doesn’t support the Arduino UNO. And users are having issues with it (to say the least).

So, to abstract this type of complexity, we built Helium Channels. Channels are prebuilt connections to cloud services like Azure IoT, AWS IoT, and Google Cloud IoT. (You can see a full list of Helium Channels available here.) They handle all the heavy lifting: from hardware secured certificate generation and management to integration with cloud device management APIs and everything in between.

From Zero to Azure IoT in Five Minutes?

To demonstrate the power of Channels, we thought we would see just how quickly a developer could go from unboxing their Helium Starter Kit to sending fully-encrypted and authenticated data to Azure IoT using an Helium Atom riding on an Arduino UNO. Can we do it in five minutes? Let’s give it a shot. And jump to the bottom if you want to get your hands on the hardware to replicate this yourself.

Getting Started

Want to replicate this yourself? Here’s what you need:

• Grab a Helium Starter Kit. We recommend buying through Mouser. (Above we’re using the Arduino version but any will do.)
• Create a Helium Dashboard Account and read up on the Azure IoT Channel Documentation.
• Join us in the Helium Developer Slack Channel and soak it all in while waiting for your hardware to arrive.
• Ask your questions in the Hacker News forum thread

From Zero to Azure IoT in Five Minutes was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Helium is hiring a Community Engineer (our first). In this role, you’ll be leading the effort to build an active community of developers using Helium’s hardware and software to ship connected hardware applications.

About Helium

Helium was founded in June 2013 with a mission to make it easier to connect and make sense of the physical world. Our belief is that it shouldn’t be difficult to connect and manage your devices and sensors. Delivering data from device to cloud, regardless of your application architecture, should be straightforward and always secure.

We’re funded by industry leaders like GV, FirstMark Capital, Khosla Ventures, Munich Re, SV Angels, and others.

Why Work For Helium?

In addition to being part of a company that is on the on the bleeding edge of IoT, connected hardware, and distributed networking, we offer a full range of benefits and perks:

• Competitive Salary and Equity Compensation
• Unlimited vacation; and a yearly vacation stipend to make sure you actually take enough time off
• Yearly hardware stipend
• Monthly health and wellness stipend
• 100% company-paid health insurance
• Dog-friendly office, pallets of La Croix, and a Turing-complete Spotify bot.
• Company-provided lunches at our San Francisco HQ.
• Much more.

What You’ll be Doing

In short, expect to be doing anything and everything required to
expand the Helium Developer Community. This will consist of (but won’t be
be limited to) things like:

• Building — End-to-end connected hardware applications, esoteric sensors, drone race tracks, etc. Anything that helps developers and newcomers learn about and use Helium and connected hardware is relevant.
• Speaking — Conferences, meetups, internal tech talks, etc. You’ll be
  in front of developers and executives, talking about Helium and IoT every chance you get.
• Writing, Writing, and More Writing — Docs, code, blog posts, email campaigns, etc.
• Community and Customer Support — Support Helium’s community of
  developers and customers in venues like Slack, the Community forums,
  meetups, on-site, and much more.

Your Background and Capabilities

This is a role is for a software / hardware engineer who wants to spend most of their time in front of users and customers. Ideally you’ll be proficient in various programming languages, hardware platforms, cloud technologies, and RF/wireless. Some examples of these are (in no particular order):

• Arduino, Raspberry Pi, ARM mbed, etc.
• Azure, AWS, Google Cloud Platform, etc.
• JavaScript, Java, C/C++, Python, Ruby, etc.
• Wireless protocols and standards like 802.15.4, LoRa, and others.

Location and Travel

You’ll be working out of our San Francisco headquarters (though for the right candidate we would consider another location within the US). You should also expect frequent travel. San Francisco and the Bay Area have a lot of IoT and connected hardware activity but we go where the action is. You can look forward to attending many conferences, events, and on-site hack days with a backpack full of hardware and sensors.

Interested?

If this sounds like you, send an email to mark@helium.com.

Helium is hiring a Community Engineer was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we’re excited to announce that we’re making it easier for IoT developers to prototype and ship connected devices as part of a new collaboration with GitHub, and the GitHub Developer Program.

This means two things for the GitHub community:

1. You can look forward to Helium integrating several parts of the Helium platform and features with the GitHub API. This means a smoother experience when building IoT hardware and sensors.
2. Starting today, all GitHub Developer Program members can access discounts on Helium hardware products, cloud services, and ongoing support to get started.

Why Helium and GitHub?

Hardware and IoT developers already use GitHub as a core part of their workflows. Arduino and Raspberry Pi, two of the most popular hardware development platforms, use GitHub for their open source development and community building. Similarly, the Helium Team depends on GitHub for our growing suite of open source IoT development tools.

We firmly believe that Helium, and our combination of hardware and software, is the best way for developers to prototype and deploy connected, secure hardware products. Now we’re going to make it even better by removing as much friction as possible for GitHub users who are building applications with a wireless component. Our partnership will make it easier for you to access IoT development services and move faster when you’re prototyping.

Helium and GitHub integration roadmap

Our current integration roadmap currently has two components, and it will likely expand as we collect your feedback.

GitHub authentication for the Helium Dashboard

Soon we’ll deliver the ability to create accounts and log in to the Helium Dashboard using your existing GitHub account. We’ll also make it possible to automatically mirror your GitHub Team structure within the Helium Dashboard.

git push to deploy device configurations updates over the air

Very few wireless platforms make it possible to deploy configuration or complete software updates over the air to connected sensors. Helium, however, does. And we’ll offer developers the ability to `git push` updates to a target repository that will then kick off an OTA deployment to devices running in the field.

Stay tuned for developments on both of these.

Helium for GitHub Developer Program members

Use the discount code HELIUM-AND-GITHUB-4-IOT for 35% off a Starter Kit if you buy before September 1st. After that, the discount drops to 25%.

To help Developer Program members get started, we’re offering the following discounts on Helium products:

• 35% off a Helium Starter Kit (until September 1, 2017)
• 25% off a Helium Starter Kit (after September 1, 2017)
• 15% off all future hardware purchases
• $100 worth of Helium Dashboard credits
• 30 minute on-boarding with Helium Engineering
• 10% off future support contract purchases

All current members of the GitHub Developer Program received an email with details about how to buy Helium products with these discounts. If you’re not yet a member of the GitHub Developer Program, you can apply here

We can’t wait to see what you build with GitHub and Helium. If you have any questions about our partnership or products, find us in the Helium Community Slack, post a message on the Helium Developer Forum, or send a note to mark@helium.com.

Helium and GitHub partner to streamline connected hardware development was originally published in The Helium Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.