{"action":"created","issue":{"url":"https://api.github.com/repos/nilmtk/nilmtk/issues/413","labels_url":"https://api.github.com/repos/nilmtk/nilmtk/issues/413/labels{/name}","comments_url":"https://api.github.com/repos/nilmtk/nilmtk/issues/413/comments","events_url":"https://api.github.com/repos/nilmtk/nilmtk/issues/413/events","html_url":"https://github.com/nilmtk/nilmtk/issues/413","id":89555615,"number":413,"title":"Storing appliance fingerprints/signatures/priors needs definition","user":{"login":"gjwo","id":12109990,"avatar_url":"https://avatars.githubusercontent.com/u/12109990?v=3","gravatar_id":"","url":"https://api.github.com/users/gjwo","html_url":"https://github.com/gjwo","followers_url":"https://api.github.com/users/gjwo/followers","following_url":"https://api.github.com/users/gjwo/following{/other_user}","gists_url":"https://api.github.com/users/gjwo/gists{/gist_id}","starred_url":"https://api.github.com/users/gjwo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gjwo/subscriptions","organizations_url":"https://api.github.com/users/gjwo/orgs","repos_url":"https://api.github.com/users/gjwo/repos","events_url":"https://api.github.com/users/gjwo/events{/privacy}","received_events_url":"https://api.github.com/users/gjwo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-06-19T12:38:53Z","updated_at":"2015-10-15T12:30:27Z","closed_at":null,"body":"NILMTK doesn't appear to have an agreed format for the storage of a set of labelled fingerprints for appliances, i.e. a way of decoupling the training and disaggregation steps. Have any \"standard\" methods come into common use? If not the following elements would seem to be needed\r\n*  **Result label** (mandatory) <String> the name label associated with appliance described\r\n*  **Result metadata** (optional) further information on the appliance, such as  location - building, room, meter; list of components; see appliance in nilmtk_metadata\r\n*  **Signature** (mandatory) <DataFrame> The signature the appliance will produce in the data - there are a variety of ways this could be represented in a dataframe\r\n*  **Signature metadata** (optional) a description of the signature characteristics, such as granularity, compression methods etc. NB a basic signature type may in fact be mandatory if there can be more than one type\r\n\r\nThis would need to be stored in some kind of defined file format possibly HDF5 so that it could be loaded at a late point in time and used by a disaggregation algorithm. "},"comment":{"url":"https://api.github.com/repos/nilmtk/nilmtk/issues/comments/148371180","html_url":"https://github.com/nilmtk/nilmtk/issues/413#issuecomment-148371180","issue_url":"https://api.github.com/repos/nilmtk/nilmtk/issues/413","id":148371180,"user":{"login":"gjwo","id":12109990,"avatar_url":"https://avatars.githubusercontent.com/u/12109990?v=3","gravatar_id":"","url":"https://api.github.com/users/gjwo","html_url":"https://github.com/gjwo","followers_url":"https://api.github.com/users/gjwo/followers","following_url":"https://api.github.com/users/gjwo/following{/other_user}","gists_url":"https://api.github.com/users/gjwo/gists{/gist_id}","starred_url":"https://api.github.com/users/gjwo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gjwo/subscriptions","organizations_url":"https://api.github.com/users/gjwo/orgs","repos_url":"https://api.github.com/users/gjwo/repos","events_url":"https://api.github.com/users/gjwo/events{/privacy}","received_events_url":"https://api.github.com/users/gjwo/received_events","type":"User","site_admin":false},"created_at":"2015-10-15T12:30:27Z","updated_at":"2015-10-15T12:30:27Z","body":"@JackKelly @nipunreddevil  (as you are looking at Hart85 soon) \r\nAfter having explored the implementation of Hart in nilmtk at some length, and having read Hart's '85 and '92 papers, I think I have a better handle on this now.  See summary of Hart's '92 process below\r\n![image](https://cloud.githubusercontent.com/assets/12109990/10513090/0b817b4c-733d-11e5-998c-79068d627f9e.png)\r\n\r\nThe result of the cluster analysis in nilmtk terms is the list of centroids that have been build by the training step. A single centroid is a rudimentary model for an on/off type of appliance,  by extension a list of centroids would be a rudimentary model for a multi-state or FSM type of appliance (disregarding any continuously variable states or appliances).\r\n\r\nOne of the things I believe is currently missing from the Hart implementation in nilmtk is step 'H' above i.e. the linking of the centroid models to any appliance metadata. If the typical steady power states (active and reactive) were recorded in the metadata, some automatic matching of names to observed patterns would be possible following training and could then be used for disaggregation. This initial centroid values would need to be entered in metadata manually from a training run to bootstrap this process as the plate values for power consumption are unlikely to be accurate enough. There would also need to be a definition of how far from a centroid a result would be an acceptable match.  \r\n\r\nThe results from training could be stored as unnamed centroids, along with metadata including ALL parameters to the training step. The linkage of names to centroids, could be (optionally) stored in the same dataset if the linkage were available. \"Unknown n\" could be used for any centroids not linked.\r\n\r\nIt would them be possible to produce the kind of appliance usage charts included in Hart's papers.\r\n\r\nAppliance Signatures can clearly be more complex than this (see taxonomy below from the '92 paper\r\n![image](https://cloud.githubusercontent.com/assets/12109990/10513598/a276e372-7340-11e5-82cc-b3bafb5317d8.png)\r\nIn particular the transients could be of use in further differentiating between devices. \r\n\r\n"}}