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