Barelle

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

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

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.

HC3-00003400 mai 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...

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.

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. 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

Oups, la photo ci-dessus est celle du pluviomètre. En fait, je suspecte plus un problème de condensation car je n'ai pu identifier une quelconque erreur de conception. Mettre du gel électrique pourrait-être effectivement une solution, sous réserve qu'il ne s'écoule pas vers le compartiment des piles.

J'ai eu également ce souci au bout de 4 ans avec l'anémomètre, la plaque était oxydée...

os.time() retourne un temps en secondes écoulé depuis le 1er janvier 1970 à minuit. Je te suggère d'essayer : fibaro:setGlobal('time_last_rain', os.time{year=2020, month=6, day=17, hour=0}) cf.la doc Lua pour mieux comprendre...

Dans le code on trouve : WindStrength = { type = "com.fibaro.windSensor", unit = "m/s", conversion = function(value) return value/3.6 end }, Il suffit de remplacer 3.6 par 1 (ou de supprimer la fonction conversion...) et de changer "m/s" en "km/h.

Dans ce que je comprends à la lecture du code, le coût de l'abonnement est calculé en se basant sur le nombre de jours, les autres coûts sont proportionnels au volume d'eau consommé (en litres). Certaines variables ou fonctions mériteraient d'être renommées, ainsi : * production devrait s'appeler consommation, à moins que l'on produise de l'eau... * le J dans pollution, par souci de cohérence devrait être remplacé par un L, * les J dans les textes de debug n'apportent rien, * les variables globales y gagneraient en lisibilité si Compteur était remplacé par Index... * de même, les variables calc_ auraient pu être nommées conso_ pour faciliter la compréhension.

local Compteur_eau = fibaro:getGlobal("IC1") Où la variable globale "IC1" est-elle renseignée ? Si elle n'existe pas, Compteur_eau vaudra nil...

Nous sommes d'accord , mais ma réponse citée précédemment concernait la nécessité d'un Ou au lieu d'un ET...

Ouais , sauf que, sunrise est toujours positif et sunset jamais négatif ! C'est plutôt le timestamp courant qui doit être compris entre les deux

Merci, c'est commandé.

Oui, j'utilise Hi--Connect sur un vieux smartphone sans carte Sim. Et pour l'avoir essayé à l'instant, avec HiLook également.

Les applications Hik-Connect et hiLook le font. EZVIZ également. Après, les goûts et les couleurs

Concernant le standard 802.3, c'est devenu une norme (ISO/IEC 60950), il n'y a donc pas de coût de licence. Effectivement le danger réside dans les vieux matériels non-conformes et pas seulement de marque Ubiquiti.

Pour ceux qui voudraient en savoir un peu plus, et d'après ce que je comprends : - Pour le POE passif, la tension est toujours présente, d'où un risque pour les équipements non compatibles. Manifestement d'autres qu'Ubiquiti ont utilisé cette solution cf. https://www.tp-link.com/fr/support/faq/906/ - Pour le POE standard (802.3af ou 802.3at), il y a négociation lors du branchement, ainsi selon http://notionsinformatique.free.fr/reseaux/POE_Conectis.pdf : L’alimentation fournie sur l’infrastructure de réseau local est automatiquement activée lors du raccordement et de l’identification d’un terminal compatible. Elle est coupée également de manière automatique lorsque les équipements raccordés ne sont pas compatibles, assurant ainsi la protection de ceux-ci, mais également celle de l’ensemble de l’infrastructure. Plus concrètement, lors de la connexion, une faible tension est appliquée entre les câbles Tx et Rx, si la résistance est de l'ordre de 25k Ohm, l'équipement est compatible. La séquence de négociation peut alors commencer. Fin de mon analyse

Je n'ai pas la prétention d'avoir raison, je me suis juste permis d'éclairer le sujet à partir de différents éléments techniques. Il est plus que probable qu'Ubiquiti, comme toute société US fasse valider ses notices par ses avocats. La notice fait bien de préciser ce point pour se couvrir juridiquement.

C'est bien, avec d'autres mots, ce que j'ai décrit

La question ne se pose pas en termes de couleurs des fils selon le standard T568A ou T568B, mais selon l'usage qui est fait de chacune des pins du connecteur. Selon https://en.wikipedia.org/wiki/Power_over_Ethernet 802.3af Standards A and B from the power sourcing equipment perspective Pins at switch T568A color T568B color 10/100 mode B, DC on spares 10/100 mode A, mixed DC & data 1000 (1 gigabit) mode B, DC & bi-data 1000 (1 gigabit) mode A, DC & bi-data Pin 1 White/green stripe White/orange stripe Rx + Rx + DC + TxRx A + TxRx A + DC + Pin 2 Green solid Orange solid Rx − Rx − DC + TxRx A − TxRx A − DC + Pin 3 White/orange stripe White/green stripe Tx + Tx + DC − TxRx B + TxRx B + DC − Pin 4 Blue solid Blue solid DC + Unused TxRx C + DC + TxRx C + Pin 5 White/blue stripe White/blue stripe DC + Unused TxRx C − DC + TxRx C − Pin 6 Orange solid Green solid Tx − Tx − DC − TxRx B − TxRx B − DC − Pin 7 White/brown stripe White/brown stripe DC − Unused TxRx D + DC − TxRx D + Pin 8 Brown solid Brown solid DC − Unused TxRx D − DC − TxRx D −

Cela semble effectivement fonction du câblage, pas de celui des prises et de la couleur des fils, mais des fils sur lesquels la tension est appliquée. Extrait de https://www.poetexas.com/blogs/news/mode-b-vs-mode-a-whats-up-with-that Here you can see Mode A, with power on pins 1, 2, 3, and 6… And here is Mode B, with power on pins 4, 5, 7, and 8… Merci d'avoir insisté, cela m'a permis d'apprendre quelque chose...

Quand j'étais petit, Dell avait déjà mauvaise réputation, IBM imposait l'uniforme, Dec avant son rachat était apprécié, HP ne vendait en France que des instruments de mesure... La dégradation des conditions de travail, trouve, selon moi, sa source dans les orientations politiques largement diffusées par les grands cabinets de conseil américains auprès des entreprises et de certains gouvernements (en France sous Sarko), on y retrouve des aspects pertinents (KISS, tout ce qui se mesure s'améliore...) mais aussi des dogmes (big is beautiful, l'unité de mesure comprise par tout le monde est monétaire, do more with less...). Ces idées brillamment diffusées auprès des DG ont peu à peu envahi le monde de l'entreprise et les écoles de commerce ou d'administration. Cela a débouché vers le développement d'un système financiarisé à outrance où les dividendes versés aux actionnaires deviennent un objectif qui prime sur la qualité du service rendu au client ou sur la vision industrielle qui elle s'inscrit dans le temps long. On assiste donc à une partition (accentuée par le code des marchés publics) avec d'un coté les grandes sociétés (ou organismes) qui confient leurs grandes commandes aux grandes entreprises, et de l'autre les PME, qui hésitent moins à confier des travaux à des boites plus humaines. Mais dès qu'une petite entreprise devient attractive, elle se fait racheter par une plus grosse, c'est d'ailleurs très souvent l'objectif des startuppers qui exploitent sans vergogne de jeunes développeurs en leur faisant miroiter des avantages et un état d'esprit (baby-foot, massages...) et qui s'empresse de faire la culbute dès que leur bébé a acquis suffisamment de notoriété pour être vendu ; l'acquéreur, fréquemment, se dépêchant de fermer sa nouvelle acquisition en l'accusant de défaut de rentabililité. Il existe des contre-exemples comme Fibaro ou Netatmo, pour notre domaine d'intérêt. Désolé d'avoir pourri ton post sur l'onduleur connecté.