Ankündigung

Einklappen
Keine Ankündigung bisher.

Featurewunsch: Relay Funktion für hsfusion

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Featurewunsch: Relay Funktion für hsfusion

    Hi,

    ich habe leider noch keine Lösung für folgendes:
    Ich möchte die Funktionen aus zwei iviewer Projekten (hsfusion und mmh) in einer gemeinsamen GUI nutzen (ohne die App wechseln zu müssen).
    Dazu wird auf Seite von hsfusion eine Relay Funktion benötigt.
    D.h. ich möchte zunächst ganz normal mit hsfusion kommunizieren, der HS soll sich jedoch bei Bedarf, idealerweise bei join oder knx adresse, transparent schalten und die Kommunikation zu mmh weiterleiten (sobald ich eine Multimediaseite aufrufe).

    Ich hatte das hier schonmal beschrieben. https://knx-user-forum.de/94421-post44.html

    So eine Relay-Funktion hat mmh ja bereits implementiert - geht aber auch noch nicht mit hsfusion - https://knx-user-forum.de/m-myhome-m...als-relay.html

    #2
    So wie ich das auf die schnelle dort gelesen habe, wäre das dann quasi ein Proxy, da die Verbindung dann ja iViewer -> HS -> mmh wäre.

    mmh würde die Verbindung ja dann HS erhalten, genau so wäre es umgekehrt.

    Das was du im mmh Forum beschrieben hast, lässt darauf schließen, dass die Verbindung einfach nur durchgereicht wird, ohne das die Initialisierungsprozedur durchgeführt wird.

    Normalerweise müsste dieser Wechsel eigentlich im iViewer gemacht werden. Da gibts doch auch irgendwas.Da kann man irgendwie mittels cf:// ein weiteres GUI File verlinken.
    Nils

    aktuelle Bausteine:
    BusAufsicht - ServiceCheck - Pushover - HS-Insight

    Kommentar


      #3
      auch wenn ich keine - im Sinne von überhaupt keine - Idee habe, wofür das gut sein soll, wäre es IMHO schon möglich, dass über das KO-GW zu realisieren.
      mmh ist in der Lage sich das gesamte Prozessabbild über das KO-GW zu besorgen.
      Somit wären dann beide System stets aktuell.

      Weiter gibt es in CF die Möglichkeit, per Link den GUI-Server zu wechseln und dabei in einer GUI-Oberfläche zu bleiben. Somit ist ein Zugriff auf mehrere Projekte möglich. Zugegeben die Umschaltzeit ist eher unsexy....

      Aber erkläre doch bitte noch mal warum Du das willst und was das bringen soll und wo der Vorteil ist, zwei Systeme zu pflegen......... Das habe ich irgendwie noch nicht verstanden.
      Gruß Christian

      Kommentar


        #4
        Vielleicht besteht das Problem auch in meinem Kopf und ich brauche etwas Nachhilfe ;-)

        für hsfusion spricht:
        ich möchte meine Visu weiterhin auf Basis von hsfusion nutzen. Das ist meines Erachtens nun wirklich bullet proof und ausreichend ausfallsicher. Ich kann darüber hinaus ohne Umwege direkt an iKOs und Logik.
        Oder kann ich mit mmh auch direkt IKOs im HS ansteuern?

        für mmh spricht:
        Manche Seiten (iTunes Steuerung) sind ja schon komplett in mmh fertig, die würde ich auch so gern weiter nutzen. Das kriege ich ja nur schwer in hsfusion integriert, oder?
        Mmh läuft zwar sehr stabil, aber das Gesamtsystem wäre mir insgesamt zu anfällig.

        Ich habe nun gedacht, dass es am sinnvollsten ist zwischen beiden Welten hin- und herzuschalten und zwar ohne die App wechseln zu müssen.

        PS:
        Dann erstelle ich gerade Visuseiten, die auf beide Systeme zugreifen würden (Grundrissplan). Wie komme ich am einfachsten mit hsfusion and die Infos von mmh, z.B. Screensaver an/aus ?

        Kommentar


          #5
          Ok, jetzt ist es etwas klarer.

          Es gibt wie schon beschrieben zwei Möglichkeiten.

          1. mit cf:// ein weiteres GUI File verlinken. Also zwischen mmh und hs umschalten.

          2. das KO-Gateway. Für den Screensaver wird das gut gehen, für Playlists etc. ist das aber eher nicht geeignet. Da bleibt dann derzeit nur Möglichkeit 1.
          Gruß Christian

          Kommentar


            #6
            Was vielleicht auch noch eine Möglichkeit wäre (ungetestet)

            - mmh und hsfusion mit gleichen Zugangsdaten ausstatten
            - Joins unterschiedlich zuweisen (join 1-100 = mmh 101-200 = hsfusion)

            Dann sollte auf beide Systeme von einer Seite zugegriffen werden können oder?

            Wie gesagt das ist alles reine Theorie....

            Kommentar


              #7
              Hi Micha,

              verschiedene Wertebereiche sind schonmal sinnvoll, aber beide Systeme haben unterschiedliche IPs.

              @Christian:
              Da die Umschaltzeit (Variante 1), wie von dir beschrieben, nicht so toll ist:

              Nochmal zurück zur ursprünglichen Idee. Man bräuchte einen Schalter, der es ermöglicht, dass die Kommunikation zum iViewer von hsfusion an ein anderes System weitergeleitet wird. (so wie mmh das mit der relay Funktion auch macht).

              Kommentar


                #8
                Dann sollte auf beide Systeme von einer Seite zugegriffen werden können oder?

                Wie gesagt das ist alles reine Theorie....
                Wie soll denn eine TCP-Verbindung zu zwei Systemen gleichzeitig gehen?

                Man bräuchte einen Schalter, der es ermöglicht, dass die Kommunikation zum iViewer von hsfusion an ein anderes System weitergeleitet wird. (so wie mmh das mit der relay Funktion auch macht).
                Die Datenpunkte zu mmh zu schaufeln geht doch über das KO-Gatway.
                Gruß Christian

                Kommentar


                  #9
                  Ich weiß nicht wie mmh das macht. Aber so wie es aussieht geht es da auch nicht.

                  hsfusion hällt sich beim Verbindungsaufbau strict an das SDK My Account

                  Das Passwort müsste dann weitergegeben werden, was passiert dann mit dem INIT? wird das verworfen ? Laut Specifikation gibt es ein Init nur am Anfang einer Sitzung direkt nach dem Passwort. Der iViewer weiß beim Relay ja nix davon. Oder geht es um ein generelles Weiterschalten bevor die Verbindung aufgebaut wird ? Das träfe dann aber auch nicht deine Beschreibung.

                  Relay generell an sich würde gehen, also bevor irgendeine Session läuft, aber was soll das bringen ? Ich hab zum wechsel einfach 2 Apps. 1 x CF 1x K... (vergessen)
                  Nils

                  aktuelle Bausteine:
                  BusAufsicht - ServiceCheck - Pushover - HS-Insight

                  Kommentar


                    #10
                    ohne das jetzt im Detail zu kennen:

                    Muss ich dem iviewer denn die Umschaltung überhaupt mitteilen? Dieser kann doch weiterhin mit dem HS kommunizieren und nichts von der Weiterleitung erfahren?!
                    Deer HS leitet (intern) einfach alles an mmh weiter. Mmh müsste dann durch den HS so aktiviert werden, dass es kein INIT machen will, also quasi im relay Modos angesprochen wird.

                    Oder stelle ich mir das zu einfach vor?

                    Kommentar


                      #11
                      Ja das stellst du dir zu einfach vor.

                      Ok nehmen wir mal an ich Verbinde jetzt einfach vom HS zu mmh (sprich ich melde mich mit dem Passwort (( welches hoffentlich nicht an die IP gekoppelt ist (((geht bei hsfusion ))) )) das der iviewer an hsfusion geschickt hat bei mmh an. Das INIT verschlucke ich jetzt einfach ??. Woher soll der iViewer dann die Initialen States/palylist... was auch immer bekommen // OK ich nehme das INIT von mmh und füge es dem Lokalen INIT hinzu, ohne zu wissen wohin mit diesen Daten ? )

                      Ein zusätzlicher Baustein der am HSfusion send/receive hängt wäre denkbar.
                      Der würde sich beim Starten mit mmh verbinden und durch das INIT bzw. die laufend eintreffenden Werte wissen welche joins für IHN wären und diese dann an mmh weiterleiten. .............. aber was passiert wenn mmh aus und keine Verbindung mehr ? hs versucht kontinuirlich mmh zu erreichen ?

                      Sorry aber der Nutzen gegenüber dem Aufwand und der daraus reultierenden Anfälligkeiten sind in keinem Verhältnis zueinander.
                      Nils

                      aktuelle Bausteine:
                      BusAufsicht - ServiceCheck - Pushover - HS-Insight

                      Kommentar


                        #12
                        Ich klinke mich an der Stelle mal ein.

                        @Nils:
                        - der init vom iViewer ist nichts anderes als eine Anfrage nach einem "Join-Dump" vom Server. Funktional hat der init auf dem Client keine Auswirkung.
                        - mmh löst das so:
                        Das (De-)Aktivieren einer Relay-Verbindung kann man an einen Join und seinen Zustand koppeln, also z.b.
                        d507=1 -> relay zu 192.168.2.25:5000 aktiveren
                        d507=0 -> relay deaktiveren

                        Wird das Relay aktiviert, baut mmh eine Verbindung zur entfernten Maschine auf, löscht alle Joins != 0 auf dem iViewer (=Start-Zustand der App) und sendet ein "i=1" an die entfernte Maschine (das Passwort-Request beim Aufbau der Relay Verbindung fehlt in mmh noch, da bisher nie benötigt. mmh besteht auch nicht auf eine Passwort-Abfrage, wenn kein Passwort gesetzt ist).
                        Ab diesem Zeitpunkt wird alles zwischen entfernter Maschine und Client wie ein Proxy geforwarded (inkl. Heartbeat) und geloggt.
                        Lediglich Joins (inkl. ihres Zustands), die eine Relay-Funktion haben, werden lokal verarbeitet.

                        Wird das Relay beendet (egal ob manuell oder durch abreißende Verbindung), werden alle von der entfernten Maschine geschriebenen Joins, die != 0 waren, wieder gelöscht und anschließend der lokale init-String neu gesendet. Damit bekommt der Client wieder ein exaktes Abbild der lokalen Maschine.

                        Alles ganz einfach, durchgängig und überhaupt nicht kompliziert.
                        Gruß

                        Sascha

                        Kommentar


                          #13
                          Zitat von no sleep Beitrag anzeigen
                          Wird das Relay aktiviert, baut mmh eine Verbindung zur entfernten Maschine auf, löscht alle Joins != 0 auf dem iViewer (=Start-Zustand der App)
                          OK das wäre dann der INIT-Cache mit allem genullt

                          und sendet ein "i=1" an die entfernte Maschine (das Passwort-Request beim Aufbau der Relay Verbindung fehlt in mmh noch, da bisher nie benötigt. mmh besteht auch nicht auf eine Passwort-Abfrage, wenn kein Passwort gesetzt ist).
                          OK das erklärt schonmal warum das relay mmh -> hsfusion nicht geht, hsfusion besteht selbst bei keinem Passwort auf das "p=", sonst geht garnichts. Könnte ich aber einbauen und als weitere Option die für den Relay eh benötigt würden machen.


                          die eine Relay-Funktion haben, werden lokal verarbeitet.
                          Das würde dann höchstens mit einer Maske gehen
                          LocalMask=3000-4000 würde alle joins von 3000-4000 als Lokal betrachten und diese dann natürlich auch nicht beim nullen des INIT-Cache beachten.


                          ............. mal sehen ....... kommt aber weiter unten auf die ToDo ......
                          derzeit sind da noch hsphone neu(40%),hsfusion-ListConnector(10%),SystemLog Regex erneuern(0%), Textarchiv(30%), xxAPI2 (0%) .......................... hsfusion relay
                          Nils

                          aktuelle Bausteine:
                          BusAufsicht - ServiceCheck - Pushover - HS-Insight

                          Kommentar

                          Lädt...
                          X