FHEM FAQ

The syntax changed, you have to modify you config file:
• logfile/modpath/pidfile/port/verbose "renamed" to "attr global xx
• change logfile to attr global logfile
• change modpath to attr global modpath
• change pidfile to attr global pidfilename
• change port to attr global port
• change verbose to attr global verbose
• savefile renamed to "attr global statefile" (not savefile)
• at/notify "renamed" to "define at/notify"
  This means you have to give a name to each of your at's or notify commands. E.g.:
  • at *07:00 set lamp on
      becomes
    define wake_me at *07:00 set lamp on
  • notify fire:on "send_sms"
      becomes
    define fire_alarm notify fire:on "send_sms"
    
  This seems to be tedious at the beginning but you get easy deletion and attribute specification for these commands.

Stop fhem.pl, delete the previous .save file and restart fhem.pl. If the problem still exists, send a bugreport.

The protocol used by the FS20 family is quite simple: it is not encrypted in any way, and there is no feedback to the sender. So if you push any buttons on a pure receiver, no radio waves will be sent out, and the FHZ1000 won't notice anything. The FHZ1000PC does not even know if somebody received its message, it simply sends it out 3 times and hopes for good luck.
To answer the question: it is not a bug :-)

If you already programmed some devices, then just start fhem.pl with one of the example configuration files, and watch the log. When activating a device (e.g. with the remote) then it will be logged as an unknown device with the housecode. Note: the verbose level must be 3 or higher. KS300 devices do not have a proper code, so you can use anything.

Note: current fhem versions accept FS20 codes in ELV notation.

The code used by ELV is in the "quaternal" (?) system plus one added to each digit, so you can even use the 4 button remote for programming. To convert, you have two choices: the program four2hex in the contrib directory, or the good old unix program bc.
• From quaternal (ELV Remote) to hex (fhem.pl):
  

  	 % bc
  	 obase=16
  	 ibase=4
  	 <elv number>

  where <elv number> is the number used on the remote, but 1 substracted from every digit (so each digit is between 0 and 3).
• From hex (fhem.pl) to quaternal (ELV Remote):
  

           % bc
  	 ibase=16
  	 obase=4
  	 <hex number>

  Now add 1 to each digit of the result, and prepend it with 1's if it has less than 4 digits.

The FHT80b's are talking to a single FHZ1XXX device, which has a unique "FHTcode". You have two choices: if you know the old FHTcode, then you can set it, or you can tell the FHT80b to forget the old FHZ, and start talking with the new one.
• Set the FHTcode: The problem with this method is that I don't know how to read out the value, we just can change it with
  set FHZ FHTcode <hex-code>
• Resync the FHT80b: Press PROG until "Sond" appears, then select "CEnt" with the wheel, press PROG again, Select "nA" with the wheel, press PROG again.

The manual talks about 0.3l resolution, but I wanted to calibrate my device. So I filled a plastic bottle with 0.5 liter water from the measuring cup, drilled a small hole in the bottom of the bottle, let the water flow slowly in the KS300 rain-cup, and looked at the counter after the bottle was empty.
The raincounter was incremented by 130 ticks. The diameter of my KS300 rain-cup is 13.9 cm, the area ca 151.75 cm², which is ca 1/65.9 m². The 0.5 liter corresponds to 32.95 liter per m². 130 ticks correspond to 32.95 l/m2 -> 1 tick is ca 253 ml. I estimate the error margin to +/- 2%
You are welcome to do your own experiments, I am interested in the results.

Please take a look at the holiday device, and the perl helper variables (both described in the commandref.html).

The FS20STR is an FS20 device, even if it looks like an FHT80b. You'll get "only" on-for-timer and off-for-timer events sent.

Convert the first 2 digits first from decimal to hex, then the next two. Example:


         % bc
	 obase=16
	 <first two digits>
	 <last two digits>

E.g The FHT8b code 1121 is 0b15 for the fhem.pl

Look for the geographic coordinates of your home, e.g with a GPS receiver or with googleearth. Compute the latitude/longitude as needed, and enter them in your lastinclude file with the command:

{sunrise_coord("", "", "") }

After restart, { sunrise() } will return the time of the next sunrise, in a HH:MM:SS format.

Note: 99_SUNRISE_EL.pm is the ExtraLight version of the original 99_SUNRISE.pm, which needs the DateTime::Event::Sunrise perl module, which in turn is usually difficult to install. If you still want to use the original module, then the initialization string will be slightly different:

{sunrise_coord("", "", "Europe/Berlin") }

To get used to the methods, we do it step by step. Telnet to fhem, and type the following:

  # Check simply the value. It is the same as seen in "list"
  FHZ> {$value{myfht}}
  measured-temp: 23.8 (Celsius)

  # Get the second word, so we can compare it.
  FHZ> { my @a = split(" ", $value{myfht});; $a[1] }
  23.8

  # Set the ventilator on now, if its too hot.
  FHZ> { my @a = split(" ", $value{myfht});; fhem("set ventilator on") if($a[1] > 25.0) }

  # Now do this regularly
  FHZ> define chilldown at +*00:30:00 { my @a = split(" ", $value{myfht});; fhem("set ventilator on") if($a[1] > 25.0) }

  # An alternative:
  FHZ> define chilldown at +*00:30:00 { fhem("set ventilator on") if($value{myfht} gt "measured-temp: 25.0") }
  

Just define a new (pseudo) FS20 device called "window" and use the following notify settings:

  define window_open notify bad.*warnings.*Window.*open.* set window on
  define window_close notify bad.*warnings.*none.* set window off
  

(Thanks for Martin Fischer for researching)
The problem happens if at the weekly lime-protection time (usually saturday at 11:00 AM) the desired temperature is lower than the measured temperature. I think this is an FHT80b firmware bug, a workaround is to set the desired temperature for a short time higher than the measured temperature. You can automate it with the following notify:

  define lime_reset notify .*lime-protection {\
    $d = $defs{@}{READINGS}{"desired-temp"}{VAL};;\
    $m = $defs{@}{READINGS}{"measured-temp"}{VAL};;\
    if($m gt $d) {\
      fhem("set @ desired-temp 29");;\
      fhem("set @ desired-temp $d");;\
    }\
  }

Several fhem users are plagued by spontaneous disconnects/reconnects of USB devices. This is not an issue of fhem but a problem of hardware and/or USB drivers. See USB compendium for help.