Categories for sensors

[saroele]

Finalise the categories introduced by Vincent and David. These sensor categories should enable automated filtering and aggregation of sensors. For example: to get the total net consumption if different submeters are present, to filter out PV sensors etc.

Next step will be to integrate these catogories in the houseprint, and use it to filter the sensors for the standby power analysis.

Below the proposal of Vincent and David from the dev meeting in April 2015:

gridExport metering of electricity export via grid connection pvProd electricity generation of PV-system gridImport metering of electricity import via grid connection (non-reversible) gridNet net metering of grid connection (reversible meter) gridCons total electricity consumpion after grid connection, including self-consumed PV-generation gridWater metering of total drinking water import gridSub submeter of gridCons gridGas metering of total natural gas import heatProd heat generation of a system (via calorific meter)

Om de siteverbruiken te kennen werk je met een 'metric' die 'meterdata' aggregeert: siteCons =gridNet+gridImport+pvProd-gridExport+gridCons

[saroele]

Added this info in the wiki https://github.com/opengridcc/opengrid/wiki/CodeOverview

[Ryton]

Any progress on this? Should/will the info be coded in the houseprint, a database or hardcoded in a python/notebook script? (last one probably a bad idea for expandability...)

[saroele]

One of the first two :-)

I think for expandability, a db is the best option, inclusive transferring the whole houseprint to that same db. Than we can build an interface to that db similar to how energieid does it. Maybe using the energie-id db is even the quickest solution?

It would be good to have a first something by next sprint. Maybe a simple csv or google sheet is sufficient for a prove of concept? The only thing we need right now is a link between sensor id and category.

[pedrusky]

I prefer a loosely coupled system, where the Open Grid server and the local development environment run independently from EnergieID or any other system. What’s the approach you guys are following for the weather data and sensor data? They are fetched on a regular basis and stored locally, correct? Let’s do the same with the houseprint data. EnergieID can provide the data, I can create an API for you guys to fetch the JSON whenever you feel like.

And what about storing the JSON in a local MongoDB? Very scalable, and very flexible (due to the JSON scheme). There are MongoDB drivers for Python available. I can participate to setup the MongoDB, it’s on my professional bucket list anyway.

If we decide to go forward with this approach, then let’s define what houseprint data is missing in the JSON that I have sent earlier on. Also, the JSON was just an example, I’m open to any improvement with respect to naming conventions, labels, enum values etc.

Regards, D.

[dirkdevriendt]

If we're talking bucketlists: MongoDB is sooo 2014. Today RethinkDB is all the rage :-) http://rethinkdb.com/ I have the impression high volume performance is still behind on MongoDB by a large margin, but I like where they're going and for low volumes like the houseprint, the problem should be negligable.

[pedrusky]

Maybe it’s time to rethink my bucket list ☺

[saroele]

Bleeding-Edge-Dirk! Let's discuss on Tuesday. @pedrusky maybe you can post the mail you've sent me in this thread, it's a very good basis for the discussion.

[saroele]

By checking the project haystack again, I think we should really take the time to spit this out, apply it and propose enhancements to the standard if needed.

Interesting, the founder of the project is also the founder of skyfoundry, a platform to watch! Here's an (older but still relevant) interview with him. I specifically like this part:

It turns out that semantic modeling of data is the key to streamlined interoperability among applications and devices of all types.

For example, Haystack tagging makes it possible for visualization software to assemble graphics of equipment systems with almost no human involvement -- some companies using Haystack have basically accomplished the holy grail of “self assembling graphic displays”. This is possible because the software can “understand” the meaning of the devices and their data and make decisions to build an appropriate graphic.

And other devices and systems like lighting controls and wireless devices support Haystack because it enables their products to be integrated into a “whole” with far less work. It’s very much like the revolution that “plug and play” caused in the PC market -- devices can self-describe themselves and their data to any external application that wants to interact with them. It’s the next level beyond simply having a standard wire protocol where you can get data “IF” you know what to look for and how to ask for it.

Project haystack has some interesting members, like KNX, Siemens, BuildingSystemSolutions, Wattstopper, Lynxspring, ...