Wanted to make sure I had this figured out. It looks like AM doesn't always function correctly and things are delayed or possibly aren't executed on systems that are heavily overloaded. The computer it was on was around 80-90% CPU utilization. Setting AM to high priority fixed this and haven't had a issue since doing this. I believe this issue can be duplicated by overloading the work system.

Could a option be added to run AM as high priority on startup (or whatever the person wants)?

Hey Patrike, running into some weird issues with Rules > Action > Wait. It seems like it doesn't trigger the first action and WAIT based on where it is in the list, it instead WAITs prior to doing any actions, at least with changing variables.

Please consider adding a 'wait' period to rules, triggers. So it'll wait before checking the next trigger if you have multiples. Right now for instance, if I have a variable setup and checking for hashrate for 60s, as soon as the variable is true (or whatever you have it setup to be), the other trigger is true and it'll immediately trigger instead of waiting to check hashrate despite wanting the hashrate check to happen after the variable changes.

It's available under actions, but not triggers.

Thanks.


I know you're trolling at this point so this is one of the last interactions we're going to have since you're wasting my time. 10pm comes after 9pm on a 12hour clock. Latest dates are at the top of the list. Patrike already fixed it, so appreciate that.

Sometimes posts get eaten here, thought you might have moderated rights to the thread.

TLDR:


1. Not true, there seems to be a problem with localization and while it's not the 0 position it's probably a issue with 12/24 hour format as it also has problems with the date, where it seems like it's not organized properly. Some parts of the world are DD/MM/YY, where the US is MM/DD/YY.

https://i.imgur.com/aMdiLL1.jpg

2. Static IPs are a lot of tedious work, especially as your network grows. The solution would be to run a active directory, which entails a lot more work. This is something that should be built into AM as AM is made to make mining easier, not harder, and I don't believe it's beyond scope.

3. Bandaid fix and not something you want in a mission critical environment. I have something similar already setup, but you have to manage each installation and make sure they're identical at all times or bad things happen.

Don't play dev when you're not the dev. Ideally we should be working to improve a piece of software, not come up with arbitrary rules as to why things can't be fixed or improved upon.


1. I didn't think of setting up longer leases (already done), although another bandaid I'll see if it helps. Ideally you don't want really long leases or you end up with devices that are no longer on your network eating a IP. Weirdly enough, the only time I've seen asics pull another IP is when the rule reboots them when they're locked up. They almost never pull new IPs or change.

2. Proxy looks to be a solution, although I feel as though this functionality should already be built into AM in some way. I intended on using a action to scan for new devices after the lockup rule goes off and readding them.

I already have MAC tracking turned on. For some reason after I readd them to AM they don't take over the original entry and are added as a new entry in the list.

Did my post get moderated or did it not post?

Appreciate looking into this, would this allow for a backup server then? Right now the client is the server and if the server goes offline, the problem still remains.


Couple other bugs I'm running into.

1. Tools > activity log > all

Appears as though the list isn't sorted or doesn't properly support 12 hour sorting. Also dates don't seem to be sorted properly due to them not properly parsing times that would have a 0 in front.

2. I'm running into a issue where IPs are changing on ASICs and the AM client doesn't update the current listing to reflect this. They can easily be found by scanning the network, but obviously not good. This is generally being caused by my router resetting then occasionally the miners resetting.

Could you add a Rule Action that runs a network scan and readds the miners replacing their original entry? They are uniquely identifiable at least by their MAC address.

Hey Patrike, considering how integral AM is to a lot of us at this point, could you look into adding failover. Like another installation of AM that will take over if the primary one goes down on your network.

Thanks

It seems as though there is a bug with the Time Rule Trigger. If you select a month range that is lets say late in the year till the next year, it doesn't properly read it. Like 10-04, so from Oct to April. It works fine in the opposite direction. So 1-8 or 4-12, but not 5-1 or whatever range you want that moves across the year till next year.

Tools > Rule History

Maybe it's not a normal log that gets saved, however with variable triggers it only keeps about a hour worth of data before it gets pushed out due to the variable activating every 6s.

This does work, I feel as though the 'detect change' or 'comparison' should instead be checkboxes, instead of radial buttons and could eliminate this, while being more intuitive and simplistic. So it could do both in one or either/or.

I don't know if you can do anything about the rulespam, but the comparison activates every 6s and keeps hitting the logs, which buries anything of value.

Aye... Thanks.

Errr... I don't think the variable change thing really solves the original problem. The problem was it would constantly trigger if conditions were met, not only once when they're first met.

So I have two different variables, and a rule that triggers turning miners off if one variable is true. Then I have another rule when both variables are false that turns things back on. However, if it's setup normally the miners will keep resetting (turning off) as long as one of the variables is true and with the 'detect change' wont be able to know the correct state that both need to be in to turn things back on.

Isn't that just a loop or completely break the automation till it's manually reset?

I saw the run X number of minutes, but when you have a interaction that's semi-random in nature, you can't set something like that up. I think 'on state change' instead of running in a loop would be possible and often times preferable depending on what you're looking for.

Looks like when I restart AM, some of the global variables disappear from tools > rules > variables? Do they automatically show up when rules get called that trigger them or if they aren't there will the program throw a error?

Also how do you get something to trigger once on a variable state change? Seems they're set to constantly repeat. You can set time limit, but that's not applicable nor do I want triggers to run when the variable states don't change.

Thanks

Is there anyway to setup rules taking precedent over other rules, so if one is active or has been triggered, another that adjusts the same condition wont trigger?

Not sure if OP still visits this, please add a stablecoin payment option. There are plenty out there that have minimal transaction fees too, such as binance and tron - basically free.

Could we get some Home Assistant or other smart home integration? Rules need to be able to pull a trigger in from a outside source, thanks!

Would also be useful if you could pull information out of emails or use a email as a trigger. You can send emails with rules, but not receive them.

1. Yes, both for Braiins as well as Asicto 24 hour hashrates are off in terms of what average shows on AM vs the dashboard on the miner itself. It will gravitate close to the 24 hour hashrate on the miner within about a decimal, however this takes a decent chunk of time - sometimes a couple days. Hashrate averages over 6 and 12 hours are pretty far off. The instaneous reading also is off, however it might just be when AM is polling the data vs the dashboard.

2. Appreciate adding support!

3. Couple more things here, due to the nature of Braiins and how pause functionality works, it actually consumes much more power then it should. When you stop BOSminer it puts fans at 100% and doesn't completely power down the miner. This leads to around 80w of power usage. I've talked with the developers, but fixing this seems to be a very low priority for them.

However, if you remove the pools or the pools are dead, it drops into a very low power mode and the dev fee doesn't work. It will use around 13w of power and of course is much quieter. I can do this myself through some custom rules finagling, but if you could add a bandaid checkbox where AM will 'pause' mining by removing all the pools, then readd them again when you 'unpause' it will save power. Then add a rule to pause/unpause through this functionality.

4. I looked through the rules section and can't find a way to pull in variables from outside of AM. I assume this can be done through a custom script, but looking at a text document for a variable after formatting. IE look for syntax and then variable after syntax in a file. Such as start/stop time. This could be as simple as 1 or 0 in the file.

This doesn't necessarily seem to be completely true, it doesn't match Braiins 24 hour hashrate for instance (it does eventually with enough time). It seems like Brains discards the warmup period and tuning periods after a certain amount of time where AM does not.

The pause functionality for Brains seems to be broken as well. This needs to be done with the BOSminer stop/start command.

I meant in AwesomeMiner, not on the miner itself. Under performance category in the miners tab. Unless that's directly linked to the miner firmware? It appears as though it's different from what is displayed on the miner itself. Would be useful if this was a 24/hr rolling average instead of since powerup as well.

Also please add support for pause/resume mining for brains OS.