-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switchbot Meter Plus sometimes detected as Tile tracker #505
Comments
Yes, very strange and unwanted recognition of your Meter Plus as a Tile tracker. Not having a Meter Plus nor a Tile tracker, these two decoder have been solely based on user data and the BLE-API from the semi-offical SwitchBot repo. For the Tile trackers the uuids for model recognition have been fine so far, with being unique to Tile, but obviously it seems that SwitchBot is now using the same uuid for a Meter Plus alternative broadcast, while at the same time the actual servicedata is a lot longer too, 20, compared to the expected 12, which is also being broadcast when your Meter Plus is being recognised correctly. It seems that this longer alternative servicedata does not actually contain the temperature and humidity information which is gathered and decoded from the 12 long servicedata, unless it has been encoded in a very different way with this broadcasts. Why your Meter Plus seems to broadcast two different kinds of servicedata we really don't know, even the first octet, which normally indicates the device type of a SwitchBot device is with 02 and undocumented type. So with no apparent decodable data in these alternative broadcasts, this is more a situation of how to not recognise this as a Tile tracker, and not in trying to get it to be recognised as a Meter Plus with the possibility of getting useful information from it. |
Agreed, this issue is mostly to avoid the 'false positive' case and not recognize it as a Tile |
@brandonmpace Would you mind giving this test branch a go? https://github.com/DigiH/decoder/tree/tile-test Hopefully not wrongly recognising the new "feed" Meter Plus broadcasts as a Tile tracker any longer. |
It is working for me. Tile is still recognized and the Meter is not categorized as a Tile. In the changes I see both "no-mfgdata" and "no-mandata" and I'm curious what the difference is. It may also be helpful to add a note to adding-decoders.md if that was merged. Below the debug print you added is the "match = true;" supposed to be outside the if? |
Well spotted, but that part should have not actually been in the commit ;) Could you try again please with the cleaned up version of the test decoder and possibly post a Meter Plus message with the actual servicedata when it's not recognised as a Tile? |
Active scan for the meters works still (not currently sending the 'feed' uuid though)
And the tracker also still works:
Since the odd brodcasts weren't happening I just manually tested the library to confirm the None was returned:
|
"no-mfgdata" model condition implementation and application in the Tile tracker decoder theengs#505
Great, thanks for the confirmation. Merged this after adding the additional new |
"no-mfgdata" model condition implementation and application in the Tile tracker decoder #505
I have a Switchbot Meter Plus that was being picked up as a "Smart Tracker" for a bit.
To Reproduce
I collected output from runs of examples/python/ScanAndDecode.py
In the bad detection state the device sends out data like this: (MAC in output redacted, replaced with DC:FF:FF:FF:FF:FF)
Note the manufacturer data confirms it is my Switchbot Meter Plus.
I don't know why the sent data was different or what the exact trigger was since I had done several things, including:
Expected behavior
The data it sent out when it was properly tagged:
Environment (please complete the following information):
Additional context
This is output for a tracker, for comparison:
I note that there is no manufacturer data for that device.
Maybe that could be used to fine-tune the tracker detection? Right now it appears to be solely based on uuid
The text was updated successfully, but these errors were encountered: