Undefined behaviour using a Blinkup SDK based app

Situation: A development device has been blinked up to a developer account with EI’s app, and is running a model. Later the same device is blinked up to the production account with our own app based on EI’s SDK, e.g. in connection with internal field-test.

Now the device is listed on the production account under a test software, and appear to running it, but actually it is running something else. If the model is changed and a build and run is performed, the device reboots, but does not load the revised model. It is also not possible to assign the device to another test software on the production account.

This takes quite a while to sort out every time it happens, especially when the person who blinked up the device ex. in an internat field test, is not the person trying to figure out what happens.

This has been reported as a bug, and the response was that it is a feature.

So here the feature request to please change this behaviour. Apart from being a major pita as described above, it appears as if EI is not in control of the system, and the same with the developers in the organisation trying to bring out products on the EI platform. From a system point of view I am sure it can seem perfectly reasonable, but for all intents and purposes it is experienced as undefined behaviour - a bug.

What you’re describing is a developer device being configured with a production token; this is being addressed but isn’t a supported configuration; we expect people in development to use development blinkup, and people in production to use production blinkup.

There are two aspects to this: really, any device going out to the field (being used by someone who isn’t a developer) should be blessed. This prevents the device running any code apart from code you specify as blessing establishes the permanent ownership.

The problem with blessing is that you then have to deploy to all devices on that model to change the code; the ability to deploy to subsets of devices is deep in development right now. The current workaround is to bless a small number of test devices to a test model and deploy to that.

The second aspect is that the behavior when you do unsupported things should be better so that the problem is easier to debug. We’re also working on this.

We are testing the combined solution internally to be ready for a first presentation to our key customer on Monday. We do not have a production setup ready at all (takes months).

We need our key customer to sign off on the basic concept first, before we move on.

What is the work around? Can we use the EI app to clear configuration and then blinkup to the production account, so our app can be used with the device as intended?

(If it is a payment issue, it is way better to bill for active units on the production account - We need to finish development with the customer involved.)

The workaround is to use developer BlinkUp so that you can change the assigned model, and then to do another production BlinkUp (with a different plan ID; it has to be different) with your app.

That is another culprit then - our App use the same plan-id each time to keep the agent related settings/history. Sounds like that is really not supported in this case.

“developer blinkup” means the EI app while logged in with the production account credentials?

It seems we have to clear credentials with the EI app first, then blinkup with the EI app while logged in with production credentials, assign a model, and then blinkup with our SDK based app (production end point). But you still have to press build and rund after the last blinkup for the device to actually run the model.

(It also seems, if you change model, after that the agent stops/migrates, we loose settings, and our app stops working, but that is another story).

What if you later need to build and run with a correction, what needs to happen for this to run with our SDK based app? You press build and run on the model alone and the few device assigned automatically update, or do you have to start over with developer blinkup and then our SDK based app blinkup?

I believe that it’s only changing model that doesn’t work; making code changes and hitting Build&Run should work fine.

Would changing model work if our SDK based app change the plan-id at each blinkup?

Anyway, at this point it looks like there is a work around for what is needed.

The feature request remaining is that the behavior when you do unsupported things should be clear.

@rogerlipscombe

The workaround is to use developer BlinkUp so that you can change the assigned model, and then to do another production BlinkUp (with a different plan ID; it has to be different) with your app.

Unfortunately it does not seem to work. After using developer blinkup, assign the wanted model, hit build and run and watch the model run on the device, as soon as we use our SDK based app to blinkup, then some devices change back to another model not present in the account.

We can see that because we always hardcode the model name + build number into device code and server log it at each interaction with our server.

“Developer blinkup” is the EI App while logged in with production account credentials.

making code changes and hitting Build&Run should work fine.

With battery operated devices we made sure to press build and run while the device is online, and see it restart and go to sleep before blinking up with our app (not touching the model).

So I will make a PR on it, and look for a work around for Monday?

Using production blinkup on a developer device is an unsupported configuration. I’ll continue this conversation on the support system.