Bonjour @grocrabe
Merci pour cette info.
Je vais attendre
Bonne journée
Bonjour à tous,
J’ai parcouru tout le fil de discussion mais je ne pense pas avoir vu quoi que ce soit à propos de la fonction thermostat de la future IPX800 v5.
Est-ce que quelqu’un sait si le thermostat pourra gérer autre chose que le mode hystérésis?
Merci!
Bonjour Mages,
pas d’infos pour l’instant.
Vous pensez à quoi?
Bonne journée
Je n’ai pas fouillé le sujet à fond mais je pensais à un thermostat de type PID. J’aimerais utiliser le X-THL pour faire la régulation en fonction de la température de la pièce, le taux d’humidité et la température extérieure. Tout ça sans fil pilote directement depuis l’IPX et ses relais.
Bonne journée
Bonjour,
Le PID est prévu, je ne sais pas si il sera présent dès la sortie de la v5 en Septembre mais c’est bien prévu…
1 « J'aime »
Bonjour,
C’est une excellente nouvelle! Au pire je ferai un hiver avec un thermostat en hystérésis. Ca me permettra de voir la différence entre les deux modes.
Bravo à vous pour toutes ces nouveautés. 
1 « J'aime »
Bonjour,
Est que la fonction front montant/descendant est prévue ?
Bonne journée
Bonsoir tous30,
NB : comme toujours les infos que l’on donne sont celles connues au moment de la réponse mais qui sont sujettes à changement d’ici à la sortie officielle de l’IPXV5.
Donc, à ce jour, pas de front descendant sur l’IPX ou les X-24D mais on peut décider si l’action est au moment du changement d’état ou pendant toute la durée de cet état, par exemple pour un BP, au moment où on appuie dessus ou tant qu’il reste appuyé.
Bonne soirée
1 « J'aime »
Bravo aux équipes @GCE pour les naissances à venir, j’espère des appros faciles en ammont pour vous et un prix juridiceusement positionné au final
L’intégration avec le reste du monde reste pour moi un élément clé. L’arrivée du ModBUS est clairement un plus (une fois le logiciel à bord apte à l’exploiter) pour s’intégrer avec les briques plus « pro » souvent austères (VMC DF, Registres VMC, Clim…), peu évolutives et gérées par des automates/technologies hors d’âge.
Toutefois, l’évolutivité de la solution reste un soucis car sauf erreur nous sommes sur du code propriétaire. Je me trompe ?
Si tel est bien le cas, j’y vois deux soucis.
En premier, si par malheur GCE venait à changer de cap (rachat ou pire que l’on ne vous souhaite clairement pas 
) pas grand chose ne protègerait la communeauté de vos clients face à des problèmes d’évolutivité nécessaires (intégration de correctifs ou de technologies nouvelles). Est-ce un scénario qui a été envisagé chez vous ? Quelle réponse de pérénité apportez-vous ?
Ce problème se pose également avec la sortie de V(n+1) récurente : il est difficile (voire impossible par manque de ressource) pour un fabricant de continuer à faire évoluer le logiciel des anciennes itération. Une communeauté ayant accès au code peut le faire sur son propre temps, c’est une solution à peu de frais si elle est bien encadrée juridiquement
En second, de plus, j’ai beau parcourir les forums et docs, il me semble difficile d’apporter des améliorations ou modifications au code existant. Je n’ai pas vu de socle standard d’apport de module d’extensions avec des API internes documentées (et donc standardisée, lire relativement stable dans le temps). Ceci permettrait par exemple l’apport de modules Modbus pour les VMC par exemple. Est-ce quelque chose que la V5 va apporter ?
Idéalement, avoir a minima un socle standard avec un cadre définis utilisant des outils standards facilement disponibles (IDE, toolchain, etc) aide les membres des communeautés à plus s’impliquer et contribuer de de la valeur en complément de celle apportée par les équipes internes. Développer un projet matériel est complexe, couteux et long, mais celà l’est aussi pour du logiciel. Et trés souvent, je constate que dans le monde de la domotique, le logiciel reste souvent trés en dessous des attentes ou de l’état de l’art. Un tel socle standard pour des extensions est-il envisagé pour la V5 ?
De plus, du fait de l’absence de brique Node RED ou équivalent libre sur le X800 v5 (pas vu de portage sur du STM32H7), il n’est pas possible de « tout » effectuer sur un X800 en bénéficiant des larges contributions déjà existantes des briques d’automatisations existantes.
Dans ce contexte, le support de MQTT me semble indispensable sur la v5 afin de permettre la consommation et le pilotage depuis un broker tiers. Il permetrait de fluidifier les interractions entre modules et évite d’avoir à redévelopper des connecteurs de pooling pour éviter de saturer les API HTTP du X800. Car clairement hormis à partir de la V2, HTTP n’est pas fait pour faire du machine à machine fiable🙄
Côté sécurisation, j’espère que vous ajouterez la possibilité d’importer sa propre AC et de reconnaitre les utilisateurs ou équipements via certificat. Celà eviterait de voir trainer en clair des clé d’API dans des écrans. Dans un monde idéal, l’équipement serait 802.1X pour garantir la légitimité de l’équipement (
).
Côté réseau aussi, je n’ai rien vu concernant IPv6. Il me semble qu’il est important de disposer d’IPv6 a minima pour ses caractéristiques de fonctionnement sans server (« DHCPv6 » stateless) qui est le cas en cas de rupture des liens (switches, cable …) vers le serveur DNS (souvent la box, ou « pire » un serveur au de là du routeur maison… la box par défaut). Sera-t-il possible d’activer ainsi IPv6 sur les v5 ?
Enfin, se pose le problème de la gestion de panne. En cas de panne d’un X800, tout le secteur racordé tombe. Le V5 va-t-il apporter des solutions pour simplifier la gestion de panne ? Remplacement de composants « en place » (par ex les relais), réplication de configuration entre plusieurs X800 fonctionnant pour l’utilisateur en « cluster » …
Merci à toutes les équipes @GCE pour le super boulot 
PS : J’ai pas vu de docs en Anglais sur la V4 GCE Electronics - Downloads ? Erreur de lien sur votre CMS ou docs pas encore dispos ? La qualité de vos produits me semble être adaptée au marché européen (vers l’infini et au delà ), donc je n’espère pas qu’au delà du « Made in France » affiché, c’est de la timidité 
Le marché européen est-il une cible pour vous pour cette V5 ?
Bonjour @grocrabe
Merci de votre retour et je suis bien conscient que la v5 va fortement évolué mais ça me permet de de réfléchir un peu en amont en fonction dès informations que l’on a
Bonne journée
Bonjour @cescargot,
Il y a beaucoup de questions dans votre post. Si on pouvait répondre oui à toutes vos demandes le prix d’un tel produit serait tres élevé. Je vais quand même pouvoir apporter quelques réponses à vos questions 
Concernant l’avenir de GCE et la stabilité de la société, je ne suis pas inquiet. Nous sommes indépendants sans contraintes particulières avec une situation financière très stable et croissante depuis le début de nos activités en 2009.
Un petit article sur GCE Electronics en page 83 du magazine entreprendre de ce mois ci…
Il n’y a aucun intérêt de changer de cap alors que nos clients sont satisfaits et que GCE Electronics fonctionne bien
Concernant le maintient du code quand on sort un produit V+1 en général c’est qu’il n’est plus possible de faire évoluer le soft de la version en cours. Du coup on maintient en corrigeant simplement les bugs + quelques petites évolutions et on se focalise sur le dev de la v+1.
Mettre le code en open source est suicidaire car même un bon encadrement juridique et les bonnes licences, cela n’empêche pas la contrefaçon. Je n’ai pas envi de passer toutes les ressources de GCE en procès.
Par contre on a integré une api RestFul qui permet de développer des applications externes ayant la main sur toutes les fonctions internes de l’IPX. Cela permettra à n’importe qui de lancer une application open source et de faire participer la communauté. On donnera notre accord à qui veut bien se lancer.
Pour la sécurité la v5 embarque le https et le tls 1.3 avec certificat autogénéré et signé. Il faudra simplement un nom domaine et une adresse e-mail pour activer le https.
L’IP v6 est supportée.
MQTT est aussi intégré
Pour Modbus c’est prévu mais se ne sera peut être pas fonctionnel dès la sortie du produit car on a un peu de retard sur ce sujet.
Pour la gestion de panne, tous nos produits sont réparables…les connecteurs sont débrochables donc ça simplifie vraiment le remplacement d’un produit. Enfin depuis la v4 on a donné plus d’autonomie aux extensions les plus usuelles. Elles peuvent fonctionner seules sans automate. Les versions 5 seront encore plus robustes car on a vraiment envi d’ élever le niveau de fiabilité de nos produits et éviter les retours sav au maximum. Pour exemple la nouvelle alim x-psu intègre un nombre important de sécurité avec un redémarrage auto dès la disparition du défaut.
Concernant les documentations c’est toujours uu peu le point faible. Il existe une doc en anglais de la v4 disponible sur notre site rubrique téléchargement mais pas super à jour. Il y a par contre un wiki maintenue par nos contributeurs (que je remercie au passage) qui regorge d’info et d’exemple.
La v5 est multilangues donc ce sera plus simple de maintenir les docs et aussi de se positionner sur de nouveaux marchés.
Voilà c’est déjà pas si mal pour une évolution de produit. Il y a beaucoup à dire sur l’IPX800 V5 car c’est vraiment une nouvelle machine très innovante sur de nombreux points.
Les preventes approchent à grand pas, on pourra tout dévoiler dans quelques semaines
9 « J'aime »
Merci pour cette longue réponse ainsi que le lien sur l’article sympa (en p82 )
Concernant la réparabilité du produit, vous parlez de remplacement. Ce n’est pas la même chose. Domage qu’il n’y ait aucune couverture de ce point car c’est un sujet plus que d’actualité avec de plus un cadre règlementaire qui se renforce. En complément, c’est un potentiel différentiant avec les produits « made in cheap », dont la seule réparabilité est généralement le remplacement par un neuf. Peut-être sur la V6 La possibilité de remplacer un relai par embrochage, la fourniture d’une documentation de réparation (point de contrôles avec signaux à contrôler, références et principales caractéristiques des composants pouvant être changés)…
Comme les humains, les entreprises sont des entités à durée de vie finies. Votre seule bonne volonté (et celle de vos employés) ne peuvent pas prémunir à eux seul l’ensemble de vos clients d’aléas. Certes le fonctionnement hors cloud permet d’éviter l’effet Nabaztag pour les clients. Mais l’absence de code bride la capacité des clients à maitriser le cycle au delà du cycle effectif du fabricant.
Celà fait des décénies que la domotique est vendue comme le futur. Des décénies que les fabricants utilisent des technos et des codes propriétaires qui sont limitées par leurs choix propres : faible volume de vente, vendu cher, mauvaise évolutivité et piètre interropérabilité.
Utiliser Ethernet en standard de communication est une clé : stable et fiable, c’est bien pour l’IPX800 un gage de fiablité car il est facile à intégrer, facile à maintenir et surveiller son bon fonctionnement (FW, sondes, etc). Mais d’autres font déjà de même …
Vous dites « Mettre le code en open source est suicidaire car même un bon encadrement juridique et les bonnes licences, cela n’empêche pas la contrefaçon. »
Si la contrefaçon était bloquée par la mise en code propriétaire ou le dépot de brevet, celà se saurait aussi. De plus des entreprises telles que Olimex qui ont même le matériel sous licence libre semblent bien se porter pour des « suicidaires »
Domage en tous les cas qu’il n’y ait pas de possibilité d’extension a minima du système.
Vous indiquez enfin « Je n’ai pas envi de passer toutes les ressources de GCE en procès. »
Logiciel libre ou pas, vous pouvez être ammené à le faire pour vous défendre face à une concurence indélicate. Celà fait parti des aléas de la distribution de produits industriels malheureusement …
En l’absence de code source public, vous aurez simplement plus de difficulté à prouver l’antériorité d’idées sauf à tout passer sous Soleau, ce que j’espère que vous faites déjà
Bon courage à toutes les équipes pour la V5👍
Bonjour,
J’ai bien mis tous nos produits sont réparables…Donc on change les pièces et ont renvoi aux clients…
On ne changent que quand c’est vraiment irréparable.
Olimex vend des cartes électroniques brut sans software ou juste avec un soft de démo… ce n’est pas comparable. Pour comparer demander plutôt à Loxone pourquoi il ne diffuse pas leurs codes en open source ?
Je ne vais pas plus loin car vous semblez avoir des convictions bien établies et je ne souhaite pas entrer dans un dialogue sans fin. Merci en tout cas pour vos encouragements.
Pour info la meilleure des protections est le secret. Le brevet vous impose de dévoiler au grand public votre invention.
6 « J'aime »
Avez-vous prévu une note de réparabilité pour la V5 ?
Olimex est effectivement un fabricant de matériel qui met bien le coeur de son activité (le matériel) sous licence libre. Il me semblait donc bien qu’il y avait un élément opportun face à votre remarque initiale.
Concernant le « secret », il est toujours relatif quand on a des équipements électroniques que l’on vend à des tiers. Certaines officines sont spécialisées dans l’analyse de brevets mais aussi la rétro-ingénieurie …
La meilleure des protections n’est pas le secret mais bien toujours l’enveloppe Soleau Car seule une enveloppe Soleau de l’INPI prouvera votre antériorité et empéchera ainsi un concurent ayant posé un brevet de vous interdire (ou restreindre) l’utilisation d’un élément déposé dans votre système. Sans « soleautage », en simple approche par le secret, vous pouvez vous retrouver dans un dépôt « sauvage » de brevet par un concurent sur un élément clé que vous exploitez déjà. Il ne sera pas aisé de prouver l’antériorité en l’absence d’une quelconque notarisation des commencements de preuve de votre côté.
Cdt
Bonjour cescargot,
L’un n’empêche pas l’autre puisque l’enveloppe Soleau protège le secret car elle est archivée scellée par l’INPI.
Bonne journée
Bonjour,
Je ne souhaite pas rentrer dans un débat d’expert car le forum n’est pas l’endroit pour ça. Nos produits sont très bien protégés et nos innovations aussi. Nous avons un cabinet d’experts et d’avocats en droit de la propriété intellectuelle qui est en charge de cette partie.
Pour la reparabilité de nos produits je ne suis pas inquiet car on a toujours pris en compte ce facteur lors de la conception des produits.
Je clôture ce post car c’est plus dans le thème du sujet.
Et pour revenir au sujet, voila un excellente nouvelle pour celles et ceux qui, comme moi, attendent la V5 avec impatience ! Sans vouloir vous mettre la pression, on a vraiment hâte
6 « J'aime »
Oui nous aussi on a hate
7 « J'aime »
Je pense que le sujet a déjà été abordé dans ce thread mais concernant le protocole zigbee, un module complémentaire sera-t-il prévu ?
J’ai une installation domotique grand publique avec un hub tuya wifi et lampes en zigbee… j’aimerai professionnaliser avec le nouvel ipx v5 mais je vous avoue que " jeter " mes lampes connectées zigbee me feraient un peu mal 
Bonjour
Si vous utilisez l’API Tuyapi développée pour ces hubs, vous devriez pouvoir interfacer avec l’ipx800.
Bonne journée
2 « J'aime »