ESPHome is a very interesting project. I’d not heard of it until this week and am surprised that it isn’t more newsworthy. I’m always tinkering with IoT stuff, have a couple of Wemos D1 ESP8266s. They are brought out occasionally for learning. I’ve been using them this week with ESPHome. I’m looking to buy some Xiaomi BLE temperature sensors and thinking I could read the temperatures from these using the ESPs (thanks to ESPHome) and publish the data to MQTT.

Recently, I wrote about some initial adventures with OriginStamp Using OriginStamp’s UI or API, submitting a hash results in transactions being submitted to Bitcoin, Ethereum and a German newspaper. Using the API, it’s possible to query OriginStamp’s service for a proof. This post explains how to verify such a proof. The diligent reader among you (Hey Mom!) will recall that I submitted a hash for the message: Frederik Jack is a bubbly Border Collie The SHA-256 hash of this message is:

I wrote recently about some exploration of Timestamping with OriginStamp. Since writing that post, I had some supportive feedback from the helpful folks at OriginStamp and plan to continue exploring that solution. Meanwhile, OriginStamp exposed me to timestamping and trusted timestamping and I discovered freeTSA.org. What’s the point? These services provide authoritative proof of the existence of a digital asset before some point in time; OriginStamp provides a richer service and uses multiple timestamp authorities including Bitcoin, Ethereum and rather interestingly a German Newspaper’s Trusted Timestamp.

A friend mentioned OriginStamp to me. NB There are 2 sites: originstamp.com and originstamp.org. It’s an interesting project. It’s a solution for providing auditable proof that you had a(ccess to) some digital thing before a certain date. OriginStamp provides user-|developer-friendly means to submit files|hashes (of your content) and have these bundled into transactions that are submitted to e.g. bitcoin. I won’t attempt to duplicate the narrative here, review OriginStamp’s site and some of its content.

Until today, I’d not accessed a Google Container Registry repo from a non-GKE Kubernetes deployment. It turns out that it’s pretty well-documented (link) but, here’s an end-end example. Assuming: BILLING=[[YOUR-BILLING]] PROJECT=[[YOUR-PROJECT]] SERVER="us.gcr.io" If not already: gcloud projects create {$PROJECT} gcloud beta billing projects link ${PROJECT} \ --billing-account=${BILLING} gcloud services enable containerregistry.googleapis.com \ --project=${PROJECT} Container Registry IMAGE="busybox" # Or ... docker pull ${IMAGE} docker tag \ ${IMAGE} \ ${SERVER}/${PROJECT}/${IMAGE} docker push ${SERVER}/${PROJECT}/${IMAGE} gcloud container images list-tags ${SERVER}/${PROJECT}/${IMAGE} Service Account Create a service account that’s permitted to download (read-only) images from this project’s registry

I think it would be valuable if Google were to provide volumes in Cloud Build of package registries (e.g. Go Modules; PyPi; Maven; NPM etc.). Google provides a mirror of a subset of Docker Hub. This confers several benefits: Google’s imprimatur; speed (latency); bandwidth; and convenience. The same benefits would apply to package registries. In the meantime, there’s a hacky way to gain some of the benefits of these when using Cloud Build.

The prolific Alex Ellis has a new project, Inlets. Here’s a quick tutorial using Google Compute Platform’s (GCP) Compute Engine (GCE). NB I’m using one of Google’s “Always free” f1-micro instances but you may still pay for network *gress and storage Assumptions I’m assuming you’ve a Google account, have used GCP and have a billing account established, i.e. the following returns at least one billing account: gcloud beta billing accounts list If you’ve only one billing account and it’s the one you wish to use, then you can:

The FBI Portland published an interesting advisory with several, sensible recommendations including firewalling IoT devices from other devices on a home network. I decided to deploy a redundant Trendnet TEW-812DRU version 2.0 for this purpose. Caveat Developer: Before I go further, I don’t recommend installing DD-WRT on a Trendnet TEW-812DRU unless you’re willing to brick the device irrecoverably. I read the DD-WRT instructions several times (“peacock thread”,router database – do not use v3.

I’ve spent a few days exploring [Google Fit SDK] as I try to wean myself from my obsession with metrics (of all forms). A quick Googling got me to Robert’s Exporter Google Fit Daily Steps, Weight and Distance to a Google Sheet. This works and is probably where I should have stopped… avoiding the rabbit hole that I’ve been down… I threw together a simple Golang implementation of the SDK using Google’s Golang API Client Library.

I’m obsessing over Prometheus exporters. First came Linode Exporter, then GCP Exporter and, on Sunday, I stumbled upon a reverse-engineered API for Google Home devices and so wrote a very basic Google Home SDK and a similarly basic Google Home Exporter: The SDK only implements /setup/eureka_info and then only some of the returned properties. There’s not a lot of metric-like data to use besides SignalLevel (signal_level) and NoiseLevel (noise_level). I’m not clear on the meaning of some of the properties.