10_EnOcean V3179 - Erweiterungen und Überarbeitungen

[klaus.schauer]

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

1. Die Profile eltakoDimmer, eltakoShutter, FAH, FBH, FTF und SR04 entfallen. Beim Profil  PM101 haben sich die Attributdefinition und das Ausgabeformat geändert. Zur Umstellung ist folgendes Vorgehen notwendig:

- eltakoDimmer: manuell umstellen auf >> attr <name> subType gateway, attr <name> gwCmd dimming
- eltakoShutter: manuell umstellen auf >> attr <name> subType manufProfile, attr <name> manufID 00D, attr <name> model FSB14|FSB61|FSB70  
- FAH: Gerät neu an Fhem anlernen (teach in) >> attr <name> subType lightSensor.01
- FBH: Gerät neu an Fhem anlernen (teach in) >> attr <name> subType lightTempOccupSensor.01
- FTF: Gerät neu an Fhem anlernen (teach in) >> attr <name> subType roomSensorControl.05
- SR04*: Gerät neu an Fhem anlernen (teach in) >> attr <name> subType roomSensorControl.05
- PM101: manuell umstellen auf >> attr <name> subType PM101

   
Die alten Readings sollten mit dem Kommando deletereading einzeln gelöscht werden. Weitere Informationen siehe commandref.
   
2. In Umgebungen mit Repeatern ist es möglich, dass von Fhem gesendete Datentelegramme wieder von Fhem empfangen werden. Die Weiterverarbeitung dieser Telegramme kann jetzt im TCM-Modul unterdrückt werden. Hierzu ist das TCM-Attribut attr <name> blockSenderID own   zu setzen. Die Gerätebeschreibung des TCM-Modul im WEB-Interface enthält nun zusätzlich die Variablen

- BaseID mit der ersten vom TCM-Modul belegten SendeID und
- LastID mit der letzten verwendbaren SendeID.

Dies erleichtert sicherlich die richtige Auswahl der SendeIDs für die Devices.
   
3. Aus Version 2968: Beim Teach-In wurden manchmal die angelernten Attribute nicht zuverlässig in fhem.cfg gespeichert. Der Fehler ist behoben  (Schorsch M.). Nachtrag: Bei einem Test von tobias6789 wurden die angelernten Attribute nach dem Teach-In dennoch nicht vollständig gespeichert. Wird weiter beobachtet.
   
4. Aus Version 2968: Beim Profil MD15 können jetzt die Geräte durch Fhem gesteuert werden. Die Übertragung  der Isttemperatur von Fhem zum MD15 ist derzeit nicht möglich. Hierzu laufen Tests  (krikan). Zusätzliche Befehle im Service Mode sind verfügbar und zu testen.

Danke für die bisherigen Rückmeldungen und Tests. Ich möchte darum bitten, die neuen Profile zu testen. Für mich ist dies wegen der fehlenden Testobjekte nicht möglich.

[immi]

Hallo Klaus
danke fuer Dein fleissige Arbeit.
Ich finde dein Engagement in FHEM toll.

In der Vergangenheit hat SR04 als setpoint(solltemp) ein Wert in °C.
Heute haben wir ein Wert zwischen 0 und 255, den ich wirklich nicht brauchen kann.
Mir ist bewusst, dass Du den Datenblatt genau abgebildet hast.
http://www.thermokon.de/files/produktblatt-sr041319282511.pdf
Ich wuerde  lieber ein setpoint in °C  begrussen (wie in der Vergangenheit).

danke immi

Code: [Auswählen]


elsif($model =~ m/^SR04/ || $st eq "SR04") {
      # Room Sensor and Control Unit
      # [Thermokon SR04 *]
      my ($fspeed, $temp, $present, $solltemp);
      $fspeed = 3;
      $fspeed = 2      if($db_3 >= 145);
      $fspeed = 1      if($db_3 >= 165);
      $fspeed = 0      if($db_3 >= 190);
      $fspeed = "Auto" if($db_3 >= 210);
      $temp   = sprintf("%0.1f", 40-$db_1/6.375);      # 40..0
      $present= $db_0&0x1 ? "no" : "yes";
      $solltemp= sprintf("%0.1f", $db_2/6.375); #<------------------
      push @event, "3:state:temperature $temp";
      push @event, "3:set_point: $solltemp";
      push @event, "3:setpoint:$db_2";
      push @event, "3:fan:$fspeed";


[klaus.schauer]

Hallo Klaus
danke fuer Dein fleissige Arbeit.
Ich finde dein Engagement in FHEM toll.

In der Vergangenheit hat SR04 als setpoint(solltemp) ein Wert in °C.
Heute haben wir ein Wert zwischen 0 und 255, den ich wirklich nicht brauchen kann.
Mir ist bewusst, dass Du den Datenblatt genau abgebildet hast.
http://www.thermokon.de/files/produktblatt-sr041319282511.pdf
Ich wuerde  lieber ein setpoint in °C  begrussen (wie in der Vergangenheit).

danke immi

Code: [Auswählen]


elsif($model =~ m/^SR04/ || $st eq "SR04") {
      # Room Sensor and Control Unit
      # [Thermokon SR04 *]
      my ($fspeed, $temp, $present, $solltemp);
      $fspeed = 3;
      $fspeed = 2      if($db_3 >= 145);
      $fspeed = 1      if($db_3 >= 165);
      $fspeed = 0      if($db_3 >= 190);
      $fspeed = "Auto" if($db_3 >= 210);
      $temp   = sprintf("%0.1f", 40-$db_1/6.375);      # 40..0
      $present= $db_0&0x1 ? "no" : "yes";
      $solltemp= sprintf("%0.1f", $db_2/6.375); #<------------------
      push @event, "3:state:temperature $temp";
      push @event, "3:set_point: $solltemp";
      push @event, "3:setpoint:$db_2";
      push @event, "3:fan:$fspeed";


Einfach ein userReadings zusätzlich verwenden, z. B.
attr eg_kue_Temp userReadings set_point { ReadingsVal("eg_kue_Temp","setpoint",0)/6.375; }, siehe http://forum.fhem.de/index.php?t=msg&th=11549&goto=75895&rid=293#msg_75895, ff.

[immi]

Danke Klaus
Dein workarround passt

Code: [Auswählen]


attr eg_kue_Temp userReadings set_point {sprintf("%0.1f", ReadingsVal("eg_kue_Temp","setpoint",0)/6.375) }


aber ich bleibe der Meinung dass Vorher war besser.
M.e. Das Wert setpoint (from 0 to 255) wird niemand ohne Konvertierung in set_point (from 0 to 40°C) brauchen.

l.g.
Immi

[klaus.schauer]

Danke Klaus
Dein workarround passt

Code: [Auswählen]


attr eg_kue_Temp userReadings set_point {sprintf("%0.1f", ReadingsVal("eg_kue_Temp","setpoint",0)/6.375) }


aber ich bleibe der Meinung dass Vorher war besser.
M.e. Das Wert setpoint (from 0 to 255) wird niemand ohne Konvertierung in set_point (from 0 to 40°C) brauchen.

l.g.
Immi

Ich denke nicht, dass die Lösung ein "um ein Problem herumarbeiten" zu deutsch workarround ist. Das EEP sieht nun mal die Ausgabe des Rohwertes vor, da die Skalierung der jeweiligen Geräte und Hersteller unterschiedlich ist. Ich habe eben nicht nur Skalen von 0 ... 40° gefunden! Also hätte ich eine zusätzliche universelle Skalierungsfunktion bauen müssen. Das hätte den Programmcode vergrößert, obwohl es eine Universallösung mit userReadings gibt. Das gleiche gilt auch für andere Anforderungen, die gewünscht wurden, z. B. aus dem Zählerwert eines Stromzählers den Preis zu berechnen.

[immi]

Klaus,
bitte um Enschuldigung fuer meine Formulierung.
Ich moechte meine Ausdrucke besser kontrollieren. Ich moechte nicht undankbar klingen.
Ich bin vollig bei dir wenn Du sagst dass gibt es keine Beschreibung von Supplier bzg 0 40°C bei Setpoint.
Das Mapping 0-40°C --0 255 kann nicht bewiesen werden, aber fast
 
We have a room temperature sensor with set point adjustment (EEP A5-10-03 Manufacturer: Thermokon)
As far as I understood, the SR04P sends (mainly) 2 values, one byte long.
one which correspons to a measured temperature: let us call it CodeMes (255 to 0)
one which corresponds to an angle of the set point adjustment: let us call it CodeSet (0 to 255)

Problem: We have no link from CodeSet to a temperature from Thermokon
But we have a link from CodeSet to CodeMes: When CodeSet+CodeMes>255 the heating is off, when < the heating is on.
Such a comparison implies that the scale behind CodeSet and CodeMes is the same and no offset is present.
Therefore knowing the temperature domain of the CodeSet (0..40°C), we can induce that CodeSet is mapped also between  (0..40°C) with a linear scale.

This is not a demonstration, it is based on the theoretical assumption that Thermokon is not comparing apples with tomatoes (CodeSet CodeMess)

Anyways, here, you have to decide if you prefer to implement in FHEM only the supplier certified technical notes,
or take a very limited risk and provide the final FHEM user a confortable system.

In the past, a limited risk was acceptable, and therefore Setpoint was in °C.
I would suggest to close the 3D here. I updated my configuration file, which is now double as long and half as readable.
 
ciao immi

[rudolfkoenig]

Ich bin auch Immis Meinung, ohne die Arbeit von Klaus schmaelern zu wollen.

Wenn ich mich recht erinnere, sind in den EEP etwa 30 unterschiedliche reine Temperatursensor-Profile, und dann nochmal soviele kombinierte. Fuer mich klingt das so, dass jeder Hersteller sein Geraet "standardisiert", indem die Spec in der EEP dokumentiert wird. Nach dem Motto: Standards sind wichtig, jeder sollte seins haben. Das ist natuerlich fuer den Modul-Maintainer ein Alptraum.

Ich finde aber trotzdem, dass man den Endbenutzer nicht im Regen stehen lassen sollte, indem man die letzten Schritte der Programmierung auf ihn schiebt. userReading ist eigentlich nur fuer den Fall gedacht, wo der Benutzer ganz spezielle Daten haben will, z.Bsp. zusammengerechnet aus mehreren Quellen.

Vielleicht hilft eine Modell spezifische Tabelle im Modul, wo fuer jedes Modell die speziellen Umrechnungen aufgefuehrt werden. Diese Daten koennte man auch nach und nach einpflegen, wenn die Benutzer die Formel dazu melden. Damit wuerden die nachfolgenden Anwender davon profitieren.

[krikan]

Dann gebe ich mal Klaus Rückendeckung. Seine Umsetzung ist korrekt und eine vorgegebene Skalierung auf die genannte Skala und Einheit wäre mMn falsch:

SR04 mit Sollwertsteller geben beim Setpoint nur einen Skalenwert an und nicht eine genau definierte Temperatur. Dies ergibt sich sowohl aus dem EEP 2.1 und auch der oben verlinkten Beschreibung von Thermokon (Sollwerterfassung P: Bereich: 0...270° Drehwinkel). Welche Temperatur (oder auch andere Einheit) durch den Sollwertsteller ausgewählt wird, ist alleine abhängig vom Aktor an den der SR04 seine Werte liefert. Genau deshalb hat auch Thermokon keine Skala auf die Sollwertsteller gedruckt. Das anscheinend bei immi 0-40°C passen, liegt halt nur am Aktor an den die Werte geliefert werden. Bei anderen kann es ganz anders sein. Mit dem Sollwertsteller kann man auch bspw. Lüftungsanlagen (Leistung statt Temperatur) steuern. Der Weg über userReadings ist der einzig sinnvolle.

@klaus.schauer: Habe MD15 nicht vergessen, komme momentan nur nicht dazu!

Gruß, Christian

[klaus.schauer]

@klaus.schauer: Habe MD15 nicht vergessen, komme momentan nur nicht dazu!

Gruß, Christian

Freut mich zu hören. Manchmal hat gut Ding Weile.

[klaus.schauer]

Ich bin auch Immis Meinung, ohne die Arbeit von Klaus schmaelern zu wollen.

Wenn ich mich recht erinnere, sind in den EEP etwa 30 unterschiedliche reine Temperatursensor-Profile, und dann nochmal soviele kombinierte. Fuer mich klingt das so, dass jeder Hersteller sein Geraet "standardisiert", indem die Spec in der EEP dokumentiert wird. Nach dem Motto: Standards sind wichtig, jeder sollte seins haben. Das ist natuerlich fuer den Modul-Maintainer ein Alptraum.

Ich finde aber trotzdem, dass man den Endbenutzer nicht im Regen stehen lassen sollte, indem man die letzten Schritte der Programmierung auf ihn schiebt. userReading ist eigentlich nur fuer den Fall gedacht, wo der Benutzer ganz spezielle Daten haben will, z.Bsp. zusammengerechnet aus mehreren Quellen.

Vielleicht hilft eine Modell spezifische Tabelle im Modul, wo fuer jedes Modell die speziellen Umrechnungen aufgefuehrt werden. Diese Daten koennte man auch nach und nach einpflegen, wenn die Benutzer die Formel dazu melden. Damit wuerden die nachfolgenden Anwender davon profitieren.

Ich glaube nicht, dass sinnvoll ist nach und nach eine Vielzahl von möglichen Skalen einzupflegen. Deshalb habe ich eine Skalierungsfunktion für die vier Profile roomSensorControl.[01|02|05|1F] eingebaut, die die Rohwerte in setpoint ausgeben. Da kann sich jeder seine eigene individuelle Skala des Sollwertstellers vorgeben, siehe http://forum.fhem.de/index.php?t=msg&th=12946&goto=78682&rid=293#msg_78682.