Traduit de English par IA ·
Nous avons des vannes fan coil dans 140 chambres d’hôtel qui fonctionnent ainsi, voici donc notre configuration.Hermetry envoie les commandes à l’appareil sur son propre topic de downlink. La carte du ventilateur s’abonne à v1/rpc/req/+, une commande arrive sous la forme v1/rpc/req/<id> avec une méthode et des paramètres, et la carte répond sur v1/rpc/res/<id>. L’id dans le topic sert à associer la réponse.Dans le profil du ventilateur, ouvrez l’onglet Commands et ajoutez une commande, par exemple la méthode fan.set, un paramètre on de type Yes/no, tier Basic. Basic compte, car un Switch du tableau de bord n’envoie que des commandes de tier Basic. Ensuite, donnez à la carte du superviseur une carte Switch dont l’action est Run a command fan.set avec la valeur du contrôle, et liez le Current state à une clé de télémétrie que la carte publie après avoir commuté ; nous utilisons fan.on.Côté Arduino, en gros avec PubSubClient :
void onMsg(char* topic, byte* payload, unsigned int len) {
String t(topic);
if (!t.startsWith("v1/rpc/req/")) return;
String id = t.substring(11);
StaticJsonDocument<256> doc;
deserializeJson(doc, payload, len);
if (doc["method"] == "fan.set") {
bool on = doc["params"]["on"];
digitalWrite(RELAY, on ? HIGH : LOW);
client.publish(("v1/rpc/res/" + id).c_str(), "{"ok":true}");
client.publish("v1/telemetry", on ? "{"fan.on":1}" : "{"fan.on":0}");
}
}
// after every connect:
client.subscribe("v1/rpc/req/+", 1);La doc indique qu’une commande peut arriver deux fois, donc nous gardons les derniers ids et ignorons les répétitions. Page : Envoyer des commandes aux appareils. Pour les consignes qui doivent survivre à un redémarrage (température cible du chauffage), nous utilisons plutôt les attributs partagés sur v1/attributes/set ; la carte les demande juste après la connexion.
We have fan coil valves in 140 hotel rooms doing this, so here is our setup.
Hermetry sends commands to the device on its own downlink topic. The fan board subscribes to v1/rpc/req/+, a command arrives as v1/rpc/req/<id> with a method and params, and the board answers on v1/rpc/res/<id>. The id in the topic is how the answer is matched.
On the fan profile, open the Commands tab and add a command, for example method fan.set, one parameter on of type Yes/no, tier Basic. Basic matters because a dashboard Switch only sends Basic tier commands. Then the supervisor’s board gets a Switch card, its action is Run a command fan.set with the control’s value, and the Current state is bound to a telemetry key the board reports after it switched, we use fan.on.
Rough Arduino side with PubSubClient:
void onMsg(char* topic, byte* payload, unsigned int len) {
String t(topic);
if (!t.startsWith("v1/rpc/req/")) return;
String id = t.substring(11);
StaticJsonDocument<256> doc;
deserializeJson(doc, payload, len);
if (doc["method"] == "fan.set") {
bool on = doc["params"]["on"];
digitalWrite(RELAY, on ? HIGH : LOW);
client.publish(("v1/rpc/res/" + id).c_str(), "{"ok":true}");
client.publish("v1/telemetry", on ? "{"fan.on":1}" : "{"fan.on":0}");
}
}
// after every connect:
client.subscribe("v1/rpc/req/+", 1);The docs say a command can arrive twice, so keep the last few ids and skip repeats. Page: Sending commands to devices. For setpoints that should survive a reboot (heater target temperature) we use shared attributes on v1/attributes/set instead, the board asks for them right after connecting.