Place and Space is themed around our recent jointly authored book ‘Cities in the Metaverse: Spatial Computing, Digital Twins, Avatars, Economics and Digital Habitation on the New Frontier’ and consists of 10 tracks:

Digital Habitation

The New Frontier

Simulate

Invisible

Play the Game of Life

Mirror Worlds

Fork the Branch

Convariance Matrix

Let me See (in Augmented Reality)

We hope you enjoy it, over the coming weeks will have a ‘making of post’…

Andy

The post The Album: Place and Space appeared first on Digital Urban.

Linear Stepper Motor Gauge

a full 1 metre range for the data visualisation. It uses a stepper motor for precise needle movement, and a limit switch for calibration, it can be adapted to any MQTT data feed and any base mount. The example shown uses a 5cm by 10cm peice of wood, cut to 1 metre length and indicates wind speed from 0 to 60 mph.

The design uses a stepper motor (like the 28BYJ-48) which offers high-precision, 360-degree movement without the jitter or limited range of a standard servo. The limit switch allows the gauge to “home” itself on startup, ensuring the pointer always starts at a known zero position.

The main code – WindStepperTimerBeltwithLimitSwitch.ino in the Github has a distance calibration number, adjust for your range.

Hardware Components

• Arduino-compatible Board: Any board like an Arduino Uno, Nano, or a NodeMCU.
• Stepper Motor: 28BYJ-48 5V stepper motor.
• Stepper Driver: ULN2003 driver board (which often comes with the 28BYJ-48).
• Limit Switch: A small microswitch to detect the pointers zero position.
• Power Supply: USB.
• Timer Belt GT2 Timer Belt

It is made to be as simple to build/power as possible but also adatable for a number of senarios.

The github provides the mount for the stepper motor, the pointer (which also joins together the timing belt) the limit switch and the end mount for the pulley. These allow the gauge to be adapted to any size required.

At the moment the gauge is sitting on the wall in our lounge and it has become one of our most used guages. The data updates every minute to show the maximum wind gust and due to the nature of the stepper motor, it provides a smooth movement, almost replicating the gust of wind.

The post Stepper Motor Linear Data Gauge appeared first on Digital Urban.

The light simulates an oil lamp by staying “steady” for a random period and then “flickering” for a short time by rapidly dimming and brightening – the flicker speed changes acording to the wind speed. The full code and details are available on Github as part of the ever growing Open Gauges Project.

Ships Lamp

Features

• Real-time Data: Connects to an MQTT broker to subscribe to a wind speed topic.
• Weather Map Gradient: Displays wind speed using an intuitive “weather map” color gradient:
  • 0 mph: Off (Black)
  • 1-10 mph: Solid Green
  • 10-20 mph: Fades from Green → Yellow
  • 20-30 mph: Fades from Yellow → Orange
  • 30-40 mph: Fades from Orange → Red
  • 40+ mph: Solid Red
• Realistic Flicker Effect: The light doesn’t just stay solid; it cycles between a “steady” phase (10-60s) and a “flicker” phase (5-15s) to simulate a real lamp.
• Asynchronous & Resilient: Built using uasyncio and mqtt_as. The mqtt_as library automatically handles and recovers from WiFi or MQTT broker disconnections, re-subscribing to topics as needed.
• Hardware Watchdog: Uses the Pico’s built-in machine.WDT (Watchdog Timer) to automatically reboot the device only if the main code loop freezes, ensuring high reliability. (This replaces the old 60-minute timer).
• Status LEDs: Provides a heartbeat flash on one LED and a WiFi status indicator on another.

Hardware Requirements

• Raspberry Pi Pico W: (or any Pico with a WiFi-capable board).
• NeoPixel LED Strip: The code is configured for a strip, but can be any WS812B/NeoPixel compatible LEDs.
• Power Supply: A sufficient power supply for your LED strip (a strip of 60 LEDs can draw several amps at full brightness).
• A Ships Lamp (old or new).

Default Pinout (Pico W)

• NeoPixel Data: GP15
• Blue LED (Heartbeat): blue_led (defined in config.py, often the onboard LED).
• WiFi LED: wifi_led (defined in config.py).

Software & Dependencies

This project relies on a few key MicroPython libraries that you must have on your Pico:

1. neopixel.py: The standard Adafruit NeoPixel library for MicroPython.
2. mqtt_as.py: A robust, asynchronous MQTT client. You can find it here.
3. config.py: A file you must create to hold your credentials and pin definitions.

Configuration

You must create a config.py file in the root of your Pico’s filesystem. This file should contain:

1. Your WiFi and MQTT broker credentials.
2. Definitions for your wifi_led and blue_led.

The mqtt_as library expects the config.py to contain a config dictionary.

Example config.py:

# config.py
from machine import Pin

# --- WiFi Configuration ---
config['wifi_led'] = Pin("WL_GPIO0", Pin.OUT) # Onboard LED on Pico W
config['ssid'] = 'YOUR_WIFI_SSID'
config['wifi_pw'] = 'YOUR_WWIFI_PASSWORD'

# --- MQTT Configuration ---
# This example is for the open broker mqtt.cetools.org
config['server'] = 'mqtt.cetools.org'
config['port'] = 1884
config['client_id'] = 'pico_ships_lamp' # Or any unique ID

# --- Optional: For Secured Brokers ---
# If your broker requires a username and password, add these lines:
# config['user'] = 'YOUR_MQTT_USER'
# config['password'] = 'YOUR_MQTT_PASSWORD'

# --- Other Hardware ---
# This is for the heartbeat LED
blue_led = Pin(10, Pin.OUT) # Example: an external LED on GP10

Running the Project

1. Upload main.py, neopixel.py, mqtt_as.py, and your config.py to your Raspberry Pi Pico.
2. Reset the device.
3. The device will automatically connect to your WiFi and MQTT broker.
4. It will subscribe to the topic personal/ucfnaps/downhamweather/windSpeed_mph.
5. As messages are published to that topic, the ship’s lamp will spring to life!

Customizing

• LED Count: Change the numpix variable at the top of main.py to match your strip.
• Data Pin: Change the 15 in pixels = Neopixel(numpix, 0, 15, "GRB") to match your data pin.
• MQTT Topic: Change the a topic name in the conn_han function to subscribe to your own data source.

The post Ships Lamp Wind Speed Gauge appeared first on Digital Urban.

The post Will AI Push the Human Planner to the Point of Irrelevance? appeared first on Digital Urban.

It’s an exciting time to be a Pebble fan. After years of being kept alive by the dedicated Rebble community, the Pebble is officially back. The new Pebble 2 Duo watches (the black-and-white model) are officially shipping to the first backers, with the high-resolution color Pebble Time 2 set to follow.

So, I decided to make one myself.

 

Introducing ‘Just Weather’

I wanted a face that was clean, digital, and gave me all the key data at a glance, formatted to look great on the 144×168 screen of the Pebble 2. I call it “Just Weather.”

It uses the free Open-Meteo API to pull in a ton of useful, hyperlocal data right to your wrist:

 

• • Current Location (from your phone’s GPS)
  • Temperature
  • Current Conditions (“Partly Cloudy,” “Rain,” etc.)
  • Barometric Pressure & 3-Hour Trend
  • Wind Speed & Precipitation
  • …and of course, the time!

 

 

Built with GitHub CoPiliot

The best part is that the new Pebble development workflow is incredibly modern. I was able to build this using the CloudPebble IDE, which now integrates directly with VS Code in the browser.

This meant I could use the emerging tools like GitHub Copilot to help generate the code and work through the trickiest parts—like making direct HTTPS requests to the weather API, which (after a lot of testing!) we proved is possible from the phone app.

After getting the data, the final step was tweaking the C code to make sure the layout wasn’t clipped and all the information fit perfectly on the 144×168 screen. It’s now compatible with watches in the Pebble family, from the original Pebble Time (color) to the new Pebble 2 Duo and the upcoming Pebble Time 2.

 

 

Available Now

This project took around 6 hours, with the main issue being that Co-Pilot did not know how to get HTTP requests – it took me down a lot of rabbit holes, and in the end, it was down to using a simpler call on the data – XMLHttpRequest. Once this worked it all fell into place and it was simply a case of asking Copilot to add in the data fields, do the geocoding and then take a step back and explain how the code actually works.

If you’re like me and just want a simple, data-rich weather face, please give it a try…

 

• • Download ‘Just Weather‘ from the Rebble Appstore
  • Check out the source code on GitHub for the latest updates – now includes its own settings page (its become a proper watch face app)…

 

 

The post Just Weather for The Pebble Watch: Making a Data Watch Face appeared first on Digital Urban.

The book examines:

·         The size and shape of cities in the Metaverse

·         Spatial computing and its impact on digital interaction

·         Digital twins in urban planning and management

·         Avatars and social dynamics in virtual spaces

·         Economic models emerging in the Metaverse

·         The influence of gaming on immersive digital landscapes

·         The impact of Artificial Intelligence on the Metaverse

·         Potential futures of digital habitation

Drawing from architecture, computer science, urban planning, geography, social studies, and economics, the authors provide a multidisciplinary analysis of how virtual cities are shaping our digital future. Using key case studies, they trace the evolution from early cyberspace concepts to current spatial computing technologies, offering insights into both historical context and future possibilities. The book addresses key questions about the opportunities and challenges presented by metaverse technologies, including issues of accessibility, creativity, and the future of humans and artificial intelligence co-existing, side by side, in digital spaces. It serves as a practical guide, equipping readers with the knowledge they need to navigate the future of urban life in virtual environments with a thought-provoking examination of how we might build, inhabit, and govern cities in the Metaverse.

The authors explore the concept of digital twins, demonstrating how these virtual replicas of physical spaces can revolutionise urban planning and management. They delve into the social aspects of the metaverse, examining how avatars shape our interactions and relationships in digital realms. Economic considerations are central to the book ethos, with an analysis of emerging models that often leverage blockchain technologies. The book addresses the challenges, potential pitfalls and ethical considerations in creating and inhabiting digital cities. At the same time, it takes a step back and examines already abandoned digital worlds, offering lessons from past attempts at creating virtual spaces. 

Essential reading for urban planners, geographers, economists, technologists, policymakers, and anyone interested in the future of cities and digital interaction, Cities in the Metaverse provides a balanced, informed perspective on this rapidly evolving field.

Authors:

Andrew Hudson-Smith is a Professor of Digital Urban Systems at the Centre for Advanced Spatial Analysis (CASA), University College London. He focuses on real-time data, virtual environments and the Internet of Things within the urban environment. He is also an elected Fellow of the Royal Society of Arts, A Fellow of the Academy of Social Sciences and a Fellow of the Royal Geographic Society. Socials: @digitalurban

Duncan Wilson is a Professor of Connected Environments at the Centre for Advanced Spatial Analysis (CASA), University College London. His research focuses on how emerging technologies, such as connected sensors and cognitive computing, can augment our understanding of the built and natural environment. He has over 25 years of experience in industry and is a Fellow of the Royal Society of Arts. Socials: @djdunc

Valerio Signorelli is a Lecturer in Connected Environments at the Bartlett Centre for Advanced Spatial Analysis (CASA), University College London. He holds an MSc in Architecture and Urban Design and a PhD in Territorial Design and Government from the Department of Architecture and Urban Studies at the Politecnico di Milano (Italy). He is also a Fellow of the Royal Society of Arts. Socials: @ValeSignorelli

The post Cities in the Metaverse: Spatial Computing, Digital Twins, Avatars, Economics and Digital Habitation on the New Frontier appeared first on Digital Urban.

Over the years, I have followed various clock makers online, looking at their designs, 3D printed models, and generally spending more time than I would like to admit trying to get a 3D printed clock running. Makers such as the excellent Brian Law (Wooden and 3D printed), Steve’s Clocks (great insights and designs), JBV (amazing, complex engineering) and Wooden Gear Clocks (a lovely site for premade clocks which come in kits but still need more skills then it turns out i have in basic cutting/sanding of brass rods) have all inspired me, but have also driven my need for a simpler, open source design which would be free and easier to build.

It has taken a year to perfect, mainly as a summer project last year (in between work) and refining it this year to reach a point where other people could make it.

All 3D printed clocks are however never completely ‘easy’ to build, they all need a few extra parts, mainly in the need to reduce friction with metal rods, bearings, but we have limited the parts to the minimum, made sure they are all off shelf parts and have also reduced the need for any sanding/cutting/ beyond one small part. We have also provided all the files available on Printables, and incoming to Github, allowing others to refine and contribute new designs or updates. As time goes along, the clock will evolve – but for now it’s ready for its first release, and it’s called TIME.

We have tried and mainly failed with other designs online; as such, we wanted to build our own version, from first principles, not modifying others, but from the ground up, with the following aims:

1. It should be as easy to build and replicate as possible

2. Any additional parts should be easy to source and low-cost

3. Cutting/Sanding should be limited

4. It should have a proper 1-second tick/tock sound – this was important.

As such, the first thing to learn was how an Escapement Mechanism worked, how it contributes to the timing of a clock, the importance of the length of the pendulum and how it dictates the sound of the clock.

First Steps: The Escapement

While most people listen to music on their headphones on the way to work, last summer, I started listening to ChatGPT’s newly introduced voice mode to talk me through the history and detailed workings of a clock escapement mechanism. It allowed me to gain enough knowledge to start drawing my own deadbeat escapement.

A clock’s escapement is the heart of its mechanism, ingeniously translating the constant power from the gear train into the precise, rhythmic pulses that create the “tick-tock.” It performs two critical jobs: it allows the gears to “escape” forward one tooth at a time, regulating the speed of the hands, and it gives the pendulum a tiny push on each swing to overcome friction and keep it moving. The deadbeat escapement, perfected by George Graham around 1715, was a major leap in accuracy. Unlike earlier “recoil” escapements, where the escape wheel would kick backwards slightly after each tick, the deadbeat’s pallets are shaped so the teeth land “dead” with no recoil. This crucial improvement prevents the escapement from disturbing the pendulum’s natural, isochronous swing, making the clock significantly more accurate and establishing the design as the standard for precision regulator clocks. My 3D tool of choice to design mechanisms/enclosures for devices is Autodesk 360, as such, all I needed was a reference drawing and the thought that getting a working escapement would be a good first step. Over at Abbey Clock there is an excellent guide on Drawing Graham Pallets – which led to our own slightly modified design and, as pictured below, our first working escapement:

We haven’t published our prototypes yet, but I can share them if people are interested in either the escapement above or the next stage – the Pomodoro Timer, below. The escapement mechanisim is powered by a weight and counterweight sytem with a 1 metre pendulum – this provided a way to perfect the initial ‘tick tock’ of the clock, designed to provide a steady beat every 0.5 seconds, allowing the escapment to move forward, once every seconds and more importantly, make a full rotation once a minute.

Gear Ratios: The Pomodoro Timer

The second step was to add an additional gear and gain an understanding of gear ratios. Gear ratios for a clock are all-important as they not only define the number of gears you need, but also define the relationship between them, turning the fast-paced energy of the escapement into the slow, readable passage of time.

At its core, a gear ratio translates speed and torque between rotating shafts. In our clock, we have a known starting speed: our escape wheel’s shaft rotates once every minute (60 seconds). To build a timer that rings a bell every 25 minutes, we needed to create a gear train that would complete one full rotation in that time.

The maths to figure out the required gear ratio is straightforward:

• Target Rotation Time: 25 minutes = 25×60=1500 seconds.

• Source Rotation Time (Escape Wheel Shaft): 60 seconds.

• Required Gear Ratio: Target Time​=601500​ or 25:1 – as we see later on, it is the ratio which is important, and arguably, easier to understand.

As you can see in our prototype, we achieved this with a compound gear train made of two identical stages, which makes the design elegant and easy to replicate. A compound gear it a cluster of two or more gears of different sizes that are fixed together on the same shaft, forcing them to rotate at the same speed. In short, instead of having one massive gear drive a tiny one to get a big gear ratio, a compound gear lets you achieve the same result in stages.

This setup is the key to creating a gear train that can achieve a large change in speed or in a compact space

1. First Stage: The shaft from the escapement has an 8-tooth pinion that drives a 40-tooth gear. This gives a reduction of 840​=5:1.

2. Second Stage: Mounted on the same shaft as the first 40-tooth gear, a second 8-tooth pinion drives the final 40-tooth gear. This provides another reduction of 840​=5:1.

The total reduction is the product of the individual stages: 5×5=25:1. This ratio perfectly transforms the 60-second rotation of the escapement shaft into the 25-minute rotation needed to trigger the bell. Or at least that’s how it should be in a perfect world. To be honest, I experimented a little, and my timings were a little out, coming in at approximately 20 minutes per bell ring, with the weight running the timer for an hour. The main point is that I had extended out from the escapement and used compound gears to start using ratios for timings. Of note, Chat GPT was useful in the wider understanding of the clock mechanism and theory, but it would frequently miscalculate gear trains and ratios, so the final design was done with old-fashioned logic.

TIME: 3D Printed Clock

The final clock is simply a case of building out the number of gears, using the same logic as the Pomodoro Timer. I had an escapement rotating once a minute, and I needed the main gear rotating once an hour, so I could attach an hour hand to it – that’s a ratio of 60:1

Following that logic and a ratio of 60:1 –

• Escapement: The Minute Gear – The escape wheel has 30 teeth, with a 10-tooth pinion on its shaft, delivering a 1-second “tick-tock” rhythm. The escape wheel completes one full rotation every minute.

• Gear 1: 40-tooth wheel (driven by the 10-tooth pinion) and 20-tooth pinion.

• Gear 2: 60-tooth wheel (driven by the 20-tooth pinion) and 24-tooth pinion.

• Gear 3: The Hour Gear- a 120-tooth wheel (driven by the 24-tooth pinion), which completes one rotation per hour and connects to a drive gear (details on the drive gear to follow).

The gear ratios provide the necessary speed reduction to convert the escapement’s motion into hourly rotation. Starting from the escapement:

• The 10-tooth pinion drives the 40-tooth wheel of Gear 1, creating a 40:10 (or 4:1) reduction ratio—Gear 1 rotates at 1/4 the speed of the escape wheel.

• Gear 1’s 20-tooth pinion drives Gear 2’s 60-tooth wheel, a 60:20 (or 3:1) ratio—Gear 2 rotates at 1/3 the speed of Gear 1.

• Gear 2’s 24-tooth pinion drives Gear 3’s 120-tooth wheel, a 120:24 (or 5:1) ratio—Gear 3 rotates at 1/5 the speed of Gear 2.

It all suddenly seems complicated – but if you look at it more simply, the cumulative reduction ratio is 4 × 3 × 5 = 60:1. Since the escape wheel rotates once per minute, Gear 3 rotates once every 60 minutes—or exactly once per hour.

I could have chosen any ratio for the gears as long as it works out to 60:1.

With a main gear turning once an hour, upon which an hour hand can be attached, all that is now needed is a Drive Gear to power the clock and a small subset gear on which to put the minute hand.

The Drive

The drive gear serves a dual purpose as a catch mechanism, enabling the clock to be wound up while preventing unintended unwinding. This gear, connected to the drum, includes a ratchet and pawl system. When winding the clock, the ratchet allows the drum to rotate in the winding direction, lifting a weight of 2kg. The pawl engages the ratchet teeth, locking the drum in place to stop it from unwinding backwards once the winding is complete. This ensures the stored energy remains secure, releasing only through the controlled escapement and gear train during operation.

The Minute Hand

Finally, there is a separate gear chain for the minute hand, which fits behind the hour hand; this allows the traditional hour and minute hand configuration (the hour hand fits on a brass rod going through the hour gear, holding everything in place while also allowing it to freely move.

And that’s it! It seems simple when you break it down, although designing and building it from scratch took a little more time than I thought, and I lost count of the iterations it took to get here. The design will continue to be refined—perhaps with the addition of an hourly chime in the near future.

For now, we hope you enjoy making the clock. Do let us know if you build one, over at Printables (the 3D printed files are incoming, we are just collating the files)…

The post TIME: An Open Source 3D Printed Clock appeared first on Digital Urban.

For those of us who run a personal weather station (PWS), the obsession isn’t just about collecting data; it’s about seeing it and sharing it, and that often means an online data dashboard. At the Connected Environments Lab based within the Centre for Advanced Spatial Analysis, University College London, we have been running weather stations in Central London since the early 2000s, each one uploading and communicating data every 3 seconds – that’s approximately 268,918,537 measures of wind speed, air pressure, temperature, and solar intensity, amoungst others, including cloud height and now air quality etc. Getting the data online, however, has never been quite as easy as it should be…

The Past: The Golden Age of Tweens and Live Dials

So, back in the early 2000s, getting a Davis, Oregon Scientific, or La Crosse station online was a rite of passage for anyone interested in environmental data. The challenge wasn’t just mounting the hardware; it was wrestling with software to display the information. In this era, two names stood out for many hobbyists: Cumulus and Weather Display, and we have used them both extensively over the years.

Weather Display, the long-standing creation of New Zealand-based developer Brian Hamilton, is a testament to the remarkable longevity of software. First appearing around 1999, it has been continuously developed for over two decades with hundreds of updates, making it a cornerstone of the personal weather station community. Its web component, Weather Display Live, became the golden standard for its time. Built entirely on Adobe Flash, it presented a fully featured dashboard of analogue-style gauges and tickers updating in real-time. The wind speed needle would smoothly tween with every gust, the rain gauge would visibly fill, and a ticker tape would scroll with the latest observations, creating a dynamic and immersive view of the weather that was unparalleled in its era. I’ve been chasing that smooth ‘tween’ ever since in dashboards, and indeed, further into this article that tween is still the ultimate draw in real-time data.

By today’s standards, Weather Display Live perhaps looks cluttered, as design language shifts, indeed we are about to enter the era of ‘glass’ with the latest iOS updates and that will bring about a whole new look to apps and displays. Despite Adobe Flash requiring a browser plugin it allows dashboard that using the then HTML standard would simply not have been possible.

For a brief time Flash burned bright and was the basis of data on a little desktop device known as the Chumby – the Chumby was a device ahead of its time, providing realtime data updates via a series of rotating dashboards. As such it was the perfect device for displaying weather data, although the technical knowledge at the time, escaped me. Luckly a computer scientist, now Professor Steven Gray had recently joined our lab and kindly wrote a custom script to display the data.

However, Flash’s days were numbered when Steve Jobs famously called it a ‘bag of hurt’, ushering in a new age of HTML5 and laying the foundations to the web we see today.

Alongside Weather Display was Cumulus (now Cumulus MX), which carved out a huge following, particularly for Windows users. It was, and is, a robust piece of software for processing PWS data. Its approach to web display was more traditional. It used a system of web templates and tags. You could design a basic HTML page, insert special tags like <#temp>, and Cumulus would periodically process this file, replacing the tags with current data and uploading it to your web server. While it lacked the fluid dynamism of Flash, it was reliable and customisable if you knew your way around HTML and CSS. It represented, arguably the dawn of the template-driven, self-hosted dashboard. Adobe Flash dials were replaced with new plugin free gauges via a system known as Steel Gauges.

The Steel Gauges are a much-loved part of the Cumulus software legacy, while not part of the official template that came with the software, they were a hugely popular style that the Cumulus community created and shared, made possible by the software’s flexible templating system. They are the perfect example of a design philosophy called skeuomorphism – which came and went but is actually one we end this article on with perhaps the best example of a weather dashboard, but more on that later.

Skeuomorphism’s goal is to make digital items resemble their real-world counterparts. The Steel Gauges aesthetic was heavily influenced by the design trends of the late 2000s and early 2010s, aiming to make a web page look like a physical, high-end piece of hardware. The designs were rich with photorealistic detail: brushed metal or carbon fibre backgrounds, glistening chrome bezels with drop shadows, and precisely rendered needles and tick marks. The goal was to create a sense of tangible reality on the screen.

The implementation was a clever two-part process:

1. The Visuals: A user would first design the entire dashboard as a single, static background image in a graphics program like Photoshop. This image contained all the “steel” dials, gauges, and labels, but with no data.

2. The Data: They would then use this image as a background in an HTML file. The magic happened by using Cumulus’s simple but powerful templating engine. Users would strategically place Cumulus’s special “web tags” (e.g., <#temp>, <#windspeed>, <#press>) over the blank areas on the gauges.

When Cumulus processed this file, it would replace the tags with the live weather data. The software would then automatically upload the updated HTML file and the background image to the user’s web server.

Today, the Steel Gauges are perhaps a time capsule of a specific design era. They were built for a desktop-first world and were not responsive, often looking cluttered on mobile screens. As web design shifted towards minimalism, flat design, and mobile-first principles, the Steel Gauge aesthetic was largely superseded by clean, abstract, and data-dense interfaces like the Belchertown skin for WeeWX, which we come to next. However, they remain a nostalgic and important step in the evolution of personal weather data visualisation.

The Current: Between Open and Closed Systems

Standing down our Weather Display and Cumulus systems, we moved onto software known as WeeWX, running on a Raspberry Pi and sending data to a variety of online sources. It remains the system we use today. WeeWX (often stylised as weewx ) is a foundational piece of software in the modern personal weather station (PWS) world, but it’s fundamentally different from its predecessors. It is best understood not as a single application, but as an open-source software engine for collecting, processing, and displaying weather data.

It was created earlier than we at first thought – by Tom Keffer, with initial development beginning in the winter of 2008, with the first official release of WeeWX in 2009.

WeeWX is written entirely in Python and designed to run on Linux-based systems. This makes it the go-to choice for hobbyists who want to run their weather station on a low-power, single-board computer like a Raspberry Pi, operating 24/7 with minimal energy consumption, making it a notable move away from our previous power-hungry Windows machines.

The core philosophy is based around modularity and extensibility. It treats the different parts of managing a weather station as separate, interconnected components:

1. The Engine: At its heart, weewx runs a main loop that communicates directly with the weather station hardware. It polls the station every few seconds for live data (like wind speed) and stores this information in a database (typically SQLite by default, though others are supported).

2. The Reporting Cycle: At a regular, user-defined interval (the “archive interval,” often every 5 minutes), the reporting engine wakes up. It pulls the latest data from the database and uses it to generate reports.

3. Skins and Generators: This is where the user-facing magic happens. A “skin” in weewx is a complete template for a website, containing HTML files, CSS, images, and configuration settings. Using the powerful Cheetah templating engine, weewx fills these templates with data to generate static HTML pages. It can also run “generators” that push data to public services like Weather Underground, PWSWeather, and in our case custom MQTT brokers – this is key as it opens up the new world of Vibe Coding, which we come to next.

4. Extensibility: The most powerful feature of weewx is its architecture, which is designed to be extended. Users can write their own services in Python to calculate new variables (e.g., custom fire danger indices), add new sensor types, or create entirely new report formats. This makes it a flexible platform for tinkerers and data enthusiasts.

Out of the box, weewx comes with a simple, functional skin. However, its skinning architecture is has been key to community projects. The most used by far is the Belchertown skin, created by Pat O’Brien. First gaining widespread popularity around early 2019, Belchertown provides a clean, modern, mobile-responsive interface with dark mode, interactive charts, and real-time streaming updates via MQTT. It has become the de-facto “face” of weex for many users and perfectly embodies the modernist design principles of clarity and function.

At the polar opposite of weewx are the more propoietry systems that are run by the weather station hardware providers – Davis, being one key example with their live data system via Weatherlink.

Davis Instruments is a respected name in the personal weather station market, occupying the premium “prosumer” space. Based in California, the company is renowned for producing accurate, durable, and reliable hardware that is arguably considered a gold standard by serious hobbyists, educators, and agricultural professionals.

Their flagship products are the Vantage Pro2 (their expandable, top-of-the-line model) and the Vantage Vue (a more compact, all-in-one unit). For decades, the main challenge for Davis owners was getting the rich data from this excellent hardware onto a computer and the internet – we have run their Vantage Pro line since the 2000’s and now use weewx – but they do have their own ‘out of the box’ system for people who do not want to tinker with a Raspberry Pi.

Originally, connecting a Davis station required a piece of hardware called the WeatherLink Data Logger. This was a small module that slotted into the back of the weather station console, attached via a serial or USB cable to a PC. To get data online 24/7, a user had to leave a computer running constantly with the WeatherLink PC software. The data logger itself was a one-time hardware purchase, costing around £150-£250 – our data logger used to plug into our Windows machine and Weather Display.

The modern solution is thankfully far more elegant. Davis replaced the data logger with their WeatherLink Live unit in 2019. This small, standalone box acted as an internet bridge. It independently listened for the radio signals from the outdoor sensors and sent the data directly to their WeatherLink Cloud. This was the first device to eliminate the need for a console to be connected to a computer – it basically took the computer out of the workflow.

This was superseded by the WeatherLink Console (model 6313) in early 2023, updating the previous and notably dated previous iteration.

Today, WeatherLink refers to the entire cloud-based ecosystem (WeatherLink.com and the mobile app). When you buy and connect a WeatherLink Live device, you get access to this platform. It allows you to view your data from anywhere, see historical charts, and share your station publicly.

The web-based dashboard is, however, slightly ‘clunky’ and arguably badly designed:

It also operates on a tiered subscription model, and to view your data in real-time, costs.

1. Basic Tier (Free): When you purchase your hardware (e.g., a Vantage Vue station + a WeatherLink Live device), you get the Basic tier for free. This includes:

   • Your current, live data updated every minute.

   • A 24-hour chart of your data.

   • The ability to see your data on the app and website.

2. Pro Tier (Paid): This is the most common upgrade for enthusiasts. For a recurring fee, it unlocks much deeper access to your own data.

   • Cost: Approximately $3.95/month or $42.50/year (with prices subject to change and regional variation).

   • Features:

     • Access to your full, detailed historical data archive.

     • Advanced, customisable charting tools to analyse your history.

     • More frequent “live” data updates on the web (every 2.5 seconds).

     • The ability to download your data archive as a CSV file.

As such, we still have our Davis Vantage Pro plugged into a WeeWX system, which enables the transmission of data through an MQTT server and bypasses any paywalls to view our own data.

Towards Personal Templates with Vibe Coding

This would normally leave us with the Belchertown Skin, and while excellent, the itch to edit and innovate is always strong, and with it the desire to pull in increasingly customised data feeds, pulling in multiple sources of data to gain a better overview of the current environmental conditions. This would normally require a good understanding of data structures, application protocol interfaces, cascading style sheets, JavaScript and perhaps a bit of Firebase and databases. All of course are good to know and learn but if you want a new look to your data and only have a hour free then Vibe Coding is the current route to take. As in our previous substack post, the term ‘Vibe Coding’ was defined Andrej Karpathy, a co-founder at OpenAI in Early 2025. The basic idea is to rely entirely on Large Language Models – LLMs – and code by using only natural language prompting, rather than writing the code yourself. At the moment we are exploring this new way to develop Weather Dashboards and are in the process of adding examples to our GitHub.

Our first example (see https://digitalurban.github.io/VibeWeatherDashboards/mixed_dashboard.html), pictured above, was created using Gemini 2.5 Pro, which is currently available for free for a month. The Pro version provides sufficient usage to create an unlimited number of dashboards. Vibe Coding is good – but it’s not that good, it won’t create the dashboard above in a single prompt, it takes a number of iterations, starting small and building up. It was built using the Canvas feature, which allows both a view of the code and a live preview, making it quick and easy to make changes. For example, our first prompt into Gemini was ‘make a 5-day forecast for ‘our area’ using a free weather api and use flat icons’. This created the 5-day forecast, using the Open-Meteo API, we subsequently pointed Gemini to our weewx data feed and asked it to use the same icon style to provide a dashboard using the key weather data indicators of Temperature, Wind, Rain, Pressure and Solar. Once that was working, with a few edits back and forth, we then added the coloured background, which changes colour according to the outside temperature, ranging from a dark blue for -10 °C through to a deep red for 35 degrees and above.

At the moment, we have it running on an old iPad, which we have mounted in a frame, sitting on a bookshelf in the corner of the room:

Vibe coding has also enabled us to explore the creation of AI Weather Landscape dashboards, which take the raw output of the UK Met Office forecast and send it to the Google Vertex AI platform to interpret it as an image of an English Landscape, twice a day.

Finally, Vibe Coding has allowed us to experiment with real-time graphing, something that harks back to Cumulus, as their templates integrated a series of graphs as part of a drop-down menu. Our graphing displays data in real-time over a period of 24 hours, allowing trends to be visualised and also the graphs to update as new data points come in.

The creation of a real-time graphing required the setting up of Firebase – something which is not overly self-explanatory. However, using Vibe Coding it only took an hour and a half from knowing little to nothing, to have a full system set up and running – it is all in the human language prompts and taking things in small steps. Our first prompt was ‘we have this data feed (insert mqtt feed link) and want to view it as a real-time graph, probably using Firebase, can you show us how to set it up and provide me with full code to view the data on a webpage’ – this was 6 months ago using ChatGPT, things move rapdily in this space and now there is Firebase Studio which makes it even easier to get up and running.

Having been using and making weather dashboards in 25 years it is only in the last 6 months with the invention of Vibe Coding that innovation has speeded up. We have moved from clunky Windows PC looking interfaces through Flash, skeuomorphism, flat designs and now into hyper-customised dashboards using vibe computing. Yet there is one dashboard that I have kept looking at over the years and so far have been unable to replicate (mainly due to copyright issues, but also the code) – and that is an online version of the classic Intromet Climatica Weather System.

It is perhaps the ultimate digital-analogue physical display, and one that is likely on every weather data enthusiast’s wish list. While the physical system remains out of reach for us, the developer over at Wimslow Weather has made an online version (hidden away under his developer section) and it is lovely:

Sure, it’s full on skeuomorphism – but the tween on the wind direction and wind speed is one of the best we have seen – so despite having access to the new opportunities of AI, it’s a physical design from a small British company, Instromet, that somehow still remains the best, in our view.

We would love to know what dashboard you like or us, do tell us in the comments, and if you like this article, the subscribe link is of course below.

The post Chasing the Tween: My 25-Year Obsession with Weather Data appeared first on Digital Urban.

Everything Changed

The term ‘Vibe Coding’ was defined Andrej Karpathy, a co-founder at OpenAI in Early 2025. The basic idea is to rely entirely on Large Language Models – LLMs – and code by using only natural language prompting, rather than writing the code yourself.

Back in 2023, I published ‘Frame-IT’, an iOS app on the Apple Store, written in Swift but coded completely in the then-early version of ChatGPT. As I noted on DigitalUrban, every app has a story, from the idea through to story boarding, finding a design team, working with in house computer scientists or outsourcing. All of these steps take time, resources and often for the small ‘would be developer’ the obstacles are overwhelming, meaning that the spark of an idea often gets lost.

Yet, everything has changed, the whole landscape of developing, designing and creating has turned on its head. It has reached the point where the spark of an idea can be coded, designed, marketed and launched with the help of Artificial Intelligence. Frame-IT is a very simple app, doing a simple thing, but it came from an idea, a want, a desire to do something which before AI would have got lost in logistics, finding the time of computer scientists, and it would certainly be economically unfeasible.

The First Idea

Frame-IT came about while looking at Samsungs’ Frame Televisions, beyond the normal 4K television they blend into the background by displaying art and making the art look as it is mounted on a white background while also being enclosed in a frame – i.e. like a painting. Samsung does this well and the screens are excellent, but it is limited to art works, leading to the idea that it would be nice to frame websites, specifically ‘data’ based web sites and hang data on walls, data that changes in Realtime. Of course, any screen could be used, but if you simply show data on a screen or monitor, no one notices. If you hang it in a frame, as if its art, people will notice.

The concept was therefore simple, build an application that puts a picture frame around websites, allow users to select which websites to show and if there is more than one, cycle through them, like a dashboard. This would allow small screens, such as iPads, to act as frames and, via AirPlay, devices such as projectors or general screens to gain a look beyond their norm and display websites and data in the same way as hanging art on the wall.

The problem was, this was an idea, to code it would require knowledge of Swift, a library of ‘picture frames’ and probably a business case to justify the time of resident computer scientists (I work at University College London, so we have a few around) and to be honest it was such a simple idea I’m note sure anyone would listen. So, with the rise of AI, I decided to build it myself, using AI from start to finish, from knowing little about Swift, and only as much about AI as my then twitter feed was full of and reading articles on site such as The Verge.

The app took me two days to build, two days where I was also working, so mainly doing things in-between other tasks, over lunch and a little bit in the evenings. With the initial learning curve out the way, I could rebuild it in a day. The first things I did was sign up to OpenAI to gain access to GPT 4 , which released on March 14th 2023. This allowed me access to the latest version and therefore the most up to date knowledge base, although looking back version 3 would probably have been fine and I could have simply used the free tier. My first prompt was “Can you write me swift code to take a website, centre it and add the image of a picture frame around it’. The app should work full screen, in landscape mode”. I had a sample picture frame (taken from Wikipedia and cutting out the actual image to leave a transparent centre).

Within 60 seconds, GPT gave me a section of code and then stopped, it turns out there was a limit in the amount of characters it could respond with. A quick Google search (ironically) showed me that by typing ‘continue’ ChatGPT will continue the code. With this I became a master of cutting and pasting, with the code often taking three continues and code which while sometimes was in code boxes, was also in simply text. It also allowed me to start to understand the layout and nature of Swift, within 30 minutes i had my first app running on an iPad, via Xcode. Simply by cutting and pasting and pressing ‘play’. Not all things worked out, there were often errors, but errors I could cut and paste back into GPT and it would solve them, most of the time.

Each time a milestone was made – a working version, a version with a picture frame in and a website showing, I would save the code as Chat GPT would sometimes break the next version while I was asking for new features. Features such as ‘Add a button to move to the next website’, ‘If there is more than one website, then cycle through them every 60 seconds’ (the websites were hard-coded at this point). Once i had a concept running on my own iPad, I realised it was quite neat and decided to then adapt it so others maybe able to use it. I added a settings page – via ‘Can you delete all the websites I have added and include a settings page, the settings page should be reached via a button and have the ability to add and delete websites, once added they should be saved so the app remembers them when reopened’. This is coding but in the new language – human language.

The picture frames were created in Image Creator by Bing, a search engine I never thought I would use (being a Mac user) but in that last week I had not been near Google. Bing allowed me to type in prompt and get images without any user limits. Simple prompts such as “create me a gold Victorian picture frame, it should be photorealistic with minimum reflections and the centre should be cut out” worked amazingly well, providing me with an almost limitless range of Picture frames to include as part of the assets.

Not all the picture frames are from AI, a couple are from open source imagery, it felt wrong to cut out the picture, but the frames have some provenance and they were nice to include.

Marketing requires imagery as well – as such I took a very simple picture of my two test iPads and used the ‘PhotoRoom” AI app to transform it to two iPads on a bench with a concrete wall behind, whereas the reality was far from as glamourous.

The App is now available via the Apple Store, it even has its own website and logo – again designed by AI, designed using Looka and hosted on Framer. So while it worked, it was a little painful with the limited lengths of code in the early version of ChatGPT and the endless cutting and pasting/fixing things – it was quick, but it still took a notable commitment and time. It is also a very very niche app, but as we get to, thats the point of Vibe Coding.

And then Everything Changed Again

That was 2023 – late 2024, and everything has changed again, not only the workflow and the tools, but also the ability of the LLMs to Vibe Code, they now work, no more cutting and pasting small chunks of code, everything works. Code comes out ready to go and any errors can be fixed in a complete code base, with notably less errors compared to 2024 . As such, we made another app – again Vibe Coding, without knowing at the time – MQTTFrame.

The aim was to build on the concept of FrameIT but allow realtime data intergration directly in the app via MQTT (a lightweight, publish-subscribe network protocol for data) and to make it easy to subscribe to any MQTT topic and display live updates.

Our aim was to allow:

• Customizable Frames: Choose from multiple high-quality decorative frames to complement your home or office décor.

• Clean and Clear Data Display: Showcase important data such as temperature, pressure, news, and more with clear typography and layout.

• Fullscreen Mode: Tap to seamlessly switch to an immersive fullscreen view, maximizing readability and aesthetics.

• Easy Management: Add, edit, and reorder topics quickly through an intuitive interface.

• Instant Updates: Receive real-time data updates over MQTT, ensuring you’re always in the know.

And that’s what we did – but this time in a day and with everything created in ChatGPT – icons, graphics, code, marking text, and even walking me back through how to get it on the Apple Store (as it’s an oddly complex and easily forgotten process).

So one day Vibe Coding and an app was taken from concept to ready to publish on the Apple Store – if you want to try it its currently available for free, on the Apple Store

Everything Again and Again

That was the end of 2024, now in mid 2025 and term Vibe Coding has come into common use and Large Language Models are now more than capable of making anything from webpages to apps to writing posts (all of this was, however, written by an actual human; any grammatical errors are of course, intentional). We have now switched from ChatGPT to Google Gemini and use it almost daily to produce and make apps or webpages that perhaps only I want in my life, such as – an Asteroids Clock, made in 30 minutes (temporarily housed at – https://finchamweather.co.uk/astroidsclock.html – we will move it to Github soon as we get chance).

or a Procedural City Maker (https://finchamweather.co.uk/proceduralcity.html)

or a Weather Dashboard with the forecast made into the image of an English Landscape using data from the API from the UK Met Office:

You can view the dashboard live at https://finchamweather.co.uk/aiweatherimage.html

All small, niche things that somehow I love and I am happy that Vibe Coding allowed them to exist – that’s the magic, Vibe Coding allows you to create anything in your imagination that did not exist to exist, it’s a great time to be making digital things.

If you liked this post, please do subscribe, it gives us a good reason to write another one…

The post Vibe Coding: From iOS Apps to an Asteroid Clock and 3D Cities appeared first on Digital Urban.

The post MQTT Frame – Beautifully Framed Live Data appeared first on Digital Urban.