Komplett überarbeitetes ECMD und ECMDDevice vom 16.3.2014

[kpwg]

Tja, mit Nachdenken kommt man auch von selbst drauf:

Code Auswählen Erweitern

get value expect "^\d+ \n$" funktioniert natürlich... 

[Dr. Boris Neubert]

Code Auswählen Erweitern

get value expect "^\d+ \n$" funktioniert natürlich... 

Ups, ich hatte die +-Taste nicht gedrückt. 

Viele Grüße
Boris

[Dr. Boris Neubert]

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

[kpwg]

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

[kpwg]

Es gibt Neuigkeiten: den DHT22 habe ich nun ordentlich eingebunden! Es werden zyklisch mit nur einem at Befehl

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[Tom_S]

ich 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

[Dr. Boris Neubert]

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

Viele Grüße
Boris

[kpwg]

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.

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

[tpm88]

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

[Dr. Boris Neubert]

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

[kpwg]

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

[Dr. Boris Neubert]

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

[kpwg]

Ich denke, ESEND wäre gut geeignet. Ein Link mit Beispiel: 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.

[H_doc]

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

[Dr. Boris Neubert]

Hallo Heiner,

bitte füge noch Deine Definition der ECMD- und ECMDDevice-Geräte sowie Deine classdef bei.

Danke
Boris