OSCAT Forum
network.lib => Modulentwicklung => Thema gestartet von: mattsches am 14. Juli 2017, 22:40:33
-
Update: Zwischenzeitlich habe ich einen neuen Baustein für die Abfrage von Wetterdaten von Weatherbit.io erstellt. Damit ist eine zumindest aktuell funktionierende Alternative gefunden. Details siehe hier: http://www.oscat.de/community/index.php/topic,4952.0.html (http://www.oscat.de/community/index.php/topic,4952.0.html)
Achtung, openweathermap.org hat die Lizenzpolitik dahingehend geändert, dass die vom Baustein genutzte 16 Tage-Vorhersage nun nicht mehr mit dem kostenfreien API-Key nutzbar ist. Leider kann auch nicht einfach auf die weiterhin kostenfreie 5 Tage/3 Stunden-Vorhersage umgebaut werden, da dort keine zusammenfassenden Werte pro Tag verfügbar sind, sondern ausschließlich die 3 Stunden-Abschnitte. Zudem sind bei der daraus resultierenden Größe der XML-Antwort Probleme mit der NETWORK_BUFFER-Variable zu erwarten, deren Standardlänge dann nicht ausreichen wird.
Ich habe derzeit keine schlüssige Idee, wie hier weiter verfahren werden könnte. Möglicherweise landet der Baustein nach dann recht kurzer Lebenszeit doch wieder in der Tonne.
Hallo zusammen,
nachdem worldweather.com nun auch die alten kostenlosen APIs abgeschaltet hat, war ich auf der Suche nach einer Alternative. Fündig wurde ich bei www.openweathermap.org, wo es weiterhin kostenlose APIs mit Zugriff auf verschiedene Vorhersagen gibt. Man registriert sich, erhält - wie gewohnt - einen API Key und kann loslegen.
Die Angabe des Ortes, für den die Vorhersage bezogen werden soll, erfolgt gemäß Empfehlung des Wetterdienstes mittels City ID. Eine Liste der verfügbaren IDs findet sich unter hier: http://bulk.openweathermap.org/sample/city.list.json.gz (http://bulk.openweathermap.org/sample/city.list.json.gz)
Bausteine für Beschreibung und Icons habe ich vorerst nicht erstellt, weil
a) die Beschreibung für die einzelnen Tage direkt vom Wetterbaustein in die Struktur geschrieben wird und ich
b) keine Icons in Verwendung habe.
Wer mag, kann das natürlich gerne ergänzen.
Doku gibt es auch (noch?) keine, wer die Bausteine für Yahoo und WorldWeather kennt, dürfte auch mit der OpenWeatherMap-Variante zurecht kommen.
Ich habe den Baustein auf einer Beckhoff in Betrieb. Durch die Verwendung von IP_CONTROL etc. sollte er aber auch auf "normalen" CODESYS-Steuerungen laufen, wenn ich das richtig verstehe. Habe ich aber nicht ausprobiert.
Feedback ist natürlich willkommen.
Cheers,
mattsches
Edit: Danke übrigens noch an das OSCAT-Team für die ganzen wertvollen Bausteine! Mit dem XML_READER, der ganzen IP_...-Infrastruktur und den anderen Wetterbausteinen als Vorlage war das Ganze recht schnell erledigt.
Edit 26.07.17: URL geändert, so dass immer nur fünf Tage abgefragt werden ("&cnt=5") und die Standard-Empfangspuffergröße auch bei Änderung des Standardverhaltens seitens des Anbieters ausreichend bleibt.
Edit 04.10.17: Länge des URL_PREFIX Strings korrigiert. Danke an Lightcommander für den Hinweis!
Edit 03.11.17: Hinweis auf geänderte Preispolitik aufgenommen.
[gelöscht durch Administrator]
-
hallo mattsches
du hast aber sicherlich die buffergrosse auch angepasst da der Baustein mit diesen Parametern eigentlich immer über 4096 bytes zurückliefert.
An der Sache war ich ja auch vor Monaten schon dran aber soweit ich mich erinnere habe ich nichts gefunden um die Datenmenge unter 4096 Bytes zu drücken
da ich aber nicht in der lib die buffergroesse deswegen generell erhöhen möchte suche ich da noch einen Kompromiss
wie sieht du die Sache ?
-
Nein, die Puffergröße steht bei mir unverändert auf 4096. Ich verwende die Abfrage "16 day weather forecast" (http://openweathermap.org/forecast16 (http://openweathermap.org/forecast16)) von openweathermap.org, die praktischerweise aber standardmäßig nur die Daten für sieben Tage zurückliefert (tagesgranular). Da bekomme ich dann eine Antwort mit ziemlich genau 3300 Zeichen. Mehr oder weniger Tage ließen sich durch Anhängen des Parmaeters
&cnt=5 spezifizieren. Das habe ich in meinem Baustein gerade noch angepasst, damit es nicht kracht, wenn der Default mal verändert werden sollte. Ich werde den Eingangspost noch entsprechend aktualisieren mit der aktualisierten Version.
Eine andere, aber durchaus interessante Option wäre die Nutzung des JSON-Formats, das vom Anbieter standardmäßig angeboten wird. Dafür bräuchte es aber erst einmal einen Parser in der OSCAT, was mir vorerst aber zu aufwändig ist.
-
ja das wäre gut wenn der baustein mit weniger als 4096 bytes sicher arbeitet.
die anzahl der tage sollten so verkleinert werden das es hier auch nicht durch zufällig lange wettertexte einen crash gibt !
json-reader
daran habe ich schon öfters gedacht.
aber ich weiß noch zu gut wie viel arbeit mir der xml-reader machte und darum habe ich das bis jetzt liegen gelassen....
-
Hallo mattsches,
habe deinen Baustein für OpenWeather ausprobiert und bekomme jedoch ständig den Fehlercode Error_C: 4278190080.
Ich benutze Codesys V3.
Hast du eine Idee was der Code aussagt?
MfG
-
du musst auch den error_t code mit angeben damit man sehen kann welche sub-baustein den fehler ausgibt
an sich ist
Error_C: 4278190080 = 0xFF00_0000
und das bedeutet das derjenige Baustein ein problem mit dem TCP-Connect hat
der baustein von mattsches ansich funktioniert korrekt
man muss aber auf jedenfall den network_buffer vergroessern
aber bei dir ist das noch ein anderes problem
-
Hallo peewit,
erstmal vielen Dank für die Antwort.
Wie bekomme ich denn heraus, warum ich ein Problem mit dem TCP-Connect habe?
Bei mir funktioniert zur weder der Wetterdienst, noch der SMTP-Dienst.
Scheint ja wirklich keine TCP-Kommunikation vorhanden zu sein... die Steuerung selbst hat eine stabile Verbindung.
Gruß
-
Beim SMTP-Baustein kommen z.B. folgende Fehlercodes:
Error_C: 124518904
Error_T: 5
MfG
-
ERROR_T = 5 ist ein Timeout-Fehler im Ablauf (Etwas ist eingetreten was nicht sein sollte !)
ERROR_C = 124518904 = 0x076C_01F8
Das linke Word 0x076C = 1900
Im Schritt 1900 im Baustein ist das Problem aufgetreten
Das rechte Word 0x01F8 = 504 letzte Return-Code vom SMTP-Server
504 = A command parameter is not implemented.
Der Fehler im Schritt 1900 bedeutet "keine Authentifizierung gefunden"
Der SMTP-Server bietet normalerweise verschiedene Arten der Authorisierung an und der Baustein kann auch ein paar Varianten
Wenn aber beim Abgleich festgestellt wird das es keine Gemeinsamkeiten gibt dann passiert das.
Um das noch genauer zu analysieren zu können musst du die Baustein Parameter noch preisgeben (passwort kannst du ja ändern)
Noch hilfreicher wäre ein Wireshark-Mitschnitt der Kommunikation
Hast du denn überhaupt einen SMTP-Server (Email-Provider) der ohne SSL (Verschlüsselung) überhaupt funktioniert ?
-
Hallo peewit,
das Problem mit dem SMTP-Baustein hat sich mittlerweile geklärt...
Du hattest Recht, es gab keine Authentifizierung. Unsere IT hat den Mailzugang ohne Authentifizierung eingerichtet.
Einach die Zugangsdaten weggelassen und schon hat alles einwandfrei funktioniert!
Gruß
-
Hallo zusammen,
erstmal danke für den Baustein.
Bei der ersten Kompilierung ist mir gleich aufgefallen dass im hier zum Download stehenden Baustein der String für die URL zu kurz ist.
Das liegt wahrscheinlich an der Einschränkung der Tage. Statt string(80) müsste es string(86) heißen.
Grüße
Michael
-
Danke für den Hinweis! Habe die Quelle im Eingangspost oben entsprechend aktualisiert.
-
Vielen Dank für den Baustein.
Die Einbindung hat super geklappt.
Gruß
Marco
-
Ich habe den Baustein eingebunden. Mit dem API Key aus dem Baustein funktioniert es problemlos. Habe mich bei Openweathermap registriert und einen API Key erhalten. Mit diesem funktioniert es aber nicht. Ist das Problem noch jemand anderst bekannt?
-
Hast du City ID und API-Key geändert? Wenn ja, hast du schonmal probiert, nur den API-Key auszutauschen und die City ID erst einmal beizubehalten? Wenn die Abfrage dann fehlschlägt, ist irgendwas an deinem API-Key nicht in Ordnung.
-
Ja habe ich schon versucht.
Habe bei Openweathermap nachgefrat. Mit dem Key geht das nicht. Ist kostenpflichtig.
-
Das ist interessant. Laut http://openweathermap.org/price (http://openweathermap.org/price) gibt es bei der freien API keinen Zugriff mehr auf die 16 Tage-Vorhersage. Früher war das noch so.
Testweise habe ich gerade einen neuen API Key generiert, mit dem scheitert die Abfrage bei mir auch. Mit meinem alten API Key dagegen funktioniert sie.
Ich werde den Baustein also wohl auf die 5 Tage/3 Stunden-Vorhersage umbauen müssen. Kann dir aber leider nicht sagen, wann ich dazu kommen werde.
-
Achtung,
openweathermap.org hat die Lizenzpolitik dahingehend geändert, dass die vom Baustein genutzte 16 Tage-Vorhersage nun nicht mehr mit dem kostenfreien API-Key nutzbar ist. Leider kann auch nicht einfach auf die weiterhin kostenfreie 5 Tage/3 Stunden-Vorhersage umgebaut werden, da dort keine zusammenfassenden Werte pro Tag verfügbar sind, sondern ausschließlich die 3 Stunden-Abschnitte. Zudem sind bei der daraus resultierenden Größe der XML-Antwort Probleme mit der NETWORK_BUFFER-Variable zu erwarten, deren Standardlänge dann nicht ausreichen wird.
Ich habe derzeit keine schlüssige Idee, wie hier weiter verfahren werden könnte. Möglicherweise landet der Baustein nach dann recht kurzer Lebenszeit doch wieder in der Tonne.
-
Hallo mattsches
Hast ganz sicher bin ich nicht ob ich dich verstanden habe mit den Problemen zur Preispolitik.
Da es keine 1 Tages Werte mehr sind geht das 5d a 3h trotzdem oder? Ich stehe etwas auf den Schlauch? Ich habe vor Wetterdaten als Prognose zu benutzen und würde eher 1h Daten haben wollen wie 1 Tages Daten aber die 5d a 3h passen auch ganz gut vorerst. Übersehe ich etwas oder warum sollte es nicht funktionieren? Würde ungerne Zeit reinstecken wenn du oder jemand anderes vorher schon ausschließen kann das es funktioniert die Daten zu lesen.
Bitte daher kurz um Rückmeldung was ich nicht verstanden habe. ;D
-
Hallo,
grundsätzlich kannst du schon einen Baustein für die 15 Tage/3 Stunden-Vorhersage bauen oder meinen modifzieren. Du wirst halt die globale Variable NETWORK_BUFFER_LONG_SIZE aus der OSCAT Network Lib vergrößern müssen, da der zurückgelieferte XML-String länger als 4095 Zeichen ist und somit standardmäßig nicht in den Empfangspuffer passt. Das ist mit einer einfachen Anpassung in der Network.lib erledigt; allerdings kann der Baustein nicht einfach ohne diese Anpassung von jemand anders genutzt werden.
Gruß,
mattsches
-
Hallo Zusammen,
habe heute das erste Mal den Openweather-Baustein mit Codesys 3.5 getestet. Bei mir funktioniert er tadellos, sodass ich mich auch gleich dazu entschlossen habe Ihn zu erweitern. ;D
Dazu gekommen ist:
- Übersetzungsbaustein für die Wettervorhersage von Englisch in Deutsch
- Zuordnung Wetter-Icons nach Openweather-Standard in Anlehnung an die YAHOO_WEATHER-Icons (d.h. die Icon-Struktur ist an die vorhandenen Yahoo-Icons angepasst inkl. Beschriftung der
zugeordneten Dateibezeichnung, siehe OSCAT Network Handbuch)
Ich füge die Dateien gleich dem Anhang bei und hoffe, dass der Eine oder Andere einen Nutzen daraus ziehen kann :)
Anmerkung: Die Projekt-Dateien sind mit Codesys 3.5.11 erstellt worden. Wenn gewünscht kann ich Sie auch nochmal für Codesys 2 bereitstellen.
[gelöscht durch Administrator]
-
Auch wenn ich jetzt Wasser in den Wein gieße, die Arbeit war zumindest nicht optimal investiert. Denn:
Achtung,
openweathermap.org hat die Lizenzpolitik dahingehend geändert, dass die vom Baustein genutzte 16 Tage-Vorhersage nun nicht mehr mit dem kostenfreien API-Key nutzbar ist. Leider kann auch nicht einfach auf die weiterhin kostenfreie 5 Tage/3 Stunden-Vorhersage umgebaut werden, da dort keine zusammenfassenden Werte pro Tag verfügbar sind, sondern ausschließlich die 3 Stunden-Abschnitte. Zudem sind bei der daraus resultierenden Größe der XML-Antwort Probleme mit der NETWORK_BUFFER-Variable zu erwarten, deren Standardlänge dann nicht ausreichen wird.
Ich habe derzeit keine schlüssige Idee, wie hier weiter verfahren werden könnte. Möglicherweise landet der Baustein nach dann recht kurzer Lebenszeit doch wieder in der Tonne.
Diese Einschränkung gilt weiterhin, die tagesgenaue Vorhersage ist mit neu generierten API-Keys nicht kostenlos nutzbar.
Mit welchem API-Key hast Du denn getestet?
-
Hallo mattsches,
ja das kann gut möglich sein. Ich habe glaube noch einen API-Key von 2017.
Damit bekomme ich für alle 5 Tage Vorhersagen. Das habe ich vor ca. 30 min. getestet...
-
Das ist der Punkt. Ich habe ja oben schon darauf hingewiesen, dass alte Keys noch funktionieren, neue jedoch nicht mehr. Für diejenigen, die einen neuen Key anlegen müssen, ist der Baustein nicht nutzbar. Leider.
-
We have been surfing the website for a long time and we have come to see what has been told about the right knowledge here.
-
Falls hier jemand auf der Suche nach einem Wetter-Baustein hereinschauen sollte: Es gibt zwischenzeitlich mit Weatherbit.io eine Alternative. Näheres siehe hier: http://www.oscat.de/community/index.php/topic,4952.0.html (http://www.oscat.de/community/index.php/topic,4952.0.html)