Reading -get -set

[th1984]

Hallo,

ich habe eine Frage zu dem KNX Modul: Ich habe meine Steckdosen über einen Aktor geschaltet. Von diesem möchte ich mir 2 Werte holen und eben die Steckdose schalten. Wenn ich nun alle drei Adressen einzeln in FHEM definiere, klappt alles, aber, man möchte es ja schön und richtig machen, deswegen habe ich dieses jetzt entsprechend geändert:

Code Auswählen Erweitern

7/2/6:dpt1:status 6/4/7:dpt9.021 6/4/2:dpt13.010

Soweit so gut. die Werte mA und auch kw/h kann ich mir problemlos anzeigen lassen, da diese ja auch immer in dem get-reading gespeichert werden. Ich habe nur ein Problem mit dem Status. Hier steht das aktuelle Reading mal im status-get und mal im status-set reading, je nachdem ob der Schaltbefehl von KNX kam oder aber aus dem Webinterface von FHEM. Da nun aber auch die anderen readings im state landen, kann ich von dort auch den Status nicht mehr abfragen. Daher meine Frage, gibt es eine Möglichkeit das reading ohne -get & -set zu speichern. Oder ist es eigentlich nicht vorgesehen, dass ich so ein Device so zusammen bastle?

Danke und vlg
Thomas

[EIB-Fan]

Hallo th1984,

der Status des KNX-Aktors wird durch status-get aktualisiert.

Um diesen in Fhem in state anzuzeigen, musst du statecmd verwenden.

Code Auswählen Erweitern

attr steckdose stateCmd {sprintf("%s", ReadingsVal($name,"status-get",""))}

Gruß Jens

[th1984]

Hallo Jens,

danke für deine Antwort. Das ist ja genau mein Problem. Das funktioniert ja nicht. Auf state laufen regelmäßig andere Werte drüber, zum Beispiel der momentane Verbrauch in mA (aktualisiert sich immer wenn er sich ändert) oder aber der Gesamtverbrauch einmal in der Stunde. Daher bildet state nie den tatsächlichen Status der Steckdose ab (also ob ein oder aus). Einfach gesagt müsste ich nur beide readings (status-get, status-set) in ein reading status schreiben. Aber ist der Gedanke nicht zu kompliziert? Und wenn nein, wie schreibe ich ein Reading in ein anderes und auch nur dann wenn dieses einen neuen Wert liefert?

Grüße
Thomas

[EIB-Fan]

Hallo thomas,

hast du statecmd probiert?

Gruß Jens

[th1984]

Hallo Jens,

klar hab ichs probiert. Mit deiner Variante und auch mit nachstehender. Erfolg hatte ich gar keinen, sprich state wurde überhaupt nicht geändert. Wenngleich ich glaube, selbst wenn sich state kurz ändert, was passiert wenn ein neues Reading kommt? Wird dann state auch wieder mit dem ein aus status überschrieben?

Code Auswählen Erweitern

{$state = sprintf("%s", "ReadingsVal($name,"status-set",""))}
das ist ja das Original aus der Commandref aber auch mit deinem Vorschlag. State lässt sich jedoch damit nicht verändern. Warum auch immer....

Dafür gibt es eine Fehlermeldung im Log:

Code Auswählen Erweitern

PERL WARNING: String found where operator expected at (eval 187) line 1, near "set",""
PERL WARNING: String found where operator expected at (eval 187) line 1, at end of line
PERL WARNING: Bareword found where operator expected at (eval 191) line 1, near

Grüße
Thomas

[EIB-Fan]

Hallo Thomas,

habe bei mir immer alle KNX-Gruppenadressen mit einem ReadingName (status, strom, verbrauch ...) angegeben. Probier das mal ...

Vielleicht hilft auch mal alle Readings des Device zu löschen. Diese werden dann neu geschrieben.

In der Kommadozeile von Fhem eingeben:

Code Auswählen Erweitern

deletereading steckdose .*

Kannst du bitte auch mal das komplette Device posten.

Gruß Jens

[th1984]

Hallo Jens,

danke schonmal für deine Geduld. Mein Device ist eigentlich ganz einfach, keine Besonderheiten. Aber das statecmd mag er gar nicht. Da kommt dann keine Aktualisierung zu state mehr durch. Deswegen vermutlich auch der Fehler im Log. Da bin ich noch am Suchen was den auslöst.

Code Auswählen Erweitern

define og_bu_steckdose_neben_fenster_links KNX 7/2/6:dpt1:status 6/4/7:dpt9.021:ma 6/4/2:dpt13.010:kwh
attr og_bu_steckdose_neben_fenster_links IODev KNX
attr og_bu_steckdose_neben_fenster_links alias Schreibtisch Thomas
attr og_bu_steckdose_neben_fenster_links group Steckdose
attr og_bu_steckdose_neben_fenster_links room OG_Büro

Hast du deine Steckdosen eventuell ähnlich aufgebaut? Wie hat das bei dir mit den unterschiedlichen Readings funktioniert... ich steh da scheinbar immer noch auf dem Schlauch. Gerade auch wenn ich dann eine Groupreadings machen will, muss ich ja sicherstellen das ich nur ein Reading habe. Wenn aber jedes mal -get -set dahinter steht, hab ich ja immer zwei die ich dann immer irgendwie zusammenfassen muss da ja das Ergebnis sonst nicht stimmen kann.

Readings hab ich übrigens mal gelöscht, ist aber vom Ergebnis her alles das gleiche. Auch das mit der Fehlermeldung wenn ich den statecmd wieder rein klopfe. Über weitere Ideen bin ich dankbar

vlg
Thomas

[Andi291]

Abend!

Ich hab noch nicht so ganz verstanden, was Dein Problem ist...In state steht immer die letzte Transaktion im aktuellen Gerät. Kannst Du (wie zuvor beschrieben) per StateCmd anpacken.

Ich persönlich modifiziere lieber per stateRegex und packe mir die nötigen Informationen in den INHALT von state. Beispiel:

Code Auswählen Erweitern

define nas KNX 11/0/1:dpt1.001:status 11/0/0:dpt1.001:steuern 11/0/2:dpt1.001:reboot
attr nas stateRegex /steuern-[sg]et:/steuern-/ /status-[sg]et:/status-/ /reboot-[sg]et:/reboot-/
attr nas devStateIcon status-on:general_an:Aus status-off:general_aus:Ein steuern-.*:hourglass reboot-.*:hourglass
attr nas eventMap /on g2:Ein/off g2:Aus/on g3:Reboot/
attr nas webCmd Ein:Aus:Reboot

Ergebnis sieht dann so aus - state enthält:
status-on ODER steuern-off ODER reboot-on ODER...

Damit kann ich ein-eindeutig agieren. Dafür habe ich das Attribut stateRgex auch gebaut


Wie gesagt hab ich aber noch nicht verstanden, was Du willst...Beispielsweise zur Auswertung von Energie und Strom würd ich eher auf userreadings ausweichen und die entsprechenden Readings getG2 und getG3 hernehmen...

Grüße, Andi

Grüße, Andi

[th1984]

Hallo Andi,

danke für deinen Input. Allerdings glaube ich sind wir noch nicht ganz bei einander. Was ich will ist eigentlich mal sehr simpel. Ich versuch es mal nochmal zu erklären und mein Problem darzustellen: Ich habe mein Device, welches eine Steckdose mit 3 Funktionen abbildet: Funktion 1: schalten, Funktion 2 Stromwert ausgeben, Funktion 3 kwh sammeln und ausgeben. Getrennt voneinander funktioniert alles prächtig. Wenn ich es aber in ein Device zusammenfasse wie hier:

Code Auswählen Erweitern


define og_bu_steckdose_neben_fenster_links KNX 7/2/6:dpt1:status 6/4/7:dpt9.021:ma 6/4/2:dpt13.010:kwh
attr og_bu_steckdose_neben_fenster_links IODev KNX
attr og_bu_steckdose_neben_fenster_links alias Schreibtisch Thomas
attr og_bu_steckdose_neben_fenster_links group Steckdose
attr og_bu_steckdose_neben_fenster_links room OG_Büro
attr og_bu_steckdose_neben_fenster_links stateRegex /status-[sg]et:/status-/


bekomme ich nach kurzer Zeit folgende Readings:

Code Auswählen Erweitern

last-sender 1/1/17 2016-12-17 20:27:20
ma-get 0.00 mA 2016-12-17 20:27:20
state ma-get:0.00 mA 2016-12-17 20:27:20
status-get on 2016-12-17 20:26:51
status-set off 2016-12-17 20:27:11


Mir geht es jetzt darum, dass ich aus dem state nicht lesen kann, ob die Steckdose jetzt ein oder aus ist, da wie in diesem Fall zwischenzeitlich ein neues Reading mit mA dazwischen gefunkt hat. Vielleicht jetzt eine saublöde Frage, aber kann man das verhindern das ein Reading im State landet, ich glaub das würde mein Problem lösen. Auf mA und kwh greife ich ja sowieso über get zu, das ist ja kein Problem und funkt aus. Für mich ist nur das Problem, dass ich beim Schalten in der KNX Welt das Reading status-get on auslöse und wenn ich in Fhem online rumspiele das status-set on. Quasi zwei Probleme auf einmal, allerdings wenn das State jeweils den aktuellen Schaltzustand hätte, wäre das hier leicht ausreichend.

Blöde Frage am Rande, warum gibt es eigentlich -set und -get nur getrennt? Warum nicht einfach ein Reading für beides? Bezogen auf den oberen Fall gäbe es dann keine Frage ob die Steckdose jetzt ein oder aus ist, egal was im state steht.

Ich hoffe ich konnte mein Problem etwas klarer formulieren.

Danke und schönen Abend!
Thomas

[EIB-Fan]

Hallo Thomas,

habe mir mal dein Device angeschaut.

Mich wundert, dass du keine getrennte Gruppenadresse für Schalten (set) und Status (get) hast.

Hier mal eine Beipiel aus meiner Konfiguration.

Code Auswählen Erweitern


define EG_KUE_Steckdosen KNX 3/2/20:dpt1:schalten 3/2/21:dpt1:status 3/2/22:dpt7:betriebsstunden 3/2/23:dpt7:strom 3/2/24:dpt12:zaehler
attr EG_KUE_Steckdosen IODev tul
attr EG_KUE_Steckdosen devStateIcon on:message_socket@green off:message_socket
attr EG_KUE_Steckdosen event-on-change-reading status.*,strom.*:10,zaehler.*,betriebsstunden.*
attr EG_KUE_Steckdosen eventMap /on g1:AN/off g1:AUS
attr EG_KUE_Steckdosen room Küche
attr EG_KUE_Steckdosen stateCmd {sprintf("%s", ReadingsVal($name,"status-get",""))}
attr EG_KUE_SteckdosenwebCmd AN::AUS


Der Status wir hier per Icon mit AN und AUS dargestellt.

Gruß Jens

[Andi291]

Morgen Thomas,

jetzt hab ich Dich...Dann muss ich mich meinem Vorredner anschließen:

Code Auswählen Erweitern

attr EG_KUE_Steckdosen {$state = sprintf("%s", "ReadingsVal($name,"status-get",""))}

holt nach jedem Event den zuletzt empfangenen Wert aus der GAD 7/2/6 - "Status" und schreibt ihn in state. Ich kann mich Jens allerdings nur anschließen - getrennte GA für steuern und Status sind zu empfeheln - das ist die Denke vom KNX. Schimpft sich "Rückmeldung".

Zu Deiner anderen Frage: früher gab es -set und -get nicht getrennt. Das widerum hatte aber zur Folge, dass ich nicht unterscheiden konnte, ob der Wert nun vom FHEM oder vom Bus kam. Auf vielfachen Wunsch (auch meinen eigenen ) hab ich das geändert.

Grüße, Andi

[th1984]

Hallo Andi,

danke für die Info. Ich habs bei mir probiert, haut aber nicht hin und es erscheint immer der oben genannte Fehler im Log. Allerdings hab ich festgestellt, dass irgendwas anderes nicht ganz in Ordnung ist, werde daher vorerst mal eine saubere neue Installation herstellen (Qnap und VM) und dann dank eurer Hilfe auch dieses Thema lösen. Auch das mit der Rückmeldung und KNX schau ich mir nochmal näher an.

Danke
Thomas

[Löwenzahn]

Code Auswählen Erweitern


define EG_KUE_Steckdosen KNX 3/2/20:dpt1:schalten 3/2/21:dpt1:status 3/2/22:dpt7:betriebsstunden 3/2/23:dpt7:strom 3/2/24:dpt12:zaehler
attr EG_KUE_Steckdosen IODev tul
....


Hallo Jens,
ich würde gerne wissen, wo der Vorteil der "mehrfach Definition" gegenüber der "Separierten" liegt ?!
Momentan habe ich alle GAs die ich in FHEM verwende einzeln definiert.
z.B.

Code Auswählen Erweitern


define EG_KUE_Steckdosen__EA KNX 3/2/20:dpt1
....


Code Auswählen Erweitern


define EG_KUE_Steckdosen__Status KNX 3/2/21:dpt1
....


Zugegeben es ist etwas mehr Arbeit bei der Einrichtung, aber .... ? 
Vielen Dank

Gruß Lutz

[Andi291]

Abend!

Es lassen sich ohne Notifies einfach Zustände eines physikalischen Gerätes mit einem FHEM-Device abbilden. Bsp. aus der commandref:

      define myLamp KNX 0/1/1:dpt1 0/1/2:dpt1 0/1/2:dpt1
     attr myLamp stateRegex /getG1:/steuern:/ /getG2:/status:/ /getG3:/sperre:/ /setG[13]:/steuern:/ /setG[3]://
     attr myLamp devStateIcon status.on:general_an status.off:general_aus sperre.on:lock steuern.*:hourglass

Grüße, Andi

[Löwenzahn]

Perfekt, Danke.

Manchmal sieht man den Wald nicht.

Gruß Lutz

[krizztus]

Hallo....

Ich habe interessiert den Thread gelesen, weil ich seit 3 Tagen feststecke eine blöde Rückmeldung zu bekommen. Ich hab langsam das Gefühl das mein FHEM/KNXD das irgendwie garnicht empfängt oder lauscht.

###########################################################
# Loft Treppe
###########################################################
define KNX_0002009 KNX 0/1/9:dpt1:onoffschalter 0/2/9:dpt1:onoffstatus
attr KNX_0002009 IODev KNX
attr KNX_0002009 alias Treppe
attr KNX_0002009 group Beleuchtung
attr KNX_0002009 icon light_ceiling_off
attr KNX_0002009 room KNX,Loft,Homekit
attr KNX_0002009 stateRegex {$state = sprintf("%s", "ReadingsVal($name,"onoffstatus-get",""))}

Ich krieg einfach nichts in onoffstatus-get. Sprich ich kann alles schalten vom Webpanel, in der komischen Gira App bewegt sich dann auch das AN/AUS, also das Ding kriegt die Rückmeldung.

Ich hab dann mal versucht das selbst auszulesen.

Konsole1:
knxtool groupread ip:localhost 0/2/9
Send request

Konsole2:
knxtool vbusmonitor1 ip:localhost
LPDU: BC 00 00 02 09 E1 00 00 A9 :L_Data low from 0.0.0 to 0/2/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
LPDU: BC 00 01 02 09 D1 00 00 98 :L_Data low from 0.0.1 to 0/2/9 hops: 05 T_DATA_XXX_REQ A_GroupValue_Read
LPDU: BC 11 16 02 09 E1 00 41 EF :L_Data low from 1.1.22 to 0/2/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Response (small) 01

Also da steht eine 01 drin, das Licht ist grad an.
Wieso krieg ich den Wert aus der 0/2/9 nicht auf auf das doofe Reading "onoffstatus-get" da oben..Gibt es irgendetwas was ich grundsätzlich einstellen muss??

so sieht AN/AUS aus, wenn ich das mit FHEM Webpanel mache
LPDU: BC 00 00 01 09 E1 00 81 2B :L_Data low from 0.0.0 to 0/1/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
LPDU: BC 00 01 01 09 D1 00 81 1A :L_Data low from 0.0.1 to 0/1/9 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write (small) 01

LPDU: BC 00 00 01 09 E1 00 80 2A :L_Data low from 0.0.0 to 0/1/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: BC 00 01 01 09 D1 00 80 1B :L_Data low from 0.0.1 to 0/1/9 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: BC 11 16 02 09 E1 00 80 2E :L_Data low from 1.1.22 to 0/2/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00

so sieht es aus wenn ich das mit der Gira GammelApp machen

LPDU: B8 FF FF 01 09 E1 00 81 2F :L_Data normal from 15.15.255 to 0/1/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
LPDU: BC 11 16 02 09 E1 00 81 2F :L_Data low from 1.1.22 to 0/2/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01

LPDU: B8 FF FF 01 09 E1 00 80 2E :L_Data normal from 15.15.255 to 0/1/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: BC 11 16 02 09 E1 00 80 2E :L_Data low from 1.1.22 to 0/2/9 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00

Also ich sehe es geht immer halt das an/aus an 0/1/9 und auch an 0/2/9 , aber halt von 1.1.22 (ist vielleicht die Zentrale?, die dann sieht, "AAAh Wert von 0/1/9 hat sich geändert, also stelle ich den bereit auf von 1.1.22 auf 0/2/9)
....wie auch immer....
Ich kriege nix ...es nervt micht , alles geht...das geht nicht ....Warum auch immer, finde auch kaum jmd der Probleme damit hat in Foren?! Also wird das vermutlich trivial sein?! hehe

Ich hoffe der Beitrag hilft auch anderen, die da irgendein Problem mit haben ...

[Andi291]

N bißchen am THema vorbei, aber gut

Mach mal bitte ein Update. Vergangene Woche hab ich da was dummes eingespielt

[krizztus]

Hey,

das tut mir leid, ich glaube ich bin mit den Begrifflichkeiten noch nicht ganz so save....Du kannst es verschieben oder?

Und gibts eigentlich schon eine FAQ?

Wenn ja spendier ich dir jetzt die ersten beiden Beiträge...

1) Wie mache ich ein Update?
Antwort: ähhh ...(Ich schau gleich mal wo ich es finde ))

[Andi291]

Kein Problem

Nein, ich kann nicht schieben. Macht auch nichts.

Update (und FAQ ):
https://wiki.fhem.de/wiki/Update

[krizztus]

WAHNSINN!!! ES geht!...

Ich hasse es die letzten 3 tage einen Fehler gesucht zu haben, den es nicht gab. Aber ohne diesen hätte ich auch nicht tiefer in fhem geschaut..

Aber es ist einfach geil, dass es sowas gibt,,,

[Thomas B]

Ich hänge mich einfach auch mal mit dran, weil ich exakt das gleiche Thema habe.

Im KNX 2 Gruppen für eine einfache Lampe definiert.

1/1/12      schalten
1/2/12      status

im FHEM:

define Lampe KNX 1/1/12:dpt1.001 1/2/12:dpt1.001
attr Lampe IODev KNX


Ergebniss ist, dass ich die Lampe problemlos sowohl über Fhem, als auch über den physisch vorhandenen KNX Schalter, sowie die ETS Schalten kann. Es wird aber konsequent die 2. Gruppenadresse von FHEM ignoriert. Ich bekomme also beim Schalten den Status nicht geschrieben.

Bei den Readings ändert sich bei betätigen über FHEM nur setG1.
GetG1 bleibt immer stehen und ändert sich nur beim Schalten über den physischen Schalter. Das ist natürlich schlecht, da dann FHEM und die eigentliche KNX Anlage nicht synchron laufen. Sollte nicht eigentlich ein getG2 und setG2 auftauchen und die StatusGA beschreiben?

Das Beispiel "myLamp"  von Andi angepasst auf meine GA's bringt das gleiche Ergebniss.

Grüße

Thomas

[Andi291]

Wie schaltest DU denn die beiden Lampen?

Folgendes wäre korrekt:

set Lampe on (= set Lampe on g1)
set Lampe off (= set Lampe off g1)
set Lampe on g2
set Lampe off g2

Beide gleichzeitig kannst Du so nicht schalten, falls Du das vor hattest...

[Thomas B]

Ist nur eine Lampe.

Als Schaltadresse hat Sie die 1/1/12 und als Statusadresse die 1/2/12.

Wenn ich also die Lampe 1/1/12 einschalte, so sollte das die 1/2/12 merken und automatisch "mitschalten" also den Status "ON" annehmen. Per Taster an der Wand und damit nativ KNX funktioniert dies auch genauso (auch im FHEM zu sehen). Schalte ich aber im FHEM, so geht die Lampe an, aber die Gruppenadresse 1/2/12 bleibt auf "OFF". Ich könnte quasi die Lampe auch einfach so deninieren und und hätte die gleiche Funktion ohne Statusrückmeldung auf die 2. Gruppenadresse.

define Lampe KNX 1/1/12:dpt1.001
attr Lampe IODev KNX

[Andi291]

Das kann ich mir nicht erklären - das hab ich dutzendfach im Einsatz. Und zwar Problemlos.
Wie hängst Du am Bus?
Was sagt Log5?

[docm]

Hallo,
normalerweise funktioniert das absolut problemlos.
Deiner Beschreibung entnehme ich:
1/1/12 ist das Schaltsignal
1/2/12 ist das Statussignal
Wenn du mit dem echten Schalter schaltest, verändert sich die Lampe und du erhältst das Statussignal in FHEM.
Wenn du aus FHEM heraus schaltest, verändert sich die Lampe, aber du kriegst kein Statussignal in FHEM.
Habe ich das soweit richtig verstanden?

Meine Deutung:
Grundsätzlich funktioniert der Empfang des Statussignals in FHEM, denn du empfängst es ja, wenn du den echten Schalter betätigst.
Grundsätzlich funktioniert auch das Senden, denn du kannst die Lampe schalten.
Also ist auf FHEM Seite alles ok -> mögliche Ausnahmen später
Mein heißer Verdacht wäre jetzt, dass auf der knx-Seite irgend etwas faul ist. Kannst du mit ETS die Zuordnung der GAs zu den Geräten prüfen? Es wäre z.B. möglich, dass 1/2/12 gar nicht das Statussignal des Schaltaktors ist, sondern ein zweites Schaltsignal des Lichtschalters. Wenn du bisher nur einen Schalter für die Lampe hattest, so hättest du das in der Installation gar nicht bemerkt.
Solltest du keine ETS haben, kannst du mit dem Monitor aus knxtool (sofern du knxd verwendest) überprüfen, wer der Sender der 1/2/12 ist. Oder du baust dir ein FHEM KNX Device, das nur diese GA empfängt, und kontrollierst es über Reading last_sender.
Könnte sein, dass die GA 1/2/12 gar nicht vom Aktor gesendet wird, sondern vom Schalter.

Bitte prüfe das zunächst und gib Rückmeldung. Dann geht es weiter!
Viele Grüße
Andreas

[Thomas B]

Wenn ich per Schalter an der Wand aus schalte kommt folgendes.

Code Auswählen Erweitern


2018-01-24 16:10:42 KNX Buerolampe_status setG1: off
2018-01-24 16:10:42 KNX Buerolampe_status off
2018-01-24 16:10:42 KNX Buerolampe_schalten getG1: off
2018-01-24 16:10:42 KNX Buerolampe_schalten last-sender: 2/2/36
2018-01-24 16:10:42 KNX Buerolampe_schalten off
2018-01-24 16:10:42 KNX Burolampe getG1: off
2018-01-24 16:10:42 KNX Burolampe last-sender: 2/2/36
2018-01-24 16:10:42 KNX Burolampe off


Schalten per FHEM erzeugt nur 2 Zeilen:

Code Auswählen Erweitern


2018-01-24 16:12:16 KNX Burolampe setG1: on
2018-01-24 16:12:16 KNX Burolampe on


Ich hab das Ganze mit einem MDT Heizungsaktor und Smart Taster 2 als Stellglied auch über Fhem analog gemacht, also Schalte als erste Gruppe und Status als 2. Gruppe im gleichen device und hier funktioniert es problemlos, dass ich den Sollwert der Temperatur erhöhe und der 2. Teil setzt die Erhöhung im Aktor um 0,5 grad auch um. Sowohl im FHEM als auch am Taster. Läuft alles synchron.

Hab mir die Lampe + Status auch mal mit dem Eventbeispiel aus dem Einsteigertutorial (mylamp) nachgebaut, und hier tut sie genau was sie soll. Bin jetzt aber unsicher ob es bei einem einfachen KNX device so angedacht so zu agieren. Die Angabe von 2 Gruppenadressen in einem Device ohne zwischenschalten von extra notifys wäre ja schon erheblich einfacher.

[Andi291]

Nochmal die Frage:
Wie hängst Du am Bus? TUL ohne knxd, richtig?

[docm]

Hallo Thomas B,

ich bin sicher, wir kriegen es zum Laufen, aber dazu brauche ich präzise Informationen.
Aus dem Eventlog schließe ich, dass du bereits drei KNX Devices Buerolampe_status, Buerolampe_schalten und Buerolampe verwendest. Außerdem schreibst du etwas von einem Notify Device.

Kannst du bitte mal die Raw Definitions all dieser Devices posten? Dann versteht man vielleicht auch die Zusammenhänge.

Viele Grüße
Andreas

[Thomas B]

@ andi
Nein ich hab nen mdt ip Router und knxd am laufen.

@andreas
Such ich raus. Komme aber heute nicht mehr an den Rechner.

Komisch ist auch, wenn der Status von der status gruppen Adresse nicht mit dem schaltstatus überein stimmt und ich schicke einfach einen lesen Befehl an die status gruppen adresse in der ets, so schaltet der Aktor auf den Wert der um Status steht. Wie gesagt, nur lesen nicht schreiben.

[docm]

Komisch ist auch, wenn der Status von der status gruppen Adresse nicht mit dem schaltstatus überein stimmt und ich schicke einfach einen lesen Befehl an die status gruppen adresse in der ets, so schaltet der Aktor auf den Wert der um Status steht. Wie gesagt, nur lesen nicht schreiben.

Da ist noch mehr komisch. Z.B. steht in deinem Eventlog in Zeile 1

Code Auswählen Erweitern


2018-01-24 16:10:42 KNX Buerolampe_status setG1: off


D.h. du schreibst die Status GA von FHEM aus auf den Bus (??). Die solltest du ja eigentlich von deinem Schaltaktor empfangen und nicht selbst auf den Bus senden. Da geht vermutlich etwas durcheinander mit dem Notify und deinen vielen knx Devices.
Eine passable Lösung sollte mit einem KNX Device auskommen, das zwei GAs umfasst (1x schalten, 1x status) und ein Notify Device, das auf den empfanenen Status triggert.
Gerne morgen mehr, wenn du die raw definitions gepostet hast.
Viele Grüße
Andreas

[Thomas B]

So ich hab mal eine andere Lampe ohne Notify oder sonstwas gebaut.

Gruppen in der ETS:
1/1/16 -> Schalter und Aktor Drin
1/2/16 -> Status Aktor drin

Definition im FHEM

Code Auswählen Erweitern


DEF 1/1/16:dpt1.001 1/2/16:dpt1.001
DEVNAME EG_WZ_Lampe_Couch
IODev KNX
KNX_MSGCNT 1
KNX_RAWMSG C02226w0111000
KNX_TIME 2018-01-23 18:34:55
LASTInputDev KNX
MSGCNT 1
NAME EG_WZ_Lampe_Couch
NR 89
NTFY_ORDER 50-EG_WZ_Lampe_Couch
STATE off
TYPE KNX


Ergebnisse einmal Einschalten und direkt danach wieder ausschalten per FHEM

Code Auswählen Erweitern


2018-01-25 15:07:04 KNX EG_WZ_Lampe_Couch setG1: on
2018-01-25 15:07:04 KNX EG_WZ_Lampe_Couch on
2018-01-25 15:07:05 KNX EG_WZ_Lampe_Couch setG1: off
2018-01-25 15:07:05 KNX EG_WZ_Lampe_Couch off


Schaltzustände (Readings) im FHEM

Code Auswählen Erweitern


getG1 off 2018-01-23 18:34:55
last-sender 2/2/38 2018-01-23 18:34:55
setG1 off 2018-01-25 15:07:05
state off 2018-01-25 15:07:05


Ergebnisse nach Schalten per KNX Schalter an der Wand

Code Auswählen Erweitern


2018-01-25 15:12:38 KNX EG_WZ_Lampe_Couch getG1: on
2018-01-25 15:12:38 KNX EG_WZ_Lampe_Couch last-sender: 2/2/39
2018-01-25 15:12:38 KNX EG_WZ_Lampe_Couch on
2018-01-25 15:12:39 KNX EG_WZ_Lampe_Couch getG1: off
2018-01-25 15:12:39 KNX EG_WZ_Lampe_Couch last-sender: 2/2/39
2018-01-25 15:12:39 KNX EG_WZ_Lampe_Couch off


Schaltzustände (Readings) im FHEM nachdem ich die per KNX eingeschaltete Lampe per FHEM ausgeschaltet habe

Code Auswählen Erweitern


getG1 on 2018-01-25 15:14:17
last-sender 2/2/39 2018-01-25 15:14:17
setG1 off 2018-01-25 15:15:27
state off 2018-01-25 15:15:27


Zu beachten ist, dass die Funktion scheinbar per KNX und FHEM identisch ist, allerdings reagiert das getG1 per KNX korrekt auf jedes Schalten und beim Schalten mit FHEM wird es komplett ignoriert und bleibt solange gleich, bis irgendwann wieder der physische Schalter an der Wand betätigt wird.

Ich hoffe das kann etwas weitedr helfen. Auf jedenfall schonmal ein großes Danke an euch, dass ihr euch dem annehmt!!!

[Thomas B]

Als Beispiel die Definition des funktionierenden Raumtermostats

Code Auswählen Erweitern


DEF
3/3/3:dpt1.007 3/2/3:dpt9.001
DEVNAME EG_Bur_Temp_Stellgr
IODev KNX


Readings

Code Auswählen Erweitern


getG1 decrease 2018-01-23 18:31:01
getG2 22.00 °C 2018-01-25 15:32:04
last-sender 1/1/2 2018-01-25 15:32:04
setG1 decrease 2018-01-25 15:32:04
state 22.00 °C 2018-01-25 15:32:04


Was auffällt, hier gibt es ein getG1 UND ein getG2.
Ich klicke auf Temperatur erhöhen und der Befehl geht ordnungsgemäß an die 2. Gruppe und die Temperatur wird um die im Aktor eingestellten 0,5°C erhöht. Bei der Lampe sollte das mit dem Status doch auch so funktionieren oder stehe ch da auf dem Schlauch?

[Andi291]

Das ist sowas von daneben...

Was sagt denn ein ETS-Mitschnitt? Oder ein verbose-5-log?

Ich wette, das ist ein Timingproblem...

[docm]

Hallo Thomas,

also ich finde, es sieht eigentlich gar nicht merkwürdig aus, sondern ganz erwartungsgemäß. Ich konzentriere mich mal auf die Lampe.
Meine Diagnose Schritt für Schritt:
1. Schaltest du die Lampe von FHEM aus, geht sie an und aus =>FHEM sendet erfolgreich Daten auf den KNX-Bus.
2. Betätigst du den Schalter an der Wand, kriegst du das in FHEM über getG1 Reading angezeigt => FHEM empfängt erfolgreich Daten vom KNX-Bus

Also halte ich es erst einmal für unwahrscheinlich, dass Übertragungsprobleme, Timingprobleme etc in der Kommunikation von FHEM über knxd und IP-Gateway bestehen. Wenn man nur einzelne Telegramme auf dem Bus hat, passiert auch nichts. In meiner Heizungssteuerung kann es schon mal vorkommen, dass 30 Telegramme gleichzeitig verschickt werden sollen. Dann muss man in der Tat die langsame Geschwindigkeit des KNX Busses berücksichtigen, sonst gehen Nachrichten verloren. Aber hier ist das bestimmt nicht das Problem.

3. Du empfängst keine Daten auf G2. Das ist das Problem. Und hierfür kann es verschiedene Ursachen geben.
3a) Stimmt die in FHEM konfigurierte GA? Im Text schreibst du 2/1/16 -> Status, im DEF steht 1/2/16. Das ist inkonsistent, aber ich kann natürlich nicht beurteilen, ob nur Tippfehler im Post oder Falschkonfiguration im FHEM.

Jetzt fahre ich mal fort unter der Annahme, das Statussignal soll Tatsächlich auf GA 1/2/16 liegen. Dann ist die naheliegende Erklärung
3b) Du empfängst kein G2, weil im KNX-System niemand etwas auf diese GA sendet.

Jetzt hoffe ich, du bist im Besitz einer ETS-Software und der Projektdatei. Dann kannst du die Konfiguration der Gruppenadressen überprüfen. Wenn die GAs richtig verdrahtet sind, muss in etwa folgendes gegeben sein
GA 1/1/16 liegt auf Taster schalten und auf Aktor schalten auf
GA 1/2/16 liegt auf Taster Status und auf Aktor Status auf
Also eigentlich ganz einfach. Du kannst bei der Gelegenheit gleich noch die Flags beim Kommunikationsobjekt Aktor Status überprüfen. Es müssen das K- und das Ü-Flag gesetzt sein. Normalerweise sollte auch das L-Flag gesetzt sein.
Wenn es falsch ist, mittels ETS die Devices umprogrammieren.

Wenn du bis hierhin gekommen bist und keine Fehler finden konntest, d.h. GA stimmt und Konfiguration in ETS stimmt auch, dann gib mal in der FHEM Befehlszeile ein: get EG_WZ_Lampe_Couch g2

Was passiert? Bitte poste deine Erfahrung. Dann geht es weiter.
Gruß
Andreas

[Thomas B]

Sorry oben war ein Dreher in der knx Gruppe. Habs editiert.

Ets log läuft synchron zum fhem log soweit ich das sehe. Was meinst du mir sowas von daneben? Das grundsätzliche schalten funktioniert ja. Ich kann den Status im reinen knx auch über die LEDs an den Tastern sauber rückmelden. Auch über völlig unabhängige Taster.

Mit dem verbose-log kann ich gerade nicht wirklich was anfangen. Muss ich mich erst schlau machen. 

[docm]

Vergiss das mit dem "daneben". Auch verbose brauchst du nicht. Andi291 vermutet Fehlfunktion im KNX-Modul Code. Glaub ich aber nicht. Ist ein anderes Problem.
Wie lauten jetzt die GAs?

[docm]

ok habs gesehen, du hast die GAs korrigiert.
Aber auf G2 empfängst du trotzdem nichts, oder?

[Thomas B]

Nein. War nur nen Zahlendreher.

Also auf der 1/1/16 ist der Schalter und der aktor verknüpft, auf der 1/2/16 lediglich der status des aktors in der ets.

Kann ja auch irgendwie nicht grundsätzlich falsch sein, denn über knx läuft ja alles problemlos, siehe logs. nur beim schalten über fhem nimmt er irgendwie die status gruppenadresse nicht mit.

[Thomas B]

"get EG_WZ_Lampe_Couch g2"

bringt nur ein fenster mit "current value..... requested" aber keinerlei einträge im event monitor. ist ja das gleiche als wenn ich im device auf get klicke und value einstelle

[docm]

Hast du die Verdrahtung der GAs in der ETS überprüft? Wie sind sie verbunden.
Wenn du im FHEM den get Befehl sendest, siehst du dann was im ETS Log? Bitte posten.

[Thomas B]

Verdrahtung hab ich eben in der ETS kontrolliert.

wie geschrieben in der schaltengruppe 1/1/16 liegt der taster sowie der aktorkanal
in der statusgruppe 1/2/16 liegt nur der statuskanal von aktor

flags passen auch. hab eben auch mal testweise alle 3 kandidaten alle flag verpasst, ohne erfolg.
ets monitor läuft synchron zum fhem event monitor wenn ich im fhem schalte.

alle hardware geräte (KNX Router, aktor, taster von mdt) fhem auf einem rpi3

[docm]

was siehst du im ETS Gruppenmonitor, wenn du im FHEM
get EG_WZ_Lampe_Couch g2
eingibst?

[Thomas B]

Nichts. Das ist es ja. Es taucht auch kein reading hierfür auf im fhem.

Ich hatte ja testweise eine andere Lampe anders gebastelt.

Dazu ein device nur schalter 1/1/16
ein zweites device nur status 1/2/16
und beides über ein notify wie im einsteigerguide beschrieben verbunden.
läuft perfekt. nur 2 gruppen in einem device funktionieren bei der den einfachen schaltern nicht.
wie erwähnt war es auch kein problem meine sollwertverschiebung in einem device unter zu bringen, wo die 2. GA für die eigentliche verschiebung zuständig ist und die erste GA eigentlich nur sagt ob hoch oder runter. das klappte alle völlig problemlos ohne notifys oder sonstwas.

[docm]

Jetzt verstehe ich es auch nicht mehr. Nur dass wir uns nicht falsch verstehen: Ich meine nicht den Event-Monitor im FHEM, sondern den Gruppenmonitor in der ETS. Und er ist auch gestartet

Auf den Befehl
get EG_WZ_Lampe_Couch g2
passiert dort gar nichts!

Was passiert bei
get EG_WZ_Lampe_Couch g1
?

[Thomas B]

Wir verstehen uns schon richtig. Hab den ets Monitor und den fhem Monitor parallel laufen. getG1 läuft aus fhem heraus geschaltet in beiden Monitoren parallel identisch. getG2 scheints nicht zu geben. Passiert nix. Als wenns nicht cht da wäre.

[docm]

Hallo Thomas,

ich habe jetzt mal ein ganz einfaches knx Device gebaut

Code Auswählen Erweitern


defmod testknx KNX 1/1/16:dpt1.001 1/2/16:dpt1.001


Diese GAs sind in meinem KNX-system frei, d.h. nirgends angeschlossen.

Auf beide Befehle

Code Auswählen Erweitern


get testknx g1
get testknx g2

sehe ich im ETS Gruppenmonitor die entsprechenden GAs auf dem Bus.

Es gibt also kein generelles Problem mit dem g2 in der von dir beschriebenen Kombination.
Liegt es an dieser speziellen GA in deinem System? Wenn du irgendwelche anderen GAs nimmst, funktioniert es dann?

[docm]

Natürlich passiert in dem zuvor beschriebenen Beispiel auch nichts mit den getG1 und getG2 Readings. Es kommt ja keine Antwort vom Bus, die FHEM empfangen könnte.

[Thomas B]

Nein mehrere Lampen getestet und auch schon komplett neue erstellt. Immer das gleiche. Die 2.adresse läuft nicht in Kombination. Bei anderen Devices wie meinen Rollos oder Thermostaten geht's. Versteh ich langsam nicht mehr

[docm]

Funktioniert eine dritte GA?
Funktioniert es mit anderen dpt-Typen?
Du schreibst zwischen den GA Blöcken ein Leerzeichen und nichts anderes?
Welchen Output liefert der Befehl

Code Auswählen Erweitern


list EG_WZ_Lampe_Couch


[docm]

Wir können es gerne noch an einem anderen Tag weiter versuchen. Bin allerdings erst Sonntag wieder online.
Das Thema mit den zwei GAs in einem Device ist so Basic, dass ich nicht annehme, etwas am Code des KNX Moduls ist faul. Das funktioniert bei hundert anderen Usern problemlos.

Was passiert im ETS Gruppenmonitor wenn du in FHEM den Schaltbefehl absetzt?
Du müsstest eigentlich zwei Einträge im Log finden:
1. der Schaltbefehl: Quelle ist FHEM
2. der Status: Quelle ist der Aktor

Ist der zweite Eintrag im Log vorhanden? Der Aktor reagiert ja auf das Schaltsignal und sendet dann seinen neuen Status. Das ist erst einmal komplett unabhängig von FHEM.

Gibt es in deiner KNX-Installation irgendwelche Linienkoppler?
Hast du mehrere Linien, oder alles in einer?
Du nutzt einen IP Router. Betreibst du ihn mit knxd als Router oder im Tunelling Modus? Ich selbst habe nur ein IP-Interface und keinen Router, kenne mich daher mit den Routern nicht aus. Habe aber gelesen, dass sie GAs filtern. Der MDT macht das in der Grundeinstellung. Überprüfe mal die Konfiguration.

Du könntest auch mal direkt mit Funktionen aus dem KNXDTOOL auf den knx Bus schreiben bzw GAs empfangen. Damit könntest du evtl FHEM Probleme erst einmal ausschließen.
Also im ersten Schritt verifizieren: Du sendest vom Raspi aus ein Schalttelegramm an die Lampe -> die Lampe schickt ein Statustelegramm zurück.
Geht das mit KNXTOOL Funktionen einwandfrei?
Gute Nacht
Andreas

[Thomas B]

Mitternacht und du bist noch immer an meinem Problem. Respekt und dickes Dankeschön erstmal dafür.

Ich probiere heute nachmittag nochmal.
Die verschiedenen Linien sind vielleicht noch ein Ansatz.
Ich habe eine TP Linie in der sich der Router befindet und eine RF Linie in der sich die Schalter mit integriertem Aktor (MDT Funkglastaster) befinden und die per RF Linienkoppler mit der tP Linie verbunden sind.
Eigentlich dachte ich ich lasse die GA'S ungefiltert durch, aber ich schaus mir nochmal genau an in der ETS. Wobei ja eigentlich dann auch das Schalten per KNX Taster nicht sauber funktionieren sollte, wenn der Linienkoppler die GA nicht durchlässt. Ich schaus mir nochmal an.

Melde mich wieder.

Grüße

Thomas

[Thomas B]

Die Statusgruppe wars tatsächlich.
Hatte die komplett auf filtern. Nach Umstellen auf weiterleiten hats sprichwörtlich "klick" gemacht und ich habe jetzt auch das G2reading vom Status im FHEM. Beim Schalten spricht er jetzt auch beide Gruppen an.

Oh Man vielen Dank nochmals an euch, dass ihr euch dem angenommen habt. Der Tip mit der Linienkoppler war Gold wert.

Thema damit erledigt.

Danke Thomas