Hi,
Recently, I've embedded my last two radiators into the FHT system. I allready had 4 FHT8B/radiators connected to my FHEM.
Since adding the two new FHT's, some of the previously working FHT's stopped reporting temprature.
I never bothered to chage the code of the FHT's, just used them them out of the box.
I've tried the following;
-added a 'define fht_sync at +*3:30 set TYPE=FHT time'
-send set CUL_0 raw T011034
-replace the batteries of the faulting module.
-turn off the two new FHT's, everything starts working again...
-change the 'code' for one of the new FHT devices. This enabled me to have 5 FHT's report, but this stoped working after 8 hours.
My questions;
-I've read that transmitting frequency depends on the 'code', so what would be the best 'code' setup, that would result in proper communication;
FHT1 0101
FHT2 0102
FHT3 0103
FHT4 0104
FHT5 0105
FHT6 0106 ?
-My CUL is defined with a random 'house code', just something I picked. Does this have to match the 'code' of the FHT's?
-One one of the new FHT80b it was just not possible to turn on the 'CenT' to 'On', only after chaging the code... How come?
Thanks!
_____________________________________________________________________________________
Background info;
Im running on a Raspberry pi;
Fhem info:
Release : 5.4
Branch : DEVELOPMENT
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.14.2
Defined modules:
CUL : 1
CUL_FHTTK : 5
FHEMWEB : 7
FHT : 6
FS20 : 18
FileLog : 18
MSG : 1
MSGMail : 1
SVG : 11
Twilight : 1
WOL : 1
at : 1
autocreate : 1
dummy : 1
notify : 7
structure : 2
telnet : 1
Defined models per module:
CUL_FHTTK : FHT80TF
FHT : fht80b
FS20 : fs20rst,fs20su,fs20tfk,fs20tk
I found answer to my own question, according to this; http://fhz4linux.info/tiki-index.php?page=FHT+protocol (//fhz4linux.info/tiki-index.php?page=FHT+protocol)
The 3 least significant bits of housecode 2 determine the communication sending frequency;
My house codes are;
HC2Hex Bin 3lsb
FHT1 04 100
FHT2 20 000
FHT3 45 101
FHT4 3e 110
FHT5 33 011
FHT6 09 001
There are 8 possible interval, so luckely I had my house codes with all unique intervals... And my assumtion was right, an ideal interval with 6 FHT's can be reached using a house-code plan as in my first post...
On the down site, this does not explain why I'm not able to have more than 4 workings FHT's in my FHEM setup...
Busy translating; http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT (//www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT)
MMmzz,
My FHT's are allways in manual mode. So no week/day planning.
I'm gonna try to put all 6 FHT just right next to my reciever. See if communication goes well then...
I've also put on lazy mode on all my FHT's...
I've thrown out all batteries, replaced them with brand new duracels, and put them all withing 30 centimeter of my recieving Raspi.
Changed all the room codes accourding to this scema;
FHT1 0101
FHT2 0202
FHT3 0303
FHT4 0404
FHT5 0505
FHT6 0606
And whole system 'collapsed'. During this situation, no communication was possible with none of the FHT's. They probally all started talking to each other.
So does anyone here has a setup with more then 4 FHT's?
I've heard of setups with up to 18 FHTs, but I think that such a setup will only work with more than one CUL reliable. I think the limit for one CUL is at about 10 FHT80b. The FHT communication is very fragile and in my opinion the protocol is braindead. Btw.: 30cm is quite short and may not work, the signal beeing too strong.
I'd really like to find out from people with more than 4 CUL's, what the house code's are for all the FHT's...
Really have the feeling that the mix of code's in the FHT's are messing up things...
Also, I've put my FHT's in 'Sond', 'CeNT', 'On'.
But accourding to this; http://www.fhemwiki.de/wiki/FHT80b (//www.fhemwiki.de/wiki/FHT80b) I should put them in 'Sond', 'CeNT', 'n/A', and then send a command to the FHT...
I do have about 9 FHTs.
Lets first talk about terminology here.
- There ist only ONE FHT-ID per Radio interface. Every CUL has exact one FHT-ID
- this FHT-ID was often called "houscode" in the past, which lead to some confusion with the FS20 housecode which has a totally different meaning. So we avoid the term "housecode" when talking abouth FHTs.
- this FHT-ID is send to the FHT during pairing, there is no way to change that in a FHT itself
- each FHT has its own address. This address is confgured in the FHT manually and must be unique. Its form in the FHT is XX XX where XX ranges from 00-99
- unfortuntaly Fhem stores these FHT adresses in HEX, so FHT address 22-44 is shown as 162c in Fhem.
Okay. So now some random answers and comments to your questions:
ZitatReally have the feeling that the mix of code\'s in the FHT\'s are messing up things...
What does "mix of code's" mean? The FHT-ID must be the same to all FHTs paired to the same CUL. The FHT addresses must be all different. After changing the addresses the FHTs must be paired again of course.
ZitatAlso, I\'ve put my FHT\'s in \'Sond\', \'CeNT\', \'On\'.
which means, that the currently stored pairing data in the FHT is used. If this is not up to date e.g. because you changed address or FHT-ID, then this will not work.
ZitatBut accourding to this; http://www.fhemwiki.de/wiki/FHT80b I should put them in \'Sond\', \'CeNT\', \'n/A\', and then send a command to the FHT...
Yep, Thats what you need to do to pair an FHT after changing address or CUL or FHT-ID. The pairing is triggerd by (any) sent command after the FHT is on "n/A". The pairing was succesfull if "n/A" changes to "ON".
So basically you NEVER change "CeNT" to "ON" yourself, you always change it to "n/A" for pairing and just check, if CeNT switched to "ON" to check fpr pairing success.
So please first do that with all your FHTs and report back and we'll see.
As a general rule of thumb: If communication with a FHTs is not working, then unsuccessfull pairing is the most common reason. In doubt: pair again.
As Rudolf mentioned, there is a certain limit, to my opinion more then 8 FHTs do not work reliable when paired to one CUL, I use an RFR for some.
Regarding the " sending frequency" thing: You can totally ignore that. The FHTs are communicating as far as I remember all 115+x (x = 0.5sec * Low-Nibble of the FHT-ID). As the FHT-ID off all your FHTs is the same, there is no way to balance that somehow. This feature is not meant to separate FHT communications from each other. There is also no need to do that. (it is meant to avoid that retry-intervalls of 2 separate installations - such as 2 neighbors using FHTs - are the same)
HI,
when this is actual .. i have 7 FHTs running properly :)
greets