Hi,
I want to add a driver for Eastron SDM630 to the dbus-cgwacs module.
The project refers to the "velib" that is currently not available on GitHub.
Can anymore pls share or give me a link where I can find the velib.
Thanks in advance......tobias
Look in any of the dbus services that are written in python and you will find a copy...
It is also available within git, here
The existing driver requires velib in C, not in Python.
See the makefile of dbus-cgwacs that refers to multiple C files of velib like "ext/velib/src/plt/serial.c".
The velib is required to be able to build dbus-cgwacs.
Venus OS is open source as it is just a re-package of linux through OE. Some of the drivers can be considered open source, but some parts are Victron specific and Victron clearly have not released the C based velib files. I am not surprised that velib has been kept within Victron and not released as it probably has some very low level device interaction/protocol components.
Looking at the make file, you need more than velib, you also need qslog, which is also an external dependancy and not available.
Maybe it would have been good if Victron had released a library and header files that can be compiled against, but then Victron has to support that interface and changing it requires more thought, time and testing.
Why don't you just create a new driver using python, to read the data from your device and write it to dbus. You can use the same dBus paths and elements. Relatively simple, and means no dependancy on Victron non open source components.
My preferred language is C, therefore I want to extend the existing driver to include SDM630 support instead of writing from scratch.
I didn't read that velib is explicitly closed source, so I thought I might ask. You're absolutely right, a library + header file would be fine.
I saw on the mailing list that somebody else has requested the velib and received a private reply, so I hopped that there's s way to get it, too.
doubh: Did you ever get this to work. I'm looking at the same challenge, I have the same Eastron mounted already, and would rather not have two smartmeters.
An alternative for me would be to emulate the values of the Eastron, in a format acceptable for Victron. Could be with a Rasberry Pi acting as a man in the middle, since i would ideally want to split the original values from Eastron to a Victron, but also a Growatt (70/30) share ish.
I think main challenge may be to get a template of both protocols/configs used without buying and test installing a EM24. It is not super expensive (about 200usd), but adding electrician hours and limited space in power cabinet is a bit of a challenge.
I'm decent in c#, and willing to spend time on this. Have played around with both rasberry pi and arduinos, so not new to C.
Hi,
I have the same requirement and got today to following conclusion:
From my point of view a reasonable try could be taking /opt/victronenergy/dbus-modbus-client/carlo_gavazzi.py (EM24 definition) as a template, adapt registers to Eastron's ones and compiling the file.
In order to activate that duplicate the import statement in /opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py has to be extended as well.
An ammendment of /opt/victronenergy/dbus-modbustcp/unitid2di.csv might be required as well.
Hi all! to read energy meter data, the dbus-modbus-client is the way to go indeed.
sources on github as well as on the gx device itself.
dbus-cgwacs is deprecated: some day we’ll move its functionality over to dbus-modbus-client.
also for any other data reading of a 3rd party device having modbus tcp or rtu/rs485: same thing, that relatively new repo is the one to extend.
For other things: Velib sources are provided sometimes, with NDA and such.
Ps sry I’m a bit late to the discussion
Hi Matthijs,
in meantime I managed to create an additional python-script, which reliably detects the SDM630 meter. Also serial is extracted correctly.
However the the register.py script does not include a class to support "float BIG ENDIAN". Therefore I added another class "Reg_f32b" with a setup, where I believed that it could cover my requirement.
class Reg_f32l(Reg_num):
def __init__(self, base, *args, **kwargs):
super(Reg_f32l, self).__init__(base, 2, *args, **kwargs)
self.coding = ('<f', '<2H')
class Reg_f32b(Reg_num):
def __init__(self, base, *args, **kwargs):
super(Reg_f32b, self).__init__(base, 2, *args, **kwargs)
self.coding = ('>f', '>2H')
With that trial however I only get weird results. Also with mixed coding setups ('<f', '>2H' or '>f', '<2H') I haven't reached a reasonable result.
I know several program languages, however I had no clue with python so far.
Therefore I would appreciate, if you could provide a hint, how to define the coding section for float in big endian.
Maybe it would make sense to integrate the class for in standard release for float in big endian?
Cheers,
Thomas
Hi Thomas, nice progress!
wrt the question; I really wouldnt know.
perhaps someone else here? And otherwise try Stackoverflow and/or Google
The link to your register.py script above does not work. Can you create a post here with the script?
Hi @osaether,
the link was generated by the forum. It tried to interprete it as a link ;-)
File attached (renamed - otherwise not accepted).
Mod from line 109 onwards
I came to following conclusion:
- Following mapping is correct.
self.coding = ('>f', '>2H') - With support of iobroker and node red I found out, that dbus-modbus-client reads always from holding registers (code 04). The dual support of same registers in holding and input area is supported by EM24 device.
- Plenty other devices like e.g. SDM630 differentiate between holding and input registers. The physical addresses are used for different purpose in holding and input area!
- I have not found any way in dbus-modbus-client to switch communication to read from input registers. The module seems to be designed only to support access to holding area.
Any confirmation about my finding is welcome.
In that case I could stop my activity.
Hi Tobias,
I had this evening a more detailed look to the Modbus definition of the Eastron device.
In newest version they have implemented a serial-number so far, however they don't have a manufacturer and product identification code.
This makes a generic implementation and especially a potential transfer into the standard product impossible. For our individual purpose we could identify the serial via a separate tool and use that as an model-identifier. However we would have to extend the model list for any additional serial.
update:
the serial is on holding-register 104513 (fc00h) and not on 464513 as referenced by Eastron!
An additional challenge might be that VenusOS evaluates only 1 register, whereas Eastron uses 2.
Halleluja!
The implementation for the SDM630 is running. I had to duplicate the "device.py" component, to link it into the Eastron module and to ammend it with Input-Register readings. In general it was not too complicated.
Device was found immediately and has shown right values, however it did not update.
Finally I wasted 3 hours in order to find out that update-method is influenced by "productid". I wondered, if I would have made potential mistakes with the "Eastron_device.py" adaptation.
Currently I have only 1 phase connected. Therefore the other phases show zero-values.
Values get also reflected into VRM ;-)
The only issue that I have is potentially created a unique product iD, so that device is not shown as "CG EM24 Ethernet Energy Meter".
No clue how to do that yet.
Let's see, as soon the module is completed, I am gonna to share it in a separate thread as "beer-ware".
Nice work! We’d then most likely need to generate a new product id. Unless we already have a “generic energy meter” one. I’ll check next week.
Hi All,
I published the SDM630 module in following thread as donation-ware.
