@golemio/energetics 1.17.2-dev.2897106860 → 2.0.0-dev.2954231424

package/db/example/09_enapo_consumption_history.sql

@@ -13,7 +13,8 @@
 
 INSERT INTO eno_budova (gid, zdroj, nazev, oznaceni, platnost_od) VALUES
 	('GIDCH1', 'mhmp', 'ZŠ Spotřeba', 'ZSS', '2019-01-01'),
-	('GIDCH2', 'mhmp', 'Objekt s více plynoměry', 'OVP', '2019-01-01');
+	('GIDCH2', 'mhmp', 'Objekt s více plynoměry', 'OVP', '2019-01-01'),
+	('GIDCH5', 'mhmp', 'Objekt s výměnou plynoměru', 'OVY', '2019-01-01');
 
 INSERT INTO enapo_gid_mapping (place_id, id_type, commodity, gid, is_first_gid, link_source, valid_from, valid_to) VALUES
 	('859182400000000101', 'ean', 'electricity', 'GIDCH1', true, 'mock', '2022-01-01', NULL),
@@ -21,7 +22,11 @@ INSERT INTO enapo_gid_mapping (place_id, id_type, commodity, gid, is_first_gid,
 	-- one physical meter behind two PPAS registrations
 	('27ZG100Z0000CH02', 'eic', 'gas', 'GIDCH2', true, 'mock', '2022-01-01', NULL),
 	-- two physical meters on one EIC
-	('27ZG100Z0000CH03', 'eic', 'gas', 'GIDCH2', true, 'mock', '2022-01-01', NULL);
+	('27ZG100Z0000CH03', 'eic', 'gas', 'GIDCH2', true, 'mock', '2022-01-01', NULL),
+	-- two physical meters on one EIC that AVE lists under one serial
+	('27ZG100Z0000CH04', 'eic', 'gas', 'GIDCH5', true, 'mock', '2022-01-01', NULL),
+	-- one meter whose serial changes mid-series, then a meter exchange
+	('27ZG100Z0000CH05', 'eic', 'gas', 'GIDCH5', true, 'mock', '2022-01-01', NULL);
 
 
 -- =================================================================================================
@@ -68,9 +73,8 @@ FROM generate_series(timestamptz '2026-03-01 00:00:00+00', timestamptz '2026-03-
 -- Gas, metered (PPAS InternetAVE)
 -- =================================================================================================
 -- Value is core(first day of next month) - core(first day of current month), core being the
--- cumulative meter state in m3. The corediff rows below carry no weight in that computation any
--- more; they exist only to seed gas_registration, which picks the (device_serial_number, place_id)
--- an EIC's 'core' readings must be joined through.
+-- cumulative meter state in m3, paired per (id, place_id) and summed over the place_ids of an id.
+-- The corediff rows below carry no weight in that computation.
 
 -- 27ZG100Z0000CH01: single registration, one meter.
 INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
@@ -86,9 +90,9 @@ INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, pl
 	('27ZG100Z0000CH01', 'eic', 900330.0, '2026-08-01 01:00:00+02', 'core', 'ppas_ave_api', '9900001', 'GAS-CH-1');
 -- June = 900180 - 900060 = 120; July = 900330 - 900180 = 150.
 
--- 27ZG100Z0000CH02, 2026-07: TWO place_ids, ONE meter serial - two live registrations of the same
--- physical meter. gas_registration picks one per serial (the most recently reporting one, here
--- 9900012), so only that place_id's core readings feed the diff: 100 m3, NOT 200.
+-- 27ZG100Z0000CH02, 2026-07: TWO place_ids, ONE meter serial, but only 9900012 carries core
+-- readings, so only it feeds the diff: 100 m3, NOT 200. A registration without core readings adds
+-- nothing.
 INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
 	('27ZG100Z0000CH02', 'eic', 100.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900011', 'GAS-CH-DUP'),
 	('27ZG100Z0000CH02', 'eic', 100.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900012', 'GAS-CH-DUP'),
@@ -105,6 +109,33 @@ INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, pl
 	('27ZG100Z0000CH03', 'eic', 800000.0, '2026-07-01 01:00:00+02', 'core', 'ppas_ave_api', '9900022', 'GAS-CH-B'),
 	('27ZG100Z0000CH03', 'eic', 800100.0, '2026-08-01 01:00:00+02', 'core', 'ppas_ave_api', '9900022', 'GAS-CH-B');
 
+-- 27ZG100Z0000CH04, 2026-07: TWO place_ids with different readings under ONE serial. Production has
+-- this (27ZG100Z0000197E): the integration stamps rows with the serial AVE lists at fetch time, so a
+-- shared serial does not mean a shared meter. Both meters count: 100 + 1 = 101 m3. Picking one
+-- place_id per serial would report 1 m3 and lose the main meter.
+-- 2026-08: the small meter drops by 1 m3 while the main one adds 100. The negative check is on the
+-- month total, so August is 100 - 1 = 99 m3, not empty.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
+	('27ZG100Z0000CH04', 'eic', 100.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900041', 'GAS-CH-SHARED'),
+	('27ZG100Z0000CH04', 'eic', 1.0, '2026-07-01 01:00:00+02', 'corediff', 'ppas_ave_api', '9900042', 'GAS-CH-SHARED'),
+	('27ZG100Z0000CH04', 'eic', 600000.0, '2026-07-01 01:00:00+02', 'core', 'ppas_ave_api', '9900041', 'GAS-CH-SHARED'),
+	('27ZG100Z0000CH04', 'eic', 600100.0, '2026-08-01 01:00:00+02', 'core', 'ppas_ave_api', '9900041', 'GAS-CH-SHARED'),
+	('27ZG100Z0000CH04', 'eic', 4000.0, '2026-07-01 01:00:00+02', 'core', 'ppas_ave_api', '9900042', 'GAS-CH-SHARED'),
+	('27ZG100Z0000CH04', 'eic', 4001.0, '2026-08-01 01:00:00+02', 'core', 'ppas_ave_api', '9900042', 'GAS-CH-SHARED'),
+	('27ZG100Z0000CH04', 'eic', 600200.0, '2026-09-01 01:00:00+02', 'core', 'ppas_ave_api', '9900041', 'GAS-CH-SHARED'),
+	('27ZG100Z0000CH04', 'eic', 4000.0, '2026-09-01 01:00:00+02', 'core', 'ppas_ave_api', '9900042', 'GAS-CH-SHARED');
+
+-- 27ZG100Z0000CH05: one place_id whose serial flips between boundary readings, as a refetch after a
+-- meter exchange leaves it (27ZG100Z00126318). June = 1050 - 1000 = 50 and July = 1120 - 1050 = 70
+-- despite the flip. The exchanged meter restarts lower on 2026-09-01, so August is null rather than
+-- a negative volume. September reads the same at both ends: 0 m3, which is also 0 kWh.
+INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
+	('27ZG100Z0000CH05', 'eic', 1000.0, '2026-06-01 01:00:00+02', 'core', 'ppas_ave_api', '9900051', 'GAS-CH-OLD'),
+	('27ZG100Z0000CH05', 'eic', 1050.0, '2026-07-01 01:00:00+02', 'core', 'ppas_ave_api', '9900051', 'GAS-CH-NEW'),
+	('27ZG100Z0000CH05', 'eic', 1120.0, '2026-08-01 01:00:00+02', 'core', 'ppas_ave_api', '9900051', 'GAS-CH-OLD'),
+	('27ZG100Z0000CH05', 'eic', 15.0, '2026-09-01 01:00:00+02', 'core', 'ppas_ave_api', '9900051', 'GAS-CH-NEW'),
+	('27ZG100Z0000CH05', 'eic', 15.0, '2026-10-01 01:00:00+02', 'core', 'ppas_ave_api', '9900051', 'GAS-CH-NEW');
+
 
 -- =================================================================================================
 -- Gas, invoices (PPAS distribution) for 27ZG100Z0000CH01
@@ -213,13 +244,16 @@ INSERT INTO enapo_eb_consumption (idodbmisto_rspotrebyfa, idodbmistoom, ean_eic,
 	(9000005, 90401, '859182400000000401', 1, '2025-11-01', '2025-12-31', 4.0, 2.0, 6.0, 2025),
 	(9000006, 90401, '859182400000000401', 1, '2025-10-15', '2025-10-31', 1.0, 0.0, 1.0, 2025),
 	-- Gas: kWh as well, EB has no combustion heat to derive m3.
-	(9000007, 90403, '27ZG100Z0000CH41', 2, '2026-01-01', '2026-01-31', 12.345, NULL, 12.345, 2026);
+	(9000007, 90403, '27ZG100Z0000CH41', 2, '2026-01-01', '2026-01-31', 12.345, NULL, 12.345, 2026),
+	(9000008, 90403, '27ZG100Z0000CH41', 2, '2026-02-01', '2026-02-28', 5.0, NULL, 5.0, 2026);
 
 -- The PPAS meter reads all of January too, but in m3 only: EB must still serve the month, being its only kWh.
+-- February reads the same at both ends: 0 m3 is 0 kWh, a whole month read in kWh, so EB's 5000 kWh loses.
 INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number) VALUES
 	('27ZG100Z0000CH41', 'eic', 1200.0, '2026-02-01 01:00:00+01', 'corediff', 'ppas_ave_api', '9900041', 'GAS-CH-4'),
 	('27ZG100Z0000CH41', 'eic', 600000.0, '2026-01-01 01:00:00+01', 'core', 'ppas_ave_api', '9900041', 'GAS-CH-4'),
-	('27ZG100Z0000CH41', 'eic', 601200.0, '2026-02-01 01:00:00+01', 'core', 'ppas_ave_api', '9900041', 'GAS-CH-4');
+	('27ZG100Z0000CH41', 'eic', 601200.0, '2026-02-01 01:00:00+01', 'core', 'ppas_ave_api', '9900041', 'GAS-CH-4'),
+	('27ZG100Z0000CH41', 'eic', 601200.0, '2026-03-01 01:00:00+01', 'core', 'ppas_ave_api', '9900041', 'GAS-CH-4');
 
 INSERT INTO enapo_measurements (id, id_type, value, "timestamp", var, source, place_id, device_serial_number)
 SELECT '859182400000000401', 'ean', 10.0, d, 'EActi_VT_NT_DaySum', 'predi_input', '8110000401', 'EL-CH-4'

package/db/migrations/postgresql/20261013090000-enapo-ave-zero-core.js

@@ -0,0 +1,53 @@
+'use strict';
+
+var dbm;
+var type;
+var seed;
+var fs = require('fs');
+var path = require('path');
+var Promise;
+
+/**
+  * We receive the dbmigrate dependency from dbmigrate initially.
+  * This enables us to not have to rely on NODE_PATH.
+  */
+exports.setup = function(options, seedLink) {
+  dbm = options.dbmigrate;
+  type = dbm.dataType;
+  seed = seedLink;
+  Promise = options.Promise;
+};
+
+exports.up = function(db) {
+  var filePath = path.join(__dirname, 'sqls', '20261013090000-enapo-ave-zero-core-up.sql');
+  return new Promise( function( resolve, reject ) {
+    fs.readFile(filePath, {encoding: 'utf-8'}, function(err,data){
+      if (err) return reject(err);
+      console.log('received data: ' + data);
+
+      resolve(data);
+    });
+  })
+  .then(function(data) {
+    return db.runSql(data);
+  });
+};
+
+exports.down = function(db) {
+  var filePath = path.join(__dirname, 'sqls', '20261013090000-enapo-ave-zero-core-down.sql');
+  return new Promise( function( resolve, reject ) {
+    fs.readFile(filePath, {encoding: 'utf-8'}, function(err,data){
+      if (err) return reject(err);
+      console.log('received data: ' + data);
+
+      resolve(data);
+    });
+  })
+  .then(function(data) {
+    return db.runSql(data);
+  });
+};
+
+exports._meta = {
+  "version": 1
+};

package/db/migrations/postgresql/20261013090100-enapo-consumption-history-gas.js

@@ -0,0 +1,53 @@
+'use strict';
+
+var dbm;
+var type;
+var seed;
+var fs = require('fs');
+var path = require('path');
+var Promise;
+
+/**
+  * We receive the dbmigrate dependency from dbmigrate initially.
+  * This enables us to not have to rely on NODE_PATH.
+  */
+exports.setup = function(options, seedLink) {
+  dbm = options.dbmigrate;
+  type = dbm.dataType;
+  seed = seedLink;
+  Promise = options.Promise;
+};
+
+exports.up = function(db) {
+  var filePath = path.join(__dirname, 'sqls', '20261013090100-enapo-consumption-history-gas-up.sql');
+  return new Promise( function( resolve, reject ) {
+    fs.readFile(filePath, {encoding: 'utf-8'}, function(err,data){
+      if (err) return reject(err);
+      console.log('received data: ' + data);
+
+      resolve(data);
+    });
+  })
+  .then(function(data) {
+    return db.runSql(data);
+  });
+};
+
+exports.down = function(db) {
+  var filePath = path.join(__dirname, 'sqls', '20261013090100-enapo-consumption-history-gas-down.sql');
+  return new Promise( function( resolve, reject ) {
+    fs.readFile(filePath, {encoding: 'utf-8'}, function(err,data){
+      if (err) return reject(err);
+      console.log('received data: ' + data);
+
+      resolve(data);
+    });
+  })
+  .then(function(data) {
+    return db.runSql(data);
+  });
+};
+
+exports._meta = {
+  "version": 1
+};

package/db/migrations/postgresql/sqls/20261013090000-enapo-ave-zero-core-down.sql

@@ -0,0 +1 @@
+-- The deleted zero readings carried no information, so there is nothing to restore.

package/db/migrations/postgresql/sqls/20261013090000-enapo-ave-zero-core-up.sql

@@ -0,0 +1,7 @@
+-- AVE sends a zero operating amount for an hour it has no reading for. `core` is a cumulative meter
+-- reading, so a zero is never a real value: it only turns the monthly difference in
+-- mv_enapo_om_consumption negative (shown as missing data) or absurdly large.
+DELETE FROM enapo_measurements
+WHERE source = 'ppas_ave_api'
+	AND var = 'core'
+	AND value = 0;