[RESOLVED] Supported thing types in v0.3.1

I’ve been playing with fiz1962’s ESP-adapter and the accompanying espThing sketch for the Arduino IDE:

https://github.com/fiz1962/ESP-adapter

I’ve gotten the adapter’s javascript code and the accompanying sketch for the ESP8266 working to the point that the gateway can find the thing on the network, and add it to its list of things. However, the thing described in the sketch is of type “thing”, and the gateway doesn’t know what to do with it. The gateway simply displays an icon labeled by the name of the thing that provides no control over the device whatsoever.

Capture

It strikes me that the sketch programs the device to be three different things, although two of them are of similar types. Unfortunately, the JSON specification in the sketch doesn’t reflect the actual nature of the device, which is composed of three “things”:

  1. An object named “led”, with a boolean property that reflects its current state, and an on-off switch action that can change its state.

  2. An object named “clock”, which returns an integer giving the “short” time in milliseconds.

  3. An object name “anotherclock”, which returns an integer representing the “long” time.

I have two questions:

  1. What thing types are functionally supported in the current version of the gateway software, and

  2. Where can I find documentation that describes how to properly describe a device to the Mozilla IoT gateway which is, in actuality, multiple things. (This goes beyond the specification at https://iot.mozilla.org/wot/ to actual programming requirements for this implementation of the specification.)

[UPDATE:] Kathy Giori told me that the “splat” symbol used to represent Things of type “thing” can be clicked, and, if the gateway software can figure out what a “thing” is from the object type of objects within a thing, it will provide it’s own styled representation of that thing.

This leads me to believe that including a specification in the standard for everything that will eventually become part of the Web of Things will result in the complete mental breakdown of anyone who spends much time trying to do it. I’m becoming convinced that defining the things that can be represented in the standard is not a great idea. There are simply too many things in the universe, and a standard like this must be abstract and general. It should specify only how to tell implementing systems where to look for the definition of a particular thing.

Require the person who invented the thing to tell the system what it is and what functionality it has. Specifying thing types in a standard that must accommodate a practically infinite number of things of an as-yet-to-be imagined number of types is, in my humble opinion, a good way to end up mumbling in a dark corner of a mental hospital.

I’m impressed by your effort. While waiting for core developers to chime in, here are two thoughts I had.

  1. Splat view? The “virtual thing” example let’s you open the “splat” bubble to see the individual values. What does your thing breakout page show? For the virtual thing example you’ll see this:
  2. Start simple. Before coding an unknown web thing, try creating a known thing. That is, copy the outline of your existing espThing.ino file a new file (e.g., espLED.ino), and make the json simpler, to match a thing “type” of onOffLight. Tie the state of the onboard LED to the “on” property. Can you toggle the LED state using the gateway GUI?

For MCU boards, especially Arduino-compatible ones, I think of toggling the onboard LED via the Things Gateway as the “Hello World” or “Arduino Blink” of this Mozilla Things project.

1 Like

[quote=“kgiori, post:2, topic:27055, full:true”]Kathy Giori said:

  1. Splat view? The “virtual thing” example let’s you open the “splat” bubble to see the individual values… What does your thing breakout page show? For the virtual thing
    [/quote]

Wow! Wha’d’ya know! There’s a “breakout” page! I had no idea. I clicked everywhere but where I needed to. Thank you for kicking me in the right place, Kathy! It felt good :smiley:

So, here’s what I’ve learned:

A device consisting of several things can be described in a JSON-formatted string this way:

A Device specification is enclosed in [{ … }] and consists of a comma-separated list of Thing specifications enclosed in { }. For instance:

[{
{Thing1 Specification},

{ThingN Specification}
}]

where the Thing specifications set the usual name, type, description, properties etc., values.

My experiment resulted in a “bubble” that looked like this.

Capture1

Clicking the “splat” icon (that’s a great name for it) results in this display.

That’s what it looks like with only the first Thing this JSON spec given to the gateway:

[{
  // Thing 1 Specification
  "name": "ESP8266 Thing 1",
  "type": "thing",
  "description": "myESP8266",
  "properties": {
    "clock": {
      "type":  "number",
      "unit":  "Ticks",
      "description":  "The short millisec clock count",
      "href":"/properties/clock"
  },
  "led": {
    "type":  "boolean",
    "description":  "The onboard LED",
    "href":"/properties/led"
	 }
  }
},
{
  // Thing 2 Specification
  "name": "ESP8266 Thing 2",
  "type": "thing",
  "description": "myESP8266",
  "properties": {
    "anotherclock": {
      "type":  "number",
      "unit":  "Ticks",
      "description":  "The long millisec clock count",
      "href":"/properties/anotherclock"
    }
  }
}]

Sending both Things in the JSON response to the gateway’s query results in this display for Things:

Capture3

Side Note: Weirdly, both Things are of type “thing”. Maybe I’m missing something, but if a gateway must be relied upon to figure out what a Thing is from the properties of the objects contained in a Thing, the “type” definition for a Thing should be eliminated as a waste of perfectly good keystrokes that should be devoted to more useful endeavors.

[quote] Kathy Giori continued:

  1. Start simple. Before coding an unknown web thing, try creating a known thing. That is, copy the outline of your existing espThing.ino file a new file (e.g., espLED.ino), and make the json simpler, to match a thing “type” of onOffLight…
    [/quote]

Yes, breaking down a problem into simpler parts is always a good idea. Thank you for your help, Kathy!

Now, all I need to know is what Thing functional types are supported. The unofficial draft specification at https://iot.mozilla.org/wot/#thing-type mentions these types of Things.

  • thing
  • onOffSwitch
  • multiLevelSwitch
  • percent
  • binarySensor
  • multiLevelSensor
  • smartPlug
  • onOffLight
  • dimmableLight
  • onOffColorLight
  • dimmableColorLight

A final thought on the specification:

Guaranteed: The specification for Web of Things things, if it is going to eventually interface with every type of thing (does anyone doubt that’s where we’re going?), it will become the longest specification in the universe. Perhaps it might benefit from being a bit more general, and allow the code which implements a thing decide how to represent it.