Piloter IPX800-v5 dans Gladys

[cce66]

Ok donc en fait :

gladys/device/mqtt:commutateur/feature/mqtt:commutateur/state

quand gladys publie, le topic sur mosquito c’est gladys et il y a en clés
device/commutateur/feature
device/commutateur/state

gladys/master/device/mqtt:commutateur/feature/mqtt:commutateur/state

quand gladys reçoit, le topic sur mosquito c’est toujours gladys et il y a en clés
master/commutateur/feature
master/commutateur/state

@Shiftmaj

Dans le premier cas, Gladys le publie sur Gladys/device (à destination du device, donc). Dans le second cas, c’est le device qui publie sur Gladys/master (à destination de Gladys cette fois), pour faire un retour d’état par exemple.

En fait c’est le coté device/master(car on a pas d’indication du sens d’envoi des données) qui trompe , slave/master (pas top) ou publish/suscribe (plus cohérent car cela indique le sens de l’envoi des données de façon implicite car le « device » comme « master » est à la fois master et slave dans le comportement !

@Shiftmaj

a position du switch sur cette page ne changera rien au fonctionnement des deux adresses, c’est juste un élément visuel.

Dans ce cas je pense que tout le monde s’accordera pour dire qu’il faudrait que les 2 adresses soit affichées de base et que si on coche “Est-ce un capteur ?” seule la ligne correspondante s’affiche !
Effectivement c’est quand implemente dans node-red qu’il faut faire attention à bien mettre dans les objets mqtt la bonne ligne !

[Shiftmaj]

@cce66

En fait c’est le coté device/master(car on a pas d’indication du sens d’envoi des données) qui trompe , slave/master (pas top) ou publish/suscribe (plus cohérent car cela indique le sens de l’envoi des données de façon implicite car le “device” comme “master” est à la fois master et slave dans le comportement !

Sur le fond, je suis assez d’accord avec ton analyse.
Néanmoins, dans notre cas, avec Gladys, on peut faire l’hypothèse que c’est notre point central (box domotique) qui pilote le reste et qui gère tout l’aspect logique/ordonnancement. Dans ce contexte, il est assez logique de nommer ce nœud principal « master ».
Je ne veux pas trop m’avancer, mais je pense que c’est la logique qui a menée à choisir ces dénominations.

@cce66

Dans ce cas je pense que tout le monde s’accordera pour dire qu’il faudrait que les 2 adresses soit affichées de base et que si on coche “Est-ce un capteur ?” seule la ligne correspondante s’affiche !

Je plussois cette partie, il me semble que ce bouton soit régulièrement source d’incompréhension sur le forum. Il faudrait peut-être créer un autre topic pour en discuter ?

[cce66]

@Shiftmaj

Néanmoins, dans notre cas, avec Gladys, on peut faire l’hypothèse que c’est notre point central (box domotique) qui pilote le reste et qui gère tout l’aspect logique/ordonnancement. Dans ce contexte, il est assez logique de nommer ce nœud principal “master”.

Oui si effectivement gladys et mosquitto sont hébergés sur la même machine on peut le voir comme un point central mais le serveur mosquitto deployé par gladys dans la machine sur lequel il tourne fait également office de serveur pour d’autres clients qui ne passe pas par gladys et si gladys passe par un autre serveur mosquitto (ce qui est possible puisque paramétrable, par exemple chez moi j’ai un autre nuc sur lequel est hébergé Home-assistant sur lequel tourne mosquitto). Et si le noeud principal est « master » la logique aurait voulu que les devices soient …slave !

@Shiftmaj

Je plussois cette partie, il me semble que ce bouton soit régulièrement source d’incompréhension sur le forum.

Je confirme j’ai mis un bout de temps à comprendre ce point là alors que j’ai déployé sans problème un flow node-red sur home-assistant qui interagis avec mon module domotique IPX800V5 (ce module intègre des objets mqtt « suscribe » et « publish »).

[pierre-gilles]

@cce66

Dans ce cas je pense que tout le monde s’accordera pour dire qu’il faudrait que les 2 adresses soit affichées de base et que si on coche “Est-ce un capteur ?” seule la ligne correspondante s’affiche !

Oui 100% d’accord, c’est un problème d’UX Il y a déjà une issue Github qui a été créé =>

MQTT: Add the publication Topic sensor if the option "Is it a sensor?" is disabled

[cce66]

Bon alors bonne nouvelle enfin presque (now j’ai plus de cheveux ! )
J’ai enfin réussi à avoir le fonctionnement dans les deux sens (relais IPX800V5 <=> Gladys) en utilisant des “commutateur” (ajouter le relais serait bien car pour moi commutateur=interrupteur )

et pareil coté IPX800V5

les suscribe MQTT coté IPX800V5

les publish MQTT coté IPX800V5

le flow graphique

et le debug dans l’ordre :
Relais 1 “On” depuis l’IPX800V5

Relais 1 “Off” depuis l’IPX800V5

Relais 1 “On” depuis Gladys

Relais 1 “Off” depuis Gladys

Et le flux au format json

 [{"id":"cf6dc2aae7c8ab92","type":"tab","label":"Flow 3","disabled":false,"info":"","env":[]},{"id":"91ee9c360eac6d43","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"IPX800_V5-1","topic":"IPX800_V5-1","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1230,"y":100,"wires":[]},{"id":"c2659b7b2ff21d6e","type":"function","z":"cf6dc2aae7c8ab92","name":"selon payload \"[IPX]Relay state x\" true/false => 0/1","func":"var msg1,msg2;\n\nswitch (msg.payload) {\n    \n  case \"{\\\"[IPX]Relay state 1\\\":true}\":\n    msg1 = {payload:\"1\" };\n    break;\n  case \"{\\\"[IPX]Relay state 1\\\":false}\":\n    msg1 = {payload:\"0\" };\n    break;\n    \n  case \"{\\\"[IPX]Relay state 2\\\":true}\":\n    msg2 = {payload:\"1\" };\n    break;\n  case \"{\\\"[IPX]Relay state 2\\\":false}\":\n    msg2 = {payload:\"0\" };\n    break;  \n    \n  default:\n    break;\n}\n\nreturn[msg1,msg2];\n","outputs":2,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":220,"wires":[["d7e02d71312aa03e"],["6ea07d03df94f62e"]]},{"id":"d9a7d3602448c88a","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"IPX800_V5-1","topic":"IPX800_V5-1","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":150,"y":220,"wires":[["c2659b7b2ff21d6e"]]},{"id":"d7e02d71312aa03e","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"gladys/master/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","topic":"gladys/master/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1000,"y":180,"wires":[]},{"id":"6ea07d03df94f62e","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"gladys/master/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","topic":"gladys/master/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1000,"y":260,"wires":[]},{"id":"4dc3520e0af08d51","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state      .","topic":"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":350,"y":80,"wires":[["1bedbf53cbd0b7c2"]]},{"id":"e51228ced7b818c2","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","topic":"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":360,"y":140,"wires":[["1bedbf53cbd0b7c2"]]},{"id":"658e6d08a9bfa70c","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"#","topic":"#","qos":"2","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":130,"y":300,"wires":[["0b066345aae7ddb9"]]},{"id":"0b066345aae7ddb9","type":"debug","z":"cf6dc2aae7c8ab92","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":340,"y":300,"wires":[]},{"id":"1bedbf53cbd0b7c2","type":"function","z":"cf6dc2aae7c8ab92","name":"selon topic => [IPX]Relay cmd x : true/false","func":"var msg1,msg2;\n\nswitch (msg.topic) {\n  case \"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state\":\n    \n    switch (msg.payload) {\n      case \"0\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 1\\\":false}\" };\n        break;\n      case \"1\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 1\\\":true}\" };\n        break;\n      default:\n        break;\n    }\n    break;\n    \n  case \"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state\":\n\n    switch (msg.payload) {\n      case \"0\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 2\\\":false}\" };\n        break;\n      case \"1\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 2\\\":true}\" };\n        break;\n      default:\n        break;\n    }\n    break;\n    \n  default:\n    break;\n}\n\nreturn[msg1,msg2];","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":860,"y":100,"wires":[["91ee9c360eac6d43"]]},{"id":"291914c5c9c68f02","type":"mqtt-broker","name":"mqtt://localhost","broker":"mqtt://localhost","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]

J’ai des latences voire des non prise en compte si les ordres sont fait trop rapidement mais si on attend pas de souci cela fonctionnes très bien par contre depuis un node red dans home assistant donc homea assistant <=> IPX800V5 pas de latence !
Par contre depuis Gladys cela génère 4 message sur le debug au lieu de 2 quand c’est depuis l’IPX800V5

[cce66]

@pierre-gilles
Bon pour le coup je vais faire un tuto et sur le site de Gladys et sur le site de GCE pour montrer comment faire une passerelle via node-red entre gladys et l’IPX800V5 (en lien direct ça passe pas dans l’IPX800V5, la chaine mqtt est trop longue) sinon tu connais MQTT Essentials - Part 1 | Introduction to MQTT - YouTube faite par un des membres du comité des spécifications MQTT par contre pour les boutonneux du rosbeef c’est pas sous-titré

[pierre-gilles]

@cce66

J’ai des latences voire des non prise en compte si les ordres sont fait trop rapidement mais si on attend pas de souci cela fonctionnes très bien par contre depuis un node red dans home assistant donc homea assistant <=> IPX800V5 pas de latence !

Très bizarre ! Tu confirme que les conditions sont les mêmes (home assistant/node-red/Gladys sont sur la même machine ?), Gladys ne faisait rien de spécial ?

@cce66

Bon pour le coup je vais faire un tuto et sur le site de Gladys et sur le site de GCE pour montrer comment faire une passerelle via node-red entre gladys et l’IPX800V5

Top, merci @cce66 !

[cce66]

@pierre-gilles

Je pense que ce serait plus simple aussi de ne pas mettre la partie “mqtt:” de “ID externe de la fonctionnalité” dans le topic, cela n’a pas de sens pour moi et ca rallonges le topic et sur l’ipx800v5 ca devient trop long ! (pas trouvé si il y a une limite pour le topic)
par exemple en renommant IPX800V5-1 en IPX800V5

gladys/device/mqtt:IPX800V5_Relais1/feature/mqtt:IPX800V5_Relais1/state

deviendrait

gladys/device/IPX800V5_Relais1/feature/IPX800V5_Relais1/state

voire (selon la norme MQTT)

gladys/device/IPX800V5_Relais1/state

De même

gladys/master/device/mqtt:IPX800V5_Relais1/feature/mqtt:IPX800V5_Relais1/state

devriendrait

gladys/master/device/IPX800V5_Relais1/state

Ca me parait plus clair là tout de suite non ?

Et comme les Dupont et Dupont je dirais même plus :

IPX800V5 souscrit à “Gladys\commutateur\state” (payload 0 ou 1 / on ou off / true ou false)
Gladys publie sur “Gladys\commutateur\state” (payload 0 ou 1 / on ou off / true ou false)
Si par scène ou dans la discussion je dis à Gladys “ouvre le relais” Gladys ouvre le commutateur
et publie l’état du commutateur, l’IPX800V5 est informé et bascule son relais et lycée de Versailles !

Gladys souscrit à “IPX800V5\Relais1\state” (payload 0 ou 1 / on ou off / true ou false)
IPX800V5 publie “IPX800V5\Relais1\state” (payload 0 ou 1 / on ou off / true ou false)
Si le relais de l’IPX800V5 est commuté par programmation dans l’IPX800V5 celui-ci publie l’état de son relais, Gladys est informé et bascule son commutateur
Le tout avec le QOS à 1 pour éviter les boucles

Donc dans Gladys on a

• une souscription à l’état du Relais1 de l’IPX800V5 (“IPX800V5\Relais1\state”)
• une publication de l’état du commutateur de Gladys (“Gladys\commutateur\state”)

Et dans l’IPX800V5 on a

• une souscription à l’état du commutateur de Gladys ( “Gladys\commutateur\state”)
• une publication de l’état du Relais1 de l’IPX800V5 (“IPX800V5\Relais1\state”)

On appréhende mieux cela si on considère que le broker mosquito ne sert qu’à stocker et transmettre les messages que des clients (publieurs) envoient à d’autres clients (souscripteurs) et que donc les clients peuvent indifféremment être à la fois publieur et souscripteur mais il faut à chaque fois bien préciser l’id du client émetteur de la publication et l’id du client receveur de la publication (Gladys et IPX800V5)

Tout cela n’étant valable que si il n’y a pas une raison objective de faire autrement !
Donc même si Gladys tient un rôle de ‘master’ et pilote les périphériques ‘esclaves’ qui lui sont associés d’un point de vue mqtt il reste un client de mosquitto comme les autres périphériques !

[pierre-gilles]

@cce66

Je pense que ce serait plus simple aussi de ne pas mettre la partie “mqtt:” de “ID externe de la fonctionnalité” dans le topic, cela n’a pas de sens pour moi et ca rallonges le topic et sur l’ipx800v5 ca devient trop long ! (pas trouvé si il y a une limite pour le topic)

En fait tu veux retirer le préfix obligatoire « mqtt: » sur l’ID externe, c’est plus une question d’ID externe que de topic MQTT.

A la base on a mis ce préfix car cet ID externe est unique en DB à tous les device dans tout Gladys, et on ne veut pas que plusieurs intégrations puissent entrer en collision, vu que l’intégration MQTT est la seule intégration ou l’utilisateur choisit cet ID externe.

Après je suis d’accord que niveau lisibilité c’est moins clean, et ça fait ces problèmes de topics trop long. A débattre avec l’équipe. @AlexTrovato T’en pense quoi ? (retirer le préfix « mqtt: » obligatoire pour les nouveaux périphériques MQTT)

@cce66

les clients peuvent indifféremment être à la fois publieur et souscripteur

C’est exactement ça

@cce66

Donc même si Gladys tient un rôle de ‘master’

En fait l’idée de master ce n’est pas que Gladys est « master », je pense que tu as mal compris cette notion de l’API car tu n’as pas tout l’historique de la conception : un des développements futurs de la v4 (bon après c’est du très long terme), c’était d’avoir une notion d’instance « maitre », et d’instances « pods »

L’idée c’était d’avoir théoriquement des « mini gladys » qui puissent tourner sur d’autre machine pour pouvoir contrôler des appareils distants.

Ainsi, Gladys ne serait pas juste une instance mais un réseau de plusieurs instances, dont 1 maitre et X pods.

On a conçu l’API pour pouvoir indiquer que tu parles à Gladys « master » :

gladys/master/**

Ou à une instance pod:

gladys/pod/ID_DU_POD/**

Néanmoins, cette notion n’étant pas développée, je ne t’en ai pas parlé pour ne pas t’embrouiller

Mais je t’assure que toute cette API c’est des mois de réflexion et de travail, rien n’est dû au hasard ! Je t’invite à relire les discussions sur le forum de la conception, tout est publique.

[cce66]

@pierre-gilles

retirer le préfix “mqtt:” obligatoire pour les nouveaux périphériques MQTT)

J’ai pas trouvé dans les docs sur mqtt cette obligation ? c’est dans la 5 ? En tout cas cela marches parfaitement sans dans l’exemple mis plus haut entre l’IPX800 et nodered !

@pierre-gilles

dont 1 maitre et X pods.

Là ok cela a du sens « gladys\master » « gladys\pods » et « gladys\device » avec ensuite des propriétés et des méthodes ! On est bien dans l’internet des objets !
D’ailleurs en réfléchissant au vu de ces infos…l’IPX800V5 est quelque part …un mini-pods !

[cce66]

Bonjour @pierre-gilles

Après beaucoup de sueur, j’ai enfin réussi à piloter l’IPX800V5 depuis Gladys, voici le tuto !

Mini Tuto - Interaction Gladys - IPX800V5 via node-red

Le but de ce tuto est de montrer comment piloter des relais de la plate-forme domotique IPX800V5 de GCE avec Gladys Allez dans l’onglet « Système » [image] Cliquez sur « MQTT » [image] Paramétrez comme suit, avec pour « Serveur: " l’ip du broker mosquito (IP du raspberry ou du Nuc sur lequel est installé Gladys, en « Client ID » le nom que vous voudrez (j’ai mis ici IPX800V5 c’est important pour les paramétrage des Topic dans Node-red) [image] Ensuite on va dans l’onglet « Liens » [image…

Et le même sur le forum de GCE histoire de faire connaitre Gladys aux possesseurs d’IPX800V5, je pense que la partie Gladys plus pourrait vraiment les intéresser !

Mini tuto Gladys Nore-red IPX800V5

J’espère avoir publié au bon endroit.
Par contre, coté reco vocale j’ai vu cela, c’est récent et ca a l’air performant
https://hub.docker.com/r/alphacep/kaldi-vosk-server
https://hub.docker.com/r/alphacep/kaldi-fr

Créer sa propre reconnaissance vocale. Librairie python : vosk

Ce serait intéressant d’étudier la question de le déployer dans gladys ! Je vais essayé de le déployer sur mon nuc et voir comment « jouer » avec. C’est vrai que cela manques par rapport à la v3 !

[pierre-gilles]

@cce66

J’espère avoir publié au bon endroit.

J’ai bougé le tutoriel dans la catégorie « tutoriel » du forum

Bravo pour le tuto, c’est top !

[cce66]

Bah si cela peut faire avancer le schmilblick et le coté IPX couplé au Zigbee via Gladys est complémentaire (manques plus que la reco vocale… )
Je vais en faire un autre car sur node-red il y a un module sun-calc qui permet de calculer la position du soleil et couplé aux capteurs température ça peut faire des scénario intéressant avec le module de volet roulants de GCE Pilotage volets roulants - X4VR qui est pilotable en mqtt via l’IPX800V5 !

[cce66]

Par contre @pierre-gilles, il y a t-il des boutons qui pourrait faire le job par rapport aux volets roulants ?

[pierre-gilles]

Non! Il y a 2 demandes de fonctionnalités qui vont dans ce sens:

Bouton à impulsion

Je propose d’ajouter un bouton à impulsion dans les fonctionnalités des Appareils. Par exemple, un des premiers équipement que l’on souhaite contrôler est le ou les volets roulants électriques. Une des possibilités est d’utiliser les fonctionnalités proposées ici : Gestion des volets roulants - #13 par syper Une autre possibilité est d’utiliser uniquement un bouton à impulsion (toujours le même message) qui permet de monter, de stopper ou de descendre le volet. Derrière bien sûr il faut gérer…

Et de manière plus complète:

Gestion des volets roulants

Ce sujet fait suite à l’issue GitHub : @AlexTrovato on peut en parler ici en français car j’ai l’impression qu’on ne se comprend pas en anglais là bas En fait le problème c’est de stocker l’information sur les capacités du volet roulant. Imaginons 3 marques de volets hypothétique : La première est contrôlée par une télécommande avec 3 boutons: ouvrir les volets à 100%, ouvrir à 50%, et ouvrir à 0% (position fermé) La deuxième est contrôlée par une télécommande avec un bouton …

[cce66]

@cce66

avec le module de volet roulants de GCE Pilotage volets roulants - X4VR

C’est pour cela que j’ai préféré automatiser mes volets avec mon IPX car j’ai des retour d’états que je peux gérer via MQTT et donc utiliser dans Gladys !

Et avec node-red il y a également ce module qui permet pas mal de possibilités pour gérer les VR, finalement l’intégration de node-red avec Gladys est

flows.nodered.org

node-red-contrib-blindcontroller-v2

A collection of Node-Red nodes that automates the control of household roller blinds on the current position of the sun

Et on peut connaitre la position du soleil sur les volets ici Calcul de la position du soleil dans le ciel pour chaque localisation à importe quel moment

Manque plus que le bouton qui va bien dans gladys !

Comme qui dirait il manques plus à Gladys que la parole…et la reconnaissance vocale !

[Fabic]

Pour gérer les volets et les moteurs il y a aussi Tasmota : Shutters and Blinds - Tasmota

Pour le coup, l’intégration dans Gladys est automatique mais il manque pour être parfait soit le bouton à impulsion soit les boutons “Monter et Descendre” comme l’a proposé @syper dans cette demande d’intégration : Gestion des volets roulants - #16 by pierre-gilles

Le seul défaut pour moi dans le mode 1 de Tasmota est que le temps de commutation entre “Monter” et “Descendre” est fixé en dur dans le code à 50 ms. Un peut juste pour des relais, et dans certain montage avec triac et même mosfet.

[cce66]

Je connais pas tasmota, il y a un module VR ? Car je préfères une solution qui soit ok en cas de problèmes (incendie) car les assurances dans ce cas cherchent toujours à t’enfumer en disant que t’as fait du bricolage !

[pierre-gilles]

@cce66

Dans ce cas je pense que tout le monde s’accordera pour dire qu’il faudrait que les 2 adresses soit affichées de base et que si on coche “Est-ce un capteur ?” seule la ligne correspondante s’affiche !

Je confirme que je viens d’améliorer l’UX de la vue MQTT en affichant les 2 topics lorsque l’option est désactivée

Actionneur:

Capteur:

Pour l’instant c’est dans une PR, ça partira dans la prochaine mise à jour de Gladys.

Fix #1401 : Improve MQTT integration UX by adding listen & publish topics to non read-only devices

[pierre-gilles]

Je confirme que l’amélioration d’UX est dispo dans Gladys Assistant 4.8 :

Gladys Assistant 4.8 est disponible et permet d'utiliser les calendriers dans les scènes !

Hello à tous, Suite au live, je suis heureux de lancer Gladys Assistant 4.8 officiellement Vous trouverez toutes les nouveautés dans un article récapitulatif sur le blog : Le replay du live est dans l’article Merci à tous ceux qui étaient là, et tous ceux qui ont contribués à cette nouvelle version !