Normalement la vidéo sur le node éditor devait sortir aujourd'hui, mais j'ai découvert un bug dans DearpyGUI 2.0 qui la rend temporairement obsolète. Le code que je présente fonctionne avec DPG 1.8 mais pas avec DPG 2.0 github.com/hoffstadt/DearPyGui/issues/2444 Je suis en train de faire un code qui contourne ce bug et peut-être vais-je devoir re-filmer une partie de la vidéo pour adresser ce bug 😅

N'importe quel convertisseur DC-DC 24v to 5v peut faire l'affaire. Voici quelques exemples de régulateurs qui devraient fonctionner : s.click.aliexpress.com/e/_DFuq6vb fr.aliexpress.com/item/1005007092498838.html s.click.aliexpress.com/e/_DlF67Zf Le dernier lien est le plus cher, mais aussi le plus performant/durable/fiable 😄

Non uniquement des graphes 2D 🥺 La liste se trouve ici dearpygui.readthedocs.io/en/latest/documentation/plots.html

Tout dépend de la fréquence de transmission de tes données. À mon travail, je pilote justement en serial des Arduino/ESP avec DPG et je suis aussi amené à récupérer des data depuis ces cartes. La render loop tourne à 60FPS donc si l'intervalle de transmission de ton Arduino est inférieur à 17ms tu n'as pas à t'inquiéter de devoir implémenter de multithreading pour ne pas skip de donnée. En pseudo code on aurait dans la main loop : while dpg.is_dearpygui_running(): if serial.available() : data = serial.read() plot(data) dpg.render_dearpygui_frame() Si par contre ton Arduino envoie en continu des données alors oui il faudra implémenter du multithreading, par défaut la lib (tout comme python) est single threaded et ne s'update que lors du render_frame(). Cela dit l'implémentation du multithreading est non seulement possible mais assez simple. Je l'utilise assez fréquemment pour réaliser des updates asynchrones de mon programme ou faire en sorte que des tâches lourdes en ressource ne ralentissement pas tout l'UI (dans une prochaine vidéo quand je montrerai un système de traitement d'image avec le Node-editor il y aura un exemple d'utilisation de multithreading évitant que l'update d'un image viewer ne ralentisse toute l'UI). En pratique, tu pourrais avoir un thread qui check en continu le serial et append les données dans une liste quand une nouvelle mesure arrive et à chaque render_loop update ton graphique avec cette liste de nouvelles données. Ton UI sera toujours à 60FPS mais ici tu seras en mesure d'ajouter une ou plusieurs nouvelles données dans ton graph. Cela dit si je ne dit pas de bêtises les chip serial ont généralement un buffer qui remplit nativement ce rôle. Mais en bref, tu ne dois t'inquiéter de ça véritablement QUE si tu remarques que ton projet a un bottleneck au niveau de la communication serial, sinon tu peux paisiblement l'ignorer 😄 Rem : quand je parle de mutithreading, je parle de la lib multithreading de python (celle qui en fait ne fait PAS de véritable multithreading à l'échelle du CPU, mais qui est adapté pour des situations IO intensive) et PAS de la lib multiprocessing qui elle spawn de nouveaux interpréteurs python et n'est pas très compatible avec DPG (ou alors, il faut implémenter une queue pour échanger les données entre process mais quasi certain que pour plot des mesure d'arduino tu ne seras pas ammené à devoir faire ça, c'est plutôt réservé aux situations où tu as un processing CPU intensive et que tu souhaites mieux exploiter la puissance de clacul de ton pc)

C'est un débat (légitime) aussi vieux que l'open-source😄. Il n'existe à mon sens pas de bonne réponse (unique) et cette question car elle est très situation-dépendante. Des modèles économiques viables pour des projets Open-source (tant software que hardware) il en existe des tas tout comme il existe tout autant de contre-exemples 😅(PysimpleGUI qui passe du jour au lendemain en modèle closed source "forçant" la transformation "d'utilisateurs" en "clients" est un excellent contre exemple). Il y a boite qui décident d'open sourcer leurs projets pour attirer une clientèle maker en gardant en interne une R&D traditionnelle parce que finalement cet aspect Open permet de créer de la confiance (même si un concurrent a les moyens techniques de copier ce que la boite d'origine a fait, ils ne le feront pas parce qu'ils ne bénéficieront pas de l'aura positive qui fait le succès des créateurs originels). On peut voir d'une certaine façon ça comme une forme de marketing. On retrouve ce modèle plus souvent dans le hardware cela dit. D'autres vivent du sponsoring, on crée un logiciel open source, d'autres grosses boitent l'utilisent à des fins commerciales (si la license le permet évidemment) et redonne une partie de leurs revenus au créateur. Bon...dans la vaste majorité des cas cette rétribution est ridiculement faible, voire inexistante... des multi-nationationales qui siphonnent des projets open-source et rendent des clopinettes ça arrive bien trop souvent, mais ça n'a jusqu'à présent pas encore suffit à détruire la motivation des contributeurs de l'open-source. Dans la même idée, d'autres projets à plus petite échellent vivent de donations d'utilisateurs qui reconnaissent la valeur du travail et ont les moyens et l'envie de payer ses créateurs. En pratique avec DearPyGUI le lead dev travaille (ou a travaillé) à la NASA et propose également du "tutoring" en programmation, mathématique ou en physique. On peut voir ses projets open-source comme une forme de portfolio/démo de ses compétences servant de vitrine pour éventuellement trouver des "clients" pour ses formations, ce qui aurait été impossible si ses logiciels n'étaient pas disponibles et largement partagés. Dans d'autres cas, il s'agit d'une démarche véritablement désintéressée, une personne a du temps, une passion et suffisamment d'argent perso que pour se permettre de partager son travail gratuitement. Ça peut paraitre illusoire et naïf, mais il existe vraiment des gens dont la seule motivation est le partage et pas le profit. C'est dans une certaine mesure ce que je fais. Je ne gagne pas d'argent avec youtube ni les tutos/codes que je partage. Ayant un salaire confortable en tant que chercheur, je n'ai pas besoin de valoriser financièrement mes projets secondaires, c'est un hobby et surtout un moyen de "rendre" à la communauté qui m'a permis d'apprendre ce que je sais et d'en être là où je suis. Il faut aussi garder en tête que l'Open-source a avant tout une vision collaborative. "Qu'est-ce que nous, en tant que codeurs, nous apportons ?" du travail gratuit en échange d'un outil gratuit. Bien que 99% des gens soient des utilisateurs (ce qui est mon cas) et non des contributeurs et qui donc "prennent" sans donner, il y a ce 1% de gens qui participent activement au développement et l'amélioration des projets-open source. Ou en tant qu'utilisateurs on peut a minima comme tu l'as dit apporter test et suggestions. Win-win on a un soft gratuit et en échange, on donne du beta testing gratuit. Node-RED dont je suis également un grand utilisateur, a un modèle économique vraiment intéressant. Proposer un outil gratuit et open-source et bénéficier ainsi des retours et suggestions de la communauté et garder le projet pérenne et économiquement viable en faisant une déclinaison B2B avec flow-fuse qui cible les entreprises et proposes d'autres services payants ici tels que de l'hébergement, probablement du consulting ainsi qu'une déclinaison plus "robuste" et "entreprise-grade" de leur logiciel. Et ces fonctionnalités payantes sont inutiles pour les utilisateurs uniques voulant faire de la domotique. Il y aurait moyen de continuer très longtemps 😅 Mais je pense qu'on peut aller au-delà du simple "si c'est gratuit, c'est toi le produit". Mais tu as raison, cependant l'Open-source PEUT être à long terme bancal et très dangereux, mais il ne l'EST pas systématiquement.

@@michelwatrelot7582 la suite demain 🤫

@@PhunkyBob la suite demain 🤫

Je ne suis pas familier avec le gestionnaire UV de chez Astral, je vais me renseigner 😄 Concernant la customisation de l'interface, ce que tu demandes est possible, mais n'est pas "natif" dans la lib. Dans une prochaine vidéo, je vais partager un système de "template" que j'ai mis au point et qui est capable d'automatiquement placer et resize des fenêtres (c'est ce qui me permet d'obtenir les différents layout que l'on voit dans la miniature). L'approche est assez simple : - Un fichier JSON qui décrit le nom, la position et la taille relative des fenêtres à afficher (en % de la taille du viewport) - Une fonction lit ce fichier json récupère les cordonnées et les convertis en valeurs absolues (en fonction de la résolution/taille du viewport) - Les fenêtre souhaitées sont créées, affichées et déplacées Cette approche permet d'avoir un layout reproductible sans devoir le programmer "en dur" dans le code Une autre solution pour rendre "aimantées" les fenêtres serait d'avoir une fonction callback qui se déclenche quand une fenêtre est déplacée. Cette fonction listerait toutes les fenêtres ouvertes et récupérerait leurs coordonnées et dimensions. Il ne resterait plus qu'à calculer la distance entre la fenêtre en cours de déplacement et toutes les autres fenêtres et les faire se coller si la distance est inférieure à un threshold. Tu trouveras aussi peut-être quelques inspirations ici : github.com/hoffstadt/DearPyGui/wiki/DEAR-PYGUI-SHOWCASE

Merci pour ta réponse je vais regarder les exemples que tu m'as donné

Effectivement 😅 C'est le premier lien mentionné dans "Lien utiles" de la description et WLED apparait à 24:55 dans la vidéo

Ça tombe bien c'est clairement ce que je dis dans la vidéo 😄 La domotique Tuya (et n'importe quel autre système wifi/cloud bases) sera toujours inférieur et plus contraignantes que du Zigbee ou autre système en local. Le but n'est justement PAS de convertir a Tuya ! Mais juste d'éviter l'E-waste si on possède déjà ce types d'appareils 😉

@@NeodymeTV Oui j'ai bien compris le propos de ta vidéo, t'inquiète. La petite séquence humoristique à la fin ne laisse aucune ambiguïté. Pour ce qui est de la domotique en wifi perso j'ai rien contre. Perso j'en ai pas mal, le reste est en Ethernet... Mais c'est des trucs "ouverts" (ESPeasy, ESPhome, Shelly) et surement pas des trucs qui dépendent d'un cloud ne serais-ce que ponctuellement pour leur intégration au système. Pour tout ces trucs Tuya c'est dommage qu'on ne puisse pas les flasher avec des firmware alternatif open-source, ça en ferrait des appareils intéressants.

Bonjour, Si l'objectif est uniquement de piloter les LED il sera peut etre plus simple d'utiliser WLED qui est nativement capable de créer une interface graphique de ce type (kzbin.info/www/bejne/eKncf6eto9F2obcsi=_NrVOS12eP7wKCjX) Sinon l'autre solution est de développer un dashboard NodeRED et d'envoyer les commandes d'intensité/couleur etc en MQTT à la bande LED kzbin.info/www/bejne/eWHLdISrn5Z1g5Ysi=o3fo7r0-3DFO9gqS

@@NeodymeTV Merci pour votre réponse ! Je regarde cela de plus près.

C'est normal 😅 c'est un extrait de live où on m'avait demandé d'expliquer vite fait ce qu'était NodeRed, j'ai du aller vite pour lister tout vu comme le logiciel est polyvalent

@@NeodymeTV En tous cas merci pour l'explication, ça fait deux jours que je suis en apnée dans Node-RED. Je m'éclate !

Oui si c'est une webcam il faut passer par windows pour récupérer et visualiser le flux vidéo. Par contre en faisant le même hack sur une action cam (genre les clones de GoPro qu'on trouve pour pas trop cher) possédant une sortie HDMI il est envisageable d'avoir une visualisation directe sans devoir passer par un ordinateur 😄

​@@NeodymeTV En plus pas besoin de pc juste un écran hdmi je vais plutôt essayer cette solution Merci