A RMS is a resource management system based on a content mangement system.
The content management system stores data of sensors an prework this data to feeds.
here the open source system emoncms is used for inputs and feed data send by pieces of internet of things.
the content management system gets richer by syncing other information apon this fetched data.
this is be done by the project energy2use (university of paderborn), where people will look on the collected data on a specialised view and comment them and put information apon them at any datapoint.
The global system is based on sensors that are sending there input data to other systems i.e. emonHUB.
this data gets its place in a cms system i.e. emoncms.
the difficulty is in the view of internet of things, that these data or data sources has to be unique.
so a node has to have a unique id (UUID) this should be firstly done by input or better by sensor.
in this way we have the possibility to get a collaborating federated system. every late node can decide weather he should handle the data by interpreting the UUID.
so the emonTH and emonTX should send instead of a "port" number a UUID or a UUID together with the "port" number. the emonhub should give this UUID together with the data instead of a "input" number and "node" number and together with the UUID of the target CMS. the data can than be encoded for data secure. cause the target system can then decode it of knowing by the UUID.
inside the CMS (emoncms) this UUID are managed.
the previous nodes can sends node information together with this UUID by time or change on them.ike emonvie
like emonview should.
CMS should get versioning on these data. resend data should stored by a new version number.
therefore there must be changes in the main of the PHPFI*, Timestore and Mysql parts, but them ar not so big in my opinion. in this way we get a redundant CMS system for the data and data will get federative.
cause of a uniqe id of the data this data are usable over different checking systems by giving them free for the systems, like allowed for UUID *** in UUID management.
like a CouchDB the emoncms data can then get synced together to targeting systems.
This is only a first scatch, but in work with the university of Paderborn (slab) and some companies around it, we will have a vision with this. we are researching on internet of things and internet of everything and the human machine interface of this. this is a part of the m2m communication for using the fetched data.
I have emoncms and the OpenEnergyMonitor project on focus since over a year and are working with it.
so i like to do a fetch of emoncms, emonhub and emonview and bring the changes in.
We will try to make a research project out of this for the 2nd half of 2015.
what do you think about it?
Re: UUID over all parts of emon* to get a federated datawarehouse
Fist thing i tried out, is to check for the inputs and the nodes.
It is no problem in standard emoncms to use UUID by sending data instead of numbers for identifiers.
So it is possible to be unique over all installations. the only thing is to bring this UUID to be sent by emonHUB.
This should not be such a Problem.
Re: UUID over all parts of emon* to get a federated datawarehouse
As I heard the node module in emoncms is not longer needed cause of emonHub is replacing it.
Is this correct?
So in my opinon the node module in emoncms should be the counterpart to the nodesview in emonview, set by the emonhub.cfg. It should be possible to send the information by emonview to emoncms a vice versa maybe.