FHEM Forum

Hallo,
Ich nutze derzeit nur FS20-Komponenten (über einen CUL an der FritzBox 7390 mit FHEM 5.5). Außerdem lausche ich auf MAX!-Heizungskomponenten über einen weiteren CUL (nur "lesen").
An Homematic gefällt mir, das es Rückkanäle gibt.
Kann ich jetzt unter FHEM auch über meinen FS20-CUL Homematic parallel steuern (Mischbetrieb)?
Unterstützt FHEM (und auch die iOS-App FHEMobile) standardmäßig Homematic (zumindest einfache Geräte wie Schalter und Dimmer)?
Würde FHEM Befehle eigentlich wiederholt senden, wenn der Aktor diese nicht bestätigt?

Danke für euren Input.

Hi,

kurze Frage kurze Antwort: nein

Grüße

Er hat eigentlich 3 Fragen gestellt und die Antworten lauten:
nein,
ja,
nein

Etwas länger:
Nein, man kann einen CUL nicht für HM und FS20 zugleich verwenden. Für HM einen weiteren CUL kaufen oder einen HMLAN-Konfigurator, der übers Netzverbunden wird.

Ja, Fhem kennt viele HM Geräte und unterstützt diese, in der Regel ist der Umgang aber wegen des Pairing-verfahrens etwas komplizierter als FS20

Nein, Fhem sendet nicht automatisch neu, kann man aber natürlich coden. Tatsächlich ist der Rückkanal in vielen Fällen weniger nützlich als man zunächst denkt. HM hat aber andere Vorteile, insbesondere etwas besser Funkreichweite  und schnellere Datenübertragung sowie etwas höhere Sicherheit.

Würdet ihr denn einen CUL oder eher den HMLAN-Konfigurator empfehlen?
Kann ich denn überhaupt einen dritten CUL betreiben?

Prinzipiell kannst du einen 3. CUL (auch einen 4. oder 5.) betreiben.

Ich denke aber, das die meisten hier eher zu einem HMLAN-Konfigurator raten würden. Der ist billiger und kann  im Gegensatz zum CUL auch diese AES-Geschichte (wichtig für z.b. KeyMatic und anderen Devices die immer im AES Mode arbeiten)

Nachteilig ist ggf. die Anbindung per Netz (kann aber auch ein Vorteil sein, kommt eben drauf an) und die etwas geringeren Debug-Möglichkeiten.

Der große Vorteil der HM-Geräte ist doch eigentlich der Rückkanal, oder? Und dieser wird tatsächlich von FHEM nicht "beachtet"?
Ein
define chkTestOn notify Testschalter:on {\
fhem "set Licht on";;\
}
prüft also nicht automatisch, ob das Licht wirkich angegangen ist? Wie würde man das den mit implementieren?

ZitatDer große Vorteil der HM-Geräte ist doch eigentlich der Rückkanal, oder? 

Nein. (bitte lesen Sie weiter in meinem früheren Post wo ich diese Frage bereits beantwortet habe)

ZitatUnd dieser wird tatsächlich von FHEM nicht "beachtet"?

Das hängt davon ab, was man unter "beachtet" versteht. Fhem erkennt das eintreffen der ACK Medlungen aber autmatisch dann irgendwas machen ist nicht vorgesehen. Und das ist auch gut so. Ich würde doch gerne selber entscheiden was zu tun ist wenn das ACK fehlt: Nochmal schalten (warum soll das jetzt eigentlich mehr erfolg haben als vor 2/10 sekunden?), Alarm ausgeben, was ins Logfile schreiben, eine E-mail senden,  eine anderen Aktor schalten, nix tun?

Zitatprüft also nicht automatisch, ob das Licht wirkich angegangen ist? Wie würde man das den mit implementieren?

In gewisser Weise doch, nämlich kann man sich den Status des Aktors ansehen. Wenn der z.b. "missingAck" sagt, weiss man dass man VIELLEICHT en Problem hat. Und kann dann reagieren oder auch nicht.

Aber beachte, das z.b. die Sendelage von der Funkschnittstelle zum Aktor idR. besser ist als umgekehrt und eine Missing ACK *nicht* heisst, das das Licht z.b. nicht an ist (!)

Es heisst eben nur, das die Rückbestätigung nicht angekommen ist. Hat der Aktor das nicht gesendet? Kann sein. Aber in der Praxis erlebe ich öfters Missing ACKs und das Licht ist trotzdem an.

Man kann in FHEM ausserdem auch (soweit es nicht Batterie gestützte Devices sind) durch einen Befehl den Zustand jederzeit abfragen, das ist auch nettes Feature was mit FS20 oder IT  keinesfalls geht.

Aber wie man die Informationen verarbeitet bleibt einem selber überlassen.

So oder so ist der Rückkanal oft weniger nützlich als man oft denkt. Ich sage damit keineswegs, das er nutzlos ist und man damit nicht etwa nette Sachen machen kann.  Aber der Rückkanal sagt einem eben *nicht*, ob das Licht an ist oder nicht, sondern nur ob
1. der Aktor den Befehl erhalten hat *UND*
2. der Aktor in der Lage war, das ACK zur Funkschnittstelle durch zu bekommen.

Nicht mehr und nicht weniger.

D.H. wenn man das ACK hat ist das Licht mit sehr hoher Wahrscheinlichkeit an (also eben ausser Defekten im Schalter oder so) Aber wenn das ACK fehlt, ist das Licht an oder auch nicht. Zumindest bei mir ist es nach einer Schaltung aber fehlendem ACK eigentlich immer trotzdem an.

Hi,
m.W. unterstützt die AVM-Distribution für die 7390 nur max. 2 CULs.
Rudi schrieb letztens in einem anderen post, dass diese Einschränkung für die Version von fhem.de nicht gelten sollte.

Ich selbst nutze einen CUL für FS20 und einen HMLAN für HomeMatic. Klappt prima.

Den Rückkanal gbt's, und es gibt ein fhem-device "watchdog" mit dem man zB missing-ACK erkennen und zB den Befehl erneut senden kann.
HM gat ausserdem die Vorteile, dass
- der Nachbar -anders als bei FS20- meine Aktoren nicht schalten kann, da sein Sensor/Sender erst an meinem Aktor angelernt werden müsste
- Aktoren viel mehr können als bei FS20. Man kann zB einen on-for-timer direkt im device einstellen, bei Rolladenaktoren Fahrzeiten einstellen und auslesen etc

Mischen von HM und FS20 ist problemlos möglich. Nach der DDefinition sind FS20- und HM-devices ja gleichartig in fhem anzusprechen, v.a. mit notify/at. Lediglich die einzelenen Befehle unterscheiden sich - aber das ist ja bei Aktoren innerhalb FS20 z.T. auch so.

=8-)

Man sieht auch wenn jemand am Aktor manuel z.B das Licht angemacht hat, die Aktion im Fhem über den Rückkanal
auch kann man die Device fragen ob sie noch leben, manche schicken auch selbstständig ein Lebenssignal an Fhem (alle 24 std)
manche Sender schicken auch mehrmals einen Tastendruck nach Fhem wenn die Bestätigung ausbleibt (ACK)
und signalsisieren dies durch ein Leuchtdiode auch,
usw...

Kommt darauf an, was du von derner Steuerung erwartest.

Das Totschlagargument "Ich sehe ja wenn das Licht angeht" find ich doof...

Zitatm.W. unterstützt die AVM-Distribution für die 7390 nur max. 2 CULs.

Okay, die Eigenheiten dieser Distribution hab ich zugegeben nicht ganz auf dem Schirm.

ZitatDas Totschlagargument "Ich sehe ja wenn das Licht angeht" find ich doof...

Das hab ich eigentlich auch nicht gebracht. Oder sagen wir mal nicht mehr in letzter Zeit. Der Rückkanal hat sicher Vorteile ein paar hab ich schon aufgezählt (ich frage z.b. bei Neustart von Fhem den Status der Devices ab, das ist schon nett) und Rückmeldung bei lokaler Bedienung ist auch super... nur trifft das letztlich nur auf Aktoren zu, die lokale Bedienung auch regelmässig vorsehen. Und da Aktor und Sensor/Fernbedienung auch bei HM meistens getrennt sind, ist das je nach Installation vielleicht weniger oft ein Thema als man theoretisch denkt.

Wie dem auch sei, es gibt sicher gute Gründe, HM einzusetzen, ich selber  benutze es ja auch. Aber der Grund, das automatisch so lange versucht wird Licht "on" Befehle zu senden, bis der Aktor ACK sendet, wäre für mich gerade am wenigsten zutreffend, weil meiner Auffassung nach gerade hier der Rückkanal weniger bringt als man denkt.
Da die Erwartung des Threaderstellers aber in diese Richtung ging, wollte ich das ein bisschen dämpfen.

Unbenommen: die Sirene meiner Alarmanlage wird natürlich mit einem HM Aktor betrieben (wegen der von fhem-hm-knecht genannten höheren Sicherheit wegen Pairing), und auch der Schlüsselanhänger mit dem man die Alarmanlage ausmachen kann ist ein HM Sender. Und im Moment suche ich noch nach einem Weg, den Sender dazu zu bringen, die Status LED grün aufleuchten zu lassen, wenn das Unscharfschalten der Alarmanlage erfogreich war (nicht nur der Empfang des Signals durch den HMLAN-Konfig.)

Ich glaube, man muss für jeden Anwendungsfall überlegen, was für einen Aktor man nimmt, je nach Preis/Leistung.

Und um die Stehlampe im Wohnzimmer anzuschalten nehme ich ne billige IT Dose. Da leistet der Rückkanal einfach nix für mich.

Kurzum: Es gibt viele gute Gründe HM einzusetzen, aber der Rückkanal ist aus meiner Sicht nicht der Hauptgrund. Daher:

ZitatDer große Vorteil der HM-Geräte ist doch eigentlich der Rückkanal, oder?

Aus meiner Sicht: Nein.

ZitatUnd im Moment suche ich noch nach einem Weg, den Sender dazu zu bringen, die Status LED grün aufleuchten zu lassen, wenn das Unscharfschalten der Alarmanlage erfogreich war (nicht nur der Empfang des Signals durch den HMLAN-Konfig.)

Das würde ich so nicht unterschreiben

Da kommt es darauf an, wie du die Taste gepeert hast, mit dem Hmlan (nach betateilchensversion) oder Virtueller aktor (MartinP876) ?
Bei Martins version weißt du zumindest, dass es Fhem angenommen hat.

wenn scharf /unscharf über einen Kontakt bei deiner Alarmanlage realisiert wird, würde ich einen Hm aktor direkt anschliesen und die Fernbedienung direkt peeren.

Zitat

ZitatUnd im Moment suche ich noch nach einem Weg, den Sender dazu zu bringen, die Status LED grün aufleuchten zu lassen, wenn das Unscharfschalten der Alarmanlage erfogreich war (nicht nur der Empfang des Signals durch den HMLAN-Konfig.)

Das würde ich so nicht unterschreiben

Verstehe ich nicht? Was würdest du nicht unterschreiben? Das ich einen Weg suche? Oder hast du nur interpretiert ich hätte damit sagen wollen es geht nicht?  ::)

Also:
1. ich habe die Taste mit HMLAN gepeert. Nebenbei: das funktioniert bereits nicht, die LED wird nicht grün, obwohl der Befehl vom HMLAN empfangen und auch weiter ausgeführt wird.
2. Mir ist klar, dass der Umweg über einen Dummy schon mal klärt, dass Fhem es angenommen hat. Das ist schon besser aber noch nicht ganz was ich will.

Ich kenne beide Methoden, die machen aber beide nicht was mir vorschwebt.
Ich will, dass die Lampe grün wird, wenn die Alarmanlage auch echt aus ist.

Zitatwenn scharf /unscharf über einen Kontakt bei deiner Alarmanlage realisiert wird, würde ich einen Hm aktor direkt anschliesen und die Fernbedienung direkt peeren.

Hm. ich denke hier liegt ein Missverständniss vor.

Meine Alarmanlage ist natürlich rein skriptbasiert, da gibt es keinen Aktor der die auschaltet. Sie ist scharf wenn ein bestimmter Dummy auf dem Wert "scharf" steht und unscharf... wenn er auf "unscharf" steht. Der Dummy wird dann von nachfolgenden scripten und notifys ausgewertet.

Die Steuerung erfolgt natürlich so, das die HM FB per define ... notify den Wert dieses Dummys ändert.

Mein Ziel ist es nun, zu testen, ob dieser Dummy tatsächlich auf "unscharf" steht und dann die LED grün aufleuchten zu lassen.

Mir ist bisher noch kein Konstrukt eingefallen, aber ich denke, dass das am Ende nur über einen virtuellen Aktor geht.
Nur ist Martins Methode noch nicht ganz passend, weil dieser Aktor ja nicht den tatsächlichen Schaltzustand der Alarmanlage anzeigen würde. Aber zugegeben, ein:

define Anlag_aus notify VirtuellerAktor:off set Alarmanalge unscharf

lässt relativ wenig Spielraum für Dinge die schief dazwischen gehen können.


Wir werden ein bisschen off topic gerade. Ich wollte die Frage demnächst mal im HM Bereich stellen.

Ich unterschreibe nicht, dass das ACK alleing vom HMlan generiert wird.
Da kommt es auf die Einrichtung darauf an.

ZitatAlso:
1. ich habe die Taste mit HMLAN gepeert. Nebenbei: das funktioniert bereits nicht, die LED wird nicht grün, obwohl der Befehl vom HMLAN empfangen und auch weiter ausgeführt wird.
2. Mir ist klar, dass der Umweg über einen Dummy schon mal klärt, dass Fhem es angenommen hat. Das ist schon besser aber noch nicht ganz was ich will.

sondern? orange oder rot?
orange= Taste nicht gepeert!
rot= Antwort zu langsam oder keine oder aes aktiv, und kein Schlüssel definiert usw
logs erforderlich dann HMgruppe

ZitatWir werden ein bisschen off topic gerade. Ich wollte die Frage demnächst mal im HM Bereich stellen.

jain, es zeigt auch Anregungen, die man mit dem z.B Rückkanal machen kann.

ZitatIch unterschreibe nicht, dass das ACK alleing vom HMlan generiert wird.

Habe ich eigentlich auch nicht behauptet. Ich wollte damit nur andeuten, dass ich den naheligenden und einfachen WEg *nicht* meine. Aber egal, darum geht's ja nicht.

Zitatorange= Taste nicht gepeert!

LED leuchtet bei Tastendruck Orange. Aber: Taste geht. Macht was sie soll und wird von FHEM erkannt. Nicht gepeert trifft also eher nicht zu. Das ist ja das seltsame. Oder ich kapier da was nicht.

Zitatjain, es zeigt auch Anregungen, die man mit dem z.B Rückkanal machen kann.

jo.

ZitatZitat

    orange= Taste nicht gepeert!

LED leuchtet bei Tastendruck Orange. Aber: Taste geht. Macht was sie soll und wird von FHEM erkannt. Nicht gepeert trifft also eher nicht zu. Das ist ja das seltsame. Oder ich kapier da was nicht.

Ich will den Threat nicht entführen  ;D

Pairen heißt: Den ganzen Handsender mit allen Tasten mit Fhem bekannt machen, und Fhem erlauben die internen Register zu beschreiben
und ihn auch zum Chef machen.

Peeren heißt: z.B. Fernbedienung Taste 1 mit aktor xy Chanal 2 zu verbinden und nach Tastendruck kommt grün für ACK oder rot für Misserfolg bzw ACK zu spät.
Orange heißt Meldung an Broadcast, es wird kein ACK erwartet, alla wen es interresiert, Fhem interesiert es. sendet auch kein Ack

Zitat von: UliM am 22 November 2013, 16:04:05
HM gat ausserdem die Vorteile, dass
- der Nachbar -anders als bei FS20- meine Aktoren nicht schalten kann, da sein Sensor/Sender erst an meinem Aktor angelernt werden müsste

Der Punkt ist wohl leider eine Wunschvorstellung. Solange AES nicht aktiviert ist schalte ich Dir jeden Aktor. Nicht umsonst läuft Keymatic nur mit AES.

ZitatIch will den Threat nicht entführen 

Mist schon passiert. Soll ich da mal einen neuen Thread in HM aufmachen?
Ich glaube ich brache da noch etwas Hilfe.

ZitatWürde FHEM Befehle eigentlich wiederholt senden, wenn der Aktor diese nicht bestätigt?

Fhem versucht es 3 mal mit dem Cul
und hmlan 3mal selber und dann noch 3mal Fhem macht 9 mal
und dann erst gibt es einen missing ack

;)