HPR4320: Switching my Mastodon account

21 februari 2025 | min

HPR4319: Am Rande - on the edge

20 februari 2025 | min

HPR4318: What's up with the dates on the HPR future feed in AntennaPod?

19 februari 2025 | min

HPR4317: Recording an episode of HPR

18 februari 2025 | min

HPR4316: Is Scratch a real programming language?

17 februari 2025 | min

HPR4315: How I got into the wonderful world of hackery

14 februari 2025 | min

HPR4314: 24-25 New Years Eve show

13 februari 2025 | min

HPR4313: Why I made a 1-episode podcast about a war story

12 februari 2025 | min

This show has been flagged as Explicit by the host.

My setup for recording this podcast about podcasting.

I never was attached to history (I’m a shame with events, names, dates ), much less of history fictionalized, like historical romances. But I ended up working on a piece of it. The event passes between 1931 and 1945. It relates to WWII — it’s part of it.

So , I talk about producing an specific audiod rama, covering two points, that are at really three:

WHAT is the story: the chaos that came to me asking to come out; and
WHY I decided to present it (and HOW:) by a podcast of fiction with history.

In the end , I summarize that I got touched by the subject, it impacted me with disastrous images both in words and images. And I like audio, well-made audio content. In synthesis, the real story touched me and urged the crave of creating something from it, resulting in an audio drama. A minute of it translated on the end.

Full Shownotes

Why I made a 1-episode podcast about a war story

by Sem Luz em Saint Louis

A little citizen (that came from) outside the country, inside a prison. Not a common prison, though: it is Unit 731…’

“What is Unit 731? What are you bringing to Hacker Public Radio?” The impulse and reason for creating an audiodrama, dear listener. I will tell you What and Why:

- WHAT is the story: the chaos that came to me asking to come out; and

- WHY I decided to present it by a podcast of fiction with history

[WHAT]

First, the WHAT. In the wanderings of the World Wide Web, a notable event was revealed before my eyes, a war scene that was under dust for decades, but people, even participants of it in varied degrees, came to reveal the fact; so, today, we know it.

China and Japan engaged in war by the year 1931. More exactly, that is when Japan started colonizing China by the provinces of Manchuria, northeastern of the country.

The resistence started in 1937, with reaction by the Chinese troops. Japan was so much more powerful, though (and that’s why China took so long to decide fighting the Imperial Army of Japan). It took time, and without the best outcome, but it demanded courage, it showed force, and humanity, moral value. And this conflict is part of the second World War, that by one side had Japan, Italy and Germany (the German Reich), heading the Axis powers; who were fought against by the Allied powers, headed by the Soviet Union, Great Britain, France, United States and China.

Even with basically all the rest of the world against the Axis, the Japanese occupied the 3 provinces of Manchuria from 1932 until the end of the war, in September 2, 1945, making of it the main territorial base for development of weapons. The Encyclopedia Britannica explains us the following, quote:

On March 9, 1932, the Japanese created the puppet state of Manchukuo […] out of the three historical Manchurian provinces. The last Qing (Manchu) emperor, Puyi, was brought to Manchuria from his retirement in Tianjin and made “chief executive,” and later emperor, of the new state. The Manchukuo government, though nominally in Chinese hands, was in fact rigidly controlled and supervised by the Japanese, who proceeded to transform Manchuria into an industrial and military base for Japan’s expansion into Asia. The Japanese took over the direction, financing, and development of all the important Manchurian industries, with the fortunate result that by the end of World War II Manchuria was the most industrialized region in China. [Source: BRITANNICA. Manchuria. Last updated in January 31, 2025. Link: <https://www.britannica.com/place/Manchuria>. Acess in February 2025.]

Unquote.

Now, very briefly, we come to the Unit 731. It was a big Japanese construction first officially designated as a “Epidemic Prevention and Water Supply Department”. It was commanded by the tenant-general of the Army and microbiologist Shirō Ishii.

I wanted until now to say what is the theme before hopping to the motivation to do something about the knowledge. Let’s get to the WHY:

I came to know of the theme by chance, navigating the web and suddenly coming to a strange photo of human experiencing, the description of Unit 731. I searched more about it and was simply astonished to know it happened, and inflicted by the so-estimated Japan, a headquarter of technology and populated by reverent people. We are (that is, I am) often so biased, for the good or the bad.

That is, what the general public know about World War II, including me? The holocaust of the Jews. This is much, but more happened, and more can be known for our critical view of the World, the countries and its interests, and the rational thinking that might be better with this knowledge.

The Unit 731 was not the only one with deadly human experimentation, other facilities existed, but 731 came to be better known; first, it was hidden, but now, decades after the events, documents and confessions came to the ground and can’t be denied anymore. And in other sites, Shirō Ishii was already inflicting them probably since the fall of 1933, mainly Chinese people, but also Soviets, Mongolians and Koreans, men, women and children.

That’s basically it. The research I made (and the movie I saw, a fiction, based on it, horrendous) led me to dream about the theme, so I felt to throw it, what was developed and developing inside, in some manner. I like the voice, the radio, and it is accessible to do, not requiring many equipments etc., so my first choice was to tell it. How? At first, I hypothetized about proposing a script to some Brazilian podcast that tell stories. Soon I realized it could not fit so well in the lines of the ones I know. Some days after, the idea of a little fictionalized story, short story, came as a thing I like, and also with the advantages of: 1. being beautiful (men is made of stories, real or otherwise appropriated by the mind and senses); 2. being impactful (connection with characters); 3. being fast in the way I proposed it to be (one little episode). Not necessarily only this or in this order, but the idea was that.

One thing more, of course: as any interested in the subject can note, there is so many technical things produced about it, I wanted to do something that caught the emotions and interest of people, spreading the possibility of them knowing what, elsewhere, they wouldn’t come to see. I wanted to make it different in that sense, but as true to the facts as a little audio fiction can be. It’s History to our minds, for our own construction and of our world view. But, if not, if the listener just come for the art, it can be (I hope) an enjoying story after all. That was the WHY I decided to do something with the knowledge (in an expression, fire in my heart), and HOW it became a fiction podcast (to do something I like, and different about the subject, attractive).

That was my theme here for our moment in HPR! The motivation behind need to create. It was hard, I get moved easily with shocking scenes in words or images, but It catched me. Deciding how to “let go” and then producing it was not tranquil, also; the hands-on, the technical part, was as follows:

I have written some pages summarizing the events I have outlined here. Having the base, I came with a story in my mind and in two days or three I think I wrote it, in 3 and a half pages, the story that you’re going to listen. In a more silent night I went to my room, with my notebook and a USB condenser microphone, and recorded. Fast. The editing, cutting, compressing, normalizing, and choosing free sounds (all referenced in description) and fitting them in the story, took a long and time and patience, maybe 10 or more dedicated hours along days. I’m not very efficient, some of it was the necessary lack of hurry of art, but some was my slowness in getting to the technical part of what I wanted to do (this bit of information in this milisecond, move track 3 together with track 4 without affecting the sync of the other tracks and clips in the same track, cut the music at this point but with a gentle fade…). I used Audacity. I had a Reaper licence (I remember being a bit more efficient with it) but lost it after formatting without having the serial number anymore, so I went with my long-choice of the free and open source alternative.

That was my work for the audiodrama podcast in my language. Which, in between the days I have been preparing this presentation script for HPR, I have released. You may find it in the description, or searching in your podcast app for the name (in Portuguese): “O Departamento de Prevenção de Epidemias e Distribuição de Água”, under the author name “Sem Luz em Saint Louis”.

I don’t know if it will be released in English. However, I made a first minute of it, here and now, so you can enjoy having mind of what I was talking about. Thank you, be with 1 minute of the report of the survivor…

*

and

Bye!

[1 MINUTE OF THE AUDIODRAMA – EXCERPT ONLY]

The Epidemic Prevention and Water Supply Department

This account was found in the records of Parkinson Tribly (or Tribly), of Russian and Polish origins. He was recruited by Dr. Shirō Ishii for experiments at Unit 731: a legitimate opportunity to stay alive — which ultimately proved false for reasons he did not expect.

What we will hear now is his writing, unedited. Except that, for organization, we will name the three parts that he composed as follows: 1. Introduction; 2. Activities; 3. The Bargain. The author reflects and advances in his organization, but what he brings is:

INTRODUCTION

Thank God we know that, from the beginning, man has lived in war. It’s envy, a desire for power, a desire for money. It is never a good motivation, but purely selfishness. I arrived at the department a week ago and, although I have no desire to collaborate with what happens here, I know enough to realize that it is impossible to leave this place free.

When the Japanese invaded this region, Manchuria, in the long war against China, we did not expect the brutality that was witnessed. A few years ago, after the end of the Great War, several countries signed the Geneva Protocol. Although it only prohibits the use of chemical weapons, biological agents, asphyxiating, and related specificities, we believed it would mean more — that it would signify a general humanization of combat methods on land, sea, and air when there might be another Great War. I did not expect it to come in my lifetime nor to be captured to participate in it firsthand.

[END OF EXCERPT]

Thank you for your presence.

References:

The audiodrama podcast, in Brazilian Portuguese:

SEM LUZ EM SAINT LOUIS. O Departamento de Prevenção de Epidemias e Distribuição de Água. In your favorite podcast listener or at https://archive.org/details/731-podcast-audiodrama.

Credits of audios used, in order of appearance ( listenance ):

Ant.Survila / ccmixter – Nostalgic Reflections

MeijstroAudio / Freesounds – Dark Metal Rise 001

SamRam21 / Freesounds – KeysMouse

Sadiquecat / Freesounds – MBA desk with mouse

trimono / Freesounds – approving hm

[On the drama excerpt:]

Kulakovka / Pixabay – Lost in Dreams (abstract chill downtempo cinematic future beats).

Title of the beginning of the audiodrama preview (“The Epidemic Prevention and Water Supply Department”) made in https://luvvoice.com , Abeo (Male) voice.

BBC Sound Effects – Aircraft: Beaufighters - Take off (Bristol Beaufighter, World War II).

Rewob / ccmixter – Secret Sauce (Secret Mixter)

References:

BRITANNICA. Second Sino-Japanese War (1937–1945). Last updated in December 16, 2024. Link: <https://www.britannica.com/event/Second-Sino-Japanese-War>. Access in January 2025.

BRITANNICA. Manchuria. Last updated in January 31, 2025. Link: <https://www.britannica.com/place/Manchuria>. Access in February 2025.

LIANG, Jiashuo. A History of Japan’s Unit 731 and Implications for Modern Biological Warfare. Advances in Social Science, Education and Humanities Research , v. 673. Atlantis Press, 2022. [ A 5-pages article about Unit 731. If you were interested with the facts told, the text gives a synthesys of what happened between 1937 and 1945. ]

PBS. The Living Weapon : Shiro Ishii. Link: <https://www.pbs.org/wgbh/americanexperience/features/weapon-biography-shiro-ishii>. Access in January 2025.

RIDER, Dwight R. Japan’s Biological and Chemical Weapons Programs ; War Crimes and Atrocities – Who’s Who, What’s What, Where’s Where. 1928 – 1945. 3. ed. 2018. [ “In Process” version ]

Provide feedback on this episode.

HPR4312: What Is The Indie Archive?

11 februari 2025 | min

This show has been flagged as Clean by the host.

What Is The Indie Archive?

I'm Hairy Larry and you're listening to the Plain Text Programs podcast.

The Indie Archive is a archival solution for indie producers. Since most indie producers run on a shoestring budget it's important that the Indie Archive is inexpensive to install and run. It's especially important that monthly expenses are minimal because a reasonable expense most months will sometimes be more than an indie producer can afford during some months.

The first major constraint is cost. So I'll be talking about prices a lot in this podcast and get more technical in future podcasts about The Indie Archive.

Indie Archive is an archival system which is different than a backup system. If you don't have a backup system do that first. My backup system uses the same tools as Indie Archive, rsync and rsnapshot. My brother uses the online backup service Carbonite. There are many other options.

A good backup system runs automatically to back up everything frequently and preserve version history. It's also good to have backups offsite.

An archival system, like Indie Archive, keeps multiple redundant copies across several hard drives on several systems in multiple locations. An archival system also checks file integrity as protection against file corruption or user error.

When you have a project you really never want to lose, like a finished novel, a music album, a video, or any other major effort that involves significant work, that's when you need an archival system.

So The Indie Archive does not automatically backup your projects every day. That's what your backup system should do.

The Indie Archive is an archival system where the producer of the content decides what needs to be archived and when it needs to be archived and then manually moves a directory containing the files onto the Indie Archive carefully preserving the file's metadata during the transfer. Then these files are propagated over at least 7 hard drives on 4 different systems in three locations.

File integrity checks are run daily comparing the files and reporting discrepancies.

Two of the systems are kept in the studio where the content is produced. I call them the primary and secondary systems. They have a boot drive and two data drives each.

One of the systems is kept offsite at a nearby location. I call it the remote system. It also has a boot drive and two data drives. If you have a more distant location where you can put a second remotes system you can have remotenear and remotefar systems. Otherwise ...

The final system is somewhere in the cloud provided by a professional data storage provider. It has a single copy of the data and usually some additional data retention. The provider makes the backups of this data. This is the part that might involve a monthly bill. So, depending on the size of your file set, it could be free or it could cost so much a month. There are a lot of options for cloud storage providers.

But first I'm going to discuss the three systems, primary, secondary, and remote, and how they function.

As far as the hardware goes the systems are the same. Now, I"m a Linix guy and I do all my production work on Linux so I'm using Linux. I want to test the system on several versions of Linux and with BSD.

I'm not a Mac guy or a Windows guy so I won't be going there. The software is open source and the required programs run on all three platforms so I'll let a Mac or Windows programmer test The Indie Archive for their systems. My guess is that the Mac fork will be easier than the Windows fork because of the file metadata. It might even be possible to add Mac folders to The Indie Archive running Linux but I'll let someone who actually has a Mac figure that out.

I don't think the same is true for Windows. Windows file metadata is different and so if you want to preserve the metadata you will probably have to install The Indie Archive on Windows systems.

So, I'm developing and deploying on Linux and I will also test on BSD. So far I have tested Debian, Ununtu, FreeBSD, Midnight BSD, and Xubuntu and The Indie Archive works fine all of these operating systems.

So, back to the hardware. Pretty much any older system that will support at least three sata drives will work. I'm using older business class desktops, Dell and HP. I pulled mine out of storage but they are very inexpensive to buy if you're not like me with a shed full of old computer stuff. I just bought a Small Form Factor HP Desktop on ebay for $30 including tax and shipping.

To clarify, it's best if the primary system supports 4 sata drives. The secondary and remote systems do not need an optical drive so they should support three sata drives but they can be run on two sata drives if you boot from the primaryfile drive. I am currently testing a remote system with two sata drives running Midnight BSD.

The Dell desktops made a big deal about being green. I am open to suggestions on what would be the best energy efficient systems for The Indie Archive, because of both the cost of electricity and the impact on the environment.

There are three drives on each system, a boot drive and two data drives. The boot drives can be SSD or spinning hard drives and need to be big enough to hold the OS comfortably. The data drives need to be large enough to hold the files you want to archive and they should be high quality spinning drives, I use the multi terrabyte HGST drives and I am also looking at some Dell drives made by HGST.

There will be a data drive and a snapshot drive on each system. If they are not the same size the snapshot drives should be larger. I am testing with 3 terrabyte data drives and 4 terrabyte snapshot drives. Besides the main data set that is being archived the snapshot drives also hold the version history of files that have been deleted or changed. So, that's why they should be the larger drive.

So my primary system has a primaryfiles directory with a 3 terrabyte drive mounted to it and a primarysnapshots directory with a 4 terrabyte drive mounted to it. Same for the secondary and remote systems.

Now, so far I only had to buy one drive but generally speaking the six data drives will be the major expense in assembling the systems.

So a good bargain on six 4 terrabyte drives could be $120 used or $270 new. And this is the most expensive part.

I install used HGST drives all the time and rarely have problems with them. I have worked for clients who won't buy used, only new. Since the file integrity checks should give early warning on a drive failure and since there is a seven drive redundancy on the data files, if I were buying drives for The Indie Archive I'd go with six used 4 terrabyte HGST drives for $120.

There is no reason not to use drives all the same size as long as the snapshot drives are large enough. The size of data drives you need depends on the size of your projects and the time it takes to do a project. Look at your hard drives on your working systems. Think about what directories you would like to see in archival storage. What is the total size of these directories? Check how many gigabytes these projects have consumed in the last year. Think forward a few years. Assume you will use more disc space in the future than you are now. Do some quick arithmetic and make a decision.

Like I said I only had to buy one drive so far because I'm weird and I had a bunch of 3 terrabyte drives available. If I had to buy drives I probably would have tried to start larger. I am sure that at some point in the not to distant future, when I am running The Indie Archive and not developing it, I will have to upgrade my drives.

The primary system is the console for The Indie Archive. When you copy a project onto The Indie Archive the directory goes into the primaryfiles directory. From there it is propagated out to the primarysnapshots directory, the secondary system, the cloud storage (if you are using it), and eventually to the remote systems.

All of the data propagation is done with rsync using the archive setting that is desigend to preserve the file metadata like owner, permissions, and date last modified. So I have been using rsync with the archive setting to move the files from the work system to a usb drive and from the usb drive to the primaryfiles folder.

At first I thought I would use an optical disc to move the files but optical discs do not preserve file metadata. Also I had some weird results with a usb flash drive because it was formatted fat32. fat32 does not support Linux metadata so if you're going to move projects over on a flash drive or a usb external drive be sure to format to ext4.

Another way to move projects over to the primaryfiles directory is with tar compression. This preserves metadata when the files are extracted so this might be easier and it works with optical drives. If your directory will fit on an optical drive this also gives you another backup on another media. If you have any suggestions on how to transfer projects while preserving the file metadata let me know.

I know that there are network options available but I am hesitant to recommend them because if I can transfer files from a system to the primary sytem over the LAN than anyone can do the same. Or delete files. Or accidentally delete directories. I kind of want to keep tight control over access to the primary system. It kind of ruins the archival quality of The Indie Archive if anyone on the LAN can accidentally mess with it.

So, I am open to dialogue on these issues. I'm kind of where I want it to be easy to add projects to The Indie Archive but not too easy, if you know what I mean. I feel like having to sit down at the primary system and enter a password should be the minimum amount of security required to access the primary system.

The primary system also runs file integrity checks daily from a cron job. All of the propagation and file integrity scripts have to be run as root to preserve the metadata since only root can write a file that it doesn't own.

The secondary system is the ssh server for The Indie Archive. The primary system logs onto the secondary system as root using ssh. Security is managed with public and private keys so entering a password is not required. After the keys are set up for both the primary and remote systems, password authentication is disabled for the ssh server so only those two systems can ssh into the secondary system.

When the propagation script is run on the primary system rsnapshot is used to create a current version of the primaryfiles directory in the primarysnapshots directory.

Then the primary system uses rsync over ssh to make a copy of the primaryfiles directory to the secondaryfiles directory.

Then the primary system logs onto the secondary system as root and rsnapshot is used to create a current version of the secondaryfiles directory on the secondarysnapshots directory.

Finally, if cloud storage is being used, the primary system uses gcloud rsync to make a copy of the primaryfiles directory to a google cloud storage bucket archive. I have this bucket set to 90 days soft delete. If you are using another type of cloud storage on Google, AWS, Mega, or other storage providers this command will have to be adjusted.

The reason I chose the gcloud archive bucket is because of the storage cost per gigabyte. They have the cheapest cost per gigabyte that I found. This will keep the monthly bill low.

Once a day the primary system runs the file integrity check from a cron job using rsync to compare the primaryfiles directory to the current version, alpha.0, in the primarysnapshots directory logging any discrepancies. It then does the same comparing primaryfiles to secondaryfiles and to the current version in the secondarysnapshots directory, logging discrepancies and notifying the maintainer of any discrepancies. Notification is done by email using curl and an SMTP provider.

The remote system runs on it's own schedule, logging into the secondary system daily to copy data from secondaryfiles to remotefiles and then using rsnapshot to make a copy of remotefiles to the remotesnapshots directory.

Since it's run on a daily schedule it uses rsnapshot with the standard daily, weekly, monthly, and yearly backups.

The remote system also runs a daily file integrity check comparing remotefiles to the current version on remotesnapshots and comparing remotefiles to both data directories on the secondary system, again logging the results and notifying the maintainer of any discrepancies.

If there is an outward facing static IP at the location with the primary and secondary systems then the remote system can use that static IP to ssh into the secondary system. If there is not a static IP then the remote system uses a DuckDNS subdomain to log onto the secondary system. Any system using the same router as the secondary system can run a cron job to update DuckDNS with the current IP address.

Since a static IP is a monthly expense it's important that there's an alternative that does not require paying another bill.

So the secondary system has the ssh server but it doesn't really do much. Both of the other systems connect to it and use it as the junction for data propagation and file integrity checks.

So, as you can tell, there's a lot going on to make The Indie Archive work. Future podcasts will get down into the details and discuss some of the choices I had to make and why I made them.

The funny thing about this project is that the actual code was the least amount of work. Figuring out exactly how rsync and rsnapshot work together was quite a bit of work. Configuration for both rsnapshot and ssh took a bit of head scratching. Then there were a few user id tricks I had to work through to make The Indie Archive usable. But, by far the most work was writing The Indie Archive installation document detailing each step of installing the software on three systems.

It's been fun so far. If you have input I always appreciate the help. I get quite a bit of help on Mastodon. If you go to home.gamerplus.org you will find the script for this podcast with the Mastodon comment thread embedded in the post.

This podcast is being read from a document that is a work in progress. Current versions of the What Is The Indie Archive document will be posted at codeberg when I'm ready to upload the project.

Thanks for listening.

https://www.theindiearchive.com/

Provide feedback on this episode.

HPR4311: LoRaWAN and the Things Stack

10 februari 2025 | min

This show has been flagged as Clean by the host.

I have set up some LoRaWAN temperature and humidity sensors, and am using the Things Stack to collect the data.

This gets processed via a web-hook and rendered as a graph.

The LoRaWAN Alliance - https://lora-alliance.org

Mastering LoRaWAN - https://www.amazon.com/Mastering-LoRaWAN-Comprehensive-Communication-Connectivity-ebook/dp/B0CTRH6MV6

The Things Industries - https://thethingsindustries.com

server.py

import json
import sqlite3
import logging
from http.server import BaseHTTPRequestHandler, HTTPServer

rooms = {
    'eui-24e12*********07': 'living-room',
    'eui-24e12*********54': 'hall',
    'eui-24e12*********42': 'downstairs-office',
    'eui-24e12*********35': 'kitchen',
    'eui-24e12*********29': 'conservatory',
    'eui-24e12*********87': 'landing',
    'eui-24e12*********45': 'main-bedroom',
    'eui-24e12*********89': 'upstairs-office',
    'eui-24e12*********38': 'spare-bedroom',
    'eui-24e12*********37': 'playroom'
};

# Configure logging
logging.basicConfig(filename="server_log.txt", level=logging.INFO, format="%(asctime)s - %(message)s")

# Define the web server handler
class MyServerHandler(BaseHTTPRequestHandler):

    # Handle POST requests
    def do_POST(self):
        length = int(self.headers.get('Content-Length'))
        data = self.rfile.read(length).decode('utf-8')

        try:
            # Validate and parse JSON data
            json_data = json.loads(data)
            logging.info(f"Received valid JSON data: {json_data}")

            # Write the data to database
            id = json_data["end_device_ids"]["device_id"]
            room = rooms.get(id)
            readat = json_data["uplink_message"]["rx_metadata"][0]["time"]
            temp = json_data["uplink_message"]["decoded_payload"]["temperature"]
            hum = json_data["uplink_message"]["decoded_payload"]["humidity"]
            conn = sqlite3.connect('data.db')
            sql = """CREATE TABLE IF NOT EXISTS data (
                id INTEGER PRIMARY KEY AUTOINCREMENT,
                room TEXT,
                readat DATETIME,
                temp DECIMAL(4,1),
                hum DECIMAL(4,1)
            );"""
            conn.execute(sql)
            sql = "INSERT INTO data (room, readat, temp, hum) VALUES (?, ?, ?, ?)"
            conn.execute(sql, (room, readat, temp, hum))
            conn.commit()
            conn.close()

            self.send_response(200)
            self.send_header("Content-type", "text/html")
            self.end_headers()
            self.wfile.write(bytes("Data received and logged!", "utf-8"))

        except json.JSONDecodeError:
            logging.error("Invalid JSON data received.")
            self.send_response(400)  # Bad Request
            self.send_header("Content-type", "text/html")
            self.end_headers()
            self.wfile.write(bytes("Invalid JSON format.", "utf-8"))

        except PermissionError:
            logging.error("File write permission denied.")
            self.send_response(500)  # Internal Server Error
            self.send_header("Content-type", "text/html")
            self.end_headers()
            self.wfile.write(bytes("Server error: Unable to write data to file.", "utf-8"))

# Start the server
server_address = ('0.0.0.0', 12345)  # Customize host and port if needed
httpd = HTTPServer(server_address, MyServerHandler)
print("Server started on http://localhost:12345")
httpd.serve_forever()

process.php

<!DOCTYPE html>
<html>
<head>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
</head>
<body>
<canvas id="temp" style="height:50vh"></canvas>
<canvas id="hum" style="height:50vh"></canvas>
<script>
<?php

    $colors = [
        '#FF9999',  // Light red
        '#FFCC99',  // Light orange
        '#FFFF99',  // Light yellow
        '#CCFF99',  // Light lime green
        '#99FF99',  // Light green
        '#99FFCC',  // Light teal
        '#99FFFF',  // Light sky blue
        '#99CCFF',  // Light blue
        '#9999FF',  // Light violet
        '#CC99FF',  // Light lavender
        '#FF99FF',  // Light pink
        '#FFCCFF', // Light rose
        '#FFD5D5',  // Light salmon
        '#FFDDAA',  // Light peach
        '#FFE0E0',  // Light beige
        '#FFF0F0' // Light ivory
    ];

    $results = [
        'living-room' => [
            'temperature' => [],
            'humidity' => []
        ],
        'hall' => [
            'temperature' => [],
            'humidity' => []
        ],
        'downstairs-office' => [
            'temperature' => [],
            'humidity' => []
        ],
        'kitchen' => [
            'temperature' => [],
            'humidity' => []
        ],
        'conservatory' => [
            'temperature' => [],
            'humidity' => []
        ],
        'landing' => [
            'temperature' => [],
            'humidity' => []
        ],
        'main-bedroom' => [
            'temperature' => [],
            'humidity' => []
        ],
        'upstairs-office' => [
            'temperature' => [],
            'humidity' => []
        ],
        'spare-bedroom' => [
            'temperature' => [],
            'humidity' => []
        ],
        'playroom' => [
            'temperature' => [],
            'humidity' => []
        ]
    ];

    $labels = [];

    $db = new SQLite3('data.db');
        $sql = "SELECT room, readat, temp, hum FROM data";
        $stmt = $db->prepare($sql);
        $result = $stmt->execute();

        while ($row = $result->fetchArray(SQLITE3_ASSOC)) {
                $where = $row['room'];

                                $tz = 'Europe/London';
                                $dt = new DateTime($row['readat']);
                                $dt->setTimezone(new DateTimeZone($tz));
                                $when = $dt->format('d/m/Y, H:i');

                $u = intdiv(date_format(date_create($row['readat']), "U"), 600);
                $temp = number_format($row['temp'], 1);
                $hum = number_format($row['hum'], 1);

        $labels[$u] = "\"$when\"";

                $results[$where]['temperature'][] = $temp;
                $results[$where]['humidity'][] = $hum;
        }

        $stmt->close();
        $db->close();

    $c = 0;
    foreach ($results as $key => $room) {
        $col = $colors[$c];
        $temp_datasets[] = "{ label: \"$key °C\",  data: [ ".implode(",", $room['temperature'])." ], borderColor: \"$col\" }";
        $hum_datasets[] = "{ label: \"$key %\", data: [ ".implode(",", $room['humidity'])." ], borderColor: \"$col\" }";
        $c++;
    }

?>
const data1 = { datasets: [ <?php echo implode(",",$temp_datasets); ?> ], labels: [<?php echo implode(",", $labels); ?>] };
const ctx1 = document.getElementById("temp").getContext("2d");
const options1 = {
  type: "line",
  data: data1,
  options: {
    elements: {
      point:{
        radius: 0
      }
    }
  }
};
const chart1 = new Chart(ctx1, options1);

const data2 = { datasets: [ <?php echo implode(",",$hum_datasets); ?> ], labels: [<?php echo implode(",", $labels); ?>] };
const ctx2 = document.getElementById("hum").getContext("2d");
const options2 = {
  type: "line",
  data: data2,
  options: {
    elements: {
      point:{
        radius: 0
      }
    }
  }
};
const chart2 = new Chart(ctx2, options2);
</script>
</body>
</html>

Temperature Chart

Graph showing temp over time in
various rooms

Humidity Chart

Graph showing humidity over time in
various rooms

Provide feedback on this episode.

Hacker Public Radio

Hacker Public Radio is an podcast that releases shows every weekday Monday through Friday.

Om podden

Avsnitt

HPR4320: Switching my Mastodon account

Links:

HPR4319: Am Rande - on the edge

HPR4318: What's up with the dates on the HPR future feed in AntennaPod?

HPR4317: Recording an episode of HPR

HPR4316: Is Scratch a real programming language?

What is Scratch?

What are the blocks and how they relate to coding?

Why is this good?

My own experience

The workshop

HPR4315: How I got into the wonderful world of hackery

HPR4314: 24-25 New Years Eve show

HPR4313: Why I made a 1-episode podcast about a war story

Full Shownotes

[WHAT]

[1 MINUTE OF THE AUDIODRAMA – EXCERPT ONLY]

References:

HPR4312: What Is The Indie Archive?

HPR4311: LoRaWAN and the Things Stack

server.py

process.php

Temperature Chart

Humidity Chart