Just purchased EG4 16kPV, Thank you for all of your effort!

[aviateur17]

Hey there, just purchased a EG4 16kPV and am looking forward to using some automation with the unit via Home Assistant and some building automation equipment. I first tried to integrate with some building automation equipment (Niagara JACE) and found out that the modbus protocol they use is non-standard and so I really appreciate you making this project. I'm using a raspberry pi 4 with a USB-485 adapter to communicate with the device. Just started a few hours ago so still trying to go through all of the modbus values and want to be able to write the time to the device as well as some other options so it's nice that you've implemented that option.
My full installation will be in 1-2 weeks.

Just wanted to say Hi and thanks. I'll probably be asking more questions as I delve in deeper.

[HotNoob]

o.O
cool. yes, software is more flexible than hardware :)

i think a few others wanted to write the date to their eg4 inverters.
should be some hints here if you havent already read it:
#39

[aviateur17]

So I have a few questions. Hope it's okay if I ask here. Let me know if you want me to ask in a different place.

1. I modified retries in modbus_base line 429. Would be nice to have that retries setting in the config file.

get registers(0): 0 to 39 (40)
get registers(1): 40 to 77 (38)
get registers(2): 80 to 119 (40)
get registers(3): 120 to 154 (35)
get registers(4): 161 to 193 (33)
get registers(5): 400 to 411 (12)
get registers(6): 994 to 999 (6)

2. In the output above, is there a way to know which registers (holding or input, and register number) are being read? Is there an easy way of cross referencing the number to the register being read from the device?
3. In the output above. what do the numbers, ie 994 to 999, mean? I assume they are basically just the line number in the holding and input cfg files?
4. I see the get registers cycles from 0 to 8 groups and then starts over 0 to 5 and then MQTT data is sent. What triggers the MQTT send? I would think once all of the modbus data is gathered then send the MQTT data but it seems to start another cycle and MQTT data is sent in the middle of the second cycle (after 5 of 8 groups of get registers). So is there a way to grab the 8 groups of data and then send MQTT then start the queries again? Not sure what triggers the MQTT send.

03:43:50 ERROR modbus_base:452 <bound method ExceptionResponse.__str__ of <pymodbus.pdu.ExceptionResponse object at 0x7fb853a990>>
Retry(1 - (1)) range(6)

5. I'm getting the error above on get registers groups 6, 7, and 8. I assume either the config file has bad data or registers don't exist in the device? The device sent some kind of exception when trying to read data from the registers?
6. I tried adjusting the read_interval value in the config file. Not sure exactly that setting is supposed to do? Does it throttle the delay between reading registers?
7. I had an Raspberry pi with older software and the log_level statements seemed to work properly. I updated the software on the Raspberry and now the log_level statements in config file do not seem to work. I assume there was some change in the newer versions of Python or some software. I'll see if I can investigate more but if you know why they would not work any longer please let me know. Looks like even though I have them set to debug there isn't much data being output to stdout.
8. In the eg4_v58 registry map files, the first parameter seems to be variable name but the majority of them are empty or do not have values. For those lines that are missing variable names, what do you put in the variable_mask or variable_screen files to mask or just include the single line?

Thanks!

[HotNoob]

1. should be done.
2. the register #'s being read are those numbers. the way modbus works, registers can be read individually, or in chunks.
   ie, 0 to 39, is reading register 0,1,2... all the way to 39. (x) = total number of registers being read.

(4.) there are two register "types" in modbus, so the first "loop" would be one register type, and then the 2nd would be the next type.
input / holding registers.

afterwards mqtt is sent.

yes, some devices do bug out / error out on some register ranges. most appear to be releated to values from other devices, such as battery bms info.

4/6. the "read_interval" setting triggers how often the registers are read and sent via mqtt.
there is also the limiting factor of how fast all of the modbus registers can be read.

there are some fine tuning options that i still have to document.
batch_delay would adjust the delay in between reading each batch/chunk of modbus registers.
batch_size changes the max batch size.

the devices themselves do have batch size limits and read interval limits, so delays can only be shortended so far.

7. the output / logs need a bit of work. to clean up ect... i fixed it a tiny bit today in the v1.1.6 branch.

variable name overwrites documented name. documented name is the name of the variable that is in the official documentation ( if any ).
variable name would be my attempt to normalize or interpret a better name.

variable or documented name can be used in the variable_mask or variable_screen files.
one variable per line.

on my todo list to implement an overrides file system for more precsise control of the protocols. in the meantime the mask/screen files or copying and making a "custom" protocol is the best way to control the registers.

[aviateur17]

the output / logs need a bit of work. to clean up ect... i fixed it a tiny bit today in the v1.1.6 branch.

now using the 1.1.6 branch the log_level seems to work again. Thanks!

[aviateur17]

4.) there are two register "types" in modbus, so the first "loop" would be one register type, and then the 2nd would be the next type.
input / holding registers. afterwards mqtt is sent.

Makes sense now. The 1.1.6 branch shows the register type (input vs holding) so that's a nice improvement.

[aviateur17]

the main README.md, line 69, need to add --config before config.cfg

lehman@raspberrypi ~/PythonProtocolGateway (main) [1]> python3 protocol_gateway.py config.cfg
usage: protocol_gateway.py [-h] [--config CONFIG]
protocol_gateway.py: error: unrecognized arguments: config.cfg

[HotNoob]

bde13ba
should do the trick. allow for both.

[aviateur17]

So when the device goes down it seems that there is a delay between queries (I assume error_interval setting in config.cfg), which is fine, however, when the device comes back and reads successfully it doesn't seem to go back to the read_interval - it seems to stay at the error_interval? I would assume that a successful read should then restore the interval to the read_interval and not stay at the error_interval.

[HotNoob]

PythonProtocolGateway/protocol_gateway.example.service

Line 11 in ed1d92f

RestartSec=30

decreasing this would reduce the restart time.

[HotNoob]

or now im confusing myself :P
it's supposed to restart... i wonder if i changed that...

[HotNoob]

uhgg, sorry i think that was the old behaviour. oops :P

yeah maybe it does get stuck.

[HotNoob]

198e408
this should fix things.

[aviateur17]

Thanks, I'll have to fetch and test out. I looked at the diff and not sure I understand what's happening but I assume you fixed it ;)