Scenario: Deye Inverter + PowerFox

[nfocke]

Dear Reinhard,
thanks for the great work here. I think, this is an important contribution making SolarFlow do what it should do... (interesting that Zendure seems to follow this repo ;))

I have a somewhat different setup, but I think it is not so uncommon in Germany.
Concretely, I have a Deye SUN 600 Inverter (hence, no OpenDTU, no direct control of inverter input/output) and a PowerFox smartmeter interface. Both are working okay with Homeassistant for visualization purposes, but, as you know, given the current Zendure MQTT implementation do not allow controlling power-to-home. Actually, it would be probably most straight-forward to use Homeassistant automation/scripts/... to allow SolarFlow control, but this is out of our hands [enough Zendure-bashing for now ;]

My question is: will your control script(s) be working in this situation? I.e. is the SolarFlow output-to-home fully enabled in the current version?

Going through the code, I have some doubts.
The main loops calls:

  while True:
         time.sleep(steering_interval)
         limitHomeInput(client)'

In limitHomeInput

   if not(hub.ready() and inv.ready() and smt.ready()):
        return

Would this not stop execution is inv.ready() is not set / no DTU available?

I see there is a src/solarflow/solarflow.py, but it does not seem to be called as replacement for the inverter-based limit. Mabye I am missing something here.

Unrelated, but maybe relevant. In solarflow.py,

class Solarflow:
   opts = {"device_id":str ,"full_charge_interval":int}
   SF_PRODUCT_ID = "73bkTV"

SF_PRODUCT_ID seem to be hard-coded (probably your ID). Shouldn't this take the globally set ID?

Reasons why I am asking: it feels a bit risky to bring the Hub to "offline" mode (which is needed for the control script to work as far as I understand) only to find out that it does not work in my scenario... ;)

[reinhard-brandstaedter]

Hi @nfocke ,

actually this project started off allowing control of the hub directly from HA. You can find that in my old “solarflow” project.
This project indeed focuses on a combined control of SF AND the inverter as most people today also use panels connected to the inverter directly.
Back then the control of the hub only worked rather sluggish, this has improved now.
That said it depends on AhoyDTU/OpenDTU and your observation is correct.

However we might consider bringin a basic control only of the hub at some point.

Taking the hub offline and reporting to your own MQTT is not dangerous, it will allow you to realize an automated full control by sending MQTT commands from HA (the current firmware also switches SF output a lot faster and precise as begore).
So you can totally use a offline hub and implemend your own switching from HA.

You can find some documentation in my “solarflow” repo or even in this sourcecode.
If you have any questions, happy to support.

[nfocke]

Thanks Reinhard. Will see if I can get a SolarFlow-only version to work. Will need to learn more about the MQTT syntax used by Zendure. In particular the "write" options. If the app needs to be fully replaced, are you aware of a documentation of the write commands available? E.g. battery charge limits etc... these can also be set via the App. I guess these are also communicated to the hub via MQTT?

[nfocke]

Alright. I took a "leap" (I know should not be) and disconnected the hub from the Zendure cloud. Somehow with mixed effect.

I used solarflow-bt-manager.py -d with my Wifi info and -b option for my local Mosquitto broker (running on a Raspi 5).
While pinging, the hub goes offline from the Wifi for ~10 seconds and comes back responding normally to ping.

I can see an iot/73bkTV/<SF_ID>/register/replay message in the MQTT explorer with {"messageId":123,"timestamp":1708975541,"params":{"token":"abcdefgh","result":0}}
Then I get a
/73bkTV/<SF_ID>/event/device {"messageId":"123","method":"device","deviceId":"<SF_ID>","timestamp":1708975690,"offData":0,"data":{"eventId":3,"startTime":1708975511,"endTime":1708975690,"inout":1,"mode":3,"electric":0}}
Also, the hub disappears from the Zendure app (shown as offline).

However, after waiting some ~5-10 minutes I get no further MQTT messages in the MQTT explorer. I made sure no MQTT authentication is in place and tested posting anonymous messages and also messages with random user name/password to the MQTT broker via mosquitto_pub. This worked without problem and showed in the Explorer. But no messages from the hub unfortunately. I guess, waiting longer does not really make sense, right?

On the plus side, the re-connect to Zendure was indeed not a problem.

Am I missing something? Or is my hub somehow different? It was bought ~07/2023, firmware V2.0.33

[reinhard-brandstaedter]

There could be two reasons why you are not seeing data immediately:

• a BT connection to the hub is somehow still active/locled on your device you ran the bt-manger command on
• your mobile is talking to the hub via BT

Make sure you disconnect all BT connection (turn off mobile app, reset BT on the raspi (if thats where you ran the bt-manager).
The hub will not send data via WiFi if it has an (idle/zombie) BT connection.

[reinhard-brandstaedter]

@nfocke regarding what properties you can set and how this is done via MQTT:
There is one MQTT topic that the hub receives set commands:
iot/73bkTV/<device id>/properties/write

The payload has to be JSON and follows this structure:

{
    "properties": { 
        <property>: <value> 
    }
}

The list of properties most relevant:

• buzzerSwitch: turns on/off audio confirmation of commands
• socSet: 0-1000 percentage of max charge level 1000=100%
• minSoc: 0-1000 percentage of max discharge level 10=1%
• outputLimit: hub output limit in W
• inverseMaxPower: maximum output power to inverter
• passMode: BypassMode (0|1|2) off|auto|manual
• inputLimit: is ignored

[nfocke]

@reinhard-brandstaedter Thanks for explaining the syntax. Very helpful indeed.
Now I only need to make my hub talk to the MQTT broker... ;)
I put my today's experience in the issue thread in solarflow-bt-manager were a similar case seems to have emerged.

[rostchri]

The SF_PRODUCT_ID 73bkTv is for the Solarflow Hub 1200. The Hub 2000 will most likely have another one…
We will see that, as soon the first Hub 2000 are shipped …
The device_id is what you are asking for. The code is correct.

I‘m using solarflow-control with an hoymiles inverter (HMT-2250-6T) + OpenDTU, but I‘m not limiting my Inverter in any way.
With some small changes in the solarflow-control code it is possible to do the limiting only via the Solarflow-Hub.
The Solarflow Hub is not very fast doing this, but it is working (with solarflow-control) and I‘m perfectly fine with it.

[nfocke]

Cool. I was thinking in this direction as well. But have not worked much with MQTT so far. Do you have your version/fork on Github as well?

[rostchri]

I will publish my changes in the next days, but I really changed very few lines. I won’t speak about an own version ;) Running an own Mqtt is important, but if everything is working you won’t notice mqtt. Most interactions will be done via the solarflow-statuspage, and of course solarflow-control will use mqtt to control the hub.

[mavo]

Hi @rostchri,

As I ordered a Hub2000 and waiting for it now I wonder how's the flow to get the product ID from the hub when it will eventually arrive? Will we just see it in the MQTT (explorer), or how to extract this ID?

I really hope HUb2000 will work, as this for me seems to be the missing puzzle piece to be as close to a "proper" PV-Installation as I could.

MaVo

[rostchri]

I‘m pretty sure that the hub2000 will work out of the box without much changes in reinhard-brandstaedter solarflow-stack. My hub2000 will arrive around end of march. If your hub2000 arive, a good start will be the solarflow-bt-manager. As long as the hub will use „Zen“ as name in bluetooth communication, the solarflow-bt-manager tool will give you most of the information.

[reinhard-brandstaedter]

I’m almost certain the Hub2000 will not be much different firmware-wise.
So taking it offline is likely straightforward.
The rest, depending on the product ID, shouldn’t be too much change and once we see the first ones, I’ll rather quickly support those.