Le projet de domotique open source français Jeedom passe un nouveau cap : la v4 de son « Core » est désormais finalisée et considérée comme stable. Il faut maintenant migrer les nombreux utilisateurs sur cette version, avant de continuer l'évolution : cap sur la v4.1.
Cela fait plusieurs mois maintenant que Jeedom v4 est disponible, utilisé sur certaines plateformes comme la Freebox Delta par exemple. Mais elle n'était pas considérée comme finalisée par ses développeurs. C'est aujourd'hui le cas, annoncent-ils dans un billet de blog. Elle est accessible à tous et considérée comme stable.
Une évolution des bases de Jeedom
De nombreux changements sont au programme notamment un travail de fond puisque l'équipe s'est notamment consacrée sur l'allègement du code, l'amélioration des performances et autres correctifs de sécurité. Les différentes bibliothèques utilisées ont été mises à jour, le résumé domotique a eu droit à une refonte, tout comme la configuration système qui a été réorganisée, gagnant quelques nouveaux paramètres au passage.
On a aussi droit à des raccourcis clavier, de nouveaux menus contextuels apparaissant au clic droit sur les onglets, des bulles d'aide au survol de la souris, une optimisation de la recherche. Trois thèmes sont proposés : un clair, un sombre et « legacy » qui reprend les codes graphiques de la v3, « pour les nostalgiques ». Une bascule peut être opérée selon l'heure de la journée ou de la luminosité sur mobile.
L'un des objectifs était ainsi de rendre l'ensemble plus agréable à l'utilisation, notamment pour les nouveaux venus. Jeedom souffrant notamment de son image de produit « complet mais complexe », pas toujours au meilleur de sa forme d'un point de vue graphique pour qui ne passe pas des heures à tout revoir.
Nouveaux thèmes, personnalisation, widgets
Sur ce terrain, la v4 apporte d'ailleurs des « options de personnalisation dans les paramètres d’affichage des éléments d’un design en complément de différentes optimisations dans la gestion des designs et des éléments qui le composent. » mais les développeurs préviennent : « certaines personnalisations apportées aux designs en V3 devront être remaniées lors du passage en V4 ». Un outil de migration v3/v4 est d'ailleurs disponible.
Le menu principal a également eu droit à un petit coup de rafraichissement, proposant un accès plus direct à certains éléments désormais ainsi qu'un sous-menu Outil > Widgets. L'année dernière, l'équipe détaillait d'ailleurs son plan pour la gestion des Widgets et comment elle diffère en v4. La documentation est disponible par ici. Enfin, la page Scénarios se veut plus lisible et plus simple à utiliser, avec la possibilité d'en exporter/importer.
Tous les détails de Jeedom v4 se trouvent dans les notes de version. L'équipe travaille d'ailleurs actuellement sur la prochaine évolution du système domotique : la v4.1. Elle est actuellement en phase d'alpha.
Commentaires (47)
#1
Y’a eu aussi une grosse refonte du plugin rfxcom, qqn l’a testé ?
Je m’en sers beaucoup et je suis un poil inquiet…
#2
Salut !
Oui j’ai fais les MAJ au fur et à mesure et j’ai eu des soucis jusqu’à lundi. Avec la version du 29⁄11 et une réinstallation des dépendances (+ demon restart), tout est revenu à la normale.
FYI j’ai 2 modules de volet roulant et 5 prises 220V DIO. LE tout tourne sur rpi 3b et jeedom 4.0.61
#3
Es-tu resté sur une carte SD ou as-tu fais un montage de SSD mSATA ou 2”5 via carte controleur ? ou autre ? Je viens de me monter un Jeedom sur RPI 3B, avec notamment un relevé Teleinfo du compteur électrique et ma station météo Netatmo. Quand je vois la fréquence des actualisations et la quantité de donnée que ça représente, je me dis que ma carte SD ne va pas faire long feu…
#4
t’as utilisé quoi pour ton relevé téléinfo ?
coté électronique branchée au compteur et coté pi pour récupérer les données
j’ai un pi (plusieurs mais osef pour le coup), j’ai le montage qui convertit la téléinfo en qqch de lisible sur les pattes tx/rx d’un arduino / esp8266, mais je me suis pas lancé dans la lecture depuis l’esp vers un mini écran oled (par exemple) et/ou vers l’envoi sur un pi des quelques infos intéressantes :s
#5
Et pour lire les données j’utilises ce plugin Jeedom.
#6
:(
j’espérais une solution plus DYI :p
du coup le tout est géré directement par le pi et il y a un module jdom que tu as pu paramétrer pour lire le résultat et le stocker je suppose
merci pour l’info, j’avais déjà vu quelques modules usb mais pas celui-là
(edit : par contre vu le prix des composants que la partie electronique m’a coûté, ce boîtier est hyper cher en fait)
#7
Dans le genre DIY y’a ça : https://www.magdiblog.fr/gpio/teleinfo-edf-suivi-conso-de-votre-compteur-electrique/. Ca me semble simple et efficace.
#8
Je n’en doute pas. Combien t’a coûté le matériel électronique ?
Une solution pour se passer de la carte SD ?
#9
je sais plus si j’étais tombé sur cet article ou pas à l’époque, je me rend compte que j’ai fait le montage y’a un bon moment déjà, mais jamais mis en service XD
ça me (re)titille d’en faire qqch :p
merci
#10
raaaah c’est moche, j’étais en train d’éditer pour te répondre et pouf, j’ai tout perdu
donc euh, pour le matos, le schéma ressemble à celui de ton lien, donc l’optocoupleur doit venir d’un lot du genre 10 à 10 euros (probablement plutôt entre 3 et 5 euros)
les résistances traînaient de montages précédents, et/ou probablement d’un lot de 200 avec plusieurs valeurs, le genre de truc à 5/8€
je vois un transistor sur mon montage, vu son format ça devait être un truc précis, disons 0.5€
le morceau de plaque de protypage sur lequel tout est soudé doit venir d’un lot pas cher aussi
j’ai pu constater le fonctionnement du port série grace à la platique de programmation d’un module esp8266 “witty cloud” (entre 3 et 7 euros la platine + l’esp8266) car la platine se branche en usb et fourni un “port com” lisible depuis l’IDE arduino, où j’ai pu lire la téléinfo :p
edit:
ah et pour le pi, j’ai pas de pi 3, j’ai des “1” et des “4”, les 4 peuvent maintenant booter sur l’usb, donc c’est ce que j’ai fait pour l’un d’eux
il parait qu’on peut le faire aussi sur les pi3, mais j’ai jamais fait :s
sinon ce qui est faisable aussi, c’est d’enregistrer dans des fichiers sur un dd branché en usb au lieu de sur la sd, mais peut-etre plus compliqué à paramétrer dans jdom
#11
Ne faisant pas de domotique mais faisant du Raspberry (Raspb1B / Raspb2b / 2x Raspb3b / Raspb3B+ / Raspb4B8GB), je peux t’apporter quelques informations :
À partir du Raspberry 3 et supérieur, il est possible de booter sur USB directement. Il n’y a pas de port USB précis, le Raspberry boot sur le premier périphérique USB qui répond (attention donc au combo HDD et clef USB).
Avant le Raspberry 3 (donc le 1 et 2) il est aussi possible de “booter” sur USB de manière indirecte pour préserver la carte µSD. En gros pour ceux là, le boot reste sur la carte µSD mais tu rediriges directement sur la clef USB. Ce faisant, la carte µSD n’est là que pour ça (vu que ceux là doivent obligatoirement démarrer sur le port µSD au boot) et peut être mise en lecture seule vu que tu n’écris pas dessus.
L’autre chose à faire pour la carte µSD de conseillé et de mettre les logs en RAM
#12
Je suis en uSD avec qq dizaines de capteurs et d’équipements à piloter depuis 2 ans…
j’ai pas pris du 1er prix et ça semble tenir pour l’instant
#13
Tu peux y aller plus de souci depuis les dernières MAJ, après bon rien de neuf.
#14
Passes en msata, ça change la vie et après 2 cartes SD morte tu le feras xD
Perso perf et fiabilité avec quand même une sauvegarde externe auto.
#15
Est-ce que cette solution dépend d’un serveur WAN ? Je n’ai pas compris, ni dans l’article ni dans les commentaires si le dispositif pouvait rester opérationnel après l’achat en l’absence de son fournisseur.
#16
le concept est bon … mais il mériterai d’être intégralement réécrit malheureusement :-(
j’en ai un qui tourne mais je n’ai aucune confiance ni dans les perfs, ni dans la sécurité ni dans la résilience. Et l’UI qui est un mix très bizarre entre de l’ancien et du nouveau mais sans convaincre.
ceci étant dit, il fait le taff mais j’en attends bcp plus.
#17
Non non, c’est du « on premise » (tu l’installes toi même chez toi et tu es autonome)
#18
Thx
Ouais je sais bien mais pour l’instant, je m’en fout un peu à vrai dire. Ça tiendra tant que ça tiendra.
#19
Je suis exactement dans ce cas là, mais je serai bien embêté si ça me pète dans les doigts en ce moment alors que ça contrôle les radiateurs
#20
Moi aussi
#21
Fait un clone de ta carte sd (toujours le faire !)
En cas de décès de la carte en cours, il suffira de switcher ;)
Soit sur une autre carte sd, soit en .img sur ton pc (utilise PiShrink pour réduire la taille de l’image)
#22
Pas con ça. Mais je n’ai plus de carte SD sous la main.
Faudrait que je m’en commande une… ou quitte à en commander une, commander un stockage plus efficace et faire la transition
Est-qu’il est facile de passer de SD à sotkcage mSata par exemple ?
#23
A mon avis, faut tout réinstaller et restaurer un backup…
#24
Je suis avec intérêt Jeedom depuis un moment. Il faudra un jour que je m’y mette. Pour l’instant j’ai installé Homebridge sur un rPi zero W pour gérer l’ensemble de mes luminaires et force est de reconnaître que ça marche très bien même si je comprends bien qu’on est loin des fonctionnalités de Jeedom.
#25
Avec un domoticz gérant depuis plus de 4 ans la baraque (chauffage, alarme, caméras IP…), tournant donc 24⁄7, je suis aussi resté à la uSD.
En fait, la première avait tenu un peut plus d’1 an… Mais c’était un peu de ma faute, car les caméras envoient les captures sur un FTP qui était sur la uSD. Comme ce FTP est monitoré côté serveur/PI par un service qui gère l’interaction avec l’alarme (un système de poids ajoutés sur une mn glissante, fonction pour les caméras du nb de captures, afin que le piaf qui passe ne déclenche pas mais celui qui bricole un volet/porte pendant 30s oui) et l’externalisation des captures (envoi d’archives chiffrées par tranche de 10s sur un gmail dédié, ainsi un voleur qui repart avec le PI sera détronché) ensuite effacées localement, c’est passé sur un tmpfs en ram et a bien diminué les accès.
Pour les logs etc, pas question de les foutre en ram: Trop utile de les avoir post-mortem. Par contre, pas mal de réglages sysfs au rayon vmm (virtual mem management) et fs (influant sur les commit) permettent de mieux mutualiser les écritures avec des pertes potentielles restant limitées en cas de crash. Surtout si on a mis une alim tampon et que ca ne tombe jamais brutalement.
Le choix de la uSD influe également; Désormais, privilégier les A2 (classe applicative, A2 offrant plus d’IO/s que les A1) qui sont faites pour les smartphones, allumés aussi 24⁄7, donc au firmware du contrôleur de stockage plus évolué et proche dans son fonctionnement d’un vrai SSD interne.
La plupart des cartes mémoire sont en effet faites pour un usage occasionnel (on le temps de prendre une photo/vidéo, donc usage séquentiel ; pas de possibilité de faire des choses en tâche de fond à des moments de moindre utilisation, comme un wear levelling statique et non dynamique…). Sauf ces classes applicatives.
Le gain est très significatif sur l’usure (plus de points chauds typiques d’un wear levelling dynamique) et les perf (plus de lags de l’interface web).
#26
Perso, si Jeedom se mets a utiliser autre chose que PHP à 99%, je considérerais la chose. En attendant, j’en reste à Domoticz qui est codé avec un vrai langage de programmation applicative: C++.
Ca fait tout de suite plus sérieux sous le capot, même si Jeedom est sans doute plus agréable à voir.
#27
PHP fonctionne très bien, si ça marche pourquoi ils changeraient…
Sinon pour les adeptes de Home Assistant, la version 1 va bientôt sortir aussi :)
#28
par contre pas de gros ménage sur le catalogue de Plugins :/
un paquet non compatible, non maintenu, même les page de doc renvoi vers la page d’accueil du site Jeedom. Difficile de savoir ce qui va fonctionner ou non, y compris dans les payants. c’est ce qui me déçoit le plus chez Jeedom.
sinon j’attends pas pizigate pour noyel, et je vire la centrale Xiaomi, tout tournera en local :)
#29
Je m’en sers pour recevoir les ordres de ma sonnette, ça marche bien, et pour commander mon poele MCZ. CA ne marche plus après la première mise à jour du plugin. Je testerai de reinstaller les dependances etc…
#30
J’ai fait la MAJ ce matin, j’ai du réinstaller les dépendances et relancer le démon à la main.
J’ai eu aussi qq confs spécifiques de moteurs de volets qui ont bougé mais je ne sais pas si c’est lié à la MAJ 3.4.54 de Jeedom que j’ai fait en même temps ou pas.
#31
PHP n’est pas ‘très bien’ pour couvrir les besoins d’un système de domotique, c’est à la base un écosystème pensé pour s’initialiser à la réception d’une requête web en grande partie stateless, chopper de la donnée dans une bdd, traiter la requête, sortir un résultat (une page web, un bout de Jason, …) et se rendormir.
Sauf qu’un serveur domotique c’est pas un site web. Sa GUI pourquoi pas, mais certainement pas son coeur.
PHP a sans doute été adopté pour jeedom au départ parce que c’était un langage de script assez accessible, relativement répandu, un dénominateur commun pour fédérer une communauté de bidouilleurs, et qui avait la préférence des initiateurs du projet. Mais ça reste un hérésie pour un tel projet et son usage a été largement tordu et détourné de son but initial. il suffit de se plonger dans le code de jeedom pour comprendre l’ampleur des pansements mis sur certaines jambes de bois pour parvenir à leur fin.
Donc oui, ça marche … mais c’est clairement pas efficient et adapté. un peu comme il est possible techniquement de coder un doom rien qu’avec des formules excel ( https://www.tomshardware.fr/video-un-fou-furieux-code-un-moteur-3d-avec-des-formules-excel/ ). De là à dire que c’est adapté et efficient… certainement pas.
#32
Même principe qu’avant: utiliser une uSD pour en faire le stockage d’un OS c’est possible, voir même passablement pérenne en mettant en oeuvre moults bidouilles et autres hacks.
Ça reste faire rentrer des fonds dans des carrés: comparé à une vraie solution de stockage prévue pour ça, ce n’est ni adapté, ni efficient (pour quel avantage in fine ?)
#33
Je sais ce qu’est PHP merci. Ça peut être fait de manière propre avec des outils modernes. Oui, il y a des langages plus adaptés (surtout pour la concurrence, et utilisation de la mémoire), mais ça peut être propre. Après, je suis allé voir le code, ça fait très old school le style quand même.
(je ne pensais pas que tout leur coeur était en php aussi)
Je me suis installé HAAS dernièrement, ils ont clairement du soucis à se faire avec la traction que le projet a (et oui, python a plus de sens)
#34
Perso j’avais déjà vu que le code se trainait un mauvais départ… il y a eu plusieurs sujets sur le forum à ce propos.
Mais je trouve tout de même que Jeedom fait plutôt bien le taf, même si des améliorations seraient les bienvenues.
Pour Home Assitant, cca me tente de migrer dessus aussi. La solution a l’air mieux conçue. Par contre pour le coté configuration, j’ai l’impression (je peux me tromper) que cela passe exclusivement par des fichiers de config, là où Jeedom passe par un GUI “prémâché”. Me trompe-je ?
#35
En quoi python a plus de sens ? ASP.NET Core n’aurait-il pas plus de sens alors ?
#36
Je n’ai jamais utilisé jeedom donc je ne peux pas comparer, mais il peut y avoir un peut de config via des fichiers yml pour haas oui. Après c’est pas bien méchant, ya pas mal de doc/tutos, et il y a quand même de la config visuelle aussi.
(l’intégration avec esphome est top si on veut installer ses propre capteurs/composants)
Oui ça pourrait être un choix aussi, c’était pour rebondir sur le fait que c’était sûrement un meilleur choix que PHP pour le cœur du système domotique.
#37
Hass c’est le diminutif de ?
OK
#38
https://www.home-assistant.io/
#39
Yep, mais pourquoi haas ? J’ai toujours vu juste HA perso
#40
parce que les dev ont nommé les commandes comme ça : https://www.home-assistant.io/docs/tools/hass/
#41
Ce n’est pas tant une problématique de langage que de plateforme.
Jeedom est architecturé autour d’un coeur qui est trigger par des évenements externes sous forme de calls à des “pseudo pages web” = le principe d’un site web quand un visiteur visite le site web. Il n’y a pas de notion de “démon” (pour le ‘core’ j’entends), dans le sens un process qui tourne en permanence, qui stocke en RAM un état global du système et qui répond aux sollicitations externes, mais peut également décider de lancer lui même des actions en l’absence d’une sollicitation tierce.
Perso, c’est ce principe de base qui me choque.
Après tu pourrais avoir un démon à base de Python, de nodeJS, C/C++, .Net Core ou même de PHP mais à la mode démon/CLI plutôt qu’en mode ‘page web’, là n’est pas tant le coeur du souci.
#42
J’ai fait, ça ne marche toujours pas avec mon poêle à pellets…
#43
#44
Avec un choix de uSD adapté et en utilisant les possibilités de l’OS, ca se gère très bien. L’avantage est de garder la compacité du PI.
En réalité, utiliser la couche simplifiée SCSI/SATA sur USB (l’usb-storage de Linux, ici) n’est pas forcément mieux quand on sort de son cadre d’utilisation classique: Un média extractible.
Tous ceux qui l’ont utilisé comme média de boot/permanent par obligation dans l’embarqué (sous la forme de modules eUSB), sur des SoC n’ayant pas de SATA par exemple, te diront que niveau fiabilité ce n’est pas forcément idéal (très dépendant du controleur que l’on a en face, des options de compilation ou patchs noyau appliqués) sauf à aller encore plus loin dans la customisation: Monter tout le FS en DDR par exemple au démarrage, a condition d’en avoir autant que la partition système. Aie!
#45
Mouais … sacré ‘avantage’ en regard de la complexité induite et la ram bouffée.
Je serais curieux de voir tes refs.
#46
Certains d’entre vous on deja testé gladys ?
https://gladysassistant.com/fr/
#47
Je viens de DL & installer jeedom sur mon Pi 3 après 45 min d’install,
et le premier login par defaut,
j’ai une mire de login pour le jeedom market, apparemment impossible à skip.
C’est quoi cette merde, il faut un compte jeedom pour l’utiliser, sérieusement ?