Cloud4all WP103 2015-03-12

From wiki.gpii
Jump to: navigation, search

Back to meetings list

Time and date

Important Information for the Meeting

This is a meeting of WP103 within the European Project Cloud4All. However, the minutes of the meeting will be made available to the public to allow people outside Cloud4All to follow our thoughts. If, in the meeting, you want to share confidential information that should not appear in the public minutes, you need to state so in the meeting. This is in line with the Cloud4All Consortium Agreement, section 10.

Please connect to the audio using gotomeeting:

1. Please join my meeting.

2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.

  • United States: +1 (213) 493-0618
  • Australia: +61 2 8355 1036
  • Austria: +43 (0) 7 2088 1036
  • Belgium: +32 (0) 28 08 4345
  • Canada: +1 (647) 497-9372
  • Denmark: +45 (0) 69 91 89 24
  • Finland: +358 (0) 942 41 5788
  • France: +33 (0) 170 950 586
  • Germany: +49 (0) 811 8899 6928
  • Ireland: +353 (0) 19 030 053
  • Italy: +39 0 693 38 75 53
  • Netherlands: +31 (0) 208 080 212
  • New Zealand: +64 (0) 4 974 7243
  • Norway: +47 21 04 29 76
  • Spain: +34 931 81 6713
  • Sweden: +46 (0) 852 500 182
  • Switzerland: +41 (0) 225 3311 20
  • United Kingdom: +44 20 3657 6777

Access Code: 619-028-605 Audio PIN: Shown after joining the meeting

Meeting ID: 619-028-605



  1. Read previous meeting minutes and make corrections if needed
  2. Topics
    • Core B Conference
    • Always evolving code
    • Cooperate between apps and operating system
    • Provide a how-to for having external developers coding other systems rather than z-wave
    • On demand: more motes, more sensors, more rules
    • Integration meeting tasks
    • <add your topic here>


best seen as source


Core B Conference For next iteration

Always evolving code I need your guidance in moving the code to master branch in GPII, and we have to deal with a number of issues, namely:

XML Setting handler only working if at least two setting of the same type are setted --> it's on Kasper's radar ACTION Kasper: provide regular updates on the matter JSONx JSONx is an IBM® standard format to represent JSON as XML.

just in case it helps!!! not forcing anything!

Acoustic noise sensor making the system to crash Too fast reports from the environment stacking changes before they’re applied, making the system to crash Maybe the new temporal reporter can help, what takes us to Extensive use of temporal conditions (once at 9pm, every day at 9pm, only weekends at 9 pm …)

Whatever it happened to the mote during the review

GPS and other location mechanisms 1st is to have real GPS then, ideas nfc reader to CAS directly (mini-GPII) user as a sensor: app in the user smartphone semantic location -> i'm on my bank bluetooth handshaking (so having a BT sensor as part of the CAS) ACTION ALL to think about it

Complex handshaking between the user smartphone, the CAS and eventually the target machine (eg the ATM) - Interesting see before

Unit testing (yeah I’m such a n00b…) "new" context manager ACTION: Andres schedule a telco with Kasper to get help Acceptance/integration tests ACTION: Andres schedule a telco with Kasper to get help

PCP showing the messages from the MMM ACTION: Kasper kick-off a PCP team the "showing messages" feature is on a branch already basic version, PCP connects to a socket the system can send/receive messages to/from that socket could be improved to a bus mechanism as a backup plan, Javi can implement this on Linux but the part of reacting to the users' feedback will need more logic Cooperate between apps and operating system E.g who takes care of the fontsize, Android or Smart Twitter (or both) ? --"common term" o algo así para saber si la app sigue o no los estándares or something like that to know whether the app is following standards or not Should we wait to the "GPII NExus" to be in place? Should we start doing this mechanism on our own? The Nexus is still in design phase We have to ask in next architecture meeting. ACTION Kasper to put that on the agenda ACTION Kasper|Javi to raise the topic on the meeting Also thinking in Desktop Provide a how-to for having external developers coding other systems rather than z-wave Having a how-to for z-wave would be an excellent starting point

ACTION Andres to ask Guillem about the new team

On demand: more motes, more sensors, more rules Remember our first Stuttgart meeting? (October 2012) Classify the numeric value into a qualified category (rules, finally!) Decide a UI action based on the brightness category (more rules!) Steps to full context 1st phase: sensors attached to a mobile device Noise Luminosity Proximity... Some proxy sensors: Time of the day Day of the week Location Steps to full context 2nd phase: human as a sensor Some information can be provided directly by the user. Inference: Status on one of them: Whatssapp, google talk Direct asking: Ad-hoc app, if done, must be easier for the user to employ the app than to change N&P manually (must be studied) Steps to full context 3nd phase: Sensors separate from mobile • ●WSN • ●Some trust model starts to be needed. • –Several sensors stating different information for the same • topic. • –Luminosity: two motes in the room, a mobile device • carried by the user (btw, on his pocket, on his hand?) [ref • Dey] • Steps to full context • ●4th phase: Full inference of user state • ●Emotional context, Task the user is engaged in... • ●Commitment (pig style) to 1st phase • ●Involvement to 2nd phase • ●On our way to getting 3rd phase • ●We can study 4th phase, to happen after c4 • Logic to move logic between the RB-MM and the MMM transparently – The starting point has to be the MMM “asking for help” scenario

.. and Integration Meeting duties (say hello to Kasper :-P )