Hi Dario and all,<br><br>With regards to the status of integration I have to say a couple of things: in general our system successfully communicates with the provided socket server and receives events from the device simulator as well. However, I have observed some weird situations when the the device simulator client cannot connect to the server. More specifically, these situations occur only when I have to restart the device client after my own client has already been connected to the server, and the server has generated a thread for my client. At this point, if I restart the device simulator, the server fails to register this new client (which is confirmed by the server log - there is no indication of a new client connection). I am wondering whether other competitors have encountered a similar problem.<br>


<br>I understand that during the competition the device simulator will not be used as it is, that is, domotic bus events generation and the socket server might be incorporated in one processing unit and therefore there won't be a problem of reconnecting clients. However, if this is not the case, and every physical device connects to the server as a separate client, I would like to be reassured that our system won't be missing any contextual events due to the issue with clients reconnections.<br>


<br>Another question relevant to the integration: will we be given the unique IDs of the domotic bus devices before the competition? I am asking because in order to make the integration of our system with the domotic bus more or less transparent, we need to register these additional devices in our system in compliance with the specifications used for our own devices. At the very least, we need to make sure that all the ids are unique so if we don't know the ids of your devices in advance, we might have collisions. If you choose not to disclose the ids of your devices since you have already provided the coordinates, it's fine with us too because we can assign our own ids and upon receiving events from the domotic bus, we'll simply infer those ids from the provided coordinates.<br>


<br>After reading one of the recent digests, I am not sure I understand what timestamp is meant here:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
the time stamp is really used in the metrics is the one that is created<br>
where the integration program is running.<br>
This timestamp is automatically computed locally using the computer's<br>
clock. For this reason, the only machine that must be synchronised with<br>
the NTP client is the one runnning the integration program (the socket<br>
server or the itnegrated java package).<br></blockquote><div><br>I believe that this information applies to java-based systems only, otherwise it's rather confusing. We are using a second option for integration - communication over sockets. As far as I understand, competitors do NOT run the socket server in their systems during the competition - our system acts as a telnet client which publishes localization tuples to/reads contextual events from the server provided by the organizers at the given ip address. I did not read any details of java integration but the above explanation sounds like the java package calculates its own timestamps when sending a tuple to the socket server. This is NOT the case for our system because the timestamps reported by our system will be delayed compared to the time when they are actually published. Our computer which acts as a telnet client and publishes the tuples will be ntp synchronized prior to the beginning of the tests and the timestamps will be reported in epoch time with milliseconds so that there is no issue of conversion from relative time. Please let me know if my understanding is correct.<br>

<br>One more thing I would like to know is how the "half a second" parameter is exactly measured. In the case of our system where the delayed timestamps are reported, there are two options: 1) to keep the log of when the tuples are published to the server socket and measure the time difference between each two consecutive published tuples; 2) measure the difference between two consecutive timestamps taken from the actual tuple. Depending on which calculation scheme is used, we need to make appropriate arrangements in the code. Also, how strict is this requirement, is it expected to be 500ms sharp or some deviations within reasonable number of milliseconds are allowed?<br>
<br>Thank you,<br>Julia Vlasenko<br><br><br></div></div>