Neues Modul - Mobile Blitzer Anzeigen

Begonnen von bismosa, 27 März 2019, 20:14:16

Vorheriges Thema - Nächstes Thema

Sailor

Ein herzerfrischend Moin vom achtern Diek vorweg!

Wenn dort gar kein Zugang mehr zu bekommen ist, kann der Modul-Owner ja versuchen auf eine neue Quelle umzusteigen:
https://github.com/Steiger04/ioBroker.radar-trap/wiki/radar-trap-Adapter-(deutsch)

Gruß
    Sailor
******************************
Man wird immer besser...

Wolle02

@bismosa:
Ich hätte hier einen Patch mit dem es bei mir wieder geht.

Jamo

Guten morgen, wenn ich den Patch mit patch < Blitzer.patch auf 98_Blitzer.pm anwende, bekomme ich patch fails with multiple rejected hunks. Wahrscheinlich ist der Patch fuer einen andere Version von 98_Blitzer.pm gemacht worden.
@Wolle02: Kannst Du eventuell die gepatchte Version von 98_Blitzer.pm hier posten, oder den 98_Blitzer.pm, auf den ich den Patch anwenden muss?
Anbei meine Files.

patch < Blitzer.patch
patching file 98_Blitzer.pm
Hunk #2 succeeded at 44 (offset -1 lines).
Hunk #3 FAILED at 447.
Hunk #4 succeeded at 513 (offset -17 lines).
Hunk #5 succeeded at 560 (offset -17 lines).
Hunk #6 succeeded at 584 (offset -17 lines).
Hunk #7 FAILED at 641.
Hunk #8 FAILED at 653.
Hunk #9 FAILED at 689.
Hunk #10 FAILED at 764.
Hunk #11 FAILED at 813.
Hunk #12 succeeded at 775 (offset -66 lines).
Hunk #13 succeeded at 881 (offset -66 lines).
6 out of 13 hunks FAILED -- saving rejects to file 98_Blitzer.pm.rej
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee2MQTT, Conbee III, FB7690, Signal, Alexa (fhem-lazy), Geotracking, LaCrosse JeeLink, LoRaWan (TTN / Chirpstack), Sonos, ESPresence, HomeAssistant via MQTT, Meshtastic

Wolle02

Ja, da hat die KI bei dem Patch wohl Scheiße gebaut. Das vollständige Modul funktioniert bei mir aber eigentlich ganz gut. Ich habe es angehängt.

Jamo

Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee2MQTT, Conbee III, FB7690, Signal, Alexa (fhem-lazy), Geotracking, LaCrosse JeeLink, LoRaWan (TTN / Chirpstack), Sonos, ESPresence, HomeAssistant via MQTT, Meshtastic

blitzerinkiel

#275
@wolle02

Danke für die Bereitstellung, sie half mir bei der Lösung meines Problems. Die API von blitzer.de geht mit dem Aufruf der neuen Datei ^^ Ich selbst nutze es anderes aber atudo war ja tot... Endlich wieder Blitzer abfragen 🫣

Prof. Dr. Peter Henning

#276
Das Modul hat auch nach dem Patch eine wesentliche Schwäche.
Es verlangt das Attribut area_bottomLeft_latitude, um überhaupt etwas anzuzeigen - und setzt danach die anderen Eck-Koordinaten als Attribute(!) auf ziemlich intransparente Weise.

Ich schlage folgende Änderungen vor:
1. Wenn die Attribute home_latitude/home_longitude nicht gesetzt sind, werden die Werte aus dem global-device verwendet.
2. Als Attribut verbleibt lediglich radius. Das Modul berechnet daraus die Eckkoordinaten der Bounding Box. Dazu kann man diesen Code hier verwenden: https://forum.fhem.de/index.php?topic=145912
3. Diese Eckpunkte werden als Reading gesetzt, denn ein Modul sollte nicht seine eigenen Attribute verändern können.

Außerdem halte ich es nicht für sinnvoll, eine erzeugte Karte als Bild zu versenden. Das frisst nur mobile Bandbreite. Stattdessen ist es besser, einen anklickbaren Link zu senden - dann kann der Empfänger selbst entscheiden, ob ihm die textuelle Angabe ausreicht, oder er eine Karte sehen will.

LG

pah

Edit: Ich sehe, dass in dem Modul die Eckkoordinaten schon berechnet werden - allerdings ist das alles etwas wirr, warum ist dann noch die Angabe der Eckpunkte nötig? Da scheint mir dringend eine Überarbeitung nötig zu sein. Auch solche Codezeilen wie
sqrt($radius*$radius+$radius*$radius)*1000sind ziemlich sinnlos - wieso wird als "Abstand" gerade Wurzel(2) * radius gesetzt?

sat-cracker

Danke für den Patch. Läuft wieder einwandfrei!
Echtsystem:  intel NUC i7, fhem 5.9, 5x LGW, nanocul433, nanocul868, nanoculHM, sduino,
Testsystem auf Raspberry Pi 4