Free Live Dashboard?

We want to display current lead times on a TV screen. My first thought was a kinetic dashboard, but that would consume a license constantly. The second thing we tried was a google sheet, which worked great with live updates. But after a few hours the ‘live updates’ connection goes idle and it won’t pick any up until its refreshed. That wouldn’t be a problem if it was a desktop with a full browser, because I could install a plugin that auto-refreshed the page. But the smart TV browser doesn’t support that.

What do you guys do for displaying a few bits of data, for free and in real time?

I’ve used grafana for this:

3 Likes

Google Charts using Javascript, and the Rest API a BAQ.

3 Likes

Using the API would have saved us a butt-ton of trouble. We built a python script to run a query against the DB and used a raspberry pi to call & display it, refreshing it every minute. When the query hit an error causing it to run for 5 minutes instead of 5 seconds, SQL server eventually overloaded and crashed, bringing the whole system down. Took forever to find the culprit, too - we thought we were being hacked etc.

So don’t be like bob

2 Likes

So does that auto-refresh or do you have a script/plugin that reloads the dashboard?

each dashboard has auto refresh settings you can update.

Right, so this has been tripping me up. There is the data refresh, i.e how often the dashboard imports the data and there is the client screen update. When grafana pulls in new data from the data source, does it push out an update to the TV, or is it up to the TV to check periodically for updates?

If memory serves me right, the data refresh and dashboard refresh are independent.
The dashboard refresh is what will refresh the tv.

Seconding Grafana. We use it for a multitude of dashboards displayed throughout the production floor. Works great, very flexible, doesn’t consume an Epicor seat. Use a browser add-on to periodically refresh the screen at whatever interval you determine is applicable.

3 Likes

Hey guys! I am working on setting up Grafana in a Docker container along with Xibo to display some data from Epicor on screens around the shop. We have stick PCs pulling down the data from the Xibo CMS. This works ok. However, we need to pull data from Epicor.

I have setup a webservice, api key, and integration account(OJEXWebService), as well as a BAQ(OJEXForDash). I can enter the rest call into my browser and input my user/pass then get my json back in raw form.

https://centralusdtapp01.epicorsaas.com/saas512/api/v2/odata/VTAERO/BaqSvc/OJEXForDash/Data?api-key=myapikeygoeshere

I want to pull this datasource into Grafana to make some charts. I added a SimpleJson datasource to grafana, and configured it as follows:



No matter what settings I choose in the setup here, I always get “HTTP error”, “Bad Gateway”, or “HTTP error Forbidden”.

If you all are using Grafana to show your Epicor data, how are you configuring your datasource in Grafana?
Thanks for your time!
Nate

I don’t use Granfana, but have used the REST interface quite a bit. Have you tried changing the api-key param to x-api-key? Or removing it from the URI and adding it as a custom HTTP header instead?

1 Like

Also, the username/password has to be base64 encoded - I don’t know if Grafana does that for you?

Edit: just noticed that the “With Credentials” toggle doesn’t appear to be on in your dashboard, so I don’t think they’re being passed.

1 Like

I have tried that With Credentials flag on and off, in browser and server. I just tried pulling the api and inserting it as a header. Admittedly, I don’t know what I am doing, but it didn’t work. I am hoping that grafana does the encoding, as when I enter a password it replaced it with password dots, then when I reload it just shows that “configured” word in there. I think that means that it took my pw and saved it encoded somehow.

Hmmm…If you open the dev console and watch the Network tab, you should be able to see the call, and if the username/password is being passed encoded or decoded.

Edit: you could also try using V1 of the REST API. I’ve had trouble with V2 in the past.

He’s passing it in the url, so it is api-key.

Got tripped up on that one myself a few days ago.

Headers: x-api-key
Url: api-key

1 Like

x-api-key in the header is more secure.

blah blah blah, nobody cares Mark.

1 Like

If anyone is wondering, it’s because of many peoples logging policies, it can get exposed.

Details here:

https://w3ctag.github.io/capability-urls/

2 Likes