Eltako FAM14 + 5x FUD14 schalten bei Einzelbetätigung alle gleichzeitig

Begonnen von bajuware, 11 November 2018, 14:49:16

Vorheriges Thema - Nächstes Thema

bajuware

Hallo Miteinander,

ich habe folgendes Hardware Setup: 1x FAM14 + 5x FUD14
In FHEM angelegt und eingelernt:
EnO_sensor_00000001
EnO_sensor_00000002
EnO_sensor_00000003
EnO_sensor_00000004
EnO_sensor_00000005

Im Prinzip bin ich danach vorgegangen und habe beschriebene Attribute angelegt:
https://wiki.fhem.de/wiki/EnOcean-FUD14-RS485-Bus-Universal-Dimmaktor

Nun habe ich allerdings folgendes Phänomen, dass ich, egal welchen Dimmer ich in FHEM individuell an oder aus schalte, alle Dimmer gleichzeitig an bzw aus gehen.

Weiß jemand woran das liegt?

Grüße


hexenmeister

Ohne deine Konfiguration zu sehen kann ich nur raten. Die Glaskugel ist leider zurzeit nicht einsatzbereit  ;D

Es könnte sein, dass in der Konfiguration 5 mal die selbe id steht, oder auch, dass in FAM14 fünf ids gleichzeitig an alle Dimmer gleichzeitig angelernt sind. Das kannst du mit PCT14 überprüfen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

Hallo Hexenmeister,

das mit der Konfig aus FAM14 und PCT14 kann ich leider erst Ende der Woche posten, da ich vorhin den USB-Port an der FAM14 geschrottet habe. Im Anhang aber Screenshots von der letzten Verbindung.
Was FHEM angeht, da habe ich im Prinzip so angelegt:

define EnO_sensor_00000001 EnOcean 00000001
attr EnO_sensor_00000001 gwCmd dimming
attr EnO_sensor_00000001 subType gateway
attr EnO_sensor_00000001 subDef 01000001
attr EnO_sensor_00000001 manufID 00D
attr EnO_sensor_00000003 model Eltako_TF         
attr EnO_sensor_00000003 webCmd on:off:dim

define EnO_sensor_00000002 EnOcean 00000002
attr EnO_sensor_00000002 gwCmd dimming
attr EnO_sensor_00000002 subType gateway
attr EnO_sensor_00000002 subDef 01000003
attr EnO_sensor_00000002 manufID 00D
attr EnO_sensor_00000002 model Eltako_TF           
attr EnO_sensor_00000002 webCmd on:off:dim

und das gleichen eben mit den restlichen drei Geräten.

Dann eingelernt mit set EnO_sensor_00000001 teach, set EnO_sensor_00000002 teach usw.


hexenmeister

FHEM-Konfig sieht korrekt aus, aber... die ZuordnungsIDs sind in allen drei Aktoren gleich. Somit werden sie auch zusammen angesteuert. Hast Du beim anlernen alle gleichzitig in Lern-Modus gesetzt?

Zitatda ich vorhin den USB-Port an der FAM14 geschrottet habe.
:o wie bekommt man das hin? Rohe Gewalt?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

Zitat von: hexenmeister am 11 November 2018, 19:05:20
FHEM-Konfig sieht korrekt aus, aber... die ZuordnungsIDs sind in allen drei Aktoren gleich. Somit werden sie auch zusammen angesteuert. Hast Du beim anlernen alle gleichzitig in Lern-Modus gesetzt?
:o wie bekommt man das hin? Rohe Gewalt?

Eigentlich nicht. Schon nacheinander an den FUDs eingelernt. Glaube aber mittlerweile auch dass es an der FAM14 Konfig liegt. Ich habs zwar vorhin mit der manuellen Methode versucht um IDs zuzuweisen, aber das hilft auch nicht wirklich. Und ohne Tool ist das irgendwie ein totaler Blindflug.

Ganz einfach: USB-Kabel vergessen abzuziehen und mit Laptop davon laufen....Hoffe nur dass die Platine einfach auszubauen ist.

hexenmeister

Das ist ja blöd :(
Wenn nur die Buchse abgerissen ist (und Platine und Leiterbahnn noch intakt sind), sollte mit etwas Glück leicht austauschbar sein.

Kann leider wenig zum Anlernen sagen, habe alles mit PCT14 angelegt. Außerdem habe ich FGW14 als Gateway zum FHEM, Du nutzt vermutlich USB-Funk-Stick. Da ist das Vorgehen ja etwas anders.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

Zitat von: hexenmeister am 11 November 2018, 19:41:52
Das ist ja blöd :(
Wenn nur die Buchse abgerissen ist (und Platine und Leiterbahnn noch intakt sind), sollte mit etwas Glück leicht austauschbar sein.

FAM14 läuft an sich zu Glück noch. Die Buchse hat definitiv was abbekommen.

Zitat von: hexenmeister am 11 November 2018, 19:41:52
Kann leider wenig zum Anlernen sagen, habe alles mit PCT14 angelegt. Außerdem habe ich FGW14 als Gateway zum FHEM, Du nutzt vermutlich USB-Funk-Stick. Da ist das Vorgehen ja etwas anders.
Gibts denn zu den Unterschieden eine Beschreibung?

hexenmeister

Zitat von: bajuware am 11 November 2018, 19:53:02
Gibts denn zu den Unterschieden eine Beschreibung?
Habe keine gesehen. Aber die Art der Kommunikation ist schon ganz anders. Mit FGW14 kann fhem direkt beliebige ID in das Bus senden, bei Funk lässt FAM14 so etwas aus Sicherheitsgründen nicht zu. Der Stick hat eine Menge eindeutiger unveränderlichen IDs, diese werden dann beim Anlernen verwendet. Daher habe ich leider keine Erfahrung mit dieser Art anzulernen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

Aber jetzt mal ne ganz blöde Frage:
wenn ich diesen Befehl auslöse: define EnO_sensor_00000003 EnOcean 00000003
ich aber folgendes in der Doku lese:
ZitatDie Adressen der am RS485-Bus angeschlossenen Devices setzten sich aus der FAM-Basis-Adresse und der RS485-Bus-Adresse zusammen, die vom FAM14 vergeben werden
Müsste es dann nicht folgendermaßen lauten:
define EnO_sensor_[FAM-Basis-Adresse]3 EnOcean [FAM-Basis-Adresse]3 etc?

In meinem Fall ist die FAM-Basis-Adresse: FF EB 24 00
dann wäre das:
define EnO_sensor_FFEB24003 EnOcean FFEB24003 etc?

hexenmeister

Diese ID braucht FHEM um Rückmeldungen zuordnen zu können.
Mit FGW14 ist das so korrekt, da wird keine FAM-BasisID übertragen. Mit FunkStick bin ich mir nicht sicher, denke aber auch nicht.
Du weiß, dass es korrekt ist, wenn FHEM Statusänderuingen mitbekommt.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Cybers

Warum Funk-Stick? Bzw. wofür? Entweder FAM14 per USB direkt an den Server oder noch das FGW14 dazwischen...
Bei deinen Adressen stimmt auf jeden Fall so einiges nicht.
Gruß, Sascha
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

bajuware

 
Zitat von: Cybers am 11 November 2018, 20:48:14
Warum Funk-Stick? Bzw. wofür? Entweder FAM14 per USB direkt an den Server oder noch das FGW14 dazwischen...
Bei deinen Adressen stimmt auf jeden Fall so einiges nicht.
Gruß, Sascha
Hallo Sascha,

mein Raspi wird erstens an ganz anderer Stelle betrieben als der FAM(Keller) und zweitens benutze ja auch noch Funkaktoren(FSB61&FUD61NPN) die im ganzen Haus Unterputz verteilt sind. Und letztere funktionieren ja auch Einwandfrei.

Grüße

hexenmeister

Ich würde an dieser Stelle zu einem FTD14 greifen, dann ist der bus über Draht und Funk gespannt und man kann alles mit allem direkt anlernen. Ist stressfreier. Aber die Variante über einen Stick funktioniert natürlich auch.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy


hexenmeister

Mit "Direkt" meine ich ohne FHEM. Soll heißen ist es möglich, alle Aktoren (Funk und drahtgebunden) mit allen Eingabegeräten (Tester, Sensoren) direkt anlernen (über FAM14). So könnten Funkaktoren über Schalter gesteuert werden, die an einem FTS14EM angeschlossen sind.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

Also ich habe mit Eltako gesprochen und die sagen, dass es an den IDs in FHEM liegen muss.
Ich frage mich, ob ich attr EnO_sensor_00000003 subDef 01000003 vor dem einlernen mit teach
auslösen muss.

hexenmeister

Ich denke, du musst as ID in subDef eine der 127 aus dem Vorrat deines Sticks nutzen. Hast du das hier schon gesehen: https://wiki.fhem.de/wiki/EnOcean_Starter_Guide
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

Hab ich gelesen, Danke. Dort steht dazu auch folgendes:
ZitatAb Updatestand 04.01.2015 ist eine manuelle Vergabe einer freien SenderID per subDef nicht mehr notwendig. Beim ersten Senden des "teach"-Befehls an den Aktor wird eine freie SenderID vergeben, sofern keine gültige SenderID eingetragen war.

Jetzt hab ich mal die subDef's bei den ersten beiden FUD14 mehrmals gelöscht und jeweils einen erneuten teach ausgeführt.
Nun steht das erste mal in den subDef's FFF27989 & FFF27988.

Ich schwöre aber, dass ich das nun das dritte mal hintereinander mache und mir vorher bei beiden Devices immer die gleiche subDef 010000002 eintegragen wurde.

Wo sieht man denn - logfile - was tasächlich beim teach in gesendet wird. Gibts da ein Log das den output am USB 300 mitscheibt?

hexenmeister

Zum Log kann ich leider nichts sagen, müsste ich selbst rumprobieren.

Nach dem die IDs besser aussehen, funktioniert es jetzt immer noch nicht?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

Ja, funktioniert endlich bis auf die Telegramme zwecks Rückmeldung. Da is tote Hose.

hexenmeister

Zitat von: bajuware am 12 November 2018, 16:59:24
Ja, funktioniert endlich bis auf die Telegramme zwecks Rückmeldung. Da is tote Hose.
Dafür ist die ID in Define zuständig. Ist wohl auch noch falsch.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

bajuware

So, USB-Buchse repariert. FUDs nochmals entsprechend an FAM14 angemeldet, Rückmeldeliste angelegt, aber mir ist immer noch schleierhaft woher man die korrekte ID zum <teach> bekommt. Sollen das wirklich die 00000001, 00000002, 00000003 etc für Adr. 1, Adr 2, bzw Adr 3 sein oder setzt die sich jeweils irgendwie aus der BaseID der FAM14 zusammen?
Und welcher Modus ist am FAM14 denn final der korrekte. Man liest ja viel das BA2 alles kann.

EDIT:
Es ist tatsächlich so, dass sich die ID des FUDs an der BaseID des FAM14 ranhängt.
Siehe: https://forum.fhem.de/index.php/topic,66656.msg608631.html#msg608631

In meinem Fall BaseId der FAM14: FF EB 24 00
Erste FUD14(Adr. 1) am Bus -> FF EB 24 01
Zweite FUD14(Adr. 2) am Bus -> FF EB 24 02
Dritte FUD14(Adr. 3) am Bus -> FF EB 24 03

und schon gibts Rückmeldung!


Cybers

Meines Wissens nach kann das FAM14 zwar Funksignale empfangen, aber keine senden. Demnach können die Rückmeldungen nicht in ûbermittelt werden. Hierfür brauchst du meiner Meinung nach noch ein FTD14. Auf welchen Positionen stehen die beiden Regler am FAM14?
Gruß, Sascha
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

bajuware

Zitat von: Cybers am 13 November 2018, 22:03:15
Meines Wissens nach kann das FAM14 zwar Funksignale empfangen, aber keine senden. Demnach können die Rückmeldungen nicht in ûbermittelt werden. Hierfür brauchst du meiner Meinung nach noch ein FTD14. Auf welchen Positionen stehen die beiden Regler am FAM14?
Gruß, Sascha

Da warst Du jetzt schneller als ich. Klappt alles. Siehe vorigen Post.

hexenmeister

Zitat von: Cybers am 13 November 2018, 22:03:15
Meines Wissens nach kann das FAM14 zwar Funksignale empfangen, aber keine senden. Demnach können die Rückmeldungen nicht in ûbermittelt werden. Hierfür brauchst du meiner Meinung nach noch ein FTD14. Auf welchen Positionen stehen die beiden Regler am FAM14?
Das ist meines Wissens nicht korrekt. FAM14 kann durchaus Signale senden, was jedoch softwaremäßig eben auf Rückmeldungen begrenzt ist.
FTD14 kann aber tatsächlich 'echte' Befehle übermitteln.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Zitat von: bajuware am 13 November 2018, 21:26:36
Es ist tatsächlich so, dass sich die ID des FUDs an der BaseID des FAM14 ranhängt.
Siehe: https://forum.fhem.de/index.php/topic,66656.msg608631.html#msg608631

Wieder was gelernt. Bei einer Anbindung über FGW14 ist das nicht so.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy