Eltako FWZ12-16A

[aicgazi]

Config:
Aktuelles Fhem linux 12.01.2013
TCM310 ( und 2 CULS und FHZ1300 )

Habe mir das FWZ12-16A besorgt.
Nach dem Stromanschluß fängt das Teil "ganz normal" an zu senden
Nach eine unbestimmten Zeit werden keine Telegramme mehr empfangen.
wobei von anderen EnOcean Geräten Daten empfangen werden können.

Hat da jemand ne Idee ( oder ist der FWZ einfach nur kaputt ? )

mfg


----
2013-01-12_01:33:45 L1 teach-in: class A5.12.01 (manufacturer: Eltako)
2013-01-12_01:33:45 L1 0
2013-01-12_01:33:45 L1 sensor1: 0
2013-01-12_01:33:45 L1 sensor2: 0
2013-01-12_01:33:45 L1 sensor3: 24
2013-01-12_01:33:45 L1 D3: 1
2013-01-12_01:33:45 L1 D2: 0
2013-01-12_01:33:45 L1 D1: 0
2013-01-12_01:33:45 L1 D0: 1
2013-01-12_01:33:45 L1 0
2013-01-12_01:33:45 L1 sensor1: 0
2013-01-12_01:33:45 L1 sensor2: 0
2013-01-12_01:33:45 L1 sensor3: 0
2013-01-12_01:33:45 L1 D3: 1
2013-01-12_01:33:45 L1 D2: 1
2013-01-12_01:33:45 L1 D1: 0
2013-01-12_01:33:45 L1 D0: 0
2013-01-12_01:34:15 L1 0
2013-01-12_01:34:15 L1 sensor1: 0
2013-01-12_01:34:15 L1 sensor2: 0
2013-01-12_01:34:15 L1 sensor3: 10
2013-01-12_01:34:15 L1 D3: 1
2013-01-12_01:34:15 L1 D2: 1
2013-01-12_01:34:15 L1 D1: 0
2013-01-12_01:34:15 L1 D0: 0
2013-01-12_01:43:34 L1 0
2013-01-12_01:43:34 L1 sensor1: 0
2013-01-12_01:43:34 L1 sensor2: 0
2013-01-12_01:43:34 L1 sensor3: 24
2013-01-12_01:43:34 L1 D3: 1
2013-01-12_01:43:34 L1 D2: 0
2013-01-12_01:43:34 L1 D1: 0
2013-01-12_01:43:34 L1 D0: 1
2013-01-12_01:43:34 L1 0
2013-01-12_01:43:34 L1 sensor1: 0
2013-01-12_01:43:34 L1 sensor2: 0
2013-01-12_01:43:34 L1 sensor3: 10
2013-01-12_01:43:34 L1 D3: 1
2013-01-12_01:43:34 L1 D2: 1
2013-01-12_01:43:34 L1 D1: 0
2013-01-12_01:43:34 L1 D0: 0
----

Wenn D0 = 0 dann ist das wohl Sensor3 der Zählerstand in Sensor3/10 KWh ( eine Nachkommastelle )
Wenn D0 = 1 dann ist das wohl Sensor3 der augenblickliche Verbrauch in W


---
Beschreibung:
ORG = 0x07
Data_byte3 bis Data_byte1 bilden eine 24Bit Binär Codierte Zahl
Data_byte3 = Data Byte 3 (MSB) 0...16777215
Data_byte2 = Data Byte 2 0...16777215
Data_byte1 = Data Byte 1 (LSB) 0...16777215
Data_byte0 = 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 (fi x)
DB0_Bit0 = 1 (fi x)
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)

[rudolfkoenig]

Ein FWZ12-16A kenne ich nicht, aber ich wuerde im "verklemmten" Zustand versuchen, ob es auf "get fwzName idbase" reagiert, um das Problem einzugrenzen.

[aicgazi]

Der FWZ12-16A ist ein Eltako FunkWechselstromZähler für eine Phase 16 A

bei
define EUL TCM 310 /dev/ttyTCM0@57600
define L1 EnOcean 00860E41
attr L1 subType sensor

funktioiniert im "verklemmten" Zustand
get EUL idbase
BaseId=FFFAAD80,RemainingWriteCycles=0A

ein
get L1 idbase geht ( so wie so ) nicht ( muss ja bei einem Sensor auch nicht sein oder? )

[rudolfkoenig]

Hilft im verklemmten Zustand das abstecken/anstecken der EUL?
Wenn nicht, dann vermute ich ein Problem des Senders.

[aicgazi]

Es ist tatsächlich so, daß ein an und abstecken des TCM310 dannach das Funktelegramm wieder aufnimmt.
Ein "get tcm310 irgendwas" ( z.B. get TCM310 idbase ) hilft nicht.

seltsamerweise funktioniert ein EnOcean Schalter und der PM101 auch im "verklemmten" Zustand.

hm. evtl. kann man das über die firmware noch optimieren.
Kann ich dabei noch was helfen ?

[rudolfkoenig]

MWn ist das EUL Firmware nur fuer Seriell->USB Wandlung zustaendig, der Rest wird in den abgeschlossenen TCM310 Modul gemacht. Hilft ein "modify EUL 310 /dev/ttyTCM0@57600" ? Dieses Befehl schliesst /dev/ttyTCM0 und oeffnet es wieder. Es waere auch interessant zu sehen, ob das Problem auch mit einem anderen USB-Stick oder FWZ12 besteht. Ansonsten kann man entweder hightech auspacken (Funksignale protokollieren) oder EnOcean/Eltako fragen.

[aicgazi]

OK mit dem modify kann man den TCM310 tatsächlich "aufwecken"

Piezzo Schalter WS R101 von Omnio funktioniert nicht
modfiy EUL 310 /dev/ttyACM0@57600
Piezzo Schalter funktioniert.

Die Funkinformationen vom FWZ12-16A kommen allerdings nicht durch.
( irgendwann kommt dann ein paket aber ich hab noch nicht rausgefunden welche Bedingungen das begünstigen bzw. verhindern. Einstreueffekt vom LTE kann ich glaub ich ausschliessen das modem hab ich auch schon ausgemacht..)

Der PM101 liegt neben dem FWZ12-16A und sendet fleissig vor sich hin
( btw. kannst du den Code vom PM101 in die "A5" if-Schleife legen - ich hab das kurz vor dem teach-in reingemacht damit es funktioniert - guckst du:)

----------- CODE
    if(($db_0 & 0x08) == 0) {
      if($db_0 & 0x80) {
        my $fn = sprintf "%02x", ($db_3>>2);
        my $tp = sprintf "%02X", ((($db_3&3) << 5) | ($db_2 >> 3));
        my $mf = sprintf "%03X", ((($db_2&7) << 8) | $db_1);
        $mf = $EnO_manuf{$mf} if($EnO_manuf{$mf});
        my $m = "teach-in:class A5.$fn.$tp (manufacturer: $mf)";
        Log 1, $m;
        push @event, "3:$m";
        my $st = "A5.$fn.$tp";
        $st = $EnO_subType{$st} if($EnO_subType{$st});
        $attr{$name}{subType} = $st;

        if("$fn.$tp" eq "20.01" && $iohash->{pair}) {      # MD15
          select(undef, undef, undef, 0.1);                # max 10 Seconds
          EnOcean_A5Cmd($hash, "800800F0", "00000000");
          select(undef, undef, undef, 0.5);
          EnOcean_MD15Cmd($hash, $name, 128); # 128 == 20 degree C
        }

      } elsif($model eq "PM101") {
         ####################################
         # Ratio Presence Sensor Eagle PM101, code by aicgazi
         ####################################
         my $lux = sprintf "%3d", $db_2;
         # content  of $db_2 is the illuminance where max value 0xFF stands for 1000 lx
         $lux = sprintf "%4d", ( $lux * 1000 / 255 ) ;
         push @event, "3:brightness:$lux";
         push @event, "3:channel1:" . ($db_0 & 0x01 ? "on" : "off");
         push @event, "3:channel2:" . ($db_0 & 0x02 ? "on" : "off");

      } else {
        push @event, "3:teach-in:no type/manuf. data transmitted";

      }
------------------ Code

[klaus.schauer]

Welche Aufgabe soll der zusätzliche Programmcode für die Abfrage von PM-101 Meldungen in der Teach-In Prozedure haben? Die gleiche Abfrage steht doch weiter unten nochmals (an der richtigen Stelle)!

Ich bin gerade dabei die automatiche Erkennnung von devices nicht nur für das Gerät MD15 zu ermöglichen. Hoffentlich gelingt es. Leider habe ich für das Gerät PM-101 bisher nicht herausfinden können, welches EEP verwendet wird. So richtig scheinen die Standardprofile nicht zu passen. Bei der Firma Omnio bin ich auch nicht fündig geworden.

[krikan]

Hallo Klaus,
nach meiner dunkelen Erinnerung entspricht der PM101 keinem Standard-EEP, was sich mit anscheinend mit Deiner Beobachtung deckt. Schau Dir mal Seite 5 der dieses Dokumentes an: http://www.omnio.ch/content-en/downloads/Betriebsanleitungen/2902000_Betriebsanleitung_ea.pdf Das sollte die Telegrammbeschreibung sein.
Gruß, Christian

[klaus.schauer]

Der PM-101 sollte aber eine EEP und eine ManufacturerID beim teach-in senden. Damit könnte man das Gerät dann theoretisch verhältnismäßig sicher automatisch anlernen. In der Anleitung steht nichts dazu und leider reagiert Omnio nicht auf meine E-Mail-Anfragen dazu.

[aicgazi]

Wenn das die richtige Stelle ist warum wird die Helligkeitsangabe nur dargestellt wenn der Code an der Stelle steht die ich beschrieben habe ?

btw. das sind beispielhaft ein paar auszüge aus meinem Logfile.
2013.03.01 18:40:30 4: PM101: ORG:A5 DATA:BB08FF03 ID:FF850031 STATUS:00
2013.03.01 18:40:30 4: PM101: ORG:A5 DATA:BB08FF03 ID:FF850031 STATUS:00
2013.03.01 18:52:17 4: PM101_SW: ORG:F6 DATA:70 ID:FF850030 STATUS:10
2013.03.01 18:52:17 4: PM101_SW: ORG:F6 DATA:00 ID:FF850030 STATUS:00
2013.03.01 18:52:19 4: PM101_SW: ORG:F6 DATA:30 ID:FF850030 STATUS:10
2013.03.01 18:52:19 4: PM101_SW: ORG:F6 DATA:00 ID:FF850030 STATUS:00
2013.03.01 18:52:22 4: PM101_SW: ORG:F6 DATA:B0 ID:FF850030 STATUS:10
2013.03.01 18:52:22 4: PM101_SW: ORG:F6 DATA:00 ID:FF850030 STATUS:00
2013.03.01 18:52:24 4: PM101_SW: ORG:F6 DATA:F0 ID:FF850030 STATUS:10
2013.03.01 18:52:25 4: PM101_SW: ORG:F6 DATA:00 ID:FF850030 STATUS:00
2013.03.01 18:52:27 4: PM101: ORG:A5 DATA:CC08FF00 ID:FF850031 STATUS:00
2013.03.01 18:52:27 4: PM101: ORG:A5 DATA:CC08FF00 ID:FF850031 STATUS:00

Die Schaltfunktionen gehen ganz "normal" über die Enocean Schalter programmierung mir einer eigenen ID
Die Helligkeit wird über eine 2.ID gesendet und fällt mir diesem DATA eben in die Schleife oben - aus dem Grund hätte ich das gerne oben stehen, damit ich mir das Modul nicht selbst wieder anpassen muß.
Sollte es programiertechnisch eine bessere Lösung geben, nehme ich die auch gerne an.
Ich möchte nur die Packete von ID FF850031 dekodiert haben.

Was bedeutet EEP ? in dem PDF steht doch wie die Packete gesendete werden und deren Bedeutung ?

mfg

[krikan]

Hallo aicgazi,

aus meiner laienhaften Sicht müsste die Codeposition im aktuellen 10_ENOCEAN.PM richtig sein. Stammt der Ursprungs-Code zum PM101 nicht von Dir und hat das jemals funktioniert?

Deine Änderung verschiebt doch den Code in den Bereich zur Interpretation von Lerntelegrammen. Sendet Dein PM101 vielleicht Lerntelegramme?

Gruß, Christian

[krikan]

Sendet Dein PM101 vielleicht Lerntelegramme?

Zumindest die DATA-Werte Deines Logauszuges sind afaik keine Lern- sondern Standardtelegramme. Dann verstehe ich den Erfolg Deiner Codeänderung und das Problem mit dem Originalcode überhaupt nicht. Hast Du es noch mal mit dem Origial-Code ohne eigene Änderungen probiert.

[krikan]

Sendet Dein PM101 vielleicht Lerntelegramme?

Zumindest die DATA-Werte Deines Logauszuges sind afaik keine Lern- sondern Standardtelegramme. Dann verstehe ich den Erfolg Deiner Codeänderung und das Problem mit dem Originalcode überhaupt nicht. Hast Du es noch mal mit dem Origial-Code ohne eigene Änderungen probiert.

Noch mal in Ruhe Deine Telegramme mit der Betriebsanleitung des PM101 angeschaut und behaupte nun das Gegenteil, da 0 Kennzeichen für Lerntelegramm und nicht 1:

DATA:BB08FF03
     ^^
     Reguläres Telegramm im Normal-Mode
     03 ist binär 00000011; damit ist B3=0 und es handelt sich um ein Lerntelegramm

DATA:CC08FF00
     ^^
     Telegramme im Gehtest-Mode
     00 ist binär 00000000; damit ist B3=0 und es handelt sich um ein Lerntelegramm

Wenn Dein PM101 permanent nur Lerntelegramme sendet, dann wundert es mich nicht, wenn Du derartige Veränderungen am Code vornehmen musst. Ich würde dann aber nicht zwingend auf ein Problem bei FHEM tippen; vor allem wenn ich Deine anderen Funkprobleme anschaue.

Du kannst gerne mal einen längeren Log-Auszug für den PM einstellen.

Gruß, Christian

[harryzz]

sorry for english but i get Eltako FWZ12-65 and found some bugs in 10_EnOcean.pm
on latest dev verion: line 1058 must be :        if ($dataType == 4)
line 1061:          push @event, "3:state:$meterReading";

also i provide gplot file for chart of current consumption and report of Cumulative.