Hallo Wilfried,
ich bin mit meinem Latein am Ende. Ich sende Dir jetzt aber noch eine Mail dazu.
2. WsWin-Instanz und Dateiüberwachung
Moderatoren: Werner, Tex, weneu
- Tex
- Moderator
- Beiträge: 2007
- Registriert: 04 Aug 2014 17:47
- Wohnort: Woldegk
- Hat sich bedankt: 3 mal
- Danksagung erhalten: 45 mal
- Kontaktdaten:
Ohne jetzt dieses Problem erklären zu können, es gäbe die Alternative via merge.csv.
In der 1. WSWIN-Instanz eine Datei merge.txt erstellen - und hier alle Sensoren eintragen. Diese merge.txt mit customfile an die 2. Instanz schicken und diese liest dann die Werte ein. Wie das genau geht habe ich mal im Forum beschrieben und steht auch irgendwo bei Werners Hilfedateien drin. Ist gar nicht so schlimm.
So eine merge.txt sieht ungefähr so aus:
%customfile=C:\WSWIN2\ws_merge.csv%
<!-- %openfile=nächste-datei.txt% -->
,,0,18,42,43,44,usw...
%unit_off%%alwaysmetric_on%%alwaysseppoint_on%%ws_date%,%ws_time%,%curval[0]%,%curval[18]%,%curval[42]%,%curval[43]%,%curval[44]%,usw....
%unit_on%%alwaysmetric_off%%alwaysseppoint_off%
Das hätte zumindest einen Vorteil: die merge.csv wird nach dem einlesen gelöscht, bzw. die Daten beim nächsten mal einfach überschrieben. Bei der Dateiüberwachung via newdata.csv wird nix gelöscht. Evtl. liegt ja hier der Fehler begründet, daß immer alte Daten aus der newdata.csv zum Senden herangezogen werden. Dagegen spricht allerdings, daß AWEKAS nicht betroffen ist. Insofern glaube ich da nicht so recht dran, daß sich an dem Problem etwas ändert.
Und ob man überhaupt Daten via merge einlesen kann, ohne grundsätzliche Dateiüberwachung, weß ich auch nicht.
In der 1. WSWIN-Instanz eine Datei merge.txt erstellen - und hier alle Sensoren eintragen. Diese merge.txt mit customfile an die 2. Instanz schicken und diese liest dann die Werte ein. Wie das genau geht habe ich mal im Forum beschrieben und steht auch irgendwo bei Werners Hilfedateien drin. Ist gar nicht so schlimm.
So eine merge.txt sieht ungefähr so aus:
%customfile=C:\WSWIN2\ws_merge.csv%
<!-- %openfile=nächste-datei.txt% -->
,,0,18,42,43,44,usw...
%unit_off%%alwaysmetric_on%%alwaysseppoint_on%%ws_date%,%ws_time%,%curval[0]%,%curval[18]%,%curval[42]%,%curval[43]%,%curval[44]%,usw....
%unit_on%%alwaysmetric_off%%alwaysseppoint_off%
Das hätte zumindest einen Vorteil: die merge.csv wird nach dem einlesen gelöscht, bzw. die Daten beim nächsten mal einfach überschrieben. Bei der Dateiüberwachung via newdata.csv wird nix gelöscht. Evtl. liegt ja hier der Fehler begründet, daß immer alte Daten aus der newdata.csv zum Senden herangezogen werden. Dagegen spricht allerdings, daß AWEKAS nicht betroffen ist. Insofern glaube ich da nicht so recht dran, daß sich an dem Problem etwas ändert.
Und ob man überhaupt Daten via merge einlesen kann, ohne grundsätzliche Dateiüberwachung, weß ich auch nicht.
- Tex
- Moderator
- Beiträge: 2007
- Registriert: 04 Aug 2014 17:47
- Wohnort: Woldegk
- Hat sich bedankt: 3 mal
- Danksagung erhalten: 45 mal
- Kontaktdaten:
@Wilfried
Vergiß erst mal den obigen Beitrag von mir. WSWIN sendet erst, nachdem die Daten eingelesen wurden. Was mir auffällt: AWEKAS wird per Direktlink gefüttert. Wettersektor via Template. Doch wie kommen dort veraltete Zeiten und Daten rein? Die Variablen, die in diesen Templates verwendet werden, sind immer die aktuellen Variablen, also z.B. %curval[0]%. Diese aktuellen Variablen sind allerdings abhängig von der Ansicht, die im WSWIN angezeigt bzw. eingestellt wird.
Beispiel: gehe ich händisch (während) des laufenden Betriebs 3 Tage zurück, wird der letzte sichtbare Wert der WSWIN-Anzeige in diesen Variabletyp übernommen, incl. Datums- und Zeitangabe.
Da man das ja nicht macht: könnte das evtl. von alleine unkontrolliert passieren????
Bevor Daten an AWEKAS gesendet werden, wird zwangsweise die Ansicht auf den aktuellen Tag umgestellt. Möglicherweise passiert das deshalb dort nicht. Wenn da ein Bug (wie auch immer sich in WSWIN breit gemacht hat???) - könnte man den evtl. vorrest umgehen, indem man im Sendebetrieb von www-templates eine Zeitverzögerung eingibt, die 1 Minute hinter dem Sendeintervall von AWEKAS liegt.
Mein Hintergedanke dabei: evtl. wurde die (interne) Ansicht dann noch nicht umgestellt - und so können in diese Templates die richtigen Daten geschrieben werden. --- Gleiches gilt dann auch für WU, hie auch eine Zeitverzögerung eingeben, die 1 Minute hinter AWEKAS liegt.
Vergiß erst mal den obigen Beitrag von mir. WSWIN sendet erst, nachdem die Daten eingelesen wurden. Was mir auffällt: AWEKAS wird per Direktlink gefüttert. Wettersektor via Template. Doch wie kommen dort veraltete Zeiten und Daten rein? Die Variablen, die in diesen Templates verwendet werden, sind immer die aktuellen Variablen, also z.B. %curval[0]%. Diese aktuellen Variablen sind allerdings abhängig von der Ansicht, die im WSWIN angezeigt bzw. eingestellt wird.
Beispiel: gehe ich händisch (während) des laufenden Betriebs 3 Tage zurück, wird der letzte sichtbare Wert der WSWIN-Anzeige in diesen Variabletyp übernommen, incl. Datums- und Zeitangabe.
Da man das ja nicht macht: könnte das evtl. von alleine unkontrolliert passieren????
Bevor Daten an AWEKAS gesendet werden, wird zwangsweise die Ansicht auf den aktuellen Tag umgestellt. Möglicherweise passiert das deshalb dort nicht. Wenn da ein Bug (wie auch immer sich in WSWIN breit gemacht hat???) - könnte man den evtl. vorrest umgehen, indem man im Sendebetrieb von www-templates eine Zeitverzögerung eingibt, die 1 Minute hinter dem Sendeintervall von AWEKAS liegt.
Mein Hintergedanke dabei: evtl. wurde die (interne) Ansicht dann noch nicht umgestellt - und so können in diese Templates die richtigen Daten geschrieben werden. --- Gleiches gilt dann auch für WU, hie auch eine Zeitverzögerung eingeben, die 1 Minute hinter AWEKAS liegt.
- moppedhausi
- Beiträge: 851
- Registriert: 01 Jan 2007 11:37
- Wohnort: Willich / Niederrhein
- Hat sich bedankt: 68 mal
- Danksagung erhalten: 5 mal
- Kontaktdaten:
- moppedhausi
- Beiträge: 851
- Registriert: 01 Jan 2007 11:37
- Wohnort: Willich / Niederrhein
- Hat sich bedankt: 68 mal
- Danksagung erhalten: 5 mal
- Kontaktdaten:
