diff --git a/.env.example b/.env.example new file mode 100644 index 000000000..0fe3f6de0 --- /dev/null +++ b/.env.example @@ -0,0 +1,3 @@ +EDU_EMAIL=SEE_README +EDU_PW=SEE_README +EDU_API_URL=SEE_README \ No newline at end of file diff --git a/.gitignore b/.gitignore index 3ced74ee0..7fb431e21 100644 --- a/.gitignore +++ b/.gitignore @@ -10,6 +10,7 @@ # Misc .DS_Store +.env .env.local .env.development.local .env.test.local @@ -20,3 +21,4 @@ yarn-debug.log* yarn-error.log* .idea +.yarn diff --git a/.vscode/extensions.json b/.vscode/extensions.json index 85891a208..5c529e808 100644 --- a/.vscode/extensions.json +++ b/.vscode/extensions.json @@ -1,6 +1,7 @@ { - "recommendations": [ - "esbenp.prettier-vscode", - "znck.grammarly", - ] -} \ No newline at end of file + "recommendations": [ + "esbenp.prettier-vscode", + "ban.spellright", + "unifiedjs.vscode-mdx" + ] +} diff --git a/.vscode/launch.json b/.vscode/launch.json new file mode 100644 index 000000000..822d64456 --- /dev/null +++ b/.vscode/launch.json @@ -0,0 +1,23 @@ +{ + // Use IntelliSense to learn about possible attributes. + // Hover to view descriptions of existing attributes. + // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 + "version": "0.2.0", + "configurations": [ + { + "type": "node", + "request": "launch", + "name": "Launch Docusaurus", + "runtimeExecutable": "yarn", + "cwd": "${workspaceFolder}", + "runtimeArgs": ["start"] + }, + { + "type": "node", + "request": "launch", + "name": "Install Packages", + "runtimeExecutable": "yarn", + "cwd": "${workspaceFolder}" + } + ] +} \ No newline at end of file diff --git a/.vscode/settings.json b/.vscode/settings.json index 4e130910a..4086e376a 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -9,7 +9,25 @@ "editor.formatOnSave": true, "editor.defaultFormatter": "esbenp.prettier-vscode" }, - "grammarly.files.include": ["**/*.mdx", "**/*.md"], - "grammarly.config.suggestions.InformalPronounsAcademic": true, - "grammarly.config.suggestions.PassiveVoice": true + "spellright.language": [ + "en" + ], + "spellright.documentTypes": [ + "markdown", + "mdx" + ], + "spellright.parserByClass": { + "mdx": { + "parser": "markdown" + } + }, + "spellright.ignoreRegExpsByClass": { + "mdx": [ + "/&/g", + "/ /g", + "/—/g", + "/>/g", + "/</g" + ], + } } diff --git a/.vscode/spellright.dict b/.vscode/spellright.dict new file mode 100644 index 000000000..18d69b26b --- /dev/null +++ b/.vscode/spellright.dict @@ -0,0 +1,27 @@ +DevAddr +DevAddrs +NwkAddr +NwkAddrs +AppEUI +DevEUI +NwkSKey +AppSKey +docusaurus +Merkle +Helius +GenesysGo +Mainnet +Devnet +veHNT +veMOBILE +veIOT +Landrush +Beaconer +Permissionless +trustless +Denylist +denylist +misasserted +Hivemapper +Passpoint +Ubiquiti diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0b5d6fe00..721583bda 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,38 +1,16 @@ -# How to Contribute to this repository # +# How to Contribute to this repository -We value contributions from the community and will do everything we -can go get them reviewed in a timely fashion. If you have code to send -our way or a bug to report: +We value contributions from the community and will do everything we can to get them reviewed in a +timely fashion. If you have code to send our way or a bug to report: -* **Contributing Code**: If you have new documentation, fork this - repo, create a logically-named branch, and [submit a PR against this - repo](https://github.com/helium/docs). Include a - write up of the PR with details on what it does. +- **Contributing Code**: If you have new documentation, fork this repo, create a logically-named + branch, and [submit a PR against this repo](https://github.com/helium/docs). Include a write up of + the PR with details on what it does. -* **Reporting Bugs**: Open an issue [against this - repo](https://github.com/helium/docs/issues) with as much - detail as you can. At the very least you'll include steps to - reproduce the problem. +- **Reporting Bugs**: Open an issue [against this repo](https://github.com/helium/docs/issues) with + as much detail as you can. At the very least you'll include steps to reproduce the problem. -# Contibuting a Helium Improvement Proposal (HIP) # +This project is intended to be a safe, welcoming space for collaboration, and contributors are +expected to adhere to the [Contributor Covenant Code of Conduct](http://contributor-covenant.org/). -HIPs are modeled off Bitcoin Improvement Proposals (BIPs) and has become a standard in the crypto world for open source development on both technical and economic issues. - -HIPs serve several primiary functions: -- To make architecture changes -- To make economic and token changes -- To address cheating and security issues -- To address meta-governance - -HIPs are not: -- Funding requests to The Helium Foundation -- Foundation treasury management - -* **How do I submit a HIP?**: Open a 'pull request' in the HIP repository. DO NOT create an 'issue'. Your pull request signifies a HIP in draft status. HIPs in draft status should be discussed in #hip-general in the [Helium Official Community](https://discord.gg/uTauMaJ2We). Draft HIPs will be addressed and managed by HIP editors. Please be sure to answer all of their questions appropriately. HIPs that do not work with HIP editors are seen as incomplete and are likely to be closed. Once your HIP is clear and has met all HIP requirements, HIPs are then open for deeper discussion with their own channels in the Helium Official Community. HIPs move to a vote after rough consensus that this HIP is appropriate for the community to vote on. There is never a guarantee your HIP will receive a channel or move to a vote. - -This project is intended to be a safe, welcoming space for -collaboration, and contributors are expected to adhere to the -[Contributor Covenant Code of -Conduct](http://contributor-covenant.org/). - -Above all, thank you for taking the time to be a part of the Helium community. \ No newline at end of file +Above all, thank you for taking the time to be a part of the Helium Community. diff --git a/README.md b/README.md index 4aa6e9e9a..82894db07 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ Documentation for the Helium network. - [Yarn](https://yarnpkg.com/getting-started/install) version >= 1.5 -## Installation +## Helium Documentation Installation Guide - [Installation Guide](https://docs.helium.com/faq/docs-installation/) @@ -46,9 +46,9 @@ bottom of the doc. Abbreviated links help improve readability of the raw markdow links reusable in the same doc. Abbreviated Links Example: If you would like to link to the development devices introduction page -found at `/use-the-network/devices/development`, use `[development devices][devices.development]` -inline with your text content. Next, create the link to the full path at the very bottom of the doc -markdown like this `[devices.development]: /use-the-network/devices/development`. +found at `/network-iot/devices/development`, use `[development devices][devices.development]` inline +with your text content. Next, create the link to the full path at the very bottom of the doc +markdown like this `[devices.development]: /network-iot/devices/development`. ## Adding Images @@ -98,12 +98,12 @@ sidebar_label: Devices ``` `slug: ` If the doc id path has repeated sections like the following doc path -`use-the-network/devices/devices`, define a `slug:` field in the front matter to make it pretty as -shown below. This way when this doc is navigated to, the URL shown will not have repeating sections -names in it. +`network-iot/devices/devices`, define a `slug:` field in the front matter to make it pretty as shown +below. This way when this doc is navigated to, the URL shown will not have repeating sections names +in it. ``` -slug: use-the-network/devices +slug: network-iot/devices ``` ## Check for dead links diff --git a/devblog/2019-10-18-beta-deploy.mdx b/devblog/2019-10-18-beta-deploy.mdx deleted file mode 100644 index cb2941eb0..000000000 --- a/devblog/2019-10-18-beta-deploy.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Blockchain Beta Deploy -date: 2019-10-18 23:41 -0700 -hide_table_of_contents: true -authors: [madninja] ---- - -As part of improving network behavior and testing it in a real environment we use a number of opt-in -beta hotspots. - - - -There are some ground rules for beta deployments that we strictly follow: - -- The change can _not_ affect blockchain consensus behavior. Any behavior change that affects chain - consensus rules _must_ be gated on a chain variable - -- The change can improve peripheral elements of the software which _may_ indirectly affect the - behavior of the blockchain. Changes are usually related to performance or stability improvements - that make it more likely that a hotspot can talk to more hotspots or recover from error conditions - better than before the update. - -## Content - -The beta group was updated with firmware `2019.10.18.1` which includes: - -- Improving some error resilience in the network relay service -- Only blacklisting relays that are explicitly known to not be connected by the intermediate host -- Speed improvements in NAT detection -- Using more available peer targets when syncing the blockchain -- Fix ledger disagreement over ordering of each hotspot's geographic neighbor list - -## Deployment Plan - -Given the small set of patches this beta includes and the expected stabilizing effect on block sync -and PoC receipt delivery issues, we plan to let this beta run for 24 hours and then deploy it to the -network at large. diff --git a/devblog/2019-10-18-incident-report.mdx b/devblog/2019-10-18-incident-report.mdx deleted file mode 100644 index 95a3ef264..000000000 --- a/devblog/2019-10-18-incident-report.mdx +++ /dev/null @@ -1,154 +0,0 @@ ---- -layout: post -title: Incident Report - Oct 10 - 17, 2019 -date: 2019-10-18 22:36 -0700 -hide_table_of_contents: true -authors: [madninja] ---- - -## Overview - -The Helium blockchain team has been working for several weeks on some incremental upgrades to our -Proof of Coverage (PoC) and election systems, to make them more scalable and fair. Changes here -include: - - - -- adjustments to make consensus groups more geographically diverse. -- changes to limit the length of PoC paths, which grow exponentially more expensive to validate - (`O(n²)` for the computer scientists in the audience) as they grow longer. -- changes to PoC challenge generation to make it impossible for an unsynced hotspot to participate - in a PoC challenge. - -## What Happened - -### PoCv2 Issues - -On October 10th around noon PDT, we submitted the chain variable transaction to activate these -changes, which had gone, disabled, into production over the preceeding few weeks. Shortly -thereafter, things began to go badly wrong. We were immediately aware of the impact and began -analysis of the situation. While we were able to determine quickly that block gossip has stopped -functioning effectively, it was unclear why. Our public-facing API server, which allows our mobile -apps to communicate with the hotspot blockchain network, was also not functioning correctly. - -First, we discovered that the code version on our cloud based full nodes was too old, and they had -stopped syncing the chain and participating in block gossip, slowing things down quite a bit. This -was remedied by 3pm, but did not help as much as expected, so we continued to look at hotspots to -figure out what the true root of the issue was. It was clear that validating PoC receipt -transactions was a major part of the problem, but it was unclear how they had become problematic. - -By 8PM PDT the ledger on the API had been reset and it resumed normal service, and the team was deep -into discussions of how to resolve the issue. At 11PM PDT a transaction was prepared that rolled -back part of the configuration change, and this seemed, initially, to be effective, so the team went -to sleep. Overnight, at approximately 1:30AM, the chain halted again, for similar reasons. - -The next morning was also dedicated to analysis of the problem. We prepared and partially rolled out -a patch by 3pm that set a deadline on how long a transaction would have to have to validate, -preventing extremely long block times. It was declared GA at 4:20PM PDT and seemed to help somewhat, -but not enough. By 6PM PDT, it was decided that this was not helping enough and the full suite of -PoC changes should be removed via another chain variable change transaction. This had the desired -effect of restabilizing the chain. - -### Ledger Fork - -However, just after 8PM PDT, the chain experienced another halt. Investigation revealed that a large -number of hotspots considered the block invalid and could not continue syncing the chain. While we -initially feared that this was related to the earlier problems, it turned out to be unrelated. We -have been dealing with long-term determinism issues surrounding retained floating point values and -list ordering diverging over time for a while now, and this was another in the same category. - -Our initial response was to skip past the invalid block that had been generated, but the block that -the consensus group subsequently generated proved impossible (for the aforementioned determinism -issues) for a large percentage of the hotspot fleet to progress past. However, the rest of the fleet -managed to continue making blocks and holding elections. Over the weekend, we spent time refining -the process for safely bringing hotspots back into line with the group. This involved reconstructing -the ledger data from blocks on disk, which was moderately time-consuming and not particularly safe. -By Monday, we had improved the existing code around this enough to safely fix the remaining -hotspots. - -### API Recovery - -The API server essentially is a blockchain consumer and was affected by the ledger fork as well. A -conflicting view of the ledger wouldn't allow the API server to ingest blocks and update the -necessary data in the back-end database required by the app to render different screens. - -Before we realized that the root issue was the ledger fork, we tried a few cleanup methods on the -API server: - -- Rebooted the API server on all the AWS instances, between 1–2 PM PDT Thursday, Oct 10 -- Rebuilt the API server from scratch with updated blockchain dependencies, between 2–5 PM PDT - Thursday, Oct 10 - -None of which actually resolved the issue. However, once we knew that we had a conflicting ledger, -it was a simple matter of: - -- Pausing the API server's sync process -- Resetting the API server's copy of the ledger -- Resuming the blockchain sync process - -These steps worked as intended and the API server was back up and running around 8PM PDT, Thursday, -Oct 10. - -### Continued Struggles with Pathing - -Through the weekend and for most of the following week we struggled with block production and a -phenomenon where PoC rate would fall terribly low, causing a large number of issues as many active -hotspots were assumed down due to how long it had been since they'd issued a PoC challenge. - -We eventually realized that the issue had nothing, strictly, to do with the PoC code, but that in -our more crowded cities, changes to how long a hotspot would be judged a poor network participant -for failing PoC challenges was lessened, leading to many new hotspots being in the neighborhood all -at once. This lead to many new and exceptionally long paths. - -Since paths grow exponentially more expensive with their length, this would lead to situations where -our PoC challenge generation state machine would be stuck so long generating challenges that no -challenge that it generated could ever succeed, as their validity is height-limited. - -Since challenge generation took longer than the rate at which new challenges would be issues, this -state machine entered a spiral from which it would never recover, until either restarted or fixed by -a code change, which was made on the 17th. - -## Resolution - -There were a number of operational and code fixes undertaken over the course of the week. We added -time budgets to all of the places where a PoC challenge could be generated or validated, and added -new path limitation code to trim paths as soon as they grow too long, rather than computing them in -full before truncating them. The new PoC code was re-enabled on Thursday, October 17th, along with -these changes. - -Operationally, our team worked to reset all of the nodes that had been effected by the ledger fork -and return them to proper working order. - -## Impact - -Over the course of the incident, block production was massively slowed down, and with them, -elections, so token production was slowed down. We were regularly seeing block times of well over -half an hour, many of which took manual intervention to resolve. - -A number of hotspots had their PoC challenge code fall behind such that they could no longer issue -challenges, impacting their ability to make tokens. - -Due to the ledger fork, 65 hotspots ceased to stay synchronized with the chain, making it so that -they couldn't, temporarily, participate in PoC processes or elections, making them effectively -unable to earn tokens. - -These changes also altered the topology of the network, leading to unstable block and election -times. - -## Next steps - -We've taken action to continually measure determinism drift on the ledger, and when we detect any, -we'll work to reduce it until there is none. - -Work on restablizing block and election times is ongoing. Since our consensus groups run on -appliances using consumer internet, this is will be an ongoing challenge. - -We have put in place procedures for slower and more careful roll out of new chain variables, and -re-prioritized the reconstruction of our separated test cluster. - -This blog is a first step in clearly documenting both incidents and our work to remediate them, as -well as the place to announce planned changes, deployments of those changes, and any maintenance of -the app and associated services. - -We apologize for the instability as we work to improve everyone's ability to participate in the -growth of the network. diff --git a/devblog/2019-10-21-beta-deploy.mdx b/devblog/2019-10-21-beta-deploy.mdx deleted file mode 100644 index 760dbe8b9..000000000 --- a/devblog/2019-10-21-beta-deploy.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: Blockchain Beta Deploy -date: 2019-10-22 08:56 -0700 -hide_table_of_contents: true -authors: [madninja] ---- - -We rolled out the [Beta update](https://docs.helium.com/blog/2019/10/10/beta-deploy) over the -weekend and it appears to have helped some, but a number of issues were discovered that caused -unneeded network load, slowing down blocks and elections. - - - -## Content - -- An optimization was added to ignore transactions already in the honey badger buffer. - -- Elections that failed were not being cleaned up. Now they are. - -- A recent blockchain refactor was reverted because it was inappropriately dropping transactions. - -- The transaction manager now dumps a transaction if it sees f+1 rejections from the consensus - group. - -- More informative logging messages added around transaction validation and speculative absorption. - This will help diagnose lingering issues. - -## Deployment Plan - -The patches are directly related to a focused set of issues that should improve chain behavior. We -plan to let this beta run for 24 hours and then deploy it to the network at large. diff --git a/devblog/2019-10-22-wallet-update.mdx b/devblog/2019-10-22-wallet-update.mdx deleted file mode 100644 index 3830863e9..000000000 --- a/devblog/2019-10-22-wallet-update.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: Wallet Status Update -date: 2019-10-22 09:00 -0700 -hide_table_of_contents: true -authors: [madninja] ---- - -As the number of hotspots grows with the national launch a number of issues were reported by some -users and the engineering team: - - - -- Some times pending transactions are cached incorrectly in the app which can cause the app to show - the block-chain being down. This has affected a small number of customers over the past weekend. - - The workaround is to delete the app cache data (Android) or uninstall and re-install the app - (iOS). We'll be pushing out a short term fix while we work out the root cause of the issue. - -- The mobile app reports that a hotspot needs attention while it is syncing the blockchain. While - your hotspot is syncing the needs attention warning can be ignored. - - Contact support if your hotspot states that it needs attention while the sync is at 100% or if the - sync percentage is stuck at the same number for more than an hour. - -- The app reports that is "unable to pair because it's not \". This usually - happens when the hotspot is syncing, which causes high CPU load. - - We're working on fixing this. A workaround is to try to pair again a few times to get past it. - -- The app reports that there is a fee associated with adding a hotspot. All Helium hotspots have - these fees waived, and a hotspot update fixes this issue. - - If you see this error, please close the application and wait for about 10-15 minutes for the - hotspot to update itself. You should see the light turn of as the hotspot restarts to apply the - update. diff --git a/devblog/2019-10-23-beta-deploy.mdx b/devblog/2019-10-23-beta-deploy.mdx deleted file mode 100644 index baf46d5f3..000000000 --- a/devblog/2019-10-23-beta-deploy.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Blockchain Beta Deploy -date: 2019-10-23 -hide_table_of_contents: true -authors: [fvasquez] ---- - -In preparation for release of the LongFi SDK we are testing the latest version of the LongFi -protocol on a select few San Francisco hotspots that are within radio range of each other. - - - -## Content - -This newly selected beta group was updated with Hotspot firmware version `2019.10.23.0` which -includes: - -- A new version of concentrate which is the reference implemnentation of LongFi that runs on all - Helium hotspots -- A new version of miner that integrates with this new version of concentrate for Proof of Coverage. - -## Deployment Plan - -We plan to let this beta run overnight to see how Proof of Coverage is impacted then deploy it to -the network at large to use the LongFi protocol. diff --git a/devblog/2019-10-25-beta-deploy-2.mdx b/devblog/2019-10-25-beta-deploy-2.mdx deleted file mode 100644 index da2d4cdbb..000000000 --- a/devblog/2019-10-25-beta-deploy-2.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: Beta Deploy 2 -date: 2019-10-25 09:47 -0700 -hide_table_of_contents: true -authors: [madninja, vagabond] ---- - -As more and more hotspots ship out, we are encountering some blockchain syncing problems. A number -of the shipped hotspots were assembled over a month ago but had older firmwware that did not include -some important bugfixes. - - - -In some cases the older firmware absorbs blocks in their ledger that they don't properly understand -causing ledger corruption issues that prevent further syncing. - -To mitigate this problem we have decided to deploy an intentionally backwards incompatible change to -the blockchain sync protocol. The goal here is two fold; to correct some deficiencies in the -original sync protocol and to force hotspots running an older firmware to upgrade before starting to -sync the chain. - -In addition a small change to peerbook metadata has been made to allow hotspots to advertise the -last time they wrote a block to their local blockchain. This is intended to help spotting and -diagnosing hotspots experiencing syncing problems. - -## Content - -- Roll the blockcain sync protocol version - -## Deployment Plan - -As this is a network-wide breaking change we plan to roll it out as quickly a possible to everyone -to avoid partitioning the network. A small controlled smoke test OTA will be done followed shortly -by a release to general availability. diff --git a/devblog/2019-10-25-beta-deploy.mdx b/devblog/2019-10-25-beta-deploy.mdx deleted file mode 100644 index f810b06ef..000000000 --- a/devblog/2019-10-25-beta-deploy.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: post -title: Blockchain Beta Deploy -date: 2019-10-25 -hide_table_of_contents: true -authors: [fvasquez] ---- - -The [last beta deploy](https://docs.helium.com/blog/2019/20/23/beta-deploy) did not go well. Parsing -of LongFi packets was broken in concentrate so the selected hotspots were not able to engage in -Proof of Coverage with each other as planned. - - - -Rolling back the hotspot firmware update resulted in a hard reboot of the beta hotspots. This hard -reboot resulted in minor file system corruption which triggered reformatting of the `/var` partition -mounted on /var because of an incorrect return code check from fsck. - -WiFi credentials were lost so hotspots that were connected to the internet over WiFi fell offline. -Older pre-production units also lost their `swarm_keys` which reside on the SD card rather than the -hardware security module in production units. - -Since the `/var` partition was lost on the affected beta hotspots, the blockchain cache was also -lost resulting in any production hotspots in the beta group having to resync the blockchain over -about 24 hours. - -To remedy the inadvertent reformatting of hotspots persistent file system we have fast-tracked a PR -to correct the behavior of the file system check and repair script that runs on start up. - -To minimize risk all the recent LongFi related commits were reverted from the master branch of the -hotspot firmware so that shut down behavior remains unchanged. - -## Content - -The beta group will be updated with Hotspot firmware version `2019.10.25.0` which includes: - -- Revert concentrate upgrade for LongFi (not in `2019.10.21.0` GA release) -- Do not treat all non-zero fsck return codes as unrecoverable errors -- Revert miner upgrade for LongFi (not in `2019.10.21.0` GA release) -- Revert CMake upgrade (not in `2019.10.21.0` GA release) - -## Deployment Plan - -We plan to let this beta run for at least a couple of hours. If that proves to be stable we will tag -the branch as `2019.10.25.0` and confirm that the GA release OTA updates successfully before making -it available to all hotspots. diff --git a/devblog/2019-10-28-beta-deploy.mdx b/devblog/2019-10-28-beta-deploy.mdx deleted file mode 100644 index 0cf042f30..000000000 --- a/devblog/2019-10-28-beta-deploy.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: Beta Deploy -date: 2019-10-28 -hide_table_of_contents: true -authors: [fvasquez] ---- - -On October 25 around 6 PM PDT we rolled out a -[GA release](https://docs.helium.com/blog/2019/20/25/beta-deploy-2) to address blockchain syncing -problems. This was a network-wide change that intentionally broke compatibility with the previous -1.0 version of the blockchain sync protocol. - - - -While the change did not appear to effect any hotspots that were already fully synced with the -blockchain, several reports of stuck or backwards syncing hotspots began arriving the following -morning from customers who had just finished onboarding their newly unboxed hotspots. - -## Content - -The beta group was updated with Hotspot firmware version `2019.10.25.1-2-g64a37ee4` which includes: - -- Add block height to assume valid block information -- Implement recursive locking for blockchain mutex -- Bump assume valid block to 98917 (2019.10.29.0 GA release only) - -## Deployment Plan - -We plan to let this beta overnight to give the targeted hotspots enough time to resync past the -assumed valid block from scratch. If resyncing succeeds we will tag the branch as `2019.10.29.0` and -confirm that the GA release OTA updates successfully before making it available to all hotspots. diff --git a/devblog/2019-10-29-app-releases-to-date.mdx b/devblog/2019-10-29-app-releases-to-date.mdx deleted file mode 100644 index 51b800c42..000000000 --- a/devblog/2019-10-29-app-releases-to-date.mdx +++ /dev/null @@ -1,155 +0,0 @@ ---- -layout: post -title: iOS and Android App Release Notes to Date (1.0 to 1.4.6) -date: 2019-10-29 15:42 -0700 -hide_table_of_contents: true -authors: [cokes518, evanmcc] ---- - -  - -# iOS Version 1.4.6/Android Version 1.4.6 - -- Fixed an unrecoverable bug when you enter irrelevant information in custom endpoints - - - -# iOS Version 1.4.5/Android Version 1.4.5 - -- Sent Payment transactions appeared as + instead of -. This bug is fixed -- When there's a firmware update, the app will disconnect with the Hotspot over bluetooth so that it - can get an update -- The app sometimes thinks the Hotspot it's trying to pair with is not who it says it is. This is - also fixed. - -# iOS Version 1.4.4/Android Version 1.4.4 - -- fixed crash loop when there is only 1 pending transaction in a user's wallet - -# iOS Version 1.4.3/Android Version 1.4.3 - -- Improve data fetching speeds from the API - -# iOS Version 1.4.2/Android Version 1.4.2 - -- Update HLM to HNT -- Other minor bug fixes - -# iOS Version 1.4.1/Android Version 1.4.1 - -- FaceID and TouchID support for iOS and Android -- (iOS only) App stability for iOS 13 devices - -# iOS Version 1.4.0/Android Version 1.4.0 - -## Redesigned Network Stats - -- In this new update, you’ll find a brand new Network Statistics UI. See who’s in a consensus group, - view Hotspot maps, block explorer, and challenges. Average block times and circulating HNT are - also included in this update. Keep your eye on Helium app updates because we’ll be adding more - interesting Network statistics soon! - -## Witnesses in Challenges - -- When you view Challenges, you can now toggle witnesses on and off, so you can see a better, - clearer, zoomed-in view of a challenge. - -## Setting Up Wi-Fi - -- Show Wi-Fi password when setting up your Hotspot’s internet connection. - -## Blockchain Sync Percentage - -- See how blockchain synchronization is going with a clear sync percentage for every Hotspot you - own. - -# iOS Version 1.3.0/Android Version 1.3.0 - -## Hotspot Activity - -- Did you see your Hotspot participate in a challenge and want to explore further? Now you can view - more by tapping the challenge number or block number to see what happened. - -## New Witness List - -- We’ve added more detail in each Challenge. See which hotspots witnessed different stages of a - challenge path. - -## Other - -- Bug Fixes (iOS only) -- Fixed an app crash when you tapped on a specific transaction - -# iOS Version 1.2.0 - -## Hotspot Diagnostic Report - -- This new feature allows you to run a diagnostics report on your Hotspot - check on its inbound and - outbound connectivity, its sync status on the blockchain, and unique details about your Hotspot to - send to support when you need to. To check this out, go to your Hotspot’s Setting and run - diagnostics report. - -## Hotspot Status - -- We’ve made several improvements at how the Hotspot communicates its status to you. Is it - connected? Is it synced to the blockchain? Now we show that information for every hotspot you own. - The Hotspot also has a more reliable and realistic Online/Needs Attention status indicator, so no - more false alarms. - -## Challenge City - -When you are looking at Challenges in the network tab, we now tell you where the challenge occurred. -No more guessing! - -# iOS Version 1.1.3/Android Version 1.1.3 - -- New Notifications - Learn how many tokens you’ve mined every week from your Hotspot. -- We’re no longer displaying scores from Hotspots in the app simply because it was a little - confusing and because we’re revamping how scores are calculated. Until then, your Hotspots will - continue to participate in challenges, mine tokens, etc. Everything is business as usual. We just - won’t show the scores. -- In the Network tab, when viewing a list of challenges, now you’ll know the city where challenges - occurred. -- We’ve added the app version to our More menu so that if you contact support, you’ll know which app - version you’re using. - -# iOS Version 1.1.2/Android Version 1.1.2 - -- Users with iPhone 6s were unable to confirm their Hotspot’s location because the size of the data - packet transferred over bluetooth was too large. We adjusted the size of the packet and users are - now able to set their Hotspot’s location. -- Reduced the time ago indicator to say mins instead of minutes, keeping activity types like “Joined - Consensus Group” from touching other text. -- Users were not asked to pair with a Hotspot if it was recently paired, resulting in failed confirm - location transactions. We’ve fixed the timeout of the pairing process so that a fresh connection - is established every time. -- Added Online/Offline Hotspot status to Hotspot List View. -- Your total account balance is now on one line. - -# iOS version 1.1.1 - -- We now allow Hotspots to connect to Wi-Fi networks that have no passwords. Woot. -- Sometimes the app will crash when you view a consensus group transaction in the block explorer. It - doesn't crash anymore. -- Fixed location permissions so that if you deny it the first time and enable it later, you can - still set your Hotspot's location. -- The language around using Ethernet wasn't clear. You don't need to wait for the green LED light to - appear to know that ethernet is working. -- On the Network tab, when a new challenge result comes in and you're viewing an older challenge, - the app will switch out the view from under you and serve up the new challenge, causing much - confusion. Sorry about that. It won't happen again. - -# iOS version 1.1.0 - -- When completing the passphrase quiz, sometimes the same word appears twice. This isn't useful so - we made sure that doesn't happen. -- When entering Wi-Fi credentials for the Hotspot, the submit button was behind the keyboard which - made it pretty hard to continue. Sorry about that. - -# iOS Version 1.0.0 - -- Helium Hotspot App Launches! -- Create an official Helium Account with 12 unique words that act as your private key -- Onboard Hotspots purchased from Helium -- View the Network! See how Hotspots are challenging others using Proof-of-Coverage, as well as see - the Block Explorer and Network Coverage. diff --git a/devblog/2019-10-29-beta-deploy.mdx b/devblog/2019-10-29-beta-deploy.mdx deleted file mode 100644 index 3696868c6..000000000 --- a/devblog/2019-10-29-beta-deploy.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: Blockchain Beta Deploy -date: 2019-10-29 -hide_table_of_contents: true -authors: [fvasquez] ---- - -In preparation for release of the LongFi SDK we are testing the latest version of the LongFi -protocol on a select few San Francisco hotspots that are within radio range of each other. - - - -## Content - -This beta group was updated with Hotspot firmware version `2019.10.29.0-5-g8375a825`which includes: - -- The latest 0.2.5 version of concentrate which is the reference implementation of LongFi that runs - on all Helium hotspots -- A new version of miner that integrates with this new version of concentrate for Proof of Coverage -- An upgrade from CMake 3.8 to 3.11 so that the latest version of concentrate can be built - -## Deployment Plan - -We plan to let this beta run overnight to see how Proof of Coverage is impacted If the beta hotspots -are able to witness Proof of Coverage challenges we will tag the branch as `2019.10.30.0` and -confirm that the GA release OTA updates successfully before making it available to all hotspots. diff --git a/devblog/2019-10-31-android-update.mdx b/devblog/2019-10-31-android-update.mdx deleted file mode 100644 index 4b35bad9b..000000000 --- a/devblog/2019-10-31-android-update.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -layout: post -title: Android 1.4.6.1 Update -date: 2019-10-31 08:42 -0700 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Android Version 1.4.6.1 - -- Our previous update for Android 1.4.6 had a bug for one of our require libraries and caused X86 - architecture devices running Android 8.0 and 9.0 to crash and never recover. This update fixes the - library crash. diff --git a/devblog/2019-11-01-beta-deploy.mdx b/devblog/2019-11-01-beta-deploy.mdx deleted file mode 100644 index 487c07050..000000000 --- a/devblog/2019-11-01-beta-deploy.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: post -title: Beta Deploy -date: 2019-11-01 -hide_table_of_contents: true -authors: [evanmcc] ---- - -On November 1 around 3 PM PDT we rolled out a new beta release to better distribute PoC requests -throughout the election cycle, and including some other longer-term engineering improvements. - - - -## Block Weather - -We're aware of the increasing block times and low PoC success rate and are working actively to -ameliorate them. They are largely a result of increasing hotspot density interacting poorly with our -soon-to-be-deprecated initial PoC path selection code. - -We're working as quickly as possible on a new version of this code which should scale more cleanly -due to its use of radio data, rather than asserted location, for hotspot neighborhood graph -construction. If the new code to spread the work into more blocks isn't effective enough, we will -likely alter the PoC challenge interval from 30 to 60 to decrease the number of PoC receipts that we -have to process. Since the PoC rewards are proportional, rather than per-challenge, this should not, -in aggregate, effect challenge rewards once the challenges have redistributed themselves. We expect -challenge rewards to rise as we improve the distribution and make them less expensive to process. - -## Content - -- _Validation Timings_: We've added more log data so as to better understand which transaction - validations are expensive, so that we can better optimize them. -- _PoC Request Randomization_: We've changed how we approach the randomization of when in the - request cycle PoC requests are issued. This should do a better job of spreading them out and allow - more of them to go through. This change also persists temporary receipt information so that fewer - requests are lost to restarts. -- _Prorated Rewards_: Up to now, we have calculated all rewards on the basis of an idealized 30 - round election period. This is sometimes not the case. The code here prepares for the activation - of a new chain variable which will switch us to a code path that changes all rewards to use the - actual period (other than for consensus rewards, which will continue to use the ideal period to - disincentiveize delaying the completion of elections). Expect another dev blog update when this - variable is activated. -- _Chain Var Validation_: All chain vars are now fully validated when their transaction is absorbed. - This is a safety measure to keep hotspots with stale firmware from absorbing blocks that have - chain vars their firmware doesn't know about, which they cannot safely process. - -## Deployment Plan - -We plan to let this beta over the weekend, but may activate it before Monday if block times continue -to be poor. diff --git a/devblog/2019-11-04-ga-deploy.mdx b/devblog/2019-11-04-ga-deploy.mdx deleted file mode 100644 index 0d5942b99..000000000 --- a/devblog/2019-11-04-ga-deploy.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: GA Deploy of 2019-11-03.0 -date: 2019-11-04 -hide_table_of_contents: true -authors: [vagabond] ---- - -We have released a firmware based on the previous beta to general availability. This firmware is -focused on improving Proof of Coverage construction and validation times. The main change from the -last beta has been to refactor our PoC path calculation routines to be more efficent and to improve -our caching of expensive to obtain information necessary for pathing. This change can be seen at -[blockchain-core#289](https://github.com/helium/blockchain-core/pull/289) . - - - -Other notable changes, mentioned in the previous beta post: - -Blockchain: - -- [blockchain-core#282](https://github.com/helium/blockchain-core/pull/282) -- [blockchain-core#280](https://github.com/helium/blockchain-core/pull/280) - -Miner: - -- [miner#240](https://github.com/helium/miner/pull/240) - -We are still working towards an overhaul of the proof of coverage system that should be fairer and -generate more achieveable paths, as well as be much cheaper to compute. That work is being tracked, -at least partially in [blockchain-core#257](https://github.com/helium/blockchain-core/pull/257). In -the meantime this release should help improve the proportion of hotspots getting rewarded and -stabilize block times a little more. diff --git a/devblog/2019-11-06-api-update.mdx b/devblog/2019-11-06-api-update.mdx deleted file mode 100644 index b47d1bdb0..000000000 --- a/devblog/2019-11-06-api-update.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: Blockchain API Update -date: 2019-11-06 14:28 -0800 -hide_table_of_contents: true -authors: [vihu, evanmcc] ---- - -As part of updating the blockchain-api to support newer routes and squash some critical api bugs, -the team has pushed out a new release of the production blockchain-api. - - - -## Content - -The new release contains the following updates: - -- Fix a google maps reverse api lookup crash, which would previously cause the whole application to - shut down. -- Add hotspot name to `/api/accounts//gateways` route for easy cross-checking of - account holder hotspots. -- Rounded off block sync percent to be in line with the current state of the hotspot. -- Enable `/api/hotspots/
/challenges` route which shows a list of poc challenges a hotspot - has done so far. -- Enable `/api/hotspots/timeline` route to check newly added hotspots. -- Enable `/api/accounts//rewards` route to check account rewards. -- Add support for `oui_v1` transaction posting and querying. -- Add support for `security_exchange_v1` transaction posting and querying. - -## Related PRs - -- [blockchain-api#194](https://github.com/helium/blockchain-api/pull/194) -- [blockchain-api#205](https://github.com/helium/blockchain-api/pull/205) -- [blockchain-api#209](https://github.com/helium/blockchain-api/pull/209) -- [blockchain-api#210](https://github.com/helium/blockchain-api/pull/210) -- [blockchain-api#211](https://github.com/helium/blockchain-api/pull/211) -- [blockchain-api#212](https://github.com/helium/blockchain-api/pull/212) -- [blockchain-api#213](https://github.com/helium/blockchain-api/pull/213) -- [blockchain-api#214](https://github.com/helium/blockchain-api/pull/214) diff --git a/devblog/2019-11-06-emergency-firmware-fix.mdx b/devblog/2019-11-06-emergency-firmware-fix.mdx deleted file mode 100644 index 422519ea9..000000000 --- a/devblog/2019-11-06-emergency-firmware-fix.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: post -title: Emergency Firmware Fix -date: 2019-11-06 21:46 -0800 -hide_table_of_contents: true -authors: [madninja] ---- - -The Helium hotspot uses an [ECC608](http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf) -security chip which generates and stores private keys for the hotspot. The private keys generated by -the ECC are not accessible outside of the secure confines of the ECC hardware. - - - -The Helium miner uses the ECC to generate and store the private key for the hotspot, and uses it as -a signing service for transactions, blocks, identified network sessions, and encrypted network -communication, among other things. - -We had a number of reports from hotspot users that their hotspot animal names were changing after -they'd staked their hotspot. Normal operation is for the miner to request the ECC to generate the -hotspot keys just once on startup. - -On inspection it turns out there is a condition where the miner will get the ECC chip to re-generate -a keypair under the any error condition which is too broad of a check. - -Since the ECC does not allow access to the private keys there is no way to recover the keys to the -hotspot once this happens and the hotspot has to be re-added and location re-asserted on the -blockchain. - -The fix we're deploying only generates a key in the ECC when there is not already a key there. This -should avoid erroneous key generation from happening again. - -If your mobile app states that you do not own your hotspot with an animal name that isn't the -original one, please [contact support](https://intercom.help/heliumnetwork/en/) and we'll try to -help set things right for the new hotspot keys. - -## Content - -- Fix for miner to only generate new keys when there are no keys present. - [PR205](https://github.com/helium/miner/pull/250) - -## Deployment Plan - -We'll plan a quick beta roll-out to ensure the firmware build went right and then release the -firmware to all hotspots to help safeguard them potentially resetting their keys on a restart. diff --git a/devblog/2019-11-07-sidecar-beta-deploy.mdx b/devblog/2019-11-07-sidecar-beta-deploy.mdx deleted file mode 100644 index dfd695bbf..000000000 --- a/devblog/2019-11-07-sidecar-beta-deploy.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -layout: post -title: Sidecar Beta Deploy -date: 2019-11-07 15:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -On November 7 around 3 PM PDT we rolled out a new beta release. - - - -## Block Weather - -We're aware that since our last major deployment on Nov. 1 that block times have been less than -ideal. That release did a much better job of distributing PoC request/receipt pairs, which allowed -more of them to complete, but at the cost of nearly continual overdue blocks (the target block -interval is 60 seconds). To ameliorate this problem, this release includes a new process, which we -call the validation sidecar, that allows validation of requests to proceed in parallel to the -progress of the consensus protocol. This should improve the block times quite a bit, and since it -can validate more than one transaction at time should allow still more PoC receipt transactions to -complete. - -We're still working on version two of our PoC system, which radically decreases the cost of -production and validation of receipt transactions, and should allow many more of them to complete, -increasing our insight into hotspot placement and spreading PoC rewards more evenly throughout the -hotspot ownership. - -_Update_: During the beta, a few bugs were discovered and fixed. - -## Content - -- _Validation Sidecar_: As described above, this change allows us to validate transactions in an - asynchronous way, which should lead to improved block times. PRs: - [miner/245](https://github.com/helium/miner/pull/245), - [blockchain-core/285](https://github.com/helium/blockchain-core/pull/285) -- _Metadata Gossip Randomization_: This change reduces the amount of metadata gossip by selecting a - random subset of the nodes that a given knows instead of gossiping the whole set. This should - reduce the bandwidth that hotspots use, but may occasionally increase metadata convergence time in - the system. PRs: [libp2p/229](https://github.com/helium/erlang-libp2p/pull/229) - -_Beta Bugfixes_: [miner/251](https://github.com/helium/miner/pull/251), -[miner/252](https://github.com/helium/miner/pull/252) - -## Deployment Plan - -We plan to let this beta overnight and deploy in the morning PST on Friday the 7th. diff --git a/devblog/2019-11-13-incident-report-emergency-ota.mdx b/devblog/2019-11-13-incident-report-emergency-ota.mdx deleted file mode 100644 index 69782a22e..000000000 --- a/devblog/2019-11-13-incident-report-emergency-ota.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: Incident Report and Emergency OTA -date: 2019-11-13 11:00 -0800 -hide_table_of_contents: true -authors: [vagabond] ---- - -On November 13 around 7am PST the blockchain halted due to an out of memory bug. All the consensus -members, having agreed on the next block's contents were unable to verify them. This was because, -for performance reasons, the transactions in the block were being verified in parallel. -Unfortunately there was no limit on the amount of concurrency used and this led to CPU and memory -exhaustion as all 65 transactions in block 110,710 were being verified simultaneously. - - - -A hotfix to limit the number of transactions verified at once was developed and rolled out around -10:30am PST to the consensus group. This immediately allowed the in-progress block to be completed -and gossipped around. However non-concensus nodes without the fix, when trying to validate the new -block, then began to OOM as they saw the new block. An OTA build was completed around 11:20am PST -and deployed to the beta group. Shortly afterwards, assuming everything looks good, we will do a -deployment to the wider network. - -Longer term, this relates to the rapid growth of the network. We are still working hard on improving -the scalability of the systems as the network grows and expect to deploy significant improvements to -make transactions much cheaper to validate soon. - -## Content - -- _Limit pmap width when validating signatures and transactions_: PRs - [blockchain-core/#292](https://github.com/helium/blockchain-core/pull/292) - -## Deployment Plan - -The OTA is already in beta and will be deployed more widely soon. diff --git a/devblog/2019-11-18-chain-var-deploy.mdx b/devblog/2019-11-18-chain-var-deploy.mdx deleted file mode 100644 index f1dcb42ef..000000000 --- a/devblog/2019-11-18-chain-var-deploy.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -layout: post -title: Chain Variable Deployment -date: 2019-11-18 17:00 -0800 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -We've deployed a chain var transaction to tweak some blockchain behaviour to allow for better -rewards when elections run long and to try to increase the diversity of the consensus group. More -details can be seen over in the -[chain var audit log](https://github.com/helium/miner/blob/master/audit/var-9.md). diff --git a/devblog/2019-11-25-kernel-beta-deploy.mdx b/devblog/2019-11-25-kernel-beta-deploy.mdx deleted file mode 100644 index 21d24ac57..000000000 --- a/devblog/2019-11-25-kernel-beta-deploy.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Linux Kernel Beta Deploy -date: 2019-11-25 15:00 -hide_table_of_contents: true -authors: [fvasquez] ---- - -On November 25 around 11:30 AM PDT we rolled out a new beta release. - - - -Hotspot owners have been reporting long blockchain sync times anywhere from 3 to 5 days after -onboarding. The assumed valid block was last bumped in hotspot firmware release `2019.11.08` to -106,300. As of 3:30 PM November 25 PDT the blockchain height is at 119,322. This means that when a -hotspot is done syncing 89% of the blockchain the rate at which it syncs the remaining 11% is much -slower. This `2019.11.25` release bumps the assumed valid block to 116,796. - -## Content - -- _Linux Kernel_: Upgrade Linux kernel to 4.19.81 for an upcoming hardware revision. -- _concentrate_: Upgrade concentrate for SX1302 support. -- _OTA Updates_: Issue firmware update requests on port 443 instead of 5022. -- _Transaction Bundles_: Add support for transaction bundles so that the Helium mobile app can - submit the add hotspot and assert location transactions in the same block. PRs: - [miner/256](https://github.com/helium/miner/pull/256) - -## Deployment Plan - -We plan to let this `2019.11.25` release beta for a few hours before making it available to all -hotspots. diff --git a/devblog/2019-11-26-pocv4-beta-deploy.mdx b/devblog/2019-11-26-pocv4-beta-deploy.mdx deleted file mode 100644 index 9660b7981..000000000 --- a/devblog/2019-11-26-pocv4-beta-deploy.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: Proof of Coverage v4 Beta Deploy -date: 2019-11-27 5:40 -hide_table_of_contents: true -authors: [vagabond, madninja, evanmcc] ---- - -On November 26 around 9:40 PM PDT we rolled out a new beta release. - - - -This beta contains the new version of the proof of coverage implementation. A fuller explanation of -the changes will be delivered in a subsequent blog post but the essence of the changes are: - -- Pathing is based on historical witnessing, not raw geography -- Hotspots will not be challenged until they themselves have synced and begun to challenge -- All hotspots will have the opportunity to be challenged -- Proof of Coverage paths are now much, much faster to compute and verify, which should lower block - times and avoid dropping PoC receipts that are too slow to verify - -## Content - -- _PoCv4_: Implement PoCv4 [miner](https://github.com/helium/miner/pull/254) - [blockchain](https://github.com/helium/blockchain-core/pull/257) - -In additon the assume valid block was updated to block 119,972. - -## Deployment Plan - -We plan to let this `2019.11.26` release beta overnight and deploy it to general availability -sometime Wednesday. We plan to activate the new code next Monday, December 2nd after the -Thanksgiving holiday in the US so we will have as many personnel as possible online to watch for -issues during the activation. diff --git a/devblog/2019-11-30-force-consensus-deploy.mdx b/devblog/2019-11-30-force-consensus-deploy.mdx deleted file mode 100644 index 9480ed44c..000000000 --- a/devblog/2019-11-30-force-consensus-deploy.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -layout: post -title: Force Consensus Update to Make Blocks -date: 2019-11-30 13:05 -hide_table_of_contents: true -authors: [vihu, evanmcc] ---- - -On November 30, around 13:05 PST we forcefully selected a new consensus group since the previous -consensus group got wedged because of a bad update to the hotspots on the network. - - - -## Content - -In order to make progress on making blocks, the team chose a new consensus group via a -`blockchain_txn_consensus_group_v1` transaction. - -These new members were chosen randomly based on their network score and ability to be connectable. - -Transaction block height: 121439 - -Transaction: - -``` -type=group -height=121438 -delay=0 -members=["melted-ultraviolet-mole", - "decent-lemonade-starling", - "micro-clear-griffin", - "mammoth-tartan-tortoise", - "harsh-alabaster-mole", - "magic-rainbow-wasp", - "fit-latte-crow", - "shambolic-rusty-cyborg", - "noisy-gingham-dolphin", - "mythical-jade-tarantula", - "innocent-tweed-wolverine", - "soft-lava-toad", - "savory-licorice-badger", - "sneaky-rusty-giraffe", - "formal-sapphire-pike", - "short-graphite-terrier"] -proof_hash=13708901 -``` - -API endpoint: [explorer](https://explorer.helium.foundation/api/blocks/121439/transactions) - -## Deployment Plan - -The block containing the transaction is live on the network. diff --git a/devblog/2019-11-30-ota-knocking-hotspots-offline.mdx b/devblog/2019-11-30-ota-knocking-hotspots-offline.mdx deleted file mode 100644 index 2f753db33..000000000 --- a/devblog/2019-11-30-ota-knocking-hotspots-offline.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Latest OTA Knocking Hotspots Offline -date: 2019-11-30 22:20 -hide_table_of_contents: true -authors: [vagabond, madninja, evanmcc] ---- - -The prior update, shipped this morning, has had some unintented consequences. Because of a change in -an init script, a latent race condition in the configuration of the WiFi interface has caused some -Hotspots to be unable to connect to WiFi. Whether a Hotspot is affected depends on what firmware -version it was running when it was initially configured for WiFi. Hotspots on Ethernet should not be -affected. - - - -**If your Hotspot is showing 'needs attention' and has a greenish/yellow LED color, you are likely -affected.** - -We have analyzed the problem and there are 2 known fixes: - -- Re-configure the wifi credentials on the Hotspot -- Boot the previous firmware - -To boot the previous firmware, use the following procedure: - -- Unplug the power -- Press down the black pairing button on the side of the Hotspot -- Reconnect the power while holding down the black pairing button -- While holding down the button, wait for the status LED to light up, then wait an additional 10 - seconds -- Release the button - -This will cause the Hotspot to boot the previous firmware where the race condition was far less -likely and the Hotspot will be able to use its configured Wifi credentials. - -An OTA with a permanent fix is in testing and will be deployed once it is confirmed to work as -intended. We apologize for the inconvienience. diff --git a/devblog/2019-11-30-weekend-updates.mdx b/devblog/2019-11-30-weekend-updates.mdx deleted file mode 100644 index 58a3407e4..000000000 --- a/devblog/2019-11-30-weekend-updates.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: Weekend Updates to Fix Block Time Issues -date: 2019-11-30 10:40 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -On November 30, around 10:30 PST we will be rolling out a new beta release. - - - -This beta contains only 2 changes, one to fix a problem introduced by an earlier release that turned -out to have some performance impacts and one fix for a long-standing problem where a node would -generate an invalid PoC receipt and thus fail to submit the results of its challenge. - -## Content - -- [libp2p - make peerbook metadata asynchronous](https://github.com/helium/erlang-libp2p/pull/231) -- [blockchain-core - snapshot ledger after block is committed](https://github.com/helium/blockchain-core/pull/300) - -No assume-valid adjustments were made. - -## Deployment Plan - -Due to the performance impacts, we will probably fast track this beta to GA if the deployment to the -beta group looks good. diff --git a/devblog/2019-12-01-ledger_at-performance-improvements.mdx b/devblog/2019-12-01-ledger_at-performance-improvements.mdx deleted file mode 100644 index e1ce39a79..000000000 --- a/devblog/2019-12-01-ledger_at-performance-improvements.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -layout: post -title: Ledger at Performance Improvements OTA -date: 2019-12-01 17:45 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -While debugging performance issues over the weekend it was realized we could significantly improve -performance of an expensive operation, calculating the ledger at a specific height, by using a -ledger snapshot we were already making. A simple cache was added to track the last 30 ledger -snapshots and if the `ledger_at` height existed in the cache, it will be used. This has resulted in -a significant performance improvement both to validating PoC receipts as well as block syncing. -While we still plan to activate PoCv4 tomorrow we feel that this interim performance fix, which -remains relevant for PoCv4, is worth it to get the amount of accepted PoC receipts that can be -validated and added to the chain up from the levels they have dropped to. - - - -The changes are completely encapsulated in -[blockchain-core#301](https://github.com/helium/blockchain-core/pull/301). - -The beta deploy was done around 3:40 PM PST and will be deployed to GA shortly. diff --git a/devblog/2019-12-02-calc-edg-prob-perf-fix.mdx b/devblog/2019-12-02-calc-edg-prob-perf-fix.mdx deleted file mode 100644 index fde5b621a..000000000 --- a/devblog/2019-12-02-calc-edg-prob-perf-fix.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -layout: post -title: PoC v4 Performance Improvements OTA -date: 2019-12-02 -hide_table_of_contents: true -authors: [fvasquez, evanmcc] ---- - -Upon activating PoC v4 at 1:50 PM PST on December 2nd we soon realized that the `calc_edge_prob` had -become a performance bottleneck. In response, we changed the order of operations and switched from -using `sets` to `lists` so the calculation is less costly. - - - -The changes are encapsulated in -[blockchain-core#303](https://github.com/helium/blockchain-core/pull/303). - -The beta deploy was done around 5:10 PM PST and will be deployed to GA shortly. diff --git a/devblog/2019-12-02-poc-v4.mdx b/devblog/2019-12-02-poc-v4.mdx deleted file mode 100644 index bb032d365..000000000 --- a/devblog/2019-12-02-poc-v4.mdx +++ /dev/null @@ -1,209 +0,0 @@ ---- -layout: post -title: POC V4 -date: 2019-12-02 09:19 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -As part of our efforts to continually improve the network, we recently implemented Proof-of-Coverage -(PoC) version 4. This blog attempts to detail some of the planning, decisions and analysis that went -into overhauling the existing PoC mechanism. - - - -## Motivation - -The team has learned a lot of valuable lessons from having the first version of PoC out in the wild -and watching the network grow organically. The initial PoC design was reliant on geography, simply -because we did not have enough RF coverage data to make any decisions about the potential quality of -a network generated via RF witnesses. - -As the network grew past 500 Hotspots, we began to realize that we had several shortcomings in our -PoC algorithm, the most important being: - -- **Expensive Computation** - - Our path and target calculation were extremely computationally expensive, and did a fair amount of - superfluous work. This was exacerbated by the resource constraints of the Hotspot hardware. - -- **Favoring localized clusters** - - We saw several clusters of 3 and 5 Hotspots which would get challenged more frequently than - others. This behavior stems from the fact that we biased paths towards confirming high score, so - these clusters would complete their challenges, gain score and enter into a feedback loop which - would challenge them again too soon, leading to score inflation. While we originally thought this - score bias would be reasonable, we realized that this was prohibitive to organic network growth - and it is more equitable and useful to keep PoCs more evenly distributed across all Hotspots on - the network. - -- **New Hotspots left out** - - We soon realized that the old PoC pathing strategy does not account well enough for newly added - Hotspots, as there was no way to construct a path with them if they have no geographic neighbors, - even if they could hear those neighbors via RF and do useful work in the PoC process. We alleviate - this to a degree by allowing every Hotspot to _issue_ PoC challenges and rewarding them for that, - but a better way to address this problem was needed. PoC V4 brings in a new concept, which we call - "beaconing", to address this concern. - -## Getting started: Collecting witness data - -Radio propagation is finicky, and you cannot rely on nearby Hotspots to reliably be able to hear -each other, especially in cities. To improve things, we needed a way to understand which Hotspots -were able to talk to each other during the PoC process. - -This realization led to adding "witness" data in the blockchain ledger. A "witness" is a Hotspot -which has seen an RF packet over the air for any ongoing PoC. Witnesses allow us to gain another key -metric - true RF range between Hotspots. You may have noticed in the Helium mobile app under any PoC -challenge that there are now "witnesses" for each step in path. - -We activated witness collection in block -[89232](https://github.com/helium/miner/blob/master/audit/var-8.md) to begin the process of data -collection while simultaneously deploying the building blocks require to solve the aforementioned -issues. - -## Planning: New Proof-of-Coverage model - -Once we had enough witness data, which you can view -[via the API](https://explorer.helium.foundation/api/witnesses/115JucmPFDKUwvE4fkHR6GyQsttSUMi11KYme6pRcRTVXTqE7ww), -we began working on simulating new PoC models. - -We started by setting out some motivating questions: - -- Which Hotspot to target? -- How do we build a high quality PoC challenge path? -- What do we do if we can't build a path? - -### Targeting - -We find a "target" Hotspot to be the first Hotspot in the PoC challenge path. The "target" in itself -has no special role other than allowing us to narrow our field of search. So rather than looking at -the network as a whole, we start building a path outwards from the target Hotspot. - -The targeting mechanism is based on the following set of rules: - -- **Favor high scoring Hotspots**. - - Since the initial PoC challenge gets delivered via p2p over the network to the first Hotspot in - the path (target), we require some confidence that this Hotspot will be online to successfully - receive the challenge and subsequently broadcast it via RF. - -- **Favor loosely connected Hotspots** - - We believe it is far more interesting to construct PoC paths on the edge of the existing network - because we don't have as much information about the Hotspots there. This enables newly added - Hotspots to get a chance to participate in future Proofs-of-Coverage. - -- **Assigning probabilites and weights** - - Both the above criteria have - [chain variable](https://developer.helium.com/blockchain/blockchain-primitives#chain-variables) - controlled probabilities and weights associated with them to allow us to better tune the selection - over time. - -- **Filter Hotspots which haven't issued a PoC request for a long time** - - We require that the Hotspots must be synced to the network and have constructed PoC requests - within a certain number of blocks. This is to try and ensure that we don't have targets which have - been offline for a long time. - -- **A target must ALWAYS be found** - - We require that we always find _a_ target Hotspot to be start of the PoC path. If we don't find - one, we simply retry. - -### Beaconing - -The simplest way to describe beaconing is to consider it a PoC challenge with a target no other -Hotspot can _decrypt_, but any can _witness_. - -We believe this is an extremely valuable new addition to the PoC mechanism since it has multiple -benefits: - -- New geographically aloof Hotspots now have a way to broadcast that they too are ready for PoC - challenges. Prior to beaconing, all a new Hotspot could do (assuming it was alone geographically) - was issue network rate-limited PoC challenges. With the introduction of PoC v4 these Hotspots - would also be able to construct a beacon which other Hotspots can potentially witness. Both the - challengee Hotspot and the potential witness Hotspot add each other to their witness lists, grow - the network, and PoC further. We hope the information gathered because of this change will allow - us to construct more interesting paths in the future. - -- Even if a Hotspot in a crowded region cannot witness any other Hotspots over RF and was selected - as a target, it would still be able to construct the single layer challenge and get a chance to - grow its witness list. - -### Greedy Paths - -Prior to PoC V4, the way paths were calculated was dependent on the state of the entire network, -which is an expensive calculation to perform every time a Hotspot issues a PoC request, and also -when that request needs to be verified. - -In V4, we've altered the algorithm to be _greedy_ by nature and reduced the size of the input to the -path creation by a significant factor. - -We start path creation by first finding a candidate target Hotspot and grow the path outwards from -it. A brief overview of the algorithm can be described as: - -1. Find target Hotspot, an `O(n)` operation, where `n` is the size of the network. We have plans to - reduce the cost of this further. -2. Inspect witness list of the target Hotspot. An `O(k)` operation, where `k` is the size of the - witness list associated with the target Hotspot. Note that `k` is usually a significantly lower - number than the number of Hotspots present on the network. -3. Assign weights and probabilities to each of the witness members in the witness list. Detailed - further below. -4. Run an inverse cumulative distribution function to select the next hop from the target. -5. Repeat step 2, with the selected witness as the next target Hotspot. - -The overall asymptotic run time of the algorithm is `O(n) + O(m*k) ~ O(n*m)`, which we know is -orders of magnitude faster than the previous PoC version run times. Not only do we get a better run -time complexity with V4, we also gain a huge saving from the reduced input sizes in step 2 onwards. - -#### Weights and probabilites for witness selection - -The blockchain ledger maintains a list of associated witnesses for each Hotspot in the network -(given that there are any) and a -[witness RSSI histogram](https://explorer.helium.foundation/api/witnesses/11bVX2ViJ3yPAgnhGhBhrNtAvDYQLA1K1PucdNz6pQfVe7NUUk8). - -To select a witness as a next potential hop from a target Hotspot we assign probabilities and -weights to each of the target Hotspot's witnesses. - -We defined four distinct probabilities and associated weights with each, these are calculated on the -fly given the Hotspot's behavior on the network, namely: - -- The witness having a good RSSI value. -- The witness timestamp being stale. -- The witness being infrequently challenged. -- A randomness factor. - -Each of these probabilities can be controlled via chain variables to allow for easy tuning in the -future. - -Furthermore, each of the above probabilities have chain variable controlled weights associated with -them, which allow even more fine tuning. - -The overall probability of selecting a witness thus becomes: - -``` -P(Witness) = RSSIWeight * P(WitnessRSSI) + - TimeWeight * P(WitnessTime) + - CountWeight * P(WitnessCount) + - RandomnessWeight * 1.0 -``` - -Note that the probabilty of a witness being selected as random is set to 1.0 as the controlling -factor would be driven by the `RandomnessWeight` given that all the other weights are scaled -accordingly. This was a community suggestion we added to make witness selection slightly more -interesting and random. (Thank you,`@andrew gifft`, for this idea.) - -Once we have the probability tagged witness list for the target, we do an -[inverse cumulative distribution function](https://en.wikipedia.org/wiki/Cumulative_distribution_function) -to pick the next hop and repeat the algorithm to grow the path further. - -## Summary - -We hope that these improvements to Proof-of-Coverage will meaningfully improve both the quality of -the PoC system and the consistency of block times, which have suffered of late as receipt counts -have climbed and those receipts have grown ever more expensive to validate. - -Please visit our [Community Slack Chat](http://chat.helium.com/) if you have questions or would like -to engage in discussion with the team. diff --git a/devblog/2019-12-11-performance-patch.mdx b/devblog/2019-12-11-performance-patch.mdx deleted file mode 100644 index e41766536..000000000 --- a/devblog/2019-12-11-performance-patch.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: post -title: Performance Enhancement Beta -date: 2019-12-11 15:00 -0700 -hide_table_of_contents: true -authors: [evanmcc, madninja] ---- - -On December 11 around 3 PM PDT we rolled out a new beta release. - - - -## Block Weather - -While our [PoCv4](https://docs.helium.com/blog/2019/12/02/poc-v4) changes have improved the -performance of the chain somewhat, we're still regularly missing our 60 block production target, -with an average block production time of 76s at the time of this writing. We've also seen increasing -problems with block sync as the increased performance of receipts has roughly tripled the average -block size. This beta is meant to address both of these issues and improve performance in the medium -term so that the chain performs acceptably until we have time to make changes that address the root -of the problems rather than the symptoms. - -Going forward, we are reworking our targeting such that it does not require knowledge of all of the -Hotspots on the network, which should speed up targeting and validation of PoC challenges quite -alot. Additionally, we'll be investigating why sync streams are failing so often with bigger blocks. -Reducing the rate of failures will speed the initial sync of new Hotspots. - -## Contents - -- _Targeting performance changes_: We were doing too much work here, so we stopped. PR: - [miner/268](https://github.com/helium/miner/pull/269) -- _Validation performance changes_: Since receipt validation needs to re-do the work of targeting, - performed the same optimization here as well. PR: - [blockchain-core/320](https://github.com/helium/blockchain-core/pull/320) -- _Stream monitoring_: A part of our p2p networking layer would stall when a failure was too quick - and not recover in a timely fashion, which slowed down syncing to the assumed valid block quite a - lot. This fix speeds recovery quite a lot. PR: - [libp2p/232](https://github.com/helium/erlang-libp2p/pull/232) - -## Deployment Plan - -We plan to let this beta overnight and deploy in the morning PST on Thursday the 12th. diff --git a/devblog/2019-12-16-poc-v5.mdx b/devblog/2019-12-16-poc-v5.mdx deleted file mode 100644 index 5aecf7dd6..000000000 --- a/devblog/2019-12-16-poc-v5.mdx +++ /dev/null @@ -1,103 +0,0 @@ ---- -layout: post -title: PoC v5 -date: 2019-12-17 -hide_table_of_contents: true -authors: [vihu] ---- - -The launch and activation of PoC v4 introduced some interesting new paths and brought in much needed -performance improvements. We have essentially quadrupled the number of challenges on the network as -validation of PoC receipts is now significantly more efficient. - - - -Since the activation of PoC v4 the community has been consistently providing feedback to make PoC -challenges more random and fair. The new firmware `2019.12.16.0` attempts to address some of these -issues. We also upgraded Erlang `rocksdb` to an upstream `1.1.0` version and bumped the assumed -valid block to `138655`. - -## Content - -With this update we attempt to solve: - -- [blockchain-core#314. Filteration for witnesses which are considered invalid](https://github.com/helium/blockchain-core/pull/314). - -Since each Hotspot maintains a histogram of the witnesses with the corresponding RSSI of witnessed -packets, we can use the free space path loss formula to determine whether it's _impossible_ for two -hotspots to have witnessed each other at those RSSI values. We will now filter these values out. - -Secondly, we check whether the witness being considered for a potential next hop is actually an -active Hotspot or not. If the Hotspot has not issued a challenge in the last 300 blocks it is -considered inactive. - -And finally, we added support for a chain variable for making the initial target selection more -random. A breakdown of chain variables is described below. - -- [blockchain-core#314. Scoring fixes for verifiably impossible RSSI values](https://github.com/helium/blockchain-core/pull/314). - -We believe that witnesses which are too close to a challenged Hotspot should not gain any score, as -these witnesses are often located in the same room or building as the Hotspot being challenged and -not adding significant value to the network. - -We also now ensure that RSSI values look reasonable and have added a check that the _impossible_ -RSSI values don't dominate the overall RSSI values. - -- [blockchain-core#313. Cache improvements to speed up cold miner start](https://github.com/helium/blockchain-core/pull/313). - -Since we can't do a snapshot without committing, we do the next best thing and save the context -state between old ledger height calls to the same height. - -- [blockchain-core#317. Fix potential ledger snapshot inconsistencies](https://github.com/helium/blockchain-core/pull/317). - -The ledger has two modes "active" and "delayed". We ensure snapshots can only be taken from an -"active" ledger. - -Furthermore, when restoring a context cache we make sure the ledger is in delayed mode to prevent -the context being installed onto the wrong subledger. - -- [blockchain-core#310. Float normalization all around](https://github.com/helium/blockchain-core/pull/310). - -Floats are a necessarily evil and may cause a potential latent drift in the ledger view. Therefore -we have normalized all the necessary floats introduced with PoC v4 and PoC v5. - -- [miner#265. Miner updates to support and test POC V5](https://github.com/helium/miner/pull/265). - -We've added three comprehensive test suites to the miner to check for the above PoC v5 changes. - -We've also improved how we assess PoC witness quality from blockchain-core so the API can do the -same. - -- [blockchain-core#322. Export witness quality checks from core](https://github.com/helium/blockchain-core/pull/322) - -This builds on top of core#314 and ensures that verifiably inconsistent witnesses don't get -rewarded. We've added filters to check for two potential discrepancies: - -1. Check that the witness is sufficiently far from the Hotspot it witnessed. We believe this would - discourage installing multiple Hotspots in vicinity and attempting to game the reward system. - -2. Since we collect the RSSI data in the ledger, we've also added a check for - [Free Space Path Loss](https://en.wikipedia.org/wiki/Free-space_path_loss) for witness <-> - challengee RSSI values. - -- [miner#270. Add support and tests for witness quality checks](https://github.com/helium/miner/pull/270) - -This is to ensure that we correctly check the blockchain-core behavior in miner. - -## Chain variable proposal - -| Var | Existing | Proposed | Rationale | -| -------------------------------- | --------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| poc_version | 4 | 5 | Update poc_version to 5 | -| poc_v4_exclusion_cells | 10 | 8 | This will change min hop from ~433m to ~300m | -| poc_v4_prob_rssi_wt | 0.3 | 0.0 | Removed to compensate for poc_v4_randomness_wt | -| poc_v4_prob_time_wt | 0.3 | 0.0 | Removed to compensate for poc_v4_randomness_wt | -| poc_v4_prob_count_wt | 0.3 | 0.0 | Removed to compensate for poc_v4_randomness_wt | -| poc_v4_randomness_wt | 0.1 | 1.0 | Bias entirely towards picking a next hop witness randomly | -| poc_v4_target_prob_score_wt | 0.8 | 0.0 | Removed to compensate for poc_v5_target_prob_randomness_wt | -| poc_v4_target_prob_edge_wt | 0.2 | 0.0 | Removed to compensate for poc_v5_target_prob_randomness_wt | -| poc_v5_target_prob_randomness_wt | undefined | 1.0 | Introduced to make target selection entirely random. Currently high scoring hotspots are always getting targeted, this causes a feedback loop where, high scoring will keep gaining score | - -## Deployment Plan - -We ran the beta overnight on Monday the 16th and marked it GA on Tuesday the 17th at 12 PM PST. diff --git a/devblog/2019-12-18-api-outage.mdx b/devblog/2019-12-18-api-outage.mdx deleted file mode 100644 index a0ac52633..000000000 --- a/devblog/2019-12-18-api-outage.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Api Outage -date: 2019-12-18 09:23 -0800 -hide_table_of_contents: true -authors: [vihu, evanmcc] ---- - -## Content - -With the launch of PoC V5, we unintentionally caused an API fork, where the blockchain couldn't sync -past the new election block. This happened due to the following reasons: - - - -1. The API had been running a partially upgraded blockchain-core dependency which knew only about a - subset of the new consensus rules. -2. We issued the PoC V5 chain variables without realizing that the API would not understand how to - ingest the blocks after the new rules kick in after an election happens. - -To address this, we've taken the following steps: - -1. Stopped the blockchain-api writer instance. -2. Upgraded blockchain-core dependency in blockchain-api. -3. Issued a `reset_ledger` command on the blockchain-api which would bring back the correct ledger - state and allow the blockchain-api to continue syncing and ingesting blocks. - -## Deployment Plan - -The new code is running live on the blockchain-api prod instance now. We will continue to monitor -its progress. diff --git a/devblog/2019-12-18-core-hotfix.mdx b/devblog/2019-12-18-core-hotfix.mdx deleted file mode 100644 index d8cd00b89..000000000 --- a/devblog/2019-12-18-core-hotfix.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: Blockchain H3 Crash Hotfix -date: 2019-12-18 09:52 -0800 -hide_table_of_contents: true -authors: [vihu, madninja, amirhaleem] ---- - -The -[PoC v5 update](https://engineering.helium.comhttps://docs.helium.com/blog/2019/12/17/poc-v5.html) -exposed a few edge cases in [blockchain-core](https://github.com/helium/blockchain-core) related to -Uber's [H3](https://github.com/uber/h3) library. The `grid_distance` function in H3 can crash in the -following scenarios: - - - -- Pentagonal distortion -- Mismatched h3 resolutions -- Hotspots being too far away with no possible `grid_distance` existing between them - -## Content - -[blockchain-core#325](https://github.com/helium/blockchain-core/pull/325) addresses the above -crashes. This fix attempts to calculate the distance and fails gracefully if any of the above -scenarios occur. - -## Deployment Plan - -On December 18 around 10:20 AM PDT we rolled out a `2019.12.18.0` beta release with a hotfix for -these issues. We plan to let this beta run for 1 hour then deploy it to the network at large. diff --git a/devblog/2019-12-18-poc-v5-var-update.mdx b/devblog/2019-12-18-poc-v5-var-update.mdx deleted file mode 100644 index 51e8df7d9..000000000 --- a/devblog/2019-12-18-poc-v5-var-update.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: PoC V5 Chain Var Update -date: 2019-12-18 09:35 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -With the launch and activation of PoC v5, the team quickly realized that we needed to bring back -some of the PoC RSSI related probability weights back to the path construction algorithm to allow -building paths with potentially known valid witnesses as next hops. - - - -Note that the targeting mechanism is still deterministically random to avoid the high scoring -feedback loops we observed with PoC V4. - -## Content - -We've updated the following chain vars: - -| Var | Existing | Proposed | Rationale | -| -------------------- | -------- | -------- | -------------------------------------------------------------------------------------------------------------------- | -| poc_v4_prob_rssi_wt | 0.0 | 0.2 | Re-introduced to bias for selecting next hop witnesses which have proven good RSSI values when constructing poc path | -| poc_v4_prob_time_wt | 0.0 | 0.2 | Re-introduced to bias for selecting next hop witnesses which are not stale when constructing poc path | -| poc_v4_prob_count_wt | 0.0 | 0.2 | Re-introduced to bias for selecting next hop witnesses which have been rarely seen when constructing poc path | -| poc_v4_randomness_wt | 1.0 | 0.4 | Reduce bias for selecting next hop witness entirely randomly | - -The audit log can be found [here](https://github.com/helium/miner/blob/master/audit/var-12.md). - -## Deployment Plan - -The chain var was activated in block 140720. diff --git a/devblog/2019-12-19-emergency-firmware-fix.mdx b/devblog/2019-12-19-emergency-firmware-fix.mdx deleted file mode 100644 index 1a38f8bb9..000000000 --- a/devblog/2019-12-19-emergency-firmware-fix.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Emergency Firmware Fix -date: 2019-12-19 11:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -Over time we've seen our gossip quality degrade as the network has become larger. Quite suddenly, we -crossed some threshold and gossip has become untenable without changes. `libp2p` groups, the -abstraction that our consensus and dkg are built upon, are taking longer and longer to converge, -leading to elections that don't complete, and occasionally to chain stalls. This emergency release -speeds up gossip dissemination by increasing the number of peers to gossip per gossip round, and -changes the seed node connection strategy to only connect to two seed nodes, rather than all of -them. At the same time, we're increasing the number of seed nodes to deal with overload. - - - -## Content - -- Tweak libp2p gossip strategies: PR: [libp2p/233](https://github.com/helium/erlang-libp2p/pull/233) - -## Deployment Plan - -We'll plan a quick beta roll-out of release `2019.12.19.0` to ensure the firmware build went -properly and then release the firmware to all Hotspots. diff --git a/devblog/2020-01-05-p2p-arp.mdx b/devblog/2020-01-05-p2p-arp.mdx deleted file mode 100644 index 179fa0141..000000000 --- a/devblog/2020-01-05-p2p-arp.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: libp2p ARP -date: 2020-01-06 -hide_table_of_contents: true -authors: [fvasquez] ---- - -Over time we have seen our gossip quality degrade as the network has become larger. Over the -holidays, we experienced multiple blockchain stalls. Some of these stalls were the result of -out-of-memory errors. This `2020.01.05.0` release adds an ARP mechanism to libp2p to pro-actively -refresh stale peer book entries. In addition, we fixed a couple of unfortunate typos in PoC receipt -validation. We also bumped the assumed valid block to 163,853 for faster resync times. - - - -## Content - -- ARP for peer book entries: PR: [libp2p/239](https://github.com/helium/erlang-libp2p/pull/239) -- Do not put RFC1918 addresses in peerbook entries by default: PR: - [libp2p/236](https://github.com/helium/erlang-libp2p/pull/236) -- Fix two typos in PoC receipt validation: PR: - [blockchain-core/328](https://github.com/helium/blockchain-core/pull/328) -- Add blockchain analyze and repair: PR: - [blockchain-core/324](https://github.com/helium/blockchain-core/pull/324) - -## Deployment Plan - -We plan to beta `2020.01.05.0` overnight and confirm that the GA release OTA downgrades successfully -before making it available to all hotspots. diff --git a/devblog/2020-01-06-poc-v6-update.mdx b/devblog/2020-01-06-poc-v6-update.mdx deleted file mode 100644 index 6093aa99b..000000000 --- a/devblog/2020-01-06-poc-v6-update.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: POC V6 -date: 2020-01-06 13:51 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -With this update we hope to alleviate some of the known concerns regarding POC path construction -while also fixing some overlooked typos. - - - -## Content - -We've updated the following chain vars: - -| Var | Old | New | Rationale | -| -------------- | --------- | ---- | ------------------------------------------------------------------------ | -| poc_version | 5 | 6 | Update poc version to disallow pathing with known impossible RSSI values | -| poc_typo_fixes | undefined | true | Introduce this chain var to trigger POC receipt validation typo fixes | - -## Related PRs - -- [blockchain-core#326. Fix incorrect bad RSSI check](https://github.com/helium/blockchain-core/pull/326). - -We have updated the `poc_version` to `6` which triggers filtering witnesses eligible for a potential -next hop when constructing a path to have reasonable RSSI values. We track known RSSI values as a -histogram in the ledger for each hotspot and can veriafiably prove that a hotspot A has witnessed -another hotspot B with an _impossible_ RSSI value in accordance with the Free Space Path Loss. - -- [blockchain-core#328. Fix two typos in POC receipt validation](https://github.com/helium/blockchain-core/pull/328). - -Prior to the typo fixes we were mistakenly dropping about 1/3rd of POC receipts when doing -validation. We expect the number of POC receipts to go significantly up with this change. However, -to not break consensus rules we have masked this change behind `poc_typo_fixes` chain var and have -activated it to be `true`. diff --git a/devblog/2020-01-07-throttle-arp.mdx b/devblog/2020-01-07-throttle-arp.mdx deleted file mode 100644 index fe7143d2d..000000000 --- a/devblog/2020-01-07-throttle-arp.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Throttle libp2p ARP -date: 2020-01-07 -hide_table_of_contents: true -authors: [fvasquez] ---- - -After adding an ARP mechanism to libp2p with the release of `2020.01.05.0` on January 6, 2020 we -noticed that gossip quality began to degrade again over time. To remedy this we decreased the ARP's -peer staleness time from 24 hours down to 6 minutes and began throttling ARP requests. We also -bumped the assumed valid block to 165,353 for faster resync times. - - - -## Content - -- Fix ARP peer staleness time and add a throttle for ARP requests: PR: - [libp2p/240](https://github.com/helium/erlang-libp2p/pull/240) -- Add peer refresh CLI command: PR - [blockchain-core/334](https://github.com/helium/blockchain-core/pull/334) - -## Deployment Plan - -We plan to beta `2020.01.07.0` for a couple of hours starting at 1:45 PM PDT and confirm that the GA -release OTA downgrades successfully before making it available to all hotspots. diff --git a/devblog/2020-01-08-atomic-flush.mdx b/devblog/2020-01-08-atomic-flush.mdx deleted file mode 100644 index f65388157..000000000 --- a/devblog/2020-01-08-atomic-flush.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: RocksDB Atomic Flush and Double Block Validation Avoidance release -date: 2020-01-08 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -We've been seeing issues of ledger corruption when nodes are syncing the chain with increased -frequency and have finally identified the fix. In the way we use rocksdb we split data in the ledger -and the blockchain across column families (eg token balances are distinct from hotspot information). -The ledger corrruption issues were when _part_ of a ledger update would commit but the other parts -would not. The fix was to enable the -[atomic flush](https://github.com/facebook/rocksdb/wiki/Atomic-flush) option in the rocksdb database -options which ensures that all updates in a batch update are committed atomically, even across -column families. - - - -Additionally we added a small optimization to block validation for bypassing validation for a block -the node is a signatory of. This helps the consensus group move to a new round faster, especially -when the block is large or slow to validate. Since the signer has already validated the block before -it signed it, validating it again is redundant. - -## Content - -- Add atomic flush option PRs: [relcast#38](https://github.com/helium/relcast/pull/38), - [libp2p#241](https://github.com/helium/erlang-libp2p/pull/241), - [blockchain-core#336](https://github.com/helium/blockchain-core/pull/336) -- Bypass double validation of self signed blocks PR: - [blockchain-core#337](https://github.com/helium/blockchain-core/pull/337) - -## Deployment Plan - -We plan to beta `2020.01.08.0` for a couple of hours starting around 7:00 PM PDT and confirm that -the GA release OTA downgrades successfully before making it available to all hotspots. diff --git a/devblog/2020-01-08-chain-var.mdx b/devblog/2020-01-08-chain-var.mdx deleted file mode 100644 index c83df2c27..000000000 --- a/devblog/2020-01-08-chain-var.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: PoC Rate Reduction -date: 2020-01-08 17:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -## Plan - -Shortly, we are going to issue a chain variable which will increase the Proof of Coverage (PoC) -interval from 30 blocks to 60 blocks. This will have the effect of reducing the rate of PoC requests -sharply, which should decrease long blocks going forward. - - - -Note that this may increase the number of low-reward epochs for some users, but it should average -out to the same rate of rewards in the longer run. - -## Rationale - -We initially picked the PoC interval of 30 blocks essentially because it was similar to our election -interval of 30 blocks. It meant that most Hotspots would challenge each election period. However, -validating PoC receipts remains challenging and computationally expensive. While this is something -that we're working to ameliorate (see PR -[core/318](https://github.com/helium/blockchain-core/pull/318)), it doesn't really get to the core -of the issue, which is that we are only beginning to understand the _quality_ of the results from -the PoC system. It's quite likely that even an interval of 60 is still far too often than is needed -for good quality results, and since the PoC system represents (necessary) overhead on the -functioning of the rest of the system, we hope to engage it as seldom as is possible while still -getting good results. As such, we intend to spend more time in the near future attempting to -understand system quality and to develop a metric that will allow us to understand how things like -the challenge interval affect the quality of the results that the PoC system delivers. Our PoC -system is quite novel, and we often make mistakes in its implementation. We appreciate your patience -as we work towards making this system deliver high-quality results for all of our stakeholders. - -Watch this space for more on the quality metric and potential future changes to the challenge -interval in the future. diff --git a/devblog/2020-01-08-emergency-fix.mdx b/devblog/2020-01-08-emergency-fix.mdx deleted file mode 100644 index b02d79065..000000000 --- a/devblog/2020-01-08-emergency-fix.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Emergency Patch for Assertion Transactions -date: 2020-01-10 12:00 -0800 -hide_table_of_contents: true -authors: [evanmcc, vagabond] ---- - -A number of assert location transactions had become stalled and were replayed from the API. -Unfortunately they all landed in the same few blocks, which became nearly impossible to process -quickly because of some index book-keeping overhead that must be done when gateways are asserted. -This release disabled some of that book-keeping, which is obsolete, and optimized other cases where -the expensive work doesn't need to be done. This should allow all of the stalled Hotspots (around 5% -of the fleet) to resume syncing and challenging. - - - -## Content - -- Improve performance of assert location transactions: - [blockchain-core#339](https://github.com/helium/blockchain-core/pull/339) - -## Deployment Plan - -This release was briefly in beta to assure ourselves of its safety, and then was deployed around 1PM -PST. diff --git a/devblog/2020-01-16-poc7.mdx b/devblog/2020-01-16-poc7.mdx deleted file mode 100644 index 477067be3..000000000 --- a/devblog/2020-01-16-poc7.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -layout: post -title: Hierarchical Targeting Images and Chain Variables -date: 2020-01-16 21:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -### Block Weather - -As you may have noticed, block times recently have regularly not been meeting their typical sixty -second deadline with any regularity. You can read more about how we deal with slow block times and -long elections -[here](https://developer.helium.com/blockchain/mining-token-rewards#hnt-proration-and-slow-block-times). - - - -In a [recent post](https://docs.helium.com/blog/2020/01/08/chain-var.html), we discussed a reduction -in the rate of Proof of Coverage (PoC) challenges. While this seemed to briefly be effective, we -quickly found ourselves back where we started with the growth of the network. While slowing the rate -of challenge did have the intended effect, soon after we fixed a number of bugs and reissued a large -number of location assertion transactions that had gotten lost, making the network even larger, and -taking back most of the ground we had gained. While we were observing these changes, we have been -working on a feature called -[hierarchical targeting](https://github.com/helium/blockchain-core/pull/318). This pull requests and -other related requests changes how the _initial target_ of a PoC challenge. The initial target is -the first step of a PoC challenge path. Previously, this Hotspot was selected from the entire list -of hotspots. Somewhat obviously, this scales poorly as the network grows (recall, that while there -are only a few thousand Hotspots at this point, they're all running on relatively under-powered -hardware). This code uses a new index that is built and maintained on disk of Hotspots that are -relatively nearby each other (in [H3](https://eng.uber.com/h3/) terms, they all share the same -parent hex at resolution 5). - -### Contents - -- _Hierarchical Targeting_: Don't pull all Hotspots for every target selection and receipt - validation. PRs [core/318](https://github.com/helium/blockchain-core/pull/318), - [miner/287](https://github.com/helium/miner/pull/287) -- _Reduce Memory Usage_: Another issue that we've been running into is Hotspot miners running out of - memory and getting restarted by the linux OOM killer. These PRs start our efforts to make this - happen less often: [miner/286](https://github.com/helium/miner/pull/286), - [libp2p/242](https://github.com/helium/erlang-libp2p/pull/242), - [libp2p/243](https://github.com/helium/erlang-libp2p/pull/243), - [libp2p/244](https://github.com/helium/erlang-libp2p/pull/244) - -### Plan - -We'll beta this release overnight, then GA in the morning on Friday, Jan 17. Once we're satsfied -that things are stable, we'll commit a chain variable transaction setting -`poc_target_hex_parent_res` to 5 and `poc_version` to 7. diff --git a/devblog/2020-01-27-oom-fix.mdx b/devblog/2020-01-27-oom-fix.mdx deleted file mode 100644 index ffa7d0039..000000000 --- a/devblog/2020-01-27-oom-fix.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: OOM Abatement -date: 2020-01-27 10:30 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -### Block Weather - -After the Proof of Coverage v7 (PoC) firmware release, block times quickly began to suffer again. -This time, the cause seems to be the Linux Out of Memory subsystem killing the miner process as it -begins to use too much memory. We've tracked this down to RocksDB, which we use for storage for a -number of subsystems, using too much memory. We applied a large number of tunings and upgraded the -version of RocksDB, picking up a number of fixes and enhancements along with some memory use -improvements. - - - -Additionally, we've included a new garbage collector for some PoC corner cases which should help -keep the ledger small and consistent from Hotspot to Hotspot. - -### Contents - -- _Tune RocksDB_: Various memory-related tunings and a version upgrade. PRs: - [core/354](https://github.com/helium/blockchain-core/pull/354), - [miner/297](https://github.com/helium/miner/pull/297) -- _PoC GC_: Clean up stale PoC request data in the ledger. PRs: - [core/307](https://github.com/helium/blockchain-core/pull/307) - -### Plan - -We'll beta this release briefly starting around 11AM PST, then GA in the afternoon today, Jan 27. diff --git a/devblog/2020-01-28-block-time-improvements.mdx b/devblog/2020-01-28-block-time-improvements.mdx deleted file mode 100644 index 98f1d0acc..000000000 --- a/devblog/2020-01-28-block-time-improvements.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Block production speed improvements -date: 2020-01-28 15:40 -0800 -hide_table_of_contents: true -authors: [vagabond] ---- - -### Block Weather - -While the out of memory improvements from yesterday have helped, the erratic block times have -returned. We believe this has to do with the gossip network topolology degrading over time (an OTA -resets the gossip network connections as the nodes reboot). We have identified some more fixes that -should help block propogation times between the consensus group which should limit the impact of bad -gossip topologies on the block production rate. - - - -### Contents - -- _Cleanup Proof of Coverage state machine_: PR: - [miner/277](https://github.com/helium/miner/pull/277) -- _Fix some deadlocks in blockchain core_: PR: - [core/357](https://github.com/helium/blockchain-core/pull/357) -- _Fastforward consensus members that did not sign the block and gossip full block signature list_: - PR: [miner/300](https://github.com/helium/miner/pull/300) - -### Plan - -We'll beta this release briefly starting around 4pm PST and release it to general availability this -afternoon or evening. diff --git a/devblog/2020-01-29-challenge-fix.mdx b/devblog/2020-01-29-challenge-fix.mdx deleted file mode 100644 index 773be80dd..000000000 --- a/devblog/2020-01-29-challenge-fix.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: Fix for Too Few Challenges -date: 2020-01-29 15:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -### Block Weather - -While the recent releases have done a fairly good job at cleaning up block times, the last firmware -image introduced a bug that can prevent Hotspots from challenging. This release fixes that bug and -should restore the normal challenge rate. - - - -### Contents - -- _Fix PoC State Machine Loop_: PR: [miner/303](https://github.com/helium/miner/pull/303) - -### Plan - -We'll beta this release briefly starting around 2pm PST and release it to general availability this -afternoon. diff --git a/devblog/2020-01-30-emergency-oom-fixes.mdx b/devblog/2020-01-30-emergency-oom-fixes.mdx deleted file mode 100644 index 6532d8e09..000000000 --- a/devblog/2020-01-30-emergency-oom-fixes.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: Emergency Out of Memory Patch Release -date: 2020-01-30 20:50 -0800 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -### Block Weather - -Despite our prior efforts, we have still been tracking (and debugging) high memory usage in our -storage engine, RocksDB. We have identified some additional fixes and this issue has become critical -as of block `186592`. This block was somewhat large and has triggered Out of Memory kills on much of -the network as it propogates out. This release contains improvements that should allow the network -to absorb past that block. - - - -Additionally this release bumps the assume-valid block to `186622`. - -### Contents - -- _RocksDB cleanups in ledger_: PR: [core/359](https://github.com/helium/blockchain-core/pull/359) -- _Compact libp2p peerbook on startup_: PR: - [libp2p/251](https://github.com/helium/erlang-libp2p/pull/251) -- _Increase libp2p relay lifetimes_: PR: - [libp2p/252](https://github.com/helium/erlang-libp2p/pull/252) - -### Plan - -We'll beta this release briefly starting around 9pm PST and release it to general availability ASAP -thereafter. diff --git a/devblog/2020-01-31-time-catchup.mdx b/devblog/2020-01-31-time-catchup.mdx deleted file mode 100644 index 0a4d914c5..000000000 --- a/devblog/2020-01-31-time-catchup.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Upcoming Changes to Block Time Targets -date: 2020-01-31 13:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -## Executive summary - -Block time disruptions have lowered the rate of token production from the chain, and we're -implementing a mechanism to shorten block times when this is the case, so that we catch up to our -targeted production rates of 5 million HNT per month if we experience long block times. - - - -### Details - -Currently, the lifetime average block interval is around 85 seconds, due to some long pauses, halts, -and various growing pains. While we do our best to maintain good block times, we are ultimately -running a complex distributed system on commodity networks and small machines running on mains -power. Some level of disruption is inevitable. - -Understandably, this variable rate of token emission is concerning, and we have put some thought -into various alternatives. While we considered time-based proration, we were concerned that the -incentives there were not particularly good, as anyone who wanted to minimize work while maximizing -return would simply do what they could to slow times down by interfering with the consensus group. -The strategy we have eventually settled on is a deterministic speedup. Typically, the next target -block time is calculated by taking the time of the last block and adding a chain variable called -`block_time`, which is currently 60000ms. If that time is in the past, we start immediately. - -The current proposal, implemented in [this PR](https://github.com/helium/miner/pull/306), takes the -lifetime average of block times by finding the time at block 187000 (a recent round number after the -latest period of disruption), comparing it with the time from the last block, and nudging the target -time back by the difference. Originally, we took a moving average over the last several hundred -blocks, but we were concerned that this would be too expensive on the modest Hotspot hardware. This -strategy, cribbed from NTP, means that we'll gently accelerate (and pleasingly, decelerate, should a -bug cause us to produce blocks too quickly) until the average block time is on target. diff --git a/devblog/2020-02-03-lorawan.mdx b/devblog/2020-02-03-lorawan.mdx deleted file mode 100644 index 7207ab676..000000000 --- a/devblog/2020-02-03-lorawan.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: post -title: Enabling Beta Support for LoRaWAN -date: 2020-02-03 14:00 -0800 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -## Executive summary - -We have enabled LoRaWAN support on the Helium network. This has not been without compromises but we -feel we have found a solution that should work for the vast majority of existing LoRaWAN devices. - - - -The Helium Console has been updated with support for generating LoRaWAN AppEUIs and AppKeys that can -be provisioned to existing LoRaWAN devices. We have decided to use the 7th bank of 8 channels in the -US902-928 LoRaWAN regional parameters. The specific channel frequencies are (in mHz) 911.9, 912.1, -912.3, 912.5, 912.7, 912.9, 913.1, 913.3. These channels are 125kHz wide and use 4/5 coding. Devices -that support enabling an 8 channel sub bank of the defined 64 default channels should use that -option, devices which join across all 64 channels must wait to hit one of the enabled channels. A -subsequent ADR adjustment will be sent after joining. - -We are currently targeting class A devices and the LoRaWAN 1.0.2 spec. We will work on adding -support for class C devices and 1.0.3 and 1.1 features that make sense in the future. - -### Details - -LoRaWAN is more like layer 3 and Helium needs more of a layer 2 protocol, which means that we've had -to bend the rules of LoRaWAN a bit. Speficially we abuse the DeviceID issued to joining devices to -be a routing identifier rather than a unique device ID and instead on the destination router we -brute-force the Message Integrity Check to discover what device actually sent the packet. This is -similar to something the Things Network does, but it does introduce some ambiguity about packet -provenence while the packet is in transit. We hope to address some of these shortcomings in the -future with a LoRaWAN extension that compliant devices will be able to use to improve the packet -handoff between Helium Hotspots and Routers. - -Unfortunately, due to the frequency changes required to be LoRaWAN compatible, we will be breaking -compatibility with any active LongFi devices. Simply changing the frequencies used will be -sufficient but we don't currently expect to be able to dedicate more time to LongFi support as we -have decided to focus on providing seamless LoRaWAN support to take advantage of the large number of -devices with difficult, or impossible to change LoRaWAN stacks. diff --git a/devblog/2020-02-07-poc-v8.mdx b/devblog/2020-02-07-poc-v8.mdx deleted file mode 100644 index 30036889e..000000000 --- a/devblog/2020-02-07-poc-v8.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -layout: post -title: PoC v8 -date: 2020-02-09 18:30 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -### Summary - -We have been steadily gathering data on the performance of Proof-of-Coverage and are ready to -release the PoC version 8 update. This update brings a few key bug fixes and enhancements detailed -below. - - - -### Contents - -- **Target filtering**: With the introduction of hierarchical targeting we stopped checking whether - the target Hotspot is actually eligible to be a target. This was largely done for performance - improvements, however, we are re-introducing target filtering with PoC v8. We believe we have - mitigated the performance drawbacks by limiting the target search space addressed in PoC v7. We - _know_ that there are Hotspots on the network which are not participating in any poc/reward - activity for a variety reasons (offline, etc), and there is no reason to attempt to target or path - through them. - -- **Witness RSSI centrality metrics**: As the network grows we have gathered enough data to make - more conscientious decisions around which Hotspots to include to when creating PoC paths. In order - to do this we split the witness histogram into two buckets, one being a "good" bucket the other - being "bad". The probability of picking a witness as a next hop in the path is now governed by the - ratio of good vs bad counts. We believe this to be a better approach rather than simply declaring - a witness as bad by looking at RSSI values. The fact that RSSI alone is not a good enough metric - to make such decisions hinders better paths, and as a result we plan on adding additional witness - data collection to make better decisions going forward. - -- **Address next hop randomness bug**: Thanks to the community we identified a bug in the next hop - selection algorithm where the random seed for target selection would conflict with the seed for - the _first_ subsequent hop when creating a path. We've addressed this bug by generating a random - seed **once** for targeting, and propogating that through the target/pathing algorithm. - -- **Fix extremely long next hops**: We've introduced a new chain variable `poc_max_hop_cells` which - would limit how far away a potential next hop can be. It is defined in terms of h3 grid cells. - -- **Ensure new consensus members have latest block**: We've added code to prevent slow block gossip - holding up a new election round by trying to fast-forward all the new consensus group members to - the same block. - -- **Bump assumed valid block**: We've also bumped the assumed valid block to 196777. - -- **Adjust some peerbook gossip rules**: We're trying some changes to peerbook gossip to try to keep - peers fresher. - -### Chain Var Proposal - -| Var | Existing | Proposed | Rationale | -| -------------------- | --------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| poc_version | 7 | 8 | Bump poc_version | -| poc_v4_prob_rssi_wt | 0.2 | 0.0 | Zeroed because centrality weight takes precedence with v8 | -| poc_v4_prob_time_wt | 0.2 | 0.0 | Zeroed because centrality weight takes precedence with v8 | -| poc_v4_prob_count_wt | 0.2 | 0.0 | Zeroed because centrality weight takes precedence with v8 | -| poc_v4_randomness_wt | 0.4 | 0.5 | Increased to still keep 50% chance of picking a random witness as next hop _after_ filtering. | -| poc_centrality_wt | undefined | 0.5 | Introduced to pick potentially legitimate witnesses as next hops when constructing paths. | -| poc_max_hop_cells | undefined | 2000 | Introduced to limit max next hop distance. A rough estimate is given by: sqrt(3).a.(n-1), where, a: hex_edge_length and n: poc_max_hop_cells. For hexagons at resolution 12, ~32.5kms | -| poc_good_bucket_high | undefined | -80 | Upper bound for a good RSSI value | -| poc_good_bucket_low | undefined | -115 | Lower bound for a good RSSI value | - -### Related PRs - -- [blockchain-core#365](https://github.com/helium/blockchain-core/pull/365): Support for PoC v8. -- [miner#291](https://github.com/helium/miner/pull/291): Miner side support for PoC V8. -- [miner#319](https://github.com/helium/miner/pull/319): Fast forward new consensus members to - prevent slow block gossip. -- [miner#320](https://github.com/helium/miner/pull/320): Bump assumed valid block to 196777. -- [libp2p#254](https://github.com/helium/erlang-libp2p/pull/254): Store similar peers, add debugging - to relcast exits - -### Plan - -We've been betaing this release since Saturday morning and plan to release it go General -Availibility this evening. We will then activate PoCv8 sometime Monday morning. diff --git a/devblog/2020-02-11-p2p-arp-adjustment.mdx b/devblog/2020-02-11-p2p-arp-adjustment.mdx deleted file mode 100644 index 5963244b8..000000000 --- a/devblog/2020-02-11-p2p-arp-adjustment.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: libp2p ARP Adjustment -date: 2020-02-11 -hide_table_of_contents: true -authors: [fvasquez, evanmcc] ---- - -### Block Weather - -In an effort to stabilize block times the `2020.02.11.0` release adds fixes to libp2p and -blockchain-core. Additionally this release bumps the assume-valid block to `201493`. - - - -### Contents - -- _Adjust libp2p gossip strategies_: PR: - [libp2p/257](https://github.com/helium/erlang-libp2p/pull/257) -- _Do not start additional sync handlers_: PR: - [blockchain-core/353](https://github.com/helium/blockchain-core/pull/353) - -### Plan - -We will beta this overnight starting around 5 PM PST and release it to general availability the -following morning. diff --git a/devblog/2020-02-14-chain-var-18.mdx b/devblog/2020-02-14-chain-var-18.mdx deleted file mode 100644 index 3d503a7a3..000000000 --- a/devblog/2020-02-14-chain-var-18.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Chain Variable 18 -date: 2020-02-14 10:57 -0800 -hide_table_of_contents: true -authors: [vihu, evanmcc] ---- - -### Summary - -We continue to receive excellent feedback from the community regarding some of the decisions we made -with the introduction of PoC V8. This update clarifies the new chain variable transaction we issued -on Thu 13 Feb 2020 09:29:39 PM UTC. - - - -### Concerns - -- **Consensus group membership not geographically diverse**: In order to ensure that the consensus - members are geographically diverse, we have reduced the `election_cluster_res` from `8` to `4`. - -- **Lower bucket for good RSSI values too strict**: In order to allow witnesses seen at RSSI values - below our initial expectation to be considered good enough for constructing paths, we have reduced - the lower threshold `poc_good_bucket_low` from `-115` to `-118`. Note that since this is a - logarthmic scale, we believe that any RSSI below -118 is likely too low to be considered good - enough. - -### Audit - -You can find the chain variable transaction details -[here](https://github.com/helium/miner/blob/master/audit/var-18.md). diff --git a/devblog/2020-02-19-consensus-group-and-sync-fixes.mdx b/devblog/2020-02-19-consensus-group-and-sync-fixes.mdx deleted file mode 100644 index 4633927a3..000000000 --- a/devblog/2020-02-19-consensus-group-and-sync-fixes.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: Consensus Group Crash Loops and Block Sync Fixes -date: 2020-02-19 09:20 -0800 -hide_table_of_contents: true -authors: [vagabond, fvasquez, evanmcc] ---- - -### Summary - -In a previous release, we attempted to resolve some rare issues with consensus members forgetting -they're in the consensus group. Unfortunately this traded a rare consensus member failure for a rare -crash loop. This issue led to the long block over the weekend and we've been testing a fix for the -last couple days. - - - -Additionally it was observed that nodes with clock skew behind the block time would refuse to sync. -This has also been corrected and validarted to unstick such nodes. - -Additionally we've landed a bugfix for a rare division by 0 during PoC packet construction and -bumped the assume-valid block to 211438. - -### Contents - -- **Consensus member crash loop**: [miner#326](https://github.com/helium/miner/pull/326) - [libp2p#259](https://github.com/helium/erlang-libp2p/pull/259) - -- **Sync improvements**: [core#373](https://github.com/helium/blockchain-core/pull/373) - [core#374](https://github.com/helium/blockchain-core/pull/374) - -- **Divide by zero fix**: [core#372](https://github.com/helium/blockchain-core/pull/372) - -- **Assume-valid bump to 211438**: [miner#327](https://github.com/helium/miner/pull/327) - -### Plan - -We've been betaing this `2020.02.18.1` release overnight and plan to roll it out to general -availability shortly. diff --git a/devblog/2020-03-07-multi-payment-txns.mdx b/devblog/2020-03-07-multi-payment-txns.mdx deleted file mode 100644 index 7f1d34c48..000000000 --- a/devblog/2020-03-07-multi-payment-txns.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Multi-payment Transactions -date: 2020-03-07 -hide_table_of_contents: true -authors: [fvasquez, vihu, evanmcc] ---- - -### Summary - -This `2020.03.07.0` release adds support for multi-payment transactions and includes bug fixes for -repairing the blockchain on-disk. Additionally this release bumps the assumed valid block to -`234600`. - - - -### Contents - -- _Don't crash loop on ledger mismatch so we can attempt repair_: - [miner/#266](https://github.com/helium/miner/pull/266) -- _Resync the chain if the ledger is missing or at height 0_: PR: - [blockchain-core/#331](https://github.com/helium/blockchain-core/pull/331) -- _Support nonce in HTLC transactions_: PR: - [blockchain-core/378](https://github.com/helium/blockchain-core/pull/378) -- _Add payment_v2 transactions for multiple payees_: PR: - [blockchain-core/382](https://github.com/helium/blockchain-core/pull/382) - -### Plan - -We will beta `2020.03.07.0` Saturday morning and release it to general availability early that -afternoon. diff --git a/devblog/2020-03-13-command-line-interface-for-console.mdx b/devblog/2020-03-13-command-line-interface-for-console.mdx deleted file mode 100644 index bb80907e9..000000000 --- a/devblog/2020-03-13-command-line-interface-for-console.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: Command Line Interface for Console -date: 2020-03-13 -hide_table_of_contents: true -authors: [lthiery] ---- - -### Summary - -In order to streamline device uploading to Helium Console, and, in particular, migrations from The -Things Network (TTN) Console, we are releasing -[pre-built executables](https://github.com/helium/helium-console-cli/releases) and the -[source code](https://github.com/helium/helium-console-cli) of helium-console-cli. - - - -This public release includes the following features: - -- create and delete devices records, using (app_eui, app_key, dev_eui) or UUID -- list all device records from an organization -- create and delete labels by UUID -- create and delete device labels, by using (device_uuid, label_uuid) -- import devices from The Things Network (TTN) with optional labeling with app i - - d - -### Notes - -- **Console 'api/v1' Endpoint**: a new endpoint and the ability to generate keys that don't expire - has been added to Console. The endpoints have been rate limited in the following way: - - - a single user can create a maximum of 10k labels and devices - - the API is rate limited to 100 calls per second - -- **API Keys stored in Plain Text**: currently, when the user types in their API keys, it is stored - in the directory of the executable in plain text. diff --git a/devblog/2020-03-16-app-version-160.mdx b/devblog/2020-03-16-app-version-160.mdx deleted file mode 100644 index 121370cfd..000000000 --- a/devblog/2020-03-16-app-version-160.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: App Version 1.6.0 -date: 2020-03-16 -hide_table_of_contents: true -authors: [cokes518] ---- - -### Summary - -A new app version 1.6.0 is now available for iOS and Android - - - -### Contents - -Hello Helium Community! - -In this release, we included big changes to our notification system that you’ll start to see more of -in the coming weeks. Soon you’ll receive information about your Hotspots, earnings, and more. - -Also in this update the introduction of “Witness too close”. What does this mean? It means if a -Hotspot is within 300ft of witnessing a Hotspot transmit and reports it to the challenger, the -Hotspot will not be included in the witness list of that challenge. - -A witness that is too close may not provide enough information about the validity of the hop in the -challenge. - -- Example: if a Hotspot in an open office setting sent a packet and another Hotspot heard the - transmission 50ft away. It's not clear if the transmission made it outside the office building to - another Hotspot down the street and doesn't tell the system enough information about the success - of the hop. - -When a witness is considered too close, they will appear as grey in that challenge. - -This update also removes the alert Hotspots get when their score declines, updated terminology in -diagnostic reports, and other small bug fixes. diff --git a/devblog/2020-03-16-rework-txn-manager.mdx b/devblog/2020-03-16-rework-txn-manager.mdx deleted file mode 100644 index ff8552dd5..000000000 --- a/devblog/2020-03-16-rework-txn-manager.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: Rework Transaction Manager -date: 2020-03-16 -hide_table_of_contents: true -authors: [fvasquez, evanmcc] ---- - -### Summary - -This `2020.03.16.0` release includes a rework of the blockchain transaction manager. Additionally -this release bumps the assumed valid block to `249675`. - - - -### Contents - -- _Rework transaction manager_: PR: - [blockchain-core/#370](https://github.com/helium/blockchain-core/pull/370) - -### Plan - -The plan was to beta `2020.03.13.1` over the weekend, bump the assumed valid block Monday morning -then release `2020.03.16.0` to general availability. diff --git a/devblog/2020-03-18-voting-poc-fix.mdx b/devblog/2020-03-18-voting-poc-fix.mdx deleted file mode 100644 index 258bf2133..000000000 --- a/devblog/2020-03-18-voting-poc-fix.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -layout: post -title: Presence Voting and PoC Bug Fix -date: 2020-03-18 17:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -### Block Weather - -For that past month or so, our various fixes and optimizations have done a fairly good job of -preventing long blocks and keeping token emissions on schedule. For more details see -[here](https://docs.helium.com/blog/2020/01/27/oom-fix.html) and -[here](https://docs.helium.com/blog/2020/01/31/time-catchup.html). - - - -However, we've still not managed to restore our 60s block times. Because of this, we're shipping a -firmware soon that will contain a new feature and an adjustment of existing behavior that should -allow us to close the gap and to stay much closer to optimal token production rates. Firstly, we're -adjusting the catch-up time feature to be more aggressive in its adjustments, which should allow us -to recover from long block times more quickly. Secondly, we're introducing a consensus feature which -records which consensus members completed the consensus protocol round correctly and quickly, and -also which other members each member sees during its own round. Once this feature is activated (look -for a chain var soon), we should be able to remove downed consensus members much more quickly and -reliably and will more often remove those nodes which are consistently lagging behind due to poor -internet connections or faulty hardware. As always, see the PRs below for more details. - -Additionally this firmware contains various bug fixes, including an important fix for the Proof of -Coverage state machine, which can, in certain circumstances, become stalled indefinitely (or at -least until the Hotspot restarts). - -### Contents - -- _Presence Voting_: PRs: [miner/340](https://github.com/helium/miner/pull/340), - [core/392](https://github.com/helium/blockchain-core/pull/392) -- _Make Catch-up More Aggressive_: PR: [miner/348](https://github.com/helium/miner/pull/348) -- _Fix PoC Stalls_: PRs: [core/398](https://github.com/helium/blockchain-core/pull/398), - [libp2p2/264](https://github.com/helium/erlang-libp2p/pull/264) - -### Plan - -This was deployed to the beta group around 6PM PST on Wednesday the 18th and will run until the -morning of the 19th, when we'll release it to GA. diff --git a/devblog/2020-03-26-htlc-redeems.mdx b/devblog/2020-03-26-htlc-redeems.mdx deleted file mode 100644 index c46fc4915..000000000 --- a/devblog/2020-03-26-htlc-redeems.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: Fix Validating HTLC Redeem Transactions -date: 2020-03-26 -hide_table_of_contents: true -authors: [fvasquez, evanmcc] ---- - -### Summary - -This `2020.03.26.0` release fixes a bug when validating HTLC redeems and adds a timeout to sync -processes so they do not get stuck forever. Additionally this release bumps the assumed valid block -to `263260`. - - - -### Contents - -- _Fix a badmatch when validating HTLC redeems_: PR: - [blockchain-core/#405](https://github.com/helium/blockchain-core/pull/405) -- _Add timeout to sync process_: PR: - [blockchain-core/#406](https://github.com/helium/blockchain-core/pull/406) - -### Plan - -A `2020.03.25.0` release was deployed to the beta group around 2 PM PST on Wednesday the 25th. If -overnight testing goes well we will tag and build `2020.03.26.0` for immediate release to general -availability. diff --git a/devblog/2020-03-27-console-updates-backend.mdx b/devblog/2020-03-27-console-updates-backend.mdx deleted file mode 100644 index 9e2061a27..000000000 --- a/devblog/2020-03-27-console-updates-backend.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: Console Backend and Integration Updates -date: 2020-03-27 -hide_table_of_contents: true -authors: [jdgemm, evanmcc] ---- - -### Summary - -We made recent updates to Console that included backend changes and apologize if the update may have -caused any disruption for existing users. - - - -Although Console is still in beta, going forward we’ll inform the community of relevant updates -before deployment. - -### Contents - -Backend changes/fixes: - -- Identical payloads sent from multiple Hotspots, within a one second window, will be aggregated so - only a single payload will be pushed to integrations. -- Updated the payload schema (included list of Hotspots, labels). -- Fixed fields in payload (frame_up/down, fcnt, and timestamp). - -Integrations: - -- Added myDevices Cayenne and AWS IoT integrations. diff --git a/devblog/2020-03-31-sync-fix.mdx b/devblog/2020-03-31-sync-fix.mdx deleted file mode 100644 index 8f36ab691..000000000 --- a/devblog/2020-03-31-sync-fix.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Block Gossip and Sync Strategy Adjustment -date: 2020-03-31 13:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -### Block Weather - -Recently we've seen some gossip issues, where the consensus group and some small number of Hotspots -manage to forge ahead on schedule, but the bulk of the Hotspots and their ancillary services fall, -in lockstep, behind. - - - -Since Proof of Coverage (PoC) receipts are only valid for a short period of time, most of them begin -to fail and more and more nodes fall out of step with the consensus group. At some point this -morning, we experienced a prolonged and severe drop in PoC receipt rates (challenge rates are still -mostly fine, due to recent fixes). Manually syncing the full nodes that we maintain in the cloud did -not manage to fix the issue, so we're doing a single PR release that adjusts sync to be more -aggressive, in hopes that this lessens the issue in the future. There will no doubt be a few more -minor gossip adjustments in the coming days. - -The PR (details below) changes which time Hotspots pay attention to when they try a new sync, which -should allow them to sync more often. Without a long delay (originally introduced to fix an issue -with clock skew, but too broadly applied) we should be able to keep up with gossip more -consistently. - -### Contents - -- _Sync Strategy Adjustment_: PRs: [core/409](https://github.com/helium/blockchain-core/pull/409) - -### Plan - -On the morning of Tuesday, March 31, PoC receipts went to close to 0 for a quite a long time. In -addition to manual intervention, this PR was rushed into an image which was briefly betaed and then -deployed to GA around 1:30PM PDT. diff --git a/devblog/2020-04-01-block-ledger-mismatch.mdx b/devblog/2020-04-01-block-ledger-mismatch.mdx deleted file mode 100644 index f85f78946..000000000 --- a/devblog/2020-04-01-block-ledger-mismatch.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: Handle block and ledger height mismatch -date: 2020-04-01 -hide_table_of_contents: true -authors: [fvasquez] ---- - -### Summary - -This `2020.04.01.0` release fixes a bug that results in hotspots getting stuck syncing. A gateway -OUI field was also added to the blockchain protocol. The new gateway OUI field is a breaking change -that requires a software upgrade. - - - -### Contents - -- _Handle cases when block or ledger height disagree_: PR: - [blockchain-core/#410](https://github.com/helium/blockchain-core/pull/410) -- _Move the OUI upgrade and field to master_: PR: - [blockchain-core/#397](https://github.com/helium/blockchain-core/pull/397) - -### Plan - -A `2020.04.01.0` release was deployed to the beta group around 5:30 PM PST on Wednesday April 1st. -If overnight testing goes well we will release `2020.04.01.0` to general availability the following -morning. diff --git a/devblog/2020-04-03-console-backend-ui-updates.mdx b/devblog/2020-04-03-console-backend-ui-updates.mdx deleted file mode 100644 index 201ac2d19..000000000 --- a/devblog/2020-04-03-console-backend-ui-updates.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: Console Backend phase 2 and UI Updates -date: 2020-04-03 -hide_table_of_contents: true -authors: [jdgemm] ---- - -### Summary - -Key user experience enhancements: - -- Labels mapped to integrations are easily identifiable by Integration icon. -- Device details: includes packet transferred numbers. -- Device index page includes: Labels, Integration, Frames up, Frames down, Date added, Last - connected. - - - -Another round of updates planned for the Console backend, this Monday, April 6. - -### Impact of planned update - -Device events stored prior to Monday’s update will be purged from Console. - -### Planned updates - -Backend update phase 2 - -- The backend will aggregate Integration reponses (over 3s) and report them all at once to Console. -- Update data sent to Integrations: - - Adding `devaddr` field - - Renaming any `timestamp` field to `reported_at` - - Adding `frequency`, `spreading`, and `status` to each Hotspot object -- Update data sent to Console: - - Same as above - - Adding `port` field diff --git a/devblog/2020-04-07-api-route-changes.mdx b/devblog/2020-04-07-api-route-changes.mdx deleted file mode 100644 index 61f658f54..000000000 --- a/devblog/2020-04-07-api-route-changes.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: API Route Changes -date: 2020-04-07 11:27 -0700 -hide_table_of_contents: true -authors: [madninja] ---- - -The new API has been deployed to api.helium.wtf (development) and api.helium.io (prod) for a couple -of weeks now and as part of moving the mobile application to it we realized that two routes were not -quite consistent. - - - -`/v1/blocks/:height` and `/v1/blocks/hash/:hash` currently return a paged response that includes -both the high level block details _and_ a paged list of transactions. - -In order to make paging more consistent and not return duplicate information, we're going to: - -1. Add new routes `/v1/blocks/:height/transactions` and `/v1/blocks/hash/:hash/transactions` to get - a paged list of transactions for a block at a given height or hash, respectively. - -2. Remove the _transactions_ field from the result of `/v1/blocks/:height` and - `/v1/blocks/hash/:hash`. - -This will require a change from code using the API to retrieve transactions, but should make API -usage more consistent. - -### Deployment - -This API change is ready in a [pull request](https://github.com/helium/blockchain-http/pull/42) and -will be merged and deployed to api.helium.wtf and api.helium.io on April 7. diff --git a/devblog/2020-04-07-multiple-default-routers.mdx b/devblog/2020-04-07-multiple-default-routers.mdx deleted file mode 100644 index 715585ce6..000000000 --- a/devblog/2020-04-07-multiple-default-routers.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: Support Multiple Default Routers -date: 2020-04-07 -hide_table_of_contents: true -authors: [fvasquez] ---- - -### Summary - -This `2020.04.07.0` release adds support for multiple default LoRa routers to miner. A bug fix for -the libp2p NAT server crashing is also included. Additionally this release bumps the assumed valid -block to `282180`. - - - -### Contents - -- _Support multiple default routers_: PR: [miner/#358](https://github.com/helium/miner/pull/358) -- _Don't crash the NAT server on bad cache insert_: PR: - [libp2p/#266](https://github.com/helium/erlang-libp2p/pull/266) - -### Plan - -A `2020.04.07.0` release was deployed to the beta group around 5:30 PM PST on Tuesday April 7th. If -overnight testing goes well we will release `2020.04.07.0` to general availability the following -morning. diff --git a/devblog/2020-04-10-console-updates.mdx b/devblog/2020-04-10-console-updates.mdx deleted file mode 100644 index 4af68c188..000000000 --- a/devblog/2020-04-10-console-updates.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: Console AWS IoT Downlink and upcoming Debug mode -date: 2020-04-10 -hide_table_of_contents: true -authors: [jdgemm, madninja] ---- - -### Key feature updates - -- AWS IoT downlink completed, more details about documentation - [here](https://developer.helium.com/console/integrations/awsiotcore). -- This week pushed out backend updates: see previous blog - [here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/04/03/console-backend-ui-updates.html). -- Dedudped data sent from Helium Hotspots. - - - -### UI updates/fixes - -- Label index, quick action menu: added ability to add integrations. -- Updated UI to make it easier to view device details. -- Confirmation needed before deleting label mapped to integration. -- AWS Integration name displays correctly. - -### Key planned updates - -Debug mode- Once enabled Debug mode allows users to view device payloads on Console in real time. -Due to privacy concerns and to reduce the attack surface, payloads will only be displayed on Console -if Debug mode is enabled. diff --git a/devblog/2020-04-13-forget-wifi-networks.mdx b/devblog/2020-04-13-forget-wifi-networks.mdx deleted file mode 100644 index 16faa2298..000000000 --- a/devblog/2020-04-13-forget-wifi-networks.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: Forget Wi-Fi Networks -date: 2020-04-13 -hide_table_of_contents: true -authors: [fvasquez] ---- - -### Summary - -This `2020.04.13.0` release upgrades gateway-config to enable the removal of saved Wi-Fi networks -from hotspots via the mobile app. A bug fix for a recent regression that disabled GPS on the -hotspots is also included. - - - -### Contents - -- _Delete saved profiles for an unseen network_: PR: - [gateway-config/#58](https://github.com/helium/gateway-config/pull/58) -- _Add configured Wi-Fi services characteristic_: PR: - [gateway-config/#57](https://github.com/helium/gateway-config/pull/57) -- _Add GATT characteristic for removal of Wi-Fi networks_: PR: - [gateway-config/#56](https://github.com/helium/gateway-config/pull/56) - -### Plan - -A `2020.04.13.0` release was deployed to the beta group around 1:00 PM PST on Monday April 13th. If -overnight testing goes well we will release `2020.04.13.0` to general availability the following -morning. diff --git a/devblog/2020-04-14-prefilter.mdx b/devblog/2020-04-14-prefilter.mdx deleted file mode 100644 index 1f2a9ade6..000000000 --- a/devblog/2020-04-14-prefilter.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Transaction Throughput Fix -date: 2020-04-16 14:30 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -We've been doing some internal work to increase transaction throughput from our API, and this has -required some Hotspot side support, with respect to how the consensus group prefilters incoming -transactions. The old code wasn't playing well with ordered transactions (multiple consecutive -payments, for example). Expect more related fixes in the next few releases. - - - -This release also bumps the assumed valid block. - -### Contents - -- _Adjust Assumed Valid_: PRs: [miner/367](https://github.com/helium/miner/pull/367) -- _Throughput Prefilter Fix_: PRs: [core/409](https://github.com/helium/miner/pull/363) - -### Plan - -This image was released to the beta before noon on Thursday the 16th PST, and will be betaed for a -short time. We anticipate releasing it to GA before the end of the day. diff --git a/devblog/2020-04-15-helium-wallet-1-2-0.mdx b/devblog/2020-04-15-helium-wallet-1-2-0.mdx deleted file mode 100644 index 278cd9856..000000000 --- a/devblog/2020-04-15-helium-wallet-1-2-0.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: helium-wallet 1.2.0 -date: 2020-04-15 16:07 -0700 -hide_table_of_contents: true -authors: [madninja] ---- - -We just pushed a new `1.2.0` release of the -[helium-wallet](https://github.com/helium/helium-wallet-rs). - - - -- Moves `-f` and `--file` to _before_ the command. The wallet file option is considered a global - option which needs to precede the command. - -- Adds a new global option `--format` which specifies the output format of a given command. The - supported output formats are: - - - `table` (default) - The existing visual table output - - `json` - A json form of the output of the command - - The `json` form is handy for scripts wrapping the wallet commands - -- Removes the `--hash` option for the `pay` command since the `--format json` output gives the - equivalent information and more - -- Removes the short version of the `--hashlock` and `--timelock` options to the `htlc` command since - they conflicted with global options. - -The binary release of the cli is available on the -[releases page](https://github.com/helium/helium-wallet-rs/releases/tag/v1.2.0). diff --git a/devblog/2020-04-17-console-debugmode.mdx b/devblog/2020-04-17-console-debugmode.mdx deleted file mode 100644 index 513a8ce88..000000000 --- a/devblog/2020-04-17-console-debugmode.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: Console Debug mode -date: 2020-04-17 -hide_table_of_contents: true -authors: [jdgemm, madninja] ---- - -### Key feature updates - -- We’re releasing Debug mode Monday April 20 as we described last - [week](https://engineering.helium.comhttps://docs.helium.com/blog/2020/04/10/console-updates.html). -- Users can access Debug mode on a specific device or label page. This allows users to view data - from a single or multiple devices. -- Debug mode will display 10 packets at a time. -- Each packet is made up of two parts: the information sent from Console to an integration, and - information sent to Console from the backend independent of the integration. - - - -### Impact of planned update - -Payload information on Console will only be available while using Debug mode. - -### UI updates/fixes - -- The historical number of packets sent by a device is displayed: for all time, last 24 hours, last - 7 days, and last 30 days. -- myDevices integration event message no longer blank. - -### Next up - -We’re adding the ability to execute functions on Console, the first will be used to decode payloads. -Users can create a decoder function, and add a custom script to decode the payload. Users can test -scripts to ensure they’re working properly. - -After applying the decoder to a label, the payload of any devices with that label will be decoded. -If there is an integration connected to the device, both the raw and decoded payload will be sent. -If the Debug mode is enabled, the decoded payloads will display on Console in real time. diff --git a/devblog/2020-04-19-chain-var-21.mdx b/devblog/2020-04-19-chain-var-21.mdx deleted file mode 100644 index f876921b5..000000000 --- a/devblog/2020-04-19-chain-var-21.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: post -title: Chain Variable 21 -date: 2020-04-19 13:30 -0800 -hide_table_of_contents: true -authors: [vagabond] ---- - -### Summary - -We identified a flaw where we did not check for 0 amount transactions in some cases. While largely -harmless, it can lead to transaction spam. Additionally, after doing some load testing, we've -lowered the maximum block size (measured in number of transactions) while we continue to work on -improving block propogation times. - -### Audit - -You can find the chain variable transaction details -[here](https://github.com/helium/miner/blob/master/audit/var-21.md). diff --git a/devblog/2020-04-20-app-version-161.mdx b/devblog/2020-04-20-app-version-161.mdx deleted file mode 100644 index bf376a271..000000000 --- a/devblog/2020-04-20-app-version-161.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: App Version 1.6.1 -date: 2020-04-20 -hide_table_of_contents: true -authors: [cokes518] ---- - -### Summary - -A new app version 1.6.1 is now available for iOS and Android - - - -### Contents - -Hello Helium Community! - -In this update, we fixed a few bugs and added more information to diagnostic reports, and show your -location when viewing the Hotspot Network Map. - -#### Bugs - -Show how many Hotspots are offline - -- In Hotspot list view, we were incorrectly showing how many Hotspots were offline. This is now - fixed. - -Fixed an i18n issue where a different language and locale caused the app to crash (iOS only). - -#### Features - -Diagnostic Reports now include IP Address to further help troubleshoot issues. - -When viewing the Hotspot Networ Map, we show your location so you can see the Hotspots around you. diff --git a/devblog/2020-04-22-various-times.mdx b/devblog/2020-04-22-various-times.mdx deleted file mode 100644 index bc66d446c..000000000 --- a/devblog/2020-04-22-various-times.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: HBBFT Signature Phase Fixes -date: 2020-04-22 10:00 -0800 -hide_table_of_contents: true -authors: [evanmcc] ---- - -### Block Weather - -Lately, as our receipt count has improved, we've been seeing long block times again. - - - -We have spent a couple of days doing some performance analysis and instrumenting the consensus code -a bit better, and have come up with some changes that should hopefully improve the situation. This -release mostly focuses on some correctness issues with the signature phase of our HBBFT system. -There will be another release in a few days which should contain some speedups to HBBFT primitives, -once we've had a chance to validate them for a bit longer. - -This release also contains various low-level tweaks to things like P2P relay selection, and when -exactly a block is gossiped on. - -### Contents - -- _Fix Gossip Phase Threshold_: PRs: [miner/371](https://github.com/helium/miner/pull/371) -- _Fix Race in Validation Sidecar_: PRs: [miner/374](https://github.com/helium/miner/pull/374) -- _Fix Signature Validation_: PRs: [miner/375](https://github.com/helium/miner/pull/375) -- _Optimistic Block Gossip_: PRs: [core/429](https://github.com/helium/blockchain-core/pull/429) - -### Plan - -In the late afternoon of Tuesday, April 21st, we rolled this image out to the beta group. It has -betaed overnight and we will roll it out to General Availability sometime in the late morning today, -April 22. diff --git a/devblog/2020-04-23-collapse.mdx b/devblog/2020-04-23-collapse.mdx deleted file mode 100644 index 8b724cb14..000000000 --- a/devblog/2020-04-23-collapse.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -layout: post -title: Emergency Release to Alleviate PoC Receipt Collapse -date: 2020-04-23 15:00 -0800 -hide_table_of_contents: true -authors: [evanmcc, madninja] ---- - -### Block Weather - -While yesterdays fix for block times -([see here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/04/22/various-times.html)) -went well, a seemingly unrelated change has caused quite a bit of trouble today. - - - -[This PR](https://github.com/helium/erlang-libp2p/pull/267) simplified our P2P relay system quite a -lot and should allow us to get better performance for less memory. However, the `random` routine in -our peerbook (which the PR uses heavily) does not filter for stale peer entries (which contain the -actual IP addresses to open a network connection to). So, after 24h (the global staleness deadline) -a large number of peers become un-dialable via the address which `random` returns. For various -reasons, dials are done via a string representing the peer, rather than the peer entry itself. When -`random` would return a stale peer, the dial would not be able to find that peer because its entry -was stale and the downstream code was correctly filtering for stale peers. 24 hours after -yesterday's release, which caused all Hotspots to reboot and update their peer entries, this was -affecting around 12% of all peers which returned from `random`. - -This issue by itself was not a horrible problem. Mostly things would retry in this situation. But -our gossip server does not appear to handle this situation correctly, and when a gossip worker dies -due to the above misdial, it never seems to notice, so eventually the node cannot establish any -gossip connections and the gossip network collapses like we have seen today. -[You can read this post](https://engineering.helium.comhttps://docs.helium.com/blog/2020/03/31/sync-fix.html) -for more context. - -This release adds filtering both for the relay and for the peerbook `random` function, so now we -favor newly updated random peers and never return a stale peer from the random function. We've also -found and fixed the tracking of gossip workers, so if they crash their replacement is correctly -tracked and used for sending gossip messages. In addition, it bumps the assumed valid block. The -speed-ups for hbbft mentioned -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/04/22/various-times.html) -will land in a release early next week. - -### Contents - -- _Favor Recently Updated Peers for Relay_: PR: - [libp2p/268](https://github.com/helium/erlang-libp2p/pull/268) -- _Filter Stale Peers Out of random/1,2,3,4 Returns_: PR: - [libp2p/269](https://github.com/helium/erlang-libp2p/pull/269) -- _Track group workers by ref, not pid, so restarts can be handled_: PR: - [libp2p/270](https://github.com/helium/erlang-libp2p/pull/270) - -### Plan - -This release will be in beta starting around 3pm Thursday April 23rd, for a short time, and then -will be released to GA. diff --git a/devblog/2020-04-28-hbbft-speed.mdx b/devblog/2020-04-28-hbbft-speed.mdx deleted file mode 100644 index d7006ad09..000000000 --- a/devblog/2020-04-28-hbbft-speed.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: HBBFT Speed and Correctness Improvements -date: 2020-04-28 14:00 -0700 -hide_table_of_contents: true -authors: [evanmcc, madninja] ---- - -### Block Weather - -[Recently](https://engineering.helium.comhttps://docs.helium.com/blog/2020/04/23/collapse.html), we -mentioned that we had some pending speedups to our HBBFT implementation. This image releases them to -the cluster. - - - -These changes mostly speed up HBBFT by eliminating duplicate work. Our threshold decryption library, -used (albeit indirectly) to anonymize transaction proposals, now retains its verification state in -between operations, which both makes it faster to use and harder to misuse. Additionally, the local -node was not giving its own inputs any special treatment, despite the fact that it knew them -already, so now it retains the pre-verified and decrypted shares for the combination phase of the -protocol. There have been a few other changes to guarantee that we're duplicating as little work as -possible. - -Additionally, this release contains: - -- Currently disabled code for resetting witnesses over time, which will be activated later. -- Relaxed Proof of Coverage receipt timeouts, so we will wait longer for a delayed request. - -### Contents - -- _Update to New TPKE Version_: PR: [hbbft/52](https://github.com/helium/erlang-hbbft/pull/52) -- _Retain Own Proposal_: PR: [hbbft/54](https://github.com/helium/erlang-hbbft/pull/54) -- _Relax PoC Statem Request Timeout_: PR: [miner/379](https://github.com/helium/miner/pull/379) -- _Reset Witnesses_: PR: [core/360](https://github.com/helium/blockchain-core/pull/360) - -### GA Plan - -The image will be put on the beta group around 2PM PDT, and will beta overnight. diff --git a/devblog/2020-04-30-helium-wallet-1-2-2.mdx b/devblog/2020-04-30-helium-wallet-1-2-2.mdx deleted file mode 100644 index 82aa0a35d..000000000 --- a/devblog/2020-04-30-helium-wallet-1-2-2.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: helium-wallet 1.2.2 -date: 2020-04-30 19:15 -0700 -hide_table_of_contents: true -authors: [madninja] ---- - -We just pushed a `1.2.2` patch release of the -[helium-wallet](https://github.com/helium/helium-wallet-rs). - - - -- Fixes the `-f` and `--file` option to take filenames correctly instead of only showing usage. - - For example: - - ``` - heliium-wallet -f my_wallet.key info - ``` - - and for sharded wallets: - - ``` - helium-wallet -f w.key.1m -f w.key.2 -f w.key.3 info - ``` - -The binary release of the cli is available on the -[releases page](https://github.com/helium/helium-wallet-rs/releases/tag/v1.2.2). diff --git a/devblog/2020-05-04-lorawan-network-upgrade-potential-disruption-mitigation.mdx b/devblog/2020-05-04-lorawan-network-upgrade-potential-disruption-mitigation.mdx deleted file mode 100644 index f8fec0371..000000000 --- a/devblog/2020-05-04-lorawan-network-upgrade-potential-disruption-mitigation.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -layout: post -title: 'LoRaWAN Network Upgrade: Impact & Mitigation' -date: 2020-05-05 12:00 -0700 -hide_table_of_contents: true -authors: [lthiery, lthiery] ---- - -On Tuesday, May 12th, we plan to start a network upgrade both to the blockchain and the LoRaWAN -compliant infrastructure at 8 am PDT / 11 am ET. The operation is expected to be complete no later -than 8:59 am PDT / 11:59 am ET. Progress will be reported live [here](http://status.helium.com/). - - - -The upgrade focuses on many infrastructure improvements which are designed to help the network scale -and continue to decentralize as adoption continues to grow. We consider that upgrades with potential -disruptions should be infrequent and avoided whenever possible, but as our adaptation of LoRaWAN to -a decentralized model for network infrastructure has matured, such an upgrade is necessary at this -time. - -In addition, be aware that there is only the _potential_ for disruption and, in fact, many devices -with resilient LoRaWAN implementations should experience minimal interruption. That being said, the -reality is that resilience is often at odds with simplicity, and as such, many LoRaWAN -implementations have opted for simplicity and may not navigate the upcoming changes without -intervention. - -The upcoming updates include the following: - -- A blockchain transaction for registering LoRaWAN identifiers (ie: AppEui, DevEui pairs) to the - blockchain; Organizational Unique Identifiers (OUIs) all maintain their own table of these which - allow Miners to know that the OUIs LoRaWAN Network Server (or “Router”) is interested in - JoinRequests from these devices. **This effectively enables permissionless registering of devices - to the network.** -- A blockchain transaction for reserving a subnet, ie: bits in the DevAddr space; after the Join, a - Router may allocate any of its reserved subnet space to any of its devices. **This permits the - co-location of many devices on the same public network despite having disparate private network - servers.** -- Switching to subband 2; We've made the decision to adopt subband 2 (switching from subband 7, our - current selection). As we’ve on-boarded various existing LoRaWAN devices and gateways to the - network, it’s become apparent that standardizing on subband 2 will increase usage and reduce - onboarding friction. And though there is some traffic on this subband already, we have determined - that it's minimal and shouldn't pose a problem for our Network users. **By reducing friction, we - increase adoption of the network, which in turn drives Data Credit usage and thus the - incentivization for Hotspot operators.** - -There are several potential disruptions resulting from these changes: - -- Due to the new DevAddr scheme, existing sessions will expire and devices will need to Join again. - Many LoRaWAN stacks detect network presence with occasional ADR commands or ConfirmedUplinks and - will Join again on their own. However, if your device stack does not have such logic - - specifically if it's not configured to join on all potential subbands - a manual resetting to - trigger a new Join may be necessary allowing for a DevAddr to be assigned that is compliant with - the new scheme -- Due to the subband switch, devices will need to issue Joins on subband 2 rather than 7 to Join the - Helium Network. In theory, LoRaWAN-compliant devices should attempt to Join on many subbands. In - our experience, however, many LoRaWAN stacks are pre-configured for a subband and only attempt to - Join on said subband. If this is the case, you will need to reconfigure the subband or update the - LoRaWAN stack so it attempts to Join on other subbands than the preconfigured subband. In both - cases, manual intervention may be required. - -If you need help determining if and how this may impact your devices, please reach out to -developer@helium.com or join us on [Slack](http://chat.helium.com/). diff --git a/devblog/2020-05-05-docker-images.mdx b/devblog/2020-05-05-docker-images.mdx deleted file mode 100644 index 918579cb1..000000000 --- a/devblog/2020-05-05-docker-images.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: Docker Images -date: 2020-05-05 13:00 -0700 -hide_table_of_contents: true -authors: [fvasquez, evanmcc] ---- - -This release adds support for amd64 and arm64 Docker images containing miner. These images can be -fetched from Helium's image registry at quay.io. They are Alpine Linux-based so specify /bin/ash as -the interactive terminal. The amd64 images will run in the cloud and the arm64 images will run on a -Raspberry Pi 3 or 4 that has Ubuntu 20.04 LTS 64-bit installed. - - - -This release also bumps the assumed valid block up to `320747`. - -### Contents - -- _Build miner for Docker_: PRs: [miner/362](https://github.com/helium/miner/pull/362) - -### Plan - -A `2020.05.05.0` release was deployed to the beta group before noon on Tuesday the 5th PST. We -anticipate releasing it to general ability before the end of the day. diff --git a/devblog/2020-05-06-block-gossip.mdx b/devblog/2020-05-06-block-gossip.mdx deleted file mode 100644 index f5a1b686d..000000000 --- a/devblog/2020-05-06-block-gossip.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -layout: post -title: Reducing Redundant Block Gossip and Removing Unnecessary Bottlenecks -date: 2020-05-06 15:00 -0700 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -This release fixes some problems where nodes would re-gossip a block several times because they had -not finished processing the block absorb when other copies of the block came in. This could lead to -a bunch of unnecessary work as the same block would be received several times, from several peers. - - - -A related fix was made to the fast-forward handler, which is used to ensure consensus members can be -quickly synced if they fall behind. Several fast-forwards could happen at once and cause contention. -A fix has been make to limit the number of active fast-forwards at once to 1. - -Work has also been done to reduce bottlenecking on some processes to get p2p swarm information. -We've made much more of that access concurrent so swarm lookups don't timeout or cause crashes, -which will improve resiliency. - -To support ETL, several fixes have also landed to improve the syncing behaviour; background absorbs -are now done in properly monitored background processes, add_block events now fire in every case and -applications can now optionally defer loading of the chain to allow themselves to complete their own -initialization. - -Finally a small fix to the transaction manager was made, to handle the case where a queued -transaction was absorbed immediately prior to a dependent transaction being evaluated. - -### Contents - -- _Less block re-gossip_: PR: [core/443](https://github.com/helium/blockchain-core/pull/443) -- _Singleton fast-forward_: PR: [core/444](https://github.com/helium/blockchain-core/pull/444) -- _Remove synchronous swarm lookups_: PRs: [miner/384](https://github.com/helium/miner/pull/384) - [core/442](https://github.com/helium/blockchain-core/pull/442) - [libp2p/276](https://github.com/helium/erlang-libp2p/pulls/276) -- _Block sync improvements_: PRs: [core/439](https://github.com/helium/blockchain-core/pull/439) - [core/440](https://github.com/helium/blockchain-core/pull/440) - [core/441](https://github.com/helium/blockchain-core/pull/441) -- _Fix dependent transaction resolution_: PR: - [core/438](https://github.com/helium/blockchain-core/pull/438) - -### Plan - -A `2020.05.06.0` release was deployed to the beta group the evening of Tuesday the 5th PST. We -anticipate releasing it to general ability the afternoon of the 6th PST. diff --git a/devblog/2020-05-07-console-decoder.mdx b/devblog/2020-05-07-console-decoder.mdx deleted file mode 100644 index 09e80dba6..000000000 --- a/devblog/2020-05-07-console-decoder.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -layout: post -title: Console Functions and HTTP Downlink -date: 2020-05-07 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, madninja, evanmcc] ---- - -### Key feature updates - -### Functions - -We’ve added the ability to execute functions on Console, the first can be used to decode payloads. -With the Decoder Function, users can can transform and/or parse a raw payload before it is posted to -an endpoint, such that, for example, individual sensor values are reported rather than the base64 -string. This transformation also applies to debug output, allowing it to be more human-readable. - - - -When a Decoder Function is applied to the device via a Label, the Decoder Function code is executed -on the payload sent by the device. The Decoder Function could be written using custom javascript -code provided by the user or prebuilt code (currently Browan Object Locator and Cayenne LPP exist as -pre-provided decoders). - -Our decoder API is compatible with existing The Things Network decoders, which are already available -for a wide array of devices. - -### HTTP Downlink - -HTTP integration has been extended to include the ability to asynchronously POST and enqueue a -Downlink packet; previously, Downlink was only available in the HTTP Response to an Uplink POST. In -addition, this features enables a Downlink to be enqueued for an entire group of devices that share -the same label, allowing messages to be broadcasted easily. - -### Other updates/fixes - -- Home screen with shortcuts and links to resources can be accessed by the Home icon in the top - right corner. -- LoRaWAN Link Check commands are supported to validate network connectivity. -- An issue with the Debug mode has been resolved. - -### Next up - -We have a scheduled outage to make a number of network updates and switch from subband 7 to 2. In -addition, we will deploy stronger account authentication. - -On Tuesday, May 12 this planned outage will start at 8 am PDT / 11 am ET and last approximately one -hour. During this time Console will be inaccessible. - -### Impact of planned update - -Details about the switch from subband 7 and other network updates including the impact can be found -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/05/05/lorawan-network-upgrade-potential-disruption-mitigation.html). diff --git a/devblog/2020-05-09-packet-routing.mdx b/devblog/2020-05-09-packet-routing.mdx deleted file mode 100644 index b209613fa..000000000 --- a/devblog/2020-05-09-packet-routing.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: Initial Work for On-Chain Packet Routing -date: 2020-05-08 14:00 -0700 -hide_table_of_contents: true -authors: [vagabond, madninja, evanmcc] ---- - -This release lands a bunch of work (7000+ lines of code) to enable proper packet routing using the -ledger information. This work also lays the groundwork for paying for packets with data credits. You -can read more details in the earlier blog post -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/05/05/lorawan-network-upgrade-potential-disruption-mitigation.html). - - - -Additionally this release fixes a bug that could cause the Honeybadger BFT reliable broadcast -sub-protocol to fail to converge in some rare situations. - -### Contents - -- _State Channels and routing tables_: PRs: - [core/434](https://github.com/helium/blockchain-core/pull/434) - [miner/389](https://github.com/helium/miner/pull/389) -- _HBBFT RBC partition testing_: PR: [hbbft/56](https://github.com/helium/erlang-hbbft/pull/56) - -### Plan - -A `2020.05.09.0` release was deployed to the beta group the evening of Friday the 8th PST. We did -some testing over the weekend and into Monday. Monday afternoon we identified some small fixes and -cut `2020.05.11.0` which we deployed to the beta group around 4:30pm PST. At about 7pm PST, if the -betas look good we will release to GA. On Tuesday morning we plan to activate the routing tables on -the blockchain and perform the subband 2 switch by GAing a second release, which will simply change -the config files for the subband 2 switch. diff --git a/devblog/2020-05-14-console-auth0.mdx b/devblog/2020-05-14-console-auth0.mdx deleted file mode 100644 index 1ca47b247..000000000 --- a/devblog/2020-05-14-console-auth0.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -layout: post -title: Console Stronger Authentication -date: 2020-05-14 15:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, madninja, evanmcc] ---- - -### Key feature updates - - - -### Stronger Authentication - -We’ve upgraded to a battle-tested authentication platform that provides the following key benefits -allowing us to focus on delivering core Console features: - -- Take full advantage of best-in-class authentication features like their implementation of - Multi-Factor Authentication -- Leverage their platform to protect sensitive data like password hashes and removing it from our - database -- Benefit from additional features such as social authentication with Google (and other social - providers in the future like GitHub) - -### LoRaWAN Network Upgrades - -A number of backend network updates including the switch from sub-band 7 to 2 was completed this -week. - -Technical details about the upgrade and potential impact can be found -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/05/05/lorawan-network-upgrade-potential-disruption-mitigation.html) - -### Better user engagement - -We value your feedback and want to improve direct communication with Console users. We’ve provided -the ability to send notifications and receive feature requests or issues you may be experiencing. - -### Impact of planned update - -After the authentication upgrade users can continue to use existing login credentials (email and -password). However, users will need to enroll in two-factor authentication even if they were -previously enrolled. - -**To enroll in two-factor authentication:** - -- After you login to Console, at the top right click the user account icon and choose My Account. -- Click Enroll in 2FA and follow the instructions. diff --git a/devblog/2020-05-14-packet-routing-cleanup.mdx b/devblog/2020-05-14-packet-routing-cleanup.mdx deleted file mode 100644 index c3c6d7c0d..000000000 --- a/devblog/2020-05-14-packet-routing-cleanup.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: Cleanup Work for On-Chain Routing Work -date: 2020-05-14 16:00 -0700 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -This release is a follow up release to 2020.05.11.0 and 2020.05.12.0 which corrects some bugs we'be -observed preventing state channels from opening and fixes some scalability issues that were -affecting packet routing. - - - -### Contents - -- \*Create blank DC entry if its not found: PR: - [core/447](https://github.com/helium/blockchain-core/pull/447) -- _Asynchronous packet handling_: PR: [core/449](https://github.com/helium/blockchain-core/pull/449) - -### Plan - -A `2020.05.14.0` release was deployed to the beta group the evening of Thursday the 13th PST. It ran -overnight and we release it to GA shortly. diff --git a/devblog/2020-05-15-app-version-170.mdx b/devblog/2020-05-15-app-version-170.mdx deleted file mode 100644 index aeb6b9775..000000000 --- a/devblog/2020-05-15-app-version-170.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: App Version 1.7.0 -date: 2020-05-15 -hide_table_of_contents: true -authors: [cokes518] ---- - -### Summary - -A new app version 1.7.0 is now available for iOS and Android - - - -### New Features - -Hello Helium Community! - -In this update, we added bundled reward transactions per epoch. This means for every epoch, all -Hotspot rewards are batched as one, with specific details on how much HNT each Hotspot has earned -(if you have more than one Hotspot). Tapping on the activity will show specifically what the Hotspot -did to earn HNT (challenge, witness, PoC, etc). - -In addition, we've added a filter on the Account page that lets you drill down to what you need to -find. Pending transactions, payment transactions, and more. - -Lastly, while not user-facing, we've updated the API routes to use the new API for account activity, -including an update to display payment_v2 transactions. diff --git a/devblog/2020-05-15-compression.mdx b/devblog/2020-05-15-compression.mdx deleted file mode 100644 index c56123d80..000000000 --- a/devblog/2020-05-15-compression.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Communications Compression for Hotspots -date: 2020-05-15 11:00 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -Some common feedback we get is that Hotspots use too much bandwidth. We've taken some steps to -address this in the past, and today is the latest step in scaling bandwidth back. This release -applies compression to all connections between Hotspots and their other gossip peers, and makes it -easier to shift to more effective compression in the future. For non-Hotspot peers, this code is -backwards compatible, but you'll need to upgrade to see the benefits. - - - -### Contents - -- _Compress Fastforward and Block Sync_: PR: - [core/377](https://github.com/helium/blockchain-core/pull/377) -- _Compress Gossip_: PR: [libp2p/274](https://github.com/helium/erlang-libp2p/pull/274) - -### Plan - -A `2020.05.15.0` release was deployed to the beta group in the morning of Friday the 14th PST. We'll -beta shortly and then GA when things seem stable. diff --git a/devblog/2020-05-18-audit23.mdx b/devblog/2020-05-18-audit23.mdx deleted file mode 100644 index 1769cb4a0..000000000 --- a/devblog/2020-05-18-audit23.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -layout: post -title: Chain Variable Changes -date: 2020-05-18 10:00 -0700 -hide_table_of_contents: true -authors: [evanmcc, cokes518, vihu] ---- - -Today we're going to issue a transaction to change several chain variables. The high level summary: - - - -1. More high scoring Hotspots will have a chance to be part of the consensus group. -2. More transactions will be allowed per block. -3. We'll widen the range of RSSIs that are allowable for PoC witnesses, to address community - complaints. -4. Old witnesses will get get cleaned up over time and no longer contribute to Proof of Coverage - path generation. - -### Details - -1. `election_selection_pct` will be changed from 20 to 1. Since we now have a large number of high - scoring Hotspots and the top of the list is currently dominated by Hotspots in suspect - configurations, we're spreading out consensus membership more, in the hopes of disincentivizing - bad behavior by lowering the returns to cheating your way to a high score. - -How will this affect Hotspot owners? - -- More high scoring Hotspots will have a chance to be in the consensus group instead of the select - few now. This, in conjunction with a change we made a few weeks ago to geographically distribute - consensus group Hotspots will further disincentivize unwanted behavior. - -2. `batch_size` will be changed from 200 to 400. We lowered this a few weeks ago due to some - gigantic blocks that caused some issues with gossip. It looks like we lowered it too much, as - we're only able to sustain about 150 transactions per block. We currently have a target of 250 - transactions per block, so we're raising the limit in order to hit that target. Expect more - adjustments in the future. - -How will this affect Hotspot owners? - -- While this may not have a direct affect on Hotspot owners, you may see reduced pending transaction - times. - -3. `poc_good_bucket_high` will be changed from -80 to -70 and `poc_good_bucket_low` will be changed - from -118 to -130. These change what recorded signal strengths are allowed for witnesses. This is - an anti-cheating measure, but it looks like we've been too restrictive, and people with high gain - antennas are having issues with Hotspots witnesses nearby and valid Hotspots too clearly. - -How will this affect Hotspot owners? - -- This means those with non-stock antennas will no longer be penalized and bucketed as a poor - witness. Hotspot owners with high gain antennas may see more challenges succeed. - -4. `witness_refresh_interval` will be added to the chain at 10080 (approximately one week of - blocks), and `witness_refresh_rand_n` will be added at 1000 (an implementation detail that - nevertheless must be on the chain for the sake of determinism). The former will probabilistically - age out witnesses over the course of a week, leading to more valid and recent paths. This should - allow the network to adjust to seasonal variations and the slow churn of spots as people add, - remove, and move them around. - -How will this affect Hotspot owners? - -- Currently witnesses never expire, which means old and weak witnesses are often used to create - paths. By refreshing witnesses on a weekly interval, we can purge bad Hotspots and create more - meaningful PoC paths. We can expect fewer challenges to spuriously fail with this change. diff --git a/devblog/2020-05-18-audit24.mdx b/devblog/2020-05-18-audit24.mdx deleted file mode 100644 index c4050f92d..000000000 --- a/devblog/2020-05-18-audit24.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -layout: post -title: Chain Variable Reversion -date: 2020-05-18 10:00 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -It turns out that there is an issue with the implementation of the old witness refresh code and -we're going to disable these chain variables until we can fix the issue and re-enable them. - - - -## Details - -Our chain implementation keeps two different copies of the ledger, one which is delayed 50 blocks -behind main one. When we change something that happens to the ledger outside of a transaction we -have to be sure that we're doing the same things to both versions (at that same delay). In this case -we failed to do so, and since the lagging ledger is used to validate old transactions, we're seeing -differences in the validity of transactions on different nodes. diff --git a/devblog/2020-05-20-postmortem.mdx b/devblog/2020-05-20-postmortem.mdx deleted file mode 100644 index 0c6db519c..000000000 --- a/devblog/2020-05-20-postmortem.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -layout: post -title: 2020-05-18 Incident Postmortem -date: 2020-05-20 15:30 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -### What Happened? - -We activated witness refresh at block 339044 -([see audit 23](https://github.com/helium/miner/blob/master/audit/var-23.md)), which was intended to -gradually clear witness tables over the course of about a week. Unfortunately we neglected to apply -this refresh to the lagging ledger in the same way. Once we realized this, we issued a deactivation -of the new feature at block 339291. Unfortunately it was too late and about 37 ledger entries were -now divergent between the leading and lagging ledger. This led to disagreements on the block -contents between the consensus members and caused a chain halt. - - - -### When? - -All times approximate, in PDT. - -11:20AM Monday, May 18th: Initial chain variable transaction absorbed.
3:10PM Monday, May -18th: Initial signs of trouble as some nodes start to have issues absorbing blocks.
3:23PM -Monday, May 18th: Chain halts for the first time.
5:40PM Monday, May 18th: Second chain -variable transaction, disabling witness refresh -([see audit 24](https://github.com/helium/miner/blob/master/audit/var-24.md)).
6:30PM Monday, -May 18th: Chain halts again, is left down.
6:51PM Monday, May 18th: Issue diagnosed.
7PM -to late: Work on recovery code, eventually giving up for the night.
7:15AM Tuesday, May 19th: -Issue fully understood, fix code written.
8:00AM Tuesday, May 19th: Hard reset plan -formulated.
11:00AM Tuesday, May 19th: Fixed image goes GA.
11:45AM Tuesday, May 19th: -Ancillary services fully updated, chain restarted, hard reset chain variable issued.
1:45PM -Tuesday, May 19th: Witness reset interval chain variable submitted, returning the value to -approximately one week. - -### Why did it happen? - -The core of the problem was disagreement between the two versions of the ledger that we keep on -disk. The leading ledger is the current ledger. The lagging ledger is 50 blocks behind, so that we -have a stable base to play transactions into to validate things at heights between these ledgers. -Problems started occurring when different members of the consensus group would disagree about which -transactions they considered as valid. We use witnesses to generate the paths that PoC requests can -go along, and when the witnesses on the ledger disagree, some nodes can consider the paths generated -by others impossible. When, after some time, the disagreements happened between too many members, we -could no longer construct a block. - -Our lagging ledger had two sources of drift: - -1. The witness, PoC entry, and state channel garbage collection processes were not run on the - lagging ledger. -2. When the ledger was played forward via ledger_at, for the purposes of transaction validation, the - GC processes were not invoked either, so even if the lagging ledger was correct, the played - forward ledger that we would have arrived at would not be. - -Garbage collection in this context means that we have rules for the removal of stale data from the -ledgers that are invoked potentially at every block. Currently we have collectors for PoC challenge -data, state channel data, and Hotspot challenge witness data. - -### How did we fix it? - -There are additional complications, but these facts suffice to contextualize the fix, which was to -apply the garbage collection process both during the playforward and also as the lagging ledger -absorbed blocks. - -Operationally, things were a bit more complicated. The team stayed up late into the night trying to -understand how the ledger could reliably be repaired, but in the end, we decided that since witness -data was now meant to be ephemeral, we could simply set the witness reset interval to 1, which would -reset all witnesses at each block. If we let this run for 50+ blocks, longer than the gap between -the leading and the lagging ledger, the witnesses should be consistent (which is to say, absent) in -both versions of the ledger and we could let them start to accumulate again. This required building -a new image with the new code, and then starting up the group again, skipping past the split block -it had stalled on, with only the new chain var transaction in their buffers -([see audit 25](https://github.com/helium/miner/blob/master/audit/var-25.md)). Once the group was -moving again, we monitored it closely for halts and issues until the ledger was consistent across -almost all nodes, at which point we could submit another transaction that would allow witnesses to -accumulate ([see audit-26](https://github.com/helium/miner/blob/master/audit/var-26.md)). diff --git a/devblog/2020-05-26-snapshots.mdx b/devblog/2020-05-26-snapshots.mdx deleted file mode 100644 index 7a875e988..000000000 --- a/devblog/2020-05-26-snapshots.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: Ledger Snapshots -date: 2020-05-26 15:00 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -Another big issue that we've been dealing with recently is sync times on new Hotspots. We've seen -cases recently when new Hotspots have taken in excess of 10 days to fully sync and start issuing -challenges. This release is the first to support a feature we're calling "ledger snapshots", which -allow Hotspots to safely sync without downloading the entire blockchain first. A few times a day, -the running consensus group will take a snapshot of its ledger, package it up with a relatively -small number of blocks and then store its hash on the chain. We can then attest the validity of a -particular snapshot to allow new Hotspots to download that snapshot and start using it, much as we -now attest to the validity of a particular block (and all the blocks leading up to it). This should -allow syncing in hours, rather than in days as is currently the case. - - - -This feature requires a new chain variable to be enabled, so please, if you're running a blockchain -core based service, go update it to the latest core now, so that it doesn't halt when we issue the -chain variable transaction. - -This release also contains enhancements for our recent state channels releases, and a number of -support features for our API services. - -### Contents - -- _Ledger Snapshots_: PR: [core/403](https://github.com/helium/blockchain-core/pull/403) -- _Ledger Snapshots - Miner Support_: PR: [miner/388](https://github.com/helium/miner/pull/388) - -### Plan - -A `2020.05.27.0` release was deployed to the beta group in the morning of Wednesday the 27th around -11:50AM PST. This follows a series of previous beta releases we used for testing, starting on Friday -22nd. We'll briefly beta, given the numerous previous releases, and then GA in the early afternoon. -Following this we'll release a chain variable transaction (setting `snapshot_interval` to 240) to -activate this code. diff --git a/devblog/2020-05-29-HNT-Price-Oracles.mdx b/devblog/2020-05-29-HNT-Price-Oracles.mdx deleted file mode 100644 index b96bc5dd7..000000000 --- a/devblog/2020-05-29-HNT-Price-Oracles.mdx +++ /dev/null @@ -1,139 +0,0 @@ ---- -layout: post -title: The Introduction of HNT Price Oracles -date: 2020-05-29 15:30 -0700 -hide_table_of_contents: true -authors: [pharkmillups, evanmcc, pharkmillups] ---- - -The biggest developments in the Helium blockchain ecosystem right now are around -[HNT and Data Credits](https://developer.helium.com/blockchain/tokens). - - - -- HNT is the native cryptoasset produced by the Helium blockchain that's distributed to miners and - other network stakeholders. -- Data Credits (DCs) are the unit of transaction on the Network, and are spent when completing - transactions like sending data to/from a device, sending HNT from wallet to wallet, adding - Hotspots, and asserting a Hotspot's location. - -HNT and DCs are linked in a very simple, powerful way: DCs are produced by burning HNT. (This is -based on a concept called "Burn and Mint Equillibrum, and the -[Messari team has some great initial reading and pointers here](https://messari.io/article/burn-and-mint-equilibrium).) -Most of the work to faciliate this is done. The HNT burn transaction already exists on the -blockchain, and we recently completed the state_channel work which enables us to track data credit -usage per account. - -DCs are actually pegged to a $USD amount: `$0.00001`. This means that, at any time, a user can know -the price of their transactions in advance in $USD. For example, -[we have a great calculator](https://www.helium.com/business) that lets you calculate the cost of -sending device data. - -### How many DCs are produced by burning HNT? - -But if HNT converts to DCs, what's the conversion rate? Don't we need to know the price of HNT in -$USD before this can happen? Yes. And to find the answer, we're implementing a what's typically -called a "price oracle". Specifically, we're opting for a system built on multiple oracle feeds from -network participants. - -### HNT Price Oracles - -To establish the price of HNT in $USD, we've chosen to implement a price oracle model based on what -the -[Maker community announced and has been using successfully](https://blog.makerdao.com/introducing-oracles-v2-and-defi-feeds/) -since last year. - -At a high level, the system works like this: - -- Some number of participants/entities submit `HNT/$USD` feed transactions using a key pair known to - be from an approved feed. -- The prices are submitted every N hours, or when a participants/entity notices a big movement in - the $USD price. -- The blockchain establishes an external $USD price of HNT by calculating the median of the price - inputs. -- This price is used for HNT / DC conversion until a point at which a new price is determined using - the method above. - -### Who are the Oracles? How were they chosen? What are their responsiblities? - -The price feeds are supplied by a group of nine (9) Oracles, composed of companies, organizations, -and indivduals. They are: - -- Helium, Inc -- Decentralized Wireless Alliance (DEWI) -- Seven (7) Anonymous Individual Community Members - -We've chosen to keep the names of the individual feed contributors anonymous as it's essential to -prevent any external attempts at extortion or blackmail. The names of large companies and -organizations that supply feeds, however, are public and it's easier for them to combat potential -attacks and bad actors. The selection criteria for the Anonymous Individual Community Members were -as follows: - -- Have they been a long time, active member of the Helium Community? -- Do they contribute actively and positively to the betterment and progression of the Helium - Network? -- Do they have a complete technical understanding of the Helium network and our token system? -- Are they capable of challenging Helium and other community members on the roadmap and technical - decisions? -- If their names were to be known, is it likely that most fellow community members would deem them - trustworthy? - -If the answer to all of the above was "yes", they were a candidate for being an Oracle. This list -was assembled and randomized, then each participant was approached, in order. If yes, they were -added. If no, we moved on. - -It's worth noting that being a price Oracle does not confer any special status on the companies, -organizations, and indivduals. It's largely a clerical role, and does not come with any sort of -compensation (or even swag). Also, it's not expected that the current set of Oracles will be in this -role for all eternity. (That would be a lot to ask.) And we expect to expand the group in the future -as the system evolves. For example, in the event that a major, trusted exchange does start to offer -HNT, we would likely look to add their price as an Oracle. - -### How is the price of HNT actually calculated? - -Most of the code that handles the HNT price oracles -[can be found in blockchain-core](https://github.com/helium/blockchain-core/pull/448). But if you're -not fluent in reading Erlang (guilty), here's the summary of how things are designed: - -Every `50` blocks (roughly every 50 minutes) the blockchain will attempt to establish a new price of -HNT. (This `50` block number is defined in a new chain variable). To do this: - -1. The blockchain looks for recent price submissions from valid Oracles (submitted using a new - transaction called `price_oracle_submission`). A valid price submission is anything that was - submitted within the last 25 hours but is older than 1 hour. This gives us the ability to do a - trailing 24 hour median while also having a buffer against wild price inputs in the most recent - 60 minutes. (Think of it like a bleep filter on "live" televsion. They aren't bleeping four - letter words live. It happens because there is a bit of lag.) -2. If there are enough new, valid price submissions in the 24 hour window, a new price will be - calculated. For this to happen, a majority of the price Oracles need to have submitted a price in - the window - `((N / 2) +1 )`. So, in our system of `9` Oracles, we would need valid prices from - at least `5`. (If there aren't `((N / 2) +1 )` new prices, no new HNT price is calcuated.) -3. If there are at least `5` new prices, we then proceed to sort order the list low to high, and - take the median. So, if we had `7` valid submissions of `$.20,` `$.22`, `$.235`, `$.238`, `$.25`, - `$.27`, `$.45`, the blockchain would select `$.238`, and use this as the external price of HNT - for all HNT / DC burn transactions until a new price is established (which could be as soon as - `50` blocks). - -With the price of `$.238` established, the blockchain will now use this as the input to all burn -transactions. - -### New Chain Variables - -As part of this work, we're proposing a series of new Chain Variables. They are: - -| Proposed Chain Variable | Rationale | -| ----------------------------- | ----------------------------------------------------------------------- | -| price_oracle_public_keys | Array of ed25519 binary public keys of price oracles | -| price_oracle_refresh_interval | Number of blocks between price recalculation | -| price_oracle_height_delta | Delta allowed between current block height and the price_submission txn | -| price_oracle_price_scan_delay | Number of seconds to delay scanning for prices | -| price_oracle_price_scan_max | Number of seconds to stop scanning for prices | - -When this work is fully merged, they will be part of the -[complete list of chain variables](https://github.com/helium/blockchain-core/blob/master/include/blockchain_vars.hrl). - -### What's Next? - -We're putting the final touches on the Oracle system as we speak. In the coming days we plan to do -the first test run with the current group of Oracles, and then refine things a bit more before Data -Credits and burning HNT formally goes live in the coming weeks. Exciting times. diff --git a/devblog/2020-06-01-cleanup.mdx b/devblog/2020-06-01-cleanup.mdx deleted file mode 100644 index 7171c2ebb..000000000 --- a/devblog/2020-06-01-cleanup.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: Ledger Snapshots Cleanup Release -date: 2020-06-01 10:00 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -Over the weekend we've identified a few minor issues with ledger snapshots, and since they're -impacting block times, we're issuing a minor release to clear them up. Our old code assumed that all -Hotspots would have all of the blocks, and there are a few bits of code that rely on that, one of -which affects consensus nodes, which has been negatively affecting block times. - - - -### Contents - -- _Time Stabilization Block Fix_: PR: [miner/411](https://github.com/helium/miner/pull/411) -- _Various Snapshot Sync Improvements_: PR: - [core/474](https://github.com/helium/blockchain-core/pull/474) - -### Plan - -A `2020.05.31.0` release was deployed to the beta group in the evening of Sunday the 31st around -8:50PM PDT. After this beta period was released to GA around 10:45 AM PDT on June 1st. diff --git a/devblog/2020-06-04-price-oracles.mdx b/devblog/2020-06-04-price-oracles.mdx deleted file mode 100644 index 24b17baa8..000000000 --- a/devblog/2020-06-04-price-oracles.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: Price Oracles Initial Release -date: 2020-06-04 10:20 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -This release lands support for the HNT/USD price oracle. The code will be inactive until activated -via chain variable transaction, which we expect to do Friday afternoon or Monday. - - - -In addition to this, we've also landed several smaller fixes and improvements, largely to snapshots. -We've also upgraded our libsodium library which has led to a backwards incompatible change to -encrypted streams. This means that during the upgrade the consensus group will not be able to -operate in mixed mode, all the nodes will need to be upgraded to resume block production. - -### Contents - -- _Price Oracle_: PRs: [core/448](https://github.com/helium/blockchain-core/pull/448), - [miner/415](https://github.com/helium/miner/pull/415) -- _Snapshot Fixes_: PRs: [core/475](https://github.com/helium/blockchain-core/pull/475), - [core/480](https://github.com/helium/blockchain-core/pull/480), - [core/478](https://github.com/helium/blockchain-core/pull/478), - [core/485](https://github.com/helium/blockchain-core/pull/485), - [core/482](https://github.com/helium/blockchain-core/pull/482), - [core/486](https://github.com/helium/blockchain-core/pull/482) - [miner/413](https://github.com/helium/miner/pull/413) -- _Libsodium upgrades_: PRs: [libp2p/284](https://github.com/helium/erlang-libp2p/pull/284), - [libp2p/284](https://github.com/helium/erlang-libp2p/pull/284), - [core/481](https://github.com/helium/blockchain-core/pull/481) - -### Plan - -A `2020.06.03.0` release was deployed to the beta group in the evening of Wednesday the 3rd around -8:50PM PDT. After this beta period was released to GA around Thursday the 4th around 10:15AM PST. diff --git a/devblog/2020-06-05-868-and-yamux.mdx b/devblog/2020-06-05-868-and-yamux.mdx deleted file mode 100644 index c7be22131..000000000 --- a/devblog/2020-06-05-868-and-yamux.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: Initial Support for EU868 Region and snapshot syncing fix -date: 2020-06-04 10:20 -0700 -hide_table_of_contents: true -authors: [vagabond, lthiery] ---- - -As we gear up for expanding the Helium network to other regions we've been threading region -awareness through our code. As of this release the Helium Network will support hotspots in the EU868 -region as well as the currently supported US915 region. - - - -Additionally we've identified an issue that leads to Hotspots being unable to sync a snapshot over a -low bandwidth or high latency link. We've improved the situation somewhat and will work on -delivering a more comprehensive fix next week. - -### Contents - -- _Region awareness_ PRs: [core/473](https://github.com/helium/blockchain-core/pull/473), - [miner/405](https://github.com/helium/miner/pull/405) -- _Yamux stream timeouts_ PRs: [libp2p/285](https://github.com/helium/erlang-libp2p/pull/285), - [core/487](https://github.com/helium/blockchain-core/pull/487), - [miner/417](https://github.com/helium/miner/pull/417) - -### Plan - -A `2020.06.05.1` release was deployed to the beta group around 3pm on the afternoon of Friday the -4th PST. Once we've validated everything looks good we will release it to GA this evening. diff --git a/devblog/2020-06-08-app-version-180.mdx b/devblog/2020-06-08-app-version-180.mdx deleted file mode 100644 index 9282868e8..000000000 --- a/devblog/2020-06-08-app-version-180.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: post -title: App Version 1.8.0 -date: 2020-06-08 -hide_table_of_contents: true -authors: [cokes518] ---- - -### Summary - -A new app version 1.8.0 is now available for iOS and Android - - - -### New Features - -Hello Helium Community! - -#### Hotspot Activity Filter - -In this updated, we added filters to Hotspot activity. Now you can filter by the type of activity -your Hotspot has done, including participating in challenges, creating challenges, and (new!) -transferring data packets on the network. - -#### Data Packet Transfer - -Wondering if your Hotspot has transferred data packets? Wonder no more. Don't see any activity? If -you have a LoRaWAN device, you can test it out yourself to see how it works. Don't have a LoRaWAN -device and want to join in the fun? Join the Helium Community and learn how to set one up. - -#### Display Payment v2 transactions - -If you have sent or received a payment v2 transaction, you can now see it displayed in the mobile -app. Payment v2 transactions allow the sender to send HNT to multiple recipients with one command in -the CLI. - -#### Include Device information in Diagnostic Reports - -To help serve you better, we've added device information (phone type and operating system) -automatically in diagnostic reports. - -#### Fixed Bugs - -Fixed Android Bugs - -### Known Issues - -Filtering Hotspot Activity by Consensus group may return no activity even if the Hotspot has -participated in Consensus. - -- this is caused by the API timing out. We have fixes planned next week to increase the speed of the - API - -Switching Wi-Fi networks doesn't work if both Wi-Fi networks are found in the scan list. - -- If you need to update your Wi-Fi credentials and both old and new networks appear in the scan - list, contact support@helium.com and we can help manually update it for you. diff --git a/devblog/2020-06-09-console-updates.mdx b/devblog/2020-06-09-console-updates.mdx deleted file mode 100644 index 82ce30002..000000000 --- a/devblog/2020-06-09-console-updates.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: Console Network Server and Infrastructure Improvements -date: 2020-06-09 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -### Key feature updates - -See below for the updates and enhancements we’ve made to Console. - - - -### Network Server and infrastructure improvements - -- Console and the Network Server now use web sockets for internal communication instead of caching - which improves performance for a number of capabilities including switching integrations. -- Updated Console testing infrastructure which allows us to do full testing without any dependency - on the Network Server. - -### UX enhancements/updates - -- Gateway channel info is included in json payloads. -- The number of devices connected to a Label is reflected in the Console left-hand menu. -- The Downlink URL is populated with the Integration ID’s and Downlink Keys. -- Users can create Labels while they’re adding new Integrations. -- Smoother onboarding flow to add devices for first time Console users. - -### Next up - -We’re working on supporting the acquisition of Data Credits using Console. The initial release will -allow users to purchase Data Credits using their credit card directly from Console. - -In a follow up release users can use their own HNT to convert and add to their Data Credit balance. diff --git a/devblog/2020-06-09-price-oracle-math.mdx b/devblog/2020-06-09-price-oracle-math.mdx deleted file mode 100644 index cd61de4dd..000000000 --- a/devblog/2020-06-09-price-oracle-math.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -layout: post -title: Price Oracle Math -date: 2020-06-09 -hide_table_of_contents: true -authors: [fvasquez] ---- - -This minor release fixes a bug in the math that the price oracle uses to calculate HNT/USD. - - - -### Contents - -- _Fix Price Oracle Calculations_: PRs: - [core/491](https://github.com/helium/blockchain-core/pull/491) - -### Plan - -A `2020.06.09.0` release was deployed to the beta group on the afternoon of Tuesday the 9th around -12:45PM PDT. After a brief period of testing we plan to release it to GA. diff --git a/devblog/2020-06-12-gps-yamux-snapshots.mdx b/devblog/2020-06-12-gps-yamux-snapshots.mdx deleted file mode 100644 index e736aea84..000000000 --- a/devblog/2020-06-12-gps-yamux-snapshots.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Price Oracle Math -date: 2020-06-12 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -This minor release increases some network timeouts again to compensate for snapshot sizes. It also -corrects an error in the "bad GPS fix" reporting code and makes snapshots more compatible with the -upcoming changes for data credits and transaction fees. Finally there's a small fix that may help -with some cases of ledger corruption. A bigger fix on this front is in the works. - - - -### Contents - -- _Fix Bad GPS Fix Reporting_: PR: [miner/419](https://github.com/helium/miner/pull/419) -- _Stricter Witness Update Application_: PR: - [core/498](https://github.com/helium/blockchain-core/pull/498) -- _Encode Blocks in Snapshot_: PR: [core/497](https://github.com/helium/blockchain-core/pull/497) - -### Plan - -A `2020.06.12.1` release was deployed to the beta group on the afternoon of Friday the 12th around -4:40PM PDT. After a brief period of testing we plan to release it to GA around 5:30PM PDT. diff --git a/devblog/2020-06-16-gps-cache.mdx b/devblog/2020-06-16-gps-cache.mdx deleted file mode 100644 index d1341a0f9..000000000 --- a/devblog/2020-06-16-gps-cache.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: New Gateway Cache -date: 2020-06-16 10:40 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -In an attempt to improve block times, we have developed a new Hotspot cache which keeps the -deserialized spots in memory for longer, so we're not constantly fetching and refetching the same -information from the disk. There's also a change make validation of Proof of Coverage(PoC) receipts -substantially cheaper. - - - -Together these changes should make it easier validate incoming blocks and block times should -improve. Also stemming from this performance investigation, we anticipate lowering the maximum PoC -path length via chain variable transaction in order to reduce the cost of validating length six and -seven PoC paths, which are currently rarely successful. - -### Contents - -- _Re-fix Bad GPS Fix Reporting_: PR: [miner/420](https://github.com/helium/miner/pull/420) -- _Add Hotspot Cache and Optimize ECDH_: PR: - [core/490](https://github.com/helium/blockchain-core/pull/490) - -### Plan - -A `2020.06.15.1` release was deployed to the beta group on the morning of Tuesday the 16th around -10:00AM PDT. After a brief period of testing we plan to release it to GA around 11:00AM PDT. diff --git a/devblog/2020-06-17-txn-fees-and-fixes.mdx b/devblog/2020-06-17-txn-fees-and-fixes.mdx deleted file mode 100644 index 4b94fda7e..000000000 --- a/devblog/2020-06-17-txn-fees-and-fixes.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: Consensus Group Stall Fixes and Landing Transaction Fees -date: 2020-06-17 17:50 -0700 -hide_table_of_contents: true -authors: [vagabond, evanmcc] ---- - -We've identified some more failures that have been leading to long block times and included fixes -for them in this release. In addition, now we have the price oracle running, we've landed the code -for real transaction fees and staking fees. These fees won't be active until we've made sure all the -wallets have been updated and everyone has had appropriate warning. Finally we've bumped the blessed -snapshot to 376561. - - - -### Contents - -- _Consensus and Out of Memory fixes_: PRs: - [core/506](https://github.com/helium/blockchain-core/pull/506), - [miner/427](https://github.com/helium/miner/pull/427), - [miner/425](https://github.com/helium/miner/pull/425), - [miner/430](https://github.com/helium/miner/pull/430), - [miner/429](https://github.com/helium/miner/pull/429) -- _Transaction fee support_: PRs: [core/492](https://github.com/helium/blockchain-core/pull/492), - [core/507](https://github.com/helium/blockchain-core/pull/507), - [miner/422](https://github.com/helium/miner/pull/422), - [miner/424](https://github.com/helium/miner/pull/424), - [miner/426](https://github.com/helium/miner/pull/426) - -### Plan - -A `2020.06.17.0` release was deployed to the beta group on the afternoon of Wednesday June 17th at -around 3:45 PDT. After testing we expect to release this to GA around 6:30PM PDT. diff --git a/devblog/2020-06-18-retune.mdx b/devblog/2020-06-18-retune.mdx deleted file mode 100644 index 0c15c2310..000000000 --- a/devblog/2020-06-18-retune.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: Retune Hotspot Cache -date: 2020-06-18 13:30 -0700 -hide_table_of_contents: true -authors: [evanmcc, vagabond] ---- - -After monitoring the chain overnight and seeing few signs of recovery, further investigation -revealed that we were still seeing out of memory errors on v1 Hotspots. A closer reading of the docs -revealed that a part of the Erlang runtime reports memory usage in machine words (the width of the -processor's registers), which means that the earlier measurements we based our tunings on were too -low by a factor of 8. This release does nothing but retune the cache to use much less memory, which -we hope will stabilize the chain, if not fully restore block times. - - - -Current block time troubles are largely related to the slowness of the disk on the Hotspots combined -with certain problematic behaviors, mostly excessive clustering, engaged in by some users. We have -work in train to ameliorate the worst effects of these behaviors, but this will require a new chain -var, and so can't be rushed. Our in-progress Proof of Coverage redesign will include disincentives -for this sort of behavior as well. - -### Contents - -- _Out of Memory fixes_: PRs: [miner/433](https://github.com/helium/miner/pull/433) - -### Plan - -A `2020.06.18.0` release was deployed to the beta group on the afternoon of Thursday June 18th at -around 1:00 PDT. After testing we expect to release this to GA around 4:30PM PDT. diff --git a/devblog/2020-06-19-downlink-packet-times.mdx b/devblog/2020-06-19-downlink-packet-times.mdx deleted file mode 100644 index c25ec6388..000000000 --- a/devblog/2020-06-19-downlink-packet-times.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: Downlink Packet Timing -date: 2020-06-19 20:20 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -While we are aware of some Hotspots falling out of sync (although they will eventually recover) we -have not yet isolated the root cause. This release only makes 2 changes, it fixes a problem with the -timing of LoRaWAN packets, specifically around meeting the downlink window and it blesses a new -snapshot at height 379441. The new snapshot should help unstick some Hotspots that are struggling, -and we will continue to work on a more permanent fix. - - - -### Contents - -- _Packet downlink timing_: PR: [core/512](https://github.com/helium/blockchain-core/pull/512) - -### Plan - -A `2020.06.19.0` will be deployed to the beta group this evening, Friday the 19th of June, and once -it passes basic testing, being a simple release, will be promoted to GA thereafter. diff --git a/devblog/2020-06-22-bandaid.mdx b/devblog/2020-06-22-bandaid.mdx deleted file mode 100644 index e7fadd041..000000000 --- a/devblog/2020-06-22-bandaid.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: Sync Issues Remediation -date: 2020-06-22 15:50 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -Recently it's come to our attention that a growing number of Hotspots are having issues staying in -sync with the chain. Hotspots use RocksDB as their storage layer for the ledger and the blockchain. -RocksDB offers a feature called snapshots which purports to provide an immutable, read-only version -of your store, in this case, old ledgers to make validation cheaper. Unfortunately, due to an -as-yet-unidentified issue, either to do with RocksDB itself, how the RocksDB Erlang NIF library is -written, or how our code is creating and using these snapshots, we're seeing some writes which have -been synchronously written to disk missing from the snapshots. - - - -While we look into this, we're releasing this image, which will make affected Hotspots fall back -onto a less efficient path when they run into a validation error. The less efficient path is not -affected by this issue, and syncing should continue. - -### Contents - -- _Drop Snapshots on Validation Error_: PR: - - [core/518](https://github.com/helium/blockchain-core/pull/518) -- _Condense Block Absorb into One Context_: PR: - - [core/520](https://github.com/helium/blockchain-core/pull/520) - -### Plan - -A `2020.06.22.0` release was deployed to the beta group on the afternoon of Monday June 22th at -around 3:40PM PDT. After testing we expect to release this to GA around 5:30PM PDT. diff --git a/devblog/2020-06-24-new-var.mdx b/devblog/2020-06-24-new-var.mdx deleted file mode 100644 index 18e91d3e0..000000000 --- a/devblog/2020-06-24-new-var.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: New Chain Variable Release -date: 2020-06-24 17:00 -0700 -hide_table_of_contents: true -authors: [evanmcc, fvasquez] ---- - -Much of the trouble that we've been having lately with maintaining consistent block times has been a -result of Hotspot clusters, some of them quite large. These clusters, often hosted in the same -place, lead to an abnormally high number of witnesses and a large disk representation. Since they're -colocated and witness each other, our Proof of Coverage (PoC) pathing code has some pathological -behavior when they're challenged, since it must consider sometimes hundreds of Hotspots to generate -the path. This can lead to single transactions that take the Hotspot hardware multiple seconds to -validate, which can cause a lot of problems for protocol completion and steady block times as the -validation and the Honeybadger runners compete for the disk. - - - -This release introduces a new chain variable that will allow us to restrict the number of Hotspots -that will be considered per target and pathing transaction step. This should more tightly bound the -amount of time that a single transaction can take and should make block times more predictable. This -new chain variable will cause applications using our `blockchain-core` library to halt when it is -activated sometime next week, so please, if you're running something that uses core, upgrade to or -past the `2020.06.24.0` tag by Tuesday June 30. - -### Contents - -- _Allow Restriction of Considered Hotspots_: PR: - - [core/504](https://github.com/helium/blockchain-core/pull/504) -- _Update Transaction Fee Code and Tests_: PR: - - [core/514](https://github.com/helium/blockchain-core/pull/514) - -### Plan - -A `2020.06.24.0` release was deployed to the beta group on the afternoon of Wednesday June 24th at -around 5:30PM PDT. After testing we expect to release this to GA around 9:30 AM PDT the next -morning. The chain variable transaction activating it will be issued some time in the coming week, -no earlier than Wednesday July 1. diff --git a/devblog/2020-06-25-app-version-190.mdx b/devblog/2020-06-25-app-version-190.mdx deleted file mode 100644 index d9a00ddd4..000000000 --- a/devblog/2020-06-25-app-version-190.mdx +++ /dev/null @@ -1,91 +0,0 @@ ---- -layout: post -title: App Version 1.9.0 -date: 2020-06-25 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Summary - -PLEASE UPDATE TO THIS RELEASE. This update includes the following new features and is not backwards -compatible. Failure to update to `1.9.0` will cause all transactions in the mobile app to fail once -we activate **transaction fee chain variables**. - - - -What will fail: - -- wallet-to-wallet payment transactions -- updating hotspot locations -- adding a hotspot - -What will NOT fail, as these are blockchain activities and not wallet activities: - -- hotspot earnings -- proof-of-coverage challenges -- witnessing -- consensus groups -- creating challenges - -## Why will those transactions fail if I don't update my app version? - -The blockchain essentially has a new way of processing transactions (with transaction fees). So any -service (including the app) will need to "speak the blockchain's new language" for transactions to -succeed. - -# Other Features included in this release - -## GPS Information (Experimental) - -As part of validating network coverage, the team looked to expose key GPS information for Hotspot -owners to see if their GPS location matched their Hotspot location on the blockchain. For more -information, please see the previous post on this: -[https://helium-community.slack.com/files/T23CDV4N4/F014793ASPR?origin_team=T23CDV4N4](https://helium-community.slack.com/files/T23CDV4N4/F014793ASPR?origin_team=T23CDV4N4) - -At this stage, the GPS information is experimental and merely for informational purposes. _There is -no impact to Hotspot mining_. If you do decide to move the Hotspot, do so at your own discretion. - -- Reasserting it across a room is not necessary, just unplug and replug the power. -- Acquiring a GPS fix may also take up to 48 hours, depending on satellites in the sky, cloud - coverage, and obstacles in the way between the GPS antenna underneath the black disc and the sky. -- If you occasionally see a bad assert, and your Hotspot is asserted in its physical location - (accurate to 200 meters), do not panic! The GPS can wander. If you leave it alone, the bad assert - will likely change back to a good fix. - -## Show synced block height if a Hotspot falls out of sync with the chain - -If your Hotspot falls out of sync with the tip of the blockchain, the app will now show it's current -synced block height so you know how many blocks it has before the Hotspot is caught up. - -## Transaction Fees - -As mentioned earlier, the breaking change introduced in `1.9.0` relates to how the mobile app -calculates transaction fees. - -When the chain variable for transaction fees are activated, users will see how much it will cost to -send a payment transaction (wallet-to-wallet), add a hotspot, and update hotspot location. - -All Hotspots from Helium will continue to see 0 fees for adding a Hotspot, and setting a location -for the first time. - -We will send another notice when the chain variable is activated. - -# Bug Fixes - -- Fixed Hotspot filter for consensus groups - -- Fixed how participants in a challenge and witnesses are displayed in the mobile app. - -- Fixed Hotspot loading times for those with 50+ Hotspots in their app - -- Fixed stale data when swiping between Hotspots - -### Known Issues - -Switching Wi-Fi networks doesn't work if both Wi-Fi networks are found in the scan list. - -- If you need to update your Wi-Fi credentials and both old and new networks appear in the scan - list, contact support@helium.com and we can help manually update it for you. diff --git a/devblog/2020-06-26-console-updates.mdx b/devblog/2020-06-26-console-updates.mdx deleted file mode 100644 index fba55da56..000000000 --- a/devblog/2020-06-26-console-updates.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -layout: post -title: Console Import and Data Credits -date: 2020-06-26 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -### Key feature updates - -Next week we’ll provide the ability to import devices from The Things Network Console directly from -the Helium Console. - - - -That capability currently exists with our CLI tool -[here](https://developer.helium.com/console/console-cli-and-api/cli), but we’ve made it easier to -perform directly from the Console UI. - -### Acquire Data Credits - -Devices will need Data Credits to transfer payload data (uplink and downlink) on the Helium Network. - -We’re taking a phased approach to when: - -1. Users can acquire Data Credits via credit cards. -2. Users can acquire Data Credits via HNT. - -In terms of deployment, we plan to make Data Credit acquisition with Credit Cards and via HNT in -July. - -**Even though Console users will be able to initially acquire Data Credits, we will communicate when -devices will require them at a later date.** - -### Phase 1 Purchase via credit card - -We’re starting with Data Credit purchases via credit cards. - -Users will be able to: - -- Purchase Data Credits directly through Console (minimum $10 transactions), per organization. -- Set up a recurring autopayment when their Data Credit reaches a certain balance ($5 equivalent - worth of Data Credits). -- Receive email alerts for a number of conditions related to Data Credits. -- Add multiple stored credit cards. - -### Phase 2 Purchase via HNT - -A number of users have requested to use their own HNT to acquire Data Credits. - -After we have completed the Credit Card implementation we’re moving on to allow users to convert HNT -to acquire Data Credits. - -Users will be able to: - -- Acquire Data Credits with their HNT balance directly via the Console and their mobile app. -- Just use their mobile app or the Wallet CLI tool to acquire Data Credits. - -Remember Data Credits are non-transferrable, and non refundable. Users will need to make sure they -send Data Credits to the correct recipient. - -### Fixes and issues - -- We fixed a state channel bug that was causing sync call issues during downlink messages and also - blocking uplink messages. This bug also caused inaccuracies with the fcount. -- Console email invitation links work with Microsoft Outlook. -- Debug packets are limited to 10 packets before needing to refresh. -- Frequency for Downlink events are correctly reported in Console. -- Script validator payload input can accept 00 Hex. diff --git a/devblog/2020-07-01-limit-var.mdx b/devblog/2020-07-01-limit-var.mdx deleted file mode 100644 index 3b83f4974..000000000 --- a/devblog/2020-07-01-limit-var.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -layout: post -title: New Chain Variable Activation -date: 2020-07-01 10:20 -0700 -hide_table_of_contents: true -authors: [evanmcc, madninja] ---- - -The chain variable discussed -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/06/24/new-var.html) has been -activated. The limit has been set at 20 for the time, being, and we'll analyze Proof of Coverage -path variety and transaction validation times to see if we need to make any further adjustments. diff --git a/devblog/2020-07-02-blessed-snapshot.mdx b/devblog/2020-07-02-blessed-snapshot.mdx deleted file mode 100644 index 4c3f04cb0..000000000 --- a/devblog/2020-07-02-blessed-snapshot.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -layout: post -title: Blessed Snapshot -date: 2020-07-02 -hide_table_of_contents: true -authors: [fvasquez] ---- - -This release is a routine update of the onboard blessed snapshot to block height `396721`. This -allows newly onboarded Helium Hotspots to sync the whole blockchain in hours not days. - - - -### Plan - -A `2020.07.02.0` release was deployed to the beta group on the afternoon of Thursday July 2nd at -around 4:00PM PDT. After a brief testing period we expect to release this to GA around 5:00PM PDT. diff --git a/devblog/2020-07-07-docker-run-supports-region-change.mdx b/devblog/2020-07-07-docker-run-supports-region-change.mdx deleted file mode 100644 index f0eccd623..000000000 --- a/devblog/2020-07-07-docker-run-supports-region-change.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Docker Run Supports Region Change -date: 2020-07-07 10:47 -0700 -hide_table_of_contents: true -authors: [lthiery] ---- - -For those of your running -[a Miner image for Docker](https://quay.io/repository/team-helium/miner?tab=tags), there has been a -change as of `miner-XXX64_2020.07.02.0_GA` to make regional support easier to configure. - - - -Previously, regional configuration required changes to the `sys.config` file, but now it can be done -by environmental variable, making it much easier to maintain or remove the override. The previous -workaround no longer works. - -When using the `docker run` command, you will want to now use the `--env` option to set -`REGION_OVERRIDE` to the appropriate region, which would be one of the following: - -``` -US915 | EU868 | EU433 | CN470 | CN779 | AU915 | AS923 | KR920 | IN865 -``` - -For example, `--env REGION_OVERRIDE=US915` tells your miner that you are connecting to a packet -forwarder configured for the US915 region. - -Simply updating the docker image will reset the sys.config to a working default and if you were -using the previous `sys.config` copying workaround, please do not do so unless you have other -reasons to. - -Keep in mind as we work towards allowing the adding and assertion of third-party gateways on the -Helium blockchain, this override will no longer be necessary for location-asserted miners and that -fully synced as the miner will derive the region from the blockchain. - -These changes have also been documented -[here](https://developer.helium.com/blockchain/run-your-own-miner#start-container). diff --git a/devblog/2020-07-10-console-updates.mdx b/devblog/2020-07-10-console-updates.mdx deleted file mode 100644 index 7b48b22d2..000000000 --- a/devblog/2020-07-10-console-updates.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: post -title: Console Data Credit Purchase and TTN Device Import -date: 2020-07-13 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -### Key feature updates - -- Acquire Data Credits directly from Console. -- Import multiple devices from The Things Network Console directly from the Helium Console. - - - -### Acquire Data Credits with Credit Cards - -Console Administrator users can: - -- Purchase Data Credits directly through Console (minimum $10 transactions) per Organization. -- Set up a recurring autopayment when their Data Credit reaches a certain balance ($5 equivalent - worth of Data Credits). -- Add multiple stored Credit Cards. -- Transfer Data Credits to another Organization within the same Helium account. - -**Data Credits can only be created by converting HNT, however, Helium Inc. is making it easy for -customers to purchase Data Credits with a credit card by performing the conversion for customers. -Data Credits are non-transferable, are not resellable, and can only be used to pay for data transfer -and other blockchain fees.** - -For more information about Data Credits check out the blog -[here](https://blog.helium.com/data-credits-will-soon-be-live-on-the-helium-network-c672ac1aa052). - -### The Things Network Multiple Device Import - -Users can import multiple devices from The Things Network Console directly from the Helium Console. - -For easy identification and management, Console Labels can automatically be applied to imported -devices using the same names as the TTN Applications. - -### Other updates and fixes - -- Device packets now include Hotspot latitude and longitude details in the JSON schema. -- Router (Console backend) will try to assign a regionally unique devaddr, but can also reuse if - needed. More information about devaddr [here](https://developer.helium.com/longfi/longfi-routing). diff --git a/devblog/2020-07-10-wifi-states.mdx b/devblog/2020-07-10-wifi-states.mdx deleted file mode 100644 index d672132a6..000000000 --- a/devblog/2020-07-10-wifi-states.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: WiFi States -date: 2020-07-10 -hide_table_of_contents: true -authors: [fvasquez] ---- - -This `2020.07.09.0` release fixes longstanding bugs in gateway-config that resulted in incorrect -WiFi network states being reported to the mobile app and via the Hotspot's LED. - - - -This release also updates the onboard blessed snapshot to block height `407521`. This allows newly -onboarded Helium Hotspots to sync the whole blockchain in hours not days. - -### Contents - -- _Rework WiFi State Changes_: PR: - - [gateway-config/60](https://github.com/helium/gateway-config/pull/60) - -### Plan - -A `2020.07.09.0` release candidate was deployed to the beta group on the evening of Thursday July -9th at around 8:15PM PDT. After overnight testing we expect to release this candidate to GA before -12:00PM PDT the following morning. diff --git a/devblog/2020-07-13-app-version-200.mdx b/devblog/2020-07-13-app-version-200.mdx deleted file mode 100644 index abaf95d61..000000000 --- a/devblog/2020-07-13-app-version-200.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: App Version 2.0.0 -date: 2020-07-13 -hide_table_of_contents: true -authors: [cokes518] ---- - -## Removal of GPS Status - -In our last release `1.9.0`, we introduced and experimental feature on a Hotspot's GPS status that -was meant to be informational. - - - -It was clear to us that GPS was not a useful metric to validate Hotspot coverage as satellite -positions change, clouds get in the way, or if a tree happened to sway in the wind. - -Because of this, we are removing the GPS information and will not depend on it to determine a -Hotspot's ability to earn HNT. - -Some other updates: - -- We've updated the API used under the hood. -- You may notice Hotspot Activity loading take a bit longer. We've changed how that information is - loaded so that the rest of the app is speedier, and swiping between Hotspots is less buggy. -- Wallet now supports sending payments using `payments_v2` transaction types. -- Fixed a crash when viewing a `Confirm Location` transaction on the accounts page - -### Known Issues - -Switching Wi-Fi networks doesn't work if both Wi-Fi networks are found in the scan list. - -- If you need to update your Wi-Fi credentials and both old and new networks appear in the scan - list, contact support@helium.com and we can help manually update it for you. diff --git a/devblog/2020-07-16-app-version-201.mdx b/devblog/2020-07-16-app-version-201.mdx deleted file mode 100644 index f304bbd04..000000000 --- a/devblog/2020-07-16-app-version-201.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: App Version 2.0.1 -date: 2020-07-16 -hide_table_of_contents: true -authors: [cokes518] ---- - -In this release, we are focused on squashing bugs and updating our community link to reflect our -move to Discord! - - - -Bugs Fixed: - -- Better account address validation for payments -- Updated community link -- Fix for sync percentage in diagnostic report -- Fix for add hotspot - -### Known Issues - -Switching Wi-Fi networks doesn't work if both Wi-Fi networks are found in the scan list. - -- If you need to update your Wi-Fi credentials and both old and new networks appear in the scan - list, contact support@helium.com and we can help manually update it for you. diff --git a/devblog/2020-07-17-snr-witness-data.mdx b/devblog/2020-07-17-snr-witness-data.mdx deleted file mode 100644 index 8ab6dab44..000000000 --- a/devblog/2020-07-17-snr-witness-data.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: SNR and frequency witness data -date: 2020-07-17 -hide_table_of_contents: true -authors: [fvasquez] ---- - -This `2020.07.16.0` release adds a chain variable for radio data gathering to aid with improvements -to proof-of-coverage. When the chain variable is activated the witness data collected will include -signal-to-noise ratio and frequency fields. - - - -This release also bumps the onboard blessed snapshot to block height `417601`. - -### Contents - -- _SNR and frequency witness data_: PR: - - [blockchain-core/540](https://github.com/helium/blockchain-core/pull/540) - -### Plan - -A `2020.07.16.0` release was deployed to the beta group on the evening of Thursday July 16 at around -6:45PM PDT. After overnight testing we expect to release this to GA around 10:15AM PDT the following -morning. diff --git a/devblog/2020-07-20-scv2.mdx b/devblog/2020-07-20-scv2.mdx deleted file mode 100644 index 6f7b42a49..000000000 --- a/devblog/2020-07-20-scv2.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: State Channels v2 -date: 2020-07-20 10:27 -0700 -hide_table_of_contents: true -authors: [jadeallenx] ---- - -This release lands a bunch of work (4000+ lines of code) to enable state channels v2. This release -lays the ground work to start charging and accounting for data credits to move data across the -Helium network. - - - -### Contents - -- _State Channels v2_: PRs: [core/543](https://github.com/helium/blockchain-core/pull/543) - [miner/447](https://github.com/helium/miner/pull/447) - -### Plan - -A `2020.07.17.0` release was deployed to the beta group the evening of Friday the 17th PST. Chain -variable activation to switch to v2 channels is scheduled to happen tomorrow (21 July). After -testing over the weekend we expect to release this to GA around 11:15AM PDT Monday morning July 20. diff --git a/devblog/2020-07-24-console-updates.mdx b/devblog/2020-07-24-console-updates.mdx deleted file mode 100644 index 10332962b..000000000 --- a/devblog/2020-07-24-console-updates.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -layout: post -title: Console Data Credits via HNT -date: 2020-07-24 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -We’ve moved the date when devices need Data Credits from 7/27 to 8/3. On 8/3 all device owners must -pay Data Credits to transfer packets and Hotspots start earning HNT for data transfer from devices. - - - -### Key feature updates - -- Acquire Data Credits with HNT -- Email notifications and UI improvements - -### Acquire Data Credits with HNT - -We’ve made further updates in preparation for Data Credits going live. We anticipate these updates -will be released week of 7/27. - -- Owners of HNT will be able to acquire Data Credits by ‘burning’ or converting their HNT into Data - Credits. -- Initially HNT owners can use the Wallet CLI tool and then later directly with the Helium mobile - app. - -More Data Credit information -[here](https://blog.helium.com/data-credits-will-soon-be-live-on-the-helium-network-c672ac1aa052). - -### Email notifications and UI improvements - -- Email notifications will be sent to administrators for Data Credit events including: purchases, - transfers, low Data Credit balances. -- Data Credit balances for Organizations and Devices added to UI. - -### Other updates and fixes - -- The styling of Console has been updated for improved usability. -- Every new Console sign up receives 10,000 Data Credits (existing Console users also received). -- Backend updates for better performance. - -### Upcoming - -Here’s what we’re focused on in the coming weeks (usual disclaimers apply): - -- Add multiple devices to Console through import via CSV file. -- Provide support for LoRaWAN ADR. -- Open sourcing Console and its backend network server and blockchain components (Router). diff --git a/devblog/2020-07-24-forget-wifi.mdx b/devblog/2020-07-24-forget-wifi.mdx deleted file mode 100644 index 75bf4998a..000000000 --- a/devblog/2020-07-24-forget-wifi.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: Forget WiFi Networks -date: 2020-07-24 -hide_table_of_contents: true -authors: [fvasquez] ---- - -This `2020.07.24.0` release completes the "Forget Network" feature that will be added to an upcoming -version of the Helium mobile app. We also fixed a couple bugs and added debugging to prepare for -upcoming state channels V2 chain variable. - - - -This release also updates miner to handle payerless assert location transactions and bumps the -onboard blessed snapshot to block height `427681`. - -### Contents - -- Convert PayerB58 of [] to `<<>>`: PR: - - [blockchain-core/546](https://github.com/helium/blockchain-core/pull/546) -- _Delete profile directories after removing WiFi network_: PR: - - [gateway-config/62](https://github.com/helium/gateway-config/pull/62) -- _Reattempt to connect to WiFi network when agent off_: PR: - - [gateway-config/61](https://github.com/helium/gateway-config/pull/61) - - [blockchain-core/545](https://github.com/helium/blockchain-core/pull/545) - - [miner/437](https://github.com/helium/miner/pull/437) - -### Plan - -A `2020.07.24.0` release was deployed to the beta group on the morning of Friday July 24 at around -11:00AM PDT. A `2020.07.23.0` release candidate was deployed to the beta group the previous evening -for overnight testing. After confirming that reasserting a Helium Hotspot's location works from the -mobile app we expect to release `2020.07.24.0` to GA around 12:00PM PDT Friday diff --git a/devblog/2020-07-27-app-version-210.mdx b/devblog/2020-07-27-app-version-210.mdx deleted file mode 100644 index 23fc3b199..000000000 --- a/devblog/2020-07-27-app-version-210.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: App Version 2.1.0 -date: 2020-07-27 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -Forget Wi-Fi Network - -- This feature allows users to forget a wi-fi network that the Hotspot has remembered, so that you - can either update the password, or connect to a new network -- To forget a network, tap the Hotspot settings, pair with the Hotspot, and tap the network name. - The app will cycle through all the networks profiles saved on the Hotspot until they're all - forgotten. Then you can connect to a new network. - - - -Updated Assert Location - -- We've updated the UI when a user sets their location. It will also show how much HNT needs to be - burned in order to update location. -- A reminder: All Hotspots come with 1 free add_gateway and 1 free assert_location transaction when - purchased from Helium. - -## Bug Fixes - -- In the Network > challenges page, sometimes tapping on a challenge will display a completely - unrelated challenge. This is fixed. diff --git a/devblog/2020-07-29-downlink-fix.mdx b/devblog/2020-07-29-downlink-fix.mdx deleted file mode 100644 index 7bf0a95d6..000000000 --- a/devblog/2020-07-29-downlink-fix.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: Prevent Dropped Downlink Packets -date: 2020-07-29 -hide_table_of_contents: true -authors: [fvasquez] ---- - -This `2020.07.29.0` release fixes a bug in miner that resulted in numerous downlink LoRa packets -being dropped. - - - -In addition, this release upgrades the Linux image on the Helium Hotspot to Buildroot 2020.02.1. -This LTS release of Buildroot includes various security fixes and allowed us to upgrade the onboard -Erlang/OTP installation to 22.3.1. - -Lastly, this release also bumps the onboard blessed snapshot to block height `435601`. - -### Contents - -- _Prevent dropped downlink packets_: PR: - - [miner/465](https://github.com/helium/miner/pull/465) - -### Plan - -A `2020.07.29.0` release was deployed to the beta group on the morning of Wednesday July 29 at -around 10:30AM PDT. After reactivating the `state_channels_v2` chain variable we expect to release -`2020.07.29.0` to GA at 2:00PM PDT later that day. diff --git a/devblog/2020-07-31-bugfix-release-for-hotspots-dropping-packets.mdx b/devblog/2020-07-31-bugfix-release-for-hotspots-dropping-packets.mdx deleted file mode 100644 index 2edc5dd83..000000000 --- a/devblog/2020-07-31-bugfix-release-for-hotspots-dropping-packets.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: Bugfix Release for Hotspots Dropping Packets -date: 2020-07-31 -hide_table_of_contents: true -authors: [vihu] ---- - -This `2020.07.31.0` release fixes an issue in libp2p which prevented some hotspots from being able -to reach the router when they didn't have router in their peerbook. - - - -We have updated `erlang-libp2p` and introduced a `miner` configuration option named `node_aliases` -to allow hotspots to connect to the router despite them not having it in their peerbook. - -### Contents - -- _Use aliases to shortcut p2p lookups_: PR: - - [erlang-libp2p/294](https://github.com/helium/erlang-libp2p/pull/294) - -### Plan - -We will beta `2020.07.31.0` around 2:50 PM PDT Friday July 31 and monitor the router and beta -hotspots closely. If testing goes as planned we will GA shortly afterwards by 3:30 PM PDT. diff --git a/devblog/2020-07-31-console-postmortem.mdx b/devblog/2020-07-31-console-postmortem.mdx deleted file mode 100644 index 8a8043471..000000000 --- a/devblog/2020-07-31-console-postmortem.mdx +++ /dev/null @@ -1,68 +0,0 @@ ---- -layout: post -title: Console Post Mortem -date: 2020-07-31 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -### Summary - -- We're moving the Phase 3 Data Credits go live date to 8/11 for further testing and fixing issues. -- A fix has been pushed to address issue with Hotspots not transferring packets. -- We're going to improve communication and status of issues with this tool, subscribe - [here](http://status.helium.com/). - - - -### Long week - -It’s been a long week for Console and we’re sorry for any inconvenience. - -Throughout this entire process we have tried to be transparent to keep users informed and updated as -best we could. - -Releasing Data Credits live is an important milestone and these updates need to be made before any -devices started paying for packets and Hotspots can start earning rewards for transferring. - -During testing we have discovered issues that we’ll need additional time to fix and test. - -**Therefore the team has decided to push the phase 3 Data Credits live date from 8/4 to 8/11.** - -Until then device users will continue to connect without needing Data Credits, and Hotspots will -continue earning as usual. - -### What went wrong - -These state channel v2 changes are a massive protocol update for the -[blockchain](https://github.com/helium/blockchain-core/pull/543). We've needed to test state -channels to ensure devices correctly pay for connectivity with Data Credits, and verify correct -communication between the Console backend (Router), and Hotspots to accept the offer and sent -packets to the desired location. There was an issue with state channels not correctly spaced out and -a gap ensued. This communication issue between state channels and Router prevented packets from -being forwarded. We -[updated chain vars](https://github.com/helium/miner/blob/master/audit/var-36.md) to fix this issue. - -Another [issue](https://github.com/helium/erlang-libp2p/pull/294) prevented Hotspots from forwarding -packets despite otherwise normally participating in POC challenges. - -We pushed out a fix this afternoon which includes a mechanism that allows a Hotspot to connect to -Console when transferring packets. - -### Better communication - -To improve communication going forward in addition to Discord announcements, we will ensure Console -backend (Router) status is kept up to date [here](http://status.helium.com/). - -This tool will allow us to better provide status updates in real time, and we will also use it for -future planned maintenance updates. Please subscribe to get updated in real time. - -After Data Credits go live, we will give much more advanced notice for future maintenance updates -that may result in interruption of packet transfers and minimize the time frame for disruptions. -However, we don’t anticipate needing to make any fundamental infrastructure changes that rival the -scope of the work that caused this outage. - -### We’re sorry - -All the teams, blockchain, firmware, Console work very hard with the community to build this network -and the tools needed to use it and our sincerest apologies for the interruptions. diff --git a/devblog/2020-08-04-app-version-211.mdx b/devblog/2020-08-04-app-version-211.mdx deleted file mode 100644 index 9b0d46241..000000000 --- a/devblog/2020-08-04-app-version-211.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -layout: post -title: App Version 2.1.1 -date: 2020-08-04 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Bug Fixes - -This release is to prep for the new Hotspots coming online, plus a few bug fixes. - -- Fix crash when tapping reward transactions with 0 amount -- Add missing translation for data credit rewards -- Fix account addresses being cut off in Android transaction details -- Change hotspot activity reward transactions to just show HNT earned -- Fix payment transactions not rendering correctly in block details -- Fix assert location for accounts with 0 balance diff --git a/devblog/2020-08-06-console-updates.mdx b/devblog/2020-08-06-console-updates.mdx deleted file mode 100644 index 8b366071a..000000000 --- a/devblog/2020-08-06-console-updates.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: Console Updates- Data Credits prep and multi-device import -date: 2020-08-06 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -ICYMI next Tuesday 8/11 device owners must pay Data Credits for devices to transfer packets and -Hotspots earn HNT for forwarding device data. - - - -### Key Feature Updates - -- Router (Console Backend) integrated with state channels v2 to accept packet offers from Hotspots - based on Data Credit balances. -- Add multiple devices to Console through import via CSV file. Use a CSV file with DevEUI, AppEUI, - AppKey, and name column headings to import multiple devices. Users can also include an optional - LabelID column heading to automatically create and assign a label. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Owners of HNT will be able to acquire Data Credits by ‘burning’ or converting their HNT into Data - Credits. HNT owners can either scan a QR code on Console with the Helium mobile app or use the - Wallet CLI tool to burn HNT and send Data Credits to an Organization within a Helium account -- Provide ability to pause data transfer for a device or an Organization. -- Make debug information easier to view -- Allow users to manually test downlink for a device from within Console. -- Include support for LoRaWAN adaptive data rate (ADR). -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-08-07-bugfix-release-for-state-channel-causality-issues.mdx b/devblog/2020-08-07-bugfix-release-for-state-channel-causality-issues.mdx deleted file mode 100644 index 48bf3d856..000000000 --- a/devblog/2020-08-07-bugfix-release-for-state-channel-causality-issues.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: Bugfix Release for State Channel Causality Issues -date: 2020-08-07 09:43 -0700 -hide_table_of_contents: true -authors: [vihu, vagabond] ---- - -This `2020.08.06.0` release fixes a few issues related to state channel v2 causality problems we -were seeing on chain. Essentially, we see hotspots file a duplicate state channel close txn despite -the fact that the router has already submitted one. This release attempts to fix that. - - - -We also fixed some reported concerns of miners crashing when trying to send packets to router. - -Additionally, the blessed snapshot was bumped to 447121. - -### Contents - -- _Fix state channel causality issues_: PR: - - [blockchain-core/550](https://github.com/helium/blockchain-core/pull/550) -- _Potential fix for undefined chain on dial_success_: PR: - - [blockchain-core/552](https://github.com/helium/blockchain-core/pull/552) -- _Updates for state channel causality fixes_: PR: - - [miner/471](https://github.com/helium/miner/pull/471) -- _limit peer connection gossip, use random for eligible peers_: PR: - - [libp2p/295](https://github.com/helium/erlang-libp2p/pull/295) - -### Plan - -We have been running `2020.08.06.0` in beta since 4:00 PM PDT Thursday August 06 and have been -monitoring the router and beta hotspots closely. If testing goes as planned we will GA shortly today -Friday August 07 around 10:30 AM PDT. diff --git a/devblog/2020-08-10-snapshot-ooms-and-state-channel-lifecycle-issues.mdx b/devblog/2020-08-10-snapshot-ooms-and-state-channel-lifecycle-issues.mdx deleted file mode 100644 index 47e362591..000000000 --- a/devblog/2020-08-10-snapshot-ooms-and-state-channel-lifecycle-issues.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Bugfix Release for Snapshot OOMs and State Channel Lifecycle Issues -date: 2020-08-10 16:00 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -This `2020.08.10.0` release fixes an out of memory issue encountered when computing blockchain -snapshots, especially consensus members, which has been leading to the rough block times over the -weekend. Additionally a couple state channel issues have been identified and fixed as well. - - - -### Contents - -- _Fix spurious state channel close_: PR: - - [blockchain-core/559](https://github.com/helium/blockchain-core/pull/559) -- _Limit memory usage when computing snapshots_: PR: - - [blockchain-core/555](https://github.com/helium/blockchain-core/pull/555) -- _Improve performance of packet offer rejections_: PR: - - [blockchain-core/554](https://github.com/helium/blockchain-core/pull/554) - -### Plan - -We will beta `2020.08.10.0` this afternoon PST and release it to GA this evening or early tomorrow. diff --git a/devblog/2020-08-11.0-reliability-improvements.mdx b/devblog/2020-08-11.0-reliability-improvements.mdx deleted file mode 100644 index 2713d52cd..000000000 --- a/devblog/2020-08-11.0-reliability-improvements.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: Bugfix Release for Reliability Improvements -date: 2020-08-11 15:40 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -This `2020.08.11.0` release fixes another out of memory condition during elections, it also fixes an -issue with transactions larger than 65kb and finally it improves restart behavior when certain -essential processes crash. - - - -### Contents - -- _Reduce memory overhead during elections_: PR: - - [blockchain-core/563](https://github.com/helium/blockchain-core/pull/563) -- _Improve hbbft transaction encoding/decoding robustness_: PR: - - [hbbft/58](https://github.com/helium/erlang-hbbft/pull/58) -- _Rework miner supervisor tree_: PR: - - [miner/450](https://github.com/helium/miner/pull/450) - -### Plan - -We will beta `2020.08.11.0` this afternoon PST and release it to GA on an accelerated schedule -because the transaction encoding fix is not backwards compatible. diff --git a/devblog/2020-08-12-blockchain-state-channel-optimizations.mdx b/devblog/2020-08-12-blockchain-state-channel-optimizations.mdx deleted file mode 100644 index 8c413fa5b..000000000 --- a/devblog/2020-08-12-blockchain-state-channel-optimizations.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: Blockchain State Channel Optimizations -date: 2020-08-12 16:18 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -This `2020.08.12.0` release addresses some of the concerns regarding the opening/closing of state -channels responsible for packet transfer. Essentially it allows the router to maintain state -channels better as we have introduced proper rollover of the channels on DC exhaustion. - - - -Lastly, we removed a lot of extraneous logging which should improve performance on the Hotspots. - -### Contents - -- _Reduce state channel server logging_: PR: - - [blockchain-core/567](https://github.com/helium/blockchain-core/pull/567) -- _Lookup ledger before client issues an sc close txn_: PR: - - [blockchain-core/565](https://github.com/helium/blockchain-core/pull/565) -- _Minimal state channel rollover_: PR: - - [blockchain-core/560](https://github.com/helium/blockchain-core/pull/560) - -### Plan - -We will beta `2020.08.12.0` this evening around 5PM PST and release it to GA on an accelerated -schedule. diff --git a/devblog/2020-08-14-app-version-213.mdx b/devblog/2020-08-14-app-version-213.mdx deleted file mode 100644 index 279de007c..000000000 --- a/devblog/2020-08-14-app-version-213.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -layout: post -title: App Version 2.1.3 -date: 2020-08-14 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Bug Fixes - -This release fixes the websockets used on the main Accounts page (it was using the old API, now uses -the new one) and updates the polling interval to 30 seconds so it can fetch recently cleared pending -transactions. - -It also fixes a bug where NaN is displayed for pending transactions. diff --git a/devblog/2020-08-14-stabilization.mdx b/devblog/2020-08-14-stabilization.mdx deleted file mode 100644 index 0ff8c1847..000000000 --- a/devblog/2020-08-14-stabilization.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Stabilization Firmware Release -date: 2020-08-14 15:30 -0700 -hide_table_of_contents: true -authors: [evanmcc, vihu] ---- - -Recent increases in the size of the network have caused some scaling issues. When the network was -smaller, we wrote some code without concern for scaling, pulling the entirety of various data -structures off of disk and into memory for the duration of various operations. The code was simpler -that way, but these in-memory structures have come to cause a lot of problems as the number of -gateways has gotten larger. - - - -The `2020.08.14.0` release includes incrementalized rewrites of all of the above mentioned places, -which were causing OOM issues on some of our older Hotspot hardware when in the consensus group. It -shouldn't change the behavior of the network other than to allow smoother block times. - -Furthermore, we have also fixed a few more bottlenecks concerning state channel clients that should -further increase the likelyhood of hotspots being able to transfer packets. - -This release also bumps the blessed snapshot and contains some bugfixes for full nodes. - -### Contents - -- _Reduce Snapshot Cost_: PR: - - [blockchain-core/557](https://github.com/helium/blockchain-core/pull/557) -- _Incrementalize Metadata and Reassertion_: PR - - [blockchain-core/571](https://github.com/helium/blockchain-core/pull/571) -- _Cache pubkeybin and sigfun on sc client_: PR: - - [blockchain-core/578](https://github.com/helium/blockchain-core/pull/578) - -### Plan - -We will beta `2020.08.14.0` this afternoon PST and release it to GA on an accelerated schedule in -hopes of stabilizing the chain. diff --git a/devblog/2020-08-15-memory-and-state-channel-improvements.mdx b/devblog/2020-08-15-memory-and-state-channel-improvements.mdx deleted file mode 100644 index 8f9c7065b..000000000 --- a/devblog/2020-08-15-memory-and-state-channel-improvements.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: Blockchain Memory Usage and State Channel Improvements -date: 2020-08-14 10:05 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -This `2020.08.14.1` release addresses some excessive memory use that is causing issues as the -network grows. Additionally, we have identified several improvements that should help with -performance and with the reliability of state channels. - - - -### Contents - -- _Memory use improvements_: PRs: - - [blockchain-core/571](https://github.com/helium/blockchain-core/pull/571) - - [blockchain-core/557](https://github.com/helium/blockchain-core/pull/557) -- _State channel improvements_: PR: - - [blockchain-core/579](https://github.com/helium/blockchain-core/pull/579) - - [blockchain-core/572](https://github.com/helium/blockchain-core/pull/572) - - [miner/487](https://github.com/helium/blockchain-core/pull/487) -- _Performance improvements_: PRs: - - [blockchain-core/580](https://github.com/helium/blockchain-core/pull/580) - - [blockchain-core/578](https://github.com/helium/blockchain-core/pull/578) - - [libp2p/298](https://github.com/helium/erlang-libp2p/pull/298) - -### Plan - -We have been betaing `2020.08.14.1` since late last night on the 14th PST. We will release it to GA -around 10:30 am PST. diff --git a/devblog/2020-08-18-further-state-channel-improvements.mdx b/devblog/2020-08-18-further-state-channel-improvements.mdx deleted file mode 100644 index 2bc21fc00..000000000 --- a/devblog/2020-08-18-further-state-channel-improvements.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -layout: post -title: Further state channel improvements -date: 2020-08-18 21:00 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -This `2020.08.18.4` release addresses some addtional issues in the state channel client. It simply -consists of 4 commits backported from a state channel fixup branch: - - - -- [Safely get num_dcs for a state channel](https://github.com/helium/blockchain-core/commit/e247c489a9484472d3d930b41758f36535dbe912) -- [Use a queue for pending packets in state channel client](https://github.com/helium/blockchain-core/commit/2c00a71884d91d9250c7a26e636baff5b4fb1a76) -- [Don't send on channel until banner; avoid redundant sc broadcasts](https://github.com/helium/blockchain-core/commit/c82ae4cea341a0ce663604aa1a6db161c7acabf1) -- [Don't loose packet ordering on the client side](https://github.com/helium/blockchain-core/commit/b96223aa5f4d038dcda44e7e43e187ee2764005a) - -### Plan - -We have been betaing `2020.08.18.4` and its prior tags throughout the day and will be releasing it -GA by 9:30 pm PST. diff --git a/devblog/2020-08-21-HIP-10-implementation.mdx b/devblog/2020-08-21-HIP-10-implementation.mdx deleted file mode 100644 index f22a31508..000000000 --- a/devblog/2020-08-21-HIP-10-implementation.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: HIP-10 Implementation Release -date: 2020-08-21 12:30 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -This `2020.08.21.0` provides an implementation of -[HIP-10](https://github.com/helium/HIP/blob/master/0010-usage-based-data-transfer-rewards.md). The -implementation is gated behind a chain var, which we will activate once everyone has upgraded and -we've finalized and announced an activation date and time. - - - -### Contents - -- _HIP-10 implementation_: PRs & fixes: - - - [blockchain-core/587](https://github.com/helium/blockchain-core/pull/587) - - [Fix typo in HIP-10 implementation](https://github.com/helium/blockchain-core/commit/076dae6d935309997d9ebf4b8fd2d5741f7aca12) - - [Make floating point calculations in HIP-10 backwards compatible](https://github.com/helium/blockchain-core/commit/ac84f6195b2190e21db2d4b14d017a2082546ba4) - -- _Prevent deduplication of transactions with same payload in transaction manager_: PRs: - - [blockchain-core/586](https://github.com/helium/blockchain-core/pull/586) - -### Plan - -We have been betaing `2020.08.21.0` since last night and expect to release it to GA this afternoon. diff --git a/devblog/2020-08-26-budget.mdx b/devblog/2020-08-26-budget.mdx deleted file mode 100644 index 3dd607a5a..000000000 --- a/devblog/2020-08-26-budget.mdx +++ /dev/null @@ -1,67 +0,0 @@ ---- -layout: post -title: Validation Budgets and Stablization Window -date: 2020-08-26 10:30 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -**Final Update:** - -The updated release had some issues with loading ledger snapshots on first-generation Hotspot -hardware, and we had to cut the `2020.08.26.0` release in order to reduce snapshot import memory -usage. Since the only new behavior was -[core PR 599](https://github.com/helium/blockchain-core/pull/599), we did a very short beta to -confirm the fix for the issue and released the image to GA around 12:30PM PDT. - - - -**Original Post:** - -The `2020.08.25.0` release focuses primarily on to changes to the functioning of the consensus -group. - -Heretofore, the group used a particular block as the start of its stabilization window (the time -period over which we attempt to maintain the one block per minute cadence). With this release we -move to a rolling 100000 block window to maintain responsiveness and to adapt to the post-snapshot -world where most new Hotspots don't have the target block. Prior to this release we also simply -failed to the present block when calculating the catchup time, and this release we use the earliest -available block if the target block for the start of the window is not available. - -We've been seeing a lot of long block times recently, for which we apologize. A major source of -disruption that we've seen is that transaction validation times have bloated as the size of the -network has grown. In particular, the most expensive part of validating or constructing a block is -the verification of Proof of Coverage receipts. We've noticed that a class of these are extremely -expensive to validate for various reasons. As a result, we're adding a time budget for the -verification of any individual transaction. This may result in the lower receipt acceptance rates -for certain Hotspots, but we've set the budget generously at a limit that we think will not affect -most users, but should improve chain stability. - -This release also bumps the blessed snapshot to 468001. - -**Update:** We found an issue with the windowing adjustments that wasn't revealed by the beta -process (it only caused issues on consensus group members) which we have now fixed in release -`2020.08.26.0`, which contains all of these PRs plus two additional changes to fix the issue. - -### Contents - -- _Stabilization Window_ PRs: - - - [blockchain-core/589](https://github.com/helium/blockchain-core/pull/589) - - [miner/488](https://github.com/helium/miner/pull/488) - -- _Validation Budget_ PR: - - [miner/491](https://github.com/helium/miner/pull/491) - -**Update**: - -- _Fix last-minute issues_ PRs: - - [miner/494](https://github.com/helium/miner/pull/492) - - [blockchain-core/596](https://github.com/helium/blockchain-core/pull/596) - -### Plan - -We have been betaing `2020.08.25.0` since last night and expect to release it to GA this morning. - -**Update:** We found a critical issue at the last moment and cut another image (`2020.08.26.0`), -which will go through the beta process and be deployed as soon as this evening. diff --git a/devblog/2020-08-27-app-version-220.mdx b/devblog/2020-08-27-app-version-220.mdx deleted file mode 100644 index a5f893356..000000000 --- a/devblog/2020-08-27-app-version-220.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: App Version 2.2.0 -date: 2020-08-27 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Updated Payments UI - -In this new update, we've revamped the payments UI. Use the QR code scanner to not only populate the -recipient address, but HNT amounts embedded in the QR code will populate as well! - - - -A guide on how to generate these new QR codes will be coming soon. - -## Burn HNT to generate DC on behalf of a Console user - -Since the launch of Data Credits, Console users were only able to purchase Data Credits using a -credit card. But what if you have access to HNT? With this new update, you can generate a Burn HNT -transaction from Console, scan the QR code using the app, and HNT will automatically be burned, -generating Data Credits that goes into your Console account. - -Never run out of DC again. - -# Bug Fixes - -- This updates an error message when trying to add a Hotspot and the miner is busy. -- Fixes a bug when trying to update location diff --git a/devblog/2020-08-27-console-updates.mdx b/devblog/2020-08-27-console-updates.mdx deleted file mode 100644 index 4a1e90b24..000000000 --- a/devblog/2020-08-27-console-updates.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Console Updates- Burn HNT to Data Credits -date: 2020-08-27 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Owners of HNT can acquire Data Credits by ‘burning' their HNT into Data Credits. - - - -### Key Feature Updates - -HNT owners can either scan a QR code on Console with the Helium mobile app or use the Wallet CLI -tool to burn HNT and send Data Credits to an Organization within a Helium account. These -transactions will appear on the Console Data Credits page and the Data Credit balance will be -updated accordingly. - -On Console, users choose the Data Credit amount they want to add to their account and select Burn -HNT to DC. This burn action can be accomplished using either the Helium App or the Helium Wallet CLI -Tool: - -- On the Helium App (v2.2.0 or above), tap Send and open the QR code scanner located on the top left - of the screen. -- To use the Wallet CLI tool, follow the directions - [here](https://developer.helium.com/blockchain/blockchain-cli#burn). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Fix recently discovered issues related to packet loss. -- Allow users to manually test downlink for a device from within Console. -- Provide ability to pause data transfer for a device or an Organization. -- Make debug information easier to view. -- Include support for LoRaWAN adaptive data rate (ADR). -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-09-01-minor-release-for-state-channel-fixes.mdx b/devblog/2020-09-01-minor-release-for-state-channel-fixes.mdx deleted file mode 100644 index 57510ae40..000000000 --- a/devblog/2020-09-01-minor-release-for-state-channel-fixes.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -layout: post -title: Minor release for State Channel fixes -date: 2020-09-01 13:19 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -This `2020.09.01.0` release is a minor bugfix release to fix state channel issues on the hotspots so -they can continue to transfer data. We have also added initial support for third-party gateways. - - - -- [Fix incorrect causality check for SC client](https://github.com/helium/blockchain-core/pull/600) -- [Read onboarding key for third-party gateways](https://github.com/helium/miner/pull/497) - -### Plan - -We have been betaing `2020.09.01.0` and its prior tags throughout the day and will be releasing it -GA by 2 PM PST. diff --git a/devblog/2020-09-03-state-channel-performance-improvements.mdx b/devblog/2020-09-03-state-channel-performance-improvements.mdx deleted file mode 100644 index 34b96f898..000000000 --- a/devblog/2020-09-03-state-channel-performance-improvements.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: post -title: State channel performance improvements -date: 2020-09-03 17:27 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -This `2020.09.03.0` release contains a small but significant performance improvement for state -channel causality validations for hotspots. We have also update the snapshot block to `480241`. - - - -- [Improve performance of client side validation of state channels](https://github.com/helium/blockchain-core/pull/605) - -### Plan - -We have been betaing `2020.09.03.0` since 4:15 PM PST this afternoon and will be releasing it to GA -by 8 PM PST. diff --git a/devblog/2020-09-04-console-updates.mdx b/devblog/2020-09-04-console-updates.mdx deleted file mode 100644 index 1fe7227af..000000000 --- a/devblog/2020-09-04-console-updates.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: post -title: Console Updates- Manual Downlink and Fixes -date: 2020-09-04 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This release includes the ability to manually downlink from Console, UI updates, and a number of -Router (backend) fixes related to packet transfer. - - - -### Features - -- Allow users to manually test downlink for a device from within Console. Instructions - [here](https://docs.helium.com/use-the-network/console/integrations/http/#downlink-tool-example). -- Updated event logs to add categories for errors. -- Provided ability on the Device index page to choose the number of devices to display on screen. -- Added the ability to apply bulk actions to all devices. - -### Fixes - -- Resolved an issue related to a state channel causality check that caused packet loss and the - ability for devices to rejoin. -- Downlink payloads no longer incorrectly display as empty in the Debug Window. -- Addressed an issue that devices may have trouble joining due to initially connecting to a Hotspot - with weak RSSI. To resolve multiple copies of packets may be purchased, but users are only charged - for one. Only the Hotspot that forwards the packet earns rewards. -- Released a patch to address the issue of DIY Hotspots not able to transfer data. As a reminder - regardless of Hotspot (DIY or “official”) devices need to pay Data Credits to transfer data. -- An issue of communication between Console and Router that led to dots or events occasionally not - updating correctly has been fixed. -- Labels no longer auto expand within Console when navigating content. -- Fixed issue preventing scrolling left nav with many Labels. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Provide ability to pause data transfer for a device or an Organization. -- Make debug information easier to view. -- Update MQTT integration to allow more flexibility. -- Include support for LoRaWAN adaptive data rate (ADR). -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-09-08-postmortem.mdx b/devblog/2020-09-08-postmortem.mdx deleted file mode 100644 index 961e70219..000000000 --- a/devblog/2020-09-08-postmortem.mdx +++ /dev/null @@ -1,110 +0,0 @@ ---- -layout: post -title: Console Post Mortem -date: 2020-09-08 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -On 8/12 the system changed the token allocation providing rewards for Hotspots that transferred data -and required devices to pay for network traffic with Data Credits. - - - -An arbitrage situation was created that allowed users to earn a disproportionately high amount of -HNT for sending packets and the network experienced a significant spike in both number of devices -(>3x), and amount of traffic (>10x). - -This caused a number of Console and Router issues. The main challenge wasn’t the amount of traffic -hitting the system. Rather the complexity involved in the interaction among devices, Hotspots, and -Router and the synchronization required for state channels to maintain an accurate accounting of -traffic sent across a decentralized network. - -This level of stress testing allowed us to identify and fix issues that would have been impossible -to simulate in a lab/staging environment. Here’s a breakdown of the main categories of issues and -their fixes. - -### Console - -Console is the front end interface between the backend (Router) and the blockchain. The additional -traffic from Router to Console caused performance issues including ‘Data Failed to Load” messages. - -#### Issues and fixes - -Issue: Delays viewing device pages, Device index, sometimes resulting in the Data Failed to Load -message. - -Fix: The database was updated to handle the additional communication between Router and Console. - -Issue: Burn HNT transaction was successful, but the Data Credit balance did not update. - -Fix: The memo field changed to dynamically update, and communication between Router and Console for -HNT burn transactions was fixed. - -### Router - -Router is the workhorse behind the scenes, transferring packets, accepting offers from Hotspots to -send packets, communicating with Console to ensure Data Credit balances are correct, and many other -functions. - -In the LoRaWAN world, Router provides the equivalent functions as Network Server, Join Server, and -Application Server, while also communicating with the Helium Blockchain. - -The HNT and DC arbitrage situation inspired users to send as much data as possible, and Router took -the brunt of those packet requests. - -#### Issues and fixes - -Issue: Devices trouble joining or issues with downlinks. - -Fix: For initial join or when downlink is queued provided an update that allows the system to choose -among several packets and pick the best one to downlink through based on signal strength. - -Issue: Accepting incorrect offers of packets from Hotspots. - -Fix: Router validation of packet offers was moved upfront. - -Issue: Router performance struggled to keep up with the number of requests while synchronizing with -state channels. - -Fix: Optimization and performance patches deployed to reduce disk writes and decrease response -times; in addition dropped redundant load from Router. - -### State Channels - -State channels are side chains used to handle the accounting and verification for Data Credit -transactions and ensure these transactions are added to the main blockchain in an efficient manner. - -The volume of micro-transactions between devices, Hotspots, and the blockchain makes account -handling and verification impossible to scale on the main blockchain. Active open state channels are -necessary for data to transfer. - -State channels necessary for packets to transfer as these microtransactions involving Data Credits -are accounted for on these state channels. - -#### Issues and fixes - -Issue: State channels not opening and closing in sync with each other. - -Fix: The number of state channels was increased from 2 to 5 to help ensure an active state channel -will be open at all times. - -Issue: State channel timing misaligned with epoch reward blocks; state channels remained open too -long. - -Fix: State channels were updated to open and close faster: the number of blocks that a state channel -remains open was also reduced, currently 40 blocks. - -The Garbage Collector (GC) is used to perform cleanup of the ledger and free up memory. - -Issue: GC was out of sync with the state channels open and close cycle preventing new state channels -opening. - -Fix: Garbage Collector was initially set to perform cleanup every 100 blocks, but clean up was made -dynamic using a chain variable, and set to 10 to align the closing of state channels. - -Issue: Packet loss and devices trouble rejoining. - -Fix: An incorrect causality check in the state channel client that caused packet loss was addressed. -A function to only add a causally newer version of the state channel to the local state channel -database was added. diff --git a/devblog/2020-09-09-minor-release-for-block-timing-fixes.mdx b/devblog/2020-09-09-minor-release-for-block-timing-fixes.mdx deleted file mode 100644 index 3c59690e3..000000000 --- a/devblog/2020-09-09-minor-release-for-block-timing-fixes.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -layout: post -title: Minor Release for Block Interval Fixes -date: 2020-09-09 09:00 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -The `2020.09.08.0` release is a minor bugfix release to fix an issue with the stabilization interval -calculations on newer Hotspots that have been loaded from a snapshot. There was an error in the how -the interval was calculated, which the PR below fixes: - - - -[Fix Time Targeting on Newer Nodes](https://github.com/helium/miner/pull/505) - -Additionally, this release bumps the blessed snapshot to height 487441. - -### Plan - -We have been betaing `2020.09.08.0` since the afternoon on the 8th and will be release it to GA by -10AM PST. diff --git a/devblog/2020-09-15-major-blockchain-release-multisig-and-poc-v9.mdx b/devblog/2020-09-15-major-blockchain-release-multisig-and-poc-v9.mdx deleted file mode 100644 index b92f47196..000000000 --- a/devblog/2020-09-15-major-blockchain-release-multisig-and-poc-v9.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -layout: post -title: Major Blockchain Release - Multisig and POC V9 -date: 2020-09-15 16:14 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The `2020.09.15.0` release is a major blockchain release adding support for two features: `Multisig` -and `POC-v9`. - - - -#### Multisig - -Currently, Helium is the sole entity involved in proposing and issuing chain variables which control -the behavior of the blockchain. This is done via signing the chain variable txn using a single -authoritative key. With the introduction of multisig, we go from having a single key to a group of -keys, a majority of which will be required to sign a chain var txn. This change is guarded behind -`use_multi_keys` chain variable and will be in effect once we activate it. - -#### Proof-of-Coverage V9 - -POC V9 now checks and validates witnesses and receipts contained within a POC transaction by -checking whether the reported RSSI, SNR and Frequency are within reasonable bounds. We have also -added `channel` and `datarate` fields to poc-witness and poc-receipt record definitions. This change -is guarded behind two chain variables that the team will activate once we GA the release. The -proposed chain variable updates are: - -- `poc_version` from 8 to 9 -- `data_aggregation_version` from 1 to 2 - -Additionally, we also improved logging to better debug POC related issues. Finally, this release -bumps the blessed snapshot to height 499681. - -#### Related PRs - -- _Add witness and receipt validation for poc txns_ - - [blockchain-core/593](https://github.com/helium/blockchain-core/pull/593) -- _Add support for POC V9_ - - [miner/507](https://github.com/helium/miner/pull/507) -- _Add channel and datarate to witness/receipt_ - - [proto/50](https://github.com/helium/proto/pull/50) -- _Add support for multisig_ - - [blockchain-core/526](https://github.com/helium/blockchain-core/pull/526) -- _Change poc_id to base64 of onion_key_hash_ - - [blockchain-core/617](https://github.com/helium/blockchain-core/pull/617) - -### Plan - -We have been betaing `2020.09.15.0` since 4 PM PST on the 15th and will be release it to GA by 8 PM -PST. diff --git a/devblog/2020-09-16-blockchain-emergency-release.mdx b/devblog/2020-09-16-blockchain-emergency-release.mdx deleted file mode 100644 index ece6628b8..000000000 --- a/devblog/2020-09-16-blockchain-emergency-release.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -layout: post -title: Blockchain Emergency Release -date: 2020-09-16 17:21 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The `2020.09.16.0` emergency release addresses the chain halt we observed after activating PoC-v9. -The team will continue to closely monitor the situation but we're fairly confident that this update -will get the blockchain moving again. - - - -### Contents - -With every chain variable update there's a little uncertainty that older code paths may get broken. -The team tries their best to test any such changes thoroughly but sometimes bugs slip through the -cracks. - -#### What exactly happened? - -- We believe that the root cause of the chain halt was the fact that we were re-validating - `poc_receipts_txn` by using a lagging ledger while trying to absorb the transaction. We have - addressed that by getting the required channel information for witnesses by walking the chain - backwards instead of relying on a potentially old ledger. - -- Furthermore, `rewards_txn` were being extremely expensive due to unnecessary logging, thereby - causing IO issues. We have reduced the log levels from `info` to `debug` to address that. - -#### Related PRs - -- - Fix poc eunits and reduce log level - * [blockchain-core/619](https://github.com/helium/blockchain-core/pull/619) -- - Dont call check_is_valid_poc to get channels\* - * [blockchain-core/621](https://github.com/helium/blockchain-core/pull/621) - -### Plan - -Since this is an emergency release, we have already began betaing it on some hotspots and will be -deploying it throughout the network around 5:30PM PST, Wednesday 16th Sept. diff --git a/devblog/2020-09-16-downgrade-poc-to-v8.mdx b/devblog/2020-09-16-downgrade-poc-to-v8.mdx deleted file mode 100644 index ad50f7b00..000000000 --- a/devblog/2020-09-16-downgrade-poc-to-v8.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -layout: post -title: Downgrade PoC to v8 -date: 2020-09-16 19:51 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -Due to the recent blockchain outage with the activation of PoC v9 and extremely slow election block -times, the team has agreed to revert back to PoC v8 while a more optimized mechanism to run PoC v9 -is being worked upon. We will continue to post updates as we make further progress. - - - -### Plan - -This chain variable is already live on the network. Details are available -[here](https://github.com/helium/miner/blob/master/audit/var-44.md). diff --git a/devblog/2020-09-17-blockchain-poc-v9-postmortem.mdx b/devblog/2020-09-17-blockchain-poc-v9-postmortem.mdx deleted file mode 100644 index a456001e5..000000000 --- a/devblog/2020-09-17-blockchain-poc-v9-postmortem.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -layout: post -title: Blockchain PoC v9 Postmortem -date: 2020-09-17 12:30 -0700 -hide_table_of_contents: true -authors: [vihu, madninja, abhay] ---- - -On 9/16/2020 the team activated -[PoC v9](https://github.com/helium/miner/blob/master/audit/var-43.md), which didn't go as planned, -causing a complete blockchain halt for ~5 hours and subsequent slow down of blocks for ~7 hours. -Longer term effects included several hotspots going out of sync for several hours after the chain -resumed. Please read on for the details on what happened, what we did in the short term to fix it, -and the steps we'll be taking to address these kinds of issues longer term. - - - -### What went wrong? - -With the introduction of PoC v9, we require validation of `poc_receipts` and `poc_witnesses` at the -time of a `poc_receipts_txn` _and_ a `rewards_txn`. Both these operations are relatively expensive -to perform, especially the rewards transaction, which grows in size relative to the number of -receipts in the election epoch. Note that the rewards transaction appears at consensus epoch change -(ideally every 30 blocks) and gathers PoC details about the past `poc_receipts_txns` which occurred -within the epoch. - -In order to validate witnesses at `rewards_txn` time, we walk the chain backwards to find the -corresponding `poc_request` transaction for each corresponding `poc_receipt` transaction to -cross-check the reported witnesses and receipts. This is a tremendously costly operation which we -did not consider during development as even a developer's slow laptop is much faster than the -deployed Generation 1 Hotspots. - -### Timeline - -#### Activation of PoC v9, Wed Sep 16 07:09:40 PM UTC 2020 - -- PoC v9 was activated in block - [502316](https://github.com/helium/miner/blob/master/audit/var-43.md) - -#### PoC v9: Blockchain Halts, Wed Sep 16 07:09:40 PM UTC 2020 - Wed Sep 16 12:09:40 PM UTC 2020 - -- At block `502342`, the blockchain came to a halt due to disagreement over the block that was - produced by the consensus round. -- We were monitoring the situation closely and ensured that we did not have any latent ledger drift, - which could cause ongoing problems in terms of consensus agreement. -- The team narrowed the root cause to two potential issues: - - A bad call to a stale ledger in `poc_receipts_txn` which we quickly fixed - [here](https://github.com/helium/blockchain-core/pull/621) - - Extraneous logging in `poc_receipts_txn` and `rewards_txn`, which we addressed - [here](https://github.com/helium/blockchain-core/pull/619) -- A subsequent - [release](https://engineering.helium.comhttps://docs.helium.com/blog/2020/09/16/blockchain-emergency-release.html) - with the above two fixes was GA-ed and deployed immediately - -#### Continued Troubles: Extremely long election blocks, Wed Sep 16 12:09:40 PM UTC 2020 - -- Despite the emergency release, the team noticed that election blocks were taking close to 15 - minutes to get accepted. This is unacceptable behavior and was causing eventual network gossip - collapse. -- In order to maintain ~60s block times, the team agreed to downgrade PoC v9 back to v8 while a more - optimized fix for PoC v9 was being discussed internally. - -#### Downgrading back to PoC v8, Thu Sep 17 02:34:45 AM UTC 2020 - -- After internal discussion and ensuring that downgrading PoC back to v8 was safe and backwards - compatible, the team issued another chain variable transaction to revert back to PoC v8. - [Details](https://github.com/helium/miner/blob/master/audit/var-44.md) -- This was sufficient to get back to normal block and election times. - -#### Addressing stuck hotspots, Thu Sep 17 06:15:00 PM UTC 2020 - -- We let the blockchain recover overnight Sep 16th, 2020 after reverting back to PoC v8, however, - early morning Sep 17th, the team noticed that we had ~1000 hotspots stuck at block `502499`. -- In order to address that, we started working on an immediate GA release `2020.09.17.0` with a new - blessed snapshot targeted at block height [503281](https://github.com/helium/miner/pull/515). - -### Solutions? - -- A relatively simple fix is to avoid walking the chain backwards altogether by attaching the - `poc_request_txn` block hash to the `poc_receipts_txn`, this would in theory be a constant time - lookup at transaction validation time. Please refer the following PRs for progress: - [helium/proto](https://github.com/helium/proto/pull/52), - [helium/blockchain-core](https://github.com/helium/blockchain-core/pull/622), - [helium/miner](https://github.com/helium/miner/pull/516). -- Due to the nature of blockchains, protocol buffers, and immutable ledgers, we cannot reactivate - PoC v9 with different and less problematic code. Instead, we will skip over PoC v9 altogther and - jump straight to PoC v10. -- Finally, we plan on accelerating setting up a testnet to catch such issues before they make it to - production. We look forward to engaging with the community to participate in the development of - this testnet. - -### Next Steps - -- Once the team has confirmed that the fixes indeed work as intended, we shall deploy a beta release - and apprise the community of eventual GA release. -- Current timeline is to activate PoC v10 on Monday, Sep 21st, 2020. diff --git a/devblog/2020-09-17-console-updates.mdx b/devblog/2020-09-17-console-updates.mdx deleted file mode 100644 index 11d9ed3a9..000000000 --- a/devblog/2020-09-17-console-updates.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -layout: post -title: Console Updates- Debug Pane, pause transfer, and internal monitoring -date: 2020-09-17 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Debug pane enhancements, ability to pause data transfer for devices and across organizations, and -tools for internal monitoring by Helium dev team. - - - -### Features and Updates - -- Updated Debug pane: information is easier to view, can be copied to clipboard or exported as json - file, and entries can be cleared. -- Provided ability to pause data transfer for a device or an Organization with on/off switches on - pages: Device, Device index, Labels, and Organizations. -- Added more front end metrics for internal monitoring by Helium dev team. -- Internal backend monitoring and metrics for Helium dev team. -- Fix custom decoders crashing (it will now retry to decode if crash is detected). -- Improve state channels handling. -- Updated to enforce a max payload for downlinks to adhere to LoRaWAN spec. - -### Fixes - -- Deployed a fix for the issue causing decoder functions to suddenly stop working. Decoders exist in - a "context", an isolated memory space in a v8 VM (see - [here](https://github.com/helium/erlang_v8)). A context will now be recreated if it fails and the - function restarted. -- Released a patch to update state channels and increase stability. -- Fixed an issue with TTN devices and Labels not appearing consistently. -- Addressed downlink payloads incorrectly displaying as empty in Debug window. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Ability to filter and sort tables. -- Adding MAC command information in event logs. -- Update MQTT integration to allow more flexibility. -- Include support for LoRaWAN adaptive data rate (ADR). -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-09-21-blockchain-poc-v10.mdx b/devblog/2020-09-21-blockchain-poc-v10.mdx deleted file mode 100644 index aed7637a1..000000000 --- a/devblog/2020-09-21-blockchain-poc-v10.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: post -title: Blockchain PoC v10 -date: 2020-09-21 15:17 -0700 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -The `2020.09.21.1` blockchain release adds support for `PoC v10`. - - - -With the release of `PoC v9`, the blockchain experienced a halt and subsequent block slow down, -please refer -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/09/17/blockchain-poc-v9-postmortem.html) -for further details. This release addresses the performance issues the team noticed with `PoC v9`. - -#### Proof-of-Coverage v10 - -`PoC v10` remains practically the same as `PoC v9` in principle except the addition of -`request_block_hash` in the `poc_receipts_txn` to allow fetching valid receipt and witness -information in an optimized manner. - -The proposed chain variable updates are: - -- `poc_version` from 8 to 10 -- `data_aggregation_version` from 1 to 2 - -Aditionally, this release bumps the blessed snapshot to height `509761`. - -#### Related PRs - -- _Add block hash to poc receipts_ - - [proto/52](https://github.com/helium/proto/pull/52) -- _Store block hash in poc receipts txn for poc v10_ - - [blockchain-core/622](https://github.com/helium/blockchain-core/pull/622) -- _Store request block hash in poc receipt_ - - [miner/516](https://github.com/helium/miner/pull/516) -- _Bump blessed snapshot to height 509761_ - - [miner/517](https://github.com/helium/miner/pull/517) - -### Plan - -We have been beta-ing `2020.09.21.1` since 9 AM PST on 22nd September, 2020 and will release it to -GA by 1 PM PST, 22nd September, 2020. The proposed chain variables will be activated separately on -Wednesday, 23rd September 2020. diff --git a/devblog/2020-09-29-blockchain-housekeeping-release.mdx b/devblog/2020-09-29-blockchain-housekeeping-release.mdx deleted file mode 100644 index 1f196999c..000000000 --- a/devblog/2020-09-29-blockchain-housekeeping-release.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -layout: post -title: Blockchain Housekeeping Release -date: 2020-09-29 18:03 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The `2020.09.30.1` release is a regular blockchain maintenance update. Notably, the team has added -support for providing witness validity information to Proof of Coverage receipts, fixed blockchain -snapshot determinism and updated state channel client to make device join accepts more robust. - - - -#### Witness Validation Visibility - -`blockchain-core` now provides visibility for Proof of Coverage witness validation. This would allow -network participants to better correlate their PoC mining rewards with `poc_receipts_txn` paths. -This is intended to be used by [blockchain-etl](https://github.com/helium/blockchain-etl) and the -API. Ultimately this data will be visible in explorer and the Helium mobile wallet. - -#### Snapshot Determinism Fixes - -Another minor change was made to make snapshot serialization more deterministic. While this would -not normally merit a mention, these serialization issues are making it less likely that any given -Hotspot will generate and store a correct snapshot, which has two effects that that a user might -notice: - -1. It makes it harder for the Consensus Group to generate a snapshot, because two-thirds of the - group needs to agree. This means that snapshots fail more often than they should and there are - fewer to choose from when it comes time to bless the latest. - -2. Since fewer Hotspots agree, it's less likely that any given Hotspot will agree about the snapshot - hash and store it. New Hotspots coming on to the network have to look around for longer to find a - snapshot. Currently, agreement seems to have fallen into two major groups covering around 75% of - all spots with a long tail of smaller groups. - -#### Device JoinAccept Fixes - -This release also addresses concerns related to client devices not being able to send join requests -to the console without repeated attempts. We updated the state channel client on the miner to -properly enqueue and dequeue packets once the router accepts an incoming packet offer from a -Hotspot. - -#### Blessed Snapshot Update - -Finally, this release bumps the blessed snapshot to height `522721` which will improve sync times of -newly onboarded Hotspots. - -#### Related PRs - -- _Fix snapshot diffs for serialization changes_ - - [blockchain-core/624](https://github.com/helium/blockchain-core/pull/624) -- _Ensure oracle prices are recalculated while absorbing snapshot_ - - [blockchain-core/625](https://github.com/helium/blockchain-core/pull/625) -- _Expose snapshot_height from blockchain_ - - [blockchain-core/626](https://github.com/helium/blockchain-core/pull/626) -- _Add request_block_hash to receipts json_ - - [blockchain-core/629](https://github.com/helium/blockchain-core/pull/629) -- _Add is_valid entries for poc_receipts/poc_witnesses_ - - [blockchain-core/632](https://github.com/helium/blockchain-core/pull/632) -- _Fix snapshot deserialize upgrades for older snaps_ - - [blockchain-core/634](https://github.com/helium/blockchain-core/pull/634) -- _Cleanup poc receipt txn logging noise_ - - [blockchain-core/636](https://github.com/helium/blockchain-core/pull/636) -- _Enqueue packet when sending offer on banner recv_ - - [blockchain-core/637](https://github.com/helium/blockchain-core/pull/637) -- _Dynamically select spreading factor for PoC packets_ - - [miner/521](https://github.com/helium/miner/pull/521) -- _Update blockchain-core and snapshot_ - - [miner/524](https://github.com/helium/miner/pull/524) -- _Bump core for join accept fix_ - - [miner/525](https://github.com/helium/miner/pull/525) - -### Plan - -We will begin beta-testing `2020.09.30.1` around 4 PM PST on 30th September, 2020 and plan to -release it to GA by 11 AM PST, 1st October, 2020. diff --git a/devblog/2020-10-01-console-updates.mdx b/devblog/2020-10-01-console-updates.mdx deleted file mode 100644 index de1bf0394..000000000 --- a/devblog/2020-10-01-console-updates.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: post -title: Console Updates- MQTT Integration overhaul, UI enhancements -date: 2020-10-01 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The team has overhauled MQTT integration to make topic composition more flexible and added templates -to use for device and org identifiers. - - - -Existing MQTT Integrations should continue to work fine. However, should you encounter any issues -related to data transfer due to MQTT integration, simply update the topics on those existing -integrations. - -### Features and Updates - -- MQTT topic composition and UI update: In addition, to interface updates to make it more similar to - other integrations, we have also overhauled the topic composition, making it more flexible, and - included templating which provides an easy way to insert device ID, and key information should you - want to include that in your topic structure. -- Topics should follow MQTT topic rules. Templates can be provided using \{\{template}} format. - Valid template tags are: `device_id`, `device_eui`, `app_eui`, and `organization_id`. -- During TTN import provided the ability to delete application handlers to avoid rejoin attempts - after import. -- UI enhancements: - - Debug mode: moved Packet Information to top and expanded by default. - - Updated retransmission procedure to align with LoRaWAN spec. - - Added ability to delete devices on specific Device page. - - Added confirmation for Organization delete even if no devices. - -### Fixes - -- Import TTN devices consistently appears in the Console device list. -- Resolved an issue with search to ensure results are clear. -- Fcnt in Debug mode aligns with Console event information. -- New data in the event log consistently appears. -- Addressed an HTTPS cert issue that was causing issues with certain HTTP endpoint integrations. -- A device no longer requires two join attempts before a join accept is downlinked if a device does - not already have an established session. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Include support for LoRaWAN adaptive data rate (ADR). -- UI enhancements for sorting and filtering tables. -- Updates to event logs, more information, ability to export json format. -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-10-01-spreading-factor-changes-poc.mdx b/devblog/2020-10-01-spreading-factor-changes-poc.mdx deleted file mode 100644 index 68d1cb9df..000000000 --- a/devblog/2020-10-01-spreading-factor-changes-poc.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -layout: post -title: Spreading factor changes and how they may affect Proof of Coverage -date: 2020-10-02 14:00 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -In order to comply with local North American and European regulations, we added an undocumented -update to PoC to correct the spreading factor used by PoC packets. - - - -This change was deployed along with a recent maintenance update, but was not communicated. We're -sorry about the late communication, but given the importance of complying with regulations we wanted -to deploy this as quickly as possible. - -**Why was this change made?** - -Thanks to testing and verification of members of the community, we realized that PoC packets were -being sent with the longest range possible in all cases. Instead, we needed to set the spreading -factor based on the size of the packet (which is directly correlated with the number of Hotspots in -the challenge path). - -**What is spreading factor and why does it matter?** - -There are resources online to learn more about data rate and spreading factor if you want to dive -into the specifics of how LoRa works, but here's a high level overview. - -LoRa uses what is known as a “chirp” protocol and spreading factors are the duration of the "chirp". -Typically you're looking at a range of SF7 to SF12 where the 7 is the shortest time on air. Each -step up doubles the time on air to transmit the same amount of data and increases the range. Due to -local restrictions, we are limited by max payload sizes to certain spreading factors, usually SF8 -and SF9 for most packets. - -**How does this affect currently issued PoCs?** - -Because we are now dynamically adjusting spreading factor based on packet size, PoC paths with a -larger number of Hotspots and over longer distances may not complete. There are a variety of things -that we could have considered including forcing all witness lists to reset over a shorter interval -temporarily but we decided not to do that since it would create other disruptions. - -**Does this impact my earnings?** - -Possibly. This change can impact earnings for some Hotspots if the newer spreading factors result in -existing witnesses being out of range. If the Hotspot isn't able to complete a PoC challenge with a -witness that it was able to reach earlier, the failed challenge will not earn HNT. - -**Why do my earnings fluctuate?** - -There are a lot of factors to take into consideration here given that the system that generates PoC -based rewards is not static. Hotspots come online and go offline and anything that could temporarily -(or permanently) affect RF and/or the internet connectivity of the Hotspot can affect the success of -a PoC challenge. - -This is why we typically advise looking at PoC over a longer period of time (weekly or longer) with -respect to HNT rewards. Rewards over short periods, like days or hours, can fluctuate 100s of -percentage points due to the inherently random nature of the system and RF performance. - -**What can I change to fix my witness list now?** - -You shouldn't have to change anything proactively. Witness lists update automatically (on average, -every two weeks). You should be able to verify this using the API. You can certainly trigger an -update to this manually if you want via re-asserting your location, but this may incur a Data Credit -cost. diff --git a/devblog/2020-10-08-blockchain-state-channel-overpayment-fix-release.mdx b/devblog/2020-10-08-blockchain-state-channel-overpayment-fix-release.mdx deleted file mode 100644 index 94d123855..000000000 --- a/devblog/2020-10-08-blockchain-state-channel-overpayment-fix-release.mdx +++ /dev/null @@ -1,88 +0,0 @@ ---- -layout: post -title: Blockchain State Channel Overpayment Fix Release -date: 2020-10-08 15:09 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The primary objective of the `2020.10.08.0` release is to address the state channel overpayment -exploit. The fix is guarded behind `reward_version` chain variable which would be incremented to `4` -to activate the fix. We intend to activate this chain variable after verifying this release. - - - -#### Addressing the State Channel Overpayment Exploit - -When a `state_channel_close` transaction is in a `dispute` state, Data Credit (DC) rewards were -always paid out 1:1. Prior to this release, it was not considered that a state channel could have -closed with a total DC count higher than the amount of DC available to the state channel. - -Furthermore, since the router always opens state channels with an "overcommit" factor (set to 2 on -the blockchain as a chain variable), router has an incentive to recover the overcommit amount and -pay the client Hotspots involved in the state channel. - -To address this, after we set `reward_version` to `4`, we would fully remove the overcommitted DC -amount and only pay out the participants of the state channel proportionally after truncating any -large participant payouts to the amount of DC in the state channel. - -#### Prep for Proof-of-Coverage Changes - -For those following [Helium Improvement Proposals](https://github.com/helium/hip), there are a few -proposals on reworking the proof-of-coverage mechanism. The team has removed the artificial max -limit of potential witnesses a PoC packet may have and made it an on-chain variable, this change -would allow us to gather more witnesses per PoC hop. The proposed chain variable is: -`poc_per_hop_max_witnesses`, and is currently set at a default of `5` to preserve existing behavior. - -#### Several Test Changes and API related Changes - -- Updated miner and blockchain-core tests to be more reliable and significantly reduced test - runtime. - -- Addressed a few bugs related to the exported json data for poc receipt transactions. - -- Fixed a bug in ledger fingerprinting. - -- Added EU868 specific datarates for PoC packets. - -- Altered block catchup time calculation to produce more consistently spaced blocks and faster - emissions rate catchup. - -#### Blessed Snapshot Update - -Finally, this release bumps the blessed snapshot to height `535681` which will improve sync times of -newly onboarded Hotspots. - -#### Related PRs - -- _Move purchase to a call_ - - [blockchain-core/638](https://github.com/helium/blockchain-core/pull/638) -- _Ignore static in ledger fingerprint_ - - [blockchain-core/639](https://github.com/helium/blockchain-core/pull/639) -- _Fix poc path reversal_ - - [blockchain-core/640](https://github.com/helium/blockchain-core/pull/640) -- _Introudce poc_per_hop_max_witnesses chain variable_ - - [blockchain-core/641](https://github.com/helium/blockchain-core/pull/641) -- _Fix nonce state-keeping_ - - [blockchain-core/642](https://github.com/helium/blockchain-core/pull/642) -- _When closing a disputed state channel slash overcommit & normalize payouts_ - - [blockchain-core/643](https://github.com/helium/blockchain-core/pull/643) -- _Datarate list fixups_ - - [blockchain-core/644](https://github.com/helium/blockchain-core/pull/644) -- _Add EU868 specific datarates for PoC packets_ - - [miner/527](https://github.com/helium/miner/pull/527) -- _Add support for poc_per_hop_max_witnesses_ - - [miner/528](https://github.com/helium/miner/pull/528) -- _Substantial state channel test rework_ - - [miner/529](https://github.com/helium/miner/pull/529) -- _Reduce the time period, be more aggresive about catchup_ - - [miner/530](https://github.com/helium/miner/pull/530) -- _Test slashing on overpaid state channel_ - - [miner/533](https://github.com/helium/miner/pull/533) -- _Bump blessed snapshot_ - - [miner/534](https://github.com/helium/miner/pull/534) - -### Plan - -We will begin beta-testing `2020.10.08.0` around 6 PM PST on 8th October, 2020 and plan to release -it to GA by 2 PM PST, 9th October, 2020. diff --git a/devblog/2020-10-12-blockchain-datacredit-reward-and-joinaccept-fixes.mdx b/devblog/2020-10-12-blockchain-datacredit-reward-and-joinaccept-fixes.mdx deleted file mode 100644 index 8ed031e1f..000000000 --- a/devblog/2020-10-12-blockchain-datacredit-reward-and-joinaccept-fixes.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: post -title: Blockchain DataCredit Reward and JoinAccept Fixes -date: 2020-10-12 17:08 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The primary objective of the `2020.10.12.1` release is to address the missing data credit rewards -for `blockchain_txn_state_close_v1` transaction. This release also fixes inconsistent `JoinAccept` -for packet transfers. - - - -#### Addressing the Missing DataCredit Rewards - -When a `blockchain_txn_state_channel_close_v1` transaction appears between the next epoch start -(next election block for new consensus group) and the grace period of the state channel close (as -defined in the corresponding open state channel transaction), there's a possibility that the data -credit rewards for hotspots involved in packet transfer for the duration of the state channel would -not appear in the next epoch. The team has addressed this bug and to preserve backwards -compatability guarded the change behind chain variable `reward_version`. - -Once `reward_version` is set to `5` the fix will come into effect and data credit rewards will -appropriately appear in the corresponding epoch change. - -#### Addressing Inconsistent JoinAccept for Packet Transfer - -The team has addressed reported concerns for inconsistent `JoinAccept` for packet transfers as -reported by network users. This was caused due a regression in refactoring old code. We expect -`JoinAccept` to be more consistent once `2020.10.12.1` release goes GA. Note, this does _not_ -require a chain variable to trigger. - -#### Blessed Snapshot Update - -Finally, this release bumps the blessed snapshot to height `540721` which will improve sync times of -newly onboarded Hotspots. - -#### Related PRs - -- _Calculate DC rewards in previous epoch grace blocks_ - - [blockchain-core/627](https://github.com/helium/blockchain-core/pull/627) -- _Fix lost state when enqueueing packets_ - - [blockchain-core/646](https://github.com/helium/blockchain-core/pull/646) -- _Test that state channel closes within grace blocks of an epoch end are rewarded_ - - [miner/523](https://github.com/helium/miner/pull/523) -- _Update blessed snapshot to 540721_ - - [miner/535](https://github.com/helium/miner/pull/535) - -### Plan - -We have begun beta-testing `2020.10.12.1` around 6:30 PM PST on 12th October, 2020 and plan to -release it to GA by 3 PM PST, 13th October, 2020. And we will activate `reward_vesion=5` on Monday, -19th October, 2020. diff --git a/devblog/2020-10-15-console-updates.mdx b/devblog/2020-10-15-console-updates.mdx deleted file mode 100644 index 60ce20a50..000000000 --- a/devblog/2020-10-15-console-updates.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: post -title: Console Updates- Enhancements for large deployments -date: 2020-10-15 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This release includes enhancements to help manage large numbers of devices including ability to sort -and customize the device table, and making group import more flexible. In addition, a number of -backend fixes were made including improving join request reliability, making integrations more -robust, and resolving an arbitrage issue. - - - -### Features and Updates - -- Organization and user names permanently displayed. -- Ability to: - - Sort list of devices, on Device Index and Label Show pages - - Customize which table columns appear on the Device Index page. -- Can export device events in JSON format. -- Group Import, required and field names for columns no longer case sensitive: `DevEUI`, `AppEUI`, - `AppKey`, `Name`, optional: `LabelID`. -- Email notification when an admin deletes an Organization. -- For security purposes the ability to mask important keys on Console. - -### Fixes - -- Provided a patch to better handle reconnects for integrations. -- Fixed an issue that allowed Hotspots to earn HNT for sending device data without spending Data - Credits using the pause device feature. -- Improved reliability of join requests. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Structuring payloads using templating. -- Include support for LoRaWAN adaptive data rate (ADR). -- Adding more information to event logs -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-10-16-app-version-250.mdx b/devblog/2020-10-16-app-version-250.mdx deleted file mode 100644 index f58fc0c4b..000000000 --- a/devblog/2020-10-16-app-version-250.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: post -title: App Version 2.5.0 -date: 2020-10-16 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## View Witness List - -In this new update, we've brought in a feature called "View Witnesses". This new feature can be -found on your Hotspot's page. Simply toggle the View Witness to see all the Hotspots that your -Hotspot has seen and interacted with! - - - -This Witness List can vary over time as new Hotspots come online, Hotspots move, antennas get -upgraded, and as the list gets refeshed every 2 weeks. - -This list serves as the basis of how challenges involving your Hotspot are constructed. - -Not seeing any witnesses? If you're a new Hotspot, witnesses can take up to a week to fully -populate. Otherwise, check that the antenna is affixed properly, that the Hotspot is situated next -to a window, and it is unobstructed by objects. Looking to upgrade your antenna to improve the -range? Head into our Discord Server and find the #Antennas channel to learn more about what works -best for your setup. - -If you're a lonely Hotspot, you won't have any Hotspots in the witness list. New Hotspots are coming -online everyday around the world so this shouldn't last long! - -## Changes in language used in Challenges - -In an effort to simplify and understand Challenges in the mobile app, we've removed terms like -receipts to help our users understand why a hop in a path passed, and why it wouldn't. - -In the simplest sense, a Hotspot can pass a challenge in 2 ways: - -1. If a valid witness hears the challenge being transmitted to the next hop -2. If the Hotspot in the next hop confirms it heard the challenge - -To consider a witness as valid depends on several factors. This includes distance, RSSI, and FSPL. -In its simplest terms, if the RSSI and FSPL fall within an acceptable range of normal, and the -Hotspot is more than 300 meters away, then it is a valid witness. To read more and understand what -makes a witness valid, our Discord server is a great place to engage. Check out the Technical -> -#poc-discussion channel. - -## RAK Hotspot Miner - -In preparation of RAK Hotspot Miners coming online, we've changed our Hotspot onboarding flow to -include the RAK Hotspots. Keep in mind that RAK Hotspot Miners do not have a bluetooth pairing -button. In order to pair with the RAK Hotspot Miner, you will need to unplug the Hotspot, plug it -back in, wait about a minute for the Miner to boot up, then scan. diff --git a/devblog/2020-10-19-blockchain-maintenance-release.mdx b/devblog/2020-10-19-blockchain-maintenance-release.mdx deleted file mode 100644 index c8569aff0..000000000 --- a/devblog/2020-10-19-blockchain-maintenance-release.mdx +++ /dev/null @@ -1,108 +0,0 @@ ---- -layout: post -title: Blockchain Maintenance Release -date: 2020-10-19 14:36 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -**Update: The current release candidate primed for GA is `2020.10.23.0` which fixes minor state -channel server side issues. We will keep this post updated with more details.** - - - -~~Note: The `2020.10.21.0` has been held prior to GA while we continue to work through small issues -that were found during beta testing. We will update this post with more details.~~ - -The ~~`2020.10.19.0`~~ ~~`2020.10.20.0`~~ ~~`2020.10.21.0`~~ `2020.10.23.0` release is a blockchain -maintenance release. Notably the team has fixed an issue where miners running in Docker were getting -stuck during elections, finalized support for multisig, and improved client side packet transfer -performance for state channels. - -#### Highlights and Related PRs - -- Handle unsupported regions for miner lora module. - [miner#540](https://github.com/helium/miner/pull/540) -- Added asynchronous election completion. [miner#537](https://github.com/helium/miner/pull/537) -- Fixed divide by zero error for calculating next block time. - [miner#536](https://github.com/helium/miner/pull/536) -- Use bloom filter to improve packet times. - [blockchain-core#602](https://github.com/helium/blockchain-core/pull/602) -- Fixed bad match error on state channel garbage collection. - [blockchain-core#651](https://github.com/helium/blockchain-core/pull/651) -- Filter downed packet streams on client side state channels. - [blockchain-core#654](https://github.com/helium/blockchain-core/pull/654) -- Added timeouts for outbound packet dials. - [blockchain-core#653](https://github.com/helium/blockchain-core/pull/653) -- Refactored voting counts for multisig. - [blockchain-core#650](https://github.com/helium/blockchain-core/pull/650) -- Added safe defaults to `reward_version` for state channel garbage collection. - [blockchain-core#647](https://github.com/helium/blockchain-core/pull/647) -- Fixed lost state when enqueuing packets on client side state channels. - [blockchain-core#647](https://github.com/helium/blockchain-core/pull/646) -- Added ability to fetch snapshot from the network. - [blockchain-core#648](https://github.com/helium/blockchain-core/pull/648) - -#### Blessed Snapshot Update - -Finally, this release bumps the blessed snapshot to height `549361` which will improve sync times of -newly onboarded Hotspots. - -### Release Update: New tag `2020.10.20.0` October 20th, 2020 - -As a result of beta testing overnight, the team identified a few more regression induced bugs. We -have addressed those bugs and have updated the tag from `2020.10.19.0` to `2020.10.20.0`. - -Below is a short summary of the bug fixes and their related PRs - -- Switch downstream `erbloom` depenency with an updated `rebar.config` file. - [blockchain-core#657](https://github.com/helium/blockchain-core/pull/657) -- Add miner side support for invalid transaction log messages. - [miner#432](https://github.com/helium/miner/pull/432) -- Update libp2p for downstream `relcast` bug fixes. - [libp2p#301](https://github.com/helium/erlang-libp2p/pull/301) - -### Release Update: New tag `2020.10.21.0` October 21st, 2020 - -The team has added support for LoRaWAN rx2 window and squashed a few more bugs in the new release -tagged `2020.10.21.0`. Below is a list of related PRs: - -- Add support for rx2 window. - [blockchain-core#656](https://github.com/helium/blockchain-core/pull/656) -- Fix state channel test suite. - [blockchain-core#652](https://github.com/helium/blockchain-core/pull/652) -- Fix txn validation printing. - [blockchain-core#660](https://github.com/helium/blockchain-core/pull/660) -- Add miner side support for rx2 window. [miner#542](https://github.com/helium/miner/pull/542) -- Fix state channel tests for miner. [miner#543](https://github.com/helium/miner/pull/543) - -### Release Update: New tag `2020.10.23.0` October 23rd, 2020 - -The team noticed additional issues with state channel server side handling while beta testing the -previous release candidate, we have fixed those in `2020.10.23.0` release candidate. Additionally we -have updated the blessed snapshot block to `555121` and updated the Dockerfile for ARM images. -Related PRs: - -- Don't close state channel on overspend. - [blockchain-core#664](https://github.com/helium/blockchain-core/pull/664) -- Reapply nonce fix for correct state keeping sc server side. - [blockchain-core#663](https://github.com/helium/blockchain-core/pull/663) -- Update blockchain-core and snapshot block. [miner-548](https://github.com/helium/miner/pull/548) -- Add rust and cargo for ARM docker image. [miner-546](https://github.com/helium/miner/pull/546) - -### Plan - -As you can note in our release updates, the team continues to iterate on a stable release version we -were comfortable sending to GA. We are finding important issues through beta testing. Ultimately we -decided to scrap three release candidates but we have documented the plan below for posterity. - -We will likely work towards finding a solution and initiate testing tomorrow and over the weekend. - -- ~~We have begun beta-testing `2020.10.19.0` around 2:30 PM PST on 19th October, 2020 and plan to - release it to GA by 3 PM PST, 20th October, 2020.~~ -- ~~We will begin beta-testing `2020.10.20.0` around 2:30 PM PST, October 20th, 2020 and keep the - community apprised of any further changes.~~ -- ~~We have begun beta-testing `2020.10.21.0` around 2:30 PM PST, October 21st, 2020 and plan to GA - by October 22nd, 2020 around 3PM PST.~~ -- We have begun beta-testing `2020.10.23.0` around 2:30 PM PST, October 23rd, 2020 and plan to GA on - Monday, October 26th, 2020 around 11AM PST. diff --git a/devblog/2020-10-27-blockchain-fixes-and-chain-halt-postmortem.mdx b/devblog/2020-10-27-blockchain-fixes-and-chain-halt-postmortem.mdx deleted file mode 100644 index 8f77bfb3f..000000000 --- a/devblog/2020-10-27-blockchain-fixes-and-chain-halt-postmortem.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: post -title: Blockchain Fixes and Chain Halt Postmortem -date: 2020-10-27 17:27 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The `2020.10.27.0` blockchain release contains some critical fixes specifically meant to address the -blockchain halt observed on Monday, October 26th, 2020. Please read on for a detailed breakdown. - - - -#### October 26th, 2020: Chain halt postmortem - -- _11AM PST_: Miner tag `2020.10.23.0` is released to GA -- _4:30PM PST_: The team notices chain stall and begins investigation -- _5:00PM PST_: Root cause identified as an unhandled `EXIT` error message caused while trying to - create a block containing a stale poc receipt transaction. Patch deployed to the consensus group - to regain block production. -- _5:30PM PST_: After having internal discussions, the team decided to roll back to previous GA tag - `2020.10.12.1`. It was not worth it to rush a release, especially knowing that the bug was largely - harmless and the previous GA had been running solidly. -- _6:00PM PST_: All hotspots on the network downgraded back to `2020.10.12.1`. By this time, network - gossip caught up and block production resumed normally. - -#### Highlights and Related PRs - -- Better transaction error handling and testing. - [blockchain-core#665](https://github.com/helium/blockchain-core/pull/665) -- Enhance client side state channel validation. - [blockchain-core#667](https://github.com/helium/blockchain-core/pull/667) -- Fix state channel tests. [blockchain-core#668](https://github.com/helium/blockchain-core/pull/668) -- Add EU868 region for Ukraine. [miner#550](https://github.com/helium/miner/pull/550) -- Fix argument order for LoRaWAN rx2 window. [miner#551](https://github.com/helium/miner/pull/551) -- Update blockchain-core and snapshot block to `560881`. - [miner#552](https://github.com/helium/miner/pull/552) - -#### Plan - -We have begun beta-testing `2020.10.27.0` around 5:15 PM PST, October 27th, 2020 and plan to GA on -Thursday, October 29th, 2020 around 11AM PST. diff --git a/devblog/2020-10-29-console-updates.mdx b/devblog/2020-10-29-console-updates.mdx deleted file mode 100644 index 2295f9213..000000000 --- a/devblog/2020-10-29-console-updates.mdx +++ /dev/null @@ -1,94 +0,0 @@ ---- -layout: post -title: Console Updates- Second rx window, custom JSON messages -date: 2020-10-29 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, vihu] ---- - -In this release we provide support for a second receive window, a number of UI improvements, as well -as a beta feature that allows users customize JSON messages sent to Integrations. - - - -### Features and Updates - -- Included a second receive window for devices aligned with LoRaWAN spec. -- Increased Data Credit visibility: total for Organization prominently displayed, as well as on - specific device page. -- Group import capability supports adding an additional labelID column in the CSV file for imports. -- Labels can be quickly swapped from one to another from the quick action menu. For example, if - Labels were defined for location (SF, LA), and a device moved from SF to LA, users could easily - swap these location Labels for devices. This same feature could be used to define different - customers, POC vs. production devices, etc. -- Included pause/resume device transfer on Device index page quick action menu. -- Significantly improved uplink speed by caching devices instead of needing to query DB each time. -- Beta - JSON Message Templates: provide users the ability to customize the JSON message sent to - HTTP, MQTT or AWS IoT Integrations. This is a beta feature and we expect only users familiar with - templating to try this feature. More info about the logic-less Mustache templating we're using - [here](https://mustache.github.io/mustache.5.html). - -```json -{ -// Browan example - {% raw %}{{#decoded}}{{#payload}} {% endraw %} - "battery": {% raw %}"{{battery_percent}}"{% endraw %}, - "lat": {% raw %}"{{latitude}}"{% endraw %}, - "long": {% raw %}"{{longitude}},{{payload}}{{decoded}}"{% endraw %} - "device_id": {% raw %}"{id}}"{% endraw %} -} -``` - -- Current list of template of supported keys and values: - -```json -{ - "id": "device_uuid", - "name": "device_name", - "dev_eui": "dev_eui", - "app_eui": "app_eui", - "metadata": {}, - "fcnt": 2, - "reported_at": 123, - "payload": "base64 encoded payload", - // ONLY if payload is decoded - "decoded": { - "status": "success | error", - "error": "...", - "payload": "..." - }, - "port": 1, - "devaddr": "devaddr", - "hotspots": [ - { - "id": "hotspot_id", - "name": "hotspot name", - "reported_at": 123, - "status": "success | error", - "rssi": -30, - "snr": 0.2, - "spreading": "SF9BW125", - "frequency": 923.3, - "channel": 12, - "lat": 37.00001962582851, - "long": -120.9000053210367 - } - ], - "dc": { - "balance": 3000, - "nonce": 2 - } -} -``` - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Add manager role: this would be an operational role that is similar to an Administrator without - certain capabilities including the ability to manage Data Credits, users, or Organizations. -- Provide email alerting for a number of conditions related to devices and integrations. -- Include support for LoRaWAN adaptive data rate (ADR). -- Providing more information related to LoRaWAN commands in the Event log. -- Release Cargo asset tracking eval tool as open source. -- Release Console and its backend network server and blockchain components (Router) as open source diff --git a/devblog/2020-10-31-emergency-release-additional-rak-hotspot-fix.mdx b/devblog/2020-10-31-emergency-release-additional-rak-hotspot-fix.mdx deleted file mode 100644 index b01852957..000000000 --- a/devblog/2020-10-31-emergency-release-additional-rak-hotspot-fix.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: 'Emergency Release: Additional RAK Hotspot Fix' -date: 2020-10-31 19:45 -0700 -hide_table_of_contents: true -authors: [abhay, madninja] ---- - -The team has prepared a second emergency weekend release, tagged `2020.10.31.1`. This release -addresses a software issue that affects _only_ a subset of the RAK Hotspot Miners, which were unable -to witness challenges or build witness lists. - - - -RAK Hotspot Miner owners who purchased from Cal-Chip with a Rev 1.2 Rasberry Pi 4 board would have -noticed that there was no improvement with the prior emergency release today (tag `2020.10.31.0`). -During our initial testing with the RAK Hotspot Miner, we identified one revision of this board but -did not expect this new one before they were released to the public. We believe that this fix will -at least handle the new revision for the weekend and we'll look at a more holistic change over the -next week. - -**Helium Hotspots are not affected by this issue.** - -Be advised that there's still a possibility that the RAK Hotspot Miners may fail to update to the -new release `2020.10.31.1` for the same boot pin misconfiguration as described in the -[prior post](https://engineering.helium.comhttps://docs.helium.com/blog/2020/10/31/emergency-release-rak-hotspot-fix.html) -and may require an power cycle after 30 minutes of operating with the new firmware. - -### Plan - -We are currently beta testing `2020.10.31.1` and we will release to GA imminently. Current ETA for -GA is 9:00 PM PST, October 31st 2020. diff --git a/devblog/2020-10-31-emergency-release-rak-hotspot-fix.mdx b/devblog/2020-10-31-emergency-release-rak-hotspot-fix.mdx deleted file mode 100644 index f45db2b55..000000000 --- a/devblog/2020-10-31-emergency-release-rak-hotspot-fix.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: 'Emergency Release: RAK Hotspot Fix' -date: 2020-10-31 09:22 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The team has prepared an emergency weekend release, tagged `2020.10.31.0`. This release addresses a -software issue that affects _only_ the RAK Hotspot Miner where they were unable to witness -challenges or build witness lists. - - - -For folks who have a RAK Hotspot Miner purchased from Cal-Chip, they would have noticed that their -Hotspot has no witnesses but there are potentially valid hotspots in their area. On the bright side, -the RAK Hotspot Miners have been issuing challenges and maintaining blockchain sync. - -**Helium Hotspots are not affected by this issue.** - -### Advisory for RAK Hotspot Miner Owners - -Despite this fix, there's a non-zero chance that some RAK Hotspot Miners may fail to update to the -new release `2020.10.31.0`. If an operator notices no Proof-of-Coverage Witness or Challengee -Participant activity, we request them to manually power cycle their Hotspot after waiting ~30 -minutes. The failure to update to the GA seems to happen due to mis-configuration of boot pins on -the RAK Hotspot Miners, the team is actively investigating this and will prepare another release mid -next week to address whether we can fix this issue in software. - -### Plan - -We are currently beta testing `2020.10.31.0` and we will release to GA imminently. Current ETA for -GA is 11:30 AM PST, October 31st 2020. diff --git a/devblog/2020-11-06-blockchain-release-rak-miner-updates.mdx b/devblog/2020-11-06-blockchain-release-rak-miner-updates.mdx deleted file mode 100644 index 7f630f265..000000000 --- a/devblog/2020-11-06-blockchain-release-rak-miner-updates.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: post -title: 'RAK Hotspot Miner: Firmware Update Issues' -date: 2020-11-06 12:13 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The team has noticed issues where a small number of RAK Hotspot Miners are not applying firmware -updates containing bug fixes. - - - -After investigation, we found that these Miners were booting from a secondary, fallback image that -is used as backup on the device. The Miner is fooled into thinking a reset button was pressed which -doesn't exist on the RAK Hotspot Miner. The code is in place to support Helium Hotspots. - -Because the RAK Hotspot Miners continue to think the "reset button" is being pushed, they will -always boot from their older, fallback image. - -**This issue only affects a very small number of RAK Hotspot Miners** - -#### Identifying the Problem - -- Is it a Helium Hotspot? -> If yes, you do not have the issue -- Is it actively mining? -> If yes, you do not have the issue -- Does it have the latest firmware `2020.10.31.1`? -> If yes, you do not have the issue - -If you find that you do not have the latest firmware, unplug it from power, wait ~30 minutes, and -plug it back in. Then check if it has the latest firmware. If it doesn’t update, you have an -affected unit. - -#### Interim Solution - -Since we know OTA updates continue to be applied to the primary image, the fix is to copy the -primary image to the fallback image, effectively making the image the same. This allows the RAK -Hotspot Miners to boot the fallback image which is the latest version. - -#### Permanent Solution - -The permanent solution requires two steps: - -1. An OTA with a permanent fix that will be applied to the primary image. -2. Manually copying the primary image to the fallback image and reboot. - -Once rebooted, the RAK Hotspot miner will download and apply new firmware updates to both locations, -so there is no difference between locations. - -### Plan - -The short term fix can be applied at any time. If your RAK Hotspot Miner does not have the latest -update `2020.10.31.1`, please contact support@helium.com. You can find out by running a diagnostic -report on the Miner. - -The permanent fix needs additional testing. The plan is to beta the next firmware on Tuesday, -November 10th, 2020 with a scheduled GA on Wednesday, November 11th, 2020. diff --git a/devblog/2020-11-11-app-version-261.mdx b/devblog/2020-11-11-app-version-261.mdx deleted file mode 100644 index 799e7c72e..000000000 --- a/devblog/2020-11-11-app-version-261.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: post -title: App Version 2.6.1 -date: 2020-11-11 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features and Enhancements - -## Send Max HNT - -In this new update, we've made it easier for anyone to send the full amount of HNT in their wallet. -You no longer have to worry about calculating the transaction fee. - - - -## Support for other transaction types - -Security Tokens transactions and mining rewards are now supported. - -# Performance Fixes - -- Update to React Native 63 -- Update to Android Target Version 29 - -# Security Fixes - -## Android PIN Bypass - -A Helium Discord community member alerted us of a change in behaviour in the Android mobile app -where a bad actor can access the account screen, completely bypassing the PIN screen if auto-rotate -is enabled in their phone settings. This is a security vulnerability and can allow bad actors to -access your wallet and funds. - -**We strongly recommend ALL Android app users update to app v2.6.1.** - -Special thanks to @Weelecht for discovering this vulnerability. - -# Bug Fixes - -## DC Display Amount - -We now show the correct amount of Data Credits generated when burning HNT. diff --git a/devblog/2020-11-11-blockchain-release-rak-hotspot-miner-ota-fix.mdx b/devblog/2020-11-11-blockchain-release-rak-hotspot-miner-ota-fix.mdx deleted file mode 100644 index 4d36b5b27..000000000 --- a/devblog/2020-11-11-blockchain-release-rak-hotspot-miner-ota-fix.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: RAK Hotspot Miner OTA Fix' -date: 2020-11-11 10:11 -0800 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -The team has prepared a new blockchain chain release tagged `2020.11.10.0` addressing a key issue -where RAK Hotspot Miners would not properly update to new firmware OTAs. - - - -We have described the issue in depth -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/11/06/blockchain-release-rak-miner-updates.html), -this release aims to fix that. RAK Hotspot Miner owners will now be able to seamlessly update to new -firmwares as they come along. - -Furthermore, we have updated the snapshot block to `583201` to allow newly onboarded hotspots to -sync faster to the current blockchain head block. - -### Plan - -We have been beta testing `2020.11.10.0` since November 10th, 2020 and will release to GA -imminently. Current ETA for GA is 12:00 PM PST, November 11th 2020. diff --git a/devblog/2020-11-12-console-updates-1.3.5.mdx b/devblog/2020-11-12-console-updates-1.3.5.mdx deleted file mode 100644 index f00e3c26a..000000000 --- a/devblog/2020-11-12-console-updates-1.3.5.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -layout: post -title: Console Updates- Manager role, open source Cargo -date: 2020-11-12 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This release includes a new Manager user role, and other usability updates as well the Cargo -tracking application was released as open source. - - - -### Features and Updates - -- Add Manager user role: an operational role similar to an Administrator without certain - capabilities including the ability to manage Data Credits, users, or Organizations. -- Released Cargo asset tracking eval tool as open source - [here](https://github.com/helium/cargo-elixir). -- Ability to switch Organizations from the main header menu. -- Updated UI to provide a smoother navigation among pages. -- Mapped Console ver. number to Engineering Blog release notes. - -### Fixes - -- API fix: updates happen in real time for Integrations similar to Console UI. -- Updated Console so reloading browser no longer displays inaccurate Hotspots signal details. -- Addressed an issue related to labels that caused functions to stop working. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Add a pre-built integration for Adafruit IO. -- Console custom notifications: provide email notifications for a number of conditions related to - devices and integrations. -- Provide the ability to pay for additional packets for redundancy and location triangulation - purposes. -- Include support for LoRaWAN adaptive data rate (ADR). -- Provide more information related to LoRaWAN commands in the Event log. -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-11-18-blockchain-release-feature-updates.mdx b/devblog/2020-11-18-blockchain-release-feature-updates.mdx deleted file mode 100644 index f2dc8f46d..000000000 --- a/devblog/2020-11-18-blockchain-release-feature-updates.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Feature Updates' -date: 2020-11-18 12:20 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The team has been busy working on a new blockchain chain release tagged `2020.11.17.0`. This release -contains a few new features: - - - -| Feature | PRs | HIP | -| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -| Transfer hotspot | [blockchain-core#659](https://github.com/helium/blockchain-core/pull/659), [miner#555](https://github.com/helium/miner/pull/555) | [HIP13](https://github.com/helium/HIP/blob/master/0013-transfer-hotspot.md) | -| Remove score from consensus group | [blockchain-core#676](https://github.com/helium/blockchain-core/pull/676), [miner#561](https://github.com/helium/miner/pull/561) | [HIP16](https://github.com/helium/HIP/blob/master/0016-random-consensus-group-election.md) | -| Beaconing Rewards | [blockchain-core#662](https://github.com/helium/blockchain-core/pull/662) | [HIP15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md) | - -**NOTE: Each of the above features will remain dormant until we activate their corresponding chain -variables. This release is in preparation for the support for the above features.** - -We have also updated the snapshot block to `591841` to allow newly onboarded hotspots to sync faster -to the current blockchain head block. - -### Chain Variable Activation Schedule - -The team has settled on the below chain variable activation schedule for the features mentioned -above. We will keep the community apprised if this changes. - -| Feature | Proposed Activation Date | -| --------------------------------- | ---------------------------- | -| Transfer hotspot | Planned: Monday Nov 23, 2020 | -| Remove score from consensus group | Planned: Monday Nov 23, 2020 | -| Beaconing Rewards | Tentative: End of November | - -**NOTE: There's some remaining work to be done to implement transfer hotspot using -[the CLI](https://github.com/helium/helium-wallet-rs/issues/60) and will be prioritized as one of -the last features of the v2 mobile app.** - -### Plan - -We have been beta testing `2020.11.17.0` since November 17th, 2020. Once the team is comfortable -with initial testing, we plan on releasing to GA at 10:00 AM PST, November 19th 2020. diff --git a/devblog/2020-11-23-app-version-270.mdx b/devblog/2020-11-23-app-version-270.mdx deleted file mode 100644 index c91ffc0b4..000000000 --- a/devblog/2020-11-23-app-version-270.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: App Version 2.7.0 -date: 2020-11-23 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Performance Fixes - -- Migrate legacy secure store data in preparation for new app version (v3). We recommend all users - update to this new app version. Failure to update to this version could mean losing access to your - Wallet/Account and associated Hotspots if a user directly upgrades from 2.6.1 to 3.x.x. as a - restore from the deprecated secure store will no longer be supported. This is also a good reminder - to write down the 12 words used to generate the wallet's private key. You can find those 12 words - by launching the Helium App > More > Advanced > Reveal 12 Words. - - - -# Bug Fixes - -## Android 8.0.0 - -Some Samsung Galaxy S7 users running Android 8.0.0 were unable to launch the app due to a splash -screen size issue. We've optimized the logic for those types of devices so that it pulls a smaller -file instead. Users will be able to launch the app once they update to 2.7.0. - -## iPhone 12 Pro Max Layout Fix - -New iPhone 12 Pro Max users saw a layout issue with the navigation menu. This is now fixed. - -## Hotspot Offline Notification Icon clipped - -The Hotspot Offline Notification had a clipped icon. This is fixed. diff --git a/devblog/2020-11-30-blockchain-maintenance-release.mdx b/devblog/2020-11-30-blockchain-maintenance-release.mdx deleted file mode 100644 index 98fdf6262..000000000 --- a/devblog/2020-11-30-blockchain-maintenance-release.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: 'Blockchain Maintenance Release' -date: 2020-11-30 09:00 -0700 -hide_table_of_contents: true -authors: [abhay, vihu, madninja] ---- - -The `2020.11.30.0` release is a minor blockchain maintenance release. The primary goal of this -release is to bump the blessed snapshot. - - - -#### Blessed Snapshot Update - -This release also bumps the blessed snapshot to height `609841` which will improve sync times of -newly onboarded Hotspots. - -#### Transaction Type Sort Ordering - -This release also addresses a minor issue with transaction type sort ordering for block ingestion on -nodes syncing from the genesis block. This should not affect any running instances of the miner but -useful for the blockchain team for testing code changes and for audits. - -#### Related PRs - -- _Dont allow any unsortable transaction to validate_ - - [blockchain-core/683](https://github.com/helium/blockchain-core/pull/683) -- _Add sort order for routing_v1, token_burn_v1 transactions_ - - [blockchain-core/682](https://github.com/helium/blockchain-core/pull/682) -- _Prepare for 11/30 release bump_ - - [miner/565](https://github.com/helium/miner/pull/565) - -### Plan - -We began beta-testing `2020.11.30.0` around 1:00 PM PST, November 30, 2020 and plan to GA on -Tuesday, December 1st, 2020 around 4PM PST. diff --git a/devblog/2020-11-30-console-updates-1.4.0.mdx b/devblog/2020-11-30-console-updates-1.4.0.mdx deleted file mode 100644 index c45e225b6..000000000 --- a/devblog/2020-11-30-console-updates-1.4.0.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: post -title: Console Updates- Adafruit IO Integration -date: 2020-12-01 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This release was focused on Integration work, including adding a pre-built Adafruit IO Integration, -and frontend updates to make the selected Integration more obvious. - - - -### Features and Updates - -- Added a pre-built integration for Adafruit IO. Users simply input Adafruit IO username, key, and - choose a group name. -- Integration usability updates to make selected Integration more clear. -- Group device import provides a progress indicator during import. -- Payload size sent to Integrations. -- On the navigation bar the blue/active hover state persists after users have selected and navigated - to that section of the site. -- Keyboard shortcut added to quickly access search. - -### Fixes - -- Removed unintended white screen that appeared when clicking show Integrations in debug -- Improved communication between the Console front and backend to align Data Credit count. -- Fixed an issue related to access control among Organizations. -- Template properly updates when attached to MQTT integration. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Console custom notifications: provide email notifications for a number of conditions related to - devices and integrations. -- Provide the ability to pay for additional packets for redundancy and location triangulation - purposes. -- Include support for LoRaWAN adaptive data rate (ADR). -- Provide more information related to LoRaWAN commands in the Event log. -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-12-02-blockchain-chain-variable-update-reducing-poc-transaction-rate.mdx b/devblog/2020-12-02-blockchain-chain-variable-update-reducing-poc-transaction-rate.mdx deleted file mode 100644 index 9ca3fe945..000000000 --- a/devblog/2020-12-02-blockchain-chain-variable-update-reducing-poc-transaction-rate.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: 'Blockchain Chain Variable Update: Reducing PoC Transaction Rate' -date: 2020-12-02 11:25 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The Helium blockchain team will be submitting a chain variable transaction that will increase the -target interval between Proof-of-Coverage challenges (PoCs), changing the `poc_challenge_interval` -variable from `120` to `240` blocks. This update will effectively halve the rate of PoC transactions -that Hotspots generate. - - - -As some folks have noticed, the block production rate is experiencing some growing pains due to the -number of new Hotspots that are coming online. We strive to maintain block time reliability and this -is one of the levers we have to keep the network stable. - -### How does this impact Hotspots? - -The impact on individual Hotspots is participating in fewer PoCs per day but because this is being -applied to all Hotspots in the network, system wide rewards distribution will be maintained. -Individual reward numbers will change so, as always, it’s best to look at rewards over a -multi-day/week period. - -### Plan - -We intend to submit this chain variable around 4:00 PM PT, December 2, 2020. This blog post will be -updated with links to the audit and a link to the transaction in explorer. - -- [Audit Log](https://github.com/helium/miner/blob/master/audit/var-49.md) -- [Transaction](https://explorer-old.helium.com/txns/pux3k87XKsfoeL6YAIJLDG1HRZPtvXexoQ3lr_AsJN0) diff --git a/devblog/2020-12-02-helium-api-update-removing-the-score.mdx b/devblog/2020-12-02-helium-api-update-removing-the-score.mdx deleted file mode 100644 index d5746652d..000000000 --- a/devblog/2020-12-02-helium-api-update-removing-the-score.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: 'Helium API Update: Removing the Score' -date: 2020-12-02 15:57 -0800 -hide_table_of_contents: true -authors: [abhay, madninja] ---- - -With the release of -[HIP 16](https://github.com/helium/HIP/blob/master/0016-random-consensus-group-election.md) and -implementation of -[Random Consensus Group selection](https://engineering.helium.comhttps://docs.helium.com/blog/2020/11/18/blockchain-release-feature-updates.html), -the PoC-based Hotspot Score is no longer a metric that's used by the Helium blockchain. We intend to -completely remove the `score` field from the -[API response](https://developer.helium.com/blockchain/api/api-hotspots#hotspot-for-address). - - - -To ease the transition to removing it entirely, we've adjusted all Hotspot scores to `1`. This -change was made earlier today, December 2, 2020 around 1:15 PM PT. - -We plan on deploying an additional change on Monday, December 7, 2020 around 10AM PT to completely -remove the field. If you're currently a consumer of the API and depend on this field, please take -this time to update your clients / applications. - -There will be a subsequent code change that updates the `blockchain-etl` project to remove this from -the database as well. diff --git a/devblog/2020-12-09-blockchain-release-hip-17/dense.png b/devblog/2020-12-09-blockchain-release-hip-17/dense.png deleted file mode 100644 index 70577d806..000000000 Binary files a/devblog/2020-12-09-blockchain-release-hip-17/dense.png and /dev/null differ diff --git a/devblog/2020-12-09-blockchain-release-hip-17/index.mdx b/devblog/2020-12-09-blockchain-release-hip-17/index.mdx deleted file mode 100644 index fca4efbf5..000000000 --- a/devblog/2020-12-09-blockchain-release-hip-17/index.mdx +++ /dev/null @@ -1,133 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: HIP 17' -date: 2020-12-09 17:16 -0800 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The `2020.12.15.2` release was a monumental release adding support for -[HIP17](https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md). -**Note that we have decided to scrap the `2020.12.09.0`, `2020.12.11.0`, and `2020.12.15.1` releases -because of bugs we identified during ongoing testing. Details about those bug fixes can be found -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/12/14/blockchain-release-hip-17-bugfixes.html) -and -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/12/15/blockchain-release-hip-17-additional-bugfixes.html).** - - - -#### HIP17: Hex density based reward scaling - -The primary goal of HIP17 is to scale the rewards for challengees (transmitters) and witnesses -(receivers) depending on the [h3](https://h3geo.org/) hexagon they are asserted at. This change to -reward distribution is to better incentivize coverage by reducing rewards earned by -transmitting/witnessing hotspots in close proximity to each other. The formulae used for the scaling -are detailed in the above link. - -Essentially we expect an optimum density at every possible -[h3 resolution](https://h3geo.org/docs/core-library/restable), these would be supplied as chain -variables when we activate this feature. If the challengee is found to be in a hex where the density -is higher than the configured optimum value, they would get scaled rewards. The witnesses for those -transmissions would get the scale of the transmitter applied to their rewards as well. It's -important to note that the scale of the witness does not matter. - -The team has modeled all the Hotspots on the network with their corresponding scale values, below -are some examples of scale values from the map. - -**NOTE: The scale value on the below images does not apply to overall reward scaling, it's only an -indicator for PoC transmission reward scaling. A scale of `0.2` does _not_ mean that a Hotspot's -overall rewards will go down by `80%`.** - -_Sparse Density Scaling_ - -![sparse](./sparse.png) - -_Variable Scaling_ - -![variable](./variable.png) - -_Dense Cluster Scaling_ - -![dense](./dense.png) - -_Finally, here's San Francisco with Scaling_ - -![sf](./sf.png) - -The team had previously published `2020.11.10.0` which added support for -[HIP15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md), this release adds on -top of that since HIP17 goes in conjunction with HIP15. - -**NOTE: This release only adds support for HIP17, please refer to the plan to know the exact -activation time.** - -#### HIP17: Proposed chain variables - -These are the same chain variables as proposed in the HIP17, just written in a way that the chain -understands. - -| Chain Variable | Proposed Value | Reason | -| -------------------------- | --------------------- | ------------------------------------------------------------------------ | -| hip17_res_0 | <"2,100000,100000">> | Default (unused) | -| hip17_res_1 | <"2,100000,100000">> | Default (unused) | -| hip17_res_2 | <"2,100000,100000">> | Default (unused) | -| hip17_res_3 | <"2,100000,100000">> | Default (unused) | -| hip17_res_4 | <<"1,250,800">> | Number of siblings: 1, density_tgt: 250, density_max: 800 | -| hip17_res_5 | <<"1,100,400">> | Number of siblings: 1, density_tgt: 100, density_max: 400 | -| hip17_res_6 | <<"1,25,100">> | Number of siblings: 1, density_tgt: 25, density_max: 100 | -| hip17_res_7 | <<"2,5,20">> | Number of siblings: 2, density_tgt: 5, density_max: 20 | -| hip17_res_8 | <<"2,1,4">> | Number of siblings: 2, density_tgt: 1, density_max: 4 | -| hip17_res_9 | <<"2,1,2">> | Number of siblings: 2, density_tgt: 1, density_max: 2 | -| hip17_res_10 | <<"2,1,1">> | Number of siblings: 2, density_tgt: 1, density_max: 1 | -| hip17_res_11 | <<"2,100000,100000">> | Default (unused) | -| hip17_res_12 | <<"2,100000,100000">> | Default (unused) | -| density_tgt_res | 4 | Resolution to calculate density | -| hip17_interactivity_blocks | 3600 | Number of blocks since last_poc_challenge a Hotspot is considered active | - -Furthermore, below are the proposed chain variables for HIP15: - -| Chain Variable | Proposed Value | Reason | -| --------------------- | -------------- | ---------------------------------------------------------- | -| witness_redundancy | 4 | Optimum desired redundant witnesses for a poc transmission | -| poc_reward_decay_rate | 0.8 | Decay rate for additional poc transmission | - -In order to have full effect for HIP17 all the above mentioned chain variables (HIP15 + HIP17) are -required. - -#### Bump snapshot to 624961 - -This release also bumps the blessed snapshot to height `624961` which will improve sync times of -newly onboarded Hotspots. - -#### Related PRs - -- _Add support for HIP17_ - - [blockchain-core/677](https://github.com/helium/blockchain-core/pull/677) -- _Add support for HIP17 and bump snapshot_ - - [miner/579](https://github.com/helium/miner/pull/579) -- _Bugfixes_ - - [blockchain-core/695](https://github.com/helium/blockchain-core/pull/695) - - [blockchain-core/696](https://github.com/helium/blockchain-core/pull/696) - - [blockchain-core/697](https://github.com/helium/blockchain-core/pull/697) - - [blockchain-core/703](https://github.com/helium/blockchain-core/pull/703) - -### Plan - -~~We began beta-testing `2020.12.09.0` around 5:00 PM PST, December 8th, 2020 and plan to GA on -Thursday, December 10th, 2020 around 2PM PST. We will activate HIP17 and HIP15 chain variables on -Monday, December 14th, 2020 and will be announcing this change via push notification and on -Discord.~~ - -~~We began beta-testing `2020.12.09.0` around 5:00 PM PT, December 8th, 2020 and deployed the -release to GA on Thursday, December 10th, 2020 around 3:00 PM PT. After identifying an issue that -required an additional deployment before the chain variable activation, we began beta-testing -`2020.12.11.0` around 4:00 PM PT, Friday, December 11, 2020. We plan to GA around 10:00 AM, Sunday, -December 13, 2020.~~ - -~~We planned to activate the HIP17 and HIP15 chain variables on Monday, December 14th, 2020 but -scrapped the change due to bugs we found in HIP17 implementation. A future blog post will describe -our next steps.~~ - -We activated the HIP17 and HIP15 chain variables on Wednesday, December 16th, 2020 at 10AM PST. -Activation Transaction can be found on -[Helium Explorer](https://explorer-old.helium.com/txns/vnEqwbKtFfFxXgYI_9L5Th0LRVkpJlsX-sQzZTh2VwY). diff --git a/devblog/2020-12-09-blockchain-release-hip-17/sf.png b/devblog/2020-12-09-blockchain-release-hip-17/sf.png deleted file mode 100644 index 5bb2b0001..000000000 Binary files a/devblog/2020-12-09-blockchain-release-hip-17/sf.png and /dev/null differ diff --git a/devblog/2020-12-09-blockchain-release-hip-17/sparse.png b/devblog/2020-12-09-blockchain-release-hip-17/sparse.png deleted file mode 100644 index f5ec4d88d..000000000 Binary files a/devblog/2020-12-09-blockchain-release-hip-17/sparse.png and /dev/null differ diff --git a/devblog/2020-12-09-blockchain-release-hip-17/variable.png b/devblog/2020-12-09-blockchain-release-hip-17/variable.png deleted file mode 100644 index fc0ede9c7..000000000 Binary files a/devblog/2020-12-09-blockchain-release-hip-17/variable.png and /dev/null differ diff --git a/devblog/2020-12-09-console-updates-1.4.5.mdx b/devblog/2020-12-09-console-updates-1.4.5.mdx deleted file mode 100644 index 4cb06201a..000000000 --- a/devblog/2020-12-09-console-updates-1.4.5.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: Console Updates- Initial backend components released as open source -date: 2020-12-10 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -During this sprint we released Console backend components on our public github repo, made updates to -JSON Messaging template, and made interface enhancements to help educate new users. - - - -### Features and Updates - -- JSON Messaging template: users can use templates to customize messages that get sent from - Integrations. Default JSON messages and corresponding templates for known decoders (Cayenne, and - Browan) are provided. -- Released Console backend code ([Packet Purchaser](https://github.com/helium/packet-purchaser)) on - our public github, the first step to providing Console backend (Router) as open source, and - enabling integration with other LoRaWAN Network Servers. -- Added syntax highlighting for custom script code editor. -- Additional help content added to educate new users: on main feature screens and tooltips for both - Debug and Downlink. -- Direct link to release notes from Console version number. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Console custom notifications: provide email notifications for a number of conditions related to - devices and integrations. -- Provide the ability to pay for additional packets for redundancy and location triangulation - purposes. -- Include support for LoRaWAN adaptive data rate (ADR). -- Provide more information related to LoRaWAN commands in the Event log. -- Release Console and its backend network server and blockchain components (Router) as open source. diff --git a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/dense-v2.png b/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/dense-v2.png deleted file mode 100644 index 6a0a4467c..000000000 Binary files a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/dense-v2.png and /dev/null differ diff --git a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/index.mdx b/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/index.mdx deleted file mode 100644 index 5e9347e6f..000000000 --- a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/index.mdx +++ /dev/null @@ -1,81 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: HIP 17 Bugfixes' -date: 2020-12-14 21:58 -0800 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -The `2020.12.15.1` release is a bugfix release to add support for -[HIP17](https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md). -Please find a detailed breakdown of the bugfixes below. - - - -#### [blockchain-core#697](https://github.com/helium/blockchain-core/pull/697): Fix H3 Index Corruption - -Before the team could activate support for HIP 17 in a previous release (you can read more about -this -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/12/09/blockchain-release-hip-17.html)), -we realized that the network could run into a potential blockchain halt due to mismatching h3 -indexes, which are updated on every `add_gateway` and `assert_location` transaction. We had an -internal discussion on the impact of this issue and collectively decided to address the bug and -postpone HIP 17 activation for a day. Please find the plan below. - -The bug was quickly root caused to malformed case clauses in `assert_location` transaction which -were not correctly updating the h3 indexes when a Hotspot's location changed on the network. Please -feel free to view the commits on the bug -[here](https://github.com/helium/blockchain-core/pull/697/commits). - -#### Debugging HIP 17 Variables - -The team continues to make improvements in how Hotspot owners can visualize their Hotspot -performance and needs to make some blockchain core changes to visualize the rewards scale. As a stop -gap, we've modeled all the Hotspots on the network with their corresponding scale values, we -currently use [this debugging tool](https://hip17.helium.wtf/) to help us understand reward scales -at a particular block height. This tool is not updated live and bound to the specific block height -that is in the legend (currently: [632627](https://explorer-old.helium.com/blocks/632627), -approximately `2020-12-14 @ 5:47 PM PT`). - -As mentioned in a prior post, the scale value in the visualization does not apply to overall reward -scaling. It is only an indicator for PoC transmission reward scaling. A scale of `0.2` does _not_ -mean that a Hotspot's overall rewards will go down by `80%`. - -Here are some updated images from the tool for reference - -_Sparse Density Scaling_ - -![sparse-v2](./sparse-v2.png) - -_Variable Scaling_ - -![variable-v2](./variable-v2.png) - -_Dense Cluster Scaling_ - -![dense-v2](./dense-v2.png) - -_Finally, here's San Francisco with Scaling_ - -![sf-v2](./sf-v2.png) - -#### [miner#580](https://github.com/helium/miner/pull/580): Adjust Spreading Factor - -This release also adjusts spreading factors again to take into account the lack of a LoRaWAN header -for PoC. We're including this change in this release since it's a minor code change but a -significant improvement for EU Hotspots and a useful improvement for US Hotspots. You can see a past -description of spreading factor changes in this -[old post](https://engineering.helium.comhttps://docs.helium.com/blog/2020/10/02/spreading-factor-changes-poc.html). - -#### [blockchain-core#699](https://github.com/helium/blockchain-core/pull/699): Fix Bad Snapshot Binary Tag - -We also fixed the snapshot binary tag which wasn't getting updated correctly therefore doing -incorrect deserialization and enhanced the tests to avoid future slippage. - -### Plan - -We began beta testing `2020.12.15.1` around 10:00 AM PT, December 15th, 2020 and plan to deploy to -GA on Tuesday, December 15th, 2020 around 3:00 PM PT. - -We plan on activating HIP15 and HIP17 chain variables on Wednesday, December 16th, 2020 and will be -announcing this change via push notification and on Discord. diff --git a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/sf-v2.png b/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/sf-v2.png deleted file mode 100644 index 8db0ef497..000000000 Binary files a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/sf-v2.png and /dev/null differ diff --git a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/sparse-v2.png b/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/sparse-v2.png deleted file mode 100644 index ce46a2d87..000000000 Binary files a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/sparse-v2.png and /dev/null differ diff --git a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/variable-v2.png b/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/variable-v2.png deleted file mode 100644 index b856b9af4..000000000 Binary files a/devblog/2020-12-14-blockchain-release-hip-17-bugfixes/variable-v2.png and /dev/null differ diff --git a/devblog/2020-12-15-app-version-280.mdx b/devblog/2020-12-15-app-version-280.mdx deleted file mode 100644 index a0ce78ac0..000000000 --- a/devblog/2020-12-15-app-version-280.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -layout: post -title: App Version 2.8.0 -date: 2020-12-15 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Transfer Hotspot - -As approved by HIP13, the engineering team has finished the implementation of Transfer Hotspot, -allowing any Hotspot owner to transfer ownership of a Hotspot to a new owner. The full help -documentation can be found here: https://docs.helium.com/wallets/app-wallet/transfer-hotspot/ and -CLI support here: https://developer.helium.com/blockchain/blockchain-cli#hotspots-transfer - - - -**To successfully transfer a Hotspot, both parties must have app version 2.8.0 installed.** -**Sellers and Buyers do not need to be physically next to the Hotspot to transfer.** - -## How It Works - -As a seller, the user navigates to the Hotspot to be transferred and taps Settings (cog). In the -settings is a new option to Transfer Hotspot. Press "Start". - -A message will appear letting the seller know they will no longer see the Hotspot in their app or -earn HNT from mining. Enter the Hotspot name to proceed. This is not case-sensitive. - -At this point, the user is asked to enter the buyer wallet address (note that the buyer must also -have a valid wallet address on the Helium network). _The amount in HNT is optional. This allows for -other methods of payment using fiat (PayPal, other cryptocurrencies)._ - -The seller confirms the transfer and a partial transaction is constructed and signed by the seller. - -The buyer receives a notification in their Helium app and views the transaction to confirm a) seller -address b) Hotspot name c) last reported activty on the blockchain and d) cost of Hotspot. - -When the buyer accepts the transfer, the transaction is countersigned by the buyer and the fully -constructed transaction is submitted to the blockchain. - -After the transaction clears, the Hotspot will appear in the new owner's account and the HNT (if -any) is debited from the buyer's balance. The Hotspot will be removed from the seller's account, and -all new HNT earnings will belong to the new owner. - -**Note: All mining history from the Hotspot will transfer to the new owner as well. This cannot be -cleared as all history is from the ledger.** - -It is up to the buyer and seller to coordinate the physical exchange of the Hotspot. - -## Canceling a Pending Transfer - -A seller can cancel a pending Hotspot transfer by going to the Hotspot settings and tapping "Cancel" -next to Transfer Hotspot. The buyer will receive a notification that the transfer has been -cancelled. - -## Things to Keep In Mind - -It is the buyer's responsibility to confirm the Hotspot is fully functional and will arrive in the -same, working condition. - -The buyer must pay the transaction fee, even if the cost of Hotspot is zero. - -# Known Issues - -## Transaction Screen spacing - -Some device screens may see more or less spacing on the Transfer Hotspot transaction screen. diff --git a/devblog/2020-12-15-blockchain-release-hip-17-additional-bugfixes.mdx b/devblog/2020-12-15-blockchain-release-hip-17-additional-bugfixes.mdx deleted file mode 100644 index 995b70950..000000000 --- a/devblog/2020-12-15-blockchain-release-hip-17-additional-bugfixes.mdx +++ /dev/null @@ -1,67 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: HIP 17 Additional Bugfixes' -date: 2020-12-15 18:41 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The `2020.12.15.2` release is an additional bugfix release to add support for -[HIP15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md) and -[HIP17](https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md). -Please find a detailed breakdown of the bugfixes below. - - - -#### [blockchain-core#703](https://github.com/helium/blockchain-core/pull/703): Update PoC path limit validation - -The team is releasing one last minute change to chain variable validation to help allow one of the -chain variables that need to be updated tomorrow to land. - -#### Chain Variables - -Here's a review of the chain variables we intend to activate tomorrow. Please note the additions of -PoC path length and the change to the PoC Challengee and Witness percentages. The total pool between -the two has stayed the same (26.55%) but we've adjusted the two numbers to be more aligned with the -goals of HIP 15 as written by the author. Because of the way the blockchain calculates rewards -(separately between the two pools), it is necessary to set the Witness rewards pool to be -approximately 4 times the Challengee rewards pool to line up with the witness redundancy target -of 4. - -**HIP 15** - -| Chain Variable | Proposed Value | Reason | -| ----------------------- | -------------- | ---------------------------------------------------------- | -| poc_path_limit | 1 | Enabling Beacon PoC | -| witness_redundancy | 4 | Optimum desired redundant witnesses for a PoC transmission | -| poc_reward_decay_rate | 0.8 | Decay rate for additional PoC transmission | -| poc_challengees_percent | 0.0531 | PoC Challengee Rewards (formerly 0.18) | -| poc_witnesses_percent | 0.2124 | PoC Witnesses Rewards (formerly 0.0855) | - -**HIP 17** - -| Chain Variable | Proposed Value | Reason | -| -------------------------- | --------------------- | ------------------------------------------------------------------------ | -| hip17_res_0 | <<"2,100000,100000">> | Default (unused) | -| hip17_res_1 | <<"2,100000,100000">> | Default (unused) | -| hip17_res_2 | <<"2,100000,100000">> | Default (unused) | -| hip17_res_3 | <<"2,100000,100000">> | Default (unused) | -| hip17_res_4 | <<"1,250,800">> | Number of siblings: 1, density_tgt: 250, density_max: 800 | -| hip17_res_5 | <<"1,100,400">> | Number of siblings: 1, density_tgt: 100, density_max: 400 | -| hip17_res_6 | <<"1,25,100">> | Number of siblings: 1, density_tgt: 25, density_max: 100 | -| hip17_res_7 | <<"2,5,20">> | Number of siblings: 2, density_tgt: 5, density_max: 20 | -| hip17_res_8 | <<"2,1,4">> | Number of siblings: 2, density_tgt: 1, density_max: 4 | -| hip17_res_9 | <<"2,1,2">> | Number of siblings: 2, density_tgt: 1, density_max: 2 | -| hip17_res_10 | <<"2,1,1">> | Number of siblings: 2, density_tgt: 1, density_max: 1 | -| hip17_res_11 | <<"2,100000,100000">> | Default (unused) | -| hip17_res_12 | <<"2,100000,100000">> | Default (unused) | -| density_tgt_res | 4 | Resolution to calculate density | -| hip17_interactivity_blocks | 3600 | Number of blocks since last_poc_challenge a Hotspot is considered active | - -### Plan - -We began beta testing `2020.12.15.2` around 07:20 PM PT, December 15th, 2020 and plan to deploy to -GA on Tuesday, December 15th, 2020 around 9:00 PM PT. - -We still plan on activating HIP 15 and HIP 17 chain variables on Wednesday, December 16th, 2020 and -will be announcing this change via push notification and on Discord. diff --git a/devblog/2020-12-16-chain-variable-update-max-witnesses.mdx b/devblog/2020-12-16-chain-variable-update-max-witnesses.mdx deleted file mode 100644 index 66bd4af4b..000000000 --- a/devblog/2020-12-16-chain-variable-update-max-witnesses.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: post -title: 'Chain Variable Update: Max Witnesses' -date: 2020-12-16 14:00 -0800 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -The team has successfully deployed support for -[HIP 15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md) and -[HIP 17](https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md) -and switched to a beacon-only PoC model. One of the things we decided not to change with all of the -other chain variables this morning was an increase to the number of max witnesses for each PoC. Now -that we are confident with the way the Consensus Group is able to handle the new PoC receipts and -new rewards calculations, we feel like it's safe to increase the max number of witnesses in each PoC -receipt. - - - -Previously, we allowed maximum PoC path length of 5 with each PoC hop allowed to have 5 max -witnesses. This implied that the total number of witnesses per PoC transaction would be 25 (best -case scenario). In the beacon-only model, since there's only a single challengee (beaconer) who -would transmit a PoC packet, we are increasing the witness limit from 5 to 25. - -You can read more about the deployment progress of HIPs 15 and 17 in our previous blog posts -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/12/09/blockchain-release-hip-17.html), -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/12/14/blockchain-release-hip-17-bugfixes.html) -and -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2020/12/15/blockchain-release-hip-17-additional-bugfixes.html). - -#### Proposed Chain Variable - -| Chain Variable | Proposed Value | Reason | -| ------------------------- | -------------- | ------------------------------------------------ | -| poc_per_hop_max_witnesses | 25 | Increased to allow more witnesses per PoC beacon | - -### Plan - -We plan on issuing the chain variable transaction at 3PM PST on Wednesday, Dec 16 2020. We will -update this post to reflect the transaction on chain when it goes live. diff --git a/devblog/2020-12-17-blockchain-maintenance-release.mdx b/devblog/2020-12-17-blockchain-maintenance-release.mdx deleted file mode 100644 index 340997cd5..000000000 --- a/devblog/2020-12-17-blockchain-maintenance-release.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -layout: post -title: Blockchain Maintenance Release -date: 2020-12-17 09:37 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The `2020.12.16.0` release is a minor blockchain maintenance release. The primary goal of this -release is to bump the blessed snapshot. - - - -#### Blessed Snapshot Update - -This release bumps the blessed snapshot to height `635041` which will improve sync times of newly -onboarded Hotspots. - -### Plan - -We began beta-testing `2020.12.16.0` around 9:00 PM PT, December 16, 2020 and plan to GA on -Thursday, December 17, 2020 around 11:00 AM PST. diff --git a/devblog/2020-12-22-blockchain-release-minor-updates.mdx b/devblog/2020-12-22-blockchain-release-minor-updates.mdx deleted file mode 100644 index 79e167ccc..000000000 --- a/devblog/2020-12-22-blockchain-release-minor-updates.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Minor Updates' -date: 2020-12-22 17:37 -0800 -hide_table_of_contents: true -authors: [vihu, abhay, vagabond] ---- - -The team has a new release tagged `2020.12.22.1` before the holidays with a snapshot bump and -blockchain core support for showing invalid witnesses in the API. Please read on for more details -and plan for GA. - - - -### [blockchain-core#706](https://github.com/helium/blockchain-core/pull/706): Expose invalid witness reason - -In order for the API to have consistency with the blockchain, blockchain-core now exports helper -functions which output the precise reasons why a particular PoC witness Hotspot was considered -invalid during ingestion of a PoC Receipt Transaction. The team has planned support for exposing -this information in [explorer](https://explorer-old.helium.com) and Helium app via the blockchain -API. - -### [miner#586](https://github.com/helium/miner/pull/586): Snapshot bump to 642961 - -We have updated the snapshot block to `642961` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2020.12.22.1` since December 22nd, 2020 7:00PM PT. Current ETA for GA is -11:00 AM PT, December 23rd, 2020. diff --git a/devblog/2020-12-30-chain-variable-update-increase-poc-target-challenge-age.mdx b/devblog/2020-12-30-chain-variable-update-increase-poc-target-challenge-age.mdx deleted file mode 100644 index 9e023fc10..000000000 --- a/devblog/2020-12-30-chain-variable-update-increase-poc-target-challenge-age.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: 'Chain Variable Update: Increase PoC Target Challenge Age' -date: 2020-12-30 10:09 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The Helium team will be adjusting the `poc_v4_target_challenge_age` chain variable from `300` to -`1000` in order to align more closely with the current value of `poc_challenge_interval` (which is -currently set to `240`). - - - -This variable is a staleness check that miners use to determine if the hotspot being challenged has -been active recently enough for the challenge to succeed. Hotspots which have not themselves issued -a challenge in a long time are unlikely to be online or properly synced with the chain. - -The `poc_v4_target_challenge_age` variable was originally set to `300` when the -`poc_challenge_interval` was set to `30` but never updated proportionally. - -### Impact on Challenge Rate - -We expect that adjusting this variable will increase the diversity of the hotspots being challenged. -As this affects all hotspots, it should have no aggregate impact on PoC rewards. - -#### Proposed Chain Variable - -| Chain Variable | Old Value | New Value | Reason | -| --------------------------- | --------- | --------- | -------------------------------------------- | -| poc_v4_target_challenge_age | 300 | 1000 | Mirror the change in the challenge interval. | - -### Plan - -We plan on issuing the chain variable transaction at 1PM PT on Wednesday, Dec 30 2020. We will -update this post to reflect the transaction on chain when it goes live. diff --git a/devblog/2020-12-30-hotspot-firmware-updates-hardware-support-and-blockchain-improvements.mdx b/devblog/2020-12-30-hotspot-firmware-updates-hardware-support-and-blockchain-improvements.mdx deleted file mode 100644 index 4c7a13547..000000000 --- a/devblog/2020-12-30-hotspot-firmware-updates-hardware-support-and-blockchain-improvements.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Updates: Hardware Support and Blockchain Improvements' -date: 2020-12-30 12:32 -0800 -hide_table_of_contents: true -authors: [abhay, vagabond] ---- - -The team has a new release tagged `2020.12.30.0` with improved hardware support for the RAK Hotspot -Miner updates (ECC chip support), new region configs for future hotspots in China, Japan, Malaysia, -Singapore and Australia, minor adjustments to challenge targeting jitter, and a snapshot bump. -Please read on for more details and plan for GA. - - - -### [miner#597](https://github.com/helium/miner/pull/587): Adjust the POC challenge jitter factor - -Adjust the PoC interval jitter to behave better with larger PoC interval values. This should result -in slightly increased challenge rates. - -### [miner#589](https://github.com/helium/miner/pull/589): Snapshot bump to 653041 - -We have updated the snapshot block to `653041` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2020.12.30.0` since December 30th, 2020 2:00PM PT. Current ETA for GA is -12:00 PM PT, December 31st, 2020. diff --git a/devblog/2021-01-06-console-updates-1.5.0.mdx b/devblog/2021-01-06-console-updates-1.5.0.mdx deleted file mode 100644 index 1bae6f685..000000000 --- a/devblog/2021-01-06-console-updates-1.5.0.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: Console Updates- Notifications, and additional packet purchases -date: 2021-01-07 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -During the last sprint of 2020, the team delivered email notifications, the ability to pay for -additional packets, and a number of backend updates. Configuration for email notifications and the -ability to pay for additional packets has been added to Labels. This allows for flexibility over -which devices trigger the notifications or receive additional packets. - - - -### Features, updates, and fixes - -- Email notifications for a number of conditions related to devices and integrations including when - devices are deleted, Integrations updated or deleted. -- The ability to pay for additional packets for redundancy and location triangulation purposes. - Note: Even if you don't use the multiple packet purchase feature, there are certain conditions - which the system will purchase multiple packets to help ensure successful packet transmission. - These include: initial joining of the device (up to 5 packets), downlink (up to 3 packets), and - for acknowledgements (up to 3 packets). -- Increased accuracy for timestamp information sent to Integrations. -- The link "More details about adding devices can be found here" has been fixed to point to the - right doc url. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- API for packet purchase capability. -- Additional work on notifications: notifications to cover more conditions, including a webhook to - send notifications to dashboards. -- Include support for LoRaWAN adaptive data rate (ADR). -- Provide more information related to LoRaWAN commands in the Event log. -- Release Console and its backend network server and blockchain components (Router) as open source. -- Building foundation for a more visual-oriented interface for improved usability. diff --git a/devblog/2021-01-12-blockchain-release-minor-updates.mdx b/devblog/2021-01-12-blockchain-release-minor-updates.mdx deleted file mode 100644 index 046ac6d0e..000000000 --- a/devblog/2021-01-12-blockchain-release-minor-updates.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Minor Updates' -date: 2021-01-12 14:50 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The team has a new release tagged `2021.01.12.0` which contains minor bug fixes, test updates and a -snapshot bump. Please read further for more details. - - - -### [blockchain-core#704](https://github.com/helium/blockchain-core/pull/704): Add hip17 beacon only test group - -The team added more test cases which specifically address beacon specific HIP15/17 changes in -blockchain-core. - -### [blockchain-core#710](https://github.com/helium/blockchain-core/pull/710): Reduce log level for reward transaction - -Just reduces the chatter when an error happens when a Hotspot is not found in gateway_cache. - -### [blockchain-core#715](https://github.com/helium/blockchain-core/pull/715): Detect missing request block hash - -The team found a bug which was caused due to an unhandled case clause condition which would make -blockchain-etl drop sync with the chain when trying to tag witnesses for their invalidation reason. -This is now fixed. - -### [miner#592](https://github.com/helium/miner/pull/592): Fix POC to disallow self-witnessing - -After doing some investigation on chain, the team found that there are instances where a Hotspot may -incorrectly witness itself for a PoC receipt transaction. This happens likely due to inconsistent -RF. We have updated miner to disallow any self-witnessing. - -### [miner#596](https://github.com/helium/miner/pull/596): Update blockchain and Snapshot - -We have updated miner to use new blockchain-core and the snapshot block to `672481` to allow newly -onboarded hotspots to sync faster to the current blockchain head block. - -### Plan - -We have been beta testing `2021.01.12.0` since January 12th, 2021 4:00PM PT. Current ETA for GA is -11:00 AM PT, January 13th, 2021. diff --git a/devblog/2021-01-17-emergency-release-rak-hw-detect.mdx b/devblog/2021-01-17-emergency-release-rak-hw-detect.mdx deleted file mode 100644 index 87cef6782..000000000 --- a/devblog/2021-01-17-emergency-release-rak-hw-detect.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -layout: post -title: 'Emergency Release - RAK Hardware Detection' -date: 2021-01-17 14:50 -0800 -hide_table_of_contents: true -authors: [cokes518] ---- - -The team has a new emergency release tagged `2021.01.17.0` which contains a bug fix to detect new -RAK Hotspot Hardware. - - - -RAK Hotspot Miners shipped in late 2020 and January 2021 have a new hardware version that the -firmware was unable to detect. Without the ability to identify the hardware, the Hotspot's packet -forwarder continuously crashed, preventing its ability to witness and PoC. - -### Plan - -We have been beta testing `2021.01.17.0` since January 17th, 2021 10:30AM PT. Current ETA for GA is -11:00AM PT, January 17th, 2021. diff --git a/devblog/2021-01-20-console-updates-1.5.5.mdx b/devblog/2021-01-20-console-updates-1.5.5.mdx deleted file mode 100644 index f1cd3dbc2..000000000 --- a/devblog/2021-01-20-console-updates-1.5.5.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: post -title: Console Updates- ADR (Beta), APIs, More Notifications -date: 2021-01-21 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -In this release we’ve included beta support for LoRaWAN adaptive data rate (ADR), increased the -number of email notifications, and added a new API for multiple packet purchase. ADR allows devices -to use an optimal data rate which reduces power consumption and airtime on the network based on RF -conditions. It's recommended to only use this setting for fixed or non-mobile devices to ensure -reliable connectivity. - - - -### Features and updates - -- Added LoRaWAN adaptive data rate (ADR) support (beta). For flexibility we’ve included ADR as a - Label setting which allows users to allow ADR settings for a group of devices. ADR needs to be - requested by a device for this setting to have an effect. To access this setting, choose the Label - from the side menu > click `Label Settings` > choose the `ADR (Beta)` tab. -- Provided an API to include ability to specify multiple packet purchases if coverage is available. - Use a POST request: `https://console.helium.com/api/v1/labels/label_id/multi_buy` In Body - Parameters, specify `value`: and choose [1-10] for the desired number of packets to purchase, 10 = - all available packets. -- API reminders: - - To obtain an API key, click the user icon in the top right corner > `My Account` > - `Generate Key`. You will need to verify the API key via email before you can use it. - - To obtain a Label UUID, Use a GET request: `https://console.helium.com/api/v1/labels/` -- Increase the number of email notifications for a number of conditions related to devices and - integrations including when devices are deleted, Integrations updated or deleted. - -### Fixes - -- Deployed a patch that fixed a potential vulnerability for a Server Side Request Forgery - vulnerability attack. -- Deployed a patch that prevents JoinRequest replay attacks. -- Sorting the device table no longer causes the Device table to hang. -- Fixed pixel shift when clicking top bar profile icon. -- Updated clickable areas on different tables (e.g., Devices, Integrations) to be consistent. -- Fixed an inaccurate display of device count when deleting a Label from an Integration. -- Resolved an issue that prevented certain users from confirming invitations. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Provide the ability to send notifications via a web hook. -- Add APIs for notifications. -- Release Console and its backend network server and blockchain components (Router) as open source. -- Update the Event log to include more LoRaWAN-related information. -- Build foundation for a more visual-oriented interface for improved usability. -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack. diff --git a/devblog/2021-01-26-app-version-290.mdx b/devblog/2021-01-26-app-version-290.mdx deleted file mode 100644 index e1713acee..000000000 --- a/devblog/2021-01-26-app-version-290.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: App Version 2.9.0 -date: 2021-01-26 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 2.9.0 App Update - Onboarding Support - -As outlined in the -[blog posted January 20, 2021](https://blog.helium.com/onboarding-for-third-party-hotspots-f8b99df35be), -the team is making a change to how Hotspots are onboarded to accommodate our new third-party -Hotspots and manufacturers. - - - -We’re happy to announce another step in completing this initiative - the Helium App is now updated -to support new onboarding accounts for Helium and Cal-Chip Connected Devices. - -Please update your app to v2.9.0 for all Hotspot onboarding. Those who try to onboard with an older -app version will experience errors and will be unable to add Hotspots. - -At this point, all new onboarded Hotspots and RAK Hotspot Miners will be using the funded Data -Credits. - -As a reminder: - -- Adding Hotspots to the blockchain is free. -- Setting a Hotspot location is free for Helium and RAK Hotspot Miners. -- Setting a second Hotspot location is free for Helium Hotspots only. diff --git a/devblog/2021-01-26-maker-audit/index.mdx b/devblog/2021-01-26-maker-audit/index.mdx deleted file mode 100644 index 6577378b7..000000000 --- a/devblog/2021-01-26-maker-audit/index.mdx +++ /dev/null @@ -1,135 +0,0 @@ ---- -layout: post -title: Auditing Makers for the Decentralized Wireless Alliance -date: 2021-01-26 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# The Maker Audit - -The Helium community places a lot of trust in -[HIP19](https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md) approved -hardware vendors and grants them the ability to add full mining gateways to the Helium blockchain. -These manufacturers, also known as “Makers”, are limited by chain variables and the Onboarding -Server as described previously on -[the Helium blog](https://blog.helium.com/onboarding-for-third-party-hotspots-f8b99df35be). The -community trusts that the Maker will produce and deliver a real physical Hotspot with approved -security methods. - - - -As the network grows, it's important to put forth a set of guidelines that all Makers should adhere -to, for the growth and stability of the Network, but also for the community to understand the -progress of each Maker before purchasing products. - -The Helium team has been asked by the Decentralized Wireless Alliance (DeWi) to review the hardware -that has been presented and wants to provide transparency of our process thus far and it may evolve -as more Makers are approved. - -## EDIT: As of April 2021, the Maker Audit Process has evolved and changed - -The new process is below (current as of April 2021). Previous Makers approved before April 2021 are -legacied and will not be subject to the new process. - -1. Submit application -2. Hardware audit -3. Onboarding server integration -4. FCC/CE or other application radio certification -5. Community approval -6. Pre-orders note: items 2-4 can occur simultaneously - -For continuity, the old process is below. - -A summary of how a Maker goes from HIP19-approved to market: - -1. Makers submit a HIP. -2. DeWi and Community approve. -3. Makers send hardware samples for Audit. -4. Once Makers pass hardware audit, they are allowed to proceed to Network Integration. -5. The final stage of Network Integration is being able to add Hotspots to the Onboarding Server. - -If at any point, a Maker is unable to proceed to the next step, it will be up to the Maker to -process refunds to pre-orders. It is important as consumers to be aware of the Maker's Hotspot -status before purchasing. - -# Audit Status (Current as of January 25, 2021) - -**Results of the Audit are based on samples provided at start of audit. Consumer discretion is -advised.** - -![maker-audit](./maker-audit.png) - -## Table Definitions - -#### HIP19 Application - -Before being eligible for sample audit, a vendor must be community approved via -[HIP19](https://github.com/helium/HIP/tree/master/0019-third-party-manufacturers). - -#### Sample Received - -A sample representative of final production quality must be sent - -#### Block Syncing Benchmark - -The Miner’s data is wiped and the rate at which the device syncs from a specific block height is -monitored for roughly an hour. This is to ensure its processor is able to handle syncing the -blockchain and load snapshots. - -#### libp2p Validation - -The Miner’s peer book is inspected after roughly an hour; in addition, a direct connection over a -LAN is attempted - -#### Radio Configuration File Verification - -Insofar as the configuration files are compatible with those used in the Semtech Packet Forwarders, -channel configurations are verified to match the configuration required for each region using -[this utility](https://github.com/helium/packet-forwarder-test). The configuration files may be -present on the sample but may also be provided digitally. - -#### RF Validation - -For each hardware sample provided, an automated gateway-to-gateway test is done over the air to -further validate the regional configuration using -[this utility](https://github.com/helium/packet-forwarder-test). When possible, a gateway other than -the vendor’s gateway is used is the control. - -#### Alternative Security Audit - -When proposing an alternate security model than the ECC608 approach, a Maker may be subject to a -third-party verification of their security claims. This may block the conclusion of the audit, -however, providing these measures as an enhancement to the ECC608 model will avoid any blocking. - -#### ECC608 Provisioning - -When the ECC608 model is implemented, the provisioning of the ECC608 may be verified using -[this utility](https://github.com/helium/gateway_mfr). This proves that the ECC608 is configured in -the same way as the original Helium Hotspots. Makers should run the test themselves if they make any -changes to this stage of their manufacturing process. - -#### Miner Integration Test - -The Miner is queried to verify that it returns the same keys output from the ECC608 utility - -#### Onboarding Integration - -Only one of these three methods must be passed to conclude the audit. - -#### Alternative Onboarding Process - -When a Maker provides an alternative onboarding process, its integration with the onboarding server -shall be tested. - -#### BLE or QR Code Linking with App - -Onboarding using the Hotspot App will be tested with a dummy onboarding key to test proper -integration. - -#### Linking with Helium Wallet CLI - -Onboarding using the Helium Wallet CLI will be tested with a dummy onboarding key to test proper -integration. diff --git a/devblog/2021-01-26-maker-audit/maker-audit.png b/devblog/2021-01-26-maker-audit/maker-audit.png deleted file mode 100644 index b59a90b5e..000000000 Binary files a/devblog/2021-01-26-maker-audit/maker-audit.png and /dev/null differ diff --git a/devblog/2021-01-28-hotspot-firmware-power-updates/US915.png b/devblog/2021-01-28-hotspot-firmware-power-updates/US915.png deleted file mode 100644 index cefbaf2b1..000000000 Binary files a/devblog/2021-01-28-hotspot-firmware-power-updates/US915.png and /dev/null differ diff --git a/devblog/2021-01-28-hotspot-firmware-power-updates/index.mdx b/devblog/2021-01-28-hotspot-firmware-power-updates/index.mdx deleted file mode 100644 index 3742846f7..000000000 --- a/devblog/2021-01-28-hotspot-firmware-power-updates/index.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Power Updates' -date: 2021-01-27 12:32 -0800 -hide_table_of_contents: true -authors: [cokes518, vihu] ---- - -The team has a new release tagged `2021.01.27.0` containing a change to the Radio Power Output, -updates to RSSI offset, support for the onboarding server, bug fixes, and a snapshot bump. - - - -Please read on for more details and plan for GA. - -### [miner#597](https://github.com/helium/miner/pull/597): Power Output Change - -Please read to understand the impact in your region: - -#### US 915 Hotspots (Helium and RAK): - -We’ve discovered that Hotspots with the Semtech SX1302 chip inside (v2 Helium Hotspots, RAK -Hotspots) had their Transmit Power table configured incorrectly. This change will increase the power -output from 20 dBm to 27 dBm, which will significantly increase the range of PoC. - -![US915](./US915.png) - -#### EU868 Hotspots (Helium and RAK): - -We also discovered through this process that the power output for PoC in the EU region was too high. -This update will scale down the Power Output for these Hotspots as they were above what is allowed -in ETSI regulations. Transmit Power has been adjusted from 20dBm to 14dBm, which will reduce PoC -range in the majority of situations. This is not something we wanted to do, as we know the community -works hard to improve range, however, we need to stay within the recommendations from governing -bodies. We apologize for this initial misconfiguration. - -We have tested the new power output for both regions and confirmed it is within specifications. - -#### RSSI Offset - -Add optimizations to RSSI Offset. This does not affect PoC range but will improve witness validity. - -### [miner#607](https://github.com/helium/miner/pull/607): Ignore mark_done message in hbbft handler - -The team noticed occasional consensus manager crashes in the miner due to an unhandled response, -this has been fixed. - -### [miner#605](https://github.com/helium/miner/pull/605): Snapshot bump to 693361 - -We have updated the snapshot block to `693361` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.01.27.0` since January 26th, 2021 3:00PM PT. Current ETA for GA is -12:30 PM PT, January 27th, 2021. diff --git a/devblog/2021-02-02-blockchain-release-bug-fixes-and-routing-txn-update.mdx b/devblog/2021-02-02-blockchain-release-bug-fixes-and-routing-txn-update.mdx deleted file mode 100644 index b4a5b82e0..000000000 --- a/devblog/2021-02-02-blockchain-release-bug-fixes-and-routing-txn-update.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Stability Release - Required Upgrade' -date: 2021-02-02 11:26 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The team has a new release tagged `2021.02.01.1` which contains minor bug fixes, routing transaction -updates and a snapshot bump. This is a _required_ upgrade for all miners and will be automatic for -all Hotspots using the Helium firmware when we GA. Please read further for more details. - - - -### [blockchain-core#726](https://github.com/helium/blockchain-core/pull/726): Allow router to update XOR filters - -The team extended the validation for routing transaction and added the ability for a router owner to -update their XOR filters for the routing table. This will enable our upcoming open source release of -the Helium Router. - -### [erlang-libp2p#312](https://github.com/helium/erlang-libp2p/pull/312): Ensure transport is aware of NAT server crashes - -The team noticed cases of the NAT server crashing from not being able to renew and subsequent -inability of the TCP transport to attempt to retry connection. This is now fixed. - -### [erlang-libp2p#310](https://github.com/helium/erlang-libp2p/pull/310): Fix the NAT matrix order - -The team has fixed a bug where the NAT matrix was being traversed in reverse order causing excess -relay churn and seed node load issues, this has been tested and fixed to behave correctly. We'd like -to thank community members `@yrral` and `@speedracer` on [Discord](https://discord.gg/helium) who -noticed this issue. - -### [miner#611](https://github.com/helium/miner/pull/611): Bump miner snapshot - -We have updated the snapshot block to `700561` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### [miner#609](https://github.com/helium/miner/pull/609): Cleanup miner crashes - -We have addressed a minor issue where the miner crashes due to the security key chip being busy on -restart, this should be now more robust. - -### [miner#608](https://github.com/helium/miner/pull/608): Ignore unknown commands instead of handling incorrectly - -The team noticed a few incorrectly handled commands in miner's consensus handler process, this has -been fixed to ignore unknown commands instead of treating them in a way that crashed the handler and -the local consensus group member. - -### Plan - -We have been beta testing `2021.02.01.1` since February 1st, 2021 5:00PM PT. Current ETA for GA is -2:00 PM PT, February 2nd, 2021. diff --git a/devblog/2021-02-03-console-updates-1.6.0.mdx b/devblog/2021-02-03-console-updates-1.6.0.mdx deleted file mode 100644 index e41ba251b..000000000 --- a/devblog/2021-02-03-console-updates-1.6.0.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -layout: post -title: Console Updates- Flows (Beta), Notification Webhooks -date: 2021-02-04 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -We’re excited to launch a beta release of Flows, a new user experience designed to simplify -performing Console core actions. Also, in this release notifications can be sent via webhooks, and -APIs for notifications have been added. - - - -With Flows (beta) users can: Instantly see the relationships between Labels, Integrations, and -Functions. Connect or disconnect Labels to Functions and Integrations and Changes made in the Flows -workspace are reflected in other areas of Console and vice versa. Remember to save changes. - -Nodes are identified by the following: - -- Labels: yellow -- Integrations: depends on integration type (HTTP, MQTT) -- Decoder functions: down arrows - -We look forward to the experience Flows provides users and the additional features we plan on adding -over time. - -### Features and updates - -- Released Flows (beta) to accelerate connecting Labels to Functions and Integrations. -- Provided the ability to send notifications via webhooks. To access this setting, choose `Label` - from the side menu > `Label Settings` > `Notifications` > `Webhooks`. To obtain a webhook key for - authorization, choose `Organizations` from the side menu and copy relevant webhook key. -- Included APIs for email and webhook notifications. - - - Email: POST: https://console.helium.com/api/v1/labels/:label_id/notification_email - - Body Parameters: - - ``` - { - `key`: `device_deleted`, - `value`: `1`, - `recipients`: `admin` - } - ``` - - - Webhooks: Email: POST: https://console.helium.com/api/v1/labels/:label_id/notification_webhook - - Body Parameters: - - ``` - { - `key`: `device_deleted`, - `value`: `1`, - `url`: `http://hello.com` - `notes`: `hello world` - } - ``` - - - _key_ matches notification type and must be one of following: `device_deleted`, - `device_join_otaa_first_time`, `device_stops_transmitting`, `integration_stops_working`, - `integration_receives_first_event`, `downlink_unsuccessful`, `integration_with_devices_deleted`, - `integration_with_devices_updated` - - _value_ must be `1` for all except for when _key_ is `device_stops_transmitting` when it should - be the number of **minutes** to check that the device stopped transmitting for. - - Email: _recipients_ must be one of: `admin`, `manager`, `read`, `all` - - Webhook: _url_ must be the webhook url, and _notes_ is optional. - -- API reminders: - - To obtain an API key, click the user icon in the top right corner > `My Account` > - `Generate Key`. You will need to verify the API key via email before you can use it. - - To obtain a Label UUID, use a GET request: `https://console.helium.com/api/v1/labels/` - -### Fixes - -- Released a patch to address a timing issue under certain conditions could end up purchasing - multiple packets. -- Provided a fix to ensure ACKs are correctly sent and not duplicated. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Ability to clear Downlink queue. -- Adding regional support (CN, AS 1,2). -- Continue to add functionality to Flows (beta) -- Release Console and its backend network server and blockchain components (Router) as open source. -- Deliver a pre-built Integration for the Ubidots IoT platform. -- Update the Event log to include more LoRaWAN-related information. -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack. diff --git a/devblog/2021-02-05-blockchain-release-nat-fixes.mdx b/devblog/2021-02-05-blockchain-release-nat-fixes.mdx deleted file mode 100644 index 536c5c9e4..000000000 --- a/devblog/2021-02-05-blockchain-release-nat-fixes.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: NAT Fixes' -date: 2021-02-05 10:42 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The team has a new minor release tagged `2021.02.05.0` which contains an important NAT fix and a -regular snapshot bump. Please read further for details. - - - -### [erlang-libp2p#313](https://github.com/helium/erlang-libp2p/pull/313): Do not try infinite leases on NAT-PMP, lease time of 0 means delete - -The team noticed that the NAT matrix in libp2p would attempt infinite leases in -[NAT-PMP](https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol) mode, this is unsupported and -it's been fixed. - -### [miner#616](https://github.com/helium/miner/pull/616): Bump miner snapshot - -We have updated the snapshot block to `706321` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.02.05.0` since February 5th, 2021 11:00 AM PT. Current ETA for GA is -2:00 PM PT, February 5th, 2021. diff --git a/devblog/2021-02-09-miner-and-cli-fixes.mdx b/devblog/2021-02-09-miner-and-cli-fixes.mdx deleted file mode 100644 index 27c415a08..000000000 --- a/devblog/2021-02-09-miner-and-cli-fixes.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Minor Reliability and CLI Fixes' -date: 2021-02-05 13:35 -0800 -hide_table_of_contents: true -authors: [vagabond] ---- - -The team has a new minor release tagged `2021.02.09.2` which contains a reliabiliy fix for consensus -group members and some CLI fixes. - - - -### [miner#612](https://github.com/helium/miner/pull/612): Have consensus manager monitor miner process - -This improves the behaviour of the consensus manager when the miner process crashes. This could lead -to a consensus member failing to run the consensus group, lowering the group's resilience to -failure. - -### [miner#619](https://github.com/helium/miner/pull/619): Useablity improvments to miner info commands - -Community contribution from maco2035. - -### [miner#614](https://github.com/helium/miner/pull/612): Remove staging router from default_routers list - -This is work towards enabling other routers to manage their own routing tables. - -### [miner#622](https://github.com/helium/miner/pull/622): Bump miner snapshot - -We have updated the snapshot block to `706321` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.02.09.2` since around 10:00 AM PT, February 9th, 2021. Current ETA -for GA is 2:00 PM PT, February 9th, 2021. diff --git a/devblog/2021-02-11-blockchain-release-maintenance-update.mdx b/devblog/2021-02-11-blockchain-release-maintenance-update.mdx deleted file mode 100644 index aaaa952ed..000000000 --- a/devblog/2021-02-11-blockchain-release-maintenance-update.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Maintenance Update' -date: 2021-02-11 10:24 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -### Contents - -The team has a new minor release tagged `2021.02.10.4` which contains regular maintenance updates. -Please read further for more details. - - - -### [miner#624](https://github.com/helium/miner/pull/624): Use packet_rssi function to use RSSIS is available - -This should improve the accuracy of signal strength readings on Helium Hotspot v1.1 and RAK Hotspot -Miners, especially when devices are far away from the Hotspot. - -### [miner#623](https://github.com/helium/miner/pull/623): Add audit#54, update staking keys for Nebra - -The team published -[chain var #54](https://explorer-old.helium.com/txns/SBFYWKHakxZPOTg7fAlx5GMLyWD3ceDbGlMuN8PkmaU) -which enables Nebra manufactured hotspots to be onboarded on the network. - -### [miner#610](https://github.com/helium/miner/pull/610): Onboarding improvements to CLI and internal miner key management - -A community member (@ke6jj on github, thanks!) enhanced onboarding miner CLI allowing a user to -obtain the miner's manufacturing and maker details from the new Decentralized Wireless Alliance -server. - -### [miner#599](https://github.com/helium/miner/pull/599): Add RU864 frequency - -A community member (@shawaj on github, thanks!) added support for RU864 frequency to miner config. - -### Plan - -We have been beta testing `2021.02.10.4` since February 9th, 2021 5:00 PM PT. Current ETA for GA is -2:00 PM PT, February 11th, 2021. diff --git a/devblog/2021-02-12-blockchain-reversing-rssis-change.mdx b/devblog/2021-02-12-blockchain-reversing-rssis-change.mdx deleted file mode 100644 index dc5ee6fa7..000000000 --- a/devblog/2021-02-12-blockchain-reversing-rssis-change.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Maintenance Update' -date: 2021-02-12 7:45 -0800 -hide_table_of_contents: true -authors: [vagabond, madninja, abhay] ---- - -### Contents - -The team has a new minor release tagged `2021.02.12.0` which reverts the RSSIS change from -`2021.02.10.4`. This change, while correct, interacts poorly with our existing PoC acceptance -criteria and we're reverting it temporarily while we fix those. - - - -### [miner#638](https://github.com/helium/miner/pull/638): Revert "Use packet_rssi function to use RSSIS is available" - -We've decided to revert this change as it was causing distant witnessing to be incorrectly penalized -in PoC. - -### Plan - -We have been beta testing `2021.02.12.0` since February 12th, 2021 7:00 AM PT. Current ETA for GA is -10:30 AM PT, February 12th, 2021. diff --git a/devblog/2021-02-16-maker-update/index.mdx b/devblog/2021-02-16-maker-update/index.mdx deleted file mode 100644 index dbecc9a2e..000000000 --- a/devblog/2021-02-16-maker-update/index.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -layout: post -title: Maker Progress Update -date: 2021-02-16 -hide_table_of_contents: true -authors: [cokes518] ---- - -## Maker Update - -The three newly approved Makers of the Helium network have made great progress in their audit and -integration with the Hotspot app. We’d like to take this opportunity to inform the community on -their progress and how long each Makers took to progress through the milestones so you, as a -potential Hotspot owner, can understand when to expect your Hotspot once a Maker starts their audit -process. - - - -A summary of how a Maker goes from HIP19-approved to market: - -1. Makers submit a HIP. -2. DeWi and Community approve. -3. Makers send hardware samples for Audit. -4. Once Makers pass hardware audit, they are allowed to proceed to Network Integration. -5. The final stage of Network Integration is being able to add Hotspots to the Blockchain. - -To expand on Step 5, Makers will have to accomplish 4 additional milestones that is -[documented here](https://docs.helium.com/hotspot-makers): - -  - -# Add a Test Hotspot using the Test Maker account - -This step is to verify that the Maker’s Hotspot is communicating with the Hotspot app over Bluetooth -and it is able to submit signed transactions using the Hotspot app and the Test Maker address. - -Makers that choose to use other onboarding methods will still need to complete this step. - -This is verified by looking at the -[API endpoint of the Test Maker address](https://api.helium.io/v1/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr/pending_transactions) -(it is expected for transactions to fail). - -Nebra completed this step on February 3, 2021. Bobcat is in progress. Syncrobit is in progress. - -# Requesting a Maker account - -In order to receive a Maker account, the Maker must prove that they’re able to submit signed -transactions using the Hotspot app using the Test Maker address. - -As of February 16 2021, Nebra Ltd, Cal-Chip Connected Devices, and Helium have a Maker Account. A -list of Makers with accounts can be found [here](https://onboarding.dewi.org/api/v2/makers). - -# Submitting a Pull Request to the Hotspot App OSS Repository - -The next step of integration is submitting accompanying imagery, copy, and code, specific to the -Maker’s Hotspot. This allows the App to display Hotspot-specific instructions on how to pair, -diagnose, and request support. - -Nebra started this step on February 3, 2021, pending last minute debugging with help from Helium -engineers. You can [find the PR here](https://github.com/helium/hotspot-app/pull/175). - -Makers that opt to use other onboarding methods will not need to complete this step. - -# Add a Maker Hotspot to the Network - -The last step of integration is verifying that a Hotspot can be added to the blockchain using their -Maker Account and the Hotspot app. - -Nebra completed this step on February 9, 2021. You can see their Add Hotspot transaction -[here](https://explorer-old.helium.com/txns/b66b9xz7YZoOtJM59L_xiftfbukDshU484uAp0OmLiI). - -## Audit Status (Current as of February 16, 2021) - -**Results of the Audit are based on samples provided at start of audit.** - -![maker-update-2-16](./maker-update-2-16.png) diff --git a/devblog/2021-02-16-maker-update/maker-update-2-16.png b/devblog/2021-02-16-maker-update/maker-update-2-16.png deleted file mode 100644 index 1ca9a1cad..000000000 Binary files a/devblog/2021-02-16-maker-update/maker-update-2-16.png and /dev/null differ diff --git a/devblog/2021-02-17-console-updates-1.6.5.mdx b/devblog/2021-02-17-console-updates-1.6.5.mdx deleted file mode 100644 index b22749544..000000000 --- a/devblog/2021-02-17-console-updates-1.6.5.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -layout: post -title: Console Updates- Ubidots, China support, and ux enhancements -date: 2021-02-18 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This release the team added another pre-built integration with Ubidots and extended regional support -for China. In addition, the team completed a number of usability enhancements, including making it -easier to add Labels to devices, and identify which devices have sent data. - - - -### Features and updates - -- Delivered a pre-built Integration for the Ubidots IoT platform. -- Conforming with LoRaWAN spec: activation event split into join requests and join accepts. -- Added regional support for frequencies used in China (CN470-510). -- More easily manage Label information on the Device page. -- Provided visual indicators to identify connected devices on Device and Label pages (green dot), - and devices without Labels (faded and None in Labels column). -- Updated quick action menus to be consistent across Console. -- Made the left-hand menu togglable to increase work area. -- Improved usability to attach multiple Labels to devices. -- Provided a footer with quick links to resources. - -### Fixes - -- Addressed an issue related to API keys disappearing when switching Organizations. -- Updated the Adafruit IO template and ensured it appears when choosing the default template for - Adafruit IO. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Release Console and its backend network server and blockchain components (Router) as open source. -- Continue to add Asian regional support (AS1, AS2). -- Ability to view and clear Downlink queue. -- Update the Event log to include more LoRaWAN-related information. -- Continue to add functionality to Flows (beta) -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack. diff --git a/devblog/2021-02-19-minor-blockchain-release.mdx b/devblog/2021-02-19-minor-blockchain-release.mdx deleted file mode 100644 index a3dd8d5f2..000000000 --- a/devblog/2021-02-19-minor-blockchain-release.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Update' -date: 2021-02-19 11:34 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new minor release tagged `2021.02.18.0` which contains a regular maintenance update -with a snapshot bump. - - - -### [miner#641](https://github.com/helium/miner/pull/641): Bump Snapshot - -We have updated the snapshot block to `725761` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.02.18.0` since February 18th, 2021 2:00 PM PT. Current ETA for GA is -12:30 PM PT, February 19th, 2021. diff --git a/devblog/2021-02-24-app-version-300.mdx b/devblog/2021-02-24-app-version-300.mdx deleted file mode 100644 index bdd4cd26b..000000000 --- a/devblog/2021-02-24-app-version-300.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -layout: post -title: App Version 3.0.0 -date: 2021-02-24 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 3.0.0 A Brand New App! - -After months of waiting, we’re so happy to announce the new version of the Helium Hotspot app is -here! Version 3.0 introduces a whole new design and introduces a new way to interact with the app. -Gone are the days of scrolling for hours toiling over challenges (we have Explorer for that!). - - - -We go into a bit more detail in our -[blog here](https://blog.helium.com/a-brand-new-app-for-hotspots-969956630ef9), and some -[background](https://blog.helium.com/an-evolution-of-the-helium-app-fc3fa52f77d5?source=collection_home---4------15-----------------------) -on why we decided to go this direction. - -### New Languages! - -As part of the Network expansion into Asia, we now support Chinese, Japanese, and Korean. Other -languages coming soon. - -### New Makers! - -The app now allows you to select new Hotspots like Nebra and Syncrobit. Get excited! - -# Download Now - -Remember to write down your 12 words as a backup before upgrading! Reveal your words in the More -menu > Reveal words. The new app is available for download on for -[iOS](https://apps.apple.com/us/app/helium-hotspot/id1450463605) and -[Android](https://play.google.com/store/apps/details?id=com.helium.wallet&hl=en_US&gl=US) today. - -# Known Issues - -There are a few known issues that the team are working hard to fix and will deploy in the next few -days. - -1. Adding a Hotspot to an account with 0 HNT gives an infinite loading Wallet screen (#284) - - Workaround: Make sure you have >0 HNT balance in the wallet -2. Sending your entire account balance (using Send Max) shows a black screen after sending (#285) - - Workaround: close the app and reopen. The transaction will succeed. diff --git a/devblog/2021-02-24-minor-blockchain-release.mdx b/devblog/2021-02-24-minor-blockchain-release.mdx deleted file mode 100644 index 97d632edb..000000000 --- a/devblog/2021-02-24-minor-blockchain-release.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Seed IPs and Snapshot Update' -date: 2021-02-23 15:23 -0800 -hide_table_of_contents: true -authors: [abhay, evanmcc] ---- - -The team has a new minor release tagged `2021.02.23.0` which contains a regular maintenance update -with an update to the seed nodes and a snapshot bump. - - - -### [miner#648](https://github.com/helium/miner/pull/648): Update Seed IP addresses - -We have updated the list of seed node IP addresses to match with the new nodes that were brought -online this week. These new nodes should improve relay connectivity for miners behind firewalls/NAT. -Apologies for the emergency firmware release, old seed node infrastructure forced an IP change, the -new IP addresses can be reassigned to different instances, which should keep this kind of thing from -happening in the future. - -### Bump Snapshot - -We have updated the snapshot block to `733681` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.02.23.0` since February 23rd, 2021 4:00 PM PT. Current ETA for GA is -7:00 PM PST, February 23th, 2021. diff --git a/devblog/2021-02-26-blockchain-release-minor-region-updates-erlang-upgrade-and-snapshot-update.mdx b/devblog/2021-02-26-blockchain-release-minor-region-updates-erlang-upgrade-and-snapshot-update.mdx deleted file mode 100644 index c79a22d25..000000000 --- a/devblog/2021-02-26-blockchain-release-minor-region-updates-erlang-upgrade-and-snapshot-update.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Minor Region Updates, Erlang Upgrade, and Snapshot Update' -date: 2021-02-26 13:02 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new release tagged `2021.02.26.0`. This is mostly minor from a Hotspot owner -perspective but there are some major infrastructural improvements which will help us continue to -maintain the code base including an upgrade to Erlang/OTP 23. We also included some region updates -and a snapshot bump. - - - -### Support Erlang/OTP 23 - -Most of the miner and blockchain code base uses Erlang so this is a much needed upgrade to the next -version of Erlang/OTP. We are now able to run on OTP 23 and anticipate upgrading to OTP 24 when it -is released soon. This required changes to many of the repositories including miner, -blockchain-core, and other dependencies. - -### Build changes to support new architectures - -Thanks to the efforts of community member `@jerm#0817` (Discord) / -[`@ke6jjj`](https://github.com/ke6jjj) we've been able to land several updates to dependencies to -enable compilation of our blockchain on FreeBSD and the Apple M1. Thanks! - -### [miner#652](https://github.com/helium/miner/pull/652) Support Cayman Islands - -Thanks to community member [`@w0ts0n`](https://github.com/w0ts0n) who added support in miner for the -Cayman Islands. I _cyah_ wait to see the network grow! - -### [miner#640](https://github.com/helium/miner/pull/640) Support North Macedonia - -We also added support for North Macedonia so hotspots can use the EU868 frequency range. - -### [miner#656](https://github.com/helium/miner/pull/656) Bump Snapshot - -We have updated the snapshot block to `738001` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### [blockchain-core#732](https://github.com/helium/blockchain-core/pull/732) Speedup Ledger CLI - -Small update to help speed up a useful commandline interface that miner operators will appreciate. - -### [hbbft#61](https://github.com/helium/hbbft/pull/61) Test Improvements - -Welcome to the team [`@xandkar`](https://github.com/xandkar). First merge that made it to -production! - -### Plan - -We have been beta testing `2021.02.26.0` since February 26rd, 2021 1:30 PM PT. Current ETA for GA is -3:00 PM PST, February 28th, 2021. diff --git a/devblog/2021-03-01-app-version-301.mdx b/devblog/2021-03-01-app-version-301.mdx deleted file mode 100644 index dfd667b0d..000000000 --- a/devblog/2021-03-01-app-version-301.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -layout: post -title: App Version 3.0.1 -date: 2021-03-1 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 3.0.1 New Features - -New Features: - -1. See Hotspots around you - -- Tap on them to view their mining details and stats - -2. Show the time period when scrubbing charts on Hotspot Details - -3. Make addresses compatible on the Network selectable: either copy to clipboard or open in explorer - - - -### Bug Fixes - -- when the account balance ends in .000000, it showed undefined -- activity lists consistently stayed loading for new accounts -- Android: fix black screen after sending a payment transaction -- update wallet activity when new blocks come in so pending transactions clear as expected -- update caret spacing in notifications -- Add support for Bobcat Miner 300 -- fix transfer hotspot nonce issue plus update pending transfer notification -- Update hotspot filter list for offline hotspots and remember last selected option between app - loads -- Android: screenshots and screen recording re-enabled -- Forget Wi-Fi when previously connected network is no longer discoverable -- improve seed phrase legibility when accessibility options are enabled on users’ devices -- Update error message when a Hotspot cannot be found on the Onboarding Server -- improve UX of opening Hotspot Details (Expanded) - -### Upcoming in 3.0.2 - -- Skip assert location in Onboarding Flow diff --git a/devblog/2021-03-02-blockchain-release-performance-and-maintenance-update.mdx b/devblog/2021-03-02-blockchain-release-performance-and-maintenance-update.mdx deleted file mode 100644 index 0ebe9f7b9..000000000 --- a/devblog/2021-03-02-blockchain-release-performance-and-maintenance-update.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Performance and Maintenance Update' -date: 2021-03-02 10:09 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new release tagged `2021.03.02.2`. This release collects several performance and -maintenance upgrades to the blockchain that should improve stability and performance of members of -the Consensus Group. We also included a few code changes that will support Light Hotspots in the -future, a bugfix for oracle prices our testnet chain, and snapshot bump. - - - -### Plan - -We have been beta testing `2021.03.02.2` since March 2nd, 2021 1:00 PM PT and have been testing -prior versions since 11 AM PT today. Current ETA for GA is 1:45 PM PST, March 2nd, 2021. diff --git a/devblog/2021-03-04-blockchain-update-proof-of-coverage-update.mdx b/devblog/2021-03-04-blockchain-update-proof-of-coverage-update.mdx deleted file mode 100644 index 44eab3c97..000000000 --- a/devblog/2021-03-04-blockchain-update-proof-of-coverage-update.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: post -title: 'Blockchain Update: Proof of Coverage Update' -date: 2021-03-04 16:44 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new release tagged `2021.03.05.0`. This release collects some small but important -maintenance upgrades to the blockchain but primarily is focused on adding a new functionality to the -Proof of Coverage system. We also included a few code changes that will support Light Hotspots in -the future and snapshot bump. - - - -### Proof of Coverage Updates - -The Proof of Coverage system, as many of you are aware, rewards Hotspots for being correctly -asserted and provide coverage for IoT devices that use the Helium network. It is the primary -incentive for Hotspot placement. This update adds a new feature that allows blockchain participants -to evaluate the quality of coverage that is being provided by Hotspots. This system needs to -continuously be updated to ensure that good providers continue to be rewarded and reduce the impact -of poor placement and bad actors in the network. - -We've introduced a new way for Hotspots to be identified on chain through the hash of the Hotspot's -IP address. The new field is associated with a chain variable `poc_addr_hash_byte_count` that will -need to be activated for this system to be used. Roughly speaking, the Challenger will hash the IP -address it sees from the challengee and attach it to the receipt. Future Challengers will be able to -inspect all receipts in the last PoC interval, see if the IP address has already been challenged, -and skip them. - -#### How will this impact me and my participation in Proof of Coverage? - -Correctly asserted Hotspots on individual IP addresses will see no impact. - -If your Hotspot is affected, you may see a reduction in Challenge rate and your Witnesses will see a -reduction in Witness rate. If you see a reduction in Witness rate, you may notice that the Challenge -rate of your neighbors is reduced. - -The filtering is done over a single PoC interval (which is currently set at 240 blocks), and, as -always, we recommend correctly asserting your location. This is an enhancement to existing radio -based filtering and upcoming work on FSPL-based judgements. - -### Plan - -We have been beta testing `2021.03.05.0` and its predecessor `2021.03.04.0` since March 4th, 2021 -5:00 PM PT. Current ETA for GA is 1:00 PM PST, March 5th, 2021. The chain variable that will -activate the address hash will be activated early next week, likely Monday, March 8th, 2021 around -11:00 AM PST. diff --git a/devblog/2021-03-04-console-updates-1.7.0.mdx b/devblog/2021-03-04-console-updates-1.7.0.mdx deleted file mode 100644 index e9eb6fea4..000000000 --- a/devblog/2021-03-04-console-updates-1.7.0.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: post -title: Console Updates- Open Source, Asia, and Datacake integration -date: 2021-03-05 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -We’re excited to announce the release of Helium Console under the Apache 2.0 license. Console joins -a growing list of Helium open source projects including blockchain core, the wallet, the blockchain -explorer, the Helium app and others - - - -To host your own version of Console, the github repository is -[here](https://github.com/helium/console) and documentation can be found -[here](https://docs.helium.com/use-the-network/run-a-network-server). - -The team also added support for Asian countries, as well as adding another prebuilt integration with -leading IoT platform Datacake. - -### Features and updates - -- Released Console as open source to increase decentralization and accelerate usage -- Regional support for Asia, specifically AS920-923 (“AS1”) and AS923-925 (“AS2”), opening up the - biggest region in the world, to the world’s largest public IoT network -- Delivered Datacake pre-built integration allowing Datacake community to start using The People’s - Network in a few clicks. -- Added associated integrations and functions on individual device pages for increased visibility - and easier management. - -### Fixes - -- Addressed an issue that prevented using a server IP address with integrations. -- Pushed a patch that resolved issues with the live data graph. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Downlink management capabilities -- Update Event log to include more LoRaWAN-related information. -- Continue to add regional support (Australia) -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack. -- Update Console core design based on Flows (beta) feedback diff --git a/devblog/2021-03-08-firmware-reliability-fix.mdx b/devblog/2021-03-08-firmware-reliability-fix.mdx deleted file mode 100644 index e36eba1d8..000000000 --- a/devblog/2021-03-08-firmware-reliability-fix.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Hotspot Firmware and Reliability Fixes -date: 2021-03-08 16:44 -0800 -hide_table_of_contents: true -authors: [cokes518] ---- - -The team has a new release tagged `2021.03.08.0`. This release includes a fix to Hotspot firmware -where onboarding keys were incorrectly generated, a snapshot bump to `750241`, and several -reliability fixes that were identified in our Validators Testnet. - - - -### Hotspot Firmware Update [miner#679](https://github.com/helium/miner/pull/679) - -Release `2021.03.04.0` included a fix for Hotspots crashing early on boot because it would fail to -get the onboarding key. The fix inadvertently caused a new onboarding key to be generated if there -was none found. This is not the correct logic for Hotspots, since the onboarding key is the public -key of the Hotspot. - -This meant that when a user tries to onboard a Hotspot with this firmware image (can happen if they -leave it connected to internet and it received an OTA before they `add_hotspot`), they will get an -onboarding error message. - -The fix is to no longer generate a key if none exists. - -### Consensus Group Reliability Updates - -Several improvements have been backported from the validators branch including reductions of -CPU/memory use due to better garbage collection of old consensus and election groups as well as a -fix to eject bad nodes from the consensus group when proposing a new consensus group. These -improvements should lead to smoother block and election times. - -### Plan - -We have been beta testing `2021.03.08.0 ` since March 8th, 2021 11:00 AM PT. Current ETA for GA is -March 8th, 2021 2:00 PM PT. diff --git a/devblog/2021-03-11-app-version-302.mdx b/devblog/2021-03-11-app-version-302.mdx deleted file mode 100644 index 0e2de8e2c..000000000 --- a/devblog/2021-03-11-app-version-302.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: App Version 3.0.2 -date: 2021-03-11 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 3.0.2 New Features - -New Features: - -1. Explore Hotspots around you if you don’t own hotspots -2. Express HNT to your local currency with CoinGecko. Tap on your HNT balance to toggle between - display options. Note that data uses current $HNT. -3. Option to disable haptic feedback - - - -### Bug Fixes - -- Move Hotspot Settings to be less hidden -- Fix duplicate month issue when viewing account changes over 12 months -- Zoom to fit witness map -- Adjust maximum font size for small screened devices -- Fix for Assert Location if you skipped during onboarding diff --git a/devblog/2021-03-17-rak-firmware-issue-2.mdx b/devblog/2021-03-17-rak-firmware-issue-2.mdx deleted file mode 100644 index 9656753db..000000000 --- a/devblog/2021-03-17-rak-firmware-issue-2.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -layout: post -title: RAK Firmware Issue (March 2021) -date: 2021-03-17 -hide_table_of_contents: true -authors: [cokes518, madninja] ---- - -  - -# RAK Hotspot Miner Firmware Issue - -We have discovered an issue, this week, that affects a number of RAK Hotspot Miners shipped by -Cal-Chip to customers starting January 2021 until today (the "Dolphin" batch, up to order #2999). -This issue is the -[same as November’s discovery](https://engineering.helium.comhttps://docs.helium.com/blog/2020/11/06/blockchain-release-rak-miner-updates.html). - - - -**This issue affects approximately 20% of RAK Hotspot Miners shipped between January 2021 and today -(including the Dolphin batch).** - -Similar to the issue found in November 2020, the RAK Hotspot Miner is unable to update to the latest -firmware image because of a floating pin, which causes the Hotspot to believe the reset button is -being pressed. This prevents the Hotspot from running the latest firmware update and cannot sync. We -fixed the issue when found but it was not adapted on the manufacturing line by the RAKWireless team. - -If your RAK Hotspot Miner is affected, these are the likely symptoms: - -- It will be stuck on a firmware image from December 2020 -- It cannot sync/stuck syncing -- It will not mine - -RAK Hotspot Miners with this issue will typically fix itself after two OTA cycles, but in the event -it doesn’t, the Helium team is taking the following steps: - -1. RAKWireless will no longer use the old firmware image from December 2020 -2. Cal-Chip will make sure the latest firmware is flashed on SD cards before shipping to customers. - This will include the current "Dolphin" batch (order #3000 onward) and future batches starting - with "Eagle". -3. Helium will create a script to check the batch of on-chain RAK Hotspot Miners to make sure it has - the latest image. If it doesn’t, then it will perform a fix to make sure it has the latest image. - This script will only run if the Hotspot is powered on and connected to the internet. - -This does not affect: - -- Helium Hotspots -- RAK Hotspot Miners shipped before January 2021 -- RAK Hotspot Miners shipped after March 17 2021 -- Nebra, Syncrob.it, or Bobcat Hotspots diff --git a/devblog/2021-03-18-console-updates-1.7.5.mdx b/devblog/2021-03-18-console-updates-1.7.5.mdx deleted file mode 100644 index 6b3d9e08e..000000000 --- a/devblog/2021-03-18-console-updates-1.7.5.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -layout: post -title: Console Updates- Events, Australia, and Tago.IO integration -date: 2021-03-18 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -G’day mates. In addition to support for Australia 🇦🇺 (AU915), significant work to improve both the -accuracy and scalability of events was completed. We also added a pre-built integration for the -Tago.IO IoT platform. - - - -### Features and updates - -- Added regional support for Australia (AU915) -- Delivered a pre-built integration for the Tago.io IoT platform. -- Updated event logs so events received with more precise timing (milliseconds), and additional - integration request and response details. Also, the foundation has been laid to add LoRaWAN - information to events in future releases for additional insights about packets. -- Provided ability to show/hide dropped uplinks either due to late arriving packets, or inactive - devices. -- Included an update to prevent accidental deletion of an organization: requires both name of - organization and DELETE. -- App key now masked during add device process. - -### Open source users - -- For new users, simply use the latest master version. - -- For existing users, you also need to pull down the latest master version, build, and restart. The - database will remain intact, devices will continue to send data, and the new migrations will get - merged into it. We moved from seconds to milliseconds, the previous event data will be purged, and - device packets and counters will be reset. - -### Fixes - -- Increased the length state channels remain open to mitigate blockchain issues. -- Deleted device using top right button correctly removed from Device table upon redirect. -- Updated Downlink tooltip to match buttons. -- Default p2p seeds were updated. -- Improved device tracing. -- Added CLI to query block aga (similar to miner). -- Updgarded blockchain core to `2021.03.09.0`. -- Mark late delivered packets (from offer to packet) as "late". -- Fixed packet multi-buy to accruately purchase the correct number of packets. -- Fixed devaddr sorting which resolves issues related to routing packets with devices that had the - same devaddr. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Downlink management capabilities -- Add more LoRaWAN-related information to event log details. -- Finalize module to integrate with other LoRaWAN network servers, initially ChirpStack. -- Update Console core design based on Flows (beta) feedback. diff --git a/devblog/2021-03-18-minor-blockchain-release-snapshot-bump-and-address-hash-adjustment.mdx b/devblog/2021-03-18-minor-blockchain-release-snapshot-bump-and-address-hash-adjustment.mdx deleted file mode 100644 index 98f83f114..000000000 --- a/devblog/2021-03-18-minor-blockchain-release-snapshot-bump-and-address-hash-adjustment.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Minor Blockchain Release: Address Hash Adjustment and Snapshot Bump' -date: 2021-03-18 12:24 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new minor release tagged `2021.03.18.0` which contains a regular maintenance update -with a snapshot bump and a minor update to the address hash. - - - -### [miner#697](https://github.com/helium/miner/pull/697): Minor Address Hash Update - -We have made a minor tuning change to the bloom filter introduced in a prior release. We've slightly -adjusted the false positive rate out of an abundance of caution but don't expect this to have any -impact to address hash identification. - -### Bump Snapshot - -We have updated the snapshot block to `764641` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.03.18.0` since March 18th, 2021 12:20 PM PT. Current ETA for GA is -3:00 PM PT, March 18th, 2021. diff --git a/devblog/2021-03-19-maker-update-march/index.mdx b/devblog/2021-03-19-maker-update-march/index.mdx deleted file mode 100644 index 2d8654b2e..000000000 --- a/devblog/2021-03-19-maker-update-march/index.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: Maker Progress Update -date: 2021-03-19 -hide_table_of_contents: true -authors: [cokes518] ---- - -## Maker Update - -Since the last update in February, Makers Nebra, Syncrob.it and Bobcat have concluded their Audit. - - - -We also have an additional Maker, Kerlink, recently approved to add to the Audit Status table. - -A summary of how a Maker goes from HIP19-approved to market: - -1. Makers submit a HIP. -2. DeWi and Community approve. -3. Makers send hardware samples for Audit. -4. Once Makers pass hardware audit, they are allowed to proceed to Network Integration. -5. The final stage of Network Integration is being able to add Hotspots to the Blockchain. - -## Audit Status (Current as of March 19, 2021) - -**Results of the Audit are based on samples provided at start of audit.** - -![maker-update-3-19](./maker-update-3-19.png) diff --git a/devblog/2021-03-19-maker-update-march/maker-update-3-19.png b/devblog/2021-03-19-maker-update-march/maker-update-3-19.png deleted file mode 100644 index 243618ad0..000000000 Binary files a/devblog/2021-03-19-maker-update-march/maker-update-3-19.png and /dev/null differ diff --git a/devblog/2021-03-22-minor-blockchain-release-country-additions-and-snapshot-update.mdx b/devblog/2021-03-22-minor-blockchain-release-country-additions-and-snapshot-update.mdx deleted file mode 100644 index 2ebfc9b87..000000000 --- a/devblog/2021-03-22-minor-blockchain-release-country-additions-and-snapshot-update.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: 'Minor Blockchain Release: Country Additions and Snapshot Update' -date: 2021-03-22 13:12 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new minor release tagged `2021.03.22.0` which contains a regular maintenance update -with an update to the countries supported by the miner codebase and a snapshot bump. - - - -### Several country additions - -We've added 105 new countries to the list of countries supported by the miner codebase. You can see -specific updates -[here](https://github.com/helium/miner/commit/0be57098e3c28700b3724f752f7b0d779710d5d2). Thanks to -[@shawaj](https://github.com/shawaj) and others in the community for these updates. - -### Bump Snapshot - -We have updated the snapshot block to `770401` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.03.22.0` since March 22nd, 2021 2:15 PM PT. Current ETA for GA is -3:30 PM PT, March 22nd, 2021. diff --git a/devblog/2021-03-23-app-version-303.mdx b/devblog/2021-03-23-app-version-303.mdx deleted file mode 100644 index a849d78ff..000000000 --- a/devblog/2021-03-23-app-version-303.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: App Version 3.0.3 -date: 2021-03-23 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 3.0.3 Improvements - -Show which Maker paid for the Add Hotspot and Assert Location transaction - - - -- Now when you add a Hotspot or assert location and the Maker paid on your behalf, we show the name. - Show Hotspot sync percentage in Hotspot list -- Similar to Explorer, we show how much more your Hotspot has to go to reach 100% Do not let - transfer proceed if it fails staleness check -- Hotspots need to have active PoC activity (witness, beacon, or challenge) in the last 1200 blocks - to be transferred. This prevents bad actors selling dead Hotspots. Rescan for Wi-Fi networks -- During onboarding and in settings, some Hotspots may take a while to load their Wi-Fi network - list. By allowing users to refresh from the app, they can get the latest list without re-pairing. - Custom Picker component -- We've customized the picker that appears in dropdowns for a more seamlined experience. - -### Bug Fixes - -Fetch oracle price when user presses send on payment - -- The app now fetches the oracle price on the payment screen instead of loading on app start. This - allows us to calculate transaction fees at the time of payment. This bug is most visible during - volatile oracle price changes and users are attempting to send the balance of their wallet. - Burning HNT to DC issue in non-US locale diff --git a/devblog/2021-03-25-blockchain-release-rewards-v2.mdx b/devblog/2021-03-25-blockchain-release-rewards-v2.mdx deleted file mode 100644 index adb06d26d..000000000 --- a/devblog/2021-03-25-blockchain-release-rewards-v2.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Rewards v2' -date: 2021-03-25 12:00 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new release tagged `2021.03.24.0` which contains a significant overhaul of the -Rewards transaction and maintenance improvements including a regular snapshot bump. - - - -### [core#751](https://github.com/helium/blockchain-core/pull/751) Rewards v2 - -The bulk of this release is enabling support for a new kind of reward transaction on chain. The -transaction itself has been significantly improved to be smaller, more efficiently produced, and -easier to gossip to nodes on the network (due to size). As more Hotspots come online and validators -are introduced to the network, the rewards transaction becomes a bottleneck on the network's ability -to produce blocks and becomes a more significant component to ledger size. We have not made any -changes to the calculation of rewards so there will be no impact to actual rewards issued on the -network. - -### Bump Snapshot - -We have updated the snapshot block to `774001` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.03.24.0` since March 24th, 2021 5:15 PM PT. Current ETA for GA is -2:00 PM PT, March 25th, 2021. - -The Rewards v2 transaction will not be used on chain until a chain variable is issued on chain, -likely early next week. This will require an upgrade by all blockchain participants before chain -variable activation. We will be updating all downstream projects, including `blockchain-etl` and -`blockchain-node`, and updating Docker images when `2021.03.24.0` is released to GA. diff --git a/devblog/2021-03-26-minor-blockchain-release-performance-and-snapshot-update.mdx b/devblog/2021-03-26-minor-blockchain-release-performance-and-snapshot-update.mdx deleted file mode 100644 index 8fcc7e050..000000000 --- a/devblog/2021-03-26-minor-blockchain-release-performance-and-snapshot-update.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Minor Blockchain Release: Performance and Snapshot Update' -date: 2021-03-26 12:46 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new minor release tagged `2021.03.26.0` which contains a regular maintenance update -with an improvement to the performance of distributed key generation used in consensus and a -snapshot bump. - - - -### [dkg#35](https://github.com/helium/erlang-dkg/pull/35) DKG Performance Improvement - -We identified an improvement to the distributed key generation protocol used by Consensus Group that -has been working well on the Testnet and are prepared to port it to Mainnet. - -### Bump Snapshot - -We have updated the snapshot block to `776161` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.03.26.0` since March 26th, 2021 12:00 PM PT. Current ETA for GA is -3:00 PM PT, March 26th, 2021. diff --git a/devblog/2021-03-31-console-updates-1.8.0.mdx b/devblog/2021-03-31-console-updates-1.8.0.mdx deleted file mode 100644 index 15e4ccce9..000000000 --- a/devblog/2021-03-31-console-updates-1.8.0.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -layout: post -title: Console Updates- Backend fixes, Debug mode, and Event updates -date: 2021-04-01 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The team made a number of core backend fixes related to downlinks, and initial device joins. Debug -mode, and the event log also received updates. - - - -After this release we’ll move to a three-week release cycle. While we’ll continue two-week sprints, -an additional week will be used for testing both internally and with third parties. - -This extended-release cycle is part of our move to increase quality of releases and requires -building a three-tier development environment which includes: dev, staging, and production. - -### Features and updates - -- Debug mode updates: more descriptive headers, only displays relevant information categories, and - position viewing events is kept constant as more events appear. -- Event log exports up to a limit of 1440 events in JSON format not just those displayed. -- Provided a visual way to identify if a device does not have an integration attached in the event - log. -- Join accept events are consistent with colors used to represent downlinks. - -### Fixes - -- Provided an update to make sure downlink information was correctly reported. -- Included internal communication when downlinks are dropped. -- Increased accuracy to identify correct devaddrs. -- Provided a patch to help make initial device joins more consistent. -- Addressed race condition with multi-packet purchase. -- Tightened tests on data fields, including _reported at_ field. -- Fixed Console email formatting issues for certain mail clients and screen sizes. - -### Open source users - -- New users use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. To update, check the - newest instructions, rebuild, and restart. The database is not affected. - -Documentation [here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Discovery mode support for Hotspots -- Build and adopt infrastructure for a three-tier development environment -- Downlink management capabilities -- Update Event log to include more LoRaWAN-related information. -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack. -- Add a prebuilt integration for Google Sheets -- Update Console core design based on Flows (beta) feedback diff --git a/devblog/2021-04-02-blockchain-release-assertv2.mdx b/devblog/2021-04-02-blockchain-release-assertv2.mdx deleted file mode 100644 index 22e5f77d0..000000000 --- a/devblog/2021-04-02-blockchain-release-assertv2.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Assert v2, Performance, and Snapshot Update' -date: 2021-04-02 17:45 -0700 -hide_table_of_contents: true -authors: [cokes518, evanmcc] ---- - -The team has a new release tagged `2021.04.02.0` which contains a regular maintenance update with a -support for assert_location_v2 and a snapshot bump. - - - -### [blockchain#519](https://github.com/helium/blockchain-core/pull/519) Assert Location v2 - -Feature work to allow remote assert location and the addition of two new values on chain (gain and -elevation). This feature is gated behind 3 chain variables, and activation will be announced next -week. - -### Hardware Support - -Added identifiction and support for 4GB Raspberry Pis. - -### Miner/Blockchain Updates - -Minor stability improvements to snapshot loading and startup improvements for low-memory units. - -### Bump Snapshot - -We have updated the snapshot block to `786241` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.04.02.0` since April 2st, 2021 4:00 PM PT. Current ETA for GA is -10:00 AM PT, April 3nd, 2021. - -**UPDATE:** Due to a stable situation and light operator coverage, we are postponing GA until early -morning PT on April 5th, 2021. If the situation worsen or operators become available we may GA -before then. diff --git a/devblog/2021-04-05-minor-miner.mdx b/devblog/2021-04-05-minor-miner.mdx deleted file mode 100644 index c07eacd57..000000000 --- a/devblog/2021-04-05-minor-miner.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Emergency Miner Release' -date: 2021-04-05 14:26 -0700 -hide_table_of_contents: true -authors: [cokes518] ---- - -The team has a new minor release tagged `2021.04.05.0` which contains a minor bug fix that caused -the miner to restart every few hours, plus a snapshot bump. - - - -### [miner#721](https://github.com/helium/miner/pull/721) Miner Update - -### [blockchain#767](https://github.com/helium/blockchain-core/pull/767) State Channel Update - -A fix to how State Channels garbage collection works that causes the miner to unnecessarily restart. - -### Bump Snapshot - -We have updated the snapshot block to `790561` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.04.05.0` since April 5th, 2021 3:30 PM PT. Current ETA for GA is -5:15 PM PT, April 5th, 2021. diff --git a/devblog/2021-04-06-api-retrospective/banner.png b/devblog/2021-04-06-api-retrospective/banner.png deleted file mode 100644 index ea073a1a1..000000000 Binary files a/devblog/2021-04-06-api-retrospective/banner.png and /dev/null differ diff --git a/devblog/2021-04-06-api-retrospective/index.mdx b/devblog/2021-04-06-api-retrospective/index.mdx deleted file mode 100644 index 7273ff66a..000000000 --- a/devblog/2021-04-06-api-retrospective/index.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: post -title: 'API Outage Retrospective' -date: 2021-04-06 14:26 -0700 -hide_table_of_contents: true -authors: [cokes518] ---- - -## April 4-6 API Outage Retrospective - -Starting on April 4, our daily active users (DAU) on -[Helium Explorer](https://explorer-old.helium.com) doubled from 15,000 to 30,000. As a result, the -API services that Explorer relies on was unable to handle the additional load. The reason for this -cannot be fully attributed to DAU, but rather a symptom of the root cause. This API is used by -multiple services including the Explorer, Helium App, and Wallet CLI. Many third party services also -depend on this API. - - - -### Root Cause: - -In the development of Explorer and the Helium App, we rapidly deployed new features that gave -insight to new users to the network. Useful information such as daily rewards, rewards overtime, and -Hotspot checklists, were not optimized for scale. - -This, in addition to creating a system where anyone can query the API, resulted in many community -API calls that queried computationally expensive endpoints, like `/stats`, `/rewards/sum`, -`/hotspots`, and `/accounts`, that the API could not handle at scale. - -As more users navigated to Explorer, these expensive API calls grew exponentially, and created the -outage. This is colloquially known as a thundering herd. - -### What we’ve done: - -- Scaled up several instances of our API services and added load balancing across all services. -- Changed how queries from Explorer and Helium App are handled. -- Either removed features or show on request to ease the load on the API for both Explorer and app. - We will reoptimize the features and relaunch them. - -## Hidden features: - -- 1 year earnings chart for Hotspots -- Hotspot Checklist in Helium App - -## By request: - -- Hotspot Checklist in Explorer - -## Additional Communication: - -We’ve added a Network Status banner notification in the Helium app that appears when an incident is -reported. This update is available in 3.0.6. - -![banner](./banner.png) - -We’ve created a twitter bot [@helium_status](https://twitter.com/helium_status) to automatically -tweet incidents and updates from our [status page](https://status.helium.com). diff --git a/devblog/2021-04-08-minor-blockchain-release-fix-snapshots.mdx b/devblog/2021-04-08-minor-blockchain-release-fix-snapshots.mdx deleted file mode 100644 index f47b759e3..000000000 --- a/devblog/2021-04-08-minor-blockchain-release-fix-snapshots.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Minor Blockchain Release: Fix Snapshots' -date: 2021-04-08 16:10 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new minor release tagged `2021.04.08.0` which contains a minor bug fix that addresses -an issue that prevented snapshots from being generated by the chain. We are deploying this change -today so that we can do a subsequent bump of the snapshot tomorrow. A list of other minor changes -are below. - - - -#### Related PRs - -- _Fix snapshots_ - This update fixes snapshot creation. - - [blockchain-core/770](https://github.com/helium/blockchain-core/pull/770) -- _Fix libp2p session close_ - Update to blockchain-core to include libp2p session close fix. - - [blockchain-core/769](https://github.com/helium/blockchain-core/pull/769) -- _Fix direction tracking_ - Typo fix to correctly determine outbound session. - - [erlang-libp2p/331](https://github.com/helium/erlang-libp2p/pull/331) - -### Plan - -We have been beta testing `2021.04.08.0` since April 8th, 2021 3:00 PM PT. Current ETA for GA is -5:00 PM PT, April 8th, 2021. diff --git a/devblog/2021-04-09-minor-blockchain-release-libp2p-fixes-and-snapshot-update.mdx b/devblog/2021-04-09-minor-blockchain-release-libp2p-fixes-and-snapshot-update.mdx deleted file mode 100644 index c11907cf5..000000000 --- a/devblog/2021-04-09-minor-blockchain-release-libp2p-fixes-and-snapshot-update.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Minor Blockchain Release: libp2p Fixes and Snapshot Update' -date: 2021-04-09 08:22 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The team has a new minor, but urgent, release tagged `2021.04.09.0` which contains a bug fix to -libp2p. A latent bug was uncovered when we fixed another issue with the prior release. We are also -updating the snapshot with this release. - - - -#### Related PRs - -- _Check we have an inbound connection in stungun in the correct place_ - - [erlang-libp2p/332](https://github.com/helium/erlang-libp2p/pull/332) - -### Bump Snapshot - -We have updated the snapshot block to `796321` to allow newly onboarded hotspots to sync faster to -the current blockchain head block. - -### Plan - -We have been beta testing `2021.04.09.0` since April 9th, 2021 8:00 AM PT. Current ETA for GA is -10:00 AM PT, April 9th, 2021, or sooner. diff --git a/devblog/2021-04-12-fix-more-v1s.mdx b/devblog/2021-04-12-fix-more-v1s.mdx deleted file mode 100644 index 92f47c426..000000000 --- a/devblog/2021-04-12-fix-more-v1s.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: More Memory Fixes and a Snapshot Update -date: 2021-04-12 13:30 -0700 -hide_table_of_contents: true -authors: [evanmcc, abhay] ---- - -The team has a new release tagged `2021.04.12.0` which contains a some fixes that should allow older -Hotspots to keep consuming the chain, as well as a snapshot bump. - - - -### [blockchain#773](https://github.com/helium/blockchain-core/pull/772) Fix Snapshot Generation on Older Hardware - -Normally we don't spend a lot of time discussing the minor details of these releases, but one of the -reasons that we've done a lot of them in the past two weeks is that older units are having more and -more issues validating the chain as more Hotspots join the network. Mostly this takes the form of -the older hardware running out of memory on startup, which loops forever. We take this sort of thing -quite seriously, and it motivates a lot of recent work on our coming shift to Validator servers -instead of running the Consensus Group on individual Hotspots. Several fixes in the past two weeks -have contained fixes for these low memory units and all have helped, but have not completely -eliminated the problem. - -This particular fix limits the number of attempts to generate a snapshot which, in our testing, -shows is a major point of failure on units with less RAM. - -### Bump Snapshot - -We have also updated the snapshot block to `800641` to allow newly onboarded hotspots to sync faster -to the current blockchain head block. - -### Plan - -We have been beta testing `2021.04.12.0` since April 12th, 2021 1:15 PM PT. Current ETA for GA is -3:00 PM PT, April 12th, 2021. diff --git a/devblog/2021-04-13-maker-update-april/index.mdx b/devblog/2021-04-13-maker-update-april/index.mdx deleted file mode 100644 index bb3e49283..000000000 --- a/devblog/2021-04-13-maker-update-april/index.mdx +++ /dev/null @@ -1,67 +0,0 @@ ---- -layout: post -title: April Maker Update & A New Process -date: 2021-04-13 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Maker Update - -Here is the latest update from our Makers manufacturing Hotspots for the Helium Network. - - - -## A Better Process for Makers - -DeWi, Makers, and Helium have agreed on an improved process that outlines how a Maker goes from -application to approved - where more of the work is done upfront before it goes to community -approval. - -### The New Process - -Once a Maker submits their intention to be manufacturer of Hotspots via a HIP19 application, Makers -no longer need to wait for community approval before starting hardware audit. By front-loading -technical work (audits and integration) and due diligence (radio certification) and placing -community approval and pre-orders last, the community will be better informed when approving new -Makers and informing purchase decisions. - -Here is a summary of steps that all new Makers will adhere to. - -1. Submit HIP19 Application -2. Hardware Audit\* -3. Onboarding Integration\* -4. FCC, CE, or an equivalent radio certification, depending on regional requirements\* -5. Community Approval -6. Pre-orders Begin - -\*These steps can occur in parallel - -With that, existing Makers already approved will follow the legacy process. This includes Kerlink -that has been community approved but not passed hardware audit. - -## New Makers - -[LongAP One](https://github.com/HeNet/HIP/blob/feature/hip19-henet-application/0019-third-party-manufacturers/henet.md) -is the first Maker to progress through the new process, congratulations! - -[SmartMimic](https://github.com/onterferon/HIP/blob/master/0019-third-party-manufacturers/Smart-Mimic.md) -is well on their way through onboarding integration. Once that’s complete, DeWi will verify -certification and move onward to community approval. - -[RAKwireless](https://github.com/helium/HIP/blob/a23147091130841584950c00f346f2577459d588/0019-third-party-manufacturers/RAKwireless%20-%203rd-party%20manufacturer%20application.md), -a previously approved HIP-19 Maker has shown intention on producing their own Hotspots separate from -CalChip and has submitted hardware for audit. - -[Browan](https://github.com/browanofficial/HIP/blob/patch-1/0019-third-party-manufacturers/Browan-Cellular-Gateway.md), -[Dragino](https://github.com/dragino/HIP/blob/master/0019-third-party-manufacturers/dragino.md), and -[ClodPi](https://github.com/clodpi/HIP/blob/master/0019-third-party-manufacturers/clodpi.md) have -all submitted applications and pending hardware audits. - -## Audit Status (Current as of April 13, 2021) - -**Results of the Audit are based on samples provided at start of audit.** - -![maker-update-4-13](./maker-update-4-13.png) diff --git a/devblog/2021-04-13-maker-update-april/maker-update-4-13.png b/devblog/2021-04-13-maker-update-april/maker-update-4-13.png deleted file mode 100644 index 1d6b9f299..000000000 Binary files a/devblog/2021-04-13-maker-update-april/maker-update-4-13.png and /dev/null differ diff --git a/devblog/2021-04-14-cert-update.mdx b/devblog/2021-04-14-cert-update.mdx deleted file mode 100644 index 8649542a4..000000000 --- a/devblog/2021-04-14-cert-update.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -layout: post -title: OTA Certificate Update -date: 2021-04-14 15:30 -0700 -hide_table_of_contents: true -authors: [cokes518] ---- - -The team has a new release tagged `2021.04.14.0` containing an OTA Server Certificate Update. - - - -The Helium team manages the OTA server infrastructure that issues firmware updates over-the-air to -Helium Hotspots and RAK Hotspot Miners. The server has a signed certificate that enables Hotspots to -verify that it is from a trusted source through mutual authentication. - -This update pushes a new certificate to the Helium Hotspots and RAK Hotspot Miners in preparation -for a server update this week. - -### Plan - -We have been beta testing `2021.04.14.0` since April 14th, 2021 3:15 PM PT. Current ETA for GA is -6:00 PM PT, April 14th, 2021. diff --git a/devblog/2021-04-21-app-version-310.mdx b/devblog/2021-04-21-app-version-310.mdx deleted file mode 100644 index 39e2b9468..000000000 --- a/devblog/2021-04-21-app-version-310.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: post -title: App Version 3.1.0 -date: 2021-04-21 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 3.1.0 New Features - -## Remote Assert - -Remote Assert is finally here! Update your Hotspot's location without being physically next to the -Hotspot, and without Bluetooth pairing! This improved user experience will make it much easier for -Owners and Hosts to set up Hotspots. - - - -Included with Remote Assert is the ability to add your Hotspot's Antenna Gain and Height. Each -Maker's gain is different, and for ease of use, we've added a dropdown of default antenna gains to -select from. If you've got an upgraded antenna, select _Custom_ to enter your antenna's dBi. - -Antenna Gain and Height will eventually be used to inform Proof-of-Coverage and until then, there is -no urgency to provide this information for each Hotspot. - -## Search - -Another new feature this release is the ability to search - a Hotspot or a geographic location. - -Search Hotspot: - -- Start typing to filter down your own Hotspots, or all Hotspots on the Network -- Results will suggest Hotspots matching your input - -Search Location: - -- Start typing a city name to see a list of suggested cities -- Tap on the city to explore deployments in that area - -## Follow a Hotspot - -View any Hotspot and tap the flag icon to follow it. Once followed, Hotspots will appear in the -"Followed Hotspots" filter and you'l be able to see its witnesses, earnings, challenges, and status. -You can even pair with a Hotspot that you follow and run diagnostic reports and update Wi-Fi. - -# Bug Fixes - -- Fix bug where users were unable to Send Max -- Notifications were displaying in the wrong order - that's now fixed diff --git a/devblog/2021-04-21-console-updates-1.8.5.mdx b/devblog/2021-04-21-console-updates-1.8.5.mdx deleted file mode 100644 index 3dd44b3b2..000000000 --- a/devblog/2021-04-21-console-updates-1.8.5.mdx +++ /dev/null @@ -1,72 +0,0 @@ ---- -layout: post -title: Console Updates- Event Log and Downlink Improvements -date: 2021-04-22 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This release was the first with our three-tier development environment and focused on improved -downlink capabilities and provided more details for LoRaWAN MAC commands for uplink events. - - - -### Features and updates - -Event log - -- Added MAC commands for uplink events. -- Included Hotspot column which provides the number of Hotspots that sent packets. -- Added a filter for events with commands. - -Downlink - -- Downlink provides the ability to schedule where a downlink is in the queue (first and last) and - view which downlinks are queued. -- Updated downlink input to make more clear for supported formats (either base64 or plain text). - -Debug mode - -- Included a check box to expand all events. -- Included a flag in the header for events that contain decoded payloads. -- Decoded payload displays among multiple lines. - -Integrations: - -- Provided a visual way to identify if a device's label does not have an Integration attached. -- Made it easier to access existing Integrations. - -Other: - -- Added ability to sort Labels on the Label index page. -- Handle ADRAckReq flag even when Allow ADR is false. -- Included internal metrics for early alerts related to blockchain issues - -### Fixes - -- Users no longer need to need to scroll through the entire list of events when expanded all. -- Downlink no longer shows an error if two or more integrations are attached. -- HTTP integration works even if “&” inside of URL. -- Reduced the number of warnings during the open-source build to avoid confusion. -- Console logs out at session expiration. - -### Open source users - -- New users use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. To update, check the - newest instructions, rebuild, and restart. The database is not affected. - -Documentation [here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Discovery mode support for Hotspot new feature -- Increase accuracy of timestamps -- Add a prebuilt integration for Google Sheets -- Provide docs to help monitor open source Console -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack. -- Update Console core design based on Flows (beta) feedback diff --git a/devblog/2021-04-26-blockchain-release-feature-updates-bug-fixes.mdx b/devblog/2021-04-26-blockchain-release-feature-updates-bug-fixes.mdx deleted file mode 100644 index 61b3c96f2..000000000 --- a/devblog/2021-04-26-blockchain-release-feature-updates-bug-fixes.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Feature Updates & Bug Fixes' -date: 2021-04-26 11:19 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The team has a new release tagged `2021.04.26.1` which contains some new features and bug fixes. -This is a _required_ upgrade for all miners and will be automatic for all Hotspots using the Helium -firmware when we GA. Specifically, this release includes support for Payment Memos which requires a -chain variable to activate and makes this a required release. We don't intend to activate this chain -variable for about a week. Please read further for more details. - - - -### [miner#742](https://github.com/helium/miner/pull/742): Update only snapshot to 819361 - -The team has updated only the snapshot block to `819361` for faster sync to the current blockchain -head block. - -### [miner#737](https://github.com/helium/miner/pull/737): Update dependencies and snapshot to 813601 - -The team updated miner dependencies and the snapshot block to `813601` to allow newly onboarded -hotspots to sync faster to the current blockchain head block. - -### [miner#655](https://github.com/helium/miner/pull/655): Update rebar to v3.14 - -As part of regular maintenance the team has updated the rebar version to 3.14 included in miner -repo. - -### [blockchain-core#785](https://github.com/helium/blockchain-core/pull/785): Better stacktrace for gossip handler crash - -A minor change to allow better error messages when libp2p gossip handler crashes in blockchain-core. - -### [blockchain-core#782](https://github.com/helium/blockchain-core/pull/782): Fix for syncing blockchain-etl - -Some members of the community reported that they had issues syncing blockchain-etl. The team found -the root cause to be an unnecessrary call to lookup the entire chain for previous -`blockchain_txn_poc_request`, this has been fixed to only start searching from the current ledger -height. - -### [blockchain-core#768](https://github.com/helium/blockchain-core/pull/768): Allow memo support for payment transactions - -The team has enabled memo support for payment-v2 transactions. Note that the implementation is a bit -different than proposed in [HIP-26](https://github.com/helium/HIP/issues/125) in the sense that the -only memos the blockchain supports will be 64 bit unsigned integers. - -### [blockchain-core#750](https://github.com/helium/blockchain-core/pull/750): Sync performance improvements - -The team updated the `blockchain_sync_handler` to try adding blocks in a spawned process so that -blocks will continue to be added if a connection drops during sync. This may improve sync times. - -### [blockchain-core#743](https://github.com/helium/blockchain-core/pull/743): Update rebar for blockchain - -As part of regular maintenance the team has updated the rebar version to 3.14 included in -blockchain-core repo. - -### [blockchain-core#733](https://github.com/helium/blockchain-core/pull/733): Add aux-ledger support - -The team added support for an auxiliary ledger to enable better testing of potential future chain -variables and new blockchain features. The aux ledger maintains a copy of the actual on-chain ledger -while allowing the team to test additional chain related changes. - -### [erlang-libp2p#335](https://github.com/helium/erlang-libp2p/pull/335): Manage the stungun timer better - -This update adds a stungun timer reference to `libp2p_transport_tcp` module state and appropriately -handles it. - -### [erlang-libp2p#334](https://github.com/helium/erlang-libp2p/pull/334): Fix fdset race condition - -This change fixes a race condition the team noticed in `libp2p_transport_tcp` module. - -### [erlang-libp2p#333](https://github.com/helium/erlang-libp2p/pull/333): Garbage collect unused processes - -This change adds a process id garbage collection monitor to better handle stale processes in the -`libp2p_swarm_server`. - -### Plan - -We have been beta testing `2021.04.26.1` since April 26th, 2021 12:30 PM PT. Current ETA for GA is -4:00 PM PT, April 26th, 2021. We've been beta testing a prior version `2021.04.22.1` over the -weekend and updated just the snapshot today in order to improve initial sync times for new miners. diff --git a/devblog/2021-04-28-app-version-311.mdx b/devblog/2021-04-28-app-version-311.mdx deleted file mode 100644 index 9b10f636d..000000000 --- a/devblog/2021-04-28-app-version-311.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: App Version 3.1.1 -date: 2021-04-28 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 3.1.1 Improvements and Bug Fixes - -## Updated Hotspot UI - -A modified Hotspot UI that allows for navigating to the next Hotspot in a list, without going back -to the Hotspot tab. - - - -## Push Notifications opens to Notifications tab - -Users will be directed to the Notifications tab when they receive an app push notification. - -## Antenna Gain and Height Bug Fix - -Fixed a bug where some users were unable to submit antenna gain and height unless they pressed Enter -before Submit. This is fixed. - -## Pin Updates - -Added an explicit "Sign Out" label on the PIN page to avoid accidentally signing out while pressing -Cancel. - -# Known Issues - -Some users may see an empty Notifications tab after initiating the app. This will be fixed in 3.1.2, -and the work around is to wait a few more seconds or leave the Notifications tab and come back. diff --git a/devblog/2021-05-05-blockchain-release-hip-29-and-hip-30-support.mdx b/devblog/2021-05-05-blockchain-release-hip-29-and-hip-30-support.mdx deleted file mode 100644 index 4434e5714..000000000 --- a/devblog/2021-05-05-blockchain-release-hip-29-and-hip-30-support.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: HIP 29 and HIP 30 support' -date: 2021-05-05 10:24 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The team has a new release tagged `2021.05.04.2` which adds support for -[HIP-29](https://github.com/helium/HIP/blob/master/0029-multisignature-keys.md), -[HIP-30](https://github.com/helium/HIP/blob/master/0030-update-threshold-cryptography.md), and -various bug fixes. This is a _required_ upgrade for all miners and will be automatic for all -Hotspots using the Helium firmware when we GA. - - - -### [miner#757](https://github.com/helium/miner/pull/757): Switch to threshold cryptography - -As mentioned in HIP-30, this adds support for [erlang-tc](https://github.com/helium/erlang-tc) in -miner to start using BLS12-381 keys for HoneyBadgerBFT consensus and DKG. - -### [miner#756](https://github.com/helium/miner/pull/756): Update blockchain-core and snapshot to 830161 - -The team updated miner dependencies and the snapshot block to `830161` to allow newly onboarded -hotspots to sync faster to the current blockchain head block. - -### [miner#755](https://github.com/helium/miner/pull/755): Make print_keys independent of running miner - -This fixes the `miner print_keys` CLI to avoid a trailing `ok` and removes a hardcoded path -dependency. - -### [blockchain-core#793](https://github.com/helium/blockchain-core/pull/792): Fix to_json for payment-v2 memos - -The team noticed that previously added memo support for payment_v2 transactions was not updating the -JSON for use in the API correctly. This has been fixed. - -### [hbbft#66](https://github.com/helium/erlang-hbbft/pull/66): Add support for threshold cryptography - -As mentioned in HIP-30, this adds support for running the HoneyBadgerBFT protocol over the BLS12-381 -curve to generate ephemeral keys used by the consensus group to make blocks. - -### [dkg#36](https://github.com/helium/erlang-dkg/pull/36): Add support for threshold cryptography - -As mentioned in HIP-30, this adds support for running the distributed key generation protocol over -the BLS12-381 curve to generate ephemeral keys used by the consensus group to make blocks. - -### [libp2p-crypto#10](https://github.com/helium/libp2p-crypto/pull/10): Multisig support - -As mentioned in HIP-29, this adds support for multi-signature keys. - -### Plan - -We have been beta testing `2021.05.04.2` since May 4th, 2021 5:30 PM PT. Current ETA for GA is 1:00 -PM PT, May 5th, 2021. diff --git a/devblog/2021-05-05-console-updates-1.9.50.mdx b/devblog/2021-05-05-console-updates-1.9.50.mdx deleted file mode 100644 index c709ad21f..000000000 --- a/devblog/2021-05-05-console-updates-1.9.50.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: post -title: Console Updates- Google Sheets and other Integration Updates -date: 2021-05-06 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This sprint the team focused on Integration updates including building a Google Sheets prebuilt -Integration, adding dynamic query parameters, and including a hold_time field to increase accuracy -of timestamps. - - - -### Features and updates - -- Added a prebuilt integration for Google Sheets. This requires: setting up a public Google form, - preparing a script to decode the payload, and setting up integration on Console. See - [here](https://docs.helium.com/use-the-network/console/integrations/google-sheets) for - instructions. -- Enhanced HTTP Integration with dynamic query parameters allowed in endpoint. -- Increase accuracy of timestamps, we’ve included hold_time (default 0) which represents the time - that a Hotspot was holding on to a packet (in milliseconds). The holding time can be due to - multiple reasons such as: time between offer and acceptance of packet or if communication between - Console/Router and Hotspots is slow then Hotspots would hold on to packets until communication is - restored. This feature will be activated when Hotspots have been updated. -- Functions page includes an Integrations column that lists Integrations. -- Downlink queued item no longer appears after downlink has been sent, and only displays a single - item even if multiple integrations. -- Added a legend to real time packets view. - -### Fixes - -- Backend work to accelerate packet ingestion from Hotspots. -- Payment options for Automatic Renewals no longer appear if a payment method hasn’t been defined. -- Spaces in custom scripts no longer cause Functions Decoder to fail. -- Updated real time packets to align with legend. - -### Open source users - -- New users use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. To update, check the - newest instructions, rebuild, and restart. The database is not affected. - -Documentation [here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Include downlink MAC command info -- Discovery mode support for Hotspot new feature -- Provide docs to help monitor open source Console -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack. -- Update Console core design based on Flows (beta) feedback diff --git a/devblog/2021-05-06-post-mortem-2021-05-05-long-election.mdx b/devblog/2021-05-06-post-mortem-2021-05-05-long-election.mdx deleted file mode 100644 index 48f096b76..000000000 --- a/devblog/2021-05-06-post-mortem-2021-05-05-long-election.mdx +++ /dev/null @@ -1,114 +0,0 @@ ---- -layout: post -title: 'Post Mortem: 2021-05-05 Long Election' -date: 2021-05-06 18:31 -0700 -hide_table_of_contents: true -authors: [abhay, vihu] ---- - -Last night, during the rollout of the `2021.05.04.2` release including the code for -[HIP-29](https://github.com/helium/HIP/blob/master/0029-multisignature-keys.md) and -[HIP-30](https://github.com/helium/HIP/blob/master/0030-update-threshold-cryptography.md), several -members of the community observed a long election including multiple proposed Consensus Groups where -only 15 of the 16 new members succeeded in their Distributed Key Generation (DKG). After several -hours of monitoring the Consensus Group, the Decentralized Wireless Alliance (DeWi) in conjunction -with several core developers ended the 450 block epoch with a Rescue Block, which later restored the -network to a functioning state. The network has been operating correctly since. All funds remained -safe through the entire process. - - - -DKG is a process which ensures that no single one consensus group member knows the entire key for an -epoch; they each have shares of a shared key which is generated per epoch for signing blocks. -Generating a new distributed epoch key is a prerequisite for completing a new Consensus Group -election and generating the associated reward transaction for the epoch that just ended. As part of -the protocol we ensure that _every_ member of the proposed new group completes the DKG thus -requiring 16 of 16 signatures. - -After several hours of monitoring it was clear that a new election was unlikely to complete. In this -instance, Rescue Blocks are used to move the blockchain forward by selecting a new Consensus Group. -The first Rescue Block nominated a group member that subsequently went offline, so a second Rescue -Block was issued with that member replaced. This action proved successful. - -To summarize: - -- No transactions were lost or rolled back and finality was always maintained. -- No assets were ever at risk. -- No loss of any IOT traffic utilizing the network. -- Block times were reasonable throughout the event, except when the Rescue Blocks were issued. -- The majority of the existing Consensus Group was maintained when the new group was nominated. -- Rewards were not issued during the 450 block epoch -- New blocks were delayed while during the creation, signing and deployment of the Rescue Blocks. - -A Rescue Block is a block the network can use to nominate a new Consensus Group in the event that -the current group is unable to fulfill its duties. A Rescue Block can also contain chain variable -updates in case a chain variable change is what is causing a Consensus issue. - -Throughout the Helium blockchain's 830,000+ blocks, Rescue Blocks have only been used on three prior -occasions ([11578](https://explorer-old.helium.com/blocks/11578), -[22462](https://explorer-old.helium.com/blocks/22462) and -[22508](https://explorer-old.helium.com/blocks/22508)). In this instance, the issue was identified -quickly, diagnosed correctly, and the community assembled quickly to take action and restore network -health. - -## What triggered the long election? - -The release of HIP-30 contains fundamental changes to the threshold cryptography underpinning the -election and consensus logic. Despite several tests beforehand, including multiple trials on the -Testnet, this release resulted in a long epoch on Mainnet. - -This issue was exacerbated by the arm64 Docker build. This issue took several hours to identify and -resolve in the middle of the night. As a consequence, Hotspots (notably DIY miners and Bobcat) using -a Docker image lagged significantly on upgrades resulting in partial rollout of the crucial changes -included in HIP-29 and HIP-30. - -Several elections came extremely close to completion (15/16 signatures) but the community became -concerned with the time it was taking. Although a majority of the group was running the new release, -not all of the members had upgraded and the new group members were either unable to complete the DKG -because they were offline and/or not on the updated threshold cryptography curve. Eventually it was -decided that while the arm64 Docker container was going out, that alone was not enough to solve the -problem in a reasonable time. - -With long elections, there are 2 issues that cause concern: the size of the rewards (and the -calculation complexity) and routers running out of state channels. The first issue led to a quick -realization that even if things were to eventually resolve, the resulting rewards block could have -been so large that it would not be computable/absorbable on some of the older Hotspot hardware. -Secondly, the number of state channels a router can run in an epoch is limited, so extremely long -elections can lead to state channel exhaustion, which leads to routers being unable to open more -state channels, which eventually leads to disruption of the IoT packet routing. Both of these -concerns led to the decision to use a rescue block to resolve the situation. - -## Lessons and Prevention - -While this situation was somewhat unique, there are definitely some lessons to learn: - -- The arm64 Docker image build needs to be more reliable (this work is already in progress) -- Rescue blocks need to have some facility for including rewards in the future -- If a complicated upgrade must be done again (which is not foreseeable), a better schedule should - be set up for it and with a clear contingency plan - -The [validators branch](https://github.com/helium/blockchain-core/pull/727/) that is planned to be -deployed to Mainnet soon includes several improvements that will help with reliability in these -kinds of cases, and several more improvements are in-progress and will be incorporated into the -final release of that feature. - -## Rewards and Total HNT Supply - -Understandably, one may wonder what happened to the rewards during the 450 blocks of the Rescue -Block exercise. The short answer is that they were never minted. Since they were never mined, this -will decrease the total supply of HNT, as described in -[HIP-20](https://github.com/helium/HIP/blob/master/0020-hnt-max-supply.md), by 52,000. - -While the community is working on mitigating the effects of lapses like this, the nature of -blockchains is that the past is immutable and all participants were uniformly affected. Although -some short-term pain was felt by participants in the network during the outage, this event should -have a minimal long-term economic impact to the network. - -## Thank yous - -We’d like to thank the Decentralized Wireless Alliance and several members of the community and core -developers for working through the night to diagnose and resolve this issue quickly. Decentralized -coordination is not easy. Swift action helped contain and resolve this issue in a timely manner. - -While this event was evidence of growing pains, the network is back to operating properly, flowing -IoT data, and growing at a rapid clip. diff --git a/devblog/2021-05-12-app-version-313.mdx b/devblog/2021-05-12-app-version-313.mdx deleted file mode 100644 index fcee82dfd..000000000 --- a/devblog/2021-05-12-app-version-313.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -layout: post -title: App Version 3.1.3 -date: 2021-05-12 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# 3.1.3 Improvements and Bug Fixes - -## Added Relayed Hotspot pill - -Hotspots that are relayed through other Hotspots on the network may experience syncing or reduced -mining rewards. We now surface that up to the user in the app (already exists on -explorer-old.helium.com). - - - -## Accessibility Support (Screen Reader) - -We made an initial effort to support Screen Reader support. Further improvements will added in the -future. - -## Retry Onboarding - -Allows users to retry onboarding Hotspots if the field is null. This can happen if the Hotspot does -not respond in time and sends null values instead of its onboarding key. - -## Fix Action Sheet Scrolling - -Fixes an issue in the action sheet where scrolling was not supported and users were unable to access -additional menu items. - -## Fixes assumptions for asserting location - -Previous versions of assert_location uses nonce + 1 to increment transactions. Since -assert_location_v2, we've seen the coordination between the blockchain and consensus group 'miss' -which can cause transactions to fail because the nonce did not match. We implement a solution on the -App and API side to use speculative nonce instead (what payment transactions also use). We expect -this to fix failing assert location transactions. - -## Update to React Native 64 diff --git a/devblog/2021-05-13-blockchain-release-light-gateway-and-discovery-mode-support.mdx b/devblog/2021-05-13-blockchain-release-light-gateway-and-discovery-mode-support.mdx deleted file mode 100644 index f2bb37316..000000000 --- a/devblog/2021-05-13-blockchain-release-light-gateway-and-discovery-mode-support.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Light Gateway and Discovery Mode Support' -date: 2021-05-13 10:34 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The team has a new release tagged `2021.05.12.0` which adds support for light gateways and miner -discovery mode. This is a _required_ upgrade for all miners and will be automatic for all Hotspots -using the Helium firmware when we GA. - - - -### [miner#708](https://github.com/helium/miner/pull/708): Add light gateway support - -This PR adds miner side support for light gateways. You can find more information about light -gateways [here](https://docs.helium.com/hotspot-makers/iot/light-hotspots/). - -### [miner#744](https://github.com/helium/miner/pull/744): Add discovery mode support - -This PR adds miner side discovery mode support. - -### [miner#764](https://github.com/helium/miner/pull/764): Update blockchain-core and snapshot to 841681 - -The team updated miner dependencies and the snapshot block to `841681` to allow newly onboarded -hotspots to sync faster to the current blockchain head block. - -### [blockchain-core#735](https://github.com/helium/blockchain-core/pull/735): Add light gateway support - -This adds light gateway support to blockchain-core, note that it won't be live until the related -chain variables are activated. The team will issue a future update on the activation schedule. - -### Plan - -We have been beta testing `2021.05.12.0` since May 12th, 2021 5:30 PM PT. Current ETA for GA is 2:30 -PM PT, May 13th, 2021. diff --git a/devblog/2021-05-17-checkpoints.mdx b/devblog/2021-05-17-checkpoints.mdx deleted file mode 100644 index 009aef36a..000000000 --- a/devblog/2021-05-17-checkpoints.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: OoM Amelioration' -date: 2021-05-17 10:30 -0700 -hide_table_of_contents: true -authors: [evanmcc, vagabond] ---- - -The Helium core developers have prepared a new blockchain release tagged `2021.05.16.1` which makes -a number of changes to help older Hotspots be able to sync the blockchain. This is a _required_ -upgrade for all miners and will be automatic for all Hotspots using the Helium firmware when we GA. - - - -In addition, we have issued the -[chain variable transaction](https://github.com/helium/miner/blob/master/audit/var-61.md) lowering -the rate at which hotspots issue Proof of Coverage challenges, which should alter load network-wide. - -### [blockchain-core/799](https://github.com/helium/blockchain-core/pull/799): Change ledger startup to recover using rocks checkpoints - -This PR makes some major changes to how previous versions of the ledger are stored on disk and -represented in memory. A major cause of out of memory (OoM) errors in older, lower-memory hardware -is the startup phase where older versions of the ledger, required for transaction validation, are -interpolated from the two versions that we keep on disk. Since these interpolations live in memory, -and are often quite duplicative, they consume a great deal of memory. Luckily, RocksDB, our main -persistent storage engine, provides a feature called -[Checkpoints](https://github.com/facebook/rocksdb/wiki/Checkpoints). While these Checkpoints were -originally meant to make taking backups easier, the work here to provide lightweight copies of the -ledger which remain on disk when the miner restarts, allowing us to start up with much less memory -used. - -Prior to this change, a subset of older, Raspberry Pi 3B+ based units with 1GB of memory were having -a great deal of trouble starting up, as they would run out of memory during interpolation, and so -have been stuck many days in the blockchain's past, unable to issue challenges or meaningfully -participate in the network. We anticipate that this release will fix most of those units, but we -remain extremely sensitive to these issues and have more performance work planned in the coming -weeks. - ---- - -Additionally, we've bumped the snapshot past the chain variable change mentioned above, which should -help older units catch up more quickly. - -### Plan - -We have been beta testing `2021.05.16.1` since May 16th, 2021 3:15 PM PT. Current ETA for GA is -1:30PM PT, May 17th, 2021. diff --git a/devblog/2021-05-18-app-version-320.mdx b/devblog/2021-05-18-app-version-320.mdx deleted file mode 100644 index 6e95fe363..000000000 --- a/devblog/2021-05-18-app-version-320.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: App Version 3.2.0 -date: 2021-05-18 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Discovery Mode is Here! - -Use Discovery Mode to understand your Hotspot’s coverage without waiting for -Proof-of-Coverage/Beacons, or setting a location! - - - -Your Hotspot acts as a device and sends out radio packets for a short period of time, and any -Hotspots that heard the packet will respond. - -How can you use Discovery Mode? - -- use it to compare antennas (is one better than the other?) -- use it to test indoor or outdoor set ups -- test if higher really is better (it is) -- which side of the house sees more Hotspots? - -Run Discovery Mode up to 5 times per day per Hotspot. - -Note: Discovery Mode will not work on syncing Hotspots, offline Hotspots, and may not work on -Relayed Hotspots. Discovery Mode is free to use until further notice. - -Try it out today - update to app version 3.2.0 and make sure your Hotspot is running firmware -2021.05.12.0. - -## Other Bug fixes - -Transfer Hotspot bug is now fixed where users were unable to tap on the button in the Transfer -Hotspot notification. diff --git a/devblog/2021-05-18-blockchain-release-fixing-oom-and-sync.mdx b/devblog/2021-05-18-blockchain-release-fixing-oom-and-sync.mdx deleted file mode 100644 index b7ac221ef..000000000 --- a/devblog/2021-05-18-blockchain-release-fixing-oom-and-sync.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Fixing OOM and Sync' -date: 2021-05-18 19:00 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The team has a new release tagged `2021.05.18.0` which primarily fixes out-of-memory and sync issues -observed on older, less capable hardware, and other bug fixes. This is a _required_ upgrade for all -miners and will be automatic for all Hotspots using the Helium firmware when we GA. - - - -### [miner#776](https://github.com/helium/miner/pull/776): Update blockchain-core and downgrade snapshot - -The current blessed snapshot was downgraded back to `845281` because the previously blessed snapshot -was incomplete. Hotspots that have tried to load the new, bad snapshot will be stuck until a newer, -complete snapshot is minted by the chain. - -### [miner#766](https://github.com/helium/miner/pull/766): Add arm64 image builder - -An ARM64 docker image builder was added to avoid long running build times. - -### [blockchain-core#807](https://github.com/helium/blockchain-core/pull/807): Parameterize snapshot generation - -The change makes snapshot generation to be dependent on the currently configured -`poc_challenge_interval` chain variable. This limits snapshot generation to only those that include -required blocks as set by this variable. - -### [blockchain-core#806](https://github.com/helium/blockchain-core/pull/806): Clean checkpoint bugs and fix subnets - -A few bugs related to ledger checkpoints were addressed and failing tests were fixed. - -### [blockchain-core#805](https://github.com/helium/blockchain-core/pull/805): Add missing light gateway chain var validation - -A few missing chain variable validation functions were added after testing Light Hotspots on the -Testnet. - -### Plan - -We have been beta testing `2021.05.18.0` since May 18th, 2021 4:30 PM PT. Current ETA for GA is -10:00 PM PT, May 18th, 2021. diff --git a/devblog/2021-05-19-blockchain-release-snapshot-update-and-low-space-fix.mdx b/devblog/2021-05-19-blockchain-release-snapshot-update-and-low-space-fix.mdx deleted file mode 100644 index 5dcdd4995..000000000 --- a/devblog/2021-05-19-blockchain-release-snapshot-update-and-low-space-fix.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Update and Low Space Fix' -date: 2021-05-19 17:24 -0700 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -The team has a new release tagged `2021.05.19.0` which primarily fixes low space observed on some -Hotspots with smaller SD cards and updates the blessed snapshot. This is a _required_ upgrade for -all miners and will be automatic for all Hotspots using the Helium firmware when we GA. - - - -### [miner#781](https://github.com/helium/miner/pull/781): Update snapshot to 851041 - -After -[yesterday's](https://engineering.helium.comhttps://docs.helium.com/blog/2021/05/18/blockchain-release-fixing-oom-and-sync.html) -stability fix release the chain was successfully able to mint a new, complete snapshot `851041`. The -team has updated miner config to switch to the newer blessed snapshot for newly onboarded Hotspots -to sync faster. - -The fix for low space Hotspots is baked in the firmware of the Hotspots itself, simply removing -previously created database directories if the storage usage is above 90% and recreating the -required database directories from the newest blessed snapshot specified in miner config. - -### Plan - -We have been beta testing `2021.05.19.0` since May 19th, 2021 4:30 PM PT. Current ETA for GA is 6:00 -PM PT, May 19th, 2021. diff --git a/devblog/2021-05-19-console-updates-1.9.51.mdx b/devblog/2021-05-19-console-updates-1.9.51.mdx deleted file mode 100644 index 50ef08744..000000000 --- a/devblog/2021-05-19-console-updates-1.9.51.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: post -title: Console Updates- Downlink MAC Info, and Discovery Mode for Hotspots -date: 2021-05-20 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, madninja] ---- - -The team delivered the ability to view LoRaWAN MAC command information for downlinks. Also along -with other updates backend work was done to enable Discovery Mode for Hotspots. See details about -Discovery Mode -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2021/05/18/app-version-320.html). - - - -### Features and updates - -- Included downlink MAC command information. -- Backend work needed to support Discovery Mode for Hotspots. -- Functions page includes link to github repo that includes custom decoders provided by the - community (choose Functions > Custom Script to reveal link). -- DevEUI, AppEUI prefix generated from Console includes Helium IEEE standards OUI. -- Updated API to list labels for a device by adding labels field to v1/devices/:device_id endpoint - response - -### Fixes - -- Only a single downlink queue appears regardless of the number of integrations. -- Updated Google Sheet pre-built Integration icon. -- Resolved an issue related to creating new Organizations. - -### Open source users - -- New users use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. To update, check the - newest instructions, rebuild, and restart. The database is not affected. - -Documentation [here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Provide ability to recognize and forward non-Helium packets to other LoRaWAN Network Servers -- Create a module to integrate with other LoRaWAN network servers, initially ChirpStack -- Update Console core design based on Flows (beta) feedback -- Microsoft Azure Pre-built Integration diff --git a/devblog/2021-05-20-blockchain-release-snapshot-and-libp2p-updates.mdx b/devblog/2021-05-20-blockchain-release-snapshot-and-libp2p-updates.mdx deleted file mode 100644 index f45b6ba8c..000000000 --- a/devblog/2021-05-20-blockchain-release-snapshot-and-libp2p-updates.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot and libp2p updates' -date: 2021-05-20 06:58 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.05.20.0` Hotspot firmware release which primarily fixes -libp2p peerbook issues affecting a small number of Hotspots and also updates the blessed snapshot. -This is a _required_ upgrade for all miners and will be automatic for all Hotspots using the Helium -firmware when we GA. - - - -### [miner#783](https://github.com/helium/miner/pull/781): Update snapshot to 852481 and bump core - -This change updates the `blockchain-core` dependency as described below and a new blessed snapshot -`852481` has been added for newly onboarded Hotspots to sync faster. - -### [erlang-libp2p#341](https://github.com/helium/erlang-libp2p/pull/341): Clear peerbook if it's not corrupted - -An error case in RocksDB opening while getting the libp2p peerbook has been addressed. - -### [erlang-libp2p#339](https://github.com/helium/erlang-libp2p/pull/339): Reset port counter to start from 1025 - -Thanks to [@Rapsssito](https://github.com/Rapsssito) for this bug fix! They identified and fixed a -bug which was incorrectly resetting the port counter. - -### Plan - -We have been beta testing `2021.05.20.0` since May 20, 2021 2:30 PM PT. Current ETA for GA is 6:00 -PM PT, May 20th, 2021. diff --git a/devblog/2021-05-23-blockchain-release-snapshots-over-s3.mdx b/devblog/2021-05-23-blockchain-release-snapshots-over-s3.mdx deleted file mode 100644 index 713120aed..000000000 --- a/devblog/2021-05-23-blockchain-release-snapshots-over-s3.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshots over S3' -date: 2021-05-23 10:30 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The core developers have tagged a new `2021.05.22.0` Hotspot firmware release which adds S3 download -functionality for snapshots and updates the blessed snapshot to `855361`. This is an optional, but -recommended upgrade for all miners and will be automatic for all Hotspots using the Helium firmware -when we GA. - - - -### [blockchain-core#810](https://github.com/helium/blockchain-core/pull/810): Pull snapshots from S3 - -This change allows blockchain participants to attempt to download a snapshot file from S3 and -install it. If that fails, it will fall back to the current code path. Additionally, it exposes a -CLI interface to attempt to grab a snapshot from the p2p code path and save it to a specified file. - -### Plan - -We have been beta testing `2021.05.22.0` since May 22nd, 2021 5:30 PM PT. Current ETA for GA is -12:30 PM PT, May 23rd, 2021. diff --git a/devblog/2021-05-24-blockchain-release-new-snapshot-and-timeout-fixes.mdx b/devblog/2021-05-24-blockchain-release-new-snapshot-and-timeout-fixes.mdx deleted file mode 100644 index 35b311f93..000000000 --- a/devblog/2021-05-24-blockchain-release-new-snapshot-and-timeout-fixes.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: New snapshot and timeout fixes' -date: 2021-05-24 17:53 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.05.24.1` Hotspot firmware release which changes S3 -snapshot download timeout to a more relaxed limit and updates the blessed snapshot to `858241`. This -is an optional, but recommended upgrade for all miners and will be automatic for all Hotspots using -the Helium firmware when we GA. - - - -### [miner#786](https://github.com/helium/miner/pull/786): Bump snapshot to 858241 and update blockchain-core - -This change updates the latest blessed snapshot to `858241` and updates blockchain-core dependency -to pick up snapshot timeout fixes. - -### [miner#784](https://github.com/helium/miner/pull/784): Fix bash script for GA docker tags - -This change fixes a misconfigured match statement which was previously preventing trigger docker -builds whenever the team would GA a new firmware tag. - -### [blockchain-core#812](https://github.com/helium/blockchain-core/pull/812): Increase snapshot download timeout - -This change increases the snapshot download timeout limits set to more acceptable values. -Furthermore it handles a sentinel error value when importing snapshots. - -### Plan - -We have been beta testing `2021.05.24.1` since May 24th, 2021 6:30 PM PT. Current ETA for GA is 9:00 -PM PT, May 24th, 2021. diff --git a/devblog/2021-05-28-major-blockchain-release-validator-support.mdx b/devblog/2021-05-28-major-blockchain-release-validator-support.mdx deleted file mode 100644 index b68b23f8b..000000000 --- a/devblog/2021-05-28-major-blockchain-release-validator-support.mdx +++ /dev/null @@ -1,81 +0,0 @@ ---- -layout: post -title: 'Major Blockchain Release: Validator Support' -date: 2021-05-28 12:54 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.05.28.0` Hotspot firmware release which prepares support -for [Validators](https://github.com/helium/HIP/blob/master/0025-validators.md) on Mainnet. This is a -_required_ upgrade for all miners and will be automatic for all Hotspots using the Helium firmware -when we GA. - - - -### [miner#795](https://github.com/helium/miner/pull/795): Update blockchain-core dependency - -A dependency bump to include resync fixes from blockchain-core. - -### [miner#794](https://github.com/helium/miner/pull/794): Update blockchain-core and new blessed snapshot - -This change updates blockchain-core dependency and changes the blessed snapshot to `862561`. - -### [miner#793](https://github.com/helium/miner/pull/793): Update blockchain-core for Validator and AS923 support - -This change updates blockchain-core depedency to include Validator support and updates AS923 LoraWAN -frequency channels. - -### [miner#791](https://github.com/helium/miner/pull/791): Relax timers on PoC related events - -The team noticed that in certain scenarios when block production is slower than expected, the -Proof-of-Coverage related timers were too restrictive. This has been fixed. - -### [miner#772](https://github.com/helium/miner/pull/772): Update CSV for LoraWAN Spec RP002-1.0.3 - -Thanks to community member [@shawaj](https://github.com/shawaj) for adding this change which updates -the countries CSV list to newer LoraWAN Spec RP002-1.0.3 and fixes channel parameters for multiple -regions. - -### [blockchain-core#832](https://github.com/helium/blockchain-core/pull/832): Fix new ledger invocation - -This change fixes some incorrect calls to invoke a new ledger when a new snapshot is loaded. - -### [blockchain-core#831](https://github.com/helium/blockchain-core/pull/831): Fix checkpoints for block handles - -This fixes checkpoints (used for snapshots) to invoke a new ledger correctly. - -### [blockchain-core#829](https://github.com/helium/blockchain-core/pull/829): Fix poc_receipts eunit - -The team noticed broken eunit tests in `blockchain_txn_poc_receipts_v1`, these have been fixed. - -### [blockchain-core#727](https://github.com/helium/blockchain-core/pull/727): Validator support - -The team finally merged the highly anticipated support for Validators. Validators are a new entity -on the Helium Blockchain that will perform the work of the consensus group including verifying -transactions and adding new blocks to the blockchain. Validators improve the overall security, and -reliability of the network allowing it to continue its unprecendented growth. - -**NOTE: We will have a separate post on the activation schedule.** - -Once the validator related chain vars are activated on the network, users will be able to stake -validator nodes. After the threshold (100 validators on Mainnet) has been met we will choose a date -to activate validator nodes to start performing consensus group work and earning HNT rewards on -Mainnet. This activation date provides everyone an equal starting point to prepare and stake -validators. - -Please feel free to read [HIP 25](https://github.com/helium/HIP/blob/master/0025-validators.md), and -docs for more information on Validators. - -This PR is also accompanied by a few smaller bug-fix PRs, notably: - -- [blockchain-core#820](https://github.com/helium/blockchain-core/pull/820): Bug fix for election-v5 -- [blockchain-core#818](https://github.com/helium/blockchain-core/pull/818): Add release height to - Validator record -- [blockchain-core#817](https://github.com/helium/blockchain-core/pull/817): Guarantee offline - Validator removal - -### Plan - -We have been beta testing `2021.05.28.0` since May 28th, 2021 11:50 AM PT. Current ETA for GA is -5:00 PM PT, May 28th, 2021. diff --git a/devblog/2021-05-29-blockchain-release-chain-halt-postmortem.mdx b/devblog/2021-05-29-blockchain-release-chain-halt-postmortem.mdx deleted file mode 100644 index e00cc9633..000000000 --- a/devblog/2021-05-29-blockchain-release-chain-halt-postmortem.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Chain Halt Postmortem' -date: 2021-05-29 06:56 -0700 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -The core developers have prepared an emergency release `2021.05.29.0` to fix the Mainnet chain halt -noticed around 1:00 PM PST, May 29th, 2021. This is a **mandatory** release for all miners on the -network. Please read further for more details. - - - -## What Happened? - -The team changed the election_info API in `blockchain-core` as part of support for -[Validators](https://engineering.helium.comhttps://docs.helium.com/blog/2021/05/28/major-blockchain-release-validator-support.html) -but missed updating the relevant API calls in miner. Surprisingly `xref` and `dialyzer`, two tools -used in the Erlang ecosystem to do static analysis, didn't catch the incorrect calls either. This -regression led to a chain halt as the code change broke a critical HoneyBadgerBFT recovery code -path. - -## Timeline - -- **Sat May 29 01:04:00 PM PDT 2021**: The core team got a pagerduty alert that there were no new - blocks after block `864000` -- **Sat May 29 01:26:00 PM PDT 2021**: [status](http://status.helium.com/) updated to reflect the - blockchain halt and debugging. -- **Sat May 29 01:45:00 PM PDT 2021**: The bug was identified as an incorrect call in miner to a - critical election related function in blockchain-core, more details available in - [miner#797](https://github.com/helium/miner/pull/797). -- **Sat May 29 02:00:00 PM PDT 2021**: `2021.05.29.0` release candidate prepared for beta testing - and imminent GA. - -The issue was identified addressed quickly and the Consensus Group will be able to continue block -production after this release. - -## Future Work - -Bugs like these can slip through normal reviews and testing but improved test suites with better -code coverage can help catch these sorts of regressions. Future regular maintenance releases will -include these improvments. - -## Plan - -We will begin beta testing `2021.05.29.0` as soon as the release is built and GA immediately after -checking beta status. diff --git a/devblog/2021-05-30-blockchain-release-tuning-slow-txns.mdx b/devblog/2021-05-30-blockchain-release-tuning-slow-txns.mdx deleted file mode 100644 index d8221f914..000000000 --- a/devblog/2021-05-30-blockchain-release-tuning-slow-txns.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Adjusting Validation Timeouts' -date: 2021-05-30 16:31 -0700 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -As some of the community has noticed, block times and elections have been struggling the last week -or so as the network continues to grow. The core developers have prepared the `2020.05.29.1` release -which will adjust validation times for two known slower transactions in our blockchain. This is an -optional but recommended release for miners on the network. - - - -Forcing receipts transaction validation to 100ms (from 125ms) and increasing validation time of the -consensus group transaction to 30s (from 10s) should improve block times between elections and make -a successful election more likely. - -### [miner#798](https://github.com/helium/miner/pull/798): Give more time to consensus groups and less to poc receipts - -After -[yesterday's](https://engineering.helium.comhttps://docs.helium.com/blog/2021/05/29/blockchain-release-chain-halt-postmortem.html) -emergency release to fix blockchain halt, the core developers noticed that election transactions -were not getting enough time for validation and absorption, this PR updates the timeouts to help -clear longer election transactions. - -## Plan - -We have been beta testing `2021.05.29.1` since 11:00 PM PST 29th May, 2021 and will GA at 4:45 PM -PST May 30th, 2021. diff --git a/devblog/2021-06-02-console-updates-1.9.52.mdx b/devblog/2021-06-02-console-updates-1.9.52.mdx deleted file mode 100644 index e0b3bea50..000000000 --- a/devblog/2021-06-02-console-updates-1.9.52.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 1.9.52 -date: 2021-06-03 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, madninja] ---- - -This sprint we included updates for downlinks including refresh and showing payloads in both base64 -and decoded text. - - - -In addition, the team updated the backend (Router) with the latest major blockchain core release, -more details -[here](https://engineering.helium.comhttps://docs.helium.com/blog/2021/05/28/major-blockchain-release-validator-support.html). - -### Features and updates - -- Ability to refresh the downlink queue -- Console downlink queue shows payloads in Base64 and decoded text -- LPP Decoder supports The Things Stack v3 additional data types -- Discovery Mode work to customize frame time outs - -### Fixes - -- Fixed data rate used when queueing downlinks -- Resolved issue that forced JoinAccept DLSettings to always be 0 - -### Open source users - -- New users use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. To update, check the - newest instructions, rebuild, and restart. The database is not affected. - -Documentation [here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Microshare pre-built Integration -- Microsoft Azure IoT Hub pre-built Integration -- CFList appended to JoinAccept: https://github.com/helium/router/issues/322 -- Packet purchaser: -- provide ability to recognize and forward non-Helium packets to other LoRaWAN Network Servers -- integrate with ChirpStack LoRaWAN Network Server -- Console 2.0 migration testing diff --git a/devblog/2021-06-03-app-version-323.mdx b/devblog/2021-06-03-app-version-323.mdx deleted file mode 100644 index 40b89639e..000000000 --- a/devblog/2021-06-03-app-version-323.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: App Version 3.2.2 and 3.2.3 -date: 2021-06-03 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Release 3.2.2 - -Bug Fixes - -- Fixes a bug where the discovery mode timer does not continue when the app is put in background -- Prevents users from submitting multiple assert location transactions before the first one clears -- Fixes onboarding errors -- Adds session length to discovery mode - - - -# App Release 3.2.3 - -Bug Fixes - -- Fixes the decimal separator when the locale is set to non-US -- Fixes a bug where values more than 1,000 HNT defaults back to zero diff --git a/devblog/2021-06-04-blockchain-release-snapshot-fixes-and-implicit-burn-support.mdx b/devblog/2021-06-04-blockchain-release-snapshot-fixes-and-implicit-burn-support.mdx deleted file mode 100644 index b07ff396c..000000000 --- a/devblog/2021-06-04-blockchain-release-snapshot-fixes-and-implicit-burn-support.mdx +++ /dev/null @@ -1,110 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Fixes and Implicit Burn Support' -date: 2021-06-04 14:33 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.06.08.0` Hotspot firmware release which fixes Snapshot -creation and ingestion. It also adds support for storing transaction with implicit burns. This is a -_required_ upgrade for all miners and will be automatic for all Hotspots using the Helium firmware -when we release to General Availability. - - - -### Community Contribution!!! - -The core developers would like to thank [@syuan100](https://github.com/syuan100) for implementing -support for storing "Implicit Burn" events on the blockchain. This is a substantial contribution -made by a community member on `blockchain-core` and we are very excited that it's packed in the new -release. Storing "Implicit Burn" events essentially allow consumers of blockchain-core to store -those transactions where the fee has been paid for by burning HNT on behalf of the user by the -network. Please feel free to read the -[blockchain-core#771](https://github.com/helium/blockchain-core/pull/771) for more details. - -### Snapshot updates for reliable generation and ingestion - -As some of the community members have noticed, the blockchain is not constructing new snapshots -reliably, this release aims to fix that. - -**IMPORTANT! This release is _not_ forwards compatible, i.e. if a Hotspot is on an older firmware -than this one, they will fail to retrieve and ingest newly generated snapshots, therefore it's -imperative to update to `2021.06.08.0`.** - -Below are the snapshot fix related PRs: - -- #### [blockchain-core#786](https://github.com/helium/blockchain-core/pull/786): Incremental snapshot [de]serialization - - This change fixes the [de]serialization of snapshot to not cause huge memory spikes the team - observed on some of the hotspots. - -- #### [blockchain-core#857](https://github.com/helium/blockchain-core/pull/857): More fixes for atomic checkpoint cleanup - - The team noticed that the checkpoint directories were not being cleaned properly, this change - fixes that and adds a unit test for it. - -- #### [blockchain-core#856](https://github.com/helium/blockchain-core/pull/856): Make ledger checkpoints more atomic - - This change enforces that we don't accidentally take a ledger checkpoint and omit writing the - delayed file or the updates because of a crash or a restart by utilizing a temporary directory and - atomic renaming. - -- #### [blockchain-core#854](https://github.com/helium/blockchain-core/pull/854): Store completed ledger upgrades in snapshot - - This adds support for storing completed ledger upgrades in the snapshots, this ensures that - snapshots contain all the necessary information required to continue resyncing. - -- #### [blockchain-core#851](https://github.com/helium/blockchain-core/pull/851): Keysort before snapshot serialization - - This change ensures that snapshots are serialized and subsequently hashed in a deterministic - order. - -- #### [blockchain-core#850](https://github.com/helium/blockchain-core/pull/850): Fix outdated snapshot API - - This change updates the tests to use the updated snapshot API. - -- #### [blockchain-core#846](https://github.com/helium/blockchain-core/pull/846): Re-add snapshot backward compatibility - - This change enables storing S3 downloads and cross-checking before doing another download. - Furthermore it updates snapshot initialization to use the already downloaded S3 snapshot. - -### Core enhancements for blockchain-etl - -The following additions allow blockchain-etl to expose a better API: - -- #### [blockchain-core#840](https://github.com/helium/blockchain-core/pull/840): Expose fee_payer function for transactions - - As a helper to blockchain-etl, each transaction now exposes a `fee_payer/2` function from each - transaction. This helps in reconciling the actual fee payer of all transactions. - -- #### [blockchain-core#839](https://github.com/helium/blockchain-core/pull/839): Expose blockchain_txn:fee function - - Add support to expose `blockchain_txn:fee/1` for each transaction on chain. - -### Transaction manager and other enhancements for blockchain-core - -The following fixes aim to address transaction processing and gossip issues observed on the network: - -- #### [blockchain-core#843](https://github.com/helium/blockchain-core/pull/843): Update condition for next plausible block - - This change fixes a long standing bug in ingesting potentially plausible blocks. Please read the - PR for further details. - -- #### [blockchain-core#836](https://github.com/helium/blockchain-core/pull/836): Route depdendent transactions to dialed members - - This fix ensures that a potentially dependent transaction gets an opportunity to be processed by - atleast some consensus group members given that it was never accepted before. Please read the PR - for further details. - -- #### [blockchain-core#825](https://github.com/helium/blockchain-core/pull/825): Get transaction submission paramaters from num_consensus_members chain variable - - This change updates the transaction submission parameters to use `num_consensus_members` chain - variable instead of being set at initialization. This ensures that the testnet continues to - process transactions at a steady rate while also future proofing if the variable eventually - chages. - -### Plan - -We have been beta testing `2021.06.08.0` since June 8th, 2021 12:30 PM PT. Several release -candidates have been tested since late last week. Current ETA for GA is 4:00 PM PT, June 8th, 2021. diff --git a/devblog/2021-06-09-blockchain-release-new-blessed-snapshot.mdx b/devblog/2021-06-09-blockchain-release-new-blessed-snapshot.mdx deleted file mode 100644 index 6d414a480..000000000 --- a/devblog/2021-06-09-blockchain-release-new-blessed-snapshot.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: New Blessed Snapshot' -date: 2021-06-09 11:58 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.06.09.0` Hotspot firmware release which contains a newly -generated snapshot. This would allow newly onboarded and previously un-synced hotspots to sync to -the head of the blockchain much faster. - - - -Below are the related PRs: - -- #### [miner#814](https://github.com/helium/blockchain-core/pull/814): Update core and set blessed snap-876961 - - This change contains `blockchain-core` fixes and a newly blessed chain generated snapshot at - height `876961`. - -- #### [miner#813](https://github.com/helium/blockchain-core/pull/813): Dont allow consensus participation in follow mode - - This change prohibits Hotspots from participating in consensus group if they are operating in - `follow-mode`. A Hotspot can be set to follow mode via touch file or configuration. By default - Hotspots are always validating transactions and blocks unless in follow mode. - -- #### [blockchain-core#858](https://github.com/helium/blockchain-core/pull/858): Fix ledger upgrade marking - - The core developers noticed that the gateway ledger upgrade marking code didn't properly commit - the ledger context, this has been fixed. - -### Plan - -We have been beta testing `2021.06.09.0` since June 9th, 2021 12:30 PM PT. Current ETA for GA is -2:30 PM PT, June 9th, 2021. diff --git a/devblog/2021-06-11-blockchain-release-minor-updates-and-snapshot.mdx b/devblog/2021-06-11-blockchain-release-minor-updates-and-snapshot.mdx deleted file mode 100644 index c4242ce82..000000000 --- a/devblog/2021-06-11-blockchain-release-minor-updates-and-snapshot.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Minor Updates and Snapshot' -date: 2021-06-11 13:22 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.06.11.2` Hotspot firmware release which has minor test -related fixes and a newly generated snapshot. This is an optional release for Hotspot owners but -recommended to get newly onboarded and/or un-synced hotspots to sync to the head of the blockchain. - - - -Below are the related PRs: - -- #### [miner#818](https://github.com/helium/blockchain-core/pull/818): Update core and set blessed snap-879121 - - This change updates `blockchain-core` dependency and supplies a newly blessed chain generated - snapshot at height `879121`. - -- #### [blockchain-core#861](https://github.com/helium/blockchain-core/pull/861): Don't validate chain vars for genesis block - - This change allows the construction of genesis block without any chain var validation. Primarily - used for testing. - -- #### [blockchain-core#860](https://github.com/helium/blockchain-core/pull/860): Don't download S3 snapshot if honor_quick_sync is false - - The core developers noticed that miner would continue to attempt to download S3 snapshot despite - setting `honor_quick_sync` as false preventing debugging, this has been fixed. - -- #### [blockchain-core#859](https://github.com/helium/blockchain-core/pull/859): Diff more elements of snapshots - - This is a minor change to allow verification and debugging of ledger deviation when generating - snapshots. - -### Plan - -We have been beta testing `2021.06.11.2` since June 11th, 2021 1:15 PM PT. Current ETA for GA is -2:15 PM PT, June 11th, 2021. diff --git a/devblog/2021-06-14-blockchain-release-bug-fixes-and-snapshot-update.mdx b/devblog/2021-06-14-blockchain-release-bug-fixes-and-snapshot-update.mdx deleted file mode 100644 index 7a78e6bc5..000000000 --- a/devblog/2021-06-14-blockchain-release-bug-fixes-and-snapshot-update.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Bug Fixes and Snapshot Update' -date: 2021-06-14 16:05 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.06.14.0` Hotspot firmware release which contains -transaction processing improvements, preparatory code for a new chain variable, and a newly -generated snapshot. This is a _required_ release for Hotspot owners. Further announcements will be -made for chain variable activation schedule but we expect about a week or so of time to allow -downstream clients of the chain (etl, node, and router users) to update. - - - -Below are the related PRs: - -- #### [miner#824](https://github.com/helium/miner/pull/824): Update core and set blessed snap-882721 - - This change updates `blockchain-core` dependency and supplies a newly blessed chain generated - snapshot at height `882721`. Subsequent miner PRs are also listed below, please feel free to read - through them for more details: - - - [miner#820](https://github.com/helium/miner/pull/820): Transaction manager depedency test - improvements - - [miner#800](https://github.com/helium/miner/pull/800): Add more transaction manager testing - -- #### [blockchain-core#830](https://github.com/helium/blockchain-core/pull/830): Ensure nonce is checked as part of transaction validation - - The Pull Request itself contains more details but this fix pulls most of the transaction - validation code further up from "absorb" context into the "validation" context of a transaction's - lifecycle. This should help classify invalid transactions earlier than the current blockchain - behavior. This will also improve valid/invalid status in `blockchain-etl` which should result in - better user experience for users of the API and App. - -- #### [blockchain-core#863](https://github.com/helium/blockchain-core/pull/863): Fix reward unit calculation - - The core developers would like to thank [@marcusze](https://github.com/marcusze) for reporting - [blockchain-core#835](https://github.com/helium/blockchain-core/issues/835). The current reward - distribution for Proof of Coverage beacons doesn't precisely conform with - [HIP-15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md) transmission reward - unit, the changes here will address that. - - This change prepares the blockchain with a fix for the reported bug. It will be gated behind a - chain variable which requires that all blockchain participants (hotspot, router, node, and etl) - update to prevent a chain halt. We typically allow at least a week before issuing a new chain - variable. Further notice will be sent for chain variable activation schedule. - -- #### [blockchain-core#864](https://github.com/helium/blockchain-core/pull/864): Fix deadlock when continuing to load snapshot - - The core developers noticed that some Hotspots would crash and not recover correctly when trying - to ingest a snapshot, this fixes that. Please read the PR description for more details. - -### Plan - -We have been beta testing `2021.06.14.0` since June 14th, 2021 5:00 PM PT. Current ETA for GA is -1:30 PM PT, June 15th, 2021. diff --git a/devblog/2021-06-16-console-updates-1.9.53.mdx b/devblog/2021-06-16-console-updates-1.9.53.mdx deleted file mode 100644 index 3866f68f6..000000000 --- a/devblog/2021-06-16-console-updates-1.9.53.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 1.9.53 -date: 2021-06-17 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The team focused on delivering an pre-built integration for Microshare in addition to continuing to -build out our roaming capabilities for non-Helium traffic. - - - -### Features and fixes - -- Provided a pre-built Integration for Microshare. -- Packet purchaser: support transfer of both uplinks and downlinks of non-Helium packets to other - LoRaWAN Network Servers. -- Enhanced Event Graph with more information for uplinks/downlinks. -- Updated NetID parsing for internal metrics. -- Addressed issue that prevented certain label notifications from sending. - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. To update, check the - newest instructions, rebuild, and restart. The database is not affected. - -Check the readme for specific upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Microsoft Azure IoT Hub pre-built Integration -- Scaling State Channels -- CFList appended to JoinAccept: https://github.com/helium/router/issues/322 -- Support AS923 for Australia -- Console 2.0 migration testing -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-06-17-app-version-330.mdx b/devblog/2021-06-17-app-version-330.mdx deleted file mode 100644 index e37e01845..000000000 --- a/devblog/2021-06-17-app-version-330.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: post -title: App Version 3.3.0 -date: 2021-06-17 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Release 3.3.0 - -Hexagons on the Helium Network - - - -We are introducing hexagons on the Helium network! We heard your feedback on how privacy is -important to all Hotspots owners, and we completely agree. This new release will represent your -Hotspot in a hexagon instead of a precise location. - -With this, we also introduce map filters: your owned and followed Hotspots, witnesses, and transmit -scale. - -Read more on our blog: https://blog.helium.com/history-in-hexagons-633775c184a Link to dev docs: -https://docs.helium.com/wallets/app-wallet/hexagons/ - -## Improvements: - -Hotspot Onboarding list now has a filter function to quickly get to the Hotspot Maker you need. - -Understand Scaling - tap on the Transmit Scale number to read our help guide. - -Witness List - -- Instead of showing average witnesses (that refreshes too frequent to be useful in any context), we - show a list of Hotspots that have witnessed your beacon based on proof-of-coverage receipts, over - the last 5 days. - -Checklist - -- We updated the checklist to be more clear and fixed a few bugs while we’re at it - -## Makers: - -Add SenseCap Maker - -Add support for QR Code Onboarding - -## Bug Fix: - -Show DC unit for pending payments - -Fix Wi-Fi showing as connected after disconnecting - -Fix Relayed Hotspot logic to only show when there is no ip4 listen addresses - -Fix Bluetooth Android crash when pressing scan 6 times in a row. diff --git a/devblog/2021-06-17-blockchain-release-network-improvements-and-snapshot-update.mdx b/devblog/2021-06-17-blockchain-release-network-improvements-and-snapshot-update.mdx deleted file mode 100644 index 1419c9b45..000000000 --- a/devblog/2021-06-17-blockchain-release-network-improvements-and-snapshot-update.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Network Improvements' -date: 2021-06-17 16:33 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.06.18.0` Hotspot firmware release which contains network -improvements related to NAT and bug fixes related to staking for Validators. This is a _required_ -release for Hotspot owners. As some of the community members have noticed that the blockchain has -not generated a new snapshot since the last GA, we believe that the improvements to networking and -an increment to snapshot memory generation limit will fix snapshot generation. The core developers -plan to do another minor release with a snapshot update once it gets generated by the blockchain. - - - -Below are the related PRs: - -- #### Network improvements - - The core developers have squashed a few NAT related bugs in `erlang-libp2p`, we believe these - fixes should significantly improve Hotspot sync. - - - [erlang-libp2p#356](https://github.com/helium/erlang-libp2p/pull/356): Stand a relay if stungun - repeatedly fails to verifiably resolve - - [erlang-libp2p#355](https://github.com/helium/erlang-libp2p/pull/355): Handle relay server - crashing and re-acquire a relay address - - [erlang-libp2p#354](https://github.com/helium/erlang-libp2p/pull/354): Cancel retry timer on - relay stop command - - [erlang-libp2p#353](https://github.com/helium/erlang-libp2p/pull/353): Once NAT type is - detected, stop trying to re-detect it - - [erlang-libp2p#351](https://github.com/helium/erlang-libp2p/pull/351): Make 3 distinct observed - addresses trigger static NAT determination - - [erlang-libp2p#350](https://github.com/helium/erlang-libp2p/pull/350): Improve static port map - discovery for other NAT types - -- #### Blockchain Bug fixes - - A few `blockchain-core` bug fixes are also packed in this release specifically around snapshot - generation and staking bugs observed on the Testnet. - - - [blockchain-core#870](https://github.com/helium/blockchain-core/pull/870): Increase snapshot - generation memory limit - - [blockchain-core#868](https://github.com/helium/blockchain-core/pull/868): Move tenure penalties - to the beginning of the election round - - [blockchain-core#865](https://github.com/helium/blockchain-core/pull/865): Fix off-by-one - validation error in `blockchain_txn_unstake_validator_v1` - -### Plan - -We have been beta testing `2021.06.18.0` since June 18th, 2021 10:30 AM PT. Current ETA for GA is -2:00 PM PT, June 18th, 2021. diff --git a/devblog/2021-06-18-app-version-331.mdx b/devblog/2021-06-18-app-version-331.mdx deleted file mode 100644 index 7fd4b0c08..000000000 --- a/devblog/2021-06-18-app-version-331.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -layout: post -title: App Version 3.3.1 -date: 2021-06-18 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Release 3.3.1 - -This release fixes 2 bugs: - -- Fixes a bug where RAK and Syncrob.it were not on the Hotspot onboarding list. -- Fixes a bug when the app goes in background, the privacy splash screen disappears. diff --git a/devblog/2021-06-21-blockchain-release-blessed-snapshot-update.mdx b/devblog/2021-06-21-blockchain-release-blessed-snapshot-update.mdx deleted file mode 100644 index 1d7f892e4..000000000 --- a/devblog/2021-06-21-blockchain-release-blessed-snapshot-update.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Blessed Snapshot Update' -date: 2021-06-21 09:22 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.06.21.0` Hotspot firmware release which only has a new -blessed snapshot update. This is an optional but recommended release for Hotspot owners; the updated -blessed snapshot will help new and lagging Hotspots to sync to blockchain head faster. - - - -#### PR - -- [miner#833](https://github.com/helium/miner/pull/833): Update blessed snapshot to 891361 - -### Plan - -We have been beta testing `2021.06.21.0` since June 21st, 2021 8:15 AM PT. Current ETA for GA is -11:00 AM PT, June 21st, 2021. diff --git a/devblog/2021-06-24-blockchain-release-validator-and-state-channel-updates.mdx b/devblog/2021-06-24-blockchain-release-validator-and-state-channel-updates.mdx deleted file mode 100644 index 0eb0efc76..000000000 --- a/devblog/2021-06-24-blockchain-release-validator-and-state-channel-updates.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Validator Support and State Channel Updates' -date: 2021-06-25 10:45 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.06.25.0` Hotspot firmware release which contains updates -to support better transaction validation for Validators and improvements to State Channel -scalability. This is a _required_ release for Hotspot owners as it introduces new chain variables -which will get activated at a later date. - - - -- #### Miner Updates - - This miner release includes Validator and JSON RPC support. Please feel free to read validator - docs and browse through the PRs listed below for further details: - - - [miner#629](https://github.com/helium/miner/pull/629): Validator support - - [miner#804](https://github.com/helium/miner/pull/804): JSON RPC support - -- #### Blockchain Updates - - The core developers have added support for a new chain variable `validator_key_check` to guard - `blockchain_txn_stake_validator_v1` and `blockchain_txn_transfer_validator_stake_v1` against using - keys from the wrong network. - - - [blockchain-core#881](https://github.com/helium/blockchain-core/pull/881): Fix validator - transfer stake transaction - - [blockchain-core#879](https://github.com/helium/blockchain-core/pull/879): Fix validator stake - transaction - -- ##### State Channel Improvements - - The core developers have updated state channels to be more scalable as the network grows by - introducing a new `sc_max_actors` chain variable and allowing validation of more than `10` - simultaneous state channels. - - - [blockchain-core#852](https://github.com/helium/blockchain-core/pull/852): Fix state channel - server to allow more state channels and overspill - -- ##### Miscellaneous `blockchain-core` Fixes - - A few `blockchain-core` bug fixes are also packed in this release specifically around ledger - upgrades when ingesting snapshots and transaction manager fixes. Related PRs are listed below: - - - [blockchain-core#877](https://github.com/helium/blockchain-core/pull/877): Don't run ledger - upgrades before checking snapshot sync - - [blockchain-core#875](https://github.com/helium/blockchain-core/pull/875): Default - is_gateway_new_location to true - - [blockchain-core#869](https://github.com/helium/blockchain-core/pull/869): Add escape hatch for - allowing unstaking validator - - [blockchain-core#866](https://github.com/helium/blockchain-core/pull/866): Transaction manager - tuning - -### Plan - -We have been beta testing `2021.06.25.0` since June 25th, 2021 11:30 AM PT. Current ETA for GA is -2:30 PM PT, June 25th, 2021. diff --git a/devblog/2021-06-25-chain-halt-postmortem.mdx b/devblog/2021-06-25-chain-halt-postmortem.mdx deleted file mode 100644 index eabe6e6e8..000000000 --- a/devblog/2021-06-25-chain-halt-postmortem.mdx +++ /dev/null @@ -1,108 +0,0 @@ ---- -layout: post -title: Chain Halt Postmortem -date: 2021-06-25 19:18 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers prepared an emergency release `2021.06.25.3` to fix the Mainnet blockchain halt -noticed around 4:00 PM PST, June 25th, 2021. This was a **mandatory** release for all blockchain -participants on the network. Hotspot manufacturers who have not picked up this release should update -their fleets. Please read further for more details. - - - -## What Happened? - -The core developers noticed that blockchain had stopped making blocks and came to halt. A rundown of -the timeline of events is as follows: - -### Timeline - -- **Fri Jun 25 04:13:00 PM PDT 2021** - - The core developers receive an alert for block production halt. - -- **Fri Jun 25 04:30:00 PM PDT 2021** - - A potential bug is identified. The issue seems to be related to prematurely garbage collected - state channels. - -- **Fri Jun 25 05:17:00 PM PDT 2021** - - State channel garbage collection fixed in - [blockchain-core#883](https://github.com/helium/blockchain-core/pull/883) and miner tagged - `2021.06.25.1`. - -- **Fri Jun 25 07:00:00 PM PDT 2021** - - Another issue in miner identified wherein HoneyBadgerBFT state was not getting set properly on - restore. Fixed in [miner#855](https://github.com/helium/miner/pull/855) and tagged `2021.06.25.2`. - -- **Fri Jun 25 07:06:00 PM PDT 2021** - - Another state related bug identified in miner. Fixed in - [miner#856](https://github.com/helium/miner/pull/856) and tagged `2021.06.25.3`. - -- **Fri Jun 25 08:21:00 PM PDT 2021** - - Team confers that `2021.06.25.3` is an eligible candidate for GA. miner tagged `2021.06.25.3_GA`. - -- **Fri Jun 25 08:30:00 PM PDT 2021** - - As the blockchain continues to be halted, core developers issue a rescue block - [896680](https://explorer-old.helium.com/blocks/896680) to unstick the chain and continue to - monitor. Rewards between 4 PM PST - 8:20 PM PST are never minted and chain variable `max_open_sc` - is lowered from `10` to `5` to reduce potential size of the next election block containing reward - transaction. - -- **Sat Jun 26 02:00:00 AM PDT 2021** - - Block production still not back to normal but since there was a successful election and blocks are - being produced slowly, the team decides to allow the chain to recover by itself overnight. - -- **Sat Jun 26 05:00:00 AM PDT 2021** - - Final HoneyBadgerBFT deserialization issues fixed in - [miner#860](https://github.com/helium/miner/pull/860) and miner tagged `2021.06.26.0_GA`. - Blockchain returns back to normal block time and election cycles. - -### Incident Summary - -At some point prior to the Consensus Group election at that caused the halt, one of the State -Channels that records packet transmission data was inappropriately deleted. This has never happened -before. When the Consensus Group tried to calculate the rewards for the election epoch, all members -ran into an error, crashed, and halted the chain. This is a straight forward halt that typically can -be resolved with an OTA but the core developers had recently released a new image that contained -numerous changes to consensus handling, and had changed chain variables related to how many state -channels could be open at any one time. All three of these issues contributed to the extended -recovery time and the need to issue a Rescue Block and replace the Consensus Group. - -While we had a fix in place for the consensus group quickly, we were unable to move forward with it -because of some bugs in some quite hard to test code which had been recently refactored. This was -fixed in small increments until we found that while consensus members were able to boot, they could -not construct the rewards for this epoch without running out of memory. At this point, we decided -that, although we had the code in place to calculate these rewards, the risk was too high that this -epoch was too complicated for the existing rewards code to calculate. The decision was made to omit -the rewards for this epoch, intentionally, while also reverting the chain variable change to state -channels so that rewards would no longer be risky to calculate. - -After the rescue block, the chain proceeded and made blocks, but extremely slowly. At this point the -team decided to go to sleep with alarms re-enabled and see how things were in the morning. Come the -morning, an east coast team member discovered the bugs in the recent refactor and issued a new image -to resolve them, restoring block times to normal. - -## Future - -A chain halt is an undesired consequence of a major change in blockchain behavior and issues like -these occur when there are big feature updates, the previous release included Validator and updated -State Channel support and some missing code does eventually slip through the cracks. The core -developers are committed to do regular maintenance updates and be vigilant for such issues in the -future. - -Some specific action items: - -- Conclusively determine the cause of the premature State Channel GC. -- Improve tests around restore after upgrade if possible. -- Refactor reward generation to be less memory intensive. diff --git a/devblog/2021-06-29-blockchain-release-maintenance-update.mdx b/devblog/2021-06-29-blockchain-release-maintenance-update.mdx deleted file mode 100644 index a2302fb9b..000000000 --- a/devblog/2021-06-29-blockchain-release-maintenance-update.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Maintenance Update' -date: 2021-06-29 11:34 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.06.29.0` Hotspot firmware release which primarily -contains maintenance updates to potentially reduce block times and enhance block sync. This is an -_optional_ but recommended release for Hotspot owners. - - - -- #### Blockchain Updates - - The primary highlights of `blockchain-core` changes are updates for better block sync times and - reduced block creation times. Please feel free to browse through the relevant PRs listed below: - - - [blockchain-core#746](https://github.com/helium/blockchain-core/pull/746): Adjust block sync to - select a random publicly available peer - - [blockchain-core#375](https://github.com/helium/blockchain-core/pull/375): Fix witness garbage - collection on chain - - [blockchain-core#885](https://github.com/helium/blockchain-core/pull/885): Fix duplicate - transaction error in blockchain transaction manager - -### Plan - -We have been beta testing `2021.06.29.0` since June 29th, 2021 10:15 AM PT. Current ETA for GA is -2:30 PM PT, June 29th, 2021. diff --git a/devblog/2021-06-30-app-version-332.mdx b/devblog/2021-06-30-app-version-332.mdx deleted file mode 100644 index 134c12920..000000000 --- a/devblog/2021-06-30-app-version-332.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: App Version 3.3.2 -date: 2021-06-30 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Release 3.3.2 - -## New Features - -• Show Hotspot's gain and elevation - -• Adds initial transaction support for staking transactions - - - -## Bug Fixes - -• Only show outages if it relates to Hotspot owners - -• Fixes bug when burning HNT to DC from Console - -• Shows proper error message when onboarding server is down diff --git a/devblog/2021-06-30-blockchain-release-networking-improvements.mdx b/devblog/2021-06-30-blockchain-release-networking-improvements.mdx deleted file mode 100644 index c58f5f913..000000000 --- a/devblog/2021-06-30-blockchain-release-networking-improvements.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Networking Improvements' -date: 2021-06-30 12:41 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.06.30.0` Hotspot firmware release which contains updates -to improve peerbook performance and a new blessed snapshot. This is an _optional_ but recommended -release for Hotspot owners. - - - -- #### Blockchain Updates - - The core developers fixed a few issues related to corrupted ledger and libp2p dials. Please read - through the PRs listed below for further details: - - - [blockchain-core#892](https://github.com/helium/blockchain-core/pull/892): Delete corrupt ledger - on open - - [blockchain-core#891](https://github.com/helium/blockchain-core/pull/891): Reduce sync noise, - change errors to exits - -- #### Libp2p Updates - - The team has also made several peerbook related performance updates. Details available in the PRs - listed below: - - - [erlang-libp2p#361](https://github.com/helium/erlang-libp2p/pull/361): Truncate connected - sessions, improve random peer selection - - [erlang-libp2p#360](https://github.com/helium/erlang-libp2p/pull/360): Don't allow a relay - address which points to itself - - [erlang-libp2p#359](https://github.com/helium/erlang-libp2p/pull/359): Increment random - connection limit for gossip - -### Plan - -We have been beta testing `2021.06.30.0` since June 30th, 2021 1:00 PM PT. Current ETA for GA is -2:30 PM PT, June 30th, 2021. diff --git a/devblog/2021-06-30-console-updates-1.9.54.mdx b/devblog/2021-06-30-console-updates-1.9.54.mdx deleted file mode 100644 index 9cd6027dc..000000000 --- a/devblog/2021-06-30-console-updates-1.9.54.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 1.9.54 -date: 2021-07-01 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This week we’re excited to release Console 2.0 beta on our staging server. Console 2.0 beta -represents months of work by the team and we’re excited to share with our community and get their -feedback. - - - -Check the Console 2.0 beta announcement [here](https://bit.ly/3waPF7x). - -### Features and fixes - -- Console 2.0 beta released to staging server. -- First phase of scaling state channels to support network growth -- Roaming in addition to uplinks/downlinks also includes joins (using ABP) -- Clear pending downlinks request as part of the backend downlink response (integration) - [293](https://github.com/helium/router/issues/293) -- Decoded payload is available for dynamic URL parameters - [307](https://github.com/helium/router/issues/307) -- CFList appended to JoinAccept for US915 [322](https://github.com/helium/router/issues/322) - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. To update, check the - newest instructions, rebuild, and restart. The database is not affected. - -Check the readme for specific upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Microsoft Azure IoT Hub pre-built Integration -- Gateway monitoring -- Support AS923 for Australia -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-07-02-blockchain-release-new-snapshot.mdx b/devblog/2021-07-02-blockchain-release-new-snapshot.mdx deleted file mode 100644 index e23d0c261..000000000 --- a/devblog/2021-07-02-blockchain-release-new-snapshot.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: New snapshot' -date: 2021-07-02 17:31 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.07.02.0` Hotspot firmware release which contains a new -blessed snapshot and minor maintenance updates. This is an _optional_ but recommended release for -Hotspot owners. - - - -- #### Related PRs - - - [miner#890](https://github.com/helium/miner/pull/890): New blessed snap-904710 - - [miner#888](https://github.com/helium/miner/pull/888): Fix missing key info fields - - [miner#884](https://github.com/helium/miner/pull/884): Bind JSONRPC port to 0.0.0.0 (thanks - [@PaulVMo](https://github.com/PaulVMo)!) - - [miner#880](https://github.com/helium/miner/pull/880): Fix .deb packagecloud - - [ecc#9](https://github.com/helium/ecc508/pull/9): Add support for specifying ECC address (thanks - [@ccrisan](https://github.com/ccrisan)!) - -### Plan - -We have been beta testing `2021.07.02.0` since July 2nd, 2021 5:00 PM PT. Current ETA for GA is 8:30 -PM PT, July 2nd, 2021. diff --git a/devblog/2021-07-09-blockchain-release-gossip-updates.mdx b/devblog/2021-07-09-blockchain-release-gossip-updates.mdx deleted file mode 100644 index 7b9e8c83e..000000000 --- a/devblog/2021-07-09-blockchain-release-gossip-updates.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Gossip Updates' -date: 2021-07-09 17:40 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.07.09.2` Hotspot firmware release which contains a new -blessed snapshot and gossip improvements. This is an _optional_ but recommended release for Hotspot -owners. - - - -- #### Related PRs - - - [blockchain-core#905](https://github.com/helium/blockchain-core/pull/905): Eagerly gossip - plausible blocks - - [blockchain-core#901](https://github.com/helium/blockchain-core/pull/901): Select active state - channel on state_channel_server startup - - [miner#907](https://github.com/helium/miner/pull/907): Update rocks db config for validators - - [miner#914](https://github.com/helium/miner/pull/914): Add random peer predicate function to - enable gossiping with validators - - [miner#918](https://github.com/helium/miner/pull/918): Bump to new snapshot, exclude for - validators - - [libp2p#364](https://github.com/helium/erlang-libp2p/pull/364): Add adjustable random peer - predicate - -### Plan - -We have been beta testing `2021.07.09.2` since July 9th, 2021 5:00 PM PT. Current ETA for GA is 9:30 -AM PT, July 10th, 2021. diff --git a/devblog/2021-07-11-blockchain-release-snapshot-performance-update.mdx b/devblog/2021-07-11-blockchain-release-snapshot-performance-update.mdx deleted file mode 100644 index a1741fefe..000000000 --- a/devblog/2021-07-11-blockchain-release-snapshot-performance-update.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Performance Update' -date: 2021-07-11 15:21 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.07.11.0` Hotspot firmware release which contains -performance improvements to snapshot ingestion. This is an _optional_ but _highly_ recommended -release for Hotspot owners and manufacturers especially for those Hotspots which are based on older -Raspberry Pi3 hardware. - - - -- #### Related PRs - - - [blockchain-core#910](https://github.com/helium/blockchain-core/pull/910): Lazy snapshot field - de-serialization - - [miner#906](https://github.com/helium/miner/pull/906): Put Raspberry Pi3-based Hotspots into - non-validation mode by default. - -### Plan - -We have been beta testing `2021.07.11.0` since July 11th, 2021 2:30 PM PT. Current ETA for GA is -5:00 PM PT, July 11th, 2021. diff --git a/devblog/2021-07-13-blockchain-release-snapshot-fixes.mdx b/devblog/2021-07-13-blockchain-release-snapshot-fixes.mdx deleted file mode 100644 index 26a094596..000000000 --- a/devblog/2021-07-13-blockchain-release-snapshot-fixes.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Fixes' -date: 2021-07-13 15:08 -0700 -hide_table_of_contents: true -authors: [vihu, evanmcc, cokes518] ---- - -The core developers have tagged a new `2021.07.13.1` Hotspot firmware release which contains -snapshot ingestion improvements and a newly blessed snapshot. This is a _mandatory_ release for -Hotspot owners and manufacturers to continue syncing with newly blessed snapshots. - - - -This release contains a much newer snapshot for block height 920126, and follows on the emergency -release on the weekend to make it even easier for older Hotspots to sync by eliminating some -time-consuming and unnecessary work. It also fixes a bug in snapshot loading that caused some -Hotspots that loaded the last snap to halt and stop syncing. Finally, this release fixes a rare -issue with restarting that can cause some Hotspots to halt until a corrupted cache file was manually -deleted. - -- #### Related PRs - - - [blockchain-core#916](https://github.com/helium/blockchain-core/pull/916): Fix snapshot - ingestion - - [blockchain-core#913](https://github.com/helium/blockchain-core/pull/913): Faster non-validation - mode - - [libp2p#362](https://github.com/helium/erlang-libp2p/pull/362): Clean up corrupted cache file - - [miner#925](https://github.com/helium/miner/pull/925): Updates deps and bless snap-920076 - -### Plan - -We have been beta testing `2021.07.13.1` since July 13th, 2021 1:30 PM PT. Current ETA for GA is -5:30 PM PT, July 13th, 2021. diff --git a/devblog/2021-07-14-app-version-340.mdx b/devblog/2021-07-14-app-version-340.mdx deleted file mode 100644 index 2949e538a..000000000 --- a/devblog/2021-07-14-app-version-340.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: post -title: App Version 3.4.0 -date: 2021-07-14 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Release 3.4.0 - -## New Features - -3.4.0 Includes a small facelift to our Wallet and Hotspot tabs! - - - -Hotspot Tab - -- We have introduced a new shortcut navigation menu that allows you to quickly swipe through all the - Hotspots you own and follow - -Wallet Tab - -- Updated UI layout on Wallet tab with new send and receive icons, easier QR code discoverability, - and a filter for transaction types -- If you’ve staked Validators, we now show the staked amount - -## Improvements - -- Improve how we calculate a Hotspot’s sync status by using the last gossiped timestamp to API - instead of gossiped block through the p2p network -- Inform users that Discovery Mode results may be inconsistent -- Update hexagon colors for accessibility - -## Bug Fixes - -- When asserting a location, check that the location actually changed -- Fix a bug when scanning QR code for payments with varying formats -- Fix a bug with the default email address when sharing from Diagnostic Reports - -## Known Issue - -- Hotspot Checklist > Sync Status is showing incorrect data. We’ll be fixing this in 3.4.1. diff --git a/devblog/2021-07-14-blockchain-release-more-snapshot-fixes.mdx b/devblog/2021-07-14-blockchain-release-more-snapshot-fixes.mdx deleted file mode 100644 index e670fb41d..000000000 --- a/devblog/2021-07-14-blockchain-release-more-snapshot-fixes.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: More Snapshot Fixes' -date: 2021-07-14 16:26 -0700 -hide_table_of_contents: true -authors: [vihu, madninja] ---- - -The core developers have tagged a new `2021.07.15.0` Hotspot firmware release which introduces more -snapshot related fixes. This is a _mandatory_ release for Hotspot owners and manufacturers to -continue syncing with newly blessed snapshots. - - - -This release improves on the -[previous](https://engineering.helium.comhttps://docs.helium.com/blog/2021/07/13/blockchain-release-snapshot-fixes.html) -release and fixes some critical issues related to light gateway support, snapshot disagreement and -non-invalidation (follow) mode. As many community members have noticed, there hasn't been a blessed -snapshot on the blockchain for a while, the core developers believe that the fixes in this new -release will further improve chances of getting a snapshot on chain. - -- #### Related PRs - - - [blockchain-core#914](https://github.com/helium/blockchain-core/pull/914): Force clean - witnesses, don't allow them to be added, disable gc - - [blockchain-core#915](https://github.com/helium/blockchain-core/pull/915): Fix add light gateway - validation - - [blockchain-core#917](https://github.com/helium/blockchain-core/pull/917): Add a - no_staking_mapping test - - [blockchain-core#918](https://github.com/helium/blockchain-core/pull/918): Cover more checkpoint - code under the follow mode check - - [blockchain-core#920](https://github.com/helium/blockchain-core/pull/920): Zero out the last - location nonce - - [blockchain-core#921](https://github.com/helium/blockchain-core/pull/921): Diff more gateway - fields in snapshot diff - -### Plan - -We have been beta testing `2021.07.15.0` since July 15th, 2021 10:00 AM PT. Current ETA for GA is -12:00 PM PT, July 15th, 2021. diff --git a/devblog/2021-07-15-console-updates-1.9.55.mdx b/devblog/2021-07-15-console-updates-1.9.55.mdx deleted file mode 100644 index 5b932c335..000000000 --- a/devblog/2021-07-15-console-updates-1.9.55.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 1.9.55 -date: 2021-07-15 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, madninja] ---- - -This release the team worked on addressing issues reported for Console 2.0 beta and also backend -fixes to make joins and packet transfer more reliable. - - - -### Join and uplink issues - -A number of issues have impacted joins and uplinks over the past few weeks. Here’s a list of updates -made to address these issues as well as upcoming fixes. - -Hotspot syncing - an issue causing earlier versions of Hotspots to continually sync, which could -have impacted packet delivery was fixed -[blog](https://engineering.helium.comhttps://docs.helium.com/blog/2021/07/11/blockchain-release-snapshot-performance-update.html) - -State channels - increased the maximum number of open state channels to 10 (from 5) which helps -Console backend (Router) serve more packets as the demand on using the network continues to -increase. For more information about state channels and their role check -[here](https://blog.helium.com/helium-state-channels-383ade2368d0) - -Channel frequency list (CFlist)- this feature was enabled according to feedback from the community, -however it was discovered to cause issues if device firmware did not closely adhere to the LoRaWAN -spec. Based on community feedback we’ve included a toggle to enable it, but disabled it by default. - -XOR filter - to help scale in an upcoming release we are updating the production Console/Router to -use an xor filter. This will allow the backend to only process known traffic and avoid spending -resources on unfamiliar packets. More information about xor filters -[here](https://docs.helium.com/lorawan-on-helium/#join-request-frames-and-filters). - -### Features and fixes - -- Updates to Console 2.0 beta on staging server based on feedback. - - Staging UI: Icons without text descriptions of their actions - [647](https://github.com/helium/console/issues/674) - - Staging UI Tweeks: Device Name [677](https://github.com/helium/console/issues/677) -- Provided a new Label setting to enable CFList for supported devices US915 (default off). -- Opening device detail in new tab has strange behavior - [653](https://github.com/helium/console/issues/653) -- Provide a backend cache to help address late packets - [343](https://github.com/helium/router/issues/343), - [338](https://github.com/helium/router/issues/338) - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - - To update, check the newest instructions, rebuild, and restart. The database is not affected. - - Libressl-dev has been swapped with openssl-dev in the Dockerfile dependencies list. This simply - requires a rebuild. - - If you experience issues running Console/Router locally, update Docker to the latest version and - pick up the changes in docker-compose-local.yaml - -Check the readme for specific upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Microsoft Azure IoT Hub pre-built Integration -- Gateway monitoring -- Support AS923 for Australia -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-07-16-app-version-341.mdx b/devblog/2021-07-16-app-version-341.mdx deleted file mode 100644 index 31aec1adc..000000000 --- a/devblog/2021-07-16-app-version-341.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: App Version 3.4.1 -date: 2021-07-16 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Release 3.4.1 - -## Improvements - -- Users with 15+ Hotspots in their wallet account were experiencing performance degradation. This is - now fixed -- Add Web Onboarding type to support new Hotspot Makers - - - -## Bug Fixes - -- Checklist now uses the new syncing logic -- Show account balance when loading the wallet tab and fetching activity -- Allows QR Payment amount to be a number or a string - -## Known Issues - -- When selecting a Hotspot from a hex, the cursor does not snap to the Hotspot in the Shortcut - Navigation menu. diff --git a/devblog/2021-07-19-blockchain-release-new-snapshot-and-follow-mode.mdx b/devblog/2021-07-19-blockchain-release-new-snapshot-and-follow-mode.mdx deleted file mode 100644 index b1b57d146..000000000 --- a/devblog/2021-07-19-blockchain-release-new-snapshot-and-follow-mode.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: New Snapshot and Follow Mode' -date: 2021-07-19 16:40 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.07.19.0` Hotspot firmware release which updates the -currently blessed snapshot, introduces state channel related improvements and switches all Hotspots -to non-validation (follow mode). This is an optional but _recommended_ release for Hotspot owners -and manufacturers to continue syncing with newly blessed snapshots. - - - -- #### Related PRs - - [blockchain-core#880](https://github.com/helium/blockchain-core/pull/880): Only count open state - channels as active - - [blockchain-core#908](https://github.com/helium/blockchain-core/pull/908): Improve state channel - performance - - [miner#943](https://github.com/helium/miner/pull/943): Add new blessed snapshot, switch all - Hotspots to follow mode with a fallback - - Much thanks to [@ke6jjj](https://github.com/ke6jjj) for enhancing JSONRPC support in the PRs - below: - - [miner#937](https://github.com/helium/miner/pull/937): Implement ability to query stats for a - single validator - - [miner#931](https://github.com/helium/miner/pull/931): Implement hbbft_perf for JSONRPC - - Finally thanks to [@BenoitDuffez](https://github.com/BenoitDuffez) for updating the dbus - endpoint in the below PRs: - - [miner#935](https://github.com/helium/miner/pull/935): Add height dbus endpoint - - [miner#934](https://github.com/helium/miner/pull/934): Add block age dbus endpoint - -### Plan - -We have been beta testing `2021.07.19.0` since July 19th, 2021 2:20 PM PT. Current ETA for GA is -6:00 PM PT, July 19th, 2021. diff --git a/devblog/2021-07-19-console-updates-2.0.mdx b/devblog/2021-07-19-console-updates-2.0.mdx deleted file mode 100644 index 4c92da836..000000000 --- a/devblog/2021-07-19-console-updates-2.0.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -layout: post -title: Console 2.0 Upcoming Release -date: 2021-07-19 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -After many months of work and testing based on community feedback, the team plans to release Console -2.0 on Thursday 7/29. - - - -There will be two major changes to Console with the release of 2.0: - -- The new Flows feature which you can read about more - [here](https://blog.helium.com/console-2-0-beta-test-and-earn-swag-ee366734779). - -- Using the xor filter to add devices to the blockchain. - -During the release of Console 2.0 to production on 7/29, there’s a planned maintenance period from -10 am to 12 pm PDT. Despite the Console interface being inaccessible during this time, devices will -continue to send data. - -**XOR filter = improved performance** - -As network usage increases, the XOR filter allows the Console backend (router) to only process known -traffic and avoid spending resources on unfamiliar packets, which significantly improves -performance. - -However, the 1st time a device joins the network its keys need to be added to the blockchain and the -updated block propagated to the miners (Hotspots). - -This initial join process could take up to 15 mins depending on: - -- when this transaction (batched with others) gets added to the blockchain -- the overall performance of the blockchain - -**What do I need to do?** - -There’s no action required. Your devices and configurations will be preserved and you won’t need to -take any action. In addition, your Data Credit balances will remain unchanged. - -Before release, you can test devices and integrations at Console 2.0 beta -[here](https://staging-console.helium.wtf/). - -1. Devices can only be in one Console organization. In other words, you can't use the same device - that's currently in another Organization. - -2. Make sure you're only logged into one Console instance at a time (for example, if you’re testing - on Console 2.0 beta, don’t also have a production Console instance open). - -3. Console 2.0 beta uses the xor filter, so devices added for the 1st time could take up to 15 - minutes. - -Thanks again for your support. - -The Console team diff --git a/devblog/2021-07-20-app-version-342.mdx b/devblog/2021-07-20-app-version-342.mdx deleted file mode 100644 index 0ad5859f7..000000000 --- a/devblog/2021-07-20-app-version-342.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: App Version 3.4.2 -date: 2021-07-20 -hide_table_of_contents: true -authors: [cokes518] ---- - -## Bug Fixes - -- Improves Shortcut loading performance -- Fixes Discovery Mode modal not extending under status bar -- Fixes the “Next” button logic for Web/QR Code onboarding - - - -## Improvements - -- Updates default antenna type for Nebra Hotspots - -## Known Issues - -- Accounts with 20+ Hotspots may still experience poor app performance. This will be addressed in - the next release in a new feature called “Fleet Mode” -- When viewing several Hotspot details in a row, sometimes the data doesn't load unless you close - the card and reopen it diff --git a/devblog/2021-07-22-blockchain-release-network-and-snapshot-improvements.mdx b/devblog/2021-07-22-blockchain-release-network-and-snapshot-improvements.mdx deleted file mode 100644 index 55b4d08a1..000000000 --- a/devblog/2021-07-22-blockchain-release-network-and-snapshot-improvements.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Network and Snapshot Improvements' -date: 2021-07-22 14:01 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.07.22.0` Hotspot firmware release which updates the -currently blessed snapshot and contains networking and snapshot improvements. This is an optional -but _recommended_ release for Hotspot owners and manufacturers to continue syncing with newly -blessed snapshots. - - - -- #### Related PRs - - - [blockchain-core#923](https://github.com/helium/blockchain-core/pull/923): Faster state channel - server side broadcast with caching - - [blockchain-core#909](https://github.com/helium/blockchain-core/pull/909): Make snapshot - download and load into discrete steps - - [blockchain-core#889](https://github.com/helium/blockchain-core/pull/889): Update debit_fee to - include potential implicit burn storage. Thanks [@syuan100](https://github.com/syuan100)! - - [blockchain-core#798](https://github.com/helium/blockchain-core/pull/798): Fix for loading a - snapshot with an aux ledger - - - [libp2p#366](https://github.com/helium/erlang-libp2p/pull/366): Make faster connected addr lists - - [libp2p#335](https://github.com/helium/erlang-libp2p/pull/335): Manage the stungun timer better - - - [hbbft#71](https://github.com/helium/erlang-hbbft/pull/71): Remove PBC based cryptography - - - [miner#952](https://github.com/helium/miner/pull/952): Bump core and update snap for 7/22 - release - - [miner#939](https://github.com/helium/miner/pull/939): Clean up JSON/RPC API for proper use of - errors and data types. Thanks [@ke6jjj](https://github.com/ke6jjj)! - - [miner#929](https://github.com/helium/miner/pull/929): Upgrade to hbbft version without PBC - encryption support - -### Plan - -We have been beta testing `2021.07.22.0` since July 22nd, 2021 12:30 PM PT. Current ETA for GA is -6:00 PM PT, July 22nd, 2021. diff --git a/devblog/2021-07-26-app-version-343.mdx b/devblog/2021-07-26-app-version-343.mdx deleted file mode 100644 index 344ffa26c..000000000 --- a/devblog/2021-07-26-app-version-343.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: App Version 3.4.3 -date: 2021-07-26 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Fleet Mode - -- Fleet Mode is a new feature for accounts with more than 20+ Hotspots that reduces the API calls it - makes and improves app performance -- Read more on [Helium Docs](https://docs.helium.com/wallets/app-wallet/fleet-mode/) - - - -# Improvements - -- Welcome summary now includes 24h Validator earnings -- Refactored how the app calculates Rewards and Earnings, so it should be much faster now -- App uses the new Hotspot sync logic and is now the same as Explorer -- Updates compileSdkVersion to 30 for Android -- Updates Nebra Onboarding Information - -# Bug Fixes - -- Fixes infinite loop when deep linking Hotspot diff --git a/devblog/2021-07-29-console-updates-2.0.mdx b/devblog/2021-07-29-console-updates-2.0.mdx deleted file mode 100644 index fdc848b06..000000000 --- a/devblog/2021-07-29-console-updates-2.0.mdx +++ /dev/null @@ -1,103 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.0 -date: 2021-07-29 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -After many months of work and testing based on community feedback, the team is excited to announce -the official release of Console 2.0! The team not only worked on new features and capabilities, but -also focused on making sure migration to Console 2.0 would be seamless for existing users. - - - -The two major changes to Console with the release of 2.0 are the Flows feature and the use of the -XOR filter. - -### Flows - -Flows makes it easy for users to transfer data from devices to endpoints by providing a -visual-centric view of the key elements: devices, functions, and integrations. No more reliance on -Labels to act as the superglue, on the Flows workspace devices directly connect to function or -integrations. Labels are soley used to group devices for better organization allowing flexibility as -your projects scale and grow. - -### XOR Filter - -The XOR filter allows the Console back-end, Router, to only process known traffic which will -significantly improve performance by allowing Router to avoid spending resources on unfamiliar -packets. - -**Important: The first time a device joins the Network, its keys need to be added to the blockchain -and the updated block propagated to the miners (Hotspots) and this initial join process could take -up to 20 mins depending on:** - -- When this transaction (batched with others) gets added to the Helium blockchain -- The overall performance of the blockchain - -### XOR Filter Details - -The device attempts a new join via XOR filter associated with the paired OUI. The OUI includes a set -of devaddrs that will be assigned to newly joined devices (note these devaddrs do not need to be -unique for each device, the combination of application key is used to avoid conflicts). - -New devices are assigned to a devaddr which are handed out based on the OUI. The `app_eui`, and -`dev_eui` are added to the XOR filter which is then written to the blockchain (added to a block and -propagated to miners). This process could take up to 20 mins. - -Gateways use device `app_eui`, `dev_eui` to query the blockchain via xor filter to identify which -OUI to send join packets. - -Router which belongs to OUI receives join request, sends down a join accept, and assigns the -NwkAddr. - -For future uplinks, gateways use a device’s devaddr to identify which router/oui to send to which is -significantly quicker. - -### Features and fixes - -- Continued optimization with state channels to improve performance including increasing the number - of actors per state channel. -- Device 'Last Modified' date shows current date/time - [707](https://github.com/helium/console/issues/707). -- Missing Device name, EUI & other info in Group - [704](https://github.com/helium/console/issues/704). -- Make Initial organization dc balance as a parameter - [683](https://github.com/helium/console/issues/683). -- Staging UI Tweaks: Device Name [677](https://github.com/helium/console/issues/677). - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -To update, view upgrading instructions -[here](https://github.com/helium/console/releases/tag/2021.07.29). The database is not affected. - -Check the readme for overall upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Migrating Devices from Staging to Production Console - -For users migrating devices from staging to production, perform the following: - -1. Deactivate device(s) on staging (can do individually or from the Organization section can - deactivate all). -2. Add device on production Console. -3. Wait up to 20 mins for device to get added to production. -4. After confirmation device is functioning as expected, delete device on staging. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Gateway monitoring -- Microsoft Azure IoT Hub pre-built Integration -- Support AS923 for Australia -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-07-30-blockchain-release-snapshot-update.mdx b/devblog/2021-07-30-blockchain-release-snapshot-update.mdx deleted file mode 100644 index 0bbc1fb17..000000000 --- a/devblog/2021-07-30-blockchain-release-snapshot-update.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Update' -date: 2021-07-30 07:30 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.07.29.0` Hotspot firmware release which updates the -currently blessed snapshot, adds a new seed node to the statically configured list, adjusts address -hashing for Hotspot identification, and contains minor bug fixes. This is an optional but -_recommended_ release for Hotspot owners and manufacturers to continue syncing with newly blessed -snapshots. - - - -- #### Related PRs - - - [blockchain-core#928](https://github.com/helium/blockchain-core/pull/928): Fix clean_dir - function to filter correctly - - [miner#960](https://github.com/helium/miner/pull/960): Add new seed node to miner config - - [miner#959](https://github.com/helium/miner/pull/959): Update new blessed snap-941761 - - [miner#958](https://github.com/helium/miner/pull/958): Add new VIP router to node_aliases - -### Plan - -We have been beta testing `2021.07.29.0` since July 29th, 2021 1:30 PM PT. Current ETA for GA is -8:30 AM PT, July 30th, 2021. diff --git a/devblog/2021-07-31-blockchain-release-networking-and-snapshot-improvements.mdx b/devblog/2021-07-31-blockchain-release-networking-and-snapshot-improvements.mdx deleted file mode 100644 index 3dcf06acb..000000000 --- a/devblog/2021-07-31-blockchain-release-networking-and-snapshot-improvements.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Networking and Snapshot Improvements' -date: 2021-07-31 09:55 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The core developers have tagged a new `2021.07.30.0` Hotspot firmware release which updates the -currently blessed snapshot, fixes a minor bug in snapshot downloads from the Amazon S3 source, and a -community contribution from [@PaulVMo](https://github.com/PaulVMo) that improves libp2p -identification of private IP addresses. This is an optional but _recommended_ release for Hotspot -owners and manufacturers to continue syncing with newly blessed snapshots. - - - -- #### Related PRs - - - [erlang-libp2p#368](https://github.com/helium/erlang-libp2p/pull/368): Expand IP bogon list - - [blockchain-core@b55319](https://github.com/helium/blockchain-core/commit/b55319b7cc46da3334a262314022daca1888df5e): - Bump libp2p dependency for bogon fix and fix snapshot download cleanup process - - [miner@a16147](https://github.com/helium/miner/commit/a161473a4b257641ee1068207f19138e4832b71e): - Update blockchain-core and update snapshot to 944641 - -### Plan - -We have been beta testing `2021.07.30.0` since July 30th, 2021 2:15 PM PT. Current ETA for GA is -10:15 AM PT, July 31st, 2021. diff --git a/devblog/2021-08-02-blockchain-release-snapshot-update.mdx b/devblog/2021-08-02-blockchain-release-snapshot-update.mdx deleted file mode 100644 index 0719e3e53..000000000 --- a/devblog/2021-08-02-blockchain-release-snapshot-update.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Update' -date: 2021-08-02 14:55 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.08.02.0` Hotspot firmware release which updates the -currently blessed snapshot and handles IPv6 addresses in bogon check. This release also removes the -default Helium production router from the static configuration to help meet the demands on -utilization on the network - - - -This is an optional but _recommended_ release for Hotspot owners and manufacturers to continue -syncing with newly blessed snapshots. - -- #### Related PRs - - - [erlang-libp2p#369](https://github.com/helium/erlang-libp2p/pull/369): Handle IPv6 addresses in - bogon check. Thanks [@PaulVMo](https://github.com/PaulVMo)! - - [miner#962](https://github.com/helium/miner/pull/962): Update blessed snap to snap-948961 - - [miner#950](https://github.com/helium/miner/pull/950): Remove default routers from prod config - -### Plan - -We have been beta testing `2021.08.02.0` since Aug 2nd, 2021 10:30 AM PT. Current ETA for GA is 5:00 -PM PT, Aug 2nd, 2021. - -### Additional Notes - -After issuing the GA release yesterday, the core developers noticed that the release did not include -the specific libp2p fix referenced above. We will be issuing a subsequent release `2021.08.02.1` at -10:30 AM PT, Aug 3rd 2021. diff --git a/devblog/2021-08-05-app-version-344.mdx b/devblog/2021-08-05-app-version-344.mdx deleted file mode 100644 index 2295fac4c..000000000 --- a/devblog/2021-08-05-app-version-344.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: post -title: App Version 3.4.4 -date: 2021-08-05 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Improvements - -- Update LongAP Descriptions -- Add Maker type to Hotspot Details\* -- Add Linxdot, ClodPi, and Pisces to Hotspot Onboarding - - - -## \*How the App Determines Maker Type - -The app (and soon explorer) looks at the payer of the add_gateway transaction, and from there, looks -up the DeWi approved Makers in the onboarding server. - -If you have one of the earlier RAK Hotspot v1s, you may see “Helium” next to your manufacturer. This -is because Helium Inc paid the onboarding fees for everyone, including RAK Hotspots at the earlier -stages of network expansion. There is nothing wrong with this and doesn’t affect your earnings in -any way. - -If you have onboarded a Data Only Hotspot, you will not see a Maker type. - -# Bug Fixes - -- Wallet chart graph number wrapped in a funny way when there are too many numbers. This is fixed. -- Fixed typo in Wallet blank state -- Handle the case for newly added Hotspots without a online status -- Attempt #1 to fix commas as decimal separator for Samsung keyboards -- Fixed a checklist bug where a task can be pending and complete at the same time -- Updates challenge interval to 300 - -# Known Issues - -- The wallet chart may take 30s or more to load. The workaround is to select a different time - selector (like 12W) and toggle back. - [We’ll look to fix this in the next release](https://github.com/helium/hotspot-app/issues/861) -- If you skip assert in the onboarding flow and try to assert later, the app crashes. - [We’re still investigating this issue](https://github.com/helium/hotspot-app/issues/867). diff --git a/devblog/2021-08-06-blockchain-release-snapshot-update.mdx b/devblog/2021-08-06-blockchain-release-snapshot-update.mdx deleted file mode 100644 index 8cfd9f2bb..000000000 --- a/devblog/2021-08-06-blockchain-release-snapshot-update.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Update and state channel fixes' -date: 2021-08-06 08:30 -0700 -hide_table_of_contents: true -authors: [vagabond] ---- - -The core developers have tagged a new `2021.08.05.0` Hotspot firmware release which updates the -currently blessed snapshot and includes some fixes for state channel handling for packet routing. -The release also includes support for fetching more seed nodes from DNS and some fixes for other -applications using blockchain-core (router and ETL). - - - -This is an optional but _recommended_ release for Hotspot owners and manufacturers to continue -syncing with newly blessed snapshots. We also believe this release will improve an issue with -'bursting' packets on router that has been observed. - -- #### Related PRs - - - [erlang-libp2p#337](https://github.com/helium/erlang-libp2p/pull/337): Allow seed nodes to be - resolved from DNS records - - [miner#967](https://github.com/helium/miner/pull/967): Update blessed snap to snap-953281 - - [blockchain-core#939](https://github.com/helium/blockchain-core/pull/939): Handle stale state - channel banners correctly - - [blockchain-core#938](https://github.com/helium/blockchain-core/pull/938): Don't send state - channel banners on normal packet reception - - [blockchain-core#936](https://github.com/helium/blockchain-core/pull/936): Improve state channel - logging for clarity and performance - - [blockchain-core#937](https://github.com/helium/blockchain-core/pull/937): Fix to json for - consensus group failure transaction - - [blockchain-core#935](https://github.com/helium/blockchain-core/pull/935): Allow custom key for - transaction manager cache - -### Plan - -We have been beta testing `2021.08.05.0` since Aug 5th, 2021 3:30 PM PT. Current ETA for GA is 10:00 -AM PT, Aug 6th, 2021. diff --git a/devblog/2021-08-11-blockchain-release-seed-node-dns.mdx b/devblog/2021-08-11-blockchain-release-seed-node-dns.mdx deleted file mode 100644 index 1463df522..000000000 --- a/devblog/2021-08-11-blockchain-release-seed-node-dns.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Seed Node DNS and Snapshot Update' -date: 2021-08-11 09:30 -0700 -hide_table_of_contents: true -authors: [vagabond, abhay] ---- - -The core developers have tagged a new `2021.08.11.0` Hotspot firmware release which allows a new way -to fetch seed nodes from DNS, updates the currently blessed snapshot, and contains a few other small -fixes - - - -This is an optional but _recommended_ release for Hotspot owners and manufacturers to continue -syncing with newly blessed snapshots. - -- #### Related PRs - - - [erlang-libp2p#370](https://github.com/helium/erlang-libp2p/pull/370): Don't crash random peer - selection when no peers exist - - [miner#975](https://github.com/helium/miner/pull/975): Update blessed snap to snap-959041 - - [miner#972](https://github.com/helium/miner/pull/975): Fetch seed nodes from CNAME DNS record - - [miner#868](https://github.com/helium/miner/pull/868): Clarify connected status in p2p info - -### Plan - -We have been beta testing `2021.08.11.0` since Aug 10th, 2021 3:30 PM PT. Current ETA for GA is -11:30 AM PT, Aug 11th, 2021. - -### Update - -The core developers noticed that the above release was incompatible with the way connectedness is -reported in Hotspot Diagnostic Reports. We have been testing `2021.08.11.2` that reverts these -changes since 5:30 PM PT, Aug 11th, 2021 and will GA immediately. We recommend that other Hotspot -manufacturers deploy this version of the miner code base instead. - -Sorry for the inconvenience! diff --git a/devblog/2021-08-13-app-version-345.mdx b/devblog/2021-08-13-app-version-345.mdx deleted file mode 100644 index 8b9f613e8..000000000 --- a/devblog/2021-08-13-app-version-345.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: App Version 3.4.5 -date: 2021-08-13 -hide_table_of_contents: true -authors: [cokes518] ---- - -## New Features - -**Support for Data-Only Hotspots** - -- Now you can search and follow data-only Hotspots on the app, and see information specific to - data-only Hotspots. - - - -**Notification Filters** - -- On the notifications tab, filter by the type of message (Helium Updates, failed notifications, - transfer Hotspots, and more). - -## Improvements - -- Adds introductory text to diagnostic report emails requesting additional information -- Improved rewards loading for wallet tab -- Adds Cotx Hotspot to Onboarding -- Update Bobcat Diagnostic Screen - -## Bug Fixes - -- Fixes an app crash when setting a location that has none diff --git a/devblog/2021-08-18-blockchain-release-minor-updates.mdx b/devblog/2021-08-18-blockchain-release-minor-updates.mdx deleted file mode 100644 index 1f0c5ef30..000000000 --- a/devblog/2021-08-18-blockchain-release-minor-updates.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Minor Updates' -date: 2021-08-18 14:11 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.08.16.0` Hotspot firmware release which is a maintenance -update to primarily update static seed nodes in miner. This is an optional but _recommended_ release -for Hotspot owners and manufacturers to improve network performance. - - - -- #### Related PRs - - - [miner#985](https://github.com/helium/miner/pull/985): Update static seed nodes - - [miner#980](https://github.com/helium/miner/pull/980): Update README and cleanup docs. Thanks - [@jthiller](https://github.com/jthiller)! - - [gateway-config#73](https://github.com/helium/gateway-config/pull/73): Add a disk status - diagnostic based on a touch file in /tmp - -### Plan - -We have been beta testing `2021.08.16.0` since Aug 16th, 2021 6:00 PM PT. Current ETA for GA is 3:30 -PM PT, Aug 18th, 2021. diff --git a/devblog/2021-08-19-app-version-346.mdx b/devblog/2021-08-19-app-version-346.mdx deleted file mode 100644 index 4a4e54cc4..000000000 --- a/devblog/2021-08-19-app-version-346.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -layout: post -title: App Version 3.4.6 / 3.4.7 -date: 2021-08-19 -hide_table_of_contents: true -authors: [cokes518] ---- - -## Improvements - -- Add support for disk health in diagnostic reports -- Allow data-only Hotspots to update antenna gain and elevation - - - -## Bug Fixes - -- HTML in diagnostic reports -- Additional fixes for assert location app crashes -- Fixes onboarding for Kerlink and FreedomFi diff --git a/devblog/2021-08-21-blockchain-release-snapshot-fixes.mdx b/devblog/2021-08-21-blockchain-release-snapshot-fixes.mdx deleted file mode 100644 index 9c711bca0..000000000 --- a/devblog/2021-08-21-blockchain-release-snapshot-fixes.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Fixes' -date: 2021-08-21 17:35 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.08.21.0` Hotspot firmware release which contains major -blockchain-core updates specifically ensuring that snapshots are correctly getting loaded. -Furthermore this release supplies a new snapshot to allow new and un-synced hotspots to continue -syncing. This is _mandatory_ release for all hotspot manufacturers. - - - -- #### Related PRs - - - [miner#997](https://github.com/helium/miner/pull/997): Update blessed snapshot to snap-975601 - - [miner#974](https://github.com/helium/miner/pull/974): Fix peer_book RPC call provided with p2p - address. Thanks [@LilaQ](https://github.com/LilaQ)! - - [miner#956](https://github.com/helium/miner/pull/956): Bump sibyl and grpcbox deps. Fix for - grpcbox socket restart issue - - [blockchain-core#954](https://github.com/helium/blockchain-core/pull/954): Fix performance of - snapshot loads in direct mode - - [blockchain-core#951](https://github.com/helium/blockchain-core/pull/951): Avoid inconsistent - snapshots by acquiring the blockchain lock - - [blockchain-core#953](https://github.com/helium/blockchain-core/pull/953): Check for a - rewards_metadata in rewards_v2 to_json opts - - [blockchain-core#950](https://github.com/helium/blockchain-core/pull/950): Allow txn_key to be - any term - - [blockchain-core#934](https://github.com/helium/blockchain-core/pull/934): Use direct rocksdb - operations when loading snap and fix snapshot sync check - - [blockchain-core#943](https://github.com/helium/blockchain-core/pull/943): Clean up scratch - files when cleaning snap dir - -### Plan - -We have been beta testing `2021.08.21.0` since Aug 21st, 2021 5:00 PM PT. Current ETA for GA is 6:00 -PM PT, Aug 21st, 2021. diff --git a/devblog/2021-08-24-blockchain-release-new-snapshot-and-minor-fixes.mdx b/devblog/2021-08-24-blockchain-release-new-snapshot-and-minor-fixes.mdx deleted file mode 100644 index a23436e35..000000000 --- a/devblog/2021-08-24-blockchain-release-new-snapshot-and-minor-fixes.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: 'Blockchain Emergency Release: Snapshot Fixes' -date: 2021-08-24 15:14 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.08.24.4` emergency Hotspot firmware release which -contains important snapshot load fixes and a new blessed snapshot. This is a _mandatory_ release for -all hotspot manufacturers to enable the loading of new snapshots. - - - -- #### Related PRs - - - [miner#e02d871def08867a8ecaa2b75155758a82a4a46](https://github.com/helium/miner/commit/e02d871def08867a8ecaa2b75155758a82a4a46): - Bump snap to 979921 - - [blockchain-core#967](https://github.com/helium/blockchain-core/pull/967): Make partial snapshot - loads very obvious and avoidable - - [erlang-libp2p#377](https://github.com/helium/erlang-libp2p/pull/377): Don't pay attention to - bogon observed IPs - -### Plan - -We have been beta testing `2021.08.24.4` since Aug 24th, 2021 2:30 PM PT. Current ETA for GA is 4:45 -PM PT, Aug 24th, 2021. diff --git a/devblog/2021-08-26-console-updates-2.0.1.mdx b/devblog/2021-08-26-console-updates-2.0.1.mdx deleted file mode 100644 index 79bbee3d0..000000000 --- a/devblog/2021-08-26-console-updates-2.0.1.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.0.1 -date: 2021-08-26 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -While the team focused on the Gateway Monitoring feature, this sprint they also knocked off a number -of frontend and backend issues reported by the community. In addition, an out-of-band update was -released last week to address a number of issues. - - - -### Features and fixes - -- Multi-packet issues: late packets: [396](https://github.com/helium/router/issues/396) -- Console UI updates: editing Device and Function names -- Enabled AWS downlinks: [790](https://github.com/helium/console/issues/790) -- Provided Pending indicator on individual device page upon initial join -- Minor system email content inconsistency issues fixed -- Resolved a search issue when using Safari -- Users able to unenroll from 2-factor authentication -- Fixed an issue that prevented users from deleting organizations -- Label metadata for devices included in uplink integration requests -- Fixed issue with `nginx-default.conf` template where the `X-Forwarded-For` header was not being - passed to the docker container -- Added additional mandatory and optional environment variables to open source `.env` template - -Out-of-band update released last week: - -- In certain situations Console UI was not kept updated with actual DC count. -- Frame counter management causing "Uplink dropped: Late" packets over AU915: - https://github.com/helium/router/issues/379 -- State channel optimization work -- Addressed GRPC server restart issue that was impacting light Hotspots -- Self-hosted router repeats error bad argument: https://github.com/helium/router/issues/407 -- Multi-purchase packet not working in certain congested situations: - https://github.com/helium/router/issues/343 - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -Check the readme for upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -This release includes changes in `nginx-default.conf` and `.env` open source template files. Please -review the updated files and make changes to your local files as you see fit. - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Gateway monitoring feature -- Microsoft Azure IoT Hub pre-built Integration -- Implement decision for Australia frequency based on Decentralized Wireless Alliance and community - decision -- Packet purchaser: provide capability to only receive single copy of packets -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-08-31-blockchain-release-stability-and-performance-updates.mdx b/devblog/2021-08-31-blockchain-release-stability-and-performance-updates.mdx deleted file mode 100644 index f7ee06724..000000000 --- a/devblog/2021-08-31-blockchain-release-stability-and-performance-updates.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Stability and Performance Updates' -date: 2021-08-31 14:18 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.08.31.1` Hotspot firmware release which contains major -blockchain and libp2p stability and performance updates. This is a _mandatory_ release for all -hotspot manufacturers to continue syncing the blockchain. - - - -- #### Related PRs - - - [miner#1017](https://github.com/helium/miner/pull/1017): Add european router - - [miner#1010](https://github.com/helium/miner/pull/1010): Parameterize transaction validation - width - - [blockchain-core#975](https://github.com/helium/blockchain-core/pull/975): Explicitly purge - duplicated transactions from cache whilst purging mined txns - - [blockchain-core#972](https://github.com/helium/blockchain-core/pull/972): All around fixes for - HIP-28 support - - [blockchain-core#912](https://github.com/helium/blockchain-core/pull/912): Fix snapshot types - and upgrades - - [blockchain-core#947](https://github.com/helium/blockchain-core/pull/947): Introduce - listen_addresses parameter to specify listen IP. Thanks [@PaulVMo](https://github.com/PaulVMo)! - - [blockchain-core#963](https://github.com/helium/blockchain-core/pull/963): Speedup POC - transaction validation - - [blockchain-core#964](https://github.com/helium/blockchain-core/pull/964): Fix the consensus - rewards to take net emissions into account - - [blockchain-core#967](https://github.com/helium/blockchain-core/pull/967): Make partial snapshot - loads very obvious and avoidable - - [blockchain-core#962](https://github.com/helium/blockchain-core/pull/962): Log for - absorb_and_commit height. Thanks [@syuan100](https://github.com/syuan100)! - - [blockchain-core#956](https://github.com/helium/blockchain-core/pull/956): Precalculate - densities for HIP-17 - - [blockchain-core#926](https://github.com/helium/blockchain-core/pull/926): Add support for net - emissions - - [blockchain-core#922](https://github.com/helium/blockchain-core/pull/922): HIP-28 consensus - reward calculate grace period. Thanks [@PaulVMo](https://github.com/PaulVMo)! - - - [libp2p#377](https://github.com/helium/erlang-libp2p/pull/377): Don't pay attention to bogon - observed IPs - - [libp2p#378](https://github.com/helium/erlang-libp2p/pull/378): Continue to monitor IP changes - even after NAT type is resolved - - [libp2p#379](https://github.com/helium/erlang-libp2p/pull/379): Handle race between resolving - static nat and port forward - -### Plan - -We have been beta testing `2021.08.31.1` since Aug 31st, 2021 1:00 PM PST. Current ETA for GA is -11:00 AM PST, Sept 1st, 2021. diff --git a/devblog/2021-09-03-blockchain-release-snapshot-update.mdx b/devblog/2021-09-03-blockchain-release-snapshot-update.mdx deleted file mode 100644 index 52a361906..000000000 --- a/devblog/2021-09-03-blockchain-release-snapshot-update.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Update' -date: 2021-09-03 10:12 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The core developers have tagged a new `2021.09.03.0` Hotspot firmware release which contains a -snapshot update. Please note that this tag is based off of `2021.08.31.1` and not on miner master as -the team wants to continue testing PoCv11 changes that landed on master yesterday. - - - -This is an _optional_, but recommended, release for all hotspot manufacturers to help catch up their -respective fleets to the latest block. - -- #### Related PRs - - - [miner#1028](https://github.com/helium/miner/pull/1028): Bump snap to 994321 - -### Plan - -We have been beta testing `2021.09.03.0` since Sept 3rd, 2021 10:00 AM PT. Current ETA for GA is -12:30 PM PT, Sept 3rd, 2021. diff --git a/devblog/2021-09-07-app-version-350/consensus_group.png b/devblog/2021-09-07-app-version-350/consensus_group.png deleted file mode 100644 index b0d9dfd7b..000000000 Binary files a/devblog/2021-09-07-app-version-350/consensus_group.png and /dev/null differ diff --git a/devblog/2021-09-07-app-version-350/hide_hotspot.png b/devblog/2021-09-07-app-version-350/hide_hotspot.png deleted file mode 100644 index 172c17545..000000000 Binary files a/devblog/2021-09-07-app-version-350/hide_hotspot.png and /dev/null differ diff --git a/devblog/2021-09-07-app-version-350/hide_hotspot2.png b/devblog/2021-09-07-app-version-350/hide_hotspot2.png deleted file mode 100644 index f4ce7899e..000000000 Binary files a/devblog/2021-09-07-app-version-350/hide_hotspot2.png and /dev/null differ diff --git a/devblog/2021-09-07-app-version-350/index.mdx b/devblog/2021-09-07-app-version-350/index.mdx deleted file mode 100644 index f665db683..000000000 --- a/devblog/2021-09-07-app-version-350/index.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -layout: post -title: App Version 3.5.0 -date: 2021-09-07 -hide_table_of_contents: true -authors: [cokes518] ---- - -App Version 3.5.0 - -  - -# New Features - -## Hide Hotspot - -Have a Hotspot that has met their untimely demise and the daily reminders just reminds you of the -good old days and it just hurts too much? Or maybe you want to hide it for other reasons - we don't -judge. Now you can hide it from app view (but it’ll stay associated with your account). To unhide -Hotspots, go to Settings to view hidden Hotspots. - - - -![hide_hotspot](./hide_hotspot.png) - -![hide_hotspot2](./hide_hotspot2.png) - -## Validators - -This new release enables anyone to search, follow, and view their validators! Do you have validators -staked in a different wallet, but want to keep tabs on it? Search and Follow and it’ll appear in the -app, see its earnings, penalties, online status, and how many consensus groups it's been in. - -You'll also be able to see the current consensus group in the app. - -![validator](./validator.png) - -![consensus_group](./consensus_group.png) - -## Adds iPad support - -Take advantage of the screen real estate and use the app on an iPad. Thanks @compojoom for the -contribution :raisehands: - -## Payment Notifications - -Receive an app notification any time someone sends you HNT. - -# New Hotspot Support - -Adds FreedomFi, Controllino, and Heltec to Hotspot list. - -# Improvements - -## Adds unasserted Hotspot filter when in Fleet Mode - -When in Fleet Mode, adds a new Hotspot filter list to show all unasserted Hotspots you own. Thanks -for the feature suggestion @pooley92! - -## Improves error message when adding a Hotspot not found in the Onboarding server - -We no longer speak nonsense when a Hotspot does not exist on the onboarding server. - -# Bug Fixes - -- Handle `/` in add_gateway transactions generated from QR codes and deeplinking gracefully and not - crash -- Handle misasserted locations when showing Hotspot witnesses -- Fixes gain keyboard input for all locales diff --git a/devblog/2021-09-07-app-version-350/validator.png b/devblog/2021-09-07-app-version-350/validator.png deleted file mode 100644 index 939174017..000000000 Binary files a/devblog/2021-09-07-app-version-350/validator.png and /dev/null differ diff --git a/devblog/2021-09-09-console-updates-2.1.1.mdx b/devblog/2021-09-09-console-updates-2.1.1.mdx deleted file mode 100644 index 2360f3963..000000000 --- a/devblog/2021-09-09-console-updates-2.1.1.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.1.1 -date: 2021-09-09 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -A major feature the team’s worked on for the last two sprints is Coverage. Unlike Hotspot monitoring -tools focused on maximizing mining rewards, Coverage is built for users of the network who want to -have more visibility about which Hotspots are transferring device packets as well as displaying the -status of those Hotspots all from within Console. - - - -### Features and fixes - -- Coverage: identify which Hotspots are transferring packets, view Hotspot status, and display - packet transfer data all from within Console. For more details go - [here](https://docs.helium.com/use-the-network/console/coverage/). -- Added label back to metadata transferred with payloads. -- Added `hold_time` to debug mode. `Hold_time` provides useful information for Console users to - identify if a Hotspot was holding on to a packet (in milliseconds). -- Provide capability to dedupe packets in the Packet Purchaser. -- Removed the default devaddr as it was no longer relevant. - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -Check the readme for upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Microsoft Azure IoT Hub pre-built Integration -- Expanding Console APIs -- Foundational work for roaming services -- Light Hotspot support -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-09-14-major-blockchain-release-pocv11-support-snapshot-updates-performance-improvements.mdx b/devblog/2021-09-14-major-blockchain-release-pocv11-support-snapshot-updates-performance-improvements.mdx deleted file mode 100644 index cd5456ef3..000000000 --- a/devblog/2021-09-14-major-blockchain-release-pocv11-support-snapshot-updates-performance-improvements.mdx +++ /dev/null @@ -1,109 +0,0 @@ ---- -layout: post -title: 'Major Blockchain Release: PoCv11 Support, Snapshot Updates, Performance Improvements' -date: 2021-09-14 12:36 -0700 -hide_table_of_contents: true -authors: [abhay, vihu] ---- - -The core developers have tagged a new `2021.09.14.0` Hotspot firmware release which contains several -updates including support for PoCv11 (not yet activated), updates to snapshot loading, several -libp2p and rewards performance changes. - - - -This is a required release for all hotspot manufacturers as it contains a few chain variable -dependent code changes that will be released after a two week period of testing for regressions. - -### Proof of Coverage v11 Support - -This release includes support for the update to Proof of Coverage system. This upgrade will be -further described in a blog post later this week but this release allows developers to begin testing -chain variables using the auxiliary ledger. No action is required by Hotspot owners at this time. - -### PoC Address Hash Update - -The core developers have removed a stray change that caused address hashes to be calculated on the -/24 octet of a Challenger's IP address. This may have an impact on PoC Rate that the community -should continue to monitor. Thanks [@ci-work](https://github.com/ci-work)! - -### PoC Random Witness Selection - -This release also includes a randomization function for witness collection. After this release, a -_random subset_ of witnesses will be reported back to the chain, rather than the _fastest_ witness. -This should provide more diversity of witness information and allow developers to reduce the number -of total witnesses to `10` from the current value of `25`. This reduction (a chain variable that -will be released later today) should help improve performance of PoC and the blockchain as a whole. - -### AU915 Channel Plan Update - -This release removes a 500KHz channel from the AU915 channel plan. This was mistakenly added in a -prior release. - -### Networking Improvements - -This release also includes two networking improvements that should help Hotspots report the correct -IP address to other blockchain participants. It also introduces a new configuration setting for -makers: - -```erl -{libp2p, {ip_confirmation_host, "https://ifconfig.co"}} -``` - -This configuration uses the ifconfig service to programmatically verify the Hotspot's IP address. -Makers may choose to update the endpoint to one that fits their customer's needs. - -### Snapshot Updates - -This release fixes some issues with snapshot loading, specifically with a Net Emissions related -variable that was causing snapshot loading to fail and download cleanup issue that was leaving large -partial downloads on disk. - -#### Related PRs - -- [miner#1049](https://github.com/helium/miner/pull/1049): Update miner for gw capability and mode - changes -- [miner#1042](https://github.com/helium/miner/pull/1042): Fix for los POCs, thanks - [@ci-work](https://github.com/ci-work)! -- [miner#1039](https://github.com/helium/miner/pull/1039): Remove 500KHz channel from AU915 -- [miner#1038](https://github.com/helium/miner/pull/1038): Fix PoC transmission channel selection - logic, thanks [@ke6jjj](https://github.com/ke6jjj)! -- [miner#1030](https://github.com/helium/miner/pull/1030): Fix debian build -- [miner#1026](https://github.com/helium/miner/pull/1026): Use a random selection of witnesses - instead of the first limit -- [miner#924](https://github.com/helium/miner/pull/924): Fix some of the state channel tests to call - newer functions -- [miner#854](https://github.com/helium/miner/pull/854): Log more when doing heartbeat txns -- [miner#817](https://github.com/helium/miner/pull/817): Add support for POC-V11 - -- [blockchain-core#996](https://github.com/helium/blockchain-core/pull/996): Decode the net missions - terms before attempting to write them -- [blockchain-core#995](https://github.com/helium/blockchain-core/pull/995): Use full paths to - delete files -- [blockchain-core#993](https://github.com/helium/blockchain-core/pull/993): State channel grpc - return types -- [blockchain-core#990](https://github.com/helium/blockchain-core/pull/990): Fix backward compat due - to infos issue -- [blockchain-core#987](https://github.com/helium/blockchain-core/pull/987): Election v6 using lists -- [blockchain-core#984](https://github.com/helium/blockchain-core/pull/984): Make rewards - memoization pid-local -- [blockchain-core#979](https://github.com/helium/blockchain-core/pull/979): More poc - receipts/requests performance work -- [blockchain-core#961](https://github.com/helium/blockchain-core/pull/961): Add peer sync CLI -- [blockchain-core#776](https://github.com/helium/blockchain-core/pull/776): Add support for POC-V11 -- [blockchain-core#723](https://github.com/helium/blockchain-core/pull/723): Add support for state - channel client/server communcation via grpc - -- [libp2p#386](https://github.com/helium/erlang-libp2p/pull/386): Use a configurable external - service to verify external IP addresses -- [libp2p#383](https://github.com/helium/erlang-libp2p/pull/383): Resolve another race condition in - NAT resolution - -- [sibyl#13](https://github.com/helium/sibyl/pull/13): Add additional fields to is_active response -- [sibyl#11](https://github.com/helium/sibyl/pull/11): Refactor for updated protos, add - is_overpaid_sc api and update tests - -### Plan - -We have been beta testing `2021.09.14.0` and prior release candidates since since Sept 9, 2021 2:00 -PM PT. Current ETA for GA is 2:15 PM PT, Sept 14th, 2021. diff --git a/devblog/2021-09-17-blockchain-release-blockchain-sync-improvements.mdx b/devblog/2021-09-17-blockchain-release-blockchain-sync-improvements.mdx deleted file mode 100644 index b5c785dea..000000000 --- a/devblog/2021-09-17-blockchain-release-blockchain-sync-improvements.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Blockchain Sync Improvements' -date: 2021-09-17 08:29 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The core developers have tagged a new `2021.09.16.1` Hotspot firmware release which primarily -includes performance improvements for Hotspots. You can read about them below. This release also -updates the blessed snapshot to `1012321`. - - - -This is a **required** release for all hotspot manufacturers and we recommend especially those with -Raspberry PI 3 or similar hardware to upgrade quickly. See the note below on Snapshot changes for -more details on why this is a required release. - -### Improvements to Block Absorption / Chain Sync - -The root cause for blockchain sync issues in the past few weeks have been due to the size of the -network and Hotspots with weaker hardware not being able to absorb blocks fast enough to keep up -with the chain. This release should help OG Helium Hotspots, Bobcats, Nebras, and other similar -hardware. - -**Your Hotspot will need to be fully synced before PoC activity resumes and you are again able to -earn HNT for providing coverage.** - -### Changes to Snapshots - -An important note for manufacturers and "fast sync" features. Snapshots generated by Validators and -Hotspots after this release (`1.3.3` and `2021.09.16.1`, respectively) will not work on older -Hotspots. Please plan accordingly with snapshot generation. - -In addition, miners (and other participants that are in "follow-mode") will no longer generate -snapshots. This should help reduce spikes in memory and CPU utilization when miners are generating -snapshots. This is no longer needed on Hotspots as Validators are responsible for generating -snapshots for the chain. - -### Various Bugfixes - -This release also includes some bugfixes around region lookups, a discovery mode bug (thanks -[@maco2035](https://github.com/maco2035) for finding and [@ke6jjj](https://github.com/ke6jjj)), and -prepares dependencies for a future Erlang/OTP 24 upgrade. - -#### Related PRs - -- [miner#1063](https://github.com/helium/miner/pull/1063): Bugfix: Region Lookup -- [miner#1063](https://github.com/helium/miner/pull/1059): Bugfix: Discovery Mode Error Handling -- [miner#1070](https://github.com/helium/miner/pull/1070): Snapshot Bump - -- [blockchain-core#998](https://github.com/helium/blockchain-core/pull/998): Speedup Block / - Transaction Absorption to help Chain syncing -- [blockchain-core#1000](https://github.com/helium/blockchain-core/pull/1000): Follow mode nodes - will no longer generate snapshots - -### Plan - -We have been beta testing `2021.09.16.1` and prior release candidates since since Sept 16, 2021 4:00 -PM PT. Current ETA for GA is 9:30 AM PT, Sept 17th, 2021. diff --git a/devblog/2021-09-22-console-updates-2.1.2.mdx b/devblog/2021-09-22-console-updates-2.1.2.mdx deleted file mode 100644 index 6db10797b..000000000 --- a/devblog/2021-09-22-console-updates-2.1.2.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.1.2 -date: 2021-09-23 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -This release includes an integration for Microsoft Azure IoT Hub. Microsoft had requested an -integration with Console based on feedback from their customers. In addition, the team made -usability updates based on community feedback, and enhanced device APIs. - - - -### Features and fixes - -- Microsoft Azure IoT Hub Integration, for information check docs - [here](https://docs.helium.com/use-the-network/console/integrations/azure/). -- Much easier to delete labels: https://github.com/helium/console/issues/731, labels info - [here](https://docs.helium.com/use-the-network/console/labels). -- Flows includes autosave feature -- Additional apis: - - `GET v1/devices/:device_id`- this endpoint now provides dc_usage, total_packets, last_connected - in the payload - - `GET v1/devices/:device_id/events`- this endpoint now provides last 100 events for desired - device - - `GET v1/devices/:device_id/events?sub_category=uplink_integration_req`- this endpoint now - provides last 10 events for desired device in the desired sub_category - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -Check the readme for upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Scale out state channels -- Continue building roaming services -- Continue to expand Console APIs -- Light Hotspot support -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-09-26-blockchain-release-networking-pocv11-and-transaction-bug-fixes.mdx b/devblog/2021-09-26-blockchain-release-networking-pocv11-and-transaction-bug-fixes.mdx deleted file mode 100644 index 35321c303..000000000 --- a/devblog/2021-09-26-blockchain-release-networking-pocv11-and-transaction-bug-fixes.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Networking, PoCv11, and Transaction Bug Fixes' -date: 2021-09-26 15:12 -0700 -hide_table_of_contents: true -authors: [abhay] ---- - -The core developers have tagged a new `2021.09.26.0` Hotspot firmware release which primarily -includes networking, PoCv11 and transaction manager bug fixes. It also includes a new core developer -blessed snapshot at height `1024971` while we wait for the validator pool to update to version -`1.3.3`. - - - -This is a **required** release for all Hotspot manufacturers as it contains bug fixes for (currently -inactive) PoCv11 code. - -### Networking Improvements - -A crash bug in the logic for deciding when to use a relay address has been fixed. This may help -hotspots in certain configurations establish more stable networking. - -### Transaction Protocol v2 - -This release introduces an update to the transaction protocol that takes into account what height -the consensus member rejected a transaction at. This is intended to help with cases of a transaction -that is marked as rejected and then clears, especially for wallet transactions. - -### PoCv11 Bug Fixes - -We've identified a few bugfixes to PoCv11 code. As this code is inactive, it shouldn't have any -impact on running Hotspots but are required for the impending release of PoCv11. - -#### Related PRs - -- [miner#1036](https://github.com/helium/miner/pull/1036): Transaction Protocol v2 -- [miner#1063](https://github.com/helium/miner/pull/1084): Bugfix: Only use RSSIS when available. - Thanks [@BenoitDuffez](https://github.com/BenoitDuffez)! - -- [blockchain-core#983](https://github.com/helium/blockchain-core/pull/983): Transaction Protocol - v2: Defer transaction rejections from the future -- [blockchain-core#1008](https://github.com/helium/blockchain-core/pull/1010): Update PoCv11 - Parameters -- [blockchain-core#1010](https://github.com/helium/blockchain-core/pull/1010): Fix PoCv11 FSPL - -- [erlang-libp2p#392](https://github.com/helium/erlang-libp2p/pull/392): Don't double bind variable - for relay server monitor (reported by nosmaster89#6016 on discord) - -### Plan - -We have been beta testing `2021.09.26.0` and prior release candidates since since Sept 24, 2021 7:00 -PM PT. Current ETA for GA is 4:00 PM PT, Sept 26, 2021. diff --git a/devblog/2021-09-28-blockchain-release.mdx b/devblog/2021-09-28-blockchain-release.mdx deleted file mode 100644 index 55b0197d2..000000000 --- a/devblog/2021-09-28-blockchain-release.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Performance Fixes' -date: 2021-09-28 11:12 -0700 -hide_table_of_contents: true -authors: [vagabond, abhay] ---- - -The core developers have tagged a new `2021.09.27.0` Hotspot firmware release which includes some -performance fixes and a bug fix to block sync. It also includes a new core developer blessed -snapshot at height `1029491`. We've identified the cause of lack of agreements on on-chain snapshots -and have issued a fix for it as well but this will require a validator release. - - - -This is a **optional** update for manufacturers. - -#### Related PRs - -- [miner#1098](https://github.com/helium/miner/pull/1098): Use Swarm TID when possible - -- [blockchain-core#1020](https://github.com/helium/blockchain-core/pull/1020): Re-run "score clean" - ledger upgrade hook to aid in snapshot agreement -- [blockchain-core#1019](https://github.com/helium/blockchain-core/pull/1019): Use Swarm TID when - possible -- [blockchain-core#1016](https://github.com/helium/blockchain-core/pull/1016): Fix handling of - plausible blocks when syncing -- [blockchain-core#1018](https://github.com/helium/blockchain-core/pull/1018): Optimize performance - of PoC request transaction absorbs -- [blockchain-core#945](https://github.com/helium/blockchain-core/pull/945): Receipts for HTLC - redemptions (thanks syuan100) -- [blockchain-core#989](https://github.com/helium/blockchain-core/pull/989): Better handling for - systems where system make is BSD make - -- [erlang-libp2p#393](https://github.com/helium/erlang-libp2p/pull/393): Don't crash on peerbook - entry with invalid signature - -### Plan - -We have been beta testing `2021.09.27.0` since Sept 27, 2021 7:00 PM PT. Current ETA for GA is 9:30 -AM PT, Sept 28, 2021. diff --git a/devblog/2021-09-30-app-version-360.mdx b/devblog/2021-09-30-app-version-360.mdx deleted file mode 100644 index a52b704b5..000000000 --- a/devblog/2021-09-30-app-version-360.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -layout: post -title: App Version 3.6.0 -date: 2021-09-30 -hide_table_of_contents: true -authors: [cokes518] ---- - -App Version 3.6.0 - -  - -# New Features - -## Deployment Mode - -Ever need to hand your phone to someone for installation but don’t want them seeing your seed -phrase, use the wallet payment functionality, or transfer Hotspots? - - - -Now you can! With deployment mode, users can “lock down” their app by hiding or disabling all -sensitive information. To enable deployment mode, go to Settings > Deployment mode. - -Please note that to disable Deployment mode, you’ll have to sign out and sign back in again. So -double check that your 12 words are written down! - -Big Thanks to Michael Brew for this contribution! - -## Check that payment transactions are to a valid wallet address - -We now have a check in the app to make sure it’s a valid wallet address so no HNT is sent to -Hotspots or Validators by mistake. - -## Scan QR Code to Assert Location - -Another Michael Brew contribution - users can now generate QR codes to assert a Hotspot’s location, -simply by going to the QR Code scanner, scanning a code, and it magically populates the update -Hotspot location fields. - -## Check the Sender is the valid owner for scanned QR Payments - -The final Michael Brew contribution, if you generate a QR code that has an embedded payment -transaction with a sender address, the app will verify that the logged in account matches the sender -before proceeding. - -## Validator Filters - -If you have owned or followed Validators, they now show up on the Home screen lists. - -# New Hotspot Support - -We’ve added PantherX and hummingbird as new options to add a Hotspot to the Helium network. - -# Bug Fixes - -- Fixed a bug where if you selected an unowned or unfollowed Hotspot, the cursor will stay on a - Hotspot name instead of scrolling back to the Explore icon. - -# Housekeeping - -## Update to City Search - -We’ve had to disable city search functionality for the time being. We look to re-enable this in the -future once we have some tools in place. - -## File Cleanup on the Hotspot-app Repository - -Thanks to @friederbluemle for keeping us honest. diff --git a/devblog/2021-10-07-console-updates-2.1.3.mdx b/devblog/2021-10-07-console-updates-2.1.3.mdx deleted file mode 100644 index eeb373068..000000000 --- a/devblog/2021-10-07-console-updates-2.1.3.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.1.3 -date: 2021-10-06 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -State channel updates to improve network performance was released to resolve a choke point caused by -the exponential growth of Hotspots providing coverage. In addition, Flows has become popular to -quickly send device data over The People’s Network and this release includes a number of usability -updates. - - - -### Features and fixes - -- Warnings and additional animations to convey status are included on nodes in the Flows Workspace -- `hold_time` added to Debug Mode- hold_time provides useful information for Console users to - identify if a Hotspot was holding on to a packet (in milliseconds). -- Allow select/unselect all to claim Hotspots on Coverage feature -- Provide ability to input wallet address in Hotspot search field. -- Coverage feature includes Debug Mode for visibility into events transferred by Hotspot -- Many link_adr_req down link messages and slow joins - [#437](https://github.com/helium/router/issues/437) - -### State Channels update - -As mentioned in previous updates network performance has suffered due to choke points and the team -has been busy re-architecting state channels to allow Console to continue to scale with network -growth. - -Specifically, the state channels server used to funnel to a single point for all incoming data. As -the network and usage grew, this approach was not sustainable as it created a choking point in the -system. The re-architected state channels will now operate with one worker being dedicated per state -channel itself (can run up to 25 state channels concurrently). This will spread out the load and -will drastically improve performance and reliability for join, uplink and downlink deliveries. - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -Check the readme for upgrading instructions -[here](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional technical documentation -[here](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Roaming services -- Configuration profiles: provide users with a streamlined way to configure, save, and apply - settings to a device or group of devices (via labels) -- Horizontal scaling -- Expand Console APIs -- Light Hotspot support -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-10-08-blockchain-release-block-gossip-state-channels-and-poc-v11-fixes.mdx b/devblog/2021-10-08-blockchain-release-block-gossip-state-channels-and-poc-v11-fixes.mdx deleted file mode 100644 index 83b773a02..000000000 --- a/devblog/2021-10-08-blockchain-release-block-gossip-state-channels-and-poc-v11-fixes.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Block Gossip, State Channels and PoC-v11 Fixes' -date: 2021-10-08 10:50 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.10.07.0` Hotspot firmware release which includes several -updates. - - - -This is a **mandatory** update for manufacturers as it contains updates to PoCv11 code that will be -required when we are ready to activate those chain variables and updates to how we will be doing -block gossip in the near future. - -## Improvements to Hotspot bandwidth utilization and Block Gossip - -We have found that as the network expands, bandwidth expectations of individual Hotspots have gone -up significantly and want to address this sooner than the Light Hotspot code is available. This -release includes preparatory work to enable lower bandwidth gossip. Details are available in the PR -listed below but at a high level, this change introduces a new protocol to gossip that dramatically -reduces bandwidth utilization. - -## Critical Bug Fixes in PoCv11 and others - -This release also fixes critical bugs that would prevent activation of PoCv11. Once this blockchain -release is on all Hotpots, Validators, ETLs, Routers and Node operators, we believe we can safely -activate PoCv11. - -## Improvements to Witness Decay Rate Implementation - -Although this implementation is not active, we found a few bugs and improvements to the -implementation of witness decay rate that could be activated through a HIP and community process to -address gaming via over-witnessing. This release updates the implementation to add a threshold and -fix some bugs found through review. - -## Transfer Hotspot v2 Support - -This release also adds support for the new `transfer_hotspot_v2` transaction. This transaction -removes the requirement of the recipient signature and removes the atomic transfer of HNT with the -transfer. The latter feature has been used by a small fraction of total Hotspot transfers. We have -also found that the implementation of requiring a recipient signature requires a centralized -coordination service which we believe should be removed in the network. This implementation is -behind a chain variable that will need to be activated once all blockchain participants have a -chance to upgrade to this release. - -## Snapshot update, Other Bug Fixes and additional OTP-24 support - -This release also addresses other miscellaneous bugs found in the past few weeks and updates the -snapshot height to `1042510`. It also adds additional support for Erlang/OTP 24 which should allow -all blockchain participants to upgrade. - -#### Related PRs - -- [miner#1107](https://github.com/helium/miner/pull/1107): Miner support for hash gossip -- [miner#1103](https://github.com/helium/miner/pull/1103): Adjust gain to float and add to summary - -- [blockchain-core#1035](https://github.com/helium/blockchain-core/pull/1035): Add packet hash to - state channel rejection -- [blockchain-core#1034](https://github.com/helium/blockchain-core/pull/1034): Add witness reward - decay rate as a legal var and add an exclusion count -- [blockchain-core#1030](https://github.com/helium/blockchain-core/pull/1030): Access chain - variables through a var-cache -- [blockchain-core#1023](https://github.com/helium/blockchain-core/pull/1023): Change block gossip - to pull model -- [blockchain-core#992](https://github.com/helium/blockchain-core/pull/992): Add support for - transfer-hotspot-v2 txn - -### Plan - -We have been beta testing `2021.10.07.0` since Oct 7, 2021 5:15 PM PT. Current ETA for GA is 1:00 PM -PT, Oct 08, 2021. diff --git a/devblog/2021-10-18-app-post-mortem.mdx b/devblog/2021-10-18-app-post-mortem.mdx deleted file mode 100644 index 543ea9e79..000000000 --- a/devblog/2021-10-18-app-post-mortem.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -layout: post -title: App Post Mortem (Oct 17 Outage) -date: 2021-10-18 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Outage Post Mortem - -This post-mortem describes the events leading up to the app outage on October 17, what happened, and -what the team is doing moving forward. - - - -## Timeline - -On Friday October 15, the team deployed a new tileserver database to bring back the data-packet map -layer on Explorer. - -**What is Tileserver?** Tileserver is the database that generates hexagons for both App and -Explorer. Whenever a Hotspot changes location, the tileserver gets updated and generates a new -hexagon to display to users. This happens on a schedule. - -This new tileserver had a feature called parallelization which generated unique hexagon IDs twice -for efficiency and to reduce API calls. This parallelization feature did not work as expected on the -mobile app and was crashing its native SDKs. The issue was not immediately apparent and the problem -grew overtime, with the symptom identified as an app crash. - -As it crashed for more users, the queries that ran on app launch, namely `hotspot rewards` that -calculates the 24h rewards for all user’s Hotspots, continued to retry, even when the app crashed. -StakeJoy API and api.helium.io (Helium’s API) saw this as “spam” as it peaked at 900 requests per -second on Sunday afternoon. Each app launch (and crash) effectively created a spammer that kept -retrying the rewards query. - -On Sunday Oct 17 around 4pm PST, Helium and StakeJoy rightly blocked the IP addresses that were -spamming, that unbeknownst to them, was from wallet-api. Later that evening, a message was returned -to the blocked IP addresses to contact the API provider to discuss next steps. This message, when -received by wallet-api, could not be parsed. The messages piled up and crashed the servers. - -**What is wallet-api?** Wallet-api is a service the app uses to query the API for data, to generate -notifications, and act as an intermediary for discovery mode and transfer Hotspot. - -### Events on October 17, 2021 - -On Oct 17 at 8:30pm PST, the team issued a - -status update -notifying the community of the app outage. - -At 9:40pm PST, the team narrowed down the root cause (crashing native SDKs due to duplicate IDs) and -recognized the wallet-api as the IP address making the hundreds of requests to both API endpoints. -The team requested the IP-ban be lifted. - -At 10:20pm PST, the team resolved the issue by pointing the app to the old tileserver (where -parallelization did not exist, thus no duplicate IDs), saw the app launch without crashing, and -requests to both API endpoints eased off. - -## Next Steps - -**Tileserver** - -- The bug fix to allow parallelization exists but is owned by a different team/company. The core - devs at Helium will attempt to fork that fix and merge it into our own repositories, but doing so - requires additional work. In the meantime, the team will continue to use the old tileserver to - generate hexagons for the next few weeks. Note that tileserver updates every few hours to draw - hexagons for newly added and asserted Hotspots - this updater will be running this evening. You - may find that Hotspots are missing hexagons until this is done. - -**Rewards Retry** - -- Removed the rewards query retry logic so if it fails (API not available etc) it won’t retry. Users - can manually force a retry by tabbing away from the Home tab, or closing/reopening the app. - -**Smarter Hotspot Rewards Query** - -- In addition to removing the retry logic, a future app release will introduce “Lazy Load Hotspot - Rewards” - this means that the app will query Hotspot rewards as the Hotspot moves into focus on - screen instead of loading it all at once on app launch. This should not have user-impact. - -**Add User Agent** - -- Helps API providers identify the service requesting data by adding a user agent to avoid - accidentally being banned. The team considered a static IP for wallet-api, but doing so would be - cost-prohibitive. - -None of the above next steps require an app release aside from lazy loading Hotspot rewards. All -other changes are being implemented and/or deployed. diff --git a/devblog/2021-10-18-blockchain-release-minor-updates-and-new-snapshot.mdx b/devblog/2021-10-18-blockchain-release-minor-updates-and-new-snapshot.mdx deleted file mode 100644 index 212f0b861..000000000 --- a/devblog/2021-10-18-blockchain-release-minor-updates-and-new-snapshot.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Minor Updates and New Snapshot' -date: 2021-10-18 17:13 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.10.18.0` Hotspot firmware release which includes some -bug fixes and a new blessed snapshot at height `1059841`. This release addresses a channel selection -bug causing unnecessary incorrect witnesses and fixes a potential race condition when initializing -`var-cache`. Furthermore, the updated `blockchain-core` has improved state channel support for -router. - - - -This is an **optional** but recommended update for manufacturers to get the latest blessed on-chain -snapshots for faster hotspot syncing. This also addresses the "invalid channel" errors that some -hotspots were seeing. - -#### Related PRs - -- [miner#1135](https://github.com/helium/miner/pull/1135): Update core and bump to snap-1059841 -- [miner#1128](https://github.com/helium/miner/pull/1128): Revert channel selection -- [miner#1125](https://github.com/helium/miner/pull/1125): Add height to deadline response -- [miner#1123](https://github.com/helium/miner/pull/1123): Fix possibly-conflicting heights in - current-chain and received-message - -- [blockchain-core#1050](https://github.com/helium/blockchain-core/pull/1050): Initial var-cache - explicitly to avoid potential race conditions -- [blockchain-core#1040](https://github.com/helium/blockchain-core/pull/1040): Rework state channel - server -- [blockchain-core#1039](https://github.com/helium/blockchain-core/pull/1039): Separate out - aux-ledger from active ledger - -### Plan - -We have been beta testing `2021.10.18.0` since Oct 18, 2021 5:00 PM PT. Current ETA for GA is 10:45 -AM PT, Oct 19, 2021. diff --git a/devblog/2021-10-20-console-updates-2.1.4.mdx b/devblog/2021-10-20-console-updates-2.1.4.mdx deleted file mode 100644 index 825796eba..000000000 --- a/devblog/2021-10-20-console-updates-2.1.4.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.1.4 -date: 2021-10-20 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Included in this sprint, the team delivered Configuration Profiles provides users with a streamlined -way to configure, save, and apply device settings (ADR, CF List) and a new authentication system. - - - -Previous logins will be migrated to the new system and device settings (ADR, and CF List) will be -preserved. - -**_Important Login Action Required_** - -_The first time logging into Console after the upgrade every user will need to login twice, once to -migrate their account and then another time to login to Console as usual._ - -### Features and fixes - -- Configuration Profiles provides users with a streamlined way to configure, save, and apply device - settings (ADR, CF List). More [info](https://docs.helium.com/use-the-network/console/profiles/) -- This new authentication system provides a better, more secure experience for users. Two-factor - authentication will be available in a future Q4 release. -- Provided show/hide functionality for Azure keys -- Hide empty labels table on device show page -- Several users report many `link_adr_req` downlink messages and slow joins - [#437](https://github.com/helium/router/issues/437) -- Join-Accept and downlink RX window choice for Europe - [#423](https://github.com/helium/router/issues/423) - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Roaming services -- Additional help resources -- Light Hotspot support (diffs for state channels) -- Continue horizontal scaling work -- Expanding Console APIs -- Packet purchaser: integrate with ChirpStack LoRaWAN Network Server diff --git a/devblog/2021-10-21-app-version-370.mdx b/devblog/2021-10-21-app-version-370.mdx deleted file mode 100644 index a2c0e597d..000000000 --- a/devblog/2021-10-21-app-version-370.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -layout: post -title: App Version 3.7.0 -date: 2021-10-21 -hide_table_of_contents: true -authors: [cokes518] ---- - -App Version 3.7.0 - -  - -# New Features - -## StakeJoy as API Provider - -We've added StakeJoy API support to the Helium App. StakeJoy provides data to -explorer-old.helium.com and now the Helium app to provide users with an improved experience. To use -StakeJoy, go to **Settings**, tap **Choose API Provider** and select **StakeJoy**. - - - -When selected, StakeJoy will deliver all Hotspot, account, and validator information. Any -transactions submitted to the blockchain will continue to use the Helium API. - -## Deeplink Support from Helium Vote - -There is now improved support when initiating a burn transaction from heliumvote.com. When you tap -the transaction on mobile, you'll be directed to the burn transaction page immediately. - -## Currency Selector - -In the past, converting HNT to a local currency was automatic and depended on your device locale. -We've added support to override the device locale so you can select any currency supported by -CoinGecko. - -Find this new setting in the app > **Settings** > **Currency**. - -# Improvements - -As promised in the post-mortem from October 18, we've added lazy loading Hotspot rewards to the app. -This was done to optimize API calls. - -# New Hotspot Support - -We’ve added RisingHF and MerryIot/Browan as new options to add a Hotspot to the Helium network. - -# Bug Fixes - -- Fixes a bug where the small map at the end of assert_location is slightly off. diff --git a/devblog/2021-10-27-blockchain-release-auto-snaps-and-bug-fixes.mdx b/devblog/2021-10-27-blockchain-release-auto-snaps-and-bug-fixes.mdx deleted file mode 100644 index 5e244ee41..000000000 --- a/devblog/2021-10-27-blockchain-release-auto-snaps-and-bug-fixes.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Auto Snapshots and Bug Fixes' -date: 2021-10-27 14:00 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.10.27.0` Hotspot firmware release which includes new -functionality for Hotspots to automatically ingest latest on-chain snapshots. **Makers, please see -the note below** as there are some updates you'll need to incorporate to use this feature. This -release also reverts the `var cache` which was causing unforeseen issues and upgrades -`blockchain-core` to include many State Channel related optimizations. - - - -This is a **mandatory** update for manufacturers to automatically ingest snapshots. We will no -longer be blessing snapshots manually after this update. - -## Snapshot Source - -This feature replaces the older snapshot loading mechanism and allows manufacturers to provide a -JSON file that is always used to load latest snapshots. Here is -[an example](https://snapshots.helium.wtf/mainnet/latest-snap.json) of a file the core team uses to -update our firmware controlled Hotspots. - -This allows the hotspot to look for a file named `snap-1072801` .This will enable Hotspots to -automatically load the latest defined snapshot (without a firmware update). Blessed snapshots are -still used in case this URL is not available. These endpoints can be configured with the new config -variables listed [here](https://github.com/helium/miner/blob/master/config/sys.config#L45-L46), -specifically `snap_source_base_url` and `fetch_latest_from_snap_source`. If you, as maker, have a -custom `sys.config` or override file, you **must** update these configuration settings. - -#### Related PRs - -- [miner#1139](https://github.com/helium/miner/pull/1139): Update config for auto snapshot ingestion -- [miner#1136](https://github.com/helium/miner/pull/1136): Bugfix to ensure `tmst` is always an - integer in miner_lora - -- [blockchain-core#1058](https://github.com/helium/blockchain-core/pull/1058): Auto snapshot - ingestion support -- [blockchain-core#1053](https://github.com/helium/blockchain-core/pull/1053): Find start blocks - faster for snapshot -- [blockchain-core#1051](https://github.com/helium/blockchain-core/pull/1051): Fix missed state - channel expirations -- [blockchain-core#1043](https://github.com/helium/blockchain-core/pull/1043): Improvements to aux - ledger metadata diffing for inspection - -### Plan - -We have been beta testing `2021.10.27.0` since Oct 27, 2021 10:00 AM PT. Current ETA for GA is 2:30 -PM PT, Oct 27, 2021. diff --git a/devblog/2021-10-29-app-version-371.mdx b/devblog/2021-10-29-app-version-371.mdx deleted file mode 100644 index 9d7511b81..000000000 --- a/devblog/2021-10-29-app-version-371.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: post -title: App Version 3.7.1 -date: 2021-10-29 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Version 3.7.1 - -## Improvements - -- updates account screen when API calls fail to avoid showing 0 balance and 0 Hotspots -- improves how the app retrieves data from the API -- fixes a bug where users couldn’t send payments or transfer Hotspot based on a security setting -- added an option to clear map cache to troubleshoot when hexagons aren’t loading or app is - malfunctioning due to tileserver diff --git a/devblog/2021-10-29-miner-emergency-release.mdx b/devblog/2021-10-29-miner-emergency-release.mdx deleted file mode 100644 index f596c91d8..000000000 --- a/devblog/2021-10-29-miner-emergency-release.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: 'Miner Release: Emergency release for dropped packets' -date: 2021-10-29 14:37 -0700 -hide_table_of_contents: true -authors: [vihu, jdgemm, abhay] ---- - -The core developers have tagged a new `2021.10.29.0` Hotspot firmware release which includes bug -fixes for dropped packets reported by the community and verified by the router team. - - - -Devices attempting to join would continue in a join accept and request loop or devices trying to -downlink would be unsuccessful. This issue did not impact existing devices sending uplink packets. - -This is a **mandatory** update for manufacturers as it includes other necessary fixes from -`2021.10.27.0`. If a manufacturer hasn't updated to `2021.10.27.0`, they should skip that build and -simply update to `2021.10.29.0`. The `2021.10.29.0` release will allow Hotspots to continue to route -LoRaWAN packets. The core developers apologize for creating urgent weekend work. - -#### Related PRs - -- [miner#1148](https://github.com/helium/miner/pull/1148): Do not use AdjustedTmst_us for tmst field - -### Plan - -We have been beta testing `2021.10.29.0` since Oct 29, 2021 3:45 PM PT. Current ETA for GA is 6:00 -PM PT, Oct 29, 2021. diff --git a/devblog/2021-11-01-console-postmortem.mdx b/devblog/2021-11-01-console-postmortem.mdx deleted file mode 100644 index 894232fc0..000000000 --- a/devblog/2021-11-01-console-postmortem.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -layout: post -title: Console Post Mortem (10/27 Connectivity Issues) -date: 2021-11-01 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, madninja] ---- - -On 10/27 a fix based on a community-raised issue was deployed along with a number of other updates -in the `2021.10.27.0` Hotspot firmware release. - - - -The firmware update included related PR `miner#1136` which caused timing issues that resulted in -perpetual join accept and requests, and impacted downlinks. - -More details: - -- [Blog](https://engineering.helium.comhttps://docs.helium.com/blog/2021/10/27/blockchain-release-auto-snaps-and-bug-fixes.html) -- [PR](https://github.com/helium/miner/pull/1136) - -This issue only affected devices attempting joins or downlinks. Devices sending uplinks were not -affected. - -An emergency update `2021.10.29.0` was pushed on 10/29 afternoon to miners/hotspots to fix the -issue. Read -[blog](https://engineering.helium.comhttps://docs.helium.com/blog/2021/10/29/miner-emergency-release.html) -for more information. - -## Next Steps - -To increase the robustness of the network and prevent a similar issue from reoccurring the team -agreed upon the following next steps. - -### More focused releases - -- Focus on targeted releases which address related items vs just opportunistically adding unrelated - items. - -### More scrutiny for issues raised - -Request clarity from community for relevant issues by asking members up front to include additional -context to answer the following: - - - What’s the problem that needs fixed or the opportunity for this feature? - - Define the success criteria to test in the field to make sure it’s fixed or working. - -### More canaries - -- Broaden beta Hotspot test environment to include more canaries (hardware devices connected to beta - Hotspot test groups). -- Add automated network side black-box testing to verify devices continue to operate as expected - after beta Hotspots updated. diff --git a/devblog/2021-11-03-blockchain-release.mdx b/devblog/2021-11-03-blockchain-release.mdx deleted file mode 100644 index 2bf0b748a..000000000 --- a/devblog/2021-11-03-blockchain-release.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Gossip v2 Support and Chain Variable Fixes' -date: 2021-11-03 11:12 -0700 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.11.02.0` Hotspot firmware release which includes two -critical blockchain-core fixes, firstly, blockchain core can now handle v1 and v2 block gossip -seamlessly; secondly, the developers noticed that the `transaction_validity_version` chain variable -definition was set incorrectly in the header file, this has been fixed. An unfortunate effect of -this is that `transfer_hotspot_v2` support has been slightly delayed. - - - -This is a **mandatory** update for manufacturers in order to correctly handle future -`transfer_hotspot_v2` transactions once `transaction_validity_version` chain variable appears on -chain. Future notices will be sent in relevant channels. - -#### Related PRs - -- [miner#1147](https://github.com/helium/miner/pull/1147): Fix received witness check - -- [blockchain-core#1070](https://github.com/helium/blockchain-core/pull/1070): Fix - transaction_validity_version var definition -- [blockchain-core#1063](https://github.com/helium/blockchain-core/pull/1063): Add a fall-back path - for getting v1 gossip while running v2 code - -### Plan - -We have been beta testing `2021.11.02.0` since November 02, 2021 5:45 PM PT. Current ETA for GA is -5:00 PM PT, November 03, 2021. diff --git a/devblog/2021-11-03-console-updates-2.1.5.mdx b/devblog/2021-11-03-console-updates-2.1.5.mdx deleted file mode 100644 index 70cb58233..000000000 --- a/devblog/2021-11-03-console-updates-2.1.5.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.1.5 -date: 2021-11-03 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The team added another prebuilt integration with a partner akenza IoT platform, as well as updates -to Configuration Profiles, and the Coverage feature. - - - -### Features and fixes - -- Added prebuilt integration with partner akenza, - [instructions](https://docs.helium.com/use-the-network/console/integrations/) -- Hotspot signal status via aggregated rssi value -- Add hotspot common region code to uplink metadata -- Configuration Profile delete warning if profile being actively used -- Added option to include join request information with integrations - [#387](https://github.com/helium/router/issues/387) -- Packets from someone else [#417](https://github.com/helium/router/issues/417) -- Misc integration error should trigger warning on flows workspace - [#907](https://github.com/helium/console/issues/907) - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Continue building out production ready roaming services -- Coverage enhancement provide a way to group gateways -- Additional help resources -- Light Hotspot support (diffs for state channels) diff --git a/devblog/2021-11-05-miner-release-minor-usability-improvements.mdx b/devblog/2021-11-05-miner-release-minor-usability-improvements.mdx deleted file mode 100644 index cfcaae2cd..000000000 --- a/devblog/2021-11-05-miner-release-minor-usability-improvements.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: 'Miner Release: Minor Usability Improvements' -date: 2021-11-05 12:33 -0700 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.11.04.2` Hotspot firmware release which includes a few -minor usability improvements, specifically allowing Makers to access a Hotspot's region parameters -via JSON-RPC and miner's CLI. - - - -This is an **optional** but recommended update for manufacturers. If you had not updated to the -previous release `2021.11.02.0`, please upgrade to this release ASAP. - -#### Related PRs - -- [miner#1162](https://github.com/helium/miner/pull/1162): Use dBm, not cBm, for EIRP results -- [miner#1158](https://github.com/helium/miner/pull/1158): Add a JSON-RPC query for LoRa region - params - -### Plan - -We have been beta testing `2021.11.04.2` since November 04, 2021 6:00 PM PT. Current ETA for GA is -2:00 PM PT, November 05, 2021. diff --git a/devblog/2021-11-09-app-version-380.mdx b/devblog/2021-11-09-app-version-380.mdx deleted file mode 100644 index 7b0f0bfaf..000000000 --- a/devblog/2021-11-09-app-version-380.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: App Version 3.8.0/3.8.1 -date: 2021-11-09 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Version 3.8.0 (iOS) and 3.8.1 (Android) - -## Improvements - -- Optimizes calls to the API and cacheing -- Adds loading indicators when data calls to longer than usual -- Updates React Native - Android screenshots are no longer enabled due to a security flag that the - app is required to set. -- Changes how the app retrieves chain variables from the blockchain. - - - -## Android Bug Fix - -- Fixes [several bugs](https://github.com/helium/hotspot-app/pull/1059) related to certain Android - versions and devices: - -## Maker Changers - -- Updates PantherX and adds Syncrobit QR Code diff --git a/devblog/2021-11-10-blockchain-release-poc-v11-preparations.mdx b/devblog/2021-11-10-blockchain-release-poc-v11-preparations.mdx deleted file mode 100644 index 2463fc11e..000000000 --- a/devblog/2021-11-10-blockchain-release-poc-v11-preparations.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: POC V11 Preparations' -date: 2021-11-10 10:27 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.11.10.0` Hotspot firmware release which includes -critical bug fixes, supplementary code for finalizing activation of POC V11 related chain variables, -packet transmission and blockchain-etl fixes. - - - -This is a **mandatory** release for manufacturers to support the packet transfer fixes that were -applied but also to ingest chain variables which will be applied once validators and other nodes are -upgraded to a matching release. We intend to re-release PoCv11 tomorrow afternoon PT pending -confirmation from sufficient manufacturers. - -### Proof-of-Coverage v11 Activation - -The core developers are planning to re-release Proof-of-Coverage v11 tomorrow. We will follow up on -Discord with an exact time but we're looking at the following changes: - -- `poc_version` to `11`. This activates PoCv11 -- `fspl_loss` set `1.0`. This sets the loss factor due to air permeability and permittivity. At this - value, It is assumed that there is no loss that is to be expected. Values greater than `1.0` - assume some loss is expected. This value can be adjusted at a later date through a governance - change. - -These variables have also been implemented but will **remain unset** until a future governance -change proposes modification. - -- `poc_distance_limit`. We believe this should be set to something reasonable as the FSPL curve - starts to be less useful at great distances but given the feedback from the community, we'll keep - this turned off. -- `witness_reward_decay_rate`: Can be used in the future to apply a soft cap on witness rewards for - an individual Hotspot within an epoch. -- `witness_reward_decay_exclusion`: Associated with the other variable to provide a "grace" number - of witnesses per epoch. - -#### Related PRs - -- [miner#1194](https://github.com/helium/miner/pull/1194): Ignore lorawan packets that are too short - to be valid -- [miner#1192](https://github.com/helium/miner/pull/1192): Fix lorawan routing crash when packet has - no payload -- [miner#1187](https://github.com/helium/miner/pull/1187): Recalculate regulatory domain on var txn -- [miner#1187](https://github.com/helium/miner/pull/1187): Recalculate regulatory domain on var txn -- [miner#1186](https://github.com/helium/miner/pull/1186): Adjust sizes downward for global caches -- [miner#1185](https://github.com/helium/miner/pull/1185): Drop 0.0 frequency witnesses -- [miner#1181](https://github.com/helium/miner/pull/1181): Allow configuration of rockdb cache sizes - -- [blockchain-core#1085](https://github.com/helium/blockchain-core/pull/1085): Catch unknown_region - explicitly -- [blockchain-core#1080](https://github.com/helium/blockchain-core/pull/1080): Convert POCV11 - regions into helium-proto enum values -- [blockchain-core#1079](https://github.com/helium/blockchain-core/pull/1079): Handle missing region - definitions to fix blockchain-etl -- [blockchain-core#1077](https://github.com/helium/blockchain-core/pull/1077): Discard 0.0 freq - witnesses behind chain variable -- [blockchain-core#1076](https://github.com/helium/blockchain-core/pull/1076): Fix segfault on - rocksdb seek -- [blockchain-core#1075](https://github.com/helium/blockchain-core/pull/1075): Handle witness crash - in tagged_path_elements -- [blockchain-core#1074](https://github.com/helium/blockchain-core/pull/1074): Fix - blockchain_state_channels worker hangup -- [blockchain-core#1061](https://github.com/helium/blockchain-core/pull/1061): Evict rejected - gateways from state channel - -### Plan - -We have been beta testing `2021.11.10.0` since November 10, 2021 12:15 PM PT. Current ETA for GA is -3:30 PM PT, November 10, 2021. diff --git a/devblog/2021-11-11-blockchain-release-critical-libp2p-fixes.mdx b/devblog/2021-11-11-blockchain-release-critical-libp2p-fixes.mdx deleted file mode 100644 index 44d0080e6..000000000 --- a/devblog/2021-11-11-blockchain-release-critical-libp2p-fixes.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Critical libp2p Fixes' -date: 2021-11-11 14:28 -0800 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.11.11.0` Hotspot firmware release which includes -critical bug fixes for gossip and ARP in libp2p. We hope that this release will help Hotspots with -improvements on block gossip and keeping an up to date peerbook. - - - -This is a **mandatory** release for manufacturers to ensure that overall network gossip continues to -work as expected. - -#### Related PRs - -- [blockchain-core#1088](https://github.com/helium/blockchain-core/pull/1088): Handle race condition - when plausible block gets added by other gossip -- [erlang-libp2p#396](https://github.com/helium/erlang-libp2p/pull/396): When getting an ARP - response for a peer behind a relay, ARP relay too - -### Plan - -We have been beta testing `2021.11.11.0` since November 11, 2021 1:50 PM PT. Current ETA for GA is -5:30 PM PT, November 11, 2021. diff --git a/devblog/2021-11-17-blockchain-release-resuming-the-blockchain.mdx b/devblog/2021-11-17-blockchain-release-resuming-the-blockchain.mdx deleted file mode 100644 index 9b5d34be9..000000000 --- a/devblog/2021-11-17-blockchain-release-resuming-the-blockchain.mdx +++ /dev/null @@ -1,84 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Resuming Block Production and Gossip' -date: 2021-11-17 13:48 -0800 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -#### Hotspot Release - -The core developers have tagged a new `2021.11.17.2` Hotspot firmware release which includes -CRITICAL fixes to ensure that Hotspots continue to follow the chain after the -[24 hr+ chain halt observed on November 15th](https://status.helium.com). - - - -This is a **mandatory** release for manufacturers to ensure that overall network gossip continues to -work as expected. - -Note: A full post-mortem will be shared with the community early next week. - -#### Blockchain Halt Fixes - -- Consensus group members were saving transaction proposals to disk more often than was needed. - Proposal construction state has been changed to write to disk piecewise. -- There were numerous places where blocks were unnecessarily read from the disk, leading to - disastrous performance with the unexpectedly large block. Most of these have been eliminated by - better block metadata caching. -- General performance sweep of the entire transaction validation and absorb pathways. -- Rewrite two low level repositories, `e2qc` and `vincenty`, in Rust to improve performance -- Added `block_size_limit` chain variable which is defaulted to 50MB on miner but can be updated in - the future with a chain variable transaction. - -Please feel free to skim through the PRs mentioned below for more information. - -#### PRs for resuming Hotspots sync - -- [blockchain-core#1108](https://github.com/helium/blockchain-core/pull/1108): Fix sync flag on add - block events -- [blockchain-core#1107](https://github.com/helium/blockchain-core/pull/1108): Ignore sync for - recent blocks - -#### PRs for resuming Blockchain - -- [miner#1213](https://github.com/helium/miner/pull/1213): Switch to `block_info_v2` -- [miner#1210](https://github.com/helium/miner/pull/1210): Add a max block size when constructing - blocks - -- [blockchain-core#1105](https://github.com/helium/blockchain-core/pull/1105): Fix snapshot info - handling -- [blockchain-core#1103](https://github.com/helium/blockchain-core/pull/1103): Update elections to - not pull blocks -- [blockchain-core#1098](https://github.com/helium/blockchain-core/pull/1098): Upgrade block info to - include hbbft round and election info -- [blockchain-core#1097](https://github.com/helium/blockchain-core/pull/1097): Remove two more - unnecessary uses of `head_block` -- [blockchain-core#1094](https://github.com/helium/blockchain-core/pull/1094): Add - `block_size_limit` chain variable -- [blockchain-core#1093](https://github.com/helium/blockchain-core/pull/1093): Add - `gossip_block_limit_mb` application variable -- [blockchain-core#1091](https://github.com/helium/blockchain-core/pull/1091): Do not send a stale - state channel -- [blockchain-core#1090](https://github.com/helium/blockchain-core/pull/1090): Various performance - improvements from downstream - -- [relcast#48](https://github.com/helium/relcast/pull/48): Write keytree under txn in another spot -- [relcast#47](https://github.com/helium/relcast/pull/47): Attempt to add other key types to relcast - serialization tree - -- [erlang-hbbft#74](https://github.com/helium/erlang-hbbft/pull/74): Attempt better - serialization/deserialzation for rbc -- [erlang-hbbft#73](https://github.com/helium/erlang-hbbft/pull/73): Temporarily hardcode max rpc - proposal size to 5mb -- [erlang-hbbft#72](https://github.com/helium/erlang-hbbft/pull/72): Attempt to use a keytree - serialization for rbc to help performance - -- [vincenty#2](https://github.com/helium/vincenty/pull/2): Switch vincenty backend to Rust - -- [e2qc#1](https://github.com/helium/e2qc/pull/1): Switch e2qc backend to Rust - -### Plan - -We have been beta testing `2021.11.17.2` since November 17, 2021 1:50 PM PT. Current ETA for GA is -4:30 PM PT, November 17, 2021. diff --git a/devblog/2021-11-17-console-updates-2.1.6.mdx b/devblog/2021-11-17-console-updates-2.1.6.mdx deleted file mode 100644 index 2d6696157..000000000 --- a/devblog/2021-11-17-console-updates-2.1.6.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.1.6 -date: 2021-11-17 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 64 - -Despite additional turbulence experienced earlier this week, the team stayed focused and released -v2.1.6. - - - -Based on product analytics the team added general and context sensitive help resources as well as a -way to group gateways with the Coverage feature, and continued to make backend improvements. - -Thank you for your patience while we rode out the turbulence and apologies for any inconvenience -caused. - -### Key features and fixes - -- Added user-friendly help resources -- Provided a way to group gateway -- Latest blockchain_core release -- Resolved issues with unknown decoders -- Devices no longer fail to submit data to integrations (no_channel) -- Provided hold_time for Join Requests -- ADR Mac responses recognized - -For a full list of completed sprint 64 features and fixes: - -- Backend [Router](https://github.com/helium/router/milestone/1?closed=1) -- Frontend [Console](https://github.com/helium/console/milestone/1?closed=1) - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Continue building out production ready roaming services -- Light Hotspot support (diffs for state channels) -- Improve Console experience on mobile devices diff --git a/devblog/2021-11-18-app-version-383.mdx b/devblog/2021-11-18-app-version-383.mdx deleted file mode 100644 index 240928dad..000000000 --- a/devblog/2021-11-18-app-version-383.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: post -title: App Version 3.8.3 -date: 2021-11-18 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# App Version 3.8.3 - -This release includes improvements to API loading, adds rewards caching, and updates how earnings -are calculated. - - - -## 24H Hotspot Rewards - -The 24 hour Hotspot rewards and summary found on the home page of the app is now based on UTC -Calendar day and not a rolling 24 hour window. The impetus behind this change is to reduce the -number of queries to the API to calculate this value. - -## App Cacheing - -The app will now cache transaction data to reduce the number of calls it needs to make to the API on -app launch. - -## Earnings Charts - -The new default chart for Hotspots has changed from 14D to 24H. The chart also displays bucketed -earnings in a UTC calendar day and no longer a rolling 24 hour window. - -The 14 and 30 day charts are also updated to UTC calendar days. - -## Places Hotspot Checklist behind a feature flag - -This feature flag will allow us to toggle this feature on and off without a new release. - -# Bug Fixes - -- Fixes a bug where the second map of assert location was off -- Fixes a bug when asserting location and the button does not respond on first press because it's - checking for a pending transaction -- Removes the API check when pairing with a Hotspot over Bluetooth -- Fixes a URL issue on Android where links can't be opened - -# Maker Support - -- Adds Deeper Maker support -- Adds QR Code support for Controllino - -# Other Improvements - -- Adds HNTenna to the list of selectable antennas in the dropdown -- Sorts antenna list by alphabetical order diff --git a/devblog/2021-11-19-blockchain-release-sync-and-snapshot-improvements.mdx b/devblog/2021-11-19-blockchain-release-sync-and-snapshot-improvements.mdx deleted file mode 100644 index f3356bf69..000000000 --- a/devblog/2021-11-19-blockchain-release-sync-and-snapshot-improvements.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Sync and Snapshot Improvements' -date: 2021-11-19 15:22 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.11.19.0` Hotspot firmware release which includes -**highly recommended** fixes to improve network-wide block sync and snapshot ingestion on Hotspots. - - - -#### Related PRs - -- [miner#1222](https://github.com/helium/miner/pull/1222): Reduce the size of generated docker image - for releases - -- [blockchain-core#1115](https://github.com/helium/blockchain-core/pull/1115): Fix - `save_plausible_blocks` to not return an error if some blocks are plausible -- [blockchain-core#1113](https://github.com/helium/blockchain-core/pull/1113): Fix `can_add_block` - to check plausible block correctly -- [blockchain-core#1112](https://github.com/helium/blockchain-core/pull/1112): Properly - release/decrement the blockchain lock in `check_plausible_blocks` -- [blockchain-core#1109](https://github.com/helium/blockchain-core/pull/1109): Eagerly gossip - plausible blocks -- [blockchain-core#1106](https://github.com/helium/blockchain-core/pull/1106): Improve - `snapshot info` command output - -### Plan - -We have been beta testing `2021.11.19.0` since November 19, 2021 11:40 AM PT. Current ETA for GA is -4:00 PM PT, November 19, 2021. diff --git a/devblog/2021-11-21-blockchain-release-snapshot-sync-emergency.mdx b/devblog/2021-11-21-blockchain-release-snapshot-sync-emergency.mdx deleted file mode 100644 index c610f2faa..000000000 --- a/devblog/2021-11-21-blockchain-release-snapshot-sync-emergency.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Emergency releases for sync and snapshot improvements' -date: 2021-11-21 11:45 -0700 -hide_table_of_contents: true -authors: [evanmcc] ---- - -The core developers have tagged a new `2021.11.21.2` Hotspot firmware release which includes -**highly recommended** fixes to improve network-wide block sync and snapshot ingestion on Hotspots -with less memory. - - - -Note that this blog post also covers the `2021.11.21.1` emergency release, which was released with -very little warning very, very early this morning. `2021.11.21.2` contains all of the fixes -mentioned in this post. - -The primary fixes here are: - -- Rescue blocks were not considered "plausible" by newer gossip code, and were not getting - distributed except via fastforward. -- The snapshot loading code has been rewritten to take much less memory, allowing lower-memory - Hotspots to load snapshots and follow the chain more easily. - -#### Related PRs - -- [blockchain-core#1111](https://github.com/helium/blockchain-core/pull/1111): Rework snap loading - to take less memory. -- [blockchain-core#1120](https://github.com/helium/blockchain-core/pull/1120): Make rescue blocks - plausible. - -### Plan - -We have been beta testing `2021.11.21.2` since November 21, 2021 9:00 AM PT. Current ETA for GA is -12:30 PM PT, November 21, 2021. diff --git a/devblog/2021-11-22-blockchain-release-sync-emergency.mdx b/devblog/2021-11-22-blockchain-release-sync-emergency.mdx deleted file mode 100644 index 6d3fa9056..000000000 --- a/devblog/2021-11-22-blockchain-release-sync-emergency.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Emergency releases for sync' -date: 2021-11-22 11:45 -0700 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2021.11.22.0` Hotspot firmware release which includes a -**mandatory fix** to unstick some Hotspot stuck syncing at 1,107,994 due to a nonce disagreement -from loading a snapshot. - - - -The primary fix is to update all nonce values for Hotspots stuck at block 1,107,994. - -#### Related PRs - -- [blockchain-core#1123](https://github.com/helium/blockchain-core/pull/1123): upgrade step to fixup - var nonces for gateway halt - -### Plan - -We have been beta testing `2021.11.22.0` since November 22, 2021 8:00 PM PT. Current ETA for GA is -9:15 PM PT, November 22, 2021. diff --git a/devblog/2021-11-30-blockchain-release-snapshot-and-rocksdb-improvements.mdx b/devblog/2021-11-30-blockchain-release-snapshot-and-rocksdb-improvements.mdx deleted file mode 100644 index e94956f97..000000000 --- a/devblog/2021-11-30-blockchain-release-snapshot-and-rocksdb-improvements.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot and RocksDB Improvements' -date: 2021-11-30 11:30 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2021.11.30.1` Hotspot firmware release which includes -**recommended** fixes to snapshot load performance, underlying rocksdb tuning and other important -bug fixes. - - - -#### Related PRs - -- [miner#1264](https://github.com/helium/miner/pull/1264): Limit the size and age of rocksdb log - files -- [miner#1237](https://github.com/helium/miner/pull/1237): Keep checking for blockchain in case of - long miner startup -- [miner#1229](https://github.com/helium/miner/pull/1229): Add election transaction to local - transaction buffer -- [miner#1267](https://github.com/helium/miner/pull/1267): Temporarily make more seed nodes static -- [miner#1248](https://github.com/helium/miner/pull/1248): Disable fetching latest snapshot on - validators (Thanks [@PaulVMo](https://github.com/PaulVMo)!) - -- [blockchain-core#1133](https://github.com/helium/blockchain-core/pull/1133): Fix recovering from - corrupt blockchain database -- [blockchain-core#1129](https://github.com/helium/blockchain-core/pull/1129): Explicitly handle - return cases for receipt validation `is_too_far` function -- [blockchain-core#1127](https://github.com/helium/blockchain-core/pull/1127): Fix bootup when no - genesis block is specified -- [blockchain-core#1125](https://github.com/helium/blockchain-core/pull/1125): Add CLI handler for - fast-forwarding a remote peer -- [blockchain-core#1124](https://github.com/helium/blockchain-core/pull/1124): Try to use more - memory efficent parsing for hexes in snapshots - -### Plan - -We have been beta testing `2021.11.30.1` since November 30, 2021 12:30 PM PT. Current ETA for GA is -2:30 PM PT, November 30, 2021. diff --git a/devblog/2021-11-30-network-outage-post-mortem.mdx b/devblog/2021-11-30-network-outage-post-mortem.mdx deleted file mode 100644 index 75273832e..000000000 --- a/devblog/2021-11-30-network-outage-post-mortem.mdx +++ /dev/null @@ -1,320 +0,0 @@ ---- -layout: post -title: 'Network Disruption Postmortem: Week of 2021-11-15' -date: 2021-11-30 17:00 -0700 -hide_table_of_contents: true -authors: [cokes518, madninja, abhay] ---- - -  - -# Overview - -Last week the Helium Network experienced several disruptions. Throughout the disruptions, there was -no risk to HNT holders, and while some devices were unable to use the Network for data transfer, the -majority of devices were unaffected. - - - -The Helium Blockchain has been running without serious interruption for over the two years and over -1 million total blocks. - -The goal of this postmortem is to provide a transparent and technical overview of the events that -took place, why they occurred, and what the Helium community and core developers did to not only -address the issues, but improve the network so it can continue to scale. The performance -improvements developed during the week and deployed by Hotspot owners and Validator operators will -benefit the network well beyond resolution of these disruptions as it continues its unprecedented -growth. - -# Huge Thanks - -We’d like to take this opportunity to give a HUGE THANKS to our community for your support and -patience, especially our Validator operators who quickly updated their nodes with the latest -releases to help resume normal block operations. - -# Summary of Disruptions - -On 2021-11-15 at approximately 2000 UTC the Helium Network was offline for approximately 30 hours -and returned to normal operations on 2021-11-17 0200 UTC. All blockchain activity was halted during -this time. - -On 2021-11-20 at approximately 1805 UTC, the core developers were alerted of another outage. The -Helium network was offline for approximately 12 hours. During this time all blockchain activity was -halted. - -On 2021-11-23 at approximately 0045 UTC, a chain variable was activated that caused some miners to -stop syncing at block 1,107,995. It was discovered that the root cause was a nonce disagreement when -miners consumed a snapshot including the rescue block from the second outage. Some Hotspots and -Validators were unable to sync the blockchain for approximately 4 hours. The blockchain continued -moving at this time. There was no impact to Proof-of-coverage and packet transfer for those Hotspots -that remained in sync. - -Normal operations of the network were restored with the help of the Helium community who continue to -be a strength of the network, specifically Validator operators who worked closely with the core -developers to timely update their Validators with releases containing performance improvements to -proceed past the bottleneck caused by an abnormally large - -# Timeline of Events - -Note: Approximate times are used for some of these events as the goal is to provide the community -with an overall sequence of events. - -## 2021-11-15 Outage - -- 2021-11-15 20:00 UTC core developers identified a community-hosted Router causing a large number - of state channel dispute transactions which ultimately caused an extremely large block (approx. - 140MB) and created a bottleneck halting the blockchain -- 2021-11-16 01:30 UTC core developers worked with the community member to apply a fix and prevent - recurrence of the issue and later also updated other Router instances -- 2021-11-16 03:00 UTC placed API into maintenance mode preventing the build-up of pending - transactions which would cause additional issues once block production resumes -- 2021-11-16 07:34 UTC the team deployed Validator release v1.5.0 with performance updates to allow - Validators in Consensus Group to break the bottleneck by consuming the large block and return to - normal block production -- 2021-11-16 09:24 UTC the team continued to monitor Consensus Group Validators to pick up the new - release and also tagged updated versions of blockchain-node, blockchain-etl, and router -- 2021-11-16 20:58 UTC the core developers released Validator v1.5.5 with further performance - improvements identified after observing v1.5.0 still struggling with the large block. -- 2021-11-16 23:50 UTC the core developers are advised by a Validator provider that their nodes may - not reenter consensus due to lost consensus data during the upgrade process. -- 2021-11-17 02:00 UTC Block production resumes. -- 2021-11-17 08:11 UTC the core developers tagged `2021.11.17.2` miner firmware emergency release - including updated blockchain-core, and snapshot to move beyond the large block, so Hotspots could - resume syncing, participate in POC, and data transfer activity. -- 2021-11-18 02:42 UTC Validator v1.5.7 was released which included fixes to the transaction - manager, improves block synchronization across the network, and transaction handling times. -- 2021-11-18 16:18 UTC a potential deadlock issue was discovered and Validator v1.5.8 was released - to fix it. - -## 2021-11-20 Outage - -- 2021-11-20 18:05 UTC the core team was alerted of a long block forming as a result of a bug in - state channels from the Discovery Mode router. Earlier mitigations by the core team prevented this - block from becoming too large. -- 2021-11-20 18:30 UTC the core team identified some Hotspots that were unable to process that - block. -- 2021-11-20 18:51 UTC the app team decided to turn off the Discovery Mode feature to prevent - further state channels from opening and closing, creating large blocks in the process. At this - time, the blockchain was still moving. -- 2021-11-20 19:11 UTC the core devs identified another state channel closing and a potential large - block. Attempts were made to generate a snapshot for the network to consume to move past the - block. -- 2021-11-20 20:50 UTC unable to get a snapshot, the core devs notified the community of a - blockchain halt. -- 2021-11-21 01:11 UTC the core team released Validator v1.5.12 to the consensus group to get past - the block. -- 2021-11-21 06:52 UTC unable to get the network past the block, the core team and members of - Decentralized Wireless Alliance proposed a Rescue Block, which would reelect the Consensus Group - and a chain variable change to close state channels used by Discovery Mode. -- 2021-11-21 07:52 UTC The [Rescue Block](https://explorer-old.helium.com/blocks/1105523) was - issued, and block production resumed shortly after. -- 2021-11-21 13:22 UTC a Hotspot firmware release was made available to all manufacturers to resume - blockchain sync, Proof-of-Coverage activity, and data transfer -- 2021-11-21 20:48 UTC a second firmware release was made available to all manufacturers with - lower-memory Hotspots to make it easier to follow the blockchain - -## 2021-11-23 Incident - -- 2021-11-23 00:45 UTC a proposed chain variable to adjust validator penalties was activated -- 2021-11-23 00:46 UTC the activated chain variable immediately caused syncing issues at block - 1,107,995. -- 2021-11-23 01:04 UTC blocks were still being produced by the Consensus Group and some Hotspots - were still syncing and participating in mining. The team continued investigating the root cause. -- 2021-11-23 01:26 UTC the core developers identified that the issue was related to a snapshot that - included the rescue block and the recently deployed chain variable. Only Hotspots and Validators - that consumed the snapshot were affected. -- 2021-11-23 02:32 UTC the core team concluded a snapshot would resolve this issue and began finding - a suitable candidate. -- 2021-11-23 02:58 UTC unable to find a suitable snapshot, the core team looked to issue a Hotspot - firmware release to realign nonce values between affected and unaffected miners. -- 2021-11-23 04:10 UTC the team has a firmware candidate `2021.11.22.0` and starts beta testing on - known stuck Hotspots. -- 2021-11-23 05:25 UTC beta testing results are positive and the core team releases `2021.11.22.0` - for GA and advises all makers to update to this release. -- 2021-11-23 06:28 UTC another build 2021.11.22.1 is made available for makers if their Hotspot - fleet experiences out-of-memory issues. -- 2021-11-23 UTC Hotspot syncing resumes for those stuck on block 1,107,994 and Proof-of-Coverage - activity resumes. - -# Event Details - -## 2021-11-15 Outage - -The core developers with a community member identified an issue impacting the blockchain that -started with abnormally long block times then evolved into a full halt 2021-11-15 20:00 UTC. A bug -in Router code that triggered a community-hosted Router instance to propagate many state channels -dispute transactions was exacerbated by the loading of a recently released chain variable. This -combination resulted in an extremely large block (around 140 MB), which was orders of magnitude -larger than typical blocks. - -Validators in the Consensus Group were unable to consume this large block causing a bottleneck that -ultimately resulted in a halt impacting all blockchain activity including PoCs, challenges, and -more. - -On 2021-11-16 a few hours later (approximately 01:30 UTC) the core developers worked with the -community member to apply a fix to the community-hosted Router intended to prevent a recurrence and -this patch was released to other Router instances shortly after. - -The team continued to work on addressing the large block that caused the bottleneck, including -fixing the boot looping caused by the large block, and pushing an update to increase the speed to -close state channels. - -Since blockchain activity remained halted at approximately 03:00 UTC, the core developers made the -decision to put the API into maintenance mode. This meant all new submitted transactions would fail -including those from the wallet (for example, payment, add Hotspot, assert location, transfer -Hotspot, etc). This decision prevented the build up of a huge queue of commands that would have -overwhelmed the servers once the blockchain returned to normal operations. - -The core developers worked on a number of performance fixes to allow Validators in the Consensus -Group to consume and move past the large block and allow validators to resume normal block -production. - -At 07:34 UTC the core developers released a Validator update for Validators in the Consensus Group -to urgently update. Two-thirds + one of the members were required to update with the release to -continue to produce blocks and return the network to normal operations. - -During this time, work also began on an emergency release for Hotspot firmware, once a snapshot had -been agreed upon by the Consensus Group. - -By 09:24 UTC the team had tagged updated versions of blockchain-node, blockchain-etl, and router and -announced to the community to update to these latest versions to ensure smooth operations once block -production had resumed. - -On 2021-11-16 at 20:58 UTC the core developers released Validator v1.5.5. This release includes a -number of performance improvements and is designed to allow Validators to consume and manage the -large block causing the bottleneck and resume normal block production. - -However, to create a snapshot to update Hotspots a minimum number of blocks need to be added to the -chain so that the snapshot does not include the large blocks itself. - -With block production returning to normal at approximately 0200 UTC on 2021-11-17, the core -developers needed to wait until a sufficient number of blocks were formed before they could create a -miner release that contained updated blockchain-core, blessed snapshot, and allowed Hotspots to -resume syncing, POC, and data transfer activity. - -On 2021-11-17 at 08:11 UTC the core developers pushed the miner firmware release with an updated -blockchain-core, and snapshot to move beyond the large block, so older Hotspots could resume -syncing, participate in POC, and data transfer activity. - -Core developers released Validator v1.5.7 on 2021-11-18 at 02:42 UTC which included fixes to the -transaction manager, which was struggling to detect it had synced with the chain, and provided -performance improvements including improved blockchain synchronization across the network and faster -transaction handling times. Hours later at 16:18 UTC the team released Validator v1.5.8 to fix a -discovered deadlock issue. - -## 2021-11-20 Outage - -On 2021-11-20 18:05 UTC, the core Helium developers received a notification that it was taking -longer than normal to form a new block (typically blocks are formed every minute). - -Upon further investigation, it was identified that a state channel processing data transfer packets -for Discovery Mode was having issues closing due to a bug. When this happens, a large block can -start to form. Last week’s chain halt also happened when a large, 140mb sized block formed, which -Hotspots and Validators were unable to ingest. Fortunately, last week’s chain halt also allowed the -core devs to implement a variety of fail safe measures to prevent large blocks of that size from -happening again, as outlined in the [Engineering Blog](https://bit.ly/3CF1jdS). However, a second -large block still formed this weekend, which was determined to be 25mb in size. - -Around 2021-11-20 18:30 UTC, the team identified a subset of Hotspots with 1GB of ram that would not -be able to ingest the block. At this point, the Discovery Mode router had several more open state -channels that could potentially become degraded and cause long blocks. - -To avoid future degradation of the Network, the Helium App team decided to disable the Discovery -Mode feature until further notice. An app notification, status incident, and announcement on Discord -regarding the large block and disabling of Discovery Mode were sent. During the day, additional -progress updates were also posted on https://status.helium.com and Discord ​​as the team continued -to monitor block formation. - -Once the team identified the issue (long blocks from state channels) and root cause (Discovery Mode -router), the team issued a status update and made a discord announcement. - -The chain was still moving at this point. - -At 2021-11-20 19:11 UTC, another state channel from the Discovery Mode router was attempting to -close, creating a long block. The team decided to create a new snapshot past the long block in an -effort to get the Network past it. - -Unable to get a snapshot, and with more state channels closing with the same problem, the core -developers issued a formal blockchain outage at 20:50 UTC. - -The core developers then began actively working with Validators to push out a release to get the -Consensus Group past the large blocks. At 2021-11-21 01:11 UTC, Validator build v.1.5.12 was -announced, with Validators recommended to update as soon as possible. - -At 2021-11-21 06:52 UTC, an announcement went out from the Decentralized Wireless Alliance, in -conjunction with several core developers, on a proposed Rescue Block, which would reelect the -Consensus Group and close state channels used by Discovery Mode. The -[Rescue Block](https://explorer-old.helium.com/blocks/1105523) was issued during the following hour, -and block production resumed shortly after. - -At 2021-11-21 13:22 UTC, a new required Hotspot firmware release was made available to all Hotspot -manufacturers that would enable their fleet of Hotspots to sync and begin to participate in Proof of -Coverage and data transfer once again. A second release was announced at 20:48 UTC, allowing -lower-memory Hotspots to follow the chain more easily. Read more about both releases on the -[Engineering Blog](https://bit.ly/3CDFtaM). - -## 2021-11-23 Incident - -The core team with DeWi decided to activate HIP 47 to increase DKG penalties for Validators. A DKG -penalty can occur if an election fails, and the Validator was part of the reason for the election to -fail. This can occur throughout the DKG process or during the signature phase. Failed elections are -significant to the network as they prevent new groups from being elected and rewards to be issued to -all network participants including Hotspots. - -At 2021-11-23 00:45 UTC the proposed chain variable to adjust DKG penalties was activated per HIP47. - -Shortly after, the activated chain variable immediately caused syncing issues at block 1,107,995. At -this point, blocks were still being produced by the blockchain and Consensus Group, Hotspots were -still syncing and participating in Proof-of-Coverage. Packet transfer was not interrupted at this -time. The team continued investigating the root cause. - -At 2021-11-23 01:26 UTC the core developers identified that the issue is related to a snapshot that -included the rescue block issued at 1105523 and the recently deployed chain variable. Only Hotspots -and Validators that consumed the snapshot are affected. - -At 2021-11-23 02:32 UTC the core team believes a snapshot will resolve this issue and begins finding -a suitable candidate. The team looked to identify a snapshot small enough for Hotspots to consume to -get them past the block. - -Unable to find a suitable snapshot, the core team looks to issue a Hotspot firmware release to -realign nonce values between affected and unaffected miners. The proposed change was submitted and -reviewed. The team looks for Hotspots that are stuck syncing at 1,107,994 as beta testing -candidates. Several were identified. - -At 2021-11-23 04:10 UTC the team has a firmware candidate `2021.11.22.0` and starts beta testing on -known stuck Hotspots. The testing successfully unstuck affected Hotspots and the team let the update -soak for an hour. - -At 2021-11-23 05:25 UTC the core team releases `2021.11.22.0` for GA and advises all makers to -update to this release. All makers were alerted of this required update. - -At 2021-11-23 06:28 UTC another build `2021.11.22.1` is made available for makers if their Hotspot -fleet experiences out-of-memory issues when loading a snapshot. This was not a required update. - -The team announces an all clear. Hotspot syncing resumes for those stuck on block 1,107,994 and -Hotspots could participate in Proof-of-Coverage. - -# Key Fixes - -This is a shortlist of key fixes to prevent the recurrence of the events that caused the initial -outage. - -A complete list and specific details to address these events can be found on the -[engineering blog](https://docs.helium.com/devblog). - -- A few hours after the cause was identified the team quickly provided a fix to ensure the root - cause prevented the issue caused by \* Router from recurring -- Significant performance enhancements were implemented (example, during testing saw Validators go - from 600% CPU utilization to 6%) that will continue to benefit the network during normal - operations -- A cap to limit the size of non-reward blocks to a maximum (initial default 50 MB). This limit will - be associated with a chain variable to allow readjustment in the future. Blocks that exceed this - threshold will be trimmed to fit. -- A cap of individual consensus member transaction proposals to 1mb was implemented as large - proposals were identified as a significant performance bottleneck. -- Snapshot loading, a crucial tool in skipping low-resource hotspots over large blocks, has been - improved to require dramatically less memory. - -Although Helium has rapidly become the world’s largest contiguous wireless network, it is still -early days and issues will happen along the way. ​However, we believe that with the help of our -community, over time, the network will continue to grow and increase its resiliency. diff --git a/devblog/2021-12-01-app-version-384.mdx b/devblog/2021-12-01-app-version-384.mdx deleted file mode 100644 index 4df55878a..000000000 --- a/devblog/2021-12-01-app-version-384.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: App Version 3.8.4 -date: 2021-12-01 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Improvements - -Updates Hotspot Earnings chart to show UTC days (7D, 14D, 30D). - - - -- 24h earnings chart removed because the API reports reward earnings for the last completed UTC day - and thus will show 0 until the day is over. This can cause unnecessary concern as these 24h - earnings chart will effectively flatline. - -Updates 24h Earnings on Home screen to say last completed UTC day. Hotspot rewards below on that -Home screen also reflects last completed UTC day. - -Updates Validators earnings to align on UTC days. - -## Bug Fix - -- Fixes QR scan on second attempt -- Fixes Android keyboard display -- Fixes Transfer Hotspot check so no transactions are stuck pending even when cleared diff --git a/devblog/2021-12-06-blockchain-release-dns-and-seednode-fixes.mdx b/devblog/2021-12-06-blockchain-release-dns-and-seednode-fixes.mdx deleted file mode 100644 index 228ff699b..000000000 --- a/devblog/2021-12-06-blockchain-release-dns-and-seednode-fixes.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: DNS and Seednode Fixes' -date: 2021-12-06 11:47 -0800 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.12.06.0` Hotspot firmware release which includes -**recommended** fixes to Seed nodes and DNS query improvements. - - - -Hotspot manufacturers should update to this release when possible in order to give their customers -access to these improvements. It specifically helps Hotspots in parts of Europe who have ISPs with -specific DNS settings (enforcing packet sizes for DNSSEC) and it also improves peer gossip (reducing -the amount of stale data that is shared amongst the 380K+ nodes in the network). - -#### Related PRs - -- [miner#1277](https://github.com/helium/miner/pull/1277): Pull seed node IPs from DNS pool -- [miner#1271](https://github.com/helium/miner/pull/1271): Honor `follow_mode` set in app env - -- [blockchain-core#1141](https://github.com/helium/blockchain-core/pull/1141): Fix nonce upgrade for - new chain instantiation -- [blockchain-core#1140](https://github.com/helium/blockchain-core/pull/1140): Maybe get new active - state channel when current state channel is overspent - -- [erlang-libp2p#405](https://github.com/helium/erlang-libp2p/pull/405): Use a pool of CNAMEs to - fetch IPs -- [erlang-libp2p#404](https://github.com/helium/erlang-libp2p/pull/404): Avoid gossiping stale and - peers with no `listen_addr` -- [erlang-libp2p#403](https://github.com/helium/erlang-libp2p/pull/403): Reduce ack stream - inactivity timeout to 1 minute - -### Plan - -We have been beta testing `2021.12.06.0` since December 06, 2021 07:45 AM PT. Current ETA for GA is -1:30 PM PT, December 06, 2021. diff --git a/devblog/2021-12-07-app-version-385.mdx b/devblog/2021-12-07-app-version-385.mdx deleted file mode 100644 index 834a02965..000000000 --- a/devblog/2021-12-07-app-version-385.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: post -title: App Version 3.8.5 -date: 2021-12-08 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Improvements - -## Updating Hotspot Antenna and Gain - -Several users have noted that submitting the antenna and elevation was not working as expected. - - - -Through testing, the team discovered that the keyboard's "Done" button can dismiss the entire screen -erroneously letting users know they had submitted the transaction. Secondly, we found that users -tended to enter a value for dbi first and couldn't because the app required a selection from the -antenna dropdown first. We've changed this to allow input first, and defaulting the dropdown to -"Custom Antenna". - -- When updating a Hotspot antenna, tapping the done button will close the keyboard, displaying an - “Update Antenna” button to submit the transaction. -- When updating a Hotspot antenna, tapping dbi field to enter a number will default the “Select - Antenna” dropdown to “Custom” - -## New Account and Import Account UX changes - -The seed words used to generate a private key on the Helium network is based in English (US). -Certain words like "Ill" in camel case can look confusing and be interpreted differently. To help -reduce unexpected mistakes, all seed words will be capitalized. We also updated the challenge to -require the user to re-enter all 12 words instead of challenging 3 random words. - -## Maker Account Deeplinking and Transaction Signing - -We've added support in the Helium app to sign transactions on behalf of Maker apps (or other apps) -to reduce the amount of times a user will have to re-enter their seed phrase. This also ensures no -private keys are leaked to apps unofficial to the Helium Network. - -## Adds Discovery Mode Maintenance Message - -Adds clarification of when Discovery Mode will be coming back. - -## Bug Fix - -- Fixes a bug for newly added Hotspots when you tap on the name on the Home screen, and nothing - happens -- Updates Hotspot details caching to fetch latest from the API as it pertains to status and owner diff --git a/devblog/2021-12-09-blockchain-release-libp2p-fix.mdx b/devblog/2021-12-09-blockchain-release-libp2p-fix.mdx deleted file mode 100644 index 40ed1f249..000000000 --- a/devblog/2021-12-09-blockchain-release-libp2p-fix.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Libp2p Fix for Relayed Hotspots' -date: 2021-12-09 10:18 -0800 -hide_table_of_contents: true -authors: [vihu, abhay] ---- - -The core developers have tagged a new `2021.12.09.0` Hotspot firmware release which includes a -**recommended** bug fix in `erlang-libp2p`. This change potentially mitigates the zero-witness -beacon issue that has been afflicting, mostly, relayed Challenger Hotspots failing to receive -witness receipts. Special thanks to @groot#3396 and others in the #poc-discussion channel on Discord -for their efforts in tracking this issue down. - - - -#### Related PRs - -- [erlang-libp2p#412](https://github.com/helium/erlang-libp2p/pull/412): Ensure `has_private_ip` - function only checks TCP - -### Plan - -We have been beta testing `2021.12.09.0` since December 09, 2021 09:56 AM PT. Current ETA for GA is -11:00 AM PT, December 09, 2021. diff --git a/devblog/2021-12-09-console-updates-2.1.7.mdx b/devblog/2021-12-09-console-updates-2.1.7.mdx deleted file mode 100644 index 438caabee..000000000 --- a/devblog/2021-12-09-console-updates-2.1.7.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: post -title: Console Updates- ver. 2.1.7 -date: 2021-12-09 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 65 - -The latest version of Console (sprint 65) was released to production, including user enhancements, -multi-factor authentication, and a host of backend updates. - - - -### Key features and fixes - -- Multi-factor authentication (for email users, Google Auth still coming) -- Horizontal scrolling for device index page -- XOR filter suite updates -- Additional alerts for state channel disputes -- `raw_packet` information included in debug mode for join requests and uplinks - -The full list of this sprint’s features and fixes: - -- Backend [Router](https://github.com/helium/console/milestone/2?closed=1) -- Frontend [Console](https://github.com/helium/console/milestone/2?closed=1) - -(Note: a closed issue does not necessarily mean the team took action and could mean the issue was a -duplicate or no longer relevant). - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Receive window delay user configuration -- Improve Console experience on mobile devices -- Continue building out production-ready roaming services diff --git a/devblog/2021-12-14-blockchain-release-snapshot-load-fix.mdx b/devblog/2021-12-14-blockchain-release-snapshot-load-fix.mdx deleted file mode 100644 index 96d7d3628..000000000 --- a/devblog/2021-12-14-blockchain-release-snapshot-load-fix.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Latest snapshot load fix for interrupted snapshot loading' -date: 2021-12-14 09:27 -0800 -hide_table_of_contents: true -authors: [vagabond] ---- - -The core developers have tagged a new `2021.12.14.0` Hotspot firmware release which includes -**recommended** bug fixes in `erlang-libp2p` and `blockchain-core` specifically in Snapshot loading -and UPnP. - - - -### Snapshot Loading - -This change helps with a case where a snapshot obtained by checking `latest.json` instead of the -snapshot in the config file was interrupted during loading. If the snapshot in the config file was -older, this would lead to the node determining it had completed the load of the snapshot and -attempting to move onto block sync. This would often not work and the node would be stuck. - -### libp2p / UPnP improvements - -Additionally a negative UPNP/PMP renew timer was observed in some hotspot logs, which is an error. -This has also been corrected. - -### Additional Updates - -Additionally there's a fix for doing a fullsync against the early chain and a PoCv11 ETL fix, but -these do not apply to Hotspots. - -#### Related PRs - -- [erlang-libp2p#413](https://github.com/helium/erlang-libp2p/pull/413): constrain renew timer -- [erlang-libp2p#414](https://github.com/helium/erlang-libp2p/pull/414): minium retry time on lease - renewal -- [blockchain-core#1157](https://github.com/helium/blockchain-core/pull/1157): If a snapshot listed - in latest.json is interrupted when loading, fix it -- [blockchain-core#1154](https://github.com/helium/blockchain-core/pull/1154): Catch unknown region - for tagged path elements -- [blockchain-core#1153](https://github.com/helium/blockchain-core/pull/1153): fix poc v1 to work - properly with mode - -### Plan - -We have been beta testing `2021.12.14.0` since December 14, 2021 09:22 AM PT. Current ETA for GA is -12:00 PM PT, December 14, 2021. diff --git a/devblog/2021-12-14-firmware-release-packet-forwarder-config-update.mdx b/devblog/2021-12-14-firmware-release-packet-forwarder-config-update.mdx deleted file mode 100644 index d28776aa6..000000000 --- a/devblog/2021-12-14-firmware-release-packet-forwarder-config-update.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Helium Hotspot Firmware Release: Packet Forwarder Config Update' -date: 2021-12-14 15:57 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The Helium Hotspot firmware developers have identified an issue with how the LoRaWAN packet -forwarder is configured on sx1302-based Helium and RAK Hotspots after PoCv11 activation. We are -issuing an emergency release to these devices to address this issue. - - - -Hotspot owners would have noticed a lack of data transfer and PoC activity since PoCv11 activation -(when there was activity immediately before) on some of their devices. This firmware release should -fix this particular issue. - -We have tagged `2021.12.14.1` and will be issuing an emergency fix after a short period of -testing/verification. Other Hotspot manufacturers do **not** need to take this update as it only -affects Helium and RAK Hotspots. We do recommend that all Hotspot manufacturers double check their -packet forwarder settings to use the on-chain region parameters now that PoCv11 has been activated. -See prior communications from the DeWi MOC on this matter. - -### Plan - -We have been beta testing `2021.12.14.1` since December 14, 2021 4:00 PM PT. Current ETA for GA is -5:30 PM PT, December 14, 2021 or sooner. diff --git a/devblog/2021-12-16-console-updates-2.1.8.mdx b/devblog/2021-12-16-console-updates-2.1.8.mdx deleted file mode 100644 index 0d0acffc2..000000000 --- a/devblog/2021-12-16-console-updates-2.1.8.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -layout: post -title: Console Updates- v2.1.8 -date: 2021-12-16 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 66 - -The latest version of Console (sprint 66) has been deployed to production. Due to holidays we had an -extended sprint 65, which shortened sprint 66. T The team also began sprint 67 which will be the -last sprint of 2021 with a release planned for early January 2022. - - - -However, there will be an out of band release (sprint 66.5) planned 12/22 to release a few key -features before the end of the year, including the ability to configure the receive window delay -which the team believes will help with downlink issues. - -The full list of this sprint’s features and fixes: - -- Backend [Router](https://github.com/helium/router/milestone/3?closed=1) -- Frontend [Console](https://github.com/helium/console/milestone/3?closed=1) - -(Note: a closed issue does not necessarily mean the team took action and could mean the issue was a -duplicate or no longer relevant). - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to quickly update Console/Router to the newest version which - includes the latest blockchain core update to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Receive window delay user configuration -- Improve Console experience on mobile devices -- Continue building out production-ready roaming services diff --git a/devblog/2021-12-22-console-updates-2.1.9.mdx b/devblog/2021-12-22-console-updates-2.1.9.mdx deleted file mode 100644 index 7223e8cb4..000000000 --- a/devblog/2021-12-22-console-updates-2.1.9.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: post -title: Console Updates- v2.1.9 -date: 2021-12-22 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 66.5 - -The latest version of Console (sprint 66.5) has been deployed to production. - - - -This release (final planned for 2021) includes the ability to configure the receive window delay -which the team believes will help with downlink issues. More information about this feature and how -to use profiles to configure the receive window delay for devices and groups can be found -[here](https://docs.helium.com/use-the-network/console/profiles/#receive-window-delay). - -Full list of this sprint’s features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/5?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/5?closed=1) - -(Note: a closed issue does not necessarily mean the team took action, for example the issue could -have been a duplicate or no longer relevant). - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to update Console/Router to the latest version was it may - include the latest blockchain core updates to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Improve Console experience on mobile devices -- Continue building out production-ready roaming services diff --git a/devblog/2021-12-27-app-version-386.mdx b/devblog/2021-12-27-app-version-386.mdx deleted file mode 100644 index 0a6bce489..000000000 --- a/devblog/2021-12-27-app-version-386.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: App Version 3.8.6 -date: 2021-12-28 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -See how your Hotspot stacks up to the Network! We’ve added the average expected network earnings per -Hotspot to see how yours perform against other Hotspots on the network. The average earnings is -based on how many Hotspots are online that day, for creating challenges, beaconing, witnessing, and -transferring data. - - - -# Bug Fixes - -- Fixes an issue when you update the gain or elevation of a Hotspot and the card disappears, - preventing you from submitting the update. -- Fixes a QR scan issue where you cannot scan again, after scanning a few times. - -# Maker Updates - -Updates Hummingbird default antenna dbi. diff --git a/devblog/2021-12-30-blockchain-release-snapshot-loading-and-storage-improvements.mdx b/devblog/2021-12-30-blockchain-release-snapshot-loading-and-storage-improvements.mdx deleted file mode 100644 index 6299ea8ae..000000000 --- a/devblog/2021-12-30-blockchain-release-snapshot-loading-and-storage-improvements.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Loading and Storage Improvements' -date: 2021-12-30 12:40 -0800 -hide_table_of_contents: true -authors: [abhay, vihu, ke6jjj] ---- - -The core developers have tagged a new `2021.12.29.2` Hotspot firmware release which includes -**recommended** improvements in `blockchain-core` specifically in how Snapshots are loaded and -blocks are stored locally on Hotspot disks. - - - -### Snapshot Loading - -As the chain continues to grow in size and more Hotspots come online, Snapshots are starting to -become larger than 300 megabytes which make it difficult for some Hotspots to load them entirely -into memory. This change to Snapshot loading allows these files to be streamed from disk in pieces -and reduce the overall memory requirements for bootstrapping a node. This is important as some -Hotspots will reset their local storage and restart syncing blocks from a Snapshot in order to clear -room for future blocks. - -As a reminder, Snapshots are still generated on-chain by Validators when they come to agreement. The -last chain blessed snapshot was created at block height `1156321` or around -`2021-12-28 04:07:07 UTC`. - -### Blockchain Garbage Collection - -The longer a Hotspot remains online and follows the blockchain the more storage space it will -consume. Most of this storage space is dedicated to storing blocks from the blockchain, but since -blocks are less useful the older they are, a long-running Hotspot will eventually run out of space -storing blocks that it doesn't need. Previously, manufacturers have exclusively handled out-of-space -situations by completely removing the Hotspot's blockchain database and rebuilding it anew by -downloading a recent Snapshot and re-syncing. During the sync process, however, the Hotspot is -unavailable to participate in Proof-of-Coverage challenges or to route device data -- the very -things that make a Hotspot valuable to the network. - -To help reduce the frequency and duration of these blockchain database rebuilds and re-syncs, there -are two configurable items in the `miner` process which will enable garbage collection of old blocks -at miner startup. These variables are: - -- a `BLOCKCHAIN_ROCKSDB_GC_BYTES` environment variable (not set by default), and -- a `blocks_to_protect_from_gc` variable in the blockchain section of `sys.config` (current default: - 10_000) - -At startup, the `miner` will check for the presence of `BLOCKCHAIN_ROCKSDB_GC_BYTES`. If it is -present, its value will be parsed as an integer and the `miner` will examine its blockchain database -and attempt to prune this many _bytes_ of unneeded blocks from the database. However, the garbage -collection process will always keep the most recent `blocks_to_protect_from_gc` blocks in storage, -even if the `BLOCKCHAIN_ROCKSDB_GC_BYTES` limit hasn't yet been reached, to ensure the Hotspot -retains enough recent blocks to function properly. - -This should reduce the number of times a Hotspot will need to do a full reset from a Snapshot, -reducing the time a Hotspot will be unable to perform Data Transfer or Proof of Coverage. - -### Additional Updates - -- The core developers have also modified `transfer_hotspot_v2` transaction support to ensure that - the owner of the hotspot is the fee payer for the transaction and guarded this change behind - `transaction_validity_version` chain variable. Future updates will be posted to outline the time - for activation. - -- This release also contains POC-V11 related performance improvements to prepare for updating the - LoraWAN parameters in the near future. - -- Finally, the core developers have also fixed a few long standing sync stall bugs that potentially - prevented nodes syncing from the genesis block with full validation. - -#### Related PRs - -- [blockchain-core#1178](https://github.com/helium/blockchain-core/pull/1178): Fix snapshot install -- [blockchain-core#1175](https://github.com/helium/blockchain-core/pull/1175): Allow snapshot to be - stream loaded from disk -- [blockchain-core#1172](https://github.com/helium/blockchain-core/pull/1172): Make region check - compatible with previous versions -- [blockchain-core#1163](https://github.com/helium/blockchain-core/pull/1163): Read through var - cache and rewards var pre-caching -- [blockchain-core#1160](https://github.com/helium/blockchain-core/pull/1160): Repair chain if - genesis block is missing -- [blockchain-core#1149](https://github.com/helium/blockchain-core/pull/1149): Change `fee_payer` - for `transfer_hotspot_v2` to owner -- [blockchain-core#1144](https://github.com/helium/blockchain-core/pull/1144): Handle plausible - block edge cases - -### Plan - -We have been beta testing `2021.12.29.2` since December 29, 2021 05:30 PM PT. Current ETA for GA is -04:30 PM PT, December 30, 2021. diff --git a/devblog/2022-01-04-blockchain-release-libp2p-and-data-transfer-fixes.mdx b/devblog/2022-01-04-blockchain-release-libp2p-and-data-transfer-fixes.mdx deleted file mode 100644 index def1512f4..000000000 --- a/devblog/2022-01-04-blockchain-release-libp2p-and-data-transfer-fixes.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Libp2p and Hotspot Sync Fixes' -date: 2022-01-04 10:21 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2022.01.04.0` Hotspot firmware release which includes -**recommended** improvements in `miner` specifically related to ensure that Hotspots with unasserted -location are still able to sync to the head of the blockchain. Secondly this release also includes -ability to use additional packet metadata provided by certain packet forwarders. - - - -#### Allow usage of RSSIS when available - -As reported by some community members, certain packet forwarders (SX1302 for example) include -additional packet metadata **RSSIS (RSSI of signal)**. This additional metadata more accurately -reflects the power level at which a packet gets received. With the release of `2022.01.04.0` -`miner_lora` would begin using `RSSIS` whenever it's available. - -#### Related PRs - -- [miner#1328](https://github.com/helium/miner/pull/1328): Handle unasserted hotspots in - `miner_lora` module -- [miner#1317](https://github.com/helium/miner/pull/1317): Fix usage of `RSSIS` when available - -- [libp2p#418](https://github.com/helium/erlang-libp2p/pull/418): Remove duplicate call to - `changed_listener` -- [libp2p#416](https://github.com/helium/erlang-libp2p/pull/416): Use `rocksdb:snapshot` for - `fold_peers` for speedup - -### Plan - -We have been beta testing `2022.01.04.0` since January 04, 2022 09:15 AM PT. Current ETA for GA is -05:00 PM PT, January 04, 2022. diff --git a/devblog/2022-01-12-blockchain-release-snapshot-fixes.mdx b/devblog/2022-01-12-blockchain-release-snapshot-fixes.mdx deleted file mode 100644 index 67c1a375d..000000000 --- a/devblog/2022-01-12-blockchain-release-snapshot-fixes.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Fixes' -date: 2022-01-12 08:36 -0800 -hide_table_of_contents: true -authors: [vihu] ---- - -The core developers have tagged a new `2022.01.12.1` Hotspot firmware release which includes -**recommended** improvements to snapshot loading and reduces their memory footprint. Furthermore, -this release also contains bug fixes for state channel handling specifically for the client side -which should now clean the internally stored channels appropriately when they observe a -`state_channel_close` transaction. - - - -### Removal of the Hotspot Filter - -As discussed on -[Discord](https://discord.com/channels/404106811252408320/730418759298318346/930675333345206352) and -on other channels, the Helium team has been maintaining a network protection mechanism to prevent -malicious actors and other forms of institutional gaming on the Helium network. As we promised to -the network, we have removed this from this release but we urge the community to independently -verify this information. - -We await the community's decision on what to do going forward here. Cast your vote on these and -other matters pertaining to network governance on [heliumvote.com](https://heliumvote.com) - -#### Related PRs - -- [miner#1343](https://github.com/helium/miner/pull/1343): Fix legacy uses of `AS923` sub regions - when user overrides are provided -- [miner#1333](https://github.com/helium/miner/pull/1333): Update `add_snapshot` api for core fix - for iolist snapshots -- [miner#1284](https://github.com/helium/miner/pull/1284): Pre-compile deps to cache and speedup the - build process - -- [blockchain-core#1197](https://github.com/helium/blockchain-core/pull/1197): Fix snapshots from - disk hashing -- [blockchain-core#1194](https://github.com/helium/blockchain-core/pull/1194): Don't have follower - nodes serve snapshots -- [blockchain-core#1193](https://github.com/helium/blockchain-core/pull/1193): Overwrite snap file - if already on disk -- [blockchain-core#1192](https://github.com/helium/blockchain-core/pull/1192): Remove state channels - that have expired if `sc_close` got missed -- [blockchain-core#1189](https://github.com/helium/blockchain-core/pull/1189): Handle file type - snaps when sending snaps via snapshot handler -- [blockchain-core#1185](https://github.com/helium/blockchain-core/pull/1185): Add hook for submit - close txn result -- [blockchain-core#1184](https://github.com/helium/blockchain-core/pull/1184): Preserve snap - metadata on `add_snapshot` returns -- [blockchain-core#1183](https://github.com/helium/blockchain-core/pull/1183): Handle storing - locally generated iolist snaps -- [blockchain-core#1182](https://github.com/helium/blockchain-core/pull/1182): Fix `OP_SIZE` so that - it works well in all contexts - -### Plan - -We have been beta testing `2022.01.12.1` since January 12, 2022 1:30 PM PT. Current ETA for GA is -12:00 PM PT, January 13, 2022. diff --git a/devblog/2022-01-12-console-updates-2.2.0.mdx b/devblog/2022-01-12-console-updates-2.2.0.mdx deleted file mode 100644 index 7b7e61a9e..000000000 --- a/devblog/2022-01-12-console-updates-2.2.0.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.0 -date: 2022-01-13 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 67 - -Based on almost 5000 responses to our Console UI survey, 70% respondents reported accessing Console -at least multiple times a week, and almost 50% daily. - - - -A smartphone (97% and about equally split between ios and android) was reported as used to access -Console. - -This release includes a new mobile experience that can be access via your mobile device browser -(iOS, Android), and extends the receive window delay which the team believes will help with latency -that can cause downlink issues. - -More information about how to use profiles to configure the receive window delay for devices and -groups [here](https://docs.helium.com/use-the-network/console/profiles/#receive-window-delay). - -Full list of this sprint’s features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/4?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/4?closed=1) - -(Note: a closed issue does not necessarily mean the team took action, for example the issue could -have been a duplicate or no longer relevant). - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to update Console/Router to the latest version as it may - include the latest blockchain core updates to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Continue building out production-ready roaming services -- Light Hotspot support (diffs for state channels) -- Continue scaling front end -- Continue to iterate mobile experience diff --git a/devblog/2022-01-24-app-version-390.mdx b/devblog/2022-01-24-app-version-390.mdx deleted file mode 100644 index c35579259..000000000 --- a/devblog/2022-01-24-app-version-390.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: post -title: App Version 3.9.0 -date: 2022-01-24 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Updated Witnessed List - -Witnessed Lists in both the App and Explorer reflects the list of Hotspots that your Hotspot has -seen beacon. This is an improved change from displaying a list of Hotspots that has witnessed your -Hotspot as the new list directly correlates with mining rewards. - - - -Typically, the more Hotspots in your witnessed list, the more likely you'll have higher mining -rewards. This is heavily influenced by the transmit scale of the Hotspots you witness. - -In the App, for any Hotspot, tap on Hotspots Witnessed and you'll find the average transmit scale of -all Hotspots in that list. The higher the transmit scale, the higher the rewards. This is why it's -important to optimize your antenna placement so it can witness Hotspots in lesser populated areas -and higher transmit scales. - -[Read more on docs.helium.com](https://docs.helium.com/troubleshooting/understanding-witnesses/#transmit-scale-and-witnessed-list) - -## Adds block height to diagnostic report without opening it as an email - -Now users can view their Hotspot's block height directly in the report without opening it as an -email. - -# Bug Fixes - -- Checks gain/elevation for assert location transactions -- Displays pending transactions immediately after submitting (regression) -- Validates address after QR scan (regression) -- Fixes assert location screen collapsing when “reduce motion” setting is enabled in iOS - -# Maker Updates - -- Adds Midas Wireless -- Updates MerryIOT antenna change -- Allows makers to configure their own onboarding server - -# Chores - -- Upgrades and fixes bottom sheet dependencies diff --git a/devblog/2022-01-24-firmware-release-containerized-miner.mdx b/devblog/2022-01-24-firmware-release-containerized-miner.mdx deleted file mode 100644 index ffe16ca07..000000000 --- a/devblog/2022-01-24-firmware-release-containerized-miner.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: 'Helium Hotspot Firmware Release: Containerize Miner' -date: 2022-01-24 -hide_table_of_contents: true -authors: [jaykickliter, cokes518] ---- - -This release decouples miner releases from Hotspot firmware updates by running miner in a -self-updating container. - - - -Running miner in a self-updating container allows for lighter-weight, miner-only updates without the -need to fully replace Hotspot firmware. Additionally, downtime is kept to a minimum because updating -the miner container is quick and doesn't require a reboot. - -While the miner self-updating container is Docker-compatible, it does not _require_ a full instance -of Docker Engine on the miner host hardware to run and in fact this firmware change utilizes a -[lightweight, daemon-less container runtime](https://podman.io/) to orchestrate the miner container -in order to reduce the unnecessary consumption of the host hardware's resources. See the Open -Container Initiative [OCI](https://opencontainers.org/about/overview/) for more details about the -container specification and non-Docker container runtimes. - -This is not a release for Makers and only for Helium Hotspots and RAK Hotspots. There are no miner -changes. - -**Plan** - -We have been beta testing `2022.01.24.0` since January 21, 2022 6:00 PM PST. Current ETA for GA is -9:00 AM PT, January 24, 2022. diff --git a/devblog/2022-01-27-console-updates-2.2.1.mdx b/devblog/2022-01-27-console-updates-2.2.1.mdx deleted file mode 100644 index a9889d130..000000000 --- a/devblog/2022-01-27-console-updates-2.2.1.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.1 -date: 2022-01-27 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 68 - -This release includes mostly backend under the hood fixes. The team plans to do an out of band -release next week to address the latest issue related to receive window delay, specifically this -[issue](https://github.com/helium/router/issues/571). - - - -The receive window delay feature has been deployed in phases, and the team believes this update will -resolve issues related to downlinks and ADR. - -The team continues to work hard to scale out the front end given the increase in coverage, usage, -and the resulting number of device-related events. If the next release requires a maintenance window -it will be communicated via the [status page](https://status.helium.com/). Sign up to receive this -and other notifications related to Console operational status. - -Full list of this sprint’s features and fixes: Backend -[(Router)](https://github.com/helium/router/milestone/6?closed=1) - -(Note: a closed issue does not necessarily mean the team took action, for example the issue could -have been a duplicate or no longer relevant). - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to update Console/Router to the latest version as it may - include the latest blockchain core updates needed to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Continue building out production-ready roaming services -- Continue scaling front end -- Microsoft Azure IoT Central integration -- Light Hotspot support (diffs for state channels) -- Preferred Hotspot selection diff --git a/devblog/2022-01-28-blockchain-release-sync-improvements.mdx b/devblog/2022-01-28-blockchain-release-sync-improvements.mdx deleted file mode 100644 index 90ae22082..000000000 --- a/devblog/2022-01-28-blockchain-release-sync-improvements.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Denylist Support and Performance Improvements' -date: 2022-01-28 -hide_table_of_contents: true -authors: [abhay] ---- - -The core developers have tagged a new `2022.01.27.0` `miner` release. This release is recommended, -but not mandatory, for all Hotspot manufacturers. - - - -This release includes denylist support, adds snapshot polling, and better storage reclamation. The -addition of denylist support allows asynchronous updates to this list independent of miner releases. -Additionally, `2022.01.27.0` improves block sync and fixes some rare crashes. - -Reminder: `miner` Docker image releases are no longer coupled to firmware releases. This release -**does not** have a corresponding firmware release / updated SD card image (for those running RAKs -and OG hotspots). - -### Denylist Support - -This release includes support for a denylist of Hotspot addresses that limits witnessing and -challenging by the Challenger. More details on how it works are available in the -[denylist](https://github.com/helium/denylist) repository and in the PRs listed below. The -management of the denylist is through a coordinated multisig of the Helium, Inc team and members of -the community. This list can be updated on a separate release cycle from `miner` and Hotspot -firmware. - -### Snapshot and Storage Improvements - -Several updates have been made to Snapshot management and Hotspot storage of blocks. Notably, a -Consensus Group or manually blessed snapshot will now be downloaded if the Hotspot is behind on -block sync periodically rather than on startup. This should help reduce the time that a Hotspot is -not participating in the network. - -Separately, a change to how blocks are stored and garbage collected has been made to reduce the -overall storage on disk. This should reduce the number of times a Hotspot needs to be cleared before -it can start syncing again. Again, this reduces the amount of time a Hotspot is not transferring -data or performing Proof-of-Coverage actions. - -We've also made a change to improve block sync speed specifically related to storing PoC records in -the ledger. - -### Other Fixes - -We've also fixed a rare crash in miner PoC state management and implemented some JSON-RPC fixes -requested by makers. - -#### Related PRs - -- [miner#1378](https://github.com/helium/miner/pull/1378): Fix #1377 and other JSONRPC related - parameter issues. -- [miner#1390](https://github.com/helium/miner/pull/1390): Be less strict on poc statem load failure - clause -- [miner#1361](https://github.com/helium/miner/pull/1361): Add PoC denylist, downloaded from github - releases -- [miner#1392](https://github.com/helium/miner/pull/1392): configuring new denylist on docker - release profile -- [miner#1394](https://github.com/helium/miner/pull/1394): default denylist in sysconfig, disable - explicitly -- [miner#1398](https://github.com/helium/miner/pull/1398): Fix incomplete xorf api refactor - - -- [blockchain-core#1210](https://github.com/helium/blockchain-core/pull/1210): Attempt to make poc - records easier to read/write from ledger -- [blockchain-core#1208](https://github.com/helium/blockchain-core/pull/1208): Check s3 - latest-snap.json in another place -- [blockchain-core#1200](https://github.com/helium/blockchain-core/pull/1200): If snapshot file on - disk is not deserializeable, remove it -- [blockchain-core#1215](https://github.com/helium/blockchain-core/pull/1215): fix snap load - -- [blockchain-core#1218](https://github.com/helium/blockchain-core/pull/1218): handle undefined - snap_info record -- [blockchain-core#1212](https://github.com/helium/blockchain-core/pull/1212): continuous block gc - - -### Plan - -We have been testing `2022.01.27.0` since Jan 27, 2022 9:35 AM PST. Current ETA for GA is Jan 28, -2022 2:00 PM PST. diff --git a/devblog/2022-01-31-blockchain-release-streaming-snap-blocks.mdx b/devblog/2022-01-31-blockchain-release-streaming-snap-blocks.mdx deleted file mode 100644 index e9ff7b068..000000000 --- a/devblog/2022-01-31-blockchain-release-streaming-snap-blocks.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Snapshot Loading Improvements' -date: 2022-01-31 -hide_table_of_contents: true -authors: [xandkar, vagabond] ---- - -The core developers have tagged a new `2022.01.29.0` `miner` release. This release is recommended -for all makers, but is only mandatory for Hotspots that are no longer able to load the latest -snapshot. As the network gets larger and the snapshot size increases, Hotspots with less RAM will -have trouble loading them. We will continue to support these Hotspots until all manufacturers have -an upgrade path to Light Hotspot firmware. - - - -Prior to this release, the blocks from snapshot were all loaded into memory before being imported; -this release switches to importing the snapshot blocks from disk, _one at a time_, and avoiding -using more memory than is strictly necessary. - -#### Related PRs - -- [blockchain-core#1225](https://github.com/helium/blockchain-core/pull/1225): stream blocks from - file - -### Plan - -We have been testing `2022.01.29.0` since Jan 28, 2022 10:00 PM EST. Current ETA for GA is Jan 31, -2022 2:00 PM PST. diff --git a/devblog/2022-01-31-console-updates-2.2.1.5.mdx b/devblog/2022-01-31-console-updates-2.2.1.5.mdx deleted file mode 100644 index 7541e1814..000000000 --- a/devblog/2022-01-31-console-updates-2.2.1.5.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.1.5 -date: 2022-01-31 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: out of band - -This is an out of band release that addresses the latest issue related to receive window delay, -specifically this [issue](https://github.com/helium/router/issues/571). - - - -The receive window delay feature has been deployed in phases, and the team believes this update will -resolve issues related to downlinks and ADR. - -More information about how to use profiles to configure the receive window delay for devices and -groups [here](https://docs.helium.com/use-the-network/console/profiles/#receive-window-delay). - -In addition, the team addressed this [issue](https://github.com/helium/router/issues/590) by -restoring the previous template functionality. - -### Open source users - -- New users should use the latest master version. - -- Existing users are highly recommended to update Console/Router to the latest version as it may - include the latest blockchain core updates needed to ensure smooth operations. - -For upgrading instructions check -[readme](https://github.com/helium/console#upgrading-your-open-source-consolerouter). - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Continue building out production-ready roaming services -- Continue scaling front end -- Microsoft Azure IoT Central integration -- Light Hotspot support (diffs for state channels) -- Preferred Hotspot selection diff --git a/devblog/2022-02-04-hotspot-firmware-release-fixes-and-handoff-preparation.mdx b/devblog/2022-02-04-hotspot-firmware-release-fixes-and-handoff-preparation.mdx deleted file mode 100644 index 1707abde7..000000000 --- a/devblog/2022-02-04-hotspot-firmware-release-fixes-and-handoff-preparation.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Operational Fixes for RAK/MNTD and Helium Hotspots' -date: 2022-02-04 11:51 -0800 -hide_table_of_contents: true -authors: [abhay] ---- - -_Note: This release is only relevant to RAK/MNTD and Original Helium Hotspots._ - - - -The `2022.02.04.1` release continues the work that the Helium team is doing to enable RAK/MNTD and -Original Helium Hotspots to use `miner` containers rather than custom firmware builds. At a high -level, this release includes several fixes to how the `miner` container operates on the firmware. -This release also fixes an issue with Diagnostic Reports, where users were unable to retrieve some -details. Finally, this release contains a fix where `miner` containers were unable to start for -Hotspots that have not been powered on for over a year. - -Although this isn't directly Hotspot owner facing, it allows easier iteration of new `miner` -releases and reduces restarts and downtime of Hotspots. Separately, the work also enables the RAK -team to take over managing the firmware for RAK/MNTD Hotspots. Original Helium Hotspots will -continue to be managed by the Helium team. - -This release does not update the `miner` container (which will be a separate release that will go -into testing as well). A separate announcement will follow regarding this release. - -For those Hotspot owners flashing new SD Cards for RAK/MNTD and original Helium Hotspots, please use -this base image going forward. No action is required otherwise and all RAK/MNTD and original -Hotspots will receive this update automatically over the air as long as your Hotspot is plugged in -and connected to the internet. - -**Plan** - -We have been beta testing `2022.02.04.1` since February 4, 2022 12:00 PM PST. Current ETA for GA is -14:30 PM PT, February 4, 2022. diff --git a/devblog/2022-02-07-app-version-310.mdx b/devblog/2022-02-07-app-version-310.mdx deleted file mode 100644 index 4d9dc3737..000000000 --- a/devblog/2022-02-07-app-version-310.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: post -title: App Version 3.10.0 -date: 2022-02-08 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Transfer Hotspot v2 - -A new way to transfer Hotspots is now available on the app. Now transferring Hotspots is as easy as -sending a payment transaction. Hotspot **sellers** can initiate the transfer from Hotspot Settings, -the same as before, but instead of waiting for the **buyer** to accept the transaction, the transfer -is immediately submitted to the blockchain. Once cleared, the **buyer** will see the new Hotspot in -their app. When the transfer is successful, both buyers and sellers will receive a notification. - - - -Please note that Sellers now pay the transaction fee of ~55,000 DC. - -Hotspots must have had Proof-of-Coverage activity (creating a challenge, beaconing, or witnessing) -in the last 1200 blocks (approximately 20 hours) in order to be transferred. - -## Earnings Map Filter - -Now available on the app, the earnings map filter introduced in Explorer in January can be found by -tapping the Map Layers icon on a Hotspot details view. Other map filters include Transmit Scale, -Witnessed Hotspots, and Coverage. - -## Hotspot Year to Date earnings - -See how much your Hotspot has earned this year by going to a Hotspot and tapping **YTD**. - -# Bug Fixes - -- We’ve fixed an issue when the Maker app uses deeplinking to add a Hotspot to the network did not - elicit the correct error message. Now we know to check if the Hotspot was already onboarded and - surfaces a clearer error message to contact the Maker for next steps. - -# Maker Updates - -- Adds Dragino Hotspot - -# Chores - -## Removes HNTenna from available list of Antennas - -Users should use the Custom Antenna dropdown to enter the dbi of custom antennas that did not come -from approved HIP-19 Hotspots. All approved Maker antennas are still selectable from the dropdown -based on name. diff --git a/devblog/2022-02-08-firmware-release.mdx b/devblog/2022-02-08-firmware-release.mdx deleted file mode 100644 index f4fcf0fe3..000000000 --- a/devblog/2022-02-08-firmware-release.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Operational Improvements' -date: 2022-02-08 -hide_table_of_contents: true -authors: [cokes518] ---- - -The Helium team has tagged a new `2022.02.08.0` `firmware` release for Original Helium and RAK/MNTD -Hotspots. This minor release changes the interval between automated update checks for a Hotspot's -`miner` container. It has been updated to every 2 hours, from the current 5 minute interval. This -update also changes how a Hotspot prunes old miner images, removing the possibility of -re-downloading the latest image multiple times. These changes should reduce the amount of bandwidth -an Original or RAK/MNTD Hotspot consumes. - - - -### Plan - -We have been testing `2022.02.08.0` since Feb 8, 2022 12:00 PM PST. Current ETA for GA is Feb 8, -2022 2:30 PM PST. diff --git a/devblog/2022-02-10-console-updates-2.2.2.mdx b/devblog/2022-02-10-console-updates-2.2.2.mdx deleted file mode 100644 index f2eb5cddd..000000000 --- a/devblog/2022-02-10-console-updates-2.2.2.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.2 -date: 2022-02-10 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 69 - -The team has pushed the latest v2.2.2 release to production. Highlights include updates to Receive -Window Delay feature, added message queue (for Production Console only) to scale frontend database, -and ux tweaks. In addition, for open source users the front end team added prebuilt Console images -hosted on Quay.io so open source users do not have to build their own Console images on docker. - - - -The team believes certain downlink issues can be addressed by specifying a higher number to increase -the receive delay window. - -For more information about this feature and how to apply to devices and labels with Configuration -profiles, check -[here](https://docs.helium.com/use-the-network/console/profiles/#receive-window-delay). - -Full list of this sprint’s implemented features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/7?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/7?closed=1) - -(Note: a closed issue does not necessarily mean the team took action, for example the issue could -have been a duplicate or no longer relevant). - -### Open source users - -Check the updated [readme](https://github.com/helium/console) for instructions on how to use the -prebuilt Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Expanding number of APIs -- Microsoft Azure IoT Central integration -- Continue building out production-ready roaming services -- Scaling out roaming services -- Preferred Hotspot selection diff --git a/devblog/2022-02-10-rak-burrow-firmware-release.mdx b/devblog/2022-02-10-rak-burrow-firmware-release.mdx deleted file mode 100644 index 2e0ae0322..000000000 --- a/devblog/2022-02-10-rak-burrow-firmware-release.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Allow RAK Support for RAK/MNTD Hotspots' -date: 2022-02-10 -hide_table_of_contents: true -authors: [cokes518] ---- - -The Helium team has tagged a new `2022.02.10.0` `firmware` release for Original Helium and RAK/MNTD -Hotspots. All Original Helium/RAK MNTD Hotspots have a designated `hardware_type` to identify its -hardware version at the manufacturing stage. By targeting Hotspots by its `hardware_type`, this -release will enable RAK/MNTD Support teams to investigate and diagnose Hotspot-related issues in a -secure manner without interaction from the Helium Support team. - - - -Original Helium and RAK/MNTD Hotspot owners that install `2022.02.10.0` on an SD Card will not need -to specify their `hardware_type` in order to receive this update. The firmware will automatically -detect the Hotspot manufacturer and enable the relevant support tools. - -### Plan - -We have been testing `2022.02.10.0` since Feb 4, 2022 12:00 PM PST. Current ETA for GA is Feb 10, -2022 3:00 PM PST. diff --git a/devblog/2022-02-11-network-disurption-post-mortem.mdx b/devblog/2022-02-11-network-disurption-post-mortem.mdx deleted file mode 100644 index 4ada2b964..000000000 --- a/devblog/2022-02-11-network-disurption-post-mortem.mdx +++ /dev/null @@ -1,145 +0,0 @@ ---- -layout: post -title: 'Network Disruption Postmortem: 2022-02-07' -date: 2022-02-11 17:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -  - -# What happened - -On Monday 2022-02-07 5:46 AM UTC the team announced a chain halt caused by enlarged block 121528. -Normal chain operations were announced at 3:04 PM UTC, less than 10 hours later. - - - -Throughout the disruption, devices continued to have coverage and operate normally as state channels -remained open processing packets. There were also no risks to Hotspot owners or HNT holders but they -did experience a delay in transaction processing and Proof-of-Coverage activity. - -# Cause - -A roaming server (see Roaming Server background below) crash created a disparity between its state -channel record and the record held by state channel participants (Hotspots). - -Due to this disparity, the state channel participants submitted a large number of dispute -transactions which increased the size of block `121528`. Low-performance validators in the Consensus -Group were unable to consume the large block, ultimately causing the chain halt. - -# Recovery - -The team worked with the validator community to execute a command for validators in the Consensus -Group. This command allowed the validators to clear the pending dispute transactions and replace -them with a chain variable that set the state channel grace period to 1 block. - -The state channel grace period is the window when valid state channel disputes can be submitted -after state channels close. Typically, this grace period is set at a number of blocks which allows -state channel participants time for dispute transactions. By limiting it to 1 block, essentially no -valid disputes can be submitted. - -# Resolution - -A fix was implemented and deployed with the latest Validator release v1.7.0 which limits valid -dispute transactions. This [fix](https://github.com/helium/blockchain-core/pull/1229/) provides the -foundation for a future chain variable which will effectively eliminate the possibility that a large -amount of valid dispute transactions can be submitted. This upgrade is designed to increase network -resiliency but also impacts transfer rewards if disputes occur so an accompanying HIP will be -proposed soon. - -The roaming servers have been upgraded and additional monitoring has been implemented to anticipate -and prevent future crashes. - -The team is further considering whether to adjust the maximum block size. - -In addition, to upgrade communication channels with the Validator community Helium Status includes -an additional page specifically for validator operators. - -To reduce the time to coordinate responses to situations like this in the future, operators hosting -large numbers of validators are **highly encouraged** to subscribe to the Helium Validator -[Status](http://validators-status.helium.com/) page. - -This is purely an opt-in channel, but will allow validator operators to subscribe and receive email, -sms, or webhook notifications. - -Additionally, an opt-in “bat signal”, a way to notify the validator community that help is needed, -so core developers can work with validator operators in real-time during future incidents is also -getting worked out. - -# Roaming Server Background - -Helium has been partnering with several leading LoRaWAN Network Service Providers to provide roaming -services. These service providers value the amount and growth of network coverage the Helium -community has provided to augment their own coverage for their customers. - -To enable this service, Helium has set up roaming servers that accept and purchase packets on behalf -of the interested partners. These roaming servers use a simplified version of Console’s backend -(Router), called Packet Purchaser. Because of the explosive growth of the Network, the number of -packets “seen” by these roaming servers continues to rapidly increase. - -A spike in traffic caused one of the roaming servers to go down, and when it restarted there were -differences between the state channel record of the packet purchaser and the records held by a large -number of state channel participants (Hotspots). These Hotspots saw the difference in the packet -purchaser state channel and submitted dispute transactions. A large number of these dispute -transactions were added to the block which became difficult for low-performance validators in the -Consensus Group to consume. - -# Community Powered - -Many THANKS to our overall validator community, but _specifically to the validator operators who -quickly responded to the core team’s requests_ for aid and helped ensure the chain recovered and -returned to normal operations. - -Scaling challenges are related to the enormous demand not only to provide coverage (nearing 600K -Hotspots), but also the increased usage of the Network. - -The Network is still in its early stages and we appreciate your patience and support as we continue -to work together to build the world’s largest contiguous wireless network. - -# Timeline of Announcements - -Throughout the disruption, the team worked to provide frequent updates and report on status: - -**02/07 Monday 5:56 AM (all times UTC)** Helium Validator operators and core developers are -investigating a potential chain halt @ block 1215286. The Consensus Group has not produced a block -in about 46 minutes. - -More information to come as we uncover more details. - -Validator community, please come online if you have validators currently in the Consensus Group. - -Proof of Coverage may be degraded, and other transactions may be queued until the Consensus Group -resumes block production. Data Transfer remains unaffected. - -**6:32 AM** The Consensus Group is still struggling to produce the next block with transactions and, -as a result, the chain remains halted. Data Transfer continues to be unaffected but all other -blockchain activity is delayed, including transaction processing. - -**7:49 AM** We are continuing to monitor the Consensus Group. It is making slow progress but has not -produced a block yet. - -**9:09 AM** The Validator community continues to monitor the Consensus Group as it tries to agree -upon a block. Once this is completed, the core developers will prepare a chain variable to address -the State Channel issue that may be affecting the blockchain. Although we are prepared to issue a -Rescue block, we are hoping to avoid doing this as Data Transfer continues to be unaffected. Other -transactions (including Hotspot onboarding, Payments, and Proof of Coverage) remain degraded at this -time. - -**1:36 PM** The Validator community is still trying to get the chain started again. As mentioned -before we are hoping to avoid a Rescue Block since Data Transfer is still unaffected. Pending -transaction posts should be avoided and will remain disabled, and other transactions (including -Hotspot onboarding, Payments, and Proof of Coverage) remain degraded at this time. - -**3:04 PM** Validators have resumed block production and the chain is back to normal operations. -Pending transactions have been re-enabled and already cleared. - -A large block was created and the skip of the halting block included wiping the transaction buffer -and replacing with a chain var to temporarily reduce the state channel grace period to mitigate the -issue. - -However, state channel closes will be negatively impacted including rewards for packet transfer and -high overages. Another chain var will be issued to return the state channel back to normal -operations. - -The team is performing further investigation to determine root cause. diff --git a/devblog/2022-02-17-ota-metadata.mdx b/devblog/2022-02-17-ota-metadata.mdx deleted file mode 100644 index d749bb167..000000000 --- a/devblog/2022-02-17-ota-metadata.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Improve OTA Targeting' -date: 2022-02-17 -hide_table_of_contents: true -authors: [cokes518] ---- - -The Helium team has tagged a new `2022.02.17.0` firmware release for Original Helium and RAK/MNTD -Hotspots. - - - -This release adds a file that enables the OTA server to target updates specific to a subset of -Hotspots for testing purposes. It also enables the final update to RAK/MNTD Hotspots so that they -can receive software updates from RAK/MNTD directly. - -For those Hotspot owners flashing new SD Cards for RAK/MNTD and original Helium Hotspots, please use -this base image going forward. No action is required otherwise and all RAK/MNTD and original -Hotspots will receive this update automatically over the air as long as your Hotspot is plugged in -and connected to the internet. - -### Plan - -We have been testing `2022.02.17.0` since Feb 16, 2022 12:00 PM PST. Current ETA for GA is Feb 17, -2022 3:00 PM PST. diff --git a/devblog/2022-02-23-blockchain-release-sync-improvements.mdx b/devblog/2022-02-23-blockchain-release-sync-improvements.mdx deleted file mode 100644 index b45459a65..000000000 --- a/devblog/2022-02-23-blockchain-release-sync-improvements.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Sync Improvements and Mandatory Core Upgrade' -date: 2022-02-23 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.02.22.0` `miner` and `blockchain-core` release. This -release is **mandatory** for all Hotspot Makers (please update your fleet by March 3, 2021 00:00 -UTC) and will be mandatory in the near future for Validators, ETLs, Routers and Nodes. It contains a -network improvement that is gated behind some currently inactive chain variables. Hotspots without -this update _will not_ be able to sync or mine once the chain variable is activated later. - - - -In addition to these improvements, this release will be the first to ship (but not use) some of the -infrastructure required for the transition to Light Hotspots: `gateway-rs`. The use of `gateway-rs` -will be -[controlled by the value of a new `sys.config` variable `gateway_and_mux_enable`](https://github.com/helium/miner/pull/1370), -which is set to `false` by default. - -If this variable is set to `true`, however, the image will run an internal copy of `gateway-rs` in a -support role to the miner process. In this phase of the transition, the `gateway-rs` will perform -two functions for the miner: process all traffic to and from the packet forwarder and interface with -the security chip (ECC) for all device transactions. - -This will allow manufacturers to begin testing the behavior of `gateway-rs`, including its ability -to transfer device packets without fully syncing with the blockchain. The miner process will -continue to manage PoC traffic for the hotspot during this phase as usual. - -Lastly, the core team has made several performance improvements that allow Hotspots to sync and stay -in sync with the blockchain over libp2p. - -#### Related PRs - -- [miner#1370](https://github.com/helium/miner/pull/1370): Integrate rust gateway-rs and semtech-udp - mux as erlang ports of miner #1370 - -- [blockchain-core#1229](https://github.com/helium/blockchain-core/pull/1229): State Channel - Disputes - -- [erlang-libp2p#424](https://github.com/helium/erlang-libp2p/pull/424): Remove extremely noisy - logging statement - -### Plan - -We have been testing `2022.02.22.0` since Feb 22, 2022 3:00 PM PST. Current ETA for GA is Feb 23, -2022 1:30 PM PST. diff --git a/devblog/2022-02-24-console-updates-2.2.3.mdx b/devblog/2022-02-24-console-updates-2.2.3.mdx deleted file mode 100644 index a77a871f5..000000000 --- a/devblog/2022-02-24-console-updates-2.2.3.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.3 -date: 2022-02-24 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 70 - -The latest v2.2.3 release has been releaseed to production by the team. Based on a number of -conversations with users, a large number of Console API’s were added to this release and existing -ones updated. - - - -Updated Console API docs [here](https://docs.helium.com/api/console). - -Full list of this sprint’s implemented features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/8?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/8?closed=1) - -(Note: a closed issue does not necessarily mean the team took action, for example the issue could -have been a duplicate or no longer relevant). - -### Open source users - -Check the updated [readme](https://github.com/helium/console) for instructions on how to use the -prebuilt Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Continue building out production-ready roaming services -- QR code scanning with mobile console -- Microsoft Azure IoT Central integration -- Scaling out roaming services -- Preferred Hotspot selection diff --git a/devblog/2022-02-28-blockchain-improvements-sync-bugfix.mdx b/devblog/2022-02-28-blockchain-improvements-sync-bugfix.mdx deleted file mode 100644 index 98f93b007..000000000 --- a/devblog/2022-02-28-blockchain-improvements-sync-bugfix.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Blockchain Sync and Snapshot Improvements' -date: 2022-02-28 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.02.28.0` `miner` and `blockchain-core` release. This -release is **recommended** for all Hotspot Makers. - - - -The primary goal of this release is to address issues affecting a Hotspot's ability to stay in sync, -especially 25% of RAK Hotspots and 15% of Original Helium Hotspots. Also included is a new, -backwards compatible way for Hotspots to load compressed snapshots. This should reduce the amount of -bandwidth required for Hotspots to download snapshots. - -#### Related PRs - -- [miner#1458](https://github.com/helium/miner/pull/1458): Updates core dependencies - -- [blockchain-core#1252](https://github.com/helium/blockchain-core/pull/1252): Clear sync_pid in - state when sync process stops - -- [blockchain-core#1254](https://github.com/helium/blockchain-core/pull/1254): Download and - deserialize compressed snapshots - -### Plan - -We have been testing `2022.02.28.0` since Feb 28, 2022 2:00 PM PST. Current ETA for GA is March 1, -2022 8:00 AM PST. diff --git a/devblog/2022-03-04-app-version-311.mdx b/devblog/2022-03-04-app-version-311.mdx deleted file mode 100644 index 8846854c3..000000000 --- a/devblog/2022-03-04-app-version-311.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: App Version 3.11.0 -date: 2022-03-04 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Identify Hotspots on Denylist - -When browsing the network map on the app, Hotspots on the denylist will appear with a red badge next -to their name. Denylist Hotspots are those identified to be gaming on the Helium Network. - - - -# Bug Fixes - -- Fixed a bug where the timeline displayed for a Hotspot Earnings Chart was 14D when it is 7D -- Added in extra check when Transferring Hotspots during API downtime - -# Maker Updates - -- Adds support for Transfer Hotspot deeplinking from Maker apps -- Fixes universal linking on Android 12 devices (for deeplinking purposes) diff --git a/devblog/2022-03-07-blockchain-improvements-sync-bugfix.mdx b/devblog/2022-03-07-blockchain-improvements-sync-bugfix.mdx deleted file mode 100644 index 003872756..000000000 --- a/devblog/2022-03-07-blockchain-improvements-sync-bugfix.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -layout: post -title: 'Blockchain Release: Blockchain Sync and Snapshot Improvements' -date: 2022-03-07 -hide_table_of_contents: true -authors: [vagabond] ---- - -The core developers have tagged a new `2022.03.07.0` `miner` and `blockchain-core` release. This -release is **recommended** for all Hotspot Makers. - - - -The primary change in this release is a fix for an issue that causes the miner hang forever while -downloading Snapshots. This becomes more likely for Hotspots in low bandwidth environments as the -chain grows and Snapshots get larger. As mentioned in other venues, the real solution for this is -not needing Snapshots at all when all Hotspots become Light and stop following the chain. - -#### Related PRs - -- [blockchain-core#1277](https://github.com/helium/blockchain-core/pull/1277): Work-around that - hackney doesn't send a message on timeouts when async option is used - -### Plan - -We have been testing `2022.03.07.0` since Mar 7, 2022 6:00 AM PST. Current ETA for GA is March 7, -2022 10:00 AM PST. diff --git a/devblog/2022-03-09-console-updates-2.2.4.mdx b/devblog/2022-03-09-console-updates-2.2.4.mdx deleted file mode 100644 index dc988ad19..000000000 --- a/devblog/2022-03-09-console-updates-2.2.4.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.4 -date: 2022-03-10 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 71 - -The team has released `v2.2.4` release to production. A number of usability updates were completed -including minimizing user input for Azure IoT Hub, making it simpler to add a label to new devices, -and adding abiliity to use mobile UI to scan QR codes for devices that have implemented the LoRaWAN -Device Identification QR Codes specification. - - - -In addition, additional APIs were added to create custom integrations including HTTP, MQTT, Azure -IoT Hub, and AWS IoT Core. - -Full list of this sprint’s implemented features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/9?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/9?closed=1) - -(Note: a closed issue does not necessarily mean the team took action, for example the issue could -have been a duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Continue building out production-ready roaming services -- Organization migration tools -- Microsoft Azure IoT Central integration -- Scaling out roaming services -- Preferred Hotspot selection diff --git a/devblog/2022-03-15-clean-sd-cards.mdx b/devblog/2022-03-15-clean-sd-cards.mdx deleted file mode 100644 index 8d470c8f9..000000000 --- a/devblog/2022-03-15-clean-sd-cards.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Improve Storage Reclamation' -date: 2022-03-15 -hide_table_of_contents: true -authors: [jaykickliter] ---- - -The Helium team has tagged a new `2022.03.15.0` firmware release for Original Helium and RAK/MNTD -Hotspots. - - - -This release changes the way Hotspots manage disk usage for storing local blockchain data. -Specifically we are reducing the threshold that Hotspots clear up their disk and resync from a -Snapshot. The threshold has been reduced from 90% to 70% full. - -As disk utilization increases, we have noticed that Hotspots have a harder time syncing blocks so -more frequent clearing allows Hotspots to recover from a non mining state sooner. - -For those Hotspot owners flashing new SD Cards for RAK/MNTD and original Helium Hotspots, please use -this base image going forward. No action is required otherwise, and all RAK/MNTD and original -Hotspots will receive this update automatically over the air as long as your Hotspot is plugged in -and connected to the internet. - -### Plan - -We have been testing `2022.03.15.0` since Mar 11, 2022 11:30 AM PST. Current ETA for GA is Mar 15, -2022 1:30 PM PST. diff --git a/devblog/2022-03-24-console-updates-2.2.5.mdx b/devblog/2022-03-24-console-updates-2.2.5.mdx deleted file mode 100644 index 83fc9e0d7..000000000 --- a/devblog/2022-03-24-console-updates-2.2.5.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.5 -date: 2022-03-24 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 72 - -Console `v2.2.5` has been released to production. During this sprint the team also launched Helium -Roaming Services. LoRaWAN network providers can learn more about how to leverage Helium coverage -[here](https://blog.helium.com/helium-roaming-services-brings-new-opportunities-for-partners-4d940ee7a030). - - - -The ability to export and import complete Organizations was added as well as a number of backend -community reported issues. Users can migrate their Organization from a Console instance hosted by -one provider to another or to their own hosted version of Console. Note Data Credits are not -transferable and will not be migrated. For more information check -[here](https://docs.helium.com/use-the-network/console/users/#organizations). - -**Important**: The Multiple Packet feature has been updated to accurately reflect the amount -specified by user configuration regardless if they're uplinks or initial joins. - -Full list of this sprint’s implemented features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/10?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/10?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -**Important**: the seed nodes in the `.env-router` template need to be updated. Check the -`.env-router` template file, and copy the value of the `ROUTER_SEED_NODES env var` to your local -`.env-router` file. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Microsoft Azure IoT Central integration -- Scaling out roaming services -- Preferred Hotspot selection diff --git a/devblog/2022-03-25-miner-embedded-gateway-improvements.mdx b/devblog/2022-03-25-miner-embedded-gateway-improvements.mdx deleted file mode 100644 index fd0b48f40..000000000 --- a/devblog/2022-03-25-miner-embedded-gateway-improvements.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -layout: post -title: 'Miner Release: Embedded Gateway Stability and Configuration Improvements' -date: 2022-03-25 -hide_table_of_contents: true -authors: [jeffgrunewald] ---- - -The core developers have tagged a new `2022.03.23.1` `miner` release. This release is **mandatory** -for all Hotspot Makers. We request that Hotspot Manufacturers upgrade their fleets by 12:00 UTC on -2022-03-29. This will allow the approved -[HIP 54](https://github.com/helium/HIP/blob/main/0054-h3dex-targeting.md) chain variable to be -activated and ensure Hotspots can continue creating Challenges using the new H3Dex-based PoC -targeting. - - - -The primary changes for this release are related to simplifying configuration or improving stability -of the embedded light hotspot `helium_gateway` that, once enabled, will have device packet routing -and crypto signing delegated to it from the primary miner process. With this change, the rpc -connection between the miner and light gateway processes becomes more robust, and all UDP listening -ports are automatically configured from the primary `miner, radio_device` setting in the -`sys.config` which defaults to 1680. This release includes an updated version of the gwmp-mux -embedded application routing UDP packets between the light hotspot and miner services. This release -_does not_ enable the embedded light gateway and mux services by default. - -#### Related PRs - -- [miner#1479](https://github.com/helium/miner/pull/1479): Consolidate udp listener port config - under radio_device -- [miner#1470](https://github.com/helium/miner/pull/1470): Monitoring and testing gateway grpc pid -- [miner#1387](https://github.com/helium/miner/pull/1387): Support h3dex based targeting -- [blockchain-core#1214](https://github.com/helium/blockchain-core/pull/1214): h3dex andymck - additions - -### Plan - -We have been testing `2022.03.23.1` since Mar 23 12:00 PM PST. Current ETA for GA is March 25, 2022 -10:00 AM PST. diff --git a/devblog/2022-03-25-poc-interval-update.mdx b/devblog/2022-03-25-poc-interval-update.mdx deleted file mode 100644 index f62e7b108..000000000 --- a/devblog/2022-03-25-poc-interval-update.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: post -title: 'PoC Rate Adjustments until HIP 55 / Validator Challenges' -date: 2022-03-25 -hide_table_of_contents: true -authors: [abhay] ---- - -The core developers are changing the PoC Interval from `475` to `950`. Hotspots will PoC less often -however total average rewards will remain unchanged. PoC rate has no effect on average individual -Hotspot earnings, but may increase variability of rewards. This will help the chain process -transactions more efficiently. Please read the details below for our reasoning. - - - -## Details - -The Helium Blockchain uses a work algorithm called “Proof of Coverage” (PoC) to verify that Hotspots -are located where they claim. Today, Hotspots take on the responsibility of creating Challenges on -the network. This responsibility changes with the recently approved and still being implemented HIP -55, which introduces a fixed limit of PoC challenges per block. - -At this time, new Challenges are created every 475 blocks by Hotspots on the Helium blockchain. With -over 600K Hotspots on the network and nearly 500K Hotspots creating those challenges, the network is -trying to support almost 1,700 PoC transactions alone per block and over 2.4mm transactions per day. - -The core developers believe that because of this, the network is currently bottlenecked on -transaction processing. This is seen by payments taking longer to confirm, Hotspot onboarding taking -longer, Oracle price submissions being rejected, and other transactions not clearing. - -We believe that the blockchain is currently only able to support around 1,000 PoC transactions per -block, the intended target for HIP 55. We believe that we need to adjust PoC Challenge Interval to -match the intended effects of HIP 55 sooner than the launch of Validator Challenges. As we’ve done -before, we will be increasing the PoC Interval, this time to `950`. The last time we adjusted PoC -interval, we immediately saw transactions start clearing more efficiently and more chain stability. - -This is a significant change but will immediately relieve the chain from this bottleneck and give us -time to focus on the last parts of testing HIP 55 and ship it next month. The goal of HIP 55 is to -keep the amount of total PoC activity across the network fixed regardless of the number of Hotspots -that come on the network. Also a reminder that there's always a fixed amount of HNT issued per month -which means there's a fixed amount of HNT "available per block". This does not change at this time -or after HIP 55. - -For Hotspot Owners, you may see a reduction in daily PoC activity as we have seen before. Over a -longer time frame, however, this activity will still be more consistent and reliable. We’ve seen -reports of witness activity issues and this is directly related to transaction clearing. The -blockchain will have less of a backlog of transactions to process and clear transactions faster. - -## Plan - -We will be issuing this change today Friday, March 25 where we will be setting -`poc_challenge_interval` to `950` around 2100 UTC / 02:00 PM Pacific Time. This immediate change -should give us the headroom to support about 125k more Hotspots (well over a month at current -Hotspot growth rate) actively generating challenges. diff --git a/devblog/2022-03-29-firmware-release.mdx b/devblog/2022-03-29-firmware-release.mdx deleted file mode 100644 index 51ff7fbe2..000000000 --- a/devblog/2022-03-29-firmware-release.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -layout: post -title: - 'Hotspot Firmware Release: Improve ECC Slot Handling and re-enable Gateway-rs Packet Forwarding' -date: 2022-03-29 -hide_table_of_contents: true -authors: [jaykickliter] ---- - -The Helium team has tagged a new `2022.03.29.1` firmware release for Original Helium and RAK/MNTD -Hotspots. - - - -This release fixes a regression in ECC key slot handling. Earlier firmware releases specified ECC -key slots 0 and 15 for public and onboarding keys, respectively. However, recent releases specified -slot 0 for both. This release reverts `sys.config` to the old spec. Note that slot 15 was only used -for _some_ very early first generation Hotspots thus very few not-yet-onboarded Hotspots were -affected by the reversion. No action is required by Hotspot owners. - -Additionally, this release uses the embedded rust gateway and gwmp-mux processes to forward packets -instead of the erlang miner, as a step toward the transition to Light Hotspots. - -For those Hotspot owners flashing new SD Cards for RAK/MNTD and original Helium Hotspots, please use -this base image going forward. No action is required otherwise, and all RAK/MNTD and original -Hotspots will receive this update automatically over the air as long as your Hotspot is plugged in -and connected to the internet. - -### Plan - -We have been testing `2022.03.29.1` since Mar 24, 2022 09:30 AM PST. Current ETA for GA is Mar 29, -2022 3:00 PM PST. diff --git a/devblog/2022-03-31-app-version-400.mdx b/devblog/2022-03-31-app-version-400.mdx deleted file mode 100644 index ca9fa20ef..000000000 --- a/devblog/2022-03-31-app-version-400.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -layout: post -title: App Version 4.0.0 -date: 2022-03-31 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## OS Widgets (Perronef5 / Peroni_F5#3413) - -iPhone users - our community member Perroni_F5 has added an incredible feature to the Hotspot app, -adding 2 widgets to your app experience: - - - -- Helium Balance Widget (Great for quickly looking at your balance, 24 hr earnings, and current - helium price.) -- Helium Hotspots Widget (Great to take a quick glance at some of your hotspots details.) - -Thank you Perroni_F5 for your contribution! - -# Maker Updates - -## Updates to RAK Support Email - -- Emails now go directly to RAK Support team when you run a diagnostic report. - -## Direct Users to onboard Bobcats using the Bobber App - -- As more Makers make their apps available on the App store, we’ll be redirecting them to use their - new app instead. The first of which is the Bobber app that has been in market for over a month. - -Remember, if a maker app asks you for your 12 word seed phrase, do not enter it! Only enter your -seed phrase in trusted Helium apps. - -## Notice to Pixel 6 and Sensecap Hotspot Owners - -- Pixel 6 Android phones are unable to pair with Sensecap Hotspots in our testing. Other phone types - and Hotspot manufacturers combinations work without a problem. Just a heads up! diff --git a/devblog/2022-03-31-firmware-release.mdx b/devblog/2022-03-31-firmware-release.mdx deleted file mode 100644 index f0e5cf9a7..000000000 --- a/devblog/2022-03-31-firmware-release.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Revert Rust Gateway' -date: 2022-03-31 -hide_table_of_contents: true -authors: [abhay] ---- - -The Nova devs have tagged a new `2022.03.31.0` firmware release for Original Helium and RAK/MNTD -Hotspots. - - - -This release disables the embedded Rust gateway and gwmp-mux processes. The Erlang miner will begin -forwarding packets again. We have identified an issue that was preventing Data Transfer on these -specific Hotspots that we will resolve in a subsequent release. - -For those Hotspot owners flashing new SD Cards for RAK/MNTD and original Helium Hotspots, please use -this base image going forward. No action is required otherwise, and all RAK/MNTD and original -Hotspots will receive this update automatically over the air as long as your Hotspot is plugged in -and connected to the internet. - -### Plan - -We have been testing `2022.03.31.0` since Mar 31, 2022 07:30 AM PST. Current ETA for GA is Mar 31, -2022 8:45 PM PST. diff --git a/devblog/2022-04-05-app-version-401.mdx b/devblog/2022-04-05-app-version-401.mdx deleted file mode 100644 index a36bc05cd..000000000 --- a/devblog/2022-04-05-app-version-401.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: App Version 4.0.1 -date: 2022-04-05 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Require Seed Words to Sign Out - -Requires users to enter their 12 word seed phrase in order to sign out to prevent accidental sign -outs. Thanks to our community Mentor for writing this request! - - - -# Maker Updates - -## Hotspot Onboarding with Bobber App - -Updates Bobcat Onboarding experience to choose between proceeding with current app or downloading -Bobber app. diff --git a/devblog/2022-04-05-firmware-release.mdx b/devblog/2022-04-05-firmware-release.mdx deleted file mode 100644 index 2d282c058..000000000 --- a/devblog/2022-04-05-firmware-release.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: RAK to manage RAK/MNTD Hotspots' -date: 2022-04-06 -hide_table_of_contents: true -authors: [jaykickliter] ---- - -The Nova developers have tagged a new `2022.04.05.0` firmware release for Original Helium and -RAK/MNTD Hotspots. - - - -This is release instructs RAK/MNTD Hotspots to check RAK's OTA server for new images. Original -Helium Hotspots will continue to download their firmware updates from Nova's OTA server. - -Once a RAK/MNTD Hotspot downloads and runs this firmware image, it will be managed and supported by -RAK. No action is required by Hotspot owners. - -### Plan - -We have been testing `2022.04.05.0` since Apr 1, 2022 1:30 PM PST. Current ETA for GA is Apr 6, 2022 -11:00 AM PST. diff --git a/devblog/2022-04-07-console-updates-2.2.6.mdx b/devblog/2022-04-07-console-updates-2.2.6.mdx deleted file mode 100644 index 19ac9f4a3..000000000 --- a/devblog/2022-04-07-console-updates-2.2.6.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.6 -date: 2022-04-07 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 73 - -The core team has released Console `v2.2.6` to production. A number of updates in this sprint -including increasing number of packets for multi-buy, clearer messaging for unsuccessful -integrations, and a pre-built Integration with Microsoft Azure IoT Central, instructions here: -https://docs.helium.com/use-the-network/console/integrations/azure/ - - - -**Important**: The Multiple Packet feature has been updated to accurately reflect the amount -specified by user configuration regardless if they're uplinks or initial joins. - -Full list of this sprint’s implemented features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/11?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/11?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Note for existing users: With the 04/07 update to increase number of packets for Multiple Packets, -the All option for users was updated to 10. - -If current users had previously chosen All, you can: - -- ask users to update on UI instructions - [here](https://docs.helium.com/use-the-network/console/multi-packets/), or -- run `UPDATE multi_buys SET value = 21 WHERE value = 10 AND updated_at < @YOUR_RELEASE_DATE;` where - `YOUR_RELEASE_DATE` is the date you deployed latest changes. - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- Preferred Hotspot selection -- State Channel v3 planning -- Rx delay enhancement diff --git a/devblog/2022-04-14-firmware-release.mdx b/devblog/2022-04-14-firmware-release.mdx deleted file mode 100644 index 5be7ec3c5..000000000 --- a/devblog/2022-04-14-firmware-release.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Operational Improvements' -date: 2022-04-14 -hide_table_of_contents: true -authors: [jaykickliter] ---- - -The Nova developers have tagged a new `2022.04.14.0` firmware release for Original Helium Hotspots. -This minor release increases the interval a Hotspot checks for a new `miner` container from 4 hours -(6 times a day) to 24 hours (once per day). - - - -### Plan - -We have been testing `2022.04.14.0` since Apr 14, 2022 11:00 AM PT. Current ETA for GA is Apr 14, -2022 1:00 PM PT. diff --git a/devblog/2022-04-19-miner-light-hotspot.mdx b/devblog/2022-04-19-miner-light-hotspot.mdx deleted file mode 100644 index 67c3ae76b..000000000 --- a/devblog/2022-04-19-miner-light-hotspot.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: post -title: 'Miner Release: Golden Build for Light Hotspot Activation' -date: 2022-04-19 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.04.19.0` `miner` release. This release is **mandatory** -for all Hotspot Makers. We request that Hotspot Manufacturers upgrade their fleets by 00:00 UTC on -2022-05-03. This update contains Light Hotspot software, and when activated via chain variable on -May 3 2022, will change how Hotspots receive challenges, remove block sync from Hotspots, and -stabilize Hotspot performance. This will allow the approved -[HIP 55](https://github.com/helium/HIP/blob/main/0055-validator-challenges.md) chain variable to be -activated and prepare for the activation of Light Hotspots. - - - -#### Related PRs - -- [core#1002](https://github.com/helium/blockchain-core/pull/1002): POC support over grpc -- [sybil#14](https://github.com/helium/sibyl/pull/14): POC support over grpc -- [miner#1068](https://github.com/helium/miner/pull/1068): POC support over grpc -- [proto#84](https://github.com/helium/proto/pull/84): POC support over grpc - -### Plan - -We have been testing `2022.04.19.0` on Testnet since April 14. Current ETA for GA is April 19, 2022 -1:10 PM PT. diff --git a/devblog/2022-04-21-console-updates-2.2.7.mdx b/devblog/2022-04-21-console-updates-2.2.7.mdx deleted file mode 100644 index 54a873aeb..000000000 --- a/devblog/2022-04-21-console-updates-2.2.7.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.7 -date: 2022-04-21 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 74 - -The team has released the latest version of Console `2.2.7` to production. Changes include MQTT -connection overflow fixes, as well as usability and open source updates, for example payment -processor Stripe is available to open source users, and new environment variables have been added to -the `.env` template file. - - - -Full list of this sprint’s implemented features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/12?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/12?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -_Important for existing users_: This version includes a mandatory update needed to support Light -Hotspot activation planned for 05/03. Users are highly recommended to update Console/Router to the -newest version without delay so they have the latest blockchain core update to ensure smooth -operations. - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Benchmarking to provide guidance for open source users -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- Preferred Hotspot selection -- XOR filter size reduction -- LoRaWAN library -- Rx delay enhancement diff --git a/devblog/2022-04-27-miner-light-hotspot.mdx b/devblog/2022-04-27-miner-light-hotspot.mdx deleted file mode 100644 index 9ee15c604..000000000 --- a/devblog/2022-04-27-miner-light-hotspot.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: post -title: 'Miner Release: Updated Golden Build for Light Hotspot Activation' -date: 2022-04-28 -hide_table_of_contents: true -authors: [jdgemm, cokes518] ---- - -The core developers have tagged a new `2022.04.27.0` `miner` release. This release is **mandatory** -for all Hotspot Makers. - - - -We request that Hotspot Manufacturers **upgrade their fleets by 00:00 UTC on 2022-05-11**. - -This update contains Light Hotspot software, and when activated via chain variable will change how -Hotspots receive challenges, remove block sync from Hotspots, and stabilize Hotspot performance. - -This will allow the approved -[HIP 55](https://github.com/helium/HIP/blob/main/0055-validator-challenges.md) chain variable to be -activated and prepare for the activation of Light Hotspots. - -#### Related PRs - -miner - -- [#1576](https://github.com/helium/miner/pull/1576) Fix rebase typos -- [#1575](https://github.com/helium/miner/pull/1575) Fix missing setting of udp_port in state record - (used only on restarts -- [#1574](https://github.com/helium/miner/pull/1574) Add audit var-127 -- [#1573](https://github.com/helium/miner/pull/1573) Deb: create data/log dirs, set helium user - homedir -- [#1566](https://github.com/helium/miner/pull/1566) Use env vars for common validator configs -- [#1564](https://github.com/helium/miner/pull/1564) Fix format error -- [#1567](https://github.com/helium/miner/pull/1567) Fix jsonrpc peer_refresh and add peer_book - count -- [#1572](https://github.com/helium/miner/pull/1572) Fix typos -- [#1568](https://github.com/helium/miner/pull/1568) Handling non-poc packets in light mode w/o rust - gw -- [#1562](https://github.com/helium/miner/pull/1562) Incorporate debian package enhancements -- [#1569](https://github.com/helium/miner/pull/1569) Bump deps - -blockchain - -- [#1315](https://github.com/helium/blockchain-core/pull/1315) Make filtering gateways cheaper -- [#1312](https://github.com/helium/blockchain-core/pull/1312) Verify poc key pair -- [#1314](https://github.com/helium/blockchain-core/pull/1314) Reduce logs -- [#1307](https://github.com/helium/blockchain-core/pull/1307) Remove dc-overage from challenger - rewards -- [#1308](https://github.com/helium/blockchain-core/pull/1308) Don't use context in a block absorb - hook - -### Plan - -We have been testing `2022.04.27.0` on Testnet since April 27. Current ETA for GA is April 28, 2022 -1:00 PM PST. diff --git a/devblog/2022-05-04-validator-lgw.mdx b/devblog/2022-05-04-validator-lgw.mdx deleted file mode 100644 index 0ac4ad3e5..000000000 --- a/devblog/2022-05-04-validator-lgw.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -layout: post -title: 'Light Hotspot Impact on Validator Traffic' -date: 2022-05-04 -hide_table_of_contents: true -authors: [jdgemm] ---- - -With HIP 55 the community approved increasing the scope of work and rewards for Validators. This -document includes preliminary estimates to help provide further insight into the changes Light -Hotspots have on Validator traffic. - - - -The core developers have tagged a new `1.9.1` release. This release is **mandatory** for all -Validators. To earn additional Challenge rewards, Validator Operators must upgrade to 1.9.1 **AND** -open port 8080. - -We request Validator Operators **upgrade by 00:00 UTC on 2022-05-11**. - -This will allow the approved -[HIP 55](https://github.com/helium/HIP/blob/main/0055-validator-challenges.md) chain variable to be -activated and prepare for the activation of Light Hotspots. - -#### Background - -Upon activation, Light Hotspots are no longer full blockchain nodes and the work plus the rewards of -issuing Proof-of-Coverage Challenges are transferred to Validators. For more information about Light -Hotspots check the -[blog](https://blog.helium.com/light-hotspots-explained-everything-you-need-to-know-f86612f571c6). - -Light Hotspots will allow the network to operate more smoothly and continue to scale for Hotspot -owners as Light Hotspot activation removes the need to sync or relay to stay updated with the Helium -Blockchain. - -From HIP 55: - -"Validator Challenges move the role of generating Challenges to the Validator pool. This not only -allows us to free Hotspots from the burden of following the blockchain but it also moves the -entities initiating Challenges to machines with much more stable and predictable networking which -reduces the likelihood of connectivity failures. Hotspots can become clients of Validators to learn -about blockchain updates in general, whether or not they're currently being challenged, and where to -deliver Witness receipts." - -For more information about HIP 55 visit here: -https://github.com/helium/HIP/blob/main/0055-validator-challenges.md - -#### Light Hotspot impact on Validator network traffic - -The team has provided these estimates to help provide further insight into the changes Light -Hotspots have on Validator traffic. - -**Note** these are mathematically derived preliminary estimates which the core team will update with -additional data as it becomes available. - -Block sizes used in these estimates include the following: - -- Non-reward block size = ~600kb -- Rewards block = ~2000kb -- Overall average block size (assuming 32 block epoch) = ~645kb - -Validator network traffic types: - -- Block Gossip: the entire blockchain or more likely verified snapshots are “gossiped” (shared) to - every blockchain node over a peer-to-peer network. As the blockchain becomes bigger, and the - number of nodes increases more resources are needed to share snapshots among peers. Light Hotspots - are no longer blockchain nodes and so the number of nodes to gossip snapshots is reduced to - Validators. - -- Location Gossip: Blockchain nodes routinely gossip the p2p address-to-ip address translation - entries stored in their local p2p peerbooks to other nodes. While peerbook entry gossip is - significantly smaller than Block Gossip, Validator peerbooks can grow into several hundred - thousand entries and the vast majority of the current network nodes (miners) change addresses - semi-frequently, requiring a re-gossip. Light Hotspots don't appear in the peerbook or gossip - their locations over the p2p network so the absolute possible size of the peerbook will shrink to - less than 5K after activation. - -- PoC Challenges (only applies to Light Hotspots): Upon activation, these Challenges are issued by - Validators to Light Hotspot Challengees and sent over gRPC vs the peer-to-peer network. Similar to - the original design, Challengees will transmit the Challenge packet and Light Hotspots “hearing” - the Challenge will serve as Witnesses. However, instead of submitting their Challengee recipients - and Witness reports to peer Hotpots, Light Hotspots will submit them via gRPC to the Validator - that issued the Challenge via lookup information provided by their connected Validator. - -#### Before Light Hotspots - -The amount of network traffic Validators handles is estimated at approximately 31 - 32 GB per day. -This includes traffic required for block gossip and location gossip. - -#### After Light Hotspots - -After Light Hotspot activation, the amount of network traffic drops to approximately 3.5 to 4 GB per -day. - -Validator network traffic still includes Block and Location gossip, but also adds Proof-of-Concept -(PoC) traffic. - -However, with Light Hotspot activation Block gossip lowers the maximum gossip limit to 4 from 32 and -the number of locations to gossip from over 700K to less than 5K. In addition, Validators, ETLs, and -others change location much less frequently and require fewer updates. - -For the new PoC traffic, assuming approximately 150 Light Hotspots per Validator on average running -a PoC Challenge approximately every 4 blocks one of them will be challenged, and challenges -currently last 20 blocks. - -Using 5 blocks at a time at any given moment, conservatively estimate 100kb per PoC works out to -120kb per minute or .17GB per day - -#### Validator Traffic Summary - -Here’s a summary of Validator network traffic before and after Light Hotspots. - -| | Before | After | -| :----------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | -| Block gossip (averaging 1 block per minute \* the number of connections) | Overall average block size \* 32 (max gossip limit) = --- approx. 30GB/day | Overall average block size \* 4 (new max gossip limit, just validators) --- approx. 3.5GB/day | -| Location gossip | Unclear, but using ~700k locations to potentially gossip (although confident not often gossiped). | Unclear, but gossip universe has reduced to less than 5K entities (majority Validators), so even with 100% saturation this number will be significantly smaller. Also, Validators, ETLs and etc change less often so fewer updates are required. | -| PoC cost | N/A | Approximately 150 Light Hotspots per Validator on average running a PoC Challenge every 4 blocks. --- Using 4 blocks at a time at any given moment, conservatively estimate 100kb per PoC. --- 100kb per minute or .15GB per day | -| Total estimated traffic | 31 - 32 GB/day | 3.5 - 4 GB/day | diff --git a/devblog/2022-05-05-console-updates-2.2.8.mdx b/devblog/2022-05-05-console-updates-2.2.8.mdx deleted file mode 100644 index 0ccc7cec1..000000000 --- a/devblog/2022-05-05-console-updates-2.2.8.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.8 -date: 2022-05-05 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 75 - -The core team has released the latest version of Console 2.2.8 to production. Changes include -merging the code for XOR filter fee reduction, however it has not been activated as the vote is -still ongoing. For more information check the -[HIP](https://github.com/helium/HIP/blob/main/0059-reduce-xor-filter-fees.md). - - - -In addition, the ability for the backend to detect “bad actors” (Hotspots that don’t send packets) -was included and the team improved usability for the Console Export feature, and added a memo field -for Data Credit receipts. - -Full list of this sprint’s implemented features and fixes: - -- Backend [(Router)](https://github.com/helium/router/milestone/13?closed=1) -- Frontend [(Console)](https://github.com/helium/console/milestone/13?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- Preferred Hotspot -- LoRaWAN library -- Rx delay enhancement diff --git a/devblog/2022-05-10-miner-firmware-hotspot-release.mdx b/devblog/2022-05-10-miner-firmware-hotspot-release.mdx deleted file mode 100644 index 3da63c0a1..000000000 --- a/devblog/2022-05-10-miner-firmware-hotspot-release.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: 'Miner Release: Additional Fixes for Light Hotspots' -date: 2022-05-10 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.05.10.0` `miner` release. This release is **highly -recommended** for all Hotspot Makers. - - - -We request that Hotspot Manufacturers **upgrade their fleets ASAP**. - -This update contains performance fixes to Hotspots as Light Hotspots are activated, specifically -adding additional seed Validators to reduce load on the Validator fleet. This also ensures that -Challenges with zero receipts are excluded from reward calculations. - -#### Related PRs - -- [#1578](https://github.com/helium/miner/pull/1578) Add correct gain measurement to region update - responses requested by miners from validators when no longer following the chain in light mode -- [#1592](https://github.com/helium/miner/pull/1592) Add new seed validators to embedded rust light - gateway's default config (gateway-rs update) -- [#1584](https://github.com/helium/miner/pull/1584) Skip 0 response receipt txns from rewards - calculation -- [#1579](https://github.com/helium/miner/pull/1579) Select correct packet routing module for - downlink packets when miner running in light mode - -### Plan - -We have been testing `2022.05.10.0` on Mainnet since May 10 11:30am PT. Current ETA for GA is May -10, 2022 1:00 PM PT. diff --git a/devblog/2022-05-11-miner-hotspot-release.mdx b/devblog/2022-05-11-miner-hotspot-release.mdx deleted file mode 100644 index 95d6cc6be..000000000 --- a/devblog/2022-05-11-miner-hotspot-release.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: 'Miner Release: Fixes for Snapshot Loading' -date: 2022-05-11 -hide_table_of_contents: true -authors: [cokes518, vihu] ---- - -The core developers have tagged a new `2022.05.11.0` `miner` release. This release is **highly -recommended** for all Hotspot Makers. - - - -This update contains a fix to snapshot loading now that Light Hotspots are live, adds better logging -for Proof-of-Coverage, and adds missing seed validators to config. - -#### Related PRs - -- [#1600](https://github.com/helium/miner/pull/1600) Don’t propose old request transactions if - challenger validators are enabled -- [#1340](https://github.com/helium/blockchain-core/pull/1340) Fixes snapshot by including - validator_count -- [#1598](https://github.com/helium/miner/pull/1598) Adds missing seed validators to config -- [#1602](https://github.com/helium/miner/pull/1602) Adds additional logging -- [#1603](https://github.com/helium/miner/pull/1603) Fixes gRPC typo - -### Plan - -We have been testing `2022.05.11.0` on Mainnet since May 11 3:00pm PT. Current ETA for GA is May 11, -2022 5:30 PM PT. diff --git a/devblog/2022-05-12-app-version-402.mdx b/devblog/2022-05-12-app-version-402.mdx deleted file mode 100644 index 517a24920..000000000 --- a/devblog/2022-05-12-app-version-402.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: App Version 4.0.2 -date: 2022-05-12 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Bug Fixes - -This update is to fix a few bugs found since the last release. The next release will address changes -for Light Hotspots. - - - -## Fixes sign out for Deploy Mode - -Addresses a display bug for seed phrase when in Deploy Mode. - -## Updates Witness days from 5 to 3 - -The Witness List looks at the last 3 days of Proof-of-Coverage receipts, not 5 anymore. diff --git a/devblog/2022-05-12-miner-hotspot-release.mdx b/devblog/2022-05-12-miner-hotspot-release.mdx deleted file mode 100644 index 97809874e..000000000 --- a/devblog/2022-05-12-miner-hotspot-release.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: 'Miner Release: Add Retry Delay for PoC Receipts' -date: 2022-05-12 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.05.12.0` `miner` release. This release is **highly -recommended** for all Hotspot Makers. - - - -This update adds a retry delay when sending PoC Witness Receipts (from a Hotspot to a Validator) so -that it has a better chance of succeeding if the Validator falls behind a few blocks from the tip of -the chain. - -#### Related PRs - -[#1608](https://github.com/helium/miner/pull/1608) Add a delay between resending PoC receipts to -allow Validators to catch up to the tip of the blockchain - -### Plan - -We have been testing `2022.05.12.0` on Mainnet since May 12 3:50pm PT. Current ETA for GA is May 12, -2022 5:50 PM PT. diff --git a/devblog/2022-05-13-miner-hotspot-release.mdx b/devblog/2022-05-13-miner-hotspot-release.mdx deleted file mode 100644 index 51da3763e..000000000 --- a/devblog/2022-05-13-miner-hotspot-release.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: 'Miner Release: Hotspot Reconnection Logic' -date: 2022-05-13 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.05.13.0` `miner` release. This release is **highly -recommended** for all Hotspot Makers. - - - -This update allows Hotspots to disconnect from a poorly performing Validator and search for a new -one if the connected validator is not keeping up with the chain for 15 blocks (approximately 15 -minutes). - -#### Related PRs - -[#1625](https://github.com/helium/miner/pull/1625) Let Hotspots disconnect from a poorly performing -validator and search for a new one. - -### Plan - -We have been testing `2022.05.13.0` on Mainnet since May 12 2:40pm PT. Current ETA for GA is May 13, -2022 3:15 PM PT. diff --git a/devblog/2022-05-17-app-version-410.mdx b/devblog/2022-05-17-app-version-410.mdx deleted file mode 100644 index ecca10376..000000000 --- a/devblog/2022-05-17-app-version-410.mdx +++ /dev/null @@ -1,14 +0,0 @@ ---- -layout: post -title: App Version 4.1.0 -date: 2022-05-17 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# Light Hotspot Support - -This update adds Light Hotspot support to the app, specifically for Transferring Hotspots and -removes pre-Light Hotspot terminology from Hotspot details and Diagnostic Reports. diff --git a/devblog/2022-05-19-console-updates-2.2.9.mdx b/devblog/2022-05-19-console-updates-2.2.9.mdx deleted file mode 100644 index 041ca896d..000000000 --- a/devblog/2022-05-19-console-updates-2.2.9.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.9 -date: 2022-05-19 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 76 - -Despite all the excitement the team has released the latest version of Console `2.2.9` to -production. - - - -Key updates include: Preferred Hotspot, setting region for downlinks to improve stability, and the -initial phase for Console Marketplace (Integrations). - -- Preferred Hotspots [docs](https://docs.helium.com/use-the-network/console/multi-packets/) -- Marketplace [docs](https://docs.helium.com/use-the-network/console-marketplace) - -Full list of this sprint’s features and fixes: - -- Backend (Router): https://github.com/helium/console/milestone/14?closed=1 -- Frontend (Console): https://github.com/helium/router/milestone/14?closed=1 - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open-source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Additional regional support -- Community Marketplace - decoders -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- LoRaWAN library -- Rx delay enhancement diff --git a/devblog/2022-05-19-miner-hotspot-release.mdx b/devblog/2022-05-19-miner-hotspot-release.mdx deleted file mode 100644 index f35f5232f..000000000 --- a/devblog/2022-05-19-miner-hotspot-release.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -layout: post -title: 'Miner Release: Improve Proof-of-Coverage Retries' -date: 2022-05-19 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.05.19.0` `miner` release. This release is **highly -recommended** for all Hotspot Makers. - - - -This update improves proof-of-coverage retries when a Hotspot receives a request. - -#### Related PRs - -[#1654](https://github.com/helium/miner/pull/1654) Improve proof-of-coverage retries - -### Plan - -We have been testing `2022.05.19.0` on Mainnet since May 18 3:00pm PT. Current ETA for GA is May 19, -2022 9:00am PT. diff --git a/devblog/2022-05-24-miner-hotspot-release.mdx b/devblog/2022-05-24-miner-hotspot-release.mdx deleted file mode 100644 index 83aec474b..000000000 --- a/devblog/2022-05-24-miner-hotspot-release.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -layout: post -title: 'Miner Release: Fix HTTP2 Client and Chain Var support for PoC' -date: 2022-05-24 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.05.24.0` `miner` release. This release is **mandatory** -for all Hotspot Makers. Contained in this release are chain variables to support Validator -Performance (to be activated some time after May 25 9:00AM PT). Failure to update your fleet before -the chain variables are activated will cause the Hotspot to stop functioning as Hotspots still -follow the blockchain. - - - -This release also adds a timeout on gen_tcp connect on the HTTP2 client and monitors the connection -to restart on unexpected disconnects. - -#### Related PRs - -[HTTP2 Fix](https://github.com/helium/http2_client/commit/45163af5399cede1c1210ea665a4532d1a67eca3) -Fix HTTP2 client timeout [#1359](https://github.com/helium/blockchain-core/pull/1359) bypass of -witness validation with chain variable `poc_receipt_witness_validation` -[#1358](https://github.com/helium/blockchain-core/pull/1358) Always process gw reactivation list -with chain variable `poc_always_process_reactivations` - -### Plan - -We have been testing `2022.05.24.0` on Mainnet and Testnet since May 24 12:00pm PT. Current ETA for -GA is May 24, 2022 2:00pm PT. diff --git a/devblog/2022-06-01-miner-hotspot-release.mdx b/devblog/2022-06-01-miner-hotspot-release.mdx deleted file mode 100644 index 463e0a1ea..000000000 --- a/devblog/2022-06-01-miner-hotspot-release.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: post -title: 'Miner Release: Additional PoC Improvements and Enabling Mux' -date: 2022-06-01 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.06.01.0` `miner` release. This release is **mandatory** -for all Hotspot Makers. Contained in this release are further improvements to the flatline issue -(fixes HTTP2) and enables mux. Enabling mux allows all data packet traffic to be routed through -gateway-rs and away from the erlang miner. This is a key step towards removing Erlang from Hotspots -altogether. - - - -This release also fixes PoC timing and lets a Hotspot retry PoC if a Validator falls behind and -catches back up quickly. This release also decreases the amount of time before a Hotspot selects a -different durable Validator if the first Validator is behind on blocks (from 15 blocks to 10 -blocks). - -#### Related PRs - -[#1707](https://github.com/helium/miner/pull/1707) Reduce invalid block age threshold -[#1705](https://github.com/helium/miner/pull/1705) stream related grpc client fixes (HTTP2 fix) -[#1616](https://github.com/helium/miner/pull/1616) enable mux/embedded light gateway -[#1689](https://github.com/helium/miner/pull/1689) allow check target reqs to be retried full -duration of a POC - -### Plan - -We have been testing `2022.06.01.0` on Mainnet and Testnet since May 31 12:00pm PT. Current ETA for -GA is June 1, 2022 1:30pm PT. diff --git a/devblog/2022-06-02-console-updates-2.2.10.mdx b/devblog/2022-06-02-console-updates-2.2.10.mdx deleted file mode 100644 index c1f95646e..000000000 --- a/devblog/2022-06-02-console-updates-2.2.10.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.10 -date: 2022-06-02 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 77 - -The team has released the latest version of Console `2.2.10` to production. - - - -Key updates: additional support for following regional frequencies: KR920, EU433, and IN865. - -Full list of this sprint’s features and fixes: - -- Backend [(Router)](https://github.com/helium/console/milestone/15?closed=1) -- Frontend [(Console)](https://github.com/helium/router/milestone/15?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open-source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml` file - an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Community Marketplace - decoders -- Customization for hosting providers -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- LoRaWAN library diff --git a/devblog/2022-06-02-emergency-miner-hotspot-release.mdx b/devblog/2022-06-02-emergency-miner-hotspot-release.mdx deleted file mode 100644 index 26981e659..000000000 --- a/devblog/2022-06-02-emergency-miner-hotspot-release.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: post -title: 'Miner Release: Emergency Fix for Genesis Load Crash and Disable Mux' -date: 2022-06-02 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.06.02.1` `miner` release. This is an emergency release -to address issues found in `2022.06.01.0`. A new dependency was introduced related to telemetry work -that wasn't properly configured for the release process. - - - -As the Hotspot boots up, it tries to look for a dependency that doesn't exist, causing crashes on a -subset of Hotspots where "fast sync"-like features are used and causes crashes on brand new Hotspots -just added to the blockchain. - -This release also disables the mux as the team has identified an issue with routing packets. Mux -will be re-enabled in the next release with the bug fix. - -#### Related PRs - -[#1712](https://github.com/helium/miner/pull/1712) disable the mux to bypass an issue that requires -testing [#1375](https://github.com/helium/blockchain-core/pull/1375) include telemetry in app src - -### Plan - -We have been testing `2022.06.02.1` on Mainnet and Testnet since June 2 8:20am PT. Current ETA for -GA is June 2, 2022 9:00am PT. diff --git a/devblog/2022-06-10-miner-hotspot-release.mdx b/devblog/2022-06-10-miner-hotspot-release.mdx deleted file mode 100644 index 295f91aa5..000000000 --- a/devblog/2022-06-10-miner-hotspot-release.mdx +++ /dev/null @@ -1,133 +0,0 @@ ---- -layout: post -title: 'Miner Release: Flatline Fix and Prepare to Disable Chain Sync' -date: 2022-06-10 -hide_table_of_contents: true -authors: [cokes518, ke6jjj, abhay] ---- - -The core developers have tagged a new `2022.06.09.0` `miner` release. This release contains fixes to -the packet issue identified in the last release by bumping the gateway-rs version to `alpha-27`, -fixes a crash in ebus (more on this below), and a "flatline" fix (more on this below). - - - -  - -# Enabling Mux - -- Makers must enable mux explicitly in their docker overlay by adding - `{gateway_and_mux_enable, true}` to your configuration file under the miner application block - -# Summary of Flatline and Ebus fixes - -These two issues have been causing various crashes and out of memory errors on Hotspots that have -been preventing them from participating in network and potentially causing "flatline" reports in the -community. - -More details are below but the team has identified an issue where Hotspots were talking to both the -Mainnet and Testnet causing a Hotspot to run out of memory. Additionally, a Hotspot can crash due to -a latent bug in the bluetooth stack. Both of these issues have been fixed. - -## Ebus Crash - -The network is in the middle of transitioning from Full (chain syncing Hotspots running Erlang-based -miners) Hotspots to Light (no chain sync, running a rust-based gateway) Hotspots. In this middle -period, the Hotspot itself uses both erlang-based and rust-based components. The core team chose to -transition this way to avoid disruptions and ease the transition over a period of time. One of the -components that needs to transition over is called "ebus". - -### What is ebus? - -ebus is used to communicate to Manufacturer Hotspot mobile applications over Bluetooth to run -diagnostics and perform the initial onboarding. During onboarding and running diagnostic reports, -ebus asks for the Hotspot's block height so it can return that information (over Bluetooth) back to -the user. - -### Explaining the problem - -Before Light Hotspots, ebus would ask the erlang-based miner what the block height is and it would -return that information. However, now that Hotspots get their chain information from Validators -using a protocol called gRPC, ebus (still talking to the erlang-based miner) thinks there is no -block height at all, and crashes. - -The fix is to tell ebus to talk to the Validator using the new rust-based gateway using gRPC. - -## "Flatline" Fix - -The core team had been chasing down the flatline fix for a while and we're optimistic that this will -resolve the issue. - -### Some background on Seed Nodes and Peerbooks - -All Hotspots, when they first boot up and connect to the internet, connect to a seed node (think of -it like a directory of all Hotspots and Validators on the network). These seed nodes share a peer -book that provide routing information for the Hotspots (like directions to a store). - -There are both Testnet seed nodes and Mainnet seed nodes that exist, providing peer book information -to whichever Hotspot requests it. - -### Explaining the problem - -When Hotspots participate in Proof-of-Coverage, they often need to look up where to send the -receipt, so they ask a seed node. The problem arises when both Testnet and Mainnet seed nodes -respond. - -Some Hotspots are unable to untangle the mix of seed nodes responding back to them, filling up their -memory, and completely exhausting any available memory they have, causing a "flatline". - -The fix is to separate out the crosstalk and ensure only Mainnet seed nodes respond to a Mainnet -Hotspot. - -For a more technical explanation, see "Flatline: Detailed Discussion". - -#### Related PRs - -[#1390](https://github.com/helium/blockchain-core/pull/1390) Prevent Testnet and Mainnet crosstalk -that caused, on boot, the Hotspot miner to think its peer book database is in a legacy byte order -state and needs to be reconverted to reversed byte order. -[#439](https://github.com/helium/erlang-libp2p/pull/439) Fixes bug that caused memory issues in -peerbook [#1381](https://github.com/helium/blockchain-core/pull/1381) Fixes Poc Targeting and -Filtering [#1723](https://github.com/helium/miner/pull/1723) Fixes an ebus crash on miner as it -tries to get `block_height` and other ledger-related params. - -### Plan - -We have been testing `2022.06.09.0` on Mainnet since June 9 3pm PT. Current ETA for GA is June 10, -2022 12:00pm PT. - -### "Flatline": Detailed Discussion - -To participate in the network effectively, Hotspots must communicate with any one of several -Validators for various services. But to do so, the Hotspot must first obtain a directory listing, -also called a peer book, of all available Validators and Hotspots on the network. It obtains the -most up-to-date peer book by contacting any other Hotspot or Validator and asking for one. If a -Hotspot doesn't have any directory listing to begin with, it will contact any one of several special -Seed Nodes to download one. Once downloaded, a Hotspot will save its peer book to disk so that it -can avoid having to ask for a full peer book from a seed on reboot. As the Hotspot hears about -changes to the peer book it will update its local copy to keep it in sync. - -The format of the peer book disk database underwent a change long ago, and to accomodate that -change, Hotspots first attempt to check whether the peer book appears to be in the older or newer -format at start up. If the Hotspot believes its database format is of the older version, it attempts -to correct the database at start up by completely rewriting it. When this "upgrade" code was written -the peer book was so small that it could effectively have been loaded entirely into memory first -before being corrected. Nowadays, however, the database is so large that when the "upgrade" code -runs it exhausts all memory on the Hotspot, causing it to crash. Fortunately, the upgrade code -hasn't been needed for quite some time, so it rarely runs, and rarely causes the crash. - -Unfortunately, however, the upgrade code can be activated accidentally if there are unusual peer -book entries in the database. Some hotspots have unfortunately started collecting unusual entries in -their peer books due to a couple of additional problems that had been occuring with Seed Nodes, one -of which is that they had been delivering peer books filled with both mainnet and testnet Validator -and Hotspot addresses. Once a Hotspot receives and stores these unusual peer book entries, it can -get in a state such that it continuously tries to "upgrade" its peer book, over and over, at -startup. Since the upgrade itself causes a crash, the Hotspot cannot get itself out of this loop (in -the affected versions). - -The solution to the issue is several fold. - -1. Remove the "upgrade" code altogether. It simply isn't needed. -2. Prevent Seed Nodes from accumulating and propagating listings for peers outside their network - type (testnet vs mainnet). -3. Prevent Seed Nodes from accumulating and propogating _empty_ peer book listings. diff --git a/devblog/2022-06-17-console-updates-2.2.11.mdx b/devblog/2022-06-17-console-updates-2.2.11.mdx deleted file mode 100644 index ad5ddbb44..000000000 --- a/devblog/2022-06-17-console-updates-2.2.11.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.11 -date: 2022-06-17 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, abhay] ---- - -Sprint: 78 - -The team has released the latest version of Console `2.2.11` to production. - - - -Key updates: include more clarity for users upon sign up on the Helium Foundation Console, and -customization options for Console Providers. This release also includes updates for regional -frequencies AU915. - -In addition, the team has implemented mechanisms to detect and minimize abusive signup traffic. - -Full list of this sprint’s features and fixes: - -- Backend [(Router)](https://github.com/helium/console/milestone/16?closed=1) -- Frontend [(Console)](https://github.com/helium/router/milestone/16?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open-source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml`, and - file an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Docs for customization options -[here](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#customize-console-environment). -IMPORTANT: If you choose to customize your version of Console you need to build from source, or your -customizations will be overwritten by the docker image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Community Marketplace - decoder functions -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- LoRaWAN library diff --git a/devblog/2022-06-30-console-updates-2.2.12.mdx b/devblog/2022-06-30-console-updates-2.2.12.mdx deleted file mode 100644 index 48b2331ca..000000000 --- a/devblog/2022-06-30-console-updates-2.2.12.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.12 -date: 2022-06-30 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm, macpie] ---- - -Sprint: 79 - -The team has released the latest version of Console `2.2.12` to production. - - - -Key updates: - -The team has corrected a misspelling in one of the Cayenne Decoder Function payload fields: -`celcius` and included the correctly spelled payload field `celsius`. - -Before the next release, users need to update any dependent systems from the incorrect to correct -payload field to help ensure normal data transfer operations. - -Full list of this sprint’s features and fixes: - -- Backend [(Router)](https://github.com/helium/console/milestone/17?closed=1) -- Frontend [(Console)](https://github.com/helium/router/milestone/17?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- **REQUIRED** upgrade for Router as it includes a necessary Blockchain Core update. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open-source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml`, and - file an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Docs for customization options -[here](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#customize-console-environment). -IMPORTANT: If you choose to customize your version of Console you need to build from source, or your -customizations will be overwritten by the docker image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Community Marketplace - decoder functions -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- LoRaWAN library diff --git a/devblog/2022-06-30-wallet-version-1-1.mdx b/devblog/2022-06-30-wallet-version-1-1.mdx deleted file mode 100644 index 52f6f1790..000000000 --- a/devblog/2022-06-30-wallet-version-1-1.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: post -title: Helium Wallet v1.1 -date: 2022-06-30 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Ledger Payment Support - -Users that have imported their Ledger Nano S (Android Only) or Ledger Nano X can now send payments -from the app! Requires Ledger Helium App version 2.2.4. Update your Nano app using Ledger Live. - - - -## iOS Widget Support - -iOS users can now add the Wallet app widget to their home screen! From the Home Screen, touch and -hold a widget or an empty area until the apps jiggle. Tap the Add button. In the upper-left corner, -select a widget (search Helium), choose from three widget sizes, then tap Add Widget. - -Android support coming soon. - -# Bug Fixes - -## Crowdspot Fixes with Wallet Connect - -Users attempting to link their Helium Wallet with Crowdspot may have encountered some issues. This -release should fix this. - -## Helium Vote - -Fixed the way the app looks up data from heliumvote.com so the most recent voting results and time -left to vote are accurate. diff --git a/devblog/2022-07-11-network-disurption-post-mortem.mdx b/devblog/2022-07-11-network-disurption-post-mortem.mdx deleted file mode 100644 index 47a483293..000000000 --- a/devblog/2022-07-11-network-disurption-post-mortem.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: post -title: 'Network Disruption Postmortem: 2022-07-11' -date: 2022-07-11 17:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -  - -# What happened - -On Monday 2022-07-11 at approximately 12:42 PM UTC the Consensus Group stopped producing blocks at -block `1,435,692`. Normal chain operations continued at 17:15 PM UTC just over 4 hours later. - - - -Throughout the disruption, devices continued to have coverage to transfer data and operate normally -as state channels remained open processing packets. There were also no risks to Hotspot owners or -HNT holders, but they did experience a delay in transaction processing and Proof-of-Coverage -activity. - -# Cause - -A minimum of 29 of the 43 Consensus Group members must be online, connected to each other, and on -the same consensus round to produce blocks. - -This disruption was caused by a combination of factors including an issue with the `1.12.3` -validator beta build and a local network outage experienced by a number of validators in the -Consensus Group. - -# Recovery - -The core team worked with the Validator community to manually move relevant, online validators to -the same consensus round so they could become synchronized and resume normal operations. - -At 10:15 AM PST the Consensus Group continued block production with `1,435,693`. - -# Resolution - -The root cause of the 1.12.3 issue was identified and fix was released with the latest `1.12.4` GA -validator build that is currently available. - -To avoid this type of situation, there is an auto-skip feature that enables validators to move to a -different consensus round without manual intervention. However, a known issue prevented the -auto-skip feature from working as expected. - -This issue along with additional performance improvements are planned for the next validator -release. - -# Power of Community - -Thank you once again to our community members that host validators. We deeply appreciate both your -timeliness and willingness to troublehsoot issues that affect the entire network. diff --git a/devblog/2022-07-14-console-updates-2.2.13.mdx b/devblog/2022-07-14-console-updates-2.2.13.mdx deleted file mode 100644 index 06b1d9f70..000000000 --- a/devblog/2022-07-14-console-updates-2.2.13.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.13 -date: 2022-07-14 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -Sprint: 80 - -The team has released the latest version of Console `2.2.13` to production. - - - -Key updates: This release provides users tha ability to decode base64 payloads without needing to -use a decoder -([docs](https://docs.helium.com/use-the-network/console/integrations/http/#decoding-base64-payloads)), -support for Malaysia (AS923_1B defines uplink frequencies at 922.0, 922.2, 922.4, 922.6, 922.8, -923.0, 923.2, 923.4), and additional benchmarking information for users who want to those their own -Console. Among UI enhancements made, the dropdown menu was expanded to see up to 250 devices for a -label. - -Full list of this sprint’s features and fixes: - -- Frontend [(Console)](https://github.com/helium/console/milestone/18?closed=1) -- Backend [(Router)](https://github.com/helium/router/milestone/18?closed=1) - -(Note: a closed issue does not mean the team took action, for example the issue could have been a -duplicate or no longer relevant). - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- **REQUIRED** upgrade for Router as it includes a necessary Blockchain Core update. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open-source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml`, and - file an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Docs for customization options -[here](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#customize-console-environment). -IMPORTANT: If you choose to customize your version of Console you need to build from source, or your -customizations will be overwritten by the docker image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Improving network scalability -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- LoRaWAN library diff --git a/devblog/2022-07-14-miner-hotspot-release.mdx b/devblog/2022-07-14-miner-hotspot-release.mdx deleted file mode 100644 index daa79ef3d..000000000 --- a/devblog/2022-07-14-miner-hotspot-release.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -layout: post -title: 'Miner Release: Turning off Chain Sync and Enabling MUX' -date: 2022-07-14 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.07.14.0` `miner` release. This release contains fixes to -packet delivery to make it more reliable when Hotspots fall offline for a brief period of time (it -will queue up to 10 device packets it saw) and fixes to let Hotspots send unknown packets if it's -not synced with the blockchain. - - - -This release also contains fixes that will allow Hotspots to transfer packets using the Light -Hotspot firmware code (or gateway-rs) and allows for individual Makers to turn off blockchain sync -for their Hotspot fleets. See directions below on how to enable mux and turn off chain sync. - -Hotspots can expect to make 3 connections to a Validator when mux is enabled (one for PoC, one for -packets, and one for activity). - -  - -# Enabling Mux - -- Makers must enable mux explicitly in their docker overlay by adding - `{gateway_and_mux_enable, true}` to your configuration file under the `miner` application block - -# Turn off Blockchain Sync - -- Makers must turn off chain sync explicitly in their docker overlay by adding - `{gateways_run_chain, false}` to your configuration file under the `miner` application block - -## Known Issues - -Some Hotspot owners may have issues running diagnostic reports over Bluetooth. This is likely due to -services that the `miner` provides, and if chain sync is off, some of those services may not be -available to support Bluetooth services, like diagnostic reports. - -#### Related PRs - -[#1407](https://github.com/helium/blockchain-core/pull/1407) SC Client Updates - -### Plan - -We have been testing `2022.07.14.0` on Mainnet since July 12 5pm PT. Current ETA for GA is July 14, -2022 4:00pm PT. diff --git a/devblog/2022-07-19-firmware-release.mdx b/devblog/2022-07-19-firmware-release.mdx deleted file mode 100644 index 2f317d9b8..000000000 --- a/devblog/2022-07-19-firmware-release.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Enable Mux and Disable Chain Sync' -date: 2022-07-19 -hide_table_of_contents: true -authors: [cokes518] ---- - -The Nova developers have tagged a new `2022.07.15.0` firmware release for Original Helium Hotspots. -This minor release enables mux and disables blockchain sync. Enabling mux allows the transferring of -packets to use the Light Hotspot part of the codebase and is a further step forward in the Light -Hotspot transition. - - - -### Plan - -We have been testing `2022.07.15.0` since July 15, 2022 11:00 AM PT. Current ETA for GA is July 19, -2022 1:00 PM PT. diff --git a/devblog/2022-07-28-console-updates-2.2.17.mdx b/devblog/2022-07-28-console-updates-2.2.17.mdx deleted file mode 100644 index 442d46cb4..000000000 --- a/devblog/2022-07-28-console-updates-2.2.17.mdx +++ /dev/null @@ -1,72 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.17 -date: 2022-07-28 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The team has released the latest version of Console `2.2.17` to production. This release includes a -rollup of out of band releases: - - - -#### Fix HTTP Integration Header - -The core team has identified an issue with HTTP Integration headers that was introduced with the -latest release v2.2.13. - -When Console sends the data over an HTTP Integration that includes headers and specific syntax -(period followed by number) it indexed the keys. - -#### Update GRPC component - -The core team identified an issue with the grpcbox component and released v2.2.15 to address it. -This issue is significant because with the latest miner release all Hotspot connections to Console -use GRPC after Hotspot manufacturers have enabled mux. - -#### Update blockchain core - -The latest release includes an updated blockchain core to fix a recent issue discovered on the -MOBILE Testnet and it improves packet transfer speed from Hotspots. - -Prior to this update packet transfer required an additional communication layer from Hotspots to -Console before device packets were sent. These extra hops added delays and could impact reliability -depending on the state of the Hotspot. - -Hotspots with the latest firmware simply send packets directly to Console improving transfer speed -and reliability. - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- **REQUIRED** upgrade for Router as it includes a necessary Blockchain Core update. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open-source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml`, and - file an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Docs for customization options -[here](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#customize-console-environment). -IMPORTANT: If you choose to customize your version of Console you need to build from source, or your -customizations will be overwritten by the docker image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Improving network scalability -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- LoRaWAN library diff --git a/devblog/2022-07-28-miner-hotspot-release.mdx b/devblog/2022-07-28-miner-hotspot-release.mdx deleted file mode 100644 index d3aff0c78..000000000 --- a/devblog/2022-07-28-miner-hotspot-release.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: post -title: 'Miner Release: Improvements to Packet Transfer' -date: 2022-08-02 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.08.02.0` `miner` release. This release contains -improvements to packet delivery such that when a Hotspot sees a packet, it sends the payload right -away to the Router (and thus, recipient) immediately. Data transfer reliability is expected to -improve with this release. - - - -#### Related PRs - -[#271](https://github.com/helium/gateway-rs/pull/271) send packets as quickly as possible -[#280](https://github.com/helium/gateway-rs/pull/280) If we have an existing connection, absorb the -updates - -### Plan - -We have been testing `2022.08.02.0` on Mainnet since August 2 11am PT. Current ETA for GA is August -2, 2022 2:00pm PT. diff --git a/devblog/2022-08-04-console-updates-2.2.20.mdx b/devblog/2022-08-04-console-updates-2.2.20.mdx deleted file mode 100644 index 165a5891f..000000000 --- a/devblog/2022-08-04-console-updates-2.2.20.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -layout: post -title: Console Updates- v2.2.20 -date: 2022-08-04 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The team has released the latest version of Console `2.2.20` to production. This release includes a -rollup of a number of updates: - - - -#### v2.2.20 - -This update fixes out of order uplinks that occur when Hotspots are very slow to deliver data. This -Hotspot delay could be caused by extreme latency or local power or network outages. - -#### v2.2.19 - -Key updates include: connectivity updates with grpc, upgrading the LoRaWAN library, and addressing -an issue to allow dual plan support in Australia. - -#### v2.2.18 - -Addresses a serious issue related to device joins and the upcoming Hotspot release planned for early -next week. Without this update devices may experience issues attempting to join. - -### Open source users - -Check the [readme](https://github.com/helium/console) for instructions on how to use prebuilt -Console images. - -- **REQUIRED** upgrade for Router as it includes a necessary Blockchain Core update. - -- New open source users should follow Option 1 listed in the readme and use - `docker-compose-quay.yaml` as the template for their docker-compose file. - -- Existing open-source users can update their existing docker-compose file and replace the lines for - just the "console" section with the updated lines in the latest `docker-compose-quay.yaml` file. - If something does not work, simply revert your changes back to the `docker-compose-quay.yaml`, and - file an issue [here](https://github.com/helium/console/issues). - -Database migrations will still happen automatically when using the hosted Console image. - -Docs for customization options -[here](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#customize-console-environment). -IMPORTANT: If you choose to customize your version of Console you need to build from source, or your -customizations will be overwritten by the docker image. - -Additional -[technical documentation](https://docs.helium.com/use-the-network/run-a-network-server/run-console/#console-setup). - -### Upcoming - -The team’s focus in the coming weeks (usual disclaimers apply): - -- Improving network scalability -- Scaling out roaming services -- [LoRaWAN roaming protocol support](https://lora-alliance.org/wp-content/uploads/2022/01/TR010-1.0.0-LoRaWAN-Roaming-Hub.pdf) -- LoRaWAN library diff --git a/devblog/2022-08-04-network.mdx b/devblog/2022-08-04-network.mdx deleted file mode 100644 index 38591ac90..000000000 --- a/devblog/2022-08-04-network.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: post -title: Network Reliability is King -date: 2022-08-04 14:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -The team is prioritizing its focus on issues to improve network reliability. Any new features or -enhancement requests, while appreciated, will be added to our backlog and prioritized accordingly. - - - -Rather than the usual sprint cadence of scheduled releases, updates that help stabilize the network -will be released immediately. - -This accelerated release schedule will not impact users of hosted Console offerings by Helium -Foundation or Nova Labs, but open source users will need to upgrade on a more frequent cadence. - -Just a reminder, Console is part of a system with multiple components, and certain issues will -require updates to both Hotspots (gateway-rs) and the backend (Router). Hotspot firmware updates -require the team to work with manufacturers to deploy. - -The real-world application of this network is paramount and what differentiates this project from -99.9% of other decentralized projects. Confidence for users of the network is critical for its -success and is a top priority for the team. diff --git a/devblog/2022-08-05-wallet-version-1-2-2.mdx b/devblog/2022-08-05-wallet-version-1-2-2.mdx deleted file mode 100644 index 7df5f85ea..000000000 --- a/devblog/2022-08-05-wallet-version-1-2-2.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -layout: post -title: Helium Wallet v1.2.0, 1.2.1, 1.2.2 -date: 2022-08-05 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## MOBILE Support - -MOBILE support is here! Once you have MOBILE in your account, you'll be able to see its balance and -send MOBILE payments to other Wallets on the network. - - - -## Add unknown addresses to Address Book - -Add an unknown wallet address to your Address Book with a long press. - -## Tap to Copy - -Whenever you see a transaction hash or an address, a quick press will automatically copy the hash or -address to your clipboard. - -# Bug Fixes - -## App Closing after Launch - -Fixed a bug for iOS and Android where the app would close after opening. This is fixed in 1.2.2 -only. diff --git a/devblog/2022-08-15-network-disurption-post-mortem.mdx b/devblog/2022-08-15-network-disurption-post-mortem.mdx deleted file mode 100644 index cef0dfacd..000000000 --- a/devblog/2022-08-15-network-disurption-post-mortem.mdx +++ /dev/null @@ -1,102 +0,0 @@ ---- -layout: post -title: 'Network Disruption Postmortem: 2022-08-08' -date: 2022-08-15 17:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -  - -# What happened - -On Monday 2022-08-08 at approximately 19:34 PM UTC Validators stopped producing blocks at block -`1,469,951` and a chain halt occurred. Normal chain operations resumed at approximately 08:00 AM UTC -just over 7 hours later. - - - -Throughout the disruption, devices continued to transfer data and operate normally. There were no -risks to Hotspot owners or HNT holders, but they did experience a halt in transaction processing, -for example, adding and transferring Hotspots, asserting location, and completing payment and burn -transactions. - -# Cause - -The latest chain variable activation revealed a previously unknown chain variable update hook bug -which caused the chain to halt. This chain variable was intended to disable legacy Hotspot indexing -operation in accordance with HIP 54, h3dex poc targeting. - -# Recovery - -The team identified the issue and requested operators of Validators in the Consensus Group to -restart. - -However, although a restart resolved the issue during testing, on mainnet a restart did not resolve -the issue and the core team issued an emergency Validator release, `v1.13.5`. This release disabled -the variable update hook and included a new blessed snapshot, generated on a chain follower with the -hook disabled. - -Validators were requested to upgrade to the emergency release, and those in the Consensus Group were -instructed to manually load the new snapshot. - -Once the Consensus Group’s ledgers were in agreement, the block skip process allowed the chain to -begin moving again, but with a lower number of transactions compared to normal operations - -# Resolution - -Following Validator release `v1.13.5`, which addressed the variable update hook issue, release -`v1.1.158` for ETL maintainers and `v1.1.70` for Blockchain Node operators were issued on 2022-08-09 -at 5:38 AM and 5:49 AM UTC, respectively, along with a snapshot to synchronize users past the halt. - -Certain Validators who updated after the chain resumed experienced ledger drift, which caused -Validators to go offline and remain halted. The team decided to issue release `v1.13.6` as a -non-mandatory release for halted Validators. This enabled the chain to continue to progress more -normally as Validators updated, aligned with the latest blocks based on the latest snapshot. - -The average PoC rate before the halt was ~270 receipts per block. The post-halt average initially -moved up to 210 receipts per block because of grpc blocking by certain Validators. Validators have -unblocked grpc connections and PoC receipts have returned to normal operations. - -The team provided an updated Validator release `v1.13.7` which included a number of performance -updates, but also included a fix to prevent the variable update hook issue from recurring. - -# Power of Community - -We want to extend our deep appreciation to our community members that host Validators. Thank you for -your attentiveness and willingness to troubleshoot issues that affect the entire network. Your -efforts and support move the network forward. - -# Timeline of Key Announcements - -Throughout the disruption, the team worked to keep users up to date on the status and required -actions. - -**2022-08-08** **19:34 PM UTC** Discovery and investigation of chain halt that occurred at block -height `1,469,951` as a result of activating the latest chain variable. - -**20:26 PM UTC** Core team requests Validators in the Consensus Group to restart their Validators in -order to resume block production. - -**22:45 PM UTC** Chain halt again at block `1,469,988`, continued exploration by the core team into -causes and solutions. - -**2022-08-09** **03:04 AM UTC** Emergency release `v1.13.5` sent to Validators which included a new -snapshot that all Validators were required to sync to in order to realign to block `1,469,990`. - -**05:09 AM UTC** Block moving at slow rates (approx 10% of normal transaction rate). No reward block -yet, team monitoring. Testing for ETL and Node releases. - -**05:49 AM UTC** Release `v1.1.158` for ETL maintainers and `v1.1.70` for Blockchain Node operators -issued along with corresponding snapshot to synchronize users past the chain halt. - -**08:02 AM UTC** Chain progressing as expected, PoC rate to continue to drift back to normal rates -(approx 270 receipts per block) over time. - -**18:31 PM UTC** Ledger drift identified among Validators that updated after chain resumed. Core -team issues release `v1.13.6` for general availability containing a newer blessed snapshot for any -Validators that are halted because of ledger drift. - -**2022-08-10** **22:34 PM UTC** Core team delivers beta release `v1.13.7` for Validators. This -release included a number of performance updates, but also included a fix to prevent the varhook -issue from recurring. diff --git a/devblog/2022-08-18-miner-hotspot-release.mdx b/devblog/2022-08-18-miner-hotspot-release.mdx deleted file mode 100644 index 00528d671..000000000 --- a/devblog/2022-08-18-miner-hotspot-release.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -layout: post -title: 'Miner Release: Disable Peer-to-Peer and Other Improvements' -date: 2022-08-18 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.08.17.1` `miner` release. This release disables -peer-to-peer activity when the Hotspot is no longer syncing the chain. This improves overall -performance for the peer-to-peer network for other participants and stability of the network as a -whole. Other improvements include an update to HTTP2 process that the Hotspot uses to communicate to -Validators (over GRPC), and a Kerlink-specific improvement that fixes the RSSI computation if the -SNR is lower than zero to reduce the number of invalid Proof-of-Coverage challenges and receipts. - - - -#### Related PRs - -[#1801](https://github.com/helium/miner/pull/1801) Disable p2p connections when the node is not -running the chain [#1777](https://github.com/helium/miner/pull/1777/) fix rssi computation from -rssic if SNR < 0 [#1760](https://github.com/helium/miner/pull/1760/) bump http2 client, pull in -settings flag fix - -### Plan - -We have been testing `2022.08.17.1` on Mainnet since August 17 12:45pm PT. Current ETA for GA is -August 18, 2022 11:00am PT. diff --git a/devblog/2022-09-14-wallet-version-1-3-0.mdx b/devblog/2022-09-14-wallet-version-1-3-0.mdx deleted file mode 100644 index 1c1a82e2c..000000000 --- a/devblog/2022-09-14-wallet-version-1-3-0.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -layout: post -title: Helium Wallet v1.3.0 -date: 2022-09-14 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Import CLI Wallet - -Do you have a CLI Wallet? Do you wish you had a user interface to use instead? Now you can! - - - -Upgrade your [CLI Wallet to v1.7.6](https://github.com/helium/helium-wallet-rs/releases/tag/v1.7.6) -to export your CLI Wallet private key and protect it with a passphrase. Scan the private key (as a -QR Code) with the Wallet app, decrypt the wallet with the passphrase you set up, and easily import a -CLI wallet into the app. Once imported, you can use the wallet like any other wallet within the -Helium Wallet app (send, receive, vote). - -## Multitoken Support - -The app now displays all tokens available on the Helium blockchain in a single place, including HNT, -MOBILE, DC, HST, and Staked HNT. All activity related to that token can be found by tapping the -Token name. - -Note that the Helium Vote option can be found in by tapping the "..." button between "Request" and -"Send" buttons. - -## Multiple Ledger Account Support - -The app now supports importing multiple Ledger accounts. diff --git a/devblog/2022-10-17-wallet-version-1-4-0.mdx b/devblog/2022-10-17-wallet-version-1-4-0.mdx deleted file mode 100644 index 0ac44466f..000000000 --- a/devblog/2022-10-17-wallet-version-1-4-0.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -layout: post -title: Helium Wallet v1.4.0 -date: 2022-10-17 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Brand New UI - -The UI has been cleaned to show a chart based on $HNT oracle price, made voting more intuitive, and -improved payments on subtokens. - - - -## iOS Homescreen and Lockscreen Widget Support - -Check out the new widgets available for iOS! See the Oracle $HNT price, diff --git a/devblog/2022-10-20-network-disruption-post-mortem.mdx b/devblog/2022-10-20-network-disruption-post-mortem.mdx deleted file mode 100644 index 1c02c3e5f..000000000 --- a/devblog/2022-10-20-network-disruption-post-mortem.mdx +++ /dev/null @@ -1,97 +0,0 @@ ---- -layout: post -title: 'Network Disruption Postmortem: 2022-10-19' -date: 2022-10-20 17:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -  - -# What happened - -On Wednesday 2022-10-19 at approximately 2:20 AM UTC Validators stopped producing blocks at block -`1,575,935` and a chain halt occurred. Consequently, at 5:55 AM UTC a second chain halt occurred at -block 1,575,955. Normal chain operations resumed approximately 5.5 hours later at 7:49 AM. - - - -Throughout the disruption, Hotspots did not participate in Proof-of-Coverage. All funds were safe, -but pending transactions were delayed until the halt was resolved. Pending Transactions include -adding a Hotspot, changing a Hotspot Location, transferring a Hotspot, payments, and token burns. -During the disruption, data transfer was largely unaffected by the chain halt. - -# Cause - -The core team identified a root cause of slow blocks. The string of slow blocks triggered a latent -bug in Hotspots to continually reach out to Validators for the latest block information and not back -off when they received a block they perceived as stale. - -# Recovery - -The temporary solution was to block gRPC port (default 8080) so Hotspots stopped making requests to -Validators and allowed Validators to resume block production. Once block production resumed, -Validators were requested to gradually reopen gRPC port(s) across their fleets. - -There was a second halt after this that the team decided required a new Validator release. The -problem was some nodes were still online, but unable to absorb blocks because they were running out -of file handles. This led to several members of the Consensus Group unable to follow the chain. The -Hotspot swarming issue is believed to be a secondary effect of the file-handle issue that initially -caused slow blocks. - -The core team then tagged mandatory release v1.15.6. This release included a patch to fix a latent -bug in environments where multiple Validator instances may have been running on the same machine -causing a resource exhaustion (due to too many open files on the server). - -Validator operators then were asked to gradually re-enable the gRPC port (default 8080). - -# Resolution - -In order to prevent this from happening again, we are implementing several changes. The first, -released in `v1.15.6`, fixed what is believed to be the original bug. - -Following that, we plan to make the system more resilient to gRPC storms both on the Hotspot and the -Validator side. - -# Power of Community - -Thank you again to our Validator community for working with us and acting swiftly to help resolve -this issue. Your continued dedication and support has such a huge positive impact on the entire -Helium community that does not go unnoticed. - -# Timeline of Key Announcements - -Throughout the disruption, the team worked to keep users up to date on the status and required -actions. All below times in UTC. - -**2022-10-19** **2:20 AM** Core team started to investigate the first chain halt at block height -`1,575,935` with a plan to update the community as soon as they learned more. - -**3:00 AM** Root cause was identified and the core team began to work with the Validator community -to resume block production. - -**4:07 AM** It was believed the root cause stemmed from Hotspots constantly reaching out to -Validators was due to a latent bug triggered by a series of slow blocks. Validators were requested -to close the communication channel that Hotspots use to get ledger information and challenges. - -Once block production resumed, Validators were instructed to gradually reopen ports across their -fleets to communicate with Hotspots once again. - -**5:55 AM** Chain halted a second time at block height `1,575,955`. The network hit the same issue -that was cleared earlier and was most likely the root cause of the initial outage. The core team and -Validator operators in the community worked together to investigate. - -**7:23 AM** The core developers and the Validator community identified the root cause of chain halt -(and the prior one) and a new Validator release, `v1.15.6`, was prepared. In the meantime, a hotfix -was applied to certain Validators in the Consensus Group and block production resumed. - -**7:29 AM** The core team tagged mandatory release `v1.15.6`. This release included a patch to fix a -latent bug in environments where multiple validator instances may have been running on the same -machine causing a resource exhaustion. Validator operators were requested to upgrade to v1.15.6 -without delay as failure to upgrade could result in another chain halt. - -**7:32 AM** Validators were notified to gradually re-enable gRPC port (default 8080) across their -fleets. - -**7:49 AM** The Validator release was issued and block production continued. All Validator operators -were urged to follow upgrade instructions to `v1.15.6`. diff --git a/devblog/2022-10-31-miner-hotspot-release.mdx b/devblog/2022-10-31-miner-hotspot-release.mdx deleted file mode 100644 index da912c6a9..000000000 --- a/devblog/2022-10-31-miner-hotspot-release.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: 'Miner Release: Add exponential back-off' -date: 2022-10-31 -hide_table_of_contents: true -authors: [cokes518] ---- - -The core developers have tagged a new `2022.10.28.0` `miner` release. This release adds exponential -back-off for Hotspots when requesting ledger information from Validators. This also ensures timely -back-off when block times are too high and avoids too many Hotspots attempting to connect to a -Validator. The pull request specifically addresses the blockchain outages over the past week from a -Hotspot's perspective. - - - -#### Related PRs - -[#1839](https://github.com/helium/miner/pull/1839) add exp backoff to grpc client reconnects to vals - -### Plan - -We have been testing `2022.10.28.0` on Mainnet since October 28 8:43am PT. GA is October 31, 2022 -10:00am PT. diff --git a/devblog/2022-11-01-wallet-version-1-4-1.mdx b/devblog/2022-11-01-wallet-version-1-4-1.mdx deleted file mode 100644 index 4e81053bd..000000000 --- a/devblog/2022-11-01-wallet-version-1-4-1.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -layout: post -title: Helium Wallet v1.4.1 -date: 2022-11-01 -hide_table_of_contents: true -authors: [cokes518] ---- - -  - -# New Features - -## Burn HNT for DC from Console - -The Wallet app now supports burn transactions from Helium Console. To burn Data Credits for packet -transfer, simply tap the "Send" button and the QR code in the top left corner and scan the QR code. - - - -# Bug Fix - -- Allow non-default wallets to sign transactions -- Fix max font size for smaller displays -- Fix payment screen if pin is off (but previously enabled) diff --git a/devblog/2022-11-02-network-disruption-post-mortem.mdx b/devblog/2022-11-02-network-disruption-post-mortem.mdx deleted file mode 100644 index d315811e8..000000000 --- a/devblog/2022-11-02-network-disruption-post-mortem.mdx +++ /dev/null @@ -1,161 +0,0 @@ ---- -layout: post -title: 'Network Disruption Postmortem: 2022-10-26' -date: 2022-11-02 17:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -  - -# What happened - -On Wednesday, 2022-10-26, at approximately 1:57 AM UTC, Validators stopped producing blocks at block -`1,587,313`, and a chain halt occurred. Consequently, two days later, at 3:57 PM UTC, a second chain -halt occurred at block `1,589,496`. Normal chain operations resumed approximately 32 hours later at -2022-10-30 1:32 AM UTC. - - - -Throughout the disruption, Hotspots were not able to fully participate in Proof-of-Coverage. All -funds were safe, but pending transactions were delayed until the halt was resolved. Pending -Transactions include adding a Hotspot, changing a Hotspot Location, transferring a Hotspot, -payments, and token burns. During the disruption, data transfer was unaffected by the chain halt. -Over the next day, the performance of the chain was not as expected. - -# Cause - -The core team identified a root cause of the chain halt. The chain halt was triggered as a result of -activating the latest chain variables, which resulted in ledger drift caused by the double -application of election penalties on the Consensus Group that the rest of the chain did not agree -with. - -The core developers have identified two main issues that contributed to this chain halt: - -- Consensus penalties got applied to the lagging ledger differently than they did on the leading - ledger. -- Some Consensus Group members had their lagging ledgers fall behind an additional block relative to - other members. - -The first issue caused snapshots to stop working (snapshots were taken via the lagging ledger, which -had become corrupted). This corruption prevented nodes that saw an invalid block and tried to -recalculate the ledger to continue syncing because they started the recalculation based on the -corrupted lagging ledger. - -The second issue caused “split rounds”: some Consensus Group members had 51 blocks (historical -ledgers) and other members (correctly) only had 50. - -Certain transactions (including poc_receipts) define transaction validity partly in terms of whether -a historical ledger is available at a certain height. This meant every time a poc_receipt -transaction from the 51st previous block was submitted, the Consensus Group members would disagree. -Some members would try to include that transaction in the proposed block while others would not, -causing the halt. - -This event correctly activated the “round skip timer” which allowed the Consensus Group to drop -transactions in the proposed block and proceed until it encountered another transaction from prior -to the previous 50 blocks. - -The Validator release forced no more than 50 blocks to be retrievable, even if more were available -locally so that particular issue was no longer possible. - -# Recovery - -The chain variables were rolled back, but the Consensus Group began to drift away from the main -chain. - -To prevent overwhelming Hotspot connections, Validator operators were asked to disable gRPC ports -(default 8080). - -To recover the team created a rescue block at (7:08 PM), and assembled a new Consensus Group to -restart the chain. - -# Resolution - -The core team released candidate Validator `v1.15.8` to resolve the chain halt by forcing no more -than 50 blocks to be retrievable. - -Looking forward, the core team has released Validator beta build, `v1.15.10`. Among the key fixes, -this release includes an update to change snapshot generation to avoid using the possibly corrupt -lagging ledger in favor of a known-good ledger checkpoint. - -# Power of Community - -Thank you again to our Validator community for working with us and acting swiftly to help resolve -this issue. During the chain halt and resolution, Validators and the entire community are asked to -slop transactions or refrain from submitting duplicate transactions. Your continued dedication and -support have such a huge positive impact on the entire Helium community that it does not go -unnoticed. - -# Timeline of Key Announcements - -Throughout the disruption, the team worked to keep users up to date on the status and required -actions. All below times in UTC. - -**2022-10-26** - -**1:57 AM** The core team started to investigate the first chain halt at block height 1,587,313 with -a plan to update the community as soon as they learned more. - -**2:15 AM** Root cause required a rescue block to solve. Validator operators were instructed to -close port 8080. The chain remained halted. - -**3:08 AM** Core developers assembled a new Consensus Group. After the group is elected, the core -team would issue a rescue block to get past the halt. The chain remained halted. - -**4:16 AM** The chain resumed. A new Consensus Group was assembled and began creating new blocks. -Other services were being monitored, including the ETL for the API that serves data to the explorer -and other apps. - -**5:08 AM** The remainder of Validators were catching up to the new block height. The core -developers continued to monitor the chain. - -**6:27 AM** Some validators were stuck at block height `1,587,339` or prior to `1,587,313`. They -issued commands for Validators stuck at the latter. - -**2022-10-27** - -**5:21 PM** The chain is operating, and transactions are clearing, but many Validators remain -offline. For hotspot owners, this means Proof-of-Coverage activity was degraded. The core developers -were still looking for a root cause. Validators were instructed to continue to force re-syncs of -blocks, and an emergency release was expected. - -**10:14 PM** PoC activity had somewhat recovered, and the chain was operational. The core developers -notified Validator operators that they would release a snapshot to get all Validators back to -operating normally. This is a temporary solution as they continue to solve the root cause and should -help the network recover. Another chain halt was still possible, but the team and operators -continued to monitor the chain. - -**2022-10-28** - -**3:45 AM** The core developers released a blessed snapshot. Many participants (Validators, Router, -ETL, Node) remained out of sync. All participants were instructed to download the snapshot or pull -the latest-snap from snapshots. - -**3:57 PM** The core developers noticed another chain halt at block `1,589,496`. - -**4:59 PM** The core team continued to monitor the Consensus Group and instructed validators to -close port 8080. - -**6:03 PM** The Core team continued to monitor the Consensus Group. Which, at this time, had agreed -on a block and began moving into block `1,589,497`. Validators remained instructed to close -port 8080. - -**7:06 AM** The core team continued to monitor the Consensus Group. Which at this time was stuck -again on block `1,589,531`. - -**9:06 PM** The chain had progressed a bit further, but it was yet to form a new Consensus Group, -leaving rewards delayed and PoC degraded. The community was asked to be patient at this time, and -the resolution would likely go through the weekend. - -**2022-10-29** - -**12:51 AM** The chain halt resolved itself. Regular blocks, Consensus Group elections, and rewards -were back up and working. - -**11:36 PM** Thanks to the logging introduced in the last few days, the core developers were able to -identify the root cause of the various halts. - -**2022-10-30** - -**1:32 AM** The chain resumed producing blocks, and a new Validator version `1.15.8` was released to -address the latent bug. diff --git a/devblog/2022-11-14-firmware-hotspot-release.mdx b/devblog/2022-11-14-firmware-hotspot-release.mdx deleted file mode 100644 index 2619709d6..000000000 --- a/devblog/2022-11-14-firmware-hotspot-release.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -layout: post -title: 'Hotspot Firmware Release: Updating Frequency Plan and Region Change Logic' -date: 2022-11-14 -hide_table_of_contents: true -authors: [cokes518] ---- - -The Nova developers have tagged a new `2022.11.10.0` firmware release for Original Helium Hotspots. -This release updates the regional frequency plan to their latest versions as well as implements the -logic required to digest band plan change. - - - -### Plan - -We have been testing `2022.11.10.0` since November 10, 2022. Current ETA for GA is November 14, 2022 -3:00 PM PT. diff --git a/devblog/2022-11-21-network-disruption-post-mortem.mdx b/devblog/2022-11-21-network-disruption-post-mortem.mdx deleted file mode 100644 index dfdbd02dc..000000000 --- a/devblog/2022-11-21-network-disruption-post-mortem.mdx +++ /dev/null @@ -1,133 +0,0 @@ ---- -layout: post -title: 'Network Disruption Postmortem: 2022-11-16' -date: 2022-11-21 17:00 -0700 -hide_table_of_contents: true -authors: [jdgemm] ---- - -  - -# What happened - -On Wednesday, 2022-11-16, at approximately 22:06 UTC, Validators stopped producing blocks at block -`1,619,546`, and a chain halt occurred. Normal chain operations resumed 18 hours on 2022-11-17 at -approximately 15:57 UTC. - - - -Throughout the disruption, Hotspots were not able to fully participate in Proof-of-Coverage. All -funds were safe, and data transfer for sensors and devices on the network continued uninterrupted. - -However, pending transactions were delayed until the halt was resolved. Validator Operators we’re -asked to restart their nodes to kickstart consensus and produce blocks again. - -At the same time, the API was down during maintenance, and a database became corrupted. This led to -a backup of 170TB of data before the main database could be restored. - -# Cause - -The chain halt was triggered as a result of a corrupted region cache issue for some validators with -the release of the latest chain variable. - -Because the region was marked as “unknown” to some of the members an election block was produced -that could not be absorbed by many nodes, including most of the new consensus group. - -This led to a halt until enough nodes had been restarted to clear the cache and absorb the block. -After enough of the group had restarted the cache issue was fixed and progress was possible. - -Several hours later a second manifestation of the bug occurred. The cache was corrupted again but on -fewer nodes, so the chain was able to make partial progress via “skipping” the block proposals where -there was disagreement. These skip blocks were the blocks that would show up every half hour to an -hour. - -New consensus group elections and reward transactions happen together, so the chain was unable to -make progress electing a new group. Therefore another restart was needed to repair the issue again. -This restart was more difficult because it was harder to reach some operators at that point. - -# Recovery - -Validators were identified and notified to run commands in an effort to resolve the cache issue. -Because of the decentralized nature of Validator operations, this message took some time to -distribute and for the call to be acted upon. - -Initially, to hasten recovery, the team created a rescue block at 5:10 AM UTC. - -# Resolution - -Validator Operators were instructed to perform several actions during the chain halt: - -Restart their node, regardless of if they are in consensus or not. After restarting, run the skip -command: `miner hbbft skip`. - -Test if your Validator was one with a corrupted region cache by running: - -`miner eval 'blockchain_region_v1:h3_to_region(611338192892723199,blockchain:ledger()).'` - -If corrupted, Validators we’re instructed to clear the cache and run two commands: -`miner ledger cache clear` followed by `miner ledger cache prewarm` - -All other Validators were asked to refresh the cache, regardless of whether they were in the -Consensus Group or not. Some Validators remained behind on block production, and they were again -asked to restart. - -18 hours on 2022-11-17 at approximately 15:57 UTC, all Validators were functioning as normal and -block production resumed. Validators were notified to take action through Discord and -validators-status.helium.com. - -# Power of Community - -Big thanks to the Validator community and those members who acted swiftly to help resolve this issue -and provide feedback during the halt. - -During the chain halt and resolution, Validators we’re asked to restart, and run commands during -late hours. - -The entire Helium Community deeply appreciates your continued dedication and support of the Helium -Network. - -# Timeline of Key Announcements - -Throughout the disruption, the team worked to keep users up to date on the status and required -actions. All below times in UTC. - -**2022-11-16** - -**00:32** Validator Operators were asked to restart their nodes to kickstart consensus and start -producing blocks again. - -**2:17** The API remained down after scheduled maintenance. The chain remained halted at this time. -Both were being fixed in parallel. - -**4:16** API and chain remained halted. - -**6:24** The Core Developers issued a rescue block, and it was accepted by the chain. Validator -Operators were instructed to monitor block production. The chain was not fully cleared. - -**12:04** The Core Developers identified the root cause of the chain halt. It was identified that -some Validators had a corrupt region cache and were preventing block production. A fix had been -issued to them. No updates were required for the entire Validator group, but operators needed to run -commands on their affected Validators. The chain remained halted. - -**14:54** The chain remained halted. The Core Developers were still working with validators to -resolve the corrupted region cache issue. - -**15:23** The API remained down. The Core Developers identified the root cause of this. The API had -a database that became corrupted during maintenance. This affected how all services could be brought -back up. As a result, over 170TB of data had to be rebuilt from scratch. At this time, the main -database was up and running, but in order to service all users and services, The Core Developers -needed to create several more instances. - -**15:51** The chain remained halted. The Core Developers were still working with validators to -resolve the corrupted region cache issue. - -**15:57** Block production resumed, and the chain halt was resolved. The Validator Operator -community responded to the call to run commands. The Core Developers continued to monitor the status -of block production. - -**16:49** At this time, the chain was producing blocks, but the API remained down. This meant that -there was no way for the App and Explorer UI to display block information, including rewards. Links -to community data sources were provided. - -**19:10** The API was back up and running. At this time, the Explorer and App were about 200 blocks -behind and were catching back up to real-time data streams. diff --git a/devblog/2022-12-12-hotspot-release.mdx b/devblog/2022-12-12-hotspot-release.mdx deleted file mode 100644 index 5c0e102c0..000000000 --- a/devblog/2022-12-12-hotspot-release.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -layout: post -title: 'Hotspot Release: Preparations for Off-Chain Proof-of-Coverage' -date: 2022-12-19 -hide_table_of_contents: true -authors: [cokes518] ---- - -The Nova developers have tagged a new `2022.12.13.0` Hotspot release for Original Helium Hotspots. -This release prepares Hotspots for off-chain proof-of-coverage by updating the automatic beacon rate -to every 6 hours, adds "jitter" to the beacon rate such that in the event all Hotspots come online -at the same time, the PoC system is not overwhelmed with PoC. - - - -### Plan - -We have been testing `2022.12.13.0` since December 13, 2022. Release for Original Helium Hotspots -will be December 13, 2022 at 2:15pm PST. GA for other Hotspot Manufacturers is December 19, 2022 at -9:30am PST. diff --git a/devblog/2022-12-19-wallet-version-1-5-0.mdx b/devblog/2022-12-19-wallet-version-1-5-0.mdx deleted file mode 100644 index 41030ab78..000000000 --- a/devblog/2022-12-19-wallet-version-1-5-0.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: post -title: Helium Wallet v1.5.0 and Helium Hotspot v4.3.0 -date: 2022-12-19 -hide_table_of_contents: true -authors: [cokes518] ---- - -## Helium Wallet 1.5.0 - -Prepare for the Helium migration to the Solana blockchain! This app update makes it easier for "blue -app" users to successfully migrate to the Wallet app to manage their tokens. For those already on -the Wallet app, migration will be easy. Just make sure your app is updated to the latest versions -and your tokens will automatically be updated to use Solana. - - - -## Support for Helium Hotspot Migration - -Adds support for incoming Wallets from Helium Hotspot App (blue app) - -- checks if wallet being migrated already exists -- adds deeplink signing for `transfer_hotspot` and `assert_location` transactions coming from the - Helium Hotspot App - -## Bug Fixes - -- fixes Wallet Connect to improve Crowdspot experience -- fixes Android Ledger Scan - -  - -# Helium Hotspot 4.3.0 - -The Helium blockchain migration to Solana is almost here! Prepare for the update by migrating your -wallet to the Helium Wallet App (aka black app)! Migration is easy. Make sure you have Helium Wallet -app v1.5.0 installed, then initiate the migration from the Helium Hotspot app. - -You'll continue using the same 12 words in the Wallet app and continue managing your tokens. When -the migration happens, you'll be all set on the black app. - -## Support for Wallet Migration - -Adds 1-click support to export your 12 word seed phrase wallet to the Helium Wallet app (v1.5.0 -required) - -## Onboarding of New Hotspots to Maker Apps - -Redirects users during onboarding of new Hotspots to use Maker apps. diff --git a/devblog/2023-01-30-wallet-version-1-6-0.mdx b/devblog/2023-01-30-wallet-version-1-6-0.mdx deleted file mode 100644 index ba9ae024e..000000000 --- a/devblog/2023-01-30-wallet-version-1-6-0.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -layout: post -title: Helium Wallet v1.6.0 -date: 2023-01-30 -hide_table_of_contents: true -authors: [cokes518] ---- - -## Helium Wallet 1.6.0 - -This latest update adds more behind the scenes support for the Solana migration, including transactions, adding, updating, and viewing Hotspots on Solana L1, and swap support. - -In addition, 1.6.0 fixes a bug where users could not sign into Crowdspot and fixes the display of HNT price on iOS widgets. - - diff --git a/devblog/2023-04-28-offchain-data-transfer-postmortem.mdx b/devblog/2023-04-28-offchain-data-transfer-postmortem.mdx deleted file mode 100644 index c74877b04..000000000 --- a/devblog/2023-04-28-offchain-data-transfer-postmortem.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -layout: post -title: Off Chain Data Transfer Post Mortem (2023-04-18 & 2023-04-19) -date: 2023-04-28 -hide_table_of_contents: true -authors: [lytzV] ---- - -On 2023-04-18, a new Config Service release was deployed as part of the Oracle 1.0.0 release, which -included a more rigorous request signature verification. This caused a protobuf mismatch with Packet -Router and Helium Router. - - - -As a result of that, there were two data transfer outages, separately occurring on 2023-04-18 and -2023-04-19. - -- On 2023-04-18, the outage was triggered by the protobuf mismatch between the Packet Router and - Config Service. An emergency Packet Router update 0.0.22 was deployed to reconcile the protobuf - mismatch. -- On 2023-04-19, the outage was triggered by the protobuf mismatch between the Helium Router and - Config Service, which caused the Helium Router hotspot location request rpc to Config Service to - fail. As a result, devices cannot join since DevAddr allocation is based on hotspot location, and - it created load & memory issue that leaked into other processes, which also led to degraded uplink - & downlink. Emergency Oracle update and Console update 2.2.36 were deployed to reconcile the - protobuf mismatch. - -## Next Steps - -At its core, this incident was caused by miscommunication and oversight. In order to minimize the -chance of exposing us and the Helium Network to preventable mistakes like this, the team has agreed -upon the following area of improvements. - -### Better Communication - -Teams cannot work in silos, especially when breaking changes can be introduced by each other. Config -Service, Packet Router and LNS such as Helium Console can only form a strong triangle when they work -together in harmony. Therefore, any change could be a breaking change. When in doubt, ask! Going -forward, the Oracle team and Data Transfer team will perform a sanity check with each before prior -to a release if it contains work that can impact each other. - -### Better Safety Net - -While better communication certainly helps, ultimately there will be human errors. That’s why we -also need to have another layer of safety net. - -- First, before any of the three components (Config Service, Packet Router, and LNS) are rolled out, - an end-to-end data transfer test must be carried out, verifying success to join, uplink and - downlink for all device profiles supported by the LNS. The test shall be initiated by the team - that tries to introduce the change, and assisted by the LNS team. There are also tests that can be - automated into the Github Actions. -- Second, make sure alerts are in place. In the 2023-04-19 incident, if alerts were more exhaustive, - our response time could have been faster. Specifically, we have grafana alerts for when join & - uplink rate approaching 0. However, turns out grafana could categorize 0 as NONE, hence requiring - a separate alarm that monitors for that state. diff --git a/devblog/2023-06-16-foundation-console-dc-usage.mdx b/devblog/2023-06-16-foundation-console-dc-usage.mdx deleted file mode 100644 index 3905c7c6b..000000000 --- a/devblog/2023-06-16-foundation-console-dc-usage.mdx +++ /dev/null @@ -1,141 +0,0 @@ ---- -layout: post -title: Foundation Console DC Usage -date: 2023-06-16 17:00 -0800 -hide_table_of_contents: true -authors: [jhiller, mbthiery] ---- - -# Foundation Console Exploit Postmortem (2023-5-27 to 2023-6-16) - -## Summary - -The Helium Foundation Console faced an exploit that was amplifying existing network usage and -allowing bad actors to earn more than they were spending in DC. In essence, they were paying for 1 -DC while the Console was burning up to 5 DC due to an accounting bug. This bug also affected all -instances of Console that weren't managing their routes. This bug only affected these public -instances and did not result in unpaid traffic on the Helium Network as a whole. - - - -Two additional potential exploits were also identified and are in the process of being resolved. - -### Background - -After the migration to Solana, routing was transferred over to the Helium Packet Router (HPR). HPR -keeps track of routes which it uses to determine which LoRaWAN Network Server (LNS) to forward the -data packets it receives from the network's hotspots to. These routes include a multibuy field which -determines how many copies of the data packet the LNS is willing to pay for. There will be multiple -copies of the same data packet when multiple hotspots receive a sensor device's uplink. Upon -receiving the packets from HPR, an LNS can then forward them to its users and bill them -appropriately. - -### Cause - -The Helium Foundation Console (an LNS) was software initially designed around the Helium L1 -blockchain and used the blockchain for routing. As such, it had a single system route for all -devices. In the interest of supporting multiple packet purchasing for the existing devices, this -route was set to multibuy value of 5. The multibuy accounting was abstracted in the UI. Due to this, -post-migration, a device without multibuy (or a multibuy of less than 5) would cause the LNS to pay -for up to 5 copies of the data while the user was only being billed for 1 copy. This bug affected -all the devices setup on our console and erroneously amplified the network usage. One or more bad -actors further amplified the effects of this bug by creating additional traffic for the sole purpose -of having their hotspots transfer the data and farming the associated rewards. In essence, their -hotspots could receive 5 DCs worth of traffic for the cost of sending a single DC from a device. - -
- -```mermaid -sequenceDiagram - participant D as Device - participant H as Multiple Hotspots - participant HPR as HPR - participant LNS as LNS (Helium Foundation Console) - actor Org as Organization (User Account) - - D->>H: Send data - H->>HPR: Each hotspot forwards received data to HPR - Note over HPR: HPR holds logic to manage how many copies to pass along.
(multibuy value: 5 from LNS route config) - HPR->>LNS: Forward 5 copies of data to LNS - Note over LNS,HPR: The LNS has a global balance of DC.
It is billed 5x DC for receiving 5 copies. - LNS->>Org: Charge Organization for only the device's multibuy config (1x DC) - Note over Org,LNS: LNS has paid for 5x DC while user is billed for only 1 DC -``` - -### Solution - -An investigation and sweep of active devices on Foundation Console revealed several dozen devices -under a small subset of organizations accounting for at least the majority of traffic on the -Foundation Console despite representing a fraction of the total devices. These accounts were removed -and account creation was temporarily halted while developers implemented an update. - -The update introduced a feature-add for the entire network which allows setting multi-buy logic on -specific devices. This functionality was added in addition to the existing multi-buy logic on -routes. This prevented the need for drastic overhaul of Console's route code and made -device-specific controls easier for other LNS operators in the future. - -This device-level control is available by attaching a multibuy value to the device's session key -filter (SKF). This SKF is transmitted to the Config Server which in turn forwards it to the HPR. If -an LNS operator does not submit a multibuy value in a device's SKF, it will default to the route's -multibuy value to determine how many copies of a packet should be purchased. - -### Outcome - -This fix was deployed on June 13, 18:00 UTC. The result was a precipitous drop in DC burned for -network traffic. Following this fix, IoT Network traffic remained stable until about June 15, 03:00 -UTC when network traffic began to increase at an inorganic rate again. Since then the data usage has -gone back down to the post fix levels. We are still investigating the potential cause for this and -whether this was a continued effort to take advantage of the fixed exploit or a new exploit -altogether. As of now, we are leaning towards the former due to the reduction in usage after a day. -We will continue monitoring DC usage for suspect activity. - -## Next Steps - -The core mechanism of these exploits resides in having the LNS pay for more data than is billed to -the users. As such we will start tracking the amount of DC billed to the user's allocation of the -overall DC pool and the amount of network usage (DC) that the LNS has paid for. When the two diverge -we'll quickly know that an exploit was likely found. - -Exploration revealed two additional attack vectors that have not yet been exploited. - -The first is similar to the multibuy bug by being a configuration bug that was introduced with the -migration to Solana and the adoption of HPR for routing. In essence, a user with a balance of 0 -whose devices were still running would cause the Console to pay for the device's uplinks. To fix -this bug, the Console now properly informs the Config Server and HPR that the user's devices should -be disabled when their balance reaches zero. This was not an issue pre-migration as the Console -would run state channels and was able to verify a user's balance itself. - -The second has not yet been resolved so, due to the opportunity for abuse, it will not be detailed -here. Core stakeholders have however been notified and a design has been proposed which will prevent -its use in the future, making the Helium IoT Network increasingly robust into the future. - -## Timeline - -**April 19th** Migrate to Solana. HPR takes over routing. The amplification of network usage starts. -This was initially attributed to improved packet delivery due to the more streamlined packet routing -system. - -**May 27th** Network usage starts growing rapidly. - -**June 8th** Foundation starts investigating the legitimacy of the network usage growth. - -**June 12th** The multibuy bug is identified. Developers work on necessary code changes. - -**June 12th - 04:08 UTC** New signups to the console are disabled and the bad actors' accounts are -deleted. - -**June 12th - 04:38 UTC** Discord Announcement with regards to disabled signups and that an exploit -was identified. - -**June 13th - 17:53 UTC** Config Service and IoT Packer Router are updated to enable SKF based -multibuy configurations. The Foundation console stops overpaying for network usage. - -**June 14th - 03:18 UTC** The bug being resolved, Abhay reveals more details about the exploit in -the Foundation channel. - -**June 15th - 04:00 UTC** Network usage nearly doubles in an hour. The team starts investigating -other possible exploits. Another potential exploit is found. It does not however seem to be actively -exploited. - -**June 16th - 13:00 UTC** Network usage has returned to expected levels. The running hypothesis is -that gamers realized they are no longer benefiting from it and stopped their traffic. diff --git a/devblog/authors.yaml b/devblog/authors.yaml deleted file mode 100644 index e74b0af3b..000000000 --- a/devblog/authors.yaml +++ /dev/null @@ -1,99 +0,0 @@ -abhay: - name: Abhay Kumar - url: https://github.com/abhay - image_url: https://github.com/abhay.png - -amirhaleem: - name: Amir Haleem - url: https://github.com/amirhaleem - image_url: https://github.com/amirhaleem.png - -cokes518: - name: Coco Tang - url: https://github.com/cokes518 - image_url: https://github.com/cokes518.png - -evanmcc: - name: Evan Vigil-McClanahan - url: https://github.com/evanmcc - image_url: https://github.com/evanmcc.png - -fvasquez: - name: Frank Vasquez - url: https://github.com/fvasquez - image_url: https://github.com/fvasquez.png - -jaykickliter: - name: Jay Kickliter - url: https://github.com/jaykickliter - image_url: https://github.com/jaykickliter.png - -jdgemm: - name: Dal - url: https://github.com/jdgemm - image_url: https://github.com/jdgemm.png - -jeffgrunewald: - name: Jeff Grunewald - url: https://github.com/jeffgrunewald - image_url: https://github.com/jeffgrunewald.png - -ke6jjj: - name: Jeremy Cooper - url: https://github.com/ke6jjj - image_url: https://github.com/ke6jjj.png - -lthiery: - name: Louis Thiery - url: https://github.com/lthiery - image_url: https://github.com/lthiery.png - -macpie: - name: Macpie - url: https://github.com/macpie - image_url: https://github.com/macpie.png - -madninja: - name: Marc Nijdam - url: https://github.com/madninja - image_url: https://github.com/madninja.png - -pharkmillups: - name: Mark Phillips - url: https://github.com/PharkMillups - image_url: https://github.com/PharkMillups.png - -vagabond: - name: Andrew Thompson - url: https://github.com/vagabond - image_url: https://github.com/vagabond.png - -vihu: - name: Rahul Garg - url: https://github.com/vihu - image_url: https://github.com/vihu.png - -xandkar: - name: Siraaj Khandkar - url: https://github.com/xandkar - image_url: https://github.com/xandkar.png - -jadeallenx: - name: Jade Allen - url: https://github.com/jadeallenx - image_url: https://github.com/jadeallenx.png - -lytzV: - name: Victor Li - url: https://github.com/lytzV - image_url: https://github.com/lytzV.png - -jhiller: - name: Joey Hiller - url: https://github.com/jthiller - image_url: https://github.com/jthiller.png - -mbthiery: - name: Matthew Thiery - url: https://github.com/mbthiery - image_url: https://github.com/mbthiery.png diff --git a/docs/api/blockchain/accounts.mdx b/docs/api/blockchain/accounts.mdx deleted file mode 100644 index 65aba25f1..000000000 --- a/docs/api/blockchain/accounts.mdx +++ /dev/null @@ -1,1770 +0,0 @@ ---- -id: accounts -title: Accounts -pagination_label: Accounts -sidebar_label: Accounts -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/accounts ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -As part of the Solana Migration, these API endpoints will no longer be updated or provide live data. -These endpoints may be accessible for a limited time following the Migration as a reference to -historical Helium blockchain data. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Available on the Solana API - -### List Accounts - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts -``` - -Retrieve the current set of known accounts.The result is paged. A `cursor` field is present if more -results are available. - -Note: The cursor for accounts is valid for a limited time. If you receive a `400` http response code -for a cursor based request, you will need to start fetching accounts from the beginning of the list. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ---------------------------------------- | -| cursor (optional) | _string_ | Cursor for the page of accounts to fetch | - - - - -200: OK - -```json -{ - "data": [ - { - "validator_count": 0, - "staked_balance": 0, - "speculative_sec_nonce": 0, - "speculative_nonce": 11, - "sec_nonce": 0, - "sec_balance": 0, - "nonce": 11, - "mobile_balance": 0, - "iot_balance": 0, - "hotspot_count": 0, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600652, - "balance": 97, - "address": "13etjTqyGLK7WQh8pp9VJy5ejh5MXmwFee2eAi3TfAA5kS1jEJb" - }, - { - "validator_count": 0, - "staked_balance": 0, - "speculative_sec_nonce": 0, - "speculative_nonce": 1, - "sec_nonce": 0, - "sec_balance": 0, - "nonce": 1, - "mobile_balance": 0, - "iot_balance": 0, - "hotspot_count": 0, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600652, - "balance": 0, - "address": "14Vshtwv9RMY5GuTe1sgLDJmmF2f46EW3etEJzjDjhKJSEprtHh" - }, - { - "validator_count": 0, - "staked_balance": 0, - "speculative_sec_nonce": 0, - "speculative_nonce": 8, - "sec_nonce": 0, - "sec_balance": 0, - "nonce": 8, - "mobile_balance": 0, - "iot_balance": 0, - "hotspot_count": 1, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600652, - "balance": 70074024822, - "address": "14PaJeSfNp5Q3MtDw5yEsJwb2kHJqbcjjLe9aycjroqNFnL4EyS" - }, - { - "validator_count": 0, - "staked_balance": 0, - "speculative_sec_nonce": 0, - "speculative_nonce": 0, - "sec_nonce": 0, - "sec_balance": 0, - "nonce": 0, - "mobile_balance": 0, - "iot_balance": 0, - "hotspot_count": 1, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600652, - "balance": 35831331399, - "address": "13rUthiDQUeY9HfwoZFpkqtsbtaubzRyerCsSu1qdDXuVZGL45k" - }, - { - "validator_count": 0, - "staked_balance": 0, - "speculative_sec_nonce": 0, - "speculative_nonce": 2, - "sec_nonce": 0, - "sec_balance": 0, - "nonce": 2, - "mobile_balance": 0, - "iot_balance": 0, - "hotspot_count": 0, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600653, - "balance": 453431287, - "address": "14Xg1SqiJDsmM2YvchR4UacevcuxjfyrjdyNEpRMmfBU7vrZba9" - } - ], - "cursor": "eyJoZWlnaHQiOjQzNTIzOSwiYmVmb3JlX2Jsb2NrIjo0MTM3MDIsImJlZm9yZV9hZGRyZXNzIjoiMTRpdndTNnRBQXVzRFo0QXVucTZXZ2dUc285cEZFbXZ2eXM5S1NXYUJDRENMd1UyMURkIn0" -} -``` - - - - ---- - -### List Richest Accounts - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/rich -``` - -Returns up to 100 of the accounts sorted by highest token balance. - - - - -_Query Parameters_ - -| param | Type | Note | -| ---------------- | -------- | -------------------------------------------------- | -| limit (optional) | _string_ | Number of accounts to return. Default 100, max 100 | - - - - -200: OK - -Result for `/v1/accounts/rich?limit=2` - -```json -{ - "data": [ - { - "validator_count": 310, - "staked_balance": 270000000000000, - "speculative_sec_nonce": 0, - "speculative_nonce": 428, - "sec_nonce": 0, - "sec_balance": 166205166949, - "nonce": 428, - "mobile_balance": 1500000000000000000, - "iot_balance": 0, - "hotspot_count": 0, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600655, - "balance": 209859912321099, - "address": "1398hLeHESZHE5jVtaLAV5fdg2vrUeZEs2B92t7TzeQTtugr8dL" - }, - { - "validator_count": 0, - "staked_balance": 0, - "speculative_sec_nonce": 0, - "speculative_nonce": 4, - "sec_nonce": 0, - "sec_balance": 166398670100, - "nonce": 4, - "mobile_balance": 0, - "iot_balance": 0, - "hotspot_count": 0, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600656, - "balance": 83885120803643, - "address": "14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz6S" - } - ] -} -``` - - - - ---- - -### Account for address - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address -``` - -Retrieve a specific account record.The account details for a record include additional speculative -nonces that indicate what the expected nonce for the account is for a specific balance. Any -transactions affecting the given balance type should use an adjusted speculative nonce for that -balance type. - -For example, when constructing a payment transaction, get the `speculative_nonce` field for the -source account and use `speculative_nonce + 1` for the new transaction nonce.Currently only the -speculative_nonce is supported. It indicates the expected nonce for the account - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch details for | - - - - -200: OK - -```json -{ - "data": { - "validator_count": 0, - "staked_balance": 0, - "speculative_sec_nonce": 0, - "speculative_nonce": 1, - "sec_nonce": 0, - "sec_balance": 0, - "nonce": 1, - "mobile_balance": 0, - "iot_balance": 0, - "hotspot_count": 0, - "dc_nonce": 0, - "dc_balance": 0, - "block": 1600656, - "balance": 0, - "address": "1122ZQigQfeeyfSmH2i4KM4XMQHouBqK4LsTp33ppP3W2Knqh8gY" - } -} -``` - - - - -### Stats for Account - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/stats -``` - -Fetches account statistics for a given account. This currently includes account balance information -(in bones) for the last month (daily), last week (every 8 hours), and daily (hourly). - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | -------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch stats for | - - - - -200: OK - -```json -{ - "data": { - "last_week": [ - { - "timestamp": "2020-12-24T00:00:00.000000Z", - "balance": 2726587598732 - }, - { - "timestamp": "2020-12-23T16:00:00.000000Z", - "balance": 2726579175524 - }, - { - "timestamp": "2020-12-23T08:00:00.000000Z", - "balance": 2726236453934 - }, - { - "timestamp": "2020-12-23T00:00:00.000000Z", - "balance": 2726227814759 - }, - { - "timestamp": "2020-12-22T16:00:00.000000Z", - "balance": 2725942362517 - }, - { - "timestamp": "2020-12-22T08:00:00.000000Z", - "balance": 2725650289654 - }, - { - "timestamp": "2020-12-22T00:00:00.000000Z", - "balance": 2725147917954 - }, - { - "timestamp": "2020-12-21T16:00:00.000000Z", - "balance": 2724406718606 - }, - { - "timestamp": "2020-12-21T08:00:00.000000Z", - "balance": 2724056284882 - }, - { - "timestamp": "2020-12-21T00:00:00.000000Z", - "balance": 2723209316840 - }, - { - "timestamp": "2020-12-20T16:00:00.000000Z", - "balance": 2722951323859 - }, - { - "timestamp": "2020-12-20T08:00:00.000000Z", - "balance": 2722934379280 - }, - { - "timestamp": "2020-12-20T00:00:00.000000Z", - "balance": 2722897458808 - }, - { - "timestamp": "2020-12-19T16:00:00.000000Z", - "balance": 2722688076583 - }, - { - "timestamp": "2020-12-19T08:00:00.000000Z", - "balance": 2722582293089 - }, - { - "timestamp": "2020-12-19T00:00:00.000000Z", - "balance": 2722544226107 - }, - { - "timestamp": "2020-12-18T16:00:00.000000Z", - "balance": 2722495151953 - }, - { - "timestamp": "2020-12-18T08:00:00.000000Z", - "balance": 2720896037594 - }, - { - "timestamp": "2020-12-18T00:00:00.000000Z", - "balance": 2720485905293 - }, - { - "timestamp": "2020-12-17T16:00:00.000000Z", - "balance": 2719886473562 - }, - { - "timestamp": "2020-12-17T08:00:00.000000Z", - "balance": 2719278670960 - }, - { - "timestamp": "2020-12-17T00:00:00.000000Z", - "balance": 2719231394336 - } - ], - "last_month": [ - { - "timestamp": "2020-12-24T00:00:00.000000Z", - "balance": 2726587598732 - }, - { - "timestamp": "2020-12-23T00:00:00.000000Z", - "balance": 2726227814759 - }, - { - "timestamp": "2020-12-22T00:00:00.000000Z", - "balance": 2725147917954 - }, - { - "timestamp": "2020-12-21T00:00:00.000000Z", - "balance": 2723209316840 - }, - { - "timestamp": "2020-12-20T00:00:00.000000Z", - "balance": 2722897458808 - }, - { - "timestamp": "2020-12-19T00:00:00.000000Z", - "balance": 2722544226107 - }, - { - "timestamp": "2020-12-18T00:00:00.000000Z", - "balance": 2720485905293 - }, - { - "timestamp": "2020-12-17T00:00:00.000000Z", - "balance": 2719231394336 - }, - { - "timestamp": "2020-12-16T00:00:00.000000Z", - "balance": 2716992988275 - }, - { - "timestamp": "2020-12-15T00:00:00.000000Z", - "balance": 2714499571334 - }, - { - "timestamp": "2020-12-14T00:00:00.000000Z", - "balance": 2712996222990 - }, - { - "timestamp": "2020-12-13T00:00:00.000000Z", - "balance": 2703175106511 - }, - { - "timestamp": "2020-12-12T00:00:00.000000Z", - "balance": 2701913148104 - }, - { - "timestamp": "2020-12-11T00:00:00.000000Z", - "balance": 2699717238347 - }, - { - "timestamp": "2020-12-10T00:00:00.000000Z", - "balance": 2698120119399 - }, - { - "timestamp": "2020-12-09T00:00:00.000000Z", - "balance": 2696104012737 - }, - { - "timestamp": "2020-12-08T00:00:00.000000Z", - "balance": 2694835982946 - }, - { - "timestamp": "2020-12-07T00:00:00.000000Z", - "balance": 2692158753830 - }, - { - "timestamp": "2020-12-06T00:00:00.000000Z", - "balance": 2689398873651 - }, - { - "timestamp": "2020-12-05T00:00:00.000000Z", - "balance": 2687488073405 - }, - { - "timestamp": "2020-12-04T00:00:00.000000Z", - "balance": 2686193207861 - }, - { - "timestamp": "2020-12-03T00:00:00.000000Z", - "balance": 2684790604843 - }, - { - "timestamp": "2020-12-02T00:00:00.000000Z", - "balance": 2682678566170 - }, - { - "timestamp": "2020-12-01T00:00:00.000000Z", - "balance": 2680802668931 - }, - { - "timestamp": "2020-11-30T00:00:00.000000Z", - "balance": 2679059221953 - }, - { - "timestamp": "2020-11-29T00:00:00.000000Z", - "balance": 2677312562564 - }, - { - "timestamp": "2020-11-28T00:00:00.000000Z", - "balance": 2675534596168 - }, - { - "timestamp": "2020-11-27T00:00:00.000000Z", - "balance": 2674031525165 - }, - { - "timestamp": "2020-11-26T00:00:00.000000Z", - "balance": 2673184081131 - }, - { - "timestamp": "2020-11-25T00:00:00.000000Z", - "balance": 2671270944491 - }, - { - "timestamp": "2020-11-24T00:00:00.000000Z", - "balance": 2669603645697 - } - ], - "last_day": [ - { - "timestamp": "2020-12-23T19:00:00.000000Z", - "balance": 2726587598732 - }, - { - "timestamp": "2020-12-23T18:00:00.000000Z", - "balance": 2726587598732 - }, - { - "timestamp": "2020-12-23T17:00:00.000000Z", - "balance": 2726587598732 - }, - { - "timestamp": "2020-12-23T16:00:00.000000Z", - "balance": 2726579175524 - }, - { - "timestamp": "2020-12-23T15:00:00.000000Z", - "balance": 2726579175524 - }, - { - "timestamp": "2020-12-23T14:00:00.000000Z", - "balance": 2726322880219 - }, - { - "timestamp": "2020-12-23T13:00:00.000000Z", - "balance": 2726322880219 - }, - { - "timestamp": "2020-12-23T12:00:00.000000Z", - "balance": 2726306228185 - }, - { - "timestamp": "2020-12-23T11:00:00.000000Z", - "balance": 2726306228185 - }, - { - "timestamp": "2020-12-23T10:00:00.000000Z", - "balance": 2726306228185 - }, - { - "timestamp": "2020-12-23T09:00:00.000000Z", - "balance": 2726252381243 - }, - { - "timestamp": "2020-12-23T08:00:00.000000Z", - "balance": 2726236453934 - }, - { - "timestamp": "2020-12-23T07:00:00.000000Z", - "balance": 2726236453934 - }, - { - "timestamp": "2020-12-23T06:00:00.000000Z", - "balance": 2726236453934 - }, - { - "timestamp": "2020-12-23T05:00:00.000000Z", - "balance": 2726236453934 - }, - { - "timestamp": "2020-12-23T04:00:00.000000Z", - "balance": 2726236453934 - }, - { - "timestamp": "2020-12-23T03:00:00.000000Z", - "balance": 2726236453934 - }, - { - "timestamp": "2020-12-23T02:00:00.000000Z", - "balance": 2726227814759 - }, - { - "timestamp": "2020-12-23T01:00:00.000000Z", - "balance": 2726227814759 - }, - { - "timestamp": "2020-12-23T00:00:00.000000Z", - "balance": 2726227814759 - }, - { - "timestamp": "2020-12-22T23:00:00.000000Z", - "balance": 2726184001677 - }, - { - "timestamp": "2020-12-22T22:00:00.000000Z", - "balance": 2726184001677 - }, - { - "timestamp": "2020-12-22T21:00:00.000000Z", - "balance": 2726184001677 - }, - { - "timestamp": "2020-12-22T20:00:00.000000Z", - "balance": 2725942362517 - }, - { - "timestamp": "2020-12-22T19:00:00.000000Z", - "balance": 2725942362517 - } - ] - } -} -``` - - - - ---- - -### Pending Transactions for Account - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -Submitting a transaction to the Solana blockchains returns a pollable signature. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/pending_transactions -``` - -Fetches the outstanding transactions for the given account. See Pending Transactions for details.The -list of returned pending transactions is paged. If a `cursor` field is present more results are -available. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch details for | - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ------------------------------------------------- | -| cursor (optional) | _string_ | Cursor for the next page of transactions to fetch | - - - - -200: OK - -A single pending transaction for a given account - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -::: - -```json -{ - "data": [ - { - "updated_at": "2022-11-04T14:34:28.254881Z", - "type": "payment_v2", - "txn": { - "type": "payment_v2", - "payments": [ - { - "token_type": "hnt", - "payee": "13PqSH7f5e2sySibkxXiLRvkiYR5cBbCNo5Nf7zZwySzM4n6S5S", - "memo": "AAAAAAAAAAA=", - "max": false, - "amount": 654251727 - } - ], - "payer": "147UgrcgD8qD5JNpfRvz8FBZW86jZsQdsaX2zFV8GP5aUFiiLpQ", - "nonce": 23, - "hash": "p7EypW_zdOyU8pJG1k2NWEUW-10FldH7402bigTqfzw", - "fee": 35000 - }, - "status": "pending", - "hash": "p7EypW_zdOyU8pJG1k2NWEUW-10FldH7402bigTqfzw", - "failed_reason": "", - "created_at": "2022-11-04T14:33:03.060952Z" - } - ] -} -``` - - - - ---- - -## Available on the Oracles API - -### Hotspots for Account - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/hotspots -``` - -Fetches hotspots owned by a given account address.The list of returned hotspots is paged. If a -`cursor` field is present more results are available. - -The `filter_modes` parameter can be used to filter hotspot by how they were added to the blockchain. -Supported values are `full`, `dataonly`, or `light`. A comma separated list (no whitespace) can be -used to filter for multiple modes. - -Note: The cursor for accounts is valid for a limited time. If you receive a `400` http response code -for a cursor based request, you will need to start fetching accounts from the beginning of the list. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch details for | - -_Query Parameters_ - -| param | Type | Note | -| ----------------------- | -------- | --------------------------------------------- | -| cursor (optional) | _string_ | Cursor for the next page of hotspots to fetch | -| filter_modes (optional) | _string_ | Filter hotspot types | - - - - -200: OK - -The hotspot list for an account - -```json -{ - "data": [ - { - "lng": -81.70707772367822, - "lat": 41.480133219396784, - "status": { - "online": "online", - "height": 435166, - "gps": "good_fix" - }, - "score_update_height": 435153, - "score": 0.9222412109375, - "owner": "13GCcF7oGb6waFBzYDMmydmXx4vNDUZGX4LE3QUh8eSBG53s5bx", - "nonce": 1, - "name": "sneaky-violet-penguin", - "location": "8c2ab38f19a43ff", - "geocode": { - "short_street": "W 32nd St", - "short_state": "OH", - "short_country": "US", - "short_city": "Cleveland", - "long_street": "West 32nd Street", - "long_state": "Ohio", - "long_country": "United States", - "long_city": "Cleveland", - "city_id": "Y2xldmVsYW5kb2hpb3VuaXRlZCBzdGF0ZXM" - }, - "block_added": 96087, - "block": 435241, - "address": "1182nyT3oXZPMztMSww4mzaaQXGXd5T7JwDfEth6obSCwwxxfsB" - } - ] -} -``` - - - - ---- - -### Roles Counts for Account - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/roles/count -``` - -Count transactions that indicate activity for an account. This includes any transaction that -involves the account, usually as a payer, payee or owner. - -The results are a map keyed by the given `filter_types` and the count of transaction of that type. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | --------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch counts for | - -_Query Parameters_ - -| param | Type | Note | -| ------------ | -------- | ----------------------------------------- | -| filter_types | _string_ | Comma separated list of transaction types | - - - - -200: OK - -Fetch counts with `filter_types=add_gateaway_v1,assert_location_v1` for account -`13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDird` - -```json -{ - "data": { - "add_gateway_v1": 5777, - "assert_location_v1": 5878 - } -} -``` - - - - ---- - -### Challenges for Account - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/challenges -``` - -Fetches challenges that hotspots owned by the given account are involved in as a challenger, -challengee, or witness. - -The results are paged. If a `cursor` field is present in the response, more results are available. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ----------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch activity for | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -::: - -```json -{ - "data": [ - { - "type": "poc_receipts_v1", - "time": 1608740853, - "secret": "AEGM923859xCnALUTWtVzYIkRKXAL4E0Ss1JRchMhhMdBOhuXOob79UwlghHhEZN2ChZe7vvnltg8Z2D-adlb-kkL-hv_ONvpcsFXPw9y_LYzIwTS7TAIVbqKfuBn_IVRcc", - "request_block_hash": "JTUr-_hX--L6TuwIkx-DEzeB--yMheo2Ud-yZ4LNVt4", - "path": [ - { - "witnesses": [ - { - "timestamp": 1608740090285495600, - "snr": -9, - "signal": -100, - "packet_hash": "p2ZijVno8DHGJui_bV6u-tABHQOiEB_c3NCFOv_-1xE", - "owner": "146MwmL9eJJCdrykbgdL3dobdChP4Ut34mCZMR3Hv9HXTeBJQzC", - "location": "8c44a105ca1d3ff", - "is_valid": true, - "gateway": "11fJaz1xwA2Xh1gQQWRh6FzDabEPkLs5bSMdDnSrb4CL1L5Y5Su", - "frequency": 905.2999877929688, - "datarate": "SF9BW125", - "channel": 7 - } - ], - "receipt": { - "timestamp": 1608740088868575200, - "snr": 0, - "signal": 0, - "origin": "p2p", - "gateway": "112V5U5MSMVBDTe6cCzWEXzuCbjK96GbKXwDPFSCyjeVnL3wHk5L", - "frequency": 0, - "datarate": null, - "data": "5_w", - "channel": 0 - }, - "geocode": { - "short_street": "Leslie Dr", - "short_state": "FL", - "short_country": "US", - "short_city": "Hallandale Beach", - "long_street": "Leslie Drive", - "long_state": "Florida", - "long_country": "United States", - "long_city": "Hallandale Beach", - "city_id": "aGFsbGFuZGFsZSBiZWFjaGZsb3JpZGF1bml0ZWQgc3RhdGVz" - }, - "challengee_owner": "1444k99dYKjngxQnqGxrB3CmqaFdGzPRWsxqbbu3LjjCyBocGhi", - "challengee_lon": -80.12177083059214, - "challengee_location": "8c44a10564825ff", - "challengee_lat": 25.9903614158387, - "challengee": "112V5U5MSMVBDTe6cCzWEXzuCbjK96GbKXwDPFSCyjeVnL3wHk5L" - } - ], - "onion_key_hash": "I86cUPLZ46naXW6IFhhXGVFeKftMi4FhtpsJwtW03T8", - "height": 644070, - "hash": "Z5yrO_XbwTT89xFjA1_3OlSke1KmkJ7VZmigd7NDVk8", - "fee": 0, - "challenger_owner": "13GCcF7oGb6waFBzYDMmydmXx4vNDUZGX4LE3QUh8eSBG53s5bx", - "challenger_lon": -81.70707772367822, - "challenger_location": "8c2ab38f19a43ff", - "challenger_lat": 41.480133219396784, - "challenger": "1182nyT3oXZPMztMSww4mzaaQXGXd5T7JwDfEth6obSCwwxxfsB" - }, - { - "type": "poc_receipts_v1", - "time": 1608739733, - "secret": "ABCXJG0PUoO0iyTzvmd-XPVfJdPW3HBztPWjld7TLvOtBA-1qOjN6UNWkVmPp69FkUrnqZmJr1Zz-H-4v1lu7HGaABQ0p3X_Ge4hNZ6b2SpijiqUYf7i9JjgxzwMUtvy8bg", - "request_block_hash": "pO2v0ZyCEOYRZy7SXcsb2fGvTvfYRUxAlz4NHLG1H44", - "path": [ - { - "witnesses": [ - { - "timestamp": 1608738987154888200, - "snr": -11.199999809265137, - "signal": -106, - "packet_hash": "zgFKUHVz-ZZa-Wk4h_XwCtB9TcJGvBZRNynSTMaEyis", - "owner": "13s2SCJbWP9ZmGW5uULCehV7EJRDdYqLrmNCQCtoj5Y1RDerZAq", - "location": "8c2ab38f1d5c9ff", - "is_valid": true, - "gateway": "112GGQtavNrmWhEoLd5ABF1fbfXLccS747ez1dZHoh9TvgjJw29p", - "frequency": 904.5, - "datarate": "SF9BW125", - "channel": 3 - }, - { - "timestamp": 1608738987176681500, - "snr": -5.5, - "signal": -106, - "packet_hash": "zgFKUHVz-ZZa-Wk4h_XwCtB9TcJGvBZRNynSTMaEyis", - "owner": "13s2SCJbWP9ZmGW5uULCehV7EJRDdYqLrmNCQCtoj5Y1RDerZAq", - "location": "8c2ab38f1da8bff", - "is_valid": true, - "gateway": "11uHyX8PJhk7kqRiW2JaF2dR2PGVX8vB7FcQXVW6M1rY2BbuQHU", - "frequency": 904.5, - "datarate": "SF9BW125", - "channel": 3 - }, - { - "timestamp": 1608738987229829600, - "snr": 3, - "signal": -119, - "packet_hash": "zgFKUHVz-ZZa-Wk4h_XwCtB9TcJGvBZRNynSTMaEyis", - "owner": "13GCcF7oGb6waFBzYDMmydmXx4vNDUZGX4LE3QUh8eSBG53s5bx", - "location": "8c2ab38f19a43ff", - "is_valid": false, - "gateway": "1182nyT3oXZPMztMSww4mzaaQXGXd5T7JwDfEth6obSCwwxxfsB", - "frequency": 904.5, - "datarate": "SF9BW125", - "channel": 3 - } - ], - "receipt": { - "timestamp": 1608738985817671400, - "snr": 0, - "signal": 0, - "origin": "p2p", - "gateway": "11nCHecDUTkDxMNfAuMjF8cev7bfoKetWj4Y1MWDoSstDGhbMSs", - "frequency": 0, - "datarate": null, - "data": "W1k", - "channel": 0 - }, - "geocode": { - "short_street": "Bridge Ave", - "short_state": "OH", - "short_country": "US", - "short_city": "Cleveland", - "long_street": "Bridge Avenue", - "long_state": "Ohio", - "long_country": "United States", - "long_city": "Cleveland", - "city_id": "Y2xldmVsYW5kb2hpb3VuaXRlZCBzdGF0ZXM" - }, - "challengee_owner": "13JyFksMcfyMTpycMy1XStssPWcQJut61n68sMUhG1cJQBmwUWi", - "challengee_lon": -81.70946661837299, - "challengee_location": "8c2ab38f56003ff", - "challengee_lat": 41.48413978192872, - "challengee": "11nCHecDUTkDxMNfAuMjF8cev7bfoKetWj4Y1MWDoSstDGhbMSs" - } - ], - "onion_key_hash": "doMVn-c8K7SnduqUU4CJFGloUeAMB0pYRcOkTrAyt4Y", - "height": 644054, - "hash": "QKjdegKY_muFONmC3mbwKjlCP4BaR9zCsXZSanKQWgY", - "fee": 0, - "challenger_owner": "13hc8BeaE5kUiMYW1FLU8dnV4t2XUM4sWxHxM2E34NF3tnJdiXj", - "challenger_lon": -73.93747871760092, - "challenger_location": "8c2a100dc6dd5ff", - "challenger_lat": 40.697659486078635, - "challenger": "11eqcRNEgAk7vioFtgtTWUERyV98Vj5iDEm75YMbUCS3uaLKFXR" - } - ] -} -``` - - - - ---- - -### Rewards for an Account - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/rewards -``` - -Returns reward entries by block and gateway for a given account in a timeframe. Timestamps are given -in ISO 8601 format. The block that contains the `max_time` timestamp is **excluded** from the -result. - -The result will be a list of rewards between `min_time` and `max_time` both given in UTC. Both -default to "now" which means that at least one of the two parameters is required. - -The result includes a `type` field which is the type of activity that generated the reward. - -This route is paged using a `cursor`. - -:::info - -For older reward results, if the `type` is `null` the amount is a total for that account or hotspot -in the given block. - -::: - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch details for | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | -------------------------------------- | -| cursor (optional) | _string_ | Cursor for page of rewards to fetch | -| max_time (optional) | _string_ | Last timestamp to include rewards for | -| min_time (required) | _string_ | First timestamp to include rewards for | - - - - -200: OK - -Rewards for an account with `min_time=2020-08-27&max_time=2020-08-28` - -```json -{ - "data": [ - { - "type": null, - "timestamp": "2020-08-27T23:55:45.000000Z", - "hash": "HF7qP3usRFFhjcSajGRElHGdQOzUS47UJfSeYRGA-1o", - "gateway": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "block": 470714, - "amount": 8650492, - "account": "12xUoMKwf12ABjNx4VCvYcNkX79gW1kzz2JnBLxkFbjswRczRvM" - } - ], - "cursor": "eyJlbmRfYmxvY2siOjQ2OTUzMCwiYmxvY2siOjQ3MDcwMCwiYW5jaG9yX2Jsb2NrIjo0NzA3MDB9" -} -``` - - - - ---- - -### Rewards in a Rewards Block for an Account - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -Reminder that parsing is done by time, not by block. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/rewards/:block -``` - -Returns rewards for a given account for a given block. - -The result includes a `type` field which is the type of activity that generated the reward. - -This route is paged using a `cursor`. - -:::info - -For older reward results, if the `type` is `null` the amount is a total for that account in the -given block. - -::: - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | -------------------------- | -| address (required) | _string_ | B58 address of the account | - - - - -200: OK - -Rewards for an account in block `470788` - -```json -{ - "data": [ - { - "type": null, - "timestamp": "2020-08-28T01:29:46.000000Z", - "hash": "DTU1GGfR0eU15hv6KiV_bg6FOJXfUWz4TjIq1H7TGy4", - "gateway": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "block": 470788, - "amount": 7885016, - "account": "12xUoMKwf12ABjNx4VCvYcNkX79gW1kzz2JnBLxkFbjswRczRvM" - } - ] -} -``` - - - - ---- - -### Reward Totals for an Account - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/rewards/sum -``` - -Returns the total rewards for a given account in a given timeframe. Timestamps can be given in ISO -8601 format (e.g. `2020-08-27T00:00:00Z`) or in relative time (e.g. `-1 week`, which when url -esacped becomes `-1%20week`). When ommitted the current time is assumed. - -The results can also be bucketed in time by specifying a `bucket` query parameter which buckets -information per bucket in the given timeframe. Data is bucketed per hotspot and time for the account -to make hotspot performance comparison possible. Valid bucket values include `hour`, `day` and -`week`). - -For example to get the last 7 days of rewards bucketed by day use the following path/parameters: -`?min_time=-7%20day&bucket=day` - -The block that contains the `max_time` timestamp is **excluded** from the result. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch details for | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| min_time (required) | _string_ | First time to include rewards for | -| max_time (required) | _string_ | Last time to include rewards for | -| bucket (optional) | _string_ | Bucket specifier | - - - - -200: OK - -Returns the total rewards over a given time range - -```json -{ - "data": { - "max_time": "2020-08-29T00:00:00Z", - "min_time": "2020-08-27T00:00:00Z", - "sum": "176714898" - } -} -``` - - - - ---- - -## Deprecated Endpoints - -### OUIs for Account - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. This data can instead be collected using the Config Server API but is -no longer defined on-chain. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/ouis -``` - -Fetches OUIs owned by a given account address.The list of returned OUIs is paged. If a `cursor` -field is present more results are available. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch details for | - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ----------------------------------------- | -| cursor (optional) | _string_ | Cursor for the next page of OUIs to fetch | - - - - -200: OK - -The oui list for account `13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc` - -```json -{ - "data": [ - { - "subnets": [ - { - "mask": 8388352, - "base": 0 - } - ], - "owner": "13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc", - "oui": 1, - "nonce": 0, - "block": 762440, - "addresses": ["112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE"] - } - ] -} -``` - - - - ---- - -### Roles for Account - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/roles -``` - -Fetches transactions that indicate an account as a participant. This includes any transaction that -involves the account, usually as a payer, payee or owner. - -The results are paged. If a `cursor` field is present in the response, more results are available. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ----------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch activity for | - -_Query Parameters_ - -| param | Type | Note | -| ---------------------- | -------- | ----------------------------------------- | -| filter_types(optional) | _string_ | Comma separated list of transaction types | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -```json -{ - "data": [ - { - "type": "rewards_v2", - "time": 1643683979, - "role": "payee", - "height": 1207030, - "hash": "6A_8hid6ZIiyg32dzQwFajM-iDyAvYJdVccSpxyymi8" - }, - { - "type": "rewards_v2", - "time": 1643624875, - "role": "payee", - "height": 1206107, - "hash": "FQnpxKBulLblJqSMsbgGbmv8ZHmu_2z4XJIeYKJGuIo" - }, - { - "type": "assert_location_v2", - "time": 1643622489, - "role": "owner", - "height": 1206070, - "hash": "yaEqGXHWOtElgG2RpaTuop2cwFaRypPIaOtsd11hPeQ" - }, - { - "type": "add_gateway_v1", - "time": 1643622489, - "role": "owner", - "height": 1206070, - "hash": "-I__6qbqiopjMd94Zi94ixO-vyqFMeZdn0t2TRiTEjc" - } - ] -} -``` - - - - ---- - -### Elections for account - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/elections -``` - -Fetches elections that hotspots for the given account are elected in. - -The results are paged. If a `cursor` field is present in the response, more results are available. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ----------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch activity for | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -```json -{ - "data": [ - { - "type": "consensus_group_v1", - "time": 1608276577, - "proof": "g1AAAAdHeJxF1Hs403scB3BWZIdDuQxzadTRcctPSO5iLqedI3ILMwxDmEs4p6whSTEqyrbsnCNMSCObueS2Vi6VS3I8Cp1OF2zusllhzvpj_PX95_08r8_n_TzfT5yEhMT-aFC86NGRwI9ayb7Ga3lcJh9L0qTkHXXTzr0HL1YSTO5lofGR6DvfU26AC0hHgrZ968eJF4KzjfhZcqHsq9FQiDbfIAwZfzWO-s_GSyQPBAvu9PkmlT5U4SBpziI1YK9EZZNrZzy-DTu5_5CJOQs3E5urJbDq5UVW1ifX0s4CqeduzYBzvw3lRhcgs6cOnA_gxCbMc9tU8TBXcWLDXmi0gL6kKDtqbvXA-ogHm5asq4k7ZCCaql21vQnp98hV_8_Fr4duN7XFpZgBi3gpKWX-pUDV95mqYjPOIv55Q-o2CpY6NtDeL2ArzIQQaertsFGjA8cslzmGO2YGvmH-Yf7fI3OWl4suvAxyOf22kK5tdOpnrvq1WdL21UqRWVJYZsJcCKoO13N6qon3DfCOfbJWHBYRN4TunpmQnbQUm8waaIO97appqLcX-yr2K7-LPTemCkvKq3ceP7RWA_HbMR3tsEfzvSN1CcoXx7D7KsMfMytU9yAXN7jFjqiCntu2IvNNzrevvJCbuNx2_mjSIjViwd_n2eCyCfCOmOAyBa2-JDYJnh82U4tyAGx2R4ulpFvX6B-NMYbtcGiJ0mO4xrs3WzumkkabPiGELzE-ciI7mQzgpnv-m1kCy1sfTy5A2ASXhYrMvhwBPD37Sm-JxMHgoG71dORWfxPeawaTP6z7PsDmk5rY_IHoKL1pO55BYGk_dpf1Znkaadw2-2Mf0boporKsu1ZuxzQn7g2P-sIFC-IpaPDWPR9gJKXup6gqoWkgO2jmRO-GyCQNIkiOLTJqbbJawFxa8786Foot8heF0bqLf8OJkQeWxKbRBy6mQiNxHFcw88C-3Z-gAyWjDRhJMdG8giTcEtPhe8oVgINgGrg6qI1ePUHtnLK3D73xLcbjdzdml9C42EKh1nPl1HkQzLq17jM_uvXHSsMi1uz8sTuJZueuSWZJywG_XWCWGyg6icktzBKcONINuS1EaBK-GDZ4rTdP3al25FmT2F-mafJV31PugKtoiQ0TOFcbFd6pwZGbBrPNnF9PMko-eCebTrk4dfZK6N343u21EU7xOPXVMCjjs9qiuhmwdn3vSUTfxK2zMiCi3QpEjP5Ll8su_GkPZfDyJatwq9cJtCs1KgxlSPkhJU4Um1cSstPtea3fwPgulyjrDNMIVULwfbPkWd7NM84G695IQWl3spbIpKZUXbCf3bfFA1B3H4LnSa2-vneHQy1cqz9rK1uknbMQm95BYPq9FOwZ0MJH81dHL5yW-vi0z9lKf8XPv8PDONtauHsTBnKGgAKbesgpbaU3jV9ttc80evnbOHZa6dLT4mgn3kJBMB_odf0y30wHGgB1LT2-UF-rz94_tOWe7m4WIwUJ9xGITVAgarxJYRpMVoupGS4mDef1DGRhOlKsuI9PnbZ-RNLaLXcKNdFzFHqP4WGy2heByqzm2hsvVdk9H2SsliLuXzzsLIpURQfWD0qvZabH5BXue3knB3er9KIm8_ikwn7I3LpJkbsY9eosDPVrApJ0wmdM0yq3InI9s5ZWY8OWqyzdYpB-NMEumptHf9hYGpXLw2EKKzL3q6j4zyrYTFelum79XmyXVnNCFLmV7vICT92kv6KUy9ycH7FTiaNFFjVIEEKiZt87vCiPFaMK_LmR1z4wAZ91TV2BQ1N6hm0ZW_aV1EL14Jrjbbs4u-0O24UGxGxWAj8fDGzSIHZQOj7KM39t7ZmrMJdjLVAYiSBYEg08GvqA8d86echrm9e_csw4sQeOQK_HCGqFe36R44jNywNZ_Hya3wirsvhu95DlmCHHJEt5NjJiOwHNTHiqwdv5LTIqG2VCLQopt41atJWKNMEi2uyff-gNroh_NJlYiMCCYAeaVB16GHW6BlRtB5sznF6VAMkKsnxTUlg1yog-bf5UTPp-mouFdgSYdrBHMQwNIoFYN57qLx0Ad9p8EtHP15_bXZOkgz_4jnukL-PPK-9B59dw6w4v_agIP4uPnU4HWzB5BSAYzLWMyA0bpkc3Q8DKSa3LA88SKjawieRVXBzaOkx6XmwiNxv0INkrD4nBb2DMFgKtumWZ-m5R7y9MWn6vXMeA-u7xO2wh74gLkgbL4KjIX5PpTHQ6AvRWQe1RF_j8-I2VRNFUtUPsctTggyP3p4ztVQWHIREnO-ueFMVSLC0Hrpd_wgjP_Q_ffiin", - "members": [ - "112qqYc77fYcGLYrD5Bd1zG1dwoXGCzaQ63oby8ws9mhDrhieTRv", - "11hxEKmhr2xgVu8srSdkmoQYNVYYKppKd82mtanBbU5kd9r42hs", - "11LmZdUgSn5Pwa8a2Q16EUDfyLutpDeQoUgzgerHJc73p8NTC3V", - "112374TV64PVuBDDArCymuiqA6AQdNr3q9JVthoYo5r9kBCS6N3", - "1124oBcVaT6pubZWxuPisQs8hNKaYp9cduvQ9skcpRmt14LnhsnX", - "11eq43bdC6iAsQJtSsxbEwZZP9ECZX7QYnWXn95uc3Ajym9bdP6", - "112vbpLrhj8kQdBn8FDBYR2KcXVh95HmPfgyZfuA8kL5kRKVEWyc", - "112hX6sPHCgYXP98tdac5TqPNfU17t3K8ZwdpLd1UfFSD8Xoqv3H", - "115fXeCtfk9FjpoNXn8QCikp1GVGgGg2S5BXq8RJovcDvFrXrL8", - "11xrgEdiN9DA2cyauB29AXDy8WoMEwhqaL1chU83YWGx7q81sp8", - "11d13u5TospVvAD8pGCYNZR3GrEykB4osswni5fcXnonfHDSEpG", - "11diD2YbFNJ4yHDoWZpJErdJmwRsGEepCteEHfFMwakrTxjvMRG", - "112PSpVub6tJxekGMF4N3wp7Yb883pPWiF4WCw9BeuugXJucGZqB", - "11pf3gLhyFPRCedRPngEUu3Rr25sRYi16WRRS1ZYsA6hGMpkaXU", - "11zcBW5mQx2iJbNUg3MhvUEVbnB7Ty4dFL7Pgt2qvENZiNSotuV", - "1182nyT3oXZPMztMSww4mzaaQXGXd5T7JwDfEth6obSCwwxxfsB" - ], - "height": 637456, - "hash": "mKX9qDdsbbHfkllXZJPmDnaWftsHeFxodSfyTPTSPMA", - "delay": 5 - }, - { - "type": "consensus_group_v1", - "time": 1607829748, - "proof": "g1AAAAdAeJxF0nk81IkbB_DxDZspsTFj5PqOa8XkmoZhLIZhpNySKzYy5Mo1SGKw5MiZIwxlI-YnJqac5UghlN-Oe2VD_LDGEZqc-emPmf3r-efzer1fn-d5_CEQiLAPEHA0kBAh9jJzyB7cZncmiwst1Yq8DWwaXb_MI-XWHd0YoNe-9CNlqk4AQAOqgbh50QFmI5Kp_3VTCXFyOOmbrs0pmt1tefcoKm82AGKiy_3Lr8_bmZ1krVea5ZI8WG6f0ZpN45I5zGCJM7pwDqmCLqpGZDWDY51dzX9IxooIRVS-C7vl-vfIaFR6-zQ55kfKTN0UQEIWYmPn2HE_X9VlwqvHpyEU0TXGUzquVAvVYf3wsmWW31GkTPDM-mQwYz1q-3mXyUcPwsxcNK3G4r4w_p-B3F0h4zgOylgDzjfx8wvwLkbYlyB08Gnza5jJtRcDend7JyMe1m5xe2ram_Hgf_uwTVGr6VNyoWwKUij-D0zmbXpZ6jTcBVseAAzB3kg77eq_FzD_UhtDlihEiRqv89992AwPn8A7a9MdOGRzptCrxy91zFRp29WOSS9Las9lftTPXbXqPrco75cKq-OS0Fq4Uv59Z3mPnZTcleE0JHaAkLqbLmqNeGCbiVwtqAfAIHP9Te1Cvs-GKLV7MpJTlinzLFtrTcQMIuep4EkXArflAY7xrTFD5aGyBk9JlKT7PjEbfrgTautxwSWF7bTr2PMjRVQ3AUBDimV_3tn2WGxseW7VqgI8attd-8NysMvX8GLUtY3WhaPN1hLn0svarhokH0KGxiPZPzVgze0QEdCE4gUFmUQfnSKOKVf8Aj2AluEF0oYvYuXqQkdLKqETig0nnj_plJjwCV7imp4dQS4336igMhRUvl32tz-t3Nq6WZ-b73BtJ8rO0YqVf2SuTGNJyAPlDvtH_SfNvd5q1PMcOPJn3RpBa-ChqQreORxzh68zaOubbyGx73a6qN5u_pdPnR-Dyn0TparvMFBKsBzuaiXv8H2JjOha45-JzhIND6wzPz6ncvP5TT_cMgEu_tgNB4AK_ego2nSIsDDrU7j3Y9jGg_Phw8GvWj7oxruZeSrqm3NIAatLoVcrGKWk-KfP5a3yvKpijdoyQv35W5LDyjv4q_r__dqhzrkPTnVSytmWj1U-7wyZylu80Y2GkmLRjNmumRMEp6PIX8fIzdTj5Jmhcniiwb2oQPk_arZaPIstsHVO0HwV3rMc9CI58qpmSLUNRqnooEjv2UQTkneS7iXo6vyxV9dgPIDK7WmUerPmN9n3S-6xZ1jltnp0_lnZhEv7pe6D0LYeq0IbBwB0qd1CXBr8UnvhzQhhr1Slqo_pYrkHTaMJ-GhbtOvIZ3DIXwgNi9R7OOFJI5K4qOkTdcuznSsLX8BG_aS0FTjLNPDfno1jsnNxIh3f8-OW70rTM3suHuxXaOiHGOQJtRh6JZitH0V69bYrYnpo0rqNWXggSBslTdQ8rQCaZFfGA7t4i20ZDvrsUHWYHWm4kT_rqfqoi1iHO7Vh_bt48s8IvqATbPGV69wfso1eIkt00MeV1fbwKdRmI50_8Q0nNmNkzTKqxLI6Mm2PzLGY0VZ0PZg9cAPULAElRu6IGOeEA3KwGUNrY7_DUirHFJMuel9RSjVnrGOKM5PsVh2anXa8eeuQRp5kknmF7VOOiYTMZq1mrLSL5cV3hyWUFuQZYlIUFwcnZn-KN73xH74h6SoAlLq898Ak5J8GxRZFy8lTG2nvy3K0pJT1AsoiBYZTjftCOKZSmZ8yOgV-ilgRoa2Gp4XtetiEHgvW0j004UMGer7Dcu95B0lyGlAM1rxPQJPqnVFeJCOpqA7XwoQYXPct5lDzAACam_oCC8eu9ZdVv2AGFfye_exKmKVWxmgihrgtbDYFQ3FIG4B9vQx3zbbO74WqGnn_9WvcFciIxpi_tNUrbMrfrx9xSQ1_9dv0OSNHFZrlse2xiK24830JwRTK56mIwEGC4T4fABJXFb_nYNAW00liuZVNWahxjRqtd0bQHPFLfoycniuqHHL1vXhFsuMmHe_EU8D4n6RIcUlvYxvsL3kHCoM-iQA-cUk3I1bGlunaV797lD9fKX8iEKckL6Ql7MxGqvlA1iMFCwDw-JNO01vjNJu8aWavmOi5g5Bfy2Gw0NGhROwYKh1848khjxML5VqboXJTNd0YxjyZ3lutX9Lx_S2MzT58AktOGeCSUisTiyWPfsnM_69vFtXh12mDLQR1efCcjvWEzJhmG2oZAFHrGz6uMW9nyry_M1lht8E2byY_yeXQGaaTKitAdlHz_T_1TBOF", - "members": [ - "11GgZk795fcucYYaCz6f3iXJpR8iA5FVBJFgYzFbdeciXVacrke", - "1182nyT3oXZPMztMSww4mzaaQXGXd5T7JwDfEth6obSCwwxxfsB", - "11aEVjsaJN7gfjggGvFuGEgixQVRtkWzEpzX15YHiZJkLSsuwdv", - "112Lx9Tren485XT7PvY7GHnmUVMTvyjwZ6hrxL7ozeDvqE7Jy6pA", - "11L2XXdnBjVmJiyb86yLyhbkg75VYEjSx9D6qMKYdsS3mnJzXoS", - "11JtrTKA3wGNE2Fgep5HLC2B3YTRDsAt4vNc7GEsVp8Y7nYKGz1", - "11JJ4RR6oPbpVouU1rzkRQC9T4VavDZrbbPaes8FVoD33uyxHQV", - "11cgLFT851vXJT4iAno1G89kct7qVM4H17EYrbJmZBuJhAyuvgD", - "112vXW9jvfNKVzWGfMYZhEmBxbGVro5iNZmUWiermAXgRebac3Pa", - "112NFATPKh4y7dXudyM9NwFwxzoLYHbX5eFzMjbQtCXTnQJrL1Ze", - "11BBZMfB8c8L3V5YVQ8KSTsVF9gx5HFcDyB5c2S1E2g86w7UPdc", - "1156oi8swcmxmR4RGM7fGHFA2JP4Lk4UjXL11tcxZQGCqfh58Po", - "112tfwpKvCqwDfzsfyAnQwj7gbmx59zKCKDaxBsmCZ4pPBd8Gasv", - "112QirNzqW2LuGAuorXA68mr9qiuWnaEALFPkeBi5AK5S5gccRjS", - "112pArcjJA6mPKAFVifkK84YVkVUro5iWh2TSbTwBcV7xrsyQyQ2", - "114eVcYfr3ujqUGsEKs1pJQQGAJTA5Lf4JgG9BjVmKnodr41Q5q" - ], - "height": 629706, - "hash": "c8gPYHwWpEGHMLhDynUHHw1k-qhW61JBPW8Q4kTlic0", - "delay": 5 - } - ] -} -``` - - - - ---- - -### Validators for Account - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/accounts/:address/validators -``` - -Fetches validators owned by a given account address. The list of returned validators is paged. If a -`cursor` field is present more results are available. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ------------------------------------------- | -| address (required) | _string_ | Account B58 address to fetch validators for | - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ----------------------------------------------- | -| cursor (optional) | _string_ | Cursor for the next page of validators to fetch | - - - - -200: OK - -The validator list for an account - -```json -{ - "data": [ - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.17/tcp/2154"], - "height": 57692 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.99200439453125, - "penalties": [ - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "shallow-butter-shark", - "last_heartbeat": 57777, - "block_added": 50636, - "block": 57780, - "address": "1Z9zkkswtjmrHsu7XK21rdxprwhNmhqpX4NirghEynauaohVjYu" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.16/tcp/2154"], - "height": 57662 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.3520050048828125, - "penalties": [ - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "amusing-sepia-caterpillar", - "last_heartbeat": 57771, - "block_added": 50614, - "block": 57780, - "address": "1Y8Rr9WaEcQBWn7Jh7QnXrctZ99a15PQEpoLQHCNTeZcDY5ziA7" - } - ], - "cursor": "eyJoZWlnaHQiOjU3NzgwLCJiZWZvcmVfYmxvY2siOjM3ODQ4LCJiZWZvcmVfYWRkcmVzcyI6IjFiSEwxblFQNWdSSHFKRVN2VFJXWHAzZTg5RnVYNXZwWnFBdGl1NlUxaVZlSERxenU4TiJ9" -} -``` - - - - ---- diff --git a/docs/api/blockchain/assert-locations.mdx b/docs/api/blockchain/assert-locations.mdx deleted file mode 100644 index 1b52602e5..000000000 --- a/docs/api/blockchain/assert-locations.mdx +++ /dev/null @@ -1,138 +0,0 @@ ---- -id: assert-locations -title: Assert Locations -pagination_label: Assert Locations -sidebar_label: Assert Locations -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/assert-locations ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Oracles API - -### List Assert Locations - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -Filter all transactions for the -[Helium Entity Manager Program](https://github.com/helium/helium-program-library/tree/master/programs/helium-entity-manager) -by assert location transactions. - -::: - -``` -GET https://api.helium.io/v1/assert_locations -``` - -Use this API to list `assert_location` transactions. - -This route is `cursor` paginated. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -Return a page of `assert_location` transactions. - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -::: - -```json -{ - "data": [ - { - "elevation": 0, - "fee": 55000, - "gain": 23, - "gateway": "112tfWD6YdC6xR22VT2D5Sbi98R5ixTUtDuDAzagv4Xz8wAjCTf4", - "hash": "yF8KGoIs_08GvA_IGL_L9DVem0SUNehr5kFcxDkDPWc", - "height": 950804, - "lat": 38.91382465500603, - "lng": -77.12481928707234, - "location": "8c2aa84c195dbff", - "nonce": 1, - "owner": "13uBLKd9B4CppL3tQq2W7jENQVygGZg3ou7dwoDdUjTQcoNBYm4", - "payer": "13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDirdY", - "staking_fee": 1000000, - "time": 1628021279, - "type": "assert_location_v2" - }, - { - "elevation": 10, - "fee": 55000, - "gain": 28, - "gateway": "1123Py2LUM13aLsCtfBpxhjxrrSWFuPujr6PNdW9Ro1TE5v8YMUH", - "hash": "zkjMS4CCfs4w0XFmim7lNZmVESCjUsbkWB2ExzicLZ0", - "height": 950804, - "lat": 35.86088843248591, - "lng": 14.485309777200525, - "location": "8c3f304ee6cb9ff", - "nonce": 3, - "owner": "13xXTxcpkFmH2tcjZy22441tMEy5AmfNokGP4ndbFVJdeoZbdoe", - "payer": "13xXTxcpkFmH2tcjZy22441tMEy5AmfNokGP4ndbFVJdeoZbdoe", - "staking_fee": 1000000, - "time": 1628021279, - "type": "assert_location_v2" - }, - { - "elevation": 4, - "fee": 55000, - "gain": 30, - "gateway": "112EywgXfCWKfygcK1zGiYbWxXKHza4DuGf8kRAdtXkXWekMN5p3", - "hash": "ZuhUWAgMaTuLrgI3wtKyl7pbZLDX6w9dFxI3bp0QqQI", - "height": 950804, - "lat": 51.20481267630534, - "lng": 3.262542526481705, - "location": "8c194d104cf67ff", - "nonce": 1, - "owner": "14UrMw4DcEy7TJQy53SJmjMkDLAGjTk4L5FXv7NMmfeN7vCJyME", - "payer": "13Zni1he7KY9pUmkXMhEhTwfUpL9AcEV1m2UbbvFsrU9QPTMgE3", - "staking_fee": 1000000, - "time": 1628021279, - "type": "assert_location_v2" - } - ], - "cursor": "eyJ0eXBlcyI6InN0YXRlX2NoYW5uZWxfY2xvc2VfdjEiLCJtaW5fYmxvY2siOjEsImJsb2NrIjo5NDM0MDAsImFuY2hvcl9ibG9jayI6OTQzNDAwfQ" -} -``` - - - - ---- diff --git a/docs/api/blockchain/blocks.mdx b/docs/api/blockchain/blocks.mdx deleted file mode 100644 index 7bc65f116..000000000 --- a/docs/api/blockchain/blocks.mdx +++ /dev/null @@ -1,984 +0,0 @@ ---- -id: blocks -title: Blocks -pagination_label: Blocks -sidebar_label: Blocks -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/blocks ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Solana API - -### Height - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -Gets the current height of the blockchainn. - -If `max_time` is specified this returns highest block height that was valid (but not equal to) the -given time.`max_time` can be given as an ISO8601 timestamp or relative time can be used. - -``` -GET https://api.helium.io/v1/blocks/height -``` - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | ------------------------------------- | -| max_time (optional) | _string_ | Last time to include in height search | - - - - -200: OK - -```json -{ - "data": { - "height": 644081 - } -} -``` - - - - ---- - -### Block Stats - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -Get statistics on block production times. - -``` - -GET https://api.helium.io/v1/blocks/stats - -``` - - - - -No Parameters - - - - -200: OK - -```json -{ - "data": { - "last_day": { - "avg": 62.31024531024531, - "stddev": 27.476995228717882 - }, - "last_hour": { - "avg": 57.04838709677419, - "stddev": 14.35889787468274 - }, - "last_month": { - "avg": 60.905921680993316, - "stddev": 45.412766632370634 - }, - "last_week": { - "avg": 61.16405380803075, - "stddev": 28.40161296349413 - } - } -} -``` - - - - --- - -### Block Descriptions - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` - -GET https://api.helium.io/v1/blocks - -``` - -Retrieves block descriptions. Blocks descriptions are paged. A `cursor` field will be in the -response when more results are available. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ------------------------ | -| cursor (optional) | _string_ | Cursor for page to fetch | - - - - -200: OK - -```json -{ - "data": [ - { - "transaction_count": 25, - "time": 1595978521, - "snapshot_hash": "", - "prev_hash": "BLlAdSn-TV2SLQzj-52UYRckLCE-D5BrZir09eVEEcQ", - "height": 435215, - "hash": "qqLVA7QELYoVFE0hoTUFy-5ZR6pPueORPYU3N8rLoQs" - }, - { - "transaction_count": 118, - "time": 1595978467, - "snapshot_hash": "", - "prev_hash": "NiK7bLdPOopqKQ8m0HF-Da6gK_UvRlypPgnjOFEooBg", - "height": 435214, - "hash": "BLlAdSn-TV2SLQzj-52UYRckLCE-D5BrZir09eVEEcQ" - }, - { - "transaction_count": 83, - "time": 1595978414, - "snapshot_hash": "", - "prev_hash": "xEsMbaiIjK_LLChHdEG78X7vsrl1CZOStEB3GHGe7g8", - "height": 435213, - "hash": "NiK7bLdPOopqKQ8m0HF-Da6gK_UvRlypPgnjOFEooBg" - }, - { - "transaction_count": 39, - "time": 1595978361, - "snapshot_hash": "", - "prev_hash": "m34Ky28U-Eqy7FjSYJ5hCXs9dRCfyPKuJoQT2F52bBA", - "height": 435212, - "hash": "xEsMbaiIjK_LLChHdEG78X7vsrl1CZOStEB3GHGe7g8" - }, - { - "transaction_count": 111, - "time": 1595978305, - "snapshot_hash": "", - "prev_hash": "C61I8DM_sq6nXNxVo7oNkV67GMzRpU21eOTrb3cRPz8", - "height": 435211, - "hash": "m34Ky28U-Eqy7FjSYJ5hCXs9dRCfyPKuJoQT2F52bBA" - }, - { - "transaction_count": 80, - "time": 1595978251, - "snapshot_hash": "", - "prev_hash": "DFy2DrhBjXg_9me2tj5lYso1WSD1In-5TBEsxMdKCTc", - "height": 435210, - "hash": "C61I8DM_sq6nXNxVo7oNkV67GMzRpU21eOTrb3cRPz8" - }, - { - "transaction_count": 60, - "time": 1595978198, - "snapshot_hash": "", - "prev_hash": "MyTG04W_ShUktv34KIeQVeomGBIET_SHU2IAM7KQCtg", - "height": 435209, - "hash": "DFy2DrhBjXg_9me2tj5lYso1WSD1In-5TBEsxMdKCTc" - }, - { - "transaction_count": 101, - "time": 1595978145, - "snapshot_hash": "", - "prev_hash": "5LHAyQ5GhydrQhNT1D1E8q6OnyjfiFTMEEwMx8G77lM", - "height": 435208, - "hash": "MyTG04W_ShUktv34KIeQVeomGBIET_SHU2IAM7KQCtg" - }, - { - "transaction_count": 78, - "time": 1595978091, - "snapshot_hash": "", - "prev_hash": "KMLLGN0v590zMEoAgW6yXWuYtdePDRza74_TF5cZNDY", - "height": 435207, - "hash": "5LHAyQ5GhydrQhNT1D1E8q6OnyjfiFTMEEwMx8G77lM" - }, - { - "transaction_count": 108, - "time": 1595978035, - "snapshot_hash": "", - "prev_hash": "i6NtsS96nGoj3H1QAU4bYjPsRTotAfG1m6CYU0gt_R0", - "height": 435206, - "hash": "KMLLGN0v590zMEoAgW6yXWuYtdePDRza74_TF5cZNDY" - }, - { - "transaction_count": 96, - "time": 1595977982, - "snapshot_hash": "", - "prev_hash": "L-kane8sS3lN5VqGXjl-VwgMvQ9gdw2Nh8rXgCgSZ4c", - "height": 435205, - "hash": "i6NtsS96nGoj3H1QAU4bYjPsRTotAfG1m6CYU0gt_R0" - }, - { - "transaction_count": 106, - "time": 1595977929, - "snapshot_hash": "", - "prev_hash": "il2OTxAn9kb-AkSBendovVQdISb2ooRrn4yE73qv6jI", - "height": 435204, - "hash": "L-kane8sS3lN5VqGXjl-VwgMvQ9gdw2Nh8rXgCgSZ4c" - }, - { - "transaction_count": 107, - "time": 1595977869, - "snapshot_hash": "", - "prev_hash": "ASznLcdOo4xX7Vl-zy17l-XuJ-oO5NvShR9QrLM8Etg", - "height": 435203, - "hash": "il2OTxAn9kb-AkSBendovVQdISb2ooRrn4yE73qv6jI" - }, - { - "transaction_count": 55, - "time": 1595977816, - "snapshot_hash": "", - "prev_hash": "IFf8Mv0rihCic2wGLA-d2ticcmDp5baPXjqSEzt_Q-w", - "height": 435202, - "hash": "ASznLcdOo4xX7Vl-zy17l-XuJ-oO5NvShR9QrLM8Etg" - }, - { - "transaction_count": 104, - "time": 1595977735, - "snapshot_hash": "", - "prev_hash": "4Bbk2hlXB9Ophgn4jk-2QH_6HeAzn12yom04WtkoPbM", - "height": 435201, - "hash": "IFf8Mv0rihCic2wGLA-d2ticcmDp5baPXjqSEzt_Q-w" - } - ], - "cursor": "eyJiZWZvcmUiOjQzNTIwMX0" -} -``` - - - - ---- - -### Block at Height Transactions - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/blocks/:height/transactions -``` - -Get transactions for a block at a given height. The list of returned transactions is paged. A cursor -field is present if more results are available. - - - - -_Path Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ------------------------------------- | -| height (required) | _number_ | Block height to fetch transaction for | - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ---------------------------- | -| cursor (optional) | _string_ | Cursor for the page to fetch | - - - - -200: OK - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -::: - -```json -{ - "data": [ - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIEtI0JUGWFDZxdZ-MqaamBibe9XA7Hu7KtppFxER2_VlAiEAjmdtV8WcdyTVOMF1wLSiRXtsim2cEndKnnhavPAj7ms", - "secret_hash": "PDp3wlQDWQHOv3_cYO3iXSGO5lQPY-nk0nGZ-aCWj6U", - "owner": "13RU6fRkU1uGviyWJzgSVJAiVDhyf97dqBDMTmVjHEAuBy5LN1F", - "onion_key_hash": "T9wxjep44KOQrgw7L7nTBUlTp87BL1lvyCievMmxSHo", - "location": "8c2a30650aad7ff", - "lng": -71.1952338305713, - "lat": 42.34690845297784, - "height": 213787, - "hash": "0XQR1wmeqRYF8BeIPLtqr7ZZQHLWAg7CavmKPrSxF8w", - "fee": 0, - "challenger": "11mxTwhQVMS9o5GqaQ3MW9NbJeQM8x89e52YG3Em4turgAHPSgs", - "block_hash": "XcQXEO8eeJeCQ1V6hcCBMH06a1pOZXxrUBp-2NhM8Yg" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIQCUJskKawMwc9G3Uv_ZRYrhSrHo4QoNuZT4amHVS3rkmQIgJ_RZ-9z3v9T5JNwnAtDTynwJpqO1cQ3KHPBeFGxRBQY", - "secret_hash": "B7scyTy8h6nsXymcrXPaCt0MShUGki2fvPx7lsmRkXc", - "owner": "13Wjb3U16ct477Qixg45nWEtRh4Jg2qTp2iuqgD2Adk8gQmF8Bo", - "onion_key_hash": "1xip4moxB5lx8UO5Dwo35ppMfJi_ASSgxsYaLPaHLRU", - "location": "8c44c13164947ff", - "lng": -84.23063101246672, - "lat": 33.85883850690923, - "height": 213787, - "hash": "6J8ZsZjDF2tiStMOVjtEG9jaKnpLZfAwY4jXx9bX1y4", - "fee": 0, - "challenger": "1181v5Saf87iUexQ8WtqA6xLrzbuF2UaS6dGY8R8p4yqoK1ZjMA", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIEEk2H6NFe9CY7ZtoPPr-9cyBDuDCTvrOOzKpPW7ldIAAiAfGXSl2cgqtVzN8um0PyCTr_dD8_Gmp2CwL8SEkuv1Ew", - "secret_hash": "zCA4W7sUqVu6Gzpz-5TUbzxTTv8SbY0B74VCIp46Hys", - "owner": "14MRMNbNQidNFTszjoYugvMPxQLqLoZyPADSwJKvvnzgd8UX2UZ", - "onion_key_hash": "PyGkman-6k81fdcQn9_DS9dJLRo9r4P9ijpRxPnM4-E", - "location": "8c2663d04684bff", - "lng": -88.31876752603684, - "lat": 40.10013118277986, - "height": 213787, - "hash": "_aOH3TaNbUXB-aETIk7bsUyH6p9HOWDfx3P5wXBxnQQ", - "fee": 0, - "challenger": "11K6YeKEqfwMJu2wy64YHdQhXT8Hy5aMA4SxFdvCR4zwQyF17Xo", - "block_hash": "znLXFN1OaN6aosWTZRmpZ2SIu0wiT4LKG3VkDpf8oqA" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIGCf9Mxj5P9aeuIwbhMrGkhVORX9ymsditZ8jwgrRGoTAiEAmv6oeps953HnAGjtW6b7yu6gKiGYDXneMJxOPPX5cN4", - "secret_hash": "otNY8AVs8_JsIay-CA5XXAiKInVEx00lwXnLBIAfWKo", - "owner": "135qJwSQD2eFBsDjcDWKRgJucKRocVLvxrunc1W9KhcJe9CAp4G", - "onion_key_hash": "lEEBV1DODq5iFKYq4h6mmb-Oba-6dcYfQ3cMUjFhxHc", - "location": "8c2a107a90b09ff", - "lng": -74.21400962950572, - "lat": 40.68133174681411, - "height": 213787, - "hash": "AqLEUGRylc9kfW_tyLMwTJPunVXmlqh5ZrzYVUWxBIE", - "fee": 0, - "challenger": "11cpn65Uuugxs9YAAvYc1i7J9xgWY2pjSj4Y2FFvaFypa8bccLq", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIGPQZRXlxMMJXAiOyYAja70dC6HihyvXNoDRTno3Rw7gAiEAsKS_4qaQ0zLf42sW1SaLnqfb1mUquwFpHbU0-lo21yo", - "secret_hash": "CZjCoW6RU6TejMQjhgePVXPc759u5yp04Y9z5ye5C28", - "owner": "14gaNAfNSL8pPAVjTyy8LhRjVgw9t8JunooEmCSyXLAX9A3pfMF", - "onion_key_hash": "mWsd00ByHhfa_2J-CpphhbhSIiqg58_tMiYkoOBEU6Y", - "location": "8c2a340910313ff", - "lng": -70.2707016518933, - "lat": 43.655908895594315, - "height": 213787, - "hash": "bdkRW7Dxx-ESPSz7i_vxk-jXIqUfmFL9pZUWYmJOwYU", - "fee": 0, - "challenger": "112u5QmxT5LVrD9vdtT1hJ7bBEdqthhbbefTaNK1JCS5n4xbKRoo", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIDDdF3MhXzgLzVRHi6-x55ASjv9BtbIneBMyGekAThY0AiApKRRfmZRVYt-7Bx_le9uaUmmWYkWPv1IXDXRgCGR1Ww", - "secret_hash": "Upa8MV8OvHZBddL-GLAyeNTJ7P80vTAxYFsTI25AnOk", - "owner": "139fiM2t9SGU8yB1QG5GxRy9qztpcnjr1F5u7Paop9Lsh7G31sn", - "onion_key_hash": "F2lzKJQyFet4zkgVaqR9FeO1i6SqICpaN5P1RfbM07E", - "location": "8c44d9975282bff", - "lng": -82.72848196624813, - "lat": 35.533213738889785, - "height": 213787, - "hash": "c-6u-jO4YX0dgxXSUMK7HKxdPUmxbxwXCbHblKDbHjQ", - "fee": 0, - "challenger": "112oBX3SKsRdxXD97dNVL8k5ejnS6bYiKxjWeRS2yuj8gCkgLUb1", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIEQkbbVN05yp4ynRKCdnXbPBOADm645fVXXg3wQ5EGgJAiAqO__gcfiLdmPqtofKvf1XAnXL6oyTe2f6YSIkatGfMg", - "secret_hash": "0RusqDuS5D1l6VxHHqOfYKN3_dRzS9glMuv9XhlHJOc", - "owner": "14FrS6JfobouRDVf7FbYuvvR5uNzB688qESpQNXLoaCqd1zDN7P", - "onion_key_hash": "VQuQlV7KfjAK2xT0CqP6a-qt_sZHBD5AQKeHOiSRMeE", - "location": "8c2a122dbb893ff", - "lng": -75.27858120362838, - "lat": 40.236503579574276, - "height": 213787, - "hash": "CGjUzaSOqukYqnJK2zYd0YuvGea0MrNdlRCubhEPbag", - "fee": 0, - "challenger": "112a5Mzuhw4h9Er29yGhsYLi9FePQmzmgyKXZW53to8uXHzZYSS3", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEYCIQC0VJsxXtXeYR_NAOtoFz3C-tbOam3sQFKMAyufH0RdGgIhAKK0BBiCJYOOpDVikt1jbxMUscVz9q3gRTrw9ga1NNJ0", - "secret_hash": "30jwhK8zdNvluN4ikCymnWo3GBwYfyWk1fALTBFYcHU", - "owner": "13T8w9Y88SEqbuzRkDq49xHKfX57cJbbv5y1fTqMU79Wu1q1o5j", - "onion_key_hash": "1oYPe7schX1Ph2ZpP4zGGOviXfBLoZlF_WK3usuelac", - "location": "8c2a10564c437ff", - "lng": -74.03002342945634, - "lat": 41.04224197668894, - "height": 213787, - "hash": "E80uoOjygu6SbUqsnEu-lCXKjbzZW9WiHSrKx033-MI", - "fee": 0, - "challenger": "114PsNUa1rMT9Q2PpeAqs9RpJXjMgb5BNT5Azi9CaVQ6daijLRo", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIBYBRSno33FSUpXXZnMy51MK9ciU_MO__wWl9nk7UlLqAiA1OU26vJxQp8irF6NpdqPLynpTMBdTxSgEiAYTcr-0UA", - "secret_hash": "G7PfwPRmL5NFwtVNhAA3y9F0-6_tfKLeV7Vq6fLUOEY", - "owner": "14RhEs3bVE9WYryYjdBG3LksJVhd9Wp5fxPLRQeHebTrPKReeyE", - "onion_key_hash": "miByk1ioQpmSoSlLmk5pSlhnoQHdK-GXZGsiNJQSvxc", - "location": "8c2836156622bff", - "lng": -121.02718668572189, - "lat": 37.65368378785006, - "height": 213787, - "hash": "eLaP-eUAJbJJIQSIkb3u5wD-eQMjJ_qeI-zF8YWa-7o", - "fee": 0, - "challenger": "11F2cGbEYfB6qvmNLE7tXWnkgqLfWPvHpxsgyghNRidusGDKD41", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIBDls8CH7DspVWl0IC77XLzzt7wHygTukGlibTygCP3QAiAl9fR9dNgLgaSIkl4cqBrSqjtbtu_Eg1UeMjRqmi9mog", - "secret_hash": "SR-livfqQa58lN3WX5a9jIBUW63DFOUUAgCC27WRu6I", - "owner": "13BPvTrw32jdsBPJYnL7whYghwLboCqipTaJbhSEaaZVzgmEemm", - "onion_key_hash": "R9GPq3ssxi6LW_iuj-7KqSwKSmZ_in7EdJEGWcVrWbs", - "location": "8c489e3534f45ff", - "lng": -97.68010436306147, - "lat": 30.30448054652587, - "height": 213787, - "hash": "eMNvkAotMP4e3xAfN1gh5oc5CTXnIhf2sIxijE3oZXA", - "fee": 0, - "challenger": "117r6sxGnFD3n5GnMTqSfhLxYqoXcDvFpzjNkweD8ZhPr9YQLRU", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "type": "poc_receipts_v1", - "time": 1582192928, - "signature": "MEQCIGVhWn3s3_2HYQzGNFi2GmV3xsr8Nm2EemoHNyqPNb33AiAPOfTXQKEo6Ol1H6JnlNTihUDpK5qtVRM6JSEDaVNvYA", - "secret": "AJswL6q6bm7bGIwk3jzzyH0kDGSJHb14ZnI2GgVApo8uBC3mU933j0w0_5rF3ejIZdLSusOmCZdzhoag7RtADi6OGXHHEdRNfTIDYR_41sddC0mqPE8A3NXXo2mzpqqkgo4", - "path": [ - { - "witnesses": [], - "receipt": { - "timestamp": 1582192367974227200, - "signature": "MEUCIDD9BLjC_ghbIe7zhKQtDrhrlLD1BJgI_95ryQ6CFyyOAiEA1BZj_-faF_d7PFela0-EC6meWh3Wbe749I73Ta5gnyM", - "signal": 0, - "origin": "p2p", - "gateway": "112oQLEtxFFw4NrPZ7d1DFM1iScCunu5xvea99kVVTorNo16cBKg", - "data": "NJA" - }, - "challengee": "112oQLEtxFFw4NrPZ7d1DFM1iScCunu5xvea99kVVTorNo16cBKg" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "112SVQqroQvvq2rQHKWYfxP2eRb91NLXU8qduBCLt1B1DmLK6Xj" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "112CGr8XwCuHtD4CmewgCWfz6ttQaRLK5Up8cjoUng37zpLN5kbi" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "11DpearQqzUSCy4Mdho5CN4LSqZffhHkAwkeRieeAvELnpQzfUP" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "11DRokFJ3U9UkDU4BFN2djb6fH7wAwLr2ysXPJsbhDoUoyGFvuV" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "112DWqhAqCd5ie5sbSxXBG7o3mrGZgPSdhEYumbvxSNA4G5ZSxNe" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "1125H31qsBackYPLiYQQYHvxi6bRxzcfjRK5aJv1gA2ZwKb7WYL7" - } - ], - "onion_key_hash": "qDnv0zJGjHUvgZTmGyJspRiPZvktTqQ-enBE43xrceg", - "height": 213787, - "hash": "GJMR4wfeHPC2xBhGM4vQqu344dyQdn7TZUpzNFu3baA", - "fee": 0, - "challenger_owner": "13uJVUm1U2iFZHhmFNp4E6L6v9rkjoABicw1SFC424rqadj7Qg5", - "challenger_loc": "8c48eba0b2d11ff", - "challenger": "112fpjqDuU3MequG617EuQ3xhtdecz6ah2WxJK87XqfHL5jnSdvc" - } - ] -} -``` - - - - ---- - -### Block at Hash - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/blocks/hash/:hash -``` - -Get block descriptor for the given block hash. - - - - -_Path Parameters_ - -| param | Type | Note | -| --------------- | -------- | --------------------------------- | -| hash (required) | _string_ | Block hash for the block to fetch | - - - - -200: OK - -```json -{ - "data": { - "transaction_count": 37, - "time": 1582192928, - "snapshot_hash": "", - "prev_hash": "Xj6vrBi_IcP0vqHHawf0FFWkG1qn18I9thQKOEhblXg", - "height": 213787, - "hash": "o5o8cBL1Zvp1KmA1d8vYJ38wXXWVxf1HW2e1uZxVJYg" - } -} -``` - - - - ---- - -### Block at Hash Transactions - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/blocks/hash/:hash/transactions -``` - -Get transactions for a block at a given block hash. The list of returned transactions is paged. A -`cursor` field is present if more results are available. - - - - -_Path Parameters_ - -| param | Type | Note | -| --------------- | -------- | --------------------------------- | -| hash (required) | _string_ | Block hash for the block to fetch | - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ---------------------------- | -| cursor (optional) | _string_ | Cursor for the page to fetch | - - - - -200: OK - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -::: - -```json -{ - "data": [ - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIEtI0JUGWFDZxdZ-MqaamBibe9XA7Hu7KtppFxER2_VlAiEAjmdtV8WcdyTVOMF1wLSiRXtsim2cEndKnnhavPAj7ms", - "secret_hash": "PDp3wlQDWQHOv3_cYO3iXSGO5lQPY-nk0nGZ-aCWj6U", - "owner": "13RU6fRkU1uGviyWJzgSVJAiVDhyf97dqBDMTmVjHEAuBy5LN1F", - "onion_key_hash": "T9wxjep44KOQrgw7L7nTBUlTp87BL1lvyCievMmxSHo", - "location": "8c2a30650aad7ff", - "lng": -71.1952338305713, - "lat": 42.34690845297784, - "height": 213787, - "hash": "0XQR1wmeqRYF8BeIPLtqr7ZZQHLWAg7CavmKPrSxF8w", - "fee": 0, - "challenger": "11mxTwhQVMS9o5GqaQ3MW9NbJeQM8x89e52YG3Em4turgAHPSgs", - "block_hash": "XcQXEO8eeJeCQ1V6hcCBMH06a1pOZXxrUBp-2NhM8Yg" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIQCUJskKawMwc9G3Uv_ZRYrhSrHo4QoNuZT4amHVS3rkmQIgJ_RZ-9z3v9T5JNwnAtDTynwJpqO1cQ3KHPBeFGxRBQY", - "secret_hash": "B7scyTy8h6nsXymcrXPaCt0MShUGki2fvPx7lsmRkXc", - "owner": "13Wjb3U16ct477Qixg45nWEtRh4Jg2qTp2iuqgD2Adk8gQmF8Bo", - "onion_key_hash": "1xip4moxB5lx8UO5Dwo35ppMfJi_ASSgxsYaLPaHLRU", - "location": "8c44c13164947ff", - "lng": -84.23063101246672, - "lat": 33.85883850690923, - "height": 213787, - "hash": "6J8ZsZjDF2tiStMOVjtEG9jaKnpLZfAwY4jXx9bX1y4", - "fee": 0, - "challenger": "1181v5Saf87iUexQ8WtqA6xLrzbuF2UaS6dGY8R8p4yqoK1ZjMA", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIEEk2H6NFe9CY7ZtoPPr-9cyBDuDCTvrOOzKpPW7ldIAAiAfGXSl2cgqtVzN8um0PyCTr_dD8_Gmp2CwL8SEkuv1Ew", - "secret_hash": "zCA4W7sUqVu6Gzpz-5TUbzxTTv8SbY0B74VCIp46Hys", - "owner": "14MRMNbNQidNFTszjoYugvMPxQLqLoZyPADSwJKvvnzgd8UX2UZ", - "onion_key_hash": "PyGkman-6k81fdcQn9_DS9dJLRo9r4P9ijpRxPnM4-E", - "location": "8c2663d04684bff", - "lng": -88.31876752603684, - "lat": 40.10013118277986, - "height": 213787, - "hash": "_aOH3TaNbUXB-aETIk7bsUyH6p9HOWDfx3P5wXBxnQQ", - "fee": 0, - "challenger": "11K6YeKEqfwMJu2wy64YHdQhXT8Hy5aMA4SxFdvCR4zwQyF17Xo", - "block_hash": "znLXFN1OaN6aosWTZRmpZ2SIu0wiT4LKG3VkDpf8oqA" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIGCf9Mxj5P9aeuIwbhMrGkhVORX9ymsditZ8jwgrRGoTAiEAmv6oeps953HnAGjtW6b7yu6gKiGYDXneMJxOPPX5cN4", - "secret_hash": "otNY8AVs8_JsIay-CA5XXAiKInVEx00lwXnLBIAfWKo", - "owner": "135qJwSQD2eFBsDjcDWKRgJucKRocVLvxrunc1W9KhcJe9CAp4G", - "onion_key_hash": "lEEBV1DODq5iFKYq4h6mmb-Oba-6dcYfQ3cMUjFhxHc", - "location": "8c2a107a90b09ff", - "lng": -74.21400962950572, - "lat": 40.68133174681411, - "height": 213787, - "hash": "AqLEUGRylc9kfW_tyLMwTJPunVXmlqh5ZrzYVUWxBIE", - "fee": 0, - "challenger": "11cpn65Uuugxs9YAAvYc1i7J9xgWY2pjSj4Y2FFvaFypa8bccLq", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEUCIGPQZRXlxMMJXAiOyYAja70dC6HihyvXNoDRTno3Rw7gAiEAsKS_4qaQ0zLf42sW1SaLnqfb1mUquwFpHbU0-lo21yo", - "secret_hash": "CZjCoW6RU6TejMQjhgePVXPc759u5yp04Y9z5ye5C28", - "owner": "14gaNAfNSL8pPAVjTyy8LhRjVgw9t8JunooEmCSyXLAX9A3pfMF", - "onion_key_hash": "mWsd00ByHhfa_2J-CpphhbhSIiqg58_tMiYkoOBEU6Y", - "location": "8c2a340910313ff", - "lng": -70.2707016518933, - "lat": 43.655908895594315, - "height": 213787, - "hash": "bdkRW7Dxx-ESPSz7i_vxk-jXIqUfmFL9pZUWYmJOwYU", - "fee": 0, - "challenger": "112u5QmxT5LVrD9vdtT1hJ7bBEdqthhbbefTaNK1JCS5n4xbKRoo", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIDDdF3MhXzgLzVRHi6-x55ASjv9BtbIneBMyGekAThY0AiApKRRfmZRVYt-7Bx_le9uaUmmWYkWPv1IXDXRgCGR1Ww", - "secret_hash": "Upa8MV8OvHZBddL-GLAyeNTJ7P80vTAxYFsTI25AnOk", - "owner": "139fiM2t9SGU8yB1QG5GxRy9qztpcnjr1F5u7Paop9Lsh7G31sn", - "onion_key_hash": "F2lzKJQyFet4zkgVaqR9FeO1i6SqICpaN5P1RfbM07E", - "location": "8c44d9975282bff", - "lng": -82.72848196624813, - "lat": 35.533213738889785, - "height": 213787, - "hash": "c-6u-jO4YX0dgxXSUMK7HKxdPUmxbxwXCbHblKDbHjQ", - "fee": 0, - "challenger": "112oBX3SKsRdxXD97dNVL8k5ejnS6bYiKxjWeRS2yuj8gCkgLUb1", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIEQkbbVN05yp4ynRKCdnXbPBOADm645fVXXg3wQ5EGgJAiAqO__gcfiLdmPqtofKvf1XAnXL6oyTe2f6YSIkatGfMg", - "secret_hash": "0RusqDuS5D1l6VxHHqOfYKN3_dRzS9glMuv9XhlHJOc", - "owner": "14FrS6JfobouRDVf7FbYuvvR5uNzB688qESpQNXLoaCqd1zDN7P", - "onion_key_hash": "VQuQlV7KfjAK2xT0CqP6a-qt_sZHBD5AQKeHOiSRMeE", - "location": "8c2a122dbb893ff", - "lng": -75.27858120362838, - "lat": 40.236503579574276, - "height": 213787, - "hash": "CGjUzaSOqukYqnJK2zYd0YuvGea0MrNdlRCubhEPbag", - "fee": 0, - "challenger": "112a5Mzuhw4h9Er29yGhsYLi9FePQmzmgyKXZW53to8uXHzZYSS3", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEYCIQC0VJsxXtXeYR_NAOtoFz3C-tbOam3sQFKMAyufH0RdGgIhAKK0BBiCJYOOpDVikt1jbxMUscVz9q3gRTrw9ga1NNJ0", - "secret_hash": "30jwhK8zdNvluN4ikCymnWo3GBwYfyWk1fALTBFYcHU", - "owner": "13T8w9Y88SEqbuzRkDq49xHKfX57cJbbv5y1fTqMU79Wu1q1o5j", - "onion_key_hash": "1oYPe7schX1Ph2ZpP4zGGOviXfBLoZlF_WK3usuelac", - "location": "8c2a10564c437ff", - "lng": -74.03002342945634, - "lat": 41.04224197668894, - "height": 213787, - "hash": "E80uoOjygu6SbUqsnEu-lCXKjbzZW9WiHSrKx033-MI", - "fee": 0, - "challenger": "114PsNUa1rMT9Q2PpeAqs9RpJXjMgb5BNT5Azi9CaVQ6daijLRo", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIBYBRSno33FSUpXXZnMy51MK9ciU_MO__wWl9nk7UlLqAiA1OU26vJxQp8irF6NpdqPLynpTMBdTxSgEiAYTcr-0UA", - "secret_hash": "G7PfwPRmL5NFwtVNhAA3y9F0-6_tfKLeV7Vq6fLUOEY", - "owner": "14RhEs3bVE9WYryYjdBG3LksJVhd9Wp5fxPLRQeHebTrPKReeyE", - "onion_key_hash": "miByk1ioQpmSoSlLmk5pSlhnoQHdK-GXZGsiNJQSvxc", - "location": "8c2836156622bff", - "lng": -121.02718668572189, - "lat": 37.65368378785006, - "height": 213787, - "hash": "eLaP-eUAJbJJIQSIkb3u5wD-eQMjJ_qeI-zF8YWa-7o", - "fee": 0, - "challenger": "11F2cGbEYfB6qvmNLE7tXWnkgqLfWPvHpxsgyghNRidusGDKD41", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "version": 2, - "type": "poc_request_v1", - "time": 1582192928, - "signature": "MEQCIBDls8CH7DspVWl0IC77XLzzt7wHygTukGlibTygCP3QAiAl9fR9dNgLgaSIkl4cqBrSqjtbtu_Eg1UeMjRqmi9mog", - "secret_hash": "SR-livfqQa58lN3WX5a9jIBUW63DFOUUAgCC27WRu6I", - "owner": "13BPvTrw32jdsBPJYnL7whYghwLboCqipTaJbhSEaaZVzgmEemm", - "onion_key_hash": "R9GPq3ssxi6LW_iuj-7KqSwKSmZ_in7EdJEGWcVrWbs", - "location": "8c489e3534f45ff", - "lng": -97.68010436306147, - "lat": 30.30448054652587, - "height": 213787, - "hash": "eMNvkAotMP4e3xAfN1gh5oc5CTXnIhf2sIxijE3oZXA", - "fee": 0, - "challenger": "117r6sxGnFD3n5GnMTqSfhLxYqoXcDvFpzjNkweD8ZhPr9YQLRU", - "block_hash": "aCrKSvuKX1dAkUURkvaCRT1C0Z-WD5m6q4TgWr7gx5Y" - }, - { - "type": "poc_receipts_v1", - "time": 1582192928, - "signature": "MEQCIGVhWn3s3_2HYQzGNFi2GmV3xsr8Nm2EemoHNyqPNb33AiAPOfTXQKEo6Ol1H6JnlNTihUDpK5qtVRM6JSEDaVNvYA", - "secret": "AJswL6q6bm7bGIwk3jzzyH0kDGSJHb14ZnI2GgVApo8uBC3mU933j0w0_5rF3ejIZdLSusOmCZdzhoag7RtADi6OGXHHEdRNfTIDYR_41sddC0mqPE8A3NXXo2mzpqqkgo4", - "path": [ - { - "witnesses": [], - "receipt": { - "timestamp": 1582192367974227200, - "signature": "MEUCIDD9BLjC_ghbIe7zhKQtDrhrlLD1BJgI_95ryQ6CFyyOAiEA1BZj_-faF_d7PFela0-EC6meWh3Wbe749I73Ta5gnyM", - "signal": 0, - "origin": "p2p", - "gateway": "112oQLEtxFFw4NrPZ7d1DFM1iScCunu5xvea99kVVTorNo16cBKg", - "data": "NJA" - }, - "challengee": "112oQLEtxFFw4NrPZ7d1DFM1iScCunu5xvea99kVVTorNo16cBKg" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "112SVQqroQvvq2rQHKWYfxP2eRb91NLXU8qduBCLt1B1DmLK6Xj" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "112CGr8XwCuHtD4CmewgCWfz6ttQaRLK5Up8cjoUng37zpLN5kbi" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "11DpearQqzUSCy4Mdho5CN4LSqZffhHkAwkeRieeAvELnpQzfUP" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "11DRokFJ3U9UkDU4BFN2djb6fH7wAwLr2ysXPJsbhDoUoyGFvuV" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "112DWqhAqCd5ie5sbSxXBG7o3mrGZgPSdhEYumbvxSNA4G5ZSxNe" - }, - { - "witnesses": [], - "receipt": null, - "challengee": "1125H31qsBackYPLiYQQYHvxi6bRxzcfjRK5aJv1gA2ZwKb7WYL7" - } - ], - "onion_key_hash": "qDnv0zJGjHUvgZTmGyJspRiPZvktTqQ-enBE43xrceg", - "height": 213787, - "hash": "GJMR4wfeHPC2xBhGM4vQqu344dyQdn7TZUpzNFu3baA", - "fee": 0, - "challenger_owner": "13uJVUm1U2iFZHhmFNp4E6L6v9rkjoABicw1SFC424rqadj7Qg5", - "challenger_loc": "8c48eba0b2d11ff", - "challenger": "112fpjqDuU3MequG617EuQ3xhtdecz6ah2WxJK87XqfHL5jnSdvc" - } - ] -} -``` - - - - ---- - -## Deprecated Endpoints - -### Block at Height - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. The data provided by this endpoint is based on blocks rather than time -and daily epochs. - -::: - -``` -GET https://api.helium.io/v1/blocks/:height -``` - -Get block descriptor for block at height - - - - -_Path Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ----------------- | -| height (required) | _number_ | Blockchain Height | - - - - -200: OK - -```json -{ - "data": { - "transaction_count": 37, - "time": 1582192928, - "snapshot_hash": "", - "prev_hash": "Xj6vrBi_IcP0vqHHawf0FFWkG1qn18I9thQKOEhblXg", - "height": 213787, - "hash": "o5o8cBL1Zvp1KmA1d8vYJ38wXXWVxf1HW2e1uZxVJYg" - } -} -``` - - - - ---- diff --git a/docs/api/blockchain/chain-variables.mdx b/docs/api/blockchain/chain-variables.mdx deleted file mode 100644 index 688b3d55b..000000000 --- a/docs/api/blockchain/chain-variables.mdx +++ /dev/null @@ -1,298 +0,0 @@ ---- -id: chain-variables -title: Chain Variables -pagination_label: Chain Variables -sidebar_label: Chain Variables -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/chain-variables ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Deprecated Endpoints - -### Get Chain Variables - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/vars -``` - -Gets the current set of chain variables - - - - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -```json -{ - "data": { - "allow_zero_amount": false, - "alpha_decay": 0.0035, - "batch_size": 400, - "beta_decay": 0.002, - "block_time": 60000, - "block_version": "v1", - "chain_vars_version": 2, - "consensus_percent": 0.1, - "dc_payload_size": 24, - "dc_percent": 0, - "dkg_curve": "SS512", - "election_bba_penalty": 0.001, - "election_cluster_res": 4, - "election_interval": 30, - "election_removal_pct": 40, - "election_replacement_factor": 4, - "election_replacement_slope": 20, - "election_restart_interval": 5, - "election_seen_penalty": 0.0033333, - "election_selection_pct": 1, - "election_version": 3, - "h3_exclusion_ring_dist": 6, - "h3_max_grid_distance": 120, - "h3_neighbor_res": 12, - "max_open_sc": 2, - "max_payments": 50, - "max_staleness": 100000, - "max_subnet_num": 5, - "max_subnet_size": 65536, - "max_xor_filter_num": 5, - "max_xor_filter_size": 102400, - "min_assert_h3_res": 12, - "min_expire_within": 15, - "min_score": 0.15, - "min_subnet_size": 8, - "monthly_reward": 500000000000000, - "num_consensus_members": 16, - "poc_centrality_wt": 0.5, - "poc_challenge_interval": 60, - "poc_challenge_sync_interval": 90, - "poc_challengees_percent": 0.35, - "poc_challengers_percent": 0.15, - "poc_good_bucket_high": -70, - "poc_good_bucket_low": -130, - "poc_max_hop_cells": 2000, - "poc_path_limit": 7, - "poc_target_hex_parent_res": 5, - "poc_typo_fixes": true, - "poc_v4_exclusion_cells": 8, - "poc_v4_parent_res": 11, - "poc_v4_prob_bad_rssi": 0.01, - "poc_v4_prob_count_wt": 0.0, - "poc_v4_prob_good_rssi": 1.0, - "poc_v4_prob_no_rssi": 0.5, - "poc_v4_prob_rssi_wt": 0.0, - "poc_v4_prob_time_wt": 0.0, - "poc_v4_randomness_wt": 0.5, - "poc_v4_target_challenge_age": 300, - "poc_v4_target_exclusion_cells": 6000, - "poc_v4_target_prob_edge_wt": 0.0, - "poc_v4_target_prob_score_wt": 0.0, - "poc_v4_target_score_curve": 5, - "poc_v5_target_prob_randomness_wt": 1.0, - "poc_version": 8, - "poc_witnesses_percent": 0.05, - "predicate_callback_fun": "version", - "predicate_callback_mod": "miner", - "predicate_threshold": 0.95, - "price_oracle_height_delta": 10, - "price_oracle_price_scan_delay": 3600, - "price_oracle_price_scan_max": 90000, - "price_oracle_public_keys": [ - "13Btezbvbwr9LhKmDQLgBnJUgjhZighEjNPLeu79dqBbmXRwoWm", - "13CFFcmPtMvNQCpWQRXCTqXPnXtcsibDWVwiQRKpUCt4nqtF7RE", - "1431WVQvoV7RAJpoLCaBrTKner1Soed4bk69DddcrHUTCWHV6pj", - "136n9BEbreGUNgXJWtyzkBQcXiNzdMQ5GBoP8L2J6ZReFUAwUjy", - "14sqAYg1qxzjKTtyHLYZdH6yDtA3KgyoARhWN1cvLZ94dZw5vEc", - "145J6Aye86pKTJrUHREiXu7qqppZBcWY1bvWo8id7ZjxyuainYj", - "13dUGHis1PdrSwxdseoyZKzQhc8WuWcueAWdT95sDVGDNhGRWV9", - "14EzXp4i1xYA7SNyim6R4J5aXN1yHYKNiPrrJ2WEvoDnxmLgaCg", - "147yRbowD1krUCC1DhhSMhpFEqnkwb26mHBow5nk9q43AakSHNA" - ], - "price_oracle_refresh_interval": 10, - "reward_version": 2, - "sc_grace_blocks": 100, - "securities_percent": 0.35, - "snapshot_interval": 720, - "snapshot_version": 1, - "var_gw_inactivity_threshold": 600, - "vars_commit_delay": 1, - "witness_refresh_interval": 10080, - "witness_refresh_rand_n": 1000 - } -} -``` - - - - ---- - -### Get the value of a chain variable - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/vars/:name -``` - -Gets the value of the chain variable with the given name - - - - -_Path Parameters_ - -| param | Type | Note | -| --------------- | -------- | ---------------------------- | -| name (optional) | _string_ | The name of a chain variable | - - - - -200: OK - -This fetched the `block_time` chain variable - -```json -{ - "data": 60000 -} -``` - - - - ---- - -### List chain variable activity - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/vars/activity -``` - -Lists all chain variable transaction activity. This route is paged using a cursor. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for the next page to fetch | - - - - -200: OK - -```json -{ - "data": [ - { - "cancels": [], - "hash": "FXLaw6csD1q_sRU9oyk6Vz6p47vBIhVPhSDcIEGXPiQ", - "height": 365778, - "key_proof": "", - "master_key": null, - "nonce": 28, - "proof": "MEUCIF255lwe5je1GMM5OdWAbc86sZ5xaU3-75VSjILrVZ0GAiEAjpFTh7bSvrZV4fC2vnFN7KKG3bsBUhdBDe6JRUJ-AyM", - "time": 1591646992, - "type": "vars_v1", - "unsets": [], - "vars": { - "price_oracle_height_delta": 10, - "price_oracle_price_scan_delay": 3600, - "price_oracle_price_scan_max": 90000, - "price_oracle_public_keys": "IQEgHuJGDwcAoZZsw1rNcZIpbsIrVqihXfFEKX2g5YLNjCEBIO1OyYQtE8A+UdHQnGfgiTPBoA9g7qAq665jgMcUmt4hAY+mQWlLOM6dVi7hrugbt5H4Mo3SkJv+UOHwpKTVDJJkIQEUgzPrDa98YpqHWsRTDnbfvd2atT5pt4d5aWUzo3fOhCEB/oFGezNl0OBjrD5+/DuCVF3n1vjPi1SeeOgGCHnzGc0hAZTW/LUBIchFlJIiHRZbbBASIS0A0mT907FOUnF6lS/wIQFaM7GI+z26SkZoPG510rm0As7zf9ZlGLS+o50txhXIwiEBqtvQSZyN25QHlP3RQjDaW0fo9Mb97CjJWnA97JxF620hAZrrw1ilYRXLAaFgR+zBvDK51g8OVj31g24WlggwrmhC", - "price_oracle_refresh_interval": 10 - }, - "version_predicate": 0 - }, - { - "cancels": [], - "hash": "J-c9UpTKIXtnDtLOJihaI7F99nrXa1IDbymVVgsugvM", - "height": 352052, - "key_proof": "", - "master_key": "1Wh4bh", - "nonce": 27, - "proof": "MEQCIEkPl2ekYjQRvNwp3CQ9wnu3nHvuiDHCs4bNkK7kntyUAiB_0fspgA60E6TNViasYBuTcla06__jpxFGMpsWPnJ3xA", - "time": 1590705257, - "type": "vars_v1", - "unsets": [], - "vars": { - "snapshot_interval": 720, - "snapshot_version": 1 - }, - "version_predicate": 0 - }, - { - "cancels": [], - "hash": "UI2IoTs4eXA68wKyL8059alByHjszUU3GMgj7Ef9Uc4", - "height": 339406, - "key_proof": "", - "master_key": "1Wh4bh", - "nonce": 26, - "proof": "MEUCIHhP-ADAk1dpz4NB1_RaHapWCBTMxRR8m0Fg4_Pq9ea-AiEAqgnPEc09kclYyv7LO3NT93fb-KbjgK4YOIQYiUm_ero", - "time": 1589921323, - "type": "vars_v1", - "unsets": [], - "vars": { - "witness_refresh_interval": 10080, - "witness_refresh_rand_n": 1000 - }, - "version_predicate": 0 - } - ] -} -``` - - - diff --git a/docs/api/blockchain/challenges.mdx b/docs/api/blockchain/challenges.mdx deleted file mode 100644 index 569b93898..000000000 --- a/docs/api/blockchain/challenges.mdx +++ /dev/null @@ -1,825 +0,0 @@ ---- -id: challenges -title: Challenges -pagination_label: Challenges -sidebar_label: Challenges -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/challenges ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Oracles API - -### List Challenge receipts - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -Lists the completed challenges by listing challenge receipts. - -``` -GET https://api.helium.io/v1/challenges -``` - -Use this API to list `challenge_receipts` transactions. - -This route is `cursor` paginated. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -Return a page of `challenge_receipts` transactions. - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) [DEPRECATED] - -::: - -```json -{ - "data": [ - { - "type": "poc_receipts_v1", - "time": 1628766652, - "secret": "AApadxK7urPuQkpYdQJpZXdiLsjlCgabJadeKGdw5EuABLb3rMNPi91rObf6J98uhcuB0-nkw8Blhaet8AYXJCnOJsv__Ao0ZjrS7yZo8oMtDCUSmAK1Il4VLxZbt0c0Y7Q", - "request_block_hash": "jZRwpQwVG304mI1NVadWM-anjWAYIZObuKm5ohjQbFc", - "path": [ - { - "witnesses": [ - { - "timestamp": 1628765223607395784, - "snr": 0.800000011920929, - "signal": -100, - "packet_hash": "N3OeevT-F5AMO5zr_vP136WHLu8YtHdrPUEbJCebKH0", - "owner": "131nTdBwd37hakns58Rz8gLaJcENZK6eBhazDRBt2i2RPfcni8Y", - "location_hex": "88268c62b7fffff", - "location": "8c268c62b75d5ff", - "is_valid": true, - "gateway": "114qCeyTcnArowArUuLfYZszKrV37f4WNd1gFNCQciajPJgTcQW", - "frequency": 904.7000122070312, - "datarate": "SF9BW125", - "channel": 4 - } - ], - "receipt": { - "timestamp": 1628765222187225510, - "snr": 0.0, - "signal": 0, - "origin": "p2p", - "gateway": "11BCGPgrFa2SxFMWfnv7S644uXX7jZTGmWVp3c2yhMh46G6pEbW", - "frequency": 0.0, - "datarate": null, - "data": "REc", - "channel": 0 - }, - "geocode": { - "short_street": "Longleaf Ln", - "short_state": "CO", - "short_country": "US", - "short_city": "Colorado Springs", - "long_street": "Longleaf Lane", - "long_state": "Colorado", - "long_country": "United States", - "long_city": "Colorado Springs", - "city_id": "Y29sb3JhZG8gc3ByaW5nc2NvbG9yYWRvdW5pdGVkIHN0YXRlcw" - }, - "challengee_owner": "12xw96UQoj64Y9JfsAy4A7BRY7fENSqoCH3a1ZVsMu8aWRN8PMs", - "challengee_lon": -104.66983411327342, - "challengee_location_hex": "88268c75a5fffff", - "challengee_location": "8c268c75a50bdff", - "challengee_lat": 38.92707131307015, - "challengee": "11BCGPgrFa2SxFMWfnv7S644uXX7jZTGmWVp3c2yhMh46G6pEbW" - } - ], - "onion_key_hash": "Sku6Zj2HUzYxqqI3tMDQdzY2as8UTWctrxknoeg0Bvw", - "height": 961893, - "hash": "0nodpQ_evdXuQAsL-Eif4X4KxDTGCa76IbwhRb0Z_zQ", - "fee": 0, - "challenger_owner": "13bCghX9hckaPobC1w2oAZpA9BWyzGh9t9rVjhMuQoyGLqUjhSf", - "challenger_lon": -117.24707207796978, - "challenger_location": "8c29a4024c93dff", - "challenger_lat": 32.73954536951243, - "challenger": "11e3ZHFacF2TPi99GNwoeYMfQGBiTTm8NwQrF5En9JKTCQUsSQf" - }, - { - "type": "poc_receipts_v1", - "time": 1628766652, - "secret": "APujuImlTzLP3srv7XhVYfarHKUcnH1L7Zj0cvrmud4IBJPYUACx4c78NS6peagnyJqKWPvofp1boQ1ESEL_kO1kAkBdL3_nn5dDj57fTgNDNzq_BRDz3GRA6pAyyZ99uPs", - "request_block_hash": "obWCHMdiQ5mCScRUgFsaVd2Kp_RDFhythHnrCoDj2DI", - "path": [ - { - "witnesses": [ - { - "timestamp": 1628765187186362850, - "snr": -9.800000190734863, - "signal": -109, - "packet_hash": "ZtfDcbFjuzTPB7UmE6a8ayZ5YU5tbKty2kNKGy_GB2I", - "owner": "148sAphN7RmmiGEYXz1dghgZTLz8kUphBrToPUgWQqNZXWuHbJE", - "location_hex": "882664c105fffff", - "location": "8c2664c10574bff", - "is_valid": true, - "gateway": "112UHF9Z6qJWsEt7L36KfXNhvTgBphVSg8V2pNqm2cFyzVtSPpHU", - "frequency": 905.0999755859375, - "datarate": "SF9BW125", - "channel": 6 - }, - { - "timestamp": 1628765187112725519, - "snr": 11.800000190734863, - "signal": -80, - "packet_hash": "ZtfDcbFjuzTPB7UmE6a8ayZ5YU5tbKty2kNKGy_GB2I", - "owner": "14pKXXAwovWrRMDjA2AdFShuvsuynWD1JCbDmghatgDBNkubjVE", - "location_hex": "882664c10dfffff", - "location": "8c2664c10d407ff", - "is_valid": false, - "invalid_reason": "witness_rssi_too_high", - "gateway": "11CNgnba2o9sX4YS5amixVWZFeh5hFXCky7RdCNrMQq6aqTvmdy", - "frequency": 905.0999755859375, - "datarate": "SF9BW125", - "channel": 6 - }, - { - "timestamp": 1628765187209047724, - "snr": -10.199999809265137, - "signal": -109, - "packet_hash": "ZtfDcbFjuzTPB7UmE6a8ayZ5YU5tbKty2kNKGy_GB2I", - "owner": "135g73WigjfXyBMC6pLjot7k5m9Yb5YaGgnDkEj5XwmKmFr3HUQ", - "location_hex": "882664c105fffff", - "location": "8c2664c104803ff", - "is_valid": true, - "gateway": "11Dz8tiM5oXQn1j8qCCK5AaMv9sZnpSmFE2EiCXpkCKzfXGHKvN", - "frequency": 905.0999755859375, - "datarate": "SF9BW125", - "channel": 6 - }, - { - "timestamp": 1628765187099934674, - "snr": 1.0, - "signal": -98, - "packet_hash": "ZtfDcbFjuzTPB7UmE6a8ayZ5YU5tbKty2kNKGy_GB2I", - "owner": "13n3RYHSxNumACZYmw8XhYD5LJogfiFy9mRRKZUw8AQQTZYvdst", - "location_hex": "882664c10dfffff", - "location": "8c2664c10c5cbff", - "is_valid": true, - "gateway": "11295CxJw7JUBy8q92k2F82aD6XxL17218NyFTxNDm7R3wi3cEyd", - "frequency": 905.0999755859375, - "datarate": "SF9BW125", - "channel": 6 - }, - { - "timestamp": 1628765187117020109, - "snr": 7.5, - "signal": -81, - "packet_hash": "ZtfDcbFjuzTPB7UmE6a8ayZ5YU5tbKty2kNKGy_GB2I", - "owner": "13JYSCay4pT2DkmsGt4oWVwQfTNjtPJajs91v7hkHDG45oMMKRM", - "location_hex": "882664c109fffff", - "location": "8c2664c108a85ff", - "is_valid": false, - "invalid_reason": "witness_rssi_too_high", - "gateway": "1121mC1u6mn33czyd4A27mMdcqqvJQhhx1vDoCnKaJqs5Q9Eupsg", - "frequency": 905.0999755859375, - "datarate": "SF9BW125", - "channel": 6 - }, - { - "timestamp": 1628765207102167357, - "snr": 8.199999809265137, - "signal": -108, - "packet_hash": "ZtfDcbFjuzTPB7UmE6a8ayZ5YU5tbKty2kNKGy_GB2I", - "owner": "14kLYw9fQXSp6J8et8aw7dsjmu2brdrjQ5TEwu89HwzNegGmkbj", - "location_hex": "882664c101fffff", - "location": "8c2664c1010b3ff", - "is_valid": false, - "invalid_reason": "witness_rssi_below_lower_bound", - "gateway": "112MfA2QcNo1tHaFsxhc1bbxPmffc36JLKVJka68rzguNu2jfAmh", - "frequency": 905.0999755859375, - "datarate": "SF9BW125", - "channel": 6 - } - ], - "receipt": { - "timestamp": 1628765185766594926, - "snr": 0.0, - "signal": 0, - "origin": "p2p", - "gateway": "112gNnGnMZYovn9R6EKbZgaEHqwdKrwm6CoFqJgDLY5FG4sZ38fp", - "frequency": 0.0, - "datarate": null, - "data": "5rA", - "channel": 0 - }, - "geocode": { - "short_street": "S Winchester Ave", - "short_state": "IL", - "short_country": "US", - "short_city": "Chicago", - "long_street": "South Winchester Avenue", - "long_state": "Illinois", - "long_country": "United States", - "long_city": "Chicago", - "city_id": "Y2hpY2Fnb2lsbGlub2lzdW5pdGVkIHN0YXRlcw" - }, - "challengee_owner": "14n3ByVSSrc8igKxpSJdu8LVjUSxvWUF6X9yrc6ZCQjAipBRa4U", - "challengee_lon": -87.67331063723876, - "challengee_location_hex": "882664cd57fffff", - "challengee_location": "8c2664cd56407ff", - "challengee_lat": 41.784514472384224, - "challengee": "112gNnGnMZYovn9R6EKbZgaEHqwdKrwm6CoFqJgDLY5FG4sZ38fp" - } - ], - "onion_key_hash": "qoZ-y7gAoRwKwo0lW_10HSIo9hotZNf3CZOPdLyoIcE", - "height": 961893, - "hash": "0Q9A9Q0vpobgwy5zdq5EEgyrtQiiLSnZ9_ZxqdqWksQ", - "fee": 0, - "challenger_owner": "13YzYnkGxcznStxSNKG2Pe5MZkLeXP8mopPy9MN1oUd2XbaSTUa", - "challenger_lon": -111.9847594152965, - "challenger_location": "8c28949906183ff", - "challenger_lat": 43.492543017975855, - "challenger": "11278Kh8WzAscpaQsBmF51pTzAT7RNeN4wDk7a8BRyZrF9THqX7F" - }, - { - "type": "poc_receipts_v1", - "time": 1628766652, - "secret": "AAmwte2lkWiov_TrMA7PLKQ9LuNh3Yw478fKqChF8r7uBMHWENO0fhfar33R1YiRfI7JebazKjvrGMfDVzETfTelaBRGKbmqAd7tVZkrAJoNwJPcaXiplcU_R4MByfHU0GE", - "request_block_hash": "FQxvgsvlhiRjgPtaJJ60AD_jpG7DgpJ3VeB31f_LTdw", - "path": [ - { - "witnesses": [ - { - "timestamp": 1628765424434700163, - "snr": -3.799999952316284, - "signal": -116, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13bJN6gEQnVbNXDgUg3LLK5xPMnZK5kG45e7rBzn5WzDNrE9pZM", - "location_hex": "881909ad1bfffff", - "location": "8c1909ad1a61dff", - "is_valid": true, - "gateway": "112AF5d88x362M5fHEuCHFBqLjTAjNWN4ZY3hPFvH4ixdruzyPWv", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424456363563, - "snr": -20.0, - "signal": -115, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13GwYiac5cNKkaNWUYNL5dG4b1cZ57SDqzPEyGEFQFBGYYgNCTY", - "location_hex": "881909aea5fffff", - "location": "8c1909aea4acdff", - "is_valid": true, - "gateway": "112WZVsJefKDrxkyZZdEb7nHqxgmZ3JdcHc51AnDCCb6Bcopd8vW", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424417539370, - "snr": -7.0, - "signal": -105, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13hNAZxPodK8JWoYH9b7YKYgZoYYtp9hhcMuL5FyjngL1cZUUmt", - "location_hex": "881909ad5dfffff", - "location": "8c1909ad5c081ff", - "is_valid": true, - "gateway": "11GgeeHUpTeFoBrrrWNgotfRubrhWJuEc3rXcHeA2ULB71co2dt", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424470630068, - "snr": -13.0, - "signal": -117, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13si5DzphSC6RsJuPDUi1AY9NLU6s5dRwX1pGFeVLdoQdKQPHaU", - "location_hex": "881909ac45fffff", - "location": "8c1909ac44501ff", - "is_valid": true, - "gateway": "11cdE5h5EJgXZpMT8HgEtPEX2PoTiBwWFopxTs6MXA7fCEyW8HM", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424425927288, - "snr": -17.0, - "signal": -114, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13JEP2fzypyNMW2kgVtWkkZQsTDbnHiDoCy8ACAAnwo1vDueiPn", - "location_hex": "881909aea9fffff", - "location": "8c1909aea98c5ff", - "is_valid": true, - "gateway": "112vz6xRKSmfGqZt49SKSigAj64ZtYrm4zMUyyPBPanF75Z96rQ8", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765423422215002, - "snr": -7.5, - "signal": -117, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14N7G2W1w7pgrkxzQSsWBMZTCdqNdXgBT22BZjHEdM6S2ww6S6i", - "location_hex": "881909ad13fffff", - "location": "8c1909ade9349ff", - "is_valid": true, - "gateway": "117xqdDJKLLpPAsCfKiULx37ggyTz9qhXWhjn9j8BpgvMrgAdDz", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424427535122, - "snr": -2.799999952316284, - "signal": -113, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13JEP2fzypyNMW2kgVtWkkZQsTDbnHiDoCy8ACAAnwo1vDueiPn", - "location_hex": "881909aea5fffff", - "location": "8c1909aea566dff", - "is_valid": true, - "gateway": "118aUZDdvpvvoim121C6qNHdr7t2gFzsnz9CZZUzBAadgK5aRSN", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424421008850, - "snr": -16.0, - "signal": -97, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "12yC6CV8cSRo7FX8McmPhYkGqKKkTdDixqSvqK7vnEnZukG4cUy", - "location_hex": "881909ac59fffff", - "location": "8c1909ac586d7ff", - "is_valid": true, - "gateway": "112RSzqabSL2BhFmd1FCphtfuwha2773wqaEDziRxxXbHCENpJkk", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765423265495335, - "snr": -9.5, - "signal": -120, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14KPWXbMm7sB18R3M88uVehqjDyDKVLEwBP9aqiJG5YtX1KMRUv", - "location_hex": "881909ac05fffff", - "location": "8c1909ac05845ff", - "is_valid": true, - "gateway": "11g6ffv4356XMovkVKzmtdaBHVhf3XFN6jdQa6DAve1Dgtncv2A", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765423265381877, - "snr": -19.0, - "signal": -120, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14tL7QvkLn58FGdkR6wUqYMPwGGEdDgSPFfRaQYwEwP8aQDLqEt", - "location_hex": "881909ac47fffff", - "location": "8c1909ac47741ff", - "is_valid": true, - "gateway": "112eo5VuyZX8bYVwVUmHLZmi2ZCXgM7nQ1RsJjra6FGXKZr8QEn", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424440965605, - "snr": 3.0, - "signal": -109, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13DeeXRMk4v31QhsWDwQcnvJxMBCCEV9PD7sorgakW6mZrruEJW", - "location_hex": "881909af3bfffff", - "location": "8c1909af3a75bff", - "is_valid": true, - "gateway": "112zqWUECYhTiHiutmG2gd3jtPmRPCBLZzjjWsNsJbXBovhKaVR", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424466688229, - "snr": -2.5, - "signal": -115, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14m5kNkmerjBgwzLWEydAnxbp3rEWwUmMCzD5oDMbqDJnTpWgBS", - "location_hex": "881909a887fffff", - "location": "8c1909a886d45ff", - "is_valid": true, - "gateway": "1126JtCB57yF2RWhkJuGP3AoVdk9xW8C2RmNWKjbhbrWK5VfZDYi", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424472367114, - "snr": 6.800000190734863, - "signal": -101, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14GCtE2PYGfsVCTpE2fjVBhYRg79M32NCMerzVrqhNq92gfv1ji", - "location_hex": "881909ac29fffff", - "location": "8c1909ac28a17ff", - "is_valid": true, - "gateway": "1121kTyLMmpvoCZ9UyHbDV58k7rGKk3BGnTDgfdba8WJKuvN6g23", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424430869339, - "snr": -14.0, - "signal": -117, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13rrHzhFTjshUXpSbgEjv36VbfCheQxLHbEoWP8rvYfruPjzGxB", - "location_hex": "881909ae35fffff", - "location": "8c1909ae34353ff", - "is_valid": true, - "gateway": "11PUAZFdYcfg9Ppibdvrr6nSC3SVzvFmpZEVgpRoo9LyT2wpr3M", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765423436009880, - "snr": -4.199999809265137, - "signal": -117, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13T3kStiuTYri949cqV2xqpwLnTRvZqrAVXhdymWDQgsHuzdHUV", - "location_hex": "881909ad41fffff", - "location": "8c1909ad43b61ff", - "is_valid": true, - "gateway": "11ngeyAQtbJ8cH5hQzBn3TFLppAVd7PmBzu5XWEKn74PA9YBVPr", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424423702518, - "snr": -3.799999952316284, - "signal": -115, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13si5DzphSC6RsJuPDUi1AY9NLU6s5dRwX1pGFeVLdoQdKQPHaU", - "location_hex": "881909ac51fffff", - "location": "8c1909ac51159ff", - "is_valid": true, - "gateway": "112nwpawRaXKKKZdccBuMvJkosaC9rjpSJBpQyeUZAXmtzLWLFqL", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424432014748, - "snr": -5.0, - "signal": -115, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14Kw64DJbgw2hNaVy4Yv6jmRgXxEG25zkSncfoFR59WaPMU7Gjn", - "location_hex": "881909af13fffff", - "location": "8c1909af121c3ff", - "is_valid": true, - "gateway": "112GMnq7voQSrWV9D2RAm7f5sDDrzdYgxCUvZEbjKhSExbXjtWyZ", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765423459374418, - "snr": 2.200000047683716, - "signal": -112, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14c58TiKhzq4DHRZkjDCDnWvj2ajG75pJJiKW3rPYs5ddRRrkqD", - "location_hex": "88190932dbfffff", - "location": "8c190932db913ff", - "is_valid": true, - "gateway": "11PmhASYzRTNDMjDm5AYQ2psvbfZZgvb8GBR56emyhR5BmxY4iT", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765423360136460, - "snr": -16.799999237060547, - "signal": -121, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14KPWXbMm7sB18R3M88uVehqjDyDKVLEwBP9aqiJG5YtX1KMRUv", - "location_hex": "881909ac15fffff", - "location": "8c1909ac1403bff", - "is_valid": true, - "gateway": "11FukpK8QpNY2RyMAaiYrESQAZeG5SKhK7ibBoksQQFrj669mrJ", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765423497045419, - "snr": -11.5, - "signal": -119, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14KPWXbMm7sB18R3M88uVehqjDyDKVLEwBP9aqiJG5YtX1KMRUv", - "location_hex": "881909aeabfffff", - "location": "8c1909ae84d85ff", - "is_valid": true, - "gateway": "112mggxyZAGdRgq3MjFt66U7eWBX31nZfd9sz1st1bXPVU6Z1C86", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424457842467, - "snr": -10.199999809265137, - "signal": -113, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "13si5DzphSC6RsJuPDUi1AY9NLU6s5dRwX1pGFeVLdoQdKQPHaU", - "location_hex": "881909ac41fffff", - "location": "8c1909ac41489ff", - "is_valid": true, - "gateway": "112CGLKP5KszpsZ9qwKKNcHdLpxLSDvUL8dbydoPyFTRxiJuKZH8", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424464395913, - "snr": -8.199999809265137, - "signal": -117, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14KPWXbMm7sB18R3M88uVehqjDyDKVLEwBP9aqiJG5YtX1KMRUv", - "location_hex": "881909ae2dfffff", - "location": "8c1909af536d3ff", - "is_valid": true, - "gateway": "112o1NixfLhdpydyDCXz719HS9eCXe34mwvMRGwLqxwNvLVd1CP8", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424412629521, - "snr": -22.799999237060547, - "signal": -115, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14FKrrsac9djE9x4VtLSnHAK8jjtHf24EU5pr4SFhesnxSqYzur", - "location_hex": "881909ac0dfffff", - "location": "8c1909ac0c1d1ff", - "is_valid": true, - "gateway": "11PtrTACfTTeQbprvztGew9CxAtLrUejBXYkf7n6hT86W3BSzmQ", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424423269561, - "snr": -14.5, - "signal": -113, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "134YnuYPdQsDZHmZNoub8o4idFwo2JN5gnQEjyVKmwhBsHYwHGx", - "location_hex": "881909ac55fffff", - "location": "8c1909ac5528bff", - "is_valid": true, - "gateway": "11om3qnHExXjSoEcRnYXHBn3aJgZuet1TZpocy1JszPpjch7oee", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - }, - { - "timestamp": 1628765424449583552, - "snr": -9.800000190734863, - "signal": -117, - "packet_hash": "jt0cfl_M5YlKGqjg4g9OIyXqnhKFAlOcvAD5iT4dkmE", - "owner": "14GCtE2PYGfsVCTpE2fjVBhYRg79M32NCMerzVrqhNq92gfv1ji", - "location_hex": "88190932d9fffff", - "location": "8c190932d9b53ff", - "is_valid": true, - "gateway": "1177nPg3TdTYe792RsjLiSSgcYRE5L8Cau65iSb74gUsx4ZPxAo", - "frequency": 867.9000244140625, - "datarate": "SF12BW125", - "channel": 4 - } - ], - "receipt": { - "timestamp": 1628765420868323704, - "snr": 0.0, - "signal": 0, - "origin": "p2p", - "gateway": "112Xa9YnzeaHTDgvWu4jT7a8X1dbrCA6Z7NdqVgcWWmJZHG347Jz", - "frequency": 0.0, - "datarate": null, - "data": "PDg", - "channel": 0 - }, - "geocode": { - "short_street": "Northinch St", - "short_state": "Scotland", - "short_country": "GB", - "short_city": "Glasgow", - "long_street": "Northinch Street", - "long_state": "Scotland", - "long_country": "United Kingdom", - "long_city": "Glasgow", - "city_id": "Z2xhc2dvd3Njb3RsYW5kdW5pdGVkIGtpbmdkb20" - }, - "challengee_owner": "13bJN6gEQnVbNXDgUg3LLK5xPMnZK5kG45e7rBzn5WzDNrE9pZM", - "challengee_lon": -4.3333950631107445, - "challengee_location_hex": "881909ac67fffff", - "challengee_location": "8c1909ac66a23ff", - "challengee_lat": 55.872184630180406, - "challengee": "112Xa9YnzeaHTDgvWu4jT7a8X1dbrCA6Z7NdqVgcWWmJZHG347Jz" - } - ], - "onion_key_hash": "ERB1iWfyG5vAHu0vtAqz2vQiwNb7G6JJSaKq9yQcsN0", - "height": 961893, - "hash": "1-rYXddPomReuV0G7yECpqk_v_aunoOD2KAQi5Ixq5E", - "fee": 0, - "challenger_owner": "13pn9WuY9QhhwhCFjmFFCtVoLr5r8kN6sAy6wVdn8wU5QhiPnty", - "challenger_lon": -122.28523730760215, - "challenger_location": "8c28342952027ff", - "challenger_lat": 37.48742558269628, - "challenger": "11291vAUs5Q9f5dnbanfchzApMfdip2kWVUTzvp2kFupxoqAYcuw" - }, - { - "type": "poc_receipts_v1", - "time": 1628766652, - "secret": "AKizy8P9tWeBDfpeACwzYFdMUlVOV70cxvX-gdBLGvjDBADcU2TvtOwy-f8ZX7CVSyXdVS0O7EKKRbx4TcGQLdfkAbDHN_W8JKX1U3s3oxtmrRCvWp3VEQpo72R0wpaO4CA", - "request_block_hash": "zGXC4FsK4P8Muwv1m9fIQcdc0Xph2s3sBK387Myhtd4", - "path": [ - { - "witnesses": [ - { - "timestamp": 1628765499799000786, - "snr": -8.800000190734863, - "signal": -107, - "packet_hash": "dnHdNKyGyAgPf_bzWIgXOskvO0KNDRwZdqKuTH2vxJU", - "owner": "14jF6o775mdvRTiqeCfF8pgQ9imgEGiJYfb2wYCDUA3DD9a471f", - "location_hex": "882baa44a1fffff", - "location": "8c2baa44a0143ff", - "is_valid": true, - "gateway": "112Af45B8bCcaQzfTwPvwsEwfKjgd6fpZndC8EwWiGQ8SkpBvqAN", - "frequency": 904.0999755859375, - "datarate": "SF9BW125", - "channel": 1 - }, - { - "timestamp": 1628765498937953663, - "snr": -4.800000190734863, - "signal": -94, - "packet_hash": "dnHdNKyGyAgPf_bzWIgXOskvO0KNDRwZdqKuTH2vxJU", - "owner": "14qHxW3wwEonzJJrVPZ78BXZujPeHvdn2fo4iZ4YQ2kLUwkZXtm", - "location_hex": "882baa44a1fffff", - "location": "8c2baa44a0a0bff", - "is_valid": true, - "gateway": "11rb9hpfByyD5LhW9KA4jwxyZf63FN19jyfCWK1XBVoArdPd9su", - "frequency": 904.0999755859375, - "datarate": "SF9BW125", - "channel": 1 - }, - { - "timestamp": 1628765499870141984, - "snr": -12.0, - "signal": -95, - "packet_hash": "dnHdNKyGyAgPf_bzWIgXOskvO0KNDRwZdqKuTH2vxJU", - "owner": "14jF6o775mdvRTiqeCfF8pgQ9imgEGiJYfb2wYCDUA3DD9a471f", - "location_hex": "882baa44e7fffff", - "location": "8c2baa44e75ddff", - "is_valid": true, - "gateway": "114FmXhJcRPhCTZpm4xy4pKBXsKpvTMZNV7S8JCZvfgp3rPMHVh", - "frequency": 904.0999755859375, - "datarate": "SF9BW125", - "channel": 1 - }, - { - "timestamp": 1628765498807608576, - "snr": 7.0, - "signal": -90, - "packet_hash": "dnHdNKyGyAgPf_bzWIgXOskvO0KNDRwZdqKuTH2vxJU", - "owner": "12zJi5Eofftpcb3gEvGsXyfm68mwoQor94dPgEmBerzz9gfrNyN", - "location_hex": "882baa44a1fffff", - "location": "8c2baa44a0aedff", - "is_valid": true, - "gateway": "11WAHV6HyRUzw8HY1Xh9zhEsRnKRBGKm8H2Zz4JQ4mmhBEyr8Ea", - "frequency": 904.0999755859375, - "datarate": "SF9BW125", - "channel": 1 - } - ], - "receipt": null, - "geocode": { - "short_street": "Côte-Des-Neiges—Notre-Dame-De-Grâce", - "short_state": "QC", - "short_country": "CA", - "short_city": "Montréal", - "long_street": "Côte-Des-Neiges—Notre-Dame-De-Grâce", - "long_state": "Québec", - "long_country": "Canada", - "long_city": "Montréal", - "city_id": "bW9udHLDqWFscXXDqWJlY2NhbmFkYQ" - }, - "challengee_owner": "14jF6o775mdvRTiqeCfF8pgQ9imgEGiJYfb2wYCDUA3DD9a471f", - "challengee_lon": -73.63483027462887, - "challengee_location_hex": "882baa44a5fffff", - "challengee_location": "8c2baa44a4015ff", - "challengee_lat": 45.46662067582368, - "challengee": "11VhN1wRVc4VkyN7d6mA9TDTV6xRy1sEHYZe79dabg4tHcG8Uxs" - } - ], - "onion_key_hash": "e_GRB3_UvVZa45FUvXntapFYlaWqI3szOfg0Fa4jd3c", - "height": 961893, - "hash": "1Y4ZsEqLdIOrlMWkha3TxQvebvNokFP9rUNIHanj-KM", - "fee": 0, - "challenger_owner": "13hmaYVZNTtPZzs62uunGMVFtYzaDRj2Lo212R46HegiPL9tBp4", - "challenger_lon": 9.159697809385476, - "challenger_location": "8c1f99508a6dbff", - "challenger_lat": 45.36202604804098, - "challenger": "11f6YvG8QZtBWZpTssHeQQE1ZT9hShPeZQagBPQWyzRaXdJtMfM" - }, - { - "type": "poc_receipts_v1", - "time": 1628766652, - "secret": "APnamrTomAaCnggW0-xKqGHB7finwcTE-wRxH8ew85FOBBwwUTNLX3SPw1z0gPZ3Ixr6dyUb02bZLdf6S5DRKKpOF6tTsy4et574-HgzRNCy0qP8pDT0-2WTbygtR1EyNd0", - "request_block_hash": "jZRwpQwVG304mI1NVadWM-anjWAYIZObuKm5ohjQbFc", - "path": [ - { - "witnesses": [], - "receipt": { - "timestamp": 1628765144196635236, - "snr": 0.0, - "signal": 0, - "origin": "p2p", - "gateway": "11g4WN6faxkoAAbnoLtWqGwX3dMBJwMGBDF5Zi9h8ZDXRADRcw9", - "frequency": 0.0, - "datarate": null, - "data": "RSY", - "channel": 0 - }, - "geocode": { - "short_street": "4th St", - "short_state": "IA", - "short_country": "US", - "short_city": "Odebolt", - "long_street": "4th Street", - "long_state": "Iowa", - "long_country": "United States", - "long_city": "Odebolt", - "city_id": "b2RlYm9sdGlvd2F1bml0ZWQgc3RhdGVz" - }, - "challengee_owner": "14F6kntXrbYNiijKSPoYa7s9fkNoyv8vifAHBa133aKQobEhL7E", - "challengee_lon": -95.26063762838024, - "challengee_location_hex": "88260cc71dfffff", - "challengee_location": "8c260cc71c289ff", - "challengee_lat": 42.310328735983994, - "challengee": "11g4WN6faxkoAAbnoLtWqGwX3dMBJwMGBDF5Zi9h8ZDXRADRcw9" - } - ], - "onion_key_hash": "4Bh0b5pO2cdW00u2Jvi5ouNuN791kZ0RgFcPkRloYGk", - "height": 961893, - "hash": "1Yx8GTt15gi3unU2RyAPAhjExFRF2J-gLU9v0e83nBU", - "fee": 0, - "challenger_owner": "14maPdZ1bLHK2fJoEHLaKWfBKBhyYnAEoqkNtuunPSCzD9QFMz3", - "challenger_lon": -3.7750320650586113, - "challenger_location": "8c195ab94a537ff", - "challenger_lat": 51.656877310336775, - "challenger": "112n4p5XRYuJLpHxWZ3p7Zj3dyGrqikGag5cLSdtn1BEfhAMCjoG" - } - ] -} -``` - - - - ---- diff --git a/docs/api/blockchain/cities.mdx b/docs/api/blockchain/cities.mdx deleted file mode 100644 index a1f10ada7..000000000 --- a/docs/api/blockchain/cities.mdx +++ /dev/null @@ -1,279 +0,0 @@ ---- -id: cities -title: Cities -pagination_label: Cities -sidebar_label: Cities -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/cities ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Deprecated Endpoints - -### List Hotspot Cities - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/cities -``` - -List all known hotspot cities with the total hotspot count for each city. Use a search parameter to -filter the list of cities with the given search termThis route is paged with a `cursor`. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ------------------------------------- | -| search (optional) | _string_ | term to limit the list of cities with | -| cursor (optional) | _string_ | Cursor for page to fetch | - - - - -200: OK - -Lists cities including the word houston in their city, state or country. - -```json -{ - "data": [ - { - "city_id": "aG91c3RvbnRleGFzdW5pdGVkIHN0YXRlcw", - "hotspot_count": 52, - "long_city": "Houston", - "long_country": "United States", - "long_state": "Texas", - "short_city": "Houston", - "short_country": "US", - "short_state": "TX" - } - ] -} -``` - - - - ---- - -### City for City ID - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/cities/:city_id -``` - -Fetch a city for a given city id. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ----------------------- | -| city_id (requires) | _string_ | ID of the city to fetch | - - - - -200: OK - -City for id `dG9yb250b29udGFyaW9jYW5hZGE` - -```json -{ - "data": { - "short_state": "ON", - "short_country": "CA", - "short_city": "Toronto", - "online_count": 1077, - "offline_count": 172, - "long_state": "Ontario", - "long_country": "Canada", - "long_city": "Toronto", - "hotspot_count": 1249, - "city_id": "dG9yb250b29udGFyaW9jYW5hZGE" - } -} -``` - - - - ---- - -### List Hotspots for a City - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/cities/:city_id/hotspots -``` - -Lists all known hotspots for a given `city_id`. The `city_id` captures the city, state and country -and is included in the city list result.This route is paged with a cursor. - -The `filter_modes` parameter can be used to filter hotspot by how they were added to the blockchain. -Supported values are `full`, `dataonly`, or `light`. A comma separated list (no whitespace) can be -used to filter for multiple modes. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | --------------------------------------------------- | -| city_id (required) | _string_ | The id for the city are returned by the cities list | - -_Query Parameters_ - -| param | Type | Note | -| ----------------------- | -------- | --------------------------------------- | -| cursor (optional) | _string_ | Cursor for the page of results to fetch | -| filter_modes (optional) | _string_ | Filter hotspot types | - - - - -200: OK - -The list of hotspots for Montrose, New York, which is city_id -`bW9udHJvc2VuZXcgeW9ya3VuaXRlZCBzdGF0ZXM`. - -```json -{ - "data": [ - { - "address": "11C5PW3fe5RmBV7jvdmBJmjH7FjiZ3URAZ5oUj2V9dVsW83a5wU", - "block": 403147, - "block_added": 356922, - "geocode": { - "long_city": "Montrose", - "long_country": "United States", - "long_state": "New York", - "long_street": "Dutch Street", - "short_city": "Montrose", - "short_country": "US", - "short_state": "NY", - "short_street": "Dutch St", - "city_id": "bW9udHJvc2VuZXcgeW9ya3VuaXRlZCBzdGF0ZXM" - }, - "lat": 41.24450048207128, - "lng": -73.93189556758152, - "location": "8c2a10c020007ff", - "name": "delightful-onyx-swan", - "nonce": 1, - "owner": "142dmsAe4qVmNxdZJuQiFmpSnB9p6wBkAX78MVza1yNrF4t5R6e", - "score": 0.25, - "score_update_height": 403138, - "status": { - "gps": "no_fix", - "height": 403025, - "online": "online" - } - }, - { - "address": "112PSCgC7kXWFnKWrczNL6srYKQpg3VdA9iou6FrQW4C1aot5HPc", - "block": 403147, - "block_added": 355849, - "geocode": { - "long_city": "Montrose", - "long_country": "United States", - "long_state": "New York", - "long_street": "Sunset Road", - "short_city": "Montrose", - "short_country": "US", - "short_state": "NY", - "short_street": "Sunset Rd", - "city_id": "bW9udHJvc2VuZXcgeW9ya3VuaXRlZCBzdGF0ZXM" - }, - "lat": 41.24464436633493, - "lng": -73.94293581685558, - "location": "8c2a10c024e1bff", - "name": "wobbly-lipstick-manatee", - "nonce": 1, - "owner": "142dmsAe4qVmNxdZJuQiFmpSnB9p6wBkAX78MVza1yNrF4t5R6e", - "score": 0.25, - "score_update_height": 403097, - "status": { - "gps": "good_fix", - "height": 402961, - "online": "online" - } - }, - { - "address": "112Byc2EoL1yB7zyfC9ve2HayLoFf9WLvJdTDtevMsmkfxu9GAA1", - "block": 403147, - "block_added": 94932, - "geocode": { - "long_city": "Montrose", - "long_country": "United States", - "long_state": "New York", - "long_street": "Sycamore Court", - "short_city": "Montrose", - "short_country": "US", - "short_state": "NY", - "short_street": "Sycamore Ct", - "city_id": "bW9udHJvc2VuZXcgeW9ya3VuaXRlZCBzdGF0ZXM" - }, - "lat": 41.24524348318981, - "lng": -73.93254191072695, - "location": "8c2a10c020337ff", - "name": "smooth-cobalt-cougar", - "nonce": 1, - "owner": "142dmsAe4qVmNxdZJuQiFmpSnB9p6wBkAX78MVza1yNrF4t5R6e", - "score": 0.25, - "score_update_height": 403117, - "status": { - "gps": "good_fix", - "height": 403026, - "online": "online" - } - } - ] -} -``` - - - diff --git a/docs/api/blockchain/dc-burns.mdx b/docs/api/blockchain/dc-burns.mdx deleted file mode 100644 index 32f5f275b..000000000 --- a/docs/api/blockchain/dc-burns.mdx +++ /dev/null @@ -1,287 +0,0 @@ ---- -id: dc-burns -title: DC Burns -pagination_label: DC Burns -sidebar_label: DC Burns -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/dc-burns ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Solana API - -### DC Burn Totals - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/dc_burns/sum -``` - -Returns the total Data Credits (DC) burned for the whole network in a given timeframe. Timestamps -can be given in ISO 8601 format (e.g. `2020-08-27T00:00:00Z`) or in relative time (e.g. `-1 week`, -which, when url- escaped becomes `-1%20week`). When omitted the current time (UTC) is assumed. - -The results can also be bucketed in time by specifying a `bucket` query parameter which buckets -information per bucket in the given timeframe. Data is bucketed by time. Valid bucket values include -`hour`, `day` and `week`). - -For example to get the last 7 days of DC burns bucketed by day use the following path/parameters: - -`?min_time=-7%20day&bucket=day` - -The block that contains the `max_time` timestamp is **excluded** from the result. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | ------------------------------- | -| min_time (required) | _string_ | First time to include burns for | -| max_time (required) | _string_ | Last time to include burns for | -| bucket (optional) | _string_ | Bucket specifier | - - - - -200: OK - -Return the last 3 hours of burns bucketed by hour - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) [DEPRECATED] - -::: - -```json -{ - "data": [ - { - "add_gateway": 240000000, - "assert_location": 71000000, - "fee": 12250000, - "state_channel": 98216, - "total": 323348216 - }, - { - "add_gateway": 276000000, - "assert_location": 107000000, - "fee": 14330000, - "state_channel": 61638, - "total": 397391638 - }, - { - "add_gateway": 364000000, - "assert_location": 118000000, - "fee": 16265000, - "state_channel": 90848, - "total": 498355848 - } - ], - "meta": { - "bucket": "hour", - "max_time": "2021-06-25T21:09:43Z", - "min_time": "2021-06-25T18:09:43Z" - } -} -``` - - - - ---- - -### DC Burn Stats - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/dc_burns/stats -``` - -Returns current statics for for Data Credits (DC) burnt for the whole network. - - - - -_No Parameters_ - - - - -200: OK - -Return the current DC burn stats - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) [DEPRECATED] - -::: - -```json -{ - "data": { - "last_day": { - "add_gateway": 4660000000, - "assert_location": 1486000000, - "fee": 245860000, - "state_channel": 1150548, - "total": 6393010548 - }, - "last_month": { - "add_gateway": 100348000000, - "assert_location": 35019000000, - "fee": 5784740000, - "oui": 90000000, - "state_channel": 31932182, - "total": 141273672182 - }, - "last_week": { - "add_gateway": 25060000000, - "assert_location": 8483000000, - "fee": 1425110000, - "state_channel": 9392114, - "total": 34977502114 - } - }, - "meta": { - "timestamp": "2021-06-25T21:10:14Z" - } -} -``` - - - - ---- - -### DC Burn Events - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/dc_burns -``` - -Use this API to list DC burn events. Events include a block, amount, type of burn, and the address -of the account the DC were burned out of. The oracle price that was active at the point the DC burn -happened is also listed to enable calculating how much HNT the burned DC represents. - -Note that this route does _not_ return the implicit HNT to DC conversion that happens when an -account does not have enough DC available for a given transaction. - -This route is `cursor` paginated. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ------------------------ | -| cursor (optional) | _string_ | Cursor for page to fetch | - - - - -200: OK - -Return a page of DC burns. Only a segment of the returned list is shown here. - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) [DEPRECATED] - -::: - -```json -{ - "cursor": "eyJmaWx0ZXJfdHlwZXMiOiJ1bmRlZmluZWQiLCJiZWZvcmVfYmxvY2siOjg5NjU5OCwiYmVmb3JlX2FkZHJlc3MiOiIxMTJhaFRTWTRIcWh4cDdhMjFhN3dKeEdUWVR0SlpvUzdpR2twakhvOG9TZHl1TlpHbnhNIn0", - "data": [ - { - "address": "13RkeC4sk3sxun6DEyDpv2CxPigupdDtbheQAHcczNdpsnp4KZL", - "amount": 35000, - "block": 896602, - "oracle_price": 1132580000, - "type": "fee" - }, - { - "address": "11w77YQLhgUt8HUJrMtntGGr97RyXmot1ofs5Ct2ELTmbFoYsQa", - "amount": 35000, - "block": 896601, - "oracle_price": 1132580000, - "type": "fee" - }, - { - "address": "1121FXJk5ppcMHyXUtuZEXA9CuF5D8GSmh3h9zyqpzajmuQgLLZT", - "amount": 1, - "block": 896599, - "oracle_price": 1117000000, - "type": "state_channel" - }, - { - "address": "1129LAbCTPjppeErYY1AbbzeAjWsjkbrk1kVtvrNztVjyW2A3CXr", - "amount": 9, - "block": 896599, - "oracle_price": 1117000000, - "type": "state_channel" - }, - { - "address": "112i8wtfaesP1EQNYz44BbBCzTvkooC9ydVEcMKjhSPykfabYXUb", - "amount": 9, - "block": 896599, - "oracle_price": 1117000000, - "type": "state_channel" - } - ] -} -``` - - - - ---- diff --git a/docs/api/blockchain/elections.mdx b/docs/api/blockchain/elections.mdx deleted file mode 100644 index efb198b45..000000000 --- a/docs/api/blockchain/elections.mdx +++ /dev/null @@ -1,183 +0,0 @@ ---- -id: elections -title: Elections -pagination_label: Elections -sidebar_label: Elections -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/elections ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Deprecated Endpoints - -### List Elections - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -Lists elections by listing `consensus group` transactions. - -``` -GET https://api.helium.io/v1/elections -``` - -Use this API to list `consensus_group` transactions. - -This route is `cursor` paginated. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -Return a page of `consensus_group` transactions. - -```json -{ - "data": [ - { - "type": "consensus_group_v1", - "time": 1628764411, - "proof": "g1AAABMIeJxN13c41f_7B3COjiMSGR3bMXJkZEVG2TMhe2aPzrGJQmRvH-OIHLKOLSMr2VtG9t4jex5RThlfuX6H31_nn_u6Htfz9brv1_s-djg4OJwvAfYXP0w47KQaDEKfYcBzgEwZCDSBqZnixhQDJT3Qq6HPC29Lbv-rkueVBUAoFT_ho6dPn8oC3IlYFw4p8vy2E6P1oUf0Hu8bLBk7eQAQLnSct20F8JVeN5ldzYtlzU0J6IcD81b_ct7j_Gwdv34sGUO8o_v5rkjE7q6kHfU3Vpk_5mjvtjMIy7EcebxtW4TnFWl-8vNJ1pxiTqMThf-irpUVsL1JnqPV1GRhufYnIdkLGQBErW4y51bmBtCLVOKX0pMNnVwSkW498qDC7OUxKY4OZzCWZJuS01NWDQJZzz6FIaLmRCT1Mff0GLNkjLWZDjjnOiivyXxO_SpoT1_KyC_rpT0DOn3fqTrO5rdRNkLSTqcopWAAhDlrwQYmctBZchL7d9Hsj8fhQvoYCy0v4QvrBAqrL3sEWNJG8qlQndgBenIMyXIWNhT2afU4eWmEJ3u8e4pmgZ9o4F-VAq8cgAmnDMLj6SidHIEr9_4euUhO5NQ-m6LW_I99vARW83sVseMAiAUb-YGwKRE1XODFQC03kUq6cnzRt30c1qrYMHGH5fnJ_zNxc9JtLFcJHiaQyN1rjdvT2Gu8GwsRjS5KxPM8NUljN3r0r0rSsMkTV673wcrUiuDB13AJTUAb5JllcjdU-OEWzV6ZrO7civLtxe8dTQ-q_oKrKMori36sRdl-bs4D048ptHPD8LDY3INwxRqllyFhmtxSKv-N-JiRNqevJt98_O1z_VqTCrzrElNDckQz-Wcd1DurmiNznsUJbpGdW5JHyqyoq4ipHuHW5opyTfFwjVSH6EQhHCT5oTi5aaM28dkAnegtL-bkECD2NDXsFQUjEkHPB-0kJJccBmG4klxdvraZXqNCJ7QHUiPR_6oUeeUvTrOPfy8omZHU52zFeZTFHRRPxdRuRCD6-MhHBT1ZOJqgclESMjQ3AtHr-YBxbFfolU6Z3j5f6DHTqQdXIU5u99HoB2IT_iKY3Ul01BhVcttv-uLqZ9UXyaDoQiYRLSDnOcq87Y-6TFhm7bzARk7ooeAlkSsOQ6WkSvaC7W6u4L4RdMlld0TRMBMkfsxDyD0eBwqebTXfAX4pR_XfrAc77HUW-3BvCuJgE4IfwrpSgm8xT5fwsjDmB7vkiEWE_97w7a38ihgLc00Zv-6X8QMX4xCqWYuetvJW-hdEqQhe-ONtzPpbbl3HaY1UlBMAYtOr8UWoRHl-zxAIBa8mv86PaSKMlSNsb2SdYFNyhnVjzddI9-I7s_YqS1AEXjlELXfVoihtEjT8rSmhYjPUWZ7--lSHBvqoe1MGyAanDNtEgwszp8DQDsm9D-hwNmhSXzmOxb82Tn-7rZqciu52f1JWGF-UFdNu8OecYgU-ZHD-bOzJ3WEsKrBuqOfdVz2P96RrDXPS3H1S6sRe7Xir8kf3yVClixMMGxTCecjx7vxmHeczYfDcw9z2baJpMu8qzFjcQPgTjlDJc9wLM3Jmf2cqkQ7OaEUrrdU2qm0N-KqAy9dRT9OR1nJDjFUVa5q2NOgKmFkgeB18d3pUCX3HeB786LIm88ekT7wnG9REXh_uocSO6GcUk5_qoukaqcUBldFB4CGO8uPEHbieeK_IxDAAwmiy3JoBireBnXMn-GBa1Fin8HBPJNjG1Drvo8QnUd-vTGGQbtAXU3g7nXzMayocXVn3nRt_glDfHR3d2FjeTPVdm5WaHbiQWF54ZHbbMJ5ujpwHZZ3ILrusFc8cp7ijwt4QAGKUvgYVDg5hAsNcy-mjXR1wc3TyNZbW7vrpJpaNzLjWYzu2O_hJ627yfH9Qh-df1a0tZItUBfBbn4jOK39IU4Ofccxlx6q_ItoIjImZR0VRxorPnY6z_eJDb2zmwIMfVcD6JmZz-QQaKfA1nb0saT_vDv7dTkfWvGXMF3cSpKU7Vk4lmMHHBtQT6PJC_24IlPZY2v60GWG7h-wiKN2zSfkajXhZ_z6D77p7kvbDFd90z95zUJAw6OD_L-JJ9bS-Cp5WSFizm8ECkqPiomQANh9XFhhmIUUz7e_JqU8yldjK9b0QeVaQSThIC_rwDpvwjEedu-ugljawyjezCJhOV0f8ioXA-Gd2KyJIH0_fquwy4buuiPUUn-7fLIo4x2Z1IZD42FucA_cf2DX8-haM-tjHyFfIyyldeN4zMSwTyWSD2MfIpIY3zwy5rTHLqaWzu2FnEtfMXgWX-0yH1XjFuX4llun-CX8csfla2TcLUipZahzXy4SSo6H2ao7U-0-5MtNWWDpyZQ6JFbo5ZfvtcfUTHG1fPWf99m3IMtB3s0amZAn3GPwsEmEn0zhSplXYU4dqz9tSuHoAZM9jGGDCIynEMt8NiHxa0L5dpk7bvxseOWjdNX5DpGR09Y165fS3bBrUuwjrgJ_Of_ySoTasfqhJ9_QO7bTzRoRCVgAAIuRKT6osx5ca9KDzbHNkmh2xafFWcWzkHlXXlLkwSfUMNp-X5391jaxiI7SLonuU2jQz_OT9b6zEw81uCjFtJLNoDF3mE-3vqmBv19t166ViLPaeG9YErwOCTqQYyGCAgckjmbqV3028Y34_T6AtmCbLNlpoxfzp63syax72_emrpSrLN7D5VJEgFc2Ou1DzJDqI8d5ckYYXR71g4I39APhUM8hPL_V6HtpOe96sRyLYMYr9JvQ_XLhK4iqTAkYfn5WK13pYhCRSACDu0VzxDV8M_YGKv0PwUrLdxZMs-yuKSUYxgRk-JKH67tiAoos6nQc7LnW_1L-qhIZKEk0PPXfsAgUgLD1mn24eG0xfBnzM1MZgeGyAeK9dIDopozxh3qrz31ggSeIiNepUSfR99y4Dx7OsZ0275QQxCP7KUrQ3aH17Ln48-nOY_x1j_HeE2IDm9niqc9y2ejW9X0Mln34OQVHyGd1uCCcJ7nW_K7qkknQd8K86O5IjyuS74TtTIUf574QnDX1NEhbIG0L-DQ6zUYaLAIiW27tQsdVhJlu7_oOX08JaUoc2p3_CaTissun0jlczS7EBBXernJNm1gmK2Or6KIM-ATS2TGULEZNJspW2SGNwc9hlwAMSjXK_NPeCgJy0vSkNm1Dw0TbmDo_WymLxoDYo46kvCzwuQGSs1QRi_zReL-Sm83Pp6HBR7tXckwypybdVDcRYbDPihCS0AB7e3jYe1IMJT_ego8-eVDtIQeYYxqXVvua-xMiTB93AjptAEHIglsmnkBNxekNbiaead7JmdAr0teQYZ_tdUd3dMhIyRtxpETSviUAeoUYBNfnDGagc7P6E820sJvGQwqd-ny5vslDVOyvAYM_q78cnrrCM403TsdBbsoSPL7HsR6wawKpHzDVbYyyB52IIf0PivDF8BA-P6cv75t7yeWyw8PkfYSJlSurMIR060agq5rQQQI9k52b46onnhs9Vb1LlF7Xq4XixupHN81HwvhXYb0DRojdJnJSEThs7S0oQV7P31kG1OIPX5ZGO9ewLOMXZ-n2TAqvnIBmGr5WdqK8ltrUACM4Z4JGD8VmN39oJKT-3L-37Tcl7QLQJH8ddYZpdDWLs64l7awPv5RvqGwFoVKaGt4WY6IxY8ef-1sAG85KK8hHq0weX-YLjD6XLpeVSZ0uE5hIsFbJ09HGK2Yx51czdeca1NlibBN_JF_b8bBjQFnuWujVQrFoPIrEz3HcDHoUmn7v7vbxqzVmoMxx-nBsQh1_G0RYI330GS_n8wdoSki7mxDBoNFj7r0qOVwbAqMSIn0VOtn8OQD2C3jsZ0Arr_4E3BSaS4VNNrqT-Enix_or5EeqL691VlbAUkau3VA04ztf5ZaXF4xD96kVYy4Q4ViwQ_lpcEbOKOhKSMX6ZVKjqUmEx1XDnwY5_qzX8J77ZrauvvPadYPx4NqMyrnxu4VkaoXmBXX158_oxGU_vtt4v7TbRF-OCgq0DDUUWw-kemw-jTdFS7mqUCqdaZy1dHfjfDB2se7EmJvGNU2R5Nb5NAUDBm6hevnAuWbE42reZVfJQg2K__fuViWt_S7Ehc3LeHpnm62Pu6rJDgaYkqOqfwJ1ZNhCgKL59YU6VBLX7_Dd-2-VE5dUURCHKvUaYuK7Q3OBllemrNJgtdrPAffkn9kPSYplwBJXRWZbN-S4G94XsiEcEbIpZssU1zvfN5TWONw8VCPxi6eFeTpMtm9QfoonJ0VyYXx5I7bz_MUoXWPZTm7pZ1qbELbVD3Kh5rSFpQDv-E3WxxlGisb-dLcnR1QDygns6NhRFKFaoLUDQAGekfVlPbYBlBv2Dwa-dGI_So0vM2MWHxR8HaqxL-KaQjwj5XRFdAxqUHrI8C_sLtSaJVcgfEYuRnHu-HdE-qldar8NtaJZfzrDh4CHmMoFn-PA9CIv9zAPwxMf30XtyETj4MuHAmiDeVr9G4jPbdG2HM6cb4i4xKX5ykghgb2OEnzYkFqW9gnynnk6KeKVP1EkkppZG7UZTWR5XuhqChrcSa_VPXyyjNQbZoal5HGdkbtZ3TRVJsNionoJ-Z3LX7WHd51TrFT2JKm1OonU83_qD7JCliHhSxUsMXStVAdGuFhMHBz8L-Os5nnGrcTmn2Ibdc3Cxd8GUtKj00f74acwC5RKLBrPA5siHi41bRTNX7HTgNDjqUMHkahoEJc3Y7Bdu0LKf_Xwp3f0C45DwS6Y-yrGGiI457v1s_cn1Qz24SSxRYXSXXjg_91iJnOrbnco8RzoFAbmjG869-sjVfgBEXjCCXcEfXW1qO0s8H887H7Q7kS9LStGkbC2vU_votwLWTIYNf9fbtJvUAYV0Lgg8SiHXdsavaJe1YzpXFjt8jmd_bU6k4ELfse9lYIbJ-9Try0nq61ylyS0LTWWORFEYjkVvAMRxg2HYmXGz-SE4uNywVFi77MQI1ODVMO8qwtqYw_-kAGsSiCju5VGh-0hnsxUSbntwlo_uZPMlawdR9Aqe18cUz1yb9YcqbSykOHTjq3IW40_f6Ggn2kus4ggPMuxlelfizLwAQPC2VmwT5m2AXllrxdKxFlQWPOss_X_nKhO4ohtL8xyfYy_ScBkXD-JVdW-o5pCvB7gcOS4FTeOsTt1wArc-kjPj1rq8SMGjg9yBMVZT9WYuTRb6N6hEjCPHH2GPL7njupPoybJ-DFveh3d-xR5yW7UZzeF9FEKYm0uprmbSX1zM3z4wKrhamaK9Hnsh17Z4PuYqO7PyVesaU36KtDj6Zbe0ZCDTNR8KvN5AkZ9WzT8JeKVObR5mPkAm_1yCwqWZPfhxe9N45Wu0DwUvSope8CYdEtbNz_l0cKuDojDrYMz2E1n9usNqqFfHmusHLDrqa1_f4Eq2Y4FTSPD0qe2JVLqAvcCz1PuMudyEFb0ih1evDI1z76qqTxwQ4jRwb7aGd3JabeBhZVyK6FFLeh1XOMrkwpwPpfPM3t26tdSvnQN7r7rURIBK0OfirDHJDY-Jeit_9feXUpULb-1-3ebcLnw7h86f4XYLY9Z-gPcXtR-v80_kJGyuTIjHrL6gI2O7uf3pPAtdTW8WHxz8F1iz_ek4dCW3VWjywqxOtqfsKeBL5jNpbOHMrqntEDGcN9FH-Rk1bwqw_knPwJqafpbFBrlqdsOe03bcE3DwGP-ngYr6ciIOPGMpp7Jov-vuyWX4yU4_aOz_Sa_puF66OhJNodxlgR_df3uO0JYldKcMACFN0tQ-Ra7_6aIr3qJ5_9jg2UGfTPbwdnopmh3x6gd_ENbkfn5Qcz-OPO6UynNHmpaYnpu-o6fvu5pkEeqm9vxg7__r2N95UDDZhNCC_L5JoWtLzb3K59EpDFs3XAqZ5KRTFIZnABA5J2X_nlR_9eNlo-AJIhPppR6IV-cwMdgWA-816D4Yhv8PM6R2ig", - "members": [ - "13gepQDvqfnrBiBvqfkvAaVX9ysmQQCgmGwRuiQkgQwU4GQTrGU", - "14p6oTWaGutK1ZiGuBveQEP8rAyWmj9hQxP3hL57YKoKbZgbXAg", - "11fr1XwmFTHNaaDjsnyqfBsAQriJcFosATrFbC3orzgokUSA5bS", - "14ZhnUJV6k4LiAFCySvgG5mcB5G76xNo88sBgRot6ZwXHxPiJui", - "112tvV6v3HkFZWk7KfBTWUofMkZxzEeyAPMsofKJrr7JDU3vx7Zm", - "1126SgELXZEjYdU6Qsq8wBmVXNezgDjADGHngvgAvrDPvHQEdFjk", - "11jNnLcKfitmSDFzG6CAqFy6acsShhkxHgvWSNUdQDsfcTDQfam", - "14D8Rs9r78RHFZ23UDFiEUbY5XtPXr4Fx5btoNSELog4x63E2MQ", - "11kMA31bym77vjMjDQ2VPP9gFUmfqrwA1hXLpRpbW8Xd6kWNRLS", - "14dbWi9KViapfv1vuZuqNZuFf5CBkuyfZyutrUbpxAV5XY7NDtK", - "11PruqvPMCxWqb5Z242AQQRR8Wvq5RP3w8x4ezF7Hrugrm8JvnG", - "11Bryk58FvAMcox7Suia6d1ocNU9odg5QmNHwMxHRRnCLpybjrx", - "133Rx7zW1sR7vdMRu8HcsFNi9oqx5YsQfM8dMpH1CY3MqJ1hR5L", - "11BDjZuKLcygBmUcgZ16xnUo2TFQXcZqTXVRyUMwTBXn6LtPJeG", - "11dJV5WdhYjpLu2Gp4TAiKt8TjUDyDQVs5qJ5SMcF6rQVYi8HCq", - "13jyigDpLxg267iYJD2tUX3bKbTHwiULYtycUAo63GTUfCy4Y5t", - "11dn2zuCmdwMMQL8GsontTKAsKQDRALDFpngA7A9ete7FXcLW1U", - "11J7SQbRGkQ4rpm79D6EL9QcZUiPqk7ttLDx2xCyNULRvLQ5Xwx", - "112BSpw3uWjQMtx7ESX6DnbFgWDNDfPKXYpYSi1kZmB41M6rJtc6", - "11QTEnSijwB4u6a6mqUX54vzQVkTUJdbmipTowwTjPB7SHtcJDS", - "13t8GxUbLnkrGhVhzdFfCZazNJ6VZuNGzoJkLSqm9tJnFonQRaM", - "11bcmudXfjUif7MXm4KJ6zfhQmdCckqr6gXaDAQKVfmJvY2CD1M", - "13RadA7vBrpNgi3Zdt1GPZbYi1HoCqA66UPerQ3i7FfbuMPejay", - "112d2cbaJp6Ma71ujhFsfC9bxffLZT7mNJUJfcZiyjeWoGsLEXMj", - "14j3Mt3tfCJQcre9s9bWqNm8pogWfjoZg8qMfffQMRqGSZkGs9P", - "13JveVL3UTC5QbfMGzVwhVx5Tf39NaN51TLx4drxKcbzrDxKchi", - "11XPUBzYFiK4NAUNV29JQbUJxhuQ8DazM3EgZkkhnNHnhHWhQ7W", - "112gQ5sc7kwqJzuc1obump4QHr9W1xJhXb76VyL37NhT3LQ2J3Ei", - "14sgzEcMGUVX7C31w3ufxWDmtCfoZy6aLyc9iuz3ud6MygcxUE6", - "11APDaL3Kzsu5noNLWDrrWBHQvJn6X878oz5SppLaB5Xd6UZ4NG", - "114d4n9kWfDgF9Hr31KXCGb2aCnWs6xUGjjAHAHvbk4rMrFWCQR", - "11LxYQxJuBnWppfNKZe8JdkdBeAynYghhqZJg9y8hR8ndH5xoXx", - "13PgCBpga1vGMWFB4J81EMLkg9xYjmJpjDeXLaCjpCgEuNLhpXK", - "11jcd7afHSBSX5jg4Z9fSkm1UqzgSHWT3pRa1TH8j7kHY3x7cgb", - "14o43rLV2ySA4cqr1AMbZBm5RkuTcomHC1m9uH2RA8E5G3oZqPL", - "13MVovW8UBq6jYv7TdxLzUQZAFCEpYJmLMewxrJayTLxopxw3Lb", - "11ug7F8doQetQzN86J5ZvwCvSE2uF2qin7oNeEQ88bDTLZZoix4", - "11nUQsd4cJdzvcvRjoSQy5VjbE4Q1Gc5n5JpobkwKTg6BHTqykY", - "14UwPcZYBwiTmftjGjviPeHuC8UCGQqsVKujENR5ghwhqjLC4Q5", - "13eDJPELXR5q1gysewvFD5G5nEyRpcryrTVRDdiXc9zLhw2bTHQ", - "1126C3J8yu7SmTZ2R7bA8xRRZbpruDo2L5B7htVLXE6xJdSn9NcM", - "11JeNjpvDrENMkncmQAqEugjNKN4DyJUDdCmzVotLCuvWYhZwDF", - "112Hy5kTUP4oUVvXqYUQJHUMaWCqXPtpdgL7U9uH6ohpgzYASLpp" - ], - "height": 961862, - "hash": "4KAZu3TeLbJlq4PKgcgOc6944tywkP4w_xX1gq26jaA", - "delay": 0 - }, - { - "type": "consensus_group_v1", - "time": 1628762061, - "proof": "g1AAABMYeJxF12VUVGsUBuAJkZQSEAVhgKEbpLsZOiQUJaUZUlqUlFZSupWURjpGGmlpEEaR7qGby2WtwV_zZ695zvvtffa3jh0AAGC1AsGvf2iAcxxhivUwq-BQbXYp1Q-jb00Iv2cupWCLdpc3LSNUbXr-r5Ks1ns2U4-YPNcsbrdwUd8OboWnd4UdrAjgeA8cvLkzoTQllbpMk7oR5dIU9oeacwfm5TQp-4TEXxh0QCmsGMVAgMZyMy1fLWE9-UQgR98Ws6213UIWDRH-WJwA9rowymB6IXCDXZHA2Hks9ud3vbQ1jn50LxNP0EmK7rc7Yug77IoxrFE3sCnwbhpqJykJ0phqsLYMqA6pHpvZJQAw-e6qAZBxd9DYIdbsZoKD1hjMdQdR4-JnPhBBpehMLPGRV85rjHbDP-cGK8JKAiMSYIiftcoNCn0YkSmYOYH7v-fCeP9cRrYggKrD1EEFX96XyGqsQMS5JHRC86QTJfA0duHbDO99ojkU0RiAYVpOX1ktCNNiVsk6NnJOSPLZCb0-9WcZQx2aXda5TtL_qxS45ECQh4yZSyrUOOetmjnzBVHxgzHYxu9fOnNpseSjtgU0zEVANIBF1treBrKs-2NRL00ySyOtGsky-1o9TapOVkNdVj3pydAmE6EWFX-5NcYVSKYCE3PypH6a_aQEQ9ITtRSiUYQvufF_lTyXLAjiQsxQHhwhqNA_Pi5rz-qvaaaNW8x-GuY0ECncXAooGQFBHiFHpJZYXPx-mbLXa6jtIjRoE8Oey9soXB3avzNPcxtGk1H3NvXKyYTCt7Yk7R52Q2VOTVE-7ZcQumO5-3G27eFe6Jg0gE3qV8lunAVOLpGLuh9mnth5g8RBJKIrzzz9DF27YUpwEIRNpa46LBlj8sUzwXCgm4eZjPOBMKmPgRc3eeNnzBGiQ7RpWzwFT07V5_NiiYeHvON7HDuoz_z0xC2YZ4_---abGujt0WIKImp314UEY5GK6cZO9bq4WwOipJOgwzw7sxCCFIqN66fyj-KJjPALQ1pH8e9_Ceo-btuEHqRb4UW564Se5PVOYaBNY0FMvaAaY5sOSvkod3KAnqzb5p3ToJx-BwdXBjqP6YH_qxS55K__8XjM_ffrJouzCbnkyqbvpu3YTf2qSdPyE8fdLyWAe9kV1yWd543RD0XiVu0LJ9ZiGFfC5Y3HOR2wuYjqnfwRat3xz9DogyfWPanv8WhnSrnoqAveO-eKhIcdrfr2fauLHQ91SZ247afozunHkvh5lR5OHgGZyxEiu5VXrJTKHlBX15wdviHCZRDEuJhS-_kZ7Os6vpdywQM15yli6JNZia-vkzg7N5NIacBoUssNEjdm-spuent76FAqFtIBuZKyT4IuA6d9rmikHtb9G9sZmk6x6BWjFTxwklvuo3XEvHNDAVtJqWUQH3PlbmT1dcwiw3BiVXWWTE_LjYB5I2qmC4nxjHgD1Broau4J5yzsI9pUS8ZU1e4kYzRNooQYbs8Va3mzNPEF3tkJsJn-jumnn35r2rnmSCEvH7J6psnFp8eVj9Lfc7-3Y0_KAA4VD74oiNu6Ns-FGbNDvbFlmyatrSsSKiX6NAOBT9PCNcSeOPSwNdsWok33ZLcSolm46jxjLLgSop63ZFacMYU50o34VLUW4iT_-F8_50-tdu3dc75ge0sn4LeFacY9pgnZGKsxi2Az9Vj425F9XTJV6dD94ETM54Mrq31LLBtc5bEa6pPpGdJVfxUqHWEnhkZPEjwcIypr71oWghR8cJvki-ZSFEs--n6HSu5rkex09N_20yb92djDIsZLVPbKwOYH-oBW-XjVjjEhffjijgabTyArCELJRqhtSESY6zjOojGYB0ZA3CZd4pxS_sbom74OnG9vQpM78M9KLatf_1ITvc4ZTUU6rG3bsOYvf6DrrGMwYqNOS_z3fk5KWf2MLAYja_KP7Di2LdiZ5fTgsyue3mEsDSvZHwp5QRDZC1oqtcxJXmxr3LQ1nQwqCnEsx6isHH9xVw9ewWOyEPSe9fb60NgCFRml-CO8Tarz6BfP_UEPc_EwE2x-mtUUOq2fN3tWeMkjMN778uVus84FR4qWNGZcu7N3J9Ygfik5K12-v0KiOeaPQKbPoOMxawb5jSabkTiExAQ3ucEgdkxuIK8K-gYBBHuvqnQPGVZb7okfndBQ9U17kKvVQ7pMwuatFH4Ks5bcDg_-IhOnQET7qgbGqrx2PqxIlN9e2hh51j0w6B2NT5QgfH0EV27DG6qexgsXflHOcwsIKAR2ZdxdxuXX_NNjRFGpHYY2P3qLeicvr3Om5Sk7Qblr9QxJv0aYHRzazc8_l-lBhmDc9lG1taLr8Mdwt9PaEJG9VtS8RNCQ1xSUeFsJlniq0qrkCoJQCfqIhKqS7qxFhW5x9GlNFY9GTvCWD-x0092XnOVnh6JJ2asoKmvB0dR7Mv3Pcd-2onx7jB03jpoF7J-SGXrgwl7cks4uRxufqWIC_m5GVVg64HnJLlmHblOOZsWT9rekC20hQRCBqrIzytc9B6jZ5Dk4j7jiaPp4JEeUc0eRrvXYEXv8JrqNP96LtW2lIAeDOr3O1NbXk1ulqjC6B4R0X_tDEM1-hlE3bVycT-ZnabSHXSiL65p391u8SQCRrmY6UgWCDyfgRksWI809tKdJHSIqwZdAir2LpxHpSdAXjrK6wJaENZt7VLd7h13l60yI7GrGflW4wejjFhv8yXqt7_vqFMdiFzpKx609_-a0KwuYC_bmCWV-Aaz4cFyPypQNtG5Qt07HaYzuKv39MQEEYV6u0bqr0Mi1KHhcTT7HTc48ENk9nAj8rTpH3yah0OSONv_UKa60sFa8fU1Zq5JxloFwB55l8Q59ui88lHJQbe6m_G8HLDhfwZLHF-pRSP-XYsuOWB7ckio1GL5Mc-tNrUuqtE3XJadeQQUctslrg18XaUiXwgSl7i0SredXTh4R9OLi4UQWo1En9fs-aZZiRk7vfNWdYJ5aWpGptflf1wXeVwtlsq2v6t020vz0kXmQtfvhTApSsme6D_Qpmv0gfm99iQAMHWB2pigCQcAvQW8vsOA_Kv4UgX2D0tixxpc7leTOWzExw2vHZ_T80eSYL7yp2YV40wxQhKWkZHsulckL51VJZ6bOY8ep6hPav31FbMeqySQX6lgJYAS2-RRgXJJD-wUVCG1BU9S8P5_qo_7rmCf48HvvVtdXpVGn8Tw-HtFyJwNimMGoucGlI9dpLKJMtHlE6CriuZA4m9QQSSHuoHRK3iIANcVrXws1xHE1sNN2vI2JK6Lj0Q9USi5O7puxI2zG3qWX_GM2EpsikwqSISiXSgRBCCr-IB2OCr7YlqVI_cZpgOC0KBOQSiYyW61oUkmDN03QJHlBcZs-wBvqSozkJuF6w7vTnEOBWiNwhPFftHSVlsbekqSYpiVxZvQtZMfPvyBBE5cBq1pn5c5Qrv3MB-WzHLBKEATION7I6u4oLlz4EyCekNs2MTvqcU8Ze9LE-yTg9FVQNpokVWMDLzM3rs1t2WzkUvpT4bdSf94J8KlRX3AvOJeTsPw3tbm-gG8rgWysPuwJMoUO4xfaJ5GMLT7mp7ytnuzj1Tn7IIjjjBJFWkLzSyNvPlrHcyi_p-p3oQinvPBk-HZGuBHpbcxCwbqSqqilnAN-GUOrpCI15yqz6WYijk3_NgubvbsmeLfd1C1XkNbVLXwL8hiGs28HlKrhmuCpA_RTP1RqymeW8QGun6oF4UvV1WeF8K5xdLTi3epgrClksHFbuWDDS3ozRx53jjZnGZ1sbI7zAmLuVrC0B9psqVinlidavIJkijhSDb8Ybrg9WlqSHGDtgmuY33ePjawneXFpOB_uN_Ri0f3kBNrT3rnDfX1x-ehiNX9d1eIScjDzZnqucKQCMIxr6suCKrcuG-UBO9CkKRysNsduq1_fVxciqVQenEPK_QK_OYzgfZ8bmfC8atItacBSFv72m1BEx7uBRunyozN7N64t4_a8H2atMTR3G-WegSA-i4QqBcf2hFyXRNZKXFRvTH_nRvBwokxtH-Vdfn2AeoteeHv5IM64uIHHXmxY9r40AGsExMf8cDQuu13PdiR7pjnmZuH1NFk1XI1KHLSK_yJeIHfqeqHM9WOxbO9jyrCo8MESlTLG02R3Wk7X5XMI38ceYoH61lbLBazJrIW3zcJhUOJKPDS2Fn5OEFJoE9bRPhHUexKW6Un5-MuU-m5qcq5BTEaDO_sN1kYYEqeRKRkYjDBUtumpWpAQ8ziZEZ77YZDxiVEbhtONhGQO-tDZBCVXm-5FppLlv8zys9DRv3f8LbGGsDMfFxONCf_R7drddG481KxTDQmRxJ35qeHQgxkQ-8pzVmnt-PnMDVbjxbveUzpkoC_HYjbTkRoUFLZX2FpM8mgb8GO4RuMBDV2vRblpvsxsRF2FqAZFcYQkmYgJH0Eqe5_6fMxqlwIOGhNfTqkxcoKu21ph_7HOD7OrGnbaQ7AKui93NVs1TeeE3GCe7tDqdoeky9fU3KoagKisp25MWXGNoeZg9s6mQwchWKd8WgwxGKPp47tsjP1f0mppbTwE5JXjSmqtL2X0aqyx0GNymvXKLF6UD3sE_-AzsByIsmLyGJOQlm8oEPNrkRDFEv_3BhZv6072f-ek6bZ8hKAAug2uG_195Y6Vz867atUo3i78BgShSXpTBIjGXzr9LozqPblroMWn840PtTm9xlOlKPkQawYdcExf4VlXSg_-iJ4G-UpVb4Jqu6NwI2f3YJBdcllsHKHiTcCNpXIrmiO-exORi9JM2kMbcAuYGZu7pWbffEgWQuDYpLvM0bD81B5ZRv5sWuOwo6JivNlLiqEMmZvF5WIfunf7hWzwFwiGeFfT_6zf5-7F-BsxIcWYwVqbvur4oE1AzoT96Q3m6JNmdiBCbqTyCKf6oKMSUvi5hGqkWMZTELBdzZxCWsOByMN6YRnOiE_rrUiZeR_rLIU7mKBBR5mlLnHmLC0FfQsDuR70dq4qCpEsPjTDZAxwSoZX9DYEvMp6zDFc13XiWXZwg9Hu8n4Tx1flX1v2PxTIkFZJ9MXt0KZznnTCGxfO5F7kN8wKkIznl2AoRH2La-ZvfyNlXmmYKqgMI2nAGzgOFbgdSrxVsJXHwzsBqJxsLR8zEeFfIiXlg22BzaalVZWjDy84brDmllVKo4a7DESrbLXBY7VzXJWtjpg_7JFUOYt0dA76Y7WnqTOxU4E8L989PS1jYqTb0Aw9N8n8u_cpvfds2pIdiJ4TjiA9fAEBteNPRPlsos0PqKK1hzeF6HvW-u8slbpMI9v-zUmQuschCU3etH1URprT8dLYOOgtdb6T2Kz_OSmG6MDxOAjiSjuKxzUJl0C5qpkuvkDhMuhYRpo9eMibdQ8YFG9p_god0Oo0OjHpT4VgOPmLy8-WV1snwJeyo57h1tO0kq0uMb4eNwGX8fm91ixsTxF-fhEYNCQRcE0Fg9NZ9RIJvfsZv6TmnUcA2SescvLGXe-U7IkRCg3BzljfH5RZhWhhPkoaUMYAoANaSirxN4rsoqbGk-kuQ3-Gfl06Tpkf5fwy8WP60W8e3KF_AQNkpWCeh72HFMY6PPsDpbG5CqeiPHuOlpR4NgOKM0WK1x__5AtlcVDMhC-QGtEuqMXG8YbHnYGO9yTGCmGxcMW3UmgTS0hxO58cNUA4-0XhE74na-XY5hfuFJ0gkj6-q6aokl-3O5q14NlV3WH5vPv9jDbwQfFjT_Kwrtp0LVxBfI8QF5dhJRDEfgsJGwM_npnunVZ_9xQlB35noRTya0WQAMd3Z5N2yhhNpliP9Ouv2U3pYgZ3_eYVSL2v43S3qkPWjuZKWWRfAwy_vf3op1glqMhpGHXyucWHyrCcSpmHzlJU48RgLJRyWGPOxNcHkZbiyrQBzOjINtL8coxMdYnm_B1a6bcy6l5oEzutQJxu8x9-WmhK", - "members": [ - "1122fkwoys8ZsyuR9Wd1FRiJ9pzCWeGJdtaEzRp2i6swFjqMLHhU", - "11Bryk58FvAMcox7Suia6d1ocNU9odg5QmNHwMxHRRnCLpybjrx", - "11Lx7ghqUFFrqp1okFnfWPGv1buifwbRry319WUFHutZ8kc2ehB", - "112iQp2G7EZYJb3g5n8zVun5fgjRncFmNtECEUBdhHwJJAiodpae", - "13eDJPELXR5q1gysewvFD5G5nEyRpcryrTVRDdiXc9zLhw2bTHQ", - "112d2cbaJp6Ma71ujhFsfC9bxffLZT7mNJUJfcZiyjeWoGsLEXMj", - "11dKNGVMKCyYjwfCWqFSHooijZ5mbfSFUdrEcw17edAXYCUs1sp", - "114d4n9kWfDgF9Hr31KXCGb2aCnWs6xUGjjAHAHvbk4rMrFWCQR", - "11APDaL3Kzsu5noNLWDrrWBHQvJn6X878oz5SppLaB5Xd6UZ4NG", - "11jNnLcKfitmSDFzG6CAqFy6acsShhkxHgvWSNUdQDsfcTDQfam", - "14j3Mt3tfCJQcre9s9bWqNm8pogWfjoZg8qMfffQMRqGSZkGs9P", - "13t8GxUbLnkrGhVhzdFfCZazNJ6VZuNGzoJkLSqm9tJnFonQRaM", - "13JveVL3UTC5QbfMGzVwhVx5Tf39NaN51TLx4drxKcbzrDxKchi", - "112BSpw3uWjQMtx7ESX6DnbFgWDNDfPKXYpYSi1kZmB41M6rJtc6", - "133Rx7zW1sR7vdMRu8HcsFNi9oqx5YsQfM8dMpH1CY3MqJ1hR5L", - "112uP245zEH3PZAE36hd9te3zfcMNe3owvfgQbYZvXEn5n4mb9m5", - "11MVK9fgQEaSAXWVC6VG51MgvH9He1BKoDhLJN5GrdvQBVZkzzG", - "11JeNjpvDrENMkncmQAqEugjNKN4DyJUDdCmzVotLCuvWYhZwDF", - "13jyigDpLxg267iYJD2tUX3bKbTHwiULYtycUAo63GTUfCy4Y5t", - "14o43rLV2ySA4cqr1AMbZBm5RkuTcomHC1m9uH2RA8E5G3oZqPL", - "11BDjZuKLcygBmUcgZ16xnUo2TFQXcZqTXVRyUMwTBXn6LtPJeG", - "14D8Rs9r78RHFZ23UDFiEUbY5XtPXr4Fx5btoNSELog4x63E2MQ", - "11XPUBzYFiK4NAUNV29JQbUJxhuQ8DazM3EgZkkhnNHnhHWhQ7W", - "14UwPcZYBwiTmftjGjviPeHuC8UCGQqsVKujENR5ghwhqjLC4Q5", - "112tvV6v3HkFZWk7KfBTWUofMkZxzEeyAPMsofKJrr7JDU3vx7Zm", - "112ptREvWm7ZkbXZkJqEmn6pcmkidXKbTJFT2zzcMfV58JXevhb7", - "13PgCBpga1vGMWFB4J81EMLkg9xYjmJpjDeXLaCjpCgEuNLhpXK", - "11ug7F8doQetQzN86J5ZvwCvSE2uF2qin7oNeEQ88bDTLZZoix4", - "14p6oTWaGutK1ZiGuBveQEP8rAyWmj9hQxP3hL57YKoKbZgbXAg", - "11nUQsd4cJdzvcvRjoSQy5VjbE4Q1Gc5n5JpobkwKTg6BHTqykY", - "1126C3J8yu7SmTZ2R7bA8xRRZbpruDo2L5B7htVLXE6xJdSn9NcM", - "112Hy5kTUP4oUVvXqYUQJHUMaWCqXPtpdgL7U9uH6ohpgzYASLpp", - "11ruKmR5j1Mj4mLtjb3o9xMLEPXetGhELAYbvs9XAZLfQyxWYq6", - "11J7SQbRGkQ4rpm79D6EL9QcZUiPqk7ttLDx2xCyNULRvLQ5Xwx", - "14dbWi9KViapfv1vuZuqNZuFf5CBkuyfZyutrUbpxAV5XY7NDtK", - "112gQ5sc7kwqJzuc1obump4QHr9W1xJhXb76VyL37NhT3LQ2J3Ei", - "11pRX3m5Ax88Vth6Ld5DefZi4PL3t1CLegzF9bTAyBuKK9AEuyK", - "11bcmudXfjUif7MXm4KJ6zfhQmdCckqr6gXaDAQKVfmJvY2CD1M", - "14ZhnUJV6k4LiAFCySvgG5mcB5G76xNo88sBgRot6ZwXHxPiJui", - "13RSzbdJTi9bnvinwhTQpzFNLqoa97D1fh7mQyug15XnvMZcqCY", - "11kMA31bym77vjMjDQ2VPP9gFUmfqrwA1hXLpRpbW8Xd6kWNRLS", - "1126SgELXZEjYdU6Qsq8wBmVXNezgDjADGHngvgAvrDPvHQEdFjk", - "112sovgvtdybLuqiGDj86A2S9oGtBN6GEU78fEvkoUjQriYDiVSh" - ], - "height": 961829, - "hash": "iSIYPxHu8B7xVYfDepDVuP3rWiHvr5Fxm6GztIL3w9k", - "delay": 0 - } - ], - "cursor": "eyJ0eXBlcyI6ImNvbnNlbnN1c19ncm91cF92MSIsInJlbWFpbmluZyI6MywibWluX2Jsb2NrIjoxLCJtYXhfYmxvY2siOjk2MTg5MywiYmxvY2siOjk2MTgwMCwiYW5jaG9yX2Jsb2NrIjo5NjE4MDB9" -} -``` - - - - ---- diff --git a/docs/api/blockchain/hotspots.mdx b/docs/api/blockchain/hotspots.mdx deleted file mode 100644 index 1b1e09a16..000000000 --- a/docs/api/blockchain/hotspots.mdx +++ /dev/null @@ -1,2387 +0,0 @@ ---- -id: hotspots -title: Hotspots -pagination_label: Hotspots -sidebar_label: Hotspots -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/hotspots ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Oracles API - -### Rewards for a Hotspot - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/rewards -``` - -Returns rewards for a given hotspot per reward block the hotspot is in, for a given timeframe. -Timestamps are given in ISO 8601 format. The block that contains the `max_time` timestamp is -**excluded** from the result. - -The result will be a list of rewards between `min_time` and `max_time` both given in UTC. Both -default to "now" which means that at least one of the two parameters is required. - -The result includes a `type` field which is the type of activity that generated the reward. - -This route is paged using a `cursor`. - -:::info - -For older reward results, if the `type` is `null` the amount is a total for that hotspot in the -given block. - -::: - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | -------------------------- | -| address (required) | _string_ | B58 address of the hotspot | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | -------------------------------------- | -| cursor (optional) | _string_ | Cursor for page of rewards to fetch | -| max_time (optional) | _string_ | Last timestamp to include rewards for | -| min_time (required) | _string_ | First timestamp to include rewards for | - - - - -200: OK - -Rewards for a hotspot with time range: `max_time=2020-08-29&min_time=2020-08-27` - -```json -{ - "data": [ - { - "account": "12xUoMKwf12ABjNx4VCvYcNkX79gW1kzz2JnBLxkFbjswRczRvM", - "amount": 7885016, - "block": 470788, - "gateway": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "hash": "DTU1GGfR0eU15hv6KiV_bg6FOJXfUWz4TjIq1H7TGy4", - "timestamp": "2020-08-28T01:29:46.000000Z" - }, - { - "account": "12xUoMKwf12ABjNx4VCvYcNkX79gW1kzz2JnBLxkFbjswRczRvM", - "amount": 3612069, - "block": 470753, - "gateway": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "hash": "l3EQR6AJ6R1qE1meHyafDnNF8vJ-X-rH1pujxQRTds4", - "timestamp": "2020-08-28T00:50:44.000000Z" - }, - { - "account": "12xUoMKwf12ABjNx4VCvYcNkX79gW1kzz2JnBLxkFbjswRczRvM", - "amount": 8623955, - "block": 470509, - "gateway": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "hash": "5fQJY9MprH9b3IstVU1SdfBteUWoF_sdsVuiARPBtTY", - "timestamp": "2020-08-27T19:01:48.000000Z" - }, - { - "account": "12xUoMKwf12ABjNx4VCvYcNkX79gW1kzz2JnBLxkFbjswRczRvM", - "amount": 4009855, - "block": 470475, - "gateway": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "hash": "0M0fudEmzW9dmAsO3dcWT286tTL6wTX9sllXtsyz-0Q", - "timestamp": "2020-08-27T18:15:17.000000Z" - } - ] -} -``` - - - - ---- - -### Reward Total for a Hotspot - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/rewards/sum -``` - -Returns the total rewards earned for a given hotspot over a given time range. Timestamps are given -in ISO 8601 format. The block that includes the `max_time` timestamp is **excluded** from the -result. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | -------------------------- | -| address (required) | _string_ | B58 address of the hotspot | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | ------------------------------------------- | -| max_time (optional) | _string_ | Last timestamp to include rewards for | -| min_time (required) | _string_ | First timestamp to include rewards for | -| bucket (optional) | _string_ | Get data in buckets ( hour / month / week ) | - - - - -200: OK - -```json -{ - "data": { - "max_time": "2020-08-29T00:00:00Z", - "min_time": "2020-08-27T00:00:00Z", - "sum": "164942208" - } -} -``` - - - - ---- - -### Witnesses for a Hotspot - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/witnesses -``` - -Retrieves the list of witnesses for a given hotspot over about the last 5 days of blocks. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ------------------------------------ | -| address (required) | _string_ | B58 address for a hotspot to look up | - - - - -200: OK - -```json -{ - "data": [ - { - "lng": -84.38947964027781, - "lat": 33.77442909128778, - "timestamp_added": "2021-06-24T22:12:07.000000Z", - "status": { - "online": "online", - "listen_addrs": [ - "/p2p/11PhkxBRa6SXjKTj32RdDhbU9jwPNvmL1rgPScfT8VwHJWTkmG6/p2p-circuit/p2p/112vrDrzMZjE8NkxgUuLWSrfXuQFA3fDhaNEca7FPmyEV4SwPJEk" - ], - "height": 900645 - }, - "reward_scale": 1.0, - "owner": "14ZDTJZE41rQJPxrSHgp3UKuyZnB1KZuE3pZgMAhJraKfEF6X7D", - "nonce": 2, - "name": "merry-blood-otter", - "mode": "full", - "location_hex": "8844c1a8ebfffff", - "location": "8c44c1a8eadebff", - "last_poc_challenge": 900303, - "last_change_block": 900738, - "geocode": { - "short_street": "Spring St NW", - "short_state": "GA", - "short_country": "US", - "short_city": "Atlanta", - "long_street": "Spring Street Northwest", - "long_state": "Georgia", - "long_country": "United States", - "long_city": "Atlanta", - "city_id": "YXRsYW50YWdlb3JnaWF1bml0ZWQgc3RhdGVz" - }, - "gain": 23, - "elevation": 50, - "block_added": 895576, - "block": 900768, - "address": "112vrDrzMZjE8NkxgUuLWSrfXuQFA3fDhaNEca7FPmyEV4SwPJEk" - }, - { - "lng": -84.41078918647065, - "lat": 33.78627614557136, - "timestamp_added": "2021-06-22T15:33:09.000000Z", - "status": { - "online": "online", - "listen_addrs": [ - "/p2p/113hRKavKYh8oRg1qTPWyB9a24tVrSRLP67jUbRutm2AcHC4bAj/p2p-circuit/p2p/11BXSMm2PnVEnRUvKhjfoF3bQS1r45x8SynmXkBpR2uW18LDfeG" - ], - "height": 900645 - }, - "reward_scale": 1.0, - "owner": "13CsDkkHCroh7EFKjEkT74JmC7qkr4PuJn4jybqShBzYYrR4p7B", - "nonce": 1, - "name": "fun-hazel-gorilla", - "mode": "full", - "location_hex": "8844c1a88bfffff", - "location": "8c44c1a88a2c9ff", - "last_poc_challenge": 900738, - "last_change_block": 900763, - "geocode": { - "short_street": "14th St NW", - "short_state": "GA", - "short_country": "US", - "short_city": "Atlanta", - "long_street": "14th Street Northwest", - "long_state": "Georgia", - "long_country": "United States", - "long_city": "Atlanta", - "city_id": "YXRsYW50YWdlb3JnaWF1bml0ZWQgc3RhdGVz" - }, - "gain": 12, - "elevation": 0, - "block_added": 892710, - "block": 900768, - "address": "11BXSMm2PnVEnRUvKhjfoF3bQS1r45x8SynmXkBpR2uW18LDfeG" - } - ] -} -``` - - - - -### Witnessed for a Hotspot - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/witnessed -``` - -Retrieves the list of hotspots the given hotspot witnessed over the last 5 days. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ------------------------------------ | -| address (required) | _string_ | B58 address for a hotspot to look up | - - - - -Shows the hotspots that hotspot `11sYnfeGAbFzDhXJ9NujYY2v2CnrcXPrewiF4iRN8upMs3HYUN2` witnessed - -200: OK - -```json -{ - "data": [ - { - "address": "112ZUpjfpGjCgoHjF5d2AUVznDYSFBzZcupdcZ5AivXkS2CNkKAG", - "block": 943086, - "block_added": 909051, - "elevation": 35, - "gain": 58, - "geocode": { - "city_id": "amFiYWwgbHVibmFubGViYW5vbg", - "long_city": null, - "long_country": "Lebanon", - "long_state": "Jabal Lubnan", - "long_street": "قماطية", - "short_city": null, - "short_country": "LB", - "short_state": "Jabal Lubnan", - "short_street": "قماطية" - }, - "last_change_block": 943072, - "last_poc_challenge": 942763, - "lat": 33.79955623248546, - "lng": 35.58377688261546, - "location": "8c2da24de12c7ff", - "location_hex": "882da24de1fffff", - "mode": "full", - "name": "handsome-satin-bat", - "nonce": 1, - "owner": "13VKSpg4fW4EbroEAEe5H7JsWM5sUBAvcQHiJWgPx2ztci5HHFg", - "payer": "13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDirdY", - "reward_scale": 1.0, - "status": { - "height": 942913, - "listen_addrs": ["/ip4/185.187.130.9/tcp/44158"], - "online": "online", - "timestamp": "2021-07-29T08:27:35.292000Z" - }, - "timestamp_added": "2021-07-06T12:25:11.000000Z" - }, - { - "address": "112KiUgwQjH3HWC8DRD1AwzBd6JYVQhcyTm2cuH9S52VAEufUTxx", - "block": 943086, - "block_added": 586187, - "elevation": 40, - "gain": 58, - "geocode": { - "city_id": "amFiYWwgbHVibmFubGViYW5vbg", - "long_city": null, - "long_country": "Lebanon", - "long_state": "Jabal Lubnan", - "long_street": "قماطية", - "short_city": null, - "short_country": "LB", - "short_state": "Jabal Lubnan", - "short_street": "قماطية" - }, - "last_change_block": 943077, - "last_poc_challenge": 943053, - "lat": 33.80608713927618, - "lng": 35.573540070314635, - "location": "8c2da24d12c19ff", - "location_hex": "882da24d13fffff", - "mode": "full", - "name": "furry-mossy-spider", - "nonce": 5, - "owner": "14CTinSvsJJDfYmbVfNUscB8ZW1GWSDmCodK3SE2kCW9oAVpERU", - "payer": "14fzfjFcHpDR1rTH8BNPvSi5dKBbgxaDnmsVPbCjuq9ENjpZbxh", - "reward_scale": 0.8333282470703125, - "status": { - "height": 942453, - "listen_addrs": ["/ip4/185.187.130.21/tcp/44158"], - "online": "online", - "timestamp": "2021-07-29T01:09:21.481000Z" - }, - "timestamp_added": "2020-11-12T17:15:45.000000Z" - } - ] -} -``` - - - - -### Hotspot Roles - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/roles -``` - -Lists all blockchain transactions that the given Hotspot was involved in. This route is paged using -a `cursor`. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | -------------------------- | -| address (optional) | _string_ | B58 address of the hotspot | - -_Query Parameters_ - -| param | Type | Note | -| ----------------------- | -------- | ----------------------------------------- | -| cursor (optional) | _string_ | Cursor for page of results to fetch | -| filter_types (optional) | _string_ | Comma separated list of transaction types | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -This lists the activity for a Hotspot which only had two transactions at the time of the request. - -```json -{ - "data": [ - { - "type": "assert_location_v2", - "time": 1644023217, - "role": "gateway", - "height": 1212339, - "hash": "DXciS1wFRf4CAfK_FPl-nE3l_YhisFibOmY2vXE0e3s" - }, - { - "type": "add_gateway_v1", - "time": 1644023156, - "role": "gateway", - "height": 1212338, - "hash": "VSO7aKH9uiCuWUNzb5rPddlq-m-kvaMeVeufUQisjbo" - } - ] -} -``` - - - - ---- - -### Hotspots Roles Counts - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/roles/count -``` - -Count transactions that indicate a Hotspot as a participant. - -The results are a map keyed by the given `filter_types` and the count of transaction of that type. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | --------------------------------------- | -| address (required) | _string_ | Hotspot B58 address to fetch counts for | - -_Query Parameters_ - -| param | Type | Note | -| ------------ | -------- | ----------------------------------------- | -| filter_types | _string_ | Comma separated list of transaction types | - - - - -200: OK - -Fetch counts with `filter_types=assert_location_v1` for hotspot -`/11yTLDH2QbVLyRnBykzdLLP2j2DoAzjSp3obNrnxhUXpVdaYCZF` - -```json -{ - "data": { - "assert_location_v1": 2 - } -} -``` - - - - ---- - -### Hotspot Challenges - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/challenges -``` - -Lists the challenge (receipts) that the given hotspot was a challenger, challengee or witness in. -This route is paged using a `cursor`. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ------------------------------------- | -| address (optional) | _string_ | B58 address of the hotspot to look up | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for the page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -Fetches the challenges that the hotspot with `11DvZivbwHVRx4PbQwAd5w2DQEAcfSCRVzsW7gjRKQ86nCEJxHJ` -was involved in. - -```json -{ - "data": [ - { - "type": "poc_receipts_v1", - "time": 1593711283, - "secret": "AGzlnZfDnyFn1F_aLLlgYErFiEIAtFH0qTVV68pAibwNBOaVB2Wvnn2ZeF_unWN55Ld_7VXemk64lPHnjsOG_1YLXDnP7RT4EGELD9xriv1AZbNCoMAfY-xPhRHlf3YVPms", - "path": [ - { - "witnesses": [ - { - "timestamp": 1593710795471113454, - "signal": -78, - "packet_hash": "5AN5Y3hcAVqZk_9KFetSbh-Z_qPGSeN-MFcH7neSyNM", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c37aa5ff", - "gateway": "112QWbkXGkZ5dSkP2511A6aYGLyabeLRRnd7un22WhQNShfSbXNc" - }, - { - "timestamp": 1593710795456164133, - "signal": -77, - "packet_hash": "5AN5Y3hcAVqZk_9KFetSbh-Z_qPGSeN-MFcH7neSyNM", - "owner": "14cSUPEX76FLdhjgyT6Y6fBFYzeJdTjTMDDrHDnpeA8tSXmYrfq", - "location": "8c2ab60c46e4bff", - "gateway": "1112cKvndYQE1X3BxpRtuycvh36ehEuA4yqpiSzJqMGzrcQGUER" - }, - { - "timestamp": 1593710795454238307, - "signal": -94, - "packet_hash": "5AN5Y3hcAVqZk_9KFetSbh-Z_qPGSeN-MFcH7neSyNM", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c170b9ff", - "gateway": "112LxPghCf7qXigCBRz74LTAKKvPtfYPjqPxbBpkie9E9BcrMDdc" - }, - { - "timestamp": 1593710795459449071, - "signal": -71, - "packet_hash": "5AN5Y3hcAVqZk_9KFetSbh-Z_qPGSeN-MFcH7neSyNM", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c4b46dff", - "gateway": "11iYaU281c2Yjo2tvMxyeu1t95Cv7aLWuAoBYte51gZ7bKijzpj" - }, - { - "timestamp": 1593710795447538617, - "signal": -78, - "packet_hash": "5AN5Y3hcAVqZk_9KFetSbh-Z_qPGSeN-MFcH7neSyNM", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c426e7ff", - "gateway": "1128s66jgeG9oxw33FV7Gw52wfNukPSKGupB2C7N3w1poid5LeRC" - } - ], - "receipt": { - "timestamp": 1593710793585261540, - "signal": 0, - "origin": "p2p", - "gateway": "11a44i7ry5WQ2ZuPTL5Hpx7RkQBHevNwiQkpU6sZgGxkYQ9K59o", - "data": "o9w" - }, - "geocode": { - "short_street": "Washington Ave", - "short_state": "MI", - "short_country": "US", - "short_city": "Port Huron", - "long_street": "Washington Avenue", - "long_state": "Michigan", - "long_country": "United States", - "long_city": "Port Huron" - }, - "challengee_owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "challengee_lon": -82.43305482993941, - "challengee_location": "8c2ab60e3c14bff", - "challengee_lat": 42.98855335905615, - "challengee": "11a44i7ry5WQ2ZuPTL5Hpx7RkQBHevNwiQkpU6sZgGxkYQ9K59o" - }, - { - "witnesses": [ - { - "timestamp": 1593710797368850439, - "signal": -95, - "packet_hash": "viJWqE5v96u8eKCRwTqm-bf2IlD2m87N3A0SKs7Yf4c", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c37aa5ff", - "gateway": "112QWbkXGkZ5dSkP2511A6aYGLyabeLRRnd7un22WhQNShfSbXNc" - }, - { - "timestamp": 1593710797331238274, - "signal": -102, - "packet_hash": "viJWqE5v96u8eKCRwTqm-bf2IlD2m87N3A0SKs7Yf4c", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c170b9ff", - "gateway": "112LxPghCf7qXigCBRz74LTAKKvPtfYPjqPxbBpkie9E9BcrMDdc" - }, - { - "timestamp": 1593710797335494047, - "signal": -93, - "packet_hash": "viJWqE5v96u8eKCRwTqm-bf2IlD2m87N3A0SKs7Yf4c", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c4b46dff", - "gateway": "11iYaU281c2Yjo2tvMxyeu1t95Cv7aLWuAoBYte51gZ7bKijzpj" - }, - { - "timestamp": 1593710797325570974, - "signal": -99, - "packet_hash": "viJWqE5v96u8eKCRwTqm-bf2IlD2m87N3A0SKs7Yf4c", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c426e7ff", - "gateway": "1128s66jgeG9oxw33FV7Gw52wfNukPSKGupB2C7N3w1poid5LeRC" - }, - { - "timestamp": 1593710797326235913, - "signal": -81, - "packet_hash": "viJWqE5v96u8eKCRwTqm-bf2IlD2m87N3A0SKs7Yf4c", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60e3c14bff", - "gateway": "11a44i7ry5WQ2ZuPTL5Hpx7RkQBHevNwiQkpU6sZgGxkYQ9K59o" - } - ], - "receipt": null, - "challengee_owner": "14cSUPEX76FLdhjgyT6Y6fBFYzeJdTjTMDDrHDnpeA8tSXmYrfq", - "challengee_lon": -82.4633534637547, - "challengee_location": "8c2ab60c024adff", - "challengee_lat": 42.94538752297601, - "challengee": "1123VfBqFkbBfLtMZiYMR2WoUew2tZWWdZcoVHGRG2KSq7pYtCpJ" - }, - { - "witnesses": [], - "receipt": null, - "challengee_owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "challengee_lon": -82.46035597096102, - "challengee_location": "8c2ab60c14219ff", - "challengee_lat": 42.941715433247545, - "challengee": "11DvZivbwHVRx4PbQwAd5w2DQEAcfSCRVzsW7gjRKQ86nCEJxHJ" - }, - { - "witnesses": [], - "receipt": null, - "challengee_owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "challengee_lon": -82.49094619308394, - "challengee_location": "8c2ab60c37aa5ff", - "challengee_lat": 42.93231949041608, - "challengee": "112QWbkXGkZ5dSkP2511A6aYGLyabeLRRnd7un22WhQNShfSbXNc" - } - ], - "onion_key_hash": "YM1oa4GmFBucT2g5NXHSN4CH907uuEo7waMnDIVG85k", - "height": 397058, - "hash": "tmWvGykf9sIjix1VxkYQwRjz1jzwuluGvVxDnMwWAZ4", - "fee": 0, - "challenger_owner": "14ZxnCvJq9wNgdFjLGatcYCjxdnT3RfzJ6dkVHNB9Wkwq5FHLj4", - "challenger_lon": -118.49635947992698, - "challenger_location": "8c29a19ab59c1ff", - "challenger_lat": 34.02420568554961, - "challenger": "118AgJni9yvsbX1nJF8ZRhXXtdPqEsSoshaZV9G9fyYz1Miwk2b" - }, - { - "type": "poc_receipts_v1", - "time": 1593709051, - "secret": "AA-QE2YLG0iIIc1KO4FA7zJSiGDYVTgxoi7bKtn7TcfABNru4ZZmh5Wo_j88yUGDXW7m_jmYc1nq8Rn8b3rmxkCBUVw31SW88BtNyWYdI4RqwHXWmtA-fqrq-Ksr0KvgA_I", - "path": [ - { - "witnesses": [ - { - "timestamp": 1593708823109097719, - "signal": -103, - "packet_hash": "bAxUoDw2Ypgv1qY6ZzFZBYun99Fa_ch4VPqKhdBZJD8", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60e38113ff", - "gateway": "112bM2Comn8VD9KXMYdKZYeSUKwRuJDWUJc2YbfKbDgHwArnt46a" - }, - { - "timestamp": 1593708823089884139, - "signal": -91, - "packet_hash": "bAxUoDw2Ypgv1qY6ZzFZBYun99Fa_ch4VPqKhdBZJD8", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c389c5ff", - "gateway": "112rzgdhF48KqLKUUuJe6FKQX6yVaCte639JuuixtybHkezL2iAB" - }, - { - "timestamp": 1593708823101331551, - "signal": -99, - "packet_hash": "bAxUoDw2Ypgv1qY6ZzFZBYun99Fa_ch4VPqKhdBZJD8", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c170b9ff", - "gateway": "112LxPghCf7qXigCBRz74LTAKKvPtfYPjqPxbBpkie9E9BcrMDdc" - }, - { - "timestamp": 1593708823100783822, - "signal": -91, - "packet_hash": "bAxUoDw2Ypgv1qY6ZzFZBYun99Fa_ch4VPqKhdBZJD8", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60c58341ff", - "gateway": "112BgzGtWwcCsL98Xpcz6p5bJeaS1KrcevDeYnrZSKDzqgBngW1a" - }, - { - "timestamp": 1593708823104408242, - "signal": -99, - "packet_hash": "bAxUoDw2Ypgv1qY6ZzFZBYun99Fa_ch4VPqKhdBZJD8", - "owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "location": "8c2ab60e318e7ff", - "gateway": "119td1MLCtGEAjnGJjMXTh6dcyq3FwW2gxoU9Ev5jrmE1f6aZQh" - } - ], - "receipt": { - "timestamp": 1593708821274903421, - "signal": 0, - "origin": "p2p", - "gateway": "112mBp6av2P1Ko7aXQZSSBiZLPxi9dP2YL1E1M8ysBx9MbKPR4FJ", - "data": "zw0" - }, - "geocode": { - "short_street": "Military St", - "short_state": "MI", - "short_country": "US", - "short_city": "Port Huron", - "long_street": "Military Street", - "long_state": "Michigan", - "long_country": "United States", - "long_city": "Port Huron" - }, - "challengee_owner": "14cSUPEX76FLdhjgyT6Y6fBFYzeJdTjTMDDrHDnpeA8tSXmYrfq", - "challengee_lon": -82.42495037863101, - "challengee_location": "8c2ab60c5b05bff", - "challengee_lat": 42.961154068414594, - "challengee": "112mBp6av2P1Ko7aXQZSSBiZLPxi9dP2YL1E1M8ysBx9MbKPR4FJ" - }, - { - "witnesses": [], - "receipt": null, - "challengee_owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "challengee_lon": -82.46035597096102, - "challengee_location": "8c2ab60c14219ff", - "challengee_lat": 42.941715433247545, - "challengee": "11DvZivbwHVRx4PbQwAd5w2DQEAcfSCRVzsW7gjRKQ86nCEJxHJ" - }, - { - "witnesses": [], - "receipt": null, - "challengee_owner": "13gXUZcSK6RBAByDQmETVNgqXBQcSi7agTe1gN7mWevVJSY6qsp", - "challengee_lon": -82.45085880023731, - "challengee_location": "8c2ab60c426e7ff", - "challengee_lat": 42.9667313386322, - "challengee": "1128s66jgeG9oxw33FV7Gw52wfNukPSKGupB2C7N3w1poid5LeRC" - } - ], - "onion_key_hash": "py6G-BruPSyZQaTAoakOtOlHH5R7CVA_Ttn3ALt6j90", - "height": 397017, - "hash": "azI_l34BanrX73rYT7E7rKbqzEK_NqoKWckPRQUrvMo", - "fee": 0, - "challenger_owner": "13NjZfyLXDWks8mhgrwN7Mw9tN2Fm1qJ7XG6LVTqvdUHgCRYz2f", - "challenger_lon": -73.98415801053285, - "challenger_location": "8c2a100d225ebff", - "challenger_lat": 40.731030047462795, - "challenger": "11iaWmYt7ixwXqbWkCaYf5b9tS24GNy7Fq3af1MSNkfGGvKVPX5" - } - ], - "cursor": "eyJ0eXBlcyI6InBvY19yZWNlaXB0c192MSIsImJsb2NrIjozOTcwMDAsImFuY2hvcl9ibG9jayI6Mzk3MDAwfQ" -} -``` - - - - ---- - -## Available on the Solana API - -### List Hotspots - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots -``` - -List known hotspots as registered on the blockchain.The results are paged. If a `cursor` field is -present in the response, more results are available. - -The `filter_modes` parameter can be used to filter hotspot by how they were added to the blockchain. -Supported values are `full`, `dataonly`, or `light`. A comma separated list (no whitespace) can be -used to filter for multiple modes. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------------- | -------- | ---------------------------- | -| cursor (optional) | _string_ | Cursor for the page to fetch | -| filter_modes (optional) | _string_ | Filter hotspot types | - - - - -200: OK - -Hotspots successfully retrieved. - -```json -{ - "data": [ - { - "lng": -122.39186733984285, - "lat": 37.784056617819544, - "status": { - "online": "offline", - "height": 394065 - }, - "score_update_height": 395577, - "score": 0.25, - "owner": "14e35CChhsnuHJxjjzYAxsHKBKDgjUop4GuD8esB7gE2VDoyPXT", - "nonce": 1, - "name": "tall-plum-griffin", - "location": "8c283082a1a19ff", - "geocode": { - "short_street": "Bryant St", - "short_state": "CA", - "short_country": "US", - "short_city": "SF", - "long_street": "Bryant Street", - "long_state": "California", - "long_country": "United States", - "long_city": "San Francisco", - "city_id": "c2FuIGZyYW5jaXNjb2NhbGlmb3JuaWF1bml0ZWQgc3RhdGVz" - }, - "block_added": 395575, - "block": 397023, - "address": "11cxkqa2PjpJ9YgY9qK3Njn4uSFu6dyK9xV8XE4ahFSqN1YN2db" - }, - { - "lng": 5.5794356104890825, - "lat": 45.13127467725158, - "status": { - "online": "online", - "height": 391690 - }, - "reward_scale": 0.25, - "owner": "13wv9QctMFJqQpvbZq8GuwaKc7YxUuvMw6WQD5JouvB3L2kuGwT", - "nonce": 1, - "name": "keen-metal-halibut", - "location": "8c1f933292185ff", - "geocode": { - "short_street": "Chemin de la Colline", - "short_state": "Auvergne-Rhône-Alpes", - "short_country": "FR", - "short_city": "Lans-en-Vercors", - "long_street": "Chemin de la Colline", - "long_state": "Auvergne-Rhône-Alpes", - "long_country": "France", - "long_city": "Lans-en-Vercors", - "city_id": "bGFucy1lbi12ZXJjb3JzYXV2ZXJnbmUtcmjDtG5lLWFscGVzZnJhbmNl" - }, - "block_added": 395500, - "block": 397023, - "address": "1122FqmqcH5uk8J1BSAStYK436GAR9CuwDVuBT2gRduofm9Vh7Lq" - }, - - { - "lng": -81.77662146961255, - "lat": 24.55934059588725, - "status": { - "online": "online", - "height": 396910 - }, - "reward_scale": 0.2593841552734375, - "owner": "131uuuyiYrPczy1aCKDBhvxYTG7ZMNfnZnKgemesd3CZEe3y6EU", - "nonce": 2, - "name": "nutty-daffodil-ferret", - "location": "8c4416a324933ff", - "geocode": { - "short_street": "Seidenberg Ave", - "short_state": "FL", - "short_country": "US", - "short_city": "Key West", - "long_street": "Seidenberg Avenue", - "long_state": "Florida", - "long_country": "United States", - "long_city": "Key West", - "city_id": "a2V5IHdlc3RmbG9yaWRhdW5pdGVkIHN0YXRlcw" - }, - "block_added": 377240, - "block": 397023, - "address": "117ucorijFWJ662HH1q6aYz78Y5q2FfF9DMyx4Ka73vBqsEuuMG" - } - ], - "cursor": "eyJoZWlnaHQiOjM5NzAyMywiYmVmb3JlX2Jsb2NrIjozNzcyNDAsImJlZm9yZV9hZGRyZXNzIjoiMTE3dWNvcmlqRldKNjYySEgxcTZhWXo3OFk1cTJGZkY5RE15eDRLYTczdkJxc0V1dU1HIn0" -} -``` - - - - ---- - -### Rewards in a Rewards Block for a Hotspot - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -Notions of blocks should be replaced with time. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/rewards/:block -``` - -Returns rewards for a given hotspot for a given block. - -The result includes a `type` field which is the type of activity that generated the reward. - -This route is paged using a `cursor`. - -:::info - -For older reward results, if the `type` is `null` the amount is a total for that hotspot in the -given block. - -::: - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | -------------------------- | -| address (required) | _string_ | B58 address of the hotspot | - - - - -200: OK - -Rewards for a hotspot in block `470788` - -```json -{ - "data": [ - { - "type": null, - "timestamp": "2020-08-28T01:29:46.000000Z", - "hash": "DTU1GGfR0eU15hv6KiV_bg6FOJXfUWz4TjIq1H7TGy4", - "gateway": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "block": 470788, - "amount": 7885016, - "account": "12xUoMKwf12ABjNx4VCvYcNkX79gW1kzz2JnBLxkFbjswRczRvM" - } - ] -} -``` - - - - ---- - -### Hotspot for Address - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address -``` - -Fetch a hotspot with a given address. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | --------------------------- | -| address (optional) | _string_ | Address of hotspot to fetch | - - - - -200: OK - -```json -{ - "data": { - "address": "11cxkqa2PjpJ9YgY9qK3Njn4uSFu6dyK9xV8XE4ahFSqN1YN2db", - "block": 397024, - "block_added": 395575, - "geocode": { - "long_city": "San Francisco", - "long_country": "United States", - "long_state": "California", - "long_street": "Bryant Street", - "short_city": "SF", - "short_country": "US", - "short_state": "CA", - "short_street": "Bryant St", - "city_id": "c2FuIGZyYW5jaXNjb2NhbGlmb3JuaWF1bml0ZWQgc3RhdGVz" - }, - "lat": 37.784056617819544, - "lng": -122.39186733984285, - "location": "8c283082a1a19ff", - "name": "tall-plum-griffin", - "nonce": 1, - "owner": "14e35CChhsnuHJxjjzYAxsHKBKDgjUop4GuD8esB7gE2VDoyPXT", - "reward_scale": 0.25, - "status": { - "height": 394065, - "online": "offline" - } - } -} -``` - - - - ---- - -## Deprecated Endpoints - -### Hotspot Elections - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/hotspots/:address/elections -``` - -Lists the consensus group transactions that the given hotspot was involved in. This route is paged -using a `cursor`. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ------------------------------------- | -| address (required) | _number_ | B58 address of the hotspot to look up | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for the page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -Fetches consensus groups that the hotspot with address -`11ztQpmCJbfPxv3RjsnvFTozbikpZ72dgmHTYwBQ2n2rABytnLE` was a part of - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) [DEPRECATED] - -::: - -```json -{ - "data": [ - { - "delay": 0, - "hash": "bGZCTdsBxM5m0IuVLcy0RvJf_OOkZ3C9C-TsvmuoQ50", - "height": 372552, - "members": [ - "112mRr9U2QkP5svLtTZjnGZ9qMwExoY8zz3Y5KyNYh6eKsvhsaxT", - "11edHhAK28WHFMZ6D6HTKnzer9jXNRq57ghzxv1ij7ERPMXRKnH", - "119hQxQAhkGT7dWMPXoPH4E811PzJB9PsgVjsTcUCDLPaCT9aNP", - "11gQQknec6vuRm8exJU4UG9pyT1e1NXr6yZV7sjPdCwvXaYCJBN", - "112VVqgL1LRxy6jhAM4AtNVa4qDcw1KmfGf4HjkjQAszo23EqYYY", - "112L7A2Xpkh7fjKjuaTfq3WgEn9nnAXg2M7BTWsR9dYvn4eopguz", - "11Qg88VmPkmv2oZggft8THbNhMKtnhUjBVPFJdy33q64GFu5JPN", - "11tWRj2Qhnn177iVYm3KUmbPdMyhRfeqHqk9kCyiR7y57hdG9JA", - "11ztQpmCJbfPxv3RjsnvFTozbikpZ72dgmHTYwBQ2n2rABytnLE", - "112HwmAx3XVW2NUGWa9Gk1yB2zkxXE6Bv4FXgop5Was5Msa7SUcH", - "1129waT8yUcphrcgYecpoXQtSGh9HS7NZfc6EfBHhQgYKJGibBHH", - "11wevymXjkG1zPE717qjb8hJQpUaJZMMp4kr3AegmTQpu1jhZ7e", - "112uxvcQWcdBCgYkCPZGZaX3Fmpe4Xrx21qBNFyfA7YyEqEY6rbm", - "1144JMF9rZsvUfW7x6koYbKbYpp86gL1xUzWohejeSZti5aPXo4", - "112NpqyB7Jq3SrmG8tbMwW6rwic8ftpkDFPsechdRzuLE59QSNmY", - "11sVuJATssrZChv2uLe3pXbLfzBkfeeLSYhfZn8kgiwAq4oJJ7D" - ], - "proof": "g1AAAAdBeJxN1Hc422sbB_D4EZqaPVachCb2KPISLaexSuz3xGlfSq2gRtrUqFipWrFqROkxYnVQRUvNcy4cRZrkoLRV0qjWKClqtJza8-gf0fev55_7uj7393nu-yGCQCCJQODa4YEEMQJEOM-LWgy11VO2wWOG3h6XuP9s6LI83lXRLtnaLUZ8r7JGYQGEZ9xppKfYt0mNqfvtaqfsLKROmLSmzQq4PHSrUdR7cvwTgAS1VY8HZUqkYHGsZFP3B5XwoaXWQuIN--dDCbP-roluSJ5JWlU_c92rEPZ1YWQLvlDqtiS-QE2tQGCvmpr6l05w5ngmEpShHz1Ains1dSXBcFsqb94qLgn_7MXcItGxdE3cySs6FUBIYIL_JhGUGkIzVPK3-cj-JvbZw21TwST51LRk59BAC57pFMzvwVjcHGUKpR8Lh939dP7s1jtRk-ZUJfQgmRE4ufjDTMnYHKmOW_6JLv-5PLyJUzUUJhyBFqGDpyMDLt3rO-kMICJ0gnFS572P__Si1lSw-aXZ41UWSxp9Dc9OusCebN_t55mCyzOfVOrSg3QyDKl0556cK4IvWDOim9CW6mWHRWX2_-VMzWX9NQNB7qfNFC5y7flj875uK0ef5vt9PSIpHVCvqQcQQcutr9NY4oN7OHdJVk-ZW7-d-2gtLK_qWz2lQ7rRS4lnFhwErFusg53BbBUZ6emL_IaWJ90Ezul2nfogJ-Dopur3w2yCygcrfMas01kC97iMEOh4lOQuC2TLiv19UHGjVOo1gDDK-ScxUmbf7TJRR_bGz4m6fcEnA96C3p57XKoePuFEWOOZNVqxJv13NbbWtrDYoYE-pVqS_PCXjwoZmM27Doy3KPbRDMHem-CyXNL41WyekovwK5A-5RxBboZ7Xl2s6RghXK7psKvqhY9tqfw2Kd4ZRtsJ1045202_2s8ItJKObMZe1JZpTOaZLWa3Q2bIDXk7JGzbSGUXSSFPZlCWQGT88uJNOZzqa_29ygplCSCcn6uAByhBhAnjGMsHzE6JpHk-y5iPYWGrtx1BmXYmVADhnmjXGrIsFUv5gptbM5n8TewWVcRj51hwgaNvpXZF1jaPlOw0z1VdY73kgyMV9-2G5Qlwzd7Y7fuvllZ6E99E6escxYSgfFvS-7sV-D4n6IyQoflaulOQ6x82Oyq_eUXxj1u0HcYsLVaf0GTG4kgraC2BcxOcn5GMVntR-irQq3OPs5_J4ZkG3Un6253dK9PxzyFFxNYKzFInrVPIPoJ2ofbm-xqztaOY2j00abHZt3S5nCoruKvm17mQ_baZALojOArnzZJeNAEQwMv7w8y1HRG00A38uKlwch0kW7bgpECo_jwZLdweZcwjd9b0S-gLal-euD96uE3d7Aw_VXEuslRhkvkLak2Mq8A-IoX0Cn4VvZJXYZIzPnHfrfFWs-xlrkeB7tAfkQTqh8T8JgBhsCvfvdfxDO5S9hjeCUGKzTAfjkCdvSl8Orpaq7SteB4ZI2e0pYyCSUYbB3RMu4oP8T1yOas49ufZenH3Vd2_fNaPSKji7QP9TRC0B1yPVVGx2IWKQG8nvWFgQ7lPKFroLB8AQfw6gTb0naa4C16-LlsoyBa6yqpICKJSXT09utoKq0t45FMp_RMG_BifTUllSXGJvF6vnNQaTm6rverGaPFTvQjCEWk2LziAoe9lV-Hj5YWHnTTqnbv-964OXuk0Jdp6xnMVByDEFJyK8pPRmKxpavaG7XmPHdg1ncb-CkVffzkrmeL6ah7pGpXgA4-5Ryixb44TSOi_cBV1p4_c2kBUIvow7cRr__tjNQvxLkuBcTAQ92-yHO2hIh2nnWtYQhFIC8ZaZNQRb_UCCMUVCb_Rdu-D-phML0_zIZ9Q46TAD_w3-7sb6xDHu8-a88y5OxRIobWSYVs-17Ya8myn5UFBUPlGfNTBXkJmZgFM5WhmJURoRGlWgbCq7qU4s0ddlWo2s38aiAXfeCM6muL_GyH-sKsy293iskprGaMym7TojiwHkoPXzfcD5kFex8w6HP0sjl6TEqJR6uWugYn6o1YJQHkiGk4ozP_qQOfQVcGd_tPJuUdXC2u0OugSOwMtVo9n5sM0m9QGxozxz6xJp2NzZzW8e1MAxEWasGXJf2yiN0lG4hupTXGD5qGvmWF-eCe_CvwGQ43MI69XlzXIYJpO2L_qQR6UTkqHVUk2QhN9TZflAE3oxTqb71U2KKvDEPWcogNtGnwlWwas9bLftVyv_IwjZ6xC76orW9JgjzDz_QuiGBiYtb9nN_hb2RTnjWGEyHfqyHsxj0Gx6Y-UC2yWrvwLgaEVxg", - "time": 1592112154, - "type": "consensus_group_v1" - }, - { - "delay": 0, - "hash": "8_UTNYLnSwLmYKI4n5OzDdjOIkYYtBREvBGthDGFMZ0", - "height": 372519, - "members": [ - "112mRr9U2QkP5svLtTZjnGZ9qMwExoY8zz3Y5KyNYh6eKsvhsaxT", - "11edHhAK28WHFMZ6D6HTKnzer9jXNRq57ghzxv1ij7ERPMXRKnH", - "119hQxQAhkGT7dWMPXoPH4E811PzJB9PsgVjsTcUCDLPaCT9aNP", - "11gQQknec6vuRm8exJU4UG9pyT1e1NXr6yZV7sjPdCwvXaYCJBN", - "112VVqgL1LRxy6jhAM4AtNVa4qDcw1KmfGf4HjkjQAszo23EqYYY", - "112L7A2Xpkh7fjKjuaTfq3WgEn9nnAXg2M7BTWsR9dYvn4eopguz", - "11eMofv6oYA3Y7LE4EZxJzwxzyjNHdedKSMNDP5y8pCuvnaMRQ6", - "11Qg88VmPkmv2oZggft8THbNhMKtnhUjBVPFJdy33q64GFu5JPN", - "11tWRj2Qhnn177iVYm3KUmbPdMyhRfeqHqk9kCyiR7y57hdG9JA", - "11ztQpmCJbfPxv3RjsnvFTozbikpZ72dgmHTYwBQ2n2rABytnLE", - "112hMyXUsTjZV68R5GpP1CMPeyF546zQjnfi9mdUiwBxNqbi2Lw5", - "112HwmAx3XVW2NUGWa9Gk1yB2zkxXE6Bv4FXgop5Was5Msa7SUcH", - "1129waT8yUcphrcgYecpoXQtSGh9HS7NZfc6EfBHhQgYKJGibBHH", - "11wevymXjkG1zPE717qjb8hJQpUaJZMMp4kr3AegmTQpu1jhZ7e", - "112Hs1kfxaER29V3C4sebiiJJao3SYB91TJ8oRgmqnG1JSavHj6n", - "11263kd7cLpvrfBDv8GLEF5kq37kjxHFYE6t8KLEpe8fnwdLoUEx" - ], - "proof": "g1AAAAdHeJxN1Hk8FGgYB3AGg8i4rQxGo4l1jWbaZnJXJPcRhjFGrCss64qhXFvIyFUYDLJuRhErd8mRotWKYVCKkdw3ww7LH8P-9f7z-7zf93mf53192NjYBD0BvoeLHNvF138gdttfr05FveHN9mks0lxsJ7VzG4eQrCl3xyp0N49S1-H6ADm2UVAcNuF9ZM2aAXbdRDoq8VbCTTnj5K9a53-1WW95ROYEQEJxn5MMV3qK6gNfQJKdZ0bBVOIaf3XDd2Iugb-xFCrNMmP9Fcl4R0XN0L8oUADcCVIjJDNnZtJB7YBxtbtP3U9jmRCZUyubTc95JWbjw3vNhTcn1W46YGA-AKiDOFvH9C5f6eGpyDTp2GGL9jxzG8LZmoOfXR7-FjDDkXrjCb6hSDZzwNGPZQZtKFwKwGdJLc-PMMDzZOwiaP5RXBFE31tHx538hTp7lDKEGxzu-L15ySrH9ZRr18s4Pj1T_30YvDSjudhRIlwBjPgYHIc5jGxtL2MKVegQy5V4VIWcupuHJRFKF6haR7q7tcxV_57NQm38OHCdCzu0Lu6HPMFS-XQrDcboae26OCjyI6HTc3LhBG1LAPKXXx2xTd0fPl2u_LFAuB0mnG7ILryz0tMasNVUcxj5ELFwcC5plUbWLRzopszZckcnJPYIxf8d3zSjt8P57RYLLd_7DkweMNQerq7d5tlMp04DKDZmKgL6a4JpB1cGu21OOvqAi2l31WXY6vz1vC74N4HyOsE30WY-dQ5TyZQUDKCQBwDR9ae-hABEwd4_AXyT6RnMsVuLn6otvEqbLiFFaLnmFJbZ6cFPfZNdj1JReLDLNYG6hXOYXttW68aNlpEcbhgthJwUGiOJAF3OXhgqmPcIliEW_UD97s-7h5nHDbVa64Ubg18cRkZqCR_qRO_CHPnKwp2DltgmwftAo43xsyZ9G-PFLTwfWWiygspbR66yFHBjxzZophpzO1rHbesCIz1Uz_RCZp2l1VHKAH4NADkVUd8d6xkUMoAcaCOuNWL7mvSlraD5nzAWSvGKT6KzABAJjZTu1IE7akS9KHRurZnpngQCGfY-t3_gfUHBGWBYKouMkEQz5OFSImFaHq1T9qBB9lKMxtmJBo3nIMcNtRaXrWMSHa8r9vni-jUpdUmfFw8VSPNJb0gNBg90r4rXJ92QDh4HQHRUhGOQYaI42mQLORjHsPYN9MP5R0J6PKXcn9HGfDVY5DNRhNBFDk2XHRF5EZDgk158alwFNa3RGLZNy3l2IcTrpJ0VoUmOQys-_3BLj_XWfl6Se2WR64sWJ0z8YINAiI_HRgAQeSOP6ecxfa4LhXORS2IEQH8dPmXDNwM2I3TfVjPPtYFlZh54bF3d4rLlGjonLjZlx4G6JovlvKL2SnlcktMCC3M7MRdFcOopte_x9yoR0jFqbSnyId-wqspJYgolYCY6J4sAgHBadc2tpwSUvBYY2lC2G6O1ZBgtMytjLc4T-4tzdCEIllmhdE-7L1-RscnQ1x_sfwelBEl_Wvoqk6i5k2_SOQwfOhmhUdmLGOD3vKmGSK0SLeD-Hn-CkaXVZQulxitW3mqWCqKHkU5KuGEvO9W9Fl32UjHKcTDosXrhnXfMK8P7UQlAfC47C705SJXjexngN825HN-5y3BSxpLBmKq-O8zpyLdyVeO-xz-RLP26qxHvZfXyEFmeHmuxjWycbHGv8-24mrlt293Zko5Dk6QqnGkQsP3coQRW2e5JcaSD8n9SDkqMEBQV-DNLXkKJZYq066XBNrs_sIPlzu4bfZL2Av_ce2_36d-Lq70x_4QiVI9NaDPAf4aJd2KalnuN2XAkzRTYITe9nw50S-TEIbNFgEfXj3qQTKvUaFIiVXn2LwT_q-6soM046LVVyrd0QsJamlnmbHosb9Z1KKopY_pGOW_bXn1h5m9_bkeFHjCjicRMqXPHc-sj09xpTb7_ISRfqFY2HDg7vuVtZ29fy1gt-7zWp7-ffDjZSX3iCbvmncocha5C_eiRVeSzJ27LVZqqZp7-WGP5dhZpHxrtAo4o8Mo1rovkjO6z9oanvyM01vhAfVy6jEAU0-MyMW2TMl8rDZYvuWefVq62ec1FvIwuD_tWhHMoNkDQN46m7FHecuB6tbZhKIaZlRMgaULHvT13Rp_0KvLpmdE7b78Is8wvdo8ndvw8_ihwTkTIeudHZbdCCah_Q_gm7HUe3aUtN__vrSj300GaaGxQq0GL7mMz0DuJXrwfSryfK3aAkKZ6xgkAMVfp1lfC8_2CAvL8QGUG6mltQgPp-TeTSbwm3H5NmNbb_wG5EB0Z", - "time": 1592110088, - "type": "consensus_group_v1" - }, - { - "delay": 5, - "hash": "MdGogde_J7Let1-D-FKR5LqAVWsC_dcTqI15ix8zPMY", - "height": 372486, - "members": [ - "112mRr9U2QkP5svLtTZjnGZ9qMwExoY8zz3Y5KyNYh6eKsvhsaxT", - "11edHhAK28WHFMZ6D6HTKnzer9jXNRq57ghzxv1ij7ERPMXRKnH", - "119hQxQAhkGT7dWMPXoPH4E811PzJB9PsgVjsTcUCDLPaCT9aNP", - "11gQQknec6vuRm8exJU4UG9pyT1e1NXr6yZV7sjPdCwvXaYCJBN", - "112VVqgL1LRxy6jhAM4AtNVa4qDcw1KmfGf4HjkjQAszo23EqYYY", - "112L7A2Xpkh7fjKjuaTfq3WgEn9nnAXg2M7BTWsR9dYvn4eopguz", - "11eMofv6oYA3Y7LE4EZxJzwxzyjNHdedKSMNDP5y8pCuvnaMRQ6", - "11Qg88VmPkmv2oZggft8THbNhMKtnhUjBVPFJdy33q64GFu5JPN", - "11tWRj2Qhnn177iVYm3KUmbPdMyhRfeqHqk9kCyiR7y57hdG9JA", - "11ADL7tz5fazKdFM21kdo6K11k7bpjun6JwY22N4tx6ab6mjrYx", - "112Pah4kwPwuVmCTmD1T5tiM2YZTQ4MmoFg68zxwyZsiYVtk8Bx3", - "11ztQpmCJbfPxv3RjsnvFTozbikpZ72dgmHTYwBQ2n2rABytnLE", - "11knHXfj4QiwxtSajc6D8FQzpDZFCEL4Q2cF74K7Yu8Lp3pCXXu", - "112dDDJ8HCWR9qGC3jsm1UBBaVy2LgLu8Pryd4vNvHXhv8LL4gMW", - "112hMyXUsTjZV68R5GpP1CMPeyF546zQjnfi9mdUiwBxNqbi2Lw5", - "112HwmAx3XVW2NUGWa9Gk1yB2zkxXE6Bv4FXgop5Was5Msa7SUcH" - ], - "proof": "g1AAAAdHeJxF1Hk81HkYB_Dxq9RE65YMdoaiiWEck9llUY5hQlnH5Jxicx-zaIxxM2Ijdsgx7mssxoQcLbs17hwTuTdCbRIh2lwjmp3-mPz1_efzer2_z_N8n68_CAQS9QYCeAcM5EiKc5eLLPEpuNIUczSObeuHzBwgtzb4K_m792BFmFZfUxikKQADJeR3riH3OHpSFZ4LtbFtybQPxJpPVclC07jw8-HG1AYACvTl18ogUNtV5e6gyfd4j8rRqKfek2rSFcDZrZYnjGt8s0Y12oBdDOdscUxNx54NKDFD5cc_vFZI0d8ttuyeRE4cmiUu1TdNt_8aPQ0zWPl3V9680GzZv5GLjXwtML1r84CjAkCv5BZN-CTbl6qhcMxs9p3TYef8HZdOzshcaEq1CkfP1vFND--ZPdTbEykDdrRTqUbK3vL1JoGzzDliBiLM5GfrxplDk6KtErUf1lqvdx2I0Q3qh-yMpMhMVyfjr0pQKp0R5BUAan10O-DeCu6Bm4XEnOCysTU9Gzhz4NFjcnFV1mam3YzBN7u9hKe68prRiPN39o7Nom-6Oi38t6PR6_qiiuZkgV0lfk2ZI814ZrMDEPnr9ojNspHU8V5lpzTWiEN-y4HE5fWNJhsddXMiLzKNdhQMCoZk0QlheS3JDR3DRooEOfwT37JfGCZzV0Vz-GidpLYY6oi--67EWQkR0ax-PDWpZiqj9YryznR-nRbR52vKDGkCQEm746NPnpf0K8uIYctpZqCuj680HOIUk5wv7feWppGhABSFoS6Ech5vFmmbQuek7t8RLmF3Rkvqv8oJyYMLSw9e5JOoDor2Hqvj45vYLnCef2uF_hqLxjp-hUizZUbN1BhtHdbZ4pkrqt6iqjx-ArGpY-pz63RfwkLz4n0NHZLc30nDF37iRZ6-wIAW_UvhSH2K5U81L21CTSF_eK6mELpn0uoT4OPn-Kh90BHX7tXd6Z7jd0_chhS__VmP8-KUQVOSks4Iudv71Sp_oFA3bCdLYFDrO0SyfQk43VDNcfLpPsIsuVpTxIltX05V5JkV8KOd0nWNPrr21aU3I0hcVSvW5n27y44GUmzZZsLIPN-0G5uCCf0ZHLRwdD25e4_jpuZcKHe9lh12sBDTB6t9GXBY6Hx3vt5_uHWC-Pi2TPmG-V7Ug2vygB50mrGSXUqEyCrxIv92N2hwwbQt0x22mM_grFE8TFMwMWqprGXn5nzRi3o0H00gwAvxLnB9UgtTCUC6QRvEFN5bW3ZOdSofY3m-Scz4VqiDi84rMueBxpJjmAh-9OJw5HJXG45Qdef2F7uUcFtdMs_MC4W0fNnvaD4i3AcnUgJ7mMaKi_TXW4wRxmPb9q1hOt8M3TyvG4zPhayv_MORWyl0XhNZSUuqgJr6GRp6Fs5PLR1uy3LqmB99BgcOeZlZ0e5x0RhenPJmcoh78mH7lNitG5LmAPSaltfmM-eCt1-cH-ukE2gWVpC4ja42Tcy9bLzLXIOsAN-ceE9XTEIr_ym5cVBa1vyu0TacS1fOOm7sIKZOIYb2Dh02N3MCEVL7235j1mYAa8pkcXlKRbbaUD-wuShM_sP8Myd_XiRdesLCt3L7Ouck9QxcoU2gRizbwUv1B5XAh5YHuj7ua3xUckUK7B2kOf_8QLXHg1MF-lHheTbNK9gps2t8gZUHs_m2LQGCWYIkLyNMjutDXxTdeSQA9Xdr4Zsh8I4aHEFNIV4FoDClXCPXRxuV2O8HrCSCqun03-333tV7HcsL-EzKcMZp8EkJ1qUM5a3eIQE5mOIX7Li8j9yF_ui90uG1j_3xoyRt9cPeprri9D4Npael34ZZDmiKYk7F31U80O2L6KaMZTpEs90BqIrbjdwmJsbeLsultfES5Kmu1rHPGE-SrOUn-IF8gSeHb7bscE8wXcQTa8mOWnUFtNo1oSC9PxZ71Lcv1-uKUwySDk2q9V0uZ5oxG59t0vUOeiuineOOwwUOyiu-1jFnqXXwfr8LcQ0DEWI9mLsB6_GXd62ov_3TgKUMovViLqFizcM1X_LNpcwEcC5GCd2WvWBRDX7yubksJ7B8J5bEPYhLTc2BnPv2bm_veJdHo9j22Gb17EcEPOGRX3CPhQKWalOq8vFdup4n71YF7xlp4vf8LB-RQ_w1C0GON4Z95IC5xEap0bEzvq65IXxzHnd_djfIi1JyI0X7e7_i2LzHSmT0PlFo1tEwLWp6_a9v4zxb0A4N00ct5chV2XOEbKK12qW5Zz-X5SSYxVx1L1KLAKCykVahSLTqvLrA3BFmovSCtHgOvjKNwV19C_41rY4u7Ps_lTspEA", - "time": 1592108023, - "type": "consensus_group_v1" - }, - { - "delay": 0, - "hash": "22qhsNH-Rw-5v8exId1KHgitBAwPf45SPMwhpyylyKI", - "height": 372448, - "members": [ - "112mRr9U2QkP5svLtTZjnGZ9qMwExoY8zz3Y5KyNYh6eKsvhsaxT", - "11edHhAK28WHFMZ6D6HTKnzer9jXNRq57ghzxv1ij7ERPMXRKnH", - "119hQxQAhkGT7dWMPXoPH4E811PzJB9PsgVjsTcUCDLPaCT9aNP", - "11gQQknec6vuRm8exJU4UG9pyT1e1NXr6yZV7sjPdCwvXaYCJBN", - "112VVqgL1LRxy6jhAM4AtNVa4qDcw1KmfGf4HjkjQAszo23EqYYY", - "112L7A2Xpkh7fjKjuaTfq3WgEn9nnAXg2M7BTWsR9dYvn4eopguz", - "11GSd5uyaRF3BkYWc7XGVDz8FzMRTxBi5bHy5ZWjg8jN9mv5gnY", - "112qdBK6mYPCnovBTcUSPSspo5dDF2GQL7TXHNKihoiqYnDwaizS", - "112wEDaaeDbUUCNtcjd8LCX6epXuRvSM9qQZW2KtyM2vDgT6GK5N", - "11eMofv6oYA3Y7LE4EZxJzwxzyjNHdedKSMNDP5y8pCuvnaMRQ6", - "11Qg88VmPkmv2oZggft8THbNhMKtnhUjBVPFJdy33q64GFu5JPN", - "112M6AiQEedVsuzfw5au1WFUgSPEiaVCU31Aa1xjCHFYX8WohEnC", - "11tWRj2Qhnn177iVYm3KUmbPdMyhRfeqHqk9kCyiR7y57hdG9JA", - "11ADL7tz5fazKdFM21kdo6K11k7bpjun6JwY22N4tx6ab6mjrYx", - "112Pah4kwPwuVmCTmD1T5tiM2YZTQ4MmoFg68zxwyZsiYVtk8Bx3", - "11ztQpmCJbfPxv3RjsnvFTozbikpZ72dgmHTYwBQ2n2rABytnLE" - ], - "proof": "g1AAAAdAeJxF1Hs4E2ocB_A1cj3llsSMjdMey23ouIUcJJeTldyblrnMMkTMIveVhNJIxhA5RW5JLqu0LGLuoyJ3Z045c4nYXHI5-mPrr_ef7_N83u_z-70vHgAASAcCg_cOKKBhbVesCiV7ozLaU7-GSqlckAw98eRLmw7P6pmRLMki5WfKFmEDhEi3W7VxTtmh26aaSp_vJmCvyvou1lGLoJ4kvP0kBcEBQhTTqibpzEfItQzUloh4-WCjZIaIMdXVheEw4d5SDtfnk66hQt6t8-sjbaK3xSJBRf86n9j4fMDiRYr6cVZ0a-DUvIC0_Xsbe_6LP7Sl-zDuxWhm5FyteTBWaesuF26-sjqgfAMIiTHIflIEi_sY6aikIBtve2jjWX8tNBzTxeshmizuFkzzyeQr8AI0Cm5GbKhSByIuQmplVDhOfzGGGLD99AD2DfLP1GnEKSAkDLv1EFkrnZFyDL9SzSNl9idq330xj2vSUPt-_aFapiwQCvgU693N4qhYKWpdlQje56_CmuYNbOmWWV8zXG4thGct8c1W7G9D7_LqjbU1bm7uHzf28faa-b6m-977cxnFy95hniCoCd2KyrTZtdN4Y8nxvvBYhETUCbzalHRn2HU4Ht4HVJwGQiLlC7WGXMwPgoe9sNXJck6FF1flDDVqqCtn_OjFz24z-KQc_U8yjPu-d58yVG3H4QMYp3yMGbdZ3LewzEwaIBroCGqK-a6KhnUpm7SU-oqL9H-yhBUbeaahYm7KO7OiKQGM13s1S8I9Zz8WdEqEsUHiuh5CIjpW3O76UhQoLL7cY_AWy4pvRqxqGIWjc0Hf5oY3lOcKLixIzd1JKYWcCjp5MqBgcmhWUNMNLF2-9NzzGm8HpMjL1Q9ugm_fDxiwKEEO5JAzo8TAeyt2eFQFbLR4YokWeysDnvq5vgDR_IByQDqda1rx2MLclk_uDL7Bd5D1elj9nP-CQuWVJP_yEqkgM0dktnk9RzFu-YKaqNcbvEf_eDh2TXrMezE-3B7XYtVx9sUctPbVlEAxBrh7NQdcsjeLc1obrRH2CqXFgY1-7GUTzWqckHsE1wv_UQ_EN78r6WwbacVEZOcnVOPiaL6jqZllWl2Xns5PltdU-OV3800o4F42qfzyLl3B52y9Yiekujb4SNjuNYIxIKlCt_FKt4QHEKJ1jir91uFsSi-CDIaPY4bI7uOmU2M2uLSgQ3Dac8JBvvlHC8lgk96yzE54J56Hp5WaLdApdFFHAuV8VezoU0vuL7Nk5Fni5MhZnNldztKsSIwNF0wLjMGsZJsL3zluYJu3AoSYN6I7arXkbEiMVaf_3qs27DM97dmCjxx7zSohFXMc0_jmoTl58cBQvcn-bc02340ygKlKfw4FG-6V9e7DDD0Peu5nyg5hu2dS8DqqmoSUmIpB_2ZftLWmGW29vZGF1g0rkohP6P82sRdJvX5TW8LFCqpsGOJsdh_h-z4XiuzbUfJtOphsErtulcNHa5FZrrbXsBHJas2Kb7No26BvrhLQsKeUQs3iXOirI4mCHbJc_I4KI2IkTW41tqvFn1nsZ6cSSJNypRG4BR26COgAEOLqdrZX2PuKKNsk1zrtTY6LxdEgRpTqE327e_sn2iv1WvnkbFayeO5pdeOXOTP25eJvftSXPAh5tJZA3N1OTE9_ADoqIAlsE2KpRtM6EPYV1tMLU4jHIi_99pmXBOiwJbj3EB2AEMiP80hVq2EYd_HrfHd25xFCl0u55fir5UFn6vHLNZHtfFJdaoNnNWthoRDd4GQzL3b4WNyy1NJKoZ9BobSQ24y_269xzpxcSyseGzXskCjSjst3dkjtdjmQQ3mY8rIuWjsDA-sAQkzfcZXBRL3OFia7IMi6QC5T4y25zjOdrXb630eLBsOyfNOTmIhRvv4QR3V8ES-c2H0-CJHVGU2rxavjMW0OUlVnfpllQSj9E_-0_N4j5AScCFkAIBVf5ll6f_FTYg9-sSfrRgEhPkE1qslel9CAubpYfZnmrz6G-q7ioqiyl1560x-YEa_5psvgEFSyKTx0RvjbrdbNjYtaFwqUPSq7o7Zn4juglWPBgucZ8iOtszXWIg0qM3KSPjEpnd3Tc6N3u5L-agKUFLRpILF3KyqB1Nkp6dNXwrx-LumUys10eWZfNsIdDV6ANjXLPheMs-aQgcwfQmaYdbnf5aSk7zPR91KeDpFpjrC1kfwafQJOME7AykB0igxjyv-IEtLa44FR37SGZIOhHSxN2KkYkSFM2PuFpvx8wj9iWGX2xncTXjHHAkIuatpj43eq-qg5XBck7fL_jZ4mIA", - "time": 1592105642, - "type": "consensus_group_v1" - } - ] -} -``` - - - - ---- - -### Hotspots for Name - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/hotspots/name/:name -``` - -Fetch the hotspots which map to the given 3-word animal name. The name must be all lower-case with -dashes between the words, e.g. tall-plum-griffin. Because of collisions in the Angry Purple Tiger -algorithm, the given name might map to **more than one hotspot**. - - - - -_Path Parameters_ - -| param | Type | Note | -| ----- | -------- | --------------------------- | -| name | _string_ | Name of hotspot(s) to fetch | - - - - -200: OK - -```json -{ - "data": [ - { - "address": "11cxkqa2PjpJ9YgY9qK3Njn4uSFu6dyK9xV8XE4ahFSqN1YN2db", - "block": 397024, - "block_added": 395575, - "geocode": { - "long_city": "San Francisco", - "long_country": "United States", - "long_state": "California", - "long_street": "Bryant Street", - "short_city": "SF", - "short_country": "US", - "short_state": "CA", - "short_street": "Bryant St", - "city_id": "c2FuIGZyYW5jaXNjb2NhbGlmb3JuaWF1bml0ZWQgc3RhdGVz" - }, - "lat": 37.784056617819544, - "lng": -122.39186733984285, - "location": "8c283082a1a19ff", - "name": "tall-plum-griffin", - "nonce": 1, - "owner": "14e35CChhsnuHJxjjzYAxsHKBKDgjUop4GuD8esB7gE2VDoyPXT", - "reward_scale": 0.25, - "status": { - "height": 394065, - "online": "offline" - } - } - ] -} -``` - - - - ---- - -### Hotspot Name Search - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/hotspots/name?search= -``` - -Fetch the hotspots which match a search term in the given `search` term query parameter. The search -parameter needs to be at least one character, with 3 or more recommended. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------ | -------- | ------------------------------- | -| search | _string_ | The name fragment to search for | - - - - -200: OK - -Search results for `search=clever-gray` - -```json -{ [74/4462] - "data": [ - { - "address": "112sBjb6sHaEf9MbCaDEH3k4yFM4e2rHZxGTzpV9RTtfDqxX9CCC", - "block": 768022, - "block_added": 750477, - "geocode": { - "city_id": "c2FuIGZyYW5jaXNjb2NhbGlmb3JuaWF1bml0ZWQgc3RhdGVz", - "long_city": "San Francisco", - "long_country": "United States", - "long_state": "California", - "long_street": "Cerritos Avenue", - "short_city": "SF", - "short_country": "US", - "short_state": "CA", - "short_street": "Cerritos Ave" - }, - "last_change_block": 750502, - "last_poc_challenge": null, - "lat": 37.72614653945264, - "lng": -122.47020118178871, - "location": "8c28309510699ff", - "name": "clever-grape-boa", - "nonce": 1, - "owner": "13NrTQR32bCjPejvzLwKmBjeieZykBVbmoR7FKqKHFjVJocecak", - "reward_scale": 1.0, - "status": { - "height": 745390, - "listen_addrs": null, - "online": "offline" - }, - "timestamp_added": "2021-03-08T16:24:54.000000Z" - }, - { - "address": "11ZbFBWirta2WCW14SDoTbFpXa8C6ZYoN4QuWL6dQDLiHajmHce", - "block": 768022, - "block_added": 742230, - "geocode": { - "city_id": "cGhpbGFkZWxwaGlhcGVubnN5bHZhbmlhdW5pdGVkIHN0YXRlcw", - "long_city": "Philadelphia", - "long_country": "United States", - "long_state": "Pennsylvania", - "long_street": "City Avenue", - "short_city": "Philadelphia", - "short_country": "US", - "short_state": "PA", - "short_street": "City Ave" - }, - "last_change_block": 742262, - "last_poc_challenge": null, - "lat": 40.00814845396687, - "lng": -75.20963332539121, - "location": "8c2a1348e5a4bff", - "name": "clever-graphite-hyena", - "nonce": 1, - "owner": "148f6FrFVro4Yoc9FBoWRPVrEMusDGWZew2zgeSWBybK2CHmNKW", - "reward_scale": 1.0, [18/4462] - "status": { - "height": 738310, - "listen_addrs": null, - "online": "offline" - }, - "timestamp_added": "2021-03-01T19:58:41.000000Z" - }, - { - "address": "11QpxYxhrhG3E2FbuJSV5mgQW6cyp2rXMrjYoBN9y29e2XegDWY", - "block": 768022, - "block_added": 143709, - "geocode": { - "city_id": "bGl2ZXJtb3JlY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM", - "long_city": "Livermore", - "long_country": "United States", - "long_state": "California", - "long_street": "Glasgow Circle", - "short_city": "Livermore", - "short_country": "US", - "short_state": "CA", - "short_street": "Glasgow Cir" - }, - "last_change_block": 767734, - "last_poc_challenge": 767734, - "lat": 37.69373462966, - "lng": -121.75659980161144, - "location": "8c2830d36ba49ff", - "name": "clever-green-beetle", - "nonce": 4, - "owner": "13auTVmhWAhV6MV6hQ9huecHhLZTXH1MbUnMTKEBtTFJVaC5bic", - "reward_scale": 0.5555572509765625, - "status": { - "height": 767999, - "listen_addrs": [ - "/p2p/112qupChNrC4UVv5dHztTrtp6UWH6ooa9WQCbmXFuLxDHow82CY3/p2p-circuit/p2p/11QpxYxhrhG3E2FbuJSV5mgQW6cyp2rXMrjYoBN9y29e2XegDWY" - ], - "online": "online" - }, - "timestamp_added": "2019-12-21T08:26:08.000000Z" - }, - { - "address": "112pCaom9T5B7bmK8p6CRhBtWrxM1DEM2p4gjh44azuwjCzex2oE", - "block": 768022, - "block_added": 553919, - "geocode": { - "city_id": "ZGVhcmJvcm4gaGVpZ2h0c21pY2hpZ2FudW5pdGVkIHN0YXRlcw", - "long_city": "Dearborn Heights", - "long_country": "United States", - "long_state": "Michigan", - "long_street": "Nightingale Street", - "short_city": "Dearborn Heights", - "short_country": "US", - "short_state": "MI", - "short_street": "Nightingale St" - }, - "last_change_block": 767950, - "last_poc_challenge": 767950, - "lat": 42.33796350854145, - "lng": -83.28504344820625, - "location": "8c2ab2cd14833ff", - "name": "clever-ginger-meerkat", - "nonce": 3, - "owner": "13NQcBoZyngE8FbjxJZ1bHE2m7SLQyMPSMDAL3MRAquzgGttZN1", - "reward_scale": 1.0, - "status": { - "height": 767963, - "listen_addrs": [ - "/p2p/11254xZhWECFDcvZLPJEj6YmaWvTeUL1yrWdbTEVcV34C83am7w9/p2p-circuit/p2p/112pCaom9T5B7bmK8p6CRhBtWrxM1DEM2p4gjh44azuwjCzex2oE" - ], - "online": "online" - }, - "timestamp_added": "2020-10-22T16:49:16.000000Z" - } - ] -} -``` - - - - ---- - -### Hotspot Location Distance Search - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/hotspots/location/distance -``` - -Fetch the hotspots which are within a given number of meters from the given `lat` and `lon` -coordinates. This route is paged using a `cursor`. - - - - -_Query Parameters_ - -| param | Type | Note | -| -------- | --------- | --------------------------------------------------- | -| lat | _float_ | Latitude of the location to search around | -| lon | _float_ | Longitude of the location to search around | -| distance | _integer_ | Distance (in meters) from location to search within | - - - - -200: OK - -Search results for `?lat=38.12129445739087&lon=-122.52885074963571&distance=1000` - -```json -{ - "data": [ - { - "lng": -122.52885074963571, - "lat": 38.12129445739087, - "timestamp_added": "1970-01-01T00:00:00.000000Z", - "status": { - "online": "online", - "listen_addrs": ["/ip4/76.102.181.228/tcp/44158"], - "height": 771115 - }, - "reward_scale": 0.5, - "owner": "13buBykFQf5VaQtv7mWj2PBY9Lq4i1DeXhg7C4Vbu3ppzqqNkTH", - "nonce": 0, - "name": "curly-berry-coyote", - "location": "8c2830aa2529dff", - "last_poc_challenge": 771113, - "last_change_block": 771113, - "geocode": { - "short_street": "Andale Ave", - "short_state": "CA", - "short_country": "US", - "short_city": "Novato", - "long_street": "Andale Avenue", - "long_state": "California", - "long_country": "United States", - "long_city": "Novato", - "city_id": "bm92YXRvY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 1, - "block": 771120, - "address": "112Z6fYnkQa8VAyMWHoaZJVzrxbWPoJV2NCfdZmaNoG1pYxWdGwD" - }, - { - "lng": -122.52885074963571, - "lat": 38.12129445739087, - "timestamp_added": "1970-01-01T00:00:00.000000Z", - "status": { - "online": "online", - "listen_addrs": ["/ip4/76.102.181.228/tcp/44160"], - "height": 768806 - }, - "reward_scale": 0.5, - "owner": "13buBykFQf5VaQtv7mWj2PBY9Lq4i1DeXhg7C4Vbu3ppzqqNkTH", - "nonce": 0, - "name": "immense-eggplant-stallion", - "location": "8c2830aa2529dff", - "last_poc_challenge": 768733, - "last_change_block": 771071, - "geocode": { - "short_street": "Andale Ave", - "short_state": "CA", - "short_country": "US", - "short_city": "Novato", - "long_street": "Andale Avenue", - "long_state": "California", - "long_country": "United States", - "long_city": "Novato", - "city_id": "bm92YXRvY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 1, - "block": 771120, - "address": "11VKaN7fEvDm6NaGhcZtNSU1KAQQmTSwuuJsYYEqzh8mSWkoEUd" - } - ] -} -``` - - - - -### Hotspot Location Box Search - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/hotspots/location/box -``` - -Fetch the hotspots which are within a given geographic boundary indicated by it's south-wesetern and -north-eastern co-ordinates. This route is paged using a `cursor`. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----- | ------- | ---------------------------------- | -| swlat | _float_ | Latitude of the south-west corner | -| swlon | _float_ | Longitude of the south-west corner | -| nelat | _float_ | Latitude of the north-east corner | -| nelon | _float_ | Longitude of the north-east corner | - - - - -200: OK - -Search results for `?swlat=38.0795392&swlon=-122.5671627&nelat=38.1588012&nelon=-122.5046937` - -```json -{ - "data": [ - { - "lng": -122.51688114452725, - "lat": 38.109947587584905, - "timestamp_added": "2019-08-02T00:13:25.000000Z", - "status": { - "online": "online", - "listen_addrs": ["/ip4/64.7.85.50/tcp/28762"], - "height": 769399 - }, - "reward_scale": 1, - "owner": "13fTdByCpUDRKuVh4VZcUWh7rdehrh4UfjMdFt17ew4h93nD86s", - "nonce": 9, - "name": "agreeable-walnut-weasel", - "location": "8c2830ab51653ff", - "last_poc_challenge": 750521, - "last_change_block": 750521, - "geocode": { - "short_street": "Lockton Ln", - "short_state": "CA", - "short_country": "US", - "short_city": "Novato", - "long_street": "Lockton Lane", - "long_state": "California", - "long_country": "United States", - "long_city": "Novato", - "city_id": "bm92YXRvY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 3805, - "block": 771120, - "address": "11tWRj2Qhnn177iVYm3KUmbPdMyhRfeqHqk9kCyiR7y57hdG9JA" - }, - { - "lng": -122.55193831997157, - "lat": 38.1204024903364, - "timestamp_added": "2019-08-01T15:44:31.000000Z", - "status": { - "online": "online", - "listen_addrs": ["/ip4/76.102.181.228/tcp/44159"], - "height": 771118 - }, - "reward_scale": 1, - "owner": "13buBykFQf5VaQtv7mWj2PBY9Lq4i1DeXhg7C4Vbu3ppzqqNkTH", - "nonce": 7, - "name": "magic-rainbow-wasp", - "location": "8c2830aa2a63dff", - "last_poc_challenge": 771079, - "last_change_block": 771079, - "geocode": { - "short_street": "Morning Star Ct", - "short_state": "CA", - "short_country": "US", - "short_city": "Novato", - "long_street": "Morning Star Court", - "long_state": "California", - "long_country": "United States", - "long_city": "Novato", - "city_id": "bm92YXRvY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 3301, - "block": 771120, - "address": "112aeWRZdyz61Y7EQeMbXwqERNMPnciDvsxyFmhz1UfA9hte4R4W" - }, - { - "lng": -122.52885074963571, - "lat": 38.12129445739087, - "timestamp_added": "1970-01-01T00:00:00.000000Z", - "status": { - "online": "online", - "listen_addrs": ["/ip4/76.102.181.228/tcp/44158"], - "height": 771115 - }, - "reward_scale": 0.5, - "owner": "13buBykFQf5VaQtv7mWj2PBY9Lq4i1DeXhg7C4Vbu3ppzqqNkTH", - "nonce": 0, - "name": "curly-berry-coyote", - "location": "8c2830aa2529dff", - "last_poc_challenge": 771113, - "last_change_block": 771113, - "geocode": { - "short_street": "Andale Ave", - "short_state": "CA", - "short_country": "US", - "short_city": "Novato", - "long_street": "Andale Avenue", - "long_state": "California", - "long_country": "United States", - "long_city": "Novato", - "city_id": "bm92YXRvY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 1, - "block": 771120, - "address": "112Z6fYnkQa8VAyMWHoaZJVzrxbWPoJV2NCfdZmaNoG1pYxWdGwD" - }, - { - "lng": -122.52885074963571, - "lat": 38.12129445739087, - "timestamp_added": "1970-01-01T00:00:00.000000Z", - "status": { - "online": "online", - "listen_addrs": ["/ip4/76.102.181.228/tcp/44160"], - "height": 768806 - }, - "reward_scale": 0.5, - "owner": "13buBykFQf5VaQtv7mWj2PBY9Lq4i1DeXhg7C4Vbu3ppzqqNkTH", - "nonce": 0, - "name": "immense-eggplant-stallion", - "location": "8c2830aa2529dff", - "last_poc_challenge": 768733, - "last_change_block": 771071, - "geocode": { - "short_street": "Andale Ave", - "short_state": "CA", - "short_country": "US", - "short_city": "Novato", - "long_street": "Andale Avenue", - "long_state": "California", - "long_country": "United States", - "long_city": "Novato", - "city_id": "bm92YXRvY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 1, - "block": 771120, - "address": "11VKaN7fEvDm6NaGhcZtNSU1KAQQmTSwuuJsYYEqzh8mSWkoEUd" - } - ] -} -``` - - - - ---- - -### Hotspots for H3 Index - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/hotspots/hex/:h3_index -``` - -Fetch the hotspots which are in the given h3 index. The supported h3 indices are currently limited -to resolution 8. - - - - -_Path Parameters_ - -| param | Type | Note | -| -------- | -------- | ---------------------------------- | -| h3_index | _string_ | The h3 index to fetch hotspots for | - - - - -Fetch all hotspots in h3 index: `882aa38c2bfffff` - -```json -{ - "data": [ - { - "lng": -77.90290276709354, - "lat": 40.80885497979477, - "timestamp_added": "2020-10-30T00:03:08.000000Z", - "status": { - "online": "offline", - "listen_addrs": null, - "height": 829767 - }, - "reward_scale": 1, - "owner": "14Cx6WkXKpaD3GFf9VkG8kLsYjQ325y4egFZKs2vJ2hB5Ftrg66", - "nonce": 3, - "name": "zesty-cinnamon-lobster", - "location": "8c2aa38c2a06dff", - "last_poc_challenge": 829703, - "last_change_block": 829807, - "geocode": { - "short_street": "N Atherton St", - "short_state": "PA", - "short_country": "US", - "short_city": "State College", - "long_street": "North Atherton Street", - "long_state": "Pennsylvania", - "long_country": "United States", - "long_city": "State College", - "city_id": "c3RhdGUgY29sbGVnZXBlbm5zeWx2YW5pYXVuaXRlZCBzdGF0ZXM" - }, - "gain": 12, - "elevation": 0, - "block_added": 565473, - "block": 842630, - "address": "1114BGcrdwhio7beaKEP49vp8sjrYAzsubonZV7nPrwoZxr4Ns4" - } - ] -} -``` - - - - ---- - -### Currently Elected Hotspots - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/hotspots/elected -``` - -Returns the list of hotspots that are currently elected to the consensus group. - - - - -_No Parameters_ - - - - -200: OK - -```json -{ - "data": [ - { - "lng": -121.85991310272425, - "lat": 37.71966414273407, - "status": { - "online": "online", - "height": 488792 - }, - "score_update_height": 488777, - "score": 0.9963226318359375, - "owner": "14S7ZHRYtCCLExgh5qJphfB25dZHn3Pfy6pBkXHNgG7WvkWxazS", - "nonce": 1, - "name": "genuine-grape-mockingbird", - "location": "8c2830d2334adff", - "geocode": { - "short_street": "Cranbrook Pl", - "short_state": "CA", - "short_country": "US", - "short_city": "Dublin", - "long_street": "Cranbrook Place", - "long_state": "California", - "long_country": "United States", - "long_city": "Dublin", - "city_id": "ZHVibGluY2FsaWZvcm5pYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 450212, - "block": 488901, - "address": "11A45JqGJ8Jnx9YnuncFYLtBj6Vn8nhcQTc6uh549QzqqFMc4F3" - }, - { - "lng": -90.31235668207206, - "lat": 38.65572336414821, - "status": { - "online": "online", - "height": 488880 - }, - "score_update_height": 488872, - "score": 0.98834228515625, - "owner": "13FYzYCw1VMJzbFNAqNB7GDD2EWPB7uE82iHj33g5KrWyZAvpPm", - "nonce": 1, - "name": "polite-raspberry-newt", - "location": "8c2646260973bff", - "geocode": { - "short_street": "Washington Ave", - "short_state": "MO", - "short_country": "US", - "short_city": "University City", - "long_street": "Washington Avenue", - "long_state": "Missouri", - "long_country": "United States", - "long_city": "University City", - "city_id": "dW5pdmVyc2l0eSBjaXR5bWlzc291cml1bml0ZWQgc3RhdGVz" - }, - "block_added": 459422, - "block": 488901, - "address": "11UeLFyfHaoL8U2oWmtkDYxSt37ZSd432Jnaa2Uy4rLSTHP5AiG" - }, - { - "lng": -74.01032445204942, - "lat": 40.72147348660547, - "status": { - "online": "online", - "height": 488871 - }, - "score_update_height": 488768, - "score": 0.9685516357421875, - "owner": "13cAirRyuUzK9pWNHQoQnk6ikLYCxHyACQvV6RJMdt4ymyNpD1K", - "nonce": 1, - "name": "cool-tawny-chameleon", - "location": "8c2a1072c44bdff", - "geocode": { - "short_street": "Washington St", - "short_state": "NY", - "short_country": "US", - "short_city": "New York", - "long_street": "Washington Street", - "long_state": "New York", - "long_country": "United States", - "long_city": "New York", - "city_id": "bmV3IHlvcmtuZXcgeW9ya3VuaXRlZCBzdGF0ZXM" - }, - "block_added": 157683, - "block": 488901, - "address": "1124V1P146uMRpNvyuoRc8Uda1G54wqVBPuRzxzNuhEMFdNFkuaD" - }, - { - "lng": -84.14116349722525, - "lat": 34.099581418911974, - "status": { - "online": "online", - "height": 488880 - }, - "score_update_height": 488885, - "score": 0.9802703857421875, - "owner": "13Htq8exAPrLx35PhTJU4Tk2N7sGw1sdfLUtaCUcik7cZJQWQJJ", - "nonce": 1, - "name": "joyful-citron-walrus", - "location": "8c44c128eb151ff", - "geocode": { - "short_street": "Bradford Ln", - "short_state": "GA", - "short_country": "US", - "short_city": "Suwanee", - "long_street": "Bradford Lane", - "long_state": "Georgia", - "long_country": "United States", - "long_city": "Suwanee", - "city_id": "c3V3YW5lZWdlb3JnaWF1bml0ZWQgc3RhdGVz" - }, - "block_added": 100661, - "block": 488901, - "address": "11cpUwQf8DpRaJbKpDwr8rBAQTmsVp72X4LePQokUM8SZWfaPSp" - }, - { - "lng": -112.02337472794586, - "lat": 33.371050552126555, - "status": { - "online": "online", - "height": 488892 - }, - "score_update_height": 488877, - "score": 0.7867889404296875, - "owner": "13ZQv5D9xiAziFxYz5SffsZH3iTaKW7WH5LXeWvnq79usjwrwhN", - "nonce": 2, - "name": "old-opal-bison", - "location": "8c48e96934201ff", - "geocode": { - "short_street": "E South Mountain Ave", - "short_state": "AZ", - "short_country": "US", - "short_city": "Phoenix", - "long_street": "East South Mountain Avenue", - "long_state": "Arizona", - "long_country": "United States", - "long_city": "Phoenix", - "city_id": "cGhvZW5peGFyaXpvbmF1bml0ZWQgc3RhdGVz" - }, - "block_added": 102779, - "block": 488901, - "address": "112ucXwiiR6i6zgkEbfUHpFtggivB4qKx8EMjAG7ZSJmhTrRwTA1" - }, - { - "lng": -79.88736058394272, - "lat": 40.398811120042815, - "status": { - "online": "online", - "height": 488864 - }, - "score_update_height": 488893, - "score": 0.8791351318359375, - "owner": "14FUSqWYcWfQd7KQjrDSPXehsxvtJqxFf2q2QdxakbH4597KCz9", - "nonce": 1, - "name": "custom-khaki-bat", - "location": "8c2a8472a5287ff", - "geocode": { - "short_street": "Grant Ave", - "short_state": "PA", - "short_country": "US", - "short_city": "Homestead", - "long_street": "Grant Avenue", - "long_state": "Pennsylvania", - "long_country": "United States", - "long_city": "Homestead", - "city_id": "aG9tZXN0ZWFkcGVubnN5bHZhbmlhdW5pdGVkIHN0YXRlcw" - }, - "block_added": 161205, - "block": 488901, - "address": "11rraissynzdXzuvR9C9zsiPuZCMsJ33jMszpNqafKhCN8T1LtJ" - }, - { - "lng": -104.9819667654663, - "lat": 39.731924587349546, - "status": { - "online": "online", - "height": 488887 - }, - "score_update_height": 488873, - "score": 0.681549072265625, - "owner": "14mgCFAcGKtcu3L3ZFrqFNvcozeWFCNRvqWtwBvifa1R6EqmiaJ", - "nonce": 4, - "name": "shaggy-pistachio-rabbit", - "location": "8c268cda821b9ff", - "geocode": { - "short_street": "Logan St", - "short_state": "CO", - "short_country": "US", - "short_city": "Denver", - "long_street": "Logan Street", - "long_state": "Colorado", - "long_country": "United States", - "long_city": "Denver", - "city_id": "ZGVudmVyY29sb3JhZG91bml0ZWQgc3RhdGVz" - }, - "block_added": 126278, - "block": 488901, - "address": "11pbDpPD8xGQxzJYcEgUTjB2A299bZqd5MyP3CUiEqYLdiDe4CX" - }, - { - "lng": -118.43240806178659, - "lat": 34.06300352288759, - "status": { - "online": "online", - "height": 488881 - }, - "score_update_height": 488816, - "score": 0.7606201171875, - "owner": "14WKFHYag7LGCFgPBWQUHiM2Pvtie1fiykDSUGUecKQMwPgMNuA", - "nonce": 1, - "name": "jumpy-pear-toad", - "location": "8c29a199d4639ff", - "geocode": { - "short_street": "Wilshire Blvd", - "short_state": "CA", - "short_country": "US", - "short_city": "Los Angeles", - "long_street": "Wilshire Boulevard", - "long_state": "California", - "long_country": "United States", - "long_city": "Los Angeles", - "city_id": "bG9zIGFuZ2VsZXNjYWxpZm9ybmlhdW5pdGVkIHN0YXRlcw" - }, - "block_added": 465022, - "block": 488901, - "address": "11DDaP3k7aZFKr1C8B9gdyvChX79RHvGbydzRxwEVHEBFd3NdKK" - }, - { - "lng": -87.90081429668973, - "lat": 42.126905592654815, - "status": { - "online": "online", - "height": 488887 - }, - "score_update_height": 488879, - "score": 0.9979248046875, - "owner": "14EQRNNEmjK8bM97NEp5vM441u7mcTxrPjnVJ4dJ8SD2X9Qwseb", - "nonce": 5, - "name": "brilliant-teal-lemur", - "location": "8c2759adc50bdff", - "geocode": { - "short_street": "Mill Cir", - "short_state": "IL", - "short_country": "US", - "short_city": "Wheeling", - "long_street": "Mill Circle", - "long_state": "Illinois", - "long_country": "United States", - "long_city": "Wheeling", - "city_id": "d2hlZWxpbmdpbGxpbm9pc3VuaXRlZCBzdGF0ZXM" - }, - "block_added": 117340, - "block": 488901, - "address": "11UtixMtxVK73SrdDqXGTRsmJNfgiHipXUHmeF6Tjp4HETnSooz" - }, - { - "lng": -80.18078079776579, - "lat": 26.022409638823497, - "status": { - "online": "online", - "height": 488881 - }, - "score_update_height": 488858, - "score": 0.9946136474609375, - "owner": "14FvBfvRkERkW4RrR16i5NharQh8Ehjq77RowbpWbdxUiHAXUdi", - "nonce": 1, - "name": "zesty-peanut-nightingale", - "location": "8c44a10426003ff", - "geocode": { - "short_street": "Cleveland St", - "short_state": "FL", - "short_country": "US", - "short_city": "Hollywood", - "long_street": "Cleveland Street", - "long_state": "Florida", - "long_country": "United States", - "long_city": "Hollywood", - "city_id": "aG9sbHl3b29kZmxvcmlkYXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 452874, - "block": 488901, - "address": "11VSRV6KZjdhBqabde1Piq4zkRVa1WRNEFAW22XMBfGtAHW7nV9" - }, - { - "lng": -121.97991888865624, - "lat": 37.31889190483364, - "status": { - "online": "online", - "height": 488862 - }, - "score_update_height": 488845, - "score": 0.9733428955078125, - "owner": "14NHk7ajkBnsBsSfZSmmHRD5SHb1UvWyLdwz5z9MCEDyjezFWXD", - "nonce": 1, - "name": "rapid-spruce-opossum", - "location": "8c28347048cd1ff", - "geocode": { - "short_street": "Norwalk Dr", - "short_state": "CA", - "short_country": "US", - "short_city": "San Jose", - "long_street": "Norwalk Drive", - "long_state": "California", - "long_country": "United States", - "long_city": "San Jose", - "city_id": "c2FuIGpvc2VjYWxpZm9ybmlhdW5pdGVkIHN0YXRlcw" - }, - "block_added": 147758, - "block": 488901, - "address": "112uRR5Vhz1kBW6c2Jbn4wDcokKibUi3NSjLwDGnBBHFuwNYuidN" - }, - { - "lng": -74.91795266574553, - "lat": 39.04734411775066, - "status": { - "online": "online", - "height": 488888 - }, - "score_update_height": 488850, - "score": 0.9910125732421875, - "owner": "13oBvk7EmZ5nMckycXRoBrR7ymXeFWn86gFhso14QnJWmB8HJQG", - "nonce": 3, - "name": "acidic-banana-pangolin", - "location": "8c2aad1441095ff", - "geocode": { - "short_street": "N 12th St", - "short_state": "NJ", - "short_country": "US", - "short_city": "Villas", - "long_street": "North 12th Street", - "long_state": "New Jersey", - "long_country": "United States", - "long_city": "Villas", - "city_id": "dmlsbGFzbmV3IGplcnNleXVuaXRlZCBzdGF0ZXM" - }, - "block_added": 448442, - "block": 488901, - "address": "11xF1ZrLGDtS1VrLU7zCwzMBu3UCHrLTzPvvT63qkcDvSnLgzYy" - }, - { - "lng": -118.3147080907313, - "lat": 34.024854598484325, - "status": { - "online": "online", - "height": 488892 - }, - "score_update_height": 488863, - "score": 0.9638671875, - "owner": "146j8VSV8gydkDVmUMeBbzwM5t879uzK5xop9Gx1Hs4pEACEszp", - "nonce": 4, - "name": "crazy-cedar-swift", - "location": "8c29a1d65c687ff", - "geocode": { - "short_street": "W 35th St", - "short_state": "CA", - "short_country": "US", - "short_city": "Los Angeles", - "long_street": "West 35th Street", - "long_state": "California", - "long_country": "United States", - "long_city": "Los Angeles", - "city_id": "bG9zIGFuZ2VsZXNjYWxpZm9ybmlhdW5pdGVkIHN0YXRlcw" - }, - "block_added": 338998, - "block": 488901, - "address": "112UBBKntnNF6LeqDTVfNmay9X3CKQSVW5iaSiFqFVfWpjCP3VKF" - }, - { - "lng": -122.42776937373586, - "lat": 37.66143533833919, - "status": { - "online": "online", - "height": 488891 - }, - "score_update_height": 488803, - "score": 0.985321044921875, - "owner": "14HvA6X2uKjSwsihJPnHHx2P4E1rbCTjSJuWkKAZzNpeUmfeRR2", - "nonce": 1, - "name": "rich-oily-whale", - "location": "8c2830972d329ff", - "geocode": { - "short_street": "Treeside Ct", - "short_state": "CA", - "short_country": "US", - "short_city": "South San Francisco", - "long_street": "Treeside Court", - "long_state": "California", - "long_country": "United States", - "long_city": "South San Francisco", - "city_id": "c291dGggc2FuIGZyYW5jaXNjb2NhbGlmb3JuaWF1bml0ZWQgc3RhdGVz" - }, - "block_added": 147503, - "block": 488901, - "address": "11oygj4b5zEagbSTP3ozTcYfBCHJwLX9uQKeUtS65howdQyteGJ" - }, - { - "lng": -75.27826551964438, - "lat": 40.08090500714629, - "status": { - "online": "online", - "height": 488816 - }, - "score_update_height": 488885, - "score": 0.991241455078125, - "owner": "13oBvk7EmZ5nMckycXRoBrR7ymXeFWn86gFhso14QnJWmB8HJQG", - "nonce": 4, - "name": "noisy-coal-beaver", - "location": "8c2aac9492d51ff", - "geocode": { - "short_street": "State Rte 3014", - "short_state": "PA", - "short_country": "US", - "short_city": "Lafayette Hill", - "long_street": "State Route 3014", - "long_state": "Pennsylvania", - "long_country": "United States", - "long_city": "Lafayette Hill", - "city_id": "bGFmYXlldHRlIGhpbGxwZW5uc3lsdmFuaWF1bml0ZWQgc3RhdGVz" - }, - "block_added": 448854, - "block": 488901, - "address": "11judjQVWMVBmsvBaQrtBZE831wVBo7LLdU4RKU1J7aVEqvztrx" - }, - { - "lng": -94.24977711202023, - "lat": 36.334097707199234, - "status": { - "online": "online", - "height": 488885 - }, - "score_update_height": 488783, - "score": 0.9935455322265625, - "owner": "13ickN56yPe38a3Vga161gp4nkSLckWvy7JChvnFr9osfP4AHGE", - "nonce": 1, - "name": "colossal-tangerine-reindeer", - "location": "8c26ed42c3915ff", - "geocode": { - "short_street": "SW Layton Rd", - "short_state": "AR", - "short_country": "US", - "short_city": "Bentonville", - "long_street": "Southwest Layton Road", - "long_state": "Arkansas", - "long_country": "United States", - "long_city": "Bentonville", - "city_id": "YmVudG9udmlsbGVhcmthbnNhc3VuaXRlZCBzdGF0ZXM" - }, - "block_added": 100810, - "block": 488901, - "address": "11Fi6ynL2ecRiTGoJGtLcWYPJXQv1aH4jxgbUTejZtu4rBtvUYZ" - } - ] -} -``` - - - - ---- diff --git a/docs/api/blockchain/introduction.mdx b/docs/api/blockchain/introduction.mdx deleted file mode 100644 index daacf7628..000000000 --- a/docs/api/blockchain/introduction.mdx +++ /dev/null @@ -1,87 +0,0 @@ ---- -id: introduction -title: Introduction -pagination_label: Introduction -sidebar_label: Introduction -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/introduction -hide_table_of_contents: true ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Blockchain API - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Endpoints - -The Helium [blockchain API](https://github.com/helium/blockchain-http) serves up the blockchain from -a database that is filled by a [blockchain node](https://github.com/helium/blockchain-etl) that -populates the database as blocks come in. - -While anyone can run a node and a corresponding API, the Helium hosted version offers up the API -through two endpoints. - -- **https://api.helium.wtf** — Beta, scalable endpoint for new features and tests. Currently - connected to mainnet. This endpoint is used for feature development. Submitted transactions may - get dropped. -- **https://api.helium.io** — Stable, scalable production service. Connected to mainnet. - -### Specify a User-Agent - -To access the helium api via script you will need to specify a valid `User-Agent` HTTP header field -identifying your agent, all requests made without a `User-Agent` header will result in an error -`429 Slow down gun powder!`. - -## Routes - -The API routes are grouped together in sub-pages of this page. Refer to the subpages for details. - -## Cursors - -In order to return data quickly and reduce the load on the API, a `cursor` may be returned from an -API request. The documentation for each route will indicate whether the result is paged with a -cursor. - -In order to request the next page of results, add a cursor URL parameter to the URL that was used to -make the first request. - -For example: - -```text -export API_URL=https://api.helium.io -http get $(API_URL)/v1/blocks -``` - -will return a `data` array with _zero or more_ block results and a `cursor` field. To request the -next page: - -```text -http get $(API_URL)/v1/blocks?cursor=eyJiZWZvcmUiOjQzOTIwMX0 -``` - -Which will return the next page of results and a next `cursor` for the following page. A cursor will -be returned with each response until the last page is reached, at which point no cursor is returned. - -:::info - -In order to improve caching the API may return an empty data array and a cursor. Use the cursor to -request more data. - -::: - -## Transaction Units - -All API endpoints which return a transaction value (i.e. `fee`, `amount`, etc) are represented in -the base unit `bones`. - -The conversion rate is `100,000,000 bone` per `HNT`. diff --git a/docs/api/blockchain/locations.mdx b/docs/api/blockchain/locations.mdx deleted file mode 100644 index 1f59f223b..000000000 --- a/docs/api/blockchain/locations.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -id: locations -title: Locations -pagination_label: Locations -sidebar_label: Locations -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/locations ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -Locations are used to associate human readable geographic informaion to an h3 location. This API -exposes this geographic information. - ---- - -## Deprecated Endpoints - -### Get Location - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/locations/:location -``` - -Get geographic information for a given location - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------- | -------- | -------- | -| location (required) | _string_ | h3 index | - - - - -200: OK - -```json -{ - "data": { - "city_id": "c2FuIGpvc2VjYWxpZm9ybmlhdW5pdGVkIHN0YXRlcw", - "location": "8c28347213117ff", - "long_city": "San Jose", - "long_country": "United States", - "long_state": "California", - "long_street": "Rainbow Drive", - "short_city": "San Jose", - "short_country": "US", - "short_state": "CA", - "short_street": "Rainbow Dr" - } -} -``` - - - diff --git a/docs/api/blockchain/oracle-prices.mdx b/docs/api/blockchain/oracle-prices.mdx deleted file mode 100644 index 609c874b5..000000000 --- a/docs/api/blockchain/oracle-prices.mdx +++ /dev/null @@ -1,431 +0,0 @@ ---- -id: oracle-prices -title: Oracle Prices -pagination_label: Oracle Prices -sidebar_label: Oracle Prices -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/oracle-prices ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Oracles API - -### Current Oracle Price - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/oracle/prices/current -``` - -The current Oracle Price and at which block it took effect. - - - - -_No Parameters_ - - - - -200: OK - -The current Oracle Price and at which block it took effect. - -```json -{ - "data": { - "price": 167000000, - "block": 471570 - } -} -``` - - - - ---- - -### Current and Historical Oracle Prices - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/oracle/prices -``` - -The current and historical Oracle Prices and at which block they took effect. This route is paged -using a cursor. - - - - -_Path Parameters_ - -| param | Type | Note | -| -------------------- | --------- | --------------------------------------------------------------------- | -| max_block (optional) | _integer_ | Last block number to include in the results | -| cursor (optional) | _string_ | Returned from an initial query, allowing client to fetch more results | - - - - -200: OK - -Returns a list of recent Oracle Prices and at which block they took effect. - -```json -{ - "data": [ - { - "price": 167000000, - "block": 471570 - }, - { - "price": 169630000, - "block": 471540 - } - ], - "cursor": "eyJiZWZvcmUiOjQ2NjE5MH0" -} -``` - - - - ---- - -### Oracle Price Stats - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/oracle/prices/stats -``` - -Gets statistics on Oracle prices. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | ------------------------------ | -| min_time (required) | _string_ | First time to include in stats | -| max_time (required) | _string_ | Last time to include in stats | - - - - -Returns Oracle price statistics over the last 30 days by specifying `?min_time=-30%20day` - -200: OK - -```json -{ - "data": { - "avg": 12.433719079615384, - "max": 20.0, - "median": 12.53731614, - "min": 6.0, - "stddev": 3.50807814 - }, - "meta": { - "max_time": "2021-04-20T15:52:28Z", - "min_time": "2021-03-21T15:52:28Z" - } -} -``` - - - - ---- - -### Oracle Price at a Specific Block - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/oracle/prices/:block -``` - -Provides the oracle price at a specific block and at which block it initially took effect. - - - - -_Path Parameters_ - -| param | Type | Note | -| ---------------- | -------- | ---------------------------------------- | -| block (required) | _string_ | The block to get the HNT Oracle Price at | - - - - -200: OK - -Returns a list of recent Oracle Prices and at which block they took effect.. - -```json -{ - "data": { - "price": 167000000, - "block": 471570 - } -} -``` - - - - ---- - -### List Oracle Activity - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/oracle/activity -``` - -List oracle price report transactions for all oracle keys. This route is paged with a cursor. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for the next page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -::: - -```json -{ - "cursor": "eyJ0eXBlcyI6InByaWNlX29yYWNsZV92MSIsImJsb2NrIjozNzc5MDAsImFuY2hvcl9ibG9jayI6Mzc3OTAwfQ", - "data": [ - { - "block_height": 377896, - "fee": 0, - "hash": "UcKE8X9UtuhOx5N3yxjyI7QcVihSoJTBq_DVQME7RWI", - "height": 377900, - "price": 35736000, - "public_key": "13Btezbvbwr9LhKmDQLgBnJUgjhZighEjNPLeu79dqBbmXRwoWm", - "time": 1592484227, - "type": "price_oracle_v1" - } - ] -} -``` - - - - ---- - -### List Activity for a Specific Oracle - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/oracle/:address/activity -``` - -Lists price report transactions for the given oracle key. This route is paged using a cursor. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------- | -| address (optional) | _string_ | The public key of the oracle | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for the next page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -::: - -```json -{ - "cursor": "eyJ0eXBlcyI6InByaWNlX29yYWNsZV92MSIsImJsb2NrIjozNzc5MDAsImFuY2hvcl9ibG9jayI6Mzc3OTAwfQ", - "data": [ - { - "block_height": 377896, - "fee": 0, - "hash": "UcKE8X9UtuhOx5N3yxjyI7QcVihSoJTBq_DVQME7RWI", - "height": 377900, - "price": 35736000, - "public_key": "13Btezbvbwr9LhKmDQLgBnJUgjhZighEjNPLeu79dqBbmXRwoWm", - "time": 1592484227, - "type": "price_oracle_v1" - } - ] -} -``` - - - - ---- - -### Get Predicted HNT Oracle Prices - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/oracle/predictions -``` - -This returns a list of expected times when the Oracle Price is expected to change.The blockchain -operates in "block-time", meaning that blocks can come out at some schedule close to 1 per minute. -Oracles report in "wall-clock-time", meaning they report what they believe the price should be.If -the route returns one or more prices and times, it indicates that the chain is expected to adjust -the price (based on Oracle reports) no earlier than the indicated time to the returned price.NOTE: A -prediction may not be seen in the blockchain if they are close together (within 10 blocks) since -block times may cause the blockchain to skip to a next predicted price. If no predictions are -returned the current HNT Oracle Price is valid for at least 1 hour. - - - - -_No Parameters_ - - - - -200: OK - -Returns a prediction that the price will change to 47000000 at the earliest at the indicated seconds -since Unix epoch time. - -```json -{ - "data": [ - { - "price": 47000000, - "time": 1594410146 - } - ] -} -``` - - - diff --git a/docs/api/blockchain/ouis.mdx b/docs/api/blockchain/ouis.mdx deleted file mode 100644 index 7ab88f92a..000000000 --- a/docs/api/blockchain/ouis.mdx +++ /dev/null @@ -1,306 +0,0 @@ ---- -id: ouis -title: OUIs -pagination_label: OUIs -sidebar_label: OUIs -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/ouis ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -> Organization Unique Identifiers - -OUIs are used to assign part of the global address space to a given set of router addresses. -Hotspots that see device traffic will look up the router address for the given device OUI and offer -the device data to registered router. - ---- - -## Deprecated Endpoints - -### List OUIs - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/ouis -``` - -Lists all OUI transactions known to the blockchain. - -This route is `cursor` paginated. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ----------------------------------- | -| cursor (optional) | _string_ | Cursor for page of results to fetch | - - - - -200: OK - -```json -{ - "data": [ - { - "subnets": [ - { - "mask": 8388606, - "base": 2080 - } - ], - "owner": "13o9kcgQQTLPGZMej8ya3RjRBWytJnGZkiLyruu4J9dqXgEDyvZ", - "oui": 7, - "nonce": 0, - "block": 762430, - "addresses": [] - }, - { - "subnets": [ - { - "mask": 8388606, - "base": 2072 - } - ], - "owner": "13HWrdkMoooYJEYz8LjKWzfK1oZifCzwxPaCnV9XDJbC5Gso1ic", - "oui": 6, - "nonce": 1, - "block": 762430, - "addresses": [] - }, - { - "subnets": [ - { - "mask": 8388606, - "base": 2064 - } - ], - "owner": "11P9o2DQNqkQ5GU6RTGcdUbRRtjc3syyhN29nFvm4ZfuhMnHj4S", - "oui": 5, - "nonce": 1, - "block": 762430, - "addresses": [] - }, - { - "subnets": [ - { - "mask": 8388606, - "base": 2056 - } - ], - "owner": "11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf", - "oui": 4, - "nonce": 1, - "block": 762430, - "addresses": [] - }, - { - "subnets": [ - { - "mask": 8388606, - "base": 2048 - } - ], - "owner": "14oSuAgRmAFPFPZRY1MUwir5AJSLGkaXHzuSZJ92BuYCfLMN1Et", - "oui": 3, - "nonce": 3, - "block": 762430, - "addresses": [] - }, - { - "subnets": [ - { - "mask": 8388352, - "base": 1024 - } - ], - "owner": "1124CJ9yJaHq4D6ugyPCDnSBzQik61C1BqD9VMh1vsUmjwt16HNB", - "oui": 2, - "nonce": 8, - "block": 762430, - "addresses": [] - }, - { - "subnets": [ - { - "mask": 8388352, - "base": 0 - } - ], - "owner": "13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc", - "oui": 1, - "nonce": 0, - "block": 762430, - "addresses": ["112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE"] - } - ] -} -``` - - - - ---- - -### Get an OUI - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/ouis/:oui -``` - -Returns information for a specific OUI. - - - - -_No Parameters_ - - - - -200: OK - -```json -{ - "data": { - "subnets": [ - { - "mask": 8388352, - "base": 1024 - } - ], - "owner": "1124CJ9yJaHq4D6ugyPCDnSBzQik61C1BqD9VMh1vsUmjwt16HNB", - "oui": 2, - "nonce": 8, - "block": 762436, - "addresses": [] - } -} -``` - - - - ---- - -### Get last assigned OUI - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/ouis/last -``` - -Returns the last assigned OUI transaction. The last assigned OUI can be used to request a new OUI - - - - -_No Parameters_ - - - - -200: OK - -```json -{ - "data": { - "subnets": [ - { - "mask": 8388606, - "base": 2080 - } - ], - "owner": "13o9kcgQQTLPGZMej8ya3RjRBWytJnGZkiLyruu4J9dqXgEDyvZ", - "oui": 7, - "nonce": 0, - "block": 762431, - "addresses": [] - } -} -``` - - - - ---- - -### Get OUI Stats - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/ouis/stats -``` - -Returns stats for the registered OUIs - - - - -_No Parameters_ - - - - -200: OK - -```json -{ - "data": { - "count": 7 - } -} -``` - - - diff --git a/docs/api/blockchain/pending-transactions.mdx b/docs/api/blockchain/pending-transactions.mdx deleted file mode 100644 index 9da87794d..000000000 --- a/docs/api/blockchain/pending-transactions.mdx +++ /dev/null @@ -1,164 +0,0 @@ ---- -id: pending-transactions -title: Pending Transactions -pagination_label: Pending Transactions -sidebar_label: Pending Transactions -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/pending-transactions ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Solana API - -### Pending Transaction Status - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/pending_transactions/:hash -``` - -Fetches the status for a given pending transaction hash. Multiple transactions for the same hash may -be returned. - - - - -_Path Parameters_ - -| param | Type | Note | -| --------------- | -------- | ----------------------------------------- | -| hash (required) | _string_ | Hash of the pending transaction to fetch. | - - - - -200: OK - -A successful pending transaction status request - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -::: - -```json -{ - "data": [ - { - "updated_at": "2022-11-04T14:34:28.254881Z", - "type": "payment_v2", - "txn": { - "type": "payment_v2", - "payments": [ - { - "token_type": "hnt", - "payee": "13PqSH7f5e2sySibkxXiLRvkiYR5cBbCNo5Nf7zZwySzM4n6S5S", - "memo": "AAAAAAAAAAA=", - "max": false, - "amount": 654251727 - } - ], - "payer": "147UgrcgD8qD5JNpfRvz8FBZW86jZsQdsaX2zFV8GP5aUFiiLpQ", - "nonce": 23, - "hash": "p7EypW_zdOyU8pJG1k2NWEUW-10FldH7402bigTqfzw", - "fee": 35000 - }, - "status": "pending", - "hash": "p7EypW_zdOyU8pJG1k2NWEUW-10FldH7402bigTqfzw", - "failed_reason": "", - "created_at": "2022-11-04T14:33:03.060952Z" - } - ] -} -``` - - - - ---- - -### Submit a New Transaction - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -POST https://api.helium.io/v1/pending_transactions/:hash -``` - -New transactions can be submitted to the blockchain by sending a pending transaction.The transaction -has to be constructed using the protobuf form, encoded and then signed. The resulting signed -transaction is then wrapped in a transaction wrapper which must be encoded and then submitted to -this endpoint.If successful, the response will include a transaction hash that can be used to check -for pending transaction status. - - - - -_Headers_ - -| param | Type | Note | -| ----------------------- | -------- | ---------------- | -| Content-Type (optional) | _string_ | application/json | - -_Body Parameters_ - -| param | Type | Note | -| -------------- | -------- | -------------------------------------------------------------------------------------------- | -| txn (required) | _string_ | A base64 encoded transaction. An exmple of the both of a post request:{ "txn": "QoWBCIe..."} | - - - - -200: OK - -A successful pending transaction status request - -```json -{ - "data": { - "hash": "Coy2WqcmCt6k8MgSq3hK0XW1Um5NtwHskoY1zwYADKE" - } -} -``` - - - diff --git a/docs/api/blockchain/rewards.mdx b/docs/api/blockchain/rewards.mdx deleted file mode 100644 index c686e46c1..000000000 --- a/docs/api/blockchain/rewards.mdx +++ /dev/null @@ -1,158 +0,0 @@ ---- -id: rewards -title: Rewards -pagination_label: Rewards -sidebar_label: Rewards -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/rewards ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Oracles API - -### Reward Totals - -:::tip Available on the Oracles API - -The data provided by endpoint is available using the Oracles API and requires parsing S3 data. More -information will be made available in the future. - -::: - -``` -GET https://api.helium.io/v1/rewards/sum -``` - -Returns the total rewards for the whole network in a given timeframe. Timestamps can be given in ISO -8601 format (e.g. `2020-08-27T00:00:00Z`) or in relative time (e.g. `-1 week`, which when url -esacped becomes `-1%20week`). When ommitted the current time is assumed. - -The results can also be bucketed in time by specifying a `bucket` query parameter which buckets -information per bucket in the given timeframe. Data is bucketed by time. Valid bucket values include -`hour`, `day` and `week`). - -For example to get the last 7 days of rewards bucketed by day use the following path/parameters: -`?min_time=-7%20day&bucket=day` - -The block that contains the `max_time` timestamp is **excluded** from the result. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| min_time (required) | _string_ | First time to include rewards for | -| max_time (required) | _string_ | Last time to include rewards for | -| bucket (optional) | _string_ | Bucket specifier | - - - - -200: OK - -Return the last 7 days of rewards bucketed by day - -```json -{ - "meta": { - "min_time": "2021-03-09T14:02:16Z", - "max_time": "2021-03-16T14:02:16Z", - "bucket": "day" - }, - "data": [ - { - "total": 163097.17250743, - "timestamp": "2021-03-15T14:02:16.000000Z", - "sum": 16309717250743, - "stddev": 1979.00681618, - "min": 3472.21917515, - "median": 4016.203702235, - "max": 12284.71884406, - "avg": 4796.975661983235 - }, - { - "total": 168002.27841848, - "timestamp": "2021-03-14T14:02:16.000000Z", - "sum": 16800227841848, - "stddev": 2309.16069573, - "min": 3472.21841404, - "median": 4016.20370501, - "max": 12611.11000226, - "avg": 5090.9781338933335 - }, - { - "total": 133361.07596175, - "timestamp": "2021-03-13T14:02:16.000000Z", - "sum": 13336107596175, - "stddev": 2798.46444455, - "min": 3472.21962795, - "median": 4124.99999633, - "max": 14787.03221898, - "avg": 5129.272152375 - }, - { - "total": 163106.43648989, - "timestamp": "2021-03-12T14:02:16.000000Z", - "sum": 16310643648989, - "stddev": 2546.58274217, - "min": 3472.2198613, - "median": 3907.40369327, - "max": 13590.27500482, - "avg": 4942.619287572425 - }, - { - "total": 172761.52602361, - "timestamp": "2021-03-11T14:02:16.000000Z", - "sum": 17276152602361, - "stddev": 1987.78361329, - "min": 3472.22221761, - "median": 4016.20370451, - "max": 10108.79357198, - "avg": 4798.931278433611 - }, - { - "total": 174583.28615868, - "timestamp": "2021-03-10T14:02:16.000000Z", - "sum": 17458328615868, - "stddev": 1803.57075522, - "min": 3472.22221792, - "median": 3798.61111202, - "max": 12502.31093528, - "avg": 4476.494516889231 - }, - { - "total": 171546.22586829, - "timestamp": "2021-03-09T14:02:16.000000Z", - "sum": 17154622586829, - "stddev": 1240.37282909, - "min": 3472.21796038, - "median": 4070.598475985, - "max": 9129.62498664, - "avg": 4514.374364955 - } - ] -} -``` - - - - ---- diff --git a/docs/api/blockchain/state-channels.mdx b/docs/api/blockchain/state-channels.mdx deleted file mode 100644 index cf0f38c31..000000000 --- a/docs/api/blockchain/state-channels.mdx +++ /dev/null @@ -1,107 +0,0 @@ ---- -id: state-channels -title: State Channels -pagination_label: State Channels -sidebar_label: State Channels -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/state-channels ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Deprecated Endpoints - -### State Channel Closes - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/state_channels -``` - -Use this API to list state channel close transactions. - -This route is `cursor` paginated. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | --------------------------------- | -| cursor (optional) | _string_ | Cursor for page to fetch | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -Return a page of state channel close transactions. - -```json -{ - "data": [ - { - "type": "state_channel_close_v1", - "time": 1627577017, - "state_channel": { - "summaries": [ - { - "owner": "14qHxW3wwEonzJJrVPZ78BXZujPeHvdn2fo4iZ4YQ2kLUwkZXtm", - "num_packets": 16, - "num_dcs": 16, - "location": "8c2baa4e889b5ff", - "client": "112uipUqDVgAzqWdtcRtPQuoeGJFFfwW3oBDXtatvisbbqHWk3RW" - }, - { - "owner": "13mYJikVu11XhX59Zqqk1ToNeWdzq6vReb3A3iSPLruMxuxqRAc", - "num_packets": 124, - "num_dcs": 248, - "location": "8c29b6d8a4dc5ff", - "client": "11fcc2zTmmXgopTNfMmoL3MU8KGfWZJ3NqQRgAZtaey5UBgAk7D" - } - ], - "state": "closed", - "root_hash": "5WgBNc99K2ql6yd300IYdDrQukxOQFSAdWuKP7u8v80", - "owner": "112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE", - "nonce": 21499, - "id": "6_S3g9x7pbAusjYPjV3sdxc9nVrWbFyjtZtcRo4NRpM", - "expire_at_block": 943427 - }, - "height": 943429, - "hash": "HOzKneeR7b18s7t6a8AISFzpUrPRTwACf26Q76kkW3E", - "conflicts_with": null, - "closer": "112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE" - } - ], - "cursor": "eyJ0eXBlcyI6InN0YXRlX2NoYW5uZWxfY2xvc2VfdjEiLCJtaW5fYmxvY2siOjEsImJsb2NrIjo5NDM0MDAsImFuY2hvcl9ibG9jayI6OTQzNDAwfQ" -} -``` - - - - ---- diff --git a/docs/api/blockchain/stats.mdx b/docs/api/blockchain/stats.mdx deleted file mode 100644 index 6b748c10b..000000000 --- a/docs/api/blockchain/stats.mdx +++ /dev/null @@ -1,162 +0,0 @@ ---- -id: stats -title: Stats -pagination_label: Stats -sidebar_label: Stats -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/stats ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - ---- - -## Available on the Solana API - -### Token Supply - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/stats/token_supply -``` - -Returns the circulating token supply in either JSON or raw form. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | --------------------------------------------------------- | -| format (optional) | _string_ | specify `raw` to get a raw number, otherwise returns json | - - - - -200: OK - -RAW form of the result when called with `/v1/stats/token_supply?format=raw` - -```json -49450470.73544278 -``` - - - - ---- - -## Deprecated Endpoints - -### Blockchain Stats - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. - -::: - -``` -GET https://api.helium.io/v1/stats -``` - -Retrieve basic stats for the blockchain such as total token supply, and average block and election -times over a number of intervals. - - - - -_No Parameters_ - - - - -200: OK - -```json -{ - "data": { - "block_times": { - "last_day": { - "avg": 70.45921696574226, - "stddev": 68.83988201467606 - }, - "last_hour": { - "avg": 66.16666666666667, - "stddev": 4.492131485499826 - }, - "last_month": { - "avg": 58.57145439754135, - "stddev": 54.42394685110655 - }, - "last_week": { - "avg": 66.77767965559113, - "stddev": 78.40328359329104 - } - }, - "challenge_counts": { - "active": 3226, - "last_day": 33084 - }, - "counts": { - "validators": 2145, - "ouis": 13, - "hotspots_dataonly": 64, - "blocks": 644074, - "challenges": 14189829, - "cities": 2458, - "consensus_groups": 16884, - "countries": 55, - "hotspots": 14402, - "transactions": 37813658 - }, - "election_times": { - "last_day": { - "avg": 2981.2413793103447, - "stddev": 1693.238289178722 - }, - "last_hour": { - "avg": 1997.0, - "stddev": null - }, - "last_month": { - "avg": 2247.3307291666665, - "stddev": 821.206067231938 - }, - "last_week": { - "avg": 2608.6293103448274, - "stddev": 1048.715520504349 - } - }, - "token_supply": 66042860.58752121 - } -} -``` - - - diff --git a/docs/api/blockchain/transactions.mdx b/docs/api/blockchain/transactions.mdx deleted file mode 100644 index a6c7c0d1a..000000000 --- a/docs/api/blockchain/transactions.mdx +++ /dev/null @@ -1,88 +0,0 @@ ---- -id: transactions -title: Transactions -pagination_label: Transactions -sidebar_label: Transactions -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/transactions ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -## Available on the Solana API - -### Transaction for Hash - -:::info Available on the Solana API - -The data provided by endpoint is available using the Solana API. More information will be made -available in the future. - -::: - -``` -GET https://api.helium.io/v1/transactions/:hash -``` - -Fetch the transaction for a given hash. - - - - -_Path Parameters_ - -| param | Type | Note | -| --------------- | -------- | ------------------------- | -| hash (required) | _string_ | Transaction hash to fetch | - - - - -200: OK - -Transaction successfully retrieved. - -:::note Transaction Units - -Remember that transaction units are in `bones`. Read more -[here](/api/blockchain/introduction/#transaction-units) [DEPRECATED] - -::: - -```json -{ - "data": { - "type": "payment_v2", - "time": 1595980494, - "payments": [ - { - "payee": "13FkKYnwHPoa6F7K23jJ7j2WNg9cMPsznJ7i4c9ysCwLoS8vx3E", - "amount": 100000000 - } - ], - "payer": "14h5MCATzJAB88gGBph8YtPM9539FdyBnMdTt7sYxg4Ts1D1aW3", - "nonce": 6, - "height": 435251, - "hash": "bUc6-LQXdR6zOBaR_8TPWlf3THCpb4wI6WPXJHJfnYw", - "fee": 35000 - } -} -``` - - - diff --git a/docs/api/blockchain/validators.mdx b/docs/api/blockchain/validators.mdx deleted file mode 100644 index 11e379839..000000000 --- a/docs/api/blockchain/validators.mdx +++ /dev/null @@ -1,7771 +0,0 @@ ---- -id: validators -title: Validators -pagination_label: Validators -sidebar_label: Validators -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/blockchain/validators ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Deprecation Incoming - -With the Solana Migration, these API endpoints may no longer be available. - -Please refer to [Oracles](/oracles) and [Oracle Data](/oracles/oracle-data) documentation for more -information on accessing data. - -::: - -:::warning - -These docs reflect the Validator Mainnet API. If you would like to use the Testnet API, please use -the following base url: - -``` -https://testnet-api.helium.wtf/v1/ -``` - -::: - -## Deprecated Endpoints - -### List Validators - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators -``` - -List known validators as registered on the blockchain. The results are paged. If a `cursor` field is -present in the response, more results are available. - - - - -_Query Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ---------------------------- | -| cursor (optional) | _string_ | Cursor for the page to fetch | - - - - -200: OK - -Validators successfully retrieved. - -```json -{ - "data": [ - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/173.234.31.106/tcp/2154"], - "height": 17454 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1angb56sircurmps45PN8S3xkp6UGWBicG4vLuxNdjjWLWKbGiJ", - "name": "soft-aquamarine-bear", - "last_heartbeat": 1, - "block_added": 57693, - "block": 57780, - "address": "1ZzqXn48DByf5RsPujPTt3AcemXKDJNudYnJfCBAkcYBaBxPzEf" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/161.35.239.72/tcp/2154"], - "height": 57620 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1aHjgDtLvURwScQRUhkY7R72Chf6LURa1kPW19orJG1B3Y1W3F6", - "name": "kind-khaki-koala", - "last_heartbeat": 57771, - "block_added": 57621, - "block": 57780, - "address": "1brL1Gop8xjXLg8ouy7mTF6ENerCq2efa8z6xueDGcDAzGMNXX2" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/3.19.229.249/tcp/2154"], - "height": 13236 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bDnpfSfjKuvXExmaUPvrgPGejGYRAnuLmEHpD9jc9tqtCdJo7L", - "name": "clean-sepia-corgi", - "last_heartbeat": 1, - "block_added": 57375, - "block": 57780, - "address": "1YcYePNZgLd5NXgozRepyLkF8RzUQy3VAgaC8QkPVXX3TnbsxHy" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": [ - "/p2p/1YHCeWRvkowVUrAmvTHYPsMu4kLTMa47ZdFfitg7mGwF4vD7nS6/p2p-circuit/p2p/1Z8miaJzGE5xKWVAhgfdsDcazvVsGgvCw4VT4fYT8dD75YU7CcM" - ], - "height": 17454 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1a8jaYof7PzvjcwrGty1EXcimpFuwKahafAsKeVyKN9VGohAHGz", - "name": "lone-cedar-bird", - "last_heartbeat": 1, - "block_added": 57094, - "block": 57780, - "address": "1Z8miaJzGE5xKWVAhgfdsDcazvVsGgvCw4VT4fYT8dD75YU7CcM" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": [ - "/p2p/1Zks5oKPUGMQMrwoxatXhpUb62jkYhpF9BQNGLjTgV3D4Pq5Tjm/p2p-circuit/p2p/1ZJdib3QEzGrbUSjShhM6N9LjsbZQx9aJJeEvrT4YPpa5MVjq2A" - ], - "height": 57693 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bqByKbvSGqvi9cNHj2pVsBKU4ozJfJaormeiuJwPYXZqQUCyh7", - "name": "dazzling-pine-deer", - "last_heartbeat": 57772, - "block_added": 56874, - "block": 57780, - "address": "1ZJdib3QEzGrbUSjShhM6N9LjsbZQx9aJJeEvrT4YPpa5MVjq2A" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/128.199.110.198/tcp/2154"], - "height": 57723 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.0800018310546875, - "penalties": [ - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1aHkk454S483K482HGvCfUdBfAiAXWtkGGZ3BmEQBCqSYJrGCpn", - "name": "original-neon-finch", - "last_heartbeat": 57777, - "block_added": 56344, - "block": 57780, - "address": "1Z6bxAwSTpKUqn1wchPAzf6chV7NaFCRqh9GdHurJGQprd1ZT64" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bd4WfNCQsBU6enYHK4NW5b8M181PgeWhuMWtfV6DiumpYzGopG", - "name": "fit-pear-corgi", - "last_heartbeat": 1, - "block_added": 55676, - "block": 57780, - "address": "1bd4WfNCQsBU6enYHK4NW5b8M181PgeWhuMWtfV6DiumpYzGopG" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/45.63.122.123/tcp/2154"], - "height": 17454 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bpNMsVaK4V9v3f979Wt8MJyrQ1qQrUeGg9nvRvaq7WpiGiFAwg", - "name": "narrow-mercurial-ostrich", - "last_heartbeat": 1, - "block_added": 55676, - "block": 57780, - "address": "1ZxNeN9S5UXP4v84iuLR6jnxv2V5c4aANUPZ7LXFR7Fa1gfN3Hi" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/95.179.229.119/tcp/2154"], - "height": 17454 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1aKoNNY5KrJDxfzW9USERQTjP5L57uq3T55jHcCBCy6RXbcL3Jf", - "name": "big-brunette-wallaby", - "last_heartbeat": 1, - "block_added": 55674, - "block": 57780, - "address": "1Zg7in5DSjgJNw1Y1tTAUkwDvMWZskGZMkK2i8qYqFo5ufQaAuT" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": [], - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bZxXDLbweRyMW43hvmQMcyvsBxA5oucjX9xwfQXDKzUU6yMhWt", - "name": "dapper-blonde-troll", - "last_heartbeat": 1, - "block_added": 55186, - "block": 57780, - "address": "1YPN2hKjbNWxfvCgwAsb4xh2P3afc2LxcaCjM12Ngf9KGzaXE25" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": [ - "/p2p/1YEmVh7eeSXdqzjKMeZUWjZbDmVWVMKVLY7Y4nQheWV5YmU8ie3/p2p-circuit/p2p/1ZvBKi4rbUue3rbbSeGVwRBZobkLRAHGpaiyxuyFEhDSKN2yqN4" - ], - "height": 57701 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 4.4100189208984375, - "penalties": [ - { - "type": "performance", - "height": 57704, - "amount": 0.477996826171875 - }, - { - "type": "performance", - "height": 57684, - "amount": 0.4792022705078125 - }, - { - "type": "performance", - "height": 57738, - "amount": 1.9405670166015625 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - } - ], - "owner": "1bXCpL79ZuEye2bKhcNqZ8yRLPgEtL4bsVUPegwthUAU1eWUVwH", - "name": "brave-hazelnut-dragon", - "last_heartbeat": 57776, - "block_added": 55105, - "block": 57780, - "address": "1ZvBKi4rbUue3rbbSeGVwRBZobkLRAHGpaiyxuyFEhDSKN2yqN4" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/72.75.228.194/tcp/2154"], - "height": 57665 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 56880, - "amount": 1.5211639404296875 - }, - { - "type": "performance", - "height": 56851, - "amount": 1.540802001953125 - }, - { - "type": "performance", - "height": 56868, - "amount": 1.986358642578125 - }, - { - "type": "tenure", - "height": 56851, - "amount": 1 - }, - { - "type": "tenure", - "height": 56868, - "amount": 1 - }, - { - "type": "tenure", - "height": 56880, - "amount": 1 - } - ], - "owner": "1bZYC5HM5z5DSJ6BYCkvZN3WqaBpLoRDjU8aTKdEQ3fqmb21cdh", - "name": "huge-hickory-flamingo", - "last_heartbeat": 57773, - "block_added": 54840, - "block": 57780, - "address": "1Zq7YFrWEihKZPfrMWVE64RWPuuR2K4qg7C6uLcHMMPCrsGMfSa" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/3.141.1.44/tcp/2154"], - "height": 57176 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57061, - "amount": 0 - }, - { - "type": "performance", - "height": 57092, - "amount": 0 - }, - { - "type": "performance", - "height": 57113, - "amount": 7.875885009765625 - }, - { - "type": "tenure", - "height": 57061, - "amount": 1 - }, - { - "type": "tenure", - "height": 57092, - "amount": 1 - }, - { - "type": "tenure", - "height": 57113, - "amount": 1 - } - ], - "owner": "1b5u8WUEZyCduBs7TSaGD86CHGkajLapmafXsQH2sUd25T7CdJj", - "name": "elegant-indigo-orca", - "last_heartbeat": 57770, - "block_added": 54721, - "block": 57780, - "address": "1YbCrM7hQHP6kKVnevibmdtVTf9Q4zosdqw4gsvJcSWgujUZfas" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/18.220.78.219/tcp/2154"], - "height": 57681 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.7920074462890625, - "penalties": [ - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1ac8ohAz1aAzPyj93R18YMdXWovPi3QD7vCVAh1pqjzqY3AAAsH", - "name": "tricky-orange-antelope", - "last_heartbeat": 57775, - "block_added": 54645, - "block": 57780, - "address": "1ZCvokeKQJEpY53aRWXxFRSNwR1D4QHMpULQwctmMfbQkgu8vPs" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": [ - "/p2p/1ZHrstqGvr1yKsEgiKr9LpSMNRNW8TRLC8owivFSEVmrmHqoMuC/p2p-circuit/p2p/1ZxFE2edaTGBbTpbd3a5frT4E4gFDFSfeXSKrsCTLdbxjyx1WVf" - ], - "height": 57427 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57147, - "amount": 0.4907989501953125 - }, - { - "type": "performance", - "height": 57171, - "amount": 0.5872039794921875 - }, - { - "type": "performance", - "height": 57158, - "amount": 0.6887969970703125 - }, - { - "type": "tenure", - "height": 57147, - "amount": 1 - }, - { - "type": "tenure", - "height": 57158, - "amount": 1 - }, - { - "type": "tenure", - "height": 57171, - "amount": 1 - } - ], - "owner": "1atx3iDSFCjUZR4R6CqfSmD38BHM3BwT5hN2uDRQ5Em5RVFvG3y", - "name": "passive-lilac-donkey", - "last_heartbeat": 57772, - "block_added": 54574, - "block": 57780, - "address": "1ZxFE2edaTGBbTpbd3a5frT4E4gFDFSfeXSKrsCTLdbxjyx1WVf" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": [], - "height": 57719 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 6.357635498046875, - "penalties": [ - { - "type": "performance", - "height": 57753, - "amount": 0.59320068359375 - }, - { - "type": "performance", - "height": 57765, - "amount": 4.22259521484375 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - } - ], - "owner": "1bZxXDLbweRyMW43hvmQMcyvsBxA5oucjX9xwfQXDKzUU6yMhWt", - "name": "magic-iris-otter", - "last_heartbeat": 57776, - "block_added": 54546, - "block": 57780, - "address": "1YJB5T4jj1PQtEeuy81DMKYUY1NpUUVDAphjLMM72zMbKFN8Wi4" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.81.253.204/tcp/2154"], - "height": 57696 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 56533, - "amount": 0 - }, - { - "type": "performance", - "height": 56547, - "amount": 0 - }, - { - "type": "performance", - "height": 56559, - "amount": 0.09759521484375 - }, - { - "type": "tenure", - "height": 56533, - "amount": 1 - }, - { - "type": "tenure", - "height": 56547, - "amount": 1 - }, - { - "type": "tenure", - "height": 56559, - "amount": 1 - } - ], - "owner": "1aLVi6Z9qcraQwLAsqdVydCTErZtKyDgUKgcQCJ9JTBbJoxCC77", - "name": "early-glass-rabbit", - "last_heartbeat": 57772, - "block_added": 54152, - "block": 57780, - "address": "1ZNaqFEXa8Uun5A4MbsGrLg7QWVCQn35fBpafxuzE4cK4se5M2Z" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/95.216.206.222/tcp/2154"], - "height": 57733 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.8350067138671875, - "penalties": [ - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "performance", - "height": 57601, - "amount": 0.0948028564453125 - }, - { - "type": "performance", - "height": 57777, - "amount": 0.096405029296875 - }, - { - "type": "performance", - "height": 57585, - "amount": 0.295196533203125 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1bLo6qZh387D9yZppCRLzvdLofyPQ4SFyPM9T8VvSf7XLuSmS62", - "name": "hot-blonde-eagle", - "last_heartbeat": 57752, - "block_added": 53507, - "block": 57780, - "address": "1YjRG26vfH5AuTmNdYpSHy8LoNZmBitWRE2sXCArzWwnCpFLLBc" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.81.143.171/tcp/2154"], - "height": 57570 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.947998046875, - "penalties": [ - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - } - ], - "owner": "1btCJwtoPL52UEDNbwNitqXtDNsD6hf71oqC2byaMY8T6YETBvY", - "name": "feisty-raisin-parrot", - "last_heartbeat": 57774, - "block_added": 53304, - "block": 57780, - "address": "1Z1kvpjykGWjPgvQT7uDRm8oCKuEKGpBs9UPun1UYbdn1bfxumU" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/34.217.83.142/tcp/2154"], - "height": 57751 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 6.2188568115234375, - "penalties": [ - { - "type": "performance", - "height": 57753, - "amount": 0.682403564453125 - }, - { - "type": "performance", - "height": 57516, - "amount": 1.204681396484375 - }, - { - "type": "performance", - "height": 57765, - "amount": 1.2259521484375 - }, - { - "type": "performance", - "height": 57738, - "amount": 2.122161865234375 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - } - ], - "owner": "1aFHALQYwKKofGd84SL2cfxCvMx58TBKpANrAXUyrVtfrEmEMJf", - "name": "proper-wooden-pelican", - "last_heartbeat": 57776, - "block_added": 53218, - "block": 57780, - "address": "1ZUi3iMFQZNbECoULtKsfnhQcRwc4UaGhcXM8wB9aQkwLNJfp6D" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "offline", - "listen_addrs": [ - "/p2p/1ZQ9cc2cTJ5RB2DcxWf4EBZebqsSWcPqb1fxKBa8357nvNZTgE7/p2p-circuit/p2p/1ZBJs1N8A7fJQcs8e2NoZBtWjdqPwPChvohUFFvPFeBszeovCeu" - ], - "height": 55498 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 55009, - "amount": 0 - }, - { - "type": "performance", - "height": 55156, - "amount": 0 - }, - { - "type": "performance", - "height": 55232, - "amount": 0 - }, - { - "type": "performance", - "height": 55216, - "amount": 0.1967926025390625 - }, - { - "type": "performance", - "height": 55192, - "amount": 1.587432861328125 - }, - { - "type": "tenure", - "height": 55009, - "amount": 1 - }, - { - "type": "tenure", - "height": 55156, - "amount": 1 - }, - { - "type": "tenure", - "height": 55192, - "amount": 1 - }, - { - "type": "tenure", - "height": 55216, - "amount": 1 - }, - { - "type": "tenure", - "height": 55232, - "amount": 1 - } - ], - "owner": "1aPwSMjyDT7BEzfp2yAZAttsNEZ5e2n6piB5HmrNNwRpYCQEPpL", - "name": "sweet-silver-python", - "last_heartbeat": 55536, - "block_added": 52892, - "block": 57780, - "address": "1ZBJs1N8A7fJQcs8e2NoZBtWjdqPwPChvohUFFvPFeBszeovCeu" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/34.214.145.125/tcp/2154"], - "height": 57692 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 56704, - "amount": 0 - }, - { - "type": "performance", - "height": 56716, - "amount": 0 - }, - { - "type": "performance", - "height": 56732, - "amount": 0 - }, - { - "type": "performance", - "height": 56751, - "amount": 0 - }, - { - "type": "tenure", - "height": 56704, - "amount": 1 - }, - { - "type": "tenure", - "height": 56716, - "amount": 1 - }, - { - "type": "tenure", - "height": 56732, - "amount": 1 - }, - { - "type": "tenure", - "height": 56751, - "amount": 1 - } - ], - "owner": "1b4WiA7V1qnmHkGGkNbUKNz1npbJS3iD87xak1mJwPmmBPmqTci", - "name": "energetic-blush-albatross", - "last_heartbeat": 57775, - "block_added": 52705, - "block": 57780, - "address": "1YGNwxjixoC51DHL8btRVKN5Tbw2ouF4xPqQxwQeg5QePQcACJR" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.208.34.210/tcp/2154"], - "height": 57662 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.089141845703125, - "penalties": [ - { - "type": "performance", - "height": 57426, - "amount": 0.0955963134765625 - }, - { - "type": "performance", - "height": 57645, - "amount": 0.096405029296875 - }, - { - "type": "performance", - "height": 57412, - "amount": 0.2971954345703125 - }, - { - "type": "performance", - "height": 57398, - "amount": 0.3907928466796875 - }, - { - "type": "performance", - "height": 57633, - "amount": 0.39520263671875 - }, - { - "type": "tenure", - "height": 57398, - "amount": 1 - }, - { - "type": "tenure", - "height": 57412, - "amount": 1 - }, - { - "type": "tenure", - "height": 57426, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1b1VsaMgUnbxuJ9kjXAs8E24pB7m65n59nSAEnMC879hBb2Abgs", - "name": "colossal-carbon-bat", - "last_heartbeat": 57776, - "block_added": 52678, - "block": 57780, - "address": "1YWQKAoUjZgG2mEMLbgaaN5v8ymFjZkubW9howLpMjmWLwe9rmz" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.29/tcp/2154"], - "height": 57573 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.6880035400390625, - "penalties": [ - { - "type": "performance", - "height": 57516, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "special-cloth-griffin", - "last_heartbeat": 57772, - "block_added": 52555, - "block": 57780, - "address": "1YcVG1K9SYo37KnpJYfVu1Py8nUvp77vruK4zMFW5jtP5N9yKMW" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.28/tcp/2154"], - "height": 57739 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 3.496002197265625, - "penalties": [ - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57665, - "amount": 0 - }, - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "great-laurel-crocodile", - "last_heartbeat": 57771, - "block_added": 52554, - "block": 57780, - "address": "1YkbPxnYTyTGBVxtmCc2on3Tqgbtm85TqJQsfBN6uDXgVeejuuG" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.27/tcp/2154"], - "height": 57740 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.264007568359375, - "penalties": [ - { - "type": "performance", - "height": 57398, - "amount": 0 - }, - { - "type": "performance", - "height": 57412, - "amount": 0 - }, - { - "type": "performance", - "height": 57426, - "amount": 0 - }, - { - "type": "performance", - "height": 57441, - "amount": 0 - }, - { - "type": "performance", - "height": 57455, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "tenure", - "height": 57398, - "amount": 1 - }, - { - "type": "tenure", - "height": 57412, - "amount": 1 - }, - { - "type": "tenure", - "height": 57426, - "amount": 1 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57455, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "early-grey-deer", - "last_heartbeat": 57775, - "block_added": 52552, - "block": 57780, - "address": "1ZPGU6W5NDFQEhn9v32PfBZ7YvnfmoRyMJfbrCTrqBzdWQi6BGu" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/143.198.104.240/tcp/2154", "/ip4/51.222.222.26/tcp/2154"], - "height": 57723 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.4239959716796875, - "penalties": [ - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57665, - "amount": 0 - }, - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "performance", - "height": 57704, - "amount": 0 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "brilliant-menthol-cobra", - "last_heartbeat": 57771, - "block_added": 52548, - "block": 57780, - "address": "1ZMyArznjcAGq6H5ax3oEoyiNSf41PJLosUHKg5sfBfxuExqDKD" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/18.216.140.136/tcp/2154"], - "height": 57630 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.944000244140625, - "penalties": [ - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1a5oTkG3cv77muh1wg76pMBajxh3RoR1zz8ZqP8ijeEGyQmcFft", - "name": "thankful-ocean-toad", - "last_heartbeat": 57773, - "block_added": 52271, - "block": 57780, - "address": "1YfaZAYDP2B3PWSun6J9hqPmd7XSxQ1N2xNc2DdxLVnuh8iF3G2" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bKCma9WJvRLNkEQQrbXXbnybGVx9DWyqrLDVhpT3jM7LW5xLY4", - "name": "mini-arctic-weasel", - "last_heartbeat": 1, - "block_added": 52189, - "block": 57780, - "address": "1ZYewkJ7oFBqiej48soq9WXNd4En4h32zKFFPnxy9kBsi46Y4H3" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/18.222.81.91/tcp/2154"], - "height": 57692 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.272003173828125, - "penalties": [ - { - "type": "performance", - "height": 57516, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - } - ], - "owner": "1bEFB6JcJ7onc7YVEAMSQMThWT9SCN62AsonJaKZY5t7LqXsU9Z", - "name": "perfect-smoke-locust", - "last_heartbeat": 57770, - "block_added": 52130, - "block": 57780, - "address": "1ZUQYRPmzRDocw2bJwG9DtgQZbXw99rNYLdDpjmD7aJ3SBJGBvz" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": [ - "/p2p/1YjRG26vfH5AuTmNdYpSHy8LoNZmBitWRE2sXCArzWwnCpFLLBc/p2p-circuit/p2p/1YYxaV7Fc39Pzz8WXHo1zK7kvAEPivJn2JEfLQoMbigrGSLNdzQ" - ], - "height": 57555 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.9040069580078125, - "penalties": [ - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1avB3L1a7B61nN8M9P8y53knzTKRMfTh453n4XQc4bckGrZFy6z", - "name": "creamy-cider-chimpanzee", - "last_heartbeat": 57778, - "block_added": 52100, - "block": 57780, - "address": "1YYxaV7Fc39Pzz8WXHo1zK7kvAEPivJn2JEfLQoMbigrGSLNdzQ" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/52.40.248.123/tcp/2154"], - "height": 57670 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 4.1024017333984375, - "penalties": [ - { - "type": "performance", - "height": 57573, - "amount": 0.585601806640625 - }, - { - "type": "performance", - "height": 57559, - "amount": 1.1022491455078125 - }, - { - "type": "performance", - "height": 57619, - "amount": 1.4909210205078125 - }, - { - "type": "performance", - "height": 57585, - "amount": 1.5559539794921875 - }, - { - "type": "performance", - "height": 57601, - "amount": 1.6009979248046875 - }, - { - "type": "performance", - "height": 57633, - "amount": 2.3933258056640625 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - } - ], - "owner": "1aV7KAzcWpTy1YLmGgua14TwhjvXZBY8PYSh9SBqBeLHt8VrdJN", - "name": "quiet-red-dragon", - "last_heartbeat": 57778, - "block_added": 51795, - "block": 57780, - "address": "1Y7xaVqrR8Ci84fh1PmV7NYDWo4d1v9n8JCmCWW3D7i9ZXQCVdb" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/18.232.161.36/tcp/2154"], - "height": 17454 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 3.9394989013671875, - "penalties": [ - { - "type": "performance", - "height": 57265, - "amount": 0 - }, - { - "type": "performance", - "height": 57280, - "amount": 0 - }, - { - "type": "performance", - "height": 57321, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57346, - "amount": 0 - }, - { - "type": "performance", - "height": 57360, - "amount": 0 - }, - { - "type": "performance", - "height": 57384, - "amount": 0 - }, - { - "type": "performance", - "height": 57398, - "amount": 0 - }, - { - "type": "performance", - "height": 57305, - "amount": 0.097198486328125 - }, - { - "type": "tenure", - "height": 57265, - "amount": 1 - }, - { - "type": "tenure", - "height": 57280, - "amount": 1 - }, - { - "type": "tenure", - "height": 57305, - "amount": 1 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57346, - "amount": 1 - }, - { - "type": "tenure", - "height": 57360, - "amount": 1 - }, - { - "type": "tenure", - "height": 57384, - "amount": 1 - }, - { - "type": "tenure", - "height": 57398, - "amount": 1 - } - ], - "owner": "1aYcwS9EvtbiNkrjQWTqBo5bk8wAmvWTAcRyVtY6dSVqc1weYHR", - "name": "damp-beige-bison", - "last_heartbeat": 57472, - "block_added": 51758, - "block": 57780, - "address": "1ZyLR6PuSW1bBCRPskZb8pbQpyfDahED6A9ikbmB25DNhAUoi4E" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.81.35.101/tcp/2154"], - "height": 57704 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57171, - "amount": 0 - }, - { - "type": "performance", - "height": 57199, - "amount": 0 - }, - { - "type": "performance", - "height": 57185, - "amount": 0.1952056884765625 - }, - { - "type": "performance", - "height": 57225, - "amount": 0.3907928466796875 - }, - { - "type": "performance", - "height": 56981, - "amount": 0.3936004638671875 - }, - { - "type": "performance", - "height": 57213, - "amount": 0.41107177734375 - }, - { - "type": "performance", - "height": 56998, - "amount": 0.489593505859375 - }, - { - "type": "tenure", - "height": 56981, - "amount": 1 - }, - { - "type": "tenure", - "height": 56998, - "amount": 1 - }, - { - "type": "tenure", - "height": 57171, - "amount": 1 - }, - { - "type": "tenure", - "height": 57185, - "amount": 1 - }, - { - "type": "tenure", - "height": 57199, - "amount": 1 - }, - { - "type": "tenure", - "height": 57213, - "amount": 1 - }, - { - "type": "tenure", - "height": 57225, - "amount": 1 - } - ], - "owner": "1aPBTQKmPv4fZpZeewyo2K22iJ6PfrnVDhjavLNx72SFzx6kn2K", - "name": "zealous-pastel-gibbon", - "last_heartbeat": 57776, - "block_added": 51619, - "block": 57780, - "address": "1ZssqG34DZZCLqBx1XhyRv8LhSTjj9szR5dRUrbfYsj3TTWefA4" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": [ - "/p2p/1ZfBoM7AVCkWbakXegpYH7MpFtdnANLbjG3LaHyNUWTsdJXwMTi/p2p-circuit/p2p/1ZvUXiiiJDEKp3fsECSuBQhdVWPcMNsdG8fjAcs6bhPWEyeSFUR" - ], - "height": 57634 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.272003173828125, - "penalties": [ - { - "type": "performance", - "height": 57321, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57516, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - } - ], - "owner": "1a4kNGHFHHPRgSzcEUKrXrqni7UnDdFqFK5SQtYYa6RgBUjaQSL", - "name": "square-scarlet-caribou", - "last_heartbeat": 57770, - "block_added": 51273, - "block": 57780, - "address": "1ZvUXiiiJDEKp3fsECSuBQhdVWPcMNsdG8fjAcs6bhPWEyeSFUR" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.7519989013671875, - "penalties": [ - { - "type": "dkg", - "height": 51817, - "amount": 1 - }, - { - "type": "dkg", - "height": 51851, - "amount": 1 - } - ], - "owner": "1bd4CVJTR9Fj2VngDKZ2uFqFCasYHfWShBhGFVZshkN9S5rkJRB", - "name": "sparkly-dijon-sloth", - "last_heartbeat": 51863, - "block_added": 51143, - "block": 57780, - "address": "1YeF6utcT8EuYcuGB2Y9W5egz8UcchSVrRmb6xgjsxmTK5dMoUh" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.25/tcp/2154"], - "height": 57534 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.7239990234375, - "penalties": [ - { - "type": "performance", - "height": 57738, - "amount": 0 - }, - { - "type": "performance", - "height": 57753, - "amount": 0 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "loud-vinyl-grasshopper", - "last_heartbeat": 57778, - "block_added": 50702, - "block": 57780, - "address": "1Z2aacQ4cAjZHPHtLwn56gL4TR4UvFAkR2x4J9a3dyFjfmE4267" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/143.198.104.240/tcp/2154", "/ip4/51.222.222.24/tcp/2154"], - "height": 57694 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 3.503997802734375, - "penalties": [ - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57665, - "amount": 0 - }, - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "performance", - "height": 57704, - "amount": 0 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "overt-licorice-goldfish", - "last_heartbeat": 57773, - "block_added": 50699, - "block": 57780, - "address": "1YxuHDUJCgqCJ9UgK8hyGhS2WDLPZKzFNjiQnDoiaryvT9JQNuH" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": [ - "/ip4/51.222.222.23/tcp/2154", - "/p2p/1Zpy7FoMr77QL2ussk2VfkvN6TicdvpPwAeWyfDZXyYDcxpDMkZ/p2p-circuit/p2p/1YEPkpDTqD1fFf6N61PBLQnwTQiMjUwwxHET2GDrx1giXzji24C" - ], - "height": 57732 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.4239959716796875, - "penalties": [ - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57665, - "amount": 0 - }, - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "performance", - "height": 57704, - "amount": 0 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "restless-metal-unicorn", - "last_heartbeat": 57771, - "block_added": 50697, - "block": 57780, - "address": "1YEPkpDTqD1fFf6N61PBLQnwTQiMjUwwxHET2GDrx1giXzji24C" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.22/tcp/2154"], - "height": 57736 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57412, - "amount": 0 - }, - { - "type": "performance", - "height": 57426, - "amount": 0 - }, - { - "type": "performance", - "height": 57441, - "amount": 0 - }, - { - "type": "performance", - "height": 57455, - "amount": 0 - }, - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "tenure", - "height": 57412, - "amount": 1 - }, - { - "type": "tenure", - "height": 57426, - "amount": 1 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57455, - "amount": 1 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "small-frost-locust", - "last_heartbeat": 57777, - "block_added": 50695, - "block": 57780, - "address": "1ZLZCVsNXfnH8KPD5hjYshSmWDiWw2imVFbq8rhnUKHpgL3LYWh" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.21/tcp/2154"], - "height": 57671 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 5.011993408203125, - "penalties": [ - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "performance", - "height": 57704, - "amount": 0 - }, - { - "type": "performance", - "height": 57738, - "amount": 0 - }, - { - "type": "performance", - "height": 57753, - "amount": 0 - }, - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "sweet-bubblegum-peacock", - "last_heartbeat": 57773, - "block_added": 50694, - "block": 57780, - "address": "1YNrqPWwBzFDFZrGdnTk7pnkQPMLXc51jJ1WCjuqNozukpUqv7e" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.20/tcp/2154"], - "height": 57589 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57225, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57346, - "amount": 0 - }, - { - "type": "performance", - "height": 57360, - "amount": 0 - }, - { - "type": "performance", - "height": 57239, - "amount": 0.09759521484375 - }, - { - "type": "tenure", - "height": 57225, - "amount": 1 - }, - { - "type": "tenure", - "height": 57239, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57346, - "amount": 1 - }, - { - "type": "tenure", - "height": 57360, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "hollow-lemonade-aardvark", - "last_heartbeat": 57769, - "block_added": 50673, - "block": 57780, - "address": "1ZJyb9E4AC9uvyrYU1692ahwZzpMhdcrnrftdgx7Cz9xMXvznHi" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.19/tcp/2154"], - "height": 57709 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57199, - "amount": 0 - }, - { - "type": "performance", - "height": 57213, - "amount": 0 - }, - { - "type": "performance", - "height": 57185, - "amount": 0.0995941162109375 - }, - { - "type": "tenure", - "height": 57185, - "amount": 1 - }, - { - "type": "tenure", - "height": 57199, - "amount": 1 - }, - { - "type": "tenure", - "height": 57213, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "calm-cinnamon-falcon", - "last_heartbeat": 57770, - "block_added": 50644, - "block": 57780, - "address": "1ZCGDMuXAxG9LnT96p4SyvS9HMEua263bx2wg8gJ1xCWsJVQ43K" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.18/tcp/2154"], - "height": 57600 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57147, - "amount": 0 - }, - { - "type": "performance", - "height": 57158, - "amount": 0 - }, - { - "type": "performance", - "height": 57171, - "amount": 0 - }, - { - "type": "performance", - "height": 57199, - "amount": 0 - }, - { - "type": "performance", - "height": 57213, - "amount": 0 - }, - { - "type": "performance", - "height": 57185, - "amount": 0.0995941162109375 - }, - { - "type": "tenure", - "height": 57147, - "amount": 1 - }, - { - "type": "tenure", - "height": 57158, - "amount": 1 - }, - { - "type": "tenure", - "height": 57171, - "amount": 1 - }, - { - "type": "tenure", - "height": 57185, - "amount": 1 - }, - { - "type": "tenure", - "height": 57199, - "amount": 1 - }, - { - "type": "tenure", - "height": 57213, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "silly-lavender-cod", - "last_heartbeat": 57769, - "block_added": 50639, - "block": 57780, - "address": "1Za9xHS9uLiifxA277kHR6VzzRp28uFeacPhyFLNnxbuW8WTBuF" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.17/tcp/2154"], - "height": 57692 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.99200439453125, - "penalties": [ - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "shallow-butter-shark", - "last_heartbeat": 57777, - "block_added": 50636, - "block": 57780, - "address": "1Z9zkkswtjmrHsu7XK21rdxprwhNmhqpX4NirghEynauaohVjYu" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/51.222.222.16/tcp/2154"], - "height": 57662 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.3520050048828125, - "penalties": [ - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - } - ], - "owner": "1aTZ28SE9BHkiLehdxaDGLVE6tyEEDvtj8YHjvYY6wmX1ANB25H", - "name": "amusing-sepia-caterpillar", - "last_heartbeat": 57771, - "block_added": 50614, - "block": 57780, - "address": "1Y8Rr9WaEcQBWn7Jh7QnXrctZ99a15PQEpoLQHCNTeZcDY5ziA7" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/27.33.106.122/tcp/2154"], - "height": 57725 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57199, - "amount": 0 - }, - { - "type": "performance", - "height": 57213, - "amount": 0 - }, - { - "type": "performance", - "height": 57225, - "amount": 0 - }, - { - "type": "performance", - "height": 57254, - "amount": 0 - }, - { - "type": "performance", - "height": 57265, - "amount": 0 - }, - { - "type": "performance", - "height": 57280, - "amount": 0 - }, - { - "type": "performance", - "height": 57321, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57305, - "amount": 0.097198486328125 - }, - { - "type": "performance", - "height": 57239, - "amount": 2.3732757568359375 - }, - { - "type": "tenure", - "height": 57199, - "amount": 1 - }, - { - "type": "tenure", - "height": 57213, - "amount": 1 - }, - { - "type": "tenure", - "height": 57225, - "amount": 1 - }, - { - "type": "tenure", - "height": 57239, - "amount": 1 - }, - { - "type": "tenure", - "height": 57254, - "amount": 1 - }, - { - "type": "tenure", - "height": 57265, - "amount": 1 - }, - { - "type": "tenure", - "height": 57280, - "amount": 1 - }, - { - "type": "tenure", - "height": 57305, - "amount": 1 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - } - ], - "owner": "1abzm1EJjtzKmh5r37nczeTWbKxmP2MLQa11sz5xwGF8YFozCLW", - "name": "sneaky-marigold-cow", - "last_heartbeat": 57769, - "block_added": 50328, - "block": 57780, - "address": "1YWPtU4sFrGVx7V3Br5AM44G16YvRm2cLofSpZmhYJxysiXxhH6" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/157.230.179.75/tcp/2154", "/ip4/3.14.135.248/tcp/2154"], - "height": 57686 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57254, - "amount": 0 - }, - { - "type": "performance", - "height": 57265, - "amount": 0 - }, - { - "type": "performance", - "height": 57280, - "amount": 0 - }, - { - "type": "performance", - "height": 57321, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57305, - "amount": 0.097198486328125 - }, - { - "type": "performance", - "height": 57239, - "amount": 0.09759521484375 - }, - { - "type": "tenure", - "height": 57239, - "amount": 1 - }, - { - "type": "tenure", - "height": 57254, - "amount": 1 - }, - { - "type": "tenure", - "height": 57265, - "amount": 1 - }, - { - "type": "tenure", - "height": 57280, - "amount": 1 - }, - { - "type": "tenure", - "height": 57305, - "amount": 1 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - } - ], - "owner": "1aX7Ns19teoSbHPZCjwvtxwmJSRn5hQgZZsrYkoGixwKWfr5F53", - "name": "docile-sangria-kookaburra", - "last_heartbeat": 57772, - "block_added": 49836, - "block": 57780, - "address": "1ZvYhyswiiGjQz8y7uxdi98LA9MoM1yauQAHhdX8oUH2FJWpX1T" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 51102, - "amount": 0.0959930419921875 - }, - { - "type": "performance", - "height": 51077, - "amount": 0.100006103515625 - }, - { - "type": "performance", - "height": 51089, - "amount": 0.2960052490234375 - }, - { - "type": "performance", - "height": 51248, - "amount": 0.419677734375 - }, - { - "type": "performance", - "height": 51271, - "amount": 0.4904022216796875 - }, - { - "type": "performance", - "height": 51260, - "amount": 0.6880035400390625 - }, - { - "type": "tenure", - "height": 51077, - "amount": 1 - }, - { - "type": "tenure", - "height": 51089, - "amount": 1 - }, - { - "type": "tenure", - "height": 51102, - "amount": 1 - }, - { - "type": "tenure", - "height": 51248, - "amount": 1 - }, - { - "type": "tenure", - "height": 51260, - "amount": 1 - }, - { - "type": "tenure", - "height": 51271, - "amount": 1 - } - ], - "owner": "1aTrjfqNa7q8T18VdTwLSJEG5a9jMmfkq1TZZQk9yMo3hQqGjMp", - "name": "bright-purple-hornet", - "last_heartbeat": 51622, - "block_added": 49718, - "block": 57780, - "address": "1Z5mHkZuDUEijpMZsTS1Y3kkbTjKoPEGAhDY9mXXvPr2gyH8irP" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/135.148.26.233/tcp/2154"], - "height": 57684 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.011993408203125, - "penalties": [ - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - } - ], - "owner": "1anVbFBA4Zqgei1Vs4uqMa8xFkiuosbVB4X4WykVfR9187YF3Gh", - "name": "real-orchid-trout", - "last_heartbeat": 57775, - "block_added": 49631, - "block": 57780, - "address": "1YaLyfKpqoUUaJMt6xHe1f3hzy8uY4nSHXTcQX2NbJoADgKjhaT" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": [ - "/p2p/1a1oxkzJWZSzUnu3y6gjfcNnp9a7VvZtoeM8hM9SPEZCRcmMrpD/p2p-circuit/p2p/1Z7LbpCvefzo58nxDVe6MNPLJ5RgAdTkQJr54ZZr8UQLgtvyRrv" - ], - "height": 57498 - }, - "stake_status": "unstaked", - "stake": 0, - "penalty": 3.5028839111328125, - "penalties": [ - { - "type": "performance", - "height": 51102, - "amount": 0 - }, - { - "type": "performance", - "height": 51120, - "amount": 0 - }, - { - "type": "performance", - "height": 51131, - "amount": 0 - }, - { - "type": "performance", - "height": 51156, - "amount": 0 - }, - { - "type": "performance", - "height": 51191, - "amount": 0 - }, - { - "type": "performance", - "height": 51143, - "amount": 0.096405029296875 - }, - { - "type": "performance", - "height": 51168, - "amount": 0.09759521484375 - }, - { - "type": "tenure", - "height": 51102, - "amount": 1 - }, - { - "type": "tenure", - "height": 51120, - "amount": 1 - }, - { - "type": "tenure", - "height": 51131, - "amount": 1 - }, - { - "type": "tenure", - "height": 51143, - "amount": 1 - }, - { - "type": "tenure", - "height": 51156, - "amount": 1 - }, - { - "type": "tenure", - "height": 51168, - "amount": 1 - }, - { - "type": "tenure", - "height": 51191, - "amount": 1 - } - ], - "owner": "1a4kNGHFHHPRgSzcEUKrXrqni7UnDdFqFK5SQtYYa6RgBUjaQSL", - "name": "real-marmalade-millipede", - "last_heartbeat": 51260, - "block_added": 49427, - "block": 57780, - "address": "1Z7LbpCvefzo58nxDVe6MNPLJ5RgAdTkQJr54ZZr8UQLgtvyRrv" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.216.185.4/tcp/2154"], - "height": 57725 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.9297027587890625, - "penalties": [ - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0.298797607421875 - }, - { - "type": "performance", - "height": 57573, - "amount": 0.3907928466796875 - }, - { - "type": "performance", - "height": 57545, - "amount": 0.39520263671875 - }, - { - "type": "performance", - "height": 57559, - "amount": 0.39520263671875 - }, - { - "type": "performance", - "height": 57619, - "amount": 0.3975982666015625 - }, - { - "type": "performance", - "height": 57601, - "amount": 0.485992431640625 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - } - ], - "owner": "1avoE626bzb1QdYco4yhhe3ahe8iYxp2PKkPPtfZmwNG4jaJ4vG", - "name": "quaint-grape-condor", - "last_heartbeat": 57770, - "block_added": 48996, - "block": 57780, - "address": "1YDxa3tQ82QHuHMjxqL7K8iUYMzRAniPsJA8nr4japhqw79LCeK" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/54.216.224.10/tcp/2154"], - "height": 54927 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.2440032958984375, - "penalties": [ - { - "type": "performance", - "height": 54806, - "amount": 0 - }, - { - "type": "performance", - "height": 54821, - "amount": 0 - }, - { - "type": "performance", - "height": 54838, - "amount": 0 - }, - { - "type": "tenure", - "height": 54806, - "amount": 1 - }, - { - "type": "tenure", - "height": 54821, - "amount": 1 - }, - { - "type": "tenure", - "height": 54838, - "amount": 1 - } - ], - "owner": "1a8jaYof7PzvjcwrGty1EXcimpFuwKahafAsKeVyKN9VGohAHGz", - "name": "rural-honeysuckle-armadillo", - "last_heartbeat": 54965, - "block_added": 48979, - "block": 57780, - "address": "1YW65RUBQHkE43N1gp4ps9msUTqKaBqaWsaRPbKUreWsDUw8WXx" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/107.23.177.78/tcp/2154"], - "height": 57692 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 4.38800048828125, - "penalties": [ - { - "type": "performance", - "height": 57704, - "amount": 0 - }, - { - "type": "performance", - "height": 57738, - "amount": 0 - }, - { - "type": "performance", - "height": 57753, - "amount": 0 - }, - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1aPexPoA1CpezaSHPjY2Lz2c15MzvQmP2M7RczExHmonQnRkBC3", - "name": "cheery-saffron-fish", - "last_heartbeat": 57772, - "block_added": 48739, - "block": 57780, - "address": "1ZLQpfQVoz7iGAByqENCzLKm8VNLxx8YrKQ1CLT6n5PPk2ChTJm" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/65.21.73.155/tcp/2154"], - "height": 57699 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57321, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57346, - "amount": 0 - }, - { - "type": "performance", - "height": 57360, - "amount": 0 - }, - { - "type": "performance", - "height": 57384, - "amount": 0 - }, - { - "type": "performance", - "height": 57398, - "amount": 0 - }, - { - "type": "performance", - "height": 57412, - "amount": 0 - }, - { - "type": "performance", - "height": 57426, - "amount": 0 - }, - { - "type": "performance", - "height": 57441, - "amount": 0 - }, - { - "type": "performance", - "height": 57455, - "amount": 0 - }, - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57305, - "amount": 0.097198486328125 - }, - { - "type": "tenure", - "height": 57305, - "amount": 1 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57346, - "amount": 1 - }, - { - "type": "tenure", - "height": 57360, - "amount": 1 - }, - { - "type": "tenure", - "height": 57384, - "amount": 1 - }, - { - "type": "tenure", - "height": 57398, - "amount": 1 - }, - { - "type": "tenure", - "height": 57412, - "amount": 1 - }, - { - "type": "tenure", - "height": 57426, - "amount": 1 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57455, - "amount": 1 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - } - ], - "owner": "1ajWa9pdk12GqwkgeYEmAvYu1BsWSJzkhv151Ze2n5pruuKwijv", - "name": "festive-mint-osprey", - "last_heartbeat": 57772, - "block_added": 48003, - "block": 57780, - "address": "1YQTkckbXNZCvsXjGoRt9Q1KT5LU4KxqJ5AqbedPkQz16GsiFNv" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/157.90.182.223/tcp/2154"], - "height": 57705 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.3679962158203125, - "penalties": [ - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1ajWa9pdk12GqwkgeYEmAvYu1BsWSJzkhv151Ze2n5pruuKwijv", - "name": "jolly-grape-cormorant", - "last_heartbeat": 57771, - "block_added": 48003, - "block": 57780, - "address": "1ZV83cUCR5Sn46XJx4EMCFi7v2KiK4jutH4GQgsPfw5NWqVMcoQ" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/157.90.182.100/tcp/2154"], - "height": 57668 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57441, - "amount": 0 - }, - { - "type": "performance", - "height": 57455, - "amount": 0 - }, - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57516, - "amount": 0 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57455, - "amount": 1 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - } - ], - "owner": "1ajWa9pdk12GqwkgeYEmAvYu1BsWSJzkhv151Ze2n5pruuKwijv", - "name": "silly-spruce-tuna", - "last_heartbeat": 57769, - "block_added": 48003, - "block": 57780, - "address": "1ZVM5goX3XWjahieRP2nqU4zKwcgtVesjUZhRSsba1KksmuHBbb" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/135.181.178.105/tcp/2154", "/ip4/143.198.104.240/tcp/2154"], - "height": 57668 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57455, - "amount": 0 - }, - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57441, - "amount": 0.0951995849609375 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57455, - "amount": 1 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - } - ], - "owner": "1ajWa9pdk12GqwkgeYEmAvYu1BsWSJzkhv151Ze2n5pruuKwijv", - "name": "tall-raspberry-reindeer", - "last_heartbeat": 57769, - "block_added": 48000, - "block": 57780, - "address": "1ZbvcJb8r6knjAuwoPS5KtuWDSj2peqLdLqYh48yosQbbpRjJRR" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.208.167.101/tcp/2154"], - "height": 57268 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57346, - "amount": 0.3975982666015625 - }, - { - "type": "performance", - "height": 57321, - "amount": 0.5915985107421875 - }, - { - "type": "performance", - "height": 57360, - "amount": 0.823883056640625 - }, - { - "type": "performance", - "height": 57334, - "amount": 1.2197113037109375 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57346, - "amount": 1 - }, - { - "type": "tenure", - "height": 57360, - "amount": 1 - } - ], - "owner": "1aJnWbphJGN9oQt9UCkdN9NxemuoRAz2nD4saSZaTotsttaF3Jf", - "name": "magnificent-fuzzy-haddock", - "last_heartbeat": 57773, - "block_added": 47982, - "block": 57780, - "address": "1ZZZ6jstSLCvmut5SVy2sCbDGeFKX6bdYJYsG1qQihjRcUXH8yT" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/79.209.216.136/tcp/2154"], - "height": 57723 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 4.3679962158203125, - "penalties": [ - { - "type": "performance", - "height": 57704, - "amount": 0 - }, - { - "type": "performance", - "height": 57738, - "amount": 0 - }, - { - "type": "performance", - "height": 57753, - "amount": 0 - }, - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1bJs4KSftnw2VhoZkxiSSovsoWjGDWjrmBrREePg5MHfGnFk655", - "name": "petite-blue-beetle", - "last_heartbeat": 57776, - "block_added": 47864, - "block": 57780, - "address": "1YJRWb3x14gz5C33Jp3VuXrnEMxgca48vv7ART5iMBcHnGs4grL" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.208.251.218/tcp/2154"], - "height": 57553 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57147, - "amount": 0 - }, - { - "type": "performance", - "height": 57346, - "amount": 0.096405029296875 - }, - { - "type": "performance", - "height": 57334, - "amount": 0.19720458984375 - }, - { - "type": "performance", - "height": 57131, - "amount": 0.2855987548828125 - }, - { - "type": "performance", - "height": 57113, - "amount": 0.7803955078125 - }, - { - "type": "tenure", - "height": 57113, - "amount": 1 - }, - { - "type": "tenure", - "height": 57131, - "amount": 1 - }, - { - "type": "tenure", - "height": 57147, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57346, - "amount": 1 - } - ], - "owner": "1aJnWbphJGN9oQt9UCkdN9NxemuoRAz2nD4saSZaTotsttaF3Jf", - "name": "passive-sepia-sparrow", - "last_heartbeat": 57771, - "block_added": 47800, - "block": 57780, - "address": "1ZHoSRYx5b8djJNQDVxC3NAJMqvpojRM3nkqXFQ6rLDNNzTmwro" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": [ - "/ip4/97.118.156.174/tcp/2154", - "/p2p/1YMCJx48nwiEWFsDnApaz1zKpUWqVG38kVruS4AFzRbvknMcBjb/p2p-circuit/p2p/1YLgpJzDFSGk2paHE4ooC32Lz2poX3y8CdkwUvuRjj6GWg81q6D" - ], - "height": 57728 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 56880, - "amount": 0 - }, - { - "type": "performance", - "height": 56893, - "amount": 0 - }, - { - "type": "performance", - "height": 56908, - "amount": 0 - }, - { - "type": "tenure", - "height": 56880, - "amount": 1 - }, - { - "type": "tenure", - "height": 56893, - "amount": 1 - }, - { - "type": "tenure", - "height": 56908, - "amount": 1 - } - ], - "owner": "1b4WiA7V1qnmHkGGkNbUKNz1npbJS3iD87xak1mJwPmmBPmqTci", - "name": "amateur-denim-pike", - "last_heartbeat": 57774, - "block_added": 47129, - "block": 57780, - "address": "1YLgpJzDFSGk2paHE4ooC32Lz2poX3y8CdkwUvuRjj6GWg81q6D" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "unstaked", - "stake": 0, - "penalty": 0, - "penalties": [ - { - "type": "dkg", - "height": 52676, - "amount": 1 - }, - { - "type": "performance", - "height": 52446, - "amount": 0 - }, - { - "type": "performance", - "height": 52457, - "amount": 0 - }, - { - "type": "performance", - "height": 52642, - "amount": 0 - }, - { - "type": "performance", - "height": 52653, - "amount": 0 - }, - { - "type": "performance", - "height": 52665, - "amount": 0 - }, - { - "type": "performance", - "height": 52679, - "amount": 0.0955963134765625 - }, - { - "type": "performance", - "height": 52694, - "amount": 0.946441650390625 - }, - { - "type": "tenure", - "height": 52446, - "amount": 1 - }, - { - "type": "tenure", - "height": 52457, - "amount": 1 - }, - { - "type": "tenure", - "height": 52642, - "amount": 1 - }, - { - "type": "tenure", - "height": 52653, - "amount": 1 - }, - { - "type": "tenure", - "height": 52665, - "amount": 1 - }, - { - "type": "tenure", - "height": 52679, - "amount": 1 - }, - { - "type": "tenure", - "height": 52694, - "amount": 1 - } - ], - "owner": "1aLVi6Z9qcraQwLAsqdVydCTErZtKyDgUKgcQCJ9JTBbJoxCC77", - "name": "brave-cyan-eagle", - "last_heartbeat": 52852, - "block_added": 46753, - "block": 57780, - "address": "1YgYM95SJwMtAfSq8K4H2uvo9NvHS6k3U1N26LeAxUj6RhM8VfE" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1b7f7BhDcuatz7ricU8p918FBkHURY6mxnKdk6dXBfm7qCtGLnw", - "name": "teeny-tawny-hyena", - "last_heartbeat": 1, - "block_added": 46394, - "block": 57780, - "address": "1YJpb6YksS8moNVGRBjs77MZ1vrdy5AESbwC6oGtzfXmcGaL9Jg" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.195.147.195/tcp/2154"], - "height": 57677 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57092, - "amount": 0 - }, - { - "type": "performance", - "height": 57113, - "amount": 0 - }, - { - "type": "performance", - "height": 57131, - "amount": 0 - }, - { - "type": "performance", - "height": 57147, - "amount": 0 - }, - { - "type": "performance", - "height": 57158, - "amount": 0 - }, - { - "type": "tenure", - "height": 57092, - "amount": 1 - }, - { - "type": "tenure", - "height": 57113, - "amount": 1 - }, - { - "type": "tenure", - "height": 57131, - "amount": 1 - }, - { - "type": "tenure", - "height": 57147, - "amount": 1 - }, - { - "type": "tenure", - "height": 57158, - "amount": 1 - } - ], - "owner": "1aYPkgUsZphXJvvcMbTuikfr3KRMYGRAPGtHKSakVcqzehajbLK", - "name": "attractive-violet-lark", - "last_heartbeat": 57774, - "block_added": 46301, - "block": 57780, - "address": "1YCaXHnZLvx8tZptK6x6nevogdvhsdJedQ1EiEELZjMWgKZofBu" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.209.187.197/tcp/2154"], - "height": 57602 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 56732, - "amount": 0.5919952392578125 - }, - { - "type": "performance", - "height": 56751, - "amount": 1.1962738037109375 - }, - { - "type": "tenure", - "height": 56732, - "amount": 1 - }, - { - "type": "tenure", - "height": 56751, - "amount": 1 - } - ], - "owner": "1bi8fa75vFtEFWn1JQpQg5FDvHeqRuxjoSXTVVzbRxyb3S6HmDW", - "name": "handsome-blood-mustang", - "last_heartbeat": 57769, - "block_added": 46256, - "block": 57780, - "address": "1Z8pQquJoYLbAPQP8UCcTBdiRJHc1qy8RUHCGntTG8Fvk7xspYQ" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/52.14.178.143/tcp/2154"], - "height": 57689 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 9.630126953125, - "penalties": [ - { - "type": "performance", - "height": 57738, - "amount": 8.668807983398438 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - } - ], - "owner": "1bbTarsZdyE8gtdNM48hNFJE6z7aiXQfT1WLJuwRcxczvjWMfAj", - "name": "oblong-rose-salmon", - "last_heartbeat": 57698, - "block_added": 46131, - "block": 57780, - "address": "1YmT6uzyBhrnm4jGGcniFuwyfBjRjQfvNbkfnYKAuUz5SToREhT" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/54.165.11.53/tcp/2154"], - "height": 57569 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.63623046875, - "penalties": [ - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0.0955963134765625 - }, - { - "type": "performance", - "height": 57516, - "amount": 0.1927947998046875 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - } - ], - "owner": "1b2LMHZmhyqz18rGizsGbjyfZ8REjwsHvG3QhkHZdRjTbDmEgpf", - "name": "silly-neon-okapi", - "last_heartbeat": 57601, - "block_added": 45809, - "block": 57780, - "address": "1YDZyKhsvvchsEgbpucD9t2ATMSNhkaktMffTUWmytJ9o5sAaYD" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bZfPLcdfCJDigYqp5exTBJiiRzKPxBHj11NNiAaMqTr5UqM1BR", - "name": "macho-lavender-duck", - "last_heartbeat": 1, - "block_added": 45697, - "block": 57780, - "address": "1YmFWY299j3VjrbCFvs6sRKJZj5YL125Bex1CkRfZHJujgJY7J9" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.245.230.192/tcp/2154"], - "height": 57715 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57321, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57346, - "amount": 0 - }, - { - "type": "performance", - "height": 57360, - "amount": 0 - }, - { - "type": "performance", - "height": 57384, - "amount": 0 - }, - { - "type": "performance", - "height": 57398, - "amount": 0 - }, - { - "type": "performance", - "height": 57412, - "amount": 0 - }, - { - "type": "performance", - "height": 57426, - "amount": 0 - }, - { - "type": "performance", - "height": 57305, - "amount": 0.097198486328125 - }, - { - "type": "tenure", - "height": 57305, - "amount": 1 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57346, - "amount": 1 - }, - { - "type": "tenure", - "height": 57360, - "amount": 1 - }, - { - "type": "tenure", - "height": 57384, - "amount": 1 - }, - { - "type": "tenure", - "height": 57398, - "amount": 1 - }, - { - "type": "tenure", - "height": 57412, - "amount": 1 - }, - { - "type": "tenure", - "height": 57426, - "amount": 1 - } - ], - "owner": "1aKoBwEpWhKL7aW4U5pcnKwUWoFzy9ppJWdq9xyBELrVcNThXwd", - "name": "acidic-shadow-cougar", - "last_heartbeat": 57770, - "block_added": 45404, - "block": 57780, - "address": "1ZN2CcXc3EXyDkbBJ93nLuWK1Crd2vA3Vs8Kth3AgRFsz4MK91A" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": [ - "/ip4/116.24.64.79/tcp/1275", - "/ip4/116.24.64.79/tcp/2154", - "/ip4/157.230.10.25/tcp/2154" - ], - "height": 57611 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.5677642822265625, - "penalties": [ - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0.0955963134765625 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1aCjBMAWymv9x7kXTvKVsTe7tBkSyWoR5uzkQ49SG1tKtYwYG6n", - "name": "quick-satin-shell", - "last_heartbeat": 57776, - "block_added": 44792, - "block": 57780, - "address": "1YPws85sTKu9rf5gBo9JYCUE1muDDrBhVkjUphDnskkk55RruVf" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/3.11.155.41/tcp/2154"], - "height": 55661 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 10.198928833007812, - "penalties": [ - { - "type": "performance", - "height": 55655, - "amount": 0 - }, - { - "type": "performance", - "height": 55674, - "amount": 0 - }, - { - "type": "performance", - "height": 55694, - "amount": 7.476837158203125 - }, - { - "type": "tenure", - "height": 55655, - "amount": 1 - }, - { - "type": "tenure", - "height": 55674, - "amount": 1 - }, - { - "type": "tenure", - "height": 55694, - "amount": 1 - } - ], - "owner": "1byV62k3WzNMCu1hHeuH39H42cLGxGBtKZK5g3MUX9DrFfyqCLS", - "name": "cheerful-laurel-dog", - "last_heartbeat": 55669, - "block_added": 44729, - "block": 57780, - "address": "1ZGwNJPLtskkfs18Miae7S7PEsKJoZp9Gn87C37GLP1VhSa9zVY" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.209.98.119/tcp/2154"], - "height": 57653 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.5706329345703125, - "penalties": [ - { - "type": "performance", - "height": 57665, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0.0951995849609375 - }, - { - "type": "performance", - "height": 57645, - "amount": 0.294403076171875 - }, - { - "type": "performance", - "height": 57601, - "amount": 0.298797607421875 - }, - { - "type": "performance", - "height": 57619, - "amount": 0.3843994140625 - }, - { - "type": "performance", - "height": 57633, - "amount": 0.391998291015625 - }, - { - "type": "performance", - "height": 57483, - "amount": 0.668792724609375 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - } - ], - "owner": "1bPJZubi2tKQev99o231oWenaERvZKbZE7B2sK5smPH35KLaWJr", - "name": "loud-cherry-oyster", - "last_heartbeat": 57777, - "block_added": 44504, - "block": 57780, - "address": "1ZXz2pLkCxAfCDMGRwd3DzPsqnEjxHjEDkrpDLDQxx1vpCiAHyi" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": [ - "/ip4/35.211.248.182/tcp/2154", - "/p2p/1Yhf5LGzkamM7dis7HxGHtyQBhFUYGDr2riJi9CW1aF7QKiXXxF/p2p-circuit/p2p/1YABQ9HqRix254pGNMLQ9GC9autumU9u8oMMpfGnPpErxFM9bUH" - ], - "height": 57719 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.8079376220703125, - "penalties": [ - { - "type": "performance", - "height": 57645, - "amount": 0.096405029296875 - }, - { - "type": "performance", - "height": 57633, - "amount": 0.49200439453125 - }, - { - "type": "performance", - "height": 57619, - "amount": 0.884796142578125 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1a9zgtYAvFgt6UtzpQnogptcczTpSdb3sS3ZcUjqKoWphBGoLJV", - "name": "decent-silver-chameleon", - "last_heartbeat": 57776, - "block_added": 44259, - "block": 57780, - "address": "1YABQ9HqRix254pGNMLQ9GC9autumU9u8oMMpfGnPpErxFM9bUH" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.247.115.147/tcp/2154"], - "height": 57732 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.8719940185546875, - "penalties": [ - { - "type": "performance", - "height": 57753, - "amount": 0 - }, - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - } - ], - "owner": "1avhBTeMUQ7V2bRvMnfevirCy2gFBDNttcsWPPCgLPCgyi2Bo6U", - "name": "loud-opaque-ant", - "last_heartbeat": 57773, - "block_added": 43945, - "block": 57780, - "address": "1YJGyfXgrQRuBBAUH8rqWb2gpLELAqZQJtaNq5scrpAiXN9UPSc" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/54.210.126.66/tcp/2154"], - "height": 57690 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 4.9080047607421875, - "penalties": [ - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57573, - "amount": 0 - }, - { - "type": "performance", - "height": 57585, - "amount": 0 - }, - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57665, - "amount": 0 - }, - { - "type": "performance", - "height": 57684, - "amount": 0 - }, - { - "type": "performance", - "height": 57704, - "amount": 0 - }, - { - "type": "performance", - "height": 57738, - "amount": 0 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - }, - { - "type": "tenure", - "height": 57573, - "amount": 1 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - }, - { - "type": "tenure", - "height": 57684, - "amount": 1 - }, - { - "type": "tenure", - "height": 57704, - "amount": 1 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - } - ], - "owner": "1aPexPoA1CpezaSHPjY2Lz2c15MzvQmP2M7RczExHmonQnRkBC3", - "name": "shallow-ultraviolet-caterpillar", - "last_heartbeat": 57775, - "block_added": 43591, - "block": 57780, - "address": "1Y9MHtteYBUCACwg4Pvo1DovaK1xs7qMv8PSajgp5urHuCKZ15n" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/54.227.10.71/tcp/2154"], - "height": 57697 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.0679931640625, - "penalties": [ - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "performance", - "height": 57516, - "amount": 0.093994140625 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - } - ], - "owner": "1aPexPoA1CpezaSHPjY2Lz2c15MzvQmP2M7RczExHmonQnRkBC3", - "name": "damaged-sapphire-robin", - "last_heartbeat": 57776, - "block_added": 43590, - "block": 57780, - "address": "1Z5dNcPs1ZkW9zmCF9TfvWYPPgPmGvwGfcUURuufvdHc1pgB8KH" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/157.230.179.75/tcp/2154", "/ip4/35.214.81.118/tcp/2154"], - "height": 57637 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 56908, - "amount": 0.100006103515625 - }, - { - "type": "performance", - "height": 56851, - "amount": 0.19720458984375 - }, - { - "type": "performance", - "height": 57092, - "amount": 1.230804443359375 - }, - { - "type": "tenure", - "height": 56851, - "amount": 1 - }, - { - "type": "tenure", - "height": 56908, - "amount": 1 - }, - { - "type": "tenure", - "height": 57092, - "amount": 1 - } - ], - "owner": "1befPFhkCGHsWncAeoGTaAoMyfDtY6A4VaHuPT53HukP9AD338G", - "name": "nutty-infrared-tardigrade", - "last_heartbeat": 57775, - "block_added": 43362, - "block": 57780, - "address": "1Ya6X63YxYg5VaRpvNiXxqJT8YwChuWUiSa8caooP8Bb4m9TKuJ" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.208.63.25/tcp/2154"], - "height": 57627 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.712158203125, - "penalties": [ - { - "type": "performance", - "height": 57777, - "amount": 0.3928070068359375 - }, - { - "type": "performance", - "height": 57765, - "amount": 0.3975982666015625 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1agpdxLkREyoEY7JyvNejFHHgf6ZWAmVRx4XB4MQmuJVXrtMSCp", - "name": "sparkly-sable-fly", - "last_heartbeat": 57755, - "block_added": 43138, - "block": 57780, - "address": "1YeaLu63qrUWeuRHgqgwdh5BHuTMpjZM18WsKJzoj3aPiQzkUDe" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "unstaked", - "stake": 0, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 44061, - "amount": 0 - }, - { - "type": "performance", - "height": 44026, - "amount": 0.19720458984375 - }, - { - "type": "performance", - "height": 44043, - "amount": 2.2281646728515625 - }, - { - "type": "tenure", - "height": 44026, - "amount": 1 - }, - { - "type": "tenure", - "height": 44043, - "amount": 1 - }, - { - "type": "tenure", - "height": 44061, - "amount": 1 - } - ], - "owner": "1b2LMHZmhyqz18rGizsGbjyfZ8REjwsHvG3QhkHZdRjTbDmEgpf", - "name": "cuddly-seaweed-mallard", - "last_heartbeat": 44342, - "block_added": 43007, - "block": 57780, - "address": "1ZY9v4SrmxsMRGbf4JRrmHzSTAj4i8uajuJRRbCS3VyZTykWtnA" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.209.2.202/tcp/2154"], - "height": 57701 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.1018829345703125, - "penalties": [ - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0.39520263671875 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - } - ], - "owner": "1aJnWbphJGN9oQt9UCkdN9NxemuoRAz2nD4saSZaTotsttaF3Jf", - "name": "modern-rosewood-orangutan", - "last_heartbeat": 57771, - "block_added": 42577, - "block": 57780, - "address": "1YXzfYnMtFJzXfjyG2QRoBF3uPY7R16pGDGW3AZoUnJxVB1yvU3" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/85.8.21.230/tcp/2154"], - "height": 57633 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57147, - "amount": 0 - }, - { - "type": "performance", - "height": 57158, - "amount": 0 - }, - { - "type": "performance", - "height": 57171, - "amount": 0 - }, - { - "type": "performance", - "height": 57199, - "amount": 0 - }, - { - "type": "performance", - "height": 57213, - "amount": 0 - }, - { - "type": "performance", - "height": 57185, - "amount": 0.0995941162109375 - }, - { - "type": "tenure", - "height": 57147, - "amount": 1 - }, - { - "type": "tenure", - "height": 57158, - "amount": 1 - }, - { - "type": "tenure", - "height": 57171, - "amount": 1 - }, - { - "type": "tenure", - "height": 57185, - "amount": 1 - }, - { - "type": "tenure", - "height": 57199, - "amount": 1 - }, - { - "type": "tenure", - "height": 57213, - "amount": 1 - } - ], - "owner": "1aWQdDjkTF5Cz7LxYrGkpgSojUNqMLwaFRsxBviUjds1ZV3MmVr", - "name": "mini-quartz-cuckoo", - "last_heartbeat": 57769, - "block_added": 41856, - "block": 57780, - "address": "1ZKNnjxcqTQebySg9nRj6WM7ndp2y4rB5BK4SbL8sdxZPyRVd8J" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/106.13.78.161/tcp/2154"], - "height": 57627 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57455, - "amount": 0.0955963134765625 - }, - { - "type": "performance", - "height": 57441, - "amount": 0.100006103515625 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57455, - "amount": 1 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - } - ], - "owner": "1a4QwKWfKpB6XnEMcpt2Hty8JVLJ5WEm53eZj56nFeG3nLkXsxM", - "name": "obedient-licorice-camel", - "last_heartbeat": 57773, - "block_added": 41814, - "block": 57780, - "address": "1Zpy7FoMr77QL2ussk2VfkvN6TicdvpPwAeWyfDZXyYDcxpDMkZ" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bKaiz8RA4WHfzos6xugoQbT4d2oTjz4fNeawnHk64X1F2BPKdh", - "name": "short-umber-bull", - "last_heartbeat": 1, - "block_added": 41699, - "block": 57780, - "address": "1YwLbGTCEhVbwKEehRVQRC8N3q35ydXTH1B6BQys5FB1paHssdR" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/34.220.160.81/tcp/2154"], - "height": 57655 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.09344482421875, - "penalties": [ - { - "type": "performance", - "height": 57412, - "amount": 1.009918212890625 - }, - { - "type": "performance", - "height": 57619, - "amount": 1.0941162109375 - }, - { - "type": "performance", - "height": 57426, - "amount": 1.4146728515625 - }, - { - "type": "performance", - "height": 57441, - "amount": 1.4228363037109375 - }, - { - "type": "performance", - "height": 57633, - "amount": 2.0711212158203125 - }, - { - "type": "tenure", - "height": 57412, - "amount": 1 - }, - { - "type": "tenure", - "height": 57426, - "amount": 1 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - } - ], - "owner": "1aU8m21HigRtdaKt3Ay7hNDrEdrfQQAfbY9ckYPHWcnFeSgw3Eh", - "name": "handsome-crepe-cat", - "last_heartbeat": 57774, - "block_added": 41669, - "block": 57780, - "address": "1Ztcua8FWRvjjMTbVpANzSwmGUaULpPbQheABFb3pJ7QU2rkAWs" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": ["/ip4/34.214.138.167/tcp/2154"], - "height": 17454 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1aX3BNk3JAa7mHnGUXmUN8MkvapjzSN7fv1ajq7G8Z9egA3iPUT", - "name": "recumbent-stone-spider", - "last_heartbeat": 1, - "block_added": 41666, - "block": 57780, - "address": "1Yi7XRq7kteD48SYYRWJ2jHbELK9qdf74wVYyFH6TbCvCEe31Nj" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1aAU1Uu8cX7C8dx7Si271avKJjjzkuXHmSxPr4CXTakawAzjKBJ", - "name": "high-cinnabar-rhino", - "last_heartbeat": 1, - "block_added": 41666, - "block": 57780, - "address": "1ZVTwjcGhEojV1wAhQmHHj4wWCRkcyCvNKiPtdyEyjyanakM3Lf" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1aYEcRYzwXLqcpXZWtFL8VRdJca7Ab2xS3oiFhsvub357cYwRou", - "name": "silly-seaweed-capybara", - "last_heartbeat": 1, - "block_added": 41438, - "block": 57780, - "address": "1Z2ZfnQb4TfNmFC6iXSpYASCv1yg9WNYquqgrsnkoasZghVhid5" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/34.196.149.109/tcp/2154"], - "height": 57633 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.05999755859375, - "penalties": [ - { - "type": "performance", - "height": 57516, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - } - ], - "owner": "1bbGCPVmUWzm7tJm6eZ7MBeRMaksH7YLH6sNRK582i7AEqXJ27K", - "name": "rapid-sandstone-panda", - "last_heartbeat": 57778, - "block_added": 41366, - "block": 57780, - "address": "1YkR2UkW1oraygxend18eihQPaeS3NiDJ4AbpteBrtdyJCEWNMk" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.212.127.221/tcp/2154"], - "height": 57693 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.3397979736328125, - "penalties": [ - { - "type": "performance", - "height": 57441, - "amount": 0.0984039306640625 - }, - { - "type": "performance", - "height": 57645, - "amount": 0.100006103515625 - }, - { - "type": "performance", - "height": 57455, - "amount": 0.29400634765625 - }, - { - "type": "performance", - "height": 57516, - "amount": 0.2967987060546875 - }, - { - "type": "performance", - "height": 57665, - "amount": 0.3787994384765625 - }, - { - "type": "performance", - "height": 57498, - "amount": 0.3892059326171875 - }, - { - "type": "performance", - "height": 57483, - "amount": 0.764801025390625 - }, - { - "type": "tenure", - "height": 57441, - "amount": 1 - }, - { - "type": "tenure", - "height": 57455, - "amount": 1 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - } - ], - "owner": "1btmSxwAML8LoBxizJtnQ22p93qdCF1xvaT8zkc1iVkweEWrx2h", - "name": "nutty-tin-seahorse", - "last_heartbeat": 57769, - "block_added": 41036, - "block": 57780, - "address": "1ZCTs5js8Cc2JVT29VRfmwhs8UXHGuzWEoqdAs7bAa6YBU59bpu" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/157.230.179.75/tcp/2154", "/ip4/206.189.176.222/tcp/2154"], - "height": 57721 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.9955291748046875, - "penalties": [ - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57738, - "amount": 0 - }, - { - "type": "performance", - "height": 57665, - "amount": 0.096405029296875 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - }, - { - "type": "tenure", - "height": 57738, - "amount": 1 - } - ], - "owner": "1bRgMcoYdL5c7upN1Xb3hNepGQncKgXe33gBs1xEwB2eZD6WQfV", - "name": "soft-azure-haddock", - "last_heartbeat": 57769, - "block_added": 41004, - "block": 57780, - "address": "1ZbRYtpawdjQSQmGSnEDgXUBWvLeZtFwBLQRURiuzp7h7f9kXSR" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.208.246.36/tcp/2154"], - "height": 57622 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 1.641845703125, - "penalties": [ - { - "type": "performance", - "height": 57633, - "amount": 0.100006103515625 - }, - { - "type": "performance", - "height": 57601, - "amount": 0.5915985107421875 - }, - { - "type": "performance", - "height": 57619, - "amount": 1.0691986083984375 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - } - ], - "owner": "1b5pvD66YPw6kNngQYzL9AybKp6cRwZSttwJxRXJtFKf5jE6UCA", - "name": "salty-ivory-blackbird", - "last_heartbeat": 57778, - "block_added": 40749, - "block": 57780, - "address": "1YPrQ852SSfmvZEE1xfVSrUYt2deshAhApcDYbxtaKy5guf6PcX" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.81.3.160/tcp/2154"], - "height": 57702 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.23199462890625, - "penalties": [ - { - "type": "performance", - "height": 57601, - "amount": 0 - }, - { - "type": "performance", - "height": 57619, - "amount": 0 - }, - { - "type": "performance", - "height": 57633, - "amount": 0 - }, - { - "type": "performance", - "height": 57645, - "amount": 0 - }, - { - "type": "performance", - "height": 57665, - "amount": 0 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - }, - { - "type": "tenure", - "height": 57633, - "amount": 1 - }, - { - "type": "tenure", - "height": 57645, - "amount": 1 - }, - { - "type": "tenure", - "height": 57665, - "amount": 1 - } - ], - "owner": "1bnSU6XW71sZ93trfyaseqwFpmakqJNbWFyxQQFpJsBKz4ttqDc", - "name": "polite-grape-narwhal", - "last_heartbeat": 57769, - "block_added": 40472, - "block": 57780, - "address": "1YgCMWPCiR1rfXNXLggW21evTnVb6BJYDdXTjAZyXiWhYNfSvJM" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/143.198.104.240/tcp/2154", "/ip4/35.167.70.214/tcp/2154"], - "height": 57690 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57265, - "amount": 0 - }, - { - "type": "performance", - "height": 57280, - "amount": 0 - }, - { - "type": "performance", - "height": 57321, - "amount": 0 - }, - { - "type": "performance", - "height": 57334, - "amount": 0 - }, - { - "type": "performance", - "height": 57346, - "amount": 0 - }, - { - "type": "performance", - "height": 57360, - "amount": 0 - }, - { - "type": "performance", - "height": 57305, - "amount": 0.097198486328125 - }, - { - "type": "tenure", - "height": 57265, - "amount": 1 - }, - { - "type": "tenure", - "height": 57280, - "amount": 1 - }, - { - "type": "tenure", - "height": 57305, - "amount": 1 - }, - { - "type": "tenure", - "height": 57321, - "amount": 1 - }, - { - "type": "tenure", - "height": 57334, - "amount": 1 - }, - { - "type": "tenure", - "height": 57346, - "amount": 1 - }, - { - "type": "tenure", - "height": 57360, - "amount": 1 - } - ], - "owner": "1a8Aq2Vbeuc5gji3W6NoJrAoNB8RfJWomncZnphBqJih9SnK2NP", - "name": "ambitious-peanut-mink", - "last_heartbeat": 57771, - "block_added": 40302, - "block": 57780, - "address": "1YfDytuvfTkmukgsnwR8ZLXWu7a8eGzNjFAMFRo4jm5SPTVWR7z" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/54.191.170.248/tcp/2154"], - "height": 57710 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [ - { - "type": "performance", - "height": 57185, - "amount": 0.6876068115234375 - }, - { - "type": "performance", - "height": 56957, - "amount": 1.1897125244140625 - }, - { - "type": "performance", - "height": 56969, - "amount": 1.325164794921875 - }, - { - "type": "performance", - "height": 57199, - "amount": 1.4130859375 - }, - { - "type": "tenure", - "height": 56957, - "amount": 1 - }, - { - "type": "tenure", - "height": 56969, - "amount": 1 - }, - { - "type": "tenure", - "height": 57185, - "amount": 1 - }, - { - "type": "tenure", - "height": 57199, - "amount": 1 - } - ], - "owner": "1bQ7xRSF5FrAsDWaUmZVqziaFjeu2VVu8CnXfSXCWViJKNuse5u", - "name": "flaky-admiral-chicken", - "last_heartbeat": 57775, - "block_added": 40201, - "block": 57780, - "address": "1ZsKNDEax89bjXQkS2J8sJSU68z6APBJN7u4BdGWJAM7xLvkFUK" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/35.199.181.8/tcp/2154"], - "height": 57670 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0.2573394775390625, - "penalties": [ - { - "type": "performance", - "height": 57483, - "amount": 0 - }, - { - "type": "performance", - "height": 57498, - "amount": 0 - }, - { - "type": "performance", - "height": 57516, - "amount": 0 - }, - { - "type": "performance", - "height": 57530, - "amount": 0 - }, - { - "type": "performance", - "height": 57559, - "amount": 0 - }, - { - "type": "performance", - "height": 57545, - "amount": 0.629638671875 - }, - { - "type": "tenure", - "height": 57483, - "amount": 1 - }, - { - "type": "tenure", - "height": 57498, - "amount": 1 - }, - { - "type": "tenure", - "height": 57516, - "amount": 1 - }, - { - "type": "tenure", - "height": 57530, - "amount": 1 - }, - { - "type": "tenure", - "height": 57545, - "amount": 1 - }, - { - "type": "tenure", - "height": 57559, - "amount": 1 - } - ], - "owner": "1agicQbv7jmG6fJr5txyPEWLtRcmwcohbQDVKoWdbdqAP2nH2p2", - "name": "teeny-tartan-frog", - "last_heartbeat": 57775, - "block_added": 39780, - "block": 57780, - "address": "1ZCVxQ8B2nQVDtd7EDxGuVsPwxTNMrjGjn4CUNeBKUw8kYcFMiE" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1bE7bL77st6n6gway77C9AtPUpZgXkk5t87XjBSAmmLvLeQwngc", - "name": "bubbly-aquamarine-woodpecker", - "last_heartbeat": 39815, - "block_added": 39641, - "block": 57780, - "address": "1ZKX9M21pxRfJfqSdTXmNMHgMoh3wob4YV82u5NDYFAdKPQh2pN" - }, - { - "version_heartbeat": 10048, - "status": { - "online": "online", - "listen_addrs": ["/ip4/157.131.101.181/tcp/2154"], - "height": 57588 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 3.1520233154296875, - "penalties": [ - { - "type": "performance", - "height": 57585, - "amount": 1.5709228515625 - }, - { - "type": "performance", - "height": 57601, - "amount": 2.266448974609375 - }, - { - "type": "performance", - "height": 57619, - "amount": 2.7936859130859375 - }, - { - "type": "tenure", - "height": 57585, - "amount": 1 - }, - { - "type": "tenure", - "height": 57601, - "amount": 1 - }, - { - "type": "tenure", - "height": 57619, - "amount": 1 - } - ], - "owner": "1bHtA48KfuxYUXz5gpxY4oSqCK9mGEzsnSaVC3QKkVNYsSCBjzt", - "name": "rich-beige-dove", - "last_heartbeat": 57770, - "block_added": 38599, - "block": 57780, - "address": "1Z3DPRpmEfTL5f528CF5xjpPDUhZY9TErB3tgnhqCtMM6nnw38L" - }, - { - "version_heartbeat": 10051, - "status": { - "online": "online", - "listen_addrs": ["/ip4/3.143.229.44/tcp/2154"], - "height": 57736 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 2.82000732421875, - "penalties": [ - { - "type": "performance", - "height": 57753, - "amount": 0 - }, - { - "type": "performance", - "height": 57765, - "amount": 0 - }, - { - "type": "performance", - "height": 57777, - "amount": 0 - }, - { - "type": "tenure", - "height": 57753, - "amount": 1 - }, - { - "type": "tenure", - "height": 57765, - "amount": 1 - }, - { - "type": "tenure", - "height": 57777, - "amount": 1 - } - ], - "owner": "1aScVVYDTW2BCqyDF4BLsXytjwPGqJ7ZjqCAezoDuwH8XvWE7zA", - "name": "proper-blue-cheetah", - "last_heartbeat": 57778, - "block_added": 38176, - "block": 57780, - "address": "1ZEVn1EeJxTtRY5dFrkkGyeKRuNGA6aYKFLqtwRXvrmgCFJSFwb" - }, - { - "version_heartbeat": 1, - "status": { - "online": "offline", - "listen_addrs": null, - "height": null - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 0, - "penalties": [], - "owner": "1b91SNH75kgPxjEGtkVpyRKHkwZWw43WczYyUGyXEEPAXB11J4u", - "name": "skinny-velvet-swift", - "last_heartbeat": 1, - "block_added": 37848, - "block": 57780, - "address": "1bHL1nQP5gRHqJESvTRWXp3e89FuX5vpZqAtiu6U1iVeHDqzu8N" - } - ], - "cursor": "eyJoZWlnaHQiOjU3NzgwLCJiZWZvcmVfYmxvY2siOjM3ODQ4LCJiZWZvcmVfYWRkcmVzcyI6IjFiSEwxblFQNWdSSHFKRVN2VFJXWHAzZTg5RnVYNXZwWnFBdGl1NlUxaVZlSERxenU4TiJ9" -} -``` - - - - ---- - -### Validator for Address - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/:address -``` - -Fetch a validator with a given address. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------- | -------- | ----------------------------- | -| address | _string_ | Address of validator to fetch | - - - - -200: OK - -```json -{ - "data": { - "version_heartbeat": 10010004, - "status": { - "timestamp": "2021-09-02T15:00:45.005000Z", - "online": "online", - "listen_addrs": ["/ip4/690.0.0.180/tcp/2154", "/ip4/340.210.76.150/tcp/2154"], - "height": 993737 - }, - "stake_status": "staked", - "stake": 1000000000000, - "penalty": 8.113204956054688, - "penalties": [ - { - "type": "performance", - "height": 992513, - "amount": 0.099853515625 - }, - { - "type": "performance", - "height": 992677, - "amount": 0.099853515625 - }, - { - "type": "performance", - "height": 992610, - "amount": 0.659027099609375 - }, - { - "type": "performance", - "height": 992643, - "amount": 0.659027099609375 - }, - { - "type": "performance", - "height": 992710, - "amount": 0.758880615234375 - }, - { - "type": "performance", - "height": 992545, - "amount": 1.1883544921875 - }, - { - "type": "performance", - "height": 992577, - "amount": 1.2882080078125 - }, - { - "type": "tenure", - "height": 992480, - "amount": 0.5 - }, - { - "type": "tenure", - "height": 992513, - "amount": 0.5 - }, - { - "type": "tenure", - "height": 992545, - "amount": 0.5 - }, - { - "type": "tenure", - "height": 992577, - "amount": 0.5 - }, - { - "type": "tenure", - "height": 992610, - "amount": 0.5 - }, - { - "type": "tenure", - "height": 992643, - "amount": 0.5 - }, - { - "type": "tenure", - "height": 992677, - "amount": 0.5 - }, - { - "type": "tenure", - "height": 992710, - "amount": 0.5 - } - ], - "owner": "14apkx9H3pkkfZWXXVCsjdPbKKdXxS5LrA4PF9v2iZUFMunbRog", - "name": "fat-thanksgiving-turkey", - "last_heartbeat": 994072, - "consensus_groups": 8, - "block_added": 983774, - "block": 994078, - "address": "112VtykzPvavfjrT9QwEyvhFMxzxCBUaYmKByYjpLFvxM5qHzw5" - } -} -``` - - - - ---- - -### Validators for Name - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/name/:name -``` - -Fetch the validators which map to the given 3-word animal name. The name must be all lower-case with -dashes between the words, e.g. tall-plum-griffin. Because of collisions in the Angry Purple Tiger -algorithm, the given name might map to **more than one validator**. - - - - -_Path Parameters_ - -| param | Type | Note | -| ----- | -------- | ----------------------------- | -| name | _string_ | Name of validator(s) to fetch | - - - - -200: OK - -```json -{ - "data": [ - { - "address": "1bHL1nQP5gRHqJESvTRWXp3e89FuX5vpZqAtiu6U1iVeHDqzu8N", - "block": 57766, - "block_added": 37848, - "last_heartbeat": 1, - "name": "skinny-velvet-swift", - "owner": "1b91SNH75kgPxjEGtkVpyRKHkwZWw43WczYyUGyXEEPAXB11J4u", - "penalties": [], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": null, - "listen_addrs": null, - "online": "offline" - }, - "version_heartbeat": 1 - } - ] -} -``` - - - - ---- - -### Validator Name Search - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/name?search= -``` - -Fetch the validators which match a search term in the given `search` term query parameter. The -search parameter needs to be at least one character, with 3 or more recommended. - - - - -_Query Parameters_ - -| param | Type | Note | -| ------ | -------- | ------------------------------- | -| search | _string_ | The name fragment to search for | - - - - -200: OK - -Search results for `search=skinny-iron` - -```json -{ - "data": [ - { - "address": "1YwjDSMjfuk2SNbV7UFRjdRsJCGaz17Nj136315bdjEM8RfNg5j", - "block": 57771, - "block_added": 1610, - "last_heartbeat": 57765, - "name": "skinny-iron-copperhead", - "owner": "1at2MZk8Cdv15ApcCeLGSm3N5NVng4JJWa9PKkWLxfJC4F2D1Hk", - "penalties": [ - { - "amount": 0.0, - "height": 57280, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57321, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57360, - "type": "performance" - }, - { - "amount": 0.0959930419921875, - "height": 57334, - "type": "performance" - }, - { - "amount": 0.096405029296875, - "height": 57346, - "type": "performance" - }, - { - "amount": 0.097198486328125, - "height": 57305, - "type": "performance" - }, - { - "amount": 1.0, - "height": 57280, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57305, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57321, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57334, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57346, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57360, - "type": "tenure" - } - ], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57699, - "listen_addrs": ["/ip4/18.193.146.142/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - }, - { - "address": "1Yte3yMu8k4t7NXwNBmeG57iayPpBfmHG8BteFqhQjE84RKG6Pk", - "block": 57771, - "block_added": 2977, - "last_heartbeat": 57762, - "name": "skinny-indigo-owl", - "owner": "1bW7KhrM9dUUm3aP3Skj8YC3S3NfEk5TuBL85gFazkyuF5RDvCL", - "penalties": [ - { - "amount": 0.0, - "height": 57441, - "type": "performance" - }, - { - "amount": 0.0955963134765625, - "height": 57573, - "type": "performance" - }, - { - "amount": 0.0980072021484375, - "height": 57530, - "type": "performance" - }, - { - "amount": 0.0991973876953125, - "height": 57559, - "type": "performance" - }, - { - "amount": 0.100006103515625, - "height": 57455, - "type": "performance" - }, - { - "amount": 0.3892059326171875, - "height": 57545, - "type": "performance" - }, - { - "amount": 1.0, - "height": 57441, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57455, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57530, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57545, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57559, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57573, - "type": "tenure" - } - ], - "penalty": 0.698944091796875, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57693, - "listen_addrs": ["/ip4/35.226.133.108/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - } - ] -} -``` - - - - ---- - -### Validator Activity - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/:address/activity -``` - -:::caution - -The `/activity` route will be deprecated on May 1, 2022 and will be replaced by -[`/roles`, described below](#validator-roles) - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -::: - -Lists all blockchain transactions that the given validator was involved in. This route is paged -using a `cursor`. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------- | -| address (optional) | _string_ | B58 address of the validator | - -_Query Parameters_ - -| param | Type | Note | -| ----------------------- | -------- | ----------------------------------------- | -| cursor (optional) | _string_ | Cursor for page of results to fetch | -| filter_types (optional) | _string_ | Comma separated list of transaction types | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -This lists the activity for a validator that recently came online. - -```json -{ - "cursor": "eyJtaW5fYmxvY2siOjEzNTYsImJsb2NrIjo1NzgwMCwiYW5jaG9yX2Jsb2NrIjo1NzgwMH0", - "data": [ - { - "address": "1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK", - "hash": "KhQxLTEOr932fAIQcqA6pw_lq5PWJJfh4GGeHA3Di8k", - "height": 57851, - "signature": "MEQCIAOhjw8ty-IOVJBhwULHZb0Z5Gf61idn8GCGNcwtPAARAiASX56H6WUzrW767qsfQKuuk7KvnXq8eveXIFmNFy1t_g", - "time": 1620766822, - "type": "validator_heartbeat_v1", - "version": 10051 - }, - { - "address": "1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK", - "hash": "hGLd-f6Y3TZa09QZzdAAu7ZnOBhyN6TTulSwB4bpZyY", - "height": 57841, - "signature": "MEUCIFjWlCejrwNfWOjD9-r_GxRxqfcs1PlsJ9sNluceH9RMAiEA-aoaLF8nSi3RcWxpkncKyrJ2JyyECy_3rbsyOBP1RnI", - "time": 1620766521, - "type": "validator_heartbeat_v1", - "version": 10051 - }, - { - "address": "1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK", - "hash": "6EkmS-Yzv9x9YMLQsMzJStUzO_I47f_jOvzODeQe4JQ", - "height": 57830, - "signature": "MEUCIBkerT71jAXtq3p7tVL6MTJKe2SSnXhiIPm-fdcLXX6fAiEAvgiFHf0vMqTOPob08D4btXTzyMK6d6m3W5ZlskY0ATw", - "time": 1620766191, - "type": "validator_heartbeat_v1", - "version": 10051 - }, - { - "address": "1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK", - "hash": "-M5roJvgoJdeWiXgDhqDNDcEuSbV-ZQ7Lc4Efpvtvz0", - "height": 57820, - "signature": "MEQCIAGa2Q2QQIKXQ5WIvGk0g_Rnu4Tnm2fLludQ8S7K9tmuAiByVpJvAtMnHLAu_SQWnkNljV0YNM8Qin4yMmuLyJzDFg", - "time": 1620765891, - "type": "validator_heartbeat_v1", - "version": 10051 - }, - { - "address": "1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK", - "hash": "iN2Os7q6W6ZFmkTqLMxKeJmkDLsWB5smBl4_sOPfF7A", - "height": 57810, - "signature": "MEQCIEwZR2GRd4ari2dK4lm4hGcD9JCtZqYSM92ABLZHmgqqAiBozLre8oabOlEXBK-pgGdATcjlZKe3plE4V_lhm6mamw", - "time": 1620765591, - "type": "validator_heartbeat_v1", - "version": 10051 - }, - { - "address": "1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK", - "hash": "eKCTTKOqSmmBvxKa1LXr4p439m2uO6r6bOPszDQCFCc", - "height": 57800, - "signature": "MEQCIEk1_wz5vyIXpqaOD3Vv0LffwwFd-hNfsCQD88QpcAsvAiAVSFqSw8lkXnn_gbZd5GePgFM_LNpbOyOXSgPfJMPW1g", - "time": 1620765291, - "type": "validator_heartbeat_v1", - "version": 10051 - } - ] -} -``` - - - - ---- - -### Validator Roles - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/:address/roles -``` - -Lists all blockchain transactions that the given validator was involved in. This route is paged -using a `cursor`. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------- | -| address (optional) | _string_ | B58 address of the validator | - -_Query Parameters_ - -| param | Type | Note | -| ----------------------- | -------- | ----------------------------------------- | -| cursor (optional) | _string_ | Cursor for page of results to fetch | -| filter_types (optional) | _string_ | Comma separated list of transaction types | -| min_time (optional) | _string_ | First time to include data for | -| max_time (optional) | _string_ | Last time to include data for | -| limit (optional) | _number_ | Maximum number of items to return | - - - - -200: OK - -This lists the activity for a validator that recently came online. - -```json -{ - "data": [ - { - "type": "validator_heartbeat_v1", - "time": 1644017331, - "role": "validator", - "height": 1212246, - "hash": "Xz7zM9mN4ZA_4uSj-SVjeiXHlTdJO8vB0yBSVDkgNBA" - }, - { - "type": "validator_heartbeat_v1", - "time": 1644010677, - "role": "validator", - "height": 1212144, - "hash": "UwTuX7FxEzhuH_zu3rRBA_yXf7UFUTJwivQLm-rR_ps" - }, - { - "type": "stake_validator_v1", - "time": 1644010555, - "role": "validator", - "height": 1212142, - "hash": "8wOjSODY4M_U8M_Eb2SBm1lqJyncf3RItXZtG4oZQJ8" - } - ] -} -``` - - - - ---- - -### Validator Roles Counts - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/:address/roles/count -``` - -Count transactions that indicate activity for a validator. - -The results are a map keyed by the given `filter_types` and the count of transaction of that type. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | --------------------------------------- | -| address (required) | _string_ | Hotspot B58 address to fetch counts for | - -_Query Parameters_ - -| param | Type | Note | -| ------------ | -------- | ----------------------------------------- | -| filter_types | _string_ | Comma separated list of transaction types | - - - - -200: OK - -Fetch counts for validator `1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK` - -```json -{ - "data": { - "vars_v1": 0, - "validator_heartbeat_v1": 812, - "unstake_validator_v1": 0, - "transfer_validator_stake_v1": 0, - "transfer_hotspot_v1": 0, - "token_burn_v1": 0, - "token_burn_exchange_rate_v1": 0, - "state_channel_open_v1": 0, - "state_channel_close_v1": 0, - "stake_validator_v1": 1, - "security_exchange_v1": 0, - "security_coinbase_v1": 0, - "routing_v1": 0, - "rewards_v2": 51, - "rewards_v1": 0, - "redeem_htlc_v1": 0, - "price_oracle_v1": 0, - "poc_request_v1": 0, - "poc_receipts_v1": 0, - "payment_v2": 0, - "payment_v1": 0, - "oui_v1": 0, - "gen_gateway_v1": 0, - "dc_coinbase_v1": 0, - "create_htlc_v1": 0, - "consensus_group_v1": 0, - "consensus_group_failure_v1": 0, - "coinbase_v1": 0, - "assert_location_v2": 0, - "assert_location_v1": 0, - "add_gateway_v1": 0 - } -} -``` - - - - ---- - -### Stats for Validators - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` - -GET https://api.helium.io/v1/validators/stats - -``` - -Returns stats for validators - - - - - - - -200: OK - -```json -{ - "data": { - "active": 194, - "cooldown": { - "amount": 0, - "count": 0 - }, - "staked": { - "amount": 2120000.0, - "count": 212 - }, - "unstaked": { - "amount": 0.0, - "count": 2 - } - } -} -``` - - - - ---- - -### Currently Elected Validators - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/elected -``` - -Returns the list of validators that are currently elected to the consensus group. - - - - -_No Parameters_ - - - - -200: OK - -```json -{ -{ - "data": [ - { - "version_heartbeat": 2, - "status": "staked", - "stake": 1000000000000, - "owner": "1aPh5LpH9AFMV3gHALYEZyZfiXvktnqADV6fKMkrgh37u5oZUnC", - "last_heartbeat": 427, - "block": 466, - "address": "1ZJmbSPJeGt9QHikNUGCd5qorvBxtGK5qc18sXRiQKcSyETFMVm" - }, - { - "version_heartbeat": 2, - "status": "staked", - "stake": 1000000000000, - "owner": "1bBTWn843DwTXTyH3hbSMmDoJXHCU1D1U8cAYRdVE5rDnaS7fLb", - "last_heartbeat": 447, - "block": 466, - "address": "1YeCAsuBq3fDTv8x4iB1fJn9zBbopHhjhXGpvVwN43JDptqMT11" - }, - { - "version_heartbeat": 2, - "status": "staked", - "stake": 1000000000000, - "owner": "1ZLXHYHZY36wKZDBfjjo8ERgio8wenhCTtJGw9tNSQeAwPEMSMG", - "last_heartbeat": 451, - "block": 466, - "address": "1ZAxCrEsigGVbLUM37Jki6p88kyZ5NVqjVC6oHSbqu49t7bQDym" - }, - { - "version_heartbeat": 2, - "status": "staked", - "stake": 1000000000000, - "owner": "1ZLXHYHZY36wKZDBfjjo8ERgio8wenhCTtJGw9tNSQeAwPEMSMG", - "last_heartbeat": 455, - "block": 466, - "address": "1YqV6er1KDWBR9zRcXm3ktqY2Gi3r7QZRD8mDPq6yz5JNxt2zxy" - } - ] -} -``` - - - - -### Elected Validators at a Block - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/elected/:height -``` - -Returns the list of validators that were in the consensus group at a given block height - - - - -_Path Parameters_ - -| param | Type | Note | -| ----------------- | -------- | ----------------- | -| height (required) | _number_ | Blockchain Height | - - - - -200: OK - -```json -{ - "data": [ - { - "address": "1ZYe21WzqJGkWjXvyEt2c8ALSrufPfjzqfQP2SGy61UJd2h9EbL", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57765, - "name": "eager-watermelon-rabbit", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 56704, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56716, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56732, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56751, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56768, - "type": "performance" - }, - { - "amount": 1.0, - "height": 56704, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56716, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56732, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56751, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56768, - "type": "tenure" - } - ], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57671, - "listen_addrs": ["/ip4/3.17.164.253/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - }, - { - "address": "1ZPNnNd9k5qiQXXigKifQpCPiy5HTbszQDSyLM56ywk7ihNRvt6", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57768, - "name": "delightful-mahogany-kitten", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 57426, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57441, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57455, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57483, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57498, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57516, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57633, - "type": "performance" - }, - { - "amount": 1.0, - "height": 57426, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57441, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57455, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57483, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57498, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57516, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57633, - "type": "tenure" - } - ], - "penalty": 0.451995849609375, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57591, - "listen_addrs": ["/ip4/18.223.171.149/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - }, - { - "address": "1YdBWwpRimEoPZ5WDxgv9ZBUfxhXyVFTkpX1oRLwmncWRvqj7Vh", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57748, - "name": "refined-vanilla-goldfish", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 56573, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56589, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56704, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56732, - "type": "performance" - }, - { - "amount": 1.0, - "height": 56573, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56589, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56704, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56732, - "type": "tenure" - } - ], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57705, - "listen_addrs": ["/ip4/3.137.173.26/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - }, - { - "address": "1Zmw2S5ksj4oxDMYFz3vQxFNnQsE7Sc3Mv9YrkiWktLznwng935", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57767, - "name": "chilly-cloth-bison", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 57199, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57213, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57225, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57254, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57265, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57280, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57321, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57334, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57346, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57360, - "type": "performance" - }, - { - "amount": 0.097198486328125, - "height": 57305, - "type": "performance" - }, - { - "amount": 0.09759521484375, - "height": 57239, - "type": "performance" - }, - { - "amount": 1.0, - "height": 57199, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57213, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57225, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57239, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57254, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57265, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57280, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57305, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57321, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57334, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57346, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57360, - "type": "tenure" - } - ], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57471, - "listen_addrs": ["/ip4/3.135.195.98/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - } - ] -} -``` - - - - -### Elected Validators in an Election - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` - -GET https://api.helium.io/v1/validators/elected/hash/:hash - -``` - -Returns the list of validators that were elected in the consensus group transcation indicated by the -given transaction hash. - - - - -_Path Parameters_ - -| param | Type | Note | -| --------------- | -------- | ---------------- | -| hash (required) | _number_ | Transaction Hash | - - - - -200: OK - -```json -{ - "data": [ - { - "address": "1ZYe21WzqJGkWjXvyEt2c8ALSrufPfjzqfQP2SGy61UJd2h9EbL", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57765, - "name": "eager-watermelon-rabbit", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 56704, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56716, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56732, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56751, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56768, - "type": "performance" - }, - { - "amount": 1.0, - "height": 56704, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56716, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56732, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56751, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56768, - "type": "tenure" - } - ], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57671, - "listen_addrs": ["/ip4/3.17.164.253/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - }, - { - "address": "1ZPNnNd9k5qiQXXigKifQpCPiy5HTbszQDSyLM56ywk7ihNRvt6", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57768, - "name": "delightful-mahogany-kitten", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 57426, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57441, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57455, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57483, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57498, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57516, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57633, - "type": "performance" - }, - { - "amount": 1.0, - "height": 57426, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57441, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57455, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57483, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57498, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57516, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57633, - "type": "tenure" - } - ], - "penalty": 0.451995849609375, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57591, - "listen_addrs": ["/ip4/18.223.171.149/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - }, - { - "address": "1YdBWwpRimEoPZ5WDxgv9ZBUfxhXyVFTkpX1oRLwmncWRvqj7Vh", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57748, - "name": "refined-vanilla-goldfish", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 56573, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56589, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56704, - "type": "performance" - }, - { - "amount": 0.0, - "height": 56732, - "type": "performance" - }, - { - "amount": 1.0, - "height": 56573, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56589, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56704, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 56732, - "type": "tenure" - } - ], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57705, - "listen_addrs": ["/ip4/3.137.173.26/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - }, - { - "address": "1Zmw2S5ksj4oxDMYFz3vQxFNnQsE7Sc3Mv9YrkiWktLznwng935", - "block": 57775, - "block_added": 1, - "last_heartbeat": 57767, - "name": "chilly-cloth-bison", - "owner": "1YoBQ8mm2s3G56Yq9YmZ1ZrhDwKruwYwKBVzUSppj8jujX1WT2v", - "penalties": [ - { - "amount": 0.0, - "height": 57199, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57213, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57225, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57254, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57265, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57280, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57321, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57334, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57346, - "type": "performance" - }, - { - "amount": 0.0, - "height": 57360, - "type": "performance" - }, - { - "amount": 0.097198486328125, - "height": 57305, - "type": "performance" - }, - { - "amount": 0.09759521484375, - "height": 57239, - "type": "performance" - }, - { - "amount": 1.0, - "height": 57199, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57213, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57225, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57239, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57254, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57265, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57280, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57305, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57321, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57334, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57346, - "type": "tenure" - }, - { - "amount": 1.0, - "height": 57360, - "type": "tenure" - } - ], - "penalty": 0.0, - "stake": 1000000000000, - "stake_status": "staked", - "status": { - "height": 57471, - "listen_addrs": ["/ip4/3.135.195.98/tcp/2154"], - "online": "online" - }, - "version_heartbeat": 10051 - } - ] -} -``` - - - - ---- - -### Rewards for a Validator - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/:address/rewards -``` - -Returns rewards for a given validator per reward block the validator is in, for a given timeframe. -Timestamps are given in ISO 8601 format, or in relative time. The block that contains the `max_time` -timestamp is **excluded** from the result. - -This route is paged using a `cursor`. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------- | -| address (required) | _string_ | B58 address of the validator | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | -------------------------------------- | -| cursor (optional) | _string_ | Cursor for page of rewards to fetch | -| max_time (required) | _string_ | Last timestamp to include rewards for | -| min_time (required) | _string_ | First timestamp to include rewards for | - - - - -200: OK - -Rewards for a validator in the last 3 hours: `min_time=-3%20hour` - -```json -{ - "data": [ - { - "account": "1bLkeh9G2c85CvvCdV3LPe94im8VTQ6Byq71u6KbfLjeQ5GBUqR", - "amount": 526094276, - "block": 7649, - "gateway": "1Z7GHfLgGUfnKCnEfZEUUqaPSo4674XyX6SA3ZY93rkSTzm9ALK", - "hash": "jJ92KTtaRyMXKUdK3R5J7tfztMrOO0ozyAC7xHu_Tgk", - "timestamp": "2021-04-24T10:38:03.000000Z" - } - ] -} -``` - - - - ---- - -### Reward Total for a Validator - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/:address/rewards/sum -``` - -Returns the total rewards earned for a given validator over a given time range. Timestamps are given -in ISO 8601 format or in relative time. The block that includes the `max_time` timestamp is -**excluded** from the result. - -The optional `bucket` parameter buckets the results in the given bucket size (`hour`, `day`, -`week`). - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------- | -| address (required) | _string_ | B58 address of the validator | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | -------------------------------------- | -| max_time (required) | _string_ | Last timestamp to include rewards for | -| min_time (required) | _string_ | First timestamp to include rewards for | -| bucket (optional) | _string_ | Bucket size (defaults to entire range) | - - - - -Rewards for a validator in the last 24 hours: `min_time=-24%20hour` - -200: OK - -```json -{ - "data": { - "avg": 5.26094276, - "max": 5.0, - "median": 5.26094276, - "min": 5.0, - "stddev": 0.0, - "sum": 4208754208, - "total": 42.08754208 - }, - "meta": { - "max_time": "2021-04-24T13:28:38Z", - "min_time": "2021-04-23T13:28:38Z" - } -} -``` - - - - ---- - -### Reward Total for all Validators - -:::caution This Endpoint Is Deprecated - -This endpoint is deprecated. Validators are no longer entities on the Helium Network. - -::: - -``` -GET https://api.helium.io/v1/validators/:rewards/sum -``` - -Returns the total rewards earned for all validators over a given time range. Timestamps are given in -ISO 8601 format or in relative time. The block that includes the `max_time` timestamp is -**excluded** from the result. - - - - -_Path Parameters_ - -| param | Type | Note | -| ------------------ | -------- | ---------------------------- | -| address (required) | _string_ | B58 address of the validator | - -_Query Parameters_ - -| param | Type | Note | -| ------------------- | -------- | -------------------------------------- | -| max_time (required) | _string_ | Last timestamp to include rewards for | -| min_time (required) | _string_ | First timestamp to include rewards for | - - - - -Rewards for valdiators in the last 24 hours: `min_time=-24%20hour` - -200: OK - -```json -{ - "data": { - "avg": 128.4722221992, - "max": 252.52525248, - "median": 126.26262624, - "min": 21.04377104, - "stddev": 49.47687432, - "sum": 2569444443984, - "total": 25694.44443984 - }, - "meta": { - "max_time": "2021-04-24T13:36:48Z", - "min_time": "2021-04-23T13:36:48Z" - } -} -``` - - - - ---- diff --git a/docs/api/console.mdx b/docs/api/console.mdx deleted file mode 100644 index d9e496fde..000000000 --- a/docs/api/console.mdx +++ /dev/null @@ -1,1603 +0,0 @@ ---- -id: console -title: Helium Console API -pagination_label: Helium Console API -sidebar_label: Helium Console API -description: Helium Console API Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api/console ---- - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -The Console API is a set of HTTP Request that allows you to programatically interact with Console. -It's the lowest level building block and is ideal for integrating with back-end services, for -example. - -### Base URL - -``` -https://console.helium.com/ -``` - -### Authentication - -All Console API requests require an API Key which provides access to devices owned by the -**organization** which owns the device. Devices are never associated to a single user, but instead -to an organization. - -To create an account key, go to your [profile](https://console.helium.com/profile) on Helium -Console. From the top right corner, click: `Account -> Profile`. - -From there, you may generate a key for your organization. _The key will only display once._ - -**You must confirm the API key** creation by clicking a link that is emailed to the account that -created the API key. - -From then on, you will want to include the API key in all of your API requests. You do this by -placing your API key in an HTTP header field called "key. - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - ---- - -### Data Credit Balance - -``` -GET https://console.helium.com/api/v1/organization -``` - -##### Response - -200: OK - -```json -[ - { - "dc_balance": 731686 - "id": "07273bc4-4bc9-44ec-b4d5-ad320f162e15", - "name": "Acme", - }, -] -``` - ---- - -### Devices List - -``` -GET https://console.helium.com/api/v1/devices -``` - -##### Response - -200: OK - -```json -[ - Device { - "active": false, - "adr_allowed": null, - "app_eui": "70B3D57ED0008E64", - "app_key": "30EACA8A2CAF0C5315D0E4A1B7F7B55B", - "dev_eui": "008000000401261D", - "cf_list_enabled": null, - "config_profile_id": null, - "dc_usage": 606837, - "id": "747246dd-d9b6-4e68-96c1-2c489ab33280", - "in_xor_filter": true, - "labels": [], - "last_connected": "2022-03-03T22:37:33", - "name": "Basement Temp", - "organization_id": "07273bc4-4bc9-44ec-b4d5-ad320f162e15", - "oui": 1, - "rx_delay": 1, - "total_packets": 303442 - }, - Device { - "active": true, - "adr_allowed": null, - "app_eui": "CE1BAF8A8824FD1D", - "app_key": "2A37E7FACF2F0B7833413E9F8988C4EF", - "dev_eui": "008000000401261D", - "cf_list_enabled": null, - "config_profile_id": null, - "dc_usage": 606925, - "id": "916fc471-87f1-43a8-939e-c36589f33232", - "in_xor_filter": true, - "labels": [ - { - "adr_allowed": null, - "cf_list_enabled": null, - "config_profile_id": null, - "id": "20865d14-bd90-4cbb-80e5-401c2c71fdab", - "name": "Device group", - "rx_delay": null - "last_connected": "2022-03-03T22:37:33", - "name": "Water Level North", - "organization_id": "07273bc4-4bc9-44ec-b4d5-ad320f162e15", - "oui": 1, - "rx_delay": 1, - "total_packets": 303486 - }, -] -``` - ---- - -### Devices by AppEui, AppKey, DevEui - -``` -GET https://console.helium.com/api/v1/devices?app_eui={app_eui}&app_key={app_key}&dev_eui={dev_eui} -``` - -Returns a device descriptor if device is found. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------ | -------- | ----------------------------------------------------------------------------------------------------- | -| dev_eui (required) | _string_ | LoRaWAN Device EUI uniquely identifies a device | -| app_eui (required) | _string_ | LoRaWAN App EUI uniquely identifies the application of the device | -| app_key (required) | _string_ | LoRaWAN App Key is a shared secret key which is used to derive secure sessions via the Join mechanism | - - - - -```json -Device { - app_eui: "70B3D57ED0008E64", - app_key: "30EACA8A2CAF0C5315D0E4A1B7F7B55B", - dev_eui: "008000000401261D", - id: "747246dd-d9b6-4e68-96c1-2c489ab33280", - name: "Basement Temp", - organization_id: "07273bc4-4bc9-44ec-b4d5-ad320f162e15", - oui: 1, -} -``` - - - - ---- - -### Device by UUID - -``` -GET https://console.helium.com/api/v1/devices/:device_id -``` - -Returns a device descriptor if device is found. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------------- | -------- | ------------------ | -| device_id (required) | _string_ | UUID of the device | - - - - -```json -Device { - "adr_allowed":(true/false), - "app_eui": (app_eui), - "app_key": (app_key), - "cf_list_enabled":(true/false), - "dc_usage": (dc_amount_used), - "dev_eui": (dev_eui), - "id": (device_id), - "in_xor_filter":(true/false) - "labels": (labels) - "last_connected": (time_UTC) - "name": (device_name) - "organization_id": (org_id) - "oui": (oui_number) - "total_packets":(packets_sent) -} -``` - - - - ---- - -### Device Events - -``` -GET https://console.helium.com/api/v1/devices/:device_id/events -``` - -Returns the previous 100 events for the device if found. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------------- | -------- | ------------------ | -| device_id (required) | _string_ | UUID of the device | - - - - -```json -Device { -"category": "uplink", - "data": { - "dc": { - "balance": 7944423, - "nonce": 2, - "used": 2 - }, - "devaddr": (devaddr), - "fcnt": 33032, - "hold_time": 30, - "hotspot": { - "channel": 15, - "frequency": 905.2999877929688, - "id": ("hotspot_id"), - "lat": (lat), - "long": (long), - "name": ("hotspot_name"), - "rssi": -57.0, - "snr": 12.800000190734863, - "spreading": "SF9BW125" - }, - "mac": [], - "payload": ("payload"), - "payload_size": 27, - "port": 1 - }, - "description": "Confirmed data up received", - "device_id": ("device_id"), - "frame_down": null, - "frame_up": 33032, - "organization_id": ("org_id"), - "reported_at": "1632352528562", - "router_uuid": ("router_id"), - "sub_category": "uplink_confirmed" -} -``` - - - - ---- - -### Device Integration Events - -``` -GET https://console.helium.com/api/v1/devices/:device_id/events?sub_category=uplink_integration_req -``` - -Returns the previous 10 Integration events for the device if found. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------------- | -------- | ------------------ | -| device_id (required) | _string_ | UUID of the device | - - - - -```json -Device { - "category": "uplink", - "data": { - "integration": { - "id": ("integration_id"), - "name": "azure-int", - "status": "success" - }, - "req": { - "body": { - "app_eui": ("app_eui)", - "dev_eui": ("dev_eui", - "devaddr": ("devaddr"), - "fcnt": 33072, - "hotspots": [ - { - "channel": 12, - "frequency": 904.7000122070313, - "hold_time": 31, - "id": ("hotspot_id)", - "lat": ("lat"), - "long": ("long", - "name": ("hotspot_name"), - "reported_at": 1632353389723, - "rssi": -57.0, - "snr": 12.5, - "spreading": "SF9BW125", - "status": "success" - }, - ], - "id": ("device_id"), - "metadata": { - "adr_allowed": false, - "cf_list_enabled": false, - "multi_buy": 1, - "organization_id": ("org_id") - }, - "name": ("device_name"), - "payload": ("device_payload"), - "payload_size": 27, - "port": 1, - "reported_at": 1632353389723, - "uuid": ("device_id") - }, - "qos": 0 - } - }, - "description": "Request sent to <<\"azure-int\">>", - "device_id": ("device_id"), - "frame_down": null, - "frame_up": null, - "organization_id": ("org_id"), - "reported_at": "1632353390125", - "router_uuid": ("router_id"), - "sub_category": "uplink_integration_req" - }, -} -``` - - - - ---- - -### Create Device - -``` -POST https://console.helium.com/api/v1/devices -``` - -:::info - -This endpoint is disabled for Helium Foundation Console. - -::: - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ---------------------------- | ---------------- | ---------------------------------------- | -| name (required) | _string_ | A human-friendly name for the device | -| app_eui (required) | _string_ | LoRaWAN Application EUI | -| app_key (required) | _string_ | LoRaWAN Application Key | -| dev_eui (required) | _string_ | LoRaWAN Device EUI | -| config_profile_id (optional) | _string_ | Config profile uuid to attach | -| label_ids (optional) | Array of strings | Array of label uuids to attach to device | - - - - -201: created - - - - ---- - -### Create Multiple Devices - -``` -POST https://console.helium.com/api/v1/devices -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ------------------ | ---------------- | ---------------------------------------------------- | -| devices (required) | Array of objects | Array of up to 1,000 device objects as defined below | - -_Device Object_ - -| Key | Value Type | Description | -| ---------------------------- | ---------------- | ---------------------------------------- | -| name (required) | _string_ | A human-friendly name for the device | -| app_eui (required) | _string_ | LoRaWAN Application EUI | -| app_key (required) | _string_ | LoRaWAN Application Key | -| dev_eui (required) | _string_ | LoRaWAN Device EUI | -| config_profile_id (optional) | _string_ | Config profile uuid to attach | -| label_ids (optional) | Array of strings | Array of label uuids to attach to device | - - - - -200: ok - -```json -{ - "failure": [ - { - "app_eui": "2111111111111111", - "app_key": "21111111111111111111111111111111", - "dev_eui": "2111111111111111", - "error": "name: Name cannot be blank", - "organization_id": "b31295c0-7164-4f45-b634-d21d498737cd", - "oui": 1 - } - ], - "success": [ - { - "app_eui": "1111111111111111", - "app_key": "11111111111111111111111111111111", - "config_profile_id": null, - "dev_eui": "1111111111111111", - "id": "c13e435e-a122-44c1-8ebb-882d5cf84e8c", - "labels": [], - "name": "Test 1" - } - ] -} -``` - - - - ---- - -### Delete Device by UUID - -``` -DELETE https://console.helium.com/api/v1/devices/:id -``` - -Deletes device record by UUID. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------- | -------- | -------------------------------- | -| id (required) | _string_ | UUID of the device to be deleted | - - - - -200: OK - -``` -Device deleted -``` - - - - ---- - -### Labels - -``` -GET https://console.helium.com/api/v1/labels -``` - -Returns a list of label descriptors associated with the organization. - -##### Response - -200: OK - -```json -[ - Label { - id: "20515fce-2f7c-4025-8841-4be47cb9ec3c", - name: "Test LoRaWAN", - }, - Label { - id: "d20d5d32-f699-40a7-a5a7-b9a49dfe2b4a", - name: "AWS", - }, - Label { - id: "a332bb1e-888e-43d9-ad38-f4043fff791f", - name: "RequestBinDownlink", - }, - Label { - id: "19bee2e7-b222-461f-a271-15b3c52d5532", - name: "MQTT-Test", - }, -] -``` - ---- - -### Create Label - -``` -POST https://console.helium.com/api/v1/labels -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ---------------------------- | -------- | ------------------------------------ | -| name (required) | _string_ | A human-friendly name for the device | -| config_profile_id (optional) | _string_ | Config profile uuid to attach | - - - - -201: created - - - - ---- - -### Delete Label - -``` -DELETE https://console.helium.com/api/v1/labels/:label_id -``` - -Delete a device label, along with all of its device links. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------- | -------- | ---------------------------------------- | -| label_id (required) | _string_ | The UUID of the label being searched for | - - - - -200: OK - -```json -Label deleted -``` - -404: Not Found - -```json -{ "errors": { "error": ["Label not found"] } } -``` - - - - ---- - -### Search for Label - -``` -GET https://console.helium.com/api/v1/labels/:label_id -``` - -Search for a label by UUID. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------- | -------- | ------------- | -| label_id (required) | _string_ | UUID of label | - - - - -200: OK - -```json -{ - "id": "868ea783-f252-4fc4-b724-a155680c0bc9", - "multi_buy": 1, - "name": "Blue Label" -} -``` - -404: Not Found - -```json -{ "errors": { "error": ["Label not found"] } } -``` - - - - -``` -GET https://console.helium.com/api/v1/labels -``` - -Search for label by name. - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| --------------- | -------- | ------------- | -| name (required) | _string_ | name of label | - - - - -200: OK - -```json -{ - "id": "868ea783-f252-4fc4-b724-a155680c0bc9", - "multi_buy": 1, - "name": "Blue Label" -} -``` - -404: Not Found - -```json -{ "errors": { "error": ["Label not found"] } } -``` - - - - ---- - -### Add Device Label - -``` -POST https://console.helium.com/api/v1/devices/:device_id/labels -``` - -Add Device to Label - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | your API key | -| content-type (required) | _string_ | application/json | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------------- | -------- | -------------- | -| device_id (required) | _string_ | UUID of device | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ---------------- | -------- | ------------- | -| label (required) | _string_ | UUID of label | - - - - -200: OK - -```json -Device added to label successfully -``` - - - - ---- - -### Remove Device Label - -``` -DELETE https://console.helium.com/api/v1/devices/:device_id/labels/:label_id -``` - -Remove Device Label - - - - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------------- | -------- | -------------- | -| device_id (required) | _string_ | UUID of device | -| label_id (required) | _string_ | UUID of label | - - - - -200: OK - -```json -Device removed from label successfully -``` - - - - ---- - -### Create a Prebuilt Integration - -Create prebuilt integration for integration providers planning to offer connectivity as a service. - -``` -POST https://console.helium.com/api/v1/integrations/prebuilt -``` - -Creates a device with corresponding name, Application EUI, Application Key, and Device EUI. - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ---------------- | -------- | -------------------------------------------------------------------------------- | -| token (required) | _string_ | Your token, authorization key, uplink secret depending on pre-built integration. | -| name (required) | _string_ | A unique name for the Integration | -| type (required) | _string_ | “akenza” “ubidots” “tago” “datacake” | - - - - -201: Created - -``` -{ - "devices": [], - "id": "8bcf235a-0ee7-4e74-9856-e07c13a863b6", - "labels": [], - "name": "name" -} -``` - - - - ---- - -### Create a Custom HTTP Integration - -``` -POST https://console.helium.com/api/v1/integrations -``` - -Creates a custom HTTP integration. Use the Console UI for JSON message templates. - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | Your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| --------------------- | -------- | -------------------------------------------------------------------- | -| name (required) | _string_ | A unique human-friendly name | -| type (required) | _string_ | “http” | -| endpoint (required) | _string_ | endpoint | -| method (required) | _string_ | HTTP method | -| headers (optional) | _map_ | Map of header keys and values { “content-type”: “application/json” } | -| url_params (optional) | _map_ | Map for payload interpolation { "id": "{{device.id}}"} | - - - - -201: Created - -``` -{ - "devices": [], - "id": "8bcf235a-0ee7-4e74-9856-e07c13a863b6", - "labels": [], - "name": "name", - "type": "http" - "credentials": { … } -} -``` - - - - ---- - -### Create a Custom MQTT Integration - -``` -POST https://console.helium.com/api/v1/integrations -``` - -Creates a custom MQTT integration. - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | Your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ------------------------- | -------- | ---------------------------- | -| name (required) | _string_ | A unique human-friendly name | -| type (required) | _string_ | “mqtt” | -| endpoint (required) | _string_ | endpoint | -| uplink_topic (required) | _string_ | Uplink topic | -| downlink_topic (required) | _string_ | Downlink topic | - - - - -201: Created - -``` -{ - "devices": [], - "id": "8bcf235a-0ee7-4e74-9856-e07c13a863b6", - "labels": [], - "name": "name", - "type": "mqtt" - "credentials": { … } -} - -``` - - - - ---- - -### Create a Custom Azure IoT Hub Integration - -``` -POST https://console.helium.com/api/v1/integrations -``` - -Creates a custom Azure IoT Hub integration. - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | Your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ---------------------------- | -------- | ---------------------------- | -| name (required) | _string_ | A unique human-friendly name | -| type (required) | _string_ | “azure” | -| azure_policy_name (required) | _string_ | Azure IoT Hub policy name | -| azure_hub_name (required) | _string_ | Azure IoT Hub name | -| azure_primary_key (required) | _string_ | Azure IoT Hub primary key | - - - - -201: Created - -``` -{ - "devices": [], - "id": "8bcf235a-0ee7-4e74-9856-e07c13a863b6", - "labels": [], - "name": "name", - "type": "azure" - "credentials": { … } -} -``` - - - - ---- - -### Create a Custom AWS IoT Core Integration - -``` -POST https://console.helium.com/api/v1/integrations -``` - -Creates a custom AWS IoT Core integration. - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | Your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ------------------------- | -------- | ---------------------------- | -| name (required) | _string_ | A unique human-friendly name | -| type (required) | _string_ | “aws” | -| topic (required) | _string_ | AWS topic | -| aws_access_key (required) | _string_ | AWS access key | -| aws_secret_key (required) | _string_ | AWS secret key | -| aws_region (required) | _string_ | AWS region | - - - - -201: Created - -``` -{ - "devices": [], - "id": "8bcf235a-0ee7-4e74-9856-e07c13a863b6", - "labels": [], - "name": "name" - "type": "aws" - "credentials": { … } -} - -``` - - - - ---- - -### Delete an Integration - -``` -DELETE https://console.helium.com/api/v1/integrations/:integration_id -``` - -Delete an Integration along with any links to labels. - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------------- | -------- | ---------------------------- | -| integration_id (required) | _string_ | UUID for removed integration | - - - - -200: OK - -``` -Integration { - id: "868ea783-f252-4fc4-b724-a155680c0bc9", - name: "Terry Fox", - } -``` - -404: Not Found - -``` -{ "errors": { "error": ["Integration not found"] } } -``` - - - - ---- - -### List Integrations - -``` -GET https://console.helium.com/api/v1/integrations/ -``` - -Returns a list of integrations associated with the organization. - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - - - - -200: OK - -``` - Integration { - id: "20515fce-2f7c-4025-8841-4be47cb9ec3c", - name: "Terry Fox" - labels: [], - devices: [], - }, - Integration { - id: "d20d5d32-f699-40a7-a5a7-b9a49dfe2b4a", - name: "Tommy Douglas", - labels: [], - devices: [], - }, -``` - - - - ---- - -### Search for an Integration by UUID - -``` -GET https://console.helium.com/api/v1/integrations/:integration_id -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------------- | -------- | ------------------- | -| integration_id (required) | _string_ | UUID of integration | - - - - -200: OK - -``` -Integration { - id: "868ea783-f252-4fc4-b724-a155680c0bc9", - name: "Terry Fox", - labels: [], - devices: [], -}, -``` - -404: Not Found - -``` -{ "errors": { "error": ["Integration not found"] } } -``` - - - - ---- - -### Search for an Integration by Name - -``` -GET https://console.helium.com/api/v1/integrations?name=your_integration_name -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Query Parameters_ - -| Parameter Name | Type | Description | -| --------------- | -------- | ------------------- | -| name (required) | _string_ | name of integration | - - - - -200: OK - -``` -Integration { - id: "868ea783-f252-4fc4-b724-a155680c0bc9", - name: "Terry Fox", - labels: [], - devices: [], -}, -``` - -404: Not Found - -``` -{ "errors": { "error": ["Integration not found"] } } -``` - - - - ---- - -### View all Flows for an Integration - -``` -GET https://console.helium.com/api/v1/flows?integration_id=your_integration_id -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Query Parameters_ - -| Parameter Name | Type | Description | -| ------------------------- | -------- | ------------------- | -| integration_id (required) | _string_ | UUID of integration | - - - - -200: OK - -``` -[ -{ - "device_id": null, - "function_id": "7591901a-1299-4893-b0b5-65786c481bcc", - "id": "1f99c35c-20c5-42f6-b3e4-984bba68ade1", - "integration_id": "c23f1419-47af-4673-931a-7acdae1ddee5", - "label_id": "d7c095cb-4923-42c1-967a-5574eedc2dc4", - "organization_id": "e9ea354a-cf4d-492a-b332-3d2ee4fe177e" - }, -{ - "device_id": null, - "function_id": "7591901a-1299-4893-b0b5-65786c481bcc", - "id": "1f99c35c-20c5-42f6-b3e4-984bba68ade1", - "integration_id": "c23f1419-47af-4673-931a-7acdae1ddee5", - "label_id": "d7c095cb-4923-42c1-967a-5574eedc2dc4", - "organization_id": "e9ea354a-cf4d-492a-b332-3d2ee4fe177e" - } - -] -``` - - - - ---- - -### Create a Flow for an Integration - -Create a prebuilt integration for partners providing a connectivity as a service solution. - -``` -POST https://console.helium.com/api/v1/flows -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| ----------------------- | -------- | ---------------- | -| key (required) | _string_ | your API key | -| content-type (required) | _string_ | application/json | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ------------------------------- | -------- | ------------------- | -| integration_id (required) | _string_ | UUID of integration | -| label_id / device_id (required) | _string_ | UUID | -| function_id (optional) | _string_ | UUID | - - - - -200: OK - -Flow with integration created successfully - -``` -{ - "devices": [], - "id": "8bcf235a-0ee7-4e74-9856-e07c13a863b6", - "labels": [], - "name": "name" -} - -``` - - - - ---- - -### Delete flow - -``` -DELETE https://console.helium.com/api/v1/flows/:flow_id -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------ | -------- | ------------ | -| flow_id (required) | _string_ | UUID of flow | - - - - -200: OK - -``` -Flow deleted successfully -``` - - - - ---- - -### Update Device Config Profile - -``` -PUT https://console.helium.com/api/v1/devices/:device_id -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------------- | -------- | -------------- | -| device_id (required) | _string_ | UUID of device | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ---------------------------- | --------------- | ------------------------------------------------------ | -| config_profile_id (required) | _string / null_ | Config profile uuid to attach or set to null to remove | - - - - -200: OK - - - - ---- - -### Update Label Config Profile - -``` -PUT https://console.helium.com/api/v1/labels/:label_id -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------- | -------- | ------------- | -| label_id (required) | _string_ | UUID of label | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ---------------------------- | -------- | ------------------------------------------------------ | -| config_profile_id (required) | _string_ | Config profile uuid to attach or set to null to remove | - - - - -200: OK - - - - ---- - -### Update Device Active Status - -``` -PUT https://console.helium.com/api/v1/devices/:device_id -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| -------------------- | -------- | -------------- | -| device_id (required) | _string_ | UUID of device | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ----------------- | -------- | ----------- | -| active (required) | _string_ | boolean | - - - - -200: OK - - - - ---- - -### Update Devices Active Status - -``` -PUT https://console.helium.com/api/v1/devices/active?dev_eui=your_dev_eui -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Query Parameters_ - -| Parameter Name | Type | Description | -| ------------------ | -------- | -------------- | -| dev_eui (required) | _string_ | Device dev_eui | -| app_eui (optional) | _string_ | Device app_eui | -| app key (optional) | _string_ | Device app_key | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ----------------- | -------- | ----------- | -| active (required) | _string_ | boolean | - - - - -200: OK - - - - ---- - -### Update Devices attached to label Active Status - -``` -PUT https://console.helium.com/api/v1/labels/:label_id/active -``` - - - - -_Headers_ - -| Parameter Name | Type | Description | -| -------------- | -------- | ------------ | -| key (required) | _string_ | your API key | - -_Path Parameters_ - -| Parameter Name | Type | Description | -| ------------------------------ | -------- | ----------- | -| label_id (required) (required) | _string_ | Label uuid | - -_Body Parameters_ - -| Parameter Name | Type | Description | -| ----------------- | -------- | ----------- | -| active (required) | _string_ | boolean | - - - - -200: OK - - - diff --git a/docs/api/home.mdx b/docs/api/home.mdx deleted file mode 100644 index 188780ec0..000000000 --- a/docs/api/home.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: home -title: Helium APIs -pagination_label: Helium APIs -sidebar_label: Helium APIs -description: Helium APIs Documentation -image: https://docs.helium.com/img/link-image.png -slug: /api ---- - -The Helium Network currently exposes the following APIs: - -- [Console API](/api/console) - Provides programatic access to your organization's sensor data on - Helium console instances. - -All other data can be accessed through [Oracles](/oracles/). - -Note: the free-to-use Foundation Console [console.helium.com](https://console.helium.com) does not -support the Console API. - -Console providers that support the Console API are listed at -[Console Hosting Providers](/use-the-network/console/hosting-providers). diff --git a/docs/archive/helium-hotspot-app.mdx b/docs/archive/helium-hotspot-app.mdx deleted file mode 100644 index dc73f1a71..000000000 --- a/docs/archive/helium-hotspot-app.mdx +++ /dev/null @@ -1,136 +0,0 @@ ---- -id: helium-hotspot-app -title: Helium Hotspot App -pagination_label: Helium Hotspot App -sidebar_label: Helium Hotspot App -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /mine-hnt/helium-hotspot-app ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -Nova Labs (formerly Helium Systems, Inc.) manufactured the first set of Hotspots on the Network. -Nova Labs no longer manufacturers Hotspots, but there is now an extensive -[list of manufacturers who sell approved Hotspots](/hotspot-makers). - -:::tip Wallet Functionality - -Use the [Helium Wallet app](/wallets/helium-wallet-app) to interact with tokens, take part in -governance, and all other non Hotspot management functions. - -::: - -## Helium Hotspot App Overview - -The Helium Hotspot apps for [iOS](https://apps.apple.com/us/app/helium-hotspot/id1450463605) and -[Android](https://play.google.com/store/apps/details?id=com.helium.wallet) include everything needed -to on-board and maintain an Original Helium Hotspot or FreedomFi Hotspot. - -The app can be used to: - -- Add Nova Labs or FreedomFi Hotspot to the Helium Network -- Set or Modify the Hotspot's location -- Configure the Wi-Fi connection of the Hotspot - ---- - -## App Tabs - -There are four tabs on the Helium Hotspot App interface, tab the buttons below to see more -information on each Tab. - - - - - -
-
-
- -
-
-

The Hotspot tab shows the Hotspot(s) held by the signed in Wallet.

-

- Tap on each one to view details, adjust location and update wifi on the{' '} - Hotspot Details screen. -

-

Use the Plus Sign Icon to onboard new Nova Labs or FreedomFi Hotspots.

-
-
-
- - - - - -
-
-
- -
-
-

- The Hotspot Details screen is used to assert the location for a Hotspot or transfer the - Hotspot to another Wallet. -

-

- Use the Gear Icon to adjust Update the Wifi connection and run diagnostics on the Hotspot. -

-
-
-
- - - - - -
-
-
- -
-
-

- Select the Model of the Hotspot to be added and follow the prompts on screen to onboard a - new Hotspot to the Helium Network. -

-
-
-
- - - - - -
-
-
- -
-
-

- The Settings tab allows the user to configure apps PIN settings, set the app Language, - reveal the 12 security words, Export the Private Key and view the current app version.{' '} -

-

- Users can also copy the wallet's Helium Wallet address and coresponding Solana Wallet - address. -

-
-
-
- - - - - ---- - -## Original Helium Hotspot Warranty - -The Helium Hotspot limited warranty is only valid for the original sale to the original owner. -Resold Helium Hotspots from anyone other than Helium directly are not under any warranty whatsoever. -Please refer to their documentation for any authorized reseller policy. diff --git a/docs/archive/improving-poc.mdx b/docs/archive/improving-poc.mdx deleted file mode 100644 index 189b1ad62..000000000 --- a/docs/archive/improving-poc.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: improving-poc -title: Improving Proof-Of-Coverage -pagination_label: Improving PoC -sidebar_label: Improving Proof-Of-Coverage -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /troubleshooting/improving-poc ---- - -Has your Hotspot been unable to complete challenges on the network? If there are known Hotspots in -the neighborhood, they just may not be able to hear you because of interference or its position is -poor. - -## There are a few ways to try and address this. - -1. Moving the Hotspot to a different window, or higher floor if possible. Metal window screens can - also affect RF, so if those can be removed it may improve the signal. -2. Placing the Hotspot outdoors. Some building materials in the surrounding walls can block RF. For - example, Stucco buildings have a layer of metal wire, so placing at least the antenna outdoors - would help with that. Look for IP-66 Waterproof cases if you’re intending to place the Hotspot - outside. You can purchase these from mouser.com, amazon.com, or most hardware stores. -3. Some newer high-rise buildings have a UV protective layer on the outside of the building glass - that is known to block and interfere with radio signals. If this occurs, you could try moving the - Hotspot outside (in a weatherproof case), or purchase an outdoor antenna so it can bypass the - glass. diff --git a/docs/archive/network-troubleshooting.mdx b/docs/archive/network-troubleshooting.mdx deleted file mode 100644 index 653edbb3b..000000000 --- a/docs/archive/network-troubleshooting.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -id: network-troubleshooting -title: Network Troubleshooting -pagination_label: Network Troubleshooting -sidebar_label: Network Troubleshooting -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /troubleshooting/network-troubleshooting ---- - -# Network Troubleshooting - -For Original Helium Hotspots, firmware updates are pushed over port 443, so that port should always -be open Outbound. You should check with the Maker to see which port they use to push firmware -updates to ensure they can be received. - -Please also verify with the Maker if they require any specific ports for connecting to the Hotspots -for support. - ---- - -## Internet Connection - -Helium Hotspots may not work if the Hotspot is behind a firewall or uses an incompatible NAT type. -Other times connection issues may be caused by a router configuration or the internet is offline. - -:::info - -If none of the below resolve Hotspot connection issues, please visit the -[#hotspot-issues](discord://discord.com/channels/404106811252408320/813976183519445084) channel in -the Helium Discord. - -::: - -Check the internet connection confirm that the connection to the Internet from the Hotspot's -location using a home computer or phone on the same network. If other devices can not connect to the -Internet, contact the Internet Service Provider for additional assistance. - -### Ethernet Connections - -Check the cables if using Ethernet, make sure the Ethernet cable is securely plugged into the -Hotspot and internet provider modem. Ethernet cables can fail from time to time, so trying a -different cable may correct some problems. - -### Wifi Connections - -If using Wi-Fi, confirm that the WEP or WPA security password. Contact the manufacturer of the -equipment directly if unsure how to operate or access the wireless modem. - ---- - -## Modem or Router Issues - -If other devices are able to connect to the internet, power cycle the router. Unplug the Hotspot and -router from power for 2 minutes. Then, plug them back in and recheck the Internet connection. diff --git a/docs/blockchain/blockchain-primitives.mdx b/docs/blockchain/blockchain-primitives.mdx deleted file mode 100644 index 7e2d7f5ad..000000000 --- a/docs/blockchain/blockchain-primitives.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: blockchain-primitives -title: Helium Blockchain Primitives -pagination_label: Helium Blockchain Primitives -sidebar_label: Helium Blockchain Primitives -description: Helium Blockchain Primitives -image: https://docs.helium.com/img/link-image.png -slug: /blockchain/blockchain-primitives ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -Below are some of the larger components and concepts of the Helium blockchain. - -### Blocks - -Blocks are used to record the most recent set of transactions in the Helium blockchain. Blocks are -mined based on time, as defined in the `block_time` chain variable. The current target block time is -`60000` milliseconds (or 60 seconds). During any given epoch, the most recent block consists of: - -- Block Version -- Block Height -- Previous Block Hash -- Transactions (stored as a Merkle hash) -- Threshold signature from the current consensus group - -The easiest way to see the blocks being mined is with the -[Helium Blockchain Explorer](https://explorer.helium.com/). The -[Helium Mobile App](https://helium.com/app) also shows block details. Developers can also use the -Helium blockchain API to access all blockchain transactions and metadata. - - - -### Chain Variables - -Chain Variables, often referred to as `chain vars`, are a series of configuration settings for the -Helium blockchain. Chain Variables can be used to change things like target block time, target epoch -time, the minimum number of targets in a PoC Challenge, and much more. Chain Variables can be -altered by submitting a transaction containing the chain variable to be changed, its new value, and -a signature of the chain variable master key. - -A full list of chain vars and their current values -[can be found here](https://helium.plus/chain-vars). - -### Accounts, Wallets, and Keys - -The Helium blockchain uses an account-based system for wallets and balances (similar to Ethereum and -others) as opposed to a UTXO-based ledger like Bitcoin blockchain. Users have several options for -creating Helium wallets and managing their private keys: - -- If you’re using the [Helium Mobile Wallet](https://helium.com/app) (iOS, Android), your private - key is encrypted locally (and can be recreated on another mobile device using the 12 word - passphrase generated when your wallet was first created); -- Using the [Helium CLI Wallet](https://github.com/helium/helium-wallet-rs), users are responsible - for creating, storing, and securing a wallet’s private key and associated passphrase; - -Both the Helium Mobile Wallet and the CLI Wallet create and use keys based on the -[ed25519 public key signature system](https://ed25519.cr.yp.to/). The CLI can also support NIST -p-256 keys. And the Helium blockchain supports both key types. - -To learn more about existing wallet solutions, check out our [section on wallets](/wallets). diff --git a/docs/blockchain/blockchain.mdx b/docs/blockchain/blockchain.mdx deleted file mode 100644 index ad222d147..000000000 --- a/docs/blockchain/blockchain.mdx +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: blockchain -title: Blockchain -pagination_label: Blockchain -sidebar_label: Introduction -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /blockchain ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -
-
-
-
- -
-

The Helium Blockchain

-

- The Helium Blockchain is a new blockchain built from the ground up to incentivize the - creation of decentralized, public wireless networks. -

- -
-
-
-
-
- -
-
-
-

Introduction

-
-
-

- The Helium Blockchain is based on a new, novel work algorithm called Proof of Coverage - (PoC), and rewards miners in $HNT, the native token of the Helium blockchain. Officially - launched on July 29, 2019, the Helium Blockchain powers{' '} - - the largest, public, decentralized LoRaWAN Network in the world - - . -

-

- If you are a developer and interested in contributing, or simply just interested in learning - more, join us in the #blockchain-development channel on{' '} - our Discord. -

-
-
-
Quick Links
- - Blockchain Primitives - - - Mining and Rewards - - - Proof of Coverage - - - Packet Purchasing - - - The Helium Token - ($HNT) - - - The IOT Network Token - ($IOT) - - - The Mobile Network - Token ($MOBILE) - - - Transaction Fees - -
-
-
diff --git a/docs/blockchain/mining.mdx b/docs/blockchain/mining.mdx deleted file mode 100644 index d97e57a89..000000000 --- a/docs/blockchain/mining.mdx +++ /dev/null @@ -1,195 +0,0 @@ ---- -id: mining -title: Mining and Token Rewards -pagination_label: Mining and Token Rewards -sidebar_label: Mining and Token Rewards -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /blockchain/mining ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -While there's no exact formula for calculating how much HNT you'll earn over a given period, there -are some higher-level concepts, design elements, and rules to keep in mind that will help better -explain what you might earn and why. This section covers these, as well as some mining and token -reward basics. - -## How Do Hotspots Earn Helium Tokens? - -The Helium blockchain rewards Hotspots for providing wireless coverage and verifying the Helium -Network. Hotspots are rewarded in Helium Token, HNT. After the Solana Migration, all LoRaWAN -Hotspots will mine IOT, and HNT will continue to be mined into the DAO Treasury. IOT Holders will be -able to redeem their IOT for HNT equivalently, per the redemption ratio. The redemption ratio is set -at the time of subDAO Treasury creation. - -Every epoch, the current consensus group mines approximately 30 blocks on the blockchain. In each -block, Hotspots perform various types of work and are awarded according to the following -distribution: - -| Reward Type | Chain Variable | Description | -| :-------------------- | :------------------------ | :-------------------------------------------------------------------------------------------------------------- | -| PoC Beaconers | `poc_challengees_percent` | Awarded to any Hotspot that successfully transmits a PoC beacon packet. | -| Witnesses | `poc_witnesses_percent` | Distributed to selected Hotspots that witness a PoC beacon packet. | -| Security | `securities_percent` | Awarded to Network investors who hold Security Tokens. | -| Network Data Transfer | `dc_percent` | Distributed each epoch to Hotspots that route LoRaWAN sensor data for sensors on the Network during that epoch. | - -**_Do I Have To Actively Participate to Earn Rewards Once My Hotspot is Deployed?_** - -No. Once your Hotspot is completely deployed and onboarded to the Helium blockchain, you as the -owner are not required to do anything else to earn HNT. Your Hotspot will perform all of the above -activities on its own while it runs. - -## Target HNT Production Per Epoch - -As of August 1, 2021 (the most recent halving), the target production rate for new HNT minted per -month is `2,500,000`. This means that, if the blockchain performs as designed, it will produce -`2,500,000` HNT per month. This target rate is based on the following two parameters, as defined in -their specific chain variables: - -- Target **block time** is `60` seconds. -- Target **epoch size** is `30` blocks. - -Recall that, in the Helium blockchain, blocks contain some number of individual transactions, and -epochs are comprised of all the blocks mined by the current Consensus Group since the last epoch. - -So, if the Network achieves its target block time of `60` seconds, and target epoch of `30` blocks, -the blockchain will produce `2,500,000` HNT per month. Per epoch, this equals roughly `1736.1111` -HNT. The math for this is as follows: - -- `(43200 minutes per month / 30 minutes per epoch) = 1440 epochs per month` -- `(2500000 tokens minted per month / 1440 epochs per month) = 1736.1111 HNT per epoch` - -### What Are The Current Block and Epoch Times? - -At any point, you can go to the [Helium blockchain Explorer](https://explorer.helium.com/) to view -recent block and epoch statistics, past HNT production numbers, and much more. - -## HNT Distributions Per Epoch - -As calculated above, the target HNT per epoch is approximately `1736.1111`. The next logical -question is, "Where does all this HNT go?" Let's take a look. - -Below are the mining rewards per epoch as of August 1, 2022. For every complete epoch, marked by the -election of a new Consensus Group, all the HNT produced are distributed over the following reward -types: - -| Reward Type | Percentage | HNT Earned by Reward Type | -| :-------------------- | :--------------- | :------------------------ | -| PoC Beaconers | 4.73% - 12.665% | 82.1181 - 219.7049 | -| Witnesses | 18.92% - 49.345% | 328.4722 - 856.6840 | -| Consensus Group | 6% | 104.1667 | -| Security Tokens | 32% | 555.5556 | -| Network Data Transfer | _Up to 37.50%_ | _Up to 651.0417_ | -| **Total** | **100%** | **1736.1111** | - -**Rewards Change Over Time** - -In the above table, you can see the maximum allotted rewards per reward type following HIP 10 -(described below). If you want to see the current reward type percentage, you can always query the -[Chain Variables API](/api/blockchain/chain-variables). The next maximum allotted rewards change is -currently scheduled for **August 1, 2023** and will be updated along with changes related to the -havening to maintain max HNT supply. - -## HIP-10 and Variable HNT Rewards for Network Data Transfer - -As noted above, -[HIP-10 was activated on August 24th, 2020](https://github.com/helium/HIP/blob/master/0010-usage-based-data-transfer-rewards.md). - -It ensures that HNT is rewarded at a rate of 1:1 to the amount of Data Credits (DCs) routed by any -given Hotspot per epoch. In doing so, the Network Data Transfer reward is proportional to the DC -spent in that epoch. This proportional relationship between Network Data Transfer reward type and DC -is capped at 37.50% (651.0417 HNT). Therefore, if the DC burned doesn't equal the value of -`651.0417` HNT, the remaining HNT is redistributed to the Proof of Coverage (PoC) rewards groups -pro-rata. - -Here are a few examples to illustrate how this works in practice: - -**Example 1: DC Burn does not exceed 37.50% HNT** - -- In a given epoch, `8,000,000` DCs are transferred across the network -- The HNT Oracle Price is `$8.00` -- In this scenario, the total HNT value of DC transferred in this epoch is `10 HNT`. This - calculation is:`(8,000,000 DC * $0.00001 / $8.00 HNT Oracle Price)` -- These `10 HNT` would be split proportionally to the Hotspots that did the work routing packets at - the 1:1 rate. -- The remaining `641.0417` from the Network Data Transfer reward would be distributed by weight - among the Witnesses and Beaconers. - - `128.2083` to the Beaconer group => `4.73/(4.73+18.92) = 20%` - - `512.8333` to the Witness group => `18.92/(4.73+18.92) = 80%` - -**Example 2: DC Burn exceeds 37.50% HNT** - -- In a given epoch, `800,000,000` DCs are spent on data transfer across the network -- The HNT Oracle Price is `$8.00` - -In this scenario, the total HNT value of DC transferred in this epoch is `1000 HNT`. This -calculation is:`(800,000,000 DC * $0.00001 / $8.00 HNT Oracle Price)` - -- Because the Network DC burn exceeded the `651.0417` available to the Network Data Transfer reward, - all Hotspots that did the work over this epoch will split the full `1000 HNT` proportionally. - -### Additional Notes on Reward Types and Payouts - -- All Hotspots participating in PoC, including `Beaconers` and `Witnesses` will earn rewards - proportional to how many events they participated in out of the total number of events per epoch. -- All Hotspots participating in `Network Data Transfer` will earn rewards proportional to their - share of the total data transfer in that epoch, as shown above. -- Hotspots can earn one or more reward types during any given epoch. -- `PoC Beacon` and `Witness` reward types get distributed in the epoch that includes the - corresponding PoC receipt. -- A Hotspots can earn more than one `PoC Beacon` and `Witness` reward per epoch. - -## HNT Proration and Slow Block Times - -The Helium blockchain is still new and growing quickly, so there are bugs to be squashed and -optimizations to be made. Target block and epoch times can be difficult to attain consistently. To -account for this, the Helium blockchain uses something called `proration` to ensure that the target -of `2,500,000` is achieved even if block and epoch times aren't on target. - -**Target HNT Depends on Blocks, Not Clocks** - -It's easiest to think of target HNT production over one month. If the blockchain performs on target, -resulting in roughly 1440 epochs per month, then `2,500,000` new HNT will be produced. "One month" -is a period of time measured by a clock. However, under the hood, we use block time, and the -resulting epochs, to mark HNT production against our target. So when blocks are slow, HNT production -is reduced proportionally. - -### What Happens to HNT When Block Times are Slow? - -Occasionally, due to the rapid growth of the network, there can be less-than-optimal block times. -This results in slower epochs. When this happens the blockchain will produce **less** HNT over the -same period of time. This may seem counterintuitive. _Shouldn't the blockchain produce more HNT when -block times are slower to ensure the `2,500,000` per month target is hit?_ No. Again, think blocks, -not clocks. Here's a step-by-step example to make it clearer: - -- Let's assume for a given `60` minute period, the average block time was `120` seconds (which is - double the target of `60` seconds). -- This would mark `30` blocks over the `60` minute period, conclude an epoch, and result in HNT - rewards being distributed. -- As with any epoch, we would distribute the target of (approximately) `1736.1111` HNT. -- However, since this epoch took twice as long as normal - `60` minutes versus `30` minute target - - the blockchain essentially distributes HNT at **half the normal rate**. - -### When Block Times Slow Down, Everyone Earns Less - -The most important takeaway here is that, when block times slow and HNT production is reduced, -everyone participating in the Network - Witnesses, Security Token Holders, etc. - **is impacted -equally** (except for Consensus Group members; more on this below). So, although it's annoying that -the effective rate of HNT may have dropped over a given period of time, know that you're not the -only one earning less. And this is by design. - -### Consensus Groups and Slow Block Times - -The only group that doesn't see its HNT reduced per epoch when blocks are slow is the Consensus -Group. Currently, there are 43 members of each Consensus Group, sharing 6% of the HNT produced per -epoch. - -This amount stays fixed while every other category of HNT payout is prorated so that members of the -Consensus Groups are incentivized to keep elections fast. Otherwise, a malicious Consensus Group -member might be inclined to prolong elections. This could be done, for example, to prevent a -subsequent election, thus ensuring current membership in the Consensus Group stays intact. By -distributing a fixed amount of HNT per `30` block epoch (as opposed to prorating payouts), we remove -the incentive to disrupt elections. diff --git a/docs/blockchain/packet-purchasing.mdx b/docs/blockchain/packet-purchasing.mdx deleted file mode 100644 index c0ba38738..000000000 --- a/docs/blockchain/packet-purchasing.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -id: packet-purchasing -title: Packet Purchasing -pagination_label: Packet Purchasing -sidebar_label: Packet Purchasing -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /blockchain/packet-purchasing ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -A trustless and decentralized way to allow coverage providers and coverage users to exchange value -is core to the Helium Network. - -Packet purchasing is implemented on the Helium Blockchain with two specific primitives: - -- Organizationally Unique Identifiers -- State Channels - -## Organizationally Unique Identifier - -Organizationally Unique Identifiers (OUIs) are registered identities on the Helium Blockchain. To -send and receive packets to an end-device, a network user needs to be serviced an OUI. This can be -their own OUI or one operated by a third party, such as [Console](/use-the-network/console) operated -by Helium Foundation. - -An OUI has some specificities related to LoRaWAN and packet routing, -[documented here](/lorawan-on-helium#the-oui), but with respect to the blockchain, what's important -is that -[only libp2p addresses registered as endpoints for the OUI](https://github.com/helium/proto/blob/master/src/blockchain_txn_oui_v1.proto#L6) -may open and close state channels on behalf of an OUI. - -For example, -[this account](https://explorer-old.helium.com/accounts/13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc) -[purchased the first OUI](https://explorer-old.helium.com/txns/6ACW9A5Hj3KDnOJELWAvAVG3yM71OpNAYpdAPM3ti1A) -on the Helium Blockchain. The address `112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE` -operates the OUI on behalf of the owner. You can monitor its activity -[here](https://explorer-old.helium.com/accounts/14oSuAgRmAFPFPZRY1MUwir5AJSLGkaXHzuSZJ92BuYCfLMN1Et). - -OUIs are purchased (see current -[fee schedule](/blockchain/transaction-fees#transaction-fee-schedule)) and numbered in incrementing -order. You can query the API for a list of existing OUIs using -[the following endpoint](/api/blockchain/ouis#list-ouis). - -## State Channels - -State channels are side-chains opened by OUI operators (any of the libp2p addresses registered to -the OUI). With an -[`state_channel_open`](https://github.com/helium/proto/blob/master/src/blockchain_txn_state_channel_open_v1.proto) -transaction, the operator stakes two times the amount of Data Credits (DC) available to be spent in -the channel. In addition, the amount of blocks until channel expiration is configured. - -Once a state channel is opened, hotspots and OUIs operators are able to transact within the channel. -Generally, the flow is as follows: - -- a packet is offered by a hotspot to the OUI operator, with some metadata but without the actual - payload -- the OUI operator decides whether to purchase the packet; if it decides to purchase, the offer is - signed -- the packet is delivered by the hotspot to the OUI operator - -These signed offers are added to the state channel "banner", which allows the device to confirm that -it is being given credit for its work during the lifetime of the state channel. This is possible -even as many other hotspots have their own transactions added to the same banner. - -Sometime before the expiration block, the OUI operator will submit a -[`state_channel_close`](https://github.com/helium/proto/blob/master/src/blockchain_txn_state_channel_close_v1.proto) -transaction channel, a transaction which also shows how many data credits are being burned in the -name of which hotspots. Should a hotspot not be credited the appropriate amount, it has recourse -during a "grace period" the ten blocks after the closure to file a dispute, using the signed offers -as evidence. This is done in the form of alternate state channel close transactions. - -If there is no overspend or disputes, the second half of the stake and any remaining credit is -returned to the OUI operator. Otherwise, the entire stake is kept and, in the event of a dispute, -the appropriate amount of data credit burns are attributed to the hotspots with valid disputes. - -Should the operator neglect to close the state channel before the expiration block, closes by all -parties are still accepted during the ten block grace period. Should the OUI operator still neglect -to close the channel, they will lose their whole stake. diff --git a/docs/blockchain/proof-of-coverage.mdx b/docs/blockchain/proof-of-coverage.mdx deleted file mode 100644 index bb4622aaf..000000000 --- a/docs/blockchain/proof-of-coverage.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -id: proof-of-coverage -title: Proof of Coverage -pagination_label: Proof of Coverage -sidebar_label: Proof of Coverage -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /blockchain/proof-of-coverage ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Proof of Coverage - -The Helium blockchain uses a novel work algorithm called "Proof of Coverage" ("PoC") to verify that -Hotspots accurately represent their location, configuration, and the wireless Network coverage they -create. - -## Why Proof of Coverage - -The Helium Network is a physical wireless Network that succeeds based on the reliable coverage it -can create for users deploying connected devices. As such, it required a working algorithm built for -this use case. Proof of Coverage takes advantage of radio frequency's (RF) unique, undeniable -properties to produce meaningful proofs to the Helium Network and its participants. Specifically, -PoC relies on the following characteristics: - -- RF has limited physical propagation and, therefore, distance. -- The strength of a received RF signal is inversely proportional to the square of the distance from - the transmitter. -- RF travels at the speed of Light with (effectively) no latency. - -The Helium blockchain uses the data generated by ongoing proofs to verify the wireless coverage -provided by Hotspots on the Network. - -## Oracled Proof of Coverage - -- Oracled Proof of Coverage ChainVar was set in - [block 1,731,335](https://explorer-old.helium.com/blocks/1731335). -- The first Oracled Proof of Coverage Receipts were in - [block 1,731,339](https://explorer-old.helium.com/blocks/1731339). -- [Bitter Concrete Parakeet](https://explorer-old.helium.com/validators/12xtDibQdaAsvbPTqFbecGaA4iHd7NzRg6s7foQ2HCxouHo11TE) - is the animal name of the Injector Oracle for Oracled PoC. - -Oracled PoC moves the responsibility of validating all PoC events to dedicated Oracles, powerful -machines that ingest completed challenges, verify challenges, and witness validity, then inject the -results back into the Helium L1 blockchain for rewards to be issued. - -Oracles interact with data and systems outside of a native blockchain environment where the -processing can be completed much more efficiently and at scale, providing a solution to a -fundamental limitation of smart contracts. - -Oracled Proof of Coverage allows Hotspots running miner version `2022.12.13.0` or later to -"self-beacon", transmitting Beacons on their own to participate in Proof of Coverage, ensuring more -reliable Beacon events. - -At the start, Hotspots are intended to self-beacon every 6 hours, though this time window may change -as Oracled PoC is improved. In addition, the Beacon rate includes a "jitter" component to offset the -Beacon timing across Hotspots on the Network to avoid overloading the Oracles with large data -spikes. - -Oracled PoC is essential in implementing HIP-70 and the Helium Network's migration to the Solana -blockchain and is a significant step forward in increasing the usability and scalability of the -Network. - -## Proof of Coverage Roles - -The "challenge" is the discrete unit of work for Proof of Coverage. To date, 10s of millions of -challenges have been issued and processed by the Helium blockchain. - -PoC Challenges involve three distinct roles: - -### Beaconer - -Hotspots "Self Beacon" transmitting (or "beaconing") challenge packets to be witnessed by -geographically proximate Hotspots. - -### Witness - -Hotspots that are geographically proximate to the Beaconer and report the existence of the -transmitted challenge packet. Any Hotspot hearing the transmitted packet will serve as a Witness and -submit their Witness report to the Oracle. - -### Oracle - -Oracles are powerful machines that ingest completed challenges, verify the challenge and witness -validity, and then inject the results back into the Helium L1 blockchain for rewards to be issued. -In addition, Oracles interact with data and systems outside of a native blockchain environment, -providing a solution to a fundamental limitation of smart contracts. - -## PoC Reward Scaling - -In every epoch, rewards split amongst Hotspots that had a role in that reward pool. - -For example, a Hotspot might earn a "reward unit" for witnessing a beacon. If five additional -Hotspots successfully witnessed a Beacon during the epoch, each earning a "reward unit." In that -case, each Hotspot gets 1/6th of the 20% of rewards in that epoch. - -With the activation of [HIP-15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md) -and -[HIP-17](https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md), -we introduced the idea of scaling these "reward units", so the units earned when being witnessed or -witnessing a packet scale depending on two things: - -1. The number of Witnesses, as detailed in HIP-15 -2. The number of Hotspots in the hex tile of the transmitter, detailed in HIP-17 - -The HIPs themselves provide a rich explanation of these mechanisms, so you're encouraged to read -those, but they can be summarized as follows: - -**From HIP-15** - -> For the Transmitters, the more witnesses, the more the transmitter earns. - -> For the Witness, each additional Witness past a total of four reduces what is earned by each -> Witness in that challenge. - -**From HIP-17** - -> The Witness earns less if the number of Hotspots in the area of the transmitter exceeds the -> "target density." Target density varies by hex resolution, as detailed in the HIP and defined in -> several chain variables. diff --git a/docs/blockchain/transaction-fees.mdx b/docs/blockchain/transaction-fees.mdx deleted file mode 100644 index 0b156aa9f..000000000 --- a/docs/blockchain/transaction-fees.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -id: transaction-fees -title: Transaction Fees -pagination_label: Transaction Fees -sidebar_label: Transaction Fees -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /blockchain/transaction-fees ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -Like most blockchains, Helium has a system of transaction fees. All transactions in the Helium -blockchain are paid in Data Credits (DCs). Data Credits are produced via burning some amount of -`HNT` using an on-chain transaction. And thanks to a system called "Implicit Burn", users -(typically) don't need to manually supply `DCs` to pay fees. As long as the Helium wallet being used -to submit the transaction contains enough `HNT` to burn to `DCs` to fund the transaction, the burn -will happen implicitly, requiring no user intervention. - ---- - -## Transaction Fee Schedule - -The following is a list of the current set of fees required for various transactions, along with -their details. Transaction fees are paid in Data Credits. (Note that the cost is not shown in `HNT` -as this number is variable based on the current $USD/HNT price as defined by the HNT Price Oracle.) - -| Fee Type | Fee Description | **Cost (DC)** | Cost ($USD) | -| :------------------------------ | :-------------------------------------------------------------------------------------------------------------- | ------------: | ----------: | -| Send HNT | Transferring HNT from wallet to wallet | `Variable` | `Variable` | -| Transferring Device Packet Data | Fee paid by device owner when sending or receiving sensor data. Metered per 24 bytes. | `1` | `$0.00001` | -| Add Hotspot | Fee paid to add Hotspot to the blockchain. **Fee is generally covered by Hotspot maker**. | `4000000` | `$40.00` | -| Add Data Only Hotspot | Fee paid to add a Data Only Hotspot to the blockchain. | `1000000` | `$10.00` | -| Assert Hotspot Location | Required when asserting a Hotspot's location. \(The **first assertions** is generally covered by Hotspot maker\)| `1000000` | `$10.00` | -| Assert Data Only Location | Required for Optionally asserting a Data Only Hotspot's Location | `500000` | `$5.00` | -| Purchasing a blockchain OUI | Buy an OUI from the Helium blockchain | `10000000` | `$100.00` | -| Purchasing a blockchain Subnet | Buy a Subnet from the Helium blockchain | `10000000` | `$100.00` | - ---- - -## Calculating the DC cost for Sending HNT - -As noted above, the `DC` cost of a `Send` transaction is variable. The precise cost is based on the -size of the transaction, in bytes. Once the size is calculated, we apply a `5000x` multiplier. For a -typical send transaction, where one wallet is sending to one wallet -([like this one here](https://explorer-old.helium.com/txns/RP8xdjuYsvIAaEuyNvMmlBF7Kc8ShNoURtA1ccgMGpk)), -the complete transaction is made up of the following: - -| Transaction Component | Component Size (Bytes) | Note | -| :-------------------- | ---------------------: | ------------------------------ | -| Payer Wallet Key | 33 | -| Payee Wallet Key | 33 | -| Payer Signature | 64 | -| Nonce | 3 | (approximate; ranges from 2-4) | -| Payment Amount | 6 | (approximate; ranges from 4-8) | - -- In total, this is `139` bytes. -- Each `24` bytes requires one Data Credit (as is the case when you're transferring device packet - data). -- `139` / `24` results in `6` Data Credits. -- We then apply our 5000x multiplier, and the result is a transaction fee -- This results in a `30000 Data Credit` cost for the above transaction. - ---- - -## Transaction Fees and Implicit Burn - -:::caution Implicit Burn on Solana is Not Active - -Implicit burn is not currently implemented on the Solana blockchain. To acquire the DC needed for -transactions, use the Helium Wallet app to swap HNT for DC manually. - -::: - -
-More info - -The Helium blockchain uses something called `implicit burn` when paying fees. - -**Implicit Burn™** - -The term `implicit burn` was coined by Helium PM Coco "cokes" Tang, a recognized innovator in the -blockchain technology and terminology space. - -Thanks to Implicit Burn™, if you have enough HNT in your wallet to pay the transaction fee, the -Helium Mobile Wallet (or the Helium Wallet CLI) will calculate the DC cost of your transaction and -the blockchain will automatically burn the precise amount of HNT to supply the required DCs for the -transaction. For example: - -- You need to send `10 HNT` from a Helium Wallet that contains `11 HNT` -- The cost for this `send` transaction is `35000 DCs` -- Let's assume the `HNT/$USD` Oracle Price is `$.35` at the time you send the `HNT`. This means that - you'll need to supply a `1HNT` to fund the `35000 DCs` for this transaction. -- When you send the `10 HNT`, the Helium Wallet automatically supplies the `1 HNT` to be burned into - `DCs`. -- After the transaction is submitted and processed, your resulting Helium Wallet balance will be - `0 HNT`. - -In the above example, had you attempted to send `10.0001HNT` with only `11 HNT` in your wallet, this -transaction would have failed as burning `.999 HNT` would only result in `34965 DCs`, a mere 35 DCs -short of the `35000` required for a `send` transaction. - -
- ---- - -## Failed Transactions Result in No DCs Being Spent - -Transactions in the Helium blockchain are `atomic`. In short, this means that they either succeed -entirely or they don't. So, if you attempt to send HNT from a Helium Wallet without enough HNT to -supply the required Data Credits, the transaction will fail after being submitted to the blockchain -API by your wallet. And your `HNT` balance will be the same. No `DCs` were burned (or harmed) in -this failed transaction. diff --git a/docs/faq/build-on-network.mdx b/docs/faq/build-on-network.mdx deleted file mode 100644 index 1c38eaed4..000000000 --- a/docs/faq/build-on-network.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: build-on-network -title: Build on the IOT Network FAQ -pagination_label: Build on the IOT Network FAQ -sidebar_label: Build on the IOT Network FAQ -description: Build on the Helium IOT Network -image: https://docs.helium.com/img/link-image.png -slug: /faq/build-on-network ---- - -# FAQ - Build On Network - -## I want to use the Helium Network for my IoT project. How do I learn more? - -Thanks for your interest! Join the [community Discord server](https://discord.gg/helium) as there -are several channels dedicated to development. There’s also -[extensive documentation on using the Network](/use-the-network). - - - -## Can end devices communicate directly with each other or do they have to hop over the Helium Hotspot? - -All compatible devices communicate via Hotspots. There is no direct communication or meshing in the -Helium Network. - - - -## Will Helium be proprietary? - -We believe proprietary protocols and technologies stifle innovation. This is why we use commodity, -open-standard hardware, and modules available from dozens of vendors. And all software used is -[open source under friendly licenses](/faq/open-source). - -## What kind of data rates do you anticipate going from device to the Hotspot? - -Applications that are suitable for the Helium Network send small amounts of data. The maximum amount -possible is around 5kbits per second. But this is rarely seen in production. Typically sensors are -sending 10-1000 bytes at a time. - - diff --git a/docs/faq/data-credits.mdx b/docs/faq/data-credits.mdx deleted file mode 100644 index e9194367c..000000000 --- a/docs/faq/data-credits.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: data-credits -title: Data Credits FAQ -pagination_label: Data Credits FAQ -sidebar_label: Data Credits FAQ -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /faq/data-credits ---- - -# FAQ - Data Credits - -### What are Data Credits? Do I need them? - -If you’re a Hotspot owner, you do not need to worry about holding individual -[Data Credits](/hnt-token#data-credits-and-burn-and-mint-economics). - -Data Credits for Hotspot owners are created on-demand through the implicit burn mechanism and -[used to pay all Hotspot transaction fees](/blockchain/transaction-fees/#transaction-fees) such as -adding Hotspots, sending HNT, and asserting location. These Data Credits are burned automatically -from the available HNT in your wallet or by the CLI. - -Device users and developers who wish to transmit data via the Helium Network, your transactions will -require the use of discrete Data Credits held in a Helium Console account. - -One Data Credit pays for 24 bytes of LoRaWAN payload. Payloads exceeding 24 bytes are rounded up to -the next 24 bytes, so a packet with a 25-byte payload would cost two Data Credits, the same as one -with 48 bytes. - -Although Data Credits are produced by burning HNT, the price of a Data Credit is fixed in USD. Data -Credits are non-transferable and are only usable by their original owner. Data Credits cannot be -re-sold or traded. - -:::info - -Data Credits are similar to pre-paid cellphone minutes or airline miles. - -::: diff --git a/docs/faq/docs-installation.mdx b/docs/faq/docs-installation.mdx deleted file mode 100644 index 89df27e00..000000000 --- a/docs/faq/docs-installation.mdx +++ /dev/null @@ -1,142 +0,0 @@ ---- -id: docs-installation -title: Docs Installation Guide -pagination_label: Docs Installation Guide -sidebar_label: Contributing Documentation -description: Docs Installation Guide -image: https://docs.helium.com/img/link-image.png -slug: /faq/docs-installation ---- - -# Helium Documentation Installation Guide - -Clone the docs repo from [Github](https://github.com/helium/docs). - -```bash title="clone the repo" -$ git clone https://github.com/helium/docs.git -``` - -Navigate to the `docs` directory - -```bash title="navigate to the docs directory" -$ cd docs/ -``` - ---- - -## Prerequisites - -### Install Node.js - -Download and install the latest version of [Node.js](https://nodejs.org/en/download). - -```bash title="Verify the installation." -$ node --version -v18.16.0 -``` - -:::info - -Windows users installing Node.js do not need to install the `Compiler` nor `Chocolaty` dependencies. - -::: - -### Install Yarn - -After installing Node.js, npm will be installed and can be used to install Yarn. - -```bash title="install yarn" -$ npm install -g yarn -> yarn@1.22.11 preinstall /path/to/npm/node_modules/yarn -> :; (node ./preinstall.js > /dev/null 2>&1 || true) -``` - -To upgrade the Yarn version to be >= 1.5, set the project directory to version `berry`. - -```bash title="set yarn version to berry" -$ yarn set version berry -➤ YN0000: Retrieving https://repo.yarnpkg.com/3.5.1/packages/yarnpkg-cli/bin/yarn.js -➤ YN0000: Saving the new release in .yarn/releases/yarn-3.5.1.cjs -➤ YN0000: Done in 0s 430ms -``` - -### Install Dependencies - -Install Yarn which will download and compile all the project module dependencies. - -```bash title="install yarn and dependencies" -$ yarn install -➤ YN0070: Migrating from Yarn 1; automatically enabling the compatibility node-modules linker 👍 - -➤ YN0000: ┌ Resolution step -... -➤ YN0000: └ Completed in 4s 287ms -➤ YN0000: ┌ Fetch step -... -➤ YN0000: └ Completed in 9s 723ms -➤ YN0000: ┌ Link step -... -➤ YN0000: └ Completed in 8s 494ms -➤ YN0000: Done with warnings in 22s 635ms -``` - -Check the final version and confirm that it is >= 1.5 - -```bash title="verify yarn version" -$ yarn --version -3.5.1 -``` - ---- - -## Local Development - -```bash title="start the development server" -$ yarn start -[INFO] Starting the development server... -[SUCCESS] Docusaurus website is running at: http://localhost:3000/ - -✔ Client - Compiled successfully in 25.06s - -client (webpack 5.76.3) compiled successfully - -✔ Client - Compiled successfully in 542.45ms - -client (webpack 5.76.3) compiled successfully -``` - -This command starts a local development server and open up a browser window. Most changes are -reflected live without having to restart the server. - -### Auto Refresh - -Each time a file is saved the site will get rebuilt and the pages refreshed on the fly, there is no -need to keep restarting Yarn. - ---- - -## Link Checking Before Creating a Pull Request - -Checking links can be accomplished by using the `yarn build` command - -```bash title="make production build" -$ yarn build -[INFO] [en] Creating an optimized production build... - -✔ Client - -✔ Server - Compiled successfully in 30.22s - -bigint: Failed to load bindings, pure JS will be used (try npm run rebuild?) - -✔ Client - -● Server █████████████████████████ cache (99%) shutdown IdleFileCachePlugin - stored - -[SUCCESS] Generated static files in "build". -[INFO] Use `npm run serve` command to test your build locally. -``` diff --git a/docs/faq/edit-a-hip.mdx b/docs/faq/edit-a-hip.mdx deleted file mode 100644 index ac11d9e60..000000000 --- a/docs/faq/edit-a-hip.mdx +++ /dev/null @@ -1,268 +0,0 @@ ---- -id: edit-a-hip -title: Propose Changes To An Existing HIP -pagination_label: Edit an Existing HIP -sidebar_label: Edit an Existing HIP -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /edit-a-hip ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -While HIPs are in discussion, the actual text is included in the -[Helium HIP Repository on GitHub](https://github.com/helium/hip). - -Before a HIP goes to a vote, changes and revisions will likely need to be made to an existing -proposal. - -:::tip Key Take Aways - -This page will walk users through the process of: - -- Creating a personal copy, or "fork", of the Helium HIP repository. -- Making edits using the in-browser text editor. -- Submitting these changes for review. - -::: - ---- - -### Markdown Formatting - -All HIPs in the Helium GitHub repository are written in Markdown an easy-to-read, easy-to-write -syntax for formatting rich text. Read more about basic writing and formatting syntax -[here.](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) - -Do not let knowledge of Markdown stop you from writing a proposal. Get words on a page, and the -repository maintainers and other community members will help! - ---- - -## Fork the Repo - -**Step 1.** Log in to an existing account or create a new account on [GitHub](https://github.com). - -**Step 2.** Open the Helium HIP Repository at -[https://github.com/helium/hip](https://github.com/helium/hip) - -**Step 3.** Click the `Fork` button in the upper right-hand corner. - -
- -
- -
- -**Step 4.** Leave all settings default and confirm using the green `Create Fork` button at the -bottom left-hand corner. - -
- -
- A copy of the Helium HIP repository will be made in the user's GitHub account and should open - automatically. -
-
- ---- - -## Edit an Existing HIP - -All HIPs in the Helium GitHub repository are written in Markdown an easy-to-read, easy-to-write -syntax for formatting rich text. Read more about basic writing and formatting syntax -[here.](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) - -**Step 1.** Begin inside the forked copy at `https://github.com//HIP` - -
- -
Your username will be visible here.
-
- -
- -**Step 2.** Open the HIP to be edited by clicking on the file. This example uses 'HIP 83'. - -
- -
Click on the HIP to edit.
-
- -
- -**Step 3.** Click the `Pencil Icon` in the upper right-hand corner to make edits. - -
- -
- -
- -**Step 4.** Make edits or changes to the HIP. - -
- -
- -
- -**Step 5.** Click the green `Commit changes...` button in the upper right-hand corner. - -
- -
- -
- -**Step 6.** In the pop-up window, select the -`Create a new branch for this commit and start a pull request` option. - -
- -
- -
- -**Step 7.** Click the Green `Propose changes` button. - -
- -
- -
- -**Step 8.** Do not click the green `Create pull request` button on this page. Click the grey `Code` -tab. - -
- -
- ---- - -## Make a Pull Request - -A Pull Request, or "PR", is quite literally an ask to the repository maintainers to "pull in" -proposed changes. - -**Step 1.** A new banner will be presented with a green `Compare & pull request` button. Click the -button to start a Pull Request - -
- -
- The number may be more than 1, depending on how many edits ahead the forked repository is from - the main HIP repository. -
-
- -
- -**Step 2.** Confirm the Pull Request is to the `helium/HIP` base `main` and the correct changes are -being proposed. - -
- -
- -
- -**Step 3.** Edit the `Title` and `Description` to inform other readers and maintainers what changes -were made. - -
- -
Good pull requests are detailed in their explanation of changes.
-
- -
- -**Step 4.** Click the green `Create pull request` button. - -
- -
- -
- -**Step 5.** View the newly created Pull Request in the main Helium HIP repository. - -
- -
- -
- -All PRs are reviewed by the HIP authors, and once approved are "merged" into the main branch by -repository maintainers where the edits are visible to the Helium community. - ---- - -## Stay Involved - -Once a PR is submitted, authors are asked to keep a watch on them for comments or change requests. -By default, the user to submit a PR will be subscribed via email to receive notifications on PR -activity. - -Timely responses in GitHub and Discord keep the process moving! diff --git a/docs/faq/helium-network.mdx b/docs/faq/helium-network.mdx deleted file mode 100644 index 9f7348d6a..000000000 --- a/docs/faq/helium-network.mdx +++ /dev/null @@ -1,106 +0,0 @@ ---- -id: helium-network -title: Helium Network FAQ -pagination_label: Helium Network FAQ -sidebar_label: Helium Network FAQ -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /faq/helium-network ---- - -# FAQ - Helium Network - -### What is the Helium Network? - -Helium is a global, distributed network of Hotspots that create public, long-range wireless coverage -for Internet of Things (IoT) devices. Hotspots mine and are rewarded in IOT, a cryptocurrency now on -the Solana blockchain. - -Today, the Helium ecosystem, and its hundreds of thousands of Hotspots deployed by a global -community, provide access to the largest decentralized wireless network in the world. -[Here’s a helpful introduction video](https://youtu.be/Vx9YyS7-d3g). - -### Why is the Helium Network called The People’s Network? - -We call it The People’s Network because the people who deploy Hotspots build and operate the -network. It’s powered by them and owned by them. - -### Who governs the Helium Network and what is the Helium Foundation? - -The Helium Foundation is a global not-for-profit dedicated to the proliferation of secure, -cost-effective connectivity and it manages and maintains the open technologies that support the -Helium Network. You can read more about governance from Helium Foundation -[here](https://helium.foundation). - -### How does the Hotspot work and what does it power? - -Hotspots enable people to own and operate a wireless network that supports a wide range of Internet -of Things (IoT) devices, from smart pet collars and home delivery systems, to smart bikes and -scooters, medical transport and tracking devices, cooling systems, smart lighting systems, and more. -[Here’s a helpful video about how Helium works](https://www.youtube.com/watch?v=67aQeZTaqNY). - -### Does Helium replace the Wi-Fi in my house? - -No. Hotspots receive radio signals and route packets from low-power devices in your area that use -LoRaWAN, a wireless protocol, and have been deployed to the Helium Network. Typically these are -devices such as GPS trackers, environmental sensors, weather meters, etc., that only need to -transmit and share small bits of information. The Hotspot uses your existing Internet (via WiFi or -Ethernet) to deliver the data packets sent by devices. It does not replace internet or cellular -service for regular devices like computers and smartphones - -### If I connect the Hotspot to my Wifi, am I breaking the terms of service with my Internet provider? - -The Helium Network is not in the position or business of giving legal advice. In general, users -should check the terms with individual providers and comply with applicable law. - -### How far does the Helium Network reach and does it use radio frequency? - -Helium’s LoRaWAN technology, the combination of the Helium blockchain and LoRaWAN wireless protocol, -uses sub-GHz radio frequency between 860 and 923 MHz. Depending on conditions, Helium LoRaWAN can -reach dozens of miles or kilometers and even connect devices that are inside buildings unlike GPS -and cellular signals. - -### What kind of cryptocurrency do I earn? - -Hotspot owners earn IOT tokens. - -### How do Hotspots earn IOT? - -Hotspots earn IOT by providing wireless coverage and transferring data from nearby devices. The more -data transferred the larger the reward. Previously Hotspots earned HNT tokens and -[Here’s a helpful video about how HNT worked](https://www.youtube.com/watch?v=B0JOB88MHSI). - -### How much IOT will I earn? - -Hotspot owners earn IOT depending on how frequently their devices do two things: - -- Validate the Network - Hotspots transmit data to each other to confirm that the Network is secure - and owners receive rewards when their Hotspot participates in a process called Proof of Coverage. - You can learn more about Proof of Coverage [here](/blockchain/proof-of-coverage). -- Move Data for Device Users - If an e-scooter, pet tracker, air quality sensor or other device uses - a Hotspot to transmit data, the owner of the Hotspot receives rewards based on how much data is - transferred. - -[Here’s a helpful video about how to mine HNT](https://www.youtube.com/watch?v=kmsk8lTrrts). - -### What if I'm in a rural area, or the only Hotspot in my area? Can I still earn rewards? - -It's best to have at least one or two other Hotspots within radio range of you so that you can -participate in Proof of Coverage Challenges to earn IOT rewards at a higher rate. If you are the -only Hotspot in your area, you will earn IOT if a device uses your Hotspots connection to transfer -sensor data back to the sensor users. IOT is distributed based on these economics. Read more about -token economics [here](https://www.helium.com/token). - -### Can I connect my phone or computer to Hotspots? - -Yes. As of early 2022 the community has started to roll out 5G-CBRS Hotspots in the USA -[4G/LTE and 5G coverage on the Helium blockchain](https://www.helium.com/5G). - -### Does the Helium community have a Discord? - -The Helium Discord is the primary communication channel for the Helium Network Community and it is -the primary venue to get support for using the Network. The Helium Discord is moderated by -independent members of the Helium community. - -Here’s a [helpful blog about the Helium Community](/governance) and how you can join -[the Helium Discord](https://discord.gg/helium). diff --git a/docs/faq/hotspot-manufacturers.mdx b/docs/faq/hotspot-manufacturers.mdx deleted file mode 100644 index f5ae88f5d..000000000 --- a/docs/faq/hotspot-manufacturers.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: hotspot-manufacturers -title: Approved Hotspot Manufacturers FAQ -pagination_label: Hotspot Manufacturers FAQ -sidebar_label: Approved Hotspot Manufacturers FAQ -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /faq/hotspot-manufacturers ---- - -# FAQ - Approved Hotspot Manufacturers - -Nova Labs (formerly Helium Systems, Inc.) manufactured the first set of Hotspots on the Network. -Nova Labs no longer manufacturers Hotspots, but there is now an extensive list of approved -manufactures (known in the community as "Makers") - -- [All approved Hotspots can be found here](https://helium.com/mine) -- [All approved Makers can be found here](/hotspot-makers/iot/full-hotspots). - -* Please be very careful if purchasing a Helium Hotspot from a non-authorized seller. Hotspots can - be transferred from one Helium wallet to another. Once they are added to the blockchain, only the - owning wallet can transfer it to another. Any transfers are solely between the two entities - ("Buyer" and "Seller"), and Helium is not involved. -* Also note that the Helium Hotspot limited warranty is only valid for the original sale to the - original owner. Resold Helium Hotspots from anyone other than Helium directly are not under any - warranty whatsoever. Please refer to their documentation for any authorized reseller policy. diff --git a/docs/faq/open-source.mdx b/docs/faq/open-source.mdx deleted file mode 100644 index 540ad9629..000000000 --- a/docs/faq/open-source.mdx +++ /dev/null @@ -1,92 +0,0 @@ ---- -id: open-source -title: Open Source -pagination_label: Open Source -sidebar_label: Open Source -description: Open Source -image: https://docs.helium.com/img/link-image.png -slug: /faq/open-source ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -# Helium is Open Source - -The Helium Network is built almost entirely on open-source code. And we actively encourage the -community to develop and contribute to all parts of the Network. Below is a subset of the code that -plays an integral role in the Helium Network. The full list can be found on the official -[Helium GitHub Organization](https://github.com/helium). - -## Helium Blockchain - -These are the core libraries and repos that make up the Helium blockchain. Most things here are -written in Erlang. - -- [Miner](https://github.com/helium/miner) - The Helium blockchain miner. - -- [Blockchain Core](https://github.com/helium/blockchain-core) - The glue that ties together things - like the `Helium miner` and the `blockchain api`. - -- [Blockchain API](https://github.com/helium/blockchain-api) - A full blockchain node that exposes a - JSON API. It's ideal for supplying data to things like block explorers and mobile apps. - -- [Erlang HoneyBadgerBFT](https://github.com/helium/erlang-hbbft) - An Erlang implementation of - HoneyBadgerBFT's various protocols. - -- [Erlang DKG](https://github.com/helium/erlang-dkg) - Helium's implementation of the protocol - described in [Distributed Key Generation in the Wild](https://eprint.iacr.org/2012/377.pdf). - Prepare yourself for some math. - -- [Erlang libp2p](https://github.com/helium/erlang-libp2p) - Libp2p swarms written in (you guessed - it) Erlang. - -- [Helium CLI Wallet](https://github.com/helium/helium-wallet-rs) - Command Line Interface, written - in Rust, used to create and administer Helium wallets, and interact with the Helium Network. - -- [Helium JS](https://github.com/helium/helium-js) - Typescript SDKs for interacting with the Helium - blockchain. - -- [Packet Purchaser](https://github.com/helium/packet-purchaser) - Service that buys Helium LoRaWAN - packets from the Network and delivers them to a target LoRaWAN Network server. - -- [Angry Purple Tiger](https://github.com/helium/angry-purple-tiger) - Ever wonder how your Miner - got its cute little animal name? Here it is. - -## LoRaWAN - -The Helium Network is the largest, public LoRaWAN network in the world. This is some of the code -that makes it possible. - -- [Packet Forwarder](https://github.com/helium/packet_forwarder) - Helium's fork of the Lora packet - forwarder. -- [Light Gateway](https://github.com/helium/gateway-rs) - The next-generation packet forwarder for - the Helium-enabled gateways. - -- [Helium Console](https://github.com/helium/console) - A web browser front-end for users to manage - organizations and devices and a Helium Blockchain-compatible LoRaWAN Network Server (LNS). - -- [Console Decoders](https://github.com/helium/console-decoders) - A collection of LoRaWAN sensor - decoders used in Helium Console. - -### Mobile Apps, Web Apps, and Sites - -- [Helium Wallet App](https://github.com/helium/wallet-app) - Helium wallet app for iOS and Android. - -- [Helium Hotspot App](https://github.com/helium/hotspot-app) - Helium hotspot app for iOS and - Android. - -- [Helium Blockchain Explorer](https://github.com/helium/explorer) - Code that powers the greatest - block explorer in the crypto world. - -- [Helium Docs](https://github.com/helium/docs) - Docusaurus-based docs for all things Helium. - (You're reading them.) - -- # [Helium IOT Mappers](https://github.com/helium/mappers/) - Community generated coverage map of the - - - [Installation](/faq/docs-installation) - How to install the needed components to start helping - docs development. - -- [Helium Mappers](https://github.com/helium/mappers/) - Community generated coverage map of the - Helium network using real-world testing. diff --git a/docs/faq/privacy.mdx b/docs/faq/privacy.mdx deleted file mode 100644 index ef561a75f..000000000 --- a/docs/faq/privacy.mdx +++ /dev/null @@ -1,200 +0,0 @@ ---- -id: privacy -title: Privacy Policy -pagination_label: Privacy Policy -sidebar_label: Privacy Policy -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /faq/privacy ---- - -# Privacy Policy - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This Privacy Policy governs the manner in which Helium Inc. ("Helium") collect, use, maintain and -disclose information collected from users (each, a "User" or "you") on the www.helium.com website -and all products and services offered by Helium ("Site"). - -By using the Site or otherwise providing information to Helium, you agree to our Privacy Policy. If -you do not agree with this policy or its terms, please do not visit or use our Site. The Helium -Terms and Conditions are incorporated within the terms of this Privacy Policy. Please make sure you -read and agree to them before using our Site. - -Our Privacy Policy does not apply to products or services offered by other companies, individuals or -business partners, or to information that you provide or that is collected by third parties using -our technologies. These third parties may have their own privacy policies, which we encourage you to -read before providing information to them. - -## This policy describes - -What personally identifiable information we collect from you, how it is used and with whom it may be -shared. The security procedures in place to protect the misuse of your information. What choices we -offer, including how to request access to, update or delete your personal information. - -## Personal Identification Information - -We may collect personal identification information from Users in a variety of ways, including, but -not limited to, when Users visit our Site, register on the Site, or place an order. - -## Information You Give Us - -We will collect the personal information that you provide us. For example, we will ask you to -provide personal information such as your name, address, email address, telephone number, and credit -or debit card information as part of normal business transactions. Users may provide Helium -information in the following scenarios: - -- _Registration_ - In order to use certain parts of the Site, you must first register. The - registration form requires Users to give certain information (such as name and email address). At - your option, you also may provide demographic information (such as your gender or age) about - yourself, but it is not required. -- _Orders_ - To purchase products or items from us, you must provide contact information (like name - and shipping address) and financial information (like credit card number and expiration date). -- _Surveys & other communications_ - From time-to-time our Site may request information. - Participation in these is completely voluntary, and you may choose whether or not to participate - and therefore disclose this information. Information requested may include contact information - (such as name and shipping address) and demographic information (such as zip code, age level). - Contact information may be used to market to you about third party products and services. Your - information also may be provided to third parties. Information may also be used for purposes of - monitoring or improving the use and satisfaction of the Site, as well as for public posting and - product reviews by other users. - -## Information we get from your use of our website or services - -When you browse or use our Site, we and our third party service providers collect information about -the services you use, other websites you've visited and personal preferences. We also may collect -your personal location while using our Site. This information includes: device-specific information -(such as your operating system, mobile phone network, mobile device ID, and other device-specific -unique device identifiers such as your computer's internet protocol (IP) address), user information, -specific geographical location and browsing and interaction habits. Our Site may use "cookies" or -similar technologies to enhance User experience. A cookie is a small file placed on your device or -computer. It may be possible to refuse to accept cookies by activating the appropriate setting on -your browser or mobile device. However, if you select this setting, you may be unable to access -certain parts of our Site. We use these technologies to collect and store information about you when -you interact with services or products that we offer. - -## How we use and share collected information - -Helium collects information to provide our services to you in the performance of a contract with -you, or for our legitimate interests in better understanding our customer’s interactions and to -create better products and services. We also share personal information we collect from the site to -third parties that assist us in supporting us in providing our services, in understanding how you -use our Site, and to provide advertising to us and on our behalf. These third parties are obligated -to protect the information they process on our behalf in accordance with our policies and applicable -law, and include: FullStory, Intercom, as well as the Google Analytics Advertising Feature. -Specifically, Helium collects and uses Users' personal information for the following purposes: - -- _To improve customer service_ - Your information helps us to more effectively respond to your - customer service requests and support needs. We and our service providers, such as Intercom, - assist us in processing your request including through our chat box feature, which we offer for - your use and convenience. -- _To improve our Site_ - We continually strive to improve our Site offerings based on the - information and feedback we receive from you. For example, we and our service providers, including - FullStory, to provide faster and better support to your customers and aid our engineering team in - solving bugs and improving the user experience. -- _To process transactions_ - We will use the information you provide to process your order. We do - not share this information with outside parties except to the extent necessary to provide the - service. -- _To send periodic emails_ - Your email address will be used to send you information and updates - pertaining to your order. It also may be used to respond to your inquiries. If you decide to - opt-in to our mailing list, you will receive emails that may include company news, updates, - related product or service information, etc. If at any time you would like to unsubscribe from - receiving future emails, we include detailed unsubscribe instructions at the bottom of each email - or you may contact us via our Site. -- _Protect our rights or comply with legal process_ - We may disclose your personal information to - enforce our rights arising from any contracts entered into between you and Helium; to comply with - any court order, legal process, or respond to any governmental or regulatory request; or to - protect Helium's rights or property or the safety of Helium, our customers, employees, or others. -- _Sale or merger_ - We also may disclose your personal information to a buyer or other successor in - the event of a merger, acquisition, divestiture, restructuring, reorganization, dissolution, or - other sale or transfer of Helium’s assets. -- _To market other products of Services to You_ - We may use your personal information in - association with third party vendors, marketing firms or other companies to market or sell other - non Helium products or services. For example, through Google Ads and Google Analytics, we create - remarketing audiences based on specific user behavior, demographic information and interest data, - and share those list with Adwords. We also use demographic and interest data in analytics reports - to create automated profiles for marketing purposes. We create segments based on demographic and - interest data. We and our third party vendors, including Google, will use this information to show - you ads on sites across the Internet. We may also use cookies to serve ads based on your past - visits to our website. - -We retain the information we collect for as long as we needed for the above mentioned legitimate -business purposes. - -## Your Cookie Preferences and Do Not Track Signals - -- Some browsers may offer a "Do Not Track" feature. This Site does not currently respond to "Do Not - Track" signals. -- You can opt out of Google’s use of cookies by visiting Google’s Ad’s Settings. You may also - opt-out of certain third party vendor’s use of cookies by visiting the Network Advertising - Initiative’s opt-out page. - -## Your Rights: Accessing, Updating or Deleting your personal information - -You may log in to Helium to review and update your registration information. You may also delete -your account at any time. Most data requests on your registration page will be updated -automatically. Otherwise, we will make commercially reasonable efforts to provide you with -reasonable access to your personal or other account information we maintain within 30 days of your -access request. If we cannot honor your request within 30 days, we will let you know and provide you -with an explanation. As specified above, you also have the right to opt-out of the use of cookies -for marketing purposes by selecting your preferences through the Ad Settings or NAI opt-out pages at -the links above. Also, California law permits Users who are California residents to request certain -information regarding our disclosure of personal information to third parties for their direct -marketing purposes. To make such a request, please send an e-mail to the contact information below -with "California Shine the Light Privacy Request" in the subject line and your full name, email -address, postal address and specific services you have used in the body of your email. - -## How we protect your information - -We adopt data collection, storage and processing technical and organizational measures to secure and -protect against unauthorized access, alteration, disclosure or destruction of your personal -information, username, password, transaction information and data stored on our Site. While we use -security measures to protect sensitive and personal information transmitted online, please be aware -that no security measures are perfect or impenetrable. - -## Children's information - -Our Site is not directed to children under the age of 13, and our Terms and Conditions prohibit -children under 13 from using our Site. We do not knowingly collect any information from children -under 13. - -## Changes to this privacy policy - -Helium has the discretion to update this privacy policy at any time. When we do, we revise the -updated date at the top of this page. We encourage Users to frequently check this page for any -changes to stay informed about how we are helping to protect the personal information we collect. -You acknowledge and agree that it is your responsibility to review this Privacy Policy periodically -and become aware of modifications. - -## U.S. Website - -Helium operates in the United States of America, under U.S. law. Any information you choose to send -to this Site or Helium will be transferred to Helium in the U.S., and its service providers, subject -to the laws of the United States. Some jurisdictions, such as the European Union, do not consider -the U.S. legal system to offer protections that are "adequate" in their judgment. If you do not wish -your information to subject to U.S. law, please do not send it to Helium. Helium does not intend to -offer its product or Services in any jurisdiction where the offering of such products or Services -would be contrary to applicable local law, and any such offer of products or Services is void if -illegal under applicable law. - -## Your acceptance of these terms - -By using this Site, you signify your acceptance of this Privacy Policy and our Terms and Conditions. -If you do not agree to the Privacy Policy or our Terms and Conditions, please do not use our Site. -Your continued use of the Site following the posting of changes to this Privacy Policy will be -deemed your acceptance of those changes. - -## Contacting us - -If you have any questions or concerns about this Privacy Policy, the practices of this Site, or your -dealings with this Site, please contact our privacy and data protection office us at: Helium 51 -Federal St #100 San Francisco CA 94107 - -dpo@helium.com - -We welcome your questions, comments, and feedback, and will take steps to respond to you as soon as -reasonably possible. If you have an unresolved privacy or personal information collection, use , or -disclosure concern that we have not satisfactorily addressed, you also have the right to contact and -lodge a complaint with a data protection supervisory authority. - -Last Revised: 05/09/2018 diff --git a/docs/faq/security.mdx b/docs/faq/security.mdx deleted file mode 100644 index d992f6cdb..000000000 --- a/docs/faq/security.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -id: security -title: Security FAQ -pagination_label: Security FAQ -sidebar_label: Security FAQ -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /faq/security ---- - -# FAQ - Security - -The security of the network and Hotspot owners is of the utmost importance to us. While the Internet -connection is necessary, it is only used to provide backhaul to the Hotspot for blockchain -peer-to-peer and LoRaWAN networking. As security concerns are ever present, here is what we have -done, and are doing, to combat potential risks: - -- The most common attack vector to get into a device like the Hotspot is inbound ports. As of May - 2022, the Helium Hotspot no longer requires any inbound ports to be open or forwarded. -- Helium-enabled LoRaWAN devices are hardware-secured to protect the traffic from the utilized - spectrum. This means the security is built-in since devices using the network have AES private key - encryption at the chip level. -- All approved Helium Hotspots comply with the relevant radio and wireless regulations in the - country or region where they are deployed. For example, Hotspots in the US comply with FCC - regulations for operating in the unlicensed 902-928MHz spectrum, the CE mark for the European - 868MHz spectrum, etc. -- Expected bandwidth utilized by devices is 1-5kb/s (about the size of a long text message) and - devices communicate with the Hotspot over LoRaWAN, not IP (Internet Protocol). -- While very inexpensive to use, the Helium network is not free. Any transaction requires data - credits. This is inherently a deterrent for potential scammers. -- Helium wallets (included within the Helium App) use asymmetric keys to keep your private key - secure. - -We will be diligent in our approach to maintaining and improving all aspects of the network’s -security to help ensure that you, The People who constitute The People’s Network, can continue to -help define a new era of IoT. diff --git a/docs/faq/terms.mdx b/docs/faq/terms.mdx deleted file mode 100644 index 8b2843f22..000000000 --- a/docs/faq/terms.mdx +++ /dev/null @@ -1,195 +0,0 @@ ---- -id: terms -title: Terms Of Service -pagination_label: Terms Of Service -sidebar_label: Terms Of Service -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /faq/terms ---- - -# Terms of Service - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Helium, Inc ("Helium," "we," "us," or "our") welcomes and thanks you for using our service (the -"Service") made available through our website (the "Website"). We provide access to and use of our -Service subject to the following terms of service (the "Terms of Service"), which are effective as -of the date stated above. By using the Service, you acknowledge that you have read, understood, and -agree to be legally bound by the terms and conditions of these Terms of Service and the terms and -conditions of our Privacy Policy, which is hereby incorporated by reference. Please take the time to -review our Privacy Policy. If you do not agree to any terms in these Terms of Service or the Privacy -Policy, then please do not use our Service. We may change these Terms of Service from time to time, -and will post any changes on the Website or notify you via email, at our option, as soon as such -changes are in effect. If you are using the Service on a free trial basis, then by continuing to use -the Service after we make any such changes to the Terms of Service, you are deemed to have accepted -such changes. If you have purchased a Service subscription, then the changes will not go into effect -until your Service subscription renews. Please refer back to these Terms of Service on a regular -basis. - -## Access and Use - -Subject to the terms and conditions of this Agreement, Helium will provide access to and use of the -Service to you or the entity which you have authority to bind to this Agreement ("Subscriber"). We -will also provide access to and use of the Service to any employee of Subscriber or other individual -authorized by Subscriber (each, an "Authorized User"). Subscriber acknowledges that each Authorized -User must agree to these Terms of Service and the Privacy Policy prior to use and that Subscriber -shall be responsible for ensuring compliance by each Authorized User with these Terms of Service and -for any breach of these Terms of Service by any Authorized User. Subscriber is solely responsible -for any data or content uploaded or stored on the Service by Subscriber or any Authorized User -("Subscriber Data"). In no event shall Helium be responsible for the use or misuse of any Subscriber -Data by Subscriber or any Authorized User or other third party. Subscriber warrants and represents -that it either owns or has the right to provide all Subscriber Data. Subscriber hereby grants Helium -a non-exclusive, transferable, royalty-free license to use the Subscriber Data to provide the -Service and as otherwise described in herein or in our Privacy Policy. As stated in the Privacy -Policy, we take reasonable steps to protect the Subscriber Data from loss, misuse, and unauthorized -access, disclosure, alteration, or destruction. For the avoidance of doubt, in no event will we -share the project information that you upload into the Service with third parties for marketing -purposes. All right, title, and interest in and to the Service, the Website, and any information, -data, software, graphics, and interactive features contained therein, including all modifications, -improvements, adaptations, enhancements, or translations made thereto, and all proprietary rights in -any of the foregoing (collectively, "Helium Property"), shall be and remain the sole and exclusive -property of Helium. Subscriber will not, and will not permit any Authorized User or other third -party to: (i) allow anyone other than an Authorized User to access or use the Service; (ii) use the -Service in any way that is not expressly permitted by this Agreement, including, without limitation, -reverse engineering, modifying, copying, distributing, or sublicensing the Service, or introducing -into the Service any software, virus, or code; or (iii) use the Service in violation of any -applicable law or regulation. - -## Registration - -Prior to using the Service, Subscriber will be required to register for an account. During the -registration process, Subscriber will select logon credentials for each Authorized User. Logon -credentials can only be used by the Authorized User to whom they are assigned and cannot be shared -among Authorized Users or with third parties. Subscriber is solely responsible for the -confidentiality and use of all logon credentials for its account and those assigned to Authorized -Users, as well as for any use or misuse of the Service using Subscriber's or any Authorized User's -logon credentials. Subscriber shall notify us immediately if it becomes aware of any loss, theft or -unauthorized use of any logon credentials, and we reserve the right to delete or change them at any -time and for any reason. - -## Fees and Payment - -The payment model is a pay-per-usage model and additional service costs may be bundled into the -price of usage. Regardless of the service level, users pay based on traffic and depending on the -services level or the offering a markup may be applied to the base packet transfer costs defined by -the blockchain. - -Besides the hosting of backend infrastructure, these services could include a front-end interface -designed for users to manage the offering, a dashboard to monitor traffic, user permissions, and the -ability to directly pay for Data Credits which are required to transfer packets on the network. If a -credit card is used you must provide accurate information regarding your credit card or other -payment instrument, and you must promptly update your payment information if such information -changes. You hereby authorize Helium’s payment processor to periodically bill your payment -instrument in advance, in accordance with the payment plan you have selected. If you wish to dispute -any charges, you must provide notice to Helium of such dispute within sixty (60) days of payment of -the disputed charge. All amounts paid are non-refundable. - -We reserve the right to change our prices at any point. If we do change prices, we will provide -notice to you through the Website or via email, at our option, at least thirty (30) days before such -change is to take effect. Your continued use of the Service after the price change constitutes your -agreement to pay the changed amount. If billing via invoice is an option all amounts due must be -paid by the date specified in the invoice or access and use of the Service may be terminated. Unpaid -invoices are subject to a finance charge of 1.5% per month on any outstanding balance, or the -maximum permitted by law, whichever is lower, plus all expenses of collection. You shall be -responsible for all taxes associated with the Service other than U.S. taxes based on Helium's net -income. - -## Data Credits - -Data Credits can only be used for connectivity of devices. They can be thought of similar to mobile -minutes for a pre-paid cell phone only instead of voice data, it’s packet data from sensors. Like -mobile minutes, Data Credits are non-transferrable by design. - -Data Credits have a core fixed price defined by the blockchain: one (1) data credit costs $0.00001. -Data Credits are not currency, cannot be monetized, resold, or converted into anything. - -## Publicity - -Each Subscriber is permitted to identify itself as a Subscriber of the Services for promotional and -marketing purposes. Subscriber grants Helium a non-exclusive, non-transferrable, non-sublicensable, -and royalty-free license to use and reproduce Subscriber’s name, logos, and trademarks for -promotional and marketing purposes including on Helium's customer lists, advertising, and website. -Subscriber may opt out of the provisions in this Section by emailing a request to -support@helium.com. - -## Term and Termination - -Helium may suspend or terminate your access to and use of the Service, in whole or in part, at any -time and for any reason; provided, however, that if you have purchased a subscription for the -Service, Helium’s right to suspend or terminate your access to and use of the Service will be -limited to cases where you have failed to pay the applicable subscription fees or have otherwise -breached these Terms of Service, and have not cured such payment failure or other breach within 10 -business days of receiving written notice of such payment failure or other breach from Helium (and -provided, further that Helium may suspend your access to and use of the Service immediately without -notice in the event that Helium reasonably determines that your account may cause potential harm to -Helium or third parties). You may terminate your account at any time upon notice to us; provided, -however, that if you have purchased a subscription for the Service, your right to terminate your -account before paying the full amount of fees for the subscription period that you have committed to -will be limited to cases where Helium has breached these Terms of Service, and has not cured such -breach within 10 business days of receiving written notice of such breach from you. In the event of -suspension or termination (other than cases where Helium locks your account due to fraudulent -activities or other potential harm to Helium or third parties), Helium will provide you with access -to your Subscriber Data for at least 30 days following such termination. It is your responsibility -to keep backup copies of the Subscriber Data. Helium may terminate this agreement upon written -notice if Helium determines, in its sole and absolute discretion, that Customer has engaged in or -permitted behavior that Helium considers to be immoral, racist, or discriminatory on the basis of -race, ethnicity, national origin, caste, sexual orientation, gender, gender identity, religious -affiliation, age, disability, or serious disease. - -## DISCLAIMERS; LIMITED WARRANTY - -THE PRODUCTS, THE SERVICE, ANY OTHER DELIVERABLES AND HELIUM CONTENT ARE PROVIDED "AS IS" AND -WITHOUT ANY EXPRESS OR IMPLIED REPRESENTATIONS OR WARRANTIES REGARDING ACCURACY, OPERABILITY, USE, -TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, AND EACH PARTY HEREBY -DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES OF ANY KIND REGARDING THE PRODUCTS, SERVICES, -DELIVERABLES AND HELIUM CONTENT, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT OR THAT THEIR USE WILL PRODUCE ANY -RESULTS, FINANCIAL OR OTHERWISE. - -## LIMITATION OF LIABILITY - -HELIUM SHALL NOT BE LIABLE TO CUSTOMER OR ANY THIRD PARTY FOR SPECIAL, PUNITIVE, EXEMPLARY OR -CONSEQUENTIAL DAMAGES OR LOST PROFITS (HOWEVER ARISING, INCLUDING NEGLIGENCE) ARISING OUT OF OR IN -CONNECTION WITH THIS AGREEMENT, EVEN IF HELIUM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, -AND FOR DAMAGES ARISING OUT OR IN CONNECTION WITH THIS AGREEMENT IN THE AGGREGATE IN EXCESS OF THE -FEES PAID OR PAYABLE BY CUSTOMER PURSUANT TO THIS AGREEMENT. - -## Indemnification - -Subscriber will defend, indemnify, and hold harmless Helium and its officers, directors, managers, -and employees from any and all liabilities, costs, and expenses (including, without limitation, -reasonable attorneys' fees) in connection with any third-party claim that any of the Subscriber -Data: (i) infringes or misappropriates any third-party intellectual property rights, privacy or -publicity rights, or any other rights; or (ii) violates any applicable laws, rules, or regulations. -Helium shall promptly notify Subscriber of the claim, provided, however, that failure to provide -such notice shall not relieve Subscriber of its indemnity obligations unless it is materially -prejudiced thereby. Subscriber shall have control over the defense of the claim, provided that (i) -Subscriber does not make any admission of liability on behalf of Helium or agree to any settlement -that imposes a financial burden on Helium without Helium's prior written consent; and (ii) Helium -shall have the right to participate in the defense of any such claim, at its own cost, with counsel -of its choice. - -## General Provisions - -This Agreement is governed by the laws of the State of California, without regard to conflict of law -rules. The UN Convention on Contracts for the International Sale of Goods will not apply to this -Agreement. The parties shall bring any disputes arising out of or related to this Agreement -exclusively in a court located in San Francisco County, California and each party hereby submits to -the personal jurisdiction of such courts. Each party is an independent contractor and neither -party's personnel are employees or agents of the other party for any purpose whatsoever. Nothing -hereunder will constitute, create, give effect to or otherwise recognize a joint venture, -partnership or business entity of any kind, nor will anything hereunder constitute either party as -the agent or representative of the other. Headings are for convenience. No presumption is to operate -in either party's favor as a result of who drafted this Agreement. For purposes of this Agreement, -the words "include," "includes" and "including" are deemed to be followed by the words "without -limitation," and the word "or" is not exclusive. This Agreement supersedes all prior discussions and -writings regarding (and constitutes the entire agreement between the parties with respect to) the -subject matter of this Agreement. This Agreement is effective upon Customer's purchase of the -Product. The parties may only amend this Agreement in writing. If any provision of this Agreement is -for any reason held to be invalid, illegal, or unenforceable under applicable law in any respect, -then such invalidity, illegality, or unenforceability will not affect the other provisions of this -Agreement, this Agreement will be construed as if such invalid, illegal, or unenforceable provision -were excluded from this Agreement, and the court in its discretion may substitute for the excluded -provision an enforceable provision which in economic substance reasonably approximates the excluded -provision. diff --git a/docs/faq/write-a-hip.mdx b/docs/faq/write-a-hip.mdx deleted file mode 100644 index 847ffa3f1..000000000 --- a/docs/faq/write-a-hip.mdx +++ /dev/null @@ -1,262 +0,0 @@ ---- -id: write-a-hip -title: Propose a New HIP -pagination_label: Propose a New HIP -sidebar_label: Propose a New HIP -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /write-a-hip ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -While HIPs are in discussion the actual text is included in the -[Helium HIP Repository on GitHub](https://github.com/helium/hip). - -Before a HIP goes to a vote, changes and revisions will likely need to be made to an existing -proposal. - -:::tip Key Take Aways - -This page will walk users through the process of: - -- Creating a personal copy, or "fork", of the Helium HIP repository. -- Copying the HIP template. -- Writing a new proposal using the in-browser text editor. -- Submitting the proposal for review. - -::: - ---- - -### Markdown Formatting - -All HIPs in the Helium GitHub repository are written in Markdown an easy-to-read, easy-to-write -syntax for formatting plain text. Read more about basic writing and formatting syntax -[here.](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) - -Do not let knowledge of Markdown stop you from writing a proposal. Get words on a page, and the -repository maintainers and other community members will help! - ---- - -## Fork the Repo - -**Step 1.** Log in to an existing account or create a new account on [GitHub](https://github.com). - -**Step 2.** Open the Helium HIP Repository at -[https://github.com/helium/hip](https://github.com/helium/hip) - -**Step 3.** Click the `Fork` button in the upper right-hand corner. - -
- -
- -
- -**Step 4.** Leave all settings default and confirm using the green `Create Fork` button at the -bottom left-hand corner. - -
- -
- A copy of the Helium HIP repository will be made in the user's GitHub account and should open - automatically. -
-
- ---- - -## Write a New HIP - -All HIPs follow a consistent format as closely as possible for their content. To get authors -started, a [template](https://github.com/helium/HIP/blob/main/0000-template.md) has been provided in -the HIP repository under the filename `0000-template.md`. - -**Step 1.** Open the HIP template in a second window with this link: - -[https://raw.githubusercontent.com/demogutentag/HIP/main/0000-template.md](https://raw.githubusercontent.com/demogutentag/HIP/main/0000-template.md) - -
- -
Keep this window open, or open the URL in an additional tab.
-
- -
- -**Step 2.** In the primary window, click the `Add file` button in the upper right-hand corner and -select `Create new file` from the dropdown. - -
- -
- -
- -**Step 3.** Give your file a name, the recommended format is `0000-my-new-proposal.md` replacing the -`my-new-proposal` with a relevant title to the proposal itself. - -
- -
- This example creates a proposal to never give up on the Helium Network and never let it down and - is named `0000-astley-incentive.md` -
-
- -
- -**Step 4.** Copy and paste the contents of the page from Step 2 to start. - -
- -
- If you have been authoring a proposal in another location, copy and paste it here, adjusting to - fit the template structure. -
-
- -
- -**Step 5.** Click the green `Commit changes...` button in the upper right-hand corner. - -
- -
- -
- -**Step 6.** In the pop-up window, select the -`Create a new branch for this commit and start a pull request` option. - -
- -
- -
- -**Step 7.** Click the Green `Propose changes` button. - -
- -
- -
- -**Step 8.** Do not click the green `Create pull request` button on this page. Click the grey `Code` -tab. - -
- -
- -
- ---- - -## Make a Pull Request - -A Pull Request, or "PR", is quite literally an ask to the repository maintainers to "pull in" -proposed changes. - -**Step 1.** A new banner will be presented with a green `Compare & pull request` button. Click the -button to start a Pull Request - -
- -
- -
- -**Step 2.** Confirm the Pull Request is to the `helium/HIP` base `main` and the correct changes are -being proposed. - -
- -
- -
- -**Step 3.** Edit the `Title` and `Description` to inform other readers and maintainers what the HIP -is about. - -
- -
- Copy and pasting the Summary from the proposal itself is a good `Description` filler. -
-
- -
- -**Step 4.** Click the green `Create pull request` button. - -
- -
- -
- -**Step 5.** View the newly created Pull Request in the main Helium HIP repository. - -
- -
- -
- ---- - -## Stay Involved - -Once a PR is submitted, authors are asked to keep a watch on them for comments or change requests. -By default, the user to submit a PR will be subscribed via email to receive notifications on PR -activity. - -Timely responses in GitHub and Discord keep the process moving! diff --git a/docs/governance/committees.mdx b/docs/governance/committees.mdx deleted file mode 100644 index c03c62f2c..000000000 --- a/docs/governance/committees.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: committees -title: Committees -pagination_label: Committees -sidebar_label: Committees -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/committees ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Committees are a necessary part of performing key operations, regulating standards, and coming to a -consensus on changes to the Helium Network. - -Committees are often established through [Helium Improvement Proposals][hip] ("HIPs") or out of -rough consensus from a common sense need. - ---- - -## Manufacturing Compliance Committee - -Today, the Helium Community utilizes one Committee, the Manufacturing Compliance Committee ("MCC"). - -The MCC was established by [HIP-19][hip-19] with the purpose to set basic technical, security, and -ethical standards & verifies those standards are met by Hotspot Makers joining the Helium Network -through the [HIP-19][hip-19] process. - -You can find more information about the MCC, Ethics for Makers/Manufacturers, and more [here][mcc]. - -[hip-19]: https://github.com/helium/HIP/blob/main/0019-third-party-manufacturers.md -[mcc]: /hotspot-makers/compliance-committee -[hip]: /hip diff --git a/docs/governance/faq.mdx b/docs/governance/faq.mdx deleted file mode 100644 index a87b43e5f..000000000 --- a/docs/governance/faq.mdx +++ /dev/null @@ -1,278 +0,0 @@ ---- -id: faq -title: Frequently Asked Questions -pagination_label: Frequently Asked Questions -sidebar_label: Frequently Asked Questions -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/faq ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## What Is veHNT? - -veHNT represents the voting power of the Helium Network. - -In the Helium ecosystem, HNT holders can receive veHNT by locking their HNT on-chain for a specified -period in exchange for voting rights and voting power in the HeliumDAO as defined in -[HIP-51](https://github.com/helium/HIP/issues/336). - -Additionally, this provides other benefits, such as earning MOBILE or IOT tokens, if the holder -delegates their veHNT to those subDAOs, respectively. After the lock-up period ends, the same amount -of HNT is released back to the owner's wallet and is now transferable, if needed. - -## What Are The Benefits of Staking HNT after the subDAOs launch? - -Now the Solana migration has been completed, stakers can use their staked veHNT to vote on proposals -in the HeliumDAO and help the DAO make collective decisions, influencing the future of the Network. - -Stakers will additionally be able to delegate veHNT to a subDAO for token rewards. Delegating veHNT -to a subDAO will count towards the DAO Utility Score, the `V` value referenced in -[HIP-51](https://github.com/helium/HIP/blob/main/0051-helium-dao.md#omni-protocol-poc-incentive-model). - -## Where Does My HNT Go if I Stake veHNT? - -If you lock up your HNT for veHNT, your HNT will become veHNT and remain entirely in your wallet's -custody. veHNT ownership is represented by a non-transferable Solana NFT held in your wallet. At the -end of the lock-up period, any received tokens need to be claimed, the position undelegated, and -then after a close position action is taken you will receive HNT back to your wallet 1:1 for the HNT -you staked. - -## What Is a "Lock-Up" Period? - -A lock-up period is a window of time when users are not allowed to transfer their HNT. - -You will incur a lock-up period when you stake your HNT for veHNT. The lock-up period is between 1 -day and 48 months selectable in days but with block granularity. - -Lock-up periods help incentivize long-term holders of HNT and deter short-term speculators and those -with shorter-term interests in the governance of the Network. - -## What is Voting Power? - -Voting power is the weight of your vote towards decisions made by the DAO or subDAO. The more veHNT -you have, the more weight your vote has. - -You can only increase your voting power by staking more HNT or extending an existing veHNT lock-up -period for longer. - -## How to Choose a subDAO to Stake? - -[HIP-51](https://github.com/helium/HIP/blob/main/0051-helium-dao.md#omni-protocol-poc-incentive-model) -defines that all subDAOs return a maximum of 6% of their earnings to their veHNT delegators and is -designed to be an equal maximum reward level across all subDAOs so that no subDAO can buy their way -to a higher DAO Utility score. - -Returns can be lower than 6% in subDAO tokens if the subDAO votes to provide a lower token return in -return for other benefits or similar. - -As more veHNT is delegated to a subDAO, the DAO Utility Score improves, among other factors defined -in HIP-51, which drives greater earnings of HNT for the subDAO. - -As more veHNT holders delegate to a particular subDAO, individual holder earnings will reduce the -amount of net subDAO token earnings as delegators share the 6% subDAO token emissions. - -The more veHNT delegated to a subDAO the more the subDAO Utility score increases and the more HNT -the subDAO gets at each epoch improving the HNT/subDAO Token ratio. But the more veHNT delegated, -the more veHNT holders the 6% will have to be shared between. - -## How Will Staking Work By Using veHNT? - -Anyone can stake any amount of HNT and lock it up for 1 day to 1461 days ( 48 months). You choose -your unstaking date at the time of lock-up or decide to keep it on a rolling lock-up period, called -"constant lock-up" before initiating the start or the veHNT decay process. The HNT staked is -exchanged for veHNT, which provides two benefits: - -- Voting in the Helium DAO on new subDAO proposals and Participating in the Governance. -- Receiving an income if the veHNT is delegated to a subDAO. - -Anyone can delegate veHNT to a subDAO, it's one component of a subDAO's Utility Score. Delegating -veHNT to a subDAO allows the holder to earn subDAO token rewards proportionally based on the subDAOs -rules. - -> For example: If I delegate some veHNT to MOBILE subDAO, I proportionally earn MOBILE rewards -> allocated to veHNT stakers. - -The Helium Network encourages your long-term participation in voting and governance. Those who stake -HNT for 1 day will exchange 1:0.06844627 HNT to veHNT. Those that stake veHNT for 48 months will -receive an exchange of 1:100 HNT to veHNT. Any period in between will be treated on a linear scale -from 0.0684462 to 100. - -> For example, I choose to lock up 10 HNT for six months. I receive 125 veHNT. If I decide to -> unstake immediately, after six months, my veHNT decays to 0 until my 10 HNT unlocks and is -> available to me for use in my wallet. - -A combination of an amount of HNT locked up for a specified duration and the assigned veHNT is -called a "Position". It is possible to own multiple Positions in your wallet. Actions taken on a -Position - like e.g. on the lock-up duration, delegating the veHNT, voting with the veHNT - are all -or nothing options. If a Position owner would like to receive rewards from two SubDAOs, then the -HNT-veHNT Position would need to be split into two Positions - by transferring some HNT to a second -position within the same wallet. Then each position could delegate to a different subDAO. Similarly, -wishing to extend the lock-up duration on parts of a Position requires a similar split by transfer. - -## How Can I Obtain veHNT? - -Staking HNT for veHNT will be done on [Realms](https://realms.heliumvote.com/dao/hnt) See the -[Staking veHNT on Realms](/vote-escrow/realms) documentation - -## Is There a Staking "Genesis" Period? - -For the first ten days after Helium's migration onto Solana, there was a 3x multiplier bonus for new -veHNT stakers. This is called the "Landrush" multiplier. - -New stakers were only eligible to receive this veHNT bonus during the initial ten-day Landrush -period. HNT staked now, after this period will receive veHNT at the normal rate with no multiplier. - -This landrush period ended at 23:59:59 UTC on April 28, 2023. - -For example: - -> Staking 10 HNT during this Landrush period with a lock duration of six months gets 375 veHNT -> (10x12.5x3) that, if a cooldown is selected, decays from 375 to 0 veHNT at the end of the staking -> period, and 10 HNT is returned to the wallet. - -> Staking 20 HNT during this Landrush period with a lock duration of 24 months returns 3000 veHNT -> (20x50x3), and at the end of the staking period, 20 HNT is returned to the wallet. - -## Will I Earn HNT by Staking For veHNT? - -**No.** HNT staked to veHNT will not earn more HNT, it will only return what they staked at the end -of their selected lock-up period. - -However, when you stake HNT into veHNT, you can delegate your veHNT into one or more subDAOs (such -as IOT or MOBILE), and the subDAOs allocate up to 6% of their token emissions to the veHNT owners -delegating to that subDAO. - -> For example: When you delegate your veHNT to the IOT subDAO, you receive IOT every epoch that is -> claimable in your Helium Wallet. If you choose, this IOT can then be burned at the IOT subDAO -> treasury for HNT, or you may hold your IOT tokens, or stake them into veIOT. - -## How much veHNT will I get for each lock-up period? - -The table below shows the approximate HNT to veHNT multiplier for example months of staking - -This value is multiplied by 3x during the first 10 days after the Solana transition and this -multiplier lasts as long as the last lock-up period selected in the first 10 days after the Solana -migration. - -| Months staked | veHNT received | | Months staked | veHNT received | -| :-----------: | :------------: | --- | :-----------: | :------------: | -| 1 week | 0.5 | | 12 | 25.0 | -| 2 weeks | 1.0 | | 15 | 31.2 | -| 1 | 2.0 | | 18 | 37.5 | -| 2 | 4.1 | | 21 | 43.7 | -| 3 | 6.2 | | 24 | 50.0 | -| 4 | 8.3 | | 27 | 56.2 | -| 5 | 10.4 | | 30 | 62.5 | -| 6 | 12.5 | | 33 | 68.7 | -| 7 | 14.5 | | 36 | 75.0 | -| 8 | 16.6 | | 39 | 81.2 | -| 9 | 18.7 | | 42 | 87.5 | -| 10 | 20.8 | | 45 | 93.7 | -| 11 | 22.9 | | 48 | 100.0 | - -## Do I Have to Delegate My veHNT to a subDAO? - -No. You can hold your veHNT as is or delegate to a subDAO at any time. - -:::note - -Changing delegation is allowed, but any delegation changes within a Solana Epoch will void any -delegation rewards within that Epoch. A Solana Epoch is 24 hours long and starts and ends at -00:00:00 UTC time. - -::: - -## How Granular Is The veHNT Linear Decrease? - -The veHNT decay countdown starts when initiated from the Wallet app/Realms, either immediately in -"decay" mode or after a "constant lockup" is unlocked and cooldown started. - -veHNT quantity decay is granulated per second even though the Epoch period is 24 hours. - -It is the current delegated veHNT value at the start of an Epoch that is used for calculating the -subDAO utility score during the Epoch. - -A 48-month lock-in period has approximately 1461 linear steps between 100 veHNT and 0 veHNT. - -> 4 years x 365.25 days epochs per day = 1461 steps - -After 1 day has passed after staking a single 1 HNT for 48 months, the quantity of veHNT in the -wallet will decay from 100 veHNT to 99.86311 veHNT. This decrease will recur linearly over the -remaining 48 months until it hits zero. - -## Can I Increase My Staking Lock-up Period At Any Time? - -Yes. You can increase your lock-up period by extending it to a maximum of 48 months at any time, and -the increase activates at the start of the next epoch. If the veHNT is delegated you must -undelegate, change the period, redelegate, and lose delegation rewards within that 24 hour Epoch. If -those three actions take longer than an epoch or are split over two epochs then delegation rewards -are lost for two Epochs. - -## Can I Decrease My Staking Period For Fast Access to My HNT and Take a Penalty? - -No. You define your lock-up period at the time of staking and cannot unstake or decrease the lock-up -period for any reason. - -## Can I Automate Re-Staking? - -Yes, a constant rolling lock-up period is available called Constant Lock-up. The decay countdown -start point will need positive action to start the lock-up cooldown period. - -> Staking 10 HNT for 4 years will get approx 1000 veHNT and this will be a rolling 4 year period and -> will remain at 1000 veHNT until the decay countdown is activated and this will then decrease -> linearly over 4 years to 0 veHNT and the HNT is returned. - -## Can I Transfer my veHNT or any of the veDNTs to Someone Else? - -No. veHNT and the like are fully non-transferable and represent your voting power in the Network. It -is not a token. It is represented in the wallet by a non-transferable NFT. - -## How Do I Buy veHNT or Any of the veDNTs? - -You cannot buy veHNT, veIOT, or veMOBILE. They are not tradable tokens. veHNT can only be obtained -by staking HNT with a lock-up period. Likewise, for veIOT or veMOBILE. - -veHNT and veDNTs have no price in the larger crypto markets. - -## What Is the DAO Utility Score? - -The DAO Utility score is described in [HIP-51](https://github.com/helium/HIP/issues/336) - -Every epoch, a fixed amount of HNT is allocated to all subDAOs. Each subDAO receives a share of this -fixed amount. The sizes of the shares are determined by the Utility Scores of each subDAO of Helium. - -The higher the Utility Score of a subDAO is in relation to the Utility Scores of all other subDAOs -combined, the higher its share of the total HNT allocated to all subDAOs. As the DAO Utility Scores -are calculated each epoch anew, the share of HNT a subDAO receives may change from epoch to epoch. - -Delegating veHNT to IOT or MOBILE increases the `V` value in the -[HIP-51 DAO Utility Score](https://github.com/helium/HIP/blob/main/0051-helium-dao.md#omni-protocol-poc-incentive-model) -calculation. - -The two other ways the DAO Utility score can be increased are: - -1. Increasing the amount of data usage on the subDAO, i.e., the Data Credits burned. This increases - the `D` value in the Utility Score. -2. Increasing the Data Credits used to onboard the number of Hotspots for that subDAO. This - increases the `A` value in the Utility Score. - -## Will My subDAO Earnings Remain The Same Over The Time Period Lock-Up? - -No, they are calculated and paid to the lock-up position per epoch - daily. They may increase when: - -- More veHNT is delegated in the subDAO you delegated to - your treasury gets more HNT. -- More Hotspot onboarding fees are burned in the subDAO you delegated to. -- More data is transferred and burned in the subDAO you delegated to. - -They may decrease when: - -- More veHNT is delegated in the subDAO you delegated to - your share is reduced -- More veHNT is delegated to other subDAOs - other treasuries get more HNT. -- Your delegated veHNT decays over time after you entered the cooldown. -- More Hotspots are online in other subDAOs with a non-zero onboarding fee. -- More data is transferred and burned in other subDAOs. - -Thus it can be observed that delegating more or all of your veHNT to a specific subDAO has the -opportunity to both increase or decrease your subDAO earnings from delegation. diff --git a/docs/governance/governance.mdx b/docs/governance/governance.mdx deleted file mode 100644 index 95d7f94ab..000000000 --- a/docs/governance/governance.mdx +++ /dev/null @@ -1,183 +0,0 @@ ---- -id: governance -title: Governance -pagination_label: Governance -sidebar_label: Governance -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## What is Helium Governance? - -The Helium Network is the world's largest continuous decentralized wireless network. The process by -which the Network can be modified, whether in its technical architecture, the tokens' economic -model, or meta-governance changes, is governed by the global community of Helium token owners. - -Helium token (HNT, IOT, MOBILE) owners include Hotspot owners, Network users, wireless network -operators, hardware manufacturers, and more. - -Tokens are created by providing some form of work for the Network. For example, transmitting data -packets through the internet on behalf of a network user. Hotspot owners provide public, accessible -wireless coverage. Network users must acquire and burn tokens to send data over the network. Tokens -must be locked for voting on network changes, ensuring long-term stakeholder alignment. - -Anyone participating in the Helium ecosystem can submit a Helium Improvement Proposal (HIP) as a -first step to modifying the Network. All HIPs are published in the public Helium GitHub repository, -then discussed and debated in public forums, including the Helium community Discord server, and on -monthly Community Calls. Any Helium token owner is eligible to vote on HIPs. To vote, a Helium token -owner must first lock their tokens for a period of time, up to four years, which grants the owner -voting power determined by the number of locked tokens and the lock duration. A 2/3 supermajority of -the quorum passes proposals. - -The Helium Foundation serves as a steward for the governance process. The Foundation established the -initial framework and managed the open Helium GitHub repositories. The Foundation does not vote on -HIPs but does vet proposals for compliance with the law and technical feasibility. The Foundation’s -role is to provide expert advice and guidance and to implement HIPs after they have passed. - -Information about governance is subject to change as the Helium Network constantly evolves. It is -led by the open-source community that continues to build it. - ---- - -## Terms - -- **Wallet** - A digital application designed for interacting with blockchain-based applications. - Wallets enable users to store and manage their digital assets, such as digital tokens and NFTs. -- **Blockchain** - A shared, immutable ledger that facilitates the process of recording transactions - and tracking assets in a business network. An asset can be tangible (a house, car, cash, land) or - intangible (intellectual property, patents, copyrights, branding). Virtually anything of value can - be tracked and traded on a blockchain network, reducing risk and cutting costs for all - involved.[^1] -- **Solana** - A blockchain that uses a proof-of-stake ("PoS") mechanism to provide smart contract - functionality as well as a mechanism called proof-of-history ("PoH"), which uses hashed timestamps - to verify when transactions occur. -- **Token** - Tokens are digital assets that utilize cryptography for secure transactions, represent - value, and can be used for various purposes within a decentralized network or ecosystem. -- **Non-Fungible Token ("NFT")** - A unique digital identifier that is recorded on a blockchain and - is used to certify ownership and authenticity. It cannot be copied, substituted, or subdivided. -- **Consensus Protocols** – A set of rules that define the instructions for how to be an autonomous - participant in a distributed computer network and come to an agreement about the exact state of - common data. -- **Node** - Refers to individual devices or computers that participate in maintaining the network - by storing a copy of the blockchain, validating transactions, and relaying information to achieve - consensus. -- **Validators** - A distributed network actor responsible for verifying and validating transactions - and blocks, maintaining the network's security and consensus. -- **Proof-of-Stake ("PoS")** - A PoS system is a type of blockchain consensus protocol that achieves - verification by selecting validators in proportion to their quantity of holdings in the associated - cryptocurrency. -- **Proof-of-History ("PoH")** - A consensus protocol unique to Solana, Proof-of-History is a - verifiable and sequential timestamping mechanism that provides a trustless and efficient ordering - of events in the blockchain. -- **Helium** - A global decentralized wireless network of networks utilizing a token-incentive - model. -- **Helium Improvement Proposals ("HIP")** - A bill for changes to the network. -- **Discord** - A web-based community chat platform. -- **GitHub** - A web-based platform that allows developers to collaborate, manage, and store their - code repositories. -- **Repository** - A storage location that contains all the files, documentation, and version - history of a project. -- **Realms** - A platform for decentralized projects to manage token-based governance operations and - manage token-based governance operations. -- **Helium Network Token ("HNT")** - The native token of the Helium Network, used for incentivizing - and securing the decentralized wireless network of networks through redemption and swap features. -- **IOT subNetwork Token ("IOT")** - A token specific to the LoRaWAN Network, used for incentivizing - and securing the decentralized wireless network for IoT devices. -- **MOBILE subNetwork ("MOBILE")** - A token specific for the 5G CBRS Network, used for - incentivizing and securing the decentralized wireless network for Cellular/Mobile devices. -- **Staking (or “Lock Up”)** - The act of temporarily locking up tokens as collateral to participate - in block validation and consensus mechanisms, earning rewards for supporting network operations or - generating Voting Power. -- **Voting Power** - 100 veHNT is more than ten veHNT. The higher amount would mean you have more - weight in deciding vote outcomes. The more HNT you stake for veHNT, the more voting power you - have. -- **Vote Escrowed ("ve")** - A position created by staking your tokens that only functions for - Network or subNetwork voting. Vote Escrowed positions show up in wallets as NFTs and are - non-transferrable. -- **veHNT** - A position created by staking your HNT. Used for voting on proposals that affect the - entire Helium Network of Networks model. -- **veIOT** - A position created by staking your IOT. Used for IOT Network governance. -- **veMOBILE** - A position created by staking your MOBILE. Used for MOBILE Network governance. - ---- - -## Evolution of Governance - -At the beginning of the Helium Network, the Network Founders designed their own Blockchain, the -Helium Blockchain (Helium Layer 1 or L1), written in Erlang, a general-purpose programming language -for early telecommunications systems. - -As the Network began to store large amounts of data, the chain became slow and costly, both to -operate and to use. The Solana Blockchain was proposed as an alternative in HIP 70 and voted and -approved by the Helium Community. The passing of HIP 70 ushered in a subsequent Blockchain migration -and increased tooling for voting and governance. - -The governance history of the Helium Network can be broken thus far into three phases. Each phase -contains a record of past voting. These votes reflect the community's decision-making process and -provide insight into the evolution of the network. The next part of this document will explain the -evolution of voting and how you can view past voting history: - -- Phase 1: [Voting in Discord by raising hands](governance/phase-1) -- Phase 2: [Helium Vote on-chain voting on the Helium L1](governance/phase-2) -- Phase 3: [Realms on Solana](governance/phase-3) - ---- - -## Participate - -Ready to participate? Join the global decentralized wireless network and participate in Helium -Governance, including specific HIPs, voting procedures, and Working Groups. Refer to the provided -links and resources. - - - -1. **Discord**: The Helium Discord platform serves as the primary communication channel for the - Helium Network Community. It offers real-time discussions, support, and engagement opportunities. -2. **GitHub Repository**: The HIP GitHub repository provides access to the Helium Improvement - Proposals and related discussions. -3. **Social Media and Ecosystem Voices**: The Helium Foundation and various influencers on platforms - like Twitter, Discord, and YouTube provide updates, debates, and explanations of HIPs and - governance-related matters. -4. **Monthly Community Calls**: The Helium Community holds monthly video calls (led by the Helium - Foundation). These typically happen on the 4th Wednesday of each month at Noon ET. Each call has - an open agenda, and any community member can join and add items to the agenda to be discussed. -5. **Community Calendar**: The Helium Foundation maintains a calendar of ecosystem events and - happenings. You can access and subscribe to this at: - [www.helium.foundation/community-calendar][community-calendar]. - -### Socials + Ecosystem Voices - -As a network steward, the Helium Foundation posts important governance news, calls to vote, and more -on Twitter. [Follow @HeliumFndn][foundation-twitter] on Twitter to stay up to date. - -As a decentralized network, numerous voices discuss governance, host debates, and explain HIPs in -layman's terms. You can find many of these influential voices in Discord, on Twitter, or on YouTube. - -If you'd like to have your name or channels listed and linked here as a governance resource, submit -a ticket in the Helium [Docs Repo][docs-issues]. - -[discord]: https://discord.gg/helium -[docs-issues]: https://github.com/helium/docs/issues -[community-call-notes]: - https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0 -[community-call-video]: https://helium.foundation/community-call -[foundation]: https://www.helium.foundation -[helium-dao]: https://www.realms.heliumvote.com/dao/hnt -[iot-dao]: https://www.realms.heliumvote.com/dao/iot -[mobile-dao]: https://www.realms.heliumvote.com/dao/mobile -[realms]: https://app.realms.today/ -[realms-tutorial]: /vote-escrow/realms -[github-hip]: https://github.com/helium/HIP -[discord-hip]: discord://discord.com/channels/404106811252408320/730243559873052754 -[hip-docs]: /hip -[foundation-twitter]: https://twitter.com/HeliumFndn -[realms]: /governance/realms -[bip]: https://github.com/bitcoin/bips -[community-calendar]: https://www.helium.foundation/community-calendar - -[^1]: https://www.ibm.com/topics/blockchain diff --git a/docs/governance/hip.mdx b/docs/governance/hip.mdx deleted file mode 100644 index fccf62d43..000000000 --- a/docs/governance/hip.mdx +++ /dev/null @@ -1,170 +0,0 @@ ---- -id: hip -title: Helium Improvement Proposals -pagination_label: Helium Improvement Proposals -sidebar_label: Helium Improvement Proposals -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hip ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - ---- - -## Purpose and Scope - -Helium Improvement Proposals (HIPs) define modifications to the open-source Helium protocol and -Network itself. Proposals can modify economics and incentives, technical properties, or -meta-governance, including the governance process or changes to the rules controlling how HIPs are -managed. Anyone in the Helium ecosystem can introduce a HIP. All HIPs are publicly available in the -open HIP Repository, managed by the Helium Foundation on behalf of the community. - -Users participate in network-wide token holder voting. You must have tokens to vote on Helium -Improvement Proposals. The Helium Network and subNetworks vote with three tokens: HNT, IOT, and -MOBILE. These tokens do not inherently provide governance rights and privileges and must be locked, -in a method called Staking, to create a user's voting power. Voting power is a multiplication of -tokens staked and the time duration of staking. Staking aligns a user with the long-term success of -building a decentralized wireless network. - -- Holders of HNT vote on proposals that concern meta governance, economic, or technical changes to - the entire protocol. Proposals that exclusively affect a subNetwork do not fall into HNT voting. - -- Holders of IOT tokens vote on proposals concerning the IoT (LoRaWAN) subNetwork. These proposals - include economic, technical, or governance changes to the IoT subNetwork. - -- Holders of MOBILE tokens vote on proposals concerning the Mobile (5G) subNetwork. These proposals - include economic, technical, or governance changes to the Mobile subNetwork. - -## Proposing a HIP - -Anyone can create a HIP by submitting a Pull Request in the HIP Github Repository. - -Ideas often are sparked through community discussion in the Official Helium Discord, which is -managed and owned by the Helium Foundation. The appropriate channel for new HIP ideas is -#hip-discussion. After an initial discussion to vet an idea, HIP Authors make a copy (“fork”) of the -HIP Repository and create a new one, titled with a name and '.md' to designate a Markdown file. All -instructions are provided in the format from the HIP Template within the repository. This new file -will be the basis of their Helium Improvement Proposal. - -After a HIP Author creates a Pull Request, the HIP is submitted for review by the Helium Foundation. -It will be reviewed for editing by the community and designated Helium Foundation HIP Editors. The -Helium Foundation acts as a steward in the HIP Editing Process, ensuring HIPs are clear, concise, -informed on the nuances of the network, and able to be read and interpreted by a typical reader with -the fundamental familiarity of the Helium Network. - -During the HIP Editing Process, a HIP Editor defines the scope of the HIP and determines the Voting -Requirements for the community. Voting Requirements comprise which token should be used to cast a -vote and which subnetwork this Proposal affects. Token holders are eligible to vote based on the -subNetwork that the HIP impacts. After HIP Editing, the HIP is merged into the public repository of -all documented Helium Improvement Proposals. The Helium Foundation creates the status of the HIP, -and a new HIP-specific channel in Discord is opened for community discussion. - -HIPs are managed entirely from the HIP GitHub repository, which is public and fully transparent. -Read the Steps to Create a HIP to understand how to bring an idea into a proposal. - -Discussion on HIPs occurs on both the Official Helium Discord and within the GitHub repository as -comments. All community members are able to participate in the governance process at any stage. - -View, create, or comment on a HIP at: www.github.com/helium/hip - ---- - -## HIP Editors - -HIP Editors support the governance process by moving HIPs through each stage of their lifecycle. -They review new HIPs, flag formatting and structural issues, and keep the GitHub Repository current. -Today, there are currently two HIP Editors on the Helium Foundation team who are supported -byadditional subject matter experts. To contact a HIP editor ask in the #hip-discussion channel on -Discord: [https://discord.gg/helium][discord] - ---- - -## Steps to Create a HIP: - -1. **Idea Generation:** Stakeholders propose ideas for improving the Helium Network, including - technical, economic, and meta/process-related changes. -2. **Vetting:** The idea is shared and discussed within the Helium community, typically via Discord, - to assess initial support and identify previous discussions. -3. **Proposal Writing:** The author of the idea prepares a Helium Improvement Proposal (HIP) using - the provided markdown template. The template can be adapted to suit the information required to - illustrate an idea. - - - -- Author is ready to draft a HIP. -- Author seeks out the HIP Template in HIP 7 (also located in the Discussion tab of the HIP - Repository). -- Author drafts a HIP within the template. -- Author makes changes to the template as needed to craft their argument. -- During drafting, Author may seek other information and knowledge to craft their proposal. -- Author may seek feedback or input from collaborators. -- Author may seek feedback or input from Helium Foundation - -4. **Pull Request Submission:** The Author forks the Helium GitHub repository, adds the HIP file - with a title (without allocating a number), commits the changes, and submits a pull request. – - see step-by-step guide to using Github [here](/write-a-hip). - -- Author navigates to Github in the web or desktop application. -- Author forks the Helium HIP Repository. -- Author creates a new branch to submit changes to. -- Author inputs their HIP as a new file within the branch. -- Author submits a branch as a pull request to the helium/hip repository. - -5. **HIP Review:** A HIP Editor reviews the submitted pull request. They check for adherence to the - outlined standards, focusing on formatting and structure rather than the proposal's substance. - -- HIP Editor received GitHub notification of new PR. -- HIP Editor reads the draft HIP. -- HIP Editor adds edits and comments for clarity, consistency, grammar, punctuation, formatting and - viability. -- HIP Editor submits edits to Author for revision. -- HIP Editor requests changes. -- At the same time, the HIP Editor begins a conversation with the HIP Author on Discord or Github to - make sure they are available for questions and engage the Author if more clarity or revision is - needed. -- HIP Editors define the Voting Requirements for the HIP and confirm the voting token. . -- If all Edits are made and accepted, the HIP will be merged. -- If all Edits are not made and accepted, the HIP will remain in Draft as a PR. -- Once merged into the main HIP Repository, a HIP Editor creates an issue ticket, adds basic - information about the HIP, tags, and updates the README file with status. - -6. **Discussion and Approval:** The HIP enters the discussion phase, during which comments and - feedback are provided on the associated GitHub issue or Helium Discord Community. Community calls - are scheduled to discuss the HIP. Rough consensus and motivation towards making timely changes - are used to achieve approval to move towards proposal voting. - -- HIP Editors have finished merging the file into the main Repo and move on to opening discussion. -- HIP Editors create a new channel in Discord -- HIP Editors title the channel, add essential channel information, and begin the discussion. -- HIP Editors or Community Managers make an announcement letting the community know the HIP is live - and open for discussion. -- From here on, HIP Editors monitors discussion. -- HIP Editors engage Authors to present HIPs at a following upcoming Community Call, or other Public - Community events. -- HIP Editors monitor discussions for rough consensus. -- HIP Editors may use non-binding Temperature Check votes to determine if a rough consensus is - achieved to move the HIP to a vote. -- If rough consensus is achieved, HIP Editors inform Helium Core Devs of a proposal that requires - voting in the Realms voting and governance platform. -- HIP Editors prepare the vote, including proposal descriptions, and announcements to the community, - and inform the Author. -- Helium Core Devs make the proposal available for the community to vote on in Realms. - -Vet an idea in the community by joining the #hip-discussion channel on Discord: -[https://discord.gg/helium][discord] - ---- - -## Implemented and Vetoed Proposals - -All HIPs that have passed, been implemented, or vetoed in the Helium Community can be found at -[Helium HIP repository on GitHub][hip-repo]. Not all HIPs get to the vote stage or pass -super-majority voting, so you will see different status indicators against HIP numbers as you go -down this list. Just like bills that become law, HIPs often amend each other. To get a full -understanding of how HIPs have been implemented and how each impacts another, join the Helium -Discord. Long-time Community Members are a wealth of knowledge and can help folks understand changes -over time. - -[discord]: https://discord.gg/helium -[hip-repo]: https://github.com/helium/HIP/blob/main/README.md diff --git a/docs/governance/phase-1.mdx b/docs/governance/phase-1.mdx deleted file mode 100644 index bfca99521..000000000 --- a/docs/governance/phase-1.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: phase-1 -title: Phases of Helium Governance -pagination_label: Phases of Helium Governance -sidebar_label: Phase 1 Voting in Discord -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/phase-1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Phase 1: Voting in Discord - -When the Community was using Discord for voting, the participation was low, and developers -prioritized ‘shipping code’ for quick changes to the protocol. Discord votes often happened through -hand-raising, represented by tools available in the chat application. - -### Where can I see what was voted on? - -HIP 1 to HIP 38 were voted on through Discord. Not all HIPs between HIP 1 to HIP 38 became proposals -that the community voted on. Some were closed, abandoned, or withdrawn by the Authors. You can check -the final status of these HIPs in the README at www.github.com/helium/hip. Each HIP has a -corresponding Tracking Issue holding more information about the events around a HIP. - -Each HIP has a corresponding HIP Discussion Channel in the Helium Discord. You can read the entire -chat of discussion in the “HIP-ARCHIVE-1” section of Discord here: https://discord.gg/helium - -### Where can I see the results of the votes? - -The Community documented the outcome of Discord votes in the Helium HIP Repository on GitHub. You -can review the results under README at www.github.com/helium/hip. - -Related program deployment history can be found on the Tracking Issue ticket itself. Each HIP has a -Tracking Issue associated with it that can be found linked in the “Status” section of the README -(linked above). The code of the Helium Network is available in the Helium Repository. The Repository -is fully open-source and available for public review: www.github.com/helium. - -### How can I see how each user/wallet individually voted? - -At this time, the Helium Community did not conduct wallet voting. From HIP 1 to HIP 38, you cannot -view voting results by an individual. - -### How do I vote? - -The Helium Community no longer votes through Discord. diff --git a/docs/governance/phase-2.mdx b/docs/governance/phase-2.mdx deleted file mode 100644 index 771d69152..000000000 --- a/docs/governance/phase-2.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: phase-2 -title: Phases of Helium Governance -pagination_label: Phases of Helium Governance -sidebar_label: Phase 2 Helium Vote -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/phase-2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Phase 2: Helium Vote - -As the Helium Network quickly grew, the Community moved to utilize their custom form of on-chain -voting with Heliumvote.com (also, https://helium.vote/). This became the sole platform for proposal -voting from November 2021 until the blockchain migration on April 18th, 2023. Users cast an on-chain -vote by submitting a Data Credit (DC) burn transaction. The movement to on-chain voting was a step -to mature the Helium Community voting processes and formalize voting with an immutable record. - -### Where can I see what was voted on? - -Heliumvote.com holds all the past results of proposal voting on the Helium L1 Blockchain, starting -with HIP 39 and ending with HIP 81. There, you can view proposals, how many votes were submitted, -and the HNT weight represented in voting populations. The source code can be found here: -www.github.com/helium/helium-vote. - -### Where can I see the results of the vote? - -You can see the results of the vote on Heliumvote.com directly. Each proposal that was voted on will -be found under “Closed Votes”. - -### How can I see how each user/wallet individually voted? - -Users can query the old Helium Blockchain through a publicly supplied data analytics tool hosted on -Metabase: https://etl.dewi.org/. - -Additionally, during the helium.vote phase of voting, users submitted Data Credit (DC) burn -transactions to a Helium-specific wallet address to cast their on-chain vote. This allowed -helium.vote to query each wallet address for all transactions and display total vote numbers for -“For” or “Against” vote tallies. These wallet addresses with DC burn transactions can be read by -examining the open-source code within the helium-vote Repository: www.github.com/helium/helium-vote -and utilizing the legacy Helium Explorer to query the old Helium Blockchain: -https://explorer-old.helium.com/. If you would like to review the results of a vote by individual -wallet, feel free to utilize these instructions above or reach out to the Helium Foundation for -assistance. - -### How do I vote? - -All voting ceased to function on Helium Vote on April 18th, 2023, when the Helium Community migrated -to the Solana Blockchain. As of April 18th, 2023, all voting is conducted on Realms. diff --git a/docs/governance/phase-3.mdx b/docs/governance/phase-3.mdx deleted file mode 100644 index 51eef52aa..000000000 --- a/docs/governance/phase-3.mdx +++ /dev/null @@ -1,132 +0,0 @@ ---- -id: phase-3 -title: Phases of Helium Governance -pagination_label: Phases of Helium Governance -sidebar_label: Phase 3 Realms on Solana -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/phase-3 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Phase 3: Realms on Solana - -Realms is the most recent and current phase of Helium Governance. Realms is a Solana native tool for -decentralized governance. This tool replaces the previously used Helium Vote system. It is the -platform adopted by the Helium Community in the passing of HIP 70 and includes features for staking, -delegating, and on-chain voting. HIP 70 defined the Vote Escrowed model of token holder voting as -the next phase for Helium Governance. - -Realms enables token holders to actively participate in the governance process by staking their -tokens and casting votes on proposed changes and decisions. - -### Where can I see what was voted on? - -You can view past and current proposals on Realms by navigating to either the Helium Network or -subNetworks at: - - - -- Helium (HNT): [realms.heliumvote.com/dao/hnt](https://www.realms.heliumvote.com/dao/hnt) -- IoT subNetwork (IOT): [realms.heliumvote.com/dao/iot](https://www.realms.heliumvote.com/dao/iot) -- Mobile subNetwork (MOBILE): - [realms.heliumvote.com/dao/mobile](https://www.realms.heliumvote.com/dao/mobile) - -You’ll also always find the in progress and final statuses in the Helium HIP Repository at: -www.github.com/helium/hip. - -### Where can I see the results of the vote? - -You can view all past and current results of a vote on Realms by navigating to the links above and -clicking directly into the proposal. Programs deployed in relation to these proposals can be found -in the helium-program-library and within the full open-source Helium Repository at: -www.github.com/helium. - -### How can I see how each user/wallet individually voted? - -The Realms “Explore” tab allows you to search for votes by wallet address. Please note that Helium -Network's rules for voting differ from the default rules on Realms. As a result, viewing the results -on realms.today is not representative of the actual outcome under the Helium Network's rules for HIP -voting. For the correct results, please make sure to view them on GitHub. - -The results of a proposal vote can also be reviewed by querying the Solana Blockchain and related -spl-governance contracts. - -You can view the Helium governance contracts on Solana here: - - - -#### Contract for delegation of tokens to subNetworks for rewards - -``` -hdaoVTCqhfHHo75XdAMxBKdUqvq1i5bF23sisBqVgGR -``` - -#### Default spl-governance contract to govern our own contracts and council - -``` -hgovkRU6Ghe1Qoyb54HdSLdqN7VtxaifBzRmh9jtd3S -``` - -#### Contract for governance to create Helium-specific voting power rules - -``` -hvsrNC3NKbcryqDs2DocYHZ9yPKEVzdSjQG6RVtK1s8 -``` - -### How do I vote? - -Any token holder is eligible to vote. Token holders may go through different steps to vote depending -on their level of onboarding and familiarity with the Solana Blockchain. - -Users need to have one of the Helium Network or subNetwork Tokens: HNT, IOT, or MOBILE. After this, -they need to be familiar with the Solana Network and have a Solana-compatible wallet. A wallet -allows users to interact with applications that utilize the Blockchain as a backend for data -storage. A wallet is straightforward to use and generally is a mobile application or browser plugin -for easy interactions with websites. - -After a user has their wallet, they must acquire some SOL to complete transactions on the Solana -Blockchain. SOL is the native token of the Solana Blockchain and is required to use and store data -on the blockchain. The amount of SOL required per transaction depends on if a user is completing a -one-time transaction with a small amount of data or is storing data for a longer amount of time that -will need to be called later. - -Once a user is onboarded with a wallet, Helium tokens, and some SOL for transactions, they can begin -using and interacting with Realms, the Helium Network’s tool for voting. When a user is ready to use -Realms, they will need to lock or stake their tokens for voting power, creating a vote escrowed -position with their tokens. This vote escrowed position gives them the ability to cast votes on any -active proposals for the Helium Network or subNetwork they let you quickly. - -**A detailed step-by-step description of moving from onboarding to voting is outlined below. All -steps that may require the signing of a transaction are noted as such:** - -1. Establish an account on a Solana-compatible wallet. The Helium Wallet is a recommended choice - built for Helium users specifically, but any Solana-compatible wallet will perform all the - functions you need. -2. Acquire tokens by providing coverage for the network or through a liquidity provider in the - Solana Ecosystem. The tokens you have depend on the network you are providing coverage for or the - Network or subNetworks you wish to participate in the governance of (HNT, IOT, or MOBILE). - _Requires signing a transaction_ -3. Acquire SOL to perform transactions on the Solana Blockchain. _Requires signing a transaction_ -4. Navigate to Realms at the addresses above. -5. Connect your wallet. _Requires signing a transaction_ -6. Navigate to “my governance power.” -7. Select “Lock Tokens”. This is how you stake tokens for voting power. -8. Follow the on-screen instructions to “Lock” your tokens. You can lock as little as one token or - as many as you have. -9. You can choose up to 4 years to lock or as little as six months. -10. You will need to choose “Decaying” or “Constant” -11. Decaying means the lockup period begins to countdown immediately. -12. Constant means the lockup period will remain until the user decides to start the countdown. -13. Select “Lock Tokens” to complete the action. _Requires signing a transaction _ -14. Locate an active proposal. -15. Cast your vote with options “Yes” or “No”. _Requires signing a transaction_ - -A step-by-step user guide to staking on Realms can be found in Helium Docs: -[here](/governance/realms) - -View the index of past HIP decisions on Github -[here](https://github.com/helium/HIP#helium-improvement-proposals-hip) - -View the index of implemented HIPs on Docs [here](https://docs.helium.com/hip#implemented-hips) diff --git a/docs/governance/realms.mdx b/docs/governance/realms.mdx deleted file mode 100644 index fe65f7f1d..000000000 --- a/docs/governance/realms.mdx +++ /dev/null @@ -1,105 +0,0 @@ ---- -id: realms -title: Realms -pagination_label: Realms -sidebar_label: Realms -description: Helium Documentation -slug: /governance/realms ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -To approve or deny changes to the blockchain, economics, or governance of the Helium Network; The -Helium Network leverages on-chain voting which is open to the entire community. This on-chain voting -is facilitated through the website [Realms][realms]. - ---- - -## How to Vote on Realms - -Like many other Solana Ecosystem projects, Helium uses Realms to organize and manage governance, -vote escrowed tokens, delegation, and more. Using the links below, you can cast your vote for the -subDAO of which you seek to impact and contribute to. - -Ensure that you have a Solana-ready wallet that is funded with some SOL and one of the network -tokes: HNT, IOT, or MOBILE. - -
-
- - -
-
- The Helium DAO in Realms with an active test - vote. Shown on desktop and mobile. -
-
- -### Signing Into Realms - -Use your account that holds your veHNT positions to sign in to Realms. The same account can be used -for all platforms, but it must have veTokens for the specific DAO or subDAO hosting the vote. - -The links for the Realms governance portals are: - -- [https://realms.heliumvote.com/dao/hnt][realms-hnt] -- [https://realms.heliumvote.com/dao/iot][realms-iot] -- [https://realms.heliumvote.com/dao/mobile][realms-mobile] - -Sign in to these using the in-app browser from the Helium Wallet App. - -
- -
- This user is logged in with their 4qPt5... account. -
-
- -### Casting Your Vote - -After you have reviewed the proposal, casting your vote is as easy as issuing a Solana transaction -for "Yes" or "No". - -Note: You will need a bit of Sol to cast your veTokens for a vote. - -
-
- - -
-
After voting, you can leave a comment supporting your stance.
-
- -### Understanding Vote Power - -When you vote your veTokens, all positions will be attributed to your vote choice. Token positions -cannot be split within one vote on a single account. - -Your vote is calculated at the time your vote is submitted. If your position is in 'decay' mode, -voting sooner means you apply greater voting power. Conversely, if a position is extended to added -to, a vote can be relinquished and re-voted to apply the new voting power. - -
- -
A vote can be changed by first relinquishing it.
-
- -[realms]: https://realms.today -[realms-hnt]: https://realms.heliumvote.com/dao/hnt -[realms-iot]: https://realms.heliumvote.com/dao/iot -[realms-mobile]: https://realms.heliumvote.com/dao/mobile -[discord]: https://discord.gg/helium -[staking]: /vote-escrow/realms -[swap-utility]: /sol-token#swap-utility diff --git a/docs/governance/voting.mdx b/docs/governance/voting.mdx deleted file mode 100644 index 3639b4f08..000000000 --- a/docs/governance/voting.mdx +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: voting -title: Voting -pagination_label: Voting -sidebar_label: Voting -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /voting ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -To go from a proposed HIP to a vote, the Helium Community follows the process initially laid out in -HIP 7. Rough consensus and running code are critical factors for achieving approval. Rough consensus -is achieved In partnership with HIP Authors, as well as non-binding Temperature Checks in the Helium -Discord. Temperature Checks allow the community and all stakeholders discussing the HIP to signal -readiness or suggest more time for discussion. HIPs progress through different stages, including -Draft, In Discussion, Approved, Deployed, or Rejected. - -Read the HIP 7 Process here: https://github.com/helium/HIP/blob/main/0007-managing-hip-process.md - -## Blockchains + On-Chain Voting - -The Helium Network, uses on-chain voting to maximize inclusive participation and maintain a publicly -auditable voting record. On-chain voting means storing a piece of data on a Blockchain. The -Blockchain acts as an immutable ledger. To store data on a Blockchain, users must pay a small -transaction fee, which covers the data storage cost permanently. The Helium Network utilizes the -Solana Blockchain for blockchain-based data storage. The Solana Blockchain has fast processing times -and low fees, keeping costs accessible to all participants for small transactions like voting and -governance. Storing voting data on a Blockchain ensures transparency and immutability of the voting -process. - -Today, the Helium Network utilizes the tool Realms for on-chain voting. Since the passage of HIP 51- -53, the Helium Network established the distinction between Networks and subNetworks, currently -represented by a token for each. HIP 51 - 53 also established the Vote Escrowed Model of token -Staking for Voting Power. - -## The veToken model - -The veToken model originated from Curve (veCRV) as a native token initiating a lockup and creating -voting rights. Curve’s native token is CRV and has three functions: voting, staking, and boosting -yield. To perform any of those functions, CRV is required to be locked in the form of veCRV. The -"ve" in veToken stands for "Voter/vote escrowed." Today, this model has been emulated by various -DeFi protocols within many Layer 1 ecosystems. The Helium Network has adopted the model originally -introduced and passed by the community in HIP 51. - -The veToken initiatives within the Helium Network serve two primary purposes: maximizing rewards, -specifically for protocol emission earnings and governance. Governance seeks to establish the best -outcomes for new projects, new initiatives, and for the future of decentralized wireless. - -## The Value of veTokens for Governance - -In the context of the Helium Network, the veToken model’s primary use is to establish voting -strength and governance rights. The additional on-chain object (the veToken) represents that -wallet’s voting strength. - -The veToken model requires users to stake the underlying token, locking the tokens up for a period -of up to four years. The longer the staking period, the greater the voting strength. By locking up -tokens, economic interests and voting rights are effectively aligned. The native token holders -retain the tokens' economic value and utility, while the veToken assumes the voting rights. All -Helium veTokens are non-transferable, ‘soulbound,’ and have zero intrinsic economic value. They are -represented by an NFT in your Helium Wallet App. - -Visit Realms, the Helium Network, and subNetworks at: - -- Helium (HNT): [realms.heliumvote.com/dao/hnt][realms-helium] -- IoT subNetwork (IOT): [realms.heliumvote.com/dao/iot][realms-iot] -- Mobile subNetwork (MOBILE): [realms.heliumvote.com/dao/mobile][realms-mobile] - -## Staking - -To vote in the Helium Network for changes to either the Network at large, the IoT (LoRaWAN) -subNetwork, or the Mobile (5G) subNetwork, a participant must stake tokens: HNT, IOT, or MOBILE -tokens. - -Staking is a process of locking up a token amount (as little as one token) for a specific period of -time in an on-chain program on the Solana Blockchain. This program defines the parameters for -lockup. In the Helium Network and subNetworks, users can stake tokens for up to 4 years. Staking -allows users to make a commitment to the future, creating long-term alignment to increase the value -of the Network. - -:::note How to stake tokens - -For a full walkthrough on how to stake your tokens to the Helium Network or one of its subNetworks, -see the [Realms Staking][voting-power] guide. - -::: - -## Voting Power - -Specific network tokens will give you Voting Power in the designated Network or subNetworks. Voting -Power is your token amount multiplied by the duration of a lock-up period. Voting Power creates a -weight of your vote against others. This Voting Power enables those with strong incentive alignment -with the network to have greater influence over governance decisions. The function of staking and -Voting Power applies to any new subNetworks in the future, as per the community-passed and approved -HIP 51. - ---- - -## Vote Escrowed Positions as NFTs - -When you stake a token, you'll receive a veToken position in your wallet. ‘ve’ represents the Vote -Escrowed position created by staking your tokens for a voting power multiplier. For all users, the -veToken positions will be shown in a web3 wallet as Non-Fungible Tokens (NFTs). They are not -tradable or transferable and are considered ‘soulbound’ to your wallet. Vote Escrowed simply means -the tokens sit in an escrow period until the staking, or locking, position is over and is only to be -used for voting and governance while in escrow. - -### veHNT - -The [Helium Network][realms-helium] and the Helium Network serve as the overarching system that -enables a multitude of networks (subNetworks) to exist. As such, veHNT's role in network governance -is in matters affecting the entire network. For example, a proposal affecting HNT emissions would be -voted on using veHNT. - -Additionally, veHNT can be [delegated][delegate] to a subNetwork in order to earn a portion of that -network's tokens. - -### veIOT - -The [IOT subNetwork][realms-iot] focuses on the original vision of the Helium Network, supporting -the growth and development of IoT devices and applications. Staking your IOT tokens to the IOT -subNetwork grants veIOT which can be used to vote on matters specific to the IOT network. For -example, a proposal affecting proof of coverage behavior for IoT Hotspots. - -### veMOBILE - -The [MOBILE subNetwork][realms-mobile] is dedicated to the growth and expansion of the Helium -Network in the mobile and telecommunications sectors. Staking your IOT tokens to the IOT subNetwork -grants veIOT which can be used to vote on matters specific to the IOT network. For example, a -proposal affecting proof of coverage behavior for IoT Hotspots. - ---- - -## Supermajority - -A proposition is deemed 'Approved' and accepted by the community if it achieves a super-majority of -66% of the Voting Power. This is not a new rule for the Helium Community and was first established -in Phase 2 of Governance. - -The duration for which a proposal must be made available for voting is not predetermined. Generally, -voting occurs within seven days. - -## Quorum - -A quorum of tokens represented must be met to certify the proposal as a valid outcome. The quorum is -100,000,000 tokens represented at the time of the vote in the vote results. This quorum is equal -across the Network and all subNetworks. If a proposal does not reach this quorum, the proposal will -automatically fail. Even if the proposal received a 66% super majority of Voting Power, the proposal -did not reach quorum and therefore is invalidated. - ---- - -[realms]: https://www.realms.today -[realms-helium]: https://realms.heliumvote.com/dao/hnt -[realms-iot]: https://realms.heliumvote.com/dao/iot -[realms-mobile]: https://realms.heliumvote.com/dao/mobile -[delegate]: /vote-escrow/realms#delegating-stakes -[voting-power]: /governance/faq diff --git a/docs/governance/working-groups.mdx b/docs/governance/working-groups.mdx deleted file mode 100644 index 94081bb34..000000000 --- a/docs/governance/working-groups.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -id: working-groups -title: Working Groups -pagination_label: Working Groups -sidebar_label: Working Groups -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/working-groups ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Working Groups - -The People’s Network continues to see innovation fueled by community engagement and strong feedback -loops. Working Groups are small circles of highly engaged members of the community dedicated to -understanding specific aspects of the Helium Network, identifying challenges and opportunities, and -advocating a path forward to the larger community based on thoughtful consideration. - -The Helium Community often establishes Working Groups based on several high-level needs: - -1. Research & Development -2. Stewardship & Guidance - -Working Groups self-organize and sunset as needed. They are volunteer-based. - -You can find more information below about all _active_ working groups. - -### IOT Working Group - -The IOT Working Group was created to develop guidance on improvements to -the IOT network. The Working Group is made up of volunteers and stewarded by the -Helium Foundation. The IoT network is Helium’s original and largest sub-network. During its long -history, it has been governed by some of the most important Helium Improvement Proposals (HIPs) ever -published ([HIP-10][hip-10], [HIP-15][hip-15], [HIP-17][hip-17], [HIP-19][hip-19], etc). Its -continued success depends on the Working Group's ability to incentivize LoRaWAN Hotspot deployments -in a manner that encourages network growth and useful coverage. - -The Group consists of Community members that were self-nominated and voted in by the Community. -Future membership is open and membership can be obtained by contributing to the weekly open sessions on discord. -Members meet for 1 hour every monday at GMT 8PM to work on HIPs. - -You can find the IOT PoC Working Group Charter [here][iot-wg-charter]. - -### MOBILE PoC Working Group - -The MOBILE Proof-of-Coverage (PoC) Working Group was created to develop guidance on improvements to -the 5g-CBRS PoC algorithm. - -The success of the MOBILE network is critically tied to the Group's ability to quickly build and -roll out an effective Proof-of-Coverage framework that incentivizes useful coverage. - -The Group consists of 10 Community members that were self-nominated and voted in by the Community -for three months. Members will meet for 30 mins each week to work on the HIPs. - -You can find the MOBILE PoC Working Group Charter [here][mobile-wg-charter]. - ---- - -## Past Working Groups - -Working Groups are an effective way of creating alignment and advancement on short-term needs. See -the list below for some of the Working Groups that have helped shape the development of the network -over time: - -1. Readiness Working Group -2. LoRaWAN Working Group -3. 5G -4. Anti-Gaming -5. Bridges -6. Municipal -7. ETL -8. Mobile Apps -9. Hardware Security - ---- - -## Fishbowl Channels - -Everyone is welcome to stay up to date on Working Group progress by following along in the fishbowl -channels in Discord. You can find these channels under the Category, "Governance". - -[iot-wg-charter]: - https://docs.google.com/document/d/e/2PACX-1vSIIyDSEkIzjEJc-OJx6SvchFVaPpuOitPWhNl5KBYKTa66L2KC-_zVHKktchQfiYT8RmYQlhjPhkxE/pub -[mobile-wg-charter]: - https://docs.google.com/document/u/2/d/e/2PACX-1vRcK8J95XIwkLEM8gHy-rnaWRZ3Af2ZfV5nfeqqyHsBwC9S-EBCoKw-7jykYFvfiqfVp9D0Yg8ctc_m/pub -[hip-10]: https://github.com/helium/HIP/blob/main/0010-usage-based-data-transfer-rewards.md -[hip-15]: https://github.com/helium/HIP/blob/main/0015-beaconing-rewards.md -[hip-17]: https://github.com/helium/HIP/blob/main/0017-hex-density-based-transmit-reward-scaling.md -[hip-19]: https://github.com/helium/HIP/blob/main/0019-third-party-manufacturers.md diff --git a/docs/helium-tokens/datacredit-portal.mdx b/docs/helium-tokens/datacredit-portal.mdx deleted file mode 100644 index 6936d699a..000000000 --- a/docs/helium-tokens/datacredit-portal.mdx +++ /dev/null @@ -1,246 +0,0 @@ ---- -id: data-credit-portal -title: Helium Data Credit Portal -pagination_label: Data Credit Portal -sidebar_label: Buy Data Credits with Credit Card -description: Helium Data Credit Portal Documentation -image: https://docs.helium.com/img/link-image.png -slug: /data-credit-portal ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - -
-
- -The Data Credit Portal built by [Sphere][sphere] allows Network users to acquire Data Credits -without directly holding cryptocurrency. The tool is designed for allocating Data Credits for -Network users like [LNS operators][open-lns] or mobile [service providers][service-providers]. The -tool provides a clear invoice to simplify accounting. - -Access the Data Credit Portal at [dc-portal.helium.com][dc-portal]. - -
- -
Helium Data Credit Portal powered by Sphere.
-
-
- -:::note This portal is currently available to the United States only. - -If you are in another region and this is your only means of purchase, please email -[hello@helium.foundation][mailto-foundation] with the subject `DC Portal Invoice` for assistance. - -::: - -## Using the Data Credit Portal - -For the sake of this example, we will send 100,000 DC ($1.00 USD) to OUI 1 with the memo “helium”. - -As you type in the OUI number, you will notice a pop-up. OUI owners can see how many DC are -available under their OUI. For instance, there are just over 850 million DC available under OUI 1 -for the LoRaWAN network. - -
- -
A preview is offered for each destination address.
-
-
- -Upon clicking “Continue”, you will be taken to this view, where you will interface with Link which -is Stripe's crypto payment service. Hit “Continue” again. - -
- -
-
- -### KYC - -If you have already completed Link KYC, you can skip to [payment method][payment-method]. If you are -new to Link, you will need to sign up. - -First, fill in your email address. - -
- -
-
- -Fill in your phone number to initiate Stripe's KYC (Know-Your-Customer) process. - -
- -
-
- -Then, check your email for a six-digit code, and fill that in. You will then share the following -personal information with Stripe for compliance. - -
- -
The KYC process managed by Stripe requires this information.
-
-
- -Afterward, you will be taken to this screen. There's nothing you need to do here, press “Use this -wallet”. - -The suggested address in this view will be used to automatically create the Data Credits in your -previously selected OUI. - -
- -
-
- -### Payment Method - -Now that you've completed Stripe's KYC, add your payment method. - -
- -
-
- -### Confirm Purchase - -Next, you'll be asked to verify your identity. Hit “Verify” - -
- -
-
- -Hit “Complete on your mobile device” - -
- -
-
- -Choose one of the four ways to begin verification. If you're quick with your camera app, scanning -the QR code is fast and easy. - -
- -
-
- -Finish the verification on your mobile device. You should see “Verification submitted.” Then you can -return to your computer. - -You should be able to see this page. When you are ready, hit “Pay.” - -
- -
-
- -
- -
Letting the magic happen 🪄✨
-
-
- -You will be notified when the transaction is complete. The transaction can be verified by clicking -on the Explorer link. - -
- -
-
- -### Invoice - -With the completion of a successful transaction, an invoice is promptly emailed to the account that -was used for the transaction. - -
- -
A receipt will be emailed to the account responsible for the transaction.
-
- -## Deep Links - -The Data Credit portal provides a simple interface to pre-populate fields within the tool. Use URL -parameters to pre-fill fields on the Data Credit Portal such as OUI and memo. - -``` -https://dc-portal.helium.com/?oui=24&memo=HelloHelium -``` - -**Supported Parameters** - -| Description | Field | Example | -| ----------------- | ------ | ------------- | -| OUI | `oui` | `oui=24` | -| Transaction memo. | `memo` | `memo=aX0fe8` | - -[sphere]: https://spherepay.co -[open-lns]: /iot/open-lns -[service-providers]: /mobile/service-providers -[dc-portal]: https://dc-portal.helium.com -[payment-method]: #payment-method -[mailto-foundation]: mailto:hello@helium.foundation diff --git a/docs/helium-tokens/datacredit.mdx b/docs/helium-tokens/datacredit.mdx deleted file mode 100644 index edbc88fa0..000000000 --- a/docs/helium-tokens/datacredit.mdx +++ /dev/null @@ -1,144 +0,0 @@ ---- -id: data-credit -title: Data Credit -pagination_label: Data Credit -sidebar_label: Data Credit -description: Helium Data Credit Documentation -image: https://docs.helium.com/img/link-image.png -slug: /data-credit ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -Data Credits are the mechanism by which all usage is paid and accounted for on the Helium Network. -The same Data Credit token can be used interchangeably on any Network within Helium. However, once -Data Credits have been delegated, they cannot be redelegated. Data Credits are not transferable once -created. - -For further reading on Data Credits and their place in the overall token mechanics of the Helium -Network, please read more about [burn and mint economics][bme] in the HNT token documentation. - -## Data Credit Usage - -Data Credits are used first and foremost as the payment of data transfer on the Helium IoT and -Mobile networks. In the original design of the Network, it was recognized that users of the Network -would not be comfortable with the typical volatility that comes with typical token economics. -Therefore, Data Credits were designed such that all data transfer is pinned to USD, making it -predictable. **One Data Credit equals $0.00001 USD.** - -Unlike traditional wireless networks, the Helium Network has no annual fee, and you only pay for -data you use. - -As the Helium Network has evolved to support multiple types of data transfer, Data Credits have -grown to handle a larger role in support of these different protocols. - -### Data Credits and IoT - -On the Helium IoT Network, the primary utility of Data Credits is for network data transfer. Data -transfer is billed in 24-byte increments. Data transfer is only billed if it is delivered through -the Helium Network. - -Network users also have the choice to purchase multiple reports of the same packet. These additional -reports each account for their own cost. For instance, if three 24-byte copies are returned for a -given message, the cost would be 3 DC. - -
-

Message Payload Size

- - - - - - - - - - - - - - - -
0-24 bytes25-48 bytes... 241 bytes
1 DC2 DC... 11 DC
-
- Data transfer is accounted for in 24-byte increments per message on the LoRaWAN Network. -
-
-
- -#### Data Transfer Calculator - -Use this calculator to estimate deployment costs based on the number of devices and how often they -send data. - -This calculator assumes a 24-byte message size which is typical of most deployments. - -import OperationCostEstimator from '@site/src/theme/DcCostEstimator' - -
- -
- -#### Protocol Fees - -In addition to Network data transfer, Data Credits are also utilized for certain network-related -fees. - -| Action | Fee | -| ----------------- | --------------------------------------- | -| Device Onboarding | $40 | -| Assert Location | $10([^1]) | -| OUI | $100 | -| DevAddr | $100 ($800)([^2]) | - -[^1]: - [HIP-69][hip-69] sets the assert location fee to $5 for three months following the Solana - migration. - -[^2]: DevAddrs must be purchased in slabs of 8. -[^2]: DevAddrs must be purchased in slabs of 8. - -### Data Credits and Mobile - -In much the same design as the IoT network, the cellular network leverages Data Credits as the sole -mechanism of billing and fee management. However, as a separate protocol, different pricing -mechanics apply. While the IoT network charges data at a rate of $0.00001 per 24-byte message, the -Mobile network charges data at a rate of **$0.50 per 1 gigabyte** (50,000 DC). - -On cellular networks, it is customary that network operators bill for bulk data rather than for -individual packets. By setting the data cost to $0.50 per gigabyte, the Helium Mobile Network -positions itself competitively in the marketplace while preserving valuable rewards for the mobile -Hotspot Operator. - -#### Protocol Fees - -Fees related to onboarding and location assert have not yet been defined for the Mobile Network. - -| Action | Fee | -| --------------- | --- | -| Onboard | — | -| Assert Location | — | - -## Acquiring Data Credits - -### HNT Swap - -If you already have HNT or your organization is comfortable using cryptocurrencies for business, -swapping HNT to Data Credits using the on-chain Helium programs is the most direct means of -acquiring Data Credits. - -### Sphere Data Credit Portal - -The [Data Credit Portal][dc-portal] built by [Sphere][sphere] allows Network users to acquire Data -Credits without directly holding cryptocurrency. The tool is designed for allocating Data Credits -for Network users like [LNS operators][open-lns] or mobile [service providers][service-providers]. -The tool provides a clear invoice once transactions are complete to simplify accounting. - -[bme]: /hnt-token/#data-credits-and-burn-and-mint-economics -[sphere]: https://spherepay.co -[open-lns]: /iot/open-lns -[service-providers]: /mobile/service-providers -[hip-69]: https://github.com/helium/HIP/blob/main/0069-reassertion-fee-reduction.md -[dc-portal]: /data-credit-portal diff --git a/docs/helium-tokens/hnt.mdx b/docs/helium-tokens/hnt.mdx deleted file mode 100644 index bef44c7c1..000000000 --- a/docs/helium-tokens/hnt.mdx +++ /dev/null @@ -1,126 +0,0 @@ ---- -id: hnt-token -title: The Helium Network Token -pagination_label: Helium Network Token -sidebar_label: Helium Network Token -description: Helium Network Token Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hnt-token ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -The Helium Network Token ("HNT") is the native cryptocurrency and protocol token of the Helium -Network ("the Network"). - -The original Helium blockchain produced the first HNT on July 29th, 2019, on [block 93][block-93]. -There was no pre-mine of HNT before the launch of the Network. - -Navigate to [https://explorer.helium.com/stats][explorer-stats] for up-to-date information on -Network tokens. - ---- - -## HNT Usage - -HNT serves the needs of the two primary parties in the Helium Ecosystem: - -1. **Hotspot Hosts and Operators**. Hosts are rewarded in network tokens like [IOT][iot] or - [MOBILE][mobile] while deploying and maintaining network coverage. These network tokens are - redeemable for HNT. -2. **Enterprises and Developers use the Helium Network** to connect devices and build IoT - applications. [Data Credits][datacredit], which are a $USD-pegged utility token derived from HNT - in a burn transaction, [are used to pay transaction fees][txn-fees] for wireless data - transmissions on the Network. - ---- - -## HNT Token Economic Concepts - -The Network uses three token economic concepts to ensure HNT supply is both plentiful for usage -needs and relatively scarce, with a known maximum. - -### Max Supply - -The Network targeted the distribution of 5,000,000 HNT per month at launch. Following the community -approval of HIP-20, the Network uses a two-year halving schedule, resulting in a maximum HNT supply -of 223,000,000 HNT. - -| Year([^1]) | HNT at Year Start | Target HNT Emission | -| :------------------------------: | ----------------: | ------------------: | -| 1 | 0 | 60,000,000 | -| 2 | 60,000,000 | 60,000,000 | -| 3 | 120,000,000 | 30,000,000 | -| 4 | 150,000,000 | 30,000,000 | - -> The full token emission schedule can be viewed in the HNT section of this document: [Token -> Emissions as of Solana Migration][sol-emissions]. - -[^1]: - Year 1 starts on **August 1st, 2019**. The first halving happened on day one of year three, - **August 1st, 2021**. - -### Burn and Mint Economics - -[Data Credits][datacredit] ("DC") are a $USD-pegged utility token derived from HNT in a burn -transaction and used to pay [all transaction fees][txn-fees] on the Helium Network. DC is only -produced by burning HNT. - -One Data Credit will always cost $0.00001. Or, $1.00 will always exchange for 100,000 DC. - -This HNT to DC relationship is based on a design commonly called a [burn and mint equilibrium][bme] -("BME") and intends to allow for the supply of HNT to respond to Network usage trends such that the -amount of HNT that exists remains static month on month. The amount of DC produced by burning HNT -will increase and decrease based on the USD price of HNT as reported by the HNT [Price -Oracles][price-oracles]. - -Below are a few examples of HNT to DC conversion calculations: - -**Example 1: 1 HNT = $1.00** - -- The price of one DC is $0.00001. -- The current HNT Oracle price is $1. -- Burning 1 HNT would produce 100,000 DC. - -**Example 2: 1 HNT = $5.00** - -- The price of one DC is $0.00001. -- The current HNT Oracle price is $5. -- Burning 1 HNT would produce 500,000 DC. - -:::important Data Credits are non-transferable - -Once the burn transaction is complete, the receiving Helium Wallet owns all of the DC and **cannot** -transfer them to any other Helium Wallet. - -::: - -### Net Emissions - -Net Emissions give the protocol enough HNT for rewards in perpetuity. - -Net Emissions enable the Network to monitor the number of HNT burned for DC in a given epoch and add -that to the number of HNT to mint that epoch. - -For example, if 10 HNT burn for DC in an epoch, the system would mint 10 additional HNT than were -expected in that given epoch. - -A cap on the number of HNT minted via Net Emissions per epoch ensures the desired deflationary -effect of Burn and Mint and the resulting reduction of supply. Because HNT produced via Net -Emissions do not add to the total outstanding, they do not violate max supply. - -Review the [complete Net Emissions discussion in the HIP][hip-20] for more information. - -[block-93]: https://explorer-old.helium.com/txns/sEP-cbb2tvSrfbBleT21yGDNM8FIjNr3UT3k3BeZELw -[bme]: https://multicoin.capital/2018/02/13/new-models-utility-tokens/ -[datacredit]: /data-credit -[explorer-stats]: https://explorer.helium.com/stats -[hip-20]: https://github.com/helium/HIP/blob/master/0020-hnt-max-supply.md#net-emissions -[iot]: /iot-token -[mobile]: /mobile-token -[price-oracles]: /oracles/price-oracles -[sol-emissions]: - https://github.com/helium/HIP/blob/main/HIP-solana-parameters/token-emissions-as-of-solana-migration.pdf -[txn-fees]: /blockchain/transaction-fees diff --git a/docs/helium-tokens/iot.mdx b/docs/helium-tokens/iot.mdx deleted file mode 100644 index acdf6e14e..000000000 --- a/docs/helium-tokens/iot.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -id: iot-token -title: Helium IoT Network Token -pagination_label: IOT Network Token -sidebar_label: IOT Network Token -description: Helium IoT Network Token Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot-token ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -IOT is the protocol token of the [Helium IoT Network][iot-network]. IOT was introduced to the Helium -Network through the community proposal [HIP-52][hip-52] and is further defined in subsequent -HIPs([^1],[^2]). The first IOT tokens were minted following the -Solana migration on April 18, 2023. - -[^1]: [HIP-70: Scaling the Helium Network][hip-70] -[^2]: [HIP-77: Solana Parameters][hip-77] - -The IOT token is mined by LoRaWAN Hotspots through both data transfer proceeds as well as Proof of -Coverage. - -The mint address for IOT is [`iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns`][iot-mint-address] on the -Solana blockchain. - -## Redemption for HNT - -Protocol tokens like IOT will always be backed by HNT and will convert to HNT. To enable this, each -network within the Helium Network is allocated a pool of HNT based on the Network Utility Score. The -redemption ratio is set algorithmically by the treasury swap contacts based on this Network Utility -Score. - -The [Helium Wallet App][wallet-app] serves as the primary platform for exchanging IOT to HNT. This -transaction can also be performed directly through the Solana blockchain using the open-source -tooling found in the [Helium GitHub repositories][github]. - -## Token Allocation - -IOT follows a similar minting schedule to HNT, however at a max supply of 200,000,000,000 (200B). - -Year 1 for IOT started on August 1st, 2022. - -The issuance is scheduled to have halvings every 2 years, aligning with HNT issuance halvings. - -The emissions schedule was created in [HIP-52][hip-52-emisions] and confirmed in -[HIP-77][hip-77-emisions] and is as follows: - -| Year | IOT at Year Start | IOT Minted | Proof of Coverage ([^3]) | Data Transfer ([^3]) | Oracles ([^4]) | Operations Fund | veHNT Stakes | -| ---- | ----------------- | ---------- | ---------------------------------------------- | ------------------------------------------ | ------------------------------------ | --------------- | ------------ | -| 1 | 5B | 65B | 30% | 50% | 7% | 7% | 6% | -| 2 | 70B | 32.5B | 28.5% | 51.5% | 7% | 7% | 6% | -| 3 | 102.5B | 32.5B | 27% | 53% | 7% | 7% | 6% | -| 4 | 135B | 16.25B | 25.5% | 54.5% | 7% | 7% | 6% | -| 5 | 151.25B | 16.25B | 24% | 56% | 7% | 7% | 6% | -| 6 | 167.5B | 8.125B | 22.5% | 57.5% | 7% | 7% | 6% | -| 7 | 175.625B | 8.125B | 21% | 59% | 7% | 7% | 6% | - -> Full token emissions can be viewed in the IOT section of this document: [Token Emissions as of -> Solana Migration][migration-emissions]. - -[^3]: Any IOT not rewarded for data transfer is rolled into Proof of Coverage. -[^4]: Oracles are not rewarded until additional Oracle operators deploy services. - -[github]: https://github.com/helium -[hip-52-emisions]: https://github.com/helium/HIP/blob/main/0052-iot-dao.md#emissions-curve -[hip-52]: https://github.com/helium/HIP/blob/main/0052-iot-dao.md -[hip-70]: https://github.com/helium/HIP/blob/main/0070-scaling-helium.md -[hip-77-emisions]: - https://github.com/helium/HIP/blob/main/0077-solana-parameters.md#emission-schedules -[hip-77]: https://github.com/helium/HIP/blob/main/0077-solana-parameters.md -[iot-mint-address]: https://explorer.solana.com/address/iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns -[iot-network]: /lorawan-on-helium -[migration-emissions]: - https://github.com/helium/HIP/blob/main/HIP-solana-parameters/token-emissions-as-of-solana-migration.pdf -[wallet-app]: /wallets/helium-wallet-app diff --git a/docs/helium-tokens/mine-iot.mdx b/docs/helium-tokens/mine-iot.mdx deleted file mode 100644 index 04bd8e481..000000000 --- a/docs/helium-tokens/mine-iot.mdx +++ /dev/null @@ -1,92 +0,0 @@ ---- -id: mine-iot -title: Mine IOT -pagination_label: Mine IOT -sidebar_label: Introduction -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /mine-iot ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -
-
-
-
- -
-

- Helium Hotspots mine $IOT and are built by our growing ecosystem of approved - manufacturers. -

- -
-
-
-
-
- -
-
-
-

Hotspots

-
-
-

- Want to help build the largest IoT network in the world? Want to provide coverage to IoT - devices and earn IOT while you do? -

-

- Check out some of these quick links for help getting started or join us in the - #gateway-development channel on our Discord. -

-
-
-
Quick Links
- - Approved Makers - - - Maker Approval and - Auditing - - - Data Only Hotspots - -
-
-
-
-
-

Data Only Hotspots

-

- These Hotspots get rewarded for forwarding Data Packets. Details{' '} - - can be found here - - . -

-
-
-
-
-

Maker Apps

-

- Makers have their own App to perform Hotspot onboarding, diagnostics, and troubleshooting.{' '} - Read more here -

-
-
-
-
diff --git a/docs/helium-tokens/mobile.mdx b/docs/helium-tokens/mobile.mdx deleted file mode 100644 index edd86eb7a..000000000 --- a/docs/helium-tokens/mobile.mdx +++ /dev/null @@ -1,87 +0,0 @@ ---- -id: mobile-token -title: Helium Mobile Network Token -pagination_label: MOBILE Network Token -sidebar_label: MOBILE Network Token -description: Helium Mobile Network Token Documentation -image: https://docs.helium.com/img/link-image.png -slug: /mobile-token ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -MOBILE is the protocol token of the [Helium Mobile Network][mobile]. MOBILE was introduced to the -Helium Network through the community proposal [HIP-53][hip-53] and is further defined in subsequent -HIPs([^1],[^2],[^3]). - -[^1]: [HIP-70: Scaling the Helium Network][hip-70] -[^2]: [HIP-75: MOBILE PoC - Initiate Programmatic Minting][hip-75] -[^3]: [HIP-77: Solana Parameters][hip-77] - -The MOBILE token is mined by 5G Hotspots through both data transfer proceeds as well as Proof of -Coverage. - -The mint address for MOBILE is [`mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6`][mobile-mint-addr] on -the Solana blockchain. - -## Redemption for HNT - -Protocol tokens like MOBILE will always be backed by HNT and will convert to HNT. To enable this, -each network within the Helium Network is allocated a pool of HNT based on the Network Utility -Score. The redemption ratio is set algorithmically by the treasury swap contacts based on this -Network Utility Score. - -The [Helium Wallet App][wallet-app] serves as the primary platform for exchanging MOBILE to HNT. -This transaction can also be performed directly through the Solana blockchain using the open-source -tooling found in the [Helium GitHub repositories][github]. - -## Token Allocation - -MOBILE follows a similar minting schedule to HNT, however at a max supply of 230,000,000,000 (230B). -50B MOBILE were pre-mined at the launch of the Mobile Network and distributed to the Network -operations fund administered by the Helium Foundation. A fraction of this allocation was distributed -throughout the Genesis period to live Mobile Network Hotspots. Year 1 for MOBILE started on August -1st, 2022. - -The issuance is scheduled to have halvings every 2 years, aligning with HNT issuance halvings. - -The emission schedule was created in [HIP-53][hip-53-emissions], updated in -[HIP-75][hip-75-emissions]and confirmed in [HIP-77][hip-77-emissions] and is as follows: - -| Year | MOBILE at Year Start | MOBILE Minted | Proof of Coverage ([^4]) | Hotspot Data ([^4]) | Mappers | Service Providers | Oracles ([^5]) | veHNT Stakers | -| ---- | -------------------- | --------------------------------- | ---------------------------------------------- | ----------------------------------------- | ------- | ----------------- | ------------------------------------ | ------------- | -| 1 | 50B | 110B ([^6]) | 20% | 40% | 10% | 20% | 4% | 6% | -| 2 | 110B | 30B | 20% | 40% | 10% | 20% | 4% | 6% | -| 3 | 140B | 30B | 20% | 40% | 10% | 20% | 4% | 6% | -| 4 | 170B | 15B | 20% | 40% | 10% | 20% | 4% | 6% | -| 5 | 185B | 15B | 20% | 40% | 10% | 20% | 4% | 6% | -| 6 | 200B | 7.5B | 20% | 40% | 10% | 20% | 4% | 6% | -| 7 | 207.5B | 7.5B | 20% | 40% | 10% | 20% | 4% | 6% | - -> Full token emissions can be viewed in the MOBILE section of this document: [Token Emissions as of -> Solana Migration][sol-emisions] - -[^4]: Any MOBILE not rewarded for data transfer is rolled into Proof of Coverage. -[^5]: Oracles are not rewarded until additional Oracle operators deploy services. -[^6]: - 50B pre-mine, 60B max emitted in year one. Only 30B was emitted as no emissions occurred between - August 2022 and Jan 31st, 2023 - -[github]: https://github.com/helium -[hip-53-emissions]: https://github.com/helium/HIP/blob/main/0053-mobile-dao.md#emissions-curve -[hip-53]: https://github.com/helium/HIP/blob/main/0053-mobile-dao.md -[hip-70]: https://github.com/helium/HIP/blob/main/0070-scaling-helium.md -[hip-75-emissions]: - https://github.com/helium/HIP/blob/main/0075-mobile-poc-initiate-programmatic-minting-and-updated-emissions-curve.md#economic-changes-to-emissions-curve -[hip-75]: - https://github.com/helium/HIP/blob/main/0075-mobile-poc-initiate-programmatic-minting-and-updated-emissions-curve.md -[hip-77-emissions]: - https://github.com/helium/HIP/blob/main/0077-solana-parameters.md#emission-schedules -[hip-77]: https://github.com/helium/HIP/blob/main/0077-solana-parameters.md -[mobile-mint-addr]: https://explorer.solana.com/address/mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6 -[mobile]: /5g-on-helium -[sol-emisions]: - https://github.com/helium/HIP/blob/main/HIP-solana-parameters/token-emissions-as-of-solana-migration.pdf -[wallet-app]: /wallets/helium-wallet-app diff --git a/docs/helium-tokens/sol.mdx b/docs/helium-tokens/sol.mdx deleted file mode 100644 index 031b4779a..000000000 --- a/docs/helium-tokens/sol.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -id: sol-token -title: The Solana Token -pagination_label: SOL Token -sidebar_label: SOL Token -description: Solana Token Documentation -image: https://docs.helium.com/img/link-image.png -slug: /sol-token ---- - -The Helium Network runs on the Solana blockchain, an extremely fast, scalable, and low-cost -blockchain. - -Interacting with the Solana blockchain requires a small fee (average transaction fee is 0.000014 -SOL) paid in SOL tokens, which is massively cheaper than the original Helium blockchain transaction -fee of $0.35 in DC. - -All interactions with the Solana blockchain require fees, including sending tokens, staking tokens, -making payments, swapping tokens, minting NFTs, claiming rewards from your Hotspots, and all -on-chain Helium transactions. - -## Solana Accounts and Rent - -Information is stored on the Solana blockchain, such as token balances, NFTs, or other data, in -"accounts." Keeping this data on-chain takes up space, so Solana charges a "rent" fee of ~0.002 SOL -on accounts. - -Rent Facts: - -- Each account has an individual rent fee. -- There is typically one account for each token type. -- Having more accounts (meaning more token types) requires more rent fees. -- Closing accounts can return rent to your wallet. - -Performing more complex transactions, which include creating accounts, may require more SOL. For -example, if a Wallet does not have enough SOL for rent fees, the Wallet **cannot** create new -accounts to hold tokens, and transactions will fail. - -This includes reasserting your Hotspot's location, locking HNT to gain veHNT, and potentially more -complex DeFi actions where multiple accounts must be created (even temporarily). - -Locking up HNT to gain [veHNT][vehnt] creates new accounts and requires ~0.014 SOL. It is best -practice to hold more than the minimum amount of SOL in a Wallet to fund additional accounts in the -future. - -:::note Foundation Funding - -As part of the migration to Solana, the Helium Foundation provided every Helium Wallet with 0.00139 -SOL (enough for 100 standard transactions). - -::: - ---- - -## Swap Utility - -If you do not have enough SOL, you can use this tool to swap HNT for 0.02 SOL. Open this page from -within the browser of the [Helium Wallet App][wallet-app] to swap a small amount of HNT for SOL. - -import { HntToFeeSol } from '@theme/HntToFeeSol' - -
- -
-
- -
- -
- Video of the process in action.{' '} - Click here to watch on YouTube. -
-
- -[wallet-app]: /wallets/helium-wallet-app -[vehnt]: /vehnt diff --git a/docs/home/about-helium.mdx b/docs/home/about-helium.mdx deleted file mode 100644 index ac7fd5673..000000000 --- a/docs/home/about-helium.mdx +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: about-helium -hide_title: true -title: Home -pagination_label: What is Helium? -sidebar_label: What is Helium? -description: What is Helium? -image: https://docs.helium.com/img/link-image.png -slug: /home/about-helium -hide_table_of_contents: true ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Overview of the Helium Network - -## Introduction - -The Helium Network is a decentralized, blockchain-based wireless infrastructure project that allows -individuals and organizations to deploy and operate wireless networks through token incentivization. -It leverages the Solana Blockchain for its foundation. The primary token powering the network is -HNT, while IOT and MOBILE tokens are used to facilitate the LoRaWAN and 5G networks, respectively. -Proof-of-Coverage (PoC) is a unique consensus algorithm employed by the subnetworks. - -## Helium Network Components - -**Solana Blockchain:** The underlying blockchain infrastructure that provides security, scalability, -and decentralization for the Helium Network. - -**HNT Token:** The native token of the Helium Network, which is used to incentivize network -participants and facilitate transactions. - -**IOT Token:** A token specific to the LoRaWAN network, enabling low-power, wide-area network -connectivity for Internet of Things (IoT) devices. PoC is employed for the LoRaWAN subnetwork. - -**MOBILE Token:** A token specific to the 5G network, facilitating high-speed mobile connectivity -and data transmission. PoC is employed for the 5G subnetwork. - -## Network Participants - -**Hotspot Owners:** Individuals or organizations that deploy and maintain Helium-compatible wireless -devices (Hotspots) to provide network coverage. - -**IoT Device Owners:** Users of IoT devices that leverage the Helium Network for connectivity. - -**Mobile Device Users:** Users of mobile devices that access the 5G network through the Helium -Network infrastructure. - -**Developers:** Individuals or organizations that build applications and services using the Helium -Network infrastructure. - -## Key Features - -**Decentralized Infrastructure:** The Helium Network allows for the creation and maintenance of a -distributed wireless network by incentivizing participants to contribute resources and share the -benefits. - -**Scalable and Secure:** The Helium Network leverages the Solana Blockchain, which is known for its -high scalability, low latency, and robust security. - -**Multi-Use Case Support:** The Helium Network supports various use cases, including IoT devices -through the LoRaWAN network and high-speed mobile connectivity via the 5G network. - -**Incentivized Participation:** The Helium Network employs a token-based system to reward -participants and encourage network growth. - -**Proof-of-Coverage (PoC):** A unique consensus algorithm employed by the LoRaWAN and 5G -subnetworks, which rewards participants for verifying wireless network coverage. diff --git a/docs/home/helium-history.mdx b/docs/home/helium-history.mdx deleted file mode 100644 index d1604f27b..000000000 --- a/docs/home/helium-history.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: helium-history -hide_title: true -title: Home -pagination_label: History of Helium -sidebar_label: History of Helium -description: History of Helium -image: https://docs.helium.com/img/link-image.png -slug: /home/helium-history -hide_table_of_contents: true ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# History of the Helium Network - -## Founding and Early Vision - -The Helium Network was founded in 2013 by Amir Haleem, Shawn Fanning, and Sean Carey. The founders -envisioned creating a decentralized wireless infrastructure that could support the rapidly growing -IoT industry. They aimed to lower the barriers to entry for IoT connectivity by creating a -people-powered network, driven by economic incentives. - -## Launch of the Helium Hotspot - -In 2019, Helium launched its flagship product, the Helium Hotspot. This device allowed users to -provide wireless coverage for IoT devices over a new protocol called LongFi, which combined the -long-range capabilities of LoRaWAN with the Helium blockchain. Early adopters started deploying -Hotspots to earn HNT tokens as a reward for providing network coverage. - -## Expansion and Adoption - -As more Hotspots were deployed across the globe, the Helium Network continued to grow, attracting -interest from developers, companies, and individual users. The Helium Network expanded its coverage -to various countries, enabling new use cases and further solidifying its position as a decentralized -wireless infrastructure provider. - -## Transition to Solana Blockchain - -To improve scalability, security, and decentralization, the Helium Network migrated to the Solana -blockchain. This transition allowed Helium to leverage the high-performance capabilities of Solana, -which was crucial for supporting the increasing number of network participants and transactions. - -## Introduction of Subnetworks and New Tokens - -As the Helium Network matured, it diversified its offerings by introducing subnetworks for different -wireless technologies, such as LoRaWAN and 5G. These subnetworks employed their own tokens, IOT and -MOBILE, and used the unique Proof-of-Coverage consensus algorithm to reward participants for network -coverage. - -## Present and Future - -Today, the Helium Network is a rapidly growing decentralized wireless infrastructure with a global -footprint. It continues to attract new users, developers, and organizations, paving the way for -innovative applications and services. As the Network expands, it aims to revolutionize the wireless -communication landscape and further democratize access to connectivity. diff --git a/docs/home/home.mdx b/docs/home/home.mdx index 8ff227858..6b000b7c5 100644 --- a/docs/home/home.mdx +++ b/docs/home/home.mdx @@ -3,225 +3,21 @@ id: home hide_title: true title: Home pagination_label: Home -# sidebar_label: Home +sidebar_label: Introduction description: Helium Documentation image: https://docs.helium.com/img/link-image.png slug: / hide_table_of_contents: true +pagination_next: null +pagination_prev: null --- import useBaseUrl from '@docusaurus/useBaseUrl' -
-
-
- -
-
-

- Get Started
- with Helium -

-

- Build amazing connected solutions on the world's largest decentralized wireless network. -

-
-
- - Learn about Mining IOT{' '} - - - - Use the Network{' '} - - - - Submit a Helium Improvement Proposal{' '} - - -
-
-
-
-
+ -
-
-
-

Introduction

-
-
-

- Helium is a global, distributed network of Hotspots that create public, long-range wireless - coverage for LoRaWAN-enabled IoT devices and cellular devices. LoRaWAN™ Hotspots - produce and are compensated in IOT, the native cryptocurrency of the Helium blockchain. The - Helium blockchain is a new, open-source, public blockchain created entirely to incentivize - the creation of physical, decentralized wireless networks. Today, the Helium IoT Network, - and its hundreds of thousands of Hotspots, - provide access to the largest LoRaWAN Network in the world. -

-

- If, at any time, you don't find what you need, join us in{' '} - our Discord. -

-
-
-
- -
-
-
- -
-
-
- -

Helium Network

-

- Helium is a token-incentivization model that connects devices and applications using - distributed nodes, including LoRaWAN™ and cellular networks. -

- - Learn More - -
Quick Links
- - Helium Token - - - Mining HNT - - - Proof of Coverage - - - Transaction Fees - -
-
- -

Mine $IOT

-

- Hotspots create The People’s Network, a long-range wireless coverage for very low power and - inexpensive IoT devices and are rewarded $IOT for doing so. -

- - Learn More{' '} - - -
Quick Links
- - What is a Helium - Miner? - - - Approved Hotspots - - - Become a Maker - - - Build a Packet - Forwarder - -
-
- -

Use the Helium Network

-

- The Helium Ecosystem includes thousands of ready-to-use devices, powerful integrations, and - robust developer tools. -

- - Learn More{' '} - - -
Quick Links
- - Devices - - - OpenLNS - - - LoRaWAN on Helium - -
-
- -

Community, Governance, & Open Source

-

- Helium’s decentralized ‘People’s Network’ relies on a community of supporters, developers - and advisors. -

- - Learn More - -
Quick Links
- - Discord Community - Chat - - - Helium Improvement - Proposals - - - Open Source - Software - -
-
-
- -
-
-
- -
-
-
-

Tools, Technologies & Initatives

-
-
-
- -
- -

Explorer

- -

Helium Network Explorer

-
-
-
- -
- -

Mappers

- -

Community-driven Coverage Mapping

-
-
-
-
-
- -
- -

Helium Hotspot Software

- -

Packet forwarder for Helium-enabled Gateways.

-
-
-
- -
- -

Wallet App

- -

iOS & Android Helium Wallet

-
-
-
-
-
+The Helium Network powers two distinct wireless networks; a global LoRaWAN™ network for IoT +devices, and a cellular offload Wi-Fi network for mobile connectivity. Wireless gateways called +"Hotspots", operated by the Helium community, provide the coverage for these networks. Hotspot +owners are incentivized with the Helium HNT token for providing coverage and handling wireless +traffic. diff --git a/docs/home/style-guide.mdx b/docs/home/style-guide.mdx new file mode 100644 index 000000000..c7b8b7e5a --- /dev/null +++ b/docs/home/style-guide.mdx @@ -0,0 +1,208 @@ +--- +id: style-guide +title: Style Guide +sidebar_label: Style Guide +--- + +You can write content using [GitHub-flavored Markdown syntax](https://github.github.com/gfm/). + +## Markdown Syntax + +To serve as an example page when styling markdown based Docusaurus sites. + +## Headers + +# H1 - Create the best documentation + +## H2 - Create the best documentation + +### H3 - Create the best documentation + +#### H4 - Create the best documentation + +##### H5 - Create the best documentation + +###### H6 - Create the best documentation + +--- + +## Emphasis + +Emphasis, aka italics, with _asterisks_ or _underscores_. + +Strong emphasis, aka bold, with **asterisks** or **underscores**. + +Combined emphasis with **asterisks and _underscores_**. + +Strikethrough uses two tildes. ~~Scratch this.~~ + +--- + +## Lists + +1. First ordered list item +1. Another item + - Unordered sub-list. +1. Actual numbers don't matter, just that it's a number + 1. Ordered sub-list +1. And another item. + +- Unordered list can use asterisks + +* Or minuses + +- Or pluses + +--- + +## Links + +[I'm an inline-style link](https://www.google.com/) + +[I'm an inline-style link with title](https://www.google.com/ "Google's Homepage") + +[I'm a reference-style link][arbitrary case-insensitive reference text] + +[You can use numbers for reference-style link definitions][1] + +Or leave it empty and use the [link text itself]. + +Some text to show that the reference links can follow later. + +[arbitrary case-insensitive reference text]: https://www.mozilla.org/ +[1]: http://slashdot.org/ +[link text itself]: http://www.reddit.com/ + +--- + +## Images + +Here's our logo (hover to see the title text): + +Inline-style: +![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png 'Logo Title Text 1') + +Reference-style: ![alt text][logo] + +[logo]: + https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png + 'Logo Title Text 2' + +Images from any folder can be used by providing path to file. Path should be relative to markdown +file. + +![img](../../static/img/icons/logo.svg) + +--- + +## Code + +```javascript +var s = 'JavaScript syntax highlighting' +alert(s) +``` + +```python +s = "Python syntax highlighting" +print(s) +``` + +``` +No language indicated, so no syntax highlighting. +But let's throw in a tag. +``` + +```js {2} +function highlightMe() { + console.log('This line can be highlighted!') +} +``` + +--- + +## Tables + +Colons can be used to align columns. + +| Tables | Are | Cool | +| ------------- | :-----------: | -----: | +| col 3 is | right-aligned | \$1600 | +| col 2 is | centered | \$12 | +| zebra stripes | are neat | \$1 | + +There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and +you don't need to make the raw Markdown line up prettily. You can also use inline Markdown. + +| Markdown | Less | Pretty | +| -------- | --------- | ---------- | +| _Still_ | `renders` | **nicely** | +| 1 | 2 | 3 | + +--- + +## Blockquotes + +> Blockquotes are very handy in email to emulate reply text. This line is part of the same quote. + +Quote break. + +> This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep +> writing to make sure this is long enough to actually wrap for everyone. Oh, you can _put_ > +> **Markdown** into a blockquote. + +--- + +## Inline HTML + +
+
Definition list
+
Is something people use sometimes.
+ +
Markdown in HTML
+
Does *not* work **very** well. Use HTML tags.
+
+ +--- + +## Line Breaks + +Here's a line for us to start with. + +This line is separated from the one above by two newlines, so it will be a _separate paragraph_. + +This line is also a separate paragraph, but... This line is only separated by a single newline, so +it's a separate line in the _same paragraph_. + +--- + +## Admonitions + +:::note + +This is a note + +::: + +:::tip + +This is a tip + +::: + +:::important + +This is important + +::: + +:::caution + +This is a caution + +::: + +:::warning + +This is a warning + +::: diff --git a/docs/hotspot-makers/become-a-maker/basic-miner-operation.mdx b/docs/hotspot-makers/become-a-maker/basic-miner-operation.mdx deleted file mode 100644 index aa95dc7a7..000000000 --- a/docs/hotspot-makers/become-a-maker/basic-miner-operation.mdx +++ /dev/null @@ -1,410 +0,0 @@ ---- -id: basic-miner-operation -title: Basic Miner Operation -pagination_label: Basic Miner Operation -sidebar_label: Basic Miner Operation -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/basic-miner-operation ---- - -## Basic Miner Operation - -import useBaseUrl from '@docusaurus/useBaseUrl' - -As you can see below, the Miner is central in routing data across the Helium Network. It is one of -three pieces: - - - -- Packet Forwarder: this is a utility that interacts with the radio front-end and sends and receives - raw radio packets with the Helium Miner -- Miner: the Helium Blockchain comes into the picture here; the Miner is responsible for routing - packets to the appropriate Router and entering into micro-transactions brokered via libp2p -- Router: a Helium compatible LoRaWAN Network Server, basically; this component is interested in - receiving the packets relating to its devices and handles downlink messages when appropriate - -In addition to packet routing, the Miner also participates in PoC and submits PoC packets as witness -events. When challenge, the Miner sends packets to the packet forwarder for transmission. - -The Miner connects to other Miners over libp2p where, amongst other things, it is gossiping and -saving blocks, while maintaining a ledger of the blockchain. Constantly syncing the blockchain and -downloading blocks uses significant bandwidth and CPU. - -In this guide, we will explain how to get a Docker image of the Helium Miner running on Ubuntu 20.04 -LTS, and finally some tips on how to interact with a running Miner. - -When preparing the Miner for a Hotspot product, you will want to go a little further and follow the -steps outlined [here](/hotspot-makers/become-a-maker/docker-integration), where you will learn how -to integrate it with security modules and BLE. - -If you are interested in contributing to Miner development and code-review, please visit -[the Miner's repository on Github](https://github.com/helium/miner). - -### Setting Up Ubuntu for Docker - -Ubuntu is a widely available Linux distribution. Notably, it has an easy-to-use image available for -Raspberry Pi 3 and 4, so we use it as an example system. That being said, any ARM64 or AMD64 -\(X86-64\) based OS that can run Docker is suitable. - -For Raspberry Pi, we recommend running the latest -[64-bit RaspiOS](https://downloads.raspberrypi.org/raspios_arm64/images/) image. We currently do not -have Docker image support for 32-bit systems, so please double-check that you're using a 64-bit -image. Once you have followed the instructions and are logged into the system, you are ready for the -rest of this guide. - -For most cloud service providers, launching an instance with Ubuntu 20.04 LTS should be fairly -straightforward. With AWS for example, create an EC2 instance running Ubuntu 20.04. A t2.small will -run the miner well once the initial blockchain sync has completed. Once that's launched and you're -connected, you are ready for the rest of this guide. - -First, update the package manager registry: - -```text -sudo apt-get update -``` - -Then, install Docker: - -```text -sudo apt-get install docker.io -``` - -To avoid needing to user docker with `sudo` privileges, add your user to the `docker` group, -replacing $USER with your username: - -```text -sudo usermod -aG docker $USER -``` - -Log in and out of your account to apply these changes. You are now ready to use Docker! - -### Port Forwarding - -Before launching the Miner, you will want to configure ports on your network to forward two ports: - -- **44158/TCP**: the Miner communicates to other Miners over this port. The networking logic knows - how to get around a lack of forwarding here, but you will get better performance by forwarding the - port -- **1680/UDP**: the radio connects to the Miner over this port. You will not be able to forward - packets or participate in Proof of Coverage without this - -"Forwarding" on the second port is less relevant if you are running a radio packet forwarder on the -same system at the miner \(both on a Raspberry Pi, for example\). But it is essential if you are -running a Miner on the cloud for example. - -For AWS, for example, you will want to configure the "Security Group" of your EC2 as so: - - - -### Run a Docker Container - -Miner releases are available as amd64 and arm64 images on at -[quay.io](https://quay.io/repository/team-helium/miner?tab=tags). We do not currently provide 32-bit -support. - -**Note**: on amd64 systems, AVX support is required. Verify that it exists on your host system: - -```text -grep avx /proc/cpuinfo -``` - -```text -grep avx2 /proc/cpuinfo -``` - -If nothing is returned from these commands, your host system does not have AVX support and your -Miner may not be stable. - -#### Start Container - -Before running the container for the first time, it is advisable to pick a 'system mount point\`, -i.e. a directory in your host system; some long-term miner data is stored there. This allows you to -easily maintain your miner's blockchain identity \(i.e. swarm keys\) and blockchain state through -miner image updates. - -If you are using a Linux system, you can just create a directory in your user's home directory: - -```text -mkdir ~/miner_data -``` - -If you are using Ubuntu as user ubuntu, this path would now be `/home/ubuntu/miner_data`. This will -be used later. - -Now you can try the `run` command to start your container for the first time: - -```text -docker run -d --init \ ---ulimit nofile=64000:64000 \ ---env REGION_OVERRIDE=US915 \ ---restart always \ ---publish 1680:1680/udp \ ---publish 44158:44158/tcp \ ---name miner \ ---mount type=bind,source=/home/ubuntu/miner_data,target=/var/data \ -quay.io/team-helium/miner:miner-xxxNN_YYYY.MM.DD -``` - -Replace xxxNN with the architecture used, i.e. amd64 or arm64, and with the release date of the -image. - -The `-d` option runs in detached mode, which makes the command return or not; you may want to omit -if you have a daemon manager running the docker for you. - -The `-env REGION_OVERRIDE=US915` tells your miner that you are connecting to a packet forwarder -configured for the US915 region. You will want to change this to your region i.e. -`US915 | EU868 | EU433 | CN470 | CN779 | AU915 | AS923 | KR920 | IN865` - -> Note: REGION_OVERRIDE may be completely omitted once your Miner has asserted location and is fully -> synced, but leaving it there \(as long as the region is properly configured\) is not harmful - -The `--restart always` option asks Docker to keep the image running, starting the image on boot and -restarting the image if it crashes. Depending on how you installed Docker in your system, it'll -start on boot. In the AWS AMI above, we use systemd \(`systemctl status docker` to check\). - -The `--publish 1680:1680/udp` binds your system port 1680 to the container's port 1680, where the -Miner is hosting a packet forwarder UDP server; this is necessary if you want to do any radio -interactions with your miner. - -The `--name miner` names the container, which makes interacting with the docker easier, but feel -free to name the container whatever you want. - -The `--mount` with the parameters above will mount the container's `/var/data/` directory to the -systems directory `/home/ec2-user/miner_data`. - -### Configure AWS Instance for Sync - -Amazon EC2 instances have CPU usage credits that will easily be depleted during the initial sync of -the blockchain. To avoid having your instance throttled, you can temporarily uncap your instance by -setting CPU credit usage to unlimited. Once your miner has reached full block height, a t2.small -instance is sufficient to keep your miner running. - -### Interact with the Miner within the Container - -You may want to interrogate the Miner or interact with it it as described in the -[using a miner section](/use-the-network/setup-a-packet-forwarder). Docker's `exec` command enables -this e.g. - -```text -docker exec miner miner info height -``` - -In other words, prepend `docker exec miner` to any of the commands documented in the -[using a miner section](/use-the-network/setup-a-packet-forwarder)). Or create an alias such as: -`alias miner="docker exec miner miner"` - -### Updating the Docker Image - -[the releases here](https://github.com/helium/miner/releases). Depending on whether you are running -a miner for fun, to route packets, or to participate in PoC, keeping it updated may be more or less -urgent. Each release tagged on the Github will be on the quay repository. Simply remove the current -image: - -```text -docker stop miner && docker rm miner -``` - -And start the container again as described above, but with the new release tag! Thanks to the -`--mount` option, the blockchain data and the miner keys are preserved through updates. - -### Using the Miner - -These commands will assume you are running in Docker and they have the same prefix to get you -executing a command within the docker: `docker exec miner` . If you want to make it easier, you can -always create an an alias such as: `alias miner="docker exec miner miner"`. - -#### Checking the Logs - -This is always helpful to get some idea of what's going on: - -```text -docker exec miner tail -F /var/data/log/console.log -``` - -Also, if you are particularly interested in radio traffic, it can be helpful to filter for `lora` as -so: - -```text -docker exec miner tail -f /var/data/log/console.log | grep lora -``` - -### Checking the P2P Network - -This is the first health check you can do to see how your Miner is doing. Is it finding other Helium -miners over libp2p properly? - -The Helium blockchain uses an Erlang implementation of [libp2p](https://libp2p.io/). Because we -expect Hotspot hardware to be installed in a wide variety of networking environments -[erlang-libp2p](https://github.com/helium/erlang-libp2p) includes a number of additions to the core -specification that provides support for NAT detection, proxying and relaying. - -The first order of business once the Miner is running is to see if you're connected to any peers, -whether your NAT type has been correctly identified, and that you have some listen addresses: - -```text -docker exec miner miner peer book -s -``` - -You will see an output roughly like the following: - -```bash -+--------------------------------------------------------+------------------------------+------------+-----------+---------+------------+ -| address | name |listen_addrs|connections| nat |last_updated| -+--------------------------------------------------------+------------------------------+------------+-----------+---------+------------+ -|/p2p/11dwT67atkEe1Ru6xhDqPhSXKXmNhWf3ZHxX5S4SXhcdmhw3Y1t|{ok,"genuine-steel-crocodile"}| 2 | 4 |symmetric| 3.148s | -+--------------------------------------------------------+------------------------------+------------+-----------+---------+------------+ - -+----------------------------------------------------------------------------------------------------------------------------+ -| listen_addrs (prioritized) | -+----------------------------------------------------------------------------------------------------------------------------+ -|/p2p/11apmNb8phR7WXMx8Pm65ycjVY16rjWw3PvhSeMFkviWAUu9KRD/p2p-circuit/p2p/11dwT67atkEe1Ru6xhDqPhSXKXmNhWf3ZHxX5S4SXhcdmhw3Y1t| -| /ip4/192.168.3.6/tcp/36397 | -+----------------------------------------------------------------------------------------------------------------------------+ - -+--------------------------+-----------------------------+---------------------------------------------------------+------------------------------+ -| local | remote | p2p | name | -+--------------------------+-----------------------------+---------------------------------------------------------+------------------------------+ -|/ip4/192.168.3.6/tcp/36397|/ip4/104.248.122.141/tcp/2154|/p2p/112GZJvJ4yUc7wubREyBHZ4BVYkWxQdY849LC2GGmwAnv73i5Ufy|{ok,"atomic-parchment-snail"} | -|/ip4/192.168.3.6/tcp/36397| /ip4/73.15.36.201/tcp/13984 |/p2p/112MtP4Um2UXo8FtDHeme1U5A91M6Jj3TZ3i2XTJ9vNUMawqoPVW| {ok,"fancy-glossy-rat"} | -|/ip4/192.168.3.6/tcp/36397| /ip4/24.5.52.135/tcp/41103 |/p2p/11AUHAqBatgrs2v6j3j75UQ73NyEYZoH41CdJ56P1SzeqqYjZ4o | {ok,"skinny-fuchsia-mink"} | -|/ip4/192.168.3.6/tcp/46059| /ip4/34.222.64.221/tcp/2154 |/p2p/11LBadhdCmwHFnTzCTucn6aSPieDajw4ri3kpgAoikgnEA62Dc6 | {ok,"skinny-lilac-mustang"} | -+--------------------------+-----------------------------+---------------------------------------------------------+------------------------------+ -``` - -As long as you have an address listed in `listen_addrs` and some peers in the table at the bottom, -you're connected to the p2p network and good to go. - -If you are having trouble, try forwarding port `44158` to the miner. On AWS, double check your -security group settings. - -### Checking Block Height - -As long as a genesis block is loaded, this query will work and return height 1 at least: - -```text -docker exec miner miner info height -``` - -If you are syncing, you should see something like this: - -```text -~$ miner info height -6889 280756 -``` - -The first number is the election epoch and the second number is the block height of your miner. If -you just launched an AMI instance, your Miner is been disconnected, or you simply have a slow -connection, you may be a few blocks behind. To check, you can either check the mobile app, check -[the browser-based block explorer](https://network.helium.com/blocks), or run a simple curl command -to check in a Terminal: - -```text -~$ curl https://api.helium.io/v1/blocks/height -{"data":{"height":280756}} -``` - -### Backing Up Your Swarm Keys - -Periodically, we may release updates or you may want to migrate your miner from one machine to -another. The most important thing is that you maintain a copy of your miner's private key, i.e. -`swarm_key`. Fun tidbit: this is also how your three-word name is generated. - -Assuming you've mounted the Docker image as detailed above, it is located at: - -```text -~/miner_data/miner/swarm_key -``` - -Another fun tidbit: for production hotspots sold by Helium, the swarm key is stored inside of a -secure element and is thus unable to be migrated \(or compromised/accidentally lost unless -physically damaged\). - -### Snapshots - -Snapshots are summaries of the current state of the blockchain. Since you don't need every single -block ever to sync with the blockchain, it's really just a summary of the last few blocks and the -account balance of every account on the blockchain. - -You generally want to be careful who you accept snapshots from as they might give you an incorrect -state. However, we also store hashes of valid snapshots in the blockchain. - -#### Chain-based - -You can query a running Miner to see what snapshots it (1) knows about and (2) has a copy of: - -```text -$ miner snapshot list -Height 731521 -Hash <<129,14,18,225,133,83,34,24,205,69,10,10,84,42,129,207,42,186,18,28,192, - 157,187,76,109,233,4,108,198,197,111,176>> -Have true - -Height 730801 -Hash <<80,90,115,7,10,195,115,217,87,173,24,11,63,116,201,22,150,6,252,168,204, - 60,65,83,106,68,94,19,7,13,72,165>> -Have true -``` - -A Miner knows about a snapshot in two ways: it either syncs a block where the snapshot hash and -height have been saved, or the configuration file of the Miner (`sys.config`) has the **blessed** -height and hash written into it (ie: `blessed_snapshot_block_height` and -`blessed_snapshot_block_hash`). - -If you have a fully synced Miner, you can extract these values from `snapshot list` and write them -into the `sys.config` of another non-fully synced Miner. Restart the Miner to reload the -`sys.config` and it will be able to "quick sync" to that snapshot. To make things go even faster, -try manually connecting your Miner to one of your Miners that has the snapshot. - -```text -miner peer connect /ip4/192.168.0.0.1/tcp/44158 -``` - -The only down-side of this approach is that snapshots happen at some rhythm defined by the -blockchain (currently 720 blocks). You can use the manual approach to pass around arbitrary -snapshots by hand. - -#### Manual - -You can also manually move a snapshot file around. To take a snapshot: - -```text -miner snapshot take /path/to/snapshot -``` - -Naming the snapshot something like `snap-XXXXXX`, where `XXXXXX` is the height of the blockchain is -a typical convention. Also, when using a Docker container, it's usually a good idea to save the -snapshot to `/var/data` so that you can easily copy the snapshot out of the Docker and into the host -system. - -Loading the snapshot is as follows: - -```text -miner snapshot load /path/to/snapshot -``` - -Sometimes the load command times out. If so, try to tail the logs and see if blocks are being -applied. It's working just fine! It just needs a moment to finish loading the snapshot. - -## Connecting a Packet Forwarder to the Miner - -You're almost done. The last step after you have your Miner running is to connect to it. - -With your favorite editor, open `global_conf.json` that lives in the packet forwarder directory: - -```text -nano ~/sx1302_hal/lora_pkt_fwd/global_conf.json -``` - -You want to change the field "server_address" from "localhost" to the IP address of the server, so -in this case: - -You'll need to restart the packet forwarder for the configuration change to take effect. - -To verify that things are working, you can follow the logs on your miner. eg: - -```text -docker exec miner tail -f /var/data/log/console.log | grep lora -``` - -At the very least, you should see PULL_DATA messages every few seconds. If so, then you've done it! diff --git a/docs/hotspot-makers/become-a-maker/burn-hnt-to-maker-wallet.mdx b/docs/hotspot-makers/become-a-maker/burn-hnt-to-maker-wallet.mdx deleted file mode 100644 index 62f0e372b..000000000 --- a/docs/hotspot-makers/become-a-maker/burn-hnt-to-maker-wallet.mdx +++ /dev/null @@ -1,93 +0,0 @@ ---- -id: burn-hnt-to-maker-wallet -title: Burn HNT To Maker Wallet -pagination_label: Burn HNT To Maker Wallet -sidebar_label: Burning HNT To Maker Wallet -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/burn-hnt-to-maker-wallet ---- - -# Burning HNT to Your Maker Wallet - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Any [approved Hotspot Maker](/hotspot-makers/iot/full-hotspots) is responsible for supplying Data -Credits (DCs) to the onboarding server for Hotspots they sell. They do this by burning HNT to their -specific maker address. - -:::info - -A full list of approved maker wallet addresses -[can be seen via this API](https://onboarding.dewi.org/api/v2/makers). - -::: - -## Maker Wallet Address Integration - -As an approved Maker, you will supply the Helium Foundation with the onboarding details for all the -Hotspots you manufacture and distribute. In turn, the Helium Foundation adds them to the onboarding -server. When a Hotspot is onboarded by your end customer, the onboarding server knows to associate -it with your Maker ID, and associated Maker Wallet address. If, when a Hotspot is onboarded, it's -present in the onboarding server and you have ample Data Credits to pay the onboarding fees, the -blockchain will add the Hotspot. And if you've integrated your Hotspot in the Hotspot App -[onboarding flow](/hotspot-makers/become-a-maker/hotspot-integration-testing), the Wallet knows to -use your approved Maker Wallet address. At this point, the Data Credits will be used for the -transactions with your wallet address as the payer. - -## Hotspot Data Credit Fees - -In order for any Hotspot to join the Helium Blockchain, its maker address must have sufficient Data -Credits. A full list of -[Helium blockchain data credit fees can be found here](/blockchain/transaction-fees). Hotspot Makers -need to account for at least `5,135,000` total Data Credits per Hotspot. Specifically, for each -Hotspot, a Maker must supply: - -- `4,000,000` Data Credits for the **Add Hotspot** transaction. This is a one-time fee. -- `65,000` Data Credits for the transaction fee to execute the **Add Hotspot** transaction. -- `1,000,000` Data Credits for the **Assert Location** transaction. Each Hotspot Maker is required - to supply at least one \*_Assert Location_ for their Hotspots. -- `70,000` Data Credits for the transaction fee to execute the **Assert Location** transaction. - -As a Maker, if you only supply the one-time **Add Hotspot** fee and one **Assert Location** fee, -you'll supply `5,135,000` total Data Credits per Hotspot. Add `1,070,000` Data Credits for each -additional **Assert Location** fee you wish to supply. - -:::warning - -If your wallet address does not have enough DCs to pay the required Hotspot transaction fees, these -transactions will fail. - -::: - -## Maker Integration Test Wallet Address - -During your testing, you can use the Maker Integration Test wallet address created by the Helium -Foundation. This wallet does not contain any Data Credits so onboarding transactions will fail but -it allows you to smoke test the onboarding steps. - -Maker Integration Test Wallet Address: - -[138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr](https://explorer-old.helium.com/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr) - -## Burning HNT to Supply Data Credits - -:::warning Double-check any wallet address before executing any HNT burn. - -Once you burn HNT to a specified wallet address, they are burned forever. The resulting DC are -non-transferable. - -::: - -The actual mechanism for burning HNT to DCs is via an on-chain burn transaction using the -[Helium Wallet app](/wallets/helium-wallet-app). Follow the instructions to download and install the -Helium Wallet on your device. Once installed, you'll -[use the "Swap" interface](/hotspot-makers/become-a-maker/funding-a-maker-account) to supply data -credits to your specified Maker wallet, which should be specified as the Recipient wallet. - -:::warning - -Do not send HNT into your Maker accounts. Doing so may result in lost funds. All Makers are required -to pay for the onboarding fees for their customers. - -::: diff --git a/docs/hotspot-makers/become-a-maker/docker-integration.mdx b/docs/hotspot-makers/become-a-maker/docker-integration.mdx deleted file mode 100644 index f8f4ad88a..000000000 --- a/docs/hotspot-makers/become-a-maker/docker-integration.mdx +++ /dev/null @@ -1,143 +0,0 @@ ---- -id: docker-integration -title: Docker Integration -pagination_label: Docker Integration -sidebar_label: Docker Integration -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/docker-integration ---- - -# Docker Integration - -import useBaseUrl from '@docusaurus/useBaseUrl' - -We generally recommend that Makers use Docker for running Miner. This allows you to pull images from -[Helium's Quay repository](https://quay.io/repository/team-helium/miner?tab=tags) and avoids the -need to maintain your own Miner build & release pipeline along with all of Miner's system -dependencies, such as Erlang. - -If you prefer, you _can_ [build Miner from source](https://github.com/helium/miner), but this guide -is for those that are running the Docker image. - -## The Docker Release Process - -Before we get into the details, it's useful to understand how the Quay releases integrate with the -Miner release flow. - -Helium maintains the [Miner repository](https://github.com/helium/miner) and maintains proprietary -firmware images for the original Helium Hotspots (Raspberry Pi 3B+ and 4 based). When we have a -release candidate, you will see a tag with the date of the release candidate. This usually means -that we are testing a release candidate. This testing process has many stages, but if and when a -release passes, it will graduate to "General Availability" and be re-tagged with the `_GA` suffix. -This triggers an automatic build of the Docker images which get pushed to Quay when complete. - -In addition, a "Blockchain Release" will typically be posted on [engineering.helium.com](/devblog). - -As a blockchain is decentralized in its nature, we are careful not to do breaking changes that -require immediate and synchronized updates of the Miner. - -When breaking changes need to be deployed, they tend to be gated by a "chain variable" (aka -`chainvar`) which signals to the Miners that the new behavior is to take affect. Only when this -chain variable is activated do stale Miners stop working. - -:::info - -It is highly recommended that Makers automate the process by checking the Quay repository for `_GA` -tags every half hour, and plan on deploying at least once a day in case there are emergency -releases. - -::: - -## Initial Testing of the Docker on Your Host System - -The Docker image is tailored to be able to run very simply at first, but will generally require -additional customization to integrate well with your host system. - -Start by following [these instructions](/hotspot-makers/become-a-maker/basic-miner-operation). If -that ends up being no problem, then you're doing great! The extra sections in this guide will -discuss things you should do when preparing a production system for the Miner container. - -## Omit REGION_OVERRIDE - -Setting `REGION_OVERRIDE` is only useful if you want a hotspot to forward packets without being -asserted on-chain (ie: they will not earn HNT). In a production system, the override can be -detrimental as it will lock the device into that specific region. Instead, if you omit the override, -the Miner watches the blockchain to figure out which region it has been asserted in. - -In fact, in Helium's own firwmare image, we actually use this information to also determine which -packet forwarder configuration to select, so our startup routine for packet forwarder will actually -block as it requests region from miner - -```bash -# Wait until miner knows the regulatory region. -while ! /opt/miner/bin/miner info region > /dev/null 2>&1; do - sleep 1 -done -``` - -This allows you to ship a single firmware image that will work in any region. When the user has -asserted the Miner and its location to the blockchain, you can get the appropriate region from Miner -and use the appropriate configuration for a packet forwarder. - -:::info - -If you need examples of our regional packet forwarder configurations, please see -[here](https://github.com/helium/sx1302_hal/tree/helium/hotspot/packet_forwarder). - -::: - -:::warning - -If you are using our packet forwarder, be sure to customize the `rssi_offset` field for your -particular concentrator design. Misconfiguring this value may result in decreased Proof-of-Coverage -performance for your customers. - -::: - -## Enable ECC608 and D-Bus - -Miner has [a configuration file](https://github.com/helium/miner/blob/master/config/sys.config) -which exposes many useful variables. For example, Helium uses this to configure the -"[blessed snapshot](https://github.com/helium/miner/blob/master/config/sys.config#L37)" in our -firmware which enables Miners to quickly sync their ledger to the height of the most recent -snapshots. You benefit from this automatically when you use our Docker files. - -However, our Docker images also disable the ECC608 and dbus by default. If you are using the ECC608 -and use the BLE for setting up the hotspots, you need to re-anble them. - -The default Docker overrides are seen -[here](https://github.com/helium/miner/blob/master/config/docker.config). We do a few things that -make the image more portable, such as disabling D-bus (`{use_ebus, false}`) and the ECC608 -(`{key, undefined}`). - -As a Hotspot vendor using Docker, you will want to revert these `sys.config` overrides by simply -deleting them. You can do this in a way that persists over Docker updates by maintaining your own -configuration file outside of the Docker (similar to what we do with `/var/data/`). - -For example, you can create a directory called "overlay" and copy -[the default override](https://github.com/helium/miner/blob/master/config/docker.config). You now -you will have `~/overlay/docker.config`. - -Delete the D-bus line (`{use_ebus, false}`) and the ECC608 line (`{key, undefined}`) and the -behavior will revert to that in -[the main configuration file](https://github.com/helium/miner/blob/master/config/sys.config) where -these are enabled. - -You will also want to add a few arguments to your Docker run command which create the extra mount -point for the config, connect the i2c-device to the Docker container, and connect D-bus to the -Docker container. For example: - -```bash - --device /dev/i2c-1 \ - --net host \ - --privileged \ - -v /var/run/dbus:/var/run/dbus \ - --mount type=bind,source=/home/ubuntu/overlay/docker.config,target=/config/sys.config -``` - -## Define the DBus Config - -You'll want to install -[the Miner's DBus config](https://github.com/helium/miner/blob/master/config/com.helium.Miner.conf), -typically at: `/etc/dbus-1/system.d/com.helium.Miner.conf` diff --git a/docs/hotspot-makers/become-a-maker/funding-a-maker-account.mdx b/docs/hotspot-makers/become-a-maker/funding-a-maker-account.mdx deleted file mode 100644 index dbbfc53f0..000000000 --- a/docs/hotspot-makers/become-a-maker/funding-a-maker-account.mdx +++ /dev/null @@ -1,134 +0,0 @@ ---- -id: funding-a-maker-account -title: Funding A Maker Account -pagination_label: Funding A Maker Account -sidebar_label: Funding A Maker Account -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/funding-a-maker-account ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Hotspot Makers must fund Maker wallets with enough Data Credits ("DC") and SOL to cover the -onboarding fees for all Hotspots they supply to customers. - ---- - -## Funding a Maker Account - -Funding a Maker wallet with Data Credits from HNT tokens is now performed in the Helium Wallet App. -The transaction costs for onboarding and location assertion are paid in SOL to the Solana -blockchain. - -A current public view on the funding status of Maker wallets is available at: - -[https://dune.com/helium-foundation/helium-makers][dune-makers] - -See "Data Credits By Hotspot ManufacturerH. Helium Maker DC Balances" - -### SOL Fees - -These tokens are paid to the Solana blockchain. - -| | IOT Hotspot Transaction Fee | MOBILE Hotspot Transaction Fee | -| ------------------------------------------------------ | --------------------------- | ------------------------------ | -| Hotspot NFT creation | 0.00189616 SOL | 0.00189616 SOL | -| IOT Hotspot onboarding | 0.00175696 SOL | 0.00175696 SOL | -| MOBILE Hotspot onboarding ([^1]) | | 0.00168736 SOL | -| **Total** | **0.00365312 SOL** | **0.00534048 SOL** | - -[^1]: - Onboarding a MOBILE Hotspot is an additional SOL fee as all current MOBILE Hotspots are also IOT - Hotspots. A MOBILE-only Hotspot would not be required to pay the IOT transaction fee. The Maker - App can be configured to do both, either or just one of these network onboards. - -### Data Credit Fees - -These tokens are "burned". - -| | IOT Hotspot Fee | MOBILE Hotspot Fee([^1]) | -| --------------------------- | -------------------------------------------------- | ---------------------------------------------- | -| Onboarding Fee | 4,000,000 DC ($40 USD) | 0 DC | -| First Location Assrtion Fee | 1,000,000 DC([^2]) ($10 USD) | 0 DC | -| **Total** | **5,000,000 DC** | **0 DC** | - -[^2]: Currently 500,000 due to [HIP-69][hip-69]. - ---- - -## Funding Maker Wallets with SOL - -Funding a Maker wallet with SOL is performed the same way as sending tokens to any crypto wallet. -Send from an exchange, another wallet, or swap from another cryptocurrency within the [Helium -Wallet][helium-wallet] using the inbuilt browser and a swap aggregator such as [Jupiter][jupiter]. - ---- - -## Funding Maker Wallets with Data Credits - -Funding a wallet with Data Credits requires HNT, as Data Credits can only be obtained using HNT. The -exchange rate for DC is $1 worth of HNT = 100,000 DC. - -- If HNT is $2 then 0.5 HNT = 100,000 DC -- If HNT is $10 then 0.1 HNT = 100,000 DC - -The USD/HNT exchange rate within the Helium Wallet App is used for the conversion and appears in the -Helium Wallet app before committing the transaction. - -:::warning HNT to DC swaps are irreversible - -Data Credits cannot be refunded, exchanged for other tokens, or transferred between wallets. - -Always double-check the addresses before performing essential operations. - -::: - -### Swap HNT to DC within a Maker Wallet: - -1. Select the Maker Wallet in the Helium Wallet app. -1. Tap the `$` icon on the bottom tab bar. -1. Tap the `Swap` icon in the middle of the screen. -1. Select `HNT` in the top drop-down and enter an amount of HNT to swap. -1. The lower drop-down will be filled with the resulting DC amount. -1. Tap the `Swap Tokens` button and confirm the swap transaction. -1. HNT is burned for DC within the same Wallet. - -The new DC balance amount can be verified in the app tokens list on the `$` tab within the Helium -Wallet app. - ---- - -## Swap to Fund a Different Wallet - -The Helium Wallet app can be used to swap HNT from one wallet to DC in a Maker wallet. - -This method requires that the sending Wallet is already funded with HNT to swap and SOL for -transaction fees. - -Firstly add the Maker Wallet address to the Address Book as a contact. This is the destination -wallet that you will send the DC to: - -1. Tap the `Address Book` icon in the top right corner of the Helium Wallet app. -1. Add new contact with the Maker's Solana wallet address. - -### Swap HNT to DC to send to a Maker Wallet: - -1. Select any Wallet in the Helium Wallet app. -1. Tap the `$` icon on the bottom tab bar. -1. Tap the `Swap` icon in the middle of the screen. -1. Select `HNT` in the top drop-down and enter an amount of HNT to swap. -1. The lower drop-down will be filled with the resulting DC amount. -1. **Tap the grey `Add Recipient +` text to enter the receiving Solana wallet address. This is the - wallet address to send the DC to.** -1. Tap the `...` to the right of Solana Address and select the contact for the Maker Wallet. -1. Tap the `Swap Tokens` button and confirm the swap transaction. -1. HNT is burned for DC within the same Wallet. - -The new DC balance amount in the recipient Maker Wallet can be verified by looking at the Helium -Data Credit token balance of the maker wallet on https://explorer.solana.com/ - -[dune-makers]: https://dune.com/helium-foundation/helium-makers -[helium-wallet]: /wallets/helium-wallet-app -[jupiter]: https://jup.ag/swap -[hip-69]: https://github.com/helium/HIP/blob/main/0069-reassertion-fee-reduction.md diff --git a/docs/hotspot-makers/become-a-maker/hotspot-ble-services.mdx b/docs/hotspot-makers/become-a-maker/hotspot-ble-services.mdx deleted file mode 100644 index 091a922e4..000000000 --- a/docs/hotspot-makers/become-a-maker/hotspot-ble-services.mdx +++ /dev/null @@ -1,189 +0,0 @@ ---- -id: hotspot-ble-services -title: Hotspot BLE Services -pagination_label: Hotspot BLE Services -sidebar_label: Hotspot BLE Services -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/hotspot-ble-services ---- - -# Hotspot BLE Services - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Helium Hotspot provides a Bluetooth Low Energy\(BLE\) interface for users to configure several -aspects of the device. The BLE services and advertisement data are provided below. - -It is generally recommended that the user first press a button on the Hotspot to activate the BLE -advertising. Alternatively, enabling BLE for ~5 minutes after power up is acceptable. Maintaining -BLE advertising for a prolonged period of time is not recommended. - -Hotspot Makers make develop their own BLE service which complies with the specification herein. In -addition, they may leverage Helium's open-source example: -[`gateway-config`](https://github.com/helium/gateway-config) - -:::info - -Data may need to be serialized or de-serialized to -[Protocol Buffers](https://developers.google.com/protocol-buffers) depending on the BLE -Characteristic. The Protocol Buffers message definitions are listed below. For data that are listed -as ASCII string, they can be directly interpreted as ASCII strings. - -::: - -## **Advertisement** - -`Device Name: Helium Hotspot ####` - -`UUID: 0fda92b2-44a2-4af2-84f5-fa682baa2b8d` - -## Device Information - Service - -`UUID: 180A` - -### Manufacture Name String - Characteristic - -`UUID: 2A29` - -`Data Type: ASCII String` - -`Example Value: "Helium"` - -### Serial Number String - Characteristic - -`UUID: 2A25` - -`Data Type: ASCII String` - -`Example Value: "6081F989E7BF"` - -### Firmware Revision String - Characteristic - -`UUID: 2A26` - -`Data Type: ASCII String` - -`Example Value: "2020.02.18.1"` - -## Custom Service - Service - -`UUID: 0fda92b2-44a2-4af2-84f5-fa682baa2b8d` - -### OnboardingKey - Characteristic - -`UUID: d083b2bd-be16-4600-b397-61512ca2f5ad` - -`Data Type: ASCII String` - -`Example Value: "11TqqVzycXK5k49bXbmcUcSne91krq7v3VSQCfDXr"` - -### PublicKey - Characteristic - -`UUID: 0a852c59-50d3-4492-bfd3-22fe58a24f01` - -`Data Type: ASCII String` - -`Example Value: "117ei8D1Bk2kYqWNjSFuLgg3BrtTNSTi2tt14LRUFgt"` - -### WiFiServices - Characteristic - -`UUID: d7515033-7e7b-45be-803f-c8737b171a29` - -`Data Type: Protocol Buffers` - -```text -message wifi_services_v1 { - repeated string services = 1; -} -``` - -### Diagnostics - Characteristic - -`UUID: b833d34f-d871-422c-bf9e-8e6ec117d57e` - -`Data Type: Protocol Buffers` - -```text -message diagnostics_v1 { - mapdiagnostics = 1; -} -``` - -### No Descriptor Name\(WiFi MAC Address\) - Characteristic - -`UUID: 9c4314f2-8a0c-45fd-a58d-d4a7e64c3a57` - -`Data Type: ASCII String` - -`Example Value: "6081F989E7BF"` - -### Lights - Characteristic - -`UUID: 180efdef-7579-4b4a-b2df-72733b7fa2fe` - -`Data Type: ASCII String` - -`Example Value: "on"` - -### WiFiSSID - Characteristic - -`UUID: 7731de63-bc6a-4100-8ab1-89b2356b038b` - -`Data Type: ASCII String` - -`Example Value: ""` - -### AssertLocation - Characteristic - -`UUID: d435f5de-01a4-4e7d-84ba-dfd347f60275` - -`Data Type: Protocol Buffers` - -```text -message assert_loc_v1 { - float lat = 1; - float lon = 2; - string owner = 3; - uint64 nonce = 4; - uint64 fee = 5; - uint64 amount = 6; - string payer = 7; -} -``` - -### AddGateway - Characteristic - -`UUID: df3b16ca-c985-4da2-a6d2-9b9b9abdb858` - -`Data Type: Protocol Buffers` - -```text -message add_gateway_v1 { - string owner = 1; - uint64 amount = 2; - uint64 fee = 3; - string payer = 4; -} -``` - -### WiFiConnect - Characteristic - -`UUID: 398168aa-0111-4ec0-b1fa-171671270608` - -`Data Type: Protocol Buffers` - -```text -message wifi_connect_v1 { - string service = 1; - string password = 2; -} -``` - -### EthernetOnline - Characteristic - -`UUID: e5866bd6-0288-4476-98ca-ef7da6b4d289` - -`Data Type: ASCII String` - -`Example Value: "true" or "false"` diff --git a/docs/hotspot-makers/become-a-maker/hotspot-integration-testing.mdx b/docs/hotspot-makers/become-a-maker/hotspot-integration-testing.mdx deleted file mode 100644 index 6ce370c16..000000000 --- a/docs/hotspot-makers/become-a-maker/hotspot-integration-testing.mdx +++ /dev/null @@ -1,304 +0,0 @@ ---- -id: hotspot-integration-testing -title: Hotspot Integration Testing -pagination_label: Hotspot Integration Testing -sidebar_label: Hotspot Integration Testing -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/hotspot-integration-testing ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This guide is intended for companies that have been approved via HIP-19 and successfully passed the -hardware audit stage. - -All Makers and prospective makers are required to develop, and make available to their customers, -their own mobile app. This allows Makers to create new and differentiating features for their -customers and Hotspots. Examples can include detailed diagnostics reports, notifications of status -changes, peer address reporting, Proof-of-Coverage tips and improvements, and better troubleshooting -and customer support access. - -**Makers are expected to develop their own Maker app** - -To make development easier, a [Maker Starter App](https://github.com/helium/maker-starter-app) is -available for anyone to fork and modify. - -The Helium Wallet app will support HNT / Wallet functions, such as sending payments, receiving -payments, and burn HNT. It will also continue to support the original Helium Hotspots. - -## Starter App features - -- Supports deeplinking and transaction signing through the Helium app - - Simply put: users of the Maker app will not need to sign in with their 12 words, as long as they - are signed in with the Helium app -- Hotspot onboarding with Bluetooth -- Hotspot onboarding with QR Code -- Setting Wi-Fi credentials for Hotspots onboarded with Bluetooth -- Assert Location (Bluetooth and QR Code) -- Generating any required transactions for the Helium app to sign (`add_gateway`, `assert_location`, - `transfer_hotspot_v2`) -- Submit signed transactions to the blockchain -- A settings menu with PIN code, language selector, and the linked Helium address displayed -- Light and Dark mode - -For optimal user experience, we recommend Hotspots be equipped with compatible Bluetooth and Wi-Fi -functionality. This allows a seamless onboarding experience. This integration guide will walk -through both Bluetooth onboarding and QR code/Web onboarding (to support Hotspots without Bluetooth -radios) - -## Using the Maker Starter App - -Instructions to run the Maker Starter app locally on your computer is provided on the README in the -GitHub repo. The app is written in React Native and supports both iOS and Android devices. - -Support for any other operating system will not be available. - -## Hotspot App Integration - -:::info - -Makers in the HIP-19 process can continue to submit their Hotspots to the Hotspot App for -integration. However, all active Makers by March 1, 2022 must have their own Maker app available on -App Stores. - -::: - -To add your Hotspot to the Hotspot App, follow the -[Maker Guide](https://github.com/helium/hotspot-app/tree/main/src/makers) in GitHub and -[submit a pull request to the Hotspot Github Repo](https://github.com/helium/hotspot-app). - -In this codebase, you’ll want to modify the onboarding flow to add a UI element that enables users -to select your Hotspot type on this screen, add support emails to Diagnostic Reports (Bluetooth -only), add additional onboarding instructions (web/QR) and include default antenna TX/RX gain: - -:::info - -Product names on this page should follow [Helium branding guidelines](https://www.helium.com/brand) -and image assets must conform with existing user experience. If you require help, please reach out -to the Helium team. - -::: - -# Types of Onboarding - -## QR Code Onboarding - -QR Code Onboarding allows Makers to generate a partial `add_gateway` transaction outside of the -Helium App. Users use the camera in the Helium App to add this type of Hotspot. - -To select QR Onboarding, in the `hotspot.ts` file, specify `QR` in `onboardType`. - -- [View the example in the Maker Starter app](https://github.com/helium/maker-starter-app/blob/f15a887afead44f2c0bba6ac7460cffebe02dc03/src/makers/example/hotspots.ts#L43) -- [View the example in the Hotspot app](https://github.com/helium/hotspot-app/blob/bbcf058844965e6501295643b95021b6ef26b280/src/makers/__example__/hotspots.ts#L41) -- [Read more about generating QR codes](/wallets/app-wallet/deep-links-and-qr-codes/) - -### Example QR Onboarding Flow - - - - - -## Web Onboarding - -Web Onboarding allows Makers to generate a partial `add_gateway` transaction outside of the Maker -App. Makers generate a deep link back to the Helium App/Maker App to finish the `add_gateway` -transaction. [Read more about deep linking](/wallets/app-wallet/deep-links-and-qr-codes/). - -To select Web onboarding, in the `hotspot.ts` file, specify `web` in `onboardType`. - -- [View the example in the Maker Starter app](https://github.com/helium/maker-starter-app/blob/main/src/makers/example/hotspots.ts) -- [View the example in the Hotspot App](https://github.com/helium/hotspot-app/blob/bbcf058844965e6501295643b95021b6ef26b280/src/makers/__example__/hotspots.ts#L41) - -## Bluetooth Pairing - -The Maker App will start scanning for broadcasting Hotspots. Makers will need to update the -`localname` with the product name and include the last 6 digits of the MAC identifier. The character -limit is 170 but we do not recommend anyone go beyond 25-30 characters in the product name. - -The `localname` is the name used on the **Found Hotspots** page. - -To select Bluetooth onboarding, in the `hotspot.ts` file, specify `BLE` in `onboardType`. - -- [View the example in the Maker Starter App](https://github.com/helium/maker-starter-app/blob/f15a887afead44f2c0bba6ac7460cffebe02dc03/src/makers/example/hotspots.ts#L6) -- [View the example the Hotspot app](https://github.com/helium/hotspot-app/blob/bbcf058844965e6501295643b95021b6ef26b280/src/makers/__example__/hotspots.ts#L8) -- [Read more about BLE Services](/hotspot-makers/become-a-maker/hotspot-ble-services). - -# Constructing the Add Gateway Transaction - -If you’re using [Helium’s miner image](https://github.com/helium/miner), constructing a transaction -is relatively easy. - -Every Hotspot on the blockchain goes through two transactions: - -- **add hotspot**: links the Hotspot's key (`swarm_key`) to a user's wallet -- **assert location**: provides GPS location, elevation (in meters), and dBi antenna output for the - Hotspot - -## Generate an Add Hotspot Transaction - -Use `miner` to generate the `add hotspot` transaction, - -``` -miner txn add_gateway owner=WALLET_ADDRESS --payer WALLET_ADDRESS -``` - -For testing, you'll set `payer` as `payer = 138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr`. In -production, the Payer will be your unique Maker Account Address and will be provided at the -appropriate stage with the Manufacturing Compliance Committee. The current list can be found -[here](https://onboarding.dewi.org/api/v2/makers). - -When testing with this `payer` address, adding hotspots and asserting location transactions will be -submitted and you’ll see them as pending transactions in the Hotspot App. However, once it reaches -the blockchain, the transaction will be discarded as the payer address does not exist in the -blockchain’s `chain_var` of valid addresses. This ensures no Data Credits are spent on testing, but -allows trial and error as Makers finish app integration. - -Once you have the transaction, you will pass it onto the Helium app to sign the transaction. Once -submitted, you can view the pending transaction using this API: - -- [https://api.helium.io/v1/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr/pending_transactions](https://api.helium.io/v1/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr/pending_transactions) - -The output is a JSON object: - -``` -{ - "address": "11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac", - "fee": 65000, - "mode": "full", - "owner": "14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz6S", - "payer": "138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr", - "staking fee": 4000000, - "txn": "CrkBCiEBrlImpYLbJ0z0hw5b4g9isRyPrgbXs9X+RrJ4pJJc9MkSIQA7yIy7F+9oPYCTmDz+v782GMJ4AC+jM+VfjvUgAHflWSJGMEQCIGfugfLkXv23vJcfwPYjLlMyzYhKp+Rg8B2YKwnsDHaUAiASkdxUO4fdS33D7vyid8Tulizo9SLEL1lduyvda9YVRCohAa5SJqWC2ydM9IcOW+IPYrEcj64G17PV/kayeKSSXPTJOMCEPUDo+wM=" -} -``` - -The `txn` output is then passed onto the Helium App over BLE, in QR code format, or through a deep -link in this format: `helium://add_gateway/?mac=` - -:::warning - -By design, this transaction will fail, as this is a test account. - -::: - -Once you’re ready to proceed, request a Maker account and replace the test payer address with your -own maker address. - -## Requesting a Maker Account - -:::warning - -Only request a Maker Account from your Helium Foundation contact if you have been approved by the -Manufacturing Compliance Committee (MCC). - -::: - -In your request, include the Maker Name and how many location asserts you will include for your -customers. A minimum of `1` included location assertion is required. That value is denoted under -`locationNonceLimit`. - -All Maker Accounts are public on the blockchain -[and can be found here](https://onboarding.dewi.org/api/v2/makers). - -Make note of the `Payer` address. This is the account address you will burn HNT into to generate DCs -for onboarding your Hotspots. - -:::info - -Maker IDs are sequential and cannot be customized. - -::: - -## Funding the Maker Account - -[Read the guide](/hotspot-makers/become-a-maker/burn-hnt-to-maker-wallet) for more information. - -## Adding Hotspots to the Onboarding Server - -### Testing - -When you’re ready to start integration with the Test Maker account with the mobile wallet app, send -us details about your Test Hotspot in this JSON format. : - -```json -"mac_eth0": -"mac_wlan0": -"heliumSerial": -"onboarding_key": required -"rpi_serial": -``` - -`"mac_eth0":` Ethernet MAC address - -`"mac_wlan0":` Wi-Fi MAC address - -`"heliumSerial":` Serial number for first generation Helium Hotspots. Can be ignored. - -`"onboarding_key":` The onboarding key generated from the Hotspot miner in base58. Required. - -`"rpi_serial":` Serial number for the RaspberryPi. Can be repurposed to track your own serial -number. - -### Production - -When you move to production, the JSON should be formatted like this. Note the addition of the -`batch` field: - -```json -"batch": "batch_name", -"mac_eth0": "any_value", -"mac_wlan0": "any_value", -"onboarding_key": "base58 address from the Hotspot", -"rpi_serial": "any_value" -``` - -## Wallet App, Onboarding, and Data Credits - -### Testing - -While testing, the miner will use the test payer address to construct the `add_gateway` transaction. -The Hotspot app will take that transaction, sign it, and check the onboarding server to see if the -Hotspot `mac`, `id`, and `Maker` matches and exists. - -If it does, the app submits the transaction to the blockchain. If done correctly, you should see a -[pending transaction here](https://api.helium.io/v1/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr/pending_transactions). - -Note that the blockchain WILL NOT process this transaction because the payer address is not part of -the chain variable of approved Makers. After a short period, the pending transaction will disappear -from the API and the app. This is normal and expected. - -### Production - -Prior to production, you will have sent the list of Hotspots to the Helium Foundation or your Helium -contact to upload to the Onboarding Server on your behalf. You should also have Data Credits in your -Maker account. And if not added already, notify the Helium team to include your Maker address in the -chain variable. - -The final steps and flow for production onboarding are as follows: - -1. Update the `miner` to use your Maker account as payer. -2. Onboard a Hotspot that you know is included in the upload to the Onboarding Server. -3. Go through the Onboarding process in the Hotspot app. The app will check the Onboarding server - for the Hotspot and verify the Maker ID. The app will then sign the transaction and submit to the - blockchain. -4. You’ll see a pending transaction in your Maker address. -5. The blockchain will process the `add_gateway` and `assert_location` transaction and verify that - the maker address is in the chain variable. -6. The transaction will go through and Data Credits will be deducted from the Maker account. -7. The Pending transaction in the Hotspot app will update to **Confirmed**. - -:::warning - -- If the Hotspot `mac`, `serial`, or `Maker` does not match, the transaction will silently fail. -- If there are insufficient Data Credits in the maker account, the transaction will silently fail. - -::: diff --git a/docs/hotspot-makers/become-a-maker/hotspot-wifi-configuration.mdx b/docs/hotspot-makers/become-a-maker/hotspot-wifi-configuration.mdx deleted file mode 100644 index c18294a1c..000000000 --- a/docs/hotspot-makers/become-a-maker/hotspot-wifi-configuration.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -id: hotspot-wifi-configuration -title: Hotspot WiFi Configuration -pagination_label: Hotspot WiFi Configuration -sidebar_label: Hotspot WiFi Configuration -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/hotspot-wifi-configuration ---- - -# Hotspot WiFi Configuration - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Helium Hotspot provides a WiFi configuration interface via the -device's[ BLE services](/hotspot-makers/become-a-maker/hotspot-ble-services). The following are -instructions for how to configure a Hotspot's WiFi. - -### Connecting to the Hotspot over Bluetooth Low Energy - -1. Press the black button on the side of the Hotspot once, and wait a few seconds for the BLE - advertising to begin. You will see the LED on top of the Hotspot turn blue when it is available. -2. Scan for connectable devices. -3. Connect to the Hotspot of interest with the following name format and UUID in its advertising - payload. - - `Name: Helium Hotspot ####` - - `UUID: 0fda92b2-44a2-4af2-84f5-fa682baa2b8d` - -4. Discover Services. - -### Check if Hotspot is already Connected to WiFi - -1. Read Value from: - - Service - - `UUID: 0fda92b2-44a2-4af2-84f5-fa682baa2b8d` - - Characteristic - WiFiSSID - - `UUID: 7731de63-bc6a-4100-8ab1-89b2356b038b` - -2. If string value is empty, then no WiFi connection exist, if it is not empty, then it is currently - connected to that WiFi SSID. -3. If it is not connected or you would like to change networks then proceed. - -### Enable Notifications for WiFiSSID Characteristic Value Update\*\* - -1. Enable Notifications for: - - Service - - `UUID: 0fda92b2-44a2-4af2-84f5-fa682baa2b8d` - - Characteristic - WiFiSSID - - `UUID: 7731de63-bc6a-4100-8ab1-89b2356b038b` - -### Scan For WiFi Networks - -1. Read Value from: - - Service - - `UUID: 0fda92b2-44a2-4af2-84f5-fa682baa2b8d` - - Characteristic -WiFiServices - - `UUID: d7515033-7e7b-45be-803f-c8737b171a29` - -2. De-serialize the binary value into the WiFi Services - [Protocol Buffers](https://developers.google.com/protocol-buffers) message found in - [BLE Services Docs](/hotspot-makers/become-a-maker/hotspot-ble-services#wifiservices---characteristic). - This will give you a list of available WiFi SSID string names. - -### Set Credentials For WiFi Network - -1. Using the SSID string from the scan, and password string provided by you, do the following to set - the credentials. - - 1. Serialize your WiFi Connect [Protocol Buffer](https://developers.google.com/protocol-buffers) - message, the definition of which is found in the - [BLE Services Sheet](/hotspot-makers/become-a-maker/hotspot-ble-services#wificonnect---characteristic). - 2. Write serialized Value to - - Service - - `UUID: 0fda92b2-44a2-4af2-84f5-fa682baa2b8d` - - Characteristic - WiFiConnect - - `UUID: 398168aa-0111-4ec0-b1fa-171671270608` - -### Wait For WiFiSSID Notification to Trigger - -When the notification triggers, this indicates WiFi connection success. You can repeat step two in -order to verify the correct WiFi SSID name. diff --git a/docs/hotspot-makers/become-a-maker/maker-app-requirements.mdx b/docs/hotspot-makers/become-a-maker/maker-app-requirements.mdx deleted file mode 100644 index f287539f5..000000000 --- a/docs/hotspot-makers/become-a-maker/maker-app-requirements.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -id: maker-app-requirements -title: Maker App Requirements -pagination_label: Maker App Requirements -sidebar_label: Maker App Requirements -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/maker-app-requirements ---- - -# Maker Apps - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This document describes what Maker apps requirements are and how users interact with Maker apps on -the Helium Network. - -For more information, -[read our blog post announcing this change](https://blog.helium.com/the-future-of-hotspot-apps-and-wallets-in-the-helium-ecosystem-a5b904b01d62). - ---- - -## SDKs and Starter Apps - -To assist Makers in developing their apps, an SDK and supporting libraries are available. An example -starter app is also open-sourced for forking and further customization. - -### React Native SDK - -The Helium React Native SDK is a collection of modules that can be used by a React Native -application to interact with Hotspots and the Helium Blockchain. It has first class support for -Typescript. - -[Read the full documentation](https://helium.github.io/react-native-helium/index.html) - -### Maker Starter App - -The [Maker Starter App](https://github.com/helium/maker-starter-app) includes support for -deeplinking to the Helium Wallet App to sign transactions, removing any requirements for users to -enter their 12 or 24 word seed phrase into the Maker App. **This is a security precaution and -prevents potential lost of funds and Hotspots, as the seed phrase acts as a user's private key on -the blockchain.** If you find a Maker app that asks for your seed phrase, do not trust it. - -#### Features - -The following features are supported in the Maker Starter App: - -- Add a Hotspot -- Set a Location (including gain and elevation) -- Transfer a Hotspot (optional), Function is now available by transfering an NFT in the - [Helium Wallet](/wallets/helium-wallet-app) -- Settings with PIN Code and language selection -- Deeplinking to [Helium Wallet](/wallets/helium-wallet-app) to sign transactions - -Maker Apps can also include extra enhancements such as Proof-of-Coverage analysis, earnings tools, -and more. - ---- - -## Alternatives to Maker Apps - -We recommend using the Maker App listed below for your Hotspot, as it can have additional management -and diagnostic capabilities. Continued use encourages Makers to continue developing it further. - -Helium application tools company Hotspotty has released a non-maker-specific App -"[Hotspotty Connect](https://docs.hotspotty.net/hotspotty-connect/)" that can help with essential -onboarding, location asserting, and height or antenna updates where a Maker App may not be available -or has a support issue. Select the Maker name in the Hotspotty App to check if they support your -vendor at the current time. - -- Hotspotty Connect documentation: https://docs.hotspotty.net/hotspotty-connect/ - -This app requires connection to the [Helium Wallet App](/wallets/helium-wallet-app) and HNT funds in -the Maker Wallet or your Wallet to perform onboarding, location asserts, antenna, or height updates. - -When there is a need to change a Hotspot's Wifi connection without needing to connect to a Wallet, -the unofficial Helium Hotspot Utility from Kent Williams is available. - -- iOS App: https://apps.apple.com/us/app/helium-hotspot-utility/id1527367455 -- Android App: https://play.google.com/store/apps/details?id=com.kentwilliams.hotspotutility diff --git a/docs/hotspot-makers/become-a-maker/maker-approval-auditing.mdx b/docs/hotspot-makers/become-a-maker/maker-approval-auditing.mdx deleted file mode 100644 index 0b2116f91..000000000 --- a/docs/hotspot-makers/become-a-maker/maker-approval-auditing.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -id: maker-approval-auditing -title: Maker Approval Auditing -pagination_label: Maker Approval Auditing -sidebar_label: Approval And Auditing Process -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/maker-approval-auditing ---- - -# Maker Approval and Auditing Process - -Due to the overwhelming demand for Hotspots, the community designed and approved a process for -adding new, verified manufactures to the ecosystem. -[This is known has HIP-19](https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md). -With HIP 19 in place, companies can submit an application to be reviewed by the community and the -[Helium Foundation](https://www.helium.foundation). - -The full process for approving and auditing new manafacturers is as follows -([originally outlined in this blog post](/devblog/2021/01/26/maker-audit)): - -1. Makers submit a HIP-19 Proposal. -2. Helium Foundation sends KYC/B request for documentation. -3. Helium Foundation approves KYC/B and sends hardware audit information. -4. Makers send hardware samples for audit. -5. Makers obtain and send regulatory radio certifications. \*steps 4 and 5 can happen at the same - time -6. Once Makers pass hardware audit, they are allowed to proceed to Network Integration. -7. The final stage of Network Integration is being able to add Hotspots to the Onboarding Server. diff --git a/docs/hotspot-makers/become-a-maker/security-requirements.mdx b/docs/hotspot-makers/become-a-maker/security-requirements.mdx deleted file mode 100644 index 1e90ea51d..000000000 --- a/docs/hotspot-makers/become-a-maker/security-requirements.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -id: security-requirements -title: Security Requirements -pagination_label: Security Requirements -sidebar_label: Security Requirements -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/become-a-maker/security-requirements ---- - -# Security Requirements - -import useBaseUrl from '@docusaurus/useBaseUrl' - -When the Helium Community passed -[HIP-19](https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md), it was made -clear that open and easy access to the `swarm_key` is not permitted at this time. This helps insure -that the Miner is running on real hardware and increases the barriers to dishonest actors. - -:::info - -The `swarm_key` is an ECC Compact Key used by the Miner to sign all blockchain and libp2p -transactions. The three word animal name (e.g. angry-purple-tiger) is actually derived from the -public key of the `swarm_key`. - -::: - -While formalizing the audit process, the Helium Foundation has determined that the only approved -approach to guaranteeing this at this time is using the ECC608 to generate and store the key during -manufacturing. Other approaches are possible, but they would require case-by-case consideration and -the potentially a third-party audit. - -## Securing the swarm_key with the ECC608 - -Helium has open-sourced their ECC608 provisioning utility from their own manufacturing process -[here](https://github.com/helium/gateway_mfr). By using this utility, not only do you automatically -comply with the ECC608 provisioning process, but you also create compatability with the Helium Miner -with no modifications (other than some configuration to the -[Docker overlay](/hotspot-makers/become-a-maker/docker-integration#enable-ecc608-and-d-bus)). - -You are free to compile the `gateway_mfr` repository from source or use the -[Docker image available here (for aarch64 only)](https://helium-media.s3-us-west-2.amazonaws.com/gateway_mfr-aarch64.tar). - -You will want to do the following: - -``` -docker load -i gateway_mfr.tar -docker run -d --device /dev/i2c-1 --name provision gateway_mfr:arm64 -``` - -With the Docker container running, you are now able to interact with the utility and complete the -provisioning. - -Throughout this process, you might get some errors because the ECC608 can frequently go to sleep. -You may see something like this: - -``` -docker exec provision gateway_mfr ecc onboarding -ecc_asleep -``` - -It is just fine to liberally retry commands until they work. - -First, verify that the ECC608 is untouched: - -``` -$ docker exec provision gateway_mfr ecc test -+--------------------+-------------------------------+ -| name | result | -+--------------------+-------------------------------+ -| serial_num | ok | -|{zone_locked,config}| {error,unlocked} | -| {zone_locked,data} | {error,unlocked} | -| slot_config |{error,{invalid_slot_config,0}}| -| key_config |{error,{invalid_key_config,3}} | -| miner_key |{error,ecc_response_exec_error}| -+--------------------+-------------------------------+ -``` - -This is a failing test, which is good in this case. Next, you will want to run the actual provision -command: - -``` -$ docker exec provision gateway_mfr ecc provision -{zone_locked,[{config,true},{data,true}]} -+--------------------+------+ -| name |result| -+--------------------+------+ -| serial_num | ok | -|{zone_locked,config}| ok | -| {zone_locked,data} | ok | -| slot_config | ok | -| key_config | ok | -| miner_key | ok | -+--------------------+------+ -``` - -You can run the test from the end of the provision command to verify the table at any time: - -``` -docker exec provision gateway_mfr ecc test -+--------------------+------+ -| name |result| -+--------------------+------+ -| serial_num | ok | -|{zone_locked,config}| ok | -| {zone_locked,data} | ok | -| slot_config | ok | -| key_config | ok | -| miner_key | ok | -+--------------------+------+ -``` - -And finally, you will want to extract the `onboarding_key` which is also called the Miner's -"swarm_key": - -``` -docker exec provision gateway_mfr ecc onboarding -112xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -``` - -This is what you will want to provide to the -[onboarding server](/hotspot-makers/become-a-maker/hotspot-integration-testing#adding-hotspots-to-the-onboarding-server). diff --git a/docs/hotspot-makers/hotspot-makers.mdx b/docs/hotspot-makers/hotspot-makers.mdx deleted file mode 100644 index 592a91880..000000000 --- a/docs/hotspot-makers/hotspot-makers.mdx +++ /dev/null @@ -1,348 +0,0 @@ ---- -id: hotspot-makers -title: Approved Hotspot Makers -pagination_label: Approved Hotspot Makers -sidebar_label: Approved Makers -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers ---- - -:::caution Be Careful and Do Your Own Research - -Please be very careful if purchasing a Helium Hotspot from a non-authorized seller. - -Hotspots can be transferred from one Helium Wallet to another. - -Once they are added to the blockchain, only the owning wallet can transfer it to another. - -Any transfers are solely between the two entities ("Buyer" and "Seller"), and Helium is not -involved. - -::: - -Nova Labs (formerly known as Helium Systems, Inc) was the first Hotspot manufacturer. Starting in -early 2019, they produced the first hardware capable of mining HNT and providing LoRaWAN wireless -coverage. In total, Nova Labs produced and sold the first 13,000 Hotspots to the Helium community to -seed the Network. Nova Labs no longer manufacturers Hotspots, but there is now an extensive list of -approved manufacturers (known in the community as "Makers") - -Since the introduction of -[HIP-19](https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md), additional -approved Makers have been added. Each approved Maker is given a unique onboarding address on the -Helium blockchain where they are required to [burn data credits](/blockchain/transaction-fees) to -onboard their unique Hotspots before they are granted access to the blockchain. - -## Aiteks - -- [Website](https://shop.aiteks.com/) -- [Discord](https://discord.gg/nrVjTE9vBp) -- [iOS App](https://apps.apple.com/us/app/aitek-app/id1615083798) -- [Android App](https://play.google.com/store/apps/details?id=com.aitek.maker) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/0d63e182f1381888d017ebf867c860d53ee8bd83/applications/Aitek-inc.md) - -## Atom - -- [Website](https://www.atomdesign.io) -- [Discord](https://discord.gg/sBQP69fcGd) -- [iOS App](https://apps.apple.com/us/app/proton-hotspot/id1616846283) -- [Android App](https://play.google.com/store/apps/details?id=io.atomdesign.proton&gl=ZA&pli=1) -- [Web Dashboard](https://www.atomdesign.io/proton/) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/atom-design-and-innovation.md) - -## Bobcat (Bobber) - -- [Website](http://bobber.com/) -- [Support](https://zendesk.bobber.com/hc/en-us/requests/new) -- [Discord](https://discord.gg/2Barf528uj) -- [iOS App](https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=1595267515) -- [Android App](https://play.google.com/store/apps/details?id=com.bobcatminer.hotspot) -- IOT Hotspot HIP19 Application: - - [Bobber 300](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/easylinkin.md) - - [Bobber 200](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/bobcat-light-audit.md) -- Onboarding Maker Address: - [14sKWeeYWQWrBSnLGq79uRQqZyw3Ldi7oBdxbF6a54QboTNBXDL](https://explorer-old.helium.com/accounts/14sKWeeYWQWrBSnLGq79uRQqZyw3Ldi7oBdxbF6a54QboTNBXDL) - -## ClodPi - -- [Website](https://clodpi.io/) -- [Discord](https://discord.gg/unJjAtZHBZ) -- [Android App](https://play.google.com/store/apps/details?id=io.clodpi.hotspots) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/clodpi.md) -- Onboarding Maker Address: - [13XuP2DjHEHVkKguDDZD2ev5AeqMLuJ8UQ44efEcDmVTnBcvc6F](https://explorer-old.helium.com/accounts/13XuP2DjHEHVkKguDDZD2ev5AeqMLuJ8UQ44efEcDmVTnBcvc6F) - -## Controllino/Conelcom - -- Website: - https://www.nebra.com/blogs/news/nebra-ltd-providing-updates-for-controllino-conelcom-hotspots -- [Discord](https://discord.gg/s8NAKj7Vfx) -- [iOS App](https://apps.apple.com/app/cotx/id1605937419) -- [Android App](https://play.google.com/store/apps/details?id=com.cotxnetworks) -- [Web Dashboard](https://www.cotx-sg.io/login) - -## COTX - -- [Website](https://www.cotxnetworks.com/) -- [Discord](https://discord.gg/s8NAKj7Vfx) -- IOT Hotspot HIP19 Application: - - [Model X3](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/cotx-networks.md) - - [Model X5](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/cotx_outdoor-full-hotspot.md) - - [Model X1](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/cotx_light-hotspot.md) - -## Dragino - -- [Website](https://www.dragino.com) -- [Discord](https://discord.gg/KSwbc6EsRJ) -- [Android App](http://8.211.40.43:8080/xwiki/bin/view/Main/User%20Manual%20for%20All%20Gateway%20models/HP0D/#H2.3OnboardingHotspotviaDraginoApp) -- IOT Hotspot HIP19 Application: - - [Full Outdoor Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/dragino-full-hotspot.md) - - [Light Indoor Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/dragino-light-hotspot.md) - - [Light Outdoor Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/dragino-light-hotspot.md) - -## Dusun - -- [Website](https://www.dusuniot.com/) -- [Discord](https://discord.gg/d5b2Y2rUsv) -- [iOS App](https://apps.apple.com/gb/app/dusun-hotspot-app/id1614559106) -- [Android App](https://play.google.com/store/apps/details?id=com.maker.dusunhotspotapp) -- IOT Hotspot HIP19 Application: - - [Full Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/dusun.md) - - [DSGW-090B](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/dusun_light_hotspot.md) - - [DSG-010C](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/dusun_outdoor.md) - -## EDATEC / EDA-IoT - -- [Website](https://www.eda-iot.com) -- [Support](mailto:support@edatec.cn) -- [Discord](https://discord.gg/SKwEeSreJu) -- [iOS App](https://apps.apple.com/us/app/eda-iot-hotspot/id1629546243) -- [Android App](https://play.google.com/store/apps/details?id=com.edaiot.makerapp) -- IOT Hotspot HIP19 Application: - - [Full Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/edatec.md) - - [Light Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/edatec-light.md) - -## Finestra (Mimiq) - -- [Website](https://thefinestra.com) -- [iOS App](https://apps.apple.com/us/app/finestraminer-app/id1614250948) -- [Android App](https://play.google.com/store/apps/details?id=com.mimiq.finestraminerapp) -- [Web Dashboard](https://thefinestra.com/#cloud-dashboard-m |) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/smart-mimic.md) -- Onboarding Maker Address: - [13MS2kZHU4h6wp3tExgoHdDFjBsb9HB9JBvcbK9XmfNyJ7jqzVv](https://explorer-old.helium.com/accounts/13MS2kZHU4h6wp3tExgoHdDFjBsb9HB9JBvcbK9XmfNyJ7jqzVv) - -## FreedomFi - -- [Website](https://freedomfi.com/) -- [iOS App](https://apps.ios.com/us/app/freedomfi/id1608377889) -- [Android App](https://play.google.com/store/apps/details?id=com.freedomfi.FreedomFiApp) -- [MOBILE Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/freedomfi.md) - -## Helium Hotspot - -- [Discord](https://discord.gg/helium) -- [iOS App](https://apps.apple.com/us/app/helium-hotspot/id1450463605) -- [Android App](https://play.google.com/store/apps/details?id=com.helium.wallet) - -## Heltec - -- [Website](https://heltec.org/) -- [Support](https://docs.heltec.org/) -- [Discord](https://discord.gg/Pt85TrZfxZ) -- [iOS App](https://apps.apple.com/app/heltec-hotspot/id6444391876) -- [Android App](https://heltec.org/maker-app/) -- IOT Hotspot HIP19 Application: - - [HT-2808](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/heltec.md) - - [HT-M7603](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/heltec-light.md) - -## Hummingbird / RUFF - -- [Website](https://www.xdt.com) -- [Discord](https://discord.gg/wUk9nfFGZW) -- [iOS App](https://apps.apple.com/app/hummingbird-hotspot/id1612429261) -- [Android App](https://www.xdt.com/app.html) -- [IOT Hotspot HIP19 Application](https://github.com/ruffjs/HIP/blob/master/0019-third-party-manufacturers/ruff.md) - -## Kerlink - -- [Website](https://www.kerlink.com) -- [Discord](https://discord.gg/9sYADWvZPg) -- [iOS App](https://apps.apple.com/fr/app/kerlink-helium-hotspot/id1613698129) -- [Android App](https://play.google.com/store/apps/details?id=com.kerlink.heliumhotspot&hl=fr&gl=US) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/tree/main/applications/kerlink) -- Onboarding Maker Address: - [13Mpg5hCNjSxHJvWjaanwJPBuTXu1d4g5pGvGBkqQe3F8mAwXhK](https://explorer-old.helium.com/accounts/13Mpg5hCNjSxHJvWjaanwJPBuTXu1d4g5pGvGBkqQe3F8mAwXhK) - -## KS Technologies - -- [Website](https://kstechnologies.com/) -- [Support](mailto:info@kstechnologies.com) -- [Android App](https://kstechnologies.com/affinity/affinitySetup#mobile) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/ks-technologies.md) - -## Linxdot / FX Technology - -- [Website](https://www.linxdot.com) -- [Discord](https://discord.gg/WZufQURR7m) -- [iOS App](https://apps.apple.com/lv/app/linxdot-hotspot/id1605551724) -- [Android App](https://play.google.com/store/apps/details?id=com.linxdot.companionapp&hl=en_GB&gl=US) -- IOT Hotspot HIP19 Application: - - [Full Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/linxdot.md) - - [LD1001 & LD1002](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/linxdot-rockchip.md) - - [LD-500 & LD-559](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/linxdot-light-hotspots.md) -- [MOBILE Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/6d837055a189fa2e19b5f3c4163b4d75d524a268/linxdot-5g-hotspot.md) - -## LongAP/HeNet BV - -- [Website](https://www.longap.com) -- [Support](mailto:support@longap.co)) -- [Discord](https://discord.gg/n3E3gvZr6b) -- [Local Dashboard](http://dashboard.longap.com/) -- Onboarding Maker Address: - [12zX4jgDGMbJgRwmCfRNGXBuphkQRqkUTcLzYHTQvd4Qgu8kiL4](https://explorer-old.helium.com/accounts/12zX4jgDGMbJgRwmCfRNGXBuphkQRqkUTcLzYHTQvd4Qgu8kiL4) - -## MerryIoT (Browan) - -- [Website](https://www.browan.com/) -- [Support](mailto:support@merryiot.com) -- [iOS App](https://apps.ios.com/us/app/merryiot-hotspot/id1615538142) -- [Android App](https://play.google.com/store/apps/details?id=com.merryiot.makerapp) -- IOT Hotspot HIP19 Application: - - [Light Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/MerryIoT%20Light%20Hotspot%20V2.md) - - [Full Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/merryiot.md) - -## Midas - -- [Website](https://www.midaswireless.io/) -- [Discord ](https://discord.gg/yFSTWJrA6R) -- [iOS App](https://apps.apple.com/us/app/midas-starter/id1612601349) -- [Android App](https://play.google.com/store/apps/details?id=com.midaswireless.starter) -- IOT Hotspot HIP19 Application: - - [Full Hotspot](https://github.com/helium/HIP/blob/3768d9bbdaf9cd0e9377ce61ac86424393b354ff/0019-third-party-manufacturers/midas.md) - - [Light Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/midas-light-hotspot.md) - -## Milesight IoT - -- [Website](https://www.milesight-iot.com) -- [Discord ](https://discord.gg/2wAbU4eyRy) -- [Android App](https://play.google.com/store/apps/details?id=com.milesight.hotspot) -- [IOT Hotspot HIP19 Application](https://github.com/helium/HIP/blob/bd53cbb57621b63b832163960ea2dd8fb78b1c72/0019-third-party-manufacturers/Milesight%20IoT.md) - -## MNTD / RAK Wireless - -- Website: -- [Discord ](https://discord.gg/j92Nu5nmP9) -- [iOS App](https://apps.apple.com/app/hotspotty-connect/id1622212036) -- [Android App](https://play.google.com/store/apps/details?id=com.hotspottyconnect) - -## Nebra - -- [Website](https://www.nebra.com/) -- [iOS App](https://apps.apple.com/gb/app/nebra-hotspot/id1617299471) -- [Android App](https://play.google.com/store/apps/details?id=com.nebra.helium.maker) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/nebra-ltd.md) -- [MOBILE Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/nebra-5g-ready.md) -- Onboarding Maker Address: - [13Zni1he7KY9pUmkXMhEhTwfUpL9AcEV1m2UbbvFsrU9QPTMgE3](https://explorer-old.helium.com/accounts/13Zni1he7KY9pUmkXMhEhTwfUpL9AcEV1m2UbbvFsrU9QPTMgE3) - -## Nova Labs / Helium Systems, Inc. - -- Onboarding Maker Address: - [13daGGWvDQyTyHFDCPz8zDSVTWgPNNfJ4oh31Teec4TRWfjMx53](https://explorer-old.helium.com/accounts/13daGGWvDQyTyHFDCPz8zDSVTWgPNNfJ4oh31Teec4TRWfjMx53) - -## Osprey Electronics (Ingenioius Technology) - -- [Discord ](https://discord.gg/dyJf8DD) -- [iOS App](https://apps.apple.com/us/app/osprey-electronics-hotspot/id1616301064) -- [Android App](https://play.google.com/store/apps/details?id=com.osprey.electronics) - -## Panther - -- [Website](https://panther.global/) -- [Discord ](https://discord.gg/PGeJPDUs8d) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/pantherx.md) -- Onboarding Maker Address: - [13v9iGhjvQUtVaZXcFFRCEbL1nPR4R8QJowBgMUcaGM2v1aV6mn](https://explorer-old.helium.com/accounts/13v9iGhjvQUtVaZXcFFRCEbL1nPR4R8QJowBgMUcaGM2v1aV6mn) - -## Pisces (GreenPalm) - -- [Website](http://www.piscesminer.com/) -- [Discord ](https://discord.gg/cBwEUxHcn4) -- [iOS App](https://apps.apple.com/cn/app/pisceshotspot/id1615544069) -- [Android App](https://play.google.com/store/apps/details?id=com.pisces.pisces) -- IOT Hotspot HIP19 Application: - - [Full Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/pisces-miner.md) - - [Light Hotspot](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/Pisces-Indoor-Light-Hotspot.md) - -## Polyhex - -- [Website](http://www.polyhex.net/) -- [Discord](https://discord.gg/Xx32dUy377) -- [iOS App](https://apps.apple.com/cn/app/polyhex-miner/id6444090208) -- [Android App](https://play.google.com/store/apps/details?id=com.polyhex.miner) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/Polyhex.md) - -## Pycom - -- [Website](https://www.nebra.com/blogs/news/syncrobit-hotspots-join-nebra-family) -- [Discord](https://discord.gg/sBQP69fcGd) - -## RAK Wireless - -- [Website](https://www.rakwireless.com/) -- [Discord](https://discord.gg/j92Nu5nmP9) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/rak-wireless.md) -- Onboarding Maker Address: - [13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDirdY](https://explorer-old.helium.com/accounts/13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDirdY) - -## ResIOT.io - -- [iOS App](https://apps.apple.com/app/resiot-helium-hotspot/id6444005674) -- [Android App](https://play.google.com/store/apps/details?id=com.resiot.heliumhotspot&hl=it) -- [Web Dashboard](https://helium.resiot.io/#dashboard) - -## RisingHF - -- Website: -- [Discord ](https://discord.gg/MkD2X2NSUd) -- [iOS App](https://apps.apple.com/app/risinghfhotspots/id1628074599) -- [Android App](https://play.google.com/store/apps/details?id=com.risinghf.hotspot) - -## SenseCAP (Seeed) - -- [Website](https://www.sensecapmx.com/) -- [Discord ](https://discord.gg/QqMgVwHT3X) -- [iOS App](https://apps.apple.com/us/app/sensecap-hotspot/id1600051150) -- [Android App](https://play.google.com/store/apps/details?id=com.sensecapmx.hotspot) -- [Web Dashboard](https://status.sensecapmx.cloud/) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/seeed.md) -- Onboarding Maker Address: - [14NBXJE5kAAZTMigY4dcjXSMG4CSqjYwvteQWwQsYhsu2TKN6AF](https://explorer-old.helium.com/accounts/14NBXJE5kAAZTMigY4dcjXSMG4CSqjYwvteQWwQsYhsu2TKN6AF) - -## Smart Harvest - -- [Website](https://smartharvest.ca/) -- [Support](mailto:@smartharvest.ca) -- [IOT Hotspot HIP19 Application](https://github.com/SmartHarvestInstruments/HIP/blob/master/0019-third-party-manufacturers/smart-harvest-instruments.md) - -## SONoC - -- [Website](https://sonoc.tw/) -- [Support](mailto:support@SONoC.tw) -- [Discord](https://discord.com/invite/jVRadSDNew) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/0d50f13b6942de34dcbf87b64f8d795f4c57189f/SONoC.md) - -## SyncroB.it - -- [Website](https://www.nebra.com/blogs/news/syncrobit-hotspots-join-nebra-family) -- Onboarding Maker Address: - [14rb2UcfS9U89QmKswpZpjRCUVCVu1haSyqyGY486EvsYtvdJmR](https://explorer-old.helium.com/accounts/14rb2UcfS9U89QmKswpZpjRCUVCVu1haSyqyGY486EvsYtvdJmR) - -## uGWAN Pro (Amber Link) - -- [Website](https://www.ugwan.io/) -- [Support](mailto:support@ugwan.io) -- [iOS App](https://apps.apple.com/us/app/1645839473) -- [Android App](https://play.google.com/store/apps/details?id=com.amberlink.ugapp) -- [IOT Hotspot HIP19 Application](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/ugwan-pro-ecc608.md) diff --git a/docs/hotspot-makers/iot/data-only-hotspots.mdx b/docs/hotspot-makers/iot/data-only-hotspots.mdx deleted file mode 100644 index e1aca6ae3..000000000 --- a/docs/hotspot-makers/iot/data-only-hotspots.mdx +++ /dev/null @@ -1,155 +0,0 @@ ---- -id: data-only-hotspots -title: Data Only Hotspots -pagination_label: Data Only Hotspots -sidebar_label: Data Only Hotspots -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/data-only-hotspots ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Data Only Hotspots - -Data Only Hotspots are eligible for **Network Data Transfer Rewards** but not **Proof of Coverage -Rewards**. - -Since Data Only Hotspots do not earn Proof-of-Coverage rewards, they may be permissionlessly added -to the blockchain. Once added to the blockchain and with location asserted, they will earn $HNT when -forwarding network data. - -| Rewards Type | Data Only Hotspots | Full & Light Hotspots | -| :---------------------- | :----------------- | :-------------------- | -| Network Data Forwarding | YES | YES | -| Proof of Coverage | NO | YES | - -# Setup a Data Only Hotspot - -## Transactions & Cost - -Every Hotspot on the blockchain goes through two transactions: - -- **add hotspot**: links the Hotspot's key (`swarm_key`) of a Hotspot to a user's wallet -- **assert location**: provides GPS location, elevation (in meters), and dBi antenna output for the - Hotspot - -The fee schedule is as follows: - -- **add data only hotspot**: 1000000 DC ($10) -- **assert location**: 500000 DC ($5) - -:::info - -Data Credits in your Helium Console organization cannot be used to pay blockchain onboarding and -assert location fees for Hotspots. To onboard a Hotspot, you'll need to burn HNT for Data Credits to -the wallet that owns the Hotspot. - -::: - -## Pre-requisites - -You should [setup a packet forwarder](/use-the-network/setup-a-packet-forwarder) with the -[light hotspot client](/hotspot-makers/iot/light-hotspots). - -In addition, you should setup a [CLI wallet](/wallets/cli-wallet) as this is currently the only -wallet that supports DIY Data Only Hotspots. Retail Data Only Hotspots from Hotspot Vendors can be -onboarded using the Vendor IOS and Android apps. - -**Note**: you can import a mobile wallet to the CLI. **Another note**: you should **not** install -the CLI on your gateway - -## Add Hotspot - -From a terminal on the device where the Light Hotspot client is installed, you need to generate the -`add hotspot` transaction. - -``` -./helium_gateway add --owner WALLET_ADDRESS --payer WALLET_ADDRESS --mode dataonly -``` - -The output is a JSON object: - -``` -{ - "address": "11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac", - "fee": 65000, - "mode": "dataonly", - "owner": "14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz6S", - "payer": "14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz6S", - "staking fee": 1000000, - "txn": "CrkBCiEBrlImpYLbJ0z0hw5b4g9isRyPrgbXs9X+RrJ4pJJc9MkSIQA7yIy7F+9oPYCTmDz+v782GMJ4AC+jM+VfjvUgAHflWSJGMEQCIGfugfLkXv23vJcfwPYjLlMyzYhKp+Rg8B2YKwnsDHaUAiASkdxUO4fdS33D7vyid8Tulizo9SLEL1lduyvda9YVRCohAa5SJqWC2ydM9IcOW+IPYrEcj64G17PV/kayeKSSXPTJOMCEPUDo+wM=" -} -``` - -The `txn` field needs to be used as the input to the wallet command `helium-wallet hotspot add`. For -example: - -``` -helium-wallet hotspots add CrkBCiEBrlImpYLbJ0z0hw5b4g9isRyPrgbXs9X+RrJ4pJJc9MkSIQA7yIy7F+9oPYCTmDz+v782GMJ4AC+jM+VfjvUgAHflWSJGMEQCIGfugfLkXv23vJcfwPYjLlMyzYhKp+Rg8B2YKwnsDHaUAiASkdxUO4fdS33D7vyid8Tulizo9SLEL1lduyvda9YVRCohAa5SJqWC2ydM9IcOW+IPYrEcj64G17PV/kayeKSSXPTJOMCEPUDo+wM= -``` - -After you verify the transaction, append the command with `--commit` to submit it to the API. Note -that you need sufficient funds to cover both the transaction cost (65000 DC) and the `staking_fee` -(1000000 DC). Thanks to the -["implicit burn" mechanism](/blockchain/transaction-fees/#transaction-fees-and-implicit-burn), -available HNT will be used to cover the transaction if you have insufficient DCs. - -You can track the transaction progress by using the transaction hash at the following endpoint: -`https://api.helium.io/v1/pending_transactions/TXN_HASH` - -Once the transaction clears, you're done linking the Hotspot with your wallet. - -:::warning - -At this point, you will want to be certain that you've backed up the data only hotspot's keypair. -Its location can be customized in the client's `settings.toml`, but by default, it's located at -`/etc/helium_gateway/gateway_key.bin` - -::: - -## Assert Hotspot - -To assert the Hotspot use `helium-wallet hotspots assert` - -``` -helium-wallet hotspots assert --gateway DATA_ONLY_HOTSPOT_PUBKEY --lat=37.7806295 --lon=-122.4008481 --mode dataonly -``` - -The `DATA_ONLY_HOTSPOT_PUBKEY` in the example from the previous section would be -`11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac`. - -`--elevation` and `--gain` can be also set. Use `helium-wallet hotspots assert --help` for more -info. - -After you verify the transaction, append the command with `--commit` to submit it to the API. Note -that you need sufficient funds to cover both the transaction cost (65000 DC) and the `staking_fee` -(500000 DC). Thanks to the -["implicit burn" mechanism](/blockchain/transaction-fees/#transaction-fees-and-implicit-burn), -available HNT will be used to cover the transaction if you have insufficient DCs. - -You can track the transaction progress by using the transaction hash at the following endpoint: -`https://api.helium.io/v1/pending_transactions/TXN_HASH` - -Once the transaction clears, your Data Only Hotspot is ready to start earning for data transfered! - -## Data-Only Hotspot Setup Guides - -- [Dragino LPS80/DLOS8](/hotspot-makers/iot/data-only/dragino) - - Draginos will only mine HNT as a Data Only Hotspot -- [Kerlink gateways](/hotspot-makers/iot/data-only/kerlink) - - Kerlink gateways will only mine HNT as Data Only Hotspot unless it is specified as a - Helium-Compatible Kerlink Miner. -- [RAK Concentrator (RAK2245/RAK2247/RAK2287) + Raspberry Pi 2, 3, or 4](/hotspot-makers/iot/data-only/rak-concentrators) - - This setup will only mine HNT as a Data Only Hotspot. -- [Balena Data Only Hotspot running Raspberry Pi 0, 2, 3 or 4 with RAK Concentrator (RAK2287)](/hotspot-makers/iot/data-only/balena-data-only-hotspot) - - This setup based on Nebra will only mine HNT as a Data Only Hotspot, when possible. -- [Dragino PG1301 + Raspberry Pi 4](/hotspot-makers/iot/data-only/dragino-pg1301) - - This setup based on the Dragino PG1301 Concentrator will only mine HNT as a Data Only Hotspot. - -:::info - -Gateways running a Packet Forwarder and Miner is not considered a Light Hotspot and will never earn -HNT. - -::: diff --git a/docs/hotspot-makers/iot/data-only/balena-data-only-hotspot.mdx b/docs/hotspot-makers/iot/data-only/balena-data-only-hotspot.mdx deleted file mode 100644 index c92a0179e..000000000 --- a/docs/hotspot-makers/iot/data-only/balena-data-only-hotspot.mdx +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: balena-data-only-hotspot -title: Data Only Hotspot with balena + Raspberry Pi + RAK Concentrator RAK2287 -pagination_label: balena.io + Raspberry Pi + RAK Concentrators (RAK2287) -sidebar_label: balena.io + Raspberry Pi + RAK Concentrators (RAK2287) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/data-only/balena-data-only-hotspot ---- - -# Data Only Hotspot Setup with balena + Raspberry Pi + RAK2287 - -import useBaseUrl from '@docusaurus/useBaseUrl' - -A Data Only Hotspot is a type of Hotspot that participates on the Helium Network by transferring -data from the end devices (LoRaWAN nodes). The Data Only Hotspots are eligible for Network Data -Transfer Rewards but not Proof of Coverage Rewards. - -This guide covers all the steps needed to set up a Data Only Hotspot using a Raspberry Pi and a RAK -concentrator (RAK2287) and the Pi Hat running on balena. This configuration can be achieved by -installing the **_gatewayrs_** and **_packet forwarder_** services open sourced by -[Nebra](https://github.com/nebraltd) and using balenaOS and [balenaCloud](https://balena.io). - -:::warning - -Data Only Hotspots cannot earn $HNT, at least for now, and after milestone 2 they will earn $HNT -only for Device Packet Transfer. Remember to keep an eye on -[Light Hotspots - BETA](/hotspot-makers/iot/light-hotspots) and the -**[#gateway-development](discord://discord.com/channels/404106811252408320/784462269072277576)** -channel on the [Helium Discord Server](https://discord.gg/helium) to check how the development -process evolves. - -::: - -## Getting started - -### Hardware - -- Raspberry Pi 0/2/3/4 or balenaFin -- SD card in case of the Raspberry Pi - -- [RAK 2287 LoRa concentrator SPI based](https://store.rakwireless.com/products/rak2287-lpwan-gateway-concentrator-module) - and [RAK2287 Pi Hat](https://store.rakwireless.com/products/rak2287-pi-hat) - -:::important - -To use the concentrator module with a Raspberry Pi HAT, you must make sure to order the variation -with the SPI interface. - -::: - -### Software - -- [balena.io account](https://dashboard.balena-cloud.com/) -- [balenaEtcher](https://balena.io/etcher) - -## Deploy the code - -Running this Data Only Hotspot with balena.io is as simple as deploying it to a balenaCloud -application. You can do it in just one click by using the button below: - -[![](https://www.balena.io/deploy.png)](https://dashboard.balena-cloud.com/deploy?repoUrl=https://github.com/mpous/helium-data-hotspot) - -Follow instructions, click `Add a Device` and flash an SD card with that balenaOS image dowloaded -from balenaCloud. Enjoy the magic 🌟Over-The-Air🌟! - -Find the [repository with the source code here](https://github.com/mpous/helium-data-hotspot) if you -would like to clone and deploy from your computer or you would like to contribute. - -## Configure the device - -### Device Variables - -Once the device is online on balenaCloud and the services `packet-forwarder` and `gatewayrs` are -downloaded and installed, go to `Device Variables`. - -- Create the variable for all the services `VARIANT` with your hardware definition. During the test - is being used a Raspberry Pi 4 with RAK2287 LoRa concentrator and the `VARIANT` is defined - `DIY-RAK2287`. This `VARIANT` is compatible with any Raspberry Pi. You can find here the - [list of hardware compatible](https://github.com/NebraLtd/helium-hardware-definitions). - -- Create the variable for all the services `REGION_OVERRIDE` with your LoRa region (e.g. `EU868`). - You can find here the [list of LoRa regions compatible](https://github.com/NebraLtd/hm-pktfwd). - -### Test the Helium Hotspot - -Once the Device Variables are properly set up, the Hotspot should be running showing some errors on -connecting to the Blockchain on the balenaCloud Logs. - -To check that the Hotspot has been generated correctly, go to the `Terminal` and select the -`gatewayrs` service, then introduce. - -`helium_gateway key info` - -And you will get something like this: - -`{ "address": , "name": }` - -At this point, your Data Only Hotspot is ready to join the Helium blockchain! - -### Join the Helium blockchain with your Hotspot - -To join the Helium blockchain, at the moment (summer 2021) you only can use the Helium CLI. The -Helium app is still not compatible with the data-only hotspots. Follow -[this instructions](https://github.com/mpous/helium-data-hotspot/#join-the-helium-blockchain-with-your-data-only-hotspot) -to add your Data Only Hotspot on the Blockchain. - -You can find as well the instructions to do it -[here](https://github.com/mpous/helium-data-hotspot/#join-the-helium-blockchain-with-your-data-only-hotspot). - -## Check your Data Only Hotspot - -Now that your Data Only Hostpot has been added into the Helium Blockchain you should be able to see -it on your Helium wallet. - -Go to the [Helium Explorer](https://explorer-old.helium.com/) and introduce your URL -`https://explorer-old.helium.com/hotspots/`. - -If you create a Helium Device, then go to the [Helium Console](https://console.helium.com) and -Inspect packages from your device to confirm that the Data Only Hostpot is the one that relays the -data from your Devices. You also will be able to see on the balenaCloud logs that UPLINK messages -have been relayed to the Helium OUI. - -## Manage your gateway_key - -It's extremely important that at this point, with the Hotspot added on the Helium blockchain you -backup the `gateway_key`. If you loose this key, you will not be able to use this hotspot anymore in -case there is a problem on your hostpot (SD card corrupted, etc). - -### Backup your gateway_key.bin file - -Follow this instructions to backup your gateway_key.bin file of your hotspot. - -- Open an SSH session to the "host-os" on balenaCloud Terminal. -- Type this command and keep note of the (YOUR INSTANCE)\_miner-storage: - `ls /var/lib/docker/volumes` -- Type this command to get a link to download the gateway key (note to replace the YOUR INSTANCE - part with the container number that you got from the previous command) - `curl -F "file=@/var/lib/docker/volumes/(YOUR INSTANCE)_miner-storage/_data#/gateway_key.bin" https://file.io` -- Use the outputted file.io link to securely download your swarm key. The link only works one time. - -### Restore your gateway_key.bin file on your new file - -Follow this instructions to restore your gateway_key.bin key into your new hotspot. - -- Open an SSH session to the "host-os" on balenaCloud Terminal. -- Type this command and keep note of the (YOUR INSTANCE)\_miner-storage information: - `ls /var/lib/docker/volumes` -- Navigate to where the swarm_key is stored - `cd /var/lib/docker/volumes/(YOUR INSTANCE)_miner-storage/_data#/` -- Remove the original `gateway_key.bin` file `rm gateway_key.bin` -- Reboot miner and you will see it restored and working :) -- Upload your `gateway_key.bin` that you wish to restore onto file.io and do - `curl -LJO [FILE.IO UPLOAD LINK]` - -## Contributions - -Thank you to Nebra for developing and balenifying the Helium Hotspot, Helium developers community, -Jose from RAK, Travis and Joseph from balena to work on the dbus + conman issues. diff --git a/docs/hotspot-makers/iot/data-only/dragino-pg1301.mdx b/docs/hotspot-makers/iot/data-only/dragino-pg1301.mdx deleted file mode 100644 index b2bf2830c..000000000 --- a/docs/hotspot-makers/iot/data-only/dragino-pg1301.mdx +++ /dev/null @@ -1,345 +0,0 @@ ---- -id: dragino-pg1301 -title: Data Only Hotspot Setup Dragino PG1301 and Raspberry Pi -pagination_label: Dragino PG1301 + Raspberry Pi -sidebar_label: Dragino PG1301 + Raspberry Pi -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/data-only/dragino-pg1301 ---- - -# Data Only Hotspot Setup with Dragino PG1301 and Raspberry Pi - -import useBaseUrl from '@docusaurus/useBaseUrl' - -A Data Only Hotspot is a type of Hotspot that participates on the Helium Network by transferring -data from the end devices (LoRaWAN nodes). The Data Only Hotspots are eligible for Network Data -Transfer Rewards but not Proof of Coverage Rewards. - -This guide covers all the steps needed to set up a Data Only Hotspot using a Raspberry Pi and -Dragino PG1301 hat. - -:::warning - -Data Only Hotspots cannot earn $HNT, at least for now, and after milestone 2 they will earn $HNT -only for Device Packet Transfer. Remember to keep an eye on -[Light Hotspots - BETA](/hotspot-makers/iot/light-hotspots) and the -**[#gateway-development](discord://discord.com/channels/404106811252408320/784462269072277576)** -channel on the [Helium Discord Server](https://discord.gg/helium) to check how the development -process evolves. - -::: - -## Getting started - -This process assumes you have some basic Linux skills, can use a text editor and understand what a -service is. You should be able to use programs like `scp` to move data between the Raspberry Pi and -other computers on your network. - -What we will be doing is : - -- installing the LoRa Packet Forwarder service from Dragino to use the Concentrator hat -- installing the Helium Gateway service to move data between the packet forwarder and the Helium - network -- configure everything -- verify everything is working - -### Hardware - -- Raspberry Pi 4. Other faimilies of Pi may work, but this has only been tested on the Pi 4 Model B. -- [Dragino 10 channels - LoRaWAN GPS Concentrator for Raspberry Pi](https://www.dragino.com/products/lora/item/149-lora-gps-hat.html) - -### Software - -We will be using the following: - -- Fresh Raspbian Buster image -- lorapktfwd package from - [Dragino Downloads Site](https://www.dragino.com/downloads/index.php?dir=LoRa_Gateway/PG1301/software/) -- Latest helium-gateway package release from [Helium](https://github.com/helium/gateway-rs/releases) - ending in -`-raspi234.deb` - -## Configure the Raspberry Pi - -1. Use the Raspberry Pi Configuration application and enable the SPI kernel module in the Interface - Options section. This is located in the GUI from the Applications Menu under Preferences -2. Reboot to apply the changes - -If you haven't done so, attach the Dragino PG1301 to the Raspberry Pi with the power off, attach the -antenna, then power on. - -## Install the LoRa Packet Forwarder Service - -1. Open the web browser and download `lorapktfwd_v1.1.deb` from the - [Dragino Downloads Site](https://www.dragino.com/downloads/index.php?dir=LoRa_Gateway/PG1301/software/) -2. Open a terminal window and install the package using dpkg - ``` - sudo dpkg -i lorapktfwd_v1.1.deb - ``` -3. Verify lorapktfwd is running using systemctl - ``` - sudo systemctl status lorapktfwd - ``` - -Example: - -``` -pi@raspberrypi:~ $ cd Downloads -pi@raspberrypi:~/Downloads $ sudo dpkg -i lorapktfwd_v1.1.deb -Selecting previously unselected package lorapktfwd. -(Reading database ... 98868 files and directories currently installed.) -Preparing to unpack lorapktfwd_v1.1.deb ... -Unpacking lorapktfwd (1) ... -Setting up lorapktfwd (1) ... -Created symlink /etc/systemd/system/multi-user.target.wants/lorapktfwd.service → /lib/systemd/system/lorapktfwd.service. -pi@raspberrypi:~/Downloads $ -pi@raspberrypi:~/Downloads $ sudo systemctl status lorapktfwd - lorapktfwd.service - packet forwarder - Loaded: loaded (/lib/systemd/system/lorapktfwd.service; enabled; vendor preset: enabled) - Active: active (running) since Wed 2021-10-06 10:58:26 EDT; 5min ago - Main PID: 1443 (lora_pkt_fwd) - Tasks: 5 (limit: 4915) - CGroup: /system.slice/lorapktfwd.service - └─1443 /usr/bin/lora_pkt_fwd - -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ ### [DOWNSTREAM] ### -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # PULL_DATA sent: 3 (0.00% acknowledged) -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # PULL_RESP(onse) datagrams received: 0 (0 bytes) -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # RF packets sent to concentrator: 0 (0 bytes) -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # TX errors: 0 -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # BEACON queued: 0 -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # BEACON sent so far: 0 -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # BEACON rejected: 0 -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ ### [PPS] ### -Oct 06 11:03:29 raspberrypi lora_pkt_fwd[1443]: REPORT~ # SX1301 time (PPS): 302479992 -pi@raspberrypi:~/Downloads $ -``` - -## Install the Helium Gateway Service - -1. Download the latest helium-gateway release package from - https://github.com/helium/gateway-rs/releases ending in -raspi234.deb -2. Install the package - ``` - sudo dpkg -i helium-gateway-v1.0.0-alpha.18-raspi234.deb - ``` - Replace helium-gateway-v1.0.0-alpha.18-raspi234.deb with the version you downloaded. -3. Verify the gateway is running - ``` - sudo systemctl status helium_gateway - ``` - -Example: - -``` -pi@raspberrypi:~/Downloads $ sudo dpkg -i helium-gateway-v1.0.0-alpha.18-raspi234.deb -Selecting previously unselected package helium_gateway. -(Reading database ... 98957 files and directories currently installed.) -Preparing to unpack helium-gateway-v1.0.0-alpha.18-raspi234.deb ... -Unpacking helium_gateway (1.0.0~alpha.18) ... -Setting up helium_gateway (1.0.0~alpha.18) ... -Created symlink /etc/systemd/system/multi-user.target.wants/helium_gateway.service → /lib/systemd/system/helium_gateway.service. -pi@raspberrypi:~/Downloads $ -pi@raspberrypi:~/Downloads $ sudo systemctl status helium_gateway - helium_gateway.service - Helium Gateway - Loaded: loaded (/lib/systemd/system/helium_gateway.service; enabled; vendor preset: enabled) - Active: active (running) since Wed 2021-10-06 11:51:03 EDT; 35s ago - Main PID: 2121 (helium_gateway) - Tasks: 2 (limit: 4915) - CGroup: /system.slice/helium_gateway.service - └─2121 /usr/bin/helium_gateway -c /etc/helium_gateway server - -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: updated routing to height 1042530, module: dispatcher -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 13, uri: http://46.246.38.248:8080/, public_key: 115ZS5of9wsV3M5sH3mePp9NVnKayUXG7qT2W7Sn4KJLMzd3eMr, module: router -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 12, uri: http://54.219.236.122:8080/, public_key: 112ewJNEUfSg3Jvo276tMjzFC2JzmmZcJJ32CWz2fzYqbyCMMTe1, module: rout -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 9, uri: http://13.37.13.24:8080/, public_key: 11afuQSrmk52mgxLu91AdtDXbJ9wmqWBUxC3hvjejoXkxEZfPvY, module: router -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 9, uri: http://44.238.156.97:8080/, public_key: 11w77YQLhgUt8HUJrMtntGGr97RyXmot1ofs5Ct2ELTmbFoYsQa, module: router -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 6, uri: http://185.34.141.6:8080/, public_key: 11awcuSbVURPkXX3FbKC7KF6bgEPRZqqPzv1FTEYABMLttUr13E, module: router -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 4, uri: http://54.193.165.228:8080/, public_key: 11263KvqW3GZPAvag5sQYtBJSjb25azSTSwoi5Tza9kboaLRxcsv, module: route -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 2, uri: http://54.176.88.149:8080/, public_key: 1124CJ9yJaHq4D6ugyPCDnSBzQik61C1BqD9VMh1vsUmjwt16HNB, module: router -Oct 06 11:51:03 raspberrypi helium_gateway[2121]: starting, oui: 1, uri: http://52.8.80.146:8080/, public_key: 112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE, module: router -Oct 06 11:51:04 raspberrypi helium_gateway[2121]: no update found, module: updater -pi@raspberrypi:~/Downloads $ -``` - -## Configure the LoRa Packet Forwarder - -These steps assume the US915 region. For other regions, replace with your region locale -configuration in Step 2. - -1. Change directory to the `/etc/lora-gateway` directory - ``` - cd /etc/lora-gateway - ``` -2. Copy the US915 Band 2 configuration from the `cfg` subdirectory as global_conf.json - ``` - cp cfg/dragino/global_conf.us915_1.json global_conf.json - ``` -3. Generate a unique gateway ID based on the MAC address of one of your network interface(s). Use - the following bash syntax to help create one. - ``` - echo `ip a | grep 'link/ether' | cut -d ' ' -f 6 | sed 's/://g'` | tr a-z A-Z - ``` - This command will generate you one or more unique values you can use for the gateway EUI. - -In the below example, you see two values (DCA6328XXX6F and DCA6328XXX70) because there is an active -wired and wireless interface on the Raspberry Pi. It doesn't matter which one you use, as all MAC -addresses are globally unique. - -The goal here is to guarantee a unique gateway ID in the network. - -``` -pi@raspberrypi:~/Downloads $ cd /etc/lora-gateway/ -pi@raspberrypi:/etc/lora-gateway $ cp cfg/dragino/global_conf.us915_1.json global_conf.json -pi@raspberrypi:/etc/lora-gateway $ echo `ip a | grep 'link/ether' | cut -d ' ' -f 6 | sed 's/://g'` | tr a-z A-Z -DCA6328XXX6F DCA6328XXX70 -pi@raspberrypi:/etc/lora-gateway $ -``` - -In the next step we will be using the `DCA6328XXX70` value as an example. Do not use the example -value from this documentation, it will not work. - -### Point the LoRa Packet Forwarder to the Helium Gateway - -By default the LoRa Packet Forwarder from Dragino is configured to work with the Things Network. -Here we will configure it to talk to the Helium gateway you installed on the Raspberry Pi. - -1. Use a text editor and open the `/etc/lora-gateway/local_conf.json` file -2. Replace the current value for gateway_ID with (one of) the values generated in the previous step - and **append the value FFFF to the end**. The reason we append `FFFF` to the end is the gateway - ID is required to be 16 characters, and the unique MAC address generated is only 12. Again, this - guarantees your gateway ID will be unique in the network. -3. Add the `server_address` key with the value `127.0.0.1` -4. Add the `serv_port_up` key with the value `1680` -5. Add the `serv_port_down` key with the value `1680` - -You should have something that resembles the following in your /etc/lora-gateway/local_conf.json -file. Be sure to double check the JSON syntax and have the key/values separated by commas and the {} -characters match up. - -``` - { - "gateway_conf": { - "gateway_ID": "DCA6328XXX70FFFF", - "server_address": "127.0.0.1", - "serv_port_up": 1680, - "serv_port_down": 1680 - } - } -``` - -For reference, the server address being used is the local machine (127.0.0.1, also called localhost) -and port 1680 is the port the helium service is communicating on. **Don't** use the value assigned -by your router or the public IP address. - -When you are finished make sure to save and exit the file. - -### Configure the Helium Gateway Region - -The default region of the _helium_gateway_ service is US915, so you can continue with the next -section if you are using this one. Otherwise, you must set your region frequency in -`/etc/helium_gateway/settings.toml`. Add the following line at the beginning of the file: - -``` -region = "" -``` - -Possible values are: - -``` -US915 | EU868 | EU433 | CN470 | CN779 | AU915 | AS923_1 | AS923_2 | AS923_3 | AS923_4 | KR920 | IN865 -``` - -For instance, if your region is EU868 the content in `settings.toml` must be. - -``` -region = "EU868" - -[log] -method = "syslog" -level = "info" -timestamp = false - -[update] -platform = "raspi234" -``` - -## Activate The Changes - -Now, reboot the Raspberry Pi to restart the services and verify that everything starts at boot time -and is working. - -## Post-Reboot Checks - -- You can view the log file of the LoRa Packet Forwarder by opening a terminal window and running - ``` - journalctl -u lorapktfwd - ``` -- You can view the log file of the Helium Gateway by opening another terminal window and running - ``` - journalctl -u helium_gateway - ``` - -Use the spacebar to scroll thru the logs, and Ctrl-C to get back to the command prompt. - -Congradulations, your LoRa Packet Forwarder and Helium Gateway service is setup! At this point your -LoRa radio will be able to pass radio traffic between the network and the Helium gateway. Any -devices you registered via the Helium console should now be live. Your hotspot will not appear on -the map. Before adding your hotspot to the blockchain, please check and backup your configuration. - -## Check and Backup your Configuration - -1. To view your gateway address and unique animal name assigned to you - ``` - helium_gateway key info - ``` - Example: - ``` - $ helium_gateway key info - { - "address": "13XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", - "name": "unique-animal-name" - } - ``` -2. Backup your gateway key to another machine/media for recovery purposes. The file - `/etc/helium_gateway/gateway_key.bin` contains the key. - -:::warning - -If you lose this key, you will not be able to use this hotspot anymore in case there is a problem on -your hostpot (SD card corrupted, etc). You will need to generate a new key and lose your existing -animal name/hostpot configuration - -::: - -## Testing the packet transfer with an end device - -If you have an end device (LoRaWAN node), you can check if the hotspot can transfer packets through -the network. In other words, you can check if the devices can send data to the Helium Console. The -Helium Console is where you can provision and manage the end devices, so the nodes need to be -registered to start using the network. - -### Some comments and recommendations about the Helium Console - -At least for now, it is recommended to use the staging console instead of the production one when we -are transferring data through Data Only hotspots. You can differentiate them for the URL they use, -[console.helium.com](https://console.helium.com/) for production, and -[staging-console.helium.wtf](https://staging-console.helium.wtf) for staging. Don't be surprised if -you find some differences between those console flavors, basically staging is where the new features -are tested before their rollout to production. - -:::important - -If the device you will use for testing is registered on the production console, it's better to -delete it from there to avoid any unexpected behavior. - -::: - -To register your end device on the console, you can follow the steps described on -[Adding Devices](/use-the-network/console/adding-devices/). - -## What's next? - -At this point, after you verified your Data Only Hotspot is working, it is ready to be added to the -blockchain! You can find more information about that process -[here](/hotspot-makers/iot/data-only-hotspots#pre-requisites). diff --git a/docs/hotspot-makers/iot/data-only/dragino.mdx b/docs/hotspot-makers/iot/data-only/dragino.mdx deleted file mode 100644 index 1d1601ea8..000000000 --- a/docs/hotspot-makers/iot/data-only/dragino.mdx +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: dragino -title: Dragino Data Only Hotspot Setup -pagination_label: DDragino LPS80/DLOS8 -sidebar_label: Dragino LPS80/DLOS8 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/data-only/dragino ---- - -# Dragino LoRaWAN Gateway Setup - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This guide provides instructions on how to configure an 8-channel Dragino LoRaWAN gateway such as -the LPS8 or DLOS8 to work with the Helium network. - -:::warning - -Dragino Hotspots will only mine HNT through packet transfer, and is considered a Data Only Hotspot. -The ability to mine HNT with anything other than [Approved Hotspots](https://helium.com/mine) is not -currently supported. Please join the -[#gateway-development](discord://discord.com/channels/404106811252408320/784462269072277576) channel -in the Helium Discord Server for the latest updates. - -::: - -### Video Guide for Setup - -[![Link to YouTube tutorial explaining packet forwarder setup.](https://img.youtube.com/vi/OuujPVK8f3U/0.jpg)](https://www.youtube.com/watch?v=OuujPVK8f3U) - -## Prerequisites - -Prior to configuring your Dragino to work with the Helium network, please confirm that it is -connected to the Internet and updated to the latest firmware. Refer to the user guide provided on -the [Dragino download site](http://www.dragino.com/downloads/index.php?dir=LoRa_Gateway/) for more -detailed instructions. - -- Connect to a Wi-Fi or Ethernet network with Internet access. -- Update to the latest firmware from - [Dragino](http://www.dragino.com/downloads/index.php?dir=LoRa_Gateway/). As recommended by - Dragino, leave "Preserve Settings" _unchecked_ when upgrading firmware to avoid issues caused by - incompatibility of settings between versions. This guide assumes the standard firmware version - v5.4.1618196981 or later. Earlier firmware versions may require ca-bundle to be installed prior to - gateway-rs (via SSH: `opkg update` and `opkg install ca-bundle`). Note, the OpenVPN firmware may - be used however port numbers may differ from what's included here. -- Change the root password from the default of 'dragino', if desired. - -## Configure LoRa Frequency Plan - -To be able to send and receive LoRa data, your gateway must be configured to the frequencies -specified for your region. You may be able to use the predefined frequency in the Dragino or some -cases may need to manually set them per the frequencies used by Helium in your region. - -1. Log into the Dragino gateway web interface. In the standard Dragino firmware connect via your - browser at `http://:8000` once the Dragino is connected to your network. -2. Navigate to Lora > Lora from the Menu. -3. Under Radio Settings, select your region in the Frequency Plan drop down and, if applicable, the - Frequency Sub Band. For example, in the US, select US915 for the frequency plan and 2 for the sub - band. -4. If desired, set Static GPS coordinates. -5. Click Save & Apply. - -For some regions, it my be necessary to manually populate Populate the Customized Channel Settings -based on the Helium frequencies for your region. Refer to the -[Helium sample LoRa packet forwarder global.conf files](https://github.com/helium/sx1302_hal/tree/helium/hotspot/packet_forwarder) -for your region as a guide to the values to use. You can check the values used by the pre-defined -frequency plans by viewing the global_conf.json file: `cat /etc/lora/global_conf.json` - -_Example of customized channel settings using the US915 frequency plan for Helium_ - - - -## Configure LoRaWAN Settings - -Next, you will configure the LoRa packet forwarder on the Dragino to forward packets to the Helium -Gateway service which will be installed on the Dragino in the next step. - -1. From the Dragino web interface, navigate to LoRaWAN > LoRaWAN from the menu. -2. Select `Custom / Private LoRaWAN` from the Service Provider. -3. Set the Server Address to `127.0.0.1` and both Uplink and Downlink ports to `1680`. This will - configure the forwarder to use the default port used by Helium Gateway. - - - -4. Click Save & Apply. - -## Install Helium Gateway (gateway-rs) on the Dragino - -Finally, you will install the Helium Gateway service. This requires SSH access to the Dragino. - -1. Connect to the Dragino over SSH. By default, the standard Dragino firmware uses port 2222 for SSH - (the OpenVPN firmware uses port 22) and the root user has access. `ssh root@ -p 2222` -2. Copy the Helium Gateway package to the Dragino. The latest - [source code](https://github.com/helium/gateway-rs) and pre-built - [releases](https://github.com/helium/gateway-rs/releases) are available on GitHub. Option 1: - Download from GitHub: On the Dragino run `cd /tmp` and - `wget -O helium-gateway--dragino.ipk https://github.com/helium/gateway-rs/releases/download//helium-gateway--dragino.ipk`. - Option 2: Copy from another computer: Run this command from on the computer within the directory - containing the package `scp helium-gateway--dragino.ipk :/tmp/`. -3. Install the Helium Gateway package `opkg install /tmp/helium-gateway--dragino.ipk`. -4. Backup your key file `/etc/helium_gateway/gateway_key.bin` and keep in a safe place. This will be - needed to recover this gateway especially if it is onboarded to the blockchain. - -Helium Gateway is now installed and should be running. Use the command `helium_gateway key info` to -view the public key address and animal name of your gateway. - -## Verify - -Your Dragino gateway should now be setup and forwarding LoRaWAN data traffic to the Helium Network. - -### Through Helium Console - -If you have a LoRaWAN device configured through the Helium Console, you should now see it uplinking -traffic through the Dragino gateway. You can verify this by turning on your device within range of -the Dragino and looking for traffic in Console associated to the Dragino gateway's animal name. - -Note, during the alpha period, the helium gateway service by default routes data traffic to the -[Staging Router/Console](https://staging-console.helium.wtf/). - -### Through the System Logs - -Use the Dragino system log to verify that Helium Gateway has started. You can view the log in the -web interface or by using logread on the commandline interface (e.g, -`logread | grep helium_gateway`). In the logs, you should see messages indicating helium_gateway is -starting. If you do not see these, try restarting the service (`/etc/init.d/helium_gateway restart`) -or reboot the Dragino as the messages may have rotated out of the log. - -_Example logs showing the Helium Gateway service starting_ - -``` -Thu Mar 25 19:43:06 2021 daemon.err helium_gateway[2031]: Mar 25 19:43:06.184 INFO starting server, key: , version: 1.0.0-alpha.4 -Thu Mar 25 19:43:06 2021 daemon.err helium_gateway[2031]: Mar 25 19:43:06.289 INFO starting, module: gateway -Thu Mar 25 19:43:06 2021 daemon.err helium_gateway[2031]: Mar 25 19:43:06.306 INFO starting, module: router -``` - -Additionally, the LoRa Packet Forwarder log can provide some clues as to whether the LoRaWAN server -configuration is correct. Search the system log for PULL_DATA messages and confirm that they are -acknowledged such as `REPORT~ # PULL_DATA sent: 1 (100.00% acknowledged)`. This indicates that the -packet forwarder is communicating with the Helium Gateway service running on the Dragino and is -getting replies from the service as expected. Note, this is not a foolproof way to confirm it is -configured correctly. By default, the LoRaWAN Server settings are configured for the TTN EU server -which will also provide acknowledgment. However, the absence of acknowledgment could indicate the -the LoRaWAN settings are not correct per the above. - -## Onboard as Data-Only Hotspot - -As part of the Light Hotspot project, a new class of Hotspots called "Data-Only Hotspots" can be -added to the blockchain, meaning Dragino LPS80/DLOS8 Hotspots can be added to the Network. These -Hotspots can mine HNT for transferring data but never for Proof-of-Coverage. See -[Light Hotspots](/hotspot-makers/iot/light-hotspots) for more information. This process will require -using the Helium [command-line interface (CLI) Wallet](https://github.com/helium/helium-wallet-rs) -to submit the onboarding and assert location transactions. diff --git a/docs/hotspot-makers/iot/data-only/kerlink.mdx b/docs/hotspot-makers/iot/data-only/kerlink.mdx deleted file mode 100644 index 328ddbc9e..000000000 --- a/docs/hotspot-makers/iot/data-only/kerlink.mdx +++ /dev/null @@ -1,270 +0,0 @@ ---- -id: kerlink -title: Kerlink Data Only Hotspot Setup -pagination_label: Kerlink iStation, iFemtoCell, iFemtoCell Evolution -sidebar_label: Kerlink iStation, iFemtoCell, iFemtoCell Evolution -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/data-only/kerlink ---- - -# Kerlink gateways - -import useBaseUrl from '@docusaurus/useBaseUrl' - -All Kerlink gateways share the same operating system, called KerOS. It is based on Linux and uses -OPKG, however not directly. - -:::warning - -Kerlink Gateways will only mine HNT through packet transfer, and is considered a Data Only Hotspot -unless you purchase a Kerlink Miner specificlly designed for the Helium Network. The ability to mine -HNT with anything other than [Approved Hotspots](https://helium.com/mine) is not currently -supported. Please join the -[#gateway-development](discord://discord.com/channels/404106811252408320/784462269072277576) channel -in the Helium Discord Server for the latest updates. - -::: - -## Logging in - -Use SSH. Your username is `root` and the default password is `pdmk-XXXXXX` where the X's should be -replaced with the last 6 digits of the gateway Board ID or the EUI (see labels on the gateway). - -Once logged in, please change your password. - -## Check KerOS version - -We recommend to use the latest KerOS version, which is at the time of writing 4.3.3: - -``` -root@klk-wiis-050029:~ # opkg list -keros - 4.3.3-0-g993efce1 -``` - -## Installing an IPK - -To install an IPK package, place it in `/user/.updates` and execute: - -``` -sync -kerosd -u -reboot -``` - -Example: upload from your computer - -``` -user@computer:~ $ scp file.ipk root@gateway-ip:/user/.updates/ -``` - -or directly from the gateway: - -``` -root@klk-wiis-050029:~ # wget https://github.com/helium/gateway-rs/releases/download/v1.0.0-alpha.8/helium-gateway-v1.0.0-alpha.8-klkgw.ipk -Connecting to github.com (192.30.255.112:443) -Connecting to github-releases.githubusercontent.com (185.199.110.154:443) -helium-gateway-v1.0. 100% |*************************************************************************************************************| 1032k 0:00:00 ETA -root@klk-wiis-050029:~ # mv helium-gateway-v1.0.0-alpha.8-klkgw.ipk /user/.updates -root@klk-wiis-050029:~ # sync; kerosd -u; reboot; exit - -The system is going down for reboot NOW!029 (pts/0) (Tue Apr 20 17:49:37 2021) -``` - -This is used because KerOS uses a backup mechanism when installing packages. As soon as you install -an IPK, a backup snapshot is made. You can then - -- restore to stock firmware: `kerosd -s` -- restore to the latest backup: `kerosd -b` -- trigger an update from `/user/.updates`: `kerosd -u` - -## Check installation - -You need the latest KerOS version (see above) and the appropriate light miner software installed: - -``` -root@klk-wiis-050029:~ # opkg list -helium_gateway - 1.0.0-alpha.8 -keros - 4.3.3-0-g993efce1 -``` - -## Configure LoRa Frequency Plan - -Use the built-in tool `klk_apps_config` to activate the Kerlink Packet Forwarder (CPF) on the -appropriate region: - -``` -# this is multiline just for readability -root@klk-wiis-050029:~ # klk_apps_config --activate-cpf \ - --lns-server 127.0.0.1 \ - --lns-dport 1680 --lns-uport 1680 \ - --loradconf US915-US.json -Stopping lorad 1.3.0 -Stopping lorafwd 1.2.0 -Starting lorad 1.3.0 -Starting lorafwd 1.2.0 -lorafwd[1447]: <6> Parsing configuration file: /var/run/lora/gateway-id.toml -lorafwd[1447]: <6> Parsing configuration file: /etc/lorafwd.toml -root@klk-wiis-050029:~ # -``` - -The list of available preconfigured regions are in `/etc/lorad/XXX` where XXX is the gateway model -nickname: - -- iFemtoCell: `wifc` -- iFemtoCell Evolution: `fevo` -- iStation: `wiis` - -``` -root@klk-wiis-050029:~ # ll /etc/lorad/wiis/ -drwxr-xr-x 2 root root 220 Aug 3 2020 . -drwxr-xr-x 1 root root 4.0K Apr 20 17:55 .. --rw-r--r-- 1 root root 2.4K Aug 3 2020 AS923-JP.json --rw-r--r-- 1 root root 2.0K Aug 3 2020 AS923-TH-SG-HK-TW.json --rw-r--r-- 1 root root 1.9K Aug 3 2020 AU915-AU.json --rw-r--r-- 1 root root 2.0K Aug 3 2020 EU868-FR.json --rw-r--r-- 1 root root 1.8K Aug 3 2020 IN865-IN.json --rw-r--r-- 1 root root 2.3K Aug 3 2020 KR920-KR.json --rw-r--r-- 1 root root 1.9K Aug 3 2020 RU864-RU.json --rw-r--r-- 1 root root 1.9K Aug 3 2020 RU864-RU_Legacy.json --rw-r--r-- 1 root root 1.9K Aug 3 2020 US915-US.json -``` - -If the desired configuration file is not available, feel free to create a new one and restart the -tool. - -## US915/AU915 - -Kerlink uses the first sub-band in these regions by default. To use the appropriate sub-band -(second), use this command: - -``` -source /etc/default/lorad -# US915 -sed -i s/902700000/904300000/ $CONFIGURATION_FILE -sed -i s/903400000/905000000/ $CONFIGURATION_FILE -# AU915 -sed -i s/915600000/917200000/ $CONFIGURATION_FILE -sed -i s/916300000/917900000/ $CONFIGURATION_FILE -# all regions: -monit restart lorad -``` - -## TX frequencies - -By default, Kerlink restricts the TX frequencies (downlinks) to what LoRaWAN defines. Helium Proofs -of Coverage use the uplink bands for the transmission of the challenge RF packet. - -This is only required in US915 and AU915: - -``` -# US915 -sed -i s/923300000/902300000/ ${CONFIGURATION_FILE} -# AU915 -sed -i s/923300000/915200000/ ${CONFIGURATION_FILE} -# all regions: -monit restart lorad -``` - -# Troubleshooting - -LoRa logs are available in `/var/log/lora.log`: - -## Radio configuration - -Restart the lora daemon and see if it loads the appropriate channels: - -``` -# note: timestamps removed for readability -root@klk-wiis-050029:~ # tail -f /var/log/lora.log & -[1] 2041 -root@klk-wiis-050029:~ # monit restart lorad -lorad[1414]: <5> Stopping lorad -lorad[1414]: <3> TTY PORT FAIL TO CLOSE -lorad[1414]: <4> Failed to close GPS device -lorad[1414]: <3> CONCENTRATOR UNCONNECTED -lorad[1414]: <4> concentrator was already disconnected -lorafwd[1449]: <6> Heartbeat (3E33) sent -lorafwd[1449]: <6> Heartbeat (3E33) acknowledged in 1.00509 ms -lorad[2011]: <5> Starting lorad 1.3.0 -lorad[2011]: <6> Programming FPGA with spectral scan firmware -lorad[2011]: <6> Using PPS device /sys/class/pps/pps1 -lorad[2011]: <6> Parsing configuration file: /etc/lorad/lorad.json -lorad[2011]: <6> Initialize JIT queue (nb_pkt=64, size=19716) -lorad[2011]: <6> Using board: lorawan_public=true -lorad[2011]: <6> Using lbt: enable=false -lorad[2011]: <6> Using txgain: lut=0 dig_gain=3 dac_gain=3 mix_gain=9 pa_gain=1 rf_power=-2 -lorad[2011]: <6> Using txgain: lut=1 dig_gain=3 dac_gain=3 mix_gain=11 pa_gain=1 rf_power=2 -lorad[2011]: <6> Using txgain: lut=2 dig_gain=3 dac_gain=3 mix_gain=12 pa_gain=1 rf_power=4 -lorad[2011]: <6> Using txgain: lut=3 dig_gain=3 dac_gain=3 mix_gain=14 pa_gain=1 rf_power=7 -lorad[2011]: <6> Using txgain: lut=4 dig_gain=3 dac_gain=3 mix_gain=10 pa_gain=2 rf_power=8 -lorad[2011]: <6> Using txgain: lut=5 dig_gain=3 dac_gain=3 mix_gain=11 pa_gain=2 rf_power=10 -lorad[2011]: <6> Using txgain: lut=6 dig_gain=3 dac_gain=3 mix_gain=12 pa_gain=2 rf_power=12 -lorad[2011]: <6> Using txgain: lut=7 dig_gain=3 dac_gain=3 mix_gain=13 pa_gain=2 rf_power=14 -lorad[2011]: <6> Using txgain: lut=8 dig_gain=3 dac_gain=3 mix_gain=14 pa_gain=2 rf_power=15 -lorad[2011]: <6> Using txgain: lut=9 dig_gain=3 dac_gain=3 mix_gain=9 pa_gain=3 rf_power=17 -lorad[2011]: <6> Using txgain: lut=10 dig_gain=3 dac_gain=3 mix_gain=10 pa_gain=3 rf_power=19 -lorad[2011]: <6> Using txgain: lut=11 dig_gain=3 dac_gain=3 mix_gain=11 pa_gain=3 rf_power=21 -lorad[2011]: <6> Using txgain: lut=12 dig_gain=3 dac_gain=3 mix_gain=12 pa_gain=3 rf_power=23 -lorad[2011]: <6> Using txgain: lut=13 dig_gain=3 dac_gain=3 mix_gain=13 pa_gain=3 rf_power=25 -lorad[2011]: <6> Using txgain: lut=14 dig_gain=3 dac_gain=3 mix_gain=14 pa_gain=3 rf_power=26 -lorad[2011]: <6> Using txgain: lut=15 dig_gain=3 dac_gain=3 mix_gain=15 pa_gain=3 rf_power=27 -lorad[2011]: <6> Using rxrf: chain=0 enable=true freq_hz=904300000 rssi_offset=-169.5 type=SX1257 tx_enable=true tx_notch_freq=129000 -lorad[2011]: <6> Using rxrf: chain=1 enable=true freq_hz=905000000 rssi_offset=-168.7 type=SX1257 tx_enable=false -lorad[2011]: <6> Using rxif: channel=0 enable=true type=MULTI rf_chain=0 freq_hz=903900000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=1 enable=true type=MULTI rf_chain=0 freq_hz=904100000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=2 enable=true type=MULTI rf_chain=0 freq_hz=904300000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=3 enable=true type=MULTI rf_chain=0 freq_hz=904500000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=4 enable=true type=MULTI rf_chain=1 freq_hz=904700000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=5 enable=true type=MULTI rf_chain=1 freq_hz=904900000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=6 enable=true type=MULTI rf_chain=1 freq_hz=905100000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=7 enable=true type=MULTI rf_chain=1 freq_hz=905300000 bw=125000 sf=7-12 -lorad[2011]: <6> Using rxif: channel=8 enable=true type=STD rf_chain=0 freq_hz=904600000 bw=500000 sf=8 -lorad[2011]: <6> Using rxif: channel=9 enable=false -lorad[2011]: <6> Using beacon: enable=false -lorad[2011]: <6> Using api: uplink="ipc:///var/run/lora/uplink" -lorad[2011]: <6> Using api: downlink="ipc:///var/run/lora/downlink" -lorad[2011]: <6> Using api: control="ipc:///var/run/lora/lorad" -lorad[2011]: <6> Programming FPGA with spectral scan firmware -lorad[2011]: <5> detected FPGA with SPI mux header (v31) -lorad[2011]: <6> FPGA supported features: [TX filter] [Spectral Scan] -lorad[2011]: <6> sx1272 version: 0x22, initial mode:0x1 -lorad[2011]: <6> TAI offset has been set to 37 -lorad[2011]: <6> Setting mode standby OK -lorad[2011]: <6> Selected single side bandwidth: 100000 -lorad[2011]: <6> PPS is enabled -lorad[2011]: <6> Setting mode RX OK -lorafwd[1449]: <6> Received uplink message: system event "Started" -``` - -We can see it loaded channels 903.9MHz, 904.1MHz, etc: this is the appropriate frequency sub-band -for US915. - -## LoRa traffic - -``` -# note: timestamps removed for readability -root@klk-wiis-050029:~ # tail -f /var/log/lora.log -lorad[20071]: <6> Received downlink message -lorad[20071]: <6> Sent downlink message -lorafwd[6973]: <6> Received uplink message: transmission event (000093C7 / 00000000), status "Transmitted" -lorafwd[6973]: <6> Downlink message (93C7) acknowledged -lorafwd[6973]: <6> Heartbeat (B0A6) sent -lorafwd[6973]: <6> Heartbeat (B0A6) acknowledged in 1.4919 ms -lorafwd[6973]: <6> Received uplink message: -lorafwd[6973]: <6> | lora uplink (6D700004), payload 23 B, channel 903.3 MHz, crc ok, bw 125 kHz, sf 10, cr 4/5 -lorafwd[6973]: <6> | Join Request, JoinEUI 0000000000000000, DevEUI 7076FF006A03004E, DevNonce 41214 -lorafwd[6973]: <6> | - radio (00000005) -lorafwd[6973]: <6> | - demodulator counter 21645692, TAI time 2021-04-20T18:36:02.146512Z, rssi -65 dB, snr 15 dB -lorafwd[6973]: <6> | - localization encrypted 7DB2593A662F37578CA8C7439523E199, rssi -65 dB, frequency offset 2295 Hz, version 1 -lorafwd[6973]: <6> Uplink message (43A6) sent -lorad[20071]: <6> Sent 1 uplink message -lorafwd[6973]: <6> Uplink message (43A6) acknowledged in 1.0356 ms -``` - -Here we can confirm: - -- that the packet forwarder communicates well with the Helium light gateway because all the - heartbeats / uplinks are acknowledged in a millisecond -- that the radio is well configured because it received an uplink message (Join Request) at - 903.3MHz, -65dBm RSSI and 15dB SNR (device was close) diff --git a/docs/hotspot-makers/iot/data-only/rak-concentrators.mdx b/docs/hotspot-makers/iot/data-only/rak-concentrators.mdx deleted file mode 100644 index 2c450edf1..000000000 --- a/docs/hotspot-makers/iot/data-only/rak-concentrators.mdx +++ /dev/null @@ -1,384 +0,0 @@ ---- -id: rak-concentrators -title: Data Only Hotspot Setup with RAK Concentrator + Raspberry Pi -pagination_label: RAK Concentrators (RAK2245/RAK2247/RAK2287) + Raspberry Pi -sidebar_label: RAK Concentrators (RAK2245/RAK2247/RAK2287) + Raspberry Pi -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/data-only/rak-concentrators ---- - -# Data Only Hotspot Setup with RAK Concentrator + Raspberry Pi - -import useBaseUrl from '@docusaurus/useBaseUrl' - -A Data Only Hotspot is a variation of Hotspots that can participate on the Helium Network by -transferring data from the end devices (LoRaWAN nodes), they are eligible for Network Data Transfer -Rewards but not Proof of Coverage Rewards. - -This guide covers all the steps needed to set up a Data Only Hotspot using a WisLink RAK LPWAN -concentrator module and a Raspberry Pi, you will find more details about which models/references are -supported in the requirements section. This configuration can be achieved by installing the -**_helium_gateway_** service available on the [gateway-rs](https://github.com/helium/gateway-rs) -repository. - -:::warning - -Data Only Hotspots cannot earn $HNT, at least for now, and after milestone 2 they will earn $HNT -only for Device Packet Transfer. Remember to keep an eye on -[Light Hotspots - BETA](/hotspot-makers/iot/light-hotspots) and the -**[#gateway-development](discord://discord.com/channels/404106811252408320/784462269072277576)** -channel on the [Helium Discord Server](https://discord.gg/helium) to check how the development -process evolves. - -::: - -### Video Guide for Setup - -This Hands on with RAKstars session follows the step-by-step provided across this guide. - -[![Link to YouTube tutorial explaining packet forwarder setup.](https://img.youtube.com/vi/Eyt4bbW_9yw/0.jpg)](https://www.youtube.com/watch?v=Eyt4bbW_9yw&t=2024s) - -## Requirements - -- Raspberry Pi, multiple families are supported, however not all the models have been tested yet, so - it's highly recommended to follow this guide with a model of the families Pi 3 or Pi 4. - -- The concentrator module and the proper Pi HAT to interface it with the Raspberry Pi. The following - table contains the links to the detailed information available at the RAK store. - -| WisLink LPWAN Concentrator | Raspberry Pi HAT | -| -------------------------- | :--------------------------------------------------------------: | -| [RAK2287] | [RAK2287 Pi HAT] | -| [RAK2247] | [RAK2247 Pi HAT] | -| [RAK2245] | The linked reference is a Raspberry Pi
form factor module! | - -[rak2287]: - https://store.rakwireless.com/collections/wislink-lpwan/products/rak2287-lpwan-gateway-concentrator-module -[rak2247]: - https://store.rakwireless.com/collections/wislink-lpwan/products/rak2247-lpwan-gateway-concentrator-module -[rak2245]: https://store.rakwireless.com/collections/wislink-lpwan/products/rak2245-pi-hat -[rak2287 pi hat]: https://store.rakwireless.com/products/rak2287-pi-hat -[rak2247 pi hat]: https://store.rakwireless.com/products/rak2247-pi-hat - -:::important - -To use the concentrator module with a Raspberry Pi HAT, you must make sure to order the variation -with the SPI interface. - -::: - -Let's get started! - -## Packet forwarder preparation - -To get started you must set up the packet forwarder and get some helpful configuration tools used -across this guide. - -#### Option 1 - -You can follow this -[installation procedure](https://github.com/RAKWireless/rak_common_for_gateway#installation-procedure) -if you are already familiar with the Raspberry Pi, and the RAK concentrator modules. Furthermore, -it's highly recommended to start from a fresh -[Raspbian Buster Lite image](https://www.raspberrypi.org/software/operating-systems/) (now -called'Raspberry Pi OS Lite'). - -#### Option 2 - -You can also follow the Quick Start Guide for your concentrator on the -[RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisLink/#wislink-lpwan). - -- [RAK2287] -- [RAK2247] -- [RAK2245] - -[rak2287]: https://docs.rakwireless.com/Product-Categories/WisLink/RAK2287/Quickstart/ -[rak2247]: https://docs.rakwireless.com/Product-Categories/WisLink/RAK2247/Quickstart/ -[rak2245]: https://docs.rakwireless.com/Product-Categories/WisLink/RAK2245-Pi-HAT/Quickstart/ - -### Select the region plan - -Enter the gateway configuration interface by using the following command. - -``` -sudo gateway-config -``` - -Select the _Setup RAK Gateway Channel Plan_ option, then _Server is TTN_, and in the last step -choose the proper plan according to your country. For instance, the image shows the option to select -US915. To finish, press OK. - - - -### Verify if the packet forwarder is running - -When the LoRa packet forwarder is running as a service, some log messages are recorded in the -syslog. To inspect the logs, run the following command: - -``` -sudo tail -f /var/log/syslog | grep ttn-gateway -``` - -The log output should show something similar to: - -``` -rak-gateway ttn-gateway[1886]: JSON up: {"stat":{"time":"2021-07-21 16:25:00 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"temp":0.0}} -rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms -rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms -rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms -rak-gateway ttn-gateway[1886]: ##### 2021-07-21 16:25:30 GMT ##### -rak-gateway ttn-gateway[1886]: ### [UPSTREAM] ### -rak-gateway ttn-gateway[1886]: # RF packets received by concentrator: 0 -rak-gateway ttn-gateway[1886]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% -rak-gateway ttn-gateway[1886]: # RF packets forwarded: 0 (0 bytes) -rak-gateway ttn-gateway[1886]: # PUSH_DATA datagrams sent: 1 (122 bytes) -rak-gateway ttn-gateway[1886]: # PUSH_DATA acknowledged: 0.00% -rak-gateway ttn-gateway[1886]: ### [DOWNSTREAM] ### -rak-gateway ttn-gateway[1886]: # PULL_DATA sent: 3 (100.00% acknowledged) -rak-gateway ttn-gateway[1886]: # PULL_RESP(onse) datagrams received: 0 (0 bytes) -rak-gateway ttn-gateway[1886]: # RF packets sent to concentrator: 0 (0 bytes) -rak-gateway ttn-gateway[1886]: # TX errors: 0 -rak-gateway ttn-gateway[1886]: ### SX1302 Status ### -rak-gateway ttn-gateway[1886]: # SX1302 counter (INST): 210904434 -rak-gateway ttn-gateway[1886]: # SX1302 counter (PPS): 0 -rak-gateway ttn-gateway[1886]: # BEACON queued: 0 -rak-gateway ttn-gateway[1886]: # BEACON sent so far: 0 -rak-gateway ttn-gateway[1886]: # BEACON rejected: 0 -``` - -:::note - -`ttn-gateway` is just the name for the LoRa packet forwarder service in the configuration for these -RAK concentrators; this is like a "legacy name" that doesn’t change when using different network -servers. - -::: - -### Edit the packet forwarder settings - -You will need to edit some basic options in the packet forwarder configuration to forward the -packets to the address and port the helium_gateway service is listening to. - -Select the option _Edit packet-forwarder config_ within the _gateway-config_ interface. This option -will open the `global_conf.json` file using the nano editor. Then, set the _server_address_ to -127.0.0.1 and the _server ports_ to 1680, as follows: - - - -Close the editor by pressing CTRL + X, press ENTER to save the file and restart the packet forwarder -to apply the changes by selecting the option _Restart packet-forwarder_ within the _gateway-config_ -interface. - -:::important - -Every time a new region is selected using the _Setup RAK Gateway Channel Plan_ option, these -settings are replaced with the default configuration. So, make sure to keep this in mind if you -modify the region later. - -::: - -## Helium Gateway service installation - -### Downloading the package - -Download the latest release from the [gateway-rs](https://github.com/helium/gateway-rs) repository, -and set the `` according to -[the latest release](https://github.com/helium/gateway-rs/releases). You can download it in any -directory, for example `/tmp`. - -#### Option 1 - -Getting from the repo directly to the Raspberry Pi by running the following commands. - -``` -cd /tmp -wget https://github.com/helium/gateway-rs/releases/download//helium-gateway--raspi234.deb -``` - -#### Option 2 - -You can also download it to your computer and pass it to the Raspberry Pi through the Secure Copy -Protocol (SCP). - -``` -scp helium-gateway--raspi234.deb pi@:/tmp/ -``` - -### Installing the package - -Run the following command in the same directory you downloaded the package to install the -_helium_gateway_ service in the operating system. - -``` -sudo dpkg -i helium-gateway--raspi234.deb -``` - -### Region configuration - -The default region of the _helium_gateway_ service is US915, so you can continue with the next -section if you are using this one. Otherwise, you must set your region frequency in -`/etc/helium_gateway/settings.toml`. Add the following line at the beginning of the file: - -``` -region = "" -``` - -Possible values are: -`US915 | EU868 | EU433 | CN470 | CN779 | AU915 | AS923_1 | AS923_2 | AS923_3 | AS923_4 | KR920 | IN865`. - -For instance, if your region is EU868 the content in `settings.toml` must be. - -``` -region = "EU868" - -[log] -method = "syslog" -level = "info" -timestamp = false - -[update] -platform = "raspi234" -``` - -After updating the value, you need to restart the _helium_gateway_ service to apply the changes. - -``` -sudo systemctl restart helium_gateway -``` - -## Verifying the installation - -### Inspecting the service logs - -The service starts after installation automatically. You can check the execution logs by running the -following command. - -``` -sudo tail -f /var/log/syslog | grep helium_gateway -``` - -The first log messages should look like these ones. - -``` -rak-gateway helium_gateway[23658]: starting, module: gateway -rak-gateway helium_gateway[23658]: starting, module: router -rak-gateway helium_gateway[23658]: default router, module: router, uri: [http://54.193.165.228:8080/](http://54.193.165.228:8080/), public_key: -rak-gateway helium_gateway[23658]: selected gateway, module: router, uri: [http://18.216.219.228:8080/](http://18.216.219.228:8080/), public_key: -rak-gateway helium_gateway[23658]: starting, module: updater -rak-gateway helium_gateway[23658]: updated routing to height 930678, module: router -rak-gateway helium_gateway[23658]: no update found, module: updater -rak-gateway helium_gateway[23658]: ignoring raw packet PushData(Packet { random_token: 25968, gateway_mac: MacAddress { bytes: [228, 95, 1, 255, 254, 3, 45, 43] }, data: Data { rxpk: None, stat: Some(Stat { time: "2021-07-21 17:23:40 GMT", lati: None, long: None, alti: None, rxnb: 0, rxok: 0, rxfw: 0, ackr: Some(0.0), dwnb: 0, txnb: 0 }) } }), module: gateway -rak-gateway helium_gateway[23658]: ignoring raw packet PullData(Packet { random_token: 23178, gateway_mac: MacAddress { bytes: [228, 95, 1, 255, 254, 3, 45, 43] } }), module: gateway -rak-gateway helium_gateway[23658]: new packet forwarder client: MacAddress(E4:5F:01:FF:FE:03:2B), 127.0.0.1:39196, module: gateway -rak-gateway helium_gateway[23658]: ignoring raw packet PullData(Packet { random_token: 16226, gateway_mac: MacAddress { bytes: [228, 95, 1, 255, 254, 3, 45, 43] } }), module: gateway -rak-gateway helium_gateway[23658]: ignoring raw packet PullData(Packet { random_token: 32809, gateway_mac: MacAddress { bytes: [228, 95, 1, 255, 254, 3, 45, 43] } }), module: gateway -``` - -Whenever you need to restart the service you can use the command below. - -``` -sudo systemctl restart helium_gateway -``` - -### Getting some information about the hotspot - -Use the following command to get the public key address and animal name of your hotspot. - -``` -helium_gateway key info -``` - -This command should give you an output like the following one. - -``` -{ - "address": , - "name": -} -``` - -#### Backup the gateway_key - -The `gateway_key.bin` file located at /etc/helium_gateway stores the information used to identify -the hotspot on the Helium Network. It's highly advised to backup this file, especially if you need -to recover it later after the onboarding process. - -Using SCP could be an option to do the backup; that would be something like this. - -``` -scp pi@:/etc/helium_gateway/gateway_key.bin -``` - -If you are using Windows, you can try a tool like [WinSCP](https://winscp.net/eng/index.php) too. - -### Testing the packet transfer with an end device - -If you have an end device (LoRaWAN node), you can check if the hotspot can transfer packets through -the network. In other words, you can check if the devices can send data to the Helium Console. The -Helium Console is where you can provision and manage the end devices, so the nodes need to be -registered to start using the network. - -#### Some comments and recommendations about the Helium Console - -At least for now, it is recommended to use the staging console instead of the production one when we -are transferring data through Data Only hotspots. You can differentiate them for the URL they use, -[console.helium.com](https://console.helium.com/) for production, and -[staging-console.helium.wtf](https://staging-console.helium.wtf) for staging. Don't be surprised if -you find some differences between those console flavors, basically staging is where the new features -are tested before their rollout to production. - -:::important - -If the device you will use for testing is registered on the production console, it's better to -delete it from there to avoid any unexpected behavior. - -::: - -To register your end device on the console, you can follow the steps described on -[Adding Devices](/use-the-network/console/adding-devices/). - -#### Inspecting the packet transfer behavior - -Make sure your device is configured or flashed with the same keys you registered on the console. -Then, when your device is ready to transmit data, take a look at the log messages again. - -``` -sudo tail -f /var/log/syslog | grep helium_gateway -``` - -Power up or reset your device, every time it tries to send a message, you should see the information -related to the packet received by the hotspot and where it is being routed. - -``` -rak-gateway helium_gateway[23658]: ignoring raw packet PushData(Packet { random_token: 18563, gateway_mac: MacAddress { bytes: [228, 95, 1, 255, 254, 3, 45, 43] }, data: Data { rxpk: Some([V1(RxPkV1 { chan: 4, codr: _4_5, data: [64, 11, 8, 0, 72, 0, 25, 1, 2, 138, 20, 173, 187, 16, 164, 246, 161, 241, 78, 16, 36, 238, 117, 161, 188, 240], datr: DataRate(SF7, BW125), freq: 904.7, lsnr: 13.2, modu: LORA, rfch: 1, rssi: -20, rssis: Some(-20), size: 26, stat: OK, tmst: 668364099 })]), stat: None } }), module: gateway -rak-gateway helium_gateway[23658]: routing packet to: http://54.193.165.228:8080/, module: router -``` - -If you are able to see this kind of logs your hotspot is working like a charm! The logs will record -more information according to the router/console state. - -Now, you should start to see some events on the console. Sometimes, it could take some minutes -before you start to see any activity; wait for a bit and reset your device if it's needed. - - - -As a final check, you can compare if the Hotspot Name matches the one you obtained before. It could -be different if there are more hotspots providing coverage around you. In that case, you can explore -the _Multiple Packets_ configuration to purchase more packets when several hotspots hear the device. - -## What's next? - -At this point, your Data Only Hotspot is ready to be added to the blockchain! You can find more -information about that process [here](/hotspot-makers/iot/data-only-hotspots#pre-requisites). diff --git a/docs/hotspot-makers/iot/full-hotspots.mdx b/docs/hotspot-makers/iot/full-hotspots.mdx deleted file mode 100644 index 8be4b6a7b..000000000 --- a/docs/hotspot-makers/iot/full-hotspots.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -id: full-hotspots -title: Full Hotspots -pagination_label: Full Hotspots -sidebar_label: Full Hotspots -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/full-hotspots ---- - -# Full Hotspots - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Full Hotspots are Helium coverage providers that can participate in all potential reward activity -available to Hotspots. Compared to a [Data Only Hotspots](/hotspot-makers/iot/data-only-hotspots), -Full Hotspots are eligible for [Proof-of-Coverage](/blockchain/proof-of-coverage) Rewards. - -Full Hotspots may only be manufactured by approved **Makers**. These are hardware vendors that have -been approved by the Helium community and the [Helium Foundation](https://helium.foundation). This -process is governed via -[Helium Improvement Proposal 19 (HIP-19)](https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md). - -## Approved Makers - -Nova Labs (formerly known as Helium Systems, Inc) was the first Hotspot manufacturer. Starting in -early 2019, they produced the first hardware capable of mining HNT and providing LoRaWAN wireless -coverage. In total, Nova Labs produced and sold the first 13,000 Hotspots to the Helium community to -seed the Network. - -Since the introduction of -[HIP-19](https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md), additional -approved Makers have been added. Each approved Maker is given a unique onboarding address on the -Helium blockchain where they are required to [burn data credits](/blockchain/transaction-fees) to -onboard their unique Hotspots before they are granted access to the blockchain. - -| Maker Name | HIP-19 Application | Date Approved | Onboarding Maker Address | -| :------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------- | :------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------- | -| [Helium Systems, Inc.](https://helium.com) | N/A | NA | [13daGGWvDQyTyHFDCPz8zDSVTWgPNNfJ4oh31Teec4TRWfjMx53](https://explorer-old.helium.com/accounts/13daGGWvDQyTyHFDCPz8zDSVTWgPNNfJ4oh31Teec4TRWfjMx53) | -| [Nebra Ltd](https://www.nebra.com/) | [Nebra](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/nebra-ltd.md) | 2020-12-10 | [13Zni1he7KY9pUmkXMhEhTwfUpL9AcEV1m2UbbvFsrU9QPTMgE3](https://explorer-old.helium.com/accounts/13Zni1he7KY9pUmkXMhEhTwfUpL9AcEV1m2UbbvFsrU9QPTMgE3) | -| [SyncroB.it](https://syncrob.it/) | [SyncroB.it](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/syncrobit.md) | 2020-12-14 | [14rb2UcfS9U89QmKswpZpjRCUVCVu1haSyqyGY486EvsYtvdJmR](https://explorer-old.helium.com/accounts/14rb2UcfS9U89QmKswpZpjRCUVCVu1haSyqyGY486EvsYtvdJmR) | -| [RAK Wireless/CalChip](https://www.calchipconnect.com/) | [RAK/CalChip](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/rak-wireless.md) | 2020-12-29 | [13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDirdY](https://explorer-old.helium.com/accounts/13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDirdY) | -| [EasyLinkin/Bobcat](https://www.bobcatminer.com) | [EasyLinkin](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/easylinkin.md) | 2021-01-12 | [14sKWeeYWQWrBSnLGq79uRQqZyw3Ldi7oBdxbF6a54QboTNBXDL](https://explorer-old.helium.com/accounts/14sKWeeYWQWrBSnLGq79uRQqZyw3Ldi7oBdxbF6a54QboTNBXDL) | -| [Kerlink](https://www.kerlink.com) | [Kerlink](https://github.com/dewi-alliance/hotspot-manufacturers/tree/main/applications/kerlink) | 2021-02-24 | [13Mpg5hCNjSxHJvWjaanwJPBuTXu1d4g5pGvGBkqQe3F8mAwXhK](https://explorer-old.helium.com/accounts/13Mpg5hCNjSxHJvWjaanwJPBuTXu1d4g5pGvGBkqQe3F8mAwXhK) | -| [HeNet BV/LongAP](https://www.longap.com) | [HeNet BV/LongAP](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/henet.md) | 2021-03-16 | [12zX4jgDGMbJgRwmCfRNGXBuphkQRqkUTcLzYHTQvd4Qgu8kiL4](https://explorer-old.helium.com/accounts/12zX4jgDGMbJgRwmCfRNGXBuphkQRqkUTcLzYHTQvd4Qgu8kiL4) | -| [Smart Mimic](https://smartmimic.com) | [Smart Mimic](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/smart-mimic.md) | 2021-03-25 | [13MS2kZHU4h6wp3tExgoHdDFjBsb9HB9JBvcbK9XmfNyJ7jqzVv](https://explorer-old.helium.com/accounts/13MS2kZHU4h6wp3tExgoHdDFjBsb9HB9JBvcbK9XmfNyJ7jqzVv) | -| [Seeed/SenseCap](https://www.sensecapmx.com/) | [Seeed/SenseCap](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/seeed.md) | 2021-06-15 | [14NBXJE5kAAZTMigY4dcjXSMG4CSqjYwvteQWwQsYhsu2TKN6AF](https://explorer-old.helium.com/accounts/14NBXJE5kAAZTMigY4dcjXSMG4CSqjYwvteQWwQsYhsu2TKN6AF) | -| [ClodPi](https://clodpi.io/) | [ClodPi](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/clodpi.md) | 2021-07-30 | [13XuP2DjHEHVkKguDDZD2ev5AeqMLuJ8UQ44efEcDmVTnBcvc6F](https://explorer-old.helium.com/accounts/13XuP2DjHEHVkKguDDZD2ev5AeqMLuJ8UQ44efEcDmVTnBcvc6F) | -| [E-sun Electronics/ Panther](https://panther.global/) | [PantherX](https://github.com/dewi-alliance/hotspot-manufacturers/blob/main/applications/pantherx.md) | 2021-09-24 | [13v9iGhjvQUtVaZXcFFRCEbL1nPR4R8QJowBgMUcaGM2v1aV6mn](https://explorer-old.helium.com/accounts/13v9iGhjvQUtVaZXcFFRCEbL1nPR4R8QJowBgMUcaGM2v1aV6mn) | - -## Becoming a Maker - -- [Maker Approval and Auditing](/hotspot-makers/become-a-maker/maker-approval-auditing) -- [Hotspot Integration Testing](/hotspot-makers/become-a-maker/hotspot-integration-testing) -- [Docker Integration](/hotspot-makers/become-a-maker/docker-integration) -- [Security Requirements](/hotspot-makers/become-a-maker/security-requirements) -- [Hotspot BLE Services](/hotspot-makers/become-a-maker/hotspot-ble-services) -- [Hotspot WiFi Configuration](/hotspot-makers/become-a-maker/hotspot-wifi-configuration) -- [Burning HNT to your Maker Wallet](/hotspot-makers/become-a-maker/burn-hnt-to-maker-wallet) -- [Create a Maker App](/hotspot-makers/become-a-maker/maker-app-requirements) -- [Radio Certification (FCC, CE)](/hotspot-makers/hotspot-audit-process#radio-certifications) diff --git a/docs/hotspot-makers/iot/light-hotspots.mdx b/docs/hotspot-makers/iot/light-hotspots.mdx deleted file mode 100644 index aa6efb88b..000000000 --- a/docs/hotspot-makers/iot/light-hotspots.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -id: light-hotspots -title: Light Hotspots -pagination_label: Light Hotspots -sidebar_label: Light Hotspots -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/iot/light-hotspots ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## IOT Hotspot Properties - -The IOT Hotspot software [gateway-rs](https://github.com/helium/gateway-rs) is in production, -satisfying the following properties: - -- A Hotspot on the Helium network will Beacon automatically on a pre-determined time interval. -- A Hotspot will submit PoC receipts directly to an Off-Chain PoC Oracle. -- A Hotspot will transmit packets on behalf of IoT devices on the Network to an Off-Chain Data - Oracle. -- A Hotspot will no longer depend on libp2p or "gossip", and instead use [gRPC](https://grpc.io/), a - new framework to communicate between distributed systems -- A Hotspot will be eligible to earn IOT token rewards. - -:::info Naming - -All IOT Hotspots are referred to as "Hotspots", discarding the previous distinctions of "Full -Hotspot" and "Light Hotspot." - -With the switch to `gateway-rs,` all IOT Hotspots are "Light Hotspots", so the prefix is no longer -needed. - -::: - ---- - -## HIP 70 Changes - -[HIP-70](https://github.com/helium/HIP/issues/471)has passed. HIP-70 proposes a new architecture -involving several Oracles, allowing Proof of Coverage ("PoC") generation to be automated and its -receipts to be off-chain. - -The most taxing piece of PoC is not just Challenge creation but Receipt validation and verification. -By taking these tasks off-chain, PoC event frequency can increase to several times daily. As a -result, Hotspot operators can expect more reliable challenges and witness events. - -## IOT Proof of Coverage Architecture Overview - -1. A Hotspot broadcasts a Beacon. -2. Nearby Hotspot(s) witness the Beacon. -3. Witness Hotpot(s) submit a receipt to an Ingestor Oracle. -4. The Packet Verifier gets data from the Packet Router. -5. The Ingestor Oracle uploads the receipts to a cloud store. -6. A Verifier Oracle takes this input from the Ingestor Oracle and the Packet Verifier to filter out - invalid receipts and produce a Reward output. -7. The Reward output passes to the Reward Oracle, determining how many reward shares a Hotspot - should earn for the epoch. -8. Finally, the Injector Oracle distributes Hotspots rewards. - - - ---- - -## Code and Development - -The bulk of the code that enables Hotspots on actual LoRaWAN gateways is Helium's next-generation -packet forwarder called [gateway-rs](https://github.com/helium/gateway-rs). - -:::info Join The Conversation - -For real-time development and community support of Data Only Hotspots and IOT Hotspots, please join -the [#gateway-development](discord://discord.com/channels/404106811252408320/784462269072277576) -channel on [Helium Discord](https://discord.gg/helium) - -::: diff --git a/docs/hotspot-makers/mcc/ce-red-compliance.mdx b/docs/hotspot-makers/mcc/ce-red-compliance.mdx deleted file mode 100644 index bf9180e35..000000000 --- a/docs/hotspot-makers/mcc/ce-red-compliance.mdx +++ /dev/null @@ -1,275 +0,0 @@ ---- -id: ce-red-compliance -title: CE RED Testing and Certification of Helium Compatible Gateways -pagination_label: CE RED Testing and Certification -sidebar_label: CE RED Testing and Certification -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/ce-red-compliance ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Introduction - -Helium hotspots (miners) operate in the EU868, also known as the EU863-870 MHz unlicensed band, as -modified LoRaWAN compatible gateways. Currently the Helium system operates on 200 kHz channel -frequencies from 868.1 to 868.8 MHz in the EU868 band. - -The CE Radio Equipment Directive, also known as CE RED, covers regulatory certification for all EU -member states. Other regulatory country bodies, such as Australia, some Middle Eastern, and African -countries also accept CE RED certification testing. CE RED is the most commonly accepted testing in -many countries around the world. - -Using CE pre-certified LoRaWAN gateway concentrator modules based on Semtech Corcell card designs -from marketplace suppliers can assist in the development of a new gateway product but these may or -may not include all the required certifications for Helium system support. As discussed in several -sections of this application note, not all EU member states are harmonised with their technical -specifications. It is the ultimate responsibility of manufacturers providing Helium compatible -network products that proper regulatory testing and certification or recertification is obtained for -countries of intended operation. - -In this application note the term gateway and hotspot are used interchangeably. - ---- - -## Glossary - -- **BW**: Bandwidth -- **e.r.p.**: Effective Radiated Power -- **ETSI**: European Telecommunications Standards Institute -- **EU**: European Union -- **EUT**: Equipment Under Test -- **LoRa**: Long Range radio modulation technique -- **LoRaWAN™**: LoRa low power Wide Area Network protocol -- **mW**: milli-Watts -- **PoC**: Helium Proof of Coverage function -- **RED**: Radio Equipment Directive -- **RF**: Radio Frequency -- **RX**: Receive / Receiver -- **SF**: Spreading Factor -- **TX**: Transmit / Transmitter - ---- - -## References - -- [ETSI EN 300 220-1 V3.1.1 (2017-02) Short Range Devices][etsi-220-1] -- [ETSI EN 300 220-2 V3.1.1 (2017-02) SRD Part 2 Essential requirements][etsi-220-2] -- [LoRa Alliance TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification][lora-ts001] -- [LoRa Alliance RP002-1.0.3 LoRaWAN® Regional Parameters][lora-rp002] -- [Semtech TN1300.01 How to Qualify a LoRaWAN Device in Europe][semtech-tn1300] -- [Semtech Corecell Gateway Reference Design EU Version Performance Report][semtech-corcell] - -[etsi-220-1]: - https://www.etsi.org/deliver/etsi_en/300200_300299/30022001/03.01.01_30/en_30022001v030101v.pdf -[etsi-220-2]: - https://www.etsi.org/deliver/etsi_en/300200_300299/30022002/03.01.01_60/en_30022002v030101p.pdf -[lora-ts001]: - https://resources.lora-alliance.org/technical-specifications/ts001-1-0-4-lorawan-l2-1-0-4-specification -[lora-rp002]: - https://resources.lora-alliance.org/technical-specifications/rp2-1-0-3-lorawan-regional-parameters -[semtech-tn1300]: - https://lora-developers.semtech.com/?ACT=72&fid=30&aid=48_0znCpZpvImL3agza59hG&board_id=1 -[semtech-corcell]: - https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R000000HUbM/mUMXJzdEmwrd5jfxulv1Lk7K_XiMO8DIG54TeLwnUuk - ---- - -## CE RED Certification Requirements - -Helium gateways currently operate on 9 frequencies in the 867 to 869 MHz range and are regulated by -ETSI standards. An additional channel at 869.525 MHz is supported by the gateway as a downlink -receive slot 2 (RX2) frequency. The Helium gateways meet current LoRaWAN specifications TS001-1.0.4 -and RP002-1.0.3, the document links are given in the references section above. To meet ETSI -requirements transmissions are duty cycle limited and do not use listen-before-talk protocol which -require different testing. - -The Helium frequency chart for EU868 operation is shown below. Note that uplink (transmissions to -the gateway) and downlink (transmissions from the gateway) frequencies are the same with no offsets. -These are the minimum frequencies required for operation on the Helium network. Developers may want -to test and certify for a wider EU868 frequency range of 863 through 870 MHz, 35 channels with -separations of 200 kHz, for possible future frequency expansions or the use of alternate frequencies -in some regions. It is important to note that additional frequency ranges, such as band K (863 – 865 -MHz), have lower transmit duty cycle requirements. - -### Helium Uplink and Downlink (RX1) Frequencies - -| Frequency (MHZ) | Spreading Factor | -| --------------- | ---------------------------------- | -| 868.1 | SF7BW125 to SF12BW125 | -| 868.3 | SF7BW125 to SF12BW125 and SF7BW250 | -| 868.5 | SF7BW125 to SF12BW125 | -| 867.1 | SF7BW125 to SF12BW125 | -| 867.3 | SF7BW125 to SF12BW125 | -| 867.5 | SF7BW125 to SF12BW125 | -| 867.7 | SF7BW125 to SF12BW125 | -| 867.9 | SF7BW125 to SF12BW125 | -| 868.8 | FSK | - -### Helium Downlink RX2 - -| Frequency (MHZ) | Spreading Factor | -| --------------- | ---------------- | -| 869.525 | SF12BW125 | - ---- - -## ETSI Testing Requirements - -ETSI standards define acceptable test procedures and limits. There are two applicable ETSI -specifications, EN 300-220-1 V3.1.1 (Part 1) and EN 300-200-2 V3.1.1 (Part 2). Note that the ETSI -specification EN 300-220-1 was split into these two parts with the latest versions V3.1.1 in 2017. -The Part 2 specification provides a “Harmonised Standard” for short range devices in the 25 to 1000 -MHz frequency range while the Part 1 specification gives details for “Technical characteristics and -methods of measurement”. Overall, Part 2 lists frequency bands and RF regulations for these bands -and points the reader to the applicable sections in Part 1 for specifics of measurement methods. The -EU868 (863 – 870 MHz) frequency range is broken up into many sub-bands with different power and duty -cycle requirements which are defined in the Part 2 specification. - -Since these specifications are linked, the required test explanations below for LoRaWAN / Helium -gateway certification will have the applicable sections of EN 300-220-2 and EN 300-220-1 listed. - -ETSI EN 300-220-1 4.3.3 defines normal test conditions and the following section 4.3.4 defines -extreme test conditions. Extreme conditions require additional testing over temperature and source -voltage variations depending on the operational profile defined by the manufacturer. Some standards -only require testing at normal conditions while others also require testing at extreme testing -conditions. - -### EN 300-220-2 4.2.1 / EN 300-220-1 5.1.1 Operating Frequency - -The manufacturer will declare the operating band or bands, frequencies, and operating channel widths -in the certification filing. See EN 300-220-2, Annex B and C, for tables of allowable frequencies -and bands of operation. Annex B lists the frequencies for EU wide national harmonised radio and -Annex C for radio interfaces not EU wide harmonised. The Annex C (not harmonised) is for operational -frequencies that may be allowed in some EU countries, but not all. It is up to the manufacturer to -determine which EU countries that the gateway may operate in and the requirements of that country. -Additional insight on this subject is given in the Semtech TN1300.01 technical note with a link in -the References. - -### EN 300-220-2 4.2.2 / EN 300-220-1 5.9 Spurious Emissions - -Unintended spurious emissions are measured in both transmit and receive / standby modes with -different limits for each operational mode. EN 300-220-1 5.9.1 defines a spectral mask when -transmitting with varying spurious limits depending on the frequency spacing from the intended -channel. Spurious emissions are measured in both conducted and radiated modes with the exception of -devices without antenna connectors (permanent antenna) are permitted to have radiated only -measurements. The ETSI specification covers a wide range of frequencies depending on the test mode -from 9 kHz to 6 GHz. The equipment under test must be measured at the lowest and highest operating -frequencies at maximum power. Normal test conditions are only required for spurious emissions -measurements. - -### EN 300-220-2 4.3.1 / EN 300-220-1 5.2 Effective Radiated Power - -Effective radiated power is measured by direct connection to the EUT when an external antenna port -is available. The power may be measured by radiated means when there is no external antenna -connector available. The maximum gain of the antenna, referenced to an ideal dipole, to be used with -the equipment is included in the test report. For conducted results of effective radiated power the -gain of the antenna must be added to the measured conducted power. This test is measured in transmit -mode at the lowest and highest frequencies of operation and also under normal and extreme test -conditions. - -### EN 300-220-2 4.3.2 / EN 300-220-1 5.3 Maximum e.r.p. Spectral Density - -Effective radiated power spectral density is defined as the maximum power radiated when transmitting -in units of power per hertz over the power envelop. Antenna gain referenced to a dipole, as in the -effective radiated power test, must be included in the calculation. It is important to note that the -e.r.p. spectral density test may be the limiting factor for the power setting of the gateway. - -Since gateways operate operate on several ETSI defined band “L” frequencies, specific limits may -apply depending on the EU country where it is intended for operation. In EN 300-220-2 Annex C, -certain “not EU harmonised” countries may not require the EUT to meet this regulation for spectral -density and allow 25 mW effective radiated power. For LoRaWAN / Helium operation in regions that -require this test the power will be limited to approximately 5 mW. The applicant should contact the -regulatory agencies of each EU country for the current rules and work with a testing service -facility to determine the proper limits. - -This test is measured in transmit mode at the lowest and highest frequencies of operation under -normal test conditions only. - -### EN 300-220-2 4.3.3 / EN 300-220-1 5.4 Transmit Duty Cycle - -The intent of the maximum transmitter duty cycle test is to not exceed the duty cycle limits given -in ETSI 300-220-2 Annex B and C. The EUT should be in “normal use” mode and the duty cycle -observational period is 1 hour of normal operation. - -### EN 300-220-2 4.3.4 / EN 300-220-1 5.6 Transmit Occupied Bandwidth - -Transmit occupied bandwidth is defined as the frequency range in which 99% of the total power of an -emission falls. This parameter is tested at the lowest and highest frequencies of operation and -under normal and extreme test conditions. - -### EN 300-220-2 4.3.5 / EN 300-220-1 5.8 Transmit Out of Band Emissions - -Two out of band emissions requirements are defined in ETSI specifications: The operating channel and -operational frequency band. The operating channel mask defines the emissions near the channel of -operation while the frequency band emissions include everything out to the operating band limits. -These spectrum masks may overlap. ETSI 300-220-1 5.8.1 defines the masks for both specifications. -Out of band emissions are tested at the lowest and highest frequencies of operation and also under -normal and extreme test conditions. - -### EN 300-220-2 4.3.6 / EN 300-220-1 5.10 Transmit Transient Power - -Transmit transient power is defined as the transmit power falling outside the current operating -channel when the transmitter is switched on and off. Transient power is measured at the lowest and -highest frequencies of operation at normal operating conditions only. - -### EN 300-220-2 4.4.2 / EN 300-220-1 5.18 Receiver Blocking - -Receiver blocking is defined as the capability of the receiver to receive a wanted modulated signal -without exceeding a given degradation due to the presence of a stronger unwanted input signal other -than a spurious response or an adjacent channel. The test is performed with 2 signal generators, one -on-channel with the wanted modulated signal and an offset generator with an unmodulated carrier. EN -300-220-2 specifies the minimum performance standard is a category 2, and EN300-220-2 5.18.3 defines -the levels for category 2. Blocking is measured at normal test conditions only but ETSI requires at -least 1 measurement per band that the EUT operates in. - -### Conducted and Radiated Tests, Antenna Requirements - -The effective radiated output power, EN 300-220-1 5.2, as discussed above takes into account antenna -gain. The maximum antenna gain, with respect to a dipole reference, must be added to output power to -determine the effective radiated output power. Gateways with antennas that have gain over a standard -dipole will need to reduce their maximum conducted power settings to meet this specification. - -ETSI certification testing is mostly written around conducted methods where a cable is attached to -the antenna port or a test port. The specifications do allow for radiated testing of most parameters -which may be the case for EUTs that do not have readily available test connections. See EN 300-220-1 -sections 4.3.7, 4.3.8, and 4.3.9 for requirements. Spurious emissions is a notable exception to -conducted only test procedures where a radiated measurement must be taken. - -While radiated testing for most parameters is allowed, it is usually not practical to attempt -extreme test conditions with this test method especially over temperature extremes. Most gateway -designs are stationary devices and are assumed to have access to an antenna connector or an internal -test connector. - -### Summary of Certification Testing Requirements - -| EN 300-220-2 | EN 300-220-1 | Tests | Limits | Results | -| ------------ | ------------ | ------------------------ | ---------------------------- | ------- | -| 4.2.1 | 5.1.1 | Operating Frequency | Declared | -| 4.2.2 | 5.9 | Spurious Emissions | See -1 5.9 | -| 4.3.1 | 5.2 | Effective Radiated Power | See -2 Annex B, C | -| 4.3.2 | 5.3 | e.r.p. Spectral Density | Depends on EU country | -| 4.3.3 | 5.4 | TX Duty Cycle | See -2 Annex B, C | -| 4.3.4 | 5.6 | TX Occupied Bandwidth | See -2 Annex B, C | -| 4.3.5 | 5.8 | TX Out of Band Emissions | See -1 5.8.2 Table 15 | -| 4.3.6 | 5.10 | TX Transient Power | See -1 5.10.2 Table 23 | -| 4.4.2 | 5.18 | Receiver Blocking | See -1 5.18.3 category 2 min | - ---- - -## Helium Foundation Expected Minimum Performance - -While all Helium gateways for operation in the EU must meet CD RED standards as presented in the -sections above, additional performance parameters not regulated by ETSI standards are expected to -ensure the intended operation of the Helium network. Maximum output power for the operational modes -is regulated by ETSI regulations, however, ETSI does not specify minimum power output. Likewise, the -EU does not regulate receiver minimum sensitivity levels for duty cycle limited devices. - -For the proper operation of the Helium network, minimum power outputs and receiver sensitivity are -expected for Helium’s hotspot approval process (see HIP19). The minimum performance levels are based -on Semtech Corecell reference design using the SX1302 baseband processor and SX1250 RF transceiver. -The Semtech performance report (link in the references) shows typical power outputs in section 4 and -receiver performance for various spreading factors in section 8. Helium expects power output to be -within 1 dB of the Corcell reference design and receiver sensitivities to be no worse than 2 dB -above the reference design levels. diff --git a/docs/hotspot-makers/mcc/compliance-committee.mdx b/docs/hotspot-makers/mcc/compliance-committee.mdx deleted file mode 100644 index 7e9f5d96a..000000000 --- a/docs/hotspot-makers/mcc/compliance-committee.mdx +++ /dev/null @@ -1,157 +0,0 @@ ---- -id: compliance-committee -title: Manufacturing Compliance Committee -pagination_label: Manufacturing Compliance Committee -sidebar_label: Compliance Committee -description: Manufacturing Compliance Committee -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/compliance-committee ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Charter - -- Quick Guide - - The Manufacturing Compliance Committee ("MCC") was formed to set basic standards and verify - compliance of the Hotspots being added to the Helium Network through - [HIP-19: Approval Process For Third-Party Manufacturers](https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md). - - The MCC reviews and votes to approve HIP-19 proposals. - - The purpose of the MCC is to ensure the security and integrity of the blockchain. - - The MCC does not endorse, govern, or regulate third-party manufacturers. - - The MCC requires manufacturers to submit copies of their regulatory compliance reports as part - of the final audit. - - The MCC has the power to grant and revoke maker keys. - ---- - -## Purpose and Goals - -The Manufacturing Compliance Committee (MCC) was formed to sets basic standards and verify that -these technical, security, and ethical standards are met by manufacturers joining the Helium Network -through the **[HIP-19](https://github.com/helium/HIP/blob/main/0019-third-party-manufacturers.md)** -process. - ---- - -Manufacturing a Hotspot is a new frontier for most manufacturers. They haven’t dealt with -decentralized systems, or the blockchain and its trustless implications and responsibilities. Those -features, which on the whole are beneficial, also create a risk that unwary and unethical -manufacturers develop and sell products that could negatively affect the network. - -The MCC’s mandate is to verify that manufacturers and their respective products meet the minimum -functional requirements for a device to participate on the Network. This includes blockchain-related -transactions, a check on relevant regulatory requirements for all radio hardware, and that the -devices meet the minimum authentication, encryption, and security standards needed to protect the -network. The MCC does not test for or enforce general product quality standards, ensure the overall -quality of the product, or the manufacturing process. Nor does the MCC test products for optimized -RF performance, only basic RF function is reviewed. - -## Summary - -The MCC tries to set manufacturers up for success by letting them know the _minimum_ standards they -need to meet and perform a cursory (and NOT binding) check on pre-production units. - -The MCC reviews the manufacturers at the following points: - -- When a new manufacturer makes its first application. Company information is submitted and reviewed - by the Helium Foundation and MCC. -- Each new Helium compatible product that the manufacturer brings to market is reviewed by the MCC. - -The review consists of: - -- Confirming that the appropriate radio certifications by country have been properly completed. -- Performing hardware audits to ensure it _can_ interface with the blockchain. - -The sole power the MCC wields is a very blunt instrument, which is that the MCC can bestow or -withdraw “maker keys”. In layman’s terms, the Maker’s Keys are the passcodes that allow a unit to be -added to the blockchain. This is a blunt and weak instrument by design; no one unit or entity should -be able to hold the entire ecosystem hostage. If an entity could selectively withdraw any hotspots -or group of hotspots' ability to participate in earning blockchain rewards, that entity would hold -tremendous and centralized power. - -A manufacturer is not bound or controlled by the MCC, the only required inspection points are its -initial manufacturer application approval and the subsequent submissions of Helium compatible -products for MCC hardware audit and approval. - -After being approved, a manufacturer may fail to meet either the technical, security, and/or ethical -standards set by the MCC committee. The MCC reserves the right to reassess the conformance of all -approved manufacturers and their Helium products at any time. If significant violations are found -the MCC may suggest the manufacturer take specific corrective actions and/or at its sole discretion -choose to suspend or permanently withdraw the manufactures “maker key(s)”. This will prevent the -maker from deploying any new Hotspots to the Helium network. - -Due to the nature of a decentralized ecosystem, the broader assessment of which manufacturers are -delivering high-quality and/or high-performance products must be left to the Helium Community and -natural market forces. This puts a majority of the responsibility of “buyer beware” on the -purchaser, which is unlike many other centralized network-connected products which are directly -supported by the “network operator”. - -### **MCC Member Requirements:** - -The Manufacturing Compliance Committee will prioritize prospective members with backgrounds and -expertise in the following topics: blockchain, embedded systems, electronics manufacturing, -security, and electrical, RF, or computer engineering. - -Committee members should demonstrate clear written communication and technical documentation skills. -They should have the ability to explain and educate others and conduct themselves diplomatically and -respectfully to the community. - -Committee members should be active within the Helium community, and demonstrate alignment to grow -the Helium Network responsibly with reputable partners. - -Committee members are expected to actively engage in MCC monthly meetings, discussions, and voting. -The Committee may vote to remove a member that misses more than two meetings per quarter. - -MCC members may serve indefinitely unless they are removed or resign. However, it is recommended -that members cycle yearly. - -- **Elections** - - How to get nominated: MCC members may be nominated by a MCC member or a Helium Foundation - member, then a vote will be held. ⅔ majority vote by the sitting committee must be met to - approve the new member. - - Removing a sitting committee member: The MCC may vote to remove a sitting committee member if - they do not meet the expectations and requirements outlined in this document. A ⅔ majority vote - will also remove a committee member. - - Qualifications (see disciplines) -- **Voting** - - Manufacturer approvals require a ⅔ majority vote. - - Changes to the MCC charter require a ⅔ majority vote. -- **Reporting** - - The MCC will meet for a live video call once a month. These monthly meetings are recorded and - notes are taken, both are publicly available to the community. - - Meeting are scheduled for 12pm ET on the 3rd Wednesday of each month. (This is subject to - change due to holidays, emergencies, etc) - - **Tentative 2023 Schedule:** _May 17, June 21, July 19, August 16, September 20, October 18, - November 15, & December 20_ - - [Recorded videos](https://www.youtube.com/@heliumfoundation) - - [MCC Monthly Call Notes](https://docs.google.com/document/d/1CtJK8Podx8hdWNJ8HCRImBfSwJVt1jZ10Eabeh2s-yA/edit?usp=sharing) - - Announcements will be published on the - [Committee Announcements channel](https://discord.com/channels/404106811252408320/921085505028890674) - on Discord. - ---- - -### **MCC Committee Composition:** - -To provide optimal guidance, the MCC seeks diversification of participants from the Helium -community, Helium ecosystem participants, and domain experts. - -> If you are interested in joining the working group, please -> [fill out an application](https://forms.gle/5gEf7MLniDMgkwPq8). - -Target committee size and composition are outlined in the following table. - -| MCC Member Role | Profile | # | Voting? | -| :----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-: | :-----: | -| Chair | Must have both, broad knowledge of the entire Helium ecosystem and technical expertise with the ability to commit the time required to lead MCC. | 1 | Yes | -| Vice-Chair | Back-up to Chair, with a similar background. | 1 | Yes | -| Helium Community | Active Helium community members interested in helping grow the network | 2-3 | Yes | -| Security Expert(s) | Member with expertise in encryption and supporting embedded hardware design practices using - HSM, TPM, TrustZone, secure boot. | 1-2 | Yes | -| RF Expert(s) | Member with expertise in RF design, regulatory testing, and certifications. Must be able to review and prove RF certifications issued by the FCC or other regulatory bodies. Specific expertise in LoRa, CBRS, and 5G is a bonus. | 1-2 | Yes | -| Manufacturers | Rotating representatives from the current group of approved manufacturers for a one-year term. | 1-2 | No | -| Advisor | Rotating industry domain expert | 2 | No | - ---- - -[Helium Network Manufacturer Ethics and Expectations](https://docs.helium.com/hotspot-makers/maker-ethics) diff --git a/docs/hotspot-makers/mcc/fcc-compliance.mdx b/docs/hotspot-makers/mcc/fcc-compliance.mdx deleted file mode 100644 index 09ac4889a..000000000 --- a/docs/hotspot-makers/mcc/fcc-compliance.mdx +++ /dev/null @@ -1,337 +0,0 @@ ---- -id: fcc-compliance -title: FCC Testing and Certification of Helium Compatible Gateways -pagination_label: FCC Testing and Certification -sidebar_label: FCC Testing and Certification -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/fcc-compliance ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Introduction - -Helium hotspots (miners) operate in the US915, also known as the US902-928 MHz unlicensed band, as -modified LoRaWAN compatible gateways. Currently the Helium system operates on 8 channels in sub-band -2 of the US915 band as defined by LoRaWAN Regional Parameters document. - -Standard LoRaWAN gateways downstream transmissions are in the upper frequency range (923.3 – 927.5 -MHz) using 500 kHz modulation in digital DTS mode. In addition, Helium compatible gateways transmit -in the lower frequency range (903.9 to 905.3 MHz) using 125 kHz channel modulation to support -proof-of-coverage (PoC) functions. The PoC transmissions are similar in format and requirements to -LoRaWAN endpoint devices. This PoC operation falls under a different FCC classification known as a -DSS Hybrid system and specific testing is required for certification. - -Using FCC pre-certified LoRaWAN gateway modules based on Semtech Corcell LoRaWAN concentrator card -designs from marketplace suppliers are not likely to have been tested and certified to support -Helium’s PoC 125 kHz hybrid transmissions. In this case, the FCC requires full recertification with -a new FCC product identification (FCC ID) number. It is the responsibility of manufacturers -providing Helium compatible network products to ensure that proper testing and certification or -recertification is obtained. - -This application note helps the reader understand the FCC certification testing needed to support a -Helium gateway with standard LoRaWAN DTS functions and additional DSS Hybrid mode requirements to -support PoC. - ---- - -## Glossary - -- **ANSI**: American National Standards Institute -- **BW**: Bandwidth -- **CFR**: Code of Federal Regulations (US) -- **DSS**: Digital Spread Spectrum -- **DTS**: Digital Modulation Mode -- **FCC**: Federal Communications Commission -- **FHSS**: Frequency Hopping Spread Spectrum -- **Hybrid**: System employing both frequency hopping and digital modulation -- **KDB**: FCC Knowledge Database -- **LoRa**: Long Range radio modulation technique -- **LoRaWAN™**: LoRa low power Wide Area Network protocol -- **PoC**: Helium Proof of Coverage function -- **RX**: Receive / Receiver -- **SF**: Spreading Factor -- **TX**: Transmit / Transmitter - ---- - -## References - -- [Code of Federal Regulations, Title 47, Part 15.247 Operation within the bands 902 – 928 - MHz][code-of-regulations] -- [FCC KDB publication 550874 Guidance for Compliance Measurements...][fcc-kdb] -- [IEEE/ANSI C63.10-2020 American National Standard Of Procedures For Compliance Testing Of - Unlicensed Wireless Devices][ieee-ansi-c63] -- [Semtech AN1200.62 Best Practices for FCC Pre-Compliance Testing of LoRaWAN™ - Modules][semtech-an1200] -- [LoRa Alliance TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification][lora-ts001] -- [LoRa Alliance RP002-1.0.3 LoRaWAN® Regional Parameters][lora-rp002] -- [Semetch Corcell Gateway Reference design US version Performance Report][semtech-corcell] - -[code-of-regulations]: - https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15/subpart-C/subject-group-ECFR2f2e5828339709e/section-15.247 -[fcc-kdb]: - https://apps.fcc.gov/kdb/GetAttachment.html?id=tylb5MMggvhIlVMK75RrRQ%3D%3D&desc=558074%20D01%2015.247%20Meas%20Guidance%20v05r02&tracking_number=21124 -[ieee-ansi-c63]: - https://webstore.ansi.org/Standards/IEEE/IEEEANSIC63102020?source=blog&_ga=2.34908257.1568056374.1665406651-91269165.1664804467 -[semtech-an1200]: - https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R000000Utfm/3nixYcPzYVle2Ov3YlCd6PD0o3umgTeP9lBkwgiuoN0 -[lora-ts001]: - https://resources.lora-alliance.org/technical-specifications/ts001-1-0-4-lorawan-l2-1-0-4-specification -[lora-rp002]: - https://resources.lora-alliance.org/technical-specifications/rp2-1-0-3-lorawan-regional-parameters -[semtech-corcell]: - https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/2R000000HUdh/9kR4.s9sZG5.CVW2ZrQOxjKl1FjKzwfh5k547K.M5Uc - ---- - -## FCC Certification Requirements - -As stated in the introduction, a Helium gateway must support 2 different modes of operation and -therefore requires multiple (DTS and DSS Hybrid) FCC certification testing. The test descriptions -below are grouped by these modes, DTS digital modulation and DSS Hybrid operation which employs a -combination of frequency hopping and digital modulation techniques. - -According to FCC KDB 550874 section 1, the 2 modes of operation in the same gateway require two, -Form 731 applications and the unit is considered a composite system. However, only a single product -identifier (FCC ID) is needed. - -Frequency charts and modulation types for Helium network operation are shown below for reference. -Normal LoRa gateway uplink frequencies (endpoint transmissions received by the gateway) occur in the -902 to 915 portion of the US915 band and downlink frequencies (transmissions from the gateway) occur -in the 923 to 928 MHz portion of the band. The uplink channels can be 125 kHz (64 total channels) -and 500 kHz (8 total channels) wide bandwidth. The operation for Helium gateway uplink PoC -transmissions is in sub-band 2 as defined by LoRa Alliance RP002-1.0.3 Regional Parameters -specification. These are 8 channels, 200 kHz spaced, from 903.9 to 905.3 MHz. While sub-band 2 is -the minimum requirement for Helium network gateway support, developers may want to test and certify -their gateways for all possible PoC channels in the entire range of 902.3 to 914.9 MHz. Future -network enhancements may include additional sub-bands support. - -### Helium Gateway Uplink and PoC Transmission Frequencies (BW125 channels) - -| Frequency (MHZ) | Spreading Factor | -| --------------- | --------------------- | -| 903.9 | SF7BW125 to SF10BW125 | -| 904.1 | SF7BW125 to SF10BW125 | -| 904.3 | SF7BW125 to SF10BW125 | -| 904.5 | SF7BW125 to SF10BW125 | -| 904.7 | SF7BW125 to SF10BW125 | -| 904.9 | SF7BW125 to SF10BW125 | -| 905.1 | SF7BW125 to SF10BW125 | -| 905.3 | SF7BW125 to SF10BW125 | -| 904.6 | SF8BW500 | - -### Helium Gateway Downlink Frequencies - -| Frequency (MHZ) | Spreading Factor | -| --------------- | --------------------------- | -| 923.3 | SF7BW500 to SF12BW500 (RX1) | -| 923.9 | SF7BW500 to SF12BW500 (RX1) | -| 924.5 | SF7BW500 to SF12BW500 (RX1) | -| 925.1 | SF7BW500 to SF12BW500 (RX1) | -| 925.7 | SF7BW500 to SF12BW500 (RX1) | -| 926.3 | SF7BW500 to SF12BW500 (RX1) | -| 926.9 | SF7BW500 to SF12BW500 (RX1) | -| 927.5 | SF7BW500 to SF12BW500 (RX1) | -| 923.3 | SF12BW500 (RX2) | - ---- - -## LoRaWAN Digital Modulation DTS Operation - -Standard LoRaWAN digital operation mode referred to as “DTS” mode is defined by the FCC as having a -minimum 6 dB bandwidth of 500 kHz and a maximum spectral power density of +8 dBm in any 3 kHz -segment and a +30 dBm (1 Watt) maximum output. Spurious emissions are also regulated according to -different frequency ranges which are considered restricted and non-restricted. Helium only gateways -only transmit in the 500 kHz DTS mode in the upper frequency range of 923.3 to 927.5 MHz. The -following are the descriptions of the tests required for FCC certification. - -To demonstrate compliance, the device under test is normally measured at maximum power output on 3 -frequencies that are at the low, middle, and high end of the frequency range. - -### FCC CFR 15.247 (a)(2) 6 dB Transmit Bandwidth - -The FCC requirement has a 6 dB minimum bandwidth of 500 kHz to be considered as DTS operation. The -measurement guidance for certification testing is contained in the FCC Guidance for Compliance -document KDB 558074. The KDB 558074 also refers to the acceptable test methodologies contained in -ANSI document C63.10 section 11.8. Different test methods for measuring the 6 dB bandwidth are given -in C63.10 depending on the capabilities of the test equipment. - -### FCC CFR 15.247 (b)(3) Output Power - -The maximum permissible output power for DTS operation is 30 dBm (1 Watt). While this is a -straightforward specification the FCC does permit 2 different measurements of measuring power: 1) -Maximum peak conducted output power method or 2) Maximum conducted (average) output power. The key -to understanding this measurement guidance is given in KDB 558074 section 8.3. This also refers the -reader to ANSI C63.10 sections 11.9.1 and 11.9.2 for specific test procedures. The recommended test -method is to use the average power output procedure. The reason for this is the next test -requirement listed below for power spectral density requires the same test method be used for both -measurements. There is a power advantage realized by using an average measurement for power spectral -density due to the nature of the chirp spread spectrum modulation on LoRa designs. - -### FCC CFR 15.247 (e) Power Spectral Density - -The FCC also places a power spectral density limit on all transmissions of 8 dBm maximum in any 3 -kHz segment of the transmission band. KDB 558074 8.4 lists this requirement and refers to ANSI -C63.10 section 10.11. Note that the test setups for this parameter is identical to the Output Power -(15.247 (b)(3)) above and 15.247 (e) mandates that the same method for determining the output power -shall be used to determine the power spectral density. As stated above for the output power -requirement, the average power test method is recommended. - -### FCC CFR 15.247 (d) Out of Band Emissions - -Out of band emissions, also known as spurious emissions, are transmitter power that is present out -of the current operating band. There are several parameters to note from 15.247 (d). First, the -limit does depend on how the transmitter power was measured in 15.247 (b)(3). Second, spurious -emissions will fall into “restricted” and “non-restricted” frequency bands that are defined in FCC -CFR 15.205 (a). Emissions that fall into restricted frequency bands must have radiated levels lower -than limits defined in FCC CFR 15.209 (a). - -FCC KBD 558074 section 8.5 refers to the test methodology given in ANSI C63.10 section 11.11 for -non-restricted measurements. FCC KBD 558074 section 8.6 points to ANSI C63.10 section 11.12 for -testing in restricted frequency bands. - ---- - -## Helium PoC DSS Hybrid operation - -Operation in the lower portion of the US915 frequency band using 125 kHz modulation bandwidth for -Helium’s PoC transmissions falls under the FCC classification of a Hybrid system and test -requirements for certification differ from standard digital modulation modes. A Hybrid system is -defined by the FCC as employing both frequency hopping and digital modulation techniques at the same -time on the same carrier. A Hybrid system must also meet the definition of true frequency hopping -systems. See FCC KDB 558074 section 1 and 10 for the definition of a Hybrid system. The Helium -network in the US currently uses 8 channels in sub-band 2 in the lower end of the US915 frequency -band. The channel bandwidth for PoC transmissions is 125 kHz and a LoRa coding rate of 4/5. The -packet transmission time is approximately 329 ms with spreading factors of 7 to 10. The channel -hopping is random. Power output in hybrid mode is also limited by regulations compared to the DTS -mode. Below are listed the specific requirements for certification and how these apply to the Hybrid -transmission mode. - -### FCC CFR 15.247 (a)(1) Channel Separation, Random Channels - -This paragraph of the FCC regulations defines the minimum channel separation dependent on modulation -bandwidth and the randomness of the frequency hopping. FCC KDB 558074 10 (b)(6)(iii) points to ANSI -C63.10 section 7.8.2 for testing carrier separation. A description from the applicant of the -pseudorandom hopping sequence and equal hopping frequency use is also needed for the filing. See FCC -KDB 558074 section 9 (c)(1) for the requirement. - -### FCC 15.247 (d) Out of Band Emissions - -This requirement for Hybrid mode is identical to the DTS mode operation that is described in section -4.1.4 above. - -### FCC 15.247 (f) Dwell Time and Power Spectral Density - -This paragraph describes the maximum time spent on any single channel (0.4 seconds) when frequency -hopping and also the maximum power output permitted. The maximum power is specified as +8 dBm in any -3 kHz band of the channel. For LoRaWAN 125 kHz modulation, and by using the test methods in the ANSI -C63.10 document, this results in approximately +21 dBm maximum power output on any channel, also see -LoRa Alliance RP002-1.0.3 2.5.2. Note that frequency hopping is typically turned off with special -test code for this test. FCC KDB 558074 refers to ANSI C63.10 sections 7.8 and 11 for test methods. - -### FCC 15.247 (g) Channel Distribution - -The language of this paragraph ensures that the equipment under test is capable of operation as a -true frequency hopping system. The device must demonstrate pseudorandom hopping and equal channel -usage with short data bursts or continuous (long) data streams. See FCC KDB 558047 9 (c)(2) for a -description of this requirement. - ---- - -## Antenna Requirements - -There are several important factors to consider with the antenna that will be included with a -gateway. The antenna parameters are included in the FCC filing and directly affects certification. - -### Fixed or Integrated Antenna - -A fixed antenna or one that is integrated into the design and cannot be removed from the device -requires radiative test methods since there are no conductive test capabilities. The FCC does allow -certification if there is no antenna test port available by only using radiation measurements. This -is described in FCC KDB 558074 section 3. An integrated antenna more frequently applies to LoRaWAN -endpoint devices while gateways usually have a removable antenna or a test port. - -### FCC CFR 15.247 (b)(4) Antenna Gain - -FCC regulations allows normal output power for devices up to and including an antenna with 6 dBi -(over an isotropic radiator) gain. If the antenna included with the gateway is over 6 dBi gain, the -power output must be reduced in an equal amount that the antenna is over 6 dBi. Also see FCC KDB -558074 section 7 for further clarification of antenna gain requirements. - -### FCC CFR 15.203 Antenna Connection - -Another requirement specifies that other antennas not specified by the manufacturer cannot be -attached to the unit. Permanently attached or the use of unique coupling (connector) for the antenna -will meet this requirement. Note that using industry standard antenna jacks and electrical -connectors is prohibited. The intent of this regulation is to prevent the end user from changing the -antenna and modifying the peak radiated power from the device. - ---- - -## AC Power Line Conducted Emissions - -The assumption is the majority of Helium gateway designs will be powered from the AC power line. FCC -CFR 15.207 specifies the maximum RF voltage in the 150 kHz to 30 MHz range that can be conducted -back to the utility power line. The test facility will normally perform this test during the -certification process. - ---- - -## Frequency Stability - -While FCC CFR 15.247 does not explicitly specify frequency stability of the transmitter there are -other CFR sections which are applicable to ensure operation within the frequency band over -temperature and voltage variations. See FCC CFR 15.215 (c) for keeping transmissions within -designated frequency bands and FCC CFR 2.1055 (d) for the requirements of voltage variation. - ---- - -## Summary of Certification Testing Requirements - -### DTS Digital Modulation Requirements - -| FCC Rule | Tests | Limits | Results | -| ------------- | -------------------- | ------------------------------------------ | ------- | -| 15.247 (a)(2) | 6 dB Bandwidth | 500 kHz min | -| 15.257 (b)(3) | Output Power | +30 dBm max | -| 15.247 (e) | Spectral Density | +8 dBm / 3 kHz max | -| 15.247 (d) | Radiated Emissions | See rules for limits | -| 15.209 (a) | Radiated Emissions | See rules for limits | -| 15247 (b)(4) | Antenna Requirements | 6 dBi antenna gain Connection requirements | -| 15.203 | Antenna Requirements | 6 dBi antenna gain Connection requirements | -| 15.207 | Conducted Emissions | 150 kHz – 30 MHz see rules for limits | -| 15.215 (c) | Frequency Stability | TX within band | - -### DSS Hybrid Modulation Requirements - -| FCC Rule | Tests | Limits | Results | -| ------------- | -------------------- | ------------------------------------------ | ------- | -| 15.247 (a)(1) | Channel Requirements | See rules | -| 15.247 (d) | Radiated Emissions | See rules for limits | -| 15.209 (a) | Radiated Emissions | See rules for limits | -| 15.247 (f) | Spectral Density | +8 dBm / 3 kHz max | -| 15.247 (g) | Channel Distribution | See rules | -| 15247 (b)(4) | Antenna Requirements | 6 dBi antenna gain Connection requirements | -| 15.203 | Antenna Requirements | 6 dBi antenna gain Connection requirements | -| 15.207 | Conducted Emissions | 150 kHz – 30 MHz see rules for limits | -| 15.215 (c) | Frequency Stability | TX within bands | - ---- - -## Helium Foundation Expected Minimum Performance - -While all Helium gateways for operation in the US must meet FCC standards as presented in the -sections above, additional performance parameters not regulated by federal standards are expected to -ensure the intended operation of the Helium network. Maximum output power for the operational modes -is regulated by FCC rules, however, the FCC does not specify minimum power output. Likewise, there -are no US federally regulated receiver minimum sensitivity levels. - -For the proper operation of the Helium network, minimum power outputs and receiver sensitivity are -expected for Helium’s hotspot approval process (see HIP19). The minimum performance levels are based -on Semtech Corecell reference design using the SX1302 baseband processor and SX1250 RF transceiver. -The Semtech performance report (link in the references) shows typical power output in section 6 and -receiver performance for various spreading factors in section 8. Helium expects power output to be -within 1 dB of the Corcell reference design and receiver sensitivities to be no worse than 2 dB -above the reference design levels. diff --git a/docs/hotspot-makers/mcc/hotspot-audit-process.mdx b/docs/hotspot-makers/mcc/hotspot-audit-process.mdx deleted file mode 100644 index 572e558f7..000000000 --- a/docs/hotspot-makers/mcc/hotspot-audit-process.mdx +++ /dev/null @@ -1,187 +0,0 @@ ---- -id: hotspot-audit-process -title: Hotspot Audit Process -pagination_label: Hotspot Audit Process -sidebar_label: Hotspot Audit Process -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/hotspot-audit-process ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Hardware Audit will require two hardware samples of each Hotspot. For example, if the Audit -includes Indoor and Outdoor Hotspots, 2 of each model are required for submission. - -Hardware samples submitted to Auditors should be identical to the final hardware sold to customers, -including the final enclosure. Prototypes or 3D-printed enclosures are not acceptable for Hardware -Audits. - -:::caution - -The [Manufacturing Compliance Committee](/hotspot-makers/compliance-committee) ("MCC") is only -currently accepting Light Hotspots and 5G Hotspots for audit at this time. - -::: - ---- - -## Documentation Submission Requirements - -:::info PDF Only - -Submit all documentation as a single PDF. Do not send Word documents, Excel spreadsheets, or other -non-PDF formatted documents. - -::: - -Each Hardware Audit requires a PDF copy of the responses to the following questions. Please organize -answers in order, and send the document electronically in one PDF with a response to all questions. - -Hardware Audits are expected to take a minimum of 7 weeks from the time Auditors receive Hardware -samples and payments. **Missing information will result in significant delays.** - ---- - -## Identifying Hotspots and Components - -1. Clearly label the Hardware with the company name. -2. Clearly label the Hardware with the Hotspot(s) model name(s). -3. Include a link to the HIP-19 Application. -4. Ensure the HIP-19 Application matches the hardware and related documentation. -5. Specify the Hotspot for audit type, Light or Mobile/5G. -6. If this is a Mobile/5G, specify whether the Hotspot has LoRaWAN capability. -7. Specify if Hotspot is an Indoor or Outdoor Hotspot. - - If only an Indoor Hotspot is submitted, state whether or not Auditors should expect an Outdoor - Hotspot later. - - If only an Outdoot Hotspot is submitted, state whether or not Auditors should expect an Indoor - Hotspot later. -8. Include a block diagram (see example) with clearly labeled locations of the security - implementation (ECC chip, TrustZone, etc.). - - A block diagram is a system diagram with CPU/ MCU, memory, ECC/ other security, etc., with all - circuits clearly labeled with part numbers. - - Include a sketch or photo indicating the location of the security module on the PCB. - - - ---- - -## Auditor Access To Your Hotspot - -### LoRaWAN Capable Hotspots - -1. The Hotspot should arrive running as it would be at a customer's location. -2. Provide instructions for stopping and starting Packet Forwarder. -3. Provide the location of the Packet Forward configuration file `global_conf.json`. -4. Provide the path to the `gateway-rs` executable (ie: `helium_gateway`) -5. Provide the architecture/distribution used by the CPU. - - Match it here: - [https://github.com/helium/gateway-mfr-rs/releases/tag/v0.2.2](https://github.com/helium/gateway-mfr-rs/releases/tag/v0.2.2) - so that auditors can install Helium's `gateway_mfr_rs` on the hardware and check the ECC - configuration. -6. Provide the commands to start and stop the `gateway-rs` executable (ie, `helium_gateway`) -7. If using the ECC608 as a security element, provide the key slot and bus address -8. Upon power up, is `gateway-rs` running and ready to audit? **Y/N** - - `gateway-rs` must automatically update; the Auditor shall not update the firmware. -9. Is the Hotspot using Helium's `gateway-rs` updater? **Y/N** - - If **Yes**, please indicate which [build target - (https://github.com/helium/gateway-rs/blob/main/.github/workflows/ci.yml#L42) matches the - Hardware. - -### LoRaWAN Capable Full Hotspots - -1. The Hotspot should arrive running as it would be at a customer's location. -2. Provide instructions for stopping and starting Packet Forwarder. -3. Provide the location of the Packet Forward configuration file `global_conf.json`. -4. Provide instructions for stopping and starting Miner. -5. Provide location of miner data. - -### 5G Only Hotspots - -1. The Hotspot should arrive running as it would be at a customer's location. -2. Provide instructions for stopping and starting Packet Forwarder. -3. Provide the location of the Packet Forward configuration file `global_conf.json`. -4. Specify which CBRS radio brand and models are compatible with the 5G Hotspot. - ---- - -## Radio Certifications - -1. Specify which radio certification intentions. -2. Specify country/region sales intentions. - - The MCC will only vote once all radio certifications are complete. Therefore, MCC will not vote - on reports only as certifications and reports expected at the time of voting. -3. Specify whether Hotspots will be sold in a frequency that requires "Listen Before Talk" or - "Listen Before Transmit"? **Y/N** - - e.g., Japan, South Korea -4. Specify whether Hotspots will be sold in the AU915 region. **Y/N** - - If yes, certify that you can also operate under AS923-1. - - Transmit test must be checked on AS923-1 channels - - AS923-1-AU - - The default AS923-1 freq band ranges from 915 to 928 MHz - - Verify transmit from 915 to 928 MHz at every 200 kHz interval (915.2, 915.4 ... 927.6, 927.8). - At all data rates, i.e., DR0-DR7 (including the FSK) - ---- - -## Notes On FCC - -1. Provide the FCC ID number in addition to the Certification. - -:::caution avoid delays - -Read the -[Helium PoC FCC Guidelines documentation.](https://docs.google.com/document/d/1JDh1I2UyNCXgDGXq3zNH-IUj2184ApPuqT-wI-aNwZw/edit?usp=sharing) - -Incorrect FCC Certification will experience significant delays, months or more. - -::: - ---- - -## Additional Information for Audits - -1. Explain the OTA/firmware update process. - - Show the process by which firmware updates are cryptographically verified. -2. Specify whether or not there is a dashboard or other interface on the Hotspot that allows it to - be controlled over the network. **Y/N** - - If **Yes**, this dashboard must require a password which is unique per device and sufficiently - random so as to not be guessable or other secure token to access. -3. Specify whether or not the Hotspot has production-ready firmware, including an over the air (OTA) - update process for the miner. **Y/N** -4. Confirm understanding that the Helium Hotspot app will not be available for customer use after - March 1st, 2022? **Y/N** -5. Specify whether or not a Maker App for customers to onboard has been created. **Y/N** - -:::tip Maker Apps Are Required - -A Maker App must be created and tested to continue with the hardware audit. - -::: - -### Additional Information for 5G Hotspots - -1. Provide a `gateway_mfr utility` to access the secure element. -2. Show the secure boot hardware via a diagram. - - The diagrams should include all the hardware involved in the boot process and the security - boundaries of each component. -3. Hardware items to illustrate include (but are not limited to): - - Cryptographic hardware accelerator - - Secure storage for private/secret and public keys - - Secure RAM - - Boot ROM - - Untrusted external RAM - - Untrusted external non-volatile storage (eMMC, SATA, etc) - - Communication busses -4. Using callouts to the secure boot hardware diagram, show how the system can determine that the - firmware that it is booting comes directly from an authorized source and has not been altered. -5. Show how the Secure Element, which contains the private key that identifies the Hotspot on the - blockchain, will **only** obey encryption, decryption and signature generation requests if they - come from authorized firmware. - -:::tip - -Diagrams must also show the security boundaries of the design. Group each component and bus by the -boundary it resides in. - -::: diff --git a/docs/hotspot-makers/mcc/maker-ethics.mdx b/docs/hotspot-makers/mcc/maker-ethics.mdx deleted file mode 100644 index 4f929200d..000000000 --- a/docs/hotspot-makers/mcc/maker-ethics.mdx +++ /dev/null @@ -1,148 +0,0 @@ ---- -id: maker-ethics -title: Maker Ethics -pagination_label: Maker Ethics -sidebar_label: Maker Ethics -description: Maker Ethics -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/maker-ethics ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::info - -The community may raise ethics violation issues and send evidence to the MCC via the Manufacturing -Program Manager: [christina@helium.foundation](mailto:christina@helium.foundation) - -::: - -# Summary - -This ethics document is written by the Manufacturing Compliance Committee (MCC) to clearly document -what the ethics expectations of manufacturers are. If a manufacturer fails to uphold the ethics and -expectations outlined in this document, the Helium community reserves the right to take action -against the manufacturer. The consequence will be decided on by the Helium community and may -include: requests for more information, selling restrictions, temporary probation, or in extreme -cases, revoking of a maker's key or a ban from the community. - -In order to achieve the collective goal of a global decentralized Helium network, large volumes of -Hotspots are manufactured from a wide range of manufacturers. The existing HIP-19 application -process and guidelines provide new and existing Helium Hotspot manufacturers specific guidance on -the hardware design, configuration, security, and manufacturing requirements needed to become an -approved Helium compatible Hotspot manufacturer. - -Only HIP-19 approved manufacturers are granted the trusted privilege to add new Hotspots to the -Helium network. With this privilege, manufacturers are also entrusted with the responsibility to act -ethically and with the proper internal processes to protect the integrity of the Helium network. - ---- - -## Ethics Tenents - -### 1. Reporting Gaming - -Manufacturers bear the responsibility to proactively report any potential “gamed” deployment by -their customers, partners, insiders, or employees. - -- Gaming is defined as any product, process, or service that mines or earns HNT token rewards from - the Helium blockchain without providing unimpeded Helium network coverage and/or data packet - routing and throughput. For example, methods to spoof RSSI levels or attenuate RF signal - propagation with the objective of faking network coverage are considered gaming. - - Manufacturers will be held accountable for gaming infractions associated with the company’s - employees, partners, or insiders. - - Manufacturers shall not modify device firmware in anyways to enable or facilitate “gaming”. - - Manufacturers shall not provide services or access to proprietary technical reference material - that facilitates gaming by their customers, partners, insiders, or employees. - -### 2. Maintain Internal Controls of Swarm Keys - -Manufacturers must have and maintain internal controls and processes to ensure the integrity of the -generation and registration of the miner swarm keys consistent with their HIP-19 approved -applications for the full life cycle of their products. - -- These internal controls and processes may be subject to additional auditing if manufacturer - activity warrants it. - -### 3. Publish Order Fulfillment Process - -Manufacturers must clearly publish **on their website** their order fulfillment process, including -the priority in which orders will be fulfilled, for both direct orders and by their authorized -distributor channels. - -- Manufacturers must disclose **on their website** the monthly number of units being allocated to - employees, company insiders, and/or partners for their first 12 months of initial production. - -### 4. Publish Monthly Shipping Updates - -Manufacturers must publish **on their website** monthly shipment updates for all back-ordered -products. - -- The full terms and conditions of product sales, including the manufacturer's refund policy, must - be clearly published on the company and/or authorized distributor websites. - - Refund policy must explicitly state: - - A customer's right to receive a refund. - - How any presales funds are being used. (Only permitted after MOC approval) - - How a customer will receive their refund. - - Length of time it will take to receive. - -### 5. Communicate Product Support Plan - -Manufacturers must clearly communicate their complete product support plan **on their website** -including: - -- Mobile application(s) required for Hotspot on-boarding -- How they plan to support their Onboarding server -- The expected lifetime of free OTA updates for products - - Disclose any “premium” or fee-based features, including extending the product lifetime of OTA - updates. - -### 6. Keep Prodcut Information Up To Data - -Manufacturers must keep their Helium compatible product information up to date on their website\*\* -including: - -- Product information including: - - Model name - - Countries serviced -- User installation guides -- Links to Helium Network reference sites - - [https://status.helium.com/](https://status.helium.com/) - - [https://engineering.helium.com/](https://engineering.helium.com/) - - [https://discord.com/invite/helium](https://discord.com/invite/helium) - -### 7. Communicate and Perform Firmware and Network Updates - -The Helium blockchain and Helium Network are rapidly evolving and require frequent firmware and -network updates. - -- Manufacturers must proactively communicate **on their website** the status of their products - relative to the Helium blockchain and network including: - - OTA status - - The current firmware revision number - -### 8. Maintain Firmware - -Firmware updates must be promptly maintained by manufacturers. - -- We expect that manufacturers have an automated process by which their firmware is updated. - -### 9. Communicate HNT Acquisition Plan for Onboarding - -Manufacturers must clearly communicate **to the MCC on their HIP-19 proposal** how they intend to -obtain the HNT needed to fund onboarding. Approved Hotspot Makers are responsible for supplying Data -Credits (DCs) to the onboarding server for Hotspots they sell. - -### 10. Maintain Integrity of the Helium Network - -Manufacturers are responsible for the integrity of the network and should take care to sell only to -genuine resellers and partners. Manufacturers will be held accountable for the integrity of their -distributor/ reseller network. - -### 11. The MCC considers Dual-Mining to be a gateway/Hotspot that mines both Helium tokens and another application. - -1. Dual-Mining is only permitted so long as it does not conflict with a DeWi Network. - 1. A DeWi network is any decentralized wireless network running on a blockchain and issuing - tokens. Examples include LoRaWAN, CBRS, WiFi, etc. -2. Dual-Mining on a Hotspot, on another DeWi network in a way that is competitive with the growth of - Helium Networks is not allowed. diff --git a/docs/hotspot-makers/mobile-cbrs/5g-hardware-specification.mdx b/docs/hotspot-makers/mobile-cbrs/5g-hardware-specification.mdx deleted file mode 100644 index c61b3decf..000000000 --- a/docs/hotspot-makers/mobile-cbrs/5g-hardware-specification.mdx +++ /dev/null @@ -1,208 +0,0 @@ ---- -id: 5g-hardware-specification -title: 5G Hotspot Hardware Specification -pagination_label: 5G Hardware Specification -sidebar_label: 5G Hardware Specification -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/mobile-cbrs/5g-hardware-specification ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## 5G Hotspot Minimum Specifications - -| Component | Minimum Requirement | -| -------------- | ---------------------------------------------------------------------------------- | -| CPU | x86_64 Linux compatible, 2.42 GHz Quad Core suggested, Must be TPM 2.0 compliant\* | -| RAM | 4 GB | -| Storage | 64 GB: Both SATA and NVME SSDs are supported | -| Secure Element | Enhanced Secure Element required | -| USB 3.0 | Required for imaging process | -| Software | Rust, Python, Magma (check Magma dependencies) | - -\* FreedomFi partners only. TPM 2.0 not required for non-Freedom Fi partners - ---- - -## Security - -Helium 5G/ Mobile Hotspots must have several security features in order to participate in the Helium -network and receive network rewards. These include a secure boot process and a secure element -feature for managing the cryptographic keys which identify the Hotspot on the network. - -### Secure Boot - -Helium 5G/ Mobile Hotspots must only run authenticated firmware that has been provided by the -manufacturer. This authentication process ensures that the Hotspot can be trusted by the rest of the -network. This is especially important in the 5G network because Hotspots make observational reports -on behalf of the entire network, such as: - -- User Equipment ("UE") attachment events -- Signal strength (RSSI, RSRP, RSRQ) -- Upstream bandwidth measurements - -Observational reports are ripe for “gaming” by the Hotspot owner because they directly impact the -rewards that the Hotspot will receive. - -When designed and used correctly, a secure boot process can overcome these problems, leading to a -more resilient and trustable network. - -### Secure Boot Requirements - -To be effective, the secure boot process you propose must meet these requirements: - -- There must be a secure hardware boundary encompassing: - - A boot CPU - - A one-time programmable memory area capable of storing: - - A trusted public key (or hash of such a key) for authenticating external boot code. - - A device-unique secret key - - A cryptographic hardware element capable of public key and private key cryptography. - - An unalterable (fused or masked) boot ROM. - - A static RAM. -- The buss(es) within the secure hardware boundary must be protected. - - Activity on the bus cannot be inspected nor altered by any entity outside of the boundary. - - No outside entity shall be able to inspect the device-unique secret key in unencrypted format. - - No outside entity shall be able to alter the contents of the memory elements (SRAM, boot ROM, - OTP memory) inside the boundary. - -### Secure Update Process - -A manufacturer-controlled process encompassing: - -- The external boot code signing key (private portion). -- A process for securely managing access to the signing key to trusted employees. - ---- - -## Enhanced Secure Element - -Helium has always required a Secure Element for all Hotspots that participate in LoRaWAN (soon to be -IOT) PoC rewards. This requirement will continue with the 5G network, however, the security -requirements for 5G will be more strict than what is in place for LoRaWAN. To prevent confusion, -these new requirements are known as **Enhanced Secure Element**. - -An Enhanced Secure Element is one which performs cryptographic digital signature and shared secret -derivation (currently ECDSA & ECDH) and does so _only at the request of the verified and trusted -firmware on the Hotspot_. This requirement effectively means that the secure element must be bound -the secure boot process. - -### Enhanced Secure Element Binding - -The secure element needs to be installed in such a way that the identity (private key) inside the -element cannot be easily removable or swappable. For example, secure element placement in a socket, -PCI card, or any other device that is easily removable yet retains the private key after removal is -unacceptable. - -The secure element also should refuse to function unless it is under the control of the -manufacturer’s verified firmware. A secure element which continues to function when the firmware has -been altered or replaced is unacceptable. - -#### Enhanced Secure Elements Requirements Questionnaire - -When submitting your Hotspot design, please submit an Enhanced Secure Element amendment. The -amendment should be phrased: "HIP19 amendments for alternate security implementations" and should -answer these questions about the gateway’s private key: - -1. How is the private key loaded onto the device? (Is it generated on-device or is it imported - externally?) -2. Where is the device located when this happens? (Factory? A subsidiary? When booted by the - end-customer?) -3. What kind of non-volatile memory is used to store the private key? -4. Is the private key encrypted when it is stored in this memory? -5. If so, where is the key necessary to decrypt the encrypted private key stored? -6. Again, if the key is encrypted, does each device possess its own unique storage key, or is it - shared across all devices? -7. Again, if the key is encrypted, is there also a verification check to ensure that the key has - decrypted properly when it is loaded? -8. How is the trusted code loaded? -9. How is the code checked for authenticity when it is loaded? -10. Who in your organization has access to the keys used for signing this code? -11. Your implementation should have the ability to be updated. Please share the update method. -12. What specific signing, encryption, decryption, or verification operations can an external entity - ask the code to perform? (External entity means code _outside_ the secure element, such as, say, - the Helium “miner” process). -13. Considering the algorithms your implementation implements, are there certain operations/messages - that you are aware of that the code must never perform lest it leads to an exposure of the - private key? -14. Does the code protect against these messages/operations? -15. What side-channel attacks does your implementation work to avoid, if any? (As a reminder, - side-channel attacks extract key information from variations in timing, power, temperature, - electromagnetic fields, etc). -16. What fault-injection attacks does your implementation work to avoid, if any? (As a reminder, - fault-injection attacks include power-glitching, laser pulses, strong EM fields, etc). -17. Does the code have any entry point such that an external entity can ask for the private key - directly? -18. What steps have you taken to audit the code for quality and ensure that it performs only as - designed? -19. Do you, the developer of this code, have the ability to extract the private key of a device? -20. Will you, the developer of this code, have the ability to extract the private key of a device in - the future? - -Additionally, during the audit phase, please be prepared to provide an SDK and/or API (with header -files if in C) that exposes the two cryptographic functions that your engine performs, and the -source code to a simple program that uses this API to generate test signatures and Diffie-Hellman -key agreement. - ---- - -## Re-Auditing and Hotspot - -:::info - -A Maker should notify the Helium Foundation of any changes made to an approved Hotspot(s), even if -it does not require a re-audit or new HIP19 application. - -::: - -Indoor and Outdoor Hotspots with the same hardware layout arriving together will be audited together -(additional $500 fee). An example of this would be the same Hotspot model with the same hardware, -but one has an exterior case making it an outdoor unit. - -Different Hotspot models or indoor and outdoor Hotspots arriving at the same time with different -hardware layouts will require a separate hardware audit (additional audit fee). - -Indoor and Outdoor Hotspots arriving more than 2 weeks apart or with different hardware layouts will -be audited separately. - -### Re-Audit Requirements - -Re-audit (such as a change in model) will be required only if any of the following: - -- Change from an indoor model to an outdoor model -- CPU changes -- RAM **decreases** -- Storage **decreases** -- Change in **radio or radio location** - - No re-audit is required if one SX130x PCIe card with the same chipset is swapped for another, - such as SX1302 for SX1303. -- Change in security element -- Change in any parameter that requires regulatory recertification - ---- - -## Re-Voting on Radio Certification - -If manufacturers add additional radio certifications after the MCC's initial voting and approval -they will be invoiced for a fee of $2,000 (USD). All radio certifications must be in order prior to -the initial MCC voting process. Due to an increase in requests for Radio Certification approvals, -the MCC will only review new radio certifications once every 90 days for each manufacturer. - -Fees can also be reviewed -[here](https://github.com/dewi-alliance/hotspot-manufacturers#fees-in-usd-updated-december-2021). - ---- - -## Radio Certifications for China - -The MCC has voted (December 2021) to require radio certifications for China. Manufacturers will need -to provide radio certifications to be approved to sell in China. **Previously approved Hotspots will -have until May 1, 2022 to send in their radio certifications for China.** If radio certifications -are not provided by this date manufacturers will no longer be approved to sell to China. - ---- - -## Trusted Platform Module (TPM) reading - -- [TPM overview](https://www.duhocchina.com/wiki/en/Trusted_Platform_Module) -- [TPM wiki](https://wiki.archlinux.org/title/Trusted_Platform_Module) diff --git a/docs/hotspot-makers/mobile-cbrs/5g-hotspot-requirements.mdx b/docs/hotspot-makers/mobile-cbrs/5g-hotspot-requirements.mdx deleted file mode 100644 index 3900c8761..000000000 --- a/docs/hotspot-makers/mobile-cbrs/5g-hotspot-requirements.mdx +++ /dev/null @@ -1,166 +0,0 @@ ---- -id: 5g-hotspot-requirements -title: 5G Hotspot Requirements -pagination_label: 5G Hotspot Requirements -sidebar_label: 5G Hotspot Requirements -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/mobile-cbrs/5g-hotspot-requirements ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::info - -This document is the Hardware Audit procedure for 5G/CBRS Hotspots which have a FreedomFi -whitelabel. - -::: - -## Certification Process - -Certification will require two steps, both performed by the -[Manufacturing Compliance Committee](/hotspot-makers/compliance-committee) ("MCC"). - -1. Functional Certification. -2. System Certification. - -### Audit Process - -- Indoor and Outdoor Hotspots arriving together will be audited together. -- Indoor and Outdoor Hotspots arriving more than 2 weeks apart will be audited separately. -- Re-audit (such as change in model) required only if any of the following: - - CPU changes. - - RAM decreases. - - Storage decreases. - - Change in radio. - - Change in security element. - - Change in any parameter that requires regulatory recertification. - ---- - -## Functional Certification - -### Section 1: Hardware Unboxing and Review - -- Provide directions for how to change Orc8r to FreedomFi's Orc8r or give Foundation ssh access. -- Record date of audit. -- Record Model name and serial number. -- Link to vendor provided documentation. -- Link to HIP-19 proposal on Github. -- Link to Vendor website. -- List expected certifications (for CBRS, only FCC is relevant). -- Check antenna connector, must be reverse SMA. -- Unbox hardware and list what has been received (number received, Indoor/Outdoor). -- Record block diagram of system including the secure boot hardware: - - The diagrams should include all the hardware involved in the boot process and the security - boundaries of each component. - - Hardware items to illustrate include (but are not limited to): - - Cryptographic hardware accelerator - - Secure storage for private/secret and public keys - - Secure RAM - - Boot ROM - - Untrusted external RAM - - Untrusted external non-volatile storage (eMMC, SATA, etc) - - Communication busses - - The diagram must also show the security boundaries of your design. Group each component and bus - by the boundary it resides in. - - Image of PCB with secure security element clearly outlined - -### Section 2: Hardware Specifications - -- Does the hardware meet the specifications. -- Is the hardware the same in the HIP-19 application and on the manufacturer's website as what was - sent for the audit? -- Auditor may run one or more of the following to check hardware: - - Inspect CPU: `cat /proc/cpuinfo` - - Check memory: `free --mega` - - Check storage: `lsblk` - -### Section 3: Verify Secure Element Configuration - -Purpose of this section is to verify that the key is secure - -- Check firmware version is up to date: `sudo docker exec helium_miner_1 miner versions` - - _NOTE: In FreedomFi’s firmware, it is necessary to keep the miner image running when attempting - to run`gateway_mfr`. This is because the miner image has a helper daemon that `gateway_mfr` - needs to contact in order to “talk” to the TPM._ -- Query the Miner for its working keys/ verify that private and public are the same: - `sudo docker exec helium_miner_1 miner print_keys` -- Download the Miner from Helium's repo -- Query the TPM for its keys: - `docker exec helium_miner_1 /gateway_mfr --device "tpm://tpm/HS/SRK/MinerKey" test` to verify keys - match. - -### Section 4: RF Verification - -- Verify Manufacturue has RF Verification. -- Check US915 configuration file. - ---- - -## System Certification - -### Section 5: UE Connection To Network - -:::info Telecom Acronym - -User Equipment ("UE") refers to any device capable of connecting to the Internet, such as a phone, -tablet or computer. - -::: - -- Connect a UE Device to the CBRS network and perform activity such as downloading photos, sending - emails, and chat using Discord while using the 5G network. - - **Does the UE connect to the network and able to use it?** -- Verify that the UE is connected to the correct network by matching the IMSI and IP address: - `mobility_cli.py get_subscriber_table` - - **Is the UE connected to the expected network?** -- Verify that the UE is connected to the correct radio by matching the EARFCN and - CI:`sudo cat /var/opt/magma/configs/gateway.mconfig` - - Check the "enodebd" section for "cellId" and "earfcndl" numbers and compare them to the numbers - in Carrier Lab Dashboard (app for iOS) and/or About Phone in Android. - - **Is the UE connected to the expected radio and do the EARFCN and CI match?** -- Verify attach-detach with service request for single UE, can a single UE attach and detach from - the network? - - Using wireshark: - `ssh support@IP_ADDDRESS sudo tcpdump -i enodebr0 -U -s0 -w - 'not tcp port 22' | /Applications/Wireshark.app/Contents/MacOS/Wireshark -k -i -` - filter on sctp and put the UE in airplane mode, toggle and look for detach request - - **Is the UE able to leave and rejoin the network** - -### Section 6: Federation Gateway (FeG) and Magma connection - -- Verify that traffic is flowing through Magma rather than locally by sniffing traffic between radio - and AGW where GTP traffic is encapsulated. - - **Are source and destination IP showing 2-way traffic?** **Is there GTP traffic present?** -- Verify that traffic is flowing through the Foundation hosted Federation Gateway by looking at - messages that show that the UE's SIM card is getting checked by the Foundation's HSS. - - **Is the public IP of the Foundation hosted FeG present?** **Is the UE SIM card pointing at the - Foundation HSS?** - -### Section 7: UDP/ TCP traffic - -- Verify attach to network with uplink `UDP` data and then detach from network to show traffic - flowing inside of the GTP tunnel. - - Traffic flows from the UE to Google's DNS using `UDP`. - - Use **Wireshark** while browsing internet and filter on `udp.dstport == 53`. - - **Is traffic present in the GTP tunnel in 8.8.8.8.?** -- Verify attach to network with uplink `TCP` data and then detach from network to show traffic - flowing inside of the GTP tunnel. - - Traffic flows from the UE to Google's DNS using `TCP`. - - Use **Wireshark** while browsing internet and filter on `TCP`. - - **Is traffic present in the GTP tunnel?** - -### Section 8: UE Failure - -- Verify attach/ detach for two UEs - - Put 2 UEs into airplane mode and reconnect to internet in and out of airplane mode. - - Use **Wireshark** and filter on `sctp`. - - **Is attach/ detach messaging present?** -- Verify radio link failure for single or many UEs. - - Toggle airplane mode on UE, then leave it attached to the network (not in airplane mode) and - place it in a Faraday cage. - - This may be verified by using **Wireshark** and look for GUTI cleared/ IMEI cleared. - - This may also be verified by looking at the subscriber data with the timestamp before and after - `mobility_cli.py get_subscriber_table;date` - - **Does UE detach from network in simulated failure mode?** diff --git a/docs/mdx.md b/docs/mdx.md deleted file mode 100644 index 226fce944..000000000 --- a/docs/mdx.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: mdx -title: Using MDX ---- - -You can write JSX and use React components within your Markdown thanks to [MDX](https://mdxjs.com/). - -export const Highlight = ({children, color}) => ( {children} ); - -Docusaurus green and Facebook -blue are my favorite colors. - -I can write **Markdown** alongside my _JSX_! diff --git a/docs/network-data/api-providers.mdx b/docs/network-data/api-providers.mdx new file mode 100644 index 000000000..63a56db11 --- /dev/null +++ b/docs/network-data/api-providers.mdx @@ -0,0 +1,55 @@ +--- +id: api-providers +title: Helium API Providers +pagination_label: API Providers +sidebar_label: API Providers +description: Helium API Provider Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/api-providers +--- + +## Helium Entity API + +Helium provides a basic API for accessing high-level data about entities on the network. + +- [Entity API Documentation](/network-data/entity-api) + +## Third-Party API Providers + +Helium's open on-chain data and Oracles enable third-party API providers to offer rich, +production-grade access to network data. These providers power robust applications and services in +the Helium ecosystem. + +### HeliumGeek + +HeliumGeek delivers a production-grade Helium API that blends on-chain and off-chain intelligence +into a single, reliable service. The same endpoints that drive our mobile apps and fleet management +platform power rewards tracking, Hotspot health monitoring, performance tracking, and custom vector +map tiles with confidence, giving us hands-on insight into what Helium operators really need. + +By focusing exclusively on Helium, we absorb every protocol change and publish new data the moment +it becomes available. Customers and clients lean on us for live dashboards and community explorers +because we operate the API around the clock, bolster it with proactive monitoring, and back it with +a track record of accuracy and stability that has supported the ecosystem since 2021. + +Flexible paid plans align with deployments ranging from boutique operations to nationwide fleets, +ensuring the infrastructure scales without sacrificing responsiveness or support. Our independent +funding model keeps the platform sustainable, while we still extend complimentary access to research +collaborations and other strategic partners that benefit the broader Helium community. + +- Website: [https://https://heliumgeek.com/api](https://https://heliumgeek.com/api/) +- API Documentation: [https://docs.heliumgeek.com](https://docs.heliumgeek.com) + +### Relay + +Relay API provides an easy access to all Helium Oracle, on-chain, and historical data via simple +REST endpoints. The API is public and free to use with the Community plan, sponsored by Helium +Foundation. Community can get instant access to data like Hotspot earnings, Hotspot information, +mobile data offload, and much more. + +Relay API also provides paid plans to help support users who are looking to access data at scale. +Paid plans offer higher monthly API call limits, premium features, and allow to fetch all historical +data, including from Helium L1. + +- Website: [https://www.relaywireless.com](https://www.relaywireless.com) +- API Documentation: [https://docs.relaywireless.com](https://docs.relaywireless.com) diff --git a/docs/network-data/entity-api.mdx b/docs/network-data/entity-api.mdx new file mode 100644 index 000000000..2343ffed6 --- /dev/null +++ b/docs/network-data/entity-api.mdx @@ -0,0 +1,692 @@ +--- +id: entity-api +title: Entity API Documentation +pagination_label: Entity API +sidebar_label: Entity API +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/entity-api +--- + +import Tabs from '@theme/Tabs' +import TabItem from '@theme/TabItem' + +# Entity API + +The Entity API is provided free of charge by Helium. The data provided focuses on infrequently +changing attributes of Hotspots such as their owner and asserted location. This API is provided +without any guarantees of uptime or support, and is intended for light use cases.For more in-depth +analysis, refer to [Oracles](/network-data/oracle-data) and +[Solana on-chain data](/network-data/solana-data). + +In the interest of anonymity, the latitude/longitude data provided by the API is obfuscated to +[H3](https://h3geo.org/docs/core-library/restable/) resolution 8 rather than resolution 12 stored +on-chain on Solana. + +:::note Active/Inactive Status + +Active or Inactive status is deprecated for this API and will return `false` for all Hotspots on all +routes. + +::: + +## Wallet Info by Wallet Public Key + +``` +GET https://entities.nft.helium.io/v2/wallet/:walletPublicKey +``` + +Get wallet information by wallet public key including Hotspot count, list of Hotspot records, and +token account balances. + + + + +`Path Parameters` + +| Param | Type | Note | +| ---------------------------- | -------- | ---------------------------------------- | +| Wallet public key (required) | _string_ | Solana public key/address for the wallet | + + + + +`200: OK` + +```json +{ + "hotspots_count": 1, + "hotspots": [ + { + "name": "string", + "description": "string", + "image": "string", + "asset_id": "string", + "key_to_asset_key": "string", + "entity_key_b64": "string", + "key_serialization": "string", + "entity_key_str": "string", + "hotspot_infos": { + "iot": { + "address": "string", // Solana address + "street": "string", + "city": "string", + "state": "string", + "country": "string", + "is_active": "boolean", //Deprecated, always false + "location": "string", // Obfuscated + "dc_onboarding_fee_paid": "string", + "elevation": 0, + "gain": 0, + "created_at": "string", + "asset": "string", + "lat": 0, // Obfuscated + "long": 0 // Obfuscated + }, + "mobile": { + "location": null + } + }, + "attributes": [ + { + "trait_type": "ecc_compact", + "value": "string" + }, + { + "trait_type": "entity_key_string", + "value": "string" + }, + { + "trait_type": "entity_key", + "value": "string" + }, + { + "trait_type": "rewardable", + "value": "boolean" + }, + { + "trait_type": "networks", + "value": ["string"] + }, + { + "trait_type": "iot_city", + "value": "string" + }, + { + "trait_type": "iot_state", + "value": "string" + }, + { + "trait_type": "iot_country", + "value": "string" + }, + { + "trait_type": "iot_lat", // Obfuscated + "value": 0 + }, + { + "trait_type": "iot_long", // Obfuscated + "value": 0 + } + ] + } + ], + "balances": [ + { + "mint": "hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux", + "balance": "0" + }, + { + "mint": "mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6", + "balance": "0" + }, + { + "mint": "iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns", + "balance": "0" + }, + { + "mint": "dcuc8Amr83Wz27ZkQ2K9NS6r8zRpf1J6cvArEBDZDmm", + "balance": "0" + } + ] +} +``` + +`500: Error` + +```json +{ + "statusCode": 500, + "error": "Internal Server Error", + "message": "string" +} +``` + + + + +## Hotspot Pagination Metadata + +``` +GET https://entities.nft.helium.io/v2/hotspots/pagination-metadata?subnetwork= +``` + +Get general information about the pagination of Hotspots in a particular subnetwork including +pagination page size, total number of Hotspots, and total number of pages. + + + + +`Query Parameters` + +| Param | Type | Note | +| --------------------- | -------- | ------------------------------------- | +| Subnetwork (required) | _string_ | Name of subnetwork (iot, mobile, etc) | + + + + +`200: OK` + +```json +{ + "pageSize": 0, + "totalItems": 0, + "totalPages": 0 +} +``` + +`400: Error` + +```json +{ + "statusCode": 400, + "error": "Bad Request", + "message": "string" +} +``` + +`500: Error` + +```json +{ + "statusCode": 500, + "error": "Internal Server Error", + "message": "string" +} +``` + + + + +## List Hotspots by Subnetwork + +``` +GET https://entities.nft.helium.io/v2/hotspots?subnetwork=&cursor= +``` + +Get a list of key-value pairs denoting Hotspots in a particular subnetwork. If the returned `cursor` +field is a non-null value, more results are available. If no cursor is provided (e.g., if the URL +does not include the `&cursor=` query string component), then the first page of results is +returned along with a cursor value for the subsequent page. + + + + +`Query Parameters` + +| Param | Type | Note | +| --------------------- | -------- | --------------------------------------------- | +| Subnetwork (required) | _string_ | Name of subnetwork (iot, mobile, etc.) | +| Cursor (optional) | _string_ | Cursor for the next page of Hotspots to fetch | + + + + +`200: OK` + +```json +{ + "cursor": "string", // Or null if there are no more Hotspots to fetch + "items": [ + { + "key_to_asset_key": "string", + "entity_key_str": "string", + "is_active": "boolean", //Deprecated, always false + "lat": 0, + "long": 0 + }, + { + "key_to_asset_key": "string", + "entity_key_str": "string", + "is_active": "boolean", //Deprecated, always false + "lat": 0, + "long": 0 + }, + { + "key_to_asset_key": "string", + "entity_key_str": "string", + "is_active": "boolean", //Deprecated, always false + "lat": 0, + "long": 0 + } + ] +} +``` + +`400: Error` + +```json +{ + "statusCode": 400, + "error": "Bad Request", + "message": "string" +} +``` + +`500: Error` + +```json +{ + "statusCode": 500, + "error": "Internal Server Error", + "message": "string" +} +``` + + + + +## Hotspot Info by Key to Asset Key + +``` +GET https://entities.nft.helium.io/v1/:keyToAssetKey +``` + +``` +GET https://entities.nft.helium.io/v2/hotspot/:keyToAssetKey +``` + +Get Hotspot records based on the key to asset value. Both the `/v1` and `/v2/hotspot` routes return +identical results and are merely provided for backward compatibility. + + + + +`Path Parameters` + +| Param | Type | Note | +| ----------------------- | -------- | -------------------------------------------- | +| Key to asset (required) | _string_ | Public key of on-chain `KeyToAssetV0` struct | + + + + +`200: OK` + +```json +{ + "name": "string", + "description": "string", + "image": "string", + "asset_id": "string", + "key_to_asset_key": "string", + "entity_key_b64": "string", + "key_serialization": "string", + "entity_key_str": "string", + "hotspot_infos": { + "iot": { + "address": "string", // Solana address + "street": "string", + "city": "string", + "state": "string", + "country": "string", + "is_active": "boolean", // Deprecated, always false + "location": "string", // Obfuscated + "dc_onboarding_fee_paid": "string", + "elevation": 0, + "gain": 0, + "created_at": "string", + "asset": "string", + "lat": 0, // Obfuscated + "long": 0 // Obfuscated + }, + "mobile": { + "location": null + } + }, + "attributes": [ + { + "trait_type": "ecc_compact", + "value": "string" + }, + { + "trait_type": "entity_key_string", + "value": "string" + }, + { + "trait_type": "entity_key", + "value": "string" + }, + { + "trait_type": "rewardable", + "value": "boolean" + }, + { + "trait_type": "networks", + "value": ["string"] + }, + { + "trait_type": "iot_city", + "value": "string" + }, + { + "trait_type": "iot_state", + "value": "string" + }, + { + "trait_type": "iot_country", + "value": "string" + }, + { + "trait_type": "iot_lat", // Obfuscated + "value": 0 + }, + { + "trait_type": "iot_long", // Obfuscated + "value": 0 + } + ] +} +``` + +`404: Error` + +```json +{ + "statusCode": 404, + "error": "Not Found", + "message": "string" +} +``` + +`500: Error` + +```json +{ + "statusCode": 500, + "error": "Internal Server Error", + "message": "string" +} +``` + + + + +## Hotspot Info by Entity/ECC Compact Key + +``` +GET https://entities.nft.helium.io/:eccCompact +``` + +Get Hotspot records based on the entity / ECC compact key value. + + + + +`Path Parameters` + +| Param | Type | Note | +| ------------------------ | -------- | --------------------------------------- | +| Entity / ECC compact key | _string_ | Legacy Helium L1 address of the Hotspot | + + + + +`200: OK` + +```json +{ + "name": "string", + "description": "string", + "image": "string", + "asset_id": "string", + "key_to_asset_key": "string", + "entity_key_b64": "string", + "key_serialization": "string", + "entity_key_str": "string", + "hotspot_infos": { + "iot": { + "address": "string", // Solana address + "street": "string", + "city": "string", + "state": "string", + "country": "string", + "is_active": "boolean", // Deprecated, always false + "location": "string", // Obfuscated + "dc_onboarding_fee_paid": "string", + "elevation": 0, + "gain": 0, + "created_at": "string", + "asset": "string", + "lat": 0, // Obfuscated + "long": 0 // Obfuscated + }, + "mobile": { + "location": null + } + }, + "attributes": [ + { + "trait_type": "ecc_compact", + "value": "string" + }, + { + "trait_type": "entity_key_string", + "value": "string" + }, + { + "trait_type": "entity_key", + "value": "string" + }, + { + "trait_type": "rewardable", + "value": "boolean" + }, + { + "trait_type": "networks", + "value": ["string"] + }, + { + "trait_type": "iot_city", + "value": "string" + }, + { + "trait_type": "iot_state", + "value": "string" + }, + { + "trait_type": "iot_country", + "value": "string" + }, + { + "trait_type": "iot_lat", // Obfuscated + "value": 0 + }, + { + "trait_type": "iot_long", // Obfuscated + "value": 0 + } + ] +} +``` + +`404: Error` + +```json +{ + "statusCode": 404, + "error": "Not Found", + "message": "string" +} +``` + +`500: Error` + +```json +{ + "statusCode": 500, + "error": "Internal Server Error", + "message": "string" +} +``` + + + + +## List OUI Organization Info + +``` +GET https://entities.nft.helium.io/v2/oui/all +``` + +Get a list of OUIs registered on the Helium Network and corresponding organization info. + + + + +`200: OK` + +```json +{ + "orgs": [ + { + "oui": 1, + "owner": "string", // Org admin key + "payer": "string", // Key only used for DC payments + "escrow": "string", // Escrow account key + "delegate_keys": [ + // List of keys allowed some specific actions, see services. + "string" + ], + "locked": "boolean" // Is org locked because of no payment + }, + { + "oui": 2, + "owner": "string", + "payer": "string", + "escrow": "string", + "delegate_keys": ["string"], + "locked": "boolean" + }, + { + "oui": 3, + "owner": "string", + "payer": "string", + "escrow": "string", + "delegate_keys": ["string"], + "locked": "boolean" + } + ] +} +``` + +`500: Error` + +```json +{ + "statusCode": 500, + "error": "Internal Server Error", + "message": "string" +} +``` + + + + +## OUI Organization Info by OUI ID + +``` +GET https://entities.nft.helium.io/v2/oui/:id +``` + +Get an OUI registered on the Helium Network and corresponding organization info by the OUI ID. + + + + +`Path Parameters` + +| Param | Type | Note | +| ----------------- | -------- | ---------------------------------------- | +| OUI ID (required) | _string_ | ID of the OUI (e.g., 1) for getting info | + + + + +`200: OK` + +```json +{ + "oui": 1, // OUI ID + "owner": "string", // Org admin key + "payer": "string", // Key only used for DC payments + "escrow": "string", // Escrow account key + "delegate_keys": [ + // List of keys allowed some specific actions, see services. + "string" + ], + "locked": "boolean" // Is org locked because of no payment +} +``` + +`400: Error` + +```json +{ + "statusCode": 400, + "error": "Bad Request", + "message": "string" +} +``` + +`500: Error` + +```json +{ + "statusCode": 500, + "error": "Internal Server Error", + "message": "string" +} +``` + + + diff --git a/docs/network-data/legacy-blockchain-data.mdx b/docs/network-data/legacy-blockchain-data.mdx new file mode 100644 index 000000000..a380bcf6e --- /dev/null +++ b/docs/network-data/legacy-blockchain-data.mdx @@ -0,0 +1,24 @@ +--- +id: legacy-blockchain-data +title: Legacy Blockchain Data +pagination_label: Legacy Blockchain Data +sidebar_label: Legacy Blockchain Data +description: Legacy Blockchain Data Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/legacy-blockchain-data +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +Helium initially operated on its own custom L1 blockchain. On April 18, 2023, Helium completed a +migration to the Solana. + +A snapshot of the Helium L1 data is available on a requestor-pays basis on AWS in the +`foundation-prod-etl-artifacts-v2` S3 bucket. + +Additionally, the snapshot is also available as a torrent. + +| Torrent | Magnet Link | +| ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [Helium L1 Archive - Postgres Snapshot](/helium-l1-archive-postgres.torrent) (3.1 TB) | [Magnet Link](magnet:?xt=urn:btih:ac508205c440ac66d18d2f1755a7eb682a6c6549&dn=foundation-prod-etl-artifacts-v2&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.auctor.tv%3A6969%2Fannounce&tr=udp%3A%2F%2Fopentracker.i2p.rocks%3A6969%2Fannounce&tr=https%3A%2F%2Fopentracker.i2p.rocks%3A443%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A6969%2Fannounce&tr=http%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.moeking.me%3A6969%2Fannounce&tr=udp%3A%2F%2Fexodus.desync.com%3A6969%2Fannounce&tr=udp%3A%2F%2Fuploads.gamecoast.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.tiny-vps.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker-udp.gbitt.info%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.ink%3A6969%2Fannounce&tr=udp%3A%2F%2Fmovies.zsw.ca%3A6969%2Fannounce&tr=udp%3A%2F%2Fbt1.archive.org%3A6969%2Fannounce&tr=https%3A%2F%2Ftracker.tamersunion.org%3A443%2Fannounce&tr=https%3A%2F%2Ftracker.gbitt.info%3A443%2Fannounce) | +| [Helium L1 Transactions & Blocks - CSV Export](/Helium_Txns_Archive.torrent) (724 GB) | [Magnet Link](magnet:?xt=urn:btih:090ff75cd0a834818c46f5a48483f45b37ac0199&dn=HeliumTxns&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.ink%3A6969%2Fannounce&tr=http%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.auctor.tv%3A6969%2Fannounce&tr=udp%3A%2F%2Fopentracker.i2p.rocks%3A6969%2Fannounce&tr=https%3A%2F%2Fopentracker.i2p.rocks%3A443%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.moeking.me%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexodus.desync.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker-udp.gbitt.info%3A80%2Fannounce&tr=https%3A%2F%2Ftracker.tamersunion.org%3A443%2Fannounce&tr=https%3A%2F%2Ftracker.gbitt.info%3A443%2Fannounce&tr=http%3A%2F%2Ftracker.gbitt.info%3A80%2Fannounce&tr=udp%3A%2F%2Fuploads.gamecoast.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.tiny-vps.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce&tr=udp%3A%2F%2Fretracker01-msk-virt.corbina.net%3A80%2Fannounce&tr=udp%3A%2F%2Fopentracker.io%3A6969%2Fannounce) | diff --git a/docs/network-data/network-data.mdx b/docs/network-data/network-data.mdx new file mode 100644 index 000000000..1034148e6 --- /dev/null +++ b/docs/network-data/network-data.mdx @@ -0,0 +1,34 @@ +--- +id: network-data +title: Helium Network Data +pagination_label: Network Data +sidebar_label: Introduction +description: Helium Network Data Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/network-data +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +The Helium Network operates a hybrid architecture, combining on-chain data stored on the Solana +blockchain with data stored in network Oracles. + +On-chain data includes information about Hotspots, wallet and account state, tokens, and other +attributes that pertain to the Helium Network. + +Oracles store additional network data that is not practical to store on-chain, such as Hotspot +earnings, witness data, and other time-series information. + +Review the relevant documents for a deeper dive into each data source: + +- [Solana Data](/network-data/solana-data) +- [Oracles](/network-data/oracle-data) + +In addition to the raw data sources, Helium and third-party providers offer APIs that provide +convenient access to network data: + +- [Helium API Providers](/network-data/api-providers) + +Data from Helium's legacy blockchain (Helium L1) is also available for historical reference: + +- [Legacy Blockchain Data](/network-data/legacy-blockchain-data) diff --git a/docs/network-data/oracle-data.mdx b/docs/network-data/oracle-data.mdx new file mode 100644 index 000000000..b7848ddfb --- /dev/null +++ b/docs/network-data/oracle-data.mdx @@ -0,0 +1,242 @@ +--- +id: oracle-data +title: Helium Oracle Data +pagination_label: Oracle Data +sidebar_label: Oracle Data +description: Helium Oracle Data Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/oracle-data +--- + +The Helium Network operates Oracles that perform various tasks backing Proof-of-Coverage and data +transfer for the LoRaWAN (IOT), Mobile, and any future networks. These Oracles provide extensive +logs for analysis of the Helium subnetworks. + +The Helium Oracles handle all data about the network, except for transactions handled by the +[Helium Program Libraries](https://github.com/helium/helium-program-library) on Solana. + +## Accessing Oracle Data + +Data is directly accessible from the `foundation-poc-data-requester-pays` bucket in AWS `us-west-2` +under the top-level data category prefixes listed below. All data in the S3 bucket uses 'Requestor +Pays', meaning you pay for data transfer and AWS API costs. Amazon will charge you for: + +1. Storage costs on any destination buckets +2. Egress fees if the data leaves `us-west-2` +3. `PUT`, `COPY`, `POST`, and `LIST` requests + +For more information on accessing data from an AWS requester pays bucket, refer to the +[Downloading objects in Requester Pays buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ObjectsinRequesterPaysBuckets.html) +guide provided by AWS. + +| Top-Level Data Category Prefixes | +| ----------------------------------- | +| `foundation-iot-entropy` | +| `foundation-iot-ingest` | +| `foundation-iot-packet-ingest` | +| `foundation-iot-packet-verifier` | +| `foundation-iot-verified-rewards` | +| `foundation-mobile-ingest` | +| `foundation-mobile-packet-verifier` | +| `foundation-mobile-price` | +| `foundation-mobile-verified` | + +Under each top-level data category prefix, the related PoC data files are provided in the prefix +structure noted below: + +`s3://foundation-poc-data-requester-pays//..gz` + +When working with this bucket, keeping data in `us-west-2` and being pragmatic about which AWS S3 +access patterns are used will greatly reduce the cost burden for accessing the PoC data. + +Regarding access patterns, one approach to minimize the quantity of S3 API calls over time - and +save money - is to use the `aws s3api list-objects-v2` command and specify the `--start-after` and +`--prefix` parameters. In particular, the `aws s3api list-objects-v2` command can be invoked +iteratively over time with the `--start-after` parameter set to the +`top-level data category prefix` + `filename` of the last file received and the `--prefix` parameter +set to the `top-level data category` + `file prefix` of desired file, as indicated below: + +```bash +aws s3api list-objects-v2 --bucket foundation-poc-data-requester-pays --start-after --prefix --request-payer requester +``` + +For example, if you were to execute the `aws s3api list-objects-v2` command against a `foo` prefix +of an `example` bucket, and the most recent file you received was `bar.1681917512317.gz`, in a +subsequent invocation of `aws s3api list-objects-v2` you could set the `--start-after` flag to +`foo/bar.1681917512317.gz` and the `--prefix` flag to `foo/bar` to return a list of `bar` type files +subsequent to `bar.1681917512317.gz`. In doing so, your total API calls in the second invocation of +`aws s3api list-objects-v2` would be limited to only the files subsequent to `bar.1681917512317.gz`, +rather than for all files in the bucket. From there, you can iterate over the returned list of files +and perform additional S3 API commands such as `aws s3api copy-object` to copy files based on the +file list. + +## Oracle Data File Format + +The raw PoC data stored in the `foundation-poc-data-requester-pays` bucket is in encoded protobuf +format in `.gz` compressed files. The table below provides the top-level data category prefixes, the +file types comprised within each data category prefix, the file prefixes beginning each filename, +the filename patterns for each of the file types, and links to the corresponding protobuf used to +decode the data. + +| Category | File Type | File Prefix | Filename | Protobuf Definition | +| :---------------------------------- | :--------------------------------------- | :-------------------------------------------- | :------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `foundation-iot-entropy` | `EntropyReport` | `entropy_report` | `entropy_report..gz` | [`entropy.proto`
(Line 5: `entropy_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/entropy.proto#L5) | +| `foundation-iot-ingest` | `IotBeaconIngestReport` | `iot_beacon_ingest_report` | `iot_beacon_ingest_report..gz` | [`service/poc_lora.proto`
(Line 97: `lora_beacon_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L97) | +| `foundation-iot-ingest` | `IotWitnessIngestReport` | `iot_witness_ingest_report` | `iot_witness_ingest_report..gz` | [`service/poc_lora.proto`
(Line 104: `lora_witness_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L104) | +| `foundation-iot-packet-ingest` | `PacketReport` | `packetreport` | `packetreport..gz` | [`service/packet_router.proto`
(Line 8: `packet_router_packet_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_router.proto#L8) | +| `foundation-iot-packet-verifier` | `InvalidPacket` | `invalid_packet` | `invalid_packet..gz` | [`service/packet_verifier.proto`
(Line 13: `invalid_packet`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_verifier.proto#L13) | +| `foundation-iot-packet-verifier` | `IotValidPacket` | `iot_valid_packet` | `iot_valid_packet..gz` | [`service/packet_verifier.proto`
(Line 5: `valid_packet`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_verifier.proto#L5) | +| `foundation-iot-verified-rewards` | `IotRewardShare` | `iot_reward_share` | `iot_reward_share..gz` | [`service/poc_lora.proto`
(Line 239: `iot_reward_share`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L239) | +| `foundation-iot-verified-rewards` | `IotPoc` | `iot_poc` | `iot_poc..gz` | [`service/poc_lora.proto`
(Line 216: `lora_poc_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L216) | +| `foundation-iot-verified-rewards` | `IotInvalidBeaconReport` | `iot_invalid_beacon` | `iot_invalid_beacon..gz` | [`service/poc_lora.proto`
(Line 153: `lora_invalid_beacon_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L153) | +| `foundation-iot-verified-rewards` | `IotInvalidWitnessReport` | `iot_invalid_witness` | `iot_invalid_witness..gz` | [`service/poc_lora.proto`
(Line 173: `lora_invalid_witness_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L173) | +| `foundation-iot-verified-rewards` | `GatewayRewardShare` | `gateway_reward_share`(Deprecated 4/18/23) | `gateway_reward_share..gz` | [`service/poc_lora.proto`
(Line 171: `gateway_reward_share`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L171) | +| `foundation-iot-verified-rewards` | `RewardManifest` | `reward_manifest` | `reward_manifest..gz` | [`reward_manifest.proto`
(Line 5: `reward_manifest`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/reward_manifest.proto#L5) | +| `foundation-iot-verified-rewards` | `NonRewardablePacket` | `non_rewardable_packet` | `non_rewardable_packet..gz` | [`service/poc_lora.proto`
(Line 47: `non_rewardable_packet`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L47) | +| `foundation-mobile-ingest` | `CellHeartbeatIngestReport` | `cell_heartbeat` | `cell_heartbeat..gz` | [`service/poc_mobile.proto`
(Line 65: `cell_heartbeat_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L65) | +| `foundation-mobile-ingest` | `CellSpeedtestIngestReport` | `cell_speedtest` | `cell_speedtest..gz` | [`service/poc_mobile.proto`
(Line 25: `speedtest_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L25) | +| `foundation-mobile-ingest` | `DataTransferSessionIngestReport` | `data_transfer_session_ingest_report` | `data_transfer_session_ingest_report..gz` | [`service/poc_mobile.proto`
(Line 366: `data_transfer_session_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L366) | +| `foundation-mobile-ingest` | `Heartbeat` | `heartbeat` | `heartbeat..gz` | [`service/poc_mobile.proto`
(Line 181: `heartbeat`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L181) | +| `foundation-mobile-ingest` | `SpeedtestIngestReport` | `speedtest_report` | `speedtest_report..gz` | [`service/poc_mobile.proto`
(Line 25: `speedtest_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L25) | +| `foundation-mobile-ingest` | `SubscriberLocationIngestReport` | `subscriber_location_report` | `subscriber_location_report..gz` | [`service/poc_mobile.proto`
(Line 92: `subscriber_location_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L92) | +| `foundation-mobile-packet-verifier` | `InvalidDataTransferSessionIngestReport` | `invalid_data_transfer_session_ingest_report` | `invalid_data_transfer_session_ingest_report..gz` | [`service/poc_mobile.proto`
(Line 372: `invalid_data_transfer_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L372) | +| `foundation-mobile-packet-verifier` | `ValidDataTransferSession` | `valid_data_transfer_session` | `valid_data_transfer_session..gz` | [`service/packet_verifier.proto`
(Line 24: `valid_data_transfer_session`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_verifier.proto#L24) | +| `foundation-mobile-price` | `PriceReport` | `price_report` | `price_report..gz` | [`price_report.proto`
(Line 7: `price_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/price_report.proto#L7) | +| `foundation-mobile-verified` | `ValidatedHeartbeat` | `validated_heartbeat` | `validated_heartbeat..gz` | [`service/poc_mobile.proto`
(Line 181: `heartbeat`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L181) | +| `foundation-mobile-verified` | `SpeedtestAvg` | `speedtest_avg` | `speedtest_avg..gz` | [`service/poc_mobile.proto`
(Line L226: `speedtest_avg`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L226) | +| `foundation-mobile-verified` | `VerifiedSpeedtest` | `verified_speedtest` | `verified_speedtest..gz` | [`service/poc_mobile.proto`
(Line L36: `verified_speedtest`)](https://github.com/helium/proto/blob/6cfd6dc952349e31187c7071dbbcd86780eb97e6/src/service/poc_mobile.proto#L36) | +| `foundation-mobile-verified` | `VerifiedSubscriberLocationIngestReport` | `verified_subscriber_location_report` | `verified_subscriber_location_report..gz` | [`service/poc_mobile.proto`
(Line 140: `verified_subscriber_location_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L140) | +| `foundation-mobile-verified` | `RadioRewardShare` | `radio_reward_share` | `radio_reward_share..gz` | [`service/poc_mobile.proto`
(Line 247: `radio_reward_share`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L247) | +| `foundation-mobile-verified` | `MobileRewardShare` | `mobile_reward_share` | `mobile_reward_share..gz` | [`service/poc_mobile.proto`
(Line 295: `mobile_reward_share`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L295) | +| `foundation-mobile-verified` | `RewardManifest` | `reward_manifest` | `reward_manifest..gz` | [`reward_manifest.proto`
(Line 5: `reward_manifest`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/reward_manifest.proto#L5) | +| `foundation-mobile-verified` | `SubnetworkRewards` | `subnetwork_rewards` | `subnetwork_rewards..gz` | [`blockchain_txn_subnetwork_rewards_v1.proto`
(Line 11: `subnetwork_rewards`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/blockchain_txn_subnetwork_rewards_v1.proto#L11) | +| `foundation-mobile-verified` | `InvalidShares` | `invalid_shares` | `invalid_shares..gz` | | +| `foundation-mobile-verified` | `Shares` | `shares` | `shares..gz` | | + +## Reading Bytestream Data + +To store the massive amount of data generated by the Oracles, the output is stored as zipped +bytestreams (one bytestream per `.gz` file). To 'unpack' this data, you'll first need the associated +Protobuf from [github.com/helium/proto](https://github.com/helium/proto) (also listed above). + +Once uncompressed, the file is a series of 4-byte prefix length encoded binary followed by the +associated message. More concretely, you'll need to repeatedly read the first 4 bytes and decode +that as a big-endian u32. Then use that u32 number as the number of subsequent bytes to read. Decode +those subsequent bytes using the associated proto definition. Repeat this process until you've read +the entire file. + +**Important Note:** Simply trying to pass the contents of the uncompressed files into the protobuf +decoder will fail. + +### Javascript Example + +```protobuf +// poc_mobile.proto +// copied from https://github.com/helium/proto/blob/master/src/service/poc_mobile.proto#L31 + +syntax = "proto3"; + +package helium.poc_mobile; + +message cell_heartbeat_req_v1 { + // Public key of the hotspot + bytes pub_key = 1; + string hotspot_type = 2; + uint32 cell_id = 3; + // Timestamp of heartbeat in seconds from unix epoch + uint64 timestamp = 4; + double lat = 5; + double lon = 6; + bool operation_mode = 7; + string cbsd_category = 8; + string cbsd_id = 9; + + bytes signature = 10; +} +``` + +```js +// oracle-data-reader-example.js + +// assumes you've downloaded and unzipped the below file +const fileBuffer = fs.readFileSync('./cell_heartbeat.1667919103443') + +protobuf.load('mobile.proto', function (err, root) { + if (err) throw err + + // Obtain a message type + var CellHeartbeat = root.lookupType('helium.poc_mobile.cell_heartbeat_req_v1') + + let offset = 0 + while (offset < fileBuffer.length) { + // the first 4 bytes tell you how long the message is + const messageLength = fileBuffer.readInt32BE(offset) + const bufferMessage = fileBuffer.subarray(offset + 4, offset + messageLength + 4) + try { + var decodedMessage = CellHeartbeat.decode(bufferMessage) + console.log(decodedMessage) + } catch (e) { + console.log('error', e) + } + offset += messageLength + 4 + } +}) +``` + +### Rust Example + +This leverages existing Rust dependencies used by the Oracles. + +```toml +# Cargo.toml +[package] +name = "oracle-data-reader-example" +version = "0.1.0" +edition = "2021" + +[dependencies] +anyhow = {version = "1", features = ["backtrace"]} +file-store = {git = "https://github.com/helium/oracles", branch = "main"} +futures = "*" +serde = {version = "1", features=["derive"]} +serde_json = "1" +tokio = { version = "1", default-features = false, features = [ + "fs", + "macros", + "signal", + "rt-multi-thread", + "rt", + "process", + "time" +] } +tokio-util = "0" +``` + +```rust +# main.rs +use anyhow::Result; +use file_store::{heartbeat::CellHeartbeat, traits::MsgDecode, file_source}; +use futures::{ StreamExt}; +use serde_json::json; + +fn print_json(value: &T) -> Result<()> { + println!("{}", serde_json::to_string_pretty(value)?); + Ok(()) +} + +#[tokio::main] +async fn main() -> Result<()> { + // assumes you have cell_heartbeat.1667919103443.gz in folder + let mut file_stream = file_source::source(["cell_heartbeat.1667919103443.gz"]); + + while let Some(result) = file_stream.next().await { + let msg = result?; + let heartbeat = CellHeartbeat::decode(msg)?; + print_json(&json!(heartbeat))?; + } + Ok(()) +} +``` + +A more fleshed-out example can be found in +[this sample oracle observer repo](https://github.com/dewi-alliance/oracle-observer-sample/tree/main/oracle-ingestor-lambda). diff --git a/docs/network-data/solana-data.mdx b/docs/network-data/solana-data.mdx new file mode 100644 index 000000000..c7be07bf6 --- /dev/null +++ b/docs/network-data/solana-data.mdx @@ -0,0 +1,326 @@ +--- +id: solana-data +title: Helium Data on Solana +pagination_label: Solana Data +sidebar_label: Solana Data +description: Helium Data on Solana Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/solana-data +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + + +This guide exists to give an overview of Helium data on Solana, and some general Solana programming +semantics. For a more in-depth guide, check out +[The Solana Cookbook](https://solanacookbook.com/core-concepts/accounts.html) + +## Reading Data + +At its core, Solana is just a giant Key/Value store. A public key is the key, and there's some blob +of data at that value. That blob of data is called an Account. You can imagine Public Keys like a +primary key in a traditional database. + +For example, let's consider this public key: `6r4x69WHPPDzUuMpJ7vwSUiU6e73KJqeoPyZ8nHQTmFP` + +If we check the +[Solana Explorer, under Anchor Data](https://explorer.solana.com/address/6r4x69WHPPDzUuMpJ7vwSUiU6e73KJqeoPyZ8nHQTmFP/anchor-account?cluster=devnet) +for this account, we can see that this is a `DaoV0` on the devnet `helium-sub-daos` contract. + +![Dao in Explorer](/img/solana/dao-in-explorer.png) + +Scrolling up we can see that it is, in fact, owned by the Helium subnetwork's program: + +![Program Owner](/img/solana/program-owner.png) + +This means that only the `helium-sub-daos` program can make changes to this account. On other +chains, a Program may be called a Smart Contract. Accounts are either owned by a program or owned by +the system program. An account owned by the System Program is generally either a Wallet (holding +SOL), or an account that has yet to be initialized. + +On Solana, a Wallet is just an account with some amount of SOL tokens in it, owned by the system +program. The owner of that Wallet controls the private key to that account, and so can sign +transactions as that public key. + +### PDAs + +Program Derived Addresses (PDAs) are home to accounts that are designed to be controlled by a +specific program. With PDAs, programs can programmatically sign for certain addresses without +needing a private key. PDAs serve as the foundation for Cross-Program Invocation, which allows +Solana apps to be composable with one another. + +A PDA is a Public Key that is derived from some set of seeds and a given program ID. Think of it as +a one-way hashing to a new address. So, for example, + + +```js +getProgramAddress([Buffer.from("helium", "utf8")], helium_sub_daos.programId) +``` + +will always return the same address. Better yet, the `helium_sub_daos` is able to sign transactions +as if it held the private key to this PDA. + +As you will see, the Helium programming model depends heavily on PDAs as indexes into the +blockchain. + +If you imagine the world of Helium Data on Solana as a Graph, PDAs let us hook into particular +subgraphs. + +A great example of this is the relationship between the Helium `dao` and the `hnt` mint address. The +`DaoV0` definition from earlier exists at address: + + +```js +import { daoKey } from "@helium/helium-sub-daos-sdk" + +const daoAddr = daoKey(new PublicKey("...hnt mint..."))[0]; +``` + +:::note Helium PDAs and Mints + +You'll notice that if you trace the graph of Helium PDAs, they always lead back to the address of +either the HNT token mint, or the subnetwork token mint. + +This design is intentional. Rather than making DAOs, subnetworks, etc global, we opted to make them +dependent on the specific mints being used. This allows us to set up testing scenarios in which we +use a testing token alongside the real tokens. This design also allows for easier reuse of our +contracts throughout the Solana community. + +::: + +### Aside - Tokens + +To understand the Helium model on Solana, it's important to understand how tokens work on Solana. + +You might imagine a Wallet is some kind of account (data struct) holding all of your tokens. This is +not the case! + +Instead, a Wallet is really a collection of `TokenAccount`s (Accounts whose data is a +`TokenAccount`). The token account itself has a reference to its owner, which is the Wallet. Note +that `TokenAccount.owner` is different than the `Account.owner`. In this case, the Program that is +allowed to make changes to a token account is the Token Program. That is the `Account.owner`. +Whereas the owning wallet of the `TokenAccount` is the `TokenAccount.owner`. You can see a token +account for a testing token we created +[here](https://explorer.solana.com/address/BM9kx8NZGNThVr6HnBJo1CR5Jvk5Zc3EEy7wWztaJHS2?cluster=devnet) + +Every token, whether it be USDC, HNT, or MOBILE has a definition. This is called the token `Mint`. +You can also see this key on the token account above. This includes definitions like current supply, +mint authority, freeze authority, and decimals. + +A common confusion on Solana is understanding Accounts vs Token Accounts, owners vs Token Account +owners. + +#### Associated Token Accounts + +Associated token accounts are often the first use of PDAs you will see as a developer on Solana. + +Given the above model, it is possible for a given wallet to have multiple token accounts for the +same token. That is both messy and hard to index. Early in the days of Solana, a program called +`associated-token` emerged. `Associated-token` says that the account for a given Wallet and mint can +be derived by: + + +```js + PublicKey.findProgramAddress( + [wallet.toBuffer(), TOKEN_PROGRAM_ID.toBuffer(), mint.toBuffer()], + ASSOCIATED_TOKEN_PROGRAM_ID + ) +``` + +Generally, token accounts are created through the `associated-token` program so that they can be +guaranteed to be accessed at an easy-to-find address. + +### Fetching Data + +The classic way of fetching data on Solana is to use @solana/web3.js connection object. + + +```js +import { PublicKey, Connection } from "@solana/web3.js" + +const connection = new Connection("...rpc url...") +const account = await connection.getAccountInfo(new PublicKey("...")) + +console.log(account.data) +``` + +This will get you the binary data of any account stored on chain; however, you will need to decode +the data yourself. Most programs come with their own SDKs for reading and deserializing data. For +example, SPL Token (the token program), comes with @solana/spl-token + + +```js +import { PublicKey } from "@solana/web3.js" +import { getAccount, getAssociatedTokenAddressSync } from "@solana/spl-token" + +const mint = new PublicKey("...wallet...") +const wallet = new PublicKey("...wallet...") +const tokenAddress = getAssociatedTokenAddressSync(mint, wallet) +const tokenAccount = await getAccount(connection, tokenAddress) + +console.log(tokenAcount.amount, tokenAccount.owner) +``` + +In the case of Helium programs, they all use a framework called +[Anchor](https://github.com/coral-xyz/anchor), which amongst other things generate SDKs for us. + +You can use the SDKs as follows: + + +```js +import { init } from "@helium/helium-sub-daos-sdk"; +import * as anchor from "@coral-xyz/anchor"; + +anchor.setProvider(anchor.AnchorProvider.local("...rpc url...")); +const provider = anchor.getProvider() as anchor.AnchorProvider; +const program = await init(provider) + +const daoAccount = await program.account.daoV0.fetch(new PublicKey("...dao key...")) +``` + +## Sending Transactions + +Transactions are how we modify data on Solana. All Helium SDKs use the standard +[Anchor](https://github.com/coral-xyz/anchor) SDK. + +That means the interface to all instructions are predictable. You should be able to look at either +our IDLs, or the programs themselves, and see what accounts need to be passed to generate +instructions. + +The best way to understand how to take certain actions against Helium on Solana is to look at +[our tests](https://github.com/helium/helium-program-library/tree/master/tests). + +For example, to submit a Data Credit delegation, the code may look something like this: + + +```js +import { subDaoKey } from "@helium/helium-sub-daos-sdk"; +import { init as initDc } from "@helium/data-credits-sdk"; +import * as anchor from "@coral-xyz/anchor"; + +anchor.setProvider(anchor.AnchorProvider.local("...rpc url...")); +const provider = anchor.getProvider() as anchor.AnchorProvider; + +const iotMint = new PublicKey("...iot mint..."); +const iotSubDao = subDaoKey(iotMint)[0] + +const dcProgram = await initDc(provider) + +await program.methods + .delegateDataCreditsV0({ + amount: toBN(10, 0), + routerKey: "router key", + }) + .accounts({ + subDao: iotSubDao, + }) + .rpc(); +``` + +## RPC & RPC Nodes + +An RPC is an application's gateway to the Solana cluster. RPC Nodes do not participate in consensus +and instead are dedicated to data requests. + +All the RPCs used in the Solana Migration follow the Solana chain and will index the NFT data that +Core Developers created in Compression NFTs. This is one reason the Helium Network can mint a +million or more NFTs on Solana. + +You may need to run an RPC service to access public Solana clusters. Many services are free, and +others are paid. The Foundation uses Helius as their RPC Provider, and it’s useful to use a PRC +provider that is familiar with compression. They will all support this at some point. + +You can read more about RPC & RPC Nodes [here](https://solana.com/rpc). + +## Helium Programs on Solana + +The code for all of these Programs is open source, and available in the +[helium-program-library](https://github.com/helium/helium-program-library) repository on Github. + +:::info Program Audits + +The Helium Programs have been audited by [sec3](https://www.sec3.dev/). The audit report was +published March 20, 2023. The audit report is available from sec3 on their +[GitHub reports repo](https://github.com/sec3-service/reports/blob/master/reports/sec3_helium_program_library_report.pdf). + +::: + +#### circuit_breaker + +- Program ID: `circAbx64bbsscPbQzZAUvuXpHqrCe6fLMzc2uKXz9g` +- Generic program wrapping sensitive mint authorities and token accounts in the Helium system to + prevent large movements in the case of an exploit or bug. + +#### data_credits + +- Program ID: `credMBJhYFzfn7NxBMdU4aUqFggAjgztaCcv2Fo6fPT` +- Manages the purchase, delegation, and burning of data credits. + +#### helium_entity_manager + +- Program ID: `hemjuPXBpNvggtaUnN1MwT3wrdhttKEfosTcc2P9Pg8` +- Handles the issuance of NFTs representing entities that are rewardable on the Helium network, such + as Hotspots and mappers. + +#### helium_sub_daos + +- Program ID: `hdaoVTCqhfHHo75XdAMxBKdUqvq1i5bF23sisBqVgGR` +- Manages the DAO/subnetwork structure proposed in HIP-51, including the minting of tokens to + subnetworks, HST holders, and the `lazy_distributor` for PoC earnings. + +#### lazy_distributor + +- Program ID: `1azyuavdMyvsivtNxPoz6SucD18eDHeXzFCUPq5XU7w` +- Allows off-chain Oracles to distribute PoC rewards to rewardable assets (such as Hotspots) that + are represented as NFTs. + +#### lazy_transactions + +- Program ID: `1atrmQs3eq1N2FEYWu6tyTXbCjP4uQwExpjtnhXtS8h` +- Used in the initial migration to Solana, this program allows compressing many transactions into a + merkle root to be executed lazily. This guarantees all transactions are executed exactly once. + +#### treasury_management + +- Program ID: `treaf4wWBBty3fHdyBpo35Mz84M8k3heKXmjmi9vFt5` +- Manages the treasury of each subnetwork as proposed in HIP-51, allowing DNT tokens to be swapped + for HNT according to a formula. + +#### voter_stake_registry + +- Program ID: `hvsrNC3NKbcryqDs2DocYHZ9yPKEVzdSjQG6RVtK1s8` +- Handles voting power via veHNT in Helium Governance. + +--- + +## Packages (JS/Typescript) + +| Name | Description | +| ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | +| [@helium/circuit-breaker-sdk](https://github.com/helium/helium-program-library/tree/master/packages/circuit-breaker-sdk) | SDK to circuit breaker program | +| [@helium/data-credits-sdk](https://github.com/helium/helium-program-library/tree/master/packages/data-credits-sdk) | SDK to the data credits program | +| [@helium/distributor-oracle](https://github.com/helium/helium-program-library/tree/master/packages/distributor-oracle) | SDK for interacting with the lazy-distributor oracles to claim rewards | +| [@helium/helium-entity-manager-sdk](https://github.com/helium/helium-program-library/tree/master/packages/helium-entity-manager-sdk) | SDK to the Helium entity manager program | +| [@helium/helium-sub-daos-sdk](https://github.com/helium/helium-program-library/tree/master/packages/helium-sub-daos-sdk) | SDK to Helium sub daos program | +| [@helium/idls](https://github.com/helium/helium-program-library/tree/master/packages/idls) | IDLs containing the typescript definitions for the raw anchor SDKs of our programs | +| [@helium/lazy-distributor-sdk](https://github.com/helium/helium-program-library/tree/master/packages/lazy-distributor-sdk) | SDK to the lazy distributor program | +| [@helium/lazy-transactions-sdk](https://github.com/helium/helium-program-library/tree/master/packages/lazy-transactions-sdk) | SDK to lazy transactions program | +| [@helium/spl-utils](https://github.com/helium/helium-program-library/tree/master/packages/spl-utils) | General utils for interacting with Solana, tokens, etc | +| [@helium/treasury-management-sdk](https://github.com/helium/helium-program-library/tree/master/packages/treasury-management-sdk) | SDK to the treasury management program | +| [@helium/voter-stake-registry-sdk](https://github.com/helium/helium-program-library/tree/master/packages/voter-stake-registry-sdk) | SDK to the voter stake registry program | + +--- + +## Important Addresses and Links + +All the tokens are on the `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` Program. + +The mint IDs are as follows: + +| Name | ID | +| ------ | ------------------------------------------- | +| HNT | hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux | +| MOBILE | mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6 | +| IOT | iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns | +| DC | dcuc8Amr83Wz27ZkQ2K9NS6r8zRpf1J6cvArEBDZDmm | diff --git a/docs/network-data/solana/compression-nfts.mdx b/docs/network-data/solana/compression-nfts.mdx new file mode 100644 index 000000000..1cd77256f --- /dev/null +++ b/docs/network-data/solana/compression-nfts.mdx @@ -0,0 +1,62 @@ +--- +id: compression-nfts +title: Compression NFTs +pagination_label: Compression NFTs +sidebar_label: Compression NFTs +description: Helium Compression NFTs Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/solana/compression-nfts +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +A new development on the Solana Blockchain has been +[Compression NFTs](https://www.metaplex.com/posts/expanding-digital-assets-with-compression-for-nfts). + +With normal NFTs on Solana, each token is stored on-chain as a distinct spl-token mint, with +decimals of 0 and supply of 1. This mint has some metadata attached to it, as well as a token +account representing the ownership of the token. In total, this leads to 4 accounts with a cost of +0.01197616 SOL in rent. Multiplying this by millions of Hotspots leads to not only a high cost but +also a large usage of storage space on the blockchain. + +Enter: Compression NFTs. Compression NFTs use a Concurrent Merkle Tree to compress millions of NFTs +into one 32-byte hash. Clients executing transactions on compressed NFTs can send a cryptographic +proof to the blockchain that verifies the NFT and ownership. In other words, instead of sending a +transaction with: + +```rust + +... +pub mint: Account<'info, Mint>, +pub metadata: Account<'info, Metadata>, +pub master_edition: Account<'info, MasterEdition>, +#[account( + constraint = token_account.amount >= 1, + token::owner = owner +)] +pub token_account: Account<'info, TokenAccount>, +pub owner: Signer<'info> +... +``` + +You can instead send: + +```rust + +pub struct ProofArgs { + pub hash: Vec, // The 32 byte hash of the NFT + pub root: [u8; 32], // The root of the merkle tree + pub index: u32, // The index of the item in the tree + pub proof: Vec> // An array of 32 byte proofs proving that the `hash` is part of the `root` +} + +... +pub merkle_tree: UncheckedAccount<'info>, +... + +``` + +While this can make the transaction size larger, the amount of data stored on-chain is tiny. While +this may look difficult, this is all neatly packed in the Metaplex Digital Asset API. This API runs +on multiple RPC providers and allows you to hit convenient functions like `get_assets_by_owner` and +`get_asset_proof` so that you never have to worry about the underlying concurrent merkle algorithm. diff --git a/docs/network-data/solana/helium-program-library.mdx b/docs/network-data/solana/helium-program-library.mdx new file mode 100644 index 000000000..d2b6c998d --- /dev/null +++ b/docs/network-data/solana/helium-program-library.mdx @@ -0,0 +1,49 @@ +--- +id: helium-program-library +title: Helium Program Library +pagination_label: Helium Program Library +sidebar_label: Helium Program Library +description: Helium Program Library +image: https://docs.helium.com/img/link-image.png +slug: /network-data/solana/helium-program-library +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +HPL Preview + +## Overview + +The Helium Program Library (HPL) is a collection of programs that enable the Helium Network to +operate on the Solana blockchain. The HPL is designed to be a comprehensive resource for developers +looking to build on the Helium Network, providing a suite of solana programs and tools to facilitate +the seamless integration of the Helium Network with the Solana blockchain. + +## Features + +The Helium Program Library (HPL) offers a wide range of features to support the Helium Network's +integration with the Solana blockchain. These features include: + +- **Solana Programs**: The HPL provides a comprehensive suite of programs designed to facilitate the + seamless operation of the Helium Network on the Solana blockchain. These programs are designed to + be easily accessible and customizable, allowing developers to build on the Helium Network with + ease. + +- **Documentation**: The HPL offers extensive documentation to support developers in interfacing + with the Helium Network on the Solana blockchain. This documentation includes detailed guides, + tutorials, and examples to help developers get started with building on the Helium Network. + +- **Tools**: The HPL provides a range of tools to support developers in building on the Helium + Network. + +## Getting Started + +To get started with the Helium Program Library (HPL), developers can access the HPL documentation +and at [hpl.helium.com](https://hpl.helium.com). The HPL documentation provides detailed guides, +tutorials, and examples to help developers get started with building on the Helium Network. + +The HPL GitHub repository can be found at https://github.com/helium/helium-program-library. diff --git a/docs/network-data/solana/rewardable-entities.mdx b/docs/network-data/solana/rewardable-entities.mdx new file mode 100644 index 000000000..e11363bb9 --- /dev/null +++ b/docs/network-data/solana/rewardable-entities.mdx @@ -0,0 +1,371 @@ +--- +id: rewardable-entities +title: Rewardable Entities +pagination_label: Rewardable Entities +sidebar_label: Hotspots on Solana +description: Helium Rewardable Entities Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-data/solana/rewardable-entities +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +All actors in the network that receive tokens are considered "Rewardable Entities." + +A rewardable entity on the Helium Network is represented on Solana as an NFT (Non-Fungible Token). + +NFTs are ideal for this job as they represent ownership in a way that is easily transferable and +recognized by all major wallets. + +## Fetching Rewardable Entities + +All rewardable entities are created by the `helium-entity-manager` program. Further, they exist +under a collection that is managed by the Maker of that entity. The easiest way to fetch all Helium +entities for a given wallet is to filter by the `helium-entity-manager-creator` + +We can get this address by running + + +```js +import { daoKey } from "@helium/helium-sub-daos-sdk"; +import { entityCreatorKey } from "@helium/helium-entity-manager-sdk"; + +const hntMint = new PublicKey('...hnt mint...') +const dao = daoKey(hntMint)[[0]] +const creator = entityCreatorKey(dao)[0] +``` + +This should output: `Fv5hf1Fg58htfC7YEXKNEfkpuogUUQDDTLgjGWxxv48H` + +Now, we can use the Metaplex Digital Asset API to get rewardable entities my wallet +(`BcJzP2hEYgzjUwpHEtS6RhuqGfEJVx8Rq3MejujAAWrR`) owns: + +```bash +curl --request POST \ + --url https://rpc-devnet.aws.metaplex.com/ \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc": "2.0", + "method": "search_assets", + "id": "get-assets-op-1", + "params": { + "ownerAddress": "BcJzP2hEYgzjUwpHEtS6RhuqGfEJVx8Rq3MejujAAWrR", + "page": 0, + "creatorAddress": "Fv5hf1Fg58htfC7YEXKNEfkpuogUUQDDTLgjGWxxv48H", + "creatorVerified": true, + "sortBy": {"sortBy": "created", "sortDirection": "asc"} + } + }' +``` + +### Hotspots and ECC Compact Keys + +Hotspots on the Helium Network currently are uniquely identified by their ECC Compact Public Keys. + +At onboarding time, Hotspots can sign an onboard transaction proving physical ownership of the +device. + +As such, the Helium Solana implementation enforces that all NFTs are unique by ECC Compact keys. + +If you have an asset id of an NFT on Solana, you can get the ECC Compact Key by fetching the digital +asset and pulling out the last value from the content.json_uri. + +For example: + + +```js +import { getAsset } from "@helium/spl-utils"; + +const asset = await getAsset(rpcUrl, new PublicKey("...asset id...")); + +const eccCompactKey = asset.content.json_uri.split("/").slice(-1)[0]; +``` + +If you have only an ECC Compact key and would like to find the NFT, you can use the `KeyToAssetV0` +struct that is stored on-chain: + + +```js +import { daoKey } from "@helium/helium-sub-daos-sdk" +import { keyToAssetKey, init } from "@helium/helium-entity-manager-sdk" + +// Declare constants +const hntMint = new PublicKey("...hnt mint...") +const dao = daoKey(hntMint)[0] +const eccKey = "...ecc compact key..." + +// Init program +const program = await init(provider); + +// Get the asset id from the KeyToAssetV0 account on-chain +const keyToAssetPkey = keyToAssetKey(dao, eccKey)[0] +const keyToAssetAcc = await program.account.keyToAssetV0.fetch(keyToAssetPkey); +const assetId = keyToAssetAcc.asset; + +// Now get the asset from the metaplex asset api +const asset = await getAsset(rpcUrl, assetId) +``` + +## Onboarding Rewardable Entities + +The onboarding flow for an entity is generally that a customer purchases the hardware from a Maker, +and then self-onboards to the network. Because all hardware is created by approved Makers, the +onboard transaction must be approved by the Maker. This uses a similar flow to the legacy +onboarding-server of the Helium blockchain. + +Makers are approved for specific subnetworks. A maker that creates IoT Hotspots cannot necessarily +onboard Mobile Hotspots. Each network subnetwork must approve makers to issue rewardable entities. + +The following test shows the full flow of onboarding a Hotspot using the onboarding server. + +The [React Native Helium](https://github.com/helium/react-native-helium) SDK should greatly simplify +this process. + + + + +```js +import Address from "@helium/address"; +import { Keypair } from "@helium/crypto"; +import { sendAndConfirmWithRetry } from "@helium/spl-utils"; +import { AddGatewayV1 } from "@helium/transactions"; +import { accountProviders } from "@metaplex-foundation/mpl-bubblegum"; +import { + Connection, + PublicKey, + Transaction, + Keypair as SolanaKeypair, +} from "@solana/web3.js"; +import axios from "axios"; +import { BN } from "bn.js"; + +function random(len: number): string { + return new Array(len).join().replace(/(.|$)/g, function () { + return ((Math.random() * 36) | 0).toString(36); + }); +} + +function sleep(ms: number) { + return new Promise((resolve) => setTimeout(resolve, ms)); +} + +describe("onboarding server", () => { + let me: Keypair; + let gateway: Keypair; + const maker = Address.fromB58( + "ENTER YOUR MAKER ADDRESS" + ); + let onboardingKey: string; + + let base = "https://onboarding.web.test-helium.com"; + before(async () => { + me = await Keypair.makeRandom(); + gateway = await Keypair.makeRandom(); + onboardingKey = gateway.address.b58; + const result = await axios.post( + `${base}/api/v2/hotspots`, + { + onboardingKey, + macWlan0: random(10), + macEth0: random(10), + rpiSerial: random(10), + heliumSerial: random(10), + batch: "example-batch", + }, + { + headers: { + authorization: "ENTER YOUR MAKER AUTH KEYS" + }, + } + ); + + await sleep(2000); + }); + + it("should run issue txs", async () => { + const hotspot = ( + await axios.get(`${base}/api/v2/hotspots/${onboardingKey}`) + ).data.data; + console.log(hotspot); + console.log(me.privateKey); + const solanaKeypair = SolanaKeypair.fromSecretKey(me.privateKey); + console.log("Solana pubkey: ", solanaKeypair.publicKey.toBase58()) + + await sleep(2000); + + const result = await axios.post( + `${base}/api/v3/transactions/create-hotspot`, + { + location: new BN(1).toString(), + transaction: ( + await new AddGatewayV1({ + owner: me.address, + gateway: gateway.address, + payer: maker, + }).sign({ + gateway, + }) + ).toString(), + } + ); + + const connection = new Connection("https://api.devnet.solana.com"); + const { solanaTransactions } = result.data.data; + for (const solanaTransaction of solanaTransactions) { + const txid = await sendAndConfirmWithRetry( + connection, + Buffer.from(solanaTransaction), + { skipPreflight: true }, + "confirmed" + ); + console.log(txid.txid); + } + + let tries = 0; + let onboardResult: any; + while (tries < 10 && !onboardResult) { + try { + onboardResult = await axios.post( + `${base}/api/v3/transactions/mobile/onboard`, + { + entityKey: onboardingKey, + } + ); + } catch { + console.log(`Hotspot may not exist yet ${tries}`); + tries++; + await sleep(2000); // Wait for Hotspot to be indexed into asset api + } + } + + + for (const solanaTransaction of onboardResult!.data.data + .solanaTransactions) { + const tx = Transaction.from(Buffer.from(solanaTransaction)); + tx.partialSign(solanaKeypair) + const txid = await sendAndConfirmWithRetry( + connection, + tx.serialize(), + { skipPreflight: true }, + "confirmed" + ); + console.log(txid.txid); + } + + const updateResult = await axios.post( + `${base}/api/v3/transactions/mobile/update-metadata`, + { + entityKey: onboardingKey, + location: new BN(1).toString(), + elevation: 2, + gain: 11, + wallet: solanaKeypair.publicKey.toBase58() + } + ); + + for (const solanaTransaction of updateResult.data.data.solanaTransactions) { + const tx = Transaction.from(Buffer.from(solanaTransaction)); + tx.partialSign(solanaKeypair) + const txid = await sendAndConfirmWithRetry( + connection, + tx.serialize(), + { skipPreflight: true }, + "confirmed" + ); + console.log(txid.txid); + } + }); +}); +``` + +## Claiming Rewards on Rewardable Entities + +A system of oracles keeps track of the rewards owed to each Rewardable Entity. For example, in the +IoT network there are oracles that keep track of the HNT tokens earned by each Hotspot for PoC. + +These oracles are responsible ONLY for tracking the total lifetime rewards associated with a +Hotspot. This frees the oracles from any kind of dependence on the blockchain. They don't care about +the issuance or movement of tokens. + +The `lazy-distributor` program keeps track of, for each Hotspot, how much of the total lifetime +rewards have been claimed. Claiming rewards, then, consists of two steps: + +1. Ask oracles to update the on-chain state to reflect the latest lifetime rewards for this Hotspot. +2. Issue the difference between the total lifetime rewards and total claimed rewards to the Hotspot + owner. + +In practice, we have made it so that this can all happen in a singular transaction for PoC rewards. +Staking rewards will happen in transactions combining up to 4 days of rewards. + +### Finding Current Rewards + +Oracles work off of a restful API that involves + +1. Grabbing lifetime rewards for all oracles. +2. Constructing a transaction to set the rewards and passing the transaction to each oracle to + partially sign. +3. Submitting the fully signed transaction to Solana. + +The SDK simplifies this process into two functions, `getCurrentRewards` and `formTransaction`. + +If you have interest in using the REST api, you can see the relatively simple client code +[here](https://github.com/helium/helium-program-library/blob/master/packages/distributor-oracle/src/client.ts) + +To fetch rewards across all oracles for a given asset id: + + +```js +import { init, lazyDistributorKey } from "@helium/lazy-distributor-sdk"; +import { getCurrentRewards } from "@helium/distributor-oracle"; +import * as anchor from "@coral-xyz/anchor"; + +anchor.setProvider(anchor.AnchorProvider.local("...rpc url...")); +const provider = anchor.getProvider() as anchor.AnchorProvider; +const program = await init(provider) + +const iotMint = new PublicKey("...iot mint...") +const assetId = new PublicKey("...asset id...") +const lazyDistributorPkey = lazyDistributorKey(iotMint)[0]; +const rewards = await getCurrentRewards(program, lazyDistributorPkey, assetId); + +rewards.map(reward => { + console.log(`Oracle ${reward.oracleKey} stating lifetime rewards of ${reward.currentRewards}`); +}) +``` + +### Claiming Rewards + +:::info + +The claim example in this section requires a connection to an RPC node (provider) that understands +compressed NFTs. This is an advanced feature that is not yet supported by Solana's public RPC +servers. **This example will not work unless you use an appropriate RPC provider such as +[Helius](https://www.helius.xyz/).** + +::: + +You can then get a transaction to submit to the Solana blockchain using those rewards: + + +```js + +import { formTransaction } from "@helium/distributor-oracle"; +import { sendAndConfirmWithRetry } from "@helium/spl-utils"; + +const tx = await formTransaction({ + program, + provider, + rewards, // from above + hotspot: assetId, + lazyDistributor: lazyDistributorPkey, +}) + +const signed = await provider.wallet.signTransaction(tx); + +await sendAndConfirmWithRetry( + provider.connection, + Buffer.from(signed.serialize()), + { skipPreflight: true }, + 'confirmed', +); +``` diff --git a/docs/network-iot/coverage-mapping/adeunis-mapper.mdx b/docs/network-iot/coverage-mapping/adeunis-mapper.mdx deleted file mode 100644 index 5366c5ef7..000000000 --- a/docs/network-iot/coverage-mapping/adeunis-mapper.mdx +++ /dev/null @@ -1,127 +0,0 @@ ---- -id: adeunis-mapper -title: Adeunis Mapper -pagination_label: Adeunis Mapper -sidebar_label: Adeunis Mapper -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/coverage-mapping/adeunis-mapper ---- - -# Adeunis Mapper - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Mapping Tips - -- Only operate at an above ground level of 1-2 meters, otherwise your data will not be - representative of most real world devices. -- The device is configured with an uplink interval of five seconds, sufficient for mapping on foot - or in a moving vehicle. - -## Device Instructions - -### Charging - -The device is rechargeable via a micro USB connector located on the bottom. It will charge -automatically in the ON or OFF state. The device can be used while charging. Any charger supplying -5V and at least 500mA is sufficient. - - - -If the battery is completely empty, it will be necessary to recharge the device for 6 hours in order -for it to be fully charged. - -### Operating Procedure - -Follow all the steps provided below for step-by-step instructions on how to properly operate the -field test device. - -:::important - -You must power on the device in a location with coverage in order for the device to first join the -network. If the device is not able to join, it will never begin sending uplinks. - -::: - -First, power the device On by flipping the switch on the bottom of the device into the ON position. - - - -After you are presented with the start screen, you will see the join screen. - -{' '} - -Start Screen - - - -Join Screen - -Press _Push Button 2,_ shown below, once to navigate to the GPS screen, also shown below. If the -backlight is off, you will have to press the button twice, once to turn the backlight back on and -another time to navigate to the next screen. - - - -Push Button 2 - - - -GPS Screen - -Once you have navigated to the GPS screen you'll next be monitoring this screen to validate that the -device has a sufficient GPS fix (enough satellites are visible to accurately calculate its position -and time). Make sure the device is located in a place where a good amount of the sky is visible. -Once your device obtains a fix (this may take a few minutes), you will see a latitude and longitude -show as well as how many satellites are visible. It's best if six or more satellites are visible. -You can now navigate to the Packet Count screen by again pressing the same _Push Button 2_, once if -the display backlight is on, and twice if it is off. - -:::important - -Ignore the PER % number as shown in the packet count screen below. This value is not meaningful for -the current configuration. Only pay attention to the UL\(Uplink\) Count. - -::: - - - -Packet Count Screen - -Once you see a positive number in the UL Count field, you have successfully joined the network and -are now transmitting packets with location data. At this point you are ready to begin mapping new -area. Read about how you can view your location live with Helium Cargo below! When you are finished, -simply switch the power switch to OFF. - -## Viewing on Cargo - -When your device is transmitting packets with a valid GPS fix your device will be visible on -[cargo.helium.com](https://cargo.helium.com/). The device names are in the format of _Mapper \#_, -with the number being that which is displayed on the front of your device with a label as shown -below. The Avg Speed, Elevation, and Voltage will always show zero, as these values were not -included. - - - -When you click on your device on the left, you will see a details window pop up in the right top of -the window. Here you can click on the _Sequence No_ box shown below to get a time series view of -each packet that was received in sequence as well as the Hotspot that received it. The sequence -number should match the _UL Count_ on the _Packet Count_ screen shown on the device, although it -will likely be a few seconds delayed. The sequence number will start from zero after each power -cycle of the device. - - - -You can also click on the _RSSI_ box shown below to view a time series view again, but with the -signal strength and Hotspot that received each packet. - - diff --git a/docs/network-iot/coverage-mapping/coverage-mapping.mdx b/docs/network-iot/coverage-mapping/coverage-mapping.mdx deleted file mode 100644 index 6d3875e59..000000000 --- a/docs/network-iot/coverage-mapping/coverage-mapping.mdx +++ /dev/null @@ -1,263 +0,0 @@ ---- -id: coverage-mapping -title: Coverage Mapping -pagination_label: Coverage Mapping -sidebar_label: Coverage Mapping -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/coverage-mapping ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -The [Mappers Coverage map](https://mappers.helium.com) is a crowd-sourced effort to build a -true-signal coverage map of the Helium network across the globe. By mapping real-world coverage, -network users can understand where sensor deployments are likely to have success connecting to -Helium. - -> Coverage mapping should only be done from ground level, or slightly above it. We would like the -> map to indicate the expected coverage a standard sensor device would experience. If you want to -> fly a GPS tracker on a balloon or aircraft, please do not contribute this data to the coverage -> map. - -Be sure to check out the ongoing conversation in the dedicated -[#mappers](discord://discord.com/channels/404106811252408320/730801390431240228) channel on the -[Helium Discord Server](https://discord.gg/helium). - -## Mapping Projects - -### Helium Mappers - -Helium Mappers lets you see the areas that have been explored by participants in the coverage -mapping project. The map also shows the Helium hotspots that have provided coverage to these areas. -Helium Mappers uses the H3 hexagon tiles to aggregate survey results and provided statistics. View -Mappers data at [mappers.helium.com](https://mappers.helium.com/). - -### Helium Cargo - -Cargo is an evaluation tool for LoRaWAN GPS tracking devices. It shows the current location of these -devices, along with the coverage of the network as an H3 hex grid. While Helium Mappers shows an -aggregate view of the network coverage, Cargo can display specific mapper devices by name, and their -most-recent position reports. - -View GPS trackers on Cargo at [cargo.helium.com](https://cargo.helium.com/). - -### CoverageMap.net - -Coverage Map is a third party tool that draws heatmaps for LoRaWAN networks. This tool has the -ability to show raw survey results for devices and hotspots. It aggregates coverage measurements -into a heatmap, radar plots and alpha shapes. View Helium's heatmap at -[CoverageMap.net](https://coveragemap.net/). - -## Mappers Newsletter - -Join the Mappers [newsletter](https://www.helium.com/mappers) to stay up to date on new and upcoming -features. - -## Project Roadmap - -Take a look at the big picture in the [Mappers Roadmap](/iot/coverage-mapping/roadmap). The roadmap -is a great way to understand the full scope of the project and find an area to make your own -contributions to the project. - -## Frequently Asked Questions - -### How does Mappers work? - -Participants use low cost LoRaWAN devices to survey the real-world network created by Helium. Many -contributors bring their mapper with them when they walk, hike, bike, drive or even boat! They’re -small and fit well in a pocket or on a car dash. Some have set up their mappers so they’re -contributing to the coverage map every time they take a drive. - -In order to place a mark on the map, the mapper device sends out a signal with a GPS location -encoded. If a Helium Hotspot ‘hears’ that signal, data is passed through the internet and recorded -in the Mappers database. The Mappers database uses the GPS information from the Mapper to ‘light up’ -the hex on the map. - -### Why should I contribute to Mappers? - -There are a variety of ways that Mapping is valuable to both hotspot owners and network users. For -hotspot owners, the collected data helps to visualize the coverage provided by all Helium hotspots - -identifying areas where coverage is lacking or even where hotspot placements could be made that -would participate in Proof of Coverage with other hotspots. A marked hex on the map indicates that -uplink signals from registered Helium LoRaWAN sensors have been proven to be “heard” by the Helium -network somewhere within that hex shaped area. - -For network users, the map proves the real-world coverage that hotspots provide. This is like -looking at the Verizon or T-Mobile map when evaluating phone plans, but for business users. This -real world evidence at the scale and resolution offered by our map gives prospective network users -the information they need to make decisions about their deployments. As an example, this map is what -someone like Lime scooters would look to before they sign a contract. - -In short, a robust map means high priced customers, which means adoption, which means the network -grows and the token value increases. - -### Do I earn HNT for contributing? - -No, coverage mapping is entirely voluntary. In order to participate in mapping, you will need to -spend Data Credits to pay for the data transfer that your mapper uses. To get you started, new -Helium Console accounts are funded with 250 DC. Beyond that, HNT can be converted to DC to fund -device data transfer or DC can be purchased directly through Console. - -Mapping does not make a hotspot earn more HNT through Proof of Coverage. The real value is to prove -the network, drive adoption, and increase the purchase of data credits by commercial users. - -If the hotspots that you are mapping are your own, those data credits are paid back to your hotspots -in the form of HNT. Hotspots earn HNT for data packets they transfer, for mapping or otherwise. - -### How can I use Mappers for my own hotspot deployments? - -- Find new locations for hotspots. -- Get real-world information about how far your hotspot reaches. -- Learn RF data analytics in an interactive way. - -### How can I use Mappers for my own sensor deployments? - -Take a mapping device to the area where you want to deploy sensors and watch to see if it is picked -up by a hotspot in the hex where you want to deploy a sensor. If it’s picked up by only one hotspot, -decide if you want to deploy an additional hotspot in that area for sensor connection redundancy. -Look at existing mapped areas for confirmation that your sensors can be deployed in that area and -how many hotspot can pick them up. It only takes one hotspot to receive and transmit data through -the internet, but the redundancy offered by the Helium Network helps to ensure that your data is -received. - -## Get Started with Mapping - -There are a wide variety of ways to get involved depending on your level of comfort with -arduino-type devices. A few common devices are listed below, but in no way is this list exhaustive. - -### Fully Preconfigured - -Fully managed mapping devices are ready to use as soon as they arrive. These are pre-configured and -enrolled by the seller, and not your own Helium Console. The Data Credits are provided by the -seller, and the devices have pre-selected back-end Integrations that are not user-configurable. -Generally, these devices are the most easy and accessible, requiring just power to start mapping. - -- IoWe Coverage Mapper - - [Product page](https://www.internetofwe.net/product-page/helium-coverage-mapper) -- Wio Terminal LoRaWAN Field Tester - - [Product page](https://www.seeedstudio.com/WioField-Tester-Kit-p-5282.html) - -### Plug & Play - -Console-ready device that you onboard to spend your own Data Credits. The -[Mappers Quickstart](/iot/coverage-mapping/quickstart) guide focuses on the the Dragino LGT-92, but -the steps are effectively the same for any mapping device. - -- Adeunis Field Test Device - - [Product page](https://www.adeunis.com/en/produit/ftd-network-tester/) - - [Adeunis tutorial](/iot/coverage-mapping/adeunis-mapper) -- Dragino LGT-92 - - [Product page](https://www.dragino.com/products/lora-lorawan-end-node/item/142-lgt-92.html) - - [Dragino LGT-92 tutorial](/iot/coverage-mapping/quickstart) -- Fiz-Tech Mapper - - [Product page](https://fiz-tech.net/search?type=tag&q=Mapper) -- Glamos Walker - - [Product page](https://glamos.eu/product/walker/) - - [Glamos Walker tutorial](https://glamos.eu/manual/) -- RAK Wireless RAK7200 - - [Product page](https://store.rakwireless.com/products/rak7200-lpwan-tracker?variant=29669491867693) - -### DIY Mappers - -Flash your own code, add the device to your Helium Console, and spend your own Data Credits. Setting -up a mapper from your own dev board is a great way to learn about LoRaWAN devices on the Helium -Network. - -- Heltec CubeCell GPS-6502 (HTCC-AB02S) - - ARM Cortex M0+, AIR530Z GPS module with internal antenna, SX1262 LoRa, OLED Screen - - [Product page](https://heltec.org/project/htcc-ab02s/), - [Product page via Parley Labs](https://shop.parleylabs.com/collections/iot-developers-products/products/cubecell-gps-6502-by-heltec-htcc-ab02s), - [IoWE DIY Kit](https://www.internetofwe.net/product-page/diy-coverage-mapper-kit-us915) - - [Heltec Cubecell (jas_williams)](https://github.com/jas-williams/CubeCell-Helium-Mapper) - - [Heltec Cubecell (kicko)](https://github.com/hkicko/CubeCell-GPS-Helium-Mapper) - - [Heltec Cubecell (Max_Plastix)](https://github.com/Max-Plastix/CubeCell-GPS-Helium-Mapper) - Alternate UI and behavior -- LILYGO TTGO T-Beam - - ESP32 with LoRa, WiFi, Neo-6M GPS, BlueTooth, SMA Antenna, 18650 Battery holder and 0.96" OLED - screen. - - There are multiple versions of the TTGO T-Beam available. Version `v1.1` is recommended, and - often sold with the Meshtastic software pre-loaded. - - [Product page](http://www.lilygo.cn/prod_view.aspx?TypeId=50060&Id=1317&FId=t3:50060:3) - - [TTGO T-Beam (kizniche)](https://github.com/kizniche/ttgo-tbeam-ttn-tracker) - - [TTGO T-Beam (khrys)](https://github.com/khrys63/helium-mapper-tbeam) - - [TTGO T-Beam (hekopath)](https://github.com/hekopath/ttgo-rev1-helium) - - [TTGO T-Beam (tmiklas)](https://github.com/tmiklas/tbeam-helium-mapper) - - [TTGO T-Beam (Max_Plastix)](https://github.com/Max-Plastix/tbeam-helium-mapper) -- RAK Wireless Helium Mapper Kit - - [Product page](https://store.rakwireless.com/products/helium-mapper-kit?variant=41259355701446) - - [RAK Helium Mapper Kit tutorial](https://news.rakwireless.com/make-a-helium-mapper-with-the-wisblock/) -- Helium Dev Kit / RAK WisBlock - - [Product page via RAKWireless](https://store.rakwireless.com/products/helium-developer-kit), - [Product page via ParleyLabs](https://shop.parleylabs.com/collections/iot-developers-products/products/helium-wisblock-connected-kit) - - [Helium Dev Kit tutorial (arkieguy)](https://github.com/arkieguy/RAK4631-Helium-Mapper) - - [Make a Helium Mapper with the WisBlock (johansmacias)](https://news.rakwireless.com/make-a-helium-mapper-with-the-wisblock/) -- Ingenious Things Mapper (disk91) - - [Product page](https://shop.ingeniousthings.fr/products/helium-lorawan-field-tester-and-mapper-kit) - - [Disk91 Mapper tutorial](https://www.disk91.com/2021/technology/lora/low-cost-lorawan-field-tester/) - -### Device comparisons - -Which hardware platform to select for DIY? Two common and inexpensive platforms are the CubeCell -GPS-6502 and LilyGo TTGO T-Beam v1.1. Here are some approximate comparisons: - -| | CubeCell GPS-6502 | TTGO T-Beam | -| ----------------- | ------------------------------------------ | ---------------------------------------- | -| Cost (USD) | $33 (Parley Labs) | $35 Amazon or $25 AliExpress | -| Size | Smaller | 2x Longer | -| Battery | Add ~1000mA LiPo plug-in | 18650 LiIon cell holder | -| Power Switch | None | Power Button / PMU | -| Battery Charger | Hardware USB charger | PMU programmable charger | -| GPS | Air530Z | uBlox Neo-6M | -| Operating Current | TBD | 110mA | -| Connector | microUSB side | microUSB bottom | -| Buttons | 2: Menu, Reset | 3: Power/Menu, Select, Reset | -| GPS Antenna | on-board ceramic + IPEX external connector | Included active antenna on IPEX | -| LoRa Antenna | Wire-coil IPEX antenna | SMA with included stubby or 10cm antenna | -| Display | 0.96" OLED, installed | 0.96" OLED, DIY Solder 4-pin | -| LEDs | Green GPS Fix, RGB LED, Red Charging | Red GPS Fix, Blue & Red programmable | -| Processor | ASR6502 / Cypress PSoC 4000 | ESP32 | -| LoRa Radio | SX1262 | SX1278/76 | -| PMIC | -none- | AXP192 | -| Open Source | parts | yes | -| WiFi & Bluetooth | no | yes | - -### Configuration Basics - -At its core, contributing to Helium Mappers is just a matter of delivering a specific payload -through the console. Learn more about the [Mappers API](/iot/coverage-mapping/api). - -If your mapping device is delivering messages to Helium Mappers, you can also enable the -integrations for [Cargo](/use-the-network/console/integrations/cargo/) and -[CoverageMap.net](https://docs.ttnmapper.org/integration/helium.html) to contribute to these two -projects using the same Decoded payload. - -A flow that sends data to all three projects would look similar to this: - - - -## Understanding the Mappers Visualization - -From within the [Mappers tool](http://mappers.helium.com), clicking on a green hexagon will allow -you to get more information about the coverage available in that region. - -- H3 Index - - The funny looking number like `89283082853ffff` is the unique h3 index of the hexagon on the - map. In other words, it's the hex’s name. H3 is a system of managing global datasets, and is - pervasive throughout different Helium protocols. -- RSSI - - “Received Signal Strength Indicator” is a measure of the power present in a received radio - signal. This number is computed by the hotspot when it hears the signal from a mapper. The - higher the signal (less negative), the ‘stronger’ it is considered. -- SNR - - “Signal to Noise” measures the ratio of received power to background power in the received - signal. Like the RSSI, it is also computed by the hotspot when it hears signal from the mapper. - A higher ratio represents a clear signal whereas a negative number in this field represents a - noisy signal. -- Redundancy - - The total count of hotspots that heard a mapper from within this hex. This metric is helpful in - understanding the resilience of the network in a given area. -- Distance - - This is the approximate distance of the mapper from the hotspot that heard it. diff --git a/docs/network-iot/coverage-mapping/mappers-api.mdx b/docs/network-iot/coverage-mapping/mappers-api.mdx deleted file mode 100644 index a313018f5..000000000 --- a/docs/network-iot/coverage-mapping/mappers-api.mdx +++ /dev/null @@ -1,87 +0,0 @@ ---- -id: mappers-api -title: Mappers API -pagination_label: Mappers API -sidebar_label: Mappers API -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/coverage-mapping/api ---- - -# Mappers API - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction - -The Mappers API is a set of HTTP requests used for submitting data to the Mappers project. Data -submitted is viewable on [mappers.helium.com](https://mappers.helium.com) and updated in real time. - ---- - -### Authentication - -There is currently no authentication required. - -### Ingest Uplink - -``` -POST https://mappers.helium.com/api/v1/ingest/uplink -``` - -Submit geo tagged device uplink. - -`Content-Type: application/json` - -Requests are intended to be sent from an HTTP integration within Console. Metadata from the standard -JSON message is used in addition to the required fields detailed below. - -All required fields are case sensitive and must be in the top level of the decoded payload section -as shown below: - -```json -"decoded": { - "payload" : { - "accuracy": 2, - "altitude": 2, - "latitude": 38.811706, - "longitude": -121.607035 - } -} -``` - -All of the following fields are required `latitude`, `longitude`, `altitude` , `accuracy`. - - - - -_Body Parameters_ - -| Parameter Name | Type | Description | Expected Unit | Example | -| -------------- | ------- | ------------------------- | --------------- | --------------------- | -| latitude | _float_ | Device Latitude Value | Decimal Degrees | ` 37.79518664339426` | -| longitude | _float_ | Device Longitude Value | Decimal Degrees | `-122.39384483747301` | -| altitude | _int_ | Device Altitude Value | Meters | `10` | -| accuracy | _float_ | Device GPS Accuracy Value | Meters | `2.3` | - - - - -200: OK Request submission successful - -``` -Success -``` - -400: Bad Request Required request parameters not found. - -``` -Invalid Fields -``` - - - diff --git a/docs/network-iot/coverage-mapping/mappers-quickstart.mdx b/docs/network-iot/coverage-mapping/mappers-quickstart.mdx deleted file mode 100644 index ceb965346..000000000 --- a/docs/network-iot/coverage-mapping/mappers-quickstart.mdx +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: mappers-quickstart -title: Mappers Quickstart -pagination_label: Mappers Quickstart -sidebar_label: Mappers Quickstart -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/coverage-mapping/quickstart ---- - -# Mappers Quickstart - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This guide will show you step by step how to contribute data to the Mappers project with an -off-the-shelf tracker. This guide will use the -[Dragino LGT92](https://www.dragino.com/products/lora/item/142-lgt-92.html), but any LoRaWAN -compatible tracker will work. - -### Steps - -1. Add device to Console. -2. Create new HTTP integration with Mappers API ingest endpoint. -3. Create Function Decoder to decode device payload. -4. Create a Flow and verify data is being sent successfully. - -### 1. Add Device to Console - -To start, you'll need to add your device to Console. You should have been provided with a DevEUI, -AppEUI, and AppKey from the seller of the device. Follow our -[quickstart](/use-the-network/console/quickstart) for instructions on how to add a new device to -Console. - -### 2. Create HTTP Integration - -To create a new HTTP integration in Console, navigate to the Integrations page using the left -navigation and then select the HTTP integration. - - - -Next we'll fill in the details, see instructions and image below. - -1. Enter the Mappers API Ingest Endpoint URL (Required) - `https://mappers.helium.com/api/v1/ingest/uplink` -2. Enter the name for this Integration: _Mappers Integration_ -3. Finally, click _Add Integration_ to complete. - - - -### 3. Create Function Decoder - -Next, we'll be creating a Function decoder to decode the payload from the device and properly format -it for the API endpoint. The decoder is specific to the encoding scheme used to encode the data -before the device transmits it. For off-the-shelf devices this is usually manufacturer specific. For -development devices, -[CayenneLPP](https://developers.mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload) is -often used. For this guide we'll be using a decoder specifically made for this tracking device. We -have a repository with decoders for various devices -[here](https://github.com/helium/console-decoders). - -To start, navigate to the Functions page using the left navigation and then click _Add Function_. - -1. Enter a name for the decoder (below we've used _Dragino LGT92 Decoder_), select the type of - Function, _Decoder_ in this case, and finally select _Custom Script_ from the drop down. -2. Copy and paste the complete decoder function provided by the manufacturer or found - [here](https://github.com/helium/console-decoders/blob/master/Dragino/LGT92/decoder-v1.6.4.js). - - ```javascript - function Decoder(bytes, port) { - // Decode an uplink message from a buffer - // (array) of bytes to an object of fields. - var latitude //gps latitude,units: ° - latitude = ((bytes[0] << 24) | (bytes[1] << 16) | (bytes[2] << 8) | bytes[3]) / 1000000 //gps latitude,units: ° - var longitude - longitude = ((bytes[4] << 24) | (bytes[5] << 16) | (bytes[6] << 8) | bytes[7]) / 1000000 //gps longitude,units: ° - var alarm = bytes[8] & 0x40 ? 'TRUE' : 'FALSE' //Alarm status - var batV = (((bytes[8] & 0x3f) << 8) | bytes[9]) / 1000 //Battery,units:V - if ((bytes[10] & 0xc0) == 0x40) { - var motion_mode = 'Move' - } else if ((bytes[10] & 0xc0) == 0x80) { - motion_mode = 'Collide' - } else if ((bytes[10] & 0xc0) == 0xc0) { - motion_mode = 'User' - } else { - motion_mode = 'Disable' - } //mode of motion - - var led_updown = bytes[10] & 0x20 ? 'ON' : 'OFF' //LED status for position,uplink and downlink - var Firmware = 160 + (bytes[10] & 0x1f) // Firmware version; 5 bits - var roll = (((bytes[11] << 24) >> 16) | bytes[12]) / 100 //roll,units: ° - var pitch = (((bytes[13] << 24) >> 16) | bytes[14]) / 100 //pitch,units: ° - var hdop = 0 - if (bytes[15] > 0) { - hdop = bytes[15] / 100 //hdop,units: ° - } else { - hdop = bytes[15] - } - var altitude = (((bytes[16] << 24) >> 16) | bytes[17]) / 100 //Altitude,units: ° - return { - latitude: latitude, // Note that must be lower-case - longitude: longitude, - altitude: altitude, - accuracy: 3, - Roll: roll, - Pitch: pitch, - BatV: batV, - ALARM_status: alarm, - MD: motion_mode, - LON: led_updown, - FW: Firmware, - HDOP: hdop, - } - } - ``` - - Next we need to verify that all required fields are present in the function. Find more details on - the API specification [here](/iot/coverage-mapping/api). The required fields are case-sensitive. - If you got your decoder from the manufacturer and one or more required fields are missing - add - them with hard-coded values like accuracy in the above example. - -3. Finally, save your function. - - - -### 4. Create a Flow - -Next we will create a [_Flow_](/use-the-network/console/flows/orientation). Navigate to the Flows -page and click the + sign next to Nodes. - - - -Drag and drop your device, function and integration on the workspace. Link them by drawing lines -with your mouse between the connection points. Link device -> decoder -> integration. - - - -You are now ready to power on your device and verify that data is being sent correctly to the Mapper -API. To do this just expand an uplink event in the event log and verify that you are getting a -_"Success"_ message for the integration as shown below. - - - -That's all! You can now expect to see your data show up on -[mappers.helium.com](https://mappers.helium.com) in a few minutes. If you want to see where your -mapper is on the map, you could use [Cargo](https://cargo.helium.com). You will have to add one more -[integration](/use-the-network/console/integrations/cargo/#add-a-cargo-integration) and link it to -the decoder in your flow. - - diff --git a/docs/network-iot/coverage-mapping/mappers-roadmap.mdx b/docs/network-iot/coverage-mapping/mappers-roadmap.mdx deleted file mode 100644 index 394343da1..000000000 --- a/docs/network-iot/coverage-mapping/mappers-roadmap.mdx +++ /dev/null @@ -1,144 +0,0 @@ ---- -id: mappers-roadmap -title: Mappers Roadmap -pagination_label: Mappers Roadmap -sidebar_label: Mappers Roadmap -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/coverage-mapping/roadmap ---- - -# Mappers Roadmap - -## Introduction - -The Mappers project is a crowd-sourced effort to build a true-signal coverage map of the Helium -network across the globe. - -The goal for this roadmap is to get the Helium coverage map to a state where it offers a full -understanding of the ubiquitious LoRaWAN and 5G networks and can be adapted for future protocols. In -pursuit of this goal, there are several high-level objectives that are broken out into their -tactical subparts. - -Since this project is an open source, community-driven effort; timelines have not been applied to -the various goals listed. We encourage the community to adopt any of the goals in the effort of -growing the project. - -## Make It Easier to Contribute - -### Mapping Device Tutorials - -In the nearterm, the easiest way to enable more people to participate in mapping is simply to make -it easier for them to get started. - -Any community member with experience getting their own device set up can help the next wave of -mappers get their start! If you have experience getting a device set up, consider contributing your -experience in the form of an in-depth guide. - -### Develop BLE Mapper - -We seek to build new firmware, initially targeting bluetooth-enabled, nRF52-based devices like the -RAK WisBlock or TTGO T-Echo. Building on this platform allows us to address some of the shortcomings -of LoRa-only mappers by leveraging the Bluetooth to pair with a phone. - -This firmware will be open source and accompanied by a protocol that other developers can follow if -they wish to build their own variations. Any party will be able to manufacture and sell their own -mapping devices. - -The current generation of mapping devices do a great job of showing coverage where it exists, but -are unable to report where coverage does not exist. By pairing with a phone, we can utilize the -cellular connection to report when an uplink has been attempted. With this information we have -geographic record a packet that should exist that can be compared with received data. - -The device can optionally include a GPS module which would allow reducing overall cost. When a GPS -module is not available, a phone connection would be required to provide geographic information. - -Existing devices will continue to be supported. - -### Native Mapping App - -In association with the new BLE-based mapper, a purpose-built phone app must be developed to -interface with these devices. This opens many opportunities to streamline the experience for -community members joining the project. - -The onboarding of devices will no longer require the creation of a console account, EUI onboarding, -or device flashing. Devices will be onboarded throught the app, and data credit costs may either be -paid by a party like the Helium Foundation, or covered through a small in-app fee. Just pair the -device with the app and it's ready to map. - -To make sure all mappers are up to date, software has been developed that will allow the mapping -device to be updated directly through the app as the BLE mapper firmware evolves. - -## Better Understand Mappers Data - -### Continued Mappers v2 Improvements - -Mappers v2 was structured to be the 'Minimum Lovable Release' of the longterm vision, a Helium -Coverage Explorer. In pursuit of the next major release, we have used v2 to teach us the value of -the data, how it is used, and how community members most enjoy contributing. The v2 platform has -already done a lot to help us in this respect. In the effort of continuing our user research, we -will continue to add additional features and enhancements. These additions will continue to be -tracked as issues on the [Mappers Github](https://github.com/helium/mappers/issues) project. - -### Mappers v3 (Coverage Explorer) - -In pursuit of supporting more in-depth analysis of the data, more tools, layers, and metrics can be -surfaced in the app. A rework of the UI will allow these features to be added ad-hoc to the -application. It is also possible that the mappers data finds itself in the Helium Explorer, -augmenting the data already offered there. - -As example, a few features that may land in a v3 release: - -- Showing the coverage for a single hotspot. -- New map layers showing redundancy or recency. -- Filters for altitude or spreading factor. -- Clearing of data from old assertions of hotspots. - -## Enable Community Participation - -### Mappers API - -Mappers v1 and v2 have offered a glimpse of what is possible with the data collected by the Mappers -community. Outside of the Mappers project, we have seen explosive growth of community-developed apps -like Hotspotty and Helium Vision - to name a few. - -In the interest of enabling the community to build on top of the Mappers dataset, a cohesive API can -be built to support developers in crafting their own reprentation of Helium coverage. - -### Open Source - -All source of this project will continue to be freely available to the community. In purusit of -further enabling community involvement, documentation of code, issues, and roadmap will continue to -be a high priority. Open source also means nothing is set in stone, and community input continues to -shape the future of this project. - -### Further Engage Mappers - -Should mapper growth be lower than desired, there are opportunities to further grow. Other roadmap -items likely take priority. - -- Leaderboard -- Capture the Hex game - -## Forward-looking Opportunities - -### Explore Secure Mappers - -Many have recognized the value of real-world coverage data as a valuable resource for proof of -coverage and hotspot verification. However, the current system of submitting mapper data is -inadequate for protecting the incentive-based models that reward hotspot owners. This is due only to -the fact that submitting false data to Mappers would be a trivial task. (As such, no data from this -system would ever be used in this manner.) - -In order to leverage Mappers data for network verification; new ingest protocols will need to be -built and new classes of hardware will need to be developed that are hardened against attack by -those who might submit false coverage information. - -### Additional Community Input - -As with all parts of the Helium project, we look to the community to develop use cases, provide -feedback, and define new features. Get involved in the Mappers project: - -- [Mappers Project GitHub](https://github.com/helium/mappers/) -- [Helium Community Discord](https://discord.gg/helium) - - [#mappers](discord://discord.com/channels/404106811252408320/730801390431240228) channel. diff --git a/docs/network-iot/crowdspot.mdx b/docs/network-iot/crowdspot.mdx deleted file mode 100644 index eb37d6fdb..000000000 --- a/docs/network-iot/crowdspot.mdx +++ /dev/null @@ -1,480 +0,0 @@ ---- -id: crowdspot -title: Crowdspot -pagination_label: Crowdspot -sidebar_label: Crowdspot -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/crowdspot ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -:::warning Removing A Hotspot from the Denylist with Crowdspot - -If a Hotspot has been added to the Denylist in error, the **only** method to have it removed is to -file a Removal Request using [Crowdspot](https://crowdspot.io/). - -**Instructions for submitting a removal request can be found on the -[Denylist Removal Request documentation page.](/iot/denylist-removals)** - -::: - -[Crowdspot](https://crowdspot.io/) is an unmonitored, self-service tool built by Nova Labs for the -Helium Community. This tool allows anyone to explore Helium Network Hotspot data to understand -atypical Hotspot behavior and identify anomalies. - -Similar to Voting, submitting Denylist additions, removal requests, or casting a vote on the status -of a Hotspot requires a Crowdspot account associated with a unique Helium Wallet address. - -If you do not have the [Helium Wallet app](/wallets/helium-wallet-app), you'll need to download the -Helium Wallet app and create a new Wallet or import an existing Wallet before proceeding. - -:::note Crowdspot Connections are Free - -There are 0 fees to connect a Helium Wallet address to Crowdspot. - -::: - ---- - -## How to Submit to the Denylist - -To submit Hotspots for Denylist consideration, start by logging in with your Helium Wallet and -clicking on the `Submit Denylist Request` button on the Crowdspot.io landing page. - -### Log In with the Helium Wallet App - -To associate a Helium Wallet address, click the `Login` menu bar item on the Crowdspot homepage and -scan the QR code with your phone. - -
- -
- -Once you have scanned the QR Code, the Helium Wallet app will open and prompt you to authenticate -Crowdspot. - -1. **Confirm Connection Start**: Confirm that you _do_ want to connect a Helium Wallet to Crowdspot. -2. **Choose Wallet**: Choose the account you would like to use with Crowdspot, and tap Continue. -3. **Authenticate**: Send a transaction to the Helium blockchain to complete login. - -
-
-
- -
-
- -
-
- -
-
-
-
- Confirm Connection Start -
-
- Choose Wallet -
-
- Authenticate -
-
-
- -

- -address. The Profile badge will match in the Helium Wallet app and on Crowdspot. If you are already -logged in, you will see a Profile Badge and a portion of the connected Wallet - -Otherwise, if no account is logged in, no Profile Badge is visible, and the `Login` menu bar item is -shown. - -:::note Login Status Indication - -
-
-
- Logged In - -
-
- Not Logged In - -
-
-
- -::: - -#### How to Log Out - -You can log out of Crowdspot by clicking your profile badge in the upper right corner and selecting -`Log Me Out` from the pop-up menu. - -
- -
- -### Submit an Addition - -Once you have logged in, click the `Submit Denylist Request` button to begin your submission. - -
- -
- -#### Submission Type - -On the Submission form, select the `Addition` radio button under `Submission Type.` - -#### Enter Hotspot Address - -Copy and paste the `b58` address of the Hotspot into the `Enter Hotspot b58 Address` field. The -`b58` address for a Hotspot is the 52-character address of the Hotspot, **NOT THE ANIMAL NAME**. The -`b58` address for a given Hotspot is the end of the URL for the Hotspot on the Helium Explorer or -the value next to `Address` on the Hotspot's page on Crowdspot. - -Multiple Hotspots can be added as part of a single Denylist submission by clicking the `+` button -and inputting more Hotspot `b58` addresses. - -#### Reporting Clusters - -Some abnormal Hotspots are part of a "Cluster", a group of Hotspots that only witness each other. -Clusters are often asserted in a roughly circular formation and may be nestled among legitimate -Hotspots. - -When reporting a Cluster of Hotspots, include all `b58` addresses **and** toggle on the -`Is this a cluster of Hotspots` checkbox. This information assists in evaluating the legitimacy of -the Hotspots in the request. - -#### Written Reasoning - -Submitting a written description to support the Denylist submission provides valuable insight for -evaluation. A minimum of 150 characters is required. - -#### Create the Submission - -Once you have added all the required and optional information, click the `Create Submission` button. - -:::note Submission Status - -You can view the status of your submission on the -[Submissions page](https://www.crowdspot.io/submissions/), linked in the Crowdspot menu bar. - -::: - ---- - -### Submitting Hotspots as a Batch - -Investigation of abnormal Hotspots can be a lot of work, and many workflows exist, especially for -the submission of large Clusters. To make the process easier for extensive submissions, Hotspot -`b58` addresses can be added in a batch (of up to 100 addresses) rather than one at a time. - -
- -
- -#### Entering a Batch of Hotspot Addresses - -To submit multiple Hotspots, Click the `Submit a Batch` link, and the individual address entry field -will be replaced with a text box. - -:::caution Formatting is essential! - -Hotspot addresses must be separated by commas; no more than 100 addresses can be included in a -single submission. - -::: - -#### Good Example - -> comma separated, no new lines, 100 or fewer addresses - -```bash -112Y9MOI0cSuhXXmtdjbwbggmiUTXtpGvz26djJscfJKRfoj2sUN,112YoUnnjdbi2qW51UNdcfIfzLvfzLwmWkvE7ZO1LJoz8j5XyfGu,112snBh48MrKFwkzT29ciqPDjFkpq0FtQI6uCv4EpOK6QfW9w45N,112ugTSdVRHWvO85WrAuV5JvcytQYRnkgdxtxgXKNOGMi1XYXQR7,112ZTwJcUBGC65J3XjQGKWmNkcGspVFOkDyZJVCRs5vIQrpPyT8O,112VDtGIy9COHkZFdsBQyAXM9aOfbQ2oIKSOOBSVbpwV38dxnDN5,113oCV3rIwxwwG2umgc0vBbSqRm856HrUFRdgWAJERXkA9M5aVmu,113Wcs25X8JYDVzWKgAgf1nzkUnS2i9XLrYV4bbo9RL4Xv2Q4Yay,113nRmEovrRvQF6UNFrSv79Ys9Thuw6ajAJrN7wpmen9KbqZO7nU,114xSLeZSB6DaWkirHGZsxQ0kfs2DwZ8zIFQQWRnQshshcZ0zXl8 -``` - -#### Bad Example - -> includes white space, addresses on multiple lines, includes notes, missing commas - -```bash -112Y9MOI0cSuhXXmtdjbwbggmiUTXtpGvz26djJscfJKRfoj2sUN, 112YoUnnjdbi2qW51UNdcfIfzLvfzLwmWkvE7ZO1LJoz8j5XyfGu, -112snBh48MrKFwkzT29ciqPDjFkpq0FtQI6uCv4EpOK6QfW9w45N112ugTSdVRHWvO85WrAuV5JvcytQYRnkgdxtxgXKNOGMi1XYXQR7, 112ZTwJcUBGC65J3XjQGKWmNkcGspVFOkDyZJVCRs5vIQrpPyT8O, 112VDtGIy9COHkZFdsBQyAXM9aOfbQ2oIKSOOBSVbpwV38dxnDN5, 113oCV3rIwxwwG2umgc0vBbSqRm856HrUFRdgWAJERXkA9M5aVmu -113Wcs25X8JYDVzWKgAgf1nzkUnS2i9XLrYV4bbo9RL4Xv2Q4Yay - spoofer -113nRmEovrRvQF6UNFrSv79Ys9Thuw6ajAJrN7wpmen9KbqZO7nU - probably colocated -114xSLeZSB6DaWkirHGZsxQ0kfs2DwZ8zIFQQWRnQshshcZ0zXl8 - too many beacons -``` - ---- - -## Voting - -A connected Helium Wallet can vote on the legitimacy or abnormality of a given Hotspot. This -community feedback assists in the evaluation process and is an essential factor in the evaluation -process. - -To submit a vote, navigate to a Hotspot page on Crowdspot and below the map, select the option to -Vote that the Hotspot is `Legitimate`, or that the Hotspot is `Abnormal` given the information -provided. - -
-
-
- -
-
- -
-
-
- -:::note Voter Verification - -You must be logged in to Crowdspot by connecting a valid Helium Wallet to cast a vote. - -See the section below on how to -[log in with the Helium Wallet App](./crowdspot#log-in-with-the-helium-wallet-app) - -::: - ---- - -## Hotspot Evaluation Metrics - -Crowdspot provides insight to several metrics for a given Hotspot that can be used to assist the -Community in identifying abnormal Hotpots and validating legitimate Hotspots. - -:::note Current Denylist Status - -If a Hotspot is currently on the Denylist, they will have a special badge on their page. This badge -is -not- present for Hotspots -not- currently on the Denylist. - -
-
-
- -
-
-

- This example badge includes "+ 54 other appearances", which indicates that this - particular Hotspot appears on the latest Denylist and in 54 previous updates of the - Denylist. -

-
-
-
- -::: - -### Location Confidence - -Using witness receipt data, 1,000 programmatic estimates of the asserted location are made to derive -a predicted location of a Hotspot. - -The Location Confidence Score metric reflects what percentage of estimations are within range of the -Hotspots asserted location. - -When under 20% of estimations are further than 2.3 km from the asserted location, we would describe -that Hotspot as abnormal. - -### Witness Maker Diversity - -The Witness Maker Diversity metric gives the percentage of Hotspots witnessed by the original -Hotspot that are produced by different Makers. - -When under 15% of the Hotspots being witnessed are made by different Makers, then we would describe -that Hotspot as abnormal. - -### Witness SNR versus RSSI Plot - -This graph compares a Hotspot's Signal-to-Noise ratio (SNR) against its Received Signal Strength -Indicator (RSSI). In general, small RSSI values correlate to a low SNR and vice versa. - -
-
-
- Legitimate Hotspot - -

- Witnesses will likely show a more natural, positive correlation over a broad range of RSSI - and SNR values. -

-
-
- Abnormal Hotspot - -

- Witnesses tend to appear 'grid-like' and concentrated within a much smaller range of RSSI - (±3bm) and high SNR (+10db). -

-
-
-
- -### Hotspot Witness Graph - -The graph shows a central Hotspot, the Hotspot’s immediate witnesses, and other witnesses -connections within a 10 km range. Each line indicates a witness connection between two Hotspots. -Hotspot owners are represented by unique colors, where Hotspots owned by the same Wallet address -will be displayed in the same color. - -
-
-
- Legitimate Hotspot - -

- The central Hotspot's witnesses vary with placement and the natural terrain of the area. - These witness connections are more random and feature a wider variety of Hotspot owners. -

-
-
- Abnormal Hotspot - -

- The central Hotspot can only see a specific subset of Hotspots. This is illustrated by a - sphere-like containment of Hotspots witnessing only each other but failing to connect - outside the containment. There may be less variation of Hotspot owners in an abnormal - cluster. -

-
-
-
- -### Witness RSSI versus Distance - -As the distance between Hotspots increases, the received signal strength (RSSI) decreases due to -environmental factors. Signal strength ranges between -136 to -80 dBm, with -90 to -110 dBm is a -very strong RSSI (unlikely in real life), while -130 dBm is very weak. Similarly, a high R² value -indicates strong correlation and goodness of fit. - -
-
-
- Legitimate Hotspot - -

- A Hotspot's Witness RSSI compared to distance has a weak “fit” seen through the larger - deviations from the curve. This results in a low R² value closer to 0. -

-
-
- Abnormal Hotspot - -

- A Hotspot's Witness RSSI compared to distance has a predictable, strong “fit” with minimal - deviations from the curve. This results in a high R² value close to 1, suggesting few - effects from environmental factors. -

-
-
-
- ---- - -## Evaluation Process - -Hotspots in a submission are evaluated on a variety of factors. These factors include, but are not -limited to Trust Scores, community provided text reasoning, and data found on -[Crowdspot.io](http://Crowdspot.io), including graph metrics, Witness Maker Diversity, and Location -Confidence. - -### Submission Status - -A submission is given a status to update the community on it’s evaluation progress. - -#### Pending - -This is the default state of a submission. - -> In this state, the Denylist Maintainers are working on evaluating the submission. - -#### Accepted - -This state indicates that the submission request has been accepted. - -> The Hotspots in this submission are either in the Denylist or will be added in the next version. - -#### Declined - -This state indicates that the submission request has been declined. - -> This may happen when Hotspots requested to be added are found to be legitimate or when Hotspots -> that have been requested to be removed cannot be proven to be legitimate. - -### Trust Score - -Crowdspot will leverage algorithms to increase efficiency and accurately detect gaming Hotspots. -Trust Scores will be assigned to every submitted Hotspot to assist in the evaluation. - -A Trust Score is a score assigned to Hotspot based on a combination of metrics found on -[Crowdspot.io](http://crowdspot.io/). These metrics are primarily graph data and include the Hotspot -Witness graph, the Witness SNR vs. RSSI graph, and the Witness RSSI vs. Distance graph. - -The Trust Score compares these graph metrics to a sample of known gaming Hotspots from the Denylist, -as well as a sample of known legitimate Hotspots, to determine the relative legitimacy of the -Hotspot. - ---- - -## Issues Currently on GitHub - -Current issues on GitHub will continue to be evaluated. Therefore, if you currently have an issue on -GitHub, there is no need to re-submit your request on Crowdspot.io. - -:::info What will happen to the Denylist repository on GitHub? - -While the community will no longer be able to open an issue, Pull Requests will remain on Github -with multi-signature verification for the time being. - -Hotspots submitted on Crowdspot will be pushed to the Denylist via GitHub. - -::: - ---- - -## Removing a Hotspot from the Denylist - -:::warning Removing A Hotspot from the Denylist with Crowdspot - -If a Hotspot has been added to the Denylist in error, the **only** method to have it removed is to -file a Removal Request using Crowdspot. - -**Instructions for submitting a removal request can be found on the -[Denylist Removal Request documentation page.](/iot/denylist-removals)** - -::: diff --git a/docs/network-iot/denylist-removals.mdx b/docs/network-iot/denylist-removals.mdx deleted file mode 100644 index 692e0b670..000000000 --- a/docs/network-iot/denylist-removals.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -id: denylist-removals -title: Denylist Removals -pagination_label: Denylist Removals -sidebar_label: Denylist Removals -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/denylist-removals ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Denylist Removal Submissions - -To submit a Hotspot for removal from the Denylist, start by logging in with your Helium Wallet and -clicking on the `Submit Denylist Request` button on the [Crowdspot.io](https://crowdspot.io/) home -page. - -### Log In with the Helium Wallet App - -To associate a Helium Wallet address, click the `Login` menu bar item on the -[Crowdspot homepage](https://crowdspot.io/) and scan the QR code with your phone's camera or QR code -scanner. - - - -Once you have scanned the QR Code, the Helium Wallet app will open and prompt you to authenticate -Crowdspot. - -1. **Confirm Connection Start**: Confirm that you _do_ want to connect a Helium Wallet to Crowdspot. -2. **Choose Wallet**: Choose the account you would like to use with Crowdspot, and tap Continue. -3. **Authenticate**: Send a transaction to the Helium blockchain to complete login. - -
-
-
- - Confirm Connection Start -
-
- - Choose Wallet -
-
- - Authenticate -
-
-
- -

- -If you are already logged in, you will see a Profile Badge and a portion of the connected wallet -address. The Profile badge will match in the Helium Wallet app and on Crowdspot. - -Otherwise, if no account is logged in, no Profile Badge is visible, and the `Login` menu bar item is -shown. - -## Submit a Removal Request - -:::caution Security - -For security reasons, text and visual evidence will only be accessible to Denylist maintainers. - -Although you cannot view this evidence when you click on a submission, we assure you that it can be -seen and is being evaluated. - -::: - -In an ideal world, Legitimate Hotspots are appropriately screened and not added to the Denylist. -Still, when this _does_ happen, Hotspot Owners can submit information and evidence to _potentially_ -have a Hotspot removed from the Denylist. - - - -### Submission Type - -On the Submission form, select the `Removal` radio button under Submission Type. - -### Visual Evidence - -Denylist Removal submissions can optionally include visual evidence, such as screenshots or other -images, to support the removal claim. **At this time, visual evidence can be submitted as a URL** -with a limit of 3 URLs per submission. - -- For multiple images, we recommend using a cloud image storage platform, such as - [Google Photos](https://photos.google.com/) or [Flickr](https://www.flickr.com/). Upload your - images and share a link to the folder here. **Please ensure you enable the correct sharing - settings, as links will be publicly available.** -- For a single image, we recommend using a free image-to-link converter and paste the URL in the - text box. - -### Written Reasoning - -Submitting a written description to support the Removal Request submission provides valuable insight -for evaluation. A minimum of 150 characters is required. - -### Create the Submission - -Once you have added all the required and optional information, click the `Create Submission` button. - -Users can view submission’s ID number after they have successfully created a submission. This ID -number will appear in the submission's confirmation message (ex: Submission #1234). **Please note, -that this number ID will only appear one time upon submitting, so please save it for future -reference.** - -You can view the status of your submission on the -[Submissions page](https://www.crowdspot.io/submissions/), linked in the -[Crowdspot](https://crowdspot.io/) menu bar. diff --git a/docs/network-iot/denylist.mdx b/docs/network-iot/denylist.mdx deleted file mode 100644 index 5f02f4dac..000000000 --- a/docs/network-iot/denylist.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -id: denylist -title: Denylist -pagination_label: Denylist -sidebar_label: Denylist -description: The Helium Network Denylist -image: https://docs.helium.com/img/link-image.png -slug: /iot/denylist ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Denylist - -:::warning Removing A Hotspot from the Denylist with Crowdspot - -If a Hotspot has been added to the Denylist in error, the **only** method to have it removed is to -file a Removal Request using Crowdspot. - -**Instructions for submitting a removal request can be found on the -[Denylist Removal Request documentation page.](/iot/denylist-removals)** - -::: - -## What is the Denylist? - -The Denylist is a list of Hotspot public keys and a cryptographic signature that have been -identified not to be accurately contributing to Network coverage or are otherwise circumventing the -good faith of the Network in an attempt to earn Rewards. Rewards gaming by dishonest actors, even as -a small percentage of the Network, erodes Network integrity. - -Examples include, but are not limited to: Cluster Packet Forwarders, Misasserted Locations, -Misasserted Antennas, Multiple or Shared Antennas, Attenuators, Amplifiers and Data Credit Farming - -The Denylist is another tool in a broader range of tools to incentivize Hotspots on the Network to -provide the most honest and accurate wireless coverage possible. - -The Denylist is sourced from the community to keep the Network decentralized. Credible -decentralization ensures that no one entity can control the Network. Any coordinated effort to game -rewards, block data transfer, or censor information to benefit one party while harming another, -undermines our mission of creating global, open wireless Networks. - -:::info - -The Helium Foundation has not and will never run its own Denylist out of the interest of -decentralization. - -::: - -## Network Impact - -**Hotspot Owners:** For any well-asserted, appropriately compensated Hotspot, the Denylist only -benefits you. By denying HNT to dishonest Hotspots, that HNT is shared amongst honest Hotspots. - -**Bad Actors:** The message is simple: Stop. If your Hotspots are earning HNT without providing -coverage, they are likely to appear on the Denylist and will stop earning HNT Rewards. - - - -### Denylist Generation - -Denylist generation is handled by the open-source -[xorf-generator library](https://github.com/helium/xorf-generator). This tool both allows for key -signing of the Denylist as well as the construction of the binary filter used to check transactions -against. - -## Frequently Asked Questions - -**What if the Denylist doesn’t have all of the gaming Hotspots?** - -The Denylist is one disincentive of many to keep gaming at bay. Above all, Proof of Coverage and -more direct detection methods all work in concert to ensure the security of PoC. - -**Will the Denylist have the ability to block data transfer or rewards for data transfer?** - -Yes, any Hotspot considered ‘denied’ of Proof of Coverage rewards will still be able to act as a -data-only Hotspot, providing data transfer network coverage where possible, but these hotspots will -be blocked from data transfer rewards. Because it is generally the case that these Hotspots did not -provide sensor coverage in the first place, hence their inclusion. Is it important to understand the -uninterrupted data transfer ability in the case of errant inclusions. diff --git a/docs/network-iot/frequency-plans/frequency-plans.mdx b/docs/network-iot/frequency-plans/frequency-plans.mdx deleted file mode 100644 index 462f4370c..000000000 --- a/docs/network-iot/frequency-plans/frequency-plans.mdx +++ /dev/null @@ -1,327 +0,0 @@ ---- -id: frequency-plans -title: Frequency Plans -pagination_label: Frequency Plans -sidebar_label: Frequency Plans -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/frequency-plans ---- - -# Frequencies on the Helium Network - -Helium's LoRaWAN Network is built upon 8-channel gateways. This page will help you confirm the -appropriate frequencies for gateway configuration for each country. - -Feel free to use -[our packet forwarder configuration examples](https://github.com/helium/sx1302_hal/tree/helium/hotspot/packet_forwarder) -here. - -:::warning - -LoRa gateways on the Helium Network must transmit on uplink frequencies. Some gateways limit their -transmit range to downlink frequencies and special configuration may be necessary. - -::: - -## Frequency Plans - -Each frequency/channel supports multiple spreading factors. Lower spreading factors correspond to -higher data rates, but shorter transmission ranges and less receiver sensitivity. - -### US915 - -Also known as **US902-928** - -#### Uplink - -| Channel Number | Frequency (MHZ) | Spreading Factor | -| :------------- | :-------------- | :-------------------- | -| 8 | 903.9 | SF7BW125 to SF10BW125 | -| 9 | 904.1 | SF7BW125 to SF10BW125 | -| 10 | 904.3 | SF7BW125 to SF10BW125 | -| 11 | 904.5 | SF7BW125 to SF10BW125 | -| 12 | 904.7 | SF7BW125 to SF10BW125 | -| 13 | 904.9 | SF7BW125 to SF10BW125 | -| 14 | 905.1 | SF7BW125 to SF10BW125 | -| 15 | 905.3 | SF7BW125 to SF10BW125 | -| 65 | 904.6 | SF8BW500 | - -#### Downlink - -| Channel Number | Frequency (MHZ) | Spreading Factor | -| :------------- | :-------------- | :-------------------------- | -| 0 | 923.3 | SF7BW500 to SF12BW500 (RX1) | -| 1 | 923.9 | SF7BW500 to SF12BW500 (RX1) | -| 2 | 924.5 | SF7BW500 to SF12BW500 (RX1) | -| 3 | 925.1 | SF7BW500 to SF12BW500 (RX1) | -| 4 | 925.7 | SF7BW500 to SF12BW500 (RX1) | -| 5 | 926.3 | SF7BW500 to SF12BW500 (RX1) | -| 6 | 926.9 | SF7BW500 to SF12BW500 (RX1) | -| 7 | 927.5 | SF7BW500 to SF12BW500 (RX1) | -| 0 | 923.3 | SF12BW500 (RX2) | - -### AU915_SB1 - -- AU915 sub-band 1 (ch 0 to 7) - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------- | -| 915.2 | SF7BW125 to SF12BW125 | -| 915.4 | SF7BW125 to SF12BW125 | -| 915.6 | SF7BW125 to SF12BW125 | -| 915.8 | SF7BW125 to SF12BW125 | -| 916.0 | SF7BW125 to SF12BW125 | -| 916.2 | SF7BW125 to SF12BW125 | -| 916.4 | SF7BW125 to SF12BW125 | -| 916.6 | SF7BW125 to SF12BW125 | -| 915.9 | SF8BW500 | - -#### Downlink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------------- | -| 923.3 | SF7BW500 to SF12BW500 (RX1) | -| 923.9 | SF7BW500 to SF12BW500 (RX1) | -| 924.5 | SF7BW500 to SF12BW500 (RX1) | -| 925.1 | SF7BW500 to SF12BW500 (RX1) | -| 925.7 | SF7BW500 to SF12BW500 (RX1) | -| 926.3 | SF7BW500 to SF12BW500 (RX1) | -| 926.9 | SF7BW500 to SF12BW500 (RX1) | -| 927.5 | SF7BW500 to SF12BW500 (RX1) | -| 923.3 | SF12BW500 (RX2) | - -### AU915_SB2 - -- AU915 sub-band 2 (ch 8 to 15) - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------- | -| 916.8 | SF7BW125 to SF12BW125 | -| 917.0 | SF7BW125 to SF12BW125 | -| 917.2 | SF7BW125 to SF12BW125 | -| 917.4 | SF7BW125 to SF12BW125 | -| 917.6 | SF7BW125 to SF12BW125 | -| 917.8 | SF7BW125 to SF12BW125 | -| 918.0 | SF7BW125 to SF12BW125 | -| 918.2 | SF7BW125 to SF12BW125 | -| 917.5 | SF8BW500 | - -#### Downlink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------------- | -| 923.3 | SF7BW500 to SF12BW500 (RX1) | -| 923.9 | SF7BW500 to SF12BW500 (RX1) | -| 924.5 | SF7BW500 to SF12BW500 (RX1) | -| 925.1 | SF7BW500 to SF12BW500 (RX1) | -| 925.7 | SF7BW500 to SF12BW500 (RX1) | -| 926.3 | SF7BW500 to SF12BW500 (RX1) | -| 926.9 | SF7BW500 to SF12BW500 (RX1) | -| 927.5 | SF7BW500 to SF12BW500 (RX1) | -| 923.3 | SF12BW500 (RX2) | - -### AU915_SB6 (DualPlan) - -- AU915 sub-band 6 (ch 40 to 47) (for DualPlan only) - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------- | -| 923.2 | SF7BW125 to SF12BW125 | -| 923.4 | SF7BW125 to SF12BW125 | -| 923.6 | SF7BW125 to SF12BW125 | -| 923.8 | SF7BW125 to SF12BW125 | -| 924.0 | SF7BW125 to SF12BW125 | -| 924.2 | SF7BW125 to SF12BW125 | -| 924.4 | SF7BW125 to SF12BW125 | -| 924.6 | SF7BW125 to SF12BW125 | - -#### Downlink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------------- | -| 923.3 | SF7BW500 to SF12BW500 (RX1) | -| 923.9 | SF7BW500 to SF12BW500 (RX1) | -| 924.5 | SF7BW500 to SF12BW500 (RX1) | -| 925.1 | SF7BW500 to SF12BW500 (RX1) | -| 925.7 | SF7BW500 to SF12BW500 (RX1) | -| 926.3 | SF7BW500 to SF12BW500 (RX1) | -| 926.9 | SF7BW500 to SF12BW500 (RX1) | -| 927.5 | SF7BW500 to SF12BW500 (RX1) | -| 923.3 | SF12BW500 (RX2) | - -### EU868 - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :--------------------------------- | -| 868.1 | SF7BW125 to SF12BW125 | -| 868.3 | SF7BW125 to SF12BW125 and SF7BW250 | -| 868.5 | SF7BW125 to SF12BW125 | -| 867.1 | SF7BW125 to SF12BW125 | -| 867.3 | SF7BW125 to SF12BW125 | -| 867.5 | SF7BW125 to SF12BW125 | -| 867.7 | SF7BW125 to SF12BW125 | -| 867.9 | SF7BW125 to SF12BW125 | -| 868.8 | FSK | - -#### Downlink - -- Uplink channels 1-9 (RX1) -- Helium uses the default parameters: 869.525 MHz / DR0 (SF12, 125 kHz) - -### AS923_1 - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :--------------------------------- | -| 923.2 | SF7BW125 to SF12BW125 and SF7BW250 | -| 923.4 | SF7BW125 to SF12BW125 | -| 923.6 | SF7BW125 to SF12BW125 | -| 923.8 | SF7BW125 to SF12BW125 | -| 924.0 | SF7BW125 to SF12BW125 | -| 924.2 | SF7BW125 to SF12BW125 | -| 924.4 | SF7BW125 to SF12BW125 | -| 924.6 | SF7BW125 to SF12BW125 | - -#### Downlink - -- Uplink channels 1-8 (RX1) -- Helium uses the default parameters: 923.2 MHz / DR2 (SF10, 125 kHz) - -### AS923_1 - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :--------------------------------- | -| 923.2 | SF7BW125 to SF12BW125 and SF7BW250 | -| 923.4 | SF7BW125 to SF12BW125 | -| 923.6 | SF7BW125 to SF12BW125 | -| 923.8 | SF7BW125 to SF12BW125 | -| 924.0 | SF7BW125 to SF12BW125 | -| 924.2 | SF7BW125 to SF12BW125 | -| 924.4 | SF7BW125 to SF12BW125 | -| 924.6 | SF7BW125 to SF12BW125 | - -#### Downlink - -- Uplink channels 1-8 (RX1) -- Helium uses the default parameters: 923.2 MHz / DR2 (SF10, 125 kHz) - -### AS923_1B (Malaysia) - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :--------------------------------- | -| 922.0 | SF7BW125 to SF12BW125 and SF7BW250 | -| 922.2 | SF7BW125 to SF12BW125 | -| 922.4 | SF7BW125 to SF12BW125 | -| 922.6 | SF7BW125 to SF12BW125 | -| 922.8 | SF7BW125 to SF12BW125 | -| 923.0 | SF7BW125 to SF12BW125 | -| 923.2 | SF7BW125 to SF12BW125 | -| 923.4 | SF7BW125 to SF12BW125 | - -#### Downlink - -- Uplink channels 1-8 (RX1) -- Helium uses the default parameters: 923.2 MHz / DR2 (SF10, 125 kHz) - -### AS923_2 - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :--------------------------------- | -| 921.4 | SF7BW125 to SF12BW125 and SF7BW250 | -| 921.6 | SF7BW125 to SF12BW125 | -| 921.8 | SF7BW125 to SF12BW125 | -| 922.0 | SF7BW125 to SF12BW125 | -| 922.2 | SF7BW125 to SF12BW125 | -| 922.4 | SF7BW125 to SF12BW125 | -| 922.6 | SF7BW125 to SF12BW125 | -| 922.8 | SF7BW125 to SF12BW125 | - -#### Downlink - -- Uplink channels 1-8 (RX1) -- Helium uses the default parameters: 923.2 MHz / DR2 (SF10, 125 kHz) - -### AS923_3 - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :--------------------------------- | -| 916.6 | SF7BW125 to SF12BW125 and SF7BW250 | -| 916.8 | SF7BW125 to SF12BW125 | -| 917.0 | SF7BW125 to SF12BW125 | -| 917.2 | SF7BW125 to SF12BW125 | -| 917.4 | SF7BW125 to SF12BW125 | -| 917.6 | SF7BW125 to SF12BW125 | -| 917.8 | SF7BW125 to SF12BW125 | -| 918.0 | SF7BW125 to SF12BW125 | - -#### Downlink - -- Uplink channels 1-8 (RX1) -- Helium uses the default parameters: 923.2 MHz / DR2 (SF10, 125 kHz) - -### AS923_4 - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :--------------------------------- | -| 917.3 | SF7BW125 to SF12BW125 and SF7BW250 | -| 917.5 | SF7BW125 to SF12BW125 | -| 917.7 | SF7BW125 to SF12BW125 | -| 917.9 | SF7BW125 to SF12BW125 | -| 918.1 | SF7BW125 to SF12BW125 | -| 918.3 | SF7BW125 to SF12BW125 | -| 918.5 | SF7BW125 to SF12BW125 | -| 918.7 | SF7BW125 to SF12BW125 | - -#### Downlink - -- Uplink channels 1-8 (RX1) -- Helium uses the default parameters: 923.2 MHz / DR2 (SF10, 125 kHz) - -### CN470 - -#### Uplink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------- | -| 486.3 | SF7BW125 to SF12BW125 | -| 486.5 | SF7BW125 to SF12BW125 | -| 486.7 | SF7BW125 to SF12BW125 | -| 486.9 | SF7BW125 to SF12BW125 | -| 487.1 | SF7BW125 to SF12BW125 | -| 487.3 | SF7BW125 to SF12BW125 | -| 487.5 | SF7BW125 to SF12BW125 | -| 487.7 | SF7BW125 to SF12BW125 | - -#### Downlink - -| Frequency (MHZ) | Spreading Factor | -| :-------------- | :-------------------------- | -| 506.7 | SF7BW125 to SF12BW125 (RX1) | -| 506.9 | SF7BW125 to SF12BW125 (RX1) | -| 507.1 | SF7BW125 to SF12BW125 (RX1) | -| 507.3 | SF7BW125 to SF12BW125 (RX1) | -| 507.5 | SF7BW125 to SF12BW125 (RX1) | -| 507.7 | SF7BW125 to SF12BW125 (RX1) | -| 507.9 | SF7BW125 to SF12BW125 (RX1) | -| 508.1 | SF7BW125 to SF12BW125 (RX1) | -| 505.3 | SF12BW125 (RX2) | diff --git a/docs/network-iot/frequency-plans/region-plans.mdx b/docs/network-iot/frequency-plans/region-plans.mdx deleted file mode 100644 index 65bc39da8..000000000 --- a/docs/network-iot/frequency-plans/region-plans.mdx +++ /dev/null @@ -1,408 +0,0 @@ ---- -id: region-plans -title: Region Plans -pagination_label: Region Plans -sidebar_label: Region Plans -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/region-plans ---- - -# Frequencies by Region on the Helium Network - -Helium's LoRaWAN Network is built upon 8-channel gateways. This page will help you confirm the -appropriate frequencies for gateway configuration for each region. - -## Frequency Plans by Country - -Where a frequency plan is "Unknown", it often means the local telecommunications or radio authority -in that country has not yet created -[Short Range Device (SRD)](https://en.wikipedia.org/wiki/Short-range_device) regulations for either -the 800 Mhz or 900 Mhz spectrum bands. Helium gateways cannot be operated in countries without valid -SRD regulations. Contact the LoRa Alliance for further information - -[LoRa Alliance](https://lora-alliance.org/contact/) - -Note - Helium does not support EU433 and has no plans to ever support EU433 given it is a legacy -band. Countries with EU433 should consider regulations to support the 800 or 900 Mhz SRD bands. - -#### A - -| Country | Frequency Plan | -| ----------------------- | -------------- | -| Afghanistan | Unknown | -| Aland Islands | EU868 | -| Albania | EU868 | -| Algeria | AS923_3 | -| American Samoa | US915 | -| Andorra | EU868 | -| Angola | Unknown | -| Anguilla | AU915_SB1 | -| Antarctica - Chilean | Unknown | -| Antarctica - Australian | Unknown | -| Antarctica - British | Unknown | -| Antarctica - Argentine | Unknown | -| Antigua and Barbuda | Unknown | -| Argentina | AU915_SB1 | -| Armenia | EU868 | -| Aruba | Unknown | -| Australia | AU915_SB2 | -| Austria | EU868 | -| Azerbaijan | EU433 | - -#### B - -| Country | Frequency Plan | -| ------------------------------ | -------------- | -| Bahamas | US915 | -| Bahrain | EU868 | -| Bangladesh | AS923_1 | -| Barbados | AU915_SB1 | -| Belarus | EU868 | -| Belgium | EU868 | -| Belize | AU915_SB1 | -| Benin | EU868 | -| Bermuda | US915 | -| Bhutan | EU868 | -| Bolivia | AS923_1 | -| Bonaire, Sint Eustatius & Saba | EU868 | -| Bosnia and Herzegovina | EU868 | -| Botswana | EU868 | -| Bouvet Island | EU868 | -| Brazil | AU915_SB1 | -| British Indian Ocean Territory | Unknown | -| British Virgin Islands | AU915_SB1 | -| Brunei | AS923_1 | -| Bulgaria | EU868 | -| Burkina Faso | Unknown | -| Burundi | EU868 | - -#### C - -| Country | Frequency Plan | -| ------------------------ | -------------- | -| Cambodia | AS923_1 | -| Cameroon | EU433 | -| Canada | US915 | -| Cape Verde | EU868 | -| Cayman Islands | US915 | -| Central African Republic | Unknown | -| Chad | Unknown | -| Chile | AU915_SB1 | -| China | CN470 | -| Christmas Island | AU915_SB2 | -| Cocos [Keeling] Islands | AU915_SB2 | -| Colombia | AU915_SB1 | -| Comoros | EU868 | -| Congo [DRC] | Unknown | -| Congo [Republic] | Unknown | -| Cook Islands | AS923_1 | -| Costa Rica | AS923_1 | -| Côte d'Ivoire | EU868 | -| Croatia | EU868 | -| Cuba | AS923_3 | -| Curaçao | AS923_1 | -| Cyprus | EU868 | -| Czech Republic | EU868 | - -#### D - -| Country | Frequency Plan | -| ------------------ | -------------- | -| Denmark | EU868 | -| Djibouti | Unknown | -| Dominica | AU915_SB1 | -| Dominican Republic | AU915_SB1 | - -#### E - -| Country | Frequency Plan | -| -------------------- | -------------- | -| Ecuador | AU915_SB1 | -| Egypt | EU868 | -| El Salvador | AU915_SB1 | -| Equatorial Guinea | EU868 | -| Eritrea | Unknown | -| Estonia | EU868 | -| Eswatini [Swaziland] | Unknown | -| Ethiopia | Unknown | - -#### F - -| Country | Frequency Plan | -| --------------------------------- | -------------- | -| Falkland Islands [Islas Malvinas] | EU868 | -| Faroe Islands | EU868 | -| Fiji | Unknown | -| Finland | EU868 | -| France | EU868 | -| French Guiana | EU868 | -| French Polynesia | EU868 | -| French Southern Territories | EU868 | - -#### G - -| Country | Frequency Plan | -| ------------- | -------------- | -| Gabon | Unknown | -| Gambia | EU433 | -| Gaza Strip | Unknown | -| Georgia | EU868 | -| Germany | EU868 | -| Ghana | EU433 | -| Gibraltar | EU868 | -| Greece | EU868 | -| Greenland | EU868 | -| Grenada | AU915_SB1 | -| Guadeloupe | EU868 | -| Guam | US915 | -| Guatemala | AU915_SB1 | -| Guernsey | EU868 | -| Guinea | EU433 | -| Guinea-Bissau | Unknown | -| Guyana | US915 | - -#### H - -| Country | Frequency Plan | -| --------------------------------- | -------------- | -| Haiti | Unknown | -| Heard Island and McDonald Islands | AU915_SB2 | -| Honduras | AU915_SB1 | -| Hong Kong | AS923_1 | -| Hungary | EU868 | - -#### I - -| Country | Frequency Plan | -| ----------- | -------------- | -| Iceland | EU868 | -| India | IN865 | -| Indonesia | AS923_2 | -| Iran | EU868 | -| Iraq | EU868 | -| Ireland | EU868 | -| Isle of Man | EU868 | -| Israel | AS923_4 | -| Italy | EU868 | - -#### J - -| Country | Frequency Plan | -| ------- | -------------- | -| Jamaica | AU915_SB1 | -| Japan | AS923_1 | -| Jersey | EU868 | -| Jordan | IN865 | - -#### K - -| Country | Frequency Plan | -| ---------- | -------------- | -| Kazakhstan | IN865 | -| Kenya | EU868 | -| Kiribati | Unknown | -| Kosovo | EU868 | -| Kuwait | EU868 | -| Kyrgyzstan | Unknown | - -#### L - -| Country | Frequency Plan | -| ------------- | -------------- | -| Laos | AS923_1 | -| Latvia | EU868 | -| Lebanon | EU868 | -| Lesotho | EU433 | -| Liberia | Unknown | -| Libya | Unknown | -| Liechtenstein | EU868 | -| Lithuania | EU868 | -| Luxembourg | EU868 | - -#### M - -| Country | Frequency Plan | -| ---------------- | -------------- | -| Macau | AS923_1 | -| North Macedonia | EU868 | -| Madagascar | EU868 | -| Malawi | Unknown | -| Malaysia | AS923_1B | -| Maldives | Unknown | -| Mali | EU433 | -| Malta | EU868 | -| Marshall Islands | Unknown | -| Martinique | EU868 | -| Mauritania | EU868 | -| Mauritius | EU433 | -| Mayotte | EU868 | -| Mexico | US915 | -| Micronesia | Unknown | -| Moldova | EU868 | -| Monaco | EU868 | -| Mongolia | Unknown | -| Montenegro | EU868 | -| Montserrat | AU915_SB1 | -| Morocco | EU433 | -| Mozambique | Unknown | -| Myanmar [Burma] | AS923_1 | - -#### N - -| Country | Frequency Plan | -| ------------------------ | -------------- | -| Namibia | EU868 | -| Nauru | Unknown | -| Nepal | Unknown | -| Netherlands | EU868 | -| Netherlands Antilles | EU868 | -| New Caledonia | EU868 | -| New Zealand | AS923_1C | -| Nicaragua | AU915_SB1 | -| Niger | IN865 | -| Nigeria | EU868 | -| Niue | AS923_1 | -| Norfolk Island | AU915_SB2 | -| North Korea | Unknown | -| Northern Mariana Islands | US915 | -| Norway | EU868 | - -#### O - -| Country | Frequency Plan | -| ------- | -------------- | -| Oman | EU868 | - -#### P - -| Country | Frequency Plan | -| ----------------------- | -------------- | -| Pakistan | AS923 | -| Palau | Unknown | -| Palestinian Territories | Unknown | -| Panama | AU915_SB1 | -| Papua New Guinea | AS923_1 | -| Paraguay | AU915_SB1 | -| Peru | AU915_SB1 | -| Philippines | AS923_3 | -| Pitcairn Islands | Unknown | -| Poland | EU868 | -| Portugal | EU868 | -| Puerto Rico | US915 | - -#### Q - -| Country | Frequency Plan | -| ------- | -------------- | -| Qatar | EU868 | - -#### R - -| Country | Frequency Plan | -| ------- | -------------- | -| Réunion | EU868 | -| Romania | EU868 | -| Russia | RU864 | -| Rwanda | EU868 | - -#### S - -| Country | Frequency Plan | -| -------------------------------------------- | -------------- | -| Sahrawi Arab Democratic Republic | Unknown | -| Saint Barthelemy | EU868 | -| Saint Helena | Unknown | -| Saint Kitts and Nevis | AU915_SB1 | -| Saint Lucia | AU915_SB1 | -| Saint Martin | EU868 | -| Saint Pierre and Miquelon | EU868 | -| Saint Vincent and the Grenadines | AU915_SB1 | -| Samoa | EU868 | -| San Marino | EU868 | -| São Tomé and Príncipe | Unknown | -| Saudi Arabia | EU868 | -| Senegal | EU868 | -| Serbia | EU868 | -| Seychelles | EU433 | -| Sierra Leone | EU868 | -| Singapore | AS923_1 | -| Slovakia | EU868 | -| Slovenia | EU868 | -| Solomon Islands | AS923_1 | -| Somalia | EU868 | -| South Africa | EU868 | -| South Georgia and the South Sandwich Islands | EU868 | -| South Korea | KR920 | -| South Sudan | Unknown | -| Spain | EU868 | -| Sri Lanka | AS923_1 | -| Sudan | Unknown | -| Suriname | AU915_SB1 | -| Svalbard and Jan Mayen | EU868 | -| Swaziland see Eswatini | - | -| Sweden | EU868 | -| Switzerland | EU868 | -| Syria | EU868 | - -#### T - -| Country | Frequency Plan | -| ------------------------ | -------------- | -| Taiwan | AS923_1 | -| Tajikistan | Unknown | -| Tanzania | AS923_1 | -| Thailand | AS923_1 | -| Timor-Leste | Unknown | -| Togo | EU433 | -| Tokelau | AS923_1 | -| Tonga | AU915_SB1 | -| Trinidad and Tobago | AU915_SB1 | -| Tunisia | EU868 | -| Turkey | EU868 | -| Turkmenistan | Unknown | -| Turks and Caicos Islands | AU915_SB1 | -| Tuvalu | Unknown | - -#### U - -| Country | Frequency Plan | -| --------------------------- | -------------- | -| U.S. Minor Outlying Islands | US915 | -| U.S. Virgin Islands | US915 | -| Uganda | AS923_1 | -| Ukraine | EU868 | -| United Arab Emirates | EU868 | -| United Kingdom | EU868 | -| United States | US915 | -| Uruguay | AU915_SB1 | -| Uzbekistan | EU433 | - -#### V - -| Country | Frequency Plan | -| ----------------------- | -------------- | -| Vanuatu | AS923_3 | -| Vatican City (Holy See) | EU868 | -| Venezuela | AS923_1 | -| Vietnam | AS923_2 | -| Virgin Islands (UK) | AU915_SB1 | - -#### W - -| Country | Frequency Plan | -| ----------------- | -------------- | -| Wallis and Futuna | EU868 | -| Western Sahara | Unknown | - -#### Y - -| Country | Frequency Plan | -| ------- | -------------- | -| Yemen | Unknown | - -#### Z - -| Country | Frequency Plan | -| -------- | -------------- | -| Zambia | EU868 | -| Zimbabwe | EU868 | diff --git a/docs/network-iot/hotspots-iot/data-only-hotspots.mdx b/docs/network-iot/hotspots-iot/data-only-hotspots.mdx new file mode 100644 index 000000000..415a641d2 --- /dev/null +++ b/docs/network-iot/hotspots-iot/data-only-hotspots.mdx @@ -0,0 +1,105 @@ +--- +id: data-only-hotspots +title: Data-Only Hotspots +pagination_label: Data-Only Hotspots +sidebar_label: Introduction +description: Helium Data-Only Hotspot Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/data-only-hotspots +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + +
+
+ +Any LoRaWAN gateway can be used to transfer data through the Helium Network. Data-only Hotspots are +eligible for **network data transfer rewards** but not **Proof-of-Coverage rewards**. This class of +Hotspot offers a flexible path for companies and organizations looking to leverage the Helium +Network for their IoT needs. + +Since data-only Hotspots do not earn Proof-of-Coverage rewards, they may be permissionlessly added +to the network. When added to the blockchain, they will earn HNT for transferring network data. + +## Basic Architecture + +The [gateway-rs](https://github.com/helium/gateway-rs) client backs both data-only Hotspots as well +as Proof-of-Coverage enabled IoT Hotspots. Gateway-rs is designed to run alongside a packet +forwarder and handles communications with the Helium Packet Router. + +```mermaid +graph LR; + subgraph Gateway["Helium-Enabled Gateway (Hotspot)"] + PacketForwarder["Packet
Forwarder"] + HeliumGateway["Helium
Gateway-rs"] + + PacketForwarder -- "Semtech GWMP
over UDP" --> HeliumGateway + end + + HeliumRouter["Helium
Packet Router"] + LNS["LoRaWAN
Network Server"] + + HeliumGateway -- "gRPC" --> HeliumRouter + HeliumRouter --> LNS +``` + +The articles in this section will outline the 'Gateway' highlighted portion of the above diagram. + +### Packet Forwarder + +Gateway-rs is designed to interact with the +[Semtech Packet Forwarder](https://github.com/helium/packet_forwarder). If no packet forwarder is +installed on the target hardware, follow the manufacturer's instructions using their documentation +or one of the tutorials below. + +- [Dragino LPS8/DLOS8](/iot/data-only/dragino-data-only-hotspot) +- [RAKwireless Concentrator (RAK2245/RAK2247/RAK2287) + Raspberry Pi](/iot/data-only/rak-concentrators) + - [Using Balena: RAKwireless RAK2287 Concentrator + Raspberry Pi](/iot/data-only/balena-data-only-hotspot) +- [RAKwireless WisGate Edge Lite 2](https://github.com/HoBoWAN/Helium-Data-Only-Hotspot/blob/main/README.md) +- [Seeed Studio SenseCAP M2](https://wiki.seeedstudio.com/Network/SenseCAP_Network/SenseCAP_M2_Data_Only-Helium_gateway/SenseCAP_M2_Data_Only_Quick_Start/) + +### Gateway-rs + +Gateway-rs is the lightweight client that handles message signing and communications with Helium +Packet Router, the backbone of the IoT Network. + +Gateway-rs is designed to be installed directly adjacent to the packet forwarder on the gateway. For +the latest releases and build notes, refer to the repository +[readme](https://github.com/helium/gateway-rs/blob/main/README.md) on GitHub. + +For guidance on using gateway-rs, view the +[Data-Only Hotspot Onboarding](/iot/data-only-hotspots-onboarding) section. + +## Transactions & Cost + +A data-only Hotspot is capable of transferring network traffic without being onboarded. However, +rewards for data transfer will not be issued. + +To enable the Helium Network to reward a data-only Hotspot for network traffic and to report a +location, two criteria must be met: + +1. The data-only Hotspot must be 'onboarded' to the network. + The **Add Hotspot** transaction links the Hotspot's key (`swarm_key`) to a user's + [account](/wallets) and makes the Hotspot known to the network. This allows the Hotspot to be + rewarded for data transfer. +1. The specific location of the Hotspot should be declared. + This allows the network define regional parameters and aids in location-solving for certain + sensor applications. The **Assert Location** transaction provides the physical location + (lat/long), elevation (in meters), and antenna EIRP (in dBi) data for the Hotspot. A Hotspot must + be onboarded before its location can be asserted. + +The network fees are as follows: + +- **Add Data-Only Hotspot**: 50,000 Data Credits (USD \$0.50) +- **Assert Location**: 50,000 Data Credits (USD \$0.50) + +These fees are paid using [Data Credits](/tokens/data-credit). + +Transactions are submitted using the [CLI Wallet](/wallets/cli-wallet). The CLI Wallet should +**not** be installed on the gateway, doing so could expose account keys to the open internet if the +gateway is not properly secured. Existing accounts generated using the Helium Wallet App can be +[imported to the CLI](/wallets/cli-wallet#import-seed-phrase-account-into-cli). + +For guidance on submitting these transactions, view the +[Data-Only Hotspot Onboarding](/iot/data-only-hotspots-onboarding) section. diff --git a/docs/network-iot/hotspots-iot/data-only-onboarding.mdx b/docs/network-iot/hotspots-iot/data-only-onboarding.mdx new file mode 100644 index 000000000..507d233c1 --- /dev/null +++ b/docs/network-iot/hotspots-iot/data-only-onboarding.mdx @@ -0,0 +1,330 @@ +--- +id: data-only-hotspots-onboarding +title: Data-Only Hotspot Onboarding +pagination_label: Data-Only Hotspot Onboarding +sidebar_label: Data-Only Hotspot Onboarding +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/data-only-hotspots-onboarding +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +# Data-Only Hotspot Onboarding + + +
+
+ +This guide walks through the process of onboarding a Data-Only Hotspot to the Helium Network. The +onboarding procedure expects a gateway configured with the Semtech Packet Forwarder and Helium +Gateway-rs. + +## Prerequisites + +- LoRaWAN Gateway with Gateway-rs installed. +- Helium Wallet CLI with a funded account imported. +- Token balances to onboard a Data-Only Hotspot. + - 100,000 ($1) Data Credits (DCs) comprised of + - 50,000 ($0.50) Data-Only Onboard + - 50,000 ($0.50) Data-Only Location Assert + - SOL (Solana's native cryptocurrency) to cover transaction fees (~0.01 Sol) + +## Installing Gateway-rs + +If the gateway is already configured with gateway-rs, skip to +[Prepare the Helium Wallet CLI](#prepare-the-helium-wallet-cli). + +If the gateway does not already have gateway-rs installed, follow these steps to install and +configure it. +For more in-depth guides, refer to the available tutorials. + +### Running From a Release + +Compiled releases are available directly from GitHub. + +- https://github.com/helium/gateway-rs/releases + +### Building From Source + +Build the program from source. The build chain for gateway-rs is +[Rust](https://www.rust-lang.org/tools/install). + +```sh title="Install Rust" +curl https://sh.rustup.rs -sSf | sh +``` + +```sh title="Add Rust to shell" +source "$HOME/.cargo/env" +``` + +```sh title="Install protobuf compiler" +sudo apt-get update && sudo apt-get install protobuf-compiler +``` + +```sh title="Clone the gateway-rs repository" +git clone https://github.com/helium/gateway-rs.git +``` + +```sh title="Build gateway-rs from within the gateway-rs directory" +cd gateway-rs/ +cargo build --release +``` + +The compiled `helium_gateway` program will be available in the `gateway-rs/target/release/` +directory. + +## Prepare Gateway-rs + +To simplify running the `helium_gateway` program, place it in a folder that is easily accessible or +in the `/usr/bin/` directory. Placing `helium_gateway` in this bin directory will automatically add +it to the shell path. + +```sh title="Copying the helium_gateway program to /usr/bin/" +sudo cp gateway-rs/target/release/helium_gateway /usr/bin/ +``` + +```sh title="Running the helium_gateway program after adding it to /usr/bin/" +$ helium_gateway --version +> helium_gateway 1.1.1 +``` + +### Configure `settings.toml` + +From the downloaded release or built source, copy the settings.toml file into a directory where it +will not be overwritten and can be easily found. + +The default path is `/etc/helium_gateway/settings.toml`. If using a different path, pass the +location of the settings.toml file to helium_gateway using the `-c` flag. + +```sh title="Initialize the default directory for Helium Gateway" +sudo mkdir /etc/helium_gateway +``` + +```sh title="Make a copy of settings.toml in the default directory" +sudo cp gateway-rs/config/settings.toml /etc/helium_gateway/ +``` + +For the subsequent steps, a command-line-based text editor is used. + +```sh title="Edit the copied settings.toml file" +sudo nano /etc/helium_gateway/settings.toml +``` + +#### [Optional] Region Plan + +Setting the gateway's region is only required if the Hotspot is not added and asserted to the +blockchain. For onboarded Hotspots, the region is retrieved via the asserted location stored +on-chain. The Hotspot will not transfer data unless one of these criteria is met. + +```toml title="Uncomment this line by removing the #. Set the appropriate region" +# region = "US915" +``` + +Determine the region plan that should be used. The selected region plan must match the region plan +in the Semtech Packet Forwarder. + +#### [Optional] Define `gateway_key.bin` Location + +The default path is `/etc/helium_gateway/gateway_key.bin`. If using a different path, update the key +location in `settings.toml`. + +The `gateway_key.bin` file stores the information used to identify the Hotspot on the network. The +key file will allow gateway-rs to securely sign all messages transferred from the Hotspot. Key +signing allows the Helium Network to confirm that data payloads are delivered from verifiable +sources. The gateway_key will be generated during the first run of the server if no existing key is +found. + +```toml +# File based: +keypair = "/etc/helium_gateway/gateway_key.bin" +``` + +It's advised to backup the `gateway_key.bin` file, especially if it needs to be recovered after the +onboarding process. + +### First Run + +With gateway-rs installed on the gateway, initialize the key for the Hotspot. If creating the +gateway_key in /etc/helium_gateway/, `sudo` may be required on first run to create the key file. + +```sh title="Generate a swarm_key by running gateway-rs." +sudo helium_gateway server +``` + +
+ +
Example successful result after first running Gateway-rs
+
+ +### Continued Operation + +Gateway-rs will not automatically run at system start. To make gateway-rs automatically run, create +a system service. + +```sh title="Create a service file for gateway-rs" +sudo nano /etc/systemd/system/gateway-rs.service +``` + +Define the system user to execute the service (Line 9). + +```service {9} showLineNumbers title="Create this service at /etc/systemd/system/gateway-rs.service" +# /etc/systemd/system/gateway-rs.service +[Unit] +Description=Helium Gateway + +[Service] +ExecStart=helium_gateway server +Restart=on-failure +RestartSec=15 +User= + +[Install] +WantedBy=multi-user.target +``` + +Once the service is written, activate it using the following commands. + +```sh title="Activate the service" +sudo systemctl enable gateway-rs.service +``` + +```sh title="Start the service" +sudo systemctl start gateway-rs.service +``` + +```sh title="View logs for gateway-rs" +sudo journalctl -fu gateway-rs +``` + +If there are errors in the service, edit it by first stopping the service +(`systemctl stop gateway-rs.service`), then editing it +(`sudo nano /etc/systemd/system/gateway-rs.service`). After changes are made, rerun the above +commands to test and monitor. + +## Prepare the Helium Wallet CLI + +The Helium Wallet CLI will be used to sign and submit the transaction generated. The Helium Wallet +CLI should not be installed on the Hotspot. + +For details on setting up the Helium Wallet CLI and using an existing account, see the +[CLI Wallet](/wallets/cli-wallet) documentation. + +```sh title="Get Helium address for the imported account" +./helium-wallet -f wallet.key info +``` + +The `info` command will return the wallet addresses for both the Solana blockchain and the legacy +Helium L1. + +```json +{ + "address": { + "helium": "", + "solana": "" + }, + "pwhash": "Argon2id13", + "sharded": false +} +``` + +## Generate the `add` Transaction Using Gateway-rs + +Connect to the Hotspot using SSH or the interface provided by the hardware manufacturer. + +Gateway-rs provides tooling to generate a transaction using the gateway_key. Use the Solana address +for the `` and `` fields. + +```sh title="Generate an Add Hotspot Transaction" +helium_gateway add --owner --payer +``` + +The owner and payer accounts can both be the same. To onboard the Hotspot, the payer account will +need to sign the transaction and pay the DC onboarding fee. The owner will be the recipient of the +Hotspot. + +The add command will generate the transaction that can be used in the onboarding step. + +```json {6} title="Add transaction result" +{ + "address": "", + "mode": "dataonly", + "owner": "", + "payer": "", + "txn": "" +} +``` + +## Onboarding With The Command Line Interface Wallet + +Onboarding is done using the [Helium CLI Wallet](/wallets/cli-wallet). + +The Helium CLI Wallet will not automatically convert HNT to Data Credits. Make sure the paying +account has at least 50,000 Data Credits available to complete the add transaction. The transactions +take place on the Solana blockchain, so a small amount of SOL is also required to cover Solana fees. + +```sh +helium-wallet hotspots add iot --commit +``` + +The CLI will return a Solana transaction hash for the on-chain event. This transaction can be looked +up using a Solana block explorer such as [Solana Explorer](https://explorer.solana.com/) or +[Solscan](https://solscan.io/). + +```json +{ + "result": "ok", + "txid": "" +} +``` + +## Asserting With The Command Line Interface Wallet + +To assert the location of the Hotspot using the Helium CLI Wallet, use the command +`helium-wallet hotspots update`. + +Make sure the paying account has at least 50,000 Data Credits available to complete the location +assert transaction. The transactions take place on the Solana blockchain, so a small amount of SOL +is also required to cover Solana fees. + +Before running the assert command, get the public key from the Data-Only Hotspot. + +```sh +helium_gateway key info +``` + +The `key info` command will return the Hotspot's 'animal name' along with the Hotspot's public key. + +```json +{ + "name": "angry-purple-tiger", + "key": "11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac", + "onboarding": "11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac" +} +``` + +Use the "key" value along with the Hotspot's physical latitude and longitude to assert its location +to the network. A utility such as [latlong.net](https://www.latlong.net) is helpful for looking up +coordinates. Gain is set in dBm and elevation is set in meters. + +``` +helium-wallet hotspots update iot --lat=37.771150 --lon=-122.419200 --gain 1.2 --elevation 7 --commit +``` + +`--elevation` and `--gain` are optional values and can be updated at any time without further fees +as long as the lat/lon values remain the same. Use the built-in help command, +`helium-wallet hotspots update --help` for more info. + +:::important Location Availability + +While Hotspot metadata like RSSI or pubkey are reported immediately, it may take up to 24 hours for +the location information to be processed and reflected in the LNS. + +::: diff --git a/docs/network-iot/hotspots-iot/data-only/balena-data-only-hotspot.mdx b/docs/network-iot/hotspots-iot/data-only/balena-data-only-hotspot.mdx new file mode 100644 index 000000000..2be7b9f13 --- /dev/null +++ b/docs/network-iot/hotspots-iot/data-only/balena-data-only-hotspot.mdx @@ -0,0 +1,143 @@ +--- +id: balena-data-only-hotspot +title: Data-Only Hotspot with balena + Raspberry Pi + RAK Concentrator RAK2287 +pagination_label: Balena Data-Only Tutorial +sidebar_label: Balena Data-Only Tutorial +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/data-only/balena-data-only-hotspot +--- + +# Data-Only Hotspot Setup with balena + Raspberry Pi + RAK2287 + +import useBaseUrl from '@docusaurus/useBaseUrl' + +A data-only Hotspot is a type of Hotspot that participates on the Helium Network by transferring +data from the end devices (LoRaWAN nodes). The data-only Hotspots are eligible for network data +transfer rewards but not Proof-of-Coverage rewards. + +This guide covers all the steps needed to set up a data-only Hotspot using a Raspberry Pi and a RAK +concentrator (RAK2287) and the Pi Hat running on balena. This configuration can be achieved by +installing the **_gatewayrs_** and **_packet forwarder_** services open sourced by +[Nebra](https://github.com/nebraltd) and using balenaOS and [balenaCloud](https://balena.io). + +## Getting started + +### Hardware + +- Raspberry Pi 0/2/3/4 or balenaFin +- SD card in case of the Raspberry Pi +- [RAK 2287 LoRa concentrator SPI based](https://store.rakwireless.com/products/rak2287-lpwan-gateway-concentrator-module) + and [RAK2287 Pi HAT](https://store.rakwireless.com/products/rak2287-pi-hat) + +:::important + +To use the concentrator module with a Raspberry Pi HAT, you must make sure to order the variation +with the SPI interface. + +::: + +### Software + +- [balena.io account](https://dashboard.balena-cloud.com/) +- [balenaEtcher](https://balena.io/etcher) + +## Deploy the code + +Running this data-only Hotspot with balena.io is as simple as deploying it to a balenaCloud +application. You can do it in just one click by using the button below: + +[![](https://www.balena.io/deploy.png)](https://dashboard.balena-cloud.com/deploy?repoUrl=https://github.com/mpous/helium-data-hotspot) + +Follow the instructions, click `Add a Device` and flash an SD card with that balenaOS image +downloaded from balenaCloud. Enjoy the magic 🌟Over-The-Air🌟! + +Find the [repository with the source code](https://github.com/mpous/helium-data-hotspot) if you +would like to clone and deploy from your computer or you would like to contribute. + +## Configure the device + +### Device Variables + +Once the device is online on balenaCloud and the services `packet-forwarder` and `gateway-rs` are +downloaded and installed, go to `Device Variables`. + +- Create the variable for all the services `VARIANT` with your hardware definition. During the test + is being used a Raspberry Pi 4 with RAK2287 LoRa concentrator and the `VARIANT` is defined + `DIY-RAK2287`. This `VARIANT` is compatible with any Raspberry Pi. You can find the list of + hardware compatible combinations on + [GitHub](https://github.com/NebraLtd/helium-hardware-definitions). + +- Create the variable for all the services `REGION_OVERRIDE` with your LoRa region (e.g. `EU868`). + You can find a list of LoRa regions compatible on [GitHub](https://github.com/NebraLtd/hm-pktfwd). + +### Test the Helium Data-Only Hotspot + +Once the Device Variables are properly set up, the Hotspot should be running showing some errors on +connecting to the network on the balenaCloud Logs. + +To check that the Hotspot has been generated correctly, go to the `Terminal` and select the +`gateway-rs` service, then introduce: + +`helium_gateway key info` + +And you will get something like this: + +`{ "address": , "name": }` + +At this point, your data-only Hotspot is ready to join the Helium IoT Network. + +### Join the Helium IoT Network with your Data-Only Hotspot + +To join the Helium IoT Network, at the moment only the Helium CLI Wallet can be used. The Helium +Wallet App is still not compatible with the data-only Hotspots. Follow +[these instructions](https://github.com/mpous/helium-data-hotspot/#join-the-helium-blockchain-with-your-data-only-hotspot) +to add your data-only Hotspot on the Helium IoT Network. + +## Check the Data-Only Hotspot + +Now that the data-only Hotspot has been added to the Helium IoT Network it should be visible in the +Helium Wallet. + +If you create a Helium Device, then go to the [Helium Console](https://console.helium.com) and +Inspect packages from your device to confirm that the data-only Hotspot is the one that relays the +data from your Devices. You also will be able to see on the balenaCloud logs that UPLINK messages +have been relayed to the Helium OUI. + +## Manage your gateway_key + +It's extremely important that at this point, with the Hotspot added on the Helium IoT Network you +backup the `gateway_key`. If you lose this key, you will not be able to use this hotspot anymore in +case there is a problem on your Hotspot (SD card corrupted, etc.). + +### Backup your gateway_key.bin file + +Follow these instructions to back up your `gateway_key.bin` file of your Hotspot. + +- Open an SSH session to the "host-os" on balenaCloud Terminal. +- Type this command and keep note of the (YOUR INSTANCE)\_miner-storage: + `ls /var/lib/docker/volumes`. +- Type this command to get a link to download the gateway key (note to replace the YOUR INSTANCE + part with the container number that you got from the previous command). + `curl -F "file=@/var/lib/docker/volumes/(YOUR INSTANCE)_miner-storage/_data#/gateway_key.bin" https://file.io` +- Use the outputted file.io link to securely download your swarm key. The link only works **one** + time. + +### Restore your gateway_key.bin file on your new file + +Follow these instructions to restore your `gateway_key.bin` key into your new hotspot. + +- Open an SSH session to the "host-os" on balenaCloud Terminal. +- Type this command and keep note of the (YOUR INSTANCE)\_miner-storage information: + `ls /var/lib/docker/volumes`. +- Navigate to where the swarm_key is stored + `cd /var/lib/docker/volumes/(YOUR INSTANCE)_miner-storage/_data#/`. +- Remove the original `gateway_key.bin` file `rm gateway_key.bin`. +- Reboot miner and you will see it restored and working. +- Upload your `gateway_key.bin` that you wish to restore onto file.io and do + `curl -LJO [FILE.IO UPLOAD LINK]`. + +## Contributions + +Thank you to Nebra for developing and balenifying the Helium Hotspot, Helium developers community, +Jose from RAK, Travis and Joseph from balena to work on the dbus + conman issues. diff --git a/docs/network-iot/hotspots-iot/data-only/dragino-data-only-hotspot.mdx b/docs/network-iot/hotspots-iot/data-only/dragino-data-only-hotspot.mdx new file mode 100644 index 000000000..ecdd68c3f --- /dev/null +++ b/docs/network-iot/hotspots-iot/data-only/dragino-data-only-hotspot.mdx @@ -0,0 +1,133 @@ +--- +id: dragino-data-only-hotspot +title: Dragino LPS80/DLOS8 Data-Only Tutorial +pagination_label: Dragino Data-Only Tutorial +sidebar_label: Dragino Data-Only Tutorial +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/data-only/dragino-data-only-hotspot +--- + +# Dragino LoRaWAN Gateway Setup + +import useBaseUrl from '@docusaurus/useBaseUrl' +import { YouTube } from 'mdx-embed' + +This guide provides instructions on how to configure an 8-channel Dragino LoRaWAN gateway such as +the LPS8 or DLOS8 to work with the Helium IoT Network. + +## Prerequisites + +Before configuring your Dragino to work with the Helium IoT Network, please confirm that it is +connected to the Internet and updated to the latest firmware. Refer to the user guide provided on +the [Dragino download site](http://www.dragino.com/downloads/index.php?dir=LoRa_Gateway/) for more +detailed instructions. + +## Configure LoRaWAN Frequency Plan + +To be able to send and receive LoRaWAN data, your Gateway must be configured to the frequency plan +specified for your region. You may be able to use the predefined frequency in the Dragino software +or in some cases may need to manually set them per the frequencies used by the Helium IoT Network in +your region. + +1. Log into the Dragino gateway web interface. In the standard Dragino firmware connect via your + browser at `http://:8000` once the Dragino is connected to your network. +2. Navigate to Lora > Lora from the Menu. +3. Under Radio Settings, select your region in the Frequency Plan drop-down and, if applicable, the + Frequency Sub Band. For example, in the US, select US915 for the frequency plan and 2 for the + sub-band. +4. If desired, set Static GPS coordinates. +5. Click Save & Apply. + +For some regions, it may be necessary to manually populate the Customized Channel Settings based on +the Helium frequencies for your region. Refer to the +[Helium sample LoRa packet forwarder global.conf files](https://github.com/helium/sx1302_hal/tree/helium/hotspot/packet_forwarder) +for your region as a guide to the values to use. You can check the values used by the pre-defined +frequency plans by viewing the global_conf.json file: `cat /etc/lora/global_conf.json`. + +_Example of customized channel settings using the US915 frequency plan for the Helium IoT Network_ + + + +## Configure LoRaWAN Settings + +Next, you will configure the LoRa packet forwarder on the Dragino to forward packets to the Helium +Gateway service which will be installed on the Dragino in the next step. + +1. From the Dragino web interface, navigate to LoRaWAN > LoRaWAN from the menu. +2. Select `Custom / Private LoRaWAN` from the Service Provider. +3. Set the Server Address to `127.0.0.1` and both Uplink and Downlink ports to `1680`. This will + configure the forwarder to use the default port used by Helium Gateway. + + + +4. Click Save & Apply. + +## Install Helium Gateway (gateway-rs) on the Dragino + +Finally, you will install the Helium Gateway service. This requires SSH access to the Dragino. + +1. Connect to the Dragino over SSH. By default, the standard Dragino firmware uses port 2222 for SSH + (the OpenVPN firmware uses port 22) and the root user has access. + `ssh root@ -p 2222`. +2. Copy the Helium Gateway package to the Dragino. The latest + [source code](https://github.com/helium/gateway-rs) and pre-built + [releases](https://github.com/helium/gateway-rs/releases) are available on GitHub. Option 1: + Download from GitHub: On the Dragino run `cd /tmp` and + `wget -O helium-gateway--dragino.ipk https://github.com/helium/gateway-rs/releases/download//helium-gateway--dragino.ipk`. + Option 2: Copy from another computer: Run this command from on the computer within the directory + containing the package `scp helium-gateway--dragino.ipk :/tmp/`. +3. Install the Helium Gateway package `opkg install /tmp/helium-gateway--dragino.ipk`. +4. Backup your key file `/etc/helium_gateway/gateway_key.bin` and keep in a safe place. This will be + needed to recover this Gateway especially if it is onboarded to the Helium IoT Network. + +Helium Gateway is now installed and should be running. Use the command `helium_gateway key info` to +view the public key address and animal name of your Gateway. + +## Verify + +Your Dragino gateway should now be set up and forwarding LoRaWAN data traffic to the Helium IoT +Network. + +Use the Dragino system log to verify that Helium Gateway has started. You can view the log in the +web interface or by using logread on the command line interface (e.g, +`logread | grep helium_gateway`). In the logs, you should see messages indicating helium_gateway is +starting. If you do not see these, try restarting the service (`/etc/init.d/helium_gateway restart`) +or reboot the Dragino as the messages may have rotated out of the log. + +_Example logs showing the Helium Gateway service starting_ + +``` +Thu Mar 25 19:43:06 2021 daemon.err helium_gateway[2031]: Mar 25 19:43:06.184 INFO starting server, key: , version: 1.0.0-alpha.4 +Thu Mar 25 19:43:06 2021 daemon.err helium_gateway[2031]: Mar 25 19:43:06.289 INFO starting, module: gateway +Thu Mar 25 19:43:06 2021 daemon.err helium_gateway[2031]: Mar 25 19:43:06.306 INFO starting, module: router +``` + +Additionally, the LoRa Packet Forwarder log can provide some clues as to whether the LoRaWAN server +configuration is correct. Search the system log for PULL_DATA messages and confirm that they are +acknowledged such as `REPORT~ # PULL_DATA sent: 1 (100.00% acknowledged)`. This indicates that the +packet forwarder is communicating with the Helium Gateway service running on the Dragino and is +getting replies from the service as expected. Note, this is not a foolproof way to confirm it is +configured correctly. By default, the LoRaWAN Server settings are configured for the TTN EU server +which will also provide acknowledgment. However, the absence of acknowledgment could indicate that +the LoRaWAN settings are not correct per the above. + +## Onboard as Data-Only Hotspot + +As part of the Hotspot project, a new class of Hotspots called "Data-Only Hotspots" can be added to +the Helium IoT Network, meaning Dragino LPS80/DLOS8 Hotspots can be added to the network. These +data-only Hotspots reward IOT tokens for transferring data but never for Proof-of-Coverage. This +onboarding process will require using the [Helium CLI Wallet](/wallets/cli-wallet/) to submit the +onboarding and assert location transactions. See +[Prepare the Helium Wallet CLI and further information](/iot/data-only-hotspots-onboarding#prepare-the-helium-wallet-cli) +for specific details on Hotspot onboarding. + +### Video Guide for Setup + + diff --git a/docs/network-iot/hotspots-iot/data-only/kerlink-data-only-hotspot.mdx b/docs/network-iot/hotspots-iot/data-only/kerlink-data-only-hotspot.mdx new file mode 100644 index 000000000..ea9e20028 --- /dev/null +++ b/docs/network-iot/hotspots-iot/data-only/kerlink-data-only-hotspot.mdx @@ -0,0 +1,20 @@ +--- +id: kerlink-data-only-hotspot +title: Kerlink Data-Only Hotspot Tutorial +pagination_label: Kerlink Data-Only Hotspot Tutorial +sidebar_label: Kerlink Data-Only Hotspot Tutorial +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/data-only/kerlink-data-only-hotspot +--- + +Kerlink gateways support running as Data-Only Hotspots on the Helium Network. + +Two guides are available depending on the Kerlink OS version: + +- For KerOS 5: https://github.com/BenoitDuffez/kerlink-data-only-gateway +- For KerOS 6: https://gitlab.com/dtuando1/keros-6-helium + +Once the Helium client is running on the Kerlink gateway, follow the steps in the +[Data-Only Hotspot Setup](/iot/data-only-hotspots-onboarding#prepare-the-helium-wallet-cli) guide to +complete the onboarding of the Hotspot. diff --git a/docs/network-iot/hotspots-iot/data-only/rak-concentrators.mdx b/docs/network-iot/hotspots-iot/data-only/rak-concentrators.mdx new file mode 100644 index 000000000..9b18e1969 --- /dev/null +++ b/docs/network-iot/hotspots-iot/data-only/rak-concentrators.mdx @@ -0,0 +1,365 @@ +--- +id: rak-concentrators +title: RAK Concentrator + Raspberry Pi Data-Only Tutorial +pagination_label: RAK Concentrator Data-Only Tutorial +sidebar_label: RAK Concentrator Data-Only Tutorial +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/data-only/rak-concentrators +--- + +# Data-Only Hotspot Setup with RAKwireless Concentrator + Raspberry Pi + +import useBaseUrl from '@docusaurus/useBaseUrl' +import { YouTube } from 'mdx-embed' + +This guide covers the steps needed to set up a Data-Only Hotspot using a WisLink RAK LPWAN +concentrator module and a Raspberry Pi. + +## Requirements + +- **Raspberry Pi:** Multiple families are supported, however, not all the models have been tested. + It's recommended to follow this guide with a Pi 3 or Pi 4. + +- **LoRaWAN Concentrator:** The concentrator module and Pi HAT to interface it with the Raspberry + Pi. The following table contains the links to concentrators and their HATs. + +| WisLink LPWAN Concentrator | Raspberry Pi HAT | +| --------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------: | +| [RAK2287](https://store.rakwireless.com/products/wislink-concentrator-module-sx1302-rak2287-lorawan?variant=41826859385030) | [RAK2287 Pi HAT](https://store.rakwireless.com/products/rak2287-pi-hat) | +| [RAK2247](https://store.rakwireless.com/products/rak2247-lpwan-gateway-concentrator-module?variant=39942873743558) | [RAK2247 Pi HAT](https://store.rakwireless.com/products/rak2247-pi-hat) | +| [RAK2245](https://store.rakwireless.com/products/rak2245-stamp-edition?variant=39942878494918) | Pi-compatible | + +:::important + +To use the concentrator module with a Raspberry Pi HAT, you must make sure to order the variation +with the SPI interface. + +::: + +## Packet Forwarder Preparation + +To prepare the hardware to become a Helium Data-Only Hotspot, it first must be configured to handle +LoRaWAN messages. To get started, install an operating system and set up the packet forwarder as +outlined in one of the two options below. + +LoRaWAN gateways are generally 'headless' computers. The +[Raspberry Pi Headless](https://www.raspberrypi.com/documentation/computers/configuration.html#setting-up-a-headless-raspberry-pi) +documentation is a helpful reference for initial setup. + +#### Option 1 + +Follow this +[installation procedure](https://github.com/RAKWireless/rak_common_for_gateway#installation-procedure) +if you are already familiar with the Raspberry Pi and the RAK concentrator modules. + +#### Option 2 + +Follow the Quick Start Guide for your concentrator on the +[RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisLink/#wislink-lpwan). +If using Wi-Fi for initial setup, it is recommended to initially configure the Raspberry Pi using +[Raspberry Pi Imager](https://www.youtube.com/watch?v=ntaXWS8Lk34). + +- [RAK2287 Quickstart](https://docs.rakwireless.com/Product-Categories/WisLink/RAK2287/Quickstart/) +- [RAK2247 Quickstart](https://docs.rakwireless.com/Product-Categories/WisLink/RAK2247/Quickstart/) +- [RAK2245 Quickstart](https://docs.rakwireless.com/Product-Categories/WisLink/RAK2245-Pi-HAT/Quickstart/) + +### Select the Region Plan + +Enter the gateway configuration interface by using the following command: + +``` +sudo gateway-config +``` + +Select the _Setup RAK Gateway Channel Plan_ option, then _Server is TTN_, and in the last step +choose the proper plan according to your country. To finish, press OK. + +
+ +
This image shows the option to select US915.
+
+
+ +### Verify If The Packet Forwarder Is Running + +When the LoRa packet forwarder is running as a service, some log messages are recorded in the +syslog. To inspect the logs, run the following command: + +``` +sudo tail -f /var/log/syslog | grep ttn-gateway +``` + +The log output should show something similar to: + +``` +rak-gateway ttn-gateway[1886]: JSON up: {"stat":{"time":"2021-07-21 16:25:00 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"temp":0.0}} +rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms +rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms +rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms +rak-gateway ttn-gateway[1886]: ##### 2021-07-21 16:25:30 GMT ##### +rak-gateway ttn-gateway[1886]: ### [UPSTREAM] ### +rak-gateway ttn-gateway[1886]: # RF packets received by concentrator: 0 +rak-gateway ttn-gateway[1886]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% +rak-gateway ttn-gateway[1886]: # RF packets forwarded: 0 (0 bytes) +rak-gateway ttn-gateway[1886]: # PUSH_DATA datagrams sent: 1 (122 bytes) +rak-gateway ttn-gateway[1886]: # PUSH_DATA acknowledged: 0.00% +rak-gateway ttn-gateway[1886]: ### [DOWNSTREAM] ### +rak-gateway ttn-gateway[1886]: # PULL_DATA sent: 3 (100.00% acknowledged) +rak-gateway ttn-gateway[1886]: # PULL_RESP(onse) datagrams received: 0 (0 bytes) +rak-gateway ttn-gateway[1886]: # RF packets sent to concentrator: 0 (0 bytes) +rak-gateway ttn-gateway[1886]: # TX errors: 0 +rak-gateway ttn-gateway[1886]: ### SX1302 Status ### +rak-gateway ttn-gateway[1886]: # SX1302 counter (INST): 210904434 +rak-gateway ttn-gateway[1886]: # SX1302 counter (PPS): 0 +rak-gateway ttn-gateway[1886]: # BEACON queued: 0 +rak-gateway ttn-gateway[1886]: # BEACON sent so far: 0 +rak-gateway ttn-gateway[1886]: # BEACON rejected: 0 +``` + +:::note + +`ttn-gateway` is just the name for the LoRa packet forwarder service in the configuration for these +RAK concentrators; this is a "legacy name" that doesn't change when using different network servers. + +::: + +### Edit the Packet Forwarder Settings + +You will need to edit some basic options in the packet forwarder configuration to forward the +packets to the address and port the helium_gateway service is listening to. + +Select the option _Edit packet-forwarder config_ within the _gateway-config_ interface. This option +will open the `global_conf.json` file using the nano editor. Then, set the `server_address` to +127.0.0.1 and the `serv_port_up` and `serv_port_down` to 1680, as follows: + +
+ +
+
+ +Close the editor by pressing CTRL + X simultaneously, press ENTER to save the file. + +Restart the packet forwarder to apply the changes by selecting the option _Restart packet-forwarder_ +within the _gateway-config_ interface. + +:::important + +Every time a new region is selected using the _Setup RAK Gateway Channel Plan_ option, these +settings are replaced with the default configuration. Make sure to keep this in mind if the region +is changed later. + +::: + +## Helium Gateway Service Installation + +### Downloading the Package + +Download the latest release from the [gateway-rs](https://github.com/helium/gateway-rs) repository +on GitHub, and set the `` according to +[the latest release](https://github.com/helium/gateway-rs/releases). You can download it in any +directory, for example `/tmp`. + +#### Option 1 + +Get from the repo directly to the Raspberry Pi by running the following commands: + +```sh +cd /tmp +wget https://github.com/helium/gateway-rs/releases/download//helium-gateway--armv7-unknown-linux-musleabihf.tar.gz +``` + +Expand the archive: + +```sh +tar -xf helium-gateway--armv7-unknown-linux-musleabihf.tar.gz +``` + +#### Option 2 + +You can also download it to your computer and pass it to the Raspberry Pi through the Secure Copy +Protocol (SCP): + +```sh +scp helium-gateway--armv7-unknown-linux-musleabihf.tar.gz pi@:/tmp/ +``` + +Through an SSH connection, expand the archive: + +```sh +tar -xf helium-gateway--armv7-unknown-linux-musleabihf.tar.gz +``` + +#### Option 3 + +Build the program from source. The build chain for gateway-rs is +[Rust](https://www.rust-lang.org/tools/install). While build times may be slower, gateway-rs can be +built directly on the Raspberry Pi. + +```sh title="Install Rust" +curl https://sh.rustup.rs -sSf | sh +``` + +```sh title="Add Rust to shell" +source "$HOME/.cargo/env" +``` + +```sh title="Install protobuf compiler" +sudo apt-get update && sudo apt-get install protobuf-compiler +``` + +```sh title="Clone the gateway-rs repo" +git clone https://github.com/helium/gateway-rs.git +``` + +[Increase Raspberry Pi Swap Space](https://pimylifeup.com/raspberry-pi-swap-file/) A clean Raspberry +Pi OS install may not have enough available RAM or swap space to build gateway-rs. Increase the swap +space of the Pi for a smooth build. + +```sh title="Build gateway-rs" +cd gateway-rs/ +cargo build --release +``` + +### Gateway Configuration + +After obtaining or building gateway-rs, move the `helium_gateway` executable file and +`settings.toml` file to places where they are easily accessible. + +#### Gateway Settings + +The `settings.toml` file handles the location of the keyfile used to sign messages as well as the +default region configuration for the Helium IoT Network. It is recommended to make a copy of the +settings.toml file that otherwise exists within the `gateway-rs/config/` folder. + +For simplicity in this guide, place the `settings.toml`file at the home path. + +```sh title="Make a copy of settings.toml" +cp gateway-rs/config/settings.toml ~/settings.toml +``` + +Similarly, edit `settings.toml` to match the intended path for `gateway_key.bin`. The +`gateway_key.bin` file is created at the defined directory on the first run of the gateway-rs +server. + +```toml title="Update the keypair path in settings.toml" +... +# File based: +keypair = "gateway_key.bin" +... +``` + +#### Create a Service + +Create a service to handle automatically starting gateway-rs. + +Update the paths in `ExecStart` for both the location of the `helium_gateway` binary and the +`settings.toml` file (Line 6). +Additionally, define the system user to execute the service (Line 9). + +```service {6,9} showLineNumbers title="Create this service at /etc/systemd/system/gateway-rs.service" +# /etc/systemd/system/gateway-rs.service +[Unit] +Description=Helium Gateway + +[Service] +ExecStart=helium_gateway -c settings.toml server +Restart=on-failure +RestartSec=15 +User= + +[Install] +WantedBy=multi-user.target +``` + +Once the service is written and proper paths are set, activate it using the following commands: + +```sh title="Activate the service" +sudo systemctl enable gateway-rs.service +``` + +```sh title="Start the service" +sudo systemctl start gateway-rs.service +``` + +```sh title="View logs for gateway-rs" +sudo journalctl -fu gateway-rs +``` + +If there are errors in running the service edit it by first stopping the service +(`systemctl stop gateway-rs.service`), then editing it +(`sudo nano /etc/systemd/system/gateway-rs.service`). After changes are made, rerun the above +commands to test and monitor. + +### Region Configuration + +The region configuration for gateway-rs is a default. The on-chain asserted location of the Gateway +will override the definition in `settings.toml`. Updating the region in settings is optional as long +as the Data-Only Hotspot location is asserted.. + +## Verifying the Installation + +### Inspecting the Service Logs + +The service starts after installation automatically. You can check the execution logs by running the +following command: + +``` +sudo tail -f /var/log/syslog | grep helium_gateway +``` + +### Getting some Information about the Data-Only Hotspot + +Use the following command to get the public key address and animal name of your Data-Only Hotspot: + +``` +./helium_gateway -c ~/settings.toml key info +``` + +This command should give you an output like the following one: + +```json +{ + "address": , + "onboarding": , + "name": +} +``` + +#### Backup the gateway_key + +The `gateway_key.bin` file stores the information used to identify the Data-Only Hotspot on the +Helium IoT Network. It's highly advised to backup this file, especially if you need to recover it +later after the onboarding process. + +Using SCP could be an option to do the backup; that would be something like this: + +``` +scp pi@:/etc/helium_gateway/gateway_key.bin +``` + +If using Windows, a tool like [WinSCP](https://winscp.net/eng/index.php) will enable this +functionality. + +## Onboard the Data-Only Hotspot + +Refer to the [Data-Only Hotspot Onboarding](/iot/data-only-hotspots-onboarding) section to complete +the onboarding of the fully-configured Data-Only Hotspot. + +## Video Guide for Setup + +This Hands-on with RAKStars session follows the steps provided in this guide. + + diff --git a/docs/network-iot/learn/EduDevice.tsx b/docs/network-iot/learn/EduDevice.tsx new file mode 100644 index 000000000..d4321af85 --- /dev/null +++ b/docs/network-iot/learn/EduDevice.tsx @@ -0,0 +1,423 @@ +import { ApplicationServiceClient } from '@chirpstack/chirpstack-api-grpc-web/api/application_grpc_web_pb' +import { ListApplicationsRequest } from '@chirpstack/chirpstack-api-grpc-web/api/application_pb' +import { DeviceServiceClient } from '@chirpstack/chirpstack-api-grpc-web/api/device_grpc_web_pb' +import { + CreateDeviceKeysRequest, + CreateDeviceRequest, + Device, + DeviceKeys, +} from '@chirpstack/chirpstack-api-grpc-web/api/device_pb' +import { DeviceProfileServiceClient } from '@chirpstack/chirpstack-api-grpc-web/api/device_profile_grpc_web_pb' +import { ListDeviceProfilesRequest } from '@chirpstack/chirpstack-api-grpc-web/api/device_profile_pb' +import { InternalServiceClient } from '@chirpstack/chirpstack-api-grpc-web/api/internal_grpc_web_pb' +import { + LogItem, + LoginRequest, + StreamDeviceEventsRequest, +} from '@chirpstack/chirpstack-api-grpc-web/api/internal_pb' +import { Region } from '@chirpstack/chirpstack-api-grpc-web/common/common_pb' +import useDocusaurusContext from '@docusaurus/useDocusaurusContext' +import { EventEmitter } from 'events' +import google_protobuf_empty_pb from 'google-protobuf/google/protobuf/empty_pb' +import * as grpcWeb from 'grpc-web' +import React, { useCallback, useEffect, useState } from 'react' +import { Alert, AlertIcon } from '../../../src/theme/components/Alert' +import styles from './build-a-device.module.css' + +const deviceEmitter = new EventEmitter() + +const generateRandomKey = () => { + let cryptoObj = window.crypto || window.Crypto + let b = new Uint8Array(8) + cryptoObj.getRandomValues(b) + let hexString = '' + b.forEach((num, index) => { + let hexVal = num.toString(16) + if (hexVal.length === 1) hexVal = '0' + hexVal + hexString += hexVal + }) + + return hexString +} + +const getHexArray = (key: string = '') => { + return key + .match(/[A-Fa-f0-9]{2}/g)! + .join(', ') + .toUpperCase() + .replace(/[A-Fa-f0-9]{2}/g, '0x$&') +} + +const DeviceInfoRow = ({ label, value }) => { + if (!value) + return ( +

+ + +

+ ) + return ( +

+ + e.target.select()} /> +

+ ) +} + +const useLogin = () => { + const { + siteConfig: { customFields }, + } = useDocusaurusContext() + const interalServiceClient = new InternalServiceClient(customFields.EDU_API_URL) + + return () => + new Promise((resolve, reject) => { + let req = new LoginRequest() + req.setEmail(customFields.EDU_EMAIL) + req.setPassword(customFields.EDU_PW) + interalServiceClient.login(req, {}, (error, resp) => { + if (error !== null) { + return reject(error) + } + return resolve(resp.getJwt()) + }) + }) +} + +const getRequestMeta = (jwt: string) => { + return { authorization: `Bearer ${jwt}` } +} + +const EnvChecker = ({ children }) => { + const { + siteConfig: { customFields }, + } = useDocusaurusContext() + if (!customFields.EDU_API_URL || !customFields.EDU_EMAIL || !customFields.EDU_PW) { + return ( + + +

Please configure your .env file to use the Educational LNS features

+ + ) + } + + return children +} + +const CreateDeviceComponent = () => { + const { + siteConfig: { customFields }, + } = useDocusaurusContext() + console.log('url', customFields.EDU_API_URL) + const login = useLogin() + const [deviceInfo, setDeviceInfo] = useState({ devEui: '', joinEui: '', networkKey: '' }) + const [isLoading, setIsLoading] = useState(false) + + const createDevice = () => { + setIsLoading(true) + let jwt = '' + let tenants = [] + let applicationId = '' + let deviceProfileId = '' + const interalServiceClient = new InternalServiceClient(customFields.EDU_API_URL) + + const getTenantId = () => { + return tenants[0].getTenantId() + } + const loginWrapper = () => + login().then((loginJwt) => { + jwt = loginJwt as string + }) + + const getTenants = () => { + return new Promise((resolve, reject) => { + interalServiceClient.profile( + new google_protobuf_empty_pb.Empty(), + getRequestMeta(jwt), + (error, resp) => { + if (error !== null) { + reject(error) + } + tenants = resp.getTenantsList() + resolve(tenants) + }, + ) + }) + } + + const getDeviceApplications = () => + new Promise((resolve, reject) => { + const client = new ApplicationServiceClient(customFields.EDU_API_URL) + let req = new ListApplicationsRequest() + req.setTenantId(getTenantId()) + req.setLimit(10) + req.setOffset(0) + + client.list(req, getRequestMeta(jwt), (error, resp) => { + if (error !== null) { + return reject(error) + } + const deviceApplications = resp.toObject() + const targetApplication = deviceApplications.resultList.find( + (application) => application.name === 'Docs', + ) + if (!targetApplication) return reject('Target application not found') + applicationId = targetApplication.id + return resolve(applicationId) + }) + }) + + const getDeviceProfilesPage = () => + new Promise((resolve, reject) => { + const client = new DeviceProfileServiceClient(customFields.EDU_API_URL) + + let req = new ListDeviceProfilesRequest() + req.setTenantId(getTenantId()) + req.setLimit(10) + req.setOffset(0) + + client.list(req, getRequestMeta(jwt), (error, resp) => { + if (error !== null) { + return reject(error) + } + + const deviceProfiles = resp.toObject() + const targetProfile = deviceProfiles.resultList.find( + (deviceProfile) => deviceProfile.region === Region.US915, + ) + if (!targetProfile) return reject('Target profile not found') + + deviceProfileId = targetProfile.id + return resolve(deviceProfileId) + }) + }) + + const createDevice = () => + new Promise((resolve, reject) => { + const client = new DeviceServiceClient(customFields.EDU_API_URL) + let device = new Device() + + const devEui = generateRandomKey() + const joinEui = generateRandomKey() + + device.setApplicationId(applicationId) + device.setName(devEui) + device.setDescription('Randomly generated device') + device.setDevEui(devEui) + device.setDeviceProfileId(deviceProfileId) + device.setIsDisabled(false) + device.setSkipFcntCheck(false) + device.setJoinEui(joinEui) + + let req = new CreateDeviceRequest() + req.setDevice(device) + + client.create(req, getRequestMeta(jwt), (error) => { + if (error !== null) { + setIsLoading(false) + return reject(error) + } + + let req = new CreateDeviceKeysRequest() + let deviceKeys = new DeviceKeys() + const networkKey = generateRandomKey() + generateRandomKey() + deviceKeys.setDevEui(devEui) + deviceKeys.setNwkKey(networkKey) + req.setDeviceKeys(deviceKeys) + + client.createKeys(req, getRequestMeta(jwt), (error) => { + setIsLoading(false) + if (error !== null) { + return reject(error) + } + + setDeviceInfo({ + devEui, + joinEui, + networkKey, + }) + deviceEmitter.emit('deviceInfo', { devEui: devEui, jwt }) + + return resolve(device) + }) + }) + }) + + return loginWrapper() + .then(getTenants) + .then(() => Promise.all([getDeviceApplications(), getDeviceProfilesPage()])) + .then(createDevice) + } + + return ( + <> +
+ + + +
+ + + ) +} + +export const CreateDevice = () => ( + + + +) + +function DeviceEventLoggerComponent() { + const { + siteConfig: { customFields }, + } = useDocusaurusContext() + const login = useLogin() + const [jwt, setJwt] = useState('') + const [devEui, setDevEui] = useState('') + const [events, setEvents] = useState([]) + + useEffect(() => { + const setStreamInfo = ({ devEui, jwt }) => { + setJwt(jwt) + setDevEui(devEui) + } + deviceEmitter.on('deviceInfo', setStreamInfo) + return () => deviceEmitter.removeListener('deviceInfo', setStreamInfo) + }, []) + + const onMessage = useCallback((logItem: LogItem) => { + setEvents((e) => { + if ( + e.length === 0 || + parseInt(logItem.getId().replace('-', '')) > parseInt(e[0].id.replace('-', '')) + ) { + return [logItem.toObject(), ...e] + } + return e + }) + }, []) + + // get jwt when manual devEui entry + useEffect(() => { + if (devEui.length === 16 && !jwt) { + login().then(setJwt) + } + }, [jwt, devEui]) + + useEffect(() => { + if (devEui.length === 16 && !!jwt) { + const streamDeviceEvents = (callbackFunc: (resp: LogItem) => void): (() => void) => { + let req = new StreamDeviceEventsRequest() + req.setDevEui(devEui) + var stream: grpcWeb.ClientReadableStream | undefined = undefined + let retryCount = 0 + + let setup = () => { + const client = new InternalServiceClient(customFields.EDU_API_URL) + stream = client.streamDeviceEvents(req, getRequestMeta(jwt)) + + stream = stream.on('data', (resp) => { + callbackFunc(resp) + retryCount = 0 // reset retry count on successful data reception + }) + + stream = stream.on('end', function () { + retryCount++ + setTimeout(setup, Math.min(1000 * 2 ** retryCount, 30000)) // exponential backoff with max delay + }) + + stream = stream.on('error', function () { + retryCount++ + setTimeout(setup, Math.min(1000 * 2 ** retryCount, 30000)) // exponential backoff with max delay + }) + } + + setup() + + return () => { + if (stream) { + stream.cancel() + } + } + } + + let cancelFunc = streamDeviceEvents(onMessage) + + return () => { + cancelFunc() + } + } + }, [jwt, devEui, onMessage]) + + return ( + <> + {/*

Device Event Logger

*/} + {/*

jwt: {jwt}

*/} + + {!events.length && ( +
+ setDevEui(event.target.value)} + /> +

No events yet.

+
+ )} + +
+ {events + .filter((event) => event.description !== 'log') + .map((event) => ( +
+
+

+ {event.description === 'join' + ? '🔄 Joining' + : event.description === 'up' + ? '⬆️ Uplink' + : event.description === 'down' + ? '⬇️ Downlink' + : event.description === 'status' + ? '*️⃣ Status' + : `🛜 ${event.description}`} +

+

+ {new Date(event.time?.seconds! * 1000).toLocaleString()} +

+
+
    + {event.propertiesMap.map(([key, value], index) => ( +
  • + + {key === 'DR' + ? 'Data Rate' + : key === 'FCnt' + ? 'Frame Count' + : key === 'FPort' + ? 'Frame Port' + : key} + :{' '} + + {value} +
    • + ))} +
+
+ ))} +
+ + ) +} + +export const DeviceEventLogger = () => ( + + + +) diff --git a/docs/network-iot/learn/build-a-device.mdx b/docs/network-iot/learn/build-a-device.mdx new file mode 100644 index 000000000..e5ee56f3d --- /dev/null +++ b/docs/network-iot/learn/build-a-device.mdx @@ -0,0 +1,91 @@ +--- +id: build-a-device +title: Build A LoRaWAN Device +pagination_label: Build A LoRaWAN Device +sidebar_label: Build A LoRaWAN Device +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-iot/learn/build-a-device +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' +import { DocslabCodeBlock } from 'docslab-docusaurus/lib/theme/DocslabCodeBlock' +import { CreateDevice, DeviceEventLogger } from './EduDevice.tsx' + +Many commercially-produced LoRaWAN devices come pre-provisioned and ready to use out of the box. +However, understanding how devices are onboarded, programmed, and connected unlocks the full +potential of building custom IoT solutions on the Helium Network. + +This guide walks through the process of creating a custom device from scratch using a real-world +development device remotely configured through the widgets on this page. + +## Provisioning a Device + +Every LoRaWAN device requires a unique set of cryptographic keys for authentication and encryption. +Pre-built devices typically come with these keys already configured, but for custom devices, you +must generate and provision them yourself. + +Click the button below to generate a new set of device keys: + +
+ +
+
+ +Behind the scenes, these keys are registered with a LoRaWAN Network Server (LNS). The Join EUI is +shared with the Helium Packet Router (HPR), which allows any Hotspot in the world to route messages +from this device to the correct LNS. The cryptographic keys ensure end-to-end encryption between the +device and the LNS. + +## Programming the Device + +The example below uses a [Heltec CubeCell](https://heltec.org/project/htcc-ab01/) development board +with PlatformIO. Copy the keys generated above into the `devEui`, `appEui`, and `appKey` variables: + +
+ +
+
+ +Once compiled and uploaded, the device will attempt to join the network and begin transmitting data. + +## Viewing Device Events + +When your device transmits, a Hotspot on the Helium Network receives the radio signal and forwards +it through the Packet Router to the LNS. The LNS then delivers the data here, to this page, in +real-time. + +
+ +
+
+ +If uplinks appear in the logger, you're seeing the complete data path in action. Your device +transmits, the Helium network routes, and your application receives. This same flow can deliver data +to any backend you build: a database, a dashboard, an alerting system, or an API. + +## Next Steps + +Once data reaches the LNS, it can be forwarded to your application using integrations such as HTTP +webhooks, MQTT, or cloud platforms like AWS IoT and Azure IoT Hub. See +[LoRaWAN Network Servers](/iot/lorawan-network-servers) for more information on available LNS +options. + +## Experiments + +Try modifying the device behavior to deepen your understanding: + +1. **Change the payload**: The device sends data in hexadecimal format. How would you transmit + "Hello, World!"? Tools like [asciitohex.com](https://www.asciitohex.com/) can help with + conversions. +2. **Use different ports**: LoRaWAN's `FPort` field allows you to separate data types. Send sensor + readings on one port and status updates (like battery level) on another. +3. **Adjust the transmission interval**: The device currently sends data every 30 seconds. Try + changing it to 10 seconds. Consider how this affects battery life and network usage. diff --git a/docs/network-iot/learn/build-a-device.module.css b/docs/network-iot/learn/build-a-device.module.css new file mode 100644 index 000000000..f1d1ed3ac --- /dev/null +++ b/docs/network-iot/learn/build-a-device.module.css @@ -0,0 +1,119 @@ +/*CreateDevice*/ +.DeviceKeys { + width: 100%; + padding: 0.5em; +} + +.keybox { + display: flex; + flex-direction: column; +} + +.keybox label { + font-weight: 500; + color: #53627c; + font-size: small; + background-color: #eaeff9; + line-height: 1em; + padding: 1em 1rem calc(1em + 6px); + border-radius: 8px 8px 0 0; +} + +.keybox input { + display: table; + background: white; + width: 100%; + table-layout: fixed; + border: none; + border-radius: 0 0 8px 8px; + padding: 1rem; + margin-top: -8px; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); + font-size: 1rem; +} + +.keybox input:focus { + outline-color: rgb(47, 98, 192); +} + +.keybox input::placeholder { + color: #aaadb4; +} + +.keybox input:focus:placeholder { + outline: none; +} + +.createDeviceButton { + appearance: none; + cursor: pointer; + background-color: #fff; + border: none; + border-radius: 6px; + box-shadow: 0 3px 6px -3px #0000001a; + font-size: 1em; + margin-bottom: 1em; + padding: 0.5em; +} + +.createDeviceButton:disabled { + background-color: #e8e8e8; +} + +/*DeviceEventLogger*/ +.eventsContainer { + width: 100%; + max-height: 50vh; + overflow: scroll; + display: flex; + flex-direction: column; + padding: 2rem 1rem 1rem; + margin: -0.5rem; + scroll-snap-type: y proximity; +} + +.eventFrame { + background: white; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); + border-radius: 0.5em; + overflow: scroll; + margin: 0 0.5rem 1rem; + flex: 0 0 auto; + scroll-snap-align: start; + scroll-snap-margin: 1rem; +} + +.eventHeader { + display: flex; + justify-content: space-between; + padding: 0.5em 1rem; + background: #eaeff9; +} + +.eventTime, +.eventType { + color: #53627c; + font-size: small; + padding: 0; + margin: 0; +} + +.eventType { + font-weight: 500; +} + +.eventTime { + color: #6a748c; +} + +.eventProperties { + list-style: none; + padding: 0.5rem 0 0.55rem; + margin: 0; + /* display: inline-flex; */ +} + +.eventProperties li { + margin-top: 0 !important; + padding: 0 1rem; +} diff --git a/docs/network-iot/learn/understanding-lorawan.mdx b/docs/network-iot/learn/understanding-lorawan.mdx new file mode 100644 index 000000000..4b2666d29 --- /dev/null +++ b/docs/network-iot/learn/understanding-lorawan.mdx @@ -0,0 +1,70 @@ +--- +id: understanding-lorawan +title: Understanding LoRaWAN +pagination_label: Understanding LoRaWAN +sidebar_label: Understanding LoRaWAN +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-iot/learn/understanding-lorawan +--- + +LoRaWAN is a wireless protocol built around a simple tradeoff: sacrifice bandwidth for range and +power efficiency. A LoRaWAN device can transmit small packets (sensor readings, GPS coordinates, +status updates) over several kilometers while running on a battery for years. + +This makes LoRaWAN ideal for applications where devices need to report data infrequently and operate +unattended: agricultural sensors, asset trackers, smart meters, environmental monitors. + +## How Data Flows + +A LoRaWAN device doesn't connect directly to the internet. Instead, it broadcasts a radio signal +that any nearby gateway can receive. The gateway forwards the message to a LoRaWAN Network Server +(LNS), which authenticates the device, decrypts the payload, and delivers it to your application. + +```mermaid +graph LR + device[Device] -->|LoRa radio| gateway[Gateway] + gateway -->|IP| lns[Network Server] + lns --> app[Your Application] +``` + +Multiple gateways can receive the same transmission. The network server deduplicates these messages +and selects the best one based on signal quality. This redundancy improves reliability without +requiring anything special from the device. + +## Device Keys + +Every LoRaWAN device is provisioned with cryptographic keys that authenticate it to the network and +encrypt its data. Every device, custom built or off the shelf, has three identifiers: + +**DevEUI**: A unique 64-bit address that identifies the device globally, similar to a MAC address. + +**JoinEUI**: Identifies which network server should handle the device's join request. On Helium, +this is how the Packet Router knows where to send your device's traffic. + +**AppKey**: A secret root key shared between the device and network server. During the join process, +both sides use this key to derive session keys for encrypting data. + +These keys ensure that even though your device's radio signals are received by public gateways, only +your network server can read the contents. + +## On the Helium Network + +Helium Hotspots are LoRaWAN gateways. When a device transmits, any Hotspot in range receives it and +forwards the packet to the [Helium Packet Router][hpr]. The router uses the JoinEUI to determine +which LNS should receive the data, then delivers it there. + +This architecture means a single device can roam across the entire Helium network without +configuration changes. Any Hotspot will pick up its signal and route it correctly. + +:::note + +For deeper technical details on LoRaWAN, see [The Things Network Learn][ttn-learn] or the [LoRa +Alliance LoRaWAN 1.0.2 Specification][lora-spec]. + +::: + +[hpr]: https://github.com/helium/helium-packet-router +[ttn-learn]: https://www.thethingsnetwork.org/docs/lorawan/ +[lora-spec]: + https://resources.lora-alliance.org/technical-specifications/lorawan-specification-v1-0-2 diff --git a/docs/network-iot/lorawan-network-servers/LorawanNetworkServers.jsx b/docs/network-iot/lorawan-network-servers/LorawanNetworkServers.jsx new file mode 100644 index 000000000..91ae3b055 --- /dev/null +++ b/docs/network-iot/lorawan-network-servers/LorawanNetworkServers.jsx @@ -0,0 +1,7 @@ +import useBaseUrl from '@docusaurus/useBaseUrl' + +export const LearnMore = () => ( + <> + Learn More + +) diff --git a/docs/network-iot/lorawan-network-servers/find-a-lns-provider.mdx b/docs/network-iot/lorawan-network-servers/find-a-lns-provider.mdx new file mode 100644 index 000000000..f1e898e2c --- /dev/null +++ b/docs/network-iot/lorawan-network-servers/find-a-lns-provider.mdx @@ -0,0 +1,31 @@ +--- +id: find-a-lns-provider +title: Find A LoRaWAN Network Server Provider +pagination_label: Find An LNS Provider +sidebar_label: Find An LNS Provider +description: Find A LoRaWAN Network Server Provider +image: https://docs.helium.com/img/link-image.png +slug: /iot/find-a-lns-provider +--- + +import LnsProvidersTable from './findAnLnsProvider' + +Professional hosting companies can provide support and immediate access to a ready-to-go +connectivity platform. LNS Services will vary in price, support, and features depending on the +company. Companies may offer public shared servers, and/or private servers. + +The following providers within the OpenLNS initiative offer multi-tenant and private instances to +businesses and individuals. + + + +:::note + +Helium is not directly associated with the listed vendors and makes no endorsements about the +quality of their offerings. + +::: + +> If you offer public LNS services and would like to add your company to this list, submit a pull +> request adding your company to the +> [LNS Providers](https://github.com/helium/well-known/tree/main/lists/lns-providers) list. diff --git a/docs/network-iot/lorawan-network-servers/findAnLnsProvider.js b/docs/network-iot/lorawan-network-servers/findAnLnsProvider.js new file mode 100644 index 000000000..404995a07 --- /dev/null +++ b/docs/network-iot/lorawan-network-servers/findAnLnsProvider.js @@ -0,0 +1,80 @@ +import React, { useMemo, useState, useEffect } from 'react' +import { useTable, useSortBy } from 'react-table' + +const LnsProvidersTable = () => { + const [data, setData] = useState([]) + + useEffect(() => { + fetch( + 'https://raw.githubusercontent.com/helium/well-known/main/lists/lns-providers/providers.json', + ) + .then((response) => response.json()) + .then((data) => setData(data)) + .catch((error) => console.log(error)) + }, []) + + const columns = useMemo( + () => [ + { + Header: 'Name', + accessor: 'name', + Cell: ({ row }) => ( + + {row.values.name} + + ), + }, + { + Header: 'Service Region', + accessor: (provider) => provider.serviceRegion.join(', '), + }, + { + Header: 'Offering', + accessor: (provider) => provider.serverType.join(', '), + }, + { + Header: 'Description', + accessor: 'description', + }, + ], + [], + ) + + const { getTableProps, getTableBodyProps, headerGroups, rows, prepareRow } = useTable( + { columns, data }, + useSortBy, + ) + + return ( + + + {headerGroups.map((headerGroup) => ( + + {headerGroup.headers.map((column) => ( + + ))} + + ))} + + + {rows.map((row) => { + prepareRow(row) + return ( + + {row.cells.map((cell) => { + return + })} + + ) + })} + +
+ {column.render('Header')} + + {column.isSorted ? (column.isSortedDesc ? ' ▼' : ' ▲') : ''} + +
{cell.render('Cell')}
+ ) +} + +export default LnsProvidersTable diff --git a/docs/network-iot/lorawan-network-servers/lorawan-network-servers.mdx b/docs/network-iot/lorawan-network-servers/lorawan-network-servers.mdx new file mode 100644 index 000000000..35d2c7307 --- /dev/null +++ b/docs/network-iot/lorawan-network-servers/lorawan-network-servers.mdx @@ -0,0 +1,56 @@ +--- +id: lorawan-network-servers +title: LoRaWAN Network Servers +pagination_label: LoRaWAN Network Servers +sidebar_label: Introduction +description: LoRaWAN Network Servers +image: https://docs.helium.com/img/link-image.png +slug: /iot/lorawan-network-servers +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' +import { LearnMore } from './LorawanNetworkServers' + + + +A LoRaWAN Network Server (LNS) is a vital component of a LoRaWAN network responsible for device +management, message routing, and integration with application servers. LoRaWAN Network Servers play +a crucial role in ensuring the scalability, reliability, and interoperability of LoRaWAN networks. + +
+ +
Simplified block diagram of Data Transfer Accounting.
+
+ +## Connect and Manage Devices on Helium + +There are a couple of options to get started onboarding devices and connecting through a Helium LNS. + +
+
+
+

Work with a Service Provider

+ + Professional LNS hosting companies can provide support and immediate access to a ready-to-go + connectivity platform. + + + + +
+
+

Self Host an LNS

+ + Comfortable setting up, configuring, and managing your servers? Hosting your own LNS could + be a good option. + + + + +
+
+
diff --git a/docs/network-iot/lorawan-on-helium.mdx b/docs/network-iot/lorawan-on-helium.mdx index 9a436023c..645671b04 100644 --- a/docs/network-iot/lorawan-on-helium.mdx +++ b/docs/network-iot/lorawan-on-helium.mdx @@ -5,32 +5,83 @@ pagination_label: LoRaWAN On Helium sidebar_label: LoRaWAN On Helium description: Helium Documentation image: https://docs.helium.com/img/link-image.png -slug: /lorawan-on-helium +slug: /iot/lorawan-on-helium --- import useBaseUrl from '@docusaurus/useBaseUrl' - - -In typical LoRaWAN Networks, a central or regional LNS is managed by a single entity. Helium’s -design for a decentralized Network, however, means not only do we want gateways (referred to as -Hotspots) to be independently owned and operated, but we want to enable the independent operation of -the LNS. + + +## Overview + +The Helium Network has many points of distinction from a typical LoRaWAN network that are critical +for understanding before deploying internet of things (IoT) applications on Helium. + +In conventional LoRaWAN networks, end devices, such as sensors or actuators, send LoRa wireless +messages to physical gateway devices. These gateways, in turn, forward the messages from the end +devices to central or regional LoRaWAN Network Servers (LNSs) which decompose the messages for +processing in IoT applications. Typically, LoRaWAN networks are run by a central authority in either +public or private configurations. In public configurations, the central authority allows multiple +customers to leverage gateways and LNSs in developing end-to-end IoT applications. Conversely, in +private configurations, a single entity uses the network and all of its networking components. + +The Helium Network takes a different approach with respect to LoRaWAN networks. Rather than have a +centralized authority responsible for managing gateway devices (referred to as Hotspots in the +Helium parlance) or LNSs that serves as a gatekeeper for deploying end devices, Helium allows for +the decentralized operation of both Hotspots and LNSs with a completely permisionless architecture. +In practice, this means that anybody can run a Hotspot device and provide LoRaWAN coverage to the +Helium Network. Similarly, anybody can operate an LNS and provide cloud connectivity and +configuration for end devices. In turn, end devices operating on the Helium Network are able to tap +into the global network of LoRaWAN connectivity powered by community operated Hotspots and gain +access to the largest LoRaWAN network ever created. + +In the remainder of this section, a high-level overview of the architecture of the Helium Network +will be provided, in addition to a discussion on terminology of networking primitives. + +## High-Level Architecture + +Given the unique architecture of the Helium Network in comparison to typical LoRaWAN networks, it is +helpful to understand how Helium manages a large, decentralized ecosystem of Hotspots and LNSs. + +In this regard, a first primary difference is that rather than having gateway devices directly +communicate with LNSs, Helium introduces the concept of an intermediate routing service called +[Helium Packet Router (HPR)](https://github.com/helium/helium-packet-router) that handles the +connectivity between LNSs and Hotspots. As shown in the diagram below, end devices still send +messages to Hotspots, but instead of the Hotspots subsequently forwarding the messages to directly +to an LNS, the Hotspots send the messages to HPR. In doing so, HPR can identify the particular +Hotspots that forwarded the message from the end device in order to properly credit the Hotspot with +data transfer rewards on the Helium Network. + +A second primary difference is with the introduction of the +[Helium IoT Config Service](https://github.com/helium/oracles/tree/main/iot_config) which serves as +an interface for users for configuring routing rules relied on by HPR when determining where to +forward messages from end devices to LNSs. Users can leverage tools including the +[Helium Config Service CLI](https://github.com/helium/helium-config-service-cli) for providing +routing rule configurations to the Config Service (and in turn HPR). + +```mermaid +graph LR + dev[Device] --> gateway[Hotspot] + gateway --> hpr[Helium Packet Router] + hpr --> lns[LoRaWAN Network Server] + hpr <--> ics[Helium IoT Config Service] + lns --> ics + lns --> i[Integrations] +``` -Without this, access to the Network would require permission from a single central entity, the LNS -operator of the Network. +
-Therefore, we want to enable the multi-tenancy of LNSs on the same public LoRaWAN Network. Achieving -this distinguishes Helium’s LoRaWAN Network from any other: public wireless infrastructure is now -compatible with privately-run Network Servers. +For a deeper understanding of the architecture of the Helium Network, users are encouraged to read +documentation and review the open-source code for HPR and IoT Config Service: -The rest of this article will discuss the networking primitives. If you want to go ahead and run a Network Server, please check out our article about [running a network server][run-server]. +- [HPR](https://github.com/helium/helium-packet-router) +- [Config Service](https://github.com/helium/oracles/tree/main/iot_config) ## The OUI -Each LoRaWAN Network Server (LNS) on the Helium Network acquires an Organizationally Unique -Identifier (OUI). This registers the LNS with the blockchain and allocates two very important -routing objects owned and maintained by the OUI Operator: +Each LNS on the Helium Network acquires an Organizationally Unique Identifier (OUI). This registers +the LNS with the blockchain and allocates two very important routing objects owned and maintained by +the OUI Operator: - one or more **slabs** of DevAddrs, reserving NwkAddr space for the OUI's devices on the Helium Network @@ -41,14 +92,32 @@ Integrity Check (MIC) to disambiguate. Starting in 2023, Helium will be utilizing an OpenLNS Initiative to allow more choice and increase usability. You can read more about the OpenLNS Initiative at the [Helium Foundation -Blog][foundation-blog] or read more [here](/iot/open-lns). +Blog][foundation-blog] or read more in the [Use Helium LoraWAN](/iot/lorawan-network-servers) +section. + +## Organizationally Unique Identifier + +Organizationally Unique Identifiers (OUIs) are registered identities on the Helium Blockchain. To +send and receive packets to an end-device, a network user needs to be serviced an OUI. + +An OUI has some specificities related to LoRaWAN and packet routing, as +[documented above](/iot/lorawan-on-helium#the-oui), but with respect to the blockchain, what's +important is that +[only libp2p addresses registered as endpoints for the OUI](https://github.com/helium/proto/blob/master/src/blockchain_txn_oui_v1.proto#L6) +may open and close state channels on behalf of an OUI. + +For example, the account `13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc` purchased the first +OUI on the Helium Blockchain. The address `112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE` +operates the OUI on behalf of the owner. + +OUIs are purchased and numbered in incrementing order. :::info Based on the latest benchmarking tests the upper limit for a Devaddr `1024` slab is approximately 5800 devices, but results still need to be replicated and bracketed. Community members are -encouraged to run their own benchmarking tests. Instructions [here][router-benchmark]. Requires -basic familiarity with Linux and Bash command line. +encouraged to run their own benchmarking tests. Requires basic familiarity with Linux and Bash +command line. ::: @@ -105,5 +174,3 @@ query can say which OUI owns this DevAddr slab. This look-up and routing by DevA [foundation-blog]: https://medium.com/helium-foundation/scaling-iot-growth-with-heliums-open-lns-initiative-c906e6953d6d -[run-server]: /use-the-network/run-a-network-server -[router-benchmark]: /use-the-network/run-a-network-server/router-benchmarking diff --git a/docs/network-iot/lorawan-roaming-getting-started.mdx b/docs/network-iot/lorawan-roaming-getting-started.mdx deleted file mode 100644 index 12c9ecfb3..000000000 --- a/docs/network-iot/lorawan-roaming-getting-started.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -id: lorawan-roaming-quickstart -title: Getting started with Roaming -pagination_label: Roaming Getting Started -sidebar_label: Roaming Quickstart -description: Helium Roaming Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/lorawan-roaming-quickstart ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Config Service is an Oracle service that stores all routing information on the Helium IoT Network. -Each roaming partner is registered in the Config Service under their Net ID and may define multiple -routes. Each route contains information such as - -- **DevEUI+AppEUI pairs** — so we know which join requests to send your way -- **DevAddr ranges** — so we know which uplinks to send your way -- **Server endpoint + port** — so we know where to send packets to - -There are two ways of interacting with the Config Service, directly through GRPC APIs or through CLI -(command-line-interface). - -Let’s do some setup with the CLI. - -1. Run this to pull & build the config service cli: - - ```bash - $ git clone https://github.com/helium/helium-config-service-cli.git - $ curl https://sh.rustup.rs -sSf | sh - $ source "$HOME/.cargo/env" - $ cd helium-config-service-cli - $ cargo b --release - ``` - -2. You can then find the built binary file `helium-config-service.cli` under `./target/release` - inside the `helium-config-service-cli` directory. I’d rename it into short such as `main` so you - can type less words (you can rename it by running `mv helium-config-service-cli main`) - -3. Now that we have the CLI binary, let’s just put it in a separate folder. This is recommended only - for simplicity's sake. Just copy `main` into the folder you created. You can reference the - following commands: - - ```bash - $ cd .. - $ mkdir cli-testing - $ cd cli-testing - $ cp ../helium-config-service-cli/target/release/main . - ``` - -4. Let’s generate the keypair you’ll be using to authenticate your interactions with the config - service, so only you can create/modify/delete routes. Run `./main env generate-keypair --commit` - and you should find a file called `keypair.bin`. Print out the public key of your keypair by - running: - - ```bash - $ ./main env info --keypair keypair.bin - ``` - -5. Next, make sure you have a Helium Wallet. - [You can download them here](https://wallet.helium.com/). - -6. Contact the Helium Foundation with your public key and Helium Wallet address via email at - [hello@helium.foundation](mailto:hello@helium.foundation) for the information needed in the next - steps. - -7. Next, let’s initialize some environment variables so that you don’t have to tell the CLI the same - thing over and over again in later commands: - - 1. Run `./main env init` - 1. Fill in `http://mainnet-config.helium.io:6080/` for `Config Service Host` - 1. Fill in the path `./keypair.bin` for `Keypair Location` - 1. Fill in your NET ID for `Net ID` - 1. Fill in your OUI for `Assigned OUI` - 1. Fill in the number of multi-buy you want for `Default Max Copies` as a default for your - routes. - 1. Then export the environment variables. This needs to be done manually. You will see something - like this and just add `export` to each line and run it. For instance, you would run export - `HELIUM_MAX_COPIES=15` variable. Do NOT put a space around the `=` sign - - - -8. Now, you are ready to generate your first route. Routes contain necessary information for us to - know how to route a packet — DevEUI+AppEUI (for routing join requests), DevAddr range (for - routing uplinks), Endpoint (so we know where to send the packet to), etc. - - 1. Run `./main route new --commit` - 1. You can then see the empty route template. It should look like this, except that you should be - seeing your own Net ID, assigned OUI, max_copies in there: - - - -9. Next, let’s define DevAddr range so packet router knows which uplinks to route to your endpoint. - Just use your OUI’s assigned DevAddr range, which you can get by running `./main org get`. - Afterwards, run: - - ```bash - $ ./main route devaddrs add -s -e --route-id -- commit - ``` - -10. Next, let’s define EUI pairs so packet router knows which join requests to route to your - endpoint. You can run: - - ```bash - $ ./main route euis add --route-id -d -a --commit - ``` - -11. Next, let’s define the endpoint that you use for ingesting traffic. You can run: - - ```bash - $ ./main route update server --host --port --route-id --commit - ``` - -12. Lastly, define other relevant parameters for HTTP roaming. You can run: - ```bash - $ ./main route update http --dedupe-timeout --path --auth-header --route-id --commit - ``` diff --git a/docs/network-iot/lorawan-roaming-on-helium.mdx b/docs/network-iot/lorawan-roaming-on-helium.mdx deleted file mode 100644 index 590077cd4..000000000 --- a/docs/network-iot/lorawan-roaming-on-helium.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: lorawan-roaming -title: LoRaWAN Roaming on Helium -pagination_label: Roaming -sidebar_label: Roaming -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/lorawan-roaming ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Helium Network is the world's largest LoRaWAN Network - and continues to grow at a staggering -pace. Because of this, it becomes a very attractive Network to other public and private LoRaWAN -Network Server providers (LNSs) who want to extend their coverage without deploying their own -infrastructure and capital. - -And thanks to the Helium blockchain, direct roaming integrations are very simple. Most importantly, -major LNSs are roaming with the Helium Network, which means the public coverage the Helium Community is -building is now being used by LoRaWAN devices onboarded to other Networks, and Hotspot Operators get -compensated in $HNT for routing these packets. - -For more information about the roaming services offering go [here](/use-the-network/roaming). - -## Helium Roaming Architecture - -Helium Network roaming most closely resembles the LoRa Alliance's idea of "Passive Roaming". The -Helium Community operates a dedicated Roaming Server (the "Helium Roaming Server") that is distinct -from our core LNS for native Helium Devices. The Helium Roaming Server purchases all packets for a -target LoRaWAN `NetID` and forwards them to an endpoint ready to accept them on behalf of a Roaming -Partner's LNS. Specifically, the Helium Roaming Server connects any Helium Gateway that captures -target `NetID` packets via the Semtech GWMP UDP client. - - - -## Actual Roaming Integration - -To ingest packets as a roaming partner, you need to accept Semtech GWMP client connections for the -amount of Helium Hotspots that are receiving and routing your packets. Currently, this could be a -lot - assuming you are considering the entire global network. In practice, only a small percentage -of Helium Gateways will be routing packets for a roaming partner NetID simultaneously. - -When the roaming PoC is initiated, Helium provides one or more IPs from where the connections will -originate. You will need to supply the IP and port for the host listening for Semtech GWMP -connections over UDP. Once provided, packets will start arriving at the specified host. - -## Supported Device Functionality - -Helium Roaming supports the following actions for devices: - -- **Joining**: a new device provisioned to a roaming partner's LNS can join via the Helium Network. - For new devices, `join_requests` and `join_accepts` are routed via Helium Hotspots. -- **Uplinking**: Once a device has joined, all device payloads are routed via Helium. -- **Downlinking**: All standard device downlinking is supported. - -## Extended Reading - -- [LoRaWAN on Helium](/lorawan-on-helium) - The Helium Network's approach to LoRaWAN -- [Helium LoRaWAN: Public Infrastructure with Private Network Servers](https://blog.helium.com/helium-lorawan-public-infrastructure-with-ultimate-privacy-9132560e4ae6) -- [Helium Network Data Credits](/data-credit) - The financial mechanism for purchasing packets from - the Helium Network -- [Packet Purchasing](/blockchain/packet-purchasing) - An explanation of how packet purchasing is - implemented on the Helium Network diff --git a/docs/network-iot/lorawan-roaming.mdx b/docs/network-iot/lorawan-roaming.mdx new file mode 100644 index 000000000..baa624694 --- /dev/null +++ b/docs/network-iot/lorawan-roaming.mdx @@ -0,0 +1,151 @@ +--- +id: lorawan-roaming +title: LoRaWAN Roaming on Helium +pagination_label: Roaming +sidebar_label: Roaming +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/lorawan-roaming +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +Before getting started, make sure to have the following: + +- Helium Network Organizationally Unique Identifier (OUI). +- Data Credits (>3.5M DC). +- A NetID issued by the LoRa Alliance. +- A roaming endpoint so your LNS can receive roaming traffic. +- [Helium Config Service CLI](https://github.com/helium/helium-config-service-cli) installed. + +For guidance on purchasing and funding an OUI, refer to the following guides: + +- [Buy an OUI](/iot/run-an-lns/buy-an-oui) +- [Fund an OUI](/iot/run-an-lns/fund-an-oui) + +## Roaming Quickstart + +While your roaming endpoint is up and running, you need to let the Helium config service know of its +existence. Initialization of some CLI environment variables will streamline the process: + +Run `helium-config-service-cli env init` + +1. Fill in the relative path of the delegate key pair file for `Keypair Location` +1. Fill in `Your Net ID` for `Net ID` +1. Fill in your assigned OUI for `Assigned OUI` +1. Fill in the number of `multi-buy` you want for `Default Max Copies` as a default for your + routes. +1. Export the environment variables. This needs to be done manually. The CLI will list values to be + exported. Add `export` to each line and run it. For instance, run `export HELIUM_MAX_COPIES=15` + to set the max_copies value in the session. Be sure not to put a space around the `=` sign + +```sh title="Setting environment variables in a terminal window." +export HELIUM_KEYPAIR_BIN=<./your/path/to/delegate/keypair.bin> +export HELIUM_NET_ID=00003C +export HELIUM_OUI= +export HELIUM_MAX_COPIES=15 +``` + +Now, you are ready to generate your first route. Routes contain the necessary information for us to +know how to route a packet — DevEUI+AppEUI (for routing join requests), DevAddr range (for routing +uplinks), endpoint (so the network knows where to send the packet), etc. + +1. Run `helium-config-service-cli route new --commit` +1. You can then see the empty route template. It should look like this, except that you should be + seeing your NetID, assigned OUI, and max_copies value: + +
+ +
Route creation as shown in a terminal window.
+
+
+ +Next, let's define the endpoint that you use for ingesting traffic. You can run: + +```bash +$ helium-config-service-cli route update server --host --port --route-id --commit +``` + +If you are using HTTP roaming, you need to run: + +- Note that the auth-header and receiver-nsid are optional. + +```bash +$ helium-config-service-cli route update http --dedupe-timeout --path --auth-header --receiver-nsid --route-id --commit +``` + +If you are using GWMP roaming, you need to run: + +```bash +$ helium-config-service-cli route update add-gwmp-region --route-id --commit +``` + +Make sure your endpoint, port and protocol are set correctly, otherwise, we may not be able to send +traffic to your LNS. + +### How to Add Your First Device + +In this example, we will show you how to add your first device to start roaming. To receive join +request for your device, you need to let Helium know which EUI pair to watch out for. You can run +the following + +**If you are a roaming partner migrating from Roaming Console, please read the +`Migrating from Roaming Console` section below first.** + +```bash +$ helium-config-service-cli route euis add --route-id -d -a --commit +``` + +While this allows your Helium to forward your device's join request, you also need to specify a +DevAddr range on that route so that Helium can forward its uplinks. + +```bash +$ helium-config-service-cli route devaddrs add -s -e --route-id -- commit +``` + +### Migrating from Roaming Console + +If you are a roaming partner migrating from Roaming Console to the new OpenLNS Architecture, please +carefully test out your roaming connections before the full switch. + +While the Roaming Console currently coexists with the OpenLNS Architecture, it is not possible to +have the same device to simultaneously send traffic to both Roaming Console and through OpenLNS +Architecture. + +#### Migrating EUI Pair for Join Requests + +Let's say you had 100 devices on Roaming Console, you can start the migration slowly by registering +1 EUI pair with the CLI, so that 99 of your devices will roam through Roaming Console and 1 of your +devices will roam through OpenLNS. Then, you can keep migrating, possibly registering 50 EUI pairs +with the CLI, so that 49 of your devices will roam through Roaming Console and 51 will roam through +OpenLNS. Eventually, you will have registered all 100 EUI pairs with the CLI, so that all of your +devices will roam through Roaming Console. + +#### Migrating DevAddr Range for Uplinks + +Let's say you have 10 DevAddrs, you can start the migration slowly by registering 1 DevAddr with the +CLI, so that 9 of your DevAddrs will roam through Roaming Console and 1 of your DevAddrs will roam +through OpenLNS. Then, you can keep migrating, possibly registering 5 DevAddrs with the CLI, so that +4 of your DevAddrs will roam through Roaming Console and 6 will roam through OpenLNS. Eventually, +you will have registered all 10 DevAddrs with the CLI, so that all of your devices will roam through +Roaming Console. + +## Advanced Roaming + +The session key filter gives an operator the ability to accept and reject specific roaming traffic +on a device level. Leveraging the session key filter is recommended for all operators. Read more +about the session key filter and other advanced configurations in the +[Advanced Configuration](/iot/run-an-lns/advanced-configuration) section. + +## Roaming Proxy Service + +If Helium's OpenLNS architecture is incompatible with a roaming partner's setup, then they can +leverage +[the roaming proxy service prototype](https://github.com/helium/helium-packet-router-ingest), which +should provide a standard roaming interface. Note that Helium is not in active maintenance of this +service. Helium does not necessarily recommend the usage of this architecture but appreciates the +diverse needs of roaming partners. diff --git a/docs/network-iot/open-lns-getting-started.mdx b/docs/network-iot/open-lns-getting-started.mdx deleted file mode 100644 index b8f5d5111..000000000 --- a/docs/network-iot/open-lns-getting-started.mdx +++ /dev/null @@ -1,134 +0,0 @@ ---- -id: open-lns-quickstart -title: Getting started with OpenLNS -pagination_label: Run a LoRaWAN Network Server -sidebar_label: Run a LoRaWAN Network Server -description: Helium OpenLNS Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/open-lns-quickstart ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -OpenLNS is the platform that enables any LoRaWAN network to use Helium's IoT Network. In this guide, -we'll walk you through the process of setting up and configuring OpenLNS. - -## Prerequisites - -Before getting started, make sure you have the following: - -- Helium Network OUI (Organizationally Unique Identifier) -- Helium LoRaWAN devAddr slab -- LoRaWAN Network Server (LNS). A popular option is [ChirpStack][chirpstack]. Refer to the - ChirpStack documentation for setup and integration instructions. - -## Purchasing OUI and devAddr Slab - -To purchase an OUI and devAddr slab, you will need to use the Helium Foundation's tool. The OUI -costs $100 paid in Data Credits (DC), while the devAddr slab mandates a minimum of 8 devAddrs that -cost $100 each. - -## Managing Your OUI with the Config Service - -After your OUI and devAddr are added, you can now manage your OUI through the Config Service. You -can interact with the Config Service in two ways: - -1. Directly through [GRPC APIs][grpc-api] -2. Using the [Command-Line Interface (CLI)][config-cli] detailed below - -### Authenticating with the Config Service - -Before interacting with the Config Service, generate a key pair to authenticate your interactions, -so only you can create, modify, or delete routes. Run: - -```sh -./helium-config-service-cli env generate-keypair --commit -``` - -You should find a file called keypair.bin. Print out the public key of your key pair by running: - -```sh -./helium-config-service-cli env info --keypair keypair.bin -``` - -### Initialize CLI - -CLI can be initialized with environment variables so common variables don't have to be reiterated in -subsequent commands. - -```sh -./helium-config-service-cli env init -``` - -- Fill in `http://mainnet-config.helium.io:6080/` for `Config Service Host` -- Fill in the path `./keypair.bin` for `Keypair Location` -- Fill in the Helium NetID, `0x00003C` -- Fill in your OUI for `Assigned OUI` -- Fill in the number of multi-buy you want for `Default Max Copies` as a default for your routes. - -Then export the environment variables. - -```sh -export HELIUM_CONFIG_HOST=http://mainnet-config.helium.io:6080/ -export HELIUM_KEYPAIR_BIN=./keypair.bin -export HELIUM_NET_ID=00003C -export HELIUM_OUI=1 -export HELIUM_MAX_COPIES=10 -``` - -### Managing Routes - -You are now ready to generate your first route. Routes contain the necessary information to let the -IoT network know how to route a packet; DevEUI+AppEUI (for routing join requests), DevAddr range -(for routing uplinks), endpoint (where to send the packet to), etc. - -```sh -./helium-config-service-cli route new --commit -``` - -You can then see the empty route template. It should look like this, except that you should be -seeing you own assigned OUI, max_copies, and other environment variables. - -```json -✔️ created route 7a5560e8-b722-11ed-bbe8-c3404da5a84d -{ - "id": "7a5560e8-b722-11ed-bbe8-c3404da5a84d", - "net_id": "C00053", - "oui": 3, - "server": { - "host" : "", - "port": 0, - "protocol": { - "type" : "packet_router" - } - }, - "max copies": 15, - "active": true, - "locked": false -} -``` - -Define DevAddr range so the packet router knows which uplinks to route to your endpoint. Use your -OUI's assigned DevAddr range, which you can get by running `./helium-config-service-cli org get` - -To add your DevAddr range run - -``` -./helium-config-service-cli route devaddrs add -s -e --route-id --commit -``` - -Next, define EUI pairs so the packet router knows which join requests to route to your endpoint. - -``` -./helium-config-service-cli route euis add --route-id -d -a --commit -``` - -Define your endpoint by running - -``` -./helium-config-service-cli route update server --host --port --route-id --commit -``` - -[grpc-api]: https://github.com/helium/proto/blob/master/src/service/iot_config.proto -[config-cli]: https://github.com/helium/helium-config-service-cli -[chirpstack]: https://www.chirpstack.io diff --git a/docs/network-iot/open-lns.mdx b/docs/network-iot/open-lns.mdx deleted file mode 100644 index 8d656ceb7..000000000 --- a/docs/network-iot/open-lns.mdx +++ /dev/null @@ -1,108 +0,0 @@ ---- -id: open-lns -title: OpenLNS Overview -pagination_label: OpenLNS -sidebar_label: OpenLNS -description: Helium OpenLNS Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/open-lns ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The OpenLNS initiative allows anyone looking to deploy devices on the Helium Network to use any -LoRaWAN Network Server (LNS). The LNS you choose must comply with the LoRaWAN specification to -access the Helium Network. - -## Why OpenLNS? - -OpenLNS will deliver the following network improvements: - -1. Increased accessibility -2. Accelerated device joins and a focus on increased speed -3. Increased reliability -4. Enabling massive scalability - ---- - -## Console & LNS Migration - -The OpenLNS Initiative is unaffected by the migration to Solana. LNS Operators and Console Users -will have months to migrate their LNS services. - -OpenLNS allows devices on the Helium Network to use any LoRaWAN Network Server ("LNS") that complies -with the LoRaWAN specification. - - - - - - - -## Network Improvements - -Before OpenLNS, Helium LoRaWAN Network Servers ran on bespoke software especially suited to the -Helium Blockchain. Through Helium HIP-70, these constraints were removed, allowing for a multitude -of simplifications and improvements. - -**Increased Accessibility:**
OpenLNS alleviates the usage and access bottlenecks that stem -from "Helium Console" as the only LNS option and instead scales network access through a large and -diverse set of LNS providers and software suites. - -**Accelerated Device Joins:**
The re-engineered backend architecture removes the need to store -device routing information on the Helium blockchain, dramatically reducing device join time. - -**Increased Reliability:**
By colocating in the same global regions as deployed Hotspots, -additional Oracles can support future demand, reduce latency, and increase redundancy. - -**Enable Massive Scalability:**
The upgraded architecture allows for new device classes and -innovative use cases, with new LoRaWAN infrastructure allowing IoT providers to utilize whichever -LNS they prefer based on features and capabilities. - ---- - -## OpenLNS FAQ - -### Why Are These Changes Necessary? - -In the current architecture, Helium Console is a blockchain-following node. This blockchain -dependency adds cost and complexity and can cause speed and efficiency issues, including device -joins delays and slow, delayed, or dropped packet communications. In addition, the current -architecture limits the scalability to handle future network growth. IoT solution providers can only -access part of the catalog of LoRaWAN-capable devices, and there are limited options regarding how -these devices onboard to the Helium Network. - -Moving data transfer to [Oracles][oracles] will eliminate the need for data transfer accounting -dependent on the blockchain and other chain-following entities, eliminates the issues noted above -while enabling data transfer to massively scale, and removes the fear of chain halts affecting the -underlying Network. - -
- -
Simplified block diagram of Data Transfer Accounting.
-
- -### How Would OpenLNS Provide More Access To The Network? - -OpenLNS allows partners in the ecosystem to use any LNS that complies with the LoRaWAN specification -to access the Helium Network. - -:::note New Capabilities. - -The Helium Console does not support standard LoRaWAN features such as ABP activation or Class C -devices. OpenLNS allows users to choose a different LNS, such as Chirpstack to address these -limitations. - -::: - -Reimagining this landscape of LNS providers offers users a new level of freedom and flexibility. - -### What Is The Current Progress And Future Timeline? - -Alpha testing began in October 2022. After a successful initial alpha period, a larger group of -partners in the ecosystem are participating in the ongoing beta test and are seeing positive -evidence that ABP and Class C devices will be fully functional on the Helium Network. - -Testing will continue through the start of 2023. - -[oracles]: /oracles diff --git a/docs/network-iot/proof-of-coverage.mdx b/docs/network-iot/proof-of-coverage.mdx deleted file mode 100644 index c41f27174..000000000 --- a/docs/network-iot/proof-of-coverage.mdx +++ /dev/null @@ -1,185 +0,0 @@ ---- -id: iot-poc -title: IOT Proof of Coverage Roadmap -pagination_label: Proof of Coverage Roadmap -sidebar_label: Proof of Coverage Roadmap -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /iot/proof-of-coverage ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -# IOT Proof of Coverage Roadmap - -The Helium “IOT” network is the original and largest subnetwork in the Helium system. It uses the -LoRaWAN protocol to provide Internet connectivity to a class of devices that are often described as -“the Internet of Things” (IoT). - -Proof of Coverage is the novel work algorithm that the Helium IOT Network uses to reward Hotspot -owners for providing useful coverage for the Network. Proof of Coverage (PoC) is designed to -incentivize Hotspot owners to deploy Hotspots in underserved areas and report their deployments -accurately so that users of the Network can see where coverage is likely to be available. - -## The Changing Landscape - -Because PoC is such an important part of the Network’s success and continued growth, it must adapt -to change. Change comes in many forms, but the key changes that have happened since the start of the -Network are: - -- The Network has grown exponentially -- Newer radio hardware has been developed -- Newer LoRaWAN features have arisen -- Attempts to subvert PoC have grown in sophistication -- The Network has been re-organized to be more scalable (HIP-70) -- The Network has diversified; there are more actors and roles available -- A talented and committed community has continued to grow as more Hotspots come online - -## The Plan - -While some of these changes are challenges to overcome, most of them are improvements that have -remained as untapped resources — until now. Each of the items in the roadmap that follows -either capitalizes on one of these improved resources or addresses one of the difficult challenges. - -It is also important to recognize that many ideas for improvements to PoC have been proposed by core -developers and community members, not all of which are a part of this immediate roadmap. After we -accomplish the most fundamental steps, improvements that may otherwise have been tabled because they -were deemed too complex to implement will become viable and reconsidered. - -# Step 1: Oracle-Based PoC - In Progress - -From the launch of the Network in 2019 until February 2, 2023, the IOT PoC system relied on a -“Challenger, Beaconer, Witness, Validator, Rewarder” model. In this model at least five separate -actors had to work together to make PoC events happen. Any break in the chain meant the loss of the -entire event and its rewards. - -## A History of Artificial Limits - -Over time, the Core Developers noticed breaks in this chain and have had to enact limits to PoC to -keep it functioning under the extraordinary demand generated by the growth of the Network. These -limits have frustrated Hotspot owners and Network users alike by making it hard to see just how -effective changes and additions to Hotspot setups were. These limits included: - -- A Hotspot could only expect to Beacon roughly once every two days, and -- Only 14 Witnessing Hotspots could be recorded in the results - -## Room to Breathe - -With the adoption of HIP-70, the Core Developers have been able to adopt a newer, higher performing -model known as “Oracle-Based PoC”. Oracle-Based PoC brings two important improvements: - -- It eliminates the Challenger role, allowing Hotspots to be in charge of their own Beacons, and -- It shifts PoC validation to a higher performance actor, known as the _IOT PoC Verifier Oracle_. - -The Verifier Oracle can process and validate PoC events with significantly less overhead than -before, when PoC events had to be validated under strict real-time deadlines by the members of the -currently elected Consensus Group, and which often led to events silently being dropped just to keep -the blockchain moving. - -# Step 2: Removing the Limits to PoC - -Now that Oracle-Based PoC is in effect, we can begin to remove some of the restrictions that had -been holding PoC back. In short, we will: - -- Increase the Beacon rate, and -- Separate Witness reports from Witness Rewards. - -## Increasing the Beacon Rate - -Increasing the Beacon rate per Hotspot will provide the Network and Hotspot owners with more timely -measurements, which in turn will allow them to make improvements with confidence and allow Network -users to quickly see new areas of coverage. Increasing the Beacon rate will be evaluated by the IOT -PoC Working Group as a potential upgrade to functionality on the Network. - -## Publishing the Full Witness List - -Under Oracle-Based PoC we can now separately report the entire list of Witnesses to every Beacon -without also requiring the entire list to be represented on the blockchain, which is solely -dedicated to handing out rewards for the event. The ability to separate these concerns is important -because many Hotspots are routinely Witnessed by many more than the 14 Hotspots reported in the -blockchain rewards transaction, but until now there simply was no place to report them. - -With the advent of Oracle-Based PoC, the IOT PoC Verifier Oracle can publish a side report, off -chain, of the entire witness list to each and every Beacon on the Network. - -# Step 3: Economic Scale Adjustments - -Rewards for Beacons and Witness events under PoC are prioritized by a scheme that was introduced -under HIP-17, which was designed to pay higher rewards for Beacon events that are transmitted from -less-covered areas as a way to encourage Hotspot owners to deploy Hotspots in these areas and -discourage deployments in areas that are already densely covered. PoC currently judges an area as -over- or under-served by consulting a table of density scale values, which dictates, somewhat -arbitrarily, how many Hotspots are needed to effectively cover a given area. - -Currently there are seven “targets” in the list, each of which is a pairing of an area scale and the -ideal number of Hotspots that should be deployed at that scale. As each Hotspot is added to or -removed from the Network, the system examines the deployment and how it affects the Hotspot count at -each of these scales, then it computes a new Transmit Scale for every Hotspot in the regions -affected. If the change is an addition to the Network and that addition increases the density of -Hotspots at a particular scale beyond the ideal density, then every Hotspot in that region has its -Transmit Scale reduced. - -Since HIP-17’s adoption in late 2020, these scales and density targets have remained _unchanged_. - -We should reconsider each density target individually to ensure that its limit makes sense, and if -not, change it. Additionally, we should consider shortening the list and removing area scale targets -that aren’t helpful, such as the “Res 4” scale, which roughly covers an area of 1,770 square -kilometers (683 square miles). - -# A Collection of Next Steps - -After the previously listed steps are adopted, the way forward becomes harder to predict and the -order in which developments must be made is less certain. Nonetheless, we are certain they will -include these “Next Steps”. - -# Next Steps: Algorithmic Experiments - -With more rapid Beaconing and more stable reporting, we can begin performing experimental -adjustments to PoC that will help it measure the surrounding radio environment better and make the -algorithm more robust against simulation attacks, aka “gaming”. - -It is hard to predict how effective any one of the many algorithmic proposals that these changes -will be without simply testing them. Proposed ideas include: - -- Randomized transmit powers -- Randomized coding rates (Spreading Factors) -- The Addition and/or Removal of Error-correcting codes -- Reintroduction of multi-hop paths, secondary Beacons - -# Next Steps: Modeled Coverage - -use suspicious coverage reports as a possible indicator of a misbehaving Hotspot. The IOT Proof of -Coverage shouldn’t reward for coverage that is physically impossible to provide and should Verifier -should incorporate basic terrain data and electromagnetic wave propagation models to judge the -plausibility of Witness events and begin to build a trust model to identify well-behaved Hotspots -amongst those that are untrustworthy. - -# Next Steps: Worldwide Reward Harmonization - -The IOT network uses several different “unlicensed” radio bands across the world. Each of these -bands comes with its own regulations, some of which can change from country to country in the space -of just a few kilometers. Some of these regulations limit the output power and dwell times that a -Hotspot can use when transmitting a Proof of Coverage Beacon, which ultimately changes how easily it -is heard by other Hotspots in the area, and ultimately affects a Hotspot’s PoC rewards. - -Not all of these limits ultimately affect how well a Hotspot can cover a given area, and as such, -any parameter that artificially inflates or deflates a Hotspot’s apparent coverage should be -accounted for when computing a Hotspot’s PoC rewards for a Beacon. Once Reward Harmonization is -enacted, Hotspot owners should be able to expect their rewards to be based only on the effectiveness -and uniqueness of their coverage and not by the particular country or region in which they are -deployed. - -# Next Steps: Secured Mappers and Concentrators - -Introduce specially hardened hardware elements that can cryptographically attest to their locations -and observations. Incentivize this extra expense with extra rewards but continue to let the Network -be composed of standardized and cheaper hardware. - -# Next Steps: Permissionless Participation - -Make it possible for anyone to add a Hotspot to the Network and participate in PoC, just as long as -they provide the onboarding fee. The PoC algorithm will sort out who is providing coverage and who -is not. Don’t require a specialized third party to attest which Hotspots are real and which are -virtualized. diff --git a/docs/network-iot/run-an-lns/FundAnOUI.jsx b/docs/network-iot/run-an-lns/FundAnOUI.jsx new file mode 100644 index 000000000..334a04ba1 --- /dev/null +++ b/docs/network-iot/run-an-lns/FundAnOUI.jsx @@ -0,0 +1,18 @@ +export const OUIUsage = () => ( +
+ +
+ Up-to-date usage metrics for all IoT OUIs on the Helium network.
To get a sense of traffic + and DC usage on the network, check out the full{' '} + + Dune Data Credit Dashboard + + . +
+
+) \ No newline at end of file diff --git a/docs/network-iot/run-an-lns/add-device-chirpstack-grpc.mdx b/docs/network-iot/run-an-lns/add-device-chirpstack-grpc.mdx new file mode 100644 index 000000000..6f10f5590 --- /dev/null +++ b/docs/network-iot/run-an-lns/add-device-chirpstack-grpc.mdx @@ -0,0 +1,266 @@ +--- +id: chirpstack-add-device-grpc +title: Add Device to ChirpStack via gRPC +pagination_label: Add Device to ChirpStack via gRPC +sidebar_label: Add Device to ChirpStack via gRPC +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/chirpstack-add-device-grpc +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +ChirpStack offers a [gRPC API](https://www.chirpstack.io/docs/chirpstack/api/grpc.html) to +facilitate interactions with ChirpStack such as creating device profiles, applications, and devices. +Additionally, ChirpStack provides +[SDKs](https://www.chirpstack.io/docs/chirpstack/api/grpc.html#chirpstack-sdks) in Go, Python, +JavaScript, and Rust for interacting with the gRPC API. Please refer to the +[protocol documentation](https://www.chirpstack.io/docs/chirpstack/api/api.html) for information +regarding the gRPC API specification offered by ChirpStack. + +## Overview + +This guide, outlined by the five step process below, demonstrates how to add a device to ChirpStack +via the gRPC API. + +1. Create an API key using the ChirpStack console +2. Identify the tenant ID using the ChirpStack console +3. Create a Device Profile via the gRPC API +4. Create an Application via the gRPC API +5. Create a Device via the gRPC API + +## Create an API Key Using the ChirpStack Console + +### Access ChirpStack Console + +To create an API key using the ChirpStack console, first access your ChirpStack instance. The +ChirpStack console UI is accessible at `http://:8080`. If no user has been set, +utilize the default credentials to log in: + +Username: admin +Password: admin + +### Generate an API Key + +From the dashboard, click on `API Keys` under the `Tenant` header on the left side panel. + +
+ +
+
+ +Next, click the on the `Add API Key` button in the upper right hand portion of the screen. + +
+ +
+
+ +Finally, provide a name for the API key and click Submit. + +
+ +
+
+ +When complete, take note of the API key as it will not be provided again once you navigate away from +the page. + +## Identify Tenant ID Using the ChirpStack Console + +Still using the ChirpStack console, the `Tenant ID` can be found by found by clicking on `Dashboard` +under the `Tenant` header of the left side panel. The `Tenant ID` will then be found near the top +middle of the tenant dashboard page. + +
+ +
+
+ +Take note of the Tenant ID as it will be required when using the gRPC API. + +## Create a Device Profile via the gRPC API + +The Node.js file provided below demonstrates how to create a device profile via the ChirpStack gRPC +API using the JavaScript SDK. Please note that `` corresponds to the IP address +of the ChirpStack instance, `` corresponds to the API key created through the steps +above, and `` corresponds to the tenant ID identified in the steps above. + + +```js title="ChirpStack profile creation example in Node.js" +// Required imports +const grpc = require('@grpc/grpc-js'); +const deviceProfileGrpc = require('@chirpstack/chirpstack-api/api/device_profile_grpc_pb'); +const deviceProfilePb = require('@chirpstack/chirpstack-api/api/device_profile_pb'); + +// This must point to the ChirpStack gRPC API which is provided by default on port 8080 +const server = ':8080'; + +// The API token obtained from the "Create an API key from ChirpStack Console" section above +const apiToken = ''; + +// Create the client for the DeviceProfileService +const deviceProfileService = new deviceProfileGrpc.DeviceProfileServiceClient( + server, + grpc.credentials.createInsecure(), +); + +// Create the Metadata object +const metadata = new grpc.Metadata(); +metadata.set('authorization', 'Bearer ' + apiToken); + +// Instantiate a DeviceProfile message and provide requisite information +const deviceProfile = new deviceProfilePb.DeviceProfile(); +deviceProfile.setTenantId(''); +deviceProfile.setName(''); +deviceProfile.setRegion(2); // 2 = US915 +deviceProfile.setMacVersion(3); // 3 = LoRaWAN 1.0.3 +deviceProfile.setRegParamsRevision(0); // 0 = A +deviceProfile.setAdrAlgorithmId('default'); // default = Default ADR algorithm (LoRa only) +deviceProfile.setUplinkInterval(3600); +deviceProfile.setSupportsOtaa(true); + +// Instantiate a CreateDeviceProfileRequest message and provide the DeviceProfile +const createDeviceProfileRequest = new deviceProfilePb.CreateDeviceProfileRequest(); +createDeviceProfileRequest.setDeviceProfile(deviceProfile); + +// Use the deviceProfileService client to invoke the create method, providing +// the CreateDeviceProfileRequest and Metadata as arguments +deviceProfileService.create(createDeviceProfileRequest, metadata, (err, resp) => { + if (err !== null) { + console.log(err); + return; + } + + console.log(resp.toObject()); +}); +``` + +## Create an Application via the gRPC API + +The Node.js file provided below demonstrates how to create an application via the ChirpStack gRPC +API using the JavaScript SDK. Similar to the file above for creating a device profile, please note +that `` corresponds to the IP address of the ChirpStack instance, +`` corresponds to the API key created through the steps above, and `` +corresponds to the tenant ID identified in the steps above. + + +```js title="ChirpStack application creation example in Node.js" +// Required imports +const grpc = require('@grpc/grpc-js'); +const applicationGrpc = require('@chirpstack/chirpstack-api/api/application_grpc_pb'); +const applicationPb = require('@chirpstack/chirpstack-api/api/application_pb'); + +// This must point to the ChirpStack gRPC API which is provided by default on port 8080 +const server = ':8080'; + +// The API token obtained from the "Create an API key from ChirpStack Console" section above +const apiToken = ''; + +// Create the client for the ApplicationServiceClient +const applicationService = new applicationGrpc.ApplicationServiceClient( + server, + grpc.credentials.createInsecure(), +); + +// Create the Metadata object +const metadata = new grpc.Metadata(); +metadata.set('authorization', 'Bearer ' + apiToken); + +// Instantiate an Application message and provide requisite information +const application = new applicationPb.Application(); +application.setTenantId(''); +application.setName(''); + +// Instantiate a CreateApplicationRequest message and provide the Application +const createApplicationRequest = new applicationPb.CreateApplicationRequest(); +createApplicationRequest.setApplication(application); + +// Use the applicationService client to invoke the create method, providing +// the CreateApplicationRequest and Metadata as arguments +applicationService.create(createApplicationRequest, metadata, (err, resp) => { + if (err !== null) { + console.log(err); + return; + } + + console.log(resp.toObject()); +}); +``` + +## Create a Device via the gRPC API + +The Node.js file provided below demonstrates how to create a device via the ChirpStack gRPC API +using the JavaScript SDK. Similar to the files above, please note that `` +corresponds to the IP address of the ChirpStack instance, `` corresponds to the API +key created through the steps above, and `` corresponds to the tenant ID identified +in the steps above. + +Additionally, `` and `` correspond to the application and device +profile created via the files above. + +Lastly, `` and `` are unique identifiers for the device being added to +ChirpStack. + + +```js title="Device creation example in Node.js" +// Required imports +const grpc = require('@grpc/grpc-js'); +const deviceGrpc = require('@chirpstack/chirpstack-api/api/device_grpc_pb'); +const devicePb = require('@chirpstack/chirpstack-api/api/device_pb'); + +// This must point to the ChirpStack gRPC API which is provided by default on port 8080 +const server = ':8080'; + +// The API token obtained from the "Create an API key from ChirpStack Console" section above +const apiToken = ''; + +// Create the client for the DeviceServiceClient. +const deviceService = new deviceGrpc.DeviceServiceClient( + server, + grpc.credentials.createInsecure() +); + +// Create the Metadata object. +const metadata = new grpc.Metadata(); +metadata.set('authorization', 'Bearer ' + apiToken); + +// Instantiate a Device message and provide requisite information +const device = new devicePb.Device(); +device.setApplicationId(''); +device.setDeviceProfileId(''); +device.setName(''); +device.setDevEui(''); +device.setJoinEui(''); + +// Instantiate a CreateDeviceRequest message and provide the Device +const createDeviceRequest = new devicePb.CreateDeviceRequest(); +createDeviceRequest.setDevice(device); + +// Use the createDeviceRequest client to invoke the create method, providing +// the CreateDeviceProfileRequest and Metadata as arguments +deviceService.create(createDeviceRequest, metadata, (err, resp) => { + if (err !== null) { + console.log(err); + return; + } + + console.log(resp.toObject()); +}); +``` diff --git a/docs/network-iot/run-an-lns/add-device-chirpstack.mdx b/docs/network-iot/run-an-lns/add-device-chirpstack.mdx new file mode 100644 index 000000000..55d658838 --- /dev/null +++ b/docs/network-iot/run-an-lns/add-device-chirpstack.mdx @@ -0,0 +1,185 @@ +--- +id: chirpstack-add-device +title: Add Device to ChirpStack via Console +pagination_label: Add Device to ChirpStack via Console +sidebar_label: Add Device to ChirpStack via Console +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/chirpstack-add-device +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +Adding a device to your ChirpStack console for the first time is currently a 3 step process. Each +device needs a device profile and each device needs to belong to an application. Integrations are +currently handled per-application level for device(s). + +1. Create a Device Profile or Select from Templates +2. Create an Application +3. Create a Device in the Application + +After adding a device to ChirpStack, take note of the Device EUI and Join EUI values in order to be +able to +[Configure Device in Helium Config Service](/iot/run-an-lns/configure-routing-rules#configure-device-in-helium-config-service) + +## Create Device Profile + +### Device Profiles -> Add Device Profile + +From the dashboard click on **Device Profiles**. + +
+ +
+
+
+ +From **Device Profiles** click on **Add device profile**. + +
+ +
+
+
+ +From here you can either create a new **device profile**, or select one from the **device-profile +templates** if they're available. + +
+ +
+
+
+ +Click **Submit** to add your new device profile. + +
+ +
+
+
+ +## Create Application + +### Applications -> Add Application + +From the **Applications** sidebar menu, click **Add Application**. + +
+ +
+
+
+ +Create the application with a name and description. + +
+ +
+
+
+ +## Create Device in Application {#add-device} + +### Application -> Application-Name -> Add Device + +
+ +Select your Application and click **Add Device**. + +
+ +
+
+
+ +Fill in your device details and select the device profile you made earlier. A Device EUI can be +entered from a pre-provisioned device, or pressing the **↻** button will generate a fresh EUI. +The AppKey will be shown in the next step, don't worry about finding it yet. + +
+ +
+
+
+ +Click **Submit** when done. + +
+ +
+
+
+ +Enter the application key or generate a new one by pressing the **↻** button. + +
+ +
+
+
+ +Click **Submit** once you enter the application key. + +
+ +
+
+
+ +Your device should be created and listed in the application. The **LoRaWAN frames** tab will display +a live view of payloads being delivered to the LNS. +Additional devices can be added to the existing Application. + +
+ +
+
diff --git a/docs/network-iot/run-an-lns/advanced-configuration.mdx b/docs/network-iot/run-an-lns/advanced-configuration.mdx new file mode 100644 index 000000000..f08333e12 --- /dev/null +++ b/docs/network-iot/run-an-lns/advanced-configuration.mdx @@ -0,0 +1,216 @@ +--- +id: advanced-configuration +title: Advanced Configuration +pagination_label: Advanced Configuration +sidebar_label: Advanced Configuration +description: Advanced Configuration +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/advanced-configuration +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Session Key Filter (SKF) {#session-key-filter} + +Session Key Filters (SKF) regulate device traffic on specific devAddrs by utilizing LoRaWAN device +session keys. They establish conditions to either permit or restrict data flow based on the +configured session keys. It essentially allows the LNS operators to accept and reject traffic on a +device (session) level. + +In this example scenario, consider two device addresses (devAddr) 1 and 2: + +- **Provided Session Key for devAddr 1 and "ignore empty skf" = false:** + Only allows traffic through devAddr 1 if it passes Message Integrity Code (MIC) checks. +- **No Session Key for devAddr 2 and "ignore empty skf" = false:** + All traffic is allowed through devAddr 2 without MIC checks. +- **No Session Key for devAddr 2 and "ignore empty skf" = true:** + All traffic through devAddr 2 is blocked. + +The SKF will regulate traffic based on session key availability and the "ignore empty skf" flag, +independently per devAddr. + +Check the SKF flag for a route by running + +```bash +helium-config-service-cli route get --route-id +``` + +### Importance of Configuring Session Key Filters + +Configuring SKFs for devices introduces an additional layer of security on the Helium network. In +instances where SKFs are not established, the network relies on the devAddr to associate packets +with the respective OUI, potentially attributing unauthorized packet costs to the OUI owner. + +Implementing SKFs counteracts this risk by empowering the Helium Packet Router to authenticate +packets, thus preventing the delivery of unwanted payloads (and their respective DC cost). + +## Max Copies {#max-copies} + +Given that LoRaWAN devices openly broadcast uplinks, it's common for multiple Hotspots to capture +the same device uplink within the Helium Network. LNS operators can customize the number of +duplicate uplinks they wish to receive and pay for by setting a max copies amount, also known as +"multibuy." Configuring the `max_copies` setting offers several significant advantages: + +- **Better downlink performance:** If the max copies setting is 10, the LNS will receive up to 10 + copies of the same uplink, and the downlink will be sent by the Hotspot with the best RSSI of + those 10, per the selection mechanism of the LNS. + Helium reports Hotspots' responses in chronological order, which can be challenging for scheduling + downlinks because the first Hotspot to report may not necessarily be the closest or have the + strongest RSSI/SNR attributes. This is important for downlink scenarios such as Class-C devices, + ADR, confirmed uplinks, or standard downlinks on Class-A devices. Leveraging multibuy ensures that + there is a strong Hotspot available to deliver the downlink message. +- **Geolocation:** It is possible to leverage Hotspot metadata to estimate the sensor location + without GPS or Wi-Fi. +- **Multilateration:** For devices that do not have internal location-solving abilities (GPS), the + metadata of the packet report and Helium Network can be leveraged to solve for a device location. + +The Helium Network charges for each response for a given payload. Each Hotspot that reports a +payload from a given device is eligible to be rewarded. The LNS operator can choose how many reports +they would like to buy. For instance, for a multibuy value of 10 on a device that only receives 8 +reports, the OUI would be charged 8 DC ($0.00008 USD). This assumes the payload was less than 24 +bytes. + +There are two levels of granularity for the max copies setting: + +1. **Route level:** Applies to all devices registered under the route. +2. **SKF level:** Applies only to the device with the specified network session key (NwkSKey). This + configuration overrides the route-level max copies setting. + +As an example, if the LNS operator has a route that contains device A and B, and configures a +route-level max copies setting of 2 and an SKF level max copies setting of 5 for device B, then +device A will inherit the route-level max copies setting of 2, and device B will use its SKF-level +max copies setting of 5. + +### Improve Join Performance + +Since Over-The-Air-Activation (OTAA) devices require a network joining process before they start +transmitting valuable sensor data, it is beneficial to ensure the network joining process is as +effective as possible. + +Join performance can be improved by increasing the number of copies of the same join requests the +LNS receives, because then the join accept will be delivered by the Hotspot with the best RSSI, +increasing the possibility of a successful delivery. + +Join requests are free on the Helium Network. LNS operators can leverage max copies to improve the +join performance without additional cost overhead. + +As an example, the LNS operator can define a route-level max copies setting of 20 and all SKF-level +max copies setting of 1. This will have the effect of allowing up to 20 copies of join requests and +1 copy of uplink. This way, the devices will have a much better chance to join, without consuming +extra DC from the uplinks once joined. + +## Automated EUI and SKF Route Updates + +As the ecosystem of LNS operators grows, an increasing number of developers have open-sourced their +tooling for running a Helium-enabled LNS. These tools enable functionality such as EUI and SKF +automation to per-tenant Data Credit accounting. + +A selection of the tools are outlined below. + +### Helium Route Updater + +The Helium Route Updater service is a third-party service that can be run alongside a ChirpStack +deployment to automate the adding/removing of EUIs as well as enabling session key filters on +devices to block traffic from devices that are not yours. + +You can find the service on GitHub +[here](https://github.com/thisisdevelopment/helium-route-updater). There is also a section in the +readme that details how to easily add it to your ChirpStack docker compose, found +[here](https://github.com/thisisdevelopment/helium-route-updater#chirpstack-docker-compose-usage). + +### Disk91 Helium Chirpstack + +This service includes several utilities including EUI management and per-tenant accounting. + +Find the service on GitHub [here](https://github.com/disk91/helium-chirpstack-community) + +### Chirpstack-hpr by Bones + +This service includes several utilities including EUI and SKF management. + +Find the service on GitHub [here](https://github.com/ccall48/chirpstack-hpr). + +Documentation on getting started can be found +[here](https://ccall48.github.io/chirpstack-hpr.github.io/). + +## Config Service Interaction + +The Config Service can be used to manage an OUI and devAddr. There are two ways to interact with the +Config Service: + +1. Using the [Command-Line Interface (CLI)](https://github.com/helium/helium-config-service-cli). +1. Alternatively, you can write scripts to interact with the Config Service directly through + [GRPC APIs](https://github.com/helium/proto/blob/master/src/service/iot_config.proto) for a more + programmatic approach. + +## Hotspot Location Data + +Hotspot location data can be requested from the Config Service using either the CLI or GRPC APIs. + +## EUI Pair Wildcard + +In some applications, deployers may have many DevEUIs all associated under the same AppEUI, and it +might be inconvenient to provision all those EUI pairs individually. If the LNS operator would like +to receive Join Requests for all devices under a certain AppEUI, simply input 0000000000000000 for +the DevEUI when adding an EUI pair. + +## Add and Remove Delegate Keys + +Note that only owner key can perform the actions below. OUI owners can add delegate keys by running + +```bash +helium-config-service-cli org update delegate-add --pubkey --keypair --commit +``` + +OUI owners can remove delegate keys by running + +```bash +helium-config-service-cli org update delegate-remove --pubkey --keypair --commit +``` + +## Set up NGINX for Chirpstack Docker + +NGINX can be used for web serving, reverse proxy, caching, load balancing, SSL and etc. In order to +set it up on Chirpstack docker, add the following section in docker-compose.yml + +```bash +nginx: + image: nginx:latest + container_name: chirpstack_nginx + restart: always + volumes: + - "./logs/nginx:/var/log/nginx" + - "./configuration/nginx.conf:/etc/nginx/conf.d/default.conf" + ports: + - 80:80 + - 443:443 + depends_on: + - chirpstack + networks: + - iot-network +``` + +and then create a new file under the configuration directory called nginx.conf, with the following +content + +```bash +upstream chirpstack_upstream { + server chirpstack:8080; +} + +server { + listen 80; + server_name _; + + location ^~ /api { + grpc_pass grpc://chirpstack_upstream; + } + + location / { + proxy_pass http://chirpstack_upstream; + + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_redirect off; + } +} +``` diff --git a/docs/network-iot/run-an-lns/buy-an-oui.mdx b/docs/network-iot/run-an-lns/buy-an-oui.mdx new file mode 100644 index 000000000..1c90a619b --- /dev/null +++ b/docs/network-iot/run-an-lns/buy-an-oui.mdx @@ -0,0 +1,294 @@ +--- +id: buy-an-oui +title: Buy An Organizationally Unique Identifier +pagination_label: Buy An Organizationally Unique Identifier +sidebar_label: Buy an Organizationally Unique Identifier +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/buy-an-oui +--- + +Each LoRaWAN Network Server (LNS) on the Helium Network is managed using an Organizationally Unique +Identifier (OUI). This registers the LNS with the network and manages the +[devAddrs](#devaddr-explained), [Data Credits](/tokens/data-credit), and routes for device traffic. + +Currently, the purchasing of OUIs and devAddrs must be done by contacting the Helium Foundation. In +the future, these registrations will be self-service. + +As an alternate to purchasing a devAddr slab, it is also an option to obtain a NetID from the LoRa +Alliance and use it in a roaming configuration. An OUI and data credits are required in either +scenario. + +## Pricing + +The minimum cost to deploy an LNS to the Helium Network is \$235 USD. This cost is divided into +three parts. + +The cost of an OUI is US\$100. This is a one-time fee. + +DevAddrs are issued in blocks of 8 and cost US\$12.50 per devAddr for a total of \$100. DevAddrs are +also purchased as a one-time fee. DevAddrs are only required if a NetID is not already obtained from +the LoRa Alliance. + +A minimum of 3,500,000 Data Credits (\$35 USD) must be held in the escrow account associated with +the OUI. DC are consumed in proportion to the network traffic transferred[^1]. If the DC balance +drops below 3.5M, device traffic to the routes associated with the OUI will halt. + +| Item | Fee | +| ------------------- | ------------------- | +| OUI | \$100 | +| DevAddr | \$12.50 × 8 (\$100) | +| Data Credit Minimum | \$35 | + +[^1]: [Data Credits and IoT network traffic explained.](/tokens/data-credit#dc-and-iot) + +## Prerequisites + +Before purchasing an OUI and devAddr slab, a Helium wallet, OUI owner key pair, and OUI delegate key +pair need to be created. + +The steps provided below outline how to do so: + +1. [Create Helium Wallet in Solana Format](#create-wallet) +2. [Convert Solana Formatted Public Key to Legacy Helium Format](#convert-wallet) +3. [Install The Config Service CLI](#install-cli) +4. [Generate OUI Keys](#generate-keys) + +### 1. Create Helium Wallet in Solana Format {#create-wallet} + +To create a Helium wallet, you can follow the guide for +[creating a new Helium Account](/wallets/helium-wallet-app). + +In doing so, a Helium wallet will be generated with key pairs in the native Solana format. + +### 2. Convert Solana Formatted Public Key to Legacy Helium Format {#convert-wallet} + +The OUI configuration process currently leverages public keys in a format from the legacy Helium L1 +blockchain. To convert a Solana public key into the legacy format, use the conversion tool below. + +To use the tool, simply paste your Helium wallet public key in the Solana format into the top "Enter +Helium or Solana Wallet Address" field and copy the result from the "Helium Address" field. + +**This value will be the Helium wallet public key in the legacy format required for purchasing an +OUI**. + +import { DisplayLegacyWallet } from '@theme/DisplayLegacyWallet' + +
+ +
+ +### 3. Install The Config Service CLI {#install-cli} + +The [Helium Config Service CLI](https://github.com/helium/helium-config-service-cli) will be used to +generate the key pairs used for the OUI. Run the following commands to pull & build the config +service CLI: + +```bash title="Copy the latest source code from GitHub." +git clone https://github.com/helium/helium-config-service-cli.git +``` + +To build the copied code, the Rust compiler must be installed. + +```bash title="Install the Rust toolchain." +curl https://sh.rustup.rs -sSf | sh +``` + +```bash title="Add Rust to path." +source "$HOME/.cargo/env" +``` + +Add the protobuf library which will be used during the compile process. + +```bash title="Install protobuf (Mac)" +brew update && brew install protobuf +``` + +```bash title="install protobuf (Ubuntu)" +sudo apt update && sudo apt install protobuf-compiler +``` + +With the build toolchain installed, compile the CLI. + +```bash title="Enter the directory and compile the CLI" +cd helium-config-service-cli && cargo build --release +``` + +The built binary file `helium-config-service-cli` can be found under `target/release/` inside the +`helium-config-service-cli` directory. + +Now that we have the CLI binary, let's put a copy in the local bin folder for simplicity's sake. +Just copy `helium-config-service-cli` into `/usr/local/bin`. Files added to the bin folder will +automatically be available to your command line. + +```bash +sudo cp target/release/helium-config-service-cli /usr/local/bin/ +``` + +### 4. Generate OUI Keys {#generate-keys} + +Generate the key pairs you'll be using to authenticate your interactions with the config service. +These keys are implemented such that only you can createm, modify, and delete routes. + +After this step you will have two key pairs: + +- **Delegate Key Pair**: The delegate key is actively used to create and manage routes. In case it + is ever compromised, it can be updated using the owner key. Note that an OUI can have multiple + delegate key pairs. Guidance on how to manage delegate key pairs can be found in the + [advanced configuration](/iot/run-an-lns/advanced-configuration). + +- **Owner Key Pair**: The owner key is irreplaceable and should be kept safe, secure, and private at + all times. If lost or compromised, you could lose your OUI. The owner key pair is used for + delegate key management. + +Run the generate key pair command twice. First for the owner key pair and second for the delegate +key pair. Name the files accordingly. + +```bash title="Generate key pair" +helium-config-service-cli env generate-keypair .bin +``` + +Print out the public key of the key pair by running: + +```bash +helium-config-service-cli env info --keypair .bin +``` + +```json {9} title="Example response from the info command highlighting the key pair." +{ + "arguments": { + "config_host": "unset", + "key_type_from_keypair": "ed25519", + "keypair": "/Users/me/test.bin", + "max_copies": null, + "net_id": null, + "oui": null, + "public_key_from_keypair": "13eY9uE5fjMzKC7PZ1nsDigiyurhXhV3bbj8pxbD2KtQTSC1ZHP" + }, + {/* env vars will be discussed later */} +} +``` + +The `.bin` files should be kept safe and never shared. + +**The public keys of the owner and delegate key pairs are required for purchasing an OUI and are the +only part that should be shared.** + +## Purchasing OUI and devAddr Slab + +Direct purchase of OUIs and devAddrs are not currently available on-chain. Send an email to +[hello@helium.foundation](mailto:hello@helium.foundation) containing the following information: + +- The Helium wallet address +- The public key of your owner key pair +- The public key of your delegate key pair +- The number of devAddrs you want or your non-Helium Net ID + +Once you receive your OUI, the next step is to fund it. There are several options in the +[Fund an OUI](/iot/run-an-lns/fund-an-oui/) guide. + +## Share The LNS With The Community + +- **Add the LNS to the 'Well Known' list.** + Helium operates as a permissionless network, which means it is possible to leverage the network + with complete anonymity. In the interest of making the network more transparent, an LNS can be + added to the [Well Known](https://github.com/helium/well-known) list. + + This list is leveraged in labeling OUIs with a human-readable name on public Helium Foundation + [dashboards](https://dune.com/helium-foundation/helium-data-credits) and other community-run + dashboards. Consider adding your LNS to this resource. + +- **Add the LNS to the public providers page.** + If the OUI is being used for publicly accessible operations, let the community know that business + is open! Add the LNS to the [Find an LNS Provider](/iot/find-a-lns-provider) page. + +--- + +## DevAddr Explained + +Device addresses or `DevAddr` are assigned to a device by the LNS during the join procedure as +defined in the +[LoRaWAN 1.0.3 Specification](https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-3/). +A device, defined by `(AppEUI, DevEUI)`, can be allocated any of the devAddrs owned by the OUI. It +is even possible to multiplex many devices on the same DevAddr at the same time, using the Message +Integrity Check (MIC) to disambiguate. + +DevAddrs purchased through the methods outlined above are issued under the Helium Foundation's +NetID, 0x00003C, which was assigned on May 2, 2023, as part of the Helium Foundation's membership in +the LoRa Alliance. + +| NetID (hex) | NetID (decimal) | NwkID (bits) | DevAddr Subnet | +| ----------- | --------------- | ------------ | -------------- | +| 0x00003C | 60 | 6b'111100 | 78000000/7 | + +Customers using their own netID don't need devAddrs from the Helium Foundation. Those with their own +netID assigned by the LoRa Alliance should implement [roaming](/iot/lorawan-roaming) to allow their +devices to use the Helium Network. + +### Multiplexing With DevAddrs + +Multiplexing in LoRaWAN, specifically DevAddr multiplexing, refers to the process where multiple +devices share the same device address (DevAddr). It's a way to manage the limited available range of +DevAddrs and allows more devices to join the network. + +If using ChirpStack, it randomly assigns a DevAddr at join or re-join to the device from the +available range and then multiplexes each DevAddr as needed. The ChirpStack platform does this +through the assignment of the Network Session Key. + +In the event of DevAddr collisions, i.e., when two or more devices have the same DevAddr, the +network server (LNS) uses a technique called a Message Integrity Code (MIC) check computation to +identify the real device behind each data packet. For instance, if there are 4 devices all sending +uplinks on the same DevAddr as shown in the diagram below, the LNS should have 4 network session +keys on the same DevAddr. Upon receiving an uplink on that DevAddr, the LNS will attempt a MIC check +with each of the 4 network session keys, and the uplink will be attributed to the device whose +network session key was successfully validated. + +The computational overhead of these MIC checks is not heavy in most scenarios, these are checks +designed to be performed on low-power devices. However, in high-traffic scenarios, it may be best to +attribute a larger set of DevAddrs rather than allocate additional compute. + +```mermaid +graph LR + subgraph Devices + D1[Device 1] + D2[Device 2] + D3[Device 3] + D4[Device 4] + end + subgraph OpenLNS + PR[Packet Routing] + end + subgraph LNS + MC[MIC Computation] + subgraph Device Identification + DI1[Device 1 Identified] + DI2[Device 2 Identified] + DI3[Device 3 Identified] + DI4[Device 4 Identified] + end + end + D1 -->|Packet with Shared DevAddr| PR + D2 -->|Packet with Shared DevAddr| PR + D3 -->|Packet with Shared DevAddr| PR + D4 -->|Packet with Shared DevAddr| PR + PR --> MC + MC -->|MIC checked with DevAddr and NwkSKey| DI1 + MC -->|MIC checked with DevAddr and NwkSKey| DI2 + MC -->|MIC checked with DevAddr and NwkSKey| DI3 + MC -->|MIC checked with DevAddr and NwkSKey| DI4 +``` + +### How many `DeviceAddr` are needed? + +An allocation of 8 devAddrs is enough for all operators to get started and scale their services. The +demands of devices usually won't become apparent until tens of thousands of frequently uplinking +devices are onboarded. The need for more devAddr depends on a few factors: + +1. Number of devices. +1. Frequency of uplink. +1. Number of copies of a message received. +1. LNS system specs. + +In practice, some deployers are able to successfully support 100k+ devices with 32 DevAddrs. + +More devAddrs can be allocated at any time, and LNSs generally accommodate non-sequential ranges. diff --git a/docs/network-iot/run-an-lns/common-issues.mdx b/docs/network-iot/run-an-lns/common-issues.mdx new file mode 100644 index 000000000..1ebf28ca8 --- /dev/null +++ b/docs/network-iot/run-an-lns/common-issues.mdx @@ -0,0 +1,86 @@ +--- +id: common-issues +title: Common Issues +pagination_label: Common Issues +sidebar_label: Troubleshooting Common Issues +description: Common Issues +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/common-issues +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +# Troubleshooting Common Issues + +## Data transfer stopped {#device-transfer-stopped} + +If data transfer was working before but stopped suddenly, please check the +[status page](https://status.helium.com/) and see if there is any ongoing incident with Helium +Packet Router. + +If there was no incident, please check if your OUI was locked due to insufficient DC balance. Lock +status can be verified by checking whether the "locked" field for each of your route is `true` or +`false`. Query your routes by running + +```bash +$ helium-config-service-cli route list --commit +``` + +OUI DC balance can be checked with the +[DC balance widget](/iot/run-an-lns/fund-an-oui#tracking-oui-balance). + +## LNS receives neither join requests nor uplinks + +Please first follow the same advice on investigating +[why your device transfer might be unsuccessful](/iot/run-an-lns/common-issues#device-transfer-stopped). + +If those scenarios were ruled out, it's helpful to double-check route and device configuration. A +common mistake is that routes are not properly configured or the devEUI of the testing device is not +added to the route. + +Review the [routing configuration](configure-routing-rules) guides. + +## LNS receives Join Requests but device unable to join + +Device may have issue joining the Network if the RSSI/SNR values are sub-optimal. In practice, +difficulty to join tends to show up when the RSSI value is worse than -120. + +As outlined in the [Understanding Max Copies](/iot/run-an-lns/advanced-configuration#max-copies) +section, join performance can be improved with max copies setting. + +If RSSI/SNR values continue to be low even after the max copies setting, it may be necessary to +deploy additional coverage. Review the [data-only Hotspot](/iot/data-only-hotspots) guides for steps +on adding Helium functionality to any existing LoRaWAN gateway. + +## Device able to join but not uplink + +If the join process is successful but no further data is delivered, a common issue is that the +Session Key Filter is enabled for the route, but the session key of the specific device has not been +submitted. This effectively blocks all downlink activity for the omitted device. + +Check if your route has enabled +[Session Key Filter](/iot/run-an-lns/advanced-configuration#session-key-filter). If so, check if the +device's Network Session Key is registered in that route by running + +```bash +helium-config-service-cli route skfs list --route-id +``` + +You can find your device's Network Session Key in Chirpstack in the device's Activation tab. + +## Cannot perform routing changes + +If you cannot perform routing changes such as updating EUI list, SKF list, max copy setting OR if +all of your old devices are sending data but not your newly provisioned devices. Please check the +[status page](https://status.helium.com/) and see if there is any ongoing incident with +Configuration Service. + +## Community Support + +Helium developers and community members are active on Twitter, Discord, and GitHub. + +- [Discord disk91 Server #helium-discussion](https://discord.gg/j5ENunf7) +- [Helium GitHub](https://github.com/helium) + +As a closing note, these docs are open for contributions. If there are areas to improve the content +here, please consider opening a [pull request](https://github.com/helium/docs/). diff --git a/docs/network-iot/run-an-lns/configure-chirpstack.mdx b/docs/network-iot/run-an-lns/configure-chirpstack.mdx new file mode 100644 index 000000000..fa7a40cc8 --- /dev/null +++ b/docs/network-iot/run-an-lns/configure-chirpstack.mdx @@ -0,0 +1,34 @@ +--- +id: configure-chirpstack +title: Configure ChirpStack +pagination_label: Configure ChirpStack +sidebar_label: Configure ChirpStack +description: Configure ChirpStack +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/configure-chirpstack +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +[ChirpStack](https://www.chirpstack.io/) is an open-source, multi-tenant LoRaWAN Network Server +(LNS) that provides a web console and gRPC API for managing devices, routing messages, and +interacting with major cloud providers. + +## Getting Started + +Before beginning, make sure to have the following: + +- Helium Config Service CLI with delegate keypair +- Helium Network Organizationally Unique Identifier (OUI) +- Helium LoRaWAN devAddr slab +- Data Credits (>3.5M DC) + +## Docker Compose and Kubernetes + +Detailed discussion is provided for running ChirpStack on both Docker Compose and Kubernetes. While +both can be used in a variety of settings, the configurations provided in the documentation here +describe using Docker Compose to run ChirpStack in a non-production setting and using Kubernetes to +run ChirpStack in a production setting. + +- [Run ChirpStack on Docker Compose](/iot/run-an-lns/docker-compose) +- [Run ChirpStack on Kubernetes](/iot/run-an-lns/kubernetes) \ No newline at end of file diff --git a/docs/network-iot/run-an-lns/configure-routing-rules.mdx b/docs/network-iot/run-an-lns/configure-routing-rules.mdx new file mode 100644 index 000000000..7fe69570d --- /dev/null +++ b/docs/network-iot/run-an-lns/configure-routing-rules.mdx @@ -0,0 +1,311 @@ +--- +id: configure-routing-rules +title: Configure Routing Rules +pagination_label: Configure Routing Rules +sidebar_label: Configure Routing Rules +description: Configure Routing Rules +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/configure-routing-rules +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +With ChirpStack up and running, OUI-specific routing and sensor configurations can be added to the +Helium Config Service to enable sensor data to be routed to the ChirpStack instance. + +:::info + +If ChirpStack was deployed with the Docker Compose configuration, routing rules will need to be +manually configured. + +However, if ChirpStack was deployed with the Kubernetes configuration, routing rules are +programmatically added via the Helium Network sidecar application and do not need to be manually +configured in the manner described below. + +::: + +## Initialize Helium Config Service CLI + +First, initialize the Helium Config Service CLI by running `helium-config-service-cli env init`. A +series of prompts, as noted below, will be provided in the terminal session. + +1. For `Config Service Host`, press enter to use the default value (e.g., + `https://config.iot.mainnet.helium.io:6080`). +2. For `Keypair Location`, provide the location of the delegate keypair in the local filesystem. +3. For `Net ID`, provide `00003C`. +4. For `Assigned OUI`, provide your assigned OUI number. +5. For `Default Max Copies`, press enter to use the default value (e.g., `15`). + +After providing the initialization information, an output similar to the below will be provided: + +```sh +Put these in your environment +------------------------------------ +HELIUM_KEYPAIR_BIN=<./your/path/to/delegate/keypair.bin> +HELIUM_NET_ID=00003C +HELIUM_OUI= +HELIUM_MAX_COPIES=15 +``` + +Second, as suggested in the output, export the suggested environment variables into the terminal +session. This needs to be done manually. To do so, just add `export` to each line in the manner +provided below and run the commands: + +```sh title="Setting environment variables in a terminal window." +export HELIUM_KEYPAIR_BIN=<./your/path/to/delegate/keypair.bin> +export HELIUM_NET_ID=00003C +export HELIUM_OUI= +export HELIUM_MAX_COPIES=15 +``` + +## Generate Route in Helium Config Service + +Routes contain the necessary information for the Helium Packet Router to know how to route a packet +sent from a sensor to the proper LNS. In particular, Helium Packet Router leverages information +provided in a generated route such as DevEUI+AppEUI (for routing join requests), DevAddr range (for +routing uplinks), and LNS endpoint to inform routing decisions. + +To generate a route via the Helium Config Service CLI, run the `helium-config-service-cli route new` +command. As shown below, the command will perform a "dry run" if the `--commit` flag isn't provided. +In such cases when the `--commit` flag isn't provided, the command will show what would have been +transmitted to the Helium Config Service (e.g., a configuration service which informs routing +behavior of the Helium Packet Router). In this way, you can review the route information prior to +formally submitting. + +```sh +helium-config-service-cli route new +``` + +```sh +== DRY RUN == (pass `--commit`) +{ + "id": "", + "net_id": "00003C", + "oui": , + "server": { + "host": "", + "port": 0, + "protocol": { + "type": "packet_router" + } + }, + "max_copies": 15, + "active": true, + "locked": false, + "ignore_empty_skf": false +} +``` + +Once the result looks satisfactory, simply run `helium-config-service-cli route new --commit` to +submit the route to Helium Config Service. + +## Configure Route in Helium Config Service + +After generating a route, the route needs to be configured for the ChirpStack implementation. This +will involve specifying the ChirpStack endpoint and default port and adding LoRaWAN region-specific +routing configuration. + +### Specify ChirpStack Endpoint and Default Port + +To specify the ChirpStack endpoint and default port, use the Helium Config Service CLI and run the +`helium-config-service-cli route update server` command. As shown below, the command will perform a +"dry run" if the `--commit` flag isn't provided. + +In preparing the command, please note that the `--host` flag should point to the IP address of the +server running the ChirpStack instance, the `--port` flag serves as the default for routing messages +to ChirpStack, and the `--route-id` flag corresponds to the route that was just created. + +```sh +helium-config-service-cli route update server --host --port --route-id +``` + +```sh +== DRY RUN == (pass `--commit`) +Updated +== Old +{ + "id": , + "net_id": "00003C", + "oui": , + "server": { + "host": "", + "port": 0, + "protocol": { + "type": "packet_router" + } + }, + "max_copies": 15, + "active": true, + "locked": false, + "ignore_empty_skf": false +} +== New +{ + "id": , + "net_id": "00003C", + "oui": , + "server": { + "host": , + "port": , + "protocol": { + "type": "packet_router" + } + }, + "max_copies": 15, + "active": true, + "locked": false, + "ignore_empty_skf": false +} +``` + +Once the result looks as desired, simply re-run the command with the ` --commit` to update the +route. + +### Add LoRaWAN Region-Specific Routing Configuration + +To add LoRaWAN region-specific routing configuration, use the Helium Config Service CLI and run the +`helium-config-service-cli route update add-gwmp-region` command. As shown below, the command will +perform a "dry run" if the `--commit` flag isn't provided. + +In preparing the command, the LoRaWAN region is proceeded by the port to be used for the region. For +example, in the example command below, the region `us915` is proceeded by ``. Here, the +`` value will mirror the port bound to the `chirpstack-gateway-bridge-us915` container +(e.g., `1701`). + +Please note that the command will also need to be run for the `eu868` region for port `1700`. + +```sh +helium-config-service-cli route update add-gwmp-region --route-id us915 +``` + +```sh +== DRY RUN == (pass `--commit`) +Updated +== Old +{ + "id": , + "net_id": "00003C", + "oui": , + "server": { + "host": "", + "port": 0, + "protocol": { + "type": "packet_router" + } + }, + "max_copies": 15, + "active": true, + "locked": false, + "ignore_empty_skf": false +} +== New +{ + "id": , + "net_id": "00003C", + "oui": , + "server": { + "host": "", + "port": 0, + "protocol": { + "type": "gwmp", + "mapping": { + "US915": 1701 + } + } + }, + "max_copies": 15, + "active": true, + "locked": false, + "ignore_empty_skf": false +} +``` + +After adding the LoRaWAN region-specific routing configuration for `US915` and `EU868`, the +configuration should look similar to the below: + +```sh +{ + "id": , + "net_id": "00003C", + "oui": , + "server": { + "host": "", + "port": 0, + "protocol": { + "type": "gwmp", + "mapping": { + "US915": 1701, + "EU868": 1700 + } + } + }, + "max_copies": 15, + "active": true, + "locked": false, + "ignore_empty_skf": false +} +``` + +## Add Device to ChirpStack + +To add a device in Chirpstack, please follow the documentation in either of the guides below and +return here when complete. + +- [Add Device to ChirpStack via Console](/iot/run-an-lns/chirpstack-add-device) +- [Add Device to ChirpStack via gRPC](/iot/run-an-lns/chirpstack-add-device-grpc) + +## Configure Device in Helium Config Service + +Now that the device is successfully created on ChirpStack, Helium Config Service needs to be +configured to know about the device. In doing so, the Helium Config Service CLI will be used to +associate the device EUIs and devAddrs with the route. + +### Add Device EUIs to Route + +To add device EUIs to the route, run the `helium-config-service-cli route euis add` command. As +shown below, the command will perform a "dry run" if the `--commit` flag isn't provided. + +In preparing the command, the `--route-id` flag corresponds to the id of the route created above, +the `--dev-eui` flag corresponds to the device EUI generated entered in ChirpStack, and the +`--app-eui` flag corresponds to the join EUI also entered in ChirpStack. + +Please refer to the red-boxed portion of image below to find the device and join EUIs in ChirpStack. + +
+ +
DevEUI and AppEUI displayed in ChirpStack
+
+
+ +```bash +helium-config-service-cli route euis add --route-id --dev-eui --app-eui +``` + +Once the result looks as desired, simply re-run the command with the ` --commit` to add the device +to the route. + +### Add DevAddr to Route + +To add DevAddrs to the route, run the `helium-config-service-cli route devaddrs add` command. As +shown below, the command will perform a "dry run" if the `--commit` flag isn't provided. + +Here, the `--start-addr` and `--end-addr` values correspond to the results from the +`helium-config-service-cli org get --oui ` command described in detail in +[Gather Helium DevAddr Subnet Information for OUI](/iot/run-an-lns/docker-compose/#gather-helium-devaddr-subnet-information-for-oui) + +```bash +helium-config-service-cli route devaddrs add --start-addr --end-addr --route-id +``` + +Again, once the result looks as desired, simply re-run the command with the ` --commit` to add the +DevAddr to the route. + +## Next Steps + +You now have a fully functioning LNS on the Helium IoT network. For additional advanced +configurations, including automating the device addition process, please see +[Advanced Configuration](advanced-configuration). diff --git a/docs/network-iot/run-an-lns/docker-compose.mdx b/docs/network-iot/run-an-lns/docker-compose.mdx new file mode 100644 index 000000000..2730b84f4 --- /dev/null +++ b/docs/network-iot/run-an-lns/docker-compose.mdx @@ -0,0 +1,373 @@ +--- +id: docker-compose +title: ChirpStack on Docker Compose +pagination_label: ChirpStack on Docker Compose +sidebar_label: On Docker Compose +description: ChirpStack on Docker Compose +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/docker-compose +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +This guide describes using Docker Compose to run ChirpStack in a non-production setting on AWS EC2. + +## Infrastructure Requirements + +The infrastructure requirements noted below are sufficient for getting a ChirpStack instance up and +running for experimentation purposes, but are not suggested for use in a mission critical, +production setting. + +- 4 vCPU +- 8GB RAM +- 100GB SSD hard drive +- CPU with x86 architecture +- Ubuntu 22.04 + +## Server Configuration + +While there are several methods for installing ChirpStack, this guide will demonstrate a +configuration using Docker and the +[chirpstack-docker](https://github.com/chirpstack/chirpstack-docker) repository. + +Accordingly, on the server intended to run the ChirpStack instance, +[install Docker](https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository) using +the `apt` repository on Ubuntu. + +```sh title="Install Docker using the apt repository" +# Add Docker's official GPG key: +sudo apt-get update +sudo apt-get install ca-certificates curl +sudo install -m 0755 -d /etc/apt/keyrings +sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc +sudo chmod a+r /etc/apt/keyrings/docker.asc + +# Add the repository to Apt sources: +echo \ + "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ + $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ + sudo tee /etc/apt/sources.list.d/docker.list > /dev/null +sudo apt-get update + +# Install the latest version: +sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin + +# Verify that the Docker Engine installation is successful by running the hello-world image: +sudo docker run hello-world +``` + +Next, clone the `chirpstack-docker` repository. + +```sh title="Clone the chirpstack-docker repository." +git clone https://github.com/chirpstack/chirpstack-docker.git +``` + +## ChirpStack Port Accessibility + +For the configuration described in this guide, the following ports need to be accessible on the +server running the ChirpStack instance. In an AWS parlance, a Security Group needs to be attached to +the underlying EC2 instance running ChirpStack with inbound rules for the noted ports. + +1. TCP `8080` + +- The ChirpStack web UI and gRPC API are accessible over `http://:8080` + +2. UDP `1700` + +- As described in further detail below, the `chirpstack-gateway-bridge` container for the EU868 + region binds to UDP `1700`. As such, for EU868-based sensor traffic to reach ChirpStack, UDP + `1700` needs to be open. + +3. UDP `1701` + +- Similarly, the `chirpstack-gateway-bridge` container for the US915 region binds to UDP `1701`. As + such, for US915-based sensor traffic to reach ChirpStack, UDP `1701` needs to be open. + +Please note that if more `chirpstack-gateway-bridge` containers are added for additional LoRaWAN +regions, the corresponding UDP ports will need to be added in a similar manner to UDP `1700` and +`1701`. + +## ChirpStack Configuration + +The ChirpStack settings need to be configured so that ChirpStack can operate on the Helium Network. +In particular, the `chirpstack.toml` and `docker-compose.yml` files, respectively located in the +`./chirpstack-docker/configuration/chirpstack/` and `./chirpstack-docker/` directories, need to be +updated. Prior to doing so, however, Helium-specific information for the OUI needs to be gathered to +be applied in the ChirpStack configuration. + +### Gather Helium DevAddr Subnet Information for OUI + +Use the Helium Config Service CLI to determine the subnet masks for the `DevAddr` associated with +the LNS. In ChirpStack, the subnet masks will be referred to as `dev_addr_prefixes`. + +To do so, first retrieve the `DevAddr` constraints for the OUI. The relevant values are each of the +`start_addr` and `end_addr` groups provided in the `devaddr_constraints` array. + +```sh" +helium-config-service-cli org get --oui +``` + +```json title="Example result from helium-config-service-cli org get --oui command" +{ + "org": { + "oui": , + "owner": , + "payer": , + "delegate_keys": [ + + ], + "locked": + }, + "net_id": , + "devaddr_constraints": [ + { + "start_addr": , // First DevAddr constraint + "end_addr": // Second DevAddr constraint + } + ] +} +``` + +Next, using the `start_addr` and `end_addr` values, identify the `DevAddr` subnet masks, (e.g., +labeled as `subnets` in the returned JSON). If there are multiple, non-contiguous +`devaddr_constraints`, this will need to be done for each set of constraints. + +```sh" +helium-config-service-cli subnet-mask +``` + +```json title="Example result from helium-config-service-cli subnet-mask command" +{ + "range": { + "start_addr": , + "end_addr": + }, + "subnets": [ + // Desired value corresponding to the ChirpStack dev_addr_prefixes + ] +} +``` + +### Update chirpstack.toml + +Access `./chirpstack-docker/configuration/chirpstack/chirpstack.toml`. + +Modify the following sections of `chirpstack.toml`. All other sections can be left as is. + +- Under `[network]`: + - Set `net_id` to the Helium Net ID, `00003C`, e.g., `net_id="00003C"`. + - Add `dev_addr_prefixes` with the value `[]`, e.g., + `dev_addr_prefixes=[]`. + - As an illustrative example, if the `helium-config-service-cli subnet-mask` command indicated a + subnet mask of `00000000/29`, then add `dev_addr_prefixes=["00000000/29"]`. + - If the OUI has multiple non-sequential `DevAddr` ranges, separate the corresponding subnet + masks by comma. For instance, `dev_addr_prefixes=["00000000/29", "00000010/29"]`. + - Update the `enabled_regions` array to include the desired regions. + - Multiple regions can be enabled simultaneously. + - Each added region must match the `id` parameter of the `[[regions]]` configuration in the + corresponding `./chirpstack-docker/configuration/chirpstack/.toml` file. In other + words, if the `id` parameter of the `[[regions]]` configuration is `us915_0`, add `us915_0` to + the `enabled_regions` array. +- Under `[api]`: + - Update the `secret` value used for generating login and API tokens. + - Make sure this value is never exposed. +- Create a new, top level `[gateway]` section: + - Below, add `allow_unknown_gateways=true` + +An example of the above-mentioned modified sections of `chirpstack.toml` is provided below. Please +note that the these values are exemplary and need to be filled in with the correct information for +your ChirpStack configuration. Again, all other sections in `chirpstack.toml` can be left as is. + +```toml +# Network related configuration. +[network] + + # Network identifier (NetID, 3 bytes) encoded as HEX (e.g. 010203). + # Helium net_id="00003C" + net_id="00003C" + + # Helium 8 block dev address prefix 29 + # If you have multiple blocks you can add them as an array + dev_addr_prefixes=[ + "78000000/29" + ] + + # Enabled regions. + # + # Multiple regions can be enabled simultaneously. Each region must match + # the 'id' parameter of the region configuration in '[[regions]]'. + enabled_regions=[ + "eu868", + "us915_1", + ] + +# API interface configuration. +[api] + + # Secret. + # + # This secret is used for generating login and API tokens, make sure this + # is never exposed. Changing this secret will invalidate all login and API + # tokens. The following command can be used to generate a random secret: + # openssl rand -base64 32 + secret="REPLACE-WITH-YOUR-SECRET-HERE" + +# Global gateway configuration. +# Please note that backend configuration can be found in the per-region +# configuration in ./chirpstack-docker/configuration/chirpstack/.toml +[gateway] + # Allow unknown gateways. + # + # If set to true, then uplinks received from gateways not configured in + # ChirpStack will be allowed. + allow_unknown_gateways=true +``` + +### Update docker-compose.yaml + +First, remove the entire service definitions for `chirpstack-gateway-bridge-basicstation` and +`chirpstack-rest-api` as they are not needed. + +Second, visit the [ChirpStack Docker Hub Image Repository](https://hub.docker.com/u/chirpstack) and +identify the most recent version tags for +[chirpstack](https://hub.docker.com/r/chirpstack/chirpstack/tags) and +[chirpstack-gateway-bridge](https://hub.docker.com/r/chirpstack/chirpstack-gateway-bridge/tags). At +the time of writing this manual, the current version of `chirpstack` is `4.7` and +`chirpstack-gateway-bridge` was `4.0` so these version will be used moving forward. + +Third, update `image` definitions for `chirpstack` and `chirpstack-gateway-bridge` with the most +recent version tags found in Docker Hub as noted below: + +- `image: chirpstack/chirpstack:4.7` +- `image: chirpstack/chirpstack-gateway-bridge:4.0` + +Fourth, to support every region beyond the default EU868 defined in the `enabled_regions` noted +above in the `settings.toml` file, add `chirpstack-gateway-bridge` service definitions for each +additional LoRaWAN region. Although this tutorial demonstrates adding support for US915 and EU868 +these steps can be adapted for other regions. + +To do so, amend the `chirpstack-gateway-bridge` label to be `chirpstack-gateway-bridge-eu868` then +create a new service definition for `chirpstack-gateway-bridge-us915` as provided below: + +```yml +chirpstack-gateway-bridge-us915: + image: chirpstack/chirpstack-gateway-bridge:4.0 + restart: unless-stopped + ports: + - 1701:1700/udp # The chirpstack-gateway-bridge-us915 container will bind to host port 1701 + volumes: + - ./configuration/chirpstack-gateway-bridge:/etc/chirpstack-gateway-bridge + environment: + - INTEGRATION__MQTT__EVENT_TOPIC_TEMPLATE=us915_1/gateway/{{ .GatewayID }}/event/{{ .EventType + }} + - INTEGRATION__MQTT__STATE_TOPIC_TEMPLATE=us915_1/gateway/{{ .GatewayID }}/state/{{ .StateType + }} + - INTEGRATION__MQTT__COMMAND_TOPIC_TEMPLATE=us915_1/gateway/{{ .GatewayID }}/command/# + depends_on: + - mosquitto +``` + +See the +[ChirpStack Gateway Bridge documentation](https://www.chirpstack.io/docs/chirpstack-gateway-bridge/configuration.html) +for full description on the configuration possibilities for the `chirpstack-gateway-bridge` service. + +An example of a complete `docker-compose.yaml` file is provided below: + +```yml +version: '3' + +services: + chirpstack: + image: chirpstack/chirpstack:4.7 + command: -c /etc/chirpstack + restart: unless-stopped + volumes: + - ./configuration/chirpstack:/etc/chirpstack + - ./lorawan-devices:/opt/lorawan-devices + depends_on: + - postgres + - mosquitto + - redis + environment: + - MQTT_BROKER_HOST=mosquitto + - REDIS_HOST=redis + - POSTGRESQL_HOST=postgres + ports: + - 8080:8080 + + chirpstack-gateway-bridge-eu868: + image: chirpstack/chirpstack-gateway-bridge:4.0 + restart: unless-stopped + ports: + - 1700:1700/udp + volumes: + - ./configuration/chirpstack-gateway-bridge:/etc/chirpstack-gateway-bridge + environment: + - INTEGRATION__MQTT__EVENT_TOPIC_TEMPLATE=eu868/gateway/{{ .GatewayID }}/event/{{ .EventType + }} + - INTEGRATION__MQTT__STATE_TOPIC_TEMPLATE=eu868/gateway/{{ .GatewayID }}/state/{{ .StateType + }} + - INTEGRATION__MQTT__COMMAND_TOPIC_TEMPLATE=eu868/gateway/{{ .GatewayID }}/command/# + depends_on: + - mosquitto + + chirpstack-gateway-bridge-us915: + image: chirpstack/chirpstack-gateway-bridge:4.0 + restart: unless-stopped + ports: + - 1701:1700/udp + volumes: + - ./configuration/chirpstack-gateway-bridge:/etc/chirpstack-gateway-bridge + environment: + - INTEGRATION__MQTT__EVENT_TOPIC_TEMPLATE=us915_1/gateway/{{ .GatewayID }}/event/{{ .EventType + }} + - INTEGRATION__MQTT__STATE_TOPIC_TEMPLATE=us915_1/gateway/{{ .GatewayID }}/state/{{ .StateType + }} + - INTEGRATION__MQTT__COMMAND_TOPIC_TEMPLATE=us915_1/gateway/{{ .GatewayID }}/command/# + depends_on: + - mosquitto + + redis: + image: redis:7-alpine + restart: unless-stopped + command: redis-server --save 300 1 --save 60 100 --appendonly no + volumes: + - /mnt/particle_chirpstack/redis/data:/data + + mosquitto: + image: eclipse-mosquitto:2 + restart: unless-stopped + ports: + - 1883:1883 + volumes: + - ./configuration/mosquitto/config/:/mosquitto/config/ + + postgres: + image: postgres:14-alpine + restart: unless-stopped + + volumes: + - ./configuration/postgresql/initdb:/docker-entrypoint-initdb.d + - /mnt/particle_chirpstack/postgresql/data:/var/lib/postgresql/data + environment: + - POSTGRES_PASSWORD=root +``` + +## Run ChirpStack + +From the root of the `chirpstack-docker` directory, run `docker compose up --detach` to start the +containers defining the ChirpStack instance in the background. Container logs can be accessed by +running `docker compose logs --follow` and the ChirpStack instance can be taken down by running +`docker compose down` + +The ChirpStack web console will now be accessible at `http://:8080`. Utilize the +default credentials to log in: + +Username: admin +Password: admin + +## Next Steps + +Now that the LNS is operational, proceed to establish routing rules. This ensures that the Helium +Network accurately directs device packets to the designated LNS. Learn how to implement this in the +[Configure Routing Rules](configure-routing-rules) guide. diff --git a/docs/network-iot/run-an-lns/fund-an-oui-using-hnt.mdx b/docs/network-iot/run-an-lns/fund-an-oui-using-hnt.mdx new file mode 100644 index 000000000..9ea7b424f --- /dev/null +++ b/docs/network-iot/run-an-lns/fund-an-oui-using-hnt.mdx @@ -0,0 +1,84 @@ +--- +id: fund-an-oui-using-hnt +title: Fund An OUI Using HNT +pagination_label: Fund An OUI Using HNT +sidebar_label: Buy Data Credits using HNT +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/fund-an-oui-using-hnt +--- + +import { YouTube } from 'mdx-embed' + +Whether facilitated through a third party or acquired directly through the network, all data +transfer on Helium requires [Data Credits](/tokens/data-credit). This guide will illustrate two +methods of directly converting HNT into DC and subsequently delegating it for use by an OUI. + +## Funding an OUI Using The CLI Wallet + +The [Helium CLI Wallet](/wallets/cli-wallet) provides several tools to manage DC balances. + +The `price` command is a helpful tool for determining the amount of HNT required for a particular +amount of DC. For example, this command will output the amount of HNT required to fund 1M DC ($10). + +```sh +helium-wallet dc price 10 +``` + +### Swap HNT to DC + +With HNT and Sol (for transaction fees) in an account, use the `mint` command to convert HNT into +DC. The `--dc` flag is a helpful way to mint a specific amount of DC. Mint these DC to an account +where further transactions can be issued on them — often the same account where they are being +minted from. + +```sh +helium-wallet dc mint --dc 1000000 --commit +``` + +### Delegate DC To The OUI + +After the DC is minted, it can be delegated to the OUI. The delegation is issued to the payer key of +the OUI. + +```sh +helium-wallet dc delegate iot 1000000 --commit +``` + +## Funding an OUI Using The Helium Wallet App + +### Swap HNT to DC + +1. Select a Wallet in the Helium Wallet app. +1. Tap the `Swap` icon in the middle of the screen. +1. Select `HNT` in the top drop-down and enter an amount of HNT to swap. +1. Select `DC` in the lower drop-down, and it will be filled with the resulting DC amount. +1. Tap the `Swap Tokens` button and confirm the swap transaction. +1. HNT is burned for DC within the same Wallet. + +The new DC balance amount can be verified in the app tokens list on the `$` tab within the Helium +Wallet app. + +At this point, DC has been successfully acquired into the wallet, represented by the OUI's payer +key. However, the Packet Verifier Service does not have the authority to burn DC from the wallet +directly. To enable this, it is necessary to delegate DC into the OUI's escrow account, where the +Packet Verifier Service is authorized to burn DC. + +### Delegate DC To The OUI + +1. Select a Wallet in the Helium Wallet app. +1. Tap the `$` icon on the bottom tab bar. +1. Tap the DC balance. +1. Tap `Delegate`. +1. Select the IOT Network. +1. Enter the payer key of the OUI as the address. +1. Enter the amount of DC to delegate. +1. Swipe to Delegate. + +The OUI is now funded, the history of DC delegation is visible under the "All Activity" section +towards the bottom of the DC page. It's now time to configure and deploy the LNS following the +[Chirpstack Configuration](configure-chirpstack) guides. + +### Helium Wallet App Video Walkthrough + + diff --git a/docs/network-iot/run-an-lns/fund-an-oui.mdx b/docs/network-iot/run-an-lns/fund-an-oui.mdx new file mode 100644 index 000000000..ea62dabbd --- /dev/null +++ b/docs/network-iot/run-an-lns/fund-an-oui.mdx @@ -0,0 +1,92 @@ +--- +id: fund-an-oui +title: Fund An Organizationally Unique Identifier +pagination_label: Fund An Organizationally Unique Identifier +sidebar_label: Fund an Organizationally Unique Identifier +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/fund-an-oui +--- + +[Data Credits](/tokens/data-credit) are used to pay for all transmission of data from devices on the +Helium Network. + +It is worth noting that HNT to DC conversion is irreversible. Data Credits cannot be refunded, +exchanged for other tokens, or transferred between wallets. + +Several options are available for funding an OUI with Data Credits: + +- [Fund an OUI using HNT](/iot/run-an-lns/fund-an-oui-using-hnt) +- [Fund an OUI using a credit card with the Sphere Data Credit Portal](/tokens/data-credit-portal) + +## Estimating Usage + +
+ +
+ Up-to-date usage metrics for all IoT OUIs on the Helium network.
To get a sense of + traffic and DC usage on the network, check out the full{' '} + Dune Data Credit Dashboard. +
+
+ +
+ +Data credits are charged per 1DC per 24-byte increment for each response of an uplink payload. DC +cost is based on the application payload size only. LoRaWAN protocol overhead (headers, MIC, etc.) +does not count toward the DC cost. For a helpful visualization of DC usage of devices for a given +period, check out the [Data Credit calculator](/tokens/data-credit#data-transfer-calculator) on the +DC documentation. + +Only uplinks are charged on Helium. Downlinks and join requests are not billed. + +## Tracking OUI Balance + +import { EscrowOUIWidget } from '@theme/EscrowOUIWidget' + +The balance of an OUI is held in an escrow account that is generated based on the OUI's payer key. +This escrow account is what allows the Helium Network to appropriately deduct DC as network transfer +occurs. The widget below can be used to look up the escrow account and balance for payer or router +keys associated to any valid OUI. + +
+ +
+ +
+ +The escrow account is the main source for understanding the remaining balance of an OUI. Details on +the funding and burn of data credits on an escrow account can be inspected using any Solana +blockchain explorer. + +When monitoring the OUI balance, it is worth noting that the minimum usage deducted at a time is +10,000 DC[^1]. + +[^1]: + `BURN_THRESHOLD` on + [GitHub](https://github.com/helium/oracles/blob/7c9f5b4e6f8e47be80eaf3c6cb4cc703373246ef/iot_packet_verifier/src/pending_burns.rs#L32) + +### Sphere DC Balance API + +Sphere provides a public API endpoint for querying the DC balance of an OUI's escrow account. + +``` +https://api.spherepay.co/v1/solanaDepinSession/dcAmount/ +``` + +## Minimum Balance + +The Helium Packet Router enforces a minimum balance of 3,500,000 Data Credits (\$35). This minimum +balance is required to ensure that all Hotspots are compensated for their work on the network in the +case that the LNS transfers data more quickly than can be deducted from the OUI's balance. Token +balances cannot become negative, so this \$35 buffer keeps network payments balanced. + +If the DC balance of an OUI falls below the minimum balance, the OUI will be unable to receive data +until the balance is increased. The Packet Verifier checks the DC balance of every locked OUI every +30 minutes, and unlocks them if their DC balance is above 3.5MM DC. diff --git a/docs/network-iot/run-an-lns/kubernetes.mdx b/docs/network-iot/run-an-lns/kubernetes.mdx new file mode 100644 index 000000000..3b9e8431e --- /dev/null +++ b/docs/network-iot/run-an-lns/kubernetes.mdx @@ -0,0 +1,37 @@ +--- +id: kubernetes +title: ChirpStack on Kubernetes +pagination_label: ChirpStack on Kubernetes +sidebar_label: On Kubernetes +description: ChirpStack on Kubernetes +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/kubernetes +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +This guide describes using Kubernetes to run ChirpStack in a production setting on AWS EKS with +usage of AWS RDS Postgres and ElastiCache Redis. + +## GitHub Repository + +The [chirpstack-infrastructure](https://github.com/dewi-alliance/chirpstack-infrastructure) GitHub +repository provides Terraform modules and Helm charts for a highly available Chirpstack V4 +deployment configured with Helium Network sidecar applications on AWS EKS. + +## AWS Architecture Diagram + +The AWS architecture diagram provided below shows ChirpStack, as deployed from the GitHub +repository, in a high-availability configuration with redundancies for AWS availability zones, NAT +gateway, RDS Postgres, and ElastiCache Redis. The repository also provides an example for a +cost-optimized configuration without NAT gateway, RDS Postgres, and ElastiCache Redis redundancies. + +
+ AWS architecture diagram of ChirpStack on EKS +
AWS architecture diagram of ChirpStack on EKS.
+
diff --git a/docs/network-iot/run-an-lns/run-an-lns.mdx b/docs/network-iot/run-an-lns/run-an-lns.mdx new file mode 100644 index 000000000..33138a517 --- /dev/null +++ b/docs/network-iot/run-an-lns/run-an-lns.mdx @@ -0,0 +1,34 @@ +--- +id: run-an-lns +title: Run a LoRaWAN Network Server +pagination_label: Run Your Own LNS +sidebar_label: Run Your Own LNS +description: Helium OpenLNS Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + +
+
+ +OpenLNS is the platform that enables any compatible LoRaWAN Network Server (LNS) to use Helium's IoT +Network. In this guide, we'll walk you through the process of setting up and configuring OpenLNS +with the popular open-source LNS, [ChirpStack](https://www.chirpstack.io/). + +## What to Expect + +There are four major steps to run your own LNS: + +1. [Purchase a Helium Organizationally Unique Identifier (OUI)](/iot/run-an-lns/buy-an-oui) +2. [Fund a Helium Organizationally Unique Identifier (OUI)](/iot/run-an-lns/fund-an-oui) +3. [Configure and deploy a LoRaWAN Network Server (LNS)](/iot/run-an-lns/configure-chirpstack) +4. [Configure Routing Rules with Config Service](/iot/run-an-lns/configure-routing-rules) + +## Advanced Configuration + +There are additional configurations, automations, and data you can access with OpenLNS. You can +learn more about these in the [Advanced Configuration](/iot/run-an-lns/advanced-configuration) +section. diff --git a/docs/network-mobile/5g-on-helium.mdx b/docs/network-mobile/5g-on-helium.mdx new file mode 100644 index 000000000..d03e0f111 --- /dev/null +++ b/docs/network-mobile/5g-on-helium.mdx @@ -0,0 +1,58 @@ +--- +id: 5g-on-helium +title: The Mobile Network +pagination_label: The Mobile Network +sidebar_label: Introduction +description: The Mobile Network +image: https://docs.helium.com/img/link-image.png +slug: /mobile/5g-on-helium +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + + +## Introduction + +The Helium Mobile Network is a decentralized +[carrier offload](https://blog.hellohelium.com/champions/) network. The Helium Mobile Hotspots and +Converted Wi-Fi Networks, while owned and deployed by the community, connect to a common core which +gives subscribers from various mobile carriers automatic access to the network. In return for the +work done by the radio deployer enabling this wireless coverage (securing real estate, providing +power, providing internet) the deployer is rewarded with HNT. + +## Hotspots + +Helium Mobile Hotspots allow anyone to create Helium Network coverage. Helium Mobile Hotspots are +low cost, easy to deploy, Wi-Fi radios. These are best deployed in commercial locations where slow +moving people gather; think coffee shops, restaurants, shopping malls, public transit stations, etc. +In this way subscribers, business owners, and entrepreneurs can improve the mobile wireless user +experience rapidly where it's needed. + +:::tip Purchase a Wi-Fi Hotspot + +Visit [helium.com](https://helium.com) for more information on purchasing a Mobile Wi-Fi Hotspot to +build coverage in your area! + +::: + +[Converted Wi-Fi Networks](/mobile/helium-plus-mobile) are created when an existing +[Passpoint](https://www.wi-fi.org/discover-wi-fi/passpoint) enabled Wi-Fi network is configured to +join the Helium Mobile Network. Through the Helium Plus program or +[self-serve guides](/mobile/helium-plus-mobile), owners of existing Wi-Fi networks can monetize +their asset by enabling carrier offload via the Helium Network. In return for servicing subscriber's +wireless data, the network owners gets rewarded with HNT tokens. Wi-Fi radios onboarded through +Helium Plus program do not earn Proof of Coverage (PoC) rewards. + +:::tip Add Helium+ To Your Wi-Fi Fleet + +Visit [Helium Plus](https://www.helium.com/plus) for more information on how to add Helium Plus to +your passpoint capable Wi-Fi network. + +::: + +## Rewards + +Hotspots can earn rewards for both Proof of Coverage and data transfer. PoC rewards are dependent on +the readiness and quality of service provided by a radio. Data transfer rewards are awarded based on +the amount of eligible data passed through a Hotspot. diff --git a/docs/network-mobile/cbrs/5g-on-helium.mdx b/docs/network-mobile/cbrs/5g-on-helium.mdx deleted file mode 100644 index 878808edc..000000000 --- a/docs/network-mobile/cbrs/5g-on-helium.mdx +++ /dev/null @@ -1,167 +0,0 @@ ---- -id: 5g-on-helium -title: 5G On Helium -pagination_label: 5G On Helium -sidebar_label: Introduction -description: 5G On Helium -image: https://docs.helium.com/img/link-image.png -slug: /5g-on-helium ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -Historically many mobile networks are built top-down by service providers (e.g., AT&T and Verizon in -the United States). However, future networks will likely be a hybrid of large-scale operators and -people-owned 5G Hotspots due to consumer behavior demands (higher bandwidth and lower latency -requirements) and the physics of wireless radio, requiring denser networks with more nodes, further -increasing site acquisition costs. - -The Helium model decentralizes these costs and enables communities to participate in building -reliable, high-bandwidth networks using technologies like [CBRS](/mobile/cbrs-radios) and Wi-Fi. We -see service providers as a critical component of this ecosystem rather than replacing service -providers altogether. - -:::tip Purchase a 5G Hotspot and CBRS Small Cell Radios - -Visit [https://www.helium.com/summer](https://www.helium.com/summer) for more information on -purchasing a 5G Hotspot and CBRS Radios to build coverage in your area! - -::: - -## Network of Networks - -A general structure for onboarding new Decentralized Network Protocols (DNPs) to the broader Helium -Network was created with the passing of -[HIP-51: Helium DAOs](https://github.com/helium/HIP/blob/main/0051-helium-dao.md). The Helium Mobile -DAO with 5G Hotspots is the first step in the evolution of the Helium ecosystem. - -The passing of [HIP-51: Helium DAOs](https://github.com/helium/HIP/blob/main/0051-helium-dao.md) -additionally allows for the creation of MOBILE tokens that will reward 5G Hotspots with Small Cell -Radio(s) on the existing Helium Blockchain. - ---- - -## How To Mine MOBILE - -The Helium Network rewards 5G Hotspots with CBRS Radios ("Radios") for providing 5G wireless -coverage and verifying the Helium Network with the Helium MOBILE Token. - -Mining MOBILE by providing 5G coverage requires a 5G Hotspot and one or more compatible, online -Radios. Radios must also be registered in the SAS (Spectrum Access System) maintained by the FCC. - -Several factors contribute to the amount of MOBILE a 5G Hotspot may earn over a given period. This -page covers some higher-level concepts, design elements, and rules to keep in mind that help better -explain what you might earn and why. - -:::info Where Do Rewards Go? - -MOBILE PoC rewards will be credited to the Solana NFT that owns the 5G Hotspot a given Radio is -connected to when the Rewards Oracle disperses MOBILE PoC Rewards. - -::: - -Once properly deployed, Network Builders are not required to do anything else with your 5G Hotspot -or Radios to earn MOBILE. - -More than one Radio can be connected to a single 5G Hotspot to create a larger 5G coverage area, -with 5G Hotspots able to support as many Radios as would saturate their bandwidth. Note that -connecting more than one Radio may require an additional networking switch. Refer to the 5G Hotspot -Maker installation guides for specific instructions. - ---- - -## Pre-Mine - -As defined in [HIP-51](https://github.com/helium/HIP/blob/main/0051-helium-dao.md) and -[HIP-53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md#economics-overview), and -[approved by community-wide votes](https://heliumvote.com/14rifUhocpzdwsrWaG5PDbdREDkzyesKe1hXuWzibv8h9DdqKLe), -the Helium Foundation receives an allocation of 50B (billion) of 250B MOBILE tokens in the form of a -pre-mine. - -### Genesis Period Rewards - -The Helium Foundation will work with the core developers to initiate the Genesis period of MOBILE -rewards. 100M (million) tokens will be programmatically issued per day to all active Helium 5G -Hotspots during the Genesis period. - -Details of the proportional mining rewards for active 5G Small Cell Radios -[can be found here.](/mobile/proof-of-coverage) Any MOBILE not mined during the Genesis period may -be reallocated to Grants and Operations. - -### Grants and Operations - -The Helium Foundation will distribute grants to teams making core contributions to the development -of the MOBILE subDAO. Grants will be distributed based on defined deliverables and milestones. - -The Nova Labs team will be the first grant recipient for work-in-progress and ongoing development -for the MOBILE subDAO. This is spread across three deliverables with 5B MOBILE per milestone for a -total grant of 15B MOBILE: - -- Milestone 1: Ability for 5G Hotspots to earn MOBILE (by August 2022) -- Milestone 2: Development and release of programmatic treasury (by October 2022) - - Actual Programatic Minting started Feb 1 2023 - - The treasury is due to start on April 19 2023 -- Milestone 3: Proof-of-Coverage based rewards (by January 2023) - - Actual date TBC. - -The remaining 15B MOBILE is reserved for other work pertaining to Oracles and Mappers development or -other community contributions. - -### Growth Activities Related to the MOBILE subDAO - -Reserved for marketing and educational campaigns around the MOBILE subDAO. - ---- - -## Emissions Curve - -HIP-53 defined a max supply of 250B (billion) MOBILE with issuance halvenings every two years -aligned with the HNT issuance halvenings. The first MOBILE halving will occur on August 1, 2023, to -align with HNT halving and will continue on a 2-year cycle afterward. Creating a "stub period" as -defined by [HIP-53: Mobile subDAO](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md), -which will begin when standard emissions of MOBILE tokens begin (and MOBILE can be redeemed by HNT -in the subDAO's treasury). - -[HIP-75](https://github.com/helium/HIP/blob/main/0075-mobile-poc-initiate-programmatic-minting-and-updated-emissions-curve.md#economic-changes-to-emissions-curve) -further modifiled the emission schedule and started the programatic minting of MOBILE on Feb -1st 2023. - -| | BEFORE: HIP-53 Emissions Schedule | | AFTER: HIP-75 Emissions Schedule | -| ---- | --------------------------------- | ------------- | -------------------------------- | ------------- | -| Year | MOBILE at year start | MOBILE minted | MOBILE at year start | MOBILE minted | -| 1 | 50B | 116B\* | 50B | 80B\* | -| 2 | 116B | 33B | 80B | 30B | -| 3 | 149.5B | 33B | 110B | 30B | -| 4 | 182B | 16.5B | 140B | 15B | -| 5 | 198.5B | 16.5B | 155B | 15B | -| 6 | 215B | 8.25B | 170B | 7.5B | -| 7 | 223.25B | 8.25B | 177.5B | 7.5B | - -\*50B pre-mine - -Full emissions schedule of HIP53 and HIP75 can be downloaded -[here](https://github.com/helium/HIP/blob/main/0075-mobile-poc-programmatic-minting/mobile-emissions-schedule-HIP53-vs-HIP75.pdf). - -The date for the treasury implementation is April 18, 2023 and dependent on core developers -implementing the HNT token treasury and redemption transactions on the Solana Blockchain as defined -for all new subDAOs in Phase 2 of -[HIP-51: Helium DAO](https://github.com/helium/HIP/blob/main/0051-helium-dao.md). - ---- - -## Manage Tokens with the Helium Wallet App - -A 5G Hotspot with an attached and properly registered Small Cell Radio will start earning MOBILE -automatically as one "lump sum" to the associated Hotspot. You can learn more about calculating -MOBILE Rewards in the [MOBILE Proof of Coverage](/mobile/proof-of-coverage) documentation. - -Interacting with MOBILE tokens is only possible using the -[Helium Wallet App](./wallets/helium-wallet-app). Be sure to update the Helium Wallet app to the -latest version. More information can be found on the -[#announcements](discord://discord.com/channels/404106811252408320/730418759298318346) channel in -[Helium Discord](https://discord.gg/helium) - -- [App Store](https://apps.apple.com/us/app/helium-hnt-wallet/id1609525848) -- [Google Play](https://play.google.com/store/apps/details?id=com.helium.wallet.app&gl=US) diff --git a/docs/network-mobile/cbrs/cbrs-radios.mdx b/docs/network-mobile/cbrs/cbrs-radios.mdx deleted file mode 100644 index fb2b0594a..000000000 --- a/docs/network-mobile/cbrs/cbrs-radios.mdx +++ /dev/null @@ -1,224 +0,0 @@ ---- -id: cbrs-radios -title: CBRS Radios -pagination_label: CBRS Radios -sidebar_label: CBRS Radios -description: CBRS Radios -image: https://docs.helium.com/img/link-image.png -slug: /mobile/cbrs-radios ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# CBRS Small Cell Radios - -Instead of a LoRa antenna, Helium 5G Hotspots use Citizens Broadband Radio Service (CBRS) Radios to -provide cellular coverage. CBRS is a wide broadcast 3.5Ghz band in the United States that does not -require a 5G Hotspot Host to acquire spectrum licenses. - -You can find more information about CBRS on the -[Federal Communications Commission Website](https://www.fcc.gov/35-ghz-band-overview) - -5G Hotspots can provide 5G cellular coverage when connected to Indoor or Outdoor CBRS Small Cell -Radios while also providing LoRaWAN coverage. - -:::warning - -Only certified CBRS Radios provisioned with the FreedomFi firmware will operate when connected to a -5G Hotspot. - -CBRS Radios that are not certified and do not use the FreedomFi firmware will not provide 5G -coverage and will not mine MOBILE. - -::: - -The [Helium Discord](https://discord.gg/helium) is the best place to get real-time support from the -community. The [#5g-cbrs](discord://discord.com/channels/404106811252408320/836735476659912754) -channel is most relevant for using 5G on the Network. - ---- - -## Installation and Setup Guides - -Instructions on installing a CBRS Small Cell Radio and registration with the SAS are provided by the -individual 5G Hotspot Makers. - -For FreedomFi Gateways, refer to the installation guides here: - -- [FreedomFi Indoor Install Guide](https://freedomfi.com/freedomfi-indoor-cbrs-small-cell-setup-guide/) -- [FreedomFi Outdoor Install Guide](https://freedomfi.com/freedomfi-outdoor-cbrs-small-cell-setup-guide/) - -For Bobcat500 Gateways, refer to the Bobcat Knowledge Center: - -- [Bobcat Knowledge Center CBRS Radio Troubleshooting Guide](https://bobcatminer.zendesk.com/hc/en-us/articles/4588536001435-Overview) - -:::warning - -Misrepresentation of CBRS Radio installation information, including GPS location, height, antenna -orientation, or other characteristics in a SAS, violates FCC regulations and may result in fines and -possible criminal penalties. - -::: - ---- - -## Access Gateway and Radio Dashboards - -Once the 5G Hotspot is onboarded and a Small Cell Radio installation is complete, the Small Cell -Radio will automatically initialize and acquire a GPS lock. Once that is complete, the Small Cell -Radio dashboard appears under the "Radio Dashboard" tab on the local IP address of the 5G Hotspot. - -- If you are using a FreedomFi gateway, you can access the miner and radio dashboard via the URL: - [http://freedomfi-gateway.local/](http://freedomfi-gateway.local/) - -- If you are using a Bobber 500 gateway, you can access the miner and radio dashboard via this URL: - [http://bobber-gateway.local/](http://bobber-gateway.local/) - -5G Hotspot will appear on [explorer.helium.com](https://explorer.helium.com/) within five days, -depending on how quickly it is registered in the SAS. - ---- - -## Outdoor Small Cell Radios - -Outdoor Small Cell Radios are weatherized to endure the elements and are more powerful than Indoor -Small Cell Radios. However, Outdoor Small Cell Radios create a larger area of 5G coverage while -requiring more planning when installing and maintaining. - -Outdoor Small Cell Radios require installation above ground level and require registration with the -Spectrum Access System (SAS) to operate. Please evaluate your site location and ability to install -these Small Cell Radios, and consider hiring a professional to ensure your installation is secure -and meets all regulatory requirements. - -SAS registration is expected to be completed within five days of submission. Hotspot Owners will be -contacted via email with a confirmation of successful registration or with a rejection reply and an -explanation of what needs to be corrected. - -## Indoor Small Cell Radios - -Indoor Small Cell Radios are less powerful and are ideal for installations such as coffee shops, -bars, grocery stores, etc. Indoor Small Cell Radios are generally easier to install and create a -smaller, localized area of 5G coverage. - -Indoor Small Cell Radios are physically smaller radios and can be installed at any height. -**Installing an Indoor Small Cell Radio outdoors is not recommended as they are not weather -resistant.** - -## Using Multiple Small Cell Radios - -A single 5G Hotspot can support multiple Small Cell Radios but requires an additional network -switch. A soft limit to consider is 7 Small Cell Radios to one 5G Hotspot; however, this limit is -only theoretical as the real limiting factor is bandwidth saturation. All 5G Hotspots are built with -a 1 Gbps Network Interface Card (NIC); the throughput of all the radios combined is limited to 1 -Gbps or your internet speed, whichever is lower. - ---- - -## Troubleshooting - -### Confirm the Network is Working - -Visit the [FreedomFi Status page](https://status.helium.freedomfi.com/). - -This status page will provide the latest updates on important issues that impact users, like Device -Onboarding, SAS services, or other significant events. - -### Spectrum Access on the 5G Hotspot Dashboard - -The Spectrum Access status will be in one of four states. It is not uncommon to see this status -change frequently. - -
-
-
- -

- The Small Cell Radio has been granted Spectrum Access by the SAS and is providing 5G - coverage. -

-
-
- -

- The Spectrum Access was recently None and is coming back online, this status - should be transitory. -

-
-
- -

The Spectrum Access is disabled to the Small Cell Radio.

-

- See below for more information. -

-
-
- -

The Spectrum Access Grant to the Small Cell Radio has Failed.

-

- See below for more information. -

-
-
-
- -### Spectrum Access `None` Status - -A Dynamic Protection Area (DPA) is a geographic region where incumbents (Tier 1 users) get -protection from PAL and GAA interference. - -During a DPA Activation event, all Small Cell Radios in the given DPA Neighborhood are disabled by -the SAS. There is nothing that you need or can do in these scenarios. The SAS will automatically -re-grant Spectrum Access once the DPA Activation event has concluded. - -A message similar to the following may also be present: - -> Spectrum Access status returned to "Connected" after it had been working. Wait and don't reboot. -> Suspension can last from hours to days for DPA Events. Contact support if you have been suspended -> for more than 48hrs. This is more prevalent if your location is within 150km of the DPA Regions. - -### Spectrum Access `FAILURE` Status - -This status is alarming, but do not let it scare you. - -This "Failure" status is likely because the registration process has not been completed and -submitted to the SAS for newly installed Small Cell Radios. - -You may see an information pop-up similar to this: - -> SAS status code: 200 SAS response message: Response data: installationParam - -Contact [FreedomFi Support](https://freedomfi.com/contact-us/) for any other warning messages. - -### DPA Neighborhood Regions - -DPA regions can be viewed on the map below. Remember, these coordinates are not exact, and the -affected areas for each DPA Activation event can reach as far as 150km inland. - -
- -
- -:::tip - -Further information and maps of the DPA Neighborhoods in the United States and territories can be -found here: -[CBRS Encumbrances Overview](https://winnf.memberclicks.net/assets/work_products/WINNF-20-IN-0065r1%20CBRS%20Encumbrances%20Overview.pdf) - -This link and the included information are for reference only and may not address all current DPA -Neighborhoods. - -::: - -### Small Cell Radio GPS Requirement - -All compatible CBRS Small Cell Radios use GPS for network timing data and to assert the Small Cell -Radio's location when requesting approval to transmit from the FCC-regulated Spectrum Access System -(SAS). - -Small Cell Radios will need to be placed somewhere that allows the GPS antenna to be in a location -with good GPS reception (i.e., near a window). Indoor Small Cell Radios are shipped with an external -GPS antenna which can be positioned independently, while Outdoor Small Cell Radios have the GPS -antenna integrated into the body directly. diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-5520.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-5520.mdx new file mode 100644 index 000000000..1c6d1831e --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-5520.mdx @@ -0,0 +1,213 @@ +--- +id: helium-plus-Cisco-WLC-5520 +title: Cisco Catalyst 5520 Conversion Guide +pagination_label: Cisco Catalyst 5520 Conversion Guide +sidebar_label: Cisco Catalyst 5520 +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-Cisco-WLC-5520 +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- Cisco AireOS system must be running 8.5 or later. +- Guide assumes the network is using an on-prem 5520 Controller. +- Wi-Fi system has AP(s) linked to the 5520 WLC Controller. +- Cisco system has basic traffic routing working with existing SSID(s). +- An Intel-based host is required in the network to run the + [RadSecProxy](https://github.com/novalabsxyz/radsec-proxy) container. + +# High Level Steps + +1. Deploy RadSecProxy container and record IP address of host +2. Build WLAN Helium Passpoint SSID + 1. Build an SSID for Helium + 2. Configure Security and RADIUS Connections + 3. Configure 802.11u + 4. Build Hotspot 2.0 Profile + 5. Enable Hotspot 2.0 + +# Deploy RadSecProxy Container + +RADIUS messages used to authenticate users and for session accounting are transmitted unsecured and +over UDP by default. By directing these messages internally in your secure network to a RadSecProxy, +the UDP is then converted to a TLS protected TCP connection to the Helium Network core AAA servers. + +## Prerequisites + +- An intel based machine with Docker installed. +- The intel based machine has a private IP in your network reachable from your 5520 WLC Controller +- ACLs or Firewalls allow 5520 WLC Controller and Docker Container to communicate UDP on port 1812 + and 1813 +- ACLs or Firewalls allow container/host to reach the internet on TCP ports 2083 and 3802\. + +## Container Deployment + +1. Un-zip and untar the `Helium_RadSec_Docker.tar.gz` file into the directory of your choice on the + host machine. This will unpack the following items: + 1. `Dockerfile` \- The docker instructions on how to build the container + 2. `Radsecproxy.conf` \- The radsecproxy config file is pre-populated to connect to Helium + Network AAA servers + 3. `docker-compose.yml` \- File to start and stop the container as a daemon. + +```bash +tar -xvzf Helium_RadSec_Docker.tar.gz +``` + +2. Into the same directory copy the 3 certificates obtained from Helium Network + 1. ca.pem \- the root CA certificate + 2. cert.pem \- the user certificate + 3. key.pem \- the key file matched to the certificate +3. Start the container using: + +```bash +sudo docker compose up -d +``` + +4. If/when needed, stop the container using: + +```bash +sudo docker compose down +``` + +# Build an SSID for Helium + +This guide outlines how to configure a Cisco 5520 Wireless LAN Controller (WLC) running AireOS 8.5 +for integration with the Helium Network using a local Docker-based RadSecProxy. This enables +Passpoint (Hotspot 2.0) authentication through Helium’s secure RADIUS infrastructure. + +To start login to your Cisco 5520 Dashboard in your browser, this will be our starting point for all +major steps below + +1. Log into your WLC Dashboard → click **Advanced** → **WLANs** +2. Click **Create New** → **Go**. +3. Enter Profile Name: **Helium** +4. Enter SSID: **Helium**. +5. Set ID: any available value. +6. Click 'Apply' → then select the WLAN ID to edit + +:::note + +In the following steps we will only mention mandatory fields to set. Most windows will have many +other parameters with default values set. Leave any unmentioned parameter at it's default value. + +::: + +## Configure Security and RADIUS Connections + +1. Under the **General** tab, check the **Status** box to Enable +2. Check the box to **Broadcast SSID** +3. Configure the **NAS-ID** to the value shared to you by Helium + +
+ +
+ +2. Under the **Security -> Layer2** tabs configure the following parameters: +3. In **Layer 2 Security** dropdown choose **WPA2 + WPA3** +4. Check the boxes for **WPA2** and **WPA3** Policy +5. For **Encryption Cipher** check the box for **CCM128(AES)** + +
+ +
+ +6. Under the **Security -> AAA** tabs configure the following parameters: +7. Configure **Authentication Server IP** to be the **IP of your local RadSecProxy** +8. Configure **Authentication Port** to be **1812** +9. Configure **shared secret** to **mysecret** +10. Configure **Accounting Server IP** to be the **IP of your local RadSecProxy** +11. Configure **Accounting Port** to be **1813** +12. Configure **shared secret** to **mysecret** +13. Configure **Interim Interval** to **300 seconds** + +# Configure 802.11u + +1. From the main WLANs view, select the blue down arrow to the right of the WLAN description and + select **802.11u** from the dropdown menu + +
+ +
+ +2. In the configuration page that opens configure the following parameters: +3. Check the box for **802.11u Status** to Enable to view more configurable parameters +4. Check the box for **Internet Access** to **Enabled** +5. In the dropdown for **Network Type** choose **Chargable Public** +6. In the dropdown for **IPv4 Type** choose **Single NATed Private** or most applicable option for + your network +7. In the dropdown for **IPv4 Type** choose **Not Available** or most applicable option for your + network +8. In the **Realm List** enter **hellohelium.com** and click **Add** +9. Repeat adding to **Realm List** and enter **freedomfi.com** and click **Add** +
+ +
+ +:::note + +You can see in the bottom right of the screenshot where you will add the carrier codes that will be +sent from the Helium team. + +::: + +10. **Click** on the **hellohelium.com** realm you just created +11. Set **EAP Method** to **EAP-TLS**, then click on **Ad**. The EAP method appears in the EAP + Index. If it asks for sub-method choose **Certificate** +12. Repeat the steps for the freedomfi.com realm +13. In the **Domain List** enter **hellohelium.com** and click **Add** +14. **Save** configuration + +# Build Hotspot 2.0 Profile + +1. From the main WLANs view, select the blue down arrow to the right of the WLAN description and + select **Hotspot 2.0** from the dropdown menu + +
+ +
+ +2. Check the box to **Enable** Hotspot 2.0. +3. Set **WAN Link Status** to **Link Up** +4. Click **Apply -> Save Configuration** + +# Verification + +1. After saving, attempt to connect using a Helium Mobile SIM or eSIM device. +2. Monitor the proxy logs with: + +```bash + docker logs -f radsecproxy +``` + +3. Successful authentication will display lines similar to: + +```bash + Received Access-Request from 192.168.x.x + Access-Accept for user anonymous@.hellohelium.com +``` + +4. You can also confirm in the WLC Dashboard → Monitor → Clients that the device is connected via + 802.1X authentication. diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-9800.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-9800.mdx new file mode 100644 index 000000000..b9ce077c7 --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-9800.mdx @@ -0,0 +1,449 @@ +--- +id: helium-plus-Cisco-WLC-9800 +title: Cisco Catalyst 9800 Conversion Guide +pagination_label: Cisco Catalyst 9800 Conversion Guide +sidebar_label: Cisco Catalyst 9800 +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-Cisco-WLC-9800 +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- Cisco IOS XE system must be running + [17.9](https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ) + or later. +- Guide assumes the network is using an on-prem 9800 Controller. +- Wi-Fi system has AP(s) linked to the 9800 WLC Controller. +- Cisco system has basic traffic routing working with existing SSID(s). +- An Intel-based host is required in the network to run the + [RadSecProxy](https://github.com/novalabsxyz/radsec-proxy) container. + +# High Level Steps + +1. Deploy RadSecProxy container and record IP address of host +2. Build WLAN Helium Passpoint SSID + 1. Build a RADIUS Server and Group + 2. Create a AAA Method List + 3. Add the NAS-ID to the WLAN AAA Policy + 4. Build Hotspot 2.0 Profile + 5. Build the Helium SSID + 6. Apply Policy and Hotspot Profile to the SSID + 7. Create Policy Tag + 8. Apply Tag to APs + +# Deploy RadSecProxy Container + +RADIUS messages used to authenticate users and for session accounting are transmitted unsecured and +over UDP by default. By directing these messages internally in your secure network to a RadSecProxy, +the UDP is then converted to a TLS protected TCP connection to the Helium Network core AAA servers. + +## Prerequisites + +- An intel based machine with Docker installed. +- The intel based machine has a private IP in your network reachable from your 9800 WLC Controller +- ACLs or Firewalls allow 9800 WLC Controller and Docker Container to communicate UDP on port 1812 + and 1813 +- ACLs or Firewalls allow container/host to reach the internet on TCP ports 2083 and 3802\. + +## Container Deployment + +1. Un-zip and untar the `Helium_RadSec_Docker.tar.gz` file into the directory of your choice on the + host machine. This will unpack the following items: + 1. `Dockerfile` \- The docker instructions on how to build the container + 2. `Radsecproxy.conf` \- The radsecproxy config file is pre-populated to connect to Helium + Network AAA servers + 3. `docker-compose.yml` \- File to start and stop the container as a daemon. + +```bash +tar -xvzf Helium_RadSec_Docker.tar.gz +``` + +2. Into the same directory copy the 3 certificates obtained from Helium Network + 1. ca.pem \- the root CA certificate + 2. cert.pem \- the user certificate + 3. key.pem \- the key file matched to the certificate +3. Start the container using: + +```bash +sudo docker compose up -d +``` + +4. If/when needed, stop the container using: + +```bash +sudo docker compose down +``` + +# Build Meraki Helium Passpoint SSID + +The following steps will configure your Cisco 9800 WLC system to broadcast an SSID with the needed +Passpoint and RADIUS configurations to support Helium Mobile user offload. + +To start login to your Cisco 9800 Dashboard in your browser, this will be our starting point for all +major steps below + +
+ +
+
+ +:::note + +In the following steps we will only mention mandatory fields to set. Most windows will have many +other parameters with default values set. Leave any unmentioned parameter at it's default value. + +::: + +## Build a RADIUS Profile + +1. Click on **Configuration -> Security -> AAA** in the left menu column + +
+ +
+ +2. Confirm RADIUS is selected in left column and Click **+Add** in the top left +3. Enter a **Name** e.g. Helium_AAA +4. Enter a **Server Address** with the IP of the RadSecProxy you installed earlier. +5. Enter the **Key** and **Confirm Key** fields equal to "mysecret" (modify if you have modified + during the RadSecProxy container installation) +6. Confirm the **Auth Port** and **Acct Port** are 1812 and 1813 respectively +
+ +
+7. Click **Apply to Device** + +**NOTE** If you have installed multiple RadSecProxy instances for redundancy, repeat the server +creation for each instance incrementing the names with an integer e.g. Helium_AAA_1 + +8. Click on **Server Group** +
+ +
+9. Click on **+Add** +10. Enter a **Name** e.g. "Helium_svg" +11. Select your AAA servers and use the arrows to move them into the **Assigned Servers** list +
+ +
+12. Click **Apply to Device** + +## Create a AAA Method List + +1. Click **AAA Method List** +
+ +
+2. Click **+Add** in the lower box +
+ +
+3. Enter a **Name** e.g. Helium-aaa-meth-list +4. In **Type** dropdown select **dot1x** +5. Select your Server Group in the list and use the arrows to move it to **Assigned Server Groups** +
+ +
+6. Click **Apply to Device** +7. From the left column select **Accounting** and then click **+Add** +
+ +
+8. In **Method List Name** enter **Helium_meth_list_acct** +9. In the **Type** dropdown select **Identity** +10. Select your Server Group and use the arrows to move it into the **Assigned Server Group** +
+ +
+11. Click **Apply to Device** + +# Add the NAS-ID to the WLAN AAA Policy + +1. Click on **Configuration -> Security -> Wireless AAA Policy** + +
+ +
+ +2. Click on **+Add** +3. Enter a **Name** e.g. Helium_aaa_policy +4. In the **NAS-ID Option 1** drop down select **Custom** +5. Enter the NAS_ID shared with you by Helium + +
+ +
+ +6. Click **Apply to Device** + +# Build Hotspot 2.0 Profile + +1. Click on **Configuration -> Wireless -> Hotspot/OpenRoaming** +
+ +
+2. Click **+Add** under **ANQP Servers** +3. Enter **Name** as **Helium** +4. Enter **Description** as **Helium** +5. Check the box for **Internet Access** +6. In the **Network Type** drop down select **Chargable Public** + +
+ +
+ +7. Click **+Add** under **NAI Realm** +8. Enter **NAI Realm Name** as **helloheium.com** +9. Click to **Enable** the **EAP-TLS** option +10. Check the box for **certificate** +11. Click **Save** +12. Click **Apply to Device** + +
+ +
+ +13. Repeat the steps to add a second NAI realm for **freedomfi.com** +
+ +
+14. At the top of the window select **Server Settings** +15. In the drop down for **IPv4 Type** select **Double NAT Private** (or option that appropriately + describes your network) +16. In the drop down for **IPv6 Type** select **Not Available** +
+ +
+17. Click **Apply to Device** + +# Build the Helium SSID + +1. Click on **Configuration -> Wireless -> WLANs** +
+ +
+2. Click on **+Add** +3. Enter **Name** as **Helium** +4. Enter **SSID** as **Helium** +5. Enter **WLAN ID** as your next available integer e.g. 4 +6. Select **Enable** to turn the ssid on +7. Select Enable/Discable for 6GHz as you hardware supports +
+ +
+8. Select **Security** at the top of the window +9. Select **Layer2** in the row below that +10. Ensure the following boxes are **checked** including **WPA2 Policy**, **AES(CCMP128)**, + **802.1x** +
+ +
+11. Select **AAA** at the top of the window +12. In the **Authentication List** drop down select **Helium_aaa_meth_list** +
+ +
+13. Click **Apply to Device** + +# Apply Policy and Hotspot Profile to the SSID + +1. Click on **Configuration -> Tags & Profiles -> Policy** +
+ +
+2. Enter **Name** as **Helium** +3. Enter **Description** as **Helium** +4. Toggle **Status** to **Enabled** +
+ +
+5. Across the top, select **Access Policies** +6. Select the **VLAN/VLAN Group** configured for Helium users (NOTE: This is typically a Guest type + network with access to internet only) + +
+ +
+ +7. Across the top, select **Advanced** +8. **Uncheck** the box next to **Client Exclusion Timeout** +9. In the **Hotspot Server** drop down select **Helium** +10. **Check** the box for **Allow AAA Override** +11. In the **Policy Name** drop down select **Helium_aaa_policy** +12. In the **Accounting List** drop down select **Helium_meth_list_acct** +
+ +
+13. Click **Apply to Device** + +# Create Policy Tag + +1. Click on **Configuration -> Tags & Profiles -> Tags** +
+ +
+2. Enter **Name** as **Helium** +3. Enter **Description** as **Helium** +4. Click **+Add** below **WLAN-POLICY** +5. In both **WLAN Profile** and **Policy Profile** drop down menus select **Helium** +
+ +
+6. Click the **checkmark** +7. Click **Apply to Device** + +# Apply Helium Tag to AP(s) + +1. Click on **Configuration -> Wireless Setup -> Advanced** +
+ +
+2. Click on **Start Now** +
+ +
+3. Click on the selector box next to **Tag APs** in the bottom right +
+ +
+4. **Check** the box next to the APs you want to broadcast the Helium SSID +5. Click **+Add** when you have you APs selected +
+ +
+6. In the **Policy** Drop down select **Helium** +
+ +
+7. Click **Apply to Device** diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-aruba-central.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-aruba-central.mdx new file mode 100644 index 000000000..ea283bec2 --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-aruba-central.mdx @@ -0,0 +1,252 @@ +--- +id: helium-plus-aruba-central +title: Aruba Central Conversion Guide +pagination_label: Aruba Central +sidebar_label: Aruba Central +description: Convert Aruba WLANs to support Helium Mobile offload using RadSec and Passpoint. +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-aruba-central +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +Before starting, confirm the following: + +- Aruba system is running AOS 8.10.x.x or later +- Network uses an on-prem Aruba Mobility Controller +- APs are adopted and serving traffic +- Existing SSIDs are functional +- Aruba infrastructure has outbound internet access to Helium AAA endpoints + +--- + +## High-Level Steps + +1. Upload Helium RadSec Certificates +2. Configure SSID for RadSec +3. Configure Passpoint Settings +4. Connect and Validate + +--- + +:::note + +This guide applies to "Classic Central". +If your Aruba dashboard shows a "Classic Central" toggle, enable it. + +::: + +## Upload Helium RadSec Certificates + +Helium requires RADIUS traffic to be secured using RadSec (RADIUS over TLS). + +Download the following from the Helium onboarding process (either from the WiFi Conversion process +or sent to you by your Helium Plus contact): + +- RadSec Server CA (ca.pem) +- RadSec Client Certificate (combine cert.pem and key.pem into a single PEM file; for example: + `cat cert.pem key.pem > client_combined.pem`) + +Navigate to: + +**Global → Organization → Network Structure → Certificates** + +--- + +### Upload Server CA + +Navigate to 'Organization' then 'Certificates' + +
+ +
+ +Create a new certificate with the following values: + +
+ +
+ +- Name: `Helium Server CA` (example) +- Type: CA Certificate +- Format: PEM +- File: RadSec Server CA + +
+ +
+--- + +### Upload Client Certificate + +Create another certificate: + +- Name: `Helium Client Certificate` (example) +- Type: Server Certificate +- Format: PEM +- File: Combined cert and key + +
+ +
+ +--- + +## Configure SSID for RadSec + +Navigate to: + +**Devices → WLANs** + +Note: Ensure you've selected your AP first or the WLAN options won't show. + +Click **Add SSID** and enter the SSID name. + +
+ +
+ +--- + +### SSID General Configuration + +Set the following values: + +- Under 'General', set the SSID name to 'Helium'. + +Click **Next**. + +- Configure VLAN and IP assignment as required for your deployment + +Click **Next**. + +- Under Security, set Security Level to Enterprise +- Set Key Management to WPA3-Enterprise + +Click **Add** next to **Primary Server** and create a new authentication server. + +--- + +### Create RadSec Authentication Server + +Configure the authentication server with the following values: + +- Server Name: `Helium-RadSec` +- Server Type: RADIUS +- Enable RadSec: enabled +- IP Address: radius-bf.wifi.hellohelium.com +- RadSec Port: 2083 +- RadSec Keepalive Type: TCP Keepalive + +Click **OK**. + +
+ +
+ +--- + +### Complete SSID Settings + +Verify the following: + +- Security Level: Enterprise +- Key Management: WPA3-Enterprise +- Server Group: Primary and backup only +- Primary Server: `Helium-RadSec` +- Under Advanced Settings, go to `Passpoint Service Profile` and click `Manage Passpoint Services`. + - Click **Add Profile**. + - Under `Access Network`: + - Name the profile `Helium Passpoint`. + - Enable the `Internet` slider. + - Set Domain Name to `freedomfi.com`. + - Set Network Type to `Chargeable Public`. + - Set IPv4 to `Double NAT Private`. + - Set IPv6 to `None`. + +
+ +
+ +- Under `Identity Provider` > `NAI Realms`: + - Click **Add NAI Realm**. + - Set NAI Realm to `freedomfi.com`. + - Set EAP Method to `EAP-TLS`. + - Set Authentication parameter to `Certificate`. + - Click **OK**, then repeat to add `hellohelium.com` with the same settings. + +
+ +
+
+
+ +
+ +- Back on the SSID settings under `Accounting` tab: + - Set accounting interval to `5 minutes` + +
+ +
+ +## Troubleshooting + +If authentication fails, check the following: + +- Certificates: verify the Server CA and the combined client certificate were uploaded correctly and + assigned to the device. +- Network: ensure outbound TCP 2083 to the Helium RadSec endpoint is allowed from your Aruba + infrastructure. +- Logs: check Aruba controller logs and the Helium RADIUS logs for Access-Request / Access-Accept + messages. + +## Connect and Validate + +Connect a client device to the newly created SSID. + +Verify successful authentication. + +--- diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-aruba.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-aruba.mdx new file mode 100644 index 000000000..a5aa61759 --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-aruba.mdx @@ -0,0 +1,496 @@ +--- +id: helium-plus-aruba +title: Aruba Conversion Guide +pagination_label: Aruba Conversion Guide +sidebar_label: Aruba +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-aruba +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- Aruba system must be running + [AOS 8.10.x.x](https://arubanetworking.hpe.com/techdocs/ArubaOS/Consolidated_8.x_RN/Content/8.10/overview-8100x.htm) + or later. +- Guide assumes the network is using an on-prem Aruba Mobility Controller. +- Aruba system has AP(s) linked to the Mobility Controller. +- Aruba system has basic traffic routing working with existing SSID(s). +- An Intel-based host is required in the network to run the + [RadSecProxy](https://github.com/novalabsxyz/radsec-proxy) container. + +# High Level Steps + +1. Deploy RadSecProxy container and record the IP address of the host +2. Build Helium Passpoint SSID + 1. Build RADIUS Authentication Servers + 2. Build WLAN + 3. Link AAA Profile to RADIUS Accounting Server Group + 4. Build ANQP Profile + 5. Build Advertisement Profile + 6. Link ANQP Profile to the Advertisement Profile + 7. Build Hotspot 2.0 Profile + 8. Link Advertisement Profile to Hotspot 2.0 Profile + 9. Link Hotspot 2.0 Profile to Virtual AP + +# Deploy RadSecProxy Container + +RADIUS messages used to authenticate users and for session accounting are transmitted unsecured and +over UDP by default. By directing these messages internally in your secure network to a RadSecProxy, +the UDP is then converted to a TLS protected TCP connection to the Helium Network core AAA servers. + +## Prerequisites + +- An Intel-based machine with Docker installed. +- The Intel-based machine has a private IP in your network reachable from your Aruba Mobility + Controller +- ACLs or Firewalls allow Aruba Mobility Controller and Docker Container to communicate UDP on port + 1812 and 1813 +- ACLs or Firewalls allow container/host to reach the internet on TCP ports 2083 and 3802\. + +## Container Deployment + +1. Un-zip and untar the `Helium_RadSec_Docker.tar.gz` file into the directory of your choice on the + host machine. This will unpack the following items: + 1. `Dockerfile` \- The docker instructions on how to build the container + 2. `Radsecproxy.conf` \- The radsecproxy config file is pre-populated to connect to Helium + Network AAA servers + 3. `docker-compose.yml` \- File to start and stop the container as a daemon. + +```bash +tar -xvzf Helium_RadSec_Docker.tar.gz +``` + +2. Into the same directory copy the 3 certificates obtained from Helium Network + 1. `ca.pem` \- the root CA certificate + 2. `cert.pem` \- the user certificate + 3. `key.pem` \- the key file matched to the certificate +3. Start the container using: + +```bash +sudo docker compose up -d +``` + +4. If/when needed, stop the container using: + +```bash +sudo docker compose down +``` + +--- + +## Build Aruba Helium Passpoint SSID + +The following steps will configure your Aruba Mobility Controller and AP to broadcast an SSID with +the needed Passpoint and RADIUS configurations to support Helium Mobile user offload. + +To start login to your Mobility Controller GUI in your browser, this will be our starting point for +all major steps below. + +
+ +
+
+ +:::important In the following steps we will only mention mandatory fields to set. + +Most windows will have many other parameters with default values set. Leave any unmentioned +parameter at it's default value. + +::: + +## Build RADIUS Authentication Servers + +1. Click on **Configuration** and then **Authentication** in the left menu column. +2. Click the **\+** in the **All Servers** box to add a server +3. Enter “**RadSec-1**” as the Name +4. Choose **RADIUS** as the Type +5. Enter the IP address of the RadSecProxy Container host + +
+ +
+ +6. Click **Submit** +7. Click on the Server name in the table to enter further configuration +8. Enter **Auth Port** \= **1812** +9. Enter **Acct Port** \= **1813** +10. Enter “**mysecret**” as the shared key and retype key +11. Enter the **NAS-ID** used during onboarding with Helium Network + +
+ +
+ +12. Click **Submit** +13. Click **Pending Changes** in the top right corner. +14. Click **Deploy Changes** in the pop up. + +:::note + +Redundancy is good. If you deploy two containers on two hosts, repeat these steps for a second +RadSec server called Radsec-2. + +::: + +## Build WLAN + +1. Click on the arrow next to Mobility Controller in the top left corner of the window and select + the controller you want to configure. + +
+ +
+ +2. Click on **Configuration** and **WLAN** in the left menu column. +3. Click the **\+** in the bottom left of the box to add a new WLAN +4. Enter Name (SSID) \= “**Helium**” +5. Edit Broadcast on AP group and Forwarding mode based on your network configuration. In this + example we use All APs and Tunnel mode. + +
+ +
+ +6. Click **Next** +7. Configure the VLAN settings based on your network configuration. In this example we have a VLAN + called “LAN” that we use. + +
+ +
+ +8. Click **Next** +9. Select **WPA3-Enterprise** for **Key Management** +10. Click \+ in Auth Servers and select Radsec-1 (and Radsec-2 if you have two) + +
+ +
+ +11. Click **Next** +12. Select the Default Role based on your network configuration. In this example we use a + “allow-all” rule that is wide open and allows-all user traffic. + +
+ +
+ +13. Click **Finish** + +## Link AAA Profile for RADIUS Accounting Server Group + +1. Click on **Configuration** and then **Authentication** in the left menu column. +2. Click on **AAA Profiles** in the top menu bar +3. Click the **\+** next to **AAA** and **\+** next to **Helium_aaa_prof** +4. Click on **RADIUS Accounting Server Group** +5. Select **Heium_dot1_svg** from drop down menu next to **Server Group** + +
+ +
+ +6. Click **Submit** +7. Click **Pending Changes** in the top right corner. +8. Click **Deploy Changes** in the pop up. + +## Build ANQP Profile + +### Domain Name + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **ANQP Domain Name** +4. Click the **\+** in the area to the right to build a new **ANQP Domain Name Profile** + +
+ +
+ +5. Enter “**Helium_Domain**” for Profile Name and “**Hellohelium.com**” for Domain Name +6. Click **Submit** +7. Click **Pending Changes** in the top right corner. +8. Click **Deploy Changes** in the pop up. + +### IP Address Availability + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **ANQP IP Address + Availability** +4. Click the **\+** in the area to the right to build a new **ANQP IP Address Availability Profile** + +
+ +
+ +5. Enter “Helium_IP” for profile name, select appropriate values for IPv4 and IPv6 availability. If + unsure, select “**private-double-nated**” and “**not-available**”. +6. Click **Submit** +7. Click **Pending Changes** in the top right corner. +8. Click **Deploy Changes** in the pop up. + +### NAI Realm + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **ANQP NAI Realm** +4. Click the **\+** in the area to the right to build a new **ANQP NAI Realm Profile** + +
+ +
+ +5. Enter “**Helium_realm**” for Profile Name and “**hellohelium.com**” for NAI Realm Name. +6. In the drop down for NAI Realm EAP Method 1 chose “**eap-tls**” and below that click the **\+** + to set ID \= **Credential Type** and Value \= **cred-cert** +7. Click **OK** +8. Click **Submit** +9. Click **Pending Changes** in the top right corner. +10. Click **Deploy Changes** in the pop up. + +### Venue Name + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **ANQP Venue Name** +4. Click the **\+** in the area to the right to build a new **ANQP Venue Name Profile** + +
+ +
+ +5. Enter “Helium_venue” in Profile Name, select the best fitting Venue Group e.g. “**business**” and + best fitting Venue Type e.g. “**assembly-restaurant**” and supply a Venue Name which can be the + street address of your venue e.g. “**303 Elk Ave**” +6. Click **Submit** +7. Click **Pending Changes** in the top right corner. +8. Click **Deploy Changes** in the pop up. + +## Build Advertisement Profile + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **Advertisement Profile** +4. Click the **\+** in the area to the right to build a new **Advertisement Profile** + +
+ +
+ +5. Enter “Helium_adv_prof” as Profile name +6. Click **Submit** +7. Click **Pending Changes** in the top right corner. +8. Click **Deploy Changes** in the pop up. + +## Link ANQP Profiles to the Advertisement Profile + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **Advertisement** +4. Click the **\+** next to **Advertisement** and click on the **\+** next to **Helium_adv_profile** +5. Select **ANQP Domain Name** from the list and click on the **\+** in the box to the right and + select “**Helium_Domain**” from the list. + +
+ +
+ +6. Click **OK** +7. Click **Submit** +8. Click **Pending Changes** in the top right corner. +9. Click **Deploy Changes** in the pop up. +10. Repeat steps 1-9 to add: + 1. ANQP IP Address Availability + 2. ANQP NAI Realm + 3. ANQP Venue name + +:::important + +You must do each parameter individually and deploy changes each time. + +::: + +## Build Hotspot 2.0 Profile + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **Hotspot 2.0** +4. Click the **\+** in the area to the right to build a new **Hotspot 2.0 Profile** + +
+ +
+ +5. Enter “**Helium_hs20**” for Profile name +6. Check the box for **Advertise Hotspot 2.0 Capability** +7. Select **Access Network Type** \= **Public chargeable** +8. Select best fitting **Venue Group Type** e.g. **assembly** +9. Select Best fitting **Venue Type** e.g. **assembly-restaurant** +10. Check the box next to **RADIUS Chargeable User Identity(RFC4372)** +11. Check the box next to **RADIUS Location Data (RFC5580)** +12. When complete the form should look like above. +13. Click **Submit** +14. Click **Pending Changes** in the top right corner. +15. Click **Deploy Changes** in the pop up. + +## Link Advertisement Profile to Hotspot 2.0 Profile + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **Hotspot 2.0** +4. Click the **\+** next to the **Helium** Hotspot 2.0 profile +5. Click on **Advertisement** + +
+ +
+ +6. Select **Helium_adv_prof** from the drop down menu +7. Click **Submit** +8. Click **Pending Changes** in the top right corner. +9. Click **Deploy Changes** in the pop up. + +## Link Hotspot 2.0 Profile to Virtual AP + +1. Click on **Configuration** and **System** in the left menu column. +2. Click on **Profiles** in the menu bar across the top +3. Click the **\+** next to **Wireless LAN** and scroll down to find **Virtual AP** +4. Click the **\+** next to **Virtual AP** and click the **\+** next to **Helium** +5. Click on **Hotspot 2.0** +6. Select **Helium_hs20** from drop down menu next to **Hotspot 2.0 Profile** at the top + +
+ +
+ +7. Click **Submit** +8. Click **Pending Changes** in the top right corner. +9. Click **Deploy Changes** in the pop up. + +## Troubleshooting + +### Look for incoming RADUS packets in RadSec Logs + +``` +radsec@radsec:~$ sudo docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +4cefb87fb8cc 612e4c464d65 "/usr/bin/radsecprox…" 13 hours ago Up 13 hours (healthy) 0.0.0.0:1812-1813->1812-1813/udp, :::1812-1813->1812-1813/udp radsec-radsecproxy-1 + +radsec@radsec:~$ sudo docker logs -f 4cefb87fb8cc +``` + +Follow logs from the container and look for Accept or Rejects for any reasons. + +- No Radius when phone is trying means: + - Aruba setup is not forwarding or not forwarding the right ports + - Network is blocking, check for ACLs or Firewall in network path + - Container host network is blocking it being sent to container check for firewall services on + host +- Radius arrives but you are getting rejects means: + - Make sure NAS_ID has been onboarded to Helium Network + - Double check ANQP profile creation steps + +### Inspect RADIUS AVP contents + +```bash +ssh radsec@192.168.10.209 -- sudo tcpdump -i any -U -s0 -w - port 1813 or 1812 or 2083 | /Applications/Wireshark.app/Contents/MacOS/Wireshark -k -i - +``` + +Wireshark/TCPdump on host for port 1812, 1813, 2083, 3802\. +User on host must have “sudo nopasswd” privileges. + +Look for: + +- Username AVP must have hellohelium.com realm +- NAS-ID AVP must be formatted exactly as submitted during onboarding +- Check ports are 1812 for authentication and 1813 for accounting +- Ensure the TCP connections are established on 2083 and 3802 diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-cambium-cnmaestro.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-cambium-cnmaestro.mdx new file mode 100644 index 000000000..5ffb9f5f5 --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-cambium-cnmaestro.mdx @@ -0,0 +1,205 @@ +--- +id: helium-plus-cambium-cnmaestro +title: Cambium cnMaestro Conversion Guide +pagination_label: Cambium cnMaestro Conversion Guide +sidebar_label: Cambium cnMaestro +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-cambium-cnmaestro +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- This guide assumes the network is using the **cnMaestro Cloud Controller**. +- The Cambium system has AP(s) linked to the cnMaestro Controller. +- The Cambium system already has basic traffic routing working with existing SSIDs. +- An **Intel-based host** is required in the network to run the + [RadSecProxy](https://github.com/novalabsxyz/radsec-proxy) container. + +# High Level Steps + +1. Deploy RadSecProxy container and record IP address of host +2. Create AP Group +3. Build WLAN Helium Passpoint SSID +4. Configure AAA Servers +5. Add the NAS-ID to the WLAN AAA Policy +6. Configure Passpoint and 3GPP Carrier Info +7. Assign APs to the new Group + +## Deploy RadSecProxy Container + +RADIUS messages used to authenticate users and for session accounting are transmitted unsecured and +over UDP by default. By directing these messages internally within your secure network to a +**RadSecProxy**, UDP traffic is converted to a **TLS-protected TCP connection** to the Helium +Network core AAA servers. + +### Prerequisites + +- Intel-based machine with **Docker** installed. +- The host has a **private IP address** reachable from your cnMaestro controller. +- ACLs or firewalls allow cnMaestro and the Docker container to communicate via UDP on ports + **1812** (auth) and **1813** (accounting). + +### Container Deployment + +Unzip and untar the Helium RadSec Docker package: + +```bash +tar -xvzf Helium_RadSec_Docker.tar.gz +``` + +This will unpack: + +- `Dockerfile` — Docker build instructions +- `radsecproxy.conf` — preconfigured to connect to Helium AAA servers +- `docker-compose.yml` — to start/stop the container as a daemon + +Copy the three Helium-provided certificates into the same directory: + +- `ca.pem` — root CA certificate +- `cert.pem` — user certificate +- `key.pem` — private key paired with the certificate + +Start the container: + +```bash +sudo docker compose up -d +``` + +To stop the container: + +```bash +sudo docker compose down +``` + +## Create AP Group + +1. From the **home** view of your cnMaestro controller, go to **Configuration → Wi-Fi Profiles** + +
+ +
+ +2. In _Wi-Fi Profiles_, select **AP Groups** → **Add New**. +3. Under **Basic Settings**, scroll down and click **Create WLAN**. + +
+ +
+ +## Build WLAN + +1. In **WLAN settings** set: + + - **Name:** `Helium Enterprise` (or your preferred name) + - **WiFi-Offload type:** `Custom` + - **SSID:** `Helium` + - **Security:** `WPA3 Enterprise` + - **Client Isolation:** `Network Wide` + +
+ +
+ +2. On the left panel, go to **AAA Servers**. + +3. Under **Authentication Server**: + + - **Host:** IP of your RadSecProxy host (e.g., `192.168.1.203`) + - **Secret:** `mysecret` (must match `radsecproxy.conf` which has the default secret 'mysecret') + - **Port:** `1812` + +4. Under **Accounting Server**, repeat the steps above but set **Port = 1813**. + +5. Under **Accounting Mode**, click the drop down and select **Start-Interim-Stop** + +6. At the bottom, set **Interim Update Interval = 300**. + +7. Under **Advanced Settings → NAS-Identifier**, select **Custom** and enter the **NAS ID** provided + by the Helium team for carrier offload approval. + +8. Click **Save**. + +
+ +
+ +## Configure Passpoint + +1. Go to the **Passpoint** tab and enable it under _Basic Settings_. +2. Set **Access Network Type:** `Chargeable Public` +3. Fill in **Venue Group** and **Venue Type** with your venue details. + +4. Scroll down, under **Domain Names**, click **Add New** and enter: + + - `freedomfi.com` + +5. Under **NAI Realm List**, click **Add New**: + + - **Name:** `freedomfi.com` + - **Method:** `EAP-TLS` + - **Authentication:** `Credential Type → Certificate` + - Click **Save** + + Add new again for the next NAI Realm: + + - **Name:** `hellohelium.com` + - **EAP:** `2` + - **Method:** `EAP-TLS` + - **Authentication 1:** `Credential Type → Certificate` + - Click **Save** + +
+ +
+ +7. Save the configuration again. + +8. Scroll down to **IP Address Type Information**: + - **IPv4 Type:** `Double NAT` + - **IPv6 Type:** `Not Available` + +
+ +
+ +## Assign the WLAN to the AP Group + +1. Go to **Monitor and Manage → AP Groups** +2. Select your new AP group `Helium` +3. Go to the **Configuration** tab. +4. Scroll down to **WLAN** add the `Helium Enterprise` WLAN we created if it's not already there. + +
+ +
diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-fortinet.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-fortinet.mdx new file mode 100644 index 000000000..217b5398f --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-fortinet.mdx @@ -0,0 +1,186 @@ +--- +id: helium-plus-fortinet +title: Fortinet Conversion Guide +pagination_label: Fortinet Conversion Guide +sidebar_label: Fortinet +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-fortinet +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +### Prerequisites + +**On an Intel-based Machine with Docker Installed:** + +- The Intel-based machine has a private IP in your network reachable from your Fortinet FortiGate + box. +- ACLs or Firewalls allow Fortinet FortiGate box and Docker Container to communicate UDP on port + 1812 and 1813. +- ACLs or Firewalls allow container/host to reach the internet on TCP ports 2083 and 3802. + +#### RadSecProxy Container Deployment + +1. Un-zip and untar the [`Helium_RadSec_Docker.tar.gz`](https://github.com/novalabsxyz/radsec-proxy) + file into the directory of your choice on the host machine. + +```shell +tar -xvzf Helium_RadSec_Docker.tar.gz +``` + +This will unpack the following items: + + 1. Dockerfile - The docker instructions on how to build the container + 1. Radsecproxy.conf - The radsecproxy config file is pre-populated to connect to Helium Network AAA servers + 1. docker-compose.yml - File to start and stop the container as a daemon. + +Into the same directory, copy the 3 certificates obtained from Helium + +- ca.pem - the root CA certificate +- cert.pem - the user certificate +- key.pem - the key file matched to the certificate + +Start the container using `sudo docker compose up -d`. If/when needed, stop the container using: +`sudo docker compose down`. + +### Configure Fortinet FortiGate + +On the FortiGate CLI with FortiOS 7.0.2+ + +1. Add the local RadSecProxy as the RADIUS server by replacing the \ to the + current RadSecProxy container IP address. Also, use the NAS ID used during onboarding to Helium + for \ + +```shell +config user radius + edit "Helium RadSecProxy" + set server "" + set secret mysecret + set nas-id-type custom + set nas-id "" + set radius-coa enable + set radius-port 1812 + config accounting-server + edit 1 + set status enable + set server "" + set secret mysecret + set port 1813 + next + end + next +end +``` + +2. Set the type of IP address available to subscribers connecting to your Hotspot 2.0 network. + +```shell +config wireless-controller hotspot20 anqp-ip-address-type + edit "ipv4-single-NATed-private" + set ipv4-address-type single-NATed-private + next +end +``` + +3. Define a Venue Name and configure its duple by replacing \ to the desired value. + +```shell +config wireless-controller hotspot20 anqp-venue-name + edit "" + config value-list + edit 1 + set value "" + next + end + next +end +``` + +4. Define “Helium” as the Operator Name. + +```shell +config wireless-controller hotspot20 h2qp-operator-name + edit "Helium" + config value-list + edit 1 + set value "Helium" + next + end + next +end +``` + +5. Add Helium Mobile's NAI Realms. + +```shell +config wireless-controller hotspot20 anqp-nai-realm + edit "Helium_NAI_Realm" + config nai-list + edit "freedomfi.com" + set nai-realm "freedomfi.com" + config eap-method + edit 1 + set method eap-tls + config auth-param + edit 1 + set id credential + set val cred-certificate + next + end + next + end + next + edit "hellohelium.com" + set nai-realm "hellohelium.com" + config eap-method + edit 1 + set method eap-tls + config auth-param + edit 1 + set id credential + set val cred-certificate + next + end + next + end + next + end + next +end +``` + +6. Configure the Passpoint Profile by linking the previously added NAI Realms, 3GPP Cellular + Networks, and the type of IP address available to subscribers connecting to your Hotspot 2.0, + among other parameters. + +```shell +config wireless-controller hotspot20 hs-profile + edit "Helium" + set access-network-type chargeable-public-network + set access-network-internet enable + set venue-group business + set domain-name "freedomfi.com" + set venue-name "" + set nai-realm "Helium_NAI_Realm" + set ip-addr-type "ipv4-single-NATed-private" + next +end +``` + +7. As the final step, set a Virtual Access Point (VAP) by linking the previously added “Helium + RadSecProxy” RADIUS server, and the “Helium” Passpoint Profile, among other parameters. + +```shell +config wireless-controller vap + edit "Helium" + set ssid "Helium" + set security wpa2-only-enterprise + set auth radius + set radius-server "Helium RadSecProxy" + set intra-vap-privacy enable + set schedule "always" + set hotspot20-profile "Helium" + next +end +``` diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-generic.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-generic.mdx new file mode 100644 index 000000000..003b2dfe3 --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-generic.mdx @@ -0,0 +1,86 @@ +--- +id: helium-plus-generic +title: General Network Conversion Guide +pagination_label: General Network Conversion Guide +sidebar_label: General Conversion Guide +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-generic +--- + +This guide provides a high-level, brand-agnostic walkthrough of how to set up Hotspot 2.0 +(Passpoint) for Helium. While specific steps vary across vendors—Aruba, Cisco Meraki, Ruckus, +Fortinet, Extreme, Ubiquiti, etc.—the setup follows the same general workflow: + +### 1. Hotspot 2.0 / Passpoint Enablement + +1. **Enable the Feature**: Look for a toggle or option labeled "Hotspot 2.0," "Passpoint," or + "HS2.0" on your AP or WLAN controller. +2. **NAI Realms**: For Helium Mobile, two realms must be configured: + - `freedomfi.com` (EAP Method: `EAP-TLS`, Sub-Methods: `Certificate`) + - `hellohelium.com` (EAP Method: `EAP-TLS`, Sub-Methods: `Certificate`) + +### 2. SSID Profile + +1. **Create a New SSID** (e.g., named `Helium`) or modify an existing one. +2. **Security**: Configure WPA3-Enterprise for 802.1X/EAP. +3. **Passpoint Advertising**: Under advanced or manual settings, enable Hotspot 2.0/Passpoint mode. +4. **Venue & Network Type**: Some platforms allow specification of a venue name/type. Use + `Chargeable Public Network` as type. +5. **IP Address Type Availability**: If the controller supports it, set IPv4 to + `Double NATed private IPv4` and IPv6 to `Unavailable`. +6. **Add Realms**: Input `freedomfi.com` and `hellohelium.com` with EAP Method `EAP-TLS` and + Sub-Method `Certificate`. +7. **Domain List**: Include the domain names `freedomfi.com` and `hellohelium.com` in the domain + list. If there are existing Passpoint configurations, the Helium domains may be omitted in favor + of those domains. +8. **NAS-ID**: Enter the NAS-ID used during Helium Self-Serve or Helium Plus onboarding. Typically + the MAC address of the network controller or an AP on the onboarded network. + +### 3. AAA and RADIUS / RadSec Integration + +Hotspot 2.0 deployments with Helium use RADIUS over TLS (RadSec) for secure authentication. + +1. **Create RADIUS Profile**: RadSec (RADIUS over TLS) must be supported, or the network must have + the ability to run a RadSec proxy within it. + +- Enable TLS and upload the **Client Certificate**, **Private Key**, and **CA Certificate** provided + by the Helium Self-Serve onboarding or Helium Plus representative. +- Enter the **RadSec Servers** and shared secrets: + - `52.37.147.195:2083` (Shared Secret: `radsec`) + - `44.229.62.214:2083` (Shared Secret: `radsec`) + - `44.241.107.197:2083` (Shared Secret: `radsec`) +- Enable **RADIUS Accounting** and configure the same servers. + - `52.37.147.195:2083` (Shared Secret: `radsec`) + - `44.229.62.214:2083` (Shared Secret: `radsec`) + - `44.241.107.197:2083` (Shared Secret: `radsec`) +- Set an **Interim Update Interval** of 300 seconds. + +### 4. Network & Firewall Rules + +1. **Domains & Ports**: Whitelist or allow traffic to any AAA endpoints used by the network. RadSec + uses TCP port `2083`. +2. **Walled Garden**: If the controller enforces pre-auth access, ensure Helium IP ranges are + reachable during AAA transactions. + +### 5. VLAN Assignments + +1. **Designate VLAN**: Decide which VLAN or subnet handles Passpoint traffic. Provide DHCP, DNS, and + other essential services. +2. **Isolation**: Follow best practices to segment Hotspot 2.0 traffic from internal resources. + +### 6. Testing + +1. **Client Device**: Use a smartphone or laptop known to support Hotspot 2.0. It should discover + and automatically connect to the newly configured SSID. +2. **Logs & Controller**: Review logs for successful EAP authentication events. +3. **Connectivity**: Verify that a connected device obtains the expected IP address, can access the + internet, and is properly accounted for in RADIUS logs. + +## Best Practices + +- **Keep AP Firmware Updated**: Use a version that fully supports Passpoint (HS2.0) features. +- **Segment Traffic**: A dedicated VLAN or subnet for Passpoint traffic enhances security. +- **Test Multiple OSes**: Different end-user devices can behave differently with Passpoint. +- **Monitor Logs**: Authentication or certificate issues typically appear in RADIUS or controller + logs. diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-juniper-mist.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-juniper-mist.mdx new file mode 100644 index 000000000..c6c463a08 --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-juniper-mist.mdx @@ -0,0 +1,202 @@ +--- +id: helium-plus-juniper-mist +title: Juniper Mist Conversion Guide +pagination_label: Juniper Mist Conversion Guide +sidebar_label: Juniper Mist +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-juniper-mist +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- Juniper Mist system running the latest firmware. +- Juniper Mist Access Points (APs) linked to the Mist Dashboard. +- Basic traffic routing working with existing SSID(s). +- ACLs or firewalls allow Juniper Mist APs to communicate over TCP ports **2083** RadSec. +- Access to the cloud‑hosted Juniper Mist Dashboard. + +## High‑Level Steps + +1. Build a Helium Passpoint SSID on Juniper Mist. + + 1. Create a new SSID. + 2. Configure Passpoint settings. + 3. Add RadSec servers. + +2. Apply the configuration to your sites and access points. +3. Verify operation and troubleshoot as needed. + +# Configure Juniper Mist for Helium Mobile + +To begin, sign in to the Juniper Mist Dashboard at +[https://manage.mist.com](https://manage.mist.com). + +## Create a New SSID + +1. Navigate to **Organization → WLAN Templates**. +2. Click **Create WLAN Template** or select an existing template. +3. Click **Add WLAN** to create a new SSID. + +**Required settings** + +| Field | Value | +| ------------- | ----------------- | +| **SSID Name** | `Helium` | +| **Security** | `WPA3‑Enterprise` | +| **Passpoint** | **Enable** | + +
+ +
Juniper Mist WLAN Settings
+
+
+ +## Configure Passpoint Settings + +In the WLAN settings locate the **Passpoint** section and set: + +- **Venue Name**: _(The Venue name or the name provided by the Helium Plus team)_ + +### Advanced Settings + +- **Domain Name**: `freedomfi.com` + +### NAI Realms + +- `freedomfi.com (EAP‑TLS)` +- `hellohelium.com (EAP‑TLS)` + +
+ +
+
+ +## Add RadSec Servers + +1. Under **Authentication Servers**, choose RadSec from the dropdown. +2. In the **Server Name** field, enter `radius.stage.wifi.freedomfi.com` +3. Click **Add Server** under **Server Addresses** and enter: + + | Field | Value | + | ------------ | --------------- | + | **hostname** | `44.229.62.214` | + | **Port** | `2083` | + + Repeat this process for Helium's RadSec servers `52.37.147.195` and `44.241.107.197` + +4. **NAS Identifier**: use either a static MAC address (e.g. `a8:53:7d:0b:fb:d0`) or the token + `{{DEVICE_MAC}}` to insert the AP’s MAC address. + This NAS Identifier must match the identifier used during onboarding through self-serve or Helium + Plus. + +
+ +
+ +## Other WLAN Settings + +These instructions include the minimum steps required to authenticate a client via the Helium +network. Most venue operators will want to take additional security precautions, such as placing +Helium clients into their own VLAN / subnet which is segmented from other WLANs. The steps to +accomplish this are outside the scope of this document, but should be considered achieve a healthy +security posture for both the venue operator and mobile users. + +## Upload Certificates + +Save the three certificates obtained from the Helium Network into a directory for safekeeping and +reference. + +- `ca.pem` – Root CA certificate +- `cert.pem` – User certificate +- `key.pem` – Private key matching **cert.pem** + +The keys may have different file names depending on their source. + +First add the root CA in 3 parts: + +1. Navigate to **Organization** > **Settings** +2. Under **RadSec Certificates**, click the **Add a RadSec Certificate** link +3. Open the CA file in a text editor; note that it contains **three** separate CA certs. +4. Copy and paste the **first** CA cert, including the **-----BEGIN CERTIFICATE-----** and + **-----END CERTIFICATE-----** header and footer into the text box, and click the **Add** button. +5. Repeat this process for the other two CA certs in the file. + +
+ +
+
+ +Next add the Cert and Key + +1. Under **AP RadSec Certificate**, click the **View Certificate** link. +2. Open the key.pem (or similarly named) file in a text editor, then copy and paste the contents + into the **Private Key** field +3. Open the cert.pem (or similarly named) file in a text editor, then copy and paste the contents + (including the header & footer) into the **Signed Certificate** field + +NOTE: you may need to delete existing keys and certs that in boxes when you open this popup. If +wanted you can save these to a local file on your computer in case you need them in the future. + +
+ +
+
+ +4. Apply / Save as applicable + +## Apply the Configuration + +1. Navigate to **Sites** and select the desired site. +2. Assign the updated **WLAN Template** to the site. +3. Click **Apply Changes** to push the configuration to all APs. + +# Verify Configuration + +- Confirm that the **Helium** SSID is broadcasting on your Juniper Mist APs. +- Connect a Passpoint‑enabled device and verify authentication through RadSecProxy to the Helium + Network. +- In the Mist Dashboard under **Clients**, ensure that client sessions are active. + +
+ +
+ +## Troubleshooting + +| Symptom | Checks | +| --------------------------- | --------------------------------------------------------------------------------------------------------- | +| **SSID not broadcasting** | Verify the WLAN Template is assigned and pushed; confirm AP connectivity to the Mist Dashboard. | +| **Certificate errors** | Confirm the AP trusts the RADIUS certificate and the AAA trusts the RadSec client certificate. | +| **Clients fail to connect** | Check Passpoint parameters; verify device support for Passpoint; confirm Helium AAA approves the request. | + +## Notes + +- Juniper Mist does not list Helium as a Passpoint Operator. Use preset Passpoint Operator + configurations only after receiving approval from the Helium Plus team. diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-meraki.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-meraki.mdx new file mode 100644 index 000000000..6d212627d --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-meraki.mdx @@ -0,0 +1,228 @@ +--- +id: helium-plus-meraki +title: Meraki Conversion Guide +pagination_label: Meraki Conversion Guide +sidebar_label: Meraki +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-meraki +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- Meraki system must be running + [14.0](https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ) + or later. +- Guide assumes the network is using an on-prem Meraki MX Controller. +- Meraki system has AP(s) linked to the MX Controller. +- Meraki system has basic traffic routing working with existing SSID(s). +- An Intel-based host is required in the network to run the + [RadSecProxy](https://github.com/novalabsxyz/radsec-proxy) container. + +# High Level Steps + +1. Deploy RadSecProxy container and record IP address of host +2. Build Meraki Helium Passpoint SSID + 1. Build a new SSID + 2. Configure SSID to use RADIUS + 3. Build Hotspot 2.0 Profile + +# Deploy RadSecProxy Container + +RADIUS messages used to authenticate users and for session accounting are transmitted unsecured and +over UDP by default. By directing these messages internally in your secure network to a RadSecProxy, +the UDP is then converted to a TLS protected TCP connection to the Helium Network core AAA servers. + +## Prerequisites + +- An intel based machine with Docker installed. +- The intel based machine has a private IP in your network reachable from your Meraki Mobility + Controller +- ACLs or Firewalls allow Meraki Mobility Controller and Docker Container to communicate UDP on port + 1812 and 1813 +- ACLs or Firewalls allow container/host to reach the internet on TCP ports 2083 and 3802\. + +## Container Deployment + +1. Un-zip and untar the `Helium_RadSec_Docker.tar.gz` file into the directory of your choice on the + host machine. This will unpack the following items: + 1. `Dockerfile` \- The docker instructions on how to build the container + 2. `Radsecproxy.conf` \- The radsecproxy config file is pre-populated to connect to Helium + Network AAA servers + 3. `docker-compose.yml` \- File to start and stop the container as a daemon. + +```bash +tar -xvzf Helium_RadSec_Docker.tar.gz +``` + +2. Into the same directory copy the 3 certificates obtained from Helium Network + 1. ca.pem \- the root CA certificate + 2. cert.pem \- the user certificate + 3. key.pem \- the key file matched to the certificate +3. Start the container using: + +```bash +sudo docker compose up -d +``` + +4. If/when needed, stop the container using: + +```bash +sudo docker compose down +``` + +# Build Meraki Helium Passpoint SSID + +The following steps will configure your Meraki system to broadcast an SSID with the needed Passpoint +and RADIUS configurations to support Helium Mobile user offload. + +To start login to your Meraki Dashboard in your browser, this will be our starting point for all +major steps below + +
+ +
+
+ +:::note + +In the following steps we will only mention mandatory fields to set. Most windows will have many +other parameters with default values set. Leave any unmentioned parameter at it's default value. + +::: + +## Build a new SSID + +1. Click on **Wireless** and then **SSID** in the left menu column + +
+ +
+ +2. Look for a “**Unconfigured SSID X**” +3. Click on **rename** +
+ +
+4. Enter “**Helium**” +5. Select **Enabled** +6. Click **Save Changes** + +## Configure Helium SSID for RADIUS Access Control + +:::note + +Helium is aware that Meraki has some native support for RadSec. Unfortunately, the Meraki +implementation is not scalable for a network like Helium. Meraki builds a CA certificate specific to +each group of APs and ask for it to be loaded on the AAA. That does not scale and there is no way to +load the client certificate and key Helium produces during onboarding into the Meraki RadSec client. +So for now the guide below uses our RadSecProxy container and plain RADIUS configuration on the +Meraki devices. + +::: + +1. Click **Edit Settings** +2. Under **Security** heading toggle the circle **Enterprise with** +3. Select **my RADIUS Server** +
+ +
+4. Scroll down to **RADIUS** and click the arrow on the right to expand +5. Click add server and add the following configurations + 1. Enter IP Address: **\** Port: **1812** Secret: + **mysecret**. Click **Done**. + 2. Add a second server if desired for HA redundancy. +
+ +
+6. Repeat those steps to add the same server to the RADIUS Accounting Servers list using **port + 1813\.** +
+ +
+7. Select the check box next to **Radius CoA Support** +
+ +
+8. Click on the arrow to expand the **Advanced RADIUS settings** section +9. Change the number 1 drop down for **NAS ID** to **Custom** and enter the NAS-ID you got during + onboarding +10. Click the **×** to remove number 2 in that list which says **SSID Number** +
+ +
+11. Click **Save** + +## Build Hotspot 2.0 Config + +1. Click on **Wireless** and navigate to **Hotspot 2.0** +
+ +
+2. Change the toggle for **Hotspot 2.0** to **Enabled** +3. Enter **Operator Name** to be “**Helium**” +4. Enter **Venue Name** to be the street address of your location +5. Choose the best fitting **Venue Type** from the drop down +6. Choose **Chargeable public network** from the drop down +7. In domain list enter both **FreedomFi.com** and **Hellohelium.com** +8. Click **Create Realm** + 1. Enter **freedomfi.com** as the name + 2. Select **Add EAP Method** + 3. Select **Method ID** to be **13 EAP-TLS** + 4. Select **Authentication Methods** to be **Certificate** under + 5. Click **Create realm** +
+ +
+9. Repeat for realm name **Hellohelium.com** with matching settings. +10. Final Hotspot 2.0 settings should look like this: +
+ +
+11. Click **Save Changes** diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-mikrotik.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-mikrotik.mdx new file mode 100644 index 000000000..c6810f1ed --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-mikrotik.mdx @@ -0,0 +1,171 @@ +--- +id: helium-plus-mikrotik +title: MikroTik Conversion Guide +pagination_label: MikroTik Conversion Guide +sidebar_label: MikroTik +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-mikrotik +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- **RouterOS v7** device running CAPsMAN 2 (tested on **7.18.1**) +- [RadSecProxy](https://github.com/novalabsxyz/radsec-proxy) container running in your network. +- For self-serve, CLI wallet prepared for onboarding: + [https://docs.helium.com/mobile/helium-plus-onboarding/](https://docs.helium.com/mobile/helium-plus-onboarding/) +- For Helium Plus, certificates ( `ca.pem`, `cert.pem`, `key.pem` ) supplied by the Helium Plus team + and copied into the RadSecProxy directory. +- UDP ports **1812/1813** open between MikroTik and the RadSecProxy host. +- Bridge interface already created and used as the datapath for Wi-Fi traffic. + +## High-Level Steps + +1. Deploy the RadSecProxy container and note its IP. +2. Create a **RADIUS** profile that points to the RadSecProxy. +3. Build a **Wi-Fi configuration profile** for the Helium Passpoint SSID. +4. Apply the profile to an interface (or create a virtual AP). +5. Verify operation and troubleshoot, if necessary. + +### 1. Deploy RadSecProxy + +At time of writing, RouterOS does not support RadSec natively, download the +[RadSecProxy](https://github.com/novalabsxyz/radsec-proxy) container and run it in a Docker. + +1. Un-zip and untar the `Helium_RadSec_Docker.tar.gz` file into the directory of your choice on the + host machine. This will unpack the following items: + 1. `Dockerfile` \- The docker instructions on how to build the container + 2. `Radsecproxy.conf` \- The radsecproxy config file is pre-populated to connect to Helium + Network AAA servers + 3. `docker-compose.yml` \- File to start and stop the container as a daemon. + +```bash +tar -xvzf Helium_RadSec_Docker.tar.gz +``` + +2. Into the same directory copy the 3 certificates obtained from Helium Network + 1. `ca.pem` \- the root CA certificate + 2. `cert.pem` \- the user certificate + 3. `key.pem` \- the key file matched to the certificate +3. Start the container using: + +```bash +sudo docker compose up -d +``` + +4. If/when needed, stop the container using: + +```bash +sudo docker compose down +``` + +Once the container is running, make sure you can **ping** it from the MikroTik router. + +### 2. Add a RADIUS Profile + +In **RADIUS** add a new entry: + +| Field | Value | +| ----------------------- | ------------------- | +| **Comment** | `Helium AAA` | +| **Service** | `wireless` | +| **Address** | _IP_of_RadSecProxy_ | +| **Protocol** | `udp` | +| **Secret** | `mysecret` | +| **Authentication Port** | `1812` (default) | +| **Accounting Port** | `1813` (default) | +| **Timeout** | `300 s` | +| **Enabled** | ☑︎ | + +
+ +
+ +### 3. Create a AP Configuration Profile + +Navigate to **WiFi → Configuration** and click **Add (+)**. + +#### Configuration Tab + +| Field | Value | +| ----------- | ------------------ | +| **Name** | `helium-passpoint` | +| **Enabled** | ☑︎ | +| **Mode** | `ap` | +| **SSID** | `Helium` | + +#### Channel Tab + +Select the band and channel width appropriate for your deployment. Leave **Frequency** blank for +automatic channel selection. + +#### Security Tab + +Check WPA2 or WPA3 EAP under Authentication Types. + +#### EAP Tab + +Check EAP Accounting to be enabled. + +#### AAA Tab + +Paste a MAC address of the WAN interface (usually ether1 by default) from menu Interfaces. Or enter +the NAS-ID provided during Helium Plus onboarding. + +
+ +
+ +#### Datapath Tab + +| Setting | Value | +| ---------- | -------------------------------------- | +| **Bridge** | `bridge1` (or the bridge used for LAN) | + +#### Interworking Tab + +Fill in as shown: + +
+ +
+ +### 4. Attach the Profile to an Interface + +Assign the configuration profile to the desired WiFi interface. Either click **New** (this will +create a virtual AP) or **Edit** an existing master interface. + +Make sure to select a correct 5/2.4 interface according to the band defined in the configuration +profile. + +Enable it on the General tab. + +
+ +
+ +### 5. Verification + +- Confirm that the `Helium` SSID is visible. +- In logs, watch for successful `radius` authentication messages. +- On the RadSecProxy host use `docker logs -f radsecproxy` to ensure TCP/TLS sessions are + established. +- On a compatible handset, ensure automatic connection with the carrier profile. diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-onboarding.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-onboarding.mdx new file mode 100644 index 000000000..07f0b759f --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-onboarding.mdx @@ -0,0 +1,120 @@ +--- +id: helium-plus-onboarding +title: Onboard Converted Networks +pagination_label: Onboard Converted Networks +sidebar_label: WiFi Conversion Onboarding +description: Helium Network Conversion Onboarding Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-onboarding +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + +
+
+ +WiFi networks onboarded to Helium are eligible to earn HNT for handling carrier traffic. + +At this time, only [Helium Mobile](https://hellohelium.com/) traffic is rewardable on networks +onboarded through self-serve tooling. If you are interested in handling other carrier traffic +through your commercial or other high-traffic deployment, please use the +[Helium Plus](https://www.helium.com/plus) program. + +## Considerations for Entity Creation + +Each Mobile network onboard will represent a single pin on the coverage map, regardless of how many +Hotspots (APs) it may contain. The entity representing this network will also hold any rewards +earned from data transfer until they are claimed. When considering entity creation, try to constrain +the scope of the onboarded deployment to the size of one building or smaller. + +Self-serve onboards will be counted as a single Hotspot in Helium Network metrics. Networks +onboarded through the Helium Plus program carry additional metadata which represents the total +number of Hotspots in a given deployment. For large network deployments, please use the Helium Plus +program. + +## Prepare Wallet + +Download and configure the [Helium Wallet CLI](/wallets/cli-wallet) with a new or existing Solana +account. The following steps require Helium Wallet CLI `2.1.1` or newer. + +Onboarding a new WiFi Network requires a token fee per network or location. Ensure the account has +these minimum balances. + +| Token | Amount | | +| ----------------------------------- | --------------- | -------------------------------------------- | +| [Data Credits](/tokens/data-credit) | 200,000 ($2.00) | Mobile entity onboarding cost. | +| [SOL](/tokens/sol-token) | ~0.005 | Solana blockchain fees and NFT creation.[^1] | + +[^1]: + _At the time of writing, onboarding required 0.003778 SOL; however, the fee will fluctuate based + on network conditions._ + +## Create and Onboard Networks + +The process for converting a network begins by generating a Hotspot key and then creating and +onboarding a Rewardable Entity NFT using the Helium Wallet CLI. + +Create the Hotspot key by creating an onboarding token: + +```sh title="Generate an onboarding token." +helium-wallet hotspots add mobile token +``` + +The `token` command will return a response looking like this: + +```json {6} title="Example generated entity and token." +{ + "hotspot": { + "key": "14WaYzPtgvs3sranGNBxTSj9d4f36J6c6mjRWKqRwDr8NirmrmL", + "name": "recumbent-menthol-porcupine" + }, + "token": "CmUSIQHOP/T3SOWXnjrAZXyJ5CWmQChywBmpyigcLjNVr+nMJSONJexLDs1m61BLVetCqcXla0DmOWZVUORYBn4ya9gv0jy8pz8Av4JgnZzrJlp/9bskEZ4lIYjQVObuwh+54DlTAQ==" +} +``` + +Use the "token" value (highlighted above) along with the Hotspot's physical latitude and longitude +to assert its location to the network. A utility such as [latlong.net](https://www.latlong.net/) is +helpful for looking up coordinates. + +```sh title="Onboard the Rewardable Entity (Hotspot)" +helium-wallet hotspots add mobile onboard --lat=37.779930 --lon=-122.387906 --commit +``` + +The command prompts for the CLI wallet password, signs the transaction, and submits it to the +blockchain. A result will print as a successful transaction hash. + +If any errors are returned during the onboarding, double check token balances and retry the +onboarding transaction. + +## Hotspot RADIUS Certificates + +The last step is to create the certificates for the Hotspot. Certificates are created uniquely for +each onboard. + +```sh +helium-wallet hotspots add mobile cert --nas-id xx:xx:xx:xx:xx --address "South Beach Yacht Club, 899 2nd St, San Francisco, CA 94107" +``` + +`` is the key from first step (e.g. `14Wa...mrmL`). + +`--nas-id` must match the NAS-ID being broadcast from the SSID. Use a MAC address from the onboarded +network as the NAS-ID. + +`--address` should best represent the installed location of the network. If a business, include the +business name. If residential, a street address is sufficient. + +This command will create the Hotspot certs and save them in the active directory. + +```json title="Certificate response delivered from the CLI command." +{ + "expiration": "2028-02-21T23:10:51Z", + "private_key": "14WaYzPtgvs3sranGNBxTSj9d4f36J6c6mjRWKqRwDr8NirmrmL.pk", + "certificate": "14WaYzPtgvs3sranGNBxTSj9d4f36J6c6mjRWKqRwDr8NirmrmL.cer", + "ca_chain": "data-only.ca" +} +``` + +When the `cert` command is executed with both the NAS-ID and address, any existing certificates for +the specified Hotspot are retrieved. Should certificate files already exist in the active directory, +the command returns an error; the `--force` flag may be used to overwrite existing files. diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-radsecproxy.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-radsecproxy.mdx new file mode 100644 index 000000000..f96f6691b --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-radsecproxy.mdx @@ -0,0 +1,126 @@ +--- +id: helium-plus-radsecproxy +title: RadSecProxy for Converted Networks +pagination_label: RadSecProxy for Converted Networks +sidebar_label: RadSecProxy +description: RadSecProxy for Converted Networks Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-radsecproxy +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + +
+
+ +# RadSecProxy + +radsecproxy is a generic open source RADIUS proxy that in addition to usual RADIUS UDP transport, +also supports TLS (RadSec) + +The project can be found at [https://radsecproxy.github.io/](https://radsecproxy.github.io/) + +Helium makes a preconfigured and containerized version of this project available at +[https://github.com/novalabsxyz/radsec-proxy](https://github.com/novalabsxyz/radsec-proxy) + +## Hardware Requirements + +RadSecProxy is designed to be lightweight at not require many hardware resources as it scales. Below +are suggested hardware specs that will support small (10's of WiFi APs) to medium (up to 1000 APs) +deployments. + +- Quad core CPU e.g. Intel i5 or better +- 2 GB RAM minimum, 4GB for bigger deployments +- 1.25 GB free disk space +- Docker supporting OS (Windows, MacOS, Linux) +- 1 Gbps Ethernet port +- RadSecProxy typically uses ports 2083 and 443 for RadSec communication. +- Ensure these ports are open and accessible outbound from the proxy. +- If using RADIUS/TLS, also ensure ports 1812 (UDP/TCP) and 1813 (UDP for accounting) are open. + +# Local Deployment Options + +The typical deployment used by converted Helium networks is to deploy an instance of RadSecProxy +locally within the deployer controlled network. This can take two forms depending on the how the +deployer controlled network is structured. + +## Secured Remote Sites - Local + +
+ +
+
+ +In this deployment model the Deployer has existing secure links between it's remote sites and a +central office where common infrastructure is housed. In this case, the RADIUS from WiFi APs at the +remote sites is secured back to central office where an instance of RadSecProxy can be deployed. +This one instance of RadSecProxy can then be used by all the APs in remote sites 1 - 4. + +## Unsecured Remote Sites - Local + +
+ +
+
+ +In this deployment model the Deployer has multiple remote sites, each of which are connected +directly to the internet with no secure link back to a central office location. In this scenario an +instance of RadSecProxy can be deployed locally at each site to securely proxy RADIUS traffic to +Helium over the open internet. + +# Cloud Deployment Options + +If the deployer is unable to deploy an instance of RadSecProxy locally using the options above, +another option is to purchase access to a cloud instance of RadSecProxy hosted by Helium. In this +deployment model each deployer site must be connected via IPsec VPN to the count instance to ensure +safe transport of unencrypted RADIUS to the proxy. + +## Secured Remote Sites - VPN + +
+ +
+
+ +In this deployment model the Deployer has existing secure links between it's remote sites and a +central office where common infrastructure is housed. However the deployer is unable to deploy a +local instance of RadSecProxy. Instead the Deployer can purchase access to a cloud hosted instance +of RadSecProxy managed by Helium. The deploy then establishes an IPsec based VPN link to the cloud +RadSecProxy. + +## Unsecured Remote Sites - VPN + +
+ +
+
+ +In this deployment model the Deployer has multiple remote sites, each of which are connected +directly to the internet with no secure link back to a central office location. In this scenario the +deployer can purchase access to a cloud hosted instance of RadSecProxy managed by Helium. Each site +is then connected to the cloud instance using an IPsec VPN to secure the link. diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-ruckus.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-ruckus.mdx new file mode 100644 index 000000000..2170b44b2 --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-ruckus.mdx @@ -0,0 +1,347 @@ +--- +id: helium-plus-ruckus +title: Ruckus Conversion Guide +pagination_label: Ruckus Conversion Guide +sidebar_label: Ruckus +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-ruckus +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Prerequisites + +- Ruckus SmartZone must be running version 6.1 or later +- Guide assumes SmartZone Ruckus Mobility Controller +- Ruckus system has AP(s) linked to your SmartZone Controller +- Ruckus system has basic traffic routing working with existing SSID(s) + +# High Level Steps + +1. Build Ruckus Helium Passpoint SSID + 1. Install Certs + 2. Setup RadSec Proxy + 3. Configuration HS2.0 Profile + 4. Build New SSID + +# Build Ruckus Helium Passpoint SSID + +The following steps will configure your Ruckus system to broadcast an SSID with the needed Passpoint +and RADIUS configurations to support Helium Mobile user offload. + +To start login to your Ruckus Dashboard in your browser, this will be our starting point for all +major steps below + +
+ +
+
+ +:::note + +In the following steps we will only mention mandatory fields to set. Most windows will have many +other parameters with default values set. Leave any unmentioned parameter at it's default value. + +::: + +## Install RadSec Certs: + +1. Click on **Administration\>System\>Certificates\>SZ Trusted CA Certificates/Chain(External)** + +
+ +
+
+ +2. Click **Import** +3. Load the **interim.pem, ca.pem,** and **root.pem** certificates from your local directory. + +
+ +
+
+ +4. Click **Validate** then **OK** +5. Next on sub-menu bar select **SZ as Client Certificate** tab + +
+ +
+
+ +6. Click **import** +7. Enter **Name** as **Helium_radsec_client** +8. Add **cert.pem** and **key.pem** +9. Click **Validate** then **OK** + +
+ +
+
+ +## Configure RadSec Authentication Proxy: + +1. Click on **Security\>Authentication\>Proxy(SZ Authenticator)** + +
+ +
+
+ +2. Click on **Create** +3. Fill in **Helium_Radsec** as **Name** +4. Click the toggle **Encryption** to **TLS On** +5. Enter **CN/SAN Identity** as **radius.stage.wifi.freedomfi.com** +6. Select **Client Certificate** from drop down to be **Helium_radsec_client** +7. Enter **IP Address/FQDN** to be **52.37.147.195** +8. Ensure **Port** is **2083** + +
+ +
+
+ +9. Click **OK** + +## Configure RadSec Accounting Proxy: + +1. Click on **Security\>Accounting\>Proxy** + +
+ +
+
+ +2. Click **Create** +3. Enter **Name** as **Helium_radsec_acct** +4. Enable the toggle for **Encryption** to **ON TLS** +5. Enter **CN/SAN Identity** as **radius.stage.wifi.freedomfi.com** +6. Select **Client Certificate** from drop down to be **Helium_radsec_client** +7. Enter **IP Address/FQDN** to be **52.37.147.195** +8. Ensure **Port** is **2083** + +
+ +
+
+ +9. Click **OK** + +## Build Hotspot2.0 Profile: + +1. Click **Services\>Hotspots\&Portals\>Hotspot 2.0** +2. Under **Wi-Fi Operator** click **Create** + +
+ +
+
+ +3. Configure: + 1. **Name** as **Helium_Operator** + 2. Enter **Domain Name** as **FreedomFi.com** and click **\+ADD** + 3. Repeat for **Domain Name** as **Hellohelium.com** + 4. Enter **Friendly Name** as **Helium** and click **\+ADD** +4. Click **OK** +5. Under **Identity Provider** click **Create** + 1. Fill in **Name** as **Helium_IDP** + 2. In the **Realms** section, enter **Name** as **Hellohelium.com** and click **\+Add** + 3. In the drop down for **EAP Method** select **EAP-TLS** and click Create, + +
+ +
+
+ +4. Choose **Auth Info** to be **Credential Type** and **Auth Type** to be **Certificate** and click + **OK.** + +
+ +
+
+ +5. Click **\+Add** +6. Repeat steps 5.b-5.e for Realm **FreedomFi.com** with all matching settings. + +
+ +
+
+ +6. Click Next +7. Leave online signup disabled, click Next + +
+ +
+
+ +8. In **Authentication** for both **no-match** and **unspecified**: + 1. Click on the Realm name to Select + 2. Click configure + 3. Choose Helium_Radsec from drop down + +
+ +
+
+ +9. When done you should see this: + +
+ +
+
+ +10. Repeat these steps for Accounting for both **no-match** and **unspecified**: + +
+ +
+
+ +11. Config should match this screen + +
+ +
+
+ +12. Review and make sure it matches below + +
+ +
+
+ +13. Click OK. + +## Build a new SSID + +1. Click on **Network\>Wireless LANS** +2. Select your Zone +3. Lick on **Create** +4. Name **Helium** +5. Select **Authentication Type** to be **Hotspot2.0 Access** +6. Under **Encryption** for **Method Choose WPA3** +7. **Under Hotspots 2.0 Profile** in **Hotspot 2.0 profile** click **\+** + 1. For **Name** enter **Helium** + 2. For **Operator** select **Helium_operator** + 3. For **IDP** select **Helium_IDP** click **\+Add** + 4. **Advanced** + 5. Set **Access Network Type** to **Chargeable Public Network** + 6. Select **IPv4 Double NATed private address** (or applicable to your network) + +
+ +
+
+ +8. Click **OK** and you should see configuration like the image below. + +
+ +
+
+ +9. Under **RADIUS Options** + 1. **NAS-ID \-\> User-Defined \>** enter your NAS-ID per Helium onboarding spreadsheet. + 2. For **Called Station ID** set to **AP MAC** + 3. **Enable** the toggle for **Single Session ID accounting** + +
+ +
+
+ +10. Click OK diff --git a/docs/network-mobile/helium-plus-guides/helium-plus-ubiquiti.mdx b/docs/network-mobile/helium-plus-guides/helium-plus-ubiquiti.mdx new file mode 100644 index 000000000..7dd60a3ae --- /dev/null +++ b/docs/network-mobile/helium-plus-guides/helium-plus-ubiquiti.mdx @@ -0,0 +1,216 @@ +--- +id: helium-plus-ubiquiti +title: Ubiquiti Conversion Guide +pagination_label: Ubiquiti Conversion Guide +sidebar_label: Ubiquiti +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-ubiquiti +--- + + +
+
+ +import useBaseUrl from '@docusaurus/useBaseUrl' + +Data-Only Mobile configuration requires the Passpoint protocol. Please ensure your Ubiquiti network +is using +[UniFi Network Controller version 8.4.54](https://community.ui.com/releases/UniFi-Network-Application-8-4-59/d3ba4443-ad36-4566-b1e6-2d21d8b4f225) +or higher and +[AP firmware version 6.6.77](https://community.ui.com/releases/UniFi-Access-Point-6-6-77/1368d5eb-f4d7-4861-9eae-a317e2bebce9) +or +[AP firmware version 7.0.66](https://community.ui.com/releases/UniFi-Access-Point-7-0-66/edfb7cb4-c629-4e3b-a362-549eec2e0e1b) +or higher, depending on hardware release track. + +## Obtain RadSec Certificates + +Each onboarded network requires a unique NAS-ID. For Ubiquiti networks, it is recommended to use the +MAC address of the network controller as the NAS-ID. + +Run the UniFi network controller locally or log into the cloud +[UniFi Site Manager](https://unifi.ui.com/). + +Navigate to **UniFi Devices**, choose your **Network Controller** and copy the **MAC Address**. + +
+ +
Retrieve the MAC address of the network controller.
+
+
+ +Use this NAS-ID in the [WiFi Conversion Onboarding](/mobile/helium-plus-onboarding) flow and return +to this guide after the network is onboarded and certificates have been delivered. + +:::important If updating from older RadSec certificates: + +If early access certificates were previously deployed on the network, a Ubiquiti bug may prevent new +certificates from propagating. +Restart all APs on the network after updating the certificates, and the new certificates should be +applied. + +::: + +## Configure UniFi Network Controller + +After retrieving certificates, configuring the network controller for Passpoint is a two-part +process. First, create the RADIUS profile, then apply the profile to a newly created WiFi SSID +called 'Helium'. + +
+ +
UniFi Settings screen within the UniFi Site Manager.
+
+ +### Create a RADIUS Profile + +Configure a TLS connection to Helium Cloud AAA server (aka Radiator), which performs Authentication, +Authorization, and Accounting for the end customers. Enabling RADIUS communication over TLS (RadSec) +increases the level of security for authentication that is carried out across the cloud network. + +In the sidebar, choose **Settings**, then **Profiles**, then **RADIUS**: + +
+ +
Open RADIUS profiles.
+
+
+ +Press **Create New**. + +Specify a profile name, for example "**Helium RadSec**". + +Configure RADIUS properties: + +
+ +
Configure RADIUS settings.
+
+
+ +1. Under **Radius Settings**, check the **TLS** box. + 1. Press **Upload** next to **Client Certificate**, choose the path to `cert.pem`. + 2. Press **Upload** next to **Private Key**, choose the path to `key.pem`. Keep Private Key + Password empty. + 3. Press **Upload** next to **CA Certificate**, choose the path to `ca.pem`. + +
+ +
Load the certificates from the network onboarding.
+
+
+ +2. Specify **Authentication Servers**: + + Add these three servers: + + 1. Enter IP Address: `52.37.147.195` Port: `2083` Shared Secret: `radsec`. Click **Add**. + 2. Enter IP Address: `44.229.62.214` Port: `2083` Shared Secret: `radsec`. Click **Add**. + 3. Enter IP Address: `44.241.107.197` Port: `2083` Shared Secret: `radsec`. Click **Add**. + +3. Check the **Accounting** checkbox. RADIUS Accounting Server settings will appear. + +4. Specify the following Accounting Servers: + + 1. Enter IP Address: `52.37.147.195` Port: `2083` Shared Secret: `radsec`. Click **Add**. + 2. Enter IP Address: `44.229.62.214` Port: `2083` Shared Secret: `radsec`. Click **Add**. + 3. Enter IP Address: `44.241.107.197` Port: `2083` Shared Secret: `radsec`. Click **Add**. + +5. Check **Interim Update Interval** box. +6. Specify **Interim Update Interval** with **300 Sec**, standard for the Helium Network. + +Click **Apply Changes** to create the new RADIUS Profile. + +### Create The Helium SSID + +Navigate to the **Settings** in the sidebar, choose **WiFi**, then press **Create New** + +
+ +
Create a new WiFi network.
+
+
+ +Configure settings for the new network. + +1. Set the **Name** of the SSID to `Helium`. Leave the password blank. +2. Set **Advanced** to **Manual**. +3. Set **Hotspot 2.0** to `Passpoint`. Passpoint settings will appear below. +4. Specify **Venue Name** to a name for your site. +5. Specify **Venue Type** with the option that best matches your site. +6. Set **Network Type** to `Chargeable Public Network` +7. Set **IP Address Type Availability**: + 1. IPv4 to `Double NATed private IPv4`. + 2. IPv6 to `Unavailable` +8. Add **NAI Realms** with the following two entries: + 1. Name: `freedomfi.com` EAP Method: `EAP-TLS` Sub-Methods: `Certificate`. + 2. Name: `hellohelium.com` EAP Method: `EAP-TLS` Sub-Methods: `Certificate`. +9. Add **Domain List**: `freedomfi.com` or leave your home domain, if any. Press **Add**. + +
+ +
Create a new WiFi network.
+
+
+ +10. Set **Security Protocol** to: `WPA3 Enterprise` + +11. Enter the NAS-ID used during onboarding to Helium in the **Custom** field of **NAS-ID**. + +
+ +
Identify the NAS ID using the MAC address.
+
+
+ +12. Choose **Radius Profile**: `Helium Radsec` +13. Click "Client Device Isolation" to enable secure networking. See this Ubiquiti guide on + [network and client isolation](https://help.ui.com/hc/en-us/articles/18965560820247-How-to-Implement-Network-and-Client-Isolation) + for more information. + +Press **Add WiFi Network**. + +Your Helium SSID is all set up. Verify access by forgetting the existing network on your device and +connecting to the new network using a device with a supported carrier, such as +[Helium Mobile](https://hellohelium.com). + +## Video Walkthrough + +import { YouTube } from 'mdx-embed' + + diff --git a/docs/network-mobile/helium-plus-mobile.mdx b/docs/network-mobile/helium-plus-mobile.mdx new file mode 100644 index 000000000..5446a7468 --- /dev/null +++ b/docs/network-mobile/helium-plus-mobile.mdx @@ -0,0 +1,65 @@ +--- +id: helium-plus-mobile +title: 'Convert WiFi Networks' +pagination_label: Convert WiFi Networks +sidebar_label: Introduction +description: Helium Network Conversion Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-mobile +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + +
+
+ +The network conversion process activates Passpoint-enabled hardware for cellular network data +transfer on Helium. In the cellular industry, these are known as 'Brownfield' deployments – where +existing hardware is configured to operate a new network. Converted networks continue to work with +existing SSIDs. The Helium Network configurations are additive to other configurations and do not +impact existing network function. + +Using existing infrastructure reduces costs, making it a practical solution for venue owners. When +deciding between deploying a new Hotspot (Greenfield) or converting an existing network, consider +Proof of Coverage rewards, deployment costs, and coverage needs. Both options can complement each +other in the Helium Mobile network. + +## Getting Started + +For compatible networks, integrating with Helium Mobile is simple. Start by reviewing the +manufacturer-specific guides or refer to the generic deployment reference for guidance with other +manufacturers: + +- [General Conversion Guide](/mobile/helium-plus-generic) +- [Helium Plus Security FAQ](/mobile/helium-plus-security-faq) — Security considerations and best practices for converted networks + +## Deployment Requirements + +Existing WiFi networks must have Passpoint-enabled access points, which are typically supported by +manufacturers like Ubiquiti, Cisco, and Aruba. Additionally, these access points need to integrate +with the Helium MOBILE Network to handle traffic and qualify for data transfer rewards. This +integration involves network-level configurations for authentication, authorization, and accounting. + +### Enterprise Network Considerations + +Fleets are characterized on Helium with a public on-chain key which is paired with the RADIUS +certificates. The entities created from the self-serve tooling expect each pubkey/cert pair to be +attached to a single NAS-ID. Via the [Helium Plus](http://helium.com/plus) program, multiple NAS-IDs +may be onboarded to a single certificate set. + +### RadSecProxy Deployment options + +RADIUS is a UDP protocol meant for use inside an operators secure network. RADIUS in standard form +is not meant to traverse the open internet as this would expose private user identity data to the +open internet. To address this the industry created a RADIUS over TLS protocol called RadSec. Using +RadSec RADIUS contents are encrypted and packaged into a TCP session which makes it suitable to +traverse the open internet safely. + +If your WiFi OEM does not natively support RadSec in the network you want to convert, deployers must +choose one of two main options: + +- Deploy local RadSecProxy within the deployer controlled secure domain +- Establish a secure IPsec VPN to the Helium hosted cloud RadSecProxy instance + +[More details about RadSecProxy can be found here.](/mobile/helium-plus-radsecproxy) diff --git a/docs/network-mobile/helium-plus-security-faq.mdx b/docs/network-mobile/helium-plus-security-faq.mdx new file mode 100644 index 000000000..cd8f09812 --- /dev/null +++ b/docs/network-mobile/helium-plus-security-faq.mdx @@ -0,0 +1,146 @@ +--- +id: helium-plus-security-faq +title: WiFi Conversion Security FAQ +pagination_label: WiFi Conversion Security FAQ +sidebar_label: WiFi Conversion Security FAQ +description: Security considerations and best practices for converted WiFi networks on Helium +image: https://docs.helium.com/img/link-image.png +slug: /mobile/helium-plus-security-faq +--- + +Converted (brownfield) WiFi networks use existing infrastructure to provide Helium Mobile +connectivity. While Helium manages several security features centrally, deployers retain +responsibility for network-level security at their sites. This guide explains the security model and +best practices for brownfield deployments. + +## Security Feature Comparison + +| Feature | Greenfield (HMH) | Brownfield | +| ------------------------- | ------------------ | -------------------------- | +| Protocol (WPA3) | ✅ Helium enforced | ✅ Helium enforced | +| Passpoint Authentication | ✅ Helium enforced | ✅ Helium enforced | +| Certificate Lifecycle | ✅ Helium managed | ✅ Helium managed | +| RADIUS Transport (RadSec) | ✅ Helium provided | ✅ Helium provided | +| WAN Traffic Rejection | ✅ Helium enforced | ⚠️ Customer responsibility | +| Client Isolation | ✅ Helium enforced | ⚠️ Customer responsibility | +| VLAN Isolation | — N/A (single AP) | ⚠️ Customer responsibility | + +## Features Managed by Helium + +### WPA3 and Passpoint + +Helium enforces WPA3 and Passpoint with EAP-TLS for both greenfield and brownfield deployments. The +authentication flow uses certificate-based EAP-TLS, ensuring strong encryption and mutual +authentication between client devices and the network. + +### Certificate Lifecycle + +Helium manages the certificate lifecycle for RADIUS authentication. Certificates are generated +during onboarding and must be installed on your RadSec proxy or WiFi controller. Certificate +expiration dates are provided at creation time; plan for renewal before expiration. + +### RADIUS Authentication + +Helium operates RADIUS servers that authenticate Passpoint clients. Your network sends +authentication requests over RadSec (RADIUS over TLS) to Helium's infrastructure. Both deployment +options—local RadSec proxy and Helium-hosted RadSec with VPN—ultimately deliver RADIUS traffic to +Helium over TLS. However, the encryption boundaries differ: a local proxy encrypts RADIUS at your +site, while the hosted option relies on an IPsec VPN tunnel to carry unencrypted RADIUS to the cloud +proxy, which then forwards over TLS. + +## Customer Responsibilities and Best Practices + +### VLAN Isolation + +Segment Passpoint traffic on a dedicated VLAN or subnet. Do not mix Helium Mobile traffic with +internal corporate or guest networks. This limits blast radius if a client is compromised and +prevents lateral movement between network segments. + +### Reject WAN Traffic + +Configure your network so that Passpoint clients cannot reach your internal LAN or WAN resources. +Passpoint users should only have internet access through the designated VLAN. Use firewall rules to +block access to internal IP ranges and sensitive services. + +### Client Isolation + +Enable client isolation (also called AP isolation or wireless client isolation) on the Passpoint +SSID when supported by your hardware. This prevents connected devices from communicating with each +other, reducing the risk of device-to-device attacks. + +## RadSec: Securing RADIUS Authentication + +### Why Standard RADIUS Is Not Suitable + +RADIUS is a UDP protocol designed for use inside an operator's secure network. Standard RADIUS +traffic is unencrypted and contains user identity data. Sending RADIUS over the open internet would +expose this sensitive information. For brownfield deployments that must reach Helium's cloud RADIUS +servers, a secure transport is required. + +### RadSec (RADIUS over TLS) + +The industry solution is RadSec—RADIUS encapsulated in TLS. RadSec encrypts RADIUS messages and runs +over TCP, making it suitable for traversing the internet. Helium requires RadSec for all brownfield +RADIUS connectivity. + +### Shared Secret Note + +When configuring RadSec to Helium's servers, you will use a shared secret (e.g., `radsec`). This +secret authenticates your proxy to Helium's RADIUS endpoints. The shared secret is used in +conjunction with TLS client certificates. Keep your certificates and configuration secure; do not +expose them in public repositories or documentation. + +### Deployment Options + +You have two main deployment options: + +1. **Local RadSec Proxy**: Deploy RadSecProxy within your secure domain. Your APs send RADIUS to the + local proxy over your internal network; the proxy encrypts and forwards traffic to Helium over + RadSec. This is the recommended approach when you have a central site or can deploy a proxy at + each remote location. + +2. **Helium-Hosted RadSec with VPN**: If you cannot run a local RadSec proxy, you can use Helium's + hosted RadSecProxy. In this case, you must establish an IPsec VPN from your network to the Helium + cloud instance. Unencrypted RADIUS must never traverse the open internet—the VPN provides the + secure tunnel. + +[More details about RadSecProxy deployment options can be found here.](/mobile/helium-plus-radsecproxy) + +### Hosted Environment Security + +If using Helium-hosted RadSecProxy, your RADIUS traffic is encrypted over the VPN. Helium operates +the RadSecProxy in a secure cloud environment. Ensure your VPN configuration uses strong +authentication and encryption (e.g., IPsec with IKEv2). + +## Brownfield Security FAQ + +### Is my existing WiFi network less secure if I convert it to Helium? + +Converting to Helium does not reduce the security of your existing network. Helium configurations +are additive. You add a Passpoint SSID and RadSec integration; your existing SSIDs and policies +remain unchanged. Follow the best practices in this guide to keep the Passpoint segment secure. + +### Do I need to use RadSec, or can I send RADIUS directly to Helium? + +You must use RadSec (RADIUS over TLS). Standard RADIUS over UDP is not supported for connectivity to +Helium's cloud. If your WiFi equipment does not support RadSec natively, deploy RadSecProxy locally +or use the VPN option with Helium-hosted RadSecProxy. + +### What happens if my RADIUS certificates expire? + +Expired certificates will cause authentication failures. Clients will not be able to connect to the +Passpoint SSID. Monitor certificate expiration dates and renew before they expire. Use the Helium +Wallet CLI to generate new certificates when needed. + +### Should I put Passpoint traffic on the same VLAN as my guest WiFi? + +No. Use a dedicated VLAN for Passpoint traffic. Isolating Passpoint from guest and internal networks +improves security and simplifies troubleshooting. Apply firewall rules to restrict Passpoint clients +to internet-only access. + +### Can I use the same NAS-ID for multiple locations? + +Each onboarded network should use a unique NAS-ID that matches the MAC address (or configured +NAS-ID) of the deployed equipment. Sharing NAS-IDs across locations can cause accounting and reward +attribution issues. For large deployments with multiple NAS-IDs, consider the +[Helium Plus](https://www.helium.com/plus) program. diff --git a/docs/network-mobile/mappers.mdx b/docs/network-mobile/mappers.mdx deleted file mode 100644 index 21ac57c30..000000000 --- a/docs/network-mobile/mappers.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -id: mobile-mappers -title: MOBILE Mappers -pagination_label: MOBILE Mappers -sidebar_label: MOBILE Mappers -description: MOBILE Mappers -image: https://docs.helium.com/img/link-image.png -slug: /mobile/mappers ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# MOBILE Mappers - -:::tip Coming Soon - -The details on how data from Mobile Mappers will be used in rewards calculations are currently in -development. Check out how MOBILE Mappers will be included in the MOBILE PoC Roadmap -[here](https://blog.helium.com/mobile-proof-of-coverage-the-road-ahead-73a25601a13d). - -::: - -Mobile Mappers are hardware devices explicitly designed to attach to CBRS Small Cell Radios to -verify coverage quality and location in a particular hex. - -Following [HIP-53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md), Mobile Mappers will -be eligible to earn 10% of Mobile rewards for verifying the Network. diff --git a/docs/network-mobile/mobilebancheck.jsx b/docs/network-mobile/mobilebancheck.jsx new file mode 100644 index 000000000..86e11d82a --- /dev/null +++ b/docs/network-mobile/mobilebancheck.jsx @@ -0,0 +1,307 @@ +import React, { useState, useEffect } from 'react' +import styles from './mobilebancheck.module.css' + +//////////////////////////// +// SUGGESTION UTILITIES // +//////////////////////////// + +function charsMatchOrCommonMistake(a, b) { + if (a === b) return true + // 0 ↔ O + if ((a === '0' && b === 'O') || (a === 'O' && b === '0')) return true + // 1 ↔ I + if ((a === '1' && b === 'I') || (a === 'I' && b === '1')) return true + return false +} + +// Compare two same-length blocks, allowing up to 1 mismatch. +// letter↔digit mismatch counts as 2. +function isCloseBlock(blockA, blockB) { + if (blockA.length !== blockB.length) return false + let mismatch = 0 + for (let i = 0; i < blockA.length; i++) { + if (!charsMatchOrCommonMistake(blockA[i], blockB[i])) { + const letterDigit = + (/[A-Z]/.test(blockA[i]) && /\d/.test(blockB[i])) || + (/\d/.test(blockA[i]) && /[A-Z]/.test(blockB[i])) + mismatch += letterDigit ? 2 : 1 + if (mismatch > 1) return false + } + } + return mismatch <= 1 +} + +//////////////////////////// +// VALIDATION + FORMATTING +//////////////////////////// + +// The final valid pattern: (AT|EC|RK|XX|YY)(I|O)\d+(?:E)?-\d{4}-\d{8} +function validateSerial(serialWithDashes) { + const validSerialRegex = /^(?:AT|EC|RK|XX|YY)(?:I|O)\d+(?:E)?-\d{4}-\d{8}$/i + return validSerialRegex.test(serialWithDashes) +} + +// Insert dashes only if final string is fully valid. +// E.g. 'ATI6241200014971' => 'ATI6-2412-00014971' +function insertDashes(str) { + const len = str.length + if (len < 5) return str + if (len < 13) { + if (len <= 8) { + return str.slice(0, 4) + '-' + str.slice(4) + } else { + const firstCount = len - 12 + if (firstCount <= 0) { + return str.slice(0, 4) + '-' + str.slice(4, 8) + (str.length > 8 ? '-' + str.slice(8) : '') + } + } + } + const mainBlockCount = len - 12 + if (mainBlockCount < 1) { + return str + } + const block1 = str.slice(0, mainBlockCount) + const block2 = str.slice(mainBlockCount, mainBlockCount + 4) + const block3 = str.slice(mainBlockCount + 4) + return block1 + '-' + block2 + '-' + block3 +} + +// Keep A–Z, 0–9, and dashes. Uppercase letters. +function stripToAllowed(str) { + return str.replace(/[^A-Z0-9-]/gi, '').toUpperCase() +} + +// For validation or suggestions, remove dashes. +function removeDashes(str) { + return str.replace(/-/g, '') +} + +// Split a raw (no-dash) string into up to 3 blocks: first slab, next 4, last 8. +function parseBlocks(str) { + const len = str.length + if (len <= 4) { + return [str, '', ''] + } else if (len <= 8) { + return [str.slice(0, 4), str.slice(4), ''] + } else { + const mainBlockCount = len - 12 + if (mainBlockCount <= 0) { + // partial scenario + return [str.slice(0, 4), str.slice(4, 8), str.slice(8)] + } + const b1 = str.slice(0, mainBlockCount) + const b2 = str.slice(mainBlockCount, mainBlockCount + 4) + const b3 = str.slice(mainBlockCount + 4) + return [b1, b2, b3] + } +} + +// Replace hyphens with spaces, then capitalize each word. +function formatHotspotName(name) { + return name + .split('-') + .map((word) => { + if (!word) return '' + return word.charAt(0).toUpperCase() + word.slice(1).toLowerCase() + }) + .join(' ') +} + +export function BanCheck() { + const [bannedHotspots, setBannedHotspots] = useState([]) + const [fetchError, setFetchError] = useState(false) + + // This is the raw typed string including possible dashes. + const [typedInput, setTypedInput] = useState('') + // The displayed value. If final is valid, we show the final dashed form, else typed. + const [displayValue, setDisplayValue] = useState('') + + const [matchedHotspot, setMatchedHotspot] = useState(null) + const [suggestion, setSuggestion] = useState(null) + const [isSerialValid, setIsSerialValid] = useState(false) + + // The last known fully valid dashed string, for re-check once ban data arrives. + const [lastValidDashed, setLastValidDashed] = useState('') + + useEffect(() => { + fetch('https://helium-banned-mobile-hotspots.s3.us-west-2.amazonaws.com/banned.json') + .then((res) => res.json()) + .then((data) => { + setBannedHotspots(data) + setFetchError(false) + }) + .catch((err) => { + console.error('Error fetching banned hotspots:', err) + setBannedHotspots([]) + setFetchError(true) + }) + }, []) + + useEffect(() => { + if (bannedHotspots.length > 0 && lastValidDashed) { + const found = bannedHotspots.find( + (h) => h.serial.toUpperCase() === lastValidDashed.toUpperCase(), + ) + setMatchedHotspot(found || null) + } + }, [bannedHotspots, lastValidDashed]) + + function checkForMatch(serial) { + if (!isSerialValid) { + setMatchedHotspot(null) + return + } + const found = bannedHotspots.find((h) => h.serial.toUpperCase() === serial.toUpperCase()) + setMatchedHotspot(found || null) + } + + function handleChange(e) { + // Let user type letters, digits, or dashes. + const raw = e.target.value || '' + const allowed = stripToAllowed(raw) + + // We'll keep that as typedInput. + setTypedInput(allowed) + + // For validation, we remove user typed dashes. + const noDash = removeDashes(allowed) + + // Attempt to insert final dashes if valid. + const dashed = insertDashes(noDash) + const valid = validateSerial(dashed) + setIsSerialValid(valid) + + // If valid, show the final dashed form. Else show the user typed input. + const displayed = valid ? dashed : allowed + setDisplayValue(displayed) + + if (valid) { + setLastValidDashed(dashed) + checkForMatch(dashed) + } else { + setLastValidDashed('') + setMatchedHotspot(null) + } + + // SUGGESTION logic + setSuggestion(null) + const [userFirst, userSecond, userThird] = parseBlocks(noDash) + if (userFirst.length >= 2) { + let candidate = null + for (const hotspot of bannedHotspots) { + // remove all dashes from the hotspot's serial + const hRaw = removeDashes(stripToAllowed(hotspot.serial)) + const [hFirst] = parseBlocks(hRaw) + if (isCloseBlock(userFirst, hFirst)) { + const correctedStr = hFirst + userSecond + userThird + const correctedDashed = insertDashes(correctedStr) + if (validateSerial(correctedDashed)) { + candidate = hFirst + break + } + } + } + if (candidate && candidate !== userFirst) { + setSuggestion(candidate) + } + } + } + + function applySuggestion() { + if (!suggestion) return + + // parse the typed input (minus dashes) into blocks. + const noDash = removeDashes(typedInput) + const [userFirst, userSecond, userThird] = parseBlocks(noDash) + const correctedStr = suggestion + userSecond + userThird + + // re-build typed input with the corrected first block, but keep no dashes? + // We'll just remove all dashes, combine, and re-check. + + const dashed = insertDashes(correctedStr) + const valid = validateSerial(dashed) + + // If valid, show final. Else show user typed with a dash? + if (valid) { + setDisplayValue(dashed) + setLastValidDashed(dashed) + setIsSerialValid(true) + checkForMatch(dashed) + } else { + // put the corrected raw block back into typed input. + // user typed dashes won't necessarily match up but let's keep it simple. + const newAllowed = suggestion + userSecond + userThird + setDisplayValue(newAllowed) + setIsSerialValid(false) + setLastValidDashed('') + setMatchedHotspot(null) + } + + setTypedInput(correctedStr) + setSuggestion(null) + } + + // 1) If matchedHotspot => ban UI. + // 2) Else if isSerialValid & displayValue.length > 0 => show "valid + not banned" notice. + const showBannedUi = matchedHotspot !== null + const showValidNotice = !showBannedUi && isSerialValid && displayValue.length > 0 + + return ( +
+
+ + + +
+ + {suggestion && !showBannedUi && ( + + Did you mean {suggestion}? + + )} + + {showBannedUi && ( +
+

+ The Hotspot {matchedHotspot && formatHotspotName(matchedHotspot.name)}{' '} + is marked as permanently banned. +

+

+ Public Key:{' '} + {matchedHotspot?.public_key} +

+

+ Serial:{' '} + {matchedHotspot?.serial} +

+
+ )} + + {showValidNotice && !fetchError && ( +

This Hotspot serial appears valid and is not banned.

+ )} + + {fetchError && ( +

+ Unable to load banned Hotspot data. Please try again later. +

+ )} +
+ ) +} diff --git a/docs/network-mobile/mobilebancheck.mdx b/docs/network-mobile/mobilebancheck.mdx new file mode 100644 index 000000000..cb8a02116 --- /dev/null +++ b/docs/network-mobile/mobilebancheck.mdx @@ -0,0 +1,21 @@ +--- +id: bancheck +title: Ban Check +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /mobile/bancheck +--- + +import BrowserOnly from '@docusaurus/BrowserOnly' +import { BanCheck } from './mobilebancheck' + +Hotspots provide valuable utility, and this utility must be protected. Any device found tampering +with or attempting to falsify data will be permanently removed from the network and cannot be +reactivated. + +When buying a Hotspot, always work with trusted vendors. Use this tool to check Mobile Hotspot +serial numbers. + +
+ Loading...
}>{() => } + diff --git a/docs/network-mobile/mobilebancheck.module.css b/docs/network-mobile/mobilebancheck.module.css new file mode 100644 index 000000000..e4cf9964b --- /dev/null +++ b/docs/network-mobile/mobilebancheck.module.css @@ -0,0 +1,102 @@ +.bancheckContainer { + padding: 1rem; + width: 100%; +} + +.inputGroup { + box-shadow: 0 3px 8px -3px #00000014; + border-radius: 8px; + box-sizing: content-box; +} +.inputGroup:focus-within { + outline: 2px solid var(--ifm-color-primary-lightest); +} + +.inputLabel { + display: block; + color: #53627c; + background: #eaeff9; + + padding: 0.5rem 1.5rem; + font-weight: 500; + border-radius: 8px 8px 0 0; +} +[data-theme='dark'] .inputLabel { + color: #eee; + background: #ffffff1a; +} + +.hotspotInput { + display: block; + margin-bottom: 0.25rem; + padding: 1rem 1.5rem; + width: 100%; + font-size: 1.5em; + font-family: Courier, monospace; + background: var(--ifm-background-color); + border: none; + border-radius: 0 0 8px 8px; +} +.hotspotInput::placeholder { + text-decoration: underline; + text-underline-offset: 0.18em; +} +.hotspotInput:focus { + outline: none; +} + +.successNotice, +.inputSuggestion, +.fetchError { + display: block; + color: #53627c; + margin: 0.5rem 1.5rem -0.5rem; + font-size: 1rem; + font-weight: 500; +} +.inputSuggestion { + cursor: pointer; + text-decoration: underline; + text-decoration-color: #bcc2cc; +} +.inputSuggestion strong { + color: var(--ifm-color-primary-dark); +} +[data-theme='dark'] .inputSuggestion { + color: var(--ifm-color-gray-300); +} +[data-theme='dark'] .inputSuggestion strong { + color: var(--ifm-color-primary-light); +} + +.isBanned_container { + background: #fff; + width: 100%; + padding: 0.75rem 1.5rem 1.25rem; + margin-top: 1rem; + border: none; + border-radius: 8px; + box-shadow: 0 3px 8px -3px #00000014; +} +[data-theme='dark'] .isBanned_container { + background: #ffffff0d; +} + +.header { + margin: 0.5em 0; +} +.publicKey, +.serial { + margin: 0; + font-size: smaller; + display: flex; + gap: 0.5em; +} +.publicKeyTruncate { + overflow: hidden; + white-space: nowrap; + text-overflow: ellipsis; + display: inline-block; + width: 100%; + flex: 1; +} diff --git a/docs/network-mobile/proof-of-coverage.mdx b/docs/network-mobile/proof-of-coverage.mdx deleted file mode 100644 index aa45a6c35..000000000 --- a/docs/network-mobile/proof-of-coverage.mdx +++ /dev/null @@ -1,790 +0,0 @@ ---- -id: mobile-poc -title: MOBILE Proof of Coverage -pagination_label: MOBILE Proof of Coverage -sidebar_label: MOBILE Proof of Coverage -description: MOBILE Proof of Coverage -image: https://docs.helium.com/img/link-image.png -slug: /mobile/proof-of-coverage ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -# MOBILE Proof of Coverage - -## Introduction - -The Helium blockchain uses a novel work algorithm called "Proof of Coverage" ("PoC") to verify that -Hotspots are located where they claim. Put another way, PoC tries to verify, on an ongoing basis, -that Hotspots are honestly representing their location and the wireless network coverage they are -creating from that location. - -While current 5G Hotspots are _also_ able to participate in the IOT Network and PoC, the CBRS Small -Cell and 5G aspects of a 5G Hotspot require a new approach to validating PoC. - -Modeled Coverage introduces a fundamental difference in using hexes for the MOBILE Network compared -to the IOT Network where hexes determine the locations and number of Hotspots within the given hex. -In the MOBILE Network, hexes determine where the coverage exists. Modeled Coverage data allows us to -un-tie a Radio's location from its signal strength and propagation. - -:::tip One Way Traffic - -A CBRS Small Cell Radio ("Radio") can only operate as a transmitter; they cannot receive incoming -data and thus can not "hear" one another directly. - -LoRaWAN Hotspots utilize a PoC method that benefits from Hotspots being used as senders ("Beacon") -and receivers ("Witness") of PoC activity; read more here: -[Proof of Coverage](/blockchain/proof-of-coverage) - -::: - ---- - -## Proof of Coverage Milestones - -Determining useful coverage and the impact on MOBILE PoC rewards will be based on a number of -factors: - - - -These factors will be rolled out in stages over the next twelve months and explained in detail to -ensure Network Builders can take concrete steps to plan or improve their setups. Check out the -MOBILE PoC Roadmap -[here](https://blog.helium.com/mobile-proof-of-coverage-the-road-ahead-73a25601a13d). - ---- - -## Reward Algorithm - -The proposed new algorithm for MOBILE Reward calculation in the MOBILE Rewards Oracle is as follows: - -1. Supply the declared transmitter power of each Radio and its location to the Obstruction Data - Oracle. -2. Get all hexes that have coverage from Outdoor Radios based on the information from the - Obstruction Data Oracle. -3. Based on the location of Indoor Radios, get all hexes with Indoor coverage and all adjacent - hexes. -4. Use projected signal loss information from the Obstruction Data Oracle to determine the potential - signal strength of each Outdoor Radio in each hex. -5. For each hex, get at most 5 Outdoor Radios with the top signal strength of the same level. - -- If there are more than 5 Radios with the same signal strength level, use the `coverage_claim_time` - value to determine the top 5 oldest installations where `coverage_claim_time` is the timestamp - when the Radio received the spectrum access grant for the first time. -- To prevent rewarding "dead" Radios, we propose to reset `coverage_claim_time` if the Radio was not - generating a Heartbeat for more than 72 hours and use the time of the last Heartbeat as the new - `coverage_claim_time`. - -6. Get max 5 Indoor Radios using the same approach as above for Outdoor Radios. -7. Based on [Modeled Coverage Reward Tiers](#modeled-coverage-reward-tiers), sum up all estimated - coverage points earned by each Radio in all hexes and multiply that by `speedtest_multiplier` for - each Radio. -8. Divide the total number of MOBILE Rewards emitted during the Rewards Period by the sum of - multiples of [`heartbeat_multiplier`](#heartbeat-reward-tiers), - [`estimated_reward_points`](#modeled-coverage-reward-tiers), and - [`speedtest_multiplier`](#speed-test-reward-tiers) for each Radio to determine MOBILE Rewards per - `estimated_reward_point` for Radio with a passing Speed Test and valid Heartbeats. -9. Multiply the MOBILE per `estimated_reward_point` by the sum of each Radio's reward points to - determine the MOBILE Rewards for each Radio. - -The new formula for Reward calculation per Radio: - -$$ -W = k_H \times k_S \times C_E \times W_p -$$ - -| Variable | Description | -| -------- | -------------------------------- | -| $W$ | Total rewards | -| $k_H$ | Heartbeat multiplier | -| $k_S$ | Speedtest multiplier | -| $C_E$ | Estimated coverage points | -| $W_p$ | Epoch rewards per coverage point | - -### Calculation Example - -For simplicity, assume that the total MOBILE Rewards per period is 10,000. - -| Radio | Heartbeat | Heartbeat multiplier $k_H$ | Speed Test | Speedtest Multiplier $k_S$ | Hex 1 - Hex 10 | Hex 11 - Hex 20 | Hex 21 - Hex 220 | Total Coverage Points | Total Reward Points | -| :---------: | :-------: | :------------------------: | :--------: | :------------------------: | :------------: | :-------------: | :--------------: | :-------------------: | :-----------------: | -| 1 (Outdoor) | Ok | 1 | Acceptable | 1 | 160 | 80 | 800 | 1,040 | 1,040 | -| 2 (Outdoor) | Ok | 1 | Poor | 0.25 | 80 | 40 | | 120 | 30 | -| | | | | | | | | **Points** | **1,070** | - -**Table 3.** Simplified data for two Outdoor Radios with Heartbeat, Speed Test, and Estimated -Coverage Points for one Reward Period. - -| Radio | Heartbeat | Heartbeat multiplier $k_H$ | Speed Test | Speedtest Multiplier $k_S$ | Hex 1 | Hex 2 | Hex 3 | Hex 4 | Total Coverage Points | Total Reward Points | -| :--------: | :-------: | :------------------------: | :--------: | :------------------------: | :---: | :---: | :---: | :---: | :-------------------: | :-----------------: | -| 3 (Indoor) | Ok | 1 | Degraded | 0.5 | 100 | 100 | 100 | 400 | 700 | 350 | -| | | | | | | | | | **Points** | **350** | - -**Table 4.** Simplified data for one Indoor Radio with Heartbeat, Speed Test, and Estimated Coverage -Points for one Reward Period. - -$$ -R \times (1 \times 1 \times 1040 + 1 \times 0.25 \times 120 + 1 \times 0.5 \times 700) = 10,000 -$$ - -Where R is the reward per one estimated coverage point. - -$$ -R = 6.54 -$$ - -| | Calcuation | Total MOBILE Rewards | -| ----------------- | :-------------------- | -------------------: | -| Radio 1 (Outdoor) | 6.54 x 1 x 1 x 1040 | **6,806.30** | -| Radio 2 (Outdoor) | 6.54 x 1 x 0.25 x 120 | **903.14** | -| Radio 3 (Indoor) | 6.54 x 1 x 0.5 x 700 | **2,290.58** | - ---- - -## Modeled Coverage - -With the [passing](https://heliumvote.com/14jH67zhctwb3B5NmwiAjaXQuyF7jZMZCAnfyBYhSpRS3L22sQE) of -[HIP-74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) -Modeled Coverage aims to allow for more appropriate Rewards and incentivizes the deployment of -Radios at optimal locations. - -This new algorithm uses the location of the Radio to calculate MOBILE Rewards based on the number of -res12 hexes receiving coverage from a given Radio. - -The MOBILE Rewards Oracle will calculate a coverage model for each Radio by considering the physical -location, antenna direction, radio max transmit power, and Obstruction Data Oracle inputs to -calculate the number of res12 hexes receiving coverage from each Radio. - -Depending on the number of res12 hexes and the resulting signal power in each, the MOBILE Rewards -Oracle will allot **Coverage Points** to a given Radio for calculating its MOBILE Rewards instead of -assuming a fixed Radio Type multiplier Reward. - -### Reward Hexagon Sizing - -Analysis of the coverage by a single Outdoor Radio with Modeled Coverage data shows that the res8 -hex used in the IOT Network is too large to represent a Radio's coverage. Using res12 hexes better -aligns with what an Outdoor Radio can reasonably cover, with an average area of 0.0003071 km² and an -edge length of 9.4 m, slightly bigger than an average single-family home. - -To summarize: - -- Hexes in the MOBILE Network identify the level of coverage from all the different Radios providing - coverage to each res12 hex. -- A Radio can provide coverage for a hex it is not located within. -- A Radio can earn Rewards by providing coverage in multiple hexes. - -To help visualize the significant difference between these two resolutions, below is a map with a -green res8 hex and a purple res12 hex inside. - - - -### Modeled Coverage Reward Tiers - -:::info - -Each Radio is given a **coverage points** value depending on the number and signal strength of the -res12 hexes receiving coverage from the Radio. - -::: - -#### Outdoor Radios - -Modeled Coverage replaces Radio Type multipliers with **coverage points** represented by four tiers -of potential signal power as modeled by the Obstruction Data Oracle - `High`, `Medium`, `Low`, and -`None`. - -The reward tiers for Outdoor Radios will be as follows: - -| | Tier 1 | Tier 2 | Tier 3 | Tier 4 | -| ----------------------------- | :-----------: | :------------------------: | :-------------------------: | :--------------: | -| **Potential Signal Power** | $P > -95 dBm$ | $-95 dBm \ge P > -105 dBm$ | $-105 dBm \ge P > -115 dBm$ | $P \le -115 dBm$ | -| **Potential Signal Level** | High | Medium | Low | None | -| **Estimated coverage points** | 16 | 8 | 4 | 0 | - -:::note Modeled Coverage Distance Limit for Outdoor Radios - -The Modeled Coverage algorithm limits the radius of coverage for a given Radio to 1000 meters. This -value results from evaluating a selection of "ideal case" Radios, which provided usable coverage to -roughly 500 meters and doubled that value. A larger radius would also be too heavy for the -computation and is a current trade-off. - -::: - -#### Indoor Radios - -Like Outdoor, Indoor Radios can collect MOBILE Rewards by providing coverage in multiple hexes. - -The Obstruction Data Oracle cannot evaluate coverage by Indoor Radios as there are no good and -reliable data sources about obstacles in indoor spaces. Instead, the Modeled Coverage Oracle uses an -approximation based on the data gathered while testing certified Indoor Radios in various indoor -settings. - -From this testing, the hex in which an Indoor Radio is physically located receives maximum signal -strength coverage, and all adjacent hexes receive lower signal strength. Therefore, the algorithm -errs on generosity to ensure equitable potential MOBILE Rewards for Indoor Radio coverage. - -Estimated per-hex coverage points for Indoor Radios are intentionally significantly higher than -those awarded to Outdoor Radios to balance the importance of Indoor Radios in the MOBILE Network -with their relatively smaller coverage footprints. - -The reward tiers for Indoor Radios will be as follows: - -| | Tier 1 | Tier 2 | -| ----------------------------- | :--------: | :----------------: | -| **Location** | Inside hex | All adjacent hexes | -| **Potential Signal Level** | High | Low | -| **Estimated coverage points** | 400 | 100 | - -These values were chosen by taking all the Outdoor Radios in an example area and analyzing the -resulting distribution of estimated coverage points per Radio. Estimated coverage point values were -chosen such that Indoor Radios receive roughly ¼th the estimated coverage points as the 95th -percentile Outdoor Radios and about ½ the points of the average Outdoor Radio. - -These results align with the current Radio Type Multiplieres approach `1:2.5:4` for Indoor Radios, -Outdoor Radios, and High-Power Outdoor Radios. Figure 2 below is the cumulative distribution -function plot of the sample market Outdoor Radio estimated coverage points. - - - -Cumulative distribution function of Outdoor Radio estimated coverage points for 904 Radios in the -L.A. market area. - -### Modeled Coverage Explorer - -:::tip check coverage - -Modeled Coverage Explorer is available [here](https://coverage-explorer.herokuapp.com/). - -::: - -Modeled Coverage data will play a key role in providing information to visualize it, with more data -added as additional external sources (e.g., [Mobile Mappers](mobile/mappers)) come into play. - -HIP-74 proposed the creation of a new Mobile Explorer dedicated exclusively to the MOBILE Network as -adding more features and data for MOBILE Rewards to the IOT Network Explorer becomes practically -impossible as the MOBILE Network grows. The first iteration of the MOBILE Explorer proposes a basic -map overlay of 5G data coverage with signal strength. - ---- - -## Uptime Heartbeats - -A "heartbeat" is data sent by the 5G Hotspot indicating that a connected Radio is authorized to -transmit 5G coverage. - -Heartbeats occur every 60 seconds and transmit authorizations are valid for 240 seconds. This -rolling overlap ensures that a Small Cell Radio can broadcast on an ongoing basis while allowing for -brief interruptions. - -To encourage reliable signal availability, 5G Hotspots and connected CBRS Small Cell Radios must -generate at least one heartbeat per hour in 12 unique hours of the 24-hour Reward Period. - -### Heartbeat Reward Tiers - -:::info Heartbeat impact on Radio rewards - -Each Radio is given a **heartbeat multiplier** of either `0` or `1`. - -::: - -Each Radio is awarded 1 point for a successful heartbeat in each hour, with a maximum of 24 points -in the Reward Period. All Radios with at least 12 points in the 24-hour Reward Period are given a -`heartbeat multiplier` of `1` and will be eligible to earn MOBILE Rewards. - -### Heartbeat Examples - -Choose from the options below to see some heartbeat example scenarios and the impact on MOBILE -rewards. - - - - - -The Radio generated a heartbeat every hour of the day, earning 24 points. - -This Radio **will** be eligible for rewards during the Reward Period. - - - - - - - -The Radio did not generate Heartbeats for 12 hours, earning 12 points. - -This Radio **will** be eligible for rewards during the Reward Period. - - - - - - - -The Radio did not generate Heartbeats for 19 hours, earning 5 points. - -This Radio **will not** be eligible for rewards during the Reward Period. - - - - - - - ---- - -## Backhaul Speed Tests - -A 5G Hotspot automatically performs Speed Tests, with the results averaged by the MOBILE PoC Oracle. -The MOBILE PoC Oracle includes these Speed Test metrics in the Rewards calculations for each 5G -Hotspot. - -The 5G Hotspot will randomly measure download, upload, and latency to the MOBILE verifier twice in a -given 24-hour period. If a test can not complete successfully, the 5G Hotspot automatically retries -every 30 minutes until a Speed Test is successful. The first Speed Test for a newly installed 5G -Hotspot is performed within the first 12 hours after powering it on. - -A minimum of two and maximum of six Speed Tests are required in the previous 48 hours to calculate a -Moving average results for each download, upload, and latency, after which a new series of Speed -Test results must be collected before a Moving Average can be calculated. - -### Speed Test Reward Tiers - -:::info Speed test impact on Radio rewards - -Each 5G Hotspot is given a `speedtest multiplier` of either `0.0`, `0.25`, `0.5` or `1.0`. - -This multiplier is applied to all connected Radios in rewards calculations. - -::: - -Many locations where CBRS connectivity is being deployed, including some rural areas, do not always -have the high-speed Internet connectivity needed to meet the acceptable Internet requirements for -Genesis rewards consistently. - -Often these areas do not have good cellular coverage either. That's why we believe it is essential -to incentivize Helium deployments in less well-connected areas. - -In response to community feedback and further exploration by Chris from DeWiPulse for his -[analysis of and commentary on public Internet data in the United States,](https://dewipulse.com/connectivity-where-it-matters/) -Speed Test results are categorized into one of four Tiers - `Acceptable`, `Degraded`, `Poor`, and -`Fail`. - -| Speed Test Tier | Speedtest Multiplier | Requirement (speeds in Mbps, latency in ms) | -| :-------------: | :------------------: | :----------------------------------------------------------- | -| **Acceptable** | `1.00x` | `100+` Download, **AND** `10+` Upload, **AND** `<50` Latency | -| **Degraded** | `0.50x` | `50+` Download, **AND** `5+` Upload, **AND** `<75` Latency | -| **Poor** | `0.25x` | `30+` Download, **AND** `2+` Upload, **AND** `<100` Latency | -| **Fail** | `0.00x` | `<30` Download, **OR** `<2` Upload, **OR** `>100` Latency | - -Tiered Speed Test values are used as a multiplier in Rewards calculations as follows: - -- Speed Test Results are put into Tiers based on the minimum value of each Download, Upload, and - Latency (logical `AND`). -- Speed Test results that do not meet the minimum requirements for any Download, Upload, or Latency - are considered to have `Failed` and are not eligible for Rewards until the Speed Test Average is - improved (logical `OR`). - -:::tip Requirements Will Evolve - -As the needs and realities of the Network change, backhaul requirements will evolve to better suit -the Network and its users. - -::: - -### Speedtest Examples - -Choose from the options below to see some speedtest example scenarios and the impact on MOBILE -rewards. - - - - -```bash -Download 200 -> `Acceptable` -Upload 40 -> `Acceptable` -Latency 15 -> `Acceptable` ---------------------------------- -Speed Test Tier -> `Acceptable` -> 1.0x Multiplier -``` - - - - -```bash -Download 200 -> `Acceptable` -Upload 6 -> `Degraded` -Latency 15 -> `Acceptable` ---------------------------------- -Speed Test Tier -> `Degraded` -> 0.5x Multiplier -``` - - - - -```bash -Download 40 -> `Poor` -Upload 6 -> `Degraded` -Latency 15 -> `Acceptable` ---------------------------------- -Speed Test Tier -> `Poor` -> 0.25x Multiplier -``` - - - - -```bash -Download 200 -> `Acceptable` -Upload 40 -> `Acceptable` -Latency 150 -> `Fail` ---------------------------------- -Speed Test Tier -> `Fail` -> 0.0x Multiplier -``` - - - - -### Speed Test Example Calculations - -Here are a set of tables to help visualize the components that make up the Speed Test result. - -:::info - -It may take up to 12 hours for newly connected 5G Hotspots to perform a Speed Test, and a minimum of -2 Speed Tests are required for the MOBILE PoC Oracle to calculate a moving average. - -::: - - - - - -This 5G Hotspot is passing all Speed Test metrics and is providing a high-quality connection. - - - -**Test 1** - -This 5G Hotspot **will not** be eligible for rewards during the Reward Periods for which the results -of Test 1 are the most recent as there is not enough data to calculate a Moving Average. - -**Test 2 and Later** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of these are the most recent. - - - - -This 5G Hotspot has failed its Speed Test on all metrics in Test 6, but the Moving Average stays -within the passing range. - - - -**Test 1** - -This 5G Hotspot **will not** be eligible for rewards during the Reward Periods for which the results -of Test 1 are the most recent as there is not enough data to calculate a Moving Average. - -**Test 2 and Later** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of Tests 2 and later are the most recent. - - - - -This 5G Hotspot has not reported Speed Test data at Test 5. - - - -**Test 1** - -This 5G Hotspot **will not** be eligible for rewards during the Reward Periods for which the results -of Test 1 are the most recent as there is not enough data to calculate a Moving Average. - -**Test 2 through 4** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of Tests 2 through 4 are the most recent. - -**Test 5 through 6** - -This 5G Hotspot **will not** be eligible for rewards during the Reward Periods for which the results -of Tests 5 through 6 are the most recent as there is not enough data to calculate a Moving Average. - -**Test 7 and Later** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of Tests 7 and later are the most recent. - - - - -This 5G Hotspot has less than `Acceptable` Speed Tests in Tests 3, 4, 5, and 6. This has caused the -Moving Average to fall for Tests 6, 7, and 8. - - - -**Test 1** - -This 5G Hotspot **will not** be eligible for rewards during the Reward Periods for which the results -of Test 1 are the most recent as there is not enough data to calculate a Moving Average. - -**Test 2 through 5** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of Tests 2 through 5 are the most recent. - -**Test 6 through 8** - -This 5G Hotspot **will** be eligible for **half** rewards during the Reward Periods for which the -results of Tests 6 through 8 are the most recent as at least one Speed Test metric Moving Average -has not met or exceeded the required values. - -**Test 9 and Later** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of Tests 9 and later are the most recent. - - - - -This 5G Hotspot has not reported Speed Test data during Test 5, 6, or 7. This is often a result of a -5G Hotspot being disconnected from the Internet for a long time. - - - -**Test 1** - -This 5G Hotspot **will not** be eligible for rewards during the Reward Periods for which the results -of Test 1 are the most recent as there is not enough data to calculate a Moving Average. - -**Test 2 through 4** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of Tests 2 through 4 are the most recent. - -**Test 5 through 8** - -This 5G Hotspot **will not** be eligible for rewards during the Reward Periods for which the results -of Tests 5 through 8 are the most recent as there is not enough data to calculate a Moving Average. - -**Test 9 and Later** - -This 5G Hotspot **will** be eligible for **full** rewards during the Reward Periods for which the -results of Tests 9 and later are the most recent. - - - - ---- - -## Statistics on Helium Explorer - -Speed Test metrics are viewable on the 5G Hotspot's page on Explorer under the `5G Statistics` tab. -Here are examples of each status and a brief description of each metric and the resulting impact on -Rewards calculations. - -### Helium Explorer Examples - -Choose from the options below to see some example scenarios and the impact on MOBILE rewards. - - - - - -
-
-
- -
-
- Speed Test Passing - Acceptable -

- The Moving Average for all Speed Test metrics is in the Acceptable range. -

-

- A 1.0x multiplier is applied for the current Reward Period. -

-
-
-
- - - - - -
-
-
- -
-
- Speed Test Passing - Degraded Latency -

- The Moving Average for Upload and Download metrics is in the Acceptable range, - however the 80 ms Latency metric is in the Degraded Tier. -

-

- A 0.5x multiplier is applied for the current Reward Period. -

-
-
-
- - - - - -
-
-
- -
-
- Speed Test Passing - Poor Download -

- The Moving Average for Upload and Latency metrics is in the Acceptable range, - however the 30 Mbps Download metric is in the Poor Tier. -

-

- A 0.25x multiplier is applied for the current Reward Period. -

-
-
-
- - - - - - - -
-
-
- -
-
- Speed Test Fail - Download and Upload -

- The Moving Average for Latency metrics is in the Acceptable range, however the{' '} - 10 Mbps Download and 1 Mbps Upload metrics are below the Poor{' '} - Tier. -

-

- A 0.0x multiplier is applied for the current Reward Period. -

-
-
-
- - - - - -
-
-
- -
-
- Speed Test Not Measured -

- This status appears when a 5G Hotspot has been recently installed, and no Speed Tests have - been performed. -

-

- A 0.0x multiplier is applied for the current Reward Period. -

-
-
-
- - - - - -
-
-
- -
-
- No Recent Speed Test Data -

- This status appears when a Speed Test could not be performed in the previous 24 hours. For - example, when a 5G Hotspot has recently recovered from a prolonged network interruption, - power interruption, or other connection interruptions have occurred. -

-

- A 0.0x multiplier is applied for the current Reward Period. -

-
-
-
- - - - - -
-
-
- -
-
- Not Enough Data -

- This status appears when there are fewer than 2 available Speed Test records, - and a Moving Average can not yet be calculated. -

-

- This is common when a 5G Hotspot has been newly installed, has recently recovered from a - prolonged network interruption, or in other scenarios where a Speed Test could not be - performed. -

-

- A 0.0x multiplier is applied for the current Reward Period. -

-
-
-
- - - - diff --git a/docs/network-mobile/service-providers.mdx b/docs/network-mobile/service-providers.mdx deleted file mode 100644 index 21f6e1ccc..000000000 --- a/docs/network-mobile/service-providers.mdx +++ /dev/null @@ -1,147 +0,0 @@ ---- -id: service-providers -title: Service Providers On Helium -pagination_label: Service Providers -sidebar_label: Service Providers -description: Service Providers On Helium -image: https://docs.helium.com/img/link-image.png -slug: /mobile/service-providers ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The wireless sector continues to see -[increasing demand](https://www.opensignal.com/2022/10/20/how-mobile-network-experience-affects-churn-in-us-wireless-carriers) -for higher bandwidth and lower latency while users question whether the major carriers are worth the -price. In addition, carriers’ ability to keep up with demand will require denser networks with more -nodes, which only exacerbates site acquisition costs. - -The Helium 5G Network presents an alternative that decentralizes these overhead costs while -providing more avenues for Service Providers to generate revenue including allocations of MOBILE -token emissions. - -## Background - -[HIP-53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md) put forth a detailed overview -of this economic model to pave the way for Service Providers’ success in the Helium ecosystem. - -It established the MOBILE subDAO, which handles all MOBILE Rewards emissions, mining Rewards, and -programmatic treasury operations. - -Nova Labs has emerged as the first Service Provider on the MOBILE subDAO. Its Helium Mobile service -is an innovative mobile carrier model that leverages people-built coverage and crypto-economics to -reduce costs and increase benefits for subscribers. - -## Operating A Major Carrier - -Traditional carriers present as companies that sell connectivity and phones when, in reality, -carriers must outsource work to dozens of independent third parties to deliver services to -subscribers. - -This situation creates a tangle of intermediaries resulting in a lot of overhead for the carrier to -coordinate. - -For example, most carriers do not build their own communications equipment or software. They also do -not own or operate cellular towers, do not directly employ personnel to maintain their -infrastructure or data centers, and often opt to franchise retail locations and outsource call -centers. - - - -With so many operational aspects of the business outsourced, the competitive advantage of a carrier -reduces to two critical assets over which they have direct ownership: spectrum lease contracts and -service contracts with subscribers. Everything else – all of the coordination of people and -infrastructure described above – is dedicated to bridging these two assets. - -U.S. telcos are estimated to spend -[upwards of $50B annually](https://oiehba6yxwcxqwxwmmtfxrz2pwthwd2626nvkaqwexll2jsagd3q.arweave.net/cghwg9i9hXha9mMmW8c6faZ7D17Xm1UCFiXWvSZAMPc) -coordinating these independent parties. Given the significant overhead coupled with additional costs -such as spectrum and site acquisition, there is little room for market innovation when delivering -service to subscribers. - -High costs and suboptimal user experiences in onboarding, customer support, billing transparency, -and more pass onto the subscribers due to the inefficiencies of this value chain. - -> The amount of overhead wasted on independent-party coordination creates an environment ripe for -> disruption. - -## Redefining The Carrier Value Chain - -Blockchains are an innovative approach to delivering superior economics for Service Providers by -eliminating coordination inefficiencies that plague carriers. - -Blockchain technology is ideal for coordinating economic activities between independent actors at -its core because it aligns incentives across all layers, unlike the historical model where each -layer is vying for its interest. - - - -While the value chain endpoints do not significantly change, participating Service Providers can use -blockchain technology to streamline the coordination of the layers in delivering useful coverage to -subscribers. - -Programmatic economic coordination executed through Smart Contracts replaces middle managers -shuffling paper. This efficient model delivers cost savings that can pass directly to end users or -increase profits. - -## Driving Low-Cost Coverage - -Service Providers on the Helium 5G Network benefit from decentralizing buildout costs because it -lowers overhead accomplished by enabling community participation in building reliable, -high-bandwidth networks using technologies like CBRS and Wi-Fi. - -In its first few months, the Helium 5G Network footprint has achieved what has taken some of the -largest CBRS networks in the U.S. years to accomplish, deploying more than 7,000 Small Cell Radios -in over 1,200 cities across the U.S. - -To achieve similar results, a carrier must employ extensive resources to coordinate between small -cell vendors, tower operators, installers, and backhaul ISP providers. - -This model efficiently incentivizes people to provide useful coverage on the Helium 5G Network by -offering Rewards, ultimately reducing overall coverage costs because the service is less dependent -on a carrier and its expensive infrastructure. - -Coverage Rewards are not necessarily unilaterally distributed; -[HIP-53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md) also enables Service Providers -to boost Rewards in areas with higher demands for coverage, thus incentivizing Helium 5G Network -builders to provide coverage in the most valuable regions. - -## Service Provider Benefits In Practice - -In addition to the lower coverage costs, Service Providers also benefit from Rewards by driving -subscribers to the Helium 5G Network, which they can pass on to incentivize those subscribers. - -> 20% of all MOBILE Rewards are set aside for Service Providers. - -Service Providers compete with one another based on the number of subscribers and how much data -those subscribers use. In other words, the more usage Service Providers drive on the Helium 5G -Network, the more Rewards they can earn. - -What happens with these Rewards is entirely in the hands of Service Providers. They can retain them -to increase overall profit margins, allocate them to developing innovative new features, or pass -them on to subscribers to incentivize them to continue using their service or acquire new -subscribers. Regardless, Service Providers have more autonomy and growth potential than those -offered in the otherwise rigid economic model of the traditional carrier. - - - -As more subscribers use the people-built coverage of Helium 5G and earn Rewards, the overall value -of the Network increases, more customers will subscribe to the carrier, and the cycle will continue. - -## Learning More And Next Steps - -Reading [HIP-53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md) in its entirety is the -best way to achieve a comprehensive understanding of the economic model for Service Providers. - -Check out -[this blog post](https://blog.helium.com/mobile-proof-of-coverage-the-road-ahead-73a25601a13d) for -more information about achieving better quality coverage for subscribers. - -If you are interested in discussing the next steps to becoming a Service Provider on the Helium 5G -Network, please contact the [Helium Foundation](mailto:hello@helium.foundation). diff --git a/docs/oracles/data-transfer-oracles.mdx b/docs/oracles/data-transfer-oracles.mdx deleted file mode 100644 index d40b8fb5a..000000000 --- a/docs/oracles/data-transfer-oracles.mdx +++ /dev/null @@ -1,91 +0,0 @@ ---- -id: data-transfer-oracles -title: Data Transfer Oracles -pagination_label: Data Transfer Oracles -sidebar_label: Data Transfer Oracles -description: Helium Data Transfer Oracles Documentation -image: https://docs.helium.com/img/link-image.png -slug: /oracles/data-transfer-oracles ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Moving the entire data transfer logic off-chain to Oracles will increase scalability and reduce -points of failure. - -## LoRaWAN Network Server Streamlining - -In comparison with its operation on the Helium L1, the LoRaWAN Network Server (LNS) has a more -focused role on Solana which emphasizes the execution of LoRaWAN specific functions without the -overhead of administering blockchain-specific functionality. After purchasing Organizationally -Unique Identifier (OUI) and slabs, the LNS must inform the Config Service of the routing for the -devices under their network. The LNS can optionally curate an allow-list to, for example, not accept -packets from disabled devices or tenants/devices with a depleted Data Credit (DC) balance. The LNS -will directly transmit these routes and their allow-list to the Config Service. - -The update brings the responsibilities of a Helium LNS much more in line with a generic LNS while -also easing the integrations of existing LNS systems, further helping the expansion of the Helium -Network. - -## Config Service - -The Config Service keeps track of all routing rules for all devices connected to the Helium Network, -aggregating from the LNSs into a database of routes that propagate to each Packet Router. The Config -Service immediately updates the Packet Routers whenever it receives an update. - -The Packet Verifier uses the Config Service to fetch the list of OUIs, wallet addresses per gateway, -and wallet addresses per OUI. - -## Packet Router Service - -The Packet Routers are responsible for routing packets received from Hotspots to the appropriate -LNS. This streamlined service follows the routing rules given to it by the Config Service. - -If a Packet Router can match a received packet to a defined route, it will forward that message to -the appropriate LNS and submit a packet report to the Packet Reports Database. - -Each packet report includes OUI, network ID, region, gateway, and payload hash metadata. The full -definition can be found -[here](https://github.com/helium/proto/blob/master/src/service/packet_router.proto#L8). - -## Load Balancing Service - -Hotspots interface directly with Load Balancers, helping the Helium Network scale horizontally when -needed. - -## Packet Verifier Service - -The Packet Verifier verifies the submitted packets. Its primary responsibilities are to: - -- Confirm that each OUI and the associated LNS have enough DC to pay for the packets received. - - If a given OUI does not, the Packet Verifier will inform the Config Service that it should - disable the associated routes. - - Once a disabled OUI has a positive DC balance, it will re-enable the associated routes. -- Confirm that the Message Integrity Code (MIC) check passes. -- Process reports into a separate database of verified and denied reports (denied reports include - the cause of denial). -- Based on data transfer, calculate Rewards and the amount of DC to debit from each wallet - associated with an OUI. - -```mermaid -flowchart TB; - subgraph hotspots[Hotspots] - direction TB - hotspot1[Hotspot 1] & hotspot2[Hotspot 2] & hotspot3[Hotspot 3] - end - - hotspots -->|Send Packets| loadBalancer(Load Balancer); - loadBalancer --> packerRouters(Packet Routers); - - configService(Config Service) -->|Routes| packerRouters; - packerRouters --> rawReportsDB[(Raw Packet Reports)]; - - packerRouters -->|Forward packets to appropriate LNS| lns[LoRaWAN Network Servers]; - lns --->|Routes for a given LNS| configService; - - rawReportsDB ---> packetVerfier(Packet Verfier); - packetVerfier --> verfiedDataTransferReportsDB[(Verfied Data Transfer Reports)]; - verfiedDataTransferReportsDB --> iotRewardsService(IOT Rewards Service); - - packetVerfier -->|Disables/Enables LNS Routes based on DC balance| configService; -``` diff --git a/docs/oracles/iot-proof-of-coverage-oracles.mdx b/docs/oracles/iot-proof-of-coverage-oracles.mdx deleted file mode 100644 index 7fb4e0ebc..000000000 --- a/docs/oracles/iot-proof-of-coverage-oracles.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -id: iot-proof-of-coverage-oracles -title: IOT Proof-of-Coverage Oracles -pagination_label: IOT Proof-of-Coverage Oracles -sidebar_label: IOT Proof-of-Coverage Oracles -description: Helium IOT Proof-of-Coverage Oracles Documentation -image: https://docs.helium.com/img/link-image.png -slug: /oracles/iot-proof-of-coverage-oracles ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -On the Solana L1, all PoC activity is managed by Oracles, greatly simplifying the beaconing process -by allowing Hotspots to self-beacon at regular intervals. Additionally, off-chain PoC is much more -easily scalable and will remove the limitations on the number of Witnesses per beacon. - -The main actors and their relationships with one another are as follows. - -### Hotspots - -- Hotspots will now self-beacon at regular intervals, targeting a 6-hour interval at launch. -- To prevent premature beaconing and replay attacks, the beacon will include some entropy. -- Hotspots beacon their Challenge and submit it to the PoC Ingest Farm through a Load Balancer - proxy. -- When a Hotspot witnesses a beacon, the Hotspot directly submits the receipt to the PoC ingest - farm. - -### PoC Ingest Farm - -The PoC Ingest farm only performs basic validation that filters out structurally invalid data and -then submits both the beacon receipt and the witness receipts to an S3 bucket. The limited duties of -the PoC Ingest farms make them easily scalable as the Network grows. - -### PoC Verifier Oracle - -The PoC Verifier Oracle verifies all the data submitted by correlating witnesses to receipts and -confirming the series of events, then submits these processed rewardable and invalid receipts to a -separate S3 bucket, including how many shares to give to each Hotspot. - -```mermaid -flowchart TB; -%%{ init: { 'flowchart': { 'curve': 'linear' } } }%% - -subgraph hotspotactivity[Hotspot PoC Activity] - direction LR - beaconer(Beacon Hotspot) - witness1(Witness Hotspot 1) - witness2(Witness Hotspot 2) -end - -beaconer -->|Beacon| witness1; -beaconer -->|Beacon| witness2; -beaconer -->|Beacon Report| loadBalancer; - -entropy(Entropy) -entropy -->hotspotactivity; - -witness1-->|Witness Report|loadBalancer(Load Balancer); -witness2-->|Witness Report|loadBalancer(Load Balancer); - -loadBalancer-->pocIngestFarms(PoC Ingest Farms); - -pocIngestFarms-->rawPocReceipts[(Raw PoC Receipts)]; - -rawPocReceipts-->pocVerifier(PoC Verifier); -pocVerifier-->verifiedPocReceiptsDB[(Verified PoC Receipts)]; -verifiedPocReceiptsDB-->iotRewardsService(IOT Rewards Service); - -``` diff --git a/docs/oracles/mobile-proof-of-coverage-oracles.mdx b/docs/oracles/mobile-proof-of-coverage-oracles.mdx deleted file mode 100644 index 53499fdb1..000000000 --- a/docs/oracles/mobile-proof-of-coverage-oracles.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: mobile-proof-of-coverage-oracles -title: MOBILE Proof-of-Coverage Oracles -pagination_label: MOBILE Proof-of-Coverage Oracles -sidebar_label: MOBILE Proof-of-Coverage Oracles -description: Helium MOBILE Proof-of-Coverage Oracles Documentation -image: https://docs.helium.com/img/link-image.png -slug: /oracles/mobile-proof-of-coverage-oracles ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -As the MOBILE subDAO is still in its infancy, its -[PoC model is relatively straightforward](/mobile/proof-of-coverage) and based on the following -factors: - -1. The Small Cell Radio Type. -2. Heartbeats and Reliability of Service. -3. Speed Tests and Quality of Service. - -Heartbeats and Speed Tests are submitted off-chain to the MOBILE Ingest farm to be verified and used -by the rewards service. - -In the following year, the team plans to add modeled coverage, location-based coverage, and mappers -to MOBILE PoC. You can read this -[roadmap](https://blog.helium.com/mobile-proof-of-coverage-the-road-ahead-73a25601a13d) to learn -more about these plans. - -```mermaid -flowchart LR; -%%{ init: { 'flowchart': { 'curve': 'linear' } } }%% - %% entities - entropy[Entropy] - hotspot[Hotspot] - loadBalancer[Load Balancer] - pocIngestFarms[PoC Ingest Farms] - rawPocRecipts[(Raw PoC Receipts)] - pocVerifier[PoC Verifier] - verifiedPocRecipts[(Verified PoC Receipts)] - mobileRewardsService[MOBILE Rewards Service] - - %% flows - entropy-->hotspot-->loadBalancer-->pocIngestFarms-->rawPocRecipts-->pocVerifier-->verifiedPocRecipts-->mobileRewardsService - -``` diff --git a/docs/oracles/oracle-data.mdx b/docs/oracles/oracle-data.mdx deleted file mode 100644 index 77fd93f74..000000000 --- a/docs/oracles/oracle-data.mdx +++ /dev/null @@ -1,243 +0,0 @@ ---- -id: oracle-data -title: Oracle Data -pagination_label: Oracle Data -sidebar_label: Oracle Data -description: Helium Oracle Data Documentation -image: https://docs.helium.com/img/link-image.png -slug: /oracles/oracle-data ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Helium Network operates Oracles that perform various tasks backing Proof-of-Coverage and data -transfer for the LoRaWAN (IOT), Mobile, and any future networks. These Oracles provide extensive -logs for analysis of the Helium subDAOs. - -The Helium Oracles handle all data about the network, except for transactions handled by the -[Helium Program Libraries](https://github.com/helium/helium-program-library) on Solana. - - - -## Accessing Oracle Data - -### AWS S3 Bucket - -Data is directly accessible from the `foundation-poc-data-requester-pays` bucket in AWS `us-west-2` -under the top-level data category prefixes listed below. All data provided in the S3 bucket is made -available on a basis of 'Requestor Pays', meaning you (the requester) will pay for the data transfer -and AWS API costs incurred from the data requests. - -For more information on accessing data from an AWS requester pays bucket, refer to -[Downloading objects in Requester Pays buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ObjectsinRequesterPaysBuckets.html). - -| Top Level Data Category Prefixes | -| --------------------------------- | -| `foundation-iot-entropy` | -| `foundation-iot-ingest` | -| `foundation-iot-packet-ingest` | -| `foundation-iot-packet-verifier` | -| `foundation-iot-verified-rewards` | -| `foundation-mobile-ingest` | -| `foundation-mobile-verified` | - -Under each top-level data category prefix, the related PoC data files are provided in a flattened -structure in the format provided below: - -`s3://foundation-poc-data-requester-pays//.gz` - -Again, as the `foundation-poc-data-requester-pays` bucket is 'Requestor Pays', you should be mindful -that AWS will charge you for: - -1. Storage costs on any destination buckets -2. Egress fees if the data leaves `us-west-2` -3. `PUT`, `COPY`, `POST`, and `LIST` requests - -To that end, keeping data in `us-west-2` and being pragmatic about which AWS S3 access patterns you -use will greatly reduce your cost burden for accessing the PoC data. - -Regarding access patterns, one approach that you can take to minimize the quantity of S3 API calls -over time - and save money - is to use the `aws s3api list-objects-v2` command and specify the -`--start-after` parameter with the filename of the last file you received, as indicated below: - -```bash -aws s3api list-objects-v2 --bucket foundation-poc-data-requester-pays --prefix --start-after --request-payer requester -``` - -For example, if you were to execute the `aws s3api list-objects-v2` command and the most recent file -you received was `example.gz`, in a subsequent call to `aws s3api list-objects-v2` you could add the -`--start-after example.gz` flag to return a list of files subsequent to `example.gz`. In doing so, -your total API calls in the second invocation of `aws s3api list-objects-v2` would be limited to -only the files subsequent to `example.gz`, rather than for all files in the bucket. From there, you -can iterate over the returned list of files and perform additional S3 API commands such as -`aws s3api copy-object` to copy files based on the file list. - -The raw PoC data stored in the `foundation-poc-data-requester-pays` bucket is in encoded protobuf -format in `.gz` compressed files. The table below provides the top-level data category prefixes, the -file types comprised within each data category prefix, the filename pattern for each file type, and -provides a link to the corresponding protobuf used to decode the data. - -| Category | File Type | Pattern | Protobuf Definition | -| :-------------------------------- | :---------------------------------------- | :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `foundation-iot-entropy` | `Entropy` | `entropy.*` | [`entropy.proto`
(Line 5: `entropy_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/entropy.proto#L5) | -| `foundation-iot-ingest` | `IotBeaconIngestReport` | `iot_beacon_ingest_report.*` | [`service/poc_lora.proto`
(Line 83: `lora_beacon_ingest_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L83) | -| `foundation-iot-ingest` | `IotWitnessIngestReport` | `iot_witness_ingest_report.*` | [`service/poc_lora.proto`
(Line 90: `lora_witness_ingest_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L90) | -| `foundation-iot-packet-ingest` | `PacketReport` | `packetreport.*` | [`service/packet_router.proto`
(Line 8: `packet_router_packet_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/packet_router.proto#L8) | -| `foundation-iot-verified-rewards` | `IotRewardShare` (starting 2023-04-18) | `iot_reward_share.*` | [`service/poc_lora.proto`
(Line 186: `iot_reward_share`)](https://github.com/helium/proto/blob/40388d260fd3603f453a965dbc13f79470b5adcb/src/service/poc_lora.proto#L186) | -| `foundation-iot-verified-rewards` | `IotPoc` | `iot_poc.*` | [`service/poc_lora.proto`
(Line 162: `lora_poc_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L162) | -| `foundation-iot-verified-rewards` | `IotInvalidBeaconReport` | `iot_invalid_beacon.*` | [`service/poc_lora.proto`
(Line 125: `lora_invalid_beacon_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L125) | -| `foundation-iot-verified-rewards` | `IotInvalidWitnessReport` | `iot_invalid_witness.*` | [`service/poc_lora.proto`
(Line 133: `lora_invalid_witness_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L133) | -| `foundation-iot-verified-rewards` | `GatewayRewardShare` | `gateway_reward_share.*` | [`service/poc_lora.proto`
(Line 171: `gateway_reward_share`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L171) | -| `foundation-iot-verified-rewards` | `RewardManifest` | `reward_manifest.*` | [`reward_manifest.proto`
(Line 5: `reward_manifest`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/reward_manifest.proto#L5) | -| `foundation-mobile-ingest` | `CellHeartbeatIngestReport` | `heartbeat_report.*` | [`service/poc_mobile.proto`
(Line 50: `cell_heartbeat_ingest_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_mobile.proto#L50) | -| `foundation-mobile-ingest` | `CellSpeedtestIngestReport` | `speedtest_report.*` | [`service/poc_mobile.proto`
(Line 25: `speedtest_ingest_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_mobile.proto#L25) | -| `foundation-mobile-ingest` | `DataTransferSessionIngestReport` | `data_transfer_session_ingest_report.*` | [`service/poc_mobile.proto`
(Line 177: `data_transfer_session_ingest_report_v1`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_mobile.proto#L177) | -| `foundation-mobile-verified` | `ValidatedHeartbeat` | `validated_heartbeat.*` | [`service/poc_mobile.proto`
(Line 80: `heartbeat`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_mobile.proto#L80) | -| `foundation-mobile-verified` | `SpeedtestAvg` | `speedtest_avg.*` | [`service/poc_mobile.proto`
(Line 97: `speedtest_avg`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_mobile.proto#L97) | -| `foundation-mobile-verified` | `RadioRewardShare` | `radio_reward_share.*` | [`service/poc_mobile.proto`
(Line 118: `radio_reward_share`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_mobile.proto#L118) | -| `foundation-mobile-verified` | `MobileRewardShare` (starting 2023-04-18) | `mobile_reward_share.*` | [`service/poc_mobile.proto`
(Line 145: `mobile_reward_share`)](https://github.com/helium/proto/blob/40388d260fd3603f453a965dbc13f79470b5adcb/src/service/poc_mobile.proto#L145) | -| `foundation-mobile-verified` | `RewardManifest` | `reward_manifest.*` | [`reward_manifest.proto`
(Line 5: `reward_manifest`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/reward_manifest.proto#L5) | - -### Arweave - -_**Planned:**_ In the interest of providing a decentralized option for data access, all Oracle data -will one day be replicated to [Arweave](https://www.arweave.org), which will provide a data access -option that does not require egress fees. An Arweave implementation will be accompanied by relevant -access patterns. - -## Reading Bytestream Data - -To store the massive amount of data generated by the Oracles, the output is stored as zipped -bytestreams (one bytestream per `.gz` file). To 'unpack' this data, you'll first need the associated -Protobuf from [github.com/helium/proto](https://github.com/helium/proto) (also listed above). - -Once uncompressed, the file is a series of 4-byte prefix length encoded binary followed by the -associated message. More concretely, you'll need to repeatedly read the first 4 bytes and decode -that as a big-endian u32. Then use that u32 number as the number of subsequent bytes to read. Decode -those subsequent bytes using the associated proto definition. Repeat this process until you've read -the entire file. - -**Important Note:** Simply trying to pass the contents of the uncompressed files into the protobuf -decoder will fail. - -### Javascript Example - -```protobuf -// poc_mobile.proto -// copied from https://github.com/helium/proto/blob/master/src/service/poc_mobile.proto#L31 - -syntax = "proto3"; - -package helium.poc_mobile; - -message cell_heartbeat_req_v1 { - // Public key of the hotspot - bytes pub_key = 1; - string hotspot_type = 2; - uint32 cell_id = 3; - // Timestamp of heartbeat in seconds from unix epoch - uint64 timestamp = 4; - double lat = 5; - double lon = 6; - bool operation_mode = 7; - string cbsd_category = 8; - string cbsd_id = 9; - - bytes signature = 10; -} -``` - -```js -// oracle-data-reader-example.js - -// assumes you've downloaded and unzipped the below file -const fileBuffer = fs.readFileSync('./cell_heartbeat.1667919103443') - -protobuf.load('mobile.proto', function (err, root) { - if (err) throw err - - // Obtain a message type - var CellHeartbeat = root.lookupType('helium.poc_mobile.cell_heartbeat_req_v1') - - let offset = 0 - while (offset < fileBuffer.length) { - // the first 4 bytes tell you how long the message is - const messageLength = fileBuffer.readInt32BE(offset) - const bufferMessage = fileBuffer.subarray(offset + 4, offset + messageLength + 4) - try { - var decodedMessage = CellHeartbeat.decode(bufferMessage) - console.log(decodedMessage) - } catch (e) { - console.log('error', e) - } - offset += messageLength + 4 - } -}) -``` - -### Rust Example - -This leverages existing Rust dependencies used by the Oracles. - -```toml -# Cargo.toml -[package] -name = "oracle-data-reader-example" -version = "0.1.0" -edition = "2021" - -[dependencies] -anyhow = {version = "1", features = ["backtrace"]} -file-store = {git = "https://github.com/helium/oracles", branch = "main"} -futures = "*" -serde = {version = "1", features=["derive"]} -serde_json = "1" -tokio = { version = "1", default-features = false, features = [ - "fs", - "macros", - "signal", - "rt-multi-thread", - "rt", - "process", - "time" -] } -tokio-util = "0" -``` - -```rust -# main.rs -use anyhow::Result; -use file_store::{heartbeat::CellHeartbeat, traits::MsgDecode, file_source}; -use futures::{ StreamExt}; -use serde_json::json; - -fn print_json(value: &T) -> Result<()> { - println!("{}", serde_json::to_string_pretty(value)?); - Ok(()) -} - -#[tokio::main] -async fn main() -> Result<()> { - // assumes you have cell_heartbeat.1667919103443.gz in folder - let mut file_stream = file_source::source(["cell_heartbeat.1667919103443.gz"]); - - while let Some(result) = file_stream.next().await { - let msg = result?; - let heartbeat = CellHeartbeat::decode(msg)?; - print_json(&json!(heartbeat))?; - } - Ok(()) -} -``` - -A more fleshed-out example can be found in -[this sample oracle observer repo](https://github.com/dewi-alliance/oracle-observer-sample/tree/main/oracle-ingestor-lambda). - -## Service Providers - -Several Helium Ecosystem companies are building interfaces around Oracle Data. These services range -from APIs to Oracle Data Explorers - -- [Hotspotty](https://hotspotty.net/api/) -- [HeliumGeek](https://heliumgeek.com/b/helium-offchain-api.html) -- [Helium Deploy](https://www.heliumdeploy.io) diff --git a/docs/oracles/oracles.mdx b/docs/oracles/oracles.mdx deleted file mode 100644 index 4259c3c78..000000000 --- a/docs/oracles/oracles.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: oracles -title: Helium Oracles -pagination_label: Helium Oracles -sidebar_label: Introduction -description: Helium Oracles Documentation -image: https://docs.helium.com/img/link-image.png -slug: /oracles ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -The migration of the Helium L1 to the Solana L1 brings several changes to the setup of the Network -and its associated subDAOs infrastructure. Chief among these changes is moving a lot of data that -has previously been "on-chain" (namely PoC data) "off-chain". - -As such, this migration introduces several Oracles which serve as bridges between the external world -and the blockchain. These infrastructure changes allow the Helium Network to effectively introduce -new Networks as Decentralized Network Protocol (DNP) subDAOs, and more easily scale existing DNP -subDAOs (e.g., IOT) by removing existing bottlenecks. - -With the deprecation of the Helium L1, changes to the [API](/api/) and -[ETL](https://github.com/helium/blockchain-etl) include: - -1. Existing ETL codebase will no longer sync blocks. -2. Existing API codebase will no longer serve new data. -3. api.helium.io (built on top of existing ETL and API) will stay serving old data. -4. explorer-old.helium.com (built on top of api.helium.io and other APIs) will have data from the - old chain and be migrated to explorer-old.helium.com. - -New API access options include: - -1. New datasets are available and will continue to be available on [AWS S3, via compressed Protobuf files](/oracles/oracle-data). -2. Sample API code has been published in the - [Oracles S3 Observer Sample App](https://github.com/dewi-alliance/oracle-observer-sample). It uses AWS Lambda to ingest the S3 files to a PostgreSQL database and serve them as JSON via an API. -3. Third parties are working on new APIs and services to replace existing tools - (e.g., [Hotspotty](https://hotspotty.net/api/), - [HeliumGeek](https://heliumgeek.com/b/helium-offchain-api.html), Relay, etc.). diff --git a/docs/oracles/price-oracles.mdx b/docs/oracles/price-oracles.mdx deleted file mode 100644 index d9a2e4361..000000000 --- a/docs/oracles/price-oracles.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -id: price-oracles -title: Price Oracles -pagination_label: Price Oracles -sidebar_label: Price Oracles -description: Helium Price Oracles Documentation -image: https://docs.helium.com/img/link-image.png -slug: /oracles/price-oracles ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Price Oracle is one of many Oracles on the Helium Network. The market value of the Helium tokens -is required on-chain as the price is needed to calculate everything from burning HNT for Data -Credits (DC) to treasury allocations for the Mobile and IoT networks. - -:::note Migrating Price Oracles - -On the day of the chain migration, price feeds were not available for all tokens. In this time, the -existing Helium L1 Price Oracles continued to contribute market data. - -Once a stable price feed is available, community-sourced price feeds can be removed in favor of -Pyth. - -- ✅ [HNT/USD](https://pyth.network/price-feeds/crypto-hnt-usd) Integrated May 11, 2023 -- 🔜 [IOT/USD](https://pyth.network/price-feeds/crypto-iot-usd) -- 🔜 [MOBILE/USD](https://pyth.network/price-feeds/crypto-mobile-usd) - -::: - -### Who are the HNT Price Oracles? - -The community-sourced Oracle Price feeds are supplied by a group of eleven (11) Oracles, composed of -companies, organizations, and individuals. These Oracles were selected at the activation of Data -Credits on the Helium L1 blockchain and have proven to be a trusted source of data for the Helium -Network. The Oracle pool is comprised of: - -- Helium Foundation -- Nova Labs -- Nine (9) Anonymous Individual Community Members - -The names of the individual feed contributors are kept anonymous as it's essential to prevent any -external attempts at collusion. - -The current Price Oracles can be viewed here: - -- ~~[HNT Price Oracle](https://explorer.solana.com/address/horUtvuHQFWxPFrZ35YZUmXUZ2TSQdSXhcD4kkCVNKi/anchor-account)~~ - Handled by [Pyth HNT-USD](https://pyth.network/price-feeds/crypto-hnt-usd) as of May 11, 2023. -- [IOT Price Oracle](https://explorer.solana.com/address/iortGU2NMgWc256XDBz2mQnmjPfKUMezJ4BWfayEZY3/anchor-account) -- [MOBILE Price Oracle](https://explorer.solana.com/address/moraMdsjyPFz8Lp1RJGoW4bQriSF5mHE7Evxt7hytSF/anchor-account) - - - -## Pyth Price Oracle - -The Helium Network uses the tried and tested [Pyth Network](https://pyth.network/), which publishes -financial market data. As an overview, Pyth works by having publishers (exchanges and market-making -firms) submit price points for given token pair values and then aggregates this data, making it -available on-chain. - -Pyth's -[exponentially-weighted moving average (EMA) price aggregation](https://docs.pyth.network/how-pyth-works/ema-price-aggregation) -adds time to the aggregation with a heavier weight given to more recent price samples, smoothing the -price and controlling for outliers to help further increase trust in the price and help shield -against potential bad actors. - -```mermaid -%%{ init: { 'flowchart': { 'curve': 'linear' } } }%% -flowchart TD; - maker1(Exchange or Market Maker)-->|Price Point Submissions|Pyth; - maker2(Exchange or Market Maker)-->|Price Point Submissions|Pyth; - maker3(Exchange or Market Maker)-->|Price Point Submissions|Pyth; - Pyth(Pyth)-->|Publish Aggregate|blockchain[(Solana Blockchain)]; -``` diff --git a/docs/oracles/rewards-oracles.mdx b/docs/oracles/rewards-oracles.mdx deleted file mode 100644 index b017305fe..000000000 --- a/docs/oracles/rewards-oracles.mdx +++ /dev/null @@ -1,143 +0,0 @@ ---- -id: rewards-oracles -title: Rewards Oracles -pagination_label: Rewards Oracles -sidebar_label: Rewards Oracles -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /oracles/rewards-oracles ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -There are initially three Rewards Oracles, one for each subDAO (MOBILE and IOT) and one for HNT, -which ingest the work of all of the above Oracles to determine the appropriate emissions for each -subDAO. - -Epochs will increase from around 30 blocks (or about 30 minutes) to 24 hours, with rewards issued -every 24 hours by each Reward Oracle. - -## Lazy Distribution of Rewards - -On the Solana L1, Rewards will now be "lazily distributed" to each Hotspot, meaning that instead of -passively receiving tokens, Hotspot Owners will _redeem_ them. - -When a Hotspot Owner makes a redemption request, the Rewards Oracle will compute the difference -between the `lifetime` and `claimed` token Rewards to determine the amount of unclaimed tokens per -Hotspot. It will then pre-sign a transaction which the Hotspot Owner will submit to the blockchain. -It is only at this point that Rewards will be registered on-chain and associated with the owning -Helium Wallet. - -## IOT Rewards Oracle - -The IOT Rewards Oracle combines the Verified PoC Receipts, the Verified IOT Data Transfer Receipts, -and the veHNT backing the IOT Network and emits rewards to each Hotspot. - -As a reminder, the Data Transfer Verifier and the PoC Verifier already do much of the heavy lifting -by including the shares each Hotspot should receive. - -## MOBILE Rewards Oracle - -The MOBILE Rewards Oracle combines the Verified MOBILE Receipts, the Verified MOBILE Data Transfer -Receipts, and the veHNT backing the MOBILE Network and emits rewards to each Hotspot. - -## HNT Rewards Oracle - -As defined in [HIP-51](https://github.com/helium/HIP/blob/main/0051-helium-dao.md), the HNT Rewards -Oracle will issue HNT Reward emissions to each subDAOs treasury using each subDAOs Utility Score to -determine which percentage of the total rewards each subDAO is due. - -The following comprise the subDAO Utility Score: - -- subDAO's DCs burned in USD -- subDAO's active device count and device activation fee -- veHNT backing each subDAO - -DC burned, active device count, and veHNT staked are submitted to the chain through the proxy of -[Switchboard](https://switchboard.xyz/) to facilitate this process and keep a record. - -Device count is a fluctuating number based on recent PoC activity and is not readily available -on-chain; a dedicated Oracle will submit device count to the blockchain via Switchboard. - -```mermaid -%%{ init: { 'flowchart': { 'curve': 'linear' } } }%% -flowchart LR - %% entities - solanaBlockchain[(Solana Blockchain)] - - iotTransferReceipts[(Verified IOT Transfer Receipts)] - iotPoCReceipts[(Verified IOT PoC Receipts)] - - iotRewardsOracle[IOT Rewards Oracle] - iotHotspot[IOT Hotspot] - - iotTreasury[IOT Treasury] - - mobileTransferReceipts[(Verified MOBILE Transfer Receipts)] - mobilePoCReceipts[(Verified MOBILE PoC Receipts)] - - mobileRewardsOracle[MOBILE Rewards Oracle] - mobileHotspot[MOBILE Hotspot] - - mobileTreasury[MOBILE Treasury] - - hntRewardsOracle[HNT Rewards Oracle] - - walletIOTBalance[Wallet IOT Balance]; - walletHNTBalance[Wallet HNT Balance]; - walletMOBILEBalance[Wallet MOBILE Balance]; - - %% flows - subgraph Wallet - walletHNTBalance; - walletIOTBalance; - walletMOBILEBalance; - end - - subgraph IOT subDAO - iotTransferReceipts-->iotRewardsOracle - iotPoCReceipts-->iotRewardsOracle - iotRewardsOracle-->iotHotspot - end - iotHotspot-->|IOT Redemption|walletIOTBalance --> |Burn IOT for HNT|iotTreasury - - subgraph MOBILE subDAO - mobileTransferReceipts-->mobileRewardsOracle - mobilePoCReceipts-->mobileRewardsOracle - mobileRewardsOracle-->mobileHotspot - end - mobileHotspot-->|MOBILE Redemption|walletMOBILEBalance --> |Burn MOBILE for HNT|mobileTreasury - - hntRewardsOracle-->|HNT emisions|iotTreasury & mobileTreasury -->|HNT from burn transaction|walletHNTBalance - - subgraph Blockchain - solanaBlockchain-->|veHNT backing IOT|iotRewardsOracle - solanaBlockchain-->|utility score metrics|hntRewardsOracle - solanaBlockchain-->|veHNT backing MOBILE|mobileRewardsOracle - end - -``` - -## SubDAO to HNT Conversion - -Each subDAO is responsible for defining its Treasury Reserve Decentralized Network Token (DNT) -Market Making Curve. - -The curves for -[IOT](https://github.com/helium/HIP/blob/main/0052-iot-dao.md#treasury-reserve-dnt-market-making-curve) -and [MOBILE](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md) can be found in their -respective HIPs. - -This is a "one-way" transaction to convert your subDNT into HNT, as you can not burn HNT for subDNT. - -## Other Notes - -- Initially, all of these Oracles will be run by the Helium Foundation, with the long-term goal that - community members will also run them. -- The buckets with raw PoC and Data Transfer receipts will be available for verification/security - purposes. -- During the transition to Solana, data transmission will be temporarily interrupted while Makers - roll out the new `gateway-rs` image, which will tell Hotspots to communicate with the packet - routers instead of LNS state channels. -- To learn more about how staking and governance will change, refer to the documentation on - [Voting Power](/governance/faq). diff --git a/docs/solana/compression-nfts.mdx b/docs/solana/compression-nfts.mdx deleted file mode 100644 index 8f083113d..000000000 --- a/docs/solana/compression-nfts.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -id: compression-nfts -title: Compression NFTs -pagination_label: Compression NFTs -sidebar_label: Compression NFTs -description: Helium Compression NFTs Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/compression-nfts ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning 🚧 This document is a work in progress. 🚧 - -The documentation on Solana and the upcoming Migration is under development and subject to change. - -::: diff --git a/docs/solana/introduction.mdx b/docs/solana/introduction.mdx deleted file mode 100644 index f0d3f31d6..000000000 --- a/docs/solana/introduction.mdx +++ /dev/null @@ -1,148 +0,0 @@ ---- -id: solana -title: Solana Introduction -pagination_label: Solana Introduction -sidebar_label: Introduction -description: Solana Introduction -image: https://docs.helium.com/img/link-image.png -slug: /solana ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Major Milestones - -- Available on Solana devnet for testing [Complete] -- sec3 Smart Contract Audit - [[Complete](https://github.com/sec3-service/reports/blob/master/reports/sec3_helium_program_library_report.pdf)] -- Mainnet Launch [Complete] - -### Migration Process Steps - -The migration to Solana took place on April 18, 2023, beginning at 9am PST. The team held a 48-hour -window to complete the migration. Hotspots and LoRaWAN devices continued to operate throughout the -migration window. - -1. The Helium blockchain officially halted. -2. A snapshot was taken of Helium chain state. -3. Existing $HNT and $MOBILE were mapped to Solana. Hotspots were minted as NFTs. -4. During the Migration, PoC and Data Transfer continued to function through the off-chain Oracle, - rewards were claimable after the transition phase (estimated 24-48 hours) was complete. -5. Users and Exchanges can access their assets using the same private key on Solana (Solana and - Helium blockchain use the same [ed25519 encryption](https://en.wikipedia.org/wiki/EdDSA) - algorithm.) -6. Programmatic Treasury was activated in 2023 Q2, users will be able to convert $MOBILE and $IOT - into $HNT on chain at that time. - ---- - -## Migration Guides - -As part of the Helium blockchain migration to Solana, there are some changes to existing Helium -Wallets and Applications for users to be aware of. - -Complete [migration guides](/solana/migration/) have been written for different users of Helium. - -:::info Hotspot NFTs and Token Management - -The Helium Network move to the Solana blockchain will result in all Hotspots automatically becoming -[Solana NFTs](https://solana.com/developers/nfts) which, along with the Helium Network Tokens (HNT, -IOT, and MOBILE), can be viewed in the [Helium Wallet app](/wallets/helium-wallet-app). - -::: - ---- - -## Helium Programs on Solana - -The code for all of these Programs is open source, and available in the -[helium-program-library](https://github.com/helium/helium-program-library) repository on Github. - -:::info Program Audits - -The Helium Programs have been audited by [sec3](https://www.sec3.dev/). The audit report was -published March 20, 2023. The audit report is available from sec3 on their -[GitHub reports repo](https://github.com/sec3-service/reports/blob/master/reports/sec3_helium_program_library_report.pdf). - -::: - -#### circuit_breaker - -- Program ID: `circAbx64bbsscPbQzZAUvuXpHqrCe6fLMzc2uKXz9g` -- Generic program wrapping sensitive mint authorities and token accounts in the Helium system to - prevent large movements in the case of an exploit or bug. - -#### data_credits - -- Program ID: `credMBJhYFzfn7NxBMdU4aUqFggAjgztaCcv2Fo6fPT` -- Manages the purchase, delegation, and burning of data credits. - -#### helium_entity_manager - -- Program ID: `hemjuPXBpNvggtaUnN1MwT3wrdhttKEfosTcc2P9Pg8` -- Handles the issuance of NFTs representing entities that are rewardable on the Helium network, such - as Hotspots and mappers. - -#### helium_sub_daos - -- Program ID: `hdaoVTCqhfHHo75XdAMxBKdUqvq1i5bF23sisBqVgGR` -- Manages the DAO/SubDAO structure proposed in HIP-51, including the minting of tokens to subDAOs, - HST holders, and the `lazy_distributor` for PoC earnings. - -#### lazy_distributor - -- Program ID: `1azyuavdMyvsivtNxPoz6SucD18eDHeXzFCUPq5XU7w` -- Allows off-chain Oracles to distribute PoC rewards to rewardable assets (such as Hotspots) that - are represented as NFTs. - -#### lazy_transactions - -- Program ID: `1atrmQs3eq1N2FEYWu6tyTXbCjP4uQwExpjtnhXtS8h` -- Used in the initial migration to Solana, this program allows compressing many transactions into a - merkle root to be executed lazily. This guarantees all transactions are executed exactly once. - -#### treasury_management - -- Program ID: `treaf4wWBBty3fHdyBpo35Mz84M8k3heKXmjmi9vFt5` -- Manages the treasury of each subDAO as proposed in HIP-51, allowing DNT tokens to be swapped for - HNT according to a formula. - -#### voter_stake_registry - -- Program ID: `hvsrNC3NKbcryqDs2DocYHZ9yPKEVzdSjQG6RVtK1s8` -- Handles voting power via veHNT in Helium Governance. - ---- - -## Packages (JS/Typescript) - -| Name | Description | -| ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | -| [@helium/circuit-breaker-sdk](https://github.com/helium/helium-program-library/tree/master/packages/circuit-breaker-sdk) | SDK to circuit breaker program | -| [@helium/data-credits-sdk](https://github.com/helium/helium-program-library/tree/master/packages/data-credits-sdk) | SDK to the data credits program | -| [@helium/distributor-oracle](https://github.com/helium/helium-program-library/tree/master/packages/distributor-oracle) | SDK for interacting with the lazy-distributor oracles to claim rewards | -| [@helium/helium-entity-manager-sdk](https://github.com/helium/helium-program-library/tree/master/packages/helium-entity-manager-sdk) | SDK to the Helium entity manager program | -| [@helium/helium-sub-daos-sdk](https://github.com/helium/helium-program-library/tree/master/packages/helium-sub-daos-sdk) | SDK to Helium sub daos program | -| [@helium/idls](https://github.com/helium/helium-program-library/tree/master/packages/idls) | IDLs containing the typescript definitions for the raw anchor SDKs of our programs | -| [@helium/lazy-distributor-sdk](https://github.com/helium/helium-program-library/tree/master/packages/lazy-distributor-sdk) | SDK to the lazy distributor program | -| [@helium/lazy-transactions-sdk](https://github.com/helium/helium-program-library/tree/master/packages/lazy-transactions-sdk) | SDK to lazy transactions program | -| [@helium/spl-utils](https://github.com/helium/helium-program-library/tree/master/packages/spl-utils) | General utils for interacting with Solana, tokens, etc | -| [@helium/treasury-management-sdk](https://github.com/helium/helium-program-library/tree/master/packages/treasury-management-sdk) | SDK to the treasury management program | -| [@helium/voter-stake-registry-sdk](https://github.com/helium/helium-program-library/tree/master/packages/voter-stake-registry-sdk) | SDK to the voter stake registry program | - ---- - -## Important Addresses and Links - -All the tokens are on the `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` Program. - -The mint IDs are as follows: - -| Name | ID | -| ------ | ------------------------------------------- | -| HNT | hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux | -| MOBILE | mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6 | -| IOT | iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns | -| DC | dcuc8Amr83Wz27ZkQ2K9NS6r8zRpf1J6cvArEBDZDmm | diff --git a/docs/solana/migration-faq.mdx b/docs/solana/migration-faq.mdx deleted file mode 100644 index c1152bfb3..000000000 --- a/docs/solana/migration-faq.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -id: migration-faq -title: Migration FAQ -pagination_label: Migration FAQ -sidebar_label: Migration FAQ -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration-faq ---- - -# FAQ - Solana Migration - -## Why Does My Account Have A Small Amount Of SOL? - -Every migrated Wallet was seeded with a small amount, approximately 0.00139, of SOL for -transactions, enough for roughly 100 transactions. - -If a Wallet displays 1 SOL, the app may be on the `devnet` instead of the `mainnet-beta` view of the -Wallet, be sure to switch to `mainnet-beta` in settings if it's not already. - -If the Wallet still shows 1 SOL while `mainnet-beta` is selected, this display error may resolve by -switching to `devnet` and back to `mainnet-beta`, or updating the app. - -## Where Can I See My Hotspot's Activity And Rewards? - -Oracle Data is available to application developers such as [Helium Geek](https://heliumgeek.com/) -and [Hotspotty](https://app.hotspotty.net/), which are building interfaces to monitor Hotspot -activity and rewards. - -## What Is The IOT Token? - -Instead of earning HNT, Hotspots will earn IOT rewards for their PoC and data transfer. IOT can be -swapped for HNT in the Helium Wallet app or on an exchange. Find more info about IOT -[here](/iot-token). - -## How Do I Stake My Tokens? - -Staking tokens uses [Realms](https://realms.heliumvote.com/dao/hnt) and can be done in the Helium -Wallet app. - -More instructions are available [here](/vote-escrow/realms/). - -## How Can I Exchange Or See The Exchange Rate For My Tokens? - -Here are 2 ways to do this: - -1. On the home screen in the Helium Wallet App, there is an orange button for swapping tokens using - the Treasury. -2. Using a DEX like [Jupiter](https://jup.ag) or [Orca](https://orca.so) - -:::warning - -Treasuries for each Network are very low right now. However, better rates for swapping tokens may be -available using other services. - -::: - -## Why are there so few rewards transactions? - -Rewards are distributed after each epoch, at approximately 1:30 AM UTC daily. - -Hotspots receive rewards for all the activity within an epoch as one sum. - -## Is It Possible To Migrate A Wallet Without Having To Log Into The Helium Wallet App? - -Yes, Wallets can be migrated directly within the Helium docs -[here](/solana/migration/exchange/#mapping-helium-wallets-to-solana-wallets) - -Enter an old Helium address into the entry box and click the "Seed Wallet" button, give it a few -seconds, and the Wallet will be migrated over to Solana. - -## Why Am I Getting The {"Instructionerror":[0, {"Custom":1}]} Error When I Try To Stake? - -This error occurs when a Wallet does not have enough SOL to proceed with a transaction. For example, -a Wallet will need approximately 0.02 SOL to stake. - -Use the [HNT-SOL Swapping widget](/sol-token) in the Helium docs to swap HNT for SOL as needed. - -## When Do I Get My First Rewards For Delegations? - -Rewards for delegations are distributed in the epoch following the delegation. - -For example, a delegation in epoch 10 will receive a rewards distribution at the end of epoch 11 and -every following epoch in which the delegation is unchanged. - -## What Is The Difference Between The Cliff And Constant Locks? - -You can find the explanation for the two in the Helium Docs: - -- [Cliff](/vote-escrow/realms/#cliff) -- [Constant](/vote-escrow/realms/#constant) - -## How Can I Get The New Address To My Wallet? - -Here are 2 ways you can get your new Helium address: - -1. In the Helium Wallet App, Settings > Copy Address > Solana. -2. Using another service Foundation is providing, you can go to this URL, and it will return your - new address. - - ``` - https://migration.web.helium.io/helium/ - ``` - -## How Can I Fix Hotspots Missing On The Helium Wallet App? - -If you are missing Hotspots in the Hotspots tab on the Helium Wallet, click the Filter button and -select All and pull to refresh the page. - -## Why Does My Helium Wallet App Crash When I Open It? - -The Helium Wallet App must be updated to version `2.0.8` or later. - -If your device's App/Play Store is not showing an update button, check manually by clicking on the -app inside the store to see more info, and the button should show "Update" instead of "Open". - -If neither works, save your [seed phrase](/wallets/wallet-seed-phrase), and reinstall the app. diff --git a/docs/solana/migration-overview.mdx b/docs/solana/migration-overview.mdx deleted file mode 100644 index f8841eef6..000000000 --- a/docs/solana/migration-overview.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: migration-overview -title: Solana Migration Overview -pagination_label: Solana Migration Overview -sidebar_label: Solana Migration Overview -description: Solana Migration Overview -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import MigrationStatus from '@site/src/theme/MigrationStatus' - - - -Following the community-driven proposal, [HIP70 - Scaling the Helium Network][hip-70], the Helium -Network was successfully migrated to the Solana blockchain on **April 18, 2023, 9am PST** (16:00 -UTC). This strategic move, voted in by the community, aims to capitalize on Solana's scalability, -low transaction costs, and high-performance capabilities, including its fast transaction throughput -and energy-efficient consensus mechanism. - -The migration to Solana offers key benefits for the Helium Network: it enables the IoT and Mobile -networks to support even greater scale, supports more sophisticated Proof-of-Coverage algorithms, -and enhances the network's robustness, making it an even more robust solution for high-demand -applications. - - - ---- - -:::info Why Solana? - -Read more about the [Helium Improvement Proposal][solana-proposal] and the process of evaluating -Layer 1 blockchains on the [Helium Foundation Blog][l1-evaluation]. - -::: - -[solana-proposal]: - https://medium.com/helium-foundation/hip-70-helium-core-team-proposes-to-migrate-to-solana-e7ea23a042e7 -[l1-evaluation]: - https://medium.com/helium-foundation/hip-70-evaluating-layer-1-blockchains-for-the-helium-network-15f81af6941c -[hip-70]: https://github.com/helium/HIP/blob/main/0070-scaling-helium.md diff --git a/docs/solana/migration/application-builder.mdx b/docs/solana/migration/application-builder.mdx deleted file mode 100644 index 7ad1c0819..000000000 --- a/docs/solana/migration/application-builder.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -id: application-builder -title: Application Builder Migration Guide -pagination_label: Application Builder -sidebar_label: Application Builder -description: Helium Application Builder Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/application-builder ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -As an application builder on top of Helium, many of the APIs and interfaces are changing. - -If you are building against Hotspots, token accounts, or anything blockchain related, you should -start with the [Primer on Solana](/solana/primer) and continue through the -[Solana docs](https://docs.solana.com/). - -If you are building against the Proof of Coverage datasets, you should read through the -[Data-Transfer Oracles documentation](/oracles/data-transfer-oracles). diff --git a/docs/solana/migration/blockchain-api.mdx b/docs/solana/migration/blockchain-api.mdx deleted file mode 100644 index d8936a6ec..000000000 --- a/docs/solana/migration/blockchain-api.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -id: blockchain-api -title: Blockchain API -pagination_label: Blockchain API -sidebar_label: Blockchain API -description: Blockchain API -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/blockchain-api ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The existing [Helium API](/api/blockchain/introduction) will serve only information up to the chain -halt at the time of migration. Knowing that some users will continue to rely on historical data, The -Helium Foundation has formed an agreement with the API provider, BlockJoy, to continue hosting this -API following the migration. - -For ongoing access, several organizations are already building new API services based on the -[Oracle Data](/oracles/oracle-data) available after the migration. These organizations include (but -not limited to), [Hotspotty](https://hotspotty.net/api/), -[HeliumGeek](https://heliumgeek.com/b/helium-offchain-api.html), -[Relay](https://www.relaydevice.com) and [Watchium](https://watchium.disk91.com). diff --git a/docs/solana/migration/blockchain-etl.mdx b/docs/solana/migration/blockchain-etl.mdx deleted file mode 100644 index 7c99c33d5..000000000 --- a/docs/solana/migration/blockchain-etl.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -id: blockchain-etl -title: Blockchain ETL -pagination_label: Blockchain ETL -sidebar_label: Blockchain ETL -description: Blockchain ETL -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/blockchain-etl ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Blockchain ETL](https://github.com/helium/blockchain-etl) will halt along with the blockchain -during the migration. Hosted instances of this service may choose to continue offering historical -data from the Helium L1 via these synced ETLs. A full snapshot of the Helium L1 will be retained and -uploaded for public availability post-migration. - -For ongoing insight into the operation of the Helium Network post-migration, please refer to the -[Oracle Data](/oracles/oracle-data) documentation. diff --git a/docs/solana/migration/blockchain-node.mdx b/docs/solana/migration/blockchain-node.mdx deleted file mode 100644 index 4d8cf1684..000000000 --- a/docs/solana/migration/blockchain-node.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -id: blockchain-node -title: Blockchain Node Migration Guide -pagination_label: Blockchain Node -sidebar_label: Blockchain Node -description: Helium Blockchain Node Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/blockchain-node ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Updated for Solana Mainnet - -The description provided below has been updated to reflect Solana Mainnet. - -::: - -## Migrating wallet to Solana - -As of version [1.1.88](https://github.com/helium/blockchain-node/releases/tag/1.1.88) users can -migrate their `blockchain-node` wallet to a Solana Paper Compatible Wallet. Follow the below -instructions to migrate your wallet on mainnet. - -1. Unlock wallet. - -``` -% http -b :4467 jsonrpc=2.0 id=1 method=wallet_unlock params:='{"address": "13cQ6QUDvebHAppdmLYu9KXJvNZS9voVQCn8XrMbBemiLJ3r8Z5", "password": "[snipped]"}' -{"id":"1","jsonrpc":"2.0","result":true} -``` - -2. Export secret. This exports your secret to a solana.json file. - -``` -$ http -b :4467 jsonrpc=2.0 id=1 method=wallet_export_secret params:='{"address": "13cQ6QUDvebHAppdmLYu9KXJvNZS9voVQCn8XrMbBemiLJ3r8Z5", "path": "/var/data/13cQ6QUDvebHAppdmLYu9KXJvNZS9voVQCn8XrMbBemiLJ3r8Z5.solana.json"}' -{"id":"1","jsonrpc":"2.0","result":true} -``` - -3. Get your Solana address. - -``` -$ http -b https://migration.web.helium.io/helium/13cQ6QUDvebHAppdmLYu9KXJvNZS9voVQCn8XrMbBemiLJ3r8Z5 -{ - "solanaAddress": "6ucMsEXv7KLW9V6dfGYAsx5PF4yy2hAB79nURwTuuzgN" -} -``` - -4. Verify your Solana Public Key. - -``` -$ solana-keygen pubkey /var/data/13cQ6QUDvebHAppdmLYu9KXJvNZS9voVQCn8XrMbBemiLJ3r8Z5.solana.json -6ucMsEXv7KLW9V6dfGYAsx5PF4yy2hAB79nURwTuuzgN -``` - -5. Get the list of serialized transactions, which should be sent to Solana: - -``` -$ http -b https://migration.web.helium.io/migrate/13cQ6QUDvebHAppdmLYu9KXJvNZS9voVQCn8XrMbBemiLJ3r8Z5?limit=1000&offset=0 - -``` - -6. Submit the transactions to Solana. You can see typescript code demonstrating how to use this - [here](https://github.com/helium/helium-program-library/blob/master/packages/migration-service/src/test-submit.ts#L37). - -Alternatively, you can use the -[Migration Widget](/solana/migration/exchange#mapping-helium-wallets-to-solana-wallets) or -[command line utility](https://github.com/helium/helium-program-library/releases/tag/v0.0.27-migration-cli) -for steps 5-6. Example command provided below for the command line utility: - -``` -$ env MIGRATION_SERVICE_URL=https://migration.web.helium.io env SOLANA_URL=https:/api.mainnet-beta.solana.com env SOLANA_WSS_URL=wss://api.mainnet-beta.solana.com ./migration-tx-executor --wallet 6ucMsEXv7KLW9V6dfGYAsx5PF4yy2hAB79nURwTuuzgN -``` - -7. Verify your token balance on devnet using a public explorer. Solana Explorer listed below. - -``` -https://explorer.solana.com/address/6ucMsEXv7KLW9V6dfGYAsx5PF4yy2hAB79nURwTuuzgN -``` diff --git a/docs/solana/migration/console-operator.mdx b/docs/solana/migration/console-operator.mdx deleted file mode 100644 index 9dec8c90f..000000000 --- a/docs/solana/migration/console-operator.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -id: console-operator -title: Console Operator -pagination_label: Console Operator -sidebar_label: Console Operator -description: Console Operator Migration -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/console-operator ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Please be advised that you must upgrade your instance of Helium Console to the latest version to -ensure the continued operation of devices managed by your LNS. Failure to upgrade before the Solana -Migration will result in interruptions to packet transfer for your devices. diff --git a/docs/solana/migration/exchange.mdx b/docs/solana/migration/exchange.mdx deleted file mode 100644 index b92d25b04..000000000 --- a/docs/solana/migration/exchange.mdx +++ /dev/null @@ -1,167 +0,0 @@ ---- -id: exchange -title: Exchange Operator Migration Guide -pagination_label: Exchange Operator -sidebar_label: Exchange Operator -description: Helium Exchange Operator Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/exchange ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning Updated for Solana Mainnet - -The [Migration Widget](/solana/migration/exchange#mapping-helium-wallets-to-solana-wallets) and -description provided below have been updated to reflect Solana Mainnet. - -::: - -The Helium Network is migrating to the Solana blockchain. All Helium Network Tokens (HNT, IOT, and -MOBILE), will become [Solana SPL](https://spl.solana.com/token) tokens. - -If an exchange already supports SPL tokens, follow the steps below. - -:::tip SPL token Support - -Please refer to the Solana Documentation on how to -[Add Solana to Your Exchange](https://docs.solana.com/integrations/exchange) for details. - -::: - -## Mint IDs - -All Helium Network Tokens are available on the -[`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`](https://explorer.solana.com/address/TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) -program, and mint IDs exist both on `mainnet-beta` and `devnet` for testing. - -The mint IDs are as follows: - -| Name | ID | -| ------ | ------------------------------------------- | -| HNT | hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux | -| MOBILE | mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6 | -| IOT | iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns | -| DC | dcuc8Amr83Wz27ZkQ2K9NS6r8zRpf1J6cvArEBDZDmm | - ---- - -## Mapping Helium Wallets to Solana Wallets - -Helium Wallets use the same ED25519 curve as Solana Wallets, resulting in Helium public keys and -secret keys mapping directly to Solana Wallets. - -You can either migrate your wallet using this widget: - -import { MigrateWallet } from '@theme/MigrateWallet' - - - -Or continue reading for manual instructions: - -### JavaScript - -To get the Solana public key equivalent of a Helium public key in javascript run: - - -```javascript -import Address from "@helium/address"; -import { PublicKey } from "@solana/web3.js" - -const addr = Address.fromB58("...helium pubkey..."); - -// Gets the solana pubkey -new PublicKey(addr.publicKey).toBase58() -``` - -To get a Solana equivalent `Keypair` from a Helium `Keypair`: - - -```javascript -import { Keypair } from "@helium/crypto"; -import { Keypair as SolanaKeypair } from "@solana/web3.js" - -const solanaKeypair = SolanaKeypair.fromSecretKey(heliumKeypair.privateKey); -``` - -### Rust - -In rust, to get a pubkey: - -```rust -let helium_pubkey_bytes = helium_pubkey.to_vec(); - -let solana_pubkey = solana_sdk::pubkey::Pubkey::new(&helium_pubkey_bytes[1..]); -println!("solana public key: {}", solana_pubkey); -``` - -To map a keypair: - -```rust -solana_sdk::signature::Keypair::from_bytes(helium_keypair.secret_to_vec()) -``` - -:::tip Migration API - -The Migration API can be used to retrieve the Solana Wallet address from a Helium Wallet address. - -`https://migration.web.helium.io/helium/*helium-wallet-address*` - -::: - ---- - -## Wallet Migration - -Wallets will need to be inflated on Solana. In essence this is recreating the Wallet's Helium state -on Solana. - -The -[migration-service](https://github.com/helium/helium-program-library/tree/master/packages/migration-service) -can be used to migrate wallet(s) to Solana. - -For the Helium Wallet app users, the Wallet requests the migration-service to get the needed -transaction and submits them to the Solana blockchain when the app is opened for the first time -after the Migration is complete. - -Since exchange Wallets may not use the Helium Wallet app, the migration service can instead be used -directly by following the below steps: - -For mainnet: - -1. Get the Solana Wallet address from a Helium Wallet address: - `https://migration.web.helium.io/helium/*helium-wallet-address*` - -2. Get the list of serialized transactions, which should be sent to Solana: - `https://migration.web.helium.io/migrate/*solana-wallet-address*?limit=1000&offset=0` - -3. Submit the transactions to Solana. You can see typescript code demonstrating how to use this - [here](https://github.com/helium/helium-program-library/blob/master/packages/migration-service/src/test-submit.ts#L37). - - Note: Each transaction is only allowed to execute once. - -Alternatively, you can use the -[command line utility](https://github.com/helium/helium-program-library/releases/tag/v0.0.27-migration-cli) -for steps 2-3. - -``` -$ env MIGRATION_SERVICE_URL=https://migration.web.helium.io env SOLANA_URL=https:/api.mainnet-beta.solana.com env SOLANA_WSS_URL=wss://api.mainnet-beta.solana.com ./migration-tx-executor --wallet *your-solana-wallet* -``` - -## Trustless Wallet Migration - -The tools listed above are convenient but rely on the migration service provided by the Helium -Foundation. - -The on-chain implementation of the migration is trustless, and the full state of the Helium -blockchain will be converted to a list of Solana transactions and compressed into a Merkle Tree root -on Solana. - -Any entity providing the proper proof that the provided transactions are valid can execute the -transactions to inflate a wallet. Each transaction is only allowed to execute once. - -If you would like a copy of the database serving the proofs for the migration service, please -[contact the Helium Foundation](mailto:hello@helium.foundation). - -This database copy can be used to run an instance of the -[migration service](https://github.com/helium/helium-program-library/tree/master/packages/migration-service) diff --git a/docs/solana/migration/governance.mdx b/docs/solana/migration/governance.mdx deleted file mode 100644 index 614de12e2..000000000 --- a/docs/solana/migration/governance.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -id: governance -title: Governance Migration Guide -pagination_label: Governance -sidebar_label: Governance -description: Helium Governance Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/governance ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Helium Vote][helium-vote] will transition to using [Solana SPL Governance Realms][realms]. - -While the user interface will change, the governance process will remain mostly the same. - -Using the Helium Wallet app, users will use an embedded browser to visit -[https://helium.vote][helium-vote], connect a Wallet, and vote yes/no on proposals. Ledger users, or -users of any other Solana Wallet, can also navigate to [https://helium.vote][helium-vote], connect a -wallet, and vote. - ---- - -## Governance Changes - -The major change with Solana governance is that more of the Helium Network can be governed by the -Helium DAO and its subDAOS. Everything from Program (smart contract) changes to approving Makers can -now be controlled by the Helium DAO and its subDAOs. - -[helium-vote]: https://helium.vote -[realms]: https://app.realms.today diff --git a/docs/solana/migration/hotspot-maker.mdx b/docs/solana/migration/hotspot-maker.mdx deleted file mode 100644 index 3a3952024..000000000 --- a/docs/solana/migration/hotspot-maker.mdx +++ /dev/null @@ -1,397 +0,0 @@ ---- -id: maker -title: Maker App 2.0 Upgrade Guide -pagination_label: Hotspot Maker App -sidebar_label: Hotspot Maker App -description: Helium Hotspot Maker App Migration Docs -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/maker ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Update and Add New Dependencies - -```json -"@helium/address": "^4.8.1", -"@helium/currency-utils": "^0.0.26", -"@helium/react-native-sdk": "2.0.0", -"@helium/wallet-link": "^4.8.3", -"@metaplex-foundation/mpl-bubblegum": "^0.6.2", -"@pythnetwork/client": "^2.11.0", -"@solana/web3.js": "^1.73.0", -"axios-retry": "^3.3.1", -"cipher-base": "^1.0.4", -"stream": "^0.0.2" -``` - ---- - -## Update App Providers - -Apps must now be wrapped in a `` and the `baseUrl` for `` has -changed - -A Solana Provider must be set with a Solana RPC. Because Helium makes use of Compressed NFTs, there -are currently 3 RPC providers with support: - -- [GenesysGo](https://genesysgo.com/) -- [Helius](https://helius.xyz/) -- [Triton](https://triton.one) - -You can visit their websites and get set up with an RPC url. - -```tsx -// src/App.tsx -const { walletLinkToken } = useSelector((state: RootState) => state.app) -const [heliumWallet, setHeliumWallet] = useState() - -useEffect(() => { - if (!walletLinkToken) { - if (heliumWallet) { - setHeliumWallet('') - } - return - } - - getAddress().then(setHeliumWallet) -}, [heliumWallet, walletLinkToken]) - -//////////////////////////////////////////////////// -//👇👇👇 new provider 👇👇👇 ///////////////////////// - - {/* ////////////////////////////////////////////////////////////// - Remove the /v2 from your onboarding url 👉👉👉👉👉👉👉👉👇 - ///////////////////////////////////////////////////////////👇 */} - - -{/* The Rest of your app... */} -``` - ---- - -## Testing Solana Pre-Migration - -Before the migration to Solana has been completed, the v2 onboarding server will be used, and -transactions will still be submitted to the Helium blockchain. To test Solana before transition, use -these variables: - -**_IT IS CRITICALLY IMPORTANT THAT YOU ONLY USE THESE FOR TESTING._** - -```tsx -// src/App.tsx - - -``` - -For testing against devnet, you can use our testing maker: - -``` -ONBOARDING_MAKER_ADDRESS="14neTgRNZui1hSiHgE3LXjSfwkPU8BEB192MLXXDFnSY2xKjH51" -ONBOARDING_AUTH_TOKEN="pk_TgclExRP7rEXAEQlSgrrDwaZUHJAPcw/nNfkEpWOPCk=:sk_E1xc9OVq1/5oKLGD4RzxST7bl+LMnJhalkQ3vZp/QbOjNltvAmHyPolzA0Pb2HyTD68mZp4lETuC19Y+vI72nA=" -ONBOARDING_MAKER_NAME="Test Maker" -``` - ---- - -## Onboarding a Hotspot - -When onboarding a Hotspot you must specify which `hotspotTypes` it supports (eg `iot` , `mobile`) - -You can optionally set `elevation`, `gain`, `lat`, and `lng` to avoid having to create a second -transaction. - -### Create Onboard Transactions - -`src/features/hotspots/setup/HotspotSetupConfirmLocationScreen.tsx` - -```tsx -const { getOnboardingRecord, getOnboardTransactions } = useOnboarding() - -let hotspotTypes = [] as HotspotType[] -const onboardingRecord = await getOnboardingRecord(params.hotspotAddress) -/* - TODO: Determine which network types this Hotspot supports - Could possibly use your maker address -*/ -if (Config.MAKER_ADDRESS_5G === onboardingRecord?.maker.address) { - hotspotTypes = ['iot', 'mobile'] -} else { - hotspotTypes = ['iot'] -} - -const onboardData = await getOnboardTransactions({ - txn: params.addGatewayTxn, - hotspotAddress: params.hotspotAddress, - hotspotTypes, - elevation, - decimalGain: gain, - lat, - lng, -}) - -// pre-solana this txn will exist -setAddGatewayTxn(onboardData.addGatewayTxn) - -// post-solana these txn(s) will exist -setSolanaTransactions(onboardData.solanaTransactions) -``` - ---- - -## Updating a Hotspot - -When updating a Hotspot you must specify which `hotspotTypes` it supports (eg `iot` , `mobile`) - -### Create transactions - -```tsx -// src/features/hotspots/setup/HotspotSetupConfirmLocationScreen.tsx -const { getAssertData, getOnboardingRecord } = useOnboarding() -const data = await getAssertData({ - decimalGain: gain, - elevation, - gateway: params.hotspotAddress, - lat, - lng, - owner: userAddress, - onboardingRecord, - hotspotTypes, -}) - -setAssertData(data) -setAssertLocationTxn(data.assertLocationTxn) -setSolanaTransactions(data.solanaTransactions) -``` - ---- - -## Transferring a Hotspot - -```tsx -// src/features/transferHotspot/TransferHotspot.tsx -const { createTransferTransaction } = useOnboarding() - -const { solanaTransactions, transferHotspotTxn } = await createTransferTransaction({ - hotspotAddress, - userAddress, - newOwnerAddress, -}) -``` - ---- - -## Linking to Helium Wallet app for Signing - -You must add `solanaTransactions` to the signature request - -`src/features/hotspots/setup/HotspotTxnsProgressScreen.tsx` - -```tsx -const updateParams = { - token, - platform: Platform.OS, - addGatewayTxn, - assertLocationTxn, - transferHotspotTxn, - solanaTransactions, // <---- !important! -} as SignHotspotRequest -const url = createUpdateHotspotUrl(updateParams) -Linking.openURL(url) -``` - ---- - -## Submit Signed Transaction(s) - -```tsx -// src/features/hotspots/setup/HotspotTxnsSubmitScreen.tsx -const { submitTransactions } = useOnboarding() -const { pendingAssertTxn, pendingGatewayTxn, pendingTransferTxn, solanaTxnIds } = - await submitTransactions({ - addGatewayTxn: params.gatewayTxn, - assertLocationTxn: params.assertTxn, - hotspotAddress: params.gatewayAddress, - solanaTransactions, - transferHotspotTxn: params.transferTxn, - }) -``` - ---- - -## Fetching Hotspots - -```tsx -const { getHotspots, getHotspotDetails } = useOnboarding() - -useEffect(() => { - getHotspots({ - heliumAddress, - // makerName: Config.MAKER_NAME, - }) -}, []) - -useEffect(() => { - getHotspotDetails({ - address: hotspot.address, - type: hotspotTypes[0], // The types you support ('IOT', 'MOBILE') - }) -}, []) -``` - ---- - -## Update Wallet Link - -The Helium Hotspot App is deprecated, Maker Apps should link to the Helium Wallet app. Add the hook -`useCheckWalletLink()` to `src/App.tsx` It will check to see if the user is linked to the Hotspot -app and prompt them to update their link - -```tsx -// src/App.tsx -import useCheckWalletLink from './utils/useCheckWalletLink' -const App = () => { - useCheckWalletLink() -} -``` - -Remove the ability for a new user to link to the Hotspot app. On the Welcome Screen you can now just -link directly to the black Helium Wallet app. - -```tsx -// src/features/onboarding/welcome/WelcomeScreen.tsx -const { walletApp } = useDelegateApps() - -const importAccount = useCallback(() => { - try { - const url = createWalletLinkUrl({ - universalLink: walletApp?.universalLink, - requestAppId: getBundleId(), - callbackUrl: 'makerappscheme://', - appName: 'Maker App', - }) - - Linking.openURL(url) - } catch (error) { - // eslint-disable-next-line no-console - console.error(error) - } -}, [walletApp?.universalLink]) -``` - ---- - -## New Android 13 Permissions - -Bluetooth scanning requires two new permissions on Android - -`AndroidManifest.xml` - -```xml - - -``` - -You must request these 3 permissions before scanning for bluetooth - -```tsx -const permissions = [ - PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, - PERMISSIONS.ANDROID.BLUETOOTH_CONNECT, - PERMISSIONS.ANDROID.BLUETOOTH_SCAN, -] -``` - -The Maker Starter is now using `react-native-permissions` to request/check permissions. If you'd -like to use the library, the setup guide can be found here - - ---- - -## Data Credits and SOL for Onboarding - -:::info - -Maker Wallets will need both `SOL` for transactions on the Solana blockchain and `DC` for onboarding -fees post Migration. - -::: - -### Maker Wallet SOL - -Maker Wallets will need `SOL` to pay transaction fees and for minting new Hotspot NFTs. Note that -minting is only required if Makers are attempting to mint more than 2x their existing fleet size. - -- For most Makers, ~10 SOL is recommended. -- Makers with large fleets (300k+ Hotspots) ~60 SOL is recommended. - -#### Minting Cost Examples - -| Hotspots to Mint | SOL Needed | -| ---------------: | ---------: | -| 25,000 | ~14.8324 | -| 50,000 | ~29.4431 | -| 75,000 | ~58.6499 | -| 100,000 | ~58.6499 | - -For more insight to the amount of SOL needed, check out -[https://compressed.app/](https://compressed.app/) - -- Enter the number of Hotspots to mint in the `How many compressed NFTs do you want to store?` - field. -- The `Most composable, highest cost` value is a good approximation, round up when in doubt. - -
- Helium Wallet app token swap screen -
- -> Minting 100,000 Hotspots would require ~58.6499 SOL in this example. - -### Maker Wallet DC - -Maker Wallets will need `DC` to pay Helium onboarding and assert fees. DC can be acquired by either - -- Depositing DC into the Maker Wallet on the current Helium L1. -- Use the Helium Wallet app to swap HNT for DC. - -
-
-
- Helium Wallet app token swap screen -

- Use the Orange Swap button on the Helium Wallet app home screen to swap HNT for - DC. -

-
-
- Helium Wallet app token swap screen -

- Select HNT in the drop-down list to swap for DC. -

-

- Use the Maker Wallet in the recipient field. -

-
-
-
diff --git a/docs/solana/migration/hotspot-operator.mdx b/docs/solana/migration/hotspot-operator.mdx deleted file mode 100644 index 5262c4388..000000000 --- a/docs/solana/migration/hotspot-operator.mdx +++ /dev/null @@ -1,146 +0,0 @@ ---- -id: hotspot-operator -title: Hotspot Operator Migration Guide -pagination_label: Hotspot Operator -sidebar_label: Hotspot Operator -description: Helium Hotspot Operator Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/hotspot-operator ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -No action is required of Hotspot Operators to prepare or partake in the Solana Migration. - -Some important notes: - -- Hotspots will stop mining HNT tokens. -- Hotspots will begin mining IOT tokens. -- Hotspots will become NFTs on the Solana Blockchain, visible in the Helium Wallet App. -- IOT Rewards are earned and accumulated to the Hotspot, and must be "claimed". -- Existing HNT tokens will remain HNT tokens. - -All existing Helium Hotspots from all Hotspot Manufacturers will become "LoRaWAN Hotspots". - -At the time of the Solana Migration, all existing "5G Hotspots" on the Helium Network were _also_ -LoRaWAN Hotspots but may not be enabled to operate as an active LoRaWAN hotspot. - -During the Solana Migration downtime, the 24-hour period in which the state of the Helium L1 -blockchain migrates to the Solana blockchain, the Helium Wallet App will present a "transitioning" -screen and will not accept transaction requests. - ---- - -## Reward Distribution and Claiming - -All LoRaWAN Hotspots will be rewarded in the new IOT subDAO token instead of HNT. - -Rewards will accumulate to each Hotspot, not directly to a Wallet, and must be "claimed" before they -will be in the owning Wallet. - -There is no limit to how frequently nor how many times a Wallet can claim rewards from a Hotspot, -keeping in mind that every claim requires a small transaction fee in SOL. - -:::info claiming fees - -At the time of the Solana Migration, each claiming transaction will be a fraction of a cent in SOL. - -::: - ---- - -## Wallets With 50+ Hotspots - -Wallets with a large number, 50 or more, of Hotspots may need to wait up to 48 hours after the -Solana Migration completes to see all Hotspots in the Helium Wallet App. - -Because claiming is an explicit action, enlisting a service to claim rewards on all of associated -Hotspots can be used. Information on these claiming services will be provided as they become -available. - - - ---- - -## IOT Pre-mine - -As described in [HIP-52: IOT subDAO](https://github.com/helium/HIP/blob/main/0052-iot-dao.md) the -launch of the IoT subnetwork will include a pre-mine of 5 billion IOT tokens to Validators and -Hotspots on the existing IoT network. - -The IOT Pre-mine will reward Hotspots contributing and earning on the Network within the 30 days -preceding the Solana Migration Snapshot. - -:::info What is a Snapshot? - -When the Helium L1 blockchain halts, a "snapshot" of the state of the Network occurs. The Snapshot -is a record of the final state of the Helium L1 blockchain. - -The migration-service program will use this Snapshot to map existing rewards and Network state to -the Solana blockchain. - -::: - -The pre-mine allocates IOT tokens in the following proportion: - -- Validators: 2.5 billion tokens, distributed proportionately to the amount of HNT staked at the - time of the Snapshot. -- Hotspots: 2.5 billion tokens, distributed to all active Hotspots at the time of the Snapshot. - -### What is an "Active" Hotspot? - -The migration service will consider a Hotspot as "Active" if the Snapshot includes any of the -following: - -- Witnessed and was a valid witness -- Beaconed and had valid witnesses -- Transferred LoRaWAN data and been rewarded for it - -A Hotspot is not "Active" if it: - -- Has not beaconed with valid witnesses -- Has not been a valid witness to a beacon -- Has not passed data and been rewarded for it - -:::caution Hotspots on the Denylist - -Any Hotspot on the Denylist at the time of the Snapshot is not eligible for the pre-mine regardless -of meeting any other criteria. - -::: - -### Data Only Hotspot Eligibility - -:::warning Migration Errors - -A bug in the migration snapshot resulted in Data Only Hotspots not being considered nor rewarded as -part of the IOT Pre-mine. - -Hotspots rewarded for `poc_witness` or `poc_challengee` activity were included in the pre-mine. - -::: - -The migration-service program will allocate rewards to any Data Only Hotspot which has transferred -data within the 30 days preceding the Snapshot. - -### 5G Hotspot Eligibility - -At the time of the Solana Migration, all asserted 5G Hotspots are also valid LoRaWAN Hotspots and -will be allocated pre-mine rewards under the same conditions as LoRaWAN Hotspots. - -:::caution Unasserted 5G Hotspots. - -Unasserted 5G Hotspots will not be eligible for the pre-mine as the Active criteria all require the -Hotspot to have an asserted location recorded on the Helium L1 blockchain. - -::: - -### Validator Eligibility - -The 2.5 billion IOT Token Pre-mine to Validators will be distributed to all Active Validators -proportionately to the amount of HNT staked at the time of the Snapshot. - -The migration service will consider a Validator as "Active" if the Snapshot includes any heartbeat -data from the Validator. - ---- diff --git a/docs/solana/migration/hotspot-owner.mdx b/docs/solana/migration/hotspot-owner.mdx deleted file mode 100644 index bdba99ce0..000000000 --- a/docs/solana/migration/hotspot-owner.mdx +++ /dev/null @@ -1,98 +0,0 @@ ---- -id: hotspot-owner -title: Hotspot Owner Migration -pagination_label: Hotspot Owner Migration -sidebar_label: Hotspot Owner Migration -description: Helium Hotspot Owner Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/hotspot-owner ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -As a Hotspot Owner, you will not need to do anything for the migration. You do not need to power -your Hotspot off, you can leave it on and we'll do the rest! - -If you use the Helium Wallet App, you will see it enter a "transitioning" state during the 24-hour -downtime of the Migration. Once the migration is complete, you can open the app again, and after a -minute or so you should see all of your assets and Hotspots. - -## Reward Distribution - -If you own a LoRaWAN Hotspot, you will now receive IOT tokens as mining rewards instead of HNT. - -On Solana, rewards accumulate to the Hotspot, not directly to a wallet, and must be claimed. You can -claim as often as you would like, keeping in mind that for every claim you pay a small transaction -fee in SOL, that as of writing this is a fraction of a cent. - -## Hotspot owners with 50+ hotspots - -If you own a large number of Hotspots, it may take up to 48 hours after the migration to see all -Hotspots in your app. - -Because claiming is an explicit action now, you may want to enlist a service to claim rewards on all -of your Hotspots. - ---- - -## Hotspots on Solana - -- Hotspots will move to the new Solana blockchain, specifically performing off-chain - Proof-of-Coverage. More information on off-chain PoC can be found in - [HIP-70](https://github.com/helium/HIP/blob/main/0070-scaling-helium.md#implementing-proof-of-coverage-oracles). -- Makers will push a fleet-wide update to all their Hotspots that switches a Hotspot to - automatically beaconing by themselves every 6 hours and sending results to an Off-Chain Oracle. -- Makers must push this mandatory update to their fleet of Hotspots. Failure to do so will mean - their customers cease to mine and stop earning rewards once the blockchain migration is complete. - -### Hotspots Will Earn IOT - -Hotspot Owners will start earning IOT as the blockchain migration will launch the IOT subDAO. To -view IOT earned by your Hotspot, use the Helium Wallet app. 5G Hotspot Owners will continue earning -MOBILE and will additionally begin to earn IOT. - -:::note 5G Hotspot Owners - -Your 5G Hotspot will become an NFT, and your CBRS Radios will remain with a serial number, just like -before the Solana transition. - -::: - -### Hotspots Become NFTs - -All Helium Hotspots will be represented as NFTs on the Solana blockchain. Wallet migration is -required to view your Hotspot NFT(s) in the Helium Wallet app. - -
-
-
- -
-
- -
-
-
-
- Hotspot in the current Helium app. -
-
- Hotspots NFTs in the new Helium Wallet app. -
-
-
-
-

- - Please note these images are for informational purposes only. Final design may change. - -

-
-
-
diff --git a/docs/solana/migration/hotspot-software.mdx b/docs/solana/migration/hotspot-software.mdx deleted file mode 100644 index e77ef21ac..000000000 --- a/docs/solana/migration/hotspot-software.mdx +++ /dev/null @@ -1,160 +0,0 @@ ---- -id: maker-hotspot-software -title: Maker Gateway-rs Upgrade Guide -pagination_label: Hotspot Software -sidebar_label: Hotspot Software -description: Helium Hotspot Software Migration Docs -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/maker-hotspot-software ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -As the miner image transitions to being a gateway-rs-only container, it will stop obeying settings -from the `sys.config` file that most Hotspot Makers use to notify the miner instance of Hotspot -settings. To help Makers with this transition, a list of common configuration items that were -previously configured via `sys.config` are provided along with alternates that will work for -gateway-rs. These configuration items can be set when invoking the miner container or when running -gateway-rs as a stand-alone executable. - -## Gateway-rs Configuration - -At startup, gateway-rs configures itself via two methods: from environment variables and from a -`settings.toml` file. By default, the settings file will be expected in the location -`/etc/helium_gateway/settings.toml`, but this can be overridden with the `-c` flag. However, it is -not recommended that Makers replace the default `settings.toml` file as it contains other important -key items that may change from time to time. Instead, we recommend that Makers supply any necessary -override items via _environment variables_. - -In general, any item in the `settings.toml` file can be overridden by supplying an environment -variable to gateway-rs with a name that is similar to the setting being overridden by prefixing the -settings keyword with the characters `GW_`. - -:::note Example - -To override the `keypair` item in `settings.toml` with the value `example://override`, supply the -environment variable `GW_KEYPAIR=example://override` to gateway-rs at startup. - -::: - -_Note:_ Previous versions of gateway-rs included both a `default.toml` and `settings.toml`. All -configurations are now only made in `settings.toml`. - -### Quick Reference Summary - -These are the configuration variables to migrate from miner to gateway-rs: - -| Erlang Source | Erlang Variable | gateway-rs Environment | Default Value | -| ------------- | -------------------- | ------------------------------------------ | ---------------- | -| `sys.config` | `miner:radio_device` | [`GW_LISTEN`](#packet-forwarder-bind-port) | `127.0.0.1:1680` | -| `sys.config` | `miner:jsonrpc_port` | `GW_API` | `127.0.0.1:4467` | -| `sys.config` | `blockchain:key` | [`GW_KEYPAIR`](#key-configuration) | None | -| Environment | `REGION_OVERRIDE` | [`GW_REGION`](#radio-region) | None | - -### Key Configuration - -Like the miner, gateway-rs requires a cryptographic key to identify and authenticate itself on the -Helium Network. Most Makers have likely relied on the default miner key settings, which instructed -the miner to use the cryptographic identity locked in slot 0 of an ECC608 chip on I2C bus #1 at I2C -address `0x60`/96. For these Makers this old default would have sufficed. - -Unlike the miner, however, gateway-rs does not have any default key setting. Therefore, as a Maker -you must specifically provide gateway-rs with an appropriate setting for your platform. - -If your platform deviated from the miner defaults, then you are likely familiar with the settings -that had to be adjusted in the `blockchain:key` override in sys.config. But, for the sake of -completeness, we'll illustrate all the settings that could have been adjusted in that scheme and -show how they are encoded in the scheme used by gateway-rs. - -For example, if the Erlang miner had been configured with: - -``` -{ blockchain, [ - { key, - { ecc, [ - {key_slot, 2}, - {onboarding_key_slot, 12}, - {bus, "i2c-5"}, - {address, 83} - ]} - } -]} -``` - -Then the equivalent gateway-rs ECC608 configuration would be via these two environment variables: - -``` -GW_KEYPAIR=ecc://i2c-5:83?slot=2 -GW_ONBOARDING=ecc://i2c-5:83?slot=12 -``` - -### Radio Region - -The region variable is the default region used when the Hotspot does not have an asserted location. -Makers need to ensure that the region is set correctly for the region in which the Hotspot is sold -to ensure correct beaconing behavior. - -Under the miner regime, the default radio region was adjusted via the `REGION` environment variable. -In gateway-rs it is specified via the `GW_REGION` environment variable. - -For example, if the Erlang miner had been configured to use the US915 region by default: - -``` -REGION=US915 -``` - -Then the equivalent gateway-rs configuration would be via the environment variable: - -``` -GW_REGION=US915 -``` - -### Packet Forwarder Bind Port - -The default address at which gateway-rs listens for UDP packets from the packet forwarder has not -changed (host `127.0.0.1`, port 1680). However, if you need to change the host or port binding from -this default then you will need to supply a `GW_LISTEN` environment variable. - -For example, if the Erlang miner had been configured with: - -``` -{miner, [ { - {radio_device, {{0, 0, 0, 0}, 1699, deprecated, deprecated}} -``` - -then the equivalent gateway-rs configuration would be via the environment variable: - -``` -GW_LISTEN=0.0.0.0:1699 -``` - -## Logging - -Before the migration, miner handled writing logs to disk. Post migration, helium_gateway outputs on -`stdout` as it has before. It is up to the Maker to integrate with their system's logging setup. -Capturing log output and writing to disk may be handled with a log manager such as `journald` or -`syslogd`. - -## CLI - -The CLI has changed for a few commands, notably the `helium_gateway info` command that some makers -may use now takes a list of info entries to return. The `helium_gateway info --help` output -documents what keys are available. - -## System Startup - -Since gateway-rs no longer releases as an installable package it is up to the maker to integrate the -executable with their system startup setups, (like procd or tini, systemd depending on the operating -system setup) - -## Firewall Configurations - -Makers using outbound firewall rules to restrict outbound connections should allow the following -outbound ports: - -| Purpose | Outbound Port Used | -| --------------------- | ------------------ | -| Configuration Service | TCP/6080 | -| Entropy Oracle | TCP/7080 | -| Packet Router | TCP/8080 | -| Packet Ingest | TCP/9080 | diff --git a/docs/solana/migration/hst.mdx b/docs/solana/migration/hst.mdx deleted file mode 100644 index d6bc7aa02..000000000 --- a/docs/solana/migration/hst.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: hst -title: Helium Security Tokens on Solana -pagination_label: HST Holder -sidebar_label: HST Holder -description: Helium Security Tokens on Solana, how to stake, unstake, and receive HNT. -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/hst ---- - -HST on Solana is implemented via a programmatic Fanout Wallet. - -This technology ensures that when HNT is emitted for an epoch, the HST share of HNT emissions is -subsequently distributed to HST holders. Further, a [clockwork](https://www.clockwork.xyz/) job runs -at 12:30am UTC daily to ensure that epoch's HNT is distributed. This is entirely programmatic, -meaning at no point does any party have custody of your HNT. - -The architecture of the fanout wallet has a few important considerations: - -1. All HST tokens **MUST** be staked at the time of epoch completion in order to receive HNT for - that epoch. -2. HNT can be manually claimed at any time, regardless of whether the clockwork job runs. Solana - blockchain going down will not affect this, though it may affect when an epoch ends. If - clockwork misses a day, when it runs the next day you will receive HNT for all epochs missed. -3. Staked HST tokens will appear in your Wallet as an NFT Named "Staked HST". **DO NOT BURN THIS - NFT OR YOU WILL LOSE YOUR HST**. You can freely transfer this NFT between Wallets. HNT will flow - to the Wallet holding the receipt, and the Wallet holding the receipt is the only Wallet that - can unstake to receive the HST. -4. HST tokens must be unstaked in order to separate out tokens. Once unstaked, you can transfer - freely, and the new Wallet(s) can re-stake then. - -Knowing these considerations, if you wish to unstake your HST tokens, it is important that you -**restake them before the epoch ends at UTC midnight**. - -All HST tokens were **pre-staked** when your balance was moved to Solana during the migration. If -you do not wish to move them, you do not need to do anything. HNT should be claimable in your Wallet -daily at 12:30am UTC. - -You can stake and unstake your HST below. This will prompt you with two transactions. The first will -stake the HST. The second will set up a clockwork job for distributions with enough SOL to last 50 -years. You can connect any Solana compatible Wallet following the Wallet Standard, including the -Helium Wallet App. - -import { HstManager } from '@theme/HstManager' - - diff --git a/docs/solana/migration/ledger.mdx b/docs/solana/migration/ledger.mdx deleted file mode 100644 index 39e60da23..000000000 --- a/docs/solana/migration/ledger.mdx +++ /dev/null @@ -1,107 +0,0 @@ ---- -id: ledger -title: Ledger Hardware Wallet User -pagination_label: Ledger Hardware Wallet User -sidebar_label: Ledger Hardware Wallet User -description: Ledger Hardware Wallet User Documentation -slug: /solana/migration/ledger ---- - -:::caution Post Migration Ledger Actions - -You can test the Helium-Solana Ledger migration before Helium's migration onto Solana Mainnet on -April 18, 2023, but doing so will use Solana Devnet, where your tokens are not real. You will not be -able to migrate your Helium tokens to Solana Mainnet until after the Helium migration completes on -April 19, 2023. - -**If you test the Ledger migration before then, you will need to re-migrate on or after April -19, 2023.** - -You can migrate your tokens any time after April 19, 2023. There is no need to rush to migrate your -tokens unless you want to lock up HNT early to receive the -[3X veHNT Landrush bonus.](/governance/faq/#is-there-a-staking-genesis-period) - -::: - ---- - -## Video Walkthrough - -
- -
- Video of the process in action.{' '} - Click here to watch on YouTube. -
-
- ---- - -## Installing the Helium-Solana App - -Update your Ledger firmware to at least 2.1.0 before you start. - -As of now, we are still waiting on Ledger to release our app. Until then, to install you must follow -these steps: - -1. Open Ledger Live. -2. Go to Settings (top right corner) -3. Click `Experimental Features` -4. Enable `Developer Mode` -5. Install the Helium-Solana app as you normally would. -6. Close Ledger Live - ---- - -## Migrating - -The following utility will migrate all tokens from the Helium derivation path `44'/904'/n'/0'` to -the Solana derivation path `44'/501'/n'/0'`. - -Ledger users will need to update their Helium Ledger App to a version that's pending release. This -upcoming version will use the Solana private key derivation path that moves all your tokens and -balances over to Solana. You may need to uninstall any Solana Ledger Apps during the Wallet -migration process. - ---- - -## Migration Tool - -Your public key will change on Solana, but the private key will remain the same. Note this app only -works with Chrome, Brave, or other Chromium-based web browsers. - -- [Helium-Solana Ledger App](https://github.com/helium/app-helium-solana) now available from Ledger - Live (ensure Developer Mode is enabled) -- [Solana Ledger App](https://support.ledger.com/hc/en-us/articles/360016265659-Solana-SOL-?support=true) - using Ledger Live - -:::note Close Ledger Live - -Before starting these steps, close the Ledger Live application or the transactions will fail. - -::: - -import { LedgerMigration } from '@theme/LedgerMigration' - - - ---- - -## Derivation Paths and your new Public Key - -The Helium Ledger App uses `ED25519` keys, similarly to Solana, but at a different derivation path. - -This means that, while seed phrases are the same, private keys are different on Solana. - -In order to get around this, when you run the migration, the migration application will ask you to -use the old derivation path to approve sending all of your Hotspots, tokens, etc. to the new -derivation path. diff --git a/docs/solana/migration/network-user.mdx b/docs/solana/migration/network-user.mdx deleted file mode 100644 index 9ee70707f..000000000 --- a/docs/solana/migration/network-user.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -id: network-user -title: Network User Migration Guide -pagination_label: Network User -sidebar_label: Network User -description: Helium Network User Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/network-user ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -As a LoRaWAN Network user, you will not need to do anything during the migration. The network should -continue to function. Data transfer should be unaffected during the Solana Migration. - -During the Solana Migration, users may still purchase Data Credits with a credit card on Console. -However, users will be unable to acquire DC through a direct HNT burn on Console. If you need -additional Data Credits and prefer to burn HNT, please consider doing so before the 4/18 Solana -Migration. - -Core developers will actively monitor Network performance to ensure that systems stay operational. -If you believe that data transfer have been negatively impacted, please post the issue in the -#console channel in the [Helium Discord](https://discord.gg/helium). - - diff --git a/docs/solana/migration/validator-operator.mdx b/docs/solana/migration/validator-operator.mdx deleted file mode 100644 index db3633539..000000000 --- a/docs/solana/migration/validator-operator.mdx +++ /dev/null @@ -1,257 +0,0 @@ ---- -id: validator-operator -title: Validator Operator Migration Guide -pagination_label: Validator Operator -sidebar_label: Validator Operator -description: Helium Validator Operator Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/validator-operator ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -For operators of Helium Validators at the time of the Solana Migration, this guide will outline the -changes you can expect and the steps necessary to continue earning a return for your staked HNT. - -## Prerequisites - -**Before proceeding with the migration, ensure that you have:** - -1. Access to your validator's Wallet, either through the Helium Wallet App or a Ledger hardware - wallet. -1. Familiarized yourself with the new [veHNT](/vehnt) governance model and the concept staking to - subDAOs (IOT and MOBILE). - -:::tip VeHNT, a New Way to Stake: - -After the transition, veHNT will replace staked HNT and will be represented by a non-transferable -Solana NFT held in your Wallet. veHNT grants holders voting rights to influence the future of the -Helium Network and the ability to earn IOT and/or MOBILE through subDAO delegation. - -::: - -## The Landrush Period - -For the first ten days after Helium's transition onto Solana (ending 23:59:59 UTC on April 28, -2023), there will be a 3x multiplier bonus for new veHNT stakers. This includes validator owners -migrating from Staked HNT to veHNT. This is called the "Landrush" multiplier. - -New stakers can only receive this veHNT bonus during the initial ten-day Landrush period. HNT staked -after this period will receive veHNT at the standard rate with no multiplier. - -Positions extended past the default 6-month lock-up period also receive the Landrush multiplier if -set within the initial 10 days. - -For example: - -> Staking 10,000 HNT during this Landrush period with a lock duration of six months gets 375,000 -> veHNT (10,000x12.5x3). The position decays from 375,000 to 0 veHNT at the end of the staking -> period, and 10,000 HNT is returned to the Wallet. - -> Increasing the stake to 20,000 HNT during this Landrush period with a lock duration of 24 months -> returns 3,000,000 veHNT (20,000x50x3). At the end of the staking period, 20,000 HNT is returned to -> the Wallet. - -## Migration Steps - -Follow these steps to migrate your validators: - -**Step 1: Monitor the status of the migration** Communications will be provided throughout the day -of the migration via Twitter & Discord. The migration will begin at 16:00:00 UTC on April 18. After -16:00:00 UTC on April 19, Helium validators can be shut down following comms from core developers. -Validators will no longer produce blocks for the Helium Network and will not receive HNT rewards. - -**Step 2: Access your staked HNT** If you haven't already, move wallets holding staked validators -into the Helium Wallet App. After the migration, your staked HNT will automatically become veHNT and -stay entirely in your Wallet's custody. A non-transferable Solana NFT held in your Wallet represents -veHNT ownership. - -If your validators are staked with HNT on a Ledger, migrate the Ledger Wallet using the -[Ledger Migration Guide](/solana/migration/ledger). - -**Step 3: Automatic conversion to veHNT** On April 18, 2023, all validators still staked or in -cooldown will automatically convert to veHNT with a six-month staking release date, as described in -HIP-70. Each validator will receive 375,000 veHNT as a veHNT position for six months with rolling -lock-up, called "constant lock-up." - -**Step 4: Delegation to subDAOs** Decide which subDAO or combination of subDAOs ([IOT](/iot-token) -and [MOBILE](/mobile-token)) you want to delegate your veHNT to. You can have multiple positions of -veHNT delegated to different subDAOs or for different lock-up periods. Each position of veHNT can -delegate all or nothing of the veHNT. - -Delegation of veHNT can be managed within the [Helium Wallet App](/wallets/helium-wallet-app) using -Realms. - -- [HNT DAO on Realms](https://app.realms.today/dao/HNT) -- [IOT subDAO on Realms](https://app.realms.today/dao/IOT) -- [MOBILE subDAO on Realms](https://app.realms.today/dao/MOBILE) - -**Step 5: Managing lock-up periods** - -Decide if you want to lock up all or part of your veHNT for longer than six months. You can increase -your lock-up period to a maximum of 48 months at any time. If you want to top-up your veHNT position -with more HNT, you must add it to an existing position or transfer it from a position with a lesser -lock-up time. - -**Step 6: Monitor and adjust** - -Monitor your subDAO earnings and adjust your delegations as desired. Remember that as more veHNT is -delegated to a particular subDAO, individual holder earnings will be reduced due to the sharing of -the 6% subDAO token emissions. - -:::important Important notes: - -- Validator Operators must take action to delegate veHNT to enable MOBILE Network or IOT Network - emissions -- Validator Operators must take action to return from a veHNT position to HNT (unstake). - -::: - -## Key Take Aways - -- Until the Solana transition is completed, staked Validators continue to earn HNT rewards for block - production. -- veHNT gives holders voting rights to determine the future of the Helium Network. -- Validators who remain staked receive a 3x veHNT bonus for staked HNT, and their HNT remains locked - up for the six-month lock-up period as defined in HIP 51. -- Stakers will no longer receive a reward in HNT tokens. SubDAO delegation rewards IOT and/or MOBILE - which are convertible to HNT. -- HNT can be released back to the veHNT owner's Wallet after the minimum six-month lock-up period - after selecting the staking cooldown. - ---- - -## Common Questions - -### How Will Staking Rewards Change with veHNT? - -As of February 2, 2023, Oracle Based POC removed the Challenger role from Validators as Hotspots -began to beacon independently. As a result, the PoC Challenger rewards pool returned to Hotspots. - -After HIP-70 and the L1 transition are implemented, the existing Validators will no longer produce -blocks for the Helium Network and will no longer receive HNT rewards. As their staked HNT will -convert to veHNT, these holders can optionally delegate to specific subDAOs. - -Currently, the IOT and MOBILE subDAO have a 6% token emission pool for veHNT stakers. - -After the implementation of HIP-51, HIP-52, and HIP-53, all the subDAOs combined will receive the -non-HST emissions of HNT. This is 68% of emitted HNT and will increase to 69% in the following -yearly emissions change in August 2023. This emissions curve changes annually, so the subDAOs -eventually receive 85% of all future HNT emissions. - -Previously Validator stakers had a Validator performance-based randomized chance at 6% of the daily -distribution of HNT. Now they have a share of 6% of the 68% of the HNT distributed to subDAOs based -on how much HNT for how long they are willing to lock up that HNT. - -### What Happens to my HNT Previously Staked in a Pool? - -Staking Pool providers have all made an effort to contact their customers to return the staked HNT. -Contact the vendor managing your staking pool for more detailed information if you have yet to -receive your HNT. - -### How much veHNT will validators receive? - -Each validator will receive 375,000 veHNT as a veHNT position for six months with rolling lock-up - -called "constant lock-up." - -This amount is calculated as 10,000 HNT x 12.5 multiplier for six months lock-up x 3 for the -Landrush bonus (for early veHNT investors). - -You will receive all the veHNT for each validator as a single sizeable veHNT position if you have -multiple validators. - -### Can I transfer my veHNT to another wallet? - -No, veHNT cannot be transferred to another wallet, but you can move out of one veHNT position into -another within the same wallet. - -### What Is a "Lock-Up" Period? - -A lock-up period is a window of time when users are not allowed to transfer their HNT. - -You will incur a lock-up period when you stake your HNT for veHNT. The lock-up period is between 1 -day and 48 months, selectable in days but with block granularity. - -Lock-up periods help incentivize long-term holders of HNT and deter short-term speculators and those -with shorter-term interests in the governance of the Network. - -The amount of veHNT received for a lock-up period -[can be seen in this table](/governance/faq/#how-much-vehnt-will-i-get-for-each-lock-up-period). - -### What if I do nothing about my validator stake? - -If a validator owner does nothing, the stake will transfer to veHNT automatically. - -The owner will receive 375,000 veHNT per validator in their Wallet as a single position. This -position will not enter a cooldown period automatically. The position will only unlock once the -cooldown option has been initiated. After selecting cooldown, they will get their 10,000 HNT per -validator back in 183 days (6 months) after the date of the cooldown selection. - -Validators will no longer receive any reward in HNT from the transition date. Stakes will need to be -delegated to either the IOT or MOBILE subDAO to get a reward in IOT or MOBILE tokens. A stake can -also be split among subDAOs. - -### What if I want my HNT back? - -The Stake will transfer over to veHNT. - -The owner will receive 375,000 veHNT per validator in their wallet as a single position. The -validator owner must select the cooldown option from within Realms on that position from within the -Helium Wallet App. - -After selecting cooldown, they will get their 10,000 HNT per validator back in 183 days (6 months) -after the date of the cooldown selection. This is like the 250,000 block cooldown period validators -previously had. - -veHNT can be delegated to subDAOs to earn a linearly decreasing reward in IOT or MOBILE tokens while -in cooldown. - -### "Top-up" of veHNT Positions - -You can "top-up" your 375,000 per validator stake with more HNT from a minimum of 1 HNT, and this -must be added to an existing position or transferred from a position of lesser lock-up time. - -Positions started within the Landrush period cannot be topped up AFTER the Landrush period. However, -they can be topped up within the Landrush period. - -### Why hold Multiple veHNT positions? - -It is highly recommended that previous validator owners and large HNT stakers split their single -position received after the transition into several smaller positions immediately upon lock-up and, -when applicable, within ten days after the Solana transition, before 23:59:59 UTC on April 28. - -This is because the subDAO delegation of veHNT is a 0 or 100% all-or-nothing action. - -- Splitting veHNT across multiple subDAOs requires multiple positions. -- Splitting veHNT over different lock-up periods requires multiple positions. -- Splitting veHNT with some in constant lock-up and some in cooldown requires multiple positions. - -Splitting positions after April 28 would mean that the veHNT transferred to the new part of the -split does not inherit the 3x bonus multiplier. As this bonus multiplier only applies to positions -created in the Landrush period. - -Splitting as an action transfers some of the veHNT from one position to another new or existing -position. - -veHNT owners may want to frequently vary their split of subDAO delegations and lock-up periods to -suit their situations and the variance of the HNT per subDAO emitted based on the DAO Utility -Scores. - -### Can I Increase My Staking Lock-up Period At Any Time? - -Yes. You can increase your lock-up period to the maximum of 48 months at any time, and each increase -activates at the start of the next epoch. If the veHNT is delegated, you must undelegate, change the -period and redelegate and lose delegation rewards within that 24-hour epoch. If those three actions -take longer than an epoch or are split over two epochs, then delegation rewards are lost for two -epochs. - -### Can I Decrease My Staking Period For Fast Access to My HNT and Take a Penalty? - -No. You define your lock-up period at the time of staking and cannot unstake or decrease the lock-up -period for any reason. - -### Can I Automate Re-Staking? - -Yes, a constant rolling lock-up period will be the default option called Constant Lock-up. - -Validator owners will be automatically staked for six months with a Constant lock-up. diff --git a/docs/solana/migration/wallet-user.mdx b/docs/solana/migration/wallet-user.mdx deleted file mode 100644 index 5b5a4a102..000000000 --- a/docs/solana/migration/wallet-user.mdx +++ /dev/null @@ -1,286 +0,0 @@ ---- -id: wallet-user -title: Wallet User Migration Guide -pagination_label: Wallet User -sidebar_label: Wallet User -description: Helium Wallet User Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/wallet-user ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This guide provides step-by-step instructions for Helium Wallet app, CLI Wallet, and Ledger Wallet -users to migrate their wallets to the Solana blockchain. - -Wallet migration is necessary to interact with your HNT, DC, MOBILE, IOT, and Hotspots on the Solana -blockchain. You can find Hotspot NFTs in the NFT Collectibles section once Helium on Solana goes -live. Token balances are visible on the account page. You can also create or import multiple -accounts to a maximum of 10 on the Helium Wallet app. - -Existing HNT and MOBILE tokens in your wallets will remain unchanged by this migration. - -## Migration Utility - -You can migrate a wallet using the widget below by entering a Helium or Solana wallet address and -clicking the "Seed Wallet" buttton. - -import { MigrateWallet } from '@theme/MigrateWallet' - - - -## For Helium App Users - -:::caution - -The Helium Hotspot App is no longer used to manage Tokens or perform Wallet activities and instead -is only used to manage Original Helium Hotspots and FreedomFi Hotspots. - -::: - -Helium Hotspot app users must migrate to the Helium Wallet App following these steps. - -To start, ensure your Helium Hotspot app is updated to version **5.0.0** or later and that you have -downloaded the latest Helium Wallet app version **2.0.0** or higher. - -
-
-
-

- Step 1. Open the Helium Hotspot app. -

-
-
-
-
-

- Step 2.Tap Migrate your Wallet in the Wallet migration popup. -

-

The Helium Wallet app will automatically open and complete the Wallet migration.

-
-
- -
-
-
-
-

- Step 2. If you do not see the pop up, tap the Settings menu on the bottom tab bar and - then Export Private Key (Migrate Wallet). -

-
-
-
-
- -
-
-

- Step 2a. Tap Export Private Key -

-
-
-
-
- -
-
-

- Step 2b. Enter a password to secure your private key for migration to the Helium - Wallet app. -

-

- Tap Export to Wallet App. -

-
-
-
-
- -
-
-

- Step 2c. Enter the same Password and tap done. -

-
-
-
-
-

- Step 3. Now your HNT, DC, MOBILE, and Hotspots have successfully moved to the Helium - Wallet app and are ready for the Solana migration. -

-
-
-
- -:::info Public Addresses on Solana - -Your **public** Wallet address will change post-migration, but your **private** key and seed phrase -will remain the same. - -::: - ---- - -## For Helium Wallet App Users - -> Some users may know the Helium Wallet app as the "New Wallet app" or "the black app." - -To migrate to Solana, simply update your Helium Wallet app version to 2.0.0 or newer. That’s it! - -If you have Hotspots in any account, they will appear as an NFT Collectible. All other tokens and -their balances are automatically transferred to the Solana Blockchain under the same token name. - -Your public Wallet address will change, but your private key and seed phrase (12 or 24 word) will -remain the same. - ---- - -## For CLI Wallet Users - -:::caution The Helium CLI Wallet Will Be Deprecated - -The CLI Wallet will be completely deprecated except for exporting private seed phrases and -displaying public Solana addresses. Accordingly, common payment and staking transactions should -utilize the Solana CLI Wallet or the Helium Wallet app. - -Check out the [Solana Documentation](https://docs.solana.com/wallet-guide/cli) for more information -on Solana Command Line Wallets. - -::: - -To migrate a Helium CLI Wallet to Solana, you will need to perform the following steps: - -1. Inflate/seed your Solana-mapped Helium Wallet on Solana -2. Export your private key from the Helium CLI Wallet -3. Import your private key to any of the Solana CLI Wallet, Helium Wallet App, or - [Phantom Wallet](https://phantom.app/). - -### Inflate/seed Solana-mapped Helium Wallet on Solana - -To provide high-level context, during the migration window a chain variable will be issued to cause -the Helium L1 to cease block production after which time a snapshot of Helium Network state will be -taken and loaded onto Solana Mainnet via a data structure (e.g., Merkle Tree). As such, all account -state on the Helium L1 - including that of your CLI wallet - will be available on Solana Mainnet -after the migration window. - -Given the usage of the Merkle Tree, however, you will need to "inflate" or "seed" your Solana-mapped -Helium Wallet on Solana. To do so, there is a **passive means** provided by the Helium Wallet App, -or an **active means** using the -[Migration Widget](/solana/migration/exchange/#mapping-helium-wallets-to-solana-wallets) provided in -the documentation. - -Regarding the **passive means**, you can simply export your Helium private key from the Helium CLI -Wallet and import the Helium private key into the Helium Wallet App in the manner described in steps -2 and 3 below. Once the migration window is complete and Helium Network state has been loaded onto -Solana, you will be able to open the Helium Wallet app and behind the scenes your Wallet will be -inflated on Solana. After that point, you can use the Helium Wallet app to send HNT or MOBILE -transactions on Solana Mainnet. - -Regarding the **active means**, you can use the -[Migration Widget](/solana/migration/exchange/#mapping-helium-wallets-to-solana-wallets). With the -Migration Widget, you need to provide your Helium or Solana-mapped Helium public key into the -Widget, then click the `Seed Wallet` button. After doing so, your Solana-mapped Helium Wallet on -Solana will be inflated. - -_Please note that the Widget as currently provided operates on the Solana Devnet environment but -will be changed to Solana Mainnet during the migration window._ - -### Export private key from the Helium CLI Wallet - -Starting in Helium CLI Wallet -[v1.7.11](https://github.com/helium/helium-wallet-rs/releases/tag/v1.7.11), updates were made to the -`export` command to facilitate exporting private keys in (1) password encrypted QR code format for -import into the Helium Wallet App, (2) raw format for import into a Solana CLI Wallet, and (3) raw -format for import into a Phantom Wallet. For each situation, example Helium CLI Wallet commands are -provided below: - -1. Export raw private key as password encrypted QR code for import into Helium Wallet App - -```sh -helium-wallet export --output qr -``` - -After executing the command, you will first be asked to provide the password for your Wallet, then -will be asked to provide, and confirm, a password to encrypt the QR code of your private key. Once -complete, the command will produce a QR code that can be scanned into the Helium Wallet app, as -described in further detail in step 3 below. - -2. Export raw, Solana-compatible private key for import into Solana CLI wallet - -```sh -helium-wallet -f helium_wallet.key export --output seed > solana_wallet.json -``` - -Here, `helium_wallet.key` corresponds to your private key used for your CLI Wallet. By default, this -is usually named `wallet.key`. The result of the command is then used to create a Solana private -key, which we are naming `solana_wallet.json`. - -3. Export raw, Solana-compatible private key for import into Phantom Wallet - -```sh -helium-wallet export --output seed -``` - -In executing this command, the Solana-compatible private key will be printed `stdout` and will be -displayed in your terminal / command line window. - -### Import private key on Helium Wallet app, Solana CLI Wallet, or Phantom Wallet - -Depending on how you exported your private key from the Helium CLI Wallet, you will either (1) -import your private key into the Helium Wallet app, (2) import your private key into the Solana CLI -Wallet, or (3) import your private key into Phantom Wallet. - -1. Import private key into Helium Wallet app - -If you exported your private key in password encrypted QR code form, you import the private key into -the Helium Wallet app. In particular, on the Helium Wallet app, you will need to navigate to the CLI -QR code reader found at `Add New Account > Import > CLI` and scan the encrypted private key produced -via the Helium CLI Wallet. - -Please note that after scanning the QR code in the Helium Wallet app, you will need to enter the -password provided via the Helium CLI Wallet used to encrypt the QR code export. This password may be -different than the one used to execute CLI wallet commands. - -2. Import private key into Solana CLI Wallet - -If you exported your private key in a Solana-compatible form for usage with the Solana CLI Wallet, -you are all set as the produced `json` file (which we called `solana_wallet.json`) is a bonafide -private key for usage in executing Solana CLI Wallet commands. - -3. Import private key into Phantom Wallet - -If you exported your private key for import into Phantom Wallet, you will open your Phantom browser -extension, go to the settings menu, select your account, select "Add/Connect Wallet", select "Import -Private Key", and copy/pasting the full output from the Helium CLI Wallet command. - ---- - -## For Ledger Wallet Users - -:::tip Migrate Here in Docs! - -The [Ledger Hardware Wallet User](/solana/migration/ledger) page has an integrated tool to migrate -all tokens from the Helium derivation path to the Solana derivation path. - -::: - -Ledger users will need to update their Helium Ledger App to a version that's pending release. This -upcoming version will use the Solana private key derivation path that moves all your tokens and -balances over to Solana. - -Your public key will change on Solana, but the private key will remain the same. - -The [Ledger Migration](/solana/migration/ledger) document includes the utilities needed to update -your Helium Ledger account. - -### Derivation Paths and your new Public Key - -The Helium Ledger App uses `ED25519` keys, similarly to Solana, but at a different derivation path. - -This means that, while seed phrases are the same, private keys are different on Solana. - -In order to get around this, when you run the migration, the migration application will ask you to -use the old derivation path to approve sending all of your Hotspots, tokens, etc. to the new -derivation path. diff --git a/docs/solana/primer.mdx b/docs/solana/primer.mdx deleted file mode 100644 index 55494e22f..000000000 --- a/docs/solana/primer.mdx +++ /dev/null @@ -1,232 +0,0 @@ ---- -id: primer -title: Primer on Solana Programming -pagination_label: Primer on Solana Programming -sidebar_label: Primer on Solana Programming -description: Helium Primer on Solana Programming Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/primer ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This guide exists to give an overview of Helium data on Solana, and some general Solana programming -semantics. For a more in-depth guide, check out -[The Solana Cookbook](https://solanacookbook.com/core-concepts/accounts.html) - -## Reading Data - -At its core, Solana is just a giant Key/Value store. A public key is the key, and there's some blob -of data at that value. That blob of data is called an Account. You can imagine Public Keys like a -primary key in a traditional database. - -For example, let's consider this public key: `6r4x69WHPPDzUuMpJ7vwSUiU6e73KJqeoPyZ8nHQTmFP` - -If we check the -[Solana Explorer, under Anchor Data](https://explorer.solana.com/address/6r4x69WHPPDzUuMpJ7vwSUiU6e73KJqeoPyZ8nHQTmFP/anchor-account?cluster=devnet) -for this account, we can see that this is a `DaoV0` on the devnet `helium-sub-daos` contract. - -![Dao in Explorer](/img/solana/dao-in-explorer.png) - -Scrolling up we can see that it is, in fact, owned by the Helium subDAO's program: - -![Program Owner](/img/solana/program-owner.png) - -This means that only the `helium-sub-daos` program can make changes to this account. On other -chains, a Program may be called a Smart Contract. Accounts are either owned by a program or owned by -the system program. An account owned by the System Program is generally either a Wallet (holding -SOL), or an account that has yet to be initialized. - -On Solana, a Wallet is just an account with some amount of SOL tokens in it, owned by the system -program. The owner of that Wallet controls the private key to that account, and so can sign -transactions as that public key. - -### PDAs - -Program Derived Addresses (PDAs) are home to accounts that are designed to be controlled by a -specific program. With PDAs, programs can programmatically sign for certain addresses without -needing a private key. PDAs serve as the foundation for Cross-Program Invocation, which allows -Solana apps to be composable with one another. - -A PDA is a Public Key that is derived from some set of seeds and a given program ID. Think of it as -a one-way hashing to a new address. So, for example, - - -```js -getProgramAddress([Buffer.from("helium", "utf8")], helium_sub_daos.programId) -``` - -will always return the same address. Better yet, the `helium_sub_daos` is able to sign transactions -as if it held the private key to this PDA. - -As you will see, the Helium programming model depends heavily on PDAs as indexes into the -blockchain. - -If you imagine the world of Helium Data on Solana as a Graph, PDAs let us hook into particular -subgraphs. - -A great example of this is the relationship between the Helium `dao` and the `hnt` mint address. The -`DaoV0` definition from earlier exists at address: - - -```js -import { daoKey } from "@helium/helium-sub-daos-sdk" - -const daoAddr = daoKey(new PublicKey("...hnt mint..."))[0]; -``` - -:::note Helium PDAs and Mints - -You'll notice that if you trace the graph of Helium PDAs, they always lead back to the address of -either the HNT token mint, or the subDAO token mint. - -This design is intentional. Rather than making DAOs, subDAOs, etc global, we opted to make them -dependent on the specific mints being used. This allows us to set up testing scenarios in which we -use a testing token alongside the real tokens. This design also allows for easier reuse of our -contracts throughout the Solana community. - -::: - -### Aside - Tokens - -To understand the Helium model on Solana, it's important to understand how tokens work on Solana. - -You might imagine a Wallet is some kind of account (data struct) holding all of your tokens. This is -not the case! - -Instead, a Wallet is really a collection of `TokenAccount`s (Accounts whose data is a -`TokenAccount`). The token account itself has a reference to its owner, which is the Wallet. Note -that `TokenAccount.owner` is different than the `Account.owner`. In this case, the Program that is -allowed to make changes to a token account is the Token Program. That is the `Account.owner`. -Whereas the owning wallet of the `TokenAccount` is the `TokenAccount.owner`. You can see a token -account for a testing token we created -[here](https://explorer.solana.com/address/BM9kx8NZGNThVr6HnBJo1CR5Jvk5Zc3EEy7wWztaJHS2?cluster=devnet) - -Every token, whether it be USDC, HNT, or MOBILE has a definition. This is called the token `Mint`. -You can also see this key on the token account above. This includes definitions like current supply, -mint authority, freeze authority, and decimals. - -A common confusion on Solana is understanding Accounts vs Token Accounts, owners vs Token Account -owners. - -#### Associated Token Accounts - -Associated token accounts are often the first use of PDAs you will see as a developer on Solana. - -Given the above model, it is possible for a given wallet to have multiple token accounts for the -same token. That is both messy and hard to index. Early in the days of Solana, a program called -`associated-token` emerged. `Associated-token` says that the account for a given Wallet and mint can -be derived by: - - -```js - PublicKey.findProgramAddress( - [wallet.toBuffer(), TOKEN_PROGRAM_ID.toBuffer(), mint.toBuffer()], - ASSOCIATED_TOKEN_PROGRAM_ID - ) -``` - -Generally, token accounts are created through the `associated-token` program so that they can be -guaranteed to be accessed at an easy-to-find address. - -### Fetching Data - -The classic way of fetching data on Solana is to use @solana/web3.js connection object. - - -```js -import { PublicKey, Connection } from "@solana/web3.js" - -const connection = new Connection("...rpc url...") -const account = await connection.getAccountInfo(new PublicKey("...")) - -console.log(account.data) -``` - -This will get you the binary data of any account stored on chain; however, you will need to decode -the data yourself. Most programs come with their own SDKs for reading and deserializing data. For -example, SPL Token (the token program), comes with @solana/spl-token - - -```js -import { PublicKey } from "@solana/web3.js" -import { getAccount, getAssociatedTokenAddressSync } from "@solana/spl-token" - -const mint = new PublicKey("...wallet...") -const wallet = new PublicKey("...wallet...") -const tokenAddress = getAssociatedTokenAddressSync(mint, wallet) -const tokenAccount = await getAccount(connection, tokenAddress) - -console.log(tokenAcount.amount, tokenAccount.owner) -``` - -In the case of Helium programs, they all use a framework called -[Anchor](https://github.com/coral-xyz/anchor), which amongst other things generate SDKs for us. - -You can use the SDKs as follows: - - -```js -import { init } from "@helium/helium-sub-daos-sdk"; -import * as anchor from "@coral-xyz/anchor"; - -anchor.setProvider(anchor.AnchorProvider.local("...rpc url...")); -const provider = anchor.getProvider() as anchor.AnchorProvider; -const program = await init(provider) - -const daoAccount = await program.account.daoV0.fetch(new PublicKey("...dao key...")) -``` - -## Sending Transactions - -Transactions are how we modify data on Solana. All Helium SDKs use the standard -[Anchor](https://github.com/coral-xyz/anchor) SDK. - -That means the interface to all instructions are predictable. You should be able to look at either -our IDLs, or the programs themselves, and see what accounts need to be passed to generate -instructions. - -The best way to understand how to take certain actions against Helium on Solana is to look at -[our tests](https://github.com/helium/helium-program-library/tree/master/tests). - -For example, to submit a Data Credit delegation, the code may look something like this: - - -```js -import { subDaoKey } from "@helium/helium-sub-daos-sdk"; -import { init as initDc } from "@helium/data-credits-sdk"; -import * as anchor from "@coral-xyz/anchor"; - -anchor.setProvider(anchor.AnchorProvider.local("...rpc url...")); -const provider = anchor.getProvider() as anchor.AnchorProvider; - -const iotMint = new PublicKey("...iot mint..."); -const iotSubDao = subDaoKey(iotMint)[0] - -const dcProgram = await initDc(provider) - -await program.methods - .delegateDataCreditsV0({ - amount: toBN(10, 0), - routerKey: "router key", - }) - .accounts({ - subDao: iotSubDao, - }) - .rpc(); -``` - -## RPC & RPC Nodes - -An RPC is an application's gateway to the Solana cluster. RPC Nodes do not participate in consensus -and instead are dedicated to data requests. - -All the RPCs used in the Solana Migration follow the Solana chain and will index the NFT data that -Core Developers created in Compression NFTs. This is one reason the Helium Network can mint a -million or more NFTs on Solana. - -You may need to run an RPC service to access public Solana clusters. Many services are free, and -others are paid. The Foundation uses Helius as their RPC Provider, and it’s useful to use a PRC -provider that is familiar with compression. They will all support this at some point. - -You can read more about RPC & RPC Nodes [here](https://solana.com/rpc). diff --git a/docs/solana/rewardable-entities.mdx b/docs/solana/rewardable-entities.mdx deleted file mode 100644 index 7c327524e..000000000 --- a/docs/solana/rewardable-entities.mdx +++ /dev/null @@ -1,440 +0,0 @@ ---- -id: rewardable-entities -title: Rewardable Entities -pagination_label: Rewardable Entities -sidebar_label: Hotspots on Solana -description: Helium Rewardable Entities Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/rewardable-entites ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Following the transition to Solana, all actors in the network that receive tokens are considered -"Rewardable Entities." - -While, as of writing this document, hotspots are the only rewardable entity, this will change with -the addition of mappers and other rewardable categories. - -A rewardable entity on the Helium Network is represented on Solana as an NFT (Non-Fungible Token). - -NFTs are ideal for this job as the represent ownership in a way that is easily transferrable and -recognized by all major wallets. Open your wallet and see all of your hotspots inside. - -## Compression NFTs - -A new development on the Solana Blockchain has been -[Compression NFTs](https://www.metaplex.com/posts/expanding-digital-assets-with-compression-for-nfts). - -With normal NFTs on Solana, each token is stored on chain as a distinct spl-token mint, with -decimals of 0 and supply of 1. This mint has some metadata attached to it, as well as a token -account representing the ownership of the token. In total this leads to 4 accounts with a cost of -0.01197616 SOL in rent. Multiplying this by millions of hotspots leads to not only a high cost, but -also a large usage of storage space on the blockchain. - -Enter: Compression NFTs. Compression NFTs use a Concurrent Merkle Tree to compress millions of NFTs -into one 32-byte hash. Clients executing transactions on compressed NFTs are able to send a -cryptographic proof to the blockchain that verifies the NFT and ownership. In other words, instead -of sending a transaction with: - -```rust - -... -pub mint: Account<'info, Mint>, -pub metadata: Account<'info, Metadata>, -pub master_edition: Account<'info, MasterEdition>, -#[account( - constraint = token_account.amount >= 1, - token::owner = owner -)] -pub token_account: Account<'info, TokenAccount>, -pub owner: Signer<'info> -... -``` - -You can instead send: - -```rust - -pub struct ProofArgs { - pub hash: Vec, // The 32 byte hash of the NFT - pub root: [u8; 32], // The root of the merkle tree - pub index: u32, // The index of the item in the tree - pub proof: Vec> // An array of 32 byte proofs proving that the `hash` is part of the `root` -} - -... -pub merkle_tree: UncheckedAccount<'info>, -... - -``` - -While this can make the transaction size larger, the amount of data stored on chain is tiny. While -this may look difficult, this is all neatly packed in the Metaplex Digital Asset API. This API runs -on multiple RPC providers and allows you to hit convenient functions like `get_assets_by_owner` and -`get_asset_proof` so that you never have to worry about the underlying concurrent merkle algorithm. - -## Fetching Rewardable Entities. - -All rewardable entities are created by the `helium-entity-manager` program. Further, they exist -under a collection that is managed by the Maker of that entity. The easiest way to fetch all Helium -entities for a given wallet is to filter by the `helium-entity-manager-creator` - -We can get this address by running - - -```js -import { daoKey } from "@helium/helium-sub-daos-sdk"; -import { entityCreatorKey } from "@helium/helium-entity-manager-sdk"; - -const hntMint = new PublicKey('...hnt mint...') -const dao = daoKey(hntMint)[[0]] -const creator = entityCreatorKey(dao)[0] -``` - -This should output: `Fv5hf1Fg58htfC7YEXKNEfkpuogUUQDDTLgjGWxxv48H` - -Now, we can use the Metaplex Digital Asset API to get rewardable entities my wallet -(`BcJzP2hEYgzjUwpHEtS6RhuqGfEJVx8Rq3MejujAAWrR`) owns: - -```bash -curl --request POST \ - --url https://rpc-devnet.aws.metaplex.com/ \ - --header 'Content-Type: application/json' \ - --data '{ - "jsonrpc": "2.0", - "method": "search_assets", - "id": "get-assets-op-1", - "params": { - "ownerAddress": "BcJzP2hEYgzjUwpHEtS6RhuqGfEJVx8Rq3MejujAAWrR", - "page": 0, - "creatorAddress": "Fv5hf1Fg58htfC7YEXKNEfkpuogUUQDDTLgjGWxxv48H", - "creatorVerified": true, - "sortBy": {"sortBy": "created", "sortDirection": "asc"} - } - }' -``` - -### Hotspots and ECC Compact Keys - -Hotspots on the Helium Network currently are uniquely identified by their ECC Compact Public Keys - -At onboarding time, hotspots are able to sign an onboard transaction proving physical ownership of -the device. - -As such, the Helium Solana implementation enforces that all NFTs are unique by ECC Compact keys. - -If you have an asset id of an NFT on Solana, you can get the ECC Compact Key by fetching the digital -asset and pulling out the last value from the content.json_uri. - -For example: - - -```js -import { getAsset } from "@helium/spl-utils"; - -const asset = await getAsset(rpcUrl, new PublicKey("...asset id...")); - -const eccCompactKey = asset.content.json_uri.split("/").slice(-1)[0]; -``` - -If you have only an ECC Compact key and would like to find the NFT, you can use the `KeyToAssetV0` -struct that is stored on chain: - - -```js -import { daoKey } from "@helium/helium-sub-daos-sdk" -import { keyToAssetKey, init } from "@helium/helium-entity-manager-sdk" - -// Declare constants -const hntMint = new PublicKey("...hnt mint...") -const dao = daoKey(hntMint)[0] -const eccKey = "...ecc compact key..." - -// Init program -const program = await init(provider); - -// Get the asset id from the KeyToAssetV0 account on chain -const keyToAssetPkey = keyToAssetKey(dao, eccKey)[0] -const keyToAssetAcc = await program.account.keyToAssetV0.fetch(keyToAssetPkey); -const assetId = keyToAssetAcc.asset; - -// Now get the asset from the metaplex asset api -const asset = await getAsset(rpcUrl, assetId) -``` - -## Transferring Rewardable Entities - - - -## Onboarding Rewardable Entities - -The onboarding flow for an entity is general that a customer purchases the hardware from a Maker, -and then self-onboards to the network. Because all hardware is created by approved Makers, the -onboard transaction must be approved by the Maker. This uses a similar flow to the legacy -onboarding-server of the Helium blockchain. - -The main difference between the Solana version of Helium, and the legacy version on the Helium -chain, is that onboarding is on a per-network basis. A Hotspot can be an IOT hotspot, a MOBILE -hotspot, or both. If the Hotspot wants to earn both MOBILE and IOT rewards, it must onboard to the -IOT network AND the MOBILE network. It must also assert location on both subnetworks. - -Similarly, makers are approved for specific subnetworks. A maker that creates IOT hotspots cannot -necessarily onboard MOBILE hotspots. Each network subDAO must approve makers to issue rewardable -entities. - -The following test shows the full flow of onboarding a Hotspot using the onboarding server. - -The [React Native Helium](https://github.com/helium/react-native-helium) SDK should greatly simplify -this process. - - - - -```js -import Address from "@helium/address"; -import { Keypair } from "@helium/crypto"; -import { sendAndConfirmWithRetry } from "@helium/spl-utils"; -import { AddGatewayV1 } from "@helium/transactions"; -import { accountProviders } from "@metaplex-foundation/mpl-bubblegum"; -import { - Connection, - PublicKey, - Transaction, - Keypair as SolanaKeypair, -} from "@solana/web3.js"; -import axios from "axios"; -import { BN } from "bn.js"; - -function random(len: number): string { - return new Array(len).join().replace(/(.|$)/g, function () { - return ((Math.random() * 36) | 0).toString(36); - }); -} - -function sleep(ms: number) { - return new Promise((resolve) => setTimeout(resolve, ms)); -} - -describe("onboarding server", () => { - let me: Keypair; - let gateway: Keypair; - const maker = Address.fromB58( - "ENTER YOUR MAKER ADDRESS" - ); - let onboardingKey: string; - - let base = "https://onboarding.web.test-helium.com"; - before(async () => { - me = await Keypair.makeRandom(); - gateway = await Keypair.makeRandom(); - onboardingKey = gateway.address.b58; - const result = await axios.post( - `${base}/api/v2/hotspots`, - { - onboardingKey, - macWlan0: random(10), - macEth0: random(10), - rpiSerial: random(10), - heliumSerial: random(10), - batch: "example-batch", - }, - { - headers: { - authorization: "ENTER YOUR MAKER AUTH KEYS" - }, - } - ); - - await sleep(2000); - }); - - it("should run issue txs", async () => { - const hotspot = ( - await axios.get(`${base}/api/v2/hotspots/${onboardingKey}`) - ).data.data; - console.log(hotspot); - console.log(me.privateKey); - const solanaKeypair = SolanaKeypair.fromSecretKey(me.privateKey); - console.log("Solana pubkey: ", solanaKeypair.publicKey.toBase58()) - - await sleep(2000); - - const result = await axios.post( - `${base}/api/v3/transactions/create-hotspot`, - { - location: new BN(1).toString(), - transaction: ( - await new AddGatewayV1({ - owner: me.address, - gateway: gateway.address, - payer: maker, - }).sign({ - gateway, - }) - ).toString(), - } - ); - - const connection = new Connection("https://api.devnet.solana.com"); - const { solanaTransactions } = result.data.data; - for (const solanaTransaction of solanaTransactions) { - const txid = await sendAndConfirmWithRetry( - connection, - Buffer.from(solanaTransaction), - { skipPreflight: true }, - "confirmed" - ); - console.log(txid.txid); - } - - let tries = 0; - let onboardResult: any; - while (tries < 10 && !onboardResult) { - try { - onboardResult = await axios.post( - `${base}/api/v3/transactions/mobile/onboard`, - { - entityKey: onboardingKey, - } - ); - } catch { - console.log(`Hotspot may not exist yet ${tries}`); - tries++; - await sleep(2000); // Wait for hotspot to be indexed into asset api - } - } - - - for (const solanaTransaction of onboardResult!.data.data - .solanaTransactions) { - const tx = Transaction.from(Buffer.from(solanaTransaction)); - tx.partialSign(solanaKeypair) - const txid = await sendAndConfirmWithRetry( - connection, - tx.serialize(), - { skipPreflight: true }, - "confirmed" - ); - console.log(txid.txid); - } - - const updateResult = await axios.post( - `${base}/api/v3/transactions/mobile/update-metadata`, - { - entityKey: onboardingKey, - location: new BN(1).toString(), - elevation: 2, - gain: 11, - wallet: solanaKeypair.publicKey.toBase58() - } - ); - - for (const solanaTransaction of updateResult.data.data.solanaTransactions) { - const tx = Transaction.from(Buffer.from(solanaTransaction)); - tx.partialSign(solanaKeypair) - const txid = await sendAndConfirmWithRetry( - connection, - tx.serialize(), - { skipPreflight: true }, - "confirmed" - ); - console.log(txid.txid); - } - }); -}); - - -``` - -## Claiming Rewards on Rewardable Entities - -A system of oracles keeps track of the rewards owed to each Rewardable Entity. For example, in the -IOT network there are oracles that keep track of the IOT tokens earned by each Hotspot for PoC. - -These oracles are responsible ONLY for tracking the total lifetime rewards associated with a -hotspot. This frees the oracles from any kind of dependence on the blockchain. They don't care about -the issuance or movement of tokens. - -The `lazy-distributor` program keeps track of, for each hotspot, how much of the total lifetime -rewards have been claimed. Claiming rewards, then, consists of two steps: - -1. Ask oracles to update the on-chain state to reflect the latest lifetime rewards for this hotspot. -2. Issue the difference between the total lifetime rewards and total claimed rewards to the hotspot - owner. - -In practice, we have made it so that this can all happen in a singular transaction for PoC rewards. -Staking rewards will happen in transactions combining up to 4 days of rewards. - -### Finding current rewards - -Oracles work off of a restful API that involves - -1. Grabbing lifetime rewards for all oracles. -2. Constructing a transaction to set the rewards and passing the transaction to each oracle to - partially sign. -3. Submitting the fully signed transaction to Solana. - -The SDK simplifies this process into two functions, `getCurrentRewards` and `formTransaction`. - -If you have interest in using the REST api, you can see the relatively simple client code -[here](https://github.com/helium/helium-program-library/blob/master/packages/distributor-oracle/src/client.ts) - -To fetch rewards across all oracles for a given asset id: - - -```js -import { init, lazyDistributorKey } from "@helium/lazy-distributor-sdk"; -import { getCurrentRewards } from "@helium/distributor-oracle"; -import * as anchor from "@coral-xyz/anchor"; - -anchor.setProvider(anchor.AnchorProvider.local("...rpc url...")); -const provider = anchor.getProvider() as anchor.AnchorProvider; -const program = await init(provider) - -const iotMint = new PublicKey("...iot mint...") -const assetId = new PublicKey("...asset id...") -const lazyDistributorPkey = lazyDistributorKey(iotMint)[0]; -const rewards = await getCurrentRewards(program, lazyDistributorPkey, assetId); - -rewards.map(reward => { - console.log(`Oracle ${reward.oracleKey} stating lifetime rewards of ${reward.currentRewards}`); -}) -``` - -### Claiming rewards - -:::info - -The claim example in this section requires a connection to an RPC node (provider) that understands -compressed NFTs. This is an advanced feature that is not yet supported by Solana's public RPC -servers. **This example will not work unless you use an appropriate RPC provider such as -[Helius](https://www.helius.xyz/).** - -::: - -You can then get a transaction to submit to the Solana blockchain using those rewards: - - -```js - -import { formTransaction } from "@helium/distributor-oracle"; -import { sendAndConfirmWithRetry } from "@helium/spl-utils"; - -const tx = await formTransaction({ - program, - provider, - rewards, // from above - hotspot: assetId, - lazyDistributor: lazyDistributorPkey, -}) - -const signed = await provider.wallet.signTransaction(tx); - -await sendAndConfirmWithRetry( - provider.connection, - Buffer.from(signed.serialize()), - { skipPreflight: true }, - 'confirmed', -); -``` diff --git a/docs/style-guide.md b/docs/style-guide.md deleted file mode 100644 index 8d4b79596..000000000 --- a/docs/style-guide.md +++ /dev/null @@ -1,211 +0,0 @@ ---- -id: style-guide -title: Style Guide -sidebar_label: Style Guide ---- - -You can write content using [GitHub-flavored Markdown syntax](https://github.github.com/gfm/). - -## Markdown Syntax - -To serve as an example page when styling markdown based Docusaurus sites. - -## Headers - -# H1 - Create the best documentation - -## H2 - Create the best documentation - -### H3 - Create the best documentation - -#### H4 - Create the best documentation - -##### H5 - Create the best documentation - -###### H6 - Create the best documentation - ---- - -## Emphasis - -Emphasis, aka italics, with _asterisks_ or _underscores_. - -Strong emphasis, aka bold, with **asterisks** or **underscores**. - -Combined emphasis with **asterisks and _underscores_**. - -Strikethrough uses two tildes. ~~Scratch this.~~ - ---- - -## Lists - -1. First ordered list item -1. Another item - - Unordered sub-list. -1. Actual numbers don't matter, just that it's a number - 1. Ordered sub-list -1. And another item. - -- Unordered list can use asterisks - -* Or minuses - -- Or pluses - ---- - -## Links - -[I'm an inline-style link](https://www.google.com/) - -[I'm an inline-style link with title](https://www.google.com/ "Google's Homepage") - -[I'm a reference-style link][arbitrary case-insensitive reference text] - -[You can use numbers for reference-style link definitions][1] - -Or leave it empty and use the [link text itself]. - -URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com/ or - and sometimes example.com (but not on GitHub, for example). - -Some text to show that the reference links can follow later. - -[arbitrary case-insensitive reference text]: https://www.mozilla.org/ -[1]: http://slashdot.org/ -[link text itself]: http://www.reddit.com/ - ---- - -## Images - -Here's our logo (hover to see the title text): - -Inline-style: -![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png 'Logo Title Text 1') - -Reference-style: ![alt text][logo] - -[logo]: - https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png - 'Logo Title Text 2' - -Images from any folder can be used by providing path to file. Path should be relative to markdown -file. - -![img](../static/img/icons/logo.svg) - ---- - -## Code - -```javascript -var s = 'JavaScript syntax highlighting' -alert(s) -``` - -```python -s = "Python syntax highlighting" -print(s) -``` - -``` -No language indicated, so no syntax highlighting. -But let's throw in a tag. -``` - -```js {2} -function highlightMe() { - console.log('This line can be highlighted!') -} -``` - ---- - -## Tables - -Colons can be used to align columns. - -| Tables | Are | Cool | -| ------------- | :-----------: | -----: | -| col 3 is | right-aligned | \$1600 | -| col 2 is | centered | \$12 | -| zebra stripes | are neat | \$1 | - -There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and -you don't need to make the raw Markdown line up prettily. You can also use inline Markdown. - -| Markdown | Less | Pretty | -| -------- | --------- | ---------- | -| _Still_ | `renders` | **nicely** | -| 1 | 2 | 3 | - ---- - -## Blockquotes - -> Blockquotes are very handy in email to emulate reply text. This line is part of the same quote. - -Quote break. - -> This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep -> writing to make sure this is long enough to actually wrap for everyone. Oh, you can _put_ > -> **Markdown** into a blockquote. - ---- - -## Inline HTML - -
-
Definition list
-
Is something people use sometimes.
- -
Markdown in HTML
-
Does *not* work **very** well. Use HTML tags.
-
- ---- - -## Line Breaks - -Here's a line for us to start with. - -This line is separated from the one above by two newlines, so it will be a _separate paragraph_. - -This line is also a separate paragraph, but... This line is only separated by a single newline, so -it's a separate line in the _same paragraph_. - ---- - -## Admonitions - -:::note - -This is a note - -::: - -:::tip - -This is a tip - -::: - -:::important - -This is important - -::: - -:::caution - -This is a caution - -::: - -:::warning - -This is a warning - -::: diff --git a/docs/tokens/DataCredit.jsx b/docs/tokens/DataCredit.jsx new file mode 100644 index 000000000..c22e2b90c --- /dev/null +++ b/docs/tokens/DataCredit.jsx @@ -0,0 +1,24 @@ +export const PayloadSize = () => ( +
+

Message Payload Size

+ + + + + + + + + + + + + + + +
0-24 bytes25-48 bytes... 241 bytes
1 DC2 DC... 11 DC
+
+ Data transfer is accounted for in 24-byte increments per message on the LoRaWAN network. +
+
+) diff --git a/docs/tokens/NetEmissions.jsx b/docs/tokens/NetEmissions.jsx new file mode 100644 index 000000000..137157501 --- /dev/null +++ b/docs/tokens/NetEmissions.jsx @@ -0,0 +1,132 @@ +import React, { useState } from 'react' +import BrowserOnly from '@docusaurus/BrowserOnly' +import styles from './NetEmissions.module.css' + +export const NetEmissions = () => ( + + {() => { + const EMISSIONS_CAP = 1643.83561643 + const formatter = new Intl.NumberFormat(navigator.language, { + minimumFractionDigits: 0, + maximumFractionDigits: 8, + }) + + const [yesterday, setYesterday] = useState(400) + const [today, setToday] = useState(9500) + + const uncappedTarget = (yesterday * 6) / 7 + (today * 1) / 7 + const isCapped = uncappedTarget > EMISSIONS_CAP + const netEmissions = Math.min(uncappedTarget, EMISSIONS_CAP) + const burned = Math.max(today - netEmissions, 0) + + const setPreset = (y, t) => { + setYesterday(y) + setToday(t) + } + + return ( +
+
+ + + +
+ +
+
+ setYesterday(Number(e.target.value))} + /> +
+

+ Yesterday's Net Emissions Target: {formatter.format(yesterday)} HNT +

+ +
+ setToday(Number(e.target.value))} + /> +
+

+ Today's HNT Burned: {formatter.format(today)} HNT +

+
+ +
+

+ If yesterday's Net Emissions Target was {yesterday.toLocaleString()}{' '} + HNT and today's HNT Burned is {formatter.format(today)} HNT, then + today's Net Emissions Target is calculated as follows: +

+

+ ({formatter.format(yesterday)} × 6/7) + ( + {formatter.format(today)} × 1/7) ={' '} + {formatter.format(uncappedTarget)} HNT{''} + {isCapped && ( + <> +
+ However, this will be capped at + {formatter.format(EMISSIONS_CAP)} + {' '} + HNT as today's Net Emissions. + + )} + {!isCapped && <> which is below the emissions cap.} +

+ +

+ The difference between the burn and emission represents the change in HNT supply. +
+ Today's HNT Burned value {today} HNT minus today's Net Emissions{' '} + {formatter.format(netEmissions)} HNT equals{' '} + {formatter.format(burned)} HNT permanently burned. +

+ +

+ Tomorrow, the uncapped number{' '} + + Net Emissions TargetToday + {' '} + ({formatter.format(uncappedTarget)}) will become{' '} + + Net Emissions TargetYesterday + + . +

+
+
+ ) + }} + +) diff --git a/docs/tokens/NetEmissions.module.css b/docs/tokens/NetEmissions.module.css new file mode 100644 index 000000000..d8f7f9d54 --- /dev/null +++ b/docs/tokens/NetEmissions.module.css @@ -0,0 +1,67 @@ +.container { + padding: 16px 16px 0; + width: 100%; +} + +.box { + background: white; + border-radius: 8px; + padding: 16px; + margin-bottom: 1em; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); +} + +[data-theme='dark'] .box { + background: rgba(255, 255, 255, 0.05); +} + +.inputRow { + display: flex; + margin: 0.5em 0; +} + +input[type='range'] { + flex: 1; +} + +.buttons { + display: flex; + justify-content: space-evenly; + gap: 1em; + margin-bottom: 1em; +} + +.button { + display: flex; + align-items: center; + appearance: none; + background: white; + border: none; + cursor: pointer; + color: #5a719a; + font-size: 1rem; + font-weight: 500; + padding: 1em; + gap: 1em; + text-decoration: none; + border-radius: 8px; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); +} + +.example { + font-weight: normal; + text-align: left; +} + +[data-theme='dark'] .button { + color: #fff; + background: #53627c; +} + +.button:hover { + color: rgb(18, 49, 103); +} + +[data-theme='dark'] .button:hover { + color: #fff; +} diff --git a/docs/tokens/SolToken.jsx b/docs/tokens/SolToken.jsx new file mode 100644 index 000000000..2fb61637b --- /dev/null +++ b/docs/tokens/SolToken.jsx @@ -0,0 +1,18 @@ +export const HntToSol = () => ( +
+ +
+ Video of the process in action.{' '} + Click here to watch on YouTube. +
+
+) diff --git a/docs/tokens/data-credit-portal.mdx b/docs/tokens/data-credit-portal.mdx new file mode 100644 index 000000000..1f48397d8 --- /dev/null +++ b/docs/tokens/data-credit-portal.mdx @@ -0,0 +1,146 @@ +--- +id: data-credit-portal +title: Helium Data Credit Portal +pagination_label: Data Credit Portal +sidebar_label: Buy Data Credits with Credit Card +description: Helium Data Credit Portal Documentation +image: https://docs.helium.com/img/link-image.png +slug: /tokens/data-credit-portal +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + + +
+
+ +The Data Credit Portal built by [Sphere][sphere] allows Network users to acquire Data Credits +without directly holding cryptocurrency. The tool is designed to allocate Data Credits for Network +users like [LNS operators][open-lns] or mobile service providers. The tool provides a clear invoice +to simplify accounting. + +Access the Data Credit Portal at [dc-portal.helium.com][dc-portal]. + +
+ +
Helium Data Credit Portal powered by Sphere.
+
+
+ +:::note There may be select countries where access to this tool is unavailable. + +If access appears to be restricted in your region, please email +[hello@helium.foundation][mailto-foundation] for assistance. + +::: + +## Using the Data Credit Portal + +For the sake of this example, we will send 1,000,000 DC ($10.00 USD) to OUI 1 with the memo "test". + +As you type in the OUI number, you will notice a pop-up. OUI owners can see how many DC are +available under their OUI. For instance, there are just over 180 million DC available under OUI 1 +for the LoRaWAN network. An email address can also be specified in order to receive the purchase +receipt. + +
+ +
A preview is offered for each destination address.
+
+
+ +Upon clicking “Continue”, you will be taken to Sphere's crypto payment interface. Hit "Pay" when you +have filled in your payment information. + +
+ +
+
+ +### Confirm Purchase + +While Sphere is performing the underlying transactions for you, you will see this loading screen. Do +not refresh or exit the page. + +
+ +
+
+ +You will be notified when the transaction is complete. The transaction can be verified by clicking +on the Explorer link. + +
+ +
+
+ +### Invoice + +With the completion of a successful transaction, an invoice is promptly emailed to the account that +was used for the transaction. + +
+ +
A receipt will be emailed to the account responsible for the transaction.
+
+
+ +Click on the link to explore the transaction details. Scroll down to the transaction titled +"Delegate Data Credits V 0". As you can see, 970,000 DC was delegated to the OUI's escrow account +because there is a 3% transaction fee when you purchase DC through Sphere's Data Credit portal. + +
+ +
The transaction detail that delegates DC towards your OUI escrow account.
+
+ +## Deep Links + +The Data Credit portal provides a simple interface to pre-populate fields within the tool. Use URL +parameters to pre-fill fields on the Data Credit Portal such as OUI and memo. + +``` +https://dc-portal.helium.com/?oui=24&memo=HelloHelium +``` + +**Supported Parameters** + +| Description | Field | Example | +| ----------------- | ------ | ------------- | +| OUI | `oui` | `oui=24` | +| Transaction memo. | `memo` | `memo=aX0fe8` | + +[sphere]: https://spherepay.co +[open-lns]: /iot/lorawan-network-servers +[dc-portal]: https://dc-portal.helium.com +[payment-method]: #payment-method +[mailto-foundation]: mailto:hello@helium.foundation diff --git a/docs/tokens/data-credit.mdx b/docs/tokens/data-credit.mdx new file mode 100644 index 000000000..ca60c8fa5 --- /dev/null +++ b/docs/tokens/data-credit.mdx @@ -0,0 +1,155 @@ +--- +id: data-credit +title: Data Credit +pagination_label: Data Credit +sidebar_label: Data Credit (DC) +description: Helium Data Credit Documentation +image: https://docs.helium.com/img/link-image.png +slug: /tokens/data-credit +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' +import BrowserOnly from '@docusaurus/BrowserOnly' +import { PayloadSize } from './DataCredit' +import { TopLedgerEmbed } from '@site/src/theme/TopLedgerEmbed' + + + +Data Credits (DCs) are the mechanism by which all Helium network usage is paid for. This token is +redeemable for data transfer on both the IoT and Mobile subnetworks. Furthermore, certain actions +such as onboarding a Hotspot are paid for using DC. + +For further reading on DCs place in the overall mechanics of the Helium network, refer to +[burn and mint economics](/tokens/hnt-token#burn-and-mint-economics) in the HNT token documentation. + +## Data Credit Fundamentals + +**One Data Credit equals $0.00001 USD.** + +The amount of DC produced by burning one HNT will fluctuate based on the USD price of HNT as +reported by the price provider, [Pyth](https://pyth.network). The tool below demonstrates the +HNT-to-DC conversion rate based on the price of HNT. + +import { HntToDcSimulator } from '@theme/HntToDcSimulator' + +
+ Loading Data Credit simulator...
}> + {() => } + + + +## Data Credit Usage + +DCs are used first and foremost as the payment of data transfer on the Helium IoT and Mobile +networks. Unlike traditional wireless networks, the Helium Network has no annual fee, and users only +pay for data used. In the original design of the protocol, it was recognized that users of the +network would not be comfortable with the volatility that comes with typical token economics. +Therefore, DCs were designed such that all data transfer is pinned to USD, making it predictable. + +DCs are also used for specific functions on the Helium subnetworks, such as onboarding or asserting +the locations of Hotspots. See the [IoT](#dc-and-iot) and [Mobile](#dc-and-mobile) usage sections +below for more details. DCs are not transferable once created. When being used for network transfer, +they can be delegated to be used for data transfer accounting. Once DCs have been delegated, they +cannot be redelegated. + + + +--- + +## Data Credits and Mobile {#dc-and-mobile} + +The Helium Mobile Network leverages DCs as the sole mechanism of billing and fee management. The +Mobile Network charges data at a rate of **$0.50 per 1 gigabyte** (50,000 DC). + +On cellular networks, it is customary that network operators bill for bulk data rather than for +individual packets. By setting the data cost to \$0.50 per gigabyte, the Helium Mobile network +positions itself competitively in the marketplace while preserving valuable rewards for the Mobile +Hotspot operator. + +### Mobile Protocol Fees + +Fees related to onboarding and location assert were defined through community governance through +[HIP-89](https://github.com/helium/HIP/blob/main/0089-mobile-network-onboard-fees.md). + +| Action | Fee | +| ------------------------------------------------------- | ----- | +| WiFi Indoor Onboard (Included with Hotspot) | $20 | +| WiFi Outdoor Onboard (Included with Hotspot) | $30 | +| [Converted Network Onboard](/mobile/helium-plus-mobile) | $2.00 | + +## Data Credits and IoT {#dc-and-iot} + +On the Helium IoT network, the primary utility of DCs is for network data transfer. Data transfer is +billed in 24-byte increments based on the application payload size only. LoRaWAN protocol overhead +(headers, MIC, etc.) does not count toward the DC cost. Data transfer is only billed if the message +is delivered through the Helium network. + +Network users also have the choice to purchase multiple reports of the same packet. These additional +reports each account for their own cost. For instance, if three 24-byte copies are returned for a +given message, the cost would be 3 DC. + + +
+ +### Data Transfer Calculator + +Use this calculator to estimate deployment costs based on the number of devices and how often they +send data. + +This calculator assumes a 24-byte message size which is typical of most deployments. + +import OperationCostEstimator from '@site/src/theme/DcCostEstimator' + +
+ +
+ +### IoT Protocol Fees + +In addition to network data transfer, DCs are also utilized for certain network-related fees. + +| Action | Fee | +| --------------------------------------------------------- | ---------------------------------------------- | +| Hotspot Onboarding | $10 | +| Assert Location | $1 | +| Hotspot Onboarding [(Data-Only)](/iot/data-only-hotspots) | $0.50 | +| Assert Location [(Data-Only)](/iot/data-only-hotspots) | $0.50 | +| OUI | $100 | +| DevAddr Slab | \$100 ($12.50 × 8)([^1]) | + +[^1]: + DevAddrs must be purchased in slabs of 8. + [HIP-116](https://github.com/helium/HIP/blob/main/0116-lorawan-device-address-price-adjustment.md) reduced + the fees for DevAddr purchasing and set a path to utilize the IOT token for DevAddr and OUI + purchases instead of DC. + +## Acquiring Data Credits + +At a network level, DCs are only generated through the conversion of HNT. However, several tools +exist to simplify the process for network users. + +:::important Data Credits are non-transferable + +Once the DC mint transaction is complete, the receiving Helium wallet owns all of the DC and cannot +transfer them to any other Helium wallet. + +DC can be delegated to network operator wallets in arrangement with the operator. This is a one-time +action. Learn more in the [Fund an Organizationally Unique Identifier](/iot/run-an-lns/fund-an-oui) +documentation. + +::: + +### HNT Swap + +For individuals or organizations with HNT holdings and familiarity with using cryptocurrencies in +business operations, converting HNT to DCs via the on-chain Helium programs provides a +straightforward method for acquiring DCs. + +HNT can be converted to DC using the [Helium Wallet App](/wallets/helium-wallet-app) or +[Helium CLI](/wallets/cli-wallet) wallet. diff --git a/docs/tokens/hnt-token.mdx b/docs/tokens/hnt-token.mdx new file mode 100644 index 000000000..3a645a2b2 --- /dev/null +++ b/docs/tokens/hnt-token.mdx @@ -0,0 +1,148 @@ +--- +id: hnt-token +title: The Helium Network Token +pagination_label: Helium Network Token +sidebar_label: Helium Network Token (HNT) +description: Helium Network Token Documentation +image: https://docs.helium.com/img/link-image.png +slug: /tokens/hnt-token +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' +import { TopLedgerEmbed } from '@site/src/theme/TopLedgerEmbed' + + + +The Helium Network Token (HNT) is the native cryptocurrency and protocol token of the Helium +Network. The first HNT was emitted on July 29th, 2019. There was no pre-mine of HNT before the +launch of the Network. + +The Helium network migrated from its own purpose-built blockchain to the Solana Blockchain on April +18, 2023. The mint address for HNT is [`hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux`][hnt-mint-addr] +on the Solana blockchain. + +## HNT Usage + +HNT serves the needs of the two primary parties in the Helium Ecosystem: + +1. **Hotspot Hosts and Operators**. Hosts are rewarded in HNT network tokens while deploying and + maintaining network coverage. Operators, and some network mappers are also rewarded in HNT. +2. **Enterprises and Developers use the Helium Network** to connect devices and build Network + applications. [Data Credits][datacredit], which are a \$USD-pegged utility token derived from + HNT, are used to pay transaction fees for wireless data transmissions on the Network. + +## HNT Token Economic Concepts + +The Network uses three token economic concepts to ensure HNT supply is both plentiful for usage +needs and relatively scarce, with a known maximum. + + + +### Max Supply + +The Network targeted the distribution of 5,000,000 HNT per month at launch. Following the community +approval of HIP-20, the Network uses a two-year halving schedule, resulting in an initial maximum +HNT supply of 240,000,000 HNT, but slow blockchain times in year 1 resulted in an issuance that was +~17,000,000 HNT less than the schedule targeted. Thus, at the time HIP 20 was approved, max supply +had decreased to ~223,000,000 HNT. + +| Year | Year Start | HNT at Year Start | Target HNT Emission | +| :--: | ---------------: | ----------------: | ------------------: | +| 1 | August 1st, 2019 | 0 | 60,000,000 | +| 2 | August 1st, 2020 | 60,000,000 | 60,000,000 | +| 3 | August 1st, 2021 | 120,000,000 | 30,000,000 | +| 4 | August 1st, 2022 | 150,000,000 | 30,000,000 | +| 5 | August 1st, 2023 | 180,000,000 | 15,000,000 | +| 6 | August 1st, 2024 | 195,000,000 | 15,000,000 | +| 7 | August 1st, 2025 | 210,000,000 | 7,500,000 | +| 8 | August 1st, 2026 | 217,500,000 | 7,500,000 | +| 7 | August 1st, 2027 | 225,000,000 | 3,750,000 | +| 8 | August 1st, 2028 | 228,750,000 | 3,750,000 | + +> The full token emission schedule can be viewed in the HNT section of this document: [Token +> Emissions as of Solana Migration][sol-emissions]. + +[^1]: + Year 1 starts on **August 1st, 2019**. The first halving happened on day one of year three, + **August 1st, 2021**. + +### Burn and Mint Economics {#burn-and-mint-economics} + +[Data Credits][datacredit] (DC) are a $USD-pegged utility token derived from HNT and is used to pay +fees on the Helium Network. DC is only produced by burning HNT. This HNT to DC relationship is based +on a design commonly called a [burn and mint equilibrium][bme] and intends to allow for the supply +of HNT to respond to network usage trends. + +### Net Emissions + +As the halving schedule progresses, it is possible that the HNT minted per epoch is not sufficiently +divisible for data transfer rewards. Therefore, in order to ensure that miners are incentivized to +continue transmitting data and ensure a healthy, robust network, the Net Emissions mechanism was +instituted in August 2021. + +Net Emissions give the protocol enough HNT for rewards in perpetuity by monitoring the number of HNT +burned in a given epoch and adding that to the number of HNT to mint that epoch. Because HNT +produced via Net Emissions do not add to the total outstanding, they do not violate max supply. +However, to ensure that the deflationary pressure is still present, the Net Emission is capped at 1% +of the epoch emissions at the time when HIP 20 was approved. + +Initially, Net Emissions counted only HNT burned for Data Credits but now accounts for all HNT +burned, but does not include HNT not emitted. + +Review the [complete Net Emissions discussion in the HIP][hip-20] for more information. Note that in +HIP-20, the cap was 34.24 HNT because the epoch was every 30 minutes at the time HIP-20 was written. +The current epoch is only 24 hour basis, yielding a cap of 1,643.83561643 HNT. The cap is not +affected by the 2 year emissions halvings. + +The up-to-date value can be verified +[on chain at.](https://explorer.solana.com/address/BQ3MCuTT5zVBhNfQ4SjMh3NPVhFy73MPV8rjfq5d1zie/anchor-account) +Move the decimal point 8 positions left to measure `Net Emissions Cap` in HNT. + +HIP-20 proposed a Net Emissions Pool, which would smooth out the effects of large individual burn +events occurring infrequently over several days. Without smoothing, large HNT burns for DC would be +extremely capped as the burn and cap would happen only on one day. This pool was implemented as part +of [HRP 2025-03][hrp-2025-03] using a similar smoothing calculation to that for the Utility Score +described in [HIP-141][hip-141]. With smoothing, this has an effect that large burns on one day can +increase Net Emissions over several days, rather than just one day. + +Every day, a Net Emissions Target is calculated, which takes into account the daily burn of HNT, and +the Net Emissions Target of the previous day and smooths it. The target amount of HNT is then +re-emitted as Net Emissions, up to the cap of 1,643.83561643 HNT. + +The smoothing calculation multiplies yesterday's uncapped and smoothed HNT burned amount number and +multiplies it by 6/7 and then adds it to today's actual HNT burned amount, multiplied by 1/7 and the +resulting number then has the Net Emissions Cap applied to provide the calculated Net Emission HNT +number for today. + +$$ +\text{Net Emissions Target}_{\text{Today}} = \text{Net Emissions Target}_{\text{Yesterday}} \cdot \frac{6}{7} + \text{HNT Burn}_{\text{Today}} \cdot \frac{1}{7} +$$ + +$$ +\text{HNT Net Emissions}_{\text{Today}} = \min\left( \text{Net Emissions Target}_{\text{Today}},\ 1643.83561643 \right) +$$ + +import { NetEmissions } from './NetEmissions' + +
+ +
+ +[bme]: https://multicoin.capital/2018/02/13/new-models-utility-tokens/ +[datacredit]: /tokens/data-credit +[hip-20]: https://github.com/helium/HIP/blob/master/0020-hnt-max-supply.md#net-emissions +[hip-141]: + https://github.com/helium/HIP/blob/main/0141-single-token-governance-and-release-proposals.md#smoothing-function +[hrp-2025-03]: + https://github.com/helium/helium-release-proposals/blob/main/releases/20250312-core-devs.md#1-hnt-token-net-emissions-smoothing +[iot]: /tokens/iot-token +[mobile]: /tokens/mobile-token +[sol-emissions]: + https://github.com/helium/HIP/blob/main/files/0077/token-emissions-as-of-solana-migration.pdf +[hnt-mint-addr]: https://explorer.solana.com/address/hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux diff --git a/docs/tokens/sol-token.mdx b/docs/tokens/sol-token.mdx new file mode 100644 index 000000000..f8038219f --- /dev/null +++ b/docs/tokens/sol-token.mdx @@ -0,0 +1,61 @@ +--- +id: sol-token +title: The Solana Token +pagination_label: SOL Token +sidebar_label: Solana (SOL) +description: Solana Token Documentation +image: https://docs.helium.com/img/link-image.png +slug: /tokens/sol-token +--- + +import { HntToSol } from './SolToken' + +The Helium Network runs on the [Solana](https://solana.com/) blockchain, an extremely fast, +scalable, and low-cost blockchain. + +Interacting with the Solana blockchain requires a small fee (average transaction fee is 0.000014 +SOL) paid in SOL tokens, which is massively cheaper than the original Helium blockchain transaction +fee of \$0.35 in DC. + +All interactions with the Solana blockchain require fees, including sending tokens, staking tokens, +making payments, swapping tokens, minting NFTs, claiming rewards from your Hotspots, and all +on-chain Helium transactions. + +## Solana Accounts and Rent + +Information is stored on the Solana blockchain, such as token balances, NFTs, or other data, in +"accounts." Keeping this data on-chain takes up space, so Solana charges a "rent" fee of ~0.002 SOL +on accounts. + +Rent Facts: + +- Each account has an individual rent fee. +- There is typically one account for each token type. +- Having more accounts (meaning more token types) requires more rent fees. +- Closing accounts can return rent to your wallet. + +Performing more complex transactions, which include creating accounts, may require more SOL. For +example, if a Wallet does not have enough SOL for rent fees, the Wallet **cannot** create new +accounts to hold tokens, and transactions will fail. + +This includes reasserting your Hotspot's location, locking HNT to gain veHNT, and potentially more +complex DeFi actions where multiple accounts must be created (even temporarily). + +--- + +## SOL Swap Utility + +If you do not have enough SOL, you can use this tool to swap HNT for 0.02 SOL. Open this page from +within the browser of the [Helium Wallet App][wallet-app] to swap a small amount of HNT for SOL. + +import { HntToFeeSol } from '@theme/HntToFeeSol' + +
+ +
+
+ + + +[wallet-app]: /wallets/helium-wallet-app +[vehnt]: /governance/vehnt diff --git a/docs/use-the-network/community-projects.mdx b/docs/use-the-network/community-projects.mdx deleted file mode 100644 index 7d9dbfced..000000000 --- a/docs/use-the-network/community-projects.mdx +++ /dev/null @@ -1,292 +0,0 @@ ---- -id: community-projects -title: Community Projects -pagination_label: Community Projects -sidebar_label: Community Projects -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/community-projects ---- - -# Community Projects - -Developers are using the Helium Network for hundreds of IoT and sensing applications. Here is a -snapshot of what's being built. All these projects are hosted on the -[Helium Hackster Community](https://www.hackster.io/helium). - -## Agricultural - - -    - -
- -    - -
- -## Dashboards - - -    - -
- -## Environmental - - -    - -
- -    - -
- -    - -
- -## Healthcare - - -    - -
- -    - -
- -## Industrial - - -    - -
- -    - -
- -## Security - - - -## Tracking - - -    - -
- -    - -
- -    - - -## Utility - - -    - -
- -    - -
- diff --git a/docs/use-the-network/console-marketplace.mdx b/docs/use-the-network/console-marketplace.mdx deleted file mode 100644 index 60b835fdf..000000000 --- a/docs/use-the-network/console-marketplace.mdx +++ /dev/null @@ -1,130 +0,0 @@ ---- -id: console-marketplace -title: Console Marketplace -pagination_label: Console Marketplace -sidebar_label: Console Marketplace -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console-marketplace ---- - -# Console Marketplace - -The Console Marketplace provides a way for Helium community members to contribute and share Console -components. Initially, this includes Integrations, but over time the marketplace will expand to -Decoders, and others. - -Console Hosting Providers can choose which components are available to end-users. Some (for example, -Helium Foundation) may choose to enable all available Console components, while others may only want -to provide their users access to fewer for simplicity. - -For more information about Integrations go [here](/use-the-network/console/integrations). - -## How it works overview - -Marketplace participants: - -- Community members: contribute Console components. -- Helium Foundation technical team: reviews and approves components. -- Console Hosting Providers: choose which approved components are available to Console users on - Console UI. -- Console users: decide which Console components to use. - -Follow the instructions to submit a Marketplace Integration or Decoder pull request to the Helium -Console github [repository](https://github.com/helium/console) for consideration by the Helium -Foundation. - -## Create a Marketplace Integration - -- Add image assets for icons. Icons should be square and in png or svg format. Place image assets in - `/assets/img/channels` folder and follow naming conventions. - -- Add new integration type to `/lib/console/channels/channel.ex` and indicate if new integration is - in `@http_types` and `@long_type_names`. - -- Import image assets and add new integration info to `integrationImgMap`, add an entry to - `COMMUNITY_INTEGRATION_TYPES`, and indicate if new integration is `http_integrations` or - `mqtt_integrations`. All in `/assets/js/util/integrationInfo.js`. - -- Create form component for new integration page in `/assets/js/components/channels/community` - folder and follow naming conventions. - -- Import form to `/assets/js/components/channels/ChannelNew.jsx` and add imported form component to - `renderForm()`. - -- Create form component for update integration page `/assets/js/components/channels/community` - folder and follow naming conventions. - -- Import form to `/assets/js/components/channels/ChannelConnectionDetails.jsx` and add imported form - to the switch case in `export default () =>`. - -- Add credential transform methods to populate actual connection details in file - `/lib/console/community/community_channels.ex` in `append_connection_details()` and - `inject_credentials()`. - -- Add new integration controller action to `/lib/console_web/controllers/v1/channel_controller.ex` - under `create_community_channel()` or create a new function if needed. - -More info about Integrations [here](/use-the-network/console/integrations). - -## Create a Marketplace Decoder Function (staging) - -- Decide on your format name. Make sure it is written in lower case (ex. `super_decoder`). - -- Add image assets for icons. Icons should be square and in png or svg format. Place image assets in - `/assets/img/functions/community` folder and follow naming conventions. - -- Add new function format (ex. `super_decoder`) to `@all_formats` in - `/lib/console/functions/function.ex` - -- Import image assets and add new function entry to `COMMUNITY_FUNCTION_FORMATS` in - `/assets/js/util/functionInfo.js`. Make sure the format value of the entry matches (ex. - `super_decoder`). - -- Create a new file in `/community_functions` with your function body written in javascript. - -- Create an `@variable` for your function body and add a case for your function in the - `inject_body()` method in `/lib/console/community/community_functions.ex` - -More info about Decoder Functions [here](/use-the-network/console/functions). - -## Enable Marketplace Integrations or Decoder Functions (For Console Hosting Providers) - -Console Hosting Providers can choose which Integrations or Decoder Functions are available for their -users. More information about becoming a Console Hosting Provider -[here](/use-the-network/run-a-network-server). - -:::warning - -An Integration must be available for devices to transfer data through it and a Decoder must be -available to decode packets. For example, if an existing Integration is disabled, any devices will -no longer be able to transfer data via that Integration. - -::: - -### Choosing Approved Integrations - -Choose which Integrations are available for users by making the following configuration settings. - -Set `ALLOWED_INTEGRATIONS` .env variable to toggle desired integrations. - -- To choose all reviewed integrations (default): `ALLOWED_INTEGRATIONS=all`. - -- To choose selected integrations: `ALLOWED_INTEGRATIONS=`. For example, to choose the - following integrations: HTTP, MQTT, CARGO: `ALLOWED_INTEGRATIONS=http,mqtt,cargo` - -Integration keys can be found in `/lib/console/channels/channel.ex` listed in `@long_type_names`. - -### Choosing Approved Decoder Functions (staging) - -Choose which Decoder Functions are available for users by making the following configuration -settings. - -Set `ALLOWED_FUNCTIONS` .env variable to toggle desired functions. - -- To choose all reviewed decoder functions (default): `ALLOWED_FUNCTIONS=all`. - -- To choose selected decoder functions: `ALLOWED_FUNCTIONS=`. For example, to choose the - following functions: CUSTOM, CAYENNE: `ALLOWED_FUNCTIONS=custom,cayenne` - -Function keys can be found in `/lib/console/functions/function.ex` listed in `@all_formats` diff --git a/docs/use-the-network/console/adding-devices.mdx b/docs/use-the-network/console/adding-devices.mdx deleted file mode 100644 index 2ca5304e7..000000000 --- a/docs/use-the-network/console/adding-devices.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -id: adding-devices -title: Adding Devices -pagination_label: Adding Devices -sidebar_label: Adding Devices -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/adding-devices ---- - -# Adding Devices - -import useBaseUrl from '@docusaurus/useBaseUrl' - -### When Adding Devices for the First Time - -As network usage increases, a mechanism called the XOR filter allows the Console backend (router) to -only process known traffic and avoid spending resources on unfamiliar packets, which significantly -improves performance. - -However, the first time a device joins the network its keys need to be added to the blockchain and -the updated block propagated to the miners (Hotspots). - -This initial join process could take up to 20 mins depending on: - -- when this transaction (batched with others) gets added to the blockchain -- the overall performance of the blockchain - -After the initial join takes place future rejoining of the same device will be much quicker. - -More information about XOR filters [here](/devblog/2021/07/29/console-updates-2.0). - -:::info - -For a video tutorial on adding and importing devices, check out our Tips and Tricks video -[here](https://youtu.be/ntr839pqWpg). - -::: - -To add a device, go to **Devices** and click the **+ Add Device** icon. The Add New Device screen -appears. - -:::important - -Helium Console users are capped at ONE (1) Organization and 10 devices for their account. - -If your account as of March 31, 2022 exceeds this cap, you can continue using Helium Console with -those existing devices and Orgs for 12 calendar months, but will not be able to add additional -devices and Orgs. - -To continue with more than 1 Org / 10 devices after 12 months, you will need to work with a member -of the ecosystem, host your own instance, or contact a team member at sales@nova-labs.com. - -\*While an account is in an overage state with > 1 Org / 10 devices and a device or Org is deleted, -additional devices or Orgs cannot be re-added. - -Users over the cap who would like to immediately add more devices/Organizations, or users who have -not yet exceeded the cap but plan to do so, can reach out to members of the ecosystem, host their -own instance, or contact sales@nova-labs.com. - -::: - - - -Enter a name for your device. Device names do not have to be unique \(as every device will be given -a unique identifier generated by Console\). - -`DevEUI`, `AppEUI`, and `AppKey` are auto generated by the Helium Console when you create a new -device. - -However, you can input your own `DevEUI`, `AppEUI`, and `AppKey` if your device is already -provisioned with these credentials. - -- **Device EUI** - 64-bit end-device identifier, sometimes called Manufacturer EUI -- **App EUI** - 64-bit application identifier -- **App Key** - 128-bit AES key, used to secure communication between device and network - -Once added, you'll see a consolidated view of all your device details, as well as the Activation -Method \(only `OTAA` is currently supported\). - - - -## Scan Device QR Code - -The mobile interface provides the ability to scan QR codes of sensors that are **based on the -LoRaWAN Device Identification QR Codes specification** -[here](https://lora-alliance.org/resource_hub/tr005-lorawan-device-identification-qr-codes/). - -Scanning the code will populate the `DevEUI` and `AppEUI` fields. AppKey will still need to be -manually entered. - -## Importing Devices - -Console provides a simple way to batch add multiple devices using a CSV file. - -To add a device, go to Devices and click the + Add Device icon. - -Under Import Devices choose a .csv file that contains the information for the imported devices. The -.csv file needs to include the following fields as required columns: `DevEUI`, `AppEUI`, `AppKey`, -and `Name`. Optionally you can include a `LabelID` column to add labels to imported devices. - - - -## Important Information When Adding Devices - -### Potential Delays Related to Sub-band - -LoRaWAN devices may behave differently from one manufacturer to another. If your device does not try -all 8 sub-bands, then you will need to ensure it is trying to communicate on the correct sub-band, -which is sub-band 2. - -### MSB vs LSB; and using the Correct Endianness - -When copying EUIs and Keys into your device software, or into Console, make sure you are using the -correct byte ordering, known as "endianness". This is often labeled as `MSB` \(Most Significant -Bit\) and `LSB` \(Least Significant Bit\). Reversing byte order is a very common mistake when adding -a new device to the network. On the device details page in Console, you can easily switch the byte -order of the EUIs and Key by cliking the `lsb` or `msb` label next to them. - -### Is The Helium Network a Public or Private LoRaWAN? - -The Helium Network is a Public LoRaWAN Network. You can read more about the unique, -blockchain-driven architecture [here](/blockchain). diff --git a/docs/use-the-network/console/alerts.mdx b/docs/use-the-network/console/alerts.mdx deleted file mode 100644 index 0b33b742b..000000000 --- a/docs/use-the-network/console/alerts.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: alerts -title: Alerts -pagination_label: Alerts -sidebar_label: Alerts -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/alerts ---- - -# Alerts - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Alerts (email or webhooks) can be configured for a number of conditions related to devices and -integrations including when devices are deleted, or when integrations are updated or deleted. - -User types (e.g., Administrator or Managers) can be specified to receive alerts. - -:::info - -For a video walkthrough of how to configure Alerts in Console, check out our Tips & Tricks video -[here](https://youtu.be/xv8aM1oNIEs). - -::: - -### Configuring Alerts - -To configure alerts from the Flows workspace, select a Device/Label node or Integration node -depending on the type of alert to configure and select the Inspector tab. - -Select an existing alert or create a new one. - -To create a new one, select Create New Alert choose a name, alert type (email, webhook), and the -alert. - - - -**Note:** For webhook alerts, obtain a webhook key for authorization by choosing Organizations from -the side menu and copying relevant webhook key. diff --git a/docs/use-the-network/console/api.mdx b/docs/use-the-network/console/api.mdx deleted file mode 100644 index d2f1a1336..000000000 --- a/docs/use-the-network/console/api.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -id: console-api -title: Console API -pagination_label: Console API -sidebar_label: Console API -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/api ---- - -# Console API - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Console API lets you interact with the console via HTTP Requests. You can either do that -directly using the HTTP API or you can leverage the CLI, which abstracts the API and provides higher -level features like importing devices from other network providers. - -View the API Specification [here](/api/console) diff --git a/docs/use-the-network/console/cli.mdx b/docs/use-the-network/console/cli.mdx deleted file mode 100644 index 4879a344f..000000000 --- a/docs/use-the-network/console/cli.mdx +++ /dev/null @@ -1,146 +0,0 @@ ---- -id: console-cli -title: Console CLI -pagination_label: Console CLI -sidebar_label: Console CLI -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/cli ---- - -# Console CLI - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Introduction - -The Command Line Interface \(CLI\) allows you to interact with the Console API without making HTTP -Requests, but instead via a command line prompt. It's ideal for mass provisioning or for integrating -onto a production line. - -In addition, it has certain high-level features for account setup like importing devices from other -network providers. - -## Installation - -Download a compiled release [here](https://github.com/helium/helium-console-cli/releases) for your -appropriate platform. - -## API Key - -You must activate a [Console API key](./my-account#console-api-keys) before using the CLI. - -The first time you run the CLI, it will prompt you for this key. It will save the key in a local -file: `.helium-console-config.toml` - -## Usage - -### Features - -You can view the most current commands, features, and documentation by accessing the help menus. For -example: `helium-console-cli --help` or `helium-console-cli device --help`. - -Current high level features are: - -- create and delete devices records, using \(app_eui, app_key, dev_eui\) or UUID -- list all device records -- create and delete labels by UUID -- create and delete device labels, by using \(device_uuid, label_uuid\) -- import devices from The Things Network \(TTN\ - - ) - -### Examples - -Let's create a device: - -```text -helium-console-cli device create 000A000100000046 CB67C92DD5898D07872224202DED7E76 DEADBEEF23F23454 foo -``` - -You'll get a response with the full record of this new device: - -```text -Device { - app_eui: "000A000100000046", - app_key: "CB67C92DD5898D07872224202DED7E76", - dev_eui: "DEADBEEF23F23454", - id: "03f5967a-7c79-42a2-bd5f-6e51015e73e3", - name: "foo", - organization_id: "07273bc4-4bc9-44ec-b4d5-ad320f162e15", - oui: 1, -} -``` - -You can view this device again by either \(app_eui, app_key, dev_eui\) or by id/uuid. For example: - -```text -helium-console-cli device get 000A000100000046 CB67C92DD5898D07872224202DED7E76 DEADBEEF23F23454 -``` - -or - -```text -helium-console-cli device get-by-id 03f5967a-7c79-42a2-bd5f-6e51015e73e3 -``` - -These commands will return the same record as above. - -Similarly, you may delete the device: - -```text -helium-console-cli device delete 000A000100000046 CB67C92DD5898D07872224202DED7E76 DEADBEEF23F23454 -``` - -or - -```text -helium-console-cli device delete-by-id 03f5967a-7c79-42a2-bd5f-6e51015e73e3 -``` - -Finally, at any time, you may list all your devices: - -```text -helium-console-cli device list -``` - -Which will return an array of all your devices: - -```text -[ - Device { - app_eui: "000A000100000046", - app_key: "CB67C92DD5898D07872224202DED7E76", - dev_eui: "DEADBEEF23F23454", - id: "03f5967a-7c79-42a2-bd5f-6e51015e73e3", - name: "foo", - organization_id: "07273bc4-4bc9-44ec-b4d5-ad320f162e15", - oui: 1, - } -] -``` - -### TTN Import - -To start an import session, use the ttn import command: - -```text -helium-console-cli ttn import -``` - -You will be prompted for a ttnctl access code, which you can generate by clicking on -`ttnctl access code` [here](https://account.thethingsnetwork.org/). This single-use access code is -valid for 5 minutes. During this time the CLI may use the code to request an OAuth2 token; it -expires after 60 minutes. - -The CLI's prompts will help you: - -- select to import from a single application or all applications \(maximum 10, otherwise the OAuth2 - token is "used up"\) -- you may import all the devices at once or you may approve device import one by one. -- you may use the TTN App ID as an automatic label for every device or you may approve device - labelling one by one - -The import process tolerates attempts to re-import or re-label the same device. As such, you may -re-run the script to label devices with the TTN App ID even if you already imported the devices -during a previous session. diff --git a/docs/use-the-network/console/console-hosting-providers.mdx b/docs/use-the-network/console/console-hosting-providers.mdx deleted file mode 100644 index 23c503a36..000000000 --- a/docs/use-the-network/console/console-hosting-providers.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: hosting-providers -title: Hosting Providers -pagination_label: Hosting Providers -sidebar_label: Console Hosting Providers -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/hosting-providers ---- - -# Console Hosting Providers - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This space provides information about Console Hosting Providers available in the community. Note -this is not an exhaustive list, and if you’d like to add your company feel free to make a pull -request: https://github.com/helium/docs - -:::info - -Links and information for these Console Hosting Providers is provided as is. - -::: - -The Helium Foundation is not directly associated with any of the following vendors and makes no -endorsements about the quality of their offering. For more details including pricing, please reach -out to the given provider. - -- Helium IoT Eur - A Console Hosting Provider based in the EU. More information - [here](https://www.helium-iot.eu/use-helium-with-helium-iot-europe/). -- Ubidots - Power your IoT and cloud applications with Ubidots. Sign up for beta - [here](https://bit.ly/3JygTvn). -- Foundation Console - For demo and educational purposes. Capped at 10 devices and a single - Organization. Sign up [here](https://console.helium.com/). No API v1 endpoint access on the - Foundation Console. -- BrDot Console - Console Hosting Provider based in Brazil. For more information contact - sales@brdot.co. -- MeteoScientific - Public and permissionless access to a Console, get an account along with free DC - to start [here](https://console.meteoscientific.com/front/). diff --git a/docs/use-the-network/console/console.mdx b/docs/use-the-network/console/console.mdx deleted file mode 100644 index 591053434..000000000 --- a/docs/use-the-network/console/console.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -id: console -title: Console -pagination_label: Console -sidebar_label: Helium Console -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console ---- - -# Helium Console - -The [Helium Console](http://console.helium.com/) is a web-based device management tool hosted by the -Helium Foundation that allows developers to register, authenticate, and manage their devices on the -Helium network. In addition to device management, Console provides prebuilt connections called -Integrations to route device data via HTTPs or MQTT; or directly to cloud services like AWS IoT. - -Device Management includes: - -- Flows: a visual-centric view of the key elements in Console and allows users to instantly - understand the relationship among devices, functions, and integrations. -- Organization structure with labels, and user-level permissions -- Device ID registration and seamless, secure onboarding and authentication -- Data Credits for utilizing the Helium Network - -Console is available as a free to use hosted application for demo and educational purposes (up to 10 -devices) at [console.helium.com](https://console.helium.com). - -:::info - -Console hosted by the Helium Foundation provides a way for users to easily onboard and test or demo -devices on the Helium Network. It is capped at 10 devices and a single Organization. For large -deployments and commercial use, users should consider Console Hosting Providers in the ecosystem -[here](/use-the-network/console/hosting-providers) (note: this is not an exhaustive list, and -listing does not equal endorsement). - -::: - -Learn more about how to get started using Console with our Tips and Tricks videos -[here](https://www.youtube.com/playlist?list=PLtKQNefsR5zNjWkXqdRXeBbSmYWRJFCuo). - -### Getting Started - -- [Console Quickstart](/use-the-network/console/quickstart) -- [Host Your Own Console](/use-the-network/run-a-network-server) - -### Devices - -- [Adding/Importing](/use-the-network/console/adding-devices) -- [Migrating](/use-the-network/console/migrating-devices) -- [Grouping](/use-the-network/console/labels) - -### Data - -- [Transferring (Integrations)](/use-the-network/console/integrations) -- [Decoding](/use-the-network/console/functions) -- [Monitoring Gateways/Hotspots](/use-the-network/console/coverage) -- [Console Marketplace](/use-the-network/console-marketplace) - -### Configurations - -- [Node Interface (Flows)](/use-the-network/console/flows) -- [Alerts](/use-the-network/console/alerts) -- [Packet Configurations](/use-the-network/console/multi-packets) -- [Configuration Profiles (ADR, CF List, Receive Windows)](/use-the-network/console/profiles) - -### Admin - -- [Users and Organizations](/use-the-network/console/users) -- [Data Payment](/data-credit) -- [CLI](/use-the-network/console/cli) -- [API](/use-the-network/console/api) -- [Account Security and API Keys](/use-the-network/console/my-account) - -### Issues - -- [Debug](/use-the-network/console/debug) -- [Troubleshooting](/use-the-network/console/troubleshooting) diff --git a/docs/use-the-network/console/coverage.mdx b/docs/use-the-network/console/coverage.mdx deleted file mode 100644 index 10c485e4a..000000000 --- a/docs/use-the-network/console/coverage.mdx +++ /dev/null @@ -1,110 +0,0 @@ ---- -id: coverage -title: Coverage -pagination_label: Coverage -sidebar_label: Coverage -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/coverage ---- - -# Coverage - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Coverage provides visibility for Hotspots that transfer device packets as well as the status of -those Hotspots within Console. - -:::info - -To learn more about Coverage in Console, check out our Tips & Tricks video -[here](https://youtu.be/Woh4RooY6L8). - -::: - -## Identify Hotspots that hear devices - -Coverage makes it easy to identify which Hotspots have transferred an organization’s device packets. -The `Coverage Breakdown` list is automatically populated with Hotspots that have sent traffic in the -last 24 hrs for devices belonging to the Organization. - -:::info - -Only Hotspots that have successfully transferred packets are displayed on the Coverage Breakdown -tab. To show all Hotspots on this tab within range of the device, turn on Multiple Packets -[here](/use-the-network/console/profiles/) and choose to purchase all packets. Assuming there is -sufficient Data Credit balance, Console will purchase packets from all the Hotspots that heard the -device and display them. - -::: - -`My Hotspots` is a simple way to filter and view only Hotspots users want to see. Select the flag -icon next to a Hotspot name for it to appear in the My Hotspots list. - -If a Hotspot has not transferred data but is still of interest, simply navigate to `Hotspot Search` -run a search for it, and it will appear in the My Hotspots list. Users can also use a wallet address -and all Hotspots associated with that wallet address will appear. - -## Monitoring Hotspots stats and status - -Coverage displays a number of Hotspots details including Hotspot location, packets transferred, and -number of devices that it’s “seen”. - -Simply click a Hotspot name to view more detailed Hotspot stats. Depending on the tab, users can -display overall stats (`Statistics` tab) or a list of the devices heard from the last 24 hours with -the `My Devices Heard` tab. - -Clicking any device name takes users to the specific device page for more details. - -## Create Hotspot Aliases - -Coverage allows users to easily create an alias for easier identification of the Hotspot. Click a -Hotspot name, then under its animal name, click `No Alias` to define an Alias. - -## Creating Hotspot Aliases - -Coverage allows users to easily create an alias for easier identification of the Hotspot. Click a -Hotspot name, then under its animal name, click `No Alias` to define an Alias. - - - -## Group Hotspots - -The Coverage feature allows users to create Hotspot groups for easy management. To be added to a -group, Hotspots must initially be followed and appear in the My Hotspots area. To add Hotspots to -`My Hotspot` list check -[here](/use-the-network/console/coverage/#identify-hotspots-that-hear-devices). - -### Creating a Hotspot group - -- On the left-hand menu, choose **Coverage**. -- Under `My Hotspot Groups`, click **+ Create Hotspot Group**, and enter the group name (minimum 3 - characters). - -### Adding a Hotspot to a group - -Before a Hotspot can be added to a group it must be followed and appear in the `My Hotspots` list. - -- Under `My Hotspots`, select the desired Hotspot row, and under the `Groups` column click and - choose the name of the desired Group to add the Hotspot. Note: Hotspots can belong in multiple - groups. - -### Removing a Hotspot from a group - -A Hotspot can easily be removed from a group. Note: this action only removes the Hotspot from the -group, and it will continue to appear in the `My Hotspots` list. - -- Under `My Hotspots Group`, click the Group that includes the Hotspot(s) you want to remove. -- Select the row of the Hotspot to remove and under the `Groups` column click the blue check next to - the group name. The Hotspot is removed from the group. Note: Hotspots can belong in multiple - groups. - -### Modifying groups - -Groups can be renamed or deleted. - -- Under `My Hotspots Group`, click the Group you want to: - - Rename: Click **Rename Hotspot Group**, type the name, and click **Submit**. - - Delete: Click **Delete Hotspot Group**. A confirmation message appears with Hotspots in the - group. Click **Submit** to delete the group. Note: Hotspots in a deleted group will continue to - appear in the `My Hotspots` list, and this action only deletes the group. diff --git a/docs/use-the-network/console/debug.mdx b/docs/use-the-network/console/debug.mdx deleted file mode 100644 index bdfc3e735..000000000 --- a/docs/use-the-network/console/debug.mdx +++ /dev/null @@ -1,312 +0,0 @@ ---- -id: debug -title: Debug -pagination_label: Debug -sidebar_label: Debug -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/debug ---- - -# Debug - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The Console Debug tool allows you to quickly and easily examine device messages. This enables you to -verify and debug issues much more easily without requiring the data to be sent to an application -endpoint first. For security and privacy reasons the Debug tool does not persist data. Instead, the -40 most recent events are accumulated from the time the Debug window is opened. - -### Using The Debug Tool - -The Debug tool is located on the upper right side of every device page \(shown in the image below\). -To access it, just click the Debug tab and a window will pop out. - - - -At first you will see a spinning wheel and the message _waiting for data._ This is because the Debug -tool only shows packets that come through while the window is open. - - - -Once packets are received or sent down to your device, you will see them display immediately in the -Debug window, seen here: - - - -### Debug Packet Types - -The Debug tool will display a message for every uplink or downlink. For detailed information on the -contents of the messages please see the JSON schema documentation. - -:::info Payloads shown in the debug messages are [base64 - -encoded](https://en.wikipedia.org/wiki/Base64), as are the JSON messages received by integrations. -You will need to decode the payload strings in order to correctly interpret the payload data. One -way to do this is to use a [Function Decoder](functions). - -::: - -#### Activation - -When your device first joins the network, you will see a special uplink message just for the -activation, which will not have a payload, as shown below, and only includes a single hotspot. - -```text -{ - "channels": [], - "devaddr": null, - "device_name": "Helium Dev Kit", - "frame_down": 0, - "frame_up": 1, - "hotspots": [ - { - "frequency": 903.9000244140625, - "id": "11D86CyMMt685XcsddPtaChWr3qz2UxDyhGG5EUeZbwqemxjBMb", - "name": "fancy-rusty-toad", - "rssi": -35, - "snr": 11.5, - "spreading": "SF10BW125" - } - ], - "id": "2091f225-4b7c-4524-a2c1-5f41fb429099", - "payload": null, - "payload_size": 0, - "port": 0 -} -``` - -#### Uplink - -For uplink packets, a message similar to the one below will be shown. In addition to the original -uplink message data, which starts at the very bottom, these packet types will also show a message -for each integration attached to the device, so that you can examine what is being sent to those -endpoints. For the message shown below, you can see there is a message for a **RequestBin** and -**Cayenne** Integrations attached to this device. You can differentiate uplink messages by keeping -track of the `frame_up` count. - -```text -{ - "channels": [ - { - "debug": { - "req": { - "body": { - "app_eui": "5C23E22B09F08C65", - "dev_eui": "00D644FC35CFC35E", - "devaddr": "94020048", - "downlink_url": "https://console.helium.com/api/v1/down/a22f600d-8453-4eac-912d-83f713f1df2b//d2c7b8dc-221a-4ec8-aedd-6c19ae348a33", - "fcnt": 1, - "hotspots": [ - { - "channel": 10, - "frequency": 904.2999877929688, - "id": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "lat": 37.76921631427912, - "long": -122.40353864671341, - "name": "rare-burlap-python", - "reported_at": 1593801826, - "rssi": -46, - "snr": 9.800000190734863, - "spreading": "SF9BW125", - "status": "success" - }, - { - "channel": 10, - "frequency": 904.2999877929688, - "id": "117ei8DWNjSFuLgg3BrtTNSTi2tt14LRUFgt1Bk2kYqkHWrg82c", - "lat": 37.850571034925125, - "long": -122.24405901009771, - "name": "square-goldenrod-gorilla", - "reported_at": 1593801826, - "rssi": -73, - "snr": 10, - "spreading": "SF9BW125", - "status": "success" - } - ], - "id": "d2c7b8dc-221a-4ec8-aedd-6c19ae348a33", - "metadata": { - "labels": [ - { - "id": "153baa5c-9bbe-4afb-bab4-a13358f2638d", - "name": "RequestBin", - "organization_id": "ef7c0454-177f-4ef3-aaab-d2a9ba6e9d15" - }, - { - "id": "fe5d41e4-82e6-4ea5-8e6e-e94aed3de79a", - "name": "Cayenne Integration", - "organization_id": "ef7c0454-177f-4ef3-aaab-d2a9ba6e9d15" - } - ] - }, - "name": "Helium Dev Kit", - "payload": "SGVsbG8sIFdvcmxkIQA=", - "port": 1, - "reported_at": 1593801826 - }, - "headers": { - "Content-Type": "application/json" - }, - "method": "post", - "url": "https://lora.mydevices.com/v1/networks/helium/uplink" - }, - "res": { - "body": "", - "code": 200, - "headers": { - "Connection": "keep-alive", - "Content-Length": "0", - "Date": "Fri, 03 Jul 2020 18:43:47 GMT", - "cache-control": "no-cache", - "vary": "origin" - } - } - }, - "description": "Connection established", - "id": "a22f600d-8453-4eac-912d-83f713f1df2b", - "name": "CayenneIntegration", - "status": "success" - }, - { - "debug": { - "req": { - "body": { - "app_eui": "5C23E22B09F08C65", - "dev_eui": "00D644FC35CFC35E", - "devaddr": "94020048", - "downlink_url": "https://console.helium.com/api/v1/down/897780bc-6980-42c1-a659-30077e8dbcd1/h4IxFDle6biV1ZKmrUJamaXhKjRRF3c-/d2c7b8dc-221a-4ec8-aedd-6c19ae348a33", - "fcnt": 1, - "hotspots": [ - { - "channel": 10, - "frequency": 904.2999877929688, - "id": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "lat": 37.76921631427912, - "long": -122.40353864671341, - "name": "rare-burlap-python", - "reported_at": 1593801826, - "rssi": -46, - "snr": 9.800000190734863, - "spreading": "SF9BW125", - "status": "success" - }, - { - "channel": 10, - "frequency": 904.2999877929688, - "id": "117ei8DWNjSFuLgg3BrtTNSTi2tt14LRUFgt1Bk2kYqkHWrg82c", - "lat": 37.850571034925125, - "long": -122.24405901009771, - "name": "square-goldenrod-gorilla", - "reported_at": 1593801826, - "rssi": -73, - "snr": 10, - "spreading": "SF9BW125", - "status": "success" - } - ], - "id": "d2c7b8dc-221a-4ec8-aedd-6c19ae348a33", - "metadata": { - "labels": [ - { - "id": "153baa5c-9bbe-4afb-bab4-a13358f2638d", - "name": "RequestBin", - "organization_id": "ef7c0454-177f-4ef3-aaab-d2a9ba6e9d15" - }, - { - "id": "fe5d41e4-82e6-4ea5-8e6e-e94aed3de79a", - "name": "Cayenne Integration", - "organization_id": "ef7c0454-177f-4ef3-aaab-d2a9ba6e9d15" - } - ] - }, - "name": "Helium Dev Kit", - "payload": "SGVsbG8sIFdvcmxkIQA=", - "port": 1, - "reported_at": 1593801826 - }, - "headers": { - "Content-Type": "application/json" - }, - "method": "post", - "url": "https://enyfenof1pbel.x.pipedream.net/" - }, - "res": { - "body": { - "success": true - }, - "code": 200, - "headers": { - "Access-Control-Allow-Origin": "*", - "Connection": "keep-alive", - "Content-Length": "16", - "Content-Type": "application/json; charset=utf-8", - "Date": "Fri, 03 Jul 2020 18:43:47 GMT", - "X-Powered-By": "Express", - "x-pd-status": "sent to primary" - } - } - }, - "description": "{\"success\":true}", - "id": "897780bc-6980-42c1-a659-30077e8dbcd1", - "name": "RequestBin", - "status": "success" - } - ], - "devaddr": "94020048", - "device_name": "Helium Dev Kit", - "frame_down": 1, - "frame_up": 1, - "hotspots": [ - { - "frequency": 904.2999877929688, - "id": "113kQU96zqePySTahB7PEde9ZpoWK76DYK1f57wyhjhXCBoAu88", - "name": "rare-burlap-python", - "rssi": -46, - "snr": 9.800000190734863, - "spreading": "SF9BW125" - }, - { - "frequency": 904.2999877929688, - "id": "117ei8DWNjSFuLgg3BrtTNSTi2tt14LRUFgt1Bk2kYqkHWrg82c", - "name": "square-goldenrod-gorilla", - "rssi": -73, - "snr": 10, - "spreading": "SF9BW125" - } - ], - "id": "3d62df26-a153-406c-ab85-028a5107d681", - "payload": "SGVsbG8sIFdvcmxkIQA=", - "payload_size": 14, - "port": 1 -} -``` - -#### Downlink / ACK - -`Downlink` and `ACK` messages will only show a single hotspot, similar to the activation message. -You can differentiate downlink messages by keeping track of the `frame_down` count. - -```text -{ - "channels": [], - "devaddr": null, - "device_name": "Helium Dev Kit", - "frame_down": 2, - "frame_up": 1, - "hotspots": [ - { - "frequency": 903.9000244140625, - "id": "11D86CyMMt685XcsddPtaChWr3qz2UxDyhGG5EUeZbwqemxjBMb", - "name": "fancy-rusty-toad", - "rssi": -35, - "snr": 11.5, - "spreading": "SF10BW125" - } - ], - "id": "2091f225-4b7c-4524-a2c1-5f41fb429099", - "payload": null, - "payload_size": 0, - "port": 0 -} -``` diff --git a/docs/use-the-network/console/flows/actions.mdx b/docs/use-the-network/console/flows/actions.mdx deleted file mode 100644 index a920ab372..000000000 --- a/docs/use-the-network/console/flows/actions.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -id: actions -title: Actions -pagination_label: Actions -sidebar_label: Common Flow Actions -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/flows/actions ---- - -# Common Flows Actions - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Frequent actions performed from the Flows workspace include the following: - -- creating node elements -- adding nodes to the workspace -- accessing debug mode -- viewing the inspector - -### Creating Node Elements - -To use Flows the node elements (devices, labels, integrations, and functions) must already have been -created. - -To create any node element from the Flows workspace, click the **+** circle and choose the desired -node element. - - - -### Adding Nodes to the Workspace - -Important the core node elements must have been previously created before you can add them to the -workspace (for info on creating node elements go here). - -To add nodes to the workspace, go to the Nodes list, click **+**. - - - -The Nodes panel appears: - - - -### Accessing Debug mode - -Debug mode shows packet transfer in real time. - -To access Debug mode from the Flows workspace, select a device or label and click the Debug mode -tab. - - - -### Viewing the Inspector - -The Inspector allows users to see node details, remove nodes/edges, as well as make limited changes. - - - -### Add Labels to Devices - -To add a label to a device from the Flows workspace, select the desired label, then on the Inspector -choose from the Quick Action menu. - - diff --git a/docs/use-the-network/console/flows/flows-faq.mdx b/docs/use-the-network/console/flows/flows-faq.mdx deleted file mode 100644 index 836243b1f..000000000 --- a/docs/use-the-network/console/flows/flows-faq.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: flows-faq -title: Flows FAQ -pagination_label: Flows FAQ -sidebar_label: Frequently Asked Questions -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/flows/flows-faq ---- - -# Frequently Asked Questions - -import useBaseUrl from '@docusaurus/useBaseUrl' - -### What’s changed in Helium Console? - -The biggest new feature of Console is Flows. Flows is a visual-centric view of the key elements in -Console and allows users to instantly understand the relationship among devices, functions, and -integrations. Flows enables users to visually connect nodes and control the flow of data. - -### What’s the same in Helium Console? - -The interface and work flows for the following have remained largely unchanged: - -- Data Credits -- Organizations -- Users - -### Why did you make these updates to Console? - -Based on learnings from your feedback, the team wanted to deliver a much more streamlined and -intuitive experience to accomplish core user goals including adding devices, defining functions, and -setting up integrations to transfer data to endpoints. - -### Do labels still exist? Do I still need labels? What capabilities do labels have? - -Yes. Labels will still exist to organize and manage devices. Users can choose to apply a single or -multiple Labels to as many devices as needed; for example, to identify a sensor type like a "temp -sensor" or location of the sensor. Anytime Labels are updated the changes flow to all devices with -the Labels. - -### What happens to functionality that used to be tied to labels (ADR, Notifications, multiple packet purchases)? - -This functionality still exists. ADR and CF List can be directly applied to a device or group of -devices. With notification and packet purchase users can define these features with general settings -and apply to devices or groups of devices in the Flows workspace. - -### What will happen to devices and settings when you migrate Console to the production server? - -Nothing. Your devices and configurations will be preserved and you won’t need to take any action. - -### What happens to my Data Credit balance? - -This migration has no impact on Data Credit balances. diff --git a/docs/use-the-network/console/flows/flows.mdx b/docs/use-the-network/console/flows/flows.mdx deleted file mode 100644 index 490c4ade2..000000000 --- a/docs/use-the-network/console/flows/flows.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -id: flows -title: Flows -pagination_label: Flows -sidebar_label: Flows -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/flows ---- - -# Flows - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -Welcome to Flows. Flows is a visual-centric view of the key elements in Console and allows users to -instantly understand the relationship among devices, functions, and integrations. Flows enables -users to visually connect nodes and control the flow of data. - -Although Flows is a new feature, it’s designed to be much more intuitive based on core user goals of -adding devices, defining functions, and setting up integrations to transfer data to their endpoints. - -For a video walkthough of the basic Flows functions, check out our Tips and Tricks video -[here](https://youtu.be/XrbN1CHApBI). - -- [Flows Orientation](/use-the-network/console/flows/orientation) -- [Common Actions](/use-the-network/console/flows/actions) -- [Frequently Asked Questions](/use-the-network/console/flows/flows-faq) diff --git a/docs/use-the-network/console/flows/orientation.mdx b/docs/use-the-network/console/flows/orientation.mdx deleted file mode 100644 index 33a7e0523..000000000 --- a/docs/use-the-network/console/flows/orientation.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -id: orientation -title: Orientation -pagination_label: Orientation -sidebar_label: Flows Orientation -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/flows/orientation ---- - -# Flows Orientation - -import useBaseUrl from '@docusaurus/useBaseUrl' - -The main elements of Flows are: - -- [The Workspace](#workspace) -- [Nodes and Edges](#nodes-and-edges) -- [Inspector](#inspector) -- [Debug Mode](#debug-mode) - -## Workspace - -The Workspace is where you access and manipulate nodes, make connections among nodes, and make node -configuration settings using the Inspector. - -The Workspace is optimized for manipulation of visual elements, and there’s a subset of -configuration changes that can be made via the Inspector. - -Whenever you change elements on the workspace, save your changes so it’s the same when you come back -to it after navigating to other parts of Console. - -## Nodes and Edges - -### Nodes - -Nodes are graphical representations of Console elements and for quick identification are color -coded. Connection points are used to create relationships among nodes. - - - -Devices: device nodes represent the hardware that is sending the packets. Since devices are the -source of data and integrations can only receive data there’s only one connection point for edges. - - - -Labels: label nodes represent a group of devices with a common - - - -Functions: users can transform and/or parse payloads before sending to an endpoint. Functions can -both receive data from devices and continue sending data after taking action to integrations. - - - -Integrations: enable devices to customer endpoints over HTTP or MQTT. - - - -### Edges - -Edges represent the flow of data from device or label nodes moving from left to right. Edges use -connection points create relationships among nodes. - -Users can control the flow of device data using edges to provide the following connections from -devices/groups of devices (via labels): - -- to integrations -- to functions -- to function and on to integrations - - - -## Inspector - -The Inspector provides the ability to: - -- Visually inspect node details -- Make common node configuration changes -- Access node in other areas of Console for more complete edits - - - -To access the Inspector simply click a node and different options appear for the following: - -- Devices or Labels -- Functions -- Integrations - -## Debug Mode - -The Console Debug tool allows you to quickly and easily examine device messages. This enables you to -verify and debug issues much more easily without requiring the data to be sent to an application -endpoint first. For security and privacy reasons the Debug tool does not persist data. Instead, the -40 most recent events are accumulated from the time the Debug window is opened. - - - -For more information about Debug Mode go [here](/use-the-network/console/debug). diff --git a/docs/use-the-network/console/functions.mdx b/docs/use-the-network/console/functions.mdx deleted file mode 100644 index 80c89b1ff..000000000 --- a/docs/use-the-network/console/functions.mdx +++ /dev/null @@ -1,119 +0,0 @@ ---- -id: functions -title: Functions -pagination_label: Functions -sidebar_label: Functions -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/functions ---- - -# Functions - -import useBaseUrl from '@docusaurus/useBaseUrl' - -You can now execute functions on Console! With the Decoder Function, users can transform and/or -parse a raw payload before it is posted to an endpoint. - -When a Decoder Function is applied to a device or integration, the Decoder Function code is executed -on the payload sent by the device, and the result is passed to the Integration. -The Decoder Function can be written using custom JavaScript code -provided by the user or selected from prebuilt decoders \(currently Browan Object Locator and -Cayenne LPP\). - -Console decoders are compatible with The Things Network \(TTN\) decoders, which are already -available for a wide variety of devices. - -In addition to creating a custom decoder, Helium maintains a [growing list of community-created -functions](https://github.com/helium/console-decoders). - -For more information on how to create and attach functions, check out our -[Tips and Tricks video](https://youtu.be/UNUOLbIKXww). - -## A Primer on Encoding and Decoding - -LoRaWAN networks are, by design, low bandwidth. Thus, developers make the most out of -every byte sent over the air. Developers also shouldn't send inefficient types like -characters and strings. For example, to represent a single English letter with the widely used ASCII -encoding standard, you have to use an entire byte. This makes sense if your data can only be stored -as English words, but in the case of IoT devices, there is often only the need to store numeric -values. For every transmission, we want to pack as much information into as few bytes as possible. -Because of this, there are special encoding standards specifically made for sending common IoT -device data such as -[CayenneLPP](https://developers.mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload). - -These types of standards allow you to easily encode your data much more efficiently. Once your data -has been received over the air by the network, there is no longer the necessity of encoding the data -with a standard that can make it more challenging for humans to interpret. - -**Function Decoders** allow you to decode your device data within the Helium Console so that you -can interpret it for debugging issues and/or translate \(decode\) it before sending it to your -application/service via an Integration \(e.g., HTTP\). - -## Creating a Decoder Function - -:::info **Decoder Library on GitHub** - -If you have purchased an off-the-shelf device, it is likely that there already exists a decoder you -can use! We have a [repository](https://github.com/helium/console-decoders) that contains decoders -for a number of popular devices. - -::: - -To begin creating a new function within the Helium Console, select Functions from the left side -navigation. Then create a new Function by clicking the Add New Function **+** icon. [IMAGE] - -Name your new Function, select "Decoder" as Function Type, and "Custom Script" as Format if you want -to enter your own script, or select from the predefined decoders. - - - -Next we need to enter the JavaScript that will decode our payloads for us. The Script Validator -allows you to easily test inputs in hexadecimal form to ensure that your script will run -successfully. - - - -### Decoder Function Definition - -The decoder function parameters will include the device uplink payload as an array of bytes and the -uplink port. You can return any valid type value which will then be used at the decoder output. - -```text -function Decoder(bytes, port) { - - return decoded; -} -``` - -### Decoder Function Output - -The data returned by your function decoder will be included in an additional decoded.payload field -in the standard [JSON message](integrations/json-schema), it will not alter the original payload -field. An example of the decoded field is shown below. - -```text -"decoded": { - "payload": { - "BatV": 3.039, - "Ext_sensor": "Temperature Sensor", - "Hum_SHT": "53.8", - "TempC_DS": "327.67", - "TempC_SHT": "24.58" - }, - "status": "success" -}, -``` - -### Attaching Functions - -You need to attach functions to: - -- a device or a group of devices (via a label): the function is only applied to - the device payload in the Debug utility. - -- a device or group of devices (via a label) and an integration: the function is - applied to payloads before being sent to the integration. - -Easily attach functions to devices, labels, and integations in the -[Flows Workspace](/use-the-network/console/flows). diff --git a/docs/use-the-network/console/integrations/adafruitio.mdx b/docs/use-the-network/console/integrations/adafruitio.mdx deleted file mode 100644 index d451ccedd..000000000 --- a/docs/use-the-network/console/integrations/adafruitio.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -id: adafruitio -title: AdafruitIO -pagination_label: AdafruitIO -sidebar_label: AdafruitIO -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/adafruitio ---- - -# Adafruit IO - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Adafruit IO](https://io.adafruit.com/) is a powerful but simple to use Internet of Things platform -from Adafruit. It makes data from devices useful by allowing you to display, respond, and interact -with it. You can sign up for a free account at [https://io.adafruit.com](https://io.adafruit.com/). - -To add the integration in Console, go to **Integrations** on the left-hand menu. Select the -integration to add - in this case, the **Adafruit IO** integration as shown below. - - - -The next step is to enter your Adafruit IO username and key. These can be found by visiting -[https://io.adafruit.com](https://io.adafruit.com/) and clicking _MyKey_ in the top right corner as -shown below. - - - -You will then be presented with both your username and key as shown below. - - - -Copy these values into the username and key fields in Console for the integration configuration -shown below. - - - -Last for this step, you can optionally change the group name that is set to `{{device_id}}` by -default. The group name is used to group one or more data values that is received from a device and -sent to AdafruitIO in a single message. This name is used as the default because it is guaranteed to -be unique for every Helium device. You can use any of the the available template tags which are auto -populated when messages are actually sent, which are `{{device_id}}`, `{{device_eui}}`, and -`{{device_name}}`. This integration uses group topics to send device data to AdafruitIO over MQTT, -you can read more about it [here](https://io.adafruit.com/api/docs/mqtt.html#group-topics). - -Next, let's name the integration in step 3. You will use this name to identify the integration when -attaching it to devices. - - - -The very last step is to select the decoder that will be used to decode the data payload received -from your device. We suggest using the _CayenneLPP_ decoder as shown below and encoding your data -with CayenneLPP as this will be a seamless experience and not require any further configuration on -Console. You can learn more about CayenneLPP encoding -[here ](https://developers.mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload)as well -as find an Arduino library for it [here](https://www.arduino.cc/reference/en/libraries/cayennelpp/). -If you are comfortable with writing your own decoder and template then simply select _Custom_ and -then search for your function decoder. Last be sure to click _Create Integration_ to finish. - - - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). diff --git a/docs/use-the-network/console/integrations/akenza.mdx b/docs/use-the-network/console/integrations/akenza.mdx deleted file mode 100644 index 6b8ee03a8..000000000 --- a/docs/use-the-network/console/integrations/akenza.mdx +++ /dev/null @@ -1,134 +0,0 @@ ---- -id: akenza -title: Akenza -pagination_label: Akenza -sidebar_label: Akenza -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/akenza ---- - -# Akenza - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Akenza](https://www.akenza.io/) is an IoT application enablement platform, allowing you to build -great IoT products and services with value. It connects, controls, and manages IoT devices; all in -one place. You can sign up for a free account at -[https://auth.akenza.io/register](https://auth.akenza.io/register). - -## Create Integration in Console - -To add the integration in Console, go to **Integrations** on the left-hand menu. Select the -integration to add - in this case, the **Akenza** integration as shown below. - - - -Next you will need to navgigate to your Akenza portal in another browser window in order to obtain -the Akenza uplink secret. - -In the Akenza user portal, navigate to the **Data Flows** section as shown below and click Create -Data Flow in the top right. - - - -Next, select **HTTP** for connectivity. - - - -Next, name the device connector and select Helium for the decoding type. Lastly, save the connector. - - - -Next, for simplicity we will pick the **Passthrough** device type and the E-Mail connector to -complete the data flow. Finally, click **Save Data Flow**. This Data Flow will send an email every -time the device transmits an uplink. - - - -To complete the integration creation on Console, copy the **Uplink Secret** as shown below. - - - -Next, navigate back to your Console browser window, paste it in the **Uplink Secret** field for -step 2. Lastly, name the integration and click **Add Integration** - - - -## Create Device in Akenza - -Before we connect the Akenza integration to our device in Console, we first need to make Akenza -aware of it. - -To do this, navigate back to your Akenza user portal window and create a new device by going to the -**Asset Inventory** section and clicking **Create Device** in the top right as shown below. - - - -Next fill in details such as the name and description. At the very bottom, we can establish the -connection between this new device and the Data Flow we created above with the new device. - - - -After filling in those details click Next. The final step to creating the new device is to enter the -Device EUI of the device from Console. **Important**, this is not the ID on the Console device page, -but the Device EUI as shown below. Copy the Device EUI on the Console device page as shown below. - - - -Paste it in the Device ID field on Akenza, then finish by clicking **Create Device**. - - - -This completes the steps required for setup on Akenza, but now we must connect our device to the -Akenza Integration on Console, follow the steps below. - -## Connect Akenza Integration to Device - -The final step to completing the Akenza integration with a device is to create a flow connection. -Navigate to the Flows page on Console, add the device and integration nodes, and finally connect -both of them as shown below. - - - -Your device data should now be flowing to Akenza once your device transmits an uplink. diff --git a/docs/use-the-network/console/integrations/aws-iot-core.mdx b/docs/use-the-network/console/integrations/aws-iot-core.mdx deleted file mode 100644 index 0a45f1f3c..000000000 --- a/docs/use-the-network/console/integrations/aws-iot-core.mdx +++ /dev/null @@ -1,256 +0,0 @@ ---- -id: aws-iot-core -title: AWS IoT Core -pagination_label: AWS IoT Core -sidebar_label: AWS IoT Core -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/aws-iot-core ---- - -# AWS IoT Core - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[AWS IoT Core](https://aws.amazon.com/iot-core/) is a powerful offering that lets developers build -device-based applications and services on the AWS Cloud. And this Integration via Helium Console -automates the complexity of securely connecting your devices to AWS IoT Core. - -### Add an AWS IoT Core Integration - -To add an **AWS IoT Core Integration**, go to **Integrations** on the left-hand menu. Select the -integration to add - in this case, the **AWS IoT Core** integration: - - - -The next step is to create a new user with limited permissions that this Integration will use. - -Open up the [AWS Console](https://console.aws.amazon.com/) - -Under the Services menu in the upper-left, go to **Security, Identity, & Compliance**->**IAM**: - - - -We are now going to create a new **User:** - - - -Set the user name to "**HeliumIntegrationAccess**" and select only "**Programmatic access**" - - - -We now attach a policy to the newly created user that defines what permissions they hold. - -Select "**Attach existing policies directly**" and type "**AWSIoTConfigAccess"** into the "**Filter -Policies**" box and check the box to the left of the row: - - - - - -:::warning - -Ensure you record and store these keys securely, as you will not have an opportunity to get access -to them again! - -::: - -Back in the **Helium Console**, enter the credentials we just created under **AWS Connection -Details,** as well as the AWS region that you would like AWS IoT to run in. - - - -The **Topic** field is the AWS IoT MQTT topic that this integration will publish uplink messages to, -from devices. - -Finally, we give our new Integration a name and click **Create Integration**. Your new Integration -is now ready for use. - -### Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). - -## AWS IoT MQTT Topic composition: - -### Device Uplink \(Receive Data from Device\) - -This topic is defined in the **Topic** field when creating the AWS IoT intgeration. - -**Subscribe to:** `{custom_topic}` - -### Device Downlink \(Send Data to Device\) - -**Publish to:** `helium/devices/{Device ID}/down` - -Example: `helium/devices/4f10d99a-e22e-4007-a3f0-6af3bc63acfe/down` - -## AWS IoT MQTT Messages - -To send data to a device, use JSON with a `payload_raw` field with a base64 encoded string. - -**Sending Data to Device \(Downlink\):** - -```javascript -{ - "payload_raw": "encoded_string" -} -``` - -When receiving data from a device, the messages will be in JSON and look like the following. The -data from the device is in the `payload` field, and is a base64 encoded string. - -**Receiving data from Device \(Uplink\):** - -```javascript -{ - "app_eui": "06B02F1A0E482128", - "dev_eui": "5F67F99E10B47006", - "devaddr": "1A2FB006", - "fcnt": 10, - "hotspots": [ - { - "frequency": 911.9000244140625, - "id": "112ErPy4pa8bRBQj9XgtRrHdk4i4ciTzB5gHwBbFupgNnwaGdExi", - "name": "mammoth-tartan-tortoise", - "reported_at": 1586466818, - "rssi": -57, - "snr": 12.5, - "spreading": "SF9BW125", - "status": "success" - }, - { - "frequency": 911.9000244140625, - "id": "112kFNJoxBYn7UWwZqUABrTXjhn7mkP8ePrbi6w9Hj1NXJfodwP3", - "name": "howling-gauze-guppy", - "reported_at": 1586466818, - "rssi": -91, - "snr": 13, - "spreading": "SF9BW125", - "status": "success" - } - ], - "id": "4f10d99a-e22e-4007-a3f0-6af3bc63acfe", - "metadata": { - "labels": [ - { - "id": "0ec71594-de64-4794-acd7-9ace0b7137a3", - "name": "aws-iot-integration-label", - "organization_id": "0c3fbfb6-f8ed-4dbe-af7c-1a86bf372764" - } - ] - }, - "name": "Sparkfun Pro RF", - "payload": "AWcA8AJodANzJ18Ecc04B9CYMAWGyVCIuDaw", - "port": 1, - "reported_at": 1586466818 -} -``` - -### Viewing Integration in AWS IoT Core - -Once our devices have been connected on the Flows Worskpace to our new Integration, let's return to -the [AWS Console](https://console.aws.amazon.com/), and go to **IoT Core** under the **Services** -menu: - - - -Here you are able to monitor the connections to AWS: - - - -When data comes in from the Helium Network Integration, Things will be automatically created within -AWS IoT Core: - - - -Going to **Interact** on the left while on a **Thing** takes us to a list of topics for interacting -with the **Thing Shadows**: - - - - - -To monitor in real-time what is being sent to AWS from Helium, we can open the **MQTT monitor**, and -subscribe to a topic with "\#" wildcard \(to catch all messages, or use the topic we set in **Helium -Console** if just wanting to monitor those\). - - - - - -The payload field is the actual data received from the device, -[encoded in a base64](https://www.base64decode.org/) string. - -### Integration Details - -View the details of your integration by clicking on the Integration name. - -**Integration Details** shows the integration ID that is unique to each integration, the name, the -type of integration, and whether it is active or not. - -**Devices Piped** lists all the devices that are currently sending their data to the selected -integration. - -**Update your AWS Connection Details** allows you to update your AWS connection details for the -currently viewed integration. - -### diff --git a/docs/use-the-network/console/integrations/azure.mdx b/docs/use-the-network/console/integrations/azure.mdx deleted file mode 100644 index 109ba4462..000000000 --- a/docs/use-the-network/console/integrations/azure.mdx +++ /dev/null @@ -1,147 +0,0 @@ ---- -id: azure -title: Azure IoT Hub -pagination_label: Azure IoT Hub -sidebar_label: Azure IoT Hub -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/azure ---- - -# Azure IoT Hub - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Microsoft Azure IoT Hub](https://azure.microsoft.com/en-us/overview/iot/#overview) enables highly -secure and reliable communication between your Internet of Things (IoT) application and the devices -it manages. - -To help ensure stable device connectivity only use Console to connect to client ids. Other device -monitoring tools in IoT Hub will connect to the device using the same client id which will cause -connectivity instability. - -:::important - -For more information getting started with the Azure IoT Hub integration, check out our Tips & Tricks -video on YouTube [here](https://youtu.be/emJ88cGF-Ew). - -::: - -## On Azure IoT Hub - -Prior to setting up an integration in Console, the following Azure IoT Hub information is required: -`Primary Connection String`. - -The string can be found by clicking Device Explorer on the Azure IoT Hub and then clicking on your -device name. - -Log into your Azure IoT Hub account and on the left hand menu go to "Shared access policies". - -Console requires the following permissions. - -- Registry Read: query Azure for devices in your hub -- Registry Write: create devices in your hub -- Device Connect: send messages through http/mqtt to your azure device - -:::important - -You must create your own policy and ensure it includes the permissions listed above. Although the -`iothubowner` policy includes those by default it's not designed to be used for external -integrations. - -::: - -## On Console - -To add the integration in Console, go to **Integrations** on the left-hand menu. - -Click the **Add** integration button. - - - -Choose the **Azure IoT** integration icon. - - - -Enter the Azure IoT Hub `Primary Connection String` information into the Console. Once the string -has been added the following details will be automatically filled based on the information contained -in the string: - -- `Hub Name` -- `Policy Name` -- `Primary Key` - -Remember the Azure IoT Hub policy must have the following permissions enabled: Registry Read, -Registry Write, and Device Connect. - -## Adding a device - -Every time the Azure IoT Hub integration starts up on Console, it will check if the device exists on -IoT Hub, and if it doesn’t it will create one. - -# Azure IoT Central - -According to Microsoft, "Azure IoT Central is highly secure, scales with your business as it grows, -ensures your investments are repeatable, and integrates with your existing business apps." Read more -about Azure IoT Central [here](https://azure.microsoft.com/en-us/services/iot-central/). - -## On Azure IoT Central - -Prior to setting up an integration in Console, the following Azure IoT Central information is -required: - -- API Key (role app administrator, note this is only shown one time so copy and keep in a safe, - retrievable location) -- ID scope (from Device connection groups) -- App Name (obtained from your Azure IoT Central url `.azureiotcentral.com`) - - - -## On Console - -To add the integration in Console, go to Integrations on the left-hand menu. - -Click the **Add** integration button. - - - -Choose the **Azure IoT Central** integration icon. - - - -Enter the Azure IoT Central information into the Console: - -- API Key -- Scope ID -- App Name - -After providing a name and completing the integration, make sure the device/label is mapped to the -Azure IoT Central Integration on the Flows page. - -More information about Flows [here](/use-the-network/console/flows/). - -:::important - -Decoding of sensor data must occur prior to sending data to Azure IoT Central. More information on -Decoder Functions [here](/use-the-network/console/functions#creating-a-decoder-function). - -::: - -## Adding a device - -Every time the Azure IoT Central integration starts up on Console, it will check if the device -exists on IoT Central, and if it doesn’t it will create one. diff --git a/docs/use-the-network/console/integrations/cargo.mdx b/docs/use-the-network/console/integrations/cargo.mdx deleted file mode 100644 index 5b70eca43..000000000 --- a/docs/use-the-network/console/integrations/cargo.mdx +++ /dev/null @@ -1,134 +0,0 @@ ---- -id: cargo -title: Cargo -pagination_label: Cargo -sidebar_label: Cargo -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/cargo ---- - -# Cargo - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::info - -[Helium Cargo](http://cargo.helium.com/) is an evaluation tool and the data collected is available -to all developers. Please do not share any sensitive information. Use at your own discretion. - -::: - -## Add a Cargo Integration - -To add an integration, go to **Integrations** on the left-hand menu. Select the integration to add - -in this case, the **Cargo** integration. - - - -The next step is to name the integration. - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). - -## Cargo Endpoint - -The Cargo endpoint is where device data is sent if connected with a Label. - -**HTTP Details** - -| key | value | -| :------- | :-------------------------------------- | -| Method | `post` | -| Endpoint | `https://cargo.helium.com/api/payloads` | -| Headers | `{"Content-Type":"application/json"}` | - -## Cargo Payload - -The Cargo payload defines the content and structure of the data payload that must be sent to the -cargo endpoint from a device or separate application. Cargo currently accepts data from either the -`decoded` or the`payload` field. Each field has different requirements described below. - -### Decoded Field - -The `decoded` field is the preferred method for sending data to Cargo. This method requires the use -of a [Function Decoder](/use-the-network/console/functions/) on Console in order to decode the -device payload before sending it to Cargo. The accepted fields are listed below and can be located -at any depth within the `decoded` field. - -| Required JSON Fields | Description | -| :------------------- | :------------------- | -| latitude | Latitude in Degrees | -| longitude | Longitude in Degrees | -| altitude | Altitude in Meters | - -| Optional JSON Fields | Description | -| :------------------- | :-------------- | -| speed | Speed in mph | -| battery | Battery Voltage | - -### Payload Field - -Cargo is also capable of decoding the `payload` field, but is only compatible with a few common -tracking devices. - -#### Compatible Devices: - -- RAK 7200 -- Dragino LGT-92 -- Browan Object Locator -- Digital Matter Oyster & Yabby - -You also have the option of encoding the required data on a development device before transmitting -it as described below. - -**Total Payload:** - -- 12 Bytes without Battery Voltage -- 14 Bytes with Battery Voltage - -**Packed in the following order:** - -- int32_t Latitude in Degrees -- int32_t Longitude in Degrees -- int16_t Elevation in Meters -- int16_t Speed in mph -- uint16_t Battery Voltage \(Optional\) - -### Example: - -```c -if (GPS.hasFix) { - idx = 0; - data = (uint32_t)(GPS.latitudeDegrees * 1E7); - payload[idx++] = data >> 24; - payload[idx++] = data >> 16; - payload[idx++] = data >> 8; - payload[idx++] = data; - data = (uint32_t)(GPS.longitudeDegrees * 1E7); - payload[idx++] = data >> 24; - payload[idx++] = data >> 16; - payload[idx++] = data >> 8; - payload[idx++] = data; - data = (int)(GPS.altitude); - payload[idx++] = data >> 8; - payload[idx++] = data; - data = (int)(GPS.speed); - payload[idx++] = data >> 8; - payload[idx++] = data; -} -``` diff --git a/docs/use-the-network/console/integrations/datacake.mdx b/docs/use-the-network/console/integrations/datacake.mdx deleted file mode 100644 index 1255833b5..000000000 --- a/docs/use-the-network/console/integrations/datacake.mdx +++ /dev/null @@ -1,81 +0,0 @@ ---- -id: datacake -title: Datacake -pagination_label: Datacake -sidebar_label: Datacake -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/datacake ---- - -# Datacake - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Datacake](https://datacake.co) is a multi-purpose, low-code IoT platform that requires no -programming skills and minimal time to create custom IoT applications. You can sign up for a free -account at [https://datacake.co](https://datacake.co). - -To add the integration in Console, go to **Integrations** on the left-hand menu. Select the -integration to add - in this case, the **Datacake** integration as shown below. - - - -To integrate Helium Console with Datacake, you'll need to input your **personal access token** from -Datacake. When you register on the Datacake platform and create a user account, a token is -automatically created. You can view your own token via the User Settings Menu. You can reach this -menu by clicking on "Edit Profile" at the end of the list using the Workspace Selector: - - - -You will now see a menu where you can make your personal account settings. There is also a sidebar -and in this you will find the item "API". If you click on it, you will find your personal access -token there: - - - -Copy this value into the **Enter Datacake Token** field in Console for the integration configuration -shown below. - - - -Set a name for the integration in step 3. You will use this name to identify the integration when -attaching it to devices. Simply calling the integration 'Datacake' is sufficient for most -implementations. - - - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). diff --git a/docs/use-the-network/console/integrations/google-sheets.mdx b/docs/use-the-network/console/integrations/google-sheets.mdx deleted file mode 100644 index 2d20bfab7..000000000 --- a/docs/use-the-network/console/integrations/google-sheets.mdx +++ /dev/null @@ -1,128 +0,0 @@ ---- -id: google-sheets -title: Google Sheets -pagination_label: Google Sheets -sidebar_label: Google Sheets -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/google-sheets ---- - -# Google Sheets - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Creating a Form - -[Google Forms](https://forms.google.com) - -Create a form. - -Make a question for each field you want to capture from your device. We're going to use an -environment sensor for this example. - -We recommend setting questions to "Short Answer". - - - -## Make Form Public - -In the top right, click the settings cog next to the send button. - - - -Make sure the form is publicly accessible. - - - -## Connecting to Google Sheets - -Head over to the responses tab and tell the form you want your results sent to Google Sheets by -clicking the Google Sheets button. - - - -## Get Share Link - -Now go to the **Send** button in the top right corner, and we're going to grab the share link. Do -not shorten the URL. - - - -## Adding the Integration - -Moving over to Console, to add a Google Sheets integration in Console, go to **Integrations** on the -left-hand menu. Select the integration to add - in this case, the **Google Sheets** integration as -shown below. - - - -## Get the Form Fields - -Paste the share link in the **Enter Google Form ID** field. - -We're only after the ID of the form, so we're going to remove the prefix -`https://docs.google.com/forms/d/e/` and suffix `/viewform?usp=sf_link`. We should be left with a -big string that contains no slashes. - -Now we can click the **Get Google Form Fields** button to verify we've done things correctly. - - - -## Create your Decoder - -Click the **Generate Function Body with Fields Above** button and Decoder template will be created -for you to translate your data into how Google Form expects it. - -Take this time to name your integration. - -We can fill out the Function Body now, or save the integration and edit it later under -**Functions**. We're going to fill it out now. - -The data in this example is coming from a -[Wisblock](/use-the-network/devices/development/rakwireless/wisblock-4631/) with an environment -sensor that's included in the -[RAK Helium Devkit](https://store.rakwireless.com/collections/helium/products/helium-developer-kit). -The Decoder function for this environment sensor is pasted into the **Function Body** section and -passed the data from the device so it can get us the fields we need. We then map those to the google -forms fields. - - - -With that done, we can click **Add Integration**. - -## Attach to Device - -Going to **Devices** on the left-hand menu, we can now [add our label](../labels). diff --git a/docs/use-the-network/console/integrations/http.mdx b/docs/use-the-network/console/integrations/http.mdx deleted file mode 100644 index 814aaf365..000000000 --- a/docs/use-the-network/console/integrations/http.mdx +++ /dev/null @@ -1,266 +0,0 @@ ---- -id: http -title: Http -pagination_label: HTTP -sidebar_label: HTTP -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/http ---- - -# HTTP - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Add an HTTP Integration - -To add a Integration, go to **Integrations** on the left-hand menu. Select the integration to add - -in this case, the **HTTP** integration. - - - -The next step is to paste the HTTP endpoint. - -If you're still testing, you can find popular sites that can create HTTP endpoints for you and -inspect packets. [Requestbin](https://requestbin.com) and [Beeceptor](https://www.beeceptor.com) -provide tools to make an HTTP endpoint quickly and easily. - -### Uplink \(Receive Data from Device\) - -Uplinking refers to your device sending data to be received by the network. For the HTTP -integration, this will be the data from the device that is sent to your HTTP endpoint of choice. - -### RequestBin Example - -Create an endpoint by going to [requestbin.com](https://requestbin.com/) and click **Create a Request Bin**. Once created, copy -the endpoint. - - - -... and paste it in Console's **Endpoint URL** field. - - - -**HTTP Header** and **Value** are not required, and can be left blank. - -Lastly, provide a name for the integration. Names do not have to be unique. - -Click **Add Integration**. - -Your new integration is now ready for use! Please read about the [JSON Schema](/use-the-network/console/integrations/json-schema) to understand how to -parse data received. - -### Integration Details - -View the details of your integration by clicking on the Integration name. - -**Integration Details** shows the integration ID that is unique to each integration, the name, the -type of integration, and whether it is active or not. - -**HTTP Details** shows the specific endpoint which can be changed. - -**Devices Piped** lists all the devices that are currently sending their data to the selected -integration. - -**Update your Connection Details** allows you to update your HTTP connection details for the -currently viewed integration. - -## Downlink \(Send Data to Device\) - -Downlink refers to the network sending data down to be received by your device. With regards to the -HTTP integration, this will be data sent to a unique URL called the `downlink_url` provided by -Console. - -#### Downlink URL Format - -`https://console.helium.com/api/v1/down/{Integration_ID}/{Downlink_Key}/{:optional_device_id}` - -You can send downlinks to every device that your HTTP integration is attached to or just a single -device by including the device UUID at the end. You can find this `downlink_url` with the required -downlink key in it on the HTTP integration page in the details section, an example is shown below. - - - -The downlink URL can also be found in the uplink JSON message for that particular device. It will -look similar to the URL shown below. You can also find it using the Debug window on your device -page. - -#### Downlink URL Example \(Sends to all Devices with Integration Attached\) - -```text -"downlink_url": "https://console.helium.com/api/v1/down/897780bc-6980-42c1-a659-30077e8dbcd1/h4IxFDle6biV1ZKmrUJamaXhKjRRF3c-" -``` - -#### Downlink URL Example \(Device Specific\) - -```text -"downlink_url": "https://console.helium.com/api/v1/down/897780bc-6980-42c1-a659-30077e8dbcd1/h4IxFDle6biV1ZKmrUJamaXhKjRRF3c-/d2c7b8dc-221a-4ec8-aedd-6c19ae348a33" -``` - -To send the downlink message, make a POST request including a JSON body with the following fields -shown below, see more details on the fields -[here](/use-the-network/console/integrations/json-schema#downlink-transmitting-data-to-a-device). - -#### Downlink JSON Message Example - -```text -{ - "payload_raw": "SGVsbG8sIHdvcmxkIQ==", - "port": 1, - "confirmed": false -} -``` - -### Downlink Tool Example - -The easiest way to send a downlink to your device is to use the built-in downlink tool in Console. -You will find it on the right side of every device page, as shown below. In order to use the -downlink tool, you must have an HTTP Integration attached to the device. - - - -Once you have the downlink tool open, input the downlink payload string in the payload -field. Select _Encoded_ if you are inputting a string that is already Base64 encoded, and _Plain_ if -it is plain text. Last, select your FPort, whether or not you want to send a confirmed downlink, and -then click the downlink send button, as shown below. - - - -Once you have initiated the downlink, you should see the downlink event show in the event log, as -shown below. - - - -### Postman Example - -Postman is a popular developer utility for HTTP based services, you can download it -[here](https://www.postman.com/downloads/). We can use this utility to easily make a POST request to -the downlink URL with our downlink JSON message. Follow the steps below to successfully send your -downlink message to your device. - -1. Select the type of HTTP request, POST in this case. -2. Enter the downlink URL here. -3. Select Body to begin entering your message details. -4. Select `raw` as your body type. -5. Select `JSON` as the body format. -6. Enter your JSON message with the required fields. -7. Finally, press `Send` to transmit the message. -8. You should see a response of `Downlink scheduled` if successful. - - - -### Python Example - -Python is a popular programming language. The following code generates a request to the Helium -Network to downlink data to a device. - -```python -import requests -import base64 - -# copy the Device ID from the Device page in the Helium Console -device_id = '...' - -# copy the Downlink URL from the Helium Console (HTTP Integration), replacing "{:optional_device_id}" with "+ device_id" -url = f'https://console.helium.com/api/v1/down/a0a0a0a0-10a0-1018-a0a0-a0a0a0a0a0a0/asdfasdfasdf_asdfasdfasdfasdf/' + device_id - -payload_str = 'TEST' -payload_b64 = base64.b64encode(payload_str.encode('utf-8')).decode('ascii') - -print(f"Payload (base64): {payload_b64}") - -data = { - "payload_raw": payload_b64, - "port": 1, - "confirmed": True, -} - -r = requests.post(url, json=data) - -print(f"HTTP Response: {r}. Text: {r.text}") - -# data appears as hex on receiver-side (on many units) -import binascii -print(f"Received client-side hex: {binascii.hexlify(payload_str.encode('utf-8')).decode('ascii').upper()}") - -``` - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -[Flows Workspace](/use-the-network/console/flows). - -## Advanced - JSON Message Template - -:::important - -This is an optional, advanced feature and should only be used by users familiar with logic-less -templates. - -::: - -Users can customize the JSON Message structure sent to Integrations (i.e., to the HTTP endpoint, -from the Helium Console). This feature includes the ability to write -custom JSON Messages, decoder functions, and use supplied predefined JSON templates for Cayenne and Browan. - -### Decoding base64 payloads - -Users can send decoded base64 payloads (to hex or bytes) from device to desired integration, without -creating a [decoder function](/use-the-network/console/functions) for brevity. - -To decode the base64 payload simply use `base64_to_hex()` or `base64_to_bytes()` in your integration -JSON like the following (other keys are optional): - -``` -{ - "payload": "{{base64_to_hex(payload)}}", - "name": "{{name}}", - "app_eui": "{{app_eui}}", - "dev_eui": "{{dev_eui}}", - "devaddr": "{{devaddr}}", - "fcnt": "{{fcnt}}", - "port": "{{port}}", -} -``` - -``` -{ - "payload": "{{base64_to_bytes(payload)}}", - "name": "{{name}}", - "app_eui": "{{app_eui}}", - "dev_eui": "{{dev_eui}}", - "devaddr": "{{devaddr}}", - "fcnt": "{{fcnt}}", - "port": "{{port}}", -} -``` diff --git a/docs/use-the-network/console/integrations/integrations.mdx b/docs/use-the-network/console/integrations/integrations.mdx deleted file mode 100644 index e095a9c40..000000000 --- a/docs/use-the-network/console/integrations/integrations.mdx +++ /dev/null @@ -1,91 +0,0 @@ ---- -id: integrations -title: Integrations -pagination_label: Integrations -sidebar_label: Integrations -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations ---- - -# Integrations - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Integrations enable devices to connect to pre-configured, cloud-based applications or send data -directly over HTTP or MQTT. - -Community Integrations have been submitted to the Console Marketplace, approved by the Helium -Foundation and chosen by the Console Hosting Provider. - -To learn more about the Console Marketplace and submitting an Integration, go -[here](/use-the-network/console-marketplace). - -If an Integration is not available please contact your provider. By default, the Helium Foundation -Console will enable all approved Integrations. - -:::important - -Pre-Marketplace Integrations will continue to work as expected. However, devices or groups will need -to connect to a new Community Integration to benefit from future updates provided by the Marketplace -Integration developer. - -::: - -For a video walkthrough of how to use Integrations, check out our Tips and Tricks video -[here](https://youtu.be/lnERw1f7TGE). - -## Add Integration - -To add a new integration, navigate to the **Integrations** page using the left side navigation, -click the Add New Integration **+** and then select from the available integrations. Follow the -specific integration guides below for more details. - - - -A number indicates that an Integration has been added. - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). - -- [JSON Schema](/use-the-network/console/integrations/json-schema) - -- [HTTP](/use-the-network/console/integrations/http) - -- [MQTT](/use-the-network/console/integrations/mqtt) - -- [Microsoft Azure IoT Hub/Central](/use-the-network/console/integrations/azure) - -- [AWS IoT Core](/use-the-network/console/integrations/aws-iot-core) - -- [Cargo](/use-the-network/console/integrations/cargo) - -- [Datacake](/use-the-network/console/integrations/datacake) - -- [MyDevices Cayenne](/use-the-network/console/integrations/mydevices-cayenne) - -- [Adafruit IO](/use-the-network/console/integrations/adafruitio) - -- [Ubidots](/use-the-network/console/integrations/ubidots) - -- [Tago.IO](/use-the-network/console/integrations/tago) - -- [Google Sheets](/use-the-network/console/integrations/google-sheets) - -- [Microshare](/use-the-network/console/integrations/microshare) - -- [Akenza](/use-the-network/console/integrations/akenza) diff --git a/docs/use-the-network/console/integrations/json-schema.mdx b/docs/use-the-network/console/integrations/json-schema.mdx deleted file mode 100644 index fcd47d26b..000000000 --- a/docs/use-the-network/console/integrations/json-schema.mdx +++ /dev/null @@ -1,125 +0,0 @@ ---- -id: json-schema -title: JSON Schema -pagination_label: JSON Schema -sidebar_label: JSON Schema -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/json-schema ---- - -# JSON Schema - -import useBaseUrl from '@docusaurus/useBaseUrl' - -When receiving or transmitting data with an integration, there is a consistent JSON Schema for the -data. - -## Uplink: Receiving Data from a Device - -Here is an example of data received: - -```text -{ - "app_eui": "6948A4B59F4666AD", - "dev_eui": "1C29FBD1D2084E21", - "devaddr": "B5A44869", - "fcnt": 19, - "hotspots": [ - { - "frequency": 912.2999877929688, - "id": "11KHJW1ePkfhLYptMwKyDzn4opLc62daahbi35uxhH3wwi7p6xr", - "name": "icy-fiery-hippo", - "reported_at": 15868685461234, - "rssi": -54, - "snr": 9.800000190734863, - "spreading": "SF9BW125", - "status": "success" - }, - { - "frequency": 912.2999877929688, - "id": "11ni2CACdVUAshDvXif2pYUduAsvoawoxvVub6aqgHjSNsPEapZ", - "name": "cool-chiffon-hornet", - "reported_at": 15868685461235, - "rssi": -51, - "snr": 9, - "spreading": "SF9BW125", - "status": "success" - } - ], - "id": "7c523974-4ce7-4a92-948b-55171a6e4d77", - "metadata": { - "labels": [ - { - "id": "7d11aef4-4daf-4caf-b72a-f789b191ebe4", - "name": "DontLabelMe", - "organization_id": "d724b93a-895a-4175-9852-8738ae31050b" - } - ] - }, - "name": "Test Me", - "payload": "SGVsbG8sIHdvcmxkIQ==", - "port": 1, - "reported_at": 15868685461234 -} -``` - -### Root - -| Field | Type | Description | -| :--------------- | :-------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **app_eui** | String | LoRaWAN 64-bit Application Identifier \(AppEUI\) in MSB hex; conventionally this is used to identify a type of sensor or actuator, e.g. "temperature sensor" or "valve controller" | -| **dev_eui** | String | LoRaWAN 64-bit Device Identifier \(DevEUI\) in MSB hex; conventionally this is used to identify a unique device within a specific application \(AppEUI\) or even within an entire organization | -| **devaddr** | String | Upon a successful Join, the device is allocated a LoRaWAN 64-bit DevAddr which is unique across the entire Helium Network as long the session is active; the data is represented here in MSB hex | -| **fcnt** | Number | LoRaWAN FCnt for uplink packets; this increments with every uplink packet and can be useful for surmising whether an uplink was missed | -| **hotspots** | Array\(hotspot\) | Array of hotspots which received the same packet \(schema description in a following table\) | -| **id** | String | UUID used to identify the device within Helium Console; this is assigned during device creation and maps to a unique set of AppEui, DevEui, and AppKey | -| **metadata** | Object\("label": Array\(label\)\) | A nested JSON object with a single field, "labels", which is an array of label Objects, described in the next table | -| **name** | String | Name assigned to the device by Console user | -| **payload** | String | Data transmitted by your device as a base64 encoded String. Most computer languages will have some built-in libraries for parsing this \(e.g. base64.decode\(payload\)\) | -| **payload_size** | Number | Size of the payload in bytes; you can use this to verify your libraries parsing output | -| **port** | Number | LoRaWAN FPort on which the data was transmitted; this can be useful for routing data within the application | -| **reported_at** | Number | Timestamp in milliseconds | - -### Hotspot - -| Field | Type | Description | -| :-------------- | :----- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **frequency** | Number | In MHz, the frequency which the packet was received upon | -| **id** | String | A base58 encoding of the hotspot's public key; this may serve as a concise unique identifier | -| **name** | String | A human-friendly three-word encoding of the hotspot's public key; link to [JavaScript](https://github.com/helium/angry-purple-tiger) and [Erlang](https://github.com/helium/erl_angry_purple_tiger) implementations | -| **reported_at** | Number | Timestamp in milliseconds | -| **rssi** | Number | Received Signal Strength Indicator is reported by the hotspot and indicates how strong the signal device's radio signal was; the larger the number \(closer to 0\), the better the signal | -| **snr** | Number | In dB, Signal to Noise Ratio is reported by the hotspot to indicate how clear the signal was relative to environmental noise; this generally ranges between -20 and +10 and the larger the number \(closer to 10 dB\) the better | -| **spreading** | String | LoRa Spreading Factor and Bandwidth used for the radio transmission. In the US, spreading factor ranges from 7 to 10 and bandwidth is always 125 kHz. For example, "SF7BW125" means a Spreading Factor of 7 was used and a channel width of 125 kHz. | - -### Metadata - -| Field | Type | Description | -| :--------- | :----- | :-------------------------------------- | -| **labels** | String | A list of Labels attached to the device | - -## Downlink: Transmitting Data to a Device - -Here is an example of data received: - -```text -{ - "payload_raw": "SGVsbG8sIHdvcmxkIQ==", - "port": 1, - "confirmed": false -} -``` - -| Field | Description | | -| :-------------- | :---------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **payload_raw** | String | Data transmitted to your device as a base64 encoded String. Most programming languages will have some built-in libraries for parsing/encoding this \(e.g., Python's `payload = base64.b64encode(payload_str.encode('utf-8')).decode('ascii')`\) | -| **port** | Number | LoRaWAN FPort on which the data is to be transmitted; this can be useful for routing data within the application | -| **confirmed** | Bool | Whether a device acknowledgement (ACK) is required | - -Note that many devices will show the downlinked payload (submitted as base64 in the JSON schema) as hex (base-16). - -### Clearing a Device Queue - -If the **payload_raw** field is set to the base64 encoded value -`'__clear_downlink_queue__'`, all downlinks queued for that device will be removed. diff --git a/docs/use-the-network/console/integrations/microshare.mdx b/docs/use-the-network/console/integrations/microshare.mdx deleted file mode 100644 index e60be0a3f..000000000 --- a/docs/use-the-network/console/integrations/microshare.mdx +++ /dev/null @@ -1,79 +0,0 @@ ---- -id: microshare -title: Microshare -pagination_label: Microshare -sidebar_label: Microshare -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/microshare ---- - -# Microshare - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Microshare](https://www.microshare.io/) is a data leverage platform for the IoT era, providing a -solution to sharing, privacy, security, audit, confidentiality, data monetization and cost savings. -You can sign up for a free account at [https://www.microshare.io/](https://www.microshare.io/). - -To add the integration in Console, go to **Integrations** on the left-hand menu. Select the -integration to add - in this case, the **Microshare** integration as shown below. - - - -Now we need to go over to the **Microshare** console and get our Pipe Token. - -In the **_Microshare_** console, click on "Keys" at the bottom-left, then "Create New App" in the -upper-right. - - - -Now, we give it a name - in this case, we simply call it "Helium Console" and click "Create App". - - - -Click on the "Generate a Token" button, select "Pipe Token" and click the "Create Token" button. - - - - - -Now that the token is generated, let's copy it so that we can enter it into the Helium Console. -Select the "Tokens" tab at the top of the screen, then click the Token itself to copy it to your -clipboard. - - - -Finally, let's paste in the token from **Microshare** in step 2 and name the integration in step 3. -You will use this name to identify the integration when attaching it to devices. - - - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). diff --git a/docs/use-the-network/console/integrations/mqtt.mdx b/docs/use-the-network/console/integrations/mqtt.mdx deleted file mode 100644 index 848b58cfe..000000000 --- a/docs/use-the-network/console/integrations/mqtt.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -id: mqtt -title: MQTT -pagination_label: MQTT -sidebar_label: MQTT -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/mqtt ---- - -# MQTT - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Add an MQTT Integration - -To add an integration, go to **Integrations** on the left-hand menu. Select the integration to add - -in this case, the **MQTT** integration. - - - -The next step is to paste your MQTT broker endpoint, and optional topic prefix. - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). - -## MQTT Topic composition: - -### Device Uplink \(Receive Data from Device\) - -**Subscribe to:** `{optional_prefix}/helium/{Device ID}/rx` - -Example with prefix: `mqtt/helium/3c822699-37fd-4df6-a84d-93037a450843/rx` Example without prefix: -`helium/3c822699-37fd-4df6-a84d-93037a450843/rx` - -### Device Downlink \(Send Data to Device\) - -**Publish to:** `{optional_prefix}/helium/{Device ID}/tx` - -Example with prefix: `mqtt/helium/3c822699-37fd-4df6-a84d-93037a450843/tx` Example without prefix: -`helium/3c822699-37fd-4df6-a84d-93037a450843/tx` - -## MQTT Messages - -The MQTT for downlink and uplink follow the -[JSON schema documented here.](/use-the-network/console/integrations/json-schema) - -## Send and Receive Device Data - -The following examples are done with the [MQTT CLI](https://hivemq.github.io/mqtt-cli) utility. - -Example MQTT - -**Subscribe to Uplink Packets:** - -```text -mqtt sub -V 3 -t helium/3c822699-37fd-4df6-a84d-93037a450843/rx -h {mqtt_broker_host} -p {mqtt_broker_host_port} -u "user" -pw "password" -``` - -**Publish Downlink Packet:** - -```text -mqtt pub -V 3 -t helium/3c822699-37fd-4df6-a84d-93037a450843/tx -h {mqtt_broker_host} -p {mqtt_broker_host_port} -u "user" -pw "password" -m "{\"payload_raw\":\"encoded_string\"}" -``` diff --git a/docs/use-the-network/console/integrations/mydevices-cayenne.mdx b/docs/use-the-network/console/integrations/mydevices-cayenne.mdx deleted file mode 100644 index 27ce528b0..000000000 --- a/docs/use-the-network/console/integrations/mydevices-cayenne.mdx +++ /dev/null @@ -1,143 +0,0 @@ ---- -id: mydevices-cayenne -title: MyDevices Cayenne -pagination_label: MyDevices Cayenne -sidebar_label: MyDevices Cayenne -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/mydevices-cayenne ---- - -# MyDevices Cayenne - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Cayenne](https://developers.mydevices.com/cayenne/features/) from -[myDevices](https://mydevices.com/), is a free, drag and drop IoT project builder, that empowers -developers, designers and engineers to quickly prototype and share their connected device projects. -Cayenne was designed to help users create Internet of Things prototypes and then bring them to -production. It supports -[hundreds of devices](https://developers.mydevices.com/cayenne/supported-hardware/), including -everything from popular development boards to professional grade remote sensors. Cayenne offers both -a web and mobile based application. - - - -### Add a myDevices Cayenne Integration - -To add a **myDevices Cayenne** Integration, go to Integrations on the left-hand menu. Select the -integration to add, in this case, the **myDevices Cayenne** integration: - - - -The next step is to name the integration - -:::info **Downlink Not Yet Supported** - -The MyDevices integration currently only supports uplinks. Downlinks are in the process of being -implemented and will be available soon. - -::: - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). - -### Adding Your Device on myDevices Cayenne - -Before adding your device to Cayenne, be sure you've successfully added it to the Helium network as -well as connected it the myDevices Cayenne integration. If you haven't done so yet, start -[here](../adding-devices). Once you have a device added on Console and you have verified that -packets are being received, you can then proceed to add the device on Cayenne. - -First, signup for Cayenne [here](https://developers.mydevices.com/cayenne/signup/), if you have not -already. - -From the Cayenne dashboard, click **Add New** > **Device / Widget**. - - - -From the list of devices & widgets that appears, click **LoRa** and select the **Helium** Network -option to view a list of Helium supported devices. - -:::warning **Ensure you have selected the Helium Network** - -You must select the Helium Network **before** searching for your device, else you may add your -device on the wrong network and will not receive data. - -::: - - - -Here we've selected the popular -[STM32 B-L072Z-LRWAN1 ](https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html)LoRaWAN -development board. - - - -The only information you'll need once you've selected your device is to enter the **DevEUI**, which -is found on your device details page on Console, shown below. - - - -### Downlinks - -Your device first needs to report an Actuator, either Digital or Analog one. You can check LPP doc -here -[https://developers.mydevices.com/cayenne/docs/lora/\#lora-cayenne-low-power-payload-overview](https://developers.mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload-overview) - -Once the device starts reporting DigitalActuator or AnalogActuator, you will automatically get a -button or a slider on Cayenne UI. Using that new control will then trigger downlink commands. - -Please note that both Actuators types inherit from AnalogSensor DataType, e.g. using 2-byte integers -with 0.01 precision. This means a Digital Actuator set to HIGH from the UI will trigger a Downlink -with the value = 0x0064 = 100. - -### Device Data Payload Format - -When adding your device on Cayenne, you'll need to pay close attention to whether or not the device -requires the Cayenne Low Power Payload \(CayenneLPP\). If your device is in the list of supported -devices, it will specify whether or not it requires CayenneLPP directly above the name field when -you've selected the device, and shown in the Cayenne dashboard image above. If you do not see the -line 'This device uses Cayenne LPP', then it is automatically supported by Cayenne. You can find the -official documentation on CayenneLPP -[here](https://developers.mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload), as well -as a popular Arduino library [here](https://github.com/ElectronicCats/CayenneLPP). If you have a -custom device or it is not in the list of supported devices, then select the -[STM32 B-L072Z-LRWAN1](https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html) board as a -placeholder, and be sure to use CayenneLPP formatting in your firmware. diff --git a/docs/use-the-network/console/integrations/tago.mdx b/docs/use-the-network/console/integrations/tago.mdx deleted file mode 100644 index 22681c893..000000000 --- a/docs/use-the-network/console/integrations/tago.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -id: tago -title: Tago.IO -pagination_label: Tago.IO -sidebar_label: Tago.IO -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/tago ---- - -# Tago.IO - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Tago.IO](https://tago.io/) combines advanced device management, services, data storage, -visualization, and analytics with an easy to implement cloud-based IoT platform. - -You can sign up for a free account at [https://tago.io](https://tago.io/). - -To get started, log in to your Tago.IO account and click **Devices** from the menu on the left: - - - -Generate a new **Authorization Token** by entering any name on the **Token name** field and click -the **Generate token** button. - - - -Now we simply copy the **Authorization Token** by clicking on the **Copy** icon: - - - -At this point, we move back over to the Helium Console to complete the Integration. - -Click on **Integrations** on the menu on the left and select the **Tago.IO** Prebuilt Integration: - - - -Paste the **Tago.IO Authorization Token** that we copied from the Tago.IO site above and enter a -name for our Integration: - - - -Click **Add Integration**. You should now see a verification message that the Integration was -created successfully: - - - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). diff --git a/docs/use-the-network/console/integrations/ubidots.mdx b/docs/use-the-network/console/integrations/ubidots.mdx deleted file mode 100644 index 06c8171f6..000000000 --- a/docs/use-the-network/console/integrations/ubidots.mdx +++ /dev/null @@ -1,211 +0,0 @@ ---- -id: ubidots -title: Ubidots -pagination_label: Ubidots -sidebar_label: Ubidots -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/integrations/ubidots ---- - -# Ubidots - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Ubidots](https://ubidots.com/) allows you to rapidly assemble and launch Internet of Things (IoT) -applications without having to write code or hire a software development team. You can sign up for a -free account at [https://ubidots.com](https://ubidots.com/). - -:::tip - -Additional information can be found on the Ubidots user guide to -[Connect Helium with Ubidots](https://help.ubidots.com/en/articles/5008195-plugins-connect-helium-with-ubidots) - -::: - -To get started, log in to your Ubidots account and select **Plugins** from the **Devices** dropdown -menu at the top of your screen: - - - -Click the **Create Data Plugin** button: - - - -Select **Helium**: - - - -Click the **>** (forward) button: - - - -Under **Ubidots Token**, select the **Token** you wish to associate with this integration (we will -just use **Default token**) and make sure **Device tags** is selected under **Use Helium labels -as**: - - - -Now, simply click the checkbox button: - - - -You should get a confirmation message: - - - -And see your new Data Plugin being configured: - - - -Now, click your avatar in the upper-right of your screen and select **API Credentials**: - - - -Click the **Clipboard** button to the right of **Default token** to copy it: - - - -Now, let's move over to the **Helium Console** and create our **Integration**. Select -**Integrations** from the menu on the left of the screen: - - - -And click **Ubidots** under **Add a Prebuilt Integration**: - - - -Now, under **Enter Auth Token**, paste the Ubidots Default token we copied and click the **Get -Webhook URL** button: - - - -You should now get another confirmation message: - - - -And see the **Ubidots Webhook URL**: - - - -Now, we simply name our Integration: - - - -After clicking on the **Add Integration** button, we can review the details: - - - -Notice that currently, no devices are piped through this Integration: - - - -Let's fix that! - -## Connecting Integrations to Devices - -Devices or groups of devices (via labels) can be directly connected to integrations on the Flows -Worskpace. Labels are identifiers used to group devices for easy management. To connect one or more -devices to one or more integrations, simply connect the Device and Integration nodes on the Flows -Workspace. - -:::info - -Quick video tutorial connecting devices to an integration -[here](https://www.youtube.com/watch?v=lnERw1f7TGE). - -::: - -Node elements (devices, labels, integrations) need to be created before they're available on the -Flows Workspace. More information about Flows [here](/use-the-network/console/flows/). - -Click on **Devices** on the menu on the left of your screen. - -And open up a device that we want to send through to Ubidots. - - - -At this point, we should be good to go! We can click on the **Debug** button on the right of the -Device screen and wait for the data to start coming through: - - diff --git a/docs/use-the-network/console/labels.mdx b/docs/use-the-network/console/labels.mdx deleted file mode 100644 index 327d13e7d..000000000 --- a/docs/use-the-network/console/labels.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: labels -title: Labels -pagination_label: Labels -sidebar_label: Labels -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/labels ---- - -# Labels - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Labels are used to group devices for better organization allowing flexibility as your projects scale -and grow. Think of a label as simply a group of devices. - -## Organizing with Labels - -Labels are simply user-defined identifiers that can be attached to one or more devices. Also -multiple labels can be added to a single device so users can choose to identify devices based on -attributes such as geography \(e.g. `SF`\) and device type \(e.g. `temperature` or `humidity`\). - -## Add Labels - -During device creation you can add an existing label or create a new one. - -Alternatively you can create labels beforehand. - -To add a new label, on the Devices page click the Add New Label icon. - -The following screen appears. - - - -## Attaching Labels - -Labels can be attached to devices during or after creation. If you would like to attach a label to a -device during creation, make sure to create the label beforehand, and it will be available to -select. - - - -To attach a label after creating a new device, go to the specific device details page and click the -Add Label button. You can choose an existing label from the dropdown list or create a label. - -To attach a label to a device from the Flows workspace check -[here](/use-the-network/console/flows/actions#add-labels-to-devices). - -## Label Configurations - -Label and device configurations (Alerts, ADR, Packets, CF List) have been updated, go -[here](/use-the-network/console/profiles/) for information about how to configure these settings. diff --git a/docs/use-the-network/console/migrating-devices/migrating-devices.mdx b/docs/use-the-network/console/migrating-devices/migrating-devices.mdx deleted file mode 100644 index a41d7a4f4..000000000 --- a/docs/use-the-network/console/migrating-devices/migrating-devices.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: migrating-devices -title: Migrating Devices -pagination_label: Migrating Devices -sidebar_label: Migrating Devices -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/migrating-devices ---- - -# Migrating Devices to Helium - -If you already have LoRaWAN devices deployed on another network, you can easily migrate them to the -Helium Network. Typically this only involves adding your existing `DevEUI`, `AppEUI`, and `AppKey` -to a new device in the Helium Console. - -The following is a list of network-specific migration guides. Join us! - -### When Migrating Devices for the First Time - -As network usage increases, a mechanism called the XOR filter allows the Console backend (router) to -only process known traffic and avoid spending resources on unfamiliar packets, which significantly -improves performance. - -However, the first time a device joins the network its keys need to be added to the blockchain and -the updated block propagated to the miners (Hotspots). - -This initial join process could take up to 20 mins depending on: - -- when this transaction (batched with others) gets added to the blockchain -- the overall performance of the blockchain - -After the initial join takes place future rejoining of the same device will be much quicker. - -More information about XOR filters [here](/devblog/2021/07/29/console-updates-2.0). - -:::important - -Helium Console users are capped at ONE (1) Organization and 10 devices for their account. - -If your account as of March 31, 2022 exceeds this cap, you can continue using Helium Console with -those existing devices and Orgs for 12 calendar months, but will not be able to add additional -devices and Orgs. - -To continue with more than 1 Org / 10 devices after 12 months, you will need to work with a member -of the ecosystem, host your own instance, or contact a team members at sales@nova-labs.com. - -\*While an account is in an overage state with > 1 Org / 10 devices and a device or Org is deleted, -additional devices or Orgs cannot be re-added. - -Users over the cap who would like to immediately add more devices/Organizations, or users who have -not yet exceeded the cap but plan to do so, can reach out to members of the ecosystem, host their -own instance, or contact sales@nova-labs.com. - -::: - -### Migrating from The Things Network to Helium - -- [Importing TTN Devices with Console Tool](/use-the-network/console/migrating-devices/ttn-import) -- [Manually Migrating Devices from TTN](/use-the-network/console/migrating-devices/ttn-manual) diff --git a/docs/use-the-network/console/migrating-devices/ttn-import.mdx b/docs/use-the-network/console/migrating-devices/ttn-import.mdx deleted file mode 100644 index a06b16ada..000000000 --- a/docs/use-the-network/console/migrating-devices/ttn-import.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -id: ttn-import -title: TTN Import -pagination_label: TTN Import -sidebar_label: TTN Import Migration -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/migrating-devices/ttn-import ---- - -# Import Devices From The Things Network - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Helium Console now supports importing devices from The Things Network directly from the web -interface. - -This guide will walk you through the process of migrating devices from TTN over to Helium. As you'll -see the, process is quite painless. - -## Starting the Import Process - -To get started, open up the [Helium Console](https://console.helium.com/) and switch to the -Organization that you want to import the devices into: - - - -Next, select "Devices" on the left-hand menu and click the Add New Device **+** button. - - - -Click the "Import from the Things Network" button. - -## Retrieving a TTN Access Code - -Next we need to retrieve a code from The Things Network that will allow us to manage devices -programatically. - - - -Go to [https://account.thethingsnetwork.org](https://account.thethingsnetwork.org/) and enter your -TTN Console credentials. - - - -At this point, you should be taken to our account page on the TTN Console. Click the link directly -beneath your avatar, and you will be given a `ttnctl access code` that should be valid for the next -five minutes. - - - -## - - - -Copy this code over to our _Import Devices_ page back on the Helium Console and click the "Start -Importing Devices" button! - - - -## Select the devices to Migrate - -Next, select the devices you want to migrate from The Things Network to the Helium Network. We -encourage you to move them all. - - - - - -As shown in the screenshot above, we include the option to auto-create a -[Helium label ](../labels#organizing-and-connecting-with-labels)based on the TTN Application name. -As you'll see momentarily, his can be very convenient and is recommended. - -We can also delete the devices from The Things Network so that your device will no longer attempt to -join TTN rather than Helium. - - - -Now we simply click the "Import Devices" button, and wait a few seconds as the devices are pulled -over into your Helium Console! - -In the example migrated device below, you can see the attached label that was created from the TTN -Application name. - -:::info - -Once your devices are organized using Labels, you can address them programmatically via the Console -API. - -::: - - - -And you're done. That is all that it takes to migrate devices from The Things Network over to The -People's Network! diff --git a/docs/use-the-network/console/migrating-devices/ttn-manual.mdx b/docs/use-the-network/console/migrating-devices/ttn-manual.mdx deleted file mode 100644 index bb0579355..000000000 --- a/docs/use-the-network/console/migrating-devices/ttn-manual.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -id: ttn-manual -title: TTN Manual -pagination_label: TTN Manual -sidebar_label: TTN Manual Migration -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/migrating-devices/ttn-manual ---- - -# Migrating Devices From The Things Network - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This short guide will walk you through porting your devices to the Helium Network \(and Helium -Console\) from TTN and the TTN Console. If you are doing more than a few devices though, you may -want to try the -[Command-Line Interface for automated import](/use-the-network/console/cli#ttn-import). - -At a high level, there are two steps to accomplish this migration: - -1. Copying your keys from the TTN Console to the Helium Console. \(Right now this is a manual - process, but we'll soon have a CLI that automates this\). -2. Porting your `application`logic from TTN Console to use the far superior `labels` construct in - the Helium Console. - -## Copying Keys and Ensuring you're using Sub Band 2 - -In the [TTN Console](https://console.thethingsnetwork.org/), we go to the -[Application](https://console.thethingsnetwork.org/applications) containing the device we want to -migrate and copy these keys over into a new Device created in -[Helium Console](https://console.helium.com). - - - - - -Next, you need to ensure the device can use LoRaWAN US channels `8-15` \(also known as -`Sub-band 2`\). This process can vary by device. Some come bundled with configuration utilities, -others you will have to recompile and flash the firmware yourself. It is also possible that the -network negotiates the sub-channel band itself. - -The full frequency table for the US915 band is found here but comparison is available below. - -By default, LoRaWAN compliant end nodes should use all channels \(0-63\) for the OTAA join process. -After OTAA Joined, the first uplink packet on sub-band 2 will receive a downlink response with an -ADR command with the appropriate channel mask; thereafter, the end node should use these channels -\(8-15\) to send uplink packets. - -### Comparison \(MHz\): - -| **TTN Frequency** | **Helium Frequency** | **SFBW** | -| :---------------- | :------------------- | :-------------------- | -| 903.9 | **903.9** | SF7BW125 to SF10BW125 | -| 904.1 | **904.1** | SF7BW125 to SF10BW125 | -| 904.3 | **904.3** | SF7BW125 to SF10BW125 | -| 904.5 | **904.5** | SF7BW125 to SF10BW125 | -| 904.7 | **904.7** | SF7BW125 to SF10BW125 | -| 904.9 | **904.9** | SF7BW125 to SF10BW125 | -| 905.1 | **905.1** | SF7BW125 to SF10BW125 | -| 905.3 | **905.3** | SF7BW125 to SF10BW125 | -| 904.6 | **904.6** | SF8BW500 | - -## Porting Your Application Logic to use Helium's Labels Construct - -After you've added your device to the Helium Console, you'll likely need to reconstruct the -[Application](https://www.thethingsnetwork.org/docs/applications/) you've built for your devices in -TTN's Console. - -Instead of an `application`, Helium uses [labels](../labels), and instead of creating your TTN -application first, then adding devices to it, Helium lets you add any number of devices to Console, -then group them by labels after the fact. Devices can also have more than one label. - -To read more about Labels and how you should use them to replace and extend `applications`, head -[here](../labels). diff --git a/docs/use-the-network/console/multi-packets.mdx b/docs/use-the-network/console/multi-packets.mdx deleted file mode 100644 index 86e747fc6..000000000 --- a/docs/use-the-network/console/multi-packets.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -id: multi-packets -title: Packet Configurations -pagination_label: Packet Configurations -sidebar_label: Packet Configurations -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/multi-packets ---- - -# Packets Configurations - -The Multiple Packets menu has been replaced with Packet Configurations. - -Packet Configurations allow users to specify settings that impact packet delivery and includes -settings for both Multiple Packets and Preferred Hotspots. - -:::important - -For a Packet Configurations setting, users can either set a Preferred Hotspot or a Multiple Packet -setting, but not both. - -::: - -## Preferred Hotspots - -With this feature users can designate Hotspots as “Preferred”. If the feature is enabled, packets -will ONLY be accepted by Hotspots chosen as Preferred. In the Coverage section, Hotspots must be -followed first before they can be designated as Preferred. - -After configured, Packet Configurations can be applied on the Flows workspace at a device/label -level on the Packets tab. - -As this feature is designed for troubleshooting Hotspots or initial Hotspot positioning, the default -setting is off. - -:::warning - -This feature is designed for initial Hotspot positioning or troubleshooting. If this feature is -enabled and a preferred Hotspot cannot send packets, then no packet transfer will occur even if -other non-Preferred Hotspots are in range. - -::: - -### How to designate a Preferred Hotspot - -The following steps are required to designed Preferred Hotspots: - -Step 1: On Coverage choose the desired Hotspot. Hotspots must be first followed before they can be -chosen as Preferred. - -Step 2: On Packet Configuration, choose the Preferred Hotspot settings. - -Step 3: On the Flows Workspace, apply the Packet setting to a device or group of devices. - -### Multiple Packets - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Data Credits are only spent for uplinks including initial join packets. The Multiple Packets feature -provides the ability to pay for additional packets for redundancy and location triangulation -purposes. - -:::info - -To learn more about configuring Multiple Packets, check out our Tips and Tricks video -[here](https://youtu.be/xv8aM1oNIEs). - -::: - -### Configuring Multiple Packets - -Configuring multiple packets for a device a group of devices involved two main steps: - -1. Set up the multiple packet configuration. - -- Select **Multiple Packets** on the side menu. - -{" "} - -- Click the Add **+** -icon.{' '} - -{" "} - - - -- Enter a name and choose the desired number of packets. -- Click **Create Multiple Packet Config** - -2. Apply the Multiple Packet configuration to a device or group of devices. - -- On the Flows Workspace, choose a Device/Label node and select the Inspector tab. -- Select **Packets** and choose the configuration to apply. - - diff --git a/docs/use-the-network/console/my-account.mdx b/docs/use-the-network/console/my-account.mdx deleted file mode 100644 index 479aeef5b..000000000 --- a/docs/use-the-network/console/my-account.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: my-account -title: My Account -pagination_label: My Account -sidebar_label: My Account -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/my-account ---- - -# Console Account Settings - -## Console 2FA - -Two Factor Authentication, usually written `2FA`, provides a higher level of security for your -Helium Console account by requiring a separate, one-time use password in addition to your primary -password that's always required. Helium Console features 2FA and we recommend you turn it on. - -To enable it, start by logging in and [heading to your profile](https://console.helium.com/profile). -Click `Enroll in 2FA`. From there, you'll be guided to provision the 2GA application of your -choosing. ([Authy](https://authy.com/), Google Authenticator, [1Password](https://1password.com/), -and [LastPass](https://www.lastpass.com) are a few of the popular apps that make 2FA easy.) - -:::important - -During the 2FA setup process, you'll be provided a backup code. This is what you'll need to regain -access to your account in the event that you lose access to your 2FA application. Do not lose this -backup code. Otherwise you'll be locked out of your account if you lose access to your 2FA -application. - -::: - -## Console API Keys - -To use the [Helium Console API](/api/console), you'll need an API Key. API Keys are organization- -and role-specific. - -To generate an API Key, once logged in, navigate to your -[Console Account Settings](https://console.helium.com/profile). In the **Your API Keys** section, -create a name for your new API Key, select the role for this key (currently only `Admin` is -supported), and click **Generate Key**. You'll then see a pop up with your API Key. This will be the -only time it's revealed to you. - -:::important - -Once Console shows you your API key, it won't be shown to you again. If you lose it, you'll need to -create a new one. - -::: - -After generating the API Key, it will not be active. You'll see it listed in the table as -`Active`:`False`. To activate it, you'll need to confirm activation via the email Console will send -you once the key is created. After confirming, you'll see the status as `Active`:`True`. - -Now that you've generated an API key, put it to use! Head over to the -[Console API docs](/api/console) to get started. diff --git a/docs/use-the-network/console/profiles.mdx b/docs/use-the-network/console/profiles.mdx deleted file mode 100644 index f7cd74a3d..000000000 --- a/docs/use-the-network/console/profiles.mdx +++ /dev/null @@ -1,122 +0,0 @@ ---- -id: profiles -title: Profiles -pagination_label: Profiles -sidebar_label: Configuration Profiles -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/profiles ---- - -# Configuration Profiles - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Configuration Profiles provide users with a streamlined way to configure, save, and apply settings -to a device or group of devices (via labels). - -Unlike other configuration settings, Profiles impact LoRAWAN’s protocol behavior and are binary in -nature. - -:::important - -Configuration Profiles can be added to Device/Label nodes. The last Profile assigned to a device -takes priority. For example, if a device has Profile A, and a label has Profile B, if that label is -applied to the device then Profile B overrides Profile A. - -::: - -Current settings that can be set via Profiles: - -- [ADR](#adr) -- [CF List](#cf-list) -- [Receive Window Delay](#receive-window-delay) - -:::info - -For a video walkthrough of configuring ADR and CF List, check out our Tips and Tricks video -[here](https://youtu.be/xv8aM1oNIEs). - -::: - -## ADR - -Adaptive Data Rate (ADR) is a mechanism for adapting the data rate of devices in a LoRaWAN network. -This allows a device's airtime and power consumption to be optimized by the Network Server. Learn -more about ADR from Semtech's developer portal -[here](https://lora-developers.semtech.com/library/tech-papers-and-guides/understanding-adr/). - -:::warning - -- ADR will only work if your device requests ADR. -- Using ADR is only suggested for devices that are static for long periods of times. ADR is not - suggested for devices that are constantly changing location or have unstable RF conditions. - -::: - -### ADR Algorithm - -The network server behind Console implements a specific algorithm for determining the optimal data -rate and transmit power to send down to the device. ADR not only increases the device's data rate, -but it increases or decreases transmit power as needed. The network only calculates data-rate/power -corrections after it collects 20 contiguous uplink packets with the ADR bit set to `1`. From this -point on, the network may send downlink LinkADRReq MAC commands, either alone or with -already-scheduled downlink packets. The network server clears its ADR history whenever a device -sends an uplink packet with ADR set to `0`. - -## CF List - -The Join-Accept CF List configures channels according to the LoRaWAN spec to use sub-band 2. Devices -that have not correctly implemented the LoRaWAN spec may experience transfer issues when this -setting is enabled. - -- Enabled, the server will send a CF List with every other join. -- Disabled, the server will not send a CF List. The channel mask is still transmitted via ADR - command. - -**Notes:** By default this setting is disabled and only applicable to US915 devices. - -## Receive Window Delay - -This setting allows users to specify the number of seconds the device's first receive window begins -after the transmit ends. - -The range window can be adjusted from 1 (default) to 15 seconds. - -A higher number increases the receive delay window and generally can increase downlink reliability -as higher latencies between the LoRaWAN gateway and network server will be tolerated. - -However, devices that suffer from drift may not work as well and a longer delay reduces the -theoretical maximum rate of communication since a subsequent transmit may only be accomplished after -both receive windows. - -Note: According to the LoRaWAN spec, the second receive window always begins one second after the -first. - -## Creating Profiles - -Profiles need to be created before they can be applied to devices. - -- To create Profiles, on the left-hand menu, click **Profiles** and click the **+** button. -- Choose a descriptive name for the Profile, the desired settings, and click **Create Profile**. - -### Applying Profiles - -User can apply profiles: - -- During setup of devices or labels -- On the Flows workspace or non-Flows areas - - Specific device page - - On the Label page - -On the Flows Worskpace for quick identification of devices with a Profile, a symbol appears on the -node. - -Flows Workspace - -- Choose device or label, and on the side pane click the Profile tab. -- Choose the Profile to apply or create a new one. - -### Editing or Deleting Profiles - -To edit or delete a profile, select it and make changes or click **Delete Profile**. diff --git a/docs/use-the-network/console/quickstart.mdx b/docs/use-the-network/console/quickstart.mdx deleted file mode 100644 index ebb74a800..000000000 --- a/docs/use-the-network/console/quickstart.mdx +++ /dev/null @@ -1,126 +0,0 @@ ---- -id: quickstart -title: Quickstart -pagination_label: Quickstart -sidebar_label: Quickstart -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/quickstart ---- - -# Console Quickstart - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Objective - -This Console quickstart guide will cover how to: - -- Register an account on Helium Console -- Add a device to Helium Console and record device details - -:::info - -The cost per packet is $0.00001 USD \(24 byte packets\) which is equivalent to 1 Data Credit \(DC\). -For more information please go [here](/data-credit). - -::: - -## Create an account - -To register for an account, visit [Helium Console](https://console.helium.com) and click **Sign -Up**. - -During registration, you'll be asked to provide an Organization name. For more information about -Organizations go [here](/use-the-network/console/users#organizations). - -Define an Organization name for the top level owner of the account \(i.e. company name\). - - - -### Confirm your account - -A confirmation email will be sent to the email address used to create an account. You must confirm -the account in order to continue using Console. If you did not receive an email, please check your -spam folders. - -## Device Management - -Helium Console allows developers to add devices and grab the device identifiers to load onto their -device firmware that authenticates and identifies the device for the Helium Network. - -### Add a Device - -To add a device, go to **Devices** and click the **+ Add Device** icon on the top right of the -window. - -When prompted, enter a name for your device. Device names do not have to be unique \(as every device -will be given a unique identifier generated by Console\). `DevEUI`, `AppEUI`, and `AppKey` are auto -generated by the Helium Console when you create a new device. However, you can input your own -`DevEUI`, `AppEUI`, and `AppKey` if your device is already provisioned with these credentials. - -:::important - -Helium Console users are capped at ONE (1) Organization and 10 devices for their account. - -If your account as of March 31, 2022 exceeds this cap, you can continue using Helium Console with -those existing devices and Orgs for 12 calendar months, but will not be able to add additional -devices and Orgs. - -To continue with more than 1 Org / 10 devices after 12 months, you will need to work with a member -of the ecosystem, host your own instance, or contact a team members at sales@nova-labs.com. - -\*While an account is in an overage state with > 1 Org / 10 devices and a device or Org is deleted, -additional devices or Orgs cannot be re-added. - -Users over the cap who would like to immediately add more devices/Organizations, or users who have -not yet exceeded the cap but plan to do so, can reach out to members of the ecosystem, host their -own instance, or contact sales@nova-labs.com. - -::: - - - -Once added, you'll see a consolidated view of all your device details, as well as the Activation -Method \(only `OTAA` is currently supported\) and the LoRaWAN US Channels used by the Helium Network -\(which will always be `sub-band 2`\). - - - -## Live Data and Event Logs - -When a valid data packet is received from that device, a dot will appear from the left side of the -chart and flow towards the right as time goes on. - -Blue dots represent packets that have been successfully sent to endpoints, while orange dots have -failed to reach an endpoint, and red dots do not have a defined endpoint. - -The size of the dot is related to the size of the packet. Larger sized packets will be a larger dot, -and small data packets will be a smaller dot. - -### Event Log - -Event Logs display real-time packets in table form. There's different categories including Uplinks, -Downlinks, Join Request/Accept, Acknowledge. Here you can see size of packet, Port, and Devaddr. In -addition, which Hotspot(s) received the packet, its RSSI, SNR, Frequency, Spreading Factor and time -of receipt. As well as Integration success or failure messages. - -The Event Log also provides a filter to display dropped uplinks, and allows users to filter events -w/commands. - -The information in the Event Log can also exported as a JSON file. - -## Connecting Integrations to Devices - -Devices or groups of devices can be directly connected to integrations. - -To connect one or more devices to one or more integrations, simply define an integration and attach -a device to it on the Flows workspace. Integrations need to be created before they're available. You -can use Labels to group devices together for easy identification and management read more on labels -[here](/use-the-network/console/labels). - -## Next Steps - -Now that you have learned how to add a device on Console it's time to get an actual device -connected. We have several quickstart guides for some of the most popular development and ready to -use devices [here](/use-the-network/devices). diff --git a/docs/use-the-network/console/troubleshooting.mdx b/docs/use-the-network/console/troubleshooting.mdx deleted file mode 100644 index 4eeb50520..000000000 --- a/docs/use-the-network/console/troubleshooting.mdx +++ /dev/null @@ -1,91 +0,0 @@ ---- -id: troubleshooting -title: Console Troubleshooting -pagination_label: Console Troubleshooting -sidebar_label: Console Troubleshooting -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/troubleshooting ---- - -# Console Troubleshooting - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Common issues - -### I just added my device in Console. Why am I not receiving data? - -If you are having issues receiving data after adding a new device, the first thing to check is that -the keys from the device (dev eui, app eui, app key) match exactly what is provided by the device; -it is very common for app eui and dev eui in particular to be swapped You may also want to ensure -that you are using the correct byte ordering or “endianness” this is often labeled as MSB (Most -Significant Bit) and LSB (Least Significant Bit). Reversing byte order is a very common mistake when -adding a new device to the network. You may also want to check that your device is a Class A device -as we do not currently support Class B, or C devices. - -### How can I view Decoded Payloads? - -To view a decoded payload using the Debug tool, you will need to first create a function. To access -Debug mode, go to your device > and click on the little bug on the right hand side. The Decoder -Function can be written using custom JavaScript code provided by the user or selected from prebuilt -decoders (currently Browan Object Locator and Cayenne LPP). Once the function has been created it -will need to be attached to a Label or Integration. This Label that attaches to the device must also -be applied to the device. Please see -[complete Function documentation for more information](/use-the-network/console/functions/). - -### How do I manage my Hotspots on Console? - -Currently Hotspots can’t be managed or connected on Console. You will need to use the Helium Mobile -app to manage your Hotspots. - -### What does it mean when my label is greyed out? - -When a label looks greyed out, like the image below, this would indicate that it does not have a -function attached to it. - -### Why can't my sensor/device join? - -There's a number of possibilities why a sensor/device may not be able to join. See below for reasons -and actions: - -- Confirm the sensor still has power (check batteries), and is configured properly. If other similar - devices have joined successfully, this may be a hardware or firmware issue for that specific - sensor. -- Ensure Helium Hotspot coverage is available in your area: - - Explorer for Hotspot asserted [locations](https://explorer.helium.com/) - - Mapping [data](https://mappers.helium.com/) from community members mapping coverage -- Double check to verify the **sensor keys (Dev EUI, App EUI, App Key) have been entered correctly** - into Console. These keys are typically provided by the sensor manufacturer. -- If there’s only one Hotspot in the area ensure the sensor and Hotspot are separated by a minimum - of at least 3m (approximatelty 10 feet), but ideally no closer than 30-50 feet. A sensor that is - too close to a Hotspot may also result in repeated Join Request and Join Accept attempts. -- Once all the above items have been checked and there's still no join attempts after a few minutes - try and re-initiate a rejoin by whatever means the particular device requires. - -Remember after initial joining: - -- It takes up to (20-30 mins) for a sensor to be added for the first time due to XOR filter adding - sensor credentials to blockchain: for more info check - [here](/use-the-network/console/adding-devices/#when-adding-devices-for-the-first-time). - - - -### Why are my downlinks not working? - -A LoRaWAN Class A device only listens for downlinks immediately after sending an uplink. The LoRaWAN -specification defines this as the "receive windows" (ie:`RX1`) which starts `RX_DELAY1` seconds -after the uplink is complete. - - - -If the device receives no downlinks during the first window, it will listen again one second later -during the second receive window (ie: `RX2`). - -Sometimes an enqueued downlink may be received by a LoRaWAN gateway too late for both windows. This -can be due to geographic distance between the gateway and the server or due to high latency -backhauls used by the gateway (such as cellular). - -In these cases, it is recommended to explore increasing the `RX_DELAY1` value. More information -about how to use LoRaWAN Profiles on Console to configure the `RX_DELAY1` value is available -[here](/use-the-network/console/profiles/#receive-window-delay). diff --git a/docs/use-the-network/console/users.mdx b/docs/use-the-network/console/users.mdx deleted file mode 100644 index 76868939b..000000000 --- a/docs/use-the-network/console/users.mdx +++ /dev/null @@ -1,152 +0,0 @@ ---- -id: users -title: Users And Organizations -pagination_label: Users And Organizations -sidebar_label: Users And Organizations -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/console/users ---- - -# Users and Organizations - -import useBaseUrl from '@docusaurus/useBaseUrl' - -This section describes the system of Users and Organizations within Helium Console. At a high level: - -- A `user` is someone registered for Console via their email address. -- An `organization` can have any number of `users`. -- A `user` can be part of any number of `organizations`. - -## User Roles - -The first user to register a new organization is given the highest role of `Administrator`. - -### User Role Definitions - -User permissions and privileges are as follows: - -**Administrator** - -- Manage Devices -- Manage Flows -- Manage Labels -- Manage Data Credits -- Manage Users -- Manage API Keys - -**Manager** - -- Manage Devices -- Manage Flows -- Manage Labels - -**Read-Only** - -- View Devices - -### Managing Users - -If you're an administrator, you can manage users for your organizations. To add a new user, once -logged in, [navigate to the Users page](https://console.helium.com/users) and then click **+ Add -User** in the upper right. You will be presented with a pop-up that asks you to supply the email of -the new user, and select their desired access level. Once you've done this, hit **Submit** and they -will be invited to join the organization via email. - -## Organizations - -An Organization is created when first registering an account. All Organizations of which you're a -member can be [viewed and managed from here](https://console.helium.com/organizations). From this -screen you can switch between Organizations, delete Organizations (with appropriate permissions), -view your DC balances, and make all devices for an organization either `Active` or `Inactive`(with -appropriate permissions). - -Users can add additional Organizations by navigating to the **Dashboard** page using the left side -navigation, and then click **+ Add Organization** in the upper right. To switch to another -Organization click the **Switch** button on the list of Organizations on the **Dashboard** page. - -:::important - -Helium Console users are capped at ONE (1) Organization and 10 devices for their account. - -If your account as of March 31, 2022 exceeds this cap, you can continue using Helium Console with -those existing devices and Orgs for 12 calendar months, but will not be able to add additional -devices and Orgs. - -To continue with more than 1 Org / 10 devices after 12 months, you will need to work with a member -of the ecosystem, host your own instance, or contact a team members at sales@nova-labs.com. - -\*While an account is in an overage state with > 1 Org / 10 devices and a device or Org is deleted, -additional devices or Orgs cannot be re-added. - -::: - - - -### Organization Migration - -The Organization Migration feature allows users to transfer Organization configurations to another -Console hosted instance. - -For example, if a user wants to migrate their Organization from a Console instance hosted by one -provider to another or to their own hosted version of Console. - -:::important - -Data Credit balances are not transferable and will not be migrated. - -::: - -Migrating Organizations requires exporting the desired Organization by saving the JSON configuration -file to disk, and then importing that file on the new Console instance. - -### Exporting Organizations - -Exporting Organizations allow users to transfer the following information to another Console -instance. - -:::info - -Users will need to be re-added, and Data Credit balances are not transferable. - -::: - -- Devices -- Labels -- Functions -- Integrations -- Flows -- Alerts -- Configuration settings - -To export an Organization, navigate to the Organizations section and make sure the Organization to -export is current. - -- Click the Export icon of the Organization to export and save the JSON configuration to the desired - location. - - - -### Importing Organizations - -Importing an Organization can be performed upon first login for the new Console instance or later -from the Organizations section. - -:::important - -Prior to import, set the Organization on the previous Console instance to inactive and make sure no -duplicate devices exist on the new Console instance. This will allow devices to join on the new -Console instance. - -::: - -:::info - -AWS IoT Core users - before importing users should delete existing migrated device certificates on -AWS IoT Core. - -::: - -To import an Organization, navigate to the Organizations section and click + Add Organization. - -- Drag and drop the file or navigate to the JSON file saved location. diff --git a/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruit-feather-m0-rfm95.mdx b/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruit-feather-m0-rfm95.mdx deleted file mode 100644 index 412e5b6fe..000000000 --- a/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruit-feather-m0-rfm95.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: adafruit-feather-m0-rfm95 -title: Adafruit Feather M0 RFM95 -pagination_label: Adafruit Feather M0 RFM95 -sidebar_label: Adafruit Feather M0 RFM95 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Adafruit Feather M0 RFM95 - - - -## Introduction - -The Adafruit Feather M0 RFM95 is Adafruit's popular ATSAMD21G18(ARM Cortex M0) based LoRa -development board with built in USB and battery charging. - -### Resources - -- [Product Page](https://www.adafruit.com/product/3178) -- [Manual](https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/downloads) -- [Schematic ](https://learn.adafruit.com/assets/32914) - -### Firmware Quickstart Guides - -[Arduino Guide](/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/arduino) - -### Complete Integration Guides - -[Adafruit IO Guide](/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruitio) diff --git a/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruitio.mdx b/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruitio.mdx deleted file mode 100644 index e56fd6e6a..000000000 --- a/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruitio.mdx +++ /dev/null @@ -1,378 +0,0 @@ ---- -id: adafruitio -title: AdafruitO -pagination_label: AdafruitO -sidebar_label: AdafruitO Guide -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruitio ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Adafruit IO Guide with Adafruit Feather M0 RFM95 - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from the Console quickstart -[here](/use-the-network/console/quickstart). This will ensure you have a Console account and have -created a new device. - -::: - -## Objective and Requirements - -In this guide, you will learn how to: - -- Connect your hardware -- Setup your firmware environment -- Program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range -- Create an AdafruitIO integration and attach to device - -For this example, you will need the following: - -### Hardware - -- [Adafruit Feather M0 - RFM95](https://www.adafruit.com/product/3178) -- [DHT22 Temperature and Humidity Sensor](https://www.adafruit.com/product/385) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) -- Jumper cables - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) -- [Helium Console](https://console.helium.com/) - -## Hardware Setup - -This step will cover adding an antenna, jumping pins on the LoRaWAN radio, and finally wiring the -DHT22 temperature and humidity sensor. Below is a breadboard wiring diagram that you can reference -for your setup. - - - -### Adding the Antenna - -Please visit Adafruit's Documentation for antenna options and instructions -[here](https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/antenna-options). - -### Jumping IO1 to Pin6 - -In order to use the RFM95 radio module onboard the Feather M0 for LoRaWAN we'll need to connect two -pins together. The pins are labeled `io1` and `6` on the board, as shown below. If you have the -headers soldered on, you can use a female to female jumper cable to connect them, or you can simply -solder a wire from pin to pin. - - - -### Wiring the DHT22 Sensor - -Connect the signal pin `2` of the DHT22 sensor to pin `12` on the feather board. You will also need -to add a pull up resister (20-50k) between the signal pin `2` of the DHT22 sensor and the 3.3V -supply. Last, connect the power(3.3V or 5V) and ground pins. Please reference the breadboard diagram -above. - -## Software Setup - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. - -- [Windows](https://www.arduino.cc/en/Guide/Windows) -- [Linux](https://www.arduino.cc/en/Guide/linux) -- [Mac OSX](https://www.arduino.cc/en/Guide/MacOSX) - -### Arduino Board Support - -The Adafruit Feather M0 requires two Arduino board support packages. Follow the instructions below -to install both. - -#### Arduino SAMD Boards \(32-bits ARM Cortex-M0+\) - -To install, open your Arduino IDE: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **Arduino SAMD Boards \(32-bits ARM Cortex-M0+\)** -3. Select the newest version and click Install - -#### Adafruit SAMD Boards - -To install, open your Arduino IDE: - -1. Navigate to **\(File > Preferences\), \(Arduino > Preferences\) on MacOS.** -2. Find the section at the bottom called **Additional Boards Manager URLs:** - - - -1. Add this URL in the text box: - -```text -https://adafruit.github.io/arduino-board-index/package_adafruit_index.json -``` - -1. Close the Preferences windows - -Next, to install this board support package: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **Adafruit SAMD Boards** -3. Select the newest version and click Install - -### Arduino Library - -To communicate with Helium's LoRaWAN network, we'll need to install an Arduino library. - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **IBM LMIC framework** into the search, select the version shown below, - and click Install. - - - -To communicate with the DHT22 sensor, we'll need to install an Arduino library. - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **DHT22 sensor library** into the search, select the version shown below, - and click Install. - - - -To encode our data with CayenneLPP, we'll need to install an Arduino library. - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **CayenneLPP** into the search, select the version shown below, and click - Install. - - - -#### Update IBM LMIC framework config.h - -This library requires that a config file be setup properly. After you have installed the -`IBM LMIC framework` library, navigate to it's directory on your operating system found below. Next, -replace the `config.h` file in this directory with this -[config.h](https://github.com/helium/longfi-arduino/blob/master/Adafruit-Feather-M0-RFM95/longfi-us915/config.h) -file. - -linux: /home/{user}/Arduino/libraries/IBM_LMIC_framework/src/lmic windows: -Documents/Arduino/libraries/IBM_LMIC_framework/src/lmic mac os: -Documents/Arduino/libraries/IBM_LMIC_framework/src/lmic - -### Programming Example Sketch - -Now that we have the required Arduino board support and library installed, lets program the board -with the provided example sketch. - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://github.com/helium/longfi-arduino/blob/master/Adafruit-Feather-M0-RFM95/longfi-us915-cayenne-dht22/longfi-us915-cayenne-dht22.ino), -copy and paste the entirety of it. - -Next we'll need to fill in the AppEUI\(lsb\), DevEUI\(lsb\), and AppKey\(msb\), in the sketch, which -you can find on the device details page on Console. Be sure to use the formatting buttons to match -the endianess and formatting required for the sketch, shown below. - - - -At the top of the sketch, replace the three **FILL_ME_IN** fields, with the matching field from -Console, example shown below. - - - -### Selecting Board - -Next, we need to select the correct board to build for in the Arduino IDE. Navigate to \(**Select -Tools > Board: > Adafruit Feather M0\).** - -### Enter Bootloader Mode - -Next, we need to place the board into bootloader mode, which allows us to update it with new -firmware. To do this, first plug the device into your computer, make sure the power switch is turned -on \(you should see a red LED on\). Next, quickly double click the reset push button on the top side -of the board, you should see the red LED slowly blink. If you see this then you have successfully -entered bootloader mode. - -### Selecting Port - -We're almost ready to upload our sketch, the very last step is to select the correct Serial port in -the Arduino IDE. Navigate to \(**Tools > Port: Adafruit Feather M0**\). You will also see either -**COM\# or /dev/ttyACM\#** depending on whether you are on Windows, Mac, or Linux. If you do not see -a port, please visit the Drivers section in -[Adafruit's Docs](https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/using-with-arduino-ide#install-drivers-windows-7-and-8-only-6-11) -to make sure you have what's needed for your operating system. - -### Upload Sketch - -We're finally ready to upload our sketch to the board. In the Arduino IDE, click the right arrow -button, or navigate to \(**Sketch > Upload\),** to build and upload your new firmware to the -board. You should see something similar to the image below at the bottom of your Arduino IDE, when -the upload is successful. - - - -### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. We first need to select -the serial port again, but this time it will be a **different port** than the one we selected to -communicate with the bootloader. Once again, navigate to \(**Tools > Port: Adafruit Feather -M0**\), but make sure the serial device, either COM\# or ttyACM\#, is different! Next navigate to -\(**Tools > Serial Monitor**\), you should begin to see output similar to below. - - - -Now let's head back to [Helium Console](https://console.helium.com) and look at our device page, you -should see something similar to the screenshot below. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to create -and attach the AdafruitIO integration. - -## Adafruit IO - -Next we'll create and attach the Adafruit IO integration. - -You can sign up for a free account at [https://io.adafruit.com](https://io.adafruit.com/). - -To add the integration in Console, go to **Integrations** on the left-hand menu. Select the -integration to add - in this case, the **Adafruit IO** integration as shown below. - - - -The next step is to enter your Adafruit IO username and key. These can be found by visiting -[https://io.adafruit.com](https://io.adafruit.com/) and clicking _MyKey_ in the top right corner as -shown below. - - - -You will then be presented with both your username and key as shown below. - - - -Copy these values into the username and key fields in Console for the integration configuration -shown below. - - - -Last for this step, you can optionally change the group name that is set to `{{device_id}}` by -default. The group name is used to group one or more data values that is received from a device and -sent to AdafruitIO in a single message. This name is used as the default because it is guaranteed to -be unique for every Helium device. You can use any of the the available template tags which are auto -populated when messages are actually sent, which are `{{device_id}}`, `{{device_eui}}`, and -`{{device_name}}`. This integration uses group topics to send device data to AdafruitIO over MQTT, -you can read more about it [here](https://io.adafruit.com/api/docs/mqtt.html#group-topics). - -Next let's name the integration in step 3, you will use this name later to identify the integration -when attaching it to devices. - - - -The very last step is to select the decoder that will be used to decode the data payload received -from your device. We will be using the _CayenneLPP_ decoder as shown below and encoding the sensor -data with CayenneLPP. Last be sure to click _Create Integration_ to finish. - - - -### Connecting AdafruitIO Integration to Device - -Now that we have our integration created, the last step is to attach the label to our device. To do -this, navigate your device page and click the `Add Label` button shown below. - - - -Search for the AdafruitIO label, select, and finally click Add Label. - - - -You should now see your data appearing on Adafruit IO under Feeds as shown below. - - - -That completes this guide! diff --git a/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/arduino.mdx b/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/arduino.mdx deleted file mode 100644 index 2b8106960..000000000 --- a/docs/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/arduino.mdx +++ /dev/null @@ -1,239 +0,0 @@ ---- -id: arduino -title: Arduino -pagination_label: Arduino -sidebar_label: Arduino -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/arduino ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Adafruit Feather M0 RFM95 Arduino Guide - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from the Console quickstart -[here](/use-the-network/console/quickstart). - -::: - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your environment -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, you will need the following: - -### Hardware - -- [Adafruit Feather M0 - RFM95](https://www.adafruit.com/product/3178) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) -- [Helium Console](https://console.helium.com/) - -## Hardware Setup - -This step will cover adding an antenna and closing the LoRaWAN jumpers on this board. - -### Adding the Antenna - -Please visit Adafruit's Documentation for antenna options and instructions -[here](https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/antenna-options). - -### Jumping IO1 to Pin6 - -In order to use the RFM95 radio module onboard the Feather M0 for LoRaWAN we'll need to connect two -pins together. The pins are labeled io1 and 6 on the board, as shown below. If you have the headers -soldered on, you can use a female to female jumper cable to connect them, or you can simply solder a -wire from pin to pin. - - - -## Software Setup - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. - -- [Windows](https://www.arduino.cc/en/Guide/Windows) -- [Linux](https://www.arduino.cc/en/Guide/Linux) -- [Mac OSX](https://www.arduino.cc/en/Guide/MacOSX) - -### Arduino Board Support - -The Adafruit Feather M0 requires two Arduino board support packages. Follow the instructions below -to install both. - -#### Arduino SAMD Boards \(32-bits ARM Cortex-M0+\) - -To install, open your Arduino IDE: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **Arduino SAMD Boards \(32-bits ARM Cortex-M0+\)** -3. Select the newest version and click Install - -#### Adafruit SAMD Boards - -To install, open your Arduino IDE: - -1. Navigate to **\(File > Preferences\), \(Arduino > Preferences\) on MacOS.** -2. Find the section at the bottom called **Additional Boards Manager URLs:** - - - -1. Add this URL in the text box: - -```text -https://adafruit.github.io/arduino-board-index/package_adafruit_index.json -``` - -1. Close the Preferences windows - -Next, to install this board support package: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **Adafruit SAMD Boards** -3. Select the newest version and click Install - -### Arduino Library - -To communicate with Helium's LoRaWAN network, we'll need to install an Arduino library. - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **IBM LMIC framework** into the search, select the version shown below, - and click Install. - - - -#### Update IBM LMIC framework config.h - -This library requires that a config file be setup properly. After you have installed the -`IBM LMIC framework` library, navigate to it's directory on your operating system found below. Next, -replace the `config.h` file in this directory with this -[config.h](https://github.com/helium/longfi-arduino/blob/master/Adafruit-Feather-M0-RFM95/longfi-us915/config.h) -file. - -linux: /home/{user}/Arduino/libraries/IBM_LMIC_framework/src/lmic windows: -Documents/Arduino/libraries/IBM_LMIC_framework/src/lmic mac os: -Documents/Arduino/libraries/IBM_LMIC_framework/src/lmic - -### Programming Example Sketch - -Now that we have the required Arduino board support and library installed, lets program the board -with the provided example sketch. - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://github.com/helium/longfi-arduino/blob/master/Adafruit-Feather-M0-RFM95/longfi-us915/longfi-us915.ino), -copy and paste the entirety of it. - -Next we'll need to fill in the AppEUI\(lsb\), DevEUI\(lsb\), and AppKey\(msb\), in the sketch, which -you can find on the device details page on Console. Be sure to use the formatting buttons to match -the endianess and formatting required for the sketch, shown below. - - - -At the top of the sketch, replace the three **FILL_ME_IN** fields, with the matching field from -Console, example shown below. - - - -### Selecting Board - -Next, we need to select the correct board to build for in the Arduino IDE. Navigate to \(**Select -Tools > Board: > Adafruit Feather M0\).** - -### Enter Bootloader Mode - -Next, we need to place the board into bootloader mode, which allows us to update it with new -firmware. To do this, first plug the device into your computer, make sure the power switch is turned -on \(you should see a red LED on\). Next, quickly double click the reset push button on the top side -of the board, you should see the red LED slowly blink. If you see this then you have successfully -entered bootloader mode. - -### Selecting Port - -We're almost ready to upload our sketch, the very last step is to select the correct Serial port in -the Arduino IDE. Navigate to \(**Tools > Port: Adafruit Feather M0**\). You will also see either -**COM\# or /dev/ttyACM\#** depending on whether you are on Windows, Mac, or Linux. If you do not see -a port, please visit the Drivers section in -[Adafruit's Docs](https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/using-with-arduino-ide#install-drivers-windows-7-and-8-only-6-11) -to make sure you have what's needed for your operating system. - -### Upload Sketch - -We're finally ready to upload our sketch to the board. In the Arduino IDE, click the right arrow -button, or navigate to \(**Sketch > Upload\),** to build and upload your new firmware to the -board. You should see something similar to the image below at the bottom of your Arduino IDE, when -the upload is successful. - - - -### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. We first need to select -the serial port again, but this time it will be a **different port** than the one we selected to -communicate with the bootloader. Once again, navigate to \(**Tools > Port: Adafruit Feather -M0**\), but make sure the serial device, either COM\# or ttyACM\#, is different! Next navigate to -\(**Tools > Serial Monitor**\), you should begin to see output similar to below. - - - -Now let's head back to [Helium Console](https://console.helium.com) and look at our device page, you -should see something similar to the screenshot below. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our Integrations docs -[here](/use-the-network/console/integrations). diff --git a/docs/use-the-network/devices/development/arduino/lora-vision-shield/arduino.mdx b/docs/use-the-network/devices/development/arduino/lora-vision-shield/arduino.mdx deleted file mode 100644 index d17723e86..000000000 --- a/docs/use-the-network/devices/development/arduino/lora-vision-shield/arduino.mdx +++ /dev/null @@ -1,955 +0,0 @@ ---- -id: arduino -title: Arduino -pagination_label: Arduino -sidebar_label: Arduino -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/arduino/lora-vision-shield/arduino ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LoRa Vision Shield with the Arduino Portenta - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from the Console quickstart -[here](/use-the-network/console/quickstart). - -Note: Arduino or MBED experts can skip all the following beginner setup steps, Install the MKRWAN -library, run `MKRWANFWUpdate_standalone` view the serial monitor to update the LoRa module and go -directly to the step -[portenta-lorawan-base64-encoded-sketch](#portenta-lorawan-base64-encoded-sketch). - -::: - -## Objective and Requirements - -In this version 0.2.1 of this guide, you will learn: - -- How to setup your environment -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range -- Setup a full [Adafruit.io](https://io.adafruit.com/) https connection with a base64 decoder. - (Note: CayenneLPP with Adafruit.io is easier to setup but less flexible) - -### Video Guides - -- [Community Tutorial Video](https://www.youtube.com/watch?v=wt_WZ1sBDeM&list=PL57Dnr1H_eguoFKLWY0nLMz0QI3nyQVmQ&index=12) - -For this example, you will need the following: Power users can jump ahead to the title Arduino -Library #1 MKRWAN - -### Hardware - -- [Portenta H7](https://store-usa.arduino.cc/products/portenta-h7) -- [LoRa Vision Shield](https://store-usa.arduino.cc/products/arduino-portenta-vision-shield-lora%C2%AE) -- Micro USB Type C Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) -- U.FL connector for your region. This example will use the US915MHz Antenna - [Example: U.FL IPEX to SMA Connector Antenna 915MHz for Lora Board](https://www.amazon.com/DIYmall-Connector-Antenna-915MHz-Lora32u4/dp/B084KVYBH5) - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) Old stable version ~Arduino - IDE 1.8.19 or new version ~2.0.0RC3 -- [Helium Console](https://console.helium.com/) - -## Hardware Setup - -This step will cover adding an antenna to the LoRa Vision Shield. - -### Adding the Antenna - -The uFL connector is just a push fit on the LoRa board, not the main Portenta board (That uFL -connector is for WiFi and BLE). Try not to have to remove and replace the antenna very often. The -uFL connectors are rated for 30 connection cycles, so be careful when connecting/disconnecting to -not rip the pads off the PCB. - -## Software Setup - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. - -- [Windows](https://www.arduino.cc/en/Guide/Windows) -- [Linux](https://www.arduino.cc/en/Guide/Linux) -- [Mac OSX](https://www.arduino.cc/en/Guide/MacOSX) - -### Arduino Board Support - -The PortentaH7 requires one Arduino board support package. Follow the instructions below to install -it. - -#### Arduino Mbed OS Portenta Boards - -To install, open your Arduino IDE: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **Arduino Mbed OS Portenta Boards** -3. Select the newest version and click Install - - - -### Arduino Library #1 MKRWAN - -To communicate with Helium's LoRaWAN network, we'll need to install an Arduino library. - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **MKRWAN** into the search, select the **MKRWAN** library latest version, - see image below, and click install. - - - -If you prefer to install the zipped latest file from the github click -[MKRWAN](https://github.com/arduino-libraries/MKRWAN) download the zipped file then find the library -menu item to install zipped libraries. - -### Arduino Library #2 "Portenta Pro Community Solutions" - -This is optional as the sketch is provided below - -To communicate with Helium's LoRaWAN network, we'll need to install an Arduino library. - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **community** into the search, select the - **portenta-pro-community-solutions** library latest version see image below, and click Install. - - - -If you prefer to install the zipped latest file from the github click -[portenta-pro-community-solutions](https://github.com/hpssjellis/portenta-pro-community-solutions) -download the zipped file then find the library menu item to install zipped libraries. - -### MKRWAN reprogram LoRa board using the MKRWAN example sketch - -MKRWANFWUpdate_standalone make sure you run the serial monitor to fully update the LoRa module with -the correct program. - - - -:::important - -The Sketch Install! - -::: - -### Upload Sketch - -We're finally ready to upload our sketch to the board. In the Arduino IDE, click the right arrow -button, or navigate to \(**Sketch > Upload\),** to build and upload your new firmware to the -board. You should see something similar to the image below at the bottom of your Arduino IDE, when -the upload is successful. - - - -### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. We first need to select -the serial port again, but this time it will be a **different port** than the one we selected to -communicate with the bootloader. Once again, navigate to \(**Tools > Port: Arduino Portenta**\), -but make sure the serial device, either COM\# or ttyACM\#, is different! Next navigate to \(**Tools -> Serial Monitor**\), you should begin to see output similar to below. - - - -### Selecting Board - -If you had trouble with the above steps here is an Arduino refresher. - -Next, we need to select the correct board to build for in the Arduino IDE. Navigate to \(**Select -Tools > Board: > Arduino Mbed OS Portenta Boards > Arduino PortentaH7 \(M7 Core\) \).** - -### Enter Bootloader Mode - -Next, we need to place the board into bootloader mode, which allows us to update it with new -firmware. To do this, first plug the device into your computer, make sure the board is getting power -\(you should see a green LED on\). Next, quickly double-click the reset push button on the top side -of the board, you should see the green LED slowly pulse about one green pulse per second, showing -that you have successfully entered bootloader mode. - - - -### Selecting Port - -We're almost ready to upload our sketch, the very last step is to select the correct Serial port in -the Arduino IDE. Navigate to \(**Tools > Port: Arduino Portenta**\). You will also see either -**COM\# or /dev/ttyACM\#** depending on whether you are on Windows, Mac, or Linux. If you do not see -a port, you will need to check if the Arduino drivers have been installed. - -### Programming Example Sketch - -Now that we have the required Arduino board support and library installed, lets program the board -with the provided example sketch. - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://github.com/hpssjellis/portenta-pro-community-solutions/blob/main/examples/dot3-portenta-vision-shields/dot33-lorawan-specific/dot334-proof-us915-helium-connect.ino), -copy and paste the entirety of it or if you have the Portenta-pro-community-solutions library just -find example -[dot334-proof-us915-helium-connect](https://github.com/hpssjellis/portenta-pro-community-solutions/blob/main/examples/dot3-portenta-vision-shields/dot33-lorawan-specific/dot334-proof-us915-helium-connect.ino), - -Here is the full sketch from the link -[here](https://github.com/hpssjellis/portenta-pro-community-solutions/blob/main/examples/dot3-portenta-vision-shields/dot33-lorawan-specific/dot334-proof-us915-helium-connect.ino), - -### Portenta LoRaWan Base64 Encoded Sketch - -``` -/* - Helium Send And Receive - - For Adafruit non-CayeenLPP connections for simple sensor Base 64 encoded - - In Helium "functions" section use this decoder - - function Decoder(bytes, port, uplink_info) { - var decoded={}; - try{ - var result = String.fromCharCode.apply(null, bytes); - decoded.value = result; - return decoded; - } catch (err) { - return 'Decoder: ' + err.name + " : " + err.message;; - } - } - - And in the integration section of helium use this JSON - - { "value": {{decoded.payload.value}} } - - - - - This sketch demonstrates how to send and receive data with the MKR WAN 1300/1310 LoRa module. - This example code is in the public domain. - note: Helium must be setup for what it does with the data -*/ - -#include // Only needed by https://platformio.org/ -#include - - -LoRaModem modem; -bool connected = false; -bool myWaitForDownlink = false; -bool myDownLink = false; - -unsigned long myStoredMillisA; -unsigned long myStoredMillisB; -const unsigned long myTimerDurationA = 30000; // delay between sending data -const unsigned long myTimerDurationB = 5000; // delay to wait for a downlink - - - -// Please enter your sensitive data in the Secret tab or arduino_secrets.h -// Note: Best to have the App_Device hard coded. Run the program once to see the value. -//#include "arduino_secrets.h" -#define SECRET_APP_EUI "00000000000000000" -#define SECRET_APP_KEY "00000000000000000000000000000000" - - -String appEui = SECRET_APP_EUI; // just strings of the above -String appKey = SECRET_APP_KEY; - - -void setup() { - // put your setup code here, to run once: - Serial.begin(115200); - pinMode(LEDR,OUTPUT); - pinMode(LEDG,OUTPUT); - pinMode(LEDB,OUTPUT); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, HIGH); - - //while (!Serial); // don't wait for serial - - Serial.println("Wait 4"); - delay(3000); // delay instead, so it works when disconnected - digitalWrite(LEDG, HIGH);// allows time to connect serial monitor - - Serial.println("Wait 3"); - delay(3000); - digitalWrite(LEDG, LOW); - - Serial.println("Wait 2"); - delay(3000); - digitalWrite(LEDG, HIGH); - - Serial.println("Wait 1"); - delay(3000); - digitalWrite(LEDG, LOW); - - - - - // change this to your regional band (eg. US915, AS923, ...) - if (!modem.begin(US915)) { - Serial.println("Failed to start module"); - while (1) {} - }; - - Serial.print("Your module version is: "); - Serial.println(modem.version()); - Serial.print("Your device EUI is: "); - Serial.println(modem.deviceEUI()); - - Serial.println("Now Disabling all channels and enable channel 1 only for Helium "); - - modem.disableChannel(0); - modem.enableChannel(1); // only one enabled for Helium - modem.disableChannel(2); - modem.disableChannel(3); - modem.disableChannel(4); - modem.disableChannel(5); - modem.disableChannel(6); - delay(5000); - Serial.println("Now Joining the Helium Network "); - -} - -void loop() { - - while (!connected) { - Serial.println("trying to reconnect"); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, LOW); - connected = modem.joinOTAA(appEui, appKey); - delay(5000); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, HIGH); - delay(1000); - } - - if (myWaitForDownlink){ - - char rcv[64]; - int i = 0; - while (modem.available()) { - rcv[i++] = (char)modem.read(); - myDownLink = true; - } - - if (millis() - myStoredMillisB >= myTimerDurationB){ // Test whether the period has elapsed - myStoredMillisB = millis(); - if (!modem.available()) { - Serial.println("No downlink message received at this time."); - myWaitForDownlink = false; - } - } - - - if (myDownLink) { - myWaitForDownlink = false; - myDownLink = false; - Serial.print("Received: "); - Serial.write(rcv, i); - // for (unsigned int j = 0; j < i; j++) { - // Serial.print(rcv[j] >> 4, HEX); - // Serial.print(rcv[j] & 0xF, HEX); - // Serial.print(" "); - // } - Serial.println(); - digitalWrite(LEDR, LOW); // new boards HIGH = off - digitalWrite(LEDG, HIGH); - digitalWrite(LEDB, LOW); - - } - - } - - - if (millis() - myStoredMillisA >= myTimerDurationA){ // Test whether the period has elapsed - myStoredMillisA = millis(); // IMPORTANT to save the next stored time - - - - - - String msg = String(analogRead(A0)); // program expecting numbers! - - Serial.println(); - Serial.print("Sending: " + msg + " - "); - for (unsigned int i = 0; i < msg.length(); i++) { - Serial.print(msg[i] >> 4, HEX); - Serial.print(msg[i] & 0xF, HEX); - Serial.print(" "); - } - Serial.println(); - - int err; - modem.beginPacket(); - modem.print(msg); - err = modem.endPacket(true); - if (err > 0) { - Serial.println("Message sent correctly!"); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, HIGH); - digitalWrite(LEDB, LOW); - } else { - Serial.println("Error sending message :("); - Serial.println("(you may send a limited amount of messages per minute, depending on the signal strength"); - Serial.println("it may vary from 1 message every couple of seconds to 1 message every minute)"); - digitalWrite(LEDR, LOW); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, HIGH); - } - myStoredMillisB = millis(); - myWaitForDownlink = true; - //delay(1000); - - - // delay(30000); // delay 30 seconds for testing - - } // end timerA - -} - - - -``` - -### Compile Sketch and copy the Device EUI - -Once the above sketch is compiled and you have checked the port and loaded the Serial monitor you -should see your unique Device EUI. Copy this value! - - - -:::important - -The Helium Console: Device, Function, Integration, Flows - -::: - -### Helium Console to Arduino Sketch - -After making a [Helium Console](https://console.helium.com) login, you we'll need to select a new -device "+" and on the Arduino sketch copy into the correct location the SECRET_APP_EUI called the -"APP EUI", and the SECRET_APP_KEY which is called the "APP Key", written exactly as you see them on -your Helium Console. - -``` -#define SECRET_APP_EUI "00000000000000000" -#define SECRET_APP_KEY "00000000000000000000000000000000" - -``` - -If you are familar with making a `#include "arduino_secrets.h"` tab then put these values in the -secrets tab which allows you to post your code without showing these values. It does not make your -code more secure so you don't have to do it. Note: If you are confused about the device EUI these -Arduino boards have the deviceEUI fixed per board, so you will have to run the code once, view in -the serial monitor what your boards deviceEUI is and enter that in the Helium Console. (the Helium -console however will randomly give you a deviceEUI (the top one in the list) but you must reset it -with the one specific for your board) See image below - - - -### Recompile your Arduino Sketch - -The Arduino sketch needs to be recompiled with the new App EUI and APP Key and the Portenta with -Vision Shield and LoRa Antenna need to be placed in an advantageous location to find Helium access -points. You can power your device with any 5V USB battery pack. Best locations are near windows and -the antenna placed vertically. - -### Check Your Helium Device - -Now let's head back to the [Helium Console](https://console.helium.com) and look at our device page, -Scroll down to the chart and click the black debug icon to see incoming data, you should see -something similar to the screenshot below. First the device needs to "joion" then it can "upload" -data. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build integrations to view your data, visit the Helium Integrations docs -[here](/use-the-network/console/integrations). - -:::important - -Setting up Adafruit.io - -::: - -### Connect to [Adafruit.io](https://io.adafruit.com/) - -There are a multitude of IOT sites to choose from, each with their own methods to setup. You will be -much more confident about those other sites once you have finished setting up a complete HTTPS -connection with a decoder. (I will show you the very inefficient base64 decoder simply because -LoRaWan naturally base64 encodes your information) Note: See the end of this tutorial for an easier -but less flexible Adafruit CayenneLPP MQTT example. - -### Setup Adafruit.io Feed and Webhook - -Get a free [Adafruit.io login](https://accounts.adafruit.com/users/sign_up) which allows 5 free -feeds (A feed keeps the data sent from a device to Adafruit). Click IO, then feeds, then add a new -feed. I call it "led1" but you can call it whatever you like. - - - -Next create a base (not a fancy) webhook (menu on the right of your feeds, might have to scroll -down) and copy the entire webhook URL. - - - -Webhooks are useful since you can define a duration, and they can be used on the web without giving -out your main Adafuit KEY, like you would have to if you were using MQTT. - -### Setup Helium Console Integration for Adafruit http - -Back at the Helium Console Integrations, make a new integration, give it some sensible name like -"adafruit-http-integration" and choose the manual http integration. - - - -You will be entering: 1. A name for the integration, 2. The adafruit Webhook copied earlier 3. Some -JSON code to get data from the decoder. This is at the bottom of the page and strangely replaces the -code above it. - -``` - { "value": {{decoded.payload.value}} } - -``` - - - -### Setup Helium Console Function Decoder - -At the Helium Console Functions area. Make a new function give it a sensible name like -"Adafruit-http-decoder-function". Then copy this code to replace the barebones decoder - -``` - - function Decoder(bytes, port, uplink_info) { - var decoded={}; - try{ - var result = String.fromCharCode.apply(null, bytes); - decoded.value = result; - return decoded; - } catch (err) { - return 'Decoder: ' + err.name + " : " + err.message;; - } - } - -``` - - - -### Setup Helium FLOWS to connect the nodes - -At the Helium Console go to the FLOWS menu. On some browsers the FLOWS controller is hard to see. -Click the "+" and choose and drag onto the screen the Device, Function and Integration you just -made. Close the Flows control by re-clicking the hard to see "+" - -Connect the 3 icons Portenta Device -to- function decoder -to- adafruit-integration - - - -### View your blue-dot working device - -Now let's head back to [Helium Console](https://console.helium.com) and look at our device page, -Scroll down to the chart and click the black debug icon to see incoming data, you should see -something similar to the screenshot below. This time the red-dot should be a blue dot showing a -successful Helium Adafruit integration. - - - -### View your Adafruit.io Data - -Now go back to Adafruit.io and view your feeds to see if the data is coming in like you are -expecting. - - - -### Make an Adafruit.io dashboard - -Not as important but fun to go to Adafruit dashboard and click the setup icon top right and create -buckets to view your data in streams and graphs etc. Dashboards and feed can be made public if you -want to share them with others who have the shareable link. - - - -:::important - -MQTT Adafruit with CayenneLPP - -This is easier but less flexible than the main tutorial - -::: - -### Easier CayenneLPP Adafruit MQTT example - -This example is easier than the above but less flexible. The decoder and the feed names are chosen -for you and can't be changed. Easy setup can be very useful when you know the negatives. - -1. When making a new Integration choose the MQTT Adafruit icon -2. Enter your username and "my Key" your main adafruit key -3. Name the integration and make a new function which will be the default CayenneLPP -4. Using FLOWS Connect your Portenta device to the CayenneLPP function and then to the Adafruit MQTT - Integration -5. Compile the code at dot334 example - [dot334-us915-helium-mqtt-adafruit-connect.ino](https://github.com/hpssjellis/portenta-pro-community-solutions/blob/main/examples/dot3-portenta-vision-shields/dot33-lorawan-specific/dot334-us915-helium-mqtt-adafruit-connect/dot334-us915-helium-mqtt-adafruit-connect.ino) - which takes an input on the Arduino Portenta A0 pin, converts it to CayenneLPP format, and sends - it to Helium. -6. Copy the Portenta Device_EUI to Helium and copy the App_EUI and APP_Key to the portenta code then - compile again. -7. Check the HElium device chart and debug Icon to see when uplink data is flowing, see if the graph - dots are blue for successful integration with Adafruit. The results should be the same as above. - -### CayenneLPP Portenta Example Sketch - -Following is the full arduino sketch from the link -[here](https://github.com/hpssjellis/portenta-pro-community-solutions/blob/main/examples/dot3-portenta-vision-shields/dot33-lorawan-specific/dot334-us915-helium-mqtt-adafruit-connect/dot334-us915-helium-mqtt-adafruit-connect.ino) - -``` - -/* - Helium Send And Receive - This sketch demonstrates how to send and receive data with the MKR WAN 1300/1310 LoRa module. - This example code is in the public domain. - note: Helium must be setup for what it does with the CayenneLPP encoded data -*/ - -#include // Only needed by https://platformio.org/ -#include -#include - - -LoRaModem modem; -CayenneLPP lpp(51); -bool connected = false; -bool myWaitForDownlink = false; -bool myDownLink = false; - -unsigned long myStoredMillisA; -unsigned long myStoredMillisB; -const unsigned long myTimerDurationA = 30000; // delay between sending data -const unsigned long myTimerDurationB = 5000; // delay to wait for a downlink - - - -// Please enter your sensitive data in the Secret tab or arduino_secrets.h -// Note: Best to have the App_Device hard coded. Run the program once to see the value. -//#include "arduino_secrets.h" -#define SECRET_APP_EUI "0000000000000000" -#define SECRET_APP_KEY "00000000000000000000000000000000" - - -String appEui = SECRET_APP_EUI; // just strings of the above -String appKey = SECRET_APP_KEY; - - -void setup() { - // put your setup code here, to run once: - Serial.begin(115200); - pinMode(LEDR,OUTPUT); - pinMode(LEDG,OUTPUT); - pinMode(LEDB,OUTPUT); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, HIGH); - - //while (!Serial); // don't wait for serial - - Serial.println("Wait 4"); - delay(3000); // delay instead, so it works when disconnected - digitalWrite(LEDG, HIGH);// allows time to connect serial monitor - - Serial.println("Wait 3"); - delay(3000); - digitalWrite(LEDG, LOW); - - Serial.println("Wait 2"); - delay(3000); - digitalWrite(LEDG, HIGH); - - Serial.println("Wait 1"); - delay(3000); - digitalWrite(LEDG, LOW); - - - - - // change this to your regional band (eg. US915, AS923, ...) - if (!modem.begin(US915)) { - Serial.println("Failed to start module"); - while (1) {} - }; - - Serial.print("Your module version is: "); - Serial.println(modem.version()); - Serial.print("Your device EUI is: "); - Serial.println(modem.deviceEUI()); - - Serial.println("Now Disabling all channels and enable channel 1 only for Helium "); - - modem.disableChannel(0); - modem.enableChannel(1); // only one enabled for Helium - modem.disableChannel(2); - modem.disableChannel(3); - modem.disableChannel(4); - modem.disableChannel(5); - modem.disableChannel(6); - delay(5000); - Serial.println("Now Joining the Helium Network "); - -} - -void loop() { - - while (!connected) { - Serial.println("trying to reconnect"); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, LOW); - connected = modem.joinOTAA(appEui, appKey); - delay(5000); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, HIGH); - delay(1000); - } - - if (myWaitForDownlink){ - - char rcv[64]; - int i = 0; - while (modem.available()) { - rcv[i++] = (char)modem.read(); - myDownLink = true; - } - - if (millis() - myStoredMillisB >= myTimerDurationB){ // Test whether the period has elapsed - myStoredMillisB = millis(); - if (!modem.available()) { - Serial.println("No downlink message received at this time."); - myWaitForDownlink = false; - } - } - - - if (myDownLink) { - myWaitForDownlink = false; - myDownLink = false; - Serial.print("Received: "); - Serial.write(rcv, i); - // for (unsigned int j = 0; j < i; j++) { - // Serial.print(rcv[j] >> 4, HEX); - // Serial.print(rcv[j] & 0xF, HEX); - // Serial.print(" "); - // } - Serial.println(); - Serial.println(); - digitalWrite(LEDR, LOW); // new boards HIGH = off - digitalWrite(LEDG, HIGH); - digitalWrite(LEDB, LOW); - - } - - } - - - if (millis() - myStoredMillisA >= myTimerDurationA){ // Test whether the period has elapsed - myStoredMillisA = millis(); // IMPORTANT to save the next stored time - - - - lpp.reset(); - float x = analogRead(A0); //analogRead(A0) or rand() / 10000000.0; - lpp.addDigitalOutput(1, x); - - - /* - // Can do any of these - lpp.reset(); - lpp.addDigitalInput(1, 0); - lpp.addDigitalOutput(2, 1); - lpp.addAnalogInput(3, 1.23f); - lpp.addAnalogOutput(4, 3.45f); - lpp.addLuminosity(5, 20304); - lpp.addPresence(6, 1); - lpp.addTemperature(7, 26.5f); - lpp.addRelativeHumidity(8, 86.6f); - lpp.addAccelerometer(9, 1.234f, -1.234f, 0.567f); - lpp.addBarometricPressure(10, 1023.4f); - lpp.addGyrometer(1, -12.34f, 45.56f, 89.01f); - lpp.addGPS(1, -12.34f, 45.56f, 9.01f); - - lpp.addUnixTime(1, 135005160); - - lpp.addGenericSensor(1, 4294967295); - lpp.addVoltage(1, 3.35); - lpp.addCurrent(1, 0.321); - lpp.addFrequency(1, 50); - lpp.addPercentage(1, 100); - lpp.addAltitude(1 , 50); - lpp.addPower(1 , 50000); - lpp.addDistance(1 , 10.555); - lpp.addEnergy(1 , 19.055); - lpp.addDirection(1 , 90); - lpp.addSwitch(1 , 0); - - lpp.addConcentration(1 , 512); - lpp.addColour(1 , 64, 128, 255); - - */ - - - Serial.println(); - Serial.println("Sending:" + String(x, 1)); - - - int err; - modem.beginPacket(); - modem.write(lpp.getBuffer(), lpp.getSize()); - err = modem.endPacket(true); - if (err > 0) { - Serial.println("Message sent correctly!"); - digitalWrite(LEDR, HIGH); // new boards HIGH = off - digitalWrite(LEDG, HIGH); - digitalWrite(LEDB, LOW); - } else { - Serial.println("Error sending message :("); - Serial.println("(you may send a limited amount of messages per minute, depending on the signal strength"); - Serial.println("it may vary from 1 message every couple of seconds to 1 message every minute)"); - digitalWrite(LEDR, LOW); // new boards HIGH = off - digitalWrite(LEDG, LOW); - digitalWrite(LEDB, HIGH); - } - myStoredMillisB = millis(); - myWaitForDownlink = true; - //delay(1000); - - - // delay(30000); // delay 30 seconds for testing - - } // end timerA - -} - - -``` - -### Video Guides - -- [Community Tutorial Video](https://www.youtube.com/watch?v=wt_WZ1sBDeM&list=PL57Dnr1H_eguoFKLWY0nLMz0QI3nyQVmQ&index=12) -- - -### Fails - -:::important - -Fails - -::: - -What to do when it fails! Lots of possible issues, but your best bet is the Helium console debug and -connection graph. - -1. If you are not getting a red dot your 3 secret numberes (deviceEUI, AppEUI, AppKey) are probably - not correct or you forgot to run the MRKWAN `MKRWANFWUpdate_standalone` code - [here](#compile-sketch-and-copy-the-device-eui) -2. If you get a red dot with the debug window only saying "Join Request" but never "uplink" you are - probably having network issues, just like WiFi issues if you move around, get closer to a window, - get higher, put the device on battery and leave it somewhere with a good view to the nearest - Helium gateway, use the [Helium explorer](https://explorer.helium.com/) to see which direction - the nearest gateway is. -3. If in the debug pane you see "uplink" but you only have a red dot then you have connected to - Helium and that is good, you just have not connected with an integration. Check your decoder and - integration settings [Adafruit here](#setup-adafruitio-feed-and-webhook) -4. If the dot is yellow you have connected with the function decoder but not yet fully with the - integration, check you decoder and integration settings - [decoder here](#setup-helium-console-function-decoder) -5. If the dot is blue you have successfully integrated but the data may not be in the correct - format, check your decoder/integration [Blue dot here](#view-your-blue-dot-working-device) -6. Hopefully the above helps. It is very difficult to determine if your nearest Helium Gateway is - having issues or if you have done something incorrect with your setup. Once you have a device - that connects consistently, then other devices are much easier to set up. Good luck. diff --git a/docs/use-the-network/devices/development/arduino/lora-vision-shield/lora-vision-shield.mdx b/docs/use-the-network/devices/development/arduino/lora-vision-shield/lora-vision-shield.mdx deleted file mode 100644 index 19fba2ffa..000000000 --- a/docs/use-the-network/devices/development/arduino/lora-vision-shield/lora-vision-shield.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: lora-vision-shield -title: Portenta Vision Shield Lora® -pagination_label: Lora Vision Shield -sidebar_label: Portenta Vision Shield Lora® -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/arduino/lora-vision-shield ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Portenta Vision Shield LoRa® - -A rapid solution for embedded ML combining vision, audio and connectivity - Detect Gestures, -Identify Objects, See Things. The Vision shield features a 324x324 pixels camera module containing -an Ultra Low Power Image Sensor designed for Always-on vision devices and applications. - - - -### Resources - -- [Product Page](https://store.arduino.cc/portenta-vision-shield) - -### Firmware Quickstart Guides - -- [Arduino Guide](/use-the-network/devices/development/arduino/lora-vision-shield/arduino) - -### Video Guides - -- [Community Tutorial Video](https://www.youtube.com/watch?v=wt_WZ1sBDeM&list=PL57Dnr1H_eguoFKLWY0nLMz0QI3nyQVmQ&index=12) - The easier but less flexible MQTT Adafruit connection. - -### Specifications - -#### Sensors: - -- sound (dual microphones) -- vision - -#### Dimensions: - -- width: 25 mm -- length: 67 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/arduino/mkr-wan-1310.mdx b/docs/use-the-network/devices/development/arduino/mkr-wan-1310.mdx deleted file mode 100644 index 1703c61ef..000000000 --- a/docs/use-the-network/devices/development/arduino/mkr-wan-1310.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: mkr-wan-1310 -title: Arduino Mkr Wan 1310 -pagination_label: Mkr Wan 1310 -sidebar_label: Arduino Mkr Wan 1310 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/arduino/mkr-wan-1310 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Arduino MKR WAN 1310 - -Connect your sensors and actuators over long distances harnessing the power of the LoRa® wireless -protocol or throughout LoRaWAN networks. The MKR WAN 1310 comes complete with an ECC508 crypto chip, -a battery charger, 2MByte SPI Flash, and power consumption as low as 104uA. - - - -### Resources - -- [Product Page](https://store.arduino.cc/mkr-wan-1310) - -### Specifications - -#### Dimensions: - -- width: 25 mm -- length: 67 mm - -#### Weight: - -- 32 grams - -#### Battery: - -- type: Li-Ion / Li-Po, 1024 mAh minimum capacity, JST connector -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/development.mdx b/docs/use-the-network/devices/development/development.mdx deleted file mode 100644 index ded84ec1b..000000000 --- a/docs/use-the-network/devices/development/development.mdx +++ /dev/null @@ -1,188 +0,0 @@ ---- -id: development -title: Development Devices -pagination_label: Development Devices -sidebar_label: Development Devices -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -
-
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
-
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
-
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
-
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
-
diff --git a/docs/use-the-network/devices/development/embit/emb-lr1280s.mdx b/docs/use-the-network/devices/development/embit/emb-lr1280s.mdx deleted file mode 100644 index f4e261031..000000000 --- a/docs/use-the-network/devices/development/embit/emb-lr1280s.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: emb-lr1280s -title: Emb-Lr1280S -pagination_label: Emb Lr1280S -sidebar_label: Emb-Lr1280S -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/embit/emb-lr1280s ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## EMB-LR1280S - -The new LoRa® 2.4 Ghz Embit solution to connect your sensors and actuators leveraging both the -advantages of LoRa® long range modulation and 2.4 Ghz RF properties and regulation. It offers a wide -range of serial intefaces, a crypto unit and extremely low consumptions. It represents the perfect -solution for many industrial applications with the aim of ensuring worldwide deployment and enhanced -transmission rate. - - - -- [Video](https://www.youtube.com/watch?v=W9B9bqGjlVs) - -### Specifications - -#### Dimensions: - -- width: 15.5 mm -- length: 20 mm -- height: 2.3 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/embit/emb-lrwl55.mdx b/docs/use-the-network/devices/development/embit/emb-lrwl55.mdx deleted file mode 100644 index 8281b1f46..000000000 --- a/docs/use-the-network/devices/development/embit/emb-lrwl55.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: emb-lrwl55 -title: Emb-Lrwl55 -pagination_label: Emb Lrwl55 -sidebar_label: Emb-Lrwl55 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/embit/emb-lrwl55 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## EMB-LRWL55 - -EMB-LRWL55 is the first ultra-low-power LoRaWAN® OEM module based on STM's new system-on-chip, -STM32WL55xx. Its tiny form factor and its capability of working both with 868MHz EU ISM band and -915MHz US make EMB-LRWL55 the perfect solution for small and battery powered LoRaWAN® end-devices, -with the possibility to interface any kind of sensors. - - - -- [Video](https://www.youtube.com/watch?v=W9B9bqGjlVs) - -### Specifications - -#### Dimensions: - -- width: 12.8 mm -- length: 13.5 mm -- height: 2.5 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-1-2-aa-node.mdx b/docs/use-the-network/devices/development/heltec/cubecell-1-2-aa-node.mdx deleted file mode 100644 index 1225b804d..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-1-2-aa-node.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: cubecell-1-2-aa-node -title: Htcc-Ab02A -pagination_label: Cubecell 1 2 Aa Node -sidebar_label: Htcc-Ab02A -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-1-2-aa-node ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AB02A - -HTCC-AB02A is a Dev-Board. Friendly designed for developers, easy to verify communication solutions. - - - -### Resources - -- [Product Page](https://heltec.org/project/htcc-ab02a/) -- [Datasheet](https://heltec.org/project/htcc-ab02a/#1552557147424-7f1ec-5c652144-e1d6dfc1-348c) - -### Specifications - -#### Dimensions: - -- width: 24 mm -- length: 56.6 mm -- height: 21.5 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-capsule-sensor.mdx b/docs/use-the-network/devices/development/heltec/cubecell-capsule-sensor.mdx deleted file mode 100644 index fa4bea621..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-capsule-sensor.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: cubecell-capsule-sensor -title: Htcc-Ac01 -pagination_label: Cubecell Capsule Sensor -sidebar_label: Htcc-Ac01 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-capsule-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AC01 - -HTCC-AC01 is a LoRa end node sensor. With a complete enclosure and protection measures, it can be -deployed directly into real-world applications. - - - -### Resources - -- [Product Page](https://heltec.org/project/htcc-ac01/) -- [Datasheet](https://heltec.org/project/htcc-ac01/#1552557147424-7f1ec-5c652144-e1d6f499-ec3b) - -### Specifications - -#### Dimensions: - -- height: 67 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-dev-board-plus.mdx b/docs/use-the-network/devices/development/heltec/cubecell-dev-board-plus.mdx deleted file mode 100644 index 4cef86e64..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-dev-board-plus.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -id: cubecell-dev-board-plus -title: Htcc-Ab02 -pagination_label: Cubecell Dev Board Plus -sidebar_label: Htcc-Ab02 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-dev-board-plus ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AB02 - -HTCC-AB02 is a Dev-Board. Friendly designed for developers, easy to verify communication solutions. - - - -### Resources - -- [Product Page](https://heltec.org/project/htcc-ab02/) -- [Datasheet](https://heltec.org/project/htcc-ab02/#1552557147424-7f1ec-5c652144-e1d638b1-a2e8) - -### Specifications - -#### Dimensions: - -- width: 25 mm -- length: 51.9 mm -- height: 8 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-dev-board/arduino.mdx b/docs/use-the-network/devices/development/heltec/cubecell-dev-board/arduino.mdx deleted file mode 100644 index 1f9577863..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-dev-board/arduino.mdx +++ /dev/null @@ -1,378 +0,0 @@ ---- -id: arduino -title: Arduino -pagination_label: Arduino -sidebar_label: Arduino -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-dev-board/arduino ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Heltec Cubecell HTCC AB01 Arduino Guide - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your environment -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, you will need the following: - -### Hardware - -- [Heltec CubeCell Board](https://heltec.org/project/htcc-ab01/) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) -- [Helium Console](https://console.helium.com/) - -## Hardware Setup - -### Adding the Antenna - -Your board should have come with a U.FL antenna. All you have to do is attache it to the U.FL port -as shown in the image at the top of the guide. - -### Connect Board - -Next, lets connect our board to our computer with a USB 2.0 A-Male to Micro B cable. - -## Software Setup - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. - -- ​[Windows](https://www.arduino.cc/en/Guide/Windows)​ -- ​[Linux](https://www.arduino.cc/en/Guide/Linux)​ -- ​[Mac OSX](https://www.arduino.cc/en/Guide/MacOSX)​ - -### Arduino Board Support - -The Heltec CubeCell Board requires one Arduino board support package. Follow the instructions below -to install. - -#### CubeCell Dev-boards - -To install, open your Arduino IDE: - -1. Navigate to **\(File > Preferences\), \(Arduino > Preferences\) on MacOS.** -2. Find the section at the bottom called **Additional Boards Manager URLs:** - - - -1. Add this URL in the text box: - -```text -http://resource.heltec.cn/download/package_CubeCell_index.json -``` - -1. Close the Preferences windows - -Next, to install this board support package: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **CubeCell Dev-boards** -3. Select the newest version and click Install - - - -### Manual updates to the Heltec runtime libraries - -Some versions of Heltec's runtime libraries have set default configuration variables to values that -are incompatible with the Helium network, especially when the Heltec device is configured targeting -the North American market. - -The following discusses two Heltec runtime files that must be inspected to ensure compatiblity. The -exact location of these files will depend on which operating system you are using, Windows, Linux, -or Mac as well as where the Arduino IDE is installed. - -The typical top level locations of the runtime libraries is shown below for each operating system. -From there the following discussions will present to you the file locations within these top level -directories/folders. Please note the Heltec library version numbers are expected to change as time -goes on. - -XXXXX denotes your specfic user id. - -##### Arduino IDE library location - -- Windows - -```text -C:\Users\XXXX\AppData\Local\Arduino15\packages\CubeCell\hardware\CubeCell\1.0.0 -``` - -- Linux - -```text -/home/XXXXX/.arduino15/packages/CubeCell/hardware/CubeCell/1.0.0 -``` - -- Mac - -```text -/Users/XXXXX/Library/Arduino15/packages/CubeCell/hardware/CubeCell/1.0.0 -``` - -#### Verify LoRaWAN Data Rate - -Within an editor of your choice open the file path formed by prepending the above described platform -specific top level directory structure to the following file: - -```text -libraries/LoRa/src/LoRaWan_APP.cpp (Linux/Mac) -libraries\LoRa\src\LoRaWan_APP.cpp (Windows) -``` - -Within this file look for - -``` -#define defaultDrForNoAdr -``` - -Depending on the version of the Heltec runtime that is installed this default may be set to DR_0, -DR_3, DR_5 or some other value. Note: DR_5 is not valid for US915, the North American market. - -The defaultDrForNoAdr setting is tied directly to the maximum size of the data packet you are -transferring. - -NOTE: If you try to transfer a packet that is larger than this setting allows, your device may -successfully join the network but the data transmit will fail silently. - -| Data Rate \(DR\) | Max Application Payload | -| :--------------- | :---------------------- | -| DR_0 | 11 bytes | -| DR_1 | 53 bytes | -| DR_2 | 125 bytes | -| DR_3 | 242 bytes | -| DR_4 | 242 bytes | -| DR_5 - 7 | Not Valid | - -Update the defaultDrForNoAdr as appropriate for your application needs. - -The above values are valid for the US902-928MHz region\(North America\), the values may differ for -other LoRa regions, which you can find -[here](https://lora-alliance.org/resource-hub/rp2-101-lorawanr-regional-parameters). - -#### Dynamic Data Rate Change - -If your application needs to change the current uplink data rate dynamically and Adaptive Data Rate -(ADR) is not enabled, one can call the - -``` -LoRaWAN.setDataRateForNoADR(int8_t dataRate) -``` - -API within your sketch. If you do call this API it must be called after the LoRaWAN.init() within -your sketch for the change to be effective. - -#### LoRaWAN preamble size - -There are some versions of the Heltec runtime libraries that may set a LoRaWAN preamble size that is -incompatible with the current LoRaWan specification. If the preamble size is not set correctly your -device cannot join the network. - -This should be verified in the region specific file corresponding to the region your device is -targeting. Be sure to prepend the above described platform specific top level directory structure. - -The following is the file that must be checked if targeting region US915. Within an editor of your -choice open the file path formed by prepending the above described platform specific top level -directory structure to the following file: - -```text -cores/asr650x/loramac/mac/region/RegionUS915.c (Linux/Mac) -cores\asr650x\loramac\mac\region\RegionUS915.c (Windows) -``` - -Within this file locate the line below, the 7th parameter which might be 14 should be changed to -either 8 or 16. Either value will work. Earlier versions of the runtime may have this value set to -14 which is "not" correct. - -Change: - -```text -Radio.SetTxConfig( MODsEM_LORA, phyTxPower, 0, bandwidth, phyDr, 1, 14, false, true, 0, 0, false, 3e3 ); -``` - -To: - -```text -Radio.SetTxConfig( MODEM_LORA, phyTxPower, 0, bandwidth, phyDr, 1, 8, false, true, 0, 0, false, 3e3 ); -``` - -Heltec support has been notified of these issues, hopefully a future release of those libs will -resolve the issues. - -### Install Serial Driver - -Find Directions on Heltec's website -[here](https://heltec-automation-docs.readthedocs.io/en/latest/general/establish_serial_connection.html). - -### Set Project Configuration Options - -The following options are set via the Arduino IDE Tools menu: - -#### Select Board - -If you are using the HTCC-AB02 flavor of Heltec board - -- Select Tools -> Board: ->CubeCell-Board \(HTCC-AB02\) - -If you are using the HTCC-AB02S GPS enabled flavor of Heltec board - -- Select Tools -> Board: ->CubeCell-GPS \(HTCC-AB02S\) - -#### Select LoraWAN Configuration Options - -Arduino IDE: Until you are familiar with their configuration behavior it is recommended you set the -board options as follows: - -- Select Tools -> LORAWAN_REGION: -> REGION_US915 -- Select Tools -> LORAWAN_CLASS: -> CLASS_A -- Select Tools -> LORAWAN_NETMODE: -> OTTA -- Select Tools -> LORAWAN_ADR: -> OFF -- Select Tools -> LORAWAN_UPLINKMODE: -> UNCONFIRMED -- Select Tools -> LORAWAN_Net_Reservation: -> OFF -- Select Tools -> LORAWAN_AT_SUPPORT: -> OFF -- Select Tools -> LORAWAN_AT_RGB : -> ACTIVE -- Select Tools -> LoRaWan\_ Debug Level : -> FREQ&&DIO \(for most verbose messages\) - -### Programming **Example Sketch** - -Now that we have the required Arduino board support and library installed, lets program the board -with the provided example sketch. - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://github.com/helium/longfi-arduino/blob/master/Heltec-CubeCell-Board/longfi-us915/longfi-us915.ino), -copy and paste the entirety of it. - -Next we'll need to fill in the AppEUI\(msb\), DevEUI\(msb\), and AppKey\(msb\), in the sketch, which -you can find on the device details page on Console. Be sure to use the formatting buttons to match -the endianess and formatting required for the sketch, shown below. - - -) - -At the top of the sketch, replace the three **FILL_ME_IN** fields, with the matching field from -Console, example shown below. - - - -### Upload Sketch - -We're finally ready to upload our sketch to the board. In the Arduino IDE, click the right arrow -button, or navigate to \(**Sketch > Upload\),** to build and upload your new firmware to the -board. You should see something similar to the image below at the bottom of your Arduino IDE, when -the upload is successful. - - -) - -### Using HTCC-AB02S Board With GPS Capable Sketch - -If you are using the HTCC-AB02S board with a sketch that is GPS enabled but find the device is -unable to obtain a GPS lock you can try changing the GPS data satellite source via the GPS class -Air530.setMode\(\) API. Add the Air530.setmode\(\) to the setup\(\) method of your sketch. - -```text -// MODE_GPS - US, -// MODE_GPS_BEIDOU - Chinese - This is the default -// MODE_GPS_GLONASS - Russian -// set what works best for your connectivity, for example: -Air530.setmode(MODE_GPS); -``` - -### Patching ADR Functionality - -The CubeCell may have issues joining the network with ADR OFF. If you're using ADR ON, you may also -encounter an issue where your CubeCell stops successfully sending packets after a few minutes. This -is caused by the CubeCell firmware's ADR behavior, and may happen if your payload is above the DR0 -maximum size \(11 bytes\). - -To patch the CubeCell firmware, find and open the `RegionUS915.c` file in the firmware directory. On -macOS, an example path would be -`~/Library/Arduino15/packages/CubeCell/hardware/CubeCell/1.0.0/cores/asr650x/loramac/mac/region/RegionUS915.c`. - -Find the following lines in the file and comment them out: - -```text -// Decrease the datarate -getPhy.Attribute = PHY_NEXT_LOWER_TX_DR; -getPhy.Datarate = datarate; -getPhy.UplinkDwellTime = adrNext->UplinkDwellTime; -phyParam = RegionUS915GetPhyParam(&getPhy); -datarate = phyParam.Value; -``` - -This will prevent the CubeCell from reducing the Data Rate over time and allow you to send larger -packets on a repeated, prolonged basis. - -### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. We first need to select -the serial port again, but this time it will be a **different port** than the one we selected to -communicate with the bootloader. Once again, navigate to \(**Tools > Port: COM\#/ttyACM\#**\), -but make sure the serial device, either COM\# or ttyACM\#, is different! Next navigate to \(**Tools -> Serial Monitor**\), you should begin to see output similar to below. - - -) - -Now let's head back to [Helium Console](https://console.helium.com/) and look at our device page, -you should see something similar to the screenshot below. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our Integrations docs -[here](/use-the-network/console/integrations). diff --git a/docs/use-the-network/devices/development/heltec/cubecell-dev-board/cubecell-dev-board.mdx b/docs/use-the-network/devices/development/heltec/cubecell-dev-board/cubecell-dev-board.mdx deleted file mode 100644 index 3734a04f5..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-dev-board/cubecell-dev-board.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: cubecell-dev-board -title: Htcc-Ab01 -pagination_label: Cubecell Dev Board -sidebar_label: Htcc-Ab01 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-dev-board ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AB01 - - - -## Introduction - -The Heltec Cubecell HTCC AB01 is Heltec's popular ASR605x(ARM® Cortex® M0+ Core) based LoRa -development board with built in USB and battery charging. - -### Resources - -- [Product Page](https://heltec.org/project/htcc-ab01/) -- [Manual](https://heltec-automation-docs.readthedocs.io/en/latest/cubecell/index.html) -- [US Retailer - Parley Labs](https://shop.parleylabs.com/collections/heltec-cubecell) - -### Specifications - -#### Dimensions: - -- width: 25 mm -- length: 41.5 mm -- height: 7.6 mm - -#### Battery: - -- type: Lithium -- replaceable: True - -### Firmware Quickstart Guides - -- [Arduino Guide](/use-the-network/devices/development/heltec/cubecell-dev-board/arduino) -- [PlatformIO Guide](/use-the-network/devices/development/heltec/cubecell-dev-board/platformio) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-dev-board/platformio.mdx b/docs/use-the-network/devices/development/heltec/cubecell-dev-board/platformio.mdx deleted file mode 100644 index 2ce46b4c7..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-dev-board/platformio.mdx +++ /dev/null @@ -1,716 +0,0 @@ ---- -id: platformio -title: PlatformIO -pagination_label: PlatformIO -sidebar_label: PlatformIO -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-dev-board/platformio ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Getting Started With Helium, PlatformIO and Heltec CubeCell - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -The Heltec CubeCell HTCC AB0x are one of Heltec's line of popular ASR605x(ARM® Cortex® M0+ Core) -based LoRa development boards with built in USB and battery charging. - -## Introduction - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -This guide will walk through installing PlatformIO and deploying a Helium Arduino program on a -target device. - -[PlatformIO ](https://platformio.org/)is a cross-platform, cross-architecture, multiple framework, -professional tool for embedded systems engineers and for software developers who write applications -for embedded products. - -Here, we will detail the steps required to integrate a specific board type, one of the -[Heltec CubeCell AB0x](https://heltec.org/proudct_center/lora/cubecell/) family of boards. - -However, this guide can be also used to on-board many other types of target devices. In most cases -one can just substitute your target device in place of the CubeCell developer board. - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your PlatformIO IDE environment -- How to create, build, upload a simple embedded application -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, you will need one of the following Heltec development boards. The Helium community -has experience with the AB01, AB02x and CubeCell Capsule line boards. Subsequent follow on products -may work but have not been tested - -### Hardware - -- [Heltec CubeCell Development Boards (AB01, AB02x, Capsule)](https://heltec.org/proudct_center/lora/cubecell/) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -PlatformIO is not a standalone IDE, it installs as an extension to Microsoft VSCode. The Helium -Console is a cloud based device management tool that we will use to enable our device access to the -Helium network. There is no installation required however one will need to create a user account -with the Helium Console. - -- [VSCode \(IDE)](https://code.visualstudio.com/) - - [PlatformIO \(VScode Extension)](https://platformio.org/) -- [Helium Console](https://www.helium.com/console) - -## Hardware Setup - -#### Attaching the LoRa Antenna - -Your board should have come with a U.FL antenna. All you have to do is attach it to the U.FL port on -the developer board. The method of attachment varies depending on the target board. - -In the case of our example Heltec CubeCell board, some versions of the board may have more than one -U.FL port, if this is the case generally the LoRa antenna attaches to the port that is on the same -side of the board as contains the USB port connector. In all cases it is best to verify the proper -connector with the board manufacturer. - -#### Connect Target Board to Development PC - -The target boards are typically connected to the host computer via a USB 2.0 A-Male to Micro B -cable. Again this may vary depending upon your target board. - -#### Install Develop Machine Serial Driver - -Some operating systems, especially Windows, will require the installation of hardware specific USB -device driver code. Most hardware developer board vendors will supply directions on how this can be -accomplished. - -For our example installation directions can be found on Heltec's documentation website -[here](https://heltec-automation-docs.readthedocs.io/en/latest/general/establish_serial_connection.html). - -## Software Setup - -Setting up the VSCode/PlatformIO IDE environment while not complex, does require several steps that -are independent of your target device. We will walk through these initial setup steps before trying -to integrate Helium network access code into the mix. - -### Installing PlatformIO - -Using the VSCode instructions found [here](https://code.visualstudio.com/) download and install -Microsoft's Visual Studio Code. PlatformIO IDE is built on top of VSCode as an extension. Once the -VSCode is installed: - -1. Open VSCode Extension Manager by clicking on the Extensions icon on the left side of the main - view. -2. Within the Extensions Marketplace search for official PlatformIO IDE extension -3. Install PlatformIO IDE. - \([https://marketplace.visualstudio.com/items?itemName=platformio.platformio-ide](https://marketplace.visualstudio.com/items?itemName=platformio.platformio-ide)\) - - - -It is highly recommended to give the quick-start guide a read. It will help you navigate the -unfamiliar interface. -[https://docs.platformio.org/en/latest/integration/ide/vscode.html\#quick-start](https://docs.platformio.org/en/latest/integration/ide/vscode.html#quick-start) - -In this tutorial, as an example, we will be using the -[Heltec CubeCell AB0x](https://heltec.org/proudct_center/lora/cubecell/). One can substitute your -target device as needed as you progress through these steps. - -Once PlatformIO is installed, you should be welcomed to VSCode with the following "PIO Home" screen: - - - -If not already open, the PlatformIO "Home" view can be opened by clicking on the house icon within -the VScode status bar. - - - -### Creating a New PlatformIO Project - -If you have not have not already used PlatformIO to build, upload and verify the operation of a -sample application it is best familiarize yourself with the basic use of PlatformIO before adding -the complexity of Helium network access code to the mix. - -If you are familiar and confident with the steps required you can continue at "Sample Helium Network -Access Code" by clicking [here](#ADD-HELIUM-NETWORK-CODE). - -The following steps will walk you through what is required to: - -- create a template project -- inspect the default source file, main.cpp as well as the primary project configuration file, - platformio.ini -- build the project and inspect the build log output -- upload the sample binary to the target development board. -- inspect serial output debug information. - -Before proceeding with actual code that will connect to the Helium network, create a sample, -template project. - -#### Open "New Project Wizard" - Select project name and board - -- Within the "PIO Home" view click on "New Project". - -- At the "Project Wizard" dialog enter a name for your project in the "Name" field. -- Within the "Board" field select the appropriate target board by entering the name of the - manufacturer, "Heltec" for our example. The PlatformIO auto search feature should present you with - a known list of supported boards. In our case we enter "Heltec" and choose the "Heltec - CubceCell-GPS (HTCC-AB02S)" from the supplied list. - -Note: If your target device is different start to enter the device manufacturer in the "Board" -field, PlatformIO will attempt to fill in the entry with those devices that it is aware of. -Hopefully your device will be presented in the list. If so, select it. - - - -#### Select framework and project location - -- Select the desired runtime framework from the "Framework" drop down. Target devices may support - one, and possibly more than one, runtime framework. Choose what is appropriate for your target. At - present only "Arduino" is supported for the board we have selected for our example. -- For location, if the checkbox is selected the project will be created within the default - PlatformIO workspace, which is sufficient for our purposes. -- Click the "Finish" button to create the project. ( You may need to scroll down the wizard window - to expose the Finish button) - -Note: The time taken to create a project will vary depending on whether or not the selected platform -and framework files have been previously downloaded. When the project has been created it should be -shown within the PlatformIO Explorer view typically found on the left side of the IDE. - - - -Typical project explorer view. - -#### Default project main.cpp - -If you are familiar developing within the Arduino IDE, main.cpp is much the same as the Arduino -\*.ino. It also contains default setup() and loop() functions. - -PlatformIO also adds a required "\#include " statement. This is an important/necessary -difference between PlatformIO and Arduino IDEs. - - - -#### platformio.ini - project configurations - -Let's take a look at the platformio.ini file in the root of our new project. This is where one -defines project configuration definitions. In the Arduino world one would do this via the IDE tool -bar selections. - -Note: when this file is modified the entire project will be rebuilt when the project is next built -or uploaded. - - - -Here we see the platformio.ini file that was created as a result of the running the New Project -wizard targeting our CubeCell board. - -#### Build the target device application - -Now that the template project has been created it's time to build the device application. Within -PlatformIO the "Build" button is the check-mark found within the bottom status bar. Clicking on this -button should start the build process. - - - -#### Inspect the build output - -Due to the defines within platformio.ini, PlatformIO is able to determine the project board and -framework dependencies. Any missing dependencies are automatically installed at build time, thus -this process may be seen in the build output. This feature allows us to add libraries into our -platformio.ini file, which will then be downloaded for us, if needed, at build time. - -The build process results can be found within the "Terminal View" typically found at the bottom of -the VSCode window. Much like with Arduino, the build output will dump the calculated amount of Ram -and Flash memory used by your application. - - - -Start of the build output displaying configuration information. - - - -Tail end of build log showing Ram and Flash usage. There is also a Problems output view that may -help when trying to resolve build issues. - -#### List of attached devices - -If, within the "PIO Home" view, you select the "Devices" icon on the left, you will see listed any -attached physical devices as well as their associated comm ports: - - - -The list should reflect your target device. - -#### Uploading binary to target device - -Now that the code has built successfully, if a target device is attached to your computer the -resulting binary can be uploaded to the target device. - -The method of uploading the binary to your device may vary depending on the target device. -PlatformIO will attempt to configure upload options appropriate for the chosen board. If the default -configuration does not work in your instance detailed information can be found within the PlatformIO -documentation -[here](https://docs.platformio.org/en/latest/projectconf/section_env_upload.html?highlight=upload) -or within your target board vendors documentation set. - -We will attempt to include such information along with any sample project code we provided if the -procedure is different from that described here. - -``` -For instance our target, the CubeCell has a peculiar -requirement: -Prior to attempting to upload your binary make sure -any terminal session that might be attached to the -debug comm port has been deleted. Occasionally but not -always, PlatformIO will automatically close the comm -port. If it does not upload errors will occur. -``` - - - -Click on the Upload button within the bottom Status bar. - -Below you will see a typical output as the binary is uploaded to the target board. - - - -If you have made it this far then we know your environment can build and upload a device -application. Now it's time to connect to the Helium network. - -### Helium Console - Create Device - -In order for a target device to communicate via the Helium Network a user account must first be -created. Once the user account is created then a console device must be created. - -When creating the console device, make note of the DevEUI, AppEUI, and AppKey device credentials. -These are used to connect to the network and will need to be inserted into the device application -code below. A console quick start guide can be found [here](/use-the-network/console/quickstart). - -### Sample Helium Network Access Code - -If you have not created a simple template project and you want to a try one of the samples you can -copy a sample into your workspace where it should build without error. A full PlatformIO project can -be found -[here](https://github.com/helium/longfi-platformio/blob/master/Heltec-CubeCell-Board/examples/cubecell-helium-us915-basic). -Alternatively you can update the template project created above by continuing the following steps. - -#### Update main.cpp - -Now that we have the required board and library runtime support installed, let's program the board -with an example Helium network enabled application. - -To update the sample application created above: - -- open, within PlatformIO, your projects src/main.ccp file -- replace this template main.cpp with the content of the sample application found - [here](https://github.com/helium/longfi-platformio/blob/master/Heltec-CubeCell-Board/examples/cubecell-helium-us915-basic/src/main.cpp). - Copy and paste the entirety of it. - -#### Add device credentials - -Next we'll need replace the placeholder AppEUI, DevEUI, and AppKey values found within the sample -program with the real values found on the target device page within the Helium Console. - -``` -Note: - The endianess required for these credentials varys - depending on the LoRaWAN runtime library implementation. - Using a custom library implementation will require an - understanding of that libraries endian requirement, big - endian or little endian. -``` - -For our CubeCell example all values are big endian \(msb\), most significant bit on the left. - - - -At the top of the main.cpp file, replace the three **FILL_ME_IN** fields, with the matching field -from the Helium Console, example shown below. Your numbers will be different depending on what the -console creates when you add your target device. - - - -#### Verify LoRaWAN channels mask - -Runtime library implementations are designed to work across several LoRaWAN regions and networks. -The firmware will attempt to join the network using various frequency sub-bands, defined by a -channel mask, until the join succeeds. It is recommended that you change the default channel mask to -a value that will help the join process complete connection to the Helium network in a more timely -manner. The process, where and how, to update this channel mask will vary depending on the LoRaWAN -runtime implementation - -For our example using the Heltec CubeCell and it's runtime the following piece of code has been -incorporated into the sample projects. Refer to a sample to determine where this code should reside, -generally near the above mentioned credentials is fine. - -``` -/*LoraWan channelsmask, default channels 0-7*/ -uint16_t userChannelsMask[6]={ 0xFF00,0x0000,0x0000,0x0000,0x0000,0x0000 }; -``` - -#### platformio.ini - project configurations - -For our sample application we need a few configuration items added to the project platformio.ini -file. One set is the project defaults, the next is serial debug monitor configurations and then -LoRaWAN configurations. - -Complete documentation of platformio.ini content can be found -[here](https://docs.platformio.org/en/latest/projectconf/index.html). Serial debug monitor specific -items [here](https://docs.platformio.org/en/latest/projectconf/section_env_monitor.html). - -Note: The comment character for this file type is the semicolon. - -For our example CubeCell project we update the projects platformio.ini with the content from the -sample project: - -- open, within PlatformIO, your projects platformio.ini file -- replace this template file with the content found - [here](https://github.com/helium/longfi-platformio/blob/master/Heltec-CubeCell-Board/examples/cubecell-helium-us915-basic/platformio.ini). - Copy and paste the entirety of it. - -Once you have become more familiar with the LoRaWAN/Helium network feel free to experiment with -different configuration settings possible within platformio.ini. - -#### Build the device application - -After updating the main.cpp and platformio.ini files it's time to build the device application. -Within PlatformIO the "Build" button is the check-mark found within the bottom status bar. Clicking -on this button should start the build process. - -#### Inspect the build results - -The build output results can be found within the "Terminal View" typically found at the bottom of -the VSCode window. Verify the build completed successfully. - -#### Possible Arduino to PlatformIO porting issues - -When porting Arduino sketches to PlatformIO you may find errors such as undefined functions. These -may be functions that are called by setup() or loop() or other custom functions prior to them being -defined. This is a side effect of the different C version of C compilers used with PlatformIO vs -Arduino. In this instance we just need to define the function prototype before the function is -actually called. Another compatibility issue is that unlike Arduino IDE, you must include Arduino.h -at the start of your C file if you are using Arduino defined constructs. Generally the compatibility -issues are minor. - -#### Verify Heltec runtime configurations. - -Running the previous build operation will ensure the Heltec runtime dependencies have been -downloaded. At the time of this writing some versions of Heltec's runtime libraries have set default -configuration variables to values that are incompatible with the Helium network, especially when the -Heltec device is configured targeting the North American market. Please follow this -[link](#HTCC-MANUAL-RUNTIME-UPDATES) within this document and verify the file content. Return here -after verification. - -If changes needed to be made it is best to run a "Clean" build process by clicking on the Trash Can -button on the status bar followed by a "Build" to ensure the changes have been picked up properly. - -#### Upload Binary to target device - -If the build process completed successfully, upload the binary to the target device via the "Upload" -(right pointing arrow) button found on the status bar - -NOTE: Prior to attempting to upload your binary make sure any terminal session that might be -attached to the debug comm port has been deleted. Occasionally but not always, PlatformIO will -automatically close the comm port, if it does not upload errors will occur. - - - -Successful upload example, your results will vary. - -#### Viewing Target Device Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. The -PlatformIO Serial Monitor can be used to view the serial debug output from the board. You will -recall that we set the serial port configurations within the platformio.ini file for our project. - -To open the serial monitor click on the "Serial Monitor" button within the status bar. - - - -You should begin to see output similar to below. - - - -You can use any virtual terminal emulator for this purpose, but recall certain Heltec boards seem to -require the terminal emulator be disconnected from the target device prior to attempting to upload a -new binary. - -#### Helium Console Uplinks - -Now let's head back to the [Helium Console](https://console.helium.com/) and login to your account. -Once logged in select the "Devices" item on the left, then select the target device previously -created. Scroll down a bit on the device page and you should see something similar to the screenshot -below. - - - -Activation messages are those seen when the device first attempts to join the network. Downlink -messages are those delivered from the network to your target device. Uplink messages are those -messages delivered from your target device to the Helium network. - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our Integrations docs -[here](/use-the-network/console/integrations). - -### Device Application Code Debugging - -Unfortunately at this time CubeCell does not support a debug probe that enjoys built-in support -within PlatformIO. Please visit the Heltec community forum found [here](http://community.heltec.cn/) -for help with external debugger questions. - -### Misc device application hints - -Follow this [link](#HTCC-APPLICATION-HINTS) within this guide for useful application enhancements. - -### Manual updates to the Heltec runtime libraries - -Some versions of Heltec's runtime libraries have set default configuration variables to values that -are incompatible with the Helium network, especially when the Heltec device is configured targeting -the North American market. The following discusses Heltec runtime files that must be inspected to -ensure compatibility. The exact location of these files will depend on which operating system you -are using, Windows, Linux, or Mac. The typical top level location of the runtime libraries is shown -below for each operating system. From there the following discussions will present to you the file -locations within these top level directories/folders. Please note the Heltec library version numbers -are expected to change as time goes on. XXXXX denotes your specific user id. - -#### PlatformIO IDE Heltec runtime library locations: - -```text -Windows: C:\Users\XXXX\.platformio\packages\framework-arduinoasrmicro650x\ - -Linux: /home/XXXXX/.platformio/packages/framework-arduinoasrmicro650x/ - -Mac OS: /Users/XXXXX/.platformio/packages/framework-arduinoasrmicro650x/ -``` - -#### Verify LoRaWAN Data Rate - -Within an editor of your choice open the file path formed by prepending the above described platform -specific top level directory structure to the following file: - -```text -libraries/LoRa/src/LoRaWan_APP.cpp (Linux/Mac) -libraries\LoRa\src\LoRaWan_APP.cpp (Windows) -``` - -Within this file look for - -``` -#define defaultDrForNoAdr -``` - -Depending on the version of the Heltec runtime that is installed this default may be set to DR_0, -DR_3, DR_5 or some other value. Note: DR_5 is not valid for US915, the North American market. - -The defaultDrForNoAdr setting is tied directly to the maximum size of the data packet you are -transferring. - -NOTE: If you try to transfer a packet that is larger than this setting allows, your device may -successfully join the network but the data transmit will fail silently. - -| Data Rate \(DR\) | Max Application Payload | -| :--------------- | :---------------------- | -| DR_0 | 11 bytes | -| DR_1 | 53 bytes | -| DR_2 | 125 bytes | -| DR_3 | 242 bytes | -| DR_4 | 242 bytes | -| DR_5 - 7 | Not Valid | - -Update the defaultDrForNoAdr as appropriate for your application needs. - -The above values are valid for the US902-928MHz region\(North America\), the values may differ for -other LoRa regions, which you can find -[here](https://lora-alliance.org/resource-hub/rp2-101-lorawanr-regional-parameters). - -#### Dynamic Data Rate Change - -If your application needs to change the current uplink data rate dynamically and Adaptive Data Rate -(ADR) is not enabled, one can call the - -``` -LoRaWAN.setDataRateForNoADR(int8_t dataRate) -``` - -API within your sketch. If you do call this API it must be called after the LoRaWAN.init() within -your sketch for the change to be effective. - -#### Verify LoRaWAN preamble size - -There are some versions of the Heltec runtime libraries that may set a LoRaWAN preamble size that is -incompatible with the current LoRaWan specification. If the preamble size is not set correctly your -device cannot join the network. This should be verified in the region specific file corresponding to -the region your device is targeting. Be sure to prepend the above described platform/IDE specific -top level directory structure. - -The following is the file that must be checked if targeting region US915. Within an editor of your -choice open the file path formed by prepending the above described IDE/platform specific top level -directory structure to the following file: - -``` -Linux/Mac OS: cores/asr650x/loramac/mac/region/RegionUS915.c - -Windows: cores\asr650x\loramac\mac\region\RegionUS915.c -``` - -Within this file locate the line below, the 7th parameter which might be 14 should be changed to -either 8 or 16. Either value will work. Earlier versions of the runtime may have this value set to -14 which is "not" correct. Change: - -```text -Radio.SetTxConfig( MODsEM_LORA, phyTxPower, 0, bandwidth, phyDr, 1, 14, false, true, 0, 0, false, 3e3 ); -``` - -To: - -```text -Radio.SetTxConfig( MODEM_LORA, phyTxPower, 0, bandwidth, phyDr, 1, 8, false, true, 0, 0, false, 3e3 ); -``` - -Heltec support has been notified of these issues, hopefully a future release of those libs will -resolve the issues. - -### Patching ADR Functionality - -The CubeCell may have issues joining the network with ADR OFF. If you're using ADR ON, you may also -encounter an issue where your CubeCell stops successfully sending packets after a few minutes. This -is caused by the CubeCell firmware's ADR behavior, and may happen if your payload is above the DR0 -maximum size \(11 bytes\). - -To patch the CubeCell firmware, find and open the `RegionUS915.c` in the following location. - -```text -Windows: C:\Users\XXXX\.platformio\packages\framework-arduinoasrmicro650x\cores\asr650x\loramac\mac\region\RegionUS915.c - -Linux: ~/.platformio/packages/framework-arduinoasrmicro650x/cores/asr650x/loramac/mac/region/RegionUS915.c - -Mac OS: /Users/XXXXX/.platformio/packages/framework-arduinoasrmicro650x/cores/asr650x/loramac/mac/region/RegionUS915.c -``` - -Find the following lines in the file and comment them out: - -```text -// Decrease the datarate -getPhy.Attribute = PHY_NEXT_LOWER_TX_DR; -getPhy.Datarate = datarate; -getPhy.UplinkDwellTime = adrNext->UplinkDwellTime; -phyParam = RegionUS915GetPhyParam(&getPhy); -datarate = phyParam.Value; -``` - -This will prevent the CubeCell from reducing the Data Rate over time and allow you to send larger -packets on a repeated, prolonged basis. - -### Device application hints - -#### Using HTCC-AB02S Board with GPS Capable Sketch - -If you are using the HTCC-AB02S board with a program that is GPS enabled but find the device is -unable to obtain a GPS lock you can try changing the GPS data satellite source via the GPS class -Air530.setMode\(\) API. Add the Air530.setmode\(\) to the setup\(\) method of your sketch. - -```text -// MODE_GPS - US, -// MODE_GPS_BEIDOU - Chinese - This is the default -// MODE_GPS_GLONASS - Russian -// set what works best for your connectivity, for example: -Air530.setmode(MODE_GPS); -``` - -A sample GPS enabled project for the CubeCell can be found -[here](https://github.com/helium/longfi-platformio/tree/master/Heltec-CubeCell-Board/examples/cubecell-helium-us915-gps). - -#### Dynamically altering Data Rate - -A recent change to the Heltec runtime exposes an API interface a device application can use to alter -the current LoRaWAN data rate. - -```text -LoRaWAN.setDataRateForNoADR(int8_t dataRate); -``` - -This should be done sometime after LoRaWAN.init() is called. diff --git a/docs/use-the-network/devices/development/heltec/cubecell-gps-6502.mdx b/docs/use-the-network/devices/development/heltec/cubecell-gps-6502.mdx deleted file mode 100644 index 0bc0652e6..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-gps-6502.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: cubecell-gps-6502 -title: Htcc-Ab02S -pagination_label: Cubecell GPS 6502 -sidebar_label: Htcc-Ab02S -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-gps-6502 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AB02S - -HTCC-AB02S is a Dev-Board. Already integrated AIR530 GPS module, friendly designed for developers, -easy to verify communication solutions. - - - -### Resources - -- [Product Page](https://heltec.org/project/htcc-ab02s/) -- [Datasheet](https://heltec.org/project/htcc-ab02s/#1552557147424-7f1ec-5c652144-e1d6af18-f963) - -### Specifications - -#### Dimensions: - -- width: 27.9 mm -- length: 55.9 mm -- height: 9.5 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-module-plus.mdx b/docs/use-the-network/devices/development/heltec/cubecell-module-plus.mdx deleted file mode 100644 index 23f371cd8..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-module-plus.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: cubecell-module-plus -title: Htcc-Am02 -pagination_label: Cubecell Module Plus -sidebar_label: Htcc-Am02 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-module-plus ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AM02 - -HTCC-AM02 is a Module. Supports AT transparent transmission commands, can be directly integrated -into the application circuit. - - - -### Resources - -- [Product Page](https://heltec.org/project/htcc-am02/) -- [Datasheet](https://heltec.org/project/htcc-am02/#1552557147424-7f1ec-5c652144-e1d68312-5a88) - -### Specifications - -#### Dimensions: - -- width: 20.4 mm -- length: 20.4 mm -- height: 3 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-module.mdx b/docs/use-the-network/devices/development/heltec/cubecell-module.mdx deleted file mode 100644 index 55d4b7f8b..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-module.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: cubecell-module -title: Htcc-Am01 -pagination_label: Cubecell Module -sidebar_label: Htcc-Am01 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-module ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AM01 - -HTCC-AM01 is a Module. Supports AT transparent transmission commands, can be directly integrated -into the application circuit. - - - -### Resources - -- [Product Page](https://heltec.org/project/htcc-am01/) -- [Datasheet](https://heltec.org/project/htcc-am01/#1552557147424-7f1ec-5c652144-e1d6f6d7-e5b5) - -### Specifications - -#### Dimensions: - -- width: 18 mm -- length: 18 mm -- height: 3 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/cubecell-solar-sensor.mdx b/docs/use-the-network/devices/development/heltec/cubecell-solar-sensor.mdx deleted file mode 100644 index 9d36bac90..000000000 --- a/docs/use-the-network/devices/development/heltec/cubecell-solar-sensor.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: cubecell-solar-sensor -title: Htcc-Ac02 -pagination_label: Cubecell Solar Sensor -sidebar_label: Htcc-Ac02 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/cubecell-solar-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## HTCC-AC02 - -HTCC-AC02 is a LoRa end node sensor. With a complete enclosure and protection measures, it can be -deployed directly into real-world applications. - - - -### Resources - -- [Product Page](https://heltec.org/project/htcc-ac02/) -- [Datasheet](https://heltec.org/project/htcc-ac02/#1552557147424-7f1ec-5c652144-e1d60c7e-82e5) - -### Specifications - -#### Dimensions: - -- height: 67 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/lora-kit-151.mdx b/docs/use-the-network/devices/development/heltec/lora-kit-151.mdx deleted file mode 100644 index f6a5130c9..000000000 --- a/docs/use-the-network/devices/development/heltec/lora-kit-151.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: lora-kit-151 -title: Lora Kit 151 -pagination_label: Lora Kit 151 -sidebar_label: Lora Kit 151 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/lora-kit-151 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LoRa Kit 151 - -LoRa Kit 151 is Ultra-Low-Power and standard LoRaWAN protocol, - - - -### Resources - -- [Product Page](https://heltec.org/project/lora-kit-151/) -- [Datasheet](https://heltec.org/project/lora-kit-151/#1552557147424-7f1ec-5c651922-b0bb7876-1582) - -### Specifications - -#### Dimensions: - -- width: 25.5 mm -- length: 56.3 mm -- height: 7.8 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/lora-node-151.mdx b/docs/use-the-network/devices/development/heltec/lora-node-151.mdx deleted file mode 100644 index fcf9ecb55..000000000 --- a/docs/use-the-network/devices/development/heltec/lora-node-151.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: lora-node-151 -title: Lora Node 151 -pagination_label: Lora Node 151 -sidebar_label: Lora Node 151 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/lora-node-151 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LoRa Node 151 - -LoRa Node 151， adopting the STM32L151CCU6 MCU (support DFU mode) and SX127x LoRa chip, use 1/2 AA -Lithium chlorine sulfite battery - - - -### Resources - -- [Product Page](https://heltec.org/project/lora-node-151/) -- [Datasheet](https://heltec.org/project/lora-node-151/#1552557147424-7f1ec-5c651922-b0bb9d3c-7452) - -### Specifications - -#### Dimensions: - -- width: 24 mm -- length: 56.6 mm -- height: 20 mm - -#### Battery: - -- type: 1/2AA Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/turtle-board.mdx b/docs/use-the-network/devices/development/heltec/turtle-board.mdx deleted file mode 100644 index 72215e906..000000000 --- a/docs/use-the-network/devices/development/heltec/turtle-board.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: turtle-board -title: Turtle Board -pagination_label: Turtle Board -sidebar_label: Turtle Board -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/turtle-board ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Turtle Board - -The turnkey Turtle board solution can be used immediately. Support standard LoRaWAN protocol and -RadioShuttle protocol. - - - -### Resources - -- [Product Page](https://heltec.org/project/turtle-board/) -- [Datasheet](https://heltec.org/project/turtle-board/#1552557147424-7f1ec-5c651922-b0bb1778-6c4e) - -### Specifications - -#### Dimensions: - -- width: 31.5 mm -- length: 73.5 mm -- height: 24 mm - -#### Battery: - -- type: AAA Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/wifi-lora-32-v2/arduino.mdx b/docs/use-the-network/devices/development/heltec/wifi-lora-32-v2/arduino.mdx deleted file mode 100644 index b53588c42..000000000 --- a/docs/use-the-network/devices/development/heltec/wifi-lora-32-v2/arduino.mdx +++ /dev/null @@ -1,304 +0,0 @@ ---- -id: arduino -title: Arduino -pagination_label: Arduino -sidebar_label: Arduino -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/wifi-lora-32-v2/arduino ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Heltec WiFi LoRa 32 V2 Arduino Guide - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your environment -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, you will need the following: - -### Hardware - -- [Heltec WiFi LoRa 32 V2](https://heltec.org/project/wifi-lora-32/) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) -- [Helium Console](https://console.helium.com/) - -## Hardware Setup - -### Adding the Antenna - -Your board should have come with a U.FL antenna. All you have to do is attache it to the U.FL port -as shown in the image at the top of the guide. - -### Connect Board - -Next, lets connect our board to our computer with a USB 2.0 A-Male to Micro B cable. - -## Software Setup - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. - -- [Windows](https://www.arduino.cc/en/Guide/Windows) -- [Linux](https://www.arduino.cc/en/Guide/Linux) -- [Mac OSX](https://www.arduino.cc/en/Guide/MacOSX) - -### Arduino Board Support - -The Heltec WiFi LoRa 32 V2 requires one Arduino board support package. Follow the instructions below -to install. - -#### Arduino-ESP32 - -To install, open your Arduino IDE: - -1. Navigate to **\(File > Preferences\), \(Arduino > Preferences\) on MacOS.** -2. Find the section at the bottom called **Additional Boards Manager URLs:** - - - -1. Add this URL in the text box: - -```text -https://github.com/Heltec-Aaron-Lee/WiFi_Kit_series/releases/download/0.0.5/package_heltec_esp32_index.json -``` - -:::note - -The latest versions can be found on -[Heltec Automation Docs](https://heltec-automation-docs.readthedocs.io/en/latest/esp32%2Barduino/quick_start.html#via-arduino-board-manager) -website. - -::: - -1. Close the Preferences windows - -Next, to install this board support package: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **Heltec ESP32** -3. Select the newest version and click Install - - - -### Arduino Library - -To communicate with Helium's LoRaWAN network, we'll need to install two Arduino libraries. - -#### Heltec ESP32 - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **Heltec ESP32** into the search, select the version shown below, and - click Install. - - -) - -#### Heltec ESP32 LoRaWAN - -Download [this](https://github.com/HelTecAutomation/ESP32_LoRaWAN/archive/master.zip) find into the -directory below and unzip. - -```text -linux: /home/{user}/Arduino/libraries -windows: Documents\Arduino\libraries -mac os: Documents/Arduino/libraries -``` - -### Install Serial Driver - -Find Directions on Heltec's website -[here](https://heltec-automation-docs.readthedocs.io/en/latest/general/establish_serial_connection.html). - -### Select Board - -Arduino IDE: - -1. Select Tools -> Board: -> WiFi LoRa 32\(V2\) - -### Obtain Heltec License Key - -#### **Upload GetChipID example** - -Arduino IDE: - -1. Select File -> Examples -> ESP32 -> ChipID -> GetChipID -2. Select Tools -> Port: "COM\# or ttyACM\#" -3. Select Sketch -> Upload -4. Wait for Done uploading message -5. Select Tools -> Serial Monitor Serial Monitor Window -6. Select 115200 baud from bottom right dropdown. -7. You should see something that looks like this every second `ESP32 Chip ID = ############` -8. Save this Chip ID - -#### Obtain License Key with Chip ID - -1. Go to [resource.heltec.cn/search](http://resource.heltec.cn/search) -2. Enter ChipID -3. Save license field, will look like `0x########,0x#########,0x########,0x########` - -### Programming **Example Sketch** - -Now that we have the required Arduino board support and library installed, lets program the board -with the provided example sketch. - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://github.com/helium/longfi-arduino/blob/master/Heltec-WiFi-LoRa-32-V2/longfi-us915/longfi-us915.ino), -copy and paste the entirety of it. - -Next we'll need to fill in the AppEUI\(msb\), DevEUI\(msb\), and AppKey\(msb\), in the sketch, which -you can find on the device details page on Console. Be sure to use the formatting buttons to match -the endianess and formatting required for the sketch, shown below. - - - -At the top of the sketch, replace the three **FILL_ME_IN** fields, with the matching field from -Console, example shown below. - - -) - -Finally, we will paste in the License Key we obtained above to the sketch. Replace the values in -license[4] with the key obtained from [resource.heltec.cn/search](http://resource.heltec.cn/search) - -![image](https://user-images.githubusercontent.com/15837044/159526939-543bfb34-9651-426d-8089-85ce07ee477e.png) - -### Selecting Port - -Next, we need to select the correct Serial port in the Arduino IDE. Navigate to \(**Tools > Port: -COM\#/ttyACM\#**\). You will also see either **COM\# or /dev/ttyACM\#** depending on whether you are -on Windows, Mac, or Linux. If you do not see a port, please visit the Drivers section in -[Heltec's docs](https://heltec-automation-docs.readthedocs.io/en/latest/general/establish_serial_connection.html) -to make sure you have what's needed for your operating system. - -### Select LoRaWAN Region - -The last step before we upload our sketch is to select the correct LoRaWAN Region, navigate to -**\(Tools > LoRaWAN Region: > REGION_US915\).** - -### Required Change to Default DataRate - -In this example sketch, ADR is turned off, therefore you must manually set the desired data rate for -your payload size manually. This library uses a default data rate that is not supported by the -Helium Network so you must change it to one in the following range DR_0 - DR_4. To do this change -the default data rate on line 20 in the file found below for your operating system - -`linux: /home/{user}/Arduino/libraries/ESP32_LoRaWAN-master/src/ESP32_LoRaWAN.cpp` - -`windows: Documents\Arduino\libraries\ESP32_LoRaWAN-master\src\ESP32_LoRaWAN.cpp` - -`mac os: Documents/Arduino/librariesESP32_LoRaWAN-master/src/ESP32_LoRaWAN.cpp` - -**Change line 20 to:** - -```text -#define LORAWAN_DEFAULT_DATARATE DR_3 -``` - -:::info - -If you don't want to change data rate manually, -[Helium now supports ADR](/use-the-network/console/profiles/) - -::: - -### Upload Sketch - -We're finally ready to upload our sketch to the board. In the Arduino IDE, click the right arrow -button, or navigate to \(**Sketch > Upload\),** to build and upload your new firmware to the -board. You should see something similar to the image below at the bottom of your Arduino IDE, when -the upload is successful. - - -) - -### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. We first need to select -the serial port again, but this time it will be a **different port** than the one we selected to -communicate with the bootloader. Once again, navigate to \(**Tools > Port: COM\#/ttyACM\#**\), -but make sure the serial device, either COM\# or ttyACM\#, is different! Next navigate to \(**Tools -> Serial Monitor**\), you should begin to see output similar to below. - - -) - -Your device may take several minutes to join and begin to send uplink packets because the library is -designed to work in several LoRaWAN regions and networks. Because of this, the firmware will attempt -different sub-bands until it is successful. If you would like to change the default channel mask in -the library to speed up this process you can make the following change below the sketch. - -**Change line 59 to:** - -```text -uint16_t userChannelsMask[6]={ 0xFF00,0x0000,0x0000,0x0000,0x0002,0x0000 }; -``` - -Now let's head back to [Helium Console](https://console.helium.com) and look at our device page, you -should see something similar to the screenshot below. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our Integrations docs -[here](/use-the-network/console/integrations). diff --git a/docs/use-the-network/devices/development/heltec/wifi-lora-32-v2/wifi-lora-32-v2.mdx b/docs/use-the-network/devices/development/heltec/wifi-lora-32-v2/wifi-lora-32-v2.mdx deleted file mode 100644 index 94272a09e..000000000 --- a/docs/use-the-network/devices/development/heltec/wifi-lora-32-v2/wifi-lora-32-v2.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: wifi-lora-32-v2 -title: Wifi Lora 32 V2 -pagination_label: Wifi Lora 32 V2 -sidebar_label: Wifi Lora 32 V2 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/wifi-lora-32-v2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## WiFi LoRa 32 (V2) - -WiFi LoRa 32 is a classic IoT dev-board - - - -### Resources - -- [Product Page](https://heltec.org/project/wifi-lora-32/) -- [Manual](https://heltec-automation-docs.readthedocs.io/en/latest/esp32/quick_start.html) - -### Specifications - -#### Dimensions: - -- width: 25.5 mm -- length: 51 mm -- height: 10.6 mm - -#### Battery: - -- type: Lithium -- replaceable: True - -### Firmware Quickstart Guides - -[Arduino Guide](/use-the-network/devices/development/heltec/wifi-lora-32-v2/arduino) diff --git a/docs/use-the-network/devices/development/heltec/wireless-shell.mdx b/docs/use-the-network/devices/development/heltec/wireless-shell.mdx deleted file mode 100644 index 8f1aa6c83..000000000 --- a/docs/use-the-network/devices/development/heltec/wireless-shell.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: wireless-shell -title: Wireless Shell -pagination_label: Wireless Shell -sidebar_label: Wireless Shell -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/wireless-shell ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Shell - -“Wireless Shell” is an ESP32-PICO + SX1276 module. provide Wi-Fi, BLE and LoRa solution. - - - -### Resources - -- [Product Page](https://heltec.org/project/wireless-shell/) -- [Datasheet](https://heltec.org/project/wireless-shell/#1552557147424-7f1ec-5c651922-b0bb7490-e31d) - -### Specifications - -#### Dimensions: - -- width: 16.1 mm -- length: 38.4 mm -- height: 3.6 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/wireless-stick-lite.mdx b/docs/use-the-network/devices/development/heltec/wireless-stick-lite.mdx deleted file mode 100644 index 5d0e7f9eb..000000000 --- a/docs/use-the-network/devices/development/heltec/wireless-stick-lite.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: wireless-stick-lite -title: Wireless Stick Lite (Panda Board) -pagination_label: Wireless Stick Lite -sidebar_label: Wireless Stick Lite (Panda Board) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/wireless-stick-lite ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Stick Lite (Panda Board) - -Compare with Wireless Stick, “Wireless Stick Lite” has much better low power design (30uA in deep -sleep) - - - -### Resources - -- [Product Page](https://heltec.org/project/wireless-stick-lite/) -- [Datasheet](https://heltec.org/project/wireless-stick-lite/#1552557147424-7f1ec-5c651922-b0bbfe12-55e1) - -### Specifications - -#### Dimensions: - -- width: 24.8 mm -- length: 59.3 mm -- height: 8 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/heltec/wireless-stick.mdx b/docs/use-the-network/devices/development/heltec/wireless-stick.mdx deleted file mode 100644 index a06002d42..000000000 --- a/docs/use-the-network/devices/development/heltec/wireless-stick.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: wireless-stick -title: Wireless Stick (Gecko Board) -pagination_label: Wireless Stick -sidebar_label: Wireless Stick (Gecko Board) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/heltec/wireless-stick ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Stick (Gecko Board) - -Wireless Stick (Gecko Board) is high performance and small size - - - -### Resources - -- [Product Page](https://heltec.org/project/wireless-stick/) -- [Datasheet](https://heltec.org/project/wireless-stick/#1552557147424-7f1ec-5c651922-b0bbb94c-7398) - -### Specifications - -#### Dimensions: - -- width: 24.8 mm -- length: 59.3 mm -- height: 8 mm - -#### Battery: - -- type: Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4430.mdx b/docs/use-the-network/devices/development/mcci/catena4430.mdx deleted file mode 100644 index 0f466a205..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4430.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: catena4430 -title: Animal Activity Sensor -pagination_label: Catena4430 -sidebar_label: Animal Activity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4430 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Animal Activity Sensor - -Passive Infrared Sensor optimized for monitoring laboratory animals. Includes SD card storage, -pellet feeder interface, indicator lights. - - - -### Resources - -- [Product Page](https://mcci.io/buy-catena4430) -- [Video](https://youtu.be/nG8MmaR5dsA) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- pir -- digital input -- analog input -- battery -- barometer -- time - -#### Dimensions: - -- width: 23 mm -- length: 72 mm -- height: 25 mm - -#### Battery: - -- type: LiPo 3.7V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4450.mdx b/docs/use-the-network/devices/development/mcci/catena4450.mdx deleted file mode 100644 index 2c745c1e4..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4450.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: catena4450 -title: Mcci Catena® 4450 Node -pagination_label: Catena4450 -sidebar_label: Mcci Catena® 4450 Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4450 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4450 Node - -General purpose LPWAN building block, open source, user-programmable end-device with sensors and -support - - - -### Resources - -- [Product Page](https://mcci.io/Catena4450) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- digital input -- analog input -- battery -- barometer -- pulse count -- pulse frequency - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 35 mm - -#### Battery: - -- type: LiPo 3.7V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4460.mdx b/docs/use-the-network/devices/development/mcci/catena4460.mdx deleted file mode 100644 index 6b4cd023c..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4460.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: catena4460 -title: Mcci Catena® 4460 Node -pagination_label: Catena4460 -sidebar_label: Mcci Catena® 4460 Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4460 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4460 Node - -General purpose LPWAN building block, open source, user-programmable end-device with VOC sensor and -support - - - -### Resources - -- [Product Page](https://mcci.io/buy-catena4460) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- digital input -- analog input -- battery -- barometer -- tvoc - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 35 mm - -#### Battery: - -- type: LiPo 3.7V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4470.mdx b/docs/use-the-network/devices/development/mcci/catena4470.mdx deleted file mode 100644 index 0d6c6d405..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4470.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: catena4470 -title: Mcci Catena® 4470 Node With Modbus -pagination_label: Catena4470 -sidebar_label: Mcci Catena® 4470 Node With Modbus -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4470 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4470 Node with Modbus - -General purpose LPWAN building block, open source, user-programmable end-device with sensors, -Modbus, and support - - - -### Resources - -- [Product Page](https://mcci.io/Catena4470) -- [Datasheet](https://cdn.shopify.com/s/files/1/0873/5104/files/Catena4470-Datasheet.pdf?v=1610942439) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- digital input -- analog input -- battery -- barometer -- power -- auxiliary - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 35 mm - -#### Battery: - -- type: LiPo 3.7V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4610.mdx b/docs/use-the-network/devices/development/mcci/catena4610.mdx deleted file mode 100644 index 081182ec1..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4610.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: catena4610 -title: Mcci Catena® 4610 Node -pagination_label: Catena4610 -sidebar_label: Mcci Catena® 4610 Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4610 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4610 Node - -General purpose LPWAN building block, open source, user-programmable single-board end-device with -sensors and support - - - -### Resources - -- [Product Page](https://mcci.io/catena4610) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- digital input -- analog input -- battery -- barometer -- pulse count -- pulse frequency - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 5 mm - -#### Battery: - -- type: LiPo 3.7V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4612.mdx b/docs/use-the-network/devices/development/mcci/catena4612.mdx deleted file mode 100644 index dd0feb1c2..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4612.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: catena4612 -title: Mcci Catena® 4612 Node -pagination_label: Catena4612 -sidebar_label: Mcci Catena® 4612 Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4612 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4612 Node - -General purpose LPWAN building block, open source, user-programmable single-board end-device with -sensors and support - - - -### Resources - -- [Product Page](https://mcci.io/catena4612) -- [Datasheet](https://cdn.shopify.com/s/files/1/0873/5104/files/971001048c__Catena-4612-Datasheet.pdf?v=1610856170) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- digital input -- analog input -- battery -- barometer -- pulse count -- pulse frequency - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 5 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4618.mdx b/docs/use-the-network/devices/development/mcci/catena4618.mdx deleted file mode 100644 index 606ae86fe..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4618.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: catena4618 -title: Mcci Catena® 4618 Node -pagination_label: Catena4618 -sidebar_label: Mcci Catena® 4618 Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4618 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4618 Node - -General purpose LPWAN building block, open source, user-programmable single-board end-device with -sensors and support - - - -### Resources - -- [Product Page](https://mcci.io/catena4618) -- [Datasheet](https://cdn.shopify.com/s/files/1/0873/5104/files/Catena4618-Datasheet.pdf?v=1610912841) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- digital input -- analog input -- battery - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 5 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4618m201.mdx b/docs/use-the-network/devices/development/mcci/catena4618m201.mdx deleted file mode 100644 index 4972fe3aa..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4618m201.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: catena4618m201 -title: Mcci Catena® 4618 M201 Node -pagination_label: Catena4618M201 -sidebar_label: Mcci Catena® 4618 M201 Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4618m201 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4618 M201 Node - -High accuracy LPWAN building block, open source, user-programmable single-board end-device with -sensors and support - - - -### Resources - -- [Product Page](https://mcci.io/catena4618) -- [Datasheet](https://cdn.shopify.com/s/files/1/0873/5104/files/Catena4618-Datasheet.pdf?v=1610912841) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- digital input -- analog input -- battery - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 5 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4801.mdx b/docs/use-the-network/devices/development/mcci/catena4801.mdx deleted file mode 100644 index 69bc803f4..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4801.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: catena4801 -title: Mcci Catena® 4801 Modbus Node -pagination_label: Catena4801 -sidebar_label: Mcci Catena® 4801 Modbus Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4801 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4801 Modbus Node - -General purpose LPWAN building block, open source, user-programmable single-board end-device with -RS-485 Modbus interface and support - - - -### Resources - -- [Product Page](https://mcci.io/catena4801) -- [Datasheet](https://cdn.shopify.com/s/files/1/0873/5104/files/Catena4801-datasheet.pdf?v=1610922117) - -### Specifications - -#### Sensors: - -- auxiliary -- digital input -- analog input -- battery - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 5 mm - -#### Battery: - -- type: primary, 3.6V to 1.8V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/catena4802.mdx b/docs/use-the-network/devices/development/mcci/catena4802.mdx deleted file mode 100644 index 8bb26d79b..000000000 --- a/docs/use-the-network/devices/development/mcci/catena4802.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: catena4802 -title: Mcci Catena® 4802 Modbus/Sensor Node -pagination_label: Catena4802 -sidebar_label: Mcci Catena® 4802 Modbus/Sensor Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/catena4802 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCCI Catena® 4802 Modbus/Sensor Node - -General purpose LPWAN building block, open source, user-programmable single-board end-device with -RS-485 Modbus interface, I2C bridge with Qwicc connector, integrated temperature and humidity -sensor, and support - - - -### Resources - -- [Product Page](https://mcci.io/buy-catena4802) - -### Specifications - -#### Sensors: - -- auxiliary -- temperature -- humidity -- digital input -- analog input -- battery - -#### Dimensions: - -- width: 23 mm -- length: 51 mm -- height: 5 mm - -#### Battery: - -- type: primary, 5V to 2.2V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/model4811.mdx b/docs/use-the-network/devices/development/mcci/model4811.mdx deleted file mode 100644 index 9df4bce3d..000000000 --- a/docs/use-the-network/devices/development/mcci/model4811.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: model4811 -title: Model 4811 Remote Power Meter -pagination_label: Model4811 -sidebar_label: Model 4811 Remote Power Meter -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/model4811 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Model 4811 Remote Power Meter - -Real-time power monitor for commercial and residential buildings - - - -### Resources - -- [Product Page](https://mcci.io/m4811) -- [Datasheet](https://mcci.com/971001050c_model4811-powermeter-datasheet/) - -### Specifications - -#### Sensors: - -- power -- voltage -- current - -#### Dimensions: - -- width: 93 mm -- length: 106 mm -- height: 78 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/model4821.mdx b/docs/use-the-network/devices/development/mcci/model4821.mdx deleted file mode 100644 index 76cd85950..000000000 --- a/docs/use-the-network/devices/development/mcci/model4821.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: model4821 -title: Model 4821 Indoor Environmental Sensor (Bme280) -pagination_label: Model4821 -sidebar_label: Model 4821 Indoor Environmental Sensor (Bme280) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/model4821 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Model 4821 Indoor Environmental Sensor (BME280) - -temperature, humidity, barometer, light sensor for indoor spaces - - - -### Resources - -- [Product Page](https://mcci.io/m4821) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- barometer -- battery - -#### Dimensions: - -- width: 51 mm -- length: 76 mm -- height: 32 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/model4822.mdx b/docs/use-the-network/devices/development/mcci/model4822.mdx deleted file mode 100644 index bb3dd78f8..000000000 --- a/docs/use-the-network/devices/development/mcci/model4822.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: model4822 -title: Model 4822 Indoor Environmental Sensor (Sht31) -pagination_label: Model4822 -sidebar_label: Model 4822 Indoor Environmental Sensor (Sht31) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/model4822 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Model 4822 Indoor Environmental Sensor (SHT31) - -Higher-accuracy temperature, humidity, light sensor for indoor spaces (using Sensirion SHT31) - - - -### Resources - -- [Product Page](https://mcci.io/m4821) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- battery - -#### Dimensions: - -- width: 51 mm -- length: 76 mm -- height: 32 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/model4823.mdx b/docs/use-the-network/devices/development/mcci/model4823.mdx deleted file mode 100644 index 16b1e3b66..000000000 --- a/docs/use-the-network/devices/development/mcci/model4823.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: model4823 -title: Model 4823 Precision Indoor Environmental Sensor (With Sht35) -pagination_label: Model4823 -sidebar_label: Model 4823 Precision Indoor Environmental Sensor (With Sht35) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/model4823 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Model 4823 Precision Indoor Environmental Sensor (with SHT35) - -Precision temperature, humidity, light sensor for indoor spaces. - - - -### Resources - -- [Product Page](https://mcci.io/m4821) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- battery - -#### Dimensions: - -- width: 51 mm -- length: 76 mm -- height: 32 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/model4831.mdx b/docs/use-the-network/devices/development/mcci/model4831.mdx deleted file mode 100644 index 12449c299..000000000 --- a/docs/use-the-network/devices/development/mcci/model4831.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: model4831 -title: Model 4831 Outdoor Environmental Sensor (Sht31) -pagination_label: Model4831 -sidebar_label: Model 4831 Outdoor Environmental Sensor (Sht31) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/model4831 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Model 4831 Outdoor Environmental Sensor (SHT31) - -Temperature, humidity, light sensor for outdoors (using Sensirion SHT31) - - - -### Resources - -- [Product Page](https://mcci.io/m4831) -- [Datasheet](https://cdn.shopify.com/s/files/1/0873/5104/files/model483x-datasheet.pdf?v=1610937656) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- battery - -#### Dimensions: - -- width: 51 mm -- length: 76 mm -- height: 32 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/model4832.mdx b/docs/use-the-network/devices/development/mcci/model4832.mdx deleted file mode 100644 index 31e75e77c..000000000 --- a/docs/use-the-network/devices/development/mcci/model4832.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: model4832 -title: Model 4832 High-Accuracy Outdoor Environmental Sensor (Sht35) -pagination_label: Model4832 -sidebar_label: Model 4832 High-Accuracy Outdoor Environmental Sensor (Sht35) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/model4832 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Model 4832 High-Accuracy Outdoor Environmental Sensor (SHT35) - -Temperature, humidity, light sensor for outdoors (using Sensirion SHT35) - - - -### Resources - -- [Product Page](https://mcci.io/m4832) -- [Datasheet](https://cdn.shopify.com/s/files/1/0873/5104/files/model483x-datasheet.pdf?v=1610937656) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- light -- battery - -#### Dimensions: - -- width: 51 mm -- length: 76 mm -- height: 32 mm - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/mcci/model4841.mdx b/docs/use-the-network/devices/development/mcci/model4841.mdx deleted file mode 100644 index a758ca88d..000000000 --- a/docs/use-the-network/devices/development/mcci/model4841.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: model4841 -title: Indoor Air Quality Sensor -pagination_label: Model4841 -sidebar_label: Indoor Air Quality Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/mcci/model4841 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Indoor Air Quality Sensor - -PM 2.5, TVOC, temperature, humidity sensor for indoor air quality - - - -### Resources - -- [Product Page](http://mcci.io/buy-model4841) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- dust -- tvoc -- barometer - -#### Dimensions: - -- width: 41 mm -- length: 63 mm -- height: 33 mm - -#### Battery: - -- type: LiPo 3.7V -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/midatronics/sharky-module.mdx b/docs/use-the-network/devices/development/midatronics/sharky-module.mdx deleted file mode 100644 index e5ce542b0..000000000 --- a/docs/use-the-network/devices/development/midatronics/sharky-module.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -id: sharky-module -title: Sharky -pagination_label: Sharky Module -sidebar_label: Sharky -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/midatronics/sharky-module ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sharky - -The Sharky PCB is an IoT certified module with onboard PCB antenna based on the ST Microelectronics -STM32WB55CEU6 system on chip, a highly integrated low power radio design with two core in a single -SoC. There are an ARM Cortex-M4 32-bit microprocessor to run your application and one ARM Cortex-M0+ -32-bit microprocessor running the radio networking Stack. The Sharky module supports BLE, Thread, -Zig Bee and generic IEEE 802.15.4 protocol stacks. - - - -### Resources - -- [Product Page](https://midatronics.com/shop/module/sharky-i/) -- [Datasheet](https://midatronics.com/wp-content/uploads/2019/10/Sharky_Module.pdf) - -### Specifications - -#### Dimensions: - -- width: 27.25 mm -- length: 16 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/midatronics/windy-mkr.mdx b/docs/use-the-network/devices/development/midatronics/windy-mkr.mdx deleted file mode 100644 index 0d30a21f4..000000000 --- a/docs/use-the-network/devices/development/midatronics/windy-mkr.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: windy-mkr -title: Mkr Windy -pagination_label: Windy Mkr -sidebar_label: Mkr Windy -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/midatronics/windy-mkr ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MKR WINDY - -MKR WINDY is an Arduino MKR1000 form factor board based on the Midatronics WINDY Module, an IoT -module with onboard uFL connector based on the ST Microelectronics STM32WL, System-On-Chip -integrates both a general-purpose microcontroller and a sub-GHz radio on the same chip. Built on an -Arm® Cortex®‐M4 core architecture, STM32WL microcontrollers also support multiple modulations – -LoRa®, (G)FSK, (G)MSK, BPSK – to ensure flexibility in wireless applications with LoRaWAN®, Sigfox® -or any other suitable protocol in a fully open way. The windy module features a sub-GHz radio -based-on Semtech SX126x to meet the requirements of a wide range of Low-Power Wide Area Network -(LPWAN) wireless applications in industrial and consumer Internet-of-Things (IoT). - - - -### Resources - -- [Product Page](https://midatronics.com/shop/development-boards/mkr-windy/) - -### Specifications - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/midatronics/windy-module.mdx b/docs/use-the-network/devices/development/midatronics/windy-module.mdx deleted file mode 100644 index b520c6e01..000000000 --- a/docs/use-the-network/devices/development/midatronics/windy-module.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: windy-module -title: Windy Module -pagination_label: Windy Module -sidebar_label: Windy Module -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/midatronics/windy-module ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Windy Module - -The Windy Module is an IoT module with onboard uFL connector based on the ST Microelectronics -STM32WL, System-On-Chip integrates both a general purpose microcontroller and a sub-GHz radio on the -same chip. Built on an Arm® Cortex®‐M4 core architecture, STM32WL microcontrollers also support -multiple modulations – LoRa®, (G)FSK, (G)MSK, BPSK – to ensure flexibility in wireless applications -with LoRaWAN® , Sigfox® or any other suitable protocol in a fully open way. The windy module -features a sub-GHz radio based-on Semtech SX126x to meet the requirements of a wide range of -Low-Power Wide Area Network (LPWAN) wireless applications in industrial and consumer -Internet-of-Things (IoT). - - - -### Resources - -- [Product Page](https://midatronics.com/shop/module/windy/) -- [Datasheet](https://midatronics.com/wp-content/uploads/2020/10/Windy-STM32WL-Module_1.2.pdf) - -### Specifications - -#### Dimensions: - -- width: 23 mm -- length: 14.6 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/multi-tech/multi-tech-xdot.mdx b/docs/use-the-network/devices/development/multi-tech/multi-tech-xdot.mdx deleted file mode 100644 index 4969857ff..000000000 --- a/docs/use-the-network/devices/development/multi-tech/multi-tech-xdot.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -id: multi-tech-xdot -title: Multitech Xdot® Long Range Lora Module -pagination_label: Multi Tech Xdot -sidebar_label: Multitech Xdot® Long Range Lora Module -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/multi-tech/multi-tech-xdot ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MultiTech xDot® Long Range LoRa Module - -MultiTech xDot®is a secure, end-certified, Arm®Mbed™programmable, low-power RF module, that provides -long-range, low bit rate M2M data connectivity to sensors, industrial equipment and remote -appliances. - - - -### Resources - -- [Product Page](https://www.multitech.com/brands/multiconnect-xdot) -- [Datasheet](https://www.multitech.com/documents/publications/data-sheets/86002182.pdf) - -### Specifications - -#### Dimensions: - -- width: 23.6 mm -- length: 23.6 mm -- height: 3.51 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/opensourceinitiative/paxcounter.mdx b/docs/use-the-network/devices/development/opensourceinitiative/paxcounter.mdx deleted file mode 100644 index 794b7b4b1..000000000 --- a/docs/use-the-network/devices/development/opensourceinitiative/paxcounter.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -id: paxcounter -title: Paxcounter (Esp32 Board) -pagination_label: Paxcounter -sidebar_label: Paxcounter (Esp32 Board) -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/opensourceinitiative/paxcounter ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Paxcounter (ESP32 Board) - -Paxcounter is a ESP32 based device to meter pax flows in realtime - -### Resources - -- [Product Page](https://github.com/cyberman54/ESP32-Paxcounter) -- [Datasheet](https://github.com/cyberman54/ESP32-Paxcounter#readme) - -### Specifications - -#### Hardware: - -- Heltec: LoRa-32 v1 and v2 -- TTGO: [Paxcounter-Board\*](https://www.aliexpress.com/item/2251832729579512.html), - - T1\* - - T2\* - - T3\* - - T-Beam - - T-Fox -- Pycom - - LoPy - - LoPy4 - - FiPy -- Radioshuttle.de: - [ECO Power Board](https://www.radioshuttle.de/esp32-eco-power/esp32-eco-power-board/) -- WeMos: LoLin32 + [LoraNode32 shield](https://github.com/hallard/LoLin32-Lora), LoLin32lite + - [LoraNode32-Lite shield](https://github.com/hallard/LoLin32-Lite-Lora) -- Adafruit ESP32 Feather + LoRa Wing + OLED Wing, #IoT Octopus32 (Octopus + ESP32 Feather) -- M5Stack: - [Basic Core IoT\*](https://m5stack.com/collections/m5-core/products/basic-core-iot-development-kit) + - [Lora Module RA-01H](https://m5stack.com/collections/m5-module/products/lora-module-868mhz), - [Fire IoT\*](https://m5stack.com/collections/m5-core/products/fire-iot-development-kit) - -\* supports microSD-card - -#### Features: - -Depending on board hardware following features are supported: - -- LoRaWAN communication, supporting various payload formats (see enclosed .js converters) -- MQTT communication via TCP/IP and Ethernet interface (note: payload transmitted over MQTT will be - base64 encoded) -- SPI serial communication to a local host -- LED (shows power & status) -- OLED Display (shows detailed status) -- RGB LED (shows colorized status) -- Button (short press: flip display page / long press: send alarm message) -- Battery voltage monitoring (analog read / AXP192 / IP5306) -- GPS (Generic serial NMEA, or Quectel L76 I2C) -- Environmental sensors (Bosch BMP180/BME280/BME680 I2C; SDS011 serial) -- Real Time Clock (Maxim DS3231 I2C) -- IF482 (serial) and DCF77 (gpio) time telegram generator -- Switch external power/battery -- LED Matrix display (similar to - [this 64x16 model](https://www.instructables.com/id/64x16-RED-LED-Marquee/), can be ordered on - [Aliexpress](https://www.aliexpress.com/item/2251832430369196.html) -- SD-card for logging pax data diff --git a/docs/use-the-network/devices/development/quickstart-guides.mdx b/docs/use-the-network/devices/development/quickstart-guides.mdx deleted file mode 100644 index 1a62d581e..000000000 --- a/docs/use-the-network/devices/development/quickstart-guides.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: quickstart-guides -title: Development Device Quickstart Guides -pagination_label: Development Device Quickstart Guides -sidebar_label: Development Quickstart Guides -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/quickstart-guides ---- - -Quickstart guides are provided for some of the most popular development boards. The guides cover -every step needed to program and send packets on the network. - -#### [ST B-L072Z-LRWAN1](/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1) - -- [Arduino](/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/arduino) -- [Platform IO](/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/platformio) - -#### [Sparkfun Pro RF](/use-the-network/devices/development/sparkfun/pro-rf) - -- [Arduino](/use-the-network/devices/development/sparkfun/pro-rf/arduino) - -#### [Adafruit Feather MO](/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95) - -- [Arduino](/use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/arduino) - -#### [Heltec Cubecell](/use-the-network/devices/development/heltec/cubecell-dev-board) - -- [Arduino](/use-the-network/devices/development/heltec/cubecell-dev-board/arduino) -- [Platform IO](/use-the-network/devices/development/heltec/cubecell-dev-board/platformio) - -#### [Heltec WiFi LoRa 32 V2](/use-the-network/devices/development/heltec/wifi-lora-32-v2) - -- [Arduino](/use-the-network/devices/development/heltec/wifi-lora-32-v2/arduino) - -#### [RAK Wireless WisBlock Starter](/use-the-network/devices/development/rakwireless/wisblock-4631) - -- [Arduino](/use-the-network/devices/development/rakwireless/wisblock-4631/arduino) -- [Platform IO](/use-the-network/devices/development/rakwireless/wisblock-4631/platformio) - -#### [LoRa Vision Shield with the Portenta](/use-the-network/devices/development/arduino/lora-vision-shield/) - -- [Arduino](/use-the-network/devices/development/arduino/lora-vision-shield/arduino) diff --git a/docs/use-the-network/devices/development/rakwireless/rak7431.mdx b/docs/use-the-network/devices/development/rakwireless/rak7431.mdx deleted file mode 100644 index 86cee4aae..000000000 --- a/docs/use-the-network/devices/development/rakwireless/rak7431.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -id: rak7431 -title: Rak7431 Wisnode Bridge Serial -pagination_label: Rak7431 -sidebar_label: Rak7431 Wisnode Bridge Serial -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/rakwireless/rak7431 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## RAK7431 WisNode Bridge Serial - -RAK7431 WisNode Bridge Serial is an RS485 to LoRaWAN converter designed for industrial applications. -The device relays ModBUS data using the LoRaWAN network as means of wirelessly transmitting to and -from the end devices. - - - -### Resources - -- [Product Page](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7431/) -- [Datasheet](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7431/Datasheet/) -- [Video](https://www.youtube.com/watch?v=XVRR7Akyy8M) - -### Specifications - -#### Dimensions: - -- width: 24 mm -- length: 93.6 mm -- height: 100.3 mm - -#### Weight: - -- 490 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/rakwireless/wisblock-4631/arduino.mdx b/docs/use-the-network/devices/development/rakwireless/wisblock-4631/arduino.mdx deleted file mode 100644 index 108d1a606..000000000 --- a/docs/use-the-network/devices/development/rakwireless/wisblock-4631/arduino.mdx +++ /dev/null @@ -1,330 +0,0 @@ ---- -id: arduino -title: Arduino -pagination_label: Arduino -sidebar_label: Arduino -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/rakwireless/wisblock-4631/arduino ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## RAK Wireless WisBlock Arduino Guide - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your environment -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, you will need the following: - -### Hardware - -- [RAK Wireless WisBlock Starter Kit](https://store.rakwireless.com/products/wisblock-starter-kit) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) -- [Helium Console](https://www.helium.com/console) - -## Hardware Setup - -### Attaching the LoRa and BLE Antennas - -Your WisBlock Starter Kit should have come with two U.FL antenna. - -- the one that resembles an "I" is the LoRa antenna, this one connects to the connector on the core - module marked LoRa, which is below the large K in the RAK logo. -- the one that resembles a "T" is the BLE antenna, this one connects to the connector on the core - module marked BLE - -### Connect Board - -Next, lets connect our board to our computer with a USB 2.0 A-Male to Micro B cable. - -## Software Setup - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. (At least v1.6.12) - -- ​[Windows](https://www.arduino.cc/en/Guide/Windows)​ -- ​[Linux](https://www.arduino.cc/en/Guide/Linux)​ -- ​[Mac OSX](https://www.arduino.cc/en/Guide/MacOSX)​ - -Following the Arduino IDE installation instructions that are appropriate for your development -platform. It is suggested you allow the device driver installation for your target device if -prompted. - -:::warning - -_**If you are using Windows 10**_. Do _**NOT**_ install the Arduino IDE from the Microsoft App -Store. - -Please install the original Arduino IDE from the -[Arduino official website](https://www.arduino.cc/en/Guide/Windows)​! - -The Arduino app from the Microsoft App Store has problems using third party Board Support Packages. - -::: - -### Installing Arduino Board Support - -The WisBlock Starter Kit requires the installation of an Arduino board support package. Follow the -instructions below. - -To install, open your Arduino IDE: - -1. Navigate to **\(File > Preferences\), \(Arduino > Preferences\) on MacOS.** -2. Find the section at the bottom called **Additional Boards Manager URLs:** - - - -1. Add this URL in the text box: - -```text -https://raw.githubusercontent.com/RAKwireless/RAKwireless-Arduino-BSP-Index/main/package_rakwireless_index.json -``` - -2. Click "OK" to close the Preferences windows - -Next, to install this board support package into the Arduino IDE: - -1. Navigate to \(**Tools > Board > Boards Manager...\)** -2. Enter RAKWireless in the search bar. -3. On the **RAKwireless nRF Boards** item select the newest version and then click Install - - - -When the board installation process has finished, close the Boards Manager dialog. - -### Install SX125x-Arduino Support library - -Next we need to install the LoRaWan support library. - -1. Navigate to \(**Sketch> Include Library > Manage Libraries...\)** - -{' '} - -2. Enter **SX126x-Arduino** in the search box -3. On the **SX126x-Arduino** item select the newest version and click Install - - - -When the library installation process has finished, close the Library Manager dialog. - -### Install Serial Driver - -Some operating systems, especially Windows, may require the installation of hardware specific USB -device driver code. In general it's best to just try to upload a built application before installing -new device drivers. - -If the upload fails and you believe it is a device driver issue refer to the WisBlock support forum -found [here](https://forum.rakwireless.com/) for the most up to date information. Search within the -WisBlock category. - -### Set Project Configuration Options - -The target board type and LoRaWan Region are set via the Arduino IDE Tools menu as follows: - -1. Board Type: Select (**Tools> Board>RAKwireless nRF Modules>WisBlock Core RAK4631 Board - \)** - - - -2. LoRaWan Region: Select (**Tools> Region>US915 \)** -3. Set Debug level as desired: Select (**Tools> Debug \)** -4. Port number is important and may be automatically selected for you if not it can be changed via: - (**Tools> Port \)** - - - -Unlike some other board types the remaining LoRaWan configuration items for a WisBlock are via -defines within the sketch. For example: - -``` -// example LoRaWan configuration defines -bool doOTAA = true; -DeviceClass_t gCurrentClass = CLASS_A -lmh_confirm gCurrentConfirm = LMH_UNCONFIRMED_MSG -#define LORAWAN_DATARATE DR_0 -#define LORAWAN_TX_POWER TX_POWER_5 -#define JOINREQ-NBTRIALS 3 -``` - -### Programming **Example Sketch** - -Now that we have the required Arduino board support and library installed, lets program the board -with the provided example sketch. - -#### Example Sketch - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://github.com/helium/longfi-arduino/blob/master/RAKWireless-WisBlock/longfi-us915/longfi-us915.ino), -copy and paste the entirety of it. - -#### Add device credentials - -Next we'll need replace the placeholder AppEUI, DevEUI, and AppKey values found within the sample -program with the real values found on the target device page within the Helium Console. - -``` -NOTE: - The endianess required for these credentials varies - depending on the LoRaWan runtime library - implementation. Using a custom library implementation - will require an understanding of that libraries - endian requirement, big endian or little endian. -``` - -For our WisBlock example all values are big endian \(msb\), most significant bit on the left. Be -sure to use the formatting buttons to expand the ids and match the endianess formatting required for -the sketch, as shown below. - - - -At the top of the main.cpp file, replace the three **FILL_ME_IN** fields, with the matching field -from the Helium Console, example shown below. Your numbers will be different depending on what the -console creates when you add your target device. - - - -#### Build the Sketch - -Once the device ids have been entered build the firmware by clicking on the check mark button found -at the right side of the Arduino IDE tool bar. - -#### Upload Built Firmware - -We're finally ready to upload our sketch to the board. - -1. First, without your device connected to your development platform, within the Arduino IDE make a - note of which comm ports are currently detected. \(**Tools > Port:**\). -2. Next connect your WisBlock device to your development computer. -3. Finally within the Arduino IDE select the comm port associated with the WisBlock. \(**Tools > - Port: COM\#/ttyACM\#**\). The correct one will be the one newly added after the device was - connected. - -``` -If you are still unsure which port is associated with -the WisBlock you may need to disconnect the device, -restart the Arduino IDE, then check the available ports -via "Tools>Port:" prior to re-connecting the device. -``` - -In the Arduino IDE, click the right arrow button, or navigate to \(**Sketch > Upload\),** to -build and upload your new firmware to the board. You should see something similar to the image below -at the bottom of your Arduino IDE, when the upload is successful. - - - -#### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. - -We first need to verify the connected serial port again as it may be a different port than the one -shown in the firmware upload progress view seen above. - -Again navigate to \(**Tools > Port: COM\#/ttyACM\#**\), and verify the proper serial device is -selected. - -Then open the serial monitor by clicking on the icon in the upper right corner of the Arduino IDE. - - - -When the monitor opens you should begin to see output similar to below. - - - -Now let's head back to [Helium Console](https://console.helium.com/) and look at our device page, -you should see something similar to the screenshot below. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our Integrations docs -[here](/use-the-network/console/integrations).. - -### Examples and Tutorials - -After you have installed the RAK WisBlock support into the Arduino IDE board you can see more -WisBlock examples by navigating to \(**File > Examples > RAK WisBlock Examples...\)** - -``` -NOTE: These examples have not been verified to be -compatible with the Helium network. But they will -demonstrate various aspects of the WisBlock development - board. -``` - -For more information about the examples and tutorials visit the RAK Wireless WisBlock Github repo -located [here](https://github.com/RAKWireless/WisBlock). diff --git a/docs/use-the-network/devices/development/rakwireless/wisblock-4631/platformio.mdx b/docs/use-the-network/devices/development/rakwireless/wisblock-4631/platformio.mdx deleted file mode 100644 index 599d0d437..000000000 --- a/docs/use-the-network/devices/development/rakwireless/wisblock-4631/platformio.mdx +++ /dev/null @@ -1,693 +0,0 @@ ---- -id: platformio -title: PlatformIO -pagination_label: PlatformIO -sidebar_label: PlatformIO -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/rakwireless/wisblock-4631/platformio ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Getting started with Helium and PlatformIO - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -[PlatformIO ](https://platformio.org/)is a cross-platform, cross-architecture, multiple framework, -professional tool for embedded systems engineers and for software developers who write applications -for embedded products. - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -## Introduction to Guide - -This guide will walk through installing PlatformIO and deploying a Helium Arduino program on a -target device. Here, as an example, we will detail the steps required to integrate a specific board -type, the [RAK Wireless WisBlock](https://store.rakwireless.com/pages/wisblock) family of boards. - -However, this guide can be also used to on-board many other types of target devices. In most cases -one can just substitute your target device in place of the WisBlock developer board. - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your PlatformIO IDE environment -- How to create, build, upload a simple embedded application -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, we are going to use the -[RAK Wireless WisBlock Starter Kit](https://store.rakwireless.com/products/wisblock-starter-kit). -This procedure should work as a starting point if your particular device contains more of the -WisBlock components. Follow on RAK Wireless products may work but have not been tested at this -point. - -### Hardware - -- [RAK Wireless WisBlock Starter Kit](https://store.rakwireless.com/products/wisblock-starter-kit) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -PlatformIO is not a standalone IDE, it installs as an extension to Microsoft VSCode. The Helium -Console is a cloud based device management tool that we will use to enable our device access to the -Helium network. There is no installation required however one will need to create a user account -with the Helium Console. - -- [VSCode \(IDE)](https://code.visualstudio.com/) - - [PlatformIO \(VScode Extension)](https://platformio.org/) -- [Helium Console](https://www.helium.com/console) - -## Hardware Setup - -### Attaching the LoRa and BLE Antennas - -Your WisBlock Starter Kit should have come with two U.FL antenna. - -- the one that resembles an "I" is the LoRa antenna, this one connects to the connector on the core - module marked LoRa, which is below the large K in the RAK logo. -- the one that resembles a "T" is the BLE antenna, this one connects to the connector on the core - module marked BLE - -### Connect Target Board to Development PC - -The target boards are typically connected to the host computer via a USB 2.0 A-Male to Micro B -cable. - -## Software Setup - -### Install Development Machine Serial Device Driver - -Some operating systems, especially Windows, may require the installation of hardware specific USB -device driver code. In general it's best to just try to upload a built application before installing -new device drivers. If the upload fails and you believe it is a device driver issue refer to the -WisBlock support forum for the most up to date information. -[RAK Wireless Support Forum](https://forum.rakwireless.com/). - -### Installing PlatformIO - -The WisBlock Starter Kit is not currently supported by PlatformIO out of the box. One must install -VSCode/PlatformIO and then take some extra steps to add support for WisBlock. - -This guide will walk you through the following basic steps to get a simple Helium enabled embedded -application up and running. The steps will include - -- install VSCode and the PlatformIO extension -- install the Nordic nRF52 Arduino framework -- Implement patch files for RAK WisBlock Core boards -- Add WisBlock Core RAK4631 Variants Definition Files to PlatformIO -- create a new PlatformIO project -- prove out the install via a sample RAK Wireless WisBlock project -- add a project dependency library, SX126x-Arduino -- integrate your device specific Helium network configuration keys, Device EUI, APPEUI, APPKEY which - you obtain from the Helium console device definition. -- add your target LoRaWAN region defines to the platformio.ini configuration file -- compile and upload the device application - -#### Install VSCode and PlatformIO Extension - -Using the VSCode instructions found [here](https://code.visualstudio.com/) download and install -Microsoft's Visual Studio Code. PlatformIO IDE is built on top of VSCode as an extension. Once the -VSCode is installed: - -1. Open VSCode Extension Manager by clicking on the Extensions icon on the left side of the main - view. -2. Within the Extensions Marketplace search for official "PlatformIO IDE" extension -3. Click on the "Install" button contained within the PlatformIO IDE item -4. Addtional details for the PlatformIO extension can be found - [here](https://marketplace.visualstudio.com/items?itemName=platformio.platformio-ide) - - - -It is highly recommended to give the PlatformIO quick-start guide a read. It will help you navigate -the unfamiliar interface. The guide can be found -[here](https://docs.platformio.org/en/latest/integration/ide/vscode.html#quick-start). - -Once PlatformIO is installed, you should be welcomed to VSCode with the following "PIO Home" screen: - - - -If not already open, the PlatformIO "Home" view can be opened by clicking on the house icon within -the VScode status bar. - - - -### Updating PlatformIO to Support the WisBlock Developer Board - -#### Install Nordic nRF52 Arduino framework - -We now need to install the framework of WisBlock support libraries. - -Select the "Platforms" icon located on the left side of the PIO Home view. In the "Filter Platforms -by Name" field, enter "Nordic" as follow: - - - -You may see there are several items, just select the "Nordic nRF52" item and then select "Install" -as seen below: - - - - -When complete you should see a successful install message such as the one above. - -#### Implement patch files for RAK WisBlock Core boards - -Download the PlatformIO folder from: - -https://github.com/RAKWireless/WisBlock/tree/master/PlatformIO/ - -and save it on your computer. - -From the downloaded folder copy the file **`wiscore_rak4631.json`** to the boards folder of the -nordicnrf52 platform folder. - -The path should be similar to: - -``` -Windows: %USER%\.platformio\platforms\nordicnrf52\boards -Linux: ~/.platformio/platforms/nordicnrf52/boards -Mac OS: /Users/{Your_User_id}/.platformio/platforms/nordicnrf52/boards -``` - -#### Add WisBlock Core RAK4631 Variants Definition Files to PlatformIO - -Now, from the folder downloaded above, copy the complete "WisCore_RAK4631_Board" folder into -PlatformIO's packages/framework-arduinoadafruitnrf52/variants folder. The path should be similar to: - -``` -Windows: %USER%\.platformio\packages\framework-arduinoadafruitnrf52\variants -Linux: ~/.platformio/packages/framework-arduinoadafruitnrf52/variants -Mac OS: /Users/{Your_User_id}/.platformio/packages/framework-arduinoadafruitnrf52/variants -``` - -When complete you will have a new sub folder under variants called "WisCore_RAK4631_Board". - -#### Restart PlatformIO - -This completes the necessary WisBlock updates to PlatformIO. To fully implement these changes -shutdown, then restart PlatformIO - -### Creating a New PlatformIO Project - -If you have not already used PlatformIO to build, upload and verify the operation of a sample -application it is best familiarize yourself with the basic use of PlatformIO before adding the -complexity of Helium network access code to the mix. - -If you are familiar and confident with the steps required you can continue at "Sample Helium Network -Access Code" by clicking [here](#ADD-HELIUM-NETWORK-CODE). - -#### Prove out the install with a sample non Helium project - -To avoid too many unknowns when first starting out, the following will create, build and upload a -non Helium Network device applications. Once the basics are proven we will add more complexity by -introducing code that will access the Helium LoRaWAN network. The following steps will walk you -through what is required to: - -- create a template project -- inspect the default source file, main.cpp as well as the primary project configuration file, - platformio.ini -- build the project and inspect the build log output -- upload the sample binary to the target development board. -- inspect serial output debug information. - -#### Open "New Project Wizard" - Select project name and board - -- Within the "PIO Home" view click on "New Project". - -- At the "Project Wizard" dialog enter a name for your project in the "Name" field. -- Within the "Board" field select the appropriate target board by entering the name of the board, - "WisCore" for our example. The PlatformIO auto search feature should present you with a known list - of supported boards. In our case we should see "WisCore RAK4631 Board (RAKWireless)" presented as - a selection. -- For the "Framework" selection some devices will support more than one framework within PlatformIO, - for our WisBlock example make sure "Arduino" is selected. - - - -- With the Project Wizard items filled in, click on Finish to start the project creation. - -The time taken to create a project will vary depending on whether or not the selected platform and -framework files have been previously downloaded. When the project has been created it should be -shown, as seen below, within the PlatformIO Explorer view typically found on the left side of the -IDE. - - - -Typical project explorer view. - -#### Default project main.cpp - -If you are familiar developing within the Arduino IDE, main.cpp is much the same as the Arduino -\*.ino. It also contains default setup() and loop() functions. - -PlatformIO also adds a required "\#include " statement. This is an important/necessary -difference between PlatformIO and Arduino IDEs. - - - -#### platformio.ini - project configurations - -Let's take a look at the platformio.ini file in the root of our new project. This is where one -defines project configuration definitions. In the Arduino world one would do this via the IDE tool -bar selections. - -NOTE: when this file is modified the entire project will be rebuilt when the project is next built -or uploaded. - - - -Here we see the platformio.ini file that was created as a result of the running the New Project -wizard targeting our WisBlock board. - -#### Build the target device application - -Now that the template project has been created it's time to build the device application. Within -PlatformIO the "Build" button is the check-mark found within the bottom status bar. Clicking on this -button should start the build process. - - - -#### Inspect the build output - -Due to the defines within platformio.ini, PlatformIO is able to determine the project board and -framework dependencies. Any missing dependencies are automatically installed at build time, thus -this process may be seen in the build output. This feature allows us to add libraries into our -platformio.ini file, which will then be downloaded for us, if needed, at build time. - -The build process results can be found within the "Terminal View" typically found at the bottom of -the VSCode window. Much like with Arduino, the build output will dump the calculated amount of Ram -and Flash memory used by your application. - - - -Start of the build output displaying configuration information. - - - -Tail end of build log showing Ram and Flash usage. There is also a Problems output view that may -help when trying to resolve build issues. - -#### List of attached devices - -For this sections please make sure your target device is connected to your development computer. - -If, within the "PIO Home" view, you select the "Devices" icon on the left, you will see listed any -attached physical devices as well as their associated comm ports: - - - -The list should reflect your target device. The exact content will vary depending which operating -system PlatformIO is being executed on. - -#### Uploading binary to target device - -Now that the code has built successfully, if a target device is attached to your computer the -resulting binary can be uploaded to the target device. - -The method of uploading the binary to your device may vary depending on the target device. -PlatformIO will attempt to configure upload options appropriate for the chosen board. If the default -configuration does not work in your instance detailed information can be found within the PlatformIO -documentation -[here](https://docs.platformio.org/en/latest/projectconf/section_env_upload.html?highlight=upload) -or within your target board vendors documentation set. - - - -Click on the Upload button within the bottom Status bar. - -Below you will see a typical output as the binary is uploaded to the target board. - - - -``` -NOTE: - With some target devices PlatformIO will - automatically close any open comm port connection. - An upload error may occur if for some reason the - comm port cannot be closed. If this is the case you - must manually close down the terminal emulator's - connection before retrying the upload. -``` - -Now that the application has been uploaded you can connect your favorite terminal emulator to the -comm port seen in the list of devices above. Because the above sample project is an empty project -you will not see any addition output via the terminal emulator output unless you customize the -sample with debug output statements. - -Additional RAK Wireless supported WisBlock sample code can be found at -[https://github.com/RAKWireless/WisBlock/tree/master/examples](https://github.com/RAKWireless/WisBlock/tree/master/examples) - -If you have made it this far then we know your environment can build and upload a device -application. Now it's time to connect to the Helium network. - -### Helium Console - Create Device - -In order for a target device to communicate via the Helium Network a user account must first be -created. Once the user account is created then a console device must be created. - -When creating the console device, make note of the DevEUI, AppEUI, and AppKey device credentials. -These are used to connect to the network and will need to be inserted into the device application -code below. A console quick start guide can be found [here](/use-the-network/console/quickstart). - -### Sample Helium Network Access Code - -If you have not created a simple template project and you want to try one of the samples you can -copy a sample into your workspace where it should build without error. A full PlatformIO project can -be found -[here](https://github.com/helium/longfi-platformio/tree/master/RAKWireless-WisBlock/examples/LoRaWan_OTAA). -Alternatively you can update the template project created above by continuing the following steps. - -#### Update main.cpp - -Now that we have the minimum required board and library runtime support installed, let's program the -board with an example Helium network enabled application. - -To update the sample application created above: - -- open, within PlatformIO, your projects src/main.ccp file -- replace this template main.cpp with the content of the sample application found - [here](https://github.com/helium/longfi-platformio/blob/master/RAKWireless-WisBlock/examples/LoRaWan_OTAA/src/main.cpp). - Copy and paste the entirety of it. - -#### Add WisBlock LoRaWan Support Library to Project - -The WisBlock LoraWan support library is not fully integrated into PlatformIO at this point. It must -be included within each WisBlock project. This is accomplished by: - -- Open the PlatformIO:Home view by selecting the "house" button located on the VSCode status bar -- Select the "Libraries" icon on the left side of the "PlatformIO:Home" view -- within the "Search libraries" field enter "SX126x-Arduino" and hit the enter key -- When presented with the library entry, click on it. -- Click on the highlighted "Add to Project" button -- In the dialog that pops up, select the project into which you want to include the library, then - click on the "Add" button - -This process will add a library dependency line into the platformio.ini file similar to: - -``` -lib_deps = beegee-tokyo/SX126x-Arduino@^1.3.1 -``` - -The dependent libraries are also installed into the selected project within it's .pio/libdes -directory. - -#### Add device credentials - -Next we'll need replace the placeholder AppEUI, DevEUI, and AppKey values found within the sample -program with the real values found on the target device page within the Helium Console. - -``` -NOTE: - The endianess required for these credentials varies - depending on the LoRaWAN runtime library implementation. - Using a custom library implementation will require an - understanding of that libraries endian requirement, big - endian or little endian. -``` - -For our WisBlock example all values are big endian \(msb\), most significant bit on the left. - - - -At the top of the main.cpp file, replace the three **FILL_ME_IN** fields, with the matching field -from the Helium Console, example shown below. Your numbers will be different depending on what the -console creates when you add your target device. - - - -#### Verify LoRaWAN channels mask - -Runtime library implementations are designed to work across several LoRaWAN regions and networks. -The firmware will attempt to join the network using various frequency sub-bands, defined by a -channel mask, until the join succeeds. It is recommended that you change the default channel mask to -a value that will help the join process complete connection to the Helium network in a more timely -manner. The process, where and how, to update this channel mask will vary depending on the LoRaWAN -runtime implementation - -For our example using the WisBlock and it's runtime the channel mask is set via a runtime API call. -The following piece of code can be incorporated into sample projects. Refer to a sample to determine -where this code should reside, generally just prior to the call to the join API call is fine. - -``` -/* Helium Network LoraWan sub channel 2 is recommended, default channels 0-7*/ - if (!lmh_setSubBandChannels(2)) - { - Serial.println("lmh_setSubBandChannels() failed"); - } -``` - -#### A Note About Network Join Failures - -Within the project main.cpp file there is the following define: - -``` -#define JOINREQ_NBTRIALS 10 -``` - -This define is used by the runtime to determine how many times to attempt a LoRaWAN network join. -Once this number of join retries is exhausted the runtime will call a device application level -callback, if defined. - -The runtime will no longer attempt to join the network once this callback has been called. It is -left to the device application to monitor via the join success and join fail callbacks the status of -the join process. - -If your device application has or may have difficulty joining the network due to poor signal quality -the application will need to manage the join retries beyond the number defined by JOINREQ_NBTRIALS. -An example project which attempts to handle join failure retries can be found -[here](https://github.com/helium/longfi-platformio/blob/master/RAKWireless-WisBlock/examples/LoRaWan_OTAA_Join_Retry). - -The currently supported device application level callbacks can be found within the sample -applications within the following define. - -``` -static lmh_callback_t lora_callbacks = { ... }; -``` - -#### platformio.ini - project configurations - -For our sample application we need a few configuration items added to the project platformio.ini -file. These include project defines, serial debug monitor configurations and debugger -configurations. - -Complete documentation of platformio.ini content can be found -[here](https://docs.platformio.org/en/latest/projectconf/index.html). Serial debug monitor specific -items [here](https://docs.platformio.org/en/latest/projectconf/section_env_monitor.html). - -For our example WisBlock project update the projects platformio.ini with the content from the sample -project: - -- open, within PlatformIO, your projects platformio.ini file -- replace this template file with the content found - [here](https://github.com/helium/longfi-platformio/blob/master/RAKWireless-WisBlock/examples/LoRaWan_OTAA/platformio.ini). - Copy and paste the entirety of it. - -Once you have become more familiar with the LoRaWAN/Helium network feel free to experiment with -different configuration settings possible within platformio.ini. - -NOTE: The comment character for this file type is the semicolon. - -#### Build the device application - -After updating the main.cpp and platformio.ini files it's time to build the device application. -Within PlatformIO the "Build" button is the check-mark found within the bottom status bar. Clicking -on this button should start the build process. - -#### Inspect the build results - -The build output results can be found within the "Terminal View" typically found at the bottom of -the VSCode window. Verify the build completed successfully. - -#### Possible Arduino to PlatformIO porting issues - -When porting Arduino sketches to PlatformIO you may find errors such as undefined functions. These -may be functions that are called by setup() or loop() or other custom functions prior to them being -defined. This is a side effect of the different C version of C compilers used with PlatformIO vs -Arduino. In this instance we just need to define the function prototype before the function is -actually called. Another compatibility issue is that unlike Arduino IDE, you must include Arduino.h -at the start of your C file if you are using Arduino defined constructs. Generally the compatibility -issues are minor. - -#### Upload Binary to target device - -If the build process completed successfully, upload the binary to the target device via the "Upload" -(right pointing arrow) button found on the status bar. - -``` -NOTE: - With some target devices PlatformIO will - automatically close any open comm port connection. - An upload error may occur if for some reason the - comm port cannot be closed. If this is the case you - must manually close down the terminal emulator's - connection before retrying the upload. -``` - - - -Successful upload example, your results will vary. - -#### Viewing Target Device Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. The -built-in PlatformIO Serial Monitor or any other virtual serial terminal emulator can be used to view -the serial debug output from the board. - -If the built-in serial monitor is selected PlatformIO will attempt to connect to it automatically. -If using another terminal emulator refer to the Devices view as mentioned above to determine which -comm port your device is connected to. - -To open the serial monitor click on the "Serial Monitor" button within the status bar. - - - -You should begin to see output similar to below. This example uses VSCode's builtin virtual terminal -emulator. - - - -#### Helium Console Uplinks - -Now let's head back to the [Helium Console](https://console.helium.com/) and login to your account. -Once logged in select the "Devices" item on the left, then select the target device previously -created. Scroll down a bit on the device page and you should see something similar to the screenshot -below. - - - -Activation messages are those seen when the device first attempts to join the network. Downlink -messages are those delivered from the network to your target device. Uplink messages are those -messages delivered from your target device to the Helium network. - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our integration docs -[here](/use-the-network/console/integrations). - -### Device Application Code Debugging with PlatformIO - -If, as is frequently the case, your application misbehaves VSCode/PlatformIO does support board -level debugging via various debug probes/interfaces. A general debug discussion can be found -[here](https://docs.platformio.org/en/latest/plus/debugging.html) or debug probe specific discussion -[here](https://docs.platformio.org/en/latest/plus/debugging.html#tools-debug-probes). PlatformIO -will attempt to seamlessly support your projects defined target board for debugging but with the -vast number of target boards, not all are supported out of the box. - -PlatformIO supports out of the box debugging with the WisBlock developer board via the SWD ST-Link -protocol. To enable debugging add the following to your project platformio.ini file: - -``` -build_type = debug -upload_protocol = stlink -debug_tool = stlink -``` - -The ST-Link probe should connect to the SWDIO, SWCLK and GND pins of the Single Wire Debug pins as -marked on the WisBlock core board. Complete SWD/ST-Link operation is out of scope for this guide. - -Then you can utilize the PlatformIO integrated debugging. - - - -Example WisBlock Starter Kit connected to ST Discovery configured for ST-Link support diff --git a/docs/use-the-network/devices/development/rakwireless/wisblock-4631/wisblock-4631.mdx b/docs/use-the-network/devices/development/rakwireless/wisblock-4631/wisblock-4631.mdx deleted file mode 100644 index ed85ecdce..000000000 --- a/docs/use-the-network/devices/development/rakwireless/wisblock-4631/wisblock-4631.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: wisblock-4631 -title: Wisblock Starter Kit Rak4631 -pagination_label: Wisblock 4631 -sidebar_label: Wisblock Starter Kit Rak4631 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/rakwireless/wisblock-4631 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wisblock Starter Kit RAK4631 - -The RAK4631 WisBlock Started Kit delivers a powerful Nordic nRF52840 MCU with Bluetooth 5 paired to -the latest LoRa® transceivers from Semtech, the SX126x series. - - - -## Introduction - -Here you will find one or more sample PlatformIO embedded projects designed to transmit LoRaWAN -packets using a -[RAK Wireless WisBlock Starter Kit](https://store.rakwireless.com/products/wisblock-starter-kit). -The starter kit is just that, a base developer board that can have multiple combinations of -expansion boards added to it. The full WisBlock offering can be seen -[here](https://store.rakwireless.com/pages/wisblock). - -### Resources - -[WisBlock Product Page](https://store.rakwireless.com/products/wisblock-starter-kit) -[WisBlock Documentation](https://docs.rakwireless.com/Product-Categories/WisBlock/) -[US Retailer - Parley Labs](https://shop.parleylabs.com) - -### Firmware Quickstart Guides - -- [Arduino Guide](/use-the-network/devices/development/rakwireless/wisblock-4631/arduino) -- [PlatformIO Guide](/use-the-network/devices/development/rakwireless/wisblock-4631/platformio) - -### Video Guides - -- [Community Tutorial Video](https://youtu.be/J2f_AVx-WsE) - -### Specifications - -#### Dimensions: - -- width: 30 mm -- length: 60 mm - -#### Weight: - -- 35 grams - -#### Battery: - -- type: Li-Ion / Li-Po, 1024 mAh minimum capacity, JST connector -- replaceable: True diff --git a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-devkit.mdx b/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-devkit.mdx deleted file mode 100644 index 62713781f..000000000 --- a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-devkit.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -id: loramodule-e5-devkit -title: Wio-E5 Dev Kit, For Long Range Application -pagination_label: Loramodule E5 Devkit -sidebar_label: Wio-E5 Development Kit -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/seeed-studio/loramodule-e5-devkit ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wio-E5 Development Kit - -Wio-E5 Development Kit consists of a Wio-E5 Dev Board, an antenna(EU868/US915), a USB type C cable, -and a 2\*AA 3V Battery Holder. Wio-E5 Dev Board embedded with Wio-E5 STM32WLE5JC Module that -supports LoRaWAN® protocol on global frequency band. It is user-friendly since it leads out full -GPIOs of Wio-E5 supporting various data protocols and interfaces including RS-485, Grove, -male/female headers, etc. It would be a perfect choice for fast testing and rapid prototyping of -your LoRa® IoT projects. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRa-E5-Dev-Kit-p-4868.html) -- [Datasheet](https://files.seeedstudio.com/products/113990934/LoRa-E5%20Dev%20Board%20v1.0.pdf) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRa-E5-Dev-Kit-p-4868.html) - -### Specifications - -#### Dimensions: - -- width: 12 mm -- length: 12 mm -- height: 2.5 mm diff --git a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-grove.mdx b/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-grove.mdx deleted file mode 100644 index 1bdaa8533..000000000 --- a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-grove.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -id: loramodule-e5-grove -title: Grove - Wio-E5 (Stm32Wle5Jc), For Long Range Application -pagination_label: Loramodule E5 Grove -sidebar_label: Wio-E5 Grove -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/seeed-studio/loramodule-e5-grove ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wio-E5 Grove - -Grove Wio-E5 embedded with Wio-E5 STM32WLE5JC, powered by ARM Cortex M4 ultra-low-power MCU core and -LoRa® SX126x, is an easy-to-use wireless radio module, supporting LoRaWAN® protocol on the EU868 & -US915 frequency and (G)FSK, BPSK, (G)MSK, LoRa® modulations. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/Grove-LoRa-E5-STM32WLE5JC-p-4867.html) -- [Datasheet](https://files.seeedstudio.com/products/113020091/Grove%20-%20LoRa%20-E5%20v1.0.pdf) -- [Reseller - Seeed](https://www.seeedstudio.com/Grove-LoRa-E5-STM32WLE5JC-p-4867.html) - -### Specifications - -#### Dimensions: - -- width: 12 mm -- length: 12 mm -- height: 2.5 mm diff --git a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-mini.mdx b/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-mini.mdx deleted file mode 100644 index 9fb065770..000000000 --- a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5-mini.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -id: loramodule-e5-mini -title: Wio-E5 Mini (Stm32Wle5Jc) Dev Board, For Long Range Application -pagination_label: Loramodule E5 Mini -sidebar_label: Wio-E5 Mini -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/seeed-studio/loramodule-e5-mini ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wio-E5 mini - -Wio-E5 mini is a compacted-sized dev board suitable for the rapid testing and building of small-size -LoRa® device and application prototyping. Wio-E5 mini is embedded with and leads out full GPIOs of -Wio-E5 STM32WLE5JC. It has rich interfaces including UART, ADC, SPI, IIC,etc. Supporting LoRaWAN® -protocol and global frequency, Wio-E5 mini is able to achieve a transmission range of up to 10 km in -open area and ultra-low power consumption. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRa-E5-mini-STM32WLE5JC-p-4869.html) -- [Datasheet](https://files.seeedstudio.com/products/113990939/LoRa-E5%20mini%20v1.0.pdf) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRa-E5-mini-STM32WLE5JC-p-4869.html) - -### Specifications - -#### Dimensions: - -- width: 12 mm -- length: 12 mm -- height: 2.5 mm diff --git a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5.mdx b/docs/use-the-network/devices/development/seeed-studio/loramodule-e5.mdx deleted file mode 100644 index 39f0f71db..000000000 --- a/docs/use-the-network/devices/development/seeed-studio/loramodule-e5.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: loramodule-e5 -title: Wio-E5 Wireless Module, For Long Range Application -pagination_label: Loramodule E5 -sidebar_label: Wio-E5 Stm32Wle5Jc Module -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/seeed-studio/loramodule-e5 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wio-E5 STM32WLE5JC Module - -Wio-E5 LoRaWAN® module is designed with ST system-level package chip STM32WLE5JC, ARM Cortex M4 -ultra-low-power MCU and LoRa® SX126X. It supports (G)FSK mode and LoRa®. 62.5kHz, 125kHz, 250kHz, -and 500kHz bandwidth can be used in LoRa® mode, making it suitable for the design of various IoT -nodes, supporting EU868 and US915. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRa-E5-Wireless-Module-p-4745.html) -- [Datasheet](https://files.seeedstudio.com/products/317990687/res/LoRa-E5%20module%20datasheet_V1.0.pdf) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRa-E5-Wireless-Module-p-4745.html) - -### Specifications - -#### Dimensions: - -- width: 12 mm -- length: 12 mm -- height: 2.5 mm diff --git a/docs/use-the-network/devices/development/seeed-studio/seeed-studio-lorawan-dev-kit.mdx b/docs/use-the-network/devices/development/seeed-studio/seeed-studio-lorawan-dev-kit.mdx deleted file mode 100644 index 11a1de724..000000000 --- a/docs/use-the-network/devices/development/seeed-studio/seeed-studio-lorawan-dev-kit.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: seeed-studio-lorawan-dev-kit -title: Sensecap K1100 - The Sensor Prototype Kit With Lora® And Ai -pagination_label: Seeed Studio LoRaWAN Dev Kit -sidebar_label: Sensecap K1100 - The Sensor Prototype Kit With Lora® And Ai -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/seeed-studio-lorawan-dev-kit ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP K1100 - The Sensor Prototype Kit with LoRa® and AI - -The kit includes a Wio Terminal master controller with WIFI/BLE and display, as well as carefully -selected Grove - Wio-E5, Grove - VOC and eCO2 Gas Sensor SGP30, Grove - Soil Moisture Sensor, -Grove - Temp&Humi Sensor (SHT40), and Grove - Vision AI Module. Humi Sensor (SHT40), and Grove - -Vision AI Module. This kit is a perfect combination of LoRa® and Edge AI, which allows software -engineers and every beginner to quickly deploy their first LoRaWAN® projects through plug-and-play -connectivity. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/Seeed-Studio-LoRaWAN-Dev-Kit-p-5370.html) - -### Part List - -| Part List | | -| --------------------------------------------------------- | --- | -| Wio Terminal | x1 | -| Grove - Wio-E5 | x1 | -| Grove - VOC and eCO2 Gas Sensor SGP30 | x1 | -| Grove - Soil Moisture Sensor | x1 | -| Grove - Temp&Humi Sensor (SHT40) | x1 | -| Grove - Vision AI Module | x1 | -| Grove - Cable | x4 | -| Grove - 4 pin Male Jumper to Grove 4 pin Conversion Cable | x1 | -| USB Cable - Type C | x1 | diff --git a/docs/use-the-network/devices/development/sparkfun/pro-rf/arduino.mdx b/docs/use-the-network/devices/development/sparkfun/pro-rf/arduino.mdx deleted file mode 100644 index c57b3ad38..000000000 --- a/docs/use-the-network/devices/development/sparkfun/pro-rf/arduino.mdx +++ /dev/null @@ -1,260 +0,0 @@ ---- -id: arduino -title: Arduino -pagination_label: Arduino -sidebar_label: Arduino -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/sparkfun/pro-rf/arduino ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sparkfun Pro RF Arduino Guide - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your environment -- How to program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, you will need the following: - -### Hardware - -- [Sparkfun Pro RF - LoRa](https://www.sparkfun.com/products/14916) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) -- Soldering Iron -- Small gauge wire - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) -- [Helium Console](https://console.helium.com/) - -## Hardware Setup - -This step will cover adding an antenna and closing the LoRaWAN jumpers on this board. - -### Adding the Antenna - -You have two options for adding an antenna on this board. - -**U.FL Antenna:** Connect any 915Mhz compatible antenna, for instance, -[this ](https://www.mouser.com/ProductDetail/Anaren/66089-0906?qs=sGAEpiMZZMuBTKBKvsBmlGlvlFGR4gdSgkIgGKwINqg%3D)small, -low cost antenna, to the U.FL port shown in the image below. - - - -**Wire Antenna:** Solder a short wire\(78mm in length for Americas\) to the pin-out as shown below. - - - -### Closing the LoRaWAN Jumpers - -In order to fully communicate with the LoRa radio transceiver on the board, you'll need to close two -jumpers on the underside shown below. - - - -## Software Setup - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. - -- [Windows](https://www.arduino.cc/en/Guide/Windows) -- [Linux](https://www.arduino.cc/en/Guide/Linux) -- [Mac OSX](https://www.arduino.cc/en/Guide/MacOSX) - -### Arduino Board Support - -The Sparkfun Pro RF requires two Arduino board support packages. Follow the instructions below to -install both. - -#### SAMD Boards \(32-bits ARM Cortex-M0+\) - -To install, open your Arduino IDE: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **SAMD Boards \(32-bits ARM Cortex-M0+\)** -3. Select the newest version and click Install - - **SparkFun SAMD Boards** - -#### SparkFun SAMD Boards - -To install, open your Arduino IDE: - -1. Navigate to **\(File > Preferences\), \(Arduino > Preferences\) on MacOS.** -2. Find the section at the bottom called **Additional Boards Manager URLs:** - - - -1. Add this URL in the text box: - -```text -https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json -``` - -1. Close the Preferences windows - -Next, to install this board support package: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **SparkFun SAMD Boards** -3. Select the newest version and click Install - -### Arduino Library - -To communicate with Helium's LoRaWAN network, we'll need to install an Arduino library. - -To install, open your Arduino IDE: - -1. Navigate to Library Manager \(**Sketch > Include Library > Manage Libraries**\). -2. In the search box, type **IBM LMIC framework** into the search, select the version shown below, - and click Install. - - - -#### Update IBM LMIC framework config.h - -This library requires that a config file be setup properly. After you have installed the -`IBM LMIC framework` library, navigate to it's directory on your operating system found below. Next, -replace the `config.h` file in this directory with this -[config.h](https://github.com/helium/longfi-arduino/blob/master/Sparkfun-Pro-RF/longfi-us915/config.h) -file. - -``` -linux: /home/{user}/Arduino/libraries/IBM\_LMIC\_framework/src/lmic -windows: Documents/Arduino/libraries/IBM\_LMIC\_framework/src/lmic -mac os: Documents/Arduino/libraries/IBM\_LMIC\_framework/src/lmic -``` - -### Programming **Example Sketch** - -Now that we have the required Arduino board support and library installed, lets program the board -with the provided example sketch. - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://github.com/helium/longfi-arduino/blob/master/Sparkfun-Pro-RF/longfi-us915/longfi-us915.ino), -copy and paste the entirety of it. - -Next we'll need to fill in the AppEUI, DevEUI, and AppKey, in the sketch, which you can find on the -device details page on Console. Be sure to use the formatting buttons to match the endianess and -formatting required for the sketch, shown below. - - - -At the top of the sketch, replace the three **FILL_ME_IN** fields, with the matching field from -Console, example shown below. - - - -### Selecting Board - -Next, we need to select the correct board to build for in the Arduino IDE. Navigate to \(**Select -Tools > Board: > SparkFun SAMD21 Pro RF\).** - -### Enter Bootloader Mode - -Next, we need to place the board into bootloader mode, which allows us to update it with new -firmware. To do this, first plug the device into your computer, make sure the power switch is turned -on \(you should see a red LED on\). Next, quickly double click the reset push button on the side of -the board, you should see a blue LED come on now too. If you see this then you have successfully -entered bootloader mode. - -### Selecting Port - -We're almost ready to upload our sketch, the very last step is to select the correct Serial port in -the Arduino IDE. Navigate to \(**Tools > Port: Sparkfun SAMD21 Pro RF**\). You will also see -either **COM\# or /dev/ttyACM\#** depending on whether you are on Windows, Mac, or Linux. If you do -not see a port, please visit the Drivers section in -[Sparkfun's guide](https://learn.sparkfun.com/tutorials/sparkfun-samd21-pro-rf-hookup-guide?_ga=2.148378999.1172134851.1586114454-289367592.1582349414&_gac=1.242421430.1585837307.EAIaIQobChMI86GEgfjJ6AIVBQF9Ch0mpwyeEAEYASAAEgLFn_D_BwE#hardware-overview) -to make sure you have what's needed for your operating system. - -### Upload Sketch - -We're finally ready to upload our sketch to the board. In the Arduino IDE, click the right arrow -button, or navigate to \(**Sketch > Upload\),** to build and upload your new firmware to the -board. You should see something similar to the image below at the bottom of your Arduino IDE, when -the upload is successful. - - - -### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. We first need to select -the serial port again, but this time it will be a **different port** than the one we selected to -communicate with the bootloader. Once again, navigate to \(**Tools > Port: Sparkfun SAMD21 Pro -RF**\), but make sure the serial device, either COM\# or ttyACM\#, is different! Next navigate to -\(**Tools > Serial Monitor**\), you should begin to see output similar to below. - - - -Now let's head back to [Helium Console](https://console.helium.com) and look at our device page, you -should see something similar to the screenshot below. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our Integrations docs -[here](/use-the-network/console/integrations). diff --git a/docs/use-the-network/devices/development/sparkfun/pro-rf/pro-rf.mdx b/docs/use-the-network/devices/development/sparkfun/pro-rf/pro-rf.mdx deleted file mode 100644 index b4ac173bf..000000000 --- a/docs/use-the-network/devices/development/sparkfun/pro-rf/pro-rf.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: pro-rf -title: Pro Rf -pagination_label: Pro Rf -sidebar_label: Sparkfun Pro Rf -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/sparkfun/pro-rf ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sparkfun Pro RF - - - -## Introduction - -The SparkFun Pro RF is a LoRa®-enabled wireless board that marries a SAMD21 and a long-range RFM95W -to make a compact and easy-to-use IoT Arduino board. With its fast MCU and excellent point to point -data transmission in the 915MHz ISM band with LoRa Capabilities, the Pro RF is a great choice for -anyone interested or experienced in utilizing long range data communication. - -### Resources - -- [Product Page](https://www.sparkfun.com/products/14916) -- [Manual](https://learn.sparkfun.com/tutorials/sparkfun-samd21-pro-rf-hookup-guide?_ga=2.165621823.1036802692.1607713936-859284285.1605745645#introduction) -- [Schematic ](https://cdn.sparkfun.com/assets/f/f/8/e/f/SAMD21_Pro_RF_v11_Schematic.pdf) - -### Firmware Quickstart Guides - -[Arduino Guide](/use-the-network/devices/development/sparkfun/pro-rf/arduino) diff --git a/docs/use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc1.mdx b/docs/use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc1.mdx deleted file mode 100644 index ab37f7906..000000000 --- a/docs/use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc1.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: nucleo-wl55jc1 -title: Nucleo-Wl55Jc1 -pagination_label: Nucleo Wl55Jc1 -sidebar_label: Nucleo-Wl55Jc1 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## NUCLEO-WL55JC1 - -NUCLEO-WL55JC1 high-band development board with temperature sensor and controllable LEDs - - - -### Resources - -- [Product Page](https://www.st.com/en/evaluation-tools/nucleo-wl55jc.html) -- [Datasheet](https://www.st.com/resource/en/data_brief/nucleo-wl55jc.pdf) -- [Reseller - ARROW](https://www.arrow.com/en/products/nucleo-wl55jc1/stmicroelectronics) -- [Reseller - RUTRONIK](https://www.rutronik24.com/product/st/nucleo-wl55jc1/14201387.html) -- [Video](https://www.youtube.com/watch?v=ZFtIlLbDXlo) - -### Specifications - -#### Sensors: - -- temperature -- light - -#### Dimensions: - -- width: 70 mm -- length: 64.5 mm -- height: 19 mm - -#### Weight: - -- 34 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc2.mdx b/docs/use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc2.mdx deleted file mode 100644 index f03c943ab..000000000 --- a/docs/use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc2.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: nucleo-wl55jc2 -title: Nucleo-Wl55Jc2 -pagination_label: Nucleo Wl55Jc2 -sidebar_label: Nucleo-Wl55Jc2 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## NUCLEO-WL55JC2 - -NUCLEO-WL55JC2 low-band development board with temperature sensor and controllable LEDs - - - -### Resources - -- [Product Page](https://www.st.com/en/evaluation-tools/nucleo-wl55jc.html) -- [Datasheet](https://www.st.com/resource/en/data_brief/nucleo-wl55jc.pdf) -- [Reseller - ARROW](https://www.arrow.com/en/products/nucleo-wl55jc1/stmicroelectronics) -- [Reseller - RUTRONIK](https://www.rutronik24.com/product/st/nucleo-wl55jc1/14201387.html) -- [Video](https://www.youtube.com/watch?v=ZFtIlLbDXlo) - -### Specifications - -#### Sensors: - -- temperature -- light - -#### Dimensions: - -- width: 70 mm -- length: 64.5 mm -- height: 19 mm - -#### Weight: - -- 34 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/arduino.mdx b/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/arduino.mdx deleted file mode 100644 index 0a2afcad4..000000000 --- a/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/arduino.mdx +++ /dev/null @@ -1,195 +0,0 @@ ---- -id: arduino -title: Arduino -pagination_label: Arduino -sidebar_label: Arduino -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/arduino ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## ST B-L072Z-LRWAN1 Arduino Guide - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction to Guide - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -## Objective and Requirements - -In this guide, you will learn: - -- How to setup your environment -- How to build and program a basic application that will send packets over the Helium Network -- Verify real-time packets sent to the Helium Console via Hotspot that's in range - -For this example, you will need the following: - -### Hardware - -- [STMicroelectronics B-L072Z-LRWAN1 Discovery kit](https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -- [Arduino software \(IDE\)](https://www.arduino.cc/en/Main/Software) -- [Arduino Core for STM32L0](https://github.com/GrumpyOldPizza/ArduinoCore-stm32l0) -- [Helium Console](https://console.helium.com/) - -## Hardware Setup - -To start you’ll just need to install the included antenna. - -We'll be using the ST-Link debugger on the Discovery board, so you'll want to connect the micro-USB -B connector to the micro-USB port labeled `CN7 USB STLINK`. - - - -If you will be running the device using the AAA battery supply, you will need to remove a resistor -on the underside of the board. We can just move it over to one of the pads and leave it attached for -later. **You don't have to worry about this right now, as we will be powering the board off the -MicroUSB connection.** - - - -### Required Driver \(Windows Only\) - -Download driver [here](https://www.st.com/en/development-tools/stsw-link009.html). - -That’s it for the hardware setup! Next we will setup your environment. - -### Getting the Arduino IDE - -Download and install the latest version of [Arduino IDE](https://www.arduino.cc/en/Main/Software) -for your preferred OS. - -- [Windows](https://www.arduino.cc/en/Guide/Windows) -- [Linux](https://www.arduino.cc/en/Guide/Linux) -- [Mac OSX](https://www.arduino.cc/en/Guide/MacOSX) - -### STM32L0 Core Support & Libraries - -The ST B-L072Z-LRWAN1 requires one package to be installed follow the instructions below. - -#### Arduino Core for STM32L0 - -To install, open your Arduino IDE: - -1. Navigate to **\(File > Preferences\), \(Arduino > Preferences\) on MacOS.** -2. Find the section at the bottom called **Additional Boards Manager URLs:** - - - -1. Add this URL in the text box: - -```text -https://grumpyoldpizza.github.io/ArduinoCore-stm32l0/package_stm32l0_boards_index.json -``` - -1. Close the Preferences windows - -Next, to install this board support package: - -1. Navigate to \(**Tools > Boards > Boards Manager...\)** -2. Search for **Tlera Corp STM32L0 Boards** -3. Select the newest version and click Install - -### Programming **Example Sketch** - -Now that we have the required Arduino board support and libraries installed, lets program the board -with the provided example sketch. - -To create a new Arduino sketch, open your Arduino IDE, \(**File > New\).** Next, replace the -template sketch with the sketch found -[here](https://raw.githubusercontent.com/helium/longfi-arduino/master/ST-B-L072Z-LRWAN1/longfi-us915/longfi-us915.ino), -copy and paste the entirety of it. - -Next we'll need to fill in the AppEUI, DevEUI, and AppKey, in the sketch, which you can find on the -device details page on Console. For this sketch you do not need to modify the formatting of the EUIs -and Key at all, simply copy and paste them as is. - - - -At the top of the sketch, replace the three **FILL_ME_IN** fields, with the matching field from -Console, example shown below. - - - -### Selecting Board - -Next, we need to select the correct board to build for in the Arduino IDE. Navigate to \(**Select -Tools > Board: > B-L072Z-LRWAN1\).** - -### Selecting Port - -We're almost ready to upload our sketch, the very last step is to select the correct Serial port in -the Arduino IDE. Navigate to \(**Tools > Port: COM\# or /dev/ttyACM\#** **or usbmodem\)** -depending on whether you are on Windows, Mac, or Linux. - -### Upload Sketch - -We're finally ready to upload our sketch to the board. In the Arduino IDE, click the right arrow -button, or navigate to \(**Sketch > Upload\),** to build and upload your new firmware to the -board. You should see something similar to the image below at the bottom of your Arduino IDE, when -the upload is successful. - - - -### Viewing Serial Output - -When your firmware update completes, the board will reset, and begin by joining the network. Let's -use the Serial Monitor in the Arduino IDE to view the output from the board. Navigate to \(**Tools -> Serial Monitor**\), you should begin to see output similar to below. - - - -Now let's head back to [Helium Console](https://console.helium.com) and look at our device page, you -should see something similar to the screenshot below. - - - -Congratulations! You have just transmitted data on the Helium network! The next step is to learn how -to use your device data to build applications, visit our Integrations docs -[here](/use-the-network/console/integrations). diff --git a/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/platformio.mdx b/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/platformio.mdx deleted file mode 100644 index 4445911fd..000000000 --- a/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/platformio.mdx +++ /dev/null @@ -1,285 +0,0 @@ ---- -id: platformio -title: PlatformIO -pagination_label: PlatformIO -sidebar_label: PlatformIO -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/platformio ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## ST B-L072Z-LRWAN1 PlatformIO Guide - -import Tabs from '@theme/Tabs' -import TabItem from '@theme/TabItem' - -## Introduction - -:::important - -Before we begin, please make sure you've followed the steps from this guide, which goes over some -initial setup steps. - -::: - -### Objective and Requirements - -In this guide, you will learn: - -- What hardware and software are required -- Where to find additional WisBlock documentation as well as links to hardware retail outlets -- Software required -- Where to find sample embedded application projects - -For these examples, you will need the following: - -### Hardware - -- [STMicroelectronics B-L072Z-LRWAN1 Discovery kit](https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html) -- Micro USB Type B Cable - - [Example](https://www.amazon.com/AmazonBasics-Male-Micro-Cable-Black/dp/B0719H12WD/ref=sr_1_2_sspa?) - -### Software - -The following products are required. - -- [VSCode \(IDE)](https://code.visualstudio.com/) - - [PlatformIO \(VScode Extension)](https://platformio.org/) -- [Helium Console](https://www.helium.com/console) - -### PlatformIO - An Easier Way to Develop Embedded Applications - -[PlatformIO ](https://platformio.org/)is a cross-platform, cross-architecture, multiple framework, -professional tool for embedded systems engineers and for software developers who write applications -for embedded products. - -[PlatformIO ](https://platformio.org/)provides developers with a modern integrated development -environment -\([Cloud & Desktop IDE](https://docs.platformio.org/en/latest/integration/ide/index.html#ide)\) that -works cross-platform, supports many different software development kits \(SDKs\) or -[Frameworks](https://docs.platformio.org/en/latest/frameworks/index.html#frameworks), and includes -sophisticated debugging -\([PIO Unified Debugger](https://docs.platformio.org/en/latest/plus/debugging.html#piodebug)\), unit -testing -\([PIO Unit Testing](https://docs.platformio.org/en/latest/plus/unit-testing.html#unit-testing)\), -automated code analysis -\([PIO Check](https://docs.platformio.org/en/latest/plus/pio-check.html#piocheck)\), and remote -management \([PIO Remote](https://docs.platformio.org/en/latest/plus/pio-remote.html#pioremote)\). -It is architected to maximize flexibility and choice by developers, who can use either graphical or -command line editors -\([PlatformIO Core \(CLI\)](https://docs.platformio.org/en/latest/core/index.html#piocore)\), or -both. - -If you are used to developing using the Arduino IDE but constantly feel constrained by the -environment, you are going to love what [PlatformIO ](https://platformio.org/)opens up for you. - - -The many widget views available within PlatformIO. -

- -This guide will walk through installing PlatformIO and deploying a Helium Arduino program on the ST -Discovery Development Kit. Let's do it. - -### Installing PlatformIO - -[Download ](https://code.visualstudio.com/)and install Microsoft's Visual Studio Code, PlatformIO -IDE is built on top of it. - -{% embed url="https://code.visualstudio.com/\#alt-downloads" %} - -1. Open VSCode Extension Manager -2. Search for official PlatformIO IDE extension -3. Install PlatformIO IDE. - \([https://marketplace.visualstudio.com/items?itemName=platformio.platformio-ide](https://marketplace.visualstudio.com/items?itemName=platformio.platformio-ide)\) - - - -It is highly recommended to give the quick-start guide a read. It will help you navigate the new -interface. -[https://docs.platformio.org/en/latest/integration/ide/vscode.html\#quick-start](https://docs.platformio.org/en/latest/integration/ide/vscode.html#quick-start) - -In this tutorial, I will be using the -[Helium Developer Kit](https://developer.helium.com/devices/devkit). - - - -Once PlatformIO is installed, you should be welcomed to VSCode with the following "PIO Home" screen: - - - -### Starting a new PlatformIO Project - -Let's click on "New Project" to get started. - -Enter a project name and select the following board: - - - -We will be using the Arduino Framework, so go ahead and click "Finish". - -This may take a bit on the first run, but you should soon be left with a project that looks as such: - - - -If we look into `src/main.cpp`, we see the familiar empty Arduino sketch structure: - - - -Let's take a second here to look at the `platformio.ini` file in the root of our new project: - - - -Notice that we specify the environment that we are going to be developing in using the following -variables: - -- platform -- board -- framework - -At this point, you may click the **PlatformIO Build** checkbox in the status bar, and the project -will build \(just don't expect it to do anything yet\): - - - -You may notice something unexpected here \(but very cool, and we will get into that here in just a -bit\): - - - - - -Above, PlatformIO "knew" what platform we were building on and installed what was necessary. This -will come in handy, as we can add libraries into our **`platformio.ini`** file, and they will be -added in at build time. - -If, on the **PIO Home** page, you select the "Devices" icon on the left, you will see the physical -devices that are connected to your development machine, and what ports they are connected to: - - - -Notice that under **Description**, it says we are running "JLink" rather than "ST-Link". If we were -to attempt to flash the board at this point, we would get a failure that looked like this: - -```text -Configuring upload protocol... -AVAILABLE: blackmagic, jlink, mbed, stlink -CURRENT: upload_protocol = stlink -Uploading .pio\build\disco_l072cz_lrwan1\firmware.elf -xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28) -Licensed under GNU GPL v2 -For bug reports, read - http://openocd.org/doc/doxygen/bugs.html -debug_level: 1 - -srst_only separate srst_nogate srst_open_drain connect_deassert_srst - -Error: open failed -in procedure 'program' -** OpenOCD init failed ** -shutdown command invoked - -*** [upload] Error 1 -===================================================================================== [FAILED] Took 16.63 seconds ===================================================================================== -The terminal process terminated with exit code: 1 - -``` - -What happened here? Well, we have this board set up to use a `SEGGER JTAG` interface rather than the -`ST-Link` interface that is integrated into the Discovery board. There are a number of advantages of -this approach, and I would _highly_ suggest doing this. It will make your development iteration -process much faster. - -Luckily, `SEGGER` has provided a method to \(non-destructively\) replace the ST-Link on our board -with a JTAG interface. - - - -[Head here](https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/) -to walk through the simple process. - -We then need to add one additional line to our `platformio.ini` file to let PlatformIO know that we -will be using a JTAG interface to our board \(written as `jlink` in your file\): - - - -The next time we build and attempt to upload our project, we will be presented with the following -Terms of Use: - - - -Accept this agreement, and you should see the following popup: - - - -And there you have it. At this point, we have successfully programmed an empty sketch onto our -Helium Developer Kit using PlatformIO! Check out the -[Helium LongFi PlatformIO repo](https://github.com/helium/longfi-platformio) for some example -programs to get you started. - -**Go forth and build magical things.** diff --git a/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/st-b-l072z-lrwan1.mdx b/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/st-b-l072z-lrwan1.mdx deleted file mode 100644 index 3cec7251a..000000000 --- a/docs/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/st-b-l072z-lrwan1.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: st-b-l072z-lrwan1 -title: St B L072Z Lrwan1 -pagination_label: St B L072Z Lrwan1 -sidebar_label: St B-L072Z-Lrwan1 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## ST B-L072Z-LRWAN1 - - - -The ST B-L072Z-LRWAN1 LoRaWAN development board includes the popular -[Murata CMWX1ZZABZ-091](https://wireless.murata.com/type-abz-078.html) module, which is powered by a -[STM32L072CZ ](https://www.st.com/en/microcontrollers-microprocessors/stm32l072cz.html)microcontroller -and [SX1276 ](https://www.semtech.com/products/wireless-rf/lora-transceivers/sx1276)transceiver. The -board also includes a fully featured ST-LINK/V2-1 embedded debug tool interface, LEDs, push-buttons, -antenna, Arduino™ Uno V3 connectors and USB OTG connector in Micro-B format. Paired with the ST -X-NUCLEO-IKS01A3 Sensor Expansion Board, this kit will enable you to rapidly develop and test your -end device applications on the Helium Network. To start transmitting data with the board, please see -one of the guides below. - -### Resources - -- [Product Page](https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html) -- [Manual](https://www.st.com/resource/en/user_manual/dm00352032-getting-started-with-ultralowpower-stm32l0-and-lora-discovery-kit-stmicroelectronics.pdf) -- [Schematic ](https://www.st.com/content/ccc/resource/technical/layouts_and_diagrams/schematic_pack/group1/0d/b2/51/b1/82/cd/44/42/X-NUCLEO-IKS01A3_SCHEMATIC/files/x-nucleo-iks01a3_schematic.pdf/jcr:content/translations/en.x-nucleo-iks01a3_schematic.pdf) - -### Firmware Quickstart Guides - -- [Arduino Guide](/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/arduino) -- [PlatformIO Guide](/use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/platformio) diff --git a/docs/use-the-network/devices/devices.mdx b/docs/use-the-network/devices/devices.mdx deleted file mode 100644 index cfe881b71..000000000 --- a/docs/use-the-network/devices/devices.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -id: devices -title: Helium Devices -pagination_label: Helium Devices -sidebar_label: Helium Devices -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices ---- - -The Helium Network supports any LoRaWAN capable device meeting the v1.0.2, v1.0.3, or v1.0.4 -specification. - -:::info - -There are thousands of compatible LoRaWAN devices. The devices shown here do not represent all -available devices. - -::: - -### Complete Device Solutions - -Please visit Users under our [Helium Ecosystem](https://www.helium.com/ecosystem) catalog for -companies offering complete end-to-end device solutions. - -### Ready to Use Devices - -For those looking to create a solution with purpose-built end devices, our ready to use section -provides device references and onboarding guides for some of the most well-known manufactures. - -[Browse Devices](/use-the-network/devices/ready-to-use) - -### Development Devices - -If you are looking to develop a device for a new application, then our development section provides -references and onboarding guides for some of the most popular development boards and modules -available. - -- [Browse Devices](/use-the-network/devices/development) -- [Quickstart Guides](/use-the-network/devices/development/quickstart-guides) diff --git a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-compact-tracker.mdx b/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-compact-tracker.mdx deleted file mode 100644 index d59ab0d7d..000000000 --- a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-compact-tracker.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: abeeway-compact-tracker -title: Abeeway Compact Tracker -pagination_label: Abeeway Compact Tracker -sidebar_label: Abeeway Compact Tracker -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/abeeway/abeeway-compact-tracker ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Abeeway Compact Tracker - -Highly versatile multi-mode tracker with a compact and robust form factor, designed to resist harsh -surroundings enabling you to perform seamless asset tracking and management in any industrial -environment – whether it’s for heavy-duty assets or small equipment, taking advantage of its long -battery autonomy. - - - -### Resources - -- [Product Page](https://www.abeeway.com/compact-tracker/) -- [Datasheet](https://www.abeeway.com/wp-content/uploads/2023/05/Abeeway_Compact-data-sheet_2023-v2.0.pdf) -- [Reseller - Actility](https://market.thingpark.com/abeeway-compact-tracker.html) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- accelerometer -- GPS -- temperature - -#### Dimensions: - -- width: 112 mm -- length: 66 mm -- height: 33 mm - -#### Weight: - -- 190 grams - -#### Battery: - -- type: 3x AA/3.6V Li-SOCl2 -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-geolocation-module.mdx b/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-geolocation-module.mdx deleted file mode 100644 index 0f2cfa559..000000000 --- a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-geolocation-module.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: abeeway-geolocation-module -title: Abeeway Geolocation Module -pagination_label: Abeeway Geolocation Module -sidebar_label: Abeeway Geolocation Module -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/abeeway/abeeway-geolocation-module ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Abeeway Geolocation Module - -The Abeeway Geolocation Module is a multi-technology fused location LPWAN module designed as the -ideal platform to develop a wide range of IoT tracking solutions, minimizing the Total Cost of -Ownership (TCO) of IoT geolocation use cases. It allows your engineering to focus on the use case, -to optimize time-to-market and cost by using less complex PCBs (all high-density devices being -encapsulated), to reduce certification risk and budget, as well as testing time and cost for mass -production. - - - -### Resources - -- [Product Page](https://www.abeeway.com/abeeway-geolocation-module/) -- [Datasheet](https://www.abeeway.com/wp-content/uploads/2022/04/Abeeway_Geolocation-module-data-sheet_2022-v05.pdf) -- [Reseller - Actility](https://www.actility.com/) - -### Specifications - -#### Sensors: - -- accelerometer -- GPS -- temperature - -#### Dimensions: - -- width: 17 mm -- length: 17.5 mm - -#### Weight: - -- 10 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-industrial-tracker.mdx b/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-industrial-tracker.mdx deleted file mode 100644 index 506d1fb4a..000000000 --- a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-industrial-tracker.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: abeeway-industrial-tracker -title: Abeeway Industrial Tracker -pagination_label: Abeeway Industrial Tracker -sidebar_label: Abeeway Industrial Tracker -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/abeeway/abeeway-industrial-tracker ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Abeeway Industrial Tracker - -Multi-mode tracker with a large battery designed to resist harsh surroundings enabling you to -perform seamless asset tracking and management in any industrial environment, whether it’s for -heavy-duty assets, inventory or livestock, taking advantage of its extraordinary battery autonomy. - - - -### Resources - -- [Product Page](https://www.abeeway.com/industrial-tracker/) -- [Datasheet](https://www.abeeway.com/wp-content/uploads/2023/05/Abeeway_Products_Industrial_2022-V1.6.pdf) -- [Reseller - Actility](https://market.thingpark.com/abeeway-industrial-tracker-v2.html) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- accelerometer -- GPS -- temperature - -#### Dimensions: - -- width: 76 mm -- length: 145 mm -- height: 42 mm - -#### Weight: - -- 240 grams - -#### Battery: - -- type: Lithium-thionyl Chloride Type D -- replaceable: False - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-micro-tracker.mdx b/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-micro-tracker.mdx deleted file mode 100644 index d32678a98..000000000 --- a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-micro-tracker.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: abeeway-micro-tracker -title: Abeeway Micro Tracker -pagination_label: Abeeway Micro Tracker -sidebar_label: Abeeway Micro Tracker -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/abeeway/abeeway-micro-tracker ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Abeeway Micro Tracker - -Multi-mode, versatile and multi-purpose tracker. With its small size and long battery life, it is -the ideal product for numerous tracking applications of things of value, people or pets. At the -touch of a button, you can have access to a variety of functionalities personalized for your needs. - - - -### Resources - -- [Product Page](https://www.abeeway.com/micro-tracker/) -- [Datasheet](https://www.abeeway.com/wp-content/uploads/2023/05/Abeeway_Products_Micro_B_2022-V2.6.pdf) -- [Reseller - Actility](https://market.thingpark.com/abeeway-micro-tracker-v3.html) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- accelerometer -- GPS -- temperature - -#### Dimensions: - -- width: 34 mm -- length: 59 mm -- height: 13 mm - -#### Weight: - -- 21 grams - -#### Battery: - -- type: Lithium Polymer -- replaceable: False -- rechargeable: 3.7V / 0.45 Ah - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-smart-badge.mdx b/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-smart-badge.mdx deleted file mode 100644 index 5b0323c09..000000000 --- a/docs/use-the-network/devices/ready-to-use/abeeway/abeeway-smart-badge.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: abeeway-smart-badge -title: Abeeway Smart Badge -pagination_label: Abeeway Smart Badge -sidebar_label: Abeeway Smart Badge -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/abeeway/abeeway-smart-badge ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Abeeway Smart Badge - -Portable multi-mode tracker in an ID card format. This device is ideal for tracking, zone -notification and monitoring of workforce safety and security. Simple to use, a single button gives -you access to the numerous functionalities you may personalize for your needs, e.g., as a Panic/SOS -Button. A local zoning feature is able to signal danger zones with an 80db buzzer. - - - -### Resources - -- [Product Page](https://www.abeeway.com/smart-badge/) -- [Datasheet](https://www.abeeway.com/wp-content/uploads/2023/05/Abeeway_Badge-data-sheet_2022-v3.1B.pdf) -- [Reseller - Actility](https://market.thingpark.com/abeeway-smart-badge.html) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- accelerometer -- GPS -- temperature - -#### Dimensions: - -- width: 68 mm -- length: 104 mm -- height: 11 mm - -#### Weight: - -- 64 grams - -#### Battery: - -- type: Lithium Polymer -- replaceable: False -- rechargeable: 3.7V / 1.3 Ah - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/adeunis/adeunis-field-test-device.mdx b/docs/use-the-network/devices/ready-to-use/adeunis/adeunis-field-test-device.mdx deleted file mode 100644 index c11c88d08..000000000 --- a/docs/use-the-network/devices/ready-to-use/adeunis/adeunis-field-test-device.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -id: adeunis-field-test-device -title: Adeunis Field Test Device -pagination_label: Adeunis Field Test Device -sidebar_label: Adeunis Field Test Device -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/adeunis/adeunis-field-test-device ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Adeunis Field Test Device - - - -### Introduction - -The Adeunis Field Test Device (ARF8124A LoRaWAN US902-928) is a great tool for network testing. It -allows you to rapidly test network coverage at specific geographical positions to verify that -devices will have coverage. - -### Resources - -[Product Page](https://www.adeunis.com/en/produit/ftd-iot-lorawan-network-tester-915-923/) - -[Datasheet](https://www.adeunis.com/wp-content/uploads/2020/03/Datasheet_Field_Test_Device_AS923-US915-RC4-en.pdf) - -[Manual](https://adeunis.notion.site/User-Guide-FIELD-TEST-DEVICE-LoRaWAN-US-902-928-00d3edb05f5c4423b3cc03454e4f0d08) - -### Add Device to Console - -To start, you'll need to add your device to Console. You should have been provided with a DevEUI, -AppEUI, and AppKey from the seller of the device. Follow our -[quickstart](/use-the-network/console/quickstart) for instructions on how to add a new device to -Console. - -### Device Configuration - -The following device configuration changes are required for the device to function properly on the -Helium Network. Although the Adeunis IoT Configurator application makes the device configuration -much easier, it does not allow you to change all the required settings, so we must use a serial -utility. We are using Realterm for our serial utility, but any will work, just be sure to use the -correct serial settings and send the commands in the correct format. - -[Realterm - Serial Utility](https://sourceforge.net/projects/realterm/) - -#### Serial Settings - -- Rate 115 200 bps -- Parity None -- Data 8 -- Stop Bit 1 - - - -#### Activate Command Mode - -Only this command requires that you send the command in number form. - -Enter Command Mode Command: `0xFF 0xFF 0xFF 0x2B 0x2B 0x2B` - - - -#### Unblock Operating Range - -Command: `ATT63 PROVIDER` - -This command and all that follow should be sent using the ASCII format with a carriage return \(CR\) -at the end. - - - -#### Select Sub band 2 - -Set Value Command: `ATS259=2` - -Read Value Command: `ATS259?` - -#### Uplink Unconfirmed - -Set Value Command: `ATS382=0` - -Read Value Command: `ATS382?` - -#### ADR ON - -Set Value Command: `ATS220=1` - -Read Value Command: `ATS220?` - -#### Set Transmission Interval to 5 seconds - -Set Value Command: `ATS380=5` - -Read Value Command: `ATS380?` - -#### Save Configuration - -Command: `AT&W` - -#### Exit Command View - -Command: `ATO` - -You should see the following responses below from the device after entering the above commands. - - - -### Sending Packets - -After exiting command mode and on every power on, the device will immediately attempt to join the -network. You will see the status of the join attempt on the Uplink/Downlink screen, please see the -manual for more details on this screen. Once the device has joined press the large push button in -the center of the device to send the uplink payload. - - diff --git a/docs/use-the-network/devices/ready-to-use/aquascope/bvs.mdx b/docs/use-the-network/devices/ready-to-use/aquascope/bvs.mdx deleted file mode 100644 index 37d026070..000000000 --- a/docs/use-the-network/devices/ready-to-use/aquascope/bvs.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: bvs -title: Ball Valve Servo -pagination_label: Bvs -sidebar_label: Ball Valve Servo -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/aquascope/bvs ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Ball Valve Servo - -Retrofittable Motor Actuator to operate Ball Valves - - - -### Resources - -- [Product Page](https://www.aqua-scope.com/ball-valve-servo.html) -- [Datasheet](https://www.aqua-scope.com/fileadmin/docs/BVSLWE01_DataSheet.pdf) -- [Reseller - Aqua-Scope WTB](https://www.aqua-scope.com/buy.html) -- [Video](https://www.youtube.com/watch?v=SsR9Trlw3SU) - -### Specifications - -#### LoRaWAN device type: - -- Class C end-device - -#### Sensors: - -- temperature - -#### Dimensions: - -- width: 236 mm -- length: 179 mm -- height: 114 mm - -#### Weight: - -- 1147 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/aquascope/wwd.mdx b/docs/use-the-network/devices/ready-to-use/aquascope/wwd.mdx deleted file mode 100644 index 91780ce6c..000000000 --- a/docs/use-the-network/devices/ready-to-use/aquascope/wwd.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: wwd -title: Flood Sensor -pagination_label: Wwd -sidebar_label: Flood Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/aquascope/wwd ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Flood Sensor - -Waterproof Flood Sensor with additional sensor pad - - - -### Resources - -- [Product Page](https://www.aqua-scope.com/flood-sensor.html) -- [Datasheet](https://www.aqua-scope.com/fileadmin/docs/WWDLWE_DataSheet.pdf) -- [Reseller - Aqua-Scope WTB](https://www.aqua-scope.com/buy.html) -- [Video](https://www.youtube.com/watch?v=SsR9Trlw3SU) - -### Specifications - -#### LoRaWAN device type: - -- Class C end-device - -#### Sensors: - -- temperature -- water - -#### Dimensions: - -- width: 23 mm -- length: 68 mm -- height: 23 mm - -#### Weight: - -- 27 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/beiselen/radar.mdx b/docs/use-the-network/devices/ready-to-use/beiselen/radar.mdx deleted file mode 100644 index 21586b889..000000000 --- a/docs/use-the-network/devices/ready-to-use/beiselen/radar.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: radar -title: DigiSilo Radar Sensor -pagination_label: DigiSilo Radar Sensor -sidebar_label: DigiSilo Radar Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/beiselen/radar ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DigiSilo Radar Sensor - -DigiSilo is a compact distance measurement device and presence detector. Its sensor is a low power, -high precision, pulsed short-range radar sensor and can measure in a distance range from 50 cm to 7 -meters. By operating in the 60 GHz unlicensed ISM radio band, the radar sensor provides robust -performance without interference from noise, dust, color nor direct or indirect light. DigiSilo is -made for silo monitoring with different mediums like grain, feedstock, flour, or liquids. The device -is designed to be mounted outside on top of the non-metallic silo. - - - -### Specifications - -#### Sensors: - -- distance -- motion - -#### Dimensions: - -- width: 125 mm -- length: 280 mm -- height: 60 mm - -#### Weight: - -- 725 grams - -#### Battery: - -- type: lithium-ion -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/boatofficer/boatofficerblue.mdx b/docs/use-the-network/devices/ready-to-use/boatofficer/boatofficerblue.mdx deleted file mode 100644 index 18eabc5e3..000000000 --- a/docs/use-the-network/devices/ready-to-use/boatofficer/boatofficerblue.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: boatofficerblue -title: Boatofficer Blue -pagination_label: Boatofficer Blue -sidebar_label: Boatofficer Blue -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/boatofficer/boatofficerblue ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## BoatOfficer Blue - -With BoatOfficer Blue you can monitor your boat, while you’re not around. E.g., position, battery -voltage and temperature are sent via TheThingsNetwork to the BoatOfficer app on your phone. Events -like water ingress detection trigger an immediate push notification. - - - -### Resources - -- [Product Page](https://www.boatofficer.com/products/BoatOfficerBlue) -- [Reseller - BoatOfficer Webshop](https://shop.boatofficer.com/en/) - -### Specifications - -#### Sensors: - -- button -- GPS -- temperature -- voltage - -#### Dimensions: - -- width: 90 mm -- length: 40 mm -- height: 140 mm - -#### Weight: - -- 250 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/bosch/tps110.mdx b/docs/use-the-network/devices/ready-to-use/bosch/tps110.mdx deleted file mode 100644 index af111d379..000000000 --- a/docs/use-the-network/devices/ready-to-use/bosch/tps110.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -id: tps110 -title: Parking Lot Sensor -pagination_label: Parking Lot Sensor -sidebar_label: Parking Lot Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/bosch/tps110 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Parking Lot Sensor - -The wireless smart parking sensor for detecting parking space occupancy. - - - -### Resources - -- [Product Page](https://www.bosch-connectivity.com/products/connected-mobility/parking-lot-sensor/downloads/) -- [Datasheet](https://www.bosch-connectivity.com/media/product_detail_pls/cost_pls_product_data_sheet_en_v221130.pdf) -- [Video](https://youtu.be/HYv50apV-jA) -- [Manual](https://www.bosch-connectivity.com/media/product_detail_pls/pls_usermanual_2-0_en-de-fr-it-es-nl-da-pt-gr-ro.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- magnetometer -- GPS -- temperature -- radar - -#### Dimensions: - -- diameter: 145 mm -- height: 30 mm - -#### Weight: - -- 215 grams - -#### Battery: - -- type: Lithium battery (Li-SOCI2 / 3.6V / 1200 mAh) -- replaceable: False - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/comtac/lpn-km.mdx b/docs/use-the-network/devices/ready-to-use/comtac/lpn-km.mdx deleted file mode 100644 index 90c445b71..000000000 --- a/docs/use-the-network/devices/ready-to-use/comtac/lpn-km.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: cluey-km -title: Cluey KM - Short-Circuit Monitor -pagination_label: Cluey KM - Short-Circuit Monitor -sidebar_label: Cluey KM - Short-Circuit Monitor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/comtac/cluey-km ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Cluey KM - Short-circuit Monitor - -Cluey KM is specially designed for the acquisition and transmission of short-circuit and ground -fault messages from transformer stations. - - - -### Resources - -- [Product Page](https://www.comtac.ch/en/produkte/lora/cluey/index.html#KM) -- [Datasheet](https://www.comtac.ch/cms/upload/downloads/dokumente/C-FS-Cluey_KM_220613_EN.pdf) - -### Specifications - -#### Sensors: - -- digital input -- temperature -- battery -- button - -#### Dimensions: - -- width: 115 mm -- length: 130 mm -- height: 55 mm - -#### Weight: - -- 330 grams - -#### Battery: - -- type: LiMn02 5Ah Backup battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/comtac/lpn-td1.mdx b/docs/use-the-network/devices/ready-to-use/comtac/lpn-td1.mdx deleted file mode 100644 index a160adfd3..000000000 --- a/docs/use-the-network/devices/ready-to-use/comtac/lpn-td1.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: lpn-td1 -title: LPN TD-1 Tracker -pagination_label: LPN TD-1 Tracker -sidebar_label: LPN TD-1 Tracker -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/comtac/lpn-td1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LPN TD-1 Tracker - -Designed for LoRaWAN - Indoor/outdoor positioning on request with GPS or WiFi. - - - -### Resources - -- [Product Page](https://www.comtac.ch/en/products/tracking/tracker/lpn-td-1-tracker.html) -- [Video](https://www.youtube.com/watch?v=MYK1AK2qeBk) - -### Specifications - -#### Sensors: - -- GPS -- Wi-Fi SSID -- temperature -- battery - -#### Dimensions: - -- width: 113 mm -- length: 52 mm -- height: 25 mm - -#### Weight: - -- 85 grams - -#### Battery: - -- type: Rechargeable Li-Po Battery 1.4Ah -- replaceable: False - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/comtac/lpn-tsm.mdx b/docs/use-the-network/devices/ready-to-use/comtac/lpn-tsm.mdx deleted file mode 100644 index a9340205c..000000000 --- a/docs/use-the-network/devices/ready-to-use/comtac/lpn-tsm.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: lpn-tsm -title: LPN TSM - Transformer Station Monitor -pagination_label: LPN TSM - Transformer Station Monitor -sidebar_label: LPN TSM - Transformer Station Monitor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/comtac/lpn-tsm ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LPN TSM - Transformer Station Monitor - -Transmission of operating status and error messages from transformer stations. - - - -### Resources - -- [Product Page](https://www.comtac.ch/en/products/lora/condition-monitoring/lpn-tsm-tranformer-station-monitor.html) -- [Datasheet](https://www.comtac.ch/cms/upload/produktdokumentation/TSM_NTN_E1398/TSM_Datasheet_[EN_V00.20]_E1398.pdf) - -### Specifications - -#### Sensors: - -- temperature -- battery -- voltage -- current -- digital input - -#### Dimensions: - -- width: 162 mm -- length: 252 mm -- height: 90 mm - -#### Weight: - -- 1233 grams - -#### Battery: - -- type: LiMn02 5Ah Backup battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-5tm.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-5tm.mdx deleted file mode 100644 index 45a8201f9..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-5tm.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: dl-5tm -title: DL-5TM -pagination_label: DL-5TM -sidebar_label: DL-5TM -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/decentlab/dl-5tm ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-5TM - -Legacy Soil Moisture and Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/legacy-soil-moisture-and-temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-5TM-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- moisture -- temperature -- battery - -#### Dimensions: - -**Probe:** - -- width: 34 mm -- length: 109 mm -- height: 10 mm - -**Sensor:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- probe: 155 grams (including cable) -- sensor: 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-atm22.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-atm22.mdx deleted file mode 100644 index ee03187f4..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-atm22.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: dl-atm22 -title: DL-ATM22 -pagination_label: DL-ATM22 -sidebar_label: DL-ATM22 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/decentlab/dl-atm22 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-ATM22 - -Wind Speed, Wind Direction and Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/wind-speed-wind-direction-and-temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-ATM22-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- horizontal wind speed -- wind direction -- temperature -- tilt -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -- diameter: 100 mm -- height: 160 mm - -#### Weight: - -- 1020 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-atm41.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-atm41.mdx deleted file mode 100644 index d614fccd2..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-atm41.mdx +++ /dev/null @@ -1,68 +0,0 @@ ---- -id: dl-atm41 -title: DL-ATM41 -pagination_label: DL-ATM41 -sidebar_label: DL-ATM41 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/decentlab/dl-atm41 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-ATM41 - -Eleven Parameter Weather Station for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/eleven-parameter-weather-station-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-ATM41-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- solar radiation -- precipitation -- lightning strike count / average distance -- horizontal wind speed -- wind direction -- temperature -- vapor pressure -- barometer -- relative humidity -- tilt -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- diameter: 100 mm -- height: 340 mm - -#### Weight: - -- 1290 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-ctd10.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-ctd10.mdx deleted file mode 100644 index 21d3692b7..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-ctd10.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: dl-ctd10 -title: DL-CTD10 -pagination_label: DL-CTD10 -sidebar_label: DL-CTD10 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/decentlab/dl-ctd10 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-CTD10 - -Pressure / Liquid Level, Temperature and Electrical Conductivity Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/pressure-/-liquid-level-temperature-and-electrical-conductivity-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-CTD10-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- electrical conductivity -- water depth -- temperature -- freezing flag -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor head:** - -- diameter: 34 mm -- length: 90 mm - -#### Weight: - -- 1090 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-002.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-002.mdx deleted file mode 100644 index f07f3b1e2..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-002.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: dl-dlr2-002 -title: DL-DLR2-002 -pagination_label: DL-DLR2-002 -sidebar_label: DL-DLR2-002 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-002 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-002 - -Pulse Counter Dry Contact Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pulse count -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-003.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-003.mdx deleted file mode 100644 index 5a775dab5..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-003.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: dl-dlr2-003 -title: DL-DLR2-003 -pagination_label: DL-DLR2-003 -sidebar_label: DL-DLR2-003 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-003 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-003 - -Digital Input Dry Contact Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- digital input -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-004.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-004.mdx deleted file mode 100644 index fca449112..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-004.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: dl-dlr2-004 -title: DL-DLR2-004 -pagination_label: DL-DLR2-004 -sidebar_label: DL-DLR2-004 -description: Analog 4 ... 20 mA Sensor Transmitter for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-dlr2.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-004 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-004 - -Analog 4 ... 20 mA Sensor Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- analog input -- current -- 4-20 mA -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-005.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-005.mdx deleted file mode 100644 index f7d099bf5..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-005.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: dl-dlr2-005 -title: DL-DLR2-005 -pagination_label: DL-DLR2-005 -sidebar_label: DL-DLR2-005 -description: Analog 0 ... 3 V Sensor Transmitter for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-dlr2.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-005 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-005 - -Analog 0 ... 3 V Sensor Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- analog input -- voltage -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-006.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-006.mdx deleted file mode 100644 index 2c78941a2..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-006.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: dl-dlr2-006 -title: DL-DLR2-006 -pagination_label: DL-DLR2-006 -sidebar_label: DL-DLR2-006 -description: Analog Potentiometer Sensor Transmitter for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-dlr2.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-006 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-006 - -Analog Potentiometer Sensor Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- analog input -- potentiometer -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-008.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-008.mdx deleted file mode 100644 index 6e1765c1d..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-008.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: dl-dlr2-008 -title: DL-DLR2-008 -pagination_label: DL-DLR2-008 -sidebar_label: DL-DLR2-008 -description: Analog PT100 Sensor Transmitter for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-dlr2.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-008 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-008 - -Analog PT100 Sensor Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- analog input -- temperature -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-010.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-010.mdx deleted file mode 100644 index 1105d93ab..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-010.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: dl-dlr2-010 -title: DL-DLR2-010 -pagination_label: DL-DLR2-010 -sidebar_label: DL-DLR2-010 -description: Dual Pulse Counter Dry Contact Transmitter for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-dlr2.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-010 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-010 - -Dual Pulse Counter Dry Contact Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pulse count -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-012.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-012.mdx deleted file mode 100644 index 6d50e697e..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dlr2-012.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: dl-dlr2-012 -title: DL-DLR2-012 -pagination_label: DL-DLR2-012 -sidebar_label: DL-DLR2-012 -description: Analog Strain Gauge Sensor Transmitter for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-dlr2.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dlr2-012 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DLR2-012 - -Analog Strain Gauge Sensor Transmitter for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/analog-or-digital-sensor-device-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DLR2-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- analog input -- strain -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-ds18.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-ds18.mdx deleted file mode 100644 index d2266300c..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-ds18.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: dl-ds18 -title: DL-DS18 -pagination_label: DL-DS18 -sidebar_label: DL-DS18 -description: Temperature Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-ds18.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-ds18 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DS18 - -Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-DS18-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor head:** - -- diameter: 7 mm -- length: 40 mm - -#### Weight: - -- 500 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dws.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-dws.mdx deleted file mode 100644 index 0767b078d..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-dws.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: dl-dws -title: DL-DWS -pagination_label: DL-DWS -sidebar_label: DL-DWS -description: Weighing Scale for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-dws.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-dws ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-DWS - -Weighing Scale for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/weighing-scale-for-lorawan) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pulse frequency -- weight -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Scale:** - -- width: 156 mm -- length: 325 mm -- height: 28 mm - -#### Weight: - -- 400 grams - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-iam.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-iam.mdx deleted file mode 100644 index cc92f1c61..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-iam.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: dl-iam -title: DL-IAM -pagination_label: DL-IAM -sidebar_label: DL-IAM -description: Indoor Ambiance Monitor Including Co2, TVOC And Motion Sensor For LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-iam.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-iam ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-IAM - -Indoor Ambiance Monitor including CO2, TVOC and Motion Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/indoor-ambiance-monitor-including-co2-tvoc-and-motion-sensor-for-lorawan/) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-IAM-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- CO2 -- TVOC -- temperature -- humidity -- barometer -- ambient light -- PIR motion -- battery - -#### Dimensions: - -- width: 80 mm -- length: 120 mm -- height: 27 mm - -#### Weight: - -- 144 grams (including batteries) - -#### Battery: - -- type: 2x AA alkaline (LR6) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-itst.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-itst.mdx deleted file mode 100644 index 664f03d5f..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-itst.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: dl-itst -title: DL-ITST-001 -pagination_label: DL-ITST-001 -sidebar_label: DL-ITST-001 -description: Infrared Thermometer / Surface Temperature Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-itst.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-itst ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-ITST-001 - -Infrared Thermometer / Surface Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/infrared-thermometer-/-surface-temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-ITST-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- surface temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Surface temperature sensor head:** - -- diameter: 12 mm -- length: 87 mm - -#### Weight: - -- 460 grams (including batteries, sensor and cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-kl66.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-kl66.mdx deleted file mode 100644 index 66fdedd5e..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-kl66.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -id: dl-kl66 -title: DL-KL66 -pagination_label: DL-KL66 -sidebar_label: DL-KL66 -description: Strain / Weight Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-kl66.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-kl66 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-KL66 - -Strain / Weight Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/strain-/-weight-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-KL66-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pulse frequency -- strain -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Strain sensor:** - -- width: 56 mm -- length: 72 mm -- height: 21 mm - -#### Weight: - -- 450 grams (including batteries, sensor and cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-lid.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-lid.mdx deleted file mode 100644 index ca8661f48..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-lid.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: dl-lid -title: DL-LID -pagination_label: DL-LID -sidebar_label: DL-LID -description: Laser Distance / Level Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-lid.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-lid ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-LID - -Laser Distance / Level Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/laser-distance-level-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-LID-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- distance -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- width: 55 mm -- length: 40.2 mm -- height: 35 mm - -#### Weight: - -- 440 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-lp8p.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-lp8p.mdx deleted file mode 100644 index 9f8c8f409..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-lp8p.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -id: dl-lp8p -title: DL-LP8P -pagination_label: DL-LP8P -sidebar_label: DL-LP8P -description: Co2, Temperature, Humidity And Barometric Pressure Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-lp8p.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-lp8p ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-LP8P - -CO2, Temperature, Humidity and Barometric Pressure Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/co2-temperature-humidity-and-barometric-pressure-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-LP8P-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- barometer -- CO2 -- battery - -#### Dimensions: - -- width: 81 mm -- length: 122 mm -- height: 67 mm - -#### Weight: - -- 376 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-mbx.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-mbx.mdx deleted file mode 100644 index 280c2e0b0..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-mbx.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: dl-mbx -title: DL-MBX -pagination_label: DL-MBX -sidebar_label: DL-MBX -description: Ultrasonic Distance / Level Sensor For LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-mbx.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-mbx ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-MBX - -Ultrasonic Distance / Level Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/ultrasonic-distance-/-level-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-MBX-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- distance -- battery - -#### Dimensions: - -- width: 81 mm -- length: 170 mm -- height: 70 mm - -#### Weight: - -- 450 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-optod.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-optod.mdx deleted file mode 100644 index 7a3e2ff79..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-optod.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: dl-optod -title: DL-OPTOD -pagination_label: DL-OPTOD -sidebar_label: DL-OPTOD -description: Optical Dissolved Oxygen And Temperature Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-optod.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-optod ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-OPTOD - -Optical Dissolved Oxygen and Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/optical-dissolved-oxygen-and-temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-OPTOD-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- dissolved oxygen -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- diameter: 25 mm -- length: 146 mm - -#### Weight: - -- 1050 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-par.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-par.mdx deleted file mode 100644 index 4572175cd..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-par.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: dl-par -title: DL-PAR -pagination_label: DL-PAR -sidebar_label: DL-PAR -description: Photosynthetically Active Radiation Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-pxr.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-par ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-PAR - -Photosynthetically Active Radiation Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/photosynthetically-active-radiation-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-PAR-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- solar radiation -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- diameter: 25 mm -- height: 33 mm - -**Leveling plate:** - -- diameter: 80 mm -- height: 8 mm - -#### Weight: - -- 620 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pm.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-pm.mdx deleted file mode 100644 index fd5b0be88..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pm.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: dl-pm -title: DL-PM -pagination_label: DL-PM -sidebar_label: DL-PM -description: Particulate Matter, Temperature, Humidity And Barometric Pressure Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-pm.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-pm ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-PM - -Particulate Matter, Temperature, Humidity and Barometric Pressure Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/particulate-matter-temperature-humidity-and-barometric-pressure-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-PM-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- Particulate Matter (PM) -- temperature -- humidity -- barometer -- battery - -#### Dimensions: - -- width: 81 mm -- length: 122 mm -- height: 67 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - -#### Note: - -- The device requires both an external power supply and batteries. -- External power supply: for the PM sensor exclusively. -- If the external power supply is not connected, the device operates normally, but omitting PM - sensor data. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr21.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr21.mdx deleted file mode 100644 index 0db38383e..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr21.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: dl-pr21 -title: DL-PR21 -pagination_label: DL-PR21 -sidebar_label: DL-PR21 -image: img/use-the-network/devices/ready-to-use/decentlab/dl-pr21.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-pr21 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-PR21 - -Pressure / Liquid Level and Temperature Sensor with G1/4" Pipe Thread for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/pressure-/-liquid-level-and-temperature-sensor-with-g1/4-pipe-thread-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-PR21-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pressure -- temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- diameter: 21 mm -- length: 56 mm - -**Sensor cable:** - -- length: 2 m - -#### Weight: - -- 510 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr26.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr26.mdx deleted file mode 100644 index dc0f56c43..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr26.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: dl-pr26 -title: DL-PR26 -pagination_label: DL-PR26 -sidebar_label: DL-PR26 -description: Pressure / Liquid Level And Temperature Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-pr26.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-pr26 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-PR26 - -Pressure / Liquid Level and Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/pressure-/-liquid-level-and-temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-PR26-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pressure -- temperature -- battery - -#### Dimensions: - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 840 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr36.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr36.mdx deleted file mode 100644 index 6d05800fb..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr36.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: dl-pr36 -title: DL-PR36 -pagination_label: DL-PR36 -sidebar_label: DL-PR36 -description: High-Precision Pressure / Liquid Level And Temperature Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-pr36.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-pr36 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-PR36 - -High-Precision Pressure / Liquid Level and Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/high-precision-pressure-/-liquid-level-and-temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-PR36-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pressure -- temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- diameter: 22 mm -- length: 127 mm - -**Sensor cable:** - -- length: 10 m - -#### Weight: - -- 570 grams (including batteries and sensor, not including cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr36ctd.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr36ctd.mdx deleted file mode 100644 index b953d0693..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pr36ctd.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: dl-pr36ctd -title: DL-PR36CTD -pagination_label: DL-PR36CTD -sidebar_label: DL-PR36CTD -description: - High-Precision Pressure / Liquid Level, Temperature and Electrical Conductivity Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-pr36ctd.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-pr36ctd ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-PR36CTD - -High-Precision Pressure / Liquid Level, Temperature and Electrical Conductivity Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/high-precision-pressure-/-liquid-level-temperature-and-electrical-conductivity-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-PR36CTD-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- pressure -- temperature -- electrical conductivity -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- diameter: 22 mm -- length: 238 mm - -**Sensor cable:** - -- length: 10 m - -#### Weight: - -- 700 grams (including batteries and sensor, not including cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pyr.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-pyr.mdx deleted file mode 100644 index d447ee1f5..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-pyr.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: dl-pyr -title: DL-PYR -pagination_label: DL-PYR -sidebar_label: DL-PYR -description: Total Solar Radiation Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-pxr.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-pyr ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-PYR - -Total Solar Radiation Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/total-solar-radiation-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-PYR-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- solar radiation -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- diameter: 25 mm -- height: 33 mm - -**Leveling plate:** - -- diameter: 80 mm -- height: 8 mm - -#### Weight: - -- 620 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-rhc.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-rhc.mdx deleted file mode 100644 index f9a9e3fd0..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-rhc.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: dl-rhc -title: DL-RHC-001 -pagination_label: DL-RHC-001 -sidebar_label: DL-RHC-001 -description: High-Precision Air Temperature and Humidity Sensor with Radiation Shield for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-rhc.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-rhc-001 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-RHC-001 - -High-Precision Air Temperature and Humidity Sensor with Radiation Shield for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/high-precision-air-temperature-and-humidity-sensor-with-radiation-shield-for-lorawan) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -#### Weight: - -- 500 grams (including batteries, sensor and radiation shield) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-sht35-001.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-sht35-001.mdx deleted file mode 100644 index 38c8cb602..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-sht35-001.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -id: dl-sht35-001 -title: DL-SHT35-001 -pagination_label: DL-SHT35-001 -sidebar_label: DL-SHT35-001 -description: Air Temperature and Humidity Sensor with Radiation Shield for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-sht35-001.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-sht35-001 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-SHT35-001 - -Air Temperature and Humidity Sensor with Radiation Shield for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/air-temperature-and-humidity-sensor-with-radiation-shield-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-SHT35-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- battery - -#### Dimensions: - -**Device including radiation shield:** - -- width: 105 mm -- length: 280 mm -- height: 85 mm - -#### Weight: - -- 585 grams (including batteries and radiation shield) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-sht35-002.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-sht35-002.mdx deleted file mode 100644 index c37301720..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-sht35-002.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -id: dl-sht35-002 -title: DL-SHT35-002 -pagination_label: DL-SHT35-002 -sidebar_label: DL-SHT35-002 -description: Air Temperature and Humidity Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-sht35-002.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-sht35-002 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-SHT35-002 - -Air Temperature and Humidity Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/air-temperature-and-humidity-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-SHT35-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- width: 12 mm -- length: 45 mm -- height: 6 mm - -#### Weight: - -- 425 grams (including batteries, sensor with 2 m cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-smtp.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-smtp.mdx deleted file mode 100644 index 4006d9964..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-smtp.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: dl-smtp -title: DL-SMTP -pagination_label: DL-SMTP -sidebar_label: DL-SMTP -description: Soil Moisture and Temperature Profile Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-smtp.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-smtp ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-SMTP - -Soil Moisture and Temperature Profile Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/soil-moisture-and-temperature-profile-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-SMTP-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- soil moisture -- soil temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Probe:** - -- shaft diameter: 32 mm -- length: 600 mm - -**Cable:** - -- length: 5 m - -#### Weight: - -- 1500 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-tbrg.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-tbrg.mdx deleted file mode 100644 index 0099b101b..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-tbrg.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: dl-tbrg -title: DL-TBRG -pagination_label: DL-TBRG -sidebar_label: DL-TBRG -description: Tipping Bucket Rain Gauge for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-tbrg.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-tbrg ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-TBRG - -Tipping Bucket Rain Gauge for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/tipping-bucket-rain-gauge-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-TBRG-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- precipitation -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Rain gauge:** - -- diameter: 180 mm -- height: 300 mm - -#### Weight: - -- 1530 grams (including batteries, sensor, rain gauge and cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs11.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs11.mdx deleted file mode 100644 index ad1a71f52..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs11.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -id: dl-trs11 -title: DL-TRS11 -pagination_label: DL-TRS11 -sidebar_label: DL-TRS11 -description: Soil Moisture, Temperature and Electrical Conductivity Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-trs1x.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-trs11 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-TRS11 - -Soil Moisture, Temperature and Electrical Conductivity Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/soil-moisture-temperature-and-electrical-conductivity-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-TRS11-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- moisture -- temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- width: 75 mm -- length: 95 mm -- height: 25 mm - -#### Weight: - -- 655 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs12.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs12.mdx deleted file mode 100644 index 961e60ef6..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs12.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: dl-trs12 -title: DL-DRS12 -pagination_label: DL-DRS12 -sidebar_label: DL-DRS12 -description: Soil Moisture, Temperature and Electrical Conductivity Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-trs1x.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-trs12 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-TRS12 - -Soil Moisture, Temperature and Electrical Conductivity Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/soil-moisture-temperature-and-electrical-conductivity-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-TRS12-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- moisture -- temperature -- electrical conductivity -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Sensor:** - -- width: 75 mm -- length: 95 mm -- height: 25 mm - -#### Weight: - -- 655 grams (including batteries and sensor) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs21.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs21.mdx deleted file mode 100644 index 3ac6fd287..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-trs21.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -id: dl-trs21 -title: DL-TRS21 -pagination_label: DL-TRS21 -sidebar_label: DL-TRS21 -description: Soil Water Potential and Temperature Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-trs21.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-trs21 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-TRS21 - -Soil Water Potential and Temperature Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/soil-water-potential-and-temperature-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-TRS21-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- soil water potential -- soil temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**Probe:** - -- width: 35 mm -- length: 96 mm -- height: 15 mm - -**Cable:** - -- length: 5 m - -#### Weight: - -- 565 grams (including batteries, sensor and cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-wrm.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-wrm.mdx deleted file mode 100644 index f027cf9ce..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-wrm.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: dl-wrm -title: DL-WRM-001 -pagination_label: DL-WRM-001 -sidebar_label: DL-WRM-001 -description: Winter Road Maintenance Sensor for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-wrm-001.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-wrm-001 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-WRM-001 - -Winter Road Maintenance Sensor for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/winter-road-maintenance-sensor-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-WRM-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- surface temperature -- air temperature -- sensor head temperature -- humidity -- battery - -#### Dimensions: - -**Device including radiation shield:** - -- width: 105 mm -- length: 280 mm -- height: 85 mm - -**Surface temperature sensor head:** - -- diameter: 12 mm -- length: 87 mm -- length thread: 26 mm (M12 x 1) - -#### Weight: - -- 645 grams (including batteries, radiation shield, surface temperature sensor and cable) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-zn1.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-zn1.mdx deleted file mode 100644 index c534d4952..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-zn1.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: dl-zn1 -title: DL-ZN1-001 -pagination_label: DL-ZN1-001 -sidebar_label: DL-ZN1-001 -description: T-shaped Dendrometer for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-znx.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-zn1-001 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-ZN1-001 - -T-shaped Dendrometer for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/dendrometer-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-ZN-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- potentiometer -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**T-shaped dendrometer plate:** - -- width: 92 mm -- lenght: 190 mm -- height: 8 mm - -#### Weight: - -- 600 grams (including batteries, sensor and T-shaped dendrometer) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/decentlab/dl-zn2.mdx b/docs/use-the-network/devices/ready-to-use/decentlab/dl-zn2.mdx deleted file mode 100644 index 4e504bb4b..000000000 --- a/docs/use-the-network/devices/ready-to-use/decentlab/dl-zn2.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: dl-zn2 -title: DL-ZN2-001 -pagination_label: DL-ZN2-001 -sidebar_label: DL-ZN2-001 -description: T-shaped Dual Dendrometer for LoRaWAN -image: img/use-the-network/devices/ready-to-use/decentlab/dl-znx.jpg -slug: /use-the-network/devices/ready-to-use/decentlab/dl-zn2-001 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## DL-ZN2-001 - -T-shaped Dual Dendrometer for LoRaWAN. - - - -### Resources - -- [Product Page](https://www.decentlab.com/products/dendrometer-for-lorawan) -- [Datasheet](https://cdn.decentlab.com/download/datasheets/Decentlab-DL-ZN-datasheet.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- potentiometer -- battery - -#### Dimensions: - -**Device:** - -- width: 81 mm -- length: 135 mm -- height: 70 mm - -**T-shaped dendrometer plate:** - -- width: 92 mm -- length: 190 mm -- height: 8 mm - -#### Weight: - -- 600 grams (including batteries, sensor and T-shaped dendrometer) - -#### Battery: - -- type: 2x C alkaline (LR14) -- replaceable: True - -#### Note: - -- Dual means here the dendrometer has two displacement transducers. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/develiot/rwmr.mdx b/docs/use-the-network/devices/ready-to-use/develiot/rwmr.mdx deleted file mode 100644 index 076cbd34f..000000000 --- a/docs/use-the-network/devices/ready-to-use/develiot/rwmr.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: rwmr -title: Remote Water Meter Reader -pagination_label: RWMR -sidebar_label: Remote Water Meter Reader -image: img/use-the-network/devices/ready-to-use/develiot/main.png -slug: /use-the-network/devices/ready-to-use/develiot/rwmr ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Remote Water Meter Reader - -The Remote Water Meter Reader is designed to easily connect with standard pulse water meters or -other 3rd party equipment and transmit data wirelessly and autonomously utilizing LoRaWAN network -protocol. - - - -### Resources - -- [Product Page](https://www.tbs.tech/iot-water-consumption-and-loss-tracking/) -- [Datasheet](https://www.tbs.tech/wp-content/uploads/2023/02/Datasheet-Remote-Water-Meter-Reader-EN-v8.3.pdf) - -### Specifications - -#### Sensors: - -- temperature -- battery - -#### Dimensions: - -- width: 35 mm -- length: 120 mm -- height: 35 mm - -#### Weight: - -- 163 grams - -#### Battery: - -- type: AA -- replaceable: True - -#### Note: - -- Develiot is now part of the Telelink Business Services, IoT Technology Group. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/develiot/uaqms.mdx b/docs/use-the-network/devices/ready-to-use/develiot/uaqms.mdx deleted file mode 100644 index 15e0ebcb2..000000000 --- a/docs/use-the-network/devices/ready-to-use/develiot/uaqms.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: uaqms -title: Urban Air Quality Monitoring Station -pagination_label: UAQMS -sidebar_label: Urban Air Quality Monitoring Station -image: img/use-the-network/devices/ready-to-use/develiot/station.jpg -slug: /use-the-network/devices/ready-to-use/develiot/uaqms ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Urban Air Quality Monitoring Station - -The Urban Air Quality Monitoring Station measures the key air quality indicators and environmental -parameters with high accuracy, mapping the pollution in real-time. - - - -### Resources - -- [Product Page](https://www.tbs.tech/iot-urban-air-quality-monitoring/#the-solution) -- [Datasheet](https://www.tbs.tech/wp-content/uploads/2023/03/Datasheet-Urban-Air-Quality-Monitoring-Station-EN-v7.3-March-2023.pdf) - -### Specifications - -#### Sensors: - -- air quality options: CO, NO2, SO2, O3, NH3, H2S, Cl2, HCl, HF, CH2O, H2 -- particulate matter (PM) -- low concentration CO2 -- GPS -- temperature -- humidity -- barometer -- noise level -- wind direction -- wind speed -- precipitation -- battery - -#### Dimensions: - -- width: 325 mm -- length: 430 mm -- height: 185 mm - -#### Weight: - -- 11000 grams - -#### Battery: - -- type: Lead Acid -- replaceable: True - -#### Note: - -- Develiot is now part of the Telelink Business Services, IoT Technology Group. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/digital-matter/digital-matter-lorawan-gps.mdx b/docs/use-the-network/devices/ready-to-use/digital-matter/digital-matter-lorawan-gps.mdx deleted file mode 100644 index 5cadc2615..000000000 --- a/docs/use-the-network/devices/ready-to-use/digital-matter/digital-matter-lorawan-gps.mdx +++ /dev/null @@ -1,197 +0,0 @@ ---- -id: digital-matter-lorawan-gps -title: Tutorial DM LoRaWAN GPS -pagination_label: Tutorial DM LoRaWAN GPS -sidebar_label: Tutorial DM LoRaWAN GPS -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/digital-matter/tutorial-dm-lorawan-gps ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Tutorial DM LoRaWAN GPS - -Step-by-step tutorial guide on configuring and onboarding Digital Matter LoRaWAN GPS devices. - -

- -
-
- -
- -### Introduction - -The [Digital Matter Oyster3](https://www.digitalmatter.com/devices/oyster-lorawan/) / -[Yabby Edge](https://www.digitalmatter.com/our-devices/yabby-edge/) are rugged IP68-rated -battery-powered GPS tracking devices. This guide will show you the hardware and software setup steps -required to provision and onboard these devices on the Helium Network. - -Functionally, the Oyster3 and Yabby Edge are both battery-powered GPS tracking devices. Their main -differences lie in form factor and battery life. - -### Resources - -[Oyster3 LoRaWAN Configuration and Usage Guide](https://support.digitalmatter.com/support/solutions/articles/16000133235-oyster-3-lorawan-configuration-and-usage-guide) -[Yabby Edge LoRaWAN Configuration and Usage Guide](https://support.digitalmatter.com/support/solutions/articles/16000122827-yabby-edge-lorawan-configuration-and-usage-guide) -[LoRaWAN Provisioning Tool](https://www.oemserver.com/tools/LoRaWANProvisioningTool/setup.exe) - -### Hardware - -- Digital Matter Oyster3 / Yabby Edge -- 3 x AA Lithium (LiFeS2) or Lithium Thionyl Chloride (LTC) batteries \(Oyster3\) -- 2 x AAA Lithium (LiFeS2) batteries \(Yabby Edge\) -- DM-Link Wired Provisioning Cable for LoRaWAN devices - -### Software - -- [Helium Console](https://console.helium.com/) -- [LoRaWAN Provisioning Tool](https://www.oemserver.com/tools/LoRaWANProvisioningTool/setup.exe) - \(Windows\) - -### Hardware Setup - -The Oyster3 takes 3 cells of AA battery; the Yabby Edge takes 2 cells of AAA battery. - -The Oyster3 and the Yabby Edge both use the -[DM-Link Wired Provisioning Cable for LoRaWAN decives](https://www.digitalmatter.com/dmlink/). - -Compatibility with the DM-Link Wired Provisioning Cable for older Digital Matter LoRaWAN devices can -be found at -[Wired Provisioning Tool](https://support.digitalmatter.com/support/solutions/articles/16000104317-wired-provisioning-tool). -On LoRaWAN devices, DM-Link is used to configure the region and JoinEUI to connect to a network. A -DM-Link can also be used to configure device parameters prior to deployment and update firmware and -Almanac data where applicable. - -Once the devices have been provisioned and the batteries are populated, the enclosure can be sealed -by using the included screws. - ---- - -That’s it for the hardware setup! - ---- - -### Software Setup - -The Oyster3 / Yabby Edge ship with a pre-provisioned AppEUI and AppKey. If you choose to use these -credentials, you can leave the AppEUI and AppKey fields blank in the Windows utility. If you would -like to provision the device with new credentials, you must copy the AppEUI and AppKey from the -device [created in Console](/use-the-network/console/adding-devices). - -The basic parameters of interest are as follows: - -```text -General: -In Trip Fix : hh:mm:ss : Will determine transmission frequency - -Basic LoRaWAN: - Region : US915 [1.0.2B] - Sub-Band : 2 (ch. 8-15, 70) - Activation : OTAA - JoinEUI / AppEUI : [ Blank to use pre-provisioned / AppEUI from Console ] - NwkKey (1.1) / AppKey (1.0) : [ Blank to use pre-provisioned / AppKey from Console ] - -``` - -### Connecting your device - -When you plug in your cable, your PC will assign it a COM port, which you can retrieve from the -Device Manager from the _**Ports \(COM & LPT\).**_ - -To access the device manager, press the Windows key on your keyboard and search for "Device -Manager". - -##### Windows Device Manager - -Select the corresponding port from the drop-down list in the top right of the utility and click -_**Start**_. - -If the Program Firmware and Program Parameters boxes are left unchecked, the utility will -continuously read and display the current device settings without applying changes. - -##### Current Device Settings and Transaction List - -You can check logs by clicking the DevEUI List button on the top left, which will show a list of -scanned DevEUIs and transactions. Each time a device is programmed, the parameter list will flash, -and the DevEUI list will update. This list is available in CSV format, so it can be conveniently -imported into a spreadsheet. - -To program the new parameters and firmware, enter the desired parameters in the right-hand column, -and check the corresponding boxes to update _**firmware**_ and/or _**parameters**._ When you are -finished, you may hit _**Stop**_, and disconnect your device. - -Once the device has been configured, it will attempt to join the Helium Network by transmitting join -requests. If the device has been configured properly in Console and has knowledge of the device’s -AppEUI and AppKey, the Hotspot that hears the join request will send a join-accept message and allow -the device to join the Network and transmit data. - -### Usage - -These devices use an accelerometer to detect movement, allowing it to decide when an asset is -in-trip and when it is stationary. This allows it to schedule battery-hungry GPS fixes when -appropriate, to optimize battery life. Each time a status update is scheduled, the device will -attempt a GPS fix, then transmit results \(regardless of whether a fix succeeded or not\). - -### Device Payload - -A sample device payload is as follows: - -```text -DCCF3816BF5046B70000D3 -``` - -When decoded becomes: - -```text -{ - "type": "position", - "latitudeDeg": 37.282198, - "longitudeDeg": -122.0128577, - "inTrip": false, - "fixFailed": false, - "headingDeg": 0, - "speedKmph": 0, - "batV": 5.275, - "manDown": null -} -``` - -To learn more about decoding this payload, you may use this -[utility](https://www.oemserver.com/tools/Oyster3LoRaWAN/oyster3-lr-html-decoder.html). To view the -JavaScript sample code, you can view source. - -### Battery Life Estimate Calculator - -Download the -[Oyster3 LoRaWAN Battery Life Estimate Calculator](https://support.digitalmatter.com/helpdesk/attachments/16084686136) - -This spreadsheet will help estimate the approximate battery life of the Digital Matter Oyster3 -LoRaWAN. Simply modify the fields to represent the desired number of transmissions within a day. - -### myDevices/Cayenne Integration - -Helium now supports myDevices and the Cayenne LPP \(Low Power Payload\) format. Cayenne is a -drag-and-drop IoT platform developed by myDevices, allowing developers, designers, and engineers to -quickly prototype and share their connected device projects. - -To learn more about myDevices Cayenne integration, visit -[myDevices Cayenne](https://developers.mydevices.com/cayenne/features/) and their -[documentation](https://developers.mydevices.com/cayenne/docs/intro/). - -:::info - -myDevices currently only includes the Digital Matter Oyster in their device library. - -::: - -When you are adding a device/widget in Cayenne, look for the **Digital Matter Oyster** under -**Helium**. - -#### myDevices Cayenne - Adding a Digital Matter Oyster - -Copy the device's **DevEUI** into the field. This value should correspond to the associated Digital -Matter Oyster DevEUI in **Console**. Then, click **Add device**. - -That's it for adding a Digital Matter Oyster in myDevices Cayenne! diff --git a/docs/use-the-network/devices/ready-to-use/digital-matter/oyster.mdx b/docs/use-the-network/devices/ready-to-use/digital-matter/oyster.mdx deleted file mode 100644 index e2b761800..000000000 --- a/docs/use-the-network/devices/ready-to-use/digital-matter/oyster.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -id: oyster -title: Oyster3 -description: Ultra-rugged, long-life battery-powered GPS asset tracking device for LoRaWAN Networks -pagination_label: Oyster3 -sidebar_label: Oyster3 -image: img/use-the-network/devices/ready-to-use/digital-matter/oyster.png -slug: /use-the-network/devices/ready-to-use/digital-matter/oyster ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Oyster3 - -Ultra-rugged, long-life battery-powered GPS asset tracking device for LoRaWAN Networks. - - - -### Resources - -- [Product Page](https://www.digitalmatter.com/devices/oyster-lorawan) -- [Datasheet](https://www.digitalmatter.com/wp-content/uploads/2023/02/Oyster3-LoRaWAN-Datasheet-Digital-Matter-V8.pdf) - -### Specifications - -#### Sensors: - -- accelerometer -- GPS -- temperature -- battery - -#### Dimensions: - -- width: 86 mm -- length: 108 mm -- height: 30 mm - -#### Weight: - -- 180 grams (batteries not included) - -#### Battery: - -- type: 3x AA Lithium (LiFeS2) or Lithium Thionyl Chloride (LTC) -- replaceable: True - -#### Note: - -- This next-generation Oyster tracking device has over 10 years of battery life. -- 4x battery life of Oyster LoRaWAN V1. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/digital-matter/yabby-edge.mdx b/docs/use-the-network/devices/ready-to-use/digital-matter/yabby-edge.mdx deleted file mode 100644 index 058e6f87c..000000000 --- a/docs/use-the-network/devices/ready-to-use/digital-matter/yabby-edge.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: yabby-edge -title: Yabby Edge -pagination_label: Yabby Edge -sidebar_label: Yabby Edge -description: Ultra-rugged and Compact Indoor / Outdoor Asset Tracker for LoRaWAN Networks. -image: img/use-the-network/devices/ready-to-use/digital-matter/yabby-edge.png -slug: /use-the-network/devices/ready-to-use/digital-matter/yabby-edge ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Yabby Edge - -Ultra-rugged and Compact Indoor / Outdoor Asset Tracker for LoRaWAN Networks. - - - -### Resources - -- [Product Page](https://www.digitalmatter.com/our-devices/yabby-edge) -- [Datasheet](https://www.digitalmatter.com/wp-content/uploads/2023/02/Yabby-Edge-LoRaWAN-Datasheet-Digital-Matter-V6.pdf) - -### Specifications - -#### Sensors: - -- accelerometer -- GPS -- temperature -- battery - -#### Dimensions: - -- width: 63 mm -- length: 84 mm -- height: 24 mm - -#### Weight: - -- 82 grams (batteries not included) - -#### Battery: - -- type: 2x AAA Lithium (LiFeS2) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lbt1.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lbt1.mdx deleted file mode 100644 index 9a6f673c5..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lbt1.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: lbt1 -title: LBT1 -pagination_label: LBT1 -sidebar_label: LBT1 -description: LBT1 LoRaWAN BLE Indoor Tracker -image: img/use-the-network/devices/ready-to-use/dragino/lbt1.jpg -slug: /use-the-network/devices/ready-to-use/dragino/lbt1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LBT1 - -LBT1 LoRaWAN BLE Indoor Tracker. The Dragino LBT1 is a long-range, low-power consumption LoRaWAN -Bluetooth tracker. LBT1 scans and finds the nearest iBeacon info and sends an LNS server via a -LoRaWAN Network. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/165-lbt1.html) -- [Datasheet](https://www.dragino.com/downloads/downloads/LoRa_End_Node/LBT1/Datasheet_LBT1.pdf) -- [Manual](https://www.dragino.com/downloads/downloads/LoRa_End_Node/LBT1/LBT1_LoRaWAN_BLE_Indoor_Tracker_UserManual_v1.2.0.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- motion - -#### Dimensions: - -**Device:** - -- width: 48 mm -- length: 85 mm -- height: 15 mm - -#### Weight: - -- 50 grams - -#### Battery: - -- type: 1000 mAh Lithium-ion (Li-ion) -- replaceable: false -- rechargeable: true - -### Note: - -- End of Life (EOL) device. -- Replaced by [Dragino TrackerD](https://www.dragino.com/products/tracker/item/234-trackerd.html). - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/ldds20.mdx b/docs/use-the-network/devices/ready-to-use/dragino/ldds20.mdx deleted file mode 100644 index 721a2af66..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/ldds20.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: ldds20 -title: LDDS20 -pagination_label: LDDS20 -sidebar_label: LDDS20 -description: LDDS20 LoRaWAN Liquid Level Sensor -image: img/use-the-network/devices/ready-to-use/dragino/ldds20.jpg -slug: /use-the-network/devices/ready-to-use/dragino/ldds20 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LDDS20 - -LDDS20 LoRaWAN Liquid Level Sensor. The Dragino LDDS20 is a LoRaWAN ultrasonic liquid-level sensor -for IoT solutions. It uses ultrasonic technology to measure the liquid level in a container without -opening it and send the value via a LoRaWAN Network to an LNS Server. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/164-ldds20.html) -- [Datasheet](https://www.dropbox.com/sh/2oe2xq6scri68q3/AABizfzW5HUikdJLQByWbFAga/Datasheet_LDDS20_LoRaWAN%20Liquid%20Level%20Sensor.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LDDS20%20-%20LoRaWAN%20Liquid%20Level%20Sensor%20User%20Manual/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- level -- distance -- battery - -#### Dimensions: - -**Cable:** - -- length: 25 cm - -#### Battery: - -- type: 1x - [ER26500 + SPC1520 battery pack](http://wiki.dragino.com/xwiki/bin/view/Main/How%20to%20calculate%20the%20battery%20life%20of%20Dragino%20sensors%3F/#H1.ER265002BSPC1520BatteryPack) - Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 8500 mAh (non-rechargeable) -- replaceable: true - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/ldds75.mdx b/docs/use-the-network/devices/ready-to-use/dragino/ldds75.mdx deleted file mode 100644 index 20c7e71a9..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/ldds75.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: ldds75 -title: LDDS75 -pagination_label: LDDS75 -sidebar_label: LDDS75 -description: LDDS75 LoRaWAN Distance Detection Sensor -image: img/use-the-network/devices/ready-to-use/dragino/ldds75.jpg -slug: /use-the-network/devices/ready-to-use/dragino/ldds75 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LDDS75 - -LDDS75 LoRaWAN Distance Detection Sensor. The Dragino LDDS75 is a LoRaWAN distance detection sensor -for IoT solutions. It measures the distance between the sensor and a flat object. This sensor module -uses ultrasonic sensing technology for distance measurement, and temperature compensation is -performed internally to improve data reliability. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/161-ldds75.html) -- [Datasheet](https://www.dropbox.com/sh/d1i23dqtc6uo8ye/AAAkL7vwRMUDe3UuPHUaWOJ7a/Datasheet_LDDS75_LoRaWAN_Distance_Detection_Sensor.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LDDS75%20-%20LoRaWAN%20Distance%20Detection%20Sensor%20User%20Manual/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- distance -- battery - -#### Dimensions: - -**Cable:** - -- length: 25 cm - -#### Weight: - -- 220 grams - -#### Battery: - -- type: 1x - [ER26500 + SPC1520 battery pack](http://wiki.dragino.com/xwiki/bin/view/Main/How%20to%20calculate%20the%20battery%20life%20of%20Dragino%20sensors%3F/#H1.ER265002BSPC1520BatteryPack) - Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 8500 mAh (non-rechargeable) -- replaceable: true - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lds01.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lds01.mdx deleted file mode 100644 index 04ea39496..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lds01.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: lds01 -title: LDS01 -pagination_label: LDS01 -sidebar_label: LDS01 -description: LDS01 -- LoRaWAN Door Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/dragino/lds01 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LDS01 - -LDS01 -- LoRaWAN Door Sensor - -The Dragino LDS01 is a LoRaWAN Door Sensor. It detects the door open/close status and uplinks these -statistics to an LNS server via a LoRaWAN Network. The LDS01 will send periodic data every day as -well as for each door open/close action. It also counts the door open times and calculates the last -door open duration. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/157-lds01.html) -- [Datasheet](https://www.dragino.com/downloads/downloads/LoRa_End_Node/LDS01/Datasheet_LDS01_Door_Sensor.pdf) -- [Manual](https://www.dragino.com/downloads/downloads/LoRa_End_Node/LDS01/LDS01_LoRaWAN_Door_Sensor_UserManual_v1.4.0.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- magnetometer - -#### Dimensions: - -**Device:** - -- width: 31 mm -- length: 64.2 mm -- height: 13.8 mm - -**Small close device:** - -- width: 11.2 mm -- length: 50 mm - -#### Battery: - -- type: 1x CR2032 lithium coin cell / 3 V / 220 mAh -- replaceable: true - -### Note: - -- End of Life (EOL) device. -- Replaced by - [Dragino LDS02 -- LoRaWAN Door Sensor](https://www.dragino.com/products/lorawan-nb-iot-door-sensor-water-leak/item/181-lds02.html). - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lds02.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lds02.mdx deleted file mode 100644 index 871a51477..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lds02.mdx +++ /dev/null @@ -1,279 +0,0 @@ ---- -id: lds02 -title: LDS02 -pagination_label: LDS02 -sidebar_label: LDS02 -description: LDS02 -- LoRaWAN Door Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/dragino/lds02 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LDS02 - -LDS02 - LoRaWAN Door Sensor - -The Dragino LDS02 is a LoRaWAN Door Sensor. It detects the door open/close status and uplinks these -statistics to an LNS server via a LoRaWAN Network. The LDS02 will send periodic data every day as -well as for each door open/close action. It also counts the door open times and calculates the last -door open duration. Users can also disable the uplink for each open/close event, instead, the device -can count each open event and uplink periodically. - - - -### Resources - -- [Product Page](https://www.dragino.com/products/lorawan-nb-iot-door-sensor-water-leak/item/181-lds02.html) -- [Datasheet](https://www.dropbox.com/sh/h194pj8r2chooe6/AABvkOGweKuPXWmq3VvKRhxQa/Datasheet_LDS02_Door_Sensor.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LDS02%20-%20LoRaWAN%20Door%20Sensor%20User%20Manual/) - -### Specifications: - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- magnetometer -- open door alarm - -#### Dimensions: - -**Device:** - -- width: 29.2 mm -- length: 69.2 mm -- height: 14.8 mm - -#### Weight: - -- 50 grams (excluding batteries) - -#### Battery: - -- type: 2x AAA (LR03) -- replaceable: true - ---- - -### Add Device to Console - -To start, you'll need to add your device to the Helium Console. In the package is a sticker -containing the Device EUI (also QR code), App EUI, and App Key. (The APSSKEY and NETSKEY are -unused.) Follow our [quick start guide](/use-the-network/console/adding-devices) on how to add a new -device to Console. - -Open the Debug panel on the Device view to observe incoming messages for the next step. - -### Install Batteries - -Open the LDS02 enclosure and add 2x AAA (LR03) battery cells for power. For the best wide-range -temperature tolerance and longevity, consider Lithium primary cells, such as Energizer Ultimate -Lithium L92SBP. - -On insertion, the LED should light quickly Red, Blue, Green, then off. You should immediately see -Join and Uplink messages on the Helium Console Debug panel. If you see no messages, or no LED -flashing, double-check the device IDs, then remove and reinstall one battery to start initialization -again. - -### myDevices Cayenne - -This device is supported directly by -[myDevices Cayenne](https://developers.mydevices.com/cayenne/features/) via the included Integration -in Helium's Console. - -To add the LDS02 to Cayenne, you do not need to set up a Decode script at all. Cayenne takes the -encoded Device payload directly and parses the events from it. - -Be careful to select **Helium** when adding the LDS02 to Cayenne. As described -[here](https://docs.mydevices.com/docs/lorawan/helium), select - -1. "Add new..." -2. "Device/Widget" -3. "LoRa" -4. "Helium" -5. select `Dragino LDS02 LoRaWAN Door Sensor` -6. Enter the Device EUI and other information. - -On the Helium Console, select `Flow` and directly connect the LHT65 Device to the Cayenne -Integration with a connecting flow line. _Do not use a Decoder._ - -Cayenne will show: - -- RSSI (dBm) -- SNR (dB) -- Battery Voltage (v) -- Battery (%) -- Door state (0/1) -- Door ("Dorr" sic) Open Times -- Last Door Open Duration (in minutes!) -- Alarm state (0/1) - -### Decode Device Payload - -To decompose the packed 10-byte data payload from the device into individual values, you may provide -a decode Function as explained in [our short primer](/use-the-network/console/functions). The -manufacturer of this device, Dragino, is using their own encoding scheme to define which bytes hold -which piece of data. Below is a table taken from the manual showing the size and location of each -piece of data. - - - -If you would like to decode the device payload or to view it in Console or send to your own -application, this section will show you how. We'll be using a Console Function Decoder to unpack the -device payload into a human-readable form. - -#### Create Function Decoder - -Create a new custom Function decoder, by selecting `Functions`, then `(+)`. Name the function -(perhaps "LDS02"), type `Decoder` and `Custom Script`. Paste the script below, provided by Dragino: - -```js -function Decoder(bytes, port) { - // Decode an uplink message from a buffer - // (array) of bytes to an object of fields. - var value = ((bytes[0] << 8) | bytes[1]) & 0x3fff - var bat = value / 1000 //Battery,units:V - - var door_open_status = bytes[0] & 0x80 ? 1 : 0 //1:open,0:close - var water_leak_status = bytes[0] & 0x40 ? 1 : 0 - - var mod = bytes[2] - var alarm = bytes[9] & 0x01 - - if (mod == 1) { - var open_times = (bytes[3] << 16) | (bytes[4] << 8) | bytes[5] - var open_duration = (bytes[6] << 16) | (bytes[7] << 8) | bytes[8] //units:min - if (bytes.length == 10 && 0x07 > bytes[0] < 0x0f) - return { - BAT_V: bat, - MOD: mod, - DOOR_OPEN_STATUS: door_open_status, - DOOR_OPEN_TIMES: open_times, - LAST_DOOR_OPEN_DURATION: open_duration, - ALARM: alarm, - } - } else if (mod == 2) { - var leak_times = (bytes[3] << 16) | (bytes[4] << 8) | bytes[5] - var leak_duration = (bytes[6] << 16) | (bytes[7] << 8) | bytes[8] //units:min - if (bytes.length == 10 && 0x07 > bytes[0] < 0x0f) - return { - BAT_V: bat, - MOD: mod, - WATER_LEAK_STATUS: water_leak_status, - WATER_LEAK_TIMES: leak_times, - LAST_WATER_LEAK_DURATION: leak_duration, - } - } else if (mod == 3) - if (bytes.length == 10 && 0x07 > bytes[0] < 0x0f) { - return { - BAT_V: bat, - MOD: mod, - DOOR_OPEN_STATUS: door_open_status, - WATER_LEAK_STATUS: water_leak_status, - ALARM: alarm, - } - } else { - return { - BAT_V: bat, - MOD: mod, - } - } -} -``` - -#### Create a Flow - -To associate the Device with the Decoder Function, go to the Flow panel. - -Drag the Device instance and the Function into the field. Connect them with a line from the Device -to the Function - -#### Viewing Decoded Device Data - -Once you have attached the Decoder we can now open the Debug window to view the decoded device -payload in the received uplink. To open the Debug window just click on the bug icon on the right -side of the device page. Once you have the Debug window open you can wait for the next packet to -transmit or force a manual transmission by triggering the sensor with the magnet. You will see the -LED flash green while it sends a packet to the network. - -## Google Sheets log - -You can also use the Google Sheet integration to map the decoded data to a Form for recording in -sheets. Create a Google Form with Short Answer questions for - -- `battery-volts` -- `door-open` -- `door-open-count` -- `last-open-duration` -- `alarm` - -Map it to the Google Sheets Integration and provide this decoder as part of the Sheets setup: - -```js -function Decoder(bytes, port) { - var value = ((bytes[0] << 8) | bytes[1]) & 0x3fff - var bat = value / 1000 // Battery, units:V - var door_open_status = bytes[0] & 0x80 ? 1 : 0 // 1:open, 0:close - var alarm = bytes[9] & 0x01 - var open_times = (bytes[3] << 16) | (bytes[4] << 8) | bytes[5] - var open_duration = (bytes[6] << 16) | (bytes[7] << 8) | bytes[8] //units:min - if (bytes.length == 10 && 0x07 > bytes[0] < 0x0f) { - var decodedPayload = { - 'battery-volts': bat, - 'door-open': door_open_status, - 'door-open-count': open_times, - 'last-open-duration': open_duration, - alarm: alarm, - } - return Serialize(decodedPayload) - } -} - -// Generated: do not touch unless your Google Form fields have changed -var field_mapping = { - 'battery-volts': 'entry.702320693', - 'door-open': 'entry.1934071370', - 'door-open-count': 'entry.844671899', - 'last-open-duration': 'entry.1464236526', - alarm: 'entry.2127237487', -} -// End Generated - -function Serialize(payload) { - var str = [] - for (var key in payload) { - if (payload.hasOwnProperty(key)) { - var name = encodeURIComponent(field_mapping[key]) - var value = encodeURIComponent(payload[key]) - str.push(name + '=' + value) - } - } - return str.join('&') -} -``` - -The Sheets integration will provide its own Decoder Function block. Create a new flow from the LDS02 -Device to this Decoder, to the Sheets Integration block. - -## Notes - -Note that the Door Open Duration is a count of full minutes (rounded down) that the door was last -open. It does not show the Door Closed time but repeats the Door Open time for the subsequent Open -message. - -If door open/close events happen faster than LoRa can send messages (about 3 seconds each), then the -door open/close Count will still be correct, and you will see nonsequential values in the Count for -missed door events. The last sent message appears to correctly reflect the state of the door, -regardless of previously missed messages. - -A heartbeat message is automatically sent every 24 hours (+ 5 seconds) when idle, restating the door -condition. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lgt92.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lgt92.mdx deleted file mode 100644 index 3aabff9cc..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lgt92.mdx +++ /dev/null @@ -1,64 +0,0 @@ ---- -id: lgt92 -title: LGT-92 -pagination_label: LGT-92 -sidebar_label: LGT-92 -description: LoRaWAN GPS Tracker with 9-axis Accelerometer LGT-92 -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/dragino/lgt-92 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LGT-92 - -LoRaWAN GPS Tracker with 9-axis accelerometer LGT-92. The Dragino LoRaWAN GPS Tracker LGT-92 is an -open-source GPS tracker based on ultra-low power STM32L072 MCU and SX1276/1278 LoRa Module. LGT-92 -includes a low-power GPS module L76-L and a 9-axis accelerometer for motion and attitude detection. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/142-lgt-92.html) -- [Datasheet](https://www.dragino.com/downloads/downloads/LGT_92/Datasheet_LGT-92.pdf) -- [Manual](https://www.dragino.com/downloads/downloads/LGT_92/LGT-92_LoRa_GPS_Tracker_UserManual_v1.6.8.pdf) -- [Configure on Console](/iot/coverage-mapping/quickstart) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device (default) -- Class C end-device - -#### Sensors: - -- accelerometer - -#### Dimensions: - -**Device:** - -- width: 48 mm -- length: 85 mm -- height: 15 mm - -#### Weight: - -- 50 grams (without USB cable) - -#### Battery: - -- type: 1000 mAh Lithium-ion (Li-ion) for model LGT-92-LI -- replaceable: false -- rechargeable: true - -### Note: - -- End of Life (EOL) device. -- Replaced by [Dragino TrackerD](https://www.dragino.com/products/tracker/item/234-trackerd.html). - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lht65.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lht65.mdx deleted file mode 100644 index 6b7623d91..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lht65.mdx +++ /dev/null @@ -1,157 +0,0 @@ ---- -id: lht65 -title: LHT65 -pagination_label: LHT65 -sidebar_label: LHT65 -description: LHT65 LoRaWAN Temperature & Humidity Sensor -image: img/use-the-network/devices/ready-to-use/dragino/lht65.jpg -slug: /use-the-network/devices/ready-to-use/dragino/lht65 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Dragino LHT65 - -The Dragino LHT65 is a multi-sensor device with a built-in temperature and humidity sensor and an -external sensor connector that supports temperature, soil moisture, tilting, and illumination -sensors. The device includes a non-chargeable battery that can last for more than 10 years. - - - -### Resources - -- [Product Page](https://www.dragino.com/products/lora-lorawan-end-node/item/151-lht65.html) -- [Datasheet](https://www.dragino.com/downloads/downloads/LHT65/Datasheet_LHT65_LoRaWAN_Temperature_Humidity_Sensor.pdf) -- [Manual](https://www.dragino.com/downloads/downloads/LHT65/UserManual/LHT65_Temperature_Humidity_Sensor_UserManual_v1.8.5.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- humidity -- temperature - -#### Dimensions: - -**Device:** - -- width: 70 mm -- length: 135 mm -- height: 30 mm - -#### Weight: - -- 105 grams - -#### Battery: - -- type: 2400 mAh non-chargeable -- replaceable: True (Battery Replacement Kit: LHT65-BAT-CA; includes: LHT65 battery + Enclosure + - Sticker without Dev EUI.) - -### Add Device to Console - -To start, you'll need to add your device to Console. You should have been provided with a DevEUI, -AppEUI, and AppKey inside the device packaging. Follow our -[quick start for instructions](/use-the-network/console/adding-devices) on how to add a new device -to Console. - -### Join Device to Network - -Your device will be in deep sleep mode when you receive it. To activate the device and place it in a -normal operating state, hold down the ACT button for three seconds until you see the LED blink green -five times quickly. The operating mode table is shown below for reference. - - - -The device should now begin attempting to join the Network. Within a minute or two, you should see -an activation event on the Console device page, as shown below. The device LED will also show solid -green for five seconds after it has joined. - - - -Once you have seen an event similar to above, your device is now joined to the Network and will send -its sensor values every ten minutes by default. The transmit frequency and many more settings can be -changed; please refer to the manual for instructions. - -### myDevices Cayenne - -If you would like to easily view your device's data on a web or mobile dashboard for free, this the -device is supported out of the box by myDevices Cayenne via the integration on Console. - -To add the LHT65 to myDevices Cayenne, you do not need to set up a Decode script as described below. -Cayenne takes the encoded payload directly and parses the temperature and other data elements from -it. - -Be careful to select **Helium** when adding the LHT65 to Cayenne. As described -[here](https://docs.mydevices.com/docs/lorawan/helium), select - -1. "Add new..." -2. "Device/Widget" -3. "LoRa" -4. "Helium" -5. select Dragino LHT65 - -On the Helium Console, select `Flow` and directly connect the LHT65 Device to the Cayenne -Integration. Do not use a Decoder. - -### Decode Device Payload - -When this device transmits its data, it does so space-efficiently by packing the bytes of data in a -specific way so that no space is wasted; learn more about this in -[our short primer](/use-the-network/console/functions). This device's manufacturer, Dragino, uses -their own encoding scheme to define which bytes hold which piece of data. Below is a table taken -from the manual showing the size and location of each piece of data. - - - -If you would like to decode the device payload to view it in Console or send it to your own -application, this section will show you how. We'll use a Console Function Decoder to unpack the -device payload into a human-readable form; you can learn more about Functions in general -[here](/use-the-network/console/functions/). - -#### Create Function Decoder - -Let's begin by creating a new custom function decoder. First, enter a name, select decoder for -function type, and finally, custom script since we'll input our own script. Next, remove the -template custom script, and copy and paste the entire script found -[here](https://www.dragino.com/downloads/downloads/LHT65/payload_decode/ttn_payload_decode_v1.7.txt) -into the script editor. Last, create a label that we'll use to attach this decoder to the device -with. - - - -#### Attaching Function Decoder - -Next, navigate to the device page and attach the label we just created for the function decoder as -shown below. - - - -#### Viewing Decoded Device Data - -Once you have attached the decoder, we can now open the Debug window to view the decoded device -payload in the received uplink. You can learn more about the Debug tool -[here](https://docs.helium.com/use-the-network/console/debug). To open the Debug window, click on -the bug icon on the right side of the device page. Once you open the Debug window, you can wait for -the next packet to transmit or force a manual transmission by holding down the ACT button for more -than one second and less than three. You'll see the LED turn green while you hold it down, and then -it should turn red briefly after release. You should see the uplink message with the decoded fields -below. - - - -### Sending Device Payload to Your Application - -To learn more about how to send the device data payload to your own application, check out the -Console integrations [here](https://docs.helium.com/use-the-network/console/integrations). - ---- diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lse01.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lse01.mdx deleted file mode 100644 index 766472c36..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lse01.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: lse01 -title: LSE01 -pagination_label: LSE01 -sidebar_label: LSE01 -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/dragino/lse01 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LSE01 - -LSE01 -- LoRaWAN Soil Moisture & EC Sensor - -The Dragino LSE01 is a LoRaWAN Soil Moisture & EC Sensor for IoT solutions in the field of -agriculture. It is designed to measure the soil moisture of saline-alkali soil and loamy soil. The -soil sensor uses the FDR method to calculate the soil moisture with compensation from soil -temperature and conductivity. It also has been calibrated in the factory for mineral soil type. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/159-lse01.html) -- [Datashee](https://www.dropbox.com/sh/qr6vproz4z4kzjz/AACecQwieyQVhmwPil1awal4a/Datasheet_LSE01_LoRaWAN_Soil_Moisture_%26_EC_Sensor.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LSE01-LoRaWAN%20Soil%20Moisture%20%26%20EC%20Sensor%20User%20Manual/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- soil moisture -- soil temperature -- soil conductivity -- battery - -#### Battery: - -- type: 1x - [ER26500 + SPC1520 battery pack](http://wiki.dragino.com/xwiki/bin/view/Main/How%20to%20calculate%20the%20battery%20life%20of%20Dragino%20sensors%3F/#H1.ER265002BSPC1520BatteryPack) - Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 8500 mAh (non-rechargeable) -- replaceable: true - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lsn50-v2.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lsn50-v2.mdx deleted file mode 100644 index 7fd5e122e..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lsn50-v2.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -id: lsn50-v2 -title: LSN50-V2 -pagination_label: LSN50-V2 -sidebar_label: LSN50-V2 -description: Waterproof Long Range Wireless Lora Sensor Node. -image: img/use-the-network/devices/ready-to-use/dragino/lsn50-v2.jpg -slug: /use-the-network/devices/ready-to-use/dragino/lsn50-v2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LSN50-V2 - -LSN50-V2 -- Waterproof Long Range Wireless LoRa Sensor Node. The Dragino LSN50-V2 is a Long Range -LoRaWAN Sensor Node. It is designed for outdoor data logging and powered by a Li-SOCl2 battery for -long-term use and secure data transmission. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/155-lsn50-v2.html) -- [Datasheet](https://www.dropbox.com/sh/djkxs7mr17y94mi/AACFGEHSQJmTq_dW7drL2YwAa/Datasheet_LSN50v2%20LoRaWAN%20Sensor%20Node.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LSN50%20%26%20LSN50-V2%20-%20LoRaWAN%20Sensor%20Node%20User%20Manual/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device (default) -- Class C end-device - -#### Sensors: - -- temperature -- battery - -#### Dimensions: - -**Device:** - -- width: 65 mm -- length: 97 mm -- height: 47 mm - -#### Weight: - -- 150 grams - -#### Battery: - -- type: 1x - [ER26500 + SPC1520 battery pack](http://wiki.dragino.com/xwiki/bin/view/Main/How%20to%20calculate%20the%20battery%20life%20of%20Dragino%20sensors%3F/#H1.ER265002BSPC1520BatteryPack) - Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 8500 mAh (non-rechargeable) -- replaceable: true - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lsn50v2-d20.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lsn50v2-d20.mdx deleted file mode 100644 index ed20e625b..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lsn50v2-d20.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: lsn50v2-d20 -title: LSN50v2-D20 -pagination_label: LSN50v2-D20 -sidebar_label: LSN50v2-D20 -description: LSN50v2-D20 -- LoRaWAN Waterproof / Outdoor Temperature Sensor -image: img/use-the-network/devices/ready-to-use/dragino/lsn50v2-d20-00.jpg -slug: /use-the-network/devices/ready-to-use/dragino/lsn50v2-d20 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LSN50v2-D20 - -LSN50v2-D20 -- LoRaWAN Waterproof / Outdoor Temperature Sensor. The Dragino LSN50v2-D20 is a LoRaWAN -Temperature Sensor for IoT solutions. It measures the temperature of air, liquid or object, and then -periodically reads and uploads data via a LoRaWAN Network to an IoT server. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/168-lsn50v2-d20.html) -- [Datasheet](https://www.dropbox.com/sh/z8tozdjt2r594u7/AAB0wat4NH5X-dkiFgNKur_6a/Datasheet_LSN50v2-D2x_LoRaWAN_Temperature_Sensor.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LSN50v2-D20-D22-D23%20LoRaWAN%20Temperature%20Sensor%20User%20Manual/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- battery - -#### Dimensions: - -**Cable:** - -- length: 2 m - -#### Battery: - -- type: 1x - [ER26500 + SPC1520 battery pack](http://wiki.dragino.com/xwiki/bin/view/Main/How%20to%20calculate%20the%20battery%20life%20of%20Dragino%20sensors%3F/#H1.ER265002BSPC1520BatteryPack) - Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 8500 mAh (non-rechargeable) -- replaceable: true - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lsn50v2-s31.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lsn50v2-s31.mdx deleted file mode 100644 index 4c97557b7..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lsn50v2-s31.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: lsn50v2-s31 -title: LSN50v2-S31 -pagination_label: LSN50v2-S31 -sidebar_label: LSN50v2-S31 -description: LSN50v2-S31 -- LoRaWAN Temperature & Humidity Sensor -image: img/use-the-network/devices/ready-to-use/dragino/lsn50v2-s31-00.jpg -slug: /use-the-network/devices/ready-to-use/dragino/LSN50v2-S31 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LSN50v2-S31 - -LSN50v2-S31 -- LoRaWAN Temperature & Humidity Sensor - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/169-lsn50v2-s31.html) -- [Datasheet](https://www.dropbox.com/sh/w0by0jha8inigm8/AADtFIWkfb31XFNIEJ1vTNZca/Datasheet_LSN50v2-S31_LoRaWAN_Temperature_Humidity_Sensor.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LSN50v2-S31-S31B%20LoRaWAN%20Temperature%20%26%20Humidity%20Sensor%20User%20Manual/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- battery - -### Dimensions: - -**Device:** - -- width: 50 mm -- length: 110 mm -- height: 46 mm - -**Cable:** - -- length: 2 m - -#### Weight: - -- 315 grams (cable included) - -#### Battery: - -- type: 1x - [ER26500 + SPC1520 battery pack](http://wiki.dragino.com/xwiki/bin/view/Main/How%20to%20calculate%20the%20battery%20life%20of%20Dragino%20sensors%3F/#H1.ER265002BSPC1520BatteryPack) - Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 8500 mAh (non-rechargeable) -- replaceable: true - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lt22222-l.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lt22222-l.mdx deleted file mode 100644 index 0d390380d..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lt22222-l.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: lt22222-l -title: LT-22222-L -pagination_label: LT-22222-L -sidebar_label: LT-22222-L -description: LT-22222-L LoRaWAN I/O Controller. -image: img/use-the-network/devices/ready-to-use/dragino/lt22222-l.jpg -slug: /use-the-network/devices/ready-to-use/dragino/lt-22222-l ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LT-22222-L - -LT-22222-L LoRaWAN I/O controller. The Dragino LT series I/O Modules are a long-range LoRaWAN I/O -Controller. It contains different I/O Interfaces such as: analog current input, analog voltage -input, relay output, digital input and digital output etc. The LT I/O Modules are designed to -simplify the installation of I/O monitoring. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/156-lt-22222-l.html) -- [Datasheet](https://www.dropbox.com/sh/n1j835hfwb13g0d/AADgkUKlqQSa8LIHgesEthNua/Datasheet_LT22222-L%20LoRaWAN%20IO%20Controller.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/LT-22222-L/) -- [Walkthrough](https://github.com/ilovespectra/ilovespectra/tree/main/LT-22222-L) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device -- Class C end-device (default) - -#### Dimensions: - -- width: 70 mm -- length: 135 mm -- height: 30 mm - -#### Weight: - -- 105 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lt33222-l.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lt33222-l.mdx deleted file mode 100644 index f58588232..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lt33222-l.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -id: lt33222-l -title: LT-33222-L -pagination_label: LT-33222-L -sidebar_label: LT-33222-L -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/dragino/lt-33222-l ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LT-33222-L - -LT-33222-L LoRa I/O controller. The Dragino LT series I/O Modules are long-range LoRa I/O -Controller. It contains different I/O Interfaces such as: analog current Input, analog voltage -input, relay output, digital input and digital output etc. The LT I/O Modules are designed to -simplify the installation of I/O monitoring. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/138-lt-33222-l.html) -- [Datasheet](https://www.dropbox.com/sh/gxxmgks42tqfr3a/AABaJMFV-N3ZVqbWrc1sGwXka/Datasheet_LoRa_IO_Controller.pdf?dl=0) -- [Reseller - Dragino](http://www.dragino.com/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device -- Class C end-device (default) - -#### Dimensions: - -- width: 70 mm -- length: 135 mm -- height: 30 mm - -#### Weight: - -- 105 grams - -#### Note: - -- End of Life (EOL) device. -- Replaced by [Dragino LT-22222-L](https://www.dragino.com/products/lora-lorawan-end-node/item/156-lt-22222-l.html). - -### Note: - -- End of Life (EOL) device. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/lwl01.mdx b/docs/use-the-network/devices/ready-to-use/dragino/lwl01.mdx deleted file mode 100644 index fcfeff71f..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/lwl01.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: lwl01 -title: LWL01 -pagination_label: LWL01 -sidebar_label: LWL01 -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/dragino/lwl01 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LWL01 - -LWL01 -- LoRaWAN Water Leak Sensor - -The Dragino LWL01 is a LoRaWAN Water Leak Sensor. It detects the water leak status. The Dragino -LWL01 will send periodic data every day as well as for water leak events. It also counts the water -leak event times and also calculates the last water leak duration. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/158-lwl01.html) -- [Datasheet](https://www.dragino.com/downloads/downloads/LoRa_End_Node/LDS01/Datasheet_LWL01_Water_Leak_Sensor.pdf) -- [Manual](https://www.dragino.com/downloads/downloads/LoRa_End_Node/LDS01/LWL01_LoRaWAN_Water_Leak_UserManual_v1.3.1.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- water leak - -#### Dimensions: - -**Device:** - -- width: 30 mm -- length: 60 mm -- height: 14 mm - -**Water leak detect probe:** - -- width: 15 mm -- length: 50 mm -- diameter metal probe: 5 mm -- length metal probe: 13 mm - -#### Battery: - -- type: 1x CR2032 lithium coin cell / 3 V / 220 mAh -- replaceable: true - -### Note: - -- End of Life (EOL) device. -- Replaced by - [Dragino LWL02 -- LoRaWAN Water Leak Sensor](https://www.dragino.com/products/lorawan-nb-iot-door-sensor-water-leak/item/180-lwl02.html). - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/rs485-bl.mdx b/docs/use-the-network/devices/ready-to-use/dragino/rs485-bl.mdx deleted file mode 100644 index f02dfca50..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/rs485-bl.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: rs485-bl -title: RS485-BL -pagination_label: RS485-BL -sidebar_label: RS485-BL -description: The Dragino RS485-BL is a RS485 / Uart to LoRaWAN Converter for IoT solutions. -image: img/use-the-network/devices/ready-to-use/dragino/rs485-bl.jpg -slug: /use-the-network/devices/ready-to-use/dragino/rs485-bl ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## RS485-BL - -RS485-BL -- LoRaWAN RS485/UART Converter -- Waterproof Battery Powered. The Dragino RS485-BL is a -RS485/UART to LoRaWAN Converter for IoT solutions. User can connect RS485 or UART sensor to RS485-BL -converter, and configure RS485-BL to periodically read sensor data and upload via a LoRaWAN network -to an IoT server. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/167-rs485-bl.html) -- [Datasheet](https://www.dropbox.com/sh/kv415xmwpxghk4y/AAA2OB_K5TmKUIpJ-kfX2_eXa/Datasheet_RS485-BL_WaterProof_BatteryPower_RS485_UART_to_LoRaWAN_Converter.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/test/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device (default) -- Class C end-device - -#### Dimensions: - -**Device:** - -- width: 70 mm -- length: 135 mm -- height: 30 mm - -#### Weight: - -- 105 grams (excluding batteries) - -#### Battery: - -- type: 1x - [ER26500 + SPC1520 battery pack](http://wiki.dragino.com/xwiki/bin/view/Main/How%20to%20calculate%20the%20battery%20life%20of%20Dragino%20sensors%3F/#H1.ER265002BSPC1520BatteryPack) - Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 8500 mAh (non-rechargeable) -- replaceable: true - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/dragino/rs485-ln.mdx b/docs/use-the-network/devices/ready-to-use/dragino/rs485-ln.mdx deleted file mode 100644 index 2b6cf4c85..000000000 --- a/docs/use-the-network/devices/ready-to-use/dragino/rs485-ln.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: rs485-ln -title: RS485-LN -pagination_label: RS485-LN -sidebar_label: RS485-LN -description: The Dragino RS485-LN is a RS485 to LoRaWAN Converter. -image: img/use-the-network/devices/ready-to-use/dragino/rs485-ln.jpg -slug: /use-the-network/devices/ready-to-use/dragino/rs485-ln ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## RS485-LN - -The Dragino RS485-LN is a RS485 to LoRaWAN Converter. It converts the RS485 devices into LoRaWAN -Wireless Network devices which simplify the IoT installation and reduce the installation/maintaining -cost. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/154-rs485-ln.html) -- [Datasheet](https://www.dropbox.com/sh/g7ak0jzyu3rbtpo/AACZujhnZ_SNojGhuBBKxneMa/Datasheet_RS485-LN_RS485%20to%20LoRaWAN%20Converter.pdf?dl=0) -- [Manual](http://wiki.dragino.com/xwiki/bin/view/Main/User%20Manual%20for%20LoRaWAN%20End%20Nodes/RS485-LN%20%E2%80%93%20RS485%20to%20LoRaWAN%20Converter/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device -- Class C end-device (default) - -#### Dimensions: - -**Device:** - -- width: 70 mm -- length: 135 mm -- height: 30 mm - -#### Weight: - -- 105 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/lbt1.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/lbt1.mdx deleted file mode 100644 index 2c4e28cde..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/lbt1.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: lbt1 -title: Lbt1 -pagination_label: Lbt1 -sidebar_label: Lbt1 -description: LoRaWAN Ble Indoor Tracker -image: img/use-the-network/devices/ready-to-use/enthutech/lbt1.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/lbt1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LBT1 - -LoRaWAN BLE Indoor Tracker - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/165-lbt1.html) -- [Datasheet](http://www.dragino.com/downloads/index.php?dir=LoRa_End_Node/LBT1/) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- motion - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/ldds75.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/ldds75.mdx deleted file mode 100644 index a9e47bca9..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/ldds75.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: ldds75 -title: Ldds75 -pagination_label: Ldds75 -sidebar_label: Ldds75 -description: LoRaWAN Distance Detection Sensor -image: img/use-the-network/devices/ready-to-use/enthutech/ldds75.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/ldds75 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LDDS75 - -LoRaWAN Distance Detection Sensor - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/161-ldds75.html) -- [Datasheet](http://www.dragino.com/downloads/index.php?dir=LoRa_End_Node/LDDS75/) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- distance - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/lds01.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/lds01.mdx deleted file mode 100644 index 43a24847c..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/lds01.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: lds01 -title: Lds01 -pagination_label: Lds01 -sidebar_label: Lds01 -description: LoRaWAN Door Sensor -image: img/use-the-network/devices/ready-to-use/enthutech/lds01.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/lds01 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LDS01 - -LoRaWAN Door Sensor - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/157-lds01.html) -- [Datasheet](http://www.dragino.com/products/lora-lorawan-end-node/item/157-lds01.html) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- magnetometer - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/ldss20.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/ldss20.mdx deleted file mode 100644 index 9d1fd11f4..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/ldss20.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: ldss20 -title: Ldds20 -pagination_label: Ldss20 -sidebar_label: Ldds20 -description: LoRaWAN Liquid Level Sensor -image: img/use-the-network/devices/ready-to-use/enthutech/ldss20.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/ldss20 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LDDS20 - -LoRaWAN Liquid Level Sensor - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/164-ldds20.html) -- [Datasheet](http://www.dragino.com/products/lora-lorawan-end-node/item/164-ldds20.html) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- level - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/lse01.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/lse01.mdx deleted file mode 100644 index af8481578..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/lse01.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: lse01 -title: Lse01 -pagination_label: Lse01 -sidebar_label: Lse01 -description: LoRaWAN Soil Moisture & Ec Sensor -image: img/use-the-network/devices/ready-to-use/enthutech/lse01.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/lse01 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LSE01 - -LoRaWAN Soil Moisture & EC Sensor - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/159-lse01.html) -- [Datasheet](http://www.dragino.com/products/lora-lorawan-end-node/item/159-lse01.html) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- moisture -- conductivity - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/lsn50v2-d20.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/lsn50v2-d20.mdx deleted file mode 100644 index 159370abd..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/lsn50v2-d20.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: lsn50v2-d20 -title: Lsn50V2-D20 -pagination_label: Lsn50V2 D20 -sidebar_label: Lsn50V2-D20 -description: LoRaWAN Waterproof / Outdoor Temperature Sensor For Air, Liquid Or Object. -image: img/use-the-network/devices/ready-to-use/enthutech/lsn50v2-d20-00.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/lsn50v2-d20 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LSN50v2-D20 - -LoRaWAN Waterproof / Outdoor Temperature Sensor for Air, Liquid or Object. - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/168-lsn50v2-d20.html) -- [Datasheet](http://www.dragino.com/products/lora-lorawan-end-node/item/168-lsn50v2-d20.html) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- temperature - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/lsn50v2-s31.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/lsn50v2-s31.mdx deleted file mode 100644 index a49c61e5b..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/lsn50v2-s31.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: lsn50v2-s31 -title: Lsn50V2-S31 -pagination_label: Lsn50V2 S31 -sidebar_label: Lsn50V2-S31 -description: LoRaWAN Temperature & Humidity Sensor -image: img/use-the-network/devices/ready-to-use/enthutech/lsn50v2-s31-00.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/lsn50v2-s31 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LSN50v2-S31 - -LoRaWAN Temperature & Humidity Sensor - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/169-lsn50v2-s31.html) -- [Datasheet](http://www.dragino.com/downloads/index.php?dir=LoRa_End_Node/LSN50v2-S31/) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- temperature -- humidity - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/lwl01.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/lwl01.mdx deleted file mode 100644 index e9a70f36c..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/lwl01.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -id: lwl01 -title: Lwl01 -pagination_label: Lwl01 -sidebar_label: Lwl01 -description: LoRaWAN Water Leak Sensor -image: img/use-the-network/devices/ready-to-use/enthutech/lwl01.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/lwl01 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LWL01 - -LoRaWAN Water Leak Sensor - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/158-lwl01.html) -- [Datasheet](http://www.dragino.com/products/lora-lorawan-end-node/item/158-lwl01.html) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Sensors: - -- water - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/rs485-bl.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/rs485-bl.mdx deleted file mode 100644 index 09a96ff5c..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/rs485-bl.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: rs485-bl -title: Rs485-Bl -pagination_label: Rs485 Bl -sidebar_label: Rs485-Bl -description: LoRaWAN Rs485/Uart Converter -- Waterproof Battery Powered -image: img/use-the-network/devices/ready-to-use/enthutech/rs485-bl.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/rs485-bl ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## RS485-BL - -LoRaWAN RS485/UART Converter -- WaterProof Battery Powered - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/167-rs485-bl.html) -- [Datasheet](http://www.dragino.com/downloads/index.php?dir=LoRa_End_Node/RS485-BL/&file=Datasheet_RS485-BL_WaterProof_BatteryPower_RS485_UART_to_LoRaWAN_Converter.pdf) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/category/lora-devices-2) - -### Specifications - -#### Dimensions: - -- width: 50 mm -- length: 130 mm -- height: 45 mm - -#### Weight: - -- 150 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/enthutech/rs485-ln.mdx b/docs/use-the-network/devices/ready-to-use/enthutech/rs485-ln.mdx deleted file mode 100644 index 9eb7fcc35..000000000 --- a/docs/use-the-network/devices/ready-to-use/enthutech/rs485-ln.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: rs485-ln -title: Rs485-Ln -pagination_label: Rs485 Ln -sidebar_label: Rs485-Ln -description: An Rs485/Modbus To LoRaWAN Converter -image: img/use-the-network/devices/ready-to-use/enthutech/rs485-ln.jpg -slug: /use-the-network/devices/ready-to-use/enthutech/rs485-ln ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## RS485-LN - -An RS485/Modbus to LoRaWAN Converter - - - -### Resources - -- [Product Page](http://www.dragino.com/products/lora-lorawan-end-node/item/154-rs485-ln.html) -- [Datasheet](http://www.dragino.com/products/lora-lorawan-end-node/item/154-rs485-ln.html) -- [Reseller - Enthu Technology Solutions India Pvt Ltd](https://www.enthutech.in/zh_HK/shop/product/rs485-ln-modbus-to-lorawan-converter-415) - -### Specifications - -#### Dimensions: - -- width: 110 mm -- length: 90 mm -- height: 25 mm - -#### Weight: - -- 210 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/imst/ioke868.mdx b/docs/use-the-network/devices/ready-to-use/imst/ioke868.mdx deleted file mode 100644 index 89ebb625e..000000000 --- a/docs/use-the-network/devices/ready-to-use/imst/ioke868.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: ioke868 -title: iOKE868 -pagination_label: iOKE868 -sidebar_label: iOKE868 -description: - The iOKE868 LoRaWAN optical reading head unit leverages the long-range and low power consumption - of LoRa to provide real-time data monitoring of energy consumption and secure connectivity to a - LoRaWAN IoT network. -image: img/use-the-network/devices/ready-to-use/imst/io881a.jpg -slug: /use-the-network/devices/ready-to-use/imst/ioke868 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## iOKE868 - -The iOKE868 LoRaWAN optical reading head unit leverages the long-range and low power consumption of -LoRa to provide real-time data monitoring of energy consumption and secure connectivity to a LoRaWAN -IoT network. - - - -### Resources - -- [Product Page](https://wireless-solutions.de/products/lora-solutions-by-imst/ioke868-lorawan-optical-unit/) -- [Datasheet](https://wireless-solutions.de/downloadfile/ioke868-documents/) -- [Manual](https://wireless-solutions.de/downloadfile/ioke868-documents/?ind=1684754240298&filename=iOKE868_LoRaWAN_UserManual_V1_2.pdf&wpdmdl=8233&refresh=648a291d3364c1686776093) -- [Quickstart Guide](https://wireless-solutions.de/downloadfile/ioke868-documents/?ind=1684754236765&filename=iOKE868_LoRaWAN_AN031_QuickStartGuide_V1_2.pdf&wpdmdl=8233&refresh=648a291d3370d1686776093) -- [Video](https://youtu.be/QeGTIGgXy8U) - -### Specifications - -#### Dimensions: - -- width: 34 mm -- length: 47 mm -- height: 22 mm - -#### Weight: - -- 33 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/imst/range-extender.mdx b/docs/use-the-network/devices/ready-to-use/imst/range-extender.mdx deleted file mode 100644 index 856cf5f6c..000000000 --- a/docs/use-the-network/devices/ready-to-use/imst/range-extender.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: range-extender -title: Wireless M-Bus Range Extender -pagination_label: Wireless M-Bus Range Extender -sidebar_label: Wireless M-Bus Range Extender -description: - The Wireless M-Bus Range Extender is a compact and cost-effective device that collects wireless - M-Bus messages from utility meters and forwards them to a LoRaWAN network. -image: img/use-the-network/devices/ready-to-use/imst/range-extender.jpg -slug: /use-the-network/devices/ready-to-use/imst/range-extender ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless M-Bus Range Extender - -The Wireless M-Bus Range Extender is a compact and cost-effective device that collects wireless -M-Bus messages from utility meters and forwards them to a LoRaWAN network. - - - -### Resources - -- [Product Page](https://wireless-solutions.de/products/wireless-m-bus-range-extender-with-lorawan) -- [Datasheet](https://wireless-solutions.de/downloadfile/wireless-m-bus-range-extender/?ind=1595853252483&filename=HR_HZ_LoRa-MBus_2020_07_E_K2.pdf&wpdmdl=6973&refresh=648a28eff39cf1686776047) -- [Manual](https://wireless-solutions.de/downloadfile/wireless-m-bus-range-extender/?ind=1638890204007&filename=WMBus_Range_Extender_User_Manual_V1_6.pdf&wpdmdl=6973&refresh=648a28eff380d1686776047) -- [Quickstart Guide](https://wireless-solutions.de/downloadfile/wireless-m-bus-range-extender/?ind=1636362799432&filename=WMBus_Range_Extender_AN032_QuickStartGuide_V1_3.pdf&wpdmdl=6973&refresh=648a28eff38fc1686776047) -- [Video](https://youtu.be/6d6q4RrCpS0) - -### Specifications - -#### Dimensions: - -- width: 92 mm -- length: 145 mm -- height: 55 mm - -#### Weight: - -- 335 grams - -#### Battery: - -- type: 1x SL-2880/S non-rechargeable Lithium-thionyl chloride (Li-SOCL2) / 3.6V / 19 Ah / Size D -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/iotsens/airquality-device.mdx b/docs/use-the-network/devices/ready-to-use/iotsens/airquality-device.mdx deleted file mode 100644 index 250404af7..000000000 --- a/docs/use-the-network/devices/ready-to-use/iotsens/airquality-device.mdx +++ /dev/null @@ -1,69 +0,0 @@ ---- -id: airquality-device -title: Air Quality Monitor -pagination_label: Air Quality Monitor -sidebar_label: Air Quality Monitor -description: - The IoTsens Air Quality monitor consists of a set of environmental sensors capable of collecting - different variables to evaluate the conditions of the air that surrounds it. This device measures - the concentration of CO, SO2, NO2, O3, NO, H2S, CO2, the particles suspended in the air (PM1, - PM2.5 and PM10) and TVOC. -image: img/use-the-network/devices/ready-to-use/iotsens/airquality-device.png -slug: /use-the-network/devices/ready-to-use/iotsens/airquality-device ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Air Quality Monitor - -The IoTsens Air Quality monitor consists of a set of environmental sensors capable of collecting -different variables to evaluate the conditions of the air that surrounds it. This device measures -the concentration of CO, SO2, NO2, O3, NO, H2S, CO2, the particles suspended in the air (PM1, PM2.5 -and PM10) and TVOC. In addition, it also records environmental conditions such as temperature and -humidity. The use of this device is recommended for the evaluation of air conditions, being able to -monitor the levels of contamination to make the appropriate decisions. - - - -### Resources - -- [Product Page](https://www.iotsens.com/en/product/air-quality-monitor/) -- [Datasheet](https://www.iotsens.com/wp-content/datasheets/Calidad_del_Aire_IOTSENS_EN.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -Availability depends on indoor/outdoor and standard/advanced options: - -- CO -- SO2 -- NO2 -- NO -- O3 -- H2S -- CO2 -- TVOC -- PM1 -- PM2.5 -- PM10 -- temperature -- humidity - -#### Dimensions: - -- width: 120 mm -- length: 200 mm -- height: 60 mm - -#### Weight: - -- 400 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/iotsens/lidar-device.mdx b/docs/use-the-network/devices/ready-to-use/iotsens/lidar-device.mdx deleted file mode 100644 index 8d41bc5ad..000000000 --- a/docs/use-the-network/devices/ready-to-use/iotsens/lidar-device.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: lidar-device -title: Optical Distance Monitor -pagination_label: Optical Distance Monitor -sidebar_label: Optical Distance Monitor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/iotsens/lidar-device ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Optical Distance Monitor - -The IoTsens LoRaWAN Optical Distance Monitor is equipped with a LIDAR sensor for monitoring filling -levels. Thus, it becomes an optimal tool in waste management, and can also be used in the detection -of liquid levels in tanks, among other applications. - - - -### Resources - -- [Product Page](http://hardware.iotsens.com/datasheets/IoTsens-Datasheet-Optical_Distance-Monitor_EN.pdf) -- [Datasheet](http://hardware.iotsens.com/datasheets/IoTsens-Datasheet-Optical_Distance-Monitor_EN.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-Device - -#### Sensors: - -- distance -- temperature -- battery - -#### Dimensions: - -- width: 90 mm -- length: 200 mm -- height: 80 mm - -#### Weight: - -- 400 grams (including batteries) - -#### Battery: - -- type: 2x Lithium-thionyl chloride (Li-SOCl2) D / 3.6 V / 13 Ah -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/iotsens/sound-device.mdx b/docs/use-the-network/devices/ready-to-use/iotsens/sound-device.mdx deleted file mode 100644 index 2e53c35b8..000000000 --- a/docs/use-the-network/devices/ready-to-use/iotsens/sound-device.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: sound-device -title: Sound Level Meter -pagination_label: Sound Device -sidebar_label: Sound Level Meter -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/iotsens/sound-monitor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sound Monitor - -The device can monitor noise levels due to its integrated microphone. It can analyze the surrounding -ambient sound A-weighted in the audible frequency spectrum for the human ear, showing the collected -data in dBA. Developed based on the guidelines set out in Directive 2002/49 / CE of the European -Parliament and of the Council, of June 25, 2002 and Law 37/2003 of November 17 published in the BOE -of Spain. This law aims to regulate noise pollution to avoid and, where appropriate, reduce the -damage it may cause to human health, property, or the environment. - - - -### Resources - -- [Product Page](https://www.iotsens.com/en/product/sound-monitor/) -- [Datasheet](https://www.iotsens.com/wp-content/datasheets/Monitor_Sonido_IOTSENS_EN.pdf) - -### Specifications - -#### Sensors: - -- sound -- temperature -- battery - -#### Dimensions: - -- width: 120 mm -- length: 200 mm -- height: 60 mm - -#### Weight: - -- 610 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/izinto/izi-io-4840.mdx b/docs/use-the-network/devices/ready-to-use/izinto/izi-io-4840.mdx deleted file mode 100644 index 28f258786..000000000 --- a/docs/use-the-network/devices/ready-to-use/izinto/izi-io-4840.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: izi-io-4840 -title: izi-io 4840 -pagination_label: izi-io 4840 -sidebar_label: izi-io 4840 -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/izinto/izi-io-4840 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## izi-io 4840 - -Powerful Multi-I/O Edge Computing Controller with LoRaWAN. The top-hat rail-mounted device features -8 analog / RTD / digital inputs, 4 digital outputs as well as CAN interfaces for industry-standard -bus protocols such as Modbus. Built-in Soft-PLC can process data on the device for standalone contro -purposes and efficient LoRaWAN usage. - - - -### Resources - -- [Product Page](https://www.izinto.online/izi-io-en/) -- [Datasheet](https://www.izinto.online/wp-content/uploads/2022/09/izi-io-4840-Data-Sheet-en.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device -- Class B end-device - -#### Sensors: - -- link -- temperature -- voltage -- current - -#### Dimensions: - -- width: 22.5 mm -- length: 119 mm -- height: 101 mm - -#### Weight: - -- 160 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-multi-sensor.mdx b/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-multi-sensor.mdx deleted file mode 100644 index e6cbef85c..000000000 --- a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-multi-sensor.mdx +++ /dev/null @@ -1,95 +0,0 @@ ---- -id: rs1xx-ext-multi-sensor -title: Sentrius RS1xx Multi-Sensor -pagination_label: Sentrius RS1xx Multi-Sensor -sidebar_label: Sentrius RS1xx Multi-Sensor -description: - Multi-Sensor, Integrated Temperature & Humidity Sensor with External Open/Closed Proximity -image: img/use-the-network/devices/ready-to-use/laird/rs1xx-ext-sensor.jpg -slug: /use-the-network/devices/ready-to-use/laird/rs1xx-ext-multi-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sentrius RS1xx Multi-Sensor - -The Sentrius RS1xx Multi-Sensor is a battery-powered, long-range sensor platform leveraging the -benefits of LoRaWAN and Bluetooth Low Energy (BLE) connectivity. Its small, rugged form factor -contains superior RF performance and multiple sensor capabilities including Open/Closed detection -alongside temperature & humidity, making it a perfect fit for cold chain applications. - -Part no: #455-00040/455-00041/455-00071/455-00072/455-00073/455-00074/455-00075/455-00100 - - - -### Resources - -- [Product Page](https://www.lairdconnect.com/iot-devices/lorawan-iot-devices/sentrius-rs1xx-lora-enabled-sensors) -- [Datasheet](https://www.lairdconnect.com/documentation/product-brief-sentrius-rs1xx-openclosed-sensor-and-integrated-temprh) -- [Manual](https://www.lairdconnect.com/documentation/user-guide-sentrius-rs1xx-ext-openclosed-int-temphumidity-sensors) - -- [Reseller - Digi-Key (455-00046 RS1XX Open/Closed Cable Assembly)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00046/11587434) -- [Reseller - Digi-Key (455-00040 RS1XX North America US915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00040/11587435) -- [Reseller - Digi-Key (455-00041 RS1XX Europe EU868)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00041/11587436) -- [Reseller - Digi-Key (455-00071 RS1XX Taiwan AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00071/11587432) -- [Reseller - Digi-Key (455-00072 RS1XX New Zealand AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00072/11587429) -- [Reseller - Digi-Key (455-00073 RS1XX Hong Kong AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00073/11587437) -- [Reseller - Digi-Key (455-00074 RS1XX Australia AU915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00074/11587439) -- [Reseller - Digi-Key (455-00075 RS1XX Australia AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00075/11587430) -- [Reseller - Digi-Key (455-00100 RS1XX Singapore AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00100/11587433) - -- [Reseller - Mouser (455-00046 RS1XX Open/Closed Cable Assembly)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00046?qs=GBLSl2AkiruTG6IIfppszA%3D%3D) -- [Reseller - Mouser (455-00040 RS1XX North America US915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00040?qs=GBLSl2AkirtxT10ZCOu1rQ%3D%3D) -- [Reseller - Mouser (455-00041 RS1XX Europe EU868)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00041?qs=GBLSl2AkirvsxXcPD3wu%2FQ%3D%3D) -- [Reseller - Mouser (455-00071 RS1XX Taiwan AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00071?qs=GBLSl2AkirvntQqPrtPeiQ%3D%3D) -- [Reseller - Mouser (455-00072 RS1XX New Zealand AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00072?qs=GBLSl2Akiru1Dz4sPzMQXw%3D%3D) -- [Reseller - Mouser (455-00073 RS1XX Hong Kong AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00073?qs=GBLSl2Akiru5R2hBjjJhvg%3D%3D) -- [Reseller - Mouser (455-00074 RS1XX Australia AU915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00074?qs=GBLSl2AkiruWeF4FJ92BfA%3D%3D) -- [Reseller - Mouser (455-00075 RS1XX Australia AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00075?qs=GBLSl2AkirvVaqfOzQUIeQ%3D%3D) -- [Reseller - Mouser (455-00100 RS1XX Singapore AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00100?qs=GBLSl2AkirtR%252BdyXyjHSAg%3D%3D) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- proximity - -#### Dimensions: - -**Device:** - -- width: 91 mm -- length: 116 mm -- height: 34 mm - -**External Open/Closed Sensor Cable:** - -- diameter: 30 mm -- length: 1830 mm - -**External Open/Closed Sensor Terminal:** - -- width: 19 mm -- length: 29 mm -- height: 7 mm - -#### Weight: - -- 185 grams - -#### Battery: - -- type: 2x AA alkaline (LR6)/ 1.5 V -- replaceable: True - -#### Note: - -- Sensor operation cannot be switched between countries. -- The Open/Closed cable assembly is not included with the Sentrius sensor enclosure and each part - must be ordered individually. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-1w-sensor.mdx b/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-1w-sensor.mdx deleted file mode 100644 index 4772fe227..000000000 --- a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-1w-sensor.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -id: rs1xx-ext-temp-1w-sensor -title: Sentrius RS1xx External Temperature Probe -pagination_label: RS1xx External Temperature Probe -sidebar_label: Sentrius RS1xx External Temperature Probe -description: Sentrius RS1xx External Temperature Probe. -image: img/use-the-network/devices/ready-to-use/laird/rs1xx-ext-sensor.jpg -slug: /use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-1w-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sentrius RS1xx External Temperature Probe - -RS1xx External Temperature Probe - -The Sentrius RS1xx External Series is a battery-powered, long-range sensor platform leveraging the -benefits of LoRaWAN and Bluetooth Low Energy (BLE) connectivity. Its small, rugged form factor -contains superior RF performance and flexibility with a wide-ranging external temperature probe. - -Part no: #455-00064/#455-00065/#455-00066/#455-00067/#455-00068/#455-00069/#455-00070/#455-00097 - - - -### Resources - -- [Product Page](https://www.lairdconnect.com/iot-devices/lorawan-iot-devices/sentrius-rs1xx-lora-enabled-sensors) -- [Datasheet](https://www.lairdconnect.com/node/11142) -- [Manual](https://www.lairdconnect.com/node/11151) - -- [Reseller - Digi-Key (455-00036 RS1XX External Temperature Probe)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00036/10639026) -- [Reseller - Digi-Key (455-00064 RS1XX Taiwan AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00064/10639016?s=N4IgTCBcDaICwFYEFoAM6BscQF0C%2BQA) -- [Reseller - Digi-Key (455-00065 RS1XX New Zealand AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00065/10639017?s=N4IgTCBcDaICwFYEFoAM6BsCQF0C%2BQA) -- [Reseller - Digi-Key (455-00066 RS1XX Hong Kong AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00066/10639015?s=N4IgTCBcDaICwFYEFoAM6BsGQF0C%2BQA) -- [Reseller - Digi-Key (455-00067 RS1XX Australia AU915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00067/10639012?s=N4IgTCBcDaICwFYEFoAM6BsB2EBdAvkA) -- [Reseller - Digi-Key (455-00068 RS1XX Australia AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00068/10639019?s=N4IgTCBcDaICwFYEFoAM6BsAOEBdAvkA) -- [Reseller - Digi-Key (455-00069 RS1XX Europe EU868)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00069/10639020?s=N4IgTCBcDaICwFYEFoAM6BsBOEBdAvkA) -- [Reseller - Digi-Key (455-00070 RS1XX North America US915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00070/10639014?s=N4IgTCBcDaICwFYEFoAM6DsqQF0C%2BQA) - -- [Reseller - Mouser (455-00036 RS1XX External Temperature Probe)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00036?qs=BJlw7L4Cy7%2FCpdoOZjaWBw%3D%3D) -- [Reseller - Mouser (455-00064 RS1XX Taiwan AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00064?qs=%2Fha2pyFaduiVPYR7juSnK%2Fs3kMTPbvR5t7EtThrSWfQziE16HokG0w%3D%3D) -- [Reseller - Mouser (455-00065 RS1XX New Zealand AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00065?qs=%2Fha2pyFaduiVPYR7juSnK7AoEAY9Gb1zVqqKyBhCff9VwIfiRBR2bw%3D%3D) -- [Reseller - Mouser (455-00066 RS1XX Hong Kong AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00066?qs=%2Fha2pyFaduiVPYR7juSnK5hx9Xz%2F3qlXzfgFUvpyMasvkh%252BC0yiLHw%3D%3D) -- [Reseller - Mouser (455-00067 RS1XX Australia AU915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00067?qs=%2Fha2pyFaduiVPYR7juSnKyvINsVSrtl1q7t9skaNlR4zoIJjGv0R5g%3D%3D) -- [Reseller - Mouser (455-00068 RS1XX Australia AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00068?qs=%2Fha2pyFaduiVPYR7juSnK28NraPxTJxXBk9iQuyGx4UFcwuqCIJ5OA%3D%3D) -- [Reseller - Mouser (455-00069 RS1XX Europe EU868)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00069?qs=%2Fha2pyFaduiVPYR7juSnKxhKN8fEuaKhTTI7qHCC8n8q5GR5faUpRg%3D%3D) -- [Reseller - Mouser (455-00070 RS1XX North America US915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00070?qs=%2Fha2pyFaduibvO2WQuVQr1EeKAajv6AbFp0GDHw2K7Nue1ZNsOqY2A%3D%3D) -- [Reseller - Mouser (455-00097 RS1XX Singapore AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00097?qs=W%2FMpXkg%252BdQ6vfxfEP8u7cg%3D%3D) - -### Specifications - -#### Sensors: - -- temperature - -#### Dimensions: - -**Device:** - -- width: 91 mm -- length: 116 mm -- height: 34 mm - -**Temperature probe:** - -- diameter: 6 mm -- length: 213 mm - -#### Weight: - -- 185 grams - -#### Battery: - -- type: 2x AA alkaline (LR6)/ 1.5 V -- replaceable: True - -#### Note: - -- Sensor operation cannot be switched between countries. -- The external temperature probe cable is not included with the Sentrius sensor enclosure and each - part must be ordered individually. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-rtd-sensor.mdx b/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-rtd-sensor.mdx deleted file mode 100644 index e5459a51b..000000000 --- a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-rtd-sensor.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -id: rs1xx-ext-temp-rtd-sensor -title: Sentrius RS1xx External RTD Temperature Probe -pagination_label: RS1xx External RTD Temperature Probe -sidebar_label: Sentrius RS1xx External RTD Temperature Probe -description: Sentrius RS1xx External RTD Temperature Probe #455-00103/455-00104/455-00105/455-00106/455-00108/455-00109/455-00110/455-00111 -image: img/use-the-network/devices/ready-to-use/laird/rs1xx-ext-sensor.jpg -slug: /use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-rtd-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sentrius RS1xx External RTD Temperature Probe - -Sentrius RS1xx External RTD Temperature Probe The Sentrius RS1xx External RTD Temperature Probe is a -battery-powered, long-range sensor platform that leverages the benefits of LoRaWAN and Bluetooth Low -Energy (BLE) connectivity. The RS1xx External RTD Temperature Probe serves specialized temperature -ranges for accurate temperature reading in extreme environments. - -Low Temp (-100°C to +100°C): suited for cold-chain applications such as food safety, vaccine -storage, industrial cooling, etc. Mid Temp (-40°C to +180°C): suited for applications such as -industrial cookers and smokers, food safety, HVAC, etc. High Temp (-50°C to +450°C): suited for -applications such as extreme industrial applications, fryers, pizza ovens, etc. - -Part no: #455-00103/#455-00104/#455-00105/#455-00106/#455-00108/#455-00109/#455-00110/#455-00111 - - - -### Resources - -- [Product Page](https://www.lairdconnect.com/iot-devices/lorawan-iot-devices/sentrius-rs1xx-lora-enabled-sensors) -- [Datasheet - Low Temp](https://www.lairdconnect.com/documentation/product-brief-sentrius-rs1xx-external-rtd-temp-probe-100-c-148-f) -- [Datasheet - Mid Temp](https://www.lairdconnect.com/documentation/product-brief-sentrius-rs1xx-external-rtd-temp-probe-180-c-350-f) -- [Datasheet - High Temp](https://www.lairdconnect.com/documentation/product-brief-sentrius-rs1xx-external-rtd-temp-probe-50-c-450-c) -- [Manual](https://www.lairdconnect.com/node/11151) - -- [Reseller - Digi-Key (455-00112 RS1XX RTD Mid Temp Sensor Cable Assembly)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00112/11691225) -- [Reseller - Digi-Key (455-00123 RS1XX RTD High Temp Sensor Cable Assembly)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00123/15276443) -- [Reseller - Digi-Key (455-00124 RS1XX RTD Low Temp Sensor Cable Assembly)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00124/13901891) -- [Reseller - Digi-Key (455-00103 RS1XX North America US915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00103/11691229) -- [Reseller - Digi-Key (455-00104 RS1XX Europe EU868)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00104/11691233) -- [Reseller - Digi-Key (455-00105 RS1XX Taiwan AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00105/11691232) -- [Reseller - Digi-Key (455-00106 RS1XX New Zealand AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00106/11691231) -- [Reseller - Digi-Key (455-00109 RS1XX Hong Kong AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00109/11691230) -- [Reseller - Digi-Key (455-00110 RS1XX Australia AU915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00110/11691226) -- [Reseller - Digi-Key (455-00111 RS1XX Australia AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00111/11691228) - -- [Reseller - Mouser (455-00112 RS1XX RTD Mid Temp Sensor Cable Assembly)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00112?qs=rI7uf1IzohSFux28s78pfg%3D%3D) -- [Reseller - Mouser (455-00123 RS1XX RTD High Temp Sensor Cable Assembly)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00123?qs=Wj%2FVkw3K%252BMAjG3bk1OyC0g%3D%3D) -- [Reseller - Mouser (455-00124 RS1XX RTD Low Temp Sensor Cable Assembly)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00124?qs=stqOd1AaK7%2FWTr31yZ5hnw%3D%3D) -- [Reseller - Mouser (455-00103 RS1XX North America US915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00103?qs=rI7uf1IzohSMqhNiYJbMLQ%3D%3D) -- [Reseller - Mouser (455-00104 RS1XX Europe EU868)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00104?qs=rI7uf1IzohQJRBfgRwgiWA%3D%3DD) -- [Reseller - Mouser (455-00105 RS1XX Taiwan AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00105?qs=rI7uf1IzohR1QGqtWL8iPA%3D%3D) -- [Reseller - Mouser (455-00106 RS1XX New Zealand AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00106?qs=rI7uf1IzohQEoLzkMNh4Rg%3D%3D) -- [Reseller - Mouser (455-00108 RS1XX Singapore AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00108?qs=W%2FMpXkg%252BdQ4uz46Y19fr%252BQ%3D%3D) -- [Reseller - Mouser (455-00109 RS1XX Hong Kong AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00109?qs=rI7uf1IzohSvZ%2F5rjkxGTw%3D%3D) -- [Reseller - Mouser (455-00110 RS1XX Australia AU915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00110?qs=rI7uf1IzohQbUtuo2yfbxg%3D%3D) -- [Reseller - Mouser (455-00111 RS1XX Australia AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00111?qs=rI7uf1IzohR2QFm%2FnDylcA%3D%3D) - -### Specifications - -#### Sensors: - -- temperature - -#### Dimensions: - -**Device:** - -- width: 91 mm -- length: 116 mm -- height: 34 mm - -| Temperature range | Cable | Stainless-steel shaft | Shaft collar | -| :---------------- | :-------------- | :-------------------- | :------------- | -| Low | diameter: 2 mm | diameter: 3.3 mm | | -| | length: 2000 mm | length: 50 mm | | -| Mid | diameter: 2 mm | diameter: 4 mm | | -| | length: 1320 mm | length: 100 mm | | -| High | diameter: 2 mm | diameter: 4 mm | diameter: 7 mm | -| | length: 2000 mm | length: 200 mm | length: 40 mm | - -#### Weight: - -- 185 grams - -#### Battery: - -- type: 2x AA alkaline (LR6)/ 1.5 V -- replaceable: True - -#### Note: - -- Sensor operation cannot be switched between countries. -- The external RTD temperature probe cable assembly is not included with the Sentrius sensor - enclosure and each part must be ordered individually. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-temp-rh-sensor.mdx b/docs/use-the-network/devices/ready-to-use/laird/rs1xx-temp-rh-sensor.mdx deleted file mode 100644 index 05c8f7ac0..000000000 --- a/docs/use-the-network/devices/ready-to-use/laird/rs1xx-temp-rh-sensor.mdx +++ /dev/null @@ -1,73 +0,0 @@ ---- -id: rs1xx-temp-rh-sensor -title: Laird Sentrius RS1xx Integrated Temp & Humidity -pagination_label: RS1xx Integrated Temp & Humidity Sensor -sidebar_label: Sentrius RS1xx Integrated Temp & Humidity Sensor -description: RS1xx Integrated Temperature & Humidity Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/laird/rs1xx-temp-rh-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Sentrius RS1xx Integrated Temperature & Humidity Sensor - -The Sentrius RS1xx Integrated Temperature and Humidity sensors enable battery-powered, local and -wide-area sensor applications using LoRaWAN and Bluetooth 4.2! The RS1xx are small, rugged, and -easily configurable sensors making it easier than ever to monitor environmental data with your own -network of sensors. - -Part no: #455-0001/#455-0002/#455-00059/#455-00060/#455-00061/#455-00062/#455-00063/#455-00095 - - - -### Resources - -- [Product Page](https://www.lairdconnect.com/iot-devices/lorawan-iot-devices/sentrius-rs1xx-lora-enabled-sensors) -- [Datasheet](https://www.lairdconnect.com/documentation/product-brief-sentrius-rs1xx-integrated-temp-humidity-sensor) -- [Manual](https://www.lairdconnect.com/documentation/user-guide-sentrius-rs1xx-ext-openclosed-int-temphumidity-sensors) - -- [Reseller - Digi-Key (455-0001 RS1XX North America US915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-0001/8023006) -- [Reseller - Digi-Key (455-0002 RS1XX Europe EU868)](https://www.digikey.co.uk/product-detail/en/laird-connectivity-inc/455-0002/455-0002-ND/8023004) -- [Reseller - Digi-Key (455-00059 RS1XX Taiwan AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00059/10639011?s=N4IgTCBcDaICwFYEFoAM6EE4QF0C%2BQA) -- [Reseller - Digi-Key (455-00060 RS1XX New Zealand AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00060/10639021?s=N4IgTCBcDaICwFYEFoAM6BsqQF0C%2BQA) -- [Reseller - Digi-Key (455-00061 RS1XX Hong Kong AS923)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00061/10639025?s=N4IgTCBcDaICwFYEFoAM6BsBGEBdAvkA) -- [Reseller - Digi-Key (455-00062 RS1XX Australia AU915)](https://www.digikey.com/en/products/detail/laird-connectivity-inc/455-00062/10639013?s=N4IgTCBcDaICwFYEFoAM6BsEC6BfIA) - -- [Reseller - Mouser (455-0001 RS1XX North America US915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-0001?qs=f9yNj16SXrLHWGWgPjEnvQ%3D%3D) -- [Reseller - Mouser (455-0002 RS1XX Europe EU868)](https://www.mouser.co.uk/ProductDetail/Laird-Connectivity/455-0002/?qs=f9yNj16SXrIAaoVm5TkfuA%3D%3D) -- [Reseller - Mouser (455-00059 RS1XX Taiwan AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00059?qs=%2Fha2pyFadug275OP%2F%252BIeOGqsiPUjgBUS3ujP7OCtiSiqAKHYcWnchQ%3D%3D) -- [Reseller - Mouser (455-00060 RS1XX New Zealand AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00060?qs=%2Fha2pyFaduiVPYR7juSnK4HtmUbAGQ%2FyY9G5NV4%2F5WnloWmX%2FDVRmg%3D%3D) -- [Reseller - Mouser (455-00061 RS1XX Hong Kong AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00061?qs=%2Fha2pyFaduiVPYR7juSnK65B4wN7scy2iXni0py6MqHs2gndLUPjTA%3D%3D) -- [Reseller - Mouser (455-00062 RS1XX Australia AU915)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00062?qs=%2Fha2pyFaduiVPYR7juSnK7Z5c85KXbBGXG2burRb%252Bu%2Fiv4fNSMhC1g%3D%3D) -- [Reseller - Mouser (455-00095 RS1XX Singapore AS923)](https://www.mouser.com/ProductDetail/Laird-Connectivity/455-00095?qs=W%2FMpXkg%252BdQ5CxdiDQv0Dww%3D%3D) - -### Specifications - -#### Sensors: - -- temperature -- humidity - -#### Dimensions: - -- width: 91 mm -- length: 116 mm -- height: 34 mm - -#### Weight: - -- 185 grams - -#### Battery: - -- type: 2x AA alkaline (LR6)/ 1.5 V -- replaceable: True - -#### Note: - -- Sensor operation cannot be switched between countries. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw06davk.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw06davk.mdx deleted file mode 100644 index 88ee095de..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw06davk.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: mcf-lw06davk -title: Mcf-Lw06Davk -pagination_label: Mcf Lw06Davk -sidebar_label: Mcf-Lw06Davk -description: Davis Vantage Interface -image: img/use-the-network/devices/ready-to-use/mcf88/mcf-lwws00.jpg -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw06davk ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCF-LW06DAVK - -Davis Vantage interface - - - -### Resources - -- [Product Page](https://www.mcf88.it/prodotto/mcf-lw06davk/) -- [Datasheet](https://www.mcf88.it/wp-content/uploads/2020/07/MCF-LWWS06DAVK_DAVKP.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- barometer -- wind speed -- wind direction -- rainfall -- solar radiation -- uv - -#### Dimensions: - -- width: 81 mm -- length: 60 mm -- height: 50 mm - -#### Weight: - -- 250 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw06davpk.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw06davpk.mdx deleted file mode 100644 index 3a690102f..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw06davpk.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: mcf-lw06davpk -title: Mcf-Lw06Davpk -pagination_label: Mcf Lw06Davpk -sidebar_label: Mcf-Lw06Davpk -description: Davis Vantage Interface With Pm -image: img/use-the-network/devices/ready-to-use/mcf88/mcf-lwws00.jpg -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw06davpk ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MCF-LW06DAVPK - -Davis Vantage interface with PM - - - -### Resources - -- [Product Page](https://www.mcf88.it/prodotto/mcf-lw06davk/) -- [Datasheet](https://www.mcf88.it/wp-content/uploads/2020/07/MCF-LWWS06DAVK_DAVKP.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- barometer -- wind speed -- wind direction -- rainfall -- solar radiation -- uv -- dust - -#### Dimensions: - -- width: 200 mm -- length: 210 mm -- height: 310 mm - -#### Weight: - -- 2500 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12co2.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12co2.mdx deleted file mode 100644 index 9a2b5b9fe..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12co2.mdx +++ /dev/null @@ -1,73 +0,0 @@ ---- -id: mcf-lw12co2 -title: MCF-LW12CO2E -pagination_label: MCF-LW12CO2E LoRaWAN Indoor Environmental Sensor -sidebar_label: MCF-LW12CO2E LoRaWAN Indoor Environmental Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw12co2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW12CO2E LoRaWAN Indoor Environmental Sensor VOC / LUX / CO2 with Leds - -MCF-LW12CO2E LoRaWAN Indoor Environmental Sensor VOC / LUX / CO2 with Leds - -The MCF-LW12CO2E Indoor Environmental Sensor is a battery-powered sensor for indoor applications -that reads the temperature, relative humidity, barometric pressure, ambient light, IAQ air quality -index and CO2. The device sends collected data over the LoRaWAN network. Ideally suited for a wide -range of applications such as building automation, condition monitoring, predictive maintenance, -security, healthcare and many more use cases. - - - -### Resources - -- [Product Page](https://www.mcf88.it/prodotto/mcf-lw12co2/) -- [Datasheet](https://enginko.com/wp-content/uploads/2020/09/enginko%C2%AE_datasheet_MCF-LW12CO2E_EN013W02-1.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw12co2e) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- relative humidity -- barometric pressure -- ambient light (LUX) -- IAQ index -- bVOC -- CO2 - -#### Dimensions: - -- width: 80 mm -- length: 120 mm -- height: 25 mm - -#### Weight: - -- 225 grams - -#### Battery: - -- type: 2x Lithium-thionyl chloride (Li-SOCl2) packs / total 21600 mAh (MCF-1S4PE: 14400 mAh + - MCF-12SPE: 7200 mAh) -- replaceable: True - -#### Note: - -- To ensure correct operation and reliable and consistent measurements, install the MCF-LW12CO2E - sensor away from direct sunlight and heating sources like radiators, conveyors, TV, lights etc., - and far away from doors and windows. -- NFC for node configuration, FW update and data reading. -- The sensor needs both battery packs, otherwise, the performance and battery life are not - guaranteed. -- The battery packs must be replaced together, do not let the sensor run with battery packs with - different levels of charge. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12met.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12met.mdx deleted file mode 100644 index c613c7591..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12met.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: mcf-lw12met -title: MCF-LW12MET -pagination_label: MCF-LW12MET LoRaWAN Mono-Phase Metering -sidebar_label: MCF-LW12MET LoRaWAN Mono-Phase Metering -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw12met ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW12MET LoRaWAN Mono-Phase Metering - -MCF-LW12MET LoRaWAN Mono-Phase Metering - -The MCF-LW12MET is a LoRaWAN Mono-Phase Meter that allows instantaneous reading of active, reactive -and apparent power, voltage and current up to 230 V AC - 16 Amp (active, reactive and apparent -energy, Class 0.2s). It can switch ON and OFF a 230 V AC - 8A load and reads the status of a 100-230 -V AC input. It can be used for industrial process control and home automation, energy metering, -water treatment, agriculture irrigation and similar applications. Input can be used as a pulse -counter. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/mono-phase-metering-mcf-lw12met/) -- [Datasheet](https://enginko.com/wp-content/uploads/2020/09/MCF-LW12MET.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw12met) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- power -- voltage -- current -- energy -- time -- digital input - -#### Dimensions: - -- width: 53.4 mm -- length: 87.2 mm -- height: 25 mm - -#### Note: - -- The installation has to be done by a qualified electrician. -- The device is intended as a subassembly (component). -- The MCF-LW12MET must be mounted in a vertical position. -- NFC for IoT node setup, FW upgrade and data reading. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12plg.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12plg.mdx deleted file mode 100644 index 93f6aded9..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12plg.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: mcf-lw12plg -title: EGK-LW22PLG -pagination_label: EGK-LW22PLG LoRaWAN Energy Meter Plug with On/Off -sidebar_label: EGK-LW22PLG LoRaWAN Energy Meter Plug with On/Off -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/egk-lw22plg ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko EGK-LW22PLG LoRaWAN Energy Meter Plug with On/Off - -EGK-LW22PLG LoRaWAN Energy Meter Plug with On/Off - -The EGK-LW22PLG is a compact C-class LoRaWAN energy meter that can monitor and switch a 230 V AC - -16 Amp Load (active, reactive and apparent energy, Class 0.2s), equipped with a rechargeable battery -for mains outage detection, with configurable default power-on status. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/lorawan-energy-meter-egk-lw22plg/) -- [Datasheet](https://enginko.com/wp-content/uploads/2022/01/enginko%C2%AE_datasheet_EGK-LW22PLG_EN092W01.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_egk-lw22plg) - -### Specifications - -#### LoRaWAN device type: - -- Class C end-device - -#### Sensors: - -- power -- voltage -- current -- energy -- time - -#### Dimensions: - -- width: 62 mm -- length: 110 mm -- height: 35 mm - -#### Weight: - -- 140 grams - -#### Note: - -- rechargeable lithium battery for powerline outage detection. -- embedded antenna. -- overload protection -- BLE 5.0 interface for configuration, data reading and FW upgrade. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12ter.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12ter.mdx deleted file mode 100644 index 2b3dc01f7..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12ter.mdx +++ /dev/null @@ -1,63 +0,0 @@ ---- -id: mcf-lw12ter -title: MCF-LW12TER -pagination_label: MCF-LW12TER LoRaWAN Indoor Environmental Sensor -sidebar_label: MCF-LW12TER LoRaWAN Indoor Environmental Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw12ter ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW12TER LoRaWAN Indoor Environmental Sensor - -MCF-LW12TER LoRaWAN Indoor Environmental Sensor - -The MCF-LW12TER Indoor Environmental Sensor reads the temperature, relative humidity and barometric -pressure and sends collected data over the LoRaWAN network. Ideally suited for a wide range of -applications such as building automation, condition monitoring, predictive maintenance, security, -healthcare and many more use cases. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/indoor-environmental-sensor-mcf-lw12ter/) -- [Datasheet](https://enginko.com/wp-content/uploads/2020/09/MCF-LW12TER.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw12ter) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- relative humidity -- barometric pressure - -#### Dimensions: - -- width: 80 mm -- length: 80 mm -- height: 25 mm - -#### Weight: - -- 145 grams - -#### Battery: - -- type: 1x Lithium-thionyl chloride (Li-SOCl2) pack / MCF-1S4PE: 14400 mAh -- replaceable: True - -#### Note: - -- To ensure correct operation and reliable and consistent measurements, install the MCF-LW12TER - sensor away from direct sunlight and heating sources like radiators, conveyors, TV, lights etc. - and far away from doors and windows. -- NFC for IoT node setup, FW upgrade and data reading. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12terpm.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12terpm.mdx deleted file mode 100644 index 069e2822b..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12terpm.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -id: mcf-lw12terpm -title: MCF-LW12TERPM -pagination_label: MCF-LW12TERPM LoRaWAN Outdoor Environmental Sensor PM1 PM2.5 PM10 -sidebar_label: MCF-LW12TERPM LoRaWAN Outdoor Environmental Sensor PM1 PM2.5 PM10 -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw12terpm ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW12TERPM LoRaWAN Outdoor Environmental Sensor PM1 PM2.5 PM10 - -MCF-LW12TERPM LoRaWAN Outdoor Environmental Sensor PM1 PM2.5 PM10 - -The MCF-LW12TERPM is a solar-powered outdoor environmental sensor that reads the temperature, -relative humidity, barometric pressure and PM (PM1, PM2.5, PM10) and sends collected data over the -LoRaWAN network. Ideally suited for a wide range of applications such as weather stations, urban -monitoring, air quality, industrial, environmental or farming projects. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/lorawan-outdoor-environmental-sensor-mcf-lw12terpm/) -- [Datasheet](https://enginko.com/wp-content/uploads/2020/09/enginko%C2%AE_datasheet_MCF-LW12TERPM_EN013W01.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw12terpm) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- relative humidity -- barometric pressure -- PM (PM1, PM2.5, PM10) - -#### Dimensions: - -- width: 200 mm -- length: 210 mm -- height: 310 mm - -#### Weight: - -- 2500 grams - -#### Battery: - -- main: 1x 860 mAh Li-ion rechargeable battery -- backup: 1x Lithium-thionyl chloride (Li-SOCl2) pack / MCF-1S2PE: 7200 mAh -- replaceable: True - -#### Note: - -- Place the sensor in a way that the solar panel is not in the shade and exposed to the greatest - possible amount of sunlight during the day. -- NFC for IoT node setup, FW upgrade and data reading. -- The sensor can be installed on the wall or pole using the included accessories. -- With the backup battery pack MCF-1S2PE the sensor can run for 1 year with the rechargeable battery - completely discharged. -- Battery replacement can be done only by enginko or trained personnel. -- Keep the surfaces clean and remove dust from the solar panel with a damp cloth when necessary. - Remove gently any debris lodged inside the unit. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12terwp.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12terwp.mdx deleted file mode 100644 index f6cad88ee..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12terwp.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: mcf-lw12terwp -title: MCF-LW12TERWP -pagination_label: MCF-LW12TERWP LoRaWAN IP67 Outdoor Environmental Sensor -sidebar_label: MCF-LW12TERWP LoRaWAN IP67 Outdoor Environmental Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw12terwp ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW12TERWP LoRaWAN IP67 Outdoor Environmental Sensor - -MCF-LW12TERWP LoRaWAN IP67 Outdoor Environmental Sensor - -The MCF-LW12TERWP is an IP67 battery-powered outdoor environmental sensor that reads the -temperature, relative humidity and barometric pressure and sends collected data over the LoRaWAN -network. Ideally suited for a wide range of applications such as weather stations, urban monitoring, -air quality, industrial, environmental or farming projects. - - - -### Resources - -- [Product Page](https://www.mcf88.it/prodotto/mcf-lw12terwp/) -- [Datasheet](https://enginko.com/wp-content/uploads/2020/09/MCF-LW12TERWP.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw12terwp) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- relative humidity -- barometric pressure - -#### Dimensions: - -- width: 150 mm -- length: 150 mm -- height: 40 mm - -#### Battery: - -- type: 1x Lithium-thionyl chloride (Li-SOCl2) pack / MCF-1S4PE: 14400 mAh -- replaceable: True - -#### Note: - -- To ensure correct operation and reliable and consistent measurements, install the MCF-LW12TERWP - sensor away from direct sunlight and rain. -- NFC for IoT node setup, FW upgrade and data reading. -- The sensor can be installed on the wall or pole using the included accessories. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12voc.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12voc.mdx deleted file mode 100644 index 21aee5c99..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw12voc.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -id: mcf-lw12voc -title: MCF-LW12VOC -pagination_label: MCF-LW12VOC LoRaWAN Indoor Environmental Sensor VOC & LUX -sidebar_label: MCF-LW12VOC LoRaWAN Indoor Environmental Sensor VOC & LUX -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw12voc ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW12VOC LoRaWAN Indoor Environmental Sensor VOC & LUX - -MCF-LW12VOC LoRaWAN Indoor Environmental Sensor VOC & LUX - -The MCF-LW12VOC Indoor Environmental Sensor is a battery-powered sensor for indoor applications that -reads the temperature, relative humidity, barometric pressure, ambient light and IAQ air quality -index. The device sends collected data over the LoRaWAN network. Ideally suited for a wide range of -applications such as home buildings, air quality monitoring and energy-saving applications. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/indoor-environmental-sensor-mcf-lw12voc/) -- [Datasheet](https://enginko.com/wp-content/uploads/2020/09/MCF-LW12VOC.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw12voc) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- relative humidity -- barometric pressure -- ambient light (LUX) -- IAQ index -- bVOC - -#### Dimensions: - -- width: 80 mm -- length: 80 mm -- height: 25 mm - -#### Weight: - -- 145 grams - -#### Battery: - -- type: 1x Lithium-thionyl chloride (Li-SOCl2) pack / MCF-1S4PE: 14400 mAh -- replaceable: True - -#### Note: - -- To ensure correct operation and reliable and consistent measurements, install the MCF-LW12VOC - sensor away from direct sunlight and heating sources like radiators, conveyors, TV, lights etc., - and far away from doors and windows. -- NFC for node configuration, FW update and data reading. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw13io.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw13io.mdx deleted file mode 100644 index f9ab83cf0..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw13io.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: mcf-lw13io -title: MCF-LW13IO -pagination_label: MCF-LW13IO LoRaWaN Wireless Actuator -sidebar_label: MCF-LW13IO LoRaWAN Wireless Actuator -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw13io ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW13IO LoRaWAN Wireless Actuator - -MCF-LW13IO LoRaWAN Wireless Actuator - -The MCF-LW13IO is a wireless actuator that can switch ON and OFF a 230 V AC - 8A load and reads the -status of a 100-230 V AC input. The device can transmit the status of its input and control the -output through the LoRaWAN network. The device can be used for industrial process control and home -automation, water treatment and similar applications. Input can be used as a pulse counter. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/lorawan-actuator-mcf-lw13io/) -- [Datasheet](https://www.mcf88.it/wp-content/uploads/2020/07/MCF-LW13IO.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw13io) - -### Specifications - -#### LoRaWAN device type: - -- Class C end-device - -#### Sensors: - -- digital input -- digital output -- counter - -#### Dimensions: - -- width: 44 mm -- length: 58 mm -- height: 25 mm - -#### Note: - -- The installation has to be done by a qualified electrician. -- The device is intended as a subassembly (component). -- The MCF-LW13IO must be mounted in a vertical position. -- NFC for IoT node setup and FW upgrade. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw13mio.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw13mio.mdx deleted file mode 100644 index 4a82a4650..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lw13mio.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -id: mcf-lw13mio -title: MCF-LW13MIO -pagination_label: MCF-LW13MIO LoRaWAN Multi I/O Module -sidebar_label: MCF-LW13MIO LoRaWAN Multi I/O Module -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lw13mio ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LW13MIO LoRaWAN Multi I/O Module - -MCF-LW13MIO LoRaWAN Multi I/O Module - -The MCF-LW13MIO LoRaWAN Multi I/O Module is a device that transmits the state of its 16 inputs (5-28 -V AC/DC) and controls 8 outputs (up to 5A - 230 V AC) through the LoRaWAN network. All these inputs -and outputs are galvanically isolated. It can be used for industrial process control, home -automation, water treatment, agriculture irrigation and similar applications. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/mcf-lw13mio/) -- [Datasheet](https://enginko.com/wp-content/uploads/2022/09/enginko%C2%AE_datasheet_MCF-LW13MIO-EN092W01.pdf) -- [Manual](https://www.enginko.com/support/doku.php?id=manual_mcf-lw13mio) - -### Specifications - -#### LoRaWAN device type: - -- Class C end-device - -#### Sensors: - -- 16 digital inputs -- 8 digital outputs -- up to 16 counter - -#### Dimensions: - -- width: 110 mm -- length: 160.2 mm -- height: 62 mm - -#### Note: - -- The installation has to be done by a qualified electrician. -- The device is intended as a subassembly (component). -- The MCF-LW13MIO must be mounted in a vertical position. -- USB port for IoT node setup and FW upgrade. -- DIN (EN 60715) mounting enclosure, 9 modules. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws00.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws00.mdx deleted file mode 100644 index 0bd940721..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws00.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -id: mcf-lwws00 -title: MCF-LWWS00 -pagination_label: MCF-LWWS00 LoRaWAN Weather Station -sidebar_label: MCF-LWWS00 LoRaWAN Weather Station -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lwws00 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LWWS00 LoRaWAN Weather Station - -MCF-LWWS00 LoRaWAN Weather Station - -The MCF-LWWS00 LoRaWAN Weather Station is a complete Davis Instruments Vantage Pro2 GroWeather -Station that integrates a LoRaWAN communication system (MCF-LW06DAV or MCF-LW06DAVP). The station, -rugged and flexible, is equipped with a wide range of sensors and it offers reliable weather data -under the most demanding circumstances. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/weather-station-lorawan-mcf-lwws00/) -- [Datasheet MCF-LWWS00](https://enginko.com/wp-content/uploads/2020/09/enginko%C2%AE_datasheet_MCF-LWWS00-01-02-03_EN013W01.pdf) -- [Installation Manual MCF-LWWS00](https://www.enginko.com/support/doku.php?id=manual_mcf-lwws0x) -- [Datasheet ISS Davis Vantage Pro2 GroWeather [6820CM]](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/6820_6820C_Spec_Sheet_Web.pdf?v=1631307649) -- [Manual ISS Davis Vantage Pro2 GroWeather Sensor Suite [6820C]](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/07395-289_UM_6820.pdf) -- [Manual Solar Box](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/07395-326_IM_06612_06614.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- indoor temperature -- outdoor temperature -- relative humidity -- barometric pressure -- dew point -- wind speed -- wind direction -- rainfall -- solar radiation -- UV (optional) - -#### Dimensions: - -**Sensor Suite (ISS):** - -- width: 246 mm -- length: 363 mm -- height: 368 mm - -**Solar box:** - -- width: 254 mm -- length: 349 mm -- height: 105 mm - -#### Battery Sensor Suite: - -- primary power: solar power - Davis solar charger -- backup power: 1x CR123A (lithium) / 3 V / 1500 mAh (8 months without sunlight) - -#### Note: - -- This version includes a mounting tripod with lag bolts. -- Sensor suite dimensions do not include the anemometer or bird spikes. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws01.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws01.mdx deleted file mode 100644 index f6961e978..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws01.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -id: mcf-lwws01 -title: MCF-LWWS01 -pagination_label: MCF-LWWS01 LoRaWAN Weather Station with PM Sensor -sidebar_label: MCF-LWWS01 LoRaWAN Weather Station with PM Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lwws01 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LWWS01 LoRaWAN Weather Station with PM Sensor - -MCF-LWWS01 LoRaWAN Weather Station with PM Sensor - -The MCF-LWWS01 LoRaWAN Weather Station with PM Sensor is a complete Davis Instruments Vantage Pro2 -GroWeather Station that integrates a LoRaWAN communication system (MCF-LW06DAV or MCF-LW06DAVP). The -station, rugged and flexible, is equipped with a wide range of sensors and it offers reliable -weather data under the most demanding circumstances. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/weather-station-lorawan-mcf-lwws00/) -- [Datasheet MCF-LWWS01](https://enginko.com/wp-content/uploads/2020/09/enginko%C2%AE_datasheet_MCF-LWWS00-01-02-03_EN013W01.pdf) -- [Installation Manual MCF-LWWS01](https://www.enginko.com/support/doku.php?id=manual_mcf-lwws0x) -- [Datasheet ISS Davis Vantage Pro2 GroWeather [6820CM]](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/6820_6820C_Spec_Sheet_Web.pdf?v=1631307649) -- [Manual ISS Davis Vantage Pro2 GroWeather Sensor Suite [6820C]](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/07395-289_UM_6820.pdf) -- [Manual Solar Box](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/07395-326_IM_06612_06614.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- indoor temperature -- outdoor temperature -- relative humidity -- barometric pressure -- dew point -- wind speed -- wind direction -- rainfall -- solar radiation -- PM (PM1, PM2.5, PM10) -- UV (optional) - -#### Dimensions: - -**Sensor Suite (ISS):** - -- width: 246 mm -- length: 363 mm -- height: 368 mm - -**Solar box:** - -- width: 254 mm -- length: 349 mm -- height: 105 mm - -#### Battery Sensor Suite: - -- primary power: solar power - Davis solar charger -- backup power: 1x CR123A (lithium) / 3 V / 1500 mAh (8 months without sunlight) - -#### Note: - -- This version includes a mounting tripod with lag bolts. -- Sensor suite dimensions do not include the anemometer or bird spikes. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws02.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws02.mdx deleted file mode 100644 index b5d812aa5..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws02.mdx +++ /dev/null @@ -1,73 +0,0 @@ ---- -id: mcf-lwws02 -title: MCF-LWWS02 -pagination_label: MCF-LWWS02 LoRaWAN Basic Weather Station -sidebar_label: MCF-LWWS02 LoRaWAN Basic Weather Station -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lwws02 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LWWS02 LoRaWAN Basic Weather Station - -MCF-LWWS02 LoRaWAN Basic Weather Station - -The MCF-LWWS02 LoRaWAN Basic Weather Station is a complete Davis Instruments Vantage Pro2 Weather -Station that integrates a LoRaWAN communication system (MCF-LW06DAV or MCF-LW06DAVP). The station, -rugged and flexible, is equipped with a wide range of sensors and it offers reliable weather data -under the most demanding circumstances. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/weather-station-lorawan-mcf-lwws00/) -- [Datasheet MCF-LWWS02](https://enginko.com/wp-content/uploads/2020/09/enginko%C2%AE_datasheet_MCF-LWWS00-01-02-03_EN013W01.pdf) -- [Installation Manual MCF-LWWS02](https://www.enginko.com/support/doku.php?id=manual_mcf-lwws0x) -- [Datasheet ISS Davis Vantage Pro2](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/6152_62_53_63_ss.pdf?v=1623783718) -- [Manual ISS Davis Vantage Pro2 Sensor Suite [6322C]](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/07395-333_IM-6322C-6334.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- indoor temperature -- outdoor temperature -- relative humidity -- barometric pressure -- dew point -- wind speed -- wind direction -- rainfall -- UV (optional) - -#### Dimensions: - -**Sensor Suite (ISS) with Standard Radiation Shield:** - -- width: 239 mm -- length: 356 mm -- height: 368 mm - -**Console with antenna:** - -- width: 156 mm -- length: 270 mm -- height: 41 mm - -#### Battery Sensor Suite: - -- primary power: solar power - Davis solar charger -- backup power: 1x CR123A (lithium) / 3 V / 1500 mAh (8 months without sunlight) - -### Note: - -- This version includes a pole kit. -- Sensor suite dimensions do not include the anemometer or bird spikes. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws03.mdx b/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws03.mdx deleted file mode 100644 index bde6e703a..000000000 --- a/docs/use-the-network/devices/ready-to-use/mcf88/mcf-lwws03.mdx +++ /dev/null @@ -1,74 +0,0 @@ ---- -id: mcf-lwws03 -title: MCF-LWWS03 LoRaWAN Basic Weather Station with PM Sensor -pagination_label: MCF-LWWS03 LoRaWAN Basic Weather Station with PM Sensor -sidebar_label: MCF-LWWS03 LoRaWAN Basic Weather Station with PM Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mcf88/mcf-lwws03 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## enginko MCF-LWWS03 LoRaWAN Basic Weather Station with PM Sensor - -MCF-LWWS03 LoRaWAN Basic Weather Station with PM Sensor - -The MCF-LWWS03 LoRaWAN Basic Weather Station with PM Sensor is a complete Davis Instruments Vantage -Pro2 Weather Station that integrates a LoRaWAN communication system (MCF-LW06DAV or MCF-LW06DAVP). -The station, rugged and flexible, is equipped with a wide range of sensors and it offers reliable -weather data under the most demanding circumstances. - - - -### Resources - -- [Product Page](https://enginko.com/en/solutions/weather-station-lorawan-mcf-lwws00/) -- [Datasheet MCF-LWWS03](https://enginko.com/wp-content/uploads/2020/09/enginko%C2%AE_datasheet_MCF-LWWS00-01-02-03_EN013W01.pdf) -- [Installation Manual MCF-LWWS03](https://www.enginko.com/support/doku.php?id=manual_mcf-lwws0x) -- [Datasheet ISS Davis Vantage Pro2](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/6152_62_53_63_ss.pdf?v=1623783718) -- [Manual ISS Davis Vantage Pro2 Sensor Suite [6322C]](https://cdn.shopify.com/s/files/1/0515/5992/3873/files/07395-333_IM-6322C-6334.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- indoor temperature -- outdoor temperature -- relative humidity -- barometric pressure -- dew point -- wind speed -- wind direction -- rainfall -- PM (PM1, PM2.5, PM10) -- UV (optional) - -#### Dimensions: - -**Sensor Suite (ISS) with Standard Radiation Shield:** - -- width: 239 mm -- length: 356 mm -- height: 368 mm - -**Console with antenna:** - -- width: 156 mm -- length: 270 mm -- height: 41 mm - -#### Battery Sensor Suite: - -- primary power: solar power - Davis solar charger -- backup power: 1x CR123A (lithium) / 3 V / 1500 mAh (8 months without sunlight) - -### Note: - -- This version includes a pole kit. -- Sensor suite dimensions do not include the anemometer or bird spikes. - ---- diff --git a/docs/use-the-network/devices/ready-to-use/mclimate/aqi-sensor.mdx b/docs/use-the-network/devices/ready-to-use/mclimate/aqi-sensor.mdx deleted file mode 100644 index 313ddfe23..000000000 --- a/docs/use-the-network/devices/ready-to-use/mclimate/aqi-sensor.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -id: aqi-sensor -title: MClimate AQI Sensor and Notifier LoRaWAN -pagination_label: MClimate AQI Sensor and Notifier LoRaWAN -sidebar_label: MClimate AQI Sensor and Notifier LoRaWAN -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mclimate/aqi-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MClimate AQI Sensor and Notifier LoRaWAN - -The MClimate AQI Sensor and Notifier LoRaWAN is an indoor Air Quality Index Sensor and Notifier with -10+ years of battery life, configurable settings and a beautiful and discrete design. It is a 4-in-1 -sensor with gas, humidity, pressure and temperature measurements based on proven sensing principles -by Bosch. It measures AQI, VOCs (ppm), temperature, humidity and barometric pressure. It also has a -configurable buzzer and LED to notify tenants if the air quality Index is below a configurable -threshold. - - - -### Resources - -- [Product Page](https://mclimate.bit.ai/docs/view/S14D8XaQJGaz6cF4) -- [Datasheet](https://d2j4gdpjmxjmy3.cloudfront.net/v2/22667/contents/u7oVcekloCbQIcEz/MClimate-AQI_Sensor___Notifier-LoRaWAN-Datasheet-en.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- VOCs -- temperature -- humidity -- barometer - -#### Dimensions: - -- width: 80 mm -- length: 80 mm -- height: 19 mm - -#### Weight: - -- 68 grams - -#### Battery: - -- type: 2x AA / 3 V / recommended: Energizer Lithium Ultimate L91 -- replaceable: True - -#### Note: - -- End of Life (EOL) device. - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/mclimate/flood-sensor.mdx b/docs/use-the-network/devices/ready-to-use/mclimate/flood-sensor.mdx deleted file mode 100644 index 3bcb9a31f..000000000 --- a/docs/use-the-network/devices/ready-to-use/mclimate/flood-sensor.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: flood-sensor -title: MClimate Flood Sensor LoRaWAN -pagination_label: MClimate Flood Sensor LoRaWAN -sidebar_label: MClimate Flood Sensor LoRaWAN -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mclimate/flood-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MClimate Flood Sensor LoRaWAN - -MClimate Flood Sensor LoRaWAN is a compact flood sensor suitable for residential and commercial -applications. If a flood is detected, data is immediately transmitted. - - - -### Resources - -- [Product Page](https://mclimate.bit.ai/docs/view/q4EOcRGOsCzVblyc) -- [Datasheet](https://3008755228-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-McDr-jr9h3qA888r1Yp%2Fuploads%2FhmhYjSgOs3qV94Lf0icb%2FMClimate-Flood-Sensor-LoRaWAN-Datasheet-en.pdf?alt=media&token=1ef57a6a-625e-4b96-a6ce-dea8c02bcffc) -- [Manual](https://docs.mclimate.eu/mclimate-lorawan-devices/devices/mclimate-flood-sensor-lorawan) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- flood detection -- device tampering detection -- temperature - -#### Dimensions: - -- width: 70 mm -- length: 70 mm -- height: 19 mm - -#### Weight: - -- 33 grams - -#### Battery: - -- type: 1x CR123A (lithium) / 3 V / 1500 mAh -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/mclimate/ht-sensor.mdx b/docs/use-the-network/devices/ready-to-use/mclimate/ht-sensor.mdx deleted file mode 100644 index b13cfa1d4..000000000 --- a/docs/use-the-network/devices/ready-to-use/mclimate/ht-sensor.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: ht-sensor -title: MClimate HT Sensor LoRaWAN -pagination_label: MClimate HT Sensor LoRaWAN -sidebar_label: MClimate HT Sensor LoRaWAN -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mclimate/ht-sensor ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MClimate HT Sensor LoRaWAN - -The MClimate HT Sensor LoRaWAN is an indoor temperature and humidity sensor with 10+ years of -battery life, configurable settings and beautiful and discreet design. - - - -### Resources - -- [Product Page](https://mclimate.bit.ai/docs/view/fVqYnMSrbXBt3MZa) -- [Datasheet](https://3008755228-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-McDr-jr9h3qA888r1Yp%2Fuploads%2FuWtULrkAnkdqgLeWDsIu%2FMClimate-HT-Sensor-LoRaWAN-Batteries-Datasheet-en.pdf?alt=media&token=efb23d15-d43d-490b-b82a-c205131feb5c) -- [Manual](https://3008755228-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-McDr-jr9h3qA888r1Yp%2Fuploads%2F1DU7r6DxsEpkMmsttHuF%2FMClimate-HT-Sensor-LoRaWAN-User-Manual.pdf?alt=media&token=fc972daf-7c02-4d66-a88f-1a5c361c44ae) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity - -#### Dimensions: - -- width: 80 mm -- length: 80 mm -- height: 20 mm - -#### Weight: - -- 107 grams - -#### Battery: - -- type: 2x AA / 3 V / recommended: Energizer Lithium Ultimate L91 -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/mclimate/t-valve.mdx b/docs/use-the-network/devices/ready-to-use/mclimate/t-valve.mdx deleted file mode 100644 index 9d69421f1..000000000 --- a/docs/use-the-network/devices/ready-to-use/mclimate/t-valve.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: t-valve -title: MClimate T-Valve - Water Valve -pagination_label: MClimate T-Valve Water Valve -sidebar_label: MClimate T-Valve - Water Valve -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mclimate/t-valve ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MClimate T-Valve - Water valve - -MClimate T-Valve is a LoRaWAN water valve used in residential or commercial buildings. 3/4" and 1" -versions available, respectively DN20 and DN32, certified for drinking water. It also measures water -and environment temperature. It has multiple tamper protection mechanisms - tracking magnetic -interference and if the device is being physically abused. - - - -### Resources - -- [Product Page](https://mclimate.bit.ai/docs/view/qiyURo9OxshxDj1i) -- [Datasheet](https://3008755228-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-McDr-jr9h3qA888r1Yp%2Fuploads%2FoOu86UF0iS55izKH2B7r%2FMClimate-T-Valve-LoRaWAN-Datasheet-en.pdf?alt=media&token=749e02ef-5852-4b41-bbdb-744ea32797ea) -- [Manual](https://d2j4gdpjmxjmy3.cloudfront.net/v2/22667/contents/B0Ow5RQ90iIEziS8/T-Valve-LoRaWAN-Manual.pdf) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- water temperature -- ambient temperature -- wired flood (optional) -- housing tampering detection -- magnetic tampering detection - -#### Dimensions: - -- width: 105 mm -- length: 117 mm -- diameter: 98 mm - -#### Weight: - -- 600 grams - -#### Battery: - -- type: 1x ER26500 Lithium-thionyl Chloride (Li-SOCl2) / 3.6 V / 9000 mAh -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/mclimate/vicki.mdx b/docs/use-the-network/devices/ready-to-use/mclimate/vicki.mdx deleted file mode 100644 index b2d83dd21..000000000 --- a/docs/use-the-network/devices/ready-to-use/mclimate/vicki.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: vicki -title: MClimate Vicki - Smart Thermostatic Radiator Valve -pagination_label: MClimate Vicki - Smart Thermostatic Radiator Valve -sidebar_label: MClimate Vicki - Smart Thermostatic Radiator Valve -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/mclimate/vicki ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## MClimate Vicki - Smart Thermostatic Radiator Valve - -MClimate Vicki is a smart thermostatic radiator valve (TRV) retrofitting radiators with thermostatic -valve. It allows for temperature control and monitoring of temperature and humidity from a distance. -Manual target temperature selection is possible by rotating the outer ring of the device. The target -temperature is displayed on the device. - - - -### Resources - -- [Product Page](https://mclimate.bit.ai/docs/view/hynFRwdIvWYQg867) -- [Datasheet](https://3008755228-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-McDr-jr9h3qA888r1Yp%2Fuploads%2FWYaoSjY3vbDQJ2qNV7Is%2FMClimate-Vicki-LoRaWAN-Batteries-Datasheet-en.pdf?alt=media&token=6915529d-2ca6-4e1c-aa7a-50e4b3ba4d17) -- [Manual](https://d2j4gdpjmxjmy3.cloudfront.net/v2/22667/contents/Qg57y82hNtxrnQLQ/Vicki-LoRaWAN-Manual_2021.pdf) -- [Valves Compatibility List](https://d2j4gdpjmxjmy3.cloudfront.net/v2/22667/contents/ODPVSMj2uFSK9v9p/MClimate-Vicki-Valves-Compatibility-guide._pdf__compressed_.pdf) -- [Technical Webinar](https://www.youtube.com/watch?v=LtvFchshJIA) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- ambient temperature -- relative humidity - -#### Dimensions: - -- width: 54 mm -- length: 78 mm -- diameter: 50 mm - -#### Weight: - -- 107 grams - -#### Battery: - -- type: 2x AA / 3 V / recommended: Energizer Lithium Ultimate L91 -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/milesight-iot/am107.mdx b/docs/use-the-network/devices/ready-to-use/milesight-iot/am107.mdx deleted file mode 100644 index 0610aa969..000000000 --- a/docs/use-the-network/devices/ready-to-use/milesight-iot/am107.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -id: am107 -title: Milesight AM107 -pagination_label: Milesight AM107 -sidebar_label: Milesight AM107 Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/milesight-iot/am107 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Milesight AM107 Indoor Ambiance Sensor - -AM107 Indoor Ambience Sensor - -The AM107 is a compact indoor ambience sensor for measuring temperature, humidity, light, CO2 -concentration, TVOC, barometric pressure and motion. These data will be shown on the E-ink screen in -real-time, which allows for quantifying the indoor environment and comfort. The AM107 is widely used -for offices, stores, classrooms, hospitals, etc. - - - -### Resources - -- [Product Page](https://www.milesight-iot.com/lorawan/sensor/am100/) -- [Datasheet](https://resource.milesight-iot.com/milesight/document/am100-series-datasheet-en.pdf) -- [Manual](https://resource.milesight-iot.com/milesight/document/am100-series-user-guide-en.pdf) -- [Reseller - iot.sales@milesight.com](https://www.milesight-iot.com/contact-us/) -- [Video Tutorial](https://www.youtube.com/watch?v=lu90qeIkjC0&ab_channel=MilesightIoT) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- CO2 -- TVOC -- barometric pressure -- activity level (PIR) -- light -- battery - -#### Dimensions: - -- width: 21.2 mm -- length: 105 mm -- height: 70.4 mm - -#### Battery: - -- type: 2x AA alkaline (LR6) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/milesight-iot/em300-th.mdx b/docs/use-the-network/devices/ready-to-use/milesight-iot/em300-th.mdx deleted file mode 100644 index 08b17f679..000000000 --- a/docs/use-the-network/devices/ready-to-use/milesight-iot/em300-th.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: em300-th -title: Milesight EM300-TH -pagination_label: Milesight EM300-TH -sidebar_label: Milesight EM300-TH Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/milesight-iot/em300-th ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Milesight EM300-TH - -EM300-TH Temperature & Humidity Sensor - -The EM300-TH is a compact environment monitoring sensor for measuring temperature and humidity. It -transmits data by using LoRaWAN technology. The EM300-TH can work for up to 5 years with 4000 mAh -battery. The EM300-TH is widely used for both indoor and outdoor applications, such as offices, -hospitals, factories, greenhouses, etc. - - - -### Resources - -- [Product Page](https://www.milesight-iot.com/lorawan/sensor/em300-th/) -- [Datasheet](https://resource.milesight-iot.com/milesight/document/em300-th-datasheet-en.pdf) -- [Reseller - iot.sales@milesight.com](https://www.milesight-iot.com/contact-us/) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- battery - -#### Dimensions: - -- width: 85.3 mm -- length: 88.5 mm -- height: 27 mm - -#### Battery: - -- type: 1x ER18505 Lithium-thionyl chloride (Li-SOCl2) / 4000 mAh -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/milesight-iot/em500-co2.mdx b/docs/use-the-network/devices/ready-to-use/milesight-iot/em500-co2.mdx deleted file mode 100644 index ccee35abe..000000000 --- a/docs/use-the-network/devices/ready-to-use/milesight-iot/em500-co2.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: em500-co2 -title: Milesight EM500-CO2 -pagination_label: Milesight EM500-CO2 -sidebar_label: Milesight EM500-CO2 Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/milesight-iot/em500-co2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Milesight EM500-CO2 Carbon Dioxide Sensor (4 in 1) - -EM500-CO2 Carbon Dioxide Sensor (4 in 1) - -The EM500-CO2 is designed for measuring CO2, temperature, humidity and barometric pressure in harsh -environments and transmitting data by using LoRaWAN technology. With this low-power consumption -technology, the EM500-CO2 can work for up to 10 years with 19000 mAh battery. The EM500-CO2 is -widely used for applications like greenhouse, building ventilation, fruit and vegetable storage, -forest fire detection, etc. - - - -### Resources - -- [Product Page](https://www.milesight-iot.com/lorawan/sensor/em500-co2/) -- [Datasheet](https://resource.milesight-iot.com/milesight/document/em500-co2-datasheet-en.pdf) -- [Manual](https://resource.milesight-iot.com/milesight/document/em500-series-user-guide-en.pdf) -- [Reseller - iot.sales@milesight.com](https://www.milesight-iot.com/contact-us/) -- [Video introduction EM500-series](https://youtu.be/8XLDauJbVas) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- temperature -- humidity -- CO2 -- barometric pressure -- battery - -#### Dimensions: - -- width: 71 mm -- length: 147.9 mm -- height: 69.5 mm - -#### Battery: - -- type: 1x ER34615 Lithium-thionyl chloride (LI-SOCl2) / 3.6 V / 19000 mAh -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/milesight-iot/em500-udl.mdx b/docs/use-the-network/devices/ready-to-use/milesight-iot/em500-udl.mdx deleted file mode 100644 index 251baed93..000000000 --- a/docs/use-the-network/devices/ready-to-use/milesight-iot/em500-udl.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: em500-udl -title: Milesight EM500-UDL -pagination_label: Milesight EM500-UDL Sensor -sidebar_label: Milesight EM500-UDL Sensor -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/milesight-iot/em500-udl ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Milesight EM500-UDL Ultrasonic Distance/Level Sensor - -EM500-UDL Ultrasonic Distance/Level Sensor - -The EM500-UDL is designed for object distance or level detection in harsh environments and for -transmitting data using LoRaWAN technology. With this low-power consumption technology, the -EM500-UDL can work for up to 10 years with 19000 mAh battery. The EM500-UDL is widely used for -outdoor applications like snow level detection, flood monitoring, wastewater management, granary -level monitoring, etc. The measurement is based on ultrasonic waves transmitted and reflected from -nearby objects. - - - -### Resources - -- [Product Page](https://www.milesight-iot.com/lorawan/sensor/em500-udl/) -- [Datasheet](https://resource.milesight-iot.com/milesight/document/em500-udl-datasheet-en.pdf) -- [Manual](https://resource.milesight-iot.com/milesight/document/em500-series-user-guide-en.pdf) -- [Reseller - iot.sales@milesight.com](https://www.milesight-iot.com/contact-us/) -- [Video Introduction](https://youtu.be/01_4w6LDPX4) - -### Specifications - -#### LoRaWAN device type: - -- Class A end-device - -#### Sensors: - -- distance -- level -- battery - -#### Dimensions: - -- width: 71 mm -- length: 156.1 mm -- height: 69.5 mm - -#### Battery: - -- type: 1x ER34615 Lithium-thionyl chloride (LI-SOCl2) / 3.6 V / 19000 mAh -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/moko/lw001-bg.mdx b/docs/use-the-network/devices/ready-to-use/moko/lw001-bg.mdx deleted file mode 100644 index f2095130a..000000000 --- a/docs/use-the-network/devices/ready-to-use/moko/lw001-bg.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: lw001-bg -title: Lw001-Bg -pagination_label: Lw001 Bg -sidebar_label: Lw001-Bg -description: - LW001-BG is a wireless smart, ultra-low power consumption, indoor&outdoor（IP67） LoRaWAN Tracker. - Ideal to optimize logistic process, asset management, warehouse and inventory scenarios, outdoor - tracking, theft protection and much more. -image: img/use-the-network/devices/ready-to-use/moko/lw001-bg-1.png -slug: /use-the-network/devices/ready-to-use/moko/lw001-bg ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LW001-BG - -LW001-BG is a wireless smart, ultra-low power consumption, indoor&outdoor（IP67） LoRaWAN Tracker. -Ideal to optimize logistic process, asset management, warehouse and inventory scenarios, outdoor -tracking, theft protection and much more. - - - -### Resources - -- [Product Page](https://www.mokosmart.com/) - -### Specifications - -#### Sensors: - -- accelerometer -- temperature -- humidity -- gps -- barometer -- wifi ssid -- battery -- light - -#### Dimensions: - -- width: 122 mm -- length: 72.4 mm -- height: 32.7 mm - -#### Battery: - -- type: special -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/moko/lw003-b.mdx b/docs/use-the-network/devices/ready-to-use/moko/lw003-b.mdx deleted file mode 100644 index 40cae2f27..000000000 --- a/docs/use-the-network/devices/ready-to-use/moko/lw003-b.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: lw003-b -title: Lw003-B -pagination_label: Lw003 B -sidebar_label: Lw003-B -description: - LW003-B is a BLE-LoRaWAN gateway integrating LoRa and Bluetooth wireless communication, LW003-B - can scan BLE Beacon data and send data to LoRaWAN-Based gateway,and then upload to server, so as - to realize environmental monitoring and indoor positioning. -image: img/use-the-network/devices/ready-to-use/moko/lw003-b-1.png -slug: /use-the-network/devices/ready-to-use/moko/lw003-b ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LW003-B - -LW003-B is a BLE-LoRaWAN gateway integrating LoRa and Bluetooth wireless communication, LW003-B can -scan BLE Beacon data and send data to LoRaWAN-Based gateway,and then upload to server, so as to -realize environmental monitoring and indoor positioning. - - - -### Resources - -- [Product Page](https://www.mokosmart.com/lorawan-probe-lw003-b/) - -### Specifications - -#### Sensors: - -- battery -- button -- humidity -- light -- temperature -- time - -#### Dimensions: - -- width: 122.7 mm -- length: 109 mm -- height: 36 mm - -#### Weight: - -- 165 grams - -#### Battery: - -- type: lithium battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/moko/lw004.mdx b/docs/use-the-network/devices/ready-to-use/moko/lw004.mdx deleted file mode 100644 index 3711043f3..000000000 --- a/docs/use-the-network/devices/ready-to-use/moko/lw004.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: lw004 -title: Lw004 -pagination_label: Lw004 -sidebar_label: Lw004 -description: - LW004 is a LoRaWAN-Based network IoT device specifically designed for contact tracing purposes. It - is compact, small in size and easy to use. It can be used to track close contact,social safety - distance reminder, employee attendance, access control and identity identification. -image: img/use-the-network/devices/ready-to-use/moko/lw004.jpg -slug: /use-the-network/devices/ready-to-use/moko/lw004 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LW004 - -LW004 is a LoRaWAN-Based network IoT device specifically designed for contact tracing purposes. It -is compact, small in size and easy to use. It can be used to track close contact,social safety -distance reminder, employee attendance, access control and identity identification. - - - -### Resources - -- [Product Page](https://www.mokosmart.com/lw004-lorawan-contact-tracing-wearables-button/) - -### Specifications - -#### Sensors: - -- accelerometer -- battery -- button -- gps -- light -- vibration - -#### Dimensions: - -- width: 73 mm -- length: 40 mm -- height: 17 mm - -#### Weight: - -- 48 grams - -#### Battery: - -- type: lithium battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/moko/lw005-mp.mdx b/docs/use-the-network/devices/ready-to-use/moko/lw005-mp.mdx deleted file mode 100644 index cb7b921e4..000000000 --- a/docs/use-the-network/devices/ready-to-use/moko/lw005-mp.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: lw005-mp -title: Lw005 -pagination_label: Lw005 Mp -sidebar_label: Lw005 -description: - LW005 is a compact, multi-purposes, easy-to -use, wireless LoRaWAN power meter for indoor use. It - can remotely control the output switch and detect the output power. -image: img/use-the-network/devices/ready-to-use/moko/lw005.jpg -slug: /use-the-network/devices/ready-to-use/moko/lw005-mp ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LW005 - -LW005 is a compact, multi-purposes, easy-to -use, wireless LoRaWAN power meter for indoor use. It -can remotely control the output switch and detect the output power. - - - -### Resources - -- [Product Page](https://www.mokosmart.com/) - -### Specifications - -#### Sensors: - -- current -- power -- voltage - -#### Dimensions: - -- width: 61 mm -- length: 104 mm -- height: 34 mm - -#### Weight: - -- 136 grams - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r311a.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r311a.mdx deleted file mode 100644 index f11d75091..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r311a.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: r311a -title: Wireless Window Sensor -pagination_label: R311A -sidebar_label: Wireless Window Sensor -description: - When the window is opened, R311A sends an alarm message to the control center. R311A utilizes the - latest ultra-low power consumption technology and requires no wiring. It requires just button - batteries to support its operation. -image: img/use-the-network/devices/ready-to-use/netvox/photos/r311a.jpg -slug: /use-the-network/devices/ready-to-use/netvox/r311a ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Window Sensor - -When the window is opened, R311A sends an alarm message to the control center. R311A utilizes the -latest ultra-low power consumption technology and requires no wiring. It requires just button -batteries to support its operation. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R311A) -- [Datasheet](http://www.netvox.com.tw/um/R311A/R311Adatasheet.pdf) - -### Specifications - -#### Dimensions: - -- width: 35 mm -- length: 57 mm -- height: 15 mm - -#### Weight: - -- 43.8 grams - -#### Battery: - -- type: 2 x 3.0V CR2450 button battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r311b.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r311b.mdx deleted file mode 100644 index 661d1d34b..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r311b.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: r311b -title: Wireless Light Sensor -pagination_label: R311B -sidebar_label: Wireless Light Sensor -description: - The R311B device has a built-in Wireless Light Sensor that can be used for ambient light intensity - detection. -image: img/use-the-network/devices/ready-to-use/netvox/photos/r311b.jpg -slug: /use-the-network/devices/ready-to-use/netvox/r311b ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Light Sensor - -The R311B device has a built-in Wireless Light Sensor that can be used for ambient light intensity -detection. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R311B) -- [Datasheet](http://www.netvox.com.tw/um/R311B/R311Bdatasheet.pdf) - -### Specifications - -#### Sensors: - -- light - -#### Dimensions: - -- width: 35 mm -- length: 57 mm -- height: 15.2 mm - -#### Weight: - -- 45 grams - -#### Battery: - -- type: 2 x 3.0V CR2450 button batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r311g.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r311g.mdx deleted file mode 100644 index 2ad8a95b7..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r311g.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: r311g -title: Wireless Light Sensor -pagination_label: R311G -sidebar_label: Wireless Light Sensor -description: - R311G built-in photosensitive sensor, can be used for external ambient light intensity - detection.R311G is the environmental illuminance automatic detector and the reporter which can - send out the environmental illumination report and is a low-power, long range, wireless sensor - that can accurately detect environmental illuminance indoor. -image: img/use-the-network/devices/ready-to-use/netvox/photos/r311g.jpg -slug: /use-the-network/devices/ready-to-use/netvox/r311g ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Light Sensor - -R311G built-in photosensitive sensor, can be used for external ambient light intensity -detection.R311G is the environmental illuminance automatic detector and the reporter which can send -out the environmental illumination report and is a low-power, long range, wireless sensor that can -accurately detect environmental illuminance indoor. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R311G) -- [Datasheet](http://www.netvox.com.tw/um/R311G/R311Gdatasheet.pdf) - -### Specifications - -#### Sensors: - -- light - -#### Dimensions: - -- width: 35 mm -- length: 57 mm -- height: 15.2 mm - -#### Weight: - -- 32.3 grams - -#### Battery: - -- type: 2 x 3.0V CR2450 button batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r311w.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r311w.mdx deleted file mode 100644 index d8121f517..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r311w.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: r311w -title: Wireless Water Leak Sensor -pagination_label: R311W -sidebar_label: Wireless Water Leak Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r311w ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Water leak Sensor - -Netvox R311W is a water leak sensor based on LoRaWAN™ protocol (ClassA) carrying leak detection and -alarm function. When R311W detects a leak, it will send an alarm message to the gateway. When the -sensor detects no leak, it will send a message that reports the status to the gateway. There are two -water leak sensors which allow users to monitor two spots. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R311W) -- [Datasheet](http://www.netvox.com.tw/um/R311W/R311Wdatasheet.pdf) - -### Specifications - -#### Sensors: - -- water - -#### Dimensions: - -- width: 35 mm -- length: 57 mm -- height: 15.2 mm - -#### Weight: - -- 48.9 grams - -#### Battery: - -- type: 2 x 3.0V CR2450 button batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r312.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r312.mdx deleted file mode 100644 index 8ee8a7b10..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r312.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: r312 -title: Wireless Door Bell Button -pagination_label: R312 -sidebar_label: Wireless Door Bell Button -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r312 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Door Bell Button - -R312 is a wireless doorbell control device which can detect whether the wireless doorbell is -triggered and send the doorbell status to the gateway. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R312) -- [Datasheet](http://www.netvox.com.tw/um/R312/R312datasheet.pdf) - -### Specifications - -#### Sensors: - -- button - -#### Dimensions: - -- width: 35 mm -- length: 57 mm -- height: 15.2 mm - -#### Weight: - -- 45 grams - -#### Battery: - -- type: 2 x 3.0V CR2450 button battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r312a.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r312a.mdx deleted file mode 100644 index 918b7ab6e..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r312a.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: r312a -title: Wireless Emergency Button -pagination_label: R312A -sidebar_label: Wireless Emergency Button -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r312a ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Emergency Button - -The R312A is an emergency button switch device that detects the closing or opening signal of the -emergency button switch and sends an alarm signal to the gateway for processing. It uses the SX1276 -wireless communication module. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R312A) -- [Datasheet](http://www.netvox.com.tw/um/R312A/R312Adatasheet.pdf) - -### Specifications - -#### Sensors: - -- button - -#### Dimensions: - -- width: 35 mm -- length: 57 mm -- height: 15.2 mm - -#### Weight: - -- 45 grams - -#### Battery: - -- type: 2 x 3.0V CR2450 button battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r711.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r711.mdx deleted file mode 100644 index 656721aa3..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r711.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: r711 -title: Wireless Temperature And Humidity Sensor -pagination_label: R711 -sidebar_label: Wireless Temperature And Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r711 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Temperature and Humidity Sensor - -R711 is mainly used to detect the temperature and humidity of indoor air. It transmits the collected -data to other devices for display through the wireless network communication module. The device -conforms to the LoRa protocol standard. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R711) -- [Datasheet](http://www.netvox.com.tw/um/R711/R711datasheet.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity - -#### Dimensions: - -- width: 34.2 mm -- length: 108.5 mm -- height: 19 mm - -#### Weight: - -- 83.8 grams - -#### Battery: - -- type: 2 x 1.5V AA alkaline battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718a.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718a.mdx deleted file mode 100644 index a413d201f..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718a.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: r718a -title: Temperature And Humidity Sensor For Low Temperature Environment -pagination_label: R718A -sidebar_label: Temperature And Humidity Sensor For Low Temperature Environment -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718a ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Temperature and Humidity Sensor for Low Temperature Environment - -R718A is capable to measure temperature and humidity at low temperature environment. R718A can be -used in domestic and commercial refrigerators to store and transport food, medicines, flowers and -other perishable goods, on the walls or in logistics refrigerators. Suitable as a data logger. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718A) -- [Datasheet](http://www.netvox.com.tw/um/R718A/R718Adatasheet.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity - -#### Dimensions: - -- width: 65 mm -- length: 112 mm -- height: 28 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: ER14505 AA Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718ab.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718ab.mdx deleted file mode 100644 index 0c9474982..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718ab.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: r718ab -title: Wireless Temperature And Humidity Sensor -pagination_label: R718Ab -sidebar_label: Wireless Temperature And Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718ab ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Temperature and Humidity Sensor - -R718AB is a wireless communication device that detects ambient air temperature and humidity. R718AB -can detect the temperature and humidity of the air and transmit the detected data to data center -through the wireless network. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718AB) -- [Datasheet](http://www.netvox.com.tw/um/R718AB/R718ABdatasheet.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity - -#### Dimensions: - -- width: 65 mm -- length: 112 mm -- height: 28 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: ER14505 AA Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718b.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718b.mdx deleted file mode 100644 index f3fc5d62b..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718b.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: r718b -title: Wireless Resistance Temperature Detector -pagination_label: R718B -sidebar_label: Wireless Resistance Temperature Detector -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718b ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Resistance Temperature Detector - -R718B connects an external resistance temperature detector (PT1000) to measures the temperature. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718B) -- [Datasheet](http://www.netvox.com.tw/um/R718B/R718Bdatasheet.pdf) - -### Specifications - -#### Sensors: - -- temperature - -#### Dimensions: - -- width: 88.19 mm -- length: 112 mm -- height: 32 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: 2 x 3.6V ER14505 AA lithium battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718ck.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718ck.mdx deleted file mode 100644 index 51f7d6512..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718ck.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: r718ck -title: Wireless Thermocouple Sensor -pagination_label: R718Ck -sidebar_label: Wireless Thermocouple Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718ck ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Thermocouple Sensor - -This equipment is used to detect temperature of the object and medium which thermocouple is -contacted. The detecting range of R718CK is -40 °C~ +375°C. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718CK) -- [Datasheet](http://www.netvox.com.tw/um/R718CK/R718CKdatasheet.pdf) - -### Specifications - -#### Sensors: - -- temperature - -#### Dimensions: - -- width: 88.19 mm -- length: 112 mm -- height: 32 mm - -#### Battery: - -- type: 2 x 3.6V ER14505 AA lithium battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718ct.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718ct.mdx deleted file mode 100644 index 5b534620a..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718ct.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: r718ct -title: Wireless Thermocouple Sensor -pagination_label: R718Ct -sidebar_label: Wireless Thermocouple Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718ct ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Thermocouple Sensor - -This equipment is used to detect temperature of the object and medium which thermocouple is -contacted. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718CT) -- [Datasheet](http://www.netvox.com.tw/um/R718CT/R718CTdatasheet.pdf) - -### Specifications - -#### Sensors: - -- temperature - -#### Dimensions: - -- width: 88.19 mm -- length: 112 mm -- height: 32 mm - -#### Battery: - -- type: 2 x 3.6V ER14505 AA lithium battery -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718e.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718e.mdx deleted file mode 100644 index 3b85b2109..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718e.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: r718e -title: Three-Axis Digital Accelerometer&Ntc Thermistor -pagination_label: R718E -sidebar_label: Three-Axis Digital Accelerometer&Ntc Thermistor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718e ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Three-Axis Digital Accelerometer&NTC Thermistor - -It can detect the movement or vibration of the device, send a signal to the gateway for processing, -and externally connect one NTC thermistor to detect the surface temperature of the measured object. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718E) -- [Datasheet](http://www.netvox.com.tw/um/R718E/R718Edatasheet.pdf) - -### Specifications - -#### Sensors: - -- accelerometer -- velocity -- temperature - -#### Dimensions: - -- width: 88.19 mm -- length: 112 mm -- height: 32 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: 2 x 3.6V ER14505 AA lithium batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718f.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718f.mdx deleted file mode 100644 index b3867154b..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718f.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: r718f -title: Wireless Reed Switch Open/Close Detection Sensor -pagination_label: R718F -sidebar_label: Wireless Reed Switch Open/Close Detection Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718f ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Reed Switch Open/Close Detection Sensor - -R718F utilizes a reed switch to detect whether two objects are separated or not. An example of -R718F’s application is to detect the state of a door or window for security purposes. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718F) -- [Datasheet](http://www.netvox.com.tw/um/R718F/R718Fdatasheet.pdf) - -### Specifications - -#### Dimensions: - -- width: 65 mm -- length: 112 mm -- height: 32 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: 2 x 3.6V ER14505 AA lithium batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718n1.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718n1.mdx deleted file mode 100644 index 73b515eeb..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718n1.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: r718n1 -title: Wireless 1-Phase Current Meter With 1 X 30A Solid Core Ct -pagination_label: R718N1 -sidebar_label: Wireless 1-Phase Current Meter With 1 X 30A Solid Core Ct -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718n1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless 1-Phase Current Meter with 1 x 30A Solid Core CT - -R718N1 is powered by battery and obtains the load AC current value through the current transformer. -The device adopts the solid-core current transformer, which can be conveniently connected to the -measuring device. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718N1) -- [Datasheet](http://www.netvox.com.tw/um/R718N1/R718N1datasheet.pdf) - -### Specifications - -#### Sensors: - -- current - -#### Dimensions: - -- width: 88.19 mm -- length: 112 mm -- height: 32 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: 2 x 3.6V ER14505 lithium batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718n3.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718n3.mdx deleted file mode 100644 index edb4956af..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718n3.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: r718n3 -title: Wireless 3-Phase Current Meter With 3 X 50A Solid Core Ct -pagination_label: R718N3 -sidebar_label: Wireless 3-Phase Current Meter With 3 X 50A Solid Core Ct -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718n3 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless 3-Phase Current Meter With 3 x 50A Solid Core CT - -R718N3 is powered by battery and obtains the load AC current value through the current transformer. -The device adopts the solid core current transformer, which can be conveniently connected to the -measuring device. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718N3) -- [Datasheet](http://www.netvox.com.tw/um/R718N3/R718N3datasheet.pdf) - -### Specifications - -#### Sensors: - -- current - -#### Dimensions: - -- width: 88.19 mm -- length: 112 mm -- height: 32 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: 2 x 3.6V ER14505 lithium batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r718t.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r718t.mdx deleted file mode 100644 index 8890bf6b8..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r718t.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: r718t -title: Wireless Push Button Interface -pagination_label: R718T -sidebar_label: Wireless Push Button Interface -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r718t ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Push Button Interface - -The device is connected to an external push button device (2 lines are connected to the 2 end of the -push button) that can detect the signal when the button is pushed. It uses SX1276 wireless -communication module, and the communication is fully compatible with LoRaWAN™ protocol (Class A). - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R718T) -- [Datasheet](http://www.netvox.com.tw/um/R718T/R718Tdatasheet.pdf) - -### Specifications - -#### Sensors: - -- digital input - -#### Dimensions: - -- width: 65 mm -- length: 112 mm -- height: 32 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: 2 x 3.6V ER14505 AA lithium batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r720a.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r720a.mdx deleted file mode 100644 index 3b037602a..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r720a.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: r720a -title: Temperature And Humidity Sensor -pagination_label: R720A -sidebar_label: Temperature And Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r720a ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Temperature and Humidity Sensor - -The R720A is a wireless communication device that detects ambient air temperature and humidity. The -R720A detects the temperature and humidity of the air and transmits the detected data to other -devices via a wireless network using the SX1276 wireless communication module. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R720A) -- [Datasheet](http://www.netvox.com.tw/um/R720A/R720Adatasheet.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity - -#### Dimensions: - -- width: 65 mm -- length: 88 mm -- height: 19 mm - -#### Weight: - -- 113 grams - -#### Battery: - -- type: ER14505 AA Lithium -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r72615.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r72615.mdx deleted file mode 100644 index d4518e1a7..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r72615.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: r72615 -title: Wireless Outdoor Co2/Temperature/Humidity Sensor With Solar Panel -pagination_label: R72615 -sidebar_label: Wireless Outdoor Co2/Temperature/Humidity Sensor With Solar Panel -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r72615 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Outdoor CO2/Temperature/Humidity Sensor with Solar Panel - -The R72615 is equipped with a temperature and humidity sensor that detects and transmits ambient -temperature and humidity data. It is a wireless communication method that uses the SX1276 wireless -communication module. The R72615 has a CO2 sensor that detects the concentration of CO2 in the air. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R72615) -- [Datasheet](http://www.netvox.com.tw/um/R72615/R72615datasheet.pdf) - -### Specifications - -#### Sensors: - -- co2 -- temperature -- humidity - -#### Dimensions: - -- height: 340 mm - -#### Battery: - -- type: solar and rechargeable lithium batteries - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/r72615a.mdx b/docs/use-the-network/devices/ready-to-use/netvox/r72615a.mdx deleted file mode 100644 index 8afa7368e..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/r72615a.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: r72615a -title: Wireless Co2/Temperature/Humidity Sensor -pagination_label: R72615A -sidebar_label: Wireless Co2/Temperature/Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/r72615a ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless CO2/Temperature/Humidity Sensor - -R72615A has a temperature and humidity sensor that detects and transmits ambient temperature and -humidity data. It applies wireless communication method that uses the SX1276 wireless communication -module. The R72615A has a CO2 sensor that detects the concentration of CO2 in the air. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=R72615A) -- [Datasheet](http://www.netvox.com.tw/um/R72615A/R72615Adatasheet.pdf) - -### Specifications - -#### Sensors: - -- co2 -- temperature -- humidity - -#### Dimensions: - -- width: 89.05 mm -- length: 117 mm -- height: 82 mm - -#### Battery: - -- type: 8 ER14505 lithium batteries - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/ra0715.mdx b/docs/use-the-network/devices/ready-to-use/netvox/ra0715.mdx deleted file mode 100644 index 7d17b1607..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/ra0715.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: ra0715 -title: Wireless Co2/Temperature/Humidity Sensor -pagination_label: Ra0715 -sidebar_label: Wireless Co2/Temperature/Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/ra0715 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless CO2/Temperature/Humidity Sensor - -RA0715 is equipped with RA0715. It can monitor the ambient temperature and humidity and send the -data via wireless method that adopts SX1276 wireless communication module. RA0715 is equipped with -CO2 sensor that can detect the concentration of CO2 in the air. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=RA0715) -- [Datasheet](http://www.netvox.com.tw/um/RA0715/RA0715datasheet.pdf) - -### Specifications - -#### Sensors: - -- co2 -- temperature -- humidity - -#### Dimensions: - -- width: 86 mm -- length: 111 mm -- height: 41 mm - -#### Weight: - -- 141 grams - -#### Battery: - -- type: DC 12V adapters - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/ra0715y.mdx b/docs/use-the-network/devices/ready-to-use/netvox/ra0715y.mdx deleted file mode 100644 index 1a637da8e..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/ra0715y.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -id: ra0715y -title: Wireless Outdoor Co2/Temperature/Humidity Sensor -pagination_label: Ra0715Y -sidebar_label: Wireless Outdoor Co2/Temperature/Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/ra0715y ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Outdoor CO2/Temperature/Humidity Sensor - -The device is a LoRaWAN™ device compatible with LoRaWAN™ protocol (Class A). RA0715Y Wireless -Outdoor CO2/Temperature/Humidity Sensor - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=RA0715Y) -- [Datasheet](http://www.netvox.com.tw/um/RA0715Y/RA0715Ydatasheet.pdf) - -### Specifications - -#### Sensors: - -- co2 -- temperature -- humidity - -#### Dimensions: - -- height: 180 mm - -#### Battery: - -- type: DC 12V adapters - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/rb02i.mdx b/docs/use-the-network/devices/ready-to-use/netvox/rb02i.mdx deleted file mode 100644 index 0062742a4..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/rb02i.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -id: rb02i -title: Wireless Emergency Push Button -pagination_label: Rb02I -sidebar_label: Wireless Emergency Push Button -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/rb02i ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Emergency Push Button - -The RB02I product is a wireless control terminal device for smart homes and high reliability. It -features low standby power consumption and is fully compliant with the LoRaWAN™ protocol standard. -RB02I is an emergency alarm triggering device, with a silicone waterproof cover. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=RB02I) -- [Datasheet](http://www.netvox.com.tw/um/RB02I/RB02Idatasheet.pdf) - -### Specifications - -#### Sensors: - -- button - -#### Dimensions: - -- width: 82 mm -- length: 82 mm -- height: 15 mm - -#### Battery: - -- type: 2 sections AAA batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/netvox/rb11e.mdx b/docs/use-the-network/devices/ready-to-use/netvox/rb11e.mdx deleted file mode 100644 index 24a1baac4..000000000 --- a/docs/use-the-network/devices/ready-to-use/netvox/rb11e.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: rb11e -title: Wireless Occupancy/Temperature/Light Sensor -pagination_label: Rb11E -sidebar_label: Wireless Occupancy/Temperature/Light Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/netvox/rb11e ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Wireless Occupancy/Temperature/Light Sensor - -RB11E is a Wireless Occupancy/Light/Temperature Sensor for Netvox ClassA type devices based on the -LoRaWAN open protocol and is compatible with the LoRaWAN protocol. It combines occupancy -,temperature, tamper switch and light sensors that suitable for detecting human movement indoors, -illuminance and temperature. - - - -### Resources - -- [Product Page](http://www.netvox.com.tw/product.asp?pro=RB11E) -- [Datasheet](http://www.netvox.com.tw/um/RB11E/RB11Edatasheet.pdf) - -### Specifications - -#### Sensors: - -- light -- temperature - -#### Dimensions: - -- width: 78 mm -- length: 78.8 mm -- height: 82.2 mm - -#### Weight: - -- 125.8 grams - -#### Battery: - -- type: 2 x 3.6V ER14505 AA lithium batteries -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/nwave/nps310sm.mdx b/docs/use-the-network/devices/ready-to-use/nwave/nps310sm.mdx deleted file mode 100644 index 37bf7f935..000000000 --- a/docs/use-the-network/devices/ready-to-use/nwave/nps310sm.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -id: nps310sm -title: Smart Parking Sensor -pagination_label: Nps310Sm -sidebar_label: Smart Parking Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/nwave/nps310sm ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Smart Parking Sensor - -The wireless vehicle detection sensor with high detection accuracy at 99.7%, fast detection time at -3-5 seconds, low profile - 20mm, 10 years battery life @20 parking sessions a day and vehicle -counting capabilities. - - - -### Resources - -- [Product Page](https://www.nwave.io/smart-parking-sensor/) - -### Specifications - -#### Sensors: - -- magnetometer -- temperature -- proximity - -#### Dimensions: - -- height: 20 mm - -#### Weight: - -- 460 grams - -#### Battery: - -- type: AA 13,500mAh Li-SOCI2 -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/origo/lorawan-watch.mdx b/docs/use-the-network/devices/ready-to-use/origo/lorawan-watch.mdx deleted file mode 100644 index adc395472..000000000 --- a/docs/use-the-network/devices/ready-to-use/origo/lorawan-watch.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: lorawan-watch -title: LoRaWAN Watch Ed20W -pagination_label: LoRaWAN Watch -sidebar_label: LoRaWAN Watch -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/origo/lorawan-watch ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## LoRaWAN Watch ED20W - -Smart watch for Lone worker, Oil&Gas industrial, Mining, Energy and utilities, Real estate and -construction, Manufacturing industrial, Transportation and logistics. - - - -### Resources - -- [ED20W LoRa GPS watch datasheet](http://www.origoelec.com/End-Devices/ED20W-datasheet.pdf) - -- [ED20W Payload](http://www.origoelec.com/End-Devices/ED20W-protocol-payload.pdf) - -### Features - -- Connectivity via LoRa -- Class type: Class A -- GNSS+Bluetooth (optional) positioning -- Tracking your daily activity：Heart rate, step and sleep monitor. -- SOS for cloud platform management - -### Specification - -- Modem: ISM Band LoRa® -- Frequency: EU868MHz，US915MHz，AS923MHz -- Class Type: Class A -- Positioning: Build in GNSS, Bluetooth (optional) and accelerometer -- Display: 240\*240 TFT Display -- Rubber strap: 22mm standard size -- Buttons: Two function buttons -- Battery capacity: Polymer battery，400mAh， 3.8V -- Charging: Magnetic charging cable -- Enclosure: IP65 -- Electronic tags: Support RFID (NFC Tag and M1 card) (for payment, public transportation, access - control, etc.) (not equipped by default) -- Health data: Heart rate, blood pressure, pedometer, sleep detection -- Alarm: SOS alarm，Low power alarm -- Operation temperature: 0~60℃ -- Operation humidity: 10%～ 90%，Non-condensing -- Dimensions: TYP. 48*52*14.5mm (W*L*H) -- Weight: 50g diff --git a/docs/use-the-network/devices/ready-to-use/origo/smart-badges.mdx b/docs/use-the-network/devices/ready-to-use/origo/smart-badges.mdx deleted file mode 100644 index c352939d2..000000000 --- a/docs/use-the-network/devices/ready-to-use/origo/smart-badges.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -id: smart-badges -title: Smart Badges Ed210 -pagination_label: Smart Badges -sidebar_label: Smart Badges -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/origo/smart-badges ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Smart Badges ED210 - -ED210 is an intelligent GPS tracker based on LORAWAN network transmission. It supports GNSS outdoor -positioning and Bluetooth 4.0 indoor positioning. The positioning accuracy is 10 meters outdoor and -3~5 meters indoor. Through the intelligent tracker, beacons, LoRaWAN gateway and platform, it can -realize the real-time positioning of staff and visitors. Help enterprises and institutions achieve -personnel management and safe production. - - - -### Resources - -- [ED210 Smart Badges datasheet](http://www.origoelec.com/End-Devices/ED210-Smart-badge-datasheet.pdf) - -- [ED210 Payload](http://www.origoelec.com/End-Devices/ED210-Payload-LoRa-staff-badges.pdf) - -### Features - -- Indoor & Outdoor real-time positioning -- Build in NFC, RFID(Opt.) -- SOS in emergency: Press the positioning button to relocate your position and send to the platform -- External personnel management -- Support OEM for Bulk order - -### Specification - -- Communication: Build in LoRa modul -- Frequency: EU868MHz/US915MHz -- Communication Range: 1KM in dense urban, 3~5KM line-off-site -- Bluetooth: Building in Bluetooth -- Positioning: Outdoor GPS positioning and indoor Bluetooth positioning -- Positioning accuracy: 10 meters (outdoor) 3-5 meters (indoor) -- Gyro: Build in gyro , Supports power saving mode in non-motion state -- Battery: Rechargeable 900mah lithium battery -- Charging port: Type-C -- Buttons: 1-SOS button 2-Power button -- Enclosure: IP66 -- Battery life: More than 40hours（GNSS positioning interval 5mins） -- Dimensions: 86.5*55*8mm -- NFC: Support 1~15CM detect range(Optional) -- Time sync: Time synchronization with GPS -- LED indicator: Three color LED indicator -- Operation temperature: -20℃~60℃ -- Uplink frequency: customized -- Positioning time: Cold start 38S hot start 1S Recapture <1S -- Charging voltage: 5V diff --git a/docs/use-the-network/devices/ready-to-use/rakwireless/rak10700.mdx b/docs/use-the-network/devices/ready-to-use/rakwireless/rak10700.mdx deleted file mode 100644 index b8cabe654..000000000 --- a/docs/use-the-network/devices/ready-to-use/rakwireless/rak10700.mdx +++ /dev/null @@ -1,223 +0,0 @@ ---- -id: rak10700 -title: Rak10700 Wisblock Gnss Tracker For LoRaWAN -pagination_label: Rak10700 -sidebar_label: Rak10700 Wisblock Gnss Tracker For LoRaWAN -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/rakwireless/rak10700 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Overview - -The RAK10700 WisBlock GNSS Tracker for LoRaWAN is an LPWAN Tracker device with a GNSS modem. It is -built with the WisBlock modules providing LPWAN and BLE communication using the nRF52 MCU and SX1262 -LoRa transceiver of the RAK4631 Core module. It includes the RAK12500 GNSS location module with the -u-blox ZOE-M8Q chip, the RAK1906 environment sensor with the Bosch BME680 sensor, and the RAK1904 -with an ST LIS3DH 3-axis acceleration sensor. - -It is a feature-packed tracker device for featured applications development. It can also be used as -a quick prototyping tool for Internet-of-Things (IoT) and LoRaWAN Integration. Moreover, this LPWAN -Tracker is perfect for IoT applications such as asset tracking, smart vehicle management, and -location-based services. - -### Product Features - -- Supports sleep mode and low-power consumption. -- Built-in **LIS3DH - digital motion sensor**, which has dynamic user selectable full scales of - ±2g/±4g/±8g/±18g and is capable of measuring accelerations with output data rates from 1 Hz to - 5 kHz. -- Environment sensor: Built-in **Bosch BME680 air quality sensor**. -- GNSS location sensor: **u-blox ZOE-M8Q**. -- LoRaWAN 1.0.2 Standard support - ABP or OTAA mode. -- LoRa P2P support. -- LoRa, BLE, and GPS antenna are integrated inside the casing. -- Micro USB for configuration and charging of the battery. -- Supports global license-free frequency band: RU864, IN865, EU868, RU864, US915, AU915, KR920, and - AS923. - -### Useful Resources - -- [Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK10700/Quickstart/) -- [Datasheet](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK10700/Datasheet/) -- [AT Command Manual](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK10700/AT-Command-Manual/) -- [Store: RAK10700 WisBlock GNSS Tracker for LoRaWAN](https://store.rakwireless.com/products/lpwan-tracker-solution-kit?utm_source=RAK10700&utm_medium=Document&utm_campaign=BuyFromStore) - -## Connecting to Helium (The People's Network) - -:::tip Before going through each and every step in Connecting the RAK10700 to Helium, it is -recommended to check first our -[Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK10700/Quickstart/). -::: - -Helium has quickly become the most widespread LPWAN communal network, with more than 400,000 -hotspots deployed globally at the beginning of 2021. All the RAKwireless node products are -compatible with it, and the process of adding a device to the network is intuitive and -straightforward. - -This guide focuses on connecting the GNSS Tracker to the network console, assuming that there is a -Helium Hotspot within range. - -Log in or create your account [here](https://www.helium.com/console). - - - -Once registered/logged in, you will end up at the home page, where you can see your function tree on -the left and DC balance at the top, as well as a number of useful links. - - - -Go to the **Devices** section in the function tree. There will be no registered devices if this is -your first time doing this. To add a device, click the **+ Add Device** button and get started. - - - -A window will pop up with a set of fields containing the device parameters required for its -registration. - - - -Fill in a name of your choosing. The **Dev EUI**, **App EUI**, and **App Key** will have random -values generated for you by default. Press the eye icon to reveal the values. You can manually -replace them with values of your own. For this tutorial, default values are used. Press the -**Submit** button, and you are done. - - - -To check the decoded values in the Helium Console, you need to create a **Flow** that decodes the -data. - -- First, go to **Functions** in the Helium Console and create a new function. For the name, you can - choose anything. The function type needs to be **Decoder**. For the format, choose **Cayenne - LPP**. - - - -- Next, go to **Flows** in the Helium Console and create a new flow. Connect your device to the flow - that you just created. - - - -Now, your RAK10700 is registered and is awaiting activation. For this to happen, import the **Dev -EUI**, **App EUI**, and **App Key** in the RAK10700 using the -[RAK Serial Port Tool](https://downloads.rakwireless.com/en/LoRa/Tools/RAK_SERIAL_PORT_TOOL_V1.2.1.zip). - -Open the tool, select the desired port (default baud rate) and open it. Then start importing your -settings. - -Configure your LoRa band and activation mode. This tutorial will be using the EU868 band and OTAA -(the only option available for now with Helium) with device class A (the default one does not need -configuring). - -:::info - -The different regions are selected by number: - -- 0: AS923 -- 1: AU915 -- 2: CN470 -- 3: CN779 -- 4: EU433 -- 5: EU868 -- 6: KR920 -- 7: IN865 -- 8: US915 -- 9: AS923-2 -- 10: AS923-3 -- 11: AS923-4 -- 12: RU864 - -::: - -- Regional band and activation mode setting - -``` -AT+NJM=1 -``` - -``` -AT+BAND=10 -``` - -- Enter the Dev UI - -Use the command below by replacing the XXXX with your Device EUI from the Helium console: - -``` -AT+DEVEUI=XXXX -``` - -- Enter the App EUI - -Update the APPEUI value of your LPWAN tracker by replacing the XXXX with the APPEUI value you get -from the Helium Console - -``` -AT+APPEUI=XXXX -``` - -- Enter App Key - -You also need to update the APPKEY by getting the 16-byte APPKEY from the Helium Console: - -``` -AT+APPKEY=XXXX -``` - -- Join Network - -Finish executing the join command for the node to initiate the join procedure. - -``` -AT+JOIN=1:0:8:30 -``` - -Once the procedure is initiated and completed, you will have a notification in the serial console. - - - -If you take a look at the Helium console, you will also see the join request packets both in the -graph and event log. Your node is now a part of the Helium Network. - - - -If your GNSS Tracker can get a location fix, you can see the live data in the Helium Console Debug -window. - - diff --git a/docs/use-the-network/devices/ready-to-use/rakwireless/rak2171.mdx b/docs/use-the-network/devices/ready-to-use/rakwireless/rak2171.mdx deleted file mode 100644 index 1fd3191aa..000000000 --- a/docs/use-the-network/devices/ready-to-use/rakwireless/rak2171.mdx +++ /dev/null @@ -1,263 +0,0 @@ ---- -id: rak2171 -title: Rak2171 Wisnode Trackit -pagination_label: Rak2171 -sidebar_label: Rak2171 Wisnode Trackit -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/rakwireless/rak2171 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Overview - -RAK2171 WisNode TrackIt is a LoRaWAN GPS tracking device. It comes in a small form factor with a -rechargeable battery and tracking and configuration application. Its application is available for -iOS and Android devices. - -RAK2171 supports multiple working modes and notification options. When used with RAK WisGate Edge -Gateways and P2P mode, you can monitor your tracker on the application map, create geofences, and -receive SOS and movement notifications. You can also configure the WisNode TrackIt to work with any -third-party LoRaWAN network using the TrackIt application as a configuration tool. - -### Product Features - -- MT2523 with built-in Bluetooth and GPS -- SX1262 LoRa chip -- Built-in accelerometer -- Built-in battery: 400 mAh -- Charger with a magnetic plate -- Small size: 42x42x18 mm -- Low weight: 25 g -- Operating temperature: -20 °C to +60 °C -- IP65 rating -- Android and iOS application for easy management, configuration, and location tracking - -### Useful Resources - -- [Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK2171/Quickstart/) -- [Datasheet](https://docs.rakwireless.com/Product-Categories/WisNode/RAK2171/Datasheet/) -- [Store: RAK2171 WisNode TrackIt](https://store.rakwireless.com/products/wisnode-trackit-set-rak2171?utm_source=RAK2171WisNodeTrackIt&utm_medium=Document&utm_campaign=BuyFromStore) - -## WisNode TrackIt Helium Integration - -:::tip - -Before going through each and every step in connecting RAK2171 to Helium, it is recommended to check -first the -[Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK2171/Quickstart/). - -::: - -This guide shows how to register the TrackIt device in the Helium console and make integration to -Datacake, where you can use the dashboard to view the data in a more user-friendly way. - -Before you dive into registering the device in the Helium console and creating the Datacake -integration, you need to set the device to work in -[Third-Party LoRaWAN Network Server (LNS) Mode](https://docs.rakwireless.com/Product-Categories/WisNode/RAK2171/Quickstart/#third-party-lorawan-network-server-lns-mode). - -### Register the TrackIt Node in the Helium Console - -1. Login to your Helium console account. If you do not have one, head to the web page and create - one. Once you are logged in, you will see the Welcome window. - - - -2. In the menu on the left side of the console, select **Devices** and click the **Add new device** - button to register your device. - - - -3. In the **Name** field, type the preferred name of your device. - - - -4. You can see that the Helium console generates random **Dev EUI**, **App EUI**, and **App Key**. - Since the TrackIt keys cannot be changed, you need to type your keys in the fields. These keys - are found in the TrackIt application in the LoRaWAN Working Mode (Third Party NS). - - - -5. Optionally, you can select a **Profile** and **Attach a Label**. For this tutorial, they will be - skipped. Note that **Profiles** and **Labels** can be added after the device is registered. - -6. After typing in the required keys, click **Save Device**, and you will see the registered device. - As mentioned by the console, the initial join process takes about 20 minutes for the device to - join, so be patient. - -### Create Datacake Integration - -1. While the device is joining, you can create the integration. Select **Integrations** from the - menu in the left panel. - - - -2. To create an integration, click on the **Add New Integration** button. A list of the available - integrations will appear. As for this guide, click **Datacake**. For further information, refer - to the [**Integrations** documentation](/use-the-network/console/integrations/). - - - -3. On the next page, you will need a **Datacake Token**. To generate one, you will need a Datacake - account. If you don't have an account yet, you can create one on - [Datacake's website](https://datacake.co/). - - - -4. After logging in to your Datacake account, click your profile and select **Edit Profile**. - - - -5. In the **API** tab, you will find your API token. Copy and paste it into the **Enter Datacake - Token** field in the Helium console. - - - -6. When you place the token, type a name of your choice for the integration and click **Add - Integration** to continue. - - - -#### Connection Between Helium and Datacake - -1. Now that the device is registered and the integration is created, you will need to make a - connection between Helium and Datacake. Click **Flows** on the left menu. - - - -2. Click the **+** icon in the **Nodes** area. A window will pop up with four menus – **Labels**, - **Devices**, **Functions**, and **Integrations**. Click **Devices**, and you will see your - registered device. - - - -3. Now, click your registered device, then drag and drop it on the blank page. - - - -4. Do the same with the created integration. Click the **Integrations** menu, then drag and drop it. - - - -#### Datacake Device Resignation - -1. You need to add the device to the **Datacake** console. Head to the **Devices** tab and click the - **+ Add Device** button. - - - -2. Datacake has ready-to-use TrackIt template. To add the device, click **LoRaWAN** and then - **Next**. - - - -3. On the next window, in the **Search** field, type **TrackIt** and choose the **Device Template**. - Then click **Next**. - - - -4. On the next page, choose **Helium** for Network server and click **Next**. - - - -5. On the next page, type the **Dev EUI** and the **Name of your device**. You can add more than one - device. You can also drag and drop a `.csv` file, and it automatically adds multiple devices at - once. Then click **Next**. - - - -6. Finally, choose a plan. For this example, choose the **Free** one. Click **Add 1 device** to - finish. - - - -7. Now, your device is registered in Datacake. - - - -8. You can click the name of your device and check the Dashboard. - - - -Everything in the Dashboard is pre-configured (fields, decoder, widgets), and it is ready to use. diff --git a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7200.mdx b/docs/use-the-network/devices/ready-to-use/rakwireless/rak7200.mdx deleted file mode 100644 index 511fefcd0..000000000 --- a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7200.mdx +++ /dev/null @@ -1,168 +0,0 @@ ---- -id: rak7200 -title: Rak7200 Wisnode Track Lite -pagination_label: Rak7200 -sidebar_label: Rak7200 Wisnode Track Lite -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/rakwireless/rak7200 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Overview - -The RAK7200 WisNode Track Lite is an LPWAN Tracker device with a 3.7V rechargeable Li-Ion battery -and a GPS modem. It is built around low-power LPWAN Module, which integrates the ultra-low-power -STM32L073 micro-controller, the SX1276 LoRa long-range modem, and the CXD5603GF GPS modem. - -This device can be used as a quick prototyping tool for LoRaWAN application development. It is -suited for IoT applications such as asset tracking, smart vehicle management, and location-based -services. - -### Product Features - -- Supports sleep mode and low-power consumption. -- Built-in **LIS3DH - digital motion sensor**, which has dynamic user selectable full scales of - ±2g/±4g/±8g/±18g and is capable of measuring accelerations with output data rates from 1Hz to - 5kHz. -- Barometer: Built-in **LPS22HB - digital nano pressure sensor**. -- Built-in **9-Axis Sensor**, which includes a triple-axis gyroscope, a triple-axis accelerometer, - and a triple-axis magnetometer. -- LoRaWAN 1.0.2 Standard support - ABP or OTAA mode. -- LoRa and GPS antenna are integrated inside the casing. -- Micro USB for configuration and charging of the battery. -- Supports global license-free frequency band: IN865, EU868, US915, AU915, KR920, and AS923. - -### Useful Resources - -- [Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7200/Quickstart/) -- [Datasheet](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7200/Datasheet/) -- [AT Command Manual](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7200/AT-Command-Manual) -- [Store: RAK7200 WisNode Track Lite](https://store.rakwireless.com/products/rak7200-lora-tracker?utm_source=RAK7200WisNodeTrackLite&utm_medium=Document&utm_campaign=BuyFromStore) - -## Connecting to Helium (The People's Network) - -:::tip - -Before going through each and every step in connecting the RAK7200 to Helium, it is recommended to -check first our -[Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7200/Quickstart/). - -::: - -Helium has quickly become the most widespread LPWAN communal network with more than 27,000 devices -deployed globally. All the RAKwireless node products are compatible with it and the process of -adding a device to the network is intuitive and straightforward. - -This section will focus on giving a brief guide on how to connect the RAK7200 to the network -console, assuming that there is a Helium Hotspot within range. - -Log in or create your account [here](https://www.helium.com/console). - - - -Once registered/logged in, you will end up at the home page, where you can see your function tree on -the left and DC balance at the top, as well as a number of useful links. - - - -Go to the **Devices** section in the function tree. There will be no registered devices if this is -your first time doing this. To add a device, click the **+ Add Device** button and get started. - - - -A window will pop up with a set of fields containing the device parameters required for its -registration. - - - -Fill in a name of your choosing. The **Dev EUI**, **App EUI**, and **App Key** will have random -values generated for you by default. Press the eye icon to reveal the values. You can manually -replace them with values of your own. For this tutorial, default values are used. Press the -**Submit** button, and you are done. - - - -Now, your RAK7200 is registered and is awaiting activation. For this to happen, import the **Dev -EUI**, **App EUI**, and **App Key** in the RAK7200 using the -[RAK Serial Port Tool](https://downloads.rakwireless.com/en/LoRa/Tools/RAK_SERIAL_PORT_TOOL_V1.2.1.zip). - -Open the tool, select the desired port (default baud rate) and open it. Then start importing your -settings. - -Configure your LoRa band and activation mode. This tutorial will be using the EU868 band and OTAA -(the only option available for now with Helium) with device class A (the default one does not need -configuring). - -- Regional band and activation mode setting - -``` -at+set_config=lora:join_mode:0 -``` - -``` -at+set_config=lora:region:EU868 -``` - -- Enter the Dev UI - -Use the command below by replacing the XXXX with your Device EUI from the Helium console: - -``` -at+set_config=lora:dev_eui:XXXX -``` - -- Enter the App EUI - -The same as with the Device EUI, replace the XXXX with your value: - -``` -at+set_config=lora:app_eui:XXXX -``` - -- Enter App Key - -Finally, fill in the App key with the command: - -``` -at+set_config=lora:app_key:XXXX -``` - -- Join Network - -Finish executing the join command for the node to initiate the join procedure. Once the procedure is -initiated and completed, you will have a notification in the serial console. - -``` -at+join -``` - -Your output should resemble the one in figure below: - - - -If you take a look at the Helium console, you will also see the join request packets both in the -graph and event log. Your node is now a part of the Helium Network. - - diff --git a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7201.mdx b/docs/use-the-network/devices/ready-to-use/rakwireless/rak7201.mdx deleted file mode 100644 index 5485d4810..000000000 --- a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7201.mdx +++ /dev/null @@ -1,177 +0,0 @@ ---- -id: rak7201 -title: Rak7201 Wisnode Button 4K -pagination_label: Rak7201 -sidebar_label: Rak7201 Wisnode Button 4K -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/rakwireless/rak7201 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Overview - -The RAK7201 WisNode Button 4K is a remote wireless trigger device. It supports user-defined -functions for each key and is based on the LoRaWAN 1.0.2 protocol. Supported LoRaWAN bands are -IN865, EU868, AU915, US915, KR920, and AS923. - -This WisNode Button is suitable for a variety of Smart Home applications. Including, but not limited -to, entertainment system control, control of lights, a snooze button for the alarms, or a remote -trigger. A device with long-range wireless connectivity, amazing battery life, and four programmable -buttons. There are tons of applications this device can fit into. - -### Product Features - -- Four (4) buttons with LED indicator -- Product size: 43 x 57 x 15 mm -- LoRaWAN® 1.0.2 compatible -- Battery: 350 mAh -- Battery working time: 1 year (Rechargeable) -- Power consumption: - - Transmit: 77.4-153 mA (Transmit current depends on factors such as transmit power, SF and - Payload Length) - - Standby: 4.8 uA -- Operating temperature: -20º C to 60º C -- Working environment: Indoor - -### Useful Resources - -- [Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7201/Quickstart) -- [Datasheet](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7201/Datasheet/) -- [AT Command Manual](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7201/AT-Command-Manual) -- [Firmware Upgrade Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7201/Firmware-Upgrade-Guide/) -- [RAK7201 WisNode Button 4K](https://store.rakwireless.com/products/wisnode-button-4k-rak7201?utm_source=RAK7201WisNodeButton4K&utm_medium=Document&utm_campaign=BuyFromStore) - -## Connecting to Helium (The People's Network) - -:::tip - -Before going through each and every step in connecting the RAK7201 to Helium, it is recommended to -check first our -[Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7201/Quickstart/). - -::: - -Helium has quickly become the most widespread LPWAN communal network with more than 27,000 devices -deployed globally. All the RAKwireless node products are compatible with it and the process of -adding a device to the network is intuitive and straightforward. This section will focus on giving a -brief guide on how to connect the RAK7201 to the network console, assuming that there is a Helium -Hotspot within range. - -Log in or create your account [here](https://www.helium.com/console). - - - -Once registered/logged in, you will end up at the home page, where you can see your function tree on -the left and DC balance at the top, as well as a number of useful links. - - - -Go to the **Devices** section in the function tree. There will be no registered devices if this is -your first time doing this. To add a device, click the **+ Add Device** button and get started. - - - -A window will pop up with a set of fields containing the device parameters required for its -registration. - - - -ill in a name of your choosing. The **Dev EUI**, **App EUI**, and **App Key** will have random -values generated for you by default. Press the eye icon to reveal the values. You can manually -replace them with values of your own. For this tutorial, default values are used. Press the -**Submit** button, and you are done. - - - -Now, your RAK7201 is registered and is awaiting activation. For this to happen, import the **Dev -EUI**, **App EUI**, and **App Key** in the RAK7201 using the -[RAK Serial Port Tool](https://downloads.rakwireless.com/en/LoRa/Tools/RAK_SERIAL_PORT_TOOL_V1.2.1.zip). - -Open the tool, select the desired port (default baud rate) and open it. Hold the button 1 for 3 -seconds to enter configuration mode, and then start importing your settings. - -Configure your LoRa band and activation mode. This tutorial will be using the EU868 band and OTAA -(the only option available for now with Helium) with device class A (the default one does not need -configuring). - -- Regional band, device class, and activation mode setting - -``` -at+set_config=lora:join_mode:0 -``` - -``` -at+set_config=lora:region:EU868 -``` - -- Enter the Dev UI - -Use the command below by replacing the XXXX with your Device EUI from the Helium console: - -``` -at+set_config=lora:dev_eui:XXXX -``` - -- Enter the App EUI - -The same as with the Device EUI, replace the XXXX with your value: - -``` -at+set_config=lora:app_eui:XXXX -``` - -- Enter App Key - -Finally, fill in the App key with the command: - -``` -at+set_config=lora:app_key:XXXX -``` - -- Join Network - -Finish executing the join command for the node to initiate the join procedure. Once the procedure is -initiated and completed, you will have a notification in the serial console. - -``` -at+join -``` - -Your output should resemble the one in figure below: - - - -If you take a look at the Helium console, you will also see the join request packets both in the -graph and event log. Your node is now a part of the Helium Network. - - diff --git a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7204.mdx b/docs/use-the-network/devices/ready-to-use/rakwireless/rak7204.mdx deleted file mode 100644 index d3d30866b..000000000 --- a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7204.mdx +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: rak7204 -title: Rak7204 Wisnode Sense Home -pagination_label: Rak7204 -sidebar_label: Rak7204 Wisnode Sense Home -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/rakwireless/rak7204 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Overview - -The RAK7204 WisNode Sense Home is an LPWAN node with integrated environmental sensors. The -high-precision environmental sensors, can measure changes in temperature, humidity, gas pressure and -provide an indoor air quality index. All the accumulated data can be send to a gateway in order for -it to be forwarded to the Cloud. - -### Product Features - -- Measurement of a variety of environmental parameters: **Temperature**, **Humidity**, **Gas - Pressure**, and **Indoor Air Quality (IAQ)** -- **BOSCH BME680** Integrated Environmental Unit -- **LoRaWAN 1.0.2** fully compliant -- Low power operation and standby current of less than 15 uA -- Adjustable sampling and transmission interval. -- Comes with a replaceable 3500 mAh high capacity lithium battery -- Real time battery status monitoring. -- **Battery life of more than 2 years** (At 15 minute data transmission interval) -- Compact in size, easy to install and maintain. - -### Useful Resources - -- [Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7204/Quickstart/) -- [Datasheet](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7204/Datasheet/) -- [AT Command Manual](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7204/AT-Command-Manual/) -- [Store: RAK7204 WisNode Sense Home](https://store.rakwireless.com/products/rak7204-lpwan-environmental-node) - -:::info - -[The WisNode Sense Home (RAK7204)](https://store.rakwireless.com/products/rak7204-lpwan-environmental-node) -is permanently out of stock. As an alternative product, we recommend -[RAK WisBlock Weather Monitor Kit](https://store.rakwireless.com/products/wisblock-kit-1-weather-monitor?variant=37637925372102) - -::: - -## Connecting to Helium (The People's Network) - -:::tip - -Before going through each and every step in Connecting the RAK7204 to Helium, it is recommended to -check first our -[Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7204/Quickstart/). - -::: - -Helium has quickly become the most widespread LPWAN communal network with more than 27,000 devices -deployed globally. All the RAKwireless node products are compatible with it and the process of -adding a device to the network is intuitive and straightforward. This section will focus on giving a -brief guide on how to connect the RAK7204 to the network console, assuming that there is a Helium -Hotspot within range. - -Log in or create your account [here](https://www.helium.com/console). - - - -Once registered/logged in, you will end up at the home page where you can see your function tree on -the left and your DC balance at the tops as well as a number of useful links. - - - -Go to the **Devices** section in the function tree. There will be no registered devices if this is -your first time doing this. To add a device, click the **+ Add Device** button and get started. - - - -A window will pop up with a set of field containing the device parameters required for its -registration. - - - -Fill in a name of your choosing. The **Dev EUI**, **App EUI**, and **App Key** will have random -values generated for you by default. Press the eye icon to reveal the values. You can manually -replace them with values of your own. For this tutorial, default values are used. Press the -**Submit** button, and you are done. - - - -Now your RAK7204 is registered and is awaiting activation. For this to happen we need to import the -**Dev EUI**, **App EUI**, and **App Key** in the RAK7204 using the -[RAK Serial Port Tool](https://downloads.rakwireless.com/en/LoRa/Tools/RAK_SERIAL_PORT_TOOL_V1.2.1.zip). - -Open the tool, select the desired port (default baud rate) and open it. Then start importing your -settings. - -Configure your LoRa band and activation mode. This tutorial will be using the EU868 band and OTAA -(only option available for now with Helium) with device class A (default one, does not need -configuring). - -- Regional band and activation mode setting - -``` -at+set_config=lora:join_mode:0 -``` - -``` -at+set_config=lora:region:EU868 -``` - -- Enter the Dev UI - -Use the command below by replacing the XXXX with your Device EUI from the Helium console: - -``` -at+set_config=lora:dev_eui:XXXX -``` - -- Enter the App EUI - -Same as with the Device EUI, replace the XXXX with your value: - -``` -at+set_config=lora:app_eui:XXXX -``` - -- Enter App Key - -Finally fill in the App key with the command: - -``` -at+set_config=lora:app_key:XXXX -``` - -- Join Network - -Finish executing the join command in order for the node to initiate the join procedure. - -Once the procedure is initiated and successfully complete you will have a notification in the serial -console - -``` -at+join -``` - -You output should resemble the one in figure below: - - - -If you take a look at the Helium console, you will also see the join request packets both in the -graph and event log. Your node is now a part of the Helium Network. - - diff --git a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7431.mdx b/docs/use-the-network/devices/ready-to-use/rakwireless/rak7431.mdx deleted file mode 100644 index 4bb772947..000000000 --- a/docs/use-the-network/devices/ready-to-use/rakwireless/rak7431.mdx +++ /dev/null @@ -1,178 +0,0 @@ ---- -id: rak7431 -title: Rak7431 Wisnode Bridge Serial -pagination_label: Rak7431 -sidebar_label: Rak7431 Wisnode Bridge Serial -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/rakwireless/rak7431 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -## Overview - -RAK7431 WisNode Bridge Serial is an RS485 to LoRaWAN converter designed for industrial applications. -The device relays ModBUS data using the LoRaWAN network as means of wirelessly transmitting to and -from the end-devices. - -RAK7431 can operate in all of the LoRaWAN bands within the standard parameters defined by the LoRa -Alliance. Its open environment range is 15+ km, and in industrial cases, where there are heavy -obstructions in the path of the RF signal performance is improved compared to conventional wireless -systems due to the characteristics of LoRa as a modulation technique. This allows for consistently -good signal quality within the confines of large factories, densely populated offices, storehouses, -etc. - -This RS485 compatible device can address up to 16 client terminal nodes. The conversion from and to -LoRa frames is seamless and allows for real-time control and monitoring of multiple RS485 devices, -and bus data to access and control the RS485 terminal nodes. - -RAK7431 together with RAK gateway and LoRa Server products, can easily and quickly build a wireless -industrial field control system. It adopts industrial protection design, supports a wide range -voltage supply, supports wall mounting and DIN rail installation, and facilitates field installation -and use. - -### Product Features - -- LoRaWAN 1.0.3 protocol stack, supports Class A, B, & C. -- Working modes: Polling mode, Transparent mode, and Packet mode. -- Remote cloud management of RS485 devices. -- Can address up to **16 RS485**, a que with up to **32 instruction sets**. -- Industrial grade STM MCU: ultra-low power (**4uA sleep**) and wide temperature range of operation. -- Wide range of input voltages, **8-48V DC input**. -- Can power RS485 devices via a dedicated output. -- Mounting: Wall, DIN rail, and magnetic mounting. -- Compliant with IEC61000-4-2, IEC61000-4-4, and 18kV HMB ESD protection. - -### Useful Resources - -- [Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7431/Quickstart/) -- [Datasheet](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7431/Datasheet/) -- [AT Command Manual](https://docs.rakwireless.com/Product-Categories/WisNode/RAK7431/AT-Command-Manual/) -- [Store: RAK7431 WisNode Bridge Serial](https://store.rakwireless.com/products/rak7431?utm_source=RAK7431WisNodeBridge&utm_medium=Document&utm_campaign=BuyFromStore) - -## Connecting to Helium (The People's Network) - -:::tip - -Before going through each and every step in connecting the RAK7431 to Helium, it is recommended to -check first our -[Quick Start Guide](https://docs.rakwireless.com/Product-Categories/WisNode/rak7431/Quickstart/). - -::: - -Helium has quickly become the most widespread LPWAN communal network with more than 27,000 devices -deployed globally. All the RAKwireless node products are compatible with it and the process of -adding a device to the network is intuitive and straightforward. - -This section will focus on giving a brief guide on how to connect the RAK7431 to the network -console, assuming that there is a Helium Hotspot within range. - -Log in or create your account [here](https://www.helium.com/console). - - - -Once registered/logged in, you will end up at the home page, where you can see your function tree on -the left and DC balance at the top, as well as a number of useful links. - - - -Go to the **Devices** section in the function tree. There will be no registered devices if this is -your first time doing this. To add a device, click the **+ Add Device** button and get started. - - - -A window will pop up with a set of fields containing the device parameters required for its -registration. - - - -Fill in a name of your choosing. The **Dev EUI**, **App EUI**, and **App Key** will have random -values generated for you by default. Press the eye icon to reveal the values. You can manually -replace them with values of your own. For this tutorial, default values are used. Press the -**Submit** button, and you are done. - - - -Now, your RAK7431 is registered and is awaiting activation. For this to happen, import the **Dev -EUI**, **App EUI**, and **App Key** in the RAK7431 using the -[RAK Serial Port Tool](https://downloads.rakwireless.com/en/LoRa/Tools/RAK_SERIAL_PORT_TOOL_V1.2.1.zip). - -Open the tool, select the desired port (default baud rate) and open it. Then start importing your -settings. - -Configure your LoRa band and activation mode. This tutorial will be using the EU868 band and OTAA -(the only option available for now with Helium) with device class A (the default one does not need -configuring). - -- Regional band, device class, and activation mode setting - -``` -at+joinmode=OTAA -``` - -``` -at+region=EU868 -``` - -- Enter the Dev UI - -Use the command below by replacing the XXXX with your Device EUI from the Helium console: - -``` -at+deveui=XXXX -``` - -- Enter the App EUI - -The same as with the Device EUI, replace the XXXX with your value: - -``` -at+appeui=XXXX -``` - -- Enter App Key - -Finally, fill in the App key with the command: - -``` -at+appkey=XXXX -``` - -- Join Network - -Run the following AT command for the node to join the network. Once the procedure is initiated and -completed, you will have a notification in the serial console. - -``` -at+restart -``` - -Your output should resemble the one in figure below: - - - -If you take a look at the Helium console, you will also see the join request packets both in the -graph and event log. Your node is now a part of the Helium Network. - - diff --git a/docs/use-the-network/devices/ready-to-use/ready-to-use.mdx b/docs/use-the-network/devices/ready-to-use/ready-to-use.mdx deleted file mode 100644 index 08098b121..000000000 --- a/docs/use-the-network/devices/ready-to-use/ready-to-use.mdx +++ /dev/null @@ -1,418 +0,0 @@ ---- -id: ready-to-use -title: Ready To Use Devices -pagination_label: Ready To Use Devices -sidebar_label: Ready To Use Devices -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -
-
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
- - - -

- - {' '} - View Devices - -
-
-
diff --git a/docs/use-the-network/devices/ready-to-use/seeed-sensecap.mdx b/docs/use-the-network/devices/ready-to-use/seeed-sensecap.mdx deleted file mode 100644 index c5eeafacc..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-sensecap.mdx +++ /dev/null @@ -1,193 +0,0 @@ ---- -id: seeed-sensecap -title: Seeed Sensecap -pagination_label: Seeed Sensecap -sidebar_label: Seeed Sensecap -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-sensecap ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Seeed SenseCAP - -
- -
- -### Introduction - -The SEEED SenseCAPs are are a series of industrial IoT products primarily centered around Smart -Agriculture. They are based on the LoRaWAN protocol and deployable worldwide with multiple ISM -bands. SenseCAPs are encapsulated in IP66 enclosures, making them applicable in outdoor remote -sensing scenarios such as Smart Farming, Smart City, and other IoT applications that need low-power, -long-distance, and long-term data collection. - -
- -
- -### Sensors - -| Sensors | Range | Accuracy | -| :----------------------------- | :------------------- | :------------------------------------------ | -| AirTemp&Humi Sensor | -40~90°\(0-100%RH\) | 土 0.3°C 土 2%RH | -| Soil Temp&Humi Sensor | -30~ 70°\(O~ 1 00%RH | 土 0.2°c 土 2%RH \(0%~50%\) | -| Air Pressure Sensor | 300-1100hPa | 士 1hPa \(950hPa~ 1 OSOhPa \(0\)° \(-40°c\) | -| CO2 Sensor | 400-10,000ppm | 士 30ppm+3% | -| Light Sensor | Max 188,000Lux | 0.045Lux/LSB | -| Wind Speed Sensor | 0-60m/s | 0.125m/s | -| Wind Direction Sensor | 8 Directions | 45° | -| Water PH Sensor | | | -| Light quantum Sensor | | | -| Electrical Conductivity Sensor | | | -| Dissolved Oxygen Sensor | | | -| Soil VWC&EC&Temp Sensor | | | -| Rainfall Recorder Sensor | | | - -
- The Sensor Probes can easily be interchanged between Sensor Node Controllers. -
- -### Internals - -
- - -
- -
Easily removed from enclosures.
- -
- -
- -
Ready for field-deployment right out of the box.
- -
- -
- -
- The main SenseCAP module contains the LoRaWAN radio, antenna, and batteries. -
- -### Set up new device with existing keys - -Copy down the "EUI" and the "KEY" from the label on your SenseCAP device: - -
- -
- -Understand that there is a bit of a naming issue here. The key names are mapped as such: - -
EUI = DEVEUI = Device EUI
- -

KEY = DEVICECODE = Device Code

- -
Is this super convoluted and frustrating? Yes. We did not make it this way.
-

Now, we need to get those two keys and insert them into the following URL:

- -
- - https://sensecap.seeed.cc/makerapi/device/view_device_info?nodeEui= - DEVEUI&deviceCode= - DEVICECODE - -
- -In the above example, the URL would look like such: - -
DEVEUI (Device EUI): 2cf7f12121XXXXXX
- -

DEVICECODE (Device Code): 1826ed12XXXXXXXX

- -

- - https://sensecap.seeed.cc/makerapi/device/view_device_info?nodeEui= - 2cf7f12121XXXXXX&deviceCode= - 1826ed12XXXXXXXX - -

- -

-The SenseCAP sensor device's AppEUI and AppKey have been flashed into the device by SEEED. -We will use the HTTP API to retrieve the actual App EUI and App Key. -

-

-You can use a browser to issue an HTTP GET request. -

-We simply paste the URL we constructed above into a browser address bar, and it should return a JSON object in the following format containing the *actual* keys programmed onto the device: -
- - { - "code": "0", - "data": { - "nodeEui": "2cf7f12121XXXXXX", - "deviceCode": "1826ed12XXXXXXXX", - "lorawanInformation": { - "dev_eui": "2CF7F12121XXXXXX", - "app_eui": "8000000000XXXXXX", - "app_key": "3BF3D4C5744A057E0A1A61F4XXXXXXXX" - } - } - } - -
- -The last three keys in this object (dev_eui, app_eui, and app_key) will be used to create this -device in the [Helium Console](https://console.helium.com/devices). - -
- -
- -You have now linked your new SenseCAP device to the Helium Console! - -We now simply have to turn it on. Carefully unscrew the cap on the SenseCAP node, switch it to the -"ON" position, and replace the cap. - -
- -
- -At this point, you may open up the new device within the Helium Console, click the "Debug" icon on -the right, and should see packets arriving in short order! - -
- -
- -### Programming the SenseCAP - -In some situations, you may want to change the keys provisioned on the device. To reprogram the -SenseCap, you will need a TTL/Serial cable. I added some 90 degree headers on the base unit to make -it easier to connect a molex connector, but you may can make do with sliding some pins in there and -holding them at an angle to maintain contact. Only connect the Ground and the TX/RX lines; leave the -3v3 pin disconnected. At this point, we can either connect to the device directly using a serial -terminal, or use the SenseCAP GUI utility \(for Windows and Mac only ATM\) found -[here](https://github.com/Seeed-Solution/SenseCAP-Node-Configuration-Tool). - -
- -
- -Connect your cable, turn the unit on, and then tap the Reset button while holding the Set button. -This will put you into programming mode. Following that, either jot down your Device EUI/App EUI/App -Key from the right pane in the utility and enter those into the Helium Console, or get the Helium -keys from the Console, enter them in this utility, and write them down to the node. - -
- -
- -Voila! Unplug your cable, hit the reset button, wait for the red LIVE led to flash a few times, and -you should see an activation come across your Helium Console! At this point, carefully replace the -sensor cap, and you should be good to go! diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-air-th.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-air-th.mdx deleted file mode 100644 index fd13544f4..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-air-th.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: sensecap-air-th -title: Sensecap Wireless Air Temperature And Humidity Sensor - LoRaWAN® -pagination_label: Sensecap Air Th -sidebar_label: Sensecap Wireless Air Temperature And Humidity Sensor - LoRaWAN® -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-air-th ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP Wireless Air Temperature and Humidity Sensor - LoRaWAN® - -It measures temperature and humidity in the atmosphere. It's designed with a 2-in-1 sensor, a custom -battery, and an industry-grade enclosure, optimized for outdoor use cases that need reliable data -collection for years. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRaWAN-Soil-Moisture-and-Temperature-Sensor-EU868-p-4316.html) -- [Datasheet](https://files.seeedstudio.com/products/317990687/res/LoRaWAN%20Gateway%20and%20Wireless%20Sensor%20Catalog-V1.6%20NEW.pdf) -- [Reseller - Distrelec](https://www.distrelec.nl/en/sensecap-lorawan-wireless-air-temperature-and-humidity-sensor-ip66-868mhz-seeed-studio-114991726/p/30167647?q=sensecap&pos=4&origPos=4&origPageSize=50&track=true) -- [Reseller - Mouser](https://www.mouser.com/new/seeed-studio/seeed-sensecap-lora-air-temp-sensor/) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRaWAN-Air-Temperature-and-Humidity-Sensor-EU868-p-4307.html) - -### Specifications - -#### Sensors: - -- humidity -- temperature - -#### Dimensions: - -- width: 56 mm -- length: 173 mm -- height: 56 mm - -#### Weight: - -- 236 grams - -#### Battery: - -- type: Lithium Thionyl Chloride (non-rechargeable) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-co2.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-co2.mdx deleted file mode 100644 index 2214e83a4..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-co2.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: sensecap-co2 -title: Sensecap Wireless Co2 Sensor - LoRaWAN® -pagination_label: Sensecap Co2 -sidebar_label: Sensecap Wireless Co2 Sensor - LoRaWAN® -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-co2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP Wireless CO2 Sensor - LoRaWAN® - -It measures levels of CO2 emission in the atmosphere, designed with an NDIR CO2 sensor and a custom -battery. It's dustproof, optimal for use cases that need reliable data collection, even in dusted -indoor environments such as chicken farms. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRaWAN-CO2-Sensor-EU868-p-4311.html) -- [Datasheet](https://files.seeedstudio.com/products/317990687/res/LoRaWAN%20Gateway%20and%20Wireless%20Sensor%20Catalog-V1.6%20NEW.pdf) -- [Reseller - Distrelec](https://www.distrelec.nl/en/sensecap-lorawan-wireless-co2-sensor-ip66-868mhz-seeed-studio-114991728/p/30167649?q=sensecap&pos=2&origPos=2&origPageSize=50&track=true) -- [Reseller - Mouser](https://www.mouser.com/new/seeed-studio/seeed-sensecap-lora-co2-sensor/) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRaWAN-CO2-Sensor-EU868-p-4311.html) - -### Specifications - -#### Sensors: - -- co2 - -#### Dimensions: - -- width: 56 mm -- length: 173 mm -- height: 56 mm - -#### Weight: - -- 319 grams - -#### Battery: - -- type: Lithium Thionyl Chloride (non-rechargeable) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-light.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-light.mdx deleted file mode 100644 index 563e41313..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-light.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: sensecap-light -title: Sensecap Wireless Light Intensity Sensor - LoRaWAN® -pagination_label: Sensecap Light -sidebar_label: Sensecap Wireless Light Intensity Sensor - LoRaWAN® -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-light ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP Wireless Light Intensity Sensor - LoRaWAN® - -It measures the intensity of light in lux from 0 - 188000 lux. It is designed with battery-powered -and IP66 enclosure for outdoor use, optimized for use cases that need reliable data collection over -years. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRaWAN-Light-Intensity-Sensor-EU868-p-4313.html) -- [Datasheet](https://files.seeedstudio.com/products/317990687/res/LoRaWAN%20Gateway%20and%20Wireless%20Sensor%20Catalog-V1.6%20NEW.pdf) -- [Reseller - Distrelec](https://www.distrelec.nl/en/sensecap-lorawan-wireless-light-intensity-sensor-ip66-868mhz-seeed-studio-114991727/p/30167648?q=sensecap&pos=3&origPos=3&origPageSize=50&track=true) -- [Reseller - Mouser](https://www.mouser.com/new/seeed-studio/seeed-sensecap-lora-light-intensity-sensor/) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRaWAN-Light-Intensity-Sensor-EU868-p-4313.html) - -### Specifications - -#### Sensors: - -- light - -#### Dimensions: - -- width: 56 mm -- length: 173 mm -- height: 56 mm - -#### Weight: - -- 288 grams - -#### Battery: - -- type: Lithium Thionyl Chloride (non-rechargeable) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-pressure.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-pressure.mdx deleted file mode 100644 index ab1847056..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-pressure.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: sensecap-pressure -title: Sensecap Wireless Barometric Pressure Sensor - LoRaWAN® -pagination_label: Sensecap Pressure -sidebar_label: Sensecap Wireless Barometric Pressure Sensor - LoRaWAN® -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-pressure ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP Wireless Barometric Pressure Sensor - LoRaWAN® - -It measures atmospheric pressure, featuring high-precision, stability, and high EMC robustness. It’s -designed with an air pressure sensor, a custom battery, and an industry-grade enclosure, optimized -for outdoor use cases that need reliable data collection over years. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRaWAN-Barometric-Pressure-Sensor-EU868-p-4309.html) -- [Datasheet](https://files.seeedstudio.com/products/317990687/res/LoRaWAN%20Gateway%20and%20Wireless%20Sensor%20Catalog-V1.6%20NEW.pdf) -- [Reseller - Distrelec](https://www.distrelec.nl/en/sensecap-lorawan-wireless-barometric-pressure-sensor-ip66-868mhz-seeed-studio-114991729/p/30167650?q=sensecap&pos=1&origPos=1&origPageSize=50&track=true) -- [Reseller - Mouser](https://www.mouser.com/new/seeed-studio/seeed-sensecap-lora-barometric-sensor/) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRaWAN-Barometric-Pressure-Sensor-EU868-p-4309.html) - -### Specifications - -#### Sensors: - -- barometer - -#### Dimensions: - -- width: 56 mm -- length: 173 mm -- height: 56 mm - -#### Weight: - -- 237 grams - -#### Battery: - -- type: Lithium Thionyl Chloride (non-rechargeable) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2100-data-logger.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2100-data-logger.mdx deleted file mode 100644 index c48cc59e9..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2100-data-logger.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -id: sensecap-s2100-data-logger -title: Sensecap S2100 LoRaWAN® Data Logger -pagination_label: Sensecap S2100 Data Logger -sidebar_label: Sensecap S2100 LoRaWAN® Data Logger -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2100-data-logger ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP S2100 LoRaWAN® Data Logger - -SenseCAP S2100 LoRaWAN® Data Logger is an easy-to-deploy, industrial-grade sensor hub that can -support 100+ industrial sensors and 100+ grove sensors including various sensor types such as -Analog/I2C/UART/RS485. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/SenseCAP-S2100-LoRaWAN-Data-Logger-p-5361.html) -- [Datasheet](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view?usp=sharing) -- [User Manual](https://drive.google.com/file/d/1Jq9Nigpjzda6mw9a20I6FHBEfS25PdAA/view?usp=sharing) - -### Specifications - -[S2100 LoRaWAN® Data Logger](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view) - -#### Sensors: - -- Data Logger - -#### Weight: - -- 280 grams - -#### Battery: - -(contained in equipment) - -- Battery Life: up to 10 years (Depends on the power consumption of the sensor) -- Battery Capacity: 19 Ah (non-rechargeable) -- Battery Type: Standard D-size SOCl2 Battery diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2101-tem-humid.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2101-tem-humid.mdx deleted file mode 100644 index 39c08afe4..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2101-tem-humid.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: sensecap-s2101-tem-humid -title: Sensecap S2101- LoRaWAN® Air Temperature And Humidity Sensor -pagination_label: Sensecap S2101 Tem Humid -sidebar_label: Sensecap S2101- LoRaWAN® Air Temperature And Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2101-tem-humid ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP S2101- LoRaWAN® Air Temperature and Humidity Sensor - -SenseCAP 2101 temperature & humidity sensors satisfy industrial long-distance data acquisition with -a wide range of -40°C to 85°C and 0 to 100 %RH respectively. With Bluetooth 5.0 for easy -configuration and firmware upgrade and a built-in replaceable battery for minimal maintenance, it -also supports three different LoRaWAN® network architectures enabling you to easily join it in -existing gateways and network servers to build flexible and high-performance sensor network. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/SenseCAP-S2101-LoRaWAN-Air-Temperature-and-Humidity-Sensor-p-5354.html) -- [Datasheet](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view?usp=sharing) -- [User Manual](https://drive.google.com/file/d/1Jq9Nigpjzda6mw9a20I6FHBEfS25PdAA/view?usp=sharing) - -### Specifications - -[S2101- LoRaWAN® Air Temperature and Humidity Sensor Specs](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view) - -#### Sensors: - -- humidity -- temperature - -#### Weight: - -- 280 grams - -#### Battery: - -(contained in equipment) - -- Battery Life: up to 10 years -- Battery Capacity: 19 Ah (non-rechargeable) -- Battery Type: Standard D-size SOCl2 Battery diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2102-light.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2102-light.mdx deleted file mode 100644 index 20d48bc37..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2102-light.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: sensecap-s2102-light -title: Sensecap S2102 - LoRaWAN® Light Intensity Sensor -pagination_label: Sensecap S2102 Light -sidebar_label: Sensecap S2102 - LoRaWAN® Light Intensity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2102-light ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP S2102 - LoRaWAN® Light Intensity Sensor - -SenseCAP S2102 light intensity sensors satisfy industrial long-distance data acquisition with a wide -range of intensity of light in lux from 0 - 160000 lux respectively. With Bluetooth 5.0 for easy -configuration and firmware upgrade and a built-in replaceable battery for minimal maintenance, it -also supports three different LoRaWAN® network architectures enabling you to easily join it in -existing gateways and network servers to build flexible and high-performance sensor network. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/SenseCAP-S2102-LoRaWAN-Light-Intensity-Sensor-p-5355.html) -- [Datasheet](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view?usp=sharing) -- [User Manual](https://drive.google.com/file/d/1Jq9Nigpjzda6mw9a20I6FHBEfS25PdAA/view?usp=sharing) - -### Specifications - -[S2102 - LoRaWAN® Light Intensity Sensor Specs](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view) - -#### Sensors: - -- Light Intensity - -#### Weight: - -- 280 grams - -#### Battery: - -(contained in equipment) - -- Battery Life: up to 10 years -- Battery Capacity: 19 Ah (non-rechargeable) -- Battery Type: Standard D-size SOCl2 Battery diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2103-co2-tem-humid.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2103-co2-tem-humid.mdx deleted file mode 100644 index f4157c5bd..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2103-co2-tem-humid.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: sensecap-s2103-co2-tem-humid -title: Sensecap S2103- LoRaWAN® Co2, Temperature, And Humidity Sensor -pagination_label: Sensecap S2103 Co2 Tem Humid -sidebar_label: Sensecap S2103- LoRaWAN® Co2, Temperature, And Humidity Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2103-co2-tem-humid ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP S2103- LoRaWAN® CO2, Temperature, and Humidity Sensor - -SenseCAP S2103- LoRaWAN® CO2, Temperature, and Humidity Sensors satisfy industrial long-distance -data acquisition with a wide range of 400 to 10000 ppm, -40°C to 85°C and 0 to 100% RH respectively. -With Bluetooth 5.0 for easy configuration and firmware upgrade and a built-in replaceable battery -for minimal maintenance, it also supports three different LoRaWAN® network architectures enabling -you to easily join it in existing gateways and network servers to build flexible and -high-performance sensor network. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/SenseCAP-S2103-LoRaWAN-CO2-Temperature-and-Humidity-Sensor-p-5356.html) -- [Datasheet](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view?usp=sharing) -- [User Manual](https://drive.google.com/file/d/1Jq9Nigpjzda6mw9a20I6FHBEfS25PdAA/view?usp=sharing) - -### Specifications - -[S2103- LoRaWAN® CO2, Temperature, and Humidity Sensor Specs](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view) - -#### Sensors: - -- CO2 -- Temperature -- Humidity - -#### Weight: - -- 285 grams - -#### Battery: - -(contained in equipment) - -- Battery Life: up to 10 years -- Battery Capacity: 19 Ah (non-rechargeable) -- Battery Type: Standard D-size SOCl2 Battery diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2104-soil-mois-tem.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2104-soil-mois-tem.mdx deleted file mode 100644 index 819d3b970..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2104-soil-mois-tem.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -id: sensecap-s2104-soil-mois-tem -title: Sensecap S2104 - LoRaWAN® Soil Moisture And Temperature Sensor -pagination_label: Sensecap S2104 Soil Mois Tem -sidebar_label: Sensecap S2104 - LoRaWAN® Soil Moisture And Temperature Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2104-soil-mois-tem ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP S2104 - LoRaWAN® Soil Moisture and Temperature Sensor - -SenseCAP S2104 - LoRaWAN® Soil Temperature and Moisture sensors satisfy industrial long-distance -data acquisition with a wide range of 0 ~ 100% (m³/m³) and -40 ~ 80℃ respectively. With Bluetooth -5.0 for easy configuration and firmware upgrade and a built-in replaceable battery for minimal -maintenance, it also supports three different LoRaWAN® network architectures enabling you to easily -join it in existing gateways and network servers to build flexible and high-performance sensor -network. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/SenseCAP-S2104-LoRaWAN-Soil-Temperature-and-Moisture-Sensor-p-5357.html) -- [Datasheet](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view?usp=sharing) -- [User Manual](https://drive.google.com/file/d/1Jq9Nigpjzda6mw9a20I6FHBEfS25PdAA/view?usp=sharing) - -### Specifications - -[S2104 - LoRaWAN® Soil Moisture and Temperature Sensor](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view) - -#### Sensors: - -- Soil Moisture -- Soil Temperature - -#### Weight: - -- 405 grams - -#### Battery: - -(contained in equipment) - -- Battery Life: up to 10 years -- Battery Capacity: 19 Ah (non-rechargeable) -- Battery Type: Standard D-size SOCl2 Battery diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2105-soil-mois-tem-ec.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2105-soil-mois-tem-ec.mdx deleted file mode 100644 index 989c58f49..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2105-soil-mois-tem-ec.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: sensecap-s2105-soil-mois-tem-ec -title: Sensecap S2105-LoRaWAN® Soil Moisture, Temperature And Ec Sensor -pagination_label: Sensecap S2105 Soil Mois Tem Ec -sidebar_label: Sensecap S2105-LoRaWAN® Soil Moisture, Temperature And Ec Sensor -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2105-soil-mois-tem-ec ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP S2105-LoRaWAN® Soil Moisture, Temperature and EC Sensor - -SenseCAP S2105 Soil Temperature, Moisture, and EC Sensor satisfy industrial long-distance data -acquisition with a wide range of 0 ~ 100% (m³/m³), -40 ~ 80℃, and 0 to 23 dS/m respectively. With -Bluetooth 5.0 for easy configuration and firmware upgrade and a built-in replaceable battery for -minimal maintenance, it also supports three different LoRaWAN® network architectures enabling you to -easily join it in existing gateways and network servers to build flexible and high-performance -sensor network. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/SenseCAP-S2105-LoRaWAN-Soil-Temperature-Moisture-and-EC-Sensor-p-5358.html) -- [Datasheet](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view?usp=sharing) -- [User Manual](https://drive.google.com/file/d/1Jq9Nigpjzda6mw9a20I6FHBEfS25PdAA/view?usp=sharing) - -### Specifications - -[S2105-LoRaWAN® Soil Moisture, Temperature and EC Sensor](https://drive.google.com/file/d/1HfZMCDgKOhgWbJDyBI8cY4T2JVEOh9fF/view) - -#### Sensors: - -- Soil Moisture -- Soil Temperature -- Soil EC - -#### Weight: - -- 405 grams - -#### Battery: - -(contained in equipment) - -- Battery Life: up to 10 years -- Battery Capacity: 19 Ah (non-rechargeable) -- Battery Type: Standard D-size SOCl2 Battery diff --git a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-soil-th.mdx b/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-soil-th.mdx deleted file mode 100644 index 08bde6c61..000000000 --- a/docs/use-the-network/devices/ready-to-use/seeed-studio/sensecap-soil-th.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: sensecap-soil-th -title: Sensecap Wireless Soil Moisture And Temperature Sensor - LoRaWAN® -pagination_label: Sensecap Soil Th -sidebar_label: Sensecap Wireless Soil Moisture And Temperature Sensor - LoRaWAN® -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/seeed-studio/sensecap-soil-th ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## SenseCAP Wireless Soil Moisture and Temperature Sensor - LoRaWAN® - -It measures soil volumetric water content (VWC) and temperature. It's designed with a 2-in-1 sensor -that integrates soil temperature and soil moisture, a custom battery and an IP66 enclosure, -optimized for outdoor use cases that need reliable data collection over years. - - - -### Resources - -- [Product Page](https://www.seeedstudio.com/LoRaWAN-Soil-Moisture-and-Temperature-Sensor-EU868-p-4316.html) -- [Datasheet](https://files.seeedstudio.com/products/317990687/res/LoRaWAN%20Gateway%20and%20Wireless%20Sensor%20Catalog-V1.6%20NEW.pdf) -- [Reseller - Mouser](https://www.mouser.com/ProductDetail/Seeed-Studio/101990565/?qs=wnTfsH77Xs6z38MfPrPBUw%3D%3D) -- [Reseller - Distrelec](https://www.distrelec.nl/en/sensecap-lorawan-wireless-soil-moisture-and-temperature-sensor-ip66-868mhz-seeed-studio-101990564/p/30167645?q=sensecap&pos=6&origPos=6&origPageSize=50&track=true) -- [Reseller - Seeed](https://www.seeedstudio.com/LoRaWAN-Soil-Moisture-and-Temperature-Sensor-EU868-p-4316.html) - -### Specifications - -#### Sensors: - -- moisture -- temperature - -#### Dimensions: - -- width: 56 mm -- length: 173 mm -- height: 56 mm - -#### Weight: - -- 415 grams - -#### Battery: - -- type: Lithium Thionyl Chloride (non-rechargeable) -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/sensedge/senstick-pro.mdx b/docs/use-the-network/devices/ready-to-use/sensedge/senstick-pro.mdx deleted file mode 100644 index 7fa654f10..000000000 --- a/docs/use-the-network/devices/ready-to-use/sensedge/senstick-pro.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: senstick-pro -title: Senstick Pro -pagination_label: Senstick Pro -sidebar_label: Senstick Pro -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/sensedge/senstick-pro ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Senstick Pro - -Microclimate Sensor for Harsh Environment - - - -### Resources - -- [Product Page](http://senstick.co) -- [Datasheet](http://senstick.co/downloads/Sensedge-SMC20-Datasheet.pdf) -- [Reseller - Concept13](https://www.concept13.co.uk/) -- [Reseller - Arcsgroup](https://thearcsgroup.com/) -- [Reseller - Sensational Systems](https://sensational.systems/) -- [Reseller - mydevices](https://mydevices.com/) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- pressure -- battery - -#### Dimensions: - -- width: 18 mm -- length: 210 mm -- height: 18 mm - -#### Weight: - -- 70 grams - -#### Battery: - -- type: AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/sensedge/senstick-pure.mdx b/docs/use-the-network/devices/ready-to-use/sensedge/senstick-pure.mdx deleted file mode 100644 index 1519f3e51..000000000 --- a/docs/use-the-network/devices/ready-to-use/sensedge/senstick-pure.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -id: senstick-pure -title: Senstick Pure -pagination_label: Senstick Pure -sidebar_label: Senstick Pure -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/sensedge/senstick-pure ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Senstick Pure - -Indoor Air Quality Sensor - - - -### Resources - -- [Product Page](http://senstick.co) -- [Datasheet](http://senstick.co/downloads/Sensedge-SIAQ30-Datasheet.pdf) -- [Reseller - Concept13](https://www.concept13.co.uk/) -- [Reseller - Arcsgroup](https://thearcsgroup.com/) -- [Reseller - Sensational Systems](https://sensational.systems/) -- [Reseller - mydevices](https://mydevices.com/) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- pressure -- tvoc - -#### Dimensions: - -- width: 18 mm -- length: 120 mm -- height: 18 mm - -#### Weight: - -- 50 grams - -#### Battery: - -- type: ER14505 -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/tektelic/t000489x-smart-room-base.mdx b/docs/use-the-network/devices/ready-to-use/tektelic/t000489x-smart-room-base.mdx deleted file mode 100644 index 1636fc563..000000000 --- a/docs/use-the-network/devices/ready-to-use/tektelic/t000489x-smart-room-base.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: t000489x-smart-room-base -title: Kona All-In-One Smart Room Sensor - Base Edition -pagination_label: T000489X Smart Room Base -sidebar_label: Kona All-In-One Smart Room Sensor - Base Edition -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/tektelic/t000489x-smart-room-base ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Kona All-in-One Smart Room Sensor - Base edition - -Multi-purpose LoRaWAN IoT sensor packed into a very small form factor - - - -### Resources - -- [Product Page](https://tektelic.com/catalog/smart-room-lorawan-sensor-base) -- [Datasheet](https://tektelic.com/public/uploads/Brochures/Smart%20Room%20Sensor.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- magnetometer -- accelerometer -- light -- moisture - -#### Dimensions: - -- width: 17 mm -- length: 42 mm -- height: 42 mm - -#### Weight: - -- 25 grams - -#### Battery: - -- type: CR2477B -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/tektelic/t00048xx-smart-room-pir.mdx b/docs/use-the-network/devices/ready-to-use/tektelic/t00048xx-smart-room-pir.mdx deleted file mode 100644 index 8e935a606..000000000 --- a/docs/use-the-network/devices/ready-to-use/tektelic/t00048xx-smart-room-pir.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: t00048xx-smart-room-pir -title: Kona All-In-One Smart Room Sensor - Pir Edition -pagination_label: T00048Xx Smart Room Pir -sidebar_label: Kona All-In-One Smart Room Sensor - Pir Edition -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/tektelic/t00048xx-smart-room-pir ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Kona All-in-One Smart Room Sensor - PIR edition - -Multi-purpose LoRaWAN IoT sensor packed into a very small form factor - - - -### Resources - -- [Product Page](https://tektelic.com/catalog/smart-room-lorawan-sensor-pir) -- [Datasheet](https://tektelic.com/public/uploads/Brochures/Smart%20Room%20Sensor.pdf) - -### Specifications - -#### Sensors: - -- temperature -- humidity -- magnetometer -- accelerometer -- light -- pir - -#### Dimensions: - -- width: 17 mm -- length: 42 mm -- height: 42 mm - -#### Weight: - -- 25 grams - -#### Battery: - -- type: CR2477B -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/tekzitel/tekzipark.mdx b/docs/use-the-network/devices/ready-to-use/tekzitel/tekzipark.mdx deleted file mode 100644 index 402a2067e..000000000 --- a/docs/use-the-network/devices/ready-to-use/tekzitel/tekzipark.mdx +++ /dev/null @@ -1,52 +0,0 @@ ---- -id: tekzipark -title: Tekzipark -pagination_label: Tekzipark -sidebar_label: Tekzipark -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/tekzitel/tekzipark ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## TEKZIPARK - -TEKZIPARK is a battery powered smart parking sensor to provide occupancy status updates of parking -spots wirelessly to your cloud environment. TEKZIPARK uses radar technology to detect vehicle -presence thereby providing a high degree of certainty of vehicle presence/absence. - - - -### Resources - -- [Product Page](https://tekzitel.com/product/tekzipark-lorawan-surface/) -- [Datasheet](https://tekzitel.com/prodspecs/TEKZIPARK-Specification_Data_Sheet_1_0_lorawan.pdf) - -### Specifications - -#### Sensors: - -- radar -- magnetometer -- temperature -- battery - -#### Dimensions: - -- width: 219 mm -- length: 219 mm -- height: 30 mm - -#### Weight: - -- 350 grams - -#### Battery: - -- type: C -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/the-things-products/the-things-node.mdx b/docs/use-the-network/devices/ready-to-use/the-things-products/the-things-node.mdx deleted file mode 100644 index 6cc7ca729..000000000 --- a/docs/use-the-network/devices/ready-to-use/the-things-products/the-things-node.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -id: the-things-node -title: The Things Node -pagination_label: The Things Node -sidebar_label: The Things Node -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/the-things-products/the-things-node ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## The Things Node - -The Things Node is an ideal LoRaWAN device to start prototyping your ideas without having to deal -with breadboards, wires and sensors. - - - -### Specifications - -#### Sensors: - -- accelerometer -- battery -- button -- humidity -- light -- temperature - -#### Battery: - -- type: 3x AAA -- replaceable: True - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/the-things-products/the-things-uno.mdx b/docs/use-the-network/devices/ready-to-use/the-things-products/the-things-uno.mdx deleted file mode 100644 index 1c742da92..000000000 --- a/docs/use-the-network/devices/ready-to-use/the-things-products/the-things-uno.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -id: the-things-uno -title: The Things Uno -pagination_label: The Things Uno -sidebar_label: The Things Uno -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/the-things-products/the-things-uno ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## The Things Uno - -The Things Uno is based on the Arduino Leonardo (not the Arduino Uno) with an added Microchip -LoRaWAN module. - - - -- [Reseller - Farnell](https://de.farnell.com/the-things-network/ttn-un-868/the-things-uno-eu/dp/2675815) -- [Video](https://www.youtube.com/watch?v=28Fh5OF8ev0) - -### Specifications - -#### Dimensions: - -- width: 53.3 mm -- length: 68.6 mm - ---- - -Content generated from [LoRaWAN-devices](https://github.com/TheThingsNetwork/lorawan-devices) diff --git a/docs/use-the-network/devices/ready-to-use/victor/victor-trap-v4xx.mdx b/docs/use-the-network/devices/ready-to-use/victor/victor-trap-v4xx.mdx deleted file mode 100644 index 0ee46816b..000000000 --- a/docs/use-the-network/devices/ready-to-use/victor/victor-trap-v4xx.mdx +++ /dev/null @@ -1,159 +0,0 @@ ---- -id: victor-trap-v4xx -title: Victor Trap V450 & V460 -pagination_label: Victor Trap V4Xx -sidebar_label: Victor Trap V450 & V460 -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/devices/ready-to-use/victor/victor-trap-v4xx ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Victor Trap V450 & V460 - -Self Provisioning Guide for Victor Connected Rodent Control Devices. - -The V450 is the "Electronic Mouse Trap", while the V460 is a significantly larger "Electronic Rat -Trap". The only difference is the longer & wider tunnel and rail spacing. ("Trap" is a euphemism -here. It does electrocute the rodents that enter the tunnel.) Both units share the same installation -and operation. - - - -:::info - -If you need any help provisioning this sensor, please join the `#console` channel on -[the Helium Discord Server](https://discord.gg/helium). - -::: - -### Resources - -[Manual](https://www.vlinkhq.com/instructions/V450-V460-Vlink-User-Manual-US.pdf) - -[Brochure](https://www.vlinkhq.com/images/VLink_Brochure.pdf) - -### Add device in Console - -To start, you'll need to create a Helium Console account and add your device. - -**Your trap vendor should have provided a corresponding `DevEUI`, `AppEUI`, and `AppKey` for each -delivered device.** Regrettably, these important values are not included anywhere in the box, -packaging, or unit labeling. If you did not receive these key values, you must contact the seller -and obtain them before proceeding. - -Once you have these three values, follow our -[quick start for instructions](/use-the-network/console/quickstart). - -Add a Label for your device, so that one shared configuration can be used by any additional devices -you install. - -### Victor VLINK Portal - -Victor has not published the a Payload decoder or data documentation for these traps, so you must -use the hosted monitoring solution at Woodstream's victorhq.com. - -:::info - -You will need an approved login at victorhq.com. In some cases, the device seller may have worked -with Woodstream to create an account for you at a pre-arranged email address, or you might have to -create one and wait for approval to use it. There is no way to complete this step yourself, as each -new account needs manual approval. - -::: - -Go to https://vlink.victorpest.com/ and select "Sign In" in the upper-right. **Do not** sign in at -"Registered Customers", but use the Admin Portal Login instead. Once your login is successful, you -must create a "Site" regardless of how solo simple your trap installation might be. Create a Site, -including a full floorplan with a Building, Floor, and Room. You can not add a Trap until you have -these defined. - -### Integration Configuration for VLINK - -Once you have added your device to Console, and a login and Site layout on VLINK Portal, you will -add an Integration to the Helium console to send data from your device to VLINK. - -#### Create HTTP Integration - -For your first trap, create a new HTTP integration in Console. Navigate to the Integrations page -using the left navigation and then select the HTTP integration. - - - -Next we'll fill in the details, see instructions and image below. - -1. Enter the VLINK Endpoint URL: - `https://ibgsq3pdbl.execute-api.us-west-2.amazonaws.com/default/console-to-victormouse-translator` -2. Enter the HTTP Header - Key: `x-api-key` and Value: `peKuqRvLce7CuqUE0EkR1aE9bt0Hy3nJnYSh7yM3` -3. Enter the name for this Integration: _VLINK Integration_ -4. Finally, click _Add Integration_ to complete. - - - -#### Create a Flow to connect trap Devices to the Integration. - -On the Helium Console, select Flows. Add a Node using the Label you assigned your Device. Add a node -for the _VLINK Integration_ and draw a connecting line from the Label to the Integration. The solid -line will change to a dotted line to indicate data is flowing. - -### Add Device to VLINK Platform - -You are now ready to add your device to VLINK, using the App or VLINK Portal interface. For this -step, you will use a (non-Helium) serial-number provided by Victor and shown on the QR Sticker -inside the trap. This is likely to be a 15-character identifier that starts with `LM`, entered -manually or by QR code. - -The App will guide the onboarding process and provide instruction for when to turn the device on. -Pause there to set up Console observation. - -#### Power up the device - -Install the (included) Lithium AA Batteries and close the bottom panel with the included screws, -fully sealing the weatherproofing gasket. Before powering on the device, open the Helium Console, -select the Device, and open the Debug panel or scroll down to the recent Packet list to observe -activity. - -Power on the unit by pressing the power button. You should see a few LED blinks from the middle -indicator near the power button, and also see initial data packets in the Console Device listing. - -If you do not see any Join or Uplink packets, pause here and ensure the unit is correctly added in -Console. Double-check each of the three key values. Once you see packets arriving from your unit, -you are ready to continue with registration and naming, add it to a Site/Building/Floor/Room in the -Portal, bait the trap and wait for victory over rodents. - -### FAQ - -#### What does ErrorCode in the Event Log mean? - -- ErrorCode: 0 = Lid Closed -- ErrorCode: 1 = Lid is Open - -#### What sequence of messages should I expect (in Console)? - -1. Series of 10-15 messages - These include network join, power up status, other status messages -2. Then 5 messages 10 minutes apart -3. Then a status message every 23 hours - -These messages are sent with Acknowledgement requested, so you will see both `Uplink` and -`Acknowledge` packets. - -#### What sequence of messages should I expect in the VLINK dashboard? - -In the `Activity Log` you will see "Trap Powered Up" and a series of "Trap Status" logs. - -#### What are the button presses? - -If unit is off: - -- Pressing the button will turn it on and initialize the unit - -If unit is on: - -- 1 quick button press will send a status message -- 1 Long button press will turn the unit off - -Note that there is only one button (Power) and the adjacent indicator is a Blue LED that flashes on -network activity. It is not a button. diff --git a/docs/use-the-network/find-a-lns-provider.mdx b/docs/use-the-network/find-a-lns-provider.mdx deleted file mode 100644 index 73cb1d883..000000000 --- a/docs/use-the-network/find-a-lns-provider.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: find-a-lns-provider -title: Find a LoRaWAN Network Server Provider -pagination_label: Find a LoRaWAN Network Server Provider -sidebar_label: Find a LoRaWAN Network Server Provider -description: Find a LoRaWAN Network Server Provider -image: https://docs.helium.com/img/link-image.png -slug: /find-a-lns-provider ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## Which OpenLNS Providers Can I Use?​ - -Professional hosting companies can provide support and immediate access to a ready-to-go -connectivity platform. LNS Services will vary in price, support, and features depending on the -company. Companies may offer public shared servers, and/or private servers. - -The following providers within the OpenLNS initiative offer multi-tenant and private instances to -businesses and individuals. - -| Company | Service Region | Servers Shared/Private | Public Server Location | Pricing Model | -| ---------------------------------------------------------- | -------------- | --------------------------- | ---------------------- | -------------------------------------------------------------------------------------------------- | -| [Helium IoT Europe][ingeniousthings] (by Ingenious Things) | Global | Shared & Private by request | Europe | [Pay-per-message][hnt-iot-pricing] for public or pay-per-month for private and additional support. | -| [BrDot][brdot] | Americas | Shared & Private by request | Brazil | Fixed monthly for active devices plus message plan for public & private service. | -| [Qnectd][qnectd] | Global | Shared & Private by request | Eastern Europe | Per-device monthly subscription cost, custom for private servers. | -| [Parley Labs][parley-labs] **(Coming Soon)** | USA | Shared & Private by request | USA | Contact for pricing. | -| [MeteoScientific][meteoscientific] (by Gristle King Inc) | USA | Publicly Accessible | Europe | Pay-per-message for public use, otherwise use Helium IoT Europe above | - -If you offer public LNS services and would like to add your company to this list, please make a pull -request and include information for each listed field. - -:::info - -The Helium Foundation is not directly associated with the vendors above and makes no endorsements -about the quality of their offering. For more details including pricing, please reach out to the -given provider. - -::: - -[brdot]: https://brdot.com.br/ -[hnt-iot-pricing]: https://www.helium-iot.eu/use-helium-with-helium-iot-europe/ -[ingeniousthings]: https://www.ingeniousthings.fr/ -[parley-labs]: https://parleylabs.com/ -[qnectd]: https://qnectd.com/ -[meteoscientific]: https://console.meteoscientific.com/front/ diff --git a/docs/use-the-network/lorawan-network-servers.mdx b/docs/use-the-network/lorawan-network-servers.mdx deleted file mode 100644 index 9aabcb902..000000000 --- a/docs/use-the-network/lorawan-network-servers.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -id: lorawan-network-servers -title: LoRaWAN Network Servers -pagination_label: LoRaWAN Network Servers -sidebar_label: LoRaWAN Network Servers -description: LoRaWAN Network Servers -image: https://docs.helium.com/img/link-image.png -slug: /lorawan-network-servers ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -## What is an LNS? - -An LNS (LoRaWAN Network Server) is a vital component of a LoRaWAN network. Key functions include -device management, message routing, and integration with application servers. Network servers play a -crucial role in ensuring the scalability, reliability, and interoperability of LoRaWAN networks. - -## What is the OpenLNS Initiative? - -​The OpenLNS initiative allows anyone looking to deploy devices on the Helium Network to use any -LoRaWAN Network Server (LNS). The LNS you choose must comply with the LoRaWAN specification to -access the Helium Network. - -OpenLNS will deliver the following network improvements: - -1. Increased accessibility -1. Accelerated device joins and a focus on increased speed -1. Increased reliability -1. Enabling massive scalability - -[The OpenLNS Initiative.][open-lns] - -## Connect and Manage Devices on Helium - -There are a couple of options to get started onboarding devices and connecting through a Helium LNS: - -### Work with a Professional LNS Service Provider - -Professional hosting companies can provide support and immediate access to a ready-to-go -connectivity platform. LNS Services will vary in price, support, and features depending on the -company. Companies may offer public shared servers, and/or private servers. - -[Find a Helium LNS Server Provider.][find-provider] - -### Host Your Own LNS - -If you are comfortable setting up, configuring, and managing your own servers and plan to -self-manage your entire solution in-house, hosting your own LNS could be a good option for you. Note -that this requires expertise and ongoing hosting expenses. - -[Run an LNS.][run-lns] - -[find-provider]: /find-a-lns-provider -[run-lns]: /iot/open-lns-quickstart -[open-lns]: /iot/open-lns diff --git a/docs/use-the-network/roaming.mdx b/docs/use-the-network/roaming.mdx deleted file mode 100644 index 3d74300f3..000000000 --- a/docs/use-the-network/roaming.mdx +++ /dev/null @@ -1,195 +0,0 @@ ---- -id: roaming -title: Helium Roaming Services -pagination_label: Helium Roaming Services -sidebar_label: Helium Roaming Services -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/roaming ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Helium Roaming Services enables public and private LoRaWAN Network providers around the world to -leverage Helium’s ubiquitous coverage. - -With over 993K Hotspots in 190 countries and growing, the Network sees a massive amount of -non-Helium packets. When Network providers enter a roaming partnership with Helium, this traffic can -be forwarded via the Helium Network to partners, increasing their level of service and coverage. - -Any compatible device can send data to their Home Network through Helium-compatible Hotspots without -the need for device configurations or firmware updates. - -## Getting Started - -- **Create an Account** - Contact a Helium Network Advisor to create the initial Helium Roaming - Services account (sales@nova-labs.com). Initial setup requires an Organization name, and an email - address for the administrator. As part of the initial account creation process, Net ID ownership - must be verified for the roaming partner. -- **Add Users** - An administrator can add other user accounts with various roles as needed. -- **Purchase Data Credits** - Data Credits (DCs) are needed to pay for packets sent on the Helium - Network and can be purchased with a credit card or burning HNT. -- **Configure Network Integration** - Specify the Home network Server address and port, input - roaming device join credentials, and define how many packets to purchase for devices. -- **Set up Alerts** - Set up email alerts to send to different user roles based on a number of - conditions including Data Credit balance, user management, or payment methods. - -## Users & Organizations - -Administrators can add invite users to Organizations via email. Users can be given different access -levels using roles (administrators, managers, and read-only users). - -### Adding Users - -User roles include: - -- `Administrators` can perform all actions -- `Managers` have the same permissions as administrators, but cannot add organizations, manage - users, or Data Credits -- `Read-only` users cannot take any actions - -**To add a new user** - -- On Console navigate to the **Users** page, and click **+ Add User**. A pop-up appears. -- Type the email of the new user, and select their desired access level. -- Hit **Submit**. An email invitation is sent that allows a user to join the organization. - -### Managing Organizations - -Organizations allow users to manage multiple roaming servers using the same account. An Organization -is a virtual container with its own users, Data Credit balance, and configurations. - -**Note:** Data Credits can be transferred among Organizations, see Purchasing Data Credits. - -**To add a new Organization** - -- On Console navigate to the **Organizations** page, and click **+ Add Organizations**. A pop-up - appears. -- Type the unique name of the Organization. -- Hit **Submit**, the Organization appears. - -## Data Credits - -Data Credits (DCs) are needed to pay for packets sent on the Helium Network. Every 24 bytes sent in -a packet costs 1 DC which equals $0.00001. - -### Purchasing Data Credits - -Obtaining Data Credits is the same as on the Helium Console focused on device management and -onboarding. Users can use a credit card (recommended method) and set up a recurring payment or burn -HNT. For a video tutorial of how to purchase Data Credits on Console, check out our Tips & Tricks -video [here](https://youtu.be/jyMGLymuOCE). - -In addition to purchasing Data Credits, users can transfer Data Credits among Organizations under -the same account. - -To transfer Data Credits (same account only with multiple Organizations): click **Data Credits**, -and hit **Transfer DC to Org**. On the pop up, enter the quantity of Data Credits to transfer and -receiving Organization. Click **Make Transfer**. - -Further reading: how Data Credits fit into Helium Tokenomics -[here](/hnt-token/#data-credits-and-burn-and-mint-economics). - -## Configurations - -There are a number of configurations required to successfully roam on Helium including: - -- Configuring the Home Network Server address and port number -- Adding roaming device join credentials -- Specifying how many packets to purchase for devices - -### Configuring Integrations - -To configure the Helium Roaming Service with a LoRaWAN Network Server a user needs to provide the -address of the Home Network Server and the port number. - -On Console, click Configuration and enter the Address (for example yournetworkserver.com) and port -number (for example `1700`) of the Home Network Server - -### Adding Device Credentials - -Any device that roams on the Helium Network needs to be added to the Configuration page. - -Join credentials can be added using multiple methods. Click **Configuration**, and to: - -- **Add an individual device**: choose **+Add Join Credential** and enter the device DevEUI and APP - EUI -- **Import devices with a CSV file**: choose **use CSV File**. To structure the CSV file, add - app_eui, dev_eui in the header row, followed by rows of the corresponding values. -- **Use a wildcard**: Rather than adding each device, DevEUI’s mapped to a single AppEUI can be - added using an asterisk wildcard `*`. Choose **+Add Join Credential** and enter `*` for the DevEUI - field along with the specific AppEUI. Each new AppEUI requires a new entry. - -### Purchasing Multiple Packets - -The Multiple Packets feature provides the ability to pay for additional packets (if available) for -redundancy and location triangulation purposes. - -To enable multiple packet purchase, click **Configuration**, and enter the number of desired -packets. Note: additional packets can only be purchased if multiple Hotspots "hear" and send the -same packet. By default, only `1` packet is purchased. - -## Alerts - -Email alerts can be set up for a number of conditions related to Data Credit balance, user -management, or payment methods. User types (e.g., Administrator or Managers) can be specified to -receive alerts. - -### Setting Up Alerts - -To set up email alerts: click **Alerts**, choose alert and user role to receive alerts. - -## Sample JSON - -Here are some sample JSON payloads that roaming partners can expect to receive on their roaming -endpoint. - -### Sample Uplink - -```json -{ - "MessageType": "PRStartReq", - "PHYPayload": "0x8041FD26E0800B0001932DE4E3AAC35CD0", - "ProtocolVersion": "1.1", - "ReceiverID": "0x000000", - "SenderID": "0xC00053", - "SenderNSID": "", - "TransactionID": 336746616, - "ULMetaData": { - "DataRate": 4, - "DevAddr": "0xAABBCCDD", - "FNSULToken": "0x3131334C6D4A7167434376765464585032467450564E616B5A5871576A7A6E4A6F76715863665A69664D745046796A666463623A45553836383A353838313637383235", - "GWCnt": 1, - "GWInfo": [ - { - "DLAllowed": true, - "ID": "0xCD70F2C5E437B2BB", - "Lat": 44.8594, - "Lon": -0.586, - "RFRegion": "EU868", - "RSSI": -127, - "SNR": -8.5 - } - ], - "RFRegion": "EU868", - "RecvTime": "2022-06-09T15:45:42Z", - "ULFreq": 867.7 - } -} -``` - -### Sample Downlink - -```json -{ - "DLFreq2": 869.525, - "MessageType": "XmitDataAns", - "ProtocolVersion": "1.1", - "ReceiverID": "0x000000", - "Result": { - "ResultCode": "Success" - }, - "SenderID": "0xC00053", - "TransactionID": 7627 -} -``` diff --git a/docs/use-the-network/run-a-network-server/buy-an-oui.mdx b/docs/use-the-network/run-a-network-server/buy-an-oui.mdx deleted file mode 100644 index 4db87c3cd..000000000 --- a/docs/use-the-network/run-a-network-server/buy-an-oui.mdx +++ /dev/null @@ -1,207 +0,0 @@ ---- -id: buy-an-oui -title: Buy An Organizationally Unique Identifier -pagination_label: Buy An Organizationally Unique Identifier -sidebar_label: Buy an Organizationally Unique Identifier -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/run-a-network-server/buy-an-oui ---- - -## What is an OUI? - -Each LoRaWAN Network Server (LNS) on the Helium Network acquires an Organizationally Unique -Identifier ("OUI"). This registers the LNS with the blockchain and allocates two very important -routing objects owned and maintained by the OUI operator: - -- up to five **filters**, describing the sets (AppEUI, DevEUI) expected by the LNS -- one or more **slabs** of DevAddrs, reserving an address space for the OUI's devices on the Helium - Network - -A device, defined by (AppEui, DevEui), can be allocated any of the DevAddrs owned by the OUI. It is -even possible to multiplex many devices on the same DevAddr at the same time, using the Message -Integrity Check (MIC) to disambiguate. - -:::info - -Based on benchmarking tests the upper limit for a DevAddr `1024` slab is approximately 5800 devices, -but results still need to be replicated and bracketed. Community members are encouraged to run their -own benchmarking tests. Instructions -[here](/use-the-network/run-a-network-server/router-benchmarking). Requires basic familiarity with -Linux and Bash command-line. - -::: - ---- - -## Pricing - -The OUI is purchased with [Data Credits (DC)](/blockchain/transaction-fees). Costs are subject to -change, but currently the OUI itself costs US$100 worth of DC and each DevAddr cost an additional -US$100 in DC. - -DevAddr are sold in sequential blocks between 8 and 65,536 and any power of two. - -You must purchase a slab when purchasing an OUI, therefore, the total minimum cost is US$900 worth -of Data Credits: $100 for the OUI itself and $800 for eight DevAddr's. - -[The OUI purchase transaction itself](https://github.com/helium/proto/blob/master/src/blockchain_txn_oui_v1.proto) -incurs a fee based as does any other blockchain transaction; generally this will be $0.35-1.00 worth -of DCs based on how the fields get filled and change the transaction size. - ---- - -### Purchase Transaction - -:::info Current Process - -Please send an email to [hello@helium.foundation](mailto:hello@helium.foundation) to purchase an -OUI. - -::: - -
-Legacy Process - -You need [the Helium wallet](https://github.com/helium/helium-wallet-rs) to go any further. You'll -want to [create a wallet](https://github.com/helium/helium-wallet-rs#create-a-wallet) and to have at -least US$900 in HNT (based on current HNT Oracle pricing). - -Submit a "create OUI" transaction: - -```bash -./helium-wallet oui create --subnet-size 8 -``` - -The filter is a dummy filter to initialize the OUI. When you get Console running, it will -automatically maintain it. You can once again track the transaction with the endpoint above. When it -is complete, you should also see your OUI as the most recently purchased and -[on the list here](https://api.helium.io/v1/ouis). - -Congratulations! You are the proud owner of a Helium Network OUI. OUIs are numbered sequentially, so -the lower you are, the earlier you were on the Network! - -
- ---- - -## DevAddr Explained - -Device addresses or `DeviceAddr` are assigned to a device by the LNS during the join procedure -[See LoRaWAN Spec here for more info about Joins](https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-3/). - -### Why & when should I purchase more `DeviceAddr`? - -When starting up your Helium LNS (Router / Console) you will probably be wondering, how many -`DeviceAddr` do you need? This depends on a few factors: - -1. number of devices -1. location / concentration of devices - -To better figure out the right number for you, you will need to understand how `DeviceAddr` are -assigned to Devices by Router. - -### Couple things to know before - -First you will need a basic understanding of the location system used by the Helium Network -[Full Description](/wallets/app-wallet/hexagons/). If you are aware of `H3 Indexes` & `Hexagons` you -can skip this. - -Then let's talk about the offer / purchase machanism on the Helium Network. - -The Helium Network (HN) is not your "typical" LoraWan Network in which a Hotspot (or Gateway) will -send its packets to an LNS directly and for "free". In the HN, a Hotspot will make an offer to the -appropriate LNS and if said LNS decided to purchase it, the hotspot will then deliver the "full" -packet to the LNS. Note that the LNS can refuse an offer from a Hotspot if it thinks that it is not -interested by the data from this device. - -:::info - -Offers only contain: - -- the routing information for a packet (`DeviceAddr` for uplinks or `EUIs` for join) -- a hash of the packet, to not reveal its content but still be uniquely trackable by the LNS -- the Hotspot it came from - -::: - -:::info - -Note that a Console Organization is only ever charged when a packet is received and properly -identified. Only Router's balance is charged during the offer / purchase process. - -::: - -### Assigning a `DeviceAddr` - -When a device joins the Helium Network it is assigned a `DeviceAddr` based on the location of the -hotspot that the device is communicating through. Router will lookup the hotspot's location and find -its parent hexagon at [resolution 3](https://h3geo.org/docs/core-library/restable/) (resolution 3 is -the default value but it can changed via the env variable `ROUTER_DevAddr_ALLOCATE_RESOLUTION`) it -will then assign the lowest `DeviceAddr` in its slab to the device. If another device was to join in -the same hexagon it would get the following `DeviceAddr` in the slab, ex: -`Device1 -> DevAddr1, Device2 -> DevAddr2`. - -:::info - -At resolution 3 (Average Hexagon Edge Length: 59.8 km), they are `41,162` unique hexagon in the -world, so a slab of `8 DeviceAddr` would provide `41,162 * 8 = 329,296` devices, see -[doc](https://h3geo.org/docs/core-library/restable/). - -::: - -The maybe not so obvious problem here is: what if you have more devices than `DeviceAddr` in one -Hexagon? This is when conflicts can happen. A `DeviceAddr` conflict is when Router receives an offer -but cannot be entirely sure if the offer is from for `Device1` or `Device9`: - -#### Example - -You have 2 devices `Device1` and `Device9` both sending through the same hotspot and therefor in the -same resolution 3 hexagon. As we have 9 devices that have joined in the Hexagon, the assignment -rolled back to the first `DeviceAddr` and gave `Device9` the same `DeviceAddr1` as `Device1`. - -- Assignment - `Device1 -> DevAddr1, Device2 -> DevAddr2, ..., Device8 -> DevAddr8, Device9 -> DevAddr1`. -- Scenario: `Device1` is sending an uplink. - -At this point 2 things can happen: - -1. The Router identified the offer from the hotspot to be from `Device1`. The Router can then - process the offer accordingly. -2. The Router **misidentify** the offer thinking that it is from `Device9` (as they both share - `DeviceAddr1`) - 1. If Router deems offers associated with `Device9` worthy of purchasing, the offer will be - purchased and then the packet will be properly identified via the `MIC` (Message Integrity - Code, - [see LoraWan spec for more info](https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-3/) - ). This is essentially a conflict with **happy path**. - 2. If Router does not deem offers associated with `Device9` worthy of purchasing (e.g. maybe - `Device9` was de-activated by a user in Console, or maybe `Device9`'s Console Organisation ran - out of [Data Credit](/data-credit)) the offer will be rejected and data never delivered. This - is a conflict with **non-happy path**. - -The non-happy path is fairly rare as Router will do its best to find out the right device but this -is where buying extra `DeviceAddr` can help prevent bad conflicts. - -This should help you figure out the number of `DeviceAddr` that is right for you. - -:::info - -Moving devices can trigger the same effect as well as they can get an assigned `DeviceAddr` in our -Hexagaon and move to another one, potentially causing a conflict as specified above. - -::: - ---- - -## Tools - -### DevAddr - -1. `curl http://localhost:3000/DevAddr/json` get all DevAddr assignment in json format -2. Input them in https://kepler.gl/demo - -### CLI - -- `router info device ` find every conflicts for a device -- `router info hotspot ` find every conflicts for a hotspot diff --git a/docs/use-the-network/run-a-network-server/debug-with-sniffer.mdx b/docs/use-the-network/run-a-network-server/debug-with-sniffer.mdx deleted file mode 100644 index d5d0000c0..000000000 --- a/docs/use-the-network/run-a-network-server/debug-with-sniffer.mdx +++ /dev/null @@ -1,316 +0,0 @@ ---- -id: debug-with-sniffer -title: Debug With Sniffer -pagination_label: Debug With Sniffer -sidebar_label: Debug With Sniffer -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/run-a-network-server/debug-with-sniffer ---- - -# Debug With Sniffer - -Confirm router runtime behavior using a virtual LoRaWAN device with a software-based protocol -sniffer. - -## Dependencies - -1. Ensure [Router](https://github.com/helium/router.git) is running and - [Console](https://github.com/helium/console.git) is connected to it. -2. The wallet to be used requires enough HNT to burn for joining the virtual device to the network. - - It's the same fee as for a physical device. - - See [Setup Data Only Hotspot](/hotspot-makers/iot/data-only-hotspots/#transactions--cost) -3. Clone each of these repos: - - [virtual-lorawan-device](https://github.com/helium/virtual-lorawan-device) - - [lorawan-sniffer](https://github.com/helium/lorawan-sniffer) - - [gateway-rs](https://github.com/helium/gateway-rs) - - [helium-wallet-rs](https://github.com/helium/helium-wallet-rs) - -Those packages require [Rust](https://rust-lang.org/) when building from source. You will also need -to install [Cmake](https://cgold.readthedocs.io/en/latest/first-step/installation.html). If some of -the following commands fail, try using sudo. - -Everything may run locally on a laptop/workstation, or use just the Rust-based tools locally for -connecting to a remote Router & Console. - -## Overview - -The approximate sequence: - -1. Create a virtual device -2. Use the wallet to pay for joining a device to the network -3. Device gets added via Console, which then will be "pending" for about 15 minutes -4. Start local data-only hotspot -5. Configure sniffer to use that hotspot -6. Connect the virtual device to sniffer -7. Wait for "pending" to resolve on Console -8. Finally, the virtual device joins the network - -Order of operations below is significant. - -# Setup - -## Compile - -Because there are multiple repos each in their own subdirectory, examples below assume everything is -located beneath the `~/helium/` path. - -Ensure everything compiles successfully. - -Run: - -```bash -cd ~/helium/ - -git clone https://github.com/helium/helium-wallet-rs.git -cd helium-wallet-rs/ -cargo build --release - -cd .. - -git clone https://github.com/helium/gateway-rs.git -cd gateway-rs/ -cargo install cargo-make -cargo build --release - -cd .. - -git clone https://github.com/helium/virtual-lorawan-device.git -cd virtual-lorawan-device/ -cargo build --release - -cd .. - -git clone https://github.com/helium/lorawan-sniffer.git -cd lorawan-sniffer/ -cargo build --release -``` - -Those may be built in any order but are in sequence as used below. - -## Confirm Wallet Balance - -Later steps require the command-line interface (CLI) version of a wallet. - -For using a wallet already attached to an existing hotspot, that wallet can be -[connected](https://github.com/helium/helium-wallet-rs#create-a-wallet) to this one using the -`--seed` option. - -Run: - -```bash -cd ~/helium/helium-wallet-rs/ -./target/release/helium-wallet create basic -``` - -Follow its [README](https://github.com/helium/helium-wallet-rs) or other -[instructions](/hotspot-makers/iot/data-only-hotspots/) for creating and **funding this wallet**. - -View details of the _funded_ CLI wallet: - -```bash -./target/release/helium-wallet info -``` - -See `Balance` field, and confirm having enough HNT to burn 1000000 (six zeros) data credits. One -whole HNT is more than sufficient with prevailing exchange rates in early 2022. - -Copy the value from the `Address` field: `WalletADDRESS...` will be used as the example in excerpts -below. - -## Join Hotspot To Network - -Use the `WalletADDRESS...` from the earlier wallet "info" command. - -Arguments to both the owner and payer options will be your wallet address (as with a self-signed -certificate). - -As of v1.0, gateway-rs requires running in server-mode in the background: - -```bash -cd ~/helium/gateway-rs/ -./target/release/helium_gateway server & -gw_pid=$! -``` - -Generate transaction: - -```bash -./target/release/helium_gateway add --mode dataonly \ - --owner WalletADDRESS... \ - --payer WalletADDRESS... -``` - -Output from that command will include a transaction ID associated with the `txn` field. Copy this -value (without quotes) which is referred to as `TxnID...` below for use with the CLI wallet. - -Stop the gateway service for now: - -```bash -kill $gw_pid -# or -killall helium_gateway -``` - -The gateway service will be started below, after adding the device. - -## Join Hotspot Using Wallet - -Use the `TxnID...` from the previous step. - -Add the hotspot to the network, which requires burning data credits (DC) and must use the CLI -wallet. - -Always perform a dry-run (_without_ the commit flag) first: - -```bash -cd ~/helium/helium-wallet-rs/ -./target/release/helium-wallet hotspots add TxnID... -``` - -Confirm that the staking fee in DC is `1000000` (six zeros), and then repeat same command plus -`--commit` flag: - -```bash -!! --commit -``` - -## Console - -Log on to Console, and [create a new device](/use-the-network/console/adding-devices/). - -When successful, Console should indicate "Pending" for this device. - -This _pending_ status persists until the next XOR operation by the Router, **which may take 15 -minutes** or so. - -Both the sniffer and virtual device may be configured during this wait. - -Get the following values from Console for your device: - -1. Device EUI -2. App EUI -3. App Key - -(You may also want the "Device ID" for tracing via SSH session on the router instance itself.) - -Each value gets associated with the appropriate key in different configuration files for sniffer and -virtual device. - -## Configure Virtual LoRaWAN Device - -Using those same values from Console, each value should be associated with the appropriate key -within a **TOML** file: `~/helium/virtual-lorawan-device/settings/settings.toml` - -Example: - -```toml -[device.one.credentials] -dev_eui = "DevEUIHexValue..." -app_eui = "AppEUIHexValue..." -app_key = "AppKeyLongHexValue..." - -[packet_forwarder.default] -host = "localhost:1680" -``` - -While editing that TOML file, also indicate that it should talk to your instance of `gateway-rs` as -the packet-forwarder (typically on IP Port `1680`). - -Keep the `defaults.toml` file unmodified for ease of `git pull` in future. - -## Configure LoRaWAN Sniffer - -Each value above from Console should be associated with the appropriate key within a **JSON** file: -`~/helium/lorawan-sniffer/lorawan-devices.json` - -Example: - -```json -[ - { - "dev_eui": "DevEUIHexValue...", - "app_eui": "AppEUIHexValue...", - "app_key": "AppKeyLongHexValue..." - } -] -``` - -## Wait For XOR - -Again: the Console may indicate "Pending" from having added the new device. - -Wait until that message clears before proceeding. - -# Live Debugging - -There will be _a lot_ of output from each command, so consider using separate Terminal tabs/windows. - -## Start Hotspot - -Run in its own Terminal window: - -```bash -cd ~/helium/gateway-rs/ -./target/release/helium_gateway -c config server -``` - -## Start Sniffer - -Run in its own Terminal window: - -```bash -cd ~/helium/lorawan-sniffer/ -./target/release/lorawan-sniffer sniff --host 127.0.0.1:1680 \ - --log-trace session.csv -``` - -(The session log may be replayed later with: `./target/release/lorawan-sniffer replay session.csv`) - -**Note:** If the gateway restarts, the sniffer may need to be restarted also. - -## Start Device - -Run in its own Terminal window: - -```bash -cd ~/helium/virtual-lorawan-device/ -./target/release/virtual-lorawan-device -``` - -Each start of this program begins with a fresh LoRaWAN Join, so expect to see a matching Join-Accept -response from the router. - -Consider making changes to settings within -[configuration profiles](/use-the-network/console/profiles/) in Console for this device, such as -`rx_delay`. - -## Router Trace - -This is optional. - -From Console, get the "Device ID" value, which is a UUID string. - -Run in its own Terminal window: - -```bash -ssh router-dev -``` - -Start tracing for your device: - -```bash -router device trace --id=4e698917-b44c-abcd-b258-afaf579a2099 -``` - -When finished, conclude tracing for your device: - -```bash -router device trace --id=4e698917-b44c-abcd-b258-afaf579a2099 --stop -``` - -Or extract from logs in the usual way: - -```bash -grep 4e698917-b44c-abcd-b258-afaf579a2099 /var/data/log/router.log -``` diff --git a/docs/use-the-network/run-a-network-server/deploy-console.mdx b/docs/use-the-network/run-a-network-server/deploy-console.mdx deleted file mode 100644 index 0eba5ea47..000000000 --- a/docs/use-the-network/run-a-network-server/deploy-console.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -id: deploy-console -title: Deploy Console -pagination_label: Deploy Console -sidebar_label: Deploy Console -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/run-a-network-server/deploy-console ---- - -# Deploying Console - -Getting [Console](https://github.com/helium/console) deployed is very similar to -[running Console](/use-the-network/run-a-network-server/run-console/). Go ahead and follow that -guide up to **Run it!**. - -## Encryption - -Auth0 requires being run over https. You can get a certificate on your server through -[Let's Encrypt](https://letsencrypt.org/getting-started/) by following -[this certbot guide](https://certbot.eff.org/instructions). - -"My HTTP website is running 'Web Hosting Product' on 'Ubuntu 18.04 LTS (bionic)'" Was used when -writing this guide. Follow the steps, and note where your certificates are placed, they'll be used -later in nginx. - -## Docker - -Grab the server docker-compose file - -``` -cp templates/docker-compose-quay.yaml docker-compose.yaml -``` - -This docker-compose offers an nginx container to proxy traffic through. - -If letsencrypt put your certificate in a place other than `/etc/letsencrypt/`, be sure to update the -`volumes` for the nginx container in `docker-compose.yaml`. - -## Nginx - -Copy the nxinx config - -``` -cp templates/nginx-default.conf nginx.conf -``` - -Edit `nginx.conf` and fill in your certificates name. - -## Run It! - -`docker-compose up` builds Console and launches it with three other containers: Router, Postgres, -and Nginx. You might see `helium_router` crash a few times as it waits for `helium_console` to start -up and allow the socket connection between the two. - -If you go to your host name, you should have an auth0 login available to you. Just as a heads up, -all of your important data is in the `data` in this `console` directory. diff --git a/docs/use-the-network/run-a-network-server/router-benchmarking.mdx b/docs/use-the-network/run-a-network-server/router-benchmarking.mdx deleted file mode 100644 index 4e48bd895..000000000 --- a/docs/use-the-network/run-a-network-server/router-benchmarking.mdx +++ /dev/null @@ -1,1051 +0,0 @@ ---- -id: router-benchmarking -title: Router Benchmarking -pagination_label: Router Benchmarking -sidebar_label: Router Benchmarking -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/run-a-network-server/router-benchmarking ---- - -# Router Benchmarking - -This measures load by increasing LoRaWAN traffic in steps on a -[Helium Router](https://github.com/helium/router) to find its threshold of capacity for a given -server instance. - -Measuring capacity of a particular server instance may then be compared with another server instance -with different hardware specs. The procedure used is _load & capacity measurement_ but some people -also refer to this as _stress testing_ or _performance testing_. - -This document also gives insight to interactions of routers, gateways, organizations, devices and -wallets in production. - -For these instructions, each dependency is installed beneath `~/helium/`, and **Bash** shell syntax -on Linux is used below. - -**Order of operations is significant.** - -Challenges can arise due to the nature of simulation, much like watching the shadows of Plato's -_Allegory of the Cave_ rather than seeing the true cause. Therefore, any defects observed or -suspected should be [flagged](https://github.com/helium/router/issues) by the community-- please! -Then we all benefit from the corrections. - -## Dependencies - -These **must be isolated** instances dedicated to load & capacity testing, as other users of the -system _will_ be negatively impacted as well as yield meaningless benchmarks: - -- [router](https://github.com/helium/router) - - Must be an isolated instance because **abuse-prevention measures** get triggered - - Set environment variables: `ROUTER_HOTSPOT_REPUTATION_ENABLED=false` and/or - `ROUTER_HOTSPOT_REPUTATION_THRESHOLD` to a large integer - - Set environment variable: `ROUTER_SC_OPEN_DC_AMOUNT=1000000` or higher integer value for budget - per State Channel - - By using an ed25519 key for router's wallet, it can be also used for hotspot add and location - assertion -- [console](https://github.com/helium/console) - - Set environment variable: `IMPOSE_HARD_CAP=false` - - Ensure `MAX_DEVICES_IN_ORG` exceeds number of virtual devices - -Install wallet on same host as your router if sharing its private key: - -- [helium-wallet](https://github.com/helium/helium-wallet-rs) - - Use a wallet with minimal funding **as assurance to avoid overspending** - -These may be run locally on your laptop/workstation within their respective build subdirectories: - -- [gateway-rs](https://github.com/helium/gateway-rs) -- [helium-console-cli](https://github.com/helium/helium-console-cli) -- [gwmp-mux](https://github.com/helium/gwmp-mux) LoRaWAN protocol multiplexer -- [virtual-lorawan-device](https://github.com/helium/virtual-lorawan-device) - -Additional utilities, possibly already installed on your system: - -- [jq](https://github.com/stedolan/jq) - -## Aliases & Vars - -Our working directory is `~/helium/benchmark/`. - -```bash -WORKDIR=~/helium/benchmark -``` - -Convenience aliases: - -```bash -alias helium-console-cli="~/helium/helium-console-cli/target/release/helium-console-cli" -alias helium_gateway="~/helium/gateway-rs/target/release/helium_gateway" -alias helium-wallet="~/helium/helium-wallet-rs/target/release/helium-wallet" -alias gwmp-mux="~/helium/gwmp-mux/target/release/gwmp-mux" -alias virtual-lorawan-device="~/helium/virtual-lorawan-device/target/release/virtual-lorawan-device" -``` - -Define base URLs as shell variables: - -```bash -# development versus production, respectively: -API_URL=https://api.helium.wtf -API_URL=https://api.helium.io - -# Console corresponding to router-dev: -CONSOLE_URL="https://helium-console-dev.herokuapp.com" - -# router-dev: -ROUTER_URL="http://54.176.88.149:8080" -# Optionally defined via script below: -ROUTER_OUI=2 -``` - -Convenience variables: (After a few preliminary runs, significantly increase the following values) - -```bash -# number of organizations: -N_ORGS=2 - -# number of gateways: -N_GATEWAYS=2 - -# number of devices per org: -N_DEVICES=4 - -# For priming each loop so subsequent runs can add -# more orgs/devices/gws without clobbering: - -FIRST_ORG=1 -FIRST_GW=1 -FIRST_DEV=1 -``` - -(If going above double digits for gateways or triple digits for devices, the scripts will need to be -revised; see Bash `printf` and `seq --format` expressions below.) - -Additional variables will be created along the way. - -## Logs & Graphs - -Benchmarking load is meaningless without the ability to measure, and in order to optimize server -capacity requires comparing meaningful, consistent measurements. - -Graphs described below help on both points. - -Subtle nuances to comprehend first: - -- _Normal_ has multiple meanings: - 1. colloquially speaking, it's that which is _healthy_ - 2. in statistics it's the set of values centered within a particular _distribution_ such as a bell - curve -- _Nominal_ also has multiple meanings: - - Within acceptable limits, synonymous with _healthy operation_ - - Say _nominal_ instead of _normal_ in context of Load & Capacity for clarity because inbound - traffic fluctuates, constantly altering the baseline - -The router repo includes the -[Grafana dashboard configuration](https://github.com/helium/router/blob/master/grafana-dashboard.json) -used in production. - -For router under significant load, the most critical graphs to watch: - -- Ensure **Last Block** nominally remains within single digit minutes - - Spikes of 10-20 minutes are generally recoverable - - Sustaining 15 minutes behind should be cause for alarm to take action -- Active **State Channels** on a server routing traffic nominally has **at least 1** and **often - 5-20** - - A "state channel" facilitates off-block transactions which get persisted to the Blockchain as a - single transaction - - The term "state channel" is the generic term for a Layer-2 Ledger (like the "Lightning Network") - and critical to router's use of the Helium Blockchain - - An "actor" is a co-routine in Erlang (or "Green Threads", or similar in purpose to "async/await" - with differing mechanisms) -- **Offer -> Packet -> Downlink** travel times: - - Ideally would be within **milliseconds** (ms) - - Acceptable when below **2 seconds** - - Alarm and take action when above 5 seconds -- **Offer Duration** should be within **milliseconds** (ms) - - This translates directly to latency of server response - - Excludes any Internet traffic latency -- Others have values and trends that vary based upon what is being measured and are described - [below](#comprehending-the-results): - - **Join Offer Rate** - - **Packet Offer Rate** - - **Offer Rejected Reasons** - -For designing your own graphs, it helps bucketing by percentiles. Common buckets are: 1%, 5%, 15%, -50%, 85%, 90%, 95%, 97%, 98%, 99% 100%, which give the average/mean, an approximation of standard -deviation (15%, 85%) and most importantly the _outliers_. Outliers are skewed here towards the -troublesome high end for fine-grained tracking. The 99th and 100th may be safely ignored when those -values are indistinguishable from latency across the Internet, and such outliers are generally due -to periodic garbage-collection of Erlang's underlying BEAM virtual machine. - -Ensure those graphs exist **before** load & capacity tests begin. - -## Manual Setup - -[Generate a Console API Key](/use-the-network/console/my-account/#console-api-keys), which requires -logging onto Console user interface (UI). Everything else will be done by command-line interface -(CLI). - -Each organization will have its own API Key, which may be obtained via the Console UI under Account -Settings. - -Store your new Console API Key generated from the UI to the TOML file below, and specify base URL of -the console. The default of `https://console.helium.com` is probably **not** what you want for -purposes here. This URL must match the Console corresponding to your Router instance. - -If using multiple organizations, create individual configuration files within each org's -subdirectory; e.g., `org-01`, `org-02`, respectively. - -```bash -for o in $(seq --format="%02g" $FIRST_ORG $N_ORGS); do - mkdir $WORKDIR/org-$o -done -``` - -Persist each org's API key and Console base URL in its respective TOML file: (Note the dot preceding -the file name) - -```bash -cd $WORKDIR/org-01/ - -out=.helium-console-config.toml -# Be sure to use *your* assigned key: -echo 'key = "AlphaNumericString..."' > $out -echo 'base_url = "'${CONSOLE_URL}'"' >> $out -echo 'request_timeout = 120' >> $out -``` - -**Repeat** for each of the multiple organizations to be used. - -Confirm getting valid JSON as a result: - -```bash -for o in $(seq --format="%02g" $FIRST_ORG $N_ORGS); do - cd $WORKDIR/org-$o/ - helium-console-cli device list -done -``` - -With valid JSON as the result, preliminary installation is complete. - -Everything else may be scripted; however, creating your first device via Console UI may be easier -than remembering how to create a unique EUI or app key. - -## Create & Fund Wallet - -Use or create a new wallet with minimal funding **as assurance to avoid overspending**. - -```bash -mkdir $WORKDIR/wallet -cd $WORKDIR/wallet/ - -helium-wallet create basic - -WALLET=$(helium-wallet info | grep Address | awk '{print $4}') -echo $WALLET -``` - -Ensure enough Data Credits (DC) to cover -[cost of adding data-only hotspots and asserting location](/hotspot-makers/iot/data-only-hotspots) -of each. - -> e.g., For 20 instances of gateway-rs: 20 x (1000000 + 500000) at HNT prices in 2022Q2, this will -> require 15 HNT. Plus **add for uplinks** from devices if on a non developer instance of router. - -Provide the equivalent of the following command to whomever has the main wallet from which the -limited wallet gets funded: - -> Please add funds for Load & Capacity testing: helium-wallet burn --amount 25 --payee $WALLET -> --commit - -Again, burning HNT is **only for asserting hotspots** and their locations. - -When benchmarking within an isolated environment such as `router-dev`, reset DC balance on the -router host which is described in [Fund Organizations](#fund-organizations) below. - -#### Optional: Sharing Keys With Router - -_Only applies when router's wallet uses ed25519 keys:_ - -Since the Load & Capacity activities will likely be using a development instance of a router, you -may use same private key for the wallet: `/var/data/blockchain/swarm_key` - -Router can generate a file containing both public and private keys. - -Evaluate the following **on router host** via `router remote_console` command: - -```Erlang -SwarmKey = filename:join([ - application:get_env(blockchain, base_dir, "data"), - "blockchain", - "swarm_key" - ]), - {ok, RouterKeys} = libp2p_crypto:load_keys(SwarmKey), -#{public := RouterPubKey, secret := RouterPrivKey} = RouterKeys. - -%% View octets of private key as Erlang Binary: -io:format("~P", [libp2p_crypto:keys_to_bin(RouterKeys), 999]). - -%% Using any other file path creates INSIDE docker container: -libp2p_crypto:save_keys(RouterKeys, "/var/data/wallet.key"). -``` - -> If output from above indicates that it's an ECC Compact key, that key file is incompatible with -> `helium-wallet` due to using a different elliptic curve. - -The private key to be used by `helium-wallet` command will be in `/var/data/wallet.key` file. - -```bash -WALLET=$(helium-wallet -f /var/data/wallet.key info | \ - grep Address | \ - awk '{print $4}') -echo $WALLET -``` - -That shared wallet is ready for use below. - -## Router Address - -Determine address of the router that you are using by running this one command **on router host**: - -```bash -ssh router-dev -cd router/ -router peer addr -``` - -Extract the sequence following `/p2p/` from the output. - -That long alphanumeric value gets used in multiple places below as the `$P2P` variable. - -Define this on your laptop/workstation: - -```bash -P2P=longAlphanumeric... -echo $P2P -``` - -## Hexagons - -Choose a hexagon for each gateway instance. - -Because this is a test router yet each gateway's location must be asserted onto mainnet blockchain, -pick a bogus location such as middle of a lake or river. (While there could be legitimate _devices_ -in a particular body of water, there is unlikely to be a hotspot there as well.) - -> The importance of asserting a location for each hotspot: -> -> Without any location asserted for a particular gateway, the distance calculated to router defaults -> to 1000 as defined within `distance_between()` in -> [router_device_devaddr.erl](https://github.com/helium/router/blob/master/src/device/router_device_devaddr.erl) -> which may be preferable to triangulating based upon physical location. -> -> However, relying upon this default will bypass much program logic which involves a blockchain -> ledger lookup, thereby yielding _artificially_ higher throughput. - -A dedicated and isolated router and console pair may disregard concerns about Proof-of-Coverage -(PoC) or an oversaturated Hex. - -([Router](https://github.com/helium/router) uses [h3](https://github.com/helium/erlang-h3) hexagonal -hierarchical geospatial indexing system for computing distance, so dig there for any unique criteria -or constraints. For previewing the hex for each pair of coordinates, use the live JavaScript feature -of the underlying [API's documentation](https://h3geo.org/docs/api/indexing#geotoh3) with resolution -of 8, and append the resulting value to: `https://explorer-old.helium.com/hotspots/hex/`.) - -Select latitude and longitude: - -```bash -LAT="43.5482302" -LON="-116.6575001" -echo $LAT $LON -``` - -This pair of latitude and longitude values will be used below. - -## Create Devices via Console API - -Each device across all organizations must have _unique_ Dev EUI, App EUI and App Key. - -For reference, see [LoRaWAN](https://lora-alliance.org/lorawan-for-developers/) _Link Layer -Specification_ sections as of v1.0.4: - -- 6.2.1 End-device identifier (DevEUI) -- 6.2.3 Application key (AppKey) - - and its footnote which implies the uniqueness constraint - -By using **an isolated instance** of router, we may generate identifiers: - -```bash -cd $WORKDIR - -for org in $(seq --format="%02g" $FIRST_ORG $N_ORGS); do - for dev in $(seq --format="%03g" $FIRST_DEV $N_DEVICES); do - (cd org-$org && \ - helium-console-cli device create \ - a0000000000$org$dev \ - 600000000000000000000000000$org$dev \ - d0000000000$org$dev \ - benchmark-$dev || echo "org=$org device=$dev" >> errors.log) - done -done -``` - -Confirm: - -```bash -for o in $(seq --format="%02g" $FIRST_ORG $N_ORGS); do - cd $WORKDIR/org-$o/ - helium-console-cli device list > devices.json -done -``` - -Returns JSON, which when formatted via `jq .` resembles the following. - -```JSON -{ - "devices": [ - { - "app_eui": "a000000000001001", - "app_key": "60000000000000000000000000001001", - "dev_eui": "d000000000001001", - "id": "7cbc7f9d-0205-4f85-ab0a-34de8c4d8f52", - "name": "benchmark-001", - "organization_id": "57d5b743-fc08-4119-b4ff-0c60ddf976ff", - "oui": 2 - }, - { - "app_eui": "a000000000001002", - "app_key": "60000000000000000000000000001002", - "dev_eui": "d000000000001002", - "id": "81d39917-b772-4937-b78b-618f4461340f", - "name": "benchmark-002", - "organization_id": "57d5b743-fc08-4119-b4ff-0c60ddf976ff", - "oui": 2 - }, - { - "app_eui": "a000000000001003", - "app_key": "60000000000000000000000000001003", - "dev_eui": "d000000000001003", - "id": "cb82bc53-49ec-4401-bed0-2c4010f26c1d", - "name": "benchmark-003", - "organization_id": "57d5b743-fc08-4119-b4ff-0c60ddf976ff", - "oui": 2 - }, - { - "app_eui": "a000000000001004", - "app_key": "60000000000000000000000000001004", - "dev_eui": "d000000000001004", - "id": "e7cca34d-5234-457f-ae92-8037c2649569", - "name": "benchmark-004", - "organization_id": "57d5b743-fc08-4119-b4ff-0c60ddf976ff", - "oui": 2 - } - ] -} -``` - -Confirm consistent number of devices generated across organizations: - -```bash -wc -l org-*/devices.json -``` - -The value of `"oui"` in output above should correspond to your value for `$ROUTER_OUI`. - -```bash -ROUTER_OUI=$(jq '.devices[0].oui' org-01/devices.json) -echo $ROUTER_OUI -``` - -## Virtual Devices - -This requires devices already having been created via Console API. - -The API provides the _single source of truth_ about devices. (Device ID in Console might be -mismatched with respect to identifiers generated below due to sequence of output from API, which is -unimportant for benchmarking.) - -Despite lack of plural in the name, -[virtual LoRaWAN device](https://github.com/helium/virtual-lorawan-device) accommodates multiple -devices, as indicated by its README. - -Generate a single `settings.toml` file for all devices per organization. (This segments by org for -managing benchmarking runs.) - -Connections of devices from same org will distribute across multiple gateways, simulating real world -scenarios with geographically dispersed deployments. - -Sending more frequently than 2 seconds per device would be unrealistic. The value for -`secs_between_transmits` may be tuned below, and `rx_delay` which defaults to 1s, may be increased -via Console up to 15s. - -```bash -cd $WORKDIR -# Use printf, not `seq --format` to avoid octal when assigning $i below -for o in $(seq $N_ORGS); do - org=$(printf "%02g" $o) - [ -d org-$org/settings ] || mkdir -p org-$org/settings - [ -e org-$org/settings/default.toml ] || \ - ln -s ~/helium/virtual-lorawan-device/settings/default.toml \ - org-$org/settings/ - - out="org-$org/settings/settings.toml" - echo 'default_server = "dev"' > $out - # Must be unique across all instances of virtual-lorawan-device: - metrics_port=$((9898 + o)) - echo 'metrics_server = "127.0.0.1"' >> $out - echo 'metrics_port = '$metrics_port >> $out - echo '' >> $out - - # Multiplexer sprays across all gateways: - echo "[packet_forwarder.mux]" >> $out - echo 'host = "localhost:1680"' >> $out - echo 'mac = "0807060504030200"' >> $out - echo '' >> $out - - # Optional, if you want to bypass multiplexer: - # uncomment this block and use packet_forwarder=gw below. - #for gw in $(seq $N_GATEWAYS); do - # gateway=$(printf "%02g" $gw) - # echo "[packet_forwarder.gw${gateway}]" >> $out - # port=$((1680 + gw)) - # echo 'host = "localhost:'${port}'"' >> $out - # echo 'mac = "08070605040302'${gateway}'"' >> $out - #done - - json="org-$org/devices.json" - for d in $(seq $N_DEVICES); do - device=$(printf "%03g" $d) - echo '' >> $out - echo "[device.${device}]" >> $out - seconds=$((20 + d % 20)) - echo 'secs_between_transmits = '$seconds >> $out - frames=$((120 - d % 40)) - echo 'rejoin_frames = '$frames >> $out - - echo 'packet_forwarder = "mux"' >> $out - # Optional round-robin allocation: - #i=$(( (d % N_GATEWAYS) + FIRST_GW )) - #gateway=$(printf "%02g" $i) - #echo '#packet_forwarder = "gw'${gateway}'"' >> $out - echo "[device.${device}.credentials]" >> $out - j=$((d - 1)) - echo 'dev_eui = '$(jq .devices[$j].dev_eui < $json) >> $out - echo 'app_eui = '$(jq .devices[$j].app_eui < $json) >> $out - echo 'app_key = '$(jq .devices[$j].app_key < $json) >> $out - done -done -``` - -As seconds between transmits increases, number of frames until re-joins decreases for leveling -overall traffic (reducing spikes and eliminating artificial surges). - -Some `packet_forwarder` lines are intentionally commented-out above, because there might be -occasions for connecting to a specific gateway directly rather than using the multiplexer. - -Sanity check: - -```bash -grep -q 'dev_eui = null' org*/settings/settings.toml && \ - echo Something went wrong. -``` - -Devices may require waiting upwards of 20 minutes (concurrently) for the router's XOR filter to run. -The device will be marked in Console with "Pending" status until then, and there is an API call for -this below. - -Later when running the actual test, check logs of `virtual-lorawan-device` for entries containing -the following excerpt: - -```log -WARN ... UDP packet received after tx time ... -``` - -Significantly more than 1:100 ratio indicates the value for `default_secs_between_transmits` should -be increased. That ratio accommodates interference patterns from the scheduler in Linux and the -Tokio async/await framework used within the Rust app, or it can be from the hypervisor when on a -virtualized server instance. - -The metrics API will be used below to track successful Joins. - -## Configure Gateways - -This uses the `$P2P` value defined above in "Router Address" section. - -Each gateway must open a listening socket on a unique port number, so this simply increments from -the default base port. - -Install configuration files: - -```bash -cd $WORKDIR - -i=${FIRST_GW:-1} -for gw in $(seq --format="%02g" $FIRST_GW $N_GATEWAYS); do - mkdir gw-$gw - ln -s ~/helium/gateway-rs/config/default.toml gw-$gw/ - - out=gw-$gw/settings.toml - keyfile="$(pwd)/gw-$gw/gateway_key.bin" - echo 'keypair = "'${keyfile}'"' > $out - # Must be unique per gw and consistent with device configs: - port=$((1680 + i)) - echo 'listen = "127.0.0.1:'${port}'"' >> $out - # Only needs to be unique: - port=$((4467 + i)) - echo "api = $port" >> $out - echo 'region = "US915"' >> $out - echo '' >> $out - echo '[update]' >> $out - echo 'enabled = false' >> $out - echo '' >> $out - echo '[router.release]' >> $out - echo 'pubkey = "'${P2P}'"' >> $out - echo 'uri = "'${ROUTER_URL}'"' >> $out - echo 'oui = '${ROUTER_OUI} >> $out - echo '' >> $out - # Uncomment for high traffic runs: - echo '# [log]' >> $out - echo '# level = "warn"' >> $out - i=$((i + 1)) -done -``` - -> Note: If using "beta" or other version of [gateway-rs](https://github.com/helium/gateway-rs) -> instead of "release", change `[router.release]` to match.) - -For benchmark runs with very high traffic, uncomment the `[log]` section above, because there's a -measurable cost of I/O due to logging that can negatively impact the host sending packets. - -## Add Gateways To Blockchain - -Generate transactions using `WALLET` variable defined earlier. Each transaction gets committed -_later_. - -When in server-mode for the first time, gateway-rs needs time to generate key material and connect -to upstream services, so start all concurrently: - -```bash -for gw in $(seq --format="%02g" $FIRST_GW $N_GATEWAYS); do - helium_gateway -c gw-$gw server > gw-$gw/server.log & -done -``` - -Wait until all log files contain at least one entry for `height`, which implies that each has -connected to its upstream validator: - -```bash -# Wait: -grep -c height gw-$gw/server.log -``` - -Generate transactions, which will be signed and committed later: - -```bash -for gw in $(seq --format="%02g" $FIRST_GW $N_GATEWAYS); do - helium_gateway -c gw-$gw info > gw-$gw/gw-info.json - - helium_gateway -c gw-$gw \ - add --mode dataonly \ - --owner $WALLET \ - --payer $WALLET > gw-$gw/add-dataonly.json -done -``` - -Extract each `txn` value from the previous output and strip quotes from value: - -```bash -jq .txn gw-*/add-dataonly.json | \ - sed 's/"//g' > txn-ids.log -``` - -Prepare command to add each new gateway based upon previous transactions: (if wallet is on router -host, run it there) - -```bash -for txn in $(cat txn-ids.log); do - # Prompts for wallet password - helium-wallet \ - -f $WORKDIR/wallet/wallet.key \ - hotspots add $txn -done -``` - -Ensure there were no errors in the preceding output, and repeat same command adding `--commit` flag -to make it reality. - -**This burns HNT from your wallet:** - -```bash -for txn in $(cat txn-ids.log); do - # Burn HNT from your wallet: - helium-wallet \ - -f $WORKDIR/wallet/wallet.key \ - hotspots add $txn \ - --commit -done -``` - -## Assert Location For Each Gateway - -Assert location using `$LAT` and `$LON` defined earlier for each gateway. - -```bash -for gw in $(seq --format="%02g" $FIRST_GW $N_GATEWAYS); do - key=$(jq .key gw-$gw/gw-info.json | sed 's/"//g') - - helium-wallet \ - -f $WORKDIR/wallet/wallet.key \ - hotspots assert --gateway $key \ - --mode dataonly \ - --lat=$LAT$gw --lon=$LON$gw --elevation 6 -done -``` - -Repeat with `--commit` flag, which **burns HNT from your wallet:** - -```bash -for gw in $(seq --format="%02g" $FIRST_GW $N_GATEWAYS); do - key=$(jq .key gw-$gw/gw-info.json | sed 's/"//g') - - helium-wallet \ - -f $WORKDIR/wallet/wallet.key \ - hotspots assert --gateway $key \ - --mode dataonly \ - --lat=$LAT$gw --lon=$LON$gw --elevation 6 \ - --commit -done -``` - -## Confirm Locations - -Allow time-- approximately 5-20 minutes-- for those transactions to be recorded onto the blockchain, -and then confirm asserted locations via [blockchain API](/api/blockchain/introduction/): - -```bash -curl --user-agent "$UA" \ - "$API_URL/v1/hotspots/location/distance?lat=$LAT&lon=$LON&distance=1000" -``` - -The `distance` parameter above is in meters, so adjust its value if necessary. - -Ensure that your gateways appear within those results. If not found, wait several minutes and check -again later. - -Other gateways appearing within the results is benign because a virtual LoRaWAN device will only -reach those for which it was explicitly configured since its radio is simulated. - -With that, your gateways are ready for Load & Capacity runs. - -## Fund Organizations - -Benchmarking on an **isolated server instance of router** (e.g., `router-dev`) affords the option of -resetting DC balance of an organization. Otherwise, benchmarking will make a measurable impact to -your wallet; see [Data Credits](/data-credit) within Console documentation. - -First, find your `organization_id` which may be obtained via Console UI. From the Organizations -page, there is an export widget associated with each organization listed. - -Alternatively, extract from `devices.json` for each organization. Those files were generated above. - -Run: - -```bash -jq .devices[0].organization_id org-*/devices.json -``` - -Use each of those organization IDs and provide the target DC balance, which gets specified as 100k -in this example: - -```bash -ssh router-dev -cd router/ -router organization update bb5a2fec-1234-5678-89e4-a0e3c4807628 -b 100000 -``` - -Confirm output of the above command, and then repeat with `--commit` flag: - -```bash -!! --commit -``` - -Again, the above command only works on **non-production** environments. - -## Wait for XOR Filter - -The Console may indicate "Pending" from having added new devices above and may take upwards of 20 -minutes. - -Wait until that message clears before proceeding. - -There is an API call for that status: - -```bash -for o in $(seq --format="%02g" $FIRST_ORG $N_ORGS); do - cd $WORKDIR/org-$o/ - helium-console-cli devices all > status.json -done -``` - -If any report as `false`, **wait one minute** at minimum before checking again to avoid being -throttled or blocked: - -```bash -cd $WORKDIR -jq '.[].in_xor_filter' org-*/status.json \ - | grep false && sleep 60 -``` - -## Start Gateways - -Launch each gateway "server" as a separate process, and let the OS handle concurrency: - -```bash -cd $WORKDIR - -for gw in $(seq --format="%02g" $N_GATEWAYS); do - helium_gateway -c gw-$gw server >> gw-$gw/run.log 2>&1 & -done -``` - -Allow several minutes for each gateway concurrently connecting to validators and the router -specified in settings.toml file. - -**Wait** until each hotspot reports height of the blockchain: - -```bash -for gw in $(seq --format="%02g" $FIRST_GW $N_GATEWAYS); do - helium_gateway -c gw-$gw info > gw-$gw/gw-info.json -done -jq .gateway.height gw-*/gw-info.json || echo "Wait!" -``` - -Only after each gateway reports a large integer for height, continue. - -Due to backoff and retry, each delay takes an increasing amount of time with random variation: - -```log - INFO selecting new gateway in 36s, module: dispatcher - ... - INFO selecting new gateway in 69s, module: dispatcher - ... - INFO selecting new gateway in 152s, module: dispatcher - ... - - INFO selecting new gateway in 1826s, module: dispatcher -``` - -Warnings about deadlines logged between retries can be safely ignored: - -```log - WARN gateway stream setup error: ... - "error trying to connect: deadline has elapsed" ... -``` - -> Note: -> -> A gateway may disconnect from its upstream validators or router and automatically reconnect. When -> that occurs, the warnings and retries described above may appear at that time. -> -> One or two retries should be just a blip on the graphs, but extended retries might be cause for -> invalidating the affected run for purposes of benchmarking. - -## Start Multiplexers - -This sends every Join request and packet to all gateways. - -Device configurations performed earlier per organization already account for using the multiplexer. - -Run in its own Terminal window: (running in background to be accommodated in a future release) - -```bash -port=1681 -GW_LIST='' -for gw in $(seq 2 $N_GATEWAYS); do - port=$((port + 1)) - GW_LIST="${GW_LIST} 127.0.0.1:$port" -done - -gwmp-mux --host 1680 --client $GW_LIST > mux.log 2>&1 -``` - -All gateways will receive all Join and Uplink requests. - -## Spawn Virtual Devices - -Launch fleet of virtual devices as a single OS process: - -```bash -cd $WORKDIR - -#export RUST_LOG=warn -for o in $(seq --format="%02g" $N_ORGS); do - virtual-lorawan-device \ - --settings org-$o/settings/ >> org-$o/run.log 2>&1 & - - # Slight mitigation against hammer effect: - sleep 5 -done -``` - -While waiting for the outer loop to finish, watch your graphs; e.g, Grafana. - -Optionally set `RUST_LOG=debug` environment variable for verbose logs. - -Note: [virtual-lorawan-device](https://github.com/helium/virtual-lorawan-device) causes the device -to Join (or re-join) upon each start of the utility. (For continuing a previous session, -pull-requests there are welcomed!) - -## Watch Devices - -The `metrics_port` associated with each running instance of `virtual-lorawan-device` may be queried -via HTTP GET. For bulk requests: - -```bash -metrics() { - time=$(date +%Y-%m-%dt%H:%M:%S) - for o in $(seq --format="%02g" $N_ORGS); do - port=$(grep metrics_port $WORKDIR/org-$o/settings/settings.toml | \ - awk '{print $3}') - curl http://localhost:$port/ > org-$o-stats-$time.txt - done -} -``` - -Periodically run: - -```bash -metrics -``` - -Useful statistics to observe while everything is running may be determined by counting the following -log entries for determining success ratios sampled over duration of each benchmarking run. - -Logs of virtual-lorawan-device: - -- "No Join Accept Received" -- "sending packet" -- "RxWindow expired, expected ACK to confirmed uplink not received" - -Logs from gateway-rs for each packet indicate that the packet has been queued but not necessarily -delivered to router. - -## Watch A Single Device - -This is an optional debugging step. - -While the fleet of `virtual-lorawan-device` instances runs, watch a single device. - -First, run the loop from [Wait for XOR Filter](#wait-for-xor-filter) above again to re-populate -`status.json` for each organization. - -Find devices that indicate a potential problem. - -Device IDs that never connected: - -```bash -jq '.[]|select(.last_connected|.==null)|.id' org-*/status.json -``` - -Devices that connected longest ago: - -```bash -jq '.|sort_by(.last_connected)|.[0]' org-*/status.json -``` - -Device IDs with fewest packets: - -```bash -jq '.|sort_by(.total_packets)|.[0].id' org-*/status.json -``` - -Use those Device IDs for tracing via router CLI: - -```bash -ssh router -cd router/ -router device trace --id=8db30307-1234-5678-9abc-511376ac301b -``` - -Each trace expires after 240 minutes. - -## Stop - -Generally allow this fleet of virtual devices to run for 15-20 minutes, which gives ample traffic -that the Erlang BEAM virtual machine's garbage-collector will have run, etc. - -When you have enough data: - -```bash -killall virtual-lorawan-device -killall helium_gateway -``` - -(Those must be names of each actual command-- not Bash aliases.) - -Confirm no longer running: - -```bash -ps aux | grep virtual-lorawan-device -ps aux | grep helium_gateway -``` - -## Iterate - -To ensure sufficient load, you may need to **run again with increased values** for: - -- number of organizations (`N_ORGS`) -- number of devices (`N_DEVICES`) -- number of gateways (`N_GATEWAYS`) - -When doing so, also increase corresponding values for `FIRST_*` to be the former value of `N_*` to -avoid clobbering or creating duplicate devices. - -Check for new releases of [virtual-lorawan-device](https://github.com/helium/virtual-lorawan-device) -that may facilitate driving higher traffic. Future work will occur there. - -## Comprehending The Results - -For measuring number of **devices within a devaddr slab**: - -Ensure "Join Offer Rate" graph shows step-wise increases, and "Packet Offer Rate" graph resembles a -plateau. Then, watch "Offer Rejected Reasons" graph and stop when seeing an increase in -`devaddr_no_device`. - -With disambiguation due in part to the Message Integrity Check (MIC), the usable number will be -higher than apparent capacity; thus, an 8 slab accommodates more than eight devices. Actual limits -may vary with Router and/or Console configurations used. - -For measuring **traffic load**: - -There should be a slow ramp-up of traffic such that we "find the knee" of the graph _before_ hitting -the plateau (ceiling). Understand this plateau being an approximation due to the nature of generated -traffic. - -A good rule-of-thumb: - -**Plan for 70% CPU utilization** for nominal load, which provides a cushion for traffic spikes -without being excessively oversized. - -## Repeatable Results - -When confirming any such measurements: - -**Run** the same scenario a **minimum of three consecutive** times with consistent results. - -That _excludes_ a preliminary run to invalidate the OS file-system cache. - -This rule of three requires consistency. If results vary by more than rounding error, keep running -until getting 3 with similar results. - -If the only consistency is that results vary widely, look to other artifacts on the host OS that -might be causing interference. Consider migrating to different host server hardware (via hard -stop/start) if running on a virtualized/hypervisor environment such as AWS, GCP, Linode, etc. - -Items that we addressed: - -- On Ubuntu Server, prevent Snap from updating during a benchmark run: - - `sudo snap list` and `sudo apt-get purge snapd` -- If graphs are inconsistent, confirm each gateway is still connected to its upstream Validator: - - Confirm "Join Offer Rate" graph shows step-wise increases - - Confirm "Packet Offer Rate" graph resembles a plateau diff --git a/docs/use-the-network/run-a-network-server/run-a-network-server.mdx b/docs/use-the-network/run-a-network-server/run-a-network-server.mdx deleted file mode 100644 index f629b3670..000000000 --- a/docs/use-the-network/run-a-network-server/run-a-network-server.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -id: run-a-network-server -title: Run A Network Server -pagination_label: Run A Network Server -sidebar_label: Host Your Own Console -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/run-a-network-server ---- - -# Host Your Own Console - -The Helium Network is unique in that it provides public wireless infrastructure for privately -operated LoRaWAN Network Servers. Details about how Helium blockchain primitives interoperate with -LoRaWAN routing can be read about [here](/lorawan-on-helium). - -In this section, we will provide a step-by-step guide on actually getting a LoRaWAN Network Server -(LNS) based on Helium's open-source Console up and running. - -- [buy an OUI](/use-the-network/run-a-network-server/buy-an-oui) -- [run Console](/use-the-network/run-a-network-server/run-console) -- [deploy Console](/use-the-network/run-a-network-server/deploy-console) -- Optionally [debug with sniffer](/use-the-network/run-a-network-server/debug-with-sniffer) to - confirm router runtime behavior using a virtual LoRaWAN device and a software-based protocol - sniffer -- [Router benchmarking](/use-the-network/run-a-network-server/router-benchmarking) for load & - capacity of real LoRaWAN traffic in an isolated environment - - Use this to help determine size of server instance to deploy - - This document also gives insight to interactions of console, router, gateways, organizations, - devices and wallets as used in production - -Before pursuing this configuration though, it is worth considering. - -**Do I need to own my own OUI and operate my own Console?** - -- If you are developing a few prototype devices, it might not be time to operate a network server. - Helium Foundation hosts and operates [Console](/use-the-network/console) where you can easily - manage devices (up to 10) for a organization without dealing with OUI management; you only pay for - packets and new accounts start with free 250 Data Credits (DC). To go beyond 10 devices check out - Console Hosting Providers [here](/use-the-network/console/hosting-providers). - -- The initial costs to host your own Console is U.S. $900 or 90 million DC (OUI costs 10 million DC, - and 80 million DC for the smallest address slab). - -:::info - -For a video tutorial on setting up your own instance of Console, check out our Tips and Tricks video -[here](https://www.youtube.com/watch?v=rVb5gfE_vs8) - -::: diff --git a/docs/use-the-network/run-a-network-server/run-console.mdx b/docs/use-the-network/run-a-network-server/run-console.mdx deleted file mode 100644 index 147a06588..000000000 --- a/docs/use-the-network/run-a-network-server/run-console.mdx +++ /dev/null @@ -1,341 +0,0 @@ ---- -id: run-console -title: Run Console -pagination_label: Run Console -sidebar_label: Run Console -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/run-a-network-server/run-console ---- - -# What is Console? - -import useBaseUrl from '@docusaurus/useBaseUrl' - -[Console](https://github.com/helium/console) is a project developed by Helium. It provides a web -browser front-end for users to manage organizations and devices and a Helium Blockchain-compatible -LoRaWAN Network Server (LNS) called [Router](https://github.com/helium/routerv3). - -We are working on integrations with third-party LNS's such as Chirpstack, but at this time, this is -the only "plug-and-play" solution for operating an OUI. That being said, the Router code is -open-source and custom LNS implementations may be derived by anyone already since OUI operation on -the Helium Network is entirely permissionless. - -## Requirements - -Before we begin, you should have the following: - -- [purchased an OUI](/use-the-network/run-a-network-server/buy-an-oui) and noted its number -- installed Docker and docker-compose (see quick-start for this in the next section, "Setting Up - Dependencies") -- you have some spare HNT to burn ($10-100 worth), for funding your OUI address -- a [Magic Link](https://magic.link/) account for user account management. Note that without - additional configuration, only login via link will work. Login via Google directly will _not_ - work. -- at least 4 vCPUs, 8GB of RAM, and 120 GB of SSD. The - [CPX41 product from Hetzner](https://www.hetzner.com/) or the - [numerous VPS options from Vultr](https://www.vultr.com/pricing/) end up being cost-effective - solutions. AWS provides equivalents such as t2.xlarge. - -Optionally, you should also: - -- have a fully sync'ed Miner or ETL instance to extract a snapshot from. To learn how to setup a - Miner, [please read here](/use-the-network/setup-a-packet-forwarder). -- be able to configure ports on a firewall - -### Setting up dependencies - -In a fresh CentOS/Rocky/Alma Linux configuration, you can run the following installation step to -prep the system for the rest of the tutorial. - -First run: - -``` -yum -y update -yum -y install epel-release -yum -y install net-tools \ - htop \ - vim \ - git \ - python3-devel \ - openssl-devel - -yum -y remove docker \ - docker-client \ - docker-client-latest \ - docker-common \ - docker-latest \ - docker-latest-logrotate \ - docker-logrotate \ - docker-engine -yum clean all -dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo -``` - -And then: - -``` -dnf update -dnf -y install docker-ce docker-ce-cli containerd.io - -systemctl enable docker -systemctl start docker -curl -L "https://github.com/docker/compose/releases/download/v2.3.3/docker-compose-linux-x86_64" -o /usr/local/bin/docker-compose -chmod a+wrx /usr/local/bin/docker-compose -``` - -## Console Setup - -### Clone the console repo - -```bash -git clone https://github.com/helium/console.git -``` - -### Customize Console environment - -``` -cp templates/.env .env -``` - -Then edit `.env`. Here's an example of what it should look like: - -``` -SECRET_KEY_BASE=BgrSaMYa3lW/6l/3mN2/Op5u4bHw2FP4oPahBbFGgDhmtZ3cF9YwKx8/XH7SmOvNiglRXaH7c3inElVyc0XuWQ== -CLOAK_SECRET_KEY=SbxBSg47PNTHYe+1kY+KrlLXtL+gG/pFLcYseeBKh10= -GUARDIAN_SECRET_KEY=DtUzbwYhg48179r/kDtmH8lZtCmXN01ip1kOCnwQ6JI/4GqFv2ZNl3st7kXXB83brn6C/dkVU+BylrhWgyNG/w== -ROUTER_SECRETS=1647452465:++XKKmAwaoqz3OvAeH5PdR//Yk/znwYC8Xr+a98BRnf2l565PC3MXvti7j7u3fq4NxT7iQyX7lLL2y+0Udea0A== -ENV_DOMAIN=localhost:4000 -SOCKET_CHECK_ORIGIN=http://localhost -DATABASE_DB=console -DATABASE_HOST=postgres -DATABASE_USER=postgres -DATABASE_PASSWORD=postgres -DATABASE_POOL_SIZE=20 -BLOCKCHAIN_API_RETRY=1 -OUI=22 -SELF_HOSTED=true -``` - -In addition, you'll want to configure the Magic Link fields: - -``` -USE_MAGIC_AUTH=true -MAGIC_PUBLIC_KEY=pk_live_XXXXXXXXXXXXXXXX -MAGIC_SECRET_KEY=sk_live_XXXXXXXXXXXXXXXX -``` - -You may get these from your [Magic Link dashboard](https://dashboard.magic.link/app/all_apps) upon -selecting your app. - -#### Customize Console Branding - -Console Providers can customize their instance of Console UI including the ability to swap out -images/logos, email content, and change footer links. - -To customize your open source Console: - -Copy `app-config.json` into config folder - -```bash -cp templates/app-config.json config/app-config.json -``` - -Customize `config/app-config.json` as needed. - -:::important - -If you choose to customize your version of Console you need to build from source or your -customizations will be overwritten. - -::: - -To switch to building your own Console instead of using the quay image: - -```bash -cp templates/docker-compose-server.yaml docker-compose.yaml -``` - -### Customize Router environment - -We will do something similar for `.env-router`: - -```bash -cp templates/.env-router .env-router -``` - -Then edit `.env-router`. There are many options here to familiarize yourself with, but the only -necessary field to update is `ROUTER_CONSOLE_SECRET`. It must match `ROUTER_SECRETS` from `.env`. - -### Run it! - -Copy the local docker-compose file - -```bash -cp templates/docker-compose-local.yaml docker-compose.yaml -``` - -This template builds console locally and does not use nginx for SSL. You may want to read about -nginx setup [here](/use-the-network/run-a-network-server/deploy-console). - -If you launch docker-compose from here, you will build from the `master` branch. You can use git to -build and checkout alternate branches or tags. - -Alternately, to avoid building at all, you can use a quay image by changing the image configuration -in the console section to the following: - -``` - console: - image: quay.io/team-helium/console:latest -``` - -Once you've selected which branch of quay tag to use, `docker-compose up` deploys Conosle, Router -and Postgres. - -The first deployment can take a little longer, especially if you're building. While we're waiting, -let's configure our firewall. Each cloud provider does this slightly differently, but you'll want to -continue enabling SSH on port 22 so that you can accept your own login and management, open up port -2154 for libp2p which allows you to sync the blockchain, and finally, port 8080 is for gRPC -connections from hotspots so that you may actually purchase packets: - - - -You might see `helium_router` crash a few times as it waits for `helium_console` to start up and -allow the socket connection between the two. - -You can forward the UX to your local machine with the following command: - -```bash -ssh -L 4000:$CONSOLE_IP:4000 -N -f root@$CONSOLE_IP -``` - -This allows you to have local access to the web interface without opening up your firewall publicly. - -Now, if you go to `localhost:4000`, you should have the Magic Link login available to you. - -### Load a snapshot - -Optionally, you can load a snapshot so that your Console is immediately ready for action. -Technically, the Router component of Console is what keeps up with the blockchain. You can check its -current height - -```bash -docker exec helium_router router info height -``` - -You are likely quite a ways from the tip of the blockchain, but you can load a snapshot from an -active miner (or ETL instance or blockchain-node). Details about how to do this are -[here](/hotspot-makers/become-a-maker/basic-miner-operation#snapshots). - -Simply replace `miner` with `docker exec helium_router router` for most of the commands to work. - -### Create Data Credits - -At this point, we have the software running and we have an OUI, but the router does not have any DC -to buy messages from the network. We need to burn some HNT to DC for the router. - -The cost for rurning a router is complex. See community member disk91.com's -[guide](https://www.disk91.com/2021/technology/lora/what-is-the-real-cost-of-helium-communication/) -and calculate how much you need for your planned usage. One million DC ($10) can be a good number to -start with. - -The easiest way to calculate how many HNT to burn to get the number of DC you need is to go to -https://console.helium.com/datacredits and click on `Purchase Data Credits`. Enter the amount of DC -you need and click on `Burn HNT to DC`. Helium Console shows how to burn the selected amount to the -Helium Console itself. We won't do that. Just note the amount (for example `0.49043649`). - -Let's get the address of the OUI/router. - -```bash -$ docker exec helium_router router peer addr -/p2p/11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf -``` - -The string after the second slash, `11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf`, is the -libp2p address and this is where we need to burn the DC. Now return to your command line wallet and -burn the HNT amount **with the libp2p address of your OUI/router as payee**. Example: - -```bash -helium-wallet burn --amount 0.49043649 --payee 11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf --commit -``` - -Once this transaction clears, we'll be ready for the next step. - -### OUI Update - -At this point, we have the software running and we have an OUI, but the blockchain does not know -that the address of Router is associated with the OUI. Use the same libp2p address used in the -previous step. - -```bash -/p2p/11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf -``` - -Note run the following command with the same wallet used to purchase the OUI. - -```bash -$ helium-wallet oui update routers --oui 4 --nonce 1 --address 11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf --commit -``` - -Once this transaction clears, the network will know about the association. It may take a few -minutes, but once the transaction clears, your OUI will be able to open and close state channels and -update your device table on the blockchain. - -Monitor the account in explorer to verify that Router is doing this appropriately. eg: -`https://explorer-old.helium.com/accounts/11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf` - -### Create Data Credits - -Many fees benefit from -[implicit burn](/blockchain/transaction-fees#transaction-fees-and-implicit-burn), including when -paying for OUIs and DevAddr's (done previously when you -[purchased an OUI](/use-the-network/run-a-network-server/buy-an-oui/), but your router needs a DC -balance to run. - -The cost for rurning a router is complex. See community member disk91.com's -[guide](https://www.disk91.com/2021/technology/lora/what-is-the-real-cost-of-helium-communication/) -and calculate how much you need for your planned usage. - -One million DC ($10) can be a good number to start with. The easiest way to calculate how many HNT -to burn to get the number of DC you need is to go to https://console.helium.com/datacredits and -click on `Purchase Data Credits`. Enter the amount of DC you need and click on `Burn HNT to DC`. -Helium Console shows how to burn the selected amount to the Helium Console itself. We won't do that. -Just note the amount (for example `0.49043649`). - -Now return to your command line wallet and burn the HNT amount **with the libp2p address of your -router as payee**. For example: - -```bash -helium-wallet burn --amount 0.49043649 --payee 11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf --commit -``` - -### Test a Device - -Login to your local Console instance (localhost:4000) and create an organization and a device. If -you ever need help with Console as a user, -[much documentation exists here](/use-the-network/console). - -Once you've created the device on console, go to a terminal window on server running Console and -execute the following command to tell Router to update the `xor filter` on the blockchain: - -```bash -docker exec helium_router router device xor --commit -``` - -Give the transaction some time to process (you can track it on explorer). Once it has been -processed, you can try joining the device. If you see a successful Join Request, then you are -successfully running your private LoRaWAN Network Server. - -Congratulations! - -### Backing up your `swarm_key` - -Extract the router's swarm key and store it somewhere safe. The swarm key can be extracted by -running `base64 ~/console/data/router/blockchain/swarm_key` and saved in your favorite password -manager. An alternative is to copy the file somewhere safe. - -#### A Note on the Purpose of a `swarm_key` - -The `swarm_key` equates to your unique identity on the Helium blockchain. Backing up the `swarm_key` -enables you to maintain your router's identity in the event that your node becomes compromised in -some way, or needs to be rebuilt on another server for any reason. diff --git a/docs/use-the-network/setup-a-packet-forwarder.mdx b/docs/use-the-network/setup-a-packet-forwarder.mdx deleted file mode 100644 index e9c5eb9bb..000000000 --- a/docs/use-the-network/setup-a-packet-forwarder.mdx +++ /dev/null @@ -1,158 +0,0 @@ ---- -id: setup-a-packet-forwarder -title: Build A Packet Forwarder -pagination_label: Build A Packet Forwarder -sidebar_label: Build A Packet Forwarder -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network/setup-a-packet-forwarder ---- - -# Build a Packet Forwarder - -import useBaseUrl from '@docusaurus/useBaseUrl' - -:::warning - -The ability to earn from [Proof of Coverage](/blockchain/proof-of-coverage) with anything other than -a [Full Hotspot](/hotspot-makers/iot/full-hotspots) is not supported. - -Building your own packet forwarder enables Data transfer rewards _only_, **if and only if** you -complete the setup process [here](/hotspot-makers/iot/data-only-hotspots). - -::: - -## Packet Forwarder Architecture - - - -To be a Helium Hotspot, there are three principal components to know about: - -- **Packet Forwarder**: this is a utility that interacts with the radio front-end and sends and - receives raw radio packets with the Helium Miner. -- **Hotspot Client**: the Helium blockchain comes into the picture here; the hotspot client is - responsible for routing packets to the appropriate Router entering into microtransactions brokered - via gRPC. -- **Router**: a Helium compatible LoRaWAN Network Server ("LNS"); this component is interested in - receiving the packets relating to its devices and handles downlink responses when appropriate. - -Any device that can run an 8 channel LoRa front-end (such as SX1301 or SX1302) can be used to -participate in the Helium Network. The Hotspot Client is designed to send and receive packets using -the Semtech GateWay Messaging Protocol (GWMP), making it compatible with almost every LoRaWAN -Gateway on the Market. - -Many off-the-shelf LoRaWAN Gateways work very well and using one of them gives you one less thing to -worry about as the Packet Forwarder is set up and ready to go. - -This guide, however, is for those that want a more hands-on experience. We will essentially be -assembling a LoRaWAN Gateway with discrete parts, loading up an open-source Linux distribution, -compiling the Packet Forwarder, and running it all ourselves. In short, we'll be learning Gateways -that hard way! - -
- - This guide is experimental and for advanced users only, and you may run into various issues - trying to get this working. - -
- -### Example Custom Hardware - -If you don’t have your own hardware yet, we recommend using a Raspberry Pi 4B running the latest -[64-bit RaspiOS](https://downloads.raspberrypi.org/raspios_arm64/images/) image. - -We recommend this configuration in particular if you are interested in running the Hotspot on the -Gateway itself; it's easy to run -[our Docker image from Quay](https://quay.io/repository/team-helium/miner) on a 64-bit ARM system. -If you choose to run the Hotspot elsewhere, it's possible to downgrade all the way to a Pi0, for -example, since you will only be running the Packet Forwarder on the Gateway. - -RAK Wireless sells multiple "PiHats" that provide the 8-channel front-end: - -- [the RAK2287 (SX1302)](https://store.rakwireless.com/products/rak2287-pi-hat) - -Or you can check out their -[WisGate Developer](https://store.rakwireless.com/collections/wisgate-developer) line where they -provide bundles: - -- the D4H/D4H+/D4HP are all based on the RAK2287 - -Ultimately, which configuration works for you depends on your situation, but all of them will work -with this guide with little adjustment. - -### Preparing the SD Card - -You can create an SD card from this image by looking for the recently inserted SD card in your -system. - -``` -$ ls -al /dev | grep sd -``` - -Generally, the timestamp is enough to indicate which device is the SD card. Next, write the image to -the SD card. For example: - -``` -dd if=~/2020-08-20-raspios-buster-arm64.img of=/dev/sdX bs=1M -``` - -Use the command `sync` to make sure the filesystem is written before trying to remove the SD card. -Once the `sync` command returns, you can eject and remove the SD card from your system. - -## Preparing RaspiOS - -With a keyboard, mouse, and monitor plugged in, power on the Raspberry Pi. Proceed through the -guided RaspiOS setup where you will update your password, configure your Wi-Fi, etc. - -Enable SPI and I2C using the raspi-config tool: `sudo raspi-config` - -Select `Interface Options`, and enable `I2C` and `SPI` from within the menu system. This is also a -good time to enable SSH if you want it. - -## Installing the Semtech Packet Forwarder - -Depending on which SX130x radio you are running, you will want to select the appropriate Packet -Forwarder application. - -#### Packet Forwarder SX1302 - -Pull down Helium's fork of the SX1302 Packet Forwarder: - -```bash -$ git clone https://github.com/helium/sx1302_hal.git -``` - -Go into the directory and build: - -```bash -$ cd sx1302_hal -$ make -``` - -Next, go into the the packet_forwarder directory, where we will create a link to the reset script: - -```bash -$ cd packet_forwarder -$ ln -s ../tools/reset_lgw.sh reset_lgw.sh -``` - -We will also create a link to the appropriate regional configuration. For example: - -```bash -$ ln -s global_conf.json.sx1250.US915 global_conf.json -``` - -We are now ready to test the start-up. From `~/sx1302_hal/packet_forwarder` try: - -```bash -$ ./lora_pkt_fwd -``` - -If you get the following output, you are good to go: - -```bash -INFO: [main] concentrator started, packet can now be received -INFO: concentrator EUI: 0x???????????????? -``` - -You are now ready to set up the [Hotspot client](/hotspot-makers/iot/light-hotspots). diff --git a/docs/use-the-network/use-the-network.mdx b/docs/use-the-network/use-the-network.mdx deleted file mode 100644 index 41c113323..000000000 --- a/docs/use-the-network/use-the-network.mdx +++ /dev/null @@ -1,147 +0,0 @@ ---- -id: use-the-network -title: Use the Helium IOT Network -pagination_label: Use the IOT Network -sidebar_label: Use the Helium IOT Network -description: Use the IOT Network -image: https://docs.helium.com/img/link-image.png -slug: /use-the-network ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -
-
-
-
- -
- {/*

Use the Helium Network

*/} -

- Thousands of developers and companies rely on the Helium Network for connectivity. Ready - to join them? Here's where to start. -

- -
-
-
-
-
- -
- -:::info - -[Helium Discord](https://discord.gg/helium) is the best place to get real-time support from the -community. And the [#console](discord://discord.com/channels/404106811252408320/730245319882965093) -and [#sensor-dev](discord://discord.com/channels/404106811252408320/730246602861838467) channels are -the two most relevant for developers using the Network. - -::: - -
- -
-
-
- -

Devices

-

- Purchase and customize Helium-enabled devices or prototypes and build your own. -

- - Learn More - -
Quick Links
- - Ready To Use Devices - - - Development Devices - -
-
- -

LoRaWAN Network Servers

-

- The OpenLNS initiative allows anyone looking to deploy devices on the Helium Network to use - any LoRaWAN Network Server. -

- - Learn More - -
Quick Links
- - Find an LNS Provider - - - Host Your Own LNS - -
-
- -

Community Projects

-

- We love seeing community projects that utilize the Network in clever new ways. -

- - Learn More - -
Quick Links
- - Agriculture - - - Dashboards - - - Environmental - -
-
- -

Coverage Mapping

-

- Mappers is a community-led effort to actively survey the signal intensity of the Helium - Network, using configured-trackers. -

- - See the Map - -
Quick Links
- - Intro to Coverage - Mappers - - - Mappers Quickstart - -
-
-
diff --git a/docs/vote-escrow/realms.mdx b/docs/vote-escrow/realms.mdx deleted file mode 100644 index a7ee1e4b4..000000000 --- a/docs/vote-escrow/realms.mdx +++ /dev/null @@ -1,307 +0,0 @@ ---- -id: realms -title: Staking veHNT on Realms -pagination_label: Realms -sidebar_label: Staking veHNT on Realms -description: Helium on Realms Documentation -image: https://docs.helium.com/img/link-image.png -slug: /vote-escrow/realms ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -Like many other Solana Ecosystem projects, Helium utilizes [Realms](https://realms.today) to -organize and manage vote escrow tokens, delegation, and more. Stakes can be created and later -managed within Realms at any time. - -## Creating a Stake - -Anyone with HNT in a wallet can create a stake using Realms either using an in-wallet browser or a -browser-connected wallet. - -While staking IOT or MOBILE tokens is possible through their respective subDAOs, those positions are -only eligible for voting power and cannot currently be delegated for the purposes of earning -rewards. - -This guide outlines using Realms with the [Helium Wallet App](/wallets/helium-wallet-app). To use -Realms on a desktop browser, a Solana-compatible browser wallet can be used (such as Phantom or -Backpack). - -The Helium Wallet App's browser can be accessed via the globe icon in the bottom navigation. - -
- -
- veHNT can be managed via https://realms.heliumvote.com/dao/hnt -
-
-
- -### Signing Into Realms - -Connect your account to Realms using the in-app browser from the Helium Wallet App. - -
- -
- This user is logged in with their 4qPt5... account. -
-
-
- -Once your wallet has been connected to Realms, your token balances (or existing positions) will be -displayed in the governance section of the DAO. - -
- -
- Stake positions can be made in the "My governance power" section of Realms -
-
-
- -As long as HNT is available in your linked account, new stakes can be created by tapping on the -"Lock Tokens" button within the governance view. - -
- -
- -### Lockup Period - -To build a secure voting system, Helium only allows votes from token holders willing to align -themselves with the long-term health of the Helium Network. This is done by allowing holders to -receive veHNT in proportion to the amount of time that the tokens are staked for. - -
- -
Selecting your lockup type, Decaying or Constant.
-
- -#### Decaying - -Tokens are locked for a fixed duration and are released in full at the end of the defined lockup -period. Vote weight declines linearly until release. This effectively starts the cooldown at the -moment of staking. - -You will be required to close the position to return the staked HNT to your wallet after the -cooldown period has ended. - -
- -
- You lock 10.000 tokens with a lockup duration of one year. They are then unavailable for the - next one year. After this time, you can withdraw them again. -
-
- -#### Constant - -Tokens are locked indefinitely. At any time you can start the unlock process which lasts for the -initially chosen lockup duration. Vote weight stays constant until you start the unlock process, -then it declines linearly until release. - -
- -
- You lock 10.000 tokens with a lockup duration of one year. After three years you decide to start - the unlocking process. Another year after that, you can withdraw the tokens. -
-
- -### Duration - -The duration of your cooldown is set in units of days. The longer your tokens are staked, the more -veHNT will be issued. If you chose the 'Constant' lockup period, this duration takes effect after -the 'Unlock' action is executed. - -While it is possible to set a higher duration than 4 years, no additional vote weight multiplier -will be added. - -
- -
Setting a longer duration results in a greater vote weight multiplier.
-
- -### Stake Multiplier - -veHNT positions can be strengthened by increasing the duration that they are locked for. The -resulting multiplier designates the amount of vote and delegation power of the position. It is not -indicative of an investment return. - -In other words, if you staked 10 HNT for 6 months, you'd get the same 10 HNT back 6 months later. -During this time you would be able to [delegate](#delegating-stakes) your position to a network to -get a return in that network's tokens. - -Positions created during the [landrush](#landrush) period received an additional 3x multiplier on -the overall lockup multiplier. - -
- -
- The multiplier affects a position's voting and delegation power but does not mean more HNT is - returned. -
-
- -### Confirming your Stake - -Once parameters are settled in the Realms UI, you are now ready to create your veHNT position. - -The Helium Wallet App will ask for confirmation before issuing the Solana transaction that creates -the veHNT position. - -
- -
- After pressing, "Lock Tokens", a Solana transaction is issued to create the stake. -
-
- -## Managing Stakes - -With Realms, it's a sizzling experience to take control of your HNT stakes, ensuring they're grilled -to perfection. Chew through stake delegation, transfers, splitting, and cooldowns like a master -chef. 🥩 - -### Delegating Stakes - -A stake will not earn any token return until it is delegated to a subDAO. A stake without delegation -earns voting rights, but no token return. You can delegate an active stake within the Realms -interface. - -Once a stake has been delegated, it can be undelegated in the same interface. Delegations can be -changed at any time, however, it will take one epoch for the position to be available for -redelegation. The stake must be delegated for the entire epoch to receive rewards for that epoch. - -
- -
veHNT positions can be delegated to the IoT or the Mobile network.
-
- -### Splitting a Stake - -A stake can be divided among multiple positions. This can be helpful if you wish to delegate your -veHNT position to multiple networks (IOT or MOBILE) or set different lockup times to different -positions. - -Be warned, splitting a [landrush](#landrush) position after the initial 10 day period will result in -losing the multiplier for the position being split or transferred off the position. - -You must undelegate before splitting a stake. You can redelegate after the split is complete. - -Positions that are in any active votes cannot be split. To change a position during a vote it must -be relinquished from the active vote. - -### Transfer a Stake - -Staked positions cannot be transferred from one account to another. Stakes can only be transferred -from one position to another within the same account. Positions can only transfer to positions of -greater or equal duration. This functionality is useful for consolidating positions. Landrush -positions cannot have more locked tokens transferred into them after the landrush period. Any veHNT -transferred out of a landrush position will lose the 3x multiplier bonus. - -You must undelegate both positions before transferring a stake between positions. Transferring to a -new position requires the original position to be undelegated. You can redelegate one or both -positions after the split is complete. - -
- -
A position can be transferred in full or in part.
-
- -### Extending a Stake - -Extending a stake will lengthen the time it will take to unstake. Position holders may extend a -stake to gain a larger multiplier for voting power or delegation purposes. Extending a staking -period does not add additional time to the stake, it instead updates the existing stake period to -the new selection. - -### Unlocking a Stake (Cooldown) - -If a stake was created with a 'constant' [lockup period](#lockup-period), the ability to 'Unlock' -the position will be visible in the position as long as the unlock has not yet been initiated. A -constant lockup position will first need to be unlocked before the cooldown period begins. - -Unlocking the position will begin the cooldown decay process. The time this takes is the lockup -duration set during the creation of the position. And your veHNT value will decay to 0 veHNT during -this cooldown period. - -You will be required to close the position to return the staked HNT to your wallet after the -cooldown period has ended. You must claim all tokens from the position and undelegate the position -before the Close Position button is available as an option. - -
- -
- This position will unlock over the period of 2 years once the unlock has been initiated. -
-
- -## Landrush - -For the first 10 days following the Solana migration, HNT holders were eligible to stake their HNT -for a 'landrush' bonus of 3x the locked amount.([^1],[^2]) - -If a landrush stake is moved or split out of its original position after the first 10 days have -lapsed, the landrush bonus is forfeited. - -
- -
- The 'landrush' banner indicates a position created within the first 10 days of the Solana - migration. -
-
- -[^1]: - [HIP 70: Scaling the Helium Network](https://github.com/helium/HIP/blob/main/0070-scaling-helium.md) - -[^2]: - [HIP 77: Launch Parameters for Solana Migration](https://github.com/helium/HIP/blob/main/0077-solana-parameters.md) - -## Automatically Created Validator Stakes - -For existing validators, a veHNT position is automatically created based on the existing staked -position previously tied to Validators. The -[Validator migration guide](/solana/migration/validator-operator) is a valuable reference in -understanding specific details for former Validator operators. - -These positions are not automatically delegated to a subDAO and are set with a constant -[lockup period](#lockup-period) by default. - -As a note, these Validator positions will appear as one large stake. `hntyv...` is the Solana mint -address for HNT. - -
- -
- A veHNT position representing two migrated validators (20,000 HNT) under one account. -
-
- -## Possible Errors - -### Insufficient SOL Balance - -Creating new veHNT positions requires more SOL than standard token claims or account-to-account -transfers. To stake your HNT you will need approximately 0.006 SOL in your account to create the -position. - -
- -
This transaction failed due to an insufficient $SOL balance.
-
- - diff --git a/docs/vote-escrow/vehnt.mdx b/docs/vote-escrow/vehnt.mdx deleted file mode 100644 index 6d5a274ba..000000000 --- a/docs/vote-escrow/vehnt.mdx +++ /dev/null @@ -1,94 +0,0 @@ ---- -id: vehnt -title: Helium Vote Escrow Token -pagination_label: veHNT Position -sidebar_label: veHNT -description: Helium veHNT Documentation -image: https://docs.helium.com/img/link-image.png -slug: /vehnt ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - - - -In the Helium Ecosystem, HNT holders can receive veHNT positions by locking their HNT on-chain for a -specified period in exchange for voting power and subDAO delegation reward in the Helium DAO. After -the lock-up period ends and the locked position is closed, the amount of HNT is released to the -owner's Wallet and is once again transferable. - -veHNT, or voting-escrowed HNT, is a position introduced as part of -[HIP-51](https://github.com/helium/HIP/blob/main/0051-helium-dao.md). veHNT was designed to empower -Helium Token holders by allowing them to participate in the governance of the Network and benefit -from its growth. By understanding the veHNT token and the governance model, Helium stakeholders can -make informed decisions and actively participate in shaping the Network's future. - -## How veHNT Works - -When HNT is locked into the voting escrow, it is converted to a veHNT position, which can be used to -participate in Network governance and decision-making. veHNT is the only way to vote in the Helium -Network. The primary purpose of veHNT is to incentivize long-term commitment to the Network and -align stakeholders' interests with the Network's long-term success. - -The amount of veHNT received when locking HNT depends on the lock-up period chosen by the user, with -longer lock-up periods resulting in a higher veHNT multiplier. - -## SubDAOs - -The Helium Network serves as the overarching system that enables a multitude of Networks (subDAOs) -to exist via the HNT token. - -Those who delegate their veHNT position to a subDAO are eligible to receive a portion of that -Network's token emissions. - -Each subDAO governs a specific area of the Network. The distribution of HNT tokens available to the -subDAO is determined by the amount of veHNT delegated to each subDAO. HNT is minted in proportion to -the veHNT staked to each subDAO. Initially, two subDAOs are introduced: IOT and MOBILE. Voting on -matters specific to the IoT and Mobile networks will require veIOT and veMOBILE respectively. - -### IOT subDAO - -The IOT subDAO focuses on the original vision of the Helium Network, supporting the growth and -development of IoT devices and applications. Delegating veHNT to the IOT subDAO will help fund -projects and initiatives that further the IoT Ecosystem on the Helium Network. - -### MOBILE subDAO - -The MOBILE subDAO is dedicated to the growth and expansion of the Helium Network in the cellular -communications sector of the Network. Delegating veHNT to the MOBILE subDAO will help finance -projects and initiatives aimed at integrating Helium technology into mobile devices and Networks. - -## Delegating veHNT - -To earn rewards from the token emissions, veHNT holders must delegate their position to one or more -subDAOs. The lock-up period can range from 1 day to 48 months, with the longer lock-up periods -resulting in a higher veHNT multiplier. Users can also change their delegations at any time to -optimize their rewards from the subDAOs. - -veTokens can be managed through [Realms](/vote-escrow/realms) using the in-app browser on the -[Helium Wallet App](/wallets/helium-wallet-app): - -- [HNT DAO on Realms](https://app.realms.today/dao/HNT) -- [IOT subDAO on Realms](https://app.realms.today/dao/IOT) -- [MOBILE subDAO on Realms](https://app.realms.today/dao/MOBILE) - -### Impacts on subDAO Rewards - -SubDAO rewards are calculated and paid to the lock-up position each 24-hour reward period, at -approximately 00:30 UTC. Currently, the IOT and MOBILE subDAO each have a 6% token emission pool for -veHNT stakers. This 6% is shared proportionately amongst all veHNT delegated to that subDAO at the -end of each epoch. - -**subDAO rewards may increase when:** - -- More veHNT is delegated in the subDAO you delegated to - your treasury gets more HNT. -- More Hotspot onboarding fees are burned in the subDAO you delegated to. -- More Network Data is transferred within the subDAO you delegated to. - -**subDAO rewards may decrease when:** - -- More veHNT is delegated in the subDAO you delegated to - your share is reduced. -- More veHNT is delegated to other subDAOs - other treasuries get more HNT. -- Your delegated veHNT decays over time after you enter cooldown (cliff mode) -- More Hotspots are online in other subDAOs that have a non-zero onboarding fee. -- More Network Data is transferred within other subDAOs. diff --git a/docs/wallets/app-wallet/deep-links-and-qr-codes.mdx b/docs/wallets/app-wallet/deep-links-and-qr-codes.mdx deleted file mode 100644 index db06d846b..000000000 --- a/docs/wallets/app-wallet/deep-links-and-qr-codes.mdx +++ /dev/null @@ -1,218 +0,0 @@ ---- -id: deep-links-and-qr-codes -title: Deep Links And QR Codes -pagination_label: Deep Links And QR Codes -sidebar_label: Deep Links And QR Codes -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /wallets/app-wallet/deep-links-and-qr-codes ---- - -# Deep Links and QR Codes - -:::info - -This page refers to QR codes and deep links that are signed and submitted to the blockchain via the -Helium Hotspot and Wallet Apps. Makers should not use the following information and instead use the -[Helium React Native SDK](https://helium.github.io/react-native-helium/index.html) and -[WalletLink](https://helium.github.io/helium-js/modules/wallet_link.html) libraries to sign and -submit transactions in their maker app. - -::: - -To generate a QR code to scan, find a service to generate a QR code using the json data below. This -is an example site: `https://www.qr-code-generator.com` - -## External QR Scanner (System Camera) - -This section refers to deep links that navigate into the Helium Hotspot and Wallet apps via the -native system camera. For QR codes scanned internally in the Helium Hotspot and Wallet apps see the -[Internal QR Scanner](#internal-qr-scanner) section below. - -### View Hotspot (Hotspot App) - -``` -helium://hotspot/:address -``` - -| param | Type | Note | -| ------- | -------- | ------------------------------------- | -| address | _string_ | b58 Address of the Hotspot to display | - -### Add Gateway (Hotspot App) - -``` -helium://add_gateway/:encoded_txn -``` - -| param | Type | Note | -| ----------- | -------- | --------------------------------------------- | -| encoded_txn | _string_ | base64 url encoded add gateway V1 transaction | - -Users can read more on how to generate an `add_gateway` transaction from the -[Makers Guide > Hotspot Integration](/hotspot-makers/become-a-maker/hotspot-integration-testing#generate-an-add-hotspot-transaction). - -### Payment (Hotspot App) - -``` -helium://payment?address={{address}}&amount={{amount}}&memo={{memo}} -``` - -| param | Type | Note | -| --------------- | -------- | -------------------------------------- | -| address | _string_ | b58 Address to send the payment to | -| amount | _string_ | HNT amount, 1 = 1 HNT | -| memo (optional) | _string_ | UTF8 string with a max size of 8 bytes | - -### Payment (Wallet App) - -``` -https://wallet.helium.com/payment?payee={{payee}}&amount={{amount}}&memo={{memo}} -``` - -| param | Type | Note | -| --------------- | -------- | ------------------------------------------------ | -| payee | _string_ | b58 Address to send the payment to | -| amount | _string_ | HNT amount in bones, 100000000 = 1 HNT | -| memo (optional) | _string_ | Base64 encoded string with a max size of 8 bytes | - -### Add Gateway / Assert Location / Transfer Hotspot (Wallet App) - -The Wallet App requires a maker app in order to sign Add Gateway, Assert Location, and Transfer -Hotspot Transactions via deep links. Please see the -[Helium React Native SDK](https://helium.github.io/react-native-helium/index.html) and -[WalletLink](https://helium.github.io/helium-js/modules/wallet_link.html) documentation for more -information. - -## Internal QR Scanner - -This section refers to QR codes scanned internally by the Helium Hotspot and Wallet apps. - -:::info - -In the **Hotspot App** all memos must be **UTF8 strings** with a **max size of 8 bytes**. - -In the **Wallet App** all memos should be **base64 encoded strings** with a **max size of 8 bytes**. - -If you want to target **both the Wallet App and Hotspot App** with one QR you should add -`"utf8Memo": true` to **use UTF8 memos for both**. - -::: - -### Burn HNT - -#### Generated from console - -```json -{ - "type": "dc_burn", - "address": ":address", - "amount": "1.00", - "memo": "dGVzdA===" -} -``` - -#### UTF8 memo - -```json -{ - "type": "dc_burn", - "utf8Memo": true, - "address": ":address", - "amount": "1.00", - "memo": "test" -} -``` - -### Payment - -#### Single Payee without memo - -```json -{ - "type": "payment", - "address": ":address", - "amount": 1 -} -``` - -#### Single Payee with memo - -```json -{ - "type": "payment", - "address": ":address", - "amount": 1, - "memo": "dGVzdA==" -} -``` - -#### Single Payee with UTF8 memo - -```json -{ - "type": "payment", - "utf8Memo": true, - "address": ":address", - "amount": 1, - "memo": "test" -} -``` - -#### Multiple Payee without memo - -```json -{ - "type": "payment", - "payees": { - ":address1": 10.2, - ":address2": 1.2 - } -} -``` - -#### Multiple Payee with memo - -```json -{ - "type": "payment", - "payees": { - ":address1": { - "amount": 10.2, - "memo": "dGVzdA==" - }, - ":address2": { - "amount": 1.2, - "memo": "dGVzdA==" - } - } -} -``` - -#### Multiple Payee with UTF8 memo - -```json -{ - "type": "payment", - "utf8Memo": true, - "payees": { - ":address1": { - "amount": 10.2, - "memo": "test" - }, - ":address2": { - "amount": 1.2, - "memo": "test" - } - } -} -``` - -### Wallet address QR code - -Create a qr code with a valid b58 wallet address. This is valid for both the Hotspot App and Wallet -App. - -``` -12ORy9GjFASqWWxHmUq4tNXcjvr5Xfno8qimGMrNReMsSaM9T8f -``` diff --git a/docs/wallets/app-wallet/hexagons.mdx b/docs/wallets/app-wallet/hexagons.mdx deleted file mode 100644 index 78daf5b4a..000000000 --- a/docs/wallets/app-wallet/hexagons.mdx +++ /dev/null @@ -1,225 +0,0 @@ ---- -id: hexagons -title: Understanding Hexagons -pagination_label: Hexagons -sidebar_label: Understanding Hexagons -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /wallets/app-wallet/hexagons ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Understanding Hexagons - -Hexagons, while also a six-sided shape, is the underlying representation of the earth on the Helium -network. Based on Uber's H3 index, the surface of the earth can be represented by a grid of hexagons -at different resolutions, with higher resolutions covering a larger area, and the smallest -resolution covering centimeters of the earth. To understand the technical details and the -implementation, please check out the - - - blog one of the core developers - -. - -| H3 Resolution | Average Hexagon Area (km²) | Average Hexagon Edge Length (km) | -| ------------- | :------------------------: | -------------------------------: | -| 0 | 4,250,546.8477000 | 1,107.71259100 | -| 1 | 607,220.9782429 | 418.676005500 | -| 2 | 86,745.8540347 | 158.244655800 | -| 3 | 12,392.2648621 | 59.810857940 | -| 4 | 1,770.3235517 | 22.606379400 | -| 5 | 252.9033645 | 8.544408276 | -| 6 | 36.1290521 | 3.229482772 | -| 7 | 5.1612932 | 1.220629759 | -| 8 | 0.7373276 | 0.461354684 | -| 9 | 0.1053325 | 0.174375668 | -| 10 | 0.0150475 | 0.065907807 | -| 11 | 0.0021496 | 0.024910561 | -| 12 | 0.0003071 | 0.009415526 | - -## Hexagons in Helium - -Since the genesis block, Hotspot locations have been represented (and continue to) in resolution 12, -a semi-precise point location covering 300 m² (3200 ft²), which is comparable to the footprint of a -large house. This is why some Hotspots appear to be "a few houses down from where I asserted". But, -as the network expanded, concerns over security and privacy regarding Hotspot locations grew -alongside it. - - - -# Hexagons in the App - -To improve privacy, security, and understand scaling, Helium is introducing hexagons in the Helium -app. - -**These new hexagons will replace Hotspot dots.** - -The hex your Hotspot belongs to is derived from its resolution 12 location, and scaled up to its -parent resolution 8 hexagon. - -## Resolution 8 Hexagons - -The Helium app displays resolution 8 hexagons, which have an area of 0.7373276 km², and edge length -of 0.461354684 km. About 130 resolution 8 hexagons cover the city of San Francisco. - -:::note - -Resolution 8 hexagons may be temporary. Depending on the outcome of an investigation to see how -Resolution 8 asserts affect Proof-of-Coverage, the resolution may change from resolution 8 to 9, or -another value. This will be brought forth in a Helium Improvement Proposal. - -::: - -## Viewing Hotspots in Resolution 8 - -:::note - -Viewing Resolution 8 Hexagons is only available on app version 3.3.0 and later. - -::: - -To view a map of the network, go to the **Hotspot** tab. - - - -Each occupied hexagon will have a grey hexagon representing 1 Hotspot. Hexagons with more than 1 -Hotspot will show a number. - -Tapping on a hexagon with a number will bring up a Hotspot selector, showing the Hotspots inside -that hexagon. Slide through the selector to see each individual Hotspot. - -Hotspots that you follow will be **purple**, and Hotspots that you own will be **blue**. Other -Hotspots will be grey. - - - -The **Owned and Followed Hotspot** Map layer is displayed by default. - -## Map Layers - -Removing point location and grouping Hotspots in a hexagon resulted in new design challenges: How do -we show different Hotspot attributes as a group? What if a hexagon had a mixture of different -transmit scales, or what if only one of three Hotspots in a hex is a witness? - -To address these challenges, app version 3.3.0 introduces three new map filters: - - - -1. Owned and Followed Hotspots -2. Witness -3. Scaling - -### Owned and Followed Hotspots - -This layer colors hexagons where you own or follow Hotspots. If the hexagon contains both followed -and unfollowed and/or owned and unowned Hotspots, you will see a blue or purple color indicator. - -By default, if there is an owned Hotspot in a hexagon, it will be colored blue, even if there is a -followed Hotspot occupying that hexagon. - - - -### Witness - -This map layer, when selected, shows yellow hexagons of Hotspots that have witnessed the _selected -Hotspot_ (outlined in white - in this case, Magic Fleece Terrier). - - - -To view a list of Hotspots that have witnessed your Hotspot, switch to the Witnesses tab. - - - -These Hotspots have recently witnessed a Beacon from Magic Fleece Terrier based on Proof-of-Coverage -receipts. - -### Transmit Scale - -Previously known as Reward Scale, the Transmit Scale has been renamed to properly explain what this -number conveys. - -**Transmit scale is a multiplier that is applied to rewards of _any Hotspot that witnesses you_. The -scale also affects how many rewards you receive as a Beaconer.** - -The number is a representation of how dense a hexagon is (how many Hotspots occupy that hex) at -various resolutions (from resolution 12 down to resolution 4). This means that if any Hotspots -assert themselves within the 1770 km² area surrounding your Hotspot, your Hotspot's transmit scale -can change. If you're interested in how this is calculated, check out the -[engineering blog](/devblog/2020/12/09/blockchain-release-hip-17). - -To counteract the effects of a lower transmit scale, it is recommended that Hotspots improve their -antenna setup (outdoors, higher gain, higher elevation) so it can witness beacons of Hotspots -further away, with potentially higher transmit scales. This ensures a low-scaled Hotspot can -continue to earn at an optimal level. - -:::tip - -TLDR: Low Transmit Scale does not mean your Hotspot is doomed! Make sure you have a great setup so -you can witness Hotspots with 1.0 Transmit scales. - -::: - -#### Colors of Hexagons - -A higher transmit scale will be green, and a lower transmit scale will be colored orange. - -In the app, the color of a resolution 8 hexagon is based on the average transmit scale of all -Hotspots' scale occupying that hex. - -So if a hexagon has 3 Hotspots, with scales 1.0, 0.74, and 0.68, the average scale of that hexagon -is 0.80667 and the color will be tinged light green. - - - -## Discovery Mode - -Discovery Mode is a tool to understand Hotspot coverage. Responders that heard a Discovery Mode -packet will be highlighted in a yellow hexagon. Tapping on the yellow hexagon will bring up the name -of the Hotspot that responded. - - - -## Assert Location - -Hotspot can now see how many other Hotspots are occupying hexagons next to them. - -:::info - -It's important to be truthful in where your Hotspot is located for Proof-of-Coverage. Randomly -selecting an empty hexagon will not mean the Hotspot will mine more. - -::: - -## FAQ - -**Q: Why are there hexagons now instead of exact Hotspot locations?** - -A: To protect Hotspot owner's privacy, the Helium app and Explorer will use hexagons instead of -precise locations to display coverage. - -**Q: Why is my Hotspot location so far off from the center of the hexagon?** - -A: For every Hotspot at a resolution 12, we scale up to a resolution 8 and snap the Hotspot location -to the center of resolution 8. This is why you may see the location shift. This will not affect how -the system calculates proof-of-coverage. - -**Q: Why is my Hotspot so close to its neighboring Hotspot if I asserted 300 meters away?** - -A: Two Hotspots may occupy the same resolution 8 hexagons even if they are more than 300 meters -away. Remember that a resolution 8 hexagon has an area of 737.3276 m² with edges measuring -461.354684 meters. - -**Q: Why do Hotspots in the same a hex have such varied scaling values?** - -A: Each Hotspot's transmit scale is a formula based on its density in a number of resolutions (from -resolution 12 to resolution 4). Hotspot A that occupies the same resolution as Hotspot B may be in a -very dense resolution 10 hexagon, thus lowering their scale, while Hotspot B may be the only Hotspot -occupying its resolution 10 hexagon, meaning their scale is not affected. - -**Q: Are Assert Locations still precise?** - -A: Yes. Assert Locations are still precise (at a resolution 12). The precise location helps the -network formulate proof-of-coverage challenges. Any changes to the assert location resolution will -be presented in a HIP and brought to a community vote. There is no ETA for this at the moment. diff --git a/docs/wallets/app-wallet/transaction-failures.mdx b/docs/wallets/app-wallet/transaction-failures.mdx deleted file mode 100644 index 2a890dc6a..000000000 --- a/docs/wallets/app-wallet/transaction-failures.mdx +++ /dev/null @@ -1,145 +0,0 @@ ---- -id: transaction-failures -title: Transaction Failures -pagination_label: Transaction Failures -sidebar_label: Transaction Failures -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /wallets/app-wallet/transaction-failures ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Types of Transaction Failures - -The Helium app automatically notifies users whenever a transaction fails. Transactions can fail for -a number of reasons - the most common is typically insufficient funds (not enough $HNT in the -wallet) or a nonce issue. - -:::info What is a nonce? - -Nonce is a number included in every transaction to guarantee the data is "live" and not replayed, -preventing the blockchain from replay attacks. - -The Helium app uses a speculative nonce, which increments for every type of transaction. In some -cases, the blockchain's transaction manager processes these transactions out of order which causes -some transactions to fail. - -::: - -## Payment Transaction Failures - -### Wrong Transaction Fee - -`{invalid,wrong_txn_fee}` - -Transaction fees are required on the network to prevent spamming. These fees use Data Credits (DC) -and the Helium app uses -[implicit burn](/blockchain/transaction-fees/#transaction-fees-and-implicit-burn) to determine the -appropriate amount of HNT to burn to generate these DCs. - -How much HNT to burn depends on the Oracle price. The Oracle price is the median HNT price from -alist of individual oracles and used to weather large swings in price. In special cases, the price -of HNT may shift enough in a short time period such that the amount of HNT burned to generate DCs -_is not enough_. - -:::info - -1 DC = $0.00001 HNT - -::: - -**Recommended Fix:** If you see this failure, the best thing to do is to first confirm the -transaction did not occur (check your wallet balance), then submit the payment transaction again. - -### Invalid Nonce - -`{invalid,invalid_nonce}` - -If you see this error message for payment transactions, it could mean that multiple payments were -sent in quick succession without waiting for the prior payment to clear. - -**Recommended Fix:** We recommend sending payments one at a time and waiting for it to clear before -attempting the next. - -The core developers are actively looking at ways to improve this experience. - -## Transfer Hotspot Transaction Failures - -Please check out the -[Transfer Hotspot Guide](https://docs.helium.com/wallets/app-wallet/transfer-hotspot/) for full -instructions and best practices. - -### Gateway Too Stale - -`{invalid,gateway_too_stale}` - -Due to the decentralized nature of the Helium network, it’s important that owners and new owners of -Hotspots know what they’re getting is a functional unit that is able to sync the blockchain and -participate in PoC (the way Hotspots mine $HNT). Before transferring a Hotspot, the blockchain -checks to see if it has had recent activity in the last 1200 blocks (approximately 20 hours). -Activity counts as creating a challenge, witnessing a challenge, or sending a beacon. It also checks -that it’s fully synced to the blockchain. - -If you see this notification, it means the the Hotspot you’re about to transfer has not shown “proof -of life” recently. - -**Recommended Fix:** Notify the other person involved in the transfer of this Hotspot from that they -should conect the Hotspot back into Internet and monitor the Hotspot for activity before trying -again. - -### Buyer Insufficient HNT Balance - -`{invalid,buyer_insufficient_hnt_balance}` - -The network facilitates transferring Hotspots at zero cost or at a price the seller determines. Even -if the cost is zero, there is always a transaction fee for every transaction on the network to -prevent spamming. In the case of transferring Hotspots, the buyer is the one to pay the transaction -fee, which is typically 55,000 DC. A recommendation of 1-2 HNT in the buyer’s wallet is usually more -than enough to account for the transaction. - -If you see this notification, the buyer should fund their wallet, seller should cancel and -reinitiate the transfer request to try again. - -## Assert Location Transaction Failures - -### Invalid Nonce - -`{invalid,invalid_nonce}` - -If you see this error message, it could mean that multiple attempts to update a Hotspot’s location, -gain, or elevation was attempted in quick succession, or, attempting to add multiple Hotspots in -quick succession without waiting for the prior change to clear. - -**Recommended Fix:** We recommend setting location for Hotspots one at a time and waiting for it to -clear before attempting the next. - -### Invalid Staking Fee - -`{invalid,invalid_staking_fee}` - -If you see this error message, it could mean that the app calculated the fees to pay for a location -update incorrectly. - -**Recommended Fix:** We recommend checking the API to confirm that the update never made it to the -blockchain, then trying again. - -To check the API, first copy your Hotspot address. You can find this on explorer-old.helium.com, -enter the Hotspot name, then click on the clipboard icon next to the name. - - - -Then paste the address where it says `:hotspotaddress` - -`api.helium.io/v1/hotspots/:hotspotaddress` - -**Example:** - - - -If you updated gain, look for `“gain”`. Please note this value is multiplied by ten. So if you typed -in 2.1 in the app, it will appear as 21. This is expected. - -If you updated elevation, look for `“elevation”`. This is in meters. - -If you updated the location, look for `“lng”`, `“lat”` or `“geocode”`. diff --git a/docs/wallets/app-wallet/transfer-hotspot.mdx b/docs/wallets/app-wallet/transfer-hotspot.mdx deleted file mode 100644 index 20f991715..000000000 --- a/docs/wallets/app-wallet/transfer-hotspot.mdx +++ /dev/null @@ -1,116 +0,0 @@ ---- -id: transfer-hotspot -title: Transfer Hotspot -pagination_label: Transfer Hotspot -sidebar_label: Transfer Hotspot -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /wallets/app-wallet/transfer-hotspot ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Transfer Hotspot - -As requested by the Community via HIP13, the Transfer Hotspot feature is available for Hotspot -owners of the Network to transfer their Hotspots to another owner. - -This feature enables Hotspot owners to transfer ownership of a Hotspot to another user. Once -transferred, the new owner will receive all future Hotspot mining rewards. - -:::info - -It is now recommended to use version 2.0.0 or higher of the -[Helium Wallet app](/wallets/helium-wallet-app) to perform hotspot transfers between wallets. This -app has no restrictions on the transfer - -::: - -### Requirements - -- Only the wallet that owns the Hotspot on the blockchain can initiate a transfer. -- These steps are for Seller with [Helium Hotspot app](/mine-hnt/helium-hotspot-app) version 3.10.0 - or higher, other vendor Hotspot Management apps will make the same checks. - -* Parties do not need to be physically next to the Hotspot for transfer to succeed. - -- This feature requires both users to have a valid Helium wallet account. Remember, 24-word wallets - are not supported by the Helium Hotspot App. -- The Seller pays the transaction fee of ~55,000 DC. -- Hotspots must have had LoraWAN Proof-of-Coverage activity (Issued a Broadcast Beacon or Witnessed - a valid or invalid Beacon) or performed LoraWAN Data Transfer activity in the last 1200 blocks - (approximately 20 hours) to be transferred. This is to ensure the Hotspot is functioning on the - network for the protection of the buyer. - -:::warning - -Things to keep in mind: Helium assumes no liability on the functionality of Hotspot hardware defined -in the Transfer Hotspot transaction. Buyers must verify with the Seller the Hotspot is in good, -working condition and, once transferred, understand there is no guarantee that the Hotspot hardware -will arrive in working condition. - -::: - -## As a Seller, to initiate a Transfer Hotspot transaction: - -1. Navigate to the Hotspot to transfer and tap Settings > Transfer Hotspot. - - - -2. Acknowledge that you, the Seller, will no longer own or earn mining rewards from that Hotspot - once transferred. -3. Enter the Hotspot name in the text field to confirm you want to transfer the Hotspot. - - - -4. You’ll see the payment user interface next. Enter the Buyer’s wallet address. - - - -5. Press Send Transfer Request to submit the Transfer. The transfer request will be automatically - submitted. - -- Note that once submitted, transfers can not be cancelled, reversed, or changed. Having the correct - Buyer address is critical\* - -6. Once the Transfer Hotspot transaction clears the blockchain, the Hotspot will no longer appear in - the Sellers account and will show up in the Buyers account. Both the Buyer and Seller will - receive a confirmation in their notification center. - -7. The Seller will see an activity entry on their Account page showing the Hotspot Transfer. - -## As a Buyer: - -Once the transaction clears, a notification will appear in the Buyer’s notification center. The -Hotspot will then show up in the Buyers wallet. Tap on the notification to view the transaction. - - - -## Common Questions - -### Can I undo the transaction? - -No. Once transferred, the Hotspot and its mining rewards moving forward belong to the Buyer. - -### Who pays for the transaction fee? - -The Seller pays for the transaction fee. - -### Will this be recorded in the blockchain? - -Yes. Transfer Hotspot transactions are on-chain and visible in Explorer. - -### How do I make sure the Hotspot physically changes hands? - -It is the Buyer's responsibility to confirm the Hotspot is fully functional and will arrive in the -same, working condition. - -### Do I need to be next to the Hotspot to transfer or receive? - -No. You do not need to be physically next to the Hotspot as a buyer or seller to transfer the -Hotspot. - -### Is the history of the Hotspot transferred to the new owner as well? - -Yes. All mining history from the Hotspot will transfer to the new owner as well. This cannot be -cleared as all history is from the ledger. It does not transfer any previously earned HNT. diff --git a/docs/wallets/cli-wallet.mdx b/docs/wallets/cli-wallet.mdx new file mode 100644 index 000000000..5ab06a696 --- /dev/null +++ b/docs/wallets/cli-wallet.mdx @@ -0,0 +1,191 @@ +--- +id: cli-wallet +title: CLI Wallet +pagination_label: CLI Wallet +sidebar_label: CLI Wallet +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /wallets/cli-wallet +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +# Command Line Interface Wallet + +## Installing Helium CLI Wallet + +### Running From a Release + +Releases of the Helium CLI Wallet are +[available on GitHub](https://github.com/helium/helium-wallet-rs/releases). Select the appropriate +package for your operating system. + +Unpack the zip file and place the helium-wallet binary in your `$PATH`. This operation differs +depending on your operating system but is a common task and easily searchable. + +### Building From Source + +The Helium CLI Wallet is open-source, written in Rust, and can be compiled with appropriate tooling. +For build instructions, see the +[Building from Source](https://github.com/helium/helium-wallet-rs#building-from-source) section on +the helium‑wallet‑rs GitHub repo. + +## Usage + +At any time, use `--help` to see the most recent in-program documentation. + +At the time of this writing, version 2.0.0-rc.3 looks like this: + +```sh +./helium-wallet --help +Common options for most wallet commands + +Usage: helium-wallet [OPTIONS] + +Commands: + info Get wallet information + balance Get the balance for a wallet or a given public key. The balance is given for each of the Helium related holdings of a given Solana address + upgrade Upgrade a wallet to the latest supported version of the given format. The same password is used to decrypt the old and encrypt the new wallet + router Operations on routers + create Create a new wallet or keypair + hotspots Commands on hotspots + dc Commands on data credits + transfer Send one (or more) payments to given addresses + export Exports encrypted wallet seed as QR-encoded JSON or raw seed via stdout + help Print this message or the help of the given subcommand(s) + +Options: + -f, --file File(s) to use [default: wallet.key] + --url Solana RPC URL to use [default: m] + -h, --help Print help + -V, --version Print version +``` + +Exploring the help menu is always a good way to orient yourself. To learn more about a certain +transaction (or subcommand), simply append `--help`. e.g.: + +```sh +./helium-wallet dc --help +Commands on data credits + +Usage: helium-wallet dc + +Commands: + price Get the amount of HNT needed to buy a given number of USD worth of Data Credits + mint Burn HNT to Data Credits (DC) from this wallet to given payees wallet + delegate Delegate DC from this wallet to a given router + help Print this message or the help of the given subcommand(s) + +Options: + -h, --help Print help +``` + +## Basic Commands + +### Create Wallet + +`helium-wallet create basic` + +This command will create an account as a single key, stored in `wallet.key` which gets output in the +same directory where the command is run. + +Upon creation, the CLI will prompt you for a password that encrypts the file. A strong password will +make it difficult for someone to brute force the file should the file be compromised. + +### Display Wallet + +Displaying information for an account without needing its password can be done using: + +```bash +$ helium-wallet info +``` + +To display a QR code for the public key of the given Wallet use: + +```bash +$ helium-wallet info --qr +``` + +The QR Code is useful for sending tokens to the account from a wallet app. + +### Wallet Creation Features + +Creating a Wallet above is easy, but there's a lot more flexibility you might not know about. It's +always recommended to explore the help menu to learn more: + +```bash +$ helium-wallet create basic --help +Create a new basic wallet + +Usage: helium-wallet create basic [OPTIONS] + +Options: + -o, --output Output file to store the key in [default: wallet.key] + --force Overwrite an existing file + --seed Use a BIP39 or mobile app seed phrase to generate the wallet keys + -h, --help Print help +``` + +### Managing Multiple Accounts + +A more precise location or filename can be specified when creating an account by using the +`--output` flag. e.g.: + +```bash +$ helium-wallet create basic --output ~/my-wallets/wallet-5.key +``` + +You can specify a file other than the default `./wallet.key` by using the global option `--file`. +e.g.: + +```bash +$ helium-wallet -f ~/my-wallets/wallet-5.key transfer
+``` + +### Import Seed-phrase Account into CLI + +The `--seed` flag enables you to import an account secured by a 12 or 24-word seed phrase. + +Enter the command: + +``` +$ helium-wallet create basic --seed +``` + +After you press enter, you will be prompted for your seed words, separated by spaces. + +### Export to Helium Wallet App + +Helium Wallets created using the CLI can be exported to the Helium Wallet App. + +```bash +$ helium-wallet export +``` + +You will be prompted for the Wallet Password, (this is _not_ your seed phrase, this password was +input when the Wallet was created.) + +The `export` command will display the seed phrase associated with the given account. This seed +phrase can be used with the Helium Wallet App or other Solana ecosystem wallets. + +--- + +
+ +# Helium L1 Migration to Solana + +If you have a wallet from before the migration to Solana (April 18th, 2023), you can migrate it +using this widget: + +import { MigrateWallet } from '@theme/MigrateWallet' + + + +Once this is done, the wallet should work on Solana. You can see a mapping from the Helium L1 +address to the Solana Address: + +import { DisplayLegacyWallet } from '@theme/DisplayLegacyWallet' + +
+ +
diff --git a/docs/wallets/cli.mdx b/docs/wallets/cli.mdx deleted file mode 100644 index 1783c1a96..000000000 --- a/docs/wallets/cli.mdx +++ /dev/null @@ -1,459 +0,0 @@ ---- -id: cli-wallet -title: CLI Wallet -pagination_label: CLI Wallet -sidebar_label: CLI Wallet -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /wallets/cli-wallet ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Command Line Interface Wallet - -The Helium Command Line Interface (CLI) Wallet is the most flexible of the Wallet options but it -also requires more technical knowledge. As such, it is suitable for all types of transactions, but -requires more caution on behalf of its users. - -Once you've covered the basics here, you can explore more specific use-cases for the Wallet: - -- [add and assert data only hotspot](/hotspot-makers/iot/data-only-hotspots) - -## Installing CLI Wallet - -Releases of the CLI Wallet are -[tagged and hosted on GitHub](https://github.com/helium/helium-wallet-rs/tags). Click on "Downloads" -for the most recent release and select the appropriate package for your operating system. - -Unpack the zip file and place the helium-wallet binary in your `$PATH` somewhere. This operation -differs depending on your operating system but is a common task and easily searchable. - -## Usage - -At any time, use `--help` to see the most recent documentation and help for the CLI Wallet. - -At time of this writing, version 1.7.7 looks like this: - -```bash -$ helium-wallet --help -helium-wallet 1.7.7 -Common options for most wallet commands - -USAGE: - helium-wallet [OPTIONS] - -FLAGS: - -h, --help - Prints help information - - -V, --version - Prints version information - - -OPTIONS: - -f, --file ... - File(s) to use [default: wallet.key] - - --format - Output format to use [default: table] [possible values: table, json] - - -SUBCOMMANDS: - balance Get the balance for a wallet. The balance is given in HNT and has a precision of 8 decimals - burn Burn HNT to Data Credits (DC) from this wallet to given payees wallet - commit Commit a transaction to the blockchain - create Create a new wallet - export Export an encypted wallet seed as JSON - help Prints this message or the help of the given subcommand(s) - hotspots Display list of hotspots associated with wallet or transfer a hotspot to another wallet - htlc Create or Redeem from an HTLC address - info Get wallet information - multisig Commands multi signature transactions - oracle Report an oracle price to the blockchain - oui Create or update an OUI - pay Send one (or more) payments to given addresses - request Construct various request (like payment) in a QR code - sign Commands for signing or verifying data - upgrade Upgrade a wallet to the latest supported version of the given format. The same password is used to - decrypt the old and encrypt the new wallet - vars Commands for chain variables - verify Verify an encypted wallet - -``` - -Exploring the help menu is always a good way to orient yourself. To learn more about a certain -transaction (or subcommand), simply append `--help`. e.g.: - -```bash -helium-wallet pay --help -``` - -This documentation will not cover every single command, but we will provide some basic examples to -help you get familiar. - -## Create Wallet - -`helium-wallet create basic` - -This command will create a Wallet as a single key, stored in `wallet.key` which gets output in -whatever directory you ran this command. - -Upon creation, the CLI will prompt you for a password which encrypts the file. A strong password -will make it difficult for someone to brute force the file should the file be compromised. - -### Display Wallet - -Displaying information for one or more Wallets without needing its password can be done using: - -```bash -$ helium-wallet info -``` - -To display a QR code for the public key of the given Wallet use: - -```bash -$ helium-wallet info --qr -``` - -This is useful for sending tokens to the Wallet from the mobile Wallet. - -### Wallet Creation Features - -Creating a Wallet above is easy, but there's a lot more flexibility you might not know about. It's -always recommended to explore the help menu to learn more: - -```bash -$ helium-wallet create basic --help -helium-wallet-create-basic 1.7.7 -Create a new basic wallet - -USAGE: - helium-wallet create basic [FLAGS] [OPTIONS] - -FLAGS: - --force Overwrite an existing file - -h, --help Prints help information - --seed Use a BIP39 or mobile app seed phrase to generate the wallet keys - -V, --version Prints version information - -OPTIONS: - --key-type The type of key to generate (ecc_compact/ed25519) [default: ed25519] - --network The network to generate the wallet (testnet/mainnet) [default: mainnet] - -o, --output Output file to store the key in [default: wallet.key] - --swarm Import a swarm_key file from a miner, gateway, or other blockchain actor -``` - -We'll go through a few examples next. - -### Managing Multiple Wallets - -You can specify a more precise location or filename when _creating a wallet_ by using the `--output` -flag. e.g.: - -```bash -$ helium-wallet create basic --output ~/my-wallets/wallet-5.key -``` - -When _using a wallet_, you can specify a file other than the default `./wallet.key` by using the -global option `--file`. e.g.: - -```bash -$ helium-wallet -f ~/my-wallets/wallet-5.key pay
-``` - -### Sharded Wallet - -Sharding Wallet keys is supported via Shamir's Secret Sharing. A key can be broken into N shards -such that recovering the original key needs K distinct shards. This can be done by passing options -to create: - -```bash -$ helium-wallet create sharded -n 5 -k 3 -``` - -This will create wallet.key.1 through wallet.key.5 (the base name of the Wallet file can be supplied -with the `--output` parameter). - -When keys are sharded using verify will require at least K distinct keys. - -The `--seed` option described above can also be used to construct a sharded Wallet. - -#### Implementation details - -A ed25519 key is generated via libsodium. The provided password is run through PBKDF2, with a -configurable number of iterations and a random salt, and the resulting value is used as an AES key. -When sharding is enabled, an additional AES key is randomly generated, and the 2 keys are combined -using a sha256 HMAC into the final AES key. - -The private key is then encrypted with AES256-GCM and stored in the file along with the sharding -information, the key share (if applicable), the AES initialization vector, the PBKDF2 salt and -iteration count and the AES-GCM authentication tag. - -### Import Seed - -The `--seed` flag enables you to import a Wallet generated elsewhere. For example, you may want to -import your key from the mobile Wallet, so that you can submit transactions that may not be -supported in the mobile Wallet. The `--seed` command supports seed phrase imports. - -Enter the command: - -``` -$ helium-wallet create basic --seed -``` - -After you press enter, you will be prompted for your seed words. - -:::tip - -Remember, your seed is your private key. Keep it safe and **private**. When you import the seed as a -CLI Wallet, you do not "log yourself out" of your mobile Wallet; you've only copied the private key -from your mobile Wallet into the CLI. Mobile wallet and CLI Wallet both have a local copies of the -key and can submit transactions to the blockchain API. - -::: - ---- - -## Export to Helium Wallet App - -Helium Wallets created using the CLI can be exported to the Helium Wallet App. - -:::note Version Requirements - -The `export` feature requires: - -- `helium-wallet-rs version 1.7.7` or later, available - [on GitHub](https://github.com/helium/helium-wallet-rs/tags) -- [Helium Wallet App](/wallets/helium-wallet-app) version `1.3.0` or later, available for - [iOS](https://apps.apple.com/us/app/helium-hnt-wallet/id1609525848) and - [Android](https://play.google.com/store/apps/details?id=com.helium.wallet.app) - -::: - -### Export from CLI - -Assuming you have already created a CLI Wallet, exporting the Wallet is straight forward. Simply -run: - -```bash -$ helium-wallet export -``` - -You will be prompted for the Wallet Password, (this is _not_ your seed phrase, this password was -input when the Wallet was created.) - -Next, you will be prompted to enter an `Export Password` twice. This password will be used in the -Helium Wallet App. - -A QR Code will be generated and shown in your terminal. - - - -### Import to Helium Wallet App - -Once you have generated a QR code and have your `Export Password` ready, open the Helium Wallet App -and swipe to the `Import` Screen. - -
-
-
- -
-
- - Step 1. Tap on the CLI option in the bottom Menu to begin. - -

- The **CLI** import button is located at the bottom of the **Import** screen in the Helium - Wallet App. -

-
-
-
-
-
- -
-
- Step 2. Scan the QR Code -

- When you are ready, tap the Scan QR Code button and aim your phone camera at the QR - Code generated in your terminal. -

-
-
-
-
-
- -
-
- - Step 3. Enter Export Password - -

- After a successful scan, you will be prompted for the Export Password you - created as part of the export CLI command steps above. -

-
-
-
-
-
- -
-
- Step 4. Decrypt and Naming -

- Tap the Decrypt and Import button, and give the newly imported Wallet an identifiable - name. -

-
-
-
- ---- - -## Pay Transaction Example - -If you explore the pay command, you will see the following: - -```bash -$ helium-wallet pay --help -helium-wallet-pay 1.7.7 -Send one (or more) payments to given addresses. - -The payment is not submitted to the system unless the '--commit' option is given. - -USAGE: - helium-wallet pay - -FLAGS: - -h, --help Prints help information - -V, --version Prints version information - -SUBCOMMANDS: - help Prints this message or the help of the given subcommand(s) - multi Pay multiple payees - one Pay a single payee -``` - -Let's explore the `one` subcommand to figure out usage for a single payment: - -```bash -$ helium-wallet pay one --help -helium-wallet-pay-one 1.7.7 -Pay a single payee. - -Note that HNT only goes to 8 decimals of precision. - -USAGE: - helium-wallet pay one [FLAGS] [OPTIONS]
[token] - -FLAGS: - --commit Commit the payment to the API - -h, --help Prints help information - -V, --version Prints version information - -OPTIONS: - --fee Manually set the DC fee to pay for the transaction - --memo Memo field to include. Provide as a base64 encoded string [default: AAAAAAAAAAA=] - --nonce Manually set the nonce to use for the transaction - -ARGS: -
Address to send the tokens to - Amount of token to send - Type of token to send (hnt, iot, mobile, hst) [default: hnt] -``` - -The `USAGE` section is very helpful: `helium-wallet pay one [OPTIONS]
`. - -For example, if I want to send 5.0 HNT to `14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz5S`, it -will look like this: - -```bash -$ helium-wallet pay one 14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz5S 5 --commit -``` - -The `--commit` FLAG is a global option to the `pay` command - you'll recall it was documented at the -scope of `helium-wallet pay --help`. It's critical for **all transactions** to confirm that you want -the transaction to be submitted to the blockchain API. - -When you commit a transaction to the API, you will be provided with a **transaction hash**. This is -a unique identifier for your transaction on the blockchain and you can track your transaction status -using the API endpoint: - -```bash -https://api.helium.io/v1/pending_transactions/YOUR_HASH_HERE -``` - ---- - -## Transfer Hotspot from 24-word Wallet - -If a Hotspot is transferred to a 24-word Wallet, that is ok! However, most Maker Hotspot Management -Apps do not currently support 24-word Wallets. - -To transfer a Hotspot from a 24-word Wallet to a 12-word Wallet, follow the steps below. - -1. Create a 12-word Wallet to receive the Hotspot using the - [Helium Wallet App](/wallets/helium-wallet-app) and record the Public Key. - -2. Download and install the [Helium Command Line Wallet](/wallets/cli-wallet#installing-cli-wallet) - as outlined above. and navigate to the installation directory. -3. Import your 24-word seed phrase to the CLI Wallet. - -```bash -$ helium-wallet create basic --seed --output my-24-word-wallet.key -``` - -| argument | description | -| -------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -| `create basic` | create a Wallet with a single key, as opposed to a [sharded wallet](/wallets/cli-wallet#sharded-wallet) | -| `--seed`. | import with an existing seed phrase using the 24-word list. | -| `--output my-24-word-wallet.key` | output the Wallet key file to a location of your choosing, in this case to a file called `my-24-word-wallet.key` | - -4. Find the Gateway ID of the Hotspot to be transferred by running - -```bash -$ helium-wallet hotspots list -``` - -5. Perform a Dry Run of the Hotspot transfer - -```bash -$ helium-wallet -f my-24-word-wallet.key hotspots transfer -``` - -| argument | description | -| -------------------------- | ----------------------------------------------------------------------- | -| `-f my-24-word-wallet.key` | use a file for the Hotspot Wallet, in this case `my-24-word-wallet.key` | -| `hotspots transfer` | run a Hotspot transfer | -| `` | the gateway id you collected from Step 4 above | -| `` | the public Wallet Address to receive the Hotspot | - -6. The above will do a test try and have an output you should verify. - -7. Now it's time to run it for real. - -:::danger Point of No Return - -Including the `--commit` flag submits the transfer transaction to the blockchain. - -**There is no going back from this** so please take your time and double-check your inputs. - -::: - -```bash -$ helium-wallet -f my-24-word-wallet.key hotspots transfer --commit -``` - -8. Once the transfer transaction is validated by the blockchain, your Hotspot will appear in the new - 12-word Wallet. diff --git a/docs/wallets/helium-wallet-app.mdx b/docs/wallets/helium-wallet-app.mdx index d6c49a768..b388e5cbf 100644 --- a/docs/wallets/helium-wallet-app.mdx +++ b/docs/wallets/helium-wallet-app.mdx @@ -10,13 +10,12 @@ slug: /wallets/helium-wallet-app import useBaseUrl from '@docusaurus/useBaseUrl' -# Helium Wallet App -
-
+
+
-
+
+
-The Helium Wallet app is the trusted way to manage your Helium Tokens and identity. - -Some notable features: - -- Multiple Account Support (maximum of 10) -- Ledger Balance -- Address Book -- Verify your Helium Identity -- Lock-up tokens for voting power and staking rewards -- Voting on Governance -- Multiple Recipient Payment Support -- Claiming tokens from Hotspots to your Wallet -- Transfer NFTs representing Hotspot ownership -- Exchange one Helium Token for another or SOL +The Helium Wallet app is the trusted way to manage your Helium account. -All Hotspot Management (diagnostics, asserting location, adding Hotspots, etc) should be done via -the [Maker App](/hotspot-makers) available from the manufacturer. +## Accounts -## Wallets and Accounts - -### Importing An Existing Wallet +### Creating A New Account -If you have an existing Helium Wallet, either one created from the original Helium Hotspot App or -using CLI, you can import it into the Helium Wallet app. - -| Account Type | Action | -| :------------: | :------------------------------------------------------------------------------------ | -| 12-word wallet | Tap the `12 Word` button and enter in the 12-word seed phrase, in the original order. | -| 24-word wallet | Tap the `24 Word` button and enter in the 24-word seed phrase, in the original order. | -| Ledger | Tap the Ledger option and follow the in-app prompts to pair with the hardware wallet. | +Accounts created with the Helium Wallet app are generated with a 24-word seed phrase. These 24 words +in the correct order are the **only** way to access the account and can **never** be recovered if +lost. Whomever has the 24-word seed phrase controls the wallet, meaning that they are considered the +owner of all tokens, Hotspots, or NFTs in the account. -### Creating A New Wallet +### Importing An Existing Account -Wallets created with the Helium Wallet app are generated with a 24-word seed phrase. These 24 words -in the correct order are the **ONLY** way to access the Wallet and can never be recovered if lost. -**They should never be shared**, as whoever has them is considered the owner of all Tokens, -Hotspots, or NFTs. Anyone asking for them is guaranteed to be a scammer. - -**Taking and storing screenshots of the seed words is not recommended, as it is not a** secure way -to store them. Screenshots and photos stored or backed up in the cloud can easily be hacked and -funds stolen. +If you have an existing Helium account you can import it into the Helium Wallet app. -## Working With Multiple Wallets +| Account Type | Action | +| :-----------------: | :------------------------------------------------------------------------------------ | +| 12-word seed phrase | Tap the `12 Word` button and enter the 12-word seed phrase, in the original order. | +| 24-word seed phrase | Tap the `24 Word` button and enter the 24-word seed phrase, in the original order. | +| Ledger | Tap the Ledger option and follow the in-app prompts to pair with the hardware wallet. | -You are able to create/import multiple Wallets, each with their unique set of 12 or 24 words. You -can move between Wallets by pressing on the Wallet name at the top of the screen. A pop-up screen -with the multiple Wallet names shows up and choose the Wallet name you need. When you tap on -Settings, they will be for the selected Wallet. +## Working With Multiple Accounts -:::info How Many Wallets? - -There is a limit of 10 Wallet accounts (testnet + mainnet combined) per install. - -::: +The Helium Wallet App supports creating or importing up to 10 accounts, each with its own unique set +of 12 or 24 words. Navigate between accounts by pressing on the account name at the top of the +screen. An account selector allows toggling between different onboarded accounts. The settings +screen will apply to the selected account. ## Tokens Supported -The Helium Wallet will display the quantity in your Wallet and price for: +The Helium Wallet will display the token balances and fiat value in your account for: -HNT - in USD or your defined currency MOBILE - in USD or your defined currency IOT- in USD or your -defined currency DC- in USD (Not transferable) SOL- in USD or your defined currency +**HNT** - in USD or your defined currency +**MOBILE** - in USD or your defined currency +**IOT**- in USD or your defined currency +**DC** - in USD (Not transferable) +**SOL** - in USD or your defined currency +**USDC** - in USD or your defined currency -No other tokens held in your Wallet will be displayed, the value of other tokens will not be shown. +No other tokens held in your account will be displayed in the Helium Wallet App. ## Send And Request Tokens @@ -116,59 +93,46 @@ No other tokens held in your Wallet will be displayed, the value of other tokens src={useBaseUrl('img/wallets/helium-wallet-app/send-request-banner.png')} /> -The Blue Send button allows you to choose the imported Wallet you wish to send from, and choose a -Contact you wish to send HNT to. - -The Green Request button allows you to quickly generate a QR code for someone to scan (which -provides your Wallet address) or generate a link to share via email or text. You can also enter in -the amount you are requesting, if it is a known quantity, and add a note. - -### Multiple Recipient Payment Support - -Multiple recipient payments are now supported on the Helium Wallet app. This is most useful for -those that need to wait for a payment transaction to clear and appear on the blockchain before -sending the next payment. - -:::tip - -You can create your own [QR codes](/wallets/app-wallet/deep-links-and-qr-codes/) to scan, which can -include an address/alias to send payment to. - -The new payment type supported in the Helium Wallet app can have multiple payees which can also be -included in a QR code. - -You can also form a Burn transaction in QR Code format. - -::: - -## Voting - - - -When HIPs (Helium Improvement Proposals) are being voted on, you can quickly and easily vote for or -against any Active votes. Tapping on Closed Votes shows a historical record of past HIPs and how the -vote was decided. + + + + + + +The blue send button allows you to choose the account you wish to send from and choose one or more +addresses or contacts you wish to send tokens to. + + + + + + + +The green request button allows you to quickly generate a QR code of your account's public address +for someone to scan or generate a link to share via email or text. You can also enter the amount you +are requesting or add a note. ## Helium Identity -Use the new Helium Wallet app to connect to various dApps like Crowdspot and authenticate your -identity on the Helium blockchain. - -## Transaction Filters - - - -| Filter | Description | -| :------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| All Transactions | Shows all interactions with the blockchain. | -| Mining Rewards | Shows the mining rewards the Wallet has earned from any included Hotspot. | -| Payments | Lists all payments that were either sent or received. | -| Hotspots | Lists the Hotspots associated with the Wallet. Note that any interactions with the Hotspots, such as diagnostics and asserting location, etc., will need to be done from the Maker App. This list is for reference only as Hotspot actions are not available in this Wallet app. | -| Burn Transactions | Lists Token Burn Transactions. (e.g., Data Credits burned to vote on a HIP) | -| Pending Transactions | Lists any transactions that have been submitted but have not yet been validated/cleared on the blockchain. | +Use the Helium Wallet App to connect to dApps and authenticate your identity on the Solana +blockchain. Using the in-app browser, access dApps such as Jupiter Aggregator or +[lock-up your tokens and vote using Modular Governance](https://modular-governance.helium.com/). ## Address Book And Contacts @@ -177,12 +141,12 @@ identity on the Helium blockchain. src={useBaseUrl('img/wallets/helium-wallet-app/address-book-banner.png')} /> -This feature allows you to save names/nicknames and related Wallet addresses for those you may wish -to send tokens to. Contacts are displayed in alphabetical order, and are searchable by name or -Wallet address. There is no limit to the number of Contacts you can have. +This feature allows you to save names/nicknames and related account addresses for accounts you may +wish to send tokens to. Contacts are displayed in alphabetical order and are searchable by name or +account address. There is no limit to the number of contacts you can have. -Tapping on a Contact displays the full Helium or Solana address as well as the Nickname field, which -can be adjusted at any time. +Tapping on a contact displays the public address as well as the Nickname field, which can be +adjusted at any time. ## Settings @@ -193,16 +157,27 @@ can be adjusted at any time. src={useBaseUrl('img/wallets/helium-wallet-app/settings-wallet-account-banner.png')} /> -Each Account imported to the Helium Wallet app has separate settings. +Each account imported to the Helium Wallet app has separate settings. + +| Setting | Description | +| :-------------: | :------------------------------------------------------------------------------------------------------------------------------------------------- | +| Account Alias | Give your account a name to help separate it from other accounts managed in the Helium Wallet App. | +| Default Account | When using multiple accounts, this toggle will determine which one is the default and will show first whenever the Helium Wallet app is opened. | +| Copy Address | Copies the account address to your device's clipboard. | +| Share Address | Provides QR code so someone can scan your account's public address or allows you to quickly share it via email or text. | +| Remove Wallet | Logs you out of the current account. The original seed phrase is required to ensure the words are safely backed up since they cannot be recovered. | + +### Hotspots Wallet Backup -| Setting | Description | -| :-------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Account Alias | You can rename the Wallet here for organization (does not affect your Wallet address or HNT) | -| Default Account | When using multiple Wallets, this toggle will determine which one is the default and will show first whenever the Helium Wallet app is opened. | -| Reveal Words | While logged in, you can view your 12-word or 24-word seed phrase. These are required for login/logout of a Wallet and can never be recovered if lost. Lose these, lose the Wallet and everything it contains. | -| Copy Address | Copies the Wallet address to your device's clipboard | -| Share Address | Provides QR code so someone can scan your Wallet address and allows you to quick share it via email or text. | -| Sign Out | logs you out of the current wallet. The original 12-word or 24-word seed phrase is required, to ensure the words are safely backed up since they cannot be recovered. | +If someone has your private key, they will have full control of your account. This includes the +ability to remove tokens and Hotspots. +Do **not** enter these words into any untrusted website. Any person or website asking for these keys +is likely a scammer. + +| Setting | Description | +| :----------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Reveal Words | While logged in, you can view your 12-word or 24-word seed phrase. These are required for login/logout of an account and can never be recovered if lost. Lose these, lose the Wallet and everything it contains. Back them up in a secure place. | +| Reveal Private Key | The private key of your account can be used to import the account into other Solana-compatible wallet apps such as Solflare, Phantom, Coinbase Wallet, or Backpack. | ### Security Settings @@ -211,14 +186,14 @@ Each Account imported to the Helium Wallet app has separate settings. src={useBaseUrl('img/wallets/helium-wallet-app/settings-security-banner.png')} /> -These Settings keep the Helium Wallet app secure. +These settings keep the Helium Wallet app secure. -| Setting | Description | -| :----------------------: | :------------------------------------------------------------------------------------------------- | -| Enable PIN | Set up a PIN code for accessing the Wallet from the device | -| Require PIN | Set time limit when PIN is required to log back in (Immediately, 1min, 5min, 15min, 1hr, 4hrs) | -| Reset PIN | Change the current PIN to a new one (original PIN is required to update this) | -| Require PIN for Payments | This additional security option requires the PIN to be entered before any HNT payment can be sent. | +| Setting | Description | +| :----------------------: | :---------------------------------------------------------------------------------------------- | +| Enable PIN | Set up a PIN code for accessing the Wallet from the device. | +| Require PIN | Set time limit when PIN is required to log back in (Immediately, 1min, 5min, 15min, 1hr, 4hrs). | +| Reset PIN | Change the current PIN to a new one (the original PIN is required). | +| Require PIN for Payments | This additional security option requires the PIN to be entered before any payment can be sent. | ### App Settings @@ -229,42 +204,34 @@ These Settings keep the Helium Wallet app secure. The Helium Wallet app has interface settings that can be adjusted to your liking. -| Setting | Description | -| :-----------------: | :---------------------------------------------------------------------- | -| Language | Change which language the app text will be displayed. | -| Currency | Change which currency the app displays the market equivalent to the HNT | -| Convert to Currency | Shows selected currency (at market rate) instead of HNT | -| App Version | Notes the version of the app that is installed | +| Setting | Description | +| :------: | :------------------------------------------------------------------------------ | +| Language | Change which language the app text will be displayed in. | +| Currency | Change which currency the app displays the market equivalent of token balances. | ### Developer Settings -Developer settings should be used intentionally. If you are not a Developer, or not sure what these -settings do, it is best to leave them `off` by default. +Developer settings should be used intentionally. If you are not a developer or are not sure what +these settings do, it is best to leave them unchanged. -| Setting | Description | -| :------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Enable Testnet | Testnet is typically for developers. It allows you to create a test account and get TNT (which holds zero monetary value), which can be used to test apps and transactions without burning real HNT. When toggled on, you create a testnet specific account. | +| Setting | Description | +| :------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Solana Cluster | Offers the ability to operate outside of Solana Mainnet. Devnet is typically for testing or demo purposes. Your account will operate on the selected network Solana Devnet. Hotspots or Token balances are not replicated across clusters. The in-app faucet can be used to fund devnet accounts. | --- -### Examine Hotspots - -You can now examine your Hotspots by clicking the Collectables Tab. +## 12-Word And 24-Word Seed Phrases -Let us know via Discord if you experience any issues! +When a Helium account is created with the Helium Wallet app, a 24-word "Seed Phrase" is generated. -
- -
+Users who created their Helium account using the Helium Hotspot app will have a 12-word seed phrase. +While the Helium Wallet app accepts 12-word seed phrases, all new Helium Wallets are created with +24-word seed phrases. -### Ledger Wallet +Read more about [Helium Wallet Seed Phrase](/wallets/wallet-seed-phrase). -Hardware Ledgers are not yet compatible with the Helium Wallet app on the Solana blockchain. Current -advice is to migrate using the tool mentioned below and switch to using -[Solflare](https://solflare.com/). +:::caution Before Deleting Helium Wallet Apps -See [Ledger Wallet migration guide](/solana/migration/ledger) for guidance on how to migrate Ledger -Wallets to Solana. +Do not uninstall the Helium Wallet app without first writing down the seed phrase. -See [Ledger Wallet Hardware](/wallets/ledger/) for how a Ledger wallet was configured for HNT on the -Helium blockchain. +::: diff --git a/docs/wallets/l1-migrate.mdx b/docs/wallets/l1-migrate.mdx new file mode 100644 index 000000000..c9a7ea713 --- /dev/null +++ b/docs/wallets/l1-migrate.mdx @@ -0,0 +1,18 @@ +--- +id: l1-migrate +title: L1 Migration Tool +pagination_label: Wallet User +sidebar_label: Wallet User +description: Helium L1 Wallet Migration Tool +image: https://docs.helium.com/img/link-image.png +slug: /wallets/l1-migrate +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' +import { MigrateWallet } from '@theme/MigrateWallet' + +You can migrate a wallet using the widget below by entering a Helium or Solana wallet address and +clicking the "Seed Wallet" button. Wallets seeded/migrated will have 0.00139088 SOL deposited in +them. + + diff --git a/docs/wallets/ledger-wallet.mdx b/docs/wallets/ledger-wallet.mdx new file mode 100644 index 000000000..632cf052b --- /dev/null +++ b/docs/wallets/ledger-wallet.mdx @@ -0,0 +1,182 @@ +--- +id: ledger-wallet +title: Ledger +pagination_label: Ledger +sidebar_label: Ledger +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /wallets/ledger-wallet +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +# Ledger Hardware Wallet + +The Helium tokens have support for Ledger Hardware Wallets via the Solana blockchain. Ledger allows +for: + +- Viewing account address(es) and balances +- Transferring tokens +- Signing transactions + +At this time, Hotspot management actions such as onboarding or asserting location are not supported. +You will need to perform these actions within the +[Helium Wallet App.](https://docs.helium.com/wallets/helium-wallet-app) + +Helium HNT, MOBILE and IOT are Solana SPL tokens and are supported by the Solana App for Ledger but +not directly in Ledger Live. + +Installation instructions for the Solana App are on +[Ledger Solana support page.](https://support.ledger.com/article/360016265659-zd) Remember to +configure [blind signing.](https://support.ledger.com/article/4499092909085-zd) + +## Basic Setup Guide Using Helium Black Wallet App and Ledger + +1. Turn on Ledger by pressing left button +2. Using on screen Guide to Setup as new device +3. Set the access PIN for the ledger +4. Record the 24 word recovery phrase (don't share this, store in safe place) +5. Install desktop version of [Ledger Live App](https://www.ledger.com/ledger-live) +6. Connect Ledger to your computer with USB cable +7. Open Ledger Live Desktop App +8. Click on "My Ledger" at the bottom of the left menu stack +9. Approve the connection on Ledger device by clicking both buttons +10. Look for banner at the top of the desktop Ledger Live window for FW update notification +11. Approve updates on the ledger device as needed + :::important + + It may take multiple serial updates to get your Ledger up to date. + + ::: + +12. In desktop Ledger Live window go to settings -> Developer Mode -> Enable +13. In desktop Ledger Live window, find Solana App and click install +14. On Ledger Device start Solana app by clicking both buttons +15. On Ledger Device navigate to Settings in Solana App and enable "Allow Blind Signing" +16. Open Helium Black Wallet App on smartphone +17. In Black Wallet App navigate to Add/Import Wallet +18. In Black Wallet App select Ledger from the options at the top +19. In Black Wallet App select your Ledger device from the list (should be only one in most cases) +20. In Black Wallet App select wallet to import (if more than one, import all for now) +21. On Ledger Device approve the wallet import +22. On Black Wallet App, you should now see your Helium friendly wallet with zero balance. +23. On Black Wallet App, tap the pub key / address above the wallet balance to copy your pub key to + clipboard +24. Save your wallet pubkey somewhere handy, this is destination for transfers into your cold + wallet. + +## Testing your Ledger Cold Wallet + +Before making any significant transfers into your new Ledger wallet, it is best to make a series of +test transfers in and out of your wallet. + +1. Open the Helium Black Wallet App on your smartphone +2. Navigate to your Ledger Wallet from steps above +3. Copy the pub key of your Ledger Wallet +4. Make a test transfer of SOL into your new Ledger Wallet + :::tip + + Transfers out of your wallet will require SOL to pay fees, so start by adding at little SOL e.g. + 0.1 SOL to your wallet. + + ::: + +5. Copy the pub key of an external wallet (either Coinbase or other Black Wallet App native wallet) +6. Make a test transfer of SOL out of your new Ledger Wallet + :::note + + This will require your Ledger to be PIN unlocked and Solana App started and "ready" to complete + + ::: + +7. Review and Approve the transaction on your Ledger Device when prompted +8. Repeat the Process with HNT or IOT again with small amounts +9. After your have tested transfers in and out of your Ledger wallet, you are ready for safe cold + storage using your Ledger Wallet. + +## Using Third Party Wallet Apps + +Users may alternatively use Solflare or Phantom to +[access SOL/SPL tokens with Ledger.](https://support.ledger.com/article/7723954701469-zd) + +Solflare, Phantom and other non-custodial wallets can import the private key from the Helium Wallet +App. Follow the instructions on our using +[Third Party Wallets](https://docs.helium.com/wallets/third-party-wallets#importing-helium-accounts-into-solana-wallets) +documentation. + +## Ledger Helium L1 to Solana Migration + +If you have an unmigrated Ledger wallet that existed on the Helium L1 prior to the migration to +Solana on April 18th, 2023, you will need to follow these instructions. + +### Video Walkthrough + +import { YouTube } from 'mdx-embed' + + + +--- + +### Installing the Helium-Solana App + +Update your Ledger firmware to at least 2.1.0, preferably 2.4.x before you start. + +As of now, we are still waiting on Ledger to release our app. Until then, to install you must follow +these steps: + +1. Open Ledger Live. +2. Go to Settings (top right corner) +3. Click `Experimental Features` +4. Enable `Developer Mode` +5. Install the [Helium-Solana Ledger App](https://github.com/helium/app-helium-solana) as you + normally would. +6. Close Ledger Live + +--- + +### Migrating + +The following utility will migrate all tokens from the Helium derivation path `44'/904'/n'/0'` to +the Solana derivation path `44'/501'/n'/0'`. + +Ledger users will need to update their Helium Ledger App to a version that's pending release. This +upcoming version will use the Solana private key derivation path that moves all your tokens and +balances over to Solana. You may need to uninstall any Solana Ledger Apps during the Wallet +migration process. + +--- + +### Migration Tool + +Your public key will change on Solana, but the private key will remain the same. Note this app only +works with Chrome, Brave, or other Chromium-based web browsers. + +- [Helium-Solana Ledger App](https://github.com/helium/app-helium-solana) now available from Ledger + Live (ensure Developer Mode is enabled) +- [Solana Ledger App](https://support.ledger.com/article/360016265659-zd) using Ledger Live + +:::note Close Ledger Live + +**Before starting these steps, close the Ledger Live application or the transactions will fail.** + +::: + +import { LedgerMigration } from '@theme/LedgerMigration' + + + +--- + +### Derivation Paths and your new Public Key + +The Helium Ledger App uses `ED25519` keys, similarly to Solana, but at a different derivation path. + +This means that, while seed phrases are the same, private keys are different on Solana. + +In order to get around this, when you run the migration, the migration application will ask you to +use the old derivation path to approve sending all of your Hotspots, tokens, etc. to the new +derivation path. + +More information on Derivation paths: +[Derivation Paths Explained](https://www.youtube.com/watch?v=9_9IObnJdEY) a Youtube video from +[solandy.sol](https://www.youtube.com/@Solandy) diff --git a/docs/wallets/ledger.mdx b/docs/wallets/ledger.mdx deleted file mode 100644 index 1753a1498..000000000 --- a/docs/wallets/ledger.mdx +++ /dev/null @@ -1,405 +0,0 @@ ---- -id: ledger -title: Ledger -pagination_label: Ledger -sidebar_label: Ledger -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /wallets/ledger ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -# Ledger Hardware Wallet - -The Helium blockchain has support for Ledger Hardware Wallets. When installed on a Nano S or Nano X, -the Helium Ledger App allows you to: - -- View your Helium address(es) and balances -- Issue payment to one address - -> This guide will walk through using Helium on a Ledger Nano S and is similar to the setup on a -> Ledger Nano X. - -:::info - -Ledger CLI using experimental mode is supported at this time. Work to enable HNT in Ledger Live in -addition to a CLI is ongoing. - -::: - -## Installing the Helium ledger application - -- Go to `Settings` > `Experimental features` and toggle `Developer mode` to **On** - - - -- Once enabled, go to `Manager` and search "Helium". - -:::info - -If you can not find "Helium", you may need to update your Ledger Live. - -Check your version of Ledger Live by going to `Settings` > `About` > `Version`. - -::: - -- Click Install. - - - -The Helium App has been signed by Ledger and is trusted. It is now installed on your Ledger device! - -Start the Helium app by selecting it on the Ledger screen. The "Waiting for commands..." prompt -should be on the screen. - -## Execute Commands - -:::info - -Make sure Ledger Live is closed before proceeding! The companion app cannot run when Ledger Live is -blocking the USB device. - -::: - -To interact with the app on Ledger, you will need to use the Helium Ledger CLI (CLI, for short). -Head to [Releases in the GitHub repo](https://github.com/helium/helium-ledger-cli/releases) and -download the most recent release for your operating system. - -> We'll use macOS for the remainder of this example. - -- Download the release for macOS `helium-ledger-cli-v2.2.3-x86-64-macos.tar.gz` and unzip the file -- Navigate to where you downloaded the release on your computer in Terminal -- Make sure your Ledger is connected to your computer, then type `./helium-ledger-cli` - -```bash -~/helium-ledger-cli-v2.2.3-x86-64-macos$ ./helium-ledger-cli -Communicating with Ledger - follow prompts on screen -helium-ledger 2.2.3 -Interact with Ledger Nano S for hardware wallet management - -USAGE: - helium-ledger-cli [OPTIONS] - -FLAGS: - -h, --help Prints help information - -V, --version Prints version information - -OPTIONS: - --account Select account index to stake from [default: 0] - --emulator Enable interaction with emulator for development and testing by configuring port for - TCP connection here (typically 9999 or 40000) - -SUBCOMMANDS: - balance Get wallet information - burn Burn to given address - help Prints this message or the help of the given subcommand(s) - pay Pay a given address - securities Transfer Security Tokens -``` - -## Check Balance and Receive HNT - -Type `./helium-ledger-cli balance` to see your new Ledger address and balance. - -```bash -~/helium-ledger-cli-v2.2.3-x86-64-macos$ ./helium-ledger-cli balance -Communicating with Ledger - follow prompts on screen -Ledger running Helium App v2.2.4 - -helium-ledger/2.2.3 -+-----------------------------------------------------+-------------+--------------+-----------------+ -| Address | Balance HNT | Data Credits | Security Tokens | -+-----------------------------------------------------+-------------+--------------+-----------------+ -| ACCOUNT_0_REDACTED | 0.00000000 | 0 | 0.00000000 | -+-----------------------------------------------------+-------------+--------------+-----------------+ -``` - -:::warning - -Do not simply rely on what you see on the CLI, but verify it matches what is displayed on the -Ledger. - -::: - -:::info - -You may add the `--qr` option to the command to display your address in the form of a QR code. - -::: - -To receive HNT, simply provide your address in the base58 format output from the CLI or by using the -QR code. - -## Multiple Wallet Support - -Your Ledger hardware Wallet can support many accounts per supported coin, and this is no different -for HNT. To interact with a Wallet other than the default 0th account, you place a `--account N` -flag before the command. So, the balance command becomes: - -> `helium-ledger-cli --account 1 balance` - -```bash -~/helium-ledger-cli-v2.0.0-x86-64-macos$ ./helium-ledger-cli --account 1 balance -Communicating with Ledger - follow prompts on screen -Ledger running Helium App v2.2.4 - -helium-ledger/2.2.3 -+-----------------------------------------------------+-------------+--------------+-----------------+ -| Address | Balance HNT | Data Credits | Security Tokens | -+-----------------------------------------------------+-------------+--------------+-----------------+ -| ACCOUNT_1_REDACTED | 0.00000000 | 0 | 0.00000000 | -+-----------------------------------------------------+-------------+--------------+-----------------+ -``` - -This `--account N` prefix applies to all commands. The balance command has a special flag, `--scan` -that you can place _after_ the command. This allows you to scan all the Wallets from 0 to N. For -example: - -> `helium-ledger-cli --account 8 balance --scan` - -```bash -~/helium-ledger-cli-v2.0.0-x86-64-macos$ ./helium-ledger-cli --account 8 balance --scan -Communicating with Ledger - follow prompts on screen -Ledger running Helium App v2.2.4 - -helium-ledger/2.2.3 -+-------+-----------------------------------------------------+-------------+--------------+-----------------+ -| Index | Address | Balance HNT | Data Credits | Security Tokens | -+-------+-----------------------------------------------------+-------------+--------------+-----------------+ -| 0 | ACCOUNT_0_REDACTED | 0.00000000 | 0 | 0.00000000 | -| 1 | ACCOUNT_1_REDACTED | 0.00000000 | 0 | 0.00000000 | -| 2 | ACCOUNT_2_REDACTED | 0.00000000 | 0 | 0.00000000 | -| 3 | ACCOUNT_3_REDACTED | 0.00000000 | 0 | 0.00000000 | -| 4 | ACCOUNT_4_REDACTED | 0.00000000 | 0 | 0.00000000 | -| 5 | ACCOUNT_5_REDACTED | 0.00000000 | 0 | 0.00000000 | -| 6 | ACCOUNT_6_REDACTED | 0.00000000 | 0 | 0.00000000 | -| 7 | ACCOUNT_7_REDACTED | 0.00000000 | 0 | 0.00000000 | -+-------+-----------------------------------------------------+-------------+--------------+-----------------+ -``` - -:::info - -Up to 255 Wallets may be used on the Ledger, but the `--scan` command fetches each address -one-by-one; it will take quite a long time to get all 255 addresses. - -While this convenience feature exists, **double-check the address using the screen of the Ledger** -(i.e.: call the specific `--account N balance` without the `--scan` option) before sending any -assets. A nefarious CLI application could provide fake addresses. - -::: - -## Supported Transactions - -We will document an example `pay` transaction here, but the documents may lag changes in the app. -It's good to get familiar with the built-in documentation of the CLI. At the top level, you can do -`./helium-ledger-cli --help` to get an understanding of what transactions might be available. - -At the time of writing, you'll see the following "subcommands" are available: - -- **balance**: get wallet information -- **pay**: pay a given address - -To understand how to use a particular command, simply call the command with the addition of the -`--help` flag. For example: - -> `./helium-ledger-cli --help` - -```bash -~/helium-ledger-cli-v2.0.0-x86-64-macos$ ./helium-ledger-cli pay --help -Communicating with Ledger - follow prompts on screen -helium-ledger-cli-pay 2.2.3 -Pay a given address - -USAGE: - helium-ledger-cli pay [OPTIONS]
- -FLAGS: - -h, --help Prints help information - -V, --version Prints version information - -OPTIONS: - --fee Manually set the DC fee to pay for the transaction - --memo Memo field to include. Provide as a base64 encoded string [default: AAAAAAAAAAA=] - --nonce Manually set the nonce for the transaction - -ARGS: -
Address to send the tokens to - Amount of HNT to send -``` - -The `USAGE` example shows you what the command should look like and the `ARGS` are documented at the -bottom. Always refer to the built-in help menu over these docs. - -Even if you rely on the `--help` menu from here on out, the `pay` command in this guide will be good -practice using the Ledger and make sure you understand the security model. - -## Sending HNT - -1. On the CLI, type `./helium-ledger-cli pay
` to pay in HNT. Press `return`. -2. On the Ledger, follow the prompts and confirm the transaction. -3. The CLI should show a confirmation of the transaction. - -```bash -$ ./helium-ledger-cli pay PAYEE_ACCOUNT 0.1 -Communicating with Ledger - follow prompts on screen -Ledger running Helium App v2.2.3 - -Creating the following transaction: -+-----------------------------------------------------+----------------+-------+--------+ -| Payee | Pay Amount HNT | Nonce | DC Fee | -+-----------------------------------------------------+----------------+-------+--------+ -| PAYEE_ACCOUNT | 0.10000000 | 6 | 35000 | -+-----------------------------------------------------+----------------+-------+--------+ -WARNING: do not use this output as the source of truth. Instead, rely on the Ledger Display -``` - -:::warning Use the screen of the Ledger to confirm everything you do. - -The CLI App could be nefarious (maybe you downloaded the wrong one, maybe somebody changed the -program on your computer, etc.). The Ledger on the other hand will only load applications signed by -Ledger, so your security relies on you verifying the transaction details on the screen. - -To be clear, do not compare the output to the output from the CLI shown above (the nefarious app -might be showing you the fake address), but instead from your original source. - -::: - -Verify the parameters of the transaction on the screen. Addresses are long and need to be scrolled -(hold the right or left button only). Once you are satisfied with the field, click both buttons to -confirm: - - - -Once you click the "Sign Transaction?" confirmation, the transaction will be signed by the Ledger -and submitted to the blockchain by the CLI application: - -```bash -Successfully submitted transaction to API: -+---------+---------------------------------------------+ -| Network | Hash | -+---------+---------------------------------------------+ -| mainnet | HASH | -+---------+---------------------------------------------+ -To check on transaction status, monitor the following URL: - https://api.helium.io/v1/pending_transactions/HASH -``` - -Use the link displayed to check on your transaction status. - -## Common Issues - -### Can't download the zip file because it is untrusted. - -1. In the downloads bar of your browser, click the down arrow and select `Keep`. - - - -### macOS "Developer cannot be verified" Error when running commands in Terminal - -1. Go to System Preferences > Security & Privacy -2. Allow App downloaded from `App Store and Identified Developers` -3. You may need to click the lock icon and give the CLI permissions -4. Run the command in CLI again - -
-
-
- Step 1. Dismiss "Developer cannot be verified" error -

- Due to macOS security features, the first time you attempt to run the CLI you are likely to - encounter this error: -

-
-
- -
-
-
-
- -
-
- - Step 2. Open System Preferences > Security & Privacy{' '} - -

- Ensure that Allow App downloaded from App Store and Identified Developers is - selected. -

-

- An Allow Anyway dialog should appear where indicated in the sample image. As a - reminder, macOS is picky, and may not display this option right away, with the System - Preferences window open, try to run the CLI from in Terminal again until this option is - presented to you. -

-

- When it is, click Allow Anyway to continue. -

-
-
-
-
- Step 3. Run the CLI in Terminal again. -

- Run the CLI in Terminal again and you should now see a new pop up dialogue, click{' '} - Open to continue using the CLI. -

-
-
- -
-
-
- -### Failed opening hid device - -If you see this error `error: hid error: Failed opening hid device`, close Ledger Live software and -run the command again in the CLI. - -### Unable to access memory outside buffer bounds - -If on Ledger Live you see this error, unplug the ledger from your computer and plug it in again. - - - -## Security Model - -The attack surface for using the Helium Wallet app on a Ledger comprises the Helium Wallet app -itself, the system firmware running on the Ledger Hardware Wallet, the computer that the Ledger -Hardware Wallet is connected to, and possession/control of the device. For our purposes, the Helium -only needs to ensure its correctness and protect the user from the computer that the Ledger Hardware -Wallet app is connected to. Other attack surfaces are beyond our control; we assume that the user -physically security protocols. The goal of the Helium app is to achieve security given these -assumptions. controls the device, is not running malicious/buggy software on the device and follows -proper - -The main attack vector that we are concerned with, then, is a computer running malicious software. -This software may imitate programs like `helium-ledger-cli` in such a way that the user cannot tell -the difference, but secretly act maliciously. Specifically, the computer can do the following: - -1. Lie to the user about which actions it is performing. - -Example: the user runs `./helium-ledger-cli balance` to display their public key so that they may -receive payment, yet a hard-coded address is displayed - -2. Lie to the user about who the recipient is. - -Example: the user runs `./helium-ledger-cli pay IntendedAddress amount`, yet the program again uses -a hard-coded address - -To combat these attacks, the app makes use of the embedded display on the Nano S. Data sent to/from -the Ledger Hardware Wallet is displayed on the screen so the user can verify that the computer is -not lying about what it sent or received. In the interest of user-friendliness, we would like to -display as little information as possible, but each omission brings with it the risk of introducing -a vulnerability. Therefore, the app displays all data by default, and omits data only after -subjecting the omission to extreme scrutiny. diff --git a/docs/wallets/third-party-wallets.mdx b/docs/wallets/third-party-wallets.mdx new file mode 100644 index 000000000..2feeb7ba7 --- /dev/null +++ b/docs/wallets/third-party-wallets.mdx @@ -0,0 +1,104 @@ +--- +id: third-party-wallets +title: Third-Party Wallets +pagination_label: Third-Party Wallets +sidebar_label: Third-Party Wallets +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /wallets/third-party-wallets +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' +import { Tweet } from 'mdx-embed' + +Helium operates on the Solana blockchain, which allows any Solana-compatible wallet to be used with +your account. + +- Certain Hotspot actions are not universally supported. Special tooling in the Helium Wallet App + and Maker apps enables these functions: + - Claiming Hotspot rewards. + - Asserting or updating location + - Antenna setup + - Onboarding new Hotspots. + +## Solana Ecosystem Wallets + +Several browser and mobile app based wallets support Solana. Find the right one for you on the +[Solana Documentation](https://solana.com/learn/what-is-a-wallet). + +For advanced users or developers, Command Line Interface (CLI) wallets may be more appropriate. + +- [Solana CLI](https://docs.solanalabs.com/cli/) +- [Helium CLI](/wallets/cli-wallet) + +## Importing Helium Accounts into Solana Wallets + +In order to bring a Helium account from the Helium Wallet App into another Solana wallet, the +'Private Key' for the account must be used. Importing accounts with the 12 or 24-word seed phrase +will not result in your tokens appearing in the other wallet app. + +To be technical about it, the private key embeds the specific derivation path used by the Helium +Wallet App (`44'/904'/n'/0'`). Otherwise, using the seed phrase, the Solana wallet app will attempt +to resolve the account at a default path of `44'/501'/n'/0'` or `44'/501'/n'/0'/0'`. + +### Get Your Account's Private Key + +From within the Helium Wallet App, select "Reveal Private Key" from the settings menu. + +
+ +
This setting is accessible from the Helium Wallet App.
+
+
+ +From within the private key view, the key can be copied before pasting it into the new Solana wallet +app. + +
+ +
Tapping 'Reveal Private Key' will allow copying to clipboard.
+
+ +
+ +Copy the private key before switching to the Solana wallet that you wish to import your account +into. + +### Import the Private Key into a Solana Wallet + +For this walkthrough, we'll demonstrate importing a private key into +[Phantom](https://phantom.app/). In Phantom, first make a regular Solana wallet account. Then add a +new account from the 'Manage Accounts' menu in the settings screen. + +
+ +
Add your Helium account using "Import Private Key".
+
+
+ +Success! Your Helium tokens and Hotspots should now be visible within this other wallet – all backed +by the Solana blockchain. + +
+ +
Tokens and Hotspot NFTs are now accessible from within Phantom.
+
+ +## Video Walkthrough + + diff --git a/docs/wallets/wallet-seed-phrase.mdx b/docs/wallets/wallet-seed-phrase.mdx index 81e06fac9..84fadc95a 100644 --- a/docs/wallets/wallet-seed-phrase.mdx +++ b/docs/wallets/wallet-seed-phrase.mdx @@ -1,89 +1,71 @@ --- id: wallet-seed-phrase title: Wallet Seed Phrase -pagination_label: Seed Phrase +pagination_label: Wallet Seed Phrase sidebar_label: Wallet Seed Phrase description: Helium Documentation image: https://docs.helium.com/img/link-image.png slug: /wallets/wallet-seed-phrase --- -# Helium Wallet Seed Phrase - -When creating a Helium Wallet, users are prompted to write down the 24-word seed phrase. These are -the mnemonic phrases generated from the private key of the Wallet and the only way to access the -Wallet. - -:::info Hotspot App Users must migrate to the Helium Wallet app. - -Long term Helium Hotspot app users may have a 12-word seed phrase, which can be used in place of a -24-word seed phrase. All new Helium Wallets are generated from a 24-word seed phrase. - -The Helium Hotspot app is now no longer used for creating or managing Wallets. - -You can still see the previously created 12-word phrase in the Helium Hotspot app. Select > Settings -Icon > Reveal Words. +import useBaseUrl from '@docusaurus/useBaseUrl' -The 12-word seed phrase can be imported in the [Helium Wallet App](/wallets/helium-wallet-app). - -::: +# Helium Wallet Seed Phrase ---- +When creating a Helium account, users are prompted to write down the 24-word seed phrase. This +mnemonic phrase is generated from a +[list](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt) of 2048 specifically +selected words and can be used to recover the private key of the account. The seed phrase should +never be shared. ## Seed Phrase Security -:::warning Lose the seed phrase, lose it all. +:::caution Lose the seed phrase, lose it all. -The seed phrase words can never be recovered if they are lost, and they are the sole key to -accessing a Wallet, the tokens and NFTs it contains, and all access to associated Hotspots and their -rewards. +The seed phrase words can never be recovered if they are lost. They are the sole key to accessing an +account, the tokens and NFTs it contains, and all access to associated Hotspots and their rewards. ::: -Back up a seed phrase by writing down the words on paper with a pen and appropriately secure them. - -No one can recover a lost, forgotten, or misplaced seed phrase. - -Existing Helium Wallet and Helium Hotspot app users can view the seed phrase for a Wallet in the app -settings menu under `Reveal Words`. - -:::caution Before Deleting Helium Wallet Apps +:::note Remember these important things. -Do not uninstall or log out of the Helium Wallet app without first writing down the seed phrase. +1. Write down and keep seed phrases safe, do it now. +1. Never give seed phrase words to anyone who cannot be trusted with full control of your Hotspots + and token balances. +1. Do not enter seed phrase words in any app or website you don't fully trust. ::: -The only places you were ever required to enter your seed phrase are: - -1. The [Helium Wallet App](/wallets/helium-wallet-app) - on your phone -2. The [CLI Wallet](/wallets/cli-wallet) - on your computer - this is being discontinued -3. The [Ledger Wallet](/wallets/ledger) - on your computer or phone **NEVER enter them into a - website.** - -When entering the seed phrase make sure you: +Back up a seed phrase by writing down the words in their exact order and appropriately securing +them. As an even more robust solution, some experienced crypto users engrave their seed phrases on +[titanium plates](https://www.amazon.com/s?k=titanium+seed+phrase+plate). -1. Enter them in the right order -2. Get the spelling correct. Check words here for correct spelling: - [https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt) +Storing seed phrases on cloud storage providers like Google Drive or Dropbox is **not** recommended. +When these services are compromised, seed phrases are among the first things that hackers look for. -No Helium Support or Admin person will EVER ask for your seed phrase words or ask you to enter them -into a website to fix a problem. +No one can recover a lost, forgotten, or misplaced seed phrase. Offers to do so should be ignored. -:::note Remember these important things. +When entering the seed phrase make sure you: -1. Write down and keep seed phrases safe, do it now. -2. Never give seed phrase words to anyone who can not be trusted with the HNT value and Hotspot - value. -3. Do not enter seed phrase words in any app or website not on the list above. -4. Do not enter seed phrase words in any Maker App. -5. Do not store images of your words on cloud-based doc/file stores. +1. Enter them in the right order. +1. Get the spelling correct. Check the words from this list for correct spelling: + https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt +1. Watch out for similar-sounding word errors, like 'car' vs 'can' or 'blub' vs 'bulk'. See + [Commonly Misspelled Recovery Seed Words](https://trezor.io/support/a/commonly-misspelled-recovery-seed-words), + which lists common mistakes. -::: +## 12 vs 24-Word Seed Phrases ---- +While seed phrases can come in a few different lengths, 12 and 24-word will be most familiar for +Helium users. Most early accounts leverage a 12-word seed phrase. Accounts created with the +[Helium Wallet App](/wallets/helium-wallet-app) are generated with 24-word seed phrases. The Helium +Wallet app supports both formats. -## Solana Seed Phrases +With 128 bits of entropy, a 12-word seed phrase has 3.4 × 1038 possible combinations. A +24-word seed phrase has 256 bits of entropy, resulting in approximately 1.16 × 1077 +possible combinations. Both are **highly** secure, but 24-word phrases offer the best protection. -Seed phrases generated to create Wallets on the Helium blockchain can not be used on the Solana -blockchain. To migrate a Helium Wallet to a Solana Wallet you must export and import the private key -from a Helium Wallet to a Solana Wallet. +| Phrase Length | Possible Combinations | +| :------------ | :------------------------------------------------------------------------------------------------------ | +| 12 Words | 340,282,366,920,938,463,463,374,607,431,768,211,456 | +| 24 Words | 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 | diff --git a/docs/wallets/wallets.mdx b/docs/wallets/wallets.mdx index 79cef057f..0fe392456 100644 --- a/docs/wallets/wallets.mdx +++ b/docs/wallets/wallets.mdx @@ -12,56 +12,61 @@ import useBaseUrl from '@docusaurus/useBaseUrl' -## Wallet Migration Guide +As a blockchain-powered network, Helium uses on-chain +[accounts](https://docs.solana.com/developing/programming-model/accounts) to protect Hotspots and +Tokens. An account is an abstraction for a cryptographic key which consists of two parts — a public +key and a private key. This approach of having two keys is known as +[public key cryptography](https://www.blockchain-council.org/blockchain/how-does-blockchain-use-public-key-cryptography) +which is a widely used cryptographic system in blockchains. Users new to web3 are likely accustomed +to usernames and passwords as authentication methods. Web3 projects such as Helium replace +traditional logins with private and public keys. -All Helium Wallets will need to be migrated to the Solana blockchain. Please refer to the -[Wallet migration guide](/solana/migration/wallet-user) about the different Wallets and what can be -expected as part of the blockchain migration. +## Diving into Crypto Wallets ---- +A crypto wallet operates as a custodian for the public and private cryptographic keys. Wallets +enable users to transmit, obtain, and oversee cryptocurrency ownership. These wallets can be as +varied as directories on a computer, physical paper codes, or exclusive hardware devices. A host of +apps and software solutions also present a streamlined process for wallet creation and maintenance. -## 12-Word And 24-Word Seed Phrases +Helium maintains the [Helium Wallet App](/wallets/helium-wallet-app), which is specifically catered +to the needs of the Helium Network. However, as a Solana-native token, Helium is accessible through +any Solana-enabled wallet. -When a Helium Wallet is created with the Helium Wallet app a 24-word "Seed Phrase" is generated. +## Understanding Public and Private Keys -Users who created their Helium Wallet using the Helium Hotspot app will have a 12-word seed phrase, -while the Helium Wallet app accepts 12-word seed phrases, all new Helium Wallets are created with -24-word seed phrases. +As the names imply, there is a distinction between the different keys that are generated when +creating a new Helium account, or any other web3 account for that matter. The distinction between +these keys is important to understand. -Read more about Helium Wallet [seed phrases here](/wallets/wallet-seed-phrase). +### Public Key -:::note +The public key is your 'calling card' on the blockchain. Anyone with it can view token balances, +Hotspots, and any associated history of these entities. The public key is the address that can be +shared. -Transferring Hotspot ownership between 12-word and 24-word Wallets can only be done using the -[Wallet CLI](/wallets/cli-wallet) +For purposes of security, the public key cannot be used to determine the private key. -::: +For Helium and other projects on Solana, public keys are strings of letters and numbers that look +like `dcuc8Amr83Wz27ZkQ2K9NS6r8zRpf1J6cvArEBDZDmm`. ---- +### Private Key + +The private key of your account is never to be shared and should be kept safe from potential +thieves. If a private key is lost, there is no means of recovering it. If the _public_ key is lost +or forgotten, the private key can be used to determine it using the derivation path leveraged by +Helium Wallet App accounts. + +Private keys can take several forms, though most will know them as +[12-word or 24-word seed phrases](/wallets/wallet-seed-phrase). Certain tools can also manage +private key phrases stored in a file; something like `keyfile.bin` or as a long string of letters +and numbers. + +Private keys allow for full access to an account's contents and should be protected. These keys are +never needed to diagnose a Hotspot or verify on-chain transactions. + +:::warning Important summary: Never give away your seed phrases or private keys -## iOS and Android Wallet Applications - -:::note Download the Helium Wallet Application - -
-
-
- - - -
-
- - - -
-
-
+Avoid entering or sending private keys to any untrusted websites or applications. +Helium does not require these details for any reason, including support, airdrop, or redemption. ::: diff --git a/docusaurus.config.js b/docusaurus.config.js index 8781a4997..bceced5af 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -1,9 +1,11 @@ -const math = require('remark-math') -const katex = require('rehype-katex') -const webpack = require('webpack') +import { themes } from 'prism-react-renderer' +import katex from 'rehype-katex' +import math from 'remark-math' +import webpack from 'webpack' +require('dotenv').config() -const lightCodeTheme = require('prism-react-renderer/themes/github') -const darkCodeTheme = require('prism-react-renderer/themes/dracula') +const darkCodeTheme = themes.dracula +const lightCodeTheme = themes.github module.exports = { title: 'Helium Documentation', @@ -33,72 +35,30 @@ module.exports = { // Hides the switch in the navbar // Useful if you want to support a single color mode - disableSwitch: true, + disableSwitch: false, // Should we use the prefers-color-scheme media-query, // using user system preferences, instead of the hardcoded defaultMode - respectPrefersColorScheme: false, + respectPrefersColorScheme: true, }, navbar: { title: '', style: 'primary', logo: { alt: 'Helium Logo', - src: 'img/icons/logoblack.svg', - srcDark: 'img/icons/logowhite.svg', + src: 'img/icons/logo_docs_black.svg', + srcDark: 'img/icons/logo_docs_white.svg', }, - items: [ - { - to: 'solana', - label: 'Architecture', - position: 'left', - }, - { - to: 'hnt-token', - label: 'Tokens', - position: 'left', - }, - { - to: 'wallets', - label: 'Wallets', - position: 'left', - }, - { - to: 'use-the-network', - label: 'IoT Network', - position: 'left', - }, - { - to: '5g-on-helium', - label: 'Mobile Network', - position: 'left', - }, - { - to: 'governance', - label: 'Governance', - position: 'left', - }, - { - to: 'devblog', - label: 'Dev Blog', - position: 'left', - }, - { - to: '/solana/migration/', - label: 'Solana Migration Guides', - position: 'right', - className: 'announcementnav', - }, - ], + items: [], }, footer: { style: 'dark', - copyright: `Copyright © ${new Date().getFullYear()} Helium Foundation`, + copyright: `Copyright © ${new Date().getFullYear()} Helium`, }, prism: { theme: lightCodeTheme, darkTheme: darkCodeTheme, - additionalLanguages: ['protobuf', 'rust', 'toml'], + additionalLanguages: ['protobuf', 'rust', 'toml', 'bash'], }, }, presets: [ @@ -137,7 +97,10 @@ module.exports = { customFields: { MIGRATION_SERVICE_URL: 'https://migration.web.helium.io', SOLANA_URL: 'https://solana-rpc.web.helium.io/?session-key=Pluto', - HNT_TO_RENT_SERVICE_URL: 'https://hnt-to-rent.web.helium.io', + TOKENS_TO_RENT_SERVICE_URL: 'https://tokens-to-rent.web.helium.io', + EDU_EMAIL: process.env.EDU_EMAIL, + EDU_PW: process.env.EDU_PW, + EDU_API_URL: process.env.EDU_API_URL, }, plugins: [ function (context, options) { @@ -156,6 +119,9 @@ module.exports = { assert: false, crypto: false, stream: false, + http: false, + https: false, + url: false, }, }, } @@ -184,9 +150,21 @@ module.exports = { authorsMapPath: 'authors.yaml', }, ], + [ + 'docusaurus-plugin-llms', + { + generateLLMsFullTxt: false, + generateMarkdownFiles: true, + excludeImports: true, + title: 'Helium Documentation', + description: + 'Documentation for the Helium Network — covering IoT (LoRaWAN), Mobile (5G/WiFi), tokens (HNT, DC, SOL), wallets, and network data.', + includeBlog: false, + }, + ], ], markdown: { mermaid: true, }, - themes: ['@docusaurus/theme-mermaid'], + themes: ['@docusaurus/theme-mermaid', 'docslab-docusaurus'], } diff --git a/link-preview.png b/link-preview.png deleted file mode 100644 index a01a0027d..000000000 Binary files a/link-preview.png and /dev/null differ diff --git a/netlify.toml b/netlify.toml index d6c35f044..43bc23396 100644 --- a/netlify.toml +++ b/netlify.toml @@ -9,455 +9,240 @@ status = 301 force = true [[redirects]] - from = "/use-the-network/light-hotspots/guides/*" - to = "/mine-hnt/data-only-guides/:splat" + from = "/helium-tokens/*" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] - from = "/5g-on-helium/5g-poc" - to = "/5g-on-helium/mobile-poc" + from = "/tokens" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] - from = "/5g-on-helium/mining-5g" - to = "/5g-on-helium/mobile-poc" + from = "/wallets/ledger" + to = "/wallets/ledger-wallet" status = 301 force = true [[redirects]] - from = "/wallets/app-wallet" - to = "/mine-hnt/helium-hotspot-app" + from = "/wallets/app-wallet/transaction-failures/" + to = "/wallets/helium-wallet-app" status = 301 force = true [[redirects]] - from = "/hotspot-makers/maker-apps" - to = "/hotspot-makers/hotspot-makers" + from = "/hotspot-makers/iot/data-only-hotspots" + to = "/iot/data-only-hotspots" status = 301 force = true [[redirects]] - from = "/use-the-network/policies" - to = "/faq/terms" + from = "/mine-hnt/data-only-hotspots" + to = "/iot/data-only-hotspots" status = 301 force = true [[redirects]] - from = "/use-the-network/policies/terms" - to = "/faq/terms" + from = "/data-credit" + to = "/tokens/data-credit" status = 301 force = true [[redirects]] - from = "/use-the-network/policies/privacy" - to = "/faq/privacy" + from = "/data-credit-portal" + to = "/tokens/data-credit-portal" status = 301 force = true [[redirects]] - from = "/solana/oracle-data" - to = "/oracles/oracle-data" - status = 301 - force = true -[[redirects]] - from = "/solana/migration/hotspot-owner" - to = "/solana/migration/hotspot-operator" + from = "/helium-tokens/hnt" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] - from = "/use-the-network/devices/ready-to-use/comtac/lpn-km" - to = "/use-the-network/devices/ready-to-use/comtac/cluey-km" + from = "/hnt-token" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] from = "/blockchain/helium-token" - to = "/hnt-token" - status = 301 - force = true -[[redirects]] - from = "/use-the-network/open-lns" - to = "/lorawan-on-helium/open-lns" - status = 301 - force = true -[[redirects]] - from = "/hotspot-makers/original-helium-hotspot" - to = "/mine-hnt/helium-hotspot-app" - status = 301 - force = true -[[redirects]] - from = "/wallets/twelve-words" - to = "/wallets/wallet-seed-phrase" - status = 301 - force = true -[[redirects]] - from = "/wallets/twenty-four-words" - to = "/wallets/wallet-seed-phrase" - status = 301 - force = true -[[redirects]] - from = "/blockchain/oracles" - to = "/oracles/price-oracles" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/validators/validators-and-voting-power" - to = "/governance/faq" - status = 301 - force = true -[[redirects]] - from = "/validators/*" - to = "/solana/migration/validator-operator" - status = 301 - force = true -[[redirects]] - from = "/iot" - to = "/lorawan-on-helium" - status = 301 - force = true -[[redirects]] - from = "/mobile" - to = "/5g-on-helium" - status = 301 - force = true -[[redirects]] - from = "/hotspot-makers/maker-apps" - to = "/hotspot-makers" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/basic-miner-operation" - to = "/hotspot-makers/become-a-maker/basic-miner-operation" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - to = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - to = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - to = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - to = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - to = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - to = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - to = "/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/data-only-guides/balena-data-only-hotspot" - to = "/hotspot-makers/iot/data-only/balena-data-only-hotspot" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/data-only-guides/dragino-pg1301" - to = "/hotspot-makers/iot/data-only/dragino-pg1301" - status = 301 - force = true -[[redirects]] - from = "/hotspot-makers/iot/data-only/dragino" - to = "/mine-hnt/data-only-hotspots" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/data-only-guides/dragino" - to = "/hotspot-makers/iot/data-only/dragino" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/data-only-guides/kerlink" - to = "/hotspot-makers/iot/data-only/kerlink" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/data-only-guides/rak-concentrators" - to = "/hotspot-makers/iot/data-only/rak-concentrators" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/full-hotspots" - to = "/hotspot-makers/iot/full-hotspots" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] - from = "/hotspot-makers/maker-apps" - to = "/hotspot-makers" + from = "/blockchain/hnt-token" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] - from = "/hotspot-makers/hotspot-manufacturers" - to = "/hotspot-makers" + from = "/iot/run-a-lns" + to = "/iot/run-an-lns" status = 301 force = true [[redirects]] - from = "/hotspot-makers/5g-hardware-specification" - to = "/hotspot-makers/mobile-cbrs/5g-hardware-specification" + from = "/iot/buy-an-oui" + to = "/iot/run-an-lns/buy-an-oui" status = 301 force = true [[redirects]] - from = "/hotspot-makers/5g-hotspot-requirements" - to = "/hotspot-makers/mobile-cbrs/5g-hotspot-requirements" + from = "/iot/open-lns" + to = "/iot/lorawan-network-servers" status = 301 force = true [[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/maker-approval-auditing" - to = "/hotspot-makers/hotspot-audit-process" + from = "/console/hosting-providers" + to = "/iot/find-a-lns-provider" status = 301 force = true [[redirects]] - from = "/use-the-network/coverage-mapping/adeunis-mapper" - to = "/iot/coverage-mapping/adeunis-mapper" + from = "/find-a-lns-provider" + to = "/iot/find-a-lns-provider" status = 301 force = true [[redirects]] - from = "/use-the-network/coverage-mapping" - to = "/iot/coverage-mapping" + from = "/solana/migration/wallet-user" + to = "/wallets/l1-migrate" status = 301 force = true [[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/docker-integration" - to = "/hotspot-makers//docker-integration" + from = "/mobile/data-only-mobile" + to = "/mobile/helium-plus-mobile" status = 301 force = true [[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/hotspot-ble-services" - to = "/hotspot-makers//hotspot-ble-services" + from = "/mobile/data-only-aruba" + to = "/mobile/helium-plus-aruba" status = 301 force = true [[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/hotspot-integration-testing" - to = "/hotspot-makers//hotspot-integration-testing" + from = "/mobile/data-only-fortinet" + to = "/mobile/helium-plus-fortinet" status = 301 force = true [[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/hotspot-wifi-configuration" - to = "/hotspot-makers//hotspot-wifi-configuration" + from = "/mobile/data-only-juniper-mist" + to = "/mobile/helium-plus-juniper-mist" status = 301 force = true [[redirects]] - from = "/mine-hnt/full-hotspots/become-a-maker/security-requirements" - to = "/hotspot-makers//security-requirements" + from = "/mobile/data-only-meraki" + to = "/mobile/helium-plus-meraki" status = 301 force = true [[redirects]] - from = "/use-the-network/coverage-mapping/mappers-api" - to = "/iot/coverage-mapping/api" + from = "/mobile/data-only-mikrotik" + to = "/mobile/helium-plus-mikrotik" status = 301 force = true [[redirects]] - from = "/use-the-network/coverage-mapping/mappers-quickstart" - to = "/iot/coverage-mapping/quickstart" + from = "/mobile/data-only-ruckus" + to = "/mobile/helium-plus-ruckus" status = 301 force = true [[redirects]] - from = "/use-the-network/coverage-mapping/mappers-roadmap" - to = "/iot/coverage-mapping/roadmap" + from = "/mobile/data-only-ubiquiti" + to = "/mobile/helium-plus-ubiquiti" status = 301 force = true [[redirects]] - from = "/mine-hnt/crowdspot" - to = "/iot/crowdspot" + from = "/mobile/data-only-generic" + to = "/mobile/helium-plus-generic" status = 301 force = true [[redirects]] - from = "/mine-hnt/denylist-removals" - to = "/iot/denylist-removals" + from = "/mobile/data-only-onboarding" + to = "/mobile/helium-plus-onboarding" status = 301 force = true [[redirects]] - from = "/mine-hnt/denylist" - to = "/iot/denylist" + from = "/mobile/data-only-radsecproxy" + to = "/mobile/helium-plus-radsecproxy" status = 301 force = true [[redirects]] - from = "/lorawan-on-helium/frequency-plans" - to = "/iot/frequency-plans" + from = "/mobile/data-only-cambium-cnmaestro" + to = "/mobile/helium-plus-cambium-cnmaestro" status = 301 force = true [[redirects]] - from = "/lorawan-on-helium/region-plans" - to = "/iot/region-plans" + from = "/mobile/data-only-Cisco-WLC-9800" + to = "/mobile/helium-plus-Cisco-WLC-9800" status = 301 force = true [[redirects]] - from = "/lorawan-on-helium/lorawan-roaming-getting-started" - to = "/iot/lorawan-roaming-quickstart" + from = "/mobile/data-only-Cisco-WLC-5520" + to = "/mobile/helium-plus-Cisco-WLC-5520" status = 301 force = true [[redirects]] - from = "/lorawan-on-helium/lorawan-roaming-on-helium" - to = "/iot/lorawan-roaming" + from = "/iot/coverage-mapping" + to = "/network-iot" status = 301 force = true [[redirects]] - from = "/lorawan-on-helium/open-lns-configuration" - to = "/iot/open-lns-quickstart" + from = "/api/blockchain/introduction/" + to = "/network-data/legacy-blockchain-data" status = 301 force = true [[redirects]] - from = "/lorawan-on-helium/open-lns" - to = "/iot/open-lns" + from = "/hotspot-makers/" + to = "/network-iot/hotspots-iot/data-only-hotspots" status = 301 force = true [[redirects]] - from = "/lorawan-on-helium/iot-proof-of-coverage" - to = "/iot/proof-of-coverage" + from = "/troubleshooting/network-troubleshooting/" + to = "https://hardware.hellohelium.com/" status = 301 force = true [[redirects]] - from = "/5g-on-helium/cbrs-radios" - to = "/mobile/cbrs-radios" + from = "/troubleshooting/replace-sd-card/" + to = "https://hardware.hellohelium.com/" status = 301 force = true [[redirects]] - from = "/5g-on-helium/mobile-mappers" - to = "/mobile/mappers" + from = "/iot/denylist" + to = "/network-iot" status = 301 force = true [[redirects]] - from = "/5g-on-helium/mobile-poc" - to = "/mobile/proof-of-coverage" + from = "/console/integrations/json-schema" + to = "/network-iot/lorawan-network-servers" status = 301 force = true [[redirects]] - from = "/5g-on-helium/service-providers" - to = "/mobile/service-providers" - status = 301 - force = true -[[redirects]] - from = "/troubleshooting/hotspot-led" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/wallets/app-wallet/hotspot-setup-troubleshooting" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/troubleshooting/network-troubleshooting" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/understanding-hotspot-status" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/troubleshooting/replace-sd-card" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/troubleshooting/understanding-witnesses" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/wallets/app-wallet/discovery-mode" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/wallets/app-wallet/fleet-mode" - to = "/" - status = 301 - force = true -[[redirects]] - from = "/wallets/app-wallet/rak-hotspot-setup" - to = "/" -[[redirects]] - from = "/use-the-network/console/data-credits" - to = "/data-credit" - status = 301 - force = true -[[redirects]] - from = "/mine-hnt/maker-apps" - to = "/hotspot-makers" - status = 301 - force = true -[[redirects]] - from = "/hotspot-makers/maker-apps" - to = "/hotspot-makers" - status = 301 - force = true -[[redirects]] - from = "/community-governance/governance" - to = "/governance" - status = 301 - force = true -[[redirects]] - from = "/community-governance/community-voting" - to = "/governance/voting" - status = 301 - force = true -[[redirects]] - from = "/helium-tokens/data-credit" - to = "/data-credit" - status = 301 - force = true -[[redirects]] - from = "/helium-tokens/hnt" - to = "/hnt-token" + from = "/tokens/mobile-token/" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] - from = "/helium-tokens/iot" - to = "/iot-token" + from = "/wallets/app-wallet/transfer-hotspot/" + to = "/wallets/helium-wallet-app" status = 301 force = true [[redirects]] - from = "/helium-tokens/mobile" - to = "/mobile-token" + from = "/devblog/*" + to = "/home" status = 301 force = true [[redirects]] - from = "/helium-tokens/sol-token" - to = "/sol-token" + from = "/iot/lorawan-region-plans" + to = "/network-iot" status = 301 force = true [[redirects]] - from = "/mine-hnt" - to = "/mine-iot" + from = "/blockchain/mining/" + to = "/tokens/hnt-token" status = 301 force = true [[redirects]] - from = "/vote-escrow/voting-power" - to = "/governance/faq" + from = "/iot/lorawan-frequency-plans" + to = "/network-iot" status = 301 force = true [[redirects]] - from = "/use-the-network/devices/ready-to-use/iotsens/sound-device" - to = "/use-the-network/devices/ready-to-use/iotsens/sound-monitor" + from = "/console" + to = "/network-iot/lorawan-network-servers" status = 301 force = true [[redirects]] - from = "use-the-network/devices/development/quickstart-guides" - to = "use-the-network/devices/development/development" + from = "/faq/helium-network/" + to = "/home" status = 301 force = true [build.environment] - YARN_VERSION = "1.22.19" - NODE_VERSION = "16.15.1" - - - - - - - + YARN_VERSION = "1.22.21" + NODE_VERSION = "20.19.5" \ No newline at end of file diff --git a/package.json b/package.json index be221562f..2f9b3c7a9 100644 --- a/package.json +++ b/package.json @@ -11,39 +11,46 @@ "serve": "docusaurus serve" }, "dependencies": { + "@chirpstack/chirpstack-api-grpc-web": "^4.16.2", "@clockwork-xyz/sdk": "^0.3.0", "@coral-xyz/anchor": "^0.27.0", - "@docusaurus/core": "2.4.0", - "@docusaurus/preset-classic": "2.4.0", - "@docusaurus/theme-mermaid": "2.4.0", - "@helium/account-fetch-cache": "^0.2.5", - "@helium/account-fetch-cache-hooks": "^0.2.5", + "@docusaurus/core": "^3.9.2", + "@docusaurus/plugin-google-gtag": "^3.9.2", + "@docusaurus/preset-classic": "^3.9.2", + "@docusaurus/theme-mermaid": "^3.9.2", + "@helium/account-fetch-cache": "^0.6.31", + "@helium/account-fetch-cache-hooks": "^0.6.31", "@helium/address": "^4.8.1", - "@helium/fanout-sdk": "^0.2.5", - "@helium/helium-react-hooks": "^0.2.5", - "@helium/idls": "^0.2.5", - "@helium/spl-utils": "^0.2.5", - "@mdx-js/react": "^1.5.8", + "@helium/data-credits-sdk": "^0.6.31", + "@helium/fanout-sdk": "^0.6.31", + "@helium/helium-react-hooks": "^0.6.31", + "@helium/idls": "^0.6.31", + "@helium/spl-utils": "^0.6.31", + "@mdx-js/react": "^3.0.0", "@metaplex-foundation/mpl-token-metadata": "^2.8.4", + "@pythnetwork/price-service-client": "^1.9.0", "@solana/spl-account-compression": "^0.1.7", "@solana/spl-token": "^0.3.7", - "@solana/wallet-adapter-ledger": "^0.9.24", - "@solana/wallet-adapter-phantom": "^0.9.23", - "@solana/wallet-adapter-react": "^0.15.32", - "@solana/wallet-adapter-react-ui": "^0.9.31", - "@solana/wallet-adapter-solflare": "^0.6.24", - "@solana/web3.js": "^1.66.1", - "axios": "^1.3.4", - "clsx": "^1.1.1", - "hast-util-is-element": "1.1.0", + "@solana/wallet-adapter-ledger": "^0.9.29", + "@solana/wallet-adapter-phantom": "^0.9.28", + "@solana/wallet-adapter-react": "^0.15.39", + "@solana/wallet-adapter-react-ui": "^0.9.39", + "@solana/wallet-adapter-solflare": "^0.6.32", + "@solana/web3.js": "^1.98.4", + "axios": "^1.13.5", + "docslab-docusaurus": "^0.2.10", + "docusaurus-plugin-llms": "^0.3.0", + "mdx-embed": "^1.1.2", + "prism-react-renderer": "^2.3.1", "process": "^0.11.10", - "react": "^16.8.4", + "react": "^19.2.4", "react-async-hook": "^4.0.0", - "react-dom": "^16.8.4", - "react-icons": "^4.8.0", - "rehype-katex": "5", - "remark-math": "3", - "yarn": "^1.22.10" + "react-dom": "^19.2.4", + "react-icons": "^5.4.0", + "react-table": "^7.8.0", + "rehype-katex": "^7.0.1", + "remark-math": "6.0.0", + "yarn": "^1.22.21" }, "browserslist": { "production": [ @@ -56,5 +63,11 @@ "last 1 firefox version", "last 1 safari version" ] + }, + "engines": { + "node": ">=20.0" + }, + "devDependencies": { + "dotenv": "^17.2.4" } } diff --git a/sidebarsDocs.js b/sidebarsDocs.js index 86b8a318f..6abed44ae 100644 --- a/sidebarsDocs.js +++ b/sidebarsDocs.js @@ -1,952 +1,145 @@ module.exports = { home: [ + 'home/home', { type: 'category', - label: 'Home', - link: { type: 'doc', id: 'home/home' }, - items: ['home/about-helium', 'home/helium-history'], - }, - { - type: 'category', - label: 'FAQ', - link: { type: 'doc', id: 'faq/helium-network' }, - items: [ - 'faq/security', - 'faq/open-source', - 'faq/docs-installation', - 'faq/privacy', - 'faq/terms', - ], - collapsed: true, - }, - ], - - architecture: [ - { - type: 'category', - label: 'Solana', - link: { type: 'doc', id: 'solana/solana' }, - items: ['solana/primer', 'solana/rewardable-entities', 'solana/compression-nfts'], - collapsed: true, - }, - { - type: 'category', - label: 'Oracles', - link: { type: 'doc', id: 'oracles/oracles' }, - items: [ - 'oracles/data-transfer-oracles', - 'oracles/iot-proof-of-coverage-oracles', - 'oracles/mobile-proof-of-coverage-oracles', - 'oracles/oracle-data', - 'oracles/price-oracles', - 'oracles/rewards-oracles', - ], - collapsed: true, - }, - - { - type: 'category', - label: 'Hotspots', - link: { type: 'doc', id: 'hotspot-makers/become-a-maker/basic-miner-operation' }, + label: 'Mobile Network', + link: { type: 'doc', id: 'network-mobile/5g-on-helium' }, items: [ { type: 'category', - label: 'IOT Hotspots', - link: { type: 'doc', id: 'hotspot-makers/iot/light-hotspots' }, + label: 'Convert WiFi Networks', + collapsed: false, + link: { type: 'doc', id: 'network-mobile/helium-plus-mobile' }, items: [ - 'hotspot-makers/become-a-maker/docker-integration', - 'hotspot-makers/become-a-maker/hotspot-ble-services', - 'hotspot-makers/become-a-maker/hotspot-wifi-configuration', - 'hotspot-makers/become-a-maker/maker-app-requirements', - 'hotspot-makers/become-a-maker/security-requirements', - ], - }, - { - type: 'category', - label: 'Data Only Hotspots', - link: { type: 'doc', id: 'hotspot-makers/iot/data-only-hotspots' }, - items: [ - 'hotspot-makers/iot/data-only/balena-data-only-hotspot', - 'hotspot-makers/iot/data-only/dragino-pg1301', - 'hotspot-makers/iot/data-only/dragino', - 'hotspot-makers/iot/data-only/kerlink', - 'hotspot-makers/iot/data-only/rak-concentrators', - ], - }, - 'hotspot-makers/mobile-cbrs/5g-hardware-specification', - { - type: 'category', - label: 'Hotspot Makers', - link: { type: 'doc', id: 'hotspot-makers/hotspot-makers' }, - items: [ - 'hotspot-makers/mcc/compliance-committee', - 'hotspot-makers/mcc/maker-ethics', - 'hotspot-makers/become-a-maker/burn-hnt-to-maker-wallet', - 'hotspot-makers/become-a-maker/funding-a-maker-account', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Audit Process', - link: { type: 'doc', id: 'hotspot-makers/mcc/hotspot-audit-process' }, - items: [ - 'hotspot-makers/become-a-maker/maker-approval-auditing', - 'hotspot-makers/mcc/fcc-compliance', - 'hotspot-makers/mcc/ce-red-compliance', - 'hotspot-makers/become-a-maker/hotspot-integration-testing', + { + type: 'doc', + id: 'network-mobile/helium-plus-mobile', + label: 'Introduction', + }, + 'network-mobile/helium-plus-guides/helium-plus-onboarding', + 'network-mobile/helium-plus-guides/helium-plus-radsecproxy', + 'network-mobile/helium-plus-guides/helium-plus-aruba', + 'network-mobile/helium-plus-guides/helium-plus-aruba-central', + 'network-mobile/helium-plus-guides/helium-plus-cambium-cnmaestro', + 'network-mobile/helium-plus-guides/helium-plus-fortinet', + 'network-mobile/helium-plus-guides/helium-plus-juniper-mist', + 'network-mobile/helium-plus-guides/helium-plus-meraki', + 'network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-9800', + 'network-mobile/helium-plus-guides/helium-plus-Cisco-WLC-5520', + 'network-mobile/helium-plus-guides/helium-plus-mikrotik', + 'network-mobile/helium-plus-guides/helium-plus-ruckus', + 'network-mobile/helium-plus-guides/helium-plus-ubiquiti', + 'network-mobile/helium-plus-guides/helium-plus-generic', + 'network-mobile/helium-plus-security-faq', ], }, ], - collapsed: true, }, - ], - - tokens: [ - 'helium-tokens/hnt-token', - 'helium-tokens/iot-token', - 'helium-tokens/mobile-token', { type: 'category', - label: 'Data Credit Tokens', - link: { type: 'doc', id: 'helium-tokens/data-credit' }, - items: ['helium-tokens/data-credit', 'helium-tokens/data-credit-portal'], - collapsed: true, - }, - 'helium-tokens/sol-token', - ], - - wallets: [ - 'wallets/wallets', - 'wallets/helium-wallet-app', - 'wallets/wallet-seed-phrase', - 'wallets/ledger', - 'wallets/cli-wallet', - ], - - iot_network: [ - { - type: 'category', - label: 'Use the Helium IoT Network', - link: { type: 'doc', id: 'use-the-network/use-the-network' }, - items: [], - collapsed: true, - }, - { - type: 'category', - label: 'Devices', - link: { type: 'doc', id: 'use-the-network/devices/devices' }, - items: [ - 'use-the-network/devices/ready-to-use/ready-to-use', - 'use-the-network/devices/development/development', - ], - }, - { - type: 'category', - label: 'LoRaWAN Network Servers', - link: { type: 'doc', id: 'use-the-network/lorawan-network-servers' }, - items: [ - 'network-iot/open-lns', - 'use-the-network/find-a-lns-provider', - 'network-iot/open-lns-quickstart', - 'use-the-network/run-a-network-server/buy-an-oui', - ], - }, - { - type: 'category', - label: 'LoRaWAN on Helium', - link: { type: 'doc', id: 'network-iot/lorawan-on-helium' }, - items: [ - 'network-iot/frequency-plans/frequency-plans', - 'network-iot/frequency-plans/region-plans', - { - type: 'category', - label: 'Roaming', - link: { type: 'doc', id: 'network-iot/lorawan-roaming' }, - items: ['network-iot/lorawan-roaming-quickstart', 'use-the-network/roaming'], - }, - ], - }, - { - type: 'category', - label: 'Proof of Coverage', - link: { type: 'doc', id: 'blockchain/proof-of-coverage' }, + label: 'IoT Network', + link: { type: 'doc', id: 'network-iot/lorawan-network-servers/lorawan-network-servers' }, items: [ - 'network-iot/iot-poc', { type: 'category', - label: 'Coverage Mapping', - link: { type: 'doc', id: 'network-iot/coverage-mapping/coverage-mapping' }, - items: [ - 'network-iot/coverage-mapping/mappers-api', - 'network-iot/coverage-mapping/mappers-roadmap', - ], - }, - ], - }, - ], - - mobile_network: [ - { - type: 'category', - label: '5G on Helium', - link: { type: 'doc', id: 'network-mobile/cbrs/5g-on-helium' }, - items: [ - 'network-mobile/cbrs/cbrs-radios', - 'network-mobile/mobile-mappers', - 'network-mobile/mobile-poc', - 'network-mobile/service-providers', - ], - collapsed: true, - }, - ], - - governance: [ - 'governance/governance', - 'governance/voting', - 'governance/faq', - 'governance/realms', - 'vote-escrow/vehnt', - 'vote-escrow/realms', - 'governance/working-groups', - 'governance/committees', - { - type: 'category', - label: 'Improvement Proposals', - link: { type: 'doc', id: 'governance/hip' }, - items: ['faq/write-a-hip', 'faq/edit-a-hip'], - }, - ], - - archive: [ - { - type: 'category', - label: 'Blockchain', - link: { type: 'doc', id: 'blockchain/blockchain' }, - items: [ - 'blockchain/blockchain-primitives', - 'blockchain/mining', - 'blockchain/transaction-fees', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Mine IOT', - link: { type: 'doc', id: 'helium-tokens/mine-iot' }, - items: [ - 'network-iot/crowdspot', - 'network-iot/denylist', - 'network-iot/denylist-removals', - 'faq/build-on-network', - ], - collapsed: true, - }, - { - type: 'category', - label: 'API', - link: { type: 'doc', id: 'api/home' }, - items: [ - { - type: 'category', - label: 'Blockchain API', - link: { type: 'doc', id: 'api/blockchain/introduction' }, - items: [ - 'api/blockchain/stats', - 'api/blockchain/blocks', - 'api/blockchain/accounts', - 'api/blockchain/hotspots', - 'api/blockchain/cities', - 'api/blockchain/locations', - 'api/blockchain/transactions', - 'api/blockchain/pending-transactions', - 'api/blockchain/oracle-prices', - 'api/blockchain/chain-variables', - 'api/blockchain/ouis', - 'api/blockchain/rewards', - 'api/blockchain/dc-burns', - 'api/blockchain/challenges', - 'api/blockchain/elections', - 'api/blockchain/state-channels', - 'api/blockchain/assert-locations', - 'api/blockchain/validators', - ], - collapsed: true, - }, - 'api/console', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Console', - link: { type: 'doc', id: 'use-the-network/console/quickstart' }, - items: [ - 'use-the-network/console/users', - 'use-the-network/console/adding-devices', - { - type: 'category', - label: 'Migrating Devices', - link: { - type: 'doc', - id: 'use-the-network/console/migrating-devices/migrating-devices', - }, - items: [ - 'use-the-network/console/migrating-devices/ttn-import', - 'use-the-network/console/migrating-devices/ttn-manual', - ], + label: 'Learn LoRaWAN', collapsed: true, - }, - 'use-the-network/console/labels', - 'use-the-network/console/debug', - 'use-the-network/console/alerts', - 'use-the-network/console/multi-packets', - 'use-the-network/console/profiles', - { - type: 'category', - label: 'Flows', - link: { type: 'doc', id: 'use-the-network/console/flows/flows' }, items: [ - 'use-the-network/console/flows/orientation', - 'use-the-network/console/flows/actions', - 'use-the-network/console/flows/flows-faq', + 'network-iot/learn/understanding-lorawan', + 'network-iot/learn/build-a-device', ], - collapsed: true, }, - 'use-the-network/console/functions', + 'network-iot/lorawan-network-servers/find-a-lns-provider', { type: 'category', - label: 'Integrations', - link: { type: 'doc', id: 'use-the-network/console/integrations/integrations' }, + label: 'Run Your Own LNS', + link: { type: 'doc', id: 'network-iot/run-an-lns/run-an-lns' }, items: [ - 'use-the-network/console/integrations/json-schema', - 'use-the-network/console/integrations/http', - 'use-the-network/console/integrations/mqtt', - 'use-the-network/console/integrations/azure', - 'use-the-network/console/integrations/aws-iot-core', - 'use-the-network/console/integrations/cargo', - 'use-the-network/console/integrations/datacake', - 'use-the-network/console/integrations/mydevices-cayenne', - 'use-the-network/console/integrations/adafruitio', - 'use-the-network/console/integrations/ubidots', - 'use-the-network/console/integrations/tago', - 'use-the-network/console/integrations/google-sheets', - 'use-the-network/console/integrations/microshare', - 'use-the-network/console/integrations/akenza', + 'network-iot/run-an-lns/buy-an-oui', + { + type: 'category', + label: 'Fund an Organizationally Unique Identifier', + link: { type: 'doc', id: 'network-iot/run-an-lns/fund-an-oui' }, + items: ['tokens/data-credit-portal', 'network-iot/run-an-lns/fund-an-oui-using-hnt'], + }, + { + type: 'category', + label: 'Configure ChirpStack', + link: { type: 'doc', id: 'network-iot/run-an-lns/configure-chirpstack' }, + items: ['network-iot/run-an-lns/docker-compose', 'network-iot/run-an-lns/kubernetes'], + }, + 'network-iot/run-an-lns/configure-routing-rules', + 'network-iot/run-an-lns/chirpstack-add-device', + 'network-iot/run-an-lns/chirpstack-add-device-grpc', + 'network-iot/run-an-lns/advanced-configuration', + 'network-iot/run-an-lns/common-issues', ], - collapsed: true, }, - 'use-the-network/console/coverage', - 'use-the-network/console/console-cli', - 'use-the-network/console/console-api', - 'use-the-network/console/my-account', - 'use-the-network/console/troubleshooting', - 'use-the-network/console/hosting-providers', - 'use-the-network/run-a-network-server/run-a-network-server', - 'blockchain/packet-purchasing', - ], - collapsed: true, - }, - ], - - iot_device_ready_to_use: [ - { - type: 'link', - label: '<- Devices', - href: '/use-the-network/devices', - }, - 'use-the-network/devices/ready-to-use/ready-to-use', - { - type: 'category', - label: 'Abeeway', - items: [ - 'use-the-network/devices/ready-to-use/abeeway/abeeway-geolocation-module', - 'use-the-network/devices/ready-to-use/abeeway/abeeway-industrial-tracker', - 'use-the-network/devices/ready-to-use/abeeway/abeeway-compact-tracker', - 'use-the-network/devices/ready-to-use/abeeway/abeeway-micro-tracker', - 'use-the-network/devices/ready-to-use/abeeway/abeeway-smart-badge', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Adeunis', - items: ['use-the-network/devices/ready-to-use/adeunis/adeunis-field-test-device'], - collapsed: true, - }, - { - type: 'category', - label: 'Acqua-Scope', - items: [ - 'use-the-network/devices/ready-to-use/aquascope/bvs', - 'use-the-network/devices/ready-to-use/aquascope/wwd', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Beiselen', - items: ['use-the-network/devices/ready-to-use/beiselen/radar'], - collapsed: true, - }, - { - type: 'category', - label: 'BoatOfficer', - items: ['use-the-network/devices/ready-to-use/boatofficer/boatofficerblue'], - collapsed: true, - }, - { - type: 'category', - label: 'Bosch', - items: ['use-the-network/devices/ready-to-use/bosch/tps110'], - collapsed: true, - }, - { - type: 'category', - label: 'Comtac', - items: [ - 'use-the-network/devices/ready-to-use/comtac/lpn-td1', - 'use-the-network/devices/ready-to-use/comtac/cluey-km', - 'use-the-network/devices/ready-to-use/comtac/lpn-tsm', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Decent Lab', - items: [ - 'use-the-network/devices/ready-to-use/decentlab/dl-iam', - 'use-the-network/devices/ready-to-use/decentlab/dl-pr26', - 'use-the-network/devices/ready-to-use/decentlab/dl-mbx', - 'use-the-network/devices/ready-to-use/decentlab/dl-5tm', - 'use-the-network/devices/ready-to-use/decentlab/dl-atm22', - 'use-the-network/devices/ready-to-use/decentlab/dl-atm41', - 'use-the-network/devices/ready-to-use/decentlab/dl-ctd10', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-002', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-003', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-004', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-005', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-006', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-008', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-010', - 'use-the-network/devices/ready-to-use/decentlab/dl-dlr2-012', - 'use-the-network/devices/ready-to-use/decentlab/dl-ds18', - 'use-the-network/devices/ready-to-use/decentlab/dl-dws', - 'use-the-network/devices/ready-to-use/decentlab/dl-itst', - 'use-the-network/devices/ready-to-use/decentlab/dl-kl66', - 'use-the-network/devices/ready-to-use/decentlab/dl-lid', - 'use-the-network/devices/ready-to-use/decentlab/dl-lp8p', - 'use-the-network/devices/ready-to-use/decentlab/dl-optod', - 'use-the-network/devices/ready-to-use/decentlab/dl-par', - 'use-the-network/devices/ready-to-use/decentlab/dl-pm', - 'use-the-network/devices/ready-to-use/decentlab/dl-pr21', - 'use-the-network/devices/ready-to-use/decentlab/dl-pr36', - 'use-the-network/devices/ready-to-use/decentlab/dl-pr36ctd', - 'use-the-network/devices/ready-to-use/decentlab/dl-pyr', - 'use-the-network/devices/ready-to-use/decentlab/dl-rhc', - 'use-the-network/devices/ready-to-use/decentlab/dl-sht35-001', - 'use-the-network/devices/ready-to-use/decentlab/dl-sht35-002', - 'use-the-network/devices/ready-to-use/decentlab/dl-smtp', - 'use-the-network/devices/ready-to-use/decentlab/dl-tbrg', - 'use-the-network/devices/ready-to-use/decentlab/dl-trs11', - 'use-the-network/devices/ready-to-use/decentlab/dl-trs12', - 'use-the-network/devices/ready-to-use/decentlab/dl-trs21', - 'use-the-network/devices/ready-to-use/decentlab/dl-wrm', - 'use-the-network/devices/ready-to-use/decentlab/dl-zn1', - 'use-the-network/devices/ready-to-use/decentlab/dl-zn2', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Develiot', - items: [ - 'use-the-network/devices/ready-to-use/develiot/rwmr', - 'use-the-network/devices/ready-to-use/develiot/uaqms', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Digtal Matter', - items: [ - 'use-the-network/devices/ready-to-use/digital-matter/oyster', - 'use-the-network/devices/ready-to-use/digital-matter/yabby-edge', - 'use-the-network/devices/ready-to-use/digital-matter/digital-matter-lorawan-gps', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Dragino', - items: [ - 'use-the-network/devices/ready-to-use/dragino/rs485-ln', - 'use-the-network/devices/ready-to-use/dragino/rs485-bl', - 'use-the-network/devices/ready-to-use/dragino/lsn50v2-s31', - 'use-the-network/devices/ready-to-use/dragino/lsn50v2-d20', - 'use-the-network/devices/ready-to-use/dragino/ldds20', - 'use-the-network/devices/ready-to-use/dragino/ldds75', - 'use-the-network/devices/ready-to-use/dragino/lbt1', - 'use-the-network/devices/ready-to-use/dragino/lse01', - 'use-the-network/devices/ready-to-use/dragino/lwl01', - 'use-the-network/devices/ready-to-use/dragino/lds01', - 'use-the-network/devices/ready-to-use/dragino/lds02', - 'use-the-network/devices/ready-to-use/dragino/lgt92', - 'use-the-network/devices/ready-to-use/dragino/lt22222-l', - 'use-the-network/devices/ready-to-use/dragino/lt33222-l', - 'use-the-network/devices/ready-to-use/dragino/lht65', - 'use-the-network/devices/ready-to-use/dragino/lsn50-v2', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Enthutech', - items: [ - 'use-the-network/devices/ready-to-use/enthutech/rs485-ln', - 'use-the-network/devices/ready-to-use/enthutech/rs485-bl', - 'use-the-network/devices/ready-to-use/enthutech/lsn50v2-s31', - 'use-the-network/devices/ready-to-use/enthutech/lsn50v2-d20', - 'use-the-network/devices/ready-to-use/enthutech/ldss20', - 'use-the-network/devices/ready-to-use/enthutech/ldds75', - 'use-the-network/devices/ready-to-use/enthutech/lbt1', - 'use-the-network/devices/ready-to-use/enthutech/lse01', - 'use-the-network/devices/ready-to-use/enthutech/lwl01', - 'use-the-network/devices/ready-to-use/enthutech/lds01', - ], - collapsed: true, - }, - { - type: 'category', - label: 'IMST', - items: [ - 'use-the-network/devices/ready-to-use/imst/range-extender', - 'use-the-network/devices/ready-to-use/imst/ioke868', - ], - collapsed: true, - }, - { - type: 'category', - label: 'IoTsens', - items: [ - 'use-the-network/devices/ready-to-use/iotsens/sound-device', - 'use-the-network/devices/ready-to-use/iotsens/airquality-device', - 'use-the-network/devices/ready-to-use/iotsens/lidar-device', - ], - collapsed: true, - }, - { - type: 'category', - label: 'izinto', - items: ['use-the-network/devices/ready-to-use/izinto/izi-io-4840'], - collapsed: true, - }, - { - type: 'category', - label: 'Laird', - items: [ - 'use-the-network/devices/ready-to-use/laird/rs1xx-temp-rh-sensor', - 'use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-1w-sensor', - 'use-the-network/devices/ready-to-use/laird/rs1xx-ext-multi-sensor', - 'use-the-network/devices/ready-to-use/laird/rs1xx-ext-temp-rtd-sensor', - ], - collapsed: true, - }, - { - type: 'category', - label: 'mcf88', - items: [ - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw06davk', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw06davpk', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw12co2', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw12met', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw12plg', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw12ter', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw12terwp', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw12terpm', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw12voc', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw13io', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lw13mio', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lwws00', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lwws01', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lwws02', - 'use-the-network/devices/ready-to-use/mcf88/mcf-lwws03', - ], - collapsed: true, - }, - { - type: 'category', - label: 'MClimate', - items: [ - 'use-the-network/devices/ready-to-use/mclimate/vicki', - 'use-the-network/devices/ready-to-use/mclimate/t-valve', - 'use-the-network/devices/ready-to-use/mclimate/flood-sensor', - 'use-the-network/devices/ready-to-use/mclimate/ht-sensor', - 'use-the-network/devices/ready-to-use/mclimate/aqi-sensor', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Milesight', - items: [ - 'use-the-network/devices/ready-to-use/milesight-iot/am107', - 'use-the-network/devices/ready-to-use/milesight-iot/em300-th', - 'use-the-network/devices/ready-to-use/milesight-iot/em500-co2', - 'use-the-network/devices/ready-to-use/milesight-iot/em500-udl', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Moko', - items: [ - 'use-the-network/devices/ready-to-use/moko/lw001-bg', - 'use-the-network/devices/ready-to-use/moko/lw003-b', - 'use-the-network/devices/ready-to-use/moko/lw004', - 'use-the-network/devices/ready-to-use/moko/lw005-mp', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Netvox', - items: [ - 'use-the-network/devices/ready-to-use/netvox/r311a', - 'use-the-network/devices/ready-to-use/netvox/r311b', - 'use-the-network/devices/ready-to-use/netvox/r311g', - 'use-the-network/devices/ready-to-use/netvox/r311w', - 'use-the-network/devices/ready-to-use/netvox/r312', - 'use-the-network/devices/ready-to-use/netvox/r312a', - 'use-the-network/devices/ready-to-use/netvox/r711', - 'use-the-network/devices/ready-to-use/netvox/r718a', - 'use-the-network/devices/ready-to-use/netvox/r718ab', - 'use-the-network/devices/ready-to-use/netvox/r718b', - 'use-the-network/devices/ready-to-use/netvox/r718ck', - 'use-the-network/devices/ready-to-use/netvox/r718ct', - 'use-the-network/devices/ready-to-use/netvox/r718e', - 'use-the-network/devices/ready-to-use/netvox/r718f', - 'use-the-network/devices/ready-to-use/netvox/r718n1', - 'use-the-network/devices/ready-to-use/netvox/r718n3', - 'use-the-network/devices/ready-to-use/netvox/r718t', - 'use-the-network/devices/ready-to-use/netvox/r720a', - 'use-the-network/devices/ready-to-use/netvox/r72615', - 'use-the-network/devices/ready-to-use/netvox/r72615a', - 'use-the-network/devices/ready-to-use/netvox/ra0715', - 'use-the-network/devices/ready-to-use/netvox/ra0715y', - 'use-the-network/devices/ready-to-use/netvox/rb02i', - 'use-the-network/devices/ready-to-use/netvox/rb11e', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Nwave', - items: ['use-the-network/devices/ready-to-use/nwave/nps310sm'], - collapsed: true, - }, - { - type: 'category', - label: 'Origo', - items: [ - 'use-the-network/devices/ready-to-use/origo/lorawan-watch', - 'use-the-network/devices/ready-to-use/origo/smart-badges', - ], + 'network-iot/lorawan-roaming', - collapsed: true, - }, - { - type: 'category', - label: 'RAKwireless', - items: [ - 'use-the-network/devices/ready-to-use/rakwireless/rak2171', - 'use-the-network/devices/ready-to-use/rakwireless/rak7200', - 'use-the-network/devices/ready-to-use/rakwireless/rak7201', - 'use-the-network/devices/ready-to-use/rakwireless/rak7204', - 'use-the-network/devices/ready-to-use/rakwireless/rak7431', - 'use-the-network/devices/ready-to-use/rakwireless/rak10700', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Seeed Studio', - items: [ - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2100-data-logger', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2101-tem-humid', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2102-light', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2103-co2-tem-humid', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2104-soil-mois-tem', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-s2105-soil-mois-tem-ec', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-soil-th', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-air-th', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-light', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-co2', - 'use-the-network/devices/ready-to-use/seeed-studio/sensecap-pressure', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Sensedge', - items: [ - 'use-the-network/devices/ready-to-use/sensedge/senstick-pro', - 'use-the-network/devices/ready-to-use/sensedge/senstick-pure', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Tektelic', - items: [ - 'use-the-network/devices/ready-to-use/tektelic/t000489x-smart-room-base', - 'use-the-network/devices/ready-to-use/tektelic/t00048xx-smart-room-pir', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Tekzitel', - items: ['use-the-network/devices/ready-to-use/tekzitel/tekzipark'], - collapsed: true, - }, - { - type: 'category', - label: 'The Things Products', - items: [ - 'use-the-network/devices/ready-to-use/the-things-products/the-things-node', - 'use-the-network/devices/ready-to-use/the-things-products/the-things-uno', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Victor', - items: ['use-the-network/devices/ready-to-use/victor/victor-trap-v4xx'], - collapsed: true, - }, - ], - - iot_device_development: [ - { - type: 'link', - label: '<- Devices', - href: '/use-the-network/devices', - }, - 'use-the-network/devices/development/development', - { - type: 'category', - label: 'Adafruit', - items: [ - 'use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruit-feather-m0-rfm95', - 'use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/arduino', - 'use-the-network/devices/development/adafruit/adafruit-feather-m0-rfm95/adafruitio', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Arduino', - items: [ - 'use-the-network/devices/development/arduino/mkr-wan-1310', - { - type: 'category', - label: 'Portenta Vision Shield', - link: { - type: 'doc', - id: 'use-the-network/devices/development/arduino/lora-vision-shield/lora-vision-shield', - }, - items: ['use-the-network/devices/development/arduino/lora-vision-shield/arduino'], - collapsed: true, - }, - ], - collapsed: true, - }, - { - type: 'category', - label: 'Embit', - items: [ - 'use-the-network/devices/development/embit/emb-lr1280s', - 'use-the-network/devices/development/embit/emb-lrwl55', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Heltec', - items: [ - 'use-the-network/devices/development/heltec/cubecell-gps-6502', { type: 'category', - label: 'HTCC-AB01', - link: { - type: 'doc', - id: 'use-the-network/devices/development/heltec/cubecell-dev-board/cubecell-dev-board', - }, + label: 'Data-Only Hotspots', + link: { type: 'doc', id: 'network-iot/hotspots-iot/data-only-hotspots' }, items: [ - 'use-the-network/devices/development/heltec/cubecell-dev-board/arduino', - 'use-the-network/devices/development/heltec/cubecell-dev-board/platformio', + 'network-iot/hotspots-iot/data-only-hotspots', + 'network-iot/hotspots-iot/data-only-hotspots-onboarding', + 'network-iot/hotspots-iot/data-only/balena-data-only-hotspot', + 'network-iot/hotspots-iot/data-only/dragino-data-only-hotspot', + 'network-iot/hotspots-iot/data-only/kerlink-data-only-hotspot', + 'network-iot/hotspots-iot/data-only/rak-concentrators', ], - collapsed: true, - }, - 'use-the-network/devices/development/heltec/cubecell-dev-board-plus', - 'use-the-network/devices/development/heltec/cubecell-1-2-aa-node', - 'use-the-network/devices/development/heltec/cubecell-capsule-sensor', - 'use-the-network/devices/development/heltec/cubecell-solar-sensor', - 'use-the-network/devices/development/heltec/cubecell-module', - 'use-the-network/devices/development/heltec/cubecell-module-plus', - { - type: 'category', - label: 'Wifi Lora 32 V2', - link: { - type: 'doc', - id: 'use-the-network/devices/development/heltec/wifi-lora-32-v2/wifi-lora-32-v2', - }, - items: ['use-the-network/devices/development/heltec/wifi-lora-32-v2/arduino'], - collapsed: true, }, - 'use-the-network/devices/development/heltec/wireless-stick', - 'use-the-network/devices/development/heltec/wireless-stick-lite', - 'use-the-network/devices/development/heltec/wireless-shell', - 'use-the-network/devices/development/heltec/lora-kit-151', - 'use-the-network/devices/development/heltec/lora-node-151', - 'use-the-network/devices/development/heltec/turtle-board', ], collapsed: true, }, { type: 'category', - label: 'MCCI', - items: [ - 'use-the-network/devices/development/mcci/catena4430', - 'use-the-network/devices/development/mcci/catena4450', - 'use-the-network/devices/development/mcci/catena4460', - 'use-the-network/devices/development/mcci/catena4470', - 'use-the-network/devices/development/mcci/catena4610', - 'use-the-network/devices/development/mcci/catena4612', - 'use-the-network/devices/development/mcci/catena4618', - 'use-the-network/devices/development/mcci/catena4618m201', - 'use-the-network/devices/development/mcci/catena4801', - 'use-the-network/devices/development/mcci/catena4802', - 'use-the-network/devices/development/mcci/model4811', - 'use-the-network/devices/development/mcci/model4821', - 'use-the-network/devices/development/mcci/model4822', - 'use-the-network/devices/development/mcci/model4823', - 'use-the-network/devices/development/mcci/model4831', - 'use-the-network/devices/development/mcci/model4832', - 'use-the-network/devices/development/mcci/model4841', - ], + label: 'Tokens', + link: { type: 'doc', id: 'tokens/hnt-token' }, + items: ['tokens/hnt-token', 'tokens/data-credit', 'tokens/sol-token'], collapsed: true, }, { type: 'category', - label: 'Midatronics', + label: 'Wallets', + link: { type: 'doc', id: 'wallets/wallets' }, items: [ - 'use-the-network/devices/development/midatronics/windy-module', - 'use-the-network/devices/development/midatronics/windy-mkr', - 'use-the-network/devices/development/midatronics/sharky-module', + 'wallets/wallets', + 'wallets/helium-wallet-app', + 'wallets/third-party-wallets', + 'wallets/wallet-seed-phrase', + 'wallets/ledger-wallet', + 'wallets/cli-wallet', ], collapsed: true, }, { type: 'category', - label: 'Multi-Tech', - items: ['use-the-network/devices/development/multi-tech/multi-tech-xdot'], - collapsed: true, - }, - { - type: 'category', - label: 'OpenSource Initiative', - items: ['use-the-network/devices/development/opensourceinitiative/paxcounter'], - collapsed: true, - }, - { - type: 'category', - label: 'RAK Wireless', + label: 'Network Data', + link: { type: 'doc', id: 'network-data/network-data' }, items: [ { type: 'category', - label: 'Wisblock Starter Kit Rak4631', - link: { - type: 'doc', - id: 'use-the-network/devices/development/rakwireless/wisblock-4631/wisblock-4631', - }, - items: [ - 'use-the-network/devices/development/rakwireless/wisblock-4631/arduino', - 'use-the-network/devices/development/rakwireless/wisblock-4631/platformio', - ], - collapsed: true, + label: 'API Providers', + link: { type: 'doc', id: 'network-data/api-providers' }, + items: ['network-data/entity-api'], }, - 'use-the-network/devices/development/rakwireless/rak7431', - ], - collapsed: true, - }, - { - type: 'category', - label: 'Seeed Studio', - items: [ - 'use-the-network/devices/development/seeed-studio/loramodule-e5', - 'use-the-network/devices/development/seeed-studio/loramodule-e5-devkit', - 'use-the-network/devices/development/seeed-studio/loramodule-e5-mini', - 'use-the-network/devices/development/seeed-studio/loramodule-e5-grove', - 'use-the-network/devices/development/seeed-studio/seeed-studio-lorawan-dev-kit', - ], - - collapsed: true, - }, - { - type: 'category', - label: 'Sparkfun', - items: [ - 'use-the-network/devices/development/sparkfun/pro-rf/pro-rf', - 'use-the-network/devices/development/sparkfun/pro-rf/arduino', - ], - collapsed: true, - }, - { - type: 'category', - label: 'STMicroelectronics', - items: [ + 'network-data/oracle-data', { type: 'category', - label: 'ST B-L072Z-LRWAN1', - link: { - type: 'doc', - id: 'use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/st-b-l072z-lrwan1', - }, + label: 'Solana Data', + link: { type: 'doc', id: 'network-data/solana-data' }, items: [ - 'use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/arduino', - 'use-the-network/devices/development/stmicroelectronics/st-b-l072z-lrwan1/platformio', + 'network-data/solana/rewardable-entities', + 'network-data/solana/compression-nfts', + 'network-data/solana/helium-program-library', ], - collapsed: true, }, - 'use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc1', - 'use-the-network/devices/development/stmicroelectronics/nucleo-wl55jc2', + 'network-data/legacy-blockchain-data', ], collapsed: true, }, ], - - migration: [ - 'solana/migration-overview', - 'solana/migration-faq', - 'solana/migration/hotspot-operator', - 'solana/migration/validator-operator', - { - type: 'category', - label: 'Hotspot Maker', - items: ['solana/migration/maker', 'solana/migration/maker-hotspot-software'], - }, - 'solana/migration/exchange', - 'solana/migration/network-user', - 'solana/migration/console-operator', - 'solana/migration/application-builder', - 'solana/migration/governance', - 'solana/migration/blockchain-node', - 'solana/migration/blockchain-api', - 'solana/migration/blockchain-etl', - 'solana/migration/wallet-user', - 'solana/migration/ledger', - 'solana/migration/hst', - ], } diff --git a/src/css/custom.css b/src/css/custom.css index 3515d9e6b..e8f79aa3b 100644 --- a/src/css/custom.css +++ b/src/css/custom.css @@ -7,7 +7,8 @@ /* You can override the default Infima variables here. */ :root { - --ifm-color-primary: #474cfe; + --ifm-background-color: #fff; + --ifm-color-primary: #a334fb; --ifm-color-primary-dark: #272dfe; --ifm-color-primary-darker: #171dfe; --ifm-color-primary-darkest: #0107e2; @@ -17,40 +18,51 @@ --ifm-code-font-size: 95%; --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1); --ifm-font-family-base: 'Inter'; + --ifm-font-color-base: #000; --ifm-toc-border-color: #ffffff; --ifm-menu-color-active: #a334fb; - --ifm-menu-color-background-active: #fcf9ff; + --ifm-menu-color-background-active: #f6f7fe; + --ifm-menu-color-background-hover: #f6f7fe; --ifm-menu-color: #1c1e21; - --ifm-navbar-link-hover-color: #333; --ifm-color-info: #a334fb; --ifm-tabs-padding-horizontal: 20px; --ifm-tabs-padding-vertical: 10px; + --ifm-table-stripe-background: #f6f7fe; + + --docsearch-highlight-color: #a334fb; + --docsearch-logo-color: #a334fb; } -/* For readability concerns, you should choose a lighter palette in dark mode. */ -[data-theme='dark'] { - --ifm-color-primary-lightest: #cbccff; - --ifm-color-primary-lighter: #afb1ff; - --ifm-color-primary-light: #a0a3ff; - --ifm-color-primary: #686df8; - --ifm-color-primary-dark: #7b7ff6; - --ifm-color-primary-darker: #6f73f3; - --ifm-color-primary-darkest: #585dfe; - --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3); - --ifm-toc-border-color: #ffffff; - --ifm-menu-color-active: #a334fb; - --ifm-menu-color-background-active: #fcf9ff; - --ifm-menu-color: #1c1e21; - --ifm-navbar-link-hover-color: #333; - --ifm-color-info: #a334fb; - --ifm-tabs-padding-horizontal: 20px; - --ifm-tabs-padding-vertical: 10px; +html[data-theme='dark'] { + --ifm-background-color: #13162e; + --ifm-menu-color: #ffffff; + --ifm-menu-color-background-active: rgba(255, 255, 255, 0.05); + --ifm-menu-color-background-hover: rgba(255, 255, 255, 0.1); + --ifm-navbar-background-color: rgba(19, 22, 46, 0.8); + --ifm-navbar-link-color: #ffffff; + --ifm-heading-color: #ffffff; + --ifm-font-color-base: #fff; + --ifm-table-stripe-background: rgba(105, 92, 92, 0.05); + --ifm-toc-border-color: rgba(255, 255, 255, 0.1); + --ifm-hr-background-color: #eee; + + --ifm-color-emphasis-300: rgba(255, 255, 255, 0.2); /* bottom nav button borders */ + + --docsearch-searchbox-background: rgba(255, 255, 255, 0.05); + --docsearch-searchbox-focus-background: rgba(255, 255, 255, 0.1); + --docsearch-text-color: #ffffff; + --docsearch-muted-color: #acb0c5; } .container { max-width: 1920px; } +.react-toggle .react-toggle-thumb, +.react-toggle--checked .react-toggle-thumb { + border-color: #fff !important; +} + .react-toggle-track { background-color: rgba(0, 0, 0, 0.2) !important; } @@ -59,10 +71,17 @@ box-shadow: none; background: rgba(255, 255, 255, 0.7); backdrop-filter: blur(10px); + border-bottom: 1px solid #ddd; +} + +[data-theme='dark'] .navbar { + background: rgba(19, 22, 46, 0.8); + border-bottom: 1px solid #333; } .menu { - padding-top: 80px !important; + padding-top: 16px !important; + padding-bottom: 25vh; /* extra scroll space on mobile */ font-weight: 400; } @@ -135,6 +154,10 @@ img.techicon { border-bottom: 1px solid #dadfeb; } +[data-theme='dark'] .flex { + border-bottom: 1px solid #445; +} + .headertext { max-width: 750px; } @@ -145,6 +168,10 @@ img.techicon { border-top: 1px solid #dadfeb; } +[data-theme='dark'] .borderTop div:first-of-type { + border-top: 1px solid #445; +} + .borderTop div:first-of-type p { max-width: 90%; } @@ -157,11 +184,16 @@ img.headericon { a { color: #a334fb; } + a:hover { - color: #6600b7; + filter: brightness(75%); text-decoration: none; } +[data-theme='dark'] a:hover { + filter: brightness(130%); +} + a:hover img.docicon { padding-right: 3px; padding-left: 3px; @@ -179,6 +211,11 @@ a:hover img.docicon { border: none; } +html[data-theme='dark'] .badge--secondary { + color: #ffffff; + background: rgba(255, 255, 255, 0.1); +} + .badge--secondary:hover { color: #7085ba; background: #dfe6f6; @@ -211,6 +248,11 @@ hr { margin-bottom: 20px; } +[data-theme='dark'] hr { + border-top: 1px solid #445; + background-color: #000; +} + .menu__link--sublist:after { background-size: 1rem 1rem; } @@ -332,55 +374,14 @@ a.quicklinkblue { color: #474dff; } -a.quicklinkblue:hover { - color: #2d32b6; -} - a.quicklinkgreen { color: #0eb98f; } -a.quicklinkgreen:hover { - color: #0a8566; -} - a.quicklinkred { color: #e35851; } -a.quicklinkred:hover { - color: #9c3a35; -} - -.announcementnav { - background: #474dff; - border-radius: 9999px; - padding: 4px 16px; - color: white; - display: flex; - transition: all 0.2s ease; - align-items: center; - white-space: nowrap; -} - -.announcementnav:hover { - color: white; -} - -.announcementnav:before { - content: ''; - width: 16px; - height: 16px; - display: inline-block; - padding-right: 6px; - background: url("data:image/svg+xml,%3Csvg viewBox='0 0 16 16' fill='white' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='M16 1.00002C15.9999 0.829624 15.9563 0.662082 15.8733 0.513287C15.7902 0.364492 15.6706 0.23938 15.5256 0.149821C15.3806 0.0602626 15.2152 0.00922872 15.045 0.00156219C14.8748 -0.00610433 14.7054 0.0298506 14.553 0.106016L6.763 4.00002H3C2.20435 4.00002 1.44129 4.31609 0.87868 4.8787C0.316071 5.4413 0 6.20437 0 7.00002C0 7.79567 0.316071 8.55873 0.87868 9.12134C1.44129 9.68394 2.20435 10 3 10H3.28L5.051 15.316C5.11735 15.5152 5.24472 15.6885 5.41505 15.8113C5.58538 15.934 5.79004 16.0001 6 16H7C7.26522 16 7.51957 15.8947 7.70711 15.7071C7.89464 15.5196 8 15.2652 8 15V10.618L14.553 13.894C14.7054 13.9702 14.8748 14.0061 15.045 13.9985C15.2152 13.9908 15.3806 13.9398 15.5256 13.8502C15.6706 13.7607 15.7902 13.6355 15.8733 13.4867C15.9563 13.3379 15.9999 13.1704 16 13V1.00002Z'/%3E%3C/svg%3E") - no-repeat; -} - -.announcementnav span { - font-weight: 300; -} - a.block { display: block; width: fit-content; @@ -411,23 +412,9 @@ a.block { padding-top: 5rem !important; } -html[data-theme='light'] { - --ifm-background-color: #fff; - --ifm-table-stripe-background: #f6f7fe; - --ifm-menu-color-background-active: #f6f7fe; - --ifm-menu-color-background-hover: #f6f7fe; - --ifm-navbar-link-hover-color: #333; - - --docsearch-highlight-color: #a334fb; - --docsearch-logo-color: #a334fb; -} -.react-toggle .react-toggle-thumb, -.react-toggle--checked .react-toggle-thumb { - border-color: #fff !important; -} - -html[data-theme='dark'] { - --ifm-background-color: #13162e; +/* fixes invisible light/dark toggle in light mode */ +[data-theme='light'] .clean-btn { + color: #000; } .navbar__brand { @@ -443,13 +430,6 @@ html[data-theme='dark'] { color: #a334fb; } -.navbar__link.announcementnav, -.navbar__link:hover.announcementnav { - color: white; - background: #474dff; - transition: all 0.2s ease; -} - .navbar__link { color: black; } @@ -476,8 +456,8 @@ html[data-theme='light'] .header-github-link:before { text-decoration: none !important; } -img.docsheadersmall { - display: none; +img.docsheader { + margin-bottom: 20px; } img.appscreenbanner { @@ -494,37 +474,36 @@ img.explorerSidebar { display: inline-block; } +/* mobile only */ +.navbar-sidebar { + background: rgba(255, 255, 255, 1); + /* box-shadow: none; */ + /* backdrop-filter: none; */ +} + +[data-theme='dark'] .navbar-sidebar { + background: rgba(19, 22, 46, 0.8); + backdrop-filter: blur(10px); +} + @media only screen and (max-width: 996px) { .navbar { box-shadow: none; - background: rgba(255, 255, 255, 0.7); backdrop-filter: none; - --ifm-navbar-background-color: rgba(255, 255, 255, 1); - --ifm-menu-color: #000000; - color: #000000; } + .menu__link { color: #000; } + [data-theme='dark'] .menu__link { + color: #fff; + } + .searchBox_node_modules-\@docusaurus-theme-classic-lib-theme-Navbar-Search-styles-module { position: relative !important; right: 0 !important; } - - .navbar__items--right .announcementnav { - margin-right: 1vw; - } - - img.docsheaderhome { - display: none; - } - - img.docsheadersmall { - display: block; - width: 400px; - margin-bottom: 20px; - } } @media only screen and (max-width: 768px) { @@ -609,69 +588,17 @@ html[data-theme='dark'] h2.subtitle, html[data-theme='dark'] h5, html[data-theme='dark'] h4, html[data-theme='dark'] p { - color: #acb0c5; + color: #eee; } html[data-theme='dark'] a.quicklink, html[data-theme='dark'] .badge--secondary { - background: #3e3f3f; + background: rgba(255, 255, 255, 0.1); } html[data-theme='dark'] a.quicklink:hover, html[data-theme='dark'] .badge--secondary:hover { - background: #313232; -} - -/* solana migration status */ -.migration-status { - display: flex; - justify-content: space-between; - font-size: 1rem; - color: white; - background: #474dff; - padding: 0.25rem 1rem; - margin: 1rem 0; - border-radius: 0.25rem; - transition: opacity 0.3s ease; -} - -@keyframes gradient { - 0% { - background-position: 0% 50%; - } - 50% { - background-position: 100% 50%; - } - 100% { - background-position: 0% 50%; - } -} - -.migration-status.migration-status-fetching { - opacity: 0.3; -} - -.migration-status .countdown { - font-variant-numeric: tabular-nums; -} - -.migration-status-not-started { -} - -.migration-status-in-progress { - background: linear-gradient(-45deg, #ee7752, #e73c7e, #23a6d5, #23d5ab); - background-size: 400% 400%; - animation: gradient 15s ease infinite; -} - -.migration-status-complete .countdown { - display: none; -} - -.migration-status-unknown, -.migration-status-error { - visibility: hidden; - opacity: 0; + background: rgba(0, 0, 0, 0.2); } /* DcCostEstimator.jsx */ @@ -704,6 +631,12 @@ html[data-theme='dark'] .badge--secondary:hover { border: none; } +[data-theme='dark'] .dc-calc-input-group input, +[data-theme='dark'] .dc-calc-input-group select { + background-color: rgba(255, 255, 255, 0.1); + color: #fff; +} + .dc-calc-input-group input { width: 6em; } @@ -728,23 +661,33 @@ html[data-theme='dark'] .badge--secondary:hover { margin-top: -0.5em; } +[data-theme='dark'] .dc-calc-table-title { + color: #eee; +} + .dc-calc-table { display: table; background: white; width: 100%; - /* margin-top: 0.25em; */ table-layout: fixed; border: none; border-radius: 8px; box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); } + +[data-theme='dark'] .dc-calc-table { + background: rgba(255, 255, 255, 0.05); +} + .dc-calc-table td, .dc-calc-table th { border: none; } + .dc-calc-table tr { border: none; } + .dc-calc-table th { font-weight: 500; background: #eaeff9; @@ -752,21 +695,115 @@ html[data-theme='dark'] .badge--secondary:hover { padding: 0.5em; border-right: 2px solid white; } + +[data-theme='dark'] .dc-calc-table th { + background: rgba(255, 255, 255, 0.1); + color: #eee; + border-right: 2px solid rgba(19, 22, 46, 0.8); +} + .dc-calc-table th:first-child { border-top-left-radius: 8px; } + .dc-calc-table th:last-child { border-top-right-radius: 8px; border: none; } + .dc-calc-table td { font-weight: bold; text-align: center; overflow: hidden; white-space: nowrap; } + +[data-theme='dark'] .dc-calc-table td { + color: #fff; +} /* End DcCostEstimator.jsx */ +/* DisplayLegacyWallet.tsx */ +.display-legacy-wallet { + padding: 16px; + width: 100%; +} + +.display-legacy-wallet input { + width: 100%; + font-size: 1em; + margin: 0 0 0.5em 0; + background-color: #fff; + padding: 1em; + box-shadow: 0 3px 6px -3px rgba(0, 0, 0, 0.1); + border-radius: 6px; + border: none; +} + +.display-legacy-wallet table { + display: table; + background: white; + width: 100%; + margin: 1em 0 0 0; + table-layout: fixed; + border: none; + border-radius: 8px; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); +} + +.display-legacy-wallet td { + border: none; + padding: 0.5em; +} +.display-legacy-wallet table tr { + border: none; + background: white; +} + +.display-legacy-wallet td:first-child { + font-weight: 500; + background: #eaeff9; + color: #53627c; + border-bottom: 2px solid white; + width: 10em; + padding-left: 1em; +} + +.display-legacy-wallet tr:first-child td:first-child { + border-top-left-radius: 8px; +} +.display-legacy-wallet tr:first-child td:last-child { + border-top-right-radius: 8px; +} +.display-legacy-wallet tr:last-child td:first-child { + border-bottom-left-radius: 8px; + border: none; +} +.display-legacy-wallet tr:last-child td:last-child { + border-bottom-right-radius: 8px; +} + +[data-theme='dark'] .display-legacy-wallet input { + background-color: rgba(255, 255, 255, 0.1); + color: white; +} + +[data-theme='dark'] .display-legacy-wallet table { + background: rgba(255, 255, 255, 0.05); +} + +[data-theme='dark'] .display-legacy-wallet table tr { + background: rgba(255, 255, 255, 0.05); +} + +[data-theme='dark'] .display-legacy-wallet td:first-child { + background: rgba(255, 255, 255, 0.1); + color: #eee; + border-bottom: 1px solid rgba(19, 22, 46, 0.8); +} + +/* End DisplayLegacyWallet.tsx */ + .screensnippet-wrapper { background: #f5f7fd; border-radius: 24px; @@ -778,6 +815,16 @@ html[data-theme='dark'] .badge--secondary:hover { justify-content: center; flex-direction: column; } + +[data-theme='dark'] .screensnippet-wrapper { + background: rgba(255, 255, 255, 0.1); + color: white; +} + +[data-theme='dark'] .screensnippet-wrapper svg path { + fill: white; +} + .screensnippet-wrapper img { max-height: 150px; } @@ -789,13 +836,30 @@ html[data-theme='dark'] .badge--secondary:hover { font-weight: 500; padding: 0.25rem 1rem; border-radius: 18px; + white-space: normal; +} + +[data-theme='dark'] .screensnippet-wrapper figcaption { + background: rgba(255, 255, 255, 0.1); + color: rgba(255, 255, 255, 0.9); +} + +.screensnippet-wrapper figcaption > p { + all: inherit; } + .screensnippet-wrapper .add-shadow { - box-shadow: 0px 1.4px 5.2px -10px rgba(0, 0, 0, 0.004), 0px 2.3px 8.2px -10px rgba(0, 0, 0, 0.006), - 0px 3px 10.5px -10px rgba(0, 0, 0, 0.008), 0px 3.5px 12.6px -10px rgba(0, 0, 0, 0.009), - 0px 4px 14.7px -10px rgba(0, 0, 0, 0.01), 0px 4.4px 16.8px -10px rgba(0, 0, 0, 0.011), - 0px 5px 19.1px -10px rgba(0, 0, 0, 0.012), 0px 5.8px 21.8px -10px rgba(0, 0, 0, 0.014), - 0px 7px 25.6px -10px rgba(0, 0, 0, 0.016), 0px 10px 36px -10px rgba(0, 0, 0, 0.02); + box-shadow: + 0px 1.4px 5.2px -10px rgba(0, 0, 0, 0.004), + 0px 2.3px 8.2px -10px rgba(0, 0, 0, 0.006), + 0px 3px 10.5px -10px rgba(0, 0, 0, 0.008), + 0px 3.5px 12.6px -10px rgba(0, 0, 0, 0.009), + 0px 4px 14.7px -10px rgba(0, 0, 0, 0.01), + 0px 4.4px 16.8px -10px rgba(0, 0, 0, 0.011), + 0px 5px 19.1px -10px rgba(0, 0, 0, 0.012), + 0px 5.8px 21.8px -10px rgba(0, 0, 0, 0.014), + 0px 7px 25.6px -10px rgba(0, 0, 0, 0.016), + 0px 10px 36px -10px rgba(0, 0, 0, 0.02); } .screensnippet-wrapper:has(.add-shadow-margin) { @@ -810,9 +874,16 @@ html[data-theme='dark'] .badge--secondary:hover { border-radius: 18px; } -:is(:hover) > .🥩 { - display: initial; +.screensnippet-wrapper:has(.docslabEditor) > div { + width: 100%; } -.🥩 { - display: none; + +.screensnippet-wrapper .docslabEditor { + width: 100%; + max-height: 550px; + height: 50vh; } + +.font-disable-calt { + font-feature-settings:'calt' 0,'calt'0; +} \ No newline at end of file diff --git a/src/theme/DisplayLegacyWallet.tsx b/src/theme/DisplayLegacyWallet.tsx new file mode 100644 index 000000000..4f0b637cc --- /dev/null +++ b/src/theme/DisplayLegacyWallet.tsx @@ -0,0 +1,68 @@ +import React, { useState, useMemo } from "react"; +import BrowserOnly from '@docusaurus/BrowserOnly'; +import { PublicKey } from "@solana/web3.js"; +import Address from "@helium/address"; +import { ED25519_KEY_TYPE } from "@helium/address/build/KeyTypes"; + +export const DisplayLegacyWallet = () => { + const [wallet, setWallet] = useState(""); + + return ( +
+ setWallet(e.target.value)} + /> + + {() => { + if (typeof window !== 'undefined' && !window.Buffer) { + window.Buffer = require('buffer/').Buffer; + } + + const solanaWallet = useMemo(() => { + try { + return new PublicKey(wallet); + } catch (e: any) { + try { + return new PublicKey(Address.fromB58(wallet).publicKey); + } catch (e: any) { + // ignore + } + } + }, [wallet]); + + const heliumWallet = useMemo( + () => solanaWallet && new Address(0, 0, ED25519_KEY_TYPE, solanaWallet.toBuffer()), + [solanaWallet] + ); + + return ( + <> + + + + {heliumWallet?.b58 ? ( + + ) : ( + + )} + + + + {solanaWallet?.toBase58() ? ( + + ) : ( + + )} + +
Helium Address{heliumWallet?.b58} Helium base58 public address.
Solana Address{solanaWallet?.toBase58()}Solana base58 public address.
+ + ); + }} + +
+ ); +}; diff --git a/src/theme/EscrowOUIWidget.tsx b/src/theme/EscrowOUIWidget.tsx new file mode 100644 index 000000000..a07a7228d --- /dev/null +++ b/src/theme/EscrowOUIWidget.tsx @@ -0,0 +1,142 @@ +import React, { useState, useCallback } from 'react' +import BrowserOnly from '@docusaurus/BrowserOnly' +import useDocusaurusContext from '@docusaurus/useDocusaurusContext' +import { Connection, Keypair, PublicKey, Transaction } from '@solana/web3.js' +import { delegatedDataCreditsKey, escrowAccountKey } from '@helium/data-credits-sdk' +import { subDaoKey } from '@helium/helium-sub-daos-sdk' +import { IOT_MINT } from '@helium/spl-utils' +import { useAsync } from 'react-async-hook' +import { AnchorProvider } from '@coral-xyz/anchor' +import { getAccount } from '@solana/spl-token' + +export const EscrowOUIWidget = () => { + const [wallet, setWallet] = useState('') + + const getEscrowTokenAccount = useCallback( + (subDao: PublicKey) => { + if (wallet) { + try { + const delegatedDataCredits = delegatedDataCreditsKey(subDao, wallet)[0] + const escrowTokenAccount = escrowAccountKey(delegatedDataCredits)[0] + + return { + escrowTokenAccount: escrowTokenAccount.toBase58(), + delegatedDataCredits: delegatedDataCredits.toBase58(), + } + } catch (e) { + throw e as Error + } + } + }, + [wallet], + ) + + return ( +
+ setWallet(e.target.value)} + /> + + {() => { + if (typeof window !== 'undefined' && !window.Buffer) { + window.Buffer = require('buffer/').Buffer + } + + const IOT_SUB_DAO_KEY = subDaoKey(IOT_MINT)[0] + const escrowTokenAccount = getEscrowTokenAccount(IOT_SUB_DAO_KEY)?.escrowTokenAccount + + return ( + <> + + + + {escrowTokenAccount ? ( + + ) : ( + + )} + + + +
Escrow Account + + {escrowTokenAccount} + + Solana base58 escrow token address
+ + ) + }} + +
+ ) +} + +type OuiAccountDataProps = { + escrowAccount?: PublicKey +} + +const OuiEscrowAccountBalance = ({ escrowAccount }: OuiAccountDataProps) => { + const { siteConfig } = useDocusaurusContext() + const endpoint = siteConfig.customFields.SOLANA_URL! + + const { result: dcBalance } = useAsync(async () => { + if (!endpoint || !escrowAccount) return + try { + const keypair = Keypair.generate() + const wallet = { + publicKey: keypair.publicKey, + signTransaction: async (transaction: Transaction) => { + transaction.partialSign(keypair) + return transaction + }, + signAllTransactions: async (transactions: Transaction[]) => { + return transactions.map((tx) => { + tx.partialSign(keypair) + return tx + }) + }, + } as any + + const provider = new AnchorProvider( + new Connection(endpoint, { + commitment: 'processed', + }), + wallet, + { commitment: 'processed' }, + ) + + const account = await getAccount(provider.connection, escrowAccount) + + return account.amount.toString() + } catch (e) {} + }, [escrowAccount]) + + return ( + + Escrow Account Balance + {dcBalance ? ( + + {Number(dcBalance).toLocaleString()} DC ( + {(Number(dcBalance) * 0.00001).toLocaleString('en-US', { + style: 'currency', + currency: 'USD', + currencyDisplay: 'code', + })} + ) + + ) : ( + Escrow account DC balance + )} + + ) +} diff --git a/src/theme/HntToDcSimulator.jsx b/src/theme/HntToDcSimulator.jsx new file mode 100644 index 000000000..c64eea1ca --- /dev/null +++ b/src/theme/HntToDcSimulator.jsx @@ -0,0 +1,114 @@ +import React, { useEffect, useRef, useState } from 'react' +import { PriceServiceConnection } from '@pythnetwork/price-service-client' +import styles from './HntToDcSimulator.module.css' + +const DC_PRICE = 0.00001 // 1 DC = $0.00001 +const HNT_PRICE_ID = '0x649fdd7ec08e8e2a20f425729854e90293dcbe2376abc47197a14da6ff339756' +const HERMES_ENDPOINT = 'https://hermes.pyth.network' + +function calculateDc(price) { + return price / DC_PRICE +} +function getRoundedPrice(price) { + return Math.round(price * 100) / 100 +} + +export const HntToDcSimulator = () => { + const [liveHntPrice, setLiveHntPrice] = useState(0) + const [simulatedHntPrice, setSimulatedHntPrice] = useState(1) + const [sliderRange, setSliderRange] = useState({ min: 0, max: 5 }) + const initialPriceSetRef = useRef(false) + + useEffect(() => { + const connection = new PriceServiceConnection(HERMES_ENDPOINT, { + priceFeedRequestConfig: { binary: false }, + }) + + const handlePriceUpdate = (priceFeed) => { + const { price, expo } = priceFeed.price + const rawPrice = parseInt(price, 10) + const scaledPrice = rawPrice * 10 ** expo + + if (scaledPrice > 0) { + setLiveHntPrice(scaledPrice) + + if (!initialPriceSetRef.current) { + setInitialSliderValues(scaledPrice) + initialPriceSetRef.current = true + } + } + } + + connection.subscribePriceFeedUpdates([HNT_PRICE_ID], handlePriceUpdate) + + return () => { + connection.closeWebSocket() + } + }, []) + + const setInitialSliderValues = (price) => { + const roundedPrice = getRoundedPrice(price) + setSimulatedHntPrice(roundedPrice) + + const upperLimit = Math.ceil(price / 5) * 5 + 5 + let lowerLimit = Math.max(0, Math.floor(price / 5) * 5 - 5) + if (lowerLimit === 0) { + lowerLimit = 0.01 + } + setSliderRange({ min: lowerLimit, max: upperLimit }) + } + + const handleSliderChange = (event) => { + const newPrice = parseFloat(event.target.value) + setSimulatedHntPrice(newPrice) + } + + const handleSetToLivePrice = () => { + setSimulatedHntPrice(liveHntPrice) + } + + const dcAmount = Math.round(calculateDc(simulatedHntPrice)) + const hntForTenDollars = 10 / simulatedHntPrice + + return ( +
+ + + + + + + + + + + + + +
DC from 1 HNTHNT burned for $10 DC
{dcAmount.toLocaleString()} DC{hntForTenDollars.toLocaleString()} HNT
+ +
+
+ +
+ +
+

Simulated HNT Oracle Price: ${simulatedHntPrice.toFixed(2)}

+ {liveHntPrice !== 0 && ( + + )} +
+
+
+ ) +} diff --git a/src/theme/HntToDcSimulator.module.css b/src/theme/HntToDcSimulator.module.css new file mode 100644 index 000000000..36af2639f --- /dev/null +++ b/src/theme/HntToDcSimulator.module.css @@ -0,0 +1,117 @@ +.componentSpacing { + padding: 16px 16px 0; +} + +.dcEstTable, .interactiveBox { + display: table; + background: white; + width: 100%; + table-layout: fixed; + border: none; + border-radius: 8px; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); +} + +[data-theme='dark'] .dcEstTable, +[data-theme='dark'] .interactiveBox { + background: rgba(255, 255, 255, 0.05); +} + +.interactiveBox { + display: block; + padding: 16px 16px 0; + margin-bottom: 1em; +} + +.dcEstTable td, +.dcEstTable th { + border: none; +} + +.dcEstTable tr { + border: none; +} + +.dcEstTable th { + font-weight: 500; + background: #eaeff9; + color: #53627c; + padding: 0.5em; + border-right: 2px solid white; +} + +[data-theme='dark'] .dcEstTable th { + background: rgba(255, 255, 255, 0.1); + color: #eee; + border-right: 2px solid rgba(19, 22, 46, 0.8); +} + +.dcEstTable th:first-child { + border-top-left-radius: 8px; +} + +.dcEstTable th:last-child { + border-top-right-radius: 8px; + border: none; +} + +.dcEstTable td { + font-weight: bold; + text-align: center; + overflow: hidden; + white-space: nowrap; +} + +[data-theme='dark'] .dcEstTable td { + color: #fff; +} + +.inputContainer { + display: flex; + padding: 0.125em 0 0.125em 0; +} + +.inputContainer input { + flex: 1 1 auto; +} + +[data-theme='dark'] .inputContainer input { + background-color: rgba(255, 255, 255, 0.1); + color: white; +} + +.pricesContainer { + display: flex; + justify-content: space-between; + align-items: baseline; +} + +.setToLivePriceButton { + appearance: none; + background: transparent; + border: none; + cursor: pointer; + color: #5a719a; + padding-left: 1em; + font-size: 1.125rem; + line-height: 1.65rem; + text-align: right; + font-variant-numeric: tabular-nums; + transition: color var(--ifm-transition-fast) var(--ifm-transition-timing-default); +} + +[data-theme='dark'] .setToLivePriceButton { + color: #acb0c5; +} + +.setToLivePriceButton:hover { + color: rgb(18, 49, 103); +} + +[data-theme='dark'] .setToLivePriceButton:hover { + color: #fff; +} + +.textUnderline { + text-decoration: underline; +} \ No newline at end of file diff --git a/src/theme/HntToFeeSol.tsx b/src/theme/HntToFeeSol.tsx index befd7ce4c..f4d72806e 100644 --- a/src/theme/HntToFeeSol.tsx +++ b/src/theme/HntToFeeSol.tsx @@ -1,30 +1,28 @@ +import { BN } from '@coral-xyz/anchor' import useDocusaurusContext from '@docusaurus/useDocusaurusContext' +import { HNT_MINT, sendAndConfirmWithRetry, toNumber } from '@helium/spl-utils' import { useConnection, useWallet } from '@solana/wallet-adapter-react' +import { VersionedTransaction } from '@solana/web3.js' import axios from 'axios' import React, { useEffect, useState } from 'react' import { useAsync, useAsyncCallback } from 'react-async-hook' import './bufferFill' import { Alert, AlertIcon } from './components/Alert' import { Button } from './components/Button' +import { Checkbox } from './components/Checkbox' import { Flex } from './components/Flex' import { Wallet, WrapWithAccountProvider } from './components/Wallet' -import { Transaction } from '@solana/web3.js' -import { sendAndConfirmWithRetry, toNumber } from '@helium/spl-utils' -import { Checkbox } from './components/Checkbox' -import { BN } from '@coral-xyz/anchor' // Default styles that can be overridden by your app require('@solana/wallet-adapter-react-ui/styles.css') export const HntToFeeSolImpl = () => { const { siteConfig } = useDocusaurusContext() - const url = siteConfig.customFields.HNT_TO_RENT_SERVICE_URL + const url = siteConfig.customFields.TOKENS_TO_RENT_SERVICE_URL const { publicKey, wallet } = useWallet() const { connection } = useConnection() const { result: estimate, error: estError } = useAsync(async () => { - const { estimate } = ( - await axios.get(`${url}/estimate`) - ).data + const { estimate } = (await axios.post(`${url}/estimate`, { mint: HNT_MINT.toBase58() })).data return toNumber(new BN(estimate), 8) }, []) @@ -37,10 +35,13 @@ export const HntToFeeSolImpl = () => { const { execute, error, loading } = useAsyncCallback(async () => { if (wallet && connection && wallet.adapter && wallet.adapter.connected) { - const txRaw = (await axios.post(`${url}/hnt-to-fees`, { - wallet: publicKey.toBase58() - })).data - const tx = Transaction.from(Buffer.from(txRaw)) + const txRaw = ( + await axios.post(`${url}/fees`, { + wallet: publicKey.toBase58(), + mint: HNT_MINT.toBase58(), + }) + ).data + const tx = VersionedTransaction.deserialize(Buffer.from(txRaw)) const signed = await wallet.adapter.signTransaction(tx) await sendAndConfirmWithRetry( connection, @@ -52,12 +53,12 @@ export const HntToFeeSolImpl = () => { ) } }) - const [isChecked, setIsChecked] = useState(false); + const [isChecked, setIsChecked] = useState(false) return ( {error && ( - +

{error.message}

 @@ -67,7 +68,7 @@ export const HntToFeeSolImpl = () => { uses of this system. I further agree that I will not use this system for any illegal purpose. setIsChecked((c) => !c)}>I Agree ) diff --git a/src/theme/HstManager.tsx b/src/theme/HstManager.tsx deleted file mode 100644 index d8a383790..000000000 --- a/src/theme/HstManager.tsx +++ /dev/null @@ -1,242 +0,0 @@ -import { ClockworkProvider } from '@clockwork-xyz/sdk' -import { AnchorProvider, BN, Program } from '@coral-xyz/anchor' -import { - PROGRAM_ID, - fanoutKey, - init, - membershipCollectionKey, - membershipVoucherKey, -} from '@helium/fanout-sdk' -import { useIdlAccount, useTokenAccount } from '@helium/helium-react-hooks' -import { Fanout } from '@helium/idls/lib/types/fanout' -import { HNT_MINT, searchAssets, sendInstructions, toNumber } from '@helium/spl-utils' -import { - TOKEN_PROGRAM_ID, - createInitializeMintInstruction, - getAssociatedTokenAddressSync, -} from '@solana/spl-token' -import { useConnection, useWallet } from '@solana/wallet-adapter-react' -import { Keypair, LAMPORTS_PER_SOL, PublicKey, SystemProgram } from '@solana/web3.js' -import React, { useEffect, useMemo } from 'react' -import { useAsync, useAsyncCallback } from 'react-async-hook' -import './bufferFill' -import { Alert, AlertIcon } from './components/Alert' -import { Button } from './components/Button' -import { Flex } from './components/Flex' -import { Wallet, WrapWithAccountProvider } from './components/Wallet' - -// Default styles that can be overridden by your app -require('@solana/wallet-adapter-react-ui/styles.css') - -export const HstManagerImpl = ({ idl }: { idl: Fanout }) => { - const { publicKey, wallet } = useWallet() - const fanoutK = useMemo(() => fanoutKey('HST')[0], []) - const collectionAddress = useMemo(() => membershipCollectionKey(fanoutK)[0], [fanoutK]) - const { connection } = useConnection() - const { result: stakedPosition, error: fetchErr } = useAsync(async () => { - if (publicKey && collectionAddress) { - const assets = await searchAssets(connection.rpcEndpoint, { - grouping: ['collection', collectionAddress.toBase58()], - ownerAddress: publicKey?.toBase58(), - creatorAddress: null, - }) - if (assets) { - return assets[0] - } - } - - return undefined - }, [publicKey, collectionAddress, connection.rpcEndpoint]) - - useEffect(() => { - if (fetchErr) { - console.error(fetchErr) - } - }, [fetchErr]) - - const voucher = useMemo( - () => stakedPosition && membershipVoucherKey(stakedPosition.id)[0], - [stakedPosition], - ) - - const { result: fanoutProgram } = useAsync(async () => { - if (wallet && connection && wallet.adapter && wallet.adapter.connected) { - return await init(new AnchorProvider(connection, wallet.adapter, { commitment: 'confirmed' })) - } - }, [wallet, connection]) - const { info: fanout } = useIdlAccount(fanoutK, idl as Fanout, 'FanoutV0') - const hst = useMemo(() => fanout && fanout.membershipMint, [fanout]) - const stakeAccountKey = useMemo( - () => voucher && hst && getAssociatedTokenAddressSync(hst, voucher, true), - [voucher, hst], - ) - const currAccountKey = useMemo( - () => publicKey && hst && getAssociatedTokenAddressSync(hst, publicKey, true), - [hst, publicKey], - ) - - const clockworkProvider = useMemo( - () => - wallet && - wallet.adapter && - wallet.adapter.connected && - connection && - new ClockworkProvider(wallet.adapter, connection), - [wallet, connection], - ) - const { info: stakeAccount, loading: loadingTokenAccount } = useTokenAccount(stakeAccountKey) - const { info: currAccount, loading: loadingCurrAccount } = useTokenAccount(currAccountKey) - const { execute, loading, error } = useAsyncCallback(async () => { - const name = fanout.name - const mintKeypair = Keypair.generate() - const mint = stakedPosition ? stakedPosition.id : mintKeypair.publicKey - const threadId = `${name}-${mint.toBase58().slice(0, 8)}` - const [thread] = threadKey(publicKey, threadId) - - if (!(publicKey && fanoutK && hst && currAccountKey)) { - throw new Error('Wallet not connected') - } - - async function craftDistribute(payer: PublicKey) { - return await fanoutProgram.methods.distributeV0().accounts({ - payer: payer, - fanout: fanoutK, - mint: HNT_MINT, - owner: publicKey, - }) - } - - if (stakeAccount && stakeAccount.amount > 0) { - const threadExists = await connection.getAccountInfo(thread) - const preInstructions = [] - if (threadExists) { - preInstructions.push(await clockworkProvider.threadDelete(publicKey, thread)) - } - - preInstructions.push(await (await craftDistribute(publicKey)).instruction()) - - // Unstake - await fanoutProgram.methods - .unstakeV0() - .preInstructions(preInstructions) - .accounts({ - mint: stakedPosition.id, - solDestination: publicKey, - voucherAuthority: publicKey, - }) - .rpc({ skipPreflight: true }) - } else { - // Stake - const threadExists = await connection.getAccountInfo(thread) - const preInstructions = [] - // Create daily trigger thread - const trigger = { - cron: { - schedule: '0 0 30 * * * *', - skippable: true, - }, - } - - const voucher = membershipVoucherKey(mintKeypair.publicKey)[0] - - preInstructions.push( - SystemProgram.createAccount({ - fromPubkey: publicKey, - newAccountPubkey: mintKeypair.publicKey, - space: 82, - lamports: await connection.getMinimumBalanceForRentExemption(82), - programId: TOKEN_PROGRAM_ID, - }), - await createInitializeMintInstruction(mintKeypair.publicKey, 0, voucher, voucher), - ) - await fanoutProgram.methods - .stakeV0({ - amount: new BN(currAccount.amount.toString()), - }) - .preInstructions(preInstructions) - .accounts({ - fanout: fanoutK, - recipient: publicKey, - mint: mintKeypair.publicKey, - }) - .signers([mintKeypair]) - .rpc({ skipPreflight: true }) - - if (!threadExists) { - await sendInstructions(fanoutProgram.provider as AnchorProvider, [ - await clockworkProvider.threadCreate( - publicKey, // authority - threadId, // id - [ - await ( - await craftDistribute(new PublicKey('C1ockworkPayer11111111111111111111111111111')) - ).instruction(), - ], // instructions - trigger, // trigger - LAMPORTS_PER_SOL / 10, - ), - ]) - } - } - }) - - if (error) { - console.error(error) - } - - return ( - - {error && ( - - -

{error.message}

- - )} - - - ) -} - -function threadKey(authority: PublicKey, threadId: string): [PublicKey, number] { - return PublicKey.findProgramAddressSync( - [Buffer.from('thread', 'utf8'), authority.toBuffer(), Buffer.from(threadId, 'utf8')], - new PublicKey('CLoCKyJ6DXBJqqu2VWx9RLbgnwwR6BMHHuyasVmfMzBh'), - ) -} - -export const WrapWithIdl = () => { - const { wallet } = useWallet() - const { connection } = useConnection() - const { result: idl } = useAsync(async () => { - return await Program.fetchIdl(PROGRAM_ID, new AnchorProvider(connection, wallet.adapter, {})) - }, []) - - if (idl) { - return - } - - return
-} - -export const HstManager = () => { - return ( - - - - - - ) -} diff --git a/src/theme/LedgerMigration.tsx b/src/theme/LedgerMigration.tsx index 7b7a065e6..a97d37454 100644 --- a/src/theme/LedgerMigration.tsx +++ b/src/theme/LedgerMigration.tsx @@ -1,7 +1,7 @@ import useDocusaurusContext from '@docusaurus/useDocusaurusContext' import { bulkSendRawTransactions } from '@helium/spl-utils' import { LedgerWalletAdapter } from '@solana/wallet-adapter-ledger' -import { Connection, PublicKey, Transaction } from '@solana/web3.js' +import { Connection, PublicKey, VersionedTransaction } from '@solana/web3.js' import axios from 'axios' import React, { useMemo, useState } from 'react' import { useAsyncCallback } from 'react-async-hook' @@ -188,7 +188,7 @@ const Steps: React.FunctionComponent<{ } export const LedgerMigration = () => { - const { nextStep, prevStep, reset, activeStep } = useSteps({ + const { nextStep, prevStep, activeStep } = useSteps({ initialStep: 0, }) const { siteConfig } = useDocusaurusContext() @@ -273,8 +273,7 @@ export const LedgerMigration = () => { } const txs = await getTxs() const txBuffers = txs.map((tx: any) => Buffer.from(tx)) - const deserialized = txBuffers.map((tx: Buffer) => Transaction.from(tx)) - const signed = await heliumWallet!.signAllTransactions(deserialized) + const deserialized = txs.map((tx: Buffer) => VersionedTransaction.deserialize(tx)) as VersionedTransaction[] // Disconnect so we can connect the helium ledger await heliumWallet.disconnect() @@ -286,9 +285,11 @@ export const LedgerMigration = () => { error: errorSolanaSign, loading: loadingSolanaSign, } = useAsyncCallback(async () => { - const [needSign, dontNeedSign] = partitionBy(heliumSignResult!, (tx) => - tx.signatures.some((sig) => sig.publicKey.equals(solanaPubkey!)), - ) + const [needSign, dontNeedSign] = partitionBy(heliumSignResult!, (tx) => { + const userKeyIndex = tx.message.staticAccountKeys.findIndex(k => k.equals(solanaPubkey!)) + const signingRequired = typeof userKeyIndex !== "undefined" && tx.message.isAccountSigner(userKeyIndex) + return signingRequired + }) await solanaWallet.connect() if (needSign.length > 0) { console.log(needSign) @@ -351,7 +352,7 @@ export const LedgerMigration = () => { component: ( {errorSolana && ( - +

{errorSolana.message}. Please make sure you are connected to the Solana Ledger App @@ -361,7 +362,7 @@ export const LedgerMigration = () => { )} Open the Solana App on your ledger. Be sure to{' '} - + enable blind signing {' '} in the Ledger Settings. Select the account number you would like to migrate. Then @@ -398,7 +399,7 @@ export const LedgerMigration = () => { component: ( {errorHelium && ( - +

{errorHelium.message}. Please make sure you are connected to the Helium-Solana @@ -429,7 +430,7 @@ export const LedgerMigration = () => { component: ( {errorSeed && ( - + {errorSeed.message} @@ -452,7 +453,7 @@ export const LedgerMigration = () => { component: ( {errorHeliumSign && ( - + {errorHeliumSign.message}. Please make sure you are connected to the Helium-Solana Ledger App and have blind signing enabled. @@ -476,7 +477,7 @@ export const LedgerMigration = () => { component: ( {errorSolanaSign && ( - + {errorSolanaSign.message}. Please make sure you are connected to the Solana Ledger App and have blind signing enabled. @@ -500,7 +501,7 @@ export const LedgerMigration = () => { component: ( {errorSendTransactions && ( - + {errorSendTransactions.message} diff --git a/src/theme/MigrateWallet.tsx b/src/theme/MigrateWallet.tsx index a814a1e58..01c1f24f2 100644 --- a/src/theme/MigrateWallet.tsx +++ b/src/theme/MigrateWallet.tsx @@ -56,7 +56,7 @@ export const MigrateWallet = () => { }) return ( -

+
{errorInflate && (