Thanks. When you say it is failing to auto adjust intensity, are you referring to overheat protection lowering intensities? Or adjusting intensity when idle... or adjusting intensity on a schedule? Debug reports will be helpful any time there is a problem... you can create one in the Tests tab (Create Debug Report button). Then email me the report. The log entries are particularly helpful here, and the Debug report shows the last 50 I think, so it is important to do it either around the time that the problem occurs or to also email me the CGWatcher.exe.log file, as it contains all log entries.

Regarding CGRemote... the core functionality is all working and there will be a closed beta soon, hopefully next week. How soon before release depends on how that goes, but I don't expect too long. The latest version of CGWatcher supports it, though additional features will be added with each new version. I'll be posting more info and updates on the CGRemote page and will create a forum post when it is ready.

That makes sense. I was thinking in terms of one exchange not having a buy order and had forgotten that coinchoose looks at many exchanges. So if there are no buy orders, things definitely do not look good for the coin, at least in short term. If it is resurrected from the dead then coinchoose should pick it back up and its profitability will be updated as usual.

I'll do it this way and set profitability to zero for all three profitability fields. I should have an update either today or tomorrow. There are more scheduled actions I plan on adding so might try to get one or two new ones in this update.

Thanks.

What would be the expected behavior for coins that have dropped off of coinchoose? Should their profitability data remain the same (until they are back on coinchoose or until you close CGWatcher, which loses profitability data)? I would think that would be better than setting profitability to zero, since a buy order could appear at any time causing it to appear back on coinchoose and if I did set profitability to zero, it could potentially switch profiles to mine another coin during this period depending on what you have scheduled.

So I think it is best to ask what users would expect or want it to do before finishing the fix. Thanks in advance for suggestions.

Thanks for the info. I didn't realize coins with no buy orders would drop off completely. I hadn't really thought about it, but I guess I would expect their profitability to be unknown but for them to remain on the site. That is my misunderstanding, I'll be addressing this issue today.

Right now the timers for scheduled actions running every N hours start when CGWatcher starts. They are reset if either a) the action was disabled and is re-enabled, or b) the action is modified (Save button clicked in Schedule Action window). So currently those are the only ways to sync them. I can add an option to reset the timer at a certain time, but I have to think about it a little more so it might be a few days.

I'll also keep the percentage thing in mind as I will be adding more types of actions and triggers soon so this would be a good time to add that option.

A similar problem was reported today in the Newbie thread. I didn't realize coins would drop off of Coinchoose if they had no buy orders. I would have guessed maybe the profitability would be unknown, but not for it to disappear completely. I'll be addressing this issue today.

No, it should not have that effect. It should not ask enough of the GPU to make any noticeable difference. I did have a concern it was possibly having an effect when scrypt mining at intensity 20, but even then it wouldn't be 20% and I think that may have been related to a resolved settings issue anyway. Can you go to the Tests tab and click Create Debug Report, then email me the results? I want to make sure no settings are getting altered before the miner is started.

You can also verify this by starting the miner outside of CGWatcher, and then opening CGWatcher and watching for a drop in hashrate.

Are you using a .bat or .cmd file? This normally shouldn't happen since CGWatcher tries to send the "quit" command to close cgminer so it can shutdown properly (and only kills the process as a last resort), but there are still some issues regarding batch/command files. During testing I created a batch file similar to this:


and what I found was that sending the "quit" command caused cgminer to restart itself... even though it responded correctly ("BYE"). So once I launched the miner using the batch file, the "quit" command would not close it, and cgminer would actually restart (in a new process as usual). Then CGWatcher would pick up this new process and it would close correctly with the "quit" command. So for now it is just killing the process if you're using a batch or command file to launch the miner. I even tried sending "quit" and then killing immediately after up to a few seconds after hoping it would give it time to shutdown... but it didn't matter because the original process is closing, it's just that a new one is starting. The only way to guarantee the miner would close (and not restart itself) was to kill the process. This may be dependent on what is in the batch file, but I have to do more testing to know for sure. It could be related to the setx options? Either way, I'll come up with some way to fix this... maybe creating an option to run a batch file before launching the miner instead of launching the miner through the batch file... although that creates another issue regarding the 2> log command that Windows doesn't seem to like in its process start info arguments.

A temporary workaround would be to not use batch files, but I realize this is necessary sometimes... particularly for scrypt mining (and the 2> log option). So I'm not suggesting this is a fix for everyone, just that if you don't need to use a batch file you're better off not using one. Just move any arguments from the batch file to the profile arguments in CGWatcher (again, with the exception of the 2> log option which I still have to figure out what the problem is.)

If you're not using a .bat or .cmd file, this should not be happening unless cgminer is not closing correctly. If you can email me a debug report (go to Tests tab, click Create Debug Report) I'll see what is happening.



Thanks, and yeah you can use scheduled actions for other things besides profitability mining. There will be additional actions added in the near future and this morning I received some requests for additional actions that are very good ideas.


Edit: To add to this, it was requested that when using a .bat or .cmd file and restarting cgminer, that CGWatcher actually stop and relaunch the .bat/.cmd file rather than just sending the "restart" command to ensure any other commands were executed. This is where the initial problem was discovered by users because the "quit" command was attempting to close the first cgminer, but cgminer was actually restarting itself before closing. Then immediately after, CGWatcher would launch the new cgminer (at this point unaware cgminer had restarted itself), resulting in two instances of cgminer running.

The temporary fix of killing the miner seemed acceptable to the users who reported it, but I did have it on the list to go back and figure out. Then it was sort of neglected as I worked on the schedule stuff so I'm going to look at it again now and try to fix this without killing the process. Though when restarting, I may just stick with killing the process since the miner will be re-launched anyway. To add to the confusion, I am actually trying to reproduce the problem right now as this was all a few weeks ago, and it is closing correctly.

You could use gpu|N, pga|N, and asc|N to get values for truncated devices. Not ideal for a ton of devices but it provides the same info as devs. And not using json should save you some characters and may be able to fit more devices in devs before truncating?

I've addressed this at the bottom of the post, but with how quickly you replied I expect you probably didn't read it all. The chances of CGWatcher having a noticeable impact on any particular coin are doubtful for the reasons I mentioned. Regardless of how I feel about it, it is something many users have asked for. I personally question whether or not it would actually end up being more profitable and I stated this. If you don't convert to bitcoins while the coin you mined is still more profitable, you risk losing any gains and could even end up with less than if you had just mined Bitcoins. And there are miners doing this with or without CGWatcher, like those using cryptoswitcher or their own automated method of switching.

Profitability Mining is mining whatever crypto-coin is most profitable at any given time based on how much it is worth in Bitcoins. This is not a new concept and has been in practice since the first alt-coin appeared. I did not come up with the idea, I just made it easier to do in CGWatcher. I realize Profitability Mining may not be the best name for it, as even mining one coin is done in hopes of being profitable. But I have to refer to it as something other than "switching coins often based on current profitability at the time of the switch".

CGWatcher 1.2.0 introduces profitability mining, the second most requested feature behind CGRemote (coming soon). This post will explain how this works, and how the Scheduled Actions used to control profitability mining work.


Scheduled Actions

The previous scheduling feature in CGWatcher provided a basic "start miner" and "stop miner" option, and meant that the scheduled mining would have to occur on the set days at the set times every week. I didn't want to just duplicate this feature a few times, and instead wanted to allow for unlimited control of scheduling the miner to perform a variety of actions. I think the Scheduled Actions (similar to Window's Scheduled Tasks but named differently to avoid confusion) provide that and allow for additional actions to be easily added in the future. They allow you to fine-tune what your miner does and when it does it, down to the exact.

The Scheduled Actions you create are displayed in the Schedule tab. They are sorted to display all enabled actions first, in chronological order of when they will next run. Disabled actions are displayed last.




Each action has an enable/disable checkbox, Edit button, and Delete button. Click Add Scheduled Action... to create a new action. The actions available at introduction are:

• Start Mining
• Stop Mining
• Restart Mining
• Restart Computer
• Change Intensity
• Switch Profile

When creating a scheduled action, think of creating a sentence instructing CGWatcher of what you want it to do. As you select one option, other available options may be changed or filtered.

After the action drop-down, the next field is the "value". For the Change Intensity action, this is the intensity you want to change to. For the Switch Profile action, a drop-down list of your profiles allows you to select which profile to switch to. There are some additional options at the bottom of this list related to profitability, which I'll go into more below.

The next option in the "sentence" you're creating is the frequency drop-down list. You can choose to have the action run daily, on a specific day, weekdays, or weekends. Using any of these options will lastly display a time option at which to start the action. The frequency drop-down also contains an Every... option, that when used changes the time option to a textbox where you can enter a number of hours at which to trigger the action. You can use a decimal if you wish to run the action at less-than-one-hour intervals.

You can create scheduled actions that run at the exact same time, but if you want to ensure one runs before another you should add at least one second to the one you want to run last because they are ran in order of the time you set. If you schedule a Start Mining action to run at 3:00:00 PM and a Change Intensity action to run at 3:00:01 PM, the Change Intensity action will run once the Start Mining action has completed (which takes more than one second), so you do not have to worry about timing actions depending on what they do.

When using Every... N hour(s) actions, the timer for each of these actions begins when CGWatcher is started. So creating an action to run every 4 hours would run first 4 hours after CGWatcher was started. Then it will run 4 hours after that, and so on. However, if you either edit an action or enable a disabled action, the timer's start time for it is reset.

If you move your mouse over a scheduled action in the Schedule tab, a tooltip will display the next time that action is set to run. (This only applies to enabled actions.)


Profitability Mining

So when using CGWatcher, profitability mining is using scheduled actions to automatically switch to mine the most profitable coin that you've setup to mine. It works by checking the current profitability of the various crypto-coins, and then switching to the profile with the most profitable coin. This means that you'll want to create a separate profile for each coin that you mine, and assign a coin to each profile in Profile Manager. If you do not assign a coin to a profile, the profile is ignored when determining which profile is most profitable.


The Profile Manager now includes a drop-down list to select the coin to associate to that profile. The coin data is collected from http://www.coinchoose.com, so new coins added to the website will become available in CGWatcher after the coin data is refreshed. CGWatcher also uses the data from coinchoose to determine profile profitability.

You'll need to assign a coin to at least two profiles in order for profitability mining to work. Otherwise if you did not assign a coin to any profiles, it would be unable to determine which is most profitable; and if you assign a coin to only one profile, that profile would always be the most profitable because there is nothing else to compare it to.

You can check profitability at any time by clicking an Other Tools... button and then selecting Profitability from the menu. There is also a Profitability button in the Settings tab. These open the Coin Profitability window, which displays current profitability data from coinchoose, along with some other information about each coin like hashing algorithm, difficulty, network hashrate, best price, and which exchange is currently offering the best price.


In the Coin Profitability window, you can sort columns by clicking on the column header cell once to sort ascending, then again to sort descending.

There are three columns relating to the coin profitability. The first, "Profitability", is the current profitability compared to Bitcoin. If profitability is 200%, mining that coin will earn you twice as many Bitcoins as mining Bitcoin itself. Obviously this value can change at any time, and you would need to convert the mined coins to Bitcoin immediately in order to preserve this increase. If you hold the coin and decide to convert to Bitcoins the next day when the coin's profitability is only at 50%, you've now lost the additional coins you made by profitability mining. Likewise, there is the possibility that holding the coins allows you to convert when the profitability is even higher, so it is a gamble. Yes, there are miners who are not interested in converting everything to Bitcoin. But that is an essential part of profitability mining, since all profitability is based on Bitcoin.

The second column is "Adjusted Profitability". This value has been adjusted for stales and is intended to give a more accurate estimate of profitability.

The third column is "Average Profitability", which is based on a 7-day average. This is useful if you are looking to mine something more continuously instead of jumping on whatever happens to be most profitable every couple hours.

So back in the Scheduled Action window, you'll see that if you select the Switch Profile action, there are three profitability options in the profiles drop-down list matching the three columns: {Most profitable}, {Most profitable - adjusted}, and {Most profitable - average}. Selecting one of these tells CGWatcher which profitability value you want it to use when determining which profile of yours is most profitable before switching to that profile.

By default, CGWatcher updates coin profitability data every 15 minutes. You can change this by editing the CoinRefreshInterval value in the [CGWatcher] section of the INI file. The minimum value is 5 minutes, and the maximum is 1380 (or 23 hours). When a scheduled action is triggered that switches profiles to most profitable, CGWatcher checks if the coin data has been refreshed in the past 15 minutes and if it hasn't, it attempts to refresh it to ensure it is selecting the current most profitable. If that refresh should fail and CGWatcher finds that the coin profitability data has not been updated in the past 24 hours, it cancels the action (which is why the maximum refresh interval is 23 hours.)

Some example scheduled actions:


Things to Think About

I'm not suggesting you should or shouldn't mine based on profitability. I've provided the tools to do it because it has been one of the most requested features. There are some things you should keep in mind when deciding whether profitability mining is right for you:

• Pool types: if you use PPLNS-type pools, switching pools often because of profitability changes could have a small negative effect on your earnings because these type of pools reward for consistent mining and try to penalize pool-hoppers, which is essentially what you are doing if you are constantly switching pools based on profitability. Therefore you should try to use PPS-type pools if you plan on switching profiles often.
• If everyone is switching with you, the coin may not stay most profitable for long. I don't expect this to be a big problem because CGWatcher probably doesn't have enough users to make a big impact on sending a bunch of miners to the same coin at the same time. As of this post, CGWatcher has over 2,500 (est) users (in over 65 countries! maybe translations are in order) and averages 100+ downloads per day, so there is the chance it has an effect in the future. But this assumes that all users are mining all coins. If Bob is only mining Bitcoin and Litecoin, his most profitable coin might be Litecoin even though DigitalCoin is most profitable. Tom has a DigitalCoin profile so when DigitalCoin is most profitable, profitability mining would switch him to DigitalCoin but Bob will still be back on Litecoin. Then you have to consider that how often you switch profiles based on profitability depends on how you setup your scheduled actions, so while Tom might switch every few hours, Bob might only switch once per week. So these lessen the odds of sending a wave of miners to the same coin at the same time.
• As I mentioned earlier, CGWatcher uses profitability values based on Bitcoin. So if you don't convert your more profitable coins to Bitcoin while they are still more profitable, you risk losing any gains you made by mining the more profitable coin.
  
• Because of these things, there is no guarantee that profitability mining will actually be more profitable. It depends a lot on how you set up your pools and when and if you convert your mined coins to Bitcoin. CGWatcher makes it much easier to do, but there is still work before and after coins are mined that CGWatcher cannot do for you.
• This is a new feature, so if you experience any problems with actions not running when they are supposed to, please let me know. I did quite a bit of testing, but there are always bugs that won't be found until it is released to users, especially with the wide range of setups miners use.
• I will probably add this ability to CGRemote for non-Windows users by adding and switching pools via the API, but it is too early to say for sure. It may be limited to coins of the same algorithm since CGRemote will not have the same abilities as CGWatcher does if running on a remote computer. I'll have more info on this in the future as CGRemote progresses.
• Only you can determine if profitability mining is a wise strategy for you. I am not suggesting it is or isn't. I take no responsibility for any losses, we all know how volatile prices can be. Likewise, I take no credit for gains... though you are still more than welcome to donate.

If you're not already using CGWatcher, you can find more info and download here:

http://manotechnology.blogspot.com/p/cgwatcher.html

Version 1.2.0 is available. I've updated the original post and download page with most changes and new features.

Version 1.2.0 available, see original post for changes and new features. It has some features that have been requested a lot including more advanced scheduling options and automatic profile switching based on profitability.

Let me know if you have any issues, particularly in these two areas. I won't be home tomorrow but I should be around all day Sunday.


Edit: Updated to version 1.2.0.1, which adds "adjusted profitability" and "average (7-day) profitability" when creating scheduled actions to switch profiles to most profitable.

I'm working to have some news on CGRemote soon, but there is another project that I am still waiting for the contract to be finalized that could postpone it for a couple months. I am trying to get at least a beta out before then. It will be a limited group at first, and yes I will let those who have helped with CGWatcher or have donated know first. If you fit into this group and are interested you can send a PM or email, but there are several people who have helped with reporting bugs and testing (some in this thread) that I will PM if I don't hear from to let them know the beta is ready as well if they would want to test it, so a PM is not necessarily required.

Jazkal: Yes, CGRemote will provide a remote dashboard for multiple miners... even those without CGWatcher. But miners that are running CGWatcher will have more control because it is able to do things like launch or kill the miner that cannot be done via API. So if a problem occurs on a miner not running CGWatcher and it cannot be fixed via the API, you will have to fix it yourself. And obviously CGWatcher will be required in order to switch profiles on the miner from CGRemote.

But yes anything you can do in CGWatcher you will ultimately be able to do in CGRemote.

Here is a (very) basic diagram demonstrating how it works:

Not yet but there will be in CGRemote. I've been working on it and it's getting close to beta stage.

GUIMiner Scrypt is just a front-end for cgminer or reaper. I'm not sure which one you're using, but if you're using cgminer you can set intensity to "d" for dynamic, regardless of whether or not you're doing scrypt or sha256 mining. I don't use GUIMiner but I would imagine it has somewhere to set this. Keep in mind that with cgminer, I believe sha256 has intensity range of -10 to 14 and scrypt has an intensity range of 0 to 20.

Also if you use cgminer you can use CGWatcher to monitor the miner (and as a GUI) and there is an option to raise intensity on all GPUs to a specific value when the computer is idle, and it will lower them back to their original settings when it is no longer idle. This allows you to get higher hashrates during idle than dynamic intensity would. There are many more features, you can check the thread for more info:

https://bitcointalk.org/index.php?topic=185553.0

And because GUIMiner Scrypt is just launching cgminer hidden, you can still use CGWatcher with it... although it will communicate and control cgminer only and has no interaction with GUIMiner. I've heard others mention this works but haven't tested it myself. This is assuming you've set GUIMiner to use cgminer and not reaper.



Edit: I should point out that I don't use dynamic intensity, but as I was writing this I set one GPU to "D" while scrypt mining and cgminer lowered it to 8, causing hashrate to go from ~400Kh/s to 20Kh/s. Temperature was not a factor because it was down to < 60C by the time I noticed. So either I need to adjust something in my config or cgminer is setting dynamic intensity based on sha256 intensity range and not adjusting for scrypt's intensity range.... maybe. I can't say that for certain and I'm too tired at the moment to look more into it now. I'd still suggest using cgminer and setting a specific intensity value, then setting CGWatcher to raise intensity when the computer is idle.

iPhoneDude777: I've made some changes so downloading 1.1.9.0f will hopefully correct this. I had purposely made the criteria for linking a miner more relaxed if there was only one instance of the miner running. Unfortunately, this had a bad side effect on trying to run multiple instances.

1. Make sure that the cgwatcher.exe file is updated for both instances. To make this easier to follow, I'll call them instance A and instance B. So CGWatcher A is monitoring miner A, and you want CGWatcher B to monitor miner B.

2. Start CGWatcher A as usual. If you still have the miner running it should connect to it without issue. Then there are three ways you can handle starting CGWatcher B (which is only because of problem caused by the previous version). You will only need to do one of the following after updating to 1.1.9.0f:

• Make a clean copy of the CGWatcher B folder so any settings related to Miner A are gone.
• Restart Miner A so it is no longer using the same process that CGWatcher B connected to. If you've stopped or restarted Miner A at all since last trying to use CGWatcher B, you should be fine.
• If the miner A process that CGWatcher B connected to is still running, start CGWatcher B and after it starts it should still show the miner is running but it won't have API access to it. Down in the bottom right corner next to where it says "CGMiner is running" (or something similar), a 'Reset' button will appear whenever there is no API access. Click this button to remove the link CGWatcher B had made to the Miner A process. Once you do this, it might take a second but it should change to "No miners running".

So essentially you're removing the link that CGWatcher B had made to Miner A. Once you do this, you should be able to start Miner B in CGWatcher B.

Let me know if this works or doesn't work, I'm not able to test much at the moment but from the tests I did run it worked correctly.

Fishbones: I just made changes to add a 10-second delay when launching the miner upon starting CGWatcher. You can change this value by opening the INI file, finding [Monitor] section, and editing the "AutoLaunchDelay" value (value is in seconds). This setting may not appear in the INI file until you run 1.1.9.0e at least once, which in that case you could manually add it in the INI file.


Zanatos666: I made some changes to the restart function yesterday in 1.1.9.0d, and just uploaded 1.1.9.0e which also has the delayed auto-launch setting. When restarting, the miner actually launches itself as a new process then closes the old one. CGWatcher should wait up to 15 seconds for the old process to close. If for some reason this doesn't happen, it ends up killing the process. It then checks to see if the miner successfully launched itself, and waits for it to initialize its API. If for some reason the miner didn't successfully launch itself, it will try to start the miner. It will not necessarily keep trying to start the miner, because most likely if it fails to start once it will continue to fail (e.g. incorrect config settings).

So between the different steps in the restart process, it can actually wait up to a minute or so for the restart to complete... but once the conditions for a step are met it moves on to the next step instead of waiting unconditionally.

As I mentioned, there may have been instances prior to 1.1.9.0d where this was not working as expected, so let me know if the update has not resolved the problem.

Maybe the wallet should just be hidden inside of another app. Make a simple app that performs some simple task, yet useful enough that having it installed doesn't raise suspicion. Another calculator app, or schedule app, etc. Then inside the app, there would be a hidden way to open and access the wallet. There is the possibility that it becomes well known that the app contains a hidden wallet, but you could always deny knowing about it or using it. Whatever method is used to access the wallet would have to be customizable - a certain swipe pattern or something uncommon, and there would be no way to tell if the wallet had ever been used.

Obviously there is going to be difficulty in trying to make the app completely hidden... so instead, hide it in plain sight. Even if using a file explorer and looking through app directories, it will only show the dummy app.

I'm not sure I understand exactly what mameise is describing, so I apologize if I just repeated his thoughts.