kasbert / epsolar-tracer Goto Github PK
View Code? Open in Web Editor NEWTools for EPsolar Tracer BN solar charge controller
License: Apache License 2.0
Tools for EPsolar Tracer BN solar charge controller
License: Apache License 2.0
Hi,
I have the reference manual for the epsolar protocol, and would gladly share. Please let me know if you need it. Thanks
Hi,
How do I adapt info.py to query live data rather than pull the test data from testdata.py?
Also I assume that this should work with any usb->rs458 adapter with linux support? (mine is based on ch341)
Now that python 2 is unsupported, it'd be great to see this usable in version 3.
Will you accept pull requests if I do some of the work?
Hi Kasbert,
Excuse my English. Google Translator :)
I would like to ask how do I put the PV input voltage, PV current, battery voltage, etc ... to variables that I could then use the HTTP GET sending to the server.
Unfortunately python nothing to me. I managed to create a script that will give me the following values but can not be used as a variable. I do not know how :(
{0 'EPsolar Tech CO., Ltd.', 1 'Tracer4215BN', 2 'V02.14 V07.24 +'}
PV voltage (uPV): 15000 V
Current PV (iPV): 4000
PV voltage (uPV): 15000 V
Current PV (iPV): 4000
PV voltage (uPV): 15000 V
Current PV (iPV): 4000
I assume that the value has yet to be somehow processed. E.g. value / 100?
I need to get the following:
HTTP GET: http://server_address/script.php?timestamp=timestamp&uPV=value PV voltage&iPV=value PV current&...
Could you kick me in the right direction or a better example of a piece of code as I could finish.
Thank you very much.
I have a rpi3 and installed the driver.
dmesg:
usb 1-1.5: New USB device found, idVendor=04e2, idProduct=1411
[ 4386.853868] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4386.853877] usb 1-1.5: Product: XR21B1411
[ 4386.853885] usb 1-1.5: Manufacturer: Exar Corp.
[ 4386.853893] usb 1-1.5: SerialNumber: R3991242051
[ 4386.854816] cdc_xr_usb_serial 1-1.5:1.0: USB_device_id idVendor:04e2, idProduct 1411
[ 4386.854830] cdc_xr_usb_serial 1-1.5:1.0: This device cannot do calls on its own. It is not a modem.
[ 4386.854840] cdc_xr_usb_serial 1-1.5:1.0: The data interface has switched endpoints
[ 4386.854847] cdc_xr_usb_serial 1-1.5:1.0: interfaces are valid
[ 4386.854861] cdc_xr_usb_serial 1-1.5:1.0: epwrite->bEndpointAddress =1
[ 4386.854938] cdc_xr_usb_serial 1-1.5:1.0: ttyXR_USB_SERIAL0: USB XR_USB_SERIAL device
[ 4386.856227] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_ctrl_msg - rq 0x22, val 0x0, len 0x0, result 0
[ 4386.856620] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_ctrl_msg - rq 0x20, val 0x0, len 0x7, result 7
But when i execute i can not read.
/home/pi/epsolar-tracer# python readall.py
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x1 0x2b 0xe 0x1 0x0 0x70 0x77
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 2 bytes (0 received))
DEBUG:pymodbus.framer.rtu_framer:Frame - [] not ready
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
Traceback (most recent call last):
File "readall.py", line 24, in
print repr(response.information)
AttributeError: 'ModbusIOException' object has no attribute 'information'
What is the Problem?
Good day,
I have question.
I have buy this Product,
https://www.amazon.de/Solarladeregler-Tracer3210A-Solarpanel-Stromerzeuger-LCD-Display/dp/B07C22K5HD/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1537006034&sr=1-1-catcorr&keywords=tracer+3210
is a tracer 3210 and when i read the software details from the org. software from epever then i become this infos:
Device Model: TriRon3210
Device Version: V01.47+V03.11
Device SN: 00022013012xxxxx
Can i use ure Software to Read this Model?
I understand epsolar provides firmware updates for the BN-series controllers via their Windows software; if this is the case, is it also possible to update via this software? If not, is it planned for a future version?
Dear all
I have successfully installed the RS485 driver (persistent). If someone is interested I can share the instructions.
I also successfully ran readall.py, following https://mitchross09.medium.com/solar-energy-monitoring-with-raspberry-pi-and-node-red-ed59e287cdd4
I moved on to info.py and before that installed pymodbus using pip install -U pymodbus
. Now running this file gives an error
Traceback (most recent call last):
File "info.py", line 19, in
response = client.read_device_info()
File "/home/pi/epsolar-tracer/pyepsolartracer/client.py", line 42, in read_device_info
response = self.client.execute(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 109, in execute
return self.transaction.execute(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 178, in execute
broadcast=broadcast
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 274, in _transact
size = self._send(packet)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 309, in _send
return self.client.framer.sendPacket(packet)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/framer/rtu_framer.py", line 263, in sendPacket
timeout = start + self.client.timeout
AttributeError: 'NoneType' object has no attribute 'timeout'
I tried adding a timeout-parameter to the Modbus call in pyepsolartracer/client.py but that did not help. Any suggestions?
Steps to reproduce:
and we can see an error xr_usb_serial_ctrl_irq - urb shutting down with status: -2
in kernel log
Nov 2 20:25:28 raspberrypi kernel: [ 3195.724863] tty ttyXRUSB0: xr_usb_serial_tty_install
Nov 2 20:25:28 raspberrypi kernel: [ 3195.724939] tty ttyXRUSB0: xr_usb_serial_tty_open
Nov 2 20:25:28 raspberrypi kernel: [ 3195.724961] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_port_activate
Nov 2 20:25:28 raspberrypi kernel: [ 3195.725344] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_ctrl_msg - rq 0x22, val 0x3, len 0x0, result 0
Nov 2 20:25:28 raspberrypi kernel: [ 3195.727718] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_tty_close
Nov 2 20:25:28 raspberrypi kernel: [ 3195.727776] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_port_shutdown
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728060] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_ctrl_msg - rq 0x22, val 0x0, len 0x0, result 0
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728092] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_ctrl_irq - urb shutting down with status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728125] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728148] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728171] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728194] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728216] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728238] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728261] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728283] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728305] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728328] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728350] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728396] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728421] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728443] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728466] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728488] cdc_xr_usb_serial 1-1.5:1.1: xr_usb_serial_read_bulk_callback - non-zero urb status: -2
Nov 2 20:25:28 raspberrypi kernel: [ 3195.728574] cdc_xr_usb_serial 1-1.5:1.0: xr_usb_serial_tty_cleanup
Enyone got LS-B series working ?
I have LS2024B and i'm getting None in response:
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:recv:
DEBUG:pymodbus.transaction:getting transaction 1
None
Traceback (most recent call last):
File "readall.py", line 25, in <module>
print repr(response.information)
AttributeError: 'NoneType' object has no attribute 'information'
I found this com docs http://www.solar-elektro.cz/data/dokumenty/1733_modbus_protocol.pdf
I've gone through the install per the readme.txt file but when I re boot the pi I have to re run the make and insmod commands each time in order for the pi to see theses USB devices. There must be a step missing in the instructions!! help!
insmod /home/user/.bolid/xr_usb_serial_common.ko
xr_usb_serial_common: version magic '4.8.0-36-generic SMP mod_unload modversions ' should be '4.10.0-38-generic SMP mod_unload '
Hello! First of all thanks a lot for sharing this code, very helpful.
Just a question. the modbus specifications attached seems to be related to another product from EPSolar: how did you know that they works with Tracer BN series as well? I have asked EPSolar for official docs but no luck for now...
Let me start by saying I'm an idiot, and my parents are probably idiots too. I bought the RS-485 adapter with FTDI, but then also bought the EPEVER BLE-RJ45-A. I decided to try that instead figuring I could just map it to a rfcomm port like other devices I have and it should just work with this and other projects. Well, not so fast. apparently it is BLE (even says it in the name, see my first comment). BLE is, as I'm learning, a different animal. Anyone play with this? I can map a rfcomm port, but it doesn't seem to work. Looking at the BLE paring/reading/writing info there is a whole bunch of differences that may make it a non-starter without a specific project like this one to make it work, and I lack the skills/time to create one for myself.
Anyway, thanks for looking, and you can close this out without comment if you want. I just am hoping someone has a solution! I also have the USB/RS485FTDI unit but I already installed the BLE and am 2 hours away from the Observatory hosting the EPEVER Solar charge controller. I do however have remote access VNC/ssh.
USER@Home:~$ uname -a
Linux Home 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
USER@Home:~$ gcc --version
gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
USER@Home:~$ cat /etc/issue.net
Ubuntu 18.04 LTS
Please adapt the code in PIC mode if this does not contradict your beliefs
I'm finding several broken links on the GWL site. No Windows software download is among them.
The Exar driver 'Original source' link is broken as well.
I keep getting the below error:
sudo insmod ./xr_usb_serial_common.ko
insmod: ERROR: could not insert module ./xr_usb_serial_common.ko: Invalid module format
Thanks for adding the wiring information. I am wiring up my USB to FTDI RS485. The wiring info all makes sense except one thing Im not sure about. My adapter has 3.3 and 5v outputs. Any thoughts on which one I should use? or neither? Both ends have power, so it seems like just ground would need to be hooked up (and A+ B- of course).
Thanks!'
Bryan
OpenWrt-21.02 uses Linux kernel 5.4.119 where the driver fails to compile, with 5.4.114 it was still working.
According to openwrt/packages#15666 there is a patch to make it build again. Not sure if it is still compatible with older kernels then.
It has these errors:
make -C /lib/modules/5.13.0-30-generic/build M=/home/lobater/projects/test/epsolar-tracer/linux_usb_serial
make[1]: Entering directory '/usr/src/linux-headers-5.13.0-30-generic'
CC [M] /home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.o
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c: In function ‘xr_set_flow_mode’:
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:636:27: error: expected ‘;’ before ‘int’
636 | unsigned long rs485_flags
| ^
| ;
637 | int ret;
| ~~~
In file included from ./include/linux/kernel.h:16,
from /home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:15:
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:653:33: error: ‘flags’ undeclared (first use in this function)
653 | spin_lock_irqsave(&data->lock, flags);
| ^~~~~
./include/linux/typecheck.h:11:9: note: in definition of macro ‘typecheck’
11 | typeof(x) __dummy2; \
| ^
./include/linux/spinlock.h:384:2: note: in expansion of macro ‘raw_spin_lock_irqsave’
384 | raw_spin_lock_irqsave(spinlock_check(lock), flags); \
| ^~~~~~~~~~~~~~~~~~~~~
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:653:2: note: in expansion of macro ‘spin_lock_irqsave’
653 | spin_lock_irqsave(&data->lock, flags);
| ^~~~~~~~~~~~~~~~~
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:653:33: note: each undeclared identifier is reported only once for each function it appears in
653 | spin_lock_irqsave(&data->lock, flags);
| ^~~~~
./include/linux/typecheck.h:11:9: note: in definition of macro ‘typecheck’
11 | typeof(x) __dummy2; \
| ^
./include/linux/spinlock.h:384:2: note: in expansion of macro ‘raw_spin_lock_irqsave’
384 | raw_spin_lock_irqsave(spinlock_check(lock), flags); \
| ^~~~~~~~~~~~~~~~~~~~~
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:653:2: note: in expansion of macro ‘spin_lock_irqsave’
653 | spin_lock_irqsave(&data->lock, flags);
| ^~~~~~~~~~~~~~~~~
./include/linux/typecheck.h:12:18: warning: comparison of distinct pointer types lacks a cast
12 | (void)(&__dummy == &__dummy2); \
| ^~
./include/linux/spinlock.h:251:3: note: in expansion of macro ‘typecheck’
251 | typecheck(unsigned long, flags); \
| ^~~~~~~~~
./include/linux/spinlock.h:384:2: note: in expansion of macro ‘raw_spin_lock_irqsave’
384 | raw_spin_lock_irqsave(spinlock_check(lock), flags); \
| ^~~~~~~~~~~~~~~~~~~~~
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:653:2: note: in expansion of macro ‘spin_lock_irqsave’
653 | spin_lock_irqsave(&data->lock, flags);
| ^~~~~~~~~~~~~~~~~
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:654:2: error: ‘rs485_flags’ undeclared (first use in this function); did you mean ‘rseq_flags’?
654 | rs485_flags = data->rs485.flags;
| ^~~~~~~~~~~
| rseq_flags
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c: In function ‘xr_port_remove’:
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:1062:9: error: ‘return’ with a value, in function returning void [-Werror=return-type]
1062 | return 0;
| ^
/home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.c:1056:13: note: declared here
1056 | static void xr_port_remove(struct usb_serial_port *port)
| ^~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:281: /home/lobater/projects/test/epsolar-tracer/linux_usb_serial/xr_serial.o] Error 1
make[1]: *** [Makefile:1879: /home/lobater/projects/test/epsolar-tracer/linux_usb_serial] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.13.0-30-generic'
make: *** [Makefile:9: all] Error 2
how can I fix it?
Haven't had time to dive deeper into the root cause - when trying to make a transaction on a Pi Zero W with kernel 4.9, the kernel immediately crashes. It doesn't even write a kernel panic to stdout or logs - hangs for a few seconds and then restarts. Has anyone else experienced this? With kernel 4.4 I had 100% CPU usage during the modbus transactions for the full 1+ second of delay between successive calls (tried setting timeout to a lower value, didn't help).
Just a note, your excellent work is also compatible with at least the 4210A controller:
readall.py reports:
{0: 'EPsolar Tech co., Ltd', 1: 'Tracer4210A', 2: 'V01.12+V02.11'}
Though not entirely unexpected, I appreciate your work on this project and would like to provide some formal verification for A-series support. If you have any additional tests which would help with development please don't hesitate to ask. So far, the BN-series registers match the A-series perfectly, though.
I am wondering how you write to the unit to set battery size etc.
I am working on sending the data to signalK
it is still failing to make the driver:
pi@raspberrypi4:~/xr_usb_serial_common-1a $ sudo make
make -C /lib/modules/5.15.32-v7l+/build M=/home/pi/xr_usb_serial_common-1a
make[1]: Entering directory '/usr/src/linux-headers-5.15.32-v7l+'
CC [M] /home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.o
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_ctrl_irq’:
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:261:21: warning: unused variable ‘tty’ [-Wunused-variable]
261 | struct tty_struct *tty;
| ^~~
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_process_read_urb’:
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:393:21: warning: unused variable ‘tty’ [-Wunused-variable]
393 | struct tty_struct *tty;
| ^~~
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_softint’:
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:468:21: warning: unused variable ‘tty’ [-Wunused-variable]
468 | struct tty_struct *tty;
| ^~~
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_reset_resume’:
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1626:21: warning: unused variable ‘tty’ [-Wunused-variable]
1626 | struct tty_struct tty;
| ^~~
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c: At top level:
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1691:17: error: initialization of ‘unsigned int ()(struct tty_struct )’ from incompatible pointer type ‘int ()(struct tty_struct )’ [-Werror=incompatible-pointer-types]
1691 | .write_room = xr_usb_serial_tty_write_room,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1691:17: note: (near initialization for ‘xr_usb_serial_ops.write_room’)
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1695:21: error: initialization of ‘unsigned int ()(struct tty_struct )’ from incompatible pointer type ‘int ()(struct tty_struct *)’ [-Werror=incompatible-pointer-types]
1695 | .chars_in_buffer = xr_usb_serial_tty_chars_in_buffer,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1695:21: note: (near initialization for ‘xr_usb_serial_ops.chars_in_buffer’)
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_init’:
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1709:29: error: implicit declaration of function ‘alloc_tty_driver’ [-Werror=implicit-function-declaration]
1709 | xr_usb_serial_tty_driver = alloc_tty_driver(XR_USB_SERIAL_TTY_MINORS);
| ^~~~~~~~~~~~~~~~
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1709:27: warning: assignment to ‘struct tty_driver *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
1709 | xr_usb_serial_tty_driver = alloc_tty_driver(XR_USB_SERIAL_TTY_MINORS);
| ^
/home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.c:1726:3: error: implicit declaration of function ‘put_tty_driver’ [-Werror=implicit-function-declaration]
1726 | put_tty_driver(xr_usb_serial_tty_driver);
| ^~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:277: /home/pi/xr_usb_serial_common-1a/xr_usb_serial_common.o] Error 1
make[1]: *** [Makefile:1868: /home/pi/xr_usb_serial_common-1a] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.15.32-v7l+'
make: *** [Makefile:9: all] Error 2
Is anyone else finding the modbus interface unreliable? It will suddenly stop working for me, and to get it back I have to do some combination of turning it off and on (disconnecting from battery) and factory reset. Unfortunately its not even a reliable series of steps to make it respond again.
Oddly the MT50 remote monitor box continues to work when the modbus isn't responding, which makes me think the MT50 is using some different protocol? Or maybe its some other issue?
When it fails I get this error:
Traceback (most recent call last):
File "/home/pi/pancho_brain/test_solar.py", line 27, in
result = client.read_input_registers(0x3000, 9, unit=1)
File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/common.py", line 120, in read_input_registers
return self.execute(request)
File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 82, in execute
raise ConnectionException("Failed to connect[%s]" % (self.str()))
pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] Failed to connect[rtu baud[115200]]
The device is still there at /dev/ttyUSB0, it just refuses connection. When it's not responding, the Solar Monitor program on Windows doesn't connect either. and tried the other pins too (since there's two choices for each A and B).
I'm using a cable built using this connector:
https://www.amazon.com/gp/product/B00NKAJGZM/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
I have the stock cable too, but it has never worked for me.
Can anyone think of anything to try? This is from a Raspberry Pi, if it matters. I've quadruple checks the wiring of the cable, The issue happens on two different Tracer 4210a charge controllers.
All I can think of is that it might be an issue with my adaptor (the connector linked above), since the MT50 box always works. I ordered another one, hopefully it fixes it. But I'm curious if anyone else has had any issues.
Hi,
I'm testing this library, it seems nice but I have a problem regarding voltage values that are given.
My battery is rated 24V, the epsolar is correctly set at 24V ("Charging equipment rated output voltage = 24.0V").
But the subsequent voltage values are all 12V based, examples:
Do you know where it could come from (everything is reported correctly by the MT-50)
Thanks :)
vanillax@raspberrypi:~ $ git clone https://github.com/kasbert/epsolar-tracer.git
Cloning into 'epsolar-tracer'...
remote: Enumerating objects: 163, done.
remote: Counting objects: 100% (55/55), done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 163 (delta 29), reused 38 (delta 19), pack-reused 108
Receiving objects: 100% (163/163), 665.92 KiB | 1.84 MiB/s, done.
Resolving deltas: 100% (83/83), done.
vanillax@raspberrypi:~ $ ls
Bookshelf Desktop Documents Downloads epsolar-tracer Music Pictures Public Templates Videos
vanillax@raspberrypi:~ $ cd epsolar-tracer/
vanillax@raspberrypi:~/epsolar-tracer $ ls
archive img info.py LICENSE linux_usb_serial pyepsolartracer readall.py README.md test xr_usb_serial_common-1a
vanillax@raspberrypi:~/epsolar-tracer $ cd xr_usb_serial_common-1a/
vanillax@raspberrypi:~/epsolar-tracer/xr_usb_serial_common-1a $ ls
dkms.conf Makefile README.txt xr_usb_serial_common.c xr_usb_serial_common.h xr_usb_serial_hal.c xr_usb_serial_ioctl.h
vanillax@raspberrypi:~/epsolar-tracer/xr_usb_serial_common-1a $ make
make -C /lib/modules/5.15.45-v8+/build M=/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a
make[1]: Entering directory '/usr/src/linux-headers-5.15.32-v8+'
CC [M] /home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.o
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_ctrl_irq’:
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c:261:21: warning: unused variable ‘tty’ [-Wunused-variable]
261 | struct tty_struct *tty;
| ^~~
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_process_read_urb’:
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c:393:21: warning: unused variable ‘tty’ [-Wunused-variable]
393 | struct tty_struct *tty;
| ^~~
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_softint’:
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c:468:21: warning: unused variable ‘tty’ [-Wunused-variable]
468 | struct tty_struct *tty;
| ^~~
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_reset_resume’:
/home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c:1634:21: warning: unused variable ‘tty’ [-Wunused-variable]
1634 | struct tty_struct *tty;
| ^~~
MODPOST /home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/Module.symvers
CC [M] /home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.mod.o
LD [M] /home/vanillax/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.ko
make[1]: Leaving directory '/usr/src/linux-headers-5.15.32-v8+'
vanillax@raspberrypi:~/epsolar-tracer/xr_usb_serial_common-1a $ sudo ./xr_usb_serial_common.ko
sudo: ./xr_usb_serial_common.ko: command not found
vanillax@raspberrypi:~/epsolar-tracer/xr_usb_serial_common-1a $ ls
dkms.conf Module.symvers xr_usb_serial_common.h xr_usb_serial_common.mod.c xr_usb_serial_hal.c
Makefile README.txt xr_usb_serial_common.ko xr_usb_serial_common.mod.o xr_usb_serial_ioctl.h
modules.order xr_usb_serial_common.c xr_usb_serial_common.mod xr_usb_serial_common.o
vanillax@raspberrypi:~/epsolar-tracer/xr_usb_serial_common-1a $ sudo insmod xr_usb_serial_common.ko
insmod: ERROR: could not insert module xr_usb_serial_common.ko: Invalid module format
vanillax@raspberrypi:~/epsolar-tracer/xr_usb_serial_common-1a $
Hello,
I want to read device data through modbus (TTL-RS485 module) communication using raspberry pi for this I write this python code.
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
import pymodbus
import serial
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(15, GPIO.OUT)
from pymodbus.client.sync import ModbusSerialClient as ModbusClient
client = ModbusClient(method='rtu', port='/dev/ttyAMA0', timeout=1, stopbits = 1, bytesize = 8, parity='N', baudrate= 38400)
client.connect()
while True:
temp = client.read_holding_registers(address=1, count=1, unit=1);
print temp.registers[0] / 100;
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
When i run this code i getting error..
True
Traceback (most recent call last):
File "pro.py", line 14, in
temp = client.read_input_registers(address=1009, count=2, unit=0x01);
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/common.py", line 125, in read_input_registers
return self.execute(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 108, in execute
return self.transaction.execute(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 140, in execute
full=full
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 207, in _transact
size = self._send(packet)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 224, in _send
return self.client.framer.sendPacket(packet)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/framer/rtu_framer.py", line 276, in sendPacket
size = self.client.send(message)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 77, in send
return self._send(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 512, in _send
waitingbytes = self._in_waiting()
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 494, in _in_waiting
waitingbytes = getattr(self.socket, in_waiting)()
File "/home/pi/.local/lib/python2.7/site-packages/serial/serialutil.py", line 590, in inWaiting
return self.in_waiting
File "/home/pi/.local/lib/python2.7/site-packages/serial/serialposix.py", line 467, in in_waiting
s = fcntl.ioctl(self.fd, TIOCINQ, TIOCM_zero_str)
IOError: [Errno 25] Inappropriate ioctl for device
I wrote a datalogger in Python (using Pymodbus) which stores the data from my EPSolar Charge Controller in a SQLite3 database. The connection between my PC and the EP LS1024B is a EPSolar USB UART cable CC-USB-TTL-150. On my Windows-PC everything is working fine.
I try to port this to my RaspberryPi3 (linux version 4.4.38-v7+) but until now without success. I am not able to get a connection between my RPi and the LS1024. Based on a Internet search I presume that the problem is caused by a wrong driver. My RPi sees the cable on ttyACM0 and uses the cdc-acm driver. The search learned me that the xr_usb_serial_common is the correct driver so I downloaded the source files .
But I can not get a .ko file with the make command. I get as error "#include <linux/init.h> file or map doesn't exist". I installed raspberrypi-kernel-headers and copied all the files to several places but without success.
Can you explain me what to do to get a .ko file from the driver?
I apologize if this is the wrong place to post this, but I don't know where else I might find other users of these charge controllers. Let me know if this is too off-topic, or if anyone knows of a better place to post.
I have 900 watts of panels (three 300 watt @ 36 volt panels) going into a Tracer 4210A 40 amp charge controller. That's connected to 4 Trojan T-105 batteries wired for 12 volts (450 amp hours). I recently set up a logging system using the excellent code here and I'm never getting more than 32 amps @ 14.5 volts to the battery (about 460 watts). As the sun is going up my output will rise until it levels off at 32 amps.
That's pretty close to 40 amps at 12 volts though (480 watts), so I'm wondering if the specs are a bit misleading? Shouldn't I be seeing 40 amps even when it's outputting 14.5 volts (580 watts)? Or is it in fact limiting the watts to 480 and calculating how many amps that would be at 12v?
It's not the biggest deal and I'm still really happy with this charge controller even after a year of heavy use, but I'm just wondering if anyone else is having this experience. And I also wonder whether for example the Morning Star MPPT 45 outputs a true 45 amps (even at 14.5 volts) or is also limited in this way.
(And on a sidenote, according to page 10 of the manual we can connect up to 1550 watts of panels to this controller).
http://www.epsolarpv.com/en/uploads/news/201710/1508812885787574.pdf
I have tryed to compile on centos 7 with kernel 3.10.
tty_port_initialized not found
It possible deploy a .ko ?
thanks
I can't get this driver to install at all.
When I run make. I get the following error.
pi@openplotter:~/xr_usb_serial_common-1a $ make
make -C /lib/modules/4.9.35-v7+/build M=/home/pi/xr_usb_serial_common-1a
make[1]: Entering directory '/lib/modules/4.9.35-v7+/build'
make[1]: *** No targets specified and no makefile found. Stop.
make[1]: Leaving directory '/lib/modules/4.9.35-v7+/build'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2
Do these drivers actually work??
I'm seeing fairly flaky behavior; info.py gets some info but then fails:
ReadDeviceInformationResponse(1)
Manufacturer: 'EPsolar Tech co., Ltd'
Model: 'Tracer4215BN'
Version: 'V02.14+V07.24'
Charging equipment rated input voltage = 150.0V
WARNING:pymodbus.client.sync:cleanup recv buffer before send: 0x3 0x0 0x15 0x45 0x50 0x73 0x6f 0x6c 0x61 0x72 0x20 0x54 0x65 0x63 0x68 0x20 0x63 0x6f 0x2e 0x2c 0x20 0x4c 0x74 0x64 0x1
Traceback (most recent call last):
File "info.py", line 30, in <module>
value = client.read_input(reg.name)
File "/home/joey/tmp/epsolar-tracer/pyepsolartracer/client.py", line 52, in read_input
response = self.client.read_input_registers(register.address, register.size, unit = self.unit)
File "/usr/lib/python2.7/dist-packages/pymodbus/client/common.py", line 120, in read_input_registers
return self.execute(request)
File "/usr/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 85, in execute
return self.transaction.execute(request)
File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 140, in execute
self.client.framer.processIncomingPacket(result, self.addTransaction)
File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 654, in processIncomingPacket
self._process(callback, error=True)
File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 679, in _process
result = self.decoder.decode(data)
File "/usr/lib/python2.7/dist-packages/pymodbus/factory.py", line 223, in decode
return self._helper(message)
File "/usr/lib/python2.7/dist-packages/pymodbus/factory.py", line 245, in _helper
response.decode(data[1:])
File "/usr/lib/python2.7/dist-packages/pymodbus/other_message.py", line 319, in decode
self.message_count = struct.unpack('>H', data[5:7])[0]
struct.error: unpack requires a string argument of length 2
Looking at line 319 there, data
contained "Tracer", so seems was not as long as expected, or possibly not the expected value at all.
So, I tried commenting out parts of info.py, and it seems some queries work reliably. Only running the loop to display the coils works every time without errors.
The "cleanup recv buffer before send" occurs as shown above, but also often when running the loop to display the registers. An example of the error there:
Charging equipment rated input voltage = 150.0V
WARNING:pymodbus.client.sync:cleanup recv buffer before send: 0x16 0x18
Charging equipment rated input current = 40.0A
<hang>
What seems to work fairly reliably is requesting only a few values:
response = client.read_input("Charging equipment input voltage")
print str(response)
response = client.read_input("Charging equipment input current")
print str(response)
But even then, same warning message sometimes:
Charging equipment input voltage = 57.82V
WARNING:pymodbus.client.sync:cleanup recv buffer before send: 0xa2 0x1d
Charging equipment input current = 1.97A
And if I request a third value, it often hangs.
I'm using a JBtek USB to RS485 adaptor. Have the same problems with both my laptop and a cubietruck board.
Hi, anyone succeded to write values ? I'd like to be able to control the load status. Thank you
RPi-3B/Raspbian Bullseye Full, updated and upgraded.
make
make -C /lib/modules/5.15.56-v7+/build M=/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a
make[1]: Entering directory '/usr/src/linux-headers-5.15.56-v7+'
CC [M] /var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.o
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_ctrl_irq’:
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c:261:21: warning: unused variable ‘tty’ [-Wunused-variable]
261 | struct tty_struct *tty;
| ^~~
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_process_read_urb’:
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c:393:21: warning: unused variable ‘tty’ [-Wunused-variable]
393 | struct tty_struct *tty;
| ^~~
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_softint’:
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c:468:21: warning: unused variable ‘tty’ [-Wunused-variable]
468 | struct tty_struct *tty;
| ^~~
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c: In function ‘xr_usb_serial_reset_resume’:
/var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.c:1634:21: warning: unused variable ‘tty’ [-Wunused-variable]
1634 | struct tty_struct *tty;
| ^~~
MODPOST /var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/Module.symvers
CC [M] /var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.mod.o
LD [M] /var/www/html/epsolar-tracer-kaspbert/xr_usb_serial_common-1a/xr_usb_serial_common.ko
make[1]: Leaving directory '/usr/src/linux-headers-5.15.56-v7+'
Hi, firstly thank you so much for putting this on github. I have been having a play with my tracer controller and it works great! One issue I have is that I would like the "load" to turn on and off at a certain time. However I assume this will need adjusting for daylight savings so I have been trying to do this remotely / automatically. I can successfully read the real time clock 1,2 & 3 but I cant for the life of me figure out how they represent the time / date. The description says seconds / minutes, hour / day etc but I dont really understand the results. e.g rtc1=6441 rtc2=2062 rtc3=3850 should be approx 2:30pm 8/10/15. Any light you could shed would be very gratefully received.
Additionally my issue is that I would need to change the time back one hour, I can successfully use the "write_output" command for other registers but it doesnt seem to have any effect when I use it on the rtc. The write_output command doesnt fail - no errors, it just doesnt change the result. I assume that this is because all the rtc commands must be changed simultaneously but its not very clear how to do that as write_output will only accept one argument.
Many thanks for any help you can give.
I am running Raspberry Pi with Kernel 4.14.29-v7+ and I was able to get the 1b version of this driver from the Exar website since I am running a newer version of the kernel than the 1a version is for.
I am able to compile and install the driver and even able to load it for the device, having it create the /dev/ttyXRUSB0 device. But when I run the test programs, I get the following in dmesg - any advice?
[165443.591667] tty ttyXRUSB0: xr_usb_serial_tty_install
[165443.591733] tty ttyXRUSB0: xr_usb_serial_tty_open
[165443.591746] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_port_activate
[165443.592008] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_ctrl_msg - rq 0x22, val 0x3, len 0x0, result -32
[165443.592028] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_ctrl_irq - urb shutting down with status: -2
[165443.592589] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_set_reg Error:-32
[165443.592822] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_set_reg Error:-32
[165443.592945] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_set_reg Error:-32
[165443.593069] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_set_reg Error:-32
[165443.593194] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_set_reg Error:-32
[165443.593320] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_set_reg Error:-32
[165443.593445] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_set_reg Error:-32
[165449.607737] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_tty_close
[165449.607770] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_port_shutdown
[165449.608029] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_ctrl_msg - rq 0x22, val 0x0, len 0x0, result -32
[165449.608151] cdc_xr_usb_serial 1-1.4:1.0: xr_usb_serial_tty_cleanup
Just found a problem I was having.
The existing driver works with Epever Triron4210N.
The Triron is a plugin replacement for the Tracer3210A.
UPDATE: I'm getting skips or partial reads in readings before the sun is up. Skips have indicated a too fast data rate , in the past.
Checking into the issue.
Currently suspect an update to PHP 7.4.
I have the standard epever rs485 cable, and it worked fine in windows. But I switched over to linux and can't work this out. The main issue is an extremely important piece of equipment also uses cdc-acm. So Im under the impression that if I blacklist that driver that other device won't work. Is there anything else I can do? I saw another post where someone posted a different RS-485 to USB unit that uses FTDI. But in that case Id need to make a cable so. In addition to the first question above, anyone have the pinout of the RJ45 jack?
Thanks.
Bryan
sudo insmod ./xr_usb_serial_common.ko
cat /etc/modprobe.d/bl.cdc_acm.conf
blacklist cdc_acm
tail -f / var / log / syslog -n 0 1.txt
help
As listed here, the latest is version 1B, with a few small bugfixes.
Hi there,
I am trying to run your code on a Pi Zero W with the latest version of Raspian Stretch
However, when I run this code
#################################
#!/usr/bin/env python
from pymodbus.client.sync import ModbusSerialClient as ModbusClient
client = ModbusClient(method = 'rtu', port = '/dev/ttyAMA0', baudrate = 115200)
client.connect()
while True:
result = client.read_input_registers(0x03, 1, unit=1)
print result
client.close()
###############################
it returns this error
###############################
Traceback (most recent call last):
File "./test.py", line 9, in
result = client.read_input_registers(0x03, 1, unit=1)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/common.py", line 125, in read_input_registers
return self.execute(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 107, in execute
return self.transaction.execute(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 136, in execute
full=full
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 202, in _transact
size = self._send(packet)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/transaction.py", line 219, in _send
return self.client.framer.sendPacket(packet)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/framer/rtu_framer.py", line 272, in sendPacket
size = self.client.send(message)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 76, in send
return self._send(request)
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 491, in _send
waitingbytes = self._in_waiting()
File "/home/pi/.local/lib/python2.7/site-packages/pymodbus/client/sync.py", line 473, in _in_waiting
waitingbytes = getattr(self.socket, in_waiting)()
File "/home/pi/.local/lib/python2.7/site-packages/serial/serialutil.py", line 590, in inWaiting
return self.in_waiting
File "/home/pi/.local/lib/python2.7/site-packages/serial/serialposix.py", line 467, in in_waiting
s = fcntl.ioctl(self.fd, TIOCINQ, TIOCM_zero_str)
IOError: [Errno 25] Inappropriate ioctl for device
#############################
i'd be most grateful for any advise on how to solve this
Hi there
I was wondering if it was possible to get multiple values using one request from the Tracer? I don't know if this is normal, but my Raspberry Pi takes about 4 seconds per each data request. I need 5 values from the Tracer, so the whole process takes about 16 seconds.
Is this a restriction in the pymodbus library, the Tracer itself, or your code? My data monitor is here: www.solarpoweredhome.co.uk - but as you may notice I can only get 4 complete sets of data per minute due to the time each request takes.
Thanks for your work
Matt
Dear Kasbert
I try to use your tracer, but i receive this error:
python readall.py
{0: 'EPsolar Tech co., Ltd', 1: 'Tracer1210A', 2: 'V01.10+V02.11'}
<pyepsolartracer.registers.Register instance at 0x767cbaf8>
read_input_registers: 10000
read_holding_registers: Exception Response(131, 3, IllegalAddress)
Do u have any idea about this ?
best regards
csaba
# make
make -C /lib/modules/6.1.32-v8+/build M=/home/pi/src/epsolar-tracer/xr_usb_serial_common-1a
make[1]: Entering directory '/usr/src/linux-headers-6.1.21+'
CC [M] /home/pi/src/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.o
In file included from ./include/linux/types.h:6,
from ./include/linux/limits.h:6,
from ./include/linux/kernel.h:16,
from /home/pi/src/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.c:37:
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
5 | #include <asm/types.h>
| ^~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:250: /home/pi/src/epsolar-tracer/xr_usb_serial_common-1a/xr_usb_serial_common.o] Error 1
make[1]: *** [Makefile:2012: /home/pi/src/epsolar-tracer/xr_usb_serial_common-1a] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.1.21+'
make: *** [Makefile:9: all] Error 2
It build successfully on Raspian Buster, so I don't know what changed between versions.
Modbus protocol link in readme file (https://www.solar-elektro.cz/data/dokumenty/1733_modbus_protocol.pdf) is currently broken.
Good day,
Please I need help in fixing the error below. I got it while I run: # dkms build -m xr_usb_serial_common -v 1a
"Error! echo
Your kernel headers for kernel 6.1.19-v8+ cannot be found at
/lib/modules/6.1.19-v8+/build or /lib/modules/6.1.19-v8+/source.
You can use the --kernelsourcedir option to tell DKMS where it's located."
I have ran update. Please I don't know how i fix this.
Thank you
hey guys, please help me to solve this problem
i have code
from pymodbus.client.sync import ModbusSerialClient as ModbusClient
from pymodbus.client.sync import ModbusSerialClient as ModbusClient
client = ModbusClient(method = 'rtu', port = '/dev/ttyACM0', baudrate = 115200)
client.connect()
result = client.read_input_registers(0x3100,1,unit=1)
print("result = ")
print (result)
solarVoltage = float(result.registers[0] /100.0)
solarCurrent = float(result.registers[1] /100.0)
batteryVoltage = float(result.registers[4] /100.0)
chargeCurrent = float(result.registers[5] /100.0)
print("solar voltage : ",solarVoltage)
print("solar current : ",solarCurrent)
print("battery volatage : ",batteryVoltage)
print("charge current : ",chargeCurrent)
client.close()
when i run this code, i get error like this
result =
Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 2 bytes (0 received)
Traceback (most recent call last):
File "yutub.py", line 9, in
solarVoltage = float(result.registers[0] /100.0)
AttributeError: 'ModbusIOException' object has no attribute 'registers'
i use epever tracer1210A
can anybody can help me to fix this problem?
thanks :)
hello dear friend!
looking at
8c21f4a
could you please tell where you got this value for 485 mode?
gpio_mode = 0x0b;
this patch of yours saved me quite a bit of health and time, so thanks. still curious about where you got that information?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.