Dann hast Du eine eigene Definition was ein Gateway macht oder machen sollte. Die meisten Gateways dienen nicht nur als Schnittstelle, sondern eben auch einer umfangreichen Automation, die auf dem jeweiligen Gateway selber eingerichtet wird.
Nichts anderes machen andere Gateways auch, diese dienen dazu Geräte abhängig von Ereignissen und dem Status von Geräten zu schalten, diese sind also selber die zentrale Instanz, wie Du das bezeichnest. Der einzige Unterschied ist, dass andere Funkgateways von vorn herein mehrere Funkprotokolle und Funkfrequenzen unterstützten, im Gegensatz zu einer CCU, die vom Hersteller nur darauf ausgelegt ist ausschließlich Homematic / Homematic IP anzusteuern.
Dann hast Du auch hier eine andere Vorstellung von dem was diese Systeme können und leisten. So was wie HomeKit und ähliches dient nicht nur der Fernsteuerung, sondern auch der Automatisierung, die auf dem jeweiligen Endgerät bzw. Betriebssystem eingerichtet wird, was der jeweilige Nutzer benutzt. Genau das was Du beschreibst, nämlich einen Bewegungsmelder vom Hersteller A mit einem einem Aktor vom Hersteller B zu verbinden und zu automatisieren ist mit all diesen Systemen möglich. Der wesentliche Punkt ist das Alexa nichts mit HomeKit anfangen kann und anders herum, und genau das soll matter zumindest in der Therorie ändern.
Ein Skill oder die Sprachsteuerung ist ja immer nur ein Teil der Ansteuerung. Die eigentliche Automatisierung findet aber auch jeweils in dem System statt, was die Geräte ansteuert. Bei iOS werden Automationen eben in der Kurzbefehls App eingerichtet, bei anderen System auch über die jeweilige UI Schnittstelle des Gateways zum Kunden.
Auch wenn Du das in die analoge Welt und Sprache der Menschen überträgst und dort einen Vergleich suchst ist das kein Blödsinn sondern ein Fakt.
Alle Menschen können im gleichen Frequenzbereich hören und in dem Frequenzbereich auch Laute erzeugen um sich zu verständigen. Das einzige was Du brauchst ist eine Sprache, die Du lernen musst um Dein Gegenüber auch zu verstehen. Du kannst Dir aber so viel Mühe geben wie Du willst, Du wirst weder mit Fledermäusen, Walen oder Delphinen kommunizieren können, weil Du den Frequenzbereich alleine gar nicht wahrnehmen kannst und auch keine Laute in dem Frequenzbereich selber ohne Hilfsmittel erzeugen kannst.
Ein Funkgateway kann auch nur nur in dem Frequenzbereich senden, das dieses Funkgateway durch die Hardware eben unterstützt. Die Sprache (Protokoll) ist aber nur einen Frage der Firmware und da kann durchaus jeder Hersteller eine andere Firmware benutzten aber dennoch mit einem Gerät / System kommunizieren können. Ohne das ein Funkgateway aber auch die passende Frequenz unterstützt, kannst Du an der Firmware des Gateways ändern was Du willst, Du wirst nichts in dem Frequenzbereich senden können.
Nur weil Du ausschließlich eine CCU benutzt und Dich damit auskennst ist das deswegen nicht falsch. OEM Hersteller von eQ-3 nutzten nun mal eigene Gateways und teilweise auch eigene Funkchips mit eigener Firmware. Das ist auch der Grund warum sich diese Gateways vom Funkionsumfang unterscheiden, obwohl diese alle Produkte von eQ-3 ansteuern können. Im Fall der AIO Gateway V6 Serie wird zum Beispiel auch kein HM-IP Funkmodul mehr benutzt, sondern ein Funktransceiver von Mediola, der über eine Hersteller eigene Firmware angesteuert wird. Das kannst Du gerne prüfen, indem Du Dir bei Bedarf so ein Gerät anschaffst und in Einzelteile zerlegst, Du wirst kein HM-IP Funkmodul finden.Xel66 hat geschrieben: ↑18.05.2021, 02:33Sorry, auch das ist technisch absolut falsch. Homematic-Geräte würden sich einen Dreck scheren, was das Gateway da aussendet (und maximal den CS nach oben treibt). Aber wenn das Gateway nicht mit dem korrekten Protokoll mit diesen Aktoren und Sensoren spricht, machen die schlicht gar nichts.
Oder Du vertraust einfach darauf was der jeweilige Hersteller zum Funkgateway sagt, der Hersteller selber sollte das ja am besten wissen, was im Funkgateway verbaut ist und wie die Ansteuerung von Homematic IP jeweils erfolgt. Siehe z.B. hier ist die Funktionsweise von einem V6 zur Ansteuerung von Homematic IP von einem Mediola Mitarbeiter beschrieben.
Genau das ist ein Beispiel dafür das unterschiedliche Funkgateways von unterschiedlichen OEM Herstellern auch andere Firmware nutzten.
Bei allen Herstellers die matter unterstützten werden, ist das dann aber letzlich dann egal, dann könnte der Kunde frei wählen was er für ein Funkgateway nutzten will. Da sich aber eQ-3 und auch die OEM Hersteller von eQ-3 zur Zeit nicht an matter beteiligen, ist das zumindest für die Nutzung von Homematic IP zur Zeit auch nicht relevant. Da müsste sich matter erst mal so weit durchsetzten, dass sich eQ-3 und die OEM Hersteller gezwungen sehen auch matter zu unterstützten.
Erstens verwechselt Du da persönlich was, eine Ansteuerung und Automation ist in den Systemen nicht getrennt, eine Ansteuerung ist immer nur ein Teil des Gesamtsystems sowie auch die Sprachsteuerung nur ein Teil des Gesamtsystems darstellt, der wesentliche Teil ist unter anderem auch die Verknüpfungen und Automatisierungen, die in dem jeweiligen System eingerichtet werden, sonst wäre das in der der Tat eine reine alternative Steuerungsmöglichkeit. matter wird doch dazu geschaffen, dass nicht Apple HomeKit nutzt mit Siri als Spracheingabe, und Samsung Bixby usw. sondern das am Schluss der Kunde sich ein Endgerät aussuchen kann, mit dem er egal was für ein Gateway dann ansteuern kann.Xel66 hat geschrieben: ↑18.05.2021, 02:33Vergiss doch endlich mal dieses ganze dumme Steuerungsgeraffel. Automation ist mehr, als vom Wohnzimmersessel oder aus Timbuktu die Leselampe an- und auszuschalten. Hier müssen Aktorik und Senorik über smarte Bedingungen für automatische Abläufe verknüpt werden. Dieses ganze Steuerungsgeraffel funktioniert doch so auch schon. Dazu braucht es keinerlei zusätzliches Protokoll.
Das mag Dir egal sein und vielleicht andern auch, die den Begriff falsch bzw. im falschen Kontext nutzten. Eine Middleware ist wie der Name schon sagt eine Zwischenschicht und ist damit auch nicht übergeordnet. Übergeordnet ist die Anwendungsebene, die der Anwender auch sieht, die Middleware arbeitet im Verborgenen hinter der Anwendungsebene und ist für den normalen Nutzer gar nicht sichtbar.
Siehe
Was ist Middleware
Middleware
Das was Du sehr wahrscheinlich meinst ist ein Hausautomationssystem bzw. Hausautomationssoftware, das ist aber keine Middleware, weil die meisten Systeme eben auch eine Anwendungsebene besitzten, sonnst könnte der Benutzer keine Eingaben machen bzw. das System steuern bzw. zur Visualisierung nutzten. Daher sind solche Systeme auch keine Middleware per Definition, weil diese eine Anwendungsebene besitzten, also auch nicht wie eine typische Middleware zwischen der Anwendung und der Hardware interagieren.
Das ist zumindest das Ziel vieler Hersteller, vor allem von den großen IT Konzernen, die hinter matter stehen, das so ein System in Zukunft aus den Gewohnheiten des Nutzers lernt und viel Prozesse dann automatisch macht, ohne das Du überhaupt etwas davon zwangläufig mitbekommst. Das ist dann ein "Smart" Home, weil das Haus selbstständig mitdenkt und Entscheidungen durchführt, so wie bei einem Auto auch Assistenssysteme automatisch dann greifen, wenn diese benötigt werden.Xel66 hat geschrieben: ↑18.05.2021, 02:33Für Smarthome ist nicht wirklich viel Rechenleistung notwendig. Das kann ein RaspberryPi locker. Und Smarthome wird nie so laufen, dass man Geräte kauft, in Betrieb nimmt und sinnvolle und vor allem vom Anwender gewünschte Automationen erstellen sich wie von Geisterhand.
Das was automatisch erstellt werden kann, wird auch in Zukunft auch automatisch konfiguriert werden, weil das einfach Arbeit abnimmt und nur so auch sich im Markt durchsetzten wird, wenn der Kunde selber keine Arbeit hat, sondern das der Erleichterung im Alltag dient. Und matter dient im Prinzip dazu, dass der Anwender dann eben nicht mehr an ein spezielle App oder Gerät gebunden ist, um persönliche Einstellungen vornehmen zu können.Xel66 hat geschrieben: ↑18.05.2021, 02:33Sicher werden zukünftig einfache Abläufe automatisch erstellt werden können, aber welche Lampe z.B. bei welcher Tasterbetätigung oder welchem Trigger (Anwesenheit, Helligkeit etc.) eingeschaltet oder auf welcher Dimmstufe dieses erfolgen soll, das muss der Anwender auf irgendeine Weise festlegen. Man kann es jetzt noch administrieren nenen und es erfolgt in allen Lösungen noch mehr oder minder "zu Fuß". In Zukunft erfolg sowas vielleicht im Dialog mit dem Anwender, aber festlegen muss er es immer noch.
Soll ich jetzt auch boa ey schreiben, weil Du den Begriff Middleware im Kontext immer falsch benutzt und nicht im Ansatz zu wissen scheinst was so Systeme wie Beispielsweise von Apple HomeKit leisten können, weil Du diese offensichtlich selber gar nicht umfänglich nutzt? HomeKit hat nichts mit Steuerungsquatsch zu tun, sondern ist genau das was Du immer so suchst, nämlich verschiedene Hersteller mit einer Automation zu verknüpfen. Der Nachteil ist aber, dass dies eben nur mit den Herstellern funktioniert, die auch HomeKit unterstützten. Und genau deshalb ist matter geschaffen worden, damit eben nicht der eine das System X nutzt und der nächste wieder etwas anderes, sondern das es statt dessen zumindest in der Theorie einen Application Layer gibt, auf den sich viele der größeren Hersteller geeinigt haben.
Nichts anders hatte ich geschrieben, das matter die typische professionelle Gebäudeautomation zur Zeit weitesgehend außen vor lässt, weil die üblichen Feldbusse, die im professionellen Bereich genutzt werden, zur Zeit gar nicht berücksichtigt werden. Damit ist matter dann höchstens ein weiterer Standard, zusätzlich zu bereits definierten Standards, aber bestimmt nicht der Standard, der am Schluss alles vereint.
An einer SPS ist nichts proprietär, da werden gängige Feldbusse genutzt und diese sind standardtisiert.