BACKGROUND AND CONTEXT
I developed this solution, which optimizes the energy consumption to cheap hours of the day based on the Nordpool day-ahead market prices. Control a water heater and ground source heat pump based on cheap hours of spot priced electricity - #13 by masipila
The spot prices are fetched from Entso-E Transparency Platform’s API. The script action of the rule that fetches the prices looks like this. The helper files (date-helper.js, entsoe.js and influx.js are available in the thread linked above).
dh = require('kolapuuntie/date-helper.js'); entsoe = require('kolapuuntie/entsoe.js'); influx = require('kolapuuntie/influx.js'); // Entso-E bidding zone. zone = '10YFI-1--------U'; // Entso-E API access token. token = 'insert-your-access-token-here'; // Multiplier for VAT tax = 1.24; // Get date range in the correct format for Entso-E API start = dh.getEntsoStart(); end = dh.getEntsoEnd(); // Read spot prices and write them to the database. points = entsoe.getSpotPrices(start, end, zone, token, tax); influx.writePoints('spot_price', points);
What this rule does is that
- It fetches the spot price data from Entso-E API
- Transforms the XML response to JSON with an XSLT transformation which is licensed under MIT license
- Parses the spot prices from the JSON
- Writes the future-timestamped points to Influx DB via the HTTP API of the Influx server.
PURPOSE OF THIS THREAD
I’m considering volunteering to generalize the spot price fetching as a Binding so that it would be easier to use for other community members for their own use cases. However, I would appreciate a bit of guidance since I’m still quite new to openHab and especially I’m new at contributing to openHab (okay, the documentation contribution in the thread linked above is quite significant contribution, but I mean contributing code here).
My current solution is tightly coupled to an Influx DB and it does not use any openHab abstraction layers for anything. The influx.js mentioned above has the influx server’s access parameters hard coded in it.
First of all, I acknowledge that other users might have different database servers than InfluxDB. Secondly, even if this Binding would require InfluxDB, the connection parameters could most probably be read somehow from openHab, which uses the same influx database for normal persistence reasons.
The point here is that the time series that that this rule writes is in the future, because we are talking about day-ahead prices which can be fetched for tomorrow at today afternoon. As far as I’ve let myself understand, the openHab API does not support writing arbitrary timestamps from the future.
- Question 1: Is this assumption (that openHab API does not support writing points with future timestamps) correct? How do the weather forecast Bindings handle this same kind of thing where we want to write a future time series?
- Question 2: If it is correct, does that mean that this Binding will have to be database specific (for example InfluxDB specific, MySQL / MariaDB specific)?
About the open source licensing…
Entso-E API responses the spot prices in a hard to parse XML format because of the way it declares the XML namespaces. It can of course be parsed, but when i did, the code was getting so hard to read that I was not able to read my own code after one beer anymore. To overcome the XML namespaces challenge, I used the XSLT transformation published here: https://www.bjelic.net/2012/08/01/coding/convert-xml-to-json-using-xslt/ That is published under the MIT license. According to openhab-addons/LICENSE at main · openhab/openhab-addons · GitHub, openHab add-ons must comply with the Eclipse license.
- Question 3: Is my assumption correct that MIT licensed code cannot be committed to the openHab repo?
I have a couple of other follow-up questions which depend on the answers to these first questions over here, but I’ll get back to those after these first questions are clear first.