I had to submit a case to Meraki support to get access to the Wireless Health APIs.  Until then, I received a 404 on any requests to that set of APIs.   Also, make sure you use valid values for t0 and t1.  I don't think you can submit 0 and 3600 (as you did in your example) to get the last hour.  Instead, you need to specify unix epoch values (see https://www.epochconverter.com/ if you are unfamiliar).   @PhilipDAth - I played around with connectionStats in hope that it would provide client counts or connection status for specific clients.  As far as I can tell, that's not what the API does.  Instead, the API provides the same type of information shown in the dashboard UI for Wireless Health.  The connectionStats object only seems to show information when a client attempted to establish a connection during the specified time window.   For example, one of my networks has 8 active clients.  When I query connectionStats for the last hour, I receive an empty array as a reply.  If I query for the last 3 hours, I only see a single entry for a device that happened to disassociate and re-associate at that time.   Unless I'm missing something, I don't see how the Wireless Health APIs can provide current client status information. ... View more

  Meraki describes the hash algorithm in pseudocode:     hash(mac bytes, org secret) = SHA1(mac bytes ++ org secret).takeRight(4) where: ++ indicates concatenation; takeRight(4) returns the least significant 4 bytes of the SHA1; and org secret is a per-customer salt. Example: client MAC is 11:22:33:44:55:66 org secret is t3lrdd least significant 4 bytes of SHA1(112233445566t3Irdd) = 0x0e456406   I'm not sure why you would want to implement this yourself, but here's an example in Node.js   var crypto = require('crypto'); merakiHash('11:22:33:44:55:66', 't3Irdd'); function merakiHash(mac, secret) { var sha1 = crypto.createHash('sha1'); var macBytes = mac.replace(/:/g, ''); sha1.update(Buffer.from(macBytes, 'hex')); sha1.update(secret); var hashResult = sha1.digest('hex').slice(-8); console.log('least significant 4 bytes of SHA1(' + macBytes + secret + ') = 0x' + hashResult); return hashResult; }   For any Meraki people following along, would you mind updating the docs?  The comment in your pseudocode uses a different org secret than the example, which made this a little more painful than it should have been.  "t3lrdd" is not the same as "t3Irdd".     ... View more

You're talking about 3 minutes to go through the entire organization.  I don't know your exact use case, but that doesn't sound 'very time consuming' to me.   The Scanning API includes the ssid parameter.  If you only want to track the connected clients, simply filter out the records with a empty ssid in the data you receive from the Scanning API.   If you want to review data from yesterday, last week, or last month, you can use the Organization Summary Report. ... View more

Are you certain that you're getting a 200 response?  Some Meraki API calls will respond with a redirect.  Not all libraries default to following redirects and some will even follow the redirect as a GET rather than a PUT or POST.   Do you want to share a bit of your python code (make sure to remove API key and any device serial numbers or network ids)? ... View more

To use  /devices/[serial]/clients, you first need the serial number of the device you want to check.  You can get the serial number from another API (network or inventory) or from the Meraki Dashboard UI.   When you make the clients API call, you must include a parameter 'timespan'.  This parameter tells the API how far back you want to look when listing clients (in seconds).  For your use case, you might call the API with a timespan of 1 hour (3600 seconds) and again with a timespan of 1 day (86400 seconds).  For any devices that appear in the 1-day query but not in the 1 hour query, you would revoke the splash authorization through the API call I already mentioned.   With the Scanning API, you would listen for data from Meraki, keep a list of devices and when you last saw them, and revoke authorization when a device disappears for a predefined period of time.   ... View more

I'm aware of three ways to force a client to visit the captive portal page after they sign-in or click-through successfully:  - Time limit (as you know)  - Manually click 'Revoke' on the client detail page in Meraki dashboard  - Call the  splashAuthorizationStatus API   I don't know of an automated solution to revoke the sign-in or click-through based on a client leaving an area of WiFi coverage.   I suppose you could use Meraki's Scanning API to monitor which devices are connected and call the splashAuthorizationStatus API when a device disappears for a set period of time.   You might also be able to use the /devices/[serial]/clients API with different values for timespan to try to figure out which devices were recently connected but are no longer in the area.   What's the reasoning behind forcing a client to re-login on each return visit and treating that differently from someone sitting in the store for a long period of time? ... View more

If you set up a trial account with Twilio, there are some important limitations to keep in mind.  For the full list, see https://support.twilio.com/hc/en-us/articles/223136107-How-does-Twilio-s-Free-Trial-work-   Here's the specific limitation you're likely seeing:   Outbound trial messages can only be placed to a validated phone number. Before attempting to place an outbound call, be sure to   verify the number. Only numbers in the US and Canada can be reached by default; for help enabling messages to a desired country, please see our   Global SMS on Trial Accounts article.     ... View more

There's nothing exposed that you can configure.   You should check the General page in Meraki dashboard where you set the POST URL.  Do you see a green, yellow, or red circle next to it?  You can see the response time of your endpoint (as seen by Meraki).  If your endpoint is slow, Meraki appears to slow the flow of data.   Otherwise, you should file a case with Meraki for them to investigate. ... View more

I believe the MR53 comes with mounting hardware for a drop-ceiling grid.   Take a look at page 4 of the MR53 datasheet.  The largest metal parts in the black foam twist on to the ceiling grid and are locked with set screws. ... View more

Are you perhaps getting the same response shown in https://community.meraki.com/t5/Solutions-APIs/Access-Control-Allow-Origin-error/td-p/9583 ?   Last time I checked, Meraki did not support CORS on API calls.  As a result, your cross-domain requests will fail at the browser level (see the post above for alternative approaches). ... View more

You can create a group policy that bypasses the splash page.   You would then use MAC-based authentication and have your radius server set that group policy for known MAC addresses.  For everyone else, the radius server would grant access without setting the group policy.   Unknown MAC addresses would then see the splash page. ... View more

@Adam is correct.   You also have the option of creating a Group Policy that only changes the splash behavior.   Network Wide > Group Policies > Add a group   Set Splash to 'Bypass' and leave everything else as 'Use SSID Default'.   When you locate a client in the Network-Wide > Clients page, use the 'Apply Policy' option to apply your group policy. ... View more

I don't think you can do this with the Dashboard API.   If you use the Scanning API, you can receive all currently connected wireless devices, including the SSID (if any).   Of course, you can't query the Scanning API.  You have to listen continuously. ... View more

I don't know of a way to get everything you've asked for in a CSV from Meraki dashboard.   You can go to the 'View All Networks' page, expand the box that shows the list of networks on top of the map, add all available columns and click the CSV button.  That will give you network name, type, client count, tags, template, and several other fields.   In the same place, click on the 'Devices' tab (inside the floating box), add fields, and click the CSV button.  That will give you MAC address, Public IP, Uplink IP, serial number, network name, and more.   To get more details, you may have to use the Dashboard API.  You can certainly get the lat/long of all devices from the API. ... View more