Using Collection+JSON to represent & control hardware

[Marc Christensen]

In my place of work, we automate testing of various products.  In order to do this, we designed a GPIO/1-wire/I2C expansion board for the Raspberry Pi.  This board can control up to 128 relays or a mix of relays and GPIOs, temperature sensors and A/D converters that can be read from

We have Python infrastructure to access all these hardware devices which are configured differently according to any tests that we are running on specific hardware.  Any programs we write are tied to being written for and running on a specific Raspberry Pi. My goal is to abstract the control of the hardware (creating of , reading or setting the state of relays, temperature sensors, voltages from ADCs, reading and writing from/to GPIO pins, etc.) by using a REST API.

My thought has been to use Collection+JSON to represent the hardware.

My question is this: Does this seem like an applicable use of Collection+JSON?  It seems to me that it fits well.  We have collections of devices that have a name, an I2C bus ID, a GPIO that they are controlled by. For example, once created, a relay's state can be set to "on", "off" or "toggle".  Similar properties are associated with ADCs (I2C bus), LEDs (also controlled by GPIOs), temp sensors (Dallas 1-Wire), reading/writing GPIOs, etc.

I'm also wondering how to create a Collection+JSON template that describes that during an HTTP PUT action, a relay's state (for example) can be one of the three states: 'on', 'off' or 'toggle'.   I'm not familiar yet with the Collection+JSON equivalent of HTML forms with pre-defined choices for options.

The basic URL for accessing would be similar to this:

GET /devices/

GET /devices/relays (returns a collection of relays. A POST would create a relay)

GET /devices/relays/r1 (returns the representation of a relay with it's current state, a PUT would change the state of that relay)

 

etc.  Under devices, you would find relays, leds, adcs, temp_sensors, gpios, etc.  New devices could be created with POSTs and modified with PUTs.

Any guidance would be appreciated.  Thanks,

--

Marc

[mca]

Marc:

good to see your note here.

<snip>

I'm also wondering how to create a Collection+JSON template that describes that during an HTTP PUT action, a relay's state (for example) can be one of the three states: 'on', 'off' or 'toggle'.   I'm not familiar yet with the Collection+JSON equivalent of HTML forms with pre-defined choices for options.

</snip>

the first challenge you mention here ("describing input options") is not directly supported in Cj. this has come up a few times in the past. good news is that Cj was design to easily support *extensions* for things like this. there are even some existing regisstered extensions. i've used the template-validation extension several times[1].

i've also seen people use an "options" property in the data elements and a "required" property[2]. i've not yet seen any extensions submitted and registered, but that's not a requirement.

does this help?

[1] https://github.com/collection-json/extensions/blob/master/template-validation.md

[2] https://gist.github.com/mamund/72328cc15082c533aea1

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

--
You received this message because you are subscribed to the Google Groups "Collection+JSON" group.
To unsubscribe from this group and stop receiving emails from it, send an email to collectionjso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marc Christensen]

Yes, that helps.  I was hoping there was a standard or an accepted extension for options since it is so common in setting values.  I might use the 'options' and 'required' properties.   They seem to address this. 

Thanks!

--
Marc

[Mike Amundsen]

Marc:

cool.  would really like to hear how this goes. how easy/hard it is to output on the server and consume on the client.

any/all stories will help shape the next version of Cj -- which likely will have a number of the more popular "extensions" baked into the baseline format.

cheers.

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund