Rölelerim sadece kendi MQTT konularına abone olabilir mi, yoksa Hermetry eyleyiciler için başka bir şey mi istiyor?
Yapay zekâ tarafından English dilinden çevrildi ·
Muhtemelen tam bir acemi sorusu. Lojistik deponumuz için soğuk depo izleme sistemini pilot olarak uyguluyoruz. Altı ESP32 kartı sıcaklıkları v1/telemetry konusuna yayınlıyor ve bu sorunsuz çalışıyor, grafik ve alarm hazır.Şimdi eyleyicileri istiyorum: kapı çerçevesi ısıtıcıları ve iki ek fan, her biri ESP32’li bir röle kartında. Aklımda pub/sub iki yönlü çalışıyor; planım şuydu: fan kartı warehouse/zone3/fan/set konusuna abone olacak ve bir şey (bir gösterge paneli düğmesi? bir betik?) bu konuya on veya off yayınlayacak.Bunu dizüstü bilgisayarımdan paho-mqtt ile, sensör cihazlarından biri olarak giriş yaparak test ettim ve v1/zone3/fan/set konusuna yayınladım. Fan kartına hiçbir şey ulaşmadı. Üç denemeden sonra dizüstü bilgisayarımın bağlantısı kapandı. O sensör cihazının Günlük sekmesinde, yayınların unknown_reserved_topic nedeniyle reddedildiği görünüyor.Eyleyiciler için pub/sub burada yanlış model mi? Yoksa cihazların birbiriyle konuşmasına izin veren bir ayarı mı kaçırıyorum?
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?
Yapay zekâ tarafından English dilinden çevrildi ·
Profildeki Custom topics bunun için değil mi? v1/ dışındaki herhangi bir konuyu kabul eden bir ayar olduğunu hatırlıyorum.
Isn’t that what Custom topics on the profile are for? I remember a setting that accepts any topic outside v1/.
Yapay zekâ tarafından English dilinden çevrildi ·
Özel konular yalnızca gelen yöndedir, yayımlayan cihazın telemetrisi haline gelirler. Ayrıca Hermetry’de cihazlar birbirlerinin mesajlarını hiçbir zaman almaz, dolayısıyla bir fan için yayın yapan bir sensör asla çalışmaz.Ayrıca 14 yıllık tesis deneyimimden: eyleyicinin yanıt vermesini istersiniz. Bir röleye gönder-unut yöntemiyle komut vermek, kontrol odasında açık görünen ama odada kapalı olan bir fanla sonuçlanmanın yoludur.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Tamam, bu mantıklı. Peki bir şey fan kartına nasıl iniyor? Depo amiri için yine bir yerde bir butona ihtiyacım var.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunu 140 otel odasındaki fan coil vanalarında yapıyoruz, bu yüzden kurulumumuzu aşağıda anlatıyorum.Hermetry komutları cihaza kendi downlink konusu üzerinden gönderir. Fan kartı v1/rpc/req/+ konusuna abone olur; komut v1/rpc/req/<id> olarak, bir method ve params ile gelir ve kart yanıtını v1/rpc/res/<id> üzerinden verir. Konudaki id, yanıtın eşleştirilme yoludur.Fan profilinde Commands sekmesini açın ve bir komut ekleyin; örneğin method fan.set, tipi Yes/no olan tek bir parametre on, tier Basic. Basic önemli, çünkü bir dashboard Switch yalnızca Basic tier komutları gönderir. Sonra supervisor’daki karta bir Switch kartı ekleyin, eylemi kontrolün değeriyle Run a command fan.set olsun ve Current state, kartın değiştirdikten sonra bildirdiği bir telemetri anahtarına bağlansın; biz fan.on kullanıyoruz.Arduino tarafı kabaca PubSubClient ile:
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);
Belgelere göre bir komut iki kez gelebilir, bu yüzden son birkaç id’yi saklayıp tekrarları atlıyoruz. Sayfa: Komutları cihazlara gönderme. Yeniden başlatmadan sonra korunması gereken ayar noktaları (ısıtıcı hedef sıcaklığı) için ise bunun yerine v1/attributes/set üzerindeki paylaşılan öznitelikleri kullanıyoruz; kart bağlanır bağlanmaz bunları ister.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Sahadan bir not: komut setini her zaman bir durum olarak tasarlayın, asla toggle olarak değil. Zaman aşımına uğrayan bir komut yalnızca yanıt gelmediği anlamına gelir, yine de çalışmış olabilir. Supervisor tekrar basarsa, fan.set on iki kez gönderilmesi zararsızdır, fan.toggle iki kez gönderilirse ise fan kapanır.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Çalışıyor. Denetleyici kartındaki anahtar kartı, fan tıklıyor ve durum fan.on olarak geri geliyor.Yanlış yaptığım iki şey vardı. Önce fan.toggle olarak ayarladım, Tyler’ın gönderisinden sonra değiştirdim. Ayrıca aboneliği yalnızca setup() içinde bir kez yapmıştım, bu yüzden komutlar ilk WiFi kopmasına kadar çalışıyordu, sonra bir daha çalışmıyordu. Aboneliği yeniden bağlanma fonksiyonuna taşıdım ve artık kopmalara dayanıyor.
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.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.

