Is MQTT available to use in Rockstor

I run Smartthings in my home and have noticed HomeAssistant is available as a RockOn. After doing some reading I see that HomeAssistant can/will work in conjunction with Smartthings using MQTT and that MQTT can be run in a Docker but not sure if it will run as a rockon.

It should be obvious that I am not very experienced in any of this and I apologize if this is just a stupid question.


i would think that it is very easy. if i can find some time i might make one and post it to my github or create a pull request.

i have uploaded a json file for mosquitto to my github page that seems to work fine on my setup.

1 Like

@HBDK Hello again.

As an aside, I see that a couple of your rock-ons make use of the ‘–device’ component. You might want to keep an eye on @Flox’s recent issue:

which aims to extend the rock-ons system/install UI to include the ability to specify devices. This looks like it would make for an easier install for at least 2 of your rock-ons.

Just a thought.

Cool i have been keeping tvheadend for my self for a long time because of the extra work involved in setting it up.
i think both makemkv and tvheadend would be cool additions if they could be installed without extra work from the command line.

@HBDK As of Rockstor 3.9.2-39 stable channel update @Flox’s ‘–device’ addition to the Rock-on definition files has been merged.

Agreed. With the caveat that if you do end up submitting these Rock-ons they would need some kind of:

“Requires Rockstor 3.9.2-39 or later” put into their descriptions section in the cases where a device reference is required. Older Rockstor versions will, I think, just ignore this new “devices” entry if it exists but of course your two noted Rock-ons require a device specified in order to function at all; hence the description suggestion.

See @Flox’s pending, and very prompt, rock-on registry doc pull request for how it is defined within the Rock-on json file.

Just a thought, and thanks to @Flox for enabling this feature. Now we just need some Rock-ons to use it.

Cool now we just need a way to make environment variables and volumes optional… :wink:

I’m interested in knowing more about your last sentence. Do you mean you would be interested in being able to add ENV or volumes once the Rock-on is already installed or rather not to have to fill some ENV or volume binding during Rock-on install?

the last option, it would some times be nice to be able to leave some of them out.
but only if they are marked as optional in the json file.

Interesting… I have to admit that I do like the idea as I always have to decide what are the options that should be included in the json file and those who shouldn’t for simplicity sake.
Nevertheless, I also like having to make this choice as it motivates me to make the Rock-on install as simple as it can be, resulting in the most user-friendly experience. I try to choose as little complexity as possible during the Rock-on creation process, trying to cover the most general use of the specific Rock-on. If more “specific” options are needed, then, the cli docker-run is still available with all the benefits of volumes/shares management by Rockstor–this is the reason why I personally have the Portainer Rock-on running, for instance.

On a side note, I am currently trying to work on combining these two views by allowing the Rockstor user to add ENV or other customizations allowed by docker run to an already-installed Rock-on. This would correspond to the first case of my previous post, and offer the possibility (hopefully) for more “specific” cases of a Rock-on.
This idea is still fresh in my head so I would welcome any feedback on why it’s terrible or good, whichever it is :wink:

Well i think this MQTT broker would be a good example of a container that could benefit from having optional volumes. i only mapped logs, configurations and data because some people might need all of them, but i think that for alot of uses you wouldn’t need persistent data, log files or special configurations.

if we got the option to add ENV then we might also need a bit more transparency in the ui so it is possible to find the documentation for the containers used without having to look in the json file to figure it out.