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.
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
Zitat von: peter79 schrieb am Do, 15 August 2013 01:13Hallo 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.
Fehler der lock-Funkion beim Profile gateway, dimming beseitigt.
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?
Zitat von: peter79 schrieb am Fr, 16 August 2013 03:42Jetzt 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.
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
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
Zitat von: peter79 schrieb am Sa, 17 August 2013 04:12Hallo 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.
- 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
Habe es soeben noch einmal auf die von mir benannten Probleme durchgetestet - jetzt sieht alles gut aus - besten Dank!
Logging auf Log3 Funktionen umgestellt.
Zitat von: klaus.schauer schrieb am Di, 13 August 2013 06:521. 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?
- Log auf Log3 umgestellt (Rest)
- commandref berichtigt
Hallo klaus,
habe auf Version 3958 aktualisiert.
Zitat1. 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
Zitat von: karpate schrieb am Do, 26 September 2013 11:07habe auf Version 3958 aktualisiert.
Zitat1. 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?
Das sollte gehen. Jedenfalls ist in der Anleitung zum F4H12 als Steuerungsgerät FTR55* und die FVS-Software angegeben. Das Fhem-Profil emuliert die FVS-Funktionen. Ich hatte die Funktion auf Wunsch von mediastudio eingebaut. Leider habe ich noch keine Rückmeldung, ob es wirklich so funktioniert wie geplant. Tester wie immer gern gesehen.
Hallo,
ich bin gerade bei FHEM/EnOcean eingestigen und ich tue mich noch ein bischen mit
der Heizungssteuerung schwer.
ich habe hier einen FHK61-230V und einen FTR55D. Ich kann die
beiden Anlernen und sehe im Monitor, wie der FTR55 seine Daten sendet:
2013-11-27 21:43:07 EnOcean az_ftr_018425A9 T: 22.0 SPT: 22.0 NR: 0
2013-11-27 21:43:07 EnOcean az_ftr_018425A9 nightReduction: 0
2013-11-27 21:43:07 EnOcean az_ftr_018425A9 setpointTemp: 22.0
2013-11-27 21:43:07 EnOcean az_ftr_018425A9 temperature: 22.0
Und die Bestätigungstelegramme vom FHK:
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 0
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 sensor1: 0
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 sensor2: 140
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 sensor3: 115
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 D3: 1
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 D2: 1
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 D1: 1
2013-11-27 21:43:08 EnOcean EnO_sensor_0087FB13 D0: 1
Hier noch die config:
#ftr55d
define az_ftr_018425A9 EnOcean 018425A9
attr az_ftr_018425A9 manufID 00D
attr az_ftr_018425A9 room Arbeitszimmer
attr az_ftr_018425A9 scaleDecimals 1
attr az_ftr_018425A9 scaleMax 40
attr az_ftr_018425A9 scaleMin 0
attr az_ftr_018425A9 subType roomSensorControl.05
#autocreated fhk61
define EnO_sensor_0087FB13 EnOcean 0087FB13
attr EnO_sensor_0087FB13 manufID 00D
attr EnO_sensor_0087FB13 room EnOcean
attr EnO_sensor_0087FB13 subType sensor
Jetzt habe ich mir noch einen "Regler" definiert,
um die Solltemperatur vom fhem vorzugeben.
define az_temp EnOcean FF826D02
attr az_temp manufID 00D
attr az_temp room Arbeitszimmer
attr az_temp subType roomSensorControl.05
attr az_temp temperatureRefDev az_ftr_018425A9
wenn ich den jetzt mit "set az_temp teach" anlerne,
dann wird der eingelernte FTR55D verdrängt.
Wenn ich die command reference richtig verstehe,
sollten doch das einlernen von beiden im Aktor möglich sein
Zitat
This profil can be used with a further Room Sensor and Control Unit Eltako FTR55* to control a heating/cooling relay FHK12, FHK14 or FHK61. If Fhem and FTR55* is teached in, the temperature control of the FTR55* can be either blocked or to a setpoint deviation of +/- 3 K be limited. For this use the optional parameter [block] = lock|unlock, unlock is default.
The attr subType must be roomSensorControl.05 and attr manufID must be 00D. The attributes must be set manually.
Was ich gerne erreichen würde ist die möglichkeit von FHEM aus den Absenkbetrieb und Solltemperatur
zu setzen und die lokalen Einstellmöglichkeiten am FTR55D weiter zu nutzen.
Habe ich da etwas falsch verstanden oder sollte das nicht gehen wenn ich FHEM und FTR55D einlerne?
Verwirrte Grüße
Martin
Hallo,
Ich habe mal eine frage. Hat jemand einen HowTo wie ich Fhem zusammen mit einen FHK61 und FTR55D einlerne. Bekomme das irgend wie nicht hin. Ich habe schon alles versucht.
Zitat von: martink2 am 27 November 2013, 22:08:51
wenn ich den jetzt mit "set az_temp teach" anlerne,
dann wird der eingelernte FTR55D verdrängt.
Wenn ich die command reference richtig verstehe,
sollten doch das einlernen von beiden im Aktor möglich sein
Was ich gerne erreichen würde ist die möglichkeit von FHEM aus den Absenkbetrieb und Solltemperatur
zu setzen und die lokalen Einstellmöglichkeiten am FTR55D weiter zu nutzen.
Wenn ich die Frage richtig verstehe, klappt die Steuerung mit Fhem allein ohne zusätzlichen FTR55D. Das wäre gut. Bisher habe ich dazu noch keine "Gut"-Meldung erhalten.
Grundsätzlich kann ein Aktor immer nur eine Referenz haben. Lt. Eltako soll man parallel dazu noch einen FTR55D als Stellglied für kleinere Solltemperaturänderungen verwenden können. Leider kann ich dies nicht testen, mir fehlen die Gerätschaften. Es kann deshalb durchaus sein, dass das Fhem-Profil noch nicht ganz fehlerfrei ist. Bitte deshalb mal die Datentelegramme im debug-Mode tracen.
Fehler bei der Formatierung einiger Ausgabewerte beseitigt, insbesondere des Readings voltage.
Hallo Klaus,
ich habe mich noch nicht zum fhk61 gemeldet, da mein einziger test aktor anscheinend einen
defekt hat und erstmal ausgetauscht werden muss bevor ich näheres sagen kann.
Bis jetzt kann ich sagen der Aktor stürzt in der gleichen Frequenz ab egal ob ich
fhem oder den Eltako Aktor als referenz verwende. Ich melde mich sobald der Ersatz da ist.
Grüße
Hallo,
ich warte immer noch auf meinen ersatz Aktor.
Beim weiteren spielen habe ich bemerkt, dass die Bestätigungstelegramme
des Aktors irgendwie nicht vernünftig ausgewertet werden.
FHEM legt per autocreate einen Device vom SubType sensor an.
Muss ich da noch etwas einstellen, damit ich den On/Off State des Aktors bekomme ?
EnOcean az_fhk PacketType: 1 RORG:A5 DATA:00857B0F ID:0087FB13 STATUS:00
ist mal ein beispiel was der Aktor so sendet.
Grüße
Martin
Zitat von: martink2 am 02 Januar 2014, 19:45:25
Beim weiteren spielen habe ich bemerkt, dass die Bestätigungstelegramme
des Aktors irgendwie nicht vernünftig ausgewertet werden.
FHEM legt per autocreate einen Device vom SubType sensor an.
Muss ich da noch etwas einstellen, damit ich den On/Off State des Aktors bekomme ?
EnOcean az_fhk PacketType: 1 RORG:A5 DATA:00857B0F ID:0087FB13 STATUS:00
ist mal ein beispiel was der Aktor so sendet.
Grüße
Martin
Ich würde
define az_fhk EnOcean 0087FB13
attr az_fhk manufID 00D
attr az_fhk subType roomSensorControl.05eintragen. FHK61 sendet wahrscheinlich Quittungstelegramme vom Typ roomSensorControl.05. Fhem kann das richtige Profil nicht automatisch einstellen, da der FHK61 kein teach-in Telegramm sendet.
Danke für den Tip, werde ich gleich mal probieren.
Folgenes habe ich bei Eltako ausgebuddelt:
Zitat
Bei jedem Zustandswechsel des internen Schaltrelais wird nach
ca. 300
ms, ein PTM200-Telegramm mit der Unique ID des integrierten
TCM300 gesendet.
ORG = 0x05
Data_byte3 = 0x70 = Relais Ein, 0x50 = Relais Aus
Anmerkung: Ein 0x00 (entsprache Taster losgelassen) wird nie gesendet!
Daher hatte ich eher gedacht, das da sowas wie ein Tastertelegramm zurück kommt.
Grüße
Martin
Zitat von: martink2 am 03 Januar 2014, 10:38:59
Daher hatte ich eher gedacht, das da sowas wie ein Tastertelegramm zurück kommt.
In der Eltako-Schreibung des FHK61 Aktors werden keine Telegramme vom Typ RORG = A5 bzw. ORG = 07 angegeben. Er scheint aber die Steuertelegramme mit den gleichen Bestätigungstelegrammen zu quittieren.
Es kann aber sein, dass die empfangenen Telegramme vom Typ RORG = F6 bzw. ORG = 05 und vom Typ RORG = A5 bzw. ORG = 07 sich in den Readings teilweise überschreiben. Es sollte aber ein Reading cannelB geben. Dort sollten die letzten Schaltzustände B0/BI angezeigt werden.
Bitte auch einen LOG-Eintrag der RORG F6 Pakete senden.
Also soweit ich das sehe antwortet der Aktor mit dem inhalt empfangener
Telegramme von der Raumregelung und sendet zusätzlich noch folgende:
az_fhk PacketType: 1 RORG:F6 DATA:10 ID:0087FB13 STATUS:30
az_fhk PacketType: 1 RORG:A5 DATA:00857A0F ID:0087FB13 STATUS:00
az_fhk PacketType: 1 RORG:F6 DATA:70 ID:0087FB13 STATUS:30
Was dann zu folgenden Readings führt:
buttons pressed 2014-01-06 19:49:59
channelA AI 2014-01-06 04:20:14
channelB B0 2014-01-06 19:49:59
Die F6 telegramme kommen nur sporadisch und nicht zuverlässig bei jedem Schaltvorgang,
das würde ich aber eher meinem defekten Aktor zuschreiben.
Grüße
Zitat von: martink2 am 06 Januar 2014, 19:59:13
Also soweit ich das sehe antwortet der Aktor mit dem inhalt empfangener
Telegramme von der Raumregelung und sendet zusätzlich noch folgende:
az_fhk PacketType: 1 RORG:F6 DATA:10 ID:0087FB13 STATUS:30
az_fhk PacketType: 1 RORG:A5 DATA:00857A0F ID:0087FB13 STATUS:00
az_fhk PacketType: 1 RORG:F6 DATA:70 ID:0087FB13 STATUS:30
Was dann zu folgenden Readings führt:
buttons pressed 2014-01-06 19:49:59
channelA AI 2014-01-06 04:20:14
channelB B0 2014-01-06 19:49:59
Die F6 telegramme kommen nur sporadisch und nicht zuverlässig bei jedem Schaltvorgang,
das würde ich aber eher meinem defekten Aktor zuschreiben.
Sieht also wie vermutet aus. Eine vernünftige Anzeige sollte also zustande kommen, wenn man dem Aktor manuell das Profil der ihn steuernden Raumregelung zuweist.
Hallo Klaus,
erstmal ein Hinweis an alle anderen Benutzer / Interessenten an dem Eltako FHK61-230:
VORSICHT vor Fertigungswoche 18/13, ich habe im Austausch zwei davon bekommen
und beide haben schwere Softwarefehler, die den Aktor regelmäßig zum Absturz
bringen.
Im moment habe ich im Austausch direkt von Eltako welche aus 50/13 bekommen und die scheinen
erstmal keine Probleme mehr zu verursachen. Ich werde nochmal berichten ob sich das im Dauerbetrieb
bewarheitet.
Auch hat Eltako die Dokumentation der Telgramme vom FHK61-230v angepasst:
PTM200-Telegramm
ORG=0x05
Data_byte3 =
0x70 = Normalbetrieb
0x50 = Nachtabsenkung (-4°K)
0x30 = Absenkbetrieb (-2°K)
0x10 = Aus
Was wäre denn das schlauste, um die Information in die Readings zu Bekommen
anstelle von ChannelB:B0?
Mit folgender Konfig und einem Notify, damit Pakete gesendet werden,
wenn sich die Raumtemperatur verändert scheint es erstmal ganz gut
zu funktionieren.
define az_temp EnOcean 018XXXXC
attr az_temp alias Arbeitszimmer Heizung
attr az_temp group Heizung
attr az_temp icon sani_heating_temp
attr az_temp manufID 00D
attr az_temp room Arbeitszimmer
attr az_temp subDef FFXXXD02
attr az_temp subType roomSensorControl.05
attr az_temp temperatureRefDev az_ftr
Grüße
Martin
Zitat von: martink2 am 26 Januar 2014, 16:52:54
erstmal ein Hinweis an alle anderen Benutzer / Interessenten an dem Eltako FHK61-230:
VORSICHT vor Fertigungswoche 18/13, ich habe im Austausch zwei davon bekommen
und beide haben schwere Softwarefehler, die den Aktor regelmäßig zum Absturz
bringen.
Im moment habe ich im Austausch direkt von Eltako welche aus 50/13 bekommen und die scheinen
erstmal keine Probleme mehr zu verursachen. Ich werde nochmal berichten ob sich das im Dauerbetrieb
bewarheitet.
Ich habe leider auch schon die Erfahrung gemacht, dass bei mir mehrere unterschiedliche Aktoren der 61er und 70er Serie fehlerhaft waren und sind. Die Fertigungsqualität scheint nicht konstant zu sein. Teilweise treten die Fehler nur sporadisch auf und sind kaum zu reproduzieren. Eltako tauscht die Geräte dann anstandslos aus. Aber der Aufwand für die Fehlersuche und den Umbau ist schon ganz schön nervend.
Zitat
Auch hat Eltako die Dokumentation der Telgramme vom FHK61-230v angepasst:
PTM200-Telegramm
ORG=0x05
Data_byte3 =
0x70 = Normalbetrieb
0x50 = Nachtabsenkung (-4°K)
0x30 = Absenkbetrieb (-2°K)
0x10 = Aus
Was wäre denn das schlauste, um die Information in die Readings zu Bekommen
anstelle von ChannelB:B0?
Vorerst attr modul <geraet> FHK14 verwenden. Ich muss mir noch genauer ansehen, ob es gut ist, auch das Model FHK61 in Fhem aufzunehmen, da ja wohl ältere und neue Geräte unterschiedliche Quittungstelegramme senden.
Bitte Rückmeldung, ob das so passt. Dann kann ich die Abfrageroutine auch auf "getestet" setzen.
Zitat
Mit folgender Konfig und einem Notify, damit Pakete gesendet werden,
wenn sich die Raumtemperatur verändert scheint es erstmal ganz gut
zu funktionieren.
define az_temp EnOcean 018XXXXC
attr az_temp alias Arbeitszimmer Heizung
attr az_temp group Heizung
attr az_temp icon sani_heating_temp
attr az_temp manufID 00D
attr az_temp room Arbeitszimmer
attr az_temp subDef FFXXXD02
attr az_temp subType roomSensorControl.05
attr az_temp temperatureRefDev az_ftr
Das hört sich ja gut an.
Hallo,
Wie funktioniert das mit den Notify?