Gelöst! RFXCOM Modul 41_OREGON.pm Regenrate?

Begonnen von Billy, 05 April 2014, 19:01:36

Vorheriges Thema - Nächstes Thema

Billy

Hallo ich hoffe ich bin hier richtig.

Habe heute mal meinen alten RFXCOM USB 433 Mhz RF receiver (order code 80002)
in Bertrieb genommen und meine Oregon Sensoren BTHR918N; RGR918; THGR918; in FHEM eingebunden!

Das hat super geklappt! :)

Was ich im Modul 41_OREGON.pm vermisse sind die Funktionen
      event-on-change-reading; event-on-update-reading und event-min-interval

Ich würde gerne die Loghäufigkeit einschränken.

Hat da jemand eine Idee?

Gruß Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Willi

Hallo,

ich habe damals (2010) die alten RFXCOM geschrieben. Da es den Receiver schon seit sehr langem nicht mehr zu kaufen gibt und dieser durch den RFXtrx433-Transceiver abgelöst wurde, habe ich seit 2012 keine Weiterentwicklungen gemacht.

Wenn es offensichtliche Probleme gibt, kann ich mir diese ansehen, aber ich baue keine neuen Features mehr ein.

Wenn Du möchtest, kannst Du gerne event-on-change-reading, etc. einbauen und der Community bereitstellen.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Billy

Danke Willi für die Antwort.
Ich hatte schon fast vermutet dass es da keine neuen features geben wird.
ZitatWenn Du möchtest, kannst Du gerne event-on-change-reading, etc. einbauen und der Community bereitstellen.
Bin mir noch nicht ganz sicher wie ich das für mich löse.
Da ich beim jetzigen Standort Reichweitenprobleme habe, gibt es evtl sowieso eine Fhem2Fhem Lösung.

Gruß Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Willi

ZitatWird die augenblickliche RR im Modul 41_OREGON.pm errechnet aus den flips ? oder kommt die vom Sensor?

Falls sie vom Sensor kommt wäre mein RGR918 defekt?
Die Rainrate bzw. Niederschlagsrate wird vom Sensor übertragen.

Bei meinem RGR918 wird folgendes derzeit angezeigt:

list RGR918

Internals:
   CODE       RGR918
   DEF        RGR918
   IODev      ds3
   LASTInputDev TRX_0
   MSGCNT     14765
   NAME       RGR918
   NR         42
   STATE      RR: 0 TR: 3201.4 BAT: ok
   TRX_0_MSGCNT 14765
   TRX_0_TIME 2014-04-20 17:39:53
   TYPE       TRX_WEATHER
   Readings:
     2014-04-20 17:39:53   battery         ok 100%
     2014-04-20 17:39:53   rain_rate       0
     2014-04-20 17:39:53   rain_total      3201.4
     2014-04-20 17:39:53   rssi            7
     2014-04-20 17:39:53   state           RR: 0 TR: 3201.4 BAT: ok


On Dein Sensor defekt ist, würde ich mit der originalen Basisstation von Oregon gegenchecken.
Evtl. hast Du je einen anderen Typ des Sensors, der die Rainrate nicht richtig unterstützt.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Billy

Danke Willi für deine Antwort.
ZitatDie Rainrate bzw. Niederschlagsrate wird vom Sensor übertragen.

Das stimmt, habe ich inzwischen auch festgestellt.
Oregon schreibt dazu:
Wenn der Niederschlagssensor zwei aufeinanderfolgende Stunden lang keinen Niederschlag feststellt,
wird die aktuelle Niederschlagsrate mit Null angezeigt.


Mein Sensor ist also nicht defekt. :) --> Thema gelöst.


Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Billy

Zitat von: Willi am 06 April 2014, 00:39:48
Hallo,

ich habe damals (2010) die alten RFXCOM geschrieben. Da es den Receiver schon seit sehr langem nicht mehr zu kaufen gibt und dieser durch den RFXtrx433-Transceiver abgelöst wurde, habe ich seit 2012 keine Weiterentwicklungen gemacht.
Wenn es offensichtliche Probleme gibt, kann ich mir diese ansehen, aber ich baue keine neuen Features mehr ein.
Wenn Du möchtest, kannst Du gerne event-on-change-reading, etc. einbauen und der Community bereitstellen.

Grüße

Willi

Hallo Willi das war mir doch zu lästig ich habe in Anlage 41_OREGON.pm
event-min-interval und event-on-change-reading
eingebaut. Läuft bei mir seit Tagen problemlos.
Stelle es hiermit wie von dir vorgeschlagen der Community zur Verfügung.
Gruß Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Willi

Hallo Billy,

danke. Die Änderungen habe ich mir soeben angesehen. Sieht gut aus. Es fehlt nur die Doku für commandref (die hast Du gelöscht).

Probiere ich mal aus.

Wenn sonst jemand das testet und Feedback meldet, wäre toll.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Billy

Zitat von: Willi am 31 August 2014, 20:45:48
Hallo Billy,

danke. Die Änderungen habe ich mir soeben angesehen. Sieht gut aus. Es fehlt nur die Doku für commandref (die hast Du gelöscht).

Probiere ich mal aus.

Wenn sonst jemand das testet und Feedback meldet, wäre toll.

Grüße

Willi

Hallo Willy mir fiel heute nach einem update auf, dass immer nochj die "alte"  41_OREGON.pm
ohne event-min-interval und event-on-change-reading eingecheckt ist. Hat meine Version überschrieben! :(

Die funktioniert übrigens problemlos.

Gruß Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*