La société propose depuis plusieurs années un boîtier ODB à brancher sur sa voiture afin de récupérer des données.
« Comme beaucoup d’autres entreprises aux États-Unis, la pandémie de Covid-19 a eu un impact négatif sur nos activités […] Il s’agit d’une période sans précédent, et avec tant d’incertitude à venir, nous avons pris la décision difficile d'arrêter notre produit Automatic pour voitures, le service et la plateforme », explique la société.
La fermeture aura lieu le 28 mai 2020. La société demande à ses clients de recycler leur boitier, qui ne sera plus d’aucune utilité. Si vous avez acheté un boîtier récemment, vous pouvez demander un remboursement partiel.
Commentaires (16)
#1
Encore un produit connecté qui ne peut pas fonctionner en standalone ?
" />
#2
Une preuve de plus qu’il ne faut pas faire confiance à une société pour ce type de service…
La moindre des choses serait d’ouvrir les specs de ce truc…
#3
C’est le genre de produit à éviter.
" /> ).
Le derniers que j’ai qui est collé à un service c’est une caméra de surveillance Xiaomi, mais parce que c’était avec une bonne grosse promo (et surtout parce que à l’époque, le combo Raspberry+Caméra me faisait freeze le raspberry, maintenant c’est mieux avec un Raspberry4, MotionEyeOS et des raspb zéro pour les cams
#4
Je ne sais pas comment fonctionne leur produit mais si tu as un tableau de bord en ligne, tu as une connexion à un serveur et donc par définition non ça ne fonctionne pas en standalone.
Récupérer des données d’un objet de ce type c’est bien mais quand l’historique commence à grossir la seule option viable c’est le stockage en ligne et pas sur ton téléphone.
#5
C’est un service, quand la société qui propose le service disparaît, le service disparaît avec lui.
Rien d’extra ordinaire, donc. Ca aurait été mieux d’ouvrir les specs mais la boîte perdrait toute sa valeur si c’était le cas, économiquement ce n’est pas malin, et de toutes façons ça aurait demandé un effort en plus qu’ils n’ont peut-être pas les moyens de payer.
#6
ouaip …
" />
De l’art de créer des produits fermés pour créer des déchets et enfermer les utilisateurs….
#7
#8
Tout dépend comment communiquent ces boîtiers, s’il y a des choses hard codées (clés de chiffrement, urls des serveurs, etc). Le code source doit peut-être être nettoyé, il n’y a peut être pas beaucoup de doc, il y a peut être de la propriété intellectuelle, etc.
Bref il peut y avoir des blocages, et rien n’est jamais aussi simple que dans la théorie dans ces cas là.
#9
Je ne connais pas le produit, c’est comme un boitier de vitesse ? Selon la taille du pommeau, j’imagine bien une nouvelle utilisation, que la décence m’empêche de décrire trop précisément
" />
#10
Sauf si des portions du code ne viennent pas de toi. Tu dois demander l’autorisation de leur auteur.
#11
Sauf que ça n’est souvent pas possible. Lors de la faillite, les actifs sont liquidés et le code source en fait partie. Cette propriété intellectuelle pourrait très bien être acquise par une autre société, même s’ils n’en feront rien.
#12
Et tout dépend aussi de la qualité de la documentation du code.
Dans ma vie, j’ai eu entre les mains des codes sources non documentés et de fait in-maintenables sans la présence du (des) développeur(s).
Résultats : codes de supers produits à la poubelle.
Si vous en voulez, j’en ai un paquet !
#13
#14
#15
C’est beau le cloude ❤
#16
Alors déjà 80Mo de données, c’est déjà pas mal pour une appli mobile, ensuite, tu oublies la réalité de l’utilisation, qui est que les gens perdent, cassent et changent de téléphone portable. Pour une entreprise qui développe un service comme ça, c’est extrêmement naturel de le baser sur un stockage et hébergement en ligne car ça permet d’une part de garder un historique complet avec backups et tout le tintouin, mais aussi de faire d’éventuels calculs d’agrégation ou d’analyse en ligne sur des serveurs bien puissants pour qui 100 ou 150Mo de données à traiter ne sont absolument rien, alors que ça pourrait faire galérer un téléphone un peu trop bas de gamme.