Netatmo Wetterstation - Anemometer - Windrichtung - Himmelsrichtungen

[Terdious]

Hallo,

Wie in anderen Themen bereits erwähnt, hat @damalgos die Entwicklung des Netatmo-Dienstes übernommen. Ich versuche, ihm mit dem Material, das ich besitze, zu helfen.
Derzeit arbeite ich am Modul der Wetterstationen. Wir denken, dass wir beim Regenmesser gut dastehen.
Beim Anemometer erhalten wir alle Daten, aber ich hätte mir gewünscht, dass es aussagekräftiger wäre.
Derzeit erhalten wir den Windwinkel in Grad. Ich habe im Ordner utils eine Datei cardinalpoints hinzugefügt, um diese Winkel in Himmelsrichtungen mit einem Pfeil umzuwandeln. Das funktioniert gut, wie in den Logs zu sehen ist. Leider akzeptiert der Wert der Tabelle device_feature_state in der Datenbank keine alphanumerischen Zeichen. Ich habe daher nach einem Beispiel gesucht und das einzige, das ich gefunden habe, ist die Kamera. Diese scheint jedoch nur die Spalte last_value_string der Tabelle device_feature zu verwenden. Es sei denn, ich irre mich…
@pierre-gilles, wäre es möglich, eine Spalte « value_string » in der Tabelle device_feature_state hinzuzufügen, die es uns ermöglichen würde, den letzten Wert in last_value_string zu erhalten, und dann auf dem Dashboard, wenn wir einen DEVICE_FEATURE_TYPE.SENSOR.STRING erstellen, um den Wert in der richtigen Spalte zu erhalten?

Vielen Dank im Voraus. Da ich mit @damalgos gut vorangekommen bin, wäre es gut, wenn wir schnell in diesem Bereich vorankommen könnten. Ich habe noch 1 Woche mit viel Zeit, um an dem Thema zu arbeiten.

Bilder des Fortschritts:

[Terdious]

Also, ich konnte alle Änderungen vornehmen, um mein Ziel zu erreichen:

Ich finde das für eine vollständige Wetterstation eher nicht schlecht. Jetzt stellt sich die Frage der Machbarkeit, wobei man bedenken muss, dass dafür Änderungen in der Datenbank erforderlich sind, und zwar in der Tabelle t_device_feature_state:

• Eine neue Spalte value_string vom Typ « Text » erstellen,
• Die beiden Spalten value und value_string auf is_nullable=YES setzen.
• Die Datei server/lib/device/device.newStateEvent.js mit dem folgenden Vergleich ändern, um die richtige Spalte zu treffen

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

• Und noch einige andere Dateien auf der Frontend-Seite (für die Anzeige der Daten) und auf dem Server.

Wir werden also auf eine Antwort von @pierre-gilles warten, insbesondere für das Go von diesem Thema.

In diesem Zustand ist die Wetterstation funktionsfähig.

[Tlse-vins]

Es ist super, diese Infos zu haben.
Was ist der CO2 996 %?

Ich warte auf die Netatmo-Heizungssteuerung.

[pierre-gilles]

@Terdious

@pierre-gilles, wäre es möglich, eine Spalte „value_string“ in die Tabelle device_feature_state hinzuzufügen, die es uns ermöglicht, den letzten Wert in last_value_string abzurufen, und dann im Dashboard, wenn wir einen DEVICE_FEATURE_TYPE.SENSOR.STRING erstellen, um den Wert in der richtigen Spalte abzurufen?

Kannst du erklären, warum ihr das braucht? Ich sehe nichts in den Daten, die du in der UI anzeigst, das ein String ist

[Terdious]

Ach ja, Mist, man kann die Einheit ändern, was ich nicht gemacht habe ^^ es sind 996 ppm in Wirklichkeit ^^

Ja

@Tlse-vins

Ich warte auf die Netatmo-Heizungssteuerung.

@damalgos hat bereits den Thermostat zurückgegeben. Ich kümmere mich um die Ventile bis zum Wochenende. Danach bleibt uns noch die Einstellung, aber ich glaube, @damalgos wartet auf eine Rückmeldung.

[Terdious]

Hallo @pierre-gilles,
Die Werte Windwinkel, Böenwinkel, Maximaler Windwinkel des Tages…
Ich verstehe deine Frage nicht ganz.
Wir zeigen Werte wie « -> O » « <- W » usw. an.

[pierre-gilles]

@Terdious

Die Werte Windwinkel, Böenwinkel, Maximaler Windwinkel des Tages…
Ich verstehe deine Frage nicht.
Wir zeigen Werte wie „-> O“, „<- W“ usw. an.

Okay, also sprechen wir über einen Winkel auf einem Kompass, einverstanden?

Solche Werte werden in der Regel als Winkel in Grad (0-360°) gespeichert.

Siehe:

Ich empfehle, die Werte als Ganzzahl zu speichern (kein String nötig), und dann in der UI einen speziellen Typ zu erstellen, der « N » anstelle von 0° anzeigt, « S » anstelle von 180°.

Dadurch wird die Richtung übersetzt, da nicht alle Sprachen die gleichen Buchstaben für die Himmelsrichtungen haben.

Beispiel, selbst zwischen Englisch und Französisch gibt es Unterschiede:

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

Was denkst du?

[pierre-gilles]

@Terdious

Danach bleibt uns noch die Anweisung, aber ich glaube, @damalgos wartet auf eine Rückmeldung.

Tatsächlich ist das Thema Heizung ein eigenes Thema in Gladys, und wir sind noch nicht einmal in der Phase der „Spezifikation“ dieses Teils.

Versucht, euer PR zu trennen, meiner Meinung nach, denn Heizung ist keine Kleinigkeit, das wird nicht so schnell gehen, denke ich.

[Terdious]

Ich verwende eine Funktion, die im Dateipfad server/utils/cardinalpoint.js gespeichert ist:

/** 
 * 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,
  };

Für die Windrichtung gibt es 16 mögliche Richtungen. Ich fand es einfacher, den Wert als String in der DB abzurufen, aber ich hatte nicht daran gedacht, dies in der UI zu tun. Ich werde es auf der Frontend-Seite ändern.

[damalgos]

@pierre-gilles

Versucht, euer PR meiner Meinung nach zu trennen, denn Heizung ist keine Kleinigkeit, das wird nicht so schnell gehen, denke ich

Am besten wäre es meiner Meinung nach, zunächst die Netatmo-PR umzusetzen, die die Thermostatköpfe findet und die Information bereitstellt.

In einem zweiten Schritt wird ein PR für die Heizung erstellt, um genau diese Problematik zu lösen

[pierre-gilles]

Das passt mir!

Beim Heizungsteil sollte man meiner Meinung nach vor dem Start der Entwicklung wirklich eine echte Studie über die verschiedenen Lösungen auf dem Markt durchführen und wie man das in Gladys harmonisieren kann. Ich denke, es lohnt sich, sich über Marktakteure wie Nest zu informieren, die diese Arbeit bereits geleistet haben, und dann eine funktionale und technische Spezifikation zu erstellen.

Schließlich können wir implementieren, aber wir sind noch sehr weit davon entfernt.

(darüber sprechen wir im anderen Thema)

Edit: Ich komme trotzdem darauf zurück:

@damalgos

Am besten wäre es meiner Meinung nach, zunächst den Netatmo-PR zu implementieren, der die Thermostate findet und die Information bereitstellt.

Man muss darauf achten, den Benutzer nicht in die Irre zu führen. Wenn wir die Thermostate verwalten, dann richtig. Ich bin mir nicht sicher, ob wir dem Benutzer etwas halbherzig Gemanagtes anzeigen wollen.

Vielleicht würde ich mich eher auf einen ersten PR für Wetterstationen / Anemometer und Co. (Sensoren) konzentrieren und dann einen Netatmo-Heizungs-PR machen?