The solution for monitoring tools may well be to support those broken APIs also, but ignoring the consistent and backward compatible cgminer API I've written is a mistake.
That's a bit harsh. My app is coded around the API output coming from the supported miners at the time it was written. How/why would support be added for data that isn't available and can't be tested with?
M
I agree there was nothing much to be done about the "mother" cgminer API output, simply because there was no demand for it and the assumption that bitmain actually properly implemented the API.
Saying that, the fix is quite simple, basically, the json output from kano's API is nested inside another array (if you deserialize using the native javascriptdeserializer in .NET), and there are extra values added (hopefully that will be consistent in the S5 release too).
Actually, that has nothing to do with it. The difference is literally one letter.
M
No, there are other differences.
Firstly a side track, if you use the DEVS command, it returns each device, which with an ant is always just one device.
Of course in an Ant it's ... MHS ... oh wait why is it different to the Ant summary?
So if you do a DEVS request to an Ant cgminer ... it's MHS ... but the summary request is GHS ...
Anyway, when the AntS1 was released, in the pool stats it returned the timestamp (as cgminer always has since it was added) for the "Last Share Time".
If you want to know how long ago that is, the API also always returns a field called "When" which is the cgminer time of the API request.
So how long ago was the last share? "When" - "Last Share Time" ... no big deal.
They LATER changed that to NOT return the timestamp, but rather a string HH:MM:SS
Why? Again to save having to format the the result in their web code.
What does that mean? Well you have to either accept their formatting, or if you wish to format it differently, you must first "convert" their string before formatting it differently.
... and of course you have to know which AntS1 you are talking to - the original firmware or a later version... and of course master cgminer itself always has been and always will be a timestamp since that makes sense.
Next, internal to cgminer there is the diff the pool is currently expecting for shares.
This field internally also has a formatted string of the diff for display on the cgminer text screen.
Bitmain added this text version of the field (not the numeric version) to the API.
So if you need the numeric value for any calculation, or wish to display it differently, you first must convert it to a number.
i.e. yeah nice to add it, but no that's not how it should be added.
Next, at some release of the firmware they added the "GHS 5s", "GHS av" and "Device Hardware%" to the stats output.
Why? Coz they didn't want to have to request the summary or devs that has the hash values and hardware% in it ...
Does it matter? No, but it's pointless making such changes since no other mining device has those numbers there, and they are already in devs and summary where they should be.
DEVS is designed to be (and is) standard across all devices/miners.
STATS contains other random information that differs from one device/miner to the next.
... and just to throw things out a bit more ...
Their internal web code expects all fields to be in a specific order in the API output.
As you would know
the API is name=value or json name and value ... i.e. key and value pairs ... as it should be.
When you want a value, you reference it by key, NOT by field order.
That's one of the things I fixed back in my original S2 release and again in the S3 release, my version of their web code for processing the API is smaller and wont fail if the order of fields change, or new fields are added.
They've ignored that even up to the latest S5 firmware.
