topics, brokers, mount_points, and light bulbs, oh my

[holla2040]

Here's an architecture question that I have not seen implemented
anywhere. This deals with physical placement of devices, topic
generation, and turning on a light bulb. You may want to read about a
mount_point here, http://mosquitto.org/man/mosquitto-conf-5.html.

This is a little involved but you'll get the picture quickly.

Let's say that light bulbs have a zigbee radio, a UID and know they
are a light bulb. These light bulbs connect a broker in the room they
are physically in and subscribe to
'lightbulb/1234/state'.

The room broker has a UID, knows its a room and connects a floor
broker.
Using its mount_point the subscribes to
'room/conference/#' so pub to
'room/conference/lightbulb/1234/state' gets routed to the
lightbulb

The floor broker has a UID, knows its a floor and connects a building
broker.
Using its mount_point the subscribes to
'floor/17/#' so pub to
'floor/17/room/conference/lightbulb/1234/state' gets routed to the
lightbulb

The building broker has a UID, knows its a building and connects a
cloud broker.
Using its mount_point the subscribes to
'building/17_Elm_St/#' so pub to
'building/17_Elm_St/floor/17/room/conference/lightbulb/1234/state'
gets routed to the lightbulb


All the MQTT examples I've seen the lightbulb connects directly to the
cloud broker and subscribes to its topic,
'building/17_Elm_St/floor/17/room/conference/lightbulb/1234/state'
This requires that the lightbulb know physically where it is. This is
unrealistic for massive lightbulb deployments.

To turn on the lightbulb, publish 'on' to
'building/17_Elm_St/floor/17/room/conference/lightbulb/1234/state'
which would go
to the building then
to the floor then
to the room then
to the lightbulb.

This example might seem exaggerated but its not. I don't know how the
IoT will scale without something like this in place.


My company makes solar power modules (the lightbulb) and we'll be
shipping 100's of thousands modules into the field. We want them to
automatically publish and subscribe to their unique topics where their
physical hierarchy is dynamically created. We want to ship modules
with UID only and have their topics show up that reflect their
physical location. A module topic will look like this
customer/brightleaf/location/121apolloroad/frame/17/tracker/a/
position/nw/module/1234/power

I'm about to implement portions of MQTT-S combined with bridging
connections/mount_points to accomplish this. My system design will use
mosquitto on AWS, mosquitto on beaglebone with a zigbee cape, MQTT-S
on avr over zigbee, MQTT-S on avr over half-duplex RS-485, MQTT-S on
avr over opto-isolated serial. Whew!

Anyone have a similar system, technical paper, presentation, etc where
multiple intermediaries exist within the pub-sub architecture?

Thanks for your time.
Craig

I'm the system architect at Brightleaf Technologies. I've been using
mosquitto for a year, with php, python, android, and arduino clients.
My in-house systems publish 250K topics a day and we have 50 million
pubs persisted in our distributed database.
~

[Nicholas O'Leary]

Hi Craig,

I've been working with MQTT for a number of years in IBM.

We've used mount_points in a large scale hierarchical scenario much
like you describe - albeit with RSMB rather than Mosquitto.
It isn't a reference project, so I'm not in a position to share any
specific details, but it is one of a number of architectural patterns
that I'm planning to write up and share.

Let me know if you'd like to discuss further.

Regards,
Nick

> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt

[Roger Light]

On Sat, Feb 25, 2012 at 7:57 PM, Nicholas O'Leary <nick....@gmail.com> wrote:

> it is one of a number of architectural patterns
> that I'm planning to write up and share.

This reminded me of the links I saw a while back about a residency for
writing an MQTT related IBM Redbook. The links don't seem valid now,
but assuming it's running still it's supposed to be starting on the
5th March. Hopefully this sort of pattern is something that would be
described in the redbook.

Cheers,

Roger

[holla2040]

Nick,
Thanks for writing and the encouragement that others are working
within this pattern.

Yes, I'd very much like to discuss further. Can I contact you on
Monday? I'd also like to help with the writing, example generation,
code generation, etc for your write up. Just let me know and I'll
jump right in.
Craig

On Feb 25, 12:57 pm, "Nicholas O'Leary" <nick.ole...@gmail.com> wrote:
> Hi Craig,
>
> I've been working with MQTT for a number of years in IBM.
>
> We've used mount_points in a large scale hierarchical scenario much
> like you describe - albeit with RSMB rather than Mosquitto.
> It isn't a reference project, so I'm not in a position to share any
> specific details, but it is one of a number of architectural patterns
> that I'm planning to write up and share.
>
> Let me know if you'd like to discuss further.
>
> Regards,
> Nick
>

> On 25 February 2012 09:30, holla2040 <holla2...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Here's an architecture question that I have not seen implemented
> > anywhere. This deals with physical placement of devices, topic
> > generation, and turning on a light bulb. You may want to read about a

> > mount_point here,http://mosquitto.org/man/mosquitto-conf-5.html.

> > To learn more about MQTT please visithttp://mqtt.org

[hads]

On Saturday, 25 February 2012 22:30:34 UTC+13, holla2040 wrote:

My company makes solar power modules (the lightbulb) and we'll be
shipping 100's of thousands modules into the field. We want them to
automatically publish and subscribe to their unique topics where their
physical hierarchy is dynamically created. We want to ship modules
with UID only and have their topics show up that reflect their
physical location.

Apologies for the late reply to the thread, I'm just now looking in to something similar myself.

I like the idea of the mount_point hierarchy, I have one question though; how would the modules know the address of the local broker?

hads

[holla2040]

That's a good question. The local broker is acting as a router/gateway so to speak, so the network configuration (wired, wireless) would place the local broker at a router/gateway address, 192.168.0.1 or rs-485 bus address 0 or 255. Otherwise the field entities would need to discover the local broker, which is also fine.