Hallo Leute,
wollte mal fragen, ob es eine Möglichkeit gibt, das ECMD-Modul für nen Seriellen Port vom Standard-8n1 auf 7e1 umzukonfigurieren.
Habe dazu leider nur einen Thread vom Hebst letzten Jahres gefunden, wo eine Anpassung der DevIO abgewiesen wurde:
http://forum.fhem.de/index.php?topic=15506.0 (http://forum.fhem.de/index.php?topic=15506.0)
Bräuchte das für einen Voltcraft Smartmeter, der sich leider nicht auf 8n1 umstellen lässt.
Im schlimmsten Fall müsst ich wohl eine Kopie vom ECMD machen und da drinnen die Konfiguration erstellen (Was ja aber eigentlich nicht grade im Sinne des Erfinders ist)
Hat jemand eine Idee oder nen Vorschlag hierzu?
Danke im voraus,
lg, Icinger
Hallo,
ich hatte ein ähnliches Problem,
da musste ich ECMD umschreiben...
http://forum.fhem.de/index.php/topic,17765.0.html
Generell bin ich auch für die Anpassung der DevIO, denke es gibt immer mehr und mehr Fälle, wo man verschiedenen Einstellungen der Seriellen Schnittstelle benötigt.
Den von dir verlinkten Thread hatte ich heute zufällig auch gefunden, könnte den Lösungsansatz leider nicht ganz verstehen.
Moin fischle,
ja, obwohls heisst, die Serielle Schneittstelle stirbt aus, gibt's immer noch massig Anwendungsfälle und eben auch immer wieder solche Exoten.
Die in dem Link dargestellte Adaption ist IMHO das einfachste, was es gibt, weil nur 2 kleine Codeblöcke ausgetauscht werden müssen, und damit eine
1) Konfig-Möglichkeit für neue Devices und
2) eine 100%ige Kompatibilität für bestehende Devices gegeben ist.
Habe das testweise mal so abgeändert bei mir und klappt soweit ganz ordentlich.
Jetzt habe ich das nächste Problem:
NetIO splittet die Antworten nach Gutdünken in mehrere Events auf:
2014.06.02 05:56:36 5: ECMDDevice: Analyze command >{"/?!".chr(13).chr(10)}<
2014.06.02 05:56:36 1: Voltcraft: unexpected answer "/" received (wrote "/?!\r\n", expected /EFR5\\EFR-M4-DRV004101222\n)
2014.06.02 05:56:36 4: ECMDDevice Strom Init /
2014.06.02 05:56:36 2: autocreate: define ECMDDevice message EFR5\EFR-M4-DRV00
2014.06.02 05:56:36 1: ERROR: Unknown module message
2014.06.02 05:56:36 2: autocreate: define ECMDDevice message 4101222
2014.06.02 05:56:36 1: ERROR: Unknown module message
2014.06.02 05:56:40 5: ECMDDevice: Analyze command >{chr(6)."050".chr(13).chr(10)}<
2014.06.02 05:56:40 4: ECMDDevice Strom Init2
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message EFR-M4-DRV004101222
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message 1
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message -0:0.0.0*255(G
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message ETTONE)
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message 1
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message -0:1.8.0*255(1
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message 3790.16*kWh)
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message 1
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message -0:2.1.7*255(0610
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message 0.29*kWh)
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:40 2: autocreate: define ECMDDevice message 1
2014.06.02 05:56:40 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message -0:4.1.7*255(01807
2014.06.02 05:56:41 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message .11*kWh)
2014.06.02 05:56:41 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message 1
2014.06.02 05:56:41 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message -0:6.1.7*255(05882
2014.06.02 05:56:41 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message .74*kWh)
2014.06.02 05:56:41 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message 1
2014.06.02 05:56:41 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message -0:21.7.255*255(
2014.06.02 05:56:41 1: ERROR: Unknown module message
2014.06.02 05:56:41 2: autocreate: define ECMDDevice message 0000.2762*kW)
2014.06.02 05:56:41 1: ERROR: Unknown module message
Eigentlich sollte die Kommunikation folgendermaßen ablaufen:
S: "/?!".cr.lf
R: /EFR5\EFR-M4-DRV004101222
S: chr(6)."050".cr.lf
R:
1-0:1.8.0*255(13790.16*kWh)
1-0:2.1.7*255(06100.29*kWh)
1-0:4.1.7*255(01807.11*kWh)
1-0:6.1.7*255(05882.74*kWh)
1-0:21.7.255*255(0000.2762*kW)
Meine vorläufige ClassDef zum testen:
set Init cmd {"/?!".chr(13).chr(10)}
set Init expect "/EFR5\\EFR-M4-DRV004101222\n"
#set Init postproc {fhem("set %NAME Init2")}
set Init2 cmd {chr(6)."050".chr(13).chr(10)}
reading L1_in match "^1-0:21.7.255\*255.*\n"
#reading L1_in postproc
# S: "/?!" crlf
# R: /EFR5\EFR-M4-DRV004101222
# S: chr(6) "050" crlf
# R:
# 1-0:1.8.0*255 - Eigentumsnummer (max 20 zeichen)
# 1-0:1.8.0*255 - Zählerstand in kWh mit 6 Vor- und 2 Nachkommastellen
# 1-0:2.1.7*255 - momentan eingespeiste Leistung Phase 1
# 1-0:4.1.7*255 - momentan eingespeiste Leistung Phase 2
# 1-0:6.1.7*255 - momentan eingespeiste Leistung Phase 3
# 1-0:21.7.255*255 - momentan bezogene Leistung Phase 1
# 1-0:41.7.255*255 - momentan bezogene Leistung Phase 2
# 1-0:61.7.255*255 - momentan bezogene Leistung Phase 3
# 1-0:1.7.255*255 - bezogene Leistung, Summe aller Phasen
# 1-0:96.5.5*255 - Status - Bit [6] --> 0=Leerlauf, 1=oberhalb Anlauf
# Bit [5] --> gesetzt bei Ausfall von L1
# Bit [4] --> gesetzt bei Ausfall von L2
# Bit [3] --> gesetzt bei Ausfall von L3
# Bit [2] --> reserviert, immer 0
# Bit [1] --> Telegramm wird synchron im festen zeitraster gesendet
# Bit [0] --> 0=kein Fehler, 1=Fehler
# 0-0:96.1.255*255 - Seriennummer (max 20 Zeichen)
Hat vielleicht jemand einen Ansatz, warum DevIO das so komisch aufsplittet? Könnte das Timeout zu kurz sein für 9600 Baud?
lg, Icinger
Hallo,
das Problem mit den zerhakten Daten hatte ich auch. Ich habe dafür noch ein 100ms Timeout vor dem Lesen eingebaut. Ist in meinem 4. Beitrag zu sehen, schau mal wo ich
select(undef, undef, undef,0.1); #sleep for 100ms
eingebaut habe.
Hat für mich das Problem gelöst.
Hi,
schau mal hier,
da ist beschrieben, wie man andere Paritäten usw. verwenden kann.
http://forum.fhem.de/index.php/topic,23961.msg173974.html#msg173974
Danke für den Tip, fischle, aber ich habs jetzt so gelöst, dass ich die DevIO laut meinem ersten Beitrag angepasst habe.
Das Problem mit dem willkürlichen Aufsplitten der Antworten habe ich so gelöst, dass ich in der Classdef ein Reading auf .* gemacht habe.
Als postproc wird dann einfach eine Sub in 99_myutils aufgerufen:
sub ProcessVoltcraft($$)
{
my ($name,$stri)=@_;
my $hash = $defs{$name};
$VoltcraftString=$VoltcraftString.$stri;
while(index($VoltcraftString,chr(13).chr(10)) ne -1)
{
my $rmsg="";
$rmsg = substr($VoltcraftString, 0, index($VoltcraftString,chr(13).chr(10)));
my $rs = substr($rmsg,index($rmsg,"(")+1,index($rmsg,")"-1));
$rs=substr($rs,0,index($rs,"*k")-1);
if (index($rmsg, "1-0:1.8.0*255") != -1) { readingsSingleUpdate($hash, "energy",$rs + 82064.35 , 1); }
if (index($rmsg, "1-0:2.1.7*255") != -1) { readingsSingleUpdate($hash, "Einspeisung_L1",$rs , 1); }
if (index($rmsg, "1-0:4.1.7*255") != -1) { readingsSingleUpdate($hash, "Einspeisung_L2",$rs , 1); }
if (index($rmsg, "1-0:6.1.7*255") != -1) { readingsSingleUpdate($hash, "Einspeisung_L3",$rs , 1); }
if (index($rmsg, "1-0:21.7.255*255") != -1) { readingsSingleUpdate($hash, "current_L1",$rs , 1); }
if (index($rmsg, "1-0:41.7.255*255") != -1) { readingsSingleUpdate($hash, "current_L2",$rs , 1); }
if (index($rmsg, "1-0:61.7.255*255") != -1) { readingsSingleUpdate($hash, "current_L3",$rs , 1); }
if (index($rmsg, "1-0:1.7.255*255") != -1) { readingsSingleUpdate($hash, "current",$rs , 1); }
if (index($rmsg, "0-0:96.1.255*255") != -1) { readingsSingleUpdate($hash, "Seriennummer",$rs , 1); }
# 1-0:1.8.0*255 - Eigentumsnummer (max 20 zeichen)
# 1-0:1.8.0*255 - Zählerstand in kWh mit 6 Vor- und 2 Nachkommastellen -> 1-0:1.8.0*255(13790.16*kWh)
# 1-0:2.1.7*255 - momentan eingespeiste Leistung Phase 1 -> # 1-0:2.1.7*255(06100.29*kWh)
# 1-0:4.1.7*255 - momentan eingespeiste Leistung Phase 2
# 1-0:6.1.7*255 - momentan eingespeiste Leistung Phase 3
# 1-0:21.7.255*255 - momentan bezogene Leistung Phase 1 -> # 1-0:21.7.255*255(0000.2762*kW)
# 1-0:41.7.255*255 - momentan bezogene Leistung Phase 2
# 1-0:61.7.255*255 - momentan bezogene Leistung Phase 3
# 1-0:1.7.255*255 - bezogene Leistung, Summe aller Phasen
# 1-0:96.5.5*255 - Status - Bit [6] --> 0=Leerlauf, 1=oberhalb Anlauf
# Bit [5] --> gesetzt bei Ausfall von L1
# Bit [4] --> gesetzt bei Ausfall von L2
# Bit [3] --> gesetzt bei Ausfall von L3
# Bit [2] --> reserviert, immer 0
# Bit [1] --> Telegramm wird synchron imfesten zeitraster gesendet
# Bit [0] --> 0=kein Fehler, 1=Fehler
# 0-0:96.1.255*255 - Seriennummer (max 20 Zeichen)
$VoltcraftString = substr($VoltcraftString, index($VoltcraftString,chr(13).chr(10))+1);;
}
Log3 undef,5,"TotalString: $VoltcraftString";
}
Ist sicher nicht das Gelbe vom Ei, aber für mich funktionierts seit gestern durchgehend ohne Fehler.
lg, Ici