[Discussion split from Emoncms App dev suggestion - #12 as topic has changed]
Offtopic, but could you please provide an example how to do that? Just tried it, but didn’t succeed. This function could be really helpful.
See Accessing graphs directly with apikey · Issue #27 · emoncms/graph · GitHub offhand I cannot recall if I tried it or not as I do not pull changes into my live servers immediately and my test server has fallen behind recently as it has local changes and very little test traffic at the moment.
[edit - I’ve just tried this numerous ways and cannot get it working, please let us know how you get on]
1 Like
Thank you very much @pb66 , I can confirm that a saved graph can now be called by its name using the load=Graphname option (Attention: seems to be case sensitive!). In my opinion “graphname” would have been more consistent instead of load, because graphid= is used when calling it with the id.
For embedded graphs the APIKEY is unfortunately still useless, the feeds have to be public. This PR should therefore probably be better opened again: Embedded graphs do not honor using an apikey to view · Issue #8 · emoncms/graph · GitHub
It would be wonderful if this could be changed as well @TrystanLea 
How bizarre you got the exact mirror image results to me!
I can not get the “by name with apikey” urls to work with any case, I have a test graph named “overview” all lower case, but neither overview, Overview or OVERVIEW work. I have also tried 2 url formats for each as I would have expected http://server.com/graph/mygraph to work for consistency with http://server.com/dashboard/mydashboard and http://server.com/app/myapp, as well as the “load=” examples given (which I agree is not ideal, but if the other way worked too I would not be overly concerned about).
. .
When I am logged in and can therefore just select the graph from the dropdown, and only then, I can also type the “?load=overview” and that works (but yes it is case sensitive “Overview” doesn’t work). But when I’m not logged in I cannot access any graph with any url using any case with the read apikey.
And again in contrast to your findings, the embeded graphs work fine. The first pic shows a public dashboard (also named “overview”) where only 1 of 3 feeds can be seen as it is a public feed
and the same dash and public url, but with the readapikey
or the standard non-public url with read apikey
Are you using the latest master branches? I ended up pulling in all the repos last night as it hadn’t been done for a while.
[edit - Just tried un-setting the dashboard from public in case it was hiding the fact the dash doesn’t show using apikey and with the dash non-public the “dashboard/view/overview?apikey=” still works fine, but as expected the 2 “dashboard/overview” public style urls do not (with or without an apikey).]
[edit2 - @Simsala are you using read apikey or the write apikey? All of my above tests and comments relate to the read apikey. I have just tries opening the graph using the write apikey and that works, granting full editing rights, so not something you pass out freely or embed somewhere else.
and with a working url format and write apikey, if the case is wrong for the graphname (eg here I capitalized the first letter) it results in an error and doesn’t display.
(apologies for the fudging - I raised an issue about sensitive info in errors (here))
alas the “pretty” url that would be consistent with the dashboard/mydash and app/myapp still doesn’t work with the write apikey.
I tested the option with “load=graphname” last night and it worked. This morning I pulled the latest changes from Github but without testing it again. Indeed, it also doesn’t work for me anymore.
With embeddet graph I meant something slightly different, sorry for the confusion. If I read your error description again, I understand that it is actually embedded graphs in a dashboard. What I meant was the following request: http://server.com/graph/embed&graphid=1&readkey=765f0c9d8c843d9afc3cce1e63bd432g
This allows the graph to be integrated into other applications and websites, which is actually a very neat function. Unfortunately, specifying the apikey has no effect here, the graph is only displayed if I’m logged in, or the feeds are made public.
1 Like
Ahh ok! so we have 3 types of url direct to the graphs page, embedded in a emoncms dash (maybe embeded isn’t the best term? graph widget?) and embedded elsewhere using an embed url.
I haven’t actually tried the 3rd one (with a graph), the dash widget? seems to work fine and although there were previous some “quirks” with how the direct url worked it has now stopped altogether with the read key. Does it still work for you with the write key since pulling in the latest?
Are you sure that’s the right url?
does
or
http://server.com/graph?load=graphname&apikey=READAPIKEY&embed=1
work?
If I recall correctly the readkey= is unique to the app module and both the dashboard and app modules use &embed=1 (or is it true or True?) to drop the navbar and footer etc.
perhaps also try the above again with the write apikey too, so that we can confirm the url is correct even though the read apikey doesn’t appear to be supported in places.
Unfortunately, none of the possibilities work with the APIKEY.
No luck with the writekey either.
Thanks, I changed it to apikey=, but the result is still the same.
If “&embed=1” is appended to the URL, the blue emoncms header with menu and footer will be removed. On the other hand http://server.com/graph/embed&graphid=1 shows only the actual graph.
Here are the three possibilities in comparison:
Normal View (not logged in):
Appended “&embed=1” (not logged in)
Use graph/embed (logged in):
(Note: for the last one I was logged in, otherwise only the navigation bar on the top left would be visible).
I’m not sure what to say, we’re guessing as to how it should work not knowing how it is intended to work and/or if it’s faulty. There’s very little info so I could be well off with my expectation.
I didn’t expect the &embed=1 to work with the graph/embed api, I wasn’t aware there was a way to embed the graph only, it totally makes perfect sense now you mention it and possibly if I had tried it out, it would have been obvious, I didn’t give the content much thought, just the access.
Oh! So I just tried the graph/embed url as it appears to be the same api used by the graphs embedded in dashboards using a graph widget and I looked at the source to see if the api call was any different, it wasn’t so I tried it in the browser and it worked
in fact, it doesn’t seem to matter which api key I use (readonly or readwrite) the page appears to display exactly the same. So why doesn’t this work for you ??? Or am I still barking up the wrong tree?
That’s crazy, just tried it another time, but it only works if I’m logged in. Are you sure your feeds are not public or you are still logged in? Or is it not enough to update the graph module to the latest master?
I’m definitely not logged in and it’s an incognito browser window.
Only one of the 3 feeds is public as shown in the earlier screenshots.
I do not know of any specific requirements but have you pulled in the latest emoncms (core) master too?
That did the trick! I switched over to master (from stable) it it works. To be sure that was the reason I switched back and it stopped working. So to summarize: latest graph and latest emoncms (master) are needed.
1 Like
So it’s just accessing the graph pages directly using name and/or apikey that is an issue?
I will read back through the thread at some point but from memory I think we/I have had all the other bits working?
Yes, that’s correct.
@TrystanLea @glyn.hudson @emrys - could this be looked at please.
I am pretty sure the means of accessing the graphs etc via URL used to be part of the notes when setting up a graph etc but seems to have gone. Perhaps an ‘API’ page like that for Feeds and inputs is required.
This has come up again here Emoncms dashboard crashes after x hours