Traducido del English por IA ·
Tenemos válvulas fan coil en 140 habitaciones de hotel que funcionan así, así que aquí está nuestra configuración.Hermetry envía los comandos al dispositivo en su propio topic de downlink. La placa del ventilador se suscribe a v1/rpc/req/+, un comando llega como v1/rpc/req/<id> con un método y parámetros, y la placa responde en v1/rpc/res/<id>. El id del topic es lo que se usa para asociar la respuesta.En el perfil del ventilador, abra la pestaña Commands y añada un comando, por ejemplo el método fan.set, un parámetro on de tipo Yes/no, tier Basic. Basic es importante, porque un Switch del panel solo envía comandos de tier Basic. Después, dé a la placa del supervisor una tarjeta Switch cuya acción sea Run a command fan.set con el valor del control, y enlace el Current state a una clave de telemetría que la placa informa tras conmutar; nosotros usamos fan.on.Lado Arduino, a grandes rasgos con 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 documentación dice que un comando puede llegar dos veces, así que guardamos los últimos ids y omitimos las repeticiones. Página: Envío de comandos a dispositivos. Para los setpoints que deben sobrevivir a un reinicio (temperatura objetivo del calefactor) usamos en su lugar atributos compartidos en v1/attributes/set; la placa los pide justo después de conectarse.
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.