Neues Modul - Mobile Blitzer Anzeigen

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

Vorheriges Thema - Nächstes Thema

ThomasMagnum

Hallo bismota,

bzgl. deines Wunsches die Karte zu versenden, kann man evtl. das Programm "PlotasPNG" genutzt werden. Ausgangsbasis hierfür ist allerdings ein SVG welches man erst mal generieren müsste.

Eine weitere Option die ich noch auf meiner Liste habe wären dieser Thread:

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

da sind ein paar Hinweise drin die ich mal nachvollziehen wollte, da ich ähnliches für mein XMPP Interface suche. Hatte aber noch keine Zeit bzw. keinen Nerv hierzu.

Gruß, Thomas

bismosa

Hallo!

@Thomas
Ja...es gibt auch noch andere Linux Tools. Hier ein paar vorschläge:
https://stackoverflow.com/questions/10042388/program-that-convert-html-to-image

Mein ansinnen wäre eher (aber vermutlich nicht möglich) ohne zusätzliche Module etc. auszukommen...das macht das hier sonst immer etwas komplizierter und wäre dann nicht Plattformunabhängig.  ;)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

curt

Hallo @bismosa

um wegen FTUI sowie wegen des FTUI-Moduls Map zu verstehen, was Du da überhaupt "treibst", habe ich mir mal ganz schnöde den HTML-Quelltext im "normalen" Web-Interface von FHEM angesehen. Also das, was da als Ergebnis als HTML-Seite vom FHEM-Server verschickt wird.

Ok, Leaflet als Basis. Das das JS von extern geholt wird, das finde ich jetzt unschön - aber ich weiß zu wenig, um irgendwelche Ratschläge zur Umgehung zu erteilen.

Aber was ganz anderes fiel mir auf: Du hast da einen unschönen Codierungsfehler, darauf möchte ich Dich gern hinweisen: Du leitest einen TEIL einer Webseite (das Kartenkonstrukt) nochmals mit dem ganzen html-head-body-Zirkus ein und wieder aus. Das ergibt nicht validen HTML-Code.

Hoffe geholfen zu haben.

Ich grüße und wünsche einen schönen Sonntag.
RPI 4 - Jeelink HomeMatic Z-Wave

bismosa

Hallo!

@curt
Zitatum wegen FTUI sowie wegen des FTUI-Moduls Map zu verstehen, was Du da überhaupt "treibst", habe ich mir mal ganz schnöde den HTML-Quelltext im "normalen" Web-Interface von FHEM angesehen. Also das, was da als Ergebnis als HTML-Seite vom FHEM-Server verschickt wird.
Wäre einfacher gewesen mit dem "get <device> MapHTML". Dort wird der gleiche HTML-Code ausgegeben.
Außerdem ist der Quelltext frei bei Github bzw. im Perl-Modul deiner FHEM-Installation vorhanden.

ZitatOk, Leaflet als Basis. Das das JS von extern geholt wird, das finde ich jetzt unschön - aber ich weiß zu wenig, um irgendwelche Ratschläge zur Umgehung zu erteilen.
Hier gibt es genau 2 Möglichkeiten. Entweder extern laden oder mit dem Update bei jedem die JS mit installieren. Da finde ich das externe laden besser. So war das auch in dem Beispiel angegeben. Wie es sonst rechtlich aussieht, wenn ich die Leaflet-Dateien bei Github hochlade weiß ich nicht. Dann halte ich mich lieber an angegebene Beispiele.
Es steht Dir ja frei das Modul zu ändern und die JS lokal zu verwenden.

ZitatAber was ganz anderes fiel mir auf: Du hast da einen unschönen Codierungsfehler, darauf möchte ich Dich gern hinweisen: Du leitest einen TEIL einer Webseite (das Kartenkonstrukt) nochmals mit dem ganzen html-head-body-Zirkus ein und wieder aus. Das ergibt nicht validen HTML-Code.
Das verstehe ich jetzt nicht...
Ich habe tatsächlich einen <head> Bereich da mit drin (um die leaflet.js und die leaflet.css zu laden). Ich kann mir sogar vorstellen, das dies nicht den HTML-Richtlinien entspricht. Allerdings hat es anders nicht funktionieren wollen. Meine Browser melde$n keinen Fehler und die Seite wird zügig angezeigt. Daher denke ich, das dies zu vernachlässigen ist.
Derzeit läuft das Modul auf mind. 25 Installationen in 29 Definitionen...zumindest von den Installationen, die die Statistik an FHEM übermitteln. Bisher hatte wohl noch keiner Probleme damit...

Wenn Du ein Problem mit dem Modul hast (und den Eindruck bekomme ich hier immer mehr), möchte ich die um 2 dinge bitten:
1.) Schaue Dir den Quelltext an, ändere diesen und erstelle einen Patch mit den Verbesserungen. Dann kann ich mir das anschauen und ggf. die Änderungen mit einfließen lassen.
2.) Wenn Dir die Art des Moduls nicht gefällt möchte ich ich bitten das Modul wieder aus Deiner Installation zu entfernen und nicht weiter zu nutzen. So ist der Beitrag nicht sehr hilfreich.

Verbesserungsvorschläge werden immer gerne entgegen genommen. Ich bin reiner Hobby-Programmierer. Ich habe mir das alles selbst beigebracht...da sind Fehler nie auszuschließen.

@all
Bugs können logischerweise auch gerne gemeldet werden.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

curt

Hallo allerseits und ein besondern freundliches hallo @bismosa
Das wichtigste vorab:
Ich finde, dass Du sehr sensibel, zu sensibel bist. - Ich finde Dein Modul ganz außerordentlich prima. Ich freue mich, dass es das gibt. Und ich möchte im Rahmen meiner bescheidenen Möglichkeiten mithelfen.

Ich sage das, was mir auffällt. Ich sage das so präzise ich das sagen kann. Ich hoffe, dass Dir das hilft. Und wenn Du als Modulautor entscheidest, das das nicht hilft, dann ist das so - Du bist der Chef in diesem Ring.

Mir wäre sehr recht, wenn das nun geklärt wäre (das strengt mich ja auch an, ich will das nicht vor jeden Beitrag schreiben).

Ok, dann mal los:

Zitat von: bismosa am 17 Juni 2019, 08:24:24
Wäre einfacher gewesen mit dem "get <device> MapHTML". Dort wird der gleiche HTML-Code ausgegeben.

Nein, eben nicht.
Da kommt nur ein Fragment. Aber nicht die Seite, die dann real beim Klienten (Browser) ankommt.

Bring mal bitte Firefox an den Start, navigiere zur fraglichen Seite mit der Karte. Dann irgendwo im freien Bereich der Seite rechte Maustaste, dann klicke auf "Seitenquelltext anzeigen". In einem neuen Fenster bekommst Du den Seitenquelltext, dankenswerterweise schon die Fehler farblich markiert.

Der derzeit erzeuge html-Code ist nicht valide, das kann man nun drehen und wenden wie man will.

Zitat von: bismosa am 17 Juni 2019, 08:24:24Hier gibt es genau 2 Möglichkeiten. Entweder extern laden oder mit dem Update bei jedem die JS mit installieren. Da finde ich das externe laden besser. So war das auch in dem Beispiel angegeben.

Ich habe keine Idee, ob/wie man das anders/besser machen kann.

Bitte versteh aber: Ich bin der Sicherheitsfanatiker: Möglichst nichts, was von außen kommt.
(Ja, das Leben besteht aus Kompromissen. Ich wollte öffentlich darauf hinweisen - irgendwie schon mit der Idee, dass ein Dritter um die Ecke kommt und fröhlich "aber so geht das doch auch" schreibt.

Zitat von: bismosa am 17 Juni 2019, 08:24:24
Ich habe tatsächlich einen <head> Bereich da mit drin (um die leaflet.js und die leaflet.css zu laden). Ich kann mir sogar vorstellen, das dies nicht den HTML-Richtlinien entspricht. Allerdings hat es anders nicht funktionieren wollen.

Ahhh - verstanden. Ok, das ist ein Problem.

Der Autor der Map-Moduls (OSM-Karte mit Verkehrslage von Nokia oder wer weiß wem) hat das in seinem Thread oder im Wiki so gelöst: Er schreibt sinngemäß: Also wenn Du das willst, dann MUSST Du in /opt/fhem/www/tablet/index.html im HEAD-Bereich folgende Zeile eintragen - sonst geht das nicht.

Das habe ich jetzt aus dem Stegreif geschrieben - wenn Du willst, suche ich das alles genau raus. Kein Problem. (Nur halt nicht jetzt, in diesem Beitrag) - Bitte einfach sagen.

Zitat von: bismosa am 17 Juni 2019, 08:24:24Meine Browser melde$n keinen Fehler und die Seite wird zügig angezeigt. Daher denke ich, das dies zu vernachlässigen ist.

Ist bei mir auch so. Ich teile Deine Sicht aber trotzdem nicht. Nicht valider html-Code ist ein Problem. Und kann künftig ganz unerwartet zu verblüffenden Seiteneffekten führen.

Zitat von: bismosa am 17 Juni 2019, 08:24:24
1.) Schaue Dir den Quelltext an, ändere diesen und erstelle einen Patch mit den Verbesserungen. Dann kann ich mir das anschauen und ggf. die Änderungen mit einfließen lassen.

Ich will wirklich gern mithelfen - aber das kann ich leider nicht.

Zitat von: bismosa am 17 Juni 2019, 08:24:242.) Wenn Dir die Art des Moduls nicht gefällt

Ach Du ... :(
Es gefällt mir ausgezeichnet. Wenn ich das für Käse halten würde, wäre es doch schon längst gelöscht. Statt dessen formuliere ich hier lange rum, um Dir ja nicht weh zu tun - gleichzeitig aber meine Sicht beizusteuern.

Hinweise (und selbst wenn Sie aus Deiner Sicht Schwachsinn sein sollten) sind doch weder Kritik an Dir noch am Modul! Es schreibt doch niemand, weil er was schlecht machen will. Es geht doch darum, es NOCH besser zu machen. BITTE - fühle Dich nicht angegriffen.
RPI 4 - Jeelink HomeMatic Z-Wave

MadMax-FHEM

Zitat
Ich will wirklich gern mithelfen - aber das kann ich leider nicht.

Kann man lernen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Gisbert

#111
Zitat von: MadMax-FHEM am 18 Juni 2019, 08:05:43
Kann man lernen...

Gruß, Joachim

Hallo Joachim,
auch wenn dein und mein Beitrag jetzt OT sind, natürlich kann man alles lernen: Informatik, Elektrotechnik, Physik, Humanmedizin könnte auch helfen, Gas-Wasser-Sch..., KFZ-Technik, -Elektronik, ... uvm, was man so im Alltag gebrauchen könnte (die schönen Künste, Philosophie und Juristerei mal bewusst ausgespart).
Die Frage ist ja, für was reicht die Lebenszeit noch, alles wird im fortgeschrittenen Alter nicht mehr gelingen, und Fhem an sich ist schon eine Herausforderung, zumindest für mich.

OT Ende und :-X

Viele​ Grüße​ Gisbert​

Edit:
Damit das nicht zu kurz kommt, ein dickes Lob an alle Entwickler, Tester und User, die helfen ein schönes Ergebnis noch ein wenig besser oder anwenderfreundlicher zu machen  :-*
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

MadMax-FHEM

#112
Aber man muss auch nicht an jeden Beitrag dran hängen was man nicht kann...
...und an anderer Stelle "prahlen" was man studiert hat etc.
Und es ist ja nicht nur hier sondern zieht sich halt durch...

Und jetzt halte ich mich wieder dran was ich geschrieben hab: kein Kommentar mehr bzgl. ...

EDIT: ebenso auf private "Zurechtweisungen" von ... Ich stehe zu dem was ich schreibe, darum hab ich kein Problem das in einem Forum zu tun und muss nicht noch per PN um mich werfen... Aber wie mehrfach geschrieben und jetzt wirklich... No comment...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Gisbert

Hallo Joachim,

ich hoffe das "Prahlen" bezog sich nicht auf mich. Jeder hat Limits, oder wie mein alter Chef gerne sagte: "Man kann sich ja mal dumm stellen, andersrum ist schwieriger." ;D

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

MadMax-FHEM

Nö.

Ich hab dich noch in keinem Thread prahlen "hören"...
...oder über deine Limitierungen "jammern" hören...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

bismosa

Hallo!

Nun sitze ich auch mal wieder am Rechner und kann auch auf meinen Raspberry zurückgreifen.

@Joachim
ZitatKann man lernen...

Das bzw. ähnliches habe ich hier schon häufiger als Antwort bekommen und war nie böse drum. Mich persönlich hat es angespornt mich da etwas einzuarbeiten. Eigentlich nimmt einen das ein wenig die Angst vor dem schwierigeren Anfang...mittlerweile ist das kein Hexenwerk mehr für mich  :)
Und ich denke mit meinem ersten Modul stehe ich schon nicht schlecht dar  8)

@curt
Zitat
ZitatWäre einfacher gewesen mit dem "get <device> MapHTML". Dort wird der gleiche HTML-Code ausgegeben.

Nein, eben nicht.
Da kommt nur ein Fragment. Aber nicht die Seite, die dann real beim Klienten (Browser) ankommt.

Ja...fast genau das Fagment, was ich in die Seite "einschleuse". Ich tausche den Bereich des Icons mit diesem HTML aus. Das "fast" bezieght sich nur auf ein "</pre>", das FHEM am Ende des HTMLs mit hinzufügt, wenn es im Popup angezeigt wird. Woher dies kommt weiß ich derzeit nicht...

ZitatBring mal bitte Firefox an den Start, navigiere zur fraglichen Seite mit der Karte. Dann irgendwo im freien Bereich der Seite rechte Maustaste, dann klicke auf "Seitenquelltext anzeigen". In einem neuen Fenster bekommst Du den Seitenquelltext, dankenswerterweise schon die Fehler farblich markiert.
Ich nutze den Firefox eigentlich nicht. Habe mir den aber gerade mal installiert um zu vergleichen, wie es der FireFox und der Chrome im Vergleich darstellen.
In Chrome werden mir weitaus mehr Warnungen angezeigt...die nichts mit dem eingeschleusten HTML zu tun haben. Es sind aber keine "Errors" dabei.

ZitatDer Autor der Map-Moduls (OSM-Karte mit Verkehrslage von Nokia oder wer weiß wem) hat das in seinem Thread oder im Wiki so gelöst: Er schreibt sinngemäß: Also wenn Du das willst, dann MUSST Du in /opt/fhem/www/tablet/index.html im HEAD-Bereich folgende Zeile eintragen - sonst geht das nicht.
Wir sind hier nicht im FTUI, sondern in FHEM. Da bringt es nichts die FTUI-Dateien zu verändern.

Ist bei mir auch so. Ich teile Deine Sicht aber trotzdem nicht. Nicht valider html-Code ist ein Problem. Und kann künftig ganz unerwartet zu verblüffenden Seiteneffekten führen.

Wie schon geschrieben. Es gibt ja mehrere Möglichkeiten. Hier vielleicht noch eine weitere:
Den User dazu bringen die CSS-Datei in das richtige Verzeichnis (und das ist je nach System unterschiedlich) zu kopieren, dann in FHEMWEB einen Verweis darauf zu erstellen und dann letztendlich erst dann die Karte zu nutzen. Wird dies nicht getan, wird der User überschüttet mit Fehlermeldungen...
Ich finde das sehr unpraktisch...plötzlich muss man bis etwas funktioniert erstmal die richtige Anleitung finden und ist dann schnell gefrustet, wenn es nicht gleich funktioniert.

ZitatIch bin der Sicherheitsfanatiker: Möglichst nichts, was von außen kommt.
Auch hier kann ich mich nur wiederholen: Dann bitte die Karte nicht benutzen oder das Modul umschreiben. Wirklich kein Hexenwerk.  :)

Fazit:
Ich habe jetzt nochmal ein wenig experimentiert aber keine andere Lösung gefunden. Daher habe ich folgenden Entschluss gefasst:
Ich werde es derzeit so lassen wie es ist. Es werden weiterhin die externen Dateien geladen und der HTML-Code bleibt wie er ist. Ich sehe die anderen Möglichkeiten als unpraktikabel. Im Chrome werden mir nur Warnings keine Errors angezeigt. Daher gehe ich davon aus, das auch ein nicht 100% valider HTML-Code hier nicht zu problemen führen sollte. Die Browser kommen ja damit derzeit zurecht.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

curt

Hallo @bismosa

FTUI war falsche Assoziation, stimmt. Das kam daher: Ich wollte mir den HTML-Quellcode ansehen in Bezug darauf, ob/wie man das in FTUI übernehmen könnte. (Da hatte ich dann erstmal gestoppt und wollte diese Diskussion abwarten.)

Ja, ok - hast Du jetzt so entschieden. Können sicher alle mit leben. Und falls in der Zukunft Browser mal zicken, dann haben wir im Hinterkopf, dass es daran liegen könnte.
RPI 4 - Jeelink HomeMatic Z-Wave

elektrikpe2

Hallo,

vielen Dank für diese saubere Arbeit. Modul integriert, konfiguriert, funktioniert. Ich sehe es aber richtig, dass tatsächlich nur die mobilen Blitzer gemeldet werden. Gibt es die Möglichkeit auch die festen Blitzer ausgegeben zu bekommen. Habe das jetzt bei der Durchsicht der beiden Threads nicht gefunden.

LG Peter

bismosa

Hallo!
Nein, die Möglichkeit auch feste Blitzer anzuzeigen ist derzeit nicht integriert...die kennt man ja auch im Normalfall in der Homezone  :)

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Gisbert

Zitat von: bismosa am 21 Juni 2019, 13:28:54
Hallo!
Nein, die Möglichkeit auch feste Blitzer anzuzeigen ist derzeit nicht integriert...die kennt man ja auch im Normalfall in der Homezone  :)
Gruß
Bismosa

Hallo Bismosa,
geht es technisch nicht, die festen Blitzer anzuzeigen?
Dein Argument ist natürlich richtig, in der Homezone kennt man sie nach einer gewissen Zeit. Es gibt aber immer paar wirklich gemeine Stellen, an denen man selten und dann zum 1. Mal vorbeikommt (z.B. nachts vor Kindergärten), wo man nicht vermutet, dass geblitzt wird, und wegen mangelnden Verkehr vor und hinter einem, nicht besonders gewarnt ist. Es geht ja nicht ums Rasen, aber ein paar Kilometer überm Limit kosten halt auch Geld, ohne dass irgendeine Sicherheit erhöht werden würde.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY