Hallo Boris, Hallo Forum,
Zuerst Vielen Dank für die lange gewünschte Überarbeitung des Moduls für alle Ethersex-Plattformen. Die Ankündigung und die Dateien dazu sind hier (http://forum.fhem.de/index.php/topic,21515.msg149911.html) zu finden.
Seit zwei Abenden beschäftige ich mich damit, werde aber noch nicht so ganz schlau aus der neuen Syntax. Die Übernahme der ungeänderten alten classdef geht schief und FHEM hängt komplett. Tests sind also nur- wie schon beschrieben- nicht auf dem Produktivsystem durchzuführen.
Die Beispiele der classdef und zugehörige Abschnitte der fhem.cfg sollten wir hier sammeln, damit Andere es leichter haben, ihre Konfiguration anzupassen und das Modul auch nutzen zu können. Für die "im Stoff" stehenden Programmierer ist das sicher kein Ding und in 5 Minuten angepasst. Bin gerade noch dabei, meine classdef's anzupassen und die Beispiele nachzuvollziehen und zu testen.
Beispiel: Aus bisher
get value cmd {"adc get %channel\n"}
get value params channel
get value postproc { s/^(\d+)\n$/$1/;; $_ }
wird jetzt
get value cmd {"adc get %channel\n"}
get value params channel
get value expect "\d+\n"
get value postproc { s/^(\d+)\n$/$1/;; $_ }
In der dritten Zeile wird mit dem neuen expect mitgeteilt, das in diesem Fall eine ein- oder mehrstellige Zahl sowie ein newline erwartet wird.
Wie sehen eure classdefs aus?
Viele Grüße, Ricardo
Eines von drei Knöpfchen drücken an einer Fernsteuerung (Ethersex auf AVR-NET-IO):
# these are the numbers of the buttons as hex chars from 0 to f;
params btnup btnstop btndown
# setter definitions for opening, stopping and closing the shutters
set up cmd {"io set ddr 2 ff\n\000io set port 2 1%btnup\n\000wait 1000\n\000io set port 2 00\n"}
set up expect ".+"
set up postproc { s/^OK\n\000?OK\n\000?OK\n\000?OK\n\000?$/up/; "$_" eq "up" ? undef : "error"; }
set stop cmd {"io set ddr 2 ff\n\000io set port 2 1%btnstop\n\000wait 1000\n\000io set port 2 00\n"}
set stop expect ".+"
set stop postproc { s/^OK\n\000?OK\n\000?OK\n\000?OK\n\000?$/stop/; "$_" eq "stop" ? undef : "error"; }
set down cmd {"io set ddr 2 ff\n\000io set port 2 1%btndown\n\000wait 1000\n\000io set port 2 00\n"}
set down expect ".+"
set down postproc { s/^OK\n\000?OK\n\000?OK\n\000?OK\n\000?$/down/; "$_" eq "down" ? undef : "error"; }
Ausgang ein- und ausschalten (NetServer/Pollin auf AVR-NET-IO):
# these are the numbers of the output pin from 1 to 8
params out
set on cmd { "setport %out.1\r\n" }
set on expect "^(ACK|NAK).*$"
set off cmd { "setport %out.0\r\n" }
set on expect "^(ACK|NAK).*$"
Heute habe ich die 1wire Sensoren getestet. Der Beitrag im Wiki erscheint mir zu "umständlich", da dort die Messung erst mit 1w convert angestoßen werden muss, was doch E6 bereits mit Polling selbst erledigen kann. Ich habe 30sec. gewählt. Der Code wird dadurch etwas einfacher.
1wire.classdef
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get temperature cmd {"1w get %devID\n"}
get temperature expect ".*"
In FHEM selbst zuerst wieder mit define dem Sensor einen Namen und die entsprechende 1wire-ID zuweisen.
Dann mit get <Sensorname> temperature die Messung aktualisieren. Der Wert ist im ungünstigsten Fall (bei mir) 30sec. "alt".
Ich habe "temperature" gewählt, damit das Reading einen identischen Namen wie alle Temperatur-Readings der anderen Sensoren besitzt.
Für eine zyklische Messung: Mit define Sensor_1_Messung at +*00:03 get Sensor_1 temperature
bekommt ihr dann alle 3 Minuten das reading aktualisiert.
Viel Spaß beim Testen, Ricardo
Es geht schon wieder um 1wire-Temperatur-Sensoren. Die Überlegung ist, die 1w-Sensoren den states und readings anderer Sensoren weiter anzupassen. Dazu habe ich nun ein paar kleine Änderungen in der 1wire.classdef vorgenommen:
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get T: cmd {"1w get %devID\n"}
get T: expect ".*"
Damit kann ich nun mit T: identisch zu anderen Sensoren loggen, habe ein state mit T: <Temperatur> und ein reading T:. Nun fehlt noch das reading temperature, was ich zwar mit einem Notify als Userreading erstellen könnte, eleganter jedoch in der classdef mit
get T: postproc {\
my $hash = $defs{%NAME};\
my $temperature = $1;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
\
} einmalig für alle DS1820 erstellen könnte.
Mir diesem postproc erhalte ich gar keine Messwerte, kein reading temperature, CHANGED bei den Internals wird gesetzt und das Log sieht so aus:
2014.03.22 10:15:31 3: NETIO_WZ: write "1w get 10008b7702080057\n", expect ".*"
2014.03.22 10:15:31 3: NETIO_WZ: read "20.4\n"
2014.03.22 10:15:31 3: NETIO_WZ: write "1w get 2890a5200500000b\n", expect ".*"
2014.03.22 10:15:31 3: NETIO_WZ: read "20.5\n"
2014.03.22 10:15:31 3: NETIO_WZ: write "1w get 284c8820050000a6\n", expect ".*"
2014.03.22 10:15:31 3: NETIO_WZ: read "20.4\n"
2014.03.22 10:15:31 3: NETIO_WZ: write "1w get 28521520050000b5\n", expect ".*"
2014.03.22 10:15:31 3: NETIO_WZ: read "20.5\n"
2014.03.22 10:15:31 3: Sensoren_Messung: T:
T:
T:
T:
Ohne den postproc-Teil erhalte ich wieder brauchbare Werte:
2014.03.22 10:18:16 3: NETIO_WZ: write "1w get 10008b7702080057\n", expect ".*"
2014.03.22 10:18:16 3: NETIO_WZ: read "20.4\n"
2014.03.22 10:18:16 3: NETIO_WZ: write "1w get 2890a5200500000b\n", expect ".*"
2014.03.22 10:18:16 3: NETIO_WZ: read "20.4\n"
2014.03.22 10:18:16 3: NETIO_WZ: write "1w get 284c8820050000a6\n", expect ".*"
2014.03.22 10:18:16 3: NETIO_WZ: read "20.4\n"
2014.03.22 10:18:16 3: NETIO_WZ: write "1w get 28521520050000b5\n", expect ".*"
2014.03.22 10:18:16 3: NETIO_WZ: read "20.5\n"
2014.03.22 10:18:16 3: Sensor_1_Messung: T: 20.4
T: 20.4
T: 20.4
T: 20.5
Die überzähligen Zeilenumbrüche sollten kein Problem darstellen... 8)
Hat jemand eine Idee?
Viele Grüße, Ricardo
Zitat von: kpwg am 22 März 2014, 10:27:21
get T: postproc {\
my $hash = $defs{%NAME};\
my $temperature = $1;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
\
}
Der Postprocessor operiert auf $_. Probier mal $_ statt $1. Ein eingestreuseltes Log3 $hash,1,$_ hilft vielleicht bei der Fehlersuche.
Grüße
Boris
Da hast Du natürlich Recht. Es funktioniert! Habe die readings nun passend gemacht:
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get T: cmd {"1w get %devID\n"}
get T: expect ".*"
get T: postproc {\
my $hash = $defs{%NAME};\
my $temperature = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "T:", $temperature, 1);\
readingsSingleUpdate($hash, "state", $temperature, 1);\
\
}
Damit sieht das jetzt so aus:
(http://abload.de/img/1wire_messungzsfvy.jpg)
Viele Grüße, Ricardo
Hallo Ricardo,
deine Lösung für 1wire Temperaturen ist sehr sauber - gefällt mir gut.
Zitat von: kpwg am 21 März 2014, 20:16:35
Der Beitrag im Wiki erscheint mir zu "umständlich", da dort die Messung erst mit 1w convert angestoßen werden muss, was doch E6 bereits mit Polling selbst erledigen kann. Ich habe 30sec. gewählt. Der Code wird dadurch etwas einfacher.
Kannst Du das ein wenig näher erklären? Muss man das Polling mit E6 bereits beim Kompilieren von Ethersex einstellen? Wo wird das Polling-Intervall gewählt?
Gruss
Tobias
hallo,
so.. habe jetzt die 2. Version noch mal getestet. Alles was mit der alten Version ging funktioniert auch wieder. Allerdings musste ich die classdef's anpassen. Hauptsächlich wegen "\n" und "\000". Soweit oK.
Was ich noch nicht Verstanden habe ist die Funktion
reading <reading> match "<regex>"
Ich habe bis jetzt mit der geänderten Version von Ulli mit der recv Funktion gearbeitet. Wenn ich es richtig verstanden habe soll das ähnlich funktionieren? Wenn das so ist, wäre ich für ein Beispiel dankbar.
Bis jetzt funktioniert es so:
bei Änderung des Zustands eines Ein oder Ausgang sendet der Controller von sich aus zB. "Port 2 3 1". Port ist zum erkennen, 2 wäre dann Port C, 3 das 4. Pin und 1 für high.
Das Device ist so definiert
define PORT91C3 ECMDDevice ECMD91A 2 3
Die classdef sieht dafür so aus
params port pin
recv on cmd {"port %port %pin 1"}
recv off cmd {"port %port %pin 0"}
vielen Dank und LG
Zitat von: Tom_S am 22 März 2014, 18:17:59
Wenn das so ist, wäre ich für ein Beispiel dankbar.
Was ist am Beispiel aus der commandref.html in meinem Post im Developer-Board nicht verständlich?
Zitat
Bis jetzt funktioniert es so:
bei Änderung des Zustands eines Ein oder Ausgang sendet der Controller von sich aus zB. "Port 2 3 1". Port ist zum erkennen, 2 wäre dann Port C, 3 das 4. Pin und 1 für high.
Deine Definition könnte so aussehen:
reading on match "^port 2 3 1\n$"
reading off match "^port 2 3 0\n$"
Ob da Newlines dahinter sind, mußt Du selbst herausfinden anhand des Logs.
attr PORT91C3 logTraffic 3 ist Dein Freund.
In der aktuellen Version werden die %-Parameter im Match nicht ersetzt. Das könnte eine sinnvolle Erweiterung werden.
Viele Grüße
Boris
Zitat von: tpm88 am 22 März 2014, 18:08:55
Hallo Ricardo,
deine Lösung für 1wire Temperaturen ist sehr sauber - gefällt mir gut.
Kannst Du das ein wenig näher erklären? Muss man das Polling mit E6 bereits beim Kompilieren von Ethersex einstellen? Wo wird das Polling-Intervall gewählt?
Gruss
Tobias
Hallo Tobias,
Danke für die Blumen! Das Polling habe ich bereits beim kompilieren ausgewählt. Die 600sec bzw 30sec sind voreingestellt.
(http://abload.de/img/1wire_menuconfigdqd4y.jpg)
Der
convert Befehl und die Pause werden somit überflüssig. Allerdings wird
1w convert weiterhin mit
OK bestätigt, so das vorhandener Code ohne Fehler funktioniert. Meines Wissens erfolgt bei Polling intern keine Auswertung von
convert.
Viele Grüße, Ricardo
Zitat von: Tom_S am 22 März 2014, 18:17:59
so.. habe jetzt die 2. Version noch mal getestet. Alles was mit der alten Version ging funktioniert auch wieder. Allerdings musste ich die classdef's anpassen. Hauptsächlich wegen "\n" und "\000". Soweit oK.
Ich grübele derzeit darüber, ob die zwischen den Antworten eingefügten \000 wirklich sinnvoll/hilfreich sind. Zumindest in meiner Ethersex-Installation kommt es vor, daß die Antworten zu zwei Befehlen in einem Rutsch zurückgeliefert werden, also als OK\nOK\n. GGf. baue ich das wieder aus.
Ich bin hier auf Eure Meinungen angewiesen.
Viele Grüße
Boris
Boris, ich habe mir nochmals die ADC-Sache angeschaut. das Beispiel aus der neuen commandref sieht so aus:
get value cmd {"adc get %channel\n"}
get value params channel
get value expect "\d+\n"
get value postproc { s/^(\d+)\n$/$1/;; $_ }
Damit kommt zwar dank Substitutionsoperator im postproc der derzimale Wert, jedoch meint das Log dazu:
2014.03.23 11:34:21 0: NETIO_WZ: write "adc get 3\n", expect "\\d+\\n"
2014.03.23 11:34:21 0: NETIO_WZ: read "178 \n"
2014.03.23 11:34:21 1: NETIO_WZ: unexpected answer "178 \n" received (wrote "adc get 3\n", expected "\\d+\\n")
2014.03.23 11:34:21 3: ADC_Messung: value 178
Prinzipell kann man expect ja immer mit ".*" ausstatten, nur ist das nicht das Ziel, oder? Mogeln sich hier zwei Backslashs ein?
Viele Grüße, Ricardo
Hallo,
was erwartetet wird ("expect"), wird maskiert. Aus den \ werden daher \\. Das ist aber überflüssig, weil das Regex ja schon per se maskiert ist. Das werde ich noch ändern.
Das Problem ist das Leerzeichen im empfangenen Wert zwischen der 178 und dem Newline. Du erwartest, um genau zu sein,
^\d \n$
Viele Grüße
Boris
hallo Boris,
danke für die Erläuterung
ZitatIn der aktuellen Version werden die %-Parameter im Match nicht ersetzt.
war der entscheidende Hinweis. Mit einem Pin funktioniert es jetzt. Allerdings wird das Symbol dann erst mit der Webseite aktuallisiert (kein Longpoll).
Aber so richtig klar ist mir das jetzt nicht. Da stehe ich wohl gerade auf der Leitung. Woher weis er welches logische ECMDDevice gemeint ist. Muß ich für ein weiteres Pin (also 2. logisches Device) einfach
reading on match "^port 2 4 1\n$"
reading off match "^port 2 4 0\n$".
das geht aber nicht.
ZitatIch grübele derzeit darüber, ob die zwischen den Antworten eingefügten \000 wirklich sinnvoll/hilfreich sind.
das weis ich leider auch nicht. Im Moment stellt es für mich keinen Mehrwert dar.
LG Tom_S
Zitat von: Dr. Boris Neubert am 23 März 2014, 11:48:31
Das Problem ist das Leerzeichen im empfangenen Wert zwischen der 178 und dem Newline. Du erwartest, um genau zu sein,
^\d \n$
Hallo Boris, das sehe ich anhand des Log genauso. Aber leider klappt es nicht:
2014.03.28 10:12:37 0: NETIO_WZ: write "adc get 3\n", expect "^\\d \\n$"
2014.03.28 10:12:37 0: NETIO_WZ: read "177 \n"
2014.03.28 10:12:37 1: NETIO_WZ: unexpected answer "177 \n" received (wrote "adc get 3\n", expected "^\\d \\n$")
2014.03.28 10:12:37 3: ADC_Messung: value 177 read und expect passen aus meiner Sicht genau zueinander. Vielleicht kannst du bitte bei Gelegenheit nochmal schauen; ich mache mich derweil an die Erstellung gut verwertbarer Readings bereits in der classdef.
Viele Grüße,
Ricardo
Tja, mit Nachdenken kommt man auch von selbst drauf:
get value expect "^\d+ \n$" funktioniert natürlich... ::)
Zitat von: kpwg am 28 März 2014, 13:22:33
get value expect "^\d+ \n$" funktioniert natürlich... ::)
Ups, ich hatte die +-Taste nicht gedrückt. :-[
Viele Grüße
Boris
Zitat von: Tom_S am 24 März 2014, 09:18:52
[\000 entfernen]
das weis ich leider auch nicht. Im Moment stellt es für mich keinen Mehrwert dar.
Ich denke, daß es wieder rausfliegt --> KISS
Grüße
Boris
Zitat von: Dr. Boris Neubert am 28 März 2014, 17:04:16
Ich denke, daß es wieder rausfliegt --> KISS
Grüße
Boris
ich habe \000 gebraucht, um den DHT22 abzufragen. Ohne funktioniert es nicht! (ich erhalte dann keine Feuchte; siehe Folgebeitrag)
Viele Grüße, Ricardo
Es gibt Neuigkeiten: den DHT22 habe ich nun ordentlich eingebunden! Es werden zyklisch mit nur einem at Befehl get WZ_Klima DHT alle Werte geholt und die Readings gesetzt sowie state mit T: xx.x H: xx beschrieben. Das dewpoint-Modul kann diese Daten nutzen! (gerade noch getestet)
Die dht22.classdef sieht folgendermaßen aus:
get DHT cmd {"dht temp\n\000dht humid\n"}
get DHT expect "\d+.\d\n"
get DHT postproc {\
s/(.*)\n(.*)/T: $1 H: $2/; $_;\
my $hash = $defs{%NAME};\
my $temperature = $1;\
my $humidity = $2;\
my $state = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "humidity", $humidity, 1);\
readingsSingleUpdate($hash, "state", $state, 1);\
\
}
Ein Screenshot vom Device:
(http://abload.de/img/dht22_messung79kbi.jpg)
Vielleicht kann jemand weiter testen...
Viele Grüße,
Ricardo
Zitatich habe \000 gebraucht, um den DHT22 abzufragen. Ohne funktioniert es nicht!
ja, aber auch nur weil es im Moment so gefordert wird bei Mehrfachbefehlen.
Wenn es raus fliegt funktioniert es auch ohne. Dann wären die classdefs auch fast kompatibel, bis auf ein paar Newlines.
lG Tom_S
Hallo,
zur Klarstellung: als Befehlsseparator bleibt \000 (statt \n) drin, bei der Konkatenation der Antworten auf solche Mehrfachbefehle wird es nicht (mehr) eingesetzt.
Könntet Ihr alle bitte nochmal testen?
Goto http://forum.fhem.de/index.php/topic,21515.msg155085.html#new (http://forum.fhem.de/index.php/topic,21515.msg155085.html#new)
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 01 April 2014, 19:41:41
zur Klarstellung: als Befehlsseparator bleibt \000 (statt \n) drin, bei der Konkatenation der Antworten auf solche Mehrfachbefehle wird es nicht (mehr) eingesetzt.
Das macht es denk ich etwas einfacher. Von mir erstellte classdefs brauchten das aktuell nicht. Ziel ist jetzt noch der A/D-Wandler als device mit je einem reading pro Kanal sowie eine wirklich einfach handhabbare 2272.classdef für die günstigen Funksteckdosen.
Zitat von: Dr. Boris Neubert am 01 April 2014, 19:41:41
Könntet Ihr alle bitte nochmal testen?
Sehr gerne. Die classdefs für 1wire und DHT22 funktionieren mit dem Update weiterhin einwandfrei.
Viele Grüße, Ricardo
Zitat von: Dr. Boris Neubert am 01 April 2014, 19:41:41
Könntet Ihr alle bitte nochmal testen?
Ich habe ebenfalls erfolgreich - natürlich mit angepassten classdefs - die folgenden Anwendungsfälle (vgl. auch im Wiki unter dem Stichwort AVR Netio) getestet.
- DS1820 1w-Temperaturen am AVR-NetIO mit Ethersex
- 8-Port Relaiskarte am AVR-NetIO
Gruss
Tobias
Hallo,
vielen Dank an Euch Tester.
Hat jemand auch explizit einen Anwendungsfall, bei dem das Gerät spontan Daten an FHEM sendet, also nicht als Antwort auf eine Anfrage durch FHEM? Das betrifft die neue Funktion, Readings zu aktualisieren, wenn ein Gerät von selbst neue Werte sendet.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 05 April 2014, 10:25:38
Hat jemand auch explizit einen Anwendungsfall, bei dem das Gerät spontan Daten an FHEM sendet, also nicht als Antwort auf eine Anfrage durch FHEM? Das betrifft die neue Funktion, Readings zu aktualisieren, wenn ein Gerät von selbst neue Werte sendet.
Hallo Boris, genau diese Funktion kann E6 so nicht. Habe explizit- mit Deinem Zitat/Wortlaut (Link hierher)- in der Entwicklergemeinde nachgefragt. Alle bekannten Möglichkeiten, aus E6 mit C6 eine Aktion zu generieren, bauen eine neue Verbindung auf, antworten jedoch nicht in die bestehende ECMD-Telnet-Verbindung. Ich bleibe dran, weiß jedoch derzeit keine Lösung.
Viele Grüße, Ricardo
Zitat von: kpwg am 05 April 2014, 10:50:34
Alle bekannten Möglichkeiten, aus E6 mit C6 eine Aktion zu generieren, bauen eine neue Verbindung auf, antworten jedoch nicht in die bestehende ECMD-Telnet-Verbindung. Ich bleibe dran, weiß jedoch derzeit keine Lösung.
Achso, jetzt verstehe ich das Problem. Hast Du einen Link für mich, wo das steht? Wie teilt man Ethersex mit, wohin es die neue Verbindung aufbauen soll? Sowas würde einen Server-Mode für das ECMD-Modul erfordern.
Viele Grüße
Boris
Ich denke, ESEND wäre gut geeignet. Ein Link mit Beispiel: http://old.ethersex.de/index.php/ECMD-Befehle_absetzen (http://old.ethersex.de/index.php/ECMD-Befehle_absetzen). Die Handhabung ist einfacher als bei TCP send. Interessant klingt noch httplog; leider nur sehr spärlich dokumentiert, aber hier einzusehen: https://github.com/ethersex/ethersex/blob/master/protocols/httplog/httplog.c (https://github.com/ethersex/ethersex/blob/master/protocols/httplog/httplog.c).
Hallo,
ich nutze das ECMD Device um, über die serielle Schnittstelle, ein SOMFI URTSII Interface anzusteueren.
Dies klappt mit dem bisherigen Modul ganz gut, bis auf ein paar Instabilitäten die einen gelegentlichen restart der Schnittstelle erforderlich machen. Hier erwarte ich von dem neuen Modul Vorteile.
Wenn ich die neuen Module in das Verzeichnis kopiere und FHEM neu starte, bekomme ich aber folgende Fehlermeldungen im Logfile (Auszug):
2014.04.05 14:39:53 1: reload: Error:Modul 67_ECMDDevice deactivated:
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/67_ECMDDevice.pm line 258, near "}) "
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/67_ECMDDevice.pm line 262, near "}) "
2014.04.05 14:39:53 0: Type of arg 1 to keys must be hash (not hash element) at ./FHEM/67_ECMDDevice.pm line 258, near "}) "
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/67_ECMDDevice.pm line 262, near "}) "
2014.04.05 14:39:53 3: Please define Rollo_Essecke first
2014.04.05 14:39:53 3: Please define Rollo_Essecke first
Subroutine ECMDDevice_Initialize redefined at ./FHEM/67_ECMDDevice.pm line 40, <$fh> line 63.
Subroutine ECMDDevice_AnalyzeCommand redefined at ./FHEM/67_ECMDDevice.pm line 58, <$fh> line 63.
Subroutine ECMDDevice_GetDeviceParams redefined at ./FHEM/67_ECMDDevice.pm line 67, <$fh> line 63.
Subroutine ECMDDevice_DeviceParams2Specials redefined at ./FHEM/67_ECMDDevice.pm line 81, <$fh> line 63.
Subroutine ECMDDevice_ReplaceSpecials redefined at ./FHEM/67_ECMDDevice.pm line 96, <$fh> line 63.
Subroutine ECMDDevice_Changed redefined at ./FHEM/67_ECMDDevice.pm line 109, <$fh> line 63.
Subroutine ECMDDevice_PostProc redefined at ./FHEM/67_ECMDDevice.pm line 132, <$fh> line 63.
Subroutine ECMDDevice_Get redefined at ./FHEM/67_ECMDDevice.pm line 151, <$fh> line 63.
Subroutine ECMDDevice_Set redefined at ./FHEM/67_ECMDDevice.pm line 200, <$fh> line 63.
Ich habe nicht genug Perl KnowHow, um die Ursache zu finden, aber kann es mit der Verbindung über die serielle Schnittstelle zu tun haben?
Gruß
Heiner
Hallo Heiner,
bitte füge noch Deine Definition der ECMD- und ECMDDevice-Geräte sowie Deine classdef bei.
Danke
Boris
Hallo Boris,
ECMD und ECMDDEVICEdefinitionen:
define somfyurtsi ECMD serial /dev/ttyUSB0@9600
attr somfyurtsi classdefs somfy=/opt/fhem/somfy.classdef
define Rollo_Essecke ECMDDevice somfy 05
attr Rollo_Essecke room Rolladen
attr Rollo_Essecke webCmd up:down:light:stop
define Rollo_kueche ECMDDevice somfy 06
attr Rollo_kueche room Rolladen
attr Rollo_kueche webCmd up:down:light:stop
define Rollo_Schlafzimmer ECMDDevice somfy 04
attr Rollo_Schlafzimmer room Rolladen
attr Rollo_Schlafzimmer webCmd up:down:light:stop
define Rollo_bad ECMDDevice somfy 03
attr Rollo_bad room Rolladen
attr Rollo_bad webCmd up:down:light:stop
define Rollo_heiner ECMDDevice somfy 02
attr Rollo_heiner room Rolladen
attr Rollo_heiner webCmd up:down:light:stop
define Rollo_helga ECMDDevice somfy 01
attr Rollo_helga room Rolladen
attr Rollo_helga webCmd up:down:light:stop
Die Classdef Datei sieht folgendermassen aus:
# Klassendefinition für SOMFY Rolläden
params motor
set up cmd {"01%motorU\r"}
# set up expect "01%motorU\r\n"
set down cmd {"01%motorD\r"}
# set down expect "01%motorD\r\n"
set stop cmd {"01%motorS\r"}
# set stop expect "01%motorS\r\n"
set light cmd {"01%motorU;;W6;;01%motorS\r"}
# set light expect {"01%motorU;;W6;;01%motorS\r\n"}
Die auskommentierten Zeilen sind schon für deine neue Version vorbereitet, aber bisher noch nicht aktiviert.
Gruß
Heiner
Hallo Heiner,
ich habe die Module mit Deinen Definitionen und Deiner Klassendefinition getestet und ich bekomme keinen Absturz. Alles funktioniert, wie es soll.
Hast Du beide Module aus meinem Beitrag aktualisiert? Kannst Du bitte FHEM neustarten?
Viele Grüße
Boris
Hallo Boris,
ich habe es sicherheitshalber noch einmal aus deinem Post aktualisiert, um eine Verwechselung auszuschliessen. Exakt das gleiche Ergebnis.
Darüberhinaus kommen die Fehlermeldungen ja auch aus dem Logfile nach dem Neustart von fhem.
Wenn ich die "alten" Module zurückspiele, funktioniert alles wieder.
Ich habe leider die nächste Woche keine Zeit etwas auszuprobieren, da ich auf Dienstreise bin.
Gruß
Heiner
Hallo Heiner,
welche Perl-Version (perl -v) und welches Unix (uname -a) benutzt Du?
Kannst Du bitte noch die beiden beanstandeten Zeilen wie folgt ändern?
Alt:
258 foreach my $classname (keys $IOhash->{fhem}{classDefs}) {
262 foreach my $r (keys $classDef->{readings}) {
Neu:
258 foreach my $classname (keys %{$IOhash->{fhem}{classDefs}}) {
262 foreach my $r (keys %{$classDef->{readings}}) {
Der Ausdruck hinter keys wird also mit %{ } umklammert.
Zitat von: H_doc am 06 April 2014, 18:12:43
Ich habe leider die nächste Woche keine Zeit etwas auszuprobieren, da ich auf Dienstreise bin.
Geht mir genauso. Also nächstes Wochenende müssen wir weitersuchen.
Viele Grüße
Boris
Hallo Boris,
Perl version ist 5.10.0
Linux version ist 2.6.33.2 (läuft auf einem QNAP 419P
Rest dann nächste Woche,
Danke
Heiner
hallo Boris,
danke für die Hilfe, bin jetzt erst dazu gekommen nochmal zu testen.
ZitatHat jemand auch explizit einen Anwendungsfall, bei dem das Gerät spontan Daten an FHEM sendet, also nicht als Antwort auf eine Anfrage durch FHEM?
ausgehend vom Beispiel in meinem 1. Post habe ich folgendes hinbekommen:
mein Gerät sendet bei Änderung des Port A3 auf high "port 0 2 1\n" und "port 0 2 0\n" für low.
Ohne Definition in der classdev erhalte ich folglich im Eventmonitor:
Global global UNDEFINED ECMDDevice message port 0 2 1
Global global UNDEFINED ECMDDevice message port 0 2 0
In der classdev habe ich, wie in deinem Beispiel beschrieben, folgendes definiert:
reading on match "^port 0 2 0\n$" (low für on)
reading off match "^port 0 2 1\n$"
Ich habe danach ein Reading on (port 0 2 0) ein Reading off (port 0 2 1) und state (offport 0 2 1)
Der Eventmonitor sagt nichts mehr.
Wenn ich den Status mit
reading on postproc {substr($_, 9, 1) == 0 ? "" : "Fehler";}
reading off postproc {substr($_, 9, 1) == 1 ? "" : "Fehler";}
ausfilter bekomme ich den korrekten state (on : off)
Soweit ok. allerdings sind diese Readings dann in allen definierten ECMDDevice
die auf der classdev aufbauen, also auch A1 A2 A4 usw.
ZitatAber so richtig klar ist mir das jetzt nicht. Da stehe ich wohl gerade auf der Leitung. Woher weis er welches logische ECMDDevice gemeint ist.
ZitatIn der aktuellen Version werden die %-Parameter im Match nicht ersetzt. Das könnte eine sinnvolle Erweiterung werden.
dann würde es warscheinlich funktionieren (oder für jedes Device eine eigene classdev).
Wie kann ich bei Eintreffen der Nachricht ein Event auslösen? (Damit sich das Symbol ändert)
Grüße
Tom_S
habe noch etwas getestet. Mein Gerät sendet jetzt einmal in der Minute alle OW Temperaturen in der Form
"OW 21,4 15,3 22,8 ..... \n"
die classdef sieht so aus
reading temp match "^OW .*"
reading temp postproc {my $a = substr($_, 3, -2,);\
my $hash = $defs{%NAME};\
my @temperature = split "[ \t]+", $a;\
readingsSingleUpdate($hash, "temperature 0", $temperature[0], 1);\
readingsSingleUpdate($hash, "temperature 1", $temperature[1], 1);\
readingsSingleUpdate($hash, "temperature 2", $temperature[2], 1);\
readingsSingleUpdate($hash, "temperature 3", $temperature[3], 1);\
readingsSingleUpdate($hash, "temperature 4", $temperature[4], 1);\
readingsSingleUpdate($hash, "temperature 5", $temperature[5], 1);\
readingsSingleUpdate($hash, "temperature 6", $temperature[6], 1);\
readingsSingleUpdate($hash, "temperature 7", $temperature[7], 1);\
}
Ich habe dann für jeden Sensor ein Reading.
mfg
Hallo,
Zitat von: Tom_S am 11 April 2014, 12:59:07
habe noch etwas getestet. Mein Gerät sendet jetzt einmal in der Minute alle OW Temperaturen in der Form
"OW 21,4 15,3 22,8 ..... \n"
die classdef sieht so aus
...
}
Ich habe dann für jeden Sensor ein Reading.
Warum so aufwendig? Definiere in der classdef einfach 8 Temperatur-Readings temperature0 bis temperature7, die alle auf denselben Regex "^OW .*\n$" lauschen. ECMD ist nämlich mit Absicht so programmiert, daß
alle Readings ausgewertet werden, bei denen einkommende Nachrichten auf das Regex passen. In den individuellen postprocs brauchst Du dann nur mit split die richtige Spalte rauszusuchen und zurückzugeben.
Viel Erfolg!
Boris
hallo Boris,
meinst du
>reading temperature0 match "^OW .*"
>reading temperature0 postproc {split (/ /, $_, 2);}
usw.
Ist einfacher, gibt immer mehrere Lösungen, bin nur nicht darauf gekommen.
Gibt es auch eine Lösung für mein Problem mit den Ports? Da komme ich nicht weiter.
mfg Tom_S
Ports: über Parameter (Makro) %port
Boris
habe es so probiert:
params port
reading on match "^port 0 %port 0\n$"
reading off match "^port 0 %port 1\n$"
geht nicht, das habe ich wohl noch nicht begriffen. Wie mache ich das mit einem Makro? Die Parameter gehen ja so nicht.
Gruß
Logs please
B.
hallo Boris
LogTrafic 3
definiert habe ich
reading on match "^port 2 4 1\n$"
reading off match "^port 2 4 0\n$"
2014.04.12 13:05:32 3: NETIO91: read "port 2 4 1\n"
2014.04.12 13:05:52 3: NETIO91: read "port 2 4 0\n"
2014.04.12 13:06:02 3: NETIO91: read "port 2 5 1\n"
2014.04.12 13:06:02 2: autocreate: define ECMDDevice message port 2 5 1
2014.04.12 13:06:02 1: ERROR: Unknown module message
2014.04.12 13:06:06 3: NETIO91: read "port 2 5 0\n"
2014.04.12 13:06:06 2: autocreate: define ECMDDevice message port 2 5 0
2014.04.12 13:06:06 1: ERROR: Unknown module message
Port 2 4 wird erkannt, im Prinzip funktioniert es ja. Nur das ich keinen weiteren Port definieren kann bzw. alle über die classdef definierten Geräte (alle Pins) schalten wenn ein Match erkannt wird.
ich kann natürlich noch zB.:
reading on match "^port 2 5 1\n$"
reading off match "^port 2 5 0\n$"
aber dann ist egal was erkannt wird, alle Pins gehen gleichzeitig auf on oder off.
Tom_S
wenn ich die Variablen verwende wird nichts erkannt.
params port pin
reading on match "^port %port %pin 1\n$"
reading off match "^port %port %pin 0\n$"
2014.04.12 13:23:42 3: NETIO91: read "port 2 4 1\n"
2014.04.12 13:23:42 2: autocreate: define ECMDDevice message port 2 4 1
2014.04.12 13:23:42 1: ERROR: Unknown module message
2014.04.12 13:23:52 3: NETIO91: read "port 2 4 0\n"
2014.04.12 13:23:52 2: autocreate: define ECMDDevice message port 2 4 0
2014.04.12 13:23:52 1: ERROR: Unknown module message
2014.04.12 13:23:58 3: NETIO91: read "port 2 5 1\n"
2014.04.12 13:23:58 2: autocreate: define ECMDDevice message port 2 5 1
2014.04.12 13:23:58 1: ERROR: Unknown module message
2014.04.12 13:24:06 3: NETIO91: read "port 2 5 0\n"
2014.04.12 13:24:06 2: autocreate: define ECMDDevice message port 2 5 0
2014.04.12 13:24:06 1: ERROR: Unknown module message
Gruß
Füge bitte define und classdef als Anhang bei. Schaue später zuhause drauf.
B.
die netio.cfg steht in der fhem.cfg
#===============================NETIO91===============================#
include ./config/netio91.cfg
#---------------------------------------------------------------------#
schalten von FHEM aus geht
vielen Dank im voraus
Die neue Version im Post http://forum.fhem.de/index.php/topic,21515.0.html dürfte funktionieren.
Eine vereinfachte ECMD91A.classdef sollte so aussehen:
# In FHEM festlegen => define PORT91A1 ECMDDevice ECMD91A 0 0
# Uebergabeparameter port (0-3) pin (0-7)
params port pin
# Controller sendet die Portzustände bei Änderung. Werden über reading verarbeitet
reading power match "^port %port %pin 0|1\n$"
reading power postproc { s/^.*(\d)\n$/$1/; $_ ? "on" : "off" }
Kannst Du das bitte mal ausprobieren?
Danke
Boris
hallo Boris
aus scheint jetzt zu gehen (also "port 2 4 0\n").
bei on (also "port 2 4 1\n") gehen alle Devices auf on, auch die in der anderen classdef. Im State steht "power off bzw power on)
der Event Monitor sagt nichts
Auszug aus dem Log nach "port 2 4 1\n" und "port 2 4 0\n"
2014.04.12 20:24:48 1: DEBUG>Trying to find a match for "port 2 4 1\n"
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 3 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 2 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 6 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 0 2 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 5 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 4 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 0 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 7 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 2 1 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 0 1 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 0 3 0|1\n$".
2014.04.12 20:24:48 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 20:24:48 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:24:48 1: DEBUG> Trying to match reading power with regular expressing "^port 0 0 0|1\n$".
2014.04.12 20:25:00 1: DEBUG>Trying to find a match for "port 0 0 0\nport 0 1 1\nport 0 2 1\nport 0 3 0\n"
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 3 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 2 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 6 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 0 2 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 5 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 4 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 0 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 7 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 2 1 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 0 1 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 0 3 0|1\n$".
2014.04.12 20:25:00 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 20:25:00 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:00 1: DEBUG> Trying to match reading power with regular expressing "^port 0 0 0|1\n$".
2014.04.12 20:25:06 1: DEBUG>Trying to find a match for "port 2 4 0\n"
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 3 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 2 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 6 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 0 2 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 5 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 4 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 0 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 7 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 2 1 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 0 1 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 0 3 0|1\n$".
2014.04.12 20:25:06 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 20:25:06 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 20:25:06 1: DEBUG> Trying to match reading power with regular expressing "^port 0 0 0|1\n$"
Gruß
Verflixte reguläre Ausdrücke! Das | bindet ganz schwach... Hier die neue Classdef:
# In FHEM festlegen => define PORT91A1 ECMDDevice ECMD91A 0 0
# Uebergabeparameter port (0-3) pin (0-7)
params port pin
# Controller sendet die Portzustände bei Änderung. Werden über reading verarbeitet
# Wir dürfen nicht in ^$ einschließen, weil mehrere Befehle hintereinander kommen können
reading power match "port %port %pin \d\n"
# Modifier s behandelt mehrere Zeilen wie eine einzige;
# aus dem String wird die 0 oder 1 herausgeschnitten
reading power postproc { s/.*port %port %pin (\d)\n.*/$1/s; $_ }
# oder:
#reading power postproc { s/.*port %port %pin (\d)\n.*/$1/s; $_ ? "on" : "off" }
Dabei ist noch berücksichtigt, daß mehrere Befehle am Stück kommen können.
Ferner ist mir noch aufgefallen, daß keine Events erzeugt werden. Der Fehler ist mit der soeben in dem Referenzposting neu angefügten 67_ECMDDevice.pm nun auch Geschichte.
Viele Grüße
Boris
hallo Boris
habe gerade noch eimal getestet. Unabhänig von der postproc (im STATE steht "power port 2 4 0") - da kann man noch nacharbeiten, landen die Komandos jetzt im richtigen Device. Das ist aber nur so, wenn ein einzelnes Komando kommt. Kommen mehrere dann landen alle im zuerst genannten. Im STATE steht dann "power port 2 5 1 port 2 6 0 port 2 4 0"
2014.04.12 21:39:24 1: DEBUG>Trying to find a match for "port 2 4 0\n"
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:39:24 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:39:24 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:39:24 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:40:00 1: DEBUG>Trying to find a match for "2 5 1\n"
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:40:00 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:40:00 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:40:00 2: autocreate: define ECMDDevice message 2 5 1
2014.04.12 21:40:00 1: ERROR: Unknown module message
2014.04.12 21:40:16 1: DEBUG>Trying to find a match for "port 2 5 0\nport 2 6 1\n"
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:40:16 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:40:16 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:16 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:40:32 1: DEBUG>Trying to find a match for "port 2 5 1\nport 2 6 0\n"
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:40:32 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:40:32 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:32 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:40:42 1: DEBUG>Trying to find a match for "port 2 5 0\n"
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:40:42 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:40:42 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:40:42 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:41:00 1: DEBUG>Trying to find a match for "port 0 0 1\nport 0 1 1\nport 0 2 1\nport 0 3 0\n"
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:41:00 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:41:00 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:41:08 1: DEBUG>Trying to find a match for "port 2 5 1\n"
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:41:08 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:41:08 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:41:08 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:42:00 1: DEBUG>Trying to find a match for "port 0 0 1\nport 0 1 1\nport 0 2 1\nport 0 3 0\n"
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:42:00 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:42:00 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:42:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:43:00 1: DEBUG>Trying to find a match for "port 0 0 1\nport 0 1 1\nport 0 2 1\nport 0 3 0\n"
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:43:00 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:43:00 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:43:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:44:00 1: DEBUG>Trying to find a match for "port 0 0 1\nport 0 1 1\nport 0 2 1\nport 0 3 0\n"
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91A2 with class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 1 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91A4 with class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 3 \d\n$".
2014.04.12 21:44:00 1: DEBUG> Checking device ADC5 with class adc...
2014.04.12 21:44:00 1: DEBUG> Checking device PORT91A1 with class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:44:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 0 \d\n$".
2014.04.12 21:45:00 1: DEBUG>Trying to find a match for "port 0 0 1\nport 0 1 1\nport 0 2 1\nport 0 3 0\n"
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C4 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 3 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C3 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 2 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C7 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 6 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91A3 with class ECMD91A...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91A...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 0 2 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device ADC7 with class adc...
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C6 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 5 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C5 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 4 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device ADC6 with class adc...
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C1 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 0 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C8 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 7 \d\n$".
2014.04.12 21:45:00 1: DEBUG> Checking device PORT91C2 with class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to find a match in class ECMD91C...
2014.04.12 21:45:00 1: DEBUG> Trying to match reading power with regular expressing "port 2 1 \d\n$".
Tom_S
Jajaa, die C-Geräte haben ja auch eine andere Classdef. Du mußt die ECMD91C.classdef auch noch analog zur ECMD91A.classdef anpassen.
Viele Grüße
Boris
schon klar, habe ich auch gemacht. Ich habe beide classdef angepasst. Ich denke es liegt daran das ein "port .*" möglich ist. Es wird alles was kommt eingelesen. Es müsste ein Ende zB. durch \n erkannt werden, und was danach kommt all neuer match.
Kannst Du bitte beide classdefs nochmal hier posten? Die ECMD91A.classdef geht bei mir einwandfrei (mit einem per netcat emulierten Device).
Grüße
Boris
sorry, hatte einen Fehler in der postproc.
geht aber trotzdem nicht. Im STATE steht "power on" oder "power off", es kommt aber nur das erste Kommando durch. Bei Einzelkomandos oK aber das zweite geht verloren.
hier die classdefs
Mach mal das $ in
reading power match "port %port %pin \d\n$"
weg.
B.
ja oK. Das war es. jetzt geht es. Aber es wird kein event erzeugt. Somit erhalte ich den STATE erst wenn ich die Seite aktualisiere.
Gruß
Prima.
Hol Dir noch das neue ECMDDevice.pm aus dem Ankündigungs-Posting - das macht Events.
Grüße
Boris
super so geht es.
Eins noch, es gab mal einen Trade weil das Symbol nur ein und nicht wieder ausschaltet. Ich habe damals lange gesucht und dann das Leerzeichen in (aktuelle Version Zeile 117) vor $value gelöscht. dann ging es.
Ist das notwendig, oder kann man das ändern? Wenn ich es wieder raus nehme funktioniert alles.
Gruß
Zitat von: Tom_S am 12 April 2014, 23:02:39
Eins noch, es gab mal einen Trade weil das Symbol nur ein und nicht wieder ausschaltet. Ich habe damals lange gesucht und dann das Leerzeichen in (aktuelle Version Zeile 117) vor $value gelöscht. dann ging es.
Ist das notwendig, oder kann man das ändern? Wenn ich es wieder raus nehme funktioniert alles.
Guten Morgen,
stimmt ... da war was! Habe mir damals so beholfen, das devStateIcon mit
on.*:on:off off.*:off:on zu versehen. Das funktioniert sehr gut.
Hier stand das: http://forum.fhem.de/index.php/topic,10963.msg74636.html#msg74636 (http://forum.fhem.de/index.php/topic,10963.msg74636.html#msg74636)
Eine eigenmächtige Änderung im Modul selbst halte ich immer für den allerletzten Ausweg, wenn etwas überhaupt nicht umsetzbar wäre. Vielleicht kann Boris nochmal schauen, wie das zentral gelöst werden könnte. Wenn nicht => s.o. ::)
Danke Euch beiden schon mal für die rege Diskussion gestern abend. Ich kam zwar nicht an mein System, habe für mich aber ne Menge mitgenommen, was ich die nächsten Tage in classdefs umsetze und hier dann wieder mit Beispiel und Bildchen dokumentiere.
Viele Grüße, Ricardo
Hallo,
wenn man ein Kommando CMD auf ein Gerät absetzt mit Wert VALUE, wird ein Event CMD: VALUE für das Gerät generiert. Für den (neuen) Readings-Mechanismus im ECMDDevice analog ein Event READING: VALUE.
In das state-Reading wird CMD VALUE bzw. READING VALUE geschrieben.
Wenn VALUE definiert aber leer ist, wird trotzdem ein Leerzeichen gesetzt.
Ich habe das dahingehend geändert, daß kein Leerzeichen kommt, wenn VALUE undefiniert oder leer ist.
Siehe bitte Ankündigungsposting.
Grüße
Boris
hallo Boris,
habe alles noch mal getestet. Jetzt funktioniert alles und ich werde es jetzt erst mal so übernehmen.
Mal sehen ob im Betrieb noch was auffällt. Erst mal Danke, sehr schön.
@kpwg
der Vorschlag mit devStateIcon mit on.*:on:off off.*:off:on kam damals. Aber bei über 50 Geräten fand ich das nicht so gut. Jetzt geht es ohne. Kannst ja mal testen.
mfg Tom_S
Hallo Boris,
nach Rueckkehr und JetLag habe ich eben die neueVersion aus deinem Posting probiert.
Es kommt jetzt keine Fehlermeldung mehr und es funzt auch einigermaßen.
Die Verbindung ist zwar nicht sehr stabil und ich muss sehr oft den Port resetten, das kann aber auch an der Verbindung/dem Gerät selbst liegen.
Hier muss ich noch einmal genauer auf Fehlersuche gehen.
Gruß
Heiner
hallo Boris,
habe nun doch noch eine Kleinigkeit - ist mir durch die logs aufgefallen
params port pin
reading power match "port %port %pin \d\n"
reading power postproc { s/.*port %port %pin (\d)\n.*/$1/s; $_ ? "off" : "on" }
funktioniert. Nur das ich das "power" im STATE nicht los werde. "power on : power off"
reading on match "port %port %pin 0\n"
reading off match "port %port %pin 1\n"
reading on postproc { s/.*port %port %pin 0\n.*//s; "$_" eq "" ? "" : "Fehler" }
reading off postproc { s/.*port %port %pin 1\n.*//s; "$_" eq "" ? "" : "Fehler" }
funktioniert auch. Wenn ich hier das attr "event-on-change-reading .*" setze, dann kommen keine Events mehr. Kann mir auch denken warum, on bleib ja on und off bleibt off. Der STATE ändert sich aber. Kannst du da nochmal schauen?
Tom_S
Hallo,
das ist so gewollt. Im state steht READING: VALUE. Wenn Du was anderes willst, mußt Du stateFormat verwenden.
Grüße
Boris
Das dann "power on: power off" steht ist ja oK. War auch nur die Erklärung warum ich Variante zwei probiert habe. Aber ich müsste für die zweite Variante bei "event-on-change-reading .*" ein Event bekommen. Das reading "state" ändert sich doch.
mfg
Tom_S
was mir noch aufgefallen ist:
bei allen ECMDDevices, kommt das attr verbose in der Auswahl auf der Deteilseite zweimal vor.
Vermutlich weil es in 66_ECMD.pm in Zeile 45 mit
$hash->{AttrList}= "classdefs verbose:0,1,2,3,4,5 logTraffic:0,1,2,3,4,5 timeout";
definiert wird und dann in 67_ECMDDevice.pm in Zeile 51 erneut. Du fügst es doch mit
.....IODev class ". $readingFnAttributes;
an. Kann das in ECMDDevice raus ? Es verwirrt etwas und ich habe nicht getestet welches, oder ob beide funktionieren.
Tom_S
Zitat von: Tom_S am 15 April 2014, 09:02:24
Aber ich müsste für die zweite Variante bei "event-on-change-reading .*" ein Event bekommen. Das reading "state" ändert sich doch.
Habe Dein Problem verstanden. Aus historischen Gründen (= ich weiß nicht mehr warum ich das so gemacht habe) wird für das state-reading behauptet, changed wäre falsch, damit kein Event getriggert wird. Ich habe das behoben. Du kannst einfach in Zeile 118 in 67_ECMDDevice.pm das ",1" im Argument von ReadingsBulkUpdate löschen. Dann sollte es gehen.
Viele Grüße
Boris
Zitat von: Tom_S am 15 April 2014, 18:00:22
was mir noch aufgefallen ist:
bei allen ECMDDevices, kommt das attr verbose in der Auswahl auf der Deteilseite zweimal vor.
Vermutlich weil es in 66_ECMD.pm in Zeile 45 mit
$hash->{AttrList}= "classdefs verbose:0,1,2,3,4,5 logTraffic:0,1,2,3,4,5 timeout";
definiert wird und dann in 67_ECMDDevice.pm in Zeile 51 erneut. Du fügst es doch mit
.....IODev class ". $readingFnAttributes;
an. Kann das in ECMDDevice raus ? Es verwirrt etwas und ich habe nicht getestet welches, oder ob beide funktionieren.
Es ist an mir vorübergegangen, daß verbose standardmäßig bei allen Devices gesetzt wird. Es kann in ECMD und ECMDDevice raus. Ist bei mir lokal schon behoben. Wenn die Version in Kürze freigelassen wird, ist es dann allgemein verfügbar.
Danke für die Beobachtung!
Viele Grüße
Boris
hallo Boris,
Zitat
Du kannst einfach in Zeile 118 in 67_ECMDDevice.pm das ",1" im Argument von ReadingsBulkUpdate löschen.
eine ,0. Habe ich gelöscht und es scheint zu gehen. werde ich beobachten. Ich habe einfach keinen Plot hin bekommen. Im LogFile steht "power: on". Woher wohl der Doppelpunkt kommt ??
Grüße
habe das erste readingsBulkUpdate ( Zeile 114 ) auch mit
&& $value ne ""
bei leerem $value auskommentiert. Dann ist auch der Doppelpunkt weg.
hallo Boris,
scheint alles zu laufen. Eine Frage habe ich noch. Ist der Match-String irgendwie begrenzt? Bei mir 52 Zeichen.
2014.04.16 08:58:40 3: NETIO91: read "port 0 3 0\n"
2014.04.16 08:58:42 3: NETIO91: read "port 0 3 1\n"
2014.04.16 08:58:52 3: NETIO91: read "port 0 0 0\nport 0 1 1\nport 0 2 1\nport 0 3 1\n"
2014.04.16 08:59:52 3: NETIO91: read "port 0 0 0\nport 0 1 1\nport 0 2 1\nport 0 3 1\nport"
2014.04.16 08:59:52 3: NETIO91: read " 2 2 1\n"
2014.04.16 08:59:52 2: autocreate: define ECMDDevice message 2 2 1
2014.04.16 08:59:52 1: ERROR: Unknown module message
kann vorerst mal die Ausgabe in der Firmware begrenzen. Kommt im Monent alles zu zur selben Zeit.
Zitat von: Tom_S am 15 April 2014, 21:07:28
habe das erste readingsBulkUpdate ( Zeile 114 ) auch mit
&& $value ne ""
bei leerem $value auskommentiert. Dann ist auch der Doppelpunkt weg.
Wird so berücksichtigt werden im Release.
Grüße
Boris
hallo Boris,
stellst du die fertigen Dateien hier nochmal zum testen zur Verfügung bevor sie per Update verteilt werden?
Weist du wo und warum der Matchstring auf 52 Zeichen begrenzt ist?
mfg
Tom_S
Zitat von: Tom_S am 13 April 2014, 13:15:27
@kpwg
der Vorschlag mit devStateIcon mit on.*:on:off off.*:off:on kam damals. Aber bei über 50 Geräten fand ich das nicht so gut. Jetzt geht es ohne. Kannst ja mal testen.
Ups, nun verstehe ich Deinen Wunsch! ;D Mit meinen aktuell 9 benutzten Geräten sieht das anders aus.
Getestet habe ich: leider funktionierte es trotzdem nicht. ich erhalte stets "on OK" bzw. "off OK". Bin aber der Sache auch noch nicht nachgegangen.
Habe mich an die Intertechno-Aktoren gewagt. Dabei gibt es seitens Ethersex keine Besonderheiten: es muss nur ein RFM12-433 angeschlossen sein und das Intertechno-Protokoll beim Kompilieren aktiviert sein. Derzeit warte ich noch auf Antenne und Pigtail; dann gibts auch Bilder von der Hardware, mit der ich sende.
Die rfm12_it.classdef sieht dabei so aus:
# Uebergabeparameter Intertechno Coding: Familie + Gruppe + Geraet
params it_fam it_group it_dev
# Umsetzung in ECMD Befehle
set on cmd {"rfm12 intertechno %it_fam %it_group %it_dev 1\n"}
set on expect "OK\n"
set on postproc {s/OK\n//; $_;}
set off cmd {"rfm12 intertechno %it_fam %it_group %it_dev 0\n"}
set off expect "OK\n"
set off postproc {s/OK\n//; $_;}
Neu ist das postproc, womit ich per Substitutionsoperator aus dem "OK\n" nichts mache. Damit ist das Reading nun "on" oder "off" und erspart mir "devStateIcon on.*:on:off off.*:off:on". Danke TOM_S für den Denkanstoß! Somit kann ich jetzt ohne Umstände das Symbol mit dem Smartphone toggeln. So schaut das Device nun aus:
(http://abload.de/img/intertechno_wandlampeivj9q.jpg)
Viele Grüße, Ricardo
Zitat von: Tom_S am 17 April 2014, 10:45:58
Weist du wo und warum der Matchstring auf 52 Zeichen begrenzt ist?
Ich weiß nicht, wo das herkommen sollte.
Wie kommst Du darauf, daß der Matchstring (Du meinst das, was in der classdef hinter match steht?) in der Länge begrenzt sei?
Viele Grüße
Boris
hallo Boris,
nein das meine ich nicht. Ich meine das was der Controller auf einmal ausgeben darf, damit es nicht abgeschnitten wird.
Zitat
2014.04.16 08:59:52 3: NETIO91: read "port 0 0 0\nport 0 1 1\nport 0 2 1\nport 0 3 1\nport"
2014.04.16 08:59:52 3: NETIO91: read " 2 2 1\n"
2014.04.16 08:59:52 2: autocreate: define ECMDDevice message 2 2 1
2014.04.16 08:59:52 1: ERROR: Unknown module message
es muss am Modul liegen, dass da irgend wann abgeschnitten wird. Nach 52 Zeichen ist Schluss.
schöne Ostern
Tom_S
PS: kann natürlich auch am DevIO liegen
noch eins, gerade gemerkt
Zitat
2014.04.18 17:41:49 1: 192.168.115.91:23 disconnected, waiting to reappear
ein manuelles "reopen" löst das Problem.
Lässt sich das automatisieren (ohne Notify) also direkt im Modul?
Guten Morgen,
ich hab dann heute auch das Update bekommen. Hat einer den Bodenfeuchtesensor http://www.fhemwiki.de/wiki/AVR-NET-IO (http://www.fhemwiki.de/wiki/AVR-NET-IO) am Start? Ich bekomme nur noch Value 0. Aber da hat sich vermutlich ein Rückgabewert geändert, das bekomme ich auch selber raus.
Aber bei meinem DIn bekomme ich folgende Fehler:
2014.04.19 09:42:30 3: Timer_ba_Wassertonne: status Can't use global @@ in "my" at (eval 474) line 1, near "my @@"
syntax error at (eval 474) line 1, near "@@fullport "
Can't use global @@ in "my" at (eval 474) line 1, near "my @@"
syntax error at (eval 474) line 1, near "@@hexport "
Global symbol "@fullport" requires explicit package name at (eval 474) line 1.
Global symbol "@hexport" requires explicit package name at (eval 474) line 1.
Can't use global @@ in "my" at (eval 474) line 1, near "my @@"
syntax error at (eval 474) line 1, near "@@pinarray "
Can't use global %% in "my" at (eval 474) line 1, near "my %%"
syntax error at (eval 474) line 1, near "%%hash "
(eval 474) has too many errors.
# Uebergabeparameter HEX Adresse Port
params IOPort IOPin
get status cmd {"io get pin %IOPort"}
get status postproc {\
my @@fullport = split(/ /,trim($_));\
my @@hexport = split(/x/,$fullport[2]);\
my $binport = sprintf( "%%b", hex( $hexport[1] ) );\
my $binlength = length($binport);\
while ($binlength < 8){\
$binport = "0".$binport;\
$binlength = length($binport);\
}\
my @@pinarray = split('',$binport);\
my %%hash = (\
1 => '7',\
2 => '6',\
3 => '5',\
4 => '4',\
5 => '3',\
6 => '2',\
7 => '1',\
8 => '0',\
);\
my $pinvalue = $pinarray[$hash{%IOPin}];\
$pinvalue;\
}
Hallo,
mach mal alle Doppelungen von @ und % weg. Diese Specials in ECMD sind abgeklemmt, weil sie störend sind und das Verständnis enorm erschweren.
Grüße
Boris
Zitat von: Tom_S am 18 April 2014, 23:14:05
Lässt sich das automatisieren (ohne Notify) also direkt im Modul?
Eine der Neuerungen im Modul ist, daß es sich automatisch wiederverbindet. Wenn das auch scheitert, wird das Device jedoch abgeklemmt.
Grüße
Boris
Zitat von: Tom_S am 18 April 2014, 20:54:37
PS: kann natürlich auch am DevIO liegen
Weder noch. Wenn der Sende- oder Empfangspuffer voll ist, werden die Daten aus DevIO an die Anwendung (FHEM) und von da weiter an ECMD geschickt. Die Daten kommen einfach stückweise an.
Eine Möglichkeit wäre es, PARTIAL in ECMD zu implementieren, und erst dann die empfangenen Daten Verarbeitung anzustellen, wenn es einen kompletten Match gibt (oder eine Wartezeit überschritten ist). Das ist aber fummelig und ich habe dazu erstmal keine Lust.
Viele Grüße
Boris
Ich weiß jetzt nicht, was sich von der letzten Testversion zum gestrigen Update geändert hat, aber es funktioniert so Einiges nicht mehr.
Die rfm12_2272 classdef:
params byte1 byte2 byte3
set on cmd {"rfm12 2272 %byte1,%byte2,".sprintf(1+%byte3)." 76 10\n"}
set on expect "OK\n"
set on postproc {s/OK\n//; $_;}
set off cmd {"rfm12 2272 %byte1,%byte2,".sprintf(0+%byte3)." 76 10\n"}
set off expect "OK\n"
set off postproc {s/OK\n//; $_;}
Mit s/OK\n//; $_; konnte ich das OK "entsorgen", nun kommt statt dem gewollt leeren Reading eine "0", die ich nicht brauche. Wo bekomme ich die wieder weg? Frickeln am Modul ist für mich keine Lösung!
Bah ich bin ein Depp. Ich hatte mein Server neu aufgesetzt und in dem neuen FHEM Paket hat sich die Verzeichnisstruktur verändert. Früher hatte ich immer alles unter /etc/fhem (Wo es ja auch hin gehört oO) und mit symbolischen links habe ich das nach /usr/share/fhem geschoben. Naja wie dem auch seit, ich hab die falschen Dateien bearbeitet, durch mein Restore waren die doppelt da :-)
Also Temp funktioniert schon mal, und das andere bekomme ich sicher auch noch hin.
Gruß und FROHE OSTERN!!!
Daniel
@kpwg
Zitat
Mit s/OK\n//; $_; konnte ich das OK "entsorgen", nun kommt statt dem gewollt leeren Reading eine "0", die ich nicht brauche. Wo bekomme ich die wieder weg?
liegt an der postproc. du kannst einfach
set on postproc {""}einfügen, dann kommt nichts zurück, oder den String auswerten und gegen "" ersetzen.
@Boris
Zitat
Weder noch. Wenn der Sende- oder Empfangspuffer voll ist, werden die Daten aus DevIO an die Anwendung (FHEM) und von da weiter an ECMD geschickt.
dann muss es an DevIO liegen. Mit der alten Version hat es funktioniert. Ich habe am Controller nichts verändert. Werde jetzt erst mal den String begrenzen.
Tom_S
Zitat von: Tom_S am 19 April 2014, 17:03:28
@kpwg
liegt an der postproc. du kannst einfach
set on postproc {""}
einfügen, dann kommt nichts zurück, oder den String auswerten und gegen "" ersetzen.
Das funktioniert leider nicht. es kommt dann nichts (mehr) zurück, war auch kein state ändert.
Wenn ich dagegen
set on postproc {s/OK\n/on/; $_;}und
set off postproc {s/OK\n/off/; $_;}schreibe, erhalte ich "on on" und "off off" als state zurück, was erst wieder per Workarround wie beim alten Modul behebbar ist.
Ich teste mal weiter und berichte!
Viele Grüße, Ricardo
Moin,
hat sich an den Rückgabewerten von den Digitaleingängen etwas geändert? Ich bekomme jetzt anstelle von 0/1 ein b zurück?
Gruß
Daniel
Nabend,
ich bin jetzt ein wenig ratlos, wie ich die readings und state hin bekomme. Ich möchte gerne "on" und "off" als state haben. Die Readings sind an der Stelle erst mal egal.
Wenn ich mit set off postproc {s/OK\n//; $_ } zum Beispiel ausschalten möchte, erhalte ich keine Rückmeldung mehr, da ich mir die ja komplett entferne. Bisher wurde hier noch das leere Reading als state übernommen, was wunderbar funktionierte.
Was schreibe ich nun rein, um einerseits einen Rückgabe auszulösen, anderseits aber "nichts" zusätzlich zurück zu bekommen?
Habe zB \000, \n und Anderes probiert- funktioniert nicht. Gibts eine Idee?
Viele Grüße, Ricardo
stateformat?
bn
Zitat von: Dr. Boris Neubert am 20 April 2014, 21:36:16
stateformat?
bn
Vielleicht eine Lösung (muss ich morgen lesen), aber nur ein Workarround, denn es wäre dann für jedes Device nötig. Erinnert stark an die alte Lösung mit devStateIcon. Funktioniert, ist aber nicht schön :)
@kpwg
Zitat
Das funktioniert leider nicht. es kommt dann nichts (mehr) zurück, war auch kein state ändert.
glaub ich dir nicht. Das Kommando kommt immer zurück.
es geht definitiv! Häng mal deine classdef an
mfg Tom_S
Ok, *lötkolbenkurzausschalt*, hier ist sie:
params byte1 byte2 byte3
set on cmd {"rfm12 2272 %byte1,%byte2,".sprintf(1+%byte3)." 76 10\n"}
set on expect "OK\n"
set on postproc {s/OK\n//; $_ }
set off cmd {"rfm12 2272 %byte1,%byte2,".sprintf(0+%byte3)." 76 10\n"}
set off expect "OK\n"
set off postproc {s/OK\n//; $_ }
mach einfach mal
set on cmd {"rfm12 2272 %byte1,%byte2,".sprintf(1+%byte3)." 76 10\n"}
set on expect ".*"
set on postproc {"$_" eq "OK\n" ? "" : "Fehler";}
und berichte
wenn es nicht geht, dann schreibe mal was ohne postproc zurück kommt.
LG
Ähnliches Ergebnis. Die classdef:
params byte1 byte2 byte3
set on cmd {"rfm12 2272 %byte1,%byte2,".sprintf(1+%byte3)." 76 10\n"}
set on expect ".*"
set on postproc {"$_" eq "OK\n" ? "" : "Fehler";}
set off cmd {"rfm12 2272 %byte1,%byte2,".sprintf(0+%byte3)." 76 10\n"}
set off expect ".*"
set off postproc {"$_" eq "OK\n" ? "" : "Fehler";}
Das Device schaltet zwar, state oder die Readings ändern sich aber nicht, da "nichts" zurückgegeben wird.
ja, jetzt habe ich gerade nochmal geschaut. Da ist ja schon die neue ECMDDevice im Update. Mit der geht es bei mir auch nicht. Bei leerem value wird jetzt nichts zurückgegeben. Weis nicht warum Boris das so geändert hat.
LG
Zitat von: Tom_S am 21 April 2014, 11:22:48
ja, jetzt habe ich gerade nochmal geschaut. Da ist ja schon die neue ECMDDevice im Update. Mit der geht es bei mir auch nicht. Bei leerem value wird jetzt nichts zurückgegeben. Weis nicht warum Boris das so geändert hat.
LG
Danke für's Bestätigen. Bei Ext23 scheint's auch daran zu liegen.
Boris, kannst Du bitte nochmal schauen?
Hallo,
ich habe nochmal über die Verarbeitung nachgedacht. Soll-Zustand:
- Spontan empfangene leere Daten und set-/get-Kommandos ohne Wert setzen kein entsprechendes gleichnamiges Reading.
- state wird immer auf das letzte empfangene Reading oder das letzte set-/get-Kommando gesetzt.
Wer überschüssige Readings hat, kann diese mit "deletereading <devicename> <readingname>" entfernen.
Umgesetzt habe ich das in dieser Routine:
sub
ECMDDevice_Changed($$$)
{
my ($hash, $cmd, $value)= @_;
readingsBeginUpdate($hash);
my $state= $cmd;
if(defined($value) && $value ne "") {
readingsBulkUpdate($hash, $cmd, $value);
$state.= " $value";
}
readingsBulkUpdate($hash, "state", $state);
readingsEndUpdate($hash, 1);
my $name= $hash->{NAME};
Log3 $hash, 4 , "ECMDDevice $name $state";
return $state;
}
Diese ersetzt die gleichnamige Routine in 67_ECMDDevice.pm ab Zeile 107. Die Datei der Vollständigkeit halber auch anbei.
Könntet Ihr Drei (kpwg, ext23, Tom_S) bitte einmal testen, ob ein so verändertes 67_ECMDDevice.pm Euren Vorstellungen entspricht? Bei mir tut es in einem beschränkten Testfall, was es soll. Classdef:
params out
set on cmd { "setport %out.1\r\n" }
set on expect "^(ACK|NAK).*$"
set on postproc { "$_" eq "ACK\r\n" ? "" : "error" }
set off cmd { "setport %out.0\r\n" }
set off expect "^(ACK|NAK).*$"
set off postproc { "$_" eq "ACK\r\n" ? "" : "error" }
Viele Grüße
Boris
Perfekt! (Mal wieder) Danke, Boris!
Habe es soeben getestet und es funktioniert. Im Detail:
rfm12_2272.classdef params byte1 byte2 byte3
set on cmd {"rfm12 2272 %byte1,%byte2,".sprintf(1+%byte3)." 76 10\n"}
set on expect "OK\n"
set on postproc {s/OK\n//; $_ }
set off cmd {"rfm12 2272 %byte1,%byte2,".sprintf(0+%byte3)." 76 10\n"}
set off expect "OK\n"
set off postproc {s/OK\n//; $_ }
Damit ist das state on bzw off und lässt sich ohne weitere "Zutaten" mit Druck auf's Symbol toggeln, was bedeutet, das ich nun on und off sauber zurück bekomme. Ich hatte noch alte readings on und off stehen, die ich nun gelöscht habe. Damit verhält sich das Device so, das man auch mit Extend devStateIcon arbeiten kann. Erhöht den WAF ungemein 8)
Viele Grüße, Ricardo
hallo Boris,
so funktioniert alles. Für spontan empfangene Nachrichten habe ich jetzt ein Reading wenn Value nicht leer ist.
Sehr schön und
Zitat
Wer überschüssige Readings hat, kann diese mit "deletereading <devicename> <readingname>" entfernen.
wieder was gelernt.
Gruß Tom_S
Hallo,
ich habe da noch ein Problem mit meinen 1wire-Temperatur-Sensoren.
Nachdem ich ich die Classdeff wie folgt umgeschrieben habe:
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get T: cmd {"1w get %devID\n"}
get T: expect ".*"
get T: postproc {\
my $hash = $defs{%NAME};\
my $temperature = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "T:", $temperature, 1);\
readingsSingleUpdate($hash, "state", $temperature, 1);\
\
}
hat auch allem Anschein nach erst mal alles geklappt. Nach einiger Zeit spielte dann
der erste von 4 Sensoren verrückt. Er gab als Rückgabewert 16a oder 16b oder ähnliches zurück.
Daraufhin habe ich die Temperaturen in der Ethersex Index Page kontrolliert. Da ist mir dann
aufgefallen das alle Temperaturen nicht passten. Als ob die nicht aktualisiert wurden.
Daraufhin habe ich in der Classdeff das Messen aus dem Wiki Eintrag wieder eingefügt.
Wenn ich jetzt set messen ausführe und dann get temperature bekomme ich bei
dem ersten Sensor ein OK und bei den anderen den echten aktuellen Wert.
Wenn ich dann nochmal ges temperature mache funktioniert auch der erste.
Eventuell hat ja jemand einen Tipp was ich noch falsch mache.
Vielen dank im voraus.
Heinz
Heinz,
da würde ich (selbst) dieser Tage nachsehen, wie die classdef mit messen + lesen aussehen müsste. Ich habe aktuell gute Erfahrung mit dem Polling in E6 gemacht, aber mal ehrlich: wer geht schon nochmal an seinen verbauten NetIO 'ran und stellt das um? ;)
Die 1wire.classdef sieht hier aktuell so aus:
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get T: cmd {"1w get %devID\n"}
get T: expect "\d+.\d\n"
get T: postproc {\
my $hash = $defs{%NAME};\
my $temperature = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "state", $temperature, 1);\
\
}
Das readingsSingleUpdate für T: entfiel, weil ja bereits T: gesetzt wird. Aber das sind Kleinigkeiten.
Beim expect ist man mit .* immer erst mal auf der funktionierend sicheren Seite; ich schaue mir jedoch mit logtraffic 0 im ECMDDevice an, was tatsächlich kommt und wie man das in perl beschreiben kann. Das hat nur nix mit Deinem Problem zu tun.
Aktuell habe ich funktionierende classdef's für 1wire-Sensoren, DHT22, LCD, Schalten mit control6, RFM12-Intertechno und RFM12-2272.
Beim ADC bin ich noch am frickeln- prinzipiell funktioniert es schon. Dabei verfolge ich in allen classdef's das Ziel, zu anderen Sensoren vergleichbare readings zu generieren, um die Weiterverarbeitung universeller zu halten. So ganz ohne Programmierkenntnisse... 8)
Es wäre gut, wenn Andere ihre classdef's hier vorstellen. Ich zeige meine nochmals komplett, wenn Boris den Patch vom 22.04. zum Update bereitstellt. Ein paar kleine Dinge wurden in der Zwischenzeit optimiert.
Viele Grüße, Ricardo
Zitat von: kpwg am 25 April 2014, 16:34:35
Es wäre gut, wenn Andere ihre classdef's hier vorstellen. Ich zeige meine nochmals komplett, wenn Boris den Patch vom 22.04. zum Update bereitstellt.
Patch ist jetzt eingecheckt!
bn
Hallo,
nach einem Update von heute (das letzte vor 14Tagen) ging das Einlesen der 1Wire-Temperatirewerte vom AVR-Net-Io nicht mehr.
Nach Anpassungen in der Classdef (nach Ricardo)
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get T: cmd {"1w get %devID\n"}
get T: expect "\d+.\d\n"
get T: postproc {\
my $hash = $defs{%NAME};\
my $temperature = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "state", $temperature, 1);\
\
}
und weiteren Änderungen in der conf
define NETIO_01 ECMD telnet 192.168.178.105:2701
attr NETIO_01 classdefs ONEWIRE=/opt/fhem/InternerSpeicher/onewire.classdef
#set NETIO_01 reopen
attr NETIO_01 room System
define WZ_Temp03 ECMDDevice ONEWIRE 2853b9f5040000bb
attr WZ_Temp03 alias Heizung
attr WZ_Temp03 room Heizung
define 1Wire_Temp03 at +*00:05 get WZ_Temp03 T:
attr 1Wire_Temp03 room hidden
define Log_Heizung FileLog ./log/Heizung-%Y-%m.log WZ_Temp03:(temperature).*
attr Log_Heizung room LogFiles
define weblink_Heizung SVG Log_Heizung:1wtempHz:CURRENT
attr weblink_Heizung label "Temperaturen des Warmwasserspeichers"
attr weblink_Heizung plotsize 1240,420
attr weblink_Heizung room Heizung
konnte ich wieder die Temperaturwerte logen. Aber mit einem Schönheitsfehler.
Im Log-File bzw. Heizungs-Log-File sind zwischen den Messwerten Leerzeilen.
Weiter betätigt man bei den Internals die GET-Taste kommt eine Fehlermeldung.
"WZ_Temp03 error: unknown argument T, choose one of T: "
Sind jetzt keine Fehler mit denen man nicht leben könnte, wollte aber dennoch darauf hinweisen.
Einen schönen Tag wünscht euch - Thomas
Zitat von: ThomasW am 26 April 2014, 12:09:13
Weiter betätigt man bei den Internals die GET-Taste kommt eine Fehlermeldung.
"WZ_Temp03 error: unknown argument T, choose one of T: "
Das liegt an der Idee, einen Doppelpunkt in den Namen des Readings einzubauen. Ein Wunder, daß es überhaupt funktioniert. Warum brauchst Du das?
Ich würde noch den Zeilenumbruch aus dem Reading herausschneiden:
s/\n//g
Grüße
Boris
Zitat von: Dr. Boris Neubert am 26 April 2014, 12:24:33
Das liegt an der Idee, einen Doppelpunkt in den Namen des Readings einzubauen. Ein Wunder, daß es überhaupt funktioniert. Warum brauchst Du das?
Ich würde noch den Zeilenumbruch aus dem Reading herausschneiden:
s/\n//g
Grüße
Boris
Stimmt, das T: kann funktionieren, muss nicht. Habe es geändert und auch den Zeilenumbruch wie empfohlen entfernt.
Damit habe ich jetzt folgenden Stand:
(http://abload.de/img/20140426_1wire1ckl4.jpg)
und die 1wire.classdef:
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get T cmd {"1w get %devID\n"}
get T expect "\d+.\d\n"
get T postproc {\
s/\n//g;\
my $hash = $defs{%NAME};\
my $temperature = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "state", $temperature, 1);\
\
}Sowie das regelmäßige auslesen:
define 1w_Messung at +*00:05 get Sensor_1 T;; get Sensor_2 T;; get Sensor_3 T;; get Sensor_4 TVielleicht lässt sich das noch kürzen, wenn man extrem viele Sensoren hat?
Viele Grüße, Ricardo
Warum nicht so:
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get temperature cmd {"1w get %devID\n"}
get temperature expect "\d+.\d\n"
get temperature postproc { s/\n//g }
Grüße
Boris
Zitat von: Dr. Boris Neubert am 26 April 2014, 14:59:30
Warum nicht so: ...
Kommt darauf an, ob und wie man T bein loggen benötigt. Klar geht es so auch und viel einfacher.
Zitat von: kpwg am 26 April 2014, 16:15:30
Kommt darauf an, ob und wie man T bein loggen benötigt. Klar geht es so auch und viel einfacher.
Schau Dir dazu mal userReadings an...
Grüße
Boris
Nabend,
ich hab da noch ein Problem beim Einlesen des Digitaleingangs. Ich hab meine alte classdef mal so abgespeckt:
params IOPort IOPin
get status cmd {"io get pin %IOPort\n"}
get status expect ".*"
Ich bekomme aber nach jeder Abfrage ein anderen Wert:
status port 0: 0x00
beim nächsten mal dann:
status OK
Es sieht also so aus das der nicht die ganze Antwort ausliest weil das OK gehört ja sicher mit zur Rückgabe oder?!? Ich dachte aber das expect ".*" holt erst mal alles rein was kommt.
Gruß
Daniel
Hallo,
jetzt dachte ich ich bin ein Stück weiter jedoch gefehlt. Ich benötige einmal Eure Mithilfe. Mit deralten Version und folgender relais.classdef könnte ich die Relais bzw. Ausgänge auf dem AVR-NET-IO schalten hatte mich an die Beschreibung von hier http://www.fhemwiki.de/wiki/AVR-NET-IO (http://www.fhemwiki.de/wiki/AVR-NET-IO) gehalten. Bin mit einer Mischersteuerung für die Heizung beschäfftigt. Mit dem Update habe ich einen ganze Menge Fehlermeldungen in der Log-Datei bekommen. Den größen Teil habe ich auch durch lesen und ändern beheben können. Nur leider bei der Ansteuerung für die Relais scheitere ich.
Wie muss die neue relais.classdef aussehen?
Wie werden dann die Realis aus dem normalen System angesprochen?
Die Beispiele in der "commandref" helfen mir leider nicht.
Ich kann Befehle an die Relais "senden" das Lampensymbol verändert sich. Das Relais schaltet jedoch nicht das Gerät "Ein" oder "Aus".
Danke
Martin
@ext23
Zitatich hab da noch ein Problem beim Einlesen des Digitaleingangs. Ich hab meine alte classdef mal so abgespeckt:
params IOPort IOPin
get status cmd {"io get pin %IOPort\n"}
get status expect ".*"
was übergibst du denn mit den Parametern IOPort und IOPin? Beim orginalen Ethersex kannst du doch nur die drei Register (pin, port und ddr) als gesammtes abfragen. Bei mir kommt da nur ein "port x: 0x00\n" und kein OK.
Gruß
@martinbaumert
probier mal
params PINC
set on cmd {"io set ddr 2 ff\n\000io set port 2 %PINC %PINC\n"}
set on expect ".*"
set on postproc {substr($_, 0, 2) eq "OK" ? "" : "$_";}
set off cmd {"io set ddr 2 ff\n\000io set port 2 00 %PINC\n"}
set off expect ".*"
set off postproc {substr($_, 0, 2) eq "OK" ? "" : "$_";}
die postproc kannst du natürlich an das was wirklich zurück kommt anpassen. "OK\n" oder so
viel Erfolg
Schaut doch im ECMD mit logTraffic 0 nach, was tatsächlich kommuniziert wird. Damit lässt sich auch expect hervorragend anpassen. Im Logfile steht dann die gesamte Kommunikation.
Viele Grüße, Ricardo
Zitat von: Tom_S am 28 April 2014, 19:18:12
@ext23
was übergibst du denn mit den Parametern IOPort und IOPin? Beim orginalen Ethersex kannst du doch nur die drei Register (pin, port und ddr) als gesammtes abfragen. Bei mir kommt da nur ein "port x: 0x00\n" und kein OK.
Gruß
Na IOPort ist die Portadresse als hex, und IOPin ist der Pin, das wird hier nicht benötigt aber ich brauch ist in meinem postproc um dann den wert des eigentlichen Bits zurück zu bekommen. Wie du schon sagst bekommt man normale die ganze Portgruppe zurück. So war es zumindest früher. Da mich nur ein Bit interessiert habe ich mir eine Maske gebaut. Daher also der zweite Parameter. (In der kompletten classdef wird der dann wichtig ...)
Tja bei mir kommt beides zurück, mal OK mal das andere und das wechselt immer. Aber 0x00 haut auch nicht hin, das ist immer gleich egal ob High oder Low anliegt.
Irgendwie tappe ich da gerade noch etwas im Dunkeln, früher lief das vor dem Update, also Hardwareseitig stimmt somit alles.
Gruß
Hallo Boris
ich habe meine 1wire.classdef wie in deinem Vorschlag angegeben angepasst.
Leider bekomme ich mit der Zeile get temperature postproc { s/\n//g } , die ja (wenn ich das richtig verstanden habe) die Leerzeile aus dem Logfile entfernen soll, als Temperaturwert nur 1 angezeigt.
Ich weiß nicht was postproc macht und kann mir so nicht selbst helfen.
Kannst du mir helfen?
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get temperature cmd {"1w get %devID\n"}
get temperature expect "\d+.\d\n"
get temperature postproc { s/\n//g }
Gruß
Christof
Zitat
Ich weiß nicht was postproc macht und kann mir so nicht selbst helfen.
habe leider gerade kein ethersex mit 1wire Sensoren. Was bekommst du denn ohne postproc?
Hallo Ricardo, hallo Boris,
als meine letzte Update erfolgte am 11.04 das anschließende Update bescherte mir Leerzeilen im Log-File (wie schon berichtet)
Ein Ergänzung der classdef mit den beschriebenen Befehlen ändert bei mir nicht, Leerzeilen sind nach wievor vorhanden.
get temperature postproc { s/\n//g }
bzw.
get T postproc {\
s/\n//g;\
my $hash = $defs{%NAME};\
Kann es sein daß durch Änderungen in der ECMD bzw ECMDDevice an die Messwerte des AVR die Leerzeile angehängt wird?
Durch diese Leerzeile geht auch das SVG kaputt.
Aber was viel schlimmer ist, gestern lief nur mein Testsystem mit dem AVR-Netio und es bracht immer die gleichen Temp-Werte.
SVG-Auszug siehe Anhang.
Um ca. 10:40 wurde der AVR-Netio resetet, anschließend alle Temp-Werte 85°C.
ca. 12:00 wurde FHEM neu gestartet anschließend 1 bis 2 aktuelle Messwerte - letzter Messwert wird dauernd eingelesen.
ca 12:10 wird ein weiterer FHEM-Server gestartet - liest die gleichen Messwerte ein wie der Erste.
ca. 14:00 wird die Ethersexseite im AVR-Netio mit den Meßwerten aufgerufen und läuft bis 17:00 Uhr, in dieser Zeit werden
ohne Änderung in der Konfiguration oder sonstiges alle Meßwerte aktualisiert.
Sorry, habe momentan nur eingeschränkt Zeit Fehler zu suchen - hoffe das ändert sich in den nächsten 14tagen.
Stehe aber gerne für Tests bereit.
Grüße Thomas
Zitat von: ext23 am 28 April 2014, 19:46:30
Irgendwie tappe ich da gerade noch etwas im Dunkeln, früher lief das vor dem Update, also Hardwareseitig stimmt somit alles.
Poste doch mal die Kommunikation mit logTraffic auf an.
Grüße
Boris
Zitat von: Tom_S am 28 April 2014, 22:09:01
habe leider gerade kein ethersex mit 1wire Sensoren. Was bekommst du denn ohne postproc?
Und mit logTraffic?
Merket: logTraffic ist Euer Freund.
Grüße
Boris
Zitat von: ThomasW am 29 April 2014, 10:50:50
als meine letzte Update erfolgte am 11.04 das anschließende Update bescherte mir Leerzeilen im Log-File (wie schon berichtet)
Bitte nochmal volle classdef und Traffic-Log posten.
Grüße
Boris
Zitat von: Tom_S am 28 April 2014, 22:09:01
habe leider gerade kein ethersex mit 1wire Sensoren. Was bekommst du denn ohne postproc?
Hallo Tom_S
ohne postproc bekomme ich die Temperatur richtig angezeigt.
Leider sind dann in der LOG Datei die Leerzeile.
Gruß Christof
Zitat
ohne postproc bekomme ich die Temperatur richtig angezeigt.
das ist klar. Schreib bitte mal genau was zurück kommt, und auch die logs.
mfg
Guten morgen,
ich hab das log mal über Nacht laufen lassen:
2014.04.29 15:52:08 0: AVRNETIO2: write "io get pin 0\n", expect .*
2014.04.29 15:52:08 0: AVRNETIO2: read "port 0: 0x00\n"
2014.04.29 15:53:08 0: AVRNETIO2: write "adc get 7\n", expect .*
2014.04.29 15:53:08 0: AVRNETIO2: read "048 \n"
2014.04.29 15:53:08 0: AVRNETIO2: write "io get pin 0\n", expect .*
2014.04.29 15:53:08 0: AVRNETIO2: read "port 0: 0x00\n"
2014.04.29 15:54:08 0: AVRNETIO2: write "adc get 7\n", expect .*
2014.04.29 15:54:08 0: AVRNETIO2: read "046 \n"
2014.04.29 15:54:08 0: AVRNETIO2: write "1w convert\n"
2014.04.29 15:54:08 0: AVRNETIO2: write "io get pin 0\n", expect .*
2014.04.29 15:54:08 0: AVRNETIO2: read "OK\n"
2014.04.29 15:54:09 0: AVRNETIO2: read "port 0: 0x00\n"
2014.04.29 15:54:10 0: AVRNETIO2: write "1w get 282f1bc3030000d5\n", expect .*
2014.04.29 15:54:10 0: AVRNETIO2: read "31.6\n"
2014.04.29 15:55:08 0: AVRNETIO2: write "adc get 7\n", expect .*
2014.04.29 15:55:08 0: AVRNETIO2: read "047 \n"
2014.04.29 15:55:08 0: AVRNETIO2: write "io get pin 0\n", expect .*
2014.04.29 15:55:08 0: AVRNETIO2: read "port 0: 0x00\n"
Das OK kommt wenn eine andere Abfrage dazwischen funkt so wie ich das sehe. Das OK stammt sicher von dem convert...
Wie ich gelernt habe kann man das also mit dem expect abfragen richtig? Aber ist das so sauber? Wieso schickt der ein erneutes write wenn der vorherige Befehl noch keine Rückgabe geliefert hat? Das kann man doch gar nicht mehr richtig zuordnen dann.
Und dann noch was, ich weiß nicht ob ich ein bissel Gaga bin aber vielleicht kann mir hier einer helfen. Das passiert übrigens erst nach dem großen ECMD Update. Aber eigentlich müsste das ja eher am plot modul liegen .... oO
Schaut mal bitte auf das Foto im Anhang. Auf die Kurve...
Das was unten geloggt wird steht komplett im Log, also ohne Lücken, kontinuierlich, da fehlt nichts ...
Gruß und Danke
Daniel
Hallo Boris,
habe nochmals die Versuche mit der classdef wiederholt und bin zu diesem Ergebnis gekommen.
Versuch 1
classdef
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get temp cmd {"1w get %devID\n"}
get temp expect "\d+.\d\n"
get temp postproc { s/\n//g }
get temp postproc {\
my $hash = $defs{%NAME};\
my $temperature = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "state", $temperature, 1);\
\
}
Log
temp 29.6
temp 40.6
temp 45.6
temp 38.5
2014.04.30 20:19:57 3: 1w_Messung: temp 30.9
2014.04.30 20:19:57 3: NETIO_01: read "29.6\n"
2014.04.30 20:19:57 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 20:19:57 3: NETIO_01: read "40.6\n"
2014.04.30 20:19:57 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 20:19:57 3: NETIO_01: read "45.6\n"
2014.04.30 20:19:57 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 20:19:57 3: NETIO_01: read "38.5\n"
2014.04.30 20:19:57 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 20:19:57 3: NETIO_01: read "30.9\n"
2014.04.30 20:19:57 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
Versuch 2
classdef
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get temp cmd {"1w get %devID\n"}
get temp expect "\d+.\d\n"
get temp postproc { s/\n//g }
Log
temp 1
temp 1
temp 1
temp 1
2014.04.30 20:33:41 3: 1w_Messung: temp 1
2014.04.30 20:33:41 3: NETIO_01: read "29.6\n"
2014.04.30 20:33:41 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 20:33:41 3: NETIO_01: read "40.6\n"
2014.04.30 20:33:41 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 20:33:41 3: NETIO_01: read "45.6\n"
2014.04.30 20:33:41 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 20:33:41 3: NETIO_01: read "38.5\n"
2014.04.30 20:33:41 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 20:33:41 3: NETIO_01: read "30.9\n"
2014.04.30 20:33:41 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
temp 1
temp 1
temp 1
temp 1
2014.04.30 20:28:41 3: 1w_Messung: temp 1
2014.04.30 20:28:41 3: NETIO_01: read "29.6\n"
2014.04.30 20:28:41 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 20:28:41 3: NETIO_01: read "40.6\n"
2014.04.30 20:28:41 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 20:28:41 3: NETIO_01: read "45.6\n"
2014.04.30 20:28:41 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 20:28:41 3: NETIO_01: read "38.5\n"
2014.04.30 20:28:41 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 20:28:41 3: NETIO_01: read "30.9\n"
2014.04.30 20:28:41 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
Versuch 3
classdef
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get T cmd {"1w get %devID\n"}
get T expect "\d+.\d\n"
get T postproc {\
s/\n//g;\
my $hash = $defs{%NAME};\
my $temperature = $_;\
\
readingsSingleUpdate($hash, "temperature", $temperature, 1);\
readingsSingleUpdate($hash, "state", $temperature, 1);\
\
}
Log
temp 29.6
temp 40.6
temp 45.6
temp 38.5
2014.04.30 20:45:50 3: 1w_Messung: temp 30.9
2014.04.30 20:45:50 3: NETIO_01: read "29.6\n"
2014.04.30 20:45:50 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 20:45:50 3: NETIO_01: read "40.6\n"
2014.04.30 20:45:50 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 20:45:50 3: NETIO_01: read "45.6\n"
2014.04.30 20:45:50 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 20:45:49 3: NETIO_01: read "38.5\n"
2014.04.30 20:45:49 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 20:45:49 3: NETIO_01: read "30.9\n"
2014.04.30 20:45:49 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
temp 29.6
temp 40.6
temp 45.6
temp 38.5
2014.04.30 20:40:50 3: 1w_Messung: temp 30.9
2014.04.30 20:40:50 3: NETIO_01: read "29.6\n"
2014.04.30 20:40:50 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 20:40:50 3: NETIO_01: read "40.6\n"
2014.04.30 20:40:50 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 20:40:50 3: NETIO_01: read "45.6\n"
2014.04.30 20:40:50 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 20:40:49 3: NETIO_01: read "38.5\n"
2014.04.30 20:40:49 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 20:40:49 3: NETIO_01: read "30.9\n"
2014.04.30 20:40:49 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
Vor zwei Tagen bei den gleichen Versuchen, hatte ich keine Änderungen bei den Leerzeilen. Warum das so war ?
Aber was mir Damals schon aufviel, wie auch hier zu sehen, ist das die Temperaturen über die ganze Zeit gleich bleiben.
Nochmals die Ergebnisse der Versuche mit einem 2ten geöffneten Bowserfenster, im Fenster ist die "Ethersex 1-wire Statusseite".
Versuch 1
temp 38.5
temp 41.6
temp 45.1
temp 41.2
2014.04.30 21:07:14 3: 1w_Messung: temp 30.4
2014.04.30 21:07:14 3: NETIO_01: read "38.5\n"
2014.04.30 21:07:14 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 21:07:14 3: NETIO_01: read "41.6\n"
2014.04.30 21:07:14 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 21:07:14 3: NETIO_01: read "45.1\n"
2014.04.30 21:07:14 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 21:07:14 3: NETIO_01: read "41.2\n"
2014.04.30 21:07:14 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 21:07:14 3: NETIO_01: read "30.4\n"
2014.04.30 21:07:14 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
temp 38.6
temp 41.6
temp 45.6
temp 41.2
2014.04.30 21:02:14 3: 1w_Messung: temp 30.9
2014.04.30 21:02:14 3: NETIO_01: read "38.6\n"
2014.04.30 21:02:14 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 21:02:14 3: NETIO_01: read "41.6\n"
2014.04.30 21:02:14 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 21:02:14 3: NETIO_01: read "45.6\n"
2014.04.30 21:02:14 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 21:02:14 3: NETIO_01: read "41.2\n"
2014.04.30 21:02:14 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 21:02:14 3: NETIO_01: read "30.9\n"
2014.04.30 21:02:14 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
Versuch 2
temp 1
temp 1
temp 1
temp 1
2014.04.30 21:18:33 3: 1w_Messung: temp 1
2014.04.30 21:18:33 3: NETIO_01: read "38.3\n"
2014.04.30 21:18:33 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 21:18:33 3: NETIO_01: read "41.6\n"
2014.04.30 21:18:33 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 21:18:33 3: NETIO_01: read "43.0\n"
2014.04.30 21:18:33 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 21:18:33 3: NETIO_01: read "41.1\n"
2014.04.30 21:18:33 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 21:18:33 3: NETIO_01: read "29.6\n"
2014.04.30 21:18:33 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
temp 1
temp 1
temp 1
temp 1
2014.04.30 21:13:33 3: 1w_Messung: temp 1
2014.04.30 21:13:33 3: NETIO_01: read "38.4\n"
2014.04.30 21:13:33 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 21:13:33 3: NETIO_01: read "41.6\n"
2014.04.30 21:13:33 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 21:13:33 3: NETIO_01: read "43.9\n"
2014.04.30 21:13:33 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 21:13:33 3: NETIO_01: read "41.1\n"
2014.04.30 21:13:33 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 21:13:33 3: NETIO_01: read "29.9\n"
2014.04.30 21:13:33 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
Versuch 3
temp 38.8
temp 41.6
temp 45.8
temp 41.2
2014.04.30 20:55:50 3: 1w_Messung: temp 31.1
2014.04.30 20:55:50 3: NETIO_01: read "38.8\n"
2014.04.30 20:55:50 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 20:55:50 3: NETIO_01: read "41.6\n"
2014.04.30 20:55:50 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 20:55:50 3: NETIO_01: read "45.8\n"
2014.04.30 20:55:50 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 20:55:49 3: NETIO_01: read "41.2\n"
2014.04.30 20:55:49 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 20:55:49 3: NETIO_01: read "31.1\n"
2014.04.30 20:55:49 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
temp 38.8
temp 41.6
temp 45.3
temp 41.2
2014.04.30 20:50:50 3: 1w_Messung: temp 29.9
2014.04.30 20:50:50 3: NETIO_01: read "38.8\n"
2014.04.30 20:50:50 3: NETIO_01: write "1w get 28f70cf60400002e\n", expect \d+.\d\n
2014.04.30 20:50:50 3: NETIO_01: read "41.6\n"
2014.04.30 20:50:50 3: NETIO_01: write "1w get 28e79bf50400001b\n", expect \d+.\d\n
2014.04.30 20:50:50 3: NETIO_01: read "45.3\n"
2014.04.30 20:50:50 3: NETIO_01: write "1w get 2853b9f5040000bb\n", expect \d+.\d\n
2014.04.30 20:50:49 3: NETIO_01: read "41.2\n"
2014.04.30 20:50:49 3: NETIO_01: write "1w get 28f999f5040000d0\n", expect \d+.\d\n
2014.04.30 20:50:49 3: NETIO_01: read "29.9\n"
2014.04.30 20:50:49 3: NETIO_01: write "1w get 282805f5040000b5\n", expect \d+.\d\n
Boris, herzlichen Dank daß du unserer (Unwissenden) annimmst.
Beste Grüße Thomas
Hallo Thomas,
bezüglich stets gleichbleibender Temperaturwerte ist zu beachten, das meine 1wire.classdef-Beispiele mit aktiviertem Polling im Ethersex getestet wurden! Das Feature ist noch nicht immer Bestandteil von Ethersex; es macht den Umgang mit den dann stets aktuell zur Verfügung stehenden Werten ohne vorheriges 1w convert deutlich einfacher.
Generell sollte zum "Flottmachen" alter classdef's beachtet werden:
- Kommandos und Befehle für ECMD müssen mit \n abgeschlossen werden (sonst "hängt" die Verbindung)
- expect hinzufügen; anfangs einfach mit .* , später spezifisch gestalten (Reguläre Ausdrücke)
- mit logTraffic 0 die Kommunikation beobachten!
Viele Grüße, Ricardo
Hallo
Ich habe bei mir folgende Beobachtung gemacht, deshalb hänge ich mich einmal hier mit an:
Im Logfile erscheinen diese Meldungen nach dem Absetzen des 1-wire-Kommandos "convert":
2014.05.01 22:55:47 5: ECMDDevice: Analyze command >{"1w convert\n"}<
2014.05.01 22:55:47 4: ECMDDevice OG_Temp messen
2014.05.01 22:55:48 2: autocreate: define ECMDDevice message OK
2014.05.01 22:55:48 1: ERROR: Unknown module message
Ich vermute, es wird durch die Rückgabe von "OK" nach dem "convert"ausgelöst. Das autocreate erscheint mir auch seltsam.
Kann man das irgendwie abstellen?
Viele Grüße
Gernot
Zitat von: ext23 am 30 April 2014, 08:21:38
Das OK kommt wenn eine andere Abfrage dazwischen funkt so wie ich das sehe. Das OK stammt sicher von dem convert...
Wie schaffst Du es denn überhaupt, den zweiten Befehl zu senden, bevor der erste beendet ist? Also wie löst Du die Kommunikation mit dem Gerät aus?
Grüße
Boris
Zitat von: kpwg am 30 April 2014, 22:36:39
Hallo Thomas,
bezüglich stets gleichbleibender Temperaturwerte ist zu beachten, das meine 1wire.classdef-Beispiele mit aktiviertem Polling im Ethersex getestet wurden! Das Feature ist noch nicht immer Bestandteil von Ethersex; es macht den Umgang mit den dann stets aktuell zur Verfügung stehenden Werten ohne vorheriges 1w convert deutlich einfacher.
Generell sollte zum "Flottmachen" alter classdef's beachtet werden:
- Kommandos und Befehle für ECMD müssen mit \n abgeschlossen werden (sonst "hängt" die Verbindung)
- expect hinzufügen; anfangs einfach mit .* , später spezifisch gestalten (Reguläre Ausdrücke)
- mit logTraffic 0 die Kommunikation beobachten!
Viele Grüße, Ricardo
Und, Thomas, es ist nur ein postproc pro Befehl erlaubt (erste classdef falsch) und mit Loglevel 5 zusätzlich zum logTraffic müßte sich der Ablauf noch besser verfolgen lassen.
Grüße
Boris
Zitat von: Dr. Boris Neubert am 02 Mai 2014, 07:08:45
Wie schaffst Du es denn überhaupt, den zweiten Befehl zu senden, bevor der erste beendet ist? Also wie löst Du die Kommunikation mit dem Gerät aus?
Na das wird alles über AT geregelt. Und dann minütlich, also ganz normal eben.
Gruß
Daniel
Zitat von: ext23 am 02 Mai 2014, 09:55:00
Na das wird alles über AT geregelt. Und dann minütlich, also ganz normal eben.
Zeig mal das define, bitte.
Gruß
Boris
Anbei mal alles was so dazu gehört:
define AVRNETIO2 ECMD telnet 192.168.0.58:2701
attr AVRNETIO2 classdefs adc=/opt/fhem/cfg/AVR-NET-IO_ADC.classdef:ONEWIRE=/opt/fhem/cfg/onewire.classdef:DIn=/opt/fhem/cfg/AVR-NET-IO_DIn.classdef
attr AVRNETIO2 room X_Interface
define ba_Temp_Steuereinheit ECMDDevice ONEWIRE 282f1bc3030000d5
attr ba_Temp_Steuereinheit IODev AVRNETIO2
attr ba_Temp_Steuereinheit room Balkon
define ba_Wassertonne ECMDDevice DIn 0 1
attr ba_Wassertonne IODev AVRNETIO2
attr ba_Wassertonne devStateIcon *leer:Wecker.Immer *voll:Wecker.Wochentags
attr ba_Wassertonne eventMap 0:voll 1:leer
attr ba_Wassertonne room Balkon
define Timer_1Wire_ba_Temp_Steuereinheit at +*00:05:00 set ba_Temp_Steuereinheit messen;; sleep 2;; get ba_Temp_Steuereinheit temp
attr Timer_1Wire_ba_Temp_Steuereinheit room X_Timer
define Timer_ba_Wassertonne at +*00:01:00 get ba_Wassertonne status
attr Timer_ba_Wassertonne room X_Timer
Gruß
Daniel
Hallo Daniel,
das ist kurios. Kannst Du bitte den AVRNETIO und die angeschlossenen Geräte mal mit Level 5 loggen lassen, damit wir herausfinden, wie das Reihenfolgeproblem entsteht?
Grüße
Boris
Hallo zusammen,
gibt es eigentlich eine einfache / elegante Möglichkeit eine geänderte classdef Datei für das ECMD Device neu einzulesen?
Derzeit behelfe ich mir eher unelegant, das Attribut classdef abzuändern und wieder zurück zu ändern. Dabei werden die classdef files neu gelesen.
Gruss
Tobias
Mach ich, ich hab übrigens noch die Bodenfeuchte Messung unterschlagen:
define ba_Bodenfeuchte ECMDDevice adc 7
attr ba_Bodenfeuchte IODev AVRNETIO2
attr ba_Bodenfeuchte referenz 603
attr ba_Bodenfeuchte room Balkon
attr ba_Bodenfeuchte schwellwert 70
define Bodenfeuchtemessung at +*00:01 get ba_Bodenfeuchte value
attr Bodenfeuchtemessung room X_Timer
Hier das Log, reicht das so?
2014.05.02 11:42:38 2: autocreate: define ECMDDevice message port 0: 0x0a
2014.05.02 11:42:38 1: ERROR: Unknown module message
2014.05.02 11:42:39 2: After sleep: temp 5.7
2014.05.02 11:43:37 3: Bodenfeuchtemessung: value 23.22
2014.05.02 11:43:37 5: ECMDDevice: Analyze command >{"io get pin 0\n"}<
2014.05.02 11:43:37 4: ECMDDevice ba_Wassertonne status port 0: 0x0a
2014.05.02 11:43:37 3: Timer_ba_Wassertonne: status port 0: 0x0a
2014.05.02 11:44:37 5: AVRNETIO2: sending command "adc get 7\n"
2014.05.02 11:44:37 5: AVRNETIO2: write "adc get 7\n", expect .*
2014.05.02 11:44:37 5: SW: 6164632067657420370a
2014.05.02 11:44:37 5: AVRNETIO2: read "089 \n"
2014.05.02 11:44:37 5: AVRNETIO2: received answer "089 \n"
2014.05.02 11:44:37 3: Bodenfeuchtemessung: value 22.72
2014.05.02 11:44:37 5: ECMDDevice: Analyze command >{"io get pin 0\n"}<
2014.05.02 11:44:37 5: AVRNETIO2: sending command "io get pin 0\n"
2014.05.02 11:44:37 5: AVRNETIO2: write "io get pin 0\n", expect .*
2014.05.02 11:44:37 5: SW: 696f206765742070696e20300a
2014.05.02 11:44:37 5: AVRNETIO2: read "port 0: 0x0a\n"
2014.05.02 11:44:37 5: AVRNETIO2: received answer "port 0: 0x0a\n"
2014.05.02 11:44:37 4: ECMDDevice ba_Wassertonne status port 0: 0x0a
2014.05.02 11:44:37 3: Timer_ba_Wassertonne: status port 0: 0x0a
2014.05.02 11:45:37 5: AVRNETIO2: sending command "adc get 7\n"
2014.05.02 11:45:37 5: AVRNETIO2: write "adc get 7\n", expect .*
2014.05.02 11:45:37 5: SW: 6164632067657420370a
2014.05.02 11:45:37 5: AVRNETIO2: read "088 \n"
2014.05.02 11:45:37 5: AVRNETIO2: received answer "088 \n"
2014.05.02 11:45:37 3: Bodenfeuchtemessung: value 22.55
2014.05.02 11:45:37 5: ECMDDevice: Analyze command >{"io get pin 0\n"}<
2014.05.02 11:45:37 5: AVRNETIO2: sending command "io get pin 0\n"
2014.05.02 11:45:37 5: AVRNETIO2: write "io get pin 0\n", expect .*
2014.05.02 11:45:37 5: SW: 696f206765742070696e20300a
2014.05.02 11:45:37 5: AVRNETIO2: read "port 0: 0x0a\n"
2014.05.02 11:45:37 5: AVRNETIO2: received answer "port 0: 0x0a\n"
2014.05.02 11:45:37 4: ECMDDevice ba_Wassertonne status port 0: 0x0a
2014.05.02 11:45:37 3: Timer_ba_Wassertonne: status port 0: 0x0a
2014.05.02 11:46:37 5: AVRNETIO2: sending command "adc get 7\n"
2014.05.02 11:46:37 5: AVRNETIO2: write "adc get 7\n", expect .*
2014.05.02 11:46:37 5: SW: 6164632067657420370a
2014.05.02 11:46:37 5: AVRNETIO2: read "090 \n"
2014.05.02 11:46:37 5: AVRNETIO2: received answer "090 \n"
2014.05.02 11:46:37 3: Bodenfeuchtemessung: value 23.88
2014.05.02 11:46:37 5: ECMDDevice: Analyze command >{"io get pin 0\n"}<
2014.05.02 11:46:37 5: AVRNETIO2: sending command "io get pin 0\n"
2014.05.02 11:46:37 5: AVRNETIO2: write "io get pin 0\n", expect .*
2014.05.02 11:46:37 5: SW: 696f206765742070696e20300a
2014.05.02 11:46:37 5: AVRNETIO2: read "port 0: 0x0a\n"
2014.05.02 11:46:37 5: AVRNETIO2: received answer "port 0: 0x0a\n"
2014.05.02 11:46:37 4: ECMDDevice ba_Wassertonne status port 0: 0x0a
2014.05.02 11:46:37 3: Timer_ba_Wassertonne: status port 0: 0x0a
2014.05.02 11:47:37 5: AVRNETIO2: sending command "adc get 7\n"
2014.05.02 11:47:37 5: AVRNETIO2: write "adc get 7\n", expect .*
2014.05.02 11:47:37 5: SW: 6164632067657420370a
2014.05.02 11:47:37 5: AVRNETIO2: read "08C \n"
2014.05.02 11:47:37 5: AVRNETIO2: received answer "08C \n"
2014.05.02 11:47:37 3: Bodenfeuchtemessung: value 23.22
2014.05.02 11:47:37 5: ECMDDevice: Analyze command >{"1w convert\n"}<
2014.05.02 11:47:37 5: AVRNETIO2: sending command "1w convert\n"
2014.05.02 11:47:37 5: AVRNETIO2: write "1w convert\n"
2014.05.02 11:47:37 5: SW: 317720636f6e766572740a
2014.05.02 11:47:37 4: ECMDDevice ba_Temp_Steuereinheit messen
2014.05.02 11:47:37 5: ECMDDevice: Analyze command >{"io get pin 0\n"}<
2014.05.02 11:47:37 5: AVRNETIO2: sending command "io get pin 0\n"
2014.05.02 11:47:37 5: AVRNETIO2: write "io get pin 0\n", expect .*
2014.05.02 11:47:37 5: SW: 696f206765742070696e20300a
2014.05.02 11:47:38 5: AVRNETIO2: read "OK\n"
2014.05.02 11:47:38 5: AVRNETIO2: received answer "OK\n"
2014.05.02 11:47:38 4: ECMDDevice ba_Wassertonne status OK
2014.05.02 11:47:38 3: Timer_ba_Wassertonne: status OK
2014.05.02 11:47:38 5: AVRNETIO2: read "port 0: 0x0a\n"
2014.05.02 11:47:38 5: AVRNETIO2: Spontaneously received "port 0: 0x0a\n"
2014.05.02 11:47:38 5: AVRNETIO2 dispatch port 0: 0x0a
2014.05.02 11:47:38 2: autocreate: define ECMDDevice message port 0: 0x0a
2014.05.02 11:47:38 1: ERROR: Unknown module message
2014.05.02 11:47:39 5: ECMDDevice: Analyze command >{"1w get 282f1bc3030000d5\n"}<
2014.05.02 11:47:39 5: AVRNETIO2: sending command "1w get 282f1bc3030000d5\n"
2014.05.02 11:47:39 5: AVRNETIO2: write "1w get 282f1bc3030000d5\n", expect .*
2014.05.02 11:47:39 5: SW: 31772067657420323832663162633330333030303064350a
2014.05.02 11:47:39 5: AVRNETIO2: read "5.6\n"
2014.05.02 11:47:39 5: AVRNETIO2: received answer "5.6\n"
2014.05.02 11:47:39 4: ECMDDevice ba_Temp_Steuereinheit temp 5.6
2014.05.02 11:47:39 2: After sleep: temp 5.6
Guten Abend,
mal was Anderes zwischendurch- die angepasste lcd.classdef aus dem Wiki:
# Umsetzung der ECMD Befehle
set write params line col text
set write cmd {"lcd goto %line %col\n\000lcd write %text\n"}
set write expect "OK\n"
set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";}
set clear params col
set clear cmd {"lcd clear %col\n"}
set clear expect "OK\n"
set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";}
set clear_all cmd {"lcd clear\n"}
set clear_all expect "OK\n"
set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";}
set lcd_bl params state
set lcd_bl cmd {"lcd backlight %state\n"}
set lcd_bl expect "OK\n"
set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";}
Viele Grüße, Ricardo
Hallo Boris, Hallo Ricardo,
möchte die kompl. Log's für classdef Einträge Vers02 und Vers03 nachreichen, da größer, im Anhang.
Den NetIo kann ich erst in 2-3 Wochen mit Polling programmieren.
Herzlichen Dank für die gute Unterstützung.
Mit den besten Grüßen
Thomas
Zitat von: ext23 am 02 Mai 2014, 11:50:54
2014.05.02 11:47:37 5: ECMDDevice: Analyze command >{"1w convert\n"}<
2014.05.02 11:47:37 5: AVRNETIO2: sending command "1w convert\n"
2014.05.02 11:47:37 5: AVRNETIO2: write "1w convert\n"
2014.05.02 11:47:37 5: SW: 317720636f6e766572740a
2014.05.02 11:47:37 4: ECMDDevice ba_Temp_Steuereinheit messen
2014.05.02 11:47:37 5: ECMDDevice: Analyze command >{"io get pin 0\n"}<
2014.05.02 11:47:37 5: AVRNETIO2: sending command "io get pin 0\n"
2014.05.02 11:47:37 5: AVRNETIO2: write "io get pin 0\n", expect .*
2014.05.02 11:47:37 5: SW: 696f206765742070696e20300a
2014.05.02 11:47:38 5: AVRNETIO2: read "OK\n"
2014.05.02 11:47:38 5: AVRNETIO2: received answer "OK\n"
2014.05.02 11:47:38 4: ECMDDevice ba_Wassertonne status OK
2014.05.02 11:47:38 3: Timer_ba_Wassertonne: status OK
Da oben sieht man es knallen! Spendiere doch bitte mal dem messen-Befehl ein Expect, damit auf das OK vom "1w convert" gewartet wird.
Grüße
Boris
Zitat von: ThomasW am 03 Mai 2014, 12:10:51
möchte die kompl. Log's für classdef Einträge Vers02 und Vers03 nachreichen, da größer, im Anhang.
Das Postproc liefert 1 zurück, weil die Ersetzung erfolgreich war. Probiere mal bitte
{ s/\n//g; $_ }aus.
Grüße
Boris
Hallo Boris,
herzlichen Dank für die Hilfe, jetzt funktioniert es.
Beste Grüße
Thomas
Hallo,
könnt ihr bitte die funktionierende classdeff posten.
Danke
Hallo Heinz,
die bei mir funktionierende classdef für Temperaturen.
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
get temp cmd {"1w get %devID\n"}
get temp expect "\d+.\d\n"
get temp postproc { s/\n//g; $_ }
siehe auch Antwort 124 in diesem Trade.
Version1 = falsch
Version2 = fehlerhaft (letzte Zeile geändert)
Gruß
Thomas
Hallo,
danke, aber irgendwie stehe ich auf dem Schlauch.
Wie stößt du das messen an?
Gruß
Heinz
Hallo,
kleiner Nachtrag. Habe jetzt folgendes probiert, und es scheint zu laufen.
# Uebergabeparameter Onewire Geräte ID
params devID
# Umsetzung in ECMD Befehle 1w get = Tempwert lesen
set messen cmd {"1w convert\n"}
set messen expect".*"
get temp cmd {"1w get %devID\n"}
get temp expect "\d+.\d\n"
get temp postproc { s/\n//g; $_ }
Somit läuft die Poolheizung und alles ist gut.
Danke
Gruß Heinz
Hallo,
laufen jetzt die Klassendefinitionen bei allen, die sich in diesem Thread zu Wort gemeldet haben?
Ich würde dann nämlich diesen Thread in Kürze schließen.
Könnten diejenigen, die von dem Support in diesem Thread profitiert haben, bitte die Seite(n) im FHEM-Wiki auf den Stand bringen? Das betrifft vor allem die überarbeiteten Klassendefinitionen.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 05 Mai 2014, 10:04:37
laufen jetzt die Klassendefinitionen bei allen, die sich in diesem Thread zu Wort gemeldet haben?
Ich würde dann nämlich diesen Thread in Kürze schließen.
Ich habe jetzt folgende funktionierend getestete classdef's vorzuweisen:
- adc (A/D-Wandler mit Umrechnung nach dezimal; ohne weitere Bearbeitung)
- 1wire (DS18x20-Sensoren
mit aktiviertem Polling in Ethersex)
- ltc1257 (der 12-Bit-D/A-Wandler in dem Umfang wie im Wiki)
- dht22 (der günstige und sehr genaue Temp./Feuchte-Sensor mit readings für Temperatur und Feuchte)
- control6 (damit kann ich vorher in ethersex definierte contol6-Skripte bedienen)
- lcd (der im Wiki gezeigte Code; nur entsprechend angepasst)
- rfm12_it (für Intertechno-Aktoren zum Schalten)
- rfm12_2272 (für die preiswerten Baumarkt-Steckdosen; leider noch ohne Dip-Schalter-Berechnung)
Zitat von: Dr. Boris Neubert am 05 Mai 2014, 10:04:37
Könnten diejenigen, die von dem Support in diesem Thread profitiert haben, bitte die Seite(n) im FHEM-Wiki auf den Stand bringen? Das betrifft vor allem die überarbeiteten Klassendefinitionen.
Ich habe zweimal erfolglos versucht, mich im Wiki anzumelden. Keine Antwort. Ich würde aber gerne zuarbeiten- auch mit eigenen Bildern.
Edit: Gegenfrage! Gibt es denn noch Wünsche, was man wie einbinden könnte? An was wurde noch nicht gedacht? Wie war das genau mit "watch IO changes and react"?
Meine Ziele bei den classdef's: adc verfeinern mit Umrechnung und reading je Kanal in einem device; ltc1257 mit Umrechnung; rfm12_2272 mit Umrechnung der Dip-Schalter
Viele Grüße, Ricardo
Danke Boris, also aus meiner Sicht geht das in Ordnung. Ich kämpfe noch mit ein paar Sachen aber das bekomme ich auch noch hin.
Kannste stilllegen den Thread.
Gruß
Daniel
ZitatIch habe zweimal erfolglos versucht, mich im Wiki anzumelden. Keine Antwort. Ich würde aber gerne zuarbeiten- auch mit eigenen Bildern.
bitte mal an soulman@fhemwiki.de mailen.
Ich hab eben noch mal nachgesehen und kann nichts von dir finden.
Zitat von: ext23 am 05 Mai 2014, 21:23:09
Danke Boris, also aus meiner Sicht geht das in Ordnung. Ich kämpfe noch mit ein paar Sachen aber das bekomme ich auch noch hin.
Kannste stilllegen den Thread.
Sehe ich genauso. Den Rest schaffen wir auch noch. btw: Kann wer die Relaiskarte testen? Ich könnte das auf Wunsch anpassen, aber nicht praktisch testen.
Habe meine Wiki-Anmeldung erneut gesendet. Versuch #3 sollte nun klappen.
Ich sehe da zwei Etappen:1. den vorhandenen Beitrag auf die neue Syntax ohne sonstige weitere Änderungen anpassen
2. einen neuen Beitrag "Ethersex - eigene Plattformen" gestalten, der die beiden in den letzten 5 Monaten hier entstandenen Plattformen umschreibt. Mit Bildern, Screenshots aus Ethersex, Umschreibung 1w-Polling (mit den Tücken :P ), DHT22 und künftig Multi-DHT, Beispielcode fürs Display, Erstellung von readings usw.
Viele Grüße, Ricardo
Danke an Alle fürs Testen!
Grüße
Boris