aelias-eu / hewalex-geco-protocol

Protocol reverse engineering and simple communication tool for GECO G-422 range of solar pump controllers, used also (but not only) in the Hewalex ZPS-18e
MIT License
8 stars 7 forks source link

Fork with heat pump (G-422) support #1

Open mvdklip opened 3 years ago

mvdklip commented 3 years ago

Hi aelias-eu,

Just wanted to inform you that I made a fork of this repo to add G-422 / PCWU support. You can find the fork at https://github.com/mvdklip/hewalex-geco-protocol

Two questions:

1) Would you like me to issue a pull request so that you become the host for this repo again with both PCWU and ZPS support? Or would you like me to keep my own fork?

2) Why are you requesting three times 50 registers from the ZPS controller while requesting 50 registers from start address 120 seems to be enough?

Greets,

Matthijs

aelias-eu commented 3 years ago

Hi Matthijs, I started this just to get the data into my homeassistant and also to share my progress so it can help someone. If you are OK with that, we can go on with pull request and I can add you as a collaborator on this project - just to keep all the informations together. But if you wish to continue with your work separately, I have no problem with that.

I have two future plans with this:

As to your second question - It was just for "research" purposes - I was trying to identify the meaning of every single register that I could. And it just stayed there.

have a nice day Andrej

mvdklip commented 3 years ago

Hi Andrej,

Please take a look at the 'hewalex_geco' python package burried in my Domoticz plugin:

https://github.com/mvdklip/Domoticz-Hewalex/tree/master/hewalex_geco

I have just added loads of reverse engineered ZPS registers. It also contains functions for calculating CRC8 and CRC16 header values. It is based on work done by krzysztof1111111111 on the elektroda.pl forum.

Some interesting differences between PCWU and ZPS communication seem to be:

I am especially still looking for a ZPS register containing 'Electricity consumed by solar pump'. This should be the total electricity (kWh) based on the operation of the controller and the pump(s). Ekontrol reports this number but maybe it calculates this value by constantly monitoring register 148 (Consumption in Watts).

I have also thought of dropping all this in a small ESP based device but I'm not sure that is wise to do. Hewalex already makes and sells such a device and making your own would mean competing with them.

I'll accept your invitation to become a collaborator for the project. I was planning on adding PCWU support to the MQTT script as an example. I do not actually use MQTT myself so I cannot fully test it.

Greets,

Matthijs

aelias-eu commented 3 years ago

You did some fine work there. one thing though - I have identified the register # 154 as Digital Out status register.

        154: { 'type': 'bool', 'name': 'CollectorPumpON' },             # Collector Pump ON (True/False)

On my configuration it gets the values 1 / 4 / 5 according to pump states (or output) 0 = all outputs(pumps) off 1 = solar pump on 4 = circulation pump on 5 = solar & circulation pump is on

As to the 148 - I'm not absolutely sure about that Consumption in Watts - it gives me the value 27 right now (solar pump is off) and the circulation pump is powered from another power source... I will try to watch & record the data tomorrow. Well, maybe there are differences between various firmware versions. But it's quite possible that Ekontrol is calculating this value based on pump status on/off and current PWM setting.

mvdklip commented 3 years ago

154 - Great! I'll change it. I have scheme 1 without any other pumps connected.

148 - It's the consumption wattage with one decimal precision so you have to dividide by 10. In standby it's 2.7W, with the collector pump running it's more. I know because the controller actually displays consumption values when the pump is running and it matches this register.

aelias-eu commented 3 years ago

148 - looks like you are right :) Thanks.

btw. I have scheme 2 and this is how it looks like in my Homeassistant instance: image

please ignore switched hot/cold connections on bottom heat exchanger - i was too lazy to change the drawing - the real connection is correct :)

But I will be changing the scheme to 1 as I am going to add a central controller for all pumps & valves.

mvdklip commented 3 years ago

I have added support for bitmask and time program decoding in the hewalex_geco package. Register 154 now decodes into 'CollectorPumpON' and 'CirculationPumpON'. I suspect that bit 2 is for Boiler Pump K but I cannot check this.

Can you please check the behaviour of register 150 on your installation? I have named it 'CollectorActive' because I didn't know a better term. You originally named this field 'CollectorPumpON' but that is incorrect because on manual activation of the collector pump the bit in 154 changes but 150 stays low so that's why I'm guessing register 150 indicates some kind of activity flag for the whole system. Also I'm still looking for a register which contains the total amount of consumption energy used. Unknown registers containing non-zero values for me are:

184 (25), 272 (2), 274 (2), 298 (2), 300 (2), 312 (51880), 314 (7), 316 (1044), 318 (13), 320 (varies)

Edit: I'm pretty sure 312 is some sort of counter. I see it increasing once in a while. I think it might be the total operation time in minutes together with register 314 as a dword. For me that would be +/- 354 days which seems to be right.

Edit2: Just noticed that Ekontrol is displaying Total Energy and Total Consumption with two decimals precision. That might mean that it doesn't use the controller counter(s) but calculates totals itself.

These are all zero for me:

140, 142, 146, 158, 160, 162, 164, 168, 216, 224, 276, 292, 294, 296, 302, 304, 306, 308, 310 

Regarding the scheme: my solar and heat pumps are working independently of eachother (both on scheme 1) and I use a pi running Domoticz to balance the two systems. In my case the heat pump is used during the winter to draw heat from inside the house. My scripts also include an anti-legionella program which drives the heat pump and electric heating element when tank temperatures have been below 60 degrees celcius for over a week.

Chibald commented 2 years ago

good day @mvdklip and @aelias-eu. Thanks for the excellent work on the reverse engineering of this protocol. I wanted to do it myself a while ago based on information on elektroda forum, but i was too busy and failed. But you two have done it all!

Just wanted to let you know that I created a small fork of mvdklip's version and have added a simple mqtt script as I use openhab for my home automations. It just polls every 15 seconds and updates mqtt topics. As I use docker for my services I've also included a dockerfile. I will upload a image to docker hub so it wil be really easy for people to add mqtt support for hewalex products.

I'm currently waiting for my second ew-11, so i can control my heat pump also. Once i have that i (hopefully) can add some control topics to be able to turn on and off the heatpump etc.

have a fine day

Chibald commented 2 years ago

Hi, it works :) I use it to read (a lot) of parameters and control heat pump tap water sensor temp. and circulation pump on / off.

https://hub.docker.com/repository/docker/chibald/hewalex2mqtt

ristoksi commented 2 years ago

Hello Trying to figure out the best way to integrate g422-p09 into Home Assistant and found this project. Great work!

I tried with HA's modbus integration and created a sensor for temperature using your registers, but without luck. Is g422 using non standard modbus?

Is there way to integrate sensor readings without mqtt?

Maybe I need to create custom component for HA.

mvdklip commented 2 years ago

Geco is indeed using non standard modbus. I made a plugin for Domoticz:

https://github.com/mvdklip/Domoticz-Hewalex

Maybe you can do something similar for HA? My plugin contains a Python library you could use. If useful I could release the library seperately.

aelias-eu commented 2 years ago

Hi @ristoksi the easy way on homeassistant at this time is to use mqtt just installing mqtt broker on your device running homeassistant. I can provide a simple python script, that will allow autodiscovery of all values published by the hewalex2mqtt.py The hardest way is to implement a new integration for homeassistant The code from @mvdklip is really good starting point if you decide to take the Integration route :) The modbus integration in Homeassistant will not help you here as hewalex is not using modbus, Just a proprietary protocol over RS485. It was my plan to create an integration, but for now I will stick with MQTT - I'm using it for about 9 more various devices including the zigbee2mqtt interface without a problem.

Chibald commented 2 years ago

Note my fork has pretty extensive mqqt topic documentation based on mvdklip's library. Maybe it can be of some use https://github.com/Chibald/Hewalex2Mqtt. Been using it now for a while and is very stable integrated in openhab3. I'm reading, but also controlling heat pump parameters.

aelias-eu commented 2 years ago

@Chibald it really looks good. I will probably test it on my next home-automation-maintenance day :)

ristoksi commented 2 years ago

Thanks for your responses! I will take a look and maybe test mqtt first and if I have time later think about integration or custom component.

mvdklip commented 2 years ago

@Chibald I think I will (finally) take your suggestion to move the description of the registers into the data instead of comments. Also I was thinking I should maybe publish the Python library separately from the Domoticz plugin to ease maintenance. Your forked version of the library is a lot behind the current version and in the meanwhile I have added a lot more PCWU registers.

ristoksi commented 1 year ago

@Chibald I think I will (finally) take your suggestion to move the description of the registers into the data instead of comments. Also I was thinking I should maybe publish the Python library separately from the Domoticz plugin to ease maintenance. Your forked version of the library is a lot behind the current version and in the meanwhile I have added a lot more PCWU registers.

I am beginning to integrate that into my HA soon. Are you published the python script separately yet? I need to read more, but if I install the mqtt broker into my raspi running HA, where should i put the python code? HACS custom component or some other place?

aelias-eu commented 1 year ago

@ristoksi I'm using the MQTT autodiscovery function in the HomeAssistant - take look at hass_register_hewalex.py The hewalex2mqtt.py is executed every minute by cron and feeds data.

If you are up to it, You could create an custom integration and I'm sure, it would make some people happy - me included :)

ristoksi commented 1 year ago

@ristoksi I'm using the MQTT autodiscovery function in the HomeAssistant - take look at hass_register_hewalex.py The hewalex2mqtt.py is executed every minute by cron and feeds data.

If you are up to it, You could create an custom integration and I'm sure, it would make some people happy - me included :)

I try if i could make a component. Couple of questions: In the hass register code, you have state_topic as domov/pivnica/solar/hewalex/decoded. I suppose hewalex2mqtt.py should update those states, but i did not find any references to "domov/pivnica". Should i change that part of code or is it automatically detected by home Assistant broker?

aelias-eu commented 1 year ago

good point & my fault - it's just because I'm using the

mqttPrefix="domov/pivnica/solar/hewalex/"   

in my copy of hewalex2mqtt.py just change the state_topic according to your configuration with default hewalex2mqtt.py from my git repo it should be like this

client.publish(mqttPrefix+"T1"+"/config",'{"name": "Solar T1", "unique_id":"'+uidPrefix+'_t1", "unit_of_measurement":"°C", "device_class":"temperature", "state_class":"measurement", "state_topic": "hewalex/decoded/T1"}',0,True)

I cannot test it right now but it should work

ristoksi commented 1 year ago

I got it working in my setup. Installed mqtt broker and appdaemon. Then created a python config app (with your hass_config code) for creating sensors and then minutely polling python app for sensor value reading. I had to fork the code a little for appdaemon and add mqtt user credentials, but nothing too big.

Yes it works, but is a bit mess so i may try to make the integration later.