Accelerometer datas were available in API v1, disappeared in v3.
In "Signals" page of your website (here), you claim accelerometer is globally available.

What are Xee plans about that ?
Are there other interested API users in these datas ?

Almost every 2 days, one of the refresh_tokens expires (out of a total of ~20), and the API respond with a enigmatic :

{"error":"invalid_request"}

The only solution is the get a new refresh_token by manually enter the credentials in the consent screen. I don't have precise stats about this issue, but it is too frequent and serious enough for production environments. Happens since ... mmm... 4 months.

Just occurs this morning with a relatively new refresh_token got last week : 2017-08-30 10:37:40 UTC

If the refresh_token is expired for some reasons, the API should return a appropriate and explicit error message, to allow apps to properly handle the errors and send a renewal request to the account owner.

In the trips and trip APIs.

The documentation specifies that the creationDate and the lastUpdateDate are provided but none of them are in the API.

Solution: Update the API to add the missing values

It would be great to have a sandbox API to test the results of APIs without having a user connected his data.

For example :
https://dev.xee.com/doc/api/api/v3/cars/signals_list.md
older than
https://github.com/xee-lab/xee-api-docs/blob/master/api/api/v3/cars/signals_list.md

Un appel de phare correspond à la séquence rapide 0;1;0 pour le signal des feux.

Entre l'appel de phare et la disponibilité du signal par l'API Xee, il peut se passer jusqu'à plusieurs minutes et les différents changements sur un signal ne sont pas envoyés (seule la dernière valeur est présente).

Du coup pour détecter un appel de phare via l'API, il faut que le signal des feux soit à 0 avec un timestamp modifié depuis le dernier appel à l'API.

La question est comment détecter un double appel de phare, voire triple ?
Est-il possible d'avoir un nouveau signal pour cet évènement ?

L'évènement double appel de phare peut être utile dans des scénarios liés à la domotique.

Trying to use /vehicles/{vehicleID}/compatibility, I got a list of available and unavailable signals.

A large part of signals reported as available are in fact, reported as non-existant when queried to by using /vehicles/{vehicleID}/signals?signals={signalName} and this returns a 400 error.

{
  "error_description": "Signals does not exist",
  "error": "signals_unexistant"
}

The ones that are working are actuallly the ones returned by /vehicles/{vehicleID}/status.

I don't see any link between the confidence variable and the real availablity of signals. All available signals are marked as confidence: true, here, execpt one (FuelLevel).

status is also returning ComputedAccActivity, and ComputedFuelLevel as available signals, which are not mentionned by compatibility

I have tested this only on one vehicle, so I don't know if it's a problem with the API or the vehicle/brand/model

kType is mentionned when updating a vehicle PUT /vehicles/{vehicleId} or returned when querying a vehicle either with GET /vehicles/{vehicleId} or with GET /users/me/vehicles

I don't know nothing (sic) about cars. But I can't find it either on the internet with a search engine. Except it was in API v1 and v3 already.

Bonjour,

La récupération des données sur un mois est assez long.
Après quelques tests, pour récupérer un mois de données sur quelques signals, on récupére 5mo de données avec un temps de réponse de 6-7 secondes.
Il est donc difficle d'utiliser ces services pour du temps réel.

Est-ce qu'il est possible de donner un filtre sur les données à récupérer ?
Par exemple, on voudrait récupérer les signals uniquement quand les phares sont allumés. Un parametre dans la requete de type "...&light=on".

Sinon, est-ce prévu ?

Merci d'avance

If one get an acess token with the REST API at https://cloud.xee.com/v3/auth/access_token

One get as result something like ```

{
    "access_token":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "token_type":"bearer",
    "expires_in":13060800,
    "expires_at":1481904143,
    "refresh_token":"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
}

1481904143 means 2016-12-16 at 17:02:23
But the token expires just minutes or an hour after creation.

13060800 means 151 days

It is not an error in documentation but implementatoin but there is nowhere to mention that.

In the list of signals, there are some typos:

• HighBeamsSts instead of HighBeamSts
• LowBeamsSts instead of LowBeamSts
• HeadLightsSts instead of HeadLightSts

When I ask for some ktypes with the in_service parameter, it is not working.
Without the parameter, I got the expected response from the API.

the REST API url https://sandbox.xee.com/v3/cars/42/signals?name=LockSts&begin=2016-07-24T00%3A00%3A00' gives the same 101k of data with all the signals mixed up and not the only one requested.
I mean LockSts was asked since yesterday above but all the signals were there in the json response.

Moreover the data begins from the start of the month instead of yesterday.

There is a typo in the error description

In:
https://dev.xee.com/signals

No mention of:

AutoRearWiperSts 	Represents the Auto rear Wipers status 	0 = off, 1 = on
ManualRearWiperSts 	Represents the Manual rear Wiper status 	0 = off, 1 = on

From https://github.com/xee-lab/xee-api-docs/blob/master/api/api/v3/cars/signals_list.md

I just wanted to report minor issues in documentation or feature request/improvements.

• In the section "Request and format", it could be added that for each request should be used the "Authorization" header with the value "Bearer: $ACCESS_TOKEN" where $ACCES_TOKEN has been granted at the previous step in the OAuth authentication. I guess this is implied but best be explicit, no ?

• In the pagination section, in the HTTP snippet example, it is a GET that is performed, hence it is not a Content-Type header but an Accept header. In the 2 examples.

• In the "Authorization" section, there is no mention about the refresh_token, nor how to use it.

• In the "Signals" section, there is no list of the available signals. One have to go and get them in API v3 doc. I guess signals list is bound to each model of car.

• The signals are returned in inverse chronological order. Then, if you use a Range: signals=-15 as header, one does not get that last 15 signals. In fact, one needs to use Range: signals=0-15

• /vehicles/{vehicleId}/status needs multiple scopes. One have to guess and try:

  • vehicles.signals.read
  • vehicles.locations.read
  • vehicles.accelerometers.read

It could be mentionned.

There is no explanation of what are privacies and nothing about their purposes. At least, a line would be ggod.

Thanks

Trying to use /vehicles/{vehicleId}/trips returns an empty array.

No privacy session is opened and locations returned by /vehicles/{vehicleId}/locations are available. One can draw trips from locations data.

Opening a privacy session render locations data unavailable. As could be expected.

But then why is there no trip reported/returned when no privacy session is running ?

Only tested with one vehicule.

In the access_token page.
The Authorization Header values are wrong.

Should be

But is

When you attempt to use the REST API v4 /trips/{tripId}/locations, with either "application/json" or "application/vnd.geo+json" header, one gets an error in firefox or Edge, when requesting the API over an ajax call.

This is, however, working in Chrome/Chromium (??)

In detail, the XHR ajax request is preflighted because of the "Authorization" header.

But 303 redirects are not allowed by the W3 spec for preflighted ajax CORS requests.
Source: https://stackoverflow.com/a/20854800/283067 if this is correct

This is an old spec but not all browsers have upgraded.

Trying to use the fetch API to work around that limitation does not seem to work either, even though that limitation as been lifted in that API spec too.

There is a 2 years old bug in mozilla bugzilla for firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1346749

Also this page https://w3c-test.org/cors/redirect-preflight.htm shows that niether edge nor firefox are currently working with cors preflight redirect.

I've made an SDK for pythoncompatible with 2.7 and 3.5

You can see it there xee-sdk-python

third part_y_ server in setup/README.md

fix url example in auth/auth.md

Pour récupérer les informations (localisation et signaux) d'un ensemble de voiture, il faut le faire voiture par voiture.

Du coup cela oblige à mettre en place une stratégie pour ne pas faire trop d'appels http.
Serait-il possible de pouvoir faire un appel dans l'API pour plusieurs voitures en même temps ?

par exemple :

https://{env}.xee.com/v3/cars/{carId1,carId2,...}/status

Il n'y a rien dans la documentation à propos des informations de "deviceData".

Notamment, il semble y avoir une property "RunState" mais dont j'ai déjà pu voir les valeurs 0, 3, 5 et 9. Quelles sont les valeurs disponibles et à quoi font-elles référence ?

Merci

One line to explicit what happens when you disassiocate a vehicle would be helpfull.

1. The vehicle is still know from Xee API but with no device attached ?
2. The data of the vehicle are still kept intact ? and visible with the API ?
3. The Xee Connect can be associated with the same vehicle again ?
4. Can still be associated with a new vehicule ?

Ca serait très pratique si on pouvait mettre des wildcard dans les redirect url d'une app Xee (dans le dashboard développeur). Par exemple, pouvoir mettre :

http://localhost:8080/*
ou
https://myapp.com/xee/*/callback

Au delà de faciliter le développement en local, mon cas d'usage en prod pour l'instant c'est le renouvellement du refresh_token (par exemple pour ajouter des scopes ou quand l'utilisateur change son mot de passe).
Dans ce cas on aimerait faire une requête de ce genre afin d'identifier quel compte on veut mettre à jour :
https://myapp.com/connections/xee/{xee_account_id}/renew

D'ailleurs à partir du moment où une app est publique dans le Xee Store ça serait peut-être une bonne chose d'obliger ces URLs à être en HTTPS afin d'éviter les attaques man-in-the-middle.

As there was a https://sandbox.xee.com/v3/ for v3 of the API that exposed fake mocking data, woulnd't be possible to get a vehicle accessible for all accounts for test and/or demoing for API v4 ?

May be one such vehicule could be generated on demand (with its own unique uuid) (on the dev panel ?) but point to only one general fake vehicule ? to simplify feasability ?

I have 2 use case here

• I can't test/develop features related to electric vehicule because I haven't one.
• I can't demo my site without showing my own Xee data.

I the response of a car, the deviceId should be a serial number (string) and not a generic id (integer)

It could be great if I can add a webhook in order to receive your alerts like "vehicle is moving". For example for "talk to my car" this kind of feature allows me new things. It's better for you too because I don't have to fetch the vehicle state every 5 seconds.

Trying to use /users/me/authorizations of API v4 gives error:

{
    "error":"insufficient_scope_permissions",
    "error_description":"Add the account.authorizations.read scope(s) to your application scopes and reconnect the user"
}

This scope is not listed on dev.xee.com app dashboard.

Attempting to request for this scope while doing authorization gives the warning: 'Request for non existent scope".

This is the same for /brands/xee/devices/{deviceID} and devices.administration scope

Add trip statistics like

• Mileage
• Used time

In the auth/auth page.

The url parameters
scope and redirect_uri are marked as mandatory but they are not.

In the access_token page.
The parameter grant_type for the refresh token is wrong.

Should be

But is

I have developped an app using app engine. When using the local dev server, every thing works fine and I can authenticate and get a token and use the app. For that I redirect to localhost:8080

But when I push my code to App Engine, I can't get the token of the 2nd step of OAuth because I got an error I don't understand.

HTTP Error 400: {"error":"invalid_request","error_description":"The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed."}

The code is exactly the same, only the redirect uri i schanged.

I compared the headers sent by the code when run localy and run on app engine, there is 2 differences.

{
  "args": {
    
  },
  "data": "",
  "files": {
    
  },
  "form": {
    "code": "bGVCMXXXXGtaVWJFNVJBUnh1TGNqY253dm5pRUpGa0o",
    "grant_type": "authorization_code"
  },
  "headers": {
    "Accept-Encoding": "gzip",
    "Authorization": "Basic mybasekeysecret",
    "Connection": "close",
    "Content-Length": "78",
    "Content-Type": "application\/x-www-form-urlencoded",
    "Host": "httpbin.org",
    "User-Agent": "Python-urllib\/2.7 AppEngine-Google; (+http:\/\/code.google.com\/appengine; appid: dev~myxeedashboard)"
  },
  "json": null,
  "origin": "myip",
  "url": "https:\/\/httpbin.org\/post"
}

and on app engine

{
  "args": {
    
  },
  "data": "",
  "files": {
    
  },
  "form": {
    "code": "ZDXXXXXXXXX1JDNDZOMVFUZEkzYnF3SEtlS3VxU1I",
    "grant_type": "authorization_code"
  },
  "headers": {
    "Accept-Encoding": "gzip,deflate,br",
    "Authorization": "Basic mybase64keysecret",
    "Connection": "close",
    "Content-Length": "78",
    "Content-Type": "application\/x-www-form-urlencoded",
    "Host": "httpbin.org",
    "User-Agent": "Python-urllib\/2.7 AppEngine-Google; (+http:\/\/code.google.com\/appengine; appid: e~myxeedashboard)",
    "X-Cloud-Trace-Context": "3bc377a888836efd079a22f8f23371ab\/4355818241902851511;o=1"
  },
  "json": null,
  "origin": "107.178.196.147",
  "url": "https:\/\/httpbin.org\/post"
}

The Accept-Encoding and the X-Cloud-Trace-Context

So why xee server is choking and refusing my connexion ???

In file : xee-api-docs/api/api/v3/README.md

The sentence :
Somethings it was v1, sometimes v2
should probably be
Sometimes it was v1, sometimes v2

I can fix and do a PR if you wish.

Ben-

As already discussed with Xee team, this route is a must-have.
Hope you will be able to release it in few days/weeks.

GET /v3/users/{userId}/devices

[
  {
    "deviceId": "E160000000",
    "carId": 10000   # associated to a car
  },
  {
    "deviceId": "E160000000",
    "carId": null    # no car associated yet
  }
]

If possible to implement (in future releases), the following fields could be usefull :

• timestamp of first data from this device
• timestamp of last data from this device
• cardbId detected

Frequency is not describe for advanced signals in doc here: https://dev.xee.com/signals

It could be usefull for somes Dev.

Hello,

The « heading » field for:

/cars/{carId}/locations and /trips/{tripId}/locations

is not Integer but Float

thx.

Hello Xee team,

The market of electric cars and plug-in hybrid electric vehicle is increasing exponentially, and probably among Xeetizens too.
New signals for specific needs of EV owners will be so cool !

Here is the list of essential signals :

• - Charge plug state (boolean)
• - Charge state (boolean or value of charging power)
• - % of battery charge (%)
• - Time for complete charge (minutes)
• - Autonomy (km)

Two fields are different in API and Documentation

To keep coherence we need to keep

List of actions:

• Update Documentation to set id instead of uuid.
• Update API and add the field endDate with the same value as stopDate and deprecate stopDate (will be removed in the next version).

In the response body of the /users/me API.

There is a typo in the nickName field (n instead of N)

Android SDK and iOS SDK deserves their own repositories.

The documentation could have a link to all the SDKs (official and unofficial).

• Android xee-sdk-android
• iOS xee-sdk-ios

Bonjour

l'api v1 ne fonctionne plus, impossible de se connecter sur domonux, est-ce normal ?

Merci

In docs, there are 2 different naming for the same human readable ID of the device :

• deviceId (11 occurences) :
  https://github.com/xee-lab/xee-api-docs/search?q=deviceId

• xeeId (10 occurences) :
  https://github.com/xee-lab/xee-api-docs/search?q=xeeId

Sur les endpoints /cars/{id}/locations et /cars/{id}/signals on peut ajouter un paramètre limit,
ce qui permet de faire à peu près le même effet que de la pagination,
mais dans le résultat que retourne l'API on ne voit pas si ce paramètre a eu un effet... ou pas.

On ne peut donc pas savoir si il est nécessaire de faire une requête supplémentaire pour avoir toutes les datas sur la période de temps initialement demandée.

A minima, un header HTTP serait utile pour donner le nombre total de résultats :
Xee-Limit-Total-Results: 350000 (350 000 est un cas réel sur un de nos véhicules)

Idéalement, vous pourriez fournir un header Link pour donner l'url de la page suivante (best practice des API REST), en conservant les paramètres de la requête initiale. Il suffirait juste de modifier le paramètre end pour qu'ils ne sélectionnent pas les locations déjà retournés :

Link: <https://cloud.xee.com/api/v3/cars/{carId}/locations
   ?begin={begin de la requête initiale}
   &end={date de la plus ancienne location parmi les résultats, ou n+1 pour l'exclure}
   &limit={limit de la requête initiale}>; rel="next"

Avez-vous d'autres solutions en tête ?
Comment faire en attendant ?

I would like to add a query params named "sort" in order to sort by a param. For example if I make a request like /cars/{carId}/trips?sort=-mileage in order to have trips ordered in decreasing order of mileage value. The implementation is an example in order to explain my need.

It's in order to avoid this kind of response from "talk to my car" -> "Vos trajets ne sont pas assez significatifs pour calculer votre consommation. Dans vos 15 derniers trajets aucun ne dépasse 20km, je ne préfère donc pas m'avancer sur une consommation qui ne serait pas très représentative, j'espère que tu comprends :)"

It would be great to have a /me/cars to retrieve cars directly from a Bearer.

the following signals have disappeared from a call to the REST API at https://cloud.xee.com/v3/{car_id}/status, namely

• HighBeamsSts
• LowBeamsSts
• HeadLightsSts
• FrontFogLightSts
• RearFogLightSts
• IntermittentWiperSts
• LowSpeedWiperSts
• ManualWiperSts
• HighSpeedWiperSts
• AutoRearWiperSts
• ManualRearWiperSts

Please help me to eradicate this kind of error :)

{
"type": "PARAMETER_ERROR",
"message": "Range issue in dates",
"tip": "You can only request one month max per request"
}

For a better world

When you request location following this model:
/v3/cars/{carId}/locations?begin=2016-01-01T00:00:00+00:00&end=....
you get an parsing issue as an answer.
It seems that your parser only accept 2016-01-01T00:00:00Z format for now.

Also i've noticed another issue about overlap on months
/v3/cars/{carId}/locations?begin=2016-08-31T22:00:00Z&end=2016-09-16T16:24:32Z
works even if you have parts on august and september. Is it normal ?
Because if we try with even more then you get the "You can only request one month max per request" issue (I've tried from start of the year to now).

The user profile from API has a role field, but the only explanation is :

user, dev, others

Not very explicit.
A better description which explains the precise meaning of the role is needed.