Price change alarm always updating

[drpout]

Price change alarm always updating

[dllud]

Yes, you are right. Price change alarms fetch the value from the exchange only at the end of the time frame.

the target price change can occur before timeframe has been expired

What seems you would like to have has a different semantic from Boilr's price change alarms (and any other price change alarms we have seen).

What happens to the price in between should be of no concern to you. For instance, if you set a daily alarm, it should be of no concern if the price drops 50% in the morning and rises 50% in the afternoon, what matters is that it stayed the same after 24h had gone by. If you need to track changes with a finer granularity you have to set a shorter time frame and perhaps a smaller change.

[xeverse]

Hmm, i see, thx.
Maybe u can add another alert type then
which will take care about what's happening in between?

[dllud]

To track what happens in between just set an alarm with a smaller time frame.

It seems that what you want is something that tracks price change independent of time frame. You would just define an update interval. However we would need a base price for change comparison. Which price would be used as base? A user defined value, e.g. the price at the time she set the alarm?

In Boilr's price change alarms the base price is the previously retrieved one. For instance, for a 24h alarm it is comparing today's price with yesterday's price. Then it stores today's price which will be compared with tomorrow's price and so on.

[xeverse]

The price at the other edge of the rolling timeframe:
i.e. if tf== 5h >> change for the last 5h and now.
Timeframe 5h. Update interv 1m. Price Change: 3%
If the price drops/rises quickly all of a sudden it wakes up.
And not If the price has been sliding slowly for the last 5h within 3%

[dllud]

(Edited: I hadn't read the 2nd part of your post.)

Now I see what you want and seems doable. I wonder if I should implement it has an option for the current price change alarm or as a new alarm type.

[algazarra]

Thought about submitting this earlier, but concluded the solution was having a smaller timeframe. If not mistaken, the requested feature is already present. It's just a matter of setting it right. Maybe instead of a new alarm type, have some kind of preset.

[dllud]

Not really, what @xeverse is asking for is slightly different from what Boilr has. Although it can be emulated with a shorter timeframe and a smaller change.

Timeframe 5h. Update interv 1m. Price Change: 3%
If the price drops/rises quickly all of a sudden it wakes up.

That is, it doesn't wait until 5h have gone by. It checks in a 1m interval and triggers if there is a 3% change. The timeframe is just used to define the base prices, e.g. the price used as base for change calculation is substituted every 5h.

@cicardia Have you seen anyone using something like this? Do you consider it useful?

[algazarra]

Personally, i wouldn t use this. But each trader has his own style.

What's being asked is a price variation alarm independent of any time frame. Base price is set, and if there's a spike the alarm sounds. as I see it, this is a variation of the price change alarm. if implemented, it should be in the price change alarm settings, and not in a new alarm type.

BTW, one of the flaws I see in price change alarm is that you only get the warning by the end of the timeframe. But you could have the change before the interval ends. This makes price change alarm slow. Maybe too slow for most traders.

Is it possible to have the alarm as soon as there's enough price change instead of waiting for the timeframe to end?

[dllud]

Is it possible to have the alarm as soon as there's enough price change instead of waiting for the timeframe to end?

That is exactly what @xeverse is asking for! Please re-read the discussing. As I said:

[This new alarm] has a different semantic from Boilr's price change alarms [...].
What happens to the price in between should be of no concern to you. For instance, if you set a daily alarm, it should be of no concern if the price drops 50% in the morning and rises 50% in the afternoon, what matters is that it stayed the same after 24h had gone by.

What you are describing would trigger the alarm with the 50% drop in the morning, That is a different semantic, which some traders will dislike. However, as it seems useful to both of you we can implement it as an option to the price change alarm. How would you name it? "Always updating" isn't clear enough.

[algazarra]

Sorry for the incoherence guys. Tough times clouding my mind.
As said, the price change alarm structure is flawed. Please follow @xeverse suggestion and change the price change alarm structure to the proposed one. Price change should only work that way. Setting a time interval isn't useful. What a user expects from such alarms is to be warned of sudden spikes pronto. Though not every trader's style, it's still a useful alarm and this will render it a lot more efficient. again, sorry for my last post.

[dllud]

I do not agree it should only work that way. I can see many users preferring the current semantic.

I will add the "alert about spikes" as an option to the Price Change alarm. It will then require the input of an update interval (default to 30s) besides the timeframe (required to know when to substitute the base value).

[algazarra]

I can only foresee interest in the current semantic for future, more complex alarms. Right now, seems like it will render it more confusing. If you insist on keeping both versions, would it be possible to use @xeverse suggestion as the default for the Price Change Alarms?

let's use "spike alert" or "panic alert", instead of "alert about spikes". Plus, this alarm is already targeting premium prices, speed is a must. The default update should be smaller. I'd suggest 5s. As for the timeframe, why not use the 1m, 5m, 15m, 30m, 1h, 2h, 4h, 6h, 12h, 1d, 3d, 1w, like candlestick charts?

[dllud]

The timeframe input will be in minutes like it is now. Though, I agree we should update the interface and use a scrollable list with 1m, ..., 1w but still leaving the minutes input box somewhere for those wanting a non-standard timeframe. This will be implement in conjunction with #48 and #49.