Changes to use the new JSON API in newer quietcool firmware #2
Conversation
…ds to be updated.
…he API call it came from.
…emp_L and GetTemp_H and avoid dividing it to help make it obvious to the user should they choose to view those sensors. Fixed a mistake done by copilot on GetFanInfo key "G".
|
Hi, I tried to connect (pair) my new fan, but I'm getting the following error. Firmware version on the Quiet fan is 4.1 [18:12:27.640][I][ble_text_sensor:041]: [BLE Data] Connected successfully! |
|
Hi there, sorry github does not seem to notify me of comments. I happened to swing by and check this. (edit: I think I fixed the notifications) I think this looks like the original code, as my pull request would strip the "QQ" which is why you get the "failed to parse JSON" error. I recommend copying the file (without diff markers) by going to the "files changed" tab and hitting the "..." menu to see "view file". From there, theres a little icon for "download raw file" This link may take you directly there. One tell tale that you're sending the new commands is that instead of seeing BLE messages like "Api: "GetFanInfo" you'd see "A":13 (or whatever). I'm also not 100% sure you managed to pair the esphome device or not. You need to hit the "pair BLE" button in homeassistant once you get the device up. From there you may need to restart the device so it can properly login. (Edit) I’d try to get the new code working first though, as the old pair code still works on these newer fan version. Let me know how it goes! |
|
Oh, I forgot to add, instead of using the config as described in the readme, you should copy this file in the pull request to your local machine and use You'll need to edit the mac_address at the top to the fan's mac. (Edit: do this if you haven’t tried it yet out of the new code isn’t fully working) Note, the esphome device holds onto the fan's bluetooth connection, so my suggestion is to get the device in a working state, power it down, use the quietcool phone app to put the fan into pair mode, then power on the esphome device and hit "pair BLE" in HA. |
|
Fan Model: AFG SMT PRO-2.0 (built in bluetooth, firmware 4.1) I installed your changes via remote package on my xiao-esp32c3: substitutions:
mac_address: "<redacted>"
packages:
remote_package: github://kentonr/quietcool-esphome/quietcool-smart-attic-fan-control.yaml@main
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# THIS SECTION OVERRIDES THE PACKAGE HARDWARE
esphome:
name: attic_fan
# The XIAO C3 needs 'dio' flash mode to boot correctly
platformio_options:
board_build.flash_mode: dio
esp32:
board: seeed_xiao_esp32c3
variant: esp32c3
framework:
type: esp-idf
api:
ota:The installation looks fine, and I think I'm paired, or at least connected, as I see this in the logs: But, I don't see anything received. Is there a step I am missing? Am I not paired correctly? As expected, when the xiao-esp32c3 is running and connected, the "smart control" app shows no devices in range. Fan Model: AFG SMT PRO-2.0 (built in bluetooth, firmware 4.1) EDIT: Adding some DEBUG logs: |
|
Hi, This is looking promising, note that response messages are LOGD (debug level) vs LOGI (info). By default you may not see the response. Do you see data in HA? If so then you're good. If not, try the init steps in the readme, which basically have you use your phone to put the fan in pair mode, then you power up the esp32 and hit the "pair ble" button in HA to trigger the pair call. From there, it may take a minute or maybe one last power cycle for things to settle down and data to arrive. Admittedly the ESPHome code isn't a very robust implementation. It's worth noting that changing some of the parameters (like duration of timer mode) is a little flaky, I would recommend changing it then cycling the off and on (if it was on to begin with). For my use case, I cared more about the temp/humidity from the fan vs a weather station and used that to trigger fan automations, so I rarely change the timer setting. If you continue to not see data in HA, Can you set the log to debug mode and share with you see? |
|
Here are some debug logs: I'm not able to see any temp/humidity data. Not sure why I am getting |
|
Seems like something is failing during the pairing process? |
|
(I just saw your latest reply, I edited this comment to the most relevant part. tl;dr: Flash the original code and do the pair steps, then flash to my code and hopefully you're good to go). QQ is another change they made to the API, my version of the code removes the first two chars of the response for this reason, otherwise JSON parsing fails (like you see in the logs of the other comment). In my case, the device was paired by the time I realized the API changed, and I didn't want to test the new pair API as it's been a bit of an ordeal getting the . The fan seems to support the old API at least as far as pairing goes. It's possible that my change to use the new API for pairing does not work. If so, then you should run the original code on your esp32 to pair the device, then switch to my code (no need to pair) to get the data and control the fan. |
|
original code flashed, paired, parsing failing, as expected: I then reflashed your branch, and saw in the logs the esp was able to get gatt chracteristics. i tried toggling a fan "on" in the HA UI, which worked according to the logs, but the fan did not turn on. Still seeing empty "QQ{}" and no temp/humidity data. Logs: |
|
(edit: I replied before I saw your latest, let me write something in a new reply but I keep this one for posterity) oh, I saw that the api is "13" which ties to the login, the "R" param is the result of login (yes it failed) and "P" is indicating whether the device is in pairing mode (based on the emerose python library). I thought it was the pair call (which is API 14 and otherwise is the same). I'm probably late to make this suggestion, but rather than switching your firmware around, you could probably hit "pair ble" for the esphome device in HA and see how that goes. Note that "pair" is not BLE pairing, the device lets anything pair to it to communicate, "pair" in my context is a proprietary API call which you invoke by hitting "pair BLE" in HA once your esphome device is responsive. |
|
I think what you should do is power on your esp and give turning on the fan a try. I have noticed that the fan / esp do not communicate well sometimes shortly after restart (or a BLE reconnect). You may want to even wait a minute (while tailing the logs to see whats happening). [edit: once you stop seeing empty JSON, you could expect to be able to turn on the fan. It's not unusual for the fan /esp to take a minute to stabilize, but once connected and running it's been reliable long term] The logs show empty JSON responses, which makes me think it's not recognized the pair. I suspect that could be because the fan expects a "login" to follow before giving data. That's triggered automatically when the esp is powered on. Hopefully this is the last step. I wouldn't necessarily trust the button / selectable mode states in HA to know if the fan is actually on/off, the "mode" property is most reliable as it's gotten from the fan itself. |
|
Thanks for the help - will give this a try in a couple hours and report back! |
|
No luck. I've tried turning the fan off, then on. Logs for this sequence: Is I waited 10-15 mins for the fan and esp to stabilize, but still see this stream of logs: I tried to turn it "on" via HA and the request is sent (no errors in logs), but nothing happens even after waiting 10-15 mins. Out of curiosity, what is the fan model and firmware that you have got this working on? |
|
Regarding my fan, I have the AFG SMT PRO-2.0 (same as you) but firmware version 3.9(!) Here's some sample logs, though for full disclosure, I have a modified esphome config as I am controlling two fans (in logs as east and west) with one device (but the code is effectively equivalent): Sorry for the long output, I thought it was illustrative as you can see at the beginning east was working but west was returning QQ{} (empty json) because the connection it had at the time was no good. It eventually reconnected and everything worked again. To see Suspecting yet another API change, I took a look at the latest app. At a cursory glance it doesn't seem like its different at least in how it communicates. You can see this yourself if you can sniff the BLE comms your phone makes to the fan (easy-ish on an Android device, iOS requires a mac with xcode). I have an iOS device but no mac, so I ended up discovering the API change via static analysis of the android app. An elementary question and a bit of a reach: did you change the Pair ID property? The one whose default is If that doesn't work, I'm unfortunately out of ideas. My guess is still that somehow your esphome is not properly paired. |
|
Alright, I seem to have figured out the issue, but not a pretty solution. I decompiled the latest app and with some LLM help, reversed it to understand API changes, and also did not see anything significant. After some back and forth, I thought why not pair a new phone via the app - I tried with the iOS app, and after the app tying to pair for some time, it returned "device memory full". This probably happened while I sent a bunch of pairing requests with unique pair IDs (not recognizing that I needed to use your branch to have it work right, doing it on the "original" "non-QQ" api). I then recalled I had a JS script from long ago that I paired with, which I used a 10 character pairing ID..so I figured I'll use that as my pairing id with this branch that sets the min length to 10, and I've got data coming through. So all is working now. The problem? I can't access my fan (closed up in attic) to do a physical "pair request" so looks like I'm stuck with the pairings in there.
|
|
Im glad you got it to work in the end. It’s surprising that it could run out of memory, there must be quite a lot of pair ids in there. I agree with you about (2), I’m in a similar boat where my fans are inaccessible and I can’t risk factory resetting them and needing physical access to do the initial pair either. Happy holidays! |
3 participants
I recently had quietcool attic fans installed and upon trying to connect them, I found I wasn't getting the sensor data.
Looking at the logs from the ESP device, I suspected an API change had occurred. With some research, I was able to confirm this as well as figure out how it was changed. On the whole, the API is somewhat made obfuscated, but purely by remapping the JSON keys to something else.
I think some of the older commands somewhat work with the old API, as I didn't need to re-pair my ESPHome device, but I chose to update all the API calls regardless.
Ultimately, this pull request should just be left alone, as I think your original code is valid for folks on older firmware while this code is valid for newer firmware.
I tested the sensor values, however I did not test the new pairing process (my fans are relatively-to-largely inaccessible, so I can't risk resetting them and needing to physically reach them). I also did not test turning on the fans either continuously or for a set time as I did not want to mess with the "smart" mode they're on for now.