Traduit de English par IA ·
Sans doute une question de débutant complet. Nous testons la surveillance des chambres froides dans notre entrepôt logistique. Six cartes ESP32 publient des températures sur v1/telemetry, et cela fonctionne bien, le graphique et l’alarme sont en place.Je veux maintenant ajouter des actionneurs : des résistances chauffantes pour le cadre des portes et deux ventilateurs supplémentaires, chacun sur une carte relais avec un ESP32. Dans ma tête, le pub/sub fonctionne dans les deux sens. Mon plan était donc le suivant : la carte du ventilateur s’abonne à warehouse/zone3/fan/set, et quelque chose (un bouton de tableau de bord ? un script ?) publie on ou off sur ce topic.J’ai donc testé depuis mon ordinateur portable avec paho-mqtt, connecté en tant que l’un des appareils de capteurs, et publié sur v1/zone3/fan/set. Rien n’est arrivé sur la carte du ventilateur. Après trois tentatives, la connexion de mon ordinateur portable a été fermée. L’onglet Journal de cet appareil de capteur indique que les publications ont été rejetées avec unknown_reserved_topic.Le pub/sub est-il tout simplement le mauvais modèle pour les actionneurs ici ? Ou bien me manque-t-il un paramètre qui permet aux appareils de communiquer entre eux ?
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?
Traduit de English par IA ·
N’est-ce pas à cela que servent les Custom topics du profil ? Je me souviens d’un paramètre qui accepte n’importe quel topic en dehors de v1/.
Isn’t that what Custom topics on the profile are for? I remember a setting that accepts any topic outside v1/.
Traduit de English par IA ·
Les topics personnalisés sont uniquement entrants, ils deviennent la télémétrie de l’appareil qui a publié. Et les appareils ne reçoivent jamais les messages des autres dans Hermetry, donc un capteur qui publie pour un ventilateur ne fonctionnera jamais.Également, d’après 14 ans de travail en usine : vous voulez que l’actionneur réponde. Le fire and forget vers un relais, c’est le moyen de se retrouver avec un ventilateur qui s’affiche en marche en salle de contrôle et qui est à l’arrêt dans la pièce.
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.
Traduit de English par IA ·
ok ça a du sens. Alors comment une commande descend-elle jusqu’à la carte du ventilateur ? J’ai encore besoin d’un bouton quelque part pour le superviseur de l’entrepôt.
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.
Traduit de English par IA ·
Nous avons des vannes fan coil dans 140 chambres d’hôtel qui fonctionnent ainsi, voici donc notre configuration.Hermetry envoie les commandes à l’appareil sur son propre topic de downlink. La carte du ventilateur s’abonne à v1/rpc/req/+, une commande arrive sous la forme v1/rpc/req/<id> avec une méthode et des paramètres, et la carte répond sur v1/rpc/res/<id>. L’id dans le topic sert à associer la réponse.Dans le profil du ventilateur, ouvrez l’onglet Commands et ajoutez une commande, par exemple la méthode fan.set, un paramètre on de type Yes/no, tier Basic. Basic compte, car un Switch du tableau de bord n’envoie que des commandes de tier Basic. Ensuite, donnez à la carte du superviseur une carte Switch dont l’action est Run a command fan.set avec la valeur du contrôle, et liez le Current state à une clé de télémétrie que la carte publie après avoir commuté ; nous utilisons fan.on.Côté Arduino, en gros avec 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 doc indique qu’une commande peut arriver deux fois, donc nous gardons les derniers ids et ignorons les répétitions. Page : Envoyer des commandes aux appareils. Pour les consignes qui doivent survivre à un redémarrage (température cible du chauffage), nous utilisons plutôt les attributs partagés sur v1/attributes/set ; la carte les demande juste après la connexion.
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.
Traduit de English par IA ·
Un retour de terrain : faites de l’ensemble des commandes un état, jamais un basculement. Une commande qui expire signifie seulement qu’aucune réponse n’est revenue, elle a peut-être quand même été exécutée. Si le superviseur renvoie la commande, fan.set on envoyée deux fois est sans effet, tandis que fan.toggle envoyée deux fois éteint le ventilateur.
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.
Traduit de English par IA ·
Ça marche. Carte de commutation sur la carte superviseur, le ventilateur clique, et l’état revient sous la forme fan.on.Deux choses que j’avais mal faites. Je l’avais d’abord réglé sur fan.toggle, puis changé après le message de Tyler. Et je ne m’étais abonné qu’une seule fois dans setup(), donc les commandes fonctionnaient jusqu’à la première coupure WiFi, puis plus jamais. J’ai déplacé l’abonnement dans la fonction de reconnexion et il tient maintenant.
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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.