Author: andrewc

  • Sleep States

    When I first got my own computer, it was a refurbished Windows laptop built to last all of 4 years. It wasn’t particularity fast or well built, but it was mine. I wasn’t so well versed with technology back then, and kept most everything at stock settings. This led to some unusual issues – sometimes the laptop would simply decide to heat up, melt everything around it, and die. At the time, the best I could do was keep a charger with me.

    I had heard of a new thing called Linux, but my understanding was that it was for people who knew what they were doing – and I still needed to turn in my assignments as Word documents. But as time passed and I entered college, with the looming threat of needing use a CLI and understand g++ finally gave me the push to attempt to install Ubuntu.

    Ubuntu (even now) has a strange problem – sometimes it will decide to freeze, play the same half second of audio in a loop, and then die. There are no obvious errors, and all input devices become unresponsive. The laptop uses an AMD CPU, and any attempt to sleep crashes the device. As you might have guessed, these two errors are the same type of error – mishandling sleep states.

    Aside: This is easily fixed by going into GRUB adding this to the boot options (but it will prevent your laptop from sleeping):

    intel_idle.max_cstate=1

    My Pico W also has some of the same issues as attempts tell the chip to sleep without first disabling WIFI will leave it in a pseudo-sleep – drawing significantly higher power without the ability to control it. As far as my own understanding goes, the RP2040 make use of external module for WIFI – and the power to that module and the built-in LED is not controlled by the sleep state.

    Now, as I run into power management issues with my own micro controllers and the need to keep them online for a month+ at a time for remote sensor monitoring, low power sleep states are becoming an increasingly important aspect of computing that I’ve never thought about – mishandling them is disastrous, and using them safely is difficult, but if I do this correctly, I will no longer have gaps in my data.

    Now to get my own sleep states under control.

  • IoT Sensors with InfluxDB

    I’ve discovered rather that microprocessors are rather cheap these days, and development kits that originally went for 20$ – 50$ can now be had for less than 10$. An ESP32 averages 6$ and the Pico series is roughly in the same place. Why would I would even need such a thing? I have other, significantly more capable machines. But the benefits are not in the compute – they are built for embedded systems where size and energy are primary concerns.

    The question then becomes, what do I do with such a thing? What data could I even collect?

    After scrounging through some of the old electronic kits from my time in college, I’ve come up with an assortment of sensors – a thermistor, a photocell. Since I already have an easy way to measure resistance with the picozero.py library, all that is left is set up a connection to a database.

    Rather than trying to present data as a webpage and have Prometheus scrape it, I opted to push data to InfluxDB. Prometheus does not allow push metrics – which meant that I would have a harder time with data collection if my sensors did not update fast enough. Additionally, this method integrates well with my own alerting system.

    However, file-size restrictions prevent usage of the Influx Python library. The urequests library for Pico does implement HTTP POST methods, so all that is left is translating the curl command into a requests function, and then into a urequests function. There are minor differences, but for the sake of this project, they are negligible.

    View the code on GitHub.

    Notes:

    1. The Pico does not draw enough current to run off a battery bank. while my code does include indicator lights, they can be safely omitted if you have a ‘dumb’ battery pack or draw more than 15 mA.
    2. Micropython’s urequests does not have HTTPBasicAuth – but authentication can simply be included in the header, as long as you to encode it.
    3. InfluxDB is not ‘technically’ RESTful, and the newer standard takes line protocol formatted strings rather than json.
  • Check Your Backups!

    If you are reading this, check your backups right now. Is it a pain? Will it be a bigger pain if you lose all your data? Check your backups!

    (In a twist of delicious irony, Hello World #2 is also going to be about backups…)

    If you’re looking for a Hello World #1, it doesn’t exist any more – I was lamenting the downfall of social media and the need to have a personal website for self-expression, and started this website with the hope that I would no longer need to introduce myself as often. Perhaps in a twist of delicious irony, I am introducing myself again less than 24 hours after I first wrote about it.

    The Problem: When I started Ghost and initialized the MySQL database, I did not disable automatic updates from Watchtower, a container monitor, nor did I check to see that the volume that I mounted in Docker was the correct path. As the container was ran, data was saved and a directory was created and aliased to the container, but the data was not persisted across versions of MySQL. Consequently, this blog’s data was lost upon updating.

    The Fix: MySQL has been pinned to a stable version rather than the latest version, and the typo in the volume mount has been fixed. I modified the DB and then restarted it several times to make sure changes persisted.

    Moving Forward: Test the data – writing test data and then checking if the backup is updated to reflect the change would have been a quick and dirty way to see that I did not save any relevant data and would have alerted me to the fact.