I like the idea of what's been done so far, but is this going to make it easier or harder for those of us who have our own monitoring?
I currently have a PHP script collating all my F@H statistics then feed it to my own website. Any tips for the changes I need to make?
I also include this information on my network performance summary screen I leave open 24/7, so I can see if theres a stuck WU or other problem. I wont be able to do this unless I can collate the information like I have been doing.
The current web control doesn't show estimated points or PPD, which is not useful when some of us are trying to donate as much as possible while keeping power consumption under control. I often tweak my GPUs power limit to try to reach a balance between power consumption, heat and hitting a sweet spot for getting the most PPD per watt. How will I be able to do this on v3?
But what if we don't want to use the Web UI or have custom monitoring?
Moderators: Site Moderators, FAHC Science Team
-
- Posts: 41
- Joined: Mon Oct 24, 2022 4:32 am
-
- Site Moderator
- Posts: 1115
- Joined: Sat Dec 08, 2007 1:33 am
- Location: San Francisco, CA
- Contact:
Re: But what if we don't want to use the Web UI or have custom monitoring?
The api is not documented yet, but is json over websocket.
You can see the traffic if you open your web browser JavaScript console and set it to verbose.
The most interesting thing for you would be that a json snapshot is sent when you first open the websocket.
You can see the traffic if you open your web browser JavaScript console and set it to verbose.
The most interesting thing for you would be that a json snapshot is sent when you first open the websocket.
-
- Posts: 41
- Joined: Mon Oct 24, 2022 4:32 am
Re: But what if we don't want to use the Web UI or have custom monitoring?
Thanks, that's a good start.
-
- Posts: 41
- Joined: Mon Oct 24, 2022 4:32 am
Re: But what if we don't want to use the Web UI or have custom monitoring?
Any idea why updates come in the [ ] format compared to the initial json being in { }?
I was hoping to just be able to be lazy and keep the initial information in an object and overwrite any updated information, periodically refreshing my entire table with that information so it refreshes at the same time. But as their format is different I have to parse the updates completely differently.
I get keeping update information to a minimum, but shouldn't the format be the same? I'm probably missing something completely obvious, I'm well out of my depth when it comes to modern web programming.
I was hoping to just be able to be lazy and keep the initial information in an object and overwrite any updated information, periodically refreshing my entire table with that information so it refreshes at the same time. But as their format is different I have to parse the updates completely differently.
I get keeping update information to a minimum, but shouldn't the format be the same? I'm probably missing something completely obvious, I'm well out of my depth when it comes to modern web programming.
-
- Site Moderator
- Posts: 1115
- Joined: Sat Dec 08, 2007 1:33 am
- Location: San Francisco, CA
- Contact:
Re: But what if we don't want to use the Web UI or have custom monitoring?
I don’t know. I assume Joseph had his reasons.
-
- Site Moderator
- Posts: 1115
- Joined: Sat Dec 08, 2007 1:33 am
- Location: San Francisco, CA
- Contact:
Re: But what if we don't want to use the Web UI or have custom monitoring?
I would note that not all updates correspond to something in the snapshot.
-
- Posts: 41
- Joined: Mon Oct 24, 2022 4:32 am
Re: But what if we don't want to use the Web UI or have custom monitoring?
Okay, sweet, I've got it updating correctly on my summary page. It is kinda easier that minor updates are plain arrays, I can see why they did that.