Offset bei Regenmengenmesser mit TRX_WEATHER (hier: TFA_RAIN)

[mi.ke]

Hi Oli,

kennst Du eine Möglichkeit, wie man bei "rain_total" einen Offset-Wert mitgeben kann?

In der Commandref ist zu lesen, dass bei den OWL-devices offsets mitgegeben werden können.
Deshalb der Versuch:

Code: [Auswählen]

defmod TFA_RAIN TRX_WEATHER 28000Wobei es leider bei diesem Beispiel zu einer Fehlermeldung kommt:
"wrong syntax: define <name> TRX_WEATHER code"

Hintergrund, warum ich Hilfe brauche:
Ich nutze seit 2014 einen Regenmengenmesser TFA 30.3148. Dieser hat nun den Geist aufgegeben.
Neuen bestellt und der wurde sofort als gleiches Device erkannt.

Problem ist nun, dass "rain_total" natürlich "0" ist. Ich nutze allerdings verschiedene historische Daten, die aus Readings und LOG-Files, Statistiken und neue Readings aus den IST-Werten erzeugen.

Habe versucht mit userreadings zu kompensieren, aber da ich über den Sensor einen Trichter gebaut habe, um die Genauigkeit zu verbessern, muss immer mit Faktoren gerechnet werden, damit die gemessene Menge stimmt.
Jetzt wurde der Trichter in der Vergangenheit auch noch gegen einen mit anderem Durchmesser getauscht wegen Defekt.

Und dann kommt erschwerend dazu, dass ich in den Anfängen seit 2013, aus heutiger Sicht, ein sehr verwirrendes und verzweigtes Konstrukt aus dummys,cloneDummys und notifys gebastelt habe, dass zwar funktioniert, aber nicht wirklich Wartungsfreundlich ist.

Kurz um, ich musste ein Backup der LOGs einspielen und den Regenmesser wieder offline nehmen, weil meine Rasenbewässerung plötzlich 2 Jahre am Stück laufen wollte, da dem Rasen angeblich 2000 Liter Wasser pro qm die letzten Wochen gefehlt hätten....

Von daher die Frage nach einer pragmatischen Lösung

besten Dank und und lieben Gruß
mi.ke

[KernSani]

Moin,
nur dass ich es richtig verstehe: Wegen der „gewachsenen Struktur“ möchtest du nicht „rain_total“ in allen möglichen Konstrukten durch ein „my_rain_total“ ersetzen? (Wobei in dem Fall ein bisschen fhem.cfg editieren vermutlich ok wäre)
Ich könnte ein Attribut rein basteln, dessen Wert zu rain_total hinzugezählt wird. Würde das helfen?
Grüße,
Oli


Kurz, weil mobil....

[mi.ke]

Ich könnte ein Attribut rein basteln, dessen Wert zu rain_total hinzugezählt wird. Würde das helfen?

meinst Du mit z.B.

Code: [Auswählen]

attr DEVICE offset 28123.987456321Das wäre klasse!

Cheers
mi.ke

[KernSani]

Bitte mal kurz testen. Attribut heisst rain_offset.

[mi.ke]

Hi Oli,

klasse, danke, für mich funktioniert das so.

Aber um im Standard zu bleiben müsste der Offset dann doch auch im "state" stattfinden ("TR"), oder?

cheers
mi.ke

[KernSani]

Guten Morgen,
Fa hast  du wohl recht :-) Passe ich noch an, bevor ich es einchecke.
Ich habe selbst keinen Ragenmesser daher habe ich mehr oder weniger „blind“ programmiert.
Schönen Sonntag!


Kurz, weil mobil....

[mi.ke]

Hi Oli,

soll Dir ganz liebe Grüße von meinem Rasen bestellen, der heute morgen die erwartete Menge Wasser bekommen hat.
Nochmal vielen Dank für die ultraschnelle Hilfe.

Schönes Restwochenende

mi.ke

[mi.ke]

Moin Oli,
was mir noch aufgefallen ist

Seit der neuen TRX_WEATHER sind plötzlich zwei Batterie-Readings da

Code: [Auswählen]

battery         ok 100%
batteryState    ok 100%
bei der "alten war nur

Code: [Auswählen]

battery        ok 100%
Sinn würde zwei ja machen, aber dann so:

Code: [Auswählen]

battery         ok
batteryState    100%
Was meinst Du?

Cheers
mi.ke

PS.
hatte extra noch mal die vorherige Version eingespielt, damit auch wirklich klar ist, woher der Effekt kommt

PPS.
Gab es nicht einmal ein Diskussion darüber, die battery-Radings komplett zu vereinheitlichen?
Ich weiss allerdings nicht, wie und ob es damals eine Einigung gab.


Edit: PPS eingefügt

[KernSani]

Moin Oli,
was mir noch aufgefallen ist

Seit der neuen TRX_WEATHER sind plötzlich zwei Batterie-Readings da

Code: [Auswählen]

battery         ok 100%
batteryState    ok 100%
bei der "alten war nur

Code: [Auswählen]

battery        ok 100%
Sinn würde zwei ja machen, aber dann so:

Code: [Auswählen]

battery         ok
batteryState    100%
Was meinst Du?

Cheers
mi.ke

PS.
hatte extra noch mal die vorherige Version eingespielt, damit auch wirklich klar ist, woher der Effekt kommt

PPS.
Gab es nicht einmal ein Diskussion darüber, die battery-Radings komplett zu vereinheitlichen?
Ich weiss allerdings nicht, wie und ob es damals eine Einigung gab.


Edit: PPS eingefügt

Ich bin etwas irritiert, dass du zuvor keine zwei readings hattest. Ich habe die Änderungen eigentlich basierend auf der letzten SVN Version gemacht... Aber du hast recht. Es gab damals die Diskussion und basierend darauf habe ich die Änderung gemacht, allerdings unvollständig/fehlerhaft. Das habe ich gefixt. Gemäß Guideline werden keine Battery-Readings berechnet, d.h. du bekommst kein batteryState mehr, sondern nur batteryPct. Das alte battery behalte ich aus Kompatibilitätsgründen. batteryState kannst du (für diesen Sensor) löschen.

Den "state" habe ich auch gefixt. Wenn du nochmal kurz testen könntest?

Danke,

Oli

 

[KernSani]

Hi Oli,

soll Dir ganz liebe Grüße von meinem Rasen bestellen, der heute morgen die erwartete Menge Wasser bekommen hat.
Nochmal vielen Dank für die ultraschnelle Hilfe.

Schönes Restwochenende

mi.ke

Rein interessehalber: Wie berechnest du die notwendige Wassermenge (und die daraus abgeleitete Bewässerungszeit)?

[mi.ke]

Hi Oli,

Ich bin etwas irritiert, dass du zuvor keine zwei readings hattest. Ich habe die Änderungen eigentlich basierend auf der letzten SVN Version gemacht...

Auf diesem System waren die TRX.* Dateien vom 28.12.2018.

Ich muss auf meinem Hauptsystem sogar TRX.* von 2016 bzw. die 46_TRX_SECURITY sogar von 2015.
Auch auf den RFXtrx muss ich leider unterschiedliche Firmware nutzen, da sonst einige Geschichten einfach nicht funktionieren.
Ich bin zwar dabei, diese historischen Relike zu beseitigen, aber...
 ...naja, der WAF.

Gemäß Guideline werden keine Battery-Readings berechnet, d.h. du bekommst kein batteryState mehr, sondern nur batteryPct.

Nun gut, ich hätte das niemals so entschieden
Sinn macht meines Erachten nach nur...

Code: [Auswählen]

batteryState: ok
batteryPercent: 100oder

Code: [Auswählen]

battery: ok 100%aber egal, diese Diskussion ist jetzt eh zu spät 

Das alte battery behalte ich aus Kompatibilitätsgründen.

Sehr gute Entscheidung.

Den "state" habe ich auch gefixt. Wenn du nochmal kurz testen könntest?

"state" funktioniert.
Aber "batteryPct" ist nur zweistellig, also wird aus 100 --> 10
Wenn Du da nochmal schauen könntest?

LG
mi.ke

[mi.ke]

Rein interessehalber: Wie berechnest du die notwendige Wassermenge (und die daraus abgeleitete Bewässerungszeit)?

Oje, daran hab ich lange gebastelt.

Das System errechnet anhand verschiedener Werte die Verdunstung des Rasens pro qm.
Dann wird geschaut, wieviel Regen in den letzten vierzehn Tagen gefallen ist und wann.
Dazu wird die Menge an geleistete Bewässerung addiert.
Und es wird geschaut, wieviel Regenmenge in den nächsten zwei Tagen erwaretet wird und wann.
Ist das Ergebnis negativ ist dies die Menge an Wasser pro qm die fehlt.
Die Bewässerung startet Mittwochs und Sonntags morgens so, dass sie eine Stunde vor Sonnenaufgang beendet ist.

Nachdem ich fertig war mit der ganzen Rechnerei war zu sehen, dass die vorher manuelle "Pi x Daumen" Bewässerung ziehmlich nah dran war.
Also eigentlich relativ sinnlos und bestimmt nicht exakt, aber hat einen riesen Spass gemacht letztes Jahr, nachts um 3:00-4:00 Uhr drauf zu warten, ob die Anlage anspringt (und auch wieder ausgeht).

Ach ja, und es gibt einen Umschalter auf "Ansaat", falls nachgesäht wird und einen "Katzenschreck".

naja, ich bin halt kein Gärtner und seit alles läuft, freut es das Löwnzahn 

FHEM technisch  ist das Ganze in mehreren notifys, DOIFs und dummys umgesetzt.
Ich kann das gerne zur Verfügung stellen. Es gab aber auch ein Modul "springle" aus dem Contrib, dass wohl sowas ähnliches macht. Hab ich aber nicht getestet.

cheers
mi.ke

[KernSani]

"state" funktioniert.
Aber "batteryPct" ist nur zweistellig, also wird aus 100 --> 10
Wenn Du da nochmal schauen könntest?

Nu aber ;-) Und den Typo mit batteryPct statt batteryPercent habe ich auch behoben ;-)

[KernSani]

Nachdem ich fertig war mit der ganzen Rechnerei war zu sehen, dass die vorher manuelle "Pi x Daumen" Bewässerung ziehmlich nah dran war.
Also eigentlich relativ sinnlos und bestimmt nicht exakt, aber hat einen riesen Spass gemacht letztes Jahr, nachts um 3:00-4:00 Uhr drauf zu warten, ob die Anlage anspringt (und auch wieder ausgeht).

Ok, dann bleibe ich wohl bei meiner Bodenfeuchte-Messung + Regenwahrscheinlichkeit-basierten Bewässerung, ergänzt um "sieht trocken aus, ich mach mal den Rasensprenger an"

[mi.ke]

Moin Oli,

nachdem es jetzt endlich mal geregnet hat....

"state" nimmt zwar jetzt den rain_offset mit, aber zählt die gefallenen Regenmenge nicht dazu.

Da stimmt doch noch etwas nicht.
Magst Du noch mal schauen?

cheers
mi.ke