Hi,   Yes MX / MS One Call gets me this - {"mac":"00:18:0a:bb:bb:bb","serial":"Q2FN-Q2FN-Q2FN","networkId":"9999","model":"MX400","claimedAt":"152659", "publicIp":"17.0.0.9","name":"0000-005"}     The Other returns this {"name":"0000-005","serial":"Q2FN-Q2FN-Q2FN","mac":"00:18:0a:bb:bb:bb","publicIp":"1 7.0.0.9","networkId":"9999","status":"online","usingCellularFailover":false,"wan1Ip":"1.9.2.1","wan2Ip":null},   I parse both files to get what I need, but I still need the *Real* Address used to manage the device.   Don ... View more

Hi,   Not in in our case , sorry, I might have miss labeled what I’m getting,  but what ever it is it’s not the SNMP Management address.   thanks,        Don   ... View more

If your drawn the socks”you already have them” you don’t need UPS 😉 ... View more

The vendor supplied a patch for CA Spectrum - to support casting the type to something usable and correct. We had to patch the servers to support a trap with bad /miss-typed data. ( I can only cringe thinking about when the trap format gets corrected and Breaks what we have working. ) ... View more

To add insult to injury, we discovered that the MAC address sent in the trap is declared as type Octet String, but it’s actually sent as a : (Colen) delimited Text string, not Dot (.) delimited as a Octet string would be !  We are working to “cast” it as a type we can use in our comparison when searching for device by MAC ( insert annoyed Smily here...)   Note to Engineering: Traps need some work 😉 Thanks,   Don ... View more

Hi,   One significant  issue we have with the traps is the content, ( or lack there of) every trap needs to have a target ! Most have MAC which is not helpful when trying to associate  the Alarm to a CI in the CMDB against which you are trying to assert that Alarm, the trap must supply Hostname / IP Address to be useful.   thanks,     Don   ... View more

This call was better, but I still need to make a second call to get device type Z3 Etc... We are also trying to determine which devices are Really in Production Vs. have been staged then shut off until True deployment. The status is useful, but I am thinking that is as of N minutes... Eg. it’s up now but for how long.   Is is there any way to know a device is Production other than online and Passing traffic ?   thanks, Don ... View more

Um....   So I am using these two calls:   api/v0/organizations/666/inventory   api/v0/organizations/666/deviceStatuses   And was imagining I would get the same number of Records back for each ? All Devices are part of the inventory for the Org, no ? There must be some filtering applied to one call that is not applied to the other! Could you tell us what it is please ?   Thanks,        Don ... View more

@DonL wrote: Looks good, have to check it out! i was working on a network in org loop, but one call would be preferred !   Thanks for the update. So close to having everything I wanted - missing Device type - MX / Z ... I can wait until Christmas or My Birthday ... ... View more

Looks good, have to check it out! i was working on a network in org loop, but one call would be preferred !   Thanks for the update. ... View more

Continuing to Shop for a call that gets what we’re looking for: this look promising - curl -L -H 'X-Cisco-Meraki-API-Key: <key>' -X GET -H 'Content-Type: application/json' 'https://api.meraki.com/api/v0/networks/[networkId]/devices' ... View more

Hello,   As stated in one of my other posts we are trying to get data out of the Meraki Dashboard to feed into other systems  eg: CMDB and initialy thought the  inventory call - /api/v0/organizations/648916/inventory -         "mac": "00:18:0a:0b:80c:0d",         "serial": "QQQQ-UUUU-1111",         "networkId": "A_123456789",         "model": "MX100",         "claimedAt": "1496173973.76468",         "publicIp": "10.12.18.5"   Would provide the same of more than what was on the Organization inventory Page ( but per Network ) but: - no name - IP is NAT IP not Device IP - Network ID not name ( not a big deal ) - No Country/Region   It would make sense that if there is a concensus that "We need to see X in the GUI" we will want the same data available via an API call ?   Thanks,        Don PS: The trap content needs some massaging as well 🙂     ... View more

VAfter investigating this Further - the IP Address returned by the API query is NOT the device IP, but  the NAT overload address ? so the API call is all but Useless ~  ( for our needs ) ... View more

Hi,   We have a workaround in place now !' But having a "Standard" trap there the Header contains the IP of the source would be the norm. Or having a varbind that containst the source IP or Hostname would also be "Normal" for Management consoles that Proxy traps on behalf of the Device.   Don   ... View more

Hello,   Once you get the traps to the other platform you will likely run into the issue we are having - the trap contain No IP or Hostname target information only the MAC address , Network Name / customer/Site / State / issue data. MAC is not the normal lookup value so were trying to build a workaround.   I understand the devices are DHCP so IP *might* not be a valid target if its constantly changing. - but other customers I have talked to are using DHCP Reservation to have consistent IP Addresses used. We need something other than MAC in the traps to identify the target !   Don ... View more