FHT80b: Unterschied zwischen den Versionen

Aus FHEMWiki
K (letzte Änderung gesichtet und geringfügig überarbeitet)
 
(50 dazwischenliegende Versionen von 15 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
= FHT80b Heizungs-Controller =
{{Infobox Hardware
Programmierbarer Raumthermostat, der bis zu 8 Stellantriebe [[FHT8v]] steuern kann.
|Bild=FHT80b.jpg
|Bildbeschreibung=FHT80b
|HWProtocol=FHT
|HWType=Empfänger
|HWCategory=FHT
|HWComm=868,35 MHz
|HWChannels=1
|HWVoltage=3 V
|HWPowerConsumption=(ca. 2 Jahre)
|HWPoweredBy=2x AA
|HWSize=100 x 60 x 60 mm
|HWDeviceFHEM=11_FHT8V.pm
|HWManufacturer=ELV / eQ-3}}
 
Der [[FHT80b]] ist ein programmierbarer Raumthermostat, der bis zu 8 Stellantriebe [[FHT8v]] steuern kann.
 
'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''{{Link2Forum|Topic=60219}}


== Features ==
== Features ==
Lokal programmierbare Tages- und Nachtemperatur, die pro Tag mit 4 Schaltpunkten programmiert werden kann.
Lokal programmierbare Tages- und Nachttemperatur, die pro Tag mit 4 Schaltpunkten programmiert werden kann.
Zusätzliche Anbindung eines Tür/Fensterkontaktes [[FHT80TF]] zur Absenkung der Temperatur auf seperat einstellbaren Wert bei offenem Fenster (windowopen-temp).  
Zusätzliche Anbindung eines Tür/Fensterkontaktes [[FHT80TF]] zur Absenkung der Temperatur auf separat einstellbaren Wert bei offenem Fenster (windowopen-temp).  


== Readings ==
== Readings ==
Zeile 17: Zeile 33:
|-  
|-  
| battery  
| battery  
|  ok  
|  ok <br /> low
|  Ladezustand der Batterien
|  Ladezustand der Batterien
|-  
|-  
| mode         
| mode         
|  auto <br /> manu <br />
|  auto <br /> manual <br /> holiday_short <br />
|  Funktionsmodus (auto, manuell oder urlaub/party)
|  Funktionsmodus (auto, manuell oder Urlaub/Party)
|-  
|-  
| state       
| state       
Zeile 31: Zeile 47:
|  21.0   
|  21.0   
|  Solltemperatur in ° (C oder F in FHT80B wählbar)
|  Solltemperatur in ° (C oder F in FHT80B wählbar)
|-
| holiday1
|  126
|  Endzeit der Urlaubs-/Partyfunktion. Uhrzeit in Minuten seit 00:00 geteilt 10 (im Beispiel 21:00 Uhr)
|-
| holiday2
|  31
|  Tag im Monat an der die Urlaubs-/Partyfunktion endet
|-  
|-  
| lowtemp  
| lowtemp  
|  ok  
|  ok <br /> warn
|  Frostschutz??
|  Untertemperatur-Alarm: Im Raum wird der Temperatur-Sollwert nicht erreicht
|-  
|-  
| manu-temp  
| manu-temp  
Zeile 45: Zeile 69:
|-  
|-  
| warnings  
| warnings  
|  none  
|  none <br /> Battery low <br /> Temperature too low <br /> Fault on window sensor
|  Vermutung: Batterie leer ... kann das jemand verifizieren?
|  Auflistung der Fehler
|-  
|-  
| window     
| window     
Zeile 53: Zeile 77:
|-  
|-  
| windowsensor  
| windowsensor  
|  ok  
|  ok <br />  fault
| &#160;?? Kann ich nicht interpretieren, zeigt bei mir ok, obwohl ich keinen TF habe
| fault, wenn ein angemeldeter Fenstermelder nicht erreicht werden kann.
|-  
|-  
| windowopentemp  
| windowopentemp  
| &#160;??
| 9.0
|  Solltemperatur bei offenem Fenster
|  Solltemperatur bei offenem Fenster
|-  
|-  
| year <br /><p>month<br />
| year <br />
month<br />
day<br />
day<br />
hour<br />
hour<br />
minute
minute
</p>
|  
|  
|  Zeitangaben für interne Uhr
|  Zeitangaben für interne Uhr
|-  
|-  
| mon-from1 <br /><p>mon-from2 <br />
| mon-from1 <br />
mon-from2 <br />
mon-to1 <br />
mon-to1 <br />
mon-to2 <br />
mon-to2 <br />
Zeile 95: Zeile 120:
sun-to1 <br />
sun-to1 <br />
sun-to2  
sun-to2  
</p>
|  06:00  
|  06:00  
|  Angabe von Schaltzeiten im Format HH:MM
|  Angabe von Schaltzeiten im Format HH:MM
|}
|}
== Hinweise zum Betrieb mit FHEM ==
== Hinweise zum Betrieb mit FHEM ==
Vor dem Einsatz muss der FHT80b mit der Zentrale gepairt werden. Geschieht dies nicht, können nach einer Definition in FHEM zwar Daten des FHT80b empfangen werden (z.b. Raumtemperatur), es können jedoch keine Befehle gesendet werden. Zum pairen den FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, danach sofort einen Befehl (egal welchen) an die FHT80b senden. Wenn ca. 2 Minuten später Sonderfunktion cENT auf "ON" steht, war das Pairing erfolgreich.  
Vor dem Einsatz muss der FHT80b mit der Zentrale (z.B. CUL, FHZ1X00) gepairt werden. Unterbleibt dies, werden nach einer Definition in FHEM zwar Daten vom FHT80b empfangen (z.&nbsp;B. Raumtemperatur), aber es können keine Befehle gesendet werden. Zum Pairen den FHT80b in der Sonderfunktion "cENT" auf "n/a" stellen und danach einen beliebigen Befehl an ihn senden. Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht, war das Pairing erfolgreich.  
 
Weitere Hinweise: [[FHT mit RFR CUL pairen]]
Weitere Hinweise: [[FHT mit RFR CUL pairen]]


Das FHT80b akzeptiert Befehle vom FHZ1X00 (oder CUL/CUN) nur alle 115+x Sekunden (x = 0.5*letztes Byte des FHT-Hauscodes aka [[FHT-ID]], Beispiel: FHT-ID 1234, Sendeintervall = 115+0,5*4 = 117 Sekunden)
Außerdem muss für das FHT manuell oder per Autocreate ein Device in FHEM angelegt werden. Der Raumcode als Adresse des FHT wird von der FHEM Autocreate-Funktion hexadezimal dargestellt, im Gerät jedoch dezimal. Daher muss die Adresse byteweise umgerechnet werden.  Beispiel: FHEM habe ein FHT mit der Adresse 162c angelegt. Dies entspricht dann
Praktisch ergeben sich ca. 2 Minuten.
hex 16 = 22 dez
Wenn man also mit FHEM z.B. 5 desired-temp Wechsel sendet, so wird es selbst unter optimalen Bedingungen 9- 10 Minuten dauern, bis der Letzte ausgeführt wird.  
hex 2c = 44 dez
dem FHT-Raumcode von 2244.
Beim manuelle Anlegen muss der dezimale Raumcode des FHT umgekehrt byteweise in die hexadezimale FHT-Adresse umgerechnet werden.


Dies muss insbesondere beim Debuggen von Automationszenarien berücksichtig werden. Nicht absetztbare Kommandos werden im einem Puffer der FHZ1x00/CUL/CUN gespeichert, obwohl sie im FHEM Log als abgesetzt erscheinen. Bei größeren Installationen kann auch der Puffer überlaufen ([[EOB]] Fehlermeldung im FHEM Log). Die Puffer sind unterschiedlich gross. Am kleinsten ist er bei den FHZ1x00 mit ca. 40 Byte, was für ca. 8 FHT Befehle reicht. Am grössten ist er im CULv3 oder CUN mit 200 Bytes, das reicht für ca. 40 Befehle.
Der FHT80b akzeptiert Befehle von einer Zentrale nur alle 115+x Sekunden (x&nbsp;=&nbsp;0.5*letztes Byte des [[Was ist der Hauscode%3F|FHT-Hauscodes]] (auch ''FHT-ID'' genannt), Beispiel: FHT-ID 1234, Sendeintervall = 115+0,5*4 = 117 Sekunden)
Praktisch ergeben sich so ca. zwei Minuten.
Wenn man also mit FHEM z.B. desired-temp-Wechsel an fünf verschiedene FHT80b sendet, wird es selbst unter optimalen Bedingungen 9-10 Minuten dauern, bis der letzte ausgeführt wird.  


Bei zu kleinem Puffer bietet FHEM die Möglichkeit einen Softpuffer (fhtsoftbuffer) zu konfiguriert. Dies ist vermutlich bei CUL/CUN weniger sinnvoll, da die Abarbeitung der gesamte Puffergrösse sehr viel Zeit in Anspruch nehmen kann. Dies könnte dazu führen, das Kommandos an FHTs erst Stunden später ausgeführt werden.
Dies muss insbesondere beim Debuggen von Automationszenarien berücksichtigt werden. Nicht absetzbare Kommandos werden im einem Puffer der FHZ1x00/CUL/CUN gespeichert, obwohl sie im FHEM-Log als abgesetzt erscheinen. Bei größeren Installationen kann dieser Puffer überlaufen ([[EOB]] Fehlermeldung im FHEM Log). Die Puffer sind unterschiedlich groß. Am kleinsten ist er bei den FHZ1x00 mit ca. 40 Byte, was für ca. acht FHT Befehle reicht. Am größten ist er im CULv3 oder CUN mit 200 Bytes, das reicht für ca. 40 Befehle.


Bei zu kleinem Puffer bietet FHEM die Möglichkeit, einen Softpuffer (fhtsoftbuffer) zu konfigurieren (dieser wirkt jedoch nur bei FHZ1X00PC Zentralen). Insgesamt ist fhtsoftbuffer nur dann sinnvoll einsetzbar, wenn die Funklage an sich gut ist und der Puffer zügig abgearbeitet wird. Softbuffer sollte '''nicht''' eingesetzt werden, wenn die Übertragung der FHT-Befehle gestört ist, da sich dann schnell sehr lange Befehlsketten im Puffer aufbauen können, deren Abarbeitung  sehr viel Zeit in Anspruch nehmen kann. Dies kann dazu führen, dass Kommandos an FHTs erst Stunden später ausgeführt werden.


Um mehr Befehle an ein FHT80b senden zu können, können bis zu 8 Befehle zusammengefasst werden, diese belegen dann nur einen "Zeitslot"
Um mehr Befehle an ein FHT80b senden zu können, können bis zu 8 Befehle zusammengefasst werden, diese belegen dann nur einen "Zeitslot"


Beispiel:
Beispiele:
:<code>set heizung_wohn desired-temp 20.5 day-temp 19.0 night-temp 16.0</code>
 
:<code>set hzg_WC mon-from1 07:00 mon-to1 10:00 mon-from2 14:00 mon-to2 23:00</code>
 
Die Kommunikation des FHT80b mit den Stellantrieben und dem Türkontakt erfolgt ebenso in Zeitabständen von ca. zwei Minuten. In den Pausen sind die Sender und Empfänger von FHT80b und FHT8v abgeschaltet, um Batteriestrom zu sparen.


<nowiki>set heizung_wohn desired-temp 20.5 day-temp 19.0 night-temp 16.0</nowiki>
Der FHT80b übermittelt ungefähr alle 15 Minuten aktuelle Temperaturdaten an die Zentrale.


Die Kommunikation des FHT80b mit den Stellventilen und dem Türkontakt erfolgt ebenso in Zeitabständen von ca. 2 Minuten. In den Pausen sind die Sender und Empfänger von FHT80b und FHT8v abgeschaltet, um jeweils Batteriestrom zu sparen.
Die Kommunikation mit der Zentrale ist bidirektional, d.h. die Funkzentrale sendet auch Daten an die FHT80b zurück (insbesondere Acknowledge-Meldungen etc). Dies führt dazu, dass im Zusammenhang mit der Sendzeitbegrenzung die Anzahl der [[Maximal nutzbare Geräte|maximal nutzbaren Geräte]] begrenzt ist. Theoretisch lassen sich bis zu 17, in der Praxis eher nur ca. 10 FHT80b sinnvoll mit einer Zentrale steuern.


Die Übermittlung der aktuellen Tempereaturdaten an die Zentrale (FHZ, [[CUN]]) erfolgt alle 15 Minuten.
== Verschiedene Betriebsarten mit FHEM ==
Da das FHT80 selbst ein Heizprogramm speichern und daher eigentlich auch autark arbeiten kann, stellt sich die Frage, wie FHT80 am Besten in FHEM integriert werden sollte. Es gibt dazu drei wesentliche Szenarien:


Die Kommunikation mit der Zentrale ist bidirektional, d.h. die Funkzentrale sendet auch Daten an die FHT80b zurück (insbesondere Acknowledge Meldungen etc). Dies führt dazu, dass im Zusammenhang mit der [[Maximal nutzbare Geräte]] begrenzt ist. Theoretisch lassen sich maximal 17, praktisch ca. 10 FHT80bs sinnvoll mit einer Zentrale steuern.
* das FHT80 heizt nur über seine eigenen Heizprogramme, steht also im Automatik Modus. Diese werden jedoch nicht umständlich am FHT80 selber einprogrammiert sondern über FHEM gesetzt. Auch alle gewünschten Änderungen werden über eine Anpassung der im FHT gespeicherten Programme und Setzen von day-temp und night-temp realisiert. Vorteil: Volle Funktionalität auch ohne FHEM, daher ausfallsicher. Nachteil: Änderungen erzeugen hohe Funklast, da ganze Wochenprogramme übertragen werden müssen. Führt bei mehr als fünf bis sechs FHTs idR. zu [[EOB]] und [[LOVF]] Problemen. Außerdem: Beschränkung auf die FHT80 typisch geringe Zahl von Schaltpunkten (vier pro Tag), mehrstufige Temperaturänderungen sind umständlich. Abhängigkeiten in FHEM (Anwesenheitskontrolle, Bedingungen wie Nutzungserkennung durch Bewegungssensoren etc.) sind schwerer umsetzbar.
 
* das FHT80 heizt über seine eigenen Heizprogramme, steht also im Automatik Modus. Zusätzlich sendet FHEM z.B. desired-temp Meldungen und greift so in das Heizprofil ein. Vorteil: Grundfunktionalität auch ohne FHEM, daher ausfallsicher: Das Wochenprogramm des FHT80 wird als Grundprogramm und Fallback genutzt. Zusätzliche Heizpunkte oder höhere/niedrigere Temperaturen werden durch FHEM gesteuert. Geringere Funklast, sofern das Grundprogramm selten geändert wird. Beliebige Schaltpunkte, beliebige Temperaturänderungen leicht einstellbar. Nachteil: Komplex. Das Heizverhalten hängt sowohl vom lokalen Programm im FHT80 ab, als auch von Kommandos die FHEM sendet. Das macht die Steuerung  unübersichtlich. Problematisch ist insbesondere, wenn lokale Schaltpunkte kurz vorher gesendete FHEM Kommandos negieren. Dies macht z.B. das Herunterfahren der Heizung bei ungeplanter Abwesenheit schwierig.
 
* das FHT80 wird in den manuellen Mode geschaltet und nur über FHEM mittels desired-temp Kommandos gesteuert. Vorteil: Da FHEM volle Kontrolle hat, einfache Umsetzung von Abhängigkeiten (Anwesenheitskontrolle, Bedingungen wie Nutzungserkennung durch Bewegungssensoren etc.). Beliebige Schaltpunkte, beliebige Temperaturänderungen leicht einstellbar. Unkomplex: Temperatur hängt nur vom letzt-gesendeten desired-temp Kommando ab. Nachteil: Bei Ausfall von FHEM wird das FHT80 quasi funktionslos und hält nur die letzte eingestellte Temperatur. Es könnten allerdings im FHT gespeicherte Heizprogramme durch manuelles Umschalten am FHT80 auf den Automatikmodus (Tastendruck) aktiviert werden.
 
Da das FHT80 auch per FHEM-Befehl zwischen manuellem und automatischem Modus umgestellt werden kann, sind auch Mischformen speziell zwischen den letzten beiden Varianten einsetzbar. Dies wird z.B. im Code Snippet [[FHT80b Automatik setzen]] genutzt.


== Log-Auszug ==
== Log-Auszug ==
FHT80b sendet ca alle 2 Minuten Steuerbefehle an ggf. angeschlossene Ventilstelltriebe. Der einzustellende Wert liegt zwischen 0% und 100% und wird von FHT80b auf Basis der am Gerät eingestellten Solltemperatur und der vom Gerät gemessenen Ist-Temperatur berechnet:
FHT80b sendet ca. alle zwei Minuten Steuerbefehle an ggf. angeschlossene Ventilstellantriebe. Der einzustellende Wert liegt zwischen 0% und 100% und wird von FHT80b auf Basis der am Gerät eingestellten Solltemperatur und der vom Gerät gemessenen Ist-Temperatur berechnet:
 
FHT &lt;device-name&gt; actuator: 0%


<nowiki>FHT &lt;device-name&gt; actuator: 0%</nowiki>
Außerdem sendet FHT80b ca. 4 mal pro Stunde folgenden Statusbericht:
Ausserdem sendet FHT80b ca 4 mal pro Stunde folgenden Statusbericht:


  <nowiki>FHT &lt;device-name&gt; actuator: 0%
  FHT &lt;device-name&gt; actuator: 0%
FHT &lt;device-name&gt; measured-temp: 23.1 (Celsius)
FHT &lt;device-name&gt; measured-temp: 23.1 (Celsius)
FHT &lt;device-name&gt; battery: ok
FHT &lt;device-name&gt; battery: ok
FHT &lt;device-name&gt; lowtemp: ok
FHT &lt;device-name&gt; lowtemp: ok
FHT &lt;device-name&gt; window: closed
FHT &lt;device-name&gt; window: closed
FHT &lt;device-name&gt; windowsensor: ok
FHT &lt;device-name&gt; windowsensor: ok
FHT &lt;device-name&gt; warnings: none</nowiki>
FHT &lt;device-name&gt; warnings: none


Die dazu nötige bidirektionale Kommunikation kann mit FHEM  
Die dazu nötige bidirektionale Kommunikation kann mit FHEM  
Zeile 142: Zeile 186:
beispielhafter Mitschnitt:  
beispielhafter Mitschnitt:  


  <nowiki>2008-09-28 13:04:18 FHT wz actuator: 0%  
  2008-09-28 13:04:18 FHT wz actuator: 0%  
  2008-09-28 13:04:18 FHT wz actuator: 0%  
  2008-09-28 13:04:18 FHT wz actuator: 0%  
  2008-09-28 13:04:18 FHT wz start-xmit: 17  
  2008-09-28 13:04:18 FHT wz start-xmit: 17  
Zeile 157: Zeile 201:
  2008-09-28 13:04:20 FHT wz FHZ:ack: 0  
  2008-09-28 13:04:20 FHT wz FHZ:ack: 0  
  2008-09-28 13:04:20 FHT wz end-xmit: 0  
  2008-09-28 13:04:20 FHT wz end-xmit: 0  
  2008-09-28 13:04:20 FHT wz FHZ:end-xmit: 0</nowiki>
  2008-09-28 13:04:20 FHT wz FHZ:end-xmit: 0
 
Jede Zeile steht für ein Telegramm (und nicht für 3, wie beim FS20).  
Jede Zeile steht für ein Telegramm (und nicht für 3, wie beim FS20).  


FHZ:xxx Telegramme wurden von dem FHZ (oder CUN/CUL) gesendet, die anderen vom FHT.
FHZ:xxx Telegramme wurden von der FHZ (oder CUN/CUL) gesendet, die anderen vom FHT.  
 
fhem fasst measured-low und measured-high zu measured-temp zusammen, es werden also im normalen log (telnet: inform timer) 2 Zeilen weniger gemeldet.  


17 ist der Housecode des protokollierten FHZ. Wenn das FHZ nicht mit dem richtigen Housecode antwortet, dann geht die Kommunikation nicht weiter.  
FHEM fasst measured-low und measured-high zu measured-temp zusammen, es werden also im normalen log (telnet: inform timer) zwei Zeilen weniger gemeldet.  


Wenn das FHT nicht an dem FHZ angemeldet ist (d.h. das FHT hat nicht den Housecode des FHZ gespeichert), werden keine Temperaturdaten uebermittelt. Set Prog:Cent:N/A setzt den FHT Housecode auf 100, dann sollte jeder FHZ auf "start-xmit" antworten, und das FHT merkt den ersten. Noch besser dem FHT via fhem was zu senden, dann muss man nicht auf die naechste Temperaturmeldung (bis zu 15 Minuten) warten.  
17 ist der Hauscode der protokollierten FHZ. Wenn die FHZ nicht mit dem richtigen Hauscode antwortet, dann geht die Kommunikation nicht weiter.  


Mehr dazu auch hier: [[FHT mit RFR CUL pairen]]
Wenn das FHT nicht an der FHZ angemeldet ist (d.h., das FHT hat nicht den Hauscode des FHZ gespeichert), werden keine Temperaturdaten übermittelt.  Set Prog:Cent:N/A setzt den FHT Hauscode auf 100, dann sollte jede FHZ auf "start-xmit" antworten, und das FHT merkt den ersten. Noch besser ist es, dem FHT via FHEM  etwas zu senden, dann muss nicht auf die nächste Temperaturmeldung (bis zu 15 Minuten) gewartet werden.


Falls die Gegenseite nicht wie erwartet antwortet, dann wird es nach einem Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte  
Falls die Gegenseite nicht wie erwartet antwortet, wird nach einem Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte Antwort vorliegt, wird nach 115+x Sekunden der ganze Vorgang einmal wiederholt.  
Antwort vorliegt, dann wird es nach 115+x Sekunden das ganze Vorgang einmal wiederholt.  


Durch diese recht umfangreiche Kommunikation entsteht im Zusammenhang mit der [[Maximal nutzbare Geräte]] von ca. einem Dutzend Geräten.
Durch diese recht umfangreiche Kommunikation entsteht im Zusammenhang mit der Sendezeitbeschränkung die maximale Anzahl nutzbarer Geräte von ca. einem Dutzend.


== Bekannte Probleme ==
== Bekannte Probleme ==
* Die Sendefrequenz einiger FHT80b ist nicht besonders genau auf den eigentlichen Wert von 868,35 Mhz justiert und streuen bei verschiedenen Geräten. Die FHZ 1x00PC Geräte sind gegenüber leichten Abweichungen der Frequenz durch eine etwas höhere Empfangsbandbreite eher unempfindlich. Die [[CUN]] halten die eingestellte Frequenz etwas trennschärfer ein, sodass es zu Empfangsproblemen kommen kann. Können Signale eines FHT nicht empfangen werden, kann es sinnvoll sein, probeweise die Frequenz des CUL zu ändern (in 0,05 Mhz Schritten).  
* Es gibt zwei weitere, gleich aussehende Geräte mit geringerem Funktionsumfang. Der [[FHT8b]] hat keine Verbindung zu Fensterkontakten. Der [[FHT8]] hat keinen bidirektionalen Funk und  kann nicht mit einer Zentrale/FHEM verbunden werden.
* Der äußerlich gleich aussehende [[FHT8]] ist nicht mit einer Zentrale/FHEM einsetzbar.  
* Die Sendefrequenzen einiger FHT80b sind nicht besonders genau auf den eigentlichen Wert von 868,35 MHz justiert und streuen bei verschiedenen Geräten. Die FHZ 1x00PC Geräte sind gegenüber leichten Abweichungen der Frequenz durch eine etwas höhere Empfangsbandbreite eher unempfindlich. Die [[CUL]] oder [[CUNO]] halten die eingestellte Frequenz dagegen trennschärfer ein, sodass es zu Empfangsproblemen kommen kann. Können Signale eines FHT nicht empfangen werden, kann es sinnvoll sein, probeweise die Frequenz des CUL zu ändern (in 0,05 MHz Schritten), oder die Bandbreite aufzuweiten, z.B. auf 464 kHz.
* In seltenen Fällen fehlerhafte Aktuator Meldungen, siehe [[Lime-Protection Bug]]  
* In seltenen Fällen fehlerhafte Aktuator Meldungen, siehe [[Lime-Protection Bug]]  
* FHTs hören in der Regel nach 5-10 Tagen auf, von sich aus Daten zur Zentrale zu senden, wenn sonst keine Kommunikation mit dem FHT stattfindet.. Ein regelmässiges z.b. wöchenliches Stellen der Uhrzeit oder wöchentliches Abfragen der wichtigsten Parameter (report2 = 255) vorteilhaft zu eher "funklastarmen" Zeiten schafft Abhilfe; z.B.:
* FHTs hören in der Regel nach 5-10 Tagen auf, von sich aus Daten zur Zentrale zu senden, wenn sonst keine Kommunikation mit dem FHT stattfindet. Ein regelmäßiges z.B. wöchentliches Stellen der Uhrzeit oder wöchentliches Abfragen der wichtigsten Parameter (report2 = 255) vorteilhaft zu eher "funklastarmen" Zeiten schafft Abhilfe; z.B.:<br><code>define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set hzg_Zimmer1 report2 255") } }</code>
<pre>define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set hzg_Zimmer1 report2 255") } }</pre>
* Die o.g. Situation bringt häufig auch die Actuator-Meldung "'''unknown_69'''" mit sich. Eine Beschreibung zur Behebung findet sich in {{Link2Forum|Topic=6755|Message=28860|LinkText=diesem Forums-Post}}.
* Die o.g. Situation bringt häufig auch die Actuator-Meldung "'''unknown_69'''" mit sich. Eine Beschreibung zur Behebung findet sich in [https://groups.google.com/d/msg/fhem-users/aft8E1LrsDE/8D-TsMrYY5wJ diesem Forums-post] .
* Der Betrieb von FHTs mit einen [[RFR CUL]] kann zu besonderen Problemen führen, siehe [[RFR CUL und FHT80]]
* Der Betrieb von FHTs mit einen [[RFR CUL und FHT80]] führen.  
* Es kann vorkommen, dass ein oder auch alle FHT plötzlich aufhören, Temperatur und andere Werte zu senden (aber z.B. actuator und current_action weiter senden). Meist nehmen sie dann auch keine Befehle vom FHEM aus an. Das kann dann an einem '''Verbindungsproblem zur Zentrale'''/fhem liegen (Ursache unklar). Eine Lösung ist, im jeweiligen FHT in den Sondereinstellungen die Zentrale zu deaktivieren und wieder einzustellen (Prog - Sond - CEnt - na, Prog - Sond - CEnt - on). Vgl. [[Funk-Heizkörperregler_Kurz-Bedienungsanleitung_FHT|FHT-Anleitung]], {{Link2Forum|Topic= 16422|Message=155804|LinkText=Forum dazu}}
 
Weiterführende Betrachtungen hier: [[Kommunikationsprobleme mit FHT]]


== Links ==
== Links ==
* Anleitung [http://www.eq-3.de/fileadmin/pdfs/einleitungen/FHT80B-3_UM_G_091111.pdf] PDF
* [[Funk-Heizkörperregler_Kurz-Bedienungsanleitung_FHT|Kurz-Bedienungsanleitung]]
* Baugleich auch als Set ('''FHT80b''', [[FHT80TF]]) von Medion (bei Aldi oder ebay): [http://www.haushaltselektronik.de/automatische-funk-heizkoerpersteuerung-lifetec-md-12050-aldi-nord/ Lifetec MD12050]
* Anleitung [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/andere_produkte_bda/FHT80B_UM_G_080812.pdf hier (eQ-3)] oder {{DocLink|elv|/Assets/Produkte/8/856/85643/Downloads/85643_FHT80B_UM.pdf hier (ELV)}} als PDF
* Baugleich auch als Set ('''FHT80b''', [[FHT80TF]]) von Medion (bei Aldi oder ebay): [http://www.discounter-archiv.de/de/archiv/ALDI-Nord/2011-01-06/Automatische-Funk-Heizkoerpersteuerung/692135/ Lifetec MD12050]
* [[Kommunikationsprobleme mit FHT]]  
* [[Kommunikationsprobleme mit FHT]]  
=== Verweis auf Code Snippets ===
* [[Was ist der Hauscode?]]
* [[FHT-Report regelmäßig erneuern]]
 
* [[FHT: Datum und Zeit von fhem setzen lassen]]  
Eine Reihe von Code Snippets zum Thema FHT80b:
* [[FHT80b Einstellungen]]
* [[FHT80b Automatik setzen]]
* [[FHT: Datum und Zeit von FHEM  setzen lassen]]  


[[Kategorie:FHT Components]]
[[Kategorie:FHT Components]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:868MHz]]

Aktuelle Version vom 22. September 2023, 15:48 Uhr

FHT80b
FHT80b
Allgemein
Protokoll FHT
Typ Empfänger
Kategorie FHT
Technische Details
Kommunikation 868,35 MHz
Kanäle 1
Betriebsspannung 3 V
Leistungsaufnahme (ca. 2 Jahre)
Versorgung 2x AA
Abmessungen 100 x 60 x 60 mm
Sonstiges
Modulname 11_FHT8V.pm
Hersteller ELV / eQ-3


Der FHT80b ist ein programmierbarer Raumthermostat, der bis zu 8 Stellantriebe FHT8v steuern kann.

Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).Thema

Features

Lokal programmierbare Tages- und Nachttemperatur, die pro Tag mit 4 Schaltpunkten programmiert werden kann. Zusätzliche Anbindung eines Tür/Fensterkontaktes FHT80TF zur Absenkung der Temperatur auf separat einstellbaren Wert bei offenem Fenster (windowopen-temp).

Readings

Parameter Wertbeispiel Erklärung
actuator 0% Position des Stellantriebes in %
battery ok
low 		Ladezustand der Batterien
mode auto
manual
holiday_short
Funktionsmodus (auto, manuell oder Urlaub/Party)
state measured-temp: 20.9 Ist-Temperatur in ° (C oder F in FHT80B wählbar)
desired-temp 21.0 Solltemperatur in ° (C oder F in FHT80B wählbar)
holiday1 126 Endzeit der Urlaubs-/Partyfunktion. Uhrzeit in Minuten seit 00:00 geteilt 10 (im Beispiel 21:00 Uhr)
holiday2 31 Tag im Monat an der die Urlaubs-/Partyfunktion endet
lowtemp ok
warn 		Untertemperatur-Alarm: Im Raum wird der Temperatur-Sollwert nicht erreicht
manu-temp Solltemperatur bei Manuell-Modus
night-temp Solltemperatur bei Absenkung
warnings none
Battery low
Temperature too low
Fault on window sensor 		Auflistung der Fehler
window closed
open 		Statusmeldungen vom FHT80-TF
windowsensor ok
fault 		fault, wenn ein angemeldeter Fenstermelder nicht erreicht werden kann.
windowopentemp 9.0 Solltemperatur bei offenem Fenster
year

month
day
hour
minute

Zeitangaben für interne Uhr
mon-from1

mon-from2
mon-to1
mon-to2
tue-from1
tue-from2
tue-to1
tue-to2
wed-from1
wed-from2
wed-to1
wed-to2
thu-from1
thu-from2
thu-to1
thu-to2
fri-from1
fri-from2
fri-to1
fri-to2
sat-from1
sat-from2
sat-to1
sat-to2
sun-from1
sun-from2
sun-to1
sun-to2

06:00 Angabe von Schaltzeiten im Format HH:MM

Hinweise zum Betrieb mit FHEM

Vor dem Einsatz muss der FHT80b mit der Zentrale (z.B. CUL, FHZ1X00) gepairt werden. Unterbleibt dies, werden nach einer Definition in FHEM zwar Daten vom FHT80b empfangen (z. B. Raumtemperatur), aber es können keine Befehle gesendet werden. Zum Pairen den FHT80b in der Sonderfunktion "cENT" auf "n/a" stellen und danach einen beliebigen Befehl an ihn senden. Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht, war das Pairing erfolgreich.

Weitere Hinweise: FHT mit RFR CUL pairen

Außerdem muss für das FHT manuell oder per Autocreate ein Device in FHEM angelegt werden. Der Raumcode als Adresse des FHT wird von der FHEM Autocreate-Funktion hexadezimal dargestellt, im Gerät jedoch dezimal. Daher muss die Adresse byteweise umgerechnet werden. Beispiel: FHEM habe ein FHT mit der Adresse 162c angelegt. Dies entspricht dann 

hex 16 = 22 dez
hex 2c = 44 dez

dem FHT-Raumcode von 2244. Beim manuelle Anlegen muss der dezimale Raumcode des FHT umgekehrt byteweise in die hexadezimale FHT-Adresse umgerechnet werden.

Der FHT80b akzeptiert Befehle von einer Zentrale nur alle 115+x Sekunden (x = 0.5*letztes Byte des FHT-Hauscodes (auch FHT-ID genannt), Beispiel: FHT-ID 1234, Sendeintervall = 115+0,5*4 = 117 Sekunden) Praktisch ergeben sich so ca. zwei Minuten. Wenn man also mit FHEM z.B. desired-temp-Wechsel an fünf verschiedene FHT80b sendet, wird es selbst unter optimalen Bedingungen 9-10 Minuten dauern, bis der letzte ausgeführt wird.

Dies muss insbesondere beim Debuggen von Automationszenarien berücksichtigt werden. Nicht absetzbare Kommandos werden im einem Puffer der FHZ1x00/CUL/CUN gespeichert, obwohl sie im FHEM-Log als abgesetzt erscheinen. Bei größeren Installationen kann dieser Puffer überlaufen (EOB Fehlermeldung im FHEM Log). Die Puffer sind unterschiedlich groß. Am kleinsten ist er bei den FHZ1x00 mit ca. 40 Byte, was für ca. acht FHT Befehle reicht. Am größten ist er im CULv3 oder CUN mit 200 Bytes, das reicht für ca. 40 Befehle.

Bei zu kleinem Puffer bietet FHEM die Möglichkeit, einen Softpuffer (fhtsoftbuffer) zu konfigurieren (dieser wirkt jedoch nur bei FHZ1X00PC Zentralen). Insgesamt ist fhtsoftbuffer nur dann sinnvoll einsetzbar, wenn die Funklage an sich gut ist und der Puffer zügig abgearbeitet wird. Softbuffer sollte nicht eingesetzt werden, wenn die Übertragung der FHT-Befehle gestört ist, da sich dann schnell sehr lange Befehlsketten im Puffer aufbauen können, deren Abarbeitung sehr viel Zeit in Anspruch nehmen kann. Dies kann dazu führen, dass Kommandos an FHTs erst Stunden später ausgeführt werden.

Um mehr Befehle an ein FHT80b senden zu können, können bis zu 8 Befehle zusammengefasst werden, diese belegen dann nur einen "Zeitslot"

Beispiele:

set heizung_wohn desired-temp 20.5 day-temp 19.0 night-temp 16.0
set hzg_WC mon-from1 07:00 mon-to1 10:00 mon-from2 14:00 mon-to2 23:00

Die Kommunikation des FHT80b mit den Stellantrieben und dem Türkontakt erfolgt ebenso in Zeitabständen von ca. zwei Minuten. In den Pausen sind die Sender und Empfänger von FHT80b und FHT8v abgeschaltet, um Batteriestrom zu sparen.

Der FHT80b übermittelt ungefähr alle 15 Minuten aktuelle Temperaturdaten an die Zentrale.

Die Kommunikation mit der Zentrale ist bidirektional, d.h. die Funkzentrale sendet auch Daten an die FHT80b zurück (insbesondere Acknowledge-Meldungen etc). Dies führt dazu, dass im Zusammenhang mit der Sendzeitbegrenzung die Anzahl der maximal nutzbaren Geräte begrenzt ist. Theoretisch lassen sich bis zu 17, in der Praxis eher nur ca. 10 FHT80b sinnvoll mit einer Zentrale steuern.

Verschiedene Betriebsarten mit FHEM

Da das FHT80 selbst ein Heizprogramm speichern und daher eigentlich auch autark arbeiten kann, stellt sich die Frage, wie FHT80 am Besten in FHEM integriert werden sollte. Es gibt dazu drei wesentliche Szenarien:

  • das FHT80 heizt nur über seine eigenen Heizprogramme, steht also im Automatik Modus. Diese werden jedoch nicht umständlich am FHT80 selber einprogrammiert sondern über FHEM gesetzt. Auch alle gewünschten Änderungen werden über eine Anpassung der im FHT gespeicherten Programme und Setzen von day-temp und night-temp realisiert. Vorteil: Volle Funktionalität auch ohne FHEM, daher ausfallsicher. Nachteil: Änderungen erzeugen hohe Funklast, da ganze Wochenprogramme übertragen werden müssen. Führt bei mehr als fünf bis sechs FHTs idR. zu EOB und LOVF Problemen. Außerdem: Beschränkung auf die FHT80 typisch geringe Zahl von Schaltpunkten (vier pro Tag), mehrstufige Temperaturänderungen sind umständlich. Abhängigkeiten in FHEM (Anwesenheitskontrolle, Bedingungen wie Nutzungserkennung durch Bewegungssensoren etc.) sind schwerer umsetzbar.
  • das FHT80 heizt über seine eigenen Heizprogramme, steht also im Automatik Modus. Zusätzlich sendet FHEM z.B. desired-temp Meldungen und greift so in das Heizprofil ein. Vorteil: Grundfunktionalität auch ohne FHEM, daher ausfallsicher: Das Wochenprogramm des FHT80 wird als Grundprogramm und Fallback genutzt. Zusätzliche Heizpunkte oder höhere/niedrigere Temperaturen werden durch FHEM gesteuert. Geringere Funklast, sofern das Grundprogramm selten geändert wird. Beliebige Schaltpunkte, beliebige Temperaturänderungen leicht einstellbar. Nachteil: Komplex. Das Heizverhalten hängt sowohl vom lokalen Programm im FHT80 ab, als auch von Kommandos die FHEM sendet. Das macht die Steuerung unübersichtlich. Problematisch ist insbesondere, wenn lokale Schaltpunkte kurz vorher gesendete FHEM Kommandos negieren. Dies macht z.B. das Herunterfahren der Heizung bei ungeplanter Abwesenheit schwierig.
  • das FHT80 wird in den manuellen Mode geschaltet und nur über FHEM mittels desired-temp Kommandos gesteuert. Vorteil: Da FHEM volle Kontrolle hat, einfache Umsetzung von Abhängigkeiten (Anwesenheitskontrolle, Bedingungen wie Nutzungserkennung durch Bewegungssensoren etc.). Beliebige Schaltpunkte, beliebige Temperaturänderungen leicht einstellbar. Unkomplex: Temperatur hängt nur vom letzt-gesendeten desired-temp Kommando ab. Nachteil: Bei Ausfall von FHEM wird das FHT80 quasi funktionslos und hält nur die letzte eingestellte Temperatur. Es könnten allerdings im FHT gespeicherte Heizprogramme durch manuelles Umschalten am FHT80 auf den Automatikmodus (Tastendruck) aktiviert werden.

Da das FHT80 auch per FHEM-Befehl zwischen manuellem und automatischem Modus umgestellt werden kann, sind auch Mischformen speziell zwischen den letzten beiden Varianten einsetzbar. Dies wird z.B. im Code Snippet FHT80b Automatik setzen genutzt.

Log-Auszug

FHT80b sendet ca. alle zwei Minuten Steuerbefehle an ggf. angeschlossene Ventilstellantriebe. Der einzustellende Wert liegt zwischen 0% und 100% und wird von FHT80b auf Basis der am Gerät eingestellten Solltemperatur und der vom Gerät gemessenen Ist-Temperatur berechnet: 

FHT <device-name> actuator: 0%

Außerdem sendet FHT80b ca. 4 mal pro Stunde folgenden Statusbericht: 

FHT <device-name> actuator: 0%
FHT <device-name> measured-temp: 23.1 (Celsius)
FHT <device-name> battery: ok
FHT <device-name> lowtemp: ok
FHT <device-name> window: closed
FHT <device-name> windowsensor: ok
FHT <device-name> warnings: none

Die dazu nötige bidirektionale Kommunikation kann mit FHEM mitprotokolliert werden ("set CUL raw X61" vorher nicht vergessen). Hier ein beispielhafter Mitschnitt: 

2008-09-28 13:04:18 FHT wz actuator: 0% 
2008-09-28 13:04:18 FHT wz actuator: 0% 
2008-09-28 13:04:18 FHT wz start-xmit: 17 
2008-09-28 13:04:18 FHT wz FHZ:start-xmit: 17 
2008-09-28 13:04:19 FHT wz measured-low: 21.9 (Celsius) 
2008-09-28 13:04:19 FHT wz FHZ:measured-low: 21.9 (Celsius) 
2008-09-28 13:04:19 FHT wz measured-high: 0 
2008-09-28 13:04:19 FHT wz FHZ:measured-high: 0 
2008-09-28 13:04:19 FHT wz ack: 0 
2008-09-28 13:04:20 FHT wz FHZ:ack: 0 
2008-09-28 13:04:20 FHT wz warnings: none 
2008-09-28 13:04:20 FHT wz FHZ:warnings: none 
2008-09-28 13:04:20 FHT wz ack: 0 
2008-09-28 13:04:20 FHT wz FHZ:ack: 0 
2008-09-28 13:04:20 FHT wz end-xmit: 0 
2008-09-28 13:04:20 FHT wz FHZ:end-xmit: 0

Jede Zeile steht für ein Telegramm (und nicht für 3, wie beim FS20).

FHZ:xxx Telegramme wurden von der FHZ (oder CUN/CUL) gesendet, die anderen vom FHT.

FHEM fasst measured-low und measured-high zu measured-temp zusammen, es werden also im normalen log (telnet: inform timer) zwei Zeilen weniger gemeldet.

17 ist der Hauscode der protokollierten FHZ. Wenn die FHZ nicht mit dem richtigen Hauscode antwortet, dann geht die Kommunikation nicht weiter.

Wenn das FHT nicht an der FHZ angemeldet ist (d.h., das FHT hat nicht den Hauscode des FHZ gespeichert), werden keine Temperaturdaten übermittelt. Set Prog:Cent:N/A setzt den FHT Hauscode auf 100, dann sollte jede FHZ auf "start-xmit" antworten, und das FHT merkt den ersten. Noch besser ist es, dem FHT via FHEM etwas zu senden, dann muss nicht auf die nächste Temperaturmeldung (bis zu 15 Minuten) gewartet werden.

Falls die Gegenseite nicht wie erwartet antwortet, wird nach einem Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte Antwort vorliegt, wird nach 115+x Sekunden der ganze Vorgang einmal wiederholt.

Durch diese recht umfangreiche Kommunikation entsteht im Zusammenhang mit der Sendezeitbeschränkung die maximale Anzahl nutzbarer Geräte von ca. einem Dutzend.

Bekannte Probleme

  • Es gibt zwei weitere, gleich aussehende Geräte mit geringerem Funktionsumfang. Der FHT8b hat keine Verbindung zu Fensterkontakten. Der FHT8 hat keinen bidirektionalen Funk und kann nicht mit einer Zentrale/FHEM verbunden werden.
  • Die Sendefrequenzen einiger FHT80b sind nicht besonders genau auf den eigentlichen Wert von 868,35 MHz justiert und streuen bei verschiedenen Geräten. Die FHZ 1x00PC Geräte sind gegenüber leichten Abweichungen der Frequenz durch eine etwas höhere Empfangsbandbreite eher unempfindlich. Die CUL oder CUNO halten die eingestellte Frequenz dagegen trennschärfer ein, sodass es zu Empfangsproblemen kommen kann. Können Signale eines FHT nicht empfangen werden, kann es sinnvoll sein, probeweise die Frequenz des CUL zu ändern (in 0,05 MHz Schritten), oder die Bandbreite aufzuweiten, z.B. auf 464 kHz.
  • In seltenen Fällen fehlerhafte Aktuator Meldungen, siehe Lime-Protection Bug
  • FHTs hören in der Regel nach 5-10 Tagen auf, von sich aus Daten zur Zentrale zu senden, wenn sonst keine Kommunikation mit dem FHT stattfindet. Ein regelmäßiges z.B. wöchentliches Stellen der Uhrzeit oder wöchentliches Abfragen der wichtigsten Parameter (report2 = 255) vorteilhaft zu eher "funklastarmen" Zeiten schafft Abhilfe; z.B.:
    define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set hzg_Zimmer1 report2 255") } }
  • Die o.g. Situation bringt häufig auch die Actuator-Meldung "unknown_69" mit sich. Eine Beschreibung zur Behebung findet sich in diesem Forums-Post.
  • Der Betrieb von FHTs mit einen RFR CUL kann zu besonderen Problemen führen, siehe RFR CUL und FHT80
  • Es kann vorkommen, dass ein oder auch alle FHT plötzlich aufhören, Temperatur und andere Werte zu senden (aber z.B. actuator und current_action weiter senden). Meist nehmen sie dann auch keine Befehle vom FHEM aus an. Das kann dann an einem Verbindungsproblem zur Zentrale/fhem liegen (Ursache unklar). Eine Lösung ist, im jeweiligen FHT in den Sondereinstellungen die Zentrale zu deaktivieren und wieder einzustellen (Prog - Sond - CEnt - na, Prog - Sond - CEnt - on). Vgl. FHT-Anleitung, Forum dazu

Links

Eine Reihe von Code Snippets zum Thema FHT80b:

Abgerufen von „http://wiki.fhem.de/w/index.php?title=FHT80b&oldid=38610“