DIN Energy-meter with S0-interface & RS485-Interface

[Toulon7559]

An energymeter with S0-interface sends a stream of pulses per kWh, to be collected by a computer/processor.
Actual power (W) then has to be derived by calculation, with inherent errors.
In my opinion, you can save that effort and get better quality of data if you have an Energy-meter like DDS238-1ZN, which provides various information at its RS485-interface.
Somebody with experience with such device in combination with Domoticz?

[arjanvdwiel]

That would be great, but i've never seen it being used in domotica before

[Toulon7559]

For such component advertisements from chinese manufacturers are abundant, but application indeed less or nil.
At this moment I see one configuration being offered, consisting of DIN-meter and Logger, incl. webserverservices, with upload-function for PVOutput: http://fp4all.com/index.php?main_page=p ... cts_id=316.

[Toulon7559]

Interfacing a kWh-meter with RS485-interface starts with application of RS485-interface hardware attached to the Domoticz-computer.
For that aspect I found a plug-in board for the Raspberry at http://store.linksprite.com/rs485-gpio- ... erry-pi-2/ for the price of $13,99 plus P&P from USA to Netherlands
Same board available at Conrad for the price of Euro16,99 plus P&P within Netherlands. Other solutions such as at Cooking Hacks use a transition board (for Raspberry, Arduino or Galileo) and on top of that board a common add-on RS485-board (cumulating to a much higher cost)
Subsequently such RS485-interfacing requires application of the Modbus-RTU-protocol for development of the Domoticz-functions related to write&read with the kWh-meter.
https://www.cooking-hacks.com/documenta ... l-galileo/ gives some insight.
Somebody at this forum more familiar with application of the Modbus RTU protocol?

Addition 2nd August 2015:
Linksprite-board added to Raspberry, first as transition-board for BMP180-interface at I2C, upcoming for the RS485-interface and for connection of several DS18B20s temp-sensors.

Addition 16th December 2015:
Not intended by the supplier, but the same Linksprite-shield can also be applied as RS232-interface with DB9-connector. Just put a DB9-connector at the position already indicated on the board. Not at the same time RS485 and RS232, but 'either-or', because only 1 interface-IC present for the 2 parallel-connectors.

[Toulon7559]

The Linksprite-board fitted, the I2C-interface at the GPIO-header succesfully activated for BMP180-readout, and that GPIO-header also applied for the connection of the DS18B20-chain.

After laying of the 2-wire cable for the physical connection by RS485-interface to the DDS238-1ZN meter, the next hurdle is making the software tick for the RS485-interface.
Tuning/checking according to Linksprite's instructions was easy: default Raspi-Config without touching 'Serial' results in all described mods already present!
Now a crash-course to learn sufficient Python-application to get Linksprite's test code running, and then protocol-activation for ModBus-communication with the DDS238-1ZN interface .......

[Toulon7559]

The RS485-interface of the Linksprite-board now also up and running, collecting experience.

From friendly helpers received documentation & information related to another RS485-interface-implementation for the kWh-meter type DDS238-1ZN.
The communication settings and the message structure are rather transparantly described [although the quality of manufacturer's text requires 'some' rereading & guessing ....].
Each message applying the modbus-protocol has a header, a number of data-bytes and ends with a CRC applying 2 bytes.
The periodic command messages have a fixed layout, and therefore also a fixed CRC. Fortunately, the documentation showed the CRCs for the most essential command messages [for Lifetime Energy, Voltage, Current and Power]. For the other command messages an internet-online calcutor provided the CRC-values.
Using that information I tweaked the Python-test-script from Linksprite for a first, basic, straightforward implementation:
- Apply the serial or pyserial module of Python [additional modules pymodbus and minimalmodbus also exist for Python, but their application is not (yet) clear to me]
- For the command messages mentioned above, all contents are known, and I have made a series of messages with fixed strings to be transmitted.
- Handshaking is the rule, therefore after transmission of each command/request message wait for response.
The response consists of a message with following layout (for default configuration of DDS238-1ZN):
- Slave-address 1 byte, fixed 01(hex)
- Function-code 1 byte, fixed 03(hex)
- Payload-size 1 byte, variable 02(hex) or 04(hex)
- Payload of 2 or 4 Data-bytes, with hex-contents
- CRC, 2 bytes, with hex-contents
The readout-lines in the Python-script are similar to the first one shown below (followed by comparable lines for the other messages covering all other 'user'-registers):
print "Received, DDS238_NetEnergy_Low_part: ", repr(usart.read(10))

Screenshot output Python-script

Knipsel151211test_all2b.JPG (91.47 KiB) Viewed 16468 times

In the screenshot you can see that all request-messages to the occupied Slave-address 01 get a meaningful response, but some responses are distorted & incomplete [because a complete response should be either 9 or 7 bytes].
The bottom Python-script-line calling the communication-settings from Slave-address 02 correctly reports a 'no response', shown as a 'blank'
Manually converting the received strings of hex-numbers I see realistic decimal values.
Obviously the conversion should be automated within the Python-script, and followed by application of the data.
Therefore the next step is extension of the script with timed read-out, upload to Domoticz (and PVOutput), etc.

[Toulon7559]

Experience/ Cabling
Also an RS485-interface is sensitive to interference on the interface-cable: shows as a distorted/corrupted responses from the counterpart.
For the MAX481 applied as driver-IC on the Linksprite-shield the specs tell to use twisted pair cable.
The document 'Modbus for Field Technicians' has more hints how to avoid 'nasty situations'.
Conclusion: do not stretch the cabling to the maximum length allowed by the RS485-spec, apply good quality cabling (preferably screened), run the cabling at distance from possibly disturbing cables, and keep the interface-cabling as short as possible between Master and Slave(s).

[Toulon7559]

Progress!

The distorted responses and the challenge for decoding triggered me to install the Python-module minimalmodbus.
With this installation & application a lot of the 'problems' described in my previous 2 messages seem to have been solved:
- sending requests is much easier incl. embedded automatic calculation and inclusion of CRC
- reception of messages is now without any problems [distorted responses apparently still can be decoded through minimalmodbus]
- automatic conversion of the payload-bytes to value(s).
The short request message instrument.read-register(x,y) nicely produces for register-address x an output value from the 2 payload-bytes.
By setting y in that message, the message-call outputs the value of registeraddress x as real/float value with y decimals: y=0 effectively results in output as integer value.
The output for the long request message instrument.read_registers(x,y) for register-address x and for y registers is for y=2 not a single integer value from the 4 payload-bytes, but 2 integer values in a list. Requires an extra script-line to extract the integer values from this list and then combination & multiplication with a float-factor produces the 'real' value.
The result of the script is shown in the screenshots in the attachments.

This step of development accomplished!
- information can be read from the kWh-meter,
- data can be extracted from the response-messages and converted to real/float values.
Next steps:
1. error trapping (because not every request message gets a processable response and the script should then not stop, but should robustly continue till values collected)
2. make a script for setting of the Slave-address of a meter to another value than the default 01, incl. checking that the change has been correctly performed
3. make an interface towards Domoticz for defined periodic read-out from selected registers of selected Slave(s) and transfer of values.
JSON-application seems the simplest. Somebody with some simple & proven example Python-script-lines?
4. make a direct upload-function to PVOutput in the Python-script at least for parameters v1 [=Energy] and v2 [=Power].

[Toulon7559]

HELP requested from members with more experience with Python-scripts & Domoticz!

Trying to develop an extension to the Python-script mentioned in the earlier messages in this thread, with the purpose of upload of data to Domoticz (and to PVOutput).
The wiki to the Python-script for the Omnik Solar Inverter seems a good candidate for borrowing the structure and part of the script, but for the resulting script too many error reports which I do not understand .........
Then back to basics, which means that ( borrowing from wiki and from the forum) I have squeezed the upload-section for Domoticz to the 6 lines shown below.
Host, port and url for Domoticz are inserted as parameters, enabling to direct the json_flow as required. Domoticz_url = json.htm
If Domoticz is on the Raspberry also running this Python-script, then domoticz_host = localhost or domoticz_host = 127.0.0.1 should point to the required destination. Correct assumption?

Code: Select all

# --------------------------------------------------
# Line120 = START OF UPLOAD TO DOMOTICZ
# --------------------------------------------------

if POWER >= 0:
   json.load(urllib2.urlopen('http://domoticz_host:domoticz_port/domoticz_url?type=command&param=udevice&idx=domoticz_PE&nvalue=0&svalue=POWER;ENERGY')
   json.load(urllib2.urlopen('http://domoticz_host:domoticz_port/domoticz_url?type=command&param=udevice&idx=domoticz_V&nvalue=0&svalue=VOLTAGE')
   json.load(urllib2.urlopen('http://domoticz_host:domoticz_port/domoticz_url?type=command&param=udevice&idx=domoticz_C&nvalue=0&svalue=CURRENT')
   print 'Upload done'
else:
   print 'No Power = No Upload'

# --------------------------------------------------
# Line132 = END OF UPLOAD TO DOMOTICZ
# --------------------------------------------------

And then surprised by the resulting error-report ....

Error report on 2nd of 2 comparable lines

Screenshot160107.JPG (29.12 KiB) Viewed 16172 times

In the testrun from the Putty command line the script-line 124 apparently is OK, but script-line 125 (with exactly the same structure) gets an error, already at the 'json-header'.

Update January 27
After further experiments, on January 27 a solution has been found: see http://www.domoticz.com/forum/viewtopic ... 227#p72227
In hindsight, in the inputs to the above code the insertion of strings and floating values probably has been confused, with predictable error reports.
The resulting code works: no need to look back to the 'erroneous' code above .......

[Toulon7559]

If entry to Domoticz through the frontdoor is not possible for unclear reasons, you look for entry through the backdoor .....
Which means that I searched & found a Python-script for upload of data, sufficiently compatible with my read-out script for the RS485-interface of the DDS238-1ZN kWh-meter.

The resulting script is shown below.
Application requires installation of the Python-modules serial and minimalmodbus, as required to deal with RS485-interface & Modbus.
The debug mode of minimalmodbus is a bonus when tuning & testing your application of this script: see line 34 of the script for it's (de)activation.
If you have Domoticz running, all other modules are present for import.
The different origins of the 2 parts of this basic script can be well recognized, not only by the separation bars I have inserted, but also by the structure.
Part 1 is the read-out of all registers of the DDS238's RS485-interface. Part 2 is dedicated to upload to PVOutput for v1, v2, v6 and c1.
At the start of the 2nd part (for Upload) I have simply imported there the modules extra needed in part 2, and have linked there the settings and parameters of part 2 to those in part 1, instead of only one section for the whole script for import & definition.
The script looks long, but for 'easy visibility' especially in Part1 I have programmed in small steps, and inserted plenty of print-lines/comments
1) to satisfy my curiosity to the operation of the DDS238-interface and 2) to ease error-trapping.
If you take out all print-lines and comments as well as all lines not related to LIFENERGY, POWER and VOLTAGE, the file considerably shrinks, and a skilled programmer may surely further combine various lines towards an even leaner script.
Periodical unattended running of the script requires a cronjob.

Obviously, suggestions for improvement are welcome:
- first candidate seems a form of correction for a missing read-out by repeating reading-cycles until success
[because not all read-requests are immediately successful].
- second candidate (for PV-application) is suppression of increase of 'life-energy' being reported before sunrise and after sunset
[Cannot be caused by PV-production. Due to spurious measurements, or a side-effect of standby-consumption? In that perspective the addition of the indicated calculation for 'true' Wh-today may have merits combined with a time-window for 'legal' uploads].

This script is for a DDS238-1ZN kWh-meter with it's AC-wiring set to give positive values for Forward Energy & Power for PV-production at the RS485-interface and S0-interface.
Reverse energy then implies 'consumption', and Life net energy = (Forward Energy) - (Reverse Energy)
Not documented, nor critical for the PV-production assumed in this script (0<P<32768 VA), but negative/reverse Power is represented by a value >32768.
Apparently for negative/reverse Power you need to apply 2-complement. For calculation of negative Power a simple placeholder inserted in this script by
if ActivPower > 65535/2:
ActivPower = ActivPower - 65534
The above aspects are valid for DDS238-1ZN: for another kWh-meter with RS485-interface, you will see other peculiar aspects, starting with other register-addresses and other functions.

This script is a practical solution to get the data in the 'System', but for control applications the direct entry within this script to Domoticz through the frontdoor is better: for that aspect see my later message http://www.domoticz.com/forum/viewtopic ... 227#p72227

Code: Select all

#!/usr/bin/python
# -*- coding = utf-8 to enable reading by simple editors -*-
# --------------------------------------------------
# Line004 = PREPARATION & SETTINGs
# --------------------------------------------------

# For script-operation

import serial                   # required for handling of the serial port
import minimalmodbus            # required for handling modbus
import datetime             	# used for timestamp

# Line013 = Provide here the settings for access to PVOutput

slave = 1             # decimal slave-address of the DDS238 kWh-meter
pvout_enabled   = True
pvout_apikey    = "<YOUR API-key string for PVOutput>"
pvout_sysid     = <YOUR SID for PVOutput>
pvout_cumflag   = 1   # flag is 1 if you apply lifetime-energy as reported by DDS238
                      # flag must be 0 if you upload a calculated Wh_today

# --------------------------------------------------
# Line023 = READING THE RS485-INTERFACE OF DDS238
# --------------------------------------------------
# the "print"-lines only added for local read-out e.g. during script_tuning

now = datetime.datetime.now()
print
print 'Time = ', now
print
instrument = minimalmodbus.Instrument('/dev/ttyAMA0',slave) # port name, slave address
instrument.serial.baudrate = 9600
instrument.serial.timeout = 0.5
# instrument.debug = True
print instrument
print
print '== Read-out as integer-lists from 4 bytes =='
print 'Registers 01/00 = Life_Net_Energy'
print instrument.read_registers(0,2) # startregister, number of registers
print 'Registers 09/08 = Reverse_Energy'
print instrument.read_registers(8,2) # startregister, number of registers
print 'Registers 11/10 = Forward_Energy'
print instrument.read_registers(10,2) # startregister, number of registers
print
print '== Read-out as integers from 2 bytes =='
x=12
while x<22:
  print 'Register ', x
  print instrument.read_register(x,0) # register, number of decimals
  x = x + 1

print
#print '== Values after scalecorrection & check =='
TotalEnergy1 = instrument.read_registers(0,2)
LifeEnergy_High = TotalEnergy1[0]
LifeEnergy_Low = TotalEnergy1[1]
LifeEnergy = 0.01 * ((LifeEnergy_High * 65535) + LifeEnergy_Low)
#print 'Life_Net_Energy  = ', LifeEnergy, ' kWh' 
LIFENERGY = LifeEnergy * 1000
TotalEnergy2 = instrument.read_registers(8,2)
RevEnergy_High = TotalEnergy2[0]
RevEnergy_Low = TotalEnergy2[1]
RevEnergy = 0.01 * ((RevEnergy_High * 65535) + RevEnergy_Low)
#print 'Reverse_Energy   = ', RevEnergy, ' kWh'
REVENERGY = RevEnergy * 1000
TotalEnergy3 = instrument.read_registers(10,2)
FwdEnergy_High = TotalEnergy3[0]
FwdEnergy_Low = TotalEnergy3[1]
FwdEnergy = 0.01 * ((FwdEnergy_High * 65535) + FwdEnergy_Low)
#print 'Forward_Energy   = ', FwdEnergy, ' kWh'
FWDENERGY = FwdEnergy * 1000
Voltage = instrument.read_register(12,1)
#print 'Voltage       = ', Voltage, ' V'
VOLTAGE = Voltage
Current = instrument.read_register(13,2)
#print 'Current       = ', Current, ' A'
CURRENT = Current
ActivPower = instrument.read_register(14,0)
#print 'Activpower-register = ', ActivPower
if ActivPower < 65535/2:
#   print '=> ActivePower   = ', ActivPower, ' VA'
   PRODUCTION = ActivPower
   CONSUMPTION = 0
else:
   ActivPower = ActivPower - 65534
#   print '=> ActivePower   = ', ActivPower, ' VA'
   PRODUCTION = 0
   CONSUMPTION = - ActivPower

POWER = PRODUCTION
ReactPower = instrument.read_register(15,0)
#print 'ReactivePower = ', ReactPower, ' VAR'
PF = instrument.read_register(16,3)
#print 'PowerFactor   = ', PF
Freq = instrument.read_register(17,2)
#print 'Frequency     = ', Freq, ' Hz'
Status = instrument.read_register(21,0)
Adres = Status/256
print 'DDS238_Status, Address  = ', Adres
Rate = Status%256
print 'DDS238_Status, Baudrate = ', Rate
print

# errortrapping to be added, because not every call to a register is successful .......
# --------------------------------------------------
# END READING RS485-INTERFACE OF DDS238
# --------------------------------------------------

# --------------------------------------------------
# START OF UPLOAD TO PVOUTPUT
# --------------------------------------------------

# For script-operation

import subprocess
from time import strftime
import time

# Presetting of parameters

SYSTEMID = pvout_sysid
APIKEY = pvout_apikey
t_date = format(strftime('%Y%m%d'))
t_time = format(strftime('%H:%M'))
pv_volts=0.0
pv_power=0.0
Wh_life=LIFENERGY
Wh_today=0

# space for addition of a calculation for current_temp

if pvout_enabled and (POWER >=0):
   pv_volts=VOLTAGE
   pv_power=POWER
   Wh_life=LIFENERGY
   cum=pvout_cumflag
   cmd=('curl -d "d=%s" -d "t=%s" -d "v1=%s" -d "v2=%s" -d "v6=%s" -d "c1=%s" -H \
   "X-Pvoutput-Apikey: %s" -H \
   "X-Pvoutput-SystemId: %s" \
   http://pvoutput.org/service/r2/addstatus.jsp'\
   %(t_date, t_time, Wh_life, pv_power, pv_volts, cum, \
   APIKEY, SYSTEMID))
   ret = subprocess.call(cmd, shell=True)

# space for addition of a calculation for Wh_today

#time.sleep(20)                   # delay until next lines

#if Wh_today>0:                   # if you apply a calculated Wh_today
#  cmd=('curl -d "data=%s,%s,,,,,,," -H \
#  "X-Pvoutput-Apikey: %s" -H \
#  "X-Pvoutput-SystemId: %s" http://pvoutput.org/service/r2/addoutput.jsp' \
#  %(t_date, Wh_today,\
#  APIKEY,SYSTEMID))
#  ret = subprocess.call(cmd, shell=True)

# --------------------------------------------------
# END OF UPLOAD TO PVOUTPUT
# --------------------------------------------------

print
print
print '= RS485-Values for Upload ='
print 'Life_Net_Energy  = ', LIFENERGY, ' Wh'
print 'Forward_Rnergy  = ', FWDENERGY, ' Wh'
print 'Reverse_Energy   = ', REVENERGY, ' Wh'
print 'Voltage       = ', VOLTAGE, ' V'
print 'Current       = ', CURRENT, ' A'
print 'ActivePower   = ', ActivPower, ' VA'
print '=> Production   = ', POWER, ' VA'
print '=> Consumption  = ', CONSUMPTION, ' VA'
print
print '= Uploaded to PVOutput ='
print 't_date %s' %t_date
print 't_time %s' %t_time
print 'pv_volts %s' %pv_volts
print 'pv_power %s' %pv_power
print 'Wh_life %s' %Wh_life

[Toulon7559]

Further experience

Reliable Read-out
Issuing 2 or more successive read-cycles in the Python-script seems a solution which during manual test-runs from the Putty-commandline is a rude, but effective method to get reliable results from the DDS238-meter's RS485-interface, although running that script under a cronjob still 'holes' remain appearing .........

Blocking of upload of spurious Energy-data
Rude blocking uploads before 05:00 and after 22:00 can be realised by setting of a time-gate in the Python-script.
Application of times for sunrise and sunset would be better. Looking for a short/simple & reliable method to get values for sunrise and sunset.

Upload to PVOutput and display
When information from the RS485-interface does not appear in the graphs of PVOutput, but all preparatory steps seem correct, investigation of details is required and corrective solutions to be found.
Initially in my setup 2 separate upload streams to PVOutput filled the SID WWZ_7559A0, with the streams best linked to their sources of data:
v1, v2, v6 and c1=1 from the Python-script acting on the RS485-output from DDS238 [for display of Energy, Power and Voltage in the 'Main screen']
Upload every 5 minutes by cronjob-trigger
[c1=1 because the RS485-interface has life-energy as default]
v5, v7 till v12 and c1=0 from a lua-script acting on the S0-output from DDS238 (and other info) through Domoticz
Upload every 5 minutes by clock-trigger in the lua-script
[c1=0 because from the S0-interface the calculation of day-energy is easier than calculation of life-energy]
With that setting the info from the Python-script does not appear in the screens of PVOutput.
After the following change to the setup for Upload at least the uploaded RS485-information is again visible in the PVOutput-windows, when the upload by the lua-script is running:
- in the Python-script I changed the direction for Energy-Upload to PVOutput from v1 [display in 'Main screen'] to v10 [display in 'Extended Data']
- for upload of v1 to PVOutput I re-activated the relevant part of the lua-script acting on the S0-output of the DDS238-meter
Conclusion:
The Python-script & Cronjob are principally OK, but apparently with different inputs for c1 the internal logic at PVOutput gives priority to the input with c1=0
In my setup it is the lua-script based on S0-interface .......
Next test:
Check operation of both scripts with c1=1, assuming that then the internal logic within PVOutput equally takes both streams.
- Python-script uploads for v1, v2, v6 and v10 => Wh_today for graphline v1 deducted by PVOutput from uploaded Wh_life. Wh_life also separately shown as v10
- Domoticz' lua-script uploads for all other v's
Result:
OK. Graph-line related to v1 now appears as Wh_today as soon as life-energy has made a step. All other lines also displayed as expected.
However, graphlines for v1, v2 and v10 have 'holes', probably due to missed read-out. Surprisingly, v6 [Voltage] is always continuous.
'Holes' are more or less acceptable for display, registration, etc. at PVOutput, but not acceptable for uploads to Domoticz for control applications:
the latter applications require gapless/continuous, good data.

Now find (better) solutions for the remaining 'Next steps' at http://www.domoticz.com/forum/viewtopic ... 808#p65615

[Toulon7559]

Upload with 'Time-Gating' coupled to sunrise and to sunset requires a reliable source for sunrise-time and for sunset-time.
At https://www.raspberrypi.org/forums/view ... 91&t=71010 found a reasonably simple method to get and process those times.
Ephem is a Python-module dedicated for the job:
- Load & install module pyephem from the command-line by command sudo pip install pyephem,
- apply in your script some of the code shown at the url mentioned above,
- insert your latitude and longitude as decimal degrees,
and you get times for sunrise and for sunset expressed as UTC-info.
Advantages:
The calculated times directly relate to your geographical location.
UTC is fixed time based in UK and does not jump with the changes between wintertime and summertime. OK related to the sun, which not jumps either ........
Disadvantage:
UTC-time is never your local time, and therefore pay attention to the differences due to timezone and due to summer-/wintertime.
If not willing to invent your own functions, digging a bit further in Ephem probably you'll find integrated remedies to get local time.

The Astral-module provides a similar solution to get the info for sunrise and for sunset: see http://pythonhosted.org/astral/

By URL/API-calling to OpenWeatherMap you can also get such time-info, as well as meteo-info related to your location:
see http://www.domoticz.com/forum/viewtopic ... 964#p71363

[Toulon7559]

Sometimes a remedy is simpler than expected ....

In hindsight, the 'holes' reported in my message of Mon Jan 11, 2016 5:55 pm might have been caused by a 'syncing-collision' inside PVOutput:
- in Settings of PVOutput the interval is set at 5 minutes
- the cronjob also had an interval of 5 minutes
If (due to the interval) PVOutput is busy with 'internal' processing, then apparently sometimes an incoming upload for energy & power is missed.
With the cronjob set at an interval of 2,5 minutes, the extra, 'intermediate' upload helps PVOutput to fill any gaps in the table & graph for energy & power.

But still wondering why an upload for Voltage never fails ........

[Toulon7559]

This Forum is rich on solutions: you only have to find them .......

After trying several example-scripts, finally I found a combination which in a Python-script simply & reliably uploads the floating values from the RS485-interface to the virtual sensors in Domoticz.
The segment of code shown below can be merged in my script published earlier on January 08.
In this code the IDX-values are just placeholders which you have to adapt for your own configuration.
The IP-address 127.0.0.1 means direction to the local host (= Domoticz running on the same computer as the Python-script).
Although using json, the import of json is apparently not needed [just check in your own application whether that is true].
The if-statement might be skipped if you never have negative values for Power.
The script in this message is sufficient to have in Domoticz just a recording and P1-display for 'general' lifetime energy, daily energy and power.
On TODO-list: splitting the registration to tariff-groups.
Although a lot of effort for little added value, when considering that in the Dutch grid the difference between tariffs is approx. 1 ~1,5 cent/kWh!
For a 'complete' P1-meter registration at Domoticz then the values for REVENERGY and FWDENERGY have to be split to USAGE1,2 respectively RETURN1,2 according to timing for high/low tariffs in the Dutch grid, based on the actual combination of weekday & time.
Additional bookkeeping required for splitting the information from the single, real energy-counter in at least 2 virtual counters for high tariff respectively low tariff: at start of a low tariff period or high tariff period you have to store the values for USAGE1 and RETURN1, respectively USAGE2 and RETURN2, and keep those values fixed till the next switching.

Code: Select all

# --------------------------------------------------
# START OF UPLOAD TO DOMOTICZ
# --------------------------------------------------
# Imports for script-operation

#import json
import urllib
from datetime import date

# Presetting of IDX for virtual sensors
# Numbers shown are placeholders, which you have to adapt for your own configuration
domoticz_P1 = "209"    # IDX for virtual P1-meter
domoticz_V = "211"     # IDX for virtual sensor for voltage
domoticz_PE = "202"    # IDX for virtual sensor for power & energy
domoticz_C = "210"     # IDX for virtual sensor for current

# Setting & Linking of parameters
# Next 3 lines are starter to define the period with high tariff. Further code is required to include public holidays in tariff-switching.
weekday = date.isoweekday(now)
print 'Weekday = ',weekday
hightime = (now.hour > 6) and (now.hour < 23) and (weekday < 6)
# Next 4 lines are for high tariff.  Further code is required to tune the next 4 lines for splitting & storing the energy-values for each tariff-period
USAGE1 = REVENERGY
USAGE2 = 0
RETURN1 = FWDENERGY
RETURN2 = 0

CONS = CONSUMPTION
PROD = PRODUCTION

httpresponse = urllib.urlopen("http://127.0.0.1:8080/json.htm?type=command&param=udevice&idx=" + str(domoticz_P1) + "&nvalue=0&svalue=" + str(float(USAGE1)) + ";" + str(float(USAGE2)) + ";" + str(float(RETURN1)) + ";" + str(float(RETURN2)) + ";" + str(float(CONS)) + ";" + str(float(PROD)) )

if POWER >= 0:
   httpresponse = urllib.urlopen("http://127.0.0.1:8080/json.htm?type=command&param=udevice&idx=" + str(domoticz_V) + "&nvalue=0&svalue=" + str(float(VOLTAGE)) )
   httpresponse = urllib.urlopen("http://127.0.0.1:8080/json.htm?type=command&param=udevice&idx=" + str(domoticz_PE) + "&nvalue=0&svalue=" + str(float(POWER)) + ";" + str(float(ENERGY)) )
   httpresponse = urllib.urlopen("http://127.0.0.1:8080/json.htm?type=command&param=udevice&idx=" + str(domoticz_C) + "&nvalue=0&svalue=" + str(float(CURRENT)) )

# --------------------------------------------------
# END OF UPLOAD TO DOMOTICZ
# --------------------------------------------------

[Toulon7559]

Public holidays in the Netherlands have low tariff: some are on fixed calendar-dates, others are variable.

Who has an additional (simple) solution to incorporate those holidays in the script?

[Toulon7559]

Sunrise and Sunset can be implemented by means of module Ephem, but can also directly be found within Domoticz:
see http://www.domoticz.com/wiki/Domoticz_A ... nset_times
You can also call WUnderground: see https://www.wunderground.com/weather/ap ... /astronomy
Just need some help for the Python-script to extract the time-values from the resulting response.

Who has/knows a working script-line?

[Noppie]

Can anybody please help me? I'm a newbie and have a raspberry pi. I managed to read the data out of my Omnik Solar inverter (with python script from wouterr), made virtual devices in Domoticz, but how do I get the Omnik data into Domoticz?

[Toulon7559]

@noppie

If you have applied the script-example from the Domoticz-wiki and have correctly inserted the actual idx-numbers and the actual names for your virtual sensors in Domoticz, what is wrong?

On the other hand, if you have extracted from the inverter by means of a Python-script the values for power, for energy, for voltage and for current, then in this thread my message of 28 january may give you alternative example Python-script-lines for upload of those values to related virtual sensors in Domoticz.
You have to adapt the identifiers for your values and you have to apply the idx-values valid for your virtual sensors.

[Toulon7559]

Not directly related to this thread, but applicable, because my scripts apply import of certain modules, and to be able to import first you have to install ......

My configuration of Domoticz@Raspberry once more 'locked' and only way out was reset & reinstallation from a new SD-image [stable v3530].
To my surprise apparently Python's pip-function not worked in the reinstalled software.
To get the RS485-interface running with my Python-script means that I had to 'manually' install the Python-modules serial, minimalmodbus and ephem
Realisation of installation for each module:
- download the related tar-package to PC
- unzip the package
- by means of WinScp transfer the resulting folder to the Raspberry to a selected directory
- at the commandline of Putty change the path to that same directory in the Raspberry
- run the Python setup-function for the package, which installs the package

After that installation a Python-script can locally import the module.

[kaboom748]

THIS IS THE DATASHEET FOR THE PROTOCOL

De : kWhmeter [mailto:[email protected]]
Envoyé : 13 novembre 2016 01:46
À : GUILLAUME . <[email protected]>
Objet : Re:DDS238-1 ZN

please see it

Lixin Instrument Manufacturing Co.,Ltd.
TEL:0086-577-62750366
FAX:0086-577-62752366
Liushi ,Yueqing,Zhejiang,China
ISO9001,CE,IEC,CMC,CMS,GMC
contact person : peter (manager)
MSN:[email protected]
skyper:lixinmeter
http://www.chinaenergymeter.com http://www.hi-king.com