Nach den Feiertagen, hier zunächst der noch ausstehende, ausfühliche Statusbericht des bisherigen Standes. Bevor ich mich um die Einbindung der 14er-Aktoren in CUxD gekümmert habe, hatte ich als Grundlage erstmal den Eltako-Bus sauber durchadressiert. Hier lag noch einiges im Argen, so dass dies erstmal die Basis für das weitere Vorgehen war. Inzwischen läuft der Eltako-Bus (fast) "sauber". "Fast" deshalb, weil sich ein einziger Aktor nicht beschreiben lässt, sobald der Abschlusswiderstand auf dem letzten Aktor ordnungsgemäß aufgesteckt ist. Sobald der Abschlusswiderstand entfernt wird, läuft alles bestens. Im Betrieb habe ich den Abschlusswiderstand allerdings stets aufgesteckt. Das Problem habe ich beim Eltako-Support gemeldet, aber eine Rückmeldung dazu ist erst im neuen Jahr zu erwarten.
Zunächst das grundlegend Positive: Alle 14er-Aktoren konnte ich in CUxD anlegen, in die Homematic übernehmen und lassen sich einwandfrei bedienen.
Momentan hänge ich etwas an der Zuverlässigkeit betreffend der Rückmeldungen der Aktoren. Als BiDi-Code habe ich in allen Kanälen die dezimale Adresse des Kanals im Eltako-Bus gefolgt von einem "." eingetragen und gespeichert. CUxD wandelt den dezimalen Code automatisch in einen hexadezimalen Code um (was natürlich bei den ersten Adressen erstmal gar nicht auffällt). Sehr wichtig für die Rückmeldungen ist dann ja noch der obere BA-Drehschalter des FAM14. Hierzu kommen nur folgende Positionen in Frage:
Pos. 2: zyklische Abfrage von Bestätigungstelegrammen nach Scan-Liste (mit Versand in den Gebäudefunk)
Pos. 3: zyklische Abfrage von Bestätigungstelegrammen nach Scan-Liste (ohne Versand in den Gebäudefunk)
Pos. 4: zyklische Abfrage von Bestätigungs- und Statustelegrammen nach Scan-Liste (ohne Versand in den Gebäudefunk)
Pos. 5: zyklische Abfrage von Bestätigungstelegrammen nach mit PCT14 eingetragener Geräteliste im FAM14 (mit Versand in den Gebäudefunk)
Pos. 6: zyklische Abfrage von Bestätigungstelegrammen nach mit PCT14 eingetragener Geräteliste im FAM14 (ohne Versand in den Gebäudefunk)
Pos. 7: zyklische Abfrage von Bestätigungs- und Statustelegrammen nach mit PCT14 eingetragener Geräteliste im FAM14 (ohne Versand in den Gebäudefunk)
Mit PCT14 habe ich im FAM14 alle Aktoren in die Geräteliste eingetragen. Demnach sollte es keine Rolle spielen, ob ich die Pos. 2-4 oder 5-7 wähle. Rückmeldungen in den Gebäudefunk benötige ich (bisher) nicht, da das FGW14-USB mit der Raspberrymatic verkabelt ist und ich bisher noch keine EnOcean- Sensoren oder Aktoren einsetze. Der Unterschied zwischen Bestätigungs- und Statustelegrammen ist mir bisher allerdings nicht klar. Meinem Verständnis nach, könnte es sein, dass die Aktoren Bestätigungstelegramme einmalig nach der Änderung ihres Status versenden, während sie Statustelegramme zyklisch versenden. Den oberen BA-Drehschalter des FAM14 habe ich deshalb in Pos. 4. Da ich nicht weiß, ob es hier einen Zusammenhang mit dem Haken der "Zyklischen Statusmeldung" des jeweiligen Aktors gibt, habe ich für alle Aktoren die "Zyklische Statusmeldung" aktiviert, was meinem Verständnis nach hoffentlich keine Probleme verursachen sollte. Hierzu bitte ich jedoch unbedingt um Rückmeldung, ob das so ok ist!
Im CUxD-Statusfenster sieht man, dass der Status alle Aktoren zyklisch aktualsiert wird. Hinter dem hexadezimalen BiDi-Code steht immer ":1s" bis ":5s", woraus sich für mich schließen lässt, dass alle Aktoren zyklisch im Abstand von ca. 1-5 Sekunden abgefragt werden. AUSNAHME sind die FSB14 Aktoren, die offenbar nicht zyklisch abgefragt werden, sondern deren Status sich nur bei einer Bedienung des jeweiligen Aktors ändert, siehe unterer Auszug aus dem CUxD-Statusfenster. Eine Servicemeldung über einen nicht erreichbaren Aktor habe ich, entgegen der CUxD-Anleitung, auch nach über 60 Minuten noch nicht bekommen. Im Wesentlichen habe ich das Problem, dass die Status-LED am Bustaster eingeschaltet bleibt, wenn der Rollo nur über Homematic bedient wird. Auch wenn der Rollo vollständig herab und anschließend vollständig herauf gefahren wird bleibt die Status-LED am Bustaster dauerhaft eingeschaltet. Bei Hoch- und Runterfahren mit dem Bustaster selbst, funktioniert die Status-LED korrekt. Es scheint also so, als bekäme sie bei Steuerung über Homematic nur mit, wenn der Rollo heruntergefahren wird, nicht aber wenn er (vollständig) hochgefahren wird.
CUX3600001: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(0:00000002:4s) id2(1:00000003:4s) id3(2:00000004:4s) id4(3:00000005:4s)
CUX3600002: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(4:00000006:4s) id2(5:00000007:4s) id3(6:00000008:4s) id4(7:00000009:3s)
CUX3600003: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(13:0000000F:3s) id2(14:00000010:3s) id3(15:00000011:3s) id4(16:00000012:3s)
CUX3600004: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(17:00000013:3s) id2(18:00000014:3s) id3(19:00000015:3s) id4(20:00000016:3s)
CUX3600005: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(21:00000017:3s) id2(22:00000018:3s) id3(23:00000019:3s) id4(24:0000001A:3s)
CUX3600006: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(25:0000001B:2s) id2(26:0000001C:2s) id3(27:0000001D:2s) id4(28:0000001E:2s)
CUX3600007: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(32:00000022:2s) id2(33:00000023:2s) id3(34:00000024:2s) id4(35:00000025:2s)
CUX3600008: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(36:00000026:2s) id2(37:00000027:2s) id3(38:00000028:2s) id4(39:00000029:2s)
CUX3600009: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(40:0000002A:2s) id2(41:0000002B:2s) id3(42:0000002C:1s) id4(43:0000002D:1s)
CUX3600010: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(52:00000036:1s) id2(53:00000037:1s) id3(54:00000038:1s) id4(55:00000039:1s)
CUX3600011: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(56:0000003A:1s) id2(57:0000003B:1s) id3(58:0000003C:1s) id4(59:0000003D:0s)
CUX3600012: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(60:0000003E:0s) id2(61:0000003F:0s) id3(62:00000040:0s) id4(63:00000041:0s)
CUX3600013: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(64:00000042:0s) id2(65:00000043:0s) id3(66:00000044:0s) id4(67:00000045:0s)
CUX3600014: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(68:00000046:0s) id2(69:00000047:0s) id3(70:00000048:0s) id4(71:00000049:0s)
CUX3600015: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(72:0000004A:4s) id2(73:0000004B:4s) id3(74:0000004C:4s) id4(75:0000004D:4s)
CUX3601001: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(8:0000000A:3s)
CUX3601002: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(29:0000001F:2s)
CUX3601003: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(44:0000002E:1s)
CUX3601004: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(45:0000002F:1s)
CUX3601005: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(46:00000030:1s)
CUX3601006: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(47:00000031:1s)
CUX3602001: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(9:0000000B:1h) id2(10:0000000C:1h)
CUX3602002: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(11:0000000D:1h) id2(12:0000000E:1h)
CUX3602003: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(30:00000020:1h) id2(31:00000021:1h)
CUX3602004: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(48:00000032:1h) id2(49:00000033:1h)
CUX3602005: dev('ttyUSB0') baseid('0001C680') CHECK 4BS-ELTAKO id1(50:00000034:1h) id2(51:00000035:1h)