In the ‘Planner’ the Imp device name could be set using imp.configure(“name”, …);
The device name set by this call would show up in the ‘Planner’
Under the new scheme, via the ‘IDE’ the name of the Imp is set using the ‘Device Settings’ dialogue, and is not changed by the call to imp.configure(…)
Is this just currently unimplemented? Or has the method for naming Imps been changed to not allow runtime configuration now? Maybe this ends up being a moot point as end-users will never see the name of their device so far as the Imp ‘IDE’ is concerned when the tantalisingly greyed out ‘Deploy’ button reveals its final purpose?
There may in the future be an API-driven way to set a device’s name, but not in the same way.
One of the big shifts here is the new distinction between a Model name and a Device name. The Device name shouldn’t be set by the imp firmware because device names should be distinct from each other (“Red robot” vs “Guest robot” for example) and the firmware is the same across all devices of a model. The imp.configure() name used in the old Planner was more akin to a Model name than a Device name.
The current thinking is that optional device naming will be a part of the registration process, and that the ‘default name’ of a device of a model is set in the “Model settings…” page, in the field labeled, “Default name of a new device of this model”. This number would increment for uniqueness as needed. For example, if you have “Piggy Bank” in that field, a user’s first device of that Model would be named “Piggy Bank”, and the second would be “Piggy Bank 2”, etc.
Manufacturers third-party apps or websites may be able to change the device name as is appropriate to the circumstance (for example if they want to expose renaming to the user in a way that makes more sense for their product). While some of those contexts may be device-driven, this seems generally unlikely, unless the name is being updated periodically by the imp to convey some quality of state, like “Piggy Bank (low battery!)”, and these sort of stateful messages should be handled in other ways.
I hope this all makes sense. I’m talking about a number of concepts we haven’t really talked about much yet. I’d appreciate your feedback and use cases.
Many thanks for your response. In answer to your question, yes, your answer does make sense to me, and so does the overall strategy.
What would be useful right now would be an API mechanism to get the unique ID assigned to each Imp (the default name used by the IDE). I know it’s possible to get the mac address via the API, but it would make life easier/less confusing to use a single ID throughout.
Regardless of what ends up happening with the actual name in the end, it would also be nice to be able to get the name via the API too.
To be able to get the unique ID or Device name from the API would be kinda essential to my intended production use - I think!
I have to say btw, this new beta api is awesome! I’m sure there’s either something planned on this front or maybe I’ve just missed something but…
…Being able to register Imps and their device name with a particular user, so I could then make requests from my web app to their agent url’s is pretty much everything to me as from what I can make out, it’s the difference between having hundreds of Imp’s pointlessly polling my server every minute - and the better solution of my server sending data to them when it actually needs to. If you get my drift?
…or maybe it’s possible to obtain the agent url by analysing the request url from my web application?
For example maybe I could “register” my imp with a user by making a http.get(reqURL) to my web application and saving the request url against that user.
Anyone tried this yet? Maybe the requests from agents get proxied and appear all from the same url so this won’t work?
@deldrid1 - yup, that’s obviously cool if you want to set the imps external URL in a static way, i.e because you’ve looked it up in the planner/IDE and then added it to the code, but what if you have hundreds of imps ready for production.
It would be impossible to do this manually each time for each one, so like you say, hopefully the api will soon provide an agent/device url for us to use programmatically
Nice one for making the feature request though - I suspect it’s on the guys list anyway as they seem to be all over this! Fingers crossed
…and by the way, I’ve just checked the referer and other header info and apart from an IP address (presumably the imp cloud) there doesn’t appear to be any info included in the request from the agent that can be used to distinguish the agent ID.
Apologies if this is incorrect or if it was obvious to any of you, but I thought I’d just check anyway - although please reply if you think I’m wrong, because It would be really helpful.
Although doesn’t this raise a question, in that there must be some sort of uniqueness in the agents request to a third party URL otherwise someone else’s application could surely in theory exceed a rate limit of say one of Google’s api’s and then everybody else using the imp cloud would be affected too no?
Maybe the obvious answer is to not make requests to third party servers directly and route them via your own, but that seems a shame for some scenarios.
I posted this in another thread so apologies, but…
…I just discovered that the BlinkUp integration process generates something called a setup token which has the device ID and the Imp card ID in it. If I understand this correctly, you can then pass this token to your server application and use it to make requests to the external URL of the imps agent, as the URL is constructed using the device ID.
I think that’s right anyway - please set me straight though somebody, if that’s not the case!
and you can punch the returned value into the following class’ getDeviceName() method:
`class BuildAPIAccess {
// 'Constants'
static BASE_URL = "https://build.electricimp.com/v4/";
static VERSION = [1,0,1];
// Private properties
_header = null;
_modelList = null;
// Constructor requires a Build API key
constructor(apiKey = null) {
if (apiKey == null) {
// No API key? Bail
server.error("BuildAPI class will not instantiate without an API key");
return null;
} else {
// Build the header for all future Build API requests
_header = { "Authorization" : "Basic " + http.base64encode(apiKey) };
}
}
// *** PUBLIC FUNCTIONS ***
function getDeviceName(deviceID = null) {
if (deviceID == null || deviceID == "") return null;
if (typeof deviceID != "string") deviceID = deviceID.tostring();
local device = _getDeviceInfo(deviceID);
if (device != null) return device.name;
return null;
}
// **** PRIVATE FUNCTIONS - DO NOT CALL ****
function _getDeviceInfo(devID) {
local data = _sendGetRequest("devices/" + devID);
if (data != null) return data.device;
return null;
}
function _sendGetRequest(url) {
// Issues a GET request based on the passed URL using stock header
local result = http.get(BASE_URL + url, _header).sendsync();
if (result.statuscode == 200) {
return http.jsondecode(result.body);
} else {
if (result.statuscode == 401) {
server.error("Build API Error: " + result.statuscode + " - Unrecognised API key");
} else {
// TODO Handlers for common errors
server.error("Build API Error: " + result.statuscode + " - " + result.body);
}
return null;
}
}
}`
You’ll need to instantiate the BuildAPIAccess class with a Build API key for your account - you can get this from the IDE.
