mqtt topics

[Mike Webb]

greetings.
how would you set up the topics system ??

the plan:
we have about 200 "Racks" they carry the shoes from one work station to the next. we would like to attach 8266 processors to each rack so that we can send messages from a pc to each rack. mostly the 8266 processors will be alsleep,

once every 10 minutes they will awake and check in with a pc to find out if theirs anything it should do, such as
turning on a light. then the 8266 goes back to sleep for another 10 minutes. so how would you set up the topics, i'm new

but here what i would do:

pc is subscribed to topic "im_awake"
8266 awakens logs into network subscribes to topic "PC_Commands".
8266 publishes to topic "im_awake" gives it its unique name.
pc publishes to topic "PC_Commands" 8266 unique number and what it should do if anything.

8266 receives subscribed message and reacts if necessary

8266 acknowledges it received the message ?????????????????????????????

8266 unsubscribes to topic "im_awake" ??????????????????????????????

????
8266 goes back to sleep.

so much for how a newbie would do it.
suggestions ??

[Frank Pagliughi]

There's a lot of flexibility in how you can arrange topics and payloads to achieve something like this. For example, you can use the rack number as part of the topic string, or put it in the payload. I tend to use it in the topic, since that then gives a lot of flexibility in message subscriptions. You can subscribe to messages from all the racks, a single one, or any combination.

I tend to start at the top of the topic hierarchy by separating out "commands", "data", "events", "alarms", etc. So, you could have topics like:
  commands/rack/<cmd>/<racknum>
  events/rack/<evt>/<racknum>

I would thing that a rack waking up is an event. So, when rack #5 wakes up it would publish a message on topic:
  events/rack/wakeup/5

The payload can be anything else that's helpful. A timestamp, maybe. Does the rack keep an inventory of barcodes? Put them in the payload, if you want.

The PC would then be subscribed to a wildcard topic to receive all events:
  events/#

It can then parse the topic string to figure out that it was a wakeup event from #5, and send the command(s), like:
  commands/rack/do_something/5

In this case, the payload would be any parameters required by the "do_something" command.

The other question is what to do while the device is sleeping. For a fairly local group of devices I would just connect on each wakeup and disconnect before going back to sleep. The Client ID for each device/rack can use the unique rack number as part of the ID, and then you can create a persistent (non-clean) session, and get any messages queued for the device while it was sleeping.

Frank

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Mike Webb]

"topic hierarchy" this looks like a good thing, right now theres just a couple of things that the 8266 has to do. if commanded blink the yellow led or if commanded blink the red led. BUT, i see mission creep coming. keeping the topic in an hierarchy will help with mission creep. let me study the topic hierarchy thing a little more.

"Does the rack keep an inventory of barcodes?" no. the pc knows whats in the rack.

"wildcard topic" i'm a newbie. i'll study it. but i think i get the idea.

"a persistent (non-clean) session" i not even sure what that means, i'll study it.

thanks frank, i feel like your pointing me in the right direction.

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.

[Mike Webb]

"topic hierarchy" this looks like a good thing, right now theres just a couple of things that the 8266 has to do. if commanded blink the yellow led or if commanded blink the red led. BUT, i see mission creep coming. keeping the topic in an hierarchy will help with mission creep. let me study the topic hierarchy alittle more.

"Does the rack keep an inventory of barcodes?" no. the pc knows whats in the rack.

"wildcard topic" i'm a newbie. i'll study it. but i get the idea.

"a persistent (non-clean) session" i not even sure what that means, i'll study it.

thanks frank, i feel like your pointing me in the right direction.

On Thu, Oct 26, 2017 at 8:40 AM, Frank Pagliughi <fpagl...@mindspring.com> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.

[Mike Webb]

maybe we also have 8266's at each  work station. mission creep. how does this topic hierarchy look to you.

level top:

under top

racks and stations

under racks

rack id of rack

under rackid

cmd,data,events,alarms

so a rack could wake up and sub as so:

top/racks/(rack id of rack)/+

pc could sub as so:

top/+

[Frank Pagliughi]

Mission Creep. Yup.

The trick is to come up with something that is that lets you add new components that you haven't even thought of yet without having to re-work the whole system. After you track the racks and workstations, someone will think to add environmental sensors, then position reporting, then inventory control, and on and on. No problem.

Keep in mind the two types of wildcards, "+" and "#"

"+" matches a single level
"#" matches multiple levels. It's placed at the end of a subscription to indicate "match all remaining levels".

Think about how you could use them to make meaningful matches for both the PC and the individual racks, etc. That will help you to figure out if the topic hierarchy works for you.

Frank

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.