physee / victron.arduino-esp8266 Goto Github PK

Thanks for sharing. Works great and same results as with usb serial.
But how to get the values from each day?

Like min/max battery voltage, charge state yield and so on, like the values in the official app shown.

I monitored serial usb connection when connecting to the app, but can´t find out how to receive this values.
Hope you have some tips for me.

It's not really an issue, but if there is at least 3 victron devices, the code take too much space in RAM. Is it possible to use only one read and parse functions block for more than one device ?

One should better avoid SoftwareSerial, which has massive performance problems at 19200 Baud.

The better solution is to use Serial.swap() once the ESP is initialized, which swaps the hardware UART on D7 / D8

Then one can "print" using TelnetSerial

Please look at my fork: https://github.com/rin67630/esp8266-victron-mppt-solarchargecontroller-Telnet

Regards.

Declaring an instance of SoftwareSerial on an ESP8266 affects interrupts and any WiFi communictions fail. See also here - is there a workaround for this? I assume most users of ESP8266 are using it for WiFi capabilities.

Any change to get it posting on emoncms.org??

I am trying to use this code to send data to Blynk as an output rather than serial.
The values seem to not update throughout most of the day.
Any ideas?
Thanks

Hi, why value_bytes is 33? As it is used in an 2D array, RAM left is very poor.

Could we use as 2 bytes and save values as INTs ?

Thanks a lot for your work.

Hello,

i'm trying to figure out why when increasing the print time from 1 second to 30 seconds i always get empty values. Any thoughts?

PS: 5 seconds, 10 or 15 seems ok.

I have a 75/10 that is apparently running a newer firmware and is sending 18 variables now. I was able to pull the data down on my Mac using a FTDI cable. Pretty sure my voltage divider is working (verified with voltmeter). I updated the config.h to include the changes, but while I get keywords printed out on the serial monitor, there are no values being shown.

Ideas?

output from FTDI

PID 0xA054 FW 159 SER# HQ21052GGUP V 13130 I 0 VPV 10 PPV 0 CS 0 MPPT 0 OR 0x00000001 ERR 0 LOAD ON IL 0 H19 0 H20 0 H21 0 H22 0 H23 0 HSDS 0 Checksum G

updated config.h

`#ifdef MPPT_75_10

const byte buffsize = 32;
const byte value_bytes = 33;
const byte label_bytes = 9;
const byte num_keywords = 20;

char keywords[num_keywords][label_bytes] = {
"PID",
"FW",
"SER#",
"V",
"I",
"VPV",
"PPV",
"CS",
"MPPT",
"OR",
"ERR",
"LOAD",
"IL",
"H19",
"H20",
"H21",
"H22",
"H23",
"HSDS",
"Checksum"
};
#define PID 0
#define FW 1
#define SER 2 // Offically SER# but # does not play that well as macro
#define V 3 // ScV
#define I 4 // ScI
#define VPV 5 // PVV
#define PPV 6 // PVI = PVV / VPV
#define CS 7 // ScS
#define MPPT 8 // MPPT
#define OR 9 // OR
#define ERR 10 // ScERR
#define LOAD 11 // SLs
#define IL 12 // SLI
#define H19 13
#define H20 14
#define H21 15
#define H22 16
#define H23 17
#define HSDS 18
#define CHECKSUM 19
#endif`

strcpy(recv_label[blockindex], strtokIndx); // copy it to label
The code stops on the ESP8266 at line 96 after some debugging.
WHY?

hi, i have a 100/50 controller that i want to use, but not sure how to, or if i need to set up the config file differently.

can anyone offer any assistance with this?

This code is simple and elegant, however it is prone to buffer overflows because it blindly trust Serial inputs coming from the VE.Direct device.
The two weaknesses are:

1. When parsing the data, the blockindex counter is not limited in any way, and there are conditions where it could exceed recv_label and recv_value arrays, leading to array overflow and undefined behaviour (it is really sneaky and took me weeks to figure it out)
2. use of strcpy functions instead of safer strlcpy functions

I suggest to add a check before copying strings into the arrays, and use strlcpy to do so

if(blockindex < num_keywords) {
       strlcpy(recv_label[blockindex], strtokIndx,sizeof(recv_label[blockindex])-1);
}

if(blockindex < num_keywords) {
          strlcpy(recv_value[blockindex], strtokIndx,sizeof(recv_value[blockindex])-1);
} 

Additionally, in the data parsing function, when checksum control is passed, set blockindex counter to the num_keywords - 1 number if it exceed that, otherwise this may lead to another array overflow in the value array

if(blockindex >= num_keywords) blockindex = num_keywords - 1;

Yes, we may lose data this way, but VE.Direct data is sent every second, so it would be quickly restored, and more importantly, the program doesn't get into undefined behavior.

Works with:

• Firmware 1.5
• Firmware 1.5.6

I have a MPPT 75/15 Bluesolar with newest FW 1.56.
Sadly I had to bypass the
"if (!checksum)" part, because the checksum was never 0, in fact it is always calculated wrong and 3 higher than the MPPTs transmitted checksum.

Example:
If the serially transmitted checksum by the MPPT is 66, the calculated checksum is 69.
If the serially transmitted checksum by the MPPT is 61, the calculated checksum is 64.
etc.

That is quite strange, as there don't seem to be any errors during transmission....those values are not fluctuating.