4

Let's say we have a device with sensors (eg. bunch of weather sensors like wind/air/hum/temp) and this device needs to report it's state to AWS IoT.

Let's say that every minute device would be publishing a bunch of readings as one big json:

{
   "temp" : 10,
   "wind:  100,
   "humidity" : 98.3,
   .... 
   ....
   "metric98": 23456,
   "metric99": 56789
}

I can see two ways to send these updates to AWS IoT:

  • publish status to AWS IoT shadow service topic $aws/things/super-weather-001/update
  • publish them to an arbitrary topic eg. mytopic/my-weather-data/super-weather-001...

In both cases I will have to create a rule on AWS IoT which will later throw these metrics into DynamoDb or process them in any other ways.

Which topic ($aws/... or mine) is it better to use to publish the metrics?

ps. I am aware that AWoT Shadows service is very convenient to calculate deltas vs "desired" state. But the trick in my case, that for the regular "metrics" from the weather station (like temperature or humidity), I don't have a "desired" state. I am not going to be setting temperature on the device, only reading, thus no need in calculating deltas.

Dimitry K
  • 2,236
  • 1
  • 28
  • 37

1 Answers1

2

There is a similar query on the AWS IOT forum - https://forums.aws.amazon.com/thread.jspa?messageID=703199&#703199

Bottom line, you could go either way. It is not exactly clear at this juncture if one has a decided advantage over the other. With a custom topic, there is no need for calculating deltas and other overheads of the shadow topic, as you mentioned, so this could reduce latency, but unless you have a ton of sensors and are constantly publishing values, this shouldn't be an issue, I think.

One could argue that the sensor values do still constitute the "state" of the device (which constantly keeps changing), and those values are "read-only", so a desired state doesn't have meaning, and so will not be used by the client.

It will be nice if some AWS architect can weigh in.

sridhar_rajagopal
  • 152
  • 1
  • 11
  • Thank you @sridhar_rajagopal for the answer and link. You made me think about the fact that changes in "shadow" caused by the temperature updates - would trigger shadow updates to all the listeners subscribed to change of this shadow. I think now that data from device should be separated into domains - if weather data consumption is consumed by another set of consumers, vs. let's say on/off state or calibration settings of the device sensors - then probably there's no point putting both internal settings and temperature readings into same shadow. – Dimitry K Jun 02 '16 at 13:08