Sommaire
- Le contexte
- Le Client
- Prestations attendues
- Qualités attendues
- Connaissances attendues
- Conditions de la mission
- Comment répondre
- Liens utiles
Bonjour à toutes et tous,
L'association avec laquelle je travaille recherche un renfort en développement. Nous avons déjà fait appel à la communauté avec succès, donc on y revient ! J'espère avoir respecté les formes attendues, n'hésitez pas à me dire s'il y a des choses à améliorer ;)
MàJ Février 2023 : l'offre a été pourvue, merci pour vos relais.
--
Énergies citoyennes en Pays de Vilaine (EPV) cherche les services d’un.e développeur.se Python habitué.e du logiciel libre pour participer à un projet collaboratif traitant de la répartition locale de l’énergie. Durée de la mission 20 à 30 jours.
Le contexte
Le but de la mission est de coder le contrôle-commande d’un système de gestion de l’énergie pour le projet ELFE (Expérimentons Localement la Flexibilité Énergétique). Ce projet citoyen embarque 120 foyers et 40 acteurs économiques ou publics sur le pays de Redon-Pontchateau, et vise à optimiser la consommation d’énergie produite localement. Pour cela, des équipements domotiques sont installés chez des particuliers et des professionnels afin de commander à distance des machines, des radiateurs, des chargeurs de véhicule électrique…
Un groupe de 8 bénévoles a impulsé le projet ELFE en novembre 2021, pour une durée de 2,5 années, et l’équipe opérationnelle comporte 3 salariés et plusieurs partenaires aux compétences complémentaires. Le projet bénéficie du soutien et du financement de collectivités locales, ainsi que d’acteurs économiques locaux.
Le projet est dans une phase d’expérimentation, et la stratégie est d’utiliser un maximum de logiciels libres sur étagère (Proxmox, Debian, Zabbix, PosgreSQL, Mosquitto, OpenHasp). L’architecture système et logicielle ont déjà été définies. Plusieurs composants logiciels vont se connecter à une base de données de coordination pour notamment enregistrer des configurations et des consignes. A contrario, un seul composant logiciel va, en fonction du contenu de cette base, envoyer des ordres aux équipements domotiques par l’intermédiaire d’un broker MQTT : c’est l’objet de cette mission.
Le Client
Énergies citoyennes en Pays de Vilaine (EPV) est une association qui vise la réappropriation de l’énergie par les citoyens en les impliquant le plus possible dans la transition énergétique et sociétale. Active depuis 20 ans sur les pays de Redon et de Pontchateau, EPV a permis l’émergence des premiers parcs éoliens 100 % citoyens, et défend une démarche de sobriété collective. Elle compte 10 salarié-es et plus de 110 adhérent-es.
Prestations attendues
Après la découverte de l’architecture système et logicielle déjà définie, Vous devez réaliser les programmes suivants :
- Transcription des consignes du système de gestion de l’énergie : essentiellement de la transcription d’informations (volume estimé 5j)
- Commande des équipements domotiques : envoi d’ordres via protocole MQTT (vers les équipements domotiques), écoute de topics MQTT (pour les messages de stimulation envoyés par d’autres programmes ou interfaces), commande des équipements domotiques par la réalisation de machines à états (déjà définies) . (volume estimé 12j)
- Gestion des afficheurs utilisateur : participation aux spécifications techniques, commandes en MQTT, en lien avec le firmware OpenHASP sur un M5Stack CORE2. (volume estimé 7j)
- Monitoring des équipements domotiques : écoute de topics MQTT pour mettre à jour l’état des équipements domotiques en base de donnée (volume estimé 3j)
Les programmes devront être testés et opérationnels (implémentés dans l’infrastructure SI du projet) pour la fin de la mission. Les réalisations seront publiées sous licence EUPL, dans une logique de partage citoyen.
Qualités attendues
- Pouvoir travailler dans un mode collaboratif et collectif à distance, parfois en autonomie, parfois en groupe de travail.
- Écoute, respect, bienveillance et organisation sont de mise.
- Nous avons besoin d’une personne expérimentée dans le domaine du développement.
- Avoir la fibre du logiciel libre et idéalement avoir déjà contribué au logiciel libre en général.
Connaissances attendues
- Maîtrise de la programmation Python.
- Travailler sous environnement Linux.
- Maîtriser le concept de machine à états et idéalement avoir déjà eu une expérience d’implémentation.
- La connaissance de MQTT est un plus.
Conditions de la mission
- Début : Dès que possible
- Fin : Compte-tenu des phases de test/mise en production et des délais visés par le projet, les réalisations seront réparties en deux temps : une section minimale (estimée à 20j) pour fin Février, et une section complémentaire (5-7j) attendue fin Mars.
- Nombre de jours équivalent temps plein de prestations estimé : 20 à 27
- Lieu : le centre de l’équipe de projet est à Redon. La mission peut être réalisée à distance, possibilité de venir sur site ponctuellement suivant le besoin (bureau partagé possible),
- Conditions financières : à négocier. [fourchette estimée TJM : 300 à 400€HT]
Comment répondre
- Faire une proposition commerciale détaillée avec votre taux journalier.
- Délais : proposition commerciale à faire avant fin janvier.
- Un mail décrivant votre motivation et intérêt à travailler pour le projet est souhaité, avec des références de réalisations justifiant votre expérience.
- Proposition à envoyer par mail à elfe@enr-citoyennes.fr (commencer le sujet par [ELFE RECR DEV])
Liens utiles
- Site du projet : https://www.projet-elfe.fr/
- Site du recruteur : https://epv.enr-citoyennes.fr/
# Bravo pour l'initiative
Posté par TheBreton . Évalué à 3.
Juste pour mettre mon grain de sel, je crois deviner que du coup les capteurs/actionneurs communiquent via wifi et je me demandais si vous aviez regardez du coté de lorawan (via chirpstack) pour augmenter la porté de vos capteurs ?
Chez moi le wifi ne traverse pas tout l'appartement donc j'imagine qu'un hangar agricole ou un équipement dans une cave loin de la box doit difficilement pouvoir communiquer en wifi.
[^] # Re: Bravo pour l'initiative
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 17 janvier 2023 à 08:30.
Tout dépend. Le wifi a des portées de dingue en plein air et "de visu" (il assez est facile de faire des liaisons de plusieurs centaines de mètres voire de kilomètres), par contre a de grosses difficultés en intérieur (à cause des cloisons et des murs principalement).
En gros, on l'utilise généralement là où il est le plus mauvais :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Bravo pour l'initiative
Posté par aiolos . Évalué à 3.
En même temps, les protocoles radio qui marchent mieux en intérieur qu'en extérieur ne sont pas légions non plus ;)
[^] # Re: Bravo pour l'initiative
Posté par aiolos . Évalué à 2.
Pour LoraWan, faut regarder quand même les besoins en volume de données, parce que c'est pas le point fort de LoRa (et des LPWAN) en règle générale… Et, à ma connaissance MQTT over LoRa, c'est pas possible sans compression (genre SCHC ).
Et si vous décidiez d'aller dans cette direction, Rennes est plutôt bien pourvus en spécialistes de LoRa(Wan)…
[^] # Re: Bravo pour l'initiative
Posté par TheBreton . Évalué à 1.
Dans mon idée les uplink des devices sont renvoyés en mqtt par un "application server" qui est grosso modo un service consommant sur les données du lorawan server( chirpstack en l'occurence est open source). Le lien suivant détail le principe
https://www.chirpstack.io/project/architecture/
Effectivement lorawan c'est un protocole bas debit et basse énergie pour les devices qui fonctionne généralement sur une batterie pour plusieurs années.
En désactivant l'ADR et forcant les uplinks du device en SF7 ou SF8 on peut grosso modo envoyer une trame de 10 octets toutes les 2 minutes tout en respectant les regles de "time on air" de la bande ism.
[^] # Re: Bravo pour l'initiative
Posté par le_facteur . Évalué à 1.
DASH7 passe très bien les murs en local, avec une antenne utilisée par exemple pour le réseau Helium : https://fr.rs-online.com/web/p/support-de-montage-et-installation-d-antenne/2370146
[^] # Re: Bravo pour l'initiative
Posté par tout . Évalué à 1.
Et il passe partout si on l'utilise avec une porteuse LoRa.
[^] # Re: Bravo pour l'initiative
Posté par jaxom (site web personnel) . Évalué à 1.
Merci pour le commentaire ;) Bonne question : en fait, on travaille avec un pas de données assez court (30s à 5min) et on a supposé que la bande-passante publique LoRaWAN ne serait pas forcément suffisante (avec le ratio d'occupation du spectre, le nombre de datas et de devices, etc…).
Mais la raison principale du choix du WiFi est la simplicité et la réduction de l'investissement (on compte sur les box des participants), dans cette première version du projet qui est vraiment une "expérimentation" !
Si on trouve une valeur citoyenne et économique avec ce test, on révisera probablement certains choix techniques, selon la direction que le projet prendra. (Par ex. on pourrait se concentrer sur les (futures ?) interfaces des constructeurs d'électroménager, et laisser de côté la domotique…)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.