MDT AKK-Schaltaktor, Denkfehler?

[mumpf]

Danke für den Tip,

ich werde mach über Pfingsten testen...

Gruß, Waldemar

[ggt]

Hi ggt,

hast Du eigentlich in FHEM die Möglichkeit gefunden, einen DPT5.001 bzw. einen DPT9 an KNX zu senden? Vielleicht habe ich ja nur ne alte Version, aber ich bekomm es nicht hin, nur DPT1 klappt...

Gruß, Waldemar

Hi Waldemar,

mit der neuen Version FHEM Forum: KNX/EIB » Themen Version 2/2013 funktioniert das.

Gruß, ggt

[ggt]

Hi Waldemar,

nein du hast keine alte Version das geht noch nicht mit fhem Befehlen. Du könntest das aus fhem mit dem system Befehl groupwrite ... lösen KNX/EIBD Rollo Steuerung mit Preset Funktion konfigurieren? - FHEM users | Google Groups

Gruß,
ggt

[MuckiLegden]

Mir ist echt so, dass MDT nichts aktiv auf den Bus schickt. Ich müsste pollen.

Doch das tut er wohl

Ist aber IMHO in einigen Applikationen erst zu aktivieren.

Vg,
Mucki

[mumpf]

Hi ggt,

hast Du eigentlich in FHEM die Möglichkeit gefunden, einen DPT5.001 bzw. einen DPT9 an KNX zu senden? Vielleicht habe ich ja nur ne alte Version, aber ich bekomm es nicht hin, nur DPT1 klappt...

Gruß, Waldemar

[ggt]

Hi Waldemar,

danke, du warst schneller.
Wollte das auch gerade schreiben, liegt wirklich an FHEM. Man keine Attribute festlegen, ob gelesen oder geschrieben wird. Also für diesen Fall die Adressen trennen und so verfahren wie in deiner Softwarelösung.

Gruß,
ggt

[mumpf]

Hi,




ich denke, das "Problem" liegt an verschiedenen Stellen:

1. Häufig hat man in der Visu ja 2 Adressen hinterlegt (z.B. hinter einem Button), damit dieser den Status anzeigen und auch schalten kann. Hier muss man darauf achten, dass die Visu (der Button) auf die Schaltadresse nur schreibend zugreift, und auf die Statusadresse nur lesend. Meine Vermutung hier: Schaltadresse macht ReadWrite, Statusadresse macht Read. Damit würde sich das Verhalten erklären lassen.
2. Falls die Visu wirklich FHEM ist, dann kann man da hinter einem EIB-Device eine Hauptadresse und mehrere hörende Adressen hinterlegen. Soviel ich weiss, aber keine "Flags", die festlegen, ob gelesen oder geschrieben wird (sind also immer ReadWrite). Das würde auch das Verhalten erklären.

Softwarelösung in FHEM:

• Mach 2 unterschiedliche Geräte in FHEM für die beiden Adressen (ich nenne die jetzt mal xxxSchalten und xxxStatus)
• Blende beide Geräte aus
• Erzeuge ein dummy-Gerät mit dem eigentlichen Zielnamen (hier mal xxx)
• mach ein "define NxxxSchalten notify xxx: (on|off) set xxxSchalten %", der schickt die FHEM-Schaltbefehle an den KNX-Schaltkanal (simuliert also das Write)
• mach ein "define NxxxStatus notify xxxSchalten: (on|off) setstate xxx %", das aktualisiert xxx bei einem Statuswechsel (simuliert das Read) - wichtig, dass hier unbedingt nur ein setstate verwendet wird!
• Anm.: Bei den notifies darf zwischen : und ( kein space sein, aber wenn ich das so schreibe, bekomme ich hier einen Smiley...

Das dummy-Objekt xxx verhällt sich in FHEM jetzt so wie es sein sollte.

Gruß, Waldemar

[2ndsky]

@ggt: ist ganz sicher das Statusobjekt mit der Visu verknüpft und nicht das Schaltobjekt?

[drego]

Ich versteh es immer noch nicht. Ich probiere es dann selber aus!
Zum Glück hab ich MDT und nen Experementierkasten.

drego

PS: Mir ist echt so, dass MDT nichts aktiv auf den Bus schickt. Ich müsste pollen.

[ggt]

Im Gruppenmonitor sehe ich die Statusmeldung wenn der Kanal nicht gesperrt ist. Wenn gesperrt dann nicht - wie #2.

Zur Auswahl stehen logische Verknüpfungen, Statusrückmeldungen, Sperrfunktionen, zentrale Schaltfunktionen sowie umfassende Zeitfunktionen wie z.B. Ein-/ Ausschaltverzögerungen und Treppenlichtzeitfunktionen. Zusätzlich stehen Szenenfunktionen zu Verfügung ...

Danke, lassen wir das ...

[drego]

Handbuch Seite 9

5 Status DPT 1.001 Out, Read

Gruß,
ggt

das heisst was genau? Doch nicht, dass das KO automatisch verschickt wird. Oder hab ich jetzt auch nen Brett vorm Kopf

[ggt]

@MathiasS: Das ist denk ich mal allen klar, oder?
Ich frage mich blos, wie er den Status des MDT ausliest! Der wird nämlich gar nicht verschickt. MDT hat das zumindest nicht in der Dokumentation.
Wie aber bekommt man in "Echtzeit" dann den Status vom Aktor überhaupt in die Visu, wenn der das gar nicht verschickt?

drego

Handbuch Seite 9

3.2 Kommunikationsobjekte pro Kanal
Folgende Objekte können, je nach parametrierter Funktion, pro Kanal eingeblendet werden::
Nr. Funktion Verwendung Datentyp
0 Schalten Ein/Aus Nur bei Funktion „Schaltausgang“ DPT 1.001 In, Write
1 Treppenlicht Nur bei Funktion „Treppenlicht DPT 1.001 In, Write
2 Sperren DPT 1.001 In, Write
4 Szene Nur bei Funktion „Schaltausgang und wenn Szenen aktiviert sind DPT 18.001 In, Write

5 Status DPT 1.001 Out, Read

6 Logik 1 Nur bei Funktion „Schaltausgang“ und bei aktivierter Logik DPT 1.001 In, Write
7 Logik 2 Nur bei Funktion „Schaltausgang“ und bei aktivierter Logik DPT 1.001 In, Write
+8 nächster Kanal
Tabelle 2: Kommunikationsobjekte pro Kanal

Gruß,
ggt

[drego]

@MathiasS: Das ist denk ich mal allen klar, oder?
Ich frage mich blos, wie er den Status des MDT ausliest! Der wird nämlich gar nicht verschickt. MDT hat das zumindest nicht in der Dokumentation.
Wie aber bekommt man in "Echtzeit" dann den Status vom Aktor überhaupt in die Visu, wenn der das gar nicht verschickt?

drego

[MatthiasS]

Bist du dir sicher, dass die Visu nicht auf das Schaltobjekt hört?

Das ist die entscheidende Frage. Zeigt die Visu das Schalt- oder Statusobjekt an des Aktorkanales?

Wenn da nicht das Statusobjekt hinterlegt ist, zeigt die Visu das richtigerweise falsch an.

[Basti]

Bist du dir sicher, dass die Visu nicht auf das Schaltobjekt hört?

Der Aktor sollte in dem Fall gar keinen Status senden, da der Status der Lampe "Aus" war und nach dem Telegramm immer noch "Aus" ist. Also sollte die Visu nciht auf "ein" umschalten.