outside temperature sensor

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

Vorheriges Thema - Nächstes Thema

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.