# Home Rolled MQTT Module **URL:** \ **Category:** Module Development\ **Created:** [November 23, 2022, 8:09pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873 "2022-11-23T20:09:29Z")\ **Posts on this page:** 15\ **Page:** 2
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 24, 2022, 1:43am UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/21 "2022-11-24T01:43:06Z")
When I started poking at my new driver, I thought it would be two, three months. Closing in on 18. (Not full time, though.) ---
**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\ **Post date:** [November 24, 2022, 2:20am UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/22 "2022-11-24T02:20:47Z")
Interesting discussion. I should note that our specific application is just to have a way to subscribe to messages. These messages are from package scan tunnels where packages move quick fast so the value to look at a single tag value is almost zero. Actually if all scan tunnel messages go to one topic and we subscribe to that one topic, it'd be somewhere in the range of 1,000 messages per minute. Instead, we just need a way to grab the messages and then store them to database. Only once they have been stored and then analytics can be run on them do they become useful. I'm actually thinking about doing "buffered MQTT" so that the messages can come in as fast as they like and we only have to deal with them once per second as a comma separated string, very similar to the way we do [Buffered TCP](https://github.com/Freeno83/buffered-tcp-module). But instead of an actual buffer, just stick them in an array or similar and then empty it out every one second. Nick ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 24, 2022, 2:24am UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/23 "2022-11-24T02:24:39Z")
Consider a ring buffer, where each entry (scan string?) publishes via MQTT. The tunnel just advances to the next, wrapping around, for each scan. With 100 items in the ring, each would publish 10 per minute. Very reasonable time period to handle on the subscriber end. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [November 24, 2022, 7:05pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/24 "2022-11-24T19:05:40Z")
I was wrong, it looks like as SP/Tahu approaches 1.0 it now includes a Host Application API as well: [tahu/java/lib/host/src/main/java/org/eclipse/tahu/host at master · eclipse/tahu · GitHub](https://github.com/eclipse/tahu/tree/master/java/lib/host/src/main/java/org/eclipse/tahu/host) This looks like it would significantly lower the barrier to building the host side of a SP setup. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [November 24, 2022, 11:13pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/25 "2022-11-24T23:13:18Z")
Ready by Christmas, then? 🙂 ---
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [November 28, 2022, 4:58pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/26 "2022-11-28T16:58:11Z")
We are working towards making a full parallel tag tree mirroring our MQTT Engine tags. We have continuously bumped into cases where the functionality and behavior of native MQTT Engine tags are lacking or different compared to other Ignition tags. But we discovered that most (all?) of those bad behaviors didn't happen on a reference tag pointing at the MQTT Engine tag. We don't even want to rename/reorganize the tags, we just want the more consistent functionality. Our plan is to auto-create a tree of reference tags that mirror the edge node tags in name and everything. We've been re-checking all of our views and scripts to find and fix every place that had `[MQTT Engine]` coded in the tag paths and make them all dynamic for when we switch, and also been creating the scripts that will notice new MQTT Engine tags and create the reference tags on the fly while moving any "legacy" alarm or history settings from the MQTT Engine tags to the new copies. It's a bear of a job. We did not pick this path lightly. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [November 28, 2022, 5:04pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/28 "2022-11-28T17:04:07Z")
> [@justin.brzozoski](#): > > As part of the recent push to Sparkplug 3.0, the open-source reference implementation server in the [Tahu](https://github.com/eclipse/tahu) project has been greatly improved so that it would pass the new compatability tests. I know, see my update post. ---
**Author:** ![eric.hollering](https://avatars.discourse-cdn.com/v4/letter/e/ad7895/32.png) [@eric.hollering](https://forum.inductiveautomation.com/u/eric.hollering)\ **Post date:** [November 28, 2022, 5:15pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/29 "2022-11-28T17:15:15Z")
In reply to the original question, and with the caveat that I have not read the entire thread here yet, yes -- sort of. We created a module that allows MQTT publishing of data from one of our other modules, using the Eclipse Paho library previously mentioned. It's definitely not even close to a one-to-one replacement for the Cirrus Link modules (otherwise we'd probably have just used those). ---
**Author:** ![eric.hollering](https://avatars.discourse-cdn.com/v4/letter/e/ad7895/32.png) [@eric.hollering](https://forum.inductiveautomation.com/u/eric.hollering)\ **Post date:** [November 28, 2022, 5:29pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/30 "2022-11-28T17:29:31Z")
> SparkPlug isn’t totally decentralized or uncoupled. One subscriber must be acting as the “primary” application, responsible for monitoring and control of the Edge nodes (publishers). There can be other subscribers that are purely observing, or waiting in standby to take over, but something needs to be acting as primary. Was reviewing the Sparkplug repo recently in hopes that version C would be a little more flexible than B and noticed this. > > > From \[discussion on Slack\](https://eclipse-sparkplug-wg.slack.com/archives/CSVE8…KWHF/p1645190273389259) started by \[Rick Bullotta\](https://app.slack.com/team/U033DJ00KB8) > > For the Host there is no difference to it whether it is a primary host or not. > For the edge, really the significance is "do something with the STATE/host\_id topic of a particular host. > > So all of the functionality around the concept of Primary hosts can be summarized as: > "Edge Nodes may be configured to treat one or more Hosts as a Host of Interest, and perform certain actions on STATE/host\_id payloads." > > If it is felt that it is neccessary, the specific example of a primary host may be included > "This might be for example configuring one Host as the Primary Host, and the Edge would Rebirth as soon as it noticed a state transition from OFFLINE to ONLINE. Or, when the Primary Host is OFFLINE, the edge may store data value changes for later transmission as historical metrics." ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [November 28, 2022, 7:12pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/31 "2022-11-28T19:12:57Z")
> [@justin.brzozoski](#): > > Our plan is to auto-create a tree of reference tags that mirror the edge node tags in name and everything. This is exactly what we ended up doing, and also auto adding history to mqtt tags as well ---
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [November 28, 2022, 7:19pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/32 "2022-11-28T19:19:22Z")
> [@nminchin](#): > > This is exactly what we ended up doing, and also auto adding history to mqtt tags as well We're moving the history to the reference tags instead of the MQTT Engine tags. It uses a more informative quality code for backfilled data (MQTT Engine just marks backfilled data as "Good") and also can optionally use scaling properly on history. If you backfill history on a scaled MQTT Engine tag, it is stored differently than non-backfilled data and history queries on that tag will jump back and forth between properly and improperly scaled values. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [November 28, 2022, 7:31pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/33 "2022-11-28T19:31:27Z")
Interesting to know. Your derived tags won't have backfilled history though, so are you just making do without it, or come up with a workaround? ---
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [November 28, 2022, 7:33pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/34 "2022-11-28T19:33:36Z")
> [@nminchin](#): > > Your derived tags won't have backfilled history though, so are you just making do without it, or come up with a workaround? If you ensure that "Store Historical Events" is disabled on MQTT Engine config and that "Allow Back-fill Data" is enabled on the tag provider holding the reference tags, the reference tags WILL get backfilled history! (This latter option is a new feature in the past year-ish?) ---
**Author:** ![shc](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/shc/32/4918_2.png) [@shc](https://forum.inductiveautomation.com/u/shc)\ **Post date:** [November 29, 2022, 10:29am UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/35 "2022-11-29T10:29:16Z")
Hi, we have done one already,,with client and broker,, ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 29, 2022, 1:39pm UTC](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873/36 "2022-11-29T13:39:41Z")
Perhaps you should PM the OP and make a commercial deal. Or publish the module you've created. [Previous page](https://forum.inductiveautomation.com/t/home-rolled-mqtt-module/66873.md?page=1)