CUxD 0.562

[gerd.schelbert]

Hallo Gerd,

Bei der Anzeige auf der CCU zählen aber jede Menge Misses (300 bis 400 in 24h) hoch für die beiden Sensoren und die Aktualisierungszeit hinkt bisweilen massiv nach.

Die Aktualisierungszeit ändert sich nur bei Änderungen der Werte. Das macht die WebUI so.

Und das verursacht dann auch das Hochzählen des MISS-Counters?

Nein.

Bisher konnte ich das nur bei Zugriff auf die Webseite beobachten. Der Rahmen der Seite kommt immer noch, sobald die Inhalte angezeigt werden sollen (im weissen Innenfeld) ist Essig.
Ich benutze im übrigen den IE9 unter WIN7/64 SP1. Die URL ist immer die gleiche: http://IP-Adresse:8700/

Hmm... mit dem IE9 habe ich es noch nicht getestet. Kannst Du mal bitte testen, ob das gleiche Problem auch beim Firefox auftritt?
Nutzt jemand hier aus dem Forum den IE9 erfolgreich mit CUxD?

Welche Logfile-Settings bräuchtest Du denn für die Auswertung? Einen Syslog-Server habe ich bereits aufgesetzt.

Am besten Du setzt unter Setup den Parameter: LOGFILE=/tmp/cuxdlog.txt und zeichnest die Daten für einige Zeit auf.
Diese Datei kannst Du mir dann zusenden. Zum Schluss solltest Du das Logfile aber wieder deaktivieren, sonst ist irgendwann die RAM-Disk voll.

Viele Grüße,

Uwe.

Hallo, Uwe.

Mit dem Firefox nach wie vor keine Abstürze, scheint also tatsächlich eine IE9-Marote zu sein.

Danke für den Tipp mit den TF-2. Nach der Info von Dondaik bezüglich der Adressen habe ich sie per Trial and Error im CuX-Log gesucht und auch gefunden. Geräte im CuXd eingetragen, Geräte in der CCU konfiguriert und es lief.

Dabei sind jedoch 2 Themen aufgefallen:

1. Wenn man die Hex-Adressen in der CCU-Gerätekonfiguration klein schreibt geht gar nix. Nur bei Großschreibung funktioniert es.
2. Bei jeder Änderung des Status des FHT80-TF-Kontakts ändern sich beide Kanäle des CCU-Geräts, obwohl die Telegramme nur die Änderungen eines Kanals melden (also im letzten Byte von 01 auf 02 oder von 81 auf 82). Eine Unterscheidung der beiden TF-Adressen (intern, extern) ist so nicht möglich.

Die Miss-Rate der Thermosensoren ist seit Einsatz der WDE deutlich runtergegangen und liegt jetzt im Bereich <= 50 in 24h. Wer zählt die Misses eigentlich und wie werden sie ermittelt?
Bei jedem Empfang eines der Thermosensoren taucht im CuX-Log ein neuer Eintrag im WDE-Format "$1....." mit Werten von 2 Sensoren auf. Aber wo kommt die Info mit den Misses her?

Und noch einige Fragen:

Ich habe versucht, einen FS20-LS anzuhängen. Der ist per IRP so programmiert, dass er bei Tastendrücken jeweils "sofort aus" und "dimmen auf alten Wert" sendet.
Im Cux-Log tauchen die Telegramme auch wie erwartet auf.
Im CCU-Objekt lösen die Telegramme aber keine Änderungen aus. Hier habe ich das ganze als Gerätetyp 03 und 1-Kanal-Aufputz-Schaltaktor mit HC "1111 1111" und Adresse "1111" angelegt, was einen CCU-Code von "000000" ergibt.


Thema Homeputer CL Starter:
Ist es richtig. dass die Cuxd-Geräte nicht von der Contronics-Software ausgelesen werden?

Gibt es irgendwo eine Beschreibung der RPC-Schnittstelle des Cuxd?

Sorry für die vielen Fragen. Aber wenns halt nirgendwo richtig erklärt ist

Grüße

Gerd Schelbert

[uwe111]

Hallo Gerd,

Mit dem Firefox nach wie vor keine Abstürze, scheint also tatsächlich eine IE9-Marote zu sein.

Ja, das muss ich bei Gelegenheit mal untersuchen. Aber mit Firefox geht's ja erstmal.

1. Wenn man die Hex-Adressen in der CCU-Gerätekonfiguration klein schreibt geht gar nix. Nur bei Großschreibung funktioniert es.

Ja, der Code im CUxD ist intern ein String und keine Hex-Adresse. Und da der CUL die Empfangsdaten in Großschreibung liefert, muss die Adresse für den String-Vergleich im CUxD auch in Großschreibung definiert werden.

2. Bei jeder Änderung des Status des FHT80-TF-Kontakts ändern sich beide Kanäle des CCU-Geräts, obwohl die Telegramme nur die Änderungen eines Kanals melden (also im letzten Byte von 01 auf 02 oder von 81 auf 82). Eine Unterscheidung der beiden TF-Adressen (intern, extern) ist so nicht möglich.

Leider konnte ich die FHT80-TF Funktionalität noch nicht testen, weil ich bisher einfach noch keinen FHT80-TF hatte. Intern wird zwischen den beiden Kontakten unterschieden. Ich habe im Moment keine Ahnung, warum das nicht funktioniert.

Die Miss-Rate der Thermosensoren ist seit Einsatz der WDE deutlich runtergegangen und liegt jetzt im Bereich <= 50 in 24h. Wer zählt die Misses eigentlich und wie werden sie ermittelt?
Bei jedem Empfang eines der Thermosensoren taucht im CuX-Log ein neuer Eintrag im WDE-Format "$1....." mit Werten von 2 Sensoren auf. Aber wo kommt die Info mit den Misses her?

Die Anzahl der fehlenden Werte zähle ich im CUxD beim Empfang der Datensätze mit Hilfe des bekannten Sendeintervalls.
Leider liefert der USB-WDE1 nicht nur den empfangenen Sensor zurück, sondern immer alle empfangenen Sensoren.
Deshalb synchronisiere ich das Sendeintervall hier bei Datenänderungen bzw. mit den CUL-Empfangsdaten. Das machte das ganze bei der Implementation zwar etwas komplizierter, aber es scheint ganz gut zu funktionieren.

Ich habe versucht, einen FS20-LS anzuhängen. Der ist per IRP so programmiert, dass er bei Tastendrücken jeweils "sofort aus" und "dimmen auf alten Wert" sendet.
Im Cux-Log tauchen die Telegramme auch wie erwartet auf.
Im CCU-Objekt lösen die Telegramme aber keine Änderungen aus. Hier habe ich das ganze als Gerätetyp 03 und 1-Kanal-Aufputz-Schaltaktor mit HC "1111 1111" und Adresse "1111" angelegt, was einen CCU-Code von "000000" ergibt.

Wenn Du damit kein FS20-Gerät schaltest, dann nehme doch den FS20-Sensor. Ansonsten sollte es eigentlich funktionieren. Ich bin mir aber momentan nicht ganz sicher, ob die Adresse '000000' überhaupt funktioniert. Das müsste ich testen.

Ist es richtig. dass die Cuxd-Geräte nicht von der Contronics-Software ausgelesen werden?

Das ist wohl so.

Gibt es irgendwo eine Beschreibung der RPC-Schnittstelle des Cuxd?

Der CUxD nutzt BIN-RPC und das ist leider noch nicht dokumentiert.

Viele Grüße,

Uwe.

[DirtyFrank]

Mit dem Firefox nach wie vor keine Abstürze, scheint also tatsächlich eine IE9-Marote zu sein.

Ich verwende Windows 7 64-bit (manchmal) mit IE 9 (auch in der 64-bit-Variante) und habe keine Probleme. Hast Du die 32 bit-Version?

2. Bei jeder Änderung des Status des FHT80-TF-Kontakts ändern sich beide Kanäle des CCU-Geräts, obwohl die Telegramme nur die Änderungen eines Kanals melden (also im letzten Byte von 01 auf 02 oder von 81 auf 82). Eine Unterscheidung der beiden TF-Adressen (intern, extern) ist so nicht möglich.

Ich habe nur jeweils den internen ODER externen Kanal konfiguriert. Bei mir schaltet auch immer nur ein Kanal um (es wird auch jeweils die 01/81 bzw. 02/82 gesendet), daher habe ich den zweiten, nicht überwachten Kanal in der WebUI auf unsichtbar gestellt. Wenn im Terminal nur ein Kanal das Byte ändert, dürfte es in der WebUI auch nur bei einem Kanal eine Änderung geben. Ist das bei Dir anders?

Ich habe versucht, einen FS20-LS anzuhängen. Der ist per IRP so programmiert, dass er bei Tastendrücken jeweils "sofort aus" und "dimmen auf alten Wert" sendet.
Im Cux-Log tauchen die Telegramme auch wie erwartet auf.
Im CCU-Objekt lösen die Telegramme aber keine Änderungen aus. Hier habe ich das ganze als Gerätetyp 03 und 1-Kanal-Aufputz-Schaltaktor mit HC "1111 1111" und Adresse "1111" angelegt, was einen CCU-Code von "000000" ergibt.

Ich habe auch einen LS mini. Ich habe ihn als Sensor angelegt (bzw. für jeden Kanal je einen Sensor). Versuch mal, einen anderen Hauscode zu verwenden.

Ist es richtig. dass die Cuxd-Geräte nicht von der Contronics-Software ausgelesen werden?

Von IP-Symcon auch nicht, da der RPC-Server/Port des CUxD nicht von der Software unterstützt/angesprochen wird. Dies zu implementieren wäre (für den Programmierer) technisch kein Problem, ist aber (von demselben) nicht gewollt (evtl. auch wegen der durch den CUL nicht mehr gültigen Funkzulassung der CCU).

Viele Grüße,
Frank

[uwe111]

Hallo Gerd,

Im CCU-Objekt lösen die Telegramme aber keine Änderungen aus. Hier habe ich das ganze als Gerätetyp 03 und 1-Kanal-Aufputz-Schaltaktor mit HC "1111 1111" und Adresse "1111" angelegt, was einen CCU-Code von "000000" ergibt.

Bei mir funktioniert es auch mit '000000' problemlos. Sowohl FS20-Sensor als auch FS20-Aktor. Habe es gerade getestet.

Viele Grüße,

Uwe.