Netatmo Station Météo - Anémomètre - Sens du vent - Points cardinaux

[Terdious]

Bonjour,

Comme rappelé dans d’autres sujet, @damalgos a repris le développement du service Netatmo. Je tente de lui apporter mon aide avec le matériel en ma possession.
Je suis actuellement sur la partie Modules des Stations Météo. On pense être bon côté pluviomètre.
Côté Anemometre on récupère bien toutes les données, mais j’aurais aimé que ce soit plus parlant.
On récupère actuellement l’angle du vent en degré. J’ai rajouté dans le dossier utils un fichier cardinalpoints pour transformer ces angles en points cardinaux avec une flèche. Ca fonctionne bien, récupéré dans les logs. Malheureusement en BDD la value de la table device_feature_state n’accepte pas l’alphanumerique. J’ai donc cherché si on avait un exemple et le seul que j’ai trouvé est la caméra. Mais celle-ci n’utilise apparemment que la colonne last_value_string de la table device_feature. A moins que je me trompe…
@pierre-gilles, serait-il possible de rajouter une colonne “value_string” dans la table device_feature_state qui nous permettrait de récupérer la dernière valeur dans last_value_string puis sur le dashboard, si on crée un DEVICE_FEATURE_TYPE.SENSOR.STRING, pour récupérer dans la bonne colonne la valeur ?

Merci par avance. Etant bien avancé avec @damalgos, il serait bien de pouvoir avancer rapidement sur le sujet. De mon côté je n’ai qu’1 semaine avec beaucoup de temps dispo pour bosser sur le sujet.

Images de l’avancement :

[Terdious]

Bon j’ai pu faire toute les modifications pour arriver à mes fins :

Je trouve ça plutôt pas mal pour une station météo complète. Maintenant qesako de la faisabilité en sachant que pour en arriver là il faut faire des modifs en DB, soit dans la table t_device_feature_state :

• Créer une nouvelle colonne value_string en type “Texte”,
• Passer les 2 colonnes value & value_string en is_nullable=YES.
• Modifier le fichier server/lib/device/device.newStateEvent.js avec la comparaison suivant pour taper la bonne colonne

if(isNaN(event.state)) {
      await this.saveStringState(device, deviceFeature, event.state);
    } else {
      await this.saveState(deviceFeature, event.state);
    }

• Ainsi que pas mal d’autres fichiers en front (pour l’affichage des données) et en server.

On va donc rester en attente d’une réponse de @pierre-gilles notamment pour le feu vert sur ce sujet.

En l’état la station météo est fonctionnelle.

[Tlse-vins]

C’est super d’avoir ces infos.
C’est quoi le CO2 996 %?

Moi j’attends la gestion de chauffage netatmo.

[pierre-gilles]

@Terdious

@pierre-gilles, serait-il possible de rajouter une colonne “value_string” dans la table device_feature_state qui nous permettrait de récupérer la dernière valeur dans last_value_string puis sur le dashboard, si on crée un DEVICE_FEATURE_TYPE.SENSOR.STRING, pour récupérer dans la bonne colonne la valeur ?

Tu peux expliquer pourquoi vous avez besoin de ça ? Je ne vois rien dans les données que tu affiches dans l’UI qui soit en string

[Terdious]

Ah oui mince, on peut changer l’unité, ce que je n’ai pas fait ^^ c’est 996ppm en fait ^^

Oui

@Tlse-vins

Moi j’attends la gestion de chauffage netatmo.

@damalgos a déjà fait le retour du thermostat. Je vois pour les vannes d’ici le week-end. Apres il nous reste la consigne à faire, mais je crois que @damalgos est en attente d’un retour.

[Terdious]

Salut @pierre-gilles,
Les valeurs Wind angle, Gust angle, Max Wind angle day…
Je ne comprend pas ta question pour le coup.
On affiche des valeurs “-> E”, “<- W” … etc.

[pierre-gilles]

@Terdious

Les valeurs Wind angle, Gust angle, Max Wind angle day…
Je ne comprend pas ta question pour le coup.
On affiche des valeurs “-> E”, “<- W” … etc.

Ok, donc on parle d’un angle sur un compas on est d’accord ?

Ce genre de valeur est en générale sauvegardé en tant qu’angle en degrés (0-360°)

Cf :

Je vous conseille de sauvegarder vos valeurs en tant qu’entier (pas besoin de string), et ensuite dans l’UI il faut créer un type spécial qui affichera « N » au lieu de 0°, « S » au lieu de 180°.

Cela permettra d’avoir la direction traduite, car toutes les langues n’ont pas les mêmes lettres de cardinaux.

Exemple, juste entre anglais et français il y a des différences:

N (North) - Nord
S (South) - Sud
E (East) - Est
W (West) - Ouest

Tu en pense quoi ?

[pierre-gilles]

@Terdious

Apres il nous reste la consigne à faire, mais je crois que @damalgos est en attente d’un retour.

Effectivement la partie chauffage est un sujet à part entière dans Gladys, et on est même pas à l’étape « spécification » de cette partie.

Essayez de séparer votre PR à mon avis parce que le chauffage c’est pas une mince affaire, ça sera pas pour tout de suite je pense

[Terdious]

J’utilise une fonction mise dans le fichier server/utils/cardinalpoint.js :

/** 
 * Given "0-360" returns the nearest cardinal direction "N/NE/E/SE/S/SW/W/NW"  
 */
function getCardinalDirection(angle) {
    if (typeof angle === 'string') {
        angle = parseInt(angle);
    }
    if (angle <= 0 || angle > 360 || typeof angle === 'undefined') {
        return '☈';
    }
    const arrows = { north: '↑ N', north_north_east: '↗ NNE', north_east: '↗ NE', east: '→ E', south_east: '↘ SE', south_south_east: '↘ SSE', south: '↓ S', south_south_west: '↙ SSW', south_west: '↙ SW', west: '← W', north_west: '↖ NW', north_north_west: '↖ NNW' };
    const directions = Object.keys(arrows);
    const degree = 360 / directions.length;
    angle = angle + degree / 2;
    for (let i = 0; i < directions.length; i++) {
      if (angle >= (i * degree) && angle < (i + 1) * degree) {
          return arrows[directions[i]];
        }
    }
    return arrows['north'];
  }
  module.exports = {
    getCardinalDirection,
  };

Car pour l’angle du vent il y a 16 direction possible. Je trouvais cela plus simple de récupérer la valeur en String dans la DB mais en effet je n’avais pas pensé à faire ça dans l’ui. Je vois pour le passer côté front du coup.

[damalgos]

@pierre-gilles

Essayez de séparer votre PR à mon avis parce que le chauffage c’est pas une mince affaire, ça sera pas pour tout de suite je pense

Le mieux serait à mon avis de metttre en place tout d’abord la PR netatmo qui trouve les têtes thermostatique et fournis l’information.

Dnas un second temps une PR pour le chauffage se fait pour justement répondre à ces problématiques

[pierre-gilles]

ça me va!

Pour la partie chauffage, pour moi avant de se lancer tête baissé dans le développement il faut vraiment faire une vrai étude sur les différentes solutions du marché, et comment on peut harmoniser ça dans Gladys. Je pense que ça vaudrait le coup de se renseigner sur les acteurs du marché comme Nest qui ont déjà fait ce travail, et ensuite écrire une spec fonctionnelle puis technique.

Enfin, on pourra implémenter, mais on en est très loin.

(on en parle sur l’autre sujet)

Edit: je rebondis quand même sur ça:

@damalgos

Le mieux serait à mon avis de metttre en place tout d’abord la PR netatmo qui trouve les têtes thermostatique et fournis l’information.

Il faut faire attention à ne pas induire l’utilisateur en erreur, les têtes thermostatiques si on les gère on les gère bien, je suis pas sûr qu’on veuille afficher à l’utilisateur quelque chose d’à demi géré.

Je resterais peut-être plus sur une première PR stations météo / anémométre et cie (capteurs), et ensuite faire une PR chauffage netatmo?