Re: data streams

Edoardo,

Great if it works I have no practical experience myself using the 
pub-sub for IoT data but understand that there is standards work (in 
IETF) that could be possible to reference. What is the Oxford flood 
network, sounds like an Iot mesh?

Br magnus
Ericsson Signature


http://www.ericsson.com/current_campaign 
<http://www.ericsson.com/current_campaign>

*MAGNUS OLSSON * *
*


Ericsson AB
Group Function Technology
Mobilvägen 1
22362 Lund, Sweden
SMS/MMS +46 706 756814
magnus.olsson@ericsson.com
www.ericsson.com



Ericsson




This Communication is Confidential. We only send and receive email on 
the basis of the terms set out at www.ericsson.com/email_disclaimer 
<http://www.ericsson.com/email_disclaimer>

On 2015-06-03 10:19, Edoardo Pignotti wrote:
> Hello,
> I also agree that streams would be a very useful thing to support in 
> the WoT framework.
> I am in favour of a pub-sub broker model. In the oxford flood network 
> we thought very hard how to manage data streams and we went for a 
> pub-sub model.
> I would be more than happy to discuss this further in the context of 
> our case-study.
>
> All the best,
>
> Edoardo
>
>
> From: Magnus Olsson <magnus.olsson@ericsson.com 
> <mailto:magnus.olsson@ericsson.com>>
> Organization: Ericsson AB
> Date: Wednesday, 3 June 2015 09:04
> To: "public-wot-ig@w3.org <mailto:public-wot-ig@w3.org>" 
> <public-wot-ig@w3.org <mailto:public-wot-ig@w3.org>>
> Subject: Re: data streams
> Resent-From: <public-wot-ig@w3.org <mailto:public-wot-ig@w3.org>>
> Resent-Date: Wednesday, 3 June 2015 09:05
>
> Dave,    (and woters)
>
> Streams sounds like a very useful thing to support :-)
>
> - For the multiple sinks, why not use a pub sub broker as the 
> identified source of the stream that way any number of sinks can 
> attach to that pub-source. Seems to me that setting a proxy output 
> value to point to a single output is a limitation that might result in 
> someone creating an upstream proxy to split to multiple sinks.
>
> Any thing should be able to redirect any aspect of their source 
> (defined by its meta description) to a nearby pub-sub proxy service. 
> Still that could be an "on device" (localhost) broker, a home broker, 
> a service provider broker or a public broker etc.
>
> It seems reasonable to me to have use case such as one part of the 
> stream for the snapshot, another for the live view a third for data 
> analysis, a fourth for a remote tele medicine, a fifth for a emergency 
> monitoring function etc.
>
> - Even discrete value type of sensors could be handled as a stream if 
> only given long enough time to observe
>
> - (Not convinced myself) but perhaps any data points should be allowed 
> to be retrieved as a stream with sometime only a single value being 
> sent before the connection is being terminated.
> Ericsson Signature
>
>
> - If there is a possibility to "cascade" (or chaining) the streamed 
> data points then it might open up for a "network of" data stream 
> functions that could apply smartness to the stream such as adding 
> timestamps (simple sensors do not have timestamps, but sometimes have 
> sample rates), compression, average, de-noising, composite streams.
>
>
>
> Thanks!
>
>
> Br magnus
>
> http://www.ericsson.com/current_campaign 
> <http://www.ericsson.com/current_campaign>
>
> *MAGNUS OLSSON **
> *
>
>
> Ericsson AB
> Group Function Technology
> Mobilvägen 1
> 22362 Lund, Sweden
> SMS/MMS +46 706 756814
> magnus.olsson@ericsson.com
> www.ericsson.com
>
>
>
> Ericsson
>
>
>
>
> This Communication is Confidential. We only send and receive email on 
> the basis of the terms set out at www.ericsson.com/email_disclaimer 
> <http://www.ericsson.com/email_disclaimer>
>
> On 2015-06-03 09:16, Dave Raggett wrote:
>> I am interested in enabling the Web of Things Framework to handle 
>> data streams.
>>
>> Some sensors produces streams of data as a function of time. Data 
>> streams can carry one or more data channels where each channel is a 
>> single number or a vector.
>>
>> An example would be an electrocardiography (ECG) sensor which is used 
>> to produce a waveform of the heart's activity over a time period of 
>> up to a few seconds (see attached image). In a hospital the sensor 
>> and display are connected together with electrical leads.
>>
>> In the Web of Things, the sensor and the display are both modelled as 
>> "things". In place of leads, we set the sensor's output property to 
>> the display. The display could be an object in a web page script that 
>> displays the waveform using the HTML CANVAS element, or it could be a 
>> remote service, e.g. a device that acts as an oscilloscope. The 
>> display could have properties that control its behaviour, e.g. how 
>> many seconds of data to show. It could also have actions, e.g. to 
>> freeze the display to allow a waveform to be studied in more detail.
>>
>> Script developers ony need to know the object model for the sensor 
>> and display. The details of the underlying protocols are dealt with 
>> automatically by the server platform. For this to work, we need a 
>> standard way to describe data streams as part of the data model for 
>> "things".
>>
>> For a simple thing property, e.g. the state of a light switch, 
>> setting the value of the property on the proxy results in the server 
>> sending a message to update the physical state of the switch. For 
>> streams, the semantics is slightly different. Setting the value of 
>> the proxy's' output directs the data stream to the designated object.
>>
>> This model assumes that a stream can only be sent to a single data 
>> sink.  If you want to have multiple sinks, you will need to use a 
>> "thing" that acts as splitter. In principle, the thing acting as the 
>> sensor could do this, e.g. providing one output for a data logger, 
>> and another for a display.
>>
>> p.s. I am planning on implementing this as part of the NodeJS server 
>> project on GitHub. By the way, there are several examples of how to 
>> create an ECG monitor with Arduino’s if you want to build your own.
>>
>> —
>>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
>>
>>
>