59_Buienradar

Begonnen von Christoph Morrison, 23 Juli 2019, 21:37:15

Vorheriges Thema - Nächstes Thema

mahowi

Wenn ich den Code richtig lese, wird jedes Kommando verhindert, wenn keine Wert für "disabled" angegeben wird:

    given ($attribute_name) {
        when ('disabled') {
            Debugging(
                Dumper (
                    {
                        'attribute_value' => $attribute_value,
                        'attr' => 'disabled',
                        "command" => $command,
                    }
                )
            );

            return "${attribute_value} is no valid value for disabled. Only 'on', '1', '0' or 'off' are allowed!"
                if $attribute_value !~ /^(on|off|0|1)$/;

            given ($command) {
[...]

Da bei fehlendem oder falschem Wert sofort mit der Fehlermeldung zurückgesprungen wird, wird das Kommando zum Löschen nie ausgeführt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

mahowi

Ich habe die Überprüfung jetzt bei mir im Github hinter das "set" geschoben. Jetzt wird der Wert nur beim Setzen des Attributs geprüft.
            given ($command) {
                when ('set') {
               
                return "${attribute_value} is no valid value for disabled. Only 'on', '1', '0' or 'off' are allowed!"
                if $attribute_value !~ /^(on|off|0|1)$/;


Solange Christoph den PR noch nicht übernommen hat, kann man auf die Version mit inomas Patches mit
update all https://raw.githubusercontent.com/mahowi/mod-Buienradar/2.2.5/controls_Buienradar.txt
updaten.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Christoph Morrison

#107
Ich hab' mir für diese Woche ein bisschen mehr Zeit für Buienradar eingeplant (und für FHEM allgemein). Denke ich komme morgen dazu mir die gesammelten Sachen anzuschauen und zu mergen.

Christoph Morrison

Zitat von: inoma am 18 August 2019, 18:12:48
Hallo Christoph,
kurze Rückmeldung:
1) Das Buienradar funktioniert südlich in Deutschland bis kurz vor Garmisch Partenkirchen, weiter südlich kommen keine Daten mehr.

Siehe Issue 8. Ich bekomme durchaus auch Daten für Innsbruck - und das liegt ja bekanntlich südlich von G-P. Bozen z.B. ist dann out of coverage.

Christoph Morrison

Zitat von: inoma am 18 August 2019, 18:12:48
2) Wenn man ein "deleteattr Buienradar disabled" eingibt (oder im Webinterface das attribut disabled löscht), kommt folgende Fehlermeldung:
is no valid value for disabled. Only 'on', '1', '0' or 'off' are allowed!

Issue #7 fixed in 2.2.4

Christoph Morrison

Zitat von: somansch am 10 August 2019, 14:41:38
Ich habe heute auf die letzte Version (2.2.5) aktualisiert. Dabei ist mir aufgefallen, dass das Reading "chartData" nicht mehr aktualisiert wird.

Achtung, das ist nicht die offizielle Version des Moduls. Wenn du über mahowis 2.2.5 sprechen möchtest, dann mach bitte einen neuen Thread auf.

Christoph Morrison

Zitat von: mahowi am 18 August 2019, 20:25:51
Solange Christoph den PR noch nicht übernommen hat, kann man auf die Version mit inomas Patches mit
update all https://raw.githubusercontent.com/mahowi/mod-Buienradar/2.2.5/controls_Buienradar.txt
updaten.

Das seht dir natürlich frei, ist ja open source. Allerdings haben eure Versionen die ihr hier hochladet dazu geführt, dass nun verschiedene Versionen von Buienradar verwendet werden (z.B. von somansch).

Wirklich helfen könnt ihr mir indem:
- Am besten das Github-Repository nutzen - und auch nur Github - um Code mit mir zu teilen. Wenn ihr hier Versionen der 59_Buienradar.pm hochladet motiviert das Nutzer dazu, diese runterzuladen und am Ende haben wir verschiedene Versionen im Umlauf für die ich keinen Support geben kann bzw. Support komplizierter macht weil es irgendwann auch eine offiziöse 2.2.5 geben wird und dann weiß keiner von welcher Version wir reden.
-  Einzelne Features in einzelnen Feature-Branches entwickelt und dann für einzelne Features auch einzelne Pull-Requests erstellt. Ich hab jetzt einen recht umfangreichen PR von mahowi bekommen über den ich mich eigentlich freue, aber der mich auch vor ein paar Probleme stellt: Ich möchte nicht alle Sachen übernehmen (z.B. die Dokuanpassung für disabled oder den konkreten Code für den Bar-Chart), aber ich kann nun nur recht beschwerlich die Sachen mergen, d.h. ich schaue mir die nun einzeln an und übernehme die doch wieder manuell (oder halt nicht). Mir ist klar, dass die Arbeit mit Branches, Pull Requests und Co. eher ungewohnt sind. Wenn man das aber konsequent sauber macht, kann man wirklich große Vorteile daraus ziehen.
- Issues direkt bei Github anlegt wenn ihr einen Account habt (kostet ja nix, kann man sich schon mal anlegen). Sonst mache ich hier wildes Kreuzverlinken und Copy/Paste mit dem Forum.

Viele Dank insbesondere an mahowi und inoma. Auch wenn ich nicht alle Ideen / Wünsche teile.

Christoph Morrison

Zitat von: inoma am 01 August 2019, 12:40:18
Laut Google Wiki ist "Rainamount" die RegenMenge, die in einem definierten Zeitraum fällt,

Was ist denn Google Wiki? Im Kontext von Buienradar ist rainAmount einfach nur die Regenmenge, die im nächsten 5-Minuten-Intervall gemeldet ist. Das Naming ist vielleicht nicht super, aber das war in der Originalversion schon so und ich möchte das in einer 2er-Version nicht ändern. Ich nehme mir das aber mal für eine kommende 3.0 mit. Allgemein sind solche Kontextänderungen besonders kniffelig zu releasen, denn man löscht den Datenpunkt ja nicht (in dem man ihn z.B. umbenennt), sondern ändert nur seine Bedeutung. Ein hypothetischer Nutzer der eine Logik darauf gebaut hat, dass rainAmount den Niederschlag im nächsten 5-Minuten-Intervall beinhaltet, würde das nun ohne weitere Notiz weggeändert bekommen. Das sollte ein User innerhalb einer major version nicht erwarten müssen.

Ein kurzer Exkurs zu den Versionen:
Ich benutze (wie viele andere FHEM-(Modul)-Entwickler) Semantic Versioning. Das Summary in dem Link sagt schon ganz gut, warum LuBeDas Version die 1 und meine Version jetzt die 2 ist, denn ich habe in der 2 ein paar Änderungen gemacht, die die API auf das Modul geändert haben (z.B. habe ich den Namensraum auf FHEM::Buienradar geändert und damit alle Integrationen von Google Charts / HTML-Graph). D.h. jeder der die 1er-Version im Einsatz hat, hat nach einem Update auf die 2er defekte Definitionen in seinem FHEM (kurze geistige Pause um die Tragweite davon zu verdeutlichen). Die 2.1 und 2.2 sind minor versions, d.h. zusammengepackte Feature-Changes. 2.2.x ist dann ein Bugfix an der minor-Version (z.B. 2.2.1 ist der erste Bugfix an 2.2). Das mit den Bugfixes habe ich bisher nicht wirklich verfolgt, ist aber geplant.

Christoph Morrison

Fehlerhafte Berechnung von rainNow in 2.1 und 2.2 gefixt. Beide finden sich nun in eigene Branches. Development existiert nicht mehr.

Jamo

Hallo Christoph,
ich habe jetzt noch nicht nicht nachgeguckt wie Du das 'RainAmount' gefixt hast.
Aber ein offener Punkt war doch der fehlende Unterschied zwischen 'rainNow' und rainAmount', die in den ursprünglichen Versionen beide den gleichen Wert geliefert haben, also den Wert für die Regenmenge in den nächsten 5 Minuten.
Deswegen mein Vorschlag, nach Google, rainAmount als die Regenmenge l/qm oder mm/h zu berechnen, und rainNow zu belassen. Das ist meiner Internet Suche der Standard um Regenmengen zu vergleichen. Ich habe immer nur für Regenmenge = RainAmount 1) Werte in mm/h (also Liter/qm), ODER 2) die Tagessumme (Tägliche Niederschlagsmenge) gefunden.

1) https://www.wetter.com/wetterkarten/niederschlagsmengen/niederschlagsmengen-bayern/#geo:49.0000,11.5000,7
2) https://www.wetter.com/deutschland/muenchen/DE0006515.html#niederschlag
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Christoph Morrison

Hallo inoma,

Zitat von: inoma am 19 August 2019, 22:43:05
ich habe jetzt noch nicht nicht nachgeguckt wie Du das 'RainAmount' gefixt hast.

In der 2.x wird das noch gar nicht gefixt werden, denn das würde die API für die Benutzer ändern und kommt deshalb in die 3.x (mit ein paar weiteren Änderungen an den Readings, insb. Änderungen im Naming der Readings). Ich denke ich werde mich an deiner / eurer Version orientieren.

Zitat von: inoma am 19 August 2019, 22:43:05
Aber ein offener Punkt war doch der fehlende Unterschied zwischen 'rainNow' und rainAmount', die in den ursprünglichen Versionen beide den gleichen Wert geliefert haben, also den Wert für die Regenmenge in den nächsten 5 Minuten.
Deswegen mein Vorschlag, nach Google, rainAmount als die Regenmenge l/qm oder mm/h zu berechnen, und rainNow zu belassen. Das ist meiner Internet Suche der Standard um Regenmengen zu vergleichen. Ich habe immer nur für Regenmenge = RainAmount 1) Werte in mm/h (also Liter/qm), ODER 2) die Tagessumme (Tägliche Niederschlagsmenge) gefunden.

1) https://www.wetter.com/wetterkarten/niederschlagsmengen/niederschlagsmengen-bayern/#geo:49.0000,11.5000,7
2) https://www.wetter.com/deutschland/muenchen/DE0006515.html#niederschlag

Ich nehme das mal mit 'rüber zu Github und meditiere darüber.

Für die 2er wird's wohl nur noch ein paar kleinere Features wie rainDuration und zwei neue Charts geben (fügen der API was hinzu, was keine Kompatibilität bricht, also ist's in einer minor version ok).

Jamo

Danke! Nur zur Info, hier mal ein Screenshot vom 'BAR', im direkten Vergleich von Buienradar und RainTMC.
Der Regen soll etwa um 1:10 anfangen, laut den Radarbildchen.
Mein Eindruck ist, Buienradar ist etwas akurater, dafür ist der Vorhersagezeitraum kürzer (2 Stunden), RainTMC hat etwa 3 Stunden.

Ich benutze das "dark" Theme von FHEMWEB, ich finde die 'BAR' Darstellung am übersichtlichsten, weil platzsparend, und ich will nur wissen ob es regnet, wenn ja, dann ob schwach/wenig/mittel/stark/heftig, und das ist über die Farben optisch gut dargestellt.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Christoph Morrison

rainEnd und das Problem mit disabled sind nun in 2.x gefixt.

Christoph Morrison

Zitat von: inoma am 20 August 2019, 00:00:27
Danke! Nur zur Info, hier mal ein Screenshot vom 'BAR', im direkten Vergleich von Buienradar und RainTMC.
Der Regen soll etwa um 1:10 anfangen, laut den Radarbildchen.
Mein Eindruck ist, Buienradar ist etwas akurater, dafür ist der Vorhersagezeitraum kürzer (2 Stunden), RainTMC hat etwa 3 Stunden.

Ich benutze das "dark" Theme von FHEMWEB, ich finde die 'BAR' Darstellung am übersichtlichsten, weil platzsparend, und ich will nur wissen ob es regnet, wenn ja, dann ob schwach/wenig/mittel/stark/heftig, und das ist über die Farben optisch gut dargestellt.

Gefällt mir. Wie hast du das mit dem Picker rechts (AtHome) bei Buienradar realisiert?

Christoph Morrison

Ich hab jetzt die 2.3 begonnen. Hier seht ihr was geplant ist / gemacht wurde.