-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General questions on entering data #17
Comments
A component can be any
that looks good but only a few of those attributes are required.
Please see the docs: http://nilm-metadata.readthedocs.org/en/latest/dataset_metadata.html#appliance
Good question! I've just added an
I don't understand.
That sounds sensible. The UK-DALE metadata doesn't do this because it's machine-generated and I have no control over the placement. |
components - I understand components as sub parts of a device, but that didn't appear to be how it was used in UK-DALE - I will read your references again agree, I will leave out references not required portable - I think I treated this a a pseudo room value, not a sure which way works best until I try it in the context of your toolkit. I missed the model stuff because I was working from UK-DALE examples rather than the manual |
dominant_appliance: |
Sure. |
Moved from @gjwo's comment on the UK-DALE metadata issue queue: JackKelly/UK-DALE_metadata#2 (comment)
-components is confusing, does this refer to any electric device, or to the base components described in https://github.com/nilmtk/nilm_metadata/blob/v0.2/central_metadata/appliance_types/components.yaml
In order to be consistent would this be an appropriate appliance template for me to use
appliances:
Questions
what is dominant_appliance: true for?
what about portable appliances?
what's the difference between nominal_consumption and on_power_threshold?
why no model or model number tag - could be significant as signatures become available
I would put the building related data first, then rooms, then meters then appliances i.e. least likely to change first, any reason not to do this?
The text was updated successfully, but these errors were encountered: