(17/01/2023, 13:07:38)GuillaumeB a écrit : Bonjour à tous,
J'anticipe l'achat de ma maison en réfléchissant à la structure de mon réseau knx.
Je pensais aussi à me lancer dans un projet de développement de mes capteurs et actionneurs.
J'ai vu qu'il existait des choses en Arduino, stm32 et esp.
Ayant pas mal de projet en parallèle, j'ai plusieurs questions avant de me lancer :
1) est-ce vraiment rentable ? Quand je vois le prix des interrupteurs knx je pense pouvoir faire des trucs sympa pour bien moins cher mais en vous lisant j'ai vu que ça pouvait aller à 50€ / pièce uniquement pour la carte électronique. Est-ce que vous confirmez ce prix ?
2) Je vois que plusieurs on utilisé l'esp32, est-ce pour ses fonctionnalités wifi ? quel en est l'intérêt couplé à du knx ?
3) quel est le niveau de maturité du code que l'on peut trouver ? Je bidouille un peu mais ne suis pas développeur pro. Ce projet serait l'occasion d'approfondir mes connaissances bas niveau mais j'ai l'impression que c'est assez chaud. Je sais que j'en suis capable ais il faudra du temps. Donc j'aimerai avoir une idée plus précise du niveau de difficulté. Sachant que j'aimerais partir d'un stm32 avec stknx par exemple et faire le design de la carte. Je ne suis pas buté sur cette archi mais ça me semble moins cher qu'un tpuart
Merci par avance !
Bonsoir Guillaume
Je vais essayer de répondre aux différentes questions que tu poses en exprimant mon avis personnel.
Pour la question 2 : Du fait KNX association ne donne que leur norme sur papier ( et encore une ancienne version), certaines personnes motivé (il faut lire le 90 Mo de pdf) ont "traduit" en librairie dans différents langages, à ce jeu le git de Thelsing a l'air de sortir du lot, or il l'a développé pour esp32; C'est pour cela, je pense que du moins sur le forum, qu'il est prédominant.
Pour la question 3 : Du fait donc que KNX association ne fourni plus d'api, le code que tu trouveras ne sera jamais officiel, il aura toujours des trou dans la raquette vis-à-vis l'évolution du standard, les ajouts divers (appareils, protocole de transmission, etc....). Par exemple, dans le standard accessible au public, il n'y a aucune référence à la gestion du KNX Secure.
Pour ce qui est programmation, j'ai vu la carte stm32 mais je ne l'ai pas retenu car je voulais (projet en veille actuellement, voir réponse à la question 1) une carte que je puisse mettre dans une DCL(plafonnier), cependant je pense que la carte stm32 est bien pour l'apprentissage des interactions bus-hardware, de mémoire la datasheet donne plusieurs exemples de configuration et de développement. Pour revenir aux langages de programmation, il vaut mieux être plutôt à l'aise avec le C, le C++ et le C#, après via la librairie ce n'est que de la programmation de microcontrôleur évoluer, donc pas forcement complexe.
Enfin pour la question 1 : Le coût de développement d'une carte m'a refroidi, avec la pénurie de composant, j'ai pu voir certain inconvénient. Les convertisseurs BUS<-> TTL sont en package CMS, cela à une incidence sur le reste de la fabrication de la carte. Après conseil d'un proche je suis simplement parti sur une carte avec le STKNX et les composants utile pour sont fonctionnement ainsi que que les pin de connexion pour la connexion pour la breadboard. Pour cela j'ai fait appelle à une société auquel j'ai fourni les gerber pour qu'il me fasse la production de 2 cartes d'essais. Total de l'histoire (fourniture composants, sérigraphie et implantation) j'en ai eu pour plus de 550€ soit plus de 275 € la carte. Donc même si tu arrives à optimisé l'ensemble je ne suis pas sur que tu puisse sortir une carte monté sous les 100 € (problème de d'économie sur le volume).
Maintenant, avoir envie de développer une carte spécifique peut être envisagé dans deux cas :
Un produit qui n'existe pas, mais vu ne nombre d'entreprise dans le monde qui créer des produits KNX, c'est pas évidant de ne pas trouver son bonheur. Mais cela existe (exemple) si tu créés un module de gestion de VR avec position exacte du VR sans passé par un temps calculé ou mesuré, tu auras quelques personnes intéressés.
Un produit dont le coup de développement te reviendra moins chère que celui qui existe, exemple la station ProKNX qui contient un raspberry (après il y a le soft qui est à développer et qui ajoute au prix final).
Après, j'ai du mal à entrevoir les avantages de réseau multi-protocole qui ajoute des risques de défaut non solvable dans une installation simple (je ne parle pas d'installation multi-site ou de structure importante comme des hôtels ou des hôpitaux).
Voilà j'espère que cela t'aidera dans ta réflexion.
Pour ma par sur arduino, je suis arrivé avec bien des difficultés, surement par manque de compétence, à rendre fonctionnel le Démo.knxprod, dans ETS, et ça n'a pas été une mince affaire.
Pour l'instant j'ai mis en pose, pour consacrer mon temps, à une interface HA, qui me convienne parfaitement en terme d'ergonomie.
(17/01/2023, 13:07:38)GuillaumeB a écrit : 1) est-ce vraiment rentable ? Quand je vois le prix des interrupteurs knx je pense pouvoir faire des trucs sympa pour bien moins cher mais en vous lisant j'ai vu que ça pouvait aller à 50€ / pièce uniquement pour la carte électronique. Est-ce que vous confirmez ce prix ?
Le prix c'est une chose, effectivement un inter KNX c'est plus cher qu'un inter classique, mais n'oublie pas qu'il y a aussi le rendu esthétique , le rendu final.
L'inter c'est vraiment le truc qui a mon avi ne peut pas etre réalisé (ou ne doit pas être réalisé) en Do It Yourself)
Si je me met de coté le prix, comment pourrais-tu faire pour avoir un produit fini ayant un beau rendu ?
Je parle d'avoir un inter avec un beau cadre, des bouton qualitatif, un afficheur eventuellement, des voyants ...
L'inter est parfois associé niveau design a des prises, a des sondes de T° ...
Un appareil devant etre logé dans un tableau quand a lui pourrait etre envisagé a mon avi, car la on peut trouver assez facilement des boitier vide OEM style MDT dans lesquels il suffirait de case l'electronique.
Une install KNX c'est une chose a ne pas prendre a la légère déjà avec du matériel du commerce cela demande du temps et des connaissance.
Ce lancer dans du DIY il faut déjà avoir de bonne connaissance en electronique et en programmation, mais vue le temps que ca va prendre en plus d'être passionné il faut a mon avi etre le seul occupant de la maison sinon cela risque très long pour les autres occupants.
KNX Partner Base / Avancé
Ma boite de MP est pleine, merci de créer un post si vous avez une question, cela profitera a tout le monde.
(17/01/2023, 13:07:38)GuillaumeB a écrit : 1) est-ce vraiment rentable ? Quand je vois le prix des interrupteurs knx je pense pouvoir faire des trucs sympa pour bien moins cher mais en vous lisant j'ai vu que ça pouvait aller à 50€ / pièce uniquement pour la carte électronique. Est-ce que vous confirmez ce prix ?
Le prix c'est une chose, effectivement un inter KNX c'est plus cher qu'un inter classique, mais n'oublie pas qu'il y a aussi le rendu esthétique , le rendu final.
L'inter c'est vraiment le truc qui a mon avi ne peut pas etre réalisé (ou ne doit pas être réalisé) en Do It Yourself)
Si je me met de coté le prix, comment pourrais-tu faire pour avoir un produit fini ayant un beau rendu ?
Je parle d'avoir un inter avec un beau cadre, des bouton qualitatif, un afficheur eventuellement, des voyants ...
L'inter est parfois associé niveau design a des prises, a des sondes de T° ...
Un appareil devant etre logé dans un tableau quand a lui pourrait etre envisagé a mon avi, car la on peut trouver assez facilement des boitier vide OEM style MDT dans lesquels il suffirait de case l'electronique.
Une install KNX c'est une chose a ne pas prendre a la légère déjà avec du matériel du commerce cela demande du temps et des connaissance.
Ce lancer dans du DIY il faut déjà avoir de bonne connaissance en electronique et en programmation, mais vue le temps que ca va prendre en plus d'être passionné il faut a mon avi etre le seul occupant de la maison sinon cela risque très long pour les autres occupants.
(18/01/2023, 09:29:56)filou59 a écrit : Une install KNX c'est une chose a ne pas prendre a la légère déjà avec du matériel du commerce cela demande du temps et des connaissance.
Ce lancer dans du DIY il faut déjà avoir de bonne connaissance en electronique et en programmation, mais vue le temps que ca va prendre en plus d'être passionné il faut a mon avi etre le seul occupant de la maison sinon cela risque très long pour les autres occupants.
Exactement et il faut penser à la maintenance à moyen et long terme car la maison sera revendue un jour ou l'autre. Dans mon cas c'est full KNX avec des schémas à jour et tous les repères sur les tableaux ainsi qu'une la sauvegarde du projet ETS sur une clé à proximité du tableau. Un intégrateur certifié KNX pourra s'y retrouver facilement.
Reste le problème de la supervision avec Home Assistant mais les fonctions logiques évoluées étant confiées au KNX à travers l'ABA/S1.2., dans le pire des cas on perd l'acces distant qui pourra être remis en place par un intégrateur avec un autre produit facilement.
Je parle en connaissance de cause car dans 1ère maiosn j'ai dû intervenir (après la vente) sur l'électronique de centralisation DIY des volets et dans la deuxième sur l'automate programmable Schneider qui commandait notamment un ascenseur (pour handicapé). Dans les deux cas les nouveaux propriétaires n'ont trouvé aucune entreprise ou artisan pour intervenir.
Contrairement à ce que l'on pourrait croire, une maison "technique" est souvent un moins pour la revente.
Je travail dans l'électronique, je ne suis ni dév software ni hardware, mais je vois un tas de projet au quotidien, je suis donc conscient des difficultés. Sur certains produit on utilise des boitiers standard du commerce, et oui, c'est bien pour des produits indus, mais dans la maison ce ne sera pas accepté par la patronne.
J'ai pratiqué un peu en amateur et également un peu en entreprise, mais ne me considère pas comme développeur, j'ai beaucoup à apprendre. J'ai déjà designé des cartes (4 couches) en amateur à base de cms et certains composant en QFN avec soudure au pistolet à air chaud et plaque chauffante. Il m'en reste en stock. Le coût de réalisation de la carte chez JLCPCB est dérisoire (carte seule), si on est pas pressé...
Pour ce projet, mon souhait était de designer une carte entièrement pour justement avoir quelque chose de propre et intégrable. Je vois ce projet dans son entièreté avec une carte éléc (design hw + dév soft), design méca, intégration dans l'univers KNX et dans Home Assistant.
Je bricole un peu et suis équipé d'une imprimante 3d (faite maison et fonctionnel) et CNC (en cours de fabrication), je bricole aussi le bois (menuiserie/ébénisterie). J'imaginais des inter avec un cadre en bois et plaque en verre, résine ou plexi. J'ai un Glastaster II sur mon bureau et je le prendrai un peu comme modèle. Bien sûr il ne faut pas que je sous-estime la différence de moyen d'intégration, tout est moulé sur cet inter.
Je suis entièrement en phase avec ta remarque filou, et l'intégration mécanique de l'inter à toujours fait parti du projet.
C'est pour cette raison que je questionnait sur le coût de l'électronique, si ma carte me coute 100€ uniquement pour l'élec, ce projet ne serait pas rentable et avec un résultat final aléatoire.
Par contre une carte dans les 20€, ça me laisse plus de latitude sur la mécanique et "l'échec" moins impactant.
J'ai vu certain de tes anciens post M2D, et j'ai vu que tu utilisais le STKNX. Ce composant étant bien moins cher que les TPUART de Siemens rendrait le projet moins onéreux. Je parlais d’utiliser des micros stm32 pour pouvoir étendre par la suite mon choix de micro en foncton du besoin. Mais vu les problématiques d'appro des puces st, je m'orienterai plutôt sur les RP2040 dans un premier temps. J'arriverai donc à quelque chose de similaire à ce que tu as fait.
En regardant de très loin :
Je pense développer une première carte copiant le design du RP2040 et ajoutant le STKNX et les quelques composants passifs nécessaire + éventuellement capteur de température, etc. Dans un premier temps je ne souderai que le stknx et passifs nécessaire et viendrait brancher un module RP2040 (externe) sur cette board pour m'assurer de son fonctionnement. Dans un second temps je remplacerai le module externe par les composant sur la carte.
J'ai regardé de très loin le STKNX mais la partie HW de cette carte ne me parait pas insurmontable, enfaite ça se résume en l'intégration du STKNX. Si M2D tu as des conseils, ou des documents à partager, je suis preneur.
J'abonde dans le sens de Filou59 et d'Ives, où pour créer un module il vraiment le vouloir, et c'est entre autre pour cela que j'ai développé ma réponse sur le côté technique.
Je souhaite cependant compléter deux petits détails :
Le premier est que le stm32 est un microcontrôleur et qu'il a besoin du convertisseurs bus<-> UART et si tu regarde bien la carte d'essai (le datasheet), une partie de la doc est dédié à la conversion du bus via le STKNX. KNX organisation a listé les convertisseurs à cette adresse : Liste convertisseur où tu trouveras peut être ton bonheur. Pour mon projet je suis partie sur le combo que tu as évoqué c'est à dire STKNX et rpi pico . Comme le pico peut être acheté pour 8€ tout "monté" il ne reste plus que la carte du STKNX à créer pour faire les essais. Après la programmation du pico peut être faite en C++ ou en Python via un raspberry.
Le second est que le coût du développement de la carte est pour mon cas du à l'implantation des composants. N'ayant pas l'outillage nécessaire pour implanter les composants sur la carte je suis obligé de faire appel à une société d'électronique. Mais comme tu as l'air d'avoir ce qu'il faut, quoique le STKNX à un package en VFQFN24, tu peux sortir une carte pour les moins de 75 € pièces, le prix de la carte plus celui des composants. Il faudra t'attendre à de la perte si tu fait les placements à la main sous binoculaire et cela augmentera de fait le coût de la carte fini.
Après sur le marché des composants, on revient à une normalisation, en autre le STKNX était en rupture mondial durant une année et maintenant, il est de nouveau disponible chez Farnel. Pour le RP2040 lui, il a toujours été disponible sur kubii, je pense là c'est dû à un mauvais ciblage clientèle et au conditionnement du produit; Et je pense qu'une fois le stock vendu ils ne feront pas de réassort.
Je joins, pour ceux que cela intéresse, deux images correspondant à la carte de développement pour le STKNX.
Pour ma part, j'en suis au stade d'avoir fait fonctionner le fichier knx-demo.ino sur ESP8266 ( avec les conseils donnés par Thensing sur les issues de son Github.
Le fichier correspondant .knxprod se télécharge dans ETS5 et le module est fonctionnel est fonctionnel.
Au moins ca prouve que le fichier knx-demo.ino peut fonctionner sur un ESP8266.
Il me restera à toucher à ce fichier knx-demo.ino, pour lui ajouter des fonctions, pour intégrer la programmation de ma station météo à base d'Arduino Méga, pour la faire fonctionner sur un ESP8266, et à remplacer la platine de test, par un beau circuit.
Pour en arriver déjà là, je peux remercier tous ceux qui, sur ce forum et sur le knx.de, m'ont aidé à ne pas perdre le moral.
Pour l'instant je consacre tout mon temps à mon interface avec HA, et quand on sort des chemins classiques, ce n'est pas si simple.
19/01/2023, 21:19:07 (Modification du message : 19/01/2023, 22:34:39 par GuillaumeB.)
C'est aussi pour ça que je suis venu vous consulter sur ce sujet. J'ai vu l'historique de vos échanges mais je n'arrivais pas à savoir si vous aviez réussi à obtenir quelque chose de fonctionnel. Avant de me lancer je voulais savoir si ça valait le coup.
J'ai ciblé le stknx car ~6€ pièce quand le tpuart est plus autour de 26€. Pour moi, soit je part sur un projet avec un seul device à la fin et donc le tpuart peut être la solution. Soit (ce qui est mon cas) je part sur une idée de dev de plusieurs devices (capteurs et actionneurs) avec un tronc commun et donc il faut partir sur le tpknx pour que ce soit rentable. Et l'effort à mettre sera plus récompensé.
Par contre le stknx est un transceiver et ne contient pas de stack uart. Il faut donc tout développer de zéro. Mais on peut vraiment faire ce qu'on veut sur le bus car on intervient très bas niveau.
Pour moi le gros challenge n'est pas le hardware mais vraiment le software avec ce stknx.
Et je n'ai trouvé aucun exemple de soft alors qu'on trouve un peu de schéma hard. Le site de St parle d'une stack (non libre) présente sur leur carte d'évaluation : TAPKO knx stack. Donc un gros boulot comparé à la lib de thelsing. Le boulot pourrait consister à développer la couche manquante pour dialoguer en uart et ajouter la lib de thelsing sur la couche du dessus.
M2D, as-tu un avis là-dessus ? Je vais aussi regarder le lisseur des transceiver que tu as partagé au cas où il y est une meilleure solution ou une piste vers une stack embarquée
Pour mon premier proto, j'ai changé d'avis , je vais simplement souder ou plugger un pico RP2040 sur ma carte mère qui contiendrait le stknx. Je n'ai pas fait l'exercice du coût de la BOM, mais pour moi on est plus prêt des 30€ que des 75€. Pico : 4€ + stknx : 7€ (Darnell + fdp 9€), passif : 5€, pcb : 5€ (les 5 pièces), connecteurs à ajouter. Même sur petit volume, le coût baissera si plus d'une carte car mutualisation des frais de port.
Bref, ce qui m'inquiète le plus c'est l'intégration software du STKNX car zéro exemple et donc énormément de boulot. Je sais que le rp2040 est suffisamment puissant donc oui micropython peut être intéressant, je n'ai jamais utilisé pour du bas niveau.
19/01/2023, 23:02:41 (Modification du message : 19/01/2023, 23:08:44 par M2D.)
Le RP2040 est dispo chez Kubii pour 1.20€ l'unité hors fdp(4€)
Après cela me parait light pour plus de 40 Passif dont quelques truc un cristal, un électrolyte et des diodes particulières dont je n'avais pas trouvé d'équivalent. Ma sélection de la BOM avait été fait pendant la pénurie avec, je m'en souvient des condos CMS à plus de 6€ pièces, c'est le moment où un rafraichissement de pages t'explosait ta BOM car plusieurs composant n'était plus disponible
De plus, si tu regardes lien que j'ai mis aujourd'hui, Tapko est aussi un convertisseur comme le NCN5130 ou le RP2040, mais les deux premiers ont une partie microcontrôleur avec la gestion des interruptions de transmission, répétitions des télégrammes, ect...... Le NC et je crois plus pour du filaire alors que Tapko est plus pensé pour du sans fil. Après Tapko souhaite ne pas "bradé" sont savoir et souhaite, je pense, plus être en relation avec des industriels et moins avec des bidouilleurs.
Il n' y a de d'exemple de soft voir la réponse à la question 2 d'avant hier. Il faut décompiler l'exemple de Thelsing pour voir un peu l'articulation software.
Je pense aussi, et c'est le conseil que l'on m'a donné, que tant que le proof of concept n'est pas passé (étape du breadboard), il vaut mieux avoir des blocs facilement remplaçables, imagine que le RP2040 crame pour X raison, il faudra le dessoudé pour en soudée un autre. Il pour moi plus sage de créer un carte spécifie pour le STKNX et connecter un PICO à l'aide de fil Dupont
Pour la partie software le STKNX n'est qu'un convertisseur d'un signal bus KNX en signal série, après il faut connaitre les listener pour générer des interruptions, de la manipulation de mots binaire reçu d'une liaison série et lire la norme pour connaitre l'ensemble des contraintes des télégrammes. Sinon tu utilises les librairies de Thelsing qui gère ces interactions avec le bus et il reste à interconnecté ton application avec la librairie.
Pour le travail rélisé par Thelsing ( ca donne "LeChant" avec google traduction sur le forum allemand ).
Pas mal de personnes se sont essayées à l'utiliser. Pour moi le partie qui as posée le plus de souci est l'adaptation de ses fichiers au processeur utilisé, car il faut toucher au code.
Sinon pour généerer le fichier knxprod, il y a ce github également "multiply.exe de mumpf" même forum, il faut juste comprendre comment l'utiliser. Il transforme un fichier XML, en fichier knxprod fonctionnel dans ETS. c'est au moment de l'import de ce fichier knxprod, que l'on se rend compte s'il est fonctionnel dans ETS. des fois ca ne s'importe pas , parfois ca s'importe mais ce n'est pas fonctionnel dans ETS et on a un bug, et à la fin, c'est le st Graal et ca fonctionne comme n'importe quel device dans ETS.
Quand tu voudras tester, je peux te passer par mail tout ce que j'ai pu réaliser.
Si je résume:
- Plusieurs personne utilise avec succès le code de Thelsing avec Arduino ou stm32 et un TPUART.
- Une archi avec STKNX demande plus de boulot car il faut développer la couche data link entre le STKNX et la couche Thelsing.
Cette couche data link n'est pas évidente car le protocole KNX demande des timings très précis, donc c'est un ensemble d'interruption et de timmer. Il faut également gérer les problèmes de collision lors de l'écriture sur le bus. L'idéal serait peut-être de rajouter un autre petit microcontrôleur pour gérer cette couche avant de gérer l'applicatif sur le micro principal.
-Condo4 n'a pas posté de nouvelle depuis le fin 2021, mais dans son dernier message il publiait le lien vers son github. Il bossait sur la couche de data link entre STKNX et la stack Therlsing qu'il aurait retranscrite en C (développé en C++ par Therlsing). Lors du dév, il s'est aperçu de l'existence du NCN5130, qui, comme le TPUART permet d'interfacer directement le bus KNX en UART et donc directement utilisable avec le code de Thelsing.
- Le site de KNX : https://www.knx.org/knx-en/for-manufactu...omponents/ liste les différents Hardware compatible KNX. Du peu que j'ai cherché, difficile de trouver des infos sur la plupart des références.
Pour ma part la solution TPUART pourrait être attirante car fonctionnelle, mais pour moi, pas viable financièrement sur plusieurs devices. Je ne l'ai pas vu à moins de 26€. Si quelqu'un l'a vu pas cher, je serai preneur.
La famille des NCN pourrait être intéressante car pas trop cher. Mais actuellement hors stock partout. A noter que M2D à relever des soucis de chauffe sur ce composant. Je l'avais écarté pour cette raison, mais il est possible de mettre en place des solutions pour évacuer le thermique.
Pour le moment je reste sur mon idée et je vais continuer de creuser le STKNX, surtout en découvrant le boulot de Condo4. Je vais étudier son code. M2D, de ton côté où en es-tu côté dév logiciel ? Es-tu parti sur le dév d'une couche bas niveau comme Condo4 pour interfacer avec la stack de Thelsing ?
Pour le HW, j'ai retrouvé le prix de mes anciennes cartes faites par JLCPCB. J'avais fait faire 2 designs, pour les 2 j'ai payé 1.67€ pour 5 PCB. Coût total 8.45€ pour 2*5 PCB dont 5.11€ de frais de ports. Je ne retrouve pas l'info précise, mais ayant pris un mode de livraison lent et pas cher, j'ai dû attendre 3 semaines pour recevoir les PCB.
Le STKNX est un VQFN, ok, c'est pas si simple à souder qu'un QFP, mais c'est largement jouable avec une station à air chaud. Peut-être jouable au fer car les pads remontent sur les côtés, mais le pad du dessous, je ne sais pas comment il serait géré. Pour exemple j'avais réussi à souder du BGA avec cette station air chaud.
Effectivement je n'ai pas regardé en détail les passifs autour du STKNX, il y a peut-être des trucs un peu spécifique.
J'ai quelques précision à apporter sur ta compréhension de ta lecture du sujet.
Citation :- Plusieurs personne utilise avec succès le code de Thelsing avec Arduino ou stm32 et un TPUART.
En effet la librairie de Thelsing est sert de base pour beaucoup de développement, cela entraine pour ceux qui veulent l'utiliser en filaire l'exploitation du TPUART car la "plateforme" STKNX n'est pas défini dans la librairie.
Citation :- Une archi avec STKNX demande plus de boulot car il faut développer la couche data link entre le STKNX et la couche Thelsing.
Cette couche data link n'est pas évidente car le protocole KNX demande des timings très précis, donc c'est un ensemble d'interruption et de timer. Il faut également gérer les problèmes de collision lors de l'écriture sur le bus. L'idéal serait peut-être de rajouter un autre petit microcontrôleur pour gérer cette couche avant de gérer l'applicatif sur le micro principal.
Oui et non, j'ai de nouveau survolé le code de Thelsing et ce qu'il a développé doit gérer les transmissions du bus, il faut cependant développer ce qu'il appel "plateforme" pour le STKNX. Je pense que Condo4 avait loupé cette info et il été reparti de zéro pour la transmission du bus et c'était bloqué sur la synchronisation des transmission sur le bus que cela ne être possible. Autre point que Condo4 n'a pas vu c'est que la vitesse du bus KNX est de 9600 baud et que Thelsing utilise une vitesse trois fois supérieur au bus, cela permet de mieux lire les bits transmis.
Citation :- Le site de KNX : https://www.knx.org/knx-en/for-manufactu...omponents/ liste les différents Hardware compatible KNX. Du peu que j'ai cherché, difficile de trouver des infos sur la plupart des références.
C'est le lien que je t'ai fourni, après chaque composant à ses spécificités ce qui permet de choisir en fonction des besoins du projet. Je ne t'apprend rien pour choisir un composant, il faut manger de la datasheet. Si c'est pour le prix, lorsque j'ai cherché c'est le STKNX qui été le plus intéressant.
Citation :M2D, de ton côté où en es-tu côté dév logiciel ?
Comme je l'ai dis dans un précédant message, le projet a été mis en veille, par manque de temps actuellement. Donc pas encore de dev logiciel. Regarde le code qui sont dans les ".ino" des exemple de la librairie, tu verras les prototypes de structure minimal pour les microcontrôleurs.
21/01/2023, 22:02:18 (Modification du message : 21/01/2023, 22:03:45 par condo4.)
Désolé de te décevoir mais je n'ai loupé aucune info, visiblement c'est plutôt toi qui ne comprend pas le protocole KNX
Je n'ai pas juste parcouru le code de thelsing, je l'ai dabord porté sur stm32, puis totalement reecrit en C, re structuré...
Bref, je l'ai lu en long en large et en travers.
Pour la vitesse de baudrate, ce que tu n'a pas l'air de comprendre, c'est ce qu'est un TPUART ou un NCN, et ce que n'est pas le STKNX
TPUART et NCN sont des composant actif, contenant buffer et logique complexe. D'ailleurs, il demande une clock "rapide" pour fonctionner.
Comme tu communique avec un buffer interne par spi ou uart, tu es découplé du 9600bds du bus. C'est pourquoi le MCU et le TPUART communique plus vite.
La gestion des ACK, des timing de bit et des retransmission est géré par le composant
Maintenant le composant STKNX est juste une interface analog/numerique.
Pas de buffer, pas de logique.... au MCU de tout faire.
La communication avec le mcu n'est pas un UART, c'est 2 GPIO qui pilote l'etage de sortie analog.
Donc, tu ne pourra JAMAIS le piloter juste avec la sortie UART du MCU.
Toute la complexité du protocole est a géré par le MCU.
Rien que pour transmettre 1 bit, c'est deja compliqué (bit de 104ns découpé en 2 temps, 20ns a 1, puis 84ns a zero.)
Et je ne parle même pas de la gestion de collision.
Bref, Thesling NE POURRA JAMAIS fonctionner sur STKNX.
Une simple sortie UART ne pourra JAMAIS piloter un STKNX.
Pour travailler sur STKNX, 1 seul solution, du code basé sur des timer hardware du MCU et des IRQ.
Et debug a l'oscillo indispensable.
Content de te revoir sur le sujet, je m'excuse alors d'avoir mal interpréter ton approche de communication.
Mais je reste persuadé que via le RP2040, on peut prendre en charge directement le traitement UART transmis par le STKNX.
Je pense que Guillaume et nous, sommes curieux de savoir si tu as réussi à développer ton projet jusqu'à son terme.
Voici la réponce que j'a donné hier a Guillaume en MP, mais qui peu potentiellement vous interesser plus largement...
Vaste sujet, je suis toujours en train d'avancer... plusieurs piste en parallèle.
Niveau Matériel d'abord.
J'ai commencé, simple, il y a plusieurs années.
1)
Nucleo-STM32L432KC couplé a un TP-UART récupéré dans le BCU d'un interupteur siemmens, le fameu 5WG1117-2AB12.
J'ai reussi a y adapter la stack de Thelsing.
ça fonctionne pas trop mal, la carte "plante" quand même un fois tout les 2 ou 3 mois, j'ignore pourquoi... ça sent la fuite mémoire je pense
2) Je suis passé a l'étape suivante, j'ai fait ma propre carte (PCB 2 couches, sur seeedstudio) avec un STM32L432KC et, comme le TPUART est introuvable sur mouser ou digikey; j'ai pris le STKNX.
Pour faire la carte, j'avais profité d'une super promo de seeedstudio: le cablage PCBA gratuit, en gros, j'ai payé le PCB et les composant, et c'est tout...
Comme c'était limité a 20 references de composant, j'ai quand même eux quelque composant a souder moi meme; j'ai donc fait 5 prototypes.
Pour le logiciel, c'est plus compliqué, le STKNX n'a rien a voir avec un TPUART... donc, il faut tout gérer très bas niveau...
Mais J'ai reussi a faire marcher les couche basse, avec un code assez compliqué (pas forcement long, juste très technique) basé uniquement sur des handler d'IT et des timer hardware...
Mais ça marche, j’émets et reçois des trames... avec ETS, je programme l'adresse... mais pas plus, j'ai pas fini de coder le dernier layer application, il me recte la gestion des connexions utilié par ETS...
En bas niveau, je n'ai pas encore géré la collision lorsque les communicants débutent pile en même temps...
Pour debuger ma stack, pour comparer avec le fonctionnement de Thelsing, j'ai aussi commencer a transformer totalement sa stack en C pure.
Tout en verifiant sur mon proto 1), qu'elle continue de fonctionner...
J'ai presque fini cette étape, mais, sur la fin de la transition (je fais de multiple commit etape par etape sur un projet git), je fini par avoir un plantage lors de la programmation via ETS... malheureusement, sur des commit qui ne le justifie pas... je soupçonne du coup un problème d'écrasement de stack/heap.... mais comme le domaine microcontrôleur ne m'est pas très familier, je ram un peu la dessus (je suis architecte system Linux embarqué, donc, Yocto, drivers kernel OK, mais microcontrôleur, je suis un peu débutant...
3) En paralléle, j'ai découvert donc le NCN5130 qui me semble parfait... un TPUART en mieux, et accessible sur internet plus facilement
J'ai donc repris mon hardware, pour remplacer le STKNX par ce composant; mais la, je suis tombé sur 2 problème majeur:
- Comment souder la carte, car la promo seeedstudio n'existe plus, et ça coute mega cher (1er devis, a 700€ pour 10 cartes !!) et ça, sans garantie qu'elle marche, puisque c'est un proto !
- Pénurie de composant.. STM32 introuvable, NCN5130 introuvable...
bref, depuis presque 1 an, le projet était un peu a l’arrêt.... jusqu'a une nouvelle idée a la con... faire la carte moi même... mais bon, comment souder des QFN64...
Problème que j'ai enfin résolu fin 2022; j'ai fais (du moins acheter et améliorer) un fours (https://github.com/UnifiedEngineering/T-...provements)
J'ai donc, en plusieurs mois réssi a commander tout les composants nécessaire sauf 2... le CPU et le NCN...
Pour le NCN, finalement, j'ai trouver la solution parfaite... j'ai fait une demande d’échantillon (on a le droit a 1 demande tout les 3 mois), et reçu gratuitement 5 exemplaire...
Pour le CPU, le STM32L432KC est en rupture totale... du coup, changement, je pars sur le STM32G491... consomme a peine plus, mais bien plus gros et puissant que le L432...
Du coup, commande mouser, re-design complet du PCB pour la 4eme fois... circuit, routage, commande sur seeedstudio avec un masque...
Et me voila avec tout ;-)
je tente une premiere soudure au four... mais je n'ai pas été assez precis sur la dépose de patte, la carte est raté...
2eme tentative.... réussi !!!
Du coup, c'est récent...et je manque un peu de temps... mais j'ai déjà démarrer le CPU, la led clignote, la programmation du CPU marche...
ensuite, je vait faire marcher la console serie pour debug...
puis celle pour le NCN...
puis remettre ma stack de ma carte V1; et enlever le code des timer pour gérer plus simplement avec le NCN...
Bref, il me reste beaucoup de chemin, en faite, comme j'ai pas beaucoup de temps a y consacrer, j'avance petit a petit...
Et comme dans mon boulot, je suis pris sur un énorme projet... il ne me reste pas beaucoup de temps dispo...
Mais j'y crois fort, j'ai jamais autant avancé...
Si vous êtes interessé, je peux tout mettre en ligne...
Les schema sont fait sous kicad, les source peuvent etre poser sous github, je peux aussi faire quelque photos...
je penser faire un blog comme j'avais fait pour mes spots lorsque l'état sera un peu stabilisé...
Et puis parallèlement a tout ça, je développe aussi une solution sur ma rockpro64 (équivalent raspbery), complète en Qt, basé sur KNXD... et d'une appli mobile.
ça marche déjà depuis 3 ans, je pilote toute la maison avec mon tel, lumiere volet, vmc, poele... bref, un truc genre homeassistant, mais utilisant 10 fois moins de ressources pour faire le même résultat...
Mais tout est lier, car j'ai besoin de ma carte pour automatiser les éléments suivant de ma maison...
Donc je dois tout avancer en parallèle... doucement mais sûrement...
Bonjour,
de mon coté, j'ai continué à intégrer des petits contrôleurs XIAO dans les boites de 5WG1117-2AB12 comme je l'ai présenté avant dans ce fil de discussion.
Il est possible de choisir le CPU que l'on veut. L'ajustement est juste l'adaptation série 5v <-->3,3v en CMS.
Pour l'instant je n'ai pas fait de test dans le temps car je travaille encore sur les fonctions embraquées.
Coté prix, il y a la base 5WG1117-2AB12, la carte XIAO (5 à 7 euros) et le 3 à 5 € pour la conversion de tension de la liaison série plus le PCB, je suis à moins de 40 € pour un participant.
Tous ces participants sont des fonctions annexes (relevé de température, controle Infra Rouge, ....) pas de fonctions principales
Je suis dispo pour partager les codes et les fichiers KNXPROD pour aider.
Bonjour à tous.
pour ceux qui galère un peu pour faire leurs propres fichiers knxprod, il y a une nouvelle application liée au projet OpenKNX.
La prochaine version sortira avec le support du français. N'hésitez pas à contribuer, le développeur est preneur et réactif. https://github.com/OpenKNX/Kaenx-Creator
Bonne construction et bon week-end.
(22/04/2023, 08:56:37)adm1024 a écrit : Bonjour à tous.
pour ceux qui galère un peu pour faire leurs propres fichiers knxprod, il y a une nouvelle application liée au projet OpenKNX.
La prochaine version sortira avec le support du français. N'hésitez pas à contribuer, le développeur est preneur et réactif. https://github.com/OpenKNX/Kaenx-Creator
Bonne construction et bon week-end.
Bonne nouvelle, dommage que c'est encore lié a .Net, et donc, ne fonctionne que sous windows :-c
De mon coté, voici un peu des nouvelles de ma carte.
Ma carte a base de STM32G491 et NCN5130 fonctionne très bien, j'ai pu tester toute la partie électronique, et tout est bon.
Niveau Soft, J'avance bien... mais comme ma stack n'est pas encore fini, j'ai voulu prendre un raccourcis et faire marcher la stack Thelsing. Je l'avais abandonné pour plein de raisons, mais la principal dont je me rappelais, c'est qu'avec le STKNX de ma carte précédente, c'était impossible de l'utiliser...
Mais comme je suis revenu au NCN5130, je me suis dis pourquoi pas... si ça peux me permettre d'avoir un résultat plus rapidement...
Au final, j'ai perdu pas mal de temps, pour finir par me rappeler les autres gros défaut qui m'on fait abandonner cette stack...
Déjà, bien que pas trop problématique pour le moment et avec ce nouveau MCU, la taille... sûrement a cause du runtime c++ en partie, la stack est 4 a 5 fois plus grosse que ma version en C... et demande beaucoup de RAM aussi...
Mais surtout, elle utilise des classes en cascade avec des constructeurs, qui sont instanciées en objet global (KnxFacade par exemple). C'est une très grosse erreur de conception, car dans ce cas, tout les constructeurs sont exécuté avant même d'entrer dans la fonction "main", et donc, avant toute chance d'initialiser le MCU avant...
Enfin, dernier gros problème, elle utilise des malloc dans tout les sens... ce qui rend l'usage et le debug compliqué, et fait de gros risque d'instabilité au runtime.
Bref, après avoir reperdu du temps pour la mettre sur ma carte, je suis donc revenu sur ma stack plus simple...
Et j'avance a grand pas !!!
Je suis maintenant capable de programmer l'adresse depuis ETS, et c'est pas rien, par ce que ça valide une grosse partie de la stack, en effet, après avoir configuré l'adresse (ça j'y arrivais déjà avec la carte STKNX), ETS fait des échanges avec la carte en utilisant le mode connecté du protocole, et comme j'avais pas encore géré ce mode, avec mon ancienne carte, l'adresse se programmait, mais ETS finissait en erreur.
Aujourd'hui, l'adresse se programme et ETS est content...
Je vais maintenant passer a la déclaration des paramètres et des adresse de groupes... puis leur programmation depuis ETS.
Il reste un peu du boulot, mais du coup, le bas niveau et plutôt bien debugguer, donc, ça devrait avancer plus vite.
Si j'arrive a y consacré un peu de temps, je devrais atteindre le même niveau que la stack Thelsing, mais avec quelque chose de plus portable, plus efficace, bien plus petit, et surtout, plus maintenable, et compréhensible en terme d'allocation. Avec un peu de chance, cet été j'aurais fini...
Ensuite, je pensais utiliser cette même stack pour réaliser des outils en ligne de commandes pour programmer les composant, et pouvoir se passer d'ETS sous linux.
Je suis avec beaucoup d'intérêt vos développements. Mais je dois me concentrer sur mon changement d'interface vers HA.
Je n'ai pas encore pris le temps de tester Kaenx-Creator. Mes essais avec Thelsing, m'ont convécu de l'intérêt de créer un .knxprod.
dont l'importation dans ETS permet à un novice comme moi, de valider le code et la plateforme utilisée. C'est vrai que l'adaptation du code de Thelsing à Arduino par exemple n'a pas été vraiment simple. J'aimerai bien pour passer ma station météo a base d'Arduino Méga et de One-Wire vers un ESP32 par exemple.
je voudrait commencer par une petite application type blink avec Kaenx-Creator ppour un ESP32.
Quelqu'un a-t-il déjà fait cela???
J'avance toujours sur mon projet, et je commence d'avoir quelque chose qui semble prendre la bonne direction...
Sur la stack, il me reste toujours a finaliser la couche transport et application pour gérer une programmation depuis ETS (avec les même knxprod qu'avec Thelsing).
Mais j'ai espoir d'un résultat rapidement.
Je commence donc de mettre mon code au propre, j'ai choisie la licence MPL, et je commence de mettre le projet proprement sur Github.
Le projet est composer de plusieurs repository, le hardware, la stack proprement parlé, le couplage avec un STM32, en utilisant Stm32CubeMX, et enfin, un exemple de couplage complet.
Pour le moment, j'ai mis la stack sur github https://github.com/condo4/LightKnxStack
Elle gère le NCN5130, mais je l'adapterais aussi au TPUART, et enfin, je reviendrais surement aussi sur le STKNX puisque j'étais pas loin d'un résultat (il me manquait que la gestion des collisions).
Bonjour,
Déja merci pour avoir partagé tous vos tests et expériences c'est génial.
J'ai passé des heures à lire tout se que j'ai trouvé sur le sujet mais entre se qui était valable en 2018 et les composants qui ne sont plus trouvable ou hors de prix aujourd’hui c'est difficile de s'y retrouver.
Si j'ai bien compris, aujoud'hui en 2023 la meilleur combinaison est un STM32G071KBT6 (surement d'autre je ne sais pas mais celui la j'en ai trouvé)
ou un RP2040 (rpi pico) (de préférance pour moi vue que j'en ai déja )
ou un ESP32 (n'importe lequel ?) (ESP32-C3-Zero c'est bon ?)
-->(Pour le programe et la géstion des entrées sortie)
Mais il faut obligatoirement en plus un : STKNXTR (plus compliqué mais je n'ai pas compris pourquoi !)
ou NCN5130 (j'ai retenu que ça : "un TPUART en mieux, et accessible sur internet plus facilement" )
-->(pour la transforation de KNX en uart que le STM32/RP2040/ESP32 sais comprendre)
J'ai cependant trois questions :
Les STKNXTR et NCN5130 semble être très compliqué à souder soi même, ça peux se souder quand même à la maison pour une version de dev/test ? (avec une station à aire chaud ou juste un petit faire a souder) ? Ou c'est plutôt pas possible du tout il faut obligatoirement un four ?
Pour les STKNXTR et NCN5130 ça se passe comment pour les programmer ? Il faut faire un branchement particulié pour le relier en usb ?
Il faut une carte de programation dédié ou un adaptateur ? Ou ça ne se programme pas c'est que le RP2040/ESP32 /STM32 qu'on programme ?
Enfin, après avoir lu tous ça je compte partir sur une carte de prototype à base de RP2040 + NCN5130 et utiliser se qu'a fait
thelsing et/ou condo4 car je n'ai pas bien compris comment ça marche, en regardant les Git j'ai l'impression que thelsing a fait le code pour le ESP32/RP2040 et
condo4 pour le STKNX/NCN5130 j'ai bon ?
Je verrais plus tard comment faire une vrais carte (prod) mais quelqu’un peux me donner un shema de liaison entre mes deux fils KNX et le NCN5130 puis entre le NCN5130 et le RP2040 ?
![[Image: 5cxybp.jpg]](https://i.goopics.net/5cxybp.jpg)
![[Image: 56ujf8.jpg]](https://i.goopics.net/56ujf8.jpg)