Re: [T2TRG] 2. WoT Thing needs to have istate/ostate Bands

(1)

There could be a more general concept under istate/ostate, but in all my
experience with Things I haven't seen it. So it easily makes the 80/20 cut,
and probably even the 99.9/0.1 cut.

If there's need for really more detailed analytics on what's happening, I
suggest other approaches be taken altogether, e.g. Actions. But as written
about elsewhere, I don't believe this is necessary

(2)

I do use timestamps to coordinate what's happening with istate / ostate.
You can see this here

http://homestar.io:20000/api/things/urn:iotdb:thing:REST:6acd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light/istate
http://homestar.io:20000/api/things/urn:iotdb:thing:REST:6acd18449fe571d3a1d12ef66aa443dd:rest-dimmer-light/ostate

(3)

I don't believe necessarily "unreliable" is the right word. For example,
the light could be reported as on and the light could actually be on: the
command just hasn't executed yet, for whatever reason. Once again I will
note that this is not a theoretical concern: it happens all the time and
IoT UX people talk about dealing with it.

Let's say it's in a "transitional" state.

(4)

I don't think polling is necessary on modern devices. I do do it on some
legacy devices, but only at the 30s level.

Notifications that the state has changed can be sent via MQTT or CoAP. For
example, on my reference server you can do

$ mqtt subscribe --host 184.107.137.235 --port 20001 --topic '#' --verbose
$ curl --location '
http://homestar.io:20000/api/things/urn:iotdb:thing:REST:20b2c3ca712e8b0031debf3453cc75d1:rest-color-light/ostate
' -H 'Content-Type: application/json' -X PUT -d '{ "on": true }'

And watch the transitions happen (assuming the light is off).

(5)

MQTT is quite reliable. If you have a couple of computers running nearby,
play with the interface here. All the interfaces (dynamically made via
introspection!) will update as you transition state.

http://homestar.io:20000/

It's not quite as exciting as it could because the device simulators I
wrote were written before I really got a good sense how real world things
work, and the state transitions immediately.

(6)

Now that I've played with CoAP I'm quite excited by the possibilities of a
technology that will do this "all in one"

D.



On Wed, Jan 27, 2016 at 11:56 AM, Kerry Lynn <kerlyn@ieee.org> wrote:

> David,
>
> I think you're hitting on something important with the notion of
> "interstitial state",
> but I wonder if it's a special case of a more general concept - the
> freshness
> (or fidelity?) of istate?
>
> I've seen systems that assign timestamps to istate and ostate.  If a
> command
> is issued through the API then ostate timestamp is modified.  Reading
> istate
> through the API returns ostate and istate timestamps.  If the relation
> istate_ts
> < ostate_ts is true then the returned istate is unreliable.
>
> There is also the problem of devices that can be manually as well as
> program-
> matically controlled.  To detect an out-of-band state change, the device
> either
> needs to push the new state to the authoritative data store, be observed by
> the data store, or be polled by the data store.
>
> Observation exists in some transports but not others and push requires
> additional configuration, therefore polling seems like the lowest common
> denominator.  Polling raises the question "how frequently should I poll?"
>
> These questions seem to touch on the philosophy of state transfer in REST.
> The "real" state resides in the device and any representation of that state
> that resides elsewhere would seem to be stale within some epsilon.
>
> Kerry
>
>