40 règles. 40 entrées YAML. Zéro fichier Rust.

Modèle de politique

Trigger → Condition → Action. Rien de plus.

Chaque règle a exactement trois parties. Il n'y a pas de modèle d'exécution au-delà de ce construct.

Surface de création

Un éditeur basé sur des nœuds qui exporte du YAML.

MEP est l'un des quatre moteurs de création visuelle dans la couche no-code de MOS4, avec l'éditeur de graphe de signaux, le constructeur de pipeline IA et la vue de configuration multi-pile.

Deux vues, un fichier

Machine à états pour le product owner. T·C·A pour l'ingénieur.

La même politique de geofence se lit comme une machine à trois états dans le designer et comme trois règles T·C·A YAML dans la vue d'ingénierie. Le fichier YAML est la machine à états — il n'y a pas de runtime séparé.

stateDiagram-v2
  [*] --> dehors
  dehors --> approchant: near
  approchant --> dedans: enter
  approchant --> dehors: exit
  dedans --> approchant: near
  dedans --> dehors: exit

rules:
  - name: enter_geofence
    on_event: geofence.near
    when: state == "approaching"
    do:
      - set: { state: "inside" }
      - emit: geofence.entered

  - name: leave_geofence
    on_event: geofence.exit
    do:
      - set: { state: "outside" }
      - emit: geofence.left

  - name: approach_geofence
    on_change: distance_m
    when: distance_m < 50 and state == "outside"
    do:
      - set: { state: "approaching" }

Le designer visuel rend le diagramme d'état depuis le YAML ; le YAML reste l'artefact de déploiement. Ajouter un état consiste à ajouter une règle — le diagramme se met à jour automatiquement.

Exemples de règles

Ce que les intégrateurs déploient.

Couverture de déploiement

MEP est déployé dans les six scénarios.

Les politiques machine à états et de contrôle LED font partie des capacités les plus couvertes dans la matrice de fonctionnalités MOS4 — disponibles des facteurs de forme dongle léger aux plateformes gateway compute-class.

Les politiques MEP se composent avec la couche multi-pile pour des séquences de routage de données événementielles. Voir Multi Stacks pour la composition de stratégies inter-piles.

Catalogue de nœuds

58 types de nœuds dans trois catégories.

10 déclencheurs · 17 conditions · 31 actions — dérivés au build time depuis le schéma du moteur. Chaque nœud est disponible dans le designer visuel et en YAML édité manuellement.

Utilisez les actions call_interface pour atteindre MSP, les moteurs d'inférence et les pilotes personnalisés depuis toute règle de politique. Voir le SDK pour créer des micro services que MEP peut appeler.

FAQ

Questions fréquentes

• Faut-il un développeur Rust pour changer une règle après le déploiement ?

  Non. Changer une règle consiste à éditer le YAML et pousser la politique mise à jour — via OTA ou un appel de service direct. Pas de toolchain Rust, pas de rebuild firmware, pas de re-flash. Le rechargement à chaud vide les règles en cours et échange atomiquement le graphe de politique.

• Quel est exactement le modèle de politique ?

  Chaque règle a exactement trois parties : un déclencheur (on_change, on_event, ou on_schedule — délai/périodique/cron en UTC) ; une condition optionnelle (expression évaluée contre l'état DB et le payload de l'événement) ; et une ou plusieurs actions (écrire une clé DB, émettre un événement, call_interface, ou planifier une autre règle). Il n'y a pas de modèle d'exécution au-delà de ce construct.

• MEP est-il une machine à états finis ?

  Les règles MEP expriment un comportement de style machine à états via les primitives T·C·A. Le YAML de politique est la machine à états — il n'y a pas de runtime machine à états séparé. T·C·A est la primitive de règle ; l'ensemble de règles composé est la machine à états. Les deux lectures sont disponibles — le designer visuel rend le diagramme d'état pour les product owners ; le YAML reste l'artefact d'ingénierie.

• Quel fuseau horaire utilise la planification cron ?

  UTC uniquement. La planification tenant compte des fuseaux horaires n'est pas prise en charge actuellement.

• Une politique peut-elle appeler un autre micro service MOS4 ?

  Oui. L'action call_interface atteint tout micro service MOS4 — MSP, moteurs d'inférence et pilotes personnalisés. Le proxy d'interface valide la contrainte semver au chargement de la politique, met en cache la connexion et applique un timeout configurable (3 000 ms par défaut par appel). Aucun code de liaison par intégration. Voir le SDK pour créer des micro services personnalisés.

• Puis-je tester des règles sans matériel ?

  Oui. Un outil de lint sémantique valide le YAML avant qu'il n'atteigne un device — détectant les clés DB non définies, les déclarations requires: manquantes, les graphes de règles cycliques, les conditions inaccessibles et les erreurs de type d'expression. Un runner de scénario autonome rejoue les fichiers YAML hors cible dans les pipelines CI. Un double de test du moteur de politique permet de tester l'évaluation de politique en intégration sans pile MOS4 complète.