Gira X1

[knxPaul]

Ein Datenpunkt für Schreiben und Status lässt sich im GPA an Betriebsmodus und an Status Betriebsmodus eintragen, ohne Fehler beim Projekte prüfen. Wie der X1 darauf reagiert kann ich nicht so schnell herausfinden. Hast Du einen X1 zur Verfügung? Sonst checke ich das nächste Woche.

Ich habe die Trennung aus der Erfahrung "gebranntes Kind" gemacht, weil mir nicht klar ist, aus welchem Grund Gira hier zwei Datenpunkte nutzt. Der Betriebsmodus kann auch von Tastern verändert werden. Es fällt mir recht schwer, mir vorzustellen, wie der Status Betriebsmodus neben dem RTR von einer zweiten Quelle verändert werden kann.

Im redundanten KNX-System gibt es regelmäßig mehrere gleichwertige Lösungen für eine Aufgabe

[martiko]

Auf die identische GA für schreiben und Status wird sowohl geschrieben als auch davon gelesen genau so, wie das auch die KOs auf dem KNX-Bus tun. Wer im GPA die GAs aus dem ETS Projekt importiert und daraus einen neuen Datenpunkt erzeugt erhält als Voreinstellung identische GAs für Senden und Status. In diesem Sinn ist das also der Standardfall.

Ich meinte jetzt ganz konkret beim Betriebsmodus, da schreibst Du ja, dass der X1 zwei getrennte Datenpunkte erwartet (so hast Du es ja wie man im Screenshot sieht) auch konfiguriert.
Was passiert denn wenn man stattdessen einen Datenpunkt für Schreiben und Status anlegen würde (so wie ich es z.B. bei Dimm- oder Schalt-Aktor gemacht), also in Deinem Beispiel "3/0/2 3/0/12" und diesen DP dann sowohl bei Betriebsmodus als auch Status Betriebsmodus eintragen würde (so hätte ich es spontan gemacht). Akzeptiert der GPA das gar nicht, oder wird dann falsch geschrieben/gelesen, oder...?

[knxPaul]

Auf welchem KO des Heizungsaktors liegt die Präsenz GA 3\0\3

Der Heizungsaktor Gira 2129 00 hat dafür das KO 327 "Regler x - Eingang Präsenztaste", das auf den Betriebsmodus wirkt.

warum haben im GPA die Datenpunkte getrennte GAs für schreiben und Lesen, wenn man dann an manchen Stellen doch zwei angeben muss?

Datenpunkte sind ein allgemeines Konzept im GPA und für viele unterschiedlichen Anwendungen immer gleich aufgebaut.
Häufig stehen da zwei unterschiedliche GAs für Vorgabe und Status. Das hängt davon ab, wie die GAs in der ETS angebunden wurden und ob es eine eigenständige Status-GA gibt. Manchmal muss man den Status in die Hörende Adresse verschieben, um eine Loop zu vermeiden.
Alles soll ein übersichtliches Verbinden eines Datenpunktes auf eine Funktion eines Visu- oder Logik-Elements im GPA ermöglichen.

In der ETS wird die Datenrichtung am KO mit Flags beschrieben; Flags gibt es im GPA nicht; Ersatzweise unterscheiden Datenpunkte zwischen "Senden" und "Status/Rückmeldung".

was passiert denn wem man in einem Datenpunkte beides separat angibt und den identischen Datenpunkte für schreiben und Status einträgt?

Auf die identische GA für schreiben und Status wird sowohl geschrieben als auch davon gelesen genau so, wie das auch die KOs auf dem KNX-Bus tun. Wer im GPA die GAs aus dem ETS Projekt importiert und daraus einen neuen Datenpunkt erzeugt erhält als Voreinstellung identische GAs für Senden und Status. In diesem Sinn ist das also der Standardfall.

[martiko]

3. Den Betriebsmodus will der X1 auf zwei getrennten Datenpunkt haben: Einmal für zu schreibenden Wert und noch einmal für den Status.
Die Präsenz ist nur ein Datenpunkt, mit dem geschrieben und gelesen wird.
In jedem Fall erwartet der X1 die zu lesenden GAs unter "Status/Rückmeldung".

Nicht geprüftes Beispiel als Bild

Das ist ja eine interessante Info und (für meinen Geschmack) irgendwie inkonsistent, warum haben im GPA die Datenpunkte getrennte GAs für schreiben und Lesen, wenn man dann an manchen Stellen doch zwei angeben muss?
was passiert denn wem man in einem Datenpunkte beides separat angibt und den identischen Datenpunkte für schreiben und Status einträgt?

[schoenauen]

3.
In jedem Fall erwartet der X1 die zu lesenden GAs unter "Status/Rückmeldung".

Nicht geprüftes Beispiel als Bild

Auf welchem KO des Heizungsaktors liegt die Präsenz GA 3\0\3 in deinem Beispiel? Danke

[knxPaul]

3. Den Betriebsmodus will der X1 auf zwei getrennten Datenpunkt haben: Einmal für zu schreibenden Wert und noch einmal für den Status.
Die Präsenz ist nur ein Datenpunkt, mit dem geschrieben und gelesen wird.
In jedem Fall erwartet der X1 die zu lesenden GAs unter "Status/Rückmeldung".

Nicht geprüftes Beispiel als Bild

[Shine120]

Hey.

1. Man kann deinen Nachnamen im Bild lesen....

2. Bist du der ersteller des KNX Projekts und auch der ersteller des X1 Projekts im Gira Projekt Assitent?
Welches Heizungsaktor setzt du ein?

Sind in den anderen Räumen auch alle Datenpunkte entsprechend Verbunden?

Hast du den Datentyp deines Aktor mit dem Datentyp der GA abgeglichen die im X1 Projekt angelegt ist!? Sind die Rückmeldeadresse die richtigen?

[marioe2111]

EF34B171-EB9D-4906-A5A3-912B37EB08B2.jpeg
Hi zusammen,
ich habe bei mir ein Problem, wo ich eure Hilfe benötige. Und zwar wird bei nur einem meiner Raumtemperaturregler über die X1 Visu die Präsenz angezeigt und ich kann diese dort ein und ausschalten (siehe Bild). Je nach dem wechselt automatisch der Betriebsmodus zwischen Komfort und Standby. Bei allen anderen Räumen wird mir dieser Button erst garnicht angezeigt. Wenn ich allerdings den Wer „ein“ manuell im schreibe taucht der Button dort plötzlich auf. Drücke ich diesen verschwindet er allerdings und bleibt nicht da. Verstehe das irgendwie nicht. Kennt jemand das Problem?

[Beleuchtfix]

Ob und wo das auf der Gerätewebseite steht, weiß ich gerade auch nicht.

Auf der Diagnoseseite steht folgendes:
Zwischenablage01.jpg

Roman, vielleicht hilft das auch.
Gruß
Florian

[crewo]

Und genau deshalb erwarte ich so eine Basis-Funktion vom Hersteller, der dies selbst bitte über eine eigene API zur Verfügung stellt (also quasi Proxy spielt) und das im Gerät nativ implementiert. So kann man die Quelle jederzeit wechseln oder reagieren auf Änderungen an einer Stelle. Klar kann ich mir das auch selbst basteln, aber auch ich hatte hier schon 3-4 Dienste durch in den letzten 5 Jahren.

[SirUli]

Inwiefern ist ein Web Request und ein XML/JSON-Parser fragiler als der OWM-Baustein? Beide werden versagen, wenn OWM sein API ändert.

Sorry hatte den letzten Satz nicht im korrekten Kontext geschrieben Bin ich bei dir - tatsächlich nutze ich lieber den Web Request&Parser als den OWM Baustein genau aus diesem Grund. Wenn ich aber überlege wieviele Wetter-APIs ich seit 2003 genutzt habe und schon wieder aus dem Markt verschwunden/zurückgezogen (DarkSky, Yahoo etc.) wurden...dann ist das nichts was ich einem Kunden für die nächsten 5 Jahre als dauerhaft funktionierend versprechen kann (auch wenn die API von OWM aktuell stabil und verfügbar ist). Und nun sind wir beim Kontext, welcher auf beide Lösungen zutrifft und die fragilität erklären soll Sorry!

[hyman]

Während ich Crewo und BadSmiley in den Kommentaren durchaus zustimme, gibt es aber doch zumindest einen Wetterbaustein: https://knx-user-forum.de/forum/supp...en-weather-map.

Wenn auch leider nicht ganz optimal (da nicht für die nächsten Tage) aber immerhin genug für die nächsten paar Stunden. Ansonsten gibts natürlich noch gebastel mit XML abruf und selber parsen Würde ich aber keinem Kunden einbauen - das ist mir zu fragil.

Inwiefern ist ein Web Request und ein XML/JSON-Parser fragiler als der OWM-Baustein? Beide werden versagen, wenn OWM sein API ändert. Nur kannst Du beim fertigen Baustein dann nix dagegen tun, beim frei konfigurierbaren Parser schon.

[crewo]

gibt es aber doch zumindest einen Wetterbaustein:

Der aber kann das Entscheidende für Gebäudeautomation nicht leisten (bzw. nur über zusätzliche Schätzlogik nicht optimal): Mir einfach die Höchst- Und Tiefstwerte des Tages ausgeben, damit ich eine Verschattung, Heiz- und/oder Kühlstrategie und Lüftungseinstellung (Bypass, Nachts erhöht, Tags erhöht usw.) ansteuern kann. Ich finde auch sowas muss vom Hersteller kommen und unterstützt sein, das ist trotz Wetterstation einfach sinnvoll. Z.B. auch die zu erwartende Regenmenge der nächsten 3 Tage usw...

[mst89]

Die Einschränkung mit dem AppShop auf nur Berechtigte empfinde ich auch als sehr suboptimal. In meinem Umkreis gibt es nur zwei Elektriker, die KNX Partner sind und auch implementieren, nur einer davon verbaut auch GIRA-Komponenten.

Nun hat aber ein komplett anderer Elektriker bei mir im Haus alles verlegt und ich habe selbstständig parametriert etc.
Für die 1-2 Bausteine mag ich aber nicht bei einem Elektriker anklopfen, der keinen Bezug zu meinem EFH/Projekt hat.

Verstehe nicht, was aus Sicht GIRA dagegen spricht, dass der Bauherr, WENN ER DENN MÖCHTE, selbst rein und kaufen darf...

[dalbuschat]

crewo Sorry, Informationen über die Roadmap von Gira wirst du hier leider nicht erhalten können. Ich habe dein Feedback aber an die passende Stelle weitergeleitet. Gruß!