Bonjour @agp.com
J’ai désactivé la tuile suiviCO2 et j’ai un message chaque heure:
[2020-03-11 11:00:19][ERROR] : Erreur sur la fonction cronHourly du plugin : Call to a member function getConfiguration() on null
C’est dû à:
if($suiviCO2->getConfiguration('conso_type') == 'elec')
avec suiviCO2 non initialisé puisque pas d’eqLogic actif.
Même message d’erreur quand je veux afficher le panel. Je voulais juste voir les gCO2 émis par kWh en France.
Je vais juste masquer la tuile.
Merci pour l’info, j’ajouterai des if sur getIsVisible() et getIsEnable() un peu partout pour gérer ces cas là pour la prochaine version. C’est un test auquel je n’avais pas pensé !
@jpty, je viens de pousser une nouvelle beta qui devrait corriger le problème.
En fait il y avait 2 bugs :
Tu peux tester cette nouvelle beta et me dire si ca corrige bien le soucis chez toi aussi ?
Merci !
Merci pour la correction.
Pour le panel ça semble bon j’ai bien le message « Aucun équipement actif » (J’aurais ajouté suiviCO2 ds le msg.)
Pas de message d’erreur au cron de 16h.
sleep(60); dans cronHourly ne me parait pas très ‹ clean ›.
Tous les autres cronHourly sont retardés.
24s au cron de 16h et 192s à 17h avec suiviCO2 réactivé.
J’enlève le sleep pour le cron de 18h pour voir le temps.
C’est pas grave si les données n’arrivent qu’à l’heure suivante ?
Edit : Au cron de 18h sans slip ( durée 27s ) les données récupérées :
Cron de 19h: 23s La valeur ci-dessus pour 18h a augmenté.
Super, merci pour ton test.
Je mettrais a jour le message pour la version stable : « Aucun équipement suiviCO2 actif »
En fait l’API ne répond en général pas du tout si tu la demandes à heure pile pendant son update, donc c’est pas juste un retard d’1h mais un timeout et aucune donnée ! C’est pour ça que j’ai retardé de 60s. Visiblement tu as suffisamment de cronHourly dans tes plugins pour que suiviCO2 ne s’exécute pas à heure fixe, donc tu ne vois pas l’erreur API, mais ça ne sera pas le cas de tout le monde.
Je suis d’accord ce n’est pas très propre, je voulais gérer ça avec espèce de « setTimeout » qui appellerai la fonction avec un peu de retard pour ne pas gêner les autres, mais visiblement ça existe pas en PHP… (https://stackoverflow.com/questions/3435418/is-there-a-function-similar-to-settimeout-javascript-for-php/17252448) alors j’ai fait ça avec un pauvre sleep. Mais si tu as une proposition d’amélioration, je prend ! 
Le second problème si tu vires le sleep c’est pour actualiser la variable qui s’affiche sur le dashboard avec la valeur « courante », en fait mon code prend l’heure pleine courante -15min. Donc si tu as 1h de décalage dans tes données de l’API, tu n’auras pas cette donnée…
Ta valeur de 18h (quand tu vas la lire entre 18h et 19h) dans ta base de donnée est en fait celle de 17h45 (52gCO2). Si tu regardes le log debug ou carrément l’API brut, la valeur de 18h c’est 53gCO2. Vu qu’à 18h ma dernière valeur connue est 17h45, je prend cette là pour la donner en « event » à ma commande pour actualiser le dashboard. Et pour des raisons que j’ignore, je n’arrive pas à lui assigner son horaire correct avec cette fonction. Pour lui donner un autre datetime que l’heure courante, je dois faire un addHistoryValue qui alors ne s’affiche alors pas sur le dashboard… 
Et c’est ce qui explique que ta valeur de 18h (qui était celle de 17h45) a bougé a 19h. A 19h l’API t’as donné la vrai valeur (=53 gCO2) et alors Jeedom, qui avait déjà une valeur a cet horaire a fait une moyenne entre les 2… (Tu dois avoir 52,5 après le cron de 19h, right ?).
J’avais pensé faire 2 cmd jeedom pour éviter cette approximation mais c’était lourd à gérer. C’est pas génial génial mais bon, de toute façon ces datas « temps réel » sont déjà des approximations. Il faut régulièrement lancer la fonction qui récupère les données définitives pour corriger ça et avoir les bonnes valeurs (dans la table historyArch cette fois, donc pas d’histoire de moyenne ! La fonction d’archive elle écrase l’éventuelle donnée précédente !)
Bref, je sais pas si j’ai été très claire… je me suis beaucoup pris la tête pour essayer de comprendre le fonctionnement de Jeedom sur ces fonctions d’historisation et d’archives et j’ai fait de mon mieux pour le code !
Mais bien joué, tu as trouvé un truc pas trés clean ! C’est grave docteur ?
Bonjour @agp.com
Quel pavé! J’ai mis plusieurs jours à tout lire.
Pour supprimer le sleep dans le cronHourly, il faudrait peut être le passer en cron5 et exécuter uniquement à la minute 5. if (date("i") == 5)
ou cron et exec minute 1
ou faire une entrée cron avec execution 1 * * * * avec création/suppression dans install.php, donc plus compliqué.
Je teste une solution pour que l’historique dans la table history soit avec une seule valeur à l’heure en 00 qui serait la moyenne des valeurs aux minutes 00 15 30 et 45.
Ex: A 18h05 on récupère 17h00, 17h15, 17h30 et 17h45 et on écrit dans history la valeur moyenne à 17h00.
Merci !
Tu as des propositions à faire ?
Par contre ces derniers jours j’ai pas mal bossé avec les gars qui ont repris suivi conso pour intégrer leur API (qui devrait être dispo pour tout le monde ces jours-ci, d’ici là mes nouvelles fonction dans ma beta plantent pour ceux qui n’ont pas leur fichier…), donc j’ai encore changé pas mal de choses !
(On peut maintenant choisir l’équipement suivi conso pour reprendre la configuration dans suiviCO2. Et aussi faire un import de l’historique à partir des tables spécifiques de la DB de suivi conso.)
J’avais fait un cron dédié au début, mais comme tu dis c’est compliqué, ça alourdi le code et donc ça me plaisait pas plus que ça. C’est si grave ce « sleep » toutes les heures ?
Oui j’y ai pensé aussi. En fait c’est ce que Jeedom va faire tout seul toutes les nuits avec la fonction « archive ». Donc pour la journée courante c’est highcharts qui fait sa moyenne tout seul et dés le lendemain c’est déjà 1 seule valeur par heure, avec la valeur de 17h00 qui est la moyenne de toutes les 17hxx.
Donc ça m’avait finalement pas semblé nécessaire d’optimiser…
Bonjour aux utilisateurs de mon plugin
De mon côté j’ai une erreur d’exécution sur l’appel API tous les matin au cron de 5h :
Erreur sur la fonction cronHourly du plugin : Echec de la requête HTTP : https://opendata.reseaux-energies.fr/api/records/1.0/search/?dataset=eco2mix-national-tr&rows=220&sort=date_heure cURL error : Operation timed out after 30000 milliseconds with 0 out of 0 bytes received
J’aimerai savoir si vous avez aussi cette erreur ?
Merci !
AgP
Bonjour @agp.com
Pas d’erreur chez moi mais je n’utilise pas cronHourly avec son « sleep pas propre »
J’utilise en test un cron5 avec une exécution uniquement à la 5ème minute.
public static function cron5() {
if (date("i") == 5) { // uniquement à la 5ème minute
Mais j’imagine que si tout le monde interroge à la 5ème minute, il y aura des erreurs.
Merci @jpty pour ton retour, je vais peut-être devoir changer mon code aussi alors !
Je ne pense pas que les 120 utilisateurs de ce plugin (c’est deja pas mal !) vont mettre l’API HS
Par contre faire un cron5 pour une exécution « hourly », je trouve pas ça génial non plus… Dans ce cas je lui ferai un cron dédié !
Mes erreurs ne sont qu’à 5h du matin (et encore, pas ce matin par exemple…), ils font peut-être une mise a jour de leur API tous les matins à 5h donc elle est souvent HS à ce moment… Ou alors c’est mon Jeedom qui est surchargé avec l’envoi de la sauvegarde de la nuit sur le cloud et donc mon réseau qui est saturé… A creuser encore un peu !
A+
Après avoir décalé l’heure de l’envoi de la sauvegarde journalière de 5h à 7h, j’ai maintenant les mêmes erreurs à 7h !
C’est donc bien un problème de bande passante internet chez moi et pas un soucis du plugin ni de l’API, donc je change rien
Bonjour
Pas de possibilité de modifier la valeur du coef
Dans mon exemple l’index est en Wh, je veux donc mettre le coef à une valeur de 1 (et non 1000)
Cool ton plugin ! Tu fais cela pr te faire la main pour vendre des autres plugins a l avenir?
Moi j 'aimerai bien un " meme style " de plugin , mais avec ma dette " plugin dette" suivant les instances financiers , mes fournisseurs d énergie, mes taxes, … en prévisionnelle 
journalier simplement pr rappeler a madame qu’il faut pas prendre TROP DE BAINS CHAUD ps : dans le nord, les panneaux thermique c est pas 10X + performant, mais 2 X - performant que l e photovoltaique 
Bonjour @snoopyfb,
c’est parce que tu utilises l’import via suivi conso, normalement il met justement le bon coefficient directement, c’est pour ça que tu ne peux pas y toucher.
Est-ce que tu as constaté effectivement dans le plugin que ça te fait des valeurs absurdes ?
En tout cas je trouve que c’est en fait une bonne nouvelle parce que j’en étais resté qu’il y avait un bug a corriger sur cette interface avec Suivi Conso, or visiblement ici ça marche ! Tu confirmes ? (à ce coef 1000 près peut-être)
@Thibaut_T, tu peux nous confirmer que ce coef de 1000 vient bien de l’API de suivi conso ?
Merci, tant mieux si tu le trouves cool !
Oui c’était pour me faire la main et parce que ça m’intéressait de suivre ces infos là. J’ai fait 2 plugins payant par la suite (et 3 ou 4 autres gratuits), mais vu ce que ça rapporte par rapport au temps passé de toute façon autant les faire gratuits et que ça profite au plus grand nombre.
J’ai pas tout compris de ton idée de « Plugin Dette », mais si c’est pour tracker et contrôler ta femme, c’est pas vraiment ma vision de la domotique, donc par solidarité féminine je ne ferai pas ce plugin 
Oui normalement de souvenirs sa a été corrigé apr @superbricolo il y a quelques version.
Cordialement
Thibaut
Après avoir fait la configuration dans l’onglet « Equipement » tu as aussi fait les imports des données via l’onglet « Historique » ?
Bonjour @agp.com et merci pour ce plug-in que je suis en train de mettre en place pour avoir une meilleure vision de ma consommation en énergie et de mon impact carboné.
Classiquement j’essaie d’interfacer ce plug-in avec 2 autres:
Autant via le plug-in Gazpar, je vois l’information d’index qui est remonté par le plug-in, autant côté Linky je n’ai pas un champs index en tant que tel, mais les consommations journalières, mensuelles, annuelles, … qui fonctionnent par delta.
Une idée du bon champs à renseigner pour SuiviCO2?
Autre question : les super graphes que l’on voit dans la doc ne sont-ils disponibles que si on utilise le plug-in suiviconso?
Merci de votre aide.
Bonjour
J’utilise votre plugin depuis quelques temps pour piloter mon thermostat en fonction du CO2 par kWh électrique mais depuis quelques mois, celui-ci ne remonte plus le taux de CO2/kWh fourni par eCO2. Y a t-il eu des changements sur leur API. Envisagez vous de maintenir ce plugin.
Par avance merci.
Cordialement
