[bedingt gelöst] End of data in parsing input stream010 at ...

[TomLee]

Hallo nochmal,

einen bzw. zwei Logeinträge hab ich noch die ich gerne nicht mehr hätte, mir nicht zu helfen weiß.
Es steht zwar Fehler im Log, setreading inot_Umsatz umsatzmtl $umsatzmtl wird aber korrekt ausgeführt, also es klappt alles wie es soll.
Bin eigentlich der Meinung alles wie bei meiner alten Installation gemacht zu haben, da hatte ich das nicht.

Code Auswählen Erweitern

defmod inot_Umsatz inotify /tmp UMFHEM.*
attr inot_Umsatz fhem_widget_channels [{"alias":"Umsatz","order":1,"allowed_values":[],"controlled_attribute":"STATE"}]
attr inot_Umsatz mask IN_ATTRIB
attr inot_Umsatz room Büro,Fhem_Widget
attr inot_Umsatz stateFormat umsatzmtl €

setstate inot_Umsatz xxxxxx,xx €
setstate inot_Umsatz 2019-09-24 11:44:37 lastEventFile /tmp/UMFHEM.csv
setstate inot_Umsatz 2019-09-24 11:44:37 lastEventMask IN_ATTRIB
setstate inot_Umsatz 2019-09-24 11:44:37 umsatzmtl xxxxxx,xx

Code Auswählen Erweitern

defmod not_inot_Umsatz notify inot_Umsatz:lastEventFile:.* { my $umsatzmtl = readCSV("/tmp/UMFHEM.csv","Umsatz");;;;\
{fhem ("setreading inot_Umsatz umsatzmtl $umsatzmtl")}}
attr not_inot_Umsatz room Büro

setstate not_inot_Umsatz 2019-09-24 11:44:37
setstate not_inot_Umsatz 2019-09-22 20:53:42 state active

Code Auswählen Erweitern

2019.09.24 11:44:37 1: ERROR evaluating my $EVTPART1='/tmp/UMFHEM.csv';my $EVENT='lastEventFile: /tmp/UMFHEM.csv';my $TYPE='inotify';my $SELF='not_inot_Umsatz';my $NAME='inot_Umsatz';my $EVTPART0='lastEventFile:';{ my $umsatzmtl = readCSV("/tmp/UMFHEM.csv","Umsatz");;
{fhem ("setreading inot_Umsatz umsatzmtl $umsatzmtl")}}: 2012EOF - End of data in parsing input stream010 at /usr/local/share/perl/5.24.1/Text/CSV/Slurp.pm line 101.

2019.09.24 11:44:37 3: not_inot_Umsatz return value: 2012EOF - End of data in parsing input stream010 at /usr/local/share/perl/5.24.1/Text/CSV/Slurp.pm line 101.

Code Auswählen Erweitern


##################################################################
# Routine zum Einlesen einer CSV-Datei

#!/usr/bin/perl

package main;

use strict;
use warnings;
use POSIX;
use strict;
use warnings;
use Text::CSV::Slurp;

sub myUtilsCSV_Initialize($$)
{
my ($hash) = @_;
}

####################################################################
sub readCSV ($$)
{

my ($csvDatei, $Spalte) = @_;
my $slurp = Text::CSV::Slurp->new();

my $Wert;
my $Datum;

# CSV Options - see Text::CSV
my %csv_options = (
sep_char => ';',
binary => '1',
);

# Reference to an array of hashes
my $data = $slurp->load( file => $csvDatei, %csv_options );

foreach my $row (@$data) {
$Wert = $row->{$Spalte};
}

return $Wert
}
1;

Der Inhalt der CSV-Datei

Code Auswählen Erweitern

"Monat";"Umsatz"
"September 2019";xxxxxx,xx

Gruß

Thomas

[TomLee]

In Zeile 101 der Slurp.pm steht der else-Zweig folgender Funktion :

Code Auswählen Erweitern

91 sub _from_handle {
92  my $io  = shift;
..  my $opt = shift;
..
..  my $csv = Text::CSV->new($opt);
..
..  if ( my $head = $csv->getline($io) ) {
..    $csv->column_names( $head );
..  }
..  else {
101    die $csv->error_diag();
102  }

Kann jemand mit der Info sagen, was der mögliche Grund für die Fehlermeldung ist ?

Gruß

Thomas

[Otto123]

Hallo Thomas,

ich habe keine Ahnung, finde interessant das es sowas gibt (CSV Import) 
Beim Googeln nach der Fehlernummer 2012EOF  habe ich Hinweise gefunden, dass slurp nur Zeichen 20-7F akzeptiert und deshalb eventuell das Dateiende EOF nicht erkennt.

Wo September da auch März? Das ä wäre außerhalb von 20-7F

Also nur ein Vermutung...

Gruß Otto

[TomLee]

Hier hab ich das her, würd mich wundern das du den Beitrag nicht kennst.

Wie gesagt, auf meiner alten Installation hatte ich den Logeintrag nicht und da lief das rund 1 1/2 Jahre, deshalb schliesse ich mal

Wo September da auch März? Das ä wäre außerhalb von 20-7F

vorsichtig aus.

Gruß

Thomas

[TomLee]

Muss mich korrigieren. Sry.

Hab mir mittlerweile LogFiles meiner alten Installation angeschaut, damals hatte ich die Log-Einträge auch.


Die UMFHEM.csv Datei exportiere ich aus einer Access2000-Datenbank  via VBA in den Ordner /tmp , nur dann hab ich den Fehler im Log.

Bearbeite ich die Datei händisch gibt es keine Meldungen im Log.

Sollte jemand weiterhelfen können wie ich den Fehler im Log vermeiden könnte mit folgendem DoCmd-Objekt hab ich das exportieren umgesetzt:

Code Auswählen Erweitern

DoCmd.TransferText acExportDelim, "UMFHEM-Exportspezi", _
"qry_UMFHEM", "\\192.168.188.26\Raspi3tmp\UMFHEM.csv", True

Gruß

Thomas

[Otto123]

Hallo Thomas,

mal versucht die CSV Datei ins Unix Text Format zu konvertieren? Windows hat 0D 0A als Zeilenumbruch Unix nur 0A. (CR LF | \r \n)

Gruß Otto

[TomLee]

Hallo Otto,

musste mich auch erstmal wieder eindenken, die Parameter für das konvertieren gibt man in einer Exportspezifikation (hier die UMFHEM-Exportspezi) an und in der war tatsächlich Westeuropäisch (Windows) angegeben. Das hab ich jetzt geändert in Unicode (UTF-8), es bleibt aber bei der Meldung im Log.

Eine andere Sprache einzustellen ist irgendwie nicht möglich, da kommt dann gleich ein Popup-Fenster: Die Einstellung für diese Eigenschaft ist zu lang

Gruß

Thomas

[Otto123]

Moin,

na Zeichensatz ist das Eine, Zeilenumbruch ist etwas anderes. Windows schreibt CR LF und die meisten Linux Programme kommen damit nicht zurecht.

Gruß Otto

[TomLee]

In anderen Worten es bleibt bloß ein verbose 0 im notify und inotify ?

[Otto123]

Du verstehst mich nicht, hast Du die Datei mal von den Windows Zeilenumbrüchen befreit? Das ist doch absolut easy?

Ich dachte ich habe das schon geschrieben: dos2unix oder im notepadd++ und rechts mit der rechten Maustaste konvertieren oder tr -d '\r'

[TomLee]

Ja ich komm irgendwie nicht mit, was bringt mir das wenn ich händisch die Datei ändere und es dann klappt.

Die Datei wird doch immer wieder neu exportiert, manchmal mehrmals am Tag, manchmal gar nicht, ich muss doch schauen das die Zeilenumbrüche erst gar nicht exportiert werden.

[Otto123]

Was es Dir bringt? Du bist ein Witzbold Dann wüsstest Du die Ursache und man könnte etwas in Deine Importroutine einbauen 

Wenn Du am export nichts machen kannst - dann bleibt Dir der Import, den hast "Du" doch gemacht

Versuch macht kluch

[TomLee]

Also mAn liegts nicht an dem CR LF.
Ich kann die Datei UMFHEM.csv mit Notepad++ öffnen, unten rechts sieht man das der Windows (CR LF) Zeilenumbruch verwendet wird, den Umsatz bearbeiten, ohne weitere Änderungen speichern, das inotify reagiert und es gibt keinen Log-Eintrag.

[TomLee]

Weitere Feststellung. Speichere ich die Datei in Notepad++ mit der Angabe UNIX (LF) kann ich genau einmal exportieren und es kommt kein Log-Eintrag, beim zweiten exportieren ist er wieder da.

Also liegts wsl. doch an dem CR LF.

[Otto123]

Das verwirrt mich jetzt, Du redest vom exportieren....
Du meinst importieren in FHEM?

Also wenn die Erkenntnis ist: mit LF gibt es keinen Log Eintrag mit CR LF gibt es einen bedeutet das man muss vor dem Einlesen die Datei vom CR befreien.
Ich habe keine schnelle Lösung weil deine Importroutine aus meiner Sicht für 2 Werte importieren ziemlich komplex ist
Eigentlich müsste man einfach die Originaldatei nehmen. Eine Zeile shell code

Code Auswählen Erweitern

cat original.csv|tr -d '\r' > kopie.csv und statt der original.csv die kopie.csv einlesen.

Deine Datei hat wirklich immer bloß 2 Werte?

Gruß Otto