lym a écrit 172 commentaires

Les miens sont devenus grands, majorité depuis 2 mois, mais petits ils ont beaucoup apprécié Ri-Li sur PC en petit jeu simple…

Un autre jeu simple et ludique qui les faisait bien marrer, surtout que l'on y jouait à 2 en alternance, c'est Slingshot (canardage version assistance gravitationnelle ou l'on peut s'amuser… à progressivement trouver les trajectoires les + chiadées pour exploser l'autre!).

Après, en shoot-them-up version pas gore (paintball de minimoys dans des décors de maison/jardins…), en prime jouable sur réseau local quand ils ont eu leur PC: World Of Padman!

Je ne savais pas que CP/M avait besoin d'un boot-loader lui fournissant des services (ces fameuses "interruptions BIOS", pas vraiment au sens matériel mais du nom de l'instruction permettant de les appeler avec leur numéro, correspondant aux system-call actuels des boot sécurisés) pour tout, comme le DOS (tout ce qui tapait dans le matériel y passait: frappes clavier, gestion écran/stockage…).

Car ensuite le duo wintel, qui avait lâché ce fonctionnement (Linux n'en a jamais eu vraiment besoin, sauf récemment avec les services liés aux enclaves sécurisées justement) ayant fait le nid des virus dits de secteur de boot, a été prompt à le remettre avec les runtime services UEFI (sous ensemble des boot services complets, actifs avant le lancement de l'OS, destinés à pouvoir être appelés par l'OS) avec l'arrivée du secure boot (permettant de limiter les risques passés du concept!).

CP/M était d'ailleurs fourni avec mon Amstrad CPC6128 d'ado, qui n'avait pas de BIOS, même si je ne l'ai jamais utilisé pour ma part???

Pour avoir fait du vxWorks sur PowerPC brut de fonderie, on bootait sur une flash NOR sur bus parallèle en raw (pas de FS) et le boot-loader était limité peu ou prou à un fichier assembleur nommé rominit.S, de mémoire!

Bon, ça c’était au début. Bien entendu pour faire un produit commercial derrière on avait voulu un flash file system, même minimaliste, avec une partition active et une backup pour ne pas se planter sur un upgrade foireux (et un système de reset-loop-counter RAZ par une probation en toute fin de boot OS, tout l'applicatif et liens réseau de supervision lancés, qui assurait un swap de partition si ce RLC dépassait 3).

D'où une architecture plus classique de boot loader à 2 niveau avec un premier, non upgradable (en fait, des bugs processeur sur des trucs à initialiser très tôt nous avaient contraints à mettre un mécanisme d'upgrade en place, même si ce fut rare et avec des risques de briquer du matériel déployé) et commun aux 2 partitions, fut un héritier du rominit.S (inits minimales de base et contrôleur DDR) ajoutant la gestion du swap de partition et l'appel à un second niveau, il y en avait 1 binaire en face de chaque partition, incluant le gros des inits matérielles hors DDR et les trucs qui peuvent évoluer avec l'OS ou nécessiter des corrections de bug (reader de file-system utilisé etc…), ainsi qu'un support réseau basique pour le boot TFTP (en développement/fabrication, voir dépannage).

Bon, c'est clairement une simplicité qui se perds avec les mécanismes de boot sécurisés ou on rajoute bien des étages (tournant éventuellement sur des processeurs de service qui ne sont même pas les principaux, contenant les FW de gestion pré-boot, énergie etc) à la fusée qui décolle (ou pas!)…

J'ai longtemps eu un sshd ouvert sur l'extérieur et c'est visiblement une cible très recherchée depuis longtemps. Voir trop pour un outil comme fail2ban.

J'étais donc passé au port-knocking en choisissant une séquence simple et réalisable au besoin sans outil dédié (un triplet de ping uniques): Port/redirection toujours ouverte côté box, ainsi que celle concernant les ports utilisé en stimuli au knockd, ce dernier ouvrant juste le 22 sur la machine à la demande.

Puis Orange m'a un jour passé en IPv6 une nuit sans prévenir… et qq temps après, regardant les logs par hasard, je m'en apercoit car les tentatives de bruteforce ssh avaient repris!

Ce n'était pas qu'un pb de configuration de knockd: Il ne supporte pas IPv6… Et pas trouvé d'alternatives dans les dépôts Debian quand j'avais cherché.

La machine avec un sshd étant un PI qui héberge ma domotique déjà rendue accessible en https (via domaine no-ip et certificat let's encrypt) et ce dernier étant paradoxalement incomparablement moins visé que ssh (pas grand chose en dehors des robots d'indexation des moteurs de recherche qui lâchent l'affaire après lecture du robots.txt ou sur la page de login), ça a fini par un interrupteur virtuel sur la page domotique qui déclenche un script qui ouvre le 22 pour 1 minute sur demande, laissant le temps d’établir une connexion ssh externe.

AMHA, il n'y a guère le choix avec un serveur ssh: Le seul moyen d'avoir la paix c'est d'avoir un moyen adapté à sa situation pour l'ouvrir à la demande… C'est juste trop ciblé et même passer a l'authentification par clef ne résout aucunement la pollution de log et de son LAN par les tentatives.

On peut m’enchaîner les moins sur une opinion assez factuelle, mais les faits sont têtus et leurs conséquences de plus en plus difficiles à cacher, de la Suède (historiquement tolérante, le virage à 180° y est extrêmement brutal) à l’Irlande et la Hollande, sans parler de l'Allemagne malgré les puissants tabous liés à leur triste histoire ; pour bosser avec des polonais et des slovaques, je peux vous dire que tout sera fait pour que nos problèmes n'arrivent jamais chez eux et leur politiques ne pourront pas se confondre dans une compromission intéressée comme ici: Tout se règle de manière conflictuelle avec eux, même des broutilles, c'est leur façon de fonctionner. Les conséquences seraient extrêmement brutales, voir fatales.
L'alternative, c'est une société de pesant flicage pour tous (déjà amorcée) faute d'avoir eu le courage politique de cibler ceux qui posent problème: Du "vivre ensemble" au "fliqué ensemble" en qq sorte.

L'article n'est certes pas exempt de reproches, mais il y a des réalités qui dérangent et sont depuis longtemps prisonnières d'une certaine "bien pensance" distillée par certains élus plus intéressés par leur réélection future que les problèmes du pays: Le PS avait commencé dès les années 80, LFI a repris l'affaire… C'est simple mais quand j'entends le crédo du "vivre ensemble" dans la bouche d'un élu cela ne fait, avec 100% de réussite, que confirmer mes impressions antérieures (qui il préserve en campagne, les raout islamistes permis dans des gymnases/équipements municipaux mis à disposition): A-t'on eu besoin de clamer ces crédos "intégration" et "vivre ensemble" avec les vagues d'immigration précédentes (italiens, portugais, espagnols…)? Non, en qq années ce fut plié et pourtant ils avaient eu aussi leur dose de reproches et d'insultes, y compris leurs enfants à l'école.
Exemple le plus récent, on a mis combien de jour à voir sortir, suite à la descente des charmants garçons de Romans sur Isère qui ont tué un jeune de 16 ans et blessé plusieurs autres personnes, les raisons de leurs actes? Et c'est pas nouveau, ayant habité dans une charmante cité mes 20 premières années j'ai eu l'occasion de voir de très près bien des problèmes monter, hélas sans réaction politique autre que minimiser les problèmes et mettre au ban ceux qui les dénonçaient.
Personnellement, je pense que le pouvoir soigne la presse qui le lui rends bien. En premier lieu avec cet avantage fiscal réservé aux journalistes… Le truc totalement injustifié: Pourquoi cette profession plutôt qu'une autre? Posez vous la question…
Et en face? Bin c'est action=>réaction et comparé aux médias cités Atlantico est loin d'être le pire. Mais il est ici important de ne pas confondre cause et conséquence (et le sens de la flèche).
Il y a un moment ou il faut juste regarder les choses en face, même si cela déplaît. La réaction politique de coller de la prison ferme à l’extrême droite venue manifester est probablement une connerie majeure: On officialise vraiment un 2 poids 2 mesures qui va les alimenter tout en confortant les "tueurs de blancs". Et quand les seconds encouragés à redoubler d'effort vont s'y mettre, vers qui se tourneront les gens car ils se seront préparé à faire face? Il y a un moment ou ce sera "les ennemis de mes ennemis sont mes amis" qui primera…
Les dissolutions promises, comme toujours en pareil cas qqsoit le "bord", ne vont faire que compliquer les choses en invitant leurs activistes non à se ranger mais à passer à 100% dans l'action clandestine.
Et des signaux faibles croissant depuis au moins 10 ans montrent que, comme en Irlande, il y a des gens qui ne comptent pas se laisser faire: Le nombre d'armes de chasse "volées" dans les véhicules par exemple… qui le sont car on les y a laissé "négligemment".
Et quand ce sera le cas, c'est nos dirigeants de ces 3 à 4 dernières décennies qui en porteront la lourde responsabilité, avec ceux qui les auront suivi dans leur stupide aveuglement.

Je dirais même que le plus rentable est sans doute pour ceux qui consomment peu et n'y pensent pas!

Qqun qui chauffe/cuisine au gaz, même s'il a un ballon électrique qui sera probablement déjà sur les HC, va payer beaucoup moins cher sans même devoir changer ses habitudes: Tout bénéf sans même les emmerdes, contrairement à celui qui se chauffe électrique et aura besoin d'un mode de chauffage secondaire (poelle/insert… donc un investissement conséquent si pas déjà installé, s'emmerder à un approvisionnement/manutention et pour le bois c'est une contrainte pas anodine).

Je pense que le différentiel d'abonnement entre Tempo et un HP/HC classique voir base est pour eux rentabilisé très vite à la consommation. Et ne parlons pas du prix plancher du MWh acté à 70€ par Le Maire (qui nous explique, en évoquant juste la modération côté prix plafond, que ce sera "indolore" vs les ~40€ nucléaire actuel ou tombe le gros de notre production annuelle) qui arrivera pour 2026 et va faire plus mal côté kWh qu'abonnement.

Le seul truc potentiellement un peu chiant, c'est de ne plus avoir le choix des horaires HC: C'est obligatoirement 22h/6h en Tempo.

En particulier, ceux qui ont un abonnement HP/HC heures méridiennes (toujours 8h d'HC globales par 24h, mais fractionnées 5+3 avec 3h l'après midi), peuvent devoir faire un peu mieux leurs calculs selon leurs usages: Quand j'étais en appartement, les machines à laver étaient par exemple inenvisageables la nuit avec le bruit à l'essorage et j'étais content de pouvoir coller cela en HC de 14h à 17h… En maison, ca tourne la nuit sans générer de nuisances vers les chambres à l'étage ou un voisin du dessous.

Mais bon, ces formules heures méridiennes ne semblent plus proposées, Enedis devant être plus au taquet qu'avant en milieu d'après midi côté production/distribution. Elles ne concernent donc plus que d'anciens abonnements.

Idem: j'utilise la première API, en test depuis qq mois (passage Tempo en avril dernier), pour gérer automatiquement ma domotique (essentiellement, m'avertir et commuter un peu avant 22h, juste avant les premiers ordres, un planning jours rouges afin de limiter en gros le chauffage en heures pleines au sèche serviettes de la SdB… et renforcer le planning chauffe nocturne en heures creuses). Je ne suis strict que sur HP/Rouge (chauffage elec, là y'a intérêt à faire journée bois/insert!), en blanc ça sera du "best-effort" si je peux anticiper un truc la veille car le tarif reste assez intéressant pour pas se mettre trop la rate au court-bouillon.

C'est MAJ peu après 11h, vers 11h03, toujours avant 11h10 à l'exception notable du passage heure d'hiver récent ou ca a été fait en début d'a.m.

Mon script (Lua, j'utilise Domoticz) tente toutes les 10mn à partir de 11h si dernière MAJ date de plus de 12h, jusque 16h max… mais s'arrête en fait dès que couleur J1 != NON_DEFINI. A 11h c'est ainsi, à 11h10 on a TEMPO_(BLEU||BLANC||ROUGE) donc ca se limite à 2 essais normalement. Doit bien y avoir des quotas sur leur API…

Ceux qui ont un module téléinfo sur le compteur ont l'info plus tard, a 20h00. C'est sans doute l'info la plus fiable, même si aucun gag jusque là avec leur API http/json, mais le défaut c'est que si on veut anticiper un gros consommateur (Lave/sèche linge, charger son mixer VE…) a 20h c'est bien tard comparé à 11h!

Enedis a aussi son API qui donne accès dès 10h00, donc encore un peu plus tôt, mais il faut un compte/s'authentifier donc plus pénible à scripter… un peu dommage pour de l'info ouverte que l'on veut diffuser sans entraves.

J'en reste donc à la version EDF.

1) La syntaxe est simple et permet bcp de liberté, car il y a des fois ou cela sert, même si cela peut-être source d'erreurs. Et en python, ne pas avoir d'opérateur ternaire pour un language qui se veut lisible, quand on parle du non sujet des concours de C illisible, c'est ce que j'appelle un sacré manque. Et un manque total de cohérence pour vous.
On pourrait ajouter les solutions cornecul nécessaires en Python pour pallier à l’absence de variables static, quand on fait du procédural… Pénible. Comme a été pénible de se passer 2 décennies d'un switch/case!

2) Non. Mais écrire cela situe tout de suite a qui on a affaire.

3) Oui, mais c'est comparativement rare et les librairies système n'ont aucune chance d'être concernées. Les histoire d'ABI, c'est un simple pb de cohérence du système de build et pas de sources (sauf quand on se lie à des trucs non libres, genre gnu-efi bien obligé de se fader une rupture d'ABI en appelant des services BIOS à coups de wrapper basé sur des listes variables d'arguments, dont tu me diras qu'ils sont aussi source d'erreur car le précompilateur ne peut faire aucune vérification des arguments: OK, mais va dire merci à Intel/Microsoft/AMI/Insyde/Phoenix & co).

4) Et le print et la division et les changements dans les librairies standards… Tu en devance certains à la relecture ou d'un pylint mais il reste combien de merdes tordues que tu vas te prendre, à l'execution, parfois des semaines après car tu passes pas souvent dans la branche de code concernée (et/ou pas facilement testable). Le problème de python, c'est comme souvent les loupés dans la définition initiale et plus un langage est riche plus on en aura.

5) Pour faire la boucle avec le sujet de l'article: S'il n'y avait pas ces problème omniprésents côté python, on n'aurait pas besoin de venv & co!

"Honnêtement, je suis assez surpris que tu puisses trouver le C simple à apprendre"

Il n'y a pourtant qu'a mesurer l'épaisseur d'ouvrages traitant du python à un K&R. Et comme avec tout langage capable de tout faire d'un boot loader à l'OS et son applicatif, forcément on est un peu moins à utiliser trop de dépendances évitables qui à mon sens peuvent vite devenir problématiques avec python (entre autres).

Le C est vraiment simplissime comparé à python niveau syntaxe, ce qui ne veut pas dire que coder un truc (à condition que ce soit possible dans les 2 langages) soit plus rapide/facile en C, surtout si une librairie évite de réinventer la roue. Par contre le lien perdu avec la donnée à traiter peut rendre les choses peu évidentes en python même dans de l'applicatif à mon sens. Puis si l'auteur de la dite librairie abandonne sa maintenance, vogue la (plus souvent les) galère(s) avec un langage qui n'a jamais brillé pour sa compatibilité ascendante (cf passage de python 2 à 3) et ne va donc pas permettre d'éviter des problèmes de moyen terme: On pensait avoir un truc de quelques milliers de lignes python à maintenir reposant sur des librairies maintenues… et on se retrouve à devoir maintenir des dizaines de milliers de lignes de code plus maintenu écrit par d'autres, refaire la partie que l'on utilisait from scratch voir continuer les cochonneries avec un wrapper sur une lib alternative maintenue (pour combien de temps?)…

… ce que sont les coroutines, une implémentation en C avec explications:
https://github.com/Rachid-Koucha/crtn

Le langage Python, avec son écrasante popularité (premier au classement TIOBE), est vanté pour sa simplicité.

Pardon? D'aucuns et pas des manches trouvent le C++ (pour en rester aux langages objet) bien plus simple que Python qui est tout sauf un langage simple. Sauf à confondre simple et lisible (même pour le néophyte s'il est anglophone, mais de là à lui faire prendre le clavier…), à la limite!

Le C est incomparablement plus simple (niveau grammaire) à apprendre que Python et c'est souvent le cas dans les langages interprétés évolués pour ne pas avoir des performances trop altérées (on complexifie la grammaire pour maximiser ce qui tournera direct dans l'interpréteur/en natif).

Sinon, il y a la possibilité d'en rester (surtout pour ses scripts perso) au python de sa distribution et aux librairies quelle maintient qui s'installent d'un "apt install python-XXX".

Ma Debian 12 offre quand même 831 paquets à ce rayon.

Et en prime, même si cela n'évite pas un tri ajouté, les dépendances qui ont justifié un mainteneur ont des chances d'être maintenues dans le temps.

Plus de venv, ni même de pip… et moins de problèmes à mon sens.

Il est pourtant clair: Quand on commence à avoir besoin d'un foutoir de conteneurs pour faire coucher un truc codé quick&dirty reposant sur des dépendances tenant de l'alignement des planètes, avec ses semblables… Y'a un moment ou coller les machines les unes a côté des autres, chacune avec son applicatif et son environnement cornecul, n'est peut-être pas moins bête!

Un vélo utilisable pour moi c'est un vélo à 2 roues (certains cargo sont tricycles) car cela reste pas trop large et adapté aux infra existantes.

En prime ça penche dans les virages, ce qui à la fois plus fun et est moins désagréable à vivre (pas d'accélérations latérales).

Je n'aime personnellement pas trop le concept du vélo couché même si je vois bien l'avantage aérodynamique sur longues distances et pas trop de relief (exit la "danseuse") pour 2 raisons principales:
-Visibilité surtout si trafic et des 2 côtés (cycliste couché plus près du sol et autres véhicules ou on est plus facilement masqué et c'est pas un petit drapeau en hauteur qui change grand chose).
-En cas d'accident, on est en prime avec les zones vitales (tronc/tête) pile à la hauteur qui va prendre de plein fouet. A vélo c'est les jambes.

Quand je dis à 2 roues, j'avoue que dans un registre opposé au SUC (version cycle du SUV) de l'article je pense qu'il y aurait un créneau intéressant pour une revisite du monocycle, version électrique, permise par les technos actuelles.

Il y aurait en effet la possibilité d'en faire des VAE monocycles gyrostabilisés (comme les gyroroues, mais avec un avantage réglementaire intéressant chez nous, cf la suite) pour les sortir du rayon "vélo de cirque" et les rendre accessibles à beaucoup plus de monde.

L'avantage principal, c'est le côté assisté qui les ferait tomber dans la catégorie VAE et non EPDM (donc, réglementairement, assurance spécifique obligatoire contrairement aux vélos!) avec l'avantage propre à ces derniers jusque là d'un encombrement minimal qui le rendrait intéressant pour une bonne partie de la clientèle trottinette électrique actuelle et une plus grande roue qui rends moins sensible à la moindre irrégularité de chaussée.

La raison pour laquelle ce n'est pas encore fait, à mon sens, c'est que l'intérêt est directement lié à la réglementation française… Et que l'on n'a plus beaucoup de fabricants de vélo nationaux pouvant viser un marché uniquement national.

Visiblement, waypipe ne s'utilise pas vraiment avec la même souplesse que le ssh -X (ou -XC pour avoir aussi la compression à la volée depuis des lustres).

De ce que j'en comprends, on préfixe d'un "waypipe" chaque commande/applicatif distant lancé via un ssh. Donc au lieu de tout qui passe dans un tunnel via une unique connexion initiale, on se retrouve a en faire une par commande/applicatif.

C'est certes mieux que rien, mais n'est-ce pas une verrue de transition appelée à disparaître tandis que toujours rien n'est fait au coeur de wayland pour simplement égaler l'ancêtre dénigré construit autour de l'usage réseau?!!

Niveau "usage en voie de disparition", je dirais que c'est le contraire:
-Entre le milieu des années 90 quand j'ai commencé ma vie professionnelle et la seconde moitié de la décennie 2000, j'ai eu 2 machines physiques sur mon bureau (une Sun pour le developpement, un PC windows pour mail/bureautique) puis un seul PC fixe Linux (usage dev replacant la Sun)+VM windows (bureautique).
-Ensuite, jusque mi décennie 2010, j'ai eu un PC fixe Linux pour le dev + laptop windows (bureautique+dev en télétravail sur le fixe au bureau via Cygwin/X).
-Depuis, c'est laptop windows et dev sur des VM sur serveurs Linux partagés maousse costauds, utilisées à travers du VNC ou du X11 selon les préférences utilisateurs (perso, je suis resté à X11 à travers ssh car chaque fenêtre s'intègre mieux au DE client qu'avoir deux DE disjoints).

=> Le cas d'usage distant s'est juste généralisé en une dizaine d'années et le coeur de wayland passe toujours outre! Comment dire…

Je ne voit pas ou est le mensonge à souligner que wayland n'est pas conçu avec un usage réseau en tête. Que des verrues de compatibilité/transition aient été ajoutées côté client, fort bien, mais cela ne résout pas le pb qui va se poser à terme quand X11 va fatalement tomber en désuétude, côté serveur et applicatif cette fois.

Passer a côté d'un usage réseau pré-existant actuellement, c'est quand même pas un coup de génie…

Faudrait que je demande à ma femme, c'est elle qui est chez Airbus, mais à chaque retour de vacances je l'entends pester de ne pas pouvoir prioriser ses lectures dans la tétrachiée de mails reçus comme elle l'entends: Il me semble qu'un simple classement par expéditeur est impossible…
En tout cas tout le monde regrette Outlook.

Pour le chauffage, je dirais que l'électrique a un seul avantage par rapport à un chauffage central c'est de pouvoir mieux gérer par pièces (y compris allumage ou non, par exemple à mi-saison on peut n'avoir besoin que de chauffer la SdB ce qui n'est pas vraiment possible avec un circuit eau-chaude global qui en laisse toujours un peu passer via les canalisations même radiateurs fermés).

Au delà, faut pas laisser trop tomber sous 15/16°C (sauf vacances ou c'est HG, à 7°C, mais même sur 1 semaine de vacances en février ça descend pas en dessous de 10°C) mais de toutes manières l'isolation n'étant pas si mauvaise il faudrait une journée sans chauffe par des températures très hivernales en grande banlieue parisienne pour y tomber et cela se justifie plus pour éviter des désordres (humidité…) qu'autre chose.

Pour le reste, la perte étant proportionnelle au différentiel intérieur/extérieur, j'avoue avoir du mal à comprendre le credo du "si on laisse tomber trop bas, on perds à la remontée ce qu'on a gagné à laisser baisser": Bin non! Laisser une consigne à 17 alors qu'on pourrait laisser tomber sur la pente naturelle un peu plus bas c'est des pertes en plus sur les heures ou on descend à cette consigne maintenue.

Pour en revenir à gérer par pièces, j'ai voulu garder cette spécificité. Surtout que j'avais immédiatement changé les "grille-pains" anciens présents et autres rayonnants (à mon sens, cela n'a sa place que pour une SdB de par sa capacité à vous chauffer à travers une paroi de douche… car s'il y a un ouvrant à peu près dans leur axe, on a l'inconvénient de cet avantage et cela chauffe en partie dehors!) bas de gamme.

Pas investi dans des modèles complexes niveau programmation, voulant gérer moi-même: Juste des inertie sèche avec une bonne régulation électronique intégrée et 6 ordres fabriqués en France, achetés en arrivage Brico-Dépot (alors entre 89 et 149€ selon les puissances).

Le but était de conserver cette régulation interne (+calibrée pour leur inertie, pour ce type de radiateurs!) et d'influer sur la consigne de l'extérieur avec le seul truc commun obligatoire: Le fil-pilote (FP), qui va permettre à partir d'une consigne de base dite "confort" de gérer au moins, par ordre d'offset à la baisse vs consigne locale confort, confort-1 ou -2 (2 ordres facultatifs mais présents sur des modèles pas trop anciens), éco (en général confort-3), hors-gel (7°C en fait) et off: 4 à 6 ordres donc.

A ce bon deal de "radiateurs cons" (vs les "intelligents" vendus une blinde avec souvent des gestions propriétaires cornecul en prime!) mais néanmoins qualitatifs, j'avais ajouté pour alors ~40€/radiateur des modules FP 6 ordres en radio zwave (comme souvent, les FP n'étaient hélas pas tirés jusqu'au tableau) tenant dans les boites d'encastrement des branchements.

Bref, in-fine, c'est très simple à gérer (essentiellement par planning optimisant les heures-creuses… et switch de planning présence/vacance et désormais jours rouges tempo selon l'occupation/tarifs énergétiques). Et si je dois remplacer un modèle, la commande restera identique aux autres.

Le reste est de l'adaptatif selon qui est présent (smartphone de qui réponds en BT, utilisant celui intégré au PI3B, plus fiable à l'usage que wifi très ciblé par les stratégies d'économie d'énergie des mobiles et suffisant en portée dans ma maison) et capteurs de mouvements pour certaines pièces servant aussi à l'alarme.

Cela laisse aussi la liberté de régler les consigne confort localement, selon la pièce/occupant (chambres), qui sera juste altérée sur les principes généraux ci-dessus. Et évite aussi de rajouter des composants de puissance (le FP est une entrée haute impédance), leurs bruits de relais ajoutés potentiels (chambres) + capteurs de T dans chaque pièce en régulant de dehors.

Ayant aussi un insert, les plannings chauffe se retrouvent invalidés quand il est utilisé et ensuite tant que la température n'est pas descendue sous un seuil (il a beaucoup de maçonnerie autour et restitue 6 à 10h après la fin de combustion selon la durée de fonctionnement).

Bref, rien de chiadé de ce côté chauffage (y'a pire ailleurs niveau cams IP par exemple). A l'usage c'est suffisant et a rapidement rentabilisé le matériel à comparer mes factures et celles de mes voisins (lotissement donc bcp de maisons similaires).

Niveau énergie, j'ai aussi un module compteur installé en tête de tableau qui inclus une commande de relais externe. Au delà d'avoir de belles courbes de conso permettant de valider ses stratégies d'optimisation des heures-creuses, cette commande (relais statique pour faible ampérage de commande adapté ici) est mise en série avec la commande du relais heures-creuses venant du compteur EDF.

L’intérêt étant qu'en plus du chauffage, la mise en route du ballon ECS en heures-creuses peut aussi être ou non activée.

Pratique, avec deux simples plannings normal/absence de pouvoir à la veille d'un retour de vacances remettre à distance le planning normal et d'avoir la maison à température et de l'eau chaude en arrivant.

Le webmail reste une solution de dépannage: Possibilités de tri/recherche limitées, archivage local même pas en rêve, aucune possibilité d’agréger plusieurs adresses des fournisseurs de son choix.

Voir dire qu'avoir construit un support graphique traversé par le réseau depuis les origines était mauvais tout en trouvant élégant de se retrouver avec un usage autour d'un navigateur faisant office de minitel moderne, cela manque à mon sens un peu de cohérence!

Des boites comme Airbus qui ont tout foutu chez Google côté bureautique et mail (sans permettre le smtp/imap et imposant le webmail) connaissent de gros problèmes induits par ces choix stupides: Des fonctionnalités de classement simple existant dans le plus basique des client mails sont absentes! Merci Enders…

Un RDP, au moins à chaque fois que j'en ai utilisé, tire un bureau complet… d'une machine distance ayant… un DE complet!

J'utilise pour ma part beaucoup le "ssh -X" pour un peu de dev/configuration sur des machines headless sur lesquelles un DE complet autant qu'inutile n'est pas installé.

Le combo xvfb/rxvt-unicode/nedit permettant de travailler relativement confortablement dans ce type de cadre sans devoir coller trop de mauvaise graisse sur une installation voulue minimale, n'a a mon sens pas de remplaçant avec Wayland. C'est ballot.

Au pire, je pourrais m'en passer. Mais je n'appellerais pas vraiment cela un progrès, plutôt une régression.

Pas que le gaming si je n'ai rien loupé: Les utilisateurs du "ssh -X …" ne sont pas des gamers et vont pleurer.

C'est pourtant bien pratique et évite de traîner des sessions distantes complètes (RDP/VNC) tout en s'intégrant nativement dans l'environnement graphique du client. Même face à un système headless/embarqué plus minimaliste, donc sans DE, le paquet X11 frame buffer (xvfb sur Debian&Co) permet de travailler en graphique plus confortablement sans alourdissement excessif (à condition d'éviter tout applicatif qui va tirer l'essentiel des dépendances d'un Gnome ou d'un KDE).

Des cas d'usage négligés (voir méprisés) depuis les origines par les développeurs de Wayland hélas!

Personnellement, j'ai du mal à voir le progrès d'un support graphique passant à côté du réseau. Encore plus à voir critiquer l'ancêtre quand on s'assied, à l'heure actuelle, là dessus.

Pas forcément un problème, si on a un proche/voisin qui passe tous les jours pour la gamelle et vérifier que tout va bien… et qu'ils ont de quoi s'abriter.
Y'a certains animaux assez casaniers/territoriaux qui sont bien plus perturbés par un changement d'environnement temporaire pour les vacances que rester, même seuls, chez eux.
Des chats vivant beaucoup dehors n'apprécient vraiment pas de se retrouver enfermés dans une loc de vacance par exemple. Et pire que des chiens, s'ils arrivent à profiter d'une négligence pour se tirer les retrouver peut être compliqué.

Pauvre bête!

Pour ma part, ayant démarré avec Domoticz pour gérer la baraque tout juste achetée il y a 7 ans et le gros consommateur que représente un chauffage tout électrique… j'avais rapidement étendu à l'alarme même si c'est normalement pas le même rayon.

L'avantage, c'est que les capteurs de mouvements qui peuvent servir à déterminer si une pièce est vide/occupée et adapter chauffage et autre en conséquence peuvent aussi servir à l'alarme.

Par contre, rien n'est dispo de base… mais ce soft domoticz était (et reste probablement, avec les ajouts de python et plugins depuis) le plus complet en matière de possibilités de script intégrée (blockly, pour des trucs simples en mode newbie que j'ai pas utilisé. Et surtout Lua, pour des choses plus chiadées).

J'ai donc codé le coeur de mon truc en Lua, de manière assez générique (utilisant un prefixage/convention de nommage selon le type de capteur et/ou localisation intérieure extérieure déterminant les poids de base, cf la suite, ce qui permet une intégration de nouveaux sans changer son code tant qu'on respecte la convention de nommage) et utilisant un système de poids additionnés sur une minute glissante.

Grossièrement, un capteur intérieur va avoir un poids déclenchant l'alarme longue (cf la suite) immédiatement et un capteur extérieur ce sera une fraction du seuil d'alarme courte (i.e. plusieurs déclenchements d'un même capteur et/ou de plusieurs requis pour que cela commence à sonner court, puis long si ca insiste).

Ce cumul est comparé à 2 seuils: Alarme courte déclenchant sirènes pour 5 secondes sans notifications (manière de signifier à un intrus n'ayant déclenché que des capteurs externes qu'il a été vu, sans emmerder le voisinage avec une sirène qui sonne longtemps sur le faux positif d'un chat qui passe). Puis alarme longue pour 5 minutes renouvelées au besoin.

Le but étant que cela s'arrête avant même qu'un volet/porte/fenêtre soit forcé, car ensuite en qq minutes c'est foutu donc sonner sur ouverture/capteur intérieur qui tilte insuffisant.

Au début, je n'avais que des capteurs réels (PIR, installés en intérieur et extérieur ou capteurs d'ouverture). J'ai depuis cumulé avec des caméras IP (modèles Dahua peu chers mais complets avec des sensi nocturnes bonnes, installés en extérieur et garage uniquement).

Pour les intégrer, domoticz permet un truc pas mal: La possibilité de faire des switchs/senseurs virtuels! L'intégration est alors aisée: On fait des PIR virtuels qui sont déclenchés quand les caméras génèrent des captures via leur motion intégré.

Ici c'est un service écrit en python (j'aime pas trop ce langage, mais la richesse des imports m'a permis de faire pas mal de choses que je ne détaillerais pas niveau traitement des captures, envois notifs/mails) qui surveille le FTP des caméras toutes les 5 secondes et "déclenche" les PIR virtuels via l'API HTTP/JSON fournie par Domoticz.

J'ai d'ailleurs d'autres services en python s'intégrant ainsi à Domoticz, pas écrits sous forme plugin (je les ai écrit avant que les plugins n'existent): Détection de qui est présent/absent via le BT des smartphones (permet de pallier aux oublis d'activation alarme des enfants en sortant, sachant qu'ils n'oublient jamais leurs téléphones!), filtrage (par décroché/raccroché) du spam téléphonique recyclant un vieux modem voix USB avec la fonctionnalité caller ID.

L'avantage des plugins, c'est que cela intègre les interactions sans devoir passer par l'API HTTP/JSON et la génération d'une page de cconfiguration directement intégrée à l'UI domoticz tandis que je gère mes fichier yml séparés.

Niveaux interactions externes, il y a le support https (via domaine no-ip+certif let's encrypt pour moi) pour l'interface… basique vs d'autres solutions mais efficace et fonctionnant bien même sur un mobile Android pas bien véloce. Permettant aussi de servir ses propres "custom pages" au besoin (mes services python cam IP et filtrage tél en génèrent d'assez simples via yattag par exemple: Assemblage des dernières captures cam permettant une levée de doute rapide et peu gourmande en bande passante, qui fonctionnera même sur un AP surchargé de loc de vacances au besoin d'un côté ; liste d'appelants+raison filtrage éventuel de l'autre) pour ajouter ce qui peut manquer.

=> Il faut se retrousser les manches, car au delà de l'intégration du matériel et gérer les protocoles de com courants en domotique + gestion des évènements associés et présentation (fixe+mobile) il n'y a pas grand chose (mais c'est déjà un gros morceau!)… mais les possibilités de script bien foutues/intégrées + API externes offrent une grande liberté permettant de faire des trucs qu'on ne trouverait pas dans le commerce: Une solution plus Geek que Michu.

Niveau script, j'ai appris à apprécier Lua car il est stable et me fout une paix royale (coucou Python!): Une seule ligne à modifier en 7 ans sur une MAJ domoticz qui incluait un upgrade de l'interpréteur Lua intégré. Les déclencheurs type time (toute les minutes) ou device (un changement d'état sur un interrupteur/capteur…) sont suffisants et l'interaction avec les états/séquenceur d'event bien foutue à partie de tables prise à l'appel/modifiée par le script/restituées en sortie pour déclencher les actions…

Au dessus de Lua, il y a un dérivé spécifique nommé dzVent: Arrivé après que j'ai écrit l'essentiel de mes besoins, pas utilisé mais apprécié de la majorité des utilisateurs.

Et Python (dispo en plus du reste niveau scripts depuis ~3ans, passage obligé pour les plugins): Je conseillerais pour ma part d'en rester à Lua/dzVent côté scripts (stabilité, quasi impossibilité de planter Domoticz avec une erreur dans un script ce qui n'est pas le cas de Python) plutôt que Python (sauf besoin plugin).

2 possibilités pour écrire les scripts: Intégrée à l'UI ou pas (fichier dans domoticz/script/lua par exemple, respectant la convention de nommage selon déclencheur time|device). Je conseille la seconde, car si par malheur un script plante Domoticz dans le 1er cas il est sauvegardé dans la BDD de domoticz. Pouvoir redémarrer n'est alors pas aussi simple que le faire après avoir bougé/renommé le fichier problématique car il faut éditer la BDD ou relancer domoticz manuellement, event system désactivé, pour pouvoir virer ou éditer le script problématique. Par contre, en cas de réinstallation complète, il faut penser à récupérer ses scripts en plus de la seule BDD.

C'est aussi la seule solution codée en C++ et (cross-)compilée native donc fatalement plus économe en ressources que des Jeedom/Home-Assistant… La seule vraie verrue qui m'emmerde (mais ce sera aussi le cas ailleurs), c'est la gestion zwave qui arrive: OpenZWave (librairie C++, la stable 2023.2 domoticz est la dernière à l'intégrer) étant abandonné/déprécié, il faut en passer par le genre de tas de merde "moderne" qui m'exaspère: zwavejs.

Que des mecs aient pu écrire un truc destiné à gérer du matériel (à travers une pseudo liaison série pour gérer le protocole radio derrière) en javascript, obligeant à traîner un interpréteur de plus, ses dépendances, pour conseiller en plus de coller cela en conteneur car satisfaire ces dépendances avec des OS variables tiens de l'alignement des planètes… puis interfacer cela en MQTT (un serveur à ajouter doublonnant l'event system intégré) à un auto-discovery côté domoticz.

Bonjour la prise de tête vs un truc intégré jusque là nativement.

Mon conseil pour qqun qui démarre: Partir sur du zigbee (même type de réseau radio maillé basse conso, même si en 2.4GHz plus chargé que le 868MHz, périphériques ayant un minimum d'intelligence via configuration), même s'il faut faire attention à ce qu'on achète car l'interopérabilité entre fabricants n'est pas au niveau de ce qu'imposait zwave (c'est moins cher, mais pas de process de certification assurant l'intéropérabilité en zigbee!). On a un plugin ZigbeeForDomoticz qui permet d'éviter MQTT&Co écrit en python et bien suivi.