[request] Slack Bot Integration (Notification Plugin)

[JohannesFerner]

To further improve the notication possibilities a slack-bot would be nice plugin:

https://www.npmjs.com/package/slackbots

[JohannesFerner]

Hi @askmike i did work on this yesterday and think it would be at a useable state already... but one important question/possible bug.

Why is the loading of the plugins different if you start it as in cli mode vs. --ui mode. I did a quick test and had some console.log('hello from slackbot') in my slackbot.js.

Running some Stuff in CLI mode prints "Hello from slack" -> loads the plugin. Starting the same Backtest, Watcher ... in --ui mode does not load the plugins.

The reason for this is https://github.com/askmike/gekko/blob/feature/ui-trader/gekko.js#L43.

Did you intentionally exit at Line 43 ?

This results in a state where there are only some of the installed plugins loaded.

[askmike]

hey,

I have to give some context first:

When you start a gekko (live gekko, trader, backtester, whatever) you start a pipeline. A pipeline is a market + a bunch of plugins.

Gekko used to be CLI focussed (there was no UI), so a lot of plugins were added that do things like sending messages (email, telegram, etc) whenever something happens (price, advice, etc).

Under the hood all gekkos that you run have a pipeline, which mean they have a config that specifies what plugins are ran over what market. But the UI is a "wrapper": when you run node gekko --ui you don't actually start any pipeline, you start a small webserver that allows you to later run pipelines through the interface (so the reason I intentially exit at line 43 is because starting an UI is not running a pipeline right away).

---

So two important things:

• Plugins used to be the most exciting things you can do with Gekko, but ever since the UI the main goal has shifted as a "tool" to test / measure / try strategies. If you want to use gekko as a slackbot, emailbot, telegrambot, etc. you are better off running a CLI version on a server that runs 24/7.
• If you want to add a plugin to gekkos that are ran through the UI, you need to make sure that the right config ends up being used. The easiest place for this is this default config that all UI gekkos use:

https://github.com/askmike/gekko/blob/feature/ui-trader/web/routes/baseConfig.js

[JohannesFerner]

Hi @askmike,

thanks for the Info, i think this would be an important information for the readme/wiki (Configuration Section). I'll try to implement my use-case : cloud or raspberry hosted notification center focused on several TA based strategies.

I will most likely get back to you here - or maybe you would consider opening a slack community for gekko to have a plattform where devs can ask questions, share informations without opening "discussion"-issues.

br. Johannes

[JohannesFerner]

@askmike wouldn't it be more convenient to have the cli and ui config extend a root-config, so that you could run the same system state either with UI or headless.

[askmike]

I see your point, but that would require users to understand the concept of config files and what role they play in a gekko. I am not sure everyone would expect editing one config file to run a chat bot 24/7 having an impact on everything else they do through the UI.

The way I am thinking about Gekko now is that the CLI is really a way to do different things with Gekko:

• UI: if you want to experiment with a strat (backtesting / paper trading), or if you want to trade and watch the strat & results closely (in a chart with statistics).
• CLI: if you know what you want and you want to run something in the background 24/7 (long term trading strat, chat bot, etc).

So in that way I also want to keep the configs seperated, as to reflect that they serve different purposes.

[askmike]

I am closing this as I don't see this as an existing issue. I am very open to a PR and if you have questions let me know!

[JohannesFerner]

Hi @askmike,

don't get me wrong, but where is the point in closing feature requests for upcoming versions and also flagging them as open-for-pulls.

If i would see a closed issue like this with "open-for-pulls" i would consider it already done, which this and the other issues arent.

Open Issues with "open-for-pulls" would signal to other developers that this would be a point to start off and extend the project.

I would consider the slackbot-integration still as a valid request according to the https://github.com/askmike/gekko/blob/stable/CONTRIBUTING.md#feature-requests

br.

[askmike]

Hey @JohannesFerner

I am just trying to get rid of the backlog of ~90 open "issues" which are not actually issues. This issue is a feature request, and the "open-for-pulls" tag means that I am open into accepting pull requests. I assume that before people actually start coding they would read the issue (and not just the tag + title), in which case the second sentence reads:

Hi @askmike i did work on this yesterday and think it would be at a useable state already (...)

If someone who wants to add slack stumbles across that sentence in combination with the open-for-pulls they can for themselves decide to create a new PR or not (what if that person reads it ~6 months from now and there is still no slack plugin)?

---

What my train of thought is:

• an issue describing a feature request is an open question whether something can be added to Gekko. Once it is clear if/how/by whom the issue can be closed and:
• someone can start working on a PR (just propose a WIP PR once you have code like #793) where the implementation discussion can be moved to.
• once implementation is done (and accepted) the PR can be merged which closes that PR.

If I don't stick to this I run into "feature requests" that people are supposedly working on for years and clogging up the "issues" bug tracker.