outside temperature sensor

Begonnen von HarryT, 14 Februar 2013, 21:22:55

Vorheriges Thema - Nächstes Thema

HarryT

Hi

With RFXMGR I see an outside temperature sensor which I would like to use, but in FHEM it is not recognized. What can I do to make it available? What info should I provide?

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Do, 14 Februar 2013 21:22Hi

With RFXMGR I see an outside temperature sensor which I would like to use, but in FHEM it is not recognized. What can I do to make it available? What info should I provide?

{HT}
Please look into fhem.log for messages of unkown sensors (TRX_ELSE or TRX_WEATHER). If there are such messages, please post them.
On the other hand you may post me the hexcodes of the outside temperature sensor of RFXmngr.

Regards

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

HarryT

Hi

In the log I can't finf any info. In rfxmgr I see:
------------------------------------------------
08500A01CB03000860
Packettype    = TEMP
subtype       = TEMP10 - TFA 30.3133
Sequence nbr  = 1
ID            = 51971
Temperature   = 0,8 °C
Signal level  = 6
Battery       = Low
------------------------------------------------

You need more/other info?

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

HarryT

Don't ask me why but know it is in my logging too:

2013.02.14 22:08:58 1: UNDEFINED TRX_UNKNOWN_ec TRX_ELSE ec
2013.02.14 22:08:58 3: TRX_ELSE: TRX_ELSE Unknown device TRX_UNKNOWN_ec, please define it
2013.02.14 22:08:58 2: autocreate: define TRX_UNKNOWN_ec TRX_ELSE ec
2013.02.14 22:08:58 3: No I/O device found for TRX_UNKNOWN_ec
2013.02.14 22:08:58 2: autocreate: define FileLog_TRX_UNKNOWN_ec FileLog ./log/%Y-%m-TRX_UNKNOWN_ec.log TRX_UNKNOWN_ec
2013.02.14 22:08:59 1: UNDEFINED TRX_UNKNOWN_00 TRX_ELSE 00
2013.02.14 22:08:59 3: TRX_ELSE: TRX_ELSE Unknown device TRX_UNKNOWN_00, please define it
2013.02.14 22:08:59 2: autocreate: define TRX_UNKNOWN_00 TRX_ELSE 00
2013.02.14 22:08:59 3: No I/O device found for TRX_UNKNOWN_00
2013.02.14 22:08:59 2: autocreate: define FileLog_TRX_UNKNOWN_00 FileLog ./log/%Y-%m-TRX_UNKNOWN_00.log TRX_UNKNOWN_00
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Do, 14 Februar 2013 22:07Hi

In the log I can't finf any info. In rfxmgr I see:
------------------------------------------------
08500A01CB03000860
Packettype    = TEMP
subtype       = TEMP10 - TFA 30.3133
Sequence nbr  = 1
ID            = 51971
Temperature   = 0,8 °C
Signal level  = 6
Battery       = Low

{HT}

This is strange.

Autocreate should generate a device named TFA_303133_03 (03 is the id).

Are you sure that you use a fhem version newer than Nov 7th 2012? These temp sensors were added to FHEM by me at this time.

Regards

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

Willi

Zitat von: HarryT schrieb am Do, 14 Februar 2013 22:12Don't ask me why but know it is in my logging too:

2013.02.14 22:08:58 1: UNDEFINED TRX_UNKNOWN_ec TRX_ELSE ec
2013.02.14 22:08:58 3: TRX_ELSE: TRX_ELSE Unknown device TRX_UNKNOWN_ec, please define it
2013.02.14 22:08:58 2: autocreate: define TRX_UNKNOWN_ec TRX_ELSE ec
2013.02.14 22:08:58 3: No I/O device found for TRX_UNKNOWN_ec
2013.02.14 22:08:58 2: autocreate: define FileLog_TRX_UNKNOWN_ec FileLog ./log/%Y-%m-TRX_UNKNOWN_ec.log TRX_UNKNOWN_ec
2013.02.14 22:08:59 1: UNDEFINED TRX_UNKNOWN_00 TRX_ELSE 00
2013.02.14 22:08:59 3: TRX_ELSE: TRX_ELSE Unknown device TRX_UNKNOWN_00, please define it
2013.02.14 22:08:59 2: autocreate: define TRX_UNKNOWN_00 TRX_ELSE 00
2013.02.14 22:08:59 3: No I/O device found for TRX_UNKNOWN_00
2013.02.14 22:08:59 2: autocreate: define FileLog_TRX_UNKNOWN_00 FileLog ./log/%Y-%m-TRX_UNKNOWN_00.log TRX_UNKNOWN_00

Are you using a RFXCOM RFXtrx433?

These messages are very strange. There should be no type 00 messages there. Also type ec messages (not defined according the RFXtrx SDK).
 
What is the content of the following files:
- TRX_UNKNOWN_00-2013.log
and
- TRX_UNKNOWN_ec-2013.log

Which firmware of RFXtrx433 are you using? What is the FHEM version you are using?

- Please tell me the line with "TRX: Init status" from fhem-2013-02.log:

Example:
2013.02.01 13:49:21 1: TRX: Init status: '433.92MHz transceiver, firmware=62, protocols enabled: LaCrosse OREGON AC X10 '

- Please tell me the line with "Server started" from fhem-2013-02.log:

Example:

2013.02.16 20:24:23 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2405 2013-01-03 12:50:16Z rudolfkoenig $,
 pid 25003)

Regards

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

HarryT


>Are you using a RFXCOM RFXtrx433?

Yes

>These messages are very strange. There should be no type 00 messages there. Also type ec >messages (not defined according the RFXtrx SDK).
>
>What is the content of the following files:
>- TRX_UNKNOWN_00-2013.log
>and
>- TRX_UNKNOWN_ec-2013.log

In the fhem log I have
2013.02.15 19:56:48 3: No I/O device found for TRX_UNKNOWN_ec
2013.02.15 19:56:48 3: No I/O device found for TRX_UNKNOWN_00
Both log files are empty. But I cleared my log yesterday so it might be that there was something in  it before.

>Which firmware of RFXtrx433 are you using? What is the FHEM version you are using?

Firmware version 63. Fhem 5.3 development updated on 2013-02-03

>- Please tell me the line with "TRX: Init status" from fhem-2013-02.log:

2013.02.15 23:00:27 1: TRX: Init OK
2013.02.15 23:00:27 1: TRX: Init status: '433.92MHz transceiver, firmware=63, protocols enabled: LaCrosse Hideki Visonic OREGON HOMEEASY AC X10 '
2013.02.15 23:00:27 3: No I/O device found for TRX_UNKNOWN_ec
2013.02.15 23:00:27 3: No I/O device found for TRX_UNKNOWN_00

Which is strange as I use the PT2262 pir sensor with the raw format. I don´t see them in the protocols.

>- Please tell me the line with "Server started" from fhem-2013-02.log:

2013.02.14 23:01:02 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2653 2013-02-06 18:19:59Z rudolfkoenig $, pid 31017)
2

I hope this helps

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Sa, 16 Februar 2013 21:37>- TRX_UNKNOWN_00-2013.log
>and
>- TRX_UNKNOWN_ec-2013.log

In the fhem log I have
2013.02.15 19:56:48 3: No I/O device found for TRX_UNKNOWN_ec
2013.02.15 19:56:48 3: No I/O device found for TRX_UNKNOWN_00
Both log files are empty. But I cleared my log yesterday so it might be that there was something in  it before.
{HT}

Just ignore the "No I/O device found for" messages.

Looks like TRX_ELSE does no longer work to generate events on newer FHEM versions. This results in empty Logs. This worked last year. Very strange.

I have to test what has changed there.
As I am a a business trip beginning with tomorrow until end of next week I will not have time to look into this.

Until then, please look into FHEMs Webinterface for on the tabs TRX_WEATHER if there is a device named TFA_303133_03. Also look on the tabs TRX_ELSE for the values of TRX_UNKNOWN_ec and TRX_UNKNOWN_00.

Regards

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

HarryT

[quote title=Willi schrieb am So, 17 Februar 2013 00:15]
Zitat von: HarryT schrieb am Sa, 16 Februar 2013 21:37Just ignore the "No I/O device found for" messages.

Ok
ZitatLooks like TRX_ELSE does no longer work to generate events on newer FHEM versions. This results in empty Logs. This worked last year. Very strange.

I have to test what has changed there.
As I am a a business trip beginning with tomorrow until end of next week I will not have time to look into this.
Ok I am not in a hurry.
ZitatUntil then, please look into FHEMs Webinterface for on the tabs TRX_WEATHER if there is a device named TFA_303133_03.

There is no TRX_WEATHER and also no TFA*
ZitatAlso look on the tabs TRX_ELSE for the values of TRX_UNKNOWN_ec and TRX_UNKNOWN_00.

I am afraid I don't understand what you ask me. The state is ???  is that the info you need?
ZitatRegardsm afraid

Willi

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am So, 17 Februar 2013 00:26I am afraid I don't understand what you ask me. The state is ???  is that the info you need?

Ok. Thanks for the information.

The only one you could try is to disable Lighting4. It could be that this causes the problem.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

HarryT

Zitat von: Willi schrieb am So, 17 Februar 2013 00:44
Zitat von: HarryT schrieb am So, 17 Februar 2013 00:26I am afraid I don't understand what you ask me. The state is ???  is that the info you need?

Ok. Thanks for the information.

The only one you could try is to disable Lighting4. It could be that this causes the problem.

Switching Lighting4 off didn't help. RFXTRX firmware version 64 should fix a problem with the TFA sensor. So I upgraded. In RFXMNGR the TFA sensor is still visible.  But in FHEM there is still nothing, However, I don't see TRX_ELSE anymore after I deleted it from my fhem.cfg.

If I can do any testing, just send me a message.

Have a nice trip.


{HT}




FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Icebear

Hi .. seems thats the same as my place :) enable the hideki/UPM Protokoll on rfxtrx and click SAVE .. the you should c tfa sensors ...

when it dont help say a bit. I can send you then a screenshot of my config of rfxtrx.

And as Tip. Dont enable all in RFXTRX. you got strange things in FHem :) Enable only what you need (and perhaps like I do, what you would receive) like the oregon Weather ( I have none of it but some neighbours :))

And when you Enable/Disable Protokols click SAVE Settings (only then the Receive/Send COnfig is saved into the RFXTRX. Else it wont and you have the Default Config !! (The Click on Set is only temporary ...)

So when you click so set you c everything fine in the software of the rfxtrx but when you get it work with fhem it would be resetted and now you have the defaults ..  


I Actual send/receive IT, HomeEasy, TFA, Oregon Scientifyc with my configuration.

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)

HarryT

Zitat von: Icebear schrieb am So, 17 Februar 2013 23:15Hi .. seems thats the same as my place :) enable the hideki/UPM Protokoll on rfxtrx and click SAVE .. the you should c tfa sensors ...
I already had hideki/UPM enabled. And I see the sensor in rfxmngr but not in FHEM.  
Zitatwhen it dont help say a bit. I can send you then a screenshot of my config of rfxtrx.
I think the problem is more in FHEM. Do you have the developer version of FHEM and the latest rfxtrx firmware?  If so and the sensors works in your installation, maybe you can send me the define for this sensor.
ZitatAnd as Tip. Dont enable all in RFXTRX. you got strange things in FHem :) Enable only what you need (and perhaps like I do, what you would receive) like the oregon Weather
I know. But I test them in RFXmngr so at least the receiver is ok. If the fhem drivers are not 100 % correct I think we better report it so this can me improved.
Zitat( I have none of it but some neighbours :))
The same here for the FTA sensor
ZitatAnd when you Enable/Disable Protokols click SAVE Settings (only then the Receive/Send COnfig is saved into the RFXTRX. Else it wont and you have the Default Config !! (The Click on Set is only temporary ...)

So when you click so set you c everything fine in the software of the rfxtrx but when you get it work with fhem it would be resetted and now you have the defaults ..  
I know. Found this out the hard way before :-)
Zitat{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Icebear

Hi Define of some sensors (ALL Ones working for me!)

Only the TFA is my one...

Please no comments i know theres my logs are not fine defined :)) <fg> When i have many time i must restucture all.
But i have all in several includes to have some work easyer (this one is the Sensors.inc) :))

#Sensoren
define THGR132N_1 TRX_WEATHER THGR132N_1
attr THGR132N_1 room Wetter
define FileLog_THGR132N_1 FileLog ./log/THGR132N_1-%Y.log THGR132N_1
attr FileLog_THGR132N_1 logtype text
attr FileLog_THGR132N_1 room zzFilelogs

define TX3 TRX_WEATHER TX3
attr TX3 alias Aussenfühler
attr TX3 room Wetter
define FileLog_TX3 FileLog ./log/TX3-%Y.log TX3
attr FileLog_TX3 logtype temp4hum4:Temp/Hum,text
attr FileLog_TX3 room zzFilelogs
define weblink_TX3 weblink fileplot FileLog_TX3:temp4hum4:CURRENT
attr weblink_TX3 label "TX3 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_TX3 room zz_Alle_Weblinks

define THR128_1 TRX_WEATHER THR128_1
attr THR128_1 room Wetter
define FileLog_THR128_1 FileLog ./log/THR128_1-%Y.log THR128_1
attr FileLog_THR128_1 logtype temp4:Temp,text
attr FileLog_THR128_1 room zzFilelogs
define weblink_THR128_1 weblink fileplot FileLog_THR128_1:temp4:CURRENT
attr weblink_THR128_1 label "THR128_1 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_THR128_1 room zz_Alle_Weblinks

###this one is mine .. channel 5 TFA 30.3150
define Ice_TFA_Sensor1 TRX_WEATHER TFATS34C_14
attr Ice_TFA_Sensor1 room Wohnzimmer,Wetter
define FileLog_Ice_TFA_Sensor1 FileLog ./log/Ice_TFA_Sensor1-%Y.log Ice_TFA_Sensor1
attr FileLog_Ice_TFA_Sensor1 logtype temp4hum4:Temp/Hum,text
attr FileLog_Ice_TFA_Sensor1 room zzNewDevice
define Ice_TFA_Sensor1_Weblink weblink fileplot FileLog_Ice_TFA_Sensor1:temp4hum4:CURRENT
attr Ice_TFA_Sensor1_Weblink label "Aussensensor Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr Ice_TFA_Sensor1_Weblink room zz_Alle_Weblinks,Wohnzimmer
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)

HarryT

Zitat von: Icebear schrieb am Mo, 18 Februar 2013 16:26Hi Define of some sensors (ALL Ones working for me!)


Thanks for the info. I tried everything I could imagine:
- disable all protocols which I don´t minimal need
- define the sensor manually with your info and the correct sensor identifier out of 46-weather

The resul is the same. I see the sensor in rfxmngr but nog in FHEM. So I think I better wait if Willi has an idea how to solve this.

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Mi, 20 Februar 2013 23:25So I think I better wait if Willi has an idea how to solve this.

{HT}
Hi,

I am back from my business trip....
Here we go.

Please modify 46_TRX_WEATHER.pm in line 958 to uncomment it:
Old is:
    #Log 1, "TRX_WEATHER: parsing sensor_id=$sensor_id message='$hexline'";
New should be:
    Log 1, "TRX_WEATHER: parsing sensor_id=$sensor_id message='$hexline'";

and also line 443
 #Log 1,"dev_str=$dev_str";
to
 Log 1,"dev_str=$dev_str";

Please do a "reload 46_TRX_WEATHER.pm" after this or restart FHEM.

If RFXtrx send the sensor we should see a message beginning with hex "08500A" in the log:
TRX_WEATHER: parsing sensor_id=50 message=''08500A......
dev_str=TFA_303133.....

Please tell me the exact output of these and I will look into this.

If none of these is in the log we have to debug the whole strings that RFXTRX433 sends.
In this case please modify line 375 of 45_TRX.pm from
#Log 1, "TRX_Dispatch '$rmsg'";
to
Log 1, "TRX_Dispatch '$rmsg'";

and send me the output that contains the string 08500A (which is the sensor we are looking for).

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

HarryT

Zitat von: Willi schrieb am Sa, 23 Februar 2013 14:14

ZitatPlease modify 46_TRX_WEATHER.pm in line 958 to uncomment it:
Old is:
    #Log 1, "TRX_WEATHER: parsing sensor_id=$sensor_id message='$hexline'";
New should be:
    Log 1, "TRX_WEATHER: parsing sensor_id=$sensor_id message='$hexline'";

and also line 443
 #Log 1,"dev_str=$dev_str";
to
 Log 1,"dev_str=$dev_str";

Please do a "reload 46_TRX_WEATHER.pm" after this or restart FHEM.

If RFXtrx send the sensor we should see a message beginning with hex "08500A" in the log:
TRX_WEATHER: parsing sensor_id=50 message=''08500A......
dev_str=TFA_303133.....

Unfortunately I didn't get such a message.
ZitatIf none of these is in the log we have to debug the whole strings that RFXTRX433 sends.
In this case please modify line 375 of 45_TRX.pm from
#Log 1, "TRX_Dispatch '$rmsg'";
to
Log 1, "TRX_Dispatch '$rmsg'";

and send me the output that contains the string 08500A (which is the sensor we are looking for).

A got in 5 hours lots of TRX_Dispatch message but none with 08500A.

I checked again with rfxmgr and than I still see the whether sensor. So it is still sending messages. In rfxmngr is see the code 08500A01CB03800E50 for this sensor.

Can I check anything else?

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Sa, 23 Februar 2013 21:10A got in 5 hours lots of TRX_Dispatch message but none with 08500A.

I checked again with rfxmgr and than I still see the whether sensor. So it is still sending messages. In rfxmngr is see the code 08500A01CB03800E50 for this sensor.

Can I check anything else?

{HT}
This is really strange. The modification in 45_TRX.pm shows all messages received by RFXtrx433.

Currently my code does just the normal initialisation without modifying any protocols.

Are you sure that RFXmngr is receiving the 08500A without changing the protocols?
Or do you change the protocols? If yes, please write this settings to RFXtrx433 permanently.

What operating system/hardware are you using for RFXtrx433 and FHEM?

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

HarryT

ZitatThis is really strange. The modification in 45_TRX.pm shows all messages received by RFXtrx433.

Currently my code does just the normal initialisation without modifying any protocols.

Are you sure that RFXmngr is receiving the 08500A without changing the protocols?
Or do you change the protocols? If yes, please write this settings to RFXtrx433 permanently.

This was which came to my mind too yesterday I checked it again. As far as I understand I did this correct. See the line from my logfile. (btw lighning 4 is NOT reported but IS enabled.)  
2013.02.23 15:54:14 1: TRX: Init status: '433.92MHz transceiver, firmware=64, protocols enabled: Hideki AC '

ZitatWhat operating system/hardware are you using for RFXtrx433 and FHEM?

Fritzbox 7390 with international firmware, developer version of FHEM and a bit older version of Freetz. rfxmngr is running op MSWindows7 so I have to plug the rfxtrx module in my laptop before I can use rfxmngr.

Any ideas?

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

HarryT

I now have only the Hideki protocol enabled.

Nothing appears in my fhem.log yet. :-(

So it seems FHEM is not receiving it at all and there is no interference with another protocol. (Or the 7390 is the problem but that sounds even stranger)

The only thing I can imagine is installing fhem on my netbook with mswindows 7 and look what happens there. Would that be helpfull?

Ideas??

{HT}

FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am So, 24 Februar 2013 17:03I now have only the Hideki protocol enabled.

Nothing appears in my fhem.log yet. :-(

So it seems FHEM is not receiving it at all and there is no interference with another protocol. (Or the 7390 is the problem but that sounds even stranger)


Fritzbox 7390 is ok. I have also running a 7390 with a RFXtrx433 with my drivers without any problems.
Using Windows does not change it.

If you use RFXtrx433 with just hideci enables and attach the RFXtrx433 to Windows using RFXmngr without changing protocols, do you see the sensor?

Are you sure that you did not change any protocols in RFXmngr after you saved this permanently?

If not it could be that the documentation is just not correct and the TFA sensor belongs to another protocol like oregon.

If RFXtrx433 receives with Hideci only try the following:
- In RFXmngr:
* Change to Hideci only
* save protocol permanently in RFXmngr
* detach RFXtrx433 from USB and attch it again
* Look if the sensor is displayed oin RFXmngr without changing any protocols in RFXmngr
* If yes, attach it to your 7390
* On FHEM uncomment the follwing lines in 45_TRX.pm (remove the leading #):


339     #my $hexline = unpack('H*', $TRX_data);
340     #Log 1, "TRX: TRX_Read '$hexline'";

349       #my $hexline = unpack('H*', $rmsg);
350       #Log 1, "TRX_Read rmsg '$hexline'";

352       #$hexline = unpack('H*', $TRX_data);
353       #Log 1, "TRX_Read TRX_data '$hexline'";

358     #Log 1, "TRX_Read END";

* change line 303
from
                   Log 4, "TRX: Init status hexline='$hexline'";
to
                   Log 1, "TRX: Init status hexline='$hexline'";


* restart FHEM or do a "reload 45_TRX.pm"

* Send me the output of fhem.log

This way we will see any bytes transfered,

Regards

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

Willi

Zitat von: HarryT schrieb am So, 24 Februar 2013 14:53See the line from my logfile. (btw lighning 4 is NOT reported but IS enabled.)  
When I wrote the driver. Lighting4 did not exist. I have now added all missing protocols to be displayed on 45_TRX.pm. This will not change anything on the normal behaviour. It will just print the init string correct.

It is now in SVN and will be available via update tomorrow.

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

HarryT



ZitatFritzbox 7390 is ok. I have also running a 7390 with a RFXtrx433 with my drivers without any problems.
Using Windows does not change it.

I didn't get it to work on MSWindows, but on Ubuntu. And surprise it sees the sensor. The logging:
2013.02.24 21:34:53 1: TRX_Dispatch '08500a00cb03000040'
2013.02.24 21:34:53 1: TRX_WEATHER: parsing sensor_id=50 message='08500a00cb03000040'
2013.02.24 21:34:53 1: dev_str=TFA_303133_3

ZitatIf you use RFXtrx433 with just hideci enables and attach the RFXtrx433 to Windows using RFXmngr without changing protocols, do you see the sensor?

Yes

ZitatAre you sure that you did not change any protocols in RFXmngr after you saved this permanently?

100%

ZitatIf not it could be that the documentation is just not correct and the TFA sensor belongs to another protocol like oregon.

I see it on Ubuntu now without using rfxmngr. After that connecting the module to my Fritzbox and the sensor isn't seen anymore.

ZitatIf RFXtrx433 receives with Hideci only try the following:
- In RFXmngr:
* Change to Hideci only
* save protocol permanently in RFXmngr
* detach RFXtrx433 from USB and attch it again
* Look if the sensor is displayed oin RFXmngr without changing any protocols in RFXmngr
* If yes, attach it to your 7390


This far I did it already. I send the logging from the part below within an hour.


{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

HarryT

ZitatThis far I did it already. I send the logging from the part below within an hour.


So far nothing in the logging. I had to switch the other protocols on again for the night. I leave the debug patches in the code so I can see tomorrow what happened during a longer period.

A possibility is that the sensor can't be seen from the spot where the fritzbox is located. This is very unlikely but I can't rule it out yet. I think I tested this before, but not 100 % sure so I will test it again.

It somehow looks as if the sensor is not always available. It has a low battery so it might sometimes disappear. However this would not gave an answer to the question why I see it often on frxmngr but it is never seen on my fritzbox (or not recognized)

{HT}


FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am So, 24 Februar 2013 23:24A possibility is that the sensor can't be seen from the spot where the fritzbox is located.
This could be the reason for all of this.

Please try to place the sensor near to the RFXtrx433 for the test.
If this works you may try to adjust the RFXtrx433 antenna tilt. You may put something under the case of the RFXtrx433 to adjust the tilt.

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

Willi

RFXCOM has mentioned that it could be also that the Fritzbox produces RF noise that intercepts receiving the messages from your sensor. Not unlikely as the Fritzbox sends DECT and WiFi.

You can try using a 5 meter USB cable with ferrit at the Fritzbox side.
If you find out that placement is a problem you could also use RFXtrx443 on a Raspberry Pi. FHEM runs very well on a Pi (faster than on a Fritzbox).

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

HarryT

Unfortunately I haven't seen the sensor since last sunday. So I have to wait till my neighboor replaces the battery or turns it on again before I can do any test.

So nothing to report on this issue yet.

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Di, 26 Februar 2013 23:46Unfortunately I haven't seen the sensor since last sunday. So I have to wait till my neighboor replaces the battery or turns it on again before I can do any test.

So nothing to report on this issue yet.

{HT}
Hmm.It is not your Sensor?? Did you ever tell me before?
This makes it very likely hat this just a range and an antenna placement problem. Just place antenna exactly at the same position as with your Windows system. Every change counts.
Seems to be no issue at all.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

HarryT

Zitat von: Willi schrieb am Mi, 27 Februar 2013 06:07Hmm.It is not your Sensor?? Did you ever tell me before?

Yes I mentioned it, but at that time I was thinking in the direction of a FHEM bug. So it was not a high profile remark.

ZitatThis makes it very likely hat this just a range and an antenna placement problem. Just place antenna exactly at the same position as with your Windows system. Every change counts.

At the moment I don't get any reading with MSWindows either. Before the sensor had battery low and a level of 4 for the reading. This was about 3 meter from the fritzbox and a very thin wall between. If I remember correct I even measured a level 5  1 meter away from the fritzbox without a wall between. I also had a reading upstairs just above the fritzbox.

But the RFXCom remark could be a good hint too as I had problems with my own sensor before I ruined it. When I took the rfxtrx out of the hall cupboard I got readings with that sensor.  

I aspect to see the TFA sensor back in a while and will test this stuff.

ZitatSeems to be no issue at all.

Indeed I don't believe in a software bug anymore.

BTW what is the define for the rfxtrx device in a MSWindows environment? I didn't find it yet.

{HT}

FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

HarryT

Hi

My neighbor has replaced the battery and the TFA sensor is back. I now can confirm that the FHEM and RFXTRX software works correct. The issue is indeed the place of the RFXTRX sensor and it seems the used unpowered usb hub. It now works.

The RF signals of the Fritzbox seems not the be a problem as the problem persists as I switch WLAN and DECT off.

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.