I noticed that there is no mention in the API for selecting sensors attached to a thermostat. Is this limitation going to be addressed?
Related
I'm trying to get body tracking to register on small action figures that are about 12" tall. I've tried using other depth sensors like the Zed2 and D435i and their skeletal SDK's recognize the toys as "humanoid" and attempt to track the skeleton.
Is it possible to change world scale or a filtering option so that the Azure Kinect or Kinect v2 do not ignore the toys?
I reached out to Microsoft and this was their response:
" AK Body Tracking has been tuned to process human’s from 7-8 years and up in age. The action doll is being filtered out as too small. They currently don’t expose the tuning parameters. They will considering exposing the tuning parameters but they have nothing to announce at this time. "
Unfortunately a no go at the moment.
I'm using the Microsoft Face API to track people in front of a webcam by sending a screenshot from the camera to the API every second or so
If a particular person is in front of the camera for multiple API calls, the API should return the same faceId for that person in each response, but it is returning a new faceId for that person instead. This makes it impossible for me to know whether there is a new person in front of the camera, or a different person
This was not the case a couple of weeks ago, it's just something which has started happening recently
The parameters that I'm sending are...
returnFaceId:true,returnFaceLandmarks:false,returnFaceAttributes:age,gender
... the gender and age detection are working fine, it's just the faceId that I'm having problems with
Is there a limit to how many faceIds it'll assign per month or something? I can't find any reference to a limit in the documentation
here is Shuolin from Microsoft Cognitive Service Face Team. Referring to Face Detect API is provided (https://westus.dev.cognitive.microsoft.com/docs/services/563879b61984550e40cbbe8d/operations/563879b61984550f30395236), each Detect API call will return a unique FaceId (even same face is used in different call). For your situation, I suggest that you can use Identify API to recognize person (https://westus.dev.cognitive.microsoft.com/docs/services/563879b61984550e40cbbe8d/operations/563879b61984550f30395239).
Recently started exploring the Firebase data via the Data Studio Firebase connector. I'm doing some custom reports based on the user_engagement event to compare with data we previously reported on in Flurry.
When looking at some DAU figures they are pretty close but on MAU they tend to get inflated. (Saw this behavior first on the Firebase Events Report Template). Digging into it a little more we do have a pattern where users frequently reinstall the app which generates a new app_instance_id. So as I fallback I'm using the resettable_device_id but then there's the situation advertising tracking is disabled on device resulting in a zeroed value. (Or for a brief period in January nulled out values, not sure if this was client or part of the Firebase link)
Currently thinking something roughly following the logic below, falling back to app_instance_id if the advertising identifier was not set. What approaches would be worth looking into to have a reliable user identifier for metrics reporting? (In future will be calling the setUserID to utilize our own identifier but looking to match up historical data)
IF(user_dim.device_info.resettable_device_id is not null,
IF(user_dim.device_info.resettable_device_id = '00000000-0000-0000-0000-000000000000', user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id),
user_dim.app_info.app_instance_id
) as unique_user_identifier,
Thanks in advance.
Simpler way to deal with the cases where a resettable_device_id is not available:
IF(user_dim.device_info.limited_ad_tracking, user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id) as unique_user_identifier
I was reading the documentation at:
http://woocommerce.github.io/woocommerce-rest-api-docs/
I am trying to figure out the limits for the API for the following methods
$woocommerce->get products/tags
$woocommerce->get products/categories
$woocommerce->get products/categories
$woocommerce->post products/tags
$woocommerce->post products/batch
For these methods I want to know how many items I can get or save at once. (Batch save for example I want to save 50 at a time; or for getting products I want to get 50 at a time (per page))
Also I am trying to figure out best practices to use less resources on both consumer of the API and receiver of API. Right now in development I have them both on the same machine and the fan really gets going on my laptop
The majority of work is done in products/batch. I am sending almost 4k items in batches of 50.
I know a service that uses WooCommerce says that their API calls are rate-limited by IP to 86400 calls per day (one per second on average).
That is their service so implies you can go same or higher for WooCommerce
Source: https://github.com/Paymium/api-documentation#rate-limiting
The need: a combined number of total some metric across two mobile apps and a desktop site. The question: can I implement trackers as needed (SDK and JS) that share a property ID?
My guess: no, as the hit types won't match, and either pageview or screenview hit types won't be processed (based on the property configuration).
Further question: though it won't be possible for this implementation, conceivably I could implement the measurement protocol on all apps/sites and set the hit type as whatever (as long as it matched across all apps/sites), correct?
You indeed are supposed to create separate properties for the apps and the website - cf. Best practices for Mobile App Analytics setup.
In order to get your consolidated reporting, you could use the google analytics API to get the raw data, and aggregate the measures by yourself.
To reply to your further question: Yes, technically, it is possible to hack the measurement protocol this way. Just push virtual pageviews, custom dimensions/measures, or events, however you like.
Actually, one solution for you may be to use one property per app/website as recommended, plus in addition use an extra property where you just record custom data the way you want, across the apps and the website.