Bezugnehmend auf diesen Thread
http://forum.fhem.de/index.php/topic,19988.0.html
schlage ich diesen Patch vor.
--- edit: Patch entfernt, da fehlerhaft. Weiterentwicklung im Laufe dieses Threads. ---
Die Doku ist noch nicht für das zusätzliche Reading angepasst und die im Thread gestellte Frage bzgl der stateFormat Aktualisierung ist auch noch offen.
stateFormat ist (wie du in dem Thread auch schreibst) Teil von readingFnAttributes, und 13_KS300.pm wird mit diesem Patch weder richtig noch vollstaendig auf readings*Update umgestellt. Ein bisschen umstellen mache ich nicht mit, weil ich dann bei der ersten (berechtigten) Fehlermeldung die Arbeit am Hals habe.
Die Umrechnung mit "$w ~~ [10..59|" schaut zwar elegant aus, erzeugt aber ein Feld mit 50 Elementen, und sucht dann $ w in diese Feld, indem es durchiteriert, ist also deutlich ineffizienter als ein Vergleich. Mit einem altmodischen Vergleich & Doku wuerde ich den Patch nehmen.
Uebrigens liefert ein KS300 laut Doku Werte nur bis 99,9, insofern ist Windstaerke 11 und 12 nur fuer die Code-Leser relevant.
Mich wuerde in diesem Zusammenhang deutlich mehr interessieren, wie man den Windmesser eicht.
Hallo Rudi,
die Sache mit dem stateFormat ist - wie erwartet - schon schiefgegangen (siehe den Wunschthread), das werde ich wieder rausnehmen.
Die Sache mit dem Vergleich kann ich gerne umbauen und die Windstärken 11 und 12 auskommentieren :).
Danke für Deine Hinweise, ich melde mich hier wieder.
Viele Grüße
Udo
Hallo Rudi, betateilchen
ZitatUebrigens liefert ein KS300 laut Doku Werte nur bis 99,9, insofern ist Windstaerke 11 und 12 nur fuer die Code-Leser relevant.
Mich wuerde in diesem Zusammenhang deutlich mehr interessieren, wie man den Windmesser eicht.
Wenn ich das richtig auf Seite 7 lese können schon Geschwindigkeiten bis 200 km/h gemessen werden.
http://www.elv-downloads.de/service/manuals/KS300/65390_um.pdf (http://www.elv-downloads.de/service/manuals/KS300/65390_um.pdf)
Oder eine Annahme ist total falsch, was gut möglich ist
Fein, dann warten wir hier mal in Startposition bis es eine neue Version zum Testen gibt. Jedenfalls ist das prima, wenn dieser Modul auch auf das stateFormat umgestellt wird.
Das Eichen des Windmessers ist mMn weniger das Problem, als ein Wetterwarten adäquater Aufstellungsort des K300. Solange das Ding irgendwo zwischen Haus und Nachbargarage steht (funktechnisch optimal) und nicht auf freiem Feld liefert das eh nur Relativwerte.
Zitatkönnen schon Geschwindigkeiten bis 200 km/h gemessen werden.
Bei mir stand noch 99.9 in der Anleitung drin. Ich glaube sowohl das als auch das 200 ist irgendetwas, was die Marketing-Leute erfunden haben. Auch deswegen wuerde ich gerne eichen...nein, kalibrieren ist das richtige Wort.
ZitatJedenfalls ist das prima, wenn dieser Modul auch auf das stateFormat umgestellt wird.
Das hat hier keiner behauptet...
Bei mir empfange ich einen Windmesser eines Nachbarn. Wenn man die Werte betrachtet, lierfert der m/s und nicht km/h.
grnpf... was denn nun? 99.9 oder 200? Ich werde einfach die komplette Liste bis 12 drinlassen.
@Rudi: um auf readingsFnAttr umzustellen, müsste man
- alle $def->{READINGS} (im Coding also $r) auf readings...Update() umstellen
- die Zeilen mit CHANGED alle entfernen
Richtig? Ich frage das, weil diese Logik noch aus meiner "vor-fhem-Developer-Zeit" stammt und ich mich mit dem alten Mechanismus nie beschäftigt habe.
Und an der Doku muss ich gar nix wichtiges ändern, da sind nämlich gar keine Readings beschrieben 8)
Zitat von: stromer-12 am 16 Februar 2014, 11:41:24
Bei mir empfange ich einen Windmesser eines Nachbarn. Wenn man die Werte betrachtet, lierfert der m/s und nicht km/h.
Und wenn Du im define den windfaktor angibst, kannst Du km/h bekommen, siehe commandref. 8)
Zitat von: betateilchen am 16 Februar 2014, 11:48:21
Und wenn Du im define den windfaktor angibst, kannst Du km/h bekommen, siehe commandref. 8)
Den Windfaktor habe ich irgendwie überlesen, Danke für den Tipp.
Here we go again...
Alle interessierten Tester mögen bitte diesen Post bis zum Ende lesen!
Zitat von: rudolfkoenig am 16 Februar 2014, 10:23:52Ein bisschen umstellen mache ich nicht mit, weil ich dann bei der ersten (berechtigten) Fehlermeldung die Arbeit am Hals habe.
Verlangt auch niemand von Dir. Ich habe Dir die Umstellung komplett abgenommen 8)
Zitat von: rudolfkoenig am 16 Februar 2014, 10:23:52Mit einem altmodischen Vergleich & Doku wuerde ich den Patch nehmen.
Geändert.
Zitat von: rudolfkoenig am 16 Februar 2014, 10:23:52Uebrigens liefert ein KS300 laut Doku Werte nur bis 99,9, insofern ist Windstaerke 11 und 12 nur fuer die Code-Leser relevant.
Aufgrund der hier aufgekommenen Diskussion habe ich die komplette Zuordnungstabelle bis bft 12 beibehalten.
Zitat von: rudolfkoenig am 16 Februar 2014, 10:23:52Mich wuerde in diesem Zusammenhang deutlich mehr interessieren, wie man den Windmesser eicht.
Da kann ich Dir leider nicht weiterhelfen, da ich den Sensor weder selbst besitze noch ihn kenne. Und in meiner Balkonwohnlage würde der auch keinen Sinn machen.
Wichtig für alle Tester!
- In der angehängten Version gab es viele Änderungen zur Einbindung des Moduls in fhem (Umstellung auf readings..Update).
- An der Berechnung der angezeigten Werte wurde grundsätzlich nichts verändert, die zugrundeliegenden Werte mussten allerdings auf ReadingsVal() umgestellt werden und ich hoffe, dass ich dabei keinen Fehler gemacht habe.
- stateFormat sollte damit jetzt auch funktionieren.
Bitte macht Euch einen Screenshot Eurer Readings VOR DEM Update und vergleicht nach dem Modulupdate alle Werte auf Plausibilität!
sorry, im LOG steht:
2014.02.16 14:29:51 1: readingsUpdate(CUL_0,tsecs,1392557391) missed to call readingsBeginUpdate first.
2014.02.16 14:29:51 1: readingsUpdate(CUL_0,rain_raw_adj,939) missed to call readingsBeginUpdate first.
2014.02.16 14:32:23 1: readingsUpdate(CUL_0,tsecs,1392557543) missed to call readingsBeginUpdate first.
2014.02.16 14:32:23 1: readingsUpdate(CUL_0,rain_raw_adj,939) missed to call readingsBeginUpdate first.
2014.02.16 14:34:56 1: readingsUpdate(CUL_0,tsecs,1392557696) missed to call readingsBeginUpdate first.
2014.02.16 14:34:56 1: readingsUpdate(CUL_0,rain_raw_adj,939) missed to call readingsBeginUpdate first.
2014.02.16 14:37:28 1: readingsUpdate(CUL_0,tsecs,1392557848) missed to call readingsBeginUpdate first.
2014.02.16 14:37:28 1: readingsUpdate(CUL_0,rain_raw_adj,939) missed to call readingsBeginUpdate first
und im state defined, sonst passiert nichts
Dafür brauchst DU Dich doch nicht entschuldigen. Ich kann das Modul hier mangels Sensor nur auf syntaktische Fehler testen.
War mein Fehler, das readingsBeginUpdate stand an der falschen Stelle ;)
Teste bitte nochmal.
irgendwie leitet es state auf CUL_0 um - im KS300 steht:
Zitat
[/q][/t]
CUL_0_RAWMSG |
K1794000600AB6305 |
CUL_0_RSSI |
-71.5 |
CUL_0_TIME |
2014-02-16 15:23:16 |
|
1234 |
| |
IODev |
CUL_0 (http://192.168.2.56:8083/fhem?detail=CUL_0) |
LASTInputDev |
CUL_0 (http://192.168.2.56:8083/fhem?detail=CUL_0) |
Readings
avg_day |
T: 7.0 H: 73 W: 0.7 R: 0.0 |
2014-02-16 14:17:08 |
[/t]
avg_month |
T: 3.6 H: 42 W: 39.8 R: 5.3 |
2014-02-16 00:03:05 |
cum_day |
2014-02-16 00:03:05 T: 356412.7 H: 3776741 W: 35773.2 R: 239.4 |
2014-02-16 14:17:08 |
cum_month |
15 T: 54.4 H: 633 W: 597.5 R: 5.3 |
2014-02-16 00:03:05 |
humidity |
60 |
2014-02-16 14:17:08 |
israining |
no |
2014-02-16 14:17:08 |
rain |
239.4 |
2014-02-16 14:17:08 |
rain_raw |
939 |
2014-02-16 14:17:08 |
rain_raw_adj |
939 |
2014-02-16 14:17:08 |
state |
defined |
2014-02-16 15:19:35 |
temperature |
9.7 |
2014-02-16 14:17:08 |
tsecs |
1392556628 |
2014-02-16 14:17:08 |
type_raw |
7 |
2014-02-16 14:17:08 |
unknown1 |
2 |
2014-02-16 14:17:08 |
unknown3 |
1 |
2014-02-16 14:17:08 |
wind |
2.7 |
2014-02-16 14:17:08 |
windIndex |
1 |
2014-02-16 14:17:08 |
und im CUL_0
CMDS
BCFiAZEGMRTVWXefmltux
CUL_0_MSGCNT
43
CUL_0_TIME
2014-02-16 15:29:39
Clients
:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_RFR:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:
DEF
/dev/ttyACM_CUL@9600 1034
DeviceName
/dev/ttyACM_CUL@9600
FD
11
FHTID
1034
NAME
CUL_0
NR
22
PARTIAL
RAWMSG
T7C99688224
RSSI
-56
STATE
T: 9.4 H: 60 W: 0.0 R: 239.4 IR: no Wi: 0
TYPE
CUL
VERSION
V 1.55 CUL868
initString
X21
Readings
avg_day
T: 7.1 H: 72 W: 0.6 R: 0.0
2014-02-16 15:23:16
cmds
B C F i A Z E G M R T V W X e f m l t u x
2014-02-16 15:19:29
cum_day
2014-02-16 00:03:05 T: 393711.9 H: 4014821 W: 35773.2 R: 239.4
2014-02-16 15:23:16
humidity
60
2014-02-16 15:23:16
israining
no
2014-02-16 15:23:16
rain
239.4
2014-02-16 15:23:16
rain_raw
939
2014-02-16 15:23:16
rain_raw_adj
939
2014-02-16 15:23:16
raw
is0F00F0FFFFFF
2014-01-25 16:16:03
state
T: 9.4 H: 60 W: 0.0 R: 239.4 IR: no Wi: 0
2014-02-16 15:29:39
temperature
9.4
2014-02-16 15:23:16
tsecs
1392560596
2014-02-16 15:23:16
type_raw
7
2014-02-16 15:23:16
unknown1
6
2014-02-16 15:23:16
unknown3
1
2014-02-16 15:23:16
wind
0.0
2014-02-16 15:23:16
windIndex
0
2014-02-16 15:23:16
das heißt, alle anderen Readings - außer state - funktionieren jetzt?
Doofe Frage, sorry. Sie funktionieren natürlich nicht. Ich hatte nicht weit genug runtergescrollt.
nein leider nicht, d.h. das sich die Werte des KS300 im reading und state vom CUL_0 wiederfinden - alles beim KS300 bleibt auf dem Stand von vor 2 Versionen.
jetzt geht es, Werte werden aktualisiert, stateFormat schreibt wie gewünscht! Nur noch eine (hoffentlich) Kleinigkeit: in den readings bleibt state auf defined. Damit schreibt FileLog keine Werte...
Hatte ich vorhin testweise auskommentiert und dann vergessen. Jetzt aber...
perfekt! Danke! Jetzt geht es wie gewünscht!
Na prima.
@Rudi: auf eine diff-Datei verzichte ich aufgrund der umfangreichen Änderungen in der ParseFn. Nimm einfach die Moduldatei aus dem vorletzten Beitrag zur Begutachtung und ggf. zum Einchecken.
Stunden später, es funktioniert immer noch perfekt - > bitte einchecken und der breiten Masse damit zugänglich machen.
Danke an die (Weiter-)Entwickler!
tatsächlich wissen wir das erst in 13 Tagen, wenn sowohl ein Tages- als auch ein Monatswechsel stattgefunden hat 8) Aber ich bin da recht zuversichtlich.
Aus Kompatibilitätsgründen sollte man den Modulautor von 98_rain.pm darum bitten, sein Modul auch auf readings..Update() umzustellen, wenn er in der attrList schon die readingsFnAttributes einbindet.
Habe KS300.pm eingecheckt, musste die Datei aber vorher anpassen:
- die fuer die Berechnung verwendeten readings sollten kein Event verursachen
- avg_day sollte nur einmal am Tag und avg_month nur einmal im Monat geschrieben werden (statt mit jedem Reading bzw einmal am Tag). Da ich "mutig" war, und das Modul ohne Aenderung bei mir ausprobiert habe, hat das erstmal mein Log zerschossen. Nach der Anpassung scheint es zu funktionieren, und ich bekomme wieder 10 Grad gemeldet statt 2014.
Danke fürs Einchecken.
Wie schon beschrieben - mangels Sensor konnte ich das nicht funktional selbst testen, sondern nur syntaktisch.
Da waren solche notwendigen "Feinarbeiten" nicht auszuschließen.
Moin rudolfkoenig, betateilchen
Erst mal vielen Dank für die viele Arbeit die Ihr mit dem Wunsch hattet.
Aber ich musste heute fest stellen das da wohl noch ein Fehler drin ist?
Version:
# $Id: 13_KS300.pm 4963 2014-02-17 13:24:29Z rudolfkoenig $
Log Eintrag, hier fehlt der windIndex.
2014-02-23_13:03:32 Wittingen dewpoint: 2.2
2014-02-23_13:03:32 Wittingen israining: no
2014-02-23_13:03:32 Wittingen temperature: 9.1
2014-02-23_13:03:32 Wittingen humidity: 62
2014-02-23_13:03:32 Wittingen wind: 4.1
2014-02-23_13:03:32 Wittingen rain: 989.7
2014-02-23_13:03:32 Wittingen T: 9.1 H: 62 W: 4.1 R: 989.7 IR: no Wi: 1
--------------------------------------------------------------------------------------------------
Edit: Nach dem neusten Update fehlt das Reading "windIndex"
Habe ich nur dieses Problem?
Fehlt nur das Reading selbst oder ist "Wi:" auch in state nicht vorhanden?
Kannst Du mal bitte die Zeile 116 der aktuellen Modulversion ändern in
"israining"=>1, "windIndex"=>1);
und dann nochmal testen?
So, habe ich geändert.
Reading ist wieder da, jetzt fehlt nur noch der Wind.
Werde mich dann wieder Melden
Na, das klingt ja schonmal nicht schlecht. Und wenn dann mal wirklich wieder Werte drinstehen, brauchen wir nur noch Rudi anstupsen, damit er die Korrektur einbaut.
Zitat von: rudolfkoenig am 17 Februar 2014, 14:31:37
Habe KS300.pm eingecheckt, musste die Datei aber vorher anpassen:
...
- avg_day sollte nur einmal am Tag und avg_month nur einmal im Monat geschrieben werden (statt mit jedem Reading bzw einmal am Tag).
warum?
bisher habe ich mit avg_day, die bisher gefallene Regenmenge am Tag, dazu benutzt, meine Gartenbewässerung zu aktivieren, wenn nicht genug oder kein Regen gefallen ist, bzw. die Bewässerung abzubrechen, falls es gerade und genug geregnet hat. Das funktioniert nun nicht mehr, da mit readingVal immer der Wert vom Vortag ausgelesen wird.
Frage: Wie kann ich die bisher gefallene Regenmenge anders ermitteln, wenn sich das nicht im KS300-Modul reaktivieren lässt?
Nachtrag: Habe die gefallene Regenmenge jetzt aus der Differenz aus dem Reading rain und dem Rainwert aus cum_day ermittelt, das funktioniert nun wieder. Trotzdem die Frage an @rudolfkoenig:
Bleibt das mit der Aktualisierungsrate bei avg_day mit einmal am Tag bestehen?
ZitatWie kann ich die bisher gefallene Regenmenge anders ermitteln, wenn sich das nicht im KS300-Modul reaktivieren lässt?
Das Problem hat mich vor ein paar Tagen auch ueberrascht, aber ich habe beim Fixen nicht nachgedacht, und in dem Auswerteskript Temperatur und Regenmenge nochmal aus state und cum day berechnet. Auf die Idee, es "richtig" zu machen, kam ich leider nicht.
Ich habe es jetzt hoffentlich auch "richtig" geloest: avg_day wird tagsueber auf dem aktuellen Stand gehalten, ein Event wird aber erst nach Tageswechsel generiert. Das gleiche passiert uebrigens auch mit avg_month, allerdings nur einmal am Tag.
Na supi, dann mach ich mal ein Update ;)
Zitat von: betateilchen am 26 Februar 2014, 09:50:34
Fehlt nur das Reading selbst oder ist "Wi:" auch in state nicht vorhanden?
Kannst Du mal bitte die Zeile 116 der aktuellen Modulversion ändern in
"israining"=>1, "windIndex"=>1);
und dann nochmal testen?
Das fehlt in der aktuellen 13_KS300.pm um das Event für das Reading zu erzeugen.
Zitat von: stromer-12 am 10 Mai 2014, 21:45:14
Das fehlt in der aktuellen 13_KS300.pm um das Event für das Reading zu erzeugen.
Hier der Patch dazu. :)
Fehlt gar nicht, ich will nicht mehr Events haben, insb. nicht solche, die ins Museum gehoeren.
Notfalls kann man mit stateFormat oder userReadings und KS300_windIndex dieses Wert als Event haben.
Wusste nicht das es schon antik ist. :)
Dann die Alternative. Danke.
ZitatWusste nicht das es schon antik ist.
Hast du dir die Definition mal angeschaut?
Ich finde sowas muss nicht unterstuetzt werden.