Данные не вставляются в таблицу Timestream, когда временная метка передается через основное правило IoT (через SQL time_to_epoch)

Question

Предполагая, что датчик отправляет такие данные:

{"timestamp": "2020-11-11 08:27:19", "temperature": 90, "device": "device1"}

1. Создайте основное правило IoT для отправки данных в таблицу базы данных Timestream.

2. Правило SQL: SELECT device, temperature, time_to_epoch(timestamp,'yyyy-MM-dd HH:mm:ss') as fn_ts FROM 'topic'

3. Размер: device

   значение: ${device}

4. Отметка времени: ${fn_ts}

   единица измерения: MILLISECONDS

Эти данные не достигают базы данных Timestream. Однако, если я удалю поля Timestamp, которые были установлены на шаге 4, данные достигают базы данных Timestream. В чем может быть проблема?

Удивительно - если я повторно опубликую результат шага 2 в новой теме и создам правило для отправки сообщения из этой темы в базу данных Timestream с той же конфигурацией, что и на шаге 3 и шаге 4 выше, тогда данные перейдут в базу данных Timestream db.

Кроме того, если исходное сообщение было {"fn_ts": 1605083835000, "temperature": 90, "device": "device1"} и у меня было правило отправлять данные в базу данных Timestream с тем же шагом 3 и 4, после чего данные попадают в таблицу Timestream.

Answer 1

Я просто потратил 2 дня на то, чтобы поиграть с правилом IoT, направленным в поток времени. Могу только подтвердить, что он глючит настолько, насколько кажется с самого начала. Единственный способ использовать настраиваемую метку времени - выполнить предложенный вами обходной путь, например преобразовать полезную нагрузку в отдельное правило и перенаправить на другую тему IoT. Потому что по какой-то причине действие блокировки не видит поля из результирующего JSON SQL, и я могу четко диагностировать его, потому что я прикрепил действие CloudWatch, чтобы увидеть каждую полезную нагрузку, которую я пытался создать с помощью SQL.

---

Но есть еще одна большая проблема. Когда вам, наконец, удастся ввести данные в таблицу, вы найдете КАЖДОЕ отдельное поле полезной нагрузки как отдельное поле меры в таблице, даже саму временную метку И все поля, которые вы уже отметили как размерные. Это чушь. После того, как я потратил так много времени, мне все еще нужно продолжить использование пользовательской лямбды, чтобы избежать всех этих беспорядочных мер в таблице.

Answer 2

При использовании правил AWS IoT, когда вы используете шаблоны подстановки, которые ссылаются на псевдоним, определенный в предложении AS вашего SQL, он не будет работать должным образом.

Из документации :

Поскольку выражение в шаблоне подстановки оценивается отдельно от оператора «SELECT ...», вы не можете ссылаться на псевдоним, созданный с помощью предложения AS. Вы можете ссылаться только на информацию, представленную в исходной полезной нагрузке, функциях и операторах.

Итак, с вашей полезной нагрузкой:

      {"timestamp": "2020-11-11 08:27:19", "temperature": 90, "device": "device1"}

Если вы измените свой SQL на следующий:

      SELECT * FROM 'topic'

Вы по-прежнему сможете установить размер и устройство, как и раньше, но вы можете установить метку времени следующим образом:

$ {time_to_epoch(отметка времени,'гггг-ММ-дд ЧЧ: мм: сс')}

Это будет использовать вашу метку времени для вызова функции time_to_epoch и использовать полученное значение в качестве метки времени в потоке времени.