Quick App - Ecodevice v1

**Barelle** · le 7 juillet 2020

Quick App - Ecodevice v1

Gestion de la consommation en kWh, de la puissance en VA

Pour les abonnements de type BASE, HPHC, EJP, TEMPO.

Permet l’affichage de la puissance apparente, de l’énergie consommée durant la dernière minute, l’heure en cours, la journée en cours, le mois et l’année. Permet également d’afficher les coûts pour la journée, le mois et l’année.

Ne possédant qu’un abonnement HPHC, je suis preneur des résultats de tests pour les autres abonnements, afin de vérifier la bonne adéquation entre la théorie et la pratique.

QAs.jpg.36d828df2ac26f73aa2baa23c3147fd8.jpg

Limites : les cumuls de consommation et les coûts ne sont calculés que pour T1, par défaut les unités de C1 sont en m3 ou litres et celles de C2 en kWh ; une éventuelle future version permettra peut-être de les personnaliser.

Problèmes rencontrés :

L’indigence de la documentation ;
Le swagger qui plante régulièrement (get/plugins/getView par exemple) ;
Les unités ne sont affichées qu’en lettres capitales et quand un child est agrandi, elles disparaissent ;
Curieusement les childs apparaissent dans l’application portable et pas le QA, empêchant ainsi le respect de la graphie du système international (pour kWh notamment).

Configuration pour le fonctionnement

Celle-ci est effectuée par la définition de variables (attention au respect des majuscules et minuscules) :

ipEcodevices : adresse IP de l'Eco-Devices <========= OBLIGATOIRE
portEcodevices : numéro de port de de l'Eco-Devices (80 par défaut)
debug : pour tracer plus copieusement le déroulement du programme (true ou false)

Préférences

Il s'agit de choix concernant les types de données que l'on souhaite afficher :

refreshDelay : intervalle de relevé des mesures en secondes (60 recommandé et par défaut)
iconId : numéro de l'icône à attribuer au QA. Tt oui, on peut attribuer une icône à un child mais pas au QA
globalVarName : nom de la variable globale utilisée pour mémoriser les valeurs d'index afin d’en permettre l’accès à une scène ou un autre QA
toBeDisplayed : compteurs à afficher sous forme de liste (par exemple : T1,C1,C2) par le QA
CoutKW<abonnement> : sous la forme d'une liste des coûts TTC des kWh comme ci-dessous (cf. https://www.kelwatt.fr/prix/edf) :

- CoutKWBASE : 0.1597

- CoutKWHPHC : 0.1798,0.1344 (dans l'ordre HP,HC)

- CoutKWEJP : 0.1518,0.3114 (dans l'ordre HN,HPM)

- CoutKWTEMPO : 0.1548,0.1246,0.1757,0.1397,0.6389,0.1491 (dans l'ordre HPJB,HCJB,HPJW,HCJW,HPJR,HCJR)

CoutAnnuel<abonnement> : le coût annuel TTC de l'abonnement comme ci-dessous (exemple : valeurs de décembre 2020 pour une puissance de 9 kVA), si non défini, les coûts ne tiendront pas compte du prix de l’abonnement :

- CoutAnnuelBASE : 152.64

- CoutAnnuelHPHC : 172.08

- CoutAnnuelEJP : 152.16

- CoutAnnuelTempo : 169.56

childs : liste de childs à lancer sous forme de liste (par exemple : T1kWhJour,C1,C2) voir chapitre ci-après.
displayChilds : si les childs doivent être affichés (true ou false)
displaySimul : pour simuler les coûts pour un abonnement BASE, il faudra impérativement renseigner les variables CoutAnnuelBASE et CoutKWBASE
Les unités, pour chaque child, on peut modifier la valeur des unités de l'index et des valeurs affichées. Ainsi on pourra définir les variables :

- C1IndexUnit et C2IndexUnit pour préciser l'unité de l'index du compteur (on peut également définir T1IndexUnit et T2IndexUnit, même si cela a un sens qui m'échappe) ;

- Suivant les valeurs à afficher, les multiples d'unités pourront être affichées (k, m³, kVA, kW, k€, kWh...), dans ce cas la valeur affichée est arrondie à la première décimale.

La simulation d’un tarif "BASE"

Cette simulation n’est disponible que pour les abonnements HPHC, EJP et TEMPO.
Les variables CoutAnnuelBASE et CoutKWBASE devront respectivement préciser le coût de l’abonnement "BASE" et le tarif du kWh. Les coûts simulés pourront être affichés sous la forme d'enfants ("children").

Les valeurs possibles pour la liste de la variable "childs" sont :

Les "Enfants"

Comme il faut bien découvrir, je me suis lâché… Même si la gestion des quatre types d’abonnement est à l’origine de l’inflation. Ne possédant qu’un abonnement HPHC, je n’ai pas pu tester les autres cas, merci de vos retours.

Les valeurs possibles pour la liste de la variable "childs" sont :

Compteur T1 :

T1VA = T1 puissance,
T1WhActuel = Conso. actuelle,
T1WhHeure = Conso. heure,
T1kWhJour = Conso. jour,
T1kWhMois = Conso. mois,
T1kWhAnnee = Conso. année,
T1Index = index total (somme des index si plusieurs périodes tarifaires)
Coûts par période :

* T1JourEuro = coût pour le jour en cours,
* T1MoisEuro = coût pour le mois en cours,
* T1AnneeEuro = coût pour l’année en cours,
* T1SimuBaseJour = coût simulé (tarif base) pour le jour en cours,
* T1SimuBaseMois = coût simulé (tarif base) pour le mois en cours,
* T1SimuBaseAnnee = coût simulé (tarif base) pour l’année en cours ;

Consommation abonnement BASE par période

* BASEHeure       = Conso. BASE heure,
* BASEJour       = Conso. BASE jour,
* BASEMois       = Conso. BASE mois,
* BASEAnnee       = Conso. BASE année,

* BASEIndex = index BASE ;

Coûts abonnement BASE par période

* BASEJourEuro   = Coût BASE jour,
* BASEMoisEuro   = Coût BASE mois,
* BASEAnneeEuro   = Coût BASE année ;

Consommation abonnement HPHC par période

* HPHeure       = Conso. HP heure,
* HPJour        = Conso. HP jour,
* HPMois       = Conso. HP mois,
* HPAnnee      = Conso. HP année,

* HPIndex = index HP,
* HCHeure       = Conso. HP heure,
* HCJour        = Conso. HC jour,
* HCMois          = Conso. HC mois,
* HCAnnee       = Conso. HC année,

* HCIndex = index HC ;

Coûts abonnement HPHC par période

* HPJourEuro      = Coût HP jour,
* HPMoisEuro      = Coût HP mois,
* HPAnneeEuro   = Coût HP année,
* HCJourEuro      = Coût HC jour,
* HCMoisEuro      = Coût HC mois,
* HCAnneeEuro   = Coût HC année,

Consommation abonnement EJP par période

* EJPHNHeure       = Conso. EJPHN heure,
* EJPHNJour       = Conso. EJPHN jour,
* EJPHNMois       = Conso. EJPHN mois,
* EJPHNAnnee       = Conso. EJPHN année,

* EJPHNIndex = index EJPHN,
* EJPHPMHeure   = Conso. EJPHPM Heure,
* EJPHPMJour       = Conso. EJPHPM jour,
* EJPHPMMois       = Conso. EJPHPM mois,
* EJPHPMAnnee   = Conso. EJPHPM année,

* EJPHPMIndex = index EJPHPM ;

Coûts abonnement EJP par période :

* EJPHNJourEuro   = Coût EJPHN jour,
* EJPHNMoisEuro   = Coût EJPHN mois,
* EJPHNAnneeEuro  = Coût EJPHN année,
* EJPHPMJourEuro   = Coût EJPHPM jour,
* EJPHPMMoisEuro   = Coût EJPHPM mois,
* EJPHPMAnneeEuro= Coût EJPHPM année ;

Consommation abonnement TEMPO par période :

* HPJBHeure    = Coût HPJB heure,
* HPJBJour       = Coût HPJB jour,
* HPJBMois       = Coût HPJB mois,
* HPJBAnnee = Coût HPJB année,

* HPJBIndex = index HPJB,
* HCJBHeure      = Coût HCJB heure,
* HCJBJour       = Coût HCJB jour,
* HCJBMois       = Coût HCJB mois,
* HCJBAnnee      = Coût HCJB année,

* HCJBIndex = index HPCB,
* HPJWheure    = Coût HPJW heure,
* HPJWJour       = Coût HPJW jour,
* HPJWMois       = Coût HPJW mois,
* HPJWAnnee      = Coût HPJW année,

* HPJWIndex = index HPJW,
* HCJWHeure   = Coût HCJW heure,
* HCJWJour       = Coût HCJW jour,
* HCJWMois       = Coût HCJW mois,
* HCJWAnnee   = Coût HCJW année,

* HCJWIndex = index HCJW,
* HPJRHeure      = Coût HPJR heure,
* HPJRJour       = Coût HPJR jour,
* HPJRMois       = Coût HPJR mois,
* HPJRAnnee      = Coût HPJR année,

* HPJRIndex = index HPJR,
* HCJRHeure      = Coût HCJR heure,
* HCJRJour       = Coût HCJR jour,
* HCJRMois       = Coût HCJR mois,
* HCJRAnnee     = Coût HCJR année,

* HCJRIndex = index HCJR;

Coûts abonnement TEMPO par période :

* HPJBJourEuro   = Coût HPJB jour,
* HPJBMoisEuro   = Coût HPJB mois,
* HPJBAnneeEuro   = Coût HPJB année,
* HCJBJourEuro   = Coût HCJB jour,
* HCJBMoisEuro   = Coût HCJB mois,
* HCJBAnneeEuro   = Coût HCJB année,
* HPJWJourEuro   = Coût HPJW jour,
* HPJWMoisEuro   = Coût HPJW mois,
* HPJWAnneeEuro   = Coût HPJW année,
* HCJWJourEuro   = Coût HCJW jour,
* HCJWMoisEuro   = Coût HCJW mois,
* HCJWAnneeEuro   = Coût HCJW année,
* HPJRJourEuro   = Coût HPJR jour,
* HPJRMoisEuro   = Coût HPJR mois,
* HPJRAnneeEuro   = Coût HPJR année,
* HCJRJourEuro   = Coût HCJR jour,
* HCJRMoisEuro   = Coût HCJR mois,
* HCJRAnneeEuro   = Coût HCJR année ;

Compteur T2 :

T2VA = T2 puissance,
T2WhActuel = T2 Conso. actuelle,
T2WhHeure = T2 Conso. heure,
T2kWhJour = T2 Conso. jour,
T2kWhMois = T2 Conso. mois,
T2kWhAnnee = T2 Conso. année,
T2Index = index total du compteur.

Compteur C1 :

C1Index = C1 Index,
C1Actuel = C1 Conso. actuelle,
C1Heure = C1 Conso. heure,
C1Jour = C1 Conso. jour,
C1Mois = C1 Conso. mois,
C1Annee = C1 Conso. année,

Compteur C2 :

C2Index = C2 Index,
C2Actuel = C2 Conso. actuelle,
C2Heure = C2 Conso. heure,
C2Jour = C2 Conso. jour,
C2Mois = C2 Conso. mois,
C2Annee = C2 Conso. année,

Installation/mise à jour

Pour une première installation :

Importer le fichier ".fqa" ci-dessous, puis :
Renseigner les variables ipEcodevices, globalVarName, toBeDisplayed, displayChilds et childs.

Remarque : une variable créée par le QA n’est pas modifiable par l’interface. Il suffit de la supprimer et de la recréer.

Pour une mise à jour :

Il est nécessaire de vérifier que l’interface du QA possède des labels jusqu’à "Lbl_25", sinon en rajouter sans trous dans la numérotation ;
Puis il suffit de copier le contenu du fichier lua dans l’onglet main du QA.

Version 0.800 (ajout de la variable portEcodevices, correction de divers bugs...).

Version 0.900 : Eco-Devices-0.90.fqa

Ajout des enfants pour les coûts globaux : T1JourEuro, T1MoisEuro, T1AnneeEuro ;
Ajout de la simulation d'un abonnement "BASE" et possiblement des enfants T1SimuBaseJour, T1SimuBaseMois, T1SimuBaseAnnee ;
Ajout de l’affichage des index et des enfants : BASEIndex, HPIndex, HCIndex, EJPHNIndex, EJPHPMIndex, HPJBIndex, HCJBIndex, HPJWIndex, HCJWIndex, HPJRIndex, HCJRIndex, T2Index ;
Other minor bug fixes.

Version 0.92 : Eco-Devices-0.92.fqa

Amélioration de la robustesse du code (gestion de quelques cas tordus) ;
Corrections cosmétiques.

Version 0.95 : Eco-Devices-0.95.fqa

Traitement du cas sans téléinfo ;
Ajout des variables pour les unités pour les childs ;
Amélioration de la robustesse du code (gestion de quelques cas tordus).

Version 0.96 : Eco-Devices-0.96.fqa

Gestion du cas du changement d'abonnement ;
Correction du cas où une variable du QA se termine par une espace ;
Multiples dans unités dans les valeurs affichées ;
Corrections des anomalies.

Eco-Device-0.96.fqa

Ecodevices-0.96.lua.zip

Modifié le 8 avril 2021 par Barelle
Version 0.95

**mprinfo** · le 8 juillet 2020

Salut @barelle

Jolie travail

Moi je suis entrain de bidouiller pour EDRT2 pour le moment j'ai ceci

1.jpg.7fdf8d2399c45b3ea60c20693508cad5.jpg

Pour les QA est application mobile il est exact que le parent n'est pas affiché dans l'application mobile

Après si on réfléchi un peu cela peu semblé cohérent si on compare un QA a un module le parent est caché et n'est donc pas visible non plus

J'ai quelque question au sujet de la méthode a employer pour la mise a jour de ce type de QA

Quel protocole doit t'on employer pour le mettre a jour ?

Après quelques recherche l'ecodevice est accessible en HTTP ou M2M (machine to machine)

Je pose la question si on ne pourrait pas utilisé le protocole MQTT ?

Pour la mise a jour j'ai opté pour cette méthode

C'est l'EDRT2 qui fait des GET via push vers la HC3

Donc tout les compteurs et l'état des relais est mis a jour par le EDRT2 c'est un peu galère pour trouver le nom des variables mais après cela fonctionne très bien.

J'envoie tout mes GET vers le parent et je mets a jours les CHILDS avec la commande fibaro.call cela me permet de n'avoir qu'un seul pusch pour mettre a jour plusieurs childs

autre petite question au niveau du typage des enfants

"com.fibaro.multilevelSensor"

Moi après avoir chercher un peu j'ai mis

"com.fibaro.powerSensor"

tu as mis

Qu'en pense tu ?

**Barelle** · le 8 juillet 2020

il y a 36 minutes, mprinfo a dit :

Quel protocole doit t'on employer pour le mettre a jour ?

C'est une très bonne question, même s'il vaudrait mieux parler de choix d'architecture logicielle, le protocole d'échange n'étant qu'un moyen (mais qui selon sont type va permettre un choix d'architecture , bref c'est compliqué).

L'important est de réaliser un choix sur l'interlocuteur qui sera à l'origine de la communication, dans notre cas, soit la HC3, soit l'Ecodevice.

Je n'ai pas fait le choix d'utiliser le M2M de l'Ecodevice car :

Les informations les plus utiles pour mon usage sont portées par la trame de la télérelève et, pour les obtenir, il convient de les énumérer explicitement dans l'Ecodevice ce qui se traduirait par un paramétrage différent pour chacun des types d'abonnement ;
Tel qu'implémenté par GCE, le M2M ne me satisfait pas, j'eu préféré que l'information soit envoyée lors d'un changement d'état (nouvelle valeur d'un compteur par exemple) même si cela peut se traduire par un afflux important de message. En cela le report de consommation des modules Fibaro est pertinent avec les définitions d'intervalle et de niveaux ;
Par souci de simplification, il est plus facile (surtout avec le Lua bridé par Fibaro) de traiter une réponse à une question que l'on a posé, plutôt qu'être disponible dans l'attente d'un message...
Par culture colbertiste , une centrale domotique centralise (sic) et dirige ses opérations, il me paraît plus optimisé de récupérer l'information quand on en a besoin, plutôt que filtrer le "bruit informationnel" ;
Ce dernier point est plus général : les objets communicants, doivent-ils envoyer périodiquement leurs données (par exemple à un message broker comme Mosquito) même si elles n'intéressent personne ?
Dans une architecture client/serveur, c'est le client qui effectue les requêtes, la HC3 dans notre cas.
Avec la vision IoT actuelle ,le broadcast se généralise avec des architectures ressemblant au jet d'une bouteille à la mer (la mer s'appelant Mosquito), ou au fonctionnement des réseaux sociaux : publions ! même si cela n'a aucun intérêt...
Je ne crois pas que la question ait été tranchée, pour chaque contexte une réponse peut-être plus adaptée qu'une autre.

Enfin, à ma connaissance MQTT n'est pas disponible sur les produits de GCE, donc la question de l'usage d'un Message Broker (ouais je sais ça fait pédant) ne se pose pas dans ce contexte. Toutefois, histoire de s'amuser et de pimenter un peu notre domotique, rien n'interdit de confier à Node-RED la tâche de récupérer les informations de l'Ecodevice et de mettre à jour la HC3 par l'API. Au delà de la satisfaction personnelle de la découverte d'une solution à la mode, cela permettrait de fragiliser la solution par l'ajout de serveurs logiciels et physiques.

**mprinfo** · le 8 juillet 2020

il y a 28 minutes, Barelle a dit :

L'important est de réaliser un choix sur l'interlocuteur qui sera à l'origine de la communication, dans notre cas, soit la HC3, soit l'Ecodevice.

Oui d'accord avec toi mais pour la mise a jour des relais en temps réel on n'a pas trop le choix c'est EDRT2 dans mon cas qui doit mettre a jour l'information de retour d'état

car si je ne passe pas par la HC3 pour actionner le relais il faut bien que celle-ci en soit informée

J'ai opté pour une mise a jour des valeurs de conso aussi pour que ce soit EDRT2 qui fasse cela

L'avantage dans mon cas c'est que je n'ai qu'une seule requet qui est envoyer

/api/callAction?deviceID=85&name=UPEnery&arg1=$DIP01&arg2=$TI04&arg3=$DIP02&arg4=$C01&arg5=$DIP03&arg6=$C02&arg7=$S25&arg8=$S26&arg9=$S27

si je devais faire cela sur ma HC3 je devrais faire 3 requettes pour ne récupérer qu'une partie du json de chaque requette

Donc je sais pas trop qu'elle solution serait la moins couteuse en ressource

Merci pour toute ces information je vais relire tout ce que tu as écris pour comprendre

Pour le typage peux aussi m'éclairer pourquoi tu as choisis

"com.fibaro.multilevelSensor"

plutôt que

"com.fibaro.powerSensor"

**Barelle** · le 8 juillet 2020

Il me semble que le contexte est différent :

L'EDRT2 possède des relais (comme un IPX), la question du retour d'état se pose. En terme d'implémentation, ton choix me semble pertinent ayant reçu un ordre, l'EDRT2 rend compte de son exécution, sinon, il eut fallu que l'HC3 interroge l'EDRT2 pour s'assurer de sa bonne fin ;
Pour les valeurs de consommation, ce qui m’intéresse se sont les index qui, par la différence entre deux valeurs, me permettent de savoir l'énergie (en kWh) qui me sera facturée, en n'oubliant que le nom de la variable d'index change en fonction de l'abonnement, soit 11 index possibles et 6 utiles pour un abonnement Tempo. La puissance apparente (en kVA) ne sert qu'à vérifier que l'on est bien en deçà de la valeur de son abonnement. En tant que particulier, la valeur du cos phi ne m'importe absolument pas, surtout qu'elle varie en fonction des heures de filtration de la piscine.

J'avais plutôt prévu d’utiliser le type com.fibaro.energyMeter, mais je n'ai pas réussi à obtenir l'affichage des données (non élucidé à ce jour), ma table childsConfig est conçue pour permettre de choisir le type pour chacun des childs. Quand je maîtriserai ce domaine, des évolutions seront sans doute possibles...

**Manu31** · le 19 août 2020

Bonjour,

D'abord, merci beaucoup pour ce super travail.

Mais suis-je le seul pour qui le plugin ne s'affiche pas ?

En gros, j'ai importé le plugin, mis l'ip de mon EcoDevice.
Dans les log j'ai bien :

[19.08.2020] [22:08:33] [ERROR] [QUICKAPP181]: Credentials data is empty!
[19.08.2020] [22:08:43] [TRACE] [QA_ECODEVICES_398]:
[19.08.2020] [22:08:43] [TRACE] [QA_ECODEVICES_398]: mainLoop>>>Version 0.6.00 démarrée le 19/08/2020 à 22:04:43 (depuis 00:04:00), mise à jour dans 60 secondes.
[19.08.2020] [22:08:43] [TRACE] [QA_ECODEVICES_398]: mainLoop>>>Total memory in use by Lua 5.3: 707.11 KB.
[19.08.2020] [22:08:44] [DEBUG] [QA_ECODEVICES_398]: readEcodevices>>>OK, response.data={"product":"Eco-devices","T1_PTEC":"HP..","T1_PAPP":1310,"T1_HCHP":16471255,"T1_HCHC":7455208,"T2_PTEC":"----","T2_PAPP":0,"T2_BASE":0,"INDEX_C1":0,"INDEX_C2":0}
[19.08.2020] [22:08:44] [WARNING] [QA_ECODEVICES_398]: readEcodevices>>>Erreur lors de l'appel de changePeriode : ./include/main.lua:451: attempt to compare number with nil
[19.08.2020] [22:08:54] [TRACE] [QUICKAPP401]: Le QA Diagnostics a été mise a jour : Prochane mise a jours dans 60 mn--

Et pourtant sur le plugin visuel je n'ai rien de rien (cf:pj)

Si vous avez une idée je suis preneur.

En vous remerciant

**Barelle** · le 20 août 2020

Je viens de diffuser une nouvelle version corrigeant un certain nombre de dysfonctionnement, pourrais-tu refaire un essai ?

En cas de nouveau problème, en plus d'une copie des log, merci de joindre une copie d'écran des différentes variables du QA utilisées.

**jjacques68** · le 20 août 2020

tu as réalisé ce QA avec quelle version de Firmware de la HC3 ?

**Barelle** · le 20 août 2020

Début de réalisation en 5.040.37, actuelle 5.040.37, la dernière...

Je vois mal l'intérêt de cette info

**jjacques68** · le 20 août 2020

et ben si justement !

j'ai essayé de l'installer.

J'ai rien, aucun champs, pas une seule ligne de code !

et cela vient du fait qu'avec la dernière version, il y a la gestion des "fichiers" dans les QA.

Moi je suis resté en version n-1.

Donc visiblement les QA réalisés dans la dernière version ne sont pas utilisables sur la version n-x !

Modifié le 20 août 2020 par jjacques68

**Barelle** · le 20 août 2020

Si tel est le cas, la créativité du développeur stagiaire de Fibaro mérite toute mon admiration :7:

**jjacques68** · le 20 août 2020

ben c 'est pourtant le cas, si tu édites le fichier .fqa, tu verras dans la première ligne, la version de l'API.

Ton QA est en 1.2

chez moi, si j'exporte un QA, je suis en 1.1...

Après, la dernière mise à jour a fait beaucoup de changements, je comprends que l'import/export vers une version plus ancienne pose problème...

faudrait peut-être le préciser dans ton premier post, "à partir de la version xxx".

Je voulais voir la méthode que tu utilises pour interroger l'Ecodevice...

J'ai pu le voir en éditant le fichier .fqa...

Moi je passe par une socket TCP, pas par une requête HTTP.

Le résultat est le même, heureusement ...

**Barelle** · le 20 août 2020

As-tu fais l'essai en changeant le 1.2 en 1.1 ? Juste pour voir (ou savoir)...

**jjacques68** · le 20 août 2020

ça nan, j'ose pas prendre ce risque ...

**Barelle** · le 20 août 2020

Je viens de faire le test, tout s'est bien passé...

**jjacques68** · le 20 août 2020

avec la nouvelle version de firmware oui ! dans ce sens ça marche !

Mais dans l'autre sens... ???

**Barelle** · le 20 août 2020

Toi seul à le pouvoir d'apporter une réponse

**jjacques68** · le 20 août 2020

Bon j'ai essayé, j'avais les backup sous le coude au cas où

Ben rien à faire, même en forçant la version de l'API (dans le .fqa), j'ai rien.

Pas une seule ligne de code n’apparaît.

Je vois les variables du QA, tous les label sont superposé les uns sur les autres.

Mais c'est tout.

**Manu31** · le 21 août 2020

Bonjour,

Effectivement, avec cette nouvelle version tout marche nickel

Un immense merci à toutes et tous :13:

Ps: petite question qui est hors sujet de ce poste:

Comment transformez vous vos plugins HC2 (*.vfib en HC3 *.fqa).

Car j'ai un plugin (et je me rappel plus ou je l'ai trouvé) pour mes climatiseurs Daikin au top et j'e l'appréciais fortement.

Réécriture obligtoire ou existe-t-il des petites app pour aider à convertir ?

**Barelle** · le 21 août 2020

A ma connaissance il n'existe pas, et il n'existera probablement jamais d'outils permettant la migration d'un VD vers un QA, l'architecture logicielle de l'un étant fondamentalement différente de celle de l'autre.

A titre d'illustration, dans le VD que tu montres, il est quasiment certain que le code de chacun des boutons 1, 2, 3, 4, 5 est identique hormis quelques caractères.

Lors d'une réécriture des fonctions d'un VD sous forme de QA, tout ce qui est interface utilisateur, mais aussi requêtes vers d'autres systèmes change ; en revanche le traitement des données (logique purement applicative - ou "métier") peut lui être repris.

**Manu31** · le 21 août 2020

@Barelle : Merci beaucoup pour ta réponse. Dès que j'aurai un peu plus de temps, je termine ma migration HC2 vers HC3 et j'essayerai de réécrire ce plugin

Bonne journée

**RedAlan** · le 20 septembre 2020

@Barelle Super, ça fonctionne nickel, a part l'icône de l'ecodevice que je ne peux pas changer. Je voudrais savoir si dans ton code a un moment tu récupères le mode de consommation en cours (Heure plein /heure Creuse), je voudrais récupérer l'info dans une variable globale pour lancer des scènes en heures creuses

Bonne journée

**Barelle** · le 20 septembre 2020

La variable globale EcoDevices contient les dernières valeurs calculées, et la periode en cours, illustration :

{
	"teleinfo1": {
		"abonnement": "HPHC",
		"hourTotalIndex": 43177383,
		"HCIndex": 16806364,
		"monthTotalIndex": 42984543,
		"HChourTotalIndex": 16806364,
		"HPIndex": 26371262,
		"yearTotalIndex": 42984543,
		"puissanceApparente": 1020,
		"lastTotalIndex": 43177626,
		"HCdayTotalIndex": 16795809,
		"HCmonthTotalIndex": 16736947,
		"HPhourTotalIndex": 26371019,
		"dayTotalIndex": 43163591,
		"HPdayTotalIndex": 26367782,
		"HPmonthTotalIndex": 26247596,
		"periode": "HP..",
		"HCyearTotalIndex": 16736947,
		"consoActuelleWh": 13,
		"HPyearTotalIndex": 26247596
	},
	"firstUpdate": 1596054883,
	"lastUpdate": 1600593556,
	"compteur1": {
		"consoActuelle": 0,
		"monthIndex": 631288536,
		"lastIndex": 631307338,
		"hourIndex": 631307338,
		"yearIndex": 631288536,
		"dayIndex": 631301392
	},
	"compteur2": {
		"consoActuelle": 0,
		"monthIndex": 669708259,
		"lastIndex": 669740960,
		"hourIndex": 669740960,
		"yearIndex": 669708259,
		"dayIndex": 669735562
	},
	"teleinfo2": {
		"abonnement": "BASE",
		"hourTotalIndex": 0,
		"monthTotalIndex": 0,
		"dayTotalIndex": 0,
		"periode": 0,
		"yearTotalIndex": 0,
		"BASEIndex": 0,
		"puissanceApparente": 0,
		"consoActuelleWh": 0,
		"lastTotalIndex": 0
	}
}

Pour l'icône des QA, c'est compliqué, car toujours non prévu par Fibaro. Je l'ai ajoutée pour un capteur de température et ai relevé son numéro.

**MAM78** · le 7 décembre 2020

Est-ce qu'il serait possible de pouvoir afficher dans un Child les index HC et HP ?

J'ai bien vu que l'info est dispo. dans la variable Globale mais cela pourrait être pratique lorsque EDF nous demande de leur communiquer le relevé d'index et que l'on est pas à son domicile, nous pourrions avoir l'info sur l'App Fibaro.

**Barelle** · le 7 décembre 2020

Afficher, dans un seul child les index HC et HP me semble difficile, surtout que dans le cas d'un abonnement Tempo, il faudrait y afficher six index...

Par contre, il est possible de prévoir :

D'afficher les index directement dans le QA,
Eou de prévoir un child par index, avec la possibilité de choisir lesquels créer.

Une préférence ?

Quick App - Ecodevice v1

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

Barelle

Barelle

Barelle

Images postées