Hallo!
Vorschlag für eine Erweiterung des 00_TCM.pm Moduls zur Unterstützung der bidirektionalen 14er Serie von Eltako via FGW14:
An der RS232 Schnittstelle des Eltako FGW14 Moduls verwendet Eltako das ESP2 Protokoll von Enocean.
Dies ist das selbe Protokoll, das ein TCM120 Modul an seiner seriellen Schnittstelle verwendet.
Man kann also den Eltako RS485 Bus mit FAM14 Enocean Funkantennenmodul auch kabelgebunden ohne TCM120 USB-Stick in FHEM einbinden,
indem man die serielle Schnittstelle des FGW14 als TCM120 definiert.
Z.B.:
define TCM120 TCM 120 /dev/ttyS3@57600
Achtung am FGW14 muss die Bitrate auf 57600 bit/s eingestellt sein!
VORTEIL dieser Lösung: Stellt man den Drehschalter des FAM14 Moduls auf Position 4, pollt das FAM14 zyklisch den Status aller Module.
Man erhält so auch unabhängig von Schaltaktionen und insbesondere auch nach einer Downtime von FHEM immer den aktuellen Status sämtlicher Autoren der 14er Serie. Diese werden in Position 4 nicht in das Funknetz übertragen (dieses würde man damit auch unnötig belasten).
FHEM erreichen diese Statusinfos über die kabelgebundene Anbindung an den Eltako Bus via FGW14.
Nach dieser Konfiguration funktioniert der lesende Zugriff und mit folgender Definition ist es möglich die Switch Ereignisse
einer Enocean Funkvernbedienung oder von Funktastern zu erfassen:
define RC1_B1_4 EnOcean 008B3387
attr RC1_B1_4 IODev TCM120
attr RC1_B1_4 event-on-change-reading state,buttons,channelA,channelB
attr RC1_B1_4 room EnOcean
attr RC1_B1_4 subType switch
Nach Schaltvorgängen mit Aktoren der 14er Serie findet man allerdings Fehlermeldungen folgender Art im fhem Logfile:
2014.03.15 15:14:17 2: TCM TCM120 Unknown command: 8B05500000000000000530
Diese Meldung deutet auf eine unvollständige Implementierung des ESP2 Protokolls im 00_TCM.pm Modul hin:
Die Funktion TCM_Read unterstützt bisher Telegrammtypen mit
org =05, 06, 07 nicht als Receive Message Telegram (RMT) sondern nur als Receive Radio Telegram (RRT).
Mit den nachfolgenden Anpassungen in 00_TCM.pm lässt sich dieses Problem lösen:
in der Funktion TCM_Read() ab ca Zeile 270 im else Zweig, welcher RMT Telegramme bearbeiten soll:
} else {
# Receive Message Telegram (RMT)
my $msg=TCM_Parse120($hash, $net, 1);
if (($msg eq 'OK') && ($net =~ m/^8B(..)(........)(........)(..)/)){
my ($org, $d1,$id,$status) = ($1, $2, $3, $4);
my $packetType = 1;
# Re-translate the ORG to RadioORG / TCM310 equivalent
my %orgmap = ("05"=>"F6", "06"=>"D5", "07"=>"A5", );
if($orgmap{$org}) {
$org = $orgmap{$org};
} else {
#Log 1, "TCM120: unknown ORG mapping for $org";
Log3 undef, 1, "TCM unknown ORG mapping for $org";
}
if ($org ne "A5") {
# extract db_0
$d1 = substr($d1, 0, 2);
}
if ($blockSenderID eq "own" && (hex $id) >= $baseID && (hex $id) <= $lastID) {
Log3 $name, 5, "TCM $name Telegram from $id blocked.";
} else {
Dispatch($hash, "EnOcean:$packetType:$org:$d1:$id:$status", undef);
}
}
}
$data = $rest;
}
Dann muss folgende Hash Kontakte noch um die drei Keys 8B05, 8B06 und 8B07 erweitert werden:
# Parse Table TCM 120
my %parsetbl120 = (
"8B05" => { msg=>"OK" },
"8B06" => { msg=>"OK" },
"8B07" => { msg=>"OK" },
"8B08" => { msg=>"ERR_SYNTAX_H_SEQ" },
...
Nun speichern und nach einem shutdown restart erkennt FHEM eine ganze Reihe neuer Switche und es werden defines folgender Art
für alle 14er Aktoren generiert:
define EnO_switch_00000007 EnOcean 00000007
attr EnO_switch_00000007 IODev TCM120
attr EnO_switch_00000007 room EnOcean
attr EnO_switch_00000007 subType switch
define FileLog_EnO_switch_00000007 FileLog ./log/EnO_switch_00000007-%Y.log EnO_switch_00000007
attr FileLog_EnO_switch_00000007 logtype text
attr FileLog_EnO_switch_00000007 room EnOcean
ACHTUNG: dies sind keine Funksensoren (Taster) sondern diese Objekte repräsentieren den Status eines Autors mit den Zuständen
"pressed" oder "released". Mit eventMap lässt sich dieser kosmetischer Fehler leicht anpassen.
ACHTUNG:
steht der Drehschalter des FAM14 auf Pos 4 erhält man für jeden der eben generierten "Switche" pro Sekunde 1 - 2 Events.
Man sollte daher die generierten Switche um folgendes Attribut ergänzen:
attr EnO_switch_00000007 event-on-change-reading state,buttons,channelA,channelB
So dass nur noch für Status-Änderungen ein Event generiert wird.
Der Wechselstromzähler FWZ14 verwendet ebenfalls den bisher nicht als RMT unterstützten Telegrammtyp 07.
Auch diese Zähler lassen sich nun über das FGW14 in FHEM integrieren. Allerdings unterstützt das 10_Enocean.pm Modul diesen Typ noch nicht.
Leistung, Energie und Seriennummer werden beim FWZ14 leider anders kodiert als bei den durch 10_Enocean.pm mit subType=autoMeterReading.01 unterstützten Zählern.
Folgende Definition führt zwar zu einer korrekten Dekodierung der Energie, Leistung und Seriennummer werden jedoch falsch dekodiert:
define FWZ14_STROMZAEHLER EnOcean 00000009
attr FWZ14_STROMZAEHLER IODev TCM120
attr FWZ14_STROMZAEHLER event-on-change-reading state
attr FWZ14_STROMZAEHLER manufID 00D
attr FWZ14_STROMZAEHLER room EnOcean
attr FWZ14_STROMZAEHLER subType autoMeterReading.01
attr FWZ14_STROMZAEHLER verbose 3
define FL_FWZ14_STROMZAEHLER FileLog ./log/FL_FWZ14_STROMZAEHLER-%Y.log FWZ14_STROMZAEHLER
attr FL_FWZ14_STROMZAEHLER logtype text
attr FL_FWZ14_STROMZAEHLER room EnOcean
Mehr zur korrekten Dekodierung der FWZ14 Telegramme in einem separaten Beitrag.
Ich würde mich freuen, wenn der TCM12 Modul-Maintainer die von mir hier geschilderten Erweiterungen prüft und in das offizielle 00_TCM.pm Release aufnimmt.
Viele Grüße,
Guido Carls
Hört sich gut an. Die Ergänzungen können gerne übernommen werden. Ich kann aber leider nichts zu Tests beitragen. Bitte deshalb die ergänzte 00_TCM Datei zusenden. Bitte auch die dazugehörige commandref Einträge erstellen bzw. ergänzen. Vielleicht wäre ein entsprechender WIKI-Artikel zusätzlich sinnvoll.
P. S. Wurden bereits Test vorgenommen, ob die TCM120 Transceiver nach der Änderung noch einwandfrei arbeiten?
Hallo,
ich hab in der Firma einen RasPi, ein EnOceanPi, ein FAM14 und einige FUD14 zum testen rumliegen.
Wenn ich nur noch zusätzlich ein FGW14 brauche lässt sich das ohne Probleme machen.
Grüße
Nein, mangels TCM120 Transceiver konnte ich das nicht testen.
Ich hab das Ganze in folgender Konfiguration getestet:
nanosG20 mit Debian Lenny
Eltako FAM14 getestet in Pos 2 und Pos 4, Eltako FGW14 im BS14 Modus (57600 bit/s) via RS232 an meinem nanosG20 und in FHEM als TCM120 konfiguriert, FWZ14 Wechselstromzähler, FMH8 Fernbedienung, FT55 Funktater, FSR14-4 4-fach Relais-Aktor, FSB14 Rollladenaktor, FSU14 Displayschaltuhr, FTS12EM über ein zweites FGW14.
VG, Guido
Hallo,
wie bereits im ersten Beitrag geschrieben, kann man leider mit subType=autoMeterReading.01FWZ14 Telegramme nicht vollständig korrekt dekodieren.
Dafür ist in 10_Enocean.pm eine Dekodierung gem folgender Anleitung notwendig.
ORG = 0x07
Data_byte3 bis Data_byte1 bilden eine 24Bit binär codierte Zahl
Data_byte3 = Data_byte2 = Data_byte1 = Data_byte0 =
Data Byte 3 (MSB)
Data Byte 2
Data Byte 1 (LSB)
DB0_Bit4 = Tarifumschaltung
(0 = Normaltarif, 1= Nachttarif)
DB0_Bit3 = LRN Button (0 = Lerntelegramm, 1 = Datentelegramm)
DB0_Bit2 = Umschaltung Dateninhalt: 1 = Augenblicksleistung in Watt,
0 = Zählerstand in 0,1KW/h
DB0_Bit1 = 0 (fix)
DB0_Bit0 = 1 (fix)
Mögliche Werte im Datentelegramm:
DB0 = 0x09 -> Zählerstand Normaltarif in 0,1KW/h DB0 = 0x19 -> Zählerstand Nachttarif in 0,1KW/h DB0 = 0x0C -> Augenblicksleistung in W, Normaltarif aktiv
DB0 = 0x1C -> Augenblicksleistung in W, Nachttarif aktiv
Lerntelegramm DB3..DB0: 0x48, 0x08, 0x0D, 0x80 (wird bei jedem Power-up einmal gesendet)
ID = Base-ID des FAM14 + Geräteadresse des DSZ14(W)DRS Weiterhin wird alle 10 Minuten die Zähler-Seriennummer, welche auf dem Zähler aufgedruckt ist, gesendet.
Die Daten sind in 2 aufeinanderfolgende Telegramme aufgeteilt.
1. Teil:
2. Teil:
DB0 = 0x8F -> Zähler Seriennummer = S-AABBCC (A,B,C = 0..9)
DB1 = 0x00 -> die ersten 2 Ziffern der Seriennummer in DB3
DB2 = 0x00
DB3 = AA
DB0 = 0x8F -> Zähler Seriennummer = S-AABBCC (A,B,C = 0..9)
DB1 = 0x01 -> die letzten 4 Ziffern der Seriennummer in DB2 und DB3
DB2 = BB DB3 = CC
VG, Guido
Zitat von: g.carls am 17 März 2014, 07:30:16
Hallo,
wie bereits im ersten Beitrag geschrieben, kann man leider mit subType=autoMeterReading.01FWZ14 Telegramme nicht vollständig korrekt dekodieren.
Dafür ist in 10_Enocean.pm eine Dekodierung gem folgender Anleitung notwendig.
ORG = 0x07
Data_byte3 bis Data_byte1 bilden eine 24Bit binär codierte Zahl
Data_byte3 = Data_byte2 = Data_byte1 = Data_byte0 =
Data Byte 3 (MSB)
Data Byte 2
Data Byte 1 (LSB)
DB0_Bit4 = Tarifumschaltung
(0 = Normaltarif, 1= Nachttarif)
DB0_Bit3 = LRN Button (0 = Lerntelegramm, 1 = Datentelegramm)
DB0_Bit2 = Umschaltung Dateninhalt: 1 = Augenblicksleistung in Watt,
0 = Zählerstand in 0,1KW/h
DB0_Bit1 = 0 (fix)
DB0_Bit0 = 1 (fix)
Mögliche Werte im Datentelegramm:
DB0 = 0x09 -> Zählerstand Normaltarif in 0,1KW/h DB0 = 0x19 -> Zählerstand Nachttarif in 0,1KW/h DB0 = 0x0C -> Augenblicksleistung in W, Normaltarif aktiv
DB0 = 0x1C -> Augenblicksleistung in W, Nachttarif aktiv
Lerntelegramm DB3..DB0: 0x48, 0x08, 0x0D, 0x80 (wird bei jedem Power-up einmal gesendet)
ID = Base-ID des FAM14 + Geräteadresse des DSZ14(W)DRS Weiterhin wird alle 10 Minuten die Zähler-Seriennummer, welche auf dem Zähler aufgedruckt ist, gesendet.
Die Daten sind in 2 aufeinanderfolgende Telegramme aufgeteilt.
1. Teil:
2. Teil:
DB0 = 0x8F -> Zähler Seriennummer = S-AABBCC (A,B,C = 0..9)
DB1 = 0x00 -> die ersten 2 Ziffern der Seriennummer in DB3
DB2 = 0x00
DB3 = AA
DB0 = 0x8F -> Zähler Seriennummer = S-AABBCC (A,B,C = 0..9)
DB1 = 0x01 -> die letzten 4 Ziffern der Seriennummer in DB2 und DB3
DB2 = BB DB3 = CC
Das ist so umgesetzt. Wahrscheinlich aber noch nicht fehlerfrei. Was funktioniert denn konkret nicht?
Hallo Klaus,
mir wurden innerhalb von 1 Sekunde zwei Leistungswerte (power) mit Werten von über 3000W und über 7000W signalisiert, obwohl kein Verbraucher eingeschaltet war.
Da der FWZ14 die Seriennummer in zwei aufeinanderfolgenden Telegrammen versendet, vermute ich, dass die Serienummer hier nicht korrekt dekodiert wird und diese Telegramme alle 10min zu diesen kuriosen Leistungswerten führen.
Gem. folgendem Dokument
http://www.eltako.com/fileadmin/downloads/de/Datenblatt/Funktelegramme.pdf (http://www.eltako.com/fileadmin/downloads/de/Datenblatt/Funktelegramme.pdf)
ist auch genau das der Unterschied zwischen den Zählern FSS12,FWZ12,FWZ61 und dem FWZ14.
Die Herausforderung im Enocean.pm Modul dürfte nun darin bestehen, aus zwei aufeinanderfolgenden Seriennummern Events, die Teil 1 und Teil 2 der kompletten Seriennummer enthalten, ein Seriennummern reading mit der vollständigen Seriennummer zu erzeugen.
Im ersten Step wäre es schon hilfreich, wenn die Seriennummern Events nicht als power Reading signalisiert werden.
VG, Guido
Zitat von: g.carls am 17 März 2014, 12:53:35
mir wurden innerhalb von 1 Sekunde zwei Leistungswerte (power) mit Werten von über 3000W und über 7000W signalisiert, obwohl kein Verbraucher eingeschaltet war.
Da der FWZ14 die Seriennummer in zwei aufeinanderfolgenden Telegrammen versendet, vermute ich, dass die Serienummer hier nicht korrekt dekodiert wird und diese Telegramme alle 10min zu diesen kuriosen Leistungswerten führen.
Gem. folgendem Dokument
http://www.eltako.com/fileadmin/downloads/de/Datenblatt/Funktelegramme.pdf (http://www.eltako.com/fileadmin/downloads/de/Datenblatt/Funktelegramme.pdf)
ist auch genau das der Unterschied zwischen den Zählern FSS12,FWZ12,FWZ61 und dem FWZ14.
Die Herausforderung im Enocean.pm Modul dürfte nun darin bestehen, aus zwei aufeinanderfolgenden Seriennummern Events, die Teil 1 und Teil 2 der kompletten Seriennummer enthalten, ein Seriennummern reading mit der vollständigen Seriennummer zu erzeugen.
Im ersten Step wäre es schon hilfreich, wenn die Seriennummern Events nicht als power Reading signalisiert werden.
Ob das jetzt eine Herausforderung ist? Das Datenblatt mit den Eltako Funktelegrammen ist mir bekannt. Bisher wurde kein Fehler bzgl. der Dekodierung der Seriennummer gemeldet. Vielleicht hat es aber auch noch niemand genutzt. Für die Fehleranalyse benötige ich möglichst alle Telegrammvarianten (teach-in, Leistung, Energie, Tarifumschaltung, Serien-Nr.) die empfangen werden, das konkret angezeigte Ergebnis und die Konfiguration. Geht über attr <name> verbose 5, list <name>, LOG-Dateien zentral und für das jeweilige Device.
Hier schon einmal die von mir vermuteten Seriennummer Telegramme mit den nicht korrekten power Werten:
2014.03.16 11:53:41 5: TCM TCM120 RAW: A55A8B077000008F00000009009AA55A8B073200018F00000009005DA55A8B0700008409000000090028A55A8B070000000C0000000900A7
2014.03.16 11:53:41 5: TCM120 dispatch EnOcean:1:A5:7000008F:00000009:00
2014.03.16 11:53:41 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:7000008F ID:00000009 STATUS:00
2014.03.16 11:53:41 5: Triggering FWZ14_BRUNNENPUMPE (2 changes)
2014.03.16 11:53:41 5: Notify loop for FWZ14_BRUNNENPUMPE power: 7340.0
2014.03.16 11:53:41 5: TCM120 dispatch EnOcean:1:A5:3200018F:00000009:00
2014.03.16 11:53:41 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:3200018F ID:00000009 STATUS:00
2014.03.16 11:53:41 5: Triggering FWZ14_BRUNNENPUMPE (1 changes)
2014.03.16 11:53:41 5: Notify loop for FWZ14_BRUNNENPUMPE 3276.8
2014.03.16 11:53:41 5: TCM120 dispatch EnOcean:1:A5:00008409:00000009:00
2014.03.16 11:53:41 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:00008409 ID:00000009 STATUS:00
2014.03.16 11:53:41 5: Triggering FWZ14_BRUNNENPUMPE (2 changes)
2014.03.16 11:53:41 5: Notify loop for FWZ14_BRUNNENPUMPE energy0: 13.2
2014.03.16 11:53:41 5: TCM120 dispatch EnOcean:1:A5:0000000C:00000009:00
2014.03.16 11:53:41 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:0000000C ID:00000009 STATUS:00
2014.03.16 11:53:41 5: Triggering FWZ14_BRUNNENPUMPE (1 changes)
2014.03.16 11:53:41 5: Notify loop for FWZ14_BRUNNENPUMPE 0.0
und 10min später:
2014.03.16 12:03:30 5: TCM TCM120 RAW: A55A8B077000008F00000009009AA55A8B073200018F00000009005D
2014.03.16 12:03:30 5: TCM120 dispatch EnOcean:1:A5:7000008F:00000009:00
2014.03.16 12:03:30 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:7000008F ID:00000009 STATUS:00
2014.03.16 12:03:30 5: Triggering FWZ14_BRUNNENPUMPE (1 changes)
2014.03.16 12:03:30 5: Notify loop for FWZ14_BRUNNENPUMPE 7340.0
2014.03.16 12:03:30 5: TCM120 dispatch EnOcean:1:A5:3200018F:00000009:00
2014.03.16 12:03:30 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:3200018F ID:00000009 STATUS:00
2014.03.16 12:03:30 5: Triggering FWZ14_BRUNNENPUMPE (1 changes)
2014.03.16 12:03:30 5: Notify loop for FWZ14_BRUNNENPUMPE 3276.8
2014.03.16 12:03:31 5: TCM TCM120 RAW: A55A8B0700008409000000090028
2014.03.16 12:03:31 5: TCM120 dispatch EnOcean:1:A5:00008409:00000009:00
2014.03.16 12:03:31 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:00008409 ID:00000009 STATUS:00
2014.03.16 12:03:33 5: TCM TCM120 RAW: A55A8B070000000C0000000900A7
2014.03.16 12:03:33 5: TCM120 dispatch EnOcean:1:A5:0000000C:00000009:00
2014.03.16 12:03:33 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:0000000C ID:00000009 STATUS:00
2014.03.16 12:03:33 5: Triggering FWZ14_BRUNNENPUMPE (1 changes)
2014.03.16 12:03:33 5: Notify loop for FWZ14_BRUNNENPUMPE 0.0
Hier dann nochmals echte power Messungen:
2014.03.16 12:10:50 5: TCM TCM120 RAW: A55A8B0700031C0C0000000900C6
2014.03.16 12:10:50 5: TCM120 dispatch EnOcean:1:A5:00031C0C:00000009:00
2014.03.16 12:10:50 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:00031C0C ID:00000009 STATUS:00
2014.03.16 12:10:50 5: Triggering FWZ14_BRUNNENPUMPE (1 changes)
2014.03.16 12:10:50 5: Notify loop for FWZ14_BRUNNENPUMPE 796.0
2014.03.16 12:11:18 5: TCM TCM120 RAW: A55A8B070001BA0C000000090062
2014.03.16 12:11:18 5: TCM120 dispatch EnOcean:1:A5:0001BA0C:00000009:00
2014.03.16 12:11:18 5: EnOcean FWZ14_BRUNNENPUMPE PacketType:1 RORG:A5 DATA:0001BA0C ID:00000009 STATUS:00
2014.03.16 12:11:18 5: Triggering FWZ14_BRUNNENPUMPE (1 changes)
2014.03.16 12:11:18 5: Notify loop for FWZ14_BRUNNENPUMPE 442.0
Manchmal kommt es auf die Reihenfolge der if-Abfragen an! Mit dem morgigen Update sollte es jetzt auch mit der Seriennummer passen.
Anbei das TCM-Modul mit der im 1 Beitrag beschriebenen Unterstützung der RMT Telegramme.
VG, Guido
Zitat von: g.carls am 18 März 2014, 21:58:35
Anbei das TCM-Modul mit der im 1 Beitrag beschriebenen Unterstützung der RMT Telegramme.
Danke für den ergänzten Quellcode. M. E. ist es aber notwendig, auch die Dokumentation dazu zu erweitern. Ein Forumsartikel, der später kaum auffindbar sein wird. ist zu wenig. Eine "versteckte" Funktion, ist für andere Fhem Nutzer sinnlos. Ich bitte deshalb auch um eine Beschreibung der Funktionen und Einstellparameter. Hierzu gibt es am Ende der 00_TCM-Datei einen HTML-Abschnitt, der automatisch in die commandref übernommen wird. Bitte hier die wesentlichen Neuerungen aufnehmen.
Zitat von: klaus.schauer am 17 März 2014, 19:27:43
Manchmal kommt es auf die Reihenfolge der if-Abfragen an! Mit dem morgigen Update sollte es jetzt auch mit der Seriennummer passen.
Hallo Klaus,
herzlichen Dank für Dein enocean Update.
Ich habe dein Update getestet:
Die Seriennummern-Telegramme werden nun nicht mehr als power Reading signalisiert. Das ist sehr gut!
Bei mir wird allerdings immer die Seriennummer 1 angezeigt und dieser Wert ist falsch.
Ich komme zu folgendem Ergebnis:
SN-Telegramm 1: RORG:A5 DATA:7000008F ID:00000009 STATUS:00
SN Telegramm 2: RORG:A5 DATA:3200018F ID:00000009 STATUS:00
8F in Datenbyte DB0 (von rechts nach links gezählt) in beiden Telegrammen bedeutet, dass es sich um ein Seriennummer Telegramm handelt
Der Wert 00 in DB1 bedeutet dass es sich um das erste von 2 Seriennummern-Telegrammen handelt,
Der Wert 01 in DB1 bedeutet, dass es sich um das 2. Telegramm handelt.
Die Seriennummer setzt sich nun aus
- DB3 aus Telegramm 1 und
- DB2 und DB3 aus Telegramm 2 zusammen.
Damit lautet die Seriennummer S-700032.
Viele Grüße,
Guido
Zitat von: g.carls am 19 März 2014, 19:45:56
Die Seriennummern-Telegramme werden nun nicht mehr als power Reading signalisiert. Das st sehr gut!
Bei mir wird allerdings immer die Seriennummer 1 angezeigt und dieser Wert ist falsch.
Was ist auf dem Zähler aufgedruckt: S-......
Zitat
Korrekt muss die Seriennummer wie folgt ermittelt werden:
SN-Telegramm 1: RORG:A5 DATA:7000008F ID:00000009 STATUS:00
SN Telegramm 2: RORG:A5 DATA:3200018F ID:00000009 STATUS:00
8F in Datenbyte DB0 (von rechts nach links gezählt) in beiden Telegrammen sagt uns, dass es sich um ein Seriennummer Telegramm handelt
Der Wert 00 in DB1 sagt uns dass es sich um das erste von 2 Seriennummern-Telegrammen handelt,
Der Wert 01 in DB1 sagt uns, dass es sich um das 2. Telegramm handelt.
Die Seriennummer setzt sich nun aus
- DB3 aus Telegramm 1 und
- DB2 und DB3 aus Telegramm 2 zusammen.
Damit lautet die Seriennummer 0x700032.
Die Darstellung sagt
mir nichts neues. Bei der Seriennr. leider falsch gedacht! Es ist sicher nicht 0x700032.
Zitat
Da scheint also in der Seriennummern-Ermittlung in enocean.pm noch ein Fehler zu sein.
Wirklich? Damit ich weiterkomme, brauche ich
konkret die Fhem Ausgaben, insbesondere jeweils die kompletten LOGs und list <device>, manchmal eben mehrfach.
(1) der rot markierte Index In der Bedingung für "autoMeterReading.01" muss 1 und nicht 0 sein,
denn db0 wird ja vorher schon auf 8F geprüft. D.h., es wird immer der else Zweig abgearbeitet.
(2) Die beiden printf müssen sprintf sein,
(3) Im (s)printf muss dann noch das %4c durch %4s ersetzt werden, da sonst der erste Teil der Seriennummer als ASCII Code interpretiert wird und je nach Inhalt nicht lesbar ist.
im Eventlog erhalte ich nach diesen Korrekturen dann folgende Ausgaben:
2014-03-20 07:31:05 EnOcean C_BRUNNENPUMPE serialNumber: S-70
2014-03-20 07:31:06 EnOcean C_BRUNNENPUMPE serialNumber: S-700032
2014-03-20 07:31:07 EnOcean C_BRUNNENPUMPE energy0: 13.3
Damit in den FileLogs und in DbLog nicht alle 10min die verstümmelte Seriennummer ("S-70") auftaucht möchte ich noch gerne den grün markierten Code hinzufügen, der analog zu Deiner Lösung zur Verarbeitung der hinteren Digits sich den Rest der Seriennummer aus dem letzten Reading holt.
Damit erhält man dann folgende Eventlog-Ausgaben:
2014-03-20 08:11:26 EnOcean C_BRUNNENPUMPE serialNumber: S-700032
2014-03-20 08:11:27 EnOcean C_BRUNNENPUMPE serialNumber: S-700032
Macht man diese Anpassung nicht, dann führt
event-on-change-reading zu überflüssigen Events mit kurzzeitig falschen Werten (S-70).
oder bei event-min-interval wird u.U. die ganze Zeit nur S-70 angezeigt.
Als Reading wird dann
serialNumber S-700032 2014-03-20 07:31:06
in FHEM angezeigt.
Hier der Quellcode mit den Hinweisen auf die Fehler:
if ($db[0] == 0x8F && $manufID eq "00D") {
# Eltako, read meter serial number
my $serialNumber;
if ($db[0] == 0) {
$serialNumber = substr(ReadingsVal($name, "serialNumber", "S-------"), 4, 4);
# first 2 digits of the serial number
$serialNumber = printf "S-%01x%01x%4s", $db[3] >> 4, $db[3] & 0x0F, $serialNumber;
} else {
# last 4 digits of the serial number
$serialNumber = substr(ReadingsVal($name, "serialNumber", "S---"), 0, 4);
$serialNumber = printf "%4c%01x%01x%01x%01x", $serialNumber,
$db[2] >> 4, $db[2] & 0x0F, $db[3] >> 4, $db[3] & 0x0F;
}
Anbei das korrigierte EnOcean Modul.
Viele Grüße,
Guido
Ich freue mich, dass Du dir den Quellcode angesehen hast. Vier Augen sehen mehr als zwei. Leider finden sich in dem Fhem Projekt kaum Leute, die sich intensiv an der Qualitätssicherung beteiligen.
Ob dazu allerdings oberlehrerhafte Bemerkungen wie "Ja, da sind 4 Fehler in 7 Zeilen Code" oder "Der Wert 01 in DB1 sagt uns, dass..." notwendig sind, bezweifle ich.
Sorry, das war nicht meine Intention.
Fehlerberichtigung zur Anzeige der Seriennummer steht ab morgen per update zur Verfügung.
Zitat von: klaus.schauer am 19 März 2014, 10:44:11
Danke für den ergänzten Quellcode. M. E. ist es aber notwendig, auch die Dokumentation dazu zu erweitern. Ein Forumsartikel, der später kaum auffindbar sein wird. ist zu wenig. Eine "versteckte" Funktion, ist für andere Fhem Nutzer sinnlos. Ich bitte deshalb auch um eine Beschreibung der Funktionen und Einstellparameter. Hierzu gibt es am Ende der 00_TCM-Datei einen HTML-Abschnitt, der automatisch in die commandref übernommen wird. Bitte hier die wesentlichen Neuerungen aufnehmen.
Ich habe etwas Dokumentation zu meinen Anpassungen im TCM Modul ergänzt. Anbei das um die Dokumentation ergänzte Modul.
Neue TCM-Datei V5270 ist eingestellt. Ich musste die Ergänzungen jetzt in die Version 5263 von TCM nachträglich einarbeiten. Die Arbeiten an den Dateien haben sich überschnitten.
Derzeit kann man die Stati der Eltako-Geräte am 14er-Bus auslesen. Wäre über diese Schnittstelle grundsätzlich später auch eine Steuerung der Geräte am Bus möglich? Falls ja, wird daran gearbeitet?
Können über diese Lösung u. U. auch zusätzlich Telegramme von anderen Devices außerhalb des Busses empfangen werden oder sogar dorthin gesendet werden?
Das EnOcean ESP2 ist ja zwischenzeitlich in die Jahre gekommen. Kann alternativ auch das aktuelle ESP3 über das Gateway verwendet werden?
Ich habe beide Module getestet. Funktionieren beide einwandfrei. Besten Dank für die Anpassungen!
Zu den Fragen:
(1) Steuern anderer Module mit FGW14:
Bisher ist mir das Steuern anderer Geräte noch nicht gelungen:
Das FAM14 Modul vergibt an andere Module am Bus die Ids. D.h., man muss jeden Busteilnehmer am FAM14 anmelden und dieses Modul erhält dann ein oder mehrere Ids.
Das automatische Auslesen der BaseId via FHEM funktioniert leider nicht.
Mit der PCT16 Software von Eltako kann man allerdings die bereits vergebenen Ids am Bus ermitteln und die BaseId auslesen.
U.U. gelingt das Schreiben, wenn man die BaseId auf diesem Weg ermittelt und manuell in die fhem.cfg einträgt. Man muss dann allerdings beachten, dass man keine ID verwendet die das FAM-Modul an andere Module auf dem Bus bereits vergeben hat.
Das habe ich bisher noch nicht getestet.
(2) Empfang von Telegrammen ausserhalb des Busses
Ja das geht. Das FAM14 Modul schreibt die über EnOcean-Funk empfangenen Telegramme auf den Bus und diese erhält auch FHEM über das FGW14.
Das FAM14 leitet leider nur bestimmte Telegramme vom Bus in das Funknetz weiter jedoch nicht alle um so wohl Loops zu vermeiden.
(3) ESP3 mit FGW14
Nein. Das FGW14 unterstützt nur ESP2 mit zwei unterschiedlichen Baudraten: 9600 und 57600. Eltako nennt das dann BR12 und BR14.
VG, Guido
Steuerung von Modulen am RS485 Bus via TCM120 über das RS232 Gateway FGW14 von Eltako geht!
Damit ist eine vollwertige Integration des Eltako RS485 Buses in FHEM ohne Funkschnittstelle möglich.
Ich habe zu Punkt (1) meines letzten Posts einen Test mit einem FSR14-4x von Eltako machen können:
Man muss keine vom FAM14 vergebenen IDs verwenden, sondern man kann sich frei irgendwelche IDs auswählen.
Diese sollten nur nicht im Bereich der IDs des FAM14 liegen.
Die folgende Definition wertet die Statusmeldungen vom FSR14-4x aus, welcher die ID 00000002 verwendet.
Für Schaltaktionen via FHEM muss man eine eigene ID via subDef vorgeben (attr B_HOF_SUED_WANDLAMPE subDef 00001002).
Für Schaltaktionen via FHEM habe ich in Kanal 1 des FSR14 Aktors diese ID (00001002) eingelernt (set B_HOF_SUED_WANDLAMPE teach) während der mittlere Drehschalter des FSR-14 auf Kanal 1 steht und der untere auf LRN. Die Stellung des oberen Drehschalters spielt keine Rolle. On (B0) und Off (BI) werden beide automatisch eingelernt.
Nur wenn ich eine eventMap auf On und off definiert (attr B_HOF_SUED_WANDLAMPE eventMap BI:off B0:on) habe, erhalte ich Fehlermeldungen, da die FHEM Buttons trotzdem BI und B0 verwenden. Vielleicht ist dies aber auch ein Konfigurationsfehler meinerseits.
Lässt man eventMap weg und lässt es damit bei BI und B0 funktioniert alles.
#
# B_HOF_SUED_WANDLAMPE
#
# B0: Lampe an
# BI: Lampe aus
#
define B_HOF_SUED_WANDLAMPE EnOcean 00000002
attr B_HOF_SUED_WANDLAMPE IODev TCM120
attr B_HOF_SUED_WANDLAMPE alias Hof Wandlampe Süd
attr B_HOF_SUED_WANDLAMPE event-on-change-reading state,buttons,channelA,channelB
#attr B_HOF_SUED_WANDLAMPE eventMap BI:off B0:on
attr B_HOF_SUED_WANDLAMPE group Beleuchtung
attr B_HOF_SUED_WANDLAMPE gwCmd switching
attr B_HOF_SUED_WANDLAMPE room 6.01 Garten
attr B_HOF_SUED_WANDLAMPE subDef 00001002
attr B_HOF_SUED_WANDLAMPE subType gateway
#attr B_HOF_SUED_WANDLAMPE subType switch
Soll ich einen entsprechenden Beitrag zur Dokumentation für das TCM Modul und/oder ggf für das Enocean Modul verfassen?
VG, Guido
Im Wesentlichen müssen die Unterschiede bei der Vergabe der Fhem SenderIDs i. d. R. über subDef und den Aufbau der SenderIDs des Eltako-Busses beschrieben werden. Das würde gut als zusätzlicher Abschnitt in den allgemeinen Text zu Beginn des EnOcean Abschnittes in der commandref passen.
Vielleicht wäre auch ein Wiki-Beitrag über die gesamte Konfiguration und die Besonderheiten hilfreich. Durch die einzelnen Textpasssagen in TCM und EnOcean kann man schwer einen Gesamtüberblick erhalten.