​​[#DAISEE] Carnet de bord pour les activités de la #BiennaleDesign17 

​
​Lisez Moi

​​ 
​​Ce document est le carnet de bord des contributeurs de DAISEE (réguliers & occasionnels) engagés sur la conception et le déploiement d'un "microgrid" (énergétique) adapté au ​+tiers-lieu(x)​ de la Biennale de Design de Saint-Etienne (du 9 mars au 9 avril 2017). Le prototypage a été 'accéléré' sur le temps de la résidence Open City Lab (23-29/01/2017), à la MYNE et au PAA, 3e workshop du réseau tiers-lieux préparant la biennale de design de Saint-Etienne.
​​ 
​​Pour un aperçu de la connaissance liée à DAISEE : https://frama.link/DAISEE-knowledge
​​ 
​​Ce document est régi juridiquement par une Creative Commons Licence CC-BY-NC-SA 4.0
​​ 
​​  

​
​0 - Organisation

​​ 
  • ​​Ce chat permet d'échanger en continu entre contributeurs DAISEE sur le projet biennale.
​​ 
  • ​​Ce board est dédié au suivi des tâches sur le sprint de prototype durant Open City Lab.
  • ​​Cette carte Trello a permis de préparer le déploiement des activités sur Open City Lab.
​​ 
  • ​​Ce tableau a permis de faciliter la logistique de l'hébergement pour les "non lyonnais".
  • ​​Ce dossier permet de collecter les factures (cf. les frais de transport liés à Open City Lab).
​​ 
  • ​​Ce "moment" permet de refaire le film des conférences qui ont eu lieu sur Open City Lab.
​​ 

​
​1 - Contexte global

​​ 
​
​Définitions clés
​​ 
  • ​​La Biennale de design (à Saint-Etienne) : ensemble d’expositions temporaires orchestrées par la Cité du Design de Saint-Etienne qui valorisent la création contemporaine accessible à tous dans une ambiance festive rythmée par des événements, des visites et des ateliers. 
  • ​​La Cité du Design : établissement public de coopération culturelle (EPCC) créé en 2009 qui a pour mission de sensibiliser tous les publics au design. Elle s'inscrit dans un projet de reconversion et de développement économique du territoire de Saint-Etienne (source).
  • ​​Open City Lab : 3eme workshop préparatoire avant la Biennale du Design qui s'est déroulé à Lyon de manière distribuée entre la MYNE et les PAA. Le but était d'avancer sur les "oeuvres" qui seront présentés à la Biennale et de mettre à l'epreuve la gouverance opérationelle. 
  • ​​La M[Y]NE : tiers-lieu 'situé' à Villeurbanne / maison (géré) en 'bien commun' qui permet d'expérimenter à moindre coût & dans une ambiance conviviale des projets (de transition).
  • ​​PAA : Pratiques Artistiques Amateur (Perrache). Une opportunité pour la M[Y]NE de tester des processus de collaborations dans un espace accueillant des artistes et plasticiens. Proposé par @bruno qui développe les "Ateliers Amateurs" depuis une dizaine d'années.
  • ​​DoZE Parc : proposition d'exposition des membres de la M[Y]NE pour la biennale (voir).
  • ​​CréaTEC (Créations Transdisciplinaires Expérimentales Collaboratives) : ensemble de projets ("produits" par La M[Y]NE et al.) qui se destinent à être expérimentés sur DoZE Parc.
  • ​​Rhombi(dodécaèdre) : Polyèdre ayant douze faces décagonales et des faces carrées (voir).
​​ 
​​ 
​
​Documentation
​​ 
​
​Objectifs DAISEE
​​ 
  • ​​Oeuvre DAISEE
​​DAISEE est intégrée à chaque rhombi  Celui de DAISEE est dédié à la visualisation énergétique. Objectif : consulter la consommation, la production et plus largement les flux énergétiques. Les faces du rhombi représentent la visualisation énergétique de chacun des rhombi de l'exposition.
​​ 
  • ​​User Experience
​​Les visiteurs pluggent leur smartphone sur l’exposition ou produisent directement de l'énergie (dynamo, vélo, etc.) et participent à l’apport en énergie pour la zone tiers-lieux. En retour ils gagnent des 'DAISEECoin'. Cela montre qu'ils sont déjà TOUS des prosumers (à développer...).
​​ 
  • ​​Chantiers de dev
  • ​​Production d'énergie
  • ​​Consommation d'énergie
  • ​​"Infrastructure" d'échanges
  • ​​Visualisation de la donnée
​​ 
  • ​​Prototype techno (0.2)
  • ​​Intégrant des données de sources de production et de consommation réelles
  • ​​Mettant en scène et montrant les consommations, productions et flux d'échanges
  • ​​permettant un échange automatique pair-à-pair multi-consommateurs et multi-producteurs
​​ 
​​Note : le proto v 0.2 (1) sera intégré dans un rhombi (2) devra interconnecté chaque rhombi-projet et en extraire les données de conso et prod ainsi que gérer les flux "pair-à-pair" (3) devra intégrer l'interface usagers (cf. possibilité  de se brancher avec son mobile pour participer à la production.
​​ 
  • ​​Objectifs détaillés 
  1. ​​Mettre en place des sources de consommation et de production (> données réelles).
  1. ​​Capter de manière pertinente (sensibilité et précision) la donnée de conso et de prod.
  1. ​​(Re)développer l'algorithmie des échanges pour l'intégration multi-utilisateurs :
  1. ​​Tout sur la blockchain (le contract porte l'intelligence de l'ensemble du système)
  1. ​​Ou bien hybrider avec d'autres algo (cas actuel : une partie est portée par Python)
  1. ​​Faire évoluer Ethereum VS d'autres technos (IPFS, BigChainDB, IOTA...) | à investiguer.
  1. ​​Développer la visualisation des données de consommation et de production 
  1. ​​Développer la visualisation des données  des flux énergétiques de l'espace.
  1. ​​Passer d'un système mono-conso / prod à un système multi-conso / multi-prod.
  1. ​​Faire participer les visiteurs en leur permettant de se connecter avec leur téléphone / ou du participer  de la production d'énergie dans l'espace et recevoir des DAISEECoin.
​​ 
  • ​​Scénarii de dev
  • ​​Scénario 1 : proto qui capte de la donnée issue de sources de consommation et de production réelles avec une gestion des flux (transactions) multi-acteurs. Réponse aux objectifs : 1 / 2 / 3 (a ou b en fonction des compétences et envies autour de la table) / 7 / 8
  • ​​Scénario 2 : scénario 1 + data viz. Réponse aux objectifs : 1 / 2 / 3 (a ou b en fonction des compétences et envies autour de la table) / 5 / 6 / 7 / 8 (si le temps le permet).
  • ​​Scénario 2bis: scénario 1 + Hybridation. Réponse aux objectifs : 1 / 2 / 3 (a ou b en fonction des compétences et envies autour de la table) 4 / 5 / 6 / 7 / 8 (si le temps le permet).
  • ​​Scénario 3: un prototype complet répondant à l'ensemble des objectifs (avec arbitrage au niveau l'objectif 3 et articulation entre objectif 3 et 4. Réponse aux objectifs: 1 / 2 / 3 (a ou b en fonction des compétences et envies autour de la table) 4 / 5 / 6 / 7 / 8.
​​ 

​
​2- Contributeurs

​​ 
​
​Présents sur Open City Lab
​​ 
​​ 
  • ​​Pour rappel, dans le cadre de cette résidence, été pris en charge : 
  • ​​Les déplacement (dans la limite de 150€ / personne)
  • ​​Le logement (hébergement chez l'habitant à Lyon !!)
  • ​​La nourriture (petit déjeuner + déjeuner en commun)
​​ 
​​
​​Prénom
​​Nom
​​Organisation
​​Pratique
​​Timing
​​Rieul
​​Techer
​​DAISEE
​​Facilitateur
​​Lundi au Dimanche
​​Samira
​​Rabaâoui
​​DAISEE
​​Données
​​Lundi au Dimanche
​​Nicolas
​​Loubet
​​DAISEE
​​Gouvernance
​​Lundi au Dimanche
​​Simon
​​Contraires
​​DAISEE
​​Données
​​Mardi et Mercredi
​​Alizée
​​Manutea Grard
​​DAISEE
​​Designer
​​Lundi au Vendredi
​​Emmanuel
​​Laurent
​​Forker l'Energie
​​Maker
​​Lundi au Dimanche
​​Louis
​​Villard
​​DAISEE
​​Ingénierie
​​Lundi
​​Aude
​​Omerin
​​DAISEE
​​Design
​​Lundi au Vendredi (soir)
​​Paul
​​Flipo
​​DAISEE
​​Hardware
​​Mardi (soir)
​​Sylvain
​​Pastor
​​DAISEE
​​Hardware
​​Lundi (soir) et Samedi
​​Kim
​​Castelli
​​Kim Hub
​​Informatique
​​Jeudi et Vendredi
​​Alain
​​Brégy
​​Beachain
​​Blockchain
​​Jeudi et Vendredi
​​Julien
​​Brodier
​​Sunchain
​​Blockchain
​​Jeudi au Samedi
​​David
​​Colliaux
​​P2P Food Lab
​​Computer Vision
​​Jeudi et Vendedi
​​Stéphanie
​​Couvreur
​​Enercoop
​​Médiation
​​Vendredi
​​Stéphane
​​Frenot
​​INSA Lyon
​​Informatique
​​Vendredi
​​Maxime
​​Pico
​​Food Computer
​​Machine Learning
​​Vendredi au Dimanche
​​Clément
​​Epié
​​Cellabz
​​Curiosité
​​Jeudi au Samedi
​​David
​​Level
​​Freelance
​​Micro-services
​​Samedi
​​Simon
​​Macor
​​Freelance
​​Micro-services
​​Samedi
​​ 
​
​Non présents (suivi en différé)
​​ 
​​
​​Nom
​​Prénom
​​Organisation
​​Pratique
​​Feedback
​​Olivier
​​Blondeau
​​CitizenWatt
​​Design global
​​A caler
​​Julien
​​Béranger
​​iex_ec
​​Ethereum
​​A caler
​​Serge
​​Ravet
​​Open Recognition Alliance
​​Meta-design
​​A caler
​​Xavier
​​Lavayssière
​​Bricodeurs
​​Informatique
​​A caler
​​Gael
​​Musquet
​​CxLinks
​​IT embarqué
​​A caler
​​Primavera
​​De Filippi
​​COALA / Plantoid
​​Droit
​​A caler
​​Anthony
​​Ferreti
​​Collectif BAM
​​Design de service
​​A caler
​​Thomas
​​Thibault
​​Collectif BAM
​​Design de service
​​A caler
​​Romain
​​Lafforgue
​​Collectif BAM
​​Full stack Ethereum
​​A caler
​​Paul
​​Marchesseau
​​ARTEL (Post Piper)
​​Design & Architecture
​​A caler
​​Cédric
​​Carles
​​Atelier 21
​​Design
​​A caler
​​Philippe
​​Gattegno
​​Open Aquaponie
​​Néo-artisanat
​​A caler
​​Xavier
​​Blot
​​BeyondLab
​​Dev de projet
​​A caler
​​Peter
​​Hanappe
​​Sony CSL
​​Ingénierie
​​A caler
​​Alexandre
​​Monnin
​​Inria
​​Web des données
​​A caler
​​Alexandre
​​Poltorak
​​Content backed tokens
​​Ethereum
​​A caler
​​Shaban
​​ Shaame
​​Spell of Genesis
​​Community design
​​A caler
​​Nicolas
​​Sierro
​​Spell of Genesis
​​Business & UX
​​A caler
​​Glenn
​​Roland
​​Gnuside
​​IT
​​A caler
​​Christoph
​​jentzsch
​​Slock.it
​​Ethereum
​​A caler
​​Sebastien
​​Kurt-D'ovidio
​​Mainstenant
​​Architecture
​​A caler
​​ 

​
​3- Open City Lab

​​ 
​​ 
​
​23 Janvier
​​ 
​​ 
  • ​​Présent..e.s : 
  • ​​Rieul T.
  • ​​Emmanuel L.
  • ​​Sam. R.
  • ​​Simon C.
  • ​​Nicolas L.
  • ​​Xavier C
  • ​​Alizée M.
​​ 
  • ​​Objectifs
  • ​​Clarifier les objectifs de la semaine
  • ​​Clarifier l'état d'avancement de DAISEE
  • ​​Faire le point sur les envies de Sylvain
​​ 
  • ​​Chek-in à la MYNE (10h-11h)
​​ 
  • ​​Objectifs (OCL) : 
  • ​​Finaliser les œuvres pour le tiers-lieu(x) de la biennale.
  • ​​Expliciter / mettre en visibilité le processus tiers-lieux 
  • ​​Qu'est ce que DAISEE peut produire pour la Biennale ? 
  • ​​Vision des flux énergétiques entre objets / usagers
  • ​​Intégration de la relation visiteur (avec interaction.s)
  • ​​DAISEE aura son propre Rombi avec des faces LED représentant les schémas de conso / prod de chaque projet avec une / des interface.s
​​ 
  • ​​Acteurs : 
  • ​​Emmanuel : travaille sur du mobilier qui fait de la micro-production d'énergie. Cette semaine, il va finaliser un générateur à pédales (fait à partir de matériel de récupération). Intéressé par le regard des contributeurs + Suivi de la production d'énergie + Visualisation. Comment on prend conscience de la production d'énergie (pour des non spécialistes) ?
  • ​​Alizée : designer intéressée par les piles végétales. Travaille avec des électroniciens et biologistes au FabLab de l'UBO . Souhaite ré-introduire le végétal dans l'espace urbain. Pensait travailler sur l'éclairage urbain (cf. gouvernance de l'éclairage). Comment stocker l'énergie ? Quel type de batteries ? Pas mal de problématiques commune avec DAISEE.
  • ​​Simon : géophysicien (appliqué). A travaillé sur le stockage du CO2. Expérimentateur. A participé au démarrage de DAISEE (notamment sur la couche hardware / CitizenWatt). Très intéressé par la partie captation de données. Là avec nous mardi, mercredi, vendredi.
  • ​​Xavier : biologiste. Participe à la vie d'une communauté dédié au biomimétisme (Le Biome). Engagé sur la compréhension des systèmes complexes. Projets en interaction avec DAISEE: (1) micro-prod à partir de tapis d'herbier marin (2) colonne de Winogradsky. 
  • ​​Rieul  : se positionne comme facilitateur.  "VRP de Daisee" (sic), moteur d'Open City Lab. Forte envie de montrer que les technos blockchain vont évoluer les formes de travail. 
  • ​​Nicolas: va amener des regards extérieurs et futurs contributeurs qui viennent avec des retours d'expériences et complément d'expertise sur "qu'est ce que c'est que le pair-à-pair ?". Liste des intervenants / participants: https://frama.link/OCL-DAISEE-presence
  • ​​Samira : chef proto!  Soulève des problèmes de calibration à relever / soulever (avec le Citizen Watt). Deux parties : capteur + software. Le code a été porté sur Raspberry Pi 3. Pas mal de petits soucis avec Ethereum (avec un problème sur l'opération de minage). Gros enjeu : sensibilité des capteurs (pour des micro-productions + des "petits" échanges).
​​ 
  • ​​Chantiers : 
  • ​​Quel affichage de la donnée ?  
  • ​​Quelle sensibilité des capteurs ?
  • ​​Comment on stocke la donnée ?
  • ​​Quel niveau de confidentialité ?
  • ​​Quelle algorithmie pour les flux ?
  • ​​Et si on arrêtait la blockchain ?!
  • ​​Hybridations BigChainDB, IPFS...
​​ 
  • ​​Re-design de DAISEE (11h-15h)
​​ 
  • ​​Alpha 
​​ 
​​ 
  • ​​Beta
​​ 
​​ 
​​ 
  • ​​Inventaire du matériel (11h-13h)
​​ 
  • ​​1 Open Energy Monitor (à base de Raspberry 2)
  • ​​5 capteurs CitizenWatt
  • ​​5 Raspberry Pi (en comptant celui du Proto204)
  • ​​3 PINE 64+ (2 appartenant à Louis, et 1 à Sam)
  • ​​3 Arduino Uno (dont 1 appartenant à Paul)
  • ​​2 chargeurs (panneaux) solaires : 
  • ​​Puissance: 1.5W max.
  • ​​Tension de sortie: 12V (± 20%)
  • ​​Tension nominal: 17.5 V
  • ​​Courant: max.125mA
  • ​​Température de travail: -15 ~ +45 °C
  • ​​Dimensions: 340 x 120 x 14 mm
  • ​​Poids: 0.45 kg
  • ​​Tension circuit ouvert (Voc): 21 V
  • ​​Tension de sortie: 13.5 V
  • ​​Courant de sortie: 350 mA
  • ​​Puissance de sortie: 5W (avec indication de charge)
  • ​​Couleur: gris
  • ​​Valeur IP: IP61
  • ​​Dimensions: 352 x 338 x 16 mm
  • ​​Température de travail: -15 to +45 °C
  • ​​Tension circuit ouvert (Voc): 21 V
  • ​​Tension de sortie max. (Vmp): 17.5 V
  • ​​Quelques fils, resistances et autres matériels électroniques
​​ 
  • ​​Meetup hardware (19h-21h)
​​ 
  • ​​Masterclass d'Emamnuel (19h-21h)
​​ 
​
​24 Janvier
​​ 
​​ 
  • ​​Présent.e.s : 
  • ​​Simon C.
  • ​​Sam R.
  • ​​Alizée M.
  • ​​Rieul T.
  • ​​Xavier C.
  • ​​Emmanuel L.
​​ 
  • ​​Objectifs : 
  • ​​Faire le point sur la connaissance dispo sur CW 
  • ​​Re-souder les composants des capteurs à dispo
  • ​​Tester l'installation des CitizenWatt et la sensibilité 
​​ 
  • ​​Inspection des capteurs (11h-13h)
​​ 
  • ​​Ressources : 
​​ 
  • ​​Diagnostic des oeuvres (14h-17h)
​​ 
​​ 
  • ​​Présent.e.s : 
  • ​​Alizée
  • ​​Xavier
  • ​​Rieul
  • ​​Nicolas
​​ 
  • ​​Diagnostic : 
​​ 
​​ 
​​ 
  • ​​Schématisation du grid
​​ 
​​ 
​​ 
  • ​​Masterclass de DAISEE (19h-21h)
​​ 
​​ 
​​ 
​
​25 janvier
​​ 
​​ 
  • ​​Présent.e.s : 
  • ​​Simon C.
  • ​​Sam R.
  • ​​Alizée M.
  • ​​Rieul T.
  • ​​Xavier C.
  • ​​Emmanuel L.
​​ 
  • ​​Objectifs : 
  • ​​Diagnostiquer les façons de traiter les erreurs 
  • ​​Clarifier l'expérience de consultation des flux
  • ​​Engager l'intégration des autres projets 
​​ 
  • ​​Skype avec Alexandre (10h-12h)
​​ 
  • ​​Rédaction des textes (10h-12h)
​​ 
  • ​​Réflexions sur la calibration (17h-18h)
​​ 
​​ 
  • ​​"Le compteur Linky est constitué d'un microcontrôleur principal STM32F103RF  de STMicroelectronics (caché par  l'afficheur sur la photo). Il s'agit d'un SoC embarqué basé sur un cœur Cortex-M3  32-bits à 72 MHz qui embarque 768 Ko  de mémoire flash et 96 Ko de SRAM. Il dispose également de convertisseurs A/D,  de nombreux ports I/O et de multiples interfaces de communication (I²C, UART, SPI, USB 2.0...). Il gère  aussi directement l'afficheur LCD. À proximité, on trouve une EEPROM flash de 2 Mo qui contient probablement les logs. Le fabricant a également ajouté un second microcontrôleur beaucoup moins puissant (un STM32F051R8 – ARM Cortex M0) épaulé par une autre EEPROM flash de 64 Ko. Il se charge de toute la partie "métrologie légale", qui exige un code certifié afin que les données recueillies ne puissent faire l'objet de contestations."
  • ​​ 
  • ​​"La mesure de  la tension (volt) et du courant (ampère) est réalisée par un composant tout intégré STPM10 de ST. Il calcule également les puissances actives (watts), réactives (VAR) et apparentes (VA) puis les transmet au microcontrôleur via une interface SPI. Le STPM10 mesure également la fréquence du secteur et contrôle la LED clignotante (en fonction de la puissance consommée) située en façade. Sa précision de 0,1 % reste dans les faits limitée par celle du shunt."
  • ​​ 
  • ​​"La mesure du courant en elle-même ne présente aucune particularité notable. Elle est réalisée par un shunt (qui génére une tension proportionnelle à un courant) connecté à un composant tout-en-un qui effectue les calculs de puissance nécessaires. L'ensemble offre une précision de classe 1 (1 %) après étalonnage. Tout dispositif qui mesure la consommation du secteur est basé sur le même schéma." 
  • ​​ 
​​ 
​​ 
​​ 
​​ 
​​L'objectif est de caractériser et calibrer les données de puissance mesurées par notre CitizenWatt. Nous voulons remonter au signal initial du capteur - brut - avant traitement et visualisation. 
​​ 
​​L'idée est de caractériser ce signal en mesurant la puissance de différents appareils électriques, ou en mesurant sur compteur avec différentes configurations de consommation, et d'observer les corrélations, en s'appuyant sur les valeurs théoriques des appareils ainsi que sur une mesure indépendante (Wattmètre sur prise d'Olivier) afin au final de déterminer une fonction de transfert. 
​​ 
  • ​​Pour ce faire il faut déjà réussir à sortir les données en comprenant leur échantillonnage et en faire un affichage simple. Ce qui n'est pas le cas aujourd'hui.
​​ 
​​Après appel à l'aide téléphonique de @Paul, celui-ci m'a confirmé la nécessité de repartir effectivement du code pointé par @Sam (version de Process.py de la branche Master dans GitHub), et de focaliser sur les 4 grandeurs mesurées : power, voltage, battery et timer, en court-circuitant la partie écriture dans la base de données. Il faut donc tâcher d'afficher les données, par simple print ou dans dans un fichier dans un premier temps.
​​ 
​​Si on est parasité par l'échantillonnage étrange des données (plusieurs données pour chaque timestamp), on peut faire un petit code de traitement a posteriori, avec typiquement un test sur la variation du signal et l'affichage des seules valeurs variantes, histoire d'éviter de s'encombrer de dizaines voire centaines de mesures redondantes. A voir dans un deuxième temps si ceci peut s'améliorer dès l'acquisition.
​​ 
​​L'objectif est d'identifier ainsi dès que possible si des variations cohérentes du signal de sortie s'observent sur des puissances de l'ordre de celles des œuvres sources. Si ce n'est pas le cas, le CitizenWatt sera à écarter pour une utilisation sur données réelles...
​​ 
​​ 
​​Questions:
  • ​​Pourquoi récupérer les données de consommation et de production électriques de chaque objet ? Afin de pouvoir suivre in-situ chaque objet et gérer les flux électriques entre objet. 
  • ​​Comment récupérer les données de consommation et de production électriques de chaque objet ? A déterminer pour chaque objet. Pour la production, il peut être envisagé de récupérer des prises connectées qui permettent de faire remonter de l'information. Pour la production il faut que le projet en question puisse nous envoyer les données de production en temps réel. 
  • ​​=>  La question de la récupération de donnée doit se faire avec les porteurs de projets. 
​​ 
​​Objectif : 
  • ​​Se focaliser sur 2 dispositifs de conso et de prof d'électricité et en faire les représentations. 
  • ​​Production =  Génératrice (Emmanuel L.) + si possible Power Plante | Consommation  = Aquaponie (Charlotte R. et Bruno V.) + si possible Plantoïd (il serait intéressant de monitorer la consommation d'énergie du systèmes permettant l'autonomie de la plante).
​​ 
​​Actions : 
  • ​​Définir avec Emmanuel comment récupérer la donnée de production de sa génératrice de manière fiable (Q. subsidiaire: récupère t-on la donnée de la génératrice ou la donnée de l'électricité utile qui serait celle de la batterie - nécessaire pour une utilisation stable / fiable ?).
  • ​​Définir avec Charlotte et Bruno comment récupérer la donnée de consommation de Aquaponie de manière fiable // Voir aussi avec @Guillaume (énergéticien...) d'Aquapioneers.
  • ​​SP, faire de même avec les 2 autres projets (voir avec Johann/Alizée et Isabelle/Xavier).
  • ​​Définir où stocker la donnée et comment on y accède pour gérer les flux.
  • ​​Trouver un ou plusieurs modes de représentation de la consommation et de la production (écran dans le rhombi, LED sur les face du rombi, DAISEECoin, argent physique...)
​​ 
  • ​​Besoins : 
  • ​​1 r(h)ombi (support matériel pour accueillir la tablette et représenter les flux) > OK
  • ​​1 Arduino / Raspberry / PINE 64 par projet fixé aux faces du r(h)ombi qui communique avec ledit projet, stocke - et potentiellement traite (transaction / flux) - la donnée > OK
  • ​​1 relais par Arduino / Raspberry / PINE 64  pour gérer les tensions sup. à 5V > À acheter
  • ​​1 dispositif permettant la captation de la donnée énergétique > À améliorer ou À acheter
  • ​​1 dispositif de représentation de la donnée (LED sur face du rombi ou autre) > A définir (si LED OK mais dispositif à monter et calibrer > nécessite du code arduino pour pilotage des LED en fonction de la donnée - il existe des codes qui peuvent être adaptés)
  • ​​1 tablette avec affichage déportée des productions et consommation sous forme graphique et, si possible, montrant les flux potentiels (échange sur "blockchain") > Tablette OK / Interface à développer ainsi que ce qui est affiché et comment l'afficher
​​ 
​
​26 janvier
​​ 
​​ 
  • ​​Présent.e.s : 
  • ​​Sam R.
  • ​​Alizée M.
  • ​​Rieul T.
  • ​​Nicolas L.
  • ​​David C.
  • ​​Kim C.
  • ​​Xavier C.
  • ​​Julien B.
  • ​​Alain B.
  • ​​Emmanuel L.
​​ 
  • ​​Objectifs
  • ​​Accueillir les contributeurs Kim, David, Alain, Julien
  • ​​Récupérer / tester la base Smart Plug Awox
  • ​​Avancer surl l'étalonnage du CitizenWatt 
  • ​​Amorcer le remixer l'interface graphique
  • ​​Faire le schéma du 'micro grid' de la biennale
​​ 
  • ​​Check-in @ la MYNE (9h30-12h30)
​​ 
  • ​​Contexte :  
  • ​​CitizenWatt pose un certain nombre de soucis 
  • ​​1er souci : fréquence d'envoi de la donnée => Peut être corrigé en collab avec David.
  • ​​2e souci : effet de seuil / sensibilité capteur => Peut être 'tempéré' avec le wattmètre
  • ​​Emmanuel va utliser ses propes capteurs. 
  • ​​Q: Comment on transfère les données ?
  • ​​Mini serveur Python (accessible)
  • ​​Pi capte ses données + afficheur
  • ​​Comment va-t-on stocker la donnée ?
  • ​​Comment on va plus loin que le kWh ?
​​ 
  • ​​Actions
  • ​​Alizée va s'occuper sur la représentation du 'microgrid'
  • ​​Rieul et David vont s'occuper de l'étalonnage du CW
  • ​​Emmanuel va fabriquer sur son banc de production.
  • ​​Sam et Kim vont s'occuper de l'affichage des données.
​​ 
  • ​​Masterclass sur les badges (11h30-12h30)
​​ 
  • ​​Serge en train de créer Open Cognition Alliance France / Europe. Création de BitofTrust.com
  • ​​Alternative à Change.org pour commencer (protocole de pétition, co-reconnaissance)
​​ 
  • ​​Comment partir des activités pour ne pas avoir besoin de faire un effort supplémentaire ?
  • ​​Processus de reconnaissance a du sens dans un collectif => création badge d'événement ?
  • ​​Ce badge peut porter des méta-données. Agit comme un marqueur collectif. 
  • ​​Open Badge Factory : "Application Badge" => les gens récupèrent le badge avec un lien. Chaque personne peut préciser ses contributions. Plusieurs options sont possibles.
​​ 
  • ​​Propsosition de créer `3 types de badges (voir l'exemple d'Open Recongition)
  • ​​Ambassadeur : pour le "marketing"
  • ​​Contributeur : pour la "core team"
  • ​​Occasionnel : pour les événements
​​ 
  • ​​Masterclass sur les données (13h-16h)
​​ 
  • ​​Pourquoi a-t-on besoin de (beaucoup) de données ?
  • ​​Pour que les statistiques soient pertinentes (agriculture de précision, phénotypage). [Voir]
  • ​​Pour les annoter et les utiliser en apprentissage (souvent les données d'un agriculteur seules ne suffiront pas). [Plant Identification In An Open World (LifeCLEF2016), CLEF 2016 working notes, Goëau H., Joly A., Bonnet P., LifeCLEF 2016 working notes, Evora, Portugal]
​​ 
  • ​​Pourquoi l'agriculteur diffuserait-il SES données ?
  • ​​Parce qu'il y est contraint par le constructeur ou le fournisseur de matériel (qui le fait payer).
  • ​​Pour respecter la législation. // Pour obtenir un label. // Parce qu'il est rétribué // ...
  • ​​Parce qu'il y gagne une expertise ou une réputation (cf. les performances du cycliste).
  • ​​Parce que la mise en place d'un serveur (PIMS) et d'un réseau Sigfox / Lora le décourage.
​​ 
  • ​​Pourquoi suivre la consommation énergétique ?
  • ​​Pour avoir une machine autonome => utilisation d'un WattsUpPro pour mesurer le courant.
​​ 
​​ 
  • ​​Comment gérer la répartition énergie / calcul / mémoire ?
  • ​​Capteurs équipés de Bluetooth Low Energy, processeurs dédiés la vision, gourmand en calculs, basse consommation
​​ 
  • ​​Quelles sont les données intéressantes (en agronomie) ?
  • ​​Données du robot :
  • ​​Images : 2D, 3D, infrarouges (multispectracles), thermiques,..
  • ​​Cartes : pour localiser les plantes dans le champ, pour connecter les images aux données environementales.
  • ​​Paramètres: pour caractériser la structure et la croissance des plantes.
  • ​​Données d'état du robot: consommation en énergie, trajectoires,...
  • ​​Préconisées par les agronomes: 
​​ 
  • ​​Masterclass sur les réseaux de chaleur (16h-17h)
​​ 
​​ 
  • ​​Nova7 a fait une étude des usages des réseaux de chaleur
  • ​​Une cinquantaine de personnes ont été interrogées.
  • ​​En bref, les habitants n’ont aujourd'hui aucune prise...
  • ​​Besoin de créer des espaces de partage de pratiques.
​​ 
  • ​​Il faut distinguer 2 types de centrale de production de chaleur
  • ​​Primaire : mutualisées par territoire et canalisation d'eau chaude
  • ​​Secondaire : en immeuble (connectés par échangeurs au pied)
  • ​​=> En l'occurence, ce sont - souvent - deux exploitants différents.
​​ 
​​ 
​​ 
​​ 
  • ​​Ces réseaux de chaleur permettent de gérer plus facilement le mix d’énergie.
  • ​​Connexion à des sources de production originales.
  • ​​On peut y brancher des usines et récupérer la chaleur
​​ 
  • ​​Trois grandes attentes ont été exprimées par les personnes intérogées 
  • ​​Confort : attente "clé"
  • ​​Économie : attente "clé"
  • ​​Fiabilité / Sécurité : attente "basique" (éviter les coupures)
  • ​​Ecologique : attente "bonus" (réduire l'impact écologique)
​​ 
  • ​​Deux axes pour caractériser les attitudes des gens en matière de chauffage
  • ​​Degré d'implication dans la gestion. 
  • ​​Préférence pour une démarche individuelle vs collective
​​ 
​​Les attentes "économiques" en fonction des profils
​​ 
​​Les attentes "confort" en fonction des profils
​​ 
​​Les attentes "écologiques" en fonction des profils
​​ 
​​Les attentes "sécurité / fiabilité" en fonction de profils
​​ 
  • ​​Quelques remarques conclusives pour cette enquête sur les réseaux :
  • ​​Une diversité d'attitudes. Il n'y a pas un bon système pour tous !
  • ​​"Coopératives de chauffage urbain" n’existent pas (ou peu)
  • ​​A Lyon, système centralisé (au niveau de la collectivité)
  • ​​Habitants prêts à déléguer la gestion avec de la transparence
  • ​​Ils développent des astuces pour "jouer" avec le système qui proposé. Ils exercent leurs capacités d'initiative et revendiquent des marges d'autonomie : 
  • ​​Bricolages pour "individualiser" des systèmes co., reprendre la main sur des systèmes centralisés ou déléguer (quand on essaie de leur donner des responsabilités)
  • ​​Besoin d’interaction collectives pour se réguler (cadre à créer...).
​​ 
  • ​​La société ForCity (basée à Lyon) modélise l'impact des infrastructures.
​​ 
​
​27 janvier
​​ 
​​ 
​​Présent.e.s
  • ​​Sam R.
  • ​​Alizée M.
  • ​​Rieul T.
  • ​​Xavier C.
  • ​​Nicolas L.
  • ​​David C.
  • ​​Kim C.
  • ​​Julien B.
  • ​​Alain B.
  • ​​Maxime P.
  • ​​Clément E.
  • ​​Stéphanie C.
  • ​​Simon C.
  • ​​Emmanuel L.
​​ 
  • ​​Masterclass "DAISEE 101" (10h-11h30)
​​ 
​​ 
  • ​​Enjeu : penser un cadre de gouvernance qui permettra de gérer l'énergie en bien commun.
​​ 
  • ​​Problèmes rencontrés / à résoudre :
  • ​​Sensibilité du CitizenWatt (dur de récupérer des données fiables).
  • ​​Besoin de collaborer les acteurs de l'infrastructure électrique
  • ​​Design de gouvernance multi-acteurs (sur la donnée énergétique)
  • ​​Besoin d'explorer d'autres secteurs technologiques (IA, IPFS...)
​​ 
  • ​​Masterclasss sur SunChain (11h30-12h15)
​​ 
​​ 
  • ​​Julien (Talium) a travaillé sur le 1er proto de Sunchain. Spin off de la société TECSOL (qui est partie intégrante du programme / de la commuauté GreenTech  lancé.e par le gouvernement).
​​ 
​​  
  • ​​Expérimentation avec 4 sites géographiques en PACA (5 compteurs, 2 avec prod. d'énergie).
  • ​​Compteur production / conso chez TS + Compteur Linky PERPI (en "mode historique" ) + Compteur de PME/PMI + Compteur de production (serre avec des panneaux solaires).
​​ 
  • ​​Scénario d'usage : une partie auto-conso / une partie mobilité (pour recharger une voiture)
  • ​​Charge and Share > Vendeur veut prouver que tu as acheté => Borne (délivre)
  • ​​SunChain > Consommatuer veut prouver qu'il a consommé => Plug (compteur)
  • ​​Blockchain First (société d'électronique) développe Ethan IoT (noeud Eth IoT) / OS
  • ​​Veut vendre des objets finaux. Ne sait pas encore s'il va vendre la platforme IoT.
  • ​​Ce qui est tres dur, c'est de designer des circuits robustes. Pas mal abandonnent.
​​ 
​​ 
  • ​​Principe : Talium se branche sur des compteurs existants (particuliers, PME/PMI) et utilise le TIC (Télé Info Client)  pour récupérer les trames (en ananalogique). Trame : bloc d'infos compteur.
  • ​​Il faut connecter au compteur un Module TIC (sur la sortie) + un Raspberry Pi (1 ou 2 ou 3).
  • ​​Linky est fabriqué par plusieurs constructeurs. Landis Gyr est l'un de ces constructeurs.
​​             
  • ​​Compteur : liste de prises de mesures (énergie en kWh + h). Plus calcul de redistribution. On rajoute une ligne (solaire + ENEDIS) sur la facture. Enjeux de sécurisation de clé privée. Besoin de sécuriser de le hardware (comme fait ledger) > 'Hardware Security Module'.
​​ 
  • ​​Le prototype a été fait avec un Rasbperry Pi 3. Pas de trading / rachat / revente. 
  • ​​Noeuds validateurs sur le cloud (peut se faire sur Pi). S'appuie sur l'infrastructure. 
  • ​​Enregistrement de la donnée dans un smart contract ( / se destine à être modifié).
​​ 
  • ​​Blockchains de type consortium Etape de validation en amont. Description de rôles.
  • ​​Monax est basée sur Docker. Docker = implémentation de Linux (Docker Swarm / Docker machines : permet d'initailiser des programmes dans un ensemble de machines).
  • ​​Monax vend des SDK de smart contract (Solidity) + Packages pour des POCs.
​​ 
  • ​​Masterclass sur Enercoop (12h15-13h)
​​ 
  • ​​Enjeu : créer un service citoyen de l'énergie. SCIP (société coopératives / collèges).
​​ 
  • ​​Modèle : contract direct avec des producteurs (ce qui fait une différence avec les autres fournisseurs d'énergie qui achètent sur le marché et font l'usage des certificat d'origine).
  • ​​Paient directement les fournisseurs. S'engagent à mettre dans le réseau une certaine quantité. La plupart des producteurs sont des petits producteurs. D'origine hydraulique. 
  • ​​L'argent s'échange directement entre producteurs et consommateurs (sans 'intermédiaire')
  • ​​Quelques sociétaires militants sont producteurs/consommateurs. C'est un collège ad hoc.
​​ 
  • ​​La coop doit permet de répondre aux besoins de 25k sociétaires (45k clients). Il arrive que la force de production ne répond pas aux besoins. Il y a 1 an, Enercoop a du aller sur le marché...
​​ 
  • ​​Enercoop est encore jeune sur les processus de facturation. Problèmes de base à soulever : éditer des factures "correctes" (ce que tu factures correspond à ce que tu consommes).
  • ​​Il y a un droit de passage sur le réseau. Chacun a son relevé sur le réseau...
  • ​​SolarCoin enregistre les certificats d'origine sur une blockchain. A tester !!
​​ 
  • ​​Dev. de Coopener (ENEDIS, Enercoop, client) : logiciel de facturation libre. V2 au printemps.
  • ​​Coopener doit être regardé comme un logiciel de gestion / relation client ("CRM").
​​ 
  • ​​Energie Partagée : production d'énergie via des coopératives. Acquisition à plusieurs.
  • ​​La plupart des producteurs revendent leur énergie à EDF (au regard des tarifs).
​​ 
  • ​​Prototypage de l'interface (10h-18h)
​​ 
​​Carnet de bord spécifique : https://github.com/SamR1/OpenCityLab-dataviz 
​​ 
  • ​​Remix du design du micro grid (10h-18h)
​​ 
​​ 
​​ 
  • ​​Visite de l'INSA Lyon (14h-16h)
​​ 
​​ 
  • ​​Présentation du rhombi (17-18h)
​​ 
​​ 
​​ 
​
​28 janvier
​​ 
​​ 
​​Présent.e.s
  • ​​Sam R.
  • ​​Rieul T.
  • ​​Xavier C.
  • ​​Nicolas L.
  • ​​Ju. Br
  • ​​Maxime P.
  • ​​Clément E.
  • ​​Simon M.
  • ​​David L.
​​ 
  • ​​Kick-of (10h30-11h30)
​​ 
  • ​​Ce qui est à creuser : le versioning dans l'énergie.
  • ​​Comment penser un micro grid en micro-services.
​​ 
  • ​​Docker a facilité le déploiement d'infrastructures.
  • ​​Logique d'images et de containers (hyper simple).
​​ 
  • ​​BC = mise à dispo d’un consensus distribué. 
  • ​​PoS : validateurs remplacent les mineurs
  • ​​On engage une preuve de possession
  • ​​"Proof of elapse time" > lié au processeur
​​ 
  • ​​Eth = A chaque adresse = somme.
  • ​​Etc  = On reconstruit les transactions.
​​ 
  • ​​Masterclass Microservice (11h30-12h30)
​​ 
​​ 
  • ​​Fil rouge : comment le Microservice pourrait être utile pour DAISEE > certains concepts. 
  • ​​Simon et David ont commencé le micro-service il y a un an. Ils se spécialisent dessus. 
​​ 
​​ 
  • ​​Beaucoup de doc mais peu d'outils. Ils développent un outil pour faciliter la migration. 
  • ​​Le microservice est scalable facilement, et est résilient par rapport au reste du système.
  • ​​Sur le plan organisationnel, chaque squad (équipe de dev) a la charge d'un seul service.
​​ 
  • ​​Microservice (SOA) = Service-Oriented Architecture qui se concentre sur la capacité a être déployé sans impacter son le reste du système.
  • ​​On ne déploit que les nouveaux services. Permet un déploiement continu (features).
​​ 
  • ​​Objectif de base : éviter les coutures (fonctions dépendantes les unes des autres).
  • ​​Les services ont leur propre base de données / système de stockage d'information.
​​ 
  • ​​Dans le schéma microservice, l'API gateway permet de faire l'orchestration services. Elle est le seul point d'echange entre les gateway et les microservices.
​​ 
  • ​​La scaliblité se définit en 3 axes (cf. performance) :  
  • ​​Partitionnement (ex. dico) : selon la requête il y a redirection vers tel ou tel service. 
  • ​​Séparation par fonctionnalité : nécessité la mise en place d'un service d'aiguillage. 
  • ​​Duplication d'instances : un service disponible sur un serveur web qui est dupliqué.  
​​ 
  • ​​"Tout est API "dans une architecture microservice. Service discovery = inventaire services.
​​ 
  • ​​Problème de "clients répartis" = pour une même application, on a différentes versions consommées par des clients connus et inconnus
​​ 
  • ​​On peut "préparer" une migration d'un monolithe vers une architecture micro-services. 
  • ​​La plus grosse "contrainte" est dans le métier (plutôt que dans la technique).
​​ 
  • ​​Gherkin = langage humain pour faire des tests de code (syntaxe de type User Story).
  • ​​Les clients ont la capacité de tester différentes versions en continu. 
​​ 
  • ​​Re-design de l'architecture de DAISEE (15h30-18h)
​​ 
​​ 
​​Définition de DAISEE d'un point de vue "métier". Explication du fonctionnement du secteur de l'énergie aujourd'hui et ce vers quoi on souhaiterait tendre. Temps de compréhension. 
​​ 
​​ 
​​ 
  • ​​Cartographie des consos (15h30-18h)
​​ 
​​Objectifs
  • ​​​@Xavier Coadic​ est engagé sur un effort de carto de la consommation énergétique (avec STRM).
  • ​​Il souhaite faire apparaître les données énergétiques de DAISEE alors de la biennale
​​ 
  • ​​Inspirations
​​ 
  • ​​Problèmes
  • ​​Difficulté à lancer Srtm2Osm sous Linux / Ubuntu sans trouver l'origine du problème.
  • ​​Dans la démarche holistique, est-ce faisable de s’appuyer et d'alimenter en données sur OSM pour faire de la data viz des différents test terrain de DAISEE ? (Biennale, Prats...)
​​ 
  • ​​Liens utiles

​
​4- Prototypage

​​ 
​
​06 Mars
​​ 
  • ​​wifi
​​Réseau wifi (pour les oeuvres) opérationnel
​​Oeuvres connectées : 
  • ​​DONE : Rhombi DAISEE (tablette)
  • ​​IN PROGRESS : Forest DAO (@ Isabelle)
  • ​​TO DO : Génératrice (Raspberry Pi A, Tablette), Rhombi DAISEE (Raspberry Pi 3)
​​Il reste à parametrer le point d'accès wifi Netgear.
​​ 
  • ​​Mesure de la consommation et de la production  
  • ​​Prises à monitorer ?
​​ 
​​ 
​​=> il faut 2 smartmeters (ou 3 si on veux monitorer le rombhi DAISEE)
​​ 
​​ 
  • ​​Documentation du hardware (enjeux de connectique et d’interfaçage) et la publication du code arduino (fork d'OEM) est faite ici Biennale2017 Monitoring DOZE
​​  
​
​28 Février
​​ 
  • ​​wifi
​​Un wifi (500Mb) sera disponible à partir du jeudi 2 ou vendredi 3.
​​Un réseau wifi spécifique pour les oeuvres sera configuré, avec les éléments suivants à fournir : 
​​- SSID,
​​- mot de passe,
​​- cryptage.
​​ 
​​En attendant, on peut mettre en place un réseau/point d'accès wifi afin de pouvoir configurer en amont la connexion des oeuvres au réseau. L'interet de cette solution est de pouvoir utiliser ce réseau en secours si perte d'accès du wifi principal (car même SSID/password).
​​=> mise à dispo d'un point d'accès Wifi Netgear WG602v3.
​​ 
​
​23 Février
​​ 
​​Quelques retours suite au passage à la Cité du Design :
  • ​​Wifi
​​Pour le moment, il n'y a pas de réseau wifi disponible dans l'espace où les oeuvres sont exposées (on capte  par intermittence et avec des signaux très faibles le wifi de l'OpenFactory)
​​Il n'y a pas de date quant à la mise en place de ce wifi.
  • ​​Cablage
​​Il faut limiter un maximum les fils et autres câbles apparents, par sécurité (et sur demande de la Cité du Design).
​​Cela va donc impacter le choix des capteurs et du positionnement des cartes.
  • ​​Oeuvres
​​Il faut voir si des oeuvres peuvent rester allumer continuellement sur le lieu de l'expo. Si ce n'est pas possible, des procédures de remises en route peuvent être à prévoir (ou de l'automatisation en cas de reboot des cartes).
​​ 
​​
​
​22 Février
​​ 
​​Présents
  • ​​Rieul
  • ​​Sam
  • ​​Emmanuel
​​ 
​​Objectifs
  • ​​Réglage de la génératrice
  • ​​Finalisation du rhombi
  • ​​Finalisation du "cartel"
  • ​​Finalisation de la data viz 
  • ​​Collecte des données
​​ 
​​Génératrice
​​ 
​​ 
​​Rhombi
​​ 
​​ 
​​Cartel
​​ 
​​ 
​​ 
​​Data Viz
​​ 
​​Dernire version publiée sur Github : https://github.com/SamR1/OpenCityLab-dataviz
  • ​​Mise à jour automatique de la heatmap (pour 2 items)
  • ​​Reste encore des choses à faire (intégrer plus d'oeuvres, améliorer les perfs, ajouter des textes....) et tester sur place avec le réseau mis à dispo.
  • ​​Il reste à intégrer les données d'OEM (marche qu'avec CW)
​​ 
​​Données 
​​ 
​​Dans l'idéal, ça serait top de faire point avec tous les porteurs de projets à la Cité du design. Ça permettrait de récupérer pas mas d'info et surtout de s'organiser (pas mal de choses à faire...).
  • ​​Cf. achat de capteurs si on veux suivre toutes les oeuvres
  • ​​la récup des données ne va pas etre une chose simple...
​​ 
​​Suggestion de ​@Nicolas Loubet​ : ne pas mettre la barre trop haut et privilégier 2 oeuvres : génératrice + module aqauponique. Resp. parce que nous sommes en contact direct avec les porteurs (mais aussi plus fondamentalement pour rapprocher les mondes de l'alimentaire et de l'énergie...).
  • ​​Dans le cas de l'aquaponie il s'agira donc de racheter un une prise connectée il me semble.
  • ​​Au niveau des smartplug, il va falloir remplacer l'Awox. Les recherches de ​@Sam R.​ orientent vers la TP Link HS110 (Wifi, cloud désactivable, un wrapper python existe)
​​ 
​
​20 Février
​​ 
​​Présent
  • ​​Emmanuel
  • ​​Sam
​​ 
​​Objectif
​​ 
  • ​​Mesure de puissance en courant continu en réutilisant le montage Open energy Monitor !
​​ 
​​ 
  • ​​Ici, c'est la consomation de la carte Raspberry Pr et de sa carte arduino (en mW).
​​ 
​​ 
​​Conversation : 
  • ​​@Sam : faudrait que je récupère un OEM pour l'intégration des données. (mais je peux ruser)
  • ​​@Emmanuel : je n'ai pas d'OEM de mon côté. Je dois encore plugguer le module radio sur ma carte. A moins qu'une connection wifi soit suffisante pour transmettre les données ?
  • ​​@Sam : c'est pour faire communiquer quoi ? Si l'app emoncms tourne, il suffit du wifi pour que le serveur soir accessible et donc expose l'api. Je récupère l'OEM, je vais faire des tests 
  • ​​@Emmanuel : c'est le cas. L'app emoncms tourne et je la vois les datas sur mon PC. Par contre, y a t'il moyen de brancher un écran sur la sortie HDMI du Rasp et d'exposer l'API en local ? il ne semble pas y avoir de sortie graphique sur la distribution emonpi (j'ai juste un terminal)
  • ​​@Sam : il est possible que l'OS installé soit allégé et donc que X server soit supprimé. Dans ce cas il faut le réinstaller. Là en branchant un écran tu as quoi ? Tu arrives sur le terminal ?
  • ​​@Emmanuel : emonpi2016​ (faute de frappe!)
  • ​​@Sam: si tu exécutes startx​, il se passe quoi ?
  • ​​@Emmanuel emonpi2016​, c'est que j'ai confondu les claviers en me connectant à la session... pour startx​, j'ai un command not found​, donc pas de X server... je vais installer ca !
  • ​​@Emmanuel : utilisation de l'image emonpi dispo sur le gihub. Le server X n'est pas installé. Avec sudo apt-get install raspberrypi-ui-mods , ca résoud le pb. Eventuellement, ajouter x11-xserver-utils. Et penser à passer en boot graphique dans raspi-config. Puis mettre un browser léger comme midori.
​​ 
​
​19 Février
​​ 
​​Présent
  • ​​Rieul
​​ 
​​Objectif
  • ​​Finaliser le démonstrateur (à finalité culturelle). Montre de façon imagée les flux d'énergie
​​ 
​​Livrables
​​ 
​​ 
​​ 
​
​11 Février
​​ 
​​Présent.e.s
  • ​​Emmanuel
  • ​​Samira
  • ​​Rieul
  • ​​Xavier
​​ 
​​Objectif(s)
  • ​​Discuter des délivrables attentus pour les oeuvres du tiers-lieu de la Biennale de Design.
​​ 
​​Livrables physiques
  • ​​R(h)ombi : R(h)ombi + tablette (tactile) ou écran qui affiche la consommation du module aquaponique et la production de la génératrice + quelque chose de visuel qui s'éclaire.
  • ​​Cartel : 3-5 Arduino représentant les projets + bandes de led qui relient les Arduino = > les led s'allument/s'éteignent en fonction des données de conso ou de prod envoyées à l'Arduino.
​​=> La plupart des projets on des arduinos déjà intégrés  : Plantoid + Scoby + PowerPlante (...)
​​ 
​​Visualisation de données
  • ​​OSM => pourrait être intéressant d'utiliser un OEM pour mesurer les consos de la pièce et de balancer la donnée sur une carte OSM avec les données de l'aquaponie et de la génératrice.
  • ​​Visualisation des transactions (et/ou des échanges d'énergie) entre aquaponie / génératrice.
​​ 
​​Exemple d'intégration d'une carte OSM avec la librairie Leaflet 
​​ 
  • ​​Visualisation de flux (avec un plugin de dataviz)  
​​ 
​​ 
​​  
​​ 
​​Récupération des données à partir d'OEM
  • ​​Faisable avec les API exposées par OEM (à l'instar de ce qui a été fait avec CitizenWatt)
​​ 
​​ 
​​Manu va mettre un afficheur en local de la prod. génératrice =>  Mesure puissance produite
​​ 
​​Liste de tâches
  • ​​Pour l'expo tiers-lieu et d'ici la semaine prochaine on se focalise sur la visualisation des données du module aquaponique et de la génératrice > DEADLINE : 20 Février
  • ​​Pour l'expo tiers-lieu et d'ici la semaine prochaine on se focalise sur la planche en entrée d'explication de DAISEE (avec dessin d'Alizée et Arduino-Led) > DEADLINE : 20 Février
  • ​​En préparation de la TAZ et en parallèle de la Biennale > DEADLINE : pour la TAZ
  • ​​Carte OSM avec données d'énergie (20 en affichage DAISEE > TOP mais pas d'obligation)
  • ​​Synoptique 2 (voir ce PAD) pour installation PV+Batterie+Vélo et le lien avec DAISEE
  • ​​Installation d'un/plusieurs OEM/CW pour récupération de données de consommation sur le site > Lien avec carto energie OSM et "place locale de marché énergétique" DAISEE
​​ 
​​Demande OEM
  • ​​Demande des modules OEM + Demande de modules plus simples qui sont uniquement les capteurs de courant avec module radio

​
​5- Données

​​ 
​​Cette section permet de synthétiser les données de conso / prod énergétiques du cybergarden.
  • ​​=> Ce document se destine à faire le récapitulatif des données (production / consommation).
​​ 
​
​R(h)ombi de David
​​ 
​​ 
​
​Ferme bactérienne (Scoby)
​​ 
​​Conso 
  • ​​Glacière : (module effet peltier 6 A courant 12 V) 70 W en fonctionnement. Il y a une temporisation de 160 000 millisecondes, si la température est en dessous de 25 degrés à l'intérieur, ou si je ne capte pas de signale depuis le capteur. 
  • ​​Ventilation par ventilos de PC pour brassage de l'air dans les bacs : (12V, 500 mA) 6W par cycle de 160 000 Millisecondes. 
  • ​​Arduino + écran : (5.0V : 11.67 mA) environ 60 W [AC].
  • ​​Bilan: 130 W en fonctionnement complet, 60 W en pause.
​​ 
​
​Module aquaponique
​​ 
​
​PowerPlante
​​ 
​​
​​ 
​​ 
​​ 
​​