ECMD und ECMDDevice grundlegend überarbeitet und erweitert

[Dr. Boris Neubert]

Hallo,

ich habe ECMD und ECMDDevice grundlegend überarbeitet und erweitert. Die wichtigsten Änderungen:

• ECMD verwendet nun die Routinen aus DevIo.pm für den Zugriff auf das physische Gerät.
• Man muß nun in der Klassendefinition angeben, ob und was als Antwort auf ein get- oder set-Kommando erwartet wird.
• Wird etwas erwartet aber bis zum Timeout nicht empfangen, dann wird die Verbindung zum Gerät neu aufgebaut und ein weiterer Versuch gemacht. Dies ermöglicht es, tote TCP/IP-Verbindungen wiederzuerwecken.
• Spontan, also nicht als Antwort auf ein Kommando vom physischen Gerät gelieferte Daten können nun anhand regulärer Ausdrücke in Readings geschrieben werden. Das ist ein lange gehegter Wunsch vieler hier im Forum gewesen.
• Die Sonderbehandlung von Newline-Zeichen (\n) entfällt. Daten werden nun geschrieben und gelesen, ohne daß die Newline-Zeichen verändert werden. Die meisten Klassendefinitionen werden daher angepaßt werden müssen. Wir eliminieren damit aber gleichzeitig Verwirrungspotential, was eigentlich gesendet und empfangen wird.
• Alle Daten von und zum Gerät können lesbar protokolliert werden.

Das sind umfangreiche Änderungen, weswegen ich diese nicht ohne umfangreichere Tests einchecken möchte. Bitte findet anbei daher die beiden Module in neuer Ausgabe sowie die (komplette) neue englische commandref.html. Die Module benötigen fhem.pl und DevIo.pm in den Versionen, welche heute eingecheckt wurden. Diese sind morgen auch per Update verfügbar.

Ich habe die Module getestet und sie funktionieren in meinen Anwendungsfällen. Bitte setzt jedoch die Module nicht ohne vorige Tests in einer Produktivumgebung ein. Wer seinen Forschungsreaktor im Keller durch einen Fehler in den Modulen zur Kernschmelze bringt, ist selbst schuld 

Ich bin die nächsten Tage nicht an meiner Maschine und kann an den Modulen nichts ändern.

Anmerkungen bitte in einem neuen Thread im Board "Sonstige Systeme" posten.

Viele Grüße
Boris

[Dr. Boris Neubert]

67_ECMDDevice.pm (Testversion im Board Ankündigungen):Fehlfunktion repariert für den Fall, daß für ein Device keine Readings definiert waren.Neue Version im ersten Post.

Bekannte Probleme: es kann sein, daß Ethersex zu rasch OK zurückliefert, so daß diese auf einmal ankommen und dann in der Antwort nicht durch \000 getrennt werden. Man kann sich helfen, indem man im Postprocessor \000 optional ersetzt.

[Dr. Boris Neubert]

66_ECMD.pm und 67_ECMDDevice.pm sowie commandref.html im ersten Post dieses Topics aktualisiert.

Neuerungen:

• Attribut IODev am ECMDDevice (commandref lesen für Details)
• keine \000 mehr als Separator für empfangene Daten zu Mehrfachkommandos
• diverser Kleinkram

Sofern keine Fehler mehr gemeldet werden, checke ich diese Module in zwei Wochen ein. Die Module werden dann über update verteilt. Wer seine Module dann aktualisiert, muß seine Klassendefinitionen anpassen!

[Dr. Boris Neubert]

 67_ECMDDevice.pm im ersten Post dieses Topics aktualisiert

Neuerungen:

• Parameter in regex für reading sollte nun funktionieren
• Potentielles Kompatibilitätsproblem mit älteren Perl-Versionen behoben

[Dr. Boris Neubert]

67_ECMDDevice.pm im ersten Post dieses Topics aktualisiert

Neuerungen:

• Events werden erzeugt.
• State hat die Form "CMD VALUE" oder "READING VALUE". Ist VALUE undefiniert oder leer, wird auch das dazwischenliegende Leerzeichen unterdrückt.

[Dr. Boris Neubert]

ECMD und ECMDDevice wurden soeben im SVN eingecheckt.

Ab morgen sind die neuen Versionen im Standard verfügbar und werden per update ausgeliefert.

[Dr. Boris Neubert]

Hallo,

es gibt zwei Neuerungen in ECMD und ECMDDevice:

- Ein Tag "state" in der Klassendefinition erlaubt es nun vorzugeben, dass der Wert eines bestimmten und nur dieses Readings in das state-Reading übernommen wird. Ist der Tag nicht vorhanden, bleibt es beim überkommenen Zustand: Name des zuletzt ausgeführten Kommandos oder zuletzt aktualisierten Reading konkateniert mit dessen Wert wird ins state-Reading geschrieben.
- Ein Attribut "split" am ECMD ermöglicht es, eine Übertragung vom Gerät an einem bestimmten Zeichen in mehrere Nachrichten aufzuspalten, die dann einzeln auf einen Match für Readings geprüft werden. Wer also vom Gerät zwei Meldung für Readings foo und bar erwartet, aber immer "foo 12\nbar off" erhält, kann nun diese Übertragung in "foo 12" und "bar off" zerlegen.

Viele Grüße
Boris

[Dr. Boris Neubert]

Hallo,

und nun endlich die Partial-Funktionalität in ECMD/ECMDDevice. Zu Testzwecken noch nicht eingecheckt sondern erstmal nur als Anlage zum ersten Post in diesem Thread.

Neues Attribut an ECMD:

Code: [Auswählen]

partial <seconds>
Some physical ECMD devices split readings and replies into several transmissions. If the partial attribute is set, this behavior
is accounted for as follows: (a) If a reply is expected for a get or set command, FHEM collects transmissions from the
physical ECMD device until either the reply matches the expected reply or the time in seconds given with the partial attribute
has expired. (b) If a spontaneous transmission does not match the regular expression for any reading, the transmission is
recorded and prepended to the next transmission. If the line is quiet for more than the time in seconds given with the partial
attribute, the recorded transmission is discarded.
Außerdem müssen reguläre Ausdrücke bei match und expect nun immer auf die gesamte Antwort oder Aussendung vom physikalischen Gerät passen, also wie bei m/^Ausdruck$/. Das war vorher uneinheitlich gelöst.

Erfahrungsberichte bitte in "Sonstige Systeme" posten.

Viele Grüße
Boris

[Dr. Boris Neubert]

Per eben eingecheckt.

Das Modul ist leider langsam aufgrund der vielen Aufrufe von ReplaceSpecials. Für eine künftige Version will ich prüfen, ob die regex- und postproc-Perl-Specials mit vorgefertigten Ersetzungen je Device gecachet werden können.

BN

[Dr. Boris Neubert]

Hallo,

ich habe eine neue Version von ECMDDevice eingecheckt. In dieser Version werden die postprocs und matches für Readings nach Ersetzung der Specials und Parameter zwischengespeichert. Dadurch wird die Laufzeit des Moduls drastisch reduziert.

Beispiel: auf meinem Raspberry Pi wurde die Laufzeit für meinen Netzwerkmonitor, welcher den Zustand von ca. 10 Maschinen im lokalen Netzwerk überwacht, mit ca. 560 ms pro Aufruf um etwa 60 % reduziert (gemessen mit apptime). Dadurch verbessert sich das Antwortverhalten von FHEM (Schwuppdizität) auf meiner Installation erheblich.

Berichte über Erfolge oder Nebenwirkungen bitte wie üblich in einem neuen Thread im Board "Sonstige Systeme" posten.

Grüße
Boris