Merci pour ce pointeur ! As-tu déjà étudié/utilisé ce projet ? Serais-tu intéressé de l'évaluer avec la grille de critères proposée dans le rapport ? Celui-ci étant sous licence libre CC-BY-SA 4.0, toute contribution serait la bienvenue ! ;-).
Ah, nous voilà dans le tristement courant cas de l'emprisonnement utilisateur =). Une courte recherche Google avec les mots-clefs "open source LoRaWAN" a néanmoins fait ressortir https://www.loraserver.io/ côté software, et https://lorrier.com/ côté hardware (mots-clefs "open source LPWAN") : si la question t'intéresse, pourquoi pas envisager de jeter un oeil à ces solutions, et nourrir la discussion à ce niveau ? Ma connaissance des LPWAN est plus que limitée, et j'ai le sentiment que tu as déjà des éléments de réflexion à partager ? Merci en tout cas d'avoir soulevé la question, qui mérite clairement en effet d'être soulevée, puisque les LPWAN vont être amenés à faire de plus en plus partie du quotidien des dev IoT ;-).
Encore, Damaki a souligné exactement ce qui "cloche" : "c'est un peu un mix des deux".
La plupart des plateformes Cloud présentées proposent leurs SdKs pour plateformes périphériques Edge (arduinos, esp8266, raspis et autres contrôleurs tournant à base de Gnunux…) que clients (android, Gnunux, …).
Il était donc a priori pertinent que de souligner cet effort de la part des développeurs quand il le faisaient, car ces SdKs ont un intérêt loin d'être négligeable dans la conception d'une application IoT, puisqu'ils réduisent drastiquement le temps de prise en main de la plateforme dans son entièreté.
@François Revol : je ne connaissais pas du tout, et il n'est pas du tout ressorti dans mes heures de recherche, sûrement car je recherchais des plateformes middleware cloud, et pas des os pour périphériques Edge, comme l'a souligné Belegar. Néanmoins, le projet a l'air intéressant, et a sans aucun doute sa place dans l'écosystème très vaste de l'IoT.
@Belegar : Je n'ai rien trouvé en FOSS pour ce qui est de plateforme middleware cloud pour les réseaux LPWAN. Après, dans l'absolu, pour les relier aux plateformes ici présentées, il suffirait d'une Gateway IoT connectée à la fois au LPWAN et à Internet pour renvoyer les infos au reste du système, un simple module manquant en somme ? =)
Mon emploi du temps étant très chargé jusqu'à lundi prochain, je continuerai avec plaisir cette discussion la semaine prochaine : n'hésitez pas à apporter d'autres remarques, car toutes celles relevées jusqu'à maintenant sont définitivement pertinentes, et je vous en remercie tous (d'autant que j'avais pas mal d'appréhension au départ de faire un article pour diffuser ce rapport) ! Merci également pour le respect avec lequel vous formulez vos commentaires, cela rend la discussion d'autant plus agréable ! ;-)
Damaki a très bien saisi le sens du critère : je donne d'ailleurs le même argument dans le rapport.
Après je tiens à souligner que ce rapport n'a pas pour but de donner une note : trop de critères qualitatifs et divers, il serait trop long et d'une pertinence définitivement discutable que de les pondérer d'une quelconque façon.
L'intérêt du rapport est surtout de mettre en avant les forces et faiblesses de chaque projet sur la grande variété de critères, et trouver celui qui "brille" le plus subjectivement dans le cadre du besoin du Use Case auquel le rapport renvoie.
Donc, non, il n'y a pas de bonne note pour si le projet utilise du java (en fait, la plupart le fond : le seul autre language représenté est Javascript parmi ce genre de plateforme), seulement une préférence pour le use case. =)
Tout d'abord, merci pour votre commentaire fourni en arguments et remarques pertinentes !
L'intérêt d'une plateforme générique pour l'IoT (du moins, l'argument donné par la plupart des produits présentés ici) est justement de couvrir un grand panel de cas IoT, allant de la domotique à des capteurs météo pour l'agriculture, en passant par la gestion de capteurs urbains, comme le résume par exemple le site web du projet Kaa sur sa page https://www.kaaproject.org/overview/ :
"Kaa is a multi-purpose middleware platform for the Internet of Things that allows building complete end-to-end IoT solutions, connected applications, and smart products. The Kaa platform provides an open, feature-rich toolkit for the IoT product development and thus dramatically reduces associated cost, risks, and time-to-market. For a quick start, Kaa offers a set of out-of-the-box enterprise-grade IoT features that can be easily plugged in and used to implement a large majority of the IoT use cases."
Oui, bien sûr, comme dans n'importe quel développement, il est possible de faire un petit bidule rapidement avec quelques lignes de Python qui couvre juste un besoin, mais, comme dans tout développement, si l'on veut soit passer à l'échelle, ne plus avoir à maintenir un back-end et se concentrer sur l'application, à un moment, il est vite préférable de partir sur une base préexistante, développée avec un souci d'adaptabilité et de mise à l'échelle.
Kaa, par exemple, prend en compte aussi bien le cas du simple Arduino qui fait de la télémétrie au cas très complexe de la domotique en apportant :
- Une abstraction partielle du matériel IoT edge grâce à des kits de développement/bibliothèques pour un grand nombre de plateformes hardware, accélérant le développement
- La possibilité d'un contrôle et d'une mise à jour à distance si le cas le nécessite (#domotique) (ce qui n'est pas le cas de toute les plateformes, et qui aurait sûrement mérité un critère supplémentaire)
- Une abstraction partielle des machines clientes (de consultation ou contrôle, i.e. les smartphones, tablettes et autres ordinateurs) grâce à des SdKs rendant le même service que pour les périphériques Edge.
Ce que c'est plateforme génériques apportent, c'est justement de ne pas avoir à redévelopper toutes ces fonctionnalités et bien d'autres (interface d'administration, stockage, traitement, aggrégation des données, et j'en passe), et de pouvoir directement se concentrer sur des cas d'usages.
Il est vrai que le besoin exact (capteurs de consommation d'énergie allant d'une échelle locale à continentale, en résumé) n'est pas exprimé dans l'article, mais l'est au début du rapport avec un lien vers l'OCCIware Linked Data Use Case. Votre remarque montre que je devrais préciser cela directement dans l'article et le rapport, et pas juste mettre un lien dans le rapport =).
En ce qui concerne la sécurité, j'avoue bien honnêtement que mes deux critères "Statements" and "Audits" sont très limités, et mériteraient grandement d'être détaillés, notamment au niveau des questions de :
- Chiffrement
- Signature
- Détection des périphériques malveillants
- Containerisation
- Possibilités de mise à jour à distance pour combler les failles,
…
Néanmoins, je ne disposais que d'environ 3 heures d'analyse spécifique à chaque projet : j'explique donc dans le rapport que mes critères sont orientés de telle sorte que je pouvais respecter cette durée, en se concentrant sur une analyse du site web, de la documentation et du repo du projet. Cette durée d'analyse est un des points clefs du rapport. Pour aller à un niveau de détail aussi profond, étant donné le manque d'information flagrant pour certains projets (souligné dans le rapport), il aurait fallu prendre le temps de lire le code en bonne partie pour juger de la qualité réelle de la sécurité : en gros faire un audit. Non seulement je n'avais pas le temps, mais cela sort clairement de mon domaine de compétence, ce que je préfère admettre plutôt que de m'aventurer dans des conclusions hasardeuses.
Il me semble avoir adressé dans ce commentaire la totalité des points soulevés : si cela n'est pas le cas, je répondrai avec plaisir à d'autres remarques/questions/critiques ;-).
[^] # Re: Utilité des plateformes génériques ?
Posté par Xia0ben . En réponse à la dépêche Un petit état des lieux des plates‐formes IoT FOSS. Évalué à 0.
C'est tout naturel, merci à vous pour la pertinence de vos remarques =).
[^] # Re: gobot
Posté par Xia0ben . En réponse à la dépêche Un petit état des lieux des plates‐formes IoT FOSS. Évalué à 1.
Bonjour Eggus,
Merci pour ce pointeur ! As-tu déjà étudié/utilisé ce projet ? Serais-tu intéressé de l'évaluer avec la grille de critères proposée dans le rapport ? Celui-ci étant sous licence libre CC-BY-SA 4.0, toute contribution serait la bienvenue ! ;-).
Bonne journée à toi !
[^] # Re: Contiki ??
Posté par Xia0ben . En réponse à la dépêche Un petit état des lieux des plates‐formes IoT FOSS. Évalué à 1.
Bonjour Belegar,
Ah, nous voilà dans le tristement courant cas de l'emprisonnement utilisateur =). Une courte recherche Google avec les mots-clefs "open source LoRaWAN" a néanmoins fait ressortir https://www.loraserver.io/ côté software, et https://lorrier.com/ côté hardware (mots-clefs "open source LPWAN") : si la question t'intéresse, pourquoi pas envisager de jeter un oeil à ces solutions, et nourrir la discussion à ce niveau ? Ma connaissance des LPWAN est plus que limitée, et j'ai le sentiment que tu as déjà des éléments de réflexion à partager ? Merci en tout cas d'avoir soulevé la question, qui mérite clairement en effet d'être soulevée, puisque les LPWAN vont être amenés à faire de plus en plus partie du quotidien des dev IoT ;-).
Bien à toi !
[^] # Re: Contiki ??
Posté par Xia0ben . En réponse à la dépêche Un petit état des lieux des plates‐formes IoT FOSS. Évalué à 1.
Encore, Damaki a souligné exactement ce qui "cloche" : "c'est un peu un mix des deux".
La plupart des plateformes Cloud présentées proposent leurs SdKs pour plateformes périphériques Edge (arduinos, esp8266, raspis et autres contrôleurs tournant à base de Gnunux…) que clients (android, Gnunux, …).
Il était donc a priori pertinent que de souligner cet effort de la part des développeurs quand il le faisaient, car ces SdKs ont un intérêt loin d'être négligeable dans la conception d'une application IoT, puisqu'ils réduisent drastiquement le temps de prise en main de la plateforme dans son entièreté.
@François Revol : je ne connaissais pas du tout, et il n'est pas du tout ressorti dans mes heures de recherche, sûrement car je recherchais des plateformes middleware cloud, et pas des os pour périphériques Edge, comme l'a souligné Belegar. Néanmoins, le projet a l'air intéressant, et a sans aucun doute sa place dans l'écosystème très vaste de l'IoT.
@Belegar : Je n'ai rien trouvé en FOSS pour ce qui est de plateforme middleware cloud pour les réseaux LPWAN. Après, dans l'absolu, pour les relier aux plateformes ici présentées, il suffirait d'une Gateway IoT connectée à la fois au LPWAN et à Internet pour renvoyer les infos au reste du système, un simple module manquant en somme ? =)
Mon emploi du temps étant très chargé jusqu'à lundi prochain, je continuerai avec plaisir cette discussion la semaine prochaine : n'hésitez pas à apporter d'autres remarques, car toutes celles relevées jusqu'à maintenant sont définitivement pertinentes, et je vous en remercie tous (d'autant que j'avais pas mal d'appréhension au départ de faire un article pour diffuser ce rapport) ! Merci également pour le respect avec lequel vous formulez vos commentaires, cela rend la discussion d'autant plus agréable ! ;-)
[^] # Re: "Server percentage" ?
Posté par Xia0ben . En réponse à la dépêche Un petit état des lieux des plates‐formes IoT FOSS. Évalué à 1. Dernière modification le 18 octobre 2017 à 22:39.
Damaki a très bien saisi le sens du critère : je donne d'ailleurs le même argument dans le rapport.
Après je tiens à souligner que ce rapport n'a pas pour but de donner une note : trop de critères qualitatifs et divers, il serait trop long et d'une pertinence définitivement discutable que de les pondérer d'une quelconque façon.
L'intérêt du rapport est surtout de mettre en avant les forces et faiblesses de chaque projet sur la grande variété de critères, et trouver celui qui "brille" le plus subjectivement dans le cadre du besoin du Use Case auquel le rapport renvoie.
Donc, non, il n'y a pas de bonne note pour si le projet utilise du java (en fait, la plupart le fond : le seul autre language représenté est Javascript parmi ce genre de plateforme), seulement une préférence pour le use case. =)
Autrement, ce serait en effet "hallucinant". ;-)
[^] # Re: Utilité des plateformes génériques ?
Posté par Xia0ben . En réponse à la dépêche Un petit état des lieux des plates‐formes IoT FOSS. Évalué à 1.
Bonjour à vous !
Tout d'abord, merci pour votre commentaire fourni en arguments et remarques pertinentes !
L'intérêt d'une plateforme générique pour l'IoT (du moins, l'argument donné par la plupart des produits présentés ici) est justement de couvrir un grand panel de cas IoT, allant de la domotique à des capteurs météo pour l'agriculture, en passant par la gestion de capteurs urbains, comme le résume par exemple le site web du projet Kaa sur sa page https://www.kaaproject.org/overview/ :
"Kaa is a multi-purpose middleware platform for the Internet of Things that allows building complete end-to-end IoT solutions, connected applications, and smart products. The Kaa platform provides an open, feature-rich toolkit for the IoT product development and thus dramatically reduces associated cost, risks, and time-to-market. For a quick start, Kaa offers a set of out-of-the-box enterprise-grade IoT features that can be easily plugged in and used to implement a large majority of the IoT use cases."
Oui, bien sûr, comme dans n'importe quel développement, il est possible de faire un petit bidule rapidement avec quelques lignes de Python qui couvre juste un besoin, mais, comme dans tout développement, si l'on veut soit passer à l'échelle, ne plus avoir à maintenir un back-end et se concentrer sur l'application, à un moment, il est vite préférable de partir sur une base préexistante, développée avec un souci d'adaptabilité et de mise à l'échelle.
Kaa, par exemple, prend en compte aussi bien le cas du simple Arduino qui fait de la télémétrie au cas très complexe de la domotique en apportant :
- Une abstraction partielle du matériel IoT edge grâce à des kits de développement/bibliothèques pour un grand nombre de plateformes hardware, accélérant le développement
- La possibilité d'un contrôle et d'une mise à jour à distance si le cas le nécessite (#domotique) (ce qui n'est pas le cas de toute les plateformes, et qui aurait sûrement mérité un critère supplémentaire)
- Une abstraction partielle des machines clientes (de consultation ou contrôle, i.e. les smartphones, tablettes et autres ordinateurs) grâce à des SdKs rendant le même service que pour les périphériques Edge.
Ce que c'est plateforme génériques apportent, c'est justement de ne pas avoir à redévelopper toutes ces fonctionnalités et bien d'autres (interface d'administration, stockage, traitement, aggrégation des données, et j'en passe), et de pouvoir directement se concentrer sur des cas d'usages.
Il est vrai que le besoin exact (capteurs de consommation d'énergie allant d'une échelle locale à continentale, en résumé) n'est pas exprimé dans l'article, mais l'est au début du rapport avec un lien vers l'OCCIware Linked Data Use Case. Votre remarque montre que je devrais préciser cela directement dans l'article et le rapport, et pas juste mettre un lien dans le rapport =).
En ce qui concerne la sécurité, j'avoue bien honnêtement que mes deux critères "Statements" and "Audits" sont très limités, et mériteraient grandement d'être détaillés, notamment au niveau des questions de :
- Chiffrement
- Signature
- Détection des périphériques malveillants
- Containerisation
- Possibilités de mise à jour à distance pour combler les failles,
…
Néanmoins, je ne disposais que d'environ 3 heures d'analyse spécifique à chaque projet : j'explique donc dans le rapport que mes critères sont orientés de telle sorte que je pouvais respecter cette durée, en se concentrant sur une analyse du site web, de la documentation et du repo du projet. Cette durée d'analyse est un des points clefs du rapport. Pour aller à un niveau de détail aussi profond, étant donné le manque d'information flagrant pour certains projets (souligné dans le rapport), il aurait fallu prendre le temps de lire le code en bonne partie pour juger de la qualité réelle de la sécurité : en gros faire un audit. Non seulement je n'avais pas le temps, mais cela sort clairement de mon domaine de compétence, ce que je préfère admettre plutôt que de m'aventurer dans des conclusions hasardeuses.
Il me semble avoir adressé dans ce commentaire la totalité des points soulevés : si cela n'est pas le cas, je répondrai avec plaisir à d'autres remarques/questions/critiques ;-).
Bien à vous !