HomeMatic-Forum / FHZ-Forum

Hallo PapaWolf,

ich stand auch schon vor dieser Entscheidung. Habe mich allerdings gegen IP-Symcon entschieden, da mir die Integration von Homematic in keinem Verhältnis zu den sonstigen Eigenschaften steht.
IPS ist sehr komplex und mächtig, benötigt aber für eine optimale HM-Integration trotzdem eine CCU.
Meine Entscheidung ist nun auf die Homematic in Verbindung mit der CUxD - Erweiterung und ebrixx als Konfigurations-Tool gefallen. Aus Performance-Gründen läuft ebrixx auf einem Plug-Computer.
Obwohl diese Komponenten erst in frühen Beta-Versionen vorliegen, kann man jetzt schon absehen, wie mächtig die Lösung letztlich sein wird.

-Heiko

So ich habe nun auf meinem Stick die Firmenware V3 aufgespielt und er wird im Status grün gezeigt.

CUxd-Uptime : 0 Tage 0 Stunden 18 Minuten 35 Sekunden 7928 bytes belegt Compiled Sep 23 2010 16:31:27

CUx-Version : V 1.39 CUL868 connected via /dev/ttyACM0

Erfolgreich mit HomeMatic-CCU 127.0.0.1:8181 verbunden

Erfolgreich als RPC-Server mit der CCU verbunden (5506) 127.0.0.1

Diese Web-Seite wurde aufgerufen von IP:0.0.0.0

Nun wollte ich mal eine meiner Reststeckdosen FS20 schalten. Doch nun stehe ich vor dem Nächsten Problem:
Es fehlt mir da an einer genaueren Beschreibung. Ich habe nun die Steckdose ein mal als Aktor 1 Kanal angelegt und auch als Relais Aktor 1Kanal. Doch ich bekomme beides nicht zum funktionieren.
In der HM kann ich im erstellten Gerät einen Switch|Code einstellen. Ich finde da nix mit einer "F" Nummer und alle Nummern die ich finde sind zu lang.
Ich habe auch versucht da die Nummer die auf der Steckdose unter dem Strichcode steht einzugeben, doch auch das bringt nix. Was muss denn da nun rein? Oder habe ich nur die Falsche FW Version auf dem Stick?

Hallo,

verbinde Dich mal auf die CUxD-Admin-Oberfläche (Port 8700). Dort kannst Du im Terminalfenster die Datagramme aller Geräte sehen, die Dein CUL unterstützt.
Jetzt einfach mal den Knopf an Deinem FS20 - Schalter drücken, und Du solltest ein Datagramm erkennen. In dem Datagramm ist immer die Geräteadresse enthalten.

viele Grüße
Heiko

Heiermann hat geschrieben:Hallo,

verbinde Dich mal auf die CUxD-Admin-Oberfläche (Port 8700). Dort kannst Du im Terminalfenster die Datagramme aller Geräte sehen, die Dein CUL unterstützt.
Jetzt einfach mal den Knopf an Deinem FS20 - Schalter drücken, und Du solltest ein Datagramm erkennen. In dem Datagramm ist immer die Geräteadresse enthalten.

viele Grüße
Heiko

Da ist es bei mir völlig ruhig (auch wenn ich Submit drücke)

Die Kernel-Log Messages sieht auch komisch aus. Da ist sicher noch irgend ein Wurm drin. (Ich betreibe aber kein Atomkraftwerk)

ice
<3>FAT: Directory bread(block 8198) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8199) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8192) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8193) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8194) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8195) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8196) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8197) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8198) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8199) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8192) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8193) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8194) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8195) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8196) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8197) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8198) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8199) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: FAT read failed (blocknr 7039)
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8192) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8193) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8194) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8195) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8196) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8197) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8198) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8199) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8192) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8193) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8194) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8195) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8196) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8197) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8198) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8199) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8192) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8193) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8194) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8195) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8196) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8197) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8198) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: Directory bread(block 8199) failed
<3>scsi 1:0:0:0: rejecting I/O to dead device
<3>FAT: FAT read failed (blocknr 7039)

Hallo,
stehe vor dem gleichen oder ähnlichen Problem. Über Windows und Hyperteminal lassen sich alle FS20 komponenten loggen.
Nur an der CCU im Cux-D Terminal werden keine Daten angezeigt.

Im Status-Fenster und im Terminal Kernel-Log wird angezeigt das alles richtig angeschlossen ist.

Meine Daten:
busware-stick
atmega32U4
FW: V3

Nebenbei noch zu erwähnen wäre das ich versucht habe mit der Cux-D Version 0.43 die ja eine Updatefunktion beinhaltet,
nach mehreren versuchen nur die meldung bekommen habe das "atmega32U4" nicht unterstützt wird.

Gruß Nils

Abdul79 hat geschrieben:Hallo,
stehe vor dem gleichen oder ähnlichen Problem. Über Windows und Hyperteminal lassen sich alle FS20 komponenten loggen.

Gruß Nils

Was für einen Treiber hast du da für Windows gefunden? (könntest du ihn mal packen und posten?) Den den ich gefunden habe zerstörte meine PC's (32 und 64 bit Windows7) doch funktionierte nie.

Mahlzeit,
nach dem flashen des Sticks, habe ich den Treiber "USB to serial" der sich im "culfw-1.39" archiv "docs" ordner befindet, installiert.

Abdul79 hat geschrieben:Mahlzeit,
nach dem flashen des Sticks, habe ich den Treiber "USB to serial" der sich im "culfw-1.39" archiv "docs" ordner befindet, installiert.

Daanke, den hatte ich übersehen ich probiere ihn mal aus