Lua-script to upload S0PCM-information to PVOutput

[Toulon7559]

Domoticz has interfacehandling for the S0 Pulse Counter Module (=S0PCM).
For the upload of values to PVOutput no 'internal' function is available.
After some experimenting and a 24hr-test, please find below a lua-script performing such upload-function.

Some characteristics:
- The shown code is for a 'general' script, with an activation of upload of values from only S0PCM Counter1
- Values for Voltage and Current usually are not available in configurations applying S0-interfaces, therefore processing & upload not present in this script
- A complete picture at PVO-side should have temperature, and therefore also a function for such upload has been included
- At the start of each segment some explaining comments have been included
- For reference during debugging, at the start of several segments the applicable line-number has been inserted [pay attention when changing the script!].
- As indicated in the listing, you have to adapt/tune the settings for your application/configuration, to make it run at your Domoticz.
- For control of rate of upload, the script has a waiting-loop with a interval you can set [in the example-script set to 5 minutes]
- The data to be uploaded is extracted/compiled from the time-values and from the svalues produced by Domoticz.

This is not a perfect script, and some aspects have been identified, which need attention and/or improvement:
- Be aware that PVOutput also has an internal interval-setting (with default 10 minutes), which sometimes causes surprising 'combination-effects' at PVO-side
- If feeding PVOutput with 2 or more async uploadstreams you can expect some effects due to conflict/interference [= missing info, empty fields, unexpected override, etc.]
- The waiting loop and the subsequent if-then's have an 'internal' effect that Domoticz checks every minute, but if the check is not matching the interval-time set in the lua-script, then in the log you will see a 'nil value' error and no upload.
- Addition of 2015-05-19: the script in line 30 calls for UTC-time, but (as detected later) PVOutput needs 'Local time'.
See therefore in this thread my message of 2015-05-17 for a related correction of the script.

If you see room/solutions for improvement, please contribute!
If questions, please ask.
Good luck with application!
Interested to hear your experiences.

Code: Select all

-- PVOutput S0PCM upload script
-- (C)2013 GizMoCuz for WU-Upload-script, adapted by Toulon7559 for periodic upload of S0PCM-info to PVOutput

-- The idea is to apply a dedicated lua-script for each S0PCM-Counter, separate for the application for consumption or for generation.
-- In that way for each type of data you can directly upload the data to the related PVO-account, not bothered by synchronisation.
-- This example script has an active upload for readout of consumption by Counter1 = S0PCM1
-- Combination of counter-outputs for one upload-stream to be tested in a next release of this basic script.

-- Line9= Values
-- For 'names' take the Domoticz device-names and remove -- before the line below as required for activation of the selected counter
Counter1='S0PCM1'
-- Counter2='S0PCM2'
-- Counter3='S0PCM3'
-- Counter4='S0PCM4'
-- Counter5='S0PCM5'
OutsideTemp='TFA_Temp_RV'

-- Line18= PVOutput Settings: adapt as required for your configuration & application
-- baseurl is the header for the upload-message
baseurl="http://pvoutput.org/service/r2/addstatus.jsp?"
SID="PVO_System_ID"
-- PVO System ID of your PV-System
API="PVO_API_key"
-- PVO_API_key must be the full API-string, NOT a ReadOnlyKey
Cumflag=1
-- Must be 1 for upload of lifetime cumulative energy value; set to 0 for today's cumulative energy value
Interval=5
-- Upload interval in minutes

-- Line30= Get date & time
utc_dtime = os.date("!%m-%d-%y %H:%M:%S",os.time())
month = string.sub(utc_dtime, 1, 2)
day = string.sub(utc_dtime, 4, 5)
year = "20" .. string.sub(utc_dtime, 7, 8)
hour = string.sub(utc_dtime, 10, 11)
minutes = string.sub(utc_dtime, 13, 14)
seconds = string.sub(utc_dtime, 16, 17)

-- Line39= Compile auxiliary strings for the upload-message
timestring = hour .. "%3A" .. minutes 
datestring = year .. "" .. month .. "" .. day

-- Line43= Current date from os as date.year, date.month, date.day, date.hour, date.min, date.sec
-- Check time in minutes against Interval to start the script
-- This first assembly for PVO_URL is the extended header for the upload-message
date = os.date("*t")
if (date.min % Interval == 0) then
PVO_URL= baseurl .. "sid=" .. SID .. "&key=" .. API .. "&d=" .. datestring .. "&t=" .. timestring
end

-- Line51= Data Extraction from svalues for Counter1 and for OutsideTemp
sActlPwr, sLifeEnergy = otherdevices_svalues[Counter1]:match("([^;]+);([^;]+)")
sActlPwr = tonumber(sActlPwr);
sLifeEnergy = tonumber(sLifeEnergy);
-- print (sActlPwr)
-- print (sLifeEnergy)
sTemp = otherdevices_svalues[OutsideTemp]:match("([^;]+)")
sTemp = tonumber(sTemp);
-- print(sTemp)

-- Line61= Select & activate from the following 2 examples as required to upload of an active input
-- This is the assembly of the complete message body for solo-upload of consumption values v3 and v4 based on consumption data from Counter1
-- if Counter1 ~= '' then
--   PVO_URL= PVO_URL .. "&v3=" .. sLifeEnergy .. "&v4=" .. sActlPwr .. "&c1=" .. Cumflag
-- end
-- This is the assembly of the complete message body for solo-upload of generation values v1 and v2 based on generation data from Counter2
-- if Counter2 ~= '' then
--   PVO_URL= PVO_URL .. "&v1=" .. sLifeEnergy .. "&v2=" .. sActlPwr .. "&c1=" .. Cumflag
-- end
 
-- Line71= Assembly of active message body, including insertion of v5 for temperature
if Counter1 ~= '' then
   PVO_URL= PVO_URL .. "&v3=" .. sLifeEnergy .. "&v4=" .. sActlPwr .. "&v5=" .. sTemp .. "&c1=" .. Cumflag
end

print (PVO_URL)

commandArray = {}

-- Remove -- before the line below to actually upload
-- commandArray['OpenURL']=PVO_URL

return commandArray

[Toulon7559]

The lua-script in the previous message in this thread at the time of transmission just picks the most actual svalues for Energy and for Power.
Direct copy is correct for Energy, because it accumulates.
Power (a fluctuating value expressed in W) has to be derived by Domoticz from the subsequent S0-countervalues (expressed in Wh per 10s), by a formula which principally extrapolates to the equivalent 'hour'-Wh-value and then reduces backwards to the interval-time. Due to this formula in the initial issue of interface-software the values shown by Domoticz are a multiple of 72W (or at least a multiple of 36W).
Probably a more realistic, less random & stepwise W-value can be obtained if the presented values are filtered: then not only actual peaks & dips are shown, but more the tendency.
Due to the long processing intervals (of 1 minute or more) a lua script is not the best position for a filter, but I do not have access to the software which makes the svalues from the S0PCM-readouts.
Such tendency-filter could be as simple as:
PowerOut= 0.1*ActualPower + 0.9*PowerOld
PowerOld=PowerOut
Characteristic of this filter is that (if the ActualPower jumps from Value1 to Value2) in approx. 10 cycles the value for PowerOut adaptively wanders over the gap between Value1 and Value2.
With the following definitions:
ActualPower = Power (expressed in W) as calculated by Domoticz from the Wh-data from S0PCM
PowerOut = Power after filtering
PowerOld = PowerOut as calculated by the filter in the previous cycle.

Lacking good knowledge for lua-scripting I have the following questions:
1. At start of the lua-script the intial value for PowerOld has to set for start of the filter.
How to realise that in a lua-script 'out-of-reach' of the program-loop?
2. How to realise that the first line of the filter in the next cycle can pick-up the value of PowerOld (which is generated by the second line of the filter)?
3. And with the above aspects in mind, what would be a reliable insertion of the filter in the lua-script in the earlier message in this thread?
4. Application of svalues proves a reliable way to get the data, but it is not fast (once per minute).
Somebody an idea where I can pickup the S0PCM-readouts at the original pace of 10s?

[Toulon7559]

Were are the lua-script-wizards in this Forum, which can answer any or all of my 4 questions in the previous message?
Or has somebody a solution other than a lua-script to get the same or better result?

[roblom]

i'm not a Lua expert but did you check the wiki for some examples, because the thing you want is already invented, so why reinvent it?

[Toulon7559]

@roblom

As far as I know my lua-script is presently the only one which uploads S0PCM-values to PVOutput.
Checking the wiki has been done, and no examples have been found which simply answer my 4 questions.
That is the reason for my latest question-message: I'm stuck and need some hints for guidance .....
Therefore if somebody could pinpoint one or more examples which would be more or less applicable to my 'problem', I would be grateful.
Or even better, a suggestion how to upgrade the lua-script at the start of this thread!

[simonrg]

There are number of scripts which upload different information on the wiki and do some data processing on the way, do these not give you any hints?

Personally, I am struggling to help, while feeling comfortable with Lua, I know nothing about PVOutput and don't even know what an S0PCM is. If I were to help you, I would need to learn about PVOutput and S0PCM. If there is some Lua code which isn't working, then I find I can normally understand enough about what the code is doing, to at least be able to describe what the code is actually doing (which is isn't always what the writer thought it was doing) and suggest a different way of doing it.

I guess there aren't many people on the forum who are comforable with Lua and PVOutput and S0PCM.

Could you elaborate your questions further or make them less specific i.e. what do you really want help about is it Lua or PVOutput plus S0PCM plus Lua?

So my guesses at your 4 questions, but due to lack of relevant knowledge I may have missed what you are really asking:
1. At start of the lua-script the intial value for PowerOld has to set for start of the filter. How to realise that in a lua-script 'out-of-reach' of the program-loop?
This sound like you just want to use uservariables which allow a value to be transmitted between different times the script is called - have a look on the wiki.
2. How to realise that the first line of the filter in the next cycle can pick-up the value of PowerOld (which is generated by the second line of the filter)?
Same as above uservariables sound like the way forward.
3. And with the above aspects in mind, what would be a reliable insertion of the filter in the lua-script in the earlier message in this thread?
I don't understand enough about what you are trying to do to answer this. Domoticz is able to produce trendlines from logged data, I seem to remember from previous forum posts.
4. Application of svalues proves a reliable way to get the data, but it is not fast (once per minute). Somebody an idea where I can pickup the S0PCM-readouts at the original pace of 10s?
This is not a Lua question but a specific S0PCM question, so I guess you need to modify the C code which is the device driver within Domoticz. Sort of thing if you hack the code, you may find an obvious piece of code which averages over 60seconds.

Sorry not to be more help, but hopefully some hints at least on new questions, if not your problems.

[Toulon7559]

'Uservariables' certainly may be the answer to questions 1 till 3:
have never used before in a lua-script (therefore not imagined their use), but may be worth a try .....

[Toulon7559]

Still lacking experience, the application of uservariables is a challenge .......
Therefore a question to the people with more practise.

Definitions for this question:
- the incoming value measured in the script is called 'actual value' (e.g. sActlPwr in the lua-script earlier in this thread)
- the limit-setting is called 'limit'
- the last correct 'actual value' lower than the limit is 'prevvalue'
- 'outputdata' is the resulting info to be uploaded.

In my setup the outputs from S0PCM occasionally show excessive 'spikes' related to Power-readout.
Reasons are unclear, because there is uncorrelated variation between the counters and over time.
The Power-data coming from the K8055-board parallel connected to the same S0-interfaces does not show those spikes.
The strange thing is that the Energy-reading of both boards is continuously almost identical: that implies that the 'spikes' for S0PCM are really short = with very little energy-contents.
Spurious interference on the S0PCM-inputcabling may be a source, but from the splitter the cabling to the S0PCM is not significantly longer or different than to the K8055.
The difference in behaviour of the 2 types of boards is reason to suspect that the debouncing function in in the S0PCM and the Power-calculation is 'weaker' than in K8055, or at least different.

Not able to change the firmware in the S0PCM or Domoticz, I can only try to find a remedy in the lua-script making the upload to PVOutput.
In a first upgrade-version, to suppress the S0PCM-'spikes' moving from 'actual value' to 'outputdata', I inserted lines in the lua-script with the following local function (in a solution without use of uservariables):
- if 'actual value' > 'limit', then 'outputdata' = 'limit' else 'outputdata'= 'actual value'
In this way for a 'spike' the 'outputdata' is simply clamped to a 'not-to-exceed'-value, e.g. for electricity the power consumption always less than the max. fuse rating of 16A, or power generation always less than the nominal max. output of the related inverter.
It works (as shown in the attached picture-file, with clamping at 450W, for an unusual frequent occurence of spikes).

Because this is a rather blunt method, for further refinement I look for a function which (instead of 'limit' as replacement-value) looks back for the last correct value of 'actual value':
such earlier correct value (= 'prevvalue') is probably nearer to the real actual value, and therefore better as replacement for the 'wrong' value.
Following approach (applying uservariables) seems simple & robust:
0. definition in Setup of an auxiliary uservariable 'prevvalue' as integer with a default-value
1. at the start of the script definition and setting of 'limit'-value
2. at start of script calling of uservariable 'prevvalue'
3. in the script comparison of the 'actual value' against 'limit' by following scriptlines:
if 'actual value' > 'limit'
then
'outputdata' = 'prevvalue'
else
'outputdata' = 'actual value'
'prevvalue' = 'actual value'
end
4. at end of the script save 'prevvalue' as global variable for next cycle of the script

Question: Any remarks on this concept? Better ideas to suppress the 'spikes'? Example scripts for similar function?

Addition on 23d of May 2015
In the second upgrade-version I meanwhile implemented the above concept, and the results since this morning 08:30 show that it works!
Now expanding the script to cover all 5 counters.
An update of the general lua-sript will appear in this thread as soon as test results (for above aspects) are satisfactory!
In advance you can have a look at progress at http://www.pvoutput.org/intraday.jsp?id=10324&sid=8645
The content of that URL is provided by the latest version of the lua-script, tuned for a combined read-out of 3 S0PCM-counters, covering 1 Consumer-group and 2 PV-inverters.

[Toulon7559]

Since running of the lua-script earlier published in this thread, I wondered why the info uploaded by the lua-script was lagging by 2 hours.
This morning the penny dropped: in the script I apply UTC, which at this moment is 2 hours 'behind' the Summer-CET
How should I change the below lines of script to get the correct 'local time' for Amsterdam?
Obviously I prefer a solution which automatically takes care of wintertime and summertime.

utc_dtime = os.date("!%m-%d-%y %H:%M:%S",os.time())
month = string.sub(utc_dtime, 1, 2)
day = string.sub(utc_dtime, 4, 5)
year = "20" .. string.sub(utc_dtime, 7, 8)
hour = string.sub(utc_dtime, 10, 11)
minutes = string.sub(utc_dtime, 13, 14)
seconds = string.sub(utc_dtime, 16, 17)

Addition 20150518/ expanded 20150519
Sometimes (unnoticed) a solution is right in front of you.

In the same lua-script the next (borrowed) section of lines reads:
-- Line43= Current date from os as date.year, date.month, date.day, date.hour, date.min, date.sec
-- Check time in minutes against Interval to start the script
date = os.date("*t")
if (date.min % Interval == 0) then

Derived from those lines, I made the following adaptation to the published general lua-script.
The lines below replace the section for extraction of date&time starting at Line30 in the original, general script:
-- Line30= Get Current date & time from os as date.year, date.month, date.day, date.hour, date.min, date.sec
date = os.date("*t")
year = date.year
month = date.month
if month < 10 then month = "0" .. month
end
day = date.day
if day < 10 then day = "0" .. day
end
hour = date.hour
if hour < 10 then hour = "0" .. hour
end
minutes = date.min
if minutes < 10 then minutes = "0" .. minutes
end
seconds = date.sec
if seconds < 10 then seconds = "0" .. seconds
end

The "if-then"-lines are required because in the upload to PVOutput for month, hour and minutes you always have to insert the values as 2 digits.
Obviously the subsequent line-numbers in the lua-script have to be realigned.
Seems to work for correct actual local time for PVOutput-upload.

[roblom]

If you are running on a raspberry pi, try the raspi-config and change the location values.

[Toulon7559]

@roblom

The reason of my headscratching related to the 2hour-lag was that in raspi-config the location always was/is Amsterdam.
But as indicated, I now found a working solution to get correct local time.
I hindsight, I fell in a 'trap':
- I borrowed the UTC-scriptlines from a lua-script for uploads to Wunderground (which requires time as UTC)
- uploads to PVOutput require time expressed in 'local time'
With this latest script-adaptation now PVOutput shows my uploaded info at the correct time.

Next step is further development of the 'spike'-suppression on the S0PCM-powerdata ......

[Toulon7559]

The promised update of the general lua-script.
The listing looks long, but I have aimed for 'KISS' instead of 'cleverness'.
Example: if a section works for 1 counter, then the equivalent lines for the other 4 counters are simply repeated with only the minimal numbering-adaptations.
And programming is kept as simple as 'if-then-else'.
Comment-lines have been inserted for brief explanation.
Line-numbers at the start of each section help for error-trapping.
The print-commands have the same background: with this output you can check in Domoticz' log whether and what is happening to the values.
The eventcounters inserted in the sections for Counter4 and Counter5 serve to check how many times the set limits have been exceeded.

This is an example/general script which you have to copy and then have to tune to your own configuration & application!!!!!!
The basic functional flow of this version of the script is:
- setting of values
- read-out of date&time
- calling of uservariables as global values
- readout of counter 1 (power consumption), counters 4 and 5 (power generation) and temperature, including a basic 'spike'-suppression on the power-values
The power and energy information from counters 1 and 4 is directly applied for values v1 till v4 in the upload-line, temperature becomes v5, while the extended values v7 till v10 combine a selection of values from counters 4 and 5
- compilation of the upload-line, using values v1~v4, v5, v7~v10 as mentioned above
- saving of the global values [for application in the next script-cycle]
- transmission of the upload-line
Obviously for your account at PVOutput the read-out of v7 till v10 can only be set & applied if (after Donation) you have access to PVO's Extended Values.

When tuning the script, please pay attention to
- required presetting of the applied uservariables (outside the script!) in Domoticz' Setup - Uservariables, as called in Line 54 etc.
- the setting&activation of the your applicable Counter-'names', starting in Line 8
- the insertion of your applicable PVO-Identification-info, starting in Line 17
- (de)activation of the sections per counter as required for your configuration, in Lines 74 till 133.
- Line133 is preparation for the extended value v10 in the upload-line; if you do not need it, deactivate or delete this line.
- Finally Line 151 should be your own ultimate choice of compilation for the upload to PVOutput. The section starting at Line139 shows with 2 examples how basic such line could be for consumption upload or for generation upload. The shown layout for Line 151 includes upload for a set of extended values v7 till v10: if not required, then delete the related text from the line.
- After your 'local' testruns have been successful, do not forget to activate Line 168 to start actual upload!
- And if your version of the script is running without errors, you may take out the checking-aids and the commentlines as mentioned above, to make the script leaner/shorter. If you want to keep the line-numbers as reference, don't forget to realign them!

Good luck with tuning and application!
If some aspect is unclear, use this forum to ask or send a PM.
Always interested in your experiences.

Code: Select all

-- PVOutput S0PCM upload script
-- (C)2013 GizMoCuz for WU-Upload-script, adapted (c)2015 Toulon7559 for periodic upload of S0PCM-info to PVOutput

-- The approach is to apply a general lua-script to collect all information, and then 'tune' the input-calls and the output-strings for a combined upload of data to one PVO-destination address from all S0PCM-Counters.
-- 'Tuning' is by deactivating lines of code by putting -- in front of them if not required. This version of the script assumes active counter 1 for electricity consumption and active counters 4 and 5 for PV-production
-- In that way a common structure of the software and minimal transmissions to each destination address.

-- Line8= Values
-- For 'names' take YOUR Domoticz device-names and remove -- before the line below as required for activation of the selected counter
Counter1='S0PCM_Teller1'
-- Counter2='S0PCM_Teller2'
-- Counter3='S0PCM_Teller3'
Counter4='S0PCM_Teller4'
Counter5='S0PCM_Teller5'
OutsideTemp='Meteo'

-- Line17= PVOutput Settings: adapt as required for your configuration & application
-- baseurl is the header for the upload-message
baseurl="http://pvoutput.org/service/r2/addstatus.jsp?"
SID="Your_PVO_SID_number"
-- PVO System ID of your PV-System
API="Your_PVO_API_key"
-- PVO_API_key must be the full API-string, NOT a ReadOnlyKey
Cumflag=1
-- Must be 1 for upload of v1 = lifetime cumulative energy value; set to 0 for v1 = today's cumulative energy value
Interval=5
-- Upload interval in minutes
Limit1=3200  -- For 16A consumption at 230V
Limit2=3200  -- For 16A at 230V
Limit3=1500  -- For PV-output of 1500W
Limit4=450   -- For PV-output of 0450W
Limit5=2700  -- For PV-output of 2700W
-- Limits for outputdata

-- Line35= Get Current date & time from os as date.year, date.month, date.day, date.hour, date.min, date.sec
date = os.date("*t")
year = date.year
month = date.month
if month < 10 then month = "0" .. month
end
day = date.day
if day < 10 then day = "0" .. day
end
hour = date.hour
if hour < 10 then hour = "0" .. hour
end
minutes = date.min
if minutes < 10 then minutes = "0" .. minutes
end
seconds = date.sec
if seconds < 10 then seconds = "0" .. seconds
end

-- Line54= Get the global variables, which you have predefined at Domoticz Setup - Uservariables
eventcounter1 = tonumber(uservariables['eventcounter1'])
eventcounter2 = tonumber(uservariables['eventcounter2'])
prevvalue1 = tonumber(uservariables['prevvalue1'])
prevvalue2 = tonumber(uservariables['prevvalue2'])
prevvalue3 = tonumber(uservariables['prevvalue3'])
prevvalue4 = tonumber(uservariables['prevvalue4'])
prevvalue5 = tonumber(uservariables['prevvalue5'])

-- Line63= Compile auxiliary strings for the upload-message
timestring = hour .. "%3A" .. minutes 
datestring = year .. "" .. month .. "" .. day

-- Line67= Check Current time in minutes against Interval to start the script
-- This first assembly for PVO_URL is the header for the upload-message
date = os.date("*t")
if (date.min % Interval == 0) then
PVO_URL= baseurl .. "sid=" .. SID .. "&key=" .. API .. "&d=" .. datestring .. "&t=" .. timestring
end

-- Line74= Data Extraction from svalues for Counter1
sActlPwr1, sLifeEnergy1 = otherdevices_svalues[Counter1]:match("([^;]+);([^;]+)")
sActlPwr1 = tonumber(sActlPwr1);
sLifeEnergy1 = tonumber(sLifeEnergy1);
if sActlPwr1 >= Limit1 then
  sActlPwr1 = prevvalue1
end
prevvalue1 = sActlPwr1
print ('S1Power  = '.. sActlPwr1)
print ('S1Energy = '.. sLifeEnergy1)

-- Line85= Data Extraction from svalues for Counter2
-- sActlPwr2, sLifeEnergy2 = otherdevices_svalues[Counter2]:match("([^;]+);([^;]+)")
-- sActlPwr2 = tonumber(sActlPwr2);
-- sLifeEnergy2 = tonumber(sLifeEnergy2);
-- if sActlPwr2 >= Limit2 then
--   sActlPwr2 = prevvalue2
-- end
-- prevvalue2 = sActlPwr2
-- print ('S2Power  = '.. sActlPwr2)
-- print ('S2Energy = '.. sLifeEnergy2)

-- Line96= Data Extraction from svalues for Counter3
-- sActlPwr3, sLifeEnergy3 = otherdevices_svalues[Counter3]:match("([^;]+);([^;]+)")
-- sActlPwr3 = tonumber(sActlPwr3);
-- sLifeEnergy3 = tonumber(sLifeEnergy3);
-- if sActlPwr3 >= Limit3 then
--   sActlPwr3 = prevvalue3
-- end
-- prevvalue3 = sActlPwr3
-- print ('S3Power  = '.. sActlPwr3)
-- print ('S3Energy = '.. sLifeEnergy3)

-- Line107= Data Extraction from svalues for Counter4
sActlPwr4, sLifeEnergy4 = otherdevices_svalues[Counter4]:match("([^;]+);([^;]+)")
sActlPwr4 = tonumber(sActlPwr4);
sLifeEnergy4 = tonumber(sLifeEnergy4);
if sActlPwr4 >= Limit4 then
  sActlPwr4 = prevvalue4
  eventcounter1 = eventcounter1 + 1
end
prevvalue4 = sActlPwr4
print ('S4Power  = '.. sActlPwr4)
print ('S4Energy = '.. sLifeEnergy4)
print ('S4Counter  = '.. eventcounter1)

-- Line120= Data Extraction from svalues for Counter5
sActlPwr5, sLifeEnergy5 = otherdevices_svalues[Counter5]:match("([^;]+);([^;]+)")
sActlPwr5 = tonumber(sActlPwr5);
sLifeEnergy5 = tonumber(sLifeEnergy5);
if sActlPwr5 >= Limit5 then
  sActlPwr5 = prevvalue5
  eventcounter2 = eventcounter2 + 1
end
prevvalue5 = sActlPwr5
print ('S5Power  = '.. sActlPwr5)
print ('S5Energy = '.. sLifeEnergy5)
print ('S5Counter  = '.. eventcounter2)
s45Power = sActlPwr4 + sActlPwr5

-- Line134= Data Extraction from svalues for OutsideTemp
sTemp = otherdevices_svalues[OutsideTemp]:match("([^;]+)")
sTemp = tonumber(sTemp);
print ('Temp   = '.. sTemp)

-- Line139= Select & copy from the following 2 examples as required to upload the data of an active input
-- This is the concept assembly of the complete message body for solo-upload of consumption values v3 and v4 based on consumption data from Counter1
-- if Counter1 ~= '' then
--   PVO_URL= PVO_URL .. "&v3=" .. sLifeEnergy1 .. "&v4=" .. sActlPwr1 .. "&c1=" .. Cumflag
-- end
-- This is the concept assembly of the complete message body for solo-upload of generation values v1 and v2 based on generation data from Counter4, combined with upload of temperature v5
-- if Counter4 ~= '' then
--   PVO_URL= PVO_URL .. "&v1=" .. sLifeEnergy4 .. "&v2=" .. sActlPwr4 .. "&v5=" .. sTemp .. "&c1=" .. Cumflag
-- end
 
-- Line149= Assembly of the active message body for combined upload [triggered by counter1] of v1 [life-energy], v2 [actualpower], v3 [life-energy], v4 [actualpower], v5 [temperature] and c1=1 [=lifetime energy], and experimental/extended values V7 till v10 (to fil the PVO-picture for Extended Values]
if Counter1 ~= '' then
   PVO_URL= PVO_URL .. "&v1=" .. sLifeEnergy4 .. "&v2=" .. sActlPwr4 .. "&v3=" .. sLifeEnergy1 .. "&v4=" .. sActlPwr1 .. "&v5=" .. sTemp .. "&v7=" .. sLifeEnergy4 ..  "&v8=" .. sActlPwr4 .. "&v9=" .. sActlPwr5 .. "&v10=" .. s45Power .."&c1=" .. Cumflag
end

print (PVO_URL)

commandArray = {}

-- Line158= Save the global values
commandArray['Variable:eventcounter1'] = tostring(eventcounter1)
commandArray['Variable:eventcounter2'] = tostring(eventcounter2)
commandArray['Variable:prevvalue1'] = tostring(prevvalue1)
commandArray['Variable:prevvalue2'] = tostring(prevvalue2)
commandArray['Variable:prevvalue3'] = tostring(prevvalue3)
commandArray['Variable:prevvalue4'] = tostring(prevvalue4)
commandArray['Variable:prevvalue5'] = tostring(prevvalue5)

-- Line167= Upload of PVO_URL; remove -- before the line below to actually upload
--commandArray['OpenURL']=PVO_URL

return commandArray

[Toulon7559]

By further experience ;-( I detected that the cabling from an S0-interface to the S0PCM should not be too long.
Not without reason the datasheet of most kWh-modules shows a value for max. cable-length in combination with a certain voltage&current.
The 5V USB-power supply applied by the S0PCM (and all similar USB-devices like the Velleman K8055-board) is at the lower edge, and therefore already in design the cabling should be as short as possible and with good shielding.
The longer the cabling and the less the shielding, the more susceptible to induced spurious signals. Spurious interference signals show themselves in the S0PCM/Domoticz-info as disturbances in the Wh-reporting over last interval and over Lifetime. The erratic Wh-report over last interval is a short, temporary distubance [=Spike], but the disturbance to Lifetime-Energy shows as (significant) Energy-increase [=Jump], resulting in Domoticz in unlikely high Energy values for Lifetime and for Day-production.
In the latest version of my lua-script a kind of Spike-suppression has been included, which proves effective for the Power-readout serving the upload to PVOutput.
'Correction' of Jumps is more complicated, and (in my experience) requires that you virtually create a second, 'clean' Energy-infoset and keep that uptodate online: such second Energy-infoset provides reasonably accurate info for upload to PVOutpur, but the relation with the Energy-info you read on the dashboard of Domoticz will be nil.
Therefore not recommended to solve the Energy-aspect of the problem through software, but instead go to the 'basis', and plan/try to prevent/eliminate any interference on the cabling.

;-( Unfortunately in an existing building you are usually not free to choose the position of equipment and as consequence the building dictates the cable-routing between equipments ........
An alternative approach is to improve the characteristics of the S0-interface by insertion of an optocouplerboard: with such optocouplerboard you can apply much higher supply-voltages than the 5V-USB-voltage, resulting in better signal-to-noise ratio, combined with good galvanic separation.

[Derik]

Hello..

Old post.
Only is this script still working???
I try to upload my p1 gas and Electricity to separate sids to pvo...
I understand that i must use mutiple scripts...
short how to???
Please

[Toulon7559]

@Derik,

As simple as you write yourself: upload to separate PVOutput-sids = separate scripts.
Simply because the example script applies only 1 SID, and probably you apply for each script a different combination of S0PCM-channels.
That means that as starter for each upload-script at least in lines 8 till 35 and lines 149 till 155 you have to select & insert what is applicable.

[Derik]

toulon7559
Thanks for the replay..

Sorry, scripts is not my thing...
nly i will try to upload my s0 counters to PVo
and i will try to upload my P1 meter, the gas.
And the P1 Meter use and return counters.
Is this possible with this script?
Or can i better use singel scripts..


I do not understand how i can run this script..
And do i need to remover the -- for the lines that i do not use/need?

Thanks

[ Perhaps a working example script? ]

[Toulon7559]

You can use the script to upload the reading of the S0PCM to PVOutput.
If you want to direct information to different accounts, then you have to make different, separate script-versions.
Reading and upload of P1-values is a different story and as a result a different script.

If you have -- at the start of a line, then that line is considered 'comment' and not executed by the software.
If you delete that -- , then the software assumes that the line is an active instruction and it will try to execute.
Therefore, if you do not need a line, EITHER remove that line, OR de-activate it by putting -- at the start

[Martinvdm]

I have got a S0PCM-5 module. Would really like to have a Python script for seperating the 5 output data's and make variables. Needs to be python.

[Toulon7559]

That in my configuration the S0-interfaces for the S0PCM are 'noisy & spiking' is not standard ( I hope for most other users).

If you have a 'clean configuration', then my script earlier in this thread has a lot of lines and uservariables which are not needed.

Below is the 'short' version without all those superfluous lines.

Code: Select all

-- PVOutput S0PCM upload script
-- (C)2013 GizMoCuz for WU-Upload-script, adapted (c)2015+2019 Toulon7559 for periodic upload of S0PCM-info to PVOutput
-- This version made in 2019 is WITHOUT any filtering for suppression of glitches!!!!!
-- The approach is to apply a general lua-script to collect all information from the S0PCM, and then 'tune' the input-calls and the output-strings for a combined upload of data to one PVO-destination address from all S0PCM-Counters.  The 5 counters for S0PCM have configuration svalue=POWER;ENERGY
-- 'Tuning' is by deactivating lines of code by putting -- in front of them if not required. This version of the script assumes active counter 1 for electricity consumption and active counter 4 for PV-production
-- In that way a common structure of the software and minimal transmissions to each destination address.

-- Line10= Values
-- For 'names' take YOUR Domoticz device-names and remove -- before the line below as required for activation of the selected counter
Counter1='S0PCM_Teller1' -- Consumption Power/Energy-counter
-- Counter2='S0PCM_Teller2'
-- Counter3='S0PCM_Teller3'
Counter4='S0PCM_Teller4' -- PV Production Power/Energy-counter
-- Counter5='S0PCM_Teller5'
OutsideTemp='Meteo'

-- Line19= PVOutput Settings: adapt as required for your configuration & application
-- baseurl is the header for the upload-message
baseurl="http://pvoutput.org/service/r2/addstatus.jsp?"
-- PVO System ID of your PV-System
SID="Your_PVO_SID_number"
-- PVO_API_key must be the full API-string, NOT a ReadOnlyKey
API="Your_PVO_API_key"
-- Cumflag must be 1 for upload of v1 = lifetime cumulative energy value; set to 0 for v1 = today's cumulative energy value
Cumflag=1
-- Upload interval in minutes
Interval=5 

-- Line31= Get Current date & time from os as date.year, date.month, date.day, date.hour, date.min, date.sec
date = os.date("*t")
year = date.year
month = date.month
if month < 10 then month = "0" .. month
end
day = date.day
if day < 10 then day = "0" .. day
end
hour = date.hour
if hour < 10 then hour = "0" .. hour
end
minutes = date.min
if minutes < 10 then minutes = "0" .. minutes
end
seconds = date.sec
if seconds < 10 then seconds = "0" .. seconds
end

-- Line50= Compile auxiliary strings for the upload-message
timestring = hour .. "%3A" .. minutes 
datestring = year .. "" .. month .. "" .. day

-- Line54= Check Current time in minutes against Interval to start the script
-- This first assembly for PVO_URL is the header for the upload-message
date = os.date("*t")
if (date.min % Interval == 0) then
PVO_URL= baseurl .. "sid=" .. SID .. "&key=" .. API .. "&d=" .. datestring .. "&t=" .. timestring
end

-- Line61= Data Extraction from svalues for S0PCM Counter1
sActlPwr1, sLifeEnergy1 = otherdevices_svalues[Counter1]:match("([^;]+);([^;]+)")
sActlPwr1 = tonumber(sActlPwr1);
sLifeEnergy1 = tonumber(sLifeEnergy1);
print ('S1Power  = '.. sActlPwr1)
print ('S1Energy = '.. sLifeEnergy1)

-- Line68= Data Extraction from svalues for S0PCM Counter2
-- sActlPwr2, sLifeEnergy2 = otherdevices_svalues[Counter2]:match("([^;]+);([^;]+)")
-- sActlPwr2 = tonumber(sActlPwr2);
-- sLifeEnergy2 = tonumber(sLifeEnergy2);
-- print ('S2Power  = '.. sActlPwr2)
-- print ('S2Energy = '.. sLifeEnergy2)

-- Line75= Data Extraction from svalues for S0PCM Counter3
-- sActlPwr3, sLifeEnergy3 = otherdevices_svalues[Counter3]:match("([^;]+);([^;]+)")
-- sActlPwr3 = tonumber(sActlPwr3);
-- sLifeEnergy3 = tonumber(sLifeEnergy3);
-- print ('S3Power  = '.. sActlPwr3)
-- print ('S3Energy = '.. sLifeEnergy3)

-- Line82= Data Extraction from svalues for S0PCM Counter4
sActlPwr4, sLifeEnergy4 = otherdevices_svalues[Counter4]:match("([^;]+);([^;]+)")
sActlPwr4 = tonumber(sActlPwr4);
sLifeEnergy4 = tonumber(sLifeEnergy4);
print ('S4Power  = '.. sActlPwr4)
print ('S4Energy = '.. sLifeEnergy4)

-- Line89= Data Extraction from svalues for S0PCM Counter5
-- sActlPwr5, sLifeEnergy5 = otherdevices_svalues[Counter5]:match("([^;]+);([^;]+)")
-- sActlPwr5 = tonumber(sActlPwr5);
-- sLifeEnergy5 = tonumber(sLifeEnergy5);
-- print ('S5Power  = '.. sActlPwr5)
-- print ('S5Energy = '.. sLifeEnergy5)

-- Line96= Data Extraction from svalues for OutsideTemp
sTemp = otherdevices_svalues[OutsideTemp]:match("([^;]+)")
sTemp = tonumber(sTemp);
print ('Temp   = '.. sTemp)

-- Line101= Select & copy from the following 2 examples as required to upload the data of an active input
-- This is the concept assembly of the complete message body for SOLO_UPLOAD of consumption values v3 and v4 based on consumption data from Counter1
-- if Counter1 ~= '' then
--   PVO_URL= PVO_URL .. "&v3=" .. sLifeEnergy1 .. "&v4=" .. sActlPwr1 .. "&c1=" .. Cumflag
-- end
-- This is the concept assembly of the complete message body for SOLO_UPLOAD of PV_generation values v1 and v2 based on generation data from Counter4, combined with upload of temperature v5
-- if Counter4 ~= '' then
--   PVO_URL= PVO_URL .. "&v1=" .. sLifeEnergy4 .. "&v2=" .. sActlPwr4 .. "&v5=" .. sTemp .. "&c1=" .. Cumflag
-- end
 
-- Line112= Assembly of the active message body for COMBINED UPLOAD [triggered by counter1] of v1 [life-energy], v2 [actualpower], v3 [life-energy], v4 [actualpower], v5 [temperature] and c1=1 [=lifetime energy], and experimental/extended values V7 till v9 (to fill the PVO-picture for Extended Values]
if Counter1 ~= '' then
   PVO_URL= PVO_URL .. "&v1=" .. sLifeEnergy4 .. "&v2=" .. sActlPwr4 .. "&v3=" .. sLifeEnergy1 .. "&v4=" .. sActlPwr1 .. "&v5=" .. sTemp .. "&v7=" .. sLifeEnergy4 ..  "&v8=" .. sActlPwr4 .. "&v9=" .. sActlPwr5 .. "&c1=" .. Cumflag
end

print (PVO_URL)

commandArray = {}

-- Line123= Upload of PVO_URL; remove -- before the line below for actual upload
--commandArray['OpenURL']=PVO_URL

return commandArray

In discussion with another member of this forum we made a scriptvariation which besides read-out of 1 S0-interface includes a read-out of a P1-interface, conceptually linking applicable info to the upload towards PVOutput.
If the S0-interface is applied for measuring the PV-production, by means of some calculus both in PVOutput and in Domoticz the net results can be determined for consumption and production both in the house and towards the grid.
The P1-interface provides cumulative (Lifetime) values for energy for USAGE and RETURN, and actual values for power for CONS and PROD.
For compatibility make sure that the S0_Readout (as described in this script) has a lifetime ENERGY value and an actual POWER value.
If you upload the cumulative energy-values towards PVOutput, then PVOutput itself makes comparisons and graphs to show results:
under Extended Data (= v7 till v12) even some extra calculations are possible, which subtract or add values at PVOutput.

To locally get derivative values like net internal consumption however you have to do own calulations in a script.
E.g. generally for actual day-values for energy:
Energy_PV - Production_day = ENERGY_day
Energy_Internal_Consumption_day = (ENERGY_day + USAGE_day - RETURN_day)
But 'devil is in the details', because you first must determine the actual day-values from the cumulative lifetime-values.
A simple mechanism is:
- at 00:00 (= midnight) read the cumulative values and save in user-variables as references
- during the day periodically read & subtract the reference user-variables from the related, actual, cumulative values => actual day-values for energy (in Wh)
My 'long' script in this thread includes similar kind of functions.

Actual power level is simpler:
P1-interface provides CONS and PROD (in W) relative to grid-interface
S0-Readout derived from the successive reported Whs provides POWER (in W) = (S0t2 S0t1)/(t2 - t1)
=> Power_Internal_consumption = POWER + CONS - PROD

Be aware that the P1-interface and the S0-interface may have a different sampling rate:
that might become visible as rather 'jumpy' output of the calulations.

[Derik]

dear....

Looking for a simple lua upload code..zwave counter to a sid in Pvoutput
Perhaps this working?

Can you give me a little help for just upload 1 Device with temp
I try different options in this script..
Only no luck @ all..
Thanks