search

GoumJer / Huawei_Sun2000

Shell script to read data from Huawei website en send to Domoticz/Influx
2 stars 1 forks source link

Domoticz Dummy sensortype usage #3

Closed RikBast closed 1 year ago

RikBast commented 1 year ago

Do we need to use only the dummy sensor with sensor type custom sensor? Would be nice to have also diagrams besides the graph, with sensor type electric or usage we can generate diagrams.

MichelRabozee commented 1 year ago

OK. I created a new Electricity sensor and feed them both (one with active_power, the new one with mppt_power so I can compare for a few days). Thank you for your investigation !

RikBast commented 1 year ago

OK. I created a new Electricity sensor and feed them both (one with active_power, the new one with mppt_power so I can compare for a few days). Thank you for your investigation !

You added a new line in the code?

MichelRabozee commented 1 year ago

I added a new variable to receive mppt_power, myCurrentMPPTW (value of ppt_power * 1000) and a second curl line referring to my new sensor curl "$myDomoticzURL/json.htm?type=command&param=udevice&idx=$DomoticzHuaweiGeneratedMPPTRealTime&nvalue=0&svalue=$myCurrentMPPTW;$myTotalWh"

The weather is quite variable today here.

Graph with active_power:

image

Graph with mppt_power:

image

The big blue block is due to Domoticz seeing the total value for the first time. Tomorrow, the data will be more "actual".

RikBast commented 1 year ago

Let’s see!

calling the API is not that stable, as you said. So we miss data in comparison with the fusion solar app.

MichelRabozee commented 1 year ago

Yeah, very strange that only that API call (getDevRealKpi) is targeted by the "API quota control system", because none of the other are generating calling issues, even if used every minute. And the API guide specifically says every minute is OK. I guess there is an issue there in the server, since at least 2 years as I see in their forums, but Huawai refuse to acknoledge it. Or just answer in case of that issue to write a mail to their support. No idea of what happens if you contact the support by mail, because no-one in the forum gives further information.

RikBast commented 1 year ago

I see that the hourly energy remains negative after the grid stops producing energy. In the API call the inverter_power = 0 , so I don't understand the negative value.

Schermafbeelding 2022-09-29 om 21 52 34
MichelRabozee commented 1 year ago

The "energy generated" comes from the "total_power" value. To have a negative value, it means that the "total_power" goes backwards :-(

What are the values for total_power in the debug file "realtime_inverter_data.txt" ?

RikBast commented 1 year ago

I tried the script with the txt file, however it's not generated when using crontab, only if I run the script manually

RikBast commented 1 year ago

The "energy generated" comes from the "total_power" value. To have a negative value, it means that the "total_power" goes backwards :-(

This is really strange, as said I need to debug the script better, I am no programmer, so for me it's more difficult to understand

If you put sensor on computed, it calculates the blue diagrams from the actual mppt_power variable. No negative values

What are the values for total_power in the debug file "realtime_inverter_data.txt" ?

MichelRabozee commented 1 year ago

I tried the script with the txt file, however it's not generated when using crontab, only if I run the script manually

it is a simple "echo" command, it should work. The only thing to know is where the file is written :-) On which user is the crontab running ? If the crontab entry is "cd / ; ./HuaweiSolar_API.sh InverterRealTime >/dev/null 2>&1", the "realtime_inverter_data.txt" should be in the same directory as the "HuaweiSolar_API.sh" script (that directory should be writeable to the user under which crontab runs for that entry). If the crontab entry is "//HuaweiSolar_API.sh InverterRealTime >/dev/null 2>&1", the "realtime_inverter_data.txt" should be in the home directory of the user under which crontab runs for that entry.

Anyway, if the "computed" value is good for you, I guess you may leave it that way (in my case, the graph remained empty when I chose that option).

RikBast commented 1 year ago

Have you ever tried to get the data directly from the inverter instead of the Huawei servers? It has an IP address, but don't know if it can act as a 'server'

MichelRabozee commented 1 year ago

No, and I did not find enough information to go into it reliably.

RikBast commented 1 year ago

I tried the script with the txt file, however it's not generated when using crontab, only if I run the script manually

it is a simple "echo" command, it should work. The only thing to know is where the file is written :-) On which user is the crontab running ? If the crontab entry is "cd / ; ./HuaweiSolar_API.sh InverterRealTime >/dev/null 2>&1", the "realtime_inverter_data.txt" should be in the same directory as the "HuaweiSolar_API.sh" script (that directory should be writeable to the user under which crontab runs for that entry). If the crontab entry is "//HuaweiSolar_API.sh InverterRealTime >/dev/null 2>&1", the "realtime_inverter_data.txt" should be in the home directory of the user under which crontab runs for that entry.

Anyway, if the "computed" value is good for you, I guess you may leave it that way (in my case, the graph remained empty when I chose that option).

realtime_inverter_data.txt

Total runs indeed back after midnight and today total is reset to zero.

MichelRabozee commented 1 year ago

Yes, the "total" values (and the "today" ones, but the script does not use the "today" values) are going bezerk (even around 18:24:02, it goes backwards ???). To prevent that, I suggest to use the piece of code I mentioned above (this code makes sure the "total" value is only increasing):

    PreviousTotalEnergyFile="~/previous_total_energy.txt"
    # make sure the total energy value keeps growing
    if [ -r $PreviousTotalEnergyFile ]
    then
        previousTotalEnergy=`cat $PreviousTotalEnergyFile`

    if [ $previousTotalEnergy -gt $myTotalWh ]
        then
            myTotalWh=$previousTotalEnergy
        fi
    fi
    echo $myTotalWh > $PreviousTotalEnergyFile

(code to put after the line myTotalWh=$(echo "scale=0; ${myTotalkWh} * 1000 / 1" | bc | sed 's/^./0./') )

RikBast commented 1 year ago

What does: PreviousTotalEnergyFile="~/previous_total_energy.txt" do?

I need to create this file?

MichelRabozee commented 1 year ago

The file will be created automatically into the home directory off the user under which the cron runs. If you prefer, you may just replace that line with:

PreviousTotalEnergyFile="previous_total_energy.txt"

and the file will be created in the same directory as the "realtime_inverter_data.txt" file.

MichelRabozee commented 1 year ago

Hello, I just got an issue similar to yours:

image

I will add the piece of code above as well :-) [it really seems that the "total" values go berserk at some point, eand not necessarily around midnight...] The data were:

Sat Oct 1 05:32:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Current MPPT (kW): 0 kW, Current MPPT (W): 0 W, Total: 218430 Wh, Today: 0 kWh
Sat Oct 1 06:04:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Current MPPT (kW): 0 kW, Current MPPT (W): 0 W, Total: 0 Wh, Today: 0 kWh

...

Sat Oct 1 07:44:01 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Current MPPT (kW): 0 kW, Current MPPT (W): 0 W, Total: 0 Wh, Today: 0 kWh
Sat Oct 1 07:52:01 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Current MPPT (kW): 0 kW, Current MPPT (W): 0 W, Total: 218430 Wh, Today: 0 kWh
RikBast commented 1 year ago
Schermafbeelding 2022-10-01 om 09 20 17

Look what's happening after I changed back the sensor to 'From Device' plus the extra code you supplied me at around 21.45h last night. This might me due to the new calculation when switching 'Computing' to 'From Device' I guess.

Furthermore the total is constant, but suddenly there is a drop in the number of Total Wh at 23:32h?,notice also that Today value varies a little (why that is, I don't know, Huawei server issue I presume)

Fri 30 Sep 22:00:02 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 481170 Wh, Today: 17.48 kWh Fri 30 Sep 22:04:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.47 kWh Fri 30 Sep 22:08:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.46 kWh Fri 30 Sep 22:12:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.46 kWh Fri 30 Sep 22:16:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.47 kWh Fri 30 Sep 22:20:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.47 kWh Fri 30 Sep 22:24:03 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.46 kWh Fri 30 Sep 22:28:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.44 kWh Fri 30 Sep 22:32:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.45 kWh Fri 30 Sep 22:36:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.45 kWh Fri 30 Sep 22:40:02 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 481170 Wh, Today: 17.45 kWh Fri 30 Sep 22:44:02 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 481170 Wh, Today: 17.43 kWh Fri 30 Sep 22:48:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.43 kWh Fri 30 Sep 22:52:03 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 481170 Wh, Today: 17.42 kWh Fri 30 Sep 22:56:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.41 kWh Fri 30 Sep 23:00:03 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.41 kWh Fri 30 Sep 23:04:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.41 kWh Fri 30 Sep 23:08:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.41 kWh Fri 30 Sep 23:12:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.4 kWh Fri 30 Sep 23:16:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.39 kWh Fri 30 Sep 23:20:03 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.39 kWh Fri 30 Sep 23:24:03 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 481170 Wh, Today: 17.4 kWh Fri 30 Sep 23:28:22 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: Wh, Today: kWh Fri 30 Sep 23:32:02 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 480890 Wh, Today: 17.38 kWh Fri 30 Sep 23:36:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 17.39 kWh Fri 30 Sep 23:40:02 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 480900 Wh, Today: 17.39 kWh Fri 30 Sep 23:44:03 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 17.37 kWh Fri 30 Sep 23:48:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 17.38 kWh Fri 30 Sep 23:52:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 17.36 kWh Fri 30 Sep 23:56:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 17.36 kWh Sat 1 Oct 00:00:03 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:04:02 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:08:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:12:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:16:03 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:20:04 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:24:03 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:28:03 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 480900 Wh, Today: 0 kWh Sat 1 Oct 00:32:32 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: Wh, Today: kWh Sat 1 Oct 00:36:10 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480100 Wh, Today: 0 kWh Sat 1 Oct 00:40:04 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480100 Wh, Today: 0 kWh Sat 1 Oct 00:44:03 CEST 2022 Current (kW): kW, Current (W): -N/A- W, Total: 480100 Wh, Today: 0 kWh Sat 1 Oct 00:48:05 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480100 Wh, Today: 0 kWh Sat 1 Oct 00:52:05 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480100 Wh, Today: 0 kWh Sat 1 Oct 00:56:02 CEST 2022 Current (kW): 0 kW, Current (W): 0 W, Total: 480100 Wh, Today: 0 kWh

MichelRabozee commented 1 year ago

So, even with the code to make sure the values when total decreases are not taken into account, the graph continue to show negative values ? OK, I will better look into it (as mine is exhibiting again this behaviour, I hopefully will be able to see what's happening (but it is definitively on Huawei server's side).

RikBast commented 1 year ago

So, even with the code to make sure the values when total decreases are not taken into account, the graph continue to show negative values ?

It stopped after these 3 negative bars (from 22h - 01h), let's wait tonight will bring

OK, I will better look into it (as mine is exhibiting again this behaviour, I hopefully will be able to see what's happening (but it is definitively on Huawei server's side).

RikBast commented 1 year ago

Here is an example for the battery output:

{ "data": [ { "devId": 1000000035314944, "dataItemMap": { "max_discharge_power": 2500.0, "max_charge_power": 2500.0, "battery_soh": 0.0, "busbar_u": 615.5, "discharge_cap": 2.67, ---------> Discharged energy in kWh "ch_discharge_power": -19.0, --------> Charge/Discharge power in W "run_state": 1, "battery_soc": 16.0, ---------> remaining percentage of the battery available "ch_discharge_model": 4.0, "charge_cap": 0.01, ---------> Charged energy in kWh "battery_status": 2.0 } } ], "failCode": 0, "message": null, "params": { "currentTime": 1664610269388, "devIds": "1000000035314944", "devTypeId": 39 }, "success": true

RikBast commented 1 year ago

So, even with the code to make sure the values when total decreases are not taken into account, the graph continue to show negative values ?

It stopped after these 3 negative bars (from 22h - 01h), let's wait tonight will bring

OK, I will better look into it (as mine is exhibiting again this behaviour, I hopefully will be able to see what's happening (but it is definitively on Huawei server's side).

Look at the 2 other sensors for Today and Total, these values also change in the evening when the sun is gone, they should remain stable.

RikBast commented 1 year ago

I am trying to get battery data, but I can't retrieve the devIds, I copied the Build Inverter Device Request header and changed Inverter to Battery. The same for the main function. Error I get:

BatteryDeviceID: {"data":null,"failCode":20005,"message":null,"params":{"currentTime":1664624983801,"devIds":"","devTypeId":39},"success":false}jq: error (at :0): Cannot iterate over null (null) ./HuaweiSolar_API_Battery.sh: line 320: myCurrent%=: command not found Current Battery Status(%): %

I need to find out how to retrieve the devIds.....what's the trick here?

MichelRabozee commented 1 year ago

If you do ./HuaweiSolar_API.sh Devices, you should get the devices linked to your plant:

./HuaweiSolar_API.sh Devices
Device Type: 62, Device ID: 1000000035294539, Device name: "Dongle-1"
Device Type: 38, Device ID: 1000000035294540, Device name: "Inverter-1"

The battery is indeed device type 39, you should put the corresponding device ID into the "devids" field

RikBast commented 1 year ago

yes , I tried that, works

for the inverter I use this:

myInverterDeviceHeaderData="{\"devIds\": \"$inverterDeviceID\",\"devTypeId\": \"1\"}"

I get the devIds after running ./HuaweiSolar_API.sh InverterRealTime Y, I don't put devIds inside the code

So I thought it's the same for the battery:

myBatteryDeviceHeaderData="{\"devIds\": \"$batteryDeviceID\",\"devTypeId\": \"39\"}" ?

MichelRabozee commented 1 year ago

inverterDeviceID is defined inside the « HuaweiSolar.env », you have to make a similar entry for « batteryDeviceID »

RikBast commented 1 year ago

Ah, ofcourse, stupid me. Plus don't use % in variables hahaha. Instead put 'Percentage'

StationCode: NE=35314940 BatteryDeviceID: 1000000035314944 Current Battery Status(%): 100

MichelRabozee commented 1 year ago

To have the % sign, just escape it:

\%
RikBast commented 1 year ago
Schermafbeelding 2022-10-01 om 17 45 04

Getting there :-)

Only issue is the difference between the daily generated energy in the 'single' and 'double' sensor

MichelRabozee commented 1 year ago

Nice ! What kind of sensor did you use for the "Battery Status" ?

MichelRabozee commented 1 year ago

Oops, just saw a "Percentage" sensor exists in Domoticz ;-)

RikBast commented 1 year ago

Plus charge discharge graph. Don't know if I should use this 'double' sensor:

Schermafbeelding 2022-10-01 om 18 29 36
MichelRabozee commented 1 year ago

The Energy (double) sensor, I do not know how it will react (as it expects a cumulative data for the « total » and it computes from that total the daily values).

Maybe a P1 Smart Meter sensor would be a better fit (by mapping the « charging » to the P1 « returned » and the « discharging » to the P1 « usage »)

RikBast commented 1 year ago

If I translate that into programming:

  1. First check if value is positive or negative
  2. If negative then store in Discharge variable
  3. If positive then store in Charge variable
  4. curl these 2 variables to the P1 smart meter in Domoticz

Like that I think

MichelRabozee commented 1 year ago

Roughly, yes, you get it.

Some caveats though: the P1 Smart Meter in Domoticz needs 6 values, with 1 curl at once:

curl "$myDomoticzURL/json.htm?type=command&param=udevice&idx=$batteryUsageID&nvalue=0&svalue=$USAGE1;$USAGE2;$RETURN1;$RETURN2;$CONS;$PROD"

First of all, all values need to be in Watts and Wh (not kW or kWh): the "discharge_cap" and "charge_cap" need to be multiplied by 1000. [the code is something like: myVALUEWh=$(echo "scale=0; ${myVALUEkWh} * 1000 / 1" | bc | sed 's/^./0./') ]

The "USAGE1" and "RETURN1" need to be filled with a cumulative value for respectively total discharge_cap and charge_cap. If those are not a total value since the start of the battery life, some logic will need to be put in place, depending on the period those data are cumulated (day, hour ?); as I do not have yet the battery, I have no clue. But if you log the retrieved data to a file (like the "echo" we used to search why the inverter totals were going backwards), we should be able to see if those data are always cumulative or reset every day, or hour or ??? (the doc is not very clear about that).

In the battery case, the "USAGE2" and "RETURN2" are irrelevant (in a P1 power meter, those are used for the "low price" hours.

Regarding the "CONS" and "PROD", those are to be mapped to respectively negative "ch_discharge_power" and positive "ch_discharge_power".

RikBast commented 1 year ago

Working hard on it :-)

Slowly succeeding

[ -n VAR ] means Var > O, right?

MichelRabozee commented 1 year ago

I do not think so, -n means "contents of variable is not empty". I would use [ VAR -gt 0 ] to test var > 0 (and [ VAR -ge 0 ] for VAR >= 0)

cf: https://linuxize.com/post/bash-if-else-statement/

RikBast commented 1 year ago
Schermafbeelding 2022-10-02 om 16 12 30

What do you think of this amateur :-) code?

Get Battery Device Real Time data

#################################### BatteryRealTime () {

BuildBatteryDeviceHeader

Echo ====== Echo "Existing token: "$myToken Echo "StationCode: "$stationCode Echo "BatteryDeviceID: "$batteryDeviceID

curl -s -X POST -H "CONTENT-Type:application/json" -H "XSRF-TOKEN:$myToken" -d "$myBatteryDeviceHeaderData" $baseURL/getDevRealKpi > $mydir/batterydevicerealtime.$$

cat $mydir/batterydevicerealtime.$$

myCurrentPercentage=$(cat $mydir/batterydevicerealtime.$$ |jq '.data[]|."dataItemMap".battery_soc' | bc | sed 's/^./0./') myCurrentChargeDischarge=$(cat $mydir/batterydevicerealtime.$$ |jq '.data[]|."dataItemMap".ch_discharge_power' | bc | sed 's/^./0./') myCurrentChargeCap=$(cat $mydir/batterydevicerealtime.$$ |jq '.data[]|."dataItemMap".charge_cap' | bc | sed 's/^./0./') myCurrentDischargeCap=$(cat $mydir/batterydevicerealtime.$$ |jq '.data[]|."dataItemMap".discharge_cap' | bc | sed 's/^./0./')

myCurrentChargeCapWh=$(echo "scale=0; ${myCurrentChargeCap} 1000 / 1" | bc | sed 's/^./0./') myCurrentDischargeCapWh=$(echo "scale=0; ${myCurrentDischargeCap} 1000 / 1" | bc | sed 's/^./0./')

Echo "Current Battery Status(%): "$myCurrentPercentage Echo "Charge/Discharge Power (W): "$myCurrentChargeDischarge Echo "Charged energy (kWh): "$myCurrentChargeCap Echo "Discharged energy (kWh): "$myCurrentDischargeCap

Store the values over the json interface in Domoticz

if [ -z $myCurrentPercentage ] then myCurrentPercentage="-N/A-" else curl "$myDomoticzURL/json.htm?type=command&param=udevice&idx=$DomoticzHuaweiBatteryPercentage&nvalue=0&svalue=$myCurrentPercentage" fi

Store the values over the json interface in Domoticz

if [ -z $myCurrentChargeDischarge ] then myCurrentChargeDischarge="-N/A-" elif [ $myCurrentChargeDischarge -gt 0 ] then myCurrentCharge=$myCurrentChargeDischarge Echo "CurrentCharge (W): "$myCurrentCharge else myCurrentDischarge=$myCurrentChargeDischarge Echo "CurrentDischarge (W): "$myCurrentDischarge fi curl "$myDomoticzURL/json.htm?type=command&param=udevice&idx=$batteryUsageID&nvalue=0&svalue=$myCurrentDischargeCapWh;$USAGE2;$myCurrentChargeCapWh;$RETURN2;$myCurrentDischarge;$myCurrentCharge"

}

MichelRabozee commented 1 year ago

That rocks !!!! :-) Seems perfect ! Nothing more to do after my battery arrives on next Wednesday. As they need to change the inverter (from a 2KTL to a 4 KTL because currently my solar panels may produce 3,2 kWc and they are obviously capped to 2, and I have no clue why the installer put a 2KTL instead of a 4KTL), I hope my openAPI codes will still work without a need to ask for new ones...

RikBast commented 1 year ago

That rocks !!!! :-) Seems perfect ! Nothing more to do after my battery arrives on next Wednesday.

Thx!

As they need to change the inverter (from a 2KTL to a 4 KTL because currently my solar panels may produce 3,2 kWc and they are obviously capped to 2, and I have no clue why the installer put a 2KTL instead of a 4KTL), I hope my openAPI codes will still work without a need to ask for new ones...

Ah yes, I had to educate the salesman about inverter power performance and system losses. At first they opted for 4kW Inverter with installed 4,68 kWc, so I wanted at least 5kW, ended up with 6kW Inverter. The 5kW battery will charge with max 2,5 kW, your 10 kW with max 5kW. Maybe you need more panels and even bigger Inverter.....but first try it out I would say.

MichelRabozee commented 1 year ago

Maybe one thing for your code: In order to not update the "batteryUsageID" in case the "getDevRealKPI" api fails, the line:

curl "$myDomoticzURL/json.htm?type=command&param=udevice&idx=$batteryUsageID&nvalue=0&svalue=$myCurrentDischargeCapWh;$USAGE2;$myCurrentChargeCapWh;$RETURN2;$myCurrentDischarge;$myCurrentCharge"

should only get executed if the api call is successful; same thing for the * 1000 of the "cap" values. Something like:

if [ -z $myCurrentChargeDischarge ]
then
  myCurrentChargeDischarge="-N/A-"
  myCurrentChargeCapWh="-N/A-"
  myCurrentDischargeCapWh="-N/A-"
else
  # multiply by 1000 => W(h)
  myCurrentChargeCapWh=$(echo "scale=0; ${myCurrentChargeCap} * 1000 / 1" | bc | sed 's/^./0./')
  myCurrentDischargeCapWh=$(echo "scale=0; ${myCurrentDischargeCap} * 1000 / 1" | bc | sed 's/^./0./')

  if [ $myCurrentChargeDischarge -gt 0 ]
  then
    myCurrentCharge=$myCurrentChargeDischarge
    Echo "CurrentCharge (W): "$myCurrentCharge
  else
    myCurrentDischarge=$myCurrentChargeDischarge
    Echo "CurrentDischarge (W): "$myCurrentDischarge
  fi
  curl "$myDomoticzURL/json.htm?type=command&param=udevice&idx=$batteryUsageID&nvalue=0&svalue=$myCurrentDischargeCapWh;$USAGE2;$myCurrentChargeCapWh;$RETURN2;$myCurrentDischarge;$myCurrentCharge"
fi
MichelRabozee commented 1 year ago

The 5kW battery will charge with max 2,5 kW, your 10 kW with max 5kW

Do you mean that only half of the battery will be used ? (assuming all the units in your sentence are kWh and not kW). Or I misunderstood something ?

RikBast commented 1 year ago

I mean 5 kW battery is charged with 2,5 kWh max, so full in 2 hours when charging with 2,5 kWh

RikBast commented 1 year ago

I now get 'Invalid' in the P1 sensor in Domoticz with feeding the negative value of the battery discharge:

$myCurrentDischarge

Schermafbeelding 2022-10-02 om 19 19 00

I tried multiplying * -1 to make the value positive, but still no luck

MichelRabozee commented 1 year ago

Yes, I mean 5 kW battery is charged with 2,5 kWh max

Thus, if during 2 hours, 2,5 kWh are produced continuously, the 5 kWh will be fully charged, no ?

I now get 'Invalid' in the P1 sensor in Domoticz with feeding the negative value of the battery discharge:

$myCurrentDischarge

Schermafbeelding 2022-10-02 om 19 19 00

I tried multiplying * -1 to make the value positive, but still no luck

try:

    if [ $myCurrentChargeDischarge -gt 0 ]
    then
      myCurrentCharge=$myCurrentChargeDischarge
      Echo "Current Charge (W): "$myCurrentCharge
    else
      myCurrentDischarge=$(echo "${myCurrentChargeDischarge} * -1" | bc)
      Echo "Current Discharge (W): "$myCurrentDischarge
    fi
MichelRabozee commented 1 year ago

I think I saw a potential issue in the lines

    # multiply by 1000 => W(h)
    myCurrentChargeCapWh=$(echo "scale=0; ${myCurrentChargeCap} * 1000 / 1" | bc | sed 's/^./0./')
    myCurrentDischargeCapWh=$(echo "scale=0; ${myCurrentDischargeCap} * 1000 / 1" | bc | sed 's/^./0./')

They are missing a '\' in the 's/^\. sequence. They should be:

    # multiply by 1000 => W(h)
    myCurrentChargeCapWh=$(echo "scale=0; ${myCurrentChargeCap} * 1000 / 1" | bc | sed 's/^\./0./')
    myCurrentDischargeCapWh=$(echo "scale=0; ${myCurrentDischargeCap} * 1000 / 1" | bc | sed 's/^\./0./')
RikBast commented 1 year ago

Ok, I changed all the code as suggested as per messages above. Discharge is now positive value, but still can't feed it to the sensor :-(

Output:

myTokenAge: 256 seconds Existing token: x-c51c85im48uo0brzepo41ejz3whgukinrsphpi86tc2nqnrwnwc45c6lc6qk6pinerfzqp3zkbpdnw5gnsdi46um9dhhjwermmdfs79jimlehe7sftrz6pmr4adjo42p Header Data: {"stationCodes": "NE=35314940"} Timed Header Data: {"stationCodes": "NE=35314940","collectTime": "1664733137625"} Battery Device Data: {"devIds": "1000000035314944","devTypeId": "39"}

Existing token: x-c51c85im48uo0brzepo41ejz3whgukinrsphpi86tc2nqnrwnwc45c6lc6qk6pinerfzqp3zkbpdnw5gnsdi46um9dhhjwermmdfs79jimlehe7sftrz6pmr4adjo42p StationCode: NE=35314940 BatteryDeviceID: 1000000035314944 Current Battery Status(%): 56 Charge/Discharge Power (W): -406 Charged energy (kWh): 3.06 Discharged energy (kWh): 3.1 { "status" : "OK", "title" : "Update Device" } CurrentDischarge (W): 406 { "status" : "OK", "title" : "Update Device" }

MichelRabozee commented 1 year ago

hmmm... difficult to detect what goes wrong (and the status is "OK" for the "Update", thus that positive info seems irrelevant :'()

Maybe another value is bothering the update ? can you output all 4 values: $myCurrentDischargeCapWh;;$myCurrentChargeCapWh;;$myCurrentDischarge;$myCurrentCharge" ?

RikBast commented 1 year ago

Sun 2 Oct 20:28:40 CEST 2022 DischargeCap (Wh): 3320 Wh, ChargeCap (Wh): 3060 Wh, Current Discharge (W): 298 W, Current Charge (W): W

Current Charge value is empty, maybe we should make it zero when Discharge of battery is active and also the way around

MichelRabozee commented 1 year ago

Yes, I think you are right, but I wonder why it is an issue while during the charging, the Discharge value was empty and that was not an issue; maybe once a value is filled in, it must always be ?

if [ $myCurrentChargeDischarge -gt 0 ]
    then
      myCurrentCharge=$myCurrentChargeDischarge
      myCurrentDischarge=0
      Echo "Current Charge (W): "$myCurrentCharge
    else
      myCurrentDischarge=$(echo "${myCurrentChargeDischarge} * -1" | bc)
      myCurrentCharge=0
      Echo "Current Discharge (W): "$myCurrentDischarge
    fi