Add jobs to open up events, status of the farmerbot, etc

[brandonpille]

Users want to create a UI that can be used to see what the farmerbot is doing at any time. Currently the only way to see if nodes are up is to look at the dashboard. But when the farmerbot powers the nodes off the dashboard shows the nodes as down while they are technically still available for usage. The farmerbot is the only one to know this. So it would be a great idea to open the events up to the world. We could create jobs that:

• return the events of the farmerbot
• return the status of nodes
• return other data (next periodic wakeup, etc)

[scottyeager]

A couple notes on this, hopefully without repeating too much what I wrote in #15.

• The node's current power target and power state are stored on TF Chain and easily queried over GraphQL. This means that sleeping nodes can be distinguished from nodes that are simply down, although a node that is undergoing periodic wake up can't be readily distinguished from a node that's simply online
• I think adding RMB endpoints for these functions can have greater utility than a web API since it's always reachable, and also keep things simple by using a single interface

[brandonpille]

A couple notes on this, hopefully without repeating too much what I wrote in #15.

• The node's current power target and power state are stored on TF Chain and easily queried over GraphQL. This means that sleeping nodes can be distinguished from nodes that are simply down, although a node that is undergoing periodic wake up can't be readily distinguished from a node that's simply online
• I think adding RMB endpoints for these functions can have greater utility than a web API since it's always reachable, and also keep things simple by using a single interface

I agree. I'll go ahead and open it up via RMB. I just want to clarify something. We can indeed gather data from GraphQL but it doesn't mean we should. We are and have been using GraphQL too much. It has become very centralized. I think getting that information from the farmerbot itself makes more sense. This for two reasons:

• It's a step closer to full decentralization
• The data is more realtime then GraphQL (keep in mind that GraphQL gets its data from tfchain and that there is a delay)

I think we should start asking the data directly to the owner of that data instead of using tools like GraphQL. I understand that getting the data from one point is easier but it introduces single points of failure. I also understand that in some cases we don't have any other solution.

[scottyeager]

I hear what you're saying about going more decentralized and peer to peer. Relying too much on a single instance of GraphQL is certainly a bad idea, and I hope we'll see some projects building on the grid choosing to host their own, as well as their own TF Chain nodes, if they rely on it.

To me, each data source has it's place and it's generally better if there are more options in where to source data. A blockchain is designed to be highly available and highly consistent. I don't see an issue with going to the chain for data it contains (although which data is stored on chain in the first place should certainly be minimized).

For certain use cases it becomes rather cumbersome to query the farmerbots directly for info about how nodes are being managed. One example is determining how many nodes are asleep at any given time on the grid (I do this for my grid stats posts). How do you even know which farms are using a farmerbot? What if a farmerbot happens to go offline or doesn't respond for whatever reason? Using on chain data provides the best authoritative source about what the intended power state of all nodes on the grid is.

Anyway, it will be great to have these endpoints available, and I look forward to testing them!

[brandonpille]

You know if a farmerbot is running by pinging it. Send a get_version job to the twin id of the farm and if you get a response you know it is running.

[ashraffouda]

blocked because of #67 (comment)