Traducido del English por IA ·
Probablemente sea una pregunta de principiante total. Estamos piloteando la monitorización de cámaras frigoríficas en nuestro almacén logístico. Seis placas ESP32 publican temperaturas en v1/telemetry y eso funciona bien, el gráfico y la alarma están listos.Ahora quiero actuadores: resistencias calefactoras del marco de las puertas y dos ventiladores adicionales, cada uno en una placa de relés con un ESP32. En mi cabeza, pub/sub funciona en ambos sentidos, así que mi plan era: la placa del ventilador se suscribe a warehouse/zone3/fan/set, y algo (¿un botón del panel?, ¿un script?) publica on u off en ese topic.Así que lo probé desde mi portátil con paho-mqtt, conectado como uno de los dispositivos sensores, y publiqué en v1/zone3/fan/set. No llegó nada a la placa del ventilador. Después de tres intentos, se cerró la conexión de mi portátil. La pestaña Log de ese dispositivo sensor muestra que las publicaciones fueron rechazadas como unknown_reserved_topic.¿Es pub/sub simplemente el modelo equivocado para los actuadores aquí? ¿O me falta algún ajuste que permita a los dispositivos comunicarse entre sí?
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?
Traducido del English por IA ·
¿No es para eso la opción Custom topics del perfil? Recuerdo un ajuste que acepta cualquier topic fuera de v1/.
Isn’t that what Custom topics on the profile are for? I remember a setting that accepts any topic outside v1/.
Traducido del English por IA ·
Los topics personalizados son solo de entrada, se convierten en telemetría del dispositivo que publicó. Y los dispositivos nunca reciben los mensajes de otros en Hermetry, así que un sensor que publique para un ventilador nunca funcionará.Además, por 14 años de trabajo en planta: quiere que el actuador responda. Enviar sin confirmación a un relé es la forma de acabar con un ventilador que aparece encendido en la sala de control y está apagado en la sala.
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.
Traducido del English por IA ·
ok, eso tiene sentido. Entonces, ¿cómo llega algo hasta la placa del ventilador? Todavía necesito un botón en algún sitio para el supervisor del almacén.
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.
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.
Traducido del English por IA ·
Una cosa de campo: haga que el conjunto de comandos sea un estado, nunca un cambio de estado (toggle). Un comando que caduca solo significa que no llegó respuesta; es posible que se haya ejecutado igualmente. Si el supervisor vuelve a pulsar, fan.set on enviado dos veces es inofensivo, pero fan.toggle enviado dos veces apaga el ventilador.
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.
Traducido del English por IA ·
Funciona. Tarjeta de conmutación en la placa supervisora, el ventilador hace clic y el estado vuelve como fan.on.Dos cosas que tenía mal. Al principio lo puse como fan.toggle, y lo cambié después del mensaje de Tyler. Y solo me suscribí una vez en setup(), así que los comandos funcionaban hasta la primera caída de WiFi y luego nunca más. Moví la suscripción a la función de reconexión y ahora sobrevive.
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.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.