Températures

Les températures de froid et de cuisson, relevées par une personne ou remontées par une sonde — trois collections, et ce qui les distingue.

La température est la mesure sur laquelle se joue un contrôle de sécurité alimentaire, et l'application l'enregistre de trois façons. Elles se ressemblent et ne veulent pas dire la même chose : mieux vaut faire la distinction correctement avant de construire sur l'une d'elles.

Collection	Portée	Qui a pris la mesure
`temperature-records`	`temperature-records:read`	Une personne, sur un réfrigérateur ou un congélateur, pendant un service nommé.
`temperature-readings`	`temperature-readings:read`	Une sonde, d'elle-même, sans intervention.
`cooking-temperature-records`	`cooking-temperature-records:read`	Une personne, sur un équipement de cuisson — un four, une armoire de maintien.

Toutes les trois partagent l'enveloppe d'instantané : id, deleted, capturedAt, receivedAt, sequence et le reste entourent le data décrit ci-dessous.

`temperature-records`

Un contrôle manuel sur un équipement de la chaîne du froid. Un enregistrement par relevé, par équipement, par service.

Champ	Type	Signification
`timestamp`	string, obligatoire	Quand le relevé a été pris, en millisecondes depuis l'epoch sous forme de chaîne de caractères.
`value`	number, obligatoire	La température elle-même.
`unit`	string, obligatoire	`CELSIUS` dans tous les enregistrements que nous avons vus. Lisez-le plutôt que de le supposer.
`shift`	string, obligatoire	Le service auquel il appartient — `MORNING`, `EVENING`. En majuscules.
`equipmentId`	string, obligatoire	L'équipement mesuré.
`correctiveActions`	string[]	Ce qui a été fait quand le relevé était hors plage. Vide quand rien n'était nécessaire.
`userId`	string \| null	Le membre du personnel qui l'a pris, quand l'application en a enregistré un.

{
  "id": "48a30f0b-ccc0-4d18-8404-525b16ecaaa6",
  "collection": "temperature-records",
  "deleted": false,
  "capturedAt": "1789772570338",
  "receivedAt": "1789772802108",
  "sequence": "1",
  "data": {
    "timestamp": "1789768800000",
    "value": -14.4,
    "unit": "CELSIUS",
    "shift": "MORNING",
    "equipmentId": "84ce5c13-3237-40d4-901a-cbba59a6406f",
    "userId": "2774953d-8d9b-4a68-8ec4-1209edd90777"
  }
}

value est un relevé, pas un verdict. Rien dans l'enregistrement ne dit s'il était acceptable : cela dépend des min et max portés par l'équipement, que vous devez lire séparément et que le restaurant peut changer. Un relevé pris à -14,4 °C est un problème dans un réfrigérateur et normal dans un congélateur.

correctiveActions est du texte libre, saisi pendant le service dans la langue du restaurant. Comptez-le si vous voulez ; n'en tirez pas une énumération.

`temperature-readings`

La même mesure, remontée par une sonde sans fil plutôt que par une personne. Même forme, moins les deux champs qui n'ont de sens que lorsqu'un humain est intervenu : il n'y a ni shift ni userId.

Champ	Type	Signification
`timestamp`	string, obligatoire	Quand la sonde a remonté la valeur, en millisecondes depuis l'epoch sous forme de chaîne de caractères.
`value`	number, obligatoire	La température.
`unit`	string, obligatoire	Comme ci-dessus.
`equipmentId`	string, obligatoire	L'équipement que la sonde surveille.
`correctiveActions`	string[]	Renseigné après coup, par une personne, quand une alerte a donné lieu à une action.

Ceux-ci arrivent au rythme de la sonde : un restaurant chargé en produit bien plus que d'enregistrements manuels — dimensionnez votre interrogation sur le volume plutôt que sur l'effectif.

Quelle sonde a remonté la valeur n'est pas sur le relevé. Le lien se trouve sur la collection sensors, dont le sensorEquipmentId renvoie à l'équipement — attention au nom, ce n'est pas equipmentId.

`cooking-temperature-records`

Une personne qui mesure un équipement de cuisson plutôt qu'un équipement de froid. Identique à temperature-records, sauf qu'il pointe vers un équipement de cuisson.

Champ	Type	Signification
`timestamp`	string, obligatoire	Quand le relevé a été pris.
`value`	number, obligatoire	La température.
`unit`	string, obligatoire	Comme ci-dessus.
`shift`	string, obligatoire	Le service auquel il appartient.
`cookingEquipmentId`	string, obligatoire	L'équipement de cuisson mesuré — pas `equipmentId`.
`correctiveActions`	string[]	Ce qui a été fait au sujet d'un relevé hors plage.
`userId`	string \| null	Qui l'a pris.

Le nom du champ est la seule différence qui pique : un client qui lit equipmentId ici obtient undefined, silencieusement, et un graphique sans aucun équipement dessus.

Lire les trois ensemble

Un tableau de bord qui répond à « ce réfrigérateur était-il dans la plage aujourd'hui ? » veut temperature-records et temperature-readings fusionnés sur equipmentId, avec les seuils venus d'equipment. Trois parcours, joints de votre côté — aucun endpoint ne le fait pour vous.

Deux choses à intégrer dès le départ :

Ordonnez sur capturedAt, pas sur receivedAt. Une tablette dans une chambre froide téléverse quand elle trouve du réseau : l'enregistrement d'un relevé de 09:00 peut arriver à 14:00. La page de l'enveloppe raconte toute l'histoire.
L'absence ne prouve rien. Un relevé manquant peut vouloir dire que le contrôle a été sauté, ou que l'appareil ne l'a pas encore téléversé. N'imprimez pas un taux de réalisation issu de cette API en l'appelant conformité — voyez la mise en garde.