NetatmoWeather

Hallo,

ich habe ein neues Modul erstellt.

Zu finden ist es hier: https://github.com/demel42/NetatmoWeather.

Was macht das Modul?

Es werden die Daten von einer Netatmo-Wetterstation ausgelesen und gespeichert. Es werden alle Module unterstützt in der maximalen Ausbaustufe: Basis-, Außen- und 3 Innenmodule sowie WInd- und Regenmesser.

Zusätzlich werden einige Status-Information ermittelt und als Variablen zur Verfügung gestellt, unter anderen

[ul]
[li]Status der Kommunikation mit Netatmo
[/li][li]Batterie- und Modul-Alarme als Zusammenfassung der Station der einzelnen Module als auch optional für jedes Modul separat
[/li][li]weitere (im wesentlichen modulbezogene) Status-Informationen werden in einer HTML-Box aufbereitet, hier hat man dann einen Überblick über alle Module (Zeitpunkte der letzten Kommunikation, Batterie und Signalstärken) sowie der Basisstation.
[/li][li]die Informationen werden auch als JSON-Struktur in einer Variable zur Verfügung gestellt
[/li][li]es können zusätzliche Wetter-Kenndaten berechnet werden: absoluter Luftdruck, Taupunkt, absolute Feuchte, Windchill, Heatindex
[/li][/ul]

Die geographіsche Position sowie die Höhe der Wetterstation werden von Netatmo übernommen und in die Instanz-Konfiguration als Property eingetragen
Es steht ein WebHook zur Verfügung, bei dem mit /hook/NetatmoWeathcer/status die Status-Information (analog zur HTML-Box) als Webseite abgerufen werden können.

Die Angabe der Netatmo-Zugangsdaten ist obligatorisch damit die Instanz aktiviert werden kann.

Weiterhin können die relevanten Wetterdaten in eine persönliche Wetterstation von Wunderground übertragen werden. Übertragen wird:

[ul]
[li]Innenmodul: Luftdruck
[/li][li]Aussenmodul: Temperatur, Luftfeuchtigkeit und der daraus berechnete Taupunkt
[/li][li]Regenmodul: 1h und 24h-Wert
[/li][li]Windmesser: Windgeschwindigkeit und -richtung sowie Geschwindigkeit und Richtung von Böen
[/li][/ul]

Über den Upload gibt es natürlich auch einen Status-Information.

Voraussetzung ist IPS 4.x und natürlich eine Netatmo-Wetterstation.

Es ist mein erstes Modul, also bitte ich um Nachsicht.

Mein besonderer Dank an dieser Stelle geht an fonzo, der mir mit viel Geduld auf die Sprünge geholfen hat.

demel

Gibt es doch schon, oder?
Modul: Netatmo
Michael

Ich besitze kein Netatmo, würde aber mal schätzen das dies Modul umfangreicher ist bzw. mehr abbildet, kann aber kein Vergleich anstellen. Gibt ja auch zwei Wunderground Module mit unterschiedlichem Funktionsumfang ;).

Und beide entsprechend nicht dem Best Practice :wink:
Wieder ein Modul welches einen ApplyChanges auf sich selbst ausführt und die Namen der Variablen eigenmächtig ändert.
Wenn die Umsetzung endlich mal sinnvoll wäre. Also jede Station ist eine eigene Instanz…
Michael

Ich habe es noch nicht im Detail angeschaut, aber ist doch zunächst prima das es überhaupt was gibt :p. Und wie oben steht Nachsicht üben, ist ja denke ich nicht in Stein gemeißelt sondern der aller erste Versuch und Module entwickeln sich ja weiter. Ja selbst ich lasse mich von Dir eines besseren überzeugen :p, hast ja meist Recht mit Deinen Einwänden :cool:.

Das wäre in der Tat sinnvoll, heisst ja aber nicht das dies der letzte Stand ist.

Erst mal vielen Dank für das Teilen des Modul und das nach sehr kurzer Zeit überhaupt mit IP-Symcon.

Ich selber habe keine Möglichkeit das näher zu testen, da ich kein Netatmo nutzte mir sind aber folgende Dinge aufgefallen:

[ul]
[li]es gibt unterschiedliche Gerätetypen bei Netatmo, diese erheben je nach Typ auch unterschiedliche Werte[/li][li]das Modul nutzt in der jetzigen Form ein starres Konfigurationsformular[/li][/ul]

Ich würde vorschlagen:

[ul]
[li]falls die Geräte grundsätzlich unterschiedlich kommunizieren bei unterschiedlichen Geräten dann auch eine eigene Instanz pro Gerätetyp zur Verfügung zu stellen, also mit eigener GUID[/li][li]Wenn die Geräte sehr ähnlich sind und sich z.B. in den Variablen unterschieden, dann macht es Sinn eine Auswahl des Gerätetyps durch den Nutzer vornehmen zu lassen mit einem dynamischen Konfiguationsformular und GetConfigurationForm, dadurch besteht dann die Möglichkeit pro Gerät eine Instanz anzulegen und bei der Instanz dann aber auch nur die Variablen und Variablenprofile anlegen zu lassen die von dem Nutzer für den Gerätetyp verwendet werden.[/li][li]so was wie Modulbezogende Zusatzdaten würde ich dann auch nur zur Auswahl stellen wenn der passende Gerätetyp gewählt worden ist[/li][/ul]

Wenn es eine Möglichkeit gibt über den Netatmo Account sämtliche unter dem Account angemeldeten Geräte auszulesen kann es auch Sinn machen eine Konfigurator Instanz zu bauen. Diese würde die Daten Auslesen und in eine Liste schreiben. Dann kann der Benutzer auswählen welches der Geräte er in IP-Symcon nutzten will und eine solche Instanz würde dann angelegt werden.

Wenn ein dynamisches Formular benutzt wird kann man auch Inhalte die eventuell nicht benötigt werden ausblenden. So könnte man z.B. einen Haken setzten für Wunderground Upload nutzten. Und nur wenn dieser Haken gesetzt wird dann werden auch die Eingabefelder für Wunderground Station ID und Wunderground Station Key angezeigt.

hallo,
danke für die Anregung. aber vielleicht eine Anmerkung: die Variablen werden nicht eigenständig geändert sondern einmalig bei der ersten Anlage gesetzt.
Denn der erste Kommunikation ist ja nicht bekannt, wie die Module heissen, von daher dachte ich mir, bevor der Benutzer das am Anfang eingeben numm, kann ich ihm die Arbeit auch ersparen.

das mit den Instanzen hat sicherlich bei mir auch daran gescheitert, das ich das noch nicht so ganz verstanden habe.
Das ist ja an sich eine Wetterstation mit diversen Sensoren.
Warum sollte man die aufteilen in mehrere Instanzen? So ganz erschlisst sich mir das noch nicht.

Ein HM WDS-10 unterteilt man doch auch nicht in zeinInstanzen, einer mit Temperatur und einen mit Luftfeuchtigkeit. Lige ich da ganz falsch?

ich hatte das Modul gesehen und auch, das es dort schon längere Zeit kein Weiterentwicklung gab. In das ich das als Script schon lange Zeit laufen hatte (erst nativ als Webservice, dann auf Mediola und seit einigen Wochen auf IPS) hatte ich gedacht, ich teile, das was ich habe.

Grundsätzliche Anmerkung zu Variablen einer Instanz in IP-Symcon. Eine normale Instanz Variable einer nativen IP-Symcon Instanz hat Read Only Status, da die Variable nicht direkt beschrieben werden soll, sondern nur über einen Funktionsaufruf, der an die Instanz gerichtet ist. Das ist der Unterschied zu einer Variablen, die man selber in IP-Symcon erstellt, diese kann man auch beschreiben. Damit sich das einheitlich verhält, werden zukünftig auch Variablen von PHP Modulen Read Only Status haben. Daher kannst Du eigentlich jetzt schon, um für die Zukunft gerüstet zu sein, Variablen anders setzten.

Zur Zeit machst Du das so:


SetValue($this->GetIDForIdent('OUT_Windchill'), $windchill);

Dies kannst Du im Prinzip schon jetzt austauschen gegen:


$this->SetValue("OUT_Windchill", $windchill);

Dazu muss dann diese Methode ergänzt werden damit dies auch mit allen IP-Symcon Versionen funktioniert.


//Add this Polyfill for IP-Symcon 4.4 and older
	protected function SetValue($Ident, $Value)
	{
		if (IPS_GetKernelVersion() >= 5) {
			parent::SetValue($Ident, $Value);
		} else {
			SetValue($this->GetIDForIdent($Ident), $Value);
		}
	}

Im Prinzip ist in IP-Symcon eine Instanz ein Gerät, da es ja unterschiedliche Netatmo Geräte gibt mit unterschiedlichen Messwerten macht es Sinn das von der Logik beizubehalten, das dies auch für einen Nutzer nachvollziehbar ist. Wenn Du das mit Homematic vergleichen willst gibt es da auch viele Dinge, alles zusammen kann man viele Werte erfassen um Außendaten bzw. das Wetter zu messen. Dennoch ist ein hm-wds10 ein eigener Sensor und eine OC3 eine eigene Wetterstation, beides zusammen liefert Werte. So ist das ja im Prinzip bei Netatmo auch, das sind lauter einzelne Geräte die einzelne Messwerte liefern.

Das man als Nutzer in einer Visualisierung solche Werte dann alle gesammelt darstellt ist was anderes, das macht ja auch Sinn. Ich will ja das Wetter wissen, dabei ist mir egal welcher Sensor welchen Wert liefert. Solche Dinge werden aber von jedem Nutzer individuell zur Visualisierung aufbereitet, in IP-Symcon arbeitet man da dann am Besten mit Links auf die Original Variable in den Visualisierungsordner. Um alle Werte zusammen zu fassen kann man dann eine Dummy Instanz in der Visualisierung nutzten. Die Werte kommen aber von lauter einzelnen Sensoren und diese sollten nach Möglichkeit auch als solche für einen Nutzer in IP-Symcon erkenntlich sein. Wenn ein Sensor z.B. kaputt ist und ausgetauscht wird, dann lösche ich die entsprechende Instanz, wenn das nur eine Instanz ist in der alles steht geht das nicht, das Gerät habe ich also ausgetauscht oder weggeschmissen, aber in IP-Symcon ist alles in einer Instanz. Daher macht es schon Sinn physikalische Geräte, auch wenn diese zusammen eine Einheit bilden, auch so in IP-Symcon darzustellen.

Wirklich sinnvoll für User ist es doch nicht, wenn es nachher fünf verschiedene Implementierungen gibt.

Man müsste jetzt das alte Modul und auch alle Instanzen löschen, womit alle Archiv-Daten verloren gehen, nur um zu wechseln :rolleyes:

Es ist bestimmt auch möglich mit mehreren Personen an einem Modul zu arbeiten oder einen eigenen Fork davon zu entwickeln.
Dann wären die Instanzen mit GUIDs kompatible und ein Wechsel wäre für den User einfacher.
Den Autor vom ursprünglichen Modul mal angeschrieben? Vielleicht hat er einfach keine Zeit und hätte sich auch über eine Weiterentwicklung gefreut.

So der so, folgendes solltest du nie in Modulen machen:

  • Namen ändern ! (Der User hat bei der Namensgebung die Allmacht)
  • Daten in IPS-Variablen puffern (->GetIDForIdent(‚Data‘))
  • Ein IPS_Applychanges auf sich selbst aufrufen.
  • HTML-Tabellen sind schön, aber wenn weder abschalten oder das Style anpassen kann; verärgert es nur User wo das Design nicht passt oder welche mit Variablen sparen müssen.

Man merkt dem Code an, es war mal ein Script. Ein Modul ist es eher nicht.
Dafür ist es nicht modular genug.

Betatest mit anderen versierten IPS-Usern durchgeführt ?
Dann wären einige Punkte davon schon im Vorfeld aufgefallen.

Michael

Braucht man alles nicht und macht es nur komplizierter. Zumal ich mit ‚Modulbezogende Zusatzdaten‘ nichts anfangen kann.
Eine Adresse ? Ein GeräteTyp ? So etwas kann man als Info mit SetSummary in der Console darstellen. Brauchen als Nutzwert für eine IPS-Variable ? Eher nicht.

Die Dinger heißen Module weil man etwas modular aufbaut.
Also ein Modul für die Sensoren.
Wenn dann somit ein Sensor eine Instanz ist, was ich jetzt mal voraussetze; so ist der Typ des Gerätes / Sensors doch egal.
Die Daten welche man vom Dienst erhält geben doch Aufschluss ob es sich z.B. um Temperatur, Luftdruck, Wingeschwindigkeit usw. handelt.
Warum sollte ich das Konfigurieren wollen als User ?!

Statusvariablen einfach dynamisch anlegen sobald es dieses Datenfeld gibt, und mit festen eindeutigen Ident wie z.B. ‚Temperatur‘, ‚Humidity‘, ‚WindSpeed‘ usw. anlegen. Der Name entspricht in der Regel dem Ident, bzw wird noch mit Translate übersetzt.

Beispiel wie so etwas funktioniert ist z.B.
Xiaomi-Smart-Home/module.php at eed2e800eb0258b119877d8264b23aa42ef1d1ff · MiniBlister/Xiaomi-Smart-Home · GitHub
Dort werden die Statusvariablen mit SetValue erstmalig erzeugt.

Um die API zu schonen und nicht die Zugangsdaten zig mal einzugeben, macht es dann Sinn einen eigenen IO zu bauen.
Dieser holt die Daten im definierten Intervall ab und verteilt die an die Geräte-Instanzen.

Michael

Hier wäre es schön z.B. erstens eine Option im Form anzubieten ob man das braucht oder nicht, desweiteren wäre es gut man hat bestimmte Einstellungsmöglichkeiten im Konfigurationsform um so z.B. als Nutzer Schriftfarbe, Schriftgröße, Hintergrund farbe und ähliches anpassen zu können. Der CSS wird also über das Form vom Nutzer definiert.

Vieles wird von oben nach unten abgearbeitet, das ist aber zunächst völlig normal, so ging mir das auch, weil man zunächst ein Skript einfach überträgt bevor man sich an Methoden gewöhnt hat. Es ist auf den ersten Blick gewöhnungsbedürftig modular und objektorientiert in PHP zu arbeiten. Das macht den Code aber später schlanker und auch besser pflegbar. Zum Beispiel rufst Du mehrmals hintereinander Curl auf. Hier würde es reichen den Curl Aufruf dann in eine Methode zu stecken. Dann musst Du an den passenden Stellen nur noch die Methode aufrufen, dadurch müssen Änderungen dann auch nur noch an einer Stelle vorgenommen werden und der Code wird insgesamt kürzer und wenn man das dann gewohnt ist auch übersichtlicher.

Nein, er ruft ihn einmal auf wenn der Token bekannt ist und Wunderground-Upload deaktiv ist.
Aber ja, es gibt ihn mehrmals im Code.

Das stimmt allerdings.

Michael

Hallo demel,

lieben Dank für das Modul. Funktioniert alles ohne Probleme. Einen Wunsch hätte ich noch. Kannst Du die maximale Windgeschwindigkeit / Tag noch ausgeben? Diese gibt es in der in der App, fehlt aber noch in IPS. Eventuell gleich mit der Uhrzeit. Wenn möglich eventuell auch gleich die max. Windböen pro Tag.

LG Tom

freut mich zu hören

Ich habe mal auf die scbhelle in den Datensatz geschaut. Ich habe max. Windgeschwindigkeit und -richtung sowie den Zeitpunkt gefunden.
Baue ich in den nächsten Tagen ein.

Das habe ich in den Daten nicht gefunden. Finde ich allerdings auch in der App (iPhone und iPad) nicht.

Danke!

War nur eine Idee. An die Daten komme ich auch per Logging der Variable ran, also kein Problem.

LG Tom

so, habe ich eingebaut.

Es gibt in den betroffenen Instanzen neue Schalter
‚with_trend‘: Trend von Luftdruck und Temperatur
‚with_minmax‘: Min/Max von Temperatur und Max von Wind.
die entsprechenden Variablen werden entsprechender der Schalter erzeugt (-> siehe README.md)

Ob „WindMaxSpeed“ sich auf die Windgeschwindigkeit oder doch auf die Geschwindigkeit der Böen bezieht, ist etwas unklar. In der API-Doku steht nichts, in der Anwender-Doku der App steht, das es sich auf Böen bezieht aber die Variable deuten auf den Wind hin.
Ich bin kein meteorologischer Fachmann, von daher … habe ich es einfach „Wind“ genannt.
Die Werte beziehen sich immer auf „heute“, also am Mitternacht.

In diesem Zusammenhang habe ich die Benennung der Variable „Rain_24“ von „Regen 24h“ auf „Regen heute“ - das ist eindeutiger und lt. Netatmo-Anwender-Doku auch richtig.
Ist nur ein Hinweis, die Bezeichnung wird natürlich bei angelegten Variablen vom Modul nicht mehr geändert.

Die Benennung der Variablen ist bei Netatmo nicht wirklich konsistent und die API-Doku diesbezüglich auch nicht auf aktuellem Stand.

Aber egal, bei mir funktionieren die Änderungen soweit.

Danke. Update ging ohne Problem und die Variablen sind da.

Ich habe die Werte der letzten Tage mal verglichen, es handelt sich beim Max-Wert um die Böen.

LG Tom

Hmm, dann wäre es ja konsequent, die Variablen entsprechend umzubenennen, also Variablen-ID statt „WindMax*“ in "„GustMax*“ und die Bezeichnung analog.
Dann müsstest Du nur die zwei/drei Variablen nach meiner Änderung (geht natürlich ziemlich fix) vor dem Update einmal löschen.

Wäre das ok für Dich?

Gruß
Christian