WazzaCPT

No need to flash the firmware on the Sonoff stuff as they all have LAN support. Only time you would want to flash is if Sonoff and eWelink dissapeared.

sent

@Gary Waterworth Shout if you want access to a couple of different site variations. You should still have my email address. I have access to a 50kw HV 3 phase, dual LV 3 phase and a LV single phase.

The API is working. There were more changes to the token and authentication processes. The crew for the SolarSynkv3 add-on implemented an update yesterday. That solution is currently working for sunsynk and other generic pv.inteless dongle setups. All of these solutions are all still so fundamentally flawed relying on the cloud for data access. I need to start moving my friends and family over to direct local connections.

Hello Peeps, I have created a device config for the Geyserwise MWS units for the tuya-local integration of Home Assistant. There are still some general bugs with the Geyserwise device itself. This config has been tested briefly to get it operational at a site with two unit. I would appreciate if some more users could test it out before I create a pull request to the main repository. https://github.com/Waz-Cpt/tuya-local If you want to just add the single file to the custom_components folder them you can download the file and upload it directly for testing. https://github.com/Waz-Cpt/tuya-local/blob/55581ae9ef1992e677adb7287400f2f6a1ca437f/custom_components/tuya_local/devices/geyserwise_mws_water_heater.yaml Once uploaded, restart HA and you can go through the process of adding a Tuya Device in the Tuya-Local integration. It will detect the device type for you and you will have a water_heater device and entity along with the corrected error messages and other settings. Please DM me with feedback of questions. Or comment on this thread.

Hey Regbes, The regular Geyserwise works flawlesly though the Tuya Local, but the MWS was not having a great time. Tried to do a custom config file for it. I did submit it as a new device request on the GitHub page. Kind Regards,

I can give you remote access to a system if you would like.

Anyone here tried to get this integrated into Home Assistant with the Tuya Local integration instead of the cloud.

Any ideas on a solution for this?

Which specific ESP32 SoC do you have and what board?

Hello Hannes, I gave up with KellerZA integration with the Deye or Sunsynk 50kW units. The integration kept crashing from the errors. From what I understand is that you need to connect each inverter separately to a RS485 module to get the data from all the inversters. I believe that the comms does not work with the daisy chain even with a termination resistor. @kellerza, do you have any suggestions here. I have posted on other discussion asking about the the Sunsynk 50kW units. It would also be great if you could explain how to configure your integration to work with inverters in Parallel in the documentation. Been wanting to setup your solution for my parents with their two 12kW 3phase units.

Hello Inigo, The config and node-red already support getting the data of each PV array on each inverter on the system. If you have a look at the Usable PV entry you should see PV1 through to PV3 based on how many inverters you have data polling from. So, if you see 1 through to 6 then all three inverters are been read correctly. 1 + 2 would be Inverter1, 3 + 4 would be Inverter2 and 5 + 6 would be inverter3. From there all you need to do is adjust you template sensors by adding the additional sensors for the rest of the MPPT channels.

I would also be interested to know this. From what I know there is nothing currently that provides any type of connected system that works on the CoCT. The best would to move over to the new affordable post paid meter. Those meters typically have a data output which may be able to link to HA.

I wonder how different the firmware update process is compared to say the Nextion firmware upload is.

I believe you have not got the setup of everything for Slipx card loaded correctly. You need to check you essential versus load details. Have a look at the template options for the Slipx card on Gary's repo. He has number coordinated this fairl well to align with Slipx data inputs. But using some common sense also goes a long way. Here is an example of my one slipx card: type: custom:sunsynk-power-flow-card cardstyle: full show_solar: true inverter: modern: false three_phase: true battery: energy: 40960 shutdown_soc: 20 show_daily: true solar: show_daily: true mppts: 2 pv1_name: Sunsynk pv2_name: SolarEdge load: show_daily: true grid: show_daily_buy: true show_daily_sell: true show_nonessential: false entities: use_timer_248: none priority_load_243: none inverter_voltage_154: sensor.sunsynk_output_voltage_154 load_frequency_192: sensor.sunsynk_output_frequency_192 inverter_current_164: sensor.sunsynk_output_current_164 inverter_power_175: sensor.sunsynk_output_total_power_175 grid_connected_status_194: sensor.sunsynk_grid_online_194 inverter_status_59: sensor.sunsynk_inverter_status_59 day_battery_charge_70: sensor.sunsynk_battery_daily_charge_70 day_battery_discharge_71: sensor.sunsynk_battery_daily_discharge_71 battery_voltage_183: sensor.sunsynk_battery_voltage_183 battery_soc_184: sensor.sunsynk_battery_soc_184 battery_power_190: sensor.sunsynk_battery_power_190 battery_current_191: sensor.sunsynk_battery_current_191 grid_power_169: sensor.sunsynk_grid_power_169 day_grid_import_76: sensor.sunsynk_daily_grid_buy_76 day_grid_export_77: sensor.sunsynk_daily_grid_sell_77 grid_ct_power_172: sensor.sunsynk_grid_power_172 day_load_energy_84: sensor.sunsynk_daily_load_84 essential_power: sensor.sunsynk_load_power nonessential_power: none aux_power_166: none day_pv_energy_108: sensor.sunsynk_daily_pv_108 pv1_power_186: sensor.sunsynk_pv1_186 pv2_power_187: sensor.solaredge_current_power pv1_voltage_109: none pv1_current_110: none pv2_voltage_111: none pv2_current_112: none Considering that your energy values daily grid buy, daily solar and daily load have no units, I would assume that you have made a mistake somewhere as well. For the Energy Dashboard: Electricity Grid: Grid Consumption: sensor.sunsynk_grid_total You can also add any energy meters of devices installed before the CT clamps of the Sunsynk inverter to the Grid Consumption. Move devices with energy monitoring that are installed after the CT clamps for the inverter to the "Individual Devices" section. Grid Export: sensor.sunsynk_grid_total_export Solar Panels: Solar Production: sensor.sunsynk_pv_total Home Battery Storage Battery Charge: sensor.sunsynk_battery_etotalchg Battery Discharge: sensor.sunsynk_battery_etotaldischg The above is based on whether you are using the templates as Gary has them on his GitHub repo.

Have you followed the setup guides and do you see the data in the developer tools? Also you should not be adding energy consuming devices to the Electicity Grid consumption unless they are outside of the inverter consumption. There is a section for individual devices in the energy dashboard. Gary previously indicated that you should be using the Total values for energy dashboard and not daily.

Ok, so all way to complex for me. Is there a way to make use of the firmware bin that you dumped to get to the code and functions?

Hello @DeonBez, Are you saying that you could sniff both the RX and TX packets using an ESP32 with a logic level convert (or a TTL to DB9 serial interface) while not messing with the functions of the dongle and inverter. I would assume this means you can see data but should block sending any data through the sniffing device? Would this mean that technically you would only need to sniff the TX of the inverter? Would it be possible in theory to sniff directly off the RX pin of the UART on the ESP32 in the dongle? Potentially including a second ESP module inside the same dongle? I am not very clued up with this type of approach but I do know you can scope a signal, so understand you should be able to read it with a device.

Would still be amazing to get into the orignal firmware and see if it is possible to retain the original communications but add in a stream server of the RS323 (modbus).

Hello @kellerza, Not sure if this helps. I have tried a few things. This is on the EDGE branch with 50kw HV Sunsynk. The addon would crash after around 5 to 10 minutes of running, changing the sheduling to the solarman example appears to have helped stabilise the addon. What I do notice now that I understand the inverter setup better is that the battery data is not reading correctly. There are actually two battery inputs and so the battery_power and battery_current are meant to be the summed values from battery_1_power + battery_2_power and battery_1_current + battery_2_current respectively. The battery_voltage and battery_power are both reporting a value 10x below what would be expected. Here is some of the debug log showing some errors. 2024-04-16 10:12:22,286 DEBUG pymodbus.logging Getting Frame - 0x3 0x2 0xfe 0x4a 2024-04-16 10:12:22,286 DEBUG pymodbus.logging Factory Response[ReadHoldingRegistersResponse': 3] 2024-04-16 10:12:22,286 DEBUG pymodbus.logging Frame advanced, resetting header!! 2024-04-16 10:12:22,286 DEBUG pymodbus.logging Getting transaction 1 2024-04-16 10:12:22,286 DEBUG pymodbus.logging Unrequested message: ReadHoldingRegistersResponse (1) 2024-04-16 10:12:22,286 DEBUG pymodbus.logging Frame - not ready 2024-04-16 10:12:22,287 DEBUG sunsynk.sunsynk Time taken to fetch 4 registers starting at 616 : 6.07s 2024-04-16 10:12:22,287 WARNING sunsynk.sunsynk Did not complete read, only read 8/4 2024-04-16 10:12:22,287 DEBUG sunsynk.sunsynk Request registers: [616, 617, 618, 619] glen=4. Response [100, 500, 900, 1500, 1700, 2100, 4000, 4000] len=8. regs={616: 100, 617: 500, 618: 900, 619: 1500, 620: 1700, 621: 2100, 622: 4000, 623: 4000} 2024-04-16 10:12:22,288 DEBUG pymodbus.logging Adding transaction 1 2024-04-16 10:12:22,288 DEBUG pymodbus.logging send: 0x1 0x3 0x2 0x6e 0x0 0x4 0x24 0x6c 2024-04-16 10:12:22,323 DEBUG pymodbus.logging recv: 0x1 0x3 0x8 old_data: addr=None 2024-04-16 10:12:22,323 DEBUG pymodbus.logging Processing: 0x1 0x3 0x8 2024-04-16 10:12:22,323 DEBUG pymodbus.logging Frame - not ready 2024-04-16 10:12:22,339 DEBUG pymodbus.logging recv: 0xff 0xe4 0xff 0xe2 0x0 0x4d 0x0 0x13 0x43 0x1e old_data: addr=None 2024-04-16 10:12:22,339 DEBUG pymodbus.logging Processing: 0xff 0xe4 0xff 0xe2 0x0 0x4d 0x0 0x13 0x43 0x1e 2024-04-16 10:12:22,339 DEBUG pymodbus.logging Frame - not ready 2024-04-16 10:12:25,291 DEBUG pymodbus.logging Adding transaction 1 2024-04-16 10:12:25,291 DEBUG pymodbus.logging send: 0x1 0x3 0x2 0x6e 0x0 0x4 0x24 0x6c 2024-04-16 10:12:25,330 DEBUG pymodbus.logging recv: 0x1 0x3 0x8 0xff old_data: addr=None 2024-04-16 10:12:25,330 DEBUG pymodbus.logging Processing: 0x1 0x3 0x8 0xff 2024-04-16 10:12:25,330 DEBUG pymodbus.logging Frame - not ready 2024-04-16 10:12:28,294 DEBUG pymodbus.logging Adding transaction 1 2024-04-16 10:12:28,294 DEBUG pymodbus.logging send: 0x1 0x3 0x2 0x6e 0x0 0x4 0x24 0x6c 2024-04-16 10:12:28,337 DEBUG pymodbus.logging recv: 0x1 0x3 0x8 0xff 0xe2 0xff old_data: addr=None 2024-04-16 10:12:28,337 DEBUG pymodbus.logging Processing: 0x1 0x3 0x8 0xff 0xe2 0xff 2024-04-16 10:12:28,337 DEBUG pymodbus.logging Frame - not ready 2024-04-16 10:12:28,353 DEBUG pymodbus.logging recv: 0xe1 0x0 0x4c 0x0 0xf 0x31 0x17 old_data: addr=None 2024-04-16 10:12:28,353 DEBUG pymodbus.logging Processing: 0xe1 0x0 0x4c 0x0 0xf 0x31 0x17 2024-04-16 10:12:28,353 DEBUG pymodbus.logging Frame - not ready Please let me know if there is something I can do to try and get the addon improved.

Hello Martin, It would be great to potentially build your integration to have some form of settings profiles as to the system setup and how your solution processes the creation of entities. There will also be differences between the regular 3 phase systems and the 3 phase high voltage systems. It may make sense to development work of the integration in a branch for 3phase and possible 3phase hv. PS. Does your integration self clean stale entities after corrections like with the battery data? Where does your solution store the entity data and is there a reasion that you have not included unique id data for entites? If your solution uses templating then it would also be advisable to look at using the availability feature in templating to help with filtering bad data or errors.

Hello Gary, Have you looked into using availability within your template sensors instead of the filtering? Availability for Template Sensors

Hello Gary, What is strange is that this is only happening at one of the two sites I have setup. So not sure if there is some issue with that site or the added complexity of a solar source other than Sunsynk. I will look at using the totals for the energy dashboard instead. Many thanks as always.

Do you then use the total total data in you energy dash board?

Receiving solar energy data between 11pm and 1am and relatively large amounts. Also getting random grid sell amount during those times as well. I have included the filtering but am not sure if I should be filtering on the daily totals.