Configurator

[dev-foo-bar]

Hello,

short summery about the changes:

• added an automatic configurator (creates config from available scripts in the script folder)
• added a structure for the configurator (see the ./scripts/README.md) for details
• added a the 3-step-evergreen for installing / debug build / configuration / reinstall / uninstall (see README.md for details)
• added a systemd user service for ha-mqtt-iot (based on your install_systemd.sh -> but now with variable pathes .... - generation
  is take care of in the Makefile

tested on:

• Arch Linux (amd64)
• Ubuntu Linux (amd64)
• Raspbian Buster (arm7l)

Would be great if you can merge this upstream. Yes I know its a huge merge - but I don't want to bore you with less untested or unfinished code.

Kind regards

dev-foo-bar

[W-Floyd]

I've taken a very brief look through, though not enough to merge yet, just didn't want to leave you hanging. My immediate thought is that - assuming this doesn't alter existing functionality - I'll be willing to merge.

---

That being said, here are my thoughts for future work on ha-mqtt-iot as a whole, and some reasoning. This isn't intended to discourage you from working on the tool however you like (it's open source, go for it), just provide some insight for the direction I'd like to go, hopefully to make merges easier.

I would want to move towards a Go based solution that will do all the same work internally (so, just some simple toggles in the config). It shouldn't be too hard to write a custom bit of code that can hook into the same functions that call the scripts and provide the same functionality.

As an intermediate step, the existing functionality could be made into a separate portion of the tool that is run only when an argument is called, for example, ./ha-mqtt-iot config-builder to create a config based on the local system, then ./ha-mqtt-iot to actually run it. That would be the easiest transition perhaps, assuming scripts are robust enough.

The reason I would prefer an internal solution (in Golang, not scripts) is for interoperability concerns - it is much easier to build a Windows/Mac OS version of the tool when built in devices do not depend on scripting and tools. To be clear, I use neither Windows nor Mac OS at home, but it would all the same be desirable for the sake of others (most users are on Windows, after all)

As a personal preference, I also prefer not to use Makefiles and the like for Golang projects.

PS: I really do appreciate the time and effort going into this, I'm sorry I can't be more responsive.

[dev-foo-bar]

Hi,

thanks for your message. First off all, thanks for the insides. I see the problem with the platform with the platform in/dependency. Firstly I have to mention that I am not a go developer (and not even a developer :-)). So the only way to contribute from my side is with some scripts and a little bit of python.

I am not an english native speaker - so due to you message - I have to ask some questions back:

a) As far as I understand you - you like to "transfer" or "add" some functionality, which is actually covered by one or more scripts to ha-mqtt-iot natively?
b) Furthermore I unterstand that you like to keep the "call a script inside the scripts" function (my main reason to use ha-mqtt-iot). Is this correct?

If you can answer both questions with yes - I have the following proposal:

• You close my merge request
• I rewrite the config generator, that it is located near by the linux scripts. Finally it drops a config.json in the main directory or to stdout --- until you implement it in go.
• I remove the installer (so you get rid of the ./configure, make ....)
• I replace the makefile with a simple install_systemd_user_service.sh
• To enhance the plattfrom indenpency we move the scripts to a sub directory which is called linux and create folders windows and macos. So we finally receive the following structure:

scripts/linux/ <- location for linux scripts
scripts/macos/ <- location for macos scripts
scripts/windows/ <- location for windows foo 
scripts/generator/ <- location for the config generator (meanwile) 

So it should be easier to contribute scripts, etc for the different platforms, until you included the functionallity internally in ha-mqtt-iot.

This proposal has the following advantages:
a) its easier to contribute new scripts for a plattform
b) it interfears only a little bit with the structure of the current project (only the location of the script)

What do you think - is this a good solution to keep your project goals in focus and open a way for me to contribute to your project with shell scripts and the config generator?

[W-Floyd]

a) As far as I understand you - you like to "transfer" or "add" some functionality, which is actually covered by one or more scripts to ha-mqtt-iot natively?

Eventually, yes, but that will take time and effort - scripts are still the way forward for now.

b) Furthermore I unterstand that you like to keep the "call a script inside the scripts" function (my main reason to use ha-mqtt-iot). Is this correct?

Absolutely - I will always support running custom scripts, that's the main goal of the project.

* You close my merge request

I could, but let's wait until I can review this more - I don't think we need to throw anything out just yet

* I rewrite the config generator, that it is located near by the linux scripts. Finally it drops a config.json in the main directory or to stdout --- until you implement it in go.
* I remove the installer (so you get rid of the ./configure, make ....)
* I replace the makefile with a simple install_systemd_user_service.sh

Again, could do, but I want to see what you already have first, it could be fine as is.

* To enhance the plattfrom indenpency we move the scripts to a sub directory which is called linux and create folders windows and macos. So we finally receive the following structure:

scripts/linux/ <- location for linux scripts
scripts/macos/ <- location for macos scripts
scripts/windows/ <- location for windows foo 
scripts/generator/ <- location for the config generator (meanwile) 

So it should be easier to contribute scripts, etc for the different platforms, until you included the functionallity internally in ha-mqtt-iot.

That actually sounds like a good plan. I don't know the details of what scripts we'd need on Windows, but I'm pretty sure we could make that work. Assuming some scripts are portable across Linux/Mac OS, we can symlink them (if somebody can test)

This proposal has the following advantages: a) its easier to contribute new scripts for a plattform b) it interfears only a little bit with the structure of the current project (only the location of the script)

Agreed.

What do you think - is this a good solution to keep your project goals in focus and open a way for me to contribute to your project with shell scripts and the config generator?

I think this is a great plan, other than closing this. Perhaps we can adapt this PR, or I might still merge and we can work from there.

[W-Floyd]

Just a note that I still want to look at this at some stage, just haven't made the time.