Is there a way to give someone access to blinkUp a device and have it add to my account?
My fear is that they will sneak into the IDE and have a look at my code if I let them know my account details for blinkUp. Can I add a guest?
What exactly are you trying to do?
On past projects, where I’ve wanted to have a friend be able to run a device I’ve made, I’ve just asked for their network credentials then blinked it up to their network. This way the device stays in my account, and I can also manage/update code for them remotely. Informal, and quite convenient.
Might be an approach to consider depending on your relationship with the user, and assuming they’re ok with you having their network information. (The drawback of course is if they change networks, but this hasn’t been a big issue in the situations I’ve encountered).
Otherwise, I don’t believe you can add a guest … and they would have to have an account (with your model code) to do blink up and run your application.
There’s no concept of guest; commercial imp customers get the ability to do this, though (in fact, the customer has no account details from you at all).
Thanks @LarryJ & Hugo.
I have sent a third party company several devices. I need them to BlinkUp these devices to get them added to their WiFi network.
My fear is that if I give them my credentials for BlinkUp they could go to ide.electricimp.com and steal all the code that has been written for those devices.
I want a way for them to add devices to their WiFi network without the possibility of them going to ide.electricimp.com - logging in - and seeing all the code.
Many thanks,
Dan
@danbladen - our commercial solution solves this problem by providing you with a BlinkUp SDK that you can embed in a mobile app. The BlinkUp SDK, as Hugo mentioned, does not require the user to login.
The commercial solution also includes a variety of other tools that help managed commercial deployments of IoT products.
If you’re not interested in going down that road, you could consider creating a new Electric Imp account specifically for those products - that way if they log into the IDE, they won’t be logging into your IDE. This is a little inconvenient, as you’ll need to swap accounts a bunch… but it does keep things isolated, and let 3rd parties BlinkUp with lower risk…
hmm just spit balling here…
- setup a new ide account with nothing in it. 2) give those credentials for blink up. 3) Wait until after the all imps are online and then change that new account password. 4) then drop in the ‘production’ code
So these third party devices would then live in the new account.
We have about 40 devices in the field at customer sites. This should continue to grow. We’re talking perhaps hundreds of devices, not thousands. Due to a change in philosophy here about the tools we’re developing, I doubt we’ll ever get to the volume to justify developing our own BlinkUp and configuration applications and moving to the commercial cloud service. I’m simply not ready to take on iOS and Android app development.
The “guest” BlinkUp account to the developer cloud service (even it required a modest monthly fee–even it it were the same as the commercial platform) could be very appealing, assuming the code would not be accessible via these credentials.
Lacking that option, it would be nice to have: 1) A working sample BlinkUp app that we could easily adapt to our production account settings or 2) Confirmation that @Hyperone’s “spit balling” would actually work–changing the password after BlinkUp. The former solution being more attractive, as it would involve less on-going administration and headaches.
There is another way, which in my opinion is less work that developing and maintaining a smartphone app but admittedly more work than sending them a device with their credentials pre-configured (as @LarryJ suggests). I wouldn’t dream of giving clients our IDE account details.
For our test devices, we exposed an http api call to allow the user to change the wifi network details. imp.setwificonfiguration() allows you to set the credentials remotely, provided the unit already has a connection to the server. We just ask our trial clients to set up a hotspot on their phones with a known ssid and password. The imp would see these and connect. Once connected, the user was free to change the ssid and password.
There are a number of gotchas around this approach, but it works well for us. It wasn’t really practical until release 30 of the device OS. It will require a lot more imp code around wifi connection management.
Coverdriven…How is that going to work? As once the device leaves the factory or from your location and then arrives at the customer (or other location), there is no longer any WiFi connection. Therefore, the device can no longer connect to the server?
Can you explain this better, please?
@datalink10, I can send out a unit preconfigured with a temporary ssid/pw pair. However, this will only work if the unit is shipped with working firmware. In many factory situations, this will not be the case. When the client receives the unit, they allow it to connect through the preconfigured hotspot. The client is then free to program it (via a HTTP REST interface) to support their own Wifi network.
The imp is already replete with an API for setting up and controlling wifi connections. (see imp.setwificonfiguration(), imp.scanwifinetworks(), server.connect(), server.disconnect(), imp.getssid() etc). It is more complicated than what I describe here, but I know it works well as we have deployed quite a few devices to various sites in this manner.
In @danbladen’s case, it does not sound like a commercial case, so I was simply simply suggesting one of many possible solutions.
@hvacspei If you’ve got 40+ devices in the field (being used for commercial purposes by people who aren’t you) then really you’re a commercial user.
I believe that the zip file with the iOS blinkup tools does indeed have a full sample blinkup app in it (one in swift, too), but we have got other code we could likely provide for you if you’re up to changing some constants, dropping in logos, etc. There may also be someone who could do this for you for a small fee. The downside is paying apple $99/year to stay in the store.
We’re looking at javascript blinkup options as this works very well in phone browsers (and pretty well on some laptops). As a commercial user that would also allow you to do what you want.
@Hugo. All of the units are ours, but located at customer sites. I personally do all the Blinkups to date, but would like to feel more secure in allowing others to have EI Blinkup-only credentials in case something like WiFi credentials are changed at the site. It would save me a (sometimes lengthy) trip. For this flexibility, I was suggesting a fee structure that would allow EI to enjoy income as would be the case if it were a commercial account.
Early on, I was advised by an EI rep that if our volumes weren’t going to be significant (my word, not his), then sticking with the developer approach may make the most sense. We did pay for the Ops license in anticipation of moving that direction, but haven’t gone that route largely due to the effort required to build a BlinkUp app. I simply have no experience creating an iOS app.
I’m not trying to rock the boat. I’m really just trying to provide feedback from a very satisfied user about an option you might want to consider. My perception is that others have been hesitant about trying to develop an iOS app, let alone an Android app, too. There is/was a iOS developer in the area and I plan to speak with them about the cost of doing the development work. By the way, a simple app that we could tweak would likely be a great place to start, assuming embracing Xcode isn’t a daunting task.
By now I hope it’s apparent that I really enjoy working with the EI platform and the EI community. I’m merely trying to offer suggestions, not complain.
I understand apps are a PITA; I’ve actually pinged one of our developers with the blinkup js code I wrote years ago and he’s wrapped it up nicely into something that’s much more usable for others to integrate onto a webpage.
It does need documentation, but this is essentially done now… so I’ll try to get Tony to document it next week 
Note that this will, in general, work well with phones/tablets but YMMV on laptops and desktops. We have improvements to that in a future impOS release but I’ve not merged them yet.
Thank you. If I correctly understand what you’re saying, I think this will benefit EI as well as many users. Looks like I need to get working on several factory blinkup devices, since we have several models we deploy!
Thanks @hugo sorry for the slow reply. That sounds really interesting if you’re able to share the JS?
To use the js you need to have a commercial account (and hence an APIKEY to configure it). If you are a commercial customer, file a support ticket and we can send you the current code.