From a0fe5fe1ef97650afe06574a66c23919f4e70f40 Mon Sep 17 00:00:00 2001 From: Fabrice Kirchner Date: Sat, 13 Apr 2024 10:06:52 +0200 Subject: [PATCH 1/3] Fix timing problem with register reply --- src/requirements.txt | 3 +-- src/solarflow-bt-manager.py | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/src/requirements.txt b/src/requirements.txt index 5534c37..5f9c1b2 100644 --- a/src/requirements.txt +++ b/src/requirements.txt @@ -1,2 +1 @@ -bleak -paho-mqtt \ No newline at end of file +paho-mqtt==1.6.1 diff --git a/src/solarflow-bt-manager.py b/src/solarflow-bt-manager.py index 366d094..20b6fa3 100644 --- a/src/solarflow-bt-manager.py +++ b/src/solarflow-bt-manager.py @@ -37,7 +37,7 @@ def on_connect(client, userdata, flags, rc): log.error("Failed to connect, return code %d\n", rc) def local_mqtt_connect(broker, port): - client = mqtt_client.Client(mqtt_client.CallbackAPIVersion.VERSION1, client_id="solarflow-bt") + client = mqtt_client.Client(client_id="solarflow-bt") if mqtt_user is not None and mqtt_pwd is not None: client.username_pw_set(mqtt_user, mqtt_pwd) client.connect(broker,port) @@ -92,7 +92,7 @@ async def set_IoT_Url(client,broker,port,ssid,deviceid): log.exception("Setting WiFi Mode failed") if mq_client: - mq_client.publish(f'iot/{SF_PRODUCT_ID}/{deviceid}/register/replay',reply) + mq_client.publish(f'iot/{SF_PRODUCT_ID}/{deviceid}/register/replay', reply, retain=True) def handle_rx(BleakGATTCharacteristic, data: bytearray): From c262fa4dba9051df6d30fa5c9134ce660ceb1673 Mon Sep 17 00:00:00 2001 From: Fabrice Kirchner Date: Sat, 13 Apr 2024 10:08:40 +0200 Subject: [PATCH 2/3] Fix timing problem with register reply --- src/requirements.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/src/requirements.txt b/src/requirements.txt index 5f9c1b2..ab5f8fa 100644 --- a/src/requirements.txt +++ b/src/requirements.txt @@ -1 +1,2 @@ +bleak paho-mqtt==1.6.1 From b9658c7db93fe8418319f09a85484557f137d99b Mon Sep 17 00:00:00 2001 From: Fabrice Kirchner Date: Sat, 13 Apr 2024 10:16:14 +0200 Subject: [PATCH 3/3] Added requirements and env variable to Readme --- README.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 1b050cf..85f2be6 100644 --- a/README.md +++ b/README.md @@ -56,7 +56,7 @@ The proxy mode means your SF Hub will still report some device data to Zendure's To gather telemetry data you will need to run the BT manager tool as a service on a BT-enabled device (such as a Raspberry Pi) within range of your hub. The BT manager will continously collect telemetry data and report it to MQTT for you. -*Note:* I've been using this mode for some time and it worked mostly flawless. From time to time I had the bluetooth connection drop (using a Raspberry Pi Zero W) and it wouldn't reconnect to the hub. I either had to force drop the BT connection on the RasPi or on the hub by briefly diconnecting it from the WiFi (kickin it out of my Access Point) +*Note:* I've been using this mode for some time and it worked mostly flawless. From time to time I had the bluetooth connection drop (using a Raspberry Pi Zero W) and it wouldn't reconnect to the hub. I either had to force drop the BT connection on the RasPi or on the hub by briefly diconnecting it from the WiFi (kickin it out of my Access Point) ### Getting Basic Information To get basic information about the hub (without performing any changes) run the script with the -i option only: @@ -92,7 +92,7 @@ You can use that data for any other integration (e.g. Homeautomation systems etc E.g. my [Solarflow Statuspage](https://github.com/reinhard-brandstaedter/solarflow-statuspage) is now also using this data instead of the cloud data. > [!NOTE] -> While the bluetooth connection is enabled, the hub ONLY reports telemetry via BT! There will be no data sent in parallel to the Zendure Cloud broker. As a consequence you will not see any data in the mobile app. You can still control the hub though via the app. +> While the bluetooth connection is enabled, the hub ONLY reports telemetry via BT! There will be no data sent in parallel to the Zendure Cloud broker. As a consequence you will not see any data in the mobile app. You can still control the hub though via the app. ### Disconnecting the hub from the cloud You can completely disconnect the hub from the Zendure cloud and have it report to a local MQTT broker. It will then not send any data to the cloud but you will also not be able to change any settings with the app. From that point on you can only control the hub via your local MQTT broker. This gives you full control but is for advanced usage (e.g. setting the output limit to any arbitrary value) @@ -104,15 +104,20 @@ Disconnecting works by reinitializing the hubs network connection (WiFi) and tel (eventually you need to change the WiFi first to another network before joining the target network) ``` +$ pip3 install -r requirements.txt $ export WIFI_PWD="your_wifi_password" $ export SF_DEVICE_ID="your_sf_deviceid" +# your_sf_productid is 73bkTV for Hub1200 or A8yh63 for Hub2000 +$ export SF_PRODUCT_ID="your_sf_productid" $ python3 solarflow-bt-manager.py -d -w -b ``` example: ``` +$ pip3 install -r requirements.txt $ export WIFI_PWD="Sup3rS3cret!" $ export SF_DEVICE_ID="5ak8yGU7" +$ export SF_PRODUCT_ID="73bkTV" $ python3 solarflow-bt-manager.py -d -w SuperWiFi -b 192.168.1.245 ``` @@ -139,6 +144,7 @@ Yoy can reconnect to hub back to Zendure's cloud again. This might be necessary ``` $ export WIFI_PWD="your_wifi_password" $ export SF_DEVICE_ID="your_sf_deviceid" +$ export SF_PRODUCT_ID="73bkTV" $ python3 solarflow-bt-manager.py -c -w ```