OpenEnergyMonitor Community

Goodwe Inverter interface

Tags: #<Tag:0x00007f1d59fb63c8>

I’ve been a longtime fan of openenergymonitor. I’ve never really contributed, but I’ve trailed the (old) forums and the new. I’ve been logging my in house power usage for a decade now and since the government decided to change policies, I decided it was time to change my PV inverter to a hybrid inverter. I’ve chosen a goodwe 5k-ET, which has a 3~ backup circuit of 25A, can charge a battery pack and return balanced/unbalanced output on 3~ to keep the utility feed happy.
Since I couldn’t find an implementation to inject the data in emoncms, without using home-assistant or some other tool to readout the inverter, I’ve decided to create an interface for emonhub.
For now it lives in my personal repo in a branch: GitHub - ziporah/emonhub at goodwe-5ket
I’ll testdrive it for a few days on a clean rpi installation, see what’s going on and if it is stable. If all works well, I’ll probably create a PR on the official repo.
I’ve reused a lot of code from the current goodwe homeassistant udp connector, which I’ve also referenced in the code. I hope it suits someone elses needs as well as it does mine.

1 Like


Good work.

If you make a pull request it makes it easy for people to review and comment.

It looks like this commit Change deprecated function · openenergymonitor/[email protected] · GitHub adds src/emonhub.conf which seems like a mistake.

The default value for ip should be None, not False. The superclass __init__ already does self._settings.update(self._defaults) so it doesn’t need to be done here (I appreciate this is done in other interfacers, I will aim to fix that).

Can we just call it goodwe instead of goodwelibrary? The fact that it appears in an import statement already implies it’s a library. Also renaming the class in the import statement (using as) confused me for a while. Can we just use its actual name?

I am not sure what catching the asyncio.CancelledError exception does, apart from maybe hiding bugs. If the task is cancelled, data certainly won’t be valid. If there is a reason why the task might be cancelled, I would say we should just return there. However I would strongly argue that we should not catch any exceptions here, since we can’t do anything useful about it. The thread will be restarted when exceptions are raised and we get nice verbose logs.

It looks like the big list of sensors in the for loop is just a copy of ET.__sensors. Could we just use that directly?


I’ll create the pull request and copy your suggestions in the PR.
The emonhub.conf is probably a mistake. I resetted my history, but it must have been still around there somewhere. The other suggestions I’ll answer and address in the PR.
Just quick for the asyncio.CancelledError => I’ve put it there because otherwise I wasn’t able to stop the emonhub with ctrl-c. The threads for some reason kept running and they didn’t get the term signal. While the run (according to the documentation and my knowledge) should only run it once, it somehow kept running the goodwe interface thread and then tries to publish to an mqqt channel, but the connection is cancelled by the main thread already.

@bwduncan I tagged you on the PR, can you double check if you have any more remarks on the changes I’ve made?

I’ve been monitoring the system for some time now. My system is ‘special’ since I have 2 PV inverters and the meter is connected to the goodwe PV inverter, thus measuring 1 invertor, but reporting the total load off the grid,inverter,battery and all other values. There are missing fields, which are reported as XX unknown now. And also wrong definitions, which will be correct if you only have 1 PV, but not if you have 2 systems. I’ll be adding them the coming days with same naming convention as the specification in openems.