Restrictions et limites du modèle de détecteur - AWS IoT Events

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Restrictions et limites du modèle de détecteur

Les éléments suivants sont importants à prendre en compte lors de la création d'un modèle de détecteur.

Comment utiliser le actions terrain

Le actions champ est une liste d'objets. Vous pouvez avoir plusieurs objets, mais une seule action est autorisée pour chaque objet.

Exemple
"actions": [ { "setVariable": { "variableName": "pressureThresholdBreached", "value": "$variable.pressureThresholdBreached - 1" } } { "setVariable": { "variableName": "temperatureIsTooHigh", "value": "$variable.temperatureIsTooHigh - 1" } } ]
Comment utiliser le condition terrain

Cela condition est obligatoire transitionEvents et facultatif dans les autres cas.

Si le condition champ n'est pas présent, c'est équivalent à"condition": true.

Le résultat de l'évaluation d'une expression de condition doit être une valeur booléenne. Si le résultat n'est pas une valeur booléenne, il est équivalent à la valeur nextState spécifiée dans l'actionsévénement false et n'initiera pas la transition vers celle-ci.

Disponibilité de valeurs variables

Par défaut, si la valeur d'une variable est définie dans un événement, sa nouvelle valeur n'est pas disponible ou n'est pas utilisée pour évaluer les conditions d'autres événements du même groupe. La nouvelle valeur n'est pas disponible ou utilisée dans une condition d'événement dans le même onInput onExit champ onEnter ou dans le même champ.

Définissez le evaluationMethod paramètre dans la définition du modèle de détecteur pour modifier ce comportement. Lorsque le paramètre evaluationMethod est défini surSERIAL, les variables sont mises à jour et les conditions des événements sont évaluées dans l'ordre dans lequel les événements sont définis. Sinon, lorsque cette valeur evaluationMethod est définie BATCH ou est définie par défaut, les variables d'un état sont mises à jour et les événements d'un état ne sont exécutés qu'une fois que toutes les conditions de l'événement ont été évaluées.

Dans l'"Dangerous"état, onInput sur le terrain, "$variable.pressureThresholdBreached" est décrémenté de un dans le "Pressure Okay" cas où la condition est remplie (lorsque la pression d'entrée du courant est inférieure ou égale à 70).

{ "eventName": "Pressure Okay", "condition": "$input.PressureInput.sensorData.pressure <= 70", "actions": [ { "setVariable": { "variableName": "pressureThresholdBreached", "value": "$variable.pressureThresholdBreached - 1" } } ] }

Le détecteur doit revenir à l'"Normal"état lorsqu'il "$variable.pressureThresholdBreached" atteint 0 (c'est-à-dire lorsqu'il a reçu trois relevés de pression contigus inférieurs ou égaux à 70). L'"BackToNormal"événement in transitionEvents doit tester une valeur inférieure ou égale à 1 (et non à 0) et vérifier à nouveau que la valeur actuelle donnée par "$input.PressureInput.sensorData.pressure" est inférieure ou égale à 70. "$variable.pressureThresholdBreached"

"transitionEvents": [ { "eventName": "BackToNormal", "condition": "$input.PressureInput.sensorData.pressure <= 70 && $variable.pressureThresholdBreached <= 1", "nextState": "Normal" } ]

Sinon, si la condition teste uniquement la valeur de la variable, deux lectures normales suivies d'une lecture de surpression rempliront la condition et reviendront à l'"Normal"état. La condition examine la valeur qui "$variable.pressureThresholdBreached" a été donnée lors du traitement précédent d'une entrée. La valeur de la variable est remise à 3 dans l'"Overpressurized"événement, mais n'oubliez pas que cette nouvelle valeur n'est encore disponible pour personnecondition.

Par défaut, chaque fois qu'un contrôle entre dans le onInput champ, a condition peut uniquement voir la valeur d'une variable telle qu'elle était au début du traitement de l'entrée, avant qu'elle ne soit modifiée par les actions spécifiées dansonInput. Il en va de même pour onEnter etonExit. Toute modification apportée à une variable lorsque nous entrons ou quittons l'état n'est pas disponible pour les autres conditions spécifiées dans le même onEnter ou onExit les champs.

Latence lors de la mise à jour d'un modèle de détecteur

Si vous mettez à jour, supprimez et recréez un modèle de détecteur (voir UpdateDetectorModel), il y a un certain délai avant que tous les détecteurs générés (instances) soient supprimés et que le nouveau modèle soit utilisé pour recréer les détecteurs. Ils sont recréés une fois que le nouveau modèle de détecteur prend effet et que de nouvelles entrées arrivent. Pendant ce temps, les entrées peuvent continuer à être traitées par les détecteurs générés par la version précédente du modèle de détecteur. Pendant cette période, il est possible que vous continuiez à recevoir des alertes définies par le modèle de détecteur précédent.

Espaces dans les touches de saisie

Les espaces sont autorisés dans les touches de saisie, mais les références à la clé doivent être encadrées par des backticks, à la fois dans la définition de l'attribut d'entrée et lorsque la valeur de la clé est référencée dans une expression. Par exemple, si la charge utile d'un message est la suivante :

{ "motor id": "A32", "sensorData" { "motor pressure": 56, "motor temperature": 39 } }

Utilisez ce qui suit pour définir l'entrée.

{ "inputName": "PressureInput", "inputDescription": "Pressure readings from a motor", "inputDefinition": { "attributes": [ { "jsonPath": "sensorData.`motor pressure`" }, { "jsonPath": "`motor id`" } ] } }

Dans une expression conditionnelle, vous devez également faire référence à la valeur d'une telle clé en utilisant des backticks.

$input.PressureInput.sensorData.`motor pressure`