I will be building my EmonTX shortly and using a NanodeRF to post the data to my local Emoncms server. I would like to open this server up to some friends to see the data I am collecting and let them play with graphs and visualizations of it on their own. From what it appears though, is that the server software is setup to receive a set of data and only share it with one user on the server, determined by the APIKEY used to post it. I can see how I can create public feeds and visualizations, but not how I can share the raw input data and let them use the cool software to play around with how to gather and analyze it. Is this correct? Is there any way to make data coming into the server available to multiple users to create feeds and dashboards?
I can see how I can do it by modifying the sketch on the NanodeRF to post each slug of data to the server twice, using two different API keys to post to two different users, but then you end up with double the data on the server. I tried manually editing the API keys for two users in the MYSQL database so that they matched, but then it wouldn't accept any data for anyone... Any thoughts or suggestions? Thanks in advance...
Re: Single data stream to multiple Emoncms users?
I didn't check myself, but is the raw data stored anyway ? My understanding is that it is used as an input for the feeds, but I don't think the feeds can be computed retro-actively, so why keep the raw data ? (I may as well peek into the DB to check that...)
Assuming the raw data is not kept, it is not duplicated, only the feeds are, which is your intention, so sending the data to several accounts makes sense.
If raw data is stored, I'd be interested to know why.
Re: Single data stream to multiple Emoncms users?
Just to clarify, raw data is not stored, data is only stored when feeds are created.
Sounds like you need some way to view the public feeds available? so that multiple users could then explore different visualizations on those feeds? Is there any reason why you cant share the one account between multiple users?
Re: Single data stream to multiple Emoncms users?
Is there any reason why you cant share the one account between multiple users?
That was discussed but the thought was that each of the people would want to mess around with their own feeds and dashboards, and not clutter each other's workspace. This is really just between myself and my dad. He is a retired electrical engineer who was really into Amateur shortwave radio (Ham radio for those familiar with the term) for most of his life and always tried to vainly get me interested as a kid. He lives 6 hours away, and I have been enjoying working on this project with him, although it has been long distance collaboration so far. He came up this past weekend to build the kit with me but it looks like it won't arrive until today or tomorrow so we just enjoyed visiting and looking at the Emoncms software...
Anyhow, I wanted to give him a way to mess around with the feeds and visualizations without feeling like he was messing with my setup. He was reluctant to login on the same account and possibly mess up what I am setting up. It appears that simply posting to two accounts would work, but this feature might be something to consider for future revision work, allowing feeds to be public and letting people play around with making their own visualizations or dashboards in a public play space. I could foresee a public group or science outreach organization wanting to install solar and then providing a place for the public to play with the data and see what it means.
Once I get my system up and running I may take on that work. Gotta go learn some PHP...
Re: Single data stream to multiple Emoncms users?
Posting to two feeds with the NanodeRF is not easy. I was looking into it as it's something that has been asked for a few times (specifically to a local server and to emoncms.org). Basically, it won't work the obvious way because of the way the I/O buffer is handled. It requires the four posts (if you include time requests) to be carefully separated along with their acknowledgements. I have a feeling that the only reason the time request works relatively reliably is because it happens rarely (once instead of 12 times per minute) and the potential for a data collision is that much less. I haven't got any further than identifying why it won't work. If you're thinking of looking at it, be warned - the code is un-commented and pretty much impenetrable.