Hi mate, try to set qpiri to 98 and the other to default value, if it works can you say to me how much time require to refresh your inverter value like W instant consumption.
Many thanks.
Andrea
Hi Guys,
There’s been some updates today so can you try and run it using the latest builds on docker hub (they now support multi architecture).
As for your issue @francois-dotnet
Can you try and change the following in your config:
(This seems to be the default for the 4/5kw versions)
qpiri=98
qpiws=36
qmod=5
qpigs=110
@francois-dotnet Of nothing, you’re welcome, when you can let me know how often the data is updated between the inverter and Hass.IO
@ned-kelly Is there a way to make more push notification, so I can have more data polling?
I set mine to every 15 seconds and for that you have to update two files:
-
sources/inverter-mqtt/entrypoint.shon the last command to push using the watch command to run every 15 secs instead of 30watch -n 15 /opt/inverter-mqtt/mqtt-push.sh > /dev/null 2>&1 -
config/inverter.confon therun_intervalsetting to match your execution time as this is used to calculate your watt hour values if I still remember correctly
Thank you @wax911, I have already tried to adjust the threshold by acting on these two files, also by recompiling the docker-compose after the modification, but analyzing with mqtt-spy and other listening services I know that the notifications occur anyway with a variable frequency and very not constant.
I use even other device, like the Tasmota sensor, the transmit every 10s and are very reliable.
If you connect the inverter Via RS232 or USB or Eth-RS232 with WatchPower - Lucibus and some other software you can see the variations with a refresh rate of several milliseconds…logically I do not expect to get this kind of results, but already having an update every 5/10 seconds would be very useful in programming the automations.
1 Like
HI @tcapanna - As mentioned by @wax911, your best bet is to change the interval of the ‘watch’ command to every say 5 or 10 seconds - I set it to 30 by default so you don’t fill up your DB as it transmits a fair bit more data than a simple on/off state.
I think perhaps what might be smart is modifying the script to check if the data has changed (it could run every 1-2 seconds then) and only updating the MQTT topic if the data changed from the last time the script ran - This way you won’t be flooding HA with the same ‘previous value’ - Feel free to submit a PR if you want to try and implement it - If we do go down this route, we need to store the ‘previous state’ in memory and not a file on disk - so we don’t burn out our SD card’s in our PI’s.
Thank you @ned-kelly, of course it would be very interesting to implement the script in this way.
I have already tried to implement the watch command interval at 15 - 10 and 5 seconds, the result is that the transmissions are made in a completely inconstant timing and very random way, sometimes I have 2/3 consecutive transmissions at a distance of 15 seconds and maybe after 2/3 at a distance of one minute from each other.
I also tried to limit the number of data that is passed through the script, thinking that maybe it was too much and that’s why it couldn’t run it quickly, reducing it to about ten values, such as power consumption in Watts, V AC variation and a few others, but the problem persists.
I believe that the project you have created is unique and very, very useful for Inverter owners who can read the data clearly and easily directly in HA. However, at least for my home use, I need to be able to increase the number of transmissions in a regular way so that I can then act through the automations on the devices in the house.
I apologize for my English, which in many cases has some errors 
1 Like
I see what you mean. From the tests I’ve done the inverter_poller takes ~2 seconds on a Pi 4 running buster lite to poll from the inverter, while the module jq is pretty fast when called multiple times recreating an instance of itself each time results in an additional 3 ~ 5 seconds penalty in this particular case where we have to extract each property value from the output of inverter_poller.
Anyways I think it’s probably wise to first know how long each run takes to finish publishing on average since another bottle neck is probably the serial connection (I think all the voltronic inverters are limmited to a baud rate of 2400). In my case I know that each run takes ~7 - 8 seconds so I know that I can’t have the watch command invoking inverter_poller any faster than that. Perhaps using something like paho.mqtt or the existing mosqitto_pub directly in the application may yield better results but might require a significant amount of work
@wax911 For my tests I’m using a raspberry Pi 2, connected via USB - USB because as I said in my previous posts I couldn’t connect it via USB - Serial RS232, I can’t get back the values.
Anyway the problem is actually the lack of continuity when you lower the value at the watch command, the problem is also present if lowering the reading value at the serial, when all goes well there is a transmission every 15~20 seconds, it often freezes and makes a transmission after about one minute.
@wax911maybe the RS232 is more faster than the direct USB connection for value reading?
I could try with a USB to RS232 connection, but then as I said in the posts above I can’t get a reading of the values, in this way I could certainly have a definitive result…considering that software like WatchPower have a refresh rate of few seconds via USB - RS232 at that point the problem could be only in the script or in the mqtt client on the raspberry.
However, the problem is not having a refresh every 15 seconds, which may also be acceptable when having constant updates.It cannot be that every 2/3 updates of 15 seconds there is a block for 1 minute before the next transmission.
> # Use: /dev/ttyS0 if you have a serial device,
> # /dev/ttyUSB0 if a USB<>Serial,
> # /dev/hidraw0 if you're connecting via the USB port on the inverter.
>
> device=/dev/ttyUSB0
>
> # How many times per hour is the program going to run...
> # This is used to calculate the PV & Load Watt Hours between runs...
> # If unsure, leave as default - it will run every minute...
>
> # (120 = every 30 seconds)...
> run_interval=1
>
> # This allows you to modify the amperage in case the inverter is giving an incorrect
> # reading compared to measurement tools. Normally this will remain '1'
> amperage_factor=1.0
>
> # This allows you to modify the wattage in case the inverter is giving an incorrect
> # reading compared to measurement tools. Normally this will remain '1'
> watt_factor=1.01
>
>
> # The following settings allow you to modify runtime buffers.
> # N.B. These values may not be applicable to all inverter types, as such you will
> # need t
> Sat Apr 4 15:10:42 2020 INVERTER: Current CRC: B7 A9
> Sat Apr 4 15:10:45 2020 INVERTER: QPIGS read timeout
> Sat Apr 4 15:10:45 2020 INVERTER: QPIGS reply too short (9 bytes)
> Sat Apr 4 15:10:45 2020 INVERTER: Current CRC: F8 54
> Sat Apr 4 15:10:48 2020 INVERTER: QPIRI read timeout
> Sat Apr 4 15:10:48 2020 INVERTER: QPIRI reply too short (1 bytes)
> Sat Apr 4 15:10:48 2020 INVERTER: Current CRC: B4 DA
> Sat Apr 4 15:10:51 2020 INVERTER: QPIWS read timeout
> Sat Apr 4 15:10:51 2020 INVERTER: QPIWS reply too short (6 bytes)
> Sat Apr 4 15:10:56 2020 INVERTER: Current CRC: 49 C1
> Sat Apr 4 15:10:56 2020 INVERTER: QMOD reply size (5 bytes)
> uration options for the actual inverter polling process...top bytes. Buffer: (NAKs�
>
> # The device to read from...
> # Use: /dev/ttyS0 if you have a serial device,
> # /dev/ttyUSB0 if a USB<>Serial,
> # /dev/hidraw0 if you're connecting via the USB port on the inverter.
>
> device=/dev/ttyUSB0
>
> # How many times per hour is the program going to run...
> # This is used to calculate the PV & Load Watt Hours between runs...
> # If unsure, leave as default - it will run every minute...
>
> # (120 = every 30 seconds)...
> run_interval=1
>
> # This allows you to modify the amperage in case the inverter is giving an incorrect
> # reading compared to measurement tools. Normally this will remain '1'
> amperage_factor=1.0
>
> # This allows you to modify the wattage in case the inverter is giving an incorrect
> # reading compared to measurement tools. Normally this will remain '1'
> watt_factor=1.01
>
>
> # The following settings allow you to modify runtime buffers.
> # N.B. These values may not be applicable to all inverter types, as such you will
> # need t
> Sat Apr 4 15:10:56 2020 INVERTER: Current CRC: B7 A9
The problem here is that the inverter can take time to respond on some commands - which is why it takes a while for you to get the results… Your best bet might be to check your firmware versions and upgrade it if you’re using an older firmware version since I remember it being a bit buggy when making the status queries.
That’s not entirely true - Watchpower only gets the main status query every few seconds and other commands such as the system cutoff voltage, battery float levels etc are not fetched in the same query - From memory it’s only the qpiri command that’s fetched every second or so…
You’re going to have to modify the code to only return the qpiri command, and not qpiws, qmod, and qpigs - Which technically should make the whole process 3-4x faster than it currently is.
Hope that helps.
Thanks for the information, it seems to me that I have to intervene both on main.cpp and inverter.cpp to make them read only the string related to the QPIRI, is that correct?
Hi Ned, thanks for this! I am running a 2.4kW 24v version of this inverter. It reads into WatchPower as well. Got my installation up and running and now looking at output from
sudo docker exec -it voltronic-mqtt bash -c ‘/opt/inverter-cli/bin/inverter_poller -d -1’
giving me this
Wed Apr 8 12:25:53 2020 INVERTER: Current CRC: B7 A9
Wed Apr 8 12:25:56 2020 INVERTER: QPIGS read timeout
Wed Apr 8 12:25:56 2020 INVERTER: QPIGS reply too short (7 bytes)
Wed Apr 8 12:25:56 2020 INVERTER: Current CRC: F8 54
Wed Apr 8 12:25:59 2020 INVERTER: QPIRI read timeout
Wed Apr 8 12:25:59 2020 INVERTER: QPIRI reply too short (7 bytes)
Wed Apr 8 12:25:59 2020 INVERTER: Current CRC: B4 DA
Wed Apr 8 12:26:02 2020 INVERTER: QPIWS read timeout
Wed Apr 8 12:26:02 2020 INVERTER: QPIWS reply too short (7 bytes)
Wed Apr 8 12:26:07 2020 INVERTER: Current CRC: 49 C1
Wed Apr 8 12:26:07 2020 INVERTER: QMOD reply size (5 bytes)
configuration options for the actual inverter polling process…tes. Buffer: (NAKs?
I have changed values on inverter.conf to:
qpiri=7
qpigs=7
qpiws=7
qmod=5
Used sudo docker-compose down and then sudo docker-compose up --build -d but still getting the same messages.
Yep correct
Can you try and set it to the following for the 24v version:
qpiri=97
# This allows you to modify the buffersize for the qpiws command
qpiws=36
# This allows you to modify the buffersize for the qmod command
qmod=5
# This allows you to modify the buffersize for the qpigs command
qpigs=110
Still the same result:
Thu Apr 9 08:32:05 2020 INVERTER: Current CRC: B7 A9
Thu Apr 9 08:32:08 2020 INVERTER: QPIGS read timeout
Thu Apr 9 08:32:08 2020 INVERTER: QPIGS reply too short (7 bytes)
Thu Apr 9 08:32:08 2020 INVERTER: Current CRC: F8 54
Thu Apr 9 08:32:11 2020 INVERTER: QPIRI read timeout
Thu Apr 9 08:32:11 2020 INVERTER: QPIRI reply too short (7 bytes)
Thu Apr 9 08:32:11 2020 INVERTER: Current CRC: B4 DA
Thu Apr 9 08:32:14 2020 INVERTER: QPIWS read timeout
Thu Apr 9 08:32:14 2020 INVERTER: QPIWS reply too short (7 bytes)
Thu Apr 9 08:32:19 2020 INVERTER: Current CRC: 49 C1
Thu Apr 9 08:32:19 2020 INVERTER: QMOD reply size (5 bytes)
NAKsspr 9 08:32:19 2020 INVERTER: QMOD: incorrect start/stop bytes. Buffer: (NAKs?
uration options for the actual inverter polling process...
This is what I see with a serial monitor:
QMODIÁ
(L…
QPIGS·©
(231.0 50.0 231.0 50.0 0000 0000 000 440 27.60 000 100 0368 0000 000.0 00.00 00000 10011101 03 08 00000 100º•
QPGS0?Ú
QPGS0?Ú
QPIWS´Ú
(00000000000000000000000000000000ëä
Hi @jaqkar,
Did you ever end up sorting this out?
Another thought - if you’re using Serial rather than USB, you may need to set the baud rate (You shouldn’t see those characters at the end of each line like you posted with the serial monitor) - Can you try running /dev/ttyUSB0 2400 raw (You may need to change the device if you’re not using a “serial2usb dongle”) and then restarting the docker container?
Cheers,
Got it working with 5048 inverter model. Setup is orange pi zero - armbian - usb<>serial. Had to change qpiri to 98.