Nouveautés et mise à jour des services Jeedom

Cet été a été propice à pas mal de nouvelles idées chez Jeedom, nous allons ici vous les présenter dans les grandes lignes.

Doc de compatibilité

Beaucoup l’attendaient, la doc de compatibilité est enfin là, vous la trouverez ici. N’hésitez pas à la regarder fréquemment car elle est vouée à évoluer.

Jeedom 2.4

Nous allons bientôt sortir Jeedom 2.4, je vous mets en avant-première les nouveautés :

  • Optimisation générale
    • Regroupement de requêtes SQL
    • Suppression de requêtes inutiles
    • Passage en cache du pid, état et dernier lancement des scénarios
    • Passage en cache du pid, état et dernier lancement des crons
    • Dans 99% des cas plus de requêtes d’écriture sur la base en fonctionnement nominal (donc hors configuration de Jeedom, modifications, installation, mise à jour…)
  • Suppression du fail2ban (car facilement passable en envoyant une fausse adresse ip), cela permet d’accélérer Jeedom
  • Ajout dans les interactions d’une option sans catégorie pour que l’on puisse générer des interactions sur des équipements sans catégorie
  • Ajout dans les scénario d’un bouton de choix de commande sur celles de type slider
  • Mise à jour de bootstrap en 2.3.7
  • Ajout de la notion de Résumé Domotique (permet de connaître d’un seul coup d’oeil le nombre de lumières à « On », de détections de mouvement, de portes ouvertes, pareil pour les volets et les fenêtres, la puissance électrique,…). Tout cela se configure sur la page de gestion des objets. Les types de remontées peuvent également être personnalisés depuis la page de configuration dans l’accordéon « Configuration des résumés d’objet »
  • Ajout de méthodes « pré » et « post commande » sur une commande. Cela permet de déclencher tout le temps une action avant ou après une autre action, et peut aussi permettre de synchroniser des équipements pour que par exemple 2 lumières s’allument toujours ensemble avec la même intensité.
  • Optimisation des listenner (utilisé par le plugin Jeelink)
  • Ajout de modales pour afficher les informations brutes (attribut de l’objet en base) d’un équipement ou d’une commande depuis la modale de configuration
  • Possibilité de copier l’historique d’une commande sur une autre commande
  • Possibilité de remplacer une commande par une autre dans tout Jeedom (même si la commande à remplacer n’existe plus)

Cap sur la prochaine version Jeedom

Bien que celui-ci arrivera pas avant un bon moment (1er voir 2ème trimestre 2017) nous avons commencé à travailler dessus. Les grosses nouveautés seront :

  • Suppression du mode esclave. Je sais que ce sujet soulève beaucoup d’inquiétudes, ce qu’il faut savoir c’est que déjà il est utilisé par environ 2.24 % des utilisateurs Jeedom (c’est vraiment très faible) donc l’impact est limité. Le plugin Jeelink qui remplacera le mode esclave étant déjà disponible vous permet de commencer la migration, une doc détaillée vous expliquant tout le processus est en cours de rédaction pour vous accompagner le plus possible.
  • Revue de la gestion des droits utilisateurs, en effet le système actuel n’est pas vraiment pratique en plus de ralentir Jeedom. Nous referons un article pour vous expliquer les changements.
  • Et plein d’autres trucs comme toujours !

En prévision :

Modification de la gestion des betatesteurs

Bien que le système actuel avec les beta testeurs nous convient parfaitement au niveau des plugins officiels, on a vu qu’au niveau des plugins tierces cela posait soucis où souvent les beta testeurs n’avaient pas le matériel pour tester les plugins. On a donc décidé de revoir cela en permettant à n’importe quel utilisateur d’avoir accès au beta mais attention une fois qu’un utilisateur sera sur une beta il perdra l’accès au support c’est donc un choix à faire en fonction de vos besoins et connaissances (à vos risques et périls !) mais au moins vous aurez le choix.

Modification de la gestion des tickets

On va aussi revoir la gestion des tickets, les nouveautés seront :

  • Pour les utilisateurs en community et demande de support officiel (core, plugins officiels ou services dns/sms/backup officiels) : il y aura certainement un crédit de tickets à la création du compte (on ne sait pas encore combien) et après une solution de recharge de ce crédit sera proposée
  • Pour les ouvertures de tickets auprès du support officiel, un système d’envoi de mail automatique pour informer de la prise en compte du ticket est également prévu afin de rassurer les utilisateurs quand à l’arrivée de leur demande auprès de l’équipe.
  • Pour les plugins tierces il faudra que les développeurs des plugins donnent soit :
    • une url vers leur outil de gestion de ticket (github est parfait pour ça)
    • un texte expliquant comment contacter leur propre support
    • si rien n’ait fourni à l’équipe par un développeur, le système restera tel qu’il est (mail).

Modification sur la gestion des docs

Nous allons aussi revoir la gestion des docs. En effet le système actuel souffre d’un gros soucis : la doc étant en ligne c’est forcément la dernière version que vous consultez et non celle correspondant à la version du plugin ou du core que vous avez. Nous allons donc insérer directement la génération html de la documentation à partir du asciidoc dans le plugin pour que vous puissiez consulter celle-ci en local. A coté de cela nous garderons bien sur toujours le site de doc en ligne qui lui aura la documentation de la dernière version stable du plugin (ou du core). Malheureusement ce système ne pourra être utilisé que pour les plugins officiels, une solution est en cours d’étude pour les docs des plugins tierces.

Pour les développeurs, ne vous inquiétez pas vous aurez une longue période pour faire la transition nous ne couperons pas l’ancien système de si tôt, de plus nous vous fournirons les script de conversion et vous pourrez aussi directement faire votre doc en html.

Modification sur la gestion des traductions

Actuellement, le système de gestion de traductions nous pose beaucoup de soucis et il est très lourd à maintenir. Nous allons donc effectuer pas mal de modifications dessus. Nous allons rendre github plus central dans notre processus, au lieu d’intégrer les traductions au niveau de l’archive ZIP du plugin (comme actuellement), nous allons les pousser directement dans les dépôts github des plugins. Le gain sera énorme pour nous, et beaucoup plus simple à gérer, puisque nous aurons juste un job qui partira la nuit et qui s’occupera des traductions. Ces traductions ne seront poussées que sur les branches beta des plugins et du core bien sûr, afin qu’à l’arrivée en stable un maximum soit traduit. Malheureusement cela aura une conséquence pour les plugins tierces qui ne pourront plus bénéficier d’un système de traduction… Des scripts pourront être fournis aux développeurs pour vous aider à gérer les traductions. Cela nous pose beaucoup de soucis mais si on compare à d’autres plateformes cela se déroule souvent ainsi (et nous simplifie beaucoup la gestion).

Modification sur les différentes versions des plugins et du core

Nous allons revoir aussi la gestion des versions des plugins et du core avec 3 versions au lieu de 2 : beta, stable et pro. Les versions des plugins et du core correspondront aux branches sur le dépôt git pour nous simplifier la tâche, avec un système de récupération automatique toutes les nuits vers le market. Les développeurs tierces pourront faire cela aussi pour les versions beta et stable de leurs plugins via github.

Nous allons aussi supprimer la validation en stable d’un plugin sur le market, le développeur pourra donc immédiatement passer les plugins de beta à stable sans validation de notre part (on s’est aperçu que vu tous les types de périphériques domotiques possibles et configurations existantes nous ne pouvions valider réellement tous les plugins). En revanche, dans le même temps, un bouton « signaler » sur le market sera mis en place, afin que les utilisateurs puissent signaler les dysfonctionnements répétés d’un plugin et alerter l’équipe qui prendra contact avec le développeur. Le plugin pourra être passé en obsolète en attendant que les soucis remontés soient corrigés. Le process lié à ce bouton « signaler » est en cours de réflexion mais l’idée est bien là. (Merci @domomat du forum pour cette idée qui a bien plu).

Changelogs

Les changelogs des plugins seront également intégrés directement dans la documentation du plugin ou du core, ainsi lors de la mise à jour il vous suffira de consulter la documentation du plugin.

 

Toutes ces modification sont prévues sur du long terme, globalement elles arriveront toutes d’ici l’été prochain.

Pour les développeurs tierces : rassurez-vous nous pensons à vous et nous vous tiendrons informés des avancées (vérifiez que votre mail sur le market soit à jour). Nous ferons tout notre possible pour mettre à votre disposition des outils ou solutions pour vous simplifier les démarches doc, traductions et tickets.

Pour conclure il va y avoir aussi pas mal d’autres annonces (nouveaux plugins dont EnOcean, Jarvis…), nouvelle version de l’application mobile et aussi des nouvelles de la future box Jeedom.

Cet article a été lu 6215 fois

Vous aimerez aussi...

30 réponses

  1. mickeys dit :

    Super merci pour l’info

    Si vous pensez embaucher d’autre dev… Faites moi signe 😉

  2. Dany GINHOUX dit :

    Belle présentation !

    Est ce qu’un retour de beta vers stable nous permettra de récupérer le support ? En gros, est ce que la perte du support est définitive ?

  3. llaumgui dit :

    Super nouvelles, sinon le plugin Dotti arrivera avec la 2.4 ?

  4. coulox dit :

    on pourra avoir accès au forum des bêtas testeur en lecture seul si on décide de prendre un plugin en bêta ?

  5. Syll dit :

    Très intéressant de voir tout ça et de voir que vous ne vous reposez pas sur vos lauriers 🙂

    Concernant les tickets, y’aura t-il une notion de délai ? …. j’ai fait un ticket début août sur un plugin Officiel et je n’ai eu à ce jour qu’un mail : On va regarder…. et j’attends tjs..

    • loic dit :

      Bonjour,
      Je pense qu’il y a eu un soucis avec votre ticket car nous n’en avons aucun en attente de réponse actuellement. Pour les délais ils sont indiqué sur le site web (attention c’est en heures ouvrées et il n’y en a que 8 par jour). Nous allons ajouté une confirmation de réception de ticket car beaucoup d’utilisateur sont perdus.

  6. Arnaud dit :

    Toujours plus loin, toujours plus fort… 🙂

  7. deolisa dit :

    Bonsoir,
    Est ce que cette version réalise automatiquement le transfert de nginx à apache ?

    • loic dit :

      Bonjour,
      Non nous ne ferons jamais cette migration automatiquement car nous supportons les 2 serveurs même si maintenant le choix par défaut est apache

  8. domomat dit :

    On sent la maturité par cette recherche d’industrialisation des processus, c’est une bonne nouvelle.

    Il vous faut maintenant un designer d’interface pour l’effet waouuu et on tiendra un produit d’exception (même si c’est déjà pas mal avec le thème dark sobre et quelques widgets bien choisis) !

    Merci, pour l’article et pour le clin d’oeil !

  9. i-magin dit :

    Je suis vraiment satisfait d’avoir migré mon ancien système domotique sur Jeedom J’apprécie d’être informé par cette feuille de route
    Encore merci !

  10. Lio06 dit :

    Félicitations en effet on sent l’industrialisation

    En attente de voir cette nouvelle box

    Juste une remarque dans le texte : « si rien n’ait fourni à l’équipe par un développeur, le système restera tel qu’il est (mail). » ->si rien n’est fourni

  11. toregreb dit :

    Merci pour cet article. Il y a un gros travail à faire sur les plugins qui se sont multipliés comme les nénuphares au milieu de la mare. Je suis parfois un peu perdu lorsque je cherche une fonctionnalité sur le market. Je me demande aussi si les plugins script et virtuel ne devraient pas être intégrés au core ou installés par défaut.

  12. Chris6783 dit :

    Merci pour la com. On sent la maturité qui s’affirme et vous partagez votre cap. C vraiment bien d’informer et de tenir compte des retours que vous voyez passer sur le forum.
    Bonne continuation

  13. Bimgas dit :

    C’est une bonne chose pour la gestion des plugins !

  14. clem71450 dit :

    Je me posais la question pour la documentation pourquoi pas un wiki?
    Pour un changement de version on regarde avec l’historique.
    Cela permettrait d’avoir aussi les plugins non officielle dessus?

    • loic dit :

      Bonjour,
      Au début c’était la solution choisi mais les utilisateurs nous ont remonté que c’était pas pratique nous somme donc revenu a une doc standard.

  15. gngh dit :

    Bonjour,
    Je suis très content de voir que les grosses nouveautés sont assez réduites pour chaque mise à jour.
    Ce qui veut dire qu’il y aura moins de problèmes possible a chaque fois.

    La base est la, il manque juste une interface de dingue avec animations, transition etc….pour mettre des écrans partout dans la maison et tout piloter via Jeedom 😉

  16. guenneguez_t dit :

    Bonjour,

    Merci pour ce post très intéressant. J’apprécie très fortement l’ouverture du système de ticket pour les plugins non officiel. Ce serait même intéressant de mettre (des maintenant si possible) un message genre :
    Le plugin pour lequel vous avez fait une demande de support n’est pas officiel. La demande est donc transmise au développeur du plugin.

    Par rapport aux réflexions en cours 😉
    Pour les développeurs, j’ai peur pour le système de doc 😉
    Ne serait-il pas possible que le développeur lorsqu’il soumets un plugin, que le processus dézip l’archive, génère le html et refasse l’archive ?
    Pour les traductions, ne serait-il pas possible que les traductions soient dans une arborescence indépendante (genre l’utilisateur demande à télécharger la langue XXX). Ca téléchargerait alors pour tous les plugins.
    Si chaque développeur doit se mettre à gérer ses traductions, il y a énormément de chance pour que très peu le fasse. Jeedom n’aurait-il pas gros à perdre ?
    J’adore l’idée de rendre le développeur autonome sur le passage de beta à stable avec signalement.
    J’adore le « Nous ferons tout notre possible pour mettre à votre disposition des outils ou solutions pour vous simplifier les démarches doc, traductions et tickets. », c’est pour celà que je vous partages quelques idées 😉

    Merci Loïc pour ce post très prometteur
    Thomas

    • loic dit :

      Bonjour,
      Effectivement on pourrait mettre un message mtn mais vue qu’on a déjà commencé les modifications c’est compliqué.
      Pour les traductions et doc des plugins tierce je rappel que sur toute les autres plateformes c’est au dev de gérer LEUR doc et traduction donc oui on pourrait aussi faire plein de truc on peut aussi tout faire à votre place mais on ne le fera pas. Par rapport à l’article on a juste rajouter la gestion de VOS doc et traduction si vous nous laisser un accès en écriture à vos dépôt github et uniquement github.

      • guenneguez_t dit :

        Bonjour,

        Je comprends ce soit au dev de gérer ses doc. Pour les traductions, je comprends que ce ne soit pas à l’équipe jeedom. Mon souci premier n’est pas de gérer mes traductions (bien que ce soit un souci), c’est que quelqu’un aille les traduire… Actuellement j’ai dejà du mal à trouver des beta testeur …

        Par contre le fonctionnement actuel des traductions fait que quelqu’un de motivé et qui se prend au jeu de traduire jeedom pour la communauté va aussi traduire les plugins.
        Je prends l’exemple du plugin ipx800. Il est traduit à 100% en Allemand, Espagnol, Anglais, Italien, Russe et commence à être traduit en Indonésien, Portugais, Japonnais. Personnellement je n’aurais jamais pu traduire une seule langue et j’ai réussi a identifier uniquement un beta tester…

        Je pense que ce bon résultat est lié au fait que les traducteurs n’ont qu’un seul site à gérer pour traduire, et pris au jeu, ils traduisent tout.

        Je n’ai pas dit qu’il fallait faire tout à notre place. Je dis juste que le fait que le gestionnaire de traduction étant centralysé, ca a pour conséquence que beaucoup de plugin soient traduit. Si chaque développeur doit gérer ses traductions, certains le feront dans transiflex, d’autre dans localize.reverso.net voir dans localizejs.com. En conséquent, beaucoup moins de chose seront traduite…

        Pas besoin forcément de me répondre, je vous donne juste mon point de vu, sans parler des difficultés techniques qu’ils peuvent engendrer.

        A+
        Thomas

  17. cocapic dit :

    Hello,

    Je cherche en vain a telechargé un plugin en beta, mais j’ai pas l’icone beta sur le plugin, j’ai raté une config ?

    merci

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *