Das Wetterstationen Forum

Nachdem, glaube Anfang 2023, die CustomLogs eingeführt wurden, war es super einfach sich mit den entsprechenden Tags nur die Daten aus den Log- und ExtraLog-Dateien in einer speziellen CustomLog-Datei zusammen stellen welche man auch wirklich für den Import nach WsWin benötigt.

Diese dann anschließend über externe Programme per Xcopy eine xyz.csv Datei umkopieren, welche WsWin dann per X-CSV importieren kann.

Soweit so gut, nun aber eher schlecht:
Anscheinend haben die Macher von CMX irgendwann als Trenner für die Tags in der CustomLog nur das Komma eingeführt, was ein absoluter Blödsinn ist, wenn man vorliegende Werte schon im Dezimalformat mit "," vorliegen hat.

Ich hatte mir gedacht, na, versuchste mal CMX auszutricksen und habe wie bisher ein ";" als Trenner verwendet, was auch für die Daten an sich funktioniert. Diese werden schön mit ";" aneinander gereiht. Leider werden aber Datum und Zeit von CMX automatisch vorangestellt, mit "," als Trenner.

Na suuuuper....

Wer denkt sich bitte schön denn so einen Mist aus, wenn man beim Zusammenstellen der Tags diese sogar mit der Option "rc=y" versehen könnte, um Dezimal-Punkte in den Daten gleich noch mit in ein Komma umwandeln könnte.

Damit ist nun ist eine sinnvolle Verwertung einer CSV komplett unmöglich geworden, da Tag-Trenner und Dezimalzeichen identisch sind.

Hier ein Auszug aus den Hinweisen zur Erstellung des CustomLog:

"For example you could use the string: <#temp><#hum><#SoilTemp1>
You can also use modifiers in the webtags for further control of the output like this: <#temp rc=y><#hum><#SoilTemp1 dp=2 rc=y>
You MUST use the rc=y web tag parameter for numeric values if your locale uses a comma decimal

Note: It is important to use a comma "," as the field separator as CMX will only recognise this format."

Herr laß Hirn wachsen...

Somit ist nun CMX in der 4. Generation für mich unbrauchbar geworden.
Vielleicht sollte oder muss ich einfach wieder auf die V3.23.1 Variante downgraden, dann sollte es wieder laufen.

Ich fasse es einfach nicht...

Gesagt getan und schon fluppt die Sache.

Hi!

Aber vielleicht gibst Du dem Entwickler durch einen Hinweis die Möglichkeit, diesen Missstand zu beheben.

Oliver

Danke dir für den Hinweis.
Auf welchem Wege macht man das am besten?

indem Du den Missstand, so wie Du ihn wahrnimmst (auf Englisch) beschreibst.
Zeigst was ging.
Zeigst war nicht mehr geht.
Dass die "Komma-Geschichte" für eine Locale DE so nicht mehr richtig funktioniert.
Am besten mit Beispielen.
Und dann im Cumulus Forum posten.
Topic (z.B.) - Custom Logs in CMX version 4 no longer working properly as before
https://cumulus.hosiene.co.uk/viewforum.php?f=50 (das ist das CMX Forum für CMX Version 4)
ggf. kostenlos anmelden, um posten zu klönnen.

Danke dir, habe es dort platziert.
Schönen Sonntag!

Ich habe Marks (zugegebenermassen etwas lapidar klingende) Antwort gelesen und stelle mir jetzt die Frage, ob sich das "alte" = gewünschte Format nicht trotzdem durch entsprechen Einsatz von rc=y (das ja pro WebTag vergeben wird) etc. produzieren lässt. Habe im Moment nicht die Zeit, mir das im Detail anzuschauen, aber im ersten Ansatz denke ich, dass man Datum und Uhrzeit im Format DD.MM.YYYYY oder DD.MM.YY hh:mm erzeugen kann und die Sensorwerte entweder auch mit Punkt oder eben Komma als Dezimal-Trennzeichen produzieren können sollte.

Ich benutze selbst noch Version 3 Installationen mit deutscher und britischer Locale - die deutsche eben mit Komma als Dezimaltrenner und Semikolon als Werte-Trenner.

Bevor ich das allerdings nicht selbst ausprobiert habe, möchte ich mich nicht mit Mark "anlegen" und ggf. auf eine Komma-Semikolon Möglichkeit drängen. Bislang musste das Trennzeichen zwischen den WebTags auch dem Trennzeichen bei CMX entsprechen. Wenn nun tatsächlich alles (die normalen Datenlogs) nur noch Punkt-Komma ist, würde ich auf eine Komma-Semikolon Option für die CMX-Nutzer im DACH-Raum drängen. Aber, wie gesagt, da muss ich selbst erst einmal selbst den Einblick verschaffen, eine 4.x Version installieren und mit den Custom-Logs experimentieren. Und dann sehen, was sich machen lässt.
Im Extremfall, falls es auf Marks Seite kein benötigtes Einlenken gibt, müsste man ein kleines Konvertierungsutility schreiben, das man dazwischen schaltet. Eine Komma-Semikolon-Option in CMX wäre natürlich handlicher.

So, Antwort ist da: https://cumulus.hosiene.co.uk/viewtopic ... 01#p185801

Scheint wohl niemand zu jucken, ist wohl defintiv festgeschrieben bis auf Weiteres, wenn ich das so recht verstehe.

Gruß Lutz

EDIT: Hallo Gyvate, sorry, hatte deine Antwort dazu noch gar nicht gesehen.

So denn Antworte ich hier noch mal dazu etwas ausführlicher.
Ich fand es auch etwas kurz angebunden, weiß gar nicht ob er so recht das Problem überhaupt verstanden hat.

Soweit ich es verstanden habe ist das rc=y dazu da, Punkt-Dezimale in Komma-Dezimale umzuändern.
D.h. wenn ich aber schon Komma-Dezimale habe, kann man damit gar nichts anfangen.

Um das Problem zu umgehen könnte man ja auch die gesamte Funktionalität dahin gehend ändern, daß man nur die Klammertags ohne Trenner aneinander reiht, aber eine Auswahlmöglichkeit anbietet, ob man , oder ; als Trenner haben möchte. Wegen mir als Default das Komma, aber eine Auswahl des ; sollte möglich sein.

Dies müsste dann allerdings auch auf das Voranstellen von Date und Time seitens CMX ebenso wirken.
Hier könnte man aber das programmseitige Voranstellen einfach canceln und der User fügt diese entsprechend ein.

Für die Erkennung der Abgrenzung von einem Tag zum nächsten wäre ja die sich dann ergebende Zeichenfolge >< gewiss kein Problem, oder man macht einfach Leerzeichen zwischen die Tags.

Ich denke, es ist halt nun mal leider eine wohl eher nachrangig benutzte Routine, so dass man da nun keine Energie reinstecken will/kann.

Soweit meins dazu.
Gruß Lutz

Hallöle, mir ist noch was dazu:

Gyvate hat geschrieben: 10 Nov 2024, 20:26 [...]
Im Extremfall, falls es auf Marks Seite kein benötigtes Einlenken gibt, müsste man ein kleines Konvertierungsutility schreiben, das man dazwischen schaltet. Eine Komma-Semikolon-Option in CMX wäre natürlich handlicher.

eingefallen.

Bei mir ist es ja so, dass die Daten in den Log und ExtraLogs mit Komma-Dezimale abgelegt sind. Es schaut für mich jedenfalls danach aus. Es kann aber auch sein, dass CMX die empfangenen Daten in Wirklichkeit mit Punkt-Dezimalen in den Logs hat und wandelt sie dann entsprechend der Locale im Custom-Log wieder um?

Fragen über Fragen...

Gruß Lutz

Nachtrag: Habe gerade mal nachgesehen, im Log als auch ExtraLog liegen die Daten in einer CSV-Struktur mit Semikolon (Trenner) und Dezimal-Komma.