Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Was für einiges an Diskussion bzw Support sorgen wird, weil das Thema gar nicht so einfach ist und man gerne mal einen Schritt wie die Assoziationen mit den Geräten vergisst. DURCHZUG gibt es dann nämlich ENDLICH nicht mehr.
KNX-Secure
In den Projekteinstellungen kann unter KNX-Anbindung unter folgenden KNX Secure Zugriffsmöglichen gewählt werden:
KNXnet/IP routing (mit KNX Secure Unterstützung) zusätzlich kann noch die Option IP-Secure gewählt werden
Hinweis KNX Secure:
Im ETS Projekt muss für jede KNX Secure Anbindung ein Gerät als Gira Home-Server Repräsentant eingefügt bzw. paramertiert werden. Das ist notwendig, weil alle KNX Secure Geräte immer alle KNX Secure Absender kennen müssen. Der Gira HomeServer bekommt die Informationen über die anderen KNX Secure Geräte durch den KNX Secure Schlüsselbund (in der ETS unter den Projekteinstellungen
und Sicherheit). Der Schlüsselbund wird aus der ETS exportiert und in den Gira HomeServer über die Seite https://<IP-Adresse>/hsknxkeys importiert. Gruppenadressen, die in der ETS als KNX Secure gekennzeichnet sind und die Nutzinformationen, werden nach dem Import der Schlüsseldatei (und Gira HomeServer Neustart) verschlüsselt vom Gira HomeServer versendet. Gruppenadressen, die in der ETS nicht als KNX Secure gekennzeichnet sind, werden vom Gira HomeServer unverschlüsselt versendet.
KNXnet/IP Routing: Auf der Backbone muss eine KNX Secure fähige Dummy Applikation eingefügt werden, auf die alle im Gira HomeServer verwendeten KNX Secure Gruppenadressen gezogen werden.
KNX-USB Schnittstelle: Auf die KNX USB-Schnittstelle müssen alle KNX Secure Gruppenadressen als "Assoziationen" hinzugefügt werden.
KNXnet/IP Tunneling: Auf die Tunnelling-Verbindung, auf die der Gira HomeServer zugreift, müssen alle KNX Secure Gruppenadressen als "Assoziationen" hinzugefügt werden.
Dieser Beitrag enthält keine Spuren von Sarkasmus... ich bin einfach so?!
Anbindung an IoT-Dienste
Der Gira HomeServer kann über ein Fernzugriffsmodul (z.B. der Gira S1) an IoTDienste, wie z. B. Amazon Alexa, Google Assistant oder IFTTT angebunden werden. Ist das Fernzugriffsmodul dem Gira Geräteportal zugewiesen, dann wird ein Gira HomeServer mit der FW 4.10.0 automatisch aufgelistet, sofern im Quad-Config mindestens ein Benutzer als IoT-Benutzer gekennzeichnet wurde (Option „für IoT-Dienste bereitstellen“).
Im QuadConfig sind die Templates, die in IoT-Diensten genutzt werden können mit einem "grünen Punkt" gekennzeichnet. Es ist hierzu keine weitere Parametierung
notwendig.
Das heißt dass ein S1 zusätzlich nötig ist um IFTTT mit Bordmitteln der 4.10 des HS zu nutzen?
Das heißt dass ein S1 zusätzlich nötig ist um IFTTT mit Bordmitteln der 4.10 des HS zu nutzen?
So wie ich das verstanden habe (und mir die Gira Hotline vor ca. 2 Wochen bestätigt hat) leider "Ja".
Irgendwie muss Gira den S1 ja an den Mann bringen. Aus technischer Sicht ist ein S1 mMn nicht notwendig zumal der HS ja eh schon Zugriff auf das Gira Portal hat...
Na ja die rls notes deutet man anders. z.B. Gira S1
"QuadClient
Anbindung an IoT-Dienste
Der Gira HomeServer kann über ein Fernzugriffsmodul (z.B. der Gira S1) an IoTDienste,
wie z. B. Amazon Alexa, Google Assistant oder IFTTT angebunden werden.
Ist das Fernzugriffsmodul dem Gira Geräteportal zugewiesen, dann wird ein
Gira HomeServer mit der FW 4.10.0 automatisch aufgelistet, sofern im Quad-
Config mindestens ein Benutzer als IoT-Benutzer gekennzeichnet wurde (Option
„für IoT-Dienste bereitstellen“).
Im QuadConfig sind die Templates, die in IoT-Diensten genutzt werden können
mit einem "grünen Punkt" gekennzeichnet. Es ist hierzu keine weitere Parametierung
notwendig."
Habe gestern mal 4.10 installiert und muss leider sagen, dass ich mit meinem Projekt ziemlich viele Probleme habe (ich habe kein Secure aktiviert).
Positiv ist mir aufgefallen, dass Design1 im QC nun auch die thematischen Symbole vor den Zeilen anzeigt, das hatte 4.9 noch nicht, weiterhin gab es einige kleine optische Anpassungen im QC, wie beispielsweise "Kameraansicht verkleinern", was jetzt kein unmotivierter runder Punkt in der Titelleiste mehr ist.
Leider scheint die Software den HS zu überfordern, ich bekomme jedenfalls nach ca. 20-30 Minuten Laufzeit das Kamerabild von meiner Türklingel (da polle ich 4x pro Sekunde das JPG) wegen zu langer Antwortzeit nicht mehr angezeigt und muss den Quadranten wechseln und zurück, damit das Bild wieder erscheint.
Irgendwann werden Buszugriffe dann auch sehr langsam, teilweise muss man Funktionen mehrfach aufrufen, damit sie auf den Bus gesendet werden.
Manche Logikbausteine funktionieren wohl auch nicht mehr, da die Fehlerliste auf der HS-Debugseite recht gefüllt ist.
Auch habe ich das Gefühl, dass das Übertragen von Projekten deutlich länger dauert wie mit der 4.9.
Der Monitor des HS zeigt sekündlich irgendwelche SSDP Meldungen (Simple Service Discovery Protocol) an, was aber vermutlich kein Fehler ist.
Ich werde wohl wieder auf die 4.9 zurück gehen und auf die 4.11 warten, in der Hoffnung, dass bis dahin die Probleme behoben wurden. Mit zwischenzeitlichen Bugfixes ist bei Gira ja eher nicht zu rechnen...
Von der 4.9 auf die 4.10 hat sich nicht so viel geändert, wie von 4.6 auf 4.7 im Bezug auf die Logiken so wie deren Behandlung (Root Rechte usw). Darum glaube/vermute ich nicht das die Fehler dort liegen. Auch hat sich das Kameraplugin (egal ob 1 oder 2) mit Version 4.9 auf 4.10 nicht geändert?
Dieser Beitrag enthält keine Spuren von Sarkasmus... ich bin einfach so?!
In den hs_main exceptions habe ich bei 4.10 (nicht bei 4.9):
Code:
File "hs_event.py", line 943, in doSend
File "lib_tcpclient.py", line 44, in connect
File "/usr/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
error: [Errno 113] No route to host
Sieht sehr nach einem Netzwerkproblem aus, nur ist da ja nichts geändert.
Zudem habe noch die Demo von HS-Connect Sonos drauf (auch aktualisiert), die meldet bei 4.10: Unexpected DebugError!! (, error(90, 'Message too long'), ) HSConnect_SONOS (13210) - Unexpected Error!! Unexpected error on writing to iKo. Value: GAG13210 - 192.168.169.53: INFO: __ZPController(): Currently registered Clients (local / global): {} / {} , (, TypeError('checkLogik() takes exactly 3 arguments (2 given)',), )
lange Ladezeiten des Projekts sehe ich auch. Wenn er läuft, doch relativ ok. Bei mir geht mal wieder die Buderus Kopplung nicht mehr. Kein Verbindungsaufbau, finde noch nicht den Fehler.
Hach, es wäre ja soooo schön, wenn man einzelne Logikeditor-Blätter im Experten deaktivieren könnte, um so Fehlern leichter auf den Grund zu kommen.
Das kann doch echt jede andere Logikengine. Gira bitte... !
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar