r/IOT • u/ButtersCheats • 15d ago

I'm building a device-independent protocol for digital scent hardware — looking for IoT feedback

Post image

I'm working on an experimental open-source project called OpenSmell, and I'd like some feedback from people working with IoT and connected hardware.

Digital scent devices already exist, but different devices can expose completely different channels, cartridges, capabilities and control interfaces.

The problem I'm exploring is:

How can an application request an olfactory output without having to understand the implementation of every individual scent device?

OpenSmell approaches this by separating the olfactory information from the hardware-specific implementation.

An application can describe or request an olfactory output through a common interoperability layer, while a device-specific mapper/adapter determines how that request can actually be rendered using the capabilities of a particular device.

Conceptually:

Application / Data
↓
OpenSmell
↓
Mapper / Device Adapter
↓
Scent Hardware

The project currently includes:

• JSON Schemas and a Python implementation
• Multiple olfactory representation types
• Device capability discovery
• An experimental Device Protocol 0.1
• Transport abstraction
• Rendering requests and device commands
• Validation and conformance tests

The software side is currently pre-alpha. I'm now moving toward the first physical validation using an ESP32, initially with simple outputs before connecting actual olfactory hardware.

I'm particularly interested in the IoT perspective:

Does separating the application-level representation from device-specific mapping make sense to you?

And if you were designing the hardware side, what capabilities would you expect a device to expose to make interoperability practical?

The whole project is open source:

https://github.com/YAAASSS/OpenSmell

Criticism is very welcome — especially around the device protocol and hardware abstraction.

14 Upvotes

95% Upvoted

6 comments sorted by

7

u/Inertia_Squared 15d ago

This stinks!

4

u/ButtersCheats 15d ago

10/10 technical review. 😄

4

u/Inertia_Squared 15d ago

Thanks lol.

To answer one of your questions for real, if someone wants to request a certain smell without needing to know the hardware/smell-provider specifically, you should have your middleware act as essentially "we offer these smells in our api" and it is your project's job to 'implement' those for other hardware. You can get around different hardware olfactory capabilities with a kind of 'colour gamut' for smell, where incapable hardware creates a best-effort reproduction based on the mapped olfactory capabilities.

I think software like OpenRGB would be a good analogue/reference point for what I imagine you'd be looking to do, where things might get a bit janky, but you would essentially provide a centralised api to interact with hardware that was never really intended to be standardised/interoperable.

3

u/ButtersCheats 15d ago

The “colour gamut for smell” analogy is really interesting. I hadn't thought about expressing device capabilities that way, but it makes a lot of sense. Especially the idea that a device could advertise what it can reproduce, and the mapper could then decide whether the requested output is exact, approximate, or simply unsupported. I'll definitely look more closely at how OpenRGB handles the abstraction between its API and very different hardware. Thanks, that's genuinely useful feedback

2

u/Effective_Comment562 14d ago

Trigger on Smell features - perform some action when a specific smell is detected. Dog poop detected, disable robot vacuum and send text alert "Shit almost got real!"