lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

160
hpr_transcripts/hpr4311.txt Normal file
View File

@@ -0,0 +1,160 @@
Episode: 4311
Title: HPR4311: LoRaWAN and the Things Stack
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4311/hpr4311.mp3
Transcribed: 2025-10-25 22:49:01
---
This is Hacker Public Radio episode 4,311 from Monday the 10th of February 2025.
Today's show is entitled, Low-Raw-W-I-N and the Thingstack.
It is hosted by Lee, and is about 10 minutes long.
It carries a clean flag.
The summary is, Lee sets up some temperature and humidity sensors.
Hi there, I'm Lee, and I'm going to talk about the Internet of Things, specifically about
services provided by the Thingstack and devices that operate within the lower-around protocol.
So what I'm talking about is a relatively new set of wireless protocols in a class of
devices and networks that can be created with them.
Collectively there's a called low-power, wide-airing networks.
The key feature of these protocols is that devices can be numerous and consume little
power and communicate small amounts of data over long distances for an extended period
of time.
Well, Loro-Anne, which stands for long-range wide-airing network, is one such protocol.
Other low-power wide-airing network protocols include narrow-band Internet of Things, Sig
Fox, long-term evolution machine-type communication, and wireless smart utility network.
They all have advantages and disadvantages, and some are more suited for certain applications
than others.
Loro-Anne is relatively low-cost, and has the ability to transmit reliably over longer distances.
Compared to other protocols, the bandwidth is fairly constrained, and application is
good at, will be deploying a lot of sensors over a large area, taking periodic data readings
with very little maintenance required.
I got into this when I was asked to integrate the ability to collect data from water temperature
monitors attached to equipment into a platform provided by a company who are at the time
my client and an L at the time recording one of my employees.
The platform was primarily for businesses that provide safety compliance for water systems
in buildings.
While the Loro-Anne protocol is open and you could in theory run entirely using your
own equipment, that is, devices, gateways, and servers, it's in many cases more practical
to utilise a third party to manage the various aspects of the Loro-Anne setup.
These include Senate, Loria, and the one I'm going to talk about due to the relative
ease of setting up, which is the Things Stack.
Now the Things Stack is actually just one service provided by the Things Industries.
The service called the Things Network is suited more for enthusiasts, and those getting started
with Loro-Anne, while the Things Stack is tailored more for commercial users and offers
slightly more advanced features.
I found I may want to use it for free as long as I keep to 10 devices or less.
Even though I integrated the software I was working with to be able to operate on either
of these systems, as far as I know the company in question is still using the Things Network
integration rather than the Things Stack.
The Things Network has a few limitations such as a more limited service level agreement.
Now, just to outline the topology of a Loro-Anne network, you have end devices that send packets
of data over radio frequencies, then you have gateway devices that translate between this
radio data and the internet, and finally you have the internet-based servers that process
this data.
You could also consider that there is then also an application layer that talks to these
servers and does something useful with the data.
For enterprise applications with entire fleets of devices, providers like AWS, that Samsung
web services, can be used to manage the whole network and collect data at scale.
While Loro-Anne can be used as a bidirectional protocol, my experience of it is with sampling
data from sensors rather than sending commands to actual actions in the physical world.
The only time I've been sending data to these devices is to register them on the network
and then configure their operation, for example, how often they report back data.
As mentioned before bandwidth is limited, there are strict regulations on how much data can
be sent, and typically data is sent in small bursts because the devices to be constantly
chatting would both deplete the batteries and use up the limited capacity of the allocated
radio spectrum.
The things network and the things stack doing force these limits, and on some occasions
I found my devices simply stopped communicating for up to a day because they've exceeded the
allowed limits.
This would not happen normally but can happen typically when debugging a setup, for example
re-registering a device for repeatedly many times in a short space of time.
Now while I say gateways that are unnecessary part of the network, the things network actually
has a community-based network of gateways, so in theory if you just had some end devices
and wanting them to send data to the server, you could get away with using the community-based
gateways that might exist in your local area.
However, in practice I found this was extremely unreliable, would almost always recommend acquiring
your own gateway or gateways.
Now while I've said this technology is relatively cheap, if someone does want to set up a network
of sensors quickly and have things work pretty much out of the box, rather than doing
a lot of DIY, then the cost is likely to be in the order of a few hundred pounds dollars
or euros.
The gateway device I've been using at home is called the things indoor gateway, and compared
to other gateways I tried to set up, this connected and worked seamlessly with the things
stack with very little configuration required.
The sensors I've been using are Malsai EM-300s, which can take temperature and humidity
readings, and will typically transmit data once every ten minutes.
Inside these devices is room for an extra battery, and in principle such a device could run
unattended without needing to change batteries for several years.
So now I'll go through my setup on the things stack.
To start with, I can log into my console at myusename.eu1.cloud.thethings.industries for
one-slash console.eu1 is just one of the regions, and these regions are segmented so it's
important to pick one region and stick with it.
In my console I have one application called Lee-Hyphen-IoT.
I have one gateway, this is physically located at my parents' house.
The gateway has an extended unique identifier or EUI.
This is 8 bytes expressed as colon-separate pairs of digits.
Y1 starts, 5-8 colon, A-0 colon, etc, and ends colon-7-6.
This type of identifier is not just used for gateways.
End devices also have a similar identifier called the device identifier, and a similar identifier
is used in the registration process.
It's called either the app or the join EUI.
In the console I can browse through my list of devices.
I've labeled these with the letters of the alphabet from A to J, so look at sensor A.
There's a nice little photo of the type of device, and it says EM-300-IoT-H, Tempsh
and humidity sensor.
And as mentioned it has a dev-E-U-I, and an app-E-U-I, and an app-key, which is longer
than the others, and the digits are hidden since it acts as a secure credential that limits
access to the device.
This device is in the living room, and I've attached to it with keyring a letter A tile originally
from ScrabbleGame, so it can easily be identified.
You could always read the device EUI to identify device since it's unique, but this is printed
in very small writing on the thing, and not so human-friendly.
If I wanted to add another sensor, I'd just click register new device.
Then either scan a QR code if I was using a phone, or select the manufacturer model from
a list, and set any other parameters, like hardware and firmware version, radio, region
and frequency plan.
Typically I choose the default European profile and leave all these at their default or
recommended settings.
Then I enter the join EUI, also known as the app-E-U-I, and I enter the app-key, these
credentials supplied with the device.
Hopefully then the device should be able to register and you'll start receiving data.
Now while you can inspect data packets coming in via the console, it's much more use to
be able to send the data to some web-based integration or custom application, so you
can actually use it.
Just to mention the data coming in may be in binary, depending on the particular device,
being in binary helps save bandwidth, but it's pretty hard to then work with.
So if it is in binary, it's common to then configure a payload formatter in the Thingstack,
which is a JavaScript that converts the binary into some more human readable JSON, and typically
a suitable payload formatter will already exist for any common device on the market.
So process my data I've set up a web hook.
This means whenever data comes in an HTTP request will be sent to a server of my choice.
I have an 89 Python script running on my server, which is receiving these requests, then
putting the data into an SQL-like database.
Once in the database I can process it in any way I'll see fit.
My Python script is listening on the port I've specified.
When it receives a post request, it decodes the JSON, gets the device identifier, then maps
that to find out which room in the house it corresponds to, then adds a row to the
database containing just the name of the room, the timestamp of the message, and the temperature
in Celsius and the emitate as a percentage.
Just so I can visualise this data I have a cron job running that runs a PHP script,
which scans the SQL-like database and generates a graph.
To render the graph I'm using the JavaScript library chart.js.
I'll include a copy of the scripts and the screenshot of the graph in the show notes.
So anyway, this has been a bit of an overview of what is possible for LoroRan, and in particular
the things network or things stack, plus a practical example.
But there's a lot more to LoroRan in terms of how it actually works and different ways
of working with devices and data.
You can find out more about LoroRan from Loro-hiphantaliance.org.
This is also a fairly cheap book on Kindle called Mastering LoroRan by Sir Jato Sain.
And the things stack or things network can be found at thethingsindustries.com.
So that's all for today.
I hope you found this of interest.
Thanks for listening.
You have been listening to Hecker Public Radio.
At Hecker Public Radio does work.
Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording podcasts, click on our contribute link to find out how
easy it really is.
Hosting for HBR has been kindly provided by an honesthost.com, the Internet Archive
and R-Sync.net.
Unless otherwise stated, today's show is released under Creative Commons, Attribution,
4.0 International License.