10_EnOcean V3678/3701/4446 - Erweiterungen und Überarbeitungen

[klaus.schauer]

In dieser Version sind folgende Ergänzungen, Änderungen und Fehlerbereinigungen enthalten:

   1. Das Geräteprofil Room Sensor and Control Unit (subtype roomSensorControl.05) enthält jetzt auch set-Befehle. Damit kann Fhem zur Steuerung von Aktoren wie dem Eltako Heiz-Kühl-Relais FHK12, FHK14 und FHK61 eingesetzt werden. Zwei EEP sind vorhanden:
      a. EEP A5-10-06 mit zusätzlicher Nachtabsenkung, emuliert Eltako FVS (FTR55*)
      b. EEP A5-10-02 emuliert z. B. Thermokon SR04 PTS
   An den Aktor muss u. a. neben dem Sollwert (desired-temp, setpoint, setpointTemp oder setpointScaled) auch die Isttemperatur gesendet werden. Die Isttemperatur kann aus einem Referenzdevice z. B. einem in Fhem angelernten Temperatursensor übernommen werden (attr temperatureRefDev) oder in dem Attribute atualTemp z. B. über notify eingetragen werden.
   Das Profil EEP A5-10-06 emuliert die Funktionen der Eltako Software FVS. Bei diesem Profil kann neben Fhem ein zusätzliches Raumkontrollgerät FTR55* im FHK angelernt werden. In Fhem kann dann über den Parameter "block" die Funktion des Sollwertstellers im FTR55* gesteuert werden. Entweder kann am FTR55* der Sollwert aus Fhem um +/- 3 K verändert werden oder der Sollwertsteller wird vollständig blockiert. Diese nicht dokumentierte Zusatzfunktion hat mir der Eltako-Service mitgeteilt. Ich hoffe, ich habe es richtig umgesetzt.
   Die Eltako Heiz-Kühl-Relais erwarten in regelmäßigen Abständen Datentelegramme. Nach einer Stunde Unterbrechung gehen sie in den Notbetrieb. Die Raumkontrollgeräte senden mindestens alle 15 min Datentelegramme. Das Fhem Device sollte auch so eingerichtet werden. Dies kann einfach über einen at-Befehl z. B. mit "set <name> setpointTemp" erfolgen. Falls kein zusätzlicher Parameter angegeben wird, werden die in den readings hinterlegten Werte erneut gesendet.

   2. Die Quittungstelegramme der Heiz-Kühl-Relais Eltako FHK14 und FAE14 werden jetzt frofilspezifisch ausgewertet.

   3. Manufacturer Specific Applications (EEP A5-3F-7F), Shutter: Die Readings position und
   anglePos werden jetzt automatisch aktualisiert, falls ein Kommando position gesendet wird und das Reading state zwischenzeitlich manuell oder von einem bidirektionalen Aktor auf open oder closed gesetzt wurde. Hiermit können jetzt auch Fahrkommandos  zusätzlicher Aktoren erkannt und die Positionsinformationen in Fhem abgeglichen werden. Beispiele für entsprechende notify-Skripte, die das Reading state setzen, wurden kürzlich ins Forum gestellt. Wichtig: Die Inhalte der Readings wurden vereinheitlicht, um die Stati zuverlässig erkennen zu können und um sie an die neueren Profile wie Blind Status (EEP A5-11-03) anzupassen.

   4. Die set-Kommandoliste wird nur noch in Profilen angezeigt, bei denen die Befehle tatsächlich auch zur Verfügung stehen.

   5. Das Tastereingabe-Modul Eltako FTS12EM-UC sendet bei anliegender Spannung je Kanal entweder A0, AI usw. Nach Wegfall der Spannung wird released gesendet. Falls das Attribut sensorMode auf pushbutton gesetzt wird, ist released auswertbar.

   6. Beim EEP RORG 4BS sendet teach-in nun die EEP Nummern und die Manufacturer ID.

   7. Bei subType gateway wurde das reading fan zu fanStage umbenannt.

   8. Bei subType switch wird jetzt immer das reading buttons mit den Stati pressed oder released versorgt. Damit lässt sich der Schaltzustand noch eindeutiger darstellen.

   9. Die Berechnung der Anzeigewerte für die Profile tempSensor.?? wurde berichtigt.

   10. Die Grundfunktionen von EEP RORG MSC sind jetzt implementiert. Derzeit sind aber kein Smart Ack-, UTE-Teach-In und keine spezifischen Geräteprofile verfügbar. Die Funktionen sind deshalb noch experimentell.

   11. Beim Profil MD15 ist die Übertragung der Isttemperatur von Fhem zum MD15 jetzt überarbeitet und wieder eingerichtet. Die Skalierung scheint nicht in Ordnung gewesen zu sein?! Weiterhin kann die Isttemperatur jetzt aus einem Referenzdevice z. B. einem in Fhem angelernten Temperatursensor übernommen werden (attr temperatureRefDev). Das Attribute atualTemp kann auch weiterhin verwendet werden. Falls keine oder unbrauchbare Werte vorgegeben werden, werden die Messwerte des MD15 zurückgegeben.

   12. Aus Version 2968: Beim Profil MD15 können jetzt die Geräte durch Fhem gesteuert werden. Hierzu laufen Tests  (krikan). Zusätzliche Befehle im Service Mode sind verfügbar und zu testen.

Wie immer sind Einzelheiten in der commandref zu finden.

Danke für die bisherigen Rückmeldungen und Tests. Die grundlegenden Veränderungen der Modulstruktur und viele der neuen Profile erfordern gründliche Tests. In der commandref sind die neuen Profile mit "untested" gekennzeichnet. Für mich ist dies wegen der fehlenden Testobjekte nur sehr begrenzt möglich. Ich hoffe deshalb auf zahlreiche Unterstützer.

[peter79]

Hallo Klaus,

da Du so zum testen anregst, anbei eine Sache, welche mir aufgefallen ist. Bitte beachten, dass dieses Verhalten nicht erst mit der letzten 10_EnOcean.pm-Version eingetreten ist.

Versionen (aktuell):
--> fhem.pl 3682 2013-08-13 08:41:17Z rudolfkoenig $
--> 10_EnOcean.pm 3678 2013-08-13 04:47:17Z klaus-schauer $

Hardware-Ausgangslage:
--> FHEM auf Pi mit TCM 310
--> Eltako FAM14
--> Eltako FTS12EM-UC (die installierten Taster sind darüber angeschlossen und direkt in die entsprechenden Aktoren über ein FGW14 als Universaltaster angelernt - parallel zu fhem als FVS - WAF...)
--> Eltako FSB14 für die Rollläden
--> Eltako FUD14 für das Licht

Problem:
--> Nach setzen eines Dimmwertes über fhem funktionieren die direkt über den FGW14 & FTS12EM-UC betriebenen Schalter nicht mehr.
   --> nur durch setzen des Dimmwertes auf "0" oder "off" funktioniert die Steuerung wieder
--> Wenn die interne Eltako Schlummerschaltung aktiviert wurde (Doppelklick auf Taster), werden keine Befehle von fhem am Aktor akzeptiert
   --> Nachdem man einen Befehl per fhem gesendet hat, funktionieren die Taster auch nicht mehr :-(
      --> Situation lässt sich dann aber auch wieder durch ein "off" über fhem an den Aktor auflösen
   
Aktuelle Konfiguration meiner Dimmer:
  define Licht_AZ EnOcean FFXXXXA9
  attr Licht_AZ devStateIcon 0.*:FS20.off 18.*:dim18% 2\d.*:dim25% 3\d.*:dim31% 4\d.*:dim43% 5\d.*:dim50% 6\d.*:dim62% 7\d.*:dim75% 8\d.*:dim87% 9\d.*:dim93% 1\d.*:dim100%
  attr Licht_AZ fp_EG 175,390,5,
  attr Licht_AZ gwCmd dimming
  attr Licht_AZ icon icoBELEUCHTUNG
  attr Licht_AZ manufID 00D
  attr Licht_AZ model FUD14
  attr Licht_AZ room EnOcean,Licht,Arbeitszimmer
  attr Licht_AZ stateFormat dimValue
  attr Licht_AZ subDef FFXXXXBB
  attr Licht_AZ subType gateway
  attr Licht_AZ webCmd dim
  define FileLog_Licht_AZ FileLog ./log/Licht_AZ-%Y.log Licht_AZ

Habe erst gedacht, dass dies mit der "lock/unlock" Funktion in Verbindung steht - aber auch ein "set Licht_AZ dim 50 90 unlock" lässt es nicht funktionieren. Es kann natürlich auch sein, dass das Problem vor der Tastatur sitzt (oder ich etwas falsch verstandene...) - bin mir aber sicher, dass dies vor ein paar Monaten nicht war.
Falls ich Angaben vergessen habe, oder es etwas zu testen gibt, stehe ich natürlich zur Verfügung. Durch den Code des Moduls komme ich z.Z. aber leider nicht in endlicher Zeit durch.

Zu guter letzt noch einen riesen Dank für Deine/Eure Arbeit - grundsätzlich läuft das alles schon echt prima :-)

Viele Grüße
Peter

[klaus.schauer]

Hallo Klaus,

da Du so zum testen anregst, anbei eine Sache, welche mir aufgefallen ist. Bitte beachten, dass dieses Verhalten nicht erst mit der letzten 10_EnOcean.pm-Version eingetreten ist.

Versionen (aktuell):
--> fhem.pl 3682 2013-08-13 08:41:17Z rudolfkoenig $
--> 10_EnOcean.pm 3678 2013-08-13 04:47:17Z klaus-schauer $

Hardware-Ausgangslage:
--> FHEM auf Pi mit TCM 310
--> Eltako FAM14
--> Eltako FTS12EM-UC (die installierten Taster sind darüber angeschlossen und direkt in die entsprechenden Aktoren über ein FGW14 als Universaltaster angelernt - parallel zu fhem als FVS - WAF...)
--> Eltako FSB14 für die Rollläden
--> Eltako FUD14 für das Licht

Problem:
--> Nach setzen eines Dimmwertes über fhem funktionieren die direkt über den FGW14 & FTS12EM-UC betriebenen Schalter nicht mehr.
   --> nur durch setzen des Dimmwertes auf "0" oder "off" funktioniert die Steuerung wieder
--> Wenn die interne Eltako Schlummerschaltung aktiviert wurde (Doppelklick auf Taster), werden keine Befehle von fhem am Aktor akzeptiert
   --> Nachdem man einen Befehl per fhem gesendet hat, funktionieren die Taster auch nicht mehr :-(
      --> Situation lässt sich dann aber auch wieder durch ein "off" über fhem an den Aktor auflösen
   
Aktuelle Konfiguration meiner Dimmer:
  define Licht_AZ EnOcean FFXXXXA9
  attr Licht_AZ devStateIcon 0.*:FS20.off 18.*:dim18% 2\d.*:dim25% 3\d.*:dim31% 4\d.*:dim43% 5\d.*:dim50% 6\d.*:dim62% 7\d.*:dim75% 8\d.*:dim87% 9\d.*:dim93% 1\d.*:dim100%
  attr Licht_AZ fp_EG 175,390,5,
  attr Licht_AZ gwCmd dimming
  attr Licht_AZ icon icoBELEUCHTUNG
  attr Licht_AZ manufID 00D
  attr Licht_AZ model FUD14
  attr Licht_AZ room EnOcean,Licht,Arbeitszimmer
  attr Licht_AZ stateFormat dimValue
  attr Licht_AZ subDef FFXXXXBB
  attr Licht_AZ subType gateway
  attr Licht_AZ webCmd dim
  define FileLog_Licht_AZ FileLog ./log/Licht_AZ-%Y.log Licht_AZ

Habe erst gedacht, dass dies mit der "lock/unlock" Funktion in Verbindung steht - aber auch ein "set Licht_AZ dim 50 90 unlock" lässt es nicht funktionieren.

Danke für den Hinweis. Auf den ersten Blick könnte es doch ein Fehler der lock|unlock Logik sein. Ich muss mir das genauer ansehen.

[klaus.schauer]

Fehler der lock-Funkion beim Profile gateway, dimming beseitigt.

[peter79]

Jetzt funktionieren die Taster auf jeden Fall schon mal, wenn man es als manuellen cmd sendet - allerdings macht es keinen unterschied, ob ich "unlock" oder "lock" mitgebe (dann funktioniert es bei beiden?!).

Nur damit ich das Ganze nicht falsch verstanden habe:
--> "lock" sollte den Aktor für andere Sensoren sperren
--> "unlock" wiederum nicht

Weiterhin ist default immer noch "lock", so dass nach Bedienung des konfigurierten Dim-Sliders immer noch keine Bedienung über die FTS12EM-UC-Taster möglich ist (dies kann natürlich anders herum auch wieder Sinn machen, wenn der Aktor z.B. mit einem Helligkeitssensor verknüpft ist...).

PS: habe nur die 10_EnOcean.pm ausgetauscht - oder sollte ich den gesamten Trunk nehmen?

[klaus.schauer]

Jetzt funktionieren die Taster auf jeden Fall schon mal, wenn man es als manuellen cmd sendet - allerdings macht es keinen unterschied, ob ich "unlock" oder "lock" mitgebe (dann funktioniert es bei beiden?!).

Nur damit ich das Ganze nicht falsch verstanden habe:
--> "lock" sollte den Aktor für andere Sensoren sperren
--> "unlock" wiederum nicht

Weiterhin ist default immer noch "lock", so dass nach Bedienung des konfigurierten Dim-Sliders immer noch keine Bedienung über die FTS12EM-UC-Taster möglich ist (dies kann natürlich anders herum auch wieder Sinn machen, wenn der Aktor z.B. mit einem Helligkeitssensor verknüpft ist...).

PS: habe nur die 10_EnOcean.pm ausgetauscht - oder sollte ich den gesamten Trunk nehmen?

Die Änderungen werden mit der V3701 von 10_EnOcean wirksam!

Per Default wird "unlock" gesendet. Welche konkreten Auswirkungen das "lock"-Bit hat, konnte ich bisher nicht testen. Ich kenne "nur" die Beschreibung der Eltako Funktelegramme. Zudem ist die Funktion nur in der 14er-Serie von Eltako vorhanden. Leider verhält sich Eltako mit dieser Sonderfunktion nicht standardkonform. Das gleiche Bit hat im Standard eine andere Funktion. Deshalb ist es wichtig, dass bei Eltako-Geräten das Attribut manufID auf 00D steht.

Falls wir weitere Fehleranalysen betreiben müssen, bitte die logs im debug-Mode senden. Dann sehe ich, was definitiv gesendet wird.

[peter79]

OK - anbei das ganze mal etwas aufgeschlüsselter - debug + Inform Meldungen / bitte beachten, dass der Debug mit folgendem zur besseren Lesbarkeit gekürzt wurde --> 'tail -fn0 fhem-2013-08.log |grep -vE "HTTP|html|FHEMWEB"'. Falls dies für Dich kontraproduktiv ist, kann ich es aber gerne auch noch einmal komplett machen.

PS: Habe meine ID in der Mitte mit "DDDD" anonymisiert - hoffe dies ist kein Problem, falls doch kann ich es natürlich auch im Original liefern (dann müsste ich aber irgendwann alle Aktoren neu programmieren, was in Arbeit ausartet...)

Ausgangslage immer Licht "aus":
--> "set Licht_AZ dim 100 0 unlock" (Schalter funktioniert danach)
2013.08.16 15:55:49 5: Cmd: >set Licht_AZ dim 100 0 unlock<
2013.08.16 15:55:49 5: Triggering Licht_AZ (1 changes)
2013.08.16 15:55:49 5: Notify loop for Licht_AZ dimValueStored: 100
2013.08.16 15:55:49 2: EnOcean: set Licht_AZ dim
2013.08.16 15:55:49 5: TCM: RpiTCM sending 55000A000180A502640009FFF081BB0088
2013.08.16 15:55:49 5: SW: 55000A000180A502640009FFF081BB0088
2013.08.16 15:55:49 5: RpiTCM/RAW: 5500010002650000
2013.08.16 15:55:49 5: TCM: RpiTCM RESPONSE: RET_OK
 /
2013.08.16 15:55:50 5: RpiTCM/RAW: 550007
2013.08.16 15:55:50 5: RpiTCM/RAW: 55000707017AF670FFDDDDA93001FFFFFFFF520018
2013.08.16 15:55:50 5: RpiTCM dispatch EnOcean:1:F6:70:FFDDDDA9:30:01FFFFFFFF5200
2013.08.16 15:55:50 4: EnOcean: Licht_AZ PacketType: 1 RORG:F6 DATA:70 ID:FFDDDDA9 STATUS:30
2013.08.16 15:55:50 5: Triggering Licht_AZ (3 changes)
2013.08.16 15:55:50 5: Notify loop for Licht_AZ buttons: pressed
2013.08.16 15:55:57 5: RpiTCM/RAW: 55
2013.08.16 15:55:57 5: RpiTCM/RAW: 55000A0701EBA502640009FFDDDDA90001FFFFFFFF530095
2013.08.16 15:55:57 5: RpiTCM dispatch EnOcean:1:A5:02640009:FFDDDDA9:00:01FFFFFFFF5300
2013.08.16 15:55:57 4: EnOcean: Licht_AZ PacketType: 1 RORG:A5 DATA:02640009 ID:FFDDDDA9 STATUS:00
2013.08.16 15:55:57 5: Triggering Licht_AZ (4 changes)
2013.08.16 15:55:57 5: Notify loop for Licht_AZ rampTime: 0
TCM RpiTCM EnOcean:1:F6:70:FFDDDDA9:30:01FFFFFFFF5200
TCM RpiTCM EnOcean:1:A5:02640009:FFDDDDA9:00:01FFFFFFFF5300

--> "set Licht_AZ dim 100 0 lock" (Schalter funktioniert danach - durch das "lock" hätte ich dies jetzt nicht erwartet)
2013.08.16 16:00:04 5: Cmd: >set Licht_AZ dim 100 0 lock<
2013.08.16 16:00:04 5: Triggering Licht_AZ (1 changes)
2013.08.16 16:00:04 5: Notify loop for Licht_AZ dimValueStored: 100
2013.08.16 16:00:04 2: EnOcean: set Licht_AZ dim
2013.08.16 16:00:04 5: TCM: RpiTCM sending 55000A000180A502640009FFF081BB0088
2013.08.16 16:00:04 5: SW: 55000A000180A502640009FFF081BB0088
2013.08.16 16:00:05 5: RpiTCM/RAW: 550001000265000055000707017AF670FFDDDDA93001FFFFFFFF53000D
2013.08.16 16:00:05 5: TCM: RpiTCM RESPONSE: RET_OK
2013.08.16 16:00:05 5: RpiTCM dispatch EnOcean:1:F6:70:FFDDDDA9:30:01FFFFFFFF5300
2013.08.16 16:00:05 4: EnOcean: Licht_AZ PacketType: 1 RORG:F6 DATA:70 ID:FFDDDDA9 STATUS:30
2013.08.16 16:00:05 5: Triggering Licht_AZ (3 changes)
2013.08.16 16:00:05 5: Notify loop for Licht_AZ buttons: pressed
 /
2013.08.16 16:00:12 5: RpiTCM/RAW: 55000A0701EBA502
2013.08.16 16:00:12 5: RpiTCM/RAW: 55000A0701EBA502640009FFDDDDA90001FFFFFFFF5000AA
2013.08.16 16:00:12 5: RpiTCM dispatch EnOcean:1:A5:02640009:FFDDDDA9:00:01FFFFFFFF5000
2013.08.16 16:00:12 4: EnOcean: Licht_AZ PacketType: 1 RORG:A5 DATA:02640009 ID:FFDDDDA9 STATUS:00
2013.08.16 16:00:12 5: Triggering Licht_AZ (4 changes)
2013.08.16 16:00:12 5: Notify loop for Licht_AZ rampTime: 0
TCM RpiTCM EnOcean:1:F6:70:FFDDDDA9:30:01FFFFFFFF5300
TCM RpiTCM EnOcean:1:A5:02640009:FFDDDDA9:00:01FFFFFFFF5000

--> "dim per slider auf 100%" (Schalter funktioniert danach nicht!)
2013.08.16 16:01:57 5: Cmd: >set Licht_AZ dim 100<
2013.08.16 16:01:57 5: Triggering Licht_AZ (1 changes)
2013.08.16 16:01:57 5: Notify loop for Licht_AZ dimValueStored: 100
2013.08.16 16:01:57 2: EnOcean: set Licht_AZ dim
2013.08.16 16:01:57 5: TCM: RpiTCM sending 55000A000180A50264010DFFF081BB00F3
2013.08.16 16:01:57 5: SW: 55000A000180A50264010DFFF081BB00F3
2013.08.16 16:01:57 5: RpiTCM/RAW: 5500010002650000
2013.08.16 16:01:57 5: TCM: RpiTCM RESPONSE: RET_OK
 /
2013.08.16 16:01:58 5: RpiTCM/RAW: 5500070701
2013.08.16 16:01:58 5: RpiTCM/RAW: 55000707017AF670FFDDDDA93001FFFFFFFF520018
2013.08.16 16:01:58 5: RpiTCM dispatch EnOcean:1:F6:70:FFDDDDA9:30:01FFFFFFFF5200
2013.08.16 16:01:58 4: EnOcean: Licht_AZ PacketType: 1 RORG:F6 DATA:70 ID:FFDDDDA9 STATUS:30
2013.08.16 16:01:58 5: Triggering Licht_AZ (3 changes)
2013.08.16 16:01:58 5: Notify loop for Licht_AZ buttons: pressed
2013.08.16 16:01:59 5: RpiTCM/RAW: 55
2013.08.16 16:01:59 5: RpiTCM/RAW: 55000A0701EBA502640009FFDDDDA90001FFFFFFFF530095
2013.08.16 16:01:59 5: RpiTCM dispatch EnOcean:1:A5:02640009:FFDDDDA9:00:01FFFFFFFF5300
2013.08.16 16:01:59 4: EnOcean: Licht_AZ PacketType: 1 RORG:A5 DATA:02640009 ID:FFDDDDA9 STATUS:00
2013.08.16 16:01:59 5: Triggering Licht_AZ (4 changes)
2013.08.16 16:01:59 5: Notify loop for Licht_AZ rampTime: 0
TCM RpiTCM EnOcean:1:F6:70:FFDDDDA9:30:01FFFFFFFF5200
TCM RpiTCM EnOcean:1:A5:02640009:FFDDDDA9:00:01FFFFFFFF5300

[peter79]

Hallo Klaus,

Ich denke, Deine Anpassung in der v3701 ist obsolet, da es zwei Schreibfehler bei der "manufID" gibt. So gibt es zwei Stellen mit "Oh"´s anstatt mit Nullen. Nach Anpassung in der v3678 klappt es nun bei mir, wie erwartet (mit der v3701 ist lock/unlock invertiert...):

    758         if ($sendDimCmd) {
    759           if (defined $a[1]) {
    760             return "Usage: $cmd dim/% [rampTime/s lock|unlock]" if (($a[1] ne "lock") && ($a[1] ne "unlock"));
    761             if ($manufID eq "OOD") {
    762               # Eltako devices: lock dimming value
    763               if ($a[1] eq "lock") { $setCmd = $setCmd | 4; }
    764             } else {
    765               # Dimming value relative
    766               $setCmd = $setCmd | 4;
    767             }
    768             shift(@a);
    769           } else {
    770             if ($manufID ne "OOD") { $setCmd = $setCmd | 4; }
    771           }
    772           if ($dimVal > 100) { $dimVal = 100; }
    773           if ($dimVal <= 0) { $dimVal = 0; $setCmd = 8; }
    774           if ($rampTime > 255) { $rampTime = 255; }
    775           if ($rampTime < 0) { $rampTime = 0; }
    776           $updateState = 0;
    777           $data = sprintf "%02X%02X%02X%02X", $gwCmdID, $dimVal, $rampTime, $setCmd;
    778         }

--> dies ist noch der Original-Auszug, wie er im Code ist...
PS: Wäre es nicht schöner, wenn man look/unlook auch ohne die Ramp-Time übergeben könnte?

Naja, da ich dies auch nicht sofort gesehen habe, habe ich wesentlich etwas zu den EnOcean Telegrammen dazugelernt ;-)

Gruß
Peter

[klaus.schauer]

Hallo Klaus,

Ich denke, Deine Anpassung in der v3701 ist obsolet, da es zwei Schreibfehler bei der "manufID" gibt. So gibt es zwei Stellen mit "Oh"´s anstatt mit Nullen. Nach Anpassung in der v3678 klappt es nun bei mir, wie erwartet (mit der v3701 ist lock/unlock invertiert...):

    758         if ($sendDimCmd) {
    759           if (defined $a[1]) {
    760             return "Usage: $cmd dim/% [rampTime/s lock|unlock]" if (($a[1] ne "lock") && ($a[1] ne "unlock"));
    761             if ($manufID eq "OOD") {
    762               # Eltako devices: lock dimming value
    763               if ($a[1] eq "lock") { $setCmd = $setCmd | 4; }
    764             } else {
    765               # Dimming value relative
    766               $setCmd = $setCmd | 4;
    767             }
    768             shift(@a);
    769           } else {
    770             if ($manufID ne "OOD") { $setCmd = $setCmd | 4; }
    771           }
    772           if ($dimVal > 100) { $dimVal = 100; }
    773           if ($dimVal <= 0) { $dimVal = 0; $setCmd = 8; }
    774           if ($rampTime > 255) { $rampTime = 255; }
    775           if ($rampTime < 0) { $rampTime = 0; }
    776           $updateState = 0;
    777           $data = sprintf "%02X%02X%02X%02X", $gwCmdID, $dimVal, $rampTime, $setCmd;
    778         }

--> dies ist noch der Original-Auszug, wie er im Code ist...
PS: Wäre es nicht schöner, wenn man look/unlook auch ohne die Ramp-Time übergeben könnte?

Danke für die Fehlersuche. Ich hatte schon solch einen dummen Fehler vermutet aber nicht gesehen. Ich werde die Korrektur der V3701 einstellen. Die lock-Logik in V3678 war auch sonst nicht ganz ok. Das lock/unlock sollte nach meinen Protokollen erst jetzt richtig sein. Fast... beim Ausschalten wird nie lock gesetzt. Das werde ich später nacharbeiten.

Bei der Reihenfolge der Parameter muss man sich entscheiden 8:) Natürlich könnte man die Reihenfolge lock/unlock und Ramptime tauschen oder die Übergabewerte ohne Rücksicht auf die Reihenfolge parsen. Ich möchte die Parameterabfrage aber nicht noch weiter aufblähen.

[klaus.schauer]

- Fehler der lock-Funktion im Profil gateway, dimming beseitigt
- Zusätzliches reading block im Profil gateway, switching und dimming
- Profil (subDef) roomSensorControl.05: Schreiben des readings temperature in die Befehlsblöcke verlagert, Manufacturer ID 00D berichtigt

[peter79]

Habe es soeben noch einmal auf die von mir benannten Probleme durchgetestet - jetzt sieht alles gut aus - besten Dank!

[klaus.schauer]

Logging auf Log3 Funktionen umgestellt.

[klaus.schauer]

1. Das Geräteprofil Room Sensor and Control Unit (subtype roomSensorControl.05) enthält jetzt auch set-Befehle. Damit kann Fhem zur Steuerung von Aktoren wie dem Eltako Heiz-Kühl-Relais FHK12, FHK14 und FHK61 eingesetzt werden. Zwei EEP sind vorhanden:
      a. EEP A5-10-06 mit zusätzlicher Nachtabsenkung, emuliert Eltako FVS (FTR55*)
      b. EEP A5-10-02 emuliert z. B. Thermokon SR04 PTS
   An den Aktor muss u. a. neben dem Sollwert (desired-temp, setpoint, setpointTemp oder setpointScaled) auch die Isttemperatur gesendet werden. Die Isttemperatur kann aus einem Referenzdevice z. B. einem in Fhem angelernten Temperatursensor übernommen werden (attr temperatureRefDev) oder in dem Attribute atualTemp z. B. über notify eingetragen werden.
   Das Profil EEP A5-10-06 emuliert die Funktionen der Eltako Software FVS. Bei diesem Profil kann neben Fhem ein zusätzliches Raumkontrollgerät FTR55* im FHK angelernt werden. In Fhem kann dann über den Parameter "block" die Funktion des Sollwertstellers im FTR55* gesteuert werden. Entweder kann am FTR55* der Sollwert aus Fhem um +/- 3 K verändert werden oder der Sollwertsteller wird vollständig blockiert. Diese nicht dokumentierte Zusatzfunktion hat mir der Eltako-Service mitgeteilt. Ich hoffe, ich habe es richtig umgesetzt.
   Die Eltako Heiz-Kühl-Relais erwarten in regelmäßigen Abständen Datentelegramme. Nach einer Stunde Unterbrechung gehen sie in den Notbetrieb. Die Raumkontrollgeräte senden mindestens alle 15 min Datentelegramme. Das Fhem Device sollte auch so eingerichtet werden. Dies kann einfach über einen at-Befehl z. B. mit "set <name> setpointTemp" erfolgen. Falls kein zusätzlicher Parameter angegeben wird, werden die in den readings hinterlegten Werte erneut gesendet.
 
   2. Die Quittungstelegramme der Heiz-Kühl-Relais Eltako FHK14 und FAE14 werden jetzt frofilspezifisch ausgewertet.

Bisher habe ich keine Rückmeldungen zu den neuen Funktionen! Alles komplett in Ordnung?

[klaus.schauer]

- Log auf Log3 umgestellt (Rest)
- commandref berichtigt

[karpate]

Hallo klaus,

habe auf Version 3958 aktualisiert.

1. Das Geräteprofil Room Sensor and Control Unit (subtype roomSensorControl.05) enthält jetzt auch set-Befehle. Damit kann Fhem zur Steuerung von Aktoren wie dem Eltako Heiz-Kühl-Relais FHK12, FHK14 und FHK61 eingesetzt werden. Zwei EEP sind vorhanden:

Sind die set-Befehle auch für Heizrelais F4H12 möglich?

Danke und Gruß ingo