Netatmo Weather Station - Anemometer - Wind Direction - Cardinal Points

[Terdious]

Hello,

As mentioned in other topics, @damalgos has taken over the development of the Netatmo service. I am trying to help him with the equipment I have. I am currently working on the Weather Station Modules part. We think we are good with the rain gauge.

For the anemometer, we are retrieving all the data, but I would have liked it to be more descriptive. Currently, we retrieve the wind angle in degrees. I added a file called cardinalpoints in the utils folder to convert these angles into cardinal points with an arrow. It works well, retrieved in the logs. Unfortunately, the value of the device_feature_state table in the database does not accept alphanumeric characters. I therefore looked for an example and the only one I found is the camera. However, it apparently only uses the last_value_string column of the device_feature table. Unless I am mistaken…

@pierre-gilles, would it be possible to add a « value_string » column to the device_feature_state table that would allow us to retrieve the last value in last_value_string and then on the dashboard, if we create a DEVICE_FEATURE_TYPE.SENSOR.STRING, to retrieve the value in the correct column?

Thanks in advance. As we are well advanced with @damalgos, it would be great to be able to move quickly on this subject. On my side, I only have 1 week with a lot of time available to work on the subject.

Images of the progress:

[Terdious]

Well, I was able to make all the modifications to achieve my goal:

I think it’s pretty good for a complete weather station. Now, regarding feasibility, considering that to get there, modifications need to be made in the DB, specifically in the t_device_feature_state table:

• Create a new value_string column of type « Text »,
• Set the two columns value & value_string to is_nullable=YES.
• Modify the file server/lib/device/device.newStateEvent.js with the following comparison to target the correct column

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

• As well as quite a few other files on the front end (for data display) and on the server.

We will therefore wait for a response from @pierre-gilles, especially for the green light on this subject.

As it stands, the weather station is functional.

[Tlse-vins]

It’s great to have this info.
What is the 996% CO2?
I’m waiting for the Netatmo heating management.

[pierre-gilles]

@Terdious

@pierre-gilles, would it be possible to add a « value_string » column in the device_feature_state table that would allow us to retrieve the last value in last_value_string and then on the dashboard, if we create a DEVICE_FEATURE_TYPE.SENSOR.STRING, to retrieve the value in the correct column?

Can you explain why you need this? I don’t see anything in the data you display in the UI that is in string format

[Terdious]

Oh yes, oops, you can change the unit, which I didn’t do ^^ it’s 996ppm in fact ^^

Yes

@Tlse-vins

I’m waiting for the Netatmo heating management.

@damalgos has already provided feedback on the thermostat. I’ll look into the valves by the weekend. After that, we still have the setpoint to do, but I think @damalgos is waiting for feedback.

[Terdious]

Hello @pierre-gilles,
The values Wind angle, Gust angle, Max Wind angle day…
I don’t understand your question in this case.
We display values « -→ E », « <- W » … etc.

[pierre-gilles]

@Terdious

The values Wind angle, Gust angle, Max Wind angle day…
I don’t understand your question in this case.
We display values “-→ E”, “< - W” … etc.

Ok, so we’re talking about an angle on a compass, right?

This kind of value is generally saved as an angle in degrees (0-360°)

Cf:

I advise you to save your values as integers (no need for strings), and then in the UI you need to create a special type that will display « N » instead of 0°, « S » instead of 180°.

This will allow you to have the direction translated, as not all languages have the same cardinal letters.

For example, just between English and French there are differences:

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

What do you think?

[pierre-gilles]

@Terdious

After that, we still have the instructions to do, but I think @damalgos is waiting for feedback.

Indeed, the heating part is a subject in itself in Gladys, and we are not even at the « specification » stage of this part.

I suggest you try to separate your PR because heating is no small matter, I don’t think it will be for now.

[Terdious]

I’m using a function in the file 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,
  };

For the wind angle, there are 16 possible directions. I thought it would be simpler to retrieve the value as a string from the database, but I didn’t think about doing that in the UI. I’ll look into passing it to the front end.

[damalgos]

@pierre-gilles

Try to separate your PR in my opinion because heating is no small matter, it won’t be for right away I think

The best would be in my opinion to first implement the netatmo PR which finds the thermostatic heads and provides the information.

In a second step, a PR for heating is done to specifically address these issues

[pierre-gilles]

That works for me!

For the heating part, before diving headfirst into development, I think we really need to conduct a thorough study of the different market solutions and how we can harmonize them in Gladys. I think it would be worth researching market players like Nest who have already done this work, then writing a functional and technical specification.

Finally, we can implement it, but we are very far from that.

(We’ll talk about this in the other topic)

Edit: I’ll still comment on this:

@damalgos

The best would be, in my opinion, to first implement the Netatmo PR that finds the thermostatic heads and provides the information.

We need to be careful not to mislead the user; if we manage the thermostatic heads, we manage them well. I’m not sure we want to display something half-managed to the user.

Maybe I would stick with a first PR for weather stations / anemometers, etc. (sensors), and then do a Netatmo heating PR?