Is any android API support for the following status of the nest smoke and carbon monoxide detect:
(1) When the device is on
(2) when the device is off (the batteries are removed)
Yes, if you follow the instructions provided by Nest Labs in their github account, you should be able to receive information from any nest device associated with your home.nest.com account. Create a nest developer account in console.developers.nest.com and add all devices you would like permissions for. then follow steps to receive a nest access token. with the token you can authenticate your account and initialize listeners. the smokeCo alarm listener should give you all the current info regarding the smoke alarm, last test, status etc.
Good luck.
Related
I have signed up for the stripe account and wanted to use this as a developer for my projects but every time a try to use, its shows the error StripeInvalidRequestError: You can only create new accounts if you've signed up for Connect
and my nodemon app crashes!!![enter image description here][1]
The error suggests you are using the connect portion of the Stripe APIs. If this was intended then Stripe has some steps to take before you can begin using it, which involves adding business details to your account.
I'm not completely familiar with the connect section of the API but Stripe offers a 'test' account mode which you may be able to utilize if you are early in the development phase and are not ready to fill out details just yet.
I have a scenario in that I will create a payout flow (based on Stripe's APIs) for 2 participants. One is the platform owner, the other is the customers who use the platform service. The platform owner creates a service that allows his customers to register to his platform service, and to provide services to customers' end users (customer's customers). The payout flow then will transfer money from the platform owner's bank account to the customers (a list of customers who registers to platform owner's service) manually when the platform owner confirms to pay by pressing a payout button.
I've done some research, but I am still not sure about the correct steps for processing this payout flow. The doc I found so far is [1], which looks like the one that fits my scenario. So my first question - Is the doc[1] the right direction to work on?
If that's correct, a few more questions. In the step 2.5's return_url[2] section, the doc mentions to listen to the account.updated event. I create a webhook e.g. https://example.com/return and listening to that event. And the webhook can receive the account.updated event without a problem. However, in the section 2.4[3], after creating an account link, Stripe returns an url like https://connect.stripe.com/setup/c/<random string>, which asks user to fill in info including
BUSINESS DETAILS
MANAGEMENT AND OWNERSHIP
After clicking the submit button, if the return_url is configured to reuse the webhook i.e. https://example.com/return. The service will return following error
{"code":405,"message":"method GET is not allowed, but [POST] are"}
Otherwise redirecting result will return
{"code":404,... }
I understand it's because the webhook /return I setup listening to POST operation. If return_url should be handled in GET, what parameters will passed to that return_url. I search online, but I do not see any explanation. Any docs or code that may provide some related info? I appreciate any suggestions. Thanks.
[1]. https://stripe.com/docs/connect/add-and-pay-out-guide
[2]. https://stripe.com/docs/connect/add-and-pay-out-guide?integration=with-code#return_url
[3]. https://stripe.com/docs/connect/add-and-pay-out-guide?integration=with-code#with-code-redirect-to-account-link
I am currently working on an application built in VS using a Xamarin Unified IOS project. one requirement of the application is the utilisation of push notifications. The issue is that our test device/application registers in the first instance without any issues, we can see the registration events in azure portals, and the azure service bus. I have also confirmed the initial registration using the 'Service Bus Explorer' application and the server explorer feature in VS.
The issue arises when sending the test push notification. According to all the logs I have access too the message is successfully pushed to apples APNS server and I can't see any failures being returned as part of the PNS request. However once this completed the device registration is removed and the notification never arrives on the test device.
My understanding is that the azure application hub handles PNS rejections itself in order to tidy up device registrations. This in and of itself is not a terrible idea, but due to a lack of logging, it's very hard to determine the root cause. I have done a ridiculous amount of googling for this one, and a lot of people suggest an issue with the apple certificates that are used. I have deleted, recreated, resigned, verified, both APNS certs and Provisioning profiles until I ran out of combinations. None of that has resolved the issue.
To make the issue more confusing, if I use a service such as 'http://pushtry.com' or 'http://pushwatch.com' and upload the certificate and device token, it will allow me to successfully push a notification to the device.
Am I missing something glaringly obvious? or is the notification hub absurdly difficult to setup and debug for APNS?
Any help you can provide will be appreciated, I would publish some code, but as I know that the device registers the correct device token, I don't see it necessary at this point, but please feel free to tell me otherwise. Many thanks.
What's also important to note, if you are using Azure Notification Hubs APNS, is that it will unregister devices if the application mode is not set to in production. Once you have deployed to the app store, you need to switch the "application mode" in your Azure Notification Hub from sandbox to production. Otherwise your device registrations will be unregistered.
I'm using the same token/key for both sandbox and production with no issues.
After many man hours and through luck rather than any kind of logical process, we determined that 'Azure Notification Hubs' have an in built validator for the apple device token that's passed up to the APNS. So even though there are multiple examples and answers out there that suggest submitting a device token without spaces or symbols to the notification hub, this is in fact the wrong approach. The device token should always be submitted to the 'Azure Notification Hub' in an 'as is' state, without any validating from within the Xamarin.IOS application. Although this seems like such a simple thing to overlook, there is a lot of contradictory evidence out there on google, and Azure's documentation says very little about the format of submitted device tokens. Anyway hopefully this will help someone else someday.
-- Edit --
Device Token format from Apple: < XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX >
Format that many online resources suggest it is passed to the notification hub as: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
without spaces or the '<' and '>'
However it should be passed through to the notification hub as it is received from Apple.
I been working on a app where the common user can subscribe to different plans, which give different perks.
I been trying to do this by using Stripe's payment component from xamarin component store
But for me, it seems like this component only give you the option to request a payment, but not subscript to a plan.
this leave me think, the only way i can make this happen, is to make the whole "payment and subscriptions to the plan" code on native IOS and Android, which i after bind up against my PCL
So to conclude what i'm looking for is a more simple way to create this functionality,
Thanks for your time,
So the Xamarin extension should really only be used to collect the credit card details and "tokenize" the card. The actual handling of the charge is done by your backend server (as described in the documentation for the extension under "Sending the token to your server"). Once you pass the otken to your backend, you can actually do anything you like with it-- including attach it to a Customer Record by setting the source-attribute when calling the Create a Customer API Endpoint. Once you've created the Customer record, you can then create a Subscription using your Plans.
We currently use the API for embedded signing in our web application. When reviewing doc reference guide for offline signing, I'd say it's less than crystal clear how that really works. If I'm offline when I obviously can't call the API, so how does one in fact "sign" with DS?
I can appreciate how our client app (again, which currently does embedded signing) can prepare an envelope 'request' offline, and then send that request once we have connectivity. However the REST API guide says the user in fact "signs" the doc while offline -- how does the user ever get to the Docusign interface to do signing?
from the docs
To use Offline Signing, the customer using a client application to
create an envelope on an Internet-capable device, such as a smart
phone or tablet, that is not connected to the Internet and has a
recipient fill out and sign (or initial) the envelope documents. When
the device later connects to the Internet, the client application
uploads the envelope information to DocuSign where it is processed.
Does our offline app (running, say, in/as a Chrome app) somehow connect to local client Docusign software onboard the laptop or mobile device while offline? Any pointers to more complete documentation?
From the docs:
"IMPORTANT: Access to the offline signing capability is limited by
integrator key information. If your integrator key does not have the
correct authorization, you cannot use offline signing. Access to the
offline signing capability will be evaluated on a case-by-case basis."
The reason is because your software would be responsible for providing the legal evidence that the transaction actually happened with the proper security checks. This requires a tighter business arrangement and agreement between your company and DocuSign.
Please get in touch with your business development manager and they can set up a time to talk.
-mb