Meeting minutes
Logistics
Sebastian: plugfest call, started 2 weeks ago, continue discussion
<sebastian6> https://
Sebastian: small updates regarding Wed event
Minutes
Sebastian: last time - https://
… ege also created a markdown file for detailed planning
Sebastian: talked about scenarios, including plug&play, OPC UA binding
… also NGSI-LD - we can discuss with them, maybe use cases
… then discussed TD topics; error handling, asynch communication
… then what physical devices we expect people to bring
… also, as a result, would be good to create an overview like last time
Sebastian: objections to the minutes?
Sebastian: none - approved
Plugfest during WoT Week
Organization
Sebastian: would be nice to use this event to share outcomes of plugfest, and demos
… during coffee break
Sebastian: good time to connect with other attendees
Sebastian: perhaps also give everyone a chance to make a short pitch on-stage
McCool: suggest limiting pitches to 30s
Sebastian: that is quite short
McCool: could just set the total time and divide by the number of people
McCool: suggest also consolidating pitches into a single deck, one slide per pitch
Sebastian: makes sense
Kaz: agree. that's kind of like the lightning talks at AC meetings
McCool: suggest that event managers print posters, and that the slides and posters are the same thing
Kaz: guess you are thinking about the open event we held at the first workshop
Sebastian: there is also a nice youtube video of that event...
Sebastian: need to ask the event manager about how to organize logistics
<sebastian6> https://
Posters and Pitches
Ege: it is possible to print, but hard if it's a mashup only decided on Tuesday
Sebastian: I will see if we can print-on-demand on location
McCool: another option would be to round up some big screens...
Participants
McCool: need to mention that the probability that I can go to WoT Week has been reduced to 10%
Plugfest Content
Sebastian: linked from the agenda
… David wanted to check on retail scenarios
David: still working on it; building cash systems, using AMP, looking for quick on-ramp
McCool: us-based?
David: yes, but international, lead dev is in Spain
McCool: maybe we ask for volunteers to help them
Sebastian: may be useful to have some pre-meetings
David: their system is pretty far-reaching, but for plugfest would demonstrate some key events
… minimize set of use cases
McCool: you mentioned the AMQP messaging protocol also; we have not really looked at that yet, but we probably should
Sebastian: we don't have a binding for AMQP yet, but it does fit the same role as MQTT
Sebastian: are there other interfaces, e.g. REST or MQTT? In those cases it would be very simple
Sebastian: might be too complicated...
McCool: on the other hand, the purpose of the plugfest is to look into new use cases
Sebastian: true
David: for information the company name is ArmorSafe
… is it ok to invite him to this meeting next time?
Sebastian: yes, that is not a problem with me
McCool: also ok with me
David: I can also invite people as a trade association
… could also invite them to the CG
… they are also leading the charge to adopt TDs
McCool: would be good to get a list of protocols in use...
Sebastian: next meeting will be in Sept, so next meeting would be in Sept
McCool: to clarify, proposing a plugfest call for Sept 4, and inviting them to that call?
Sebastian: yes, exactly
David: hottest retail IoT thing right now are shelf labels
McCool: and keeping the prices consistent with the labels...
David: yes, that is very important legally
Ege: if they join the actual plugfest, they could work on an AMQP binding - we can write some basic scripts - I do have some experience with it - quite similar to MQTT, as long as they are not using some of the more complex queuing features
Kaz: are they aware of web payments actitivity?
<kaz> Payment request API
McCool: maybe be some connection with online pre-payment
David: maybe possible, but semantically
McCool: probably a second-order problem though, suggest focus on iot interfacing
TD Topics
Ege: same discussion as last time, no news
… but we are going to prioritize checking existing features
… for new features, three are most important
[Existing Features]
* Additional Responses
* Error Handling on the application level (Scripting API is connected here)
* would be good to have real world example
* Multiple possible successful responses
* query-able actions?
* in Discovery API are examples where multiple responses are provided
* Default behavior (is it a normal response or is it an additional one)
* Linking between TDs
* Specifying multiple @types to TDs: This is confusing to people. We need
more guidance.
* Complex actions: Async and sync
* Meta Operations (top-level form operations): Are they implemented correctly.
This will be prioritized and idenfied gaps can be addressed as new meta
operations.
[New Features]
* Initial connection
* Data Mapping: This topic will be prioritized. It also related to additional
responses existing feature mentioned above.
* "Normative" Consumer Behavior: Degradation, Expected behavior. Writing what
a Consumer is expected to do for a TD. This will be prioritized and its results
will be used for the Interoperability Test Suite topic below.
McCool: re initial connections, AMQP will probably also need that
Ege: correct
Sebastian: (updates notes in agenda)
… we need to prioritize topics further in Nov
List of Devices
Sebastian: have some news, had meeting with TUM
… have created a list of devices that they can bring
Sebastian: including a very interesting advanced device, the HoloLens
<kaz> WoT Week at Munich on GitHub
<kaz> PR 588 - Add TUM Things to the device list overview
Sebastian: also a robot arm
McCool: would be good to have more detail on the "simple" devices - and make sure we have some. Simple switches and indicators, for instance.
… need to document those also
Kaz: need to think about what will be tested in addition to the device information - initial connections, actions, etc.
McCool: set of devices does relate the "type" issue
Kaz: right. related to the topic on "Orchestration of multiple devices", which Koster mentioned before too.
Sebastian: ok, would like to merge the TUM contributions to the markdown
… (merges)
McCool: should we allow remote participants?
Ege: related to this, some of these devices from TUM will be remote also
… and is it a physical or virtual device?
… also, we had some interest from other people who wanted to participate remotely
… making devices that are IN Siemens may be difficult
McCool: could use a local devices with SSH.
… but will need to sort that out, will have many non-Siemens devices
Kaz: right, so I mentioned potential need for a VPN service for remote connection last time
… let's think about the basic network setting also
Sebastian: will take these various questions to Siemens to figure out what is possible
Sebastian: if everyone can provide their details it will help us plan
Ege: previously we had some folders in github for people to upload things like pictures...
… for TDs and TMs will also need separate folders, validation, etc.
Kaz: VPN service we used may still be available, will check with System team
McCool: also suggest a pre-flight test for remote participants a couple of weeks in advance
Sebastian: agree with pre-flight idea
Sebastian: when should be have next meeting?
McCool: (thought we already agreed above to have it on Sept 4)
Ege: does anybody else know if they are bringing additional devices?
luca: I will probably be bringing something, details to follow
Jan: I will probably be bringing something MQTT or CoAP-based, and some kind of consumer implementation (if I can attend)
Sebastian: regarding next meeting, I will be unavailable Sept 4
Ege: I will also not be available Sept 4
Sebastian: so - suggest the week after, Sept 11.
Koster: that is Profile, but we could switch them?
Kaz: could do plugest on Sept 18.
Sebastian: ok, let's do that, and aim for Sept 18 for the next plugfest meeting.
… please create pull requests in the meantime
Kaz: Toumura-san also mentioned would bring a Node-RED consumer
Sebastian: adjourn