8 réponses à ce sujet

[Thot]

Travaillant dans le contrôle des bâtiments et menant des recherches sur comment le contrôle des bâtiments pourrait être idéal, je suis toujours confronté au fait qu'à un moment il faut un server central qui gère tout, que les bâtiments doivent echanger avec ce serveur, au moins pour du contrôle à distance. Même si ces liaisons restent ultra sécurisées, ca reste le point faible en cas d'attaque, de panne du serveur central, et si le serveur central est hébergé par un tier, il faut avoir confiance.
Le dernier point est qu'au final, souvent, il faut échanger un nombre, un booléen ou au pire un json entre deux machines, ça n'implique pas la mise en place d'une architecture aussi complexe.

En robotique, c'est d'autant plus le cas.

Pour le moment, j'envisage le contrôle des bâtiments sans connexion Internet, en «mode robot autonome». Mais Internet c'est bien quand-même.

J'ai decouvert matrix.org, je voulais savoir si des personnes connaissent ou s'ils connaissent d'autres technos.

[Ludovic Dille]

J'ai déjà un tout petit peu touché à matrix mais ça reste un gros bazard pour ce que tu veux faire j'ai l'impression.
Un petit server web c'est pas très compliqué à faire et pour sécuriser tes messages tu peux regarder du côté des jsonweb token
 

[R1D1]

Pas sûr que ma réponse t'aide beaucoup, mais mon département utilise Riot + Matrix.org comme système de chat interne.

Pour bien comprendre ta problématique: contrôle des bâtiments = domotique ? Et tu parles d'un ensemble de bâtiments contrôlés depuis un point central ?

 

D'un point de vue robotique, on construit autant que possible des systèmes informatiques hiérarchiques : ma boucle de contrôle bas-niveau tourne sur le hardware embarqué (connexion capteurs-actuateurs) et peut fonctionner en l'absence de commande de plus haut niveau / connexion au réseau (e.g. il y a un évitement d'obstacle réactif en local). La commande de direction globale vient d'un autre programme sur le robot (e.g. un planificateur ou un système de décision réactif -- je vois du rouge je vais à droite, je vois du vert, je vais à gauche, ...). Si ce programme crashe pour une raison quelconque, ma boucle bas-niveau tourne toujours et assure la sécurité minimum de l'évitement d'obstacles. S'il y a un système plus complexe qui a besoin de ressources non disponibles sur le robot (un gros traitement d'images ou du raisonnement symbolique), les systèmes inférieurs doivent pouvoir fonctionner indépendamment. La fréquence de communication baisse au fur et à mesure qu'on monte dans la hierarchie : la boucle de contrôle est en général au kHz, un système réactif de l'ordre du Hz, un planificateur symbolique de l'ordre du mHz (pifométriquement, hein).

[Thot]

Merci beaucoup pour le json web token, je ne connaissais pas.

Pour les serveurs web, c'est l'option que nous prenons en local mais au final, on se retrouve dépendant du fonctionnement de la box Internet, si c'est une IP pas fixe, ouverture des ports dédiés, possibilité d'avoir des certificats SSL...

Quand il y a changement de box ou une infrastructure réseau un peu costaud, ça devient vite galère.

Le fait que l'IP ne soit pas fixe reste le plus gros bazar à gérer, surtout quand la personne utilisatrice n'est pas au courant de toutes ces choses.

[Ludovic Dille]

Hmm comme ça je dirais que matrix ne vas non plus régler ces soucis vu que ça va encore rajouter une gestion de serveur et patatra :/

[Thot]

Hmm comme ça je dirais que matrix ne vas non plus régler ces soucis vu que ça va encore rajouter une gestion de serveur et patatra :/

Beh oui...

 

 

Pas sûr que ma réponse t'aide beaucoup, mais mon département utilise Riot + Matrix.org comme système de chat interne.

Pour bien comprendre ta problématique: contrôle des bâtiments = domotique ? Et tu parles d'un ensemble de bâtiments contrôlés depuis un point central ?

 

D'un point de vue robotique, on construit autant que possible des systèmes informatiques hiérarchiques : ma boucle de contrôle bas-niveau tourne sur le hardware embarqué (connexion capteurs-actuateurs) et peut fonctionner en l'absence de commande de plus haut niveau / connexion au réseau (e.g. il y a un évitement d'obstacle réactif en local). La commande de direction globale vient d'un autre programme sur le robot (e.g. un planificateur ou un système de décision réactif -- je vois du rouge je vais à droite, je vois du vert, je vais à gauche, ...). Si ce programme crashe pour une raison quelconque, ma boucle bas-niveau tourne toujours et assure la sécurité minimum de l'évitement d'obstacles. S'il y a un système plus complexe qui a besoin de ressources non disponibles sur le robot (un gros traitement d'images ou du raisonnement symbolique), les systèmes inférieurs doivent pouvoir fonctionner indépendamment. La fréquence de communication baisse au fur et à mesure qu'on monte dans la hierarchie : la boucle de contrôle est en général au kHz, un système réactif de l'ordre du Hz, un planificateur symbolique de l'ordre du mHz (pifométriquement, hein).

Oui, c'est de la domotique, je vais pas jouer sur les mots mais on ne fait pas que du domestique (domotique = mot du mal ) 

Il s'agit plutôt du contrôle d'un unique bâtiment par une interface web accessible de partout et hébergée en local. C'est ensuite derrière cette interface que se fait la gestion du bâtiment, et nous travaillons sur du contrôle décentralisé (KNX+ROS1). D'où le souci le l'IP pas fixe et la gestion SSL.

[Ludovic Dille]

Qu'est-ce qui bloque pour le SSL ? Car pour la gestion de certificat certbot de Let's encrypt c'est pas mal (tu peux facilement automatiser la renouvellement mais faut accès à internet).

Et sinon pour l'ip fixe, ça dépend beaucoup du router qui relie à internet mais normalement si tu mets une DMZ (en gros ça permet de spécifier une ip locale de redirection) + une allocation d'ip spécifique à la machine qui doit gérer l'interface (via son adresse MAC par exemple).

[Thot]

Qu'est-ce qui bloque pour le SSL ? Car pour la gestion de certificat certbot de Let's encrypt c'est pas mal (tu peux facilement automatiser la renouvellement mais faut accès à internet).

Et sinon pour l'ip fixe, ça dépend beaucoup du router qui relie à internet mais normalement si tu mets une DMZ (en gros ça permet de spécifier une ip locale de redirection) + une allocation d'ip spécifique à la machine qui doit gérer l'interface (via son adresse MAC par exemple).

Je parlais de l'IP publique par exemple pour acceder via smartphone de partout. En local, on fixe l'IP du serveur mais en public, ça dépent du fournisseur Internet. ca dépent par exemple contrat PRO ou particulier, si c'est Free, l'IP publique est fixe...

Ou alors, il faut déclarer un nom de domaine par bâtiment...

[Mike118]

Bon ok c'est pas je sujet et je suis un peu HS mais Thot ça te dirait pas qu'on étudie la chose avec les possibilités de vigibot comme on avait évoqué à la TRR ?
Je suis curieux de savoir les besoins que tu as en détail ... On peut déjà faire énormément de choses avec vigibot... et pas de soucis d'adresses ip non fixes etc ... Et il est possible d'avoir plusieurs serveurs et que chaque bâtiment soit connecté à ces plusieurs serveurs ...