no data from hub in offline mode

[quellekatalog]

there is no data sent from the hub to my local mqtt-server (user authentication is disabled) after disconnecting from the cloud

with BT-connection data is sent

additionally, it's not possible to re-connect to the cloud again. it's required to re-connect via the app

[reinhard-brandstaedter]

Please ensure that NOTHING is connecting to the hub via Bluetooth after it has disconnected. As long that there is a BT connection (app or br-manager in proxy mode, or idle BT connection from your computer running bt-manager) the hub will not send anything via WiFi/MQTT. (the hub sends either via BT or WiFi). Shutting down the zendure App, the bt-manager restarting the hub usually solves this.

[nfocke]

@reinhard-brandstaedter @quellekatalog I have a similar problem (as discussed in the other thread). I re-tried today making sure to close/kill the Zendure app on the mobile phone and even disabled Bluetooth. I restart the Raspi Bluetooth service after solarflow-bt-manager finished its work.

I get:

in MQTT Explorer. So there is the disconnect iot/ message, a response (from the hub likely?) and an "error" message. No further responses are received for ~20 minutes (gave a bit more time today).

Not sure if this is exactly the same as for @quellekatalog, but chances are there.

I then re-connected to Zendure cloud and got MQTT messages from there in my Homeassistant after ~45 seconds. If some Bluetooth connection would block the transfer, this should affect the Zendure MQTT messages as well, right? If I let the "proxy" mode run, no messages are transmitted to Zendure indeed (App and Zendure MQTT-Broker). So I do not think it is a Bluetooth issue.

[reinhard-brandstaedter]

@nfocke in your case you did get a successful message sent from the hub to mqtt (ignore the error content, i get these also). So the connection works obviously. Have you tried restartin (not resetting) the hub and see what happens then? Just to be sure, the MQTT listens on non-ssl standard port and you have provided the Ip of the broker and not a DNS hostname?

[nfocke]

@reinhard-brandstaedter: all standard Mosquitto, default ports, no SSL, no authentication. And yes, gave an IP address that is fixed by the router. When running in "proxy" mode with the same MQTT parameters, the messages are all forwarded to the broker as expected. But this will not allow control and is not for longterm use (as far as I understand).

But no, I did not restart the hub. Not sure, if/how that could help? When re-connecting to Zendure, the MQTTs go out nicely without a restart. So something seems to block the telemetry messages or they are not sent... Probably the latter, since the initial messages form the hub seem to have arrived.

You run your hub with the latest firmware? Or an older version? Maybe Zendure changed something...

[quellekatalog]

Please ensure that NOTHING is connecting to the hub via Bluetooth after it has disconnected. As long that there is a BT connection (app or br-manager in proxy mode, or idle BT connection from your computer running bt-manager) the hub will not send anything via WiFi/MQTT. (the hub sends either via BT or WiFi). Shutting down the zendure App, the bt-manager restarting the hub usually solves this.

unfortunately, there is still no message sent from the hub to the broker:

• connected via the zendure app with my wifi => data is sent to the cloud (& can be gathered from mqtt.zen-iot.com)
• ran solarflow-bt-manager.py => data is not sent to the cloud anymore
• disabled bt on the raspberry + closed zendure app on the mobile

by the way: many thanks for your quick assistance!

[reinhard-brandstaedter]

Just to rule out firmware version issues. I’m (and others confirmed working) are on 2.0.33. All prior fw versions also worked.

I’d give restarting the hub a try (after taking offline)

[quellekatalog]

firmware is 2.0.33, restarted the hub, but no difference. there is still no data transmitted to the mqtt-broker.

on the hub, the iot-led flashes from time to time, so it seems the connection to the broker could not be established although the hub is in the wlan and can be pinged.

[nfocke]

Another addition / observation. I had the doubt if the problem was maybe caused by the Raspi (serving the MQTT broker and performing the Bluetooth handling) being in WLAN. Although WLAN to WLAN communication is enabled in my Fritzbox, it is a mesh network, so mabye unpredictable things can happen. So I connected the Raspi via LAN instead and re-tried. I get the same intial MQTT messages as before, but no further messages unfortunately. I did restart the hub for the firmware update today, updating to V2.0.38. So, no progress in that regard.

However, different to the trials some days ago, when re-connecting to the Zendure cloud, the MQTT messages did not arrive there, the hub stayed offline and was only reachable via Bluetooth. And yes, I did stop BluetootH (turning it off and also turing of the Raspi). But no messages arrived in the Zendure MQTT / no connection in the app. After reconnecting the hub via the official app (after pushing the IOT button for 3 seconds, re-entering the WLAN code) it also re-connected to the Zendure cloud and worked again.

I am not sure, if this is due to the new firmware upgrade, but it seems plausible. It remains a mystery to me, what is going on, but I suspect, I may have to wait until Zendure eventually opens up their MQTT server for control or allows/officially enables to specify a custom MQTT broker. Running of of ideas currently... ;)

[quellekatalog]

However, different to the trials some days ago, when re-connecting to the Zendure cloud, the MQTT messages did not arrive there, the hub stayed offline and was only reachable via Bluetooth. And yes, I did stop BluetootH (turning it off and also turing of the Raspi). But no messages arrived in the Zendure MQTT / no connection in the app. After reconnecting the hub via the official app (after pushing the IOT button for 3 seconds, re-entering the WLAN code) it also re-connected to the Zendure cloud and worked again.

i face the same behavior...

[tuxianerDE]

Hey,

lets see if I can help. I am on firmware version 2.0.33.

Can you do the following.

1) Connect to you hub via bluetooth and see the data in the Zendure App 2) disable bluetooth on your mobile phone 3) restart mosquitto (or the MQTT server) I have seen that dirty closed session mosquitto really hates 4) Connect with mqtt explorer to the MQTT server 5) execute the bluetooth manager command from your raspi or laptop 6) Restart the bluetooh mapper script (if you use it) to prettify

I am using the hub also being connected via fritz mesh. I am having trouble with this WPA2+WPA3 config the new fritz box offers so I am running my wife with WPA2.

[nfocke]

Alright, further experimentation tonight. I retried the procedure, same result intitally. I get the iot/write and initial register meassge as before. Waited some time, turned of all Bluetooth on the phone, restarted Bluetooth on the Raspi, no difference.

I did get a /73bkTV//event/device message every ~10 seconds but no telemetry whatsoever. The WLAN led was blinking periodically (yellow).

So I followed @reinhard-brandstaedter 's advice to reboot the hub (6 seconds IOT button, +one brief push to restart). And viola, after some volley of device and a firmware message, telemetry messages came in nicely! :)

Then I experimented a bit. If I connect the app via Bluetooth, all messages stop arriving. So much as exptected. But I also did not get any /73bkTV//event/device messages any more. When I turn of Bluetooth, after some seconds, messages come back. Including the ~10 second distance "heartbeat" event/device messages. So I think the initial problem is not a Bluetooth related issue, but something else. Maybe the hub is waiting for some kind of confirmation to start broadcasting that is not received from the local broker. But ignored when starting fresh... Without any documentation from Zendure, it will remain mysterious probably.

Anyways, now into setting up a modified Homeassistant MQTT config and bringing in a control script for my setup. The MQTT remapper is indeed very helpful :)

[nfocke]

so thanks again to @reinhard-brandstaedter and @tuxianerDE @quellekatalog hope your problem is similar? Did you reboot the hub?

[reinhard-brandstaedter]

@nfocke as a hint for HA: remapping the native telemetry topic to something more clear (with the remapper) helps definitively as it removes the logging of missing content in telemetry messages. You might also look into the HA templates located in the solarflow-control source for HA integration and control entities.

[quellekatalog]

@nfocke sadly it isn't... as mentioned, i do not get any message from the hub. tried it with hub restart, hub hardware reset, removal + new registration in the zendure app, bt power off (i did even remove other bt devices besides the raspi)... do not have anymore ideas. anyway, thanks a lot @reinhard-brandstaedter + @nfocke + @tuxianerDE for your help!

[tuxianerDE]

Just as last point did you restart the mqtt server as well? Have seen issues with dirty connects/not closed sessions

[quellekatalog]

yes i did, no difference

[tuxianerDE]

Wifi changes? are you on WPA2 or WPA3 (WPA3 does not work with the hub) WPA2+3 mixed mode (fritzbox) also has its issues/not to work

[quellekatalog]

no wifi changes, i'm on wpa2. i doubt it's related to the wifi: zendure broker works fine...

[reinhard-brandstaedter]

@quellekatalog one thing that you could try is to connect the hub to a different WiFi (e.g. create a mobile hotspot) connect the hub to that WiFi (see if it connects) and then issue the offline command to connect it to your real WiFi with the broker.

Your mqtt broker is at a current version as well, e.g. not using an obsolete protocol version maybe?

Given that so many people take their hubs offline and back, it seems strange that this shouldn't work for you.

[reinhard-brandstaedter]

@quellekatalog another thing that just came to my mind is that you could use a mqtt proxy to debug connections. I've created a MQTT proxy some time ago to help me identifying the SF hub client ID/ pwd. It's more a dev setup but you could run this docker container and it would provide connection info on the client: https://hub.docker.com/repository/docker/rbrandstaedter/mqtt-proxy/general

(run it and use it as the mqtt endpoint to track connection attempts)

[quellekatalog]

@reinhard-brandstaedter many thanks again! will try your suggestions tomorrow and report my findings

[quellekatalog]

@quellekatalog one thing that you could try is to connect the hub to a different WiFi (e.g. create a mobile hotspot) connect the hub to that WiFi (see if it connects) and then issue the offline command to connect it to your real WiFi with the broker.

Your mqtt broker is at a current version as well, e.g. not using an obsolete protocol version maybe?

Given that so many people take their hubs offline and back, it seems strange that this shouldn't work for you.

didn't work: hub was connected via the mobile hotspot to the cloud and the data was sent. after disconnection and re-routing to the local broker, no message was sent anymore

[nfocke]

@quellekatalog sorry to hear you are still struggeling. Did you test your MQTT (mosquitto?) using e.g. mosquitto_pub? And check if these appear in MQTT explorer.

[quellekatalog]

@nfocke the broker is working fine, i do have several other devices which permanently publish messages

[nfocke]

@quellekatalog I see. Could you ping / tracert the hub from the system you run your broker on? Reason why I am asking, although I also did not get the telemetry messages initially, I did get a single response from the hub. You are not getting that either, if I understand correctly?

[nfocke]

@quellekatalog another thing that just came to my mind is that you could use a mqtt proxy to debug connections. I've created a MQTT proxy some time ago to help me identifying the SF hub client ID/ pwd. It's more a dev setup but you could run this docker container and it would provide connection info on the client: https://hub.docker.com/repository/docker/rbrandstaedter/mqtt-proxy/general

(run it and use it as the mqtt endpoint to track connection attempts)

@reinhard-brandstaedter Interesting. I was thinking about wireshark sniffing or similar to get to the hub's user/password information. I guess the MQTT user/password is hard coded and hub/SN specific? It would feel better, to be able to use MQTT authentication for the broker.

[quellekatalog]

@nfocke yes, i can ping the hub. and correct: i do not even the a single response from the hub, i do only get the "replay" from the script

[nfocke]

@nfocke yes, i can ping the hub.

@quellekatalog you can ping the hub from the MQTT server/borker system or form another PC/host? Reason why I am asking, there may be a network issue between the hub and the broker. A ping from another PC will not uncover that. Also, tracert may be helpful to understand if network traffic is passing through somewhere that could block the MQTT port.

[quellekatalog]

@nfocke the hub can be pinged from the raspberry the mosquitto broker is running on

[reinhard-brandstaedter]

@quellekatalog did you go deep and capture traffic on the raspi via tcpdump? This should also reveal the hubs communication and even clientid/password used by the hub or any connection problems.

[quellekatalog]

@reinhard-brandstaedter : interestingly, i couldn't catch any traffic from/to solarflow (used sudo tcpdump -i any -nn <IP_OF_SF>). double checked it with other devices in the same wlan from which i was able to capture traffic. the sf is currently connected to the cloud, mqtt explorer shows traffic to the cloud

[nfocke]

@reinhard-brandstaedter and @quellekatalog I also now investigated the hub<->broker communication now using wireshark. sudo wireshark -k -f "host <IP of Hub> and port 1883"

To read the username and password, you have to restart the hub. Then is is transmitted in plain text and can easily be read. Not very secure, but with this info I can probably re-enable user authentication of the MQTT broker.

@quellekatalog not sure if this helps you, but this a typical sequence of the TCP/MQTT communication No. Time Source Destination Protocol Length Info 326 272.583735580 TCP 54 1883 → 63842 [ACK] Seq=87 Ack=469 Win=63784 Len=0 327 272.635842322 MQTT 206 Publish Message [/73bkTV//properties/write/reply] 328 272.635860396 TCP 54 1883 → 63842 [ACK] Seq=87 Ack=621 Win=63784 Len=0 329 272.755269699 MQTT 300 Publish Message [/73bkTV//firmware/report] 330 272.755296532 TCP 54 1883 → 63842 [ACK] Seq=87 Ack=867 Win=63784 Len=0 331 272.880317856 MQTT 364 Publish Message [/73bkTV//properties/report] 332 272.880344079 TCP 54 1883 → 63842 [ACK] Seq=87 Ack=1177 Win=63784 Len=0 333 272.988694878 MQTT 148 Publish Message [/73bkTV//time-sync] .. plus some ping requests from the hub 397 328.738348884 MQTT 60 Ping Request 398 328.738393551 MQTT 56 Ping Response

So it may be that any point of this communication cascade is blocked for you. Can you change/simplify your network structure to isolate the problem? Maybe put hub and broker in a separate WiFi? An make sure that WiFi devices can communicate with each other. Fritzbox e.g. block this by default. In case you are using this.

[reinhard-brandstaedter]

used sudo tcpdump -i any -nn <IP_OF_SF>)

I'm not sure if that command actually does what you intend to do. For a full capture can you try: tcpdump -i <interface mqtt is listening on> -w tcpdump.pcap (don't forget to restart the hub in offline mode while capturing :-)

And then (for convenience) use wireshark to check the contents?

[quellekatalog]

@reinhard-brandstaedter thanks for the hint! captured he traffic of the hub after taking it offline and a restart.

this is just an excerpt, the entire sequence repeats increasing the port number during the ACK i interrupted the recording having the port number counted up to 51507

[quellekatalog]

ha, finally! it was truely an authentication error at the mosquitto! i did not remove the credentials line from the mosquitto config, but only set anonymous to true. but, the hub sent its authentication which did (of course) not equal my defined one which resulted in "no access" now i deleted the credentials line from the mosquitto config, restarted mosquitto... et voila! data is sent ;)

many thanks to all of you guys, @reinhard-brandstaedter @nfocke! for you support!

[reinhard-brandstaedter]

Hi @quellekatalog good to know you got it resolved! I guess I can close this one then!

[boennemann]

I'm getting the exact same behavior unfortunately.

I'm using a Hub 2000 (FW 3.0.8). I extracted the Hub's default mqtt password using the above mentioned mqtt-proxy.

I can extract telemetry via Bluetooh just fine. I can see the Hub successfully connecting to local WiFi and authenticating with local MQTT. I can see the hub responding to messages from solarflow-control

I'm just not seeing any telemetry data.

Restarted both Mosquitto an the Hub to no avail 😬

Edit: My inverter is also not receiving any power at the moment, even though sun is shining an battery was rather full-ish.

[tuxianerDE]

Hey,

have a look at this issue. If you are properly connected as you state, trigger the read command. Please note the telemetry data will only appear if the solarflow-control skript OR the mapper skript is running as the response from the hub is a large JSON that gets desconstructed.

https://github.com/reinhard-brandstaedter/solarflow-bt-manager/issues/9

[boennemann]

@tuxianerDE Thanks for the quick answer!

For all I can tell publishing iot/A8yh63/<ID>/properties/read is already taken care of by solarflow-control. I published it manually as well now, but it doesn't do anything.

The Hub does respond (/A8yh63/<ID>/properties/read/reply) however. Payload:

{"messageId":"123","deviceId":"<ID>","timestamp":1712836299,"success":1,"properties":{"getAll":1}}

The only other message I receive is /A8yh63/<ID>/event/device:

{"messageId":"123","method":"device","deviceId":"<ID>","timestamp":1712836676,"offData":0,"data":{"eventId":3,"startTime":1712836497,"endTime":1712836676,"inout":1,"mode":3,"electric":1381}}

[tuxianerDE]

Ok, so now you are saying it does not do anything anymore? Hub still connected to wifi? Just fir awareness wenn you move the hub offline, you cannot use the app, as this might move the hub back to its original target on the web.

If the hub is not doing anything anymore, can you remove any authentication from your mosquito (we are still testing so let's see that we get it working) and redo the move of the up to bring it offline?

[boennemann]

@tuxianerDE No, sorry when I said but it doesn't do anything I meant the hub responds like above (/A8yh63/<ID>/properties/read/reply), but it doesn't trigger any telemetry being sent.

I'm very aware to not touch the app anymore – all disconnected, not touching/opening.

I'm pretty sure that MQTT auth works, because initially it didn't. I then proceeded to extract the password with the mqtt-proxy and I started both seeing success messages in the mosquitto logs and the replys started appearing.

I'm running my mosquitto instance as a Home Assistant addon, and for all I gather the addon does not support disabling auth altogether.

I'm running the 3.0.8 Fireware and I fear something might be off with that.

My next step would be to setup dnsmasq so I can eavesdrop the MQTT traffic, reconnect the hub to the cloud and check whether something is different when it talks to the cloud 😬

As the maintainers of this tool I guess you have already some sort of preferred stack for doing these protocol reverse engineering tasks. Do you have any hints maybe?

[boennemann]

@tuxianerDE I completely reset the Hub (Press Button for 10sec) and reconnected all over.

What I observed now is that the Hub sends a message on its own initially:

/A8yh63/<ID>/register

{"messageId":"123","deviceId":"<ID>","params":{"token":"abcdefgh","deviceSn":"<SN>"}}

solarflow-control doesn't respond to this, but I'm not sure whether it's necessary. Maybe the hub expects an answer to this now? 🤔

[tuxianerDE]

Hey,

nope it does not at least I get this message too when I connect it. Can you try now again to send the "getAll" payload? or the script to request it?

[tuxianerDE]

@boennemann can you join the fresh created issue 12? there seems the issue to be resolved (other issues to fix) but at least the connect appears and the issue is also open better then working ina closed one.