Well with the electricity price increase today I changed the price in the sunsynk app and it has changed the value of electricity generated for previous months as well. Is there a way around this? 

Ja that is just sloppy programming. They are probably not used to price increases as often as we are 🙂

9 minutes ago, Superfly said:

LOL  programming these things are not as easy as you think.. in a PC environment we will write to a Json file as a database  .. but with EEPROM it's now or never...

However if they write to a server that's a different matter... I don't know the app.. so just guessing.

The sunsynk dongle sends inverter IoT data to the cloud (probably using mqtt portocol) which is then persisted into a cloud database.

The synsynk app and sunsynk web displays the cloud data.
see https://sunsynk.net
Nothing to do with EEPOM.

Programming these cloud apps is easy.
I wouldn't use json for the rate, just an SQL table.
The issue is sloppy programmers only use a single Rands/kWh rate for all calculations.

 

create table city_power_tariff(
       year_month date not null primary key,
       tariff numeric not null
);

-- my average CoJ rate per month
insert into city_power_tariff(year_month,tariff) values
   ('2021-07-01',2.33),
   ('2021-08-01',2.33),
   ('2021-09-01',2.33),
   ('2021-10-01',2.33),
   ('2021-11-01',2.33),
   ('2021-12-01',2.33),
   ('2022-01-01',2.33),
   ('2022-02-01',2.33),
   ('2022-03-01',2.33),
   ('2022-04-01',2.33),
   ('2022-05-01',2.33),
   ('2022-06-01',2.33),
   ('2022-07-01',2.50),
   ('2022-08-01',2.50),
   ('2022-09-01',2.50),
   ('2022-10-01',2.50),
   ('2022-12-01',2.50),
   ('2023-01-01',2.50),
   ('2023-02-01',2.50),
   ('2023-03-01',2.50),
   ('2023-04-01',2.50),
   ('2023-05-01',2.50),
   ('2023-06-01',2.50),
   ('2023-07-01',2.85) 
;

SELECT
   TO_CHAR(dt, 'Dy DD Mon') as "Period",
   pv_energy as "Solar in",
   load_energy as "Load out",
   grid_energy_in as "Grid in",
   self_energy as "Self_kWh",
   load_energy*tariff as "R Load",
   grid_energy_in*tariff as "R Grid",
   self_energy*tariff as "R Saved"
FROM solar_assistant_day 
LEFT OUTER JOIN city_power_tariff ON date_trunc('month',solar_assistant_day.dt) = city_power_tariff.year_month
WHERE $__timeFilter(dt)
ORDER by dt desc

 

Edited July 4, 20232 yr by system32

34 minutes ago, Superfly said:

LOL  programming these things are not as easy as you think.. in a PC environment we will write to a Json file as a database  .. but with EEPROM it's now or never...

However if they write to a server that's a different matter... I don't know the app.. so just guessing.

I am sure electricity price and daily usage statistics, and calculated costs are not written to EEPROM. That would be madness. It all goes to their cloud service and served up as a webapp.

30 minutes ago, Superfly said:

Yep SQL is much easier from a a Db point of view but Json is more than storage but also web (Javascript/jquery) services friendly.. but let's not get into that - but thanx for the link... I need to check that out more.

I tend to use both JSON and SQL.
I store the IoT data from tasmota and sunsynk into a postgresql database with a JSONB format:
 

-- DDL for a tasmota IoT sensor for the geyser table
CREATE TABLE IF NOT EXISTS tele_geyser_sensor(
    id integer PRIMARY KEY GENERATED ALWAYS AS IDENTITY NOT NULL
    tm timestamptz DEFAULT current_timestamp NOT NULL,
    payload JSONB NOT NULL); -- store the tasmota json payload here

CREATE INDEX tele_geyser_sensor_tm_idx ON tele_geyser_sensor(tm);

Then create a view to access the JSON as a table:

-- PostgreSQL 14 and later allow accessing JSON elements using the [] operator 
-- you can also use the SQL '->' and '->>' operators
CREATE VIEW tele_geyser_sensor_v
AS
 SELECT tm,
    tm::date AS dt,
    payload['ENERGY']['Power']::numeric AS power, -- same as ((payload -> 'ENERGY'::text) ->> 'Power'::text)::numeric AS power
    payload['ENERGY']['Current']::numeric AS current,
    payload['ENERGY']['Voltage']::numeric AS voltage,
    payload['ENERGY']['Today']::numeric AS today,
    payload['ENERGY']['Yesterday']::numeric AS yesterday,
    payload['ENERGY']['Total']::numeric AS total
   FROM tele_geyser_sensor;

 

Edited July 4, 20232 yr by system32