WISHI OneDM hackathon

April 9th (Thursday), 7:00-11:00 PDT (16:00-20:00 CET, 14:00-18:00 UTC)

Participants:

  • Andrea Fresa
  • Andrea Pinto
  • Ari Keränen
  • Carsten Bormann
  • Christer Holmberg
  • Klaus Hartke
  • Michael Koster
  • Niklas Widell
  • Wouter van der Beek

Intro

Carsten presented: https://hackmd.io/@G-qLhvWWQ5i-HVrfquEHWA/H1XGaq3P8#/

Descriptions of tools brought to the Hackathon

MJK: Internet connected OCF device would be useful. Have lots of impact. Could be worth investing.
WB: easy to hook up ecosystems with the cloud thing; but not familiar with that implementation (might be hard to do today). Good long term way forward.

AK: How to get an OCF device to do a request, then?
MJK: Need server as well as client

github.com/iotivity-lite/apps/cloud_client.c should work, if security is worked around.
or https://github.com/openconnectivityfoundation/swagger2x/tree/master/src/templates/PythonFlask

MJK: not real device but semantically equivalent. Good for quick and dirty proto.
WB: should still work but if doesn't, can fix that. But no client endpoint. Postman can be used.

CB: we have Leshan server, Client implementation from OCF (usable even if not prepared for this). We have two ends of the challenge.

MJK: Flask could be the proxy; being client to Leshan and server to OCF client (postman)

digraph G {

  {
//    rank=same;
    "OCF app" -> "Flask" [label="OCF req"] 
    "Flask" -> "node-wot" [label="hard-coded API"]
    "node-wot" -> "LwM2M device" [label = "LwM2M req"]

    "LwM2M device" -> "LwM2M server" 
    "LwM2M server" -> "node-wot" [label = "TD of LwM2M client"]
    
    "swagger2x" -> "Flask" [label="Swagger file"]
    node [shape=note]
    "SDF file" -> "swagger2x"
//    "Thing Description" -> "node-wot"
  }   
}

Leshan API entrypoint:
http://129.192.70.97:8081/api/clients

LWM2M sample device:
http://129.192.70.97:8081/api/clients/wishi-lwm2m-ak-foo

Temperature object current value: http://129.192.70.97:8081/api/clients/wishi-lwm2m-ak-foo/3303/0/5700

or: GET accept=0 (text/plain) coap://129.192.70.97:51234/3303/0/5700
(directly from the device)

http://coap.me/accept=0/coap://129.192.70.97:51234/3303/0/5700

Doing the OCF request:
Need to provide an oic.res first?

AK: could set namespace to OMA for all the IPSO models to enable detecting ecosystem specific models

MJK: need to design the details of the namespaces
WB: prefer to come out with SDF 1.0 with what we have now
AK: have the defaultNamespace construct we can use for now

(break)

Discussion about structured data as input data for an OdmAction

AF: possile according to your schema to create a structure as odmData? What I mean is that I have an object with an odmAction. The odmAction has odmInputData. My input is a structure. How can I solve it?

MJK: SDF in general abstacts these details out. WoT TD has data schemas for this purpose. Can be annotated then with @type with SDF definitions and get semantic alignment. Avoids the common problem of having different people choosing different ways of sending payload. In LwM2M could have resources per type in the complex type of arrays as multi-instance. Preferred way in OneDM a resource type per complex type subtype.

(PoC discussion)

Repo: https://github.com/t2trg/2020-04-wishi-onedm-hack

https://github.com/t2trg/2020-04-wishi-onedm-hack/blob/master/samples/ipso-load-swagger.json

CB: Where does the rt=oic.r… and if=oic.if… value come from? I find in my oic.res:

      {
        "rt": [
          "oic.r.light.brightness"
        ],
        "if": [
          "oic.if.baseline",
          "oic.if.a"
        ],
        "p": {
          "bm": 1,
          "sec": false
        },
        "href": "/brightness"
      }

https://github.com/t2trg/2020-04-wishi-onedm-hack/blob/master/samples/input_devicebuilder.json would create a server, with oic.r.load – this is a product definition, for the tool chain I use.
oic.res also has "introspection", sanitized version of what is going into generation
Client finds targeted openapi spec in the introspection component.

also: resource types that can be created

WB: Clients may be specific for a purpose, e.g. just supporting lights; and generic clients that can talk to the device – end user reads the description

What was needed for SDF was the OdmObject, for Properties: RESTful/GET
Paths not important for OCF. Just need to be unique.

WB: can make oic.res, introspection (in JSON, introspection converted by tool to binary CBOR)

MJK: agreed to use the node-WoT Server for the other side of the proxy; works LWM2M server; Flask needs handlers though
WB: is being generated
MJK: needs to operate RESTful interface provided by node-WOT

MJK: Browser GUI for a demo
What does a client do with the information?

  • What OCF client can we use in the actual testing? (That's just an HTTP client…, looking at introspection and oic.res is relatively easy)

  • MJK: Inspector? walking oic.res?

  • WB: I can make something… Like OCF, but with HTTP, without CBOR or security

  • Re LWM2M resources: already out there; is the TDs the optimal format? for node-WoT, probably.

  • AK: Now start working on that.

  • Annotate TD with OneDM vocabulary

  • MJK: Define the endpoints from the node-WoT part, may be easy by using scripting API to expose those endpoints.

What is accessible over the Internet?

  • AK: There already is a node-WoT instance on wishi.nomadiclab – Tiny TD is a node-WoT instance.
  • MJK: Input TD for the device, consume the device. Maybe just use an express server to expose endpoints for the Flask client?

Do not just look at property entries, look at object entries as well.
(Discussion about collection gets.)

Checkpoint on OneDM meeting on 20th

Select a repo