HM_CC-RT-DN WINDOW_SWITCH_RECEIVER

[Dedo]

Hallo zusammen,

hat jemand eine Idee wie man den Window-Status per Script oder Programm setzen/löschen kann?

danke
Dedo

[alchy]

WINDOW_SWITCH_RECEIVER ist der Kanaltyp des Kanal 3 bei dem Gerät.

Alchy

[Familienvater]

Hi,

man kann diesen Kanal nicht setzen oder löschen (zumindest nicht mit einer CCU und Konsorten, angeblich geht das bei FHEM).
Das ist der Kanal, mit dem ein Tür-Fenster-Kontakt per Direktverknüpfung mit dem Thermostat verknüpft wird

Der Familienvater

[Keichi]

Finde ich allerdings komisch, das FHEM das direkt auf dem Gerät setzen kann ein RM allerdings nicht.. Theoretisch sollten wir zu sowas doch auch in der Lage sein, und Werte direkt in die Kanäle schreiben können.

Gesendet von meinem C6903 mit Tapatalk

[Familienvater]

Hi,

die Schnittstellenprozess auf der EQ3-Zentrale kann das, was er können muss: Die Pakete, die zum Empfang auf der Zentrale gedacht sind "dekodieren" und als Event melden, und die Pakete per Funk versenden, die normalerweise von einer Zentrale an Aktoren gesendet werden müssen, wie z.B. Ein/Aus oder Temperaturvorgaben.

Ein Funkpaket "Fensterkontakt wurde geöffnet" ist für mich kein Funk-Paket, was eine Zentrale zwingend versenden können muss, weil das im weitesten Sinn nichts mit einem "SetValue" zu tun hat, außerdem ist damit im Zweifelsfall auch ein "bisschen" Sicherheit gegeben, weil nicht jeder mit einer CCU einfach alle Funkpakete in die Luft blasen kann, Du kannst auch nicht einfach auf dem Telefon einstellen, das der nächste abgehende Anruf von Deinem Handy mit der Rufnummer deines Nachbarn beim Angerufenen signalisiert werden soll (prinzipiell geht das, wer die richtigen SIP-Provider-Zugänge hat, kann sich mit "jeder" Rufnummer melden, aber das ist dann eben soetwas wie FHEM).

Da FHEM eine "fremde" Schnittstellensoftware hat, kann man da im Zweifelsfall alle möglichen zu versendenden Daten anliefern, und die werden dann einfach verschickt. Und FHEM ist OpenSource, da kann sich jeder noch den fehlenden Software-Nöpsi dranprogrammieren, die EQ3-Schnittstellen-Binaries sind closed-Source, da können wir nicht einfach den Software-Nöpsi dranbauen.

Der Familienvater

[alchy]

Das man auch Kanäle "direkt" schalten kann, ist ja ebenso bekannt (z.B. Lichtaktor Kanal statt den STATE Datenpunkt) wie das Vorgaukeln der Statusänderung eines eigentlich nicht beschreibbaren Datenpunktes.

Ich habe so ein Teil nicht, daher spare ich mir die Rumraterei. Auch bin ich nicht in FHEM unterwegs um mich da durchzusuchen.

Alchy

[Keichi]

Hi,

die Schnittstellenprozess auf der EQ3-Zentrale kann das, was er können muss: Die Pakete, die zum Empfang auf der Zentrale gedacht sind "dekodieren" und als Event melden, und die Pakete per Funk versenden, die normalerweise von einer Zentrale an Aktoren gesendet werden müssen, wie z.B. Ein/Aus oder Temperaturvorgaben.

Ein Funkpaket "Fensterkontakt wurde geöffnet" ist für mich kein Funk-Paket, was eine Zentrale zwingend versenden können muss, weil das im weitesten Sinn nichts mit einem "SetValue" zu tun hat, außerdem ist damit im Zweifelsfall auch ein "bisschen" Sicherheit gegeben, weil nicht jeder mit einer CCU einfach alle Funkpakete in die Luft blasen kann, Du kannst auch nicht einfach auf dem Telefon einstellen, das der nächste abgehende Anruf von Deinem Handy mit der Rufnummer deines Nachbarn beim Angerufenen signalisiert werden soll (prinzipiell geht das, wer die richtigen SIP-Provider-Zugänge hat, kann sich mit "jeder" Rufnummer melden, aber das ist dann eben soetwas wie FHEM).

Da FHEM eine "fremde" Schnittstellensoftware hat, kann man da im Zweifelsfall alle möglichen zu versendenden Daten anliefern, und die werden dann einfach verschickt. Und FHEM ist OpenSource, da kann sich jeder noch den fehlenden Software-Nöpsi dranprogrammieren, die EQ3-Schnittstellen-Binaries sind closed-Source, da können wir nicht einfach den Software-Nöpsi dranbauen.

Der Familienvater

Aber genau dafür ist das Anlernen an die CCU doch gedacht. Is ja nun nich so als könnte man irgendeine Fake CCU nehmen, und einfach die Pakete an die Aktoren senden die das dann ausführen. Wenn der Aktor nich genau weiß von wem das Paket kommtr(in dem Fall ja der gespeicherten CCU) nimmt der Aktor den Befehl auch nich an. Deswegen wüsste ich halt nich was dagegen spricht, wenn wir alle Kanäle mit Werten belegen können... In meinen Augen ist das halt eher nen Vorwand von eq3 damit man ihre Hardware auch kauft statt ein reines Sicherheitsmerkmal.

Gesendet von meinem C6903 mit Tapatalk

[Xel66]

Is ja nun nich so als könnte man irgendeine Fake CCU nehmen, und einfach die Pakete an die Aktoren senden die das dann ausführen.

Das hier kennst Du? Wenn nicht, ist es vielleicht interessant. Auch das CCC-Video dazu. BTW: ich nutze keinen eigenen Sicherheitsschlüssel in meiner Standardinstallation.

Gruß Xel66

[Keichi]

Is ja nun nich so als könnte man irgendeine Fake CCU nehmen, und einfach die Pakete an die Aktoren senden die das dann ausführen.

Das hier kennst Du? Wenn nicht, ist es vielleicht interessant. Auch das CCC-Video dazu. BTW: ich nutze keinen eigenen Sicherheitsschlüssel in meiner Standardinstallation.

Gruß Xel66

Ja, das habe ich gelesen nur wie die meisten in dem Thread bin ich der Meinung das es wahrscheinlicher ist im Lotto zu gewinnen als das jemand bei mir das Licht einschaltet oder die Rollos hoch macht.

Ausserdem ist es immer noch keine Begründung wieso die CCU nich alle Kanäle der Aktoren beschreiben darf, weil Technisch is es ja durchaus umsetzbar. Selbst mit separater Verschlüsselung der CCU sollte es dennoch gehen, man erhöht dadurch halt höchstens den Duty Cycle.

Gesendet von meinem C6903 mit Tapatalk

[Familienvater]

Hi,

das, was jeder gerne machen möchte (unterstelle ich jetzt allen mal), ist doch das Thermostat von der Zentrale aus in eine temporäre Absenkung zu schicken, in dem ein offenes Fenster vorgegaukelt wird.
Warum will man das machen? Weil die "richtige" Methode, es per Thermostat in den manuellen Modus mit Temperaturvorgabe umschalten, und später wieder zurück, wesentlich komplizierter ist, dafür hat man aber alle Freiheitsgrade, man muss es nur richtig ausprogrammieren.

Is ja nun nich so als könnte man irgendeine Fake CCU nehmen, und einfach die Pakete an die Aktoren senden die das dann ausführen

Ich will Dich jetzt nicht verunsichern, aber klassisches Homematic ist einfach "Fakebar", ich muss mich z.B. nur mit einem Raspi in die Nähe Deines Hauses stellen, und schon kann ich ALLES was da rumfunkt im Klartext im Syslog des Raspi lesen, inkl. Deiner Zentralenkennung. Ich habe damit vielleicht noch nicht die Zuordnung, welche Funkadresse welche Aktion auslöst, aber es dauert ggf. keine Minute, und ich schalte mit einem Raspi (oder auch einer orignal CCU2) Deine Homematic-Aktoren, außer Du hast die gesicherte Übertragung aktiviert, und nutzt einen individuellen Sicherheitsschlüssel, dann bin ich raus. Aber, das empfehle ich wirklich nur für "kritische" Aktoren, wie z.B. eine Keymatic, sonst handelt man sich mit der gesicherten Übetragung mehr Ärger als nutzen ein.

Ausserdem ist es immer noch keine Begründung wieso die CCU nich alle Kanäle der Aktoren beschreiben darf, weil Technisch is es ja durchaus umsetzbar. Selbst mit separater Verschlüsselung der CCU sollte es dennoch gehen, man erhöht dadurch halt höchstens den Duty Cycle.

Es ist einfach nicht vorgesehen. Der Kanal ist der Empfangspartner für Direktverknüpfungen, und zwar für Direktverknüpfungen vom einem ganz bestimmten Typen (für Zustandsmelder AUF/ZU), deswegen kann man da auch keine Fernbedienung anlernen. Und die CCU kann einfach keine Funkpakete dieses Typs verschicken, die kann höchstens Tastendrücke "faken", um Direktverknüpfungen zu testen.

Der Familienvater