The whole metadata thing seems very buggy to me. I was looking at it recently, trying to get data out via the API. Although it works, it’s not exactly foolproof.
I created a metadata entry called “meta_test”, which was allocated ID 9 (visible in the right hand column of the Template view.
Calling the get metadata API…
I eventually realised that metadata field 9 must be used internally for the device ID. This ID is visible in the URL when that device is selected…
I then created another metadata field, which was given the field ID of 10, which I called “meta_test_10”
Doing the metadata get call for that field returned:
This seems like a rather clunky way of saying that the metadata switch filed is set to On (value 1)
Setting this to Off returns a value of “0” in the API.
So, it seems as though the “Add Metadata” routine in the web console needs to be modified to avoid allocating filed ID’s that are already used internally.
@Dmitriy - one for you?
I’ve since done some testing on trying to extract the same data using the:
Blynk.sendInternal("meta", "get", "meta_test_10")
command from code and this isn’t working.
I’ve tested some other fields and the only one that seems to work is:
Blynk.sendInternal("meta", "get", "Device Name")
It’s also very confusing, because in the Template view this appears as “Device Name” (mixed case) but in the pop-up box appears as “DEVICE NAME” (all caps).
In the Device view, all the metadata fields names appear as upper case (all caps)…
If you attempt to use the capitalised version that appears in the Device view, like this:
Blynk.sendInternal("meta", "get", "DEVICE NAME") the it doesn’t return a result.
So, at the moment, it seems that the HTTPS API is the only way of retrieving the data from a custom metadata field, and then only if it’s not been allocated an ID that clashes with an internal one.