Hilfe zur 10_EnOcean.pm

[Schorsch M.]

Hallo alle zusammen :)

Ich beschäftige mich seit einiger Zeit mit Fhem und EnOcean und hätte dazu zwei kurze Fragen.

1. Ist für 10_EnOcean.pm ein UndefFn wie für HM oder FS20 in Planung oder arbeitet
   jemand vll. sogar schon daran? Meine Kenntnisse in Perl sind noch sehr rudimentär, ich werde
   mich aber mal daran versuchen.

2. Mir ist aufgefallen, dass wenn ich ein EnOcean Gerät in Fhem anlernen möchte immer zwei Telegramme benötige.
   Als Beispiel hierzu nehm ich einmal das Thermostat MD15 von Kieback & Peter.
   Ich betätige den Push-Button zum Senden eines Teach-in-Telegrammes am Thermostat. Fhem erkennt dieses und legt
   mittels Autocreate ein EnOcean Gerät mit dieser ID an, erkennt aber nicht genau um welches Gerät es sich handelt.
   Erst wenn ein zweites Telegramm eingeht, wird das Gerät wirklich als MD15 erkannt und angelegt.
   Das gleiche Spiel ist auch mit dem PTM200 Taster möglich.
   Gehe  ich richtig in der Annahme, dass beim ersten Empfang eines Telegramms eines neuen Geräts nur      
   "Define" ausgeführt wird und erst bei einem zweiten Telegramm "Parse"?

   Würd mich echt freuen, wenn mir da  jemand auf die Sprünge helfen könnte :)
   Grüße Georg

[rudolfkoenig]

1. Stimmt, UndefFn hat gefehlt und das habe ich nachgeholt. Macht aber nur einen sehr kleinen Unterschied in merkwuerdigen Situationen.

2. MAn ist das nicht der Fall, beim PTM200 kann man sicher anhand jedes Telegrammes den Sender identifizieren (da gibt es kein learn). Beim Empfang eines Telegrammes wird
Parse->Autocreate->Define aufgerufen, meist aber danach kein Parse mehr, sodass fuer das erste Event notify/FileLog/etc ausfaellt.

PS.: MWN funktioniert MD15 gar nicht, jedenfalls habe ich es nicht zum laufen gebracht.

[Schorsch M.]

Zu 1. Das es fehlt war mir auch nur zufällig aufgefallen. Aber schön das es nachgeholt wurde :)

Zu 2. Beim Schalter war das Problem, dass er beim ersten Klick (Schalter wird gedrückt) zwar erkannt wurde in Fhem, aber sein Schaltzustand nicht bekannt war. (Aber nur wenn das Gerät noch nicht bekannt war in Fhem)
Erst wenn ich den Taster losgelassen habe und das zweite Telegramm gesendet wurde, wurde auch ein Schaltzustand erkannt. Beim MD15, der bei mir läuft, verhält es sich ähnlich (Musste nach dem Teach-in-Telegramm entweder noch eins senden oder auf das erste normale 4BS Telegramm vom MD15 warten).
Ich hab das Problem jetzt erst einmal mit einer kleinen Änderung in 00_TCM.pm gelöst.

if(!Dispatch($hash, "EnOcean:$org:$d1:$id:$status:$odata", \%addvals))
{
  Log 1 , "Dispatch was called devices was not defined call
  Dispatch again";
  Dispatch($hash, "EnOcean:$org:$d1:$id:$status:$odata", \%addvals);
}

[klaus.schauer]

Ich bin derzeit dabei, eine Reihe von neuen Devices in 10_EnOcean einzuarbeiten, möglicht mit autocreate über die EEP und die Manufaturer ID (neues Attribute manufID). Ich hoffe, dass das keine verschenkte Zeit war und die Erkennung und Zuweisung zum vorhandenen attr subType und zusätzlichen attr manufID über die Tabelle EnO_subType grundsätzlich funktionsfähig ist.

[krikan]

Hallo Georg,

habe mehrfach verzewiefelt versucht, den MD15 in Gang zu bringen. Ich kann aber den MD15 nicht steuern, sondern erhalte nur die Zustände über fhem; der MD15 läuft immer im Notmodus.

Anscheind hast Du es ja gelöst, nur leider ist mir Dein Vorgehen unklar. Könntest Du das noch einmal für DAUs erklären. Vielen Dank.

Gruß, Christian

[Schorsch M.]

Hallo Georg,

habe mehrfach verzewiefelt versucht, den MD15 in Gang zu bringen. Ich kann aber den MD15 nicht steuern, sondern erhalte nur die Zustände über fhem; der MD15 läuft immer im Notmodus.

Anscheind hast Du es ja gelöst, nur leider ist mir Dein Vorgehen unklar. Könntest Du das noch einmal für DAUs erklären. Vielen Dank.

Gruß, Christian

Hallo Christian :)

Gern erkläre ich dir wie ich vorgegangen bin.
1. Das Fhem in den Pairing Modus bringen, mit set TCM310 pairForSec 600
   Der Befehl steht bisher nicht im Wiki oder im commandref - habe ihn auf jedenfall dort nicht gefunden.
   Bin in 00_TCM.pm darauf gestoßen.
2. Push-Button am MD15 drücken. Ein erfolgreiches Pairing wird mit 2 Signaltönen bestätigt.

Zur überprüfung ob die Kommunikation korrekt verläuft, habe ich alle übertragenen Daten vom MD15 zu Fhem und umgekehrt mit einem Sniffer mitprotokolliert und alle übertragenen Bits auf ihre Richtigkeit überprüft.
Die Unterlagen dafür sind im EnOcean_Equipment_Profiles_EEP2.1 zu finden und im Datenblatt von Kieback&Peter.
So konnte ich sehen, wann der MD15 im Self-controlled mode sendet und wann im Pairing mode.
Im ersteren Fall wird DB_0.Bit_2 auf 1 gesetzt - es wird also für das dritte Datenbyte des 4BS Telegramms 0x0C übertragen (00001100) - (wenn das Pairing zuvor erfolgreich war).

Der Rest war dann ausprobieren - fährt der Stellantrieb zu, fährt er auf und so weiter...

Hoffe das hilft dir :)

Gruß Georg

[klaus.schauer]

Ist es für alle 4BS-Geräte notwendig set <pcm> pairForSec <time> für das teach-in zu aktivieren oder nur für das spezielle EEP?

Wie wird die Fhem SenderID ausgehandelt und mit welcher SenderID sendet Fhem? Falls man mehrere Geräte unabhängig voneinander bedienen will, braucht man doch sicherlich auch unterschiedliche SenderID.

Ich bin derzeit dabei auch commandref aufzumöbeln. Da nehme ich natürlich gerne auch diese Informationen gerne auf.

[Schorsch M.]

Ist es für alle 4BS-Geräte notwendig set <pcm> pairForSec <time> für das teach-in zu aktivieren oder nur für das spezielle EEP?

Bisher ist der MD15 das Einzige 4BS-Gerät, welches Daten empfangen kann, das ich ausprobiert habe.
Ich denke set <pcm> pairForSec <time> wird für jedes Gerät notwendig sein, bei dem Daten in beide Richtungen gezielt übertragen werden (also ein Pairing stattgefunden hat).

Wie wird die Fhem SenderID ausgehandelt und mit welcher SenderID sendet Fhem?

Fhem sendet mit der ChipID meines TCM300 USB-Sticks, also mit der festen ID dieses Moduls.

Falls man mehrere Geräte unabhängig voneinander bedienen will, braucht man doch sicherlich auch unterschiedliche SenderID.

Eigentlich nicht. Jedem EnOcean Gerät ist eine 32Bit ID zugeteilt, was jedes Gerät "einzigartig" macht.
Eine extra ID im Rahmen der BaseID habe ich bisher nur genutzt, wenn ich in Fhem virtuelle RPS-Schalter angelegt habe. Z.B. zum ansprechen eines Stromstoß-Relais. Dieses sendet im  learn-mode seine ID nicht, sondern horscht einfach nur ob ein RPS-Schaltbefehl eingeht. Ist dies der Fall, merkt es sich dessen ID und reagiert absofort auf Schaltbefehle dieser ID. Möchte man nun mehrere solcher Relais nutzen, braucht man natürlich mehrere ID's, sonst würde ja jedes Relai schalten wenn man mit Fhem was sendet.^^ Da Fhem bei RPS nur im Broadcast sendet.

Möchte man nun mehrere 4BS-Geräte steuern, die alle eine bidirektionale Kommunikation nutzen, braucht man trotzdem nur eine ID zum Senden - schließlich sind alle Geräte mit Fhem gepairt. Sendet Fhem nun Daten an eines dieser Geräte, dann spricht es genau dessen ChipID an. Diese ist Fhem durch das Pairing bekannt.

Ich bin derzeit dabei auch commandref aufzumöbeln. Da nehme ich natürlich gerne auch diese Informationen gerne auf.

Schön zu hören :)

[krikan]

Hallo Georg,

Fhem in den Pairing Modus bringen, mit set TCM310 pairForSec 600

danke für Deine Info und das ist tatsächlich eine Variante die ich noch nicht hatte; werde mal mein Glück versuchen.

Falls man mehrere Geräte unabhängig voneinander bedienen will, braucht man doch sicherlich auch unterschiedliche SenderID.

Genau davon bin ich bisher auch immer ausgegangen und habe dort meinen Fehler zum MD15-Anlernen gesucht. :-(

Danke, Christian

[Schorsch M.]

Hätte jetzt aber auch noch eine Frage :)

Wenn ich dem MD15 eine gewünschte Temperatur übertrage z.B. desired-temp 30 setzt Fhem das Bit für die Set point selection. Damit weiß der MD15 das es sich bei den übertragenen Daten im Daten-Byte 3 um eine Temperatur handelt. Ist das Bit für die Set point selection gesetzt, wird außerdem die zuletzt gemessene Temperatur von Fhem übertragen. Diese wird im Daten-Byte 2 gesetzt.

Hoffe ich drücke mich halbwegs verständlich aus :P

Ok :) Also, das MD15 hat nach dem Empfang also 3 Temperaturen zur Verfügung.
1. Die desired-Temp von 30°C
2. Die zuletzt gemessene an Fhem übertragene Temperatur, welche Fhem wieder an den MD15 gesendet hat
3. Die eigene aktuell gemessene Temperatur

Welche von den Temperaturen werden nun im PI-Regelkreis des MD15 verwendet, um das Ventil einzustellen?

[klaus.schauer]

Nach dem EEP-Spezifikationen hat ein 4BS-Telegramm wie die anderen auch nur eine SenderID und keine EmpfängerID. Wie sollen also mehrere Empfänger wissen, wer von ihnen speziell gemeint sind? Mit einer einzigen Fhem SenderID wird es wohl in diesen Fällen nicht gehen.

[Schorsch M.]

Nach dem EEP-Spezifikationen hat ein 4BS-Telegramm wie die anderen auch nur eine SenderID und keine EmpfängerID. Wie sollen also mehrere Empfänger wissen, wer von ihnen speziell gemeint sind? Mit einer einzigen Fhem SenderID wird es wohl in diesen Fällen nicht gehen.

Ja, die Geräte senden alle im Broadcast an FFFFFFFF. Das ist ja aber egal, da die Daten doch sowieso alle an eine zentrale Einheit gehen sollen (Fhem).
Manche 4BS Geräte speichern aber die ID ihres Kommunikationspartners. Dabei handelt es sich um Variation 3 des 4BS Teach-In. Hab eben nochmal in die EEP 2.1 Specification reingeschaut, müsste auf Seite 74/94 zu finden sein.
Der Empfänger (z.B.MD15) kennt also die ID auf die er hören muss und Fhem kennt die ID an die er senden muss.

Fhem sendet gezielt an die ID des MD15 mit dem es gepairt ist.
Daher braucht man in diesem Fall nur eine ID zum senden. Ich werde versuchen noch ein paar andere Geräte mit 4BS zu testen um das ganze zu bestätigen. :)

[klaus.schauer]

Beim Teach-in ist das klar. Es geht um die "normalen" 4BS-Telegramme. Die enthalten eben "nur" die SenderID und nicht die EmpfängerID!

[Schorsch M.]

Beim Teach-in ist das klar. Es geht um die "normalen" 4BS-Telegramme. Die enthalten eben "nur" die SenderID und nicht die EmpfängerID!

Hi :)
Ja das ist fast richtig, augenscheinlich enthalten die 4BS Funk-Telegramme erst einmal nur die Sender-ID.
Hab mich an dem Problem auch schon gut aufgehängt.
Leider ist das nur das, was uns das TCM Modul sehen lässt. Über den Funkkanal wird nämlich noch etwas mehr gesendet.
Die Ziel-ID ist dort, falls bekannt, mit eingekappselt zwischen Data und Sender-ID.
Falls die Ziel-ID nicht mit übertragen wird, setzt das TCM-Modul diese auf FFFFFFFF.

Die Info dazu findest du hier http://www.enocean.com/en/enocean_modules/EnOceanSerialProtocol3_V1.17_06.pdf/ :)
Ganz ganz unten ;)
Hab das ganze am Signalanalysator bereits überprüft. Einfach mal einen TCM320 mittel SMA drangehängt und senden lassen.

[klaus.schauer]

Dann sollte man ja die Destination ID nach dem bidirectionalen Teach-In mit dem MD15 in den normalen 4BS-Telegrammen sehen, beim einfachen 4BS Teach-In aber nicht.

Auch könnte ich mir Anwendungsfälle beim einfachen Teach-In vorstellen, bei denen das Senden der Destination ID nützlich wäre. Idealerweise einschaltbar oder "frei" vergebbar durch ein Device-Attribut.

Weiterhin könnte auch die Vorgabe der Fhem Sender ID im set <name> pairForSec <t/s> [SenderID] zusätzliche Flexibilität schaffen.