mismatch errors
Closed this issue · 9 comments
Hello, I downloaded the latest version of the branch on my raspberry pi 3 and it works, but we have not managed to make it work the right way.
I get the wrong values
multigraph in_batvolt
volt.value 0.00
multigraph in_batcharge
charge.value 0.00
multigraph in_batcurrent
current.value 0.00
multigraph in_batpower
power.value 0.00
multigraph in_mainscurrent
currentin.value 128.59
currentout.value -12.48
multigraph in_mainsvoltage
voltagein.value 207.35
voltageout.value 207.35
multigraph in_mainspower
powerin.value 26662.97
powerout.value -2586.85
multigraph in_mainsfreq
freqin.value 0.36
freqout.value 1.10
Is there any way to ask the investor only the securities I need?
For example, I want to consult only currents and the actual power, I see that with winmon commands you can query variables.
I was thinking of using py.serial by querying the current snapshot in the format indicated in the document (04 FF 'A' 01 00 BB), I have been reading but I still do not know if I am doing the right thing.
I assume the format is fine, but I don't want to fail my inverter when testing.
I don't quite understand how to make my new consultation to bring these values that I tell you.
Saludos my friend and thanks for your contribution
Hi,
Could you maybe add your expected values for the output you pasted? I am guessing this is on a multiplus II?
The driver tries to request all values for the inverter and publishes them, so you can't turn some off or on. It is however not requesting some of the values via the averaged memory snapshots but through other methods. The only value requested from memory is the battery charge. I can try to create a branch where all the values are requested from memory rather, this could simplify the code quite a bit as well.
Looking at the documentation again, it looks like the scale factors have 2 modes that it can be transferred as. So far I assumed only mode 1, but mode 2 is a bit more compact. See if this does anything for you and if you can paste your output https://github.com/diebietse/invertergui/tree/scale-mode
Hello
My apologies for the delay, I am actually wrong about the inverter model as it is a multiplus 1.
The inverter is working as ups, so the battery current should be at 0%, with a floating voltage of approx. 56.5V
The grid values should be approx:
• Output current: 48 Amps8 Amps
• Input current: 4
• Output voltage: 225V
• Input voltage: 225V
• Output frequency:50Hz
• Input frequency:50Hz
• Output power: 11.8 kw1.8 kw
• Input power: 1
I was planning to perform a Modbus-type query on the network values delivered by the inverter, however, that took a lot longer than I thought to understand the brand datasheet.
Again thank you very much for your help
Cordial greetings
Is this a system with multiple multiplus devices connected? This code assumes only a single device to query, not sure how multiple devices work.
The system works with a single 3k multiplus 1
In case of power failure, the system works as a backup and the mk3 device is connected directly to the USB on raspberry
This is my Output
Hi.
I have created a new branch at https://github.com/diebietse/invertergui/tree/scalefixes that rewrites part of the scale handling code to be closer to the Victron documentation. Can you see if this gives the correct values?
Also I have added debug logging for message parsing. Could you please send the output of
./invertergui --loglevel=debug --data.device=/dev/tty<victron device>
up to the first line that start with battery state decode.
Hello
I just tested the new branch and the interface works perfectly.
thanks! is a very fast sampling.
By means of the munin plugin when reloading the page the battery values , as well as the frequency, sometimes go to zero, although it is possibly a problem with the search engine.
I am using remote VNC. So I'll try to use direct scrapy in localhost directly on the pi
This is an image of right now working.
Muning plugin
Regarding the debug log, this is what returns;
^XDEBU[0003] frame []byte{0xff, 0x56, 0x1f, 0xdb, 0x11, 0x0, 0x0, 0x99}
DEBU[0003] versiondecode [31 219 17 0 0 153]
DEBU[0003] sendCommand []byte{0x3, 0xff, 0x46, 0x0, 0xb8}
DEBU[0003] frame []byte{0x20, 0xe6, 0x3f, 0xc8, 0x4, 0xc, 0xdd, 0x14, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x88, 0x5b}
DEBU[0003] dcDecode &mk2driver.Mk2Info{Valid:true, Version:0x10c8, BatVoltage:53.410000000000004, BatCurrent:0, InVoltage:0, InCurrent:0, InFrequency:0, OutVoltage:0, OutCurrent:0, OutFrequency:50.025510204081634, ChargeState:0, LEDs:map[mk2driver.Led]mk2driver.LEDstate(nil), Errors:[]error(nil), Timestamp:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}
DEBU[0003] sendCommand []byte{0x3, 0xff, 0x46, 0x1, 0xb7}
DEBU[0003] frame []byte{0x20, 0x1, 0x1, 0x5, 0x9, 0x8, 0x62, 0x54, 0x5, 0x3, 0x62, 0x54, 0xeb, 0x2, 0xc3, 0x95}
DEBU[0003] acDecode &mk2driver.Mk2Info{Valid:true, Version:0x10c8, BatVoltage:53.410000000000004, BatCurrent:0, InVoltage:216.02, InCurrent:7.73, InFrequency:50.1025641025641, OutVoltage:216.02, OutCurrent:7.47, OutFrequency:50.025510204081634, ChargeState:0, LEDs:map[mk2driver.Led]mk2driver.LEDstate(nil), Errors:[]error(nil), Timestamp:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}
DEBU[0003] sendCommand []byte{0x2, 0xff, 0x4c, 0xb3}
DEBU[0004] frame []byte{0xff, 0x4c, 0x9, 0x0, 0x0, 0x0, 0xa, 0x0, 0x9a}
DEBU[0004] sendCommand []byte{0x5, 0xff, 0x57, 0x30, 0xd, 0x0, 0x68}
DEBU[0004] frame []byte{0xff, 0x57, 0x85, 0xc8, 0x0, 0xb6, 0x54, 0x4c}
DEBU[0004] battery state decode &mk2driver.Mk2Info{Valid:true, Version:0x10c8, BatVoltage:53.410000000000004, BatCurrent:0, InVoltage:216.02, InCurrent:7.73, InFrequency:50.1025641025641, OutVoltage:216.02, OutCurrent:7.47, OutFrequency:50.025510204081634, ChargeState:1, LEDs:map[mk2driver.Led]mk2driver.LEDstate{0:1, 1:0, 2:0, 3:1, 4:0, 5:0, 6:0, 7:0}, Errors:[]error(nil), Timestamp:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}
I am glad to hear that you are now getting the correct values.
I have opened a new issue for munin sometimes showing 0's : #19
Issue now fixed and released on v2.0.2