Seriell gelesene Daten grafisch darstellen

[efyzz]

Moin,

dies ist meine zweite Anfrage im Forum. Ich habe noch sehr wenig Ahnung von FHEM, wenig von Linux, schlechte C-Kenntnisse und Perl schon mal gar nicht. Was ich kann, ist Assembler auf 8051 programmieren  Daher habe ich mir mal was ganz einfaches vorgenommen: 

FHEM läuft auf einem RasPi 3B mit USB/serial-Converter.

Ich habe eine selbst gebastelte Heizungssteuerung auf Basis eines 8051-kompatiblen uC. Diese sendet zur Zeit einfach jede Sekunde einen Wert in hex. Also z.B. die Vorlauftemperatur 60°C wird gesendet als 3C. So werden ca. 30 Hex-Werte nacheinander gesendet, nach 1min geht's von vorne los.

Diese Werte würde ich gern mit gplot grafisch anzeigen. Ich hab's schon irgendwie geschafft, die serielle Schnittstelle mittels ECMD zu öffnen. Nun erhalte ich (wahrscheinlich für euch völlig logisch) sowas hier:

Code Auswählen Erweitern

2016-12-16_12:58:38 Seriell UNKNOWNCODE 
2016-12-16_12:58:39 Seriell UNKNOWNCODE 
2016-12-16_12:58:40 Seriell UNKNOWNCODE c
2016-12-16_12:58:41 Seriell UNKNOWNCODE v
2016-12-16_12:58:42 Seriell UNKNOWNCODE U
2016-12-16_12:58:43 Seriell UNKNOWNCODE �
2016-12-16_12:58:44 Seriell UNKNOWNCODE U
2016-12-16_12:58:45 Seriell UNKNOWNCODE �
2016-12-16_12:58:46 Seriell UNKNOWNCODE
2016-12-16_12:58:47 Seriell UNKNOWNCODE

Die empfangenen Werte können also nicht interpretiert werden. Hier könnte ich mein Programm auf der Heizungssteuerung anpassen, damit für EMCD verständliche Zeichen gesendet werden. Die Frage ist, was wird erwartet, ASCII?

Um die einzelnen Parameter (Vorlauftemperatur, Rücklauftemperatur, Mischerposition, ...) voneinander zu trennen, müsste im Log z.B. statt UNKNOWNCODE etwas sinnvolles stehen. Dann könnte ich das gplot so konfigurieren, dass sie getrennt dargestellt werden. Was müsste mein uC senden, damit hier was sinnvolles steht?

Also es gibt 2 Möglichkeiten:
1) Ich passe meine Heizungssteuerung so an, dass EMCD die Werte in der Standardkonfiguration versteht. Und ich somit etwas erhalte, dass man mit gplot anzeigen kann.
2) Ihr erklärt mir, wie man EMCD so konfiguriert, dass es das Gequatsche von meiner Steuerung versteht. Dann aber bitte gaaanz langsam und deutlich sprechen 

Ich danke euch!

[efyzz]

Nabend,

was darf ich daraus schließen, dass mir keiner antwortet?

Kann niemand helfen oder will man nicht, weil man gar nicht weiß, wo man bei mir anfangen soll? 

Ansonsten vielleicht jemand einen Tipp, wo ich anfangen könnte zu lesen? Im FHEM Wiki wird ECMD praktisch gar nicht behandelt und die ECMD-Doku http://www.ethersex.de/index.php/ECMD_(Deutsch) ist mir viel zu abgehoben ...

Also nochmals danke im Voraus!

[Otto123]

Ansonsten vielleicht jemand einen Tipp, wo ich anfangen könnte zu lesen? Im FHEM Wiki wird ECMD praktisch gar nicht behandelt und die ECMD-Doku

Hi,

also ich habe keine Ahnung was Du willst, aber zum lesen habe ich den Tipp:
http://fhem.de/commandref.html#ECMD

Vor dem Wiki kommt auf alle die commandref zum lesen!

Gruß Otto

[efyzz]

Danke, dann werde ich jetzt wohl öfter mal ins Commandref schauen 

Es wird offensichtlich überall davon ausgegangen, dass man schon Ethersex auf seinem uC laufen hat. Aber das ist im Prinzip genau das, was mir fehlt. Mein uC spricht (noch) kein Ethersex.

Die Frage ist also, was ich muss minimal in meinen uC implementieren, damit er als ECMD-Device akzeptiert wird?

Ich bräuchte erst mal eine Art Ablauf-Diagramm des Kommunikationsprotokolls. Dann könnte ich das nachbauen.

PS: Hier wird dieselbe Frage gestellt, aber auch nicht beantwortet:
https://forum.fhem.de/index.php?topic=11084.0

[oviwan]

Hi,

hatte die Tage bereits Deinen Beitrag gelesen. Ich habe die gleiche Situation, ich will mit meiner C-Control Heizungssteuerung quatschen. Auf einem Fhem Treffen habe ich zusammen mit jemanden, der in Fhem fit ist, ein Grundgerüst mit ECMD zusammen gekloppt. Das läuft auf einem Test RPI. Sendet Befehle Fhem->Serieller ausgang und empfängt Werte. Bei mir zur Zeit noch im Testaufbau über Terminal-Programm. Mit dem Eintrag in der Commandref konnte ich zuerst auch nix anfangen, da brauchts nen paar Schläge auf den Hinterkopf.

Leider brennts bei uns an allen Ecken und Kanten, sonst würde ich dir die Konfig schicken und Dich bis dahin durch lotsen. Das wird aber nix vor Ende Januar. Nur soviel, es ist im Endeffekt einfacher als man glaubt. Du kannst 90% über ECMD lösen, auch das Postprocessing wo die eingehenden Werte konvertiert bzw. gefiltert aufbereitet und als Reading dargestellt werden. Bei der Hex-Wert Geschichte bin ich mir nicht so sicher ob es nicht einfacher wäre wenn Du von Deiner Steuerung Klartext senden würdest, z.B. T1:xx.xx T2:xx.xx etc. Dann über Regular Expressions T1, T2 usw. auf Readings umschlüsseln und nur die Werte xx.xx übergeben.

Harry

[efyzz]

sonst würde ich dir die Konfig schicken und Dich bis dahin durch lotsen. Das wird aber nix vor Ende Januar.

Da würde ich mich sehr freuen. Bis dahin habe ich noch genügend andere Baustellen, mit denen ich mich beschäftigen kann 

[efyzz]

Ich bin schon mal einen Schritt weiter.

Code Auswählen Erweitern

get Heizungssteuerung raw { "A" }

Sendet ein A zum uC und erwartet eine Antwort. Also werde ich meinen uC so programmieren, dass er darauf reagiert und eine sinnvolle Antwort sendet. So einfach ist das

[efyzz]

Moin,

ich kann nun mit

Code Auswählen Erweitern

get Heizungssteuerung raw {"<Zeichen>"}
meinen uC dazu auffordern, einen Wert zurück zu senden.

Wenn ich für <Zeichen> eine 1 einsetze, erhalte ich z.B. die Vorlauftemperatur zurück und zwar bestehend aus 4 Byte in ASCII codiert. Z.B. für 57,5°C bekomme ich "5", "7", ".", "5".

Leider erhalte ich als Antwort in FHEM immer nur das erste Zeichen. Den Rest finde ich jedoch im Log als unknown command:

Code Auswählen Erweitern

2016.12.22 14:52:59 0: Heizungssteuerung: write "1", expect .*
2016.12.22 14:52:59 0: Heizungssteuerung: read "5"
2016.12.22 14:52:59 0: Heizungssteuerung: read "7"
2016.12.22 14:52:59 3: Heizungssteuerung: Unknown code 7, help me!
2016.12.22 14:52:59 0: Heizungssteuerung: read "."
2016.12.22 14:52:59 3: Heizungssteuerung: Unknown code ., help me!
2016.12.22 14:52:59 0: Heizungssteuerung: read "5"
2016.12.22 14:52:59 3: Heizungssteuerung: Unknown code 5, help me!


Also nun ist das ECMD-Plugin dran ... da komme ich nicht mehr weiter 

Wie erkläre ich dem Teil, dass es mehrere Byte lesen soll?

[efyzz]

Nabend,

hier nochmal mein aktueller Stand, vielleicht kann mir ja doch mal jemand helfen.

Ich habe mir inzwischen eine einfache Classdef gebaut, die z.B. sowas enthält:

Code Auswählen Erweitern

get AussenTemp cmd {"1"}
get AussenTemp expect ".*"

get WWTemp cmd {"2"}
get WWTemp expect "\d+.\d\n"


Sprich, es wird eine 1 bzw. eine 2 an meine Heizungssteuerung gesendet, um die Aussentemperatur bzw. die Warmwassertemperatur anzufordern. Die Heizungssteuerung antwortet dann wie gesagt mit einer Temperatur, bestehend aus 4 ASCII-Zeichen, wie z.B. "5", "7", ".", "5" für 57.5°C, gefolgt von einem "\n".

Wie man sieht, habe ich mit verschiedenen Ausdrücken für expect rumprobiert.
".*" sollte wohl alles akzeptieren, während "\d+.\d\n" nach meinem Verständnis genau mein Format erwarten sollte.

Es ist jedoch so, dass FHEM nur die erste empfangene Ziffer als Antwort interpretiert und die restlichen Zeichen als "unknown" einstuft. Meistens so:

Code Auswählen Erweitern

2017.01.05 21:21:57 0: ttyHeizung: write "2", expect \d+.\d\n
2017.01.05 21:21:57 0: ttyHeizung: read "4"
2017.01.05 21:21:57 1: ttyHeizung: unexpected answer "4" received (wrote "2", expected \d+.\d\n)
2017.01.05 21:21:57 0: ttyHeizung: read "9"
2017.01.05 21:21:57 0: ttyHeizung: read "."
2017.01.05 21:21:57 0: ttyHeizung: read "0"
2017.01.05 21:21:57 0: ttyHeizung: read "\n"
2017.01.05 21:21:57 3: ttyHeizung: Unknown code, help me!

Manchmal werden aber auch die letzten Zeichen zu einem String zusammengefasst, etwa so:

Code Auswählen Erweitern

2017.01.05 21:20:52 0: ttyHeizung: write "2", expect \d+.\d\n
2017.01.05 21:20:52 0: ttyHeizung: read "4"
2017.01.05 21:20:52 1: ttyHeizung: unexpected answer "4" received (wrote "2", expected \d+.\d\n)
2017.01.05 21:20:52 0: ttyHeizung: read "9.0\n"

Ich habe fast schon das Gefühl, dass dem ECMD die Pausen zwischen den empfangenen Bytes zu lang ist, obwohl mein Prozessor alles gibt. Leider kann er jedoch nur mit 2400 Baud senden (die Pausen zwischen den Bytes sind wenige us lang). Vielleicht ist ECMD dafür einfach zu ungeduldig? Könnte mir vorstellen, dass das mit so niedrigen Baudraten nie getestet wurde ...

Danke für eure Hilfe!

[Florian_GT]

Hier mal ein Beispiel von mir, das sollte dir ggf. helfen...

adc.classdef:

Code Auswählen Erweitern

# Uebergabeparameter Portnummer des internen Analogeingangs
# Beispiel: 3
params PortID
get adc cmd {"adc get %PortID\n"}
get adc expect "([A-F0-9]{3}) \n"
get adc postproc {\
s/([A-F0-9]{3}) \n/$1/;\
\
if (defined($1)) {\
   my $hash  = $defs{%NAME};\
   my $hexval = hex(trim("$1"));\
   my $refval = trim(AttrVal("%NAME","referenz",1023));\
   my $retval = ($hexval*100)/$refval;\
   my $state = "P: $retval";\
   \
   readingsSingleUpdate($hash, "adc_raw", $hexval, 1);\
   readingsSingleUpdate($hash, "percentage", $retval, 1);\
   readingsSingleUpdate($hash, "state", $state, 1);\
}\
}

#get portvalue cmd {"adc get %PortID\n"}
#get portvalue expect ".*"
#get portvalue postproc {hex(trim("$_"))}


fhem.cfg

Code Auswählen Erweitern

### NETIO - NETIO_04
define NETIO_04 ECMD telnet 192.168.178.252:2701
attr NETIO_04 classdefs onewire_ethersex=./conf/onewire.classdef:pin=./conf/pin.classdef:pinstate=./conf/pinstate.classdef:dht22=./conf/dht.classdef:adc=./conf/adc.classdef:mq=./conf/mq.classdef:bmp085=./conf/bmp.classdef:c6counter=./conf/c6counter.classdef
#attr NETIO_04 requestSeparator ^@


Code Auswählen Erweitern

define windr ECMDDevice adc 4
attr windr IODev NETIO_04
attr windr alias Windrichtung
attr windr event-min-interval .*:1800
attr windr event-on-change-reading .*
attr windr group Wetterstation
attr windr icon weather_directions
attr windr room Alle
attr windr stateFormat { sprintf("%s (%.2f%%)", ReadingsVal("windr","wind_direction",0), ReadingsVal("windr","percentage",0)) ;; }
attr windr userReadings wind_direction { asc_degrees_to_direction(ReadingsVal("windr","percentage",0)) ;; }
define FileLog_windr FileLog ./log/data/windrichtung-%Y-%m.log windr
attr FileLog_windr logtype text