[Hinweis] Anzeige in FHEM - Web soll sich erst ändern wenn Rückmeldung kommt

Begonnen von ZeitlerW, 02 Januar 2016, 13:09:37

Vorheriges Thema - Nächstes Thema

ZeitlerW

Hallo zusammen,

hier ein kurzer Hinweis wie Rückmeldeobjekte behandelt werden können.

Aufbau:

  • Licht wird durch EIB 0/0/1 geschaltet.
  • Aktor meldet an EIB 0/0/2 den Status zurück

Gewünschtes Verhalten:
Anzeige des Devices in FHEM - Web soll sich in FHEM erst ändern, wenn das Rückmeldeobjekt sich ändert.

Lösung:
Nutzung von EIBreadingX und event-on-update-reading:


define Licht EIB 0/0/1 0/0/2
attr Licht EIBreadingX 1
attr Licht event-on-update-reading getG2


Vielleicht hat ja jemand Verwendung dafür bzw. kopiert es ins WIKI.

lG
Wolfgang

Michael Schmidt

Perfekt vielen Dank danach suche ich schon eine Weile :)

Habe allerdings noch ein weiteres Problem.

Ich Habe eine Sollwertvorgabe im FHEM realisiert.
Der Sollwert (genauer die Verschiebung) wird per FHEM Dummy und notify versendet.

wenn ich nun aber am Regler im Raum (in diesem Fall Büro) die Solltemperatur verändere,
möchte ich das auch in FHEM die neue Temperatur im Dummy geupdated wird.

hast du (oder jemand anderes :) )eine Idee wie das zu realisieren ist


Hier mal der code für die Sollwertverschiebung des Dummy
define noti_buero_temperaturauswahl notify dum_buero_temperaturauswahl {\
if ("$EVENT" eq "16") { fhem "set com_buero_sollwertverschiebung value -8" }\
elsif ("$EVENT" eq "17") { fhem "set com_buero_sollwertverschiebung value -6" }\
elsif ("$EVENT" eq "18") { fhem "set com_buero_sollwertverschiebung value -4" }\
elsif ("$EVENT" eq "19") { fhem "set com_buero_sollwertverschiebung value -2" }\
elsif ("$EVENT" eq "20") { fhem "set com_buero_sollwertverschiebung value 0" }\
elsif ("$EVENT" eq "21") { fhem "set com_buero_sollwertverschiebung value 2" }\
elsif ("$EVENT" eq "22") { fhem "set com_buero_sollwertverschiebung value 4" }\
elsif ("$EVENT" eq "23") { fhem "set com_buero_sollwertverschiebung value 6" }\
elsif ("$EVENT" eq "24") { fhem "set com_buero_sollwertverschiebung value 8" }\
        elsif ("$EVENT" eq "26") { fhem "set com_buero_sollwertverschiebung value 12" }\
}
attr noti_buero_temperaturauswahl alias Temperaturauswahl Büro
attr noti_buero_temperaturauswahl group Logiken
attr noti_buero_temperaturauswahl room Logiken

define dum_buero_temperaturauswahl dummy
attr dum_buero_temperaturauswahl alias Solltemperatur
attr dum_buero_temperaturauswahl group Heizung
attr dum_buero_temperaturauswahl room 5 Büro
attr dum_buero_temperaturauswahl setList state:16,17,18,19,20,21,22,23,24,26
attr dum_buero_temperaturauswahl webCmd state

define com_buero_sollwertverschiebung EIB 3/4/4
attr com_buero_sollwertverschiebung IODev KNX
attr com_buero_sollwertverschiebung group Heizung
attr com_buero_sollwertverschiebung model dpt6.010
attr com_buero_sollwertverschiebung room hidden


Gruß

ZeitlerW

Hallo Jensmaier2,

ich würde da was mit DOIF machen z.b.

define doif_buero_temperaturauswahl DOIF ([dum_buero_temperaturauswahl])(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl])*2-20})
attr doif_buero_temperaturauswahl do always


Dann würde ich EIBreadingSender setzen, damit die die Physikalische Adresse des RTR auswerten kannst und es zu keinem Kreisläufer kommt. Außerdem ist es hilfreich wenn du den Wert der Temperaturverschiebung als userReading hast:
z.B. wenn die PA 6.6.6 ist:

attr com_buero_sollwertverschiebung userReadings wert {ReadingsNum("com_buero_sollwertverschiebung","state",0)}
attr com_buero_sollwertverschiebung EIBreadingSender 1
define doif_buero_rtr_update DOIF ([com_buero_sollwertverschiebung:sender] eq "6/6/6") (set dum_buero_temperaturauswahl  {([com_buero_sollwertverschiebung:wert])/2+20})
attr doif_buero_rtr_update do always
attr dum_buero_temperaturauswahl event-on-change-reading state

.. ungetestet  :)

... Achtung ich habe am 07.01. 19:00 Änderungen gemacht

lG
Wolfgang

Michael Schmidt

Hallo Wolfgang

Vielen vielen DANK für die Hilfestellung

Hinter den doif Syntax bin ich nun gestiegen und
define doif_buero_temperaturauswahl DOIF ([dum_buero_temperaturauswahl])(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl])*2-20})
attr doif_buero_temperaturauswahl do always

hat meine fhem.cfg direkt 100 Zeilen verkleinert.
Manchmal fehlt einfach nur der richtige Denkanstoß :)

jedoch kommt bei einer Sollwertänderung am RTR nicht die sollwertverschiebung zurück sondern es wird auf Gruppenadresse 3/3/4
die Solltemperatur (vollständig 2byte) gesendet.

wäre dann folgendes richtig?
define doif_buero_rtr_update DOIF ([com_buero_sollwert:sender] eq "3/3/4") (set dum_buero_temperaturauswahl  {([com_buero_sollwert:wert])})


Ich versuche vergeblich etwas über EIBreading Sender rauszufinden.
Alles was ich finden kann ist dass das Attribut sehr neu ist (08/2015).

hast du eine Dokumentation oder syntax und Optionen für das command?

Der FHEM scheint ja leider allgemein nicht sehr knx lastig zu sein :(



Gruß
Michael


ZeitlerW

Hallo Michael,

wenn die Solltemperatur zurück kommt würde ich es wie folgt machen

define com_buero_sollwert EIB 3/3/4
attr com_buero_sollwert model tempsensor
attr userReadings wert {ReadingsNum("com_buero_sollwert","state",0)}

define doif_buero_rtr_update DOIF ([com_buero_sollwert])(set dum_buero_temperaturauswahl [com_buero_sollwert:wert])
attr doif_buero_rtr_update do always

attr dum_buero_temperaturauswahl event-on-change-reading state



Beschreibung:

Device anlegen für den Sollwert der Raumtemperatur
Modell tempsensor
Da die immer mit °C kommt UserReading wert anlegen

DOIF anlegen damit das Dummy dum_buero_temperaturauswahl den richtigen Wert bekommt

Dem Dummy noch das Attribut  event-on-change-reading state verpassen, damit bei der Bedienung und der späteren Rückmeldung keine Kreisläufer entstehen.


... zum Thema EIBreading.

Hier kannst du in einem Reading die Physikalische Adresse des EIB - Devices anzeigen lassen. Leider ist die Syntax etwas veschoben, so daß die Adresse in der Gruppenadress - Notation angezeigt wird (x/x/x) anstatt (x.x.x).
Die Idee war, die Physikalische Adresse des RTR auszuwerten um diese von der Physikalischen Adresse des FHEM (0/0/0) zu unterscheiden. Ist aber eigentlich nicht notwendig.

p.s.

Das Konstrukt {([])} im DOIF ist nur notwendig wenn du rechnen willst.


ZitatDer FHEM scheint ja leider allgemein nicht sehr knx lastig zu sein :(

Dank Andi hat sich da sehr viel verbessert.
Außerdem, je mehr mitmachen desto KNX - lastiger wird es :)

lG
Wolfgang


Andi291

Hallo Wolfgang,

danke für die Blumen :-)

Zum Eingangsposting - so ganz stimmts ja leider nicht. State ändert sich ebenso, wenn getG1 kommt, nicht nur wenn getG2 kommt. So werden zum Beispiel Icons über beide GA umgeschalten.
Aktuell zeige ich bei Aktionen immer erst ein Warte-Icon. Erst über die Rückmeldeadresse wird der Zustand zugesteuert. Das haut so leider nicht hin...

Aber ein Interessanter Ansatz, den Du hier beschreibst...

Was wäre, wenn das Reading state bei der Angabe von mehreren GA nicht auf die erste hört? Aber auf welche dann? Nur auf die zweite? Auf alle ab der Zweiten?
Fragen über Fragen - muss ich mal in Ruhe drüber nachdenken...

Meinungen?

Grüße, Andi

Groej

Moin,

cool Danke wollte gerade ein Thema wegen Status am KNX aufmachen und da seh ich doch beim suchen diesen Eintrag.

Ich habe das Problem das ich auf den KNX Bus eine Timerfunktion habe die alle Lampen in der Garage für 10 Minuten einschaltet wenn das Garagentor geöffnet wird über den Funksender. Problem ist nun das die Timerfunktion eine eigene Gruppennummer hat und wenn diese geschaltet wird der Status der Lampen im FHEM nicht geändert wird halt weil die Rückgabe-/Statusgruppe für das Device fehlt.
Ich setze gerade alles von knxWeb und linknx um auf FHEM. Jetzt bekomm ich bestimmt gleich wieder haue wenn ruediger das liest aber im linknx kann man dem Object einen Listener zu ordnen über den dann der Status angezeigt wird. Sowas fehlt leider im FHEM oder ich hab es halt noch nicht gefunden. KNX hat nun mal die schöne Funktion die Logik teilweise selbst zu machen ohne einen Rechner der es steuert. Klar könnte ich das ganze auch im FHEM nachbilden aber wenn der Rechner mal nicht läuft wären diese Funktionen weg.

Im linknx sieht das wie folgt aus. Nur ein Beispiel !! :)

<object type="1.001" id="garage_wand" gad="0/0/1" init="request">Garage Lampen Wand
            <listener gad="0/1/0" read="true"/>
        </object>

Vielleicht kann man so etwas im FHEM einbauen als attr wie gesagt falls es sowas nicht geben sollte. Vielleicht hab ich es nur nicht gefunden bis jetzt.

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Andi291

Morgen!

Nene, Haue kriegst so schnell nicht.
Im Prinzip dürfte das leicht machbar sein - dafür ist FHEM ja da. Ich komme mit den Rahmenbedingungen/der Fragestellung nicht klar.

Ich nehme an, Du hast...:

1. eine GA, welche die Lampen dauerhaft schaltet (wäre dann 0/1/0 ???)
2. eine GA, welchen den Timer startet
3. eine GA, über welchen der Timer "Ausgang" die Lampen auf Zeit schaltet

Richtig? Oder willst Du FHEM als Zeitgeber einsetzen?

Grüße, Andi

ZeitlerW

Hallo Andi,

da hast Du schon recht, daß sich der state auch mit getG1 ändert.
Da habe ich mich wohl falsch ausgedrückt. Mich hat eigentlich die Anzeige in FHEM - WEB gestört und die wird ja durch einen Event des Devices getriggert.

Es muß eher heisen: Anzeige in FHEM - Web soll sich erst ändern wenn Rückmeldung kommt.

ZitatSo werden zum Beispiel Icons über beide GA umgeschalten

... also bei mir funktioniert es so wie im Eingangspost beschrieben

ZitatAktuell zeige ich bei Aktionen immer erst ein Warte-Icon

Wie hast Du das realisiert?


Zu state:

IMHO sollte sich state schon immer ändern, man hat ja auch eine Bedienung durchgeführt. Mit der Rückmeldung ändert sich dann state eigentlich nicht mehr (oder halt doch wenn die Rückmeldung unterschiedlich ist).
Da ich in meine Logiken immer nur ein Event auslöse, wenn sich getGx ändert ist für mich eigentlich alles o.k.
Wenn man allerdings in einer Logik nicht Event - getriggert den state ausliest, so hat man allerdings je nach Anwendungsfall den "falschen" Wert. Da muß man halt nicht den state, sondern das Reading getGx auslesen.
... oder habe ich da was übersehen?

lG
Wolfgang

Groej

Hallo Andi,

also sieht wie folgt aus:

eine Gruppe Lampen rechts
eine Gruppe Lampen links
eine Gruppen Treppenlicht alle Lampen

eine Gruppe Lampen rechts Status
eine Gruppe Lampen links Status

Der Aktor hat die Treppenlichtfunktion (Timer) der einfach dann angesprochen wird um die Timerfunktion zu aktivieren. Wird dieser aktiviert werden die Status Gruppen entsprechen mit gezogen. Die Funktion liegt wie geschrieben im Aktor und nicht im FHEM und dadurch wird der Status der Lampen im FHEM nicht geändert. Weil im KNX auch nicht die einzelnen Gruppen der Lampen (ein/aus) angesprochen werden sondern nur die Gruppe Treppenlicht die aber die Statusgruppen ändert.

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Michael Schmidt

Danke nochmal Wolfgang für die Erleuterungen, nun habe ich vermutlich schon 90% des userreading syntax verinnerlicht. :)

Ich bin nun soweit, dass die Temperatur wenn sie als soll vom rtr zurückkommt auf dem dummy als setstate geschrieben wird.
auch die verschiedenen betriebsmodi haben nun Anwendung gefunden (der RTR hat feste sollwertverschiebungen für diese modis).

das funktioniert auch recht prima bis ich den Betriebsmodus wechsel dann kommt es zu einer schleife.
Scheinbar löst das setstate dum_buero_temperaturauswahl trotzdem ein Ereignis aus welches das doif_buero temperaturauswahl DOIF auslöst.

EDIT Scheinbar lösen die DOIF Bedingungen [dum_buero_temperaturauswahl] sowie [betriebsmodus] jeweis auch allein das DOIF aus!?

hast du eine Idee ob das so soll?
Kann ich den Syntax der 3 DOIFS mit DOELSEIF zusammenfassen?

Danke schonmal im Vorraus

Gruß
Michael

define doif_buero_temperaturauswahl_komfort DOIF ([dum_buero_temperaturauswahl] and [betriebsmodus] eq "1")(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl]-20)*2})
attr doif_buero_temperaturauswahl_komfort do always

define doif_buero_temperaturauswahl_standby DOIF ([dum_buero_temperaturauswahl] and [betriebsmodus] eq "2")(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl]-18)*2})
attr doif_buero_temperaturauswahl_standby do always

define doif_buero_temperaturauswahl_standby DOIF ([dum_buero_temperaturauswahl] and [betriebsmodus] eq "3")(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl]-16)*2})
attr doif_buero_temperaturauswahl_standby do always


define dum_buero_temperaturauswahl dummy
attr dum_buero_temperaturauswahl alias Solltemperatur
attr dum_buero_temperaturauswahl group Heizung
attr dum_buero_temperaturauswahl room 5 Büro
attr dum_buero_temperaturauswahl setList state:16,17,18,19,20,21,22,23,24
attr dum_buero_temperaturauswahl webCmd state

define com_buero_sollwertverschiebung EIB 3/4/4
attr com_buero_sollwertverschiebung IODev KNX
attr com_buero_sollwertverschiebung EIBreadingSender 1
attr com_buero_sollwertverschiebung group Heizung
attr com_buero_sollwertverschiebung model dpt6.010
attr com_buero_sollwertverschiebung room hidden
attr com_buero_sollwertverschiebung event-on-change-reading state

define doif_buero_temp_update DOIF ([com_buero_sollwert]) (setstate dum_buero_temperaturauswahl {([com_buero_sollwert:wert])})
attr doif_buero_temp_update do always
attr doif_buero_temp_update event-on-change-reading state

define com_buero_sollwert EIB 3/3/4
attr com_buero_sollwert IODev KNX
attr com_buero_sollwert group Heizung
attr com_buero_sollwert model tempsensor
attr com_buero_sollwert room hidden
attr com_buero_sollwert userReadings wert {ReadingsNum("com_buero_sollwert","state",0)}
 

ZeitlerW

Hallo Michael,

da müßtest Du es so machen:

define doif_buero_temperaturauswahl_komfort DOIF ([dum_buero_temperaturauswahl] and [betriebsmodus] eq "1")
(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl]-20)*2})
DOELSEIF ([dum_buero_temperaturauswahl] and [betriebsmodus] eq "2")
(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl]-18)*2})
DOELSEIF ([dum_buero_temperaturauswahl] and [betriebsmodus] eq "3")
(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl]-16)*2})


Dann kommt es max zu einem Schleifendurchlauf.


zu den Userreadings: Mittlerweile habe ich gelernt, daß DOIF auch mit Einheiten leben kann: http://fhem.de/commandref_DE.html#DOIF_Nutzung_von_Readings_Stati_oder_Internals_im_Ausfuehrungsteil. Du könntest anstatt eines Userreadings im Device auch im DOIF  [com_buero_sollwert:state:d] nutzen.


lG
Wolfgang

Michael Schmidt

Danke Wolfgang
Das ist ja echt Komplex mit dem RTR ;D

Ich habe den Auslöser für die schleife gefunden.

Das DOIF wir auch von der Änderung des betriebsmodus ausgelöst.
Eigentlich ist das and doch richtig gesetzt oder?

DOIF ([dum_buero_temperaturauswahl] and [betriebsmodus] eq "1")
(set com_buero_sollwertverschiebung value {([dum_buero_temperaturauswahl]-20)*2})


Gruß
Michael

ZeitlerW

Hi,

mache mal [?betriebsmodus] eq "1". Damit der Betriebsmodus - Event nicht ausgewertet wird.

... ja, da hab ich bei meinen RTRs auch ein wenig pfuschen müssen.

Ich kann ja mal meine Konfig posten:

define Wohnzimmer_Heizung_Sollwert dummy
attr Wohnzimmer_Heizung_Sollwert devStateIcon .*.:rc_BLANK:noFhemwebLink
attr Wohnzimmer_Heizung_Sollwert event-on-change-reading state
attr Wohnzimmer_Heizung_Sollwert group Wohnzimmer_Heizung
attr Wohnzimmer_Heizung_Sollwert room Wohnzimmer
attr Wohnzimmer_Heizung_Sollwert setList state:slider,16,0.5,30,1
attr Wohnzimmer_Heizung_Sollwert webCmd state
define DI_Wohnzimmer_Heizung_Sollwert DOIF ([Wohnzimmer_Heizung_RM_Sollwert_Terrassenseite])(set Wohnzimmer_Heizung_Sollwert [Wohnzimmer_Heizung_RM_Sollwert_Terrassenseite:wert])
attr DI_Wohnzimmer_Heizung_Sollwert do always
attr DI_Wohnzimmer_Heizung_Sollwert group Wohnzimmer_Heizung
attr DI_Wohnzimmer_Heizung_Sollwert room Automatik
define DI_Wohnzimmer_Heizung_Sollwert_Visu DOIF ([Wohnzimmer_Heizung_Sollwert] and [?Wohnzimmer_Heizung_Komfortbetrieb] eq "on" and [?Wohnzimmer_Heizung_sperren] eq "off")\
(set Wohnzimmer_Heizung_Sollwert_Komfort value [?Wohnzimmer_Heizung_Sollwert])\
DOELSEIF ([Wohnzimmer_Heizung_Sollwert] and [?Wohnzimmer_Heizung_Nachtbetrieb] eq "on" and [?Wohnzimmer_Heizung_sperren] eq "off")\
(set Wohnzimmer_Heizung_Sollwert_Komfort value {([?Wohnzimmer_Heizung_Sollwert])+3})\
DOELSEIF ([Wohnzimmer_Heizung_Sollwert] and [?Wohnzimmer_Heizung_sperren] eq "off")\
(set Wohnzimmer_Heizung_Sollwert_Komfort value {([?Wohnzimmer_Heizung_Sollwert])+2})\
DOELSE
attr DI_Wohnzimmer_Heizung_Sollwert_Visu cmdState Komfort|Nacht|Tag|gesperrt
attr DI_Wohnzimmer_Heizung_Sollwert_Visu do always
attr DI_Wohnzimmer_Heizung_Sollwert_Visu group Wohnzimmer_Heizung
attr DI_Wohnzimmer_Heizung_Sollwert_Visu room Automatik

lG
Wolfgang

Michael Schmidt

Super es läuft
Das ? war die Lösung! ;)

vielen Dank Wolfgang

Hast du das alles durch ausprobieren herausgefunden oder steht dir eine bessere DOKU zur verfügung  :D

Gruß
Michael


ZeitlerW

Hi,

naja in der Doku von DOIF und EIB findet man das eigentlich.
... aber ich habe seit kurzem einen WIKI - Account - und wenn ich mal Zeit habe ...

vG

Andi291

Hallo Jörg,

dann brauchst Du eigentlich gar nichts machen. Die "Status"-GA werden nicht mitgezogen, sondern der Aktor signalisiert hierüber (mit an Sicherheit grenzender Wahrscheinlichkeit), dass er über EINE seiner Eingangsadressen ein ein- oder aus bekommen hat.

Ich nehme an:
1/1/1 eine Gruppe Lampen rechts
1/1/2 eine Gruppe Lampen links
1/1/0 eine Gruppen Treppenlicht alle Lampen

1/2/1 eine Gruppe Lampen rechts Status
1/2/2 eine Gruppe Lampen links Status

Was willst Du jetzt in FHEM realisieren? Es bietet sich an:

define links_dauer EIB 1/1/1
define rechts_dauer EIB 1/1/2
define beide_zeit EIB 1/1/0

Machst Du es jetzt so:

define links_dauer EIB 1/1/1 1/2/1
define rechts_dauer EIB 1/1/2 1/2/2

hast Du den Nachteil, dass links_dauer und rechts_dauer auch auf ein stehen, wenn über beide_zeit eingeschalten wird.
Ist irreführend...

Grüße, Andi


Andi291

Hallo Wolfgang,

realisiert habe ich heute über

xx_steuern
xx_status
xx_combined

und synchronisiere über Notify. In der Normalansicht ist nur xx_combined, die anderen beiden sind versteckt.
Ist aufwändig und unschön, darum finde ich Deinen Ansatz so gut...

Was hälst Du von einem Regex, über welchen abgefragt wird, was in den "state" eingeht?
Also im Normalfall .*, in meinem Fall (vereinfacht) getG[^1] - damit wäre die erste GA dann quasi ein reines "steuern", kein Status. Ist aber auch nicht der Heilbringer, weil damit komm ich über devStateIcon nicht weiter...

Ich schau mal, was über state Format zu holen ist...

P.S.:
Sinn der Übung - Ich arbeite recht viel mit Sperren und Zwangsrückfall. Wenn jetzt über xx_steuern eine 1 reinkommt, aber das Objekt gesperrt ist, steht die Visu natürlich auf 1, obwohl der Aktor in diesem Fall noch nicht geschalten hat.

Grüße, Andi

Groej

Hallo Andi,

ich beschreibe mal was im FHEM passiert. Alle GAs sind im FHEM eingetragen also die Status GA´s sowie die GA´s der Aktorenausgänge sowie die GA der Treppenlichtfunktion. Alles was ich jetzt schreibe hab ich über die Kommandozeile von FHEM geschaltet.

Wenn ich die GA des Treppenlichtes auf on setzte werden die Status GA´s auch auf on gesetzt aber nicht die GA´s der Aktorenausgänge.
Wenn ich die GA´s der Aktorenausgänge auf on setzte werden auch die Status GA´s auf on gesetzt.

Der Aktor sendet also keine Änderung über die GA´s der Ausgänge wenn die Treppenlichtfunktion zum einschalten genutzt wurde. Die Status GA´s werden immer mit gezogen.

Ich muß also irgendwie den Status GA auf das Device im FHEM kopieren. Klar geht ja mit FHEM kopiere ja auch Temperaturwerte in andere Dummys aber bau ich mir dann nicht unnötig Schleifen ein? Wird über das Treppenlicht eingeschaltet und kopiere ich den Status auf das Device des Aktors würde FHEM den Status ja weiter geben auf den KNX Bus und dadurch das Dauerlicht aktiviert werden? Oder denk ich jetzt zu kompliziert?

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Groej

Irre ich mich jetzt oder behandeln wir gerade zwei Themen in einem Thema hier? Einmal das eigentliche Thema Status im KNX und einmal RTR Rückgabe?

Na hoffenltich kommen wir da nicht durcheinander :)

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Andi291

Hallo Jörg,

das wirst Du nur mit Probieren schwerlich rauskriegen...

Das kommt auf Aktor und dessen Parametrierung an. Ich mutmaße, Du hast einen leichten Denkfehler - die Status-GA entsprechen dem "Aktorenausgang" also dem physikalischen Zustand der Lampen.
Die anderen drei sind Eingange, die untereinander keine Beziehung haben.
Zumindest hätte ich das so parametriert :-)

Willst Du im FHEM also nur den Status der Lampen, dann nimm die beiden Status-GA und konfigurier das Teil als dummy. Wenn Du beide GA bei der Def angibst, dann hast Du quasi Leuchte_any...

Ganz überdimensioniert wäre jetzt ein Dummy-device anzulegen, über WebCmd 1/0/Zeit anzuzeigen und über notify in die EIB-Objekte reinzusynchrinisieren.

Kommt halt drauf an, was Du machen willst...Was ist Dein Ziel? Reine Anzeige? Ansteuerung auf Zeit? Ansteuerung Dauer? Einzeln? Beide? ???

Schleifen kannst Du grundsätzlich vermeiden, wenn Du mit Change-on-event-reading, Change-on-update-reading oder wie beschrieben mit dummy-Objekten arbeitest...


Grüße, Andi


Groej

Hallo Andi,

ich möchte das die Lampen FHEM auch als on angezeigt werden wenn diese über das Treppenlicht eingeschaltet wurden. Im Moment werden diese nur als on angezeigt wenn sie auch direkt ( GA der Aktorenausgänge ) im FHEM bzw. am KNX Bus selbst geschaltet wurden.

Wenn ich die Treppenlichtfunktion nutze wird im FHEM zwar das Device der Status GA geändert aber nicht das Device des Aktors selbst. Ich werde am Aktor bzw. im KNX Bus nicht ändern weil da läuft alles. Die LED´s im Schalter gehen an und aus wie sie sollen. Egal ob Treppenlichtfunktion oder direkt schalten der Lampen. Sowie das ich den Taster nicht zweimal drücken muss um diese aus zu schalten wenn sie über das Treppenlicht eingeschaltet wurde.Dafür gibt es ja die Status GA´s auf den Bus.

Werd mal sehen ob bzw. wie ich da was basteln kann.

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Andi291

Werf mal die ETS Freeware mit nem Gruppenmonitor an - ich bin mir fast sicher, dass die Statusadressen immer auf 1 gehen, wenn die Lampen ein sind...

Groej

Hallo Andi,

klar gehen die Statusadressen auf 1. Hab ich ja auch so geschrieben aber im FHEM hab ich ja zum schalten nicht die Statusadressen sondern die GA´s des Aktorausgangs und darum werden die Lampen im FHEM nicht auf on gesetzt wenn ich diese über die Treppenlichtfunktion einschalte.

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Andi291

Morgen!

Jetzt hab ich Dich. Von schalten wollen hast Du nichts geschrieben :-)

Ich nehme an:

links_steuern 1/1/1
rechts_steuern 1/1/2
beide_zeit_ein 1/1/10
links_status 1/10/1
rechts_status 1/10/2

Dann brauchst:

define links EIB 1/1/1 1/10/1
define rechts EIB 1/1/2 1/10/2


Damit steuerst Du die Lampen auf dauer-Ein. Wird über die Zeitfunktion eine RM ausgelöst, zieht die zweite GA.
Willst DU noch zusätzlich die Zeitfunktion, dann:

define zeit EIB 1/1/10

oder:

define zeit EIB 1/1/10 1/10/1 1/10/2

Die zweite Funktion ist nicht ganz korrekt - sie schaltet die Zeitfunktion, geht aber auch auf ein, wenn eine der beiden Lampen über dauer-ein aufgefangen wird.

Das war übrigens der allererste Post in diesem Thread :-)

Grüße Andi

P.S.: Theoretisch ist es auch denkbar, alle Funktionen in einem Objekt zu verstecken. Geht dann aber nur über notify. Würd ich Dir für den Einstieg nicht empfehlen...

Groej

Moin Andi,

Danke für die Anwtort. Sorry den Teil hatte ich wohl vergessen bzw. einfach gedacht das wäre klar :).

Lese ich das richtig das ich einfach nur die Status GA hinten anhängen muß? Boa is das einfach.

Danke werde ich heute Nachmittag gleich mal testen Jetzt gehts erstmal weg vom Schreibtisch zum Sport :).

Eine kleine Frage hab ich aber noch. Ich hab dazu auch schon ein paar Einträge gefunden aber irgendwie fruchtet nichts. Ich binde FHEM an den KNX Bus über EIBD mit einen KNX IP Router. Auch ich hab das Problem das Meldungen im FHEM doppelt kommen aber nur im FHEM. Im Gruppenmonitor vom ETS ist es nicht Doppelt zu sehen. Ich denke stark das liegt an EIBD oder kommt das wirklich aus FHEM? Sollte ich vielleicht auf KNXD umsteigen? Da hatte ich aber Probleme bei der Installation und bin darum wieder auf EIBD gegangen.

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

ZeitlerW

Hallo Groej,

siehe Problem und Lösung hier: http://forum.fhem.de/index.php/topic,46048.0.html

@Andi, Was stört Dich eigentlich daran, daß state sich geändert hat aber kein Event getriggert wurde.


... EDIT: Wenn es Euch recht ist, würde ich das Thema schließen. Macht doch für die weiteren Probleme neue auf.

lG
Wolfgang

Andi291

Hallo Wolfgang,

klar - bitte schließen! Für den Rest hatte ich Dir eine PN geschrieben...

Mich stört eigentlich gar nichts, aber mit Deinem EIngangsposting hast Du mich (weil betriebsblind :-)) auf eine Idee gebracht, wie ich meine Logiken signifikant verschlanken könnte.
Nur ist die Zielvorstellung ist noch nicht so ganz ausgegoren...

Grüße, Andi

ZeitlerW

Hi Andi,

ich hab deine PM gelesen ... aber noch nicht verstanden :)

Ich melde mich wieder. Heute mußte ich ein wenig fürs Geschäft machen.

Bitte bei Bedarf neue Themen aufmachen.

lG
Wolfgang