nip/weather-data #2163

samthomson · 2025-12-17T18:40:27Z

DRAFT & WIP

I've started playing around with building weather stations. I will keep building / refining (with others - you?) the next months.
It makes sense to be to have one kind for the weather station and one kind for each weather station reading. (A list of weather stations eg I operate, could also be handy - put that doesn't need to be reinvented here).
Wisdom / collaboration is welcome, and appreciated 🙏
You can see some data being consumed here (from a proto kind): https://weather.shakespeare.wtf

vitorpamplona · 2025-12-17T18:44:29Z

Move the json in content to tags to get rid of yet another parser

derekross · 2025-12-17T18:46:47Z

i look forward to having weather stations all over the world. you should also link the PoC website.

samthomson · 2025-12-17T18:47:30Z

thanks @vitorpamplona. I first thought to have everything in tags, but then thought I'd put some high level things in tags and then fine grained data in content/json. Do you think its ok to have potentially a whole bunch of tags?

vitorpamplona · 2025-12-17T18:55:41Z

Do you think its ok to have potentially a whole bunch of tags?

Yep. That's ok. We have events with over 5000 tags.

vitorpamplona · 2025-12-17T18:56:12Z

nip-weather.md

+  "kind": 23415,
+  "tags": [
+    ["s", "<station-id>"],
+    ["a", "16428:<pubkey>", "<relay-url>"]


this a needs to have a second : 16428:<pubkey>:

vitorpamplona · 2025-12-17T18:59:26Z

nip-weather.md

+
+### Event Kind Range for Readings
+
+Currently `kind:23415` is ephemeral (20000-29999), meaning relays are not expected to store readings. Should readings use regular events (1000-9999) instead to enable historical data queries and trend analysis? Tradeoff: storage burden vs. historical value.


You could use a 30xxx event where the d tag is the station-id. In that way relays will always save the current temp (so people can check the temp right now) and those subscribed to the temp changes can save all the versions of the 30xxx event.

I'd like to query a relay and get all the weather data from the last hour or day though, which makes me think regular events (1000-9999) would be best. wdyt?

Yep. If you need to get a collection of them, then regular events (potentially with an expiration tag) are better.

alltheseas · 2025-12-25T03:03:19Z

why not: consider g tag/geohash for location, as defined in nip-52.

https://grokipedia.com/page/Geohash

samthomson · 2025-12-27T04:21:30Z

@alltheseas good idea. Updated.

alltheseas · 2025-12-27T05:37:47Z

A few more comments:

I see kind-30001 - NIP-51.md calls this kind deprecated. Not sure what the right kind is. Maybe this is a new weather-station specific kind? You mention this can be sorted at the end, so that works.
Since weather station/measurements are distinct/new kinds to all of nostr, NIP-31 alt tag could be useful to advise what this is.
Add pressure - dont recall what the real world unit of measurement is (mb?)
Add wind speed (kt/knots)
Add wind direction (see https://windy.app/blog/what-is-wind-direction.html)
add rain (in/mm)
add waves - significant wave height (ft/m) and period (seconds)
add wave direction (can use same approach as wind direction)
dealing with broken/faulty sensors - what happens if a sensor fails? what's the notation for null/no data?
timestamps - the happy path here is that the nostr JSON blob created at timestamp is also the timestamp for the observed data. An unhappy paths is that we have an offline weather station for whatever reason, which could mean that when back online the station publishes data observed at a different time and/or mass/batch submits stored / recorded data etc.

In a standard kind-1 note we have the following example: "created_at": 1766813498,
which per NIP-01 is defined as "created_at": <unix timestamp in seconds>.

So maybe we add a "observed_at": <unix timestamp in seconds> in the case of unhappy paths of JSON creation timestamp differing from met station observation timestamp.

vitorpamplona · 2025-12-27T14:31:50Z

Re NIP-51, you probably want to choose your own kind for this.

alltheseas · 2025-12-27T23:05:16Z

On wave height - on second thought metocean sensors should be assumed to record, and share raw data. Therefore wave height should be just raw wave height, not significant wave height. Hs can be calculated after.

hzrd149

I know you didn't ask for a review, but I figured I would offer some feedback.

all-in-all I really like the idea and it would be cool to start seeing weather data show up on nostr relays

hzrd149 · 2025-12-30T21:39:39Z

nip-weather.md

+```
+
+Tags:
+- `t` (optional): Hashtag for discovery. SHOULD include `["t", "weather"]` for relay indexing.


if the event kind is set in this nip then there shouldn't be need for a hashtag. clients should be able to just query for the event kind

agree, it's redundant.

hzrd149 · 2025-12-30T21:41:28Z

nip-weather.md

+
+Tags:
+- `t` (optional): Hashtag for discovery. SHOULD include `["t", "weather"]` for relay indexing.
+- `a` (optional): Reference to the station metadata event (`10xxx:<pubkey>:` - note trailing colon for replaceable events). This links the reading to its station.


The station metadata event is a single replaceable event presumably signed by the same pubkey so I don't really see the point in including an a tag since it will always be easier to lookup the station metadata by the events author

agree, obsolete.

hzrd149 · 2025-12-30T22:05:18Z

nip-weather.md

+  - `air_quality`: Raw analog sensor value (0-1023, uncalibrated)
+  - Other sensor tags as needed
+
+The third parameter (model) identifies the sensor model (e.g., "DHT11", "PMS5003", "MQ-135"), enabling:


It would be good to define if this string follows a specific format or is just generally human readable.
If its designed to be aggregated across stations then it would be good to have it standardized so there is as much interoperability as possible

you mean like a const/enum of sensor types? ie allowed values only?

hzrd149 · 2025-12-30T22:06:00Z

nip-weather.md

+
+## Discovery
+
+The `["t", "weather"]` hashtag is optional but recommended in reading events to enable relay indexing and discovery of weather stations. Clients can discover weather data by querying for `{"#t": ["weather"]}`.


This doesn't really make sense to me, couldn't they just discover the sensor data by querying for the 4223 kind?

hzrd149 · 2025-12-30T22:07:44Z

nip-weather.md

+- `t` (optional): Hashtag for discovery. SHOULD include `["t", "weather"]` for relay indexing.
+- Other tags as needed
+
+To group multiple stations together, use [NIP-51](51.md) lists. `kind:30001` (generic lists) can be used with `p` tags referencing station pubkeys. Example:


I'm not sure grouping stations needs to be part of this nip. I don't see any harm in it though

Thanks, please see my response above to elsat and kindly share any thoughts you have.

hzrd149 · 2025-12-30T22:08:43Z

nip-weather.md

+
+Tags:
+- `name` (optional): Human-readable station name
+- `g` (optional): Geohash for location indexing (see [NIP-52](52.md))


I don't remember which nip it was defined in but it would be good to define if this is a single g tag or one g tag per geohash level

Including a g tag for each level makes it possible to easily lookup events by location with the current NIP-01 filters

not a bad idea, thanks

samthomson · 2026-01-02T09:10:46Z

@alltheseas Thanks a lot for such a thorough set of thoughts.

1 - nip-51/kind-30001. I thought a way to group stations together could be handy. some usecases/context that come to mind: to see 'my' stations (each has its own private key so [author = me] isn't a fit), or all the stations in my town so that I can crunch pollution data over time that's relevant to me, or all the stations at a running route or across running routes so I can plan where to jog that day. Thoughts welcome on what could be best here. I thought 30001 as a 'custom list' type could save creating another type in nip-51 (but maybe adding more types isn't such a bad thing?). For now I'll placeholder a new 3**** custom set in nip-51.

2 - Good idea with the alt tag. Do you think just a 'Weather station data' or 'Weather station reading' is enough? I could make a literal 'Weather reading: 22.5°C, 65% humidity' otherwise, but I'm conscious that would - at one reading a minute - add up to a lot of data over time. Thoughts welcome.

3/6 - Rain/Pressure - on the list, thanks. I've added a table showing all sensors working / in progress.

4/5/7/8 - Added to the list, as proposed.

9 - I see two things here.
a)The reading event could for the failed sensor either not record that sensor, or it could record it with an intentional null value. I think omitting it makes most sense (in conjunction with b).
b) Separately the weather station could have either a 'broken' value on that sensor tag, or it could separatley have tags for 'sensor_status' or 'broken_sensor'. I think sensor_status could be best. ok, offline, error. maybe even 200, 400, 500 (or I'm overthinking).

10 - Very good point. Observed_at makes sense. I would guess the majority of the time created_at === observed_at, meanings lots of duplicate data. Do you think that's ok or we'd just add the observed_at to the event if publishing failed. or wdyt?

samthomson · 2026-01-02T09:41:02Z

@hzrd149 thanks a lot for your review. very valuable. I have updated accordingly and will udpate my wip weather station code tonight.

alltheseas · 2026-01-02T14:14:14Z

@alltheseas Thanks a lot for such a thorough set of thoughts.

1 - maybe adding more types isn't such a bad thing?). For now I'll placeholder a new 3**** custom set in nip-51.

I think new kind(s) are fine. @arcbtc @BenGWeeks did y'all have some IOT related kinds at some point on nostr? @fiatjaf was your dishwasher npub just kind-1?

2 - Good idea with the alt tag. Do you think just a 'Weather station data' or 'Weather station reading' is enough?

Short and descriptive seems fine.

10 -Observed_at makes sense. I would guess the majority of the time created_at === observed_at, meanings lots of duplicate data. Do you think that's ok or we'd just add the observed_at to the event if publishing failed. or wdyt?
I would guess the majority of the time created_at === observed_at, meanings lots of duplicate data.

The timestamp a measurement was observed at is half of the measurement. Without the timestamp the measurement loses its' value.

It is necessary to have this separate from the nostr posting time.

Here we are ensuring that data recorded/submitted via unhappy paths remains valuable, and does not lose fidelity:

e.g. solar powered node that goes down overnight, or for a few days if there is no sun,
Internet/satellite/cell goes down,
nostr relay(s) go down, not accepting data for whatever reason,
weather node outbound comms, or other failure.

The more remote the weather station, the more exotic the destination and setup, the more resources & effort it takes to go and fix it, should it go down. If it can keep recording data while not being able to transmit it, and/or not lose data that has not been transmitted, this should reduce the station maintainer headaches by not losing crucial measurement data in time.

By virtue of the distinction between created_at and observed_at the station maintainer can also spot irregular patterns in node behavior, node transmittal behavior.

BenGWeeks · 2026-01-02T18:58:27Z

@alltheseas Thanks a lot for such a thorough set of thoughts.
1 - maybe adding more types isn't such a bad thing?). For now I'll placeholder a new 3**** custom set in nip-51.

I think new kind(s) are fine. @arcbtc @BenGWeeks did y'all have some IOT related kinds at some point on nostr? @fiatjaf was your dishwasher npub just kind-1?

I haven't published any IoT-related kinds that I recall, but I did build a "Mars BioPod" project (LED grow lights + aquaponics with trout) that had air temperature sensors but most taken manually. They were constructed out of IBC containers wth soil-less grow beds and Nasa research derived LEDs (of wavelengths for photosynthesis). Before the days of Nostr though.I would have loved to also log:

pH
Water temperature
Dissolved oxygen
Ammonia/nitrite/nitrate levels

Basically the nitrogen cycle metrics you need for aquaponics.

I did just ditch my Netatmo weather station - yet another subscription service (and wanted something I could plug into Home Assist). Would be great to have a Nostr baed solution.

I also worked briefly with an agri company that were interested in various soil metrics (forget exactly which now) for farmers.

Looking at this draft, the tag-based approach (temperature, humidity, pressure) seems extensible enough to accommodate water quality sensors with the same pattern. Might be worth considering whether this could be Environmental Sensor Data rather than strictly Weather Station Data - or at least designed with that extensibility in mind for agricultural/aquaponics IoT use cases - although on the flip side you might want to differentiate between water temperature in a [controlled] fish tank, and the middle of the Atlantic).

alltheseas · 2026-01-21T17:38:00Z

I am exploring iNaturalist inspired crowdsourced environmental reporting app. Draft plan builds partially off draft weather station NIP:

https://github.com/alltheseas/bluesky-observer

samthomson · 2026-01-23T09:56:33Z

I am exploring iNaturalist inspired crowdsourced environmental reporting app. Draft plan builds partially off draft weather station NIP:

https://github.com/alltheseas/bluesky-observer

Very interesting indeed. Great stuff.

first draft

5172534

samthomson marked this pull request as draft December 17, 2025 18:40

vitorpamplona reviewed Dec 17, 2025

View reviewed changes

samthomson added 4 commits December 19, 2025 23:56

move all data to tags from json/content

8b61146

fix - add trailing tag for replaceable's a

bf6968f

change kinds (to temp)

0dc11a0

add temp kinds

3fd4849

samthomson added 4 commits December 26, 2025 05:08

updated tag format to include sensor model

8c2741e

++

83493ac

added geohash docs and power/connectivity tag docs

439b10d

+

16a92a0

samthomson added 2 commits December 27, 2025 11:26

remove old location prop

d2cf45e

updated info on client implementation

e52921f

hzrd149 reviewed Dec 30, 2025

View reviewed changes

samthomson added 5 commits January 2, 2026 14:43

propose a custom nip51 list type instead of deprecated kind-30001

46a52b2

todo: alt tags

d96661d

add current sensors I'm working on plus other proposed (wind/wave)

df9c208

todo: handle broken vlaues

1f98345

what about offline stations timestamps?

383bf6b

samthomson added 4 commits January 2, 2026 16:15

remove redundant tag for discovery

380eeef

remove rudundant a tag

8474854

future idea - aggregate stations

08b8ed5

support multilevel geohashes

e223a2e

add description prop/tag to weather station meta event

ce949bb


		### Event Kind Range for Readings

		Currently `kind:23415` is ephemeral (20000-29999), meaning relays are not expected to store readings. Should readings use regular events (1000-9999) instead to enable historical data queries and trend analysis? Tradeoff: storage burden vs. historical value.


		## Discovery

		The `["t", "weather"]` hashtag is optional but recommended in reading events to enable relay indexing and discovery of weather stations. Clients can discover weather data by querying for `{"#t": ["weather"]}`.

nip/weather-data #2163

Are you sure you want to change the base?

nip/weather-data #2163

Uh oh!

Conversation

samthomson commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vitorpamplona commented Dec 17, 2025

Uh oh!

derekross commented Dec 17, 2025

Uh oh!

samthomson commented Dec 17, 2025

Uh oh!

vitorpamplona commented Dec 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alltheseas commented Dec 25, 2025

Uh oh!

samthomson commented Dec 27, 2025

Uh oh!

alltheseas commented Dec 27, 2025

Uh oh!

vitorpamplona commented Dec 27, 2025

Uh oh!

alltheseas commented Dec 27, 2025

Uh oh!

hzrd149 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

samthomson commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samthomson commented Jan 2, 2026

Uh oh!

alltheseas commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BenGWeeks commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alltheseas commented Jan 21, 2026

Uh oh!

samthomson commented Jan 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

samthomson commented Dec 17, 2025 •

edited

Loading

samthomson commented Jan 2, 2026 •

edited

Loading

alltheseas commented Jan 2, 2026 •

edited

Loading

BenGWeeks commented Jan 2, 2026 •

edited

Loading