いつもお世話になっております。
> 検知結果は、確実に1度だけ相手に通知するという要求があります。(タイムアウト等は設計の上)
例えば、以下のサンプルで言うと、3のOFFは確実に一度だけ出す必要があるものですが、
このようにイベントで設計してもらうのが基本になります。
アクションのintervalは、同じイベントが連続する場合にアクション実行を調整する目的のため、
この用途ではそのまま使えません。
> ・この対策として例えば、アクションを1回(送信リクエストを1回)としてしまうと、通信失敗やIntervalの間に飲まれて通知そのものができなくなるケースが考えられます。
ご指摘の通り、通信失敗の場合は、1回の送信を満たせないことがありえます。
> ① Actionの結果をCallbackは取得できますか? もしくは代替手段はありますか?
例えば、HTTPSアクションで、HTTPレスポンスを返してあげる、ということですよね?
現状の仕様では、アクションの実行結果をアプリケーションに返すことはできません。
ただし、アクションを管理しているデバイスエージェントからアプリケーションcallbackへの経路は存在しており、
「外部イベント連携」と呼ぶ仕組みが該当し、例えばデバイスコンソールのマウス操作やPTZの移動、を通知することができます。
プラットフォームサービスの開発が必要ですが、ここに、アクションの実行結果を含めることが一番の近道です。
例えばHTTPSアクションに絞って仕様を明確にしてやってみるということであれば、
プロダクションのpocリポジトリで検証することは可能ですので、
案件のスケジュール含め、ご相談ください。
> ② Actionの仕様として、リクエストが成功するまでリトライするような仕様ですか?
いえ、イベントの大きさやアクション実行頻度が事前にプラットフォームでは想定できませんので、
fail fastの設計になっています。
通信不良から電源断やストリーム再起動(何らかの障害により)に至るようなケースまで想定すると、
ここまでをプラットフォームサービスでカバーした方が良いですが、
永続化ストレージ(簡易データベース)で管理する必要が出てきますね。
ハードウェア的に、ランダムI/Oによって寿命が短くなること、PCIバスの輻輳により各種障害が発生しやすくなることなど、
注意が必要なところがあり、案件によって大きく変動する要素があります。
これについても、HTTPSアクションに絞って、初回リクエストが失敗したもののみ記録してリトライ、
記録するイベント数も上限を設け、それを超えたらストリームを停止する、などルールを決めれば、十分トライ可能です。