Is MQTT available to use in Rockstor

kysdaddy · July 29, 2018, 4:08pm

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.

Chas

HBDK · September 2, 2018, 6:51am

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.

HBDK · September 3, 2018, 3:17pm

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

phillxnet · September 3, 2018, 5:20pm

@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:

github.com/rockstor/rockstor-core

Add support for mounting a particular device in Rockon

opened 07:49PM - 31 Aug 18 UTC

closed 11:52AM - 22 Sep 18 UTC

FroggyFlox

I've been interested in trying to help improving the functionalities of the Rock…on system following several obstacles I've encountered (multiple containers, custom `docker run` command argument, other `docker run` options) for a while now, but never dared digging through the code. Recently, however, I started looking into taking advantage of a new functionality of the EmbyServer container: hardware transcoding. Unfortunately, this would require the RockOn to support the `--device` option to `docker run`. As mentioned in the corresponding issue (https://github.com/rockstor/rockon-registry/issues/152), I was thus thinking to implement support for a new _**Devices**_ object in the JSON files. This object would follow the same structure as the _**Environment**_ object, with `"description"` and `"label"` fields in the JSON file triggering a new page in the Rockon install wizard for the user to input a custom device path (`/dev/dri/renderD128` for instance). ``` { "description": "path to hardware transcoding device (/dev/dri/renderD128)", "label": "VAAPI device" } ``` I started working on it and modify the files I believe are involved in such a process (https://github.com/FroggyFlox/rockstor-core/tree/RockOn_device_option), but am hitting an obstacle in figuring out what's wrong. The problem I'm facing is that I do not get the Rockon install wizard to open a new page related to the _**Devices**_ object I'm trying to implement. While I can read and understand more or less the intent behind the Python code, I am not familiar enough with Javascript to even understand whether my issue lies first in the frontend or backend. Would anyone be kind enough to offer some pointer(s)? I've been testing the following changes: https://github.com/FroggyFlox/rockstor-core/tree/RockOn_device_option With the following JSON file: https://github.com/FroggyFlox/rockon-registry/blob/emby_dotNET/embyserver.json

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.

HBDK · September 3, 2018, 5:59pm

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.

phillxnet · September 22, 2018, 4:46pm

@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.

HBDK · October 10, 2018, 4:38pm

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

Flox · October 13, 2018, 9:00pm

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?

HBDK · October 13, 2018, 9:22pm

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.

Flox · October 13, 2018, 10:53pm

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

HBDK · October 14, 2018, 8:03pm

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.