Komplett überarbeitetes ECMD und ECMDDevice vom 16.3.2014

[Dr. Boris Neubert]

Warum nicht so:

Code Auswählen Erweitern

# 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

[kpwg]

Warum nicht so: ...

Kommt darauf an, ob und wie man T bein loggen benötigt. Klar geht es so auch und viel einfacher.

[Dr. Boris Neubert]

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

[ext23]

Nabend,

ich hab da noch ein Problem beim Einlesen des Digitaleingangs. Ich hab meine alte classdef mal so abgespeckt:

Code Auswählen Erweitern

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

[martinbaumert]

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

[Tom_S]

@ext23

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 ".*"

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ß

[Tom_S]

@martinbaumert

probier mal

Code Auswählen Erweitern


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

[kpwg]

Schaut doch im ECMD mit

Code Auswählen Erweitern

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

[ext23]

@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ß

[ckbln]

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

[Tom_S]

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?

[ThomasW]

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.

Code Auswählen Erweitern


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

[Dr. Boris Neubert]

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

[Dr. Boris Neubert]

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

[Dr. Boris Neubert]

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