Von English mit KI übersetzt ·
Bei uns läuft das so an Fan-Coil-Ventilen in 140 Hotelzimmern, daher hier unser Aufbau.Hermetry sendet Befehle an das Gerät über dessen eigenes Downlink-Topic. Die Lüfterplatine abonniert v1/rpc/req/+, ein Befehl kommt als v1/rpc/req/<id> mit einer Methode und Parametern an, und die Platine antwortet auf v1/rpc/res/<id>. Die ID im Topic dient dazu, die Antwort zuzuordnen.Im Lüfterprofil den Reiter Commands öffnen und einen Befehl hinzufügen, zum Beispiel Methode fan.set, ein Parameter on vom Typ Yes/no, Tier Basic. Basic ist wichtig, weil ein Dashboard-Switch nur Basic-Tier-Befehle sendet. Dann bekommt die Platine in der Supervisor-Ansicht eine Switch-Karte, deren Aktion Run a command fan.set mit dem Wert des Steuerelements ist, und der Current state wird an einen Telemetrie-Schlüssel gebunden, den die Platine nach dem Schalten meldet; bei uns fan.on.Grobe Arduino-Seite mit 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);Laut Doku kann ein Befehl zweimal ankommen, deshalb merken wir uns die letzten IDs und überspringen Wiederholungen. Seite: Befehle an Geräte senden. Für Sollwerte, die einen Neustart überdauern sollen (Solltemperatur der Heizung), verwenden wir stattdessen Shared Attributes auf v1/attributes/set; die Platine fragt sie direkt nach dem Verbinden ab.
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.