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.

Introduction

Viewing real-time data from a personal weather station such as a Davis Vantage Pro, a Tempest, or an EcoWhitt device can be complex. However, the majority of systems that process weather data, such as Weather Display, Weewx, or CumlusMx, all have the ability to output MQTT data. This data can be used to display a real-time graph of the data, keeping you engaged with the latest weather updates, and supplemented with any other data which is MQTT-based.

With this in mind, we’ve developed a live weather monitoring dashboard as an illustrative example. This dashboard uses MQTT for real-time data updates and Chart.js for dynamic visualization. We’ve also included a visual indicator for connection status and a brief pulse effect to notify when new data arrives, enhancing the user experience.

You can view it live at: https://finchamweather.co.uk/weathergraph.htm

The data populates as the page loads – we could of course back load it via a database link, but the aim was to simply use MQTT and have a graphing system that streams in data, its a work in progress but here is how we got it working:

Setting Up the Environment

Before we dive into the code, ensure you have the following libraries included in your HTML:

• Paho MQTT: for MQTT protocol handling – our MQTT feed is open to use as a test, replace this with your own MQTT details in the main code.
• Chart.js: for creating dynamic charts
• Chart.js adapter for date-fns: for handling time scales in charts

Initial HTML Setup

We’ll start by setting up the basic HTML structure. This includes elements for displaying the connection status, forecast, weather statistics, and the weather chart.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <meta name="apple-mobile-web-app-status-bar-style" content="black">
    <title>Live Weather Graph</title>
    <script src="https://cdnjs.cloudflare.com/ajax/libs/paho-mqtt/1.0.1/mqttws31.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/chartjs-adapter-date-fns"></script>
    <style>
        body {
            font-family: Arial, sans-serif;
            margin: 20px;
        }
        #mqttStatus {
            margin-bottom: 20px;
            text-align: left;
            font-size: 1.2em;
        }
        .dot {
            height: 20px;
            width: 20px;
            border-radius: 50%;
            display: inline-block;
        }
        .green {
            background-color: green;
        }
        .red {
            background-color: red;
        }
        .orange {
            background-color: orange;
        }
        .pulse-once {
            animation: pulse-once 1s;
        }
        @keyframes pulse-once {
            0% { transform: scale(1); }
            50% { transform: scale(1.2); }
            100% { transform: scale(1); }
        }
        #forecast {
            margin-bottom: 20px;
            text-align: left;
            font-size: 1.2em;
            font-weight: bold;
        }
        #stats {
            display: flex;
            justify-content: center;
            gap: 20px;
            margin-bottom: 20px;
            font-size: 1.2em;
            font-weight: bold;
        }
        #stats div {
            padding: 10px 20px;
            border: 1px solid #ccc;
            border-radius: 8px;
            box-shadow: 2px 2px 12px #aaa;
            background-color: #f9f9f9;
        }
        canvas {
            border: 1px solid #ccc;
            box-shadow: 2px 2px 12px #aaa;
        }
    </style>
</head>
<body>
    <div id="mqttStatus"><span id="connectionDot" class="dot red"></span> mqtt: disconnected</div>
    <div id="forecast">Forecast: Loading...</div>
    <div id="stats">
        <div id="maxWindSpeed">Max Wind Speed: 0 mph</div>
        <div id="maxTemp">Max Temperature: 0 °C</div>
        <div id="minTemp">Min Temperature: 0 °C</div>
        <div id="maxPressure">Max Pressure: 0 mbar</div>
        <div id="minPressure">Min Pressure: 0 mbar</div>
    </div>
    <canvas id="weatherChart" width="800" height="400"></canvas>
</body>
</html>

Connecting to MQTT

Next, we set up the MQTT connection. The MQTT client will connect to the broker, subscribe to the necessary topics, and handle messages when they arrive.

// MQTT connection settings
var mqtt;
var reconnectTimeout = 2000;
var host = "mqtt.cetools.org";
var port = location.protocol === 'https:' ? 8081 : 8080;
var options = {
    timeout: 3,
    onSuccess: onConnect,
    onFailure: onFailure,
    useSSL: location.protocol === 'https:',
};
var clientID = "clientID" + parseInt(Math.random() * 100);

function updateConnectionStatus(status) {
    const dot = document.getElementById("connectionDot");
    if (status === "connected") {
        dot.className = "dot green";
        document.getElementById("mqttStatus").innerHTML = `<span class="dot green" id="connectionDot"></span> mqtt: connected`;
    } else if (status === "disconnected") {
        dot.className = "dot red";
        document.getElementById("mqttStatus").innerHTML = `<span class="dot red" id="connectionDot"></span> mqtt: disconnected`;
    } else if (status === "reconnecting") {
        dot.className = "dot orange";
        document.getElementById("mqttStatus").innerHTML = `<span class="dot orange" id="connectionDot"></span> mqtt: reconnecting`;
    }
}

function pulseDot() {
    const dot = document.getElementById("connectionDot");
    dot.classList.add("pulse-once");
    setTimeout(() => {
        dot.classList.remove("pulse-once");
    }, 1000); // Duration of the pulse-once animation
}

function onFailure(message) {
    console.log("Connection Attempt to Host " + host + " Failed: ", message.errorMessage);
    updateConnectionStatus("disconnected");
    setTimeout(MQTTconnect, reconnectTimeout);
}

function onConnect() {
    console.log("Connected ");
    updateConnectionStatus("connected");
    mqtt.subscribe("personal/ucfnaps/downhamweather/loop");
    mqtt.subscribe("personal/ucfnaps/eink/met");
}

function MQTTconnect() {
    console.log("Connecting to " + host + " on port " + port);
    updateConnectionStatus("reconnecting");
    mqtt = new Paho.MQTT.Client(host, port, clientID);
    mqtt.onMessageArrived = onMessageArrived;
    mqtt.onConnectionLost = function(responseObject) {
        if (responseObject.errorCode !== 0) {
            console.log("Connection Lost: " + responseObject.errorMessage);
            updateConnectionStatus("disconnected");
            setTimeout(MQTTconnect, reconnectTimeout);  // Attempt to reconnect
        }
    };
    mqtt.connect(options);
}

window.onload = function() {
    MQTTconnect();
}

Handling Incoming Messages

When messages arrive, we process the data and update the chart. We also update the connection dot to pulse briefly, indicating new data has been received.

let lastUpdate = Date.now();  // Initialize to current time
let firstUpdate = true;  // Flag to ensure first update happens immediately

let maxWindSpeed = 0;
let maxTemp = -Infinity;
let minTemp = Infinity;
let maxPressure = -Infinity;
let minPressure = Infinity;

function updateWindSpeed(windSpeed, timestamp) {
    weatherChart.data .labels.push(timestamp);
    weatherChart.data.datasets[0].data.push(windSpeed);

    // Update max wind speed
    if (windSpeed > maxWindSpeed) {
        maxWindSpeed = windSpeed;
        document.getElementById('maxWindSpeed').innerText = `Max Wind Speed: ${maxWindSpeed} mph`;
    }

    // Limit the number of data points to keep the chart responsive
    if (weatherChart.data.labels.length > 1440) { // Assuming 1 data point per minute, keep 24 hours of data
        weatherChart.data.labels.shift();
        weatherChart.data.datasets[0].data.shift();
    }

    weatherChart.update();
}

function updateOtherMetrics(temperature, solarRadiation, rainAmount, pressure, timestamp) {
    weatherChart.data.datasets[1].data.push({x: timestamp, y: temperature});
    weatherChart.data.datasets[2].data.push({x: timestamp, y: solarRadiation});
    weatherChart.data.datasets[3].data.push({x: timestamp, y: rainAmount > 0 ? rainAmount : null});
    weatherChart.data.datasets[4].data.push({x: timestamp, y: pressure});

    // Update max and min temperature
    if (temperature > maxTemp) {
        maxTemp = temperature;
        document.getElementById('maxTemp').innerText = `Max Temperature: ${maxTemp} °C`;
    }
    if (temperature < minTemp) { minTemp = temperature; document.getElementById('minTemp').innerText = `Min Temperature: ${minTemp} °C`; } // Update max and min pressure if (pressure > maxPressure) {
        maxPressure = pressure;
        document.getElementById('maxPressure').innerText = `Max Pressure: ${maxPressure} mbar`;
    }
    if (pressure < minPressure) { minPressure = pressure; document.getElementById('minPressure').innerText = `Min Pressure: ${minPressure} mbar`; } // Limit the number of data points to keep the chart responsive if (weatherChart.data.labels.length > 1440) { // Assuming 1 data point per minute, keep 24 hours of data
        weatherChart.data.datasets[1].data.shift();
        weatherChart.data.datasets[2].data.shift();
        weatherChart.data.datasets[3].data.shift();
        weatherChart.data.datasets[4].data.shift();
    }

    weatherChart.update();
}

function updateForecast(forecast) {
    document.getElementById('forecast').innerText = `Forecast: ${forecast}`;
}

function onMessageArrived(message) {
    console.log("Message Arrived: " + message.destinationName + " : " + message.payloadString);
    if (message.destinationName === "personal/ucfnaps/downhamweather/loop") {
        const data = JSON.parse(message.payloadString);
        const windSpeed = data['windSpeed_mph'];  // Adjust this key according to your data structure
        const temperature = data['outTemp_C'];  // Adjust this key according to your data structure
        const solarRadiation = data['radiation_Wpm2'];  // Adjust this key according to your data structure
        const rainAmount = data['dayRain_mm'];  // Adjust this key according to your data structure
        const pressure = data['pressure_mbar'];  // Adjust this key according to your data structure

        const nowTimestamp = new Date();

        // Update wind speed every time
        updateWindSpeed(windSpeed, nowTimestamp);

        if (firstUpdate || Date.now() - lastUpdate >= 60000) {
            // Update other metrics every minute
            updateOtherMetrics(temperature, solarRadiation, rainAmount, pressure, nowTimestamp);
            lastUpdate = Date.now();
            firstUpdate = false;  // Ensure subsequent updates follow the interval
        }

        // Pulse the dot when new data arrives
        pulseDot();
    } else if (message.destinationName === "personal/ucfnaps/eink/met") {
        const forecast = message.payloadString;
        updateForecast(forecast);
    }
}

Chart.js Setup

Now, let’s configure Chart.js to visualize the weather data. We will use multiple datasets to display wind speed, temperature, solar radiation, rain amount, and pressure.

// Chart.js setup
const ctx = document.getElementById('weatherChart').getContext('2d');
const weatherChart = new Chart(ctx, {
    type: 'line',
    data: {
        labels: [],  // Time labels
        datasets: [{
            label: 'Wind Speed (mph)',
            data: [],
            borderColor: 'rgba(75, 192, 192, 1)',
            borderWidth: 3,
            fill: false,
            yAxisID: 'y-axis-1',
            tension: 0.1
        },
        {
            label: 'Temperature (°C)',
            data: [],
            borderColor: 'rgba(255, 99, 132, 1)',
            borderWidth: 3,
            fill: false,
            yAxisID: 'y-axis-2',
            tension: 0.1
        },
        {
            label: 'Solar Radiation (W/m²)',
            data: [],
            borderColor: 'rgba(255, 206, 86, 1)',
            borderWidth: 3,
            fill: false,
            yAxisID: 'y-axis-3',
            tension: 0.1
        },
        {
            label: 'Rain Amount (mm)',
            data: [],
            borderColor: 'rgba(54, 162, 235, 1)',
            borderWidth: 3,
            fill: false,
            yAxisID: 'y-axis-4',
            tension: 0.1
        },
        {
            label: 'Pressure (mbar)',
            data: [],
            borderColor: 'rgba(153, 102, 255, 1)',
            borderWidth: 3,
            fill: false,
            yAxisID: 'y-axis-5',
            tension: 0.1
        }]
    },
    options: {
        responsive: true,
        plugins: {
            legend: {
                position: 'top',
            },
            title: {
                display: true,
                text: 'Live Weather Data'
            },
            decimation: {
                enabled: true,
                algorithm: 'lttb',
                samples: 100,  // Adjust this value as needed for performance
            },
        },
        scales: {
            x: {
                type: 'time',
                time: {
                    unit: 'minute'
                },
                title: {
                    display: true,
                    text: 'Time'
                }
            },
            'y-axis-1': {
                type: 'linear',
                position: 'left',
                beginAtZero: true,
                title: {
                    display: true,
                    text: 'Wind Speed (mph)'
                }
            },
            'y-axis-2': {
                type: 'linear',
                position: 'right',
                beginAtZero: true,
                title: {
                    display: true,
                    text: 'Temperature (°C)'
                },
                grid: {
                    drawOnChartArea: false
                }
            },
            'y-axis-3': {
                type: 'linear',
                position: 'right',
                beginAtZero: true,
                title: {
                    display: true,
                    text: 'Solar Radiation (W/m²)'
                },
                grid: {
                    drawOnChartArea: false
                }
            },
            'y-axis-4': {
                type: 'linear',
                position: 'right',
                beginAtZero: true,
                title: {
                    display: true,
                    text: 'Rain Amount (mm)'
                },
                grid: {
                    drawOnChartArea: false
                }
            },
            'y-axis-5': {
                type: 'linear',
                position: 'right',
                beginAtZero: true,
                title: {
                    display: true,
                    text: 'Pressure (mbar)'
                },
                grid: {
                    drawOnChartArea: false
                }
            }
        },
        interaction: {
            intersect: false,
            mode: 'nearest',
        },
        elements: {
            line: {
                cubicInterpolationMode: 'monotone',
            },
        },
    }
});

Conclusion

By integrating MQTT and Chart.js, it is possible to create a dynamic and real-time weather monitoring dashboard. The connection status indicator provides immediate feedback on the connection state, and the pulsing effect when new data arrives enhances user experience by visually notifying them of updates.

This setup can be further extended by adding more datasets, customizing the chart’s appearance, or integrating additional sensors. The data of course couple be from any feed, but real-time weather monitoring provides a good example of how IoT and web technologies can be combined to create realtime dashboards.

The post Enhancing Live Weather Monitoring with MQTT and Chart.js appeared first on Digital Urban.

# Import necessary libraries
import ftplib
import requests
from PIL import Image
import io
from bs4 import BeautifulSoup
from datetime import datetime

# Get Met Office Data and Strip Today/Tonight Text
url = 'http://datapoint.metoffice.gov.uk/public/data/txt/wxfcs/regionalforecast/xml/512?key=YOURMETOFFICEAPIKEY'
document = requests.get(url)
soup = BeautifulSoup(document.content, "lxml-xml")

# Extract today's weather forecast
todayraw = soup.find_all("Paragraph", attrs={'title': 'Today:'})
todaystr = str(todayraw)
today = (todaystr.replace('[<Paragraph title="Today:">', '').replace('</Paragraph>', '').replace(']', ''))

# Set up OpenAI API key
from openai import OpenAI
client = OpenAI(api_key='YourOpenAIAPIKey')

# FTP server details
ftp_server = 'YourFTPServer'
ftp_username = 'FTPUserName'
ftp_password = 'FTPPassword'

# Specify the type of Norfolk landscape (e.g., rural, coastal, urban)
landscape_type = "rural Norfolk landscape"  # Change this as per your preference

# Create the image prompt
image_prompt = (
    f"A photorealistic single, cohesive scene image of a {landscape_type}, showcasing the following weather conditions: {today}. "
    "The image should realistically depict elements like cloud formations, sunlight or lack thereof, any precipitation, and wind effects. "
    "It should convey the atmosphere and mood suggested by the weather, with appropriate lighting and color tones. No numerical data or text should be included, just a pure visual representation of the weather in the landscape."
)

# Generate an image using OpenAI's DALL·E
def generate_image(prompt):
    response = client.images.generate(prompt=prompt, n=1, model="dall-e-3", quality="standard", style="vivid", size="1792x1024")
    image_url = response.data[0].url
    return image_url

# Function to generate a datestamp
def get_datestamp():
    return datetime.now().strftime("%Y%m%d%H%M%S")

# Modified FTP upload function
def upload_to_ftp(image_url, remote_path):
    with ftplib.FTP(ftp_server) as ftp:
        ftp.login(user=ftp_username, passwd=ftp_password)
        response = requests.get(image_url)
        image = Image.open(io.BytesIO(response.content))
        datestamp = get_datestamp()
        original_image = io.BytesIO()
        image.save(original_image, format='JPEG')
        original_image.seek(0)
        ftp.storbinary(f'STOR {remote_path}_{datestamp}.jpeg', original_image)
        resized_image = image.resize((1792, 1024))
        jpeg_image = io.BytesIO()
        resized_image.save(jpeg_image, format='JPEG')
        jpeg_image.seek(0)
        ftp.storbinary('STOR public_html/image.jpeg', jpeg_image)
        resized_image = image.resize((800, 480))
        jpeg_image = io.BytesIO()
        resized_image.save(jpeg_image, format='JPEG')
        jpeg_image.seek(0)
        ftp.storbinary('STOR public_html/image_eink.jpeg', jpeg_image)

# Generate the image and upload it
image_url = generate_image(image_prompt)
upload_to_ftp(image_url, 'public_html/image.jpeg')

Breaking down the steps in the code –

1. Importing Libraries: We start by importing necessary Python libraries for HTTP requests, image processing, FTP interaction, and data parsing.
2. Fetching Weather Data: The script retrieves weather data from the Met Office using an API key. It extracts relevant information using BeautifulSoup and cleans up the output to get the weather forecast for today.
3. OpenAI API Key: The OpenAI API key is set up to use the DALL·E model for image generation.
4. FTP Server Details: FTP server credentials (server address, username, and password) are provided for image uploads.
5. Weather Details and Landscape Type: The weather description obtained earlier is stored in weather_details . A landscape type (e.g., “rural Norfolk landscape”) is specified.
6. Image Prompt Creation: The image_prompt  is constructed by combining weather details and landscape type. It describes the desired image.
7. Image Generation with DALL·E: The  generatrate_image function uses DALL·E to create and return an image based on the prompt.
8. Datestamp Generation: A datestamp is generated for archiving purposes.
9. FTP Image Upload: The upload_to_ftp function connects to the FTP server, downloads the generated image, and uploads it to specific directories – this is optional, only of use if you are hosting your images.
10. Running the Script: We run the script every 12 hours, using a cron job on a Raspberry Pi. We additional send it to our iPhone and our FrameTV, so the latest image is viewable either as a widget or on screen

Finally we also display it on our iPad, using the FrameIT app – this auto updates the image when a new one is uploaded to the web server.

 

Dall-E 3 image on an iPad using Frame-IT

Do let us know if you create you own AI based weather images using data inputs – it would be interesting to see how different landscapes and counties compare.

The post Creating Art Like Weather Forecast Images with DALL·E 3 and API Data appeared first on Digital Urban.

Traditional German weather houses are small, decorative structures that are popular in Germany and other parts of Europe. They are often made from wood and used to predict the weather.

A Traditional Weather House

The way the weather house works is quite simple. Inside the house, there is a strip of catgut or hair. The gut relaxes or shrinks based on the humidity in the surrounding air, relaxing when the air is wet and tensing when the air is dry. Attached to the strip is a small figure of a man and a woman. When the humidity in the air changes, the strip will expand or contract, causing the figures to move.

If the weather is going to be dry and sunny, the man will come out of the house. If it is going to be wet and rainy, the woman will come out of the house. If the humidity is just right, both the man and the woman will be visible.

Traditional German weather houses are, an interesting, if slightly imprecise way to predict the weather. They are also a useful inspiration to develop a slightly more modern version using the Open Weather Map API, a 360-degree non-continuous servo, some neopixels and a Raspberry Pi Pico W.

 

In essence the house is a series of weather symbols which rotate according to the feed from the Open Weather Map API. This can be set to any location in the world and it updates every 15 minutes. It is also adaptable to change to your own source of weather data, perhaps your own personal weather station.

 

There are also two sets of neopixels – one to light up the symbol, this works well at night and looks like an outside light on the house, allowing the weather conditions to be seen. The other is an 8 pixel neopixel strip which changes colour and animates according to the conditions. If it’s raining then the lights change to blue and simulate raindrops, for sunny spells they light and dim with tinges of yellow to simulate the sun poking out of the clouds, etc. All of these are editable in the code to change according to your own preference.

 

At the heart of the weather house is a Raspberry Pi Pico W, held in a 3D printed enclosure which also encases the LEDs and the Servo.

 

It slots into the case which, in our example, is laser cut from white perspex for the house and 3mm plywood for the roof.

 

Once assembled the 3D printed enclosure along with the dial, fits into the main house. The servo is set to its starting point with the ‘Sun’ icon showing through the window.

Weather House Inside View

We power ours from a 20,000mAh power bank which keeps it running for about a week. Each time the data updates the outside lamp turns on and off, so you have a visual clue that new data has uploaded.

 

The post Reimaging the Traditional Weather House with Open Data, Laser Cutting and 3D Printing appeared first on Digital Urban.

Colours – London Live Weather

Backgrounds

The post Colours: A Live London Weather Dashboard appeared first on Digital Urban.

The post Live London Weather appeared first on Digital Urban.

Here at digital urban over the years we have got used to setting up capture systems that are low cost yet get the job done, and our timelapse system is hopefully no exception.

You will need:

1 x WebCam – we recommend the QuickCam 9000 due to its 1600 x 1200 resolution but any USB webcam will do.

1 x Waterproof Torch – see the photograph below, any torch that is generally waterproof is suitable, ours cost £9.99.

1 x USB Extender Cable – depending on length required, £15.00

1 x Roll of Electrical Tape

1 x Old Sock

1 x Webcam Capture Software, we used Booru Webcam 2.0 , £0.

Time Required – One Hour.

Step 1: Mounting the Webcam

The key is to house the webcam inside the torch, thus creating a unit you can leave outside in all weather while still capturing images. As such the first step is to take the torch apart, remove all the internals, unscrew the front section and pull out the reflector.

The webcam is housed inside the reflector, where the bulb used to be. To allow a snug fit simply thread the USB cable of the webcam through the hole where the bulb was and pull so the webcam is secure inside.

We tried various methods to secure the webcam but the best is to allow it to simply sit on top of an old sock, this allows the cam to remain tight in the housing while also allowing last minute adjustments. We know it sounds very low tech, but trust us it we reached this conclusion after hours of trial and error with a lot of glue and fixings.

Step 2: Wiring it Up

Drill a hole in the base of the torch and thread the USB lead through, screw back on the glass front and you are done. You should now have a torch with a webcam inside complete with a USB cable coming our the back.

Our webcam sits on the roof with the cable running down to the eves and coming into the house through a window. Our run is approximately 10 metres so we have linked up the end of the USB of the webcam to the computer using an Active USB extender.

An active USB extender is designed to allow cable runs over and above the usual 5m limit. Multiple leads may be connected up to a maximum of 3, giving a maximum cable run of up to 20m (with three active and one standard lead). We simply plugged the USB cable into the extender and wrapped the connection in electrical tape to keep out the rain.

The webcam is ready to go and ready to mount wherever has a good view. The torch we used is useful as it has a stand allowing it to point at the sky or to be mounted on a ledge. Ours is secured to a chimney pot using regular cable ties.

Step 3: Capture the Images

Timelapse images work by capturing a image few every few seconds and then stringing together the sequence to produce a movie. Our webcam is linked up to a Eee PC running Windows XP, the laptop runs almost silently which is a bonus as most timelapses run for many hours.

There are numerous software packages for capturing timelapse images, we used Booru WebCam 2.0 as its both free and one of the best available on the Windows platform. For Mac users Gawker is a free and extremely easy option to use, although note the QuickCam 9000 is not Mac friendly, it is worth taking a look at the Logitech Vision Pro instead.

The general rule is to capture an image every 5 or 10 seconds in .png format for minimum loss of quality. The images are saved in sequence ready to be merged into a usable movie, we store ours on a portable hard drive as it is all too easy to run out of disk space when capturing every 5 seconds over a 24 hour period.

Step 4: Create the Movie

There are many ways to create a movie from a series of images. The simplest way is to use QuickTime Pro which allows one to open an image sequence (file > Open > Image Sequence), set the framerate (normally 24 frames per second) and save. If you don’t wish to use QuickTime Pro then take a look at this easy to follow tutorial on using Windows Movie Maker.

Below is an example movie captured using our set up. The frames were captured as detailed above, opened in QuickTime Pro and then simply saved at 1280 x 720 for upload to Vimeo. The whole process takes approximately 15 minutes.

The aerial is in view throughout the movie above, as such you can use the digital zoom function on the webcam to zoom past the aerial, allowing a clearer view of the skyline. The movie below was created using the digital zoom:

Music: Let it Rain

If you do install a webcam in a torch and create a timelapse movie do let us know and any thoughts/question are of course welcome via the comments below.

Update – see our post on GIS Timelapse for Pedestrian Movement Analysis for an example using the Booru webcam software and timestamped images.

The post Tutorial: Torch/Flashlight + Webcam = HD Timelapse System appeared first on Digital Urban.

Here at digital urban over the years we have got used to setting up capture systems that are low cost yet get the job done, and our timelapse system is hopefully no exception.

You will need:

1 x WebCam – we recommend the QuickCam 9000 due to its 1600 x 1200 resolution but any USB webcam will do.

1 x Waterproof Torch – see the photograph below, any torch that is generally waterproof is suitable, ours cost £9.99.

1 x USB Extender Cable – depending on length required, £15.00

1 x Roll of Electrical Tape

1 x Old Sock

1 x Webcam Capture Software, we used Booru Webcam 2.0 , £0.

Time Required – One Hour.

Step 1: Mounting the Webcam

The key is to house the webcam inside the torch, thus creating a unit you can leave outside in all weather while still capturing images. As such the first step is to take the torch apart, remove all the internals, unscrew the front section and pull out the reflector.

The webcam is housed inside the reflector, where the bulb used to be. To allow a snug fit simply thread the USB cable of the webcam through the hole where the bulb was and pull so the webcam is secure inside.

We tried various methods to secure the webcam but the best is to allow it to simply sit on top of an old sock, this allows the cam to remain tight in the housing while also allowing last minute adjustments. We know it sounds very low tech, but trust us it we reached this conclusion after hours of trial and error with a lot of glue and fixings.

Step 2: Wiring it Up

Drill a hole in the base of the torch and thread the USB lead through, screw back on the glass front and you are done. You should now have a torch with a webcam inside complete with a USB cable coming our the back.

Our webcam sits on the roof with the cable running down to the eves and coming into the house through a window. Our run is approximately 10 metres so we have linked up the end of the USB of the webcam to the computer using an Active USB extender.

An active USB extender is designed to allow cable runs over and above the usual 5m limit. Multiple leads may be connected up to a maximum of 3, giving a maximum cable run of up to 20m (with three active and one standard lead). We simply plugged the USB cable into the extender and wrapped the connection in electrical tape to keep out the rain.

The webcam is ready to go and ready to mount wherever has a good view. The torch we used is useful as it has a stand allowing it to point at the sky or to be mounted on a ledge. Ours is secured to a chimney pot using regular cable ties.

Step 3: Capture the Images

Timelapse images work by capturing a image few every few seconds and then stringing together the sequence to produce a movie. Our webcam is linked up to a Eee PC running Windows XP, the laptop runs almost silently which is a bonus as most timelapses run for many hours.

There are numerous software packages for capturing timelapse images, we used Booru WebCam 2.0 as its both free and one of the best available on the Windows platform. For Mac users Gawker is a free and extremely easy option to use, although note the QuickCam 9000 is not Mac friendly, it is worth taking a look at the Logitech Vision Pro instead.

The general rule is to capture an image every 5 or 10 seconds in .png format for minimum loss of quality. The images are saved in sequence ready to be merged into a usable movie, we store ours on a portable hard drive as it is all too easy to run out of disk space when capturing every 5 seconds over a 24 hour period.

Step 4: Create the Movie

There are many ways to create a movie from a series of images. The simplest way is to use QuickTime Pro which allows one to open an image sequence (file > Open > Image Sequence), set the framerate (normally 24 frames per second) and save. If you don’t wish to use QuickTime Pro then take a look at this easy to follow tutorial on using Windows Movie Maker.

Below is an example movie captured using our set up. The frames were captured as detailed above, opened in QuickTime Pro and then simply saved at 1280 x 720 for upload to Vimeo. The whole process takes approximately 15 minutes.

The aerial is in view throughout the movie above, as such you can use the digital zoom function on the webcam to zoom past the aerial, allowing a clearer view of the skyline. The movie below was created using the digital zoom:

Music: Let it Rain

If you do install a webcam in a torch and create a timelapse movie do let us know and any thoughts/question are of course welcome via the comments below.

Update – see our post on GIS Timelapse for Pedestrian Movement Analysis for an example using the Booru webcam software and timestamped images.

The post Tutorial: Torch/Flashlight + Webcam = HD Timelapse System appeared first on Digital Urban.

View Live Weather Data from London (data uploads every 3 seconds)

The post London Live Weather Data appeared first on Digital Urban.

The global data is updated every 15 minutes with the data for the UK on the local map updated every 10 seconds, allowing the 3d visualisation to morph between values.

If you have Second Life installed you can visit us by clicking here – you will get a red arrow pointing skywards, simply fly up to our section of Second Nature island.

You can download Second Life from here.

Thanks go to the guys at MesoMap for kindly letting us use the data.

The post Second Life – Global Weather Updates appeared first on Digital Urban.