IoT Internet of Things on Nostr (NIP 107)

[arcbtc]

The terms/conditions of IoT software/hardware are horrible. Nostr gives the simple, permissionless development environment IoT needs so it can move away from its current Orwellian paradigm.
A user should be able to message a light, heating, speaker and ask it to turn on/off over nostr.

[vitorpamplona]

I would not do a JSON in a NIP-04.

What about a new event kind?

{
  "kind": 30107,
  "created_at": 1675642635,
  "content": "",
  "tags": [
    ["d", "<String, UUID of the stall to which this device belong to>"],
    ["name", "<String, device name>"],
    ["description", "<String (optional), device description>"],
    ["t", "<category 1>"],
    ["t", "<category 2>"],
    ["t", "<category 3>"],
    ["p", "<User 1 pubkey in hex>"],
    ["p", "<User 2 pubkey in hex>"],
    ["image", "<URLs>"],
  ],
  "pubkey": "...",
  "id": "..."
}

This is a replaceable event, so no need for custom update logic.

[fiatjaf]

I think it would be nice to have a kinds for generic actions often performed by IoT devices -- which to me seem to be basically notifications of intents or information.

Would be nice to gather a list of things IoT devices often do and standardize the most common cases -- such that there is interoperability.

For example:

3400: on/off -> an event stating that a device is turning on or off
3401: temperature -> an event containing the temperature
3402: lighting -> an event containing the intensity of the lighting detected
3403: movement -> etc
3404: voice -> etc

For example, if a device gathers temperature data it can emit an event of kind 3401 with temperature 39°C, then another device can be configured to react to temperature events from a fixed list of public keys or anything that comes from a specific relay or anything that comes from a public key attested with a NIP-32 event from someone trustworthy and so on, and then turn itself on or off.

Since these events are interoperable it becomes very easy to plug in new devices to the scheme, replace devices and so on -- but it also allows for nicer ideas not yet invented, like gathering the temperature in the entire world from these public events (?) or maybe doing some silly experiments, I don't know.

[isaac-asdf]

I think there are too many possible IoT type devices/commands to encapsulate each as a separate kind number. If anything, we could have one kind for a sensor and a separate for a controller. I think tags seems like the place to put things like units, “kind” of input for sensors (temp vs pressure) and geohash data

…

On Tue, Oct 10, 2023 at 7:09 PM fiatjaf_ ***@***.***> wrote: I think it would be nice to have a kinds for generic actions often performed by IoT devices -- which to me seem to be basically notifications of intents or information. Would be nice to gather a list of things IoT devices often do and standardize the most common cases -- such that there is interoperability. For example: 3400: on/off -> an event stating that a device is turning on or off 3401: temperature -> an event containing the temperature 3402: lighting -> an event containing the intensity of the lighting detected 3403: movement -> etc 3404: voice -> etc For example, if a device gathers temperature data it can emit an event of kind 3401 with temperature 39°C, then another device can be configured to react to temperature events from a fixed list of public keys or anything that comes from a specific relay or anything that comes from a public key attested with a NIP-32 event from someone trustworthy and so on, and then turn itself on or off. Since these events are interoperable it becomes very easy to plug in new devices to the scheme, replace devices and so on -- but it also allows for nicer ideas not yet invented, like gathering the temperature in the entire world from these public events (?) or maybe doing some silly experiments, I don't know. — Reply to this email directly, view it on GitHub <#814 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXFPMRUU7FPRPUSEXUBZMWTX6XPSJAVCNFSM6AAAAAA527XJRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJWGQ4DOOBZHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[erskingardner]

I agree that this should be a new kind (or kinds), with an encrypted content field so that you can keep the commands/data private.

ACK to @isaac-asdf idea on kinds for sensor & controller but not a new kind for every conceivable type of data or command.

[motorina0]

Basic IoT usecase

I'm adding this diagram as a common ground for discussion

• Thermostat and Controller are devices that listen for and publish events
• each device has its own key-pair
• a device's software can be flashed (installed) and configured via a web-installer (see https://bitcoinswitch.lnbits.com/). The configuration:
  • MUST include at least the private key for the device
  • SHOULD include a list of accepted public keys from which it accepts commands (so your neighbour cannot stop the heating during the night)
• a device can publish
  • its state at regular intervals or when a change occurs (eg: publish temperature every 5 minutes and/or when the value changes)
  • a command as part of its state changing (eg: thermostat sends on/off command)
• a device can subscribe for events that change its config (eg: update settings, turn on/off)

Notes:

• this is just one of the many possible flows. An alternative is that the Thermostat only publishes its temperature and the Controller manages the settings (what the state should be based on current date and temperature)
• the user can also manually turn on/off the heater
  • in this case the controller should accept events from two public keys (user and thermostat)
• a mechanism should exist for synchronising the date&time across devices (so old events can be discarded)

[motorina0]

Is there an IoT expert around that can point us to some data structure standards?
All I could find is this (which is as ugly as a giant BIP) https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

[fiatjaf]

I think there are too many possible IoT type devices/commands to
encapsulate each as a separate kind number. If anything, we could have one
kind for a sensor and a separate for a controller. I think tags seems like
the place to put things like units, “kind” of input for sensors (temp vs
pressure) and geohash data

I don't think this is true. Most use cases can probably be covered by standardized kinds, and we can add more kinds as necessary.

If this was true, though, then there would be little point in using Nostr as each device would have to be programmed with custom rules anyway.

[motorina0]

I don't think this is true. Most use cases can probably be covered by standardized kinds, and we can add more kinds as necessary.

• a tag should solve this issue
• kinds are kind of scarce (since they are ints in a given interval)

[fiatjaf]

Tags give the idea that anyone can write anything there, which is not what we want (again, if everybody does that then Nostr is useless). We need standardization and interoperability, kinds are much more efficient for that (it's better for relays and indexing and uses less space and everything is faster if we have a different kind for each thing).

Given that we want interoperability and standardization, 1000 kind numbers seem more than enough. If we have more than that we will not be able to coordinate the standards anyway.

[motorina0]

@vitorpamplona regarding:

I would not do a JSON in a NIP-04.
What about a new event kind?

• I think a replaceable parametrized event (like 30107) makes sense for changing the state of a device (settings, on/off, etc)
• but in some cases the user might want to keep the event history (which is lost for 30xxx events).
  • eg: I want to see how much my solar panels produced in a time interval (at what hour they produce more so I can start more appliances), which month of the year is best, etc.

[vitorpamplona]

Sure, if you want to keep the history, regular events make sense. You can even use an unbound list to group them by streams #784

Kinds are not scarce. Don't be fooled by ranges. We can increase them at any time. I encourage implementers to do a new kind for every IoT set.

[blackcoffeexbt]

I like both approaches, a single kind and multiple and see arguments for both. Whilst kinds are scarceish, I do agree with @fiatjaf that a per sensor type kind is probably going to be most useful for iot devices and relay filtering.

Being able to REQ and respond to one kind for a sensor type is very useful for low memory and bandwidth iot devices. (e.g. esp8266).

Can we block out an int range for kinds for this nip? E.g. 30107 to 31106?

[fiatjaf]

Yes, let's block a thousand kinds for this and start listing and specifying the most common formats.

[blackcoffeexbt]

Here's some sensor types to start with:

• Temperature
• Humidity
• Pressure
• Light
• Rain
• Moisture
• Location
• Switch - This could be PIR, a pysical switch, tilt or motion switch

I'd suggest that the NIP should include a table with:

Data type	Event Kind	Data Type	Unit	Example
temperature	30109	int	celcius	20.9
pressure	30110	int	pascals	1013
location	30111	array	decimal degrees	[51.5053, -0.08737]

We will also need to reserve a kind for commands e.g. setting a switch state or motor speed / duration. We could reserve 30107 for commands, and other kinds for sensor data.

Here's an example of the data structure of the content property could be used. I've included metadata in the example below. It could be dropped or be an optional property.

{
    "version": "1.0",
    "deviceId": "[unique device ID. Needed as one pub key might be used to broadcast data for multiple sensors e.g. when using LoRa]",
    "eventType": "[data" OR "command]",
    "title": "[A friendly sensor name e.g. 'Living Room Temperature']",
    "value": [the sensor or command value e.g. 23.5 or 1],
    "metadata": {
        "batteryLevel": 95,
        "signalStrength": -70
    }
}

[Charlie67j]

I'm curious what the intended usage case might be or what problem this solves that isn't already solved by MQTT and the Sparkplug B standard? Many MQTT servers are bridgeable to relay data between them and it's simple to do. There are FOSS options and encryption is quite simple to accomplish for data in flight. Is this intended as an on/off ramp to allow interacting with an IoT device through relays? If so, why not leverage MQTT and make a client bridge wrapper for it? How is this better/different than the current self-hosted and FOSS options? Not intending to be a jerk here, just curious if I'm missing the point.

[fiatjaf]

@Charlie67j where are the specs for the MQTT thing?

I think Nostr adds the public key infrastructure needed to make this a really open thing, while MQTT-based stuff must necessarily be closed. Also Nostr relays are much easier to setup and they are already being used for other things, which makes integration seamless. It also makes a lot of sense.

Let me reverse the question: if the MQTT solution works for IoT, why can't we ditch Nostr entirely and just use MQTT for social networking?

[fiatjaf]

I've opened this new PR incorporating @blackcoffeexbt's ideas and how I'm seeing this: #817

[shaibearary]

Is there an IoT expert around that can point us to some data structure standards? All I could find is this (which is as ugly as a giant BIP) https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

i dont think there is such thing and i create sdk one by one when there is a new type of sensor coming with different format and collect them all to same format for visualization/further analysis

[shaibearary]

I'm curious what the intended usage case might be or what problem this solves that isn't already solved by MQTT and the Sparkplug B standard? Many MQTT servers are bridgeable to relay data between them and it's simple to do. There are FOSS options and encryption is quite simple to accomplish for data in flight. Is this intended as an on/off ramp to allow interacting with an IoT device through relays? If so, why not leverage MQTT and make a client bridge wrapper for it? How is this better/different than the current self-hosted and FOSS options? Not intending to be a jerk here, just curious if I'm missing the point.

for mqtt you need a mqtt server
mqtt is a pub-sub protocol. server/client dont store data and dont accept time filter or tag filter, it filter by topic and some legacy authentation instead of sign-verify. think about it when you subscribe a data with sensor id, you cannot know if its published by sensor or just a fake data. same when you write back to sensor to adjust setting
https://mqtt.org/mqtt-specification/

[blackcoffeexbt]

@arcbtc giftwrapping could be used to protect metadata but it will remove the ability to filter on tags before decrypting the event.

https://github.com/nostr-protocol/nips/blob/fd914c600fd590e6188534cd7555116da7855503/59.md

[motorina0]

@arcbtc giftwrapping could be used to protect metadata but it will remove the ability to filter on tags before decrypting the event.

I think we're working with the social-network mindset in mind here (and we should not).
Filtering events by tags and kinds is not a requirement (or useful).

Scenario:

• the user has a mobile/web app for monitoring & controlling its IoT devices
• the app has the pubkeys for all of the user's devices
• the app queries for (NIP04) events based on those pubkeys alone
• the app aggregates the data in a nice format (tables, charts).
• the app caches the the current stated and upgrade the UI based on new received DMs

Tag like fields (eg: categories: ["boiler"]) can be part of the JSON which is inside the DM.

[v0l]

Please add data-type for radiation as cpm

[v0l]

I have started to publish my weather station data on kind 8001, you can see it here:
nak req -k 8001 -l 10 wss://relay.snort.social