Switchbot detection #1288
Comments
|
Here we go, the first actual scan (I saw) with data: |
|
Might the issue be that I assumed the meter readings should stay whereas they are only advertised when announced by the switchbot? I feel absurdly stupid. Yes - the readings are all there. It was just my assumption that was wrong! |
No, that is not the case! There are too little proper readings from your SwitchBot Meter, and while you might have mistaken things a bit with the readings staying - they will once you incorporate the MQTT messages into a controller backend like Home Assistand, OpenHAB etc. - and looking at your data the decoder doesn't decode all the messages. Do you have the SwitchBot Meter in Add Mode by any chance? If so can you switch it into Normal Mode? It is the If you still do, even after having the device in Normal Mode, please continue to post these messages here, as they then do not adhere to the SwitchBot documented encoding, but might be some not yet documented decoding of newly released Meters. Then we can add those decoding guidelines to then Theengs Decoder for more frequent correctly decoded messages. |
|
It was a pebkac (problem exists between keyboard and computer). Clearly, my assumptions made me blind for what was right in front of me, i.e. this project merely mirroring signals from bluetooth to MQTT. I do apologize for wasting your time @DigiH. And I do want to express my gratitude to all maintainers and developers for making an awesome project. Hopefully not all users are so blind as me haha. Can we close this? |
|
Please see my message above, while you might have mistaken a few things a bit, you are very correct in stating that not all the messages are decoded which could/should be decoded, due to the fast that your SwitchBot Meter might be a very recent purchase with a slightly newer format which isn't fully recognised by the Decoder yet. So thanks for pointing this out! There should never be any message from your SwitchBot Meter which has any If there is only |
|
Thanks. I feel a tad less stupid now! So the servicedata was a pretty common occurence, and while I looked through your code last night - I did pick up on it containing the readings. That's why I figured there was something wrong, I also tried compiling with your decoder library but that made no difference. I'm guessing the "add" mode is when I'm pressing the button? For what it's worth, the other project* has been running since yesterday and has been updating my broker very regularly. What can I do to help with the new format? |
If you are compiling your builds with Platformio, you can just change the Decoder URL in the platformio.ini file from
to
to test the decoder changes I just uploaded. Then rebuild and upload OMG again to your ESP32. You should not see any undecoded messages now which include " |
|
Adding the device ID (i.e. the SBMT-test branch) has worked. Here's what's happening now:
This is sweet! I think this resolves the issue and now I have every excuse I need to get working on OMG <-> Homie integration ;-) Thank you @DigiH, much appreciated and such speed! |
Great, I'll will be looking forward to your Homie integration!
Thank you for pointing this out, and helping along to pinpoint and verify this different ID! As this is not documented on the official SwitchBot API pages (yet). I have merged this into the official Theengs Decoder development branch, and will delete my test branch soon. So if you have to rebuild for any reason please use decoder = https://github.com/theengs/decoder for any future builds. Thanks again! Please also close this OMG issue, if you're happy with the changes. Thanks |
I'm almost looking forward to fighting with the compiler! I do love the language but man, compilers and I never C eye to eye ;)
You're most welcome!
Just rebuilded to switch back from *-cont to esp32-dev-ble and used that repository.
I am happy with the solution. I'm going to put on some monitoring and have it run over night, see how many times it published sensor data - and hopefully this can be the start of a beautiful array of BLE devices broadcasting sensors for OMG to pick up. Cheers! |
|
After @DigiH fixed the issue, I recompiled to esp32-dev-ble (verified it used the fix) and had two ESP32's running side by side. One with OMG and another with SwitchBot-MQTT-BLE-ESP32. Both with the defaults + WiFi configuration. I monitored them via a tmux-background window and mosquitto-sub, i.e.: The log files are here: switcbot-mqtt-ble-esp32.log and openmqttgateway.log Here are some interesting bits: In short:
I'm going to restart the *-cont version to see how often it'll report sensor data. I do recall it showing 10+ sensor readings in a small window @DigiH can you advise? I'm guessing 170 sensor readings over 5 days is very low. Am I missing something? |
Yes, absolutely, and great that you made these logs. The openmqttgateway.log clearly shows that most of the messages received from the SwitchBot Meter have manufacturerdata only in them, missing the servicedata required for Theengs Decpder decoding.
Did you see any changes with the *-cont version, more specifically, was more data with servicedata being picked up and was therefor decoded? Do you have a sample log with the *-cont version? I just looked at the official SwitchBot BLE API again and realised that there are two formats for the Meters: (Old) Broadcast Message - Manufacturer data If and why your Meter seems to send out both formats, and if the manufacturerdata contains all the information - I'll have to have a closer look, only saw that the last byte looks like being the humidity. Which firmware version does your Meter have? Might there be a firmware update for it in the SwitchBot app? Any chance of resetting your Meter, to see how it behaves after a default resetting/new start? Generally I'd expect the Meter to be picked up roughly every minutes, as it already is now with the default OMG BLE binary, but with it transmitting data which can/is being decoded, so correct data from the Meter every minute. |
|
As I don't have a SwitchBot Meter myself I just checked with a colleague, and his logging shows the opposite of yours. In general the messages received by his SwitchBot Meter do contain both the manufacturerdata and servicedata, with the servicedata correctly being decoded and the wanted information included in the messages. Only now and then his Meter messages also only contain the manufacturerdata and are not being decoded, which unfortunately is the majority with your device.
Thanks |
|
Hi. Hopefully I haven't missed answering a question.
ConfigLogAt 16:03 (UTC) I pressed the bluetooth button to see what would happen, the bluetooth indicator lighted and it got picked up. So there may be a bit of a nuance in the data around that timestamp. |
|
Hi, The 'fix' I implemented previously, which allows for the 49… servicedata to be decoded, should actually be taken out again, as 49… servicedata indicates being in ADD MODE, which only last for 120 seconds, as can be seen in your
but will/should never appear in normal broadcast mode.
Yes, the configuration looks fine, the steps you follow sound fine, but why so many manufacturerdata only messages is still a mystery to me. If the longer log will be not serial, but as the above ones with mosquitto-sub, that will be great. Just out of curiosity - you haven't set ActiveBLEScan in config_BT.h to false by any chance, possibly for some other environment/test? Have all the different OMG tests been done on the same ESP32? Looking forward to your longer logs. |
|
Hi, Before filing this issue, I repulled 0.9.16 and had a clean tree. Today I moved to the development branch. Git reports my tree is clean (gitignore ignores env files). So ActiveBLEScan is default, in config_BT.h: I've started a subscriber for mosquitto-sub Things do appear to be going much better so far. I've had more sensor readings by OMG than I've had in the past 10 days. Here's a preview of the formatted logs so far: - edit - I've ran OMG on 2 different ESPs. One of those is was eventually flashed with SwitchBot-MQTT-ESP - which is currently off. |
|
The to make it a Thanks |
|
For completeness: it reported sensor readings 43 times in approximately 2 hours. A lot more than previously - but still less than what your friend sees. switched to the new build flags, and here's the log: time (in seconds) between sensor readings:- edit - Just unpacked a new ESP for testing; and it -won't- connect to WiFi with the exact same configuration, i.e. all I did was press "upload". Starting to wonder if there may be remnants of a previous configuration dangling around on the other 2 ESPs. Added '-DESPWifiManualSetup=true' and now it connects fine. Curious to see what results I'm getting on a brand new ESP. |
|
Wow. On a brand new ESP, with these opts: This is happening: So perhaps the other 2 ESP32s need a full reflash?(I did believe the "upload" on platformio did that.) So something weird happened. I grabbed an ESP32 that was lying around, I pressed 'upload' and it wasn't able to connect to WiFi. FIgured it was a fluke, and unpacked a new one. Same problem. Added the So apparently the other 2 ESPs still have dangling settings running afoul? New ESP: 5 minutes & 36 sensor readings.... |
Best to erase the Flash before uploading a new configuration to a new or well used ESP32. Worth a try with these two.
in the platformio terminal will do the trick.
Well, more regular decoded readings than the previous Still very curious as to why there are so many more manufacturerdata only messages than decoded ones including the servicedata, when it should be the other way round. But this clearly shows that with the default the 10 second scan window every 55 seconds could/would easily fall into several manufacturerdata only broadcasts, continuously only showing these for a long time, even if correctly decoded servicedata messages had been broadcast during the TimeBtwRead - when no OMG scan occurs. What you saw before with the default environment/binary. Is/was the SwitchBot Meter linked to a SwitchBot Hub at all? Any improvements after clearing the flash before a new upload? |
if you use manual WiFi and MQTT broker credentials, as in your environment above you will always also have to set as otherwise the above should be recognised. As it is indicated in the above environment. |
|
Yeah, so I did start off with the binary release - and that didn't give me sensor data. So I moved on to building myself and fiddling with settings. So presumably increasing the window might solve the issue? I don't have or own a hub. So on the brand new ESP is off and I've wiped one of the previous ESPs, cleaned the environment, built and uploaded it. These are the logs: So the brand new ESP actually flooded the logs with sensor data but that also returned to manufacturerdata. So it was mostlikely a fluke. Presumably changing/increase the window would solve it? |
|
with regards to the window: I wasn't reading correctly. You meant with the regular release, not the adjusted settings we've been using, correct?
Yes, but with the ESP I had been testing on, I hadn't set that flag for the datatest environment. It still connected to WiFi whereas 2 other ESPs failed to do so. So there must have been dangling resources/configuration going on. I'm inclinded to let the new ESP run for a night and see how it fares. So far it's been doing so much better even though it does seem to get flooded with manufacturer-only messages everyonce in a while. |
Yes, I would think having a go with the Just to show that something is still amiss is the comparison between your -cont log and the colleague's -cont log
That right side would also be the ideal for your SwichBot Meter as well! Why there seems to be a majority of manufacturerdata only messages is beyond me at this stage, but I think we found, that with nicely adjusted
Correct, that was meant for the regular default ble release, using these default settings as a comparison. |
|
That's a huge difference. With the new ESP, I've been seeing only manufacturer data for more than 5 minutes now and that's with I'm going to google around some more and see if I can find a project that allows me to use an ESP32 as a BLE-receiver and inspect that data in Wireshark. Presumably, we'd get a little bit more raw information about what's going on. Something tells me that my Switchbot is looking for a hub, or it maybe found a hub (that isn't mine) somewhere near me. Or that it's looking for registration or something along those lines. i.e. that it's saying "I'm here" w/ the manufacturer only data. Thanks for the help. It's really nice, I'll update when I get the chance! |
|
Hello, Do you mind sharing a picture of the back of your sensor. The goal is to check for any model difference. |
with the PR
Mostly manufacturer only readings esphomeThe nimble example gave me a bit of grieve so I figured: let's try ESPHome's Default tracker config Excerpt from the serial console: It reads about once a minute w/ service data. The component warning happens after some devices, but not all. Interestingly to note is that the manufacturer data changes whereas with OMG it stays the same, i.e. from one of my So far ESPHome's output is comparable with Theengs, compared the data into ESPHome's dotted format for readability i.e.
Why do you think OMG's is prefixed by 69.09 instead of the mac address such as the others? |
Could you elaborate on this?
|
I was in a bit of a rush (had a few moments in between work), so I figured I'd quickly install Arduino's IDE; but found Arduino's web IDE instead. So I imported the library and added the example, but it wouldn't compile. It ran into an issue looking for a config.h file. I figured, I'd look into it a little bit later. So I did, and then it ran into missing FreeRTOS (iirc) and so I added that, but that didn't pan out. So again, I figured I'd look into it a bit later and in the meantime I just flashed ESPHome w/ some config to get some data. So nimble example gave me a bit of grieve really means I'm still very inexperienced in the ESP* ecosystem and haven't found my way around yet :) Truth be told, I probably overlooked something obvious; or read over something while it was staring me in the face.
Ah, that makes sense. I'll be giving the nimble example another try - hopefully later today - to see if I can confirm the observations made with ESPHome. -- I do want to express my gratitude to all of you, and especially @DigiH for all his time and effort, for helping me out and looking into this! |
Not quite the case ;) as with OMG/Decoder the manufacturerdata also changes, as the last 3 bytes do actually contain the temperature and humidity information (no battery). Easily visible when both manufacturerdata and servicedata are present {"@timestamp":"2022-10-22T20:07:20+02:00","batt":100,"brand":"SwitchBot","hum":74,"id":"C6:C7:52:66:3C:BF","mac_type":1,"manufacturerdata":"6909c6c752663cbf160b09914a","model":"Meter (Plus)","model_id":"THX1/W230150X","rssi":-33,"servicedata":"6980e409914a","servicedatauuid":"0xfd3d","tempc":17.9,"tempf":64.22} Unfortunately when it is a manufacturerdata only transmission there is no additional clear identification as with the servicedata's device type and the servicedatauuid to uniquely identify this device to be able to use manufacturerdata only for a clear decoding. {"@timestamp":"2022-10-22T20:08:51+02:00","id":"C6:C7:52:66:3C:BF","mac_type":1,"manufacturerdata":"6909c6c752663cbf160b09914a","rssi":-33} |
|
Here are the logs of the NimBLE example: [c6:c7:52:66:3c:bf = the switchbot]
@h2zero The problem was either with me and/or the web ide. After installing Arduino's IDE locally, I got the example running in less than 5 minutes flat w/o any fuzz. Plan:So far - BLE-scanner (the nimble example) has only picked up the switchbot with service data. The service data isn't very readable, so I'll try to adjust that to something more readable for us. At the very least, it does appear (as suggested by Theengs GW and ESPHome) there are no readings without service data. I'm also going to flash an ESP with OMG-BLE-CONT and log the output of that. Presumably, at some point it'll randomly pick up a sensor reading; and we'll be able to compare its reading w/ the output from BLE-scanner. [edit] Modified the nimble example to filter on the MAC of the switchbot + decode the service data. I'm not a hero in these languages but I'm hopeful I did it correctly: https://gist.github.com/xanderificnl/c264238e4318f6462c6db1f83559f563 Here's an example of output (decode values are prefixed with '>>'): |
|
Let me try to run it on my side with my switchbot, and share what I see |
|
I tried in my side with different versions of NimBLEArduino and the sketch below but got constant reporting of servicedata. Could you try this sketch please with NimBLEArduino v1.3.8 and share your logs: /** Example of continuous scanning for BLE advertisements.
* This example will scan forever while consuming as few resources as possible
* and report all advertisments on the serial monitor.
*
* Created: on January 31 2021
* Author: H2zero
*
*/
#include "NimBLEDevice.h"
NimBLEScan* pBLEScan;
std::string convertServiceData(std::string deviceServiceData) {
int serviceDataLength = (int)deviceServiceData.length();
char spr[2 * serviceDataLength + 1];
for (int i = 0; i < serviceDataLength; i++) sprintf(spr + 2 * i, "%.2x", (unsigned char)deviceServiceData[i]);
spr[2 * serviceDataLength] = 0;
return spr;
}
class MyAdvertisedDeviceCallbacks: public NimBLEAdvertisedDeviceCallbacks {
void onResult(NimBLEAdvertisedDevice* advertisedDevice) {
Serial.println("-----------------------------------------------------------------------------------");
Serial.printf("Advertised Device mac: %s \n", advertisedDevice->getAddress().toString().c_str());
Serial.printf("Advertised Device name: %s \n", (char*)advertisedDevice->getName().c_str());
if (advertisedDevice->haveManufacturerData()) {
char* manufacturerdata = BLEUtils::buildHexData(NULL, (uint8_t*)advertisedDevice->getManufacturerData().data(), advertisedDevice->getManufacturerData().length());
Serial.printf("Advertised Device manufacturer data: %s \n", manufacturerdata);
free(manufacturerdata);
}
if (advertisedDevice->haveServiceData()) {
int serviceDataCount = advertisedDevice->getServiceDataCount();
Serial.printf("Get services data number: %d \n", serviceDataCount);
for (int j = 0; j < serviceDataCount; j++) {
std::string service_data = convertServiceData(advertisedDevice->getServiceData(j));
Serial.printf("Service data: %s \n", service_data.c_str());
std::string serviceDatauuid = advertisedDevice->getServiceDataUUID(j).toString();
Serial.printf("Service data UUID: %s \n", (char*)serviceDatauuid.c_str());
}
}
}
};
void setup() {
Serial.begin(115200);
Serial.println("Scanning...");
/** *Optional* Sets the filtering mode used by the scanner in the BLE controller.
*
* Can be one of:
* CONFIG_BTDM_SCAN_DUPL_TYPE_DEVICE (0) (default)
* Filter by device address only, advertisements from the same address will be reported only once.
*
* CONFIG_BTDM_SCAN_DUPL_TYPE_DATA (1)
* Filter by data only, advertisements with the same data will only be reported once,
* even from different addresses.
*
* CONFIG_BTDM_SCAN_DUPL_TYPE_DATA_DEVICE (2)
* Filter by address and data, advertisements from the same address will be reported only once,
* except if the data in the advertisement has changed, then it will be reported again.
*
* Can only be used BEFORE calling NimBLEDevice::init.
*/
NimBLEDevice::setScanFilterMode(CONFIG_BTDM_SCAN_DUPL_TYPE_DEVICE);
/** *Optional* Sets the scan filter cache size in the BLE controller.
* When the number of duplicate advertisements seen by the controller
* reaches this value it will clear the cache and start reporting previously
* seen devices. The larger this number, the longer time between repeated
* device reports. Range 10 - 1000. (default 20)
*
* Can only be used BEFORE calling NimBLEDevice::init.
*/
NimBLEDevice::setScanDuplicateCacheSize(200);
NimBLEDevice::init("");
pBLEScan = NimBLEDevice::getScan(); //create new scan
// Set the callback for when devices are discovered, no duplicates.
pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks(), false);
pBLEScan->setActiveScan(true); // Set active scanning, this will get more data from the advertiser.
pBLEScan->setInterval(97); // How often the scan occurs / switches channels; in milliseconds,
pBLEScan->setWindow(37); // How long to scan during the interval; in milliseconds.
pBLEScan->setMaxResults(0); // do not store the scan results, use callback only.
}
void loop() {
// If an error occurs that stops the scan, it will be restarted here.
if(pBLEScan->isScanning() == false) {
// Start scan with: duration = 0 seconds(forever), no scan end callback, not a continuation of a previous scan.
pBLEScan->start(0, nullptr, false);
}
delay(2000);
} |
|
Attached is the log. Notably, the switchbot got picked up with the service data a total of 113 times. Somehow, only OMG is picking up manufacturer-only data on various ESP32s. So why is OMG seeing manufacturer only data and nothing else is? I've run 3 different nimble continuous scanners (the default, yours and mine), ESPHome and Theengs Gateway (on my laptop). Can we get OMG to dump what it sees to serial before it starts processing it? |
|
Thanks for sharing this, we can see that the servicedata is retrieved constantly when focusing on the library functions only.
Yes you would need to set the debug log level to Or add this into your pio env |
|
Cheers, thanks! You can skip forward to [interesting bit] below. The final tally of the library functions: 289 broadcasts - all including service data. Steps:
Full config: [platformio]
default_envs =
esp32dev-ble-cont
;esp32 cnt
[env:esp32dev-ble-cont]
platform = ${com.esp32_platform}
board = esp32dev
board_build.partitions = min_spiffs.csv
lib_deps =
${com-esp.lib_deps}
${libraries.wifimanager32}
${libraries.ble}
${libraries.decoder}
build_flags =
${com-esp.build_flags}
'-DZgatewayBT="BT"'
'-DLED_SEND_RECEIVE=2'
'-DLED_SEND_RECEIVE_ON=0'
'-DGateway_Name="kfwnlnfkwl"'
'-DAttemptBLEConnect=false'
'-DMQTT_SERVER="172.16.32.2"'
'-Dwifi_ssid="XiFi"'
'-Dwifi_password="-snip-"'
'-DESPWifiManualSetup=true'
'-DLOG_LEVEL=LOG_LEVEL_TRACE'
upload_port = /dev/ttyUSB0interesting bitserial.log <-- LOG before my edit After not seeing anything standing out, I modified Which yielded the familiar:
and this starts to happen: and I'm starting to see this (previously unseen): At this point, restarting the ESP may result in the Switchbot being seen or not at all (missing the window permanently, it seems). What's strange is that Theengs' Gateway was about to get 16 readings per minute from the Switchbot [via my laptop]. So I'll:
Any advice and suggestions are appreciated. |
|
I think it is progressing well, thanks to your thorough testing. If you could try OMG only with this modification: It would enable pinpointing the continuous scan versus the windows/interval modification as a potential cause. |
|
So I so as far as I can see, it missed one beat at 19:53 which isn't very interesting on its own. |
|
Cool, seems But doesn't explain why we have missing service data with |
|
Running with the default esp32dev-ble at the moment with trace on. One thing that stands out is that good readings are processed before the scan ends, and readings without service data are processed after the scan ends. Is it possible that OMG is freeing the data before it's retrieved? Here's a clean reading for reference: Here's a bad reading. Ever since starting to look into this problem, I've seen garbled serial output, and I assumed it was simply the serial connection. Yet, as far as I can tell, proper readings are outputted nice and tidy and bad readings are generally accompanied by garbled output. |
|
Very interesting from the log: Looks like the switchbot was only just detected as the scan ended and results in missing data. What I suspect is going on is that the switchbot advertisement was detected but no scan response had been received when the scan ended. When this occurs NimBLE will invoke the callback with whatever data it does have, complete or not, which in this case it was not. Since the device advertises about every 10 seconds, I would adjust the scan duration to 15 seconds to allow more time to get the scan response data. |
|
Currently running w/ '-DScan_duration=15000' Results in: I am fairly sure the Switchbot advertises a bit more than once per 10 seconds. Theengs' Gateway on my laptop picked up 16 sensor readings a minute, so that's about once per 3-4 seconds. Theengs' readings for reference: Ran with |
|
Thanks for that, could you try one more thing? I'm curious what happens if you set the scan duration to 6 seconds instead. It's possible that this is caused by NimBLE when seeing the device multiple times during the scan. |
|
Scan_duration to 6000 Results: With 2 seconds: FWIW, a comparison of OMG & Theengs from MQTT:
|
|
Hmm, not really what I expected but here is a NimBLE branch to try: https://github.com/h2zero/NimBLE-Arduino/tree/adv-data-fix |
|
To confirm: Running with 10s: Running with 6s: Does NimBLE have an underlying flag to enable trace logs? From outside tests (nimble examples, Theengs', ESPhome, etc.) we know the service data is always transmitted; but it'd be nice if we can literally tell the data was picked up by OMG at some point. Can we dump a representation of NimBLEAdvertisedDevice as it is created? Life would be so much simpler if we could debug with gdb. |
|
Thanks for testing, you can enable NimBLE logs with When the device is created is when the callback is called and you get a reference to it, you can then call |
|
Thanks for all the hard work you've given to the community and the help you're providing me. It's much appreciated :) Initially I inserted this into OMG's callback: char* payload = BLEUtils::buildHexData(NULL, (uint8_t*)advertisedDevice->getPayload(), advertisedDevice->getPayloadLength());
Log.trace(F("[payload] %s: %s" CR), advertisedDevice->getAddress().toString().c_str(), payload);That resulted in: At this point, I figured I could just copy an example by technophile, and insert that: Serial.println("begin-----------------------------------------------------------------------------------");
Serial.printf("Advertised Device mac: %s \n", advertisedDevice->getAddress().toString().c_str());
Serial.printf("Advertised Device name: %s \n", (char*)advertisedDevice->getName().c_str());
if (advertisedDevice->haveManufacturerData()) {
char* manufacturerdata = BLEUtils::buildHexData(NULL, (uint8_t*)advertisedDevice->getManufacturerData().data(), advertisedDevice->getManufacturerData().length());
Serial.printf("Advertised Device manufacturer data: %s \n", manufacturerdata);
free(manufacturerdata);
}
if (advertisedDevice->haveServiceData()) {
int serviceDataCount = advertisedDevice->getServiceDataCount();
Serial.printf("Get services data number: %d \n", serviceDataCount);
for (int j = 0; j < serviceDataCount; j++) {
std::string service_data = NimBLEUtils::buildHexData(nullptr, (uint8_t*)advertisedDevice->getServiceData().data(), advertisedDevice->getServiceData().length());
Serial.printf("Service data: %s \n", service_data.c_str());
std::string serviceDatauuid = advertisedDevice->getServiceDataUUID(j).toString();
Serial.printf("Service data UUID: %s \n", (char*)serviceDatauuid.c_str());
}
}
Serial.println("end-----------------------------------------------------------------------------------");also updated the queue sender to tell us when that happens, i.e. if (xQueueSend(BLEQueue, &advertisedDevice, 0) != pdTRUE) {
Log.error(F("BLEQueue full" CR));
} else {
Log.trace(F("[xQueueSend] %s" CR), advertisedDevice->getAddress().toString().c_str());
}And here's a good reading: and a bad reading: edit also, here's a good reading w/ both payload & the extra data: and one w/o reading: To be honest, I'm getting a bit far out of my depth and I'm content to just letting it run with scan duration 0; but I'm more than happy to help trying to debug/narrow down this issue. |
|
You're welcome 😀 and thanks for your efforts as well, that's some great detailed troubleshooting! Now for the issue at hand. From the good reading: From the bad reading: As to why this is happening, this would be incredibly hard to know for certain with logs alone. This could be due to a number of factors such as the device simply didn't receive the scan response request, or went to sleep. On our side there could have been an interruption in the receiver at the moment it was sent (think WiFi, due to shared antenna), radio interference, BLE stack bugs or bad timing. The interesting thing about the applications that do work is that they are not simultaneously processing WiFi packets while scanning BLE, it would not surprise me if this was ultimately the root cause. Potential improvement might be provided by setting |
|
For what it's worth, the ESP and the switchbot are within 20 cm of each other. I'll try the window + interval shortly. We might also try disabling wifi fully (not sure how easy that'd be with OMG) since we can still see all the data over serial. Thanks :) |
|
I'm not sure about fully disabling WiFi, could be quite difficult. Hopefully there is some improvement with those settings though, let me know if it helps. |
|
I've just realized you may have missed that message. Technophile and I discovered that a scan_interval of 0 with the default OMG settings yielded at least one reading a minute, and sometimes two. During that run there were max 5 missing readings in a timeframe of a couple of hours. See this message. Anyway, setting the scan interval & window to 37 does seem to work as well. I've seen a couple serviceless data so far, but mostly readings. So scan interval 0 still seems to pick up more and at slightly higher intervals (i.e. it takes about 60-70 seconds for each reading w/ these settings). I've yet to see a wifi or mqtt disconnect. If there's anything else you'd like me to try/run, I'm more than happy to narrow down this issue further. With the way OMG's output gets garbled, I've also wondered if maybe the multithreading may be causing things to run amok - but yesterday (or earlier) I already disabled the 2 lines switching/disabling/enabling cores and that made no difference. |
|
Glad those settings made an improvement! Yes, setting the scan duration to 0 for continuous scanning would work as well simply due to the scan having more opportunities to receive all the data. I'm not sure how much better we can get than this, if I think of anything else I'll let you know. |
|
Cheers, thanks everyone! |
|
How have you been getting along with the above issue? While most users seem to be getting the servicedata included, I am asking again here, as a very similar issue has been cropping up with the SwitchBot Outdoor Meter From your above postings I can see that the manufacturerdata for the Meter Plus is one octet shorter than the Outdoor Meter, but I'm still a bit worried that other SwitchBot devices might fall under the same manufacturerdata only messages, as the uniquely identifying device ID is broadcast only with the servicedata. We could still try and change the Meter (Plus( decoder in the same way for you to run so0me tests, if you are still seeing this issue. For the Meter (Plus) there also seems to be some documentation about changing the advertisement broadcast mode https://github.com/OpenWonderLabs/SwitchBotAPI-BLE/blob/latest/devicetypes/meter.md#broadcast-mode which might also be an additional thing for you to try out. |
|
Unfortunately looking more into the other threads Outdoor Meter data, is is the same, the servicedata/uuid is really is required to uniquely identify the SwitchBot devices. So using the manufacturerdata only is unfortunately not an option. |
N: Scan begin
N: Send on /BTtoMQTT/C6C752663CBF msg {"id":"C6:C7:52:66:3C:BF","mac_type":1,"manufacturerdata":"6909c6c752663cbf850f049243","rssi":-63}
N: Found 0 devices, scan number 61 end
N: Scan begin
N: Found 1 devices, scan number N62 en: d
Device detected: C6:C7:52:66:3C:BF
Describe the bug
OpenMQTTGateway isn't recognizing my Switchbot Meter Plus properly.
To Reproduce
Expected behavior
For it to recognize my Switchbot Meter Plus.
Environment (please complete the following information):
latest versions
Additional context
Pinging @DigiH / issue #20
The switchbot is C6:C7:52:66:3C:BF
In essense the monitor just says this:
and when I press the bluetooth button on the meter:
On MQTT:
The text was updated successfully, but these errors were encountered: