- From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Date: Wed, 30 May 2018 16:17:44 +0200
- To: public-wot-ig <public-wot-ig@w3.org>
Hi all! I started coding my prototype that consists of a bunch of temperature sensors, some of which is mounted on a heat exchanger, connected to an Arduino microcontroller. Currently, I get the data from the Arduino using an HTTP GET that retrieves the temperature from all sensors as JSON with a key-value object where the key is the sensor ID. Thinking about it, I feel it doesn't really make sense to do it another way for now... Ideally, you would mint a URI for each sensor, but you'd still have to do discovery, and the application isn't now bandwidth constrained, it is constrained by the size of the code on the Arduino. To be really useful for anything, the data has to be lifted, and that isn't going to happen on the Arduino. Therefore, whatever does the lifting is probably best implemented as a servient, and so, it is that servient that mints URIs for each sensor, adds discovery, includes the semantics that is needed for an application to understand that it is dealing with a heat exchanger, and so on, it would still request all data from the microcontroller. This keeps the microcontroller code simple, at a very small cost of bandwidth between it and the lifting servient. If it had been bandwidth constrained, like over a radio, the tradeoff would be different. I don't know if this is something that you have considered? It seems to me that to meet this, it would be a useful to have a Collection of interaction patterns to describe the microcontroller, where the Collection would have a URI, and then add a description for each of the sensors based on that. This is the reverse of the current spec, where an interaction can more than one form. The above would then be a Collection of Property interaction patterns, but wouldn't this also be more intuitive for the Master LED switch example? That's also a URI of a collection of Actions. Right? I see that there's an array type, but it doesn't seem to be intended for this purpose, right? Best regards, Kjetil
Received on Wednesday, 30 May 2018 14:18:31 UTC