Hallo
Nebenbei sollte man sich im Modul mal Gedanken machen, dass das automatische
Hochladen von IPS nicht immer gut ist.
Wetterstation meldet regelmaessig an IPS.
IPS meldet regelmaessig an Wunderground.
Wetterstation faellt aus!
IPS meldet immer noch regelmaessig ( alte Daten ) an Wunderground!
Wenn keine Daten von Wetterstation dann auch sollte auch nichts weiterleitet werden.
zB Wunderground checked ob Daten einer WS logisch sind.
Also Temperatur ueber Stunden gleich , oder ganz andere Daten von einer WS in der Naehe.
Dann nehmen sie die Station aus der WunderMap bis das wieder stimmt.
https://feedback.weather.com/customer/portal/articles/2924652-are-personal-weather-stations-on-weather-underground-monitored-for-quality-?b_id=17298
Gut das kann man ja noch ergänzen man prüft auf Variablenaktualisierung, wenn keine stattgefunden hat, dann wird auch nichts hochgeladen. Allerdings ändert das ja dennoch nichts an dem Problem, dass die Station dann von der Map genommen wird wenn dann IP-Symcon längere Zeit keine Daten schickt.
Ich habe auch schon bei anderen Themen häufiger darauf hingewiesen das Module nicht mehrere Sachen vermischen sollten.
Entweder es ist eine Hardware Instanz welche die Daten der Station verarbeitet oder es ist ein Service welche z.b. die Daten zu einem Anbieter hochlädt.
Zumal es ja schon ein Modul zum Upload nach Wunderground gibt.
Die Plausibilitätsprüfung obliegt dann diesem Modul (z.b. am Zeitstempel per Variablen).
Michael
Das macht es in dem Fall aber auch nicht unbedingt einfacher, weil dann hat man wieder das Problem, dass ein Modul von einem anderen Modul abhängig ist, um vollständig zu funktionieren. Das würde sich dann wieder mit:
Module mit externen Abhängigkeiten müssen diese vollständig im speziell erlaubten libs Ordner mitliefern.
Ein Modul darf niemals Abhängigkeiten aus einer anderen Bibliothek erfordern, sodass das Modul (ohne diese Bibliothek) „kaputt“ ist
beißen.
Außerdem hat man dann das Problem das ein anderes Modul auf die Properties von einem anderen Modul zugreifen muss um z.B. festzustellen in welcher Einheit die Daten überhaupt abgelegt worden sind, damit das andere Modul die Daten dann wieder passend umrechen kann um diese im richtigen Format zu einem Wetterdienst hochzuladen.
Das stellt glaube ich grundsätzlich eine Herausforderung da, das sich Module irgendwie sinnvoll ergänzen und einwandfrei zusammen arbeiten.
Äh… Wozu hast du IPS?
Die Datentypen und die Profile liefern alle Infos um die Daten hochzuladen.
Egal ob das eine OC3 oder Enocen, Netatmo oder eure Hardware ist, welche die Variablen in IPS befüllt.
Wo soll da eine Library von einer anderen abhängig sein?!
Warum willst du irgendwelche Einstellungen lesen? Wie kompliziert denkst du dir bitte Abläufe in IPS aus.
Im Zweifelsfall gibt es eine Liste mit Werten zum hochladen, da wird eine IPS Variable ausgewählt für jeden Upload-Wert und fertig.
Upload sobald sich die Variablen ändern (MessageSink).
Michael
Das setzt voraus das das Profil korrekte Einheiten enthält oder wie löst Du das konkret, das Du anhand des Profils unterscheidest ob das Pascal, KiloPascal, Hectopascal, Bar, Nm sind? Das andere Modul muss dann außerdem sämtliche Einheiten umrechnen können in sofern sind beide Module schon voneinander abhängig bzw. müssen auf einander abgestimmt werden, das so was am Schluss auch funktioniert. Aber wenn jedes Modul das mit allen Facetten das abbildet für das es da ist, und es Schnittstellen zwischen Modulen gibt und ich weis das das andere Modul das auch alles kann, dann geht das.
Ich suche ja nicht freiwillig den komplizierten Weg, wenn mir jemand sagt wie das einfach geht, dann mache ich das gerne auch.
Dann kommt in die Liste nicht nur die Variable zum auswählen, sondern auch die QuellPotenz.
Wenn ich dann sage Variable x ist KiloPascal und Wundergroud will hecto haben, muss das Modul es umrechnen.
Es kann doch nur so funktionieren.
Wie der Name es doch schon sagt: Modul
Modularer Aufbau.
Du kannst doch nicht 10 Funktionen dort reinwerfen ( übertrieben gleich noch Bewässerung und Jalousie mit ansteuern, weil wir in diesem Modul jetzt wissen wie Regen und Sonne sind) und alle Eventualitäten hart codiert im Code hinterlegen, wenn es universell / modular nutzbar sein soll.
Michael
Genau das macht das Modul ja, die Werte umrechen, nur ein anderes Modul muss dann eben exakt das gleiche können und eben feststellen in welcher Einheit die Daten überhaupt geloggt werden. Insofern müssen sich dann zwei Module abstimmen.
Nein… das kann man doch konfigurieren.
Der User muss eh die Quell-Variablen auswählen.
Und es ist wichtig das der User aktiv Variablen auswählt welche publik gemacht werden. Allein schon um gegenüber dem Datenschutz transparent zu sein und dem User seine Kontrolle über seine Daten zu ermöglichen!
Klar sollte man sich grundsätzlich an die IPS Profile halten, das vereinfacht es etwas.
Klar machen kann man alles, nur das Modul legt zunächst mal die Daten ab, alles andere müsste dann aber auch in einem anderen Modul erweitert werden, damit die Funktion auch vollständig ist. Und das habe ich nun nicht in der Hand ob das andere Modul in der Form zeitnah umgebaut bzw. ergänzt wird. Wenn ja, dann kann man das gerne so machen.
Wobei wir da bei nächsten Dauerthema wären, so lange es keine saubere Übersicht über Module, eine einfache Auswahlmöglichkeit zur Installation gibt, ist das zur Zeit auch einfach Wunschdenken. Dazu müsste dann nämlich ein Nutzer erst mal wissen was es alles an Modulen gibt, die dann zusammen genommen den Funktionsumfang abbilden, den man braucht. Es müsste also dann schon mal bekannt sein, dass man zwei Module installieren muss und vor allem welche.
Also eine Ideallösung finde ich das zum jetzigen Zeitpunkt noch nicht, so lange es nicht ein klar gegliederte Modul Übersicht gibt mit Kategorien und Abhängigkeiten, aus der dann auch hervor geht, welche Module es gibt und in welcher Kombination bzw. Abhängigkeit bestimmte Module dann zu installieren sind. Da ist es zumindest zur Zeit aus meiner Sicht einfacher, bestimmte Funktionen noch mit ins Modul aufzunehmen, bevor man schon die Installation und Konfiguration durch zwei Module unnötig verkompliziert. Dann hat man dann auch zwei Konfigurationsformulare.
Das ist ein gutes Argument man bekommt ja ständig Emails in letzter Zeit, das kann noch ergänzt werden. Wobei das dann auch eher ein Luxus Problem von IPS ist, da könnte man so was einstellen. Wenn Du nur die Wetterstation nutzt dann geht so was auch nicht, da frisst Du oder stirbst, entweder Du lädst einfach alles hoch oder eben nichts, ein Zwischending oder gar irgendeine Konfigurationsmöglichkeit gibt es da nicht.
Danke ! Der Code hat tatsächlich noch funktioniert.
Ich habe bei Amazon den TP-Link Router TL-WR841N N300 für 18,90 EUR mitbestellt. Geliefert wurde die Version 13.1. Nach der LEDE (aktueller Snapshot) / Luci - Installation wollte das WLAN am Anfang nicht funktionieren. Nach Umstellung auf manuelle Kanalwahl läuft das WLAN störungsfrei. Die Datenumleitung von der Sainlogic-Basis zum IPS-Server klappt auch.
Im Meldungsfenster von Symcon kommt noch folgende Meldung (IPS 4.4):
27.05.2018 21:04:56*| FlowHandler*| Kann Daten nicht zur Instanz #35940 weiterleiten: <br />
<b>Warning</b>: Cannot auto-convert value for parameter VariableValue in <b>/var/lib/symcon/modules/IPSymconWeatherStation/WeatherStation/module.php</b> on line <b>896</b><br />
Die Berechnung des relativen Luftdruckes in der Sainlogic scheint bei mir noch fehlerhaft zu sein (Wert wird ca. 6 hPa zu niedrig angezeigt). Der falsche relative Luftdruck wird auch in Wunderground angezeigt. Wunderground liefert jedoch einen korrigierten Wert beim Abruf durch IPS zurück.
Als vorläufigen Workaround rechne ich den von Sainlogic an IPS gesendeten absoluten Luftdruck in IPS um.
So auf die Schnelle mach mal ein Update und gib mal Rückmeldung ob das irgendeine Besserung gebracht hat.
Muss ich mir mal anschauen kannst Du mir mal die Formel posten die Du zum umrechnen nutzt.
Meldung ist weg. Danke !
Die Umrechnung wurde hier im Forum vor längerer Zeit gepostet:
<?
$Luftdruck = GetValueFloat(34627 /*[Gateways\Wetter\Sainlogic\WeatherStation\Luftdruck absolut]*/); // aktueller lokaler Luftdruck
$Temperatur = GetValueFloat(52798 /*[Gateways\Wetter\Sainlogic\WeatherStation\Außentemperatur]*/); // aktuelle Außentemperatur
$h = 401; // Höhe über NN in Metern (Anpassen !)
$g0 = 9.80665; // Normwert der Fallbeschleunigung
$R = 287.05; // Gaskonstante trockener Luft
$T = 273.15; // 0°C in Kelvin
$Ch = 0.12; // Beiwert zu E
if ($Temperatur < 9.1)
$E = 5.6402*(-0.0916 + exp(0.06*$Temperatur)); // Dampfdruck des Wasserdampfanteils bei t < 9.1°C
else
$E = 18.2194*(1.0463 - exp(-0.0666*$Temperatur)); // Dampfdruck des Wasserdampfanteils bei t >= 9.1°C
$a = 0.0065; // vertikaler Temperaturgradient
$xp = $h*$g0/($R*($T+$Temperatur + $Ch*$E + $a*$h/2)); // Exponent für Formel
$p0 = $Luftdruck*exp($xp); // Formel für den NN-bezogenen Luftdruck laut Wikipedia
SetValueFloat (29800 /*[Gateways\Wetter\Sainlogic\WeatherStation\Luftdruck korrigiert]*/, $p0);
?>
Hier die unterschiedlichen Werte für den Luftdruck:
Danke habe ich mal ergänzt, kannst Du mal prüfen ob das jetzt so passt? Deine eigene Umrechnung must Du dann raus nehmen, sonst rechnest Du dann ja zweimal um.
Wie sieht das mit der Eingabe der Höhe aus, gibt es da Vorschläge?
Reicht da ein einfaches Eingabefeld wie jetzt?
Oder soll die Höhe aus den Geopositionsdaten nachgeschlagen werden, dazu wäre aber die Voraussetzung, dass die Geopositionsdaten in IP-Symcon mit dem Standort der Wetterstation übereinstimmen. Ansonsten müsste man nochmals separat eine Eingabe für den Standort der Wetterstation machen.
Kennt jemand einen Weg oder hat ein PHP Skript mit dem man bei Google Maps die Höhe aus Positionsdaten ausliest oder einen anderen Weg auf einfache Weise an Höhendaten des Standorts zu kommen?
Hab es jetzt auch geschafft, die Daten meiner Wetterstation auf meinen Windows-Server-PC umzurouten und dort auszuwerten.
Port 80 war dort erst mal nicht zu gebrauchen, der auf Windows7 betriebene Webserver saugt wohl alles ab.
Hab dann erst mal auf einen Raspi umgeleitet, auf dem ich auch probeweise Dein Modul installiert hatte, und zwar die Meldungen für alle über die Smartphone-App einstellbaren Wetterdaten-Provider (wunderground, weathercloud, metoffice.gov.uk). Für die hatte ich mir Fake-IDs und Fake-PWs eingetragen, mich also nicht angemeldet und die Wetterstation bläst dann regelmäßig die Wetterdaten ins blaue ohne daß eine Quittung erforderlich ist. Die Wetterdaten-Provider haben das wg. der fehlenden Registrierung sicher ignoriert, inzwischen ist mein System dicht und nichts dringt nach draussen.
Es gab allerdings erst mal auf dem Raspi in Deinem Modul jede Menge Fehlermeldungen; anscheinend wird durch das DNS-Umleiten irgendwelche Infos rausgeschnitten (oder akzeptiert Dein Modul nur einen einzigen Wetterdaten-Provider?)
Ich wollte Dich nicht belabern jetzt auch noch einen „Transparent-Mode“ einzubauen, sondern hab mir ein Skript nach diesem Rezept erstellt, das über ServerSocket und RegisterVariable befüllt wird.
Die Objekte für die anzuzeigenden Messwerte hab ich mir mit einem Konfigurations-Skript erstellt; als Ident hab ich die Kürzel aus den Wetterdaten-Protokollen eingetragen.
Weil ich aber ungedingt die Daten auf meinem Windows-System haben will, läuft jetzt auf dem Raspi ein 2zeiliges Skript, das die über Port80 (und ServerSocket und RegisterVariable) empfangenen Daten einfach an meinen Server über Port 45001 (und ClientSocket, Port# willkürlich gewählt) sendet (Port-to-Port_Reflektor.ips.php):
$Data = $_IPS['VALUE'];
CSCK_SendText (13907 /*[zum Svr]*/, $Data);
Falls Interesse an einer reinen Softwarelösung zum Umrouten der von der Wetterstation gesendeten Daten an einen anderen PC im eigenen LAN besteht, kann ich ja mal eine genauere Anleitung posten;)
Viele Grüsse
Harald
Nach Modul-Update ist der (relative) Luftdruck immer noch zu niedrig.
Durch die Umrechnung ist der Luftdruck bei mir plausibler. Interessant wäre, ob andere User ähnliche Abweichungen haben.
Hier einige aktuelle Vergleichswerte:
Sainlogic:
- absoluter Druck: 972,6 hPa
- relativer Druck: 1010,8 hPa
- korrigierter relativer Luftdruck: 1017,6 hPa
Rückmeldung von Wunderground:
- relativer Druck: 1018,0 hPa
Netatmo:
- absoluter Druck: 970,1 hPa
- relativer Druck: 1017,9 hPa
Die Höhenangabe habe ich von Wunderground übernommen. Die Angabe deckt sich mit den geologischen Karten.
PS: Link zu Wikipedia: https://de.wikipedia.org/wiki/Barometrische_H%C3%B6henformel
Komisch habe die Formel so von Dir übernommen.
Wenn mal Zeit ist schaue ich das mal näher an, wie ist das denn beim Rest habt ihr da auch Abweichungen?
Ein gute Frage wäre ja auch das Versenden an Wunderground. Die Wetterstation sendet ja einen Wert und Wunderground passt diesen an, daher muss dann wohl der ursprüngliche Wert an Wunderground übergeben werden und nicht der in IP-Symcon korrigierte Wert, sonst nimmt ja Wunderground dann nochmals eine Korrektur vor oder?
Bei mir sieht es so aus:
IPS --> 1015,9 hPa
Wunderground über IPS --> 1015,8 hPa
Wunderground direkt über ObserverIP --> 1015,46 hPa
AmbientWeather über ObserverIP --> 1015,6 hPa
Die Unterschiede liegen wohl weniger am umrechnen sondern an der Zeitdifferenz vom ablesen.
Hinweis:
Ich habe das Modul Update mit der Umrechnung noch nicht aufgespielt, weil bei mir die Werte ja eigentlich passen.
Habt Ihr den relativen Druck eurer Wetterstation Kalibriert wie es in der Bedienungsanleitung steht?
Weiterer Hinweis ich habe heute ein Firmwareupdate auf Version 1.2.2 mit der WS-View App angeboten bekommen und auch mal aufgespielt.
Leider habe ich nicht herausfinden können, was dieses Upgrade bewirkt.
Gemessen wird vom Sensor der absolute Luftdruck. Bei der Umrechnung auf den relativen Luftdruck wird auf Meereshöhe normiert.
Mutmaßung: Wunderground rechnet aufgrund der vorhandenen geographischen Daten, Temperatur und evtl. Luftfeuchtigkeit den übermittelten absoluten Luftduck von der Sainlogic um. Evtl. findet auch ein Abgleich bzw. eine Plausibilitätsprüfung mit Stationen in der Umgebung statt.
Theoretisch könnte auch die Sainlogic die geographischen Daten in die Berechnung einfließen lassen.
Vor der Umleitung der Daten zu IPS hatte ich die Sainlogic bei Wunderground angemeldet.
Bei der Registrierung der Sainlogic bei Wunderground gab es eine Eingabemöglichkeit von Längen- und Breitengrad in der WS-App.
Ich habe die Sainlogic jedoch über die Webseite von Wunderground registriert und in der WS-App nur die PWS-ID angegeben.
PS: Falls andere User keine Probleme haben, sind aus meiner Sicht keine Änderungen am Modul notwendig. Ich kann mit der von mir praktizierten Lösung leben.
Kalibriert wird laut Anleitung der absolute Luftdruck, d.h. der Messwert.
Dieser scheint im Vergleich mit der Netatmo-Station im Rahmen der Messungenauigkeiten zu passen.