Homematic IP Geräte mit CUxD loggen

[uwe111]

Was spricht denn gegen den Weg über den .POSTIT Datenpunkt und ein HM-Script für alle zu loggenden Geräte/Datenpunkte?
So, wie ich es in der CUxD Doku beschrieben habe.

Wenn die Datenpunkte dann im CUxD DEVICELOG auftauchen, ist es tatsächlich nur noch ein CUxD-HighCharts Problem.

Für die CUxD-HighCharts Weiterentwicklung werden noch Freiwillige gesucht: https://github.com/homematic-community/CUxD-Highcharts

Viele Grüße

Uwe

[Baxxy]

Wenn die Datenpunkte dann im CUxD DEVICELOG auftauchen, ist es tatsächlich nur noch ein CUxD-HighCharts Problem.

So ist es. Irgendwo stand auch schon mal das Highcharts die Namen der geloggten IP-Geräte nicht anhand der Seriennummern ermitteln kann und deswegen nichts angezeigt wird.
Ich benutze seit ca. einem Jahr die Methode von fairtv und habe damit absolut keine Probleme.

Grüße
Baxxy

[alchy]

So, wie ich es in der CUxD Doku beschrieben habe.

Sicher?
Dein Script mit POSTIT würde logischerweise nur loggen, wenn der zusätzliche LOGIT Eintrag im Setup steht.
dann würde

Code: Alles auswählen

2020-02-14T14:53:05 00047119A24711:1.ACTUAL_TEMPERATURE 20.000000

geloggt.

Wenn man zu faul für so was ist, könnte man direkt LOGIT im Ansonsten unveränderten Script verwenden
Was auch

Code: Alles auswählen

2020-02-14T12:13:12 0815000EFO4570815:1.ACTUAL_TEMPERATURE 20.000000

loggt. Egal wie, beides sollte neuerdings zu "invalid date" führen.
Irgendetwas stört sich an den Punkten bei IP Geräten. Das war nicht immer so.

Das Problem mit invalid date (je nach Script) ist das Script.

Ein RF Sensor über Setup in CUxD den Eintrag erzeugt:

Code: Alles auswählen

2020-02-14T00:04:07 LEQ0004337:2.ACTUAL_TEMPERATURE 21.6

im Log, was dann in CUxD Highcharts Menü zu

Code: Alles auswählen

Thermostat EG Bad:1.TEMPERATURE

gewandelt wird.


LEQ0004337:2.ACTUAL_TEMPERATURE ist aber eigentlich nirgends korrekt.
Seriennummer:Kanalnummer.Datenpunkt


Nun würde ein IP Sensor (je nach Script) z.B.

Code: Alles auswählen

2020-02-14T00:13:05 HmIP-RF.000C98A99FCDF5:1.ACTUAL_TEMPERATURE 21.500000

im Log anlegen sofern z.b. der Datenpunktname direkt eingetragen wird.
HmIP-RF.000C98A99FCDF5:1.ACTUAL_TEMPERATURE
wäre dann zwar der korrekte Datenpunktname, aber den verträgt CUxD Chart nicht, damit ist dann auch das Datum invalid.
Da stören soweit ich mich erinnere auch die Punkte.

Also kann man mal spielen. Wandelt man das Script so um, das

Code: Alles auswählen

2020-02-14T18:14:30 000C98A99FCDF5:1_ACTUAL_TEMPERATURE 21.300000

Seriennummer Kanalnummer Datenpunkt
gespeichert wird, würde es funktionieren. Allerdings wandelt CUxD die Seriennummer bei IP nicht in ein Geräte bzw. Kanalnamen.
Also ist es cleverer den Kanalnamen oder Devicenamen zu verwenden.

Alchy

[uwe111]

So, wie ich es in der CUxD Doku beschrieben habe.

Sicher?

Ich hatte in meinem Beitrag nur gefragt, was dagegen spricht. Also wobei soll ich mir jetzt sicher sein?

Dein Script mit POSTIT würde logischerweise nur loggen, wenn der zusätzliche LOGIT Eintrag im Setup steht.

Natürlich, es sollte genau so, wie bei den alten HM Geräten per SUBSCRIBE-RF=1 funktionieren.

Wenn man zu faul für so was ist, könnte man direkt LOGIT im Ansonsten unveränderten Script verwenden

Könnte man, aber dann ist der Workflow innerhalb von CUxD ein anderer. Dann schreibt CUxD die Daten 'nur' in das Logfile. Mittels .POSTIT kann man sie genau so, wie die z.B. per SUBSCRIBE-RF=1 empfangenen HM Datenpunkte verarbeiten. Ich dachte, darum ging es.

Nun würde ein IP Sensor (je nach Script) z.B.

Code: Alles auswählen

2020-02-14T00:13:05 HmIP-RF.000C98A99FCDF5:1.ACTUAL_TEMPERATURE 21.500000

Ja, das Interface könnte man zusätzlich ausgeben. Bisher ist mir aber noch kein Fall bekannt, wo die Seriennnummer alleine nicht eindeutig ist. Ausserdem hattest Du ja selbst geschrieben, dass das aktuelle CUxD Highcharts das nicht verträgt.

Egal wie, beides sollte neuerdings zu "invalid date" führen.
Irgendetwas stört sich an den Punkten bei IP Geräten. Das war nicht immer so.

Das stimmt nicht! Die "invalid date" Meldung hatte ich ich auch schon früher auf meiner CCU1. Aktuell habe ich sie nicht. Dazu müsste einfach mal jemand CUxD-Highcharts überarbeiten. Mir fehlt dazu leider die Zeit.

Also ist es cleverer den Kanalnamen oder Devicenamen zu verwenden.

Das sehe ich nicht so. Da die logischen Kanalnamen in der CCU Logikschicht gespeichert und durch den Nutzer veränderbar sind, könnte man bei einer Änderung alle alten geloggten Daten dann nicht mehr eindeutig zuordnen. Bei der Seriennummer gibt es dieses Problem erstmal nicht. Sie bleibt bei jedem angelernten Gerät eindeutig.

Viele Grüße

Uwe

[alchy]

Also wobei soll ich mir jetzt sicher sein?

Ich wollte dir bestimmt nicht zu nahe treten.
Ich bin mir aber relativ sicher, das deine Anleitung zum invalid date führt. (so wie ich es beschrieben habe)
Vielleicht habe ich mich aber auch falsch ausgedrückt oder damals falsch getestet.

Das sehe ich nicht so. Da die logischen Kanalnamen in der CCU Logikschicht gespeichert und durch den Nutzer veränderbar sind, könnte man bei einer Änderung alle alten geloggten Daten dann nicht mehr eindeutig zuordnen. Bei der Seriennummer gibt es dieses Problem erstmal nicht. Sie bleibt bei jedem angelernten Gerät eindeutig.

Ich stimme dir ja zu. BEi den RF Geräten wird die Seriennummer geloggt aber der Name ausgegeben.
Wenn CUxD Highcharts die geloggten IP Seriennummern auch in die Namen wandeln würde wäre das perfekt.
Ich kann wenig mit 000C98A99FCDF5:1_ACTUAL_TEMPERATURE anfangen.

Alchy

[uwe111]

Ich bin mir aber relativ sicher, das deine Anleitung zum invalid date führt. (so wie ich es beschrieben habe)

Wenn das so ist, dann sollte dieses Problem aber in CUxD Highcharts korrigiert werden. Denn die von mir im DEVLOGFILE definierte Schreibweise ist folgende:
Seriennummer:Kanal.Datenpunkt Wert

Wenn CUxD Highcharts die geloggten IP Seriennummern auch in die Namen wandeln würde wäre das perfekt.

Genau so sehe ich das auch! Wenn dann noch der sporadisch auftretende "invalid Date" Fehler weg ist, wäre es wirklich perfekt.

Ich habe momentan leider nicht die Zeit, mich nebenbei auch noch mit CUxD Highcharts zu beschäftigen und würde es sehr begrüßen, wenn jemand das Projekt weiterführen würde: https://github.com/homematic-community/CUxD-Highcharts
Bis auf kleine Optimierungen, die ich vor 5 Jahren gemacht habe ist hier seit 7 Jahren nichts mehr passiert.
Dazu muss man auch kein Programmierexperte sein. Mit grundlegendem Programmierverständnis und viel Zeit sollte eigentlich jeder in der Lage sein sich in JavaScript einzuarbeiten. Bei den Schnittstellen-Scripts würde ich natürlich gerne unterstützend zur Verfügung stehen.

Viele Grüße

Uwe

[alchy]

Wenn das so ist, dann sollte dieses Problem aber in CUxD Highcharts korrigiert werden. Denn die von mir im DEVLOGFILE definierte Schreibweise ist folgende:
Seriennummer:Kanal.Datenpunkt Wert

Das ist so. Und wenn man den Fehler nicht nur umgehen will, sondern auch beseitigen, dann ja.
Zum Umgehen habe ich ja genug geschrieben oben.

Genau so sehe ich das auch! Wenn dann noch der sporadisch auftretende "invalid Date" Fehler weg ist, wäre es wirklich perfekt.

Den Grund hatte ich ja auch genannt.

Alchy

[grmpf]

Habe jetzt eure Diskussion in aller Ausführlichkeit gelesen. Verstanden habe ich, dass es am Ende in jedem Fall eine Highcharts-Thema ist. Aber ich hätte noch eine grundlegendere Frage;
Bei non-IP Devices hängt ja CuXD irgendwie im RF-Protokoll. Dass ist nach meinem Verständnis bei IPs nicht der Fall und hier liegt der Grund, warum man in der CCU für jeden zu loggenden Datenpunkt extra ein Skript schreiben muss. Gibt es denn Hoffnung, dass HMIP irgendwann mal von CuXD transparent zu HM-RF behandelt wird?

[uwe111]

Hallo Gert,

Gibt es denn Hoffnung, dass HMIP irgendwann mal von CuXD transparent zu HM-RF behandelt wird?

Da möchte ich mich jetzt nicht festlegen, da es sich um einen Haufen Arbeit handelt.

Das Problem dabei ist, dass CUxD momentan nur das BIN-RPC Protokoll versteht. Der neue HM-IP Server auf der CCU jedoch ausschließlich XML-RPC spricht.

Aus diesem Grund gibt es den Workaround über eine Programmverknüpfung und .POSTIT, wenn man HM-IP Datenpunkte innerhalb vom CUxD auswerten möchte.
Aber auch dann, wenn CUxD XML-RPC verstehen würde, wäre damit nicht das CUxD-Highcharts Problem gelöst, da die Datenpunkte in dem gleichen Format wie beim jetzigen Workaround geloggt werden würden.

Viele Grüße

Uwe

[grmpf]

Ja, genau so habe ich es verstanden.