permundo SmartPlug PSC234 wireless relay switch with metering

Begonnen von 50watt, 14 Mai 2014, 21:50:32

Vorheriges Thema - Nächstes Thema

50watt

Permundo SmartPlug PSC234 mit Fhem verwenden:

Das Datenblatt inklusive EEP Beschreibung gibt es hier:
http://www.batterielos.de/shop/media/products/Datasheet-PSC234.pdf

Der SmartPlug ist eine per EnOcean

  • schaltbare Steckdose
  • kein Dimmer
der auch

  • die Leistung
  • den Energieverbrauch
  • die interne Temperatur
  • die Spannung
misst und ausgibt sowie flags für

  • Last an/ausgesteckt
  • Last ein/ausgeschaltet
  • ...
hat.

TeachIn funktioniert:
set TCM teach 60


Den Smartplug in eine Steckdose einstecken:
log (verbose 5):

2014.05.14 21:14:36 5: TCM TCM310_0 RAW: 55000A0701EBA500
2014.05.14 21:14:36 5: TCM TCM310_0 RAW: 55000A0701EBA5000000090186AF830001FFFFFFFF440084
2014.05.14 21:14:36 5: TCM310_0 dispatch EnOcean:1:A5:00000009:0186AF83:00:01FFFFFFFF4400
2014.05.14 21:14:36 1: EnOcean Unknown device with ID 0186AF83 and RORG sensor, please define it.
2014.05.14 21:14:36 2: autocreate: define EnO_sensor_0186AF83 EnOcean 0186AF83 EnOcean:1:A5:00000009:0186AF83:00:01FFFFFFFF4400
2014.05.14 21:14:36 2: autocreate: define FileLog_EnO_sensor_0186AF83 FileLog ./log/EnO_sensor_0186AF83-%Y.log EnO_sensor_0186AF83
2014.05.14 21:14:36 5: TCM TCM310_0 RAW: 55000A0701EBA50000000C0186AF830001FFFFFFFF44004E
2014.05.14 21:14:36 5: TCM310_0 dispatch EnOcean:1:A5:0000000C:0186AF83:00:01FFFFFFFF4400
2014.05.14 21:14:37 5: TCM TCM310_0 RAW: 550009070156D204
2014.05.14 21:14:37 5: TCM TCM310_0 RAW: 550009070156D20460000186AF830001FFFFFFFF44002A
2014.05.14 21:14:37 5: TCM310_0 dispatch EnOcean:1:D2:046000:0186AF83:00:01FFFFFFFF4400


TeachIn mode am PSC234 aktivieren (Knopf 5Sek. drücken, auslassen und wieder 3Sek. drücken)

2014.05.14 21:15:09 5: TCM TCM310_0 RAW: 55000D0701FDD4A0
2014.05.14 21:15:09 5: TCM TCM310_0 RAW: 55000D0701FDD4A0FF33000901D20186AF830001FFFFFFFF490039
2014.05.14 21:15:09 5: TCM310_0 dispatch EnOcean:1:D4:A0FF33000901D2:0186AF83:00:01FFFFFFFF4900
2014.05.14 21:15:09 5: TCM TCM310_0 sending 55000D0701FDD491FF33000901D2FF98A10500030186AF83FF00EC
2014.05.14 21:15:09 5: SW: 55000D0701FDD491FF33000901D2FF98A10500030186AF83FF00EC
2014.05.14 21:15:09 2: EnOcean EnO_sensor_0186AF83 UTE teach-in-response send to 0186AF83
2014.05.14 21:15:09 2: EnOcean EnO_sensor_0186AF83 UTE teach-in EEP D2-01-09 Manufacturer: 033
2014.05.14 21:15:10 5: TCM TCM310_0 RAW: 5500010002650000
2014.05.14 21:15:10 5: TCM TCM310_0 RESPONSE: OK


get <device> measurement all energy
2014.05.14 21:30:08 3: EnOcean EnO_sensor_0186AF83 get 6 30 energy.
2014.05.14 21:30:08 2: EnOcean get EnO_sensor_0186AF83 measurement
2014.05.14 21:30:08 5: TCM TCM310_0 sending 55000807013DD2061EFF98A10500030186AF83FF000B
2014.05.14 21:30:08 5: SW: 55000807013DD2061EFF98A10500030186AF83FF000B
2014.05.14 21:30:08 5: TCM TCM310_0 RAW: 550001000265000055000C070196D20720000000000186AF830001FFFFFFFF4A007A
2014.05.14 21:30:08 5: TCM TCM310_0 RESPONSE: OK
2014.05.14 21:30:08 5: TCM310_0 dispatch EnOcean:1:D2:072000000000:0186AF83:00:01FFFFFFFF4A00


get <device> measurement all power
2014.05.14 21:32:18 3: EnOcean EnO_sensor_0186AF83 get 6 30 power.
2014.05.14 21:32:18 2: EnOcean get EnO_sensor_0186AF83 measurement
2014.05.14 21:32:18 5: TCM TCM310_0 sending 55000807013DD2063EFF98A10500030186AF83FF00F5
2014.05.14 21:32:18 5: SW: 55000807013DD2063EFF98A10500030186AF83FF00F5
2014.05.14 21:32:18 5: TCM TCM310_0 RAW: 550001000265000055000C070196D20760000000000186AF830001FFFFFFFF46000F
2014.05.14 21:32:18 5: TCM TCM310_0 RESPONSE: OK
2014.05.14 21:32:18 5: TCM310_0 dispatch EnOcean:1:D2:076000000000:0186AF83:00:01FFFFFFFF4600

Nun gibt's auch readings für energy0, energyUnits0, power0, powerUnits0 !!

Anstecken einer Last:
2014.05.14 21:34:57 5: TCM TCM310_0 RAW: 55000707017AF610
2014.05.14 21:34:57 5: TCM TCM310_0 RAW: 55000707017AF6100186AF833001FFFFFFFF4700B9
2014.05.14 21:34:57 5: TCM310_0 dispatch EnOcean:1:F6:10:0186AF83:30:01FFFFFFFF4700
2014.05.14 21:34:57 5: TCM TCM310_0 RAW: 55000707017AF600
2014.05.14 21:34:57 5: TCM TCM310_0 RAW: 55000707017AF6000186AF833001FFFFFFFF4000AD
2014.05.14 21:34:57 5: TCM310_0 dispatch EnOcean:1:F6:00:0186AF83:30:01FFFFFFFF4000
2014.05.14 21:34:57 5: TCM TCM310_0 RAW: 550009070156D204
2014.05.14 21:34:57 5: TCM TCM310_0 RAW: 550009070156D20460640186AF830001FFFFFFFF43001A
2014.05.14 21:34:57 5: TCM310_0 dispatch EnOcean:1:D2:046064:0186AF83:00:01FFFFFFFF4300
2014.05.14 21:34:59 5: TCM TCM310_0 RAW: 55000A0701EBA500
2014.05.14 21:34:59 5: TCM TCM310_0 RAW: 55000A0701EBA500003B0C0186AF830001FFFFFFFF400081
2014.05.14 21:34:59 5: TCM310_0 dispatch EnOcean:1:A5:00003B0C:0186AF83:00:01FFFFFFFF4000
2014.05.14 21:35:08 5: TCM TCM310_0 RAW: 55000A0701EBA500
2014.05.14 21:35:08 5: TCM TCM310_0 RAW: 55000A0701EBA5000000090186AF830001FFFFFFFF440084
2014.05.14 21:35:08 5: TCM310_0 dispatch EnOcean:1:A5:00000009:0186AF83:00:01FFFFFFFF4400


Ausschalten der Last:
2014.05.14 21:36:26 5: TCM TCM310_0 RAW: 55000A0701EBA500
2014.05.14 21:36:26 5: TCM TCM310_0 RAW: 55000A0701EBA50000280C0186AF830001FFFFFFFF4300EC
2014.05.14 21:36:26 5: TCM310_0 dispatch EnOcean:1:A5:0000280C:0186AF83:00:01FFFFFFFF4300
2014.05.14 21:36:29 5: TCM TCM310_0 RAW: 55000A0701EBA500
2014.05.14 21:36:29 5: TCM TCM310_0 RAW: 55000A0701EBA50000000C0186AF830001FFFFFFFF41000F
2014.05.14 21:36:29 5: TCM310_0 dispatch EnOcean:1:A5:0000000C:0186AF83:00:01FFFFFFFF4100


Die Last lässt sich schalten!


Was fehlt sind readings für:

  • die interne Temperatur
  • die Spannung
  • Last an/ausgesteckt
  • Last ein/ausgeschaltet

PSC234 ist kein Dimmer und sollte wohl auch nicht als solcher angezeigt werden.

TAUSEND DANK für das soooo coole EnOcean Modul!
Würde gerne helfen weiter zu Testen ;-)
RaspberryPi, EnOcean PI
Sonos Play1, Connect
Eltako FT55, FSB61, FAM12, FSR12-4x

klaus.schauer

Es gibt für die gesamte Familie EEP D2.01.xx ein Fhem-Profil. Deshalb taucht beim Switch auch der Dim-Parameter auf. Das ist vielleicht ein kleiner Schönheitsfehler. Es wäre aber viel zu aufwändig gewesen, weitere Profilunterscheidungen zu machen.

Die von Fhem nicht unterstützten produktspezifischen Flags sind nicht in den EEP enthalten. Die Beschreibung des Gerätes ist ja recht umfangreich. Falls der Aufwand sich in Grenzen hält, werde ich versuchen, dies in nächster Zeit einzuarbeiten.

krikan

#2
Beim PSC234 werden bei mir nur die "Roh"-Readings D0-D3 und sensor1-sensor3 regelmäßig automatisch aktualisiert. Die Readings für energy und power werden nur nach explizitem Aufruf von "get measurment" aktualisiert.  Habe den PSC234 jetzt mehrfach resetet und neu in Fhem angelernt; Ergebniss ist immer gleich. Zudem stimmt der state unregelmäßig nicht; springt zeitweise auf "0".

Muss ich noch etwas besonderes beachten? Oder kann Fhem das noch nicht?

Danke, Christian

krikan

Die angezeigten Rohreadings scheinen EEP A5-12-01 Telegramme (4BS) zu sein. Diese versendet der PSC234 mit der gleichen Absenderadresse wie die EEP D2.01.00 (VLD) -Anders bei den neuen PEHAs dort gibt es unterschiedliche Absenderadressen-.  Laut PSC234-Anleitung müsste doch bei einem UTE-teach-in alles über VLD-Telegramme laufen. Das bekomme ich aber trotz mehrfachen Resets und neuem Teach-in nicht hin, 4BS und VLD werden immer vermischt. Zumindest auf den ersten Blick scheint bei 50watt die gleiche Vermischung vorzuliegen!?

klaus.schauer

Das Problem der Telegramme mit unterschiedlichen EEP, die über eine SenderID kommen, könnte man vielleicht mit einem "subTypeReading" lösen. Dieses Attribut müsste dann manuell gesetzt werden. Das wird aber dazu führen, dass "state" über zwei Profile gefüllt wird. Finde ich auch nicht gerade praktisch. Eine ähnliche Lösung gibts es auch fürs Senden, siehe subTypeSet. Dort kommt es aber nicht zu unerwünschten Wechselwirkungen.

Muss ich mal drüber schlafen. Manchmal frage ich mich inzwischen, wer das alles mit der Vielzahl der Attribute noch wirklich durchblicken will?

krikan

Meine Vermutung und Hoffnung geht eher in die Richtung von Problemen beim Teach-In. Die optische Anzeige des PSC234 beim Teach-In gibt mir nämlich Rätsel auf. Signalisiert nicht nur mit einem Blinken das UTE-Teach-in, sondern signalisierte noch einen weiteren mit unbekannten Vorgang. Zudem verstehe ich die Anleitung so, dass 4BS-Telegramm nur bei 4BS-Central-Command-Teach-in versendet wird. Technisch kannst Du das besser einschätzen, ob meine Gedankengänge überhaupt möglich/richtig sind.

Ich bastel noch mal...
Zitat
Manchmal frage ich mich inzwischen, wer das alles mit der Vielzahl der Attribute noch wirklich durchblicken will?
Du hoffentlich  ;)

Danke, Christian

Zephyr

Hallo zusammen,

habt ihr herausbekommen welches der Readings den aktuellen Status (an oder aus) beim PSC234 anzeigt? Egal ob an oder aus, bei mir werden immer die gleichen Werte angezeigt. Würde das aber gerne in der Übersicht sehen können...

Grüße
Zephy
FHEM 5.5 auf Fritz!Box 7390 und Beagle Bone black mit RFXtrx433

krikan

@Zephyr
Die Lösung kenne ich nicht. Könntest Du aber einmal schreiben, wie Du angelernt hast (UTE?) und welche Telegramme Dein PSC schickt (LOG mit verbose 5)

@klaus.schauer
Befürchte, dass der PSC tatsächlich beim UTE-teach-In verschiedene Telegramme mit gleicher Absenderadresse schickt und kein Anlernfehler vorliegt. Siehe auch meine Threadergänzung zu PEHA EasyclickPro. Wäre dann analog zu PEHA mit dem Nachteil der gleichen Absender-Id. Standardmäßig liefert der PSC aber -im Gegensatz zu PEHA- bei mir nur regelmäßig die A5-Telegramme.

krikan

Nach vielen Experimenten komme ich abschließend zu folgendem Ergebnis beim PSC234:

Nach einem UTE-Teach-In werden folgende Telegramme verschickt:
Bei Schaltvorgängen Statustelegramm als VLD-Telegramme EEP D2.01.00
Zyklische Statustelegramme zur Energiemessung werden automatisch als 4BS-Telegramm EEP A5-12-01 gesendet
Statustelegramme zur Energiemessung als VLD-Telegramme werden nur durch den expliziten Aufruf von "get measurement..." gesendet
Absender-ID ist für alle Telegramme gleich.

Zur annäherend korrekten Auswertung habe ich 10_EnOcean.pm (r5587) folgendermaßen angepasst:

Zeile 3289:
} elsif (($st =~ m/^autoMeterReading/) || ($st eq "actuator.01")){

Zeile 3321:
} elsif (($st eq "autoMeterReading.01") || ($st eq "actuator.01")) {

Zeile 3343:
if (!(($st eq "actuator.01") && ($manufID eq "033"))) {
    push @event, "3:state:$meterReading";
}


Reading "state" wird nach diesen Änderungen immer "nur" mit dem korrekten Schaltstatus gefüllt.

Offene Punkte/Probleme:
- Readings werden in 10_EnOcean.pm für A5 und VLD teilweise gleich benannt, aber unterschiedlich mit Inhalten gefüllt (energy0 usw.)
- MSC-Telegramme werden noch nicht unterstützt
- Einbindung ist nicht sonderlich "schön" und wieder ein Spezialfall für ein Enocan-Produkt im Code trotz EnOcean-Standart

Über kritische Anmerkungen und Ergänzungen wäre ich dankbar.

klaus.schauer

Diese Speziallösung gefällt mir eigentlich nicht. Ich hätte lieber ein allgemeingültiges Vorgehen mit einem zusätzlichen Attribut. Nur etwas wirklich Brauchbares ist mir noch nicht eingefallen. Wahrscheinlich sollten wir es deshalb zuerst mit der vorgeschlagenen Lösung versuchen.

Welche Readings und welche Inhalte sind denn konkret zweifach oder unterschiedlich vorhanden?

Die Bearbeitung der MSC-Telegramme habe ich aus Zeitgründen erst einmal zurückgestellt.

krikan

ZitatDiese Speziallösung gefällt mir eigentlich nicht. Ich hätte lieber ein allgemeingültiges Vorgehen mit einem zusätzlichen Attribut.
Mir auch nicht. Fand den Vorschlag mit subTypeReading von Dir besser, allein am Umsetzungsvermögen scheitert es. Theoretisch: immer wenn subTypeReading eine Parse-Funktion in 10_EnOcean.pm auslöst, sollte keine state-Änderung ausgelöst werden. Fraglich ist aber, ob die Problematik auf den PSC beschränkt ist.

ZitatWelche Readings und welche Inhalte sind denn konkret zweifach oder unterschiedlich vorhanden?
Reading "energy0": A5-Telegramm erzeugt Wert bspw. "0.2"; während D2-Telegramm Wert "245" ergibt; anscheinend Einheiten unterschiedlich
power wird als A5-Telegramm im Reading "power" und als D2-Telegramm im Reading "power0" ausgegeben; Werte sind erfreulicherweise einheitlich (unkritisch)


klaus.schauer

Bitte mal das Reading D2 löschen. Nach der Zuordnung des A5 Profils sollte es nicht mehr beschrieben werden. Falls dennoch, so muss es von einem weiteren gesendeten EEP kommen.

krikan

Mit "D2-Telegrammen" meinte ich nicht die Roh-Readings, sondern die VLD-Telegramme nach EEP D2....
Es werden auch keine Roh-Readings mehr erzeugt, vgl. Screenshot

klaus.schauer


krikan

Nur fast:
ZitatReading "energy0": A5-Telegramm erzeugt Wert bspw. "0.2"; während D2-Telegramm Wert "245" ergibt; anscheinend Einheiten unterschiedlich
power wird als A5-Telegramm im Reading "power" und als D2-Telegramm im Reading "power0" ausgegeben; Werte sind erfreulicherweise einheitlich (unkritisch)
Das Reading "energy0" kann man nicht sinnvoll nutzen, da es von den beiden EEP-Telegrammentypen mit jeweils anderen Einheiten bestückt wird. (0.2 kwh versus  245 wh)

krikan

Während des Langzeittests hat sich noch ein erhebliches Problem ergeben:

Mein PSC sendet in sehr langen Zeitabständen (mehre Stunden) ein unangefordertes VLD-Telegramm (MSC), dass den "state" als Schaltzustand zerstört. Es bedarf daher noch einer weiteren Änderung in 10_EnOcean.pm neben den obigen Anpassungen. MSC muss wohl eingepflegt werden. Schaue ich mir bei Gelegenheit ein.

krikan

Das erwähnte unaufgeforderte und auch unregelmäßige VLD-Telegramm(MSC) des PSC hat immer den Inhalt "0334FFFF". Wenn ich die Anleitung richtig interpretiere, ist das ein ungültiges Telegramm.

Mit folgender Codeergänzung nach Zeile 3675 der aktuellen 10_EnOcean.pm zusätzlich zu den vorherigen Anpassungen, filtere ich das/die MSC heraus. Der state bleibt dann korrekt.

} elsif (($st eq "actuator.01") && ($manufID eq "033")) {
  # MSC Permundo PSC234
  if ($data eq "0334FFFF") {
     push @event, "3:msc:MSC unvalid";
  } else {
     push @event, "3:msc:$data";
  }


Die offenen Punkte/Probleme sind damit noch nicht geklärt.

Wegen der unterschiedlichen Einheiten im Reading energy0 könnte man in der Auswertung des A5-Telegramms wie bei D2-Telegramm das Reading energyUnit0 aktualsieren. Über eine Abfrage (und-Verknüpfung) von den beiden Readings wäre dann zumindest eine sinnvolle Nutzung möglich. Ideal finde ich das nicht.

krikan

@50watt
@Zephyr

klaus.schauer hat Eure gewünschten Anpassungen zum PSC234 eingearbeitet (Download: http://forum.fhem.de/index.php/topic,24011.msg172694.html#msg172694) . Wäre schön, wenn Ihr auch testen würdet. Danke!

Gruß, Christian

klaus.schauer

Die gerätespezifischen Abfragen sind jetzt auch drin (get <Name> special ...) und funktionieren hoffentlich.

krikan

Die gerätespezifischen Abfragen liefern bei mir keine Events/Readings. Die anderen Set/Get-Befehle funktionieren.

@50watt,
@Zephyr: Funktionieren bei Euch die gerätespezifischen Abfragen?

Meine Logs der gerätespezifischen Get:

subDef="00000000"

2014.06.17 20:41:53 3: EnOcean get EnO_UTE_0186AF62 special 0 health
2014.06.17 20:41:53 5: TCM TCM310_3 sending 550009070156D10331070000000000030186AF62FF0089
2014.06.17 20:41:53 5: SW: 550009070156D10331070000000000030186AF62FF0089
2014.06.17 20:41:53 5: TCM TCM310_3 RAW: 550001000265000055000A0701EBD1033428000186AF620003FFFFFFFF530053
2014.06.17 20:41:53 5: TCM TCM310_3 RESPONSE: OK
2014.06.17 20:41:53 5: TCM310_3 dispatch EnOcean:1:D1:03342800:0186AF62:00:03FFFFFFFF5300

2014.06.17 20:44:10 3: EnOcean get EnO_UTE_0186AF62 special 0 serialNumber
2014.06.17 20:44:10 5: TCM TCM310_3 sending 550009070156D10331810000000000030186AF62FF0009
2014.06.17 20:44:10 5: SW: 550009070156D10331810000000000030186AF62FF0009
2014.06.17 20:44:10 5: TCM TCM310_3 RAW: 550001000265000055000A0701EBD1033401020186AF620003FFFFFFFF530050
2014.06.17 20:44:10 5: TCM TCM310_3 RESPONSE: OK
2014.06.17 20:44:10 5: TCM310_3 dispatch EnOcean:1:D1:03340102:0186AF62:00:03FFFFFFFF5300


subDef="FFAEEE83"

2014.06.19 10:43:46 3: EnOcean get EnO_UTE_0186AF62 special 0 load
2014.06.19 10:43:46 5: TCM TCM310_3 sending 550009070156D1033108FFAEEE8300030186AF62FF0001
2014.06.19 10:43:46 5: SW: 550009070156D1033108FFAEEE8300030186AF62FF0001
2014.06.19 10:43:46 5: TCM TCM310_3 RAW: 5500010002650000
2014.06.19 10:43:46 5: TCM TCM310_3 RESPONSE: OK
2014.06.19 10:43:46 5: TCM TCM310_3 RAW: 55000A0701EBD1033450000186AF620003FFFFFFFF52001A
2014.06.19 10:43:46 5: TCM310_3 dispatch EnOcean:1:D1:03345000:0186AF62:00:03FFFFFFFF5200

2014.06.19 10:47:20 3: EnOcean get EnO_UTE_0186AF62 special 0 serialNumber
2014.06.19 10:47:20 5: TCM TCM310_3 sending 550009070156D1033181FFAEEE8300030186AF62FF00D8
2014.06.19 10:47:20 5: SW: 550009070156D1033181FFAEEE8300030186AF62FF00D8
2014.06.19 10:47:20 5: TCM TCM310_3 RAW: 55000100
2014.06.19 10:47:20 5: TCM TCM310_3 RAW: 550001000265000055000A0701EBD1033401020186AF620003FFFFFFFF530050
2014.06.19 10:47:20 5: TCM TCM310_3 RESPONSE: OK
2014.06.19 10:47:20 5: TCM310_3 dispatch EnOcean:1:D1:03340102:0186AF62:00:03FFFFFFFF5300

2014.06.19 10:54:30 3: EnOcean get EnO_UTE_0186AF62 special 30 load
2014.06.19 10:54:30 5: TCM TCM310_3 sending 550009070156D1033108FFAEEE8300030186AF62FF0001
2014.06.19 10:54:30 5: SW: 550009070156D1033108FFAEEE8300030186AF62FF0001
2014.06.19 10:54:30 5: TCM TCM310_3 RAW: 5500010002650000
2014.06.19 10:54:30 5: TCM TCM310_3 RESPONSE: OK

2014.06.19 10:57:45 3: EnOcean get EnO_UTE_0186AF62 special 0 health
2014.06.19 10:57:45 5: TCM TCM310_3 sending 550009070156D1033107FFAEEE8300030186AF62FF0058
2014.06.19 10:57:45 5: SW: 550009070156D1033107FFAEEE8300030186AF62FF0058
2014.06.19 10:57:45 5: TCM TCM310_3 RAW: 550001000265000055000A0701EBD103342D000186AF620003FFFFFFFF5900A9
2014.06.19 10:57:46 5: TCM TCM310_3 RESPONSE: OK
2014.06.19 10:57:46 5: TCM310_3 dispatch EnOcean:1:D1:03342D00:0186AF62:00:03FFFFFFFF5900

Zephyr

Um ehrlich zu sein weiß ich nicht mal welche gerätespezifischen Readings das sein sollen. Die Kanäle außer dem state kann ich einfach mal gar nicht deuten.
Inzwischen ist das größte Problem dankenswerter Weise behoben: Dass der Status on/off gar nicht angezeigt oder dann wieder überschrieben wird.

gruß
Zephyr
FHEM 5.5 auf Fritz!Box 7390 und Beagle Bone black mit RFXtrx433

krikan

#21
@klaus.schauer:

Konnte mein Problem mit "get specials" weiter eingrenzen:

Habe in die leere Zeile 435 von 10_EnOcean.pm 

$hash->{READINGS}{getParam}{VAL} = $query;


eingefügt, dann funktionieren die Abfragen.

Das Reading "getParam" war wohl irrtümlich in der Set-funktion nicht definiert und die Parse-Funktion wurde damit nicht korrekt durchlaufen.

In der Parse-Funktion sind health (7) und load (8  ) in getParam vertauscht.

klaus.schauer

Mal abgesehen davon, dass fehlerfrei natürlich sehr praktisch wäre, macht die gemeinsame Arbeit Spaß. Danke für die Unterstützung. Die geänderte Datei kommt per Update.

krikan

Ein großes Danke für Deine Arbeit zurück! Frage mich, wie Du ohne entsprechende Hardware überhaupt soweit kommst...

get special für den PSC234 funktioniert mit r6143 von 10_Enocean.pm.

Zephyr

Zitat von: krikan am 19 Juni 2014, 21:48:15
Ein großes Danke für Deine Arbeit zurück! Frage mich, wie Du ohne entsprechende Hardware überhaupt soweit kommst...

get special für den PSC234 funktioniert mit r6143 von 10_Enocean.pm.

Herzlichen Dank, dass Du da so engagiert dran arbeitest. Für uns Nutzer ist das wirklich mehr als angenehm.
Danke!
FHEM 5.5 auf Fritz!Box 7390 und Beagle Bone black mit RFXtrx433

Zephyr

Hallo zusammen,

ich hatte in der Vergangenheit immer mal wieder das Problem, dass der PSC234 nicht auf Kommandos reagierte. Auch nicht, wenn der Schalter direkt daneben montiert war.
Nachdem ich ihn dann in den Auslieferungszustand zurückgesetzt und alle Schalter und FHEM wieder angelernt hatte, lief alles wieder.

Seit heute besteht aber das Problem, dass ich ihn zwar in den Auslieferungszustand zurückgesetzt bekomme, er aber danach die Schalter nicht wieder erkennt. Kommt euch das Problem bekannt vor? Ansonsten muss ich wohl mal mit dem Händler Kontakt aufnehmen.

Viele Grüße
Zephyr
FHEM 5.5 auf Fritz!Box 7390 und Beagle Bone black mit RFXtrx433

krikan

Hallo Zephyr,
habe zwei im Einsatz die keine Deiner beschriebenen Probleme zeigen. Einzige Schwierigkeit bei mir bisher: Anlernvorgang war schwierig, da UTE-Teach-In erst nach mehrmaligen Versuchen funktionierte.
Gruß, Christian

Zephyr

Danke für die Rückmeldung. Dann also mal an batterielos.de schreiben.

viele Grüße
Zephyr
FHEM 5.5 auf Fritz!Box 7390 und Beagle Bone black mit RFXtrx433

therapy

Hallo Zusammen,

ich habe jetzt eine handvoll PSC234 im Einsatz, anlernen ging ohne Probleme, FHEM erkennt alles, schalten geht auch, die Leistungsaufnahme in W wird angezeigt, jedoch bleibt energy0 immer auf 0, wird hier nix gemessen oder muss ich das explizit aktivieren?
Stehe gerade ein bisschen auf dem Schlauch und sehe den Wald vor lauter Bäumen nicht mehr.

Grüße
therapy

krikan

Frage mal bitte einen PSC234 mit
get <device> measurement all energy
ab.
Wird dann das Reading aktualisiert? Schau bitte mal ins Log, ob da mit dem aktuellen Fhem Fehler/Warnungen auftauchen und berichte bitte. Ich bekomme nämlich derzeit Warnings bei der Abfrage im Log und keine aktualisierten Readings; habe nur heute keine Zeit mehr mich darum zu kümmern, muss jetzt arbeiten.

Die Angabe in energy ist übrigens nach meiner Erinnerung in kwh. Hast Du schon so viel zusammen.

krikan

#30
Schneller zurück als gedacht, darum doch Problemhinweise. Keine Ahnung, ob dieses Problem nur bei mir auftritt. Könnte das bitte jemand gegenchecken.

PSC liefert mir keine Rückgabewerte mehr. Ein- und Ausschalten geht jedoch. Änderungen sind meinerseits nicht (bewusst) erfolgt. Update-Stand heute; Problem könnte aber schon länger existieren. Ursache ist mir vollkommen unklar; stacktrace von Dietmar63 verstehe ich aber nicht.

@klaus.schauer: Hoffe, dass Du es verstehst. Wenn Du mehr Infos brauchst, gib mir bitte die entsprechenden Hinweise.

version:
# $Id: fhem.pl 6684 2014-10-05 07:42:43Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6642 2014-09-30 20:09:35Z martinp876 $
# $Id: 10_EnOcean.pm 6579 2014-09-20 08:27:16Z klaus-schauer $
# $Id: 72_FB_CALLMONITOR.pm 6624 2014-09-27 13:47:52Z markusbloch $
# $Id: 01_FHEMWEB.pm 6611 2014-09-24 07:48:32Z rudolfkoenig $
# $Id: 92_FileLog.pm 6571 2014-09-19 16:05:56Z rudolfkoenig $
# $Id: 00_HMLAN.pm 6471 2014-08-27 12:32:38Z martinp876 $
# $Id: 98_HMinfo.pm 6575 2014-09-19 18:33:13Z martinp876 $
# $Id: 98_HTTPMOD.pm 6463 2014-08-26 16:14:30Z ststrobel $
# $Id: 99_SUNRISE_EL.pm 6682 2014-10-05 07:21:36Z rudolfkoenig $
# $Id: 98_SVG.pm 6649 2014-10-01 16:01:50Z rudolfkoenig $
# $Id: 42_SYSMON.pm 6678 2014-10-04 20:18:01Z hexenmeister $
# $Id: 00_TCM.pm 6559 2014-09-15 19:10:40Z klaus-schauer $
# $Id: 45_TRX.pm 5957 2014-05-24 13:46:29Z wherzig $
# $Id: 46_TRX_LIGHT.pm 6225 2014-07-09 18:36:02Z wherzig $
# $Id: 46_TRX_WEATHER.pm 5719 2014-05-01 19:18:38Z wherzig $
# $Id: 59_Twilight.pm 6318 2014-07-25 22:13:51Z dietmar63 $
# $Id: 70_USBEHZ.pm 3011 2013-04-01 11:35:04Z wherzig $
# $Id: 99_Utils.pm 6660 2014-10-03 06:35:43Z rudolfkoenig $
# $Id: 59_Weather.pm 6657 2014-10-02 19:53:20Z borisneubert $
# $Id: 00_ZWDongle.pm 6592 2014-09-21 20:01:13Z rudolfkoenig $
# $Id: 10_ZWave.pm 6693 2014-10-05 21:15:33Z rudolfkoenig $
# $Id: 98_autocreate.pm 6505 2014-09-06 12:24:48Z rudolfkoenig $
# $Id: 91_eventTypes.pm 6428 2014-08-20 11:51:27Z rudolfkoenig $
# $Id: 91_notify.pm 6371 2014-08-07 05:33:37Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 6262 2014-07-16 07:46:03Z justme1968 $
# $Id: 33_readingsHistory.pm 5918 2014-05-20 21:19:58Z justme1968 $
# $Id: 91_sequence.pm 6629 2014-09-29 09:12:34Z rudolfkoenig $
# $Id: 98_telnet.pm 6611 2014-09-24 07:48:32Z rudolfkoenig $
# $Id: 98_weblink.pm 5608 2014-04-23 10:57:16Z rudolfkoenig $

List betroffenes Device:
Internals:
   DEF        0186AF62
   IODev      TCM_ESP3_2
   NAME       EnO_UTE_0186AF62
   NOTIFYDEV  global
   NR         119
   STATE      on
   TYPE       EnOcean
   Readings:
     2014-10-06 18:23:27   channelAll      off
     2014-10-06 21:24:03   channelFF       on
     2014-10-04 13:07:50   currentTariff   0
     2014-10-06 18:23:27   dim             0
     2014-10-06 21:24:03   dimFF           100
     2014-10-04 13:07:50   energy0         0.6
     2014-09-21 20:03:33   error0          ok
     2014-09-21 20:03:33   localControl0   disabled
     2014-09-21 20:03:33   overCurrentOff0 ready
     2014-10-04 12:55:48   power           0
     2014-09-21 20:03:33   powerFailure0   disabled
     2014-09-21 20:03:33   powerFailureDetection0 not_detected
     2014-10-06 21:24:03   state           on
Attributes:
   IODev      TCM_ESP3_2
   comMode    biDir
   devChannel FF
   manufID    033
   room       EnOcean
   subDef     FFAEEE83
   subType    actuator.01


Log-Auszug (Erste Warnung beim Aufruf Detail-Seite; Restliche Warnungen bei geloggten Vorgängen):
2014.10.06 21:22:01 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 496.
2014.10.06 21:22:01 3: stacktrace:
2014.10.06 21:22:01 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (492)
2014.10.06 21:22:01 3:     main::EnOcean_Get                   called by fhem.pl (2902)
2014.10.06 21:22:01 3:     main::CallFn                        called by fhem.pl (1494)
2014.10.06 21:22:01 3:     main::CommandGet                    called by fhem.pl (2083)
2014.10.06 21:22:01 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1002)
2014.10.06 21:22:01 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (737)
2014.10.06 21:22:01 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:22:01 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:22:01 3:     main::CallFn                        called by fhem.pl (594)
2014.10.06 21:22:09 3: EnOcean get EnO_UTE_0186AF62 measurement 30 energy
2014.10.06 21:22:09 5: TCM TCM_ESP3_2 sending 55000807013DD2061EFFAEEE8300030186AF62FF00C7
2014.10.06 21:22:09 5: SW: 55000807013DD2061EFFAEEE8300030186AF62FF00C7
2014.10.06 21:22:09 5: TCM TCM_ESP3_2 RAW: 5500010002650000
2014.10.06 21:22:09 5: TCM TCM_ESP3_2 RESPONSE: OK
2014.10.06 21:22:09 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 496.
2014.10.06 21:22:09 3: stacktrace:
2014.10.06 21:22:09 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (492)
2014.10.06 21:22:09 3:     main::EnOcean_Get                   called by fhem.pl (2902)
2014.10.06 21:22:09 3:     main::CallFn                        called by fhem.pl (1494)
2014.10.06 21:22:09 3:     main::CommandGet                    called by fhem.pl (2083)
2014.10.06 21:22:09 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1002)
2014.10.06 21:22:09 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (737)
2014.10.06 21:22:09 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:22:09 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:22:09 3:     main::CallFn                        called by fhem.pl (594)
2014.10.06 21:23:14 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 496.
2014.10.06 21:23:14 3: stacktrace:
2014.10.06 21:23:14 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (492)
2014.10.06 21:23:14 3:     main::EnOcean_Get                   called by fhem.pl (2902)
2014.10.06 21:23:14 3:     main::CallFn                        called by fhem.pl (1494)
2014.10.06 21:23:14 3:     main::CommandGet                    called by fhem.pl (2083)
2014.10.06 21:23:14 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1002)
2014.10.06 21:23:14 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (737)
2014.10.06 21:23:14 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:23:14 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:23:14 3:     main::CallFn                        called by fhem.pl (594)
2014.10.06 21:23:20 3: EnOcean get EnO_UTE_0186AF62 measurement 30 energy
2014.10.06 21:23:20 5: TCM TCM_ESP3_2 sending 55000807013DD2061EFFAEEE8300030186AF62FF00C7
2014.10.06 21:23:20 5: SW: 55000807013DD2061EFFAEEE8300030186AF62FF00C7
2014.10.06 21:23:20 5: TCM TCM_ESP3_2 RAW: 5500010002650000
2014.10.06 21:23:20 5: TCM TCM_ESP3_2 RESPONSE: OK
2014.10.06 21:23:20 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 496.
2014.10.06 21:23:20 3: stacktrace:
2014.10.06 21:23:20 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (492)
2014.10.06 21:23:20 3:     main::EnOcean_Get                   called by fhem.pl (2902)
2014.10.06 21:23:20 3:     main::CallFn                        called by fhem.pl (1494)
2014.10.06 21:23:20 3:     main::CommandGet                    called by fhem.pl (2083)
2014.10.06 21:23:20 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1002)
2014.10.06 21:23:20 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (737)
2014.10.06 21:23:20 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:23:20 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:23:20 3:     main::CallFn                        called by fhem.pl (594)
2014.10.06 21:23:41 5: TCM TCM_ESP3_2 RAW: 55000707017AD5090000FA27
2014.10.06 21:23:41 5: TCM TCM_ESP3_2 RAW: 55000707017AD5090000FA270003FFFFFFFF4C0036
2014.10.06 21:23:41 5: TCM_ESP3_2 dispatch EnOcean:1:D5:09:0000FA27:00:03FFFFFFFF4C00
2014.10.06 21:23:55 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 496.
2014.10.06 21:23:55 3: stacktrace:
2014.10.06 21:23:55 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (492)
2014.10.06 21:23:55 3:     main::EnOcean_Get                   called by fhem.pl (2902)
2014.10.06 21:23:55 3:     main::CallFn                        called by fhem.pl (1494)
2014.10.06 21:23:55 3:     main::CommandGet                    called by fhem.pl (2083)
2014.10.06 21:23:55 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1002)
2014.10.06 21:23:55 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (737)
2014.10.06 21:23:55 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:23:55 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:23:55 3:     main::CallFn                        called by fhem.pl (594)
2014.10.06 21:24:03 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 1726.
2014.10.06 21:24:03 3: stacktrace:
2014.10.06 21:24:03 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (1716)
2014.10.06 21:24:03 3:     main::EnOcean_Set                   called by fhem.pl (2897)
2014.10.06 21:24:03 3:     main::CallFn                        called by fhem.pl (1434)
2014.10.06 21:24:03 3:     main::DoSet                         called by fhem.pl (1464)
2014.10.06 21:24:03 3:     main::CommandSet                    called by fhem.pl (966)
2014.10.06 21:24:03 3:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (1915)
2014.10.06 21:24:03 3:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (601)
2014.10.06 21:24:03 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:24:03 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:24:03 3:     main::CallFn                        called by fhem.pl (594)
2014.10.06 21:24:03 3: EnOcean set EnO_UTE_0186AF62 on 010064
2014.10.06 21:24:03 5: TCM TCM_ESP3_2 sending 550009070156D2010064FFAEEE8300030186AF62FF00E6
2014.10.06 21:24:03 5: SW: 550009070156D2010064FFAEEE8300030186AF62FF00E6
2014.10.06 21:24:03 5: TCM TCM_ESP3_2 RAW: 5500010002650000
2014.10.06 21:24:03 5: TCM TCM_ESP3_2 RESPONSE: OK
2014.10.06 21:24:03 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 496.
2014.10.06 21:24:03 3: stacktrace:
2014.10.06 21:24:03 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (492)
2014.10.06 21:24:03 3:     main::EnOcean_Get                   called by fhem.pl (2902)
2014.10.06 21:24:03 3:     main::CallFn                        called by fhem.pl (1494)
2014.10.06 21:24:03 3:     main::CommandGet                    called by fhem.pl (2083)
2014.10.06 21:24:03 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1002)
2014.10.06 21:24:03 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (737)
2014.10.06 21:24:03 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:24:03 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:24:03 3:     main::CallFn                        called by fhem.pl (594)
2014.10.06 21:24:10 1: PERL WARNING: Argument "FF" isn't numeric in addition (+) at ./FHEM/10_EnOcean.pm line 496.
2014.10.06 21:24:10 3: stacktrace:
2014.10.06 21:24:10 3:     main::__ANON__                      called by ./FHEM/10_EnOcean.pm (492)
2014.10.06 21:24:10 3:     main::EnOcean_Get                   called by fhem.pl (2902)
2014.10.06 21:24:10 3:     main::CallFn                        called by fhem.pl (1494)
2014.10.06 21:24:10 3:     main::CommandGet                    called by fhem.pl (2083)
2014.10.06 21:24:10 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1002)
2014.10.06 21:24:10 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (737)
2014.10.06 21:24:10 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:24:10 3:     main::FW_Read                       called by fhem.pl (2902)
2014.10.06 21:24:10 3:     main::CallFn                        called by fhem.pl (594)


Gruß, Christian

therapy

Guten Morgen,

danke erstmal für den Hinweis das reading zu aktualisieren, jetzt wird mitgeschrieben. Die Ausgabe erfolgt (noch) nur bei Abfrage des readings, aber immerhin!
Ja, so langsam sollte ich mich auch der 1kWh nähern, mich hat nur irritiert das da eben 0.0 stand, bin davon ausgegangen das auch Nachkommastellen gemessen werden können (was jetzt auch passiert z.B. : 0.097 kWh bei einem weiteren Zwischenstecker).

Zu deinem Problem:
Gestern habe ich diese Fehlermeldungen auch bekommen, Daten wurden trotzdem (auf den ersten Blick auch plausible Werte) übermittelt.
Heute morgen fix geupdated und nun sind die Fehlermeldungen ausgeblieben, weiterhin bekomme ich Messwerte.

Grüße
therapy

krikan

#32
Gut, das es bei Dir jetzt per Abfrage (D2-Telegramm) funktioniert. Eigentlich hatte ich aber in Erinnerung, dass sich die Werte beim PSC automatisch regelmäßig über A5-Telegramm aktualisieren und hatte es so auch hier (http://forum.fhem.de/index.php/topic,23613.msg171513.html#msg171513) und im Wiki dokumentiert. Findet bei Dir wirklich keine regelmäßige automatische Aktualisierung stattfindet. Hast Du ein (altes) Filelog (ich nicht)? Dort auch keine regelmäßigen Aktualisierungen erkennbar?
Zitat
Heute morgen fix geupdated und nun sind die Fehlermeldungen ausgeblieben, weiterhin bekomme ich Messwerte.
Oder heißt das regelmäßige automatische Aktualisierung?


Mein System scheint ja derzeit irgendein Problem zu haben, dem ich wohl erst auf den Grund gehen muss, bevor ich alle wild mache. Dennoch würde ich stacktrace gerne verstehen.
Was mir bei meinem betroffenen Device (obiges list) im nachhinein auffällt, ist ein fehlendes IODEV. Kann das zu ausbleibenden Rückantworten führen? Wird das nicht automatisch gesetzt?

therapy

Leider findet (noch) keine automatische Aktualisierung statt, aber ich mache mich erstmal auf die Suche ob das nicht einfach an meinem Unwissen liegt. Bin noch ganz frisch in Sachen FHEM ;)
Ein altes Filelog habe ich leider nicht, das älteste ist das mit den Fehlermedlungen und da wurde eben nicht automatisch aktualisiert.

Mit fix geupdated meinte ich den FHEM-Server ansich, ich werde das nun aber weiterhin beobachten und berichten wie sich das System verhält.

krikan

ZitatLeider findet (noch) keine automatische Aktualisierung statt, aber ich mache mich erstmal auf die Suche ob das nicht einfach an meinem Unwissen liegt.
Das sollte nach dem korrekten Anlern-Vorgang eigentlich auch automatisch mit A5-Telegramm laufen. Automatische Werte kamen im rhytmischen Abstand (20? min).
Beruhigt mich ein wenig, dass es dann nicht nur bei mir so ist. Bringt uns aber der Lösung nicht näher  :'(.

therapy

Das FHEM-Log spuckt regelmäßig (alle 20 min kommt in etwa hin) ein reading für energy0 aus, jedoch immer 0.0.
Sobald ich das manuell mit einer Abfrage anstoße wird aus den 0.0 irgendein Wert z.B. 0.037, welcher größer ist als der vorherige abgefragte Wert.
Im SmartPlug scheint also richtig "mitgezählt" zu werden, nur die Werte die automatisch übermittelt werden sind Mist, oder eben das Empfangen der Daten zickt.

Hier ein Beispiel:
2014-10-07_13:11:23 EnO_sensor_0186FF50 energyUnit0: KWh
2014-10-07_13:11:23 EnO_sensor_0186FF50 energy0: 0.038
2014-10-07_13:11:26 EnO_sensor_0186FF50 power: 23
2014-10-07_13:11:29 EnO_sensor_0186FF50 power: 24
2014-10-07_13:11:32 EnO_sensor_0186FF50 power: 23
2014-10-07_13:11:35 EnO_sensor_0186FF50 energy0: 0.0
2014-10-07_13:11:35 EnO_sensor_0186FF50 currentTariff: 0
......
2014-10-07_13:17:20 EnO_sensor_0186FF50 power: 19
2014-10-07_13:17:23 EnO_sensor_0186FF50 energy0: 0.0
......
2014-10-07_13:19:47 EnO_sensor_0186FF50 power: 20
2014-10-07_13:19:48 EnO_sensor_0186FF50 energyUnit0: KWh
2014-10-07_13:19:48 EnO_sensor_0186FF50 energy0: 0.041


Um 13:11:23 Uhr habe ich manuell den Wert für energy0 abgefragt, die Ausgabe für energy0 um 13:11:35 ist wiederrum die Standardausgabe die immer bei 0.0 bleibt und regelmäßig erfolgt.
Wenn ich nun später manuell abfrage wird mir ein plausibler Wert angegeben (z.B. um 13:19:40), obwohl die automatische Ausgabe um 13:17:23 mit 0.0 angegeben war.

krikan

Abweichende Werte bei energy0 sind für mich halbwegs nachvollziehbar, da das Reading aus dem regelmäßigen A5-Telegramm und der Abfrage mit D2-Telegramm gewonnen wird. Die Telegramme haben im Original unterschiedliche Einheiten kwh bzw. Wh. klaus.schauer hat das auf meinen Wunsch (vgl. oben im Thread) angeglichen. Dadurch kommt es wohl zu Rundungsdifferenzen, die mir aber (als es bei mir noch funktionierte) nicht aufgefallen sind.

Hast Du bei der manuellen Abfrage kein stacktrace mit PERL WARNING im zentralen Fhem-Log und update-Stand von heute (mit nachfolgendem "shutdown restart")?


therapy

Das kommt davon wenn man so ungeduldig ist  :'(
Die Stacktrace Fehler sind leider wieder da,
Bezgl. der Rundungsfehler lasse ich die Messungen einfach mal laufen und schaue wie sich das entwickelt.

krikan

Mein Problem mit den fehlenden Rücktelegrammen des PSC234 ist geklärt Es liegt an meiner Installation und hat nichts mit Fhem zu tuen. Dietmars stacktrace ist nur zufällig mit meinem Problem zusammengefallen (@klaus.schauer: hoffe Du hast jetzt noch nicht allzu tief gesucht! Sorry!).
Für Interessierte: Mein ZWave-Stick hat anscheinend die Funkkommunikation gestört. Nach dem Abstöbseln kommen alle Rücktelegramme von EnOcean wieder an. Für mich verwunderlich, da der Aufbau so seit Monaten funktionsfähig war.

Zurück zum PSC234: Die Readings power, energy0 und currentTariff werden vom ca. alle 10min von meinem PSC an Fhem gesendet.
Zitat
Bezgl. der Rundungsfehler lasse ich die Messungen einfach mal laufen und schaue wie sich das entwickelt.
Die Rundsdifferenzen zwischen regelmäßigem Telegramm und manueller Abfrage wirst Du immmer haben. Es sei denn klaus.schauer baut eine Rundung ein, was aber meiner Meinung nach nicht sinnnvoll ist.

klaus.schauer

Zitat von: krikan am 06 Oktober 2014, 21:44:34
Internals:
   DEF        0186AF62
   IODev      TCM_ESP3_2
   NAME       EnO_UTE_0186AF62
   NOTIFYDEV  global
   NR         119
   STATE      on
   TYPE       EnOcean
   Readings:
     2014-10-06 18:23:27   channelAll      off
     2014-10-06 21:24:03   channelFF       on
     2014-10-04 13:07:50   currentTariff   0
     2014-10-06 18:23:27   dim             0
     2014-10-06 21:24:03   dimFF           100
     2014-10-04 13:07:50   energy0         0.6
     2014-09-21 20:03:33   error0          ok
     2014-09-21 20:03:33   localControl0   disabled
     2014-09-21 20:03:33   overCurrentOff0 ready
     2014-10-04 12:55:48   power           0
     2014-09-21 20:03:33   powerFailure0   disabled
     2014-09-21 20:03:33   powerFailureDetection0 not_detected
     2014-10-06 21:24:03   state           on
Attributes:
   IODev      TCM_ESP3_2
   comMode    biDir
   devChannel FF
   manufID    033
   room       EnOcean
   subDef     FFAEEE83
   subType    actuator.01



devChannel FF

Den devChannel FF gibt lt. EEP nicht. Bitte Gerät neu anlernen... mal sehen, was dabei rauskommt. Falls dann immer noch "FF" angezeigt wird, müsste ich die Besonderheit zusätzlich aufnehmen.

krikan

#40
ZitatDen devChannel FF gibt lt. EEP nicht. Bitte Gerät neu anlernen... mal sehen, was dabei rauskommt. Falls dann immer noch "FF" angezeigt wird, müsste ich die Besonderheit zusätzlich aufnehmen.
Mach ich. Mein zweiter PSC hat aber den gleichen devChannel FF. Brauchst Du zusätzliche Logs mit verbose 5?

Habe den zweiten komplett zurückgesetzt und neu angelernt. Ergebnis wieder devChannel FF.
listInternals:
   CFGFN
   DEF        0186B1D5
   IODev      TCM_ESP3_2
   NAME       EnO_UTE_0186B1D5
   NOTIFYDEV  global
   NR         358
   STATE      off
   TYPE       EnOcean
   Readings:
     2014-10-07 21:11:39   channelAll      off
     2014-10-07 21:11:39   dim             0
     2014-10-07 21:11:39   state           off
     2014-10-07 21:10:35   teach-in        EEP D2-01-09 Manufacturer: Permundo GmbH
Attributes:
   IODev      TCM_ESP3_2
   comMode    biDir
   devChannel FF
   eep        D2-01-09
   manufID    033
   room       EnOcean
   subDef     FFAEEE84
   subType    actuator.01


Hat das (neue?) Attribut EEP eine bestimmte Bedeutung?

klaus.schauer

#41
Schalten des Aktors und die Rückmeldungen z. B. energy scheinen trotz des DevChannnel FF über Kanal 0 zu laufen. Ich werde deshalb FF für diesen Sonderfall auf Kanal 0 umbiegen.

Bitte testen, ob get- und set-Befehle mit Kanal 0 oder FF gesendet werden müssen!

Das neue Attribut eep wird für Remote Management benötigt, wenn es denn mal irgendwann funktionieren sollte.

krikan

ZitatBitte testen, ob get- und set-Befehle mit Kanal 0 oder FF gesendet werden müssen!
Hast Du ein bestimmtes Testszenario im Sinn?
Reicht es, wenn ich über Fhem "set <device> on <channel>" teste oder den defaultChannel ändere oder sollte ich es tiefer auf Perl-Ebene testen?
Wird leider ein wenig dauern, da ich noch die EnOcean-D-452-FU-EBIM-JR-Baustelle (Lammellen) habe, die momentan dringender ist.

@all: Wenn die Tests jemand anderes kurzfristig durchführen kann, wäre ich nicht böse  ;) ...

klaus.schauer

Tests auf Benutzerebene reichen. Ich möchte klären, über welchen Kanal das Gerät angesteuert werden muss. Ich vermute es ist der Kanal 0, obwohl als devChannel FF ausgelesen wird.

krikan

OK, dann sind die Test vermutlich einfacher.
Am Rande: devChannel FF habe ich übrigens auch bei den PEHA 452 UTE-teach-Ins stehen, aber keine PERL WARNINGS im log; dort habe ich aber defaultChannel gesetzt, beim PSC nicht.

krikan

Testergebnis: channel 0 schaltet bei meinem PS.
Gruß, Christian

felix.steinbeis

Hallo zusammen,

ich habe seit gestern auch einen Smart Plug PSC234.

Was mir aufgefallen ist und vielleicht könnt Ihr das mal prüfen:


  • Der Smart Plug meldet sporadisch "mainsPower: failure" wenn ich den Stand mit "get <dev> special 0 health" abfrage. Mal ist alles ok, dann wieder failure.
    Eine Fehlfunktion kann ich aber nicht erkennen.
    Was bedeutet der Fehler und habt Ihr das auch oder sollte ich den Smart Plug besser austauschen?
  • Der Smart Plug wird im Bereich des Steckers zur Steckdose deutlich warm, wenn ein Verbraucher angeschlossenen und angeschaltet ist.
    Die interne Temperatur des Smart Plug liegt bei ca. 56 Grad C. Ohne Last liegt die interne Temperatur bei ca. 35 Grad C.
    Ist diese Erwärmung normal und bei Euch auch?
  • Das Problem mit den kWh und eine bzw. drei Nachkommastellen besteht immer noch, oder?
  • Nach einem Stromausfall schaltet der Smart Plug immer direkt ein. Ist das so richtig und bei Euch auch so?

Wäre super, wenn Ihr das bei Euch mal prüfen könntet.

Danke und Grüße
Felix

krikan

Zitat von: felix.steinbeis am 08 Mai 2015, 14:51:24
Der Smart Plug meldet sporadisch "mainsPower: failure" wenn ich den Stand mit "get <dev> special 0 health" abfrage. Mal ist alles ok, dann wieder failure.
Eine Fehlfunktion kann ich aber nicht erkennen.
Habe das jetzt zum ersten Mal getestet. Meine beiden melden"failure". Was das bedeuten könnte, kann man vermutlich in den EEP nachsehen. Meine funktionieren aber scheinbar problemlos.

Zitat von: felix.steinbeis am 08 Mai 2015, 14:51:24
Die interne Temperatur des Smart Plug liegt bei ca. 56 Grad C. Ohne Last liegt die interne Temperatur bei ca. 35 Grad C.
Ist diese Erwärmung normal und bei Euch auch?
10 min mit  13 Watt ergeben 44 Grad C.

Zitat von: felix.steinbeis am 08 Mai 2015, 14:51:24
Das Problem mit den kWh und eine bzw. drei Nachkommastellen besteht immer noch, oder?
Problem. Na ja, das eine ist halt genauer. Nicht unbedingt von Nachteil

Zitat von: felix.steinbeis am 08 Mai 2015, 14:51:24
Nach einem Stromausfall schaltet der Smart Plug immer direkt ein. Ist das so richtig und bei Euch auch so?
Habe es bei einem getestet: Der bleibt aus.

Habe zu den einzelen Punkten nicht mehr im Handbuch nachgesehen; vielleicht liefert das noch Infos..

Gruß, Christian


felix.steinbeis

Hallo Christian,

Danke für Dein Feedback.

Nachdem ich das Gefühl hatte, die Temperatur spielt irgendwie eine Rolle, habe ich nochmal ein wenig analysiert. Die Enocean-Nachricht die vom PSC234 kommt, ist korrekt und ohne mainsPower failure.
Meiner Meinung nach gibt es einen kleinen Bug in 10_Enocean.pm. Der "mains power failure" befindet sich in Bit 3 und nicht in Bit 11 vom Health Status. In Bit 8..15 steckt die Temperatur.

In Zeile 5621 (rel8474) müsste es daher anstelle von push @event, "3:mainsPower:" . (($db[1] & 8) ? "failure":"ok");

wie folgt lauten: push @event, "3:mainsPower:" . (($db[0] & 8) ? "failure":"ok");

Da ich keine Ahnung habe, wie der Fehler im nächsten Release behoben werden kann, hoffe ich, dass Klaus mit liest.


Nochmal zur Temperatur: Ist denn der Stecker vom Smart Plug bei Dir auch richtig warm, wenn Du den Smart Plug nach Betrieb aus der Steckdose ziehst?

Viele Grüße
Felix

krikan

Klaus wird schon mitlesen, da mache ich mir keine Sorgen. Wenn Deine Analyse korrekt ist, wird er es bei Gelegenheit schon beheben.

Ehrlich gesagt, habe ich keine Ahnung, ob die PSC warm werden. Bei mir sind die permanent und schlecht erreichbar eingesteckt. Als Last hängen nur Sonoskomponenten daran. Kann mir insbesondere bei höherer Last aber schon eine spürbare Erwärmung vorstellen, wenn ich schon über 40 Grad per Telegramm bekomme.

klaus.schauer


lolle

Hallo

Seit dem letzten update von FHEM (vermutlich von 5.6 auf 5.7) kann ich den permundo SmartPlug PSC234 nicht mehr schalten. Readings funktionieren, aber set ... on/off bewirkt nichts. Auch erneutes Einlernen in FHEM zeigt keine Änderung. Direktverbindung Taster <-> Permundo SmartPlug funktioniert aber.
Hat jemand das gleiche Problem oder weiß sogar eine Lösung?

Grüße

Lolle

krikan

Hallo!
Kann bei mir mit aktuellem FHEM keine Funktionsprobleme feststellen. Die Update- und Anoassungshinweise beim Update 5.7 hast Du sicherlich beachtet.
Um Dir helfen zu können, wären logs mit verbose 5 der Schaltvorgänge, list usw. (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Welche_Infos_sollten_Anfragen_im_EnOcean-Forum_enthalten.3F) evtl. hilfreich.
Gruß, Christian

lolle

Jetzt hab ichs doch selbst rausgefunden: aus irgendeinem Grund hatte ich für die Permundo SmartPlugs in meiner fhem.cfg kein subDef attribut gesetzt. Mit der älteren FHEM Version hat das scheinbar trotzdem funktioniert, nur mit der neuen nicht.
Jetzt hab ich das Attribut dazugefügt und es funzt wieder alles.

Danke auf jeden Fall für die angebotene Hilfe!

Lolle

bert

Hallo,
habe hier 2 x PSC234 und bekommen diese nicht in FHEM angelernt. Mit FT55/FT4 geht es wunderbar. Hängt es ev. meinem alten FAM-USB mit TCM120 ?

Bert

klaus.schauer


peri

Hallo zusammen,
ich habe 2 gebrauchte PSC234 gekauft und natürlich Factory Reset gemäß Anleitung durchgeführt. Trotzdem ist energy0 nicht auf 0.
Ich finde auch nix dazu, wie das per Taster zurückzusetzen ist. Reading an sich funktioniert wie gewünscht.

   set <steckdose> measurement reset trigger

bringt auch nix. Hat jemand eine Idee?