FHEM Forum

Hallo,
ich habe mir in unser Wohnmobil einen Raspi eingebaut mit GPS Modul an Bord, das hab' ich auch alles hingekriegt. (Temperaturmessung, Heizungsregelung und GPS Empfang funktioniert alles)

Jetzt würde ich gerne einen Wetterbericht anzeige in Abhängigkeit vom Standort (GPS-Daten)

Ich bin schon soweit, dass ich das DarkSky Wetter angezeigt kriege mit fix angegebenen GPS-Koordinaten:
define Wetter_GPS Weather location=52.520007,13.404954 API=DarkSkyAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx interval=3600 lang=de

Jetzt sollten die Zahlenwerte natürlich durch die readings des GPS Moduls ersetzt werden, was aber nicht funktionierte:
define Wetter_GPS Weather location=[GPS.lat],[GPS.lon] API=DarkSkyAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx interval=3600 lang=de


Ich vermute mit den eckigen Klammern passt was nicht, komm aber nicht auf die richtige Lösung.

Ich hab's auch schon mit einem defmod versucht
define change_GPS_Loc at +*00:02:00 defmod Wetter_GPS Weather location=[GPS.lat],[GPS.lon] API=DarkSkyAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx interval=3600 lang=de
klappt aber auch nicht. Es wird durch den defmod nicht der Zahlenwert der Koordinaten geschrieben, sondern der Text mit den eckigen Klammern. (location=[GPS.lat],[GPS.lon])

Was mach ich falsch?

defmod geht nicht bei httpmod devices, Du musst das device loeschen und dann dynamisch neu anlegen, codeschnipsel fuer dynamisces anlegen eines httpmod devce fuer Tankstelle hier
https://forum.fhem.de/index.php/topic,94640.msg874886.html#msg874886

alternativ wetter proplanta, da kann man es dynamisch aedern

Zitat von: inoma am 23 Februar 2019, 14:47:16
defmod geht nicht bei httpmod devices, Du musst das device loeschen und dann dynamisch neu anlegen, codeschnipsel fuer dynamisces anlegen eines httpmod devce fuer Tankstelle hier
https://forum.fhem.de/index.php/topic,94640.msg874886.html#msg874886

Ist Weather wirklich ein HTTPMOD-Device?!

Ansonsten würde ich ja lieber die Daten in global modifizieren, dann weiß die FHEM-Instanz insgesamt auch immer, wo sie gerade ist. In der Definition von Weather bleiben die Koordinaten dann weg; Weather holt sich die Daten aus global, wenn nichts angegeben ist. Man muss dann nur noch ein Update bei Weather machen, anstatt das Device immer wieder neu zu definieren.

SUNRISE_EL liefert dann z.B. auch immer ortsbezogene Daten, Twilight wird das in Zukunft auch können.

Zitat von: inoma am 23 Februar 2019, 14:47:16
alternativ wetter proplanta, da kann man es dynamisch aedern

Ich hätte eh lieber proplanta genommen, aber ich habe nicht gefunden, wie ich da die GPS Koordinaten unterbringe, die brauchen doch immer einen Ort, oder?

ja, proplanta braucht den Ort, ich habe mir für proplanta einige feste locations definiert, die ich über owntracks gesteuert dann auswähle

Zitat von: Christoph Morrison am 23 Februar 2019, 14:52:33

Ansonsten würde ich ja lieber die Daten in global modifizieren, dann weiß die FHEM-Instanz insgesamt auch immer, wo sie gerade ist. In der Definition von Weather bleiben die Koordinaten dann weg; Weather holt sich die Daten aus global, wenn nichts angegeben ist. Man muss dann nur noch ein Update bei Weather machen, anstatt das Device immer wieder neu zu definieren.

Ich hab' jetzt schon einige Varianten probiert, aber in "global" kommt aber immer ein Text an, nicht wie gewünscht der Zahlenwert für Longitude/Latitude.

z.B. "attr global latitude [GPS.lat]"
oder "attr global latitude {readingsval("GPS","lat","0")}

Kann mir jemand auf die Sprünge helfen, wie die richtige Syntax ist um in global die attr "longitude" mit GPS.lon und "latitude" mit GPS.lat zu füllen?

Danke!

Zitat von: pure-current am 23 Februar 2019, 19:12:03
Kann mir jemand auf die Sprünge helfen, wie die richtige Syntax ist um in global die attr "longitude" mit GPS.lon und "latitude" mit GPS.lat zu füllen?

Nicht so lange du uns ein list von GPS verenthältst.

list GPS:
Internals:
   NAME       GPS
   NR         44
   STATE      Connected
   TYPE       GPSD
   gpsdHost   127.0.0.1
   gpsdPort   2947
   pollInterval 30
   READINGS:
     2019-02-23 19:25:30   altitude        184.864
     2019-02-23 19:25:30   climbRate       -0.006
     2019-02-23 19:25:30   direction       NW
     2019-02-23 19:25:30   errorAltitude   45.31
     2019-02-23 19:25:30   errorClimbRate  90.62
     2019-02-23 19:25:30   errorLonLat     11.107
     2019-02-23 19:25:30   errorSpeed      3.24
     2019-02-23 19:25:30   gpx             <trkpt lat="49.165812952" lon="9.277709423"><time>2019-02-23T18:25:30.000Z</time></trkpt>
     2019-02-23 19:25:30   heading         317.2301
     2019-02-23 19:25:30   lat             49.165812952
     2019-02-23 19:25:30   link            https://maps.google.de/maps?q=49.165812952,9.277709423
     2019-02-23 19:25:30   lon             9.277709423
     2019-02-23 19:25:30   speed           0.197
     2019-02-23 09:36:45   state           Connected
     2019-02-23 19:25:30   time_utc        2019-02-23T18:25:30.000Z
     2019-02-23 19:25:30   usedGpsDevice   /dev/ttyS0
   helper:
     GPSDparams:
       host       127.0.0.1
       port       2947
Attributes:

Guten Abend,

ich habe es bei mir für den Camper mit zwei "at" gelöst.
Geht aber sicher noch eleganter.

define GPS_global_upd at +*00:15:00 {fhem("attr global longitude ".ReadingsVal("KastenGPS","lon",""))}
define GPSlat_global_upd at +*00:15:00 {fhem("attr global latitude ".ReadingsVal("KastenGPS","lat",""))}

Probier es mal aus....
beste Grüße

Du greifst auf Readings mit der Perl-Funktion ReadingsVal (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#ReadingsVal) zu. In einem DOIF (und bei ein paar anderen Fällen) kannst auch die [device:reading]-Syntax (von set magic) verwenden.

Im Prinzip ist es doch einfach: Du nutzt ein neu eingehendes GPS-Reading (event-on-change-reading nicht vergessen) oder einen festen Zeitraum als Trigger um global anzupassen und dein Wetterdevice zu aktualisieren. Oder du baust dir einen Watchdog, der erst dann ein Update macht, wenn sich das GPS-Reading nicht mehr ändert (dein Wohnmobil steht oder GPS ist tot).

Stichwörter habe ich dir nun ein paar gegeben. Bau dir einen Dummy für dein GPS-Device mit lat und long als Reading und eines als Ziel (global-Ersatz), dann baust du die Logik außenrum. Wenn du das mit Dummies machst, kannst du auch nix kaputt machen.

Zitat von: hanami am 23 Februar 2019, 20:16:10

Code Auswählen Erweitern

define GPS_global_upd at +*00:15:00 {fhem("attr global longitude ".ReadingsVal("KastenGPS","lon",""))}

Code Auswählen Erweitern

define GPSlat_global_upd at +*00:15:00 {fhem("attr global latitude ".ReadingsVal("KastenGPS","lat",""))}

...der Teil mit den geschweiften Klammern wars, damit funktionierts.
Jetzt kommen Zahlenwerte in den readings an.

Vielen Dank!

Jetzt muss ich nur noch ausprobieren, ob die Koordinaten dann auch im Weather Modul übernommen werden.
Gruß pure-current

Hallo zusammen,

also mit dem von hanami vorgeschlagenen Code hat es funktioniert (mit at und einem Intervall von 30min), dass die Koordinaten in global ankommen.

Aus der Wetterdefinition habe ich jetzt die location mit lat,lon rausgenommen, zum Testen mal in global die Koordinaten von New York eingegeben.
define Wetter_GPS Weather API=DarkSkyAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx interval=3600 lang=de

Aber auch nach zig mal "set ... update" blieben die Werte unverändert.

Erst nach einem shutdown restart gings. Dann kamen die Werte von New York.

Hab's dann heute Nacht mal laufen lassen, es hätte sich bis heute morgen ja wieder zurückstellen sollen.
Aber auch wieder zig mal set...update - ging nicht.

Erst wieder ein shutdown restart hat funktioniert.

Das kann aber doch nicht so gedacht sein, dass ich bei jedem GPS Update einen shutdown restart machen muss...

Zitat von: pure-current am 24 Februar 2019, 10:00:33

Code Auswählen Erweitern

define Wetter_GPS Weather API=DarkSkyAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx interval=3600 lang=de

Aber auch nach zig mal "set ... update" blieben die Werte unverändert.

Schon mal in CommandRef gelesen, was cachemaxage bedeutet?

Zitat von: inoma am 23 Februar 2019, 14:47:16
defmod geht nicht bei httpmod devices,

Warum "httpmod"? Das ist kein "HTTPMOD", sondern "Weather"
Warum sollte defmod nicht funktionieren???

Zitat von: amenomade am 24 Februar 2019, 10:15:30
Schon mal in CommandRef gelesen, was cachemaxage bedeutet?

Ja, hab' ich. Aber zwischen 23.00 Uhr abends und 9.00 Uhr morgens sollte das Intervall längst erledigt sein, oder?

Ja, aber

Zitatzig mal "set ... update"

bringt nichts

Also nochmal: Du hast um 23:00 Uhr die Werte geholt, dann anschliessend die Attribute in global geändert, und dann ist um 9:00 Uhr nichts neues gekommen?

Das klingt normal. Diese Werte werden beim Define des Devices eingelesen. Solange kein neues Define vom Weather Modul, passiert nichts.

Deswegen: defmod

Das kann so nicht gehen. Die Werte für die Location werden doch nicht jedesmal vom global Device geladen, sondern einmalig nach einem define oder defmod und danach im Cache vorgehalten.
Es muss also schon noch ein defmod gemacht werden, was wiederum eine save nach sich ziehen müsste da strukturelle Änderung.

Zitat von: CoolTux am 24 Februar 2019, 11:47:49
Das kann so nicht gehen. Die Werte für die Location werden doch nicht jedesmal vom global Device geladen, sondern einmalig nach einem define oder defmod und danach im Cache vorgehalten.
Es muss also schon noch ein defmod gemacht werden, was wiederum eine save nach sich ziehen müsste da strukturelle Änderung.

Genau ;)

also dann doch zurück zu meiner ursprünglichen Idee mit defmod....

Ich hab jetzt in mein ursprüngliches defmod die Schreibweise von hanami eingebaut:
define change_GPS_Weather at +*00:01:00 {fhem("defmod Wetter_GPS Weather location=".ReadingsVal("GPS","lat","").",".ReadingsVal("GPS","lon","")." API=DarkSkyAPI,cachemaxage:600 apikey=02701858558221516c56f3faf5bc8e5c interval=3600 lang=de")}
(steht nur zu Testzwecken auf 1 min.)

Ist etwas lang und unübersichtlich geworden, scheint aber zu gehen.
Nach jedem Update erscheint das rote "?" bei save config.

Wie würdet Ihr jetzt noch das automatische Speichern der config realisieren? An das "at" als zusätzlichen Befehl mit anhängen?

Zitat von: CoolTux am 24 Februar 2019, 11:47:49
Das kann so nicht gehen. Die Werte für die Location werden doch nicht jedesmal vom global Device geladen, sondern einmalig nach einem define oder defmod und danach im Cache vorgehalten.
Es muss also schon noch ein defmod gemacht werden, was wiederum eine save nach sich ziehen müsste da strukturelle Änderung.

Interessanter Punkt. Ist irgendwo dokumentiert, dass Weather die Positionsdaten zusätzlich zu global persistiert? Sollte es zumindest, imho, besser noch: Weather/die Plugins sollten die Daten nicht persistieren und aus global lesen, wenn der User im Rahmen der Definition nichts anderes angegeben hat.

(ceterum censeo: Dies wäre übrigens der Punkt, wo ich mir wünschen würde, dass die Diskussion abgetrennt wird)

Das ist aber klar: etwas, was zu DEF gehört (auch wenn es eine Abweichmöglichkeit gibt, wie hier über global) wird nie dynamisch aktualisiert. Das ist bei allen Devices in Fhem gleich.

Zitat von: amenomade am 24 Februar 2019, 13:00:12
Das ist aber klar: etwas, was zu DEF gehört (auch wenn es eine Abweichmöglichkeit gibt, wie hier über global) wird nie dynamisch aktualisiert. Das ist bei allen Devices in Fhem gleich.

So klar ist das nicht, denn z.B. wird Twilight das nicht so machen, wenn man global als Quelle für die Positionsdaten angibt. Warum auch? Die Daten sind in global persistiert, dann halte ich die doch nicht noch mal im Modul vor. Und offenbar, siehe diesen Thread, gibt es FHEMs die sich bewegen (ich hab auch so eins im Auto, da ich aber keine mobil-lokalen Wetterdaten brauche, ist mir das nie aufgefallen).

Das sollte man zumindest mal diskutieren, bzw. dokumentieren.

(Immerhin ist mir gerade der Gedanke gekommen, dass ich mir ein zusätzliches mobiles FHEM für (Geschäfts-)Reisen bauen könnte, dass mir ortsbezogene Infos liefert, z.B. wie hier die Wettervorhersage, aber auch Twilight für den Wecker etc.)

Zitat von: Christoph Morrison am 24 Februar 2019, 12:49:13
Interessanter Punkt. Ist irgendwo dokumentiert, dass Weather die Positionsdaten zusätzlich zu global persistiert? Sollte es zumindest, imho, besser noch: Weather/die Plugins sollten die Daten nicht persistieren und aus global lesen, wenn der User im Rahmen der Definition nichts anderes angegeben hat.

(ceterum censeo: Dies wäre übrigens der Punkt, wo ich mir wünschen würde, dass die Diskussion abgetrennt wird)

https://github.com/LeonGaultier/fhem-weather/blob/master/API-Modulebeschreibung%20fuer%2059_Weather.odt

Ich bilde mir ein hier etwas dazu geschrieben zu haben.

Vielleicht tatsächlich ein separater Thread, aber ich würde auch erwarten, dass sich eine Änderung der global Attribute durchschlägt sofern es nicht im Modul explizit gepflegt ist.


Kurz, weil mobil

Zitat von: CoolTux am 24 Februar 2019, 13:15:13
Ich bilde mir ein hier etwas dazu geschrieben zu haben.

Nichts was Änderungen an global nach dem Define betrifft ...

Zitat von: Christoph Morrison am 24 Februar 2019, 13:10:08
So klar ist das nicht, denn z.B. wird Twilight das nicht so machen, wenn man global als Quelle für die Positionsdaten angibt.

Wie machst Du das?

Zitat von: CommandRefDefine

    define <name> Twilight <latitude> <longitude> [<indoor_horizon> [<Weather_Position>]]

Zitat von: Christoph Morrison am 24 Februar 2019, 13:17:19
Nichts was Änderungen an global nach dem Define betrifft ...

Habe ich wohl nicht genau gelesen. Ich bin nicht davon ausgegangen das erwähnt wurde das Änderungen an global nach einem Weather define gemacht werden sollen. Das ist ja noch unsinniger wenn ein Modul sowas machen sollte.
Das Weather Modul liest beim define lediglich die Attribute aus dem globalen Device für Latitude und Longitude aus. Mehr nicht.

Zitat von: amenomade am 24 Februar 2019, 13:25:45
Wie machst Du das?

Aktuell kann Twilight das nicht. Ich überarbeite das Modul aber gerade und dann kann man entweder global als Keyword für Lat oder Long angeben (wenn man einen indoor horizon braucht), oder aber alle Angaben weglassen, dann ist global als Default hinterlegt. Bei Berechnungen greife ich dann auf global zu. Wie ich erkenne das global geändert wurde um die Daten neu zu errechnen, weiß ich noch nicht genau, aber es gibt ja einen Event dafür. Weather_Position wird es dann nur noch zur Kompatiblität geben, hat aber keinen Effekt (außer eines Log-Eintrages) mehr. Wetterdaten kommen analog zu useExtWeather dazu, jedoch klarer benannt.

Wenn allerdings Positionsdaten explizit angegeben sind, werden diese auch verwendet. Die Minimaldefintion von Twilight wird dann defmod Twilight Twilight sein (vorausgesetzt, man hat global gepflegt).

Dies ist das Verhalten, das ich von einer indirekten Angabe erwarten würde.

Wenn es wirklich dynamisch werden soll, dann wäre es m.M.n. sinnvoller über ein "set" Kommando auf dem Device. So wäre es wirklich dynamisch. Alle andere Lösungen führen zu einem unnötigen "save".

Hallo,
die Idee mit lokalen Wettervorhersage bei wechselnden Standort finde ich ganz prima.
Gerne würde ich dies auch realisieren. Ich muss aber leider noch etwas früher einsteigen.

ZitatIch bin schon soweit, dass ich das DarkSky Wetter angezeigt kriege mit fix angegebenen GPS-Koordinaten:

Dafür benötige ich noch etwas Unterstützung.
Bitte schickt mir doch zu, welchen GPS-Empfänger ihr verwendet, und wie ihr die GPS-Daten in FHEM bringt.
Dann kann ich dies schonmal auf die Reihe bringen.
Merci

https://forum.fhem.de/index.php/topic,75736.0.html

Hallo CoolTux,
ja, das habe ich auch bereits gesehen und gelesen.
Ich bereits gerade einen RPI 3 für "Mobile-Zwecke" vor, hab das Onboard-Wifi am Laufen und auch ein Homematic Funkmodul auf der Steckerleiste aufgebaut. Eine Empfehlung für diese Konstallation kann ich aus diesem Blog nicht herauslesen. Könnt ihr mir da noch bitte einen Hinweis geben.

Also du meinst wegen Konstellation was für ein GPS Empfänger?

Danke für die Rückfrage Cooltux.

Ja, die Stiftleiste ist ja bereits teilweise belegt (1-6). Stiftleiste wäre prima, da dann (hoffentlich) noch alles in ein Gehäuse passt.

Ich dachte da eher an einen USB GPS Empfänger.

Hi Cooltux,

ich kann dem anderen Blog leider nicht entnehmen, ob dieses Problem gelöst ist:

ZitatDanke, das klingt sehr Interessant! Werde ich mir auf jeden Fall mal anschauen. :)
Allerdings habe ich auf meinem Raspi bereits ein HM-MOD-RPI als HMUART sitzen. Krieg ich so einen dann trotzdem noch mit dran?

Genau deshalb frage ich nach. USB ist auch eine Möglichkeit, eben Möglichkeit nur 2. Eben wegen dem mobilen Einsatz und den stärkeren mechanischen Anforderungen. Hast du ne Empfehlung für USB, falls Möglichkeit 1 ausscheidet?

Nicht wirklich. Habe sowas alles nicht.
Vor 15 Jahren habe ich mal bei DeLock gearbeitet. Deren Produkte kann man ruhigen Gewissens nehmen.


Grüße

Um die GPS daten auf fhem zu bekommen, kannst Du ein Android Handy oder iPhone benutzen, auf dem Handy läuft dann z.B. Geofency oder Owntracks als APP/

Einrichtung fhem geofancy für Geofency https://wiki.fhem.de/wiki/GEOFANCY
Einrichtung fhem livetracking für Owntracks https://forum.fhem.de/index.php?topic=37412.0

Hi, das mit dem Handy ist mir bewusst. Danke für den Hinweis und die Links.
Diese erfordert aber, dass man das Handy immer in der Nähe des RPI liegen hat. Diese Abhängigkeit möchte ich gerne umgehen.

Eine abgeschlossene Lösung im Raspberry bevorzuge ich aktuell, auch wenn dies mehr Aufwand ist.

Dann schau mal hier, https://forum.fhem.de/index.php/topic,75736.0.html 
da hat einer einen U-BLOX NEO-6M GPS tracker an einen Raspi gehängt.

Hallo inoma,

diesen Blog hab ich im Blick, darüber kommt auch mein eigentlicher Gedanke zur Integration.

Da ist aber ein Punkt offen, den ich nicht deutet kann;

ZitatDanke, das klingt sehr Interessant! Werde ich mir auf jeden Fall mal anschauen. :)
Allerdings habe ich auf meinem Raspi bereits ein HM-MOD-RPI als HMUART sitzen. Krieg ich so einen dann trotzdem noch mit dran?

https://forum.fhem.de/index.php/topic,75736.msg676483.html#msg676483
Ich hab genau dasselbe Problem und erkenne in dem Blog die Antwort nicht.

Zitat von: UweUwe am 03 März 2019, 13:25:33
Hallo inoma,

diesen Blog hab ich im Blick, darüber kommt auch mein eigentlicher Gedanke zur Integration.

Da ist aber ein Punkt offen, den ich nicht deutet kann;https://forum.fhem.de/index.php/topic,75736.msg676483.html#msg676483
Ich hab genau dasselbe Problem und erkenne in dem Blog die Antwort nicht.

Ich hab den anderen Thread nicht wirklich (ganz) durch aber folgendes:

das HMOD-PCB btaucht:

VCC
GND
Tx
Rx

VCC und GND ist kein Problem, das kann/könnte man einfach "abzweigen" bzw. gibt es ja mehrere andere Pins...

Tx/Rx, also die serielle Schnittstelle (UART) kann halt nur EINMAL genutzt werden!

Ich habe etwas über das in den ersten paar Posts genannte GPS-Modul (U-BLOX NEO-6M GPS) nachgelesen und es kann/könnte auch per I2C oder SPI angesprochen werden.

Was ich jetzt nicht geschaut habe: ist Software vorhanden (für den PI), wo diese Schnittstelle(n) genutzt werden (habe aber auch nicht geschaut, ob es Software für den PI gibt, welche serielle Schnittstelle/UART nutzt ;)  ).

Wenn du Software hast/findest, die das GPS-Modul auch per I2C oder SPI anspricht, dann: ja.

Wenn es so eine Software nicht gibt: nein (bzw. komplizierter)

Komplizierter: UART - SPI/I2C Umsetzerplatine zwischen PI und GPS-Modul und dann eben selber programmieren...
(dann könntest du aber auch gleich selber SPI/I2C in Richtung GPS-Modul programmieren)

EDIT: eine Variante wäre noch andere GPIO zu verwenden und dann das Modul per "Software-Serial" betreiben. Also eine Software die per GPIO-Pins eine serielle Kommunikationsschnittstelle "emuliert". Ich würde den HMOD-PCB aber auf jeden Fall an der "Hardware-Schnittstelle" (UART) lassen! (wegen Timing) Und maximal für das GPS-Modul über Software-Serial nachdenken. Siehe auch: https://www.raspberrypi.org/forums/viewtopic.php?p=446164

Gruß, Joachim

Hallo Madmax, freut mich vor dir zu hören. Due erinnnerst dich sicherlich: "Homebridge" der "Linux-Experte".
Homebridge läuft gut.
Zurück zu GPS: Die Frage lautet also:
Ich möchte das (U-BLOX NEO-6M GPS) GPS Modul verwenden. Gibt es Software für den PI, die dieses Modul per I2C oder SPI anspricht. Hintergrund: Auf dem RPI 3 sind die Signale VCC, GND,TX und RX sind bereits durch ein anderes Modul verwendet. Die Verwendung von TX und RX ist somit ein Thema.

Ich gehe dem Thema nach und berichte.

Dank und Kölle Alaaf  ;D ;D

Zitat von: UweUwe am 03 März 2019, 13:50:48
Hallo Madmax, freut mich vor dir zu hören. Due erinnnerst dich sicherlich: "Homebridge" der "Linux-Experte".
Homebridge läuft gut.

Jaja, klar ;)
Freut mich!

Zitat von: UweUwe am 03 März 2019, 13:50:48
Zurück zu GPS: Die Frage lautet also:
Ich möchte das (U-BLOX NEO-6M GPS) GPS Modul verwenden. Gibt es Software für den PI, die dieses Modul per I2C oder SPI anspricht. Hintergrund: Auf dem RPI 3 sind die Signale VCC, GND,TX und RX sind bereits durch ein anderes Modul verwendet. Die Verwendung von TX und RX ist somit ein Thema.

Ich gehe dem Thema nach und berichte.

Dank und Kölle Alaaf  ;D ;D

Jep!
Also wie geschrieben: VCC/GND sind kein Problem. Aber natürlich die UART-Schnittstelle (Tx/Rx)!

Entweder mal bzgl. Software-Serial auf dem PI schauen (Link), dort steht, dass es halbwegs zuverlässig geht (bzw. eine Antwort spricht sogar von zuverlässig). Dann einfach bei der Standard-SW für das GPS-Modul (hast du die überhaupt? Wo gibt es die? Also für den PI) diese "emulierte Schnittstelle" angeben und das GPS-Modul halt auf die dort (Software-Serial) vorgesehenen GPIOs (2 Stück: "neues" Rx/Tx) plus irgendwo Spannung abzwacken...
...Oder eben wie von dir geschrieben: nach Software für das GPS-Modul über SPI/I2C suchen...

Gruß, Joachim

Hallo MadMax-FHEM,
ich bin noch nicht auf ein bestimmes Modul festgelegt, hab keines gekauft und keines im Sinn. Das Ublox sagt mir was und ich es auch verschiedentlich im Forum gefunden.
Aufgrund der folgenden Aussage war ich zuverlässig, eine Lösung zu finden:

ZitatHallo,
ich habe mir in unser Wohnmobil einen Raspi eingebaut mit GPS Modul an Bord, das hab' ich auch alles hingekriegt. (Temperaturmessung, Heizungsregelung und GPS Empfang funktioniert alles)
Jetzt würde ich gerne einen Wetterbericht anzeige in Abhängigkeit vom Standort (GPS-Daten)
Ich bin schon soweit, dass ich das DarkSky Wetter angezeigt kriege mit fix angegebenen GPS-Koordinaten:

Du hast aber recht, man weiss nicht, ob da RX/TX für ein anderes Modul (wie in meinem Fall) bereits verwendet wird. Hatte gehofft, dass der Schreiber sich meldet.
Für die TX/RX Lösung gibt es Beschreibungen.
https://raspberry.tips/raspberrypi-tutorials/gps-modul-mit-dem-raspberry-pi-ortung-und-navigation Aber:  VCC wird mit 3,3V versorgt und kommt daher beim RasPi an PIN1 (+ 3,3 V)
    GND ist natürlich auch beim RasPi GND und kommt daher an PIN6 (GND)
    RX ist da wir Seriell verwenden beim  RasPi TX und daher PIN8 (TXD0)
    TX ist da wir Seriell verwenden beim RasPi RX und daher PIN10  (RXD0)
.

Evtl. würde sich (langsam / v.a. wenn es diesbezgl. weiter geht/ginge ;)  ) ein neuer Thread anbieten...

Hier noch mal kurz:

wenn du auch den beim PI wohl vorhandenen gps-deamon (gpsd) nutzen willst, dann geht das wohl am einfachsten mittels "Software-Serial".
Also 2 andere GPIOs per Software zur seriellen Schnittstelle "machen" und dann diese beim Einrichten des gpsd angeben.

Allerdings habe ich mich (neben dem Posten des Links: https://www.raspberrypi.org/forums/viewtopic.php?p=446164) noch nicht mit Software-Serial beim PI beschäftigt.

Ich kenne das hauptsächlich von Arduinos, also Microcontrollern.
Da gibt es aber kein Betriebssystem und somit auch keine Timingprobleme (selbst mit Software-Serial nicht), außer man hat selber irgendwelche Schleifen programmiert, die nat. dann das Software-Serial negativ beeinflussen ;)

Wäre einen Versuch wert und geht sicher schneller/einfacher als selbst ein Programm zu schreiben, welches direkt per I2C/SPI auf das Modul zugreift...

EDIT: und sofern der gpsd nicht zu empfindlich ist, wenn auf der Seriellen-Schnittstelle mal "was nicht klappt" und auch die Baudraten nicht zu hoch sind (was ich nicht glaube, stimmt: ist wohl 9600 das ist moderat), dann könnte das tatsächlich gehen. Musst du nur schauen wie (bzw. welche Variante) du Software-Serial auf dem PI zum Laufen bringst...

EDIT2: eben da drüber "gestolpert" https://www.rs-online.com/designspark/raspberry-pi-2nd-uart-a-k-a-bit-banging-a-k-a-software-serial

EDIT3: oder ein UART-HAT https://www.kickstarter.com/projects/1915118535/uart-hat-for-raspberry-pi damit hast du dann 3 UARTs. Gut das HM-Funkmodul kannst du da wohl nicht mehr einfach so aufstecken, sondern musst es (vermutlich) anpassen. Pinbelegung vom HMOD-PCB ist aber dem Wiki zu entnehmen...

Gruß, Joachim

Hallo,
jetzt kann ich hier wieder einsteigen, zwischenzeitlich habe ich regelmässig folgenden Daten von meinem aktuellen Standort als reading.
lat  51.603589192 2019-03-13 21:23:04
lon 5.292722252 2019-03-13 21:23:04
Ich würde mir wünschen, dass ich morgens die Wettervorhersage von meinem aktuellen Standort bekommen würde.
Ich habe mir den Blog nochmals durchgelesen, kann aber nicht erkennen, in welches "Wetter" und mit welchem Befehl ich diese Daten jetzt in eine Abfage bekomme. Kann mir hier jemand behilflich sein? Auf dem Blog steht ja "gelöst".
Merci.
Für alle, die es interessiert: Ich habe die Integration einer GPS Maus (Global Sat BU 35354) hier dokumentiert.
https://forum.fhem.de/index.php/topic,98199.0.html .
Merci

Hallo,
hab jetzt folgendes umgesetzt, zur Nachahmung etwas dokumentiert. (RPI3).
1. eine an USB angeschlosseene GPS-Maus empfängt regelmässig die aktuelle GPS-Position und alle 10 Minuten lege ich die wichtigsten readings in FHEM (dblog) ab.
Alles hier dazu Notwendige ist hier beschrieben:
https://forum.fhem.de/index.php/topic,98199.0.html
2. Aus diesem blog habe ich folgende Kommandos übernommen:

ZitatCode: [Auswählen]
define GPS_global_upd at +*00:15:00 {fhem("attr global longitude ".ReadingsVal("KastenGPS","lon",""))}
Code: [Auswählen]
define GPSlat_global_upd at +*00:15:00 {fhem("attr global latitude ".ReadingsVal("KastenGPS","lat",""))}

Damit schreibe ich alle 20 Minuten die aktuellen GPS Daten in die "global", mein Vordenker machte es alle 15 Minuten..  8)

3. das Weather device muss installiert sein und mit dem folgenden Kommando kann man sich dann jeden Abend das Wetter für den nächsten Tag per pushover zuschicken lassen:
*20:00:00 set pushmsg msg 'Wetterinfo für Morgen: ' 'Wettervorhersage für [W_Reisen:fc2_day_of_week]: [W_Reisen:fc2_condition] - Temperaturen liegen zwischen [W_Reisen:fc2_low_c] °C und [W_Reisen:fc2_high_c] °C, Höchsttemperatur um [W_Reisen:fc2_apparentTempHighTime] Tiefsttemperatur um [W_Reisen:fc2_apparentTempLowTime]   [W_Reisen:fc2_wind_condition]  UV-Index: [W_Reisen:fc2_uvIndex] '

Mir ist schon bewusst, dass GPS und Hausautomatisierung nicht so sehr zusammenpasst. Merkt man auch, die Inbetriebnahme der GPS-Maus hakelte, doch manuelle Eingriffe notwendig. Scheint aber jetzt stabil zu laufen. Ab Sonntag dann "produktiv". Ich werde berichten