All in One support?

[mydliar]

Hi,

This looks like a great project, exactly what I need. I just had my GivEnergy All in One system installed. Is All in One model supported though? I can see the 'INEVRTOR_AIO_1' environment variable, and 'AllinOne' model in the givenergy_modbus library, but I don't seem to be able to get a valid response from the inverter, regardless whether I set it to True or False.

Running giv_tcp in Docker on Synology NAS.

The log keeps logging in a loop:

2023-07-26 16:47:50,126 - Inv1 - read        -  [DEBUG   ] - ----------------------------Starting----------------------------
2023-07-26 16:47:50,127 - Inv1 - read        -  [DEBUG   ] - Getting All Registers
2023-07-26 16:47:50,127 - Inv1 - read        -  [DEBUG   ] - Connecting to: 192.168.1.36
2023-07-26 16:47:50,128 - Inv1 - queue       -  [DEBUG   ] - Pushed job 82b86077-add2-48ca-978e-e44281a7201f into GivTCP_1
2023-07-26 16:47:50,472 - Inv1 - sync        -  [DEBUG   ] - Connection to Modbus server established. Socket ('192.168.1.12', 47791)
2023-07-26 16:47:50,473 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - IDLE
2023-07-26 16:47:50,474 - Inv1 - transaction -  [DEBUG   ] - Running transaction 1
2023-07-26 16:47:50,476 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:50,724 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:50,729 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:50,734 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 1
2023-07-26 16:47:50,737 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:51,242 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:51,243 - Inv1 - transaction -  [DEBUG   ] - Running transaction 2
2023-07-26 16:47:51,244 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:51,474 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:51,476 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:51,477 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 2
2023-07-26 16:47:51,485 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:51,986 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:51,987 - Inv1 - transaction -  [DEBUG   ] - Running transaction 3
2023-07-26 16:47:51,988 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:52,234 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:52,235 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:52,237 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 3
2023-07-26 16:47:52,237 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:52,739 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:52,741 - Inv1 - transaction -  [DEBUG   ] - Running transaction 4
2023-07-26 16:47:52,742 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:52,974 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:52,976 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:52,977 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 4
2023-07-26 16:47:52,977 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:53,479 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:53,482 - Inv1 - transaction -  [DEBUG   ] - Running transaction 5
2023-07-26 16:47:53,484 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:53,714 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:53,715 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:53,716 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 5
2023-07-26 16:47:53,717 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:54,237 - Inv1 - queue       -  [DEBUG   ] - Starting BLPOP operation for queues rq:queue:GivTCP_1 with timeout of 405
2023-07-26 16:47:54,672 - Inv1 - read        -  [ERROR   ] - Consecutive failure count= 11 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'ValueError'>, ValueError('hour must be in 0..23'), <traceback object at 0x7feb490da7c0>)"), <traceback object at 0x7f9cb57d4940>)
2023-07-26 16:47:54,675 - Inv1 - read        -  [ERROR   ] - 10 failed inverter reads in a row so removing regCache to force update... 

Any advice would be greatly appreciated.

Martin

[britkat1980]

To make it work you need to set the number of batteries to 0. The new battery needs reverse engineering and I haven't completed it yet. You can still see SOC and control the battery, just can't see the cell level data

[britkat1980]

Also, the error is around the times. If you look at the GE portal and reset all times to something sensible, that will force it to a "proper" value and it will then spring into life

[britkat1980]

2.3.0 is now out so closing this (noting battery stats are still needed)