Jump to content


  • Content Count

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Warm water will want to rise (thermal syphoning) so if the feeding geyser is higher than your main geyser (and you have a pumped system), this can be a problem. We solved this problem by installing a non return valve. Another solution if you have the space is to run the pipes downwards and then up to the feeder geyser. The idea is that colder water collects at the bottom of the pipes effectively stopping the thermal syphoning. This could be less maintenance over the long run as small particles can collect at the NRV's keeping them from closing properly.
  2. Our Goodwe is about 6 years old and two years ago I replaced the lead acid batteries with two Pylontechs. Due to the age of my Goodwe, I had to buy an EzConverter as well to allow communication between the two but it works fine. The Pylontech does limit the charge current (to prolong its lifetime I presume) which the Goodwe picks up and deal with accordingly. I don't know the other batteries, but the Pylontech's work.
  3. I only spot this thread now. I've started playing with arduino's about a year ago and have steadily expanded my home automation system. I'm also using OH, mostly because it's the first one I tried and I'm quite familiar with it by now (read: to lazy to learn HA). Over time I have replaced a lot of RF transceivers with Wemos D1 mini and MQTT - much more reliable. The first thing I built was a weather station which included a small 5V panel which measures irridiance. I'm still trying to figure how to translate that into maximum potential PV power from our solar arrays but need time to g
  4. So my wemos is working and I'm getting the values and transmitting via MQTT. Thanks for all the help! I do need a bit of clarification on some of these readings: pgrid: On-grid Power (EzMeter) = 5 W (Is this the draw from the grid?) pload: On-grid Power = 143 W (And this the mains load?) total_power: Total Power = 427 W (I have no idea what this is)
  5. I think I got it. I basically have to put the two address together and convert the resulting hex to decimal. I think that means bitshifting by 8 though.
  6. I'm coding the wemos using arduino's IDE. For the SOC I use: BatterySOC = (int) incomingPacket[33]; If I understand bit-shifting correctly, I basically need to do this: n1 = (int) incomingPacket[7]; n2 = (int) incomingPacket[8]; PV1V = (n2*16 + n1) /10; //Divide by 10 for the single decimal But the math doesn't seem to work out. Using the example in your second post, 0x0B = B1011 and 0xA4 = B10100100 needs to give 298V. If I bitshift 0xA4 and add 0x0B I get 2635. This is the first time I come across bitshift and all help is apprecia
  7. So quick question. I find it fairly easy to get data that uses only one address, for example SOC from address 33. But how do I translate data across two addresses into a single value, for example [7,8] into PV1 voltage?
  8. Some good news. It's taking a bit of time but I have my first data from the Goodwe coming into OH!
  9. So just a brief update. I installed the openhab TCP/UDP binding and installed Packet Sender on my laptop to mimic the Goodwe. Something unusual is going on as PacketSender did not provide the IP address of the OH Raspberry Pi as "sender". So I'm parking that idea for now. As an alternative, I took a Wemos board I have and wrote some code to send the UDP packet to the Goodwe. The "0x00" initially gave some problems but I figured it out (I did say I'm a novice) and voila, the wemos is getting the data from the Goodwe! Next I'm going to add the MQTT code, decipher the incoming message a
  10. Sure, here you go: 2020-10-07 20:35:40,796 discover(449) - DEBUG: Probing ES inverter at 2020-10-07 20:35:40,796 connection_made(323) - DEBUG: Send: 'aa55c07f0102000241' 2020-10-07 20:35:41,696 datagram_received(334) - DEBUG: Received: 'aa557fc00182403037582020475735303438442d4553ffffffffffffffffffffffffffffffff33353034384553553135333030303331333630303431302d30303436382d30370e1d15' 2020-10-07 20:35:41,745 discover(451) - DEBUG: Detected ES protocol inverter GW5048D-ES, S/N:35048ESU15300031 2020-10-07 20:35:41,745 __init__(623) - DEBUG: Using proactor: Io
  11. We have a Deco M5 mesh wifi network (192.168.68.xxx) to which the Goodwe, phones, laptop etc is connected. The Raspberry Pi is connected to the primary router ( which also provides the internet to the Deco mesh. All the SmartHome controllers (pool pump, weather station, water tank, garage lights) are on the Deco wifi network and communicate seamlessly with OH via MQTT. The Goodwe is a 6 year old ES model (S/N 35xxx which may explain the different data structure?) and we connect using an app on my phone. Both PVMaster and the predecessor EZManage connect with no problem.
  12. So a bit of an update. I ran the inverter_test Python code and received the following: So even though the response could not be deciphered, at least there was a response and that is a start. So next I installed the TCP/UDP binding in OH (https://www.openhab.org/addons/bindings/tcp1/), configured the udp.cfg file and added two items: String GoodweData { udp="<[]"} String GoodweRequest { udp=">[]"} and to test this the following command is run every minute: sendCommand(GoodweRequest, "aa55c07f0102000241
  13. Thanks, this helped a lot. I installed Packet Capture on my phone and picked up the packets. I would consider moving to HA if I haven't spent so much time customising my OH set up already. I'm going to try to get the TCP/UDP binding working and see where that gets me.
  14. So I've been trying to get this to work but no success. I'm a noob but learning a lot fast. Info: Goodwe ES5048 (about 6 years old, firmware updated about 18 months ago) Deco M5 mesh network Old original EzManage app and latest PV Master apps work perfectly (but not at the same time) Phone IP is Goodwe IP is Home automation hub: Openhab on a RPI (but I don't think that is immediately relevant) I downloaded Wireshark to my laptop to see what is going on on the network and it was surprisingly difficult to identify the Go
  • Create New...