Creating I2C add-on

(Marc Engrie) #1


After succesfully setting up my RPi as a gateway and setting some GPIO pins as in and out but also added an Ikea Tradfri lamp, I am now taking my first steps into creating an add-on/adapter for I2C on the Raspberry. Because there are so many I2C devices available like temp, humidity, pressure, light etc I think it might be very usefull to get that kind of information availalbe. So one can drive AC, ventilation, blinds etc based on the reading. I started with the BME280. There is no corresponding type that matches its functionality and for the time being I am mis-using the smartPlug type. But I see that one can create its own type using JSON-LD. What I can not figure out is where you need to add/define this extra type. Who can help me out here?

(Michael Stegeman) #2

Hi Marc,

That sounds like a great addition to have in our add-ons list. If you use a thing type of thing, the UI will actually render a generic layout with all properties. That is probably your best bet for now. You could also submit an addition to the WoT spec here:


(Kathy Giori) #3

Marc – great to see your work on I2C. I agree that we need to start figuring out how to start converging around WoT definitions for more types of sensor and actuators. Yet already it seems as though there are too many specific light types, so I worry about how to expand the standardized list of thing types in a sensible way.

For example, when a “physical thing” has many sensors/actuators (e.g., thingy:52 dev board from Nordic, Circuit Playground Express from Adafruit), should it be defined in terms of the physical object, with all those attributes grouped under one WoT “thing”? In that case the core icon would be a question mark and the little “splat” bubble could be clicked on to break out a picture (hub and spoke) that shows all the attributes. Or should an object with many sensors and actuators be better represented in the GUI as multiple icons, each icon based on a more limited set of functionality?

Perhaps we should try each approach and do some UX/UI studies to determine what “feels” better for end-users; what helps them understand and interact with the IoT world around them.


(Rzr) #4

I’ve work in progress using i2c on mozilla gateway.

Is there anyone interested to try it let me know:

(Dave Hylands) #5

I’m definitely interested. I have a Grove hat for my RPi and a ton of sensors. I’m especially interested in the little OLED displays.

(Rzr) #6

Let me clean up code a bit, I will share a repo soon,

meanwhile more sensors “wrappers” can be added to:

(Rzr) #7

Please track:

I will test again and document once 0.4.0 released.

Stay tuned

(Rzr) #8

As promised, doc for 0.4.0 image:

(Ben Francis) #9

Thanks for this great blog post!

I was surprised that you had to load the gateway at http://gateway.local:8080, it should be available at http://gateway.local because we have iptables configured to forward port 80 to port 8080. Were you not able to get that to work?

(Rzr) #10

I used the 0.4.0 image, maybe something broke since…

IIRC, I saw similar complain somewhere…

Today, I just rebuilt master and observe:

pi@gateway:~ $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:4443 mark match 0x1
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:http-alt mark match 0x1

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

Local Gateway is not loading after taking latest code (0.4.0)
(Rzr) #11

Adapter is merged , for 0.4.0 make sure to enable i2c from ssh (or rebuild master image from scratch):

Feedback welcome: