CUxD 0.561

[JohannesN.]

Moin zusammen,

Meine suche zum Thema ergab einen Treffer, doch soweit komme ich leider nicht...

Meine FS20 KSE wird nicht im Terminal angezeigt, nachdem auslösen der Klingel blinkt die LED viermal.
Sie wird nur mit der Klingelspannung betrieben. Wird die Klingel dauerhaft gedrückt blinkt die LED mehrmals.
Auch das verzögerte aussenden der Signale bringt mir kein Eintrag im Terminal.

KSE defekt? Oder muss ich vorher noch was beachten?

MfG

[flo77]

Hallo zusammen,

erst mal vielen Dank an Uwe für die großartige Arbeit rund um den CUxD, ich "spiele" mangels Zeit seit einem halben Jahr nur sehr gelegentlich mit der CCU rum, habe aber gleich die CUxD Erweiterung vorgenommen, und bin eigentlich total begeistert. Nun wollte ich mich dem ganzen Thema Homematic incl. CUxD etwas mehr widmen, habe nun auch festgestellt, dass es ein Firmware-Update für die CCU gab (1.504, hatte vormals die 1.503 drauf) und ebenfalls ein CUxD update (in meinem Fall von der 0.559 auf die 0.561a. (würde gerne das Wrapper-Device ausprobieren)
Leider steigt seit dem der CUxD wie bei Stefan recht häufig aber unregelmäßig aus - wegen der mehrfachen Änderung kann ich nun nicht mehr nachvollziehen, ob es an der CCU-Firmware, oder an dem CUxD-Update liegt. ich habe nun schonmal testweise alle CUxD-Devices getötet und neu angelegt, hat aber zunächst mal nichts gebracht. Werde nun mal testen, was passiert, wenn ich jeweils nur ein Greät nach dem anderen hinzufüge, und jeweils einige Stunden vergehen lasse - (lief nun nie länger als 20 Minuten. Zusätzlich hatte ich noch ein Heizkörperventil mit aufgenommen gehabt, bislang aber nur das Wandthermostat dringehabt, evtl. ist ja auch das irgendwie der Auslöser? ) Mit der alten Version auch schon 100 Tage ohne Probleme. Gibts da evtl noch Ideen dazu?
Eine weitere Frage hätte ich noch: Kann man problemlos mehrere CUL-Devices an der CCu betreiben? Ich würde gerne eines davon mit ner USB-Verlängerung abgesetzt in den Keller zu den EM1000-Sendern Setzuen, da ich schon recht viele Pakete von dort unten bis in das 2.OG verliere.
Vielen Dank!

Gruß,
Florian

[uwe111]

Hallo Florian,

Leider steigt seit dem der CUxD wie bei Stefan recht häufig aber unregelmäßig aus - wegen der mehrfachen Änderung kann ich nun nicht mehr nachvollziehen, ob es an der CCU-Firmware, oder an dem CUxD-Update liegt.

Wenn Du auch LOVF-Fehler hast, dann kann es helfen die FHT80b-Thermostate komplett vom CUL abzulernen. Danach einige Zeit warten und dann nach und nach die FHT80b wieder mit dem CUL pairen. Das hatte jedenfalls bei Stefan geholfen.

Eine weitere Frage hätte ich noch: Kann man problemlos mehrere CUL-Devices an der CCu betreiben? Ich würde gerne eines davon mit ner USB-Verlängerung abgesetzt in den Keller zu den EM1000-Sendern Setzuen, da ich schon recht viele Pakete von dort unten bis in das 2.OG verliere.

Ich weiß zwar nicht, ob das schon jemand nutzt, aber unterstützt werden vom CUxD auch mehrere CULs. Für die Zuordnung dient der DEVICE-Parameter.

Viele Grüße,

Uwe.

[ColleLupi]

Hallo Florian,
das ist 100 pro mein durchlebter Fehler.
1. Schau nach Neustart des Cuxd über CCU-Einstellungen-System..-Zusatzprogramme-Cuxd neustarten nach ca . 30min in das Terminalfenster(Cuxd).
Sollten dort noch LOVF's auftauchen, melde die Geräte, die vor der LOVF-Anzeige auftauchen ab. Meist sind das FHT80-Thermostate. Oder rigide alle FHT80 raus.

2. CCU + Cuxd N e u starten. Dann schauen ob kein einziges LOVF im Terminal auftaucht. Läuft Cuxd jetzt rund, ein FHT80 nach dem anderen neu anlernen auch mit Cert-Einstellung vom Thermostat aus.

3. Nach wenigen Minuten müßte ohne LOVF-Anzeigen alles laufen. Selbst die CCU wird schneller (ein wenig...). Sollten jetzt noch diese LOVF's kommen kann es auch noch
a. zu langes USB-Kabel zum Cuxd
b. zu wenig Reichweite der Funkverbindung liegen.

Ich habe übrigens immer noch die 1.503 drauf, da bis heute mir keiner so richtig bei meinem Problem mit den HMW_IO-12-SW14 Multimodulen helfen konnte. Zwei Schreiben an den Hersteller...gibts den überhaupt als Person oder als Schreiber? sind leider nicht beantwortet.

Mit der neusten Software von Uwe(0.561a) und 1.503 auf der CCU läuft der Cuxd + alles andere bei mir das erstemal seit einer Woche durch.
Grüsse
Stefan

[flo77]

Hallo Uwe, Hallo Stefan

Vielen Dank für deine schnelle Antwort. Ich habe gestern alle CUxD Devices bis auf meine drei EM1000WZ- Sensoren abgelernt, und habe nun mit der 0.561 meinen persönlichen Report aufgestellt, da schon seit gestern Abend ohne Absturz. ( mit dem FHT nie über 20 Minuten).
Die LOVF-Mldungen habe ich noch nie gesehen, habe allerdings i.d.R. Auch keineen Zugriff mehr auf die Terminalseite, weil dort bekomme ich dann ja nur noch den 500 Internal Server error.
Aber da die Abstürze bisher immer so schnell passierten ist naturlich die Reproduzierbarkeit Super, und ich kann das nachher gleich nochmal testen.
Ich hatte aber mit den Abstürzen auch nur ein FHT angelert, zählen da die Kommunikationen, die tatsächlich übergeben werden, oder alles was das CUL sieht? Im Terminal sehe ich natürlich auch die anderen Kommunikationen, von einem weiteren FHT, sowie diversen Schaltern und weiteren EM 1000 Komponenten.
Ich werde im Anschluss ein FHT wieder anlernen, und dann mal sehen.

Wegen der zwei CULs:
Das wäre natürlich großartig, das mit der device-kennzeichnungnist mir schon aufgefallen - dann ignoriert das jeweils "falsche" CUL also die Meldungen einfach, und es kommt nicht zu doppelempfängen?
Und beim Senden wird dann sowieso eines konkret adressiert, vermute ich.
Klingt genial! Werde da vor dieser Aussicht noch dieses Jahr ein weiteres CUL organisieren - stehe dann auch gerne für Rückmeldungen zur Verfügung!

Vielen Dank nochmal,

Viele Grüße,
Florian

[uwe111]

Hallo Florian,

Ich hatte aber mit den Abstürzen auch nur ein FHT angelert, zählen da die Kommunikationen, die tatsächlich übergeben werden, oder alles was das CUL sieht?

Die culfw kommuniziert m. E. aufgrund des etwas komplizierten Protokolls mit allen empfangenen FHTs, unabhängig von deren Konfiguration im CUxD. Diese Kommunikation wird normalerweise auch nicht im CUxD-Terminal angezeigt. Aber das betrifft nur das Problem mit den LOVF-Meldungen.

Wegen der zwei CULs:
Das wäre natürlich großartig, das mit der device-kennzeichnungnist mir schon aufgefallen - dann ignoriert das jeweils "falsche" CUL also die Meldungen einfach, und es kommt nicht zu doppelempfängen?
Und beim Senden wird dann sowieso eines konkret adressiert, vermute ich.

Mit dem DEVICE-Parameter definiert man, mit welchem CUL das CUxD-Gerät kommunizieren soll. Das gilt für's Senden und Empfangen. Ist der Parameter leer (default), so wird immer der erste gefundene CUL genutzt. Eine Ausnahme bilden die Temperatursensoren. Hier erfolgt der Empfang von allen CULs mit automatischer Doublettenerkennung.

Viele Grüße,

Uwe.

[flo77]

Hallo, Uwe,

Abe nun eben das eine FHT wieder angelernt, das andere Batteriefrei gemacht.
Nun ist der CUxD binnen Kürzester Zeit wieder abgetaucht. Ich habe allerdings das Anlernen nun nur über den CUxD vorgenommen, Sprich neues Gerät, Code rein, und gut, oder habe ich da noch was übersehen?
..Und dann natürlich noch IN der CCU-GUI konfiguriert.

Code: Alles auswählen

[ttyACM0] 11:02:43 <-- X01
[ttyACM0] 11:02:43 <-- T01
[ttyACM0] 11:02:43 --> V 1.44 CUL868
[ttyACM0] 11:02:43 --> 0101
[ttyACM0] 11:02:44 <-- T010266FF
[ttyACM0] 11:04:02 --> E01024988A01200A600
[ttyACM0] 11:04:31 --> T010200A600
[ttyACM0] 11:04:32 --> E0103487D400600D201
[ttyACM0] 11:04:32 --> T01026669FF
[ttyACM0] 11:06:14 --> E01014CD08A0C00D000
[ttyACM0] 11:06:27 --> T010200A600
[ttyACM0] 11:06:36 --> E020835E9B001000100
[ttyACM0] 11:07:16 --> F05AF0012
[ttyACM0] 11:07:17 --> F05AF5512
[ttyACM0] 11:07:18 --> F05AF0312
[ttyACM0] 11:07:20 --> F05AF0312
[ttyACM0] 11:07:21 --> F05AF0212
[ttyACM0] 11:07:40 --> F05AF0412
[ttyACM0] 11:08:23 --> T010200A600
[ttyACM0] 11:08:23 --> T0102826929
[ttyACM0] 11:08:24 --> T010284691C
[ttyACM0] 11:08:24 --> T01028A6918
[ttyACM0] 11:08:25 --> T0102856904
[ttyACM0] 11:09:02 --> E01024A97A00F00A600
[ttyACM0] 11:09:32 --> E01034983400600D401

Noch Ideen?

Vielen Dank und viele Grüße,
Florian

[gerd.schelbert]

Hallo.

Ich starte gerade mit der CCU/Cuxd-Implementierung, nachdem ich seit einigen Jahren ein FHZ1300-System mit der Studio-Software nutze. Ich hatte mir ein stabileres System ohne Windowsunterbau erhofft. Der cuxd war der endgültige Auslöser für den Einstieg in die CCU.

Ich habe die aktuelle cuxd-Version installiert und die ersten beiden Thermofühler sowie einen Sensor und einen Aktor am Laufen.

Ein erster FHZ80 wehrt sich noch gegen seine Einbindung, er will einfach nicht syncen. Der Hauscode ist laut Log sowohl auf dem cul als auch auf dem Raumthermostat korrekt eingestellt. Aber der Status bleibt trotzig auf nA.

Der Cuxd hat sich leider bei den Versuchen mehrfach verabschiedet (Webseite nicht mehr erreichbar). Nach Restart des cuxd lief es dann wieder. Das passierte bis jetzt ausnahmslos nach Öffnen der Cuxd-Webseite und Wechsel auf die Infoseite.

Hat jemand eine Idee zu den beiden Problemen?

Einige Fragen drängen sich mir noch auf:

Gibt es irgendwo eine Beschreibung der Datagramme im cuxd-Log? Einzelteile habe ich schon gefunden, aber eine konsolidierte Fassung wäre sehr hilfreich.

Aktuell würde mich Interessieren, welche Datagramme mit einem kleinen t beginnen und wie sie zu lesen sind.

Wie viel Aufwand wäre es, in dem Log neben der Rohausgabe des cux-Outputs auch teildekodierte Datagramme mit konvertierter FS20-Notation (HHHH AA AA) auszugeben? Das würde den Umsteigern aus dem FS20-Lager deutlich helfen.

Warum gibt es eigentlich Im cuxd keine Mehrkanal-Sensoren und -Aktoren? In der CCU-Welt gibt es die doch.

Wo sind denn die Quellcodes der aktuellen Cuxd-Version? In der google-Group sind nur die Altversionen.

Grüße

Gerd

[dondaik]

habe gestern auch einen fht80 zum ersten test an die ccu angemeldet .. aber lange mit dem hauscode getüftelt .... stelle mal deinen ein, das ist eigentlich der einzige fallstrich den ich im moment sehe...
ccu daemon liefen beide im browser und haben sich trotz 1000fachen wechsel nicht verabschiedet. habe auch keinen reset per sw gefahren, einzig lange auf den ersten fhz kontakt gewartet :-) ACHTUNG: die fhz MUß aus sein oder der FHT80 abgemeldet.

[gerd.schelbert]

Code: Alles auswählen

Ich hatte den Hauscode der FHT80 geändert, um eine Querbeeinflussung durch die FHZ1300 zu vermeiden. Der neue Hauscode tauchte auch wie erwartet in Hex umgesetzt im Log auf. Den habe ich dann in das CCU-Objekt übernommen.
am FHT80 dann Prog - Cent - nA eingestellt und mit Prog abgeschickt. Aber nix synct.

Die CUL hat als Hauscode mit T01HHHH einen eigenen Hauscode bekommen, wobei die ersten beiden H's die gleichen wie beim FHT sind, die beiden letzten sind unterschiedlich.

Und noch eine Letzte:

Nach der Installation des cuxd habe ich keine Kachel für den cuxd in der CCU-WebUI.Kann man das beheben?

Gruß

Gerd