Réponse à : Comment faire migrer vers Hermetry des appareils sur un réseau Wi-Fi séparé, sans accès à Internet

Nous avons vécu exactement cela dans notre hôtel, un bâtiment de 140 chambres. Je suis d’accord avec Oğuz Bey : il n’existe pas de norme séparée, c’est une question d’architecture.Ce que nous avons fait : le VLAN IoT est resté fermé à Internet. Nous y avons installé un Raspberry Pi 4 à deux pattes. Une patte est sur le réseau IoT, où elle écoute le Mosquitto local. L’autre patte est sur le réseau de gestion et n’a l’autorisation que de sortie vers TCP 8883. Nous avons fait écrire une seule règle à l’IT : « depuis cette IP vers l’hôte broker Hermetry, 8883 en sortie ». Aucun port n’est ouvert en entrée.Le Pi est défini dans Hermetry comme un appareil unique et marqué « This device is a gateway ». Il envoie les données des capteurs des chambres sous son propre nom avec les topics v1/gw/*, et Hermetry crée lui-même chaque capteur comme appareil enfant lors de son premier rapport. Les capteurs des chambres n’ont besoin d’aucune identité dans Hermetry.

PUBLISH v1/gw/connect
{"device": "oda-214-klima", "type": "oda-sensoru"}

PUBLISH v1/gw/telemetry
{"oda-214-klima": {"values": {"temperature": 22.4, "humidity": 51}},
 "oda-214-kapi":  {"values": {"door_open": 0}}}

Si Hermetry contient un profil portant le même nom que le champ type, il l’utilise, ce qui permet de regrouper toutes les règles d’alarme des capteurs des chambres dans un seul profil. La limite par défaut est de 500 enfants par passerelle, largement suffisante pour nous. Chaque appareil enfant est en outre compté séparément, choisissez donc votre offre en conséquence.Si besoin, vous pouvez aussi envoyer des commandes et des attributs partagés aux appareils enfants : le Pi les reçoit via v1/gw/rpc et v1/gw/attributes et les transmet à l’appareil de la chambre. Nous n’envoyons pas de commandes aux chambres, nous nous contentons de les surveiller.Détails : Devices behind a gateway