Von English mit KI übersetzt ·
Wahrscheinlich eine absolute Anfängerfrage. Wir testen gerade die Überwachung von Kühllagern in unserem Logistiklager. Sechs ESP32-Boards veröffentlichen Temperaturen auf v1/telemetry, und das funktioniert gut, Diagramm und Alarm sind vorhanden.Jetzt möchte ich Aktoren einbinden: Heizungen für den Türrahmen und zwei zusätzliche Lüfter, jeweils an einer Relaisplatine mit einem ESP32. In meiner Vorstellung funktioniert Pub/Sub in beide Richtungen. Mein Plan war daher: Das Lüfter-Board abonniert warehouse/zone3/fan/set, und etwas (ein Dashboard-Button? ein Skript?) veröffentlicht on oder off auf diesem Topic.Ich habe das von meinem Laptop aus mit paho-mqtt getestet, angemeldet als eines der Sensorgeräte, und auf v1/zone3/fan/set veröffentlicht. Auf dem Lüfter-Board kam nichts an. Nach drei Versuchen wurde die Verbindung meines Laptops geschlossen. Der Log-Tab dieses Sensorgeräts zeigt, dass die Veröffentlichungen als unknown_reserved_topic abgelehnt wurden.Ist Pub/Sub für Aktoren hier einfach das falsche Modell? Oder fehlt mir irgendeine Einstellung, mit der Geräte untereinander kommunizieren können?
Total beginner question probably. We are piloting cold storage monitoring for our logistics warehouse. Six ESP32 boards publish temperatures to v1/telemetry and that works fine, chart and alarm are there.
Now I want actuators: door frame heaters and two extra fans, each on a relay board with an ESP32. In my head pub/sub works both ways, so my plan was: the fan board subscribes to warehouse/zone3/fan/set, and something (a dashboard button? a script?) publishes on or off on that topic.
So I tested it from my laptop with paho-mqtt, logged in as one of the sensor devices, and published to v1/zone3/fan/set. Nothing arrived on the fan board. After three tries my laptop connection got closed. The Log tab of that sensor device shows the publishes were rejected as unknown_reserved_topic.
Is pub/sub just the wrong model for actuators here? Or am I missing a setting somewhere that lets devices talk to each other?
Von English mit KI übersetzt ·
Ist dafür nicht das Custom topics im Profil gedacht? Ich erinnere mich an eine Einstellung, die jedes Topic außerhalb von v1/ akzeptiert.
Isn’t that what Custom topics on the profile are for? I remember a setting that accepts any topic outside v1/.
Von English mit KI übersetzt ·
Benutzerdefinierte Topics sind nur eingehend, sie werden zur Telemetrie des Geräts, das sie veröffentlicht hat. Und Geräte erhalten in Hermetry niemals die Nachrichten anderer Geräte, daher wird ein Sensor, der für einen Lüfter veröffentlicht, nie funktionieren.Außerdem aus 14 Jahren Anlagenpraxis: Man möchte, dass der Aktor antwortet. Fire-and-forget an ein Relais führt dazu, dass ein Lüfter im Leitstand als eingeschaltet angezeigt wird und im Raum aus ist.
Custom topics are inbound only, they become telemetry of the device that published. And devices never get each other’s messages in Hermetry, so a sensor publishing for a fan will never work.
Also from 14 years of plant work: you want the actuator to answer. Fire and forget to a relay is how you end up with a fan that shows on in the control room and is off in the room.
Von English mit KI übersetzt ·
ok, das leuchtet ein. Wie kommt dann etwas bis zur Lüfterplatine runter? Ich brauche trotzdem irgendwo einen Taster für den Lagerleiter.
ok that makes sense. So how does something get down to the fan board then? I still need a button somewhere for the warehouse supervisor.
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.
Von English mit KI übersetzt ·
Eine Erfahrung aus dem Feld: Gestalten Sie den Befehlssatz als Zustand, niemals als Umschalten. Ein Befehl, bei dem ein Timeout auftritt, bedeutet nur, dass keine Antwort zurückkam; er könnte trotzdem ausgeführt worden sein. Drückt der Supervisor erneut, ist fan.set on zweimal unschädlich, fan.toggle zweimal schaltet den Lüfter wieder aus.
One thing from the field: make the command set a state, never toggle. A command that times out only means no answer came back, it may have run anyway. If the supervisor presses again, fan.set on twice is harmless, fan.toggle twice turns it off.
Von English mit KI übersetzt ·
Funktioniert. Schaltkarte auf der Supervisor-Platine, der Lüfter klickt, und der Status kommt als fan.on zurück.Zwei Dinge hatte ich falsch. Ich hatte es zuerst als fan.toggle umgesetzt und es nach Tylers Beitrag geändert. Außerdem habe ich das Abonnement nur einmal in setup() ausgeführt, daher funktionierten Befehle bis zum ersten WLAN-Abbruch und danach nie wieder. Ich habe das Abonnement in die Reconnect-Funktion verschoben, und jetzt übersteht es Verbindungsabbrüche.
Working. Switch card on the supervisor board, fan clicks, state comes back as fan.on.
Two things I had wrong. I first made it fan.toggle, changed it after Tyler’s post. And I only subscribed once in setup(), so commands worked until the first WiFi drop and then never again. Moved the subscribe into the reconnect function and it survives now.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.