Meeting minutes
Minutes
<kaz> Mar-16
<kaz> (approved)
Testfest
mccool reviews several PR recently merged about implementations
PR 247
<kaz> PR 247 - add TD with profile term #247
PR 248
mccool reviews PR #247
about profile term in TD
<kaz> (merged)
PR 248
<kaz> PR 248 - profile compliant WebThings (properties)
the PR # 248 is merged
script for validating TDs
validating TDs may need for each assertion a test
assertions in TDs
McCool: in the intel-nodejs-camera.csv I removed last column and sorted the assertions
different runs may generate a different order though, it would be good to have a common sorting
NOTE: Ege said actually the template was sorted.
PR #249 now is closed
<kaz> PR 249 - Renaming Oracle TD endings
Ege: will create new PR
implementation description
Ege: was writing implementation description. Where does it go to?
McCool: Architecture ?
Ege: I suggest to clean issues also.. we have out-dated ones from previous TestFests
Fady: Will do that
McCool: Tomorrow we can look at issues we can close
… e.g., Issue #141
McCool: Does assertion tester support TMs ?
Ege: Almost, pending PR
McCool: After cleaning-up archive we can close some issues
… suggest to wait till Fady finishes the work with the archive
… maybe adding label "propose closing"
Fady: Okay, will do
McCool: Can also use again Issue Tracker to capture PlugFest results
<kaz> Issue 160 - Update assertion tester
McCool: Suggest to close Issue#160
… any further discussions for testing ?
… none -> suggest to close early and restart with PF call on time
<kaz> [Testing part adjourned]
Plugfest
Architecture
(some updates to the proposed terms in Architecture/README.md)
<kaz> 2022.03.Online/Architecture
McCool: let's use these to be consistent
PRs
(resolving merge conflict in #251
Lagally: the first device is online, not yet added to "active.csv"
Lagally: I believe many TDs are already profile compliant, if they had the profile identifier. Challenge is how to validate them
… note that you do not have to implement all profile features to be profile compliant
McCool: let me regenerate the assertions, there are 49 of them
(generates template.csv)
Lagally: we could ask other contributors to manually check the profile assertions
McCool: probably Ben's TDs should be treated with priority
Lagally: These are not TDs at this point
Cristiano: WebThings TDs may be a bit tricky, not sure about a real consumer implementation
McCool: if I use node-wot and poke these interactions, will it work?
Cristiano: WebSocket will likely not work
.ML: are these online
McCool: all are localhost, not running at this point
… we could check all non-behavioral assertions
Cristiano: let me check if I can set up sth.
Retail use cases
McCool: I worked with the MQTT Shelly sensor, some findings
… I have it running, several MQTT devices, 3 categories
… some interesting questions about keep-alive, multiple protocols (CoAP, MQTT, HTTP)
… device gets alive for a few mins, goes to sleep afterwards
… shelly uses also JSON-RPC 2.0, we may look into this in the future
<Ege> just found it, quite big indeed: https://
<Ege> stay safe!
* stay safe Japanese members *
… they are using a HTTP variant
Cristiano: were you able to trigger actions from MQTT?
… it depends on vendors of how it is supported
McCool: (shows details on the Tempest Weather System and Victron Energy)
… need to check keep-alive behavior
… I will describe in the scenarios.md
… I got ~20 devices
Lagally: are there any devices / events exposed on the Internet?
McCool: I can install Mosquitto and write TDs to expose these devices
Ege: You could also open a port in your router, I could connect to your MQTT broker
McCool: There are some security issues, none of the devices support security
… Simplest would be to temporarily redirect them to VLAN
Cristiano: This would be very beneficial
McCool: Shelly has WebHooks for actions, Cloud API
<McCool_> https://
McCool: it has a device description, includes location, other metadata
<McCool_> https://
McCool: actions are implemented as WebHooks
<kaz> [adjourned]