Rückmeldung: ECMD und ECMDDevice, Anstehende Änderung von Defaults beachten

Begonnen von Reinhart, 03 Dezember 2016, 09:37:56

Vorheriges Thema - Nächstes Thema

Reinhart

@Boris

ich habe jetzt einige Tage die neue Version der beiden Module getestet und es sind keine Fehler aufgetreten. Ich benutze ECMD zum Auslesen von eBus Informationen von einem entfernten Raspberry seit über 2 Jahren.

Die einzige Änderung musste ich am Rückgabewert durchführen, wenn dieser nicht formatiert wurde. Hier ein Beispiel eines Datensatzes vom eBus.

# Aussentemperatur
get Aussentemp cmd {"r -f outsidetemp temp\n"}
get Aussentemp expect ".*\n*"
get Aussentemp postproc {$_}

vor der Änderung  (s. Bild1)

get Aussentemp postproc { sprintf("%5.2f",$_) }
mit der neuen Version nun den Rückgabewert einfach mit sprintf formatiert dann verschwinden die Formatierungszeichen <pre> (s. Bild2)

LG
Reinhart

FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Dr. Boris Neubert

Hallo Reinhart,

Danke für Deine Rückmeldung.

Die <pre>-Zeichen werden aber nicht vom Modul eingefügt. Wo kommen die denn her und warum verschwinden sie, wenn Du ein sprintf auf sie loslässt?

Kannst Du bitte mal wieder auf die alte postproc zurückgehen und einen Mitschnitt mit maximalen Logging und trafficLog hier posten?

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Reinhart

hier das Log einmal mit und ohne dem "sprintf", der Fehler ist dann wieder da.

2016.12.03 20:15:13 4: WEB_10.0.0.100_59996 GET /fhem?detail=Aussentemp; BUFLEN:0
2016.12.03 20:15:13 4: name: /fhem?detail=Aussentemp / RL:6143 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.03 20:15:13 4: WEB_10.0.0.100_59993 GET /fhem?detail=Aussentemp; BUFLEN:0
2016.12.03 20:15:13 4: name: /fhem?detail=Aussentemp / RL:6143 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.03 20:15:13 4: Connection closed for WEB_10.0.0.100_59996: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
2016.12.03 20:15:14 4: WEB_10.0.0.100_59993 GET /fhem?XHR=1&inform=type=status;filter=Aussentemp;since=1480792512;fmt=JSON&fw_id=1992×tamp=1480792513971; BUFLEN:0
2016.12.03 20:15:16 4: Connection closed for WEB_10.0.0.100_59992: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
2016.12.03 20:15:16 4: WEB_10.0.0.100_59994 POST /fhem?detail=Aussentemp&dev.getAussentemp=Aussentemp&cmd.getAussentemp=get&arg.getAussentemp=Aussentemp&val.getAussentemp=&XHR=1&addLinks=1&fw_id=1992; BUFLEN:0
2016.12.03 20:15:16 5: Cmd: >get Aussentemp Aussentemp<
2016.12.03 20:15:16 5: ECMDDevice: Analyze command >{"r -f outsidetemp temp\n"}<
2016.12.03 20:15:16 5: EBUS: sending command r -f outsidetemp temp\n (\162\040\055\146\040\157\165\164\163\151\144\145\164\145\155\160\040\164\145\155\160\012)
2016.12.03 20:15:16 5: SW: 72202d66206f75747369646574656d702074656d700a
2016.12.03 20:15:16 5: EBUS: received answer -3.88\n\n (\055\063\056\070\070\012\012)
2016.12.03 20:15:16 5: Postprocessing "-3.88\n\n" with perl command {$_}.
2016.12.03 20:15:16 5: Postprocessed value is "-3.88\n\n".
2016.12.03 20:15:16 5: Triggering Aussentemp (2 changes)
2016.12.03 20:15:16 5: Starting notify loop for Aussentemp, 2 event(s), first is Aussentemp: -3.88\n\n
2016.12.03 20:15:17 5: Notify from Device: Aussentemp recieved
2016.12.03 20:15:17 4: name: /fhem?detail=Aussentemp&dev.getAussentemp=Aussentemp&cmd.getAussentemp=get&arg.getAussentemp=Aussentemp&val.getAussentemp=&XHR=1&addLinks=1&fw_id=1992 / RL:67 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/

get Aussentemp postproc {$_} mit dem besagten <pre> in der Ausgabe, siehe Bild.


2016.12.03 20:36:48 4: WEB_10.0.0.100_60381 POST /fhem?detail=Aussentemp&dev.getAussentemp=Aussentemp&cmd.getAussentemp=get&arg.getAussentemp=Aussentemp&val.getAussentemp=&XHR=1&addLinks=1&fw_id=1980; BUFLEN:0
2016.12.03 20:36:48 5: Cmd: >get Aussentemp Aussentemp<
2016.12.03 20:36:48 5: ECMDDevice: Analyze command >{"r -f outsidetemp temp\n"}<
2016.12.03 20:36:48 5: EBUS: sending command r -f outsidetemp temp\n (\162\040\055\146\040\157\165\164\163\151\144\145\164\145\155\160\040\164\145\155\160\012)
2016.12.03 20:36:48 5: SW: 72202d66206f75747369646574656d702074656d700a
2016.12.03 20:36:48 5: EBUS: received answer -3.88\n\n (\055\063\056\070\070\012\012)
2016.12.03 20:36:48 5: Postprocessing "-3.88\n\n" with perl command { sprintf("%5.2f",$_) }.
2016.12.03 20:36:48 5: Postprocessed value is "-3.88".
2016.12.03 20:36:48 5: Triggering Aussentemp (2 changes)
2016.12.03 20:36:48 5: Starting notify loop for Aussentemp, 2 event(s), first is Aussentemp: -3.88
2016.12.03 20:36:48 5: Notify from Device: Aussentemp recieved
2016.12.03 20:36:48 5: DbLog: logging of Device: Aussentemp , Type: ECMDDEVICE , Event: Aussentemp: -3.88 , Reading: Aussentemp , Value: -3.88 , Unit:
2016.12.03 20:36:48 5: DbLog: logging of Device: Aussentemp , Type: ECMDDEVICE , Event: Aussentemp -3.88 , Reading: state , Value: Aussentemp -3.88 , Unit:
2016.12.03 20:36:48 4: name: /fhem?detail=Aussentemp&dev.getAussentemp=Aussentemp&cmd.getAussentemp=get&arg.getAussentemp=Aussentemp&val.getAussentemp=&XHR=1&addLinks=1&fw_id=1980 / RL:67 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/

get Aussentemp postproc { sprintf("%5.2f",$_) }

Ich sehe hier allerdings auch nirgends wo das <pre> herkommen soll. Wenn der Fehler nach der Abfrage da ist und ich drücke "F5" für Browser Refresh, ist er auch schon verschwunden. Seltsames verhalten, mich stört das auch nicht weil es ohnehin besser ist jede Rückgabe zu formatieren.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Reinhart

ich glaube das hat überhaupt nichts mit der ECMD Änderung zu tun, denn wenn ich nun alles auf die alten Module umstelle gibt es den selben Ausgabefehler, nur fällt der nur auf wenn man gezielt darauf achtet und das habe ich beim Test der neuen Version getan.

Im Normalfall werden die ECMD Devices bei mir über einen Timer abgefragt und der liefert im Output saubere Ergebnisse, auch wenn das <pre> in der manuellen Abfrage (direkt über get) enthalten ist (siehe Bild, Fehler bei Abfrage ist da und in Fhem sieht man nichts davon).

D.H, die neuen ECMD Module zeigen keine weitere Unauffälligkeit und funktionieren fehlerfrei. Separatoren habe ich leider keine im Einsatz.
Sorry, wenn ich dich jetzt etwas verwirrt habe.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa