[Présentation] Benj29 et blog Jeedom-Facile

Bon déjà j’ai avancé avec traccar, je viens de me rendre compte que le périmètre virtuel se créé côté jeedom que quand on rentre ou on sort du périmètre. Du coup j’ai la remonté d’info si je suis au travail ou à la maison.

Oui, je te confirme qu’il faut faire des mouvements sur la zone pour chaque zone passe à 0 et 1.
Qu’as tu comme autre souci ?

Pour ma part, j’ai du mettre des zones très grandes côté traccar pour être dans la zone car il travaille sur une zone.

Côté macrodroid, par contre, j’utilise geofence (et non pas les antennes relais qui ont trop de sensibilité).

Par contre, je n’utilise PAS Traccar pour piloter ma présence. Uniquement geoloc via macrodroid ; bien plus fiable.

Un refresh toutes les 30min en extérieur est suffisant.

Bon sinon, j’ai commandé un modem routeur 4G, je vais tenter de supprimer JPI côté téléphone et mettre en place la balance SMS JPI en utilisant ce modem routeur.

Je vais perdre les intéractions SMS je pense, mais si j’ai toujours une connexion 4G, l’étape d’après, va être de mettre en place un système de notification type Telegram mais autohébergé.

Bon j’ai pris celui là, moins cher (75e contre 122e le tien). J’ai d’abord cru que c’était 4G pas + mais la description est fausse :

De toutes les façons, j’ai deux asus derrière qui gère très bien le réseau de la maison (aimesh + gros bébé GT5300) ; celui là ne fera que modem routeur en basculement.
https://amzn.to/3Nd2wzL

Côté PV routeur, par contre, je trouve la fiabilité très mauvaise.
La carte ESP a cramé après une mise à jour, l’écran est mort et plus de remontée.
Moyen moyen. L’autre que j’avais prise en backup refuse de démarrer, elle se met en court circuit.
Ces chinoiseries, quand tu en as une de bonne, faut la garder et plus la toucher.

J’ai prévu quelques modifications :

  • ajout de 2 shelly 2.5pm ; il faut que je vois si je peux virer les contacteurs et tout faire passer par les shelly :
    Amazon.fr
  • ajout de ventilateurs en vitesse basse et grosse brassage 12cm
    Amazon.fr
  • ajout d’un port usb double pour alimentation dont je piloterai l’alimentation pour les ventilos que quand les dimmers tourneront.
    Amazon.fr

je suis content que tu es investi dans un routeur 4G, tu va revivre!
concernant traccar et macrodroid, je pense que mon principal problème est que je travaille à moins de 3km et 2 mn de trajet de mon domicile.J’ai pas encore testé l’ouverture de mon portail quand j’arrive alors que je peux être sujet a passer plusieurs fois devant chez moi dans le cadre de mon travail en espérant que mon portail ne s’ouvrira pas

Bonjour,

Juste pour gerer la présence, tu peux utiliser les appli Jeemate ou jeedomconnect (GPS ou geofence) et tu auras les infos dans jeedom que tu veux avec la précision que tu veux…

Tu n’auras jamais la précision que tu souhaites !
Il vaut mieux que tu t’appuies sur un nut pour l’ouverture de ton portail (clé de voiture) que tu ne prends pas quand tu fais ce trajet par exemple.

1 « J'aime »

Personnellement, je n’ai pas souhaité.
Ces applications évoluent en permanence et au final, on veut quelque chose de on ne peut plus simple.
Juste envie une lat/long depuis un tél sur un virtuel.
Derrière l’affichage carte n’est qu’un widget à appliquer sur un virtuel. Et aucun problème de fiabilité à avoir.
Et cela laisse bien plus de liberté sur les possibilités d’envoi : entrée, sortie, répétition toutes les X min dehors ; Y min dedans sur wifi ; condition spéciale si travail, étranger etc.

Je fais exactement tout ce que tu dis avec uniquement la lat/long qui vient de mon tel (je le faisais avant avec l’appli officielle jeedom) et ça fait 2 ans que ça fonctionne très bien…
Et en faisant ainsi, pas besoin de nut et/ou wifi et @Chris13 aura la précision qu’il souhaite :wink:.
Pour les cartes, je ne m’en sers pas trop, c’est plus pour vérifier qu’il n’y a pas de points aberrants etc…

La précision GPS n’a rien à voir avec l’application.
Je te « défie » (sans aucune méchanceté) de mettre 1m pour ouvrir ton portail en précision et de voir si ça détecte par geofence. Le push de geofence est propre à google et n’a rien à avoir avec l’application.
Ma remarque est plus sur le fait que ces applications demandent des mises à jour, des alignements sur les plugins etc. Par macrodroid ou tasker, cela fait 5 ans que ça tourne et je ne touche rien.

Bon des fois, vaut mieux en rire.
Erreur de sélection dans le build, tout est OK et fonctionnel.

J’ai reçu mon routeur, 4G en place.
J’ai limité la bande passante à 512 Kbits ; ça suffira.
Du coup, j’ai mis en place l’envoi des SMS par script, et j’ai basculé JPI vers le routeur 4G.
Prochaine étape, recevoir les SMS et les traiter.
Avec ça, le téléphone JPI peut sauter.

Et voilà, enfin fini.

Non sans mal, et faute de plus de temps, il m’aura fallu quand même presque 1 mois et demi pour tout mettre en place. Mais comme j’aime, propre et parfaitement fonctionnel. Avec quelques stats.

Le restant de la production solaire est renvoyé sur le ballon d’eau chaude.

2 dimmers (1 seul est réellement utilisé pour l’instant car la toiture n’est pas suffisante pour tout couvrir maison, piscine et eau chaude) ; 2 mitigeurs installés sur le LV (on met bien moins de temps pour chauffer de 38 à 60/70°C par condensation) ; sur le LL (on lave à « froid », plus de résistance dans la courbe de charge !).

1 sonoff qui sert pour la reprise de la température la nuit ou sur des conditions de météo défavorables le lendemain.

1 ballon de 2400W de 3 résistances, modifié en 3 résistances pour 800W (840W chacune dans les faits).

1 carte ACI (qui bloque si le ballon arrive à 65°C) dont le câblage fil est modifié (pour être remis rapidement d’origine).

Je m’appuie aussi sur la protection des dimmers à 65°C (merci à Clyric de l’APER). J’ai ajouté une mesure par DS18B20 de la température dans le boitier et une ventilo 12cm en vitesse « lente » qui me maintient un 20/25°C max même quand j’ai 1500W !

Dans le principe, le sonoff, les dimmers prennent l’alimentation 220V du tableau élec sur la voie eau chaude (20A). Leurs sorties sont renvoyées sur des contacteurs qui alimentent les résistances. Un shelly reçoit la sortie de la carte ACI (220V quand la température est < 65°C) sur son entrée SW1. Donc par défaut, la sortie du shelly active les contacteurs (mais bon si le sonoff ou les dimmers sont à 0… voir plus bas). Si par contre, le ballon atteint les 65°C et pour une raison ou une autre il continue de chauffer, l’alimentation SW1 va se couper ; dévalidant O1 et donc les contacteurs ; CQFD.

En parallèle, un petit scénario pour piloter tout ça côté domotique. Pour rappel, les dimmers ont en interne une gestion qui stoppe la chauffe si la température de la sonde dallas dans le ballon atteint 65°C.

Donc 3 parachutes au total… car j’ajoute la couche avec jeedom. Les dimmers, routeur PV envoient en MQTT les infos.

Et bein ça donne ça :

Le routeur PV dans le garage :

Le cumulus modifié (1 résistance pour chaque dimmer ; 1 pour le sonoff ; la carte ACI en amont qui fournit l’alimentation ; la sortie ACI qui est piloté par le shelly pour les contacteurs).

Côté jeedom :

Un scénario qui décide la ventilation. Pour rappel, à la mise en marche, ce sera forcément activé … par sécurité en ventilation avant que le scénario prenne le relais. J’ai observé que le shelly peut être lent (quelques secondes) donc un petit refresh en tête de scénario. Il se déclenche sur le % des dimmers, la température du ballon, l’état du relais.

Dans les designs pour faire sympa (aujourd’hui a été une journée moche… donc rien sur les dimmers). D’où le 0.3% pour une consigne max à 65°C ; et 6.6h de chauffe sur la journée/nuit. A noter que le coût mensuel est celui TOTAL (donc production ou consommation de nuit).

Un petit widget au clic où je garde la gestion de nuit (que je peux déroger si absence ou que je peux forcer en journée si plus d’eau chaude…). Les efficacités sont encore très faibles car en marche depuis 3/4 jours … à moitié en plus.

Sinon, je valide une consigne la nuit pour le lendemain pour être sûr d’avoir de l’eau chaude le lendemain ; pour l’heure… :

  • si présence d’ami : 50 ou 60°C (si prévision météo bonne ou mauvaise)
  • si famille normale : 40 ou 50°C (si prévision météo bonne ou mauvaise).
    Donc si journée belle et que l’eau est encore à 40 ; pas besoin de chauffer de nuit. A affiner dans le temps et quand la toiture sera doublée…

Côté jeedom au démarrage, simple protection, je relance le scénario de ventilation / contacteur ACI et je coupe le sonoff de chauffe (le plugin chauffe-eau répète la commande en cas de problème).

Voilà et ça donne ça : orange (eau chaude) ; bleu (% dimmers) ; vert (température boitier).

4 « J'aime »

Bonjour,

Pour être transparent, et suite à un échange avec un modérateur, il m’est demandé de ne plus parler de la cagnotte et des dons par respect envers les autres sites/blogs.

Pour les nombreux messages reçus par MP, elle est ici :
https://www.leetchi.com/c/jeedom-facile

Je fais ce message suite à plusieurs MP que j’ai eu d’inscrits du forum et j’estime qu’il est normal d’être transparent par respect envers les personnes.

Par conséquent, je ne ferai plus mention du blog ici comme cela m’est demandé.

Aussi, merci de me contacter par MP si vous avez des questions concernant le sujet en cours ; à défaut ; je resterai sur une communication de mon installation ou des changements.

Je me dois de respecter les règles du forum (ce qui ne m’empêche pas d’avoir un avis sur le sujet…).

Rien n’empêche aux jaloux de faire la promo de leur site aussi… Enfin bref…

1 « J'aime »

Il faut respecter, c’est le principe des règles du forum. Même si on n’est pas d’accord.

1 « J'aime »

hello,

Faut que je relise ça plus en détail à tête reposée :wink: :+1:

Quelques ajouts pour finaliser mon installation domotique avec l’ajout des nouveaux panneaux (3.8kWc en toiture contre 1.6kWh) et le routage eau chaude (2 dimmers - puissance variant de 0 à 800W + 1 contacteur on/off pour le jour ou la nuit en fixe à 800W).

De ça :

On passe à ça :

Le boitier de gestion dimmers/contacteur (voir plus haut) :


En résumé :

2 dimmers + 1 sonoff qui sert pour remonter l’eau chaude la nuit si trop basse ou en délestage la journée;

2 mitigeurs installés sur le LV (on met bien moins de temps pour chauffer de 38 à 60/70°C par condensation) ; sur le LL (on lave à « froid », plus de résistance dans la courbe de charge !).

1 sonoff qui sert pour la reprise de la température la nuit ou sur des conditions de météo défavorables le lendemain.

1 ballon de 2400W de 3 résistances, modifié en 3 résistances pour 800W (830/840W chacune dans les faits).

1 carte ACI (qui bloque si le ballon arrive à 65°C) dont le câblage fil est modifié (pour être remis rapidement d’origine).

vu la toiture installée, je ne pourrai jamais avoir plus de 240/250% de routage : soit < 2000W car toiture 3.8kWc / 3kW et j’ai 450/550W de talon.

Dans le principe, le sonoff, les dimmers prennent l’alimentation 220V du tableau élec sur la voie eau chaude (20A). Leurs sorties sont renvoyées sur des contacteurs qui alimentent les résistances. Un shelly reçoit la sortie de la carte ACI (220V quand la température est < 65°C) sur son entrée SW1. Donc par défaut, la sortie du shelly active les contacteurs (mais bon si le sonoff ou les dimmers sont à 0… voir plus bas). Si par contre, le ballon atteint les 65.5°C et pour une raison ou une autre il continue de chauffer, l’alimentation SW1 va se couper ; dévalidant O1 et donc les contacteurs ; CQFD (protection mécanique par la carte ACI ou pilotage par jeedom).

En parallèle, un petit scénario pour piloter tout ça côté domotique. Pour rappel, les dimmers ont en interne une gestion qui stoppe la chauffe si la température de la sonde dallas dans le ballon atteint 65°C ; mais que le premier dimmer.

Donc 3 parachutes au total… car j’ajoute la couche avec jeedom. Les dimmers, routeur PV envoient en MQTT les infos.

A cela, modification du design de suivi de l’énergie et de l’électricité.

Les dimmers pouvant continuer à envoyer une valeur de routage même si le ballon est full, je les filtre si le ballon est full.

Depuis Agrégateurs / DimmerX => Dans Gestion Routage ECS

  • Routage ECS est un binaire qui dit si le routage est cours

  • Cumulus full est un binaire quand le ballon est plein (65.5°C sur hystérésis)

  • Le routage ECS (%) est la somme du contacteur jour (100%) et des 2 dimmers quand le ballon n’est pas full

  • Ppulse ou Routage ECS puissance sont la puissance du compteur pulse de la voie ECS ou l’estimée (8.32 x %total)

  • Dimmer 1 / Dimmer 2 / Contacteur sont les % mises en forme si le ballon n’est pas full

Pour la gestion ON/OFF chauffe (jour ou nuit) un interrupteur pour la journée, un pour la nuit. Et pour éviter les carambolages :

Un scénario Chauffe ON/OFF (jour ou nuit) qui pilote le contacteur de jour ou de nuit.

On active le scénario « répétition » correspondant (toutes les 5min en répétition). Par sécurité timeout sur les scénarios à 30s.

Chaque scénario vérifie que le contacteur « opposé » l’autorise.

Chauffe OFF JOUR => Nuit doit être à 0 => on peut faire Contacteur Jour OFF
Chauffe ON JOUR => Nuit doit être à 0 => on peut faire Contacteur Jour ON
Chauffe OFF NUIT => Jour doit être à 0 => on peut faire Contacteur Nuit OFF
Chauffe OFF NUIT => Jour doit être à 0 => on peut faire Contacteur Nuit ON

Le design principal de suivi de la maison a été un peu modifié côté énergie :

En détails :

La puissance active est donnée par le routeur. Je ne me sers pas de cette valeur pour le calcul suivi conso, car après vérification le routeur calcule depuis une tension fixe et j’ai un écart avec la facturation (logique). Le suivi conso se base sur l’index BASE (pas de HC/HP pour ma part). Je calcule une puissance active moyenne chaque minute par delta de l’index. A noter qu’après plusieurs semaines chez Total, j’ai vérifié et ça colle.

Donc le S (apparent) en VA vient du linky ; le W vient soit du routeur (à calibrer dans le futur quand j’aurai plus de données) ou calculer chaque minute.

Pour le PV, même principe. Compteur pulse (raspberry + jeedouino). Mais c’est la production :wink: … pas l’autoconsommation. D’ailleurs on voit que je rejette de la puissance sur le réseau.

Le 0% c’est le pourcentage de routage sur l’eau chaude (bein là le ballon est plein à craquer :D). Donc c’est normal, je rejette… Hier, 2.56€ autoconsommé pour un ratio d’autoconso de 94% (donc j’ai rejeté 6% sur le réseau).

Concernant l’eau chaude, le ballon est plein (67°C, je vais chercher son max à 66) ; 100% chauffé gratuitement ; soit 0.8€ gagné pour 6.5h de chauffe aujourd’hui (malgré 3 douches, 2 machines…).

Petit widget au survol comme les autres :

Me permet de voir si ça chauffe, si le ballon est full (à fond de son stockage), si la carte ACI est activée pour chauffer. Le sonoff est le contacteur J/N « fixe » de 800W. Les dimmers eux vont jusqu’à 800W chacun. Mais pour éviter de les charger à mort, un scénario me permet de délester les dimmers sur le contacteur …

Ce délestage marche sur 150% des 2 dimmers et se coupe sur 30% des dimmers…
Bien sûr, il faut que le contacteur soit non activé pour que le scénario s’enclenche et dans l’autre cas que le contacteur soit activé… et que le ballon ne soit pas plein !

Il y a pas mal de choses « cachées » notamment pour la mise en forme et un comptage « juste » propre au routeur Wifi que j’utilise de Clyric (je recommande ce routeur pour l’association APER derrière). J’ai modifié le code source aussi pour pouvoir ajouter le principe de délestage du dimmer.

Un scénario qui regarde si le ballon est full ; de toutes les manières, j’ai conservé la carte ACI qui est la source du shelly qui pilote les contacteurs. Donc c’est plus de la mise en forme et du suivi qui se déclenche sur la température de l’eau chaude (remonté par l’ESP du premier dimmer) :

Dans le principe, la ventilation du boitier tourne et s’arrête 20min après le dernier « ON » (d’un contacteur, d’un dimmer) pour avoir un refroidissement efficace du boitier.

Donc la ventilation se déclenche sur :

Qui est un interrupteur qui revient à 0 au bout de 20min. Donc on fait des ON à chaque fois qu’on a un événement (monostable à durée fixe) :

Qui déclenche un autre scénario par #[Eau Chaude][ECS][Ventilation]# qui lui va activer ou non le shelly qui autorise la chauffe (depuis la carte ACI si l’eau n’est pas à fond - protection mécanique du ballon). Cette ventilation doit marcher que ce soit pour la chauffe de nuit, de jour mais est normalement utile pour les dimmers qui chauffent (voir plus bas).

Et je peux déroger la chauffe de nuit, ou forcer une chauffe de nuit ou de jour…

Un exemple de délestage durant la journée des dimmers vers le contacteur ; ce qui me permet d’avoir 250% environ (800W * 2.5) de puissance dispo sur le ballon par effacement (puisque j’efface d’abord la puissance de la maison qu’elle soit talon ou utilisation).

Quelques exemples :

  • en bleu la température du ballon
  • en vert le délestage sur le contacteur (puissance fixe à 800W)
  • en jaune la puissance des dimmers incluant le délestage (soit 300% au max et donc la puissance max du ballon)
  • en orange quand le ballon est full

  • en vert : la ventilation (et donc si pas de ventilation ; pas d’autorisation de chauffer)
  • en orange : la puissance routée sur le ballon (contacteur, dimmers) jusqu’à 2000W
  • en bleu : la température du boitier avec les dimmers (justement qui chauffent …) et qui ne dépasse pas 27°C au plus haut (2000W)
    note : le rebond du matin de la ventilation sera supprimé, j’ai affiné le % des dimmers pour le délestage du contacteur (l’hystérésis était buggué).

Quand on zoome un peu plus loin, on voit la faiblesse de l’architecture à deux dimmers. Le second continue de chauffer car il ne tient pas compte de la protection de la température (qui est sur le premier dimmer).
Mais la protection mécanique du ballon se coupant, cela coupe l’alimentation du contacteur et donc il n’y a plus de puissance qui passe… alors je grapille quelques °C de plus, mais bon … le ballon est full.
Le top serait d’avoir un dimmer2 qui tient compte de la température du premier. Pour l’heure, c’est jeedom qui fait le travail en coupant l’alimentation du shelly même si la carte ACI autorise encore la chauffe à quelques °C près…

La difficulté est que je ne veux pas couper la ventilation tout de suite, donc je laisse le shelly enclenché et je le coupe que 15min après ; donc potentiellement le dimmer 2 peut encore envoyé un peu …
Du coup, je préfère rester en délest ou en equal.

Ensuite pour avoir une analyse de ce que je produis, autoconsomme et « perds » de ma toiture…

Dans le principe l’algo est simple pour ceux qui sont familiers avec l’énergie, la puissance.

  • on récupère les points de mesure du routeur et les temps sur la journée précédente
  • on calcule à chaque point :
  • le delta de temps,
  • l’énergie vue sur la valeur remontée par le routeur pendant ce delta de temps,
  • on stocke la borne temps supérieure pour le coup d’après,
  • l’énergie est donc la multiplication du temps et de la puissance sur la période (W = W.s pour les non-connaisseurs),
  • on regarde le sens de la puissance active vue :
    si positive, elle est consommée
    si négative, elle est perdue et rejetée (pour rappel le routeur veut tendre vers 0 suivant sa possibilité !)
  • en sortie, on normalise en Wh (/3600)

Seule faiblesse, le routeur n’est pas précis car il ne mesure pas la tension mais que l’angle (pour rappel P=UxIxcosphi. Donc le I et cosphi sont justes… mais le U c’est une constante.

Pas grave, j’ai le compteur Linky par la TIC qui lui est fiable et juste (pour l’avoir pointé et encore heureux !).

Bon et je fais ça… par un scénario avec bloc code :

// récupération de l'ID pour la puissance mesurée par le routeur
$cmdIdprouteur= cmd::byString("#[Agrégateurs][Routeur PV][Puissance]#")->getId();

// définition des bornes de temps pour l'étude pour la veille
$debut = date("Y-m-d H:i:s", strtotime("yesterday 00:00:00"));
$fin = date("Y-m-d H:i:s", strtotime("today 00:00:00"));
// permet de stocker le précédent temps pour la normalisation
$previous = $debut;

// definitions en kWh
$erouteur = 0; // energie extraite par somme cumulée
$epositive_routeur = 0; // energie vue par le routeur 
$enegative_routeur = 0; // energie vue par le routeur
$temps_obs = 0; // pour vérifier le nombre de secondes observées pour le calcul

// on récupère les valeurs
$values = history::all($cmdIdprouteur, $debut, $fin);

foreach ($values as $value) {
  
  $date = $value->getDatetime();
  $temp = $value->getValue();
  $deltatemps = strtotime($date)-strtotime($previous);
  $temps_obs = $temps_obs+$deltatemps;
  // on regarde le signe de cette énergie
  if ($temp >= 0) {
  // si positive dans le compteur énergie positif (consommée)
  $valuenorm = $temp*$deltatemps; 
  $epositive_routeur = $epositive_routeur+$valuenorm;
  //$scenario->setLog("@temps $date pour delta $deltatemps : valeur positive $temp norm $valuenorm soit $epositive_routeur Wh");
  }
  else if ($temp < 0) {
  // si négative dans le compteur énergie négative (rejetée)
  $valuenorm = $temp*$deltatemps; 
  $enegative_routeur = $enegative_routeur+$valuenorm;
  //$scenario->setLog("@temps $date pour delta $deltatemps : valeur negative $temp norm $valuenorm soit $enegative_routeur Wh");
  }
  // on stocke le temps de référence pour le pas suivant
  $previous = $date;
}

// normalisation en Wh et absolu
$epositive_routeur = $epositive_routeur/3600;
$enegative_routeur = abs($enegative_routeur)/3600;
$scenario->setLog("Total analysé : $temps_obs s - Total Consommé : $epositive_routeur Wh - Total Perdu : $enegative_routeur Wh");

// sortie par variable
$scenario->setData('econso_routeur', $epositive_routeur);
$scenario->setData('erejet_routeur', $enegative_routeur);

Ensuite je sors quelques variables pour stats :

  • effacement : je regarde sur la veille quand P=0 ; j’ajoute ça chaque jour pour avoir l’effacement depuis le début de l’installation.
round(durationBetween(#[Energie][Puissance Instantanée][Consommation]#,0,yesterday 00:00,today 00:00)/60,2)
  • je calcule le ratio d’erreur entre le routeur et linky pour normaliser
  • j’estime la vraie consommation vue par le routeur (celle facturée est celle du linky), la production est donnée par le compteur pulse et le rejet sur le réseau (le but étant d’avoir 0…)
  • on sort les statistiques suivantes :
  • production totale de la veille (par pulse),
  • la production depuis la mise en service,
  • l’autoconsommation (ce que j’ai consommé de ce que j’ai produit, le but est de tendre à 100%) en % et en Wh,
  • l’autoconsommation totale depuis la mise en service (avant, j’avais partagé le code, j’estimais cette autoconsommation sur la base d’un talon de consommation à défaut de mieux car je n’avais pas la courbe de rejet par la mesure d’un routeur),
  • le ratio total de l’installation (depuis son installation) d’autoconsommation,
  • l’efficacité électrique du routage d’eau chaude par rapport à la consommation électrique (en toute rigueur, 100% d’une durée de chauffe de l’eau chaude ne me donne pas 100% de consommation gratuite… bein oui, y a de l’électronique dans le boitier : dimmers, ventilo, alimentation etc),
  • le gain financier du jour (par rapport au prix HT du kWh,
  • le gain total HT et l’amortissement (pareil calculé HT car le kWh est HT…)

et un petit télégram tous les matins qui s’ajoute à celui du suivi des usages de la maison …

Pour les plus attentifs (il y avait une erreur dans la variable autoconso c’est corrigé et le prix économisé de l’eau chaude est corrigé aussi) :


Autre modification le design de suivi de l’énergie :

  • j’avais intégré les excellents graphiques de suivi conso widget, très pratique pour avoir l’évolution de l’année de l’électricité, la production et l’eau.

  • le tableau de mise en forme jour/veille ; semaine/semaine préc et mois/mois préc n’a pas bougé.

  • j’ai ajouté un tableau de suivi de la production et de l’électricité pour la veille qui s’appuie entre autres sur le précédent scénario :

  • et un tableau de suivi des années (année en cours/an-1/an-2)… je remets la consommation électrique totale (autoconsommation + consommation Linky) et les principaux usages ou sources :

  • ainsi avec 1.6KWc sur une maison, on peut viser jusqu’à 20% d’une consommation totale ;
  • la climatisation (chaud et froid) ; en A-2 il n’y qu’un étage climatisé chaud/froid d’où l’écart et là on sort de l’hiver donc logique qu’on tape du 36%…
  • de même la piscine qui est bien basse (5%) par contre, clairement, iopool m’a permis de bien mieux filtrer avec moins de produits (20% il y a 2 ans, 12% alors que la piscine a été ouverte 2 mois de plus !)
  • le chauffage électrique est tout petit (car ce sont juste les salles de bains),
  • l’onduleur de la maison (routeur, nas, fibre, routeur 4G, etc) mine de rien 5% !
  • le cumulus qui tire 13 à 16% de l’usage de la maison (on comprend l’intérêt de chauffer cette eau sur la production solaire) et le routage en place depuis 10 jours…

J’ai aussi supprimé weather que je trouvais moins fiable que meteofull au final. A ce jour, la consigne d’eau chaude pour la nuit est déduite par la météo ; weather m’annonçait systématiquement du couvert ou nuageux alors que le lendemain était « clair ». Meteofull est plus « propre » au niveau des conditions je trouve. Maintenant que ça fait 6 mois que je l’utilise j’en suis très satisfait, certes il est très complet…

Pour l’heure, soit j’ai internet et je regarde si la météo du lendemain est :

(#[Extérieur][MétéoFull][Condition 24h]# matches "/Ensoleillé/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Ciel voilé/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Faibles passages nuageux/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Stratus/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Stratus se dissipant/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Eclaircies/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Faiblement nuageux/") OU (#[Extérieur][MétéoFull][Condition 24h]# matches "/Fortement nuageux/")

et fonction du nombre de personnes à la maison, je vais chauffer un peu la nuit ou non.
Si pas d’internet, j’ai pris la moyenne des autres cas par principe…

Mais je pense intégrer une prédiction de l’ensoleillement en fonction de la saison… pour mieux gérer la température et le besoin en fonction des machines.

6 « J'aime »

Je ne sais pas pourquoi, mais apparemment, je ne peux modifier le message.
Bon la copie d’écran qui manque est celle là (pour le tableau de suivi des énergies/usages ):

4 « J'aime »

Bonjour Benjamin

C’est moi où tous les liens sont KO ?

Juste un peu plus haut. Et vu les faibles retours, le blog est pour l’instant suspendu. J’avais trouvé un hébergement et système plus adéquat, on verra si le temps et l’envie me reprennent à défaut du soutien financier. En parallèle, mon installation est fiable avec peu de mise à jour hormis quelques bugs ci et là.
Ce post contient beaucoup d’informations pour tout le monde et des fois bien plus détaillés que le blog.

1 « J'aime »

Bonsoir Benj29,
j’espère que tu vas bien depuis tout ce temps!
peux tu m’expliquer comment tu gères le widget en fonction du mode clim ou chauffage
image
moi je me retrouve avec la flamme rouge été comme hiver…
j’ai la même chose quand je force un mode ou quand il est défini par un agenda
je suppose qu’il faut passer une variable, mais ou?
a te lire

Bonjour @Chris13

J’utilisais une variable « panel_ZONE » pour avoir un simple widget numérique (0,1, etc).

La conversion se fait dans un scénario du type (par ZONE), un pour le thermostat chauffage, un pour le thermostat clim (car dans mon cas 2 thermostats différents) :

#[Entrée][Chauffage Entrée][Statut]#

Exemple pour le chauffage (tu adapteras pour la clim) :

Et le widget est le suivant :

<div class="tooltips cmd cmd-widget #history#" data-type="info" data-subtype="numeric" data-cmd_id="#id#" data-cmd_uid="#uid#" data-version="#version#" data-eqLogic_id="#eqLogic_id#" style="display: block;">
	<center>
      <span class="iconCmd"></span>
  </center>
	<script>
		jeedom.cmd.update['#id#'] = function(_options){
          var state = _options.display_value;
          var cmd = $('.cmd[data-cmd_id=#id#]');
          // 0 arrêt qu'importe le mode ; 1 = chauffage ; 2 = clim !
          cmd.attr('title','Valeur du '+_options.valueDate+', collectée le '+_options.collectDate);
          if (state == 0 ) {
			cmd.find('.iconCmd').empty().append('<i class="Mdi mdi-power" style="color:ghostwhite;font-size:22px;"></i>');
			}
		  if (state == 1 ) {
			cmd.find('.iconCmd').empty().append('<i class="Mdi mdi-home-remove-outline" style="color:#acacac;font-size:22px;"></i>');
			}
          if (state == 2 ) {
			cmd.find('.iconCmd').empty().append('<i class="Mdi mdi-fire-alert" style="color:#ff8c00;font-size:22px;"></i>');
			}
          if (state == 3 ) {
			cmd.find('.iconCmd').empty().append('<i class="Mdi mdi-weather-night" style="color:#30b455;font-size:22px;"></i>');
			}
          if (state == 4 ) {
			cmd.find('.iconCmd').empty().append('<i class="Mdi mdi-fire" style="color:#da3037;font-size:22px;"></i>');
			}
          if (state == 5 ) {
			cmd.find('.iconCmd').empty().append('<i class="Mdi mdi-snowflake" style="color:#5078aa;font-size:22px;"></i>');
			}
		  cmd.find('.state').empty().append(' '+state);
          cmd.find('.unite').empty().append(' #unite#');	
          
			if(_options.alertLevel){
			$('.cmd[data-cmd_id=#id#]').removeClass('label label-warning label-danger')
			if(_options.alertLevel == 'warning'){
				$('.cmd[data-cmd_id=#id#]').addClass('label label-warning');
			}else if(_options.alertLevel == 'danger'){
				$('.cmd[data-cmd_id=#id#]').addClass('label label-danger');
			}
			}
		}
		jeedom.cmd.update['#id#']({display_value:'#state#',valueDate:'#valueDate#',collectDate:'#collectDate#',alertLevel:'#alertLevel#'});
	</script>
</div>