In the Android URL parameters section, the Point of Sale API - Mobile Web Technical Reference explicitly specifies the possible auto return timeout to be within the range of 3200 to 10000 milliseconds. The iOS additional payment options section only defines the auto return timeout to be a "short timeout". Is the iOS timeout within the same time range as Android or is it something else entirely?
The auto_return timeout for iOS is 2 seconds. I also want to note that it's subject to change, but unlikely.
Related
I'm trying to trigger a notification which has no expiry but must be closed by pressing the top-right X close button. Is this possible?
I've been able to trigger a timed notification which also closes when anywhere else is clicked. With this answer.
[reflection.assembly]::loadwithpartialname("System.Windows.Forms")
[reflection.assembly]::loadwithpartialname("System.Drawing")
$notify = new-object system.windows.forms.notifyicon
$notify.icon = [System.Drawing.SystemIcons]::Information
$notify.visible = $true
$notify.showballoontip(10,"New Chat!","You have received New Chat!",[system.windows.forms.tooltipicon]::None)
Per Microsofts NotifyIcon.ShowBalloonTip Method documentation, the actual timeout property is set by the current system settings.
Minimum and maximum timeout values are enforced by the operating system and are typically 10 and 30 seconds, respectively, however this can vary depending on the operating system. Timeout values that are too large or too small are adjusted to the appropriate minimum or maximum value. In addition, if the user does not appear to be using the computer (no keyboard or mouse events are occurring) then the system does not count this time towards the timeout.
According to a couple of more google searches, you can set the time for your profile through the Registry ( Regedit - HKEY_CURRENT_USER\Control Panel\Accessibility: MessageDuration - didn't work for me).
Through group policy, or using theSystemParametersInfo API which is out of my league to explain any further. Only reference I can find was configuring the Accessibility/System Parameter: SPI_SETMESSAGEDURATION.
Its C++ though and only other article I could find was this one:SystemParametersInfoA function.
Seems possible but, it will definitely be a hassle to get it working.
In consul's documentation, it states:
This endpoint returns the most recent events known by the agent.
What does it mean exactly by most recent? Most 100 recent events? 1000? Events fired in the last 7 days?
Is there a way for me to configure this?
My concern is this event list could grow infinitely large if older events are not removed within a reasonable amount of time (which can vary across different applications).
So after some digging into the source code of consul. I found out it is max 256
https://github.com/hashicorp/consul/blob/94835a2715892f48ffa9f81a9a32808d544b1ca5/agent/agent.go#L221
eventBuf: make([]*UserEvent, 256),
On below you can see the rotation
https://github.com/hashicorp/consul/blob/94835a2715892f48ffa9f81a9a32808d544b1ca5/agent/user_event.go#L229
a.eventBuf[idx] = msg
a.eventIndex = (idx + 1) % len(a.eventBuf)
Below code shows that the data is pulled from the same buffer only
https://github.com/hashicorp/consul/blob/94835a2715892f48ffa9f81a9a32808d544b1ca5/agent/user_event.go#L235
func (a *Agent) UserEvents() []*UserEvent {
So you can safely assume, this will be max 256
I have a table of eBay itemid, and for each id I want to apply a reviseitem call, but from the second call I get the following error:
You have exceeded your maximum call limit of 3000 for 5 seconds. Try back after 5 seconds.
NB: I have just 4 calls.
How can I fix this problem?
ebay count the calls per second per unique IP's. So please make sure your all calls from your application must be less than 3000 per 5 seconds. hope this would help.
I have just finished an eBay project and this error can be misleading. eBay allow a certain amount of calla a day and if you exceed that amount in one 24 hour period you can get this error. You can get this amount increased by completing an Application Check form http://go.developer.ebay.com/developers/ebay/forums-support/certification
The eBay Trading API, to which your ReviseItem call belongs, allows up to 5000 calls per 24 hour period for all applications, and up to 1.5M calls / 24hrs for "Compatible Applications", i.e. applications that have undergone a vetting process called "Compatible Application Check". More details here: https://go.developer.ebay.com/developers/ebay/ebay-api-call-limits
However, that's just the generic, "Aggregate" call limit. There are different limits for specific calls, some of which are more liberal (AddItem: 100.000 / day) and others of which are more strict (SetApplication: 50 / day) than that. Additionally, there are hourly and periodic limits.
You can find out any application's applicable limits by executing the GetApiAccessRules call:
<GetApiAccessRulesResponse xmlns="urn:ebay:apis:eBLBaseComponents">
<Timestamp>2014-12-02T13:25:43.235Z</Timestamp>
<Ack>Success</Ack>
<Version>889</Version>
<Build>E889_CORE_API6_17053919_R1</Build>
<ApiAccessRule>
<CallName>ApplicationAggregate</CallName>
<CountsTowardAggregate>true</CountsTowardAggregate>
<DailyHardLimit>5000</DailyHardLimit>
<DailySoftLimit>5000</DailySoftLimit>
<DailyUsage>10</DailyUsage>
<HourlyHardLimit>6000</HourlyHardLimit>
<HourlySoftLimit>6000</HourlySoftLimit>
<HourlyUsage>0</HourlyUsage>
<Period>-1</Period>
<PeriodicHardLimit>10000</PeriodicHardLimit>
<PeriodicSoftLimit>10000</PeriodicSoftLimit>
<PeriodicUsage>0</PeriodicUsage>
<PeriodicStartDate>2006-02-14T07:00:00.000Z</PeriodicStartDate>
<ModTime>2014-01-20T11:20:44.000Z</ModTime>
<RuleCurrentStatus>NotSet</RuleCurrentStatus>
<RuleStatus>RuleOn</RuleStatus>
</ApiAccessRule>
<ApiAccessRule>
<CallName>AddItem</CallName>
<CountsTowardAggregate>false</CountsTowardAggregate>
<DailyHardLimit>100000</DailyHardLimit>
<DailySoftLimit>100000</DailySoftLimit>
<DailyUsage>0</DailyUsage>
<HourlyHardLimit>100000</HourlyHardLimit>
<HourlySoftLimit>100000</HourlySoftLimit>
<HourlyUsage>0</HourlyUsage>
<Period>-1</Period>
<PeriodicHardLimit>0</PeriodicHardLimit>
<PeriodicSoftLimit>0</PeriodicSoftLimit>
<PeriodicUsage>0</PeriodicUsage>
<ModTime>2014-01-20T11:20:44.000Z</ModTime>
<RuleCurrentStatus>NotSet</RuleCurrentStatus>
<RuleStatus>RuleOn</RuleStatus>
</ApiAccessRule>
You can try that out four your own application by pasting an AuthToken for your application into the form at https://ebay-sdk.intradesys.com/s/9a1158154dfa42caddbd0694a4e9bdc8 and then press "Execute call".
HTH.
three fan-related variables are defined in https://developer.nest.com/documentation/api#has_fan
has_fan (r/o, boolean)
fan_timer_active (r/w, boolean)
fan_timer_timeout (r/o, iso8601)
i suspect that fan_timer_timeout should be read-write; however, when i PUT
{"fan_timer_active": true, "fan_timer_timeout": "2014-09-30T01:07:29Z"}
i get back
No write permission(s) for field(s): fan_timer_timeout
none of the examples (on the SDK site) actually change the fan, so no guidance there.
the "non-public API" from "the early days" would have you do this:
fan_timer_duration = seconds
fan_timer_timeout = time-since-epoch-in-seconds + seconds
fan_timer_timeout isn't documented on the SDK site; however, doing that yields
No write permission(s) for field(s): fan_timer_duration,fan_timer_timeout
could someone clue me in as to what i need to send to get the fan to spin for the next 15 minutes?
many thanks!
The user configures the fan time duration in the Nest app or on the device, the API only provides a way to trigger a fan event.
It seems that fan time duration is a global setting, and would affect turning on the fan manually at the thermostat, hence why it is read only in the API. (Avoids user confusion)
I'm noticing some weird snmp communication behavior when using MS SNMP Mgmt Api in terms of timeout and retries. I was wondering if mgmt api is supported on Win Server 2008 R1 x64. My program is a C++ 64bit snmp extension agent that uses the mgmt api to communicate with other agents as well.
This is my pseudo code:
SnmpMgrOpen(ip address, 150ms timeout, 3 retries)
start = getTickCount()
result = SnmpMgrRequest(get request with 3 or 4 OIDs)
finish = getTickCount()
if (result == some error)
{
log Error including total time (i.e finish - start ticks)
}
SnmpMgrClose()
When the snmpMgrRequest call times out, the total time equals anywhere from 1014ms to 5000ms. If, I set retries to 0, the total time is still 1014ms to 5000ms.
I would expect, with retries to 0 that the SnmpMgrRequest would timeout within 150ms. The documentation seems to imply this. Am I missing something is there a minimum timeout period of at least a second? What could be causing this behavior?
Any help would be greatly appreciated. I'm at a lost here.
ballerstyle_98#hotmail.com
From my experience with SNMP on Windows platforms the minimum timeout value is 1 second. So even if you set it to any value lower than that, it will default to 1 second.
Also the timeout value used is doubled for every retry. So with a 150ms 3 retry configuration in the worst case you will have a failed response to a request in 1+2+2+2 =7 seconds.
I hope this helps.