-
-
Notifications
You must be signed in to change notification settings - Fork 137
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
Advertised device payload not copied? #55
Comments
I think the simple answer would be to save resources. 31 bytes + std::string overhead per device found. It’s also what was in the original library so... |
But manufacturer data is copied, that is inconsistent, isn't it? Can I make a PR to copy it? Or will the payload of all scanned devices be accessible through the scan object? I doubt it... |
Maybe this time would be better to left user option to copy payload and other advertising data, this wont use memory in case user is not interested some found devices, especially useful in dense environment. I think low level stack is keeping only few most recent seen devices, at least in bluedroid. |
@chegewara I see your point. @chegewara @h2zero this could also be set dynamically, like the auto pre discovery. I would opt for all or nothing, so store all data in the advertised device including the payload, or nothing at all. Also I would opt for changing payload into a |
I dont agree. Payload is type of uint8* and cant be treated as string. I know you may have not printable chars in string, even 0x0 in middle of it, and maybe even it is C++ acceptable, but this is not good idea. If you want to go that way you can replace all std:string with arduino String type. |
std::string is (mis-) used throughout this library and the original library |
Yes, i know. Maybe its time to fix it and use variable types that should be used? Just saying, if we know that something was wrong that does not mean it should be replicated. Lets try to make this library better than the other one. |
I agree with @chegewara on this. We already parse the data from the payload and store it anyway, no need for another copy. If the user wants to save it they can copy it to whatever container they want with the pointer. Not sure why you’re using this anyway? Is there some data in the payload that isn’t available from the advertisedDevice object? |
I fear the PR flood gates just got smashed with this comment lol. |
Lol, time for a revolution and a contra revolution. Finally! :D In #48 the pre revolution started already, but then it was a one day war only... ;)
Nope, the fields are parsed here and the payload is set (pointer copied) just below.
Short answer: yes, e.g.:
I do not know what I want with it exactly. I am looking for a way to do a scan and filter out the devices that I support. One way is with getName(), but 2 of my 3 devices don't have a name. I could read the characteristic, but then I have to connect. I would like to determine one way or another what from the advertised data which devices I have support for. It must be generic enough to recognize all same devices, but specific enough to differentiate between e.g. two different devices of the same manufacturer. Any suggestions? |
You simply have to parse a MiBeacon and make the decision based on the PID (the value after the frame_ctrl). In your example Look here for further info: https://github.com/Magalex2x14/LYWSD03MMC-info |
@Staars Thank you Christian for directing me to that site again. I now almost know the structure of the service data for the MJ-HT-V1:
Just 2 bytes to discover: do you know what the 2 bytes at position 12 and 13 mean? Also still looking what the last bytes mean if byte 11 equals 0xdc. Is this structure generic for every BLE peripheral or for Xiaomi only? Do you happen to know if the LYWSD03 can be read without connection? |
@Jeroen88 (a bit late ;)
You mean the last two bytes before the data? It is this enum:
I am not sure, but my best guess is: RSSI
No, this is Xiaomi only, but BTW I am not aware of any other sensor families (temp/hum-stuff for homes) out there.
My personal opinion is, that I find it more convenient to connect to the LYWSD03 from time to time. I prefer to avoid the relatively complicated procedure to obtain the "bind_key". Another advantage of the connection-method is, that you can read the real battery voltage instead of the questionable battery-percentage-level. |
Thx @Staars for the extensive answers!
Going to check that link later!
Are you sure that it is not the other way around,
Yes I thin you are right, that is the easiest option. |
Pretty sure. |
😆 thnx!
I took a better look at the link, since it seems to be the "official" site I understand the pretty now... |
Closing this as recent commits have addressed some of this issue. Version 2.0.0 will address the rest. |
Is there any good reason why payload is not copied into the advertised device member variable std::string m_payload? Now only the pointer returned from the stack is saved, see here.
The text was updated successfully, but these errors were encountered: