FHT80b only gives actuator %

[pendul]

This is my first post here, but I am a happy user of FHEM and I really like the software, but at the moment I have got a problem with both of my FHT80b`s

Both FHT80b`s worked well, but today I saw that one of the two stopped transmitting information except for the actuator percentage.

I tried to fix this by removing the FHT80b from FHEM and add it again (by turning on autocreate), but no result.

In a desperate attempt I also removed the second FHT80b and add it again, but this time also this FHT80B stopt working (apart from sending actuator percentage) . So now I have two non-working FHT80B`s ....Any thoughts?

My setup is CUL running on a raspberry pi

What have I tried myself:

Downgrade FHEM to 5.4
upgrade FHEM to current SVN status
Installed FHEM (SVN-version) on my main computer
Changed the house-code of the CUL device
Removed the batteries from the FHT80B
Paired both FHT80B again
set frequency cul to 868,35 mhz (set CUL_0 freq 868.35)

Thanks!

Pendul

[Klaus Rubik]

Hello Pendul,

usually this behavour has nothing to do with your CUL or your FHEM configuration. From my experience, this is purely the behavior of the FHTs. What you can do:

• sit and wait 
• set <FHT name> time
• check and correct the time at your FHT
• check the logfile for errors

First bullet pout was serious, usually the FHT starts sending the messages again after some time.

kind regards

Klaus

[UliM]

Hi,
if your FHT keeps sending "unknown_xx" then check this:
https://groups.google.com/forum/#!msg/fhem-users/aft8E1LrsDE/8D-TsMrYY5wJ
or this:
http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT

With my FHT, resetting the buffer worked also:
enter "set CUL raw T01xxxx" - with xxxx = FHT-ID

Good luck,
Uli

[pendul]

Thanks for all the info!

After some tweaking yesterday evening both FHT80`s are working again. I guess the solution was a mix of things you both proposed.

First I changed the batteries (although they were not that old, I have got the feeling it might have contributed to the overall solution), after that I resetted the buffer (thanks for that UliM!).

And then I took a coffee and waited quite long; but after 20-30 minutes both FHT80`s started working again. Now I know the FHT80 is quite a lazy device and it can take upto 15 minutes or more before the device will transmit information like measured temperature, so yeah Klaus you tip was useful .

greetz,

Pendul

[Prof. Dr. Peter Henning]

Very well known problem - and unsolved. Workaround: Add a timer to fhem, which once per day (say, at 4:00 in the morning) sets the current time of the FHT, and the problem will not occur again.

define WK.FHT_wup at *04:00 set WK.FHT time

Regards

pah

[borsti67]

The last post was more than a month ago?

Anyway I'd like to add that I formerly used this daily "wakeup-code", but for me it made the problem worse! Even FHTs which didn't fail before started to stop reporting temperatures afterwards.
So I decided to add individual watchdogs which are only triggered when necessary:

Code Auswählen Erweitern

define wd_az_FHT watchdog az_FHT:measured-temp.* 02:00 SAME set az_FHT time