TRX Weather BUG ?!

Begonnen von Icebear, 04 Juni 2013, 20:24:50

Vorheriges Thema - Nächstes Thema

Icebear

Moinsen,

es gibt offensichtlich einen Bug beim Auswerten der TS34C.

Ich habe heute den zweiten dazu bekommen und beide werden als identischer sensor erkannt.

Einer auf ID2 einer auf ID5 (im RFXManager auch so angezeigt) aber in FHem wird der neue erkannt als der bestandssensor der schon laenger laeuft :((

Irgendeine Idee?

Gruss Icebear
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

An den namenlosen anonymen Eisbär,

da ich TRX_WEATHER verbrochen habe und mir gerne anschaue, ob es ein Bug oder ein Feature ist ;-)

Poste die Hex-Strings, die RFXmngr bei der jeweiligen ID empfängt und an anzeigt.
Ich schau mir dann an wie bei Deinem Sensor die ID aufgebaut ist und ändere es in TRX_WEATHER.

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

Icebear

Hi Willi,

hier der Auszug aus dem TRX Manager.


BTW: Der gibt auch einen Signal Level an. Bekommst du den auch rein ?
Und die ID, könnte das die LongId bei den TX3 sein?



------------------------------------------------
0A5207014B0E00F32D0179
Packettype    = TEMP_HUM
subtype       = TH7 - Cresta, TFA TS34C
                channel 2
Sequence nbr  = 1
ID            = 19214
Temperature   = 24,3 °C
Humidity      = 45
Status        = Comfortable
Signal level  = 7
Battery       = OK


------------------------------------------------
0A520701D20E0112280169
Packettype    = TEMP_HUM
subtype       = TH7 - Cresta, TFA TS34C
                channel 5
Sequence nbr  = 1
ID            = 53774
Temperature   = 27,4 °C
Humidity      = 40
Status        = Comfortable
Signal level  = 6
Battery       = OK


huch was fang ich denn da noch auf .. ne idee ??

07.06.2013 08:52:34= 090304032682D9C65C50
Packettype        = UNDECODED RF Message
UNDECODED LACROSSE:2682D9C65C50
------------------------------------------------


und noch einer :)

------------------------------------------------
07.06.2013 08:55:40= 06030104090000
Packettype        = UNDECODED RF Message
UNDECODED ARC:090000



------------------------------------------------
07.06.2013 08:56:06= 060301040B00C0
Packettype        = UNDECODED RF Message
UNDECODED ARC:0B00C0

So danke für die Tollen Module. Wie hören uns..

Grüsse aus dem schönen Wesel

Icebear.

Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

Danke für die Infos. Probier mal folgende Version von 46_TRX_WEATHER aus.
Sofern longids nicht gesetzt wird, wird jetzt die ID gemäß der Konventionen gesetzt, die auch bei RFXmngr gelten. Ansonsten (also mit longids) werden die kompletten ID-Hexstrings genutzt.

Bzgl. UNDECODED messages: Im SDK steht, dass diese nur für "internal use" sind.
Es sind vermutlich Geräte, die RFXCOM noch nicht kennt.

Du könntest versuchen eine neuere Firmware zu installieren sowie eine neuere Version von RFXmngr und austesten, ob diese Geräte dann erkannt werden. Aktuell ist Firmware 67. Undecoded würde ich in RFXmngr ausschalten und abspeichern.

Ansonsten hilft nur:
- Gerät finden und identifizieren
- Reverse engineering, um herauszufinden was die Bits/Bytes bedeuten.

Oder Du fragst mal RFXCOM. Die werden aber auch wissen wollen, was für Geräte das sind bzw. sein können.....

Grüße

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

Icebear

Hi Willi,

also das neue TRX_Weather läuft und die devices werden sauber angelegt mit der ID, könnte also eingechecked werden (falls noch nicht geschehen)

Bekommst den Signal Level auch noch irgendwie mit rein ?

Gruss Icebear aus Wesel
(nu der verheiratete Icebear) <g>
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

Ok. Wir sollten noch mal ein paar Tage testen. Ich werde es noch auf meinen übrigen Systemen nachziehen.
Danach checke ich es ein.

Was willst Du mit dem Signallevel anfangen? Der geht nur von 0 bis 15 und ist vermutlich nicht sehr aussagekräftig. Ich füge es zur Wunschliste hinzu. Die Prio setze ich abhängig davon wie viele weitere User es benötigen, implementiere ich es optional schaltbar per Attribut.

Grüße

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

Icebear

Alles klar.

btw. lt. Sourcecode hast du z.b. für Windgeschwindigkeit TFA Sensoren vorgesehen.

Hast du da zufällig auch genauere bezeichnungen?

Der Signallevel ist eigentlich auch nur interessant, wenn man sich am Randbereich des Senders befindet. (also level < 2 = schlecht, wäre dann zu testen obs ausfällt gibt) ist dann ähnlich den FS20 (schlechter als -85 DB gibt ausfälle) oder meinste nicht ..

Ne allgemeine Frage hätte ich da noch. Wäre es theoretisch auch möglich TFA zu senden? (man könnte dann z.b. ne Wetterstation zum Display für was auch immer umfunktionieren). Nur ne Idee..

Grüsse aus Wesel
Icebear
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)

Willi

>btw. lt. Sourcecode hast du z.b. für Windgeschwindigkeit TFA Sensoren vorgesehen.
Welche Geräte RFXtrx433 kann, steht unter http://www.rfxcom.com/oregon.htm .
Der Link zu TFA ist dabei: http://www.rfxcom.com/oregon.htm#TFA

Es geht vermutlich der Windsensor der TFA_Nexus. Siehe Link
Frag mal culfritzbox . Dieser setzt eine TFA-Nexus ein.

>Wäre es theoretisch auch möglich TFA zu senden?
Schau mal unter http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf .
Bei TFA ist ein Kreuz bei "receive", aber keines bei "transmit". Man kann also TFA nicht senden.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Markus M.

Signallevel +1 ;)

Das wäre eine schöne Möglichkeit, Problemstellen in der Wohnung zu finden bzw. die perfekte Antennenposition herauszufinden.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

Willi

Habe soeben eine neue Version der RFXtrx433-Module eingecheckt mit dem RSSI-Logging für TRX_WEATHER und TRX_SECURITY-Devices. Man setzt dazu das Attribut rssi beim TRX-Device. Also beispielsweise:

attr TRX_0 rssi 1


Das gilt dann für alle RFXtrx433 (falls man mehrere hat) und alle Devices.

Das Ergebnis sieht dann wie folgt im Filelog aus:

2013-06-15_21:10:43 BTHR918N_60 temperature: 23.3
2013-06-15_21:10:43 BTHR918N_60 humidity: 51
2013-06-15_21:10:43 BTHR918N_60 pressure: 1003
2013-06-15_21:10:43 BTHR918N_60 forecast: rain
2013-06-15_21:10:43 BTHR918N_60 battery: ok
2013-06-15_21:10:43 BTHR918N_60 rssi: 6
2013-06-15_21:10:43 BTHR918N_60 T: 23.3 H: 51 P: 1003 D: 12.6 BAT: ok


Wer es nutzen will, morgen per update oder heute direkt aus dem SVN holen.
Bei letzterem müssen folgende Module ausgetauscht werden: 45_TRX.pm 46_TRX_WEATHER.pm 46_TRX_SECURITY.pm 46_TRX_ELSE.pm

Es ist noch nicht für TRX_LIGHT realisiert.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Icebear

Moin,

danke sehr..

grüsse aus dem schönen wesel
icebear
Raspberry PI mod B (Wheezy), Fhem 5.4, CUL868, CUL433 , RfxTrx, HM-USB-CFG2, Wlan, HomeEasy, IT, FS20, TFA, HomeMatic, Oregon Scientific, HMLand auf Fritzbox
Raspberry PI mod B (RaspBMC)