DEV Community: Hauke J.

How to Add a Feedback Widget to Your Astro Site in 5 Minutes

Hauke J. — Tue, 14 Apr 2026 12:11:23 +0000

TL;DR: Drop a single <script> tag into your Astro layout. No npm install, no adapter config, no island architecture gymnastics. Works with static output, SSR, and hybrid rendering.

The Problem

You shipped your Astro site. Lighthouse score is pristine. But you have no idea what your users actually think.

Contact forms collect dust. Email links get ignored. And the one bug report you did get said "it's broken" with no context — no browser, no viewport, no screenshot.

You need a feedback channel that's right there when users hit a problem.

What You're Adding

SeggWat is an embeddable feedback widget that gives your users:

A floating feedback button (bug reports, feature requests, general feedback)
Built-in screenshot annotation (arrows, rectangles, blackout sensitive areas)
Optional star ratings, helpful ratings, and contact forms

All feedback lands in a dashboard with Kanban triage, analytics, and a public ideas portal.

No cookies. No tracking scripts. GDPR compliant by default, EU-hosted.

Prerequisites

An Astro project (v2+, any rendering mode)
A SeggWat account (14-day free trial)
Your project key from the SeggWat dashboard

Step 1: Add the Script to Your Base Layout

Astro's layout components are the perfect place for global scripts. Open your base layout (usually src/layouts/Layout.astro or src/layouts/BaseLayout.astro) and add the widget script before the closing </body> tag:

---
// src/layouts/Layout.astro
interface Props {
  title: string;
}

const { title } = Astro.props;
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <title>{title}</title>
  </head>
  <body>
    <slot />

    <!-- SeggWat Feedback Widget -->
    <script
      is:inline
      defer
      src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
      data-project-key="YOUR_PROJECT_KEY"
      data-enable-screenshots="true"
    ></script>
  </body>
</html>

Replace YOUR_PROJECT_KEY with the key from your SeggWat dashboard → Project Settings → Widgets.

That's it. Build, deploy, done.

Step 2: Customize the Widget

SeggWat uses data- attributes for configuration — no JavaScript API calls needed for basic setup. Here are the most useful options:

<script
  is:inline
  defer
  src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-enable-screenshots="true"
  data-button-color="#6366f1"
  data-button-position="bottom-right"
  data-version={import.meta.env.PUBLIC_APP_VERSION ?? "dev"}
></script>

Attribute	Default	Options
`data-button-color`	`#2563eb`	Any hex color
`data-button-position`	`bottom-right`	`bottom-right`, `right-side`, `icon-only`
`data-enable-screenshots`	`false`	`true`, `false`
`data-version`	—	Any string (e.g., `"1.2.0"`)
`data-language`	Auto-detect	`en`, `de`, `sv`
`data-show-powered-by`	`true`	`true`, `false`

Version Tracking Tip

Notice the data-version attribute above? It pulls from an environment variable. Set PUBLIC_APP_VERSION in your .env file:

PUBLIC_APP_VERSION=0.3.1

Every feedback submission gets tagged with the version, so you know exactly which release triggered a bug report.

Step 3: Add Per-Page Widgets (Optional)

Want a "Was this helpful?" widget on your docs pages? Add the helpful rating widget to specific layouts or pages:

---
// src/layouts/DocsLayout.astro
import Layout from './Layout.astro';

const { title } = Astro.props;
---

<Layout title={title}>
  <article>
    <slot />
  </article>

  <div class="feedback-section">
    <p>Was this page helpful?</p>
    <div id="helpful-widget"></div>
  </div>

  <script
    is:inline
    defer
    src="https://seggwat.com/static/widgets/v1/seggwat-helpful.js"
    data-project-key="YOUR_PROJECT_KEY"
    data-container="#helpful-widget"
  ></script>
</Layout>

This renders an inline thumbs-up/thumbs-down widget right below your content. No floating button — it sits in the page flow.

Step 4: Track Logged-In Users (Optional)

If your Astro site has authentication (via middleware, cookies, or an auth adapter), you can associate feedback with specific users:

<script
  is:inline
  defer
  src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-enable-screenshots="true"
></script>

<script>
  // After widget loads, identify the user
  document.addEventListener('DOMContentLoaded', () => {
    if (window.SeggwatFeedback) {
      window.SeggwatFeedback.setUser('user-123');
    }
  });
</script>

Now feedback submissions are tied to that user ID in your dashboard.

Works With Every Astro Rendering Mode

Mode	Works?	Notes
Static (`output: 'static'`)	✅	Script loads client-side, no adapter needed
SSR (`output: 'server'`)	✅	Same — widget is purely client-side
Hybrid (`output: 'hybrid'`)	✅	Same behavior

The widget is a client-side script — it doesn't depend on how the HTML was generated.

Works With Starlight Too

Building docs with Starlight? Override the layout to inject the widget:

---
// src/components/StarlightFeedback.astro
---

<script
  is:inline
  defer
  src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-enable-screenshots="true"
  data-button-position="bottom-left"
></script>

Then add it to your Starlight config's custom components. Now your docs site has a feedback button, and users can screenshot exactly which section confused them.

What Happens Next

Once deployed, feedback starts flowing into your SeggWat dashboard:

Triage — New feedback lands in a Kanban board. Drag from New → Active → Resolved.
Screenshots — Users' annotated screenshots show exactly what they see. No more "can you send a screenshot?"
Analytics — Track feedback trends, satisfaction scores, team response times.
Ideas Portal — Promote feature requests to a public portal where users can vote.
GitHub Integration — Create GitHub issues from ideas, with automatic status sync.

Quick Comparison

Feature	SeggWat	Contact form	Google Form	Hotjar
In-page feedback	✅	❌	❌	✅
Screenshot annotation	✅	❌	❌	❌
No cookies	✅	✅	❌	❌
Setup time	60 seconds	Varies	5+ min	10+ min
GDPR (EU-hosted)	✅	Depends	❌	❌
Starts at	$6/mo	Free	Free	$32/mo

Wrapping Up

One script tag. Real feedback with context.

Check out the full Astro example on GitHub for a working integration with dynamic controls.

→ Start your 14-day free trial

Built with Rust. Hosted in the EU. No cookies. Learn more about SeggWat.

Writing a Rust Driver for the Sensirion SEN5x Air Quality Sensor

Hauke J. — Tue, 14 Apr 2026 06:26:17 +0000

If you have ever tried to integrate an environmental sensor into a Rust embedded project, you know the drill: vendor SDKs are C-only, community crates may not exist for your specific sensor, and the datasheet is your best friend. I recently went through this with the Sensirion SEN5x module and want to share what I learned building a no_std Rust driver from scratch.

The SEN5x is a multi-sensor module from Sensirion that measures particulate matter (PM1.0, PM2.5, PM4.0, PM10), volatile organic compounds (VOC index), nitrogen oxide (NOx index), temperature, and humidity, all over a single I2C bus. That is a lot of environmental data from one package.

Here is how to build a driver for it in Rust.

What You Need

A microcontroller with I2C support (I used an RP2040, but any target with embedded-hal I2C traits works)
The SEN5x module (SEN50, SEN54, or SEN55 -- the communication protocol is identical)
A Rust toolchain with your target configured (thumbv6m-none-eabi for RP2040, thumbv7em-none-eabihf for STM32, etc.)

Your Cargo.toml dependencies will look something like this:

[dependencies]
embedded-hal = "1.0"

We are intentionally keeping dependencies minimal. The driver itself only needs embedded-hal traits.

Understanding the SEN5x I2C Protocol

The SEN5x uses Sensirion's standard I2C protocol, which has a few quirks compared to a typical I2C device:

Commands are 16-bit. You send two bytes for each command, MSB first.
Every data word is 3 bytes. Two bytes of data followed by a CRC-8 checksum.
Timing matters. Some commands need execution delays before you can read the response.

This means a typical exchange looks like:

Write: [cmd_msb, cmd_lsb]
Wait: execution time
Read:  [data_hi, data_lo, crc, data_hi, data_lo, crc, ...]

The CRC-8 Implementation

Sensirion uses CRC-8 with polynomial 0x31 and initial value 0xFF. This is the first thing to implement because every data word needs CRC validation:

fn crc8(data: &[u8]) -> u8 {
    let mut crc: u8 = 0xFF;
    for &byte in data {
        crc ^= byte;
        for _ in 0..8 {
            if crc & 0x80 != 0 {
                crc = (crc << 1) ^ 0x31;
            } else {
                crc <<= 1;
            }
        }
    }
    crc
}

This runs on any no_std target with no allocations. Fast and predictable.

Structuring the Driver

I like to structure embedded drivers around the embedded-hal traits so they work on any platform. The core struct is generic over the I2C implementation and a delay provider:

use embedded_hal::i2c::I2c;
use embedded_hal::delay::DelayNs;

const SEN5X_ADDR: u8 = 0x69;

pub struct Sen5x<I2C, D> {
    i2c: I2C,
    delay: D,
}

impl<I2C, D> Sen5x<I2C, D>
where
    I2C: I2c,
    D: DelayNs,
{
    pub fn new(i2c: I2C, delay: D) -> Self {
        Self { i2c, delay }
    }
}

The default I2C address for SEN5x is 0x69. It is not configurable -- every SEN5x module uses this address.

Sending Commands

Every command follows the same pattern: write two bytes, optionally wait, optionally read back data. Let us build a helper:

impl<I2C, D> Sen5x<I2C, D>
where
    I2C: I2c,
    D: DelayNs,
{
    fn write_command(&mut self, command: u16) -> Result<(), I2C::Error> {
        let bytes = command.to_be_bytes();
        self.i2c.write(SEN5X_ADDR, &bytes)
    }

    fn read_words_no_alloc(
        &mut self,
        command: u16,
        delay_us: u32,
        buf: &mut [u16],
    ) -> Result<(), Error<I2C::Error>> {
        self.write_command(command)
            .map_err(Error::I2c)?;

        self.delay.delay_us(delay_us);

        let num_words = buf.len();
        let mut raw = [0u8; 24];
        let read_len = num_words * 3;
        self.i2c
            .read(SEN5X_ADDR, &mut raw[..read_len])
            .map_err(Error::I2c)?;

        for (i, chunk) in raw[..read_len].chunks(3).enumerate() {
            let crc = crc8(&chunk[..2]);
            if crc != chunk[2] {
                return Err(Error::Crc);
            }
            buf[i] = u16::from_be_bytes([chunk[0], chunk[1]]);
        }

        Ok(())
    }
}

This no_std-friendly version uses a fixed-size stack buffer. No heap allocations, no alloc crate needed.

Error Handling

A proper driver needs a clear error type:

#[derive(Debug)]
pub enum Error<E> {
    /// I2C bus error
    I2c(E),
    /// CRC checksum mismatch
    Crc,
    /// Command not allowed in current state
    NotAllowed,
    /// Sensor reported internal error
    Internal,
}

The error is generic over the I2C error type so you get the platform's original error information propagated through. NotAllowed catches invalid command sequences (for example, reading measurements before starting them), and Internal surfaces faults reported by the sensor itself. Enable the thiserror feature for std::error::Error integration, or defmt for embedded-friendly formatting.

Reading Measurements

The SEN5x measurement flow is: start measurement, wait for data-ready, read the values. Here are the key commands:

Command	Code	Description
Start Measurement	`0x0021`	Begin continuous measurement
Stop Measurement	`0x0104`	Stop measurement mode
Data Ready	`0x0202`	Check if new data is available
Read Measured Values	`0x03C4`	Read all sensor values

Putting it together:

pub struct SensorData {
    pub mass_concentration_pm1p0: f32,
    pub mass_concentration_pm2p5: f32,
    pub mass_concentration_pm4p0: f32,
    pub mass_concentration_pm10p0: f32,
    pub ambient_humidity: f32,
    pub ambient_temperature: f32,
    pub voc_index: f32,
    pub nox_index: f32,
}

impl<I2C, D> Sen5x<I2C, D>
where
    I2C: I2c,
    D: DelayNs,
{
    pub fn start_measurement(&mut self) -> Result<(), Error<I2C::Error>> {
        self.write_command(0x0021).map_err(Error::I2c)?;
        self.delay.delay_ms(50);
        Ok(())
    }

    pub fn data_ready(&mut self) -> Result<bool, Error<I2C::Error>> {
        let mut buf = [0u16; 1];
        self.read_words_no_alloc(0x0202, 20_000, &mut buf)?;
        Ok(buf[0] & 0x01 != 0)
    }

    pub fn measurement(&mut self) -> Result<SensorData, Error<I2C::Error>> {
        let mut words = [0u16; 8];
        self.read_words_no_alloc(0x03C4, 20_000, &mut words)?;

        Ok(SensorData {
            mass_concentration_pm1p0: words[0] as f32 / 10.0,
            mass_concentration_pm2p5: words[1] as f32 / 10.0,
            mass_concentration_pm4p0: words[2] as f32 / 10.0,
            mass_concentration_pm10p0: words[3] as f32 / 10.0,
            ambient_humidity: words[4] as i16 as f32 / 100.0,
            ambient_temperature: words[5] as i16 as f32 / 200.0,
            voc_index: words[6] as f32 / 10.0,
            nox_index: words[7] as f32 / 10.0,
        })
    }
}

A few things to note about the value scaling:

mass_concentration_pm* values are unsigned 16-bit divided by 10 (unit: ug/m3)
ambient_temperature is signed 16-bit divided by 200 (unit: degrees Celsius)
ambient_humidity is signed 16-bit divided by 100 (unit: %RH)
voc_index and nox_index are unsigned 16-bit divided by 10 (dimensionless index)

The signed/unsigned distinction is important. Casting a u16 to i16 before converting to f32 handles the two's complement correctly for temperature and humidity values.

Using the Driver

Here is what the application code looks like on an RP2040:

#![no_std]
#![no_main]

use rp2040_hal as hal;
use hal::i2c::I2C;
use hal::Timer;
use defmt_rtt as _;
use panic_probe as _;

#[hal::entry]
fn main() -> ! {
    let mut pac = hal::pac::Peripherals::take().unwrap();
    let sio = hal::Sio::new(pac.SIO);
    let pins = hal::gpio::Pins::new(
        pac.IO_BANK0,
        pac.PADS_BANK0,
        sio.gpio_bank0,
        &mut pac.RESETS,
    );

    let i2c = I2C::i2c0(
        pac.I2C0,
        pins.gpio4.into_function(),  // SDA
        pins.gpio5.into_function(),  // SCL
        400.kHz(),
        &mut pac.RESETS,
        125.MHz(),
    );

    let timer = Timer::new(pac.TIMER, &mut pac.RESETS);
    let mut sensor = Sen5x::new(i2c, timer);

    sensor.start_measurement().unwrap();

    loop {
        if sensor.data_ready().unwrap() {
            let m = sensor.measurement().unwrap();
            defmt::info!(
                "PM2.5: {} ug/m3, Temp: {} C, Humidity: {} %RH, VOC: {}",
                m.mass_concentration_pm2p5, m.ambient_temperature, m.ambient_humidity, m.voc_index
            );
        }
        // SEN5x updates roughly every 1 second
        timer.delay_ms(1000);
    }
}

Clean, readable, and fully type-safe. No unsafe blocks, no C FFI, no raw pointer arithmetic.

Testing with Mock I2C

The embedded-hal-mock crate lets you write unit tests for your driver on your development machine. You define expected I2C transactions and the mock verifies them:

#[cfg(test)]
mod tests {
    use super::*;
    use embedded_hal_mock::eh1::i2c::{Mock as I2cMock, Transaction as I2cTransaction};
    use embedded_hal_mock::eh1::delay::NoopDelay;

    #[test]
    fn test_crc8() {
        assert_eq!(crc8(&[0xBE, 0xEF]), 0x92);
        assert_eq!(crc8(&[0x00, 0x00]), 0x81);
    }

    #[test]
    fn test_data_ready() {
        let expectations = vec![
            I2cTransaction::write(SEN5X_ADDR, vec![0x02, 0x02]),
            I2cTransaction::read(SEN5X_ADDR, vec![0x00, 0x01, crc8(&[0x00, 0x01])]),
        ];
        let i2c = I2cMock::new(&expectations);
        let delay = NoopDelay::new();
        let mut sensor = Sen5x::new(i2c, delay);

        assert!(sensor.data_ready().unwrap());
    }
}

This catches protocol bugs before you flash hardware. Highly recommended.

Lessons Learned

1. Always validate CRC. I2C buses in real hardware are noisy. I initially skipped CRC checks during development and got intermittent garbage readings that were hard to debug. CRC validation catches these immediately.

2. Respect the timing. The SEN5x datasheet specifies minimum delays between sending a command and reading the response. Skipping these delays causes NACK responses. The delays are not optional.

3. The embedded-hal 1.0 migration was worth it. If you are still on embedded-hal 0.2, the I2c trait in 1.0 is cleaner and combines read/write/write-read into a single trait. The migration is straightforward and the result is more ergonomic.

4. Test with mock I2C. You can write and validate your entire driver logic without touching hardware. This speeds up development significantly.

What About Existing Crates?

You might find existing SEN5x crates on crates.io. Before reaching for one, consider whether it targets embedded-hal 1.0 (released stable in early 2024). Many embedded sensor crates still target 0.2, and mixing HAL versions in one project creates compatibility headaches. Building your own driver is also an excellent way to understand the sensor's protocol deeply, which helps when debugging real hardware issues.

Wrapping Up

The Sensirion SEN5x is a capable module that packs a lot of environmental sensing into a single I2C device. Rust's embedded-hal ecosystem makes it straightforward to write a portable driver that works across microcontroller families.

The combination of strong typing, zero-cost abstractions, and no_std support makes Rust genuinely productive for embedded sensor work. No runtime overhead, no hidden allocations, and the compiler catches protocol mistakes at build time instead of at 3 AM when your sensor readings go wrong.

If you are working on IoT or environmental monitoring projects in Rust, I would love to hear about your setup. Drop a comment or find me on GitHub.

Follow me for more embedded Rust content and practical driver guides. You can also check out oxidt.com for more articles on Rust development.