Eltako 14er Serie via FGW14 inkl Statusnachrichten von bid. Aktoren an FHEM

g.carls · 16 März 2014, 19:28:04

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

klaus.schauer · 16 März 2014, 19:58:38

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?

Puschel74 · 16 März 2014, 20:15:43

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

g.carls · 16 März 2014, 21:11:30

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

g.carls · 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

VG, Guido

klaus.schauer · 17 März 2014, 07:35:58

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?

g.carls · 17 März 2014, 12:53:35

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
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

klaus.schauer · 17 März 2014, 14:42:43

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
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.

g.carls · 17 März 2014, 16:51:45

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

g.carls · 17 März 2014, 16:57:41

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

klaus.schauer · 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.

g.carls · 18 März 2014, 21:58:35

Anbei das TCM-Modul mit der im 1 Beitrag beschriebenen Unterstützung der RMT Telegramme.

VG, Guido

klaus.schauer · 19 März 2014, 10:44:11

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.

g.carls · 19 März 2014, 19:45:56

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

klaus.schauer · 19 März 2014, 20:36:10

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.